Re: [Qemu-devel] [PATCH] pci/pcie: don't assume cap id 0 is reserved

[Peter Xu <peterx@redhat.com>]

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