On Thu, 25 Jun 2020 11:19:35 +0100 Daniel P. Berrangé <berra...@redhat.com> wrote:
> 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. Right, but that is in practice only a problem for legacy devices, isn't it? The standard says that non-legacy devices use little-endian everywhere; it's the legacy 'device endian' that is causing us headaches. Which leads to the question: Do we really need to support legacy virtio-fs devices, or can we just force virtio-1, as many (most?) newer virtio devices do? > > 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