Re: [virtio-comment] Re: [PATCH 09/11] transport-pci: Describe PCI MMR dev config registers

[Jason Wang <jasowang@redhat.com>]

On Wed, Apr 12, 2023 at 1:30âPM Parav Pandit <parav@nvidia.com> wrote:
>
>
>
> > From: Jason Wang <jasowang@redhat.com>
> > Sent: Wednesday, April 12, 2023 1:15 AM
>
> > > Because the spec for modern device do not allow it. Discussed in these
> > threads.
> >
> > Can you please tell me which part of the spec disallows it? There's a long
> > discussion in the virtualization-list a few months ago about mediating legacy
> > devices on top of modern. We don't see any blocker do you?
> >
> Modern device says FEAETURE_1 must be offered and must be negotiated by driver.
> Legacy has Mac as RW area. (hypervisor can do it).
> Reset flow is difference between the legacy and modern.

Just to make sure we're at the same page. We're talking in the context
of mediation. Without mediation, your proposal can't work.

So in this case, the guest driver is not talking with the device
directly. Qemu needs to traps whatever it wants to achieve the
mediation:

1) It's perfectly fine that Qemu negotiated VERSION_1 but presented a
mediated legacy device to guests.
2) For MAC and Reset, Qemu can trap and do anything it wants.

>
> > >
> > > > 1) legacy MMIO bar: spec changes, hypervisor mediation
> > > > 2) modern device: no spec changes, hypervisor mediation
> > > >
> > > This question repeats the same discussion occurred in this patch series.
> > > You might want to refer it again to avoid repeating all over again.
> >
> > No, I think you miss the point that modern devices could be used for mediating
> > legacy devices.
> >
> > >
> > > > 1) it's better not invent any of new facilities for legacy
> > > > 2) if legacy is insisted, allow MMIO BAR0 is much simpler and better
> > > You have missed few emails. :)
> > > MMIO BAR is proposed here and it is not limited to BAR 0.
> >
> > In the context of mediation, why do you need that flexibility?
> >
> The PCI device exposed is transitional to the guest VM, so it can do legacy as well as newer features.
> And if BAR 0 is hard coded, it may not be able to support features that may need additional BAR.

This part I don't understand, you can just put existing modern
capabilities in BAR0, then everything is fine.

>
> > > It is left for the device to either map something in existing BAR or use BAR 0.
> > > Because PCI has only 3 BARs.
> > > A device may want to support legacy and non-legacy functionality both at the
> > same time.
> >
> > This is perfectly fine, this is how Qemu did:
> >
> >     /*
> >      * virtio pci bar layout used by default.
> >      * subclasses can re-arrange things if needed.
> >      *
> >      *   region 0   --  virtio legacy io bar
> >      *   region 1   --  msi-x bar
> >      *   region 2   --  virtio modern io bar (off by default)
> >      *   region 4+5 --  virtio modern memory (64bit) bar
> >      *
> >      */
> >
> > > So better not to hard wire for BAR 0.
> >
> > Using BAR0 doesn't prevent you from adding modern capabilities in BAR0, no?
> >
> Right, it doesnât. But spec shouldnât write BAR0 is only for legacy MMIO emulation, that would prevent BAR0 usage.

How can it be prevented? Can you give me an example?

Thanks