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. > > --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org