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: [PATCH v2 0/2] transport-pci: Introduce legacy registers access using AQ


On Wed, May 10, 2023 at 2:05âPM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Mon, May 08, 2023 at 10:23:39AM +0800, Jason Wang wrote:
> > > I thought so too originally. Unfortunately I now think that no, legacy is not
> > > going to be a byproduct of transport virtqueue for modern -
> > > it is different enough that it needs dedicated commands.
> >
> > If you mean the transport virtqueue, I think some dedicated commands
> > for legacy are needed. Then it would be a transport that supports
> > transitional devices. It would be much better than having commands for
> > a partial transport like this patch did.
>
> OK I am beginning to get what you are saying.  So your criticism is
> this: what if device supports vq transport for modern, and we want to
> build a transitional device on top.  how will that look. yes?

Yes. I think it needs to be done through the transport virtqueue
otherwise the transport is not self-contained.

> A reasonable thing to include at least in the commit log. Parav?
>
> You are also asking what if the device uses transport vq,
> and we want transitional on top of that.
> It's a fair question but I don't exactly get why would
> this legacy support feature be wanted for the vq transport
> and not for other transports.

Not sure I get the question, but all the existing transport support
legacy, if we want to have another, should the legacy support be a
must or not?

>
>
>
>
> > > Consider simplest case, multibyte fields. Legacy needs multibyte write,
> > > modern does not even need multibyte read.
> >
> > I'm not sure I will get here,
>
> What does this mean?

I meant I don't get what the issue if "modern does not even need
multibyte read".

>
> > since we can't expose admin vq to
> > guests, it means we need some software mediation. So if we just
> > implement what PCI allows us, then everything would be fine (even if
> > some method is not used).
> >
> > Thanks
>
> To repeat discussion on one of the previous versions, no it will not be
> fine because legacy virtio abuses pci in fundamentally broken ways.
> So yes you need a mediator on the host but even giving this
> mediator a chance to be robust on top of hardware
> means the hardware interface can not simply mirror legacy
> to hardware.
>
> For example, host mediator needs to trap writes into mac,
> buffer them and then send a 6 byte write.
> Now, pci actually does allow 6 byte writes, but legacy
> guests instead to 6 single byte writes for portability reasons.

It's a known race condition, so PCI over adminq doesn't make it worse.
The mediator can just mirror what guests write over the admin
commands.

Thanks

> --
> MSr
>



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