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-dev] Re: [PATCH v3 0/3] transport-pci: Introduce legacy registers access using AQ


On Mon, Jun 26, 2023 at 11:59:42AM +0800, Jason Wang wrote:
> > - when some weird legacy
> >   support requirement surfaces, it will be up to the vendor
> >   to fix. HW vendors are also more agressive in deprecating
> >   old hardware - they will just stop shipping new
> >   hardware when there are no new customers and we can
> >   stop adding new hacks.
> 
> But the hacks would be there forever if there's users.

If they are in hardware, they won't - only as long as
hardware exists.

> >
> > - test out admin command interface. This use-case is smaller
> >   than full transport vq but similar enough that
> >   we will learn valuable lessons from it.
> 
> Another issue is that the interface is designed to be PCI specific (at
> least from its name) which may result in a strange mediation for MMIO
> legacy guests.


I doubt there's a way to make guests utilizing legacy MMIO work with
offloads - it's not widely used on x86 and other platforms have weaker
ordering.

> >   For example, it already helped us find and correct
> >   a design mistake where admin commands had 8 byte aligned length.
> >   As another example, I am working on ability to report events to admin command
> >   infrastructure which is currently missing.
> 
> If we want a MMIO interface for admin commands, it requires more
> extensions for such kind of notification.

Yes I don't know how that will work. Not sure what the
implication is though.


> >   With that in place we will be able to add INT#x emulation for very old
> >   guests.
> >
> >
> >
> > In short, this interface as you correctly point out is not the normal
> > way we build interfaces since it is not modular and less flexible than
> > individual feature bits.  However, for the legacy interface this might
> > be a good thing.
> 
> Ok, I think I would not object to this proposal, but we should not
> exclude the possibility of having things like LEGACY_HEADER in the
> future.
> 
> Thanks

Yes I always disliked that change. Feel free to propose it, I'll
support.

> >
> >
> > > > I would want to raise for vote in coming days to be part of 1.3 in few days as we have more than 3 weeks to sort out non-ABI language part.
> >



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