OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-dev] [PATCH 08/11] transport-pci: Introduce virtio extended capability


On Mon, Apr 10, 2023 at 09:36:17AM +0800, Jason Wang wrote:
> On Fri, Mar 31, 2023 at 7:00âAM Parav Pandit <parav@nvidia.com> wrote:
> >
> > PCI device configuration space for capabilities is limited to only 192
> > bytes shared by many PCI capabilities of generic PCI device and virtio
> > specific.
> >
> > Hence, introduce virtio extended capability that uses PCI Express
> > extended capability.
> > Subsequent patch uses this virtio extended capability.
> >
> > Co-developed-by: Satananda Burla <sburla@marvell.com>
> > Signed-off-by: Parav Pandit <parav@nvidia.com>
> 
> Can you explain the differences compared to what I've used to propose?
> 
> https://www.mail-archive.com/virtio-dev@lists.oasis-open.org/msg08078.html
> 
> This can save time for everybody.
> 
> Thanks

BTW another advantage of extended capabilities is - these are actually
cheaper to access from a VM than classic config space.


Several points
- I don't like it that yours is 32 bit. We do not need 2 variants just
  make it all 64 bit
- We need to document that if driver does not scan extended capbilities it will not find them.
  And existing drivers do not scan them. So what is safe
  to put there? vendor specific? extra access types?
  Can we make scanning these mandatory in future drivers? future devices?
  I guess we can add a feature bit to flag that.
  Is accessing these possible from bios?

So I like this one better as a basis - care reviewing it and adding
stuff?

-- 
MST



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]