From: Cornelia Huck <cohuck@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Stefan Hajnoczi" <stefanha@gmail.com>,
qemu-devel@nongnu.org, "Halil Pasic" <pasic@linux.ibm.com>,
"Marc Hartmayer" <mhartmay@linux.ibm.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>
Subject: Re: [RFC 0/4] Enable virtio-fs on s390x
Date: Tue, 30 Jun 2020 11:39:32 +0200 [thread overview]
Message-ID: <20200630113932.484b3fde.cohuck@redhat.com> (raw)
In-Reply-To: <20200630090451.GE81930@stefanha-x1.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2642 bytes --]
On Tue, 30 Jun 2020 10:04:51 +0100
Stefan Hajnoczi <stefanha@redhat.com> wrote:
> On Mon, Jun 29, 2020 at 02:07:16PM +0100, Daniel P. Berrangé wrote:
> > 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 ?
>
> vhost-user-fs-pci does not support Legacy or Transitional mode. See
> hw/virtio/vhost-user-fs-pci.c:
>
> static const VirtioPCIDeviceTypeInfo vhost_user_fs_pci_info = {
> .base_name = TYPE_VHOST_USER_FS_PCI,
> .non_transitional_name = "vhost-user-fs-pci",
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> .instance_size = sizeof(VHostUserFSPCI),
> .instance_init = vhost_user_fs_pci_instance_init,
> .class_init = vhost_user_fs_pci_class_init,
> };
This makes it very unlikely that someone accidentally configures
non-modern, but does not prevent it AFAICS. See
<20200630113527.7b27f34f.cohuck@redhat.com>, which I just sent.
(I may be off, because that is all very confusing...)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-06-30 9:42 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-25 10:04 [RFC 0/4] Enable virtio-fs on s390x Marc Hartmayer
2020-06-25 10:04 ` [RFC 1/4] virtio: add vhost-user-fs-ccw device Marc Hartmayer
2020-06-25 10:50 ` Cornelia Huck
2020-06-25 10:04 ` [RFC 2/4] libvhost-user: print invalid address on vu_panic Marc Hartmayer
2020-06-25 10:04 ` [RFC 3/4] libvhost-user: handle endianness as mandated by the spec Marc Hartmayer
2020-06-25 10:04 ` [RFC 4/4] HACK: Hard-code the libvhost-user.o-cflags for s390x Marc Hartmayer
2020-06-25 10:13 ` [RFC 0/4] Enable virtio-fs on s390x no-reply
2020-06-25 10:16 ` no-reply
2020-06-25 10:17 ` Cornelia Huck
2020-06-25 12:13 ` Halil Pasic
2020-06-25 10:19 ` Daniel P. Berrangé
2020-06-25 10:31 ` Cornelia Huck
2020-06-25 10:39 ` Daniel P. Berrangé
2020-06-25 10:46 ` Cornelia Huck
2020-06-25 11:07 ` Dr. David Alan Gilbert
2020-06-25 12:21 ` Halil Pasic
2020-06-29 12:53 ` Stefan Hajnoczi
2020-06-29 13:07 ` Daniel P. Berrangé
2020-06-30 9:04 ` Stefan Hajnoczi
2020-06-30 9:39 ` Cornelia Huck [this message]
2020-07-02 10:01 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200630113932.484b3fde.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=berrange@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mhartmay@linux.ibm.com \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.