On Thu, Jun 25, 2020 at 12:04:26PM +0200, Marc Hartmayer wrote: > This RFC is about enabling virtio-fs on s390x. For that we need > + some shim code (first patch), and we need > + libvhost-user to deal with virtio endiannes as mandated by the spec. > > The second part is trickier, because unlike QEMU we are not certain > about the guest's native endianness, which is needed to handle the > legacy-interface appropriately. In fact, this is the reason why just > RFC. > > One of the open questions is whether to build separate versions, one > for guest little endian and one for guest big endian, or do we want > something like a command line option? (Digression on the libvirt > modeling)
When you talk about big vs little endian, are you referring to TCG scenarios with mixed host/guest arch, or arches which can support either endianess, or both ? i guess it doesn't matter actually, as I think the latter forces a specific answer. Considering that some architectures allow the guest OS to flip between big & little endian as they boot, libvirt cannot know what endianess the guest is using when it launches virtiofsd. It thus cannot pick between two different endianness builds of virtiofsd automatically. This would force the user to tell libvirt what arch the guest is using at the time they define the guest. This is an undesirable restriction for use cases where the admin of the guest OS has no direct control over the host config. IOW, I think the only practical answer is to have a single binary that automagically does the right thing at runtime according to guest endianess that currently is in use. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
