[virtio-comment] 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


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/