qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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
> 


  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).