On Wed, Oct 06, 2021 at 12:13:14PM +0200, Cornelia Huck wrote:

On Mon, Oct 04 2021, "Michael S. Tsirkin" [off-list ref] wrote:

quoted

On Mon, Oct 04, 2021 at 05:50:44PM +0200, Cornelia Huck wrote:

quoted

On Mon, Oct 04 2021, "Michael S. Tsirkin" [off-list ref] wrote:

quoted

On Mon, Oct 04, 2021 at 04:33:21PM +0200, Cornelia Huck wrote:

quoted

On Mon, Oct 04 2021, "Michael S. Tsirkin" [off-list ref] wrote:

quoted

On Mon, Oct 04, 2021 at 02:19:55PM +0200, Cornelia Huck wrote:

quoted

[cc:qemu-devel]

On Sat, Oct 02 2021, "Michael S. Tsirkin" [off-list ref] wrote:

quoted

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.

quoted

quoted

quoted

quoted

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.

quoted

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

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization