From: Pierrick Bouvier <pierrick.bouvier@linaro.org>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>,
qemu-devel@nongnu.org, "Thomas Huth" <thuth@redhat.com>
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 09/10] hw/virtio: Extract vhost_user_ram_slots_max() to vhost-user-target.c
Date: Thu, 10 Apr 2025 07:36:25 -0700 [thread overview]
Message-ID: <d4ecd6c2-73db-4c28-828c-bfa84ca90084@linaro.org> (raw)
In-Reply-To: <84b2bcf7-9df7-43e2-83d8-cae9d34ca541@linaro.org>
On 4/10/25 05:14, Philippe Mathieu-Daudé wrote:
> Hi Pierrick,
>
> On 13/12/22 00:05, Philippe Mathieu-Daudé wrote:
>> The current definition of VHOST_USER_MAX_RAM_SLOTS is
>> target specific. By converting this definition to a runtime
>> vhost_user_ram_slots_max() helper declared in a target
>> specific unit, we can have the rest of vhost-user.c target
>> independent.
>>
>> To avoid variable length array or using the heap to store
>> arrays of vhost_user_ram_slots_max() elements, we simply
>> declare an array of the biggest VHOST_USER_MAX_RAM_SLOTS,
>> and each target uses up to vhost_user_ram_slots_max()
>> elements of it. Ensure arrays are big enough by adding an
>> assertion in vhost_user_init().
>>
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>> ---
>> RFC: Should I add VHOST_USER_MAX_RAM_SLOTS to vhost-user.h
>> or create an internal header for it?
>> ---
>> hw/virtio/meson.build | 1 +
>> hw/virtio/vhost-user-target.c | 29 +++++++++++++++++++++++++++++
>> hw/virtio/vhost-user.c | 26 +++++---------------------
>> include/hw/virtio/vhost-user.h | 7 +++++++
>> 4 files changed, 42 insertions(+), 21 deletions(-)
>> create mode 100644 hw/virtio/vhost-user-target.c
>>
>> diff --git a/hw/virtio/meson.build b/hw/virtio/meson.build
>> index eb7ee8ea92..bf7e35fa8a 100644
>> --- a/hw/virtio/meson.build
>> +++ b/hw/virtio/meson.build
>> @@ -11,6 +11,7 @@ if have_vhost
>> specific_virtio_ss.add(files('vhost.c', 'vhost-backend.c', 'vhost-iova-tree.c'))
>> if have_vhost_user
>> specific_virtio_ss.add(files('vhost-user.c'))
>> + specific_virtio_ss.add(files('vhost-user-target.c'))
>> endif
>> if have_vhost_vdpa
>> specific_virtio_ss.add(files('vhost-vdpa.c', 'vhost-shadow-virtqueue.c'))
>> diff --git a/hw/virtio/vhost-user-target.c b/hw/virtio/vhost-user-target.c
>> new file mode 100644
>> index 0000000000..6a0d0f53d0
>> --- /dev/null
>> +++ b/hw/virtio/vhost-user-target.c
>> @@ -0,0 +1,29 @@
>> +/*
>> + * vhost-user target-specific helpers
>> + *
>> + * Copyright (c) 2013 Virtual Open Systems Sarl.
>> + *
>> + * SPDX-License-Identifier: GPL-2.0-or-later
>> + */
>> +
>> +#include "qemu/osdep.h"
>> +#include "hw/virtio/vhost-user.h"
>> +
>> +#if defined(TARGET_X86) || defined(TARGET_X86_64) || \
>> + defined(TARGET_ARM) || defined(TARGET_ARM_64)
>> +#include "hw/acpi/acpi.h"
>> +#elif defined(TARGET_PPC) || defined(TARGET_PPC64)
>> +#include "hw/ppc/spapr.h"
>> +#endif
>> +
>> +unsigned int vhost_user_ram_slots_max(void)
>> +{
>> +#if defined(TARGET_X86) || defined(TARGET_X86_64) || \
>> + defined(TARGET_ARM) || defined(TARGET_ARM_64)
>> + return ACPI_MAX_RAM_SLOTS;
>> +#elif defined(TARGET_PPC) || defined(TARGET_PPC64)
>> + return SPAPR_MAX_RAM_SLOTS;
>> +#else
>> + return 512;
>
> Should vhost_user_ram_slots_max be another TargetInfo field?
>
I don't think so, it would be better to transform the existing function
in something like:
switch (target_current()) {
case TARGET_X86:
case TARGET_ARM:
case TARGET_X86_64:
case TARGET_ARM_64:
return ACPI_MAX_RAM_SLOTS;
case TARGET PPC:
case TARGET PPC64:
return SPAPR_MAX_RAM_SLOTS;
default:
return 512;
}
We should not add anything possible to TargetInfo, just for the sake of
it. Especially becomes it's hard to follow values set per architecture.
In a case like this, a switch is much more readable and located in one
place. With a generated jump table, it's quite efficient also.
In my opinion, it's another proof we need to have TARGET_X, and
target_X() available at runtime.
>> +#endif
>> +}
>> diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
>> index 8f635844af..21fc176725 100644
>> --- a/hw/virtio/vhost-user.c
>> +++ b/hw/virtio/vhost-user.c
>> @@ -41,24 +41,7 @@
>> #define VHOST_MEMORY_BASELINE_NREGIONS 8
>> #define VHOST_USER_F_PROTOCOL_FEATURES 30
>> #define VHOST_USER_SLAVE_MAX_FDS 8
>> -
>> -/*
>> - * Set maximum number of RAM slots supported to
>> - * the maximum number supported by the target
>> - * hardware plaform.
>> - */
>> -#if defined(TARGET_X86) || defined(TARGET_X86_64) || \
>> - defined(TARGET_ARM) || defined(TARGET_ARM_64)
>> -#include "hw/acpi/acpi.h"
>> -#define VHOST_USER_MAX_RAM_SLOTS ACPI_MAX_RAM_SLOTS
>> -
>> -#elif defined(TARGET_PPC) || defined(TARGET_PPC64)
>> -#include "hw/ppc/spapr.h"
>> -#define VHOST_USER_MAX_RAM_SLOTS SPAPR_MAX_RAM_SLOTS
>> -
>> -#else
>> #define VHOST_USER_MAX_RAM_SLOTS 512
>> -#endif
>>
>> /*
>> * Maximum size of virtio device config space
>> @@ -935,7 +918,7 @@ static int vhost_user_add_remove_regions(struct vhost_dev *dev,
>>
>> if (track_ramblocks) {
>> memcpy(u->postcopy_client_bases, shadow_pcb,
>> - sizeof(uint64_t) * VHOST_USER_MAX_RAM_SLOTS);
>> + sizeof(uint64_t) * vhost_user_ram_slots_max());
>> /*
>> * Now we've registered this with the postcopy code, we ack to the
>> * client, because now we're in the position to be able to deal with
>> @@ -956,7 +939,7 @@ static int vhost_user_add_remove_regions(struct vhost_dev *dev,
>> err:
>> if (track_ramblocks) {
>> memcpy(u->postcopy_client_bases, shadow_pcb,
>> - sizeof(uint64_t) * VHOST_USER_MAX_RAM_SLOTS);
>> + sizeof(uint64_t) * vhost_user_ram_slots_max());
>> }
>>
>> return ret;
>> @@ -1030,7 +1013,7 @@ static int vhost_user_set_mem_table_postcopy(struct vhost_dev *dev,
>> }
>>
>> memset(u->postcopy_client_bases, 0,
>> - sizeof(uint64_t) * VHOST_USER_MAX_RAM_SLOTS);
>> + sizeof(uint64_t) * vhost_user_ram_slots_max());
>>
>> /*
>> * They're in the same order as the regions that were sent
>> @@ -2169,7 +2152,7 @@ static int vhost_user_backend_init(struct vhost_dev *dev, void *opaque,
>> return -EINVAL;
>> }
>>
>> - u->user->memory_slots = MIN(ram_slots, VHOST_USER_MAX_RAM_SLOTS);
>> + u->user->memory_slots = MIN(ram_slots, vhost_user_ram_slots_max());
>> }
>> }
>>
>> @@ -2649,6 +2632,7 @@ static void vhost_user_state_destroy(gpointer data)
>>
>> bool vhost_user_init(VhostUserState *user, CharBackend *chr, Error **errp)
>> {
>> + assert(vhost_user_ram_slots_max() <= VHOST_USER_MAX_RAM_SLOTS);
>> if (user->chr) {
>> error_setg(errp, "Cannot initialize vhost-user state");
>> return false;
>> diff --git a/include/hw/virtio/vhost-user.h b/include/hw/virtio/vhost-user.h
>> index 191216a74f..e13584ade8 100644
>> --- a/include/hw/virtio/vhost-user.h
>> +++ b/include/hw/virtio/vhost-user.h
>> @@ -86,4 +86,11 @@ void vhost_user_async_close(DeviceState *d,
>> CharBackend *chardev, struct vhost_dev *vhost,
>> vu_async_close_fn cb);
>>
>> +/**
>> + * vhost_user_ram_slots_max()
>> + *
>> + * Return: maximum number of RAM slots supported by the target hardware plaform.
>> + */
>> +unsigned int vhost_user_ram_slots_max(void);
>> +
>> #endif
>
next prev parent reply other threads:[~2025-04-10 14:37 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
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 [this message]
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=d4ecd6c2-73db-4c28-828c-bfa84ca90084@linaro.org \
--to=pierrick.bouvier@linaro.org \
--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=stefanha@redhat.com \
--cc=thuth@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).