On Wed, Oct 06, 2021 at 12:13:14PM +0200, Cornelia Huck wrote: > On Mon, Oct 04 2021, "Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote: > > > On Mon, Oct 04, 2021 at 05:50:44PM +0200, Cornelia Huck wrote: > >> On Mon, Oct 04 2021, "Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote: > >> > >> > On Mon, Oct 04, 2021 at 04:33:21PM +0200, Cornelia Huck wrote: > >> >> On Mon, Oct 04 2021, "Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote: > >> >> > >> >> > On Mon, Oct 04, 2021 at 02:19:55PM +0200, Cornelia Huck wrote: > >> >> >> > >> >> >> [cc:qemu-devel] > >> >> >> > >> >> >> On Sat, Oct 02 2021, "Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote: > >> >> >> > >> >> >> > ok so that's a QEMU bug. Any virtio 1.0 and up > >> >> >> > compatible device must use LE. > >> >> >> > It can also present a legacy config space where the > >> >> >> > endian depends on the guest. > >> >> >> > >> >> >> So, how is the virtio core supposed to determine this? A > >> >> >> transport-specific callback? > >> >> > > >> >> > I'd say a field in VirtIODevice is easiest. > >> >> > >> >> The transport needs to set this as soon as it has figured out whether > >> >> we're using legacy or not. > >> > > >> > Basically on each device config access? > >> > >> Prior to the first one, I think. It should not change again, should it? > > > > Well yes but we never prohibited someone from poking at both .. > > Doing it on each access means we don't have state to migrate. > > Yes; if it isn't too high overhead, that's probably the safest way to > handle it. > > > > >> > > >> >> I guess we also need to fence off any > >> >> accesses respectively error out the device if the driver tries any > >> >> read/write operations that would depend on that knowledge? > >> >> > >> >> And using a field in VirtIODevice would probably need some care when > >> >> migrating. Hm... > >> > > >> > It's just a shorthand to minimize changes. No need to migrate I think. > >> > >> If we migrate in from an older QEMU, we don't know whether we are > >> dealing with legacy or not, until feature negotiation is already > >> done... don't we have to ask the transport? > > > > Right but the only thing that can happen is config access. > > Checking on each config space access would be enough then. > > > Well and for legacy a kick I guess. > > I think any driver that does something that is not config space access, > status access, or feature bit handling without VERSION_1 being set is > neccessarily legacy? Does that really need special handling? Likely not, I just wanted to be exact. -- MST
