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

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

On Mon, Jun 29, 2020 at 01:53:05PM +0100, Stefan Hajnoczi 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)
> > 
> > A third option would be to refuse legacy altogether.
> 
> I suggest the following:
> 
> 1. Combinations that worked with libvhost-user in the past must not break.
> 
> 2. New combinations should only support VIRTIO 1.0 and later.
> 
> This means continue to allow Legacy mode devices where they already run
> today but don't add new code for the cases that didn't work.

What I'm missing here is what PCI product ID was being used when the
current impl is in legacy/transitional mode ?

Normally legacy and transitional mode devices need an explicit PCI ID
reserved, where as modern-only devices have a PCI ID derived from their
VirtIO ID + a fixed offset.

Was this mistakenly using a VirtIO ID + fixed offset for the legacy
mode too ?

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