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



> From: Jason Wang <jasowang@redhat.com>
> Sent: Wednesday, April 12, 2023 12:05 AM

> > > It is kind of intended since it is only used for new PCI-E features:
> > >
> > New fields in new extended pci cap area is fine.
> > Migrating old fields to be present in the new extended pci cap, is not your
> intention. Right?
> 
> Right, but what I want to say is, such migration may cause unnecessary
> problems. And I don't see why it is a must for your legacy MMIO bar proposal.
>
As I explained in the commit log, there is very small space left in the PCI capabilities.
Last time I counted, our VF doesnât even have space in the PCI cap 192 bytes anymore.

So starting with the extended PCI cap for legacy MMIO bar window.

> > Only currently defined caps to be placed in two places.
> 
> What's the advantage of doing this?
>
I think Michael found one advantage of being 2x faster?
 
> New drivers should provide backward compatibility so they must scan the pci
> cap.
Yes.
> The Old driver can only scan the pci cap.
> 
Yes.
> > New fields donât need to be placed in PCI cap, because no driver is looking
> there.
> 
> It would be much more simple if we forbid placing new fields in the PCI cap, it is
> already out of space.
> 
Yes. We both are saying same point. :)



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