VFIO actually wants to create a capability with ID == 0.
This is done to make guest drivers skip the given capability.
pcie_add_capability then trips up on this capability
when looking for end of capability list.
To support this use-case, it's easy enough to switch to
e.g. 0xffffffff for these comparisons - we can be sure
it will never match a 16-bit capability ID.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
hw/pci/pcie.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index cbd4bb4..f4dd177 100644
--- a/hw/pci/pcie.c
+++ b/hw/pci/pcie.c
@@ -610,7 +610,8 @@ bool pcie_cap_is_arifwd_enabled(const PCIDevice *dev)
* uint16_t ext_cap_size
*/
-static uint16_t pcie_find_capability_list(PCIDevice *dev, uint16_t cap_id,
+/* Passing a cap_id value > 0xffff will return 0 and put end of list in prev */
+static uint16_t pcie_find_capability_list(PCIDevice *dev, uint32_t cap_id,
uint16_t *prev_p)
{
uint16_t prev = 0;
@@ -679,9 +680,11 @@ void pcie_add_capability(PCIDevice *dev,
} else {
uint16_t prev;
- /* 0 is reserved cap id. use internally to find the last capability
- in the linked list */
- next = pcie_find_capability_list(dev, 0, &prev);
+ /*
+ * 0xffffffff is not a valid cap id (it's a 16 bit field). use
+ * internally to find the last capability in the linked list.
+ */
+ next = pcie_find_capability_list(dev, 0xffffffff, &prev);
assert(prev >= PCI_CONFIG_SPACE_SIZE);
assert(next == 0);
--
MST
On Wed, 15 Feb 2017 22:49:47 +0200 "Michael S. Tsirkin" <mst@redhat.com> wrote: > VFIO actually wants to create a capability with ID == 0. > This is done to make guest drivers skip the given capability. > pcie_add_capability then trips up on this capability > when looking for end of capability list. > > To support this use-case, it's easy enough to switch to > e.g. 0xffffffff for these comparisons - we can be sure > it will never match a 16-bit capability ID. > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > --- Reviewed-by: Alex Williamson <alex.williamson@redhat.com> > hw/pci/pcie.c | 11 +++++++---- > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c > index cbd4bb4..f4dd177 100644 > --- a/hw/pci/pcie.c > +++ b/hw/pci/pcie.c > @@ -610,7 +610,8 @@ bool pcie_cap_is_arifwd_enabled(const PCIDevice *dev) > * uint16_t ext_cap_size > */ > > -static uint16_t pcie_find_capability_list(PCIDevice *dev, uint16_t cap_id, > +/* Passing a cap_id value > 0xffff will return 0 and put end of list in prev */ > +static uint16_t pcie_find_capability_list(PCIDevice *dev, uint32_t cap_id, > uint16_t *prev_p) > { > uint16_t prev = 0; > @@ -679,9 +680,11 @@ void pcie_add_capability(PCIDevice *dev, > } else { > uint16_t prev; > > - /* 0 is reserved cap id. use internally to find the last capability > - in the linked list */ > - next = pcie_find_capability_list(dev, 0, &prev); > + /* > + * 0xffffffff is not a valid cap id (it's a 16 bit field). use > + * internally to find the last capability in the linked list. > + */ > + next = pcie_find_capability_list(dev, 0xffffffff, &prev); > > assert(prev >= PCI_CONFIG_SPACE_SIZE); > assert(next == 0);
On Wed, Feb 15, 2017 at 10:49:47PM +0200, Michael S. Tsirkin wrote: > VFIO actually wants to create a capability with ID == 0. > This is done to make guest drivers skip the given capability. > pcie_add_capability then trips up on this capability > when looking for end of capability list. > > To support this use-case, it's easy enough to switch to > e.g. 0xffffffff for these comparisons - we can be sure > it will never match a 16-bit capability ID. > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Two nits: (1) maybe we can s/0xffffffff/0xffff/ in the whole patch since ecap_id is 16 bits (2) maybe we can add one more sentence in the comment below showing where the 0xffff thing comes from (it comes from PCIe spec 7.9.2) Thanks, > --- > hw/pci/pcie.c | 11 +++++++---- > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c > index cbd4bb4..f4dd177 100644 > --- a/hw/pci/pcie.c > +++ b/hw/pci/pcie.c > @@ -610,7 +610,8 @@ bool pcie_cap_is_arifwd_enabled(const PCIDevice *dev) > * uint16_t ext_cap_size > */ > > -static uint16_t pcie_find_capability_list(PCIDevice *dev, uint16_t cap_id, > +/* Passing a cap_id value > 0xffff will return 0 and put end of list in prev */ > +static uint16_t pcie_find_capability_list(PCIDevice *dev, uint32_t cap_id, > uint16_t *prev_p) > { > uint16_t prev = 0; > @@ -679,9 +680,11 @@ void pcie_add_capability(PCIDevice *dev, > } else { > uint16_t prev; > > - /* 0 is reserved cap id. use internally to find the last capability > - in the linked list */ > - next = pcie_find_capability_list(dev, 0, &prev); > + /* > + * 0xffffffff is not a valid cap id (it's a 16 bit field). use > + * internally to find the last capability in the linked list. > + */ > + next = pcie_find_capability_list(dev, 0xffffffff, &prev); > > assert(prev >= PCI_CONFIG_SPACE_SIZE); > assert(next == 0); > -- > MST -- peterx
On Thu, 16 Feb 2017 10:35:28 +0800 Peter Xu <peterx@redhat.com> wrote: > On Wed, Feb 15, 2017 at 10:49:47PM +0200, Michael S. Tsirkin wrote: > > VFIO actually wants to create a capability with ID == 0. > > This is done to make guest drivers skip the given capability. > > pcie_add_capability then trips up on this capability > > when looking for end of capability list. > > > > To support this use-case, it's easy enough to switch to > > e.g. 0xffffffff for these comparisons - we can be sure > > it will never match a 16-bit capability ID. > > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > > Reviewed-by: Peter Xu <peterx@redhat.com> > > Two nits: > > (1) maybe we can s/0xffffffff/0xffff/ in the whole patch since ecap_id > is 16 bits The former is used because it's beyond the address space of a valid capability. Using 0xffff just makes the situation different, not better. > > (2) maybe we can add one more sentence in the comment below showing > where the 0xffff thing comes from (it comes from PCIe spec 7.9.2) The capability in hardware is 16bits, thus a value that exceeds 16 bits can never match a valid ID. It has nothing to do with 7.9.2. Thanks, Alex > > --- > > hw/pci/pcie.c | 11 +++++++---- > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c > > index cbd4bb4..f4dd177 100644 > > --- a/hw/pci/pcie.c > > +++ b/hw/pci/pcie.c > > @@ -610,7 +610,8 @@ bool pcie_cap_is_arifwd_enabled(const PCIDevice *dev) > > * uint16_t ext_cap_size > > */ > > > > -static uint16_t pcie_find_capability_list(PCIDevice *dev, uint16_t cap_id, > > +/* Passing a cap_id value > 0xffff will return 0 and put end of list in prev */ > > +static uint16_t pcie_find_capability_list(PCIDevice *dev, uint32_t cap_id, > > uint16_t *prev_p) > > { > > uint16_t prev = 0; > > @@ -679,9 +680,11 @@ void pcie_add_capability(PCIDevice *dev, > > } else { > > uint16_t prev; > > > > - /* 0 is reserved cap id. use internally to find the last capability > > - in the linked list */ > > - next = pcie_find_capability_list(dev, 0, &prev); > > + /* > > + * 0xffffffff is not a valid cap id (it's a 16 bit field). use > > + * internally to find the last capability in the linked list. > > + */ > > + next = pcie_find_capability_list(dev, 0xffffffff, &prev); > > > > assert(prev >= PCI_CONFIG_SPACE_SIZE); > > assert(next == 0); > > -- > > MST > > -- peterx
On Wed, Feb 15, 2017 at 07:52:35PM -0700, Alex Williamson wrote: > On Thu, 16 Feb 2017 10:35:28 +0800 > Peter Xu <peterx@redhat.com> wrote: > > > On Wed, Feb 15, 2017 at 10:49:47PM +0200, Michael S. Tsirkin wrote: > > > VFIO actually wants to create a capability with ID == 0. > > > This is done to make guest drivers skip the given capability. > > > pcie_add_capability then trips up on this capability > > > when looking for end of capability list. > > > > > > To support this use-case, it's easy enough to switch to > > > e.g. 0xffffffff for these comparisons - we can be sure > > > it will never match a 16-bit capability ID. > > > > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > > > > Reviewed-by: Peter Xu <peterx@redhat.com> > > > > Two nits: > > > > (1) maybe we can s/0xffffffff/0xffff/ in the whole patch since ecap_id > > is 16 bits > > The former is used because it's beyond the address space of a valid > capability. Using 0xffff just makes the situation different, not > better. But isn't pcie_find_capability_list() defining cap_id parameter as uint16_t? In that case, 0xffffffff will be the same as 0xffff since we'll just take the lower 16 bits? > > > > > (2) maybe we can add one more sentence in the comment below showing > > where the 0xffff thing comes from (it comes from PCIe spec 7.9.2) > > The capability in hardware is 16bits, thus a value that exceeds 16 bits > can never match a valid ID. It has nothing to do with 7.9.2. Thanks, > > Alex > > > > --- > > > hw/pci/pcie.c | 11 +++++++---- > > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > > > diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c > > > index cbd4bb4..f4dd177 100644 > > > --- a/hw/pci/pcie.c > > > +++ b/hw/pci/pcie.c > > > @@ -610,7 +610,8 @@ bool pcie_cap_is_arifwd_enabled(const PCIDevice *dev) > > > * uint16_t ext_cap_size > > > */ > > > > > > -static uint16_t pcie_find_capability_list(PCIDevice *dev, uint16_t cap_id, > > > +/* Passing a cap_id value > 0xffff will return 0 and put end of list in prev */ > > > +static uint16_t pcie_find_capability_list(PCIDevice *dev, uint32_t cap_id, > > > uint16_t *prev_p) > > > { > > > uint16_t prev = 0; > > > @@ -679,9 +680,11 @@ void pcie_add_capability(PCIDevice *dev, > > > } else { > > > uint16_t prev; > > > > > > - /* 0 is reserved cap id. use internally to find the last capability > > > - in the linked list */ > > > - next = pcie_find_capability_list(dev, 0, &prev); > > > + /* > > > + * 0xffffffff is not a valid cap id (it's a 16 bit field). use > > > + * internally to find the last capability in the linked list. > > > + */ > > > + next = pcie_find_capability_list(dev, 0xffffffff, &prev); > > > > > > assert(prev >= PCI_CONFIG_SPACE_SIZE); > > > assert(next == 0); > > > -- > > > MST > > > > -- peterx > -- peterx
On Thu, Feb 16, 2017 at 11:04:46AM +0800, Peter Xu wrote: > On Wed, Feb 15, 2017 at 07:52:35PM -0700, Alex Williamson wrote: > > On Thu, 16 Feb 2017 10:35:28 +0800 > > Peter Xu <peterx@redhat.com> wrote: > > > > > On Wed, Feb 15, 2017 at 10:49:47PM +0200, Michael S. Tsirkin wrote: > > > > VFIO actually wants to create a capability with ID == 0. > > > > This is done to make guest drivers skip the given capability. > > > > pcie_add_capability then trips up on this capability > > > > when looking for end of capability list. > > > > > > > > To support this use-case, it's easy enough to switch to > > > > e.g. 0xffffffff for these comparisons - we can be sure > > > > it will never match a 16-bit capability ID. > > > > > > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > > > > > > Reviewed-by: Peter Xu <peterx@redhat.com> > > > > > > Two nits: > > > > > > (1) maybe we can s/0xffffffff/0xffff/ in the whole patch since ecap_id > > > is 16 bits > > > > The former is used because it's beyond the address space of a valid > > capability. Using 0xffff just makes the situation different, not > > better. > > But isn't pcie_find_capability_list() defining cap_id parameter as > uint16_t? In that case, 0xffffffff will be the same as 0xffff since > we'll just take the lower 16 bits? Alex helpped pointing out that this patch has touched the parameter while I didn't notice that. Sorry. :( Please take my r-b and ignore the two nits. Thanks, -- peterx
© 2016 - 2024 Red Hat, Inc.