Re: [PATCH v6 3/7] xen/arm: setup MMIO range trap handlers for hardware domain
Hi, Julien!
On 23.11.21 18:58, Julien Grall wrote:
> Hi,
>
> On 23/11/2021 16:41, Oleksandr Andrushchenko wrote:
>> On 23.11.21 18:12, Julien Grall wrote:
>>> On 23/11/2021 06:58, Oleksandr Andrushchenko wrote:
unsigned int domain_vpci_get_num_mmio_handlers(struct domain *d)
{
if ( !has_vpci(d) )
return 0;
if ( is_hardware_domain(d) )
{
int ret = pci_host_iterate_bridges_and_count(d,
vpci_get_num_handlers_cb);
return ret < 0 ? 0 : ret;
}
/*
* This is a guest domain:
*
* 1 for a single emulated host bridge's configuration space.
*/
return 1;
>>>
>>> I am afraid that my question stands even with this approach. This patch is
>>> only meant to handle the hardware domain, therefore the change seems to be
>>> out of context.
>>>
>>> I would prefer if this change is done separately.
>> While I do agree that MSI part and virtual bus topology are not belonging to
>> this
>> patch I can't agree with the rest: we already have MMIO handlers for guest
>> domains
>> and we introduce domain_vpci_get_num_mmio_handlers which must also account
>> on guests and stay consistent.
>> So, despite the patch has "hardware domain" in its name it doesn't mean we
>> should
>> break guests here.
>
> We were already registering the handler for guest domain before your patch.
> So this is nothing new.
>
> At the moment, we always allocate an extra 16 slot for IO handlers (see
> MAX_IO_HANDLER). So we are not breaking anything. Instead, this is simply a
> latent bug.
Agree
>
>> Thus I do think the above is still correct wrt this patch.
>
> The idea of splitting patch is to separate bug fix from new code. This helps
> backporting and review.
>
> In this case, we don't care about backport (PCI passthrough is no supported)
> and the fix a simple enough. So I am not going to insist on splitting to a
> separate patch.
>
> However, this change *must* be explained in the commit message.
I will add a dedicated patch to fix that
>
> Cheers,
>
Thank you,
Oleksandr
Re: [PATCH v6 3/7] xen/arm: setup MMIO range trap handlers for hardware domain
Hi,
On 23/11/2021 16:41, Oleksandr Andrushchenko wrote:
On 23.11.21 18:12, Julien Grall wrote:
On 23/11/2021 06:58, Oleksandr Andrushchenko wrote:
unsigned int domain_vpci_get_num_mmio_handlers(struct domain *d)
{
if ( !has_vpci(d) )
return 0;
if ( is_hardware_domain(d) )
{
int ret = pci_host_iterate_bridges_and_count(d,
vpci_get_num_handlers_cb);
return ret < 0 ? 0 : ret;
}
/*
* This is a guest domain:
*
* 1 for a single emulated host bridge's configuration space.
*/
return 1;
I am afraid that my question stands even with this approach. This patch is only
meant to handle the hardware domain, therefore the change seems to be out of
context.
I would prefer if this change is done separately.
While I do agree that MSI part and virtual bus topology are not belonging to
this
patch I can't agree with the rest: we already have MMIO handlers for guest
domains
and we introduce domain_vpci_get_num_mmio_handlers which must also account
on guests and stay consistent.
So, despite the patch has "hardware domain" in its name it doesn't mean we
should
break guests here.
We were already registering the handler for guest domain before your
patch. So this is nothing new.
At the moment, we always allocate an extra 16 slot for IO handlers (see
MAX_IO_HANDLER). So we are not breaking anything. Instead, this is
simply a latent bug.
Thus I do think the above is still correct wrt this patch.
The idea of splitting patch is to separate bug fix from new code. This
helps backporting and review.
In this case, we don't care about backport (PCI passthrough is no
supported) and the fix a simple enough. So I am not going to insist on
splitting to a separate patch.
However, this change *must* be explained in the commit message.
Cheers,
--
Julien Grall
Re: [PATCH v6 3/7] xen/arm: setup MMIO range trap handlers for hardware domain
Hi, Julien!
On 23.11.21 18:12, Julien Grall wrote:
>
>
> On 23/11/2021 06:58, Oleksandr Andrushchenko wrote:
>> Hi, Julien!
>
> Hi Oleksandr,
>
>> On 22.11.21 19:36, Julien Grall wrote:
>>> On 18/11/2021 10:46, Oleksandr Andrushchenko wrote:
On 18.11.21 09:27, Oleksandr Andrushchenko wrote:
>>> + unsigned int count;
>>> +
>>> + if ( is_hardware_domain(d) )
>>> + /* For each PCI host bridge's configuration space. */
>>> + count = pci_host_get_num_bridges();
>> This first part makes sense to me. But...
>>
>>> + else
>> ... I don't understand how the else is related to this commit. Can you
>> clarify it?
>>
>>> + /*
>>> + * There's a single MSI-X MMIO handler that deals with both PBA
>>> + * and MSI-X tables per each PCI device being passed through.
>>> + * Maximum number of supported devices is 32 as virtual bus
>>> + * topology emulates the devices as embedded endpoints.
>>> + * +1 for a single emulated host bridge's configuration space.
>>> + */
>>> + count = 1;
>>> +#ifdef CONFIG_HAS_PCI_MSI
>>> + count += 32;
>> Surely, this is a decision that is based on other factor in the vPCI
>> code. So can use a define and avoid hardcoding the number?
> Well, in the later series [1] this is defined via PCI_SLOT(~0) + 1 and
> there is no dedicated
> constant for that. I can use the same here, e.g. s/32/PCI_SLOT(~0) + 1
>>>
>>> I would prefer if we introduce a new constant for that. This makes easier
>>> to update the code if we decide to increase the number of virtual devices.
>>>
>>> However, I am still not sure how the 'else' part is related to this commit.
>>> Can you please clarify it?
>> Well, yes, this is too early for this patch to introduce some future
>> knowledge, so I'll instead have:
>>
>> unsigned int domain_vpci_get_num_mmio_handlers(struct domain *d)
>> {
>> if ( !has_vpci(d) )
>> return 0;
>>
>> if ( is_hardware_domain(d) )
>> {
>> int ret = pci_host_iterate_bridges_and_count(d,
>> vpci_get_num_handlers_cb);
>>
>> return ret < 0 ? 0 : ret;
>> }
>>
>> /*
>> * This is a guest domain:
>> *
>> * 1 for a single emulated host bridge's configuration space.
>> */
>> return 1;
>
> I am afraid that my question stands even with this approach. This patch is
> only meant to handle the hardware domain, therefore the change seems to be
> out of context.
>
> I would prefer if this change is done separately.
While I do agree that MSI part and virtual bus topology are not belonging to
this
patch I can't agree with the rest: we already have MMIO handlers for guest
domains
and we introduce domain_vpci_get_num_mmio_handlers which must also account
on guests and stay consistent.
So, despite the patch has "hardware domain" in its name it doesn't mean we
should
break guests here.
Thus I do think the above is still correct wrt this patch.
>
> Cheers,
>
Thank you,
Oleksandr
Re: [PATCH v6 3/7] xen/arm: setup MMIO range trap handlers for hardware domain
On 23/11/2021 06:58, Oleksandr Andrushchenko wrote:
Hi, Julien!
Hi Oleksandr,
On 22.11.21 19:36, Julien Grall wrote:
On 18/11/2021 10:46, Oleksandr Andrushchenko wrote:
On 18.11.21 09:27, Oleksandr Andrushchenko wrote:
+ unsigned int count;
+
+ if ( is_hardware_domain(d) )
+ /* For each PCI host bridge's configuration space. */
+ count = pci_host_get_num_bridges();
This first part makes sense to me. But...
+ else
... I don't understand how the else is related to this commit. Can you clarify
it?
+ /*
+ * There's a single MSI-X MMIO handler that deals with both PBA
+ * and MSI-X tables per each PCI device being passed through.
+ * Maximum number of supported devices is 32 as virtual bus
+ * topology emulates the devices as embedded endpoints.
+ * +1 for a single emulated host bridge's configuration space.
+ */
+ count = 1;
+#ifdef CONFIG_HAS_PCI_MSI
+ count += 32;
Surely, this is a decision that is based on other factor in the vPCI code. So
can use a define and avoid hardcoding the number?
Well, in the later series [1] this is defined via PCI_SLOT(~0) + 1 and there is
no dedicated
constant for that. I can use the same here, e.g. s/32/PCI_SLOT(~0) + 1
I would prefer if we introduce a new constant for that. This makes easier to
update the code if we decide to increase the number of virtual devices.
However, I am still not sure how the 'else' part is related to this commit. Can
you please clarify it?
Well, yes, this is too early for this patch to introduce some future knowledge,
so I'll instead have:
unsigned int domain_vpci_get_num_mmio_handlers(struct domain *d)
{
if ( !has_vpci(d) )
return 0;
if ( is_hardware_domain(d) )
{
int ret = pci_host_iterate_bridges_and_count(d,
vpci_get_num_handlers_cb);
return ret < 0 ? 0 : ret;
}
/*
* This is a guest domain:
*
* 1 for a single emulated host bridge's configuration space.
*/
return 1;
I am afraid that my question stands even with this approach. This patch
is only meant to handle the hardware domain, therefore the change seems
to be out of context.
I would prefer if this change is done separately.
Cheers,
--
Julien Grall
Re: [PATCH v6 3/7] xen/arm: setup MMIO range trap handlers for hardware domain
Hi, Julien!
On 22.11.21 19:36, Julien Grall wrote:
> Hi,
>
> On 18/11/2021 10:46, Oleksandr Andrushchenko wrote:
>> On 18.11.21 09:27, Oleksandr Andrushchenko wrote:
>>> Hi, Julien!
>>>
>>> On 16.11.21 21:12, Julien Grall wrote:
Hi Oleksandr,
On 05/11/2021 06:33, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> In order for vPCI to work it needs to maintain guest and hardware
> domain's views of the configuration space. For example, BARs and
> COMMAND registers require emulation for guests and the guest view
> of the registers needs to be in sync with the real contents of the
> relevant registers. For that ECAM address space needs to also be
> trapped for the hardware domain, so we need to implement PCI host
> bridge specific callbacks to properly setup MMIO handlers for those
> ranges depending on particular host bridge implementation.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> Since v5:
> - add vpci_sbdf_from_gpa helper for gpa to SBDF translation
> - take bridge's bus start into account while calculating SBDF
> Since v4:
> - unsigned int for functions working with count
> - gate number of MMIO handlers needed for CONFIG_HAS_PCI_MSI
> and fix their number, e.g. single handler for PBA and
> MSI-X tables (Roger)
> - re-work code for assigning MMIO handlers to be simpler
> and account on the fact that there could multiple host bridges
> exist for the hwdom
> Since v3:
> - fixed comment formatting
> Since v2:
> - removed unneeded assignment (count = 0)
> - removed unneeded header inclusion
> - update commit message
> Since v1:
> - Dynamically calculate the number of MMIO handlers required for vPCI
> and update the total number accordingly
> - s/clb/cb
> - Do not introduce a new callback for MMIO handler setup
> ---
> xen/arch/arm/domain.c | 2 +
> xen/arch/arm/pci/pci-host-common.c | 27
> xen/arch/arm/vpci.c | 66 ++
> xen/arch/arm/vpci.h | 6 +++
> xen/include/asm-arm/pci.h | 5 +++
> 5 files changed, 98 insertions(+), 8 deletions(-)
>
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 96e1b235501d..92a6c509e5c5 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -739,6 +739,8 @@ int arch_domain_create(struct domain *d,
> if ( (rc = domain_vgic_register(d, )) != 0 )
> goto fail;
> + count += domain_vpci_get_num_mmio_handlers(d);
> +
> if ( (rc = domain_io_init(d, count + MAX_IO_HANDLER)) != 0 )
> goto fail;
> diff --git a/xen/arch/arm/pci/pci-host-common.c
> b/xen/arch/arm/pci/pci-host-common.c
> index 47104b22b221..0d271a6e8881 100644
> --- a/xen/arch/arm/pci/pci-host-common.c
> +++ b/xen/arch/arm/pci/pci-host-common.c
> @@ -289,6 +289,33 @@ int pci_get_host_bridge_segment(const struct
> dt_device_node *node,
> return -EINVAL;
> }
> +int pci_host_iterate_bridges(struct domain *d,
> + int (*cb)(struct domain *d,
> + struct pci_host_bridge *bridge))
> +{
> + struct pci_host_bridge *bridge;
> + int err;
> +
> + list_for_each_entry( bridge, _host_bridges, node )
> + {
> + err = cb(d, bridge);
> + if ( err )
> + return err;
> + }
> + return 0;
> +}
> +
> +unsigned int pci_host_get_num_bridges(void)
> +{
> + struct pci_host_bridge *bridge;
> + unsigned int count = 0;
How about making this static and...
> +
> + list_for_each_entry( bridge, _host_bridges, node )
> + count++;
... only call list_for_each_entry() when count is -1? So we would only go
through the list once.
This should be fine given hostbridge can only be added during boot (we
would need to protect pci_host_bridges with a lock otherwise).
>>> Ok, I can do that
>> I have re-worked the patch so that more code can be re-used:
>>
>> if ( is_hardware_domain(d) )
>> {
>> int count;
>>
>> count = pci_host_iterate_bridges_and_count(d,
>> vpci_setup_mmio_handler_cb);
>> if ( count < 0 )
>> return count;
>>
>> return 0;
>> }
>>
>> register_mmio_handler(d, _mmio_handler,
>> GUEST_VPCI_ECAM_BASE, GUEST_VPCI_ECAM_SIZE,
>> NULL);
>>
>> so pci_host_get_num_bridges goes away.
>
> If this will be the only caller that needs to know the number hostbridges,
> then I am happy with this appropach. Otherwise, I would prefer to keep the
> helper
Re: [PATCH v6 3/7] xen/arm: setup MMIO range trap handlers for hardware domain
Hi,
On 18/11/2021 10:46, Oleksandr Andrushchenko wrote:
On 18.11.21 09:27, Oleksandr Andrushchenko wrote:
Hi, Julien!
On 16.11.21 21:12, Julien Grall wrote:
Hi Oleksandr,
On 05/11/2021 06:33, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
In order for vPCI to work it needs to maintain guest and hardware
domain's views of the configuration space. For example, BARs and
COMMAND registers require emulation for guests and the guest view
of the registers needs to be in sync with the real contents of the
relevant registers. For that ECAM address space needs to also be
trapped for the hardware domain, so we need to implement PCI host
bridge specific callbacks to properly setup MMIO handlers for those
ranges depending on particular host bridge implementation.
Signed-off-by: Oleksandr Andrushchenko
---
Since v5:
- add vpci_sbdf_from_gpa helper for gpa to SBDF translation
- take bridge's bus start into account while calculating SBDF
Since v4:
- unsigned int for functions working with count
- gate number of MMIO handlers needed for CONFIG_HAS_PCI_MSI
and fix their number, e.g. single handler for PBA and
MSI-X tables (Roger)
- re-work code for assigning MMIO handlers to be simpler
and account on the fact that there could multiple host bridges
exist for the hwdom
Since v3:
- fixed comment formatting
Since v2:
- removed unneeded assignment (count = 0)
- removed unneeded header inclusion
- update commit message
Since v1:
- Dynamically calculate the number of MMIO handlers required for vPCI
and update the total number accordingly
- s/clb/cb
- Do not introduce a new callback for MMIO handler setup
---
xen/arch/arm/domain.c | 2 +
xen/arch/arm/pci/pci-host-common.c | 27
xen/arch/arm/vpci.c | 66 ++
xen/arch/arm/vpci.h | 6 +++
xen/include/asm-arm/pci.h | 5 +++
5 files changed, 98 insertions(+), 8 deletions(-)
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 96e1b235501d..92a6c509e5c5 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -739,6 +739,8 @@ int arch_domain_create(struct domain *d,
if ( (rc = domain_vgic_register(d, )) != 0 )
goto fail;
+ count += domain_vpci_get_num_mmio_handlers(d);
+
if ( (rc = domain_io_init(d, count + MAX_IO_HANDLER)) != 0 )
goto fail;
diff --git a/xen/arch/arm/pci/pci-host-common.c
b/xen/arch/arm/pci/pci-host-common.c
index 47104b22b221..0d271a6e8881 100644
--- a/xen/arch/arm/pci/pci-host-common.c
+++ b/xen/arch/arm/pci/pci-host-common.c
@@ -289,6 +289,33 @@ int pci_get_host_bridge_segment(const struct
dt_device_node *node,
return -EINVAL;
}
+int pci_host_iterate_bridges(struct domain *d,
+ int (*cb)(struct domain *d,
+ struct pci_host_bridge *bridge))
+{
+ struct pci_host_bridge *bridge;
+ int err;
+
+ list_for_each_entry( bridge, _host_bridges, node )
+ {
+ err = cb(d, bridge);
+ if ( err )
+ return err;
+ }
+ return 0;
+}
+
+unsigned int pci_host_get_num_bridges(void)
+{
+ struct pci_host_bridge *bridge;
+ unsigned int count = 0;
How about making this static and...
+
+ list_for_each_entry( bridge, _host_bridges, node )
+ count++;
... only call list_for_each_entry() when count is -1? So we would only go
through the list once.
This should be fine given hostbridge can only be added during boot (we would
need to protect pci_host_bridges with a lock otherwise).
Ok, I can do that
I have re-worked the patch so that more code can be re-used:
if ( is_hardware_domain(d) )
{
int count;
count = pci_host_iterate_bridges_and_count(d,
vpci_setup_mmio_handler_cb);
if ( count < 0 )
return count;
return 0;
}
register_mmio_handler(d, _mmio_handler,
GUEST_VPCI_ECAM_BASE, GUEST_VPCI_ECAM_SIZE, NULL);
so pci_host_get_num_bridges goes away.
If this will be the only caller that needs to know the number
hostbridges, then I am happy with this appropach. Otherwise, I would
prefer to keep the helper pci_host_get_num_bridges().
+
+ return count;
+}
+
/*
* Local variables:
* mode: C
diff --git a/xen/arch/arm/vpci.c b/xen/arch/arm/vpci.c
index 23f45386f4b3..5a6ebd8b9868 100644
--- a/xen/arch/arm/vpci.c
+++ b/xen/arch/arm/vpci.c
@@ -16,16 +16,31 @@
#include
+static pci_sbdf_t vpci_sbdf_from_gpa(const struct pci_host_bridge *bridge,
+ paddr_t gpa)
+{
+ pci_sbdf_t sbdf;
+
+ if ( bridge )
+ {
+ sbdf.sbdf = VPCI_ECAM_BDF(gpa - bridge->cfg->phys_addr);
+ sbdf.seg = bridge->segment;
+ sbdf.bus += bridge->cfg->busn_start;
+ }
+ else
+ sbdf.sbdf = VPCI_ECAM_BDF(gpa - GUEST_VPCI_ECAM_BASE);
+
+
Re: [PATCH v6 3/7] xen/arm: setup MMIO range trap handlers for hardware domain
On 18.11.21 09:27, Oleksandr Andrushchenko wrote:
> Hi, Julien!
>
> On 16.11.21 21:12, Julien Grall wrote:
>> Hi Oleksandr,
>>
>> On 05/11/2021 06:33, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> In order for vPCI to work it needs to maintain guest and hardware
>>> domain's views of the configuration space. For example, BARs and
>>> COMMAND registers require emulation for guests and the guest view
>>> of the registers needs to be in sync with the real contents of the
>>> relevant registers. For that ECAM address space needs to also be
>>> trapped for the hardware domain, so we need to implement PCI host
>>> bridge specific callbacks to properly setup MMIO handlers for those
>>> ranges depending on particular host bridge implementation.
>>>
>>> Signed-off-by: Oleksandr Andrushchenko
>>> ---
>>> Since v5:
>>> - add vpci_sbdf_from_gpa helper for gpa to SBDF translation
>>> - take bridge's bus start into account while calculating SBDF
>>> Since v4:
>>> - unsigned int for functions working with count
>>> - gate number of MMIO handlers needed for CONFIG_HAS_PCI_MSI
>>> and fix their number, e.g. single handler for PBA and
>>> MSI-X tables (Roger)
>>> - re-work code for assigning MMIO handlers to be simpler
>>> and account on the fact that there could multiple host bridges
>>> exist for the hwdom
>>> Since v3:
>>> - fixed comment formatting
>>> Since v2:
>>> - removed unneeded assignment (count = 0)
>>> - removed unneeded header inclusion
>>> - update commit message
>>> Since v1:
>>> - Dynamically calculate the number of MMIO handlers required for vPCI
>>> and update the total number accordingly
>>> - s/clb/cb
>>> - Do not introduce a new callback for MMIO handler setup
>>> ---
>>> xen/arch/arm/domain.c | 2 +
>>> xen/arch/arm/pci/pci-host-common.c | 27
>>> xen/arch/arm/vpci.c | 66 ++
>>> xen/arch/arm/vpci.h | 6 +++
>>> xen/include/asm-arm/pci.h | 5 +++
>>> 5 files changed, 98 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
>>> index 96e1b235501d..92a6c509e5c5 100644
>>> --- a/xen/arch/arm/domain.c
>>> +++ b/xen/arch/arm/domain.c
>>> @@ -739,6 +739,8 @@ int arch_domain_create(struct domain *d,
>>> if ( (rc = domain_vgic_register(d, )) != 0 )
>>> goto fail;
>>> + count += domain_vpci_get_num_mmio_handlers(d);
>>> +
>>> if ( (rc = domain_io_init(d, count + MAX_IO_HANDLER)) != 0 )
>>> goto fail;
>>> diff --git a/xen/arch/arm/pci/pci-host-common.c
>>> b/xen/arch/arm/pci/pci-host-common.c
>>> index 47104b22b221..0d271a6e8881 100644
>>> --- a/xen/arch/arm/pci/pci-host-common.c
>>> +++ b/xen/arch/arm/pci/pci-host-common.c
>>> @@ -289,6 +289,33 @@ int pci_get_host_bridge_segment(const struct
>>> dt_device_node *node,
>>> return -EINVAL;
>>> }
>>> +int pci_host_iterate_bridges(struct domain *d,
>>> + int (*cb)(struct domain *d,
>>> + struct pci_host_bridge *bridge))
>>> +{
>>> + struct pci_host_bridge *bridge;
>>> + int err;
>>> +
>>> + list_for_each_entry( bridge, _host_bridges, node )
>>> + {
>>> + err = cb(d, bridge);
>>> + if ( err )
>>> + return err;
>>> + }
>>> + return 0;
>>> +}
>>> +
>>> +unsigned int pci_host_get_num_bridges(void)
>>> +{
>>> + struct pci_host_bridge *bridge;
>>> + unsigned int count = 0;
>> How about making this static and...
>>
>>> +
>>> + list_for_each_entry( bridge, _host_bridges, node )
>>> + count++;
>> ... only call list_for_each_entry() when count is -1? So we would only go
>> through the list once.
>>
>> This should be fine given hostbridge can only be added during boot (we would
>> need to protect pci_host_bridges with a lock otherwise).
> Ok, I can do that
I have re-worked the patch so that more code can be re-used:
if ( is_hardware_domain(d) )
{
int count;
count = pci_host_iterate_bridges_and_count(d,
vpci_setup_mmio_handler_cb);
if ( count < 0 )
return count;
return 0;
}
register_mmio_handler(d, _mmio_handler,
GUEST_VPCI_ECAM_BASE, GUEST_VPCI_ECAM_SIZE, NULL);
so pci_host_get_num_bridges goes away.
>>> +
>>> + return count;
>>> +}
>>> +
>>> /*
>>> * Local variables:
>>> * mode: C
>>> diff --git a/xen/arch/arm/vpci.c b/xen/arch/arm/vpci.c
>>> index 23f45386f4b3..5a6ebd8b9868 100644
>>> --- a/xen/arch/arm/vpci.c
>>> +++ b/xen/arch/arm/vpci.c
>>> @@ -16,16 +16,31 @@
>>> #include
>>> +static pci_sbdf_t vpci_sbdf_from_gpa(const struct pci_host_bridge
>>> *bridge,
>>> + paddr_t gpa)
>>> +{
>>> + pci_sbdf_t sbdf;
>>> +
>>> + if ( bridge )
>>> + {
>>> + sbdf.sbdf = VPCI_ECAM_BDF(gpa - bridge->cfg->phys_addr);
>>> +
Re: [PATCH v6 3/7] xen/arm: setup MMIO range trap handlers for hardware domain
Hi, Julien!
On 16.11.21 21:12, Julien Grall wrote:
> Hi Oleksandr,
>
> On 05/11/2021 06:33, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> In order for vPCI to work it needs to maintain guest and hardware
>> domain's views of the configuration space. For example, BARs and
>> COMMAND registers require emulation for guests and the guest view
>> of the registers needs to be in sync with the real contents of the
>> relevant registers. For that ECAM address space needs to also be
>> trapped for the hardware domain, so we need to implement PCI host
>> bridge specific callbacks to properly setup MMIO handlers for those
>> ranges depending on particular host bridge implementation.
>>
>> Signed-off-by: Oleksandr Andrushchenko
>> ---
>> Since v5:
>> - add vpci_sbdf_from_gpa helper for gpa to SBDF translation
>> - take bridge's bus start into account while calculating SBDF
>> Since v4:
>> - unsigned int for functions working with count
>> - gate number of MMIO handlers needed for CONFIG_HAS_PCI_MSI
>> and fix their number, e.g. single handler for PBA and
>> MSI-X tables (Roger)
>> - re-work code for assigning MMIO handlers to be simpler
>> and account on the fact that there could multiple host bridges
>> exist for the hwdom
>> Since v3:
>> - fixed comment formatting
>> Since v2:
>> - removed unneeded assignment (count = 0)
>> - removed unneeded header inclusion
>> - update commit message
>> Since v1:
>> - Dynamically calculate the number of MMIO handlers required for vPCI
>> and update the total number accordingly
>> - s/clb/cb
>> - Do not introduce a new callback for MMIO handler setup
>> ---
>> xen/arch/arm/domain.c | 2 +
>> xen/arch/arm/pci/pci-host-common.c | 27
>> xen/arch/arm/vpci.c | 66 ++
>> xen/arch/arm/vpci.h | 6 +++
>> xen/include/asm-arm/pci.h | 5 +++
>> 5 files changed, 98 insertions(+), 8 deletions(-)
>>
>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
>> index 96e1b235501d..92a6c509e5c5 100644
>> --- a/xen/arch/arm/domain.c
>> +++ b/xen/arch/arm/domain.c
>> @@ -739,6 +739,8 @@ int arch_domain_create(struct domain *d,
>> if ( (rc = domain_vgic_register(d, )) != 0 )
>> goto fail;
>> + count += domain_vpci_get_num_mmio_handlers(d);
>> +
>> if ( (rc = domain_io_init(d, count + MAX_IO_HANDLER)) != 0 )
>> goto fail;
>> diff --git a/xen/arch/arm/pci/pci-host-common.c
>> b/xen/arch/arm/pci/pci-host-common.c
>> index 47104b22b221..0d271a6e8881 100644
>> --- a/xen/arch/arm/pci/pci-host-common.c
>> +++ b/xen/arch/arm/pci/pci-host-common.c
>> @@ -289,6 +289,33 @@ int pci_get_host_bridge_segment(const struct
>> dt_device_node *node,
>> return -EINVAL;
>> }
>> +int pci_host_iterate_bridges(struct domain *d,
>> + int (*cb)(struct domain *d,
>> + struct pci_host_bridge *bridge))
>> +{
>> + struct pci_host_bridge *bridge;
>> + int err;
>> +
>> + list_for_each_entry( bridge, _host_bridges, node )
>> + {
>> + err = cb(d, bridge);
>> + if ( err )
>> + return err;
>> + }
>> + return 0;
>> +}
>> +
>> +unsigned int pci_host_get_num_bridges(void)
>> +{
>> + struct pci_host_bridge *bridge;
>> + unsigned int count = 0;
>
> How about making this static and...
>
>> +
>> + list_for_each_entry( bridge, _host_bridges, node )
>> + count++;
>
> ... only call list_for_each_entry() when count is -1? So we would only go
> through the list once.
>
> This should be fine given hostbridge can only be added during boot (we would
> need to protect pci_host_bridges with a lock otherwise).
Ok, I can do that
>
>> +
>> + return count;
>> +}
>> +
>> /*
>> * Local variables:
>> * mode: C
>> diff --git a/xen/arch/arm/vpci.c b/xen/arch/arm/vpci.c
>> index 23f45386f4b3..5a6ebd8b9868 100644
>> --- a/xen/arch/arm/vpci.c
>> +++ b/xen/arch/arm/vpci.c
>> @@ -16,16 +16,31 @@
>> #include
>> +static pci_sbdf_t vpci_sbdf_from_gpa(const struct pci_host_bridge *bridge,
>> + paddr_t gpa)
>> +{
>> + pci_sbdf_t sbdf;
>> +
>> + if ( bridge )
>> + {
>> + sbdf.sbdf = VPCI_ECAM_BDF(gpa - bridge->cfg->phys_addr);
>> + sbdf.seg = bridge->segment;
>> + sbdf.bus += bridge->cfg->busn_start;
>> + }
>> + else
>> + sbdf.sbdf = VPCI_ECAM_BDF(gpa - GUEST_VPCI_ECAM_BASE);
>> +
>> + return sbdf;
>> +}
>> +
>> static int vpci_mmio_read(struct vcpu *v, mmio_info_t *info,
>> register_t *r, void *p)
>> {
>> - pci_sbdf_t sbdf;
>> + struct pci_host_bridge *bridge = p;
>> + pci_sbdf_t sbdf = vpci_sbdf_from_gpa(bridge, info->gpa);
>> /* data is needed to prevent a pointer cast on 32bit */
>> unsigned long data;
>> - /* We ignore segment part and always handle segment 0 */
>> - sbdf.sbdf =
Re: [PATCH v6 3/7] xen/arm: setup MMIO range trap handlers for hardware domain
Hi Oleksandr,
On 05/11/2021 06:33, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
In order for vPCI to work it needs to maintain guest and hardware
domain's views of the configuration space. For example, BARs and
COMMAND registers require emulation for guests and the guest view
of the registers needs to be in sync with the real contents of the
relevant registers. For that ECAM address space needs to also be
trapped for the hardware domain, so we need to implement PCI host
bridge specific callbacks to properly setup MMIO handlers for those
ranges depending on particular host bridge implementation.
Signed-off-by: Oleksandr Andrushchenko
---
Since v5:
- add vpci_sbdf_from_gpa helper for gpa to SBDF translation
- take bridge's bus start into account while calculating SBDF
Since v4:
- unsigned int for functions working with count
- gate number of MMIO handlers needed for CONFIG_HAS_PCI_MSI
and fix their number, e.g. single handler for PBA and
MSI-X tables (Roger)
- re-work code for assigning MMIO handlers to be simpler
and account on the fact that there could multiple host bridges
exist for the hwdom
Since v3:
- fixed comment formatting
Since v2:
- removed unneeded assignment (count = 0)
- removed unneeded header inclusion
- update commit message
Since v1:
- Dynamically calculate the number of MMIO handlers required for vPCI
and update the total number accordingly
- s/clb/cb
- Do not introduce a new callback for MMIO handler setup
---
xen/arch/arm/domain.c | 2 +
xen/arch/arm/pci/pci-host-common.c | 27
xen/arch/arm/vpci.c| 66 ++
xen/arch/arm/vpci.h| 6 +++
xen/include/asm-arm/pci.h | 5 +++
5 files changed, 98 insertions(+), 8 deletions(-)
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 96e1b235501d..92a6c509e5c5 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -739,6 +739,8 @@ int arch_domain_create(struct domain *d,
if ( (rc = domain_vgic_register(d, )) != 0 )
goto fail;
+count += domain_vpci_get_num_mmio_handlers(d);
+
if ( (rc = domain_io_init(d, count + MAX_IO_HANDLER)) != 0 )
goto fail;
diff --git a/xen/arch/arm/pci/pci-host-common.c b/xen/arch/arm/pci/pci-host-common.c
index 47104b22b221..0d271a6e8881 100644
--- a/xen/arch/arm/pci/pci-host-common.c
+++ b/xen/arch/arm/pci/pci-host-common.c
@@ -289,6 +289,33 @@ int pci_get_host_bridge_segment(const struct
dt_device_node *node,
return -EINVAL;
}
+int pci_host_iterate_bridges(struct domain *d,
+ int (*cb)(struct domain *d,
+ struct pci_host_bridge *bridge))
+{
+struct pci_host_bridge *bridge;
+int err;
+
+list_for_each_entry( bridge, _host_bridges, node )
+{
+err = cb(d, bridge);
+if ( err )
+return err;
+}
+return 0;
+}
+
+unsigned int pci_host_get_num_bridges(void)
+{
+struct pci_host_bridge *bridge;
+unsigned int count = 0;
How about making this static and...
+
+list_for_each_entry( bridge, _host_bridges, node )
+count++;
... only call list_for_each_entry() when count is -1? So we would only
go through the list once.
This should be fine given hostbridge can only be added during boot (we
would need to protect pci_host_bridges with a lock otherwise).
+
+return count;
+}
+
/*
* Local variables:
* mode: C
diff --git a/xen/arch/arm/vpci.c b/xen/arch/arm/vpci.c
index 23f45386f4b3..5a6ebd8b9868 100644
--- a/xen/arch/arm/vpci.c
+++ b/xen/arch/arm/vpci.c
@@ -16,16 +16,31 @@
#include
+static pci_sbdf_t vpci_sbdf_from_gpa(const struct pci_host_bridge *bridge,
+ paddr_t gpa)
+{
+pci_sbdf_t sbdf;
+
+if ( bridge )
+{
+sbdf.sbdf = VPCI_ECAM_BDF(gpa - bridge->cfg->phys_addr);
+sbdf.seg = bridge->segment;
+sbdf.bus += bridge->cfg->busn_start;
+}
+else
+sbdf.sbdf = VPCI_ECAM_BDF(gpa - GUEST_VPCI_ECAM_BASE);
+
+return sbdf;
+}
+
static int vpci_mmio_read(struct vcpu *v, mmio_info_t *info,
register_t *r, void *p)
{
-pci_sbdf_t sbdf;
+struct pci_host_bridge *bridge = p;
+pci_sbdf_t sbdf = vpci_sbdf_from_gpa(bridge, info->gpa);
/* data is needed to prevent a pointer cast on 32bit */
unsigned long data;
-/* We ignore segment part and always handle segment 0 */
-sbdf.sbdf = VPCI_ECAM_BDF(info->gpa - GUEST_VPCI_ECAM_BASE);
-
if ( vpci_ecam_read(sbdf, ECAM_REG_OFFSET(info->gpa),
1U << info->dabt.size, ) )
{
@@ -41,10 +56,8 @@ static int vpci_mmio_read(struct vcpu *v, mmio_info_t *info,
static int vpci_mmio_write(struct vcpu *v, mmio_info_t *info,
register_t r, void *p)
{
-pci_sbdf_t sbdf;
-
-/* We ignore segment part and always handle
Re: [PATCH v6 3/7] xen/arm: setup MMIO range trap handlers for hardware domain
On 05.11.21 08:33, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> [snip]
> +int pci_host_iterate_bridges(struct domain *d,
> + int (*cb)(struct domain *d,
> + struct pci_host_bridge *bridge))
> +{
> +struct pci_host_bridge *bridge;
> +int err;
> +
> +list_for_each_entry( bridge, _host_bridges, node )
> +{
> +err = cb(d, bridge);
> +if ( err )
> +return err;
> +}
> +return 0;
> +}
> +
> +unsigned int pci_host_get_num_bridges(void)
> +{
> +struct pci_host_bridge *bridge;
> +unsigned int count = 0;
> +
> +list_for_each_entry( bridge, _host_bridges, node )
> +count++;
> +
> +return count;
> +}
> +
>
This can be even simpler if pci_host_iterate_bridges returns the count:
-int pci_host_iterate_bridges(struct domain *d,
- int (*cb)(struct domain *d,
- struct pci_host_bridge *bridge))
+int pci_host_iterate_bridges_and_count(struct domain *d,
+ int (*cb)(struct domain *d,
+ struct pci_host_bridge
*bridge))
{
struct pci_host_bridge *bridge;
- int err;
+ int err, count = 0;
list_for_each_entry( bridge, _host_bridges, node )
{
err = cb(d, bridge);
if ( err )
return err;
+ count += err;
}
- return 0;
-}
Then pci_host_get_num_bridges goes away and we can count
different entities with the same iterator and a simple callback.
This becomes possible as there is a single user for pci_host_iterate_bridges
now which sets up MMIOs, so the change above seems to be reasonable
I will include this change in v7
Thank you,
Oleksandr
[PATCH v6 3/7] xen/arm: setup MMIO range trap handlers for hardware domain
From: Oleksandr Andrushchenko
In order for vPCI to work it needs to maintain guest and hardware
domain's views of the configuration space. For example, BARs and
COMMAND registers require emulation for guests and the guest view
of the registers needs to be in sync with the real contents of the
relevant registers. For that ECAM address space needs to also be
trapped for the hardware domain, so we need to implement PCI host
bridge specific callbacks to properly setup MMIO handlers for those
ranges depending on particular host bridge implementation.
Signed-off-by: Oleksandr Andrushchenko
---
Since v5:
- add vpci_sbdf_from_gpa helper for gpa to SBDF translation
- take bridge's bus start into account while calculating SBDF
Since v4:
- unsigned int for functions working with count
- gate number of MMIO handlers needed for CONFIG_HAS_PCI_MSI
and fix their number, e.g. single handler for PBA and
MSI-X tables (Roger)
- re-work code for assigning MMIO handlers to be simpler
and account on the fact that there could multiple host bridges
exist for the hwdom
Since v3:
- fixed comment formatting
Since v2:
- removed unneeded assignment (count = 0)
- removed unneeded header inclusion
- update commit message
Since v1:
- Dynamically calculate the number of MMIO handlers required for vPCI
and update the total number accordingly
- s/clb/cb
- Do not introduce a new callback for MMIO handler setup
---
xen/arch/arm/domain.c | 2 +
xen/arch/arm/pci/pci-host-common.c | 27
xen/arch/arm/vpci.c| 66 ++
xen/arch/arm/vpci.h| 6 +++
xen/include/asm-arm/pci.h | 5 +++
5 files changed, 98 insertions(+), 8 deletions(-)
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 96e1b235501d..92a6c509e5c5 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -739,6 +739,8 @@ int arch_domain_create(struct domain *d,
if ( (rc = domain_vgic_register(d, )) != 0 )
goto fail;
+count += domain_vpci_get_num_mmio_handlers(d);
+
if ( (rc = domain_io_init(d, count + MAX_IO_HANDLER)) != 0 )
goto fail;
diff --git a/xen/arch/arm/pci/pci-host-common.c
b/xen/arch/arm/pci/pci-host-common.c
index 47104b22b221..0d271a6e8881 100644
--- a/xen/arch/arm/pci/pci-host-common.c
+++ b/xen/arch/arm/pci/pci-host-common.c
@@ -289,6 +289,33 @@ int pci_get_host_bridge_segment(const struct
dt_device_node *node,
return -EINVAL;
}
+int pci_host_iterate_bridges(struct domain *d,
+ int (*cb)(struct domain *d,
+ struct pci_host_bridge *bridge))
+{
+struct pci_host_bridge *bridge;
+int err;
+
+list_for_each_entry( bridge, _host_bridges, node )
+{
+err = cb(d, bridge);
+if ( err )
+return err;
+}
+return 0;
+}
+
+unsigned int pci_host_get_num_bridges(void)
+{
+struct pci_host_bridge *bridge;
+unsigned int count = 0;
+
+list_for_each_entry( bridge, _host_bridges, node )
+count++;
+
+return count;
+}
+
/*
* Local variables:
* mode: C
diff --git a/xen/arch/arm/vpci.c b/xen/arch/arm/vpci.c
index 23f45386f4b3..5a6ebd8b9868 100644
--- a/xen/arch/arm/vpci.c
+++ b/xen/arch/arm/vpci.c
@@ -16,16 +16,31 @@
#include
+static pci_sbdf_t vpci_sbdf_from_gpa(const struct pci_host_bridge *bridge,
+ paddr_t gpa)
+{
+pci_sbdf_t sbdf;
+
+if ( bridge )
+{
+sbdf.sbdf = VPCI_ECAM_BDF(gpa - bridge->cfg->phys_addr);
+sbdf.seg = bridge->segment;
+sbdf.bus += bridge->cfg->busn_start;
+}
+else
+sbdf.sbdf = VPCI_ECAM_BDF(gpa - GUEST_VPCI_ECAM_BASE);
+
+return sbdf;
+}
+
static int vpci_mmio_read(struct vcpu *v, mmio_info_t *info,
register_t *r, void *p)
{
-pci_sbdf_t sbdf;
+struct pci_host_bridge *bridge = p;
+pci_sbdf_t sbdf = vpci_sbdf_from_gpa(bridge, info->gpa);
/* data is needed to prevent a pointer cast on 32bit */
unsigned long data;
-/* We ignore segment part and always handle segment 0 */
-sbdf.sbdf = VPCI_ECAM_BDF(info->gpa - GUEST_VPCI_ECAM_BASE);
-
if ( vpci_ecam_read(sbdf, ECAM_REG_OFFSET(info->gpa),
1U << info->dabt.size, ) )
{
@@ -41,10 +56,8 @@ static int vpci_mmio_read(struct vcpu *v, mmio_info_t *info,
static int vpci_mmio_write(struct vcpu *v, mmio_info_t *info,
register_t r, void *p)
{
-pci_sbdf_t sbdf;
-
-/* We ignore segment part and always handle segment 0 */
-sbdf.sbdf = VPCI_ECAM_BDF(info->gpa - GUEST_VPCI_ECAM_BASE);
+struct pci_host_bridge *bridge = p;
+pci_sbdf_t sbdf = vpci_sbdf_from_gpa(bridge, info->gpa);
return vpci_ecam_write(sbdf, ECAM_REG_OFFSET(info->gpa),
1U << info->dabt.size, r);
@@ -55,17 +68,54 @@ static const struct mmio_handler_ops vpci_mmio_handler = {
.write =
