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-comment] Re: [PATCH 09/11] transport-pci: Describe PCI MMR dev config registers


On Fri, Apr 14, 2023 at 02:43:21AM +0000, Parav Pandit wrote:
> 
> > From: Jason Wang <jasowang@redhat.com>
> > Sent: Thursday, April 13, 2023 10:37 PM
> 
> > I'm not sure I get this. With VIRTIO_NET_F_LEGACY_HEADER, we don't need
> > mediation for datapath. For the control path, mediation is a must for legacy and
> > it's very easy to keep it work for modern, what's wrong with that?
> 
> There is virtio PCI VF.
> The user who attaches this VF to the VM, it doesnât know if its guest is to run legacy driver or 1.x
> Hence hypervisor doesnât want to run special stack when guest may (likely) be 1.x and device also supports 1.x.
> 
> Therefore, MMIO BAR 0 emulation is better solution in this use case without any mediation.
> The current specification claim that transitional device "works", hence it is fine to extend BAR0 to be of MMIO type instead of IO type.
> 
> In some other cases control path or additional other mediation can be done.

Do you refer to the trick Jason proposed where BAR0 is memory but
otherwise matches legacy BAR0 exactly? Is this your preferred
solution at this point then?

-- 
MST



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