Re: [RFC 0/4] Enable virtio-fs on s390x

["Daniel P. Berrangé" <berrange@redhat.com>]

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 :|