qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 01/12] vhost-user-blk: fix blkcfg->num_queues endianness


From: Stefan Hajnoczi
Subject: Re: [PATCH v3 01/12] vhost-user-blk: fix blkcfg->num_queues endianness
Date: Wed, 24 Feb 2021 15:12:23 +0000

On Tue, Feb 23, 2021 at 11:13:47AM -0500, Michael S. Tsirkin wrote:
> On Tue, Feb 23, 2021 at 02:46:42PM +0000, Stefan Hajnoczi wrote:
> > Treat the num_queues field as virtio-endian. On big-endian hosts the
> > vhost-user-blk num_queues field was in the wrong endianness.
> > 
> > Move the blkcfg.num_queues store operation from realize to
> > vhost_user_blk_update_config() so feature negotiation has finished and
> > we know the endianness of the device. VIRTIO 1.0 devices are
> > little-endian, but in case someone wants to use legacy VIRTIO we support
> > all endianness cases.
> > 
> > Cc: qemu-stable@nongnu.org
> > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> > Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
> > Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
> 
> okay but as we recently discovered config space can in theory
> be read before FEATURES_OK. Nasty, I know. Things kind of work
> right now but we really need some other path to notify backends
> when legacy guest is active. E.g. VDPA also has this problem.

Thanks for mentioning it.

Do you know specifics about this type of guest driver? If it's only
legacy drivers then device implementations can ensure compatibility by
using host-endian until FEATURES_OK :). I guess existing code needs to
be audited to check if this can be done.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]