Message ID | 20211112145749.618157-1-pasic@linux.ibm.com |
---|---|
Headers | show |
Series | virtio: early detect 'modern' virtio | expand |
On Fri, 12 Nov 2021 15:57:44 +0100 Halil Pasic <pasic@linux.ibm.com> wrote: > This is an early RFC for a transport specific early detecton of > modern virtio, which is most relevant for transitional devices on big > endian platforms, when drivers access the config space before > FEATURES_OK is set. [..] Ping! @Michael: Can you have a look at this, please?
On Tue, 23 Nov 2021 14:13:40 +0100 Halil Pasic <pasic@linux.ibm.com> wrote: > On Fri, 12 Nov 2021 15:57:44 +0100 > Halil Pasic <pasic@linux.ibm.com> wrote: > > > This is an early RFC for a transport specific early detecton of > > modern virtio, which is most relevant for transitional devices on big > > endian platforms, when drivers access the config space before > > FEATURES_OK is set. > > [..] > > Ping! > > @Michael: Can you have a look at this, please? Ping^2
On Fri, Nov 12, 2021 at 03:57:44PM +0100, Halil Pasic wrote: > This is an early RFC for a transport specific early detecton of > modern virtio, which is most relevant for transitional devices on big > endian platforms, when drivers access the config space before > FEATURES_OK is set. > > The most important part that is missing here is fixing all the problems > that arise in the situation described in the previous paragraph, when > the config is managed by a vhost device (and thus outside QEMU. This > series tackles this problem only for virtio_net+vhost as an example. If > this approach is deemed good, we need to do something very similar for > every single affected device. > > This series was only lightly tested. The vhost stuff is entirely > untested, unfortunately I don't have a working setup where this > handling would be needed (because the config space is handled in the > device). DPDK is not supported on s390x so at the moment I can't test > DPDK based setups. So this looks sane to me. Cornelia requested some name tweaks and we need to add vhost-user things and more devices, but otherwise we are good. > v1 -> v2: > > * add callback > * tweak feature manipulation > * add generic handling for vhost that needs to be called by devices > * add handling for virtio > > Halil Pasic (5): > virtio: introduce virtio_force_modern() > virtio-ccw: use virtio_force_modern() > virtio-pci: use virtio_force_modern() > vhost: push features to backend on force_modern > virtio-net: handle force_modern for vhost > > hw/net/virtio-net.c | 20 ++++++++++++++++++++ > hw/s390x/virtio-ccw.c | 3 +++ > hw/virtio/vhost.c | 17 +++++++++++++++++ > hw/virtio/virtio-pci.c | 1 + > hw/virtio/virtio.c | 13 +++++++++++++ > include/hw/virtio/vhost.h | 2 ++ > include/hw/virtio/virtio.h | 2 ++ > 7 files changed, 58 insertions(+) > > > base-commit: 2c3e83f92d93fbab071b8a96b8ab769b01902475 > -- > 2.25.1
On Wed, 8 Dec 2021 13:56:19 -0500 "Michael S. Tsirkin" <mst@redhat.com> wrote: > On Fri, Nov 12, 2021 at 03:57:44PM +0100, Halil Pasic wrote: > > This is an early RFC for a transport specific early detecton of > > modern virtio, which is most relevant for transitional devices on big > > endian platforms, when drivers access the config space before > > FEATURES_OK is set. > > > > The most important part that is missing here is fixing all the problems > > that arise in the situation described in the previous paragraph, when > > the config is managed by a vhost device (and thus outside QEMU. This > > series tackles this problem only for virtio_net+vhost as an example. If > > this approach is deemed good, we need to do something very similar for > > every single affected device. > > > > This series was only lightly tested. The vhost stuff is entirely > > untested, unfortunately I don't have a working setup where this > > handling would be needed (because the config space is handled in the > > device). DPDK is not supported on s390x so at the moment I can't test > > DPDK based setups. > > So this looks sane to me. Cornelia requested some name tweaks and we > need to add vhost-user things and more devices, but otherwise we are > good. Thanks for your feedback! There were several points where I could not reach agreement with Cornelia. From your response I recon that: 1) I should rename virtio_force_modern() to virtio_indicate_modern() (per maintainer request). 2) Keep the call to virtio_set_features()? Is that right? Regards, Halil
On Thu, Dec 09, 2021 at 02:29:25PM +0100, Halil Pasic wrote: > On Wed, 8 Dec 2021 13:56:19 -0500 > "Michael S. Tsirkin" <mst@redhat.com> wrote: > > > On Fri, Nov 12, 2021 at 03:57:44PM +0100, Halil Pasic wrote: > > > This is an early RFC for a transport specific early detecton of > > > modern virtio, which is most relevant for transitional devices on big > > > endian platforms, when drivers access the config space before > > > FEATURES_OK is set. > > > > > > The most important part that is missing here is fixing all the problems > > > that arise in the situation described in the previous paragraph, when > > > the config is managed by a vhost device (and thus outside QEMU. This > > > series tackles this problem only for virtio_net+vhost as an example. If > > > this approach is deemed good, we need to do something very similar for > > > every single affected device. > > > > > > This series was only lightly tested. The vhost stuff is entirely > > > untested, unfortunately I don't have a working setup where this > > > handling would be needed (because the config space is handled in the > > > device). DPDK is not supported on s390x so at the moment I can't test > > > DPDK based setups. > > > > So this looks sane to me. Cornelia requested some name tweaks and we > > need to add vhost-user things and more devices, but otherwise we are > > good. > > Thanks for your feedback! There were several points where I could > not reach agreement with Cornelia. From your response I recon that: > > 1) I should rename virtio_force_modern() to virtio_indicate_modern() > (per maintainer request). > 2) Keep the call to virtio_set_features()? > > Is that right? > > Regards, > Halil that's my take, yes.