From: Thomas Huth <thuth@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Richard Henderson" <richard.henderson@linaro.org>,
qemu-devel@nongnu.org
Cc: "Greg Kurz" <groug@kaod.org>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Kevin Wolf" <kwolf@redhat.com>,
qemu-block@nongnu.org, "Paolo Bonzini" <pbonzini@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Jason Wang" <jasowang@redhat.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Christian Schoenebeck" <qemu_oss@crudebyte.com>,
"Hanna Reitz" <hreitz@redhat.com>
Subject: Re: [RFC PATCH-for-8.0 06/10] hw/virtio: Cache access_is_big_endian value in VirtIODevice state
Date: Tue, 13 Dec 2022 09:47:32 +0100 [thread overview]
Message-ID: <d4063ce9-30a5-01b6-3869-b43ff5663711@redhat.com> (raw)
In-Reply-To: <6e6afa52-0a46-91fa-ebd4-642dfd2499a9@linaro.org>
On 13/12/2022 09.32, Philippe Mathieu-Daudé wrote:
> On 13/12/22 09:03, Thomas Huth wrote:
>> On 13/12/2022 08.30, Philippe Mathieu-Daudé wrote:
>>> On 13/12/22 01:14, Richard Henderson wrote:
>>>> On 12/12/22 17:05, Philippe Mathieu-Daudé wrote:
>>>>> The device endianness doesn't change during runtime.
>>>>
>>>> What are you talking about? Of course it does.
>>>
>>> The host CPU certainly does, but the virtio device doesn't... Does it?
>>>
>>> This check only consider the device, not the CPU:
>>>
>>> bool virtio_access_is_big_endian(VirtIODevice *vdev)
>>> {
>>> #if defined(LEGACY_VIRTIO_IS_BIENDIAN)
>>> return virtio_is_big_endian(vdev);
>>> #elif TARGET_BIG_ENDIAN
>>> if (virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
>>> /*Devices conforming to VIRTIO 1.0 or later are always LE.*/
>>> return false;
>>> }
>>> return true;
>>
>> Well, this part here means that the endianness can indeed change on the
>> device side during runtime. Depending on whether VIRTIO_F_VERSION_1 is
>> negotiated or not, the device is little or big endian. Happens on s390x
>> for example - for legacy virtio, big endian is used, and for modern
>> virtio, little endian is used instead.
>
> virtio_is_big_endian() depends on vdev->device_endian which is set in:
>
> 1) virtio_init()
>
> void virtio_init(VirtIODevice *vdev, uint16_t device_id,
> size_t config_size)
> {
> ....
> vdev->device_endian = virtio_default_endian();
>
> 2) virtio_load()
>
> int virtio_load(VirtIODevice *vdev, QEMUFile *f, int version_id)
> {
> int i, ret;
> int32_t config_len;
> uint32_t num;
> uint32_t features;
> BusState *qbus = qdev_get_parent_bus(DEVICE(vdev));
> VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus);
> VirtioDeviceClass *vdc = VIRTIO_DEVICE_GET_CLASS(vdev);
>
> /*
> * We poison the endianness to ensure it does not get
> * used before subsections have been loaded.
> */
> vdev->device_endian = VIRTIO_DEVICE_ENDIAN_UNKNOWN;
> ....
>
> if (vdev->device_endian == VIRTIO_DEVICE_ENDIAN_UNKNOWN) {
> vdev->device_endian = virtio_default_endian();
> }
>
> 3) virtio_reset()
>
> void virtio_reset(void *opaque)
> {
> VirtIODevice *vdev = opaque;
> VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(vdev);
> int i;
>
> virtio_set_status(vdev, 0);
> if (current_cpu) {
> /* Guest initiated reset */
> vdev->device_endian = virtio_current_cpu_endian();
This is where the virtio endianness depends on the CPU endianness. Looks
like it is fortunately only taken into account after a device reset, and not
for every access (as I originally thought).
Thomas
next prev parent reply other threads:[~2022-12-13 8:48 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-12 23:05 [RFC PATCH-for-8.0 00/10] hw/virtio: Build most objects as target independent units Philippe Mathieu-Daudé
2022-12-12 23:05 ` [PATCH-for-8.0 01/10] hw/virtio: Add missing "hw/core/cpu.h" include Philippe Mathieu-Daudé
2022-12-12 23:05 ` [PATCH-for-8.0 02/10] hw/virtio: Rename virtio_ss[] -> specific_virtio_ss[] Philippe Mathieu-Daudé
2022-12-12 23:05 ` [PATCH-for-8.0 03/10] hw/virtio: Constify qmp_virtio_feature_map_t[] Philippe Mathieu-Daudé
2022-12-13 0:02 ` Richard Henderson
2022-12-13 7:35 ` Philippe Mathieu-Daudé
2022-12-12 23:05 ` [PATCH-for-8.0 04/10] hw/virtio: Extract config read/write accessors to virtio-config.c Philippe Mathieu-Daudé
2022-12-12 23:05 ` [PATCH-for-8.0 05/10] hw/virtio: Extract QMP related code virtio-qmp.c Philippe Mathieu-Daudé
2022-12-12 23:05 ` [RFC PATCH-for-8.0 06/10] hw/virtio: Cache access_is_big_endian value in VirtIODevice state Philippe Mathieu-Daudé
2022-12-13 0:14 ` Richard Henderson
2022-12-13 7:30 ` Philippe Mathieu-Daudé
2022-12-13 8:03 ` Thomas Huth
2022-12-13 8:32 ` Philippe Mathieu-Daudé
2022-12-13 8:47 ` Thomas Huth [this message]
2022-12-13 8:22 ` Philippe Mathieu-Daudé
2022-12-13 15:41 ` Richard Henderson
2022-12-12 23:05 ` [RFC PATCH-for-8.0 07/10] hw/virtio: Directly access cached VirtIODevice::access_is_big_endian Philippe Mathieu-Daudé
2022-12-13 10:50 ` Greg Kurz
2022-12-12 23:05 ` [PATCH-for-8.0 08/10] hw/virtio: Un-inline virtio_access_is_big_endian() Philippe Mathieu-Daudé
2022-12-12 23:05 ` [RFC PATCH-for-8.0 09/10] hw/virtio: Extract vhost_user_ram_slots_max() to vhost-user-target.c Philippe Mathieu-Daudé
2025-04-10 12:14 ` Philippe Mathieu-Daudé
2025-04-10 14:36 ` Pierrick Bouvier
2025-04-10 17:21 ` Philippe Mathieu-Daudé
2025-04-10 17:29 ` Pierrick Bouvier
2025-04-11 10:15 ` Philippe Mathieu-Daudé
2022-12-12 23:05 ` [RFC PATCH-for-8.0 10/10] hw/virtio: Make most of virtio devices target-independent Philippe Mathieu-Daudé
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=d4063ce9-30a5-01b6-3869-b43ff5663711@redhat.com \
--to=thuth@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=groug@kaod.org \
--cc=hreitz@redhat.com \
--cc=jasowang@redhat.com \
--cc=kwolf@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu_oss@crudebyte.com \
--cc=richard.henderson@linaro.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).