* [Qemu-devel] [PATCH] pci/pcie: don't assume cap id 0 is reserved
@ 2017-02-15 20:49 Michael S. Tsirkin
2017-02-15 21:33 ` Alex Williamson
2017-02-16 2:35 ` Peter Xu
0 siblings, 2 replies; 6+ messages in thread
From: Michael S. Tsirkin @ 2017-02-15 20:49 UTC (permalink / raw)
To: qemu-devel; +Cc: Alex Williamson, Peter Xu, Marcel Apfelbaum
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
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [Qemu-devel] [PATCH] pci/pcie: don't assume cap id 0 is reserved
2017-02-15 20:49 [Qemu-devel] [PATCH] pci/pcie: don't assume cap id 0 is reserved Michael S. Tsirkin
@ 2017-02-15 21:33 ` Alex Williamson
2017-02-16 2:35 ` Peter Xu
1 sibling, 0 replies; 6+ messages in thread
From: Alex Williamson @ 2017-02-15 21:33 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: qemu-devel, Peter Xu, Marcel Apfelbaum
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);
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Qemu-devel] [PATCH] pci/pcie: don't assume cap id 0 is reserved
2017-02-15 20:49 [Qemu-devel] [PATCH] pci/pcie: don't assume cap id 0 is reserved Michael S. Tsirkin
2017-02-15 21:33 ` Alex Williamson
@ 2017-02-16 2:35 ` Peter Xu
2017-02-16 2:52 ` Alex Williamson
1 sibling, 1 reply; 6+ messages in thread
From: Peter Xu @ 2017-02-16 2:35 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: qemu-devel, Alex Williamson, Marcel Apfelbaum
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Qemu-devel] [PATCH] pci/pcie: don't assume cap id 0 is reserved
2017-02-16 2:35 ` Peter Xu
@ 2017-02-16 2:52 ` Alex Williamson
2017-02-16 3:04 ` Peter Xu
0 siblings, 1 reply; 6+ messages in thread
From: Alex Williamson @ 2017-02-16 2:52 UTC (permalink / raw)
To: Peter Xu; +Cc: Michael S. Tsirkin, qemu-devel, Marcel Apfelbaum
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Qemu-devel] [PATCH] pci/pcie: don't assume cap id 0 is reserved
2017-02-16 2:52 ` Alex Williamson
@ 2017-02-16 3:04 ` Peter Xu
2017-02-16 3:49 ` Peter Xu
0 siblings, 1 reply; 6+ messages in thread
From: Peter Xu @ 2017-02-16 3:04 UTC (permalink / raw)
To: Alex Williamson; +Cc: Michael S. Tsirkin, qemu-devel, Marcel Apfelbaum
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Qemu-devel] [PATCH] pci/pcie: don't assume cap id 0 is reserved
2017-02-16 3:04 ` Peter Xu
@ 2017-02-16 3:49 ` Peter Xu
0 siblings, 0 replies; 6+ messages in thread
From: Peter Xu @ 2017-02-16 3:49 UTC (permalink / raw)
To: Alex Williamson; +Cc: Michael S. Tsirkin, qemu-devel, Marcel Apfelbaum
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-02-16 3:50 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-02-15 20:49 [Qemu-devel] [PATCH] pci/pcie: don't assume cap id 0 is reserved Michael S. Tsirkin
2017-02-15 21:33 ` Alex Williamson
2017-02-16 2:35 ` Peter Xu
2017-02-16 2:52 ` Alex Williamson
2017-02-16 3:04 ` Peter Xu
2017-02-16 3:49 ` Peter Xu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).