On Tue, May 16, 2023 at 07:35:20PM +0000, Parav Pandit wrote: > > > From: virtio-comm...@lists.oasis-open.org <virtio-comment@lists.oasis- > > open.org> On Behalf Of Jason Wang > > Sent: Monday, May 15, 2023 11:55 PM > > > I don’t see how this is being any different than register-offset > > > interface. > > > > It bisects more things at hypervisor level that makes things hard to add > > > #12th > > entry. > > > > > >> 1) device features > > >> 2) driver features > > >> 3) queue address > > >> 4) queue size > > >> 5) queue select > > >> 6) queue notify > > >> 7) device status > > >> 8) ISR status > > >> 9) config msix > > >> 10) queue msix > > >> 11) device configuration space > > >> > > >> It focuses on the facilities instead of transport specific details like > > >> registers > > (we > > >> don't even need legacy registers in this case), I gives more > > >> deterministic > > >> behavior so we don't need to care about the cross registers read/write. > > >> > > > 1.x has these registers at raw level and that seems fine. > > > > > > Note that 1.x has more, the above is dumped from the section of "Legacy > > Interfaces: A Note on PCI Device Layout". > > Yeah. > Current two commands proposal has one box to transport legacy registers that > follows the legacy semantics. > Above commands in future with legacy commands of this work will be able to > work together in future anyway.
Nah, we don't need a "break randomly unless it's a full moon and you cross your heart three times" mode. If you are going to implement support for legacy emulation implement it in a way that either predictably works or predictably refuses to load. -- MST --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
