Re: [virtio-dev] Re: [PATCH v3 0/3] transport-pci: Introduce legacy registers access using AQ

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jun 07, 2023 at 02:54:22PM +0800, Jason Wang wrote:
> On Wed, Jun 7, 2023 at 11:06 AM Parav Pandit <parav@nvidia.com> wrote:
> >
> >
> >
> > > From: Jason Wang <jasowang@redhat.com>
> > > Sent: Tuesday, June 6, 2023 10:27 PM
> > >
> > > I can't say I like this. I prefer to do meditation on top of a modern device with
> > > some lightweight features like _F_LEAGCY_HEADER. I don't see any advantages
> > > of a new legacy ABI over _F_LEGACY_HEADER. I don't want to repeat but I don't
> > > get any response here
> > >
> > It is net only and not generic. Not a big blocker.
> > It doesnt stop at _F_LEAGCY_HEADER.
> >
> > > Anything that prevents you from adding things like VIRTIO_NET_F_LEGACY_HEADER?
> > It requires hypervisor to mediate 1.x config region and intercept feature negotiation including q config and more.
> 
> For config region, do you mean device configuration space or common
> config space?
> 
> I don't see why we need to do mediation on neiter of the above.
> Hypervisor just need to prepare
> 
> 1) legacy BAR with legacy config and device configuration space and
> 2) modern BAR with modern capabilities (common cfg and device cfg)
> 
> For 2) it could be mapped directly to the modern capabilities. For 1)
> hypervisor needs to mediate
> 
> >
> > Additionally, 1.x device says the mac address is read only, while legacy is RW.
> > And that requires yet another feature bit negotiation.
> 
> Hypervisor can trap the legacy device configuration space write and
> convert it to cvq commands.
> 
> Thanks

Hypervisor really can't access cvq if guest is doing it too -
that requires emulating cvq in software. And *that* is going
to be broken for workloads such as confidential computing.

> >
> > The main design goal is to not mediate 1.x specific region and not modify 1.x region definitions.
> > Which is why we step forward with the AQ.
> >
> > > https://lore.kernel.org/virtio-
> > > dev/CACGkMEuixsBibSq_pEQvcKOH0WBQWnta4Q2c28SV8qTS8gaVcA@mail.g
> > > mail.com/#t


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org