Re: [PULL 08/20] virtio-net: Add only one queue pair when realizing
On Mon, Oct 14, 2024 at 11:16 PM Laurent Vivier wrote:
>
> On 14/10/2024 10:30, Laurent Vivier wrote:
> > Hi Akihiko,
> >
> > On 04/06/2024 09:37, Jason Wang wrote:
> >> From: Akihiko Odaki
> >>
> >> Multiqueue usage is not negotiated yet when realizing. If more than
> >> one queue is added and the guest never requests to enable multiqueue,
> >> the extra queues will not be deleted when unrealizing and leak.
> >>
> >> Fixes: f9d6dbf0bf6e ("virtio-net: remove virtio queues if the guest
> >> doesn't support
> >> multiqueue")
> >> Signed-off-by: Akihiko Odaki
> >> Signed-off-by: Jason Wang
> >> ---
> >> hw/net/virtio-net.c | 4 +---
> >> 1 file changed, 1 insertion(+), 3 deletions(-)
> >>
> >> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> >> index 3cee2ef3ac..a8db8bfd9c 100644
> >> --- a/hw/net/virtio-net.c
> >> +++ b/hw/net/virtio-net.c
> >> @@ -3743,9 +3743,7 @@ static void virtio_net_device_realize(DeviceState
> >> *dev, Error **errp)
> >> n->net_conf.tx_queue_size = MIN(virtio_net_max_tx_queue_size(n),
> >> n->net_conf.tx_queue_size);
> >> -for (i = 0; i < n->max_queue_pairs; i++) {
> >> -virtio_net_add_queue(n, i);
> >> -}
> >> +virtio_net_add_queue(n, 0);
> >> n->ctrl_vq = virtio_add_queue(vdev, 64, virtio_net_handle_ctrl);
> >> qemu_macaddr_default_if_unset(&n->nic_conf.macaddr);
> >
> > This change breaks virtio net migration when multiqueue is enabled.
> >
> > I think this is because virtqueues are half initialized after migration :
> > they are
> > initialized on guest side (kernel is using them) but not on QEMU side
> > (realized has only
> > initialized one). After migration, they are not initialized by the call to
> > virtio_net_set_multiqueue() from virtio_net_set_features() because
> > virtio_get_num_queues()
> > reports already n->max_queue_pairs as this value is coming from the source
> > guest memory.
> >
> > I don't think we have a way to half-initialize a virtqueue (to initialize
> > them only on
> > QEMU side as they are already initialized on kernel side).
> >
> > I think this change should be reverted to fix the migration issue.
> >
>
> Moreover, if I look in the code of virtio_load() and virtio_add_queue() we
> can guess it's
> not correct to migrate a virtqueue that is not initialized on the destination
> side because
> fields like 'vdev->vq[i].handle_output' or 'vdev->vq[i].used_elems' cannot be
> initialized
> by virtio_load() and neither by virtio_add_queue() after virtio_load() as
> fields like
> 'vring.num' are already initialized by virtio_load().
>
> For instance, in virtio_load() we set:
>
> for (i = 0; i < num; i++) {
> vdev->vq[i].vring.num = qemu_get_be32(f);
>
> and in virtio_add_queue() we search for the firt available queue to add with:
>
> for (i = 0; i < VIRTIO_QUEUE_MAX; i++) {
> if (vdev->vq[i].vring.num == 0)
> break;
> }
>
> So virtio_add_queue() cannot be used to set:
>
> vdev->vq[i].handle_output = handle_output;
> vdev->vq[i].used_elems = g_new0(VirtQueueElement, queue_size);
>
> Moreover it would overwrite fields already set by virtio_load():
>
> vdev->vq[i].vring.num = queue_size;
> vdev->vq[i].vring.align = VIRTIO_PCI_VRING_ALIGN;
>
> It also explains why virtio_net_change_num_queue_pairs() (indirectly called by
> virtio_net_set_features()) doesn't update the queue pair numbers: vring.num
> is already set
> so it thinks there is no more queues to add.
>
> Thanks,
> LAurent
>
I agree.
Laurent, would you like to send a patch to revert this?
Thanks
>
Re: [PULL 08/20] virtio-net: Add only one queue pair when realizing
On 17/10/2024 08:59, Jason Wang wrote:
On Mon, Oct 14, 2024 at 11:16 PM Laurent Vivier wrote:
On 14/10/2024 10:30, Laurent Vivier wrote:
Hi Akihiko,
On 04/06/2024 09:37, Jason Wang wrote:
From: Akihiko Odaki
Multiqueue usage is not negotiated yet when realizing. If more than
one queue is added and the guest never requests to enable multiqueue,
the extra queues will not be deleted when unrealizing and leak.
Fixes: f9d6dbf0bf6e ("virtio-net: remove virtio queues if the guest doesn't
support
multiqueue")
Signed-off-by: Akihiko Odaki
Signed-off-by: Jason Wang
---
hw/net/virtio-net.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 3cee2ef3ac..a8db8bfd9c 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -3743,9 +3743,7 @@ static void virtio_net_device_realize(DeviceState *dev,
Error **errp)
n->net_conf.tx_queue_size = MIN(virtio_net_max_tx_queue_size(n),
n->net_conf.tx_queue_size);
-for (i = 0; i < n->max_queue_pairs; i++) {
-virtio_net_add_queue(n, i);
-}
+virtio_net_add_queue(n, 0);
n->ctrl_vq = virtio_add_queue(vdev, 64, virtio_net_handle_ctrl);
qemu_macaddr_default_if_unset(&n->nic_conf.macaddr);
This change breaks virtio net migration when multiqueue is enabled.
I think this is because virtqueues are half initialized after migration : they
are
initialized on guest side (kernel is using them) but not on QEMU side (realized
has only
initialized one). After migration, they are not initialized by the call to
virtio_net_set_multiqueue() from virtio_net_set_features() because
virtio_get_num_queues()
reports already n->max_queue_pairs as this value is coming from the source
guest memory.
I don't think we have a way to half-initialize a virtqueue (to initialize them
only on
QEMU side as they are already initialized on kernel side).
I think this change should be reverted to fix the migration issue.
Moreover, if I look in the code of virtio_load() and virtio_add_queue() we can
guess it's
not correct to migrate a virtqueue that is not initialized on the destination
side because
fields like 'vdev->vq[i].handle_output' or 'vdev->vq[i].used_elems' cannot be
initialized
by virtio_load() and neither by virtio_add_queue() after virtio_load() as
fields like
'vring.num' are already initialized by virtio_load().
For instance, in virtio_load() we set:
for (i = 0; i < num; i++) {
vdev->vq[i].vring.num = qemu_get_be32(f);
and in virtio_add_queue() we search for the firt available queue to add with:
for (i = 0; i < VIRTIO_QUEUE_MAX; i++) {
if (vdev->vq[i].vring.num == 0)
break;
}
So virtio_add_queue() cannot be used to set:
vdev->vq[i].handle_output = handle_output;
vdev->vq[i].used_elems = g_new0(VirtQueueElement, queue_size);
Moreover it would overwrite fields already set by virtio_load():
vdev->vq[i].vring.num = queue_size;
vdev->vq[i].vring.align = VIRTIO_PCI_VRING_ALIGN;
It also explains why virtio_net_change_num_queue_pairs() (indirectly called by
virtio_net_set_features()) doesn't update the queue pair numbers: vring.num is
already set
so it thinks there is no more queues to add.
Thanks,
LAurent
I agree.
Laurent, would you like to send a patch to revert this?
Yes. I will also try to fix the leak in unrealize that the patch wanted to fix
initially.
Thanks,
Laurent
Re: [PULL 08/20] virtio-net: Add only one queue pair when realizing
On 2024/10/17 16:32, Laurent Vivier wrote:
On 17/10/2024 08:59, Jason Wang wrote:
On Mon, Oct 14, 2024 at 11:16 PM Laurent Vivier
wrote:
On 14/10/2024 10:30, Laurent Vivier wrote:
Hi Akihiko,
On 04/06/2024 09:37, Jason Wang wrote:
From: Akihiko Odaki
Multiqueue usage is not negotiated yet when realizing. If more than
one queue is added and the guest never requests to enable multiqueue,
the extra queues will not be deleted when unrealizing and leak.
Fixes: f9d6dbf0bf6e ("virtio-net: remove virtio queues if the guest
doesn't support
multiqueue")
Signed-off-by: Akihiko Odaki
Signed-off-by: Jason Wang
---
hw/net/virtio-net.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 3cee2ef3ac..a8db8bfd9c 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -3743,9 +3743,7 @@ static void
virtio_net_device_realize(DeviceState *dev, Error **errp)
n->net_conf.tx_queue_size =
MIN(virtio_net_max_tx_queue_size(n),
n->net_conf.tx_queue_size);
- for (i = 0; i < n->max_queue_pairs; i++) {
- virtio_net_add_queue(n, i);
- }
+ virtio_net_add_queue(n, 0);
n->ctrl_vq = virtio_add_queue(vdev, 64,
virtio_net_handle_ctrl);
qemu_macaddr_default_if_unset(&n->nic_conf.macaddr);
This change breaks virtio net migration when multiqueue is enabled.
I think this is because virtqueues are half initialized after
migration : they are
initialized on guest side (kernel is using them) but not on QEMU
side (realized has only
initialized one). After migration, they are not initialized by the
call to
virtio_net_set_multiqueue() from virtio_net_set_features() because
virtio_get_num_queues()
reports already n->max_queue_pairs as this value is coming from the
source guest memory.
I don't think we have a way to half-initialize a virtqueue (to
initialize them only on
QEMU side as they are already initialized on kernel side).
I think this change should be reverted to fix the migration issue.
Moreover, if I look in the code of virtio_load() and
virtio_add_queue() we can guess it's
not correct to migrate a virtqueue that is not initialized on the
destination side because
fields like 'vdev->vq[i].handle_output' or 'vdev->vq[i].used_elems'
cannot be initialized
by virtio_load() and neither by virtio_add_queue() after
virtio_load() as fields like
'vring.num' are already initialized by virtio_load().
For instance, in virtio_load() we set:
for (i = 0; i < num; i++) {
vdev->vq[i].vring.num = qemu_get_be32(f);
and in virtio_add_queue() we search for the firt available queue to
add with:
for (i = 0; i < VIRTIO_QUEUE_MAX; i++) {
if (vdev->vq[i].vring.num == 0)
break;
}
So virtio_add_queue() cannot be used to set:
vdev->vq[i].handle_output = handle_output;
vdev->vq[i].used_elems = g_new0(VirtQueueElement, queue_size);
Moreover it would overwrite fields already set by virtio_load():
vdev->vq[i].vring.num = queue_size;
vdev->vq[i].vring.align = VIRTIO_PCI_VRING_ALIGN;
It also explains why virtio_net_change_num_queue_pairs() (indirectly
called by
virtio_net_set_features()) doesn't update the queue pair numbers:
vring.num is already set
so it thinks there is no more queues to add.
Thanks,
LAurent
I agree.
Laurent, would you like to send a patch to revert this?
Yes. I will also try to fix the leak in unrealize that the patch wanted
to fix initially.
I wrote a fix so I will submit it once internal testing is done. You can
see the change at:
https://gitlab.com/akihiko.odaki/qemu-kvm/-/commit/22161221aa2d2031d7ad1be7701852083aa9109a
Regards,
Akihiko Odaki
Re: [PATCH v3 1/8] target/riscv: Add Ssdbltrp CSRs handling
On 17/10/2024 10:35, Clément Léger wrote:
>
>
> On 16/10/2024 11:40, LIU Zhiwei wrote:
>>
>> On 2024/10/14 19:22, Clément Léger wrote:
>>> Add ext_ssdbltrp in RISCVCPUConfig and implement MSTATUS.SDT,
>>> {H|M}ENVCFG.DTE and modify the availability of MTVAL2 based on the
>>> presence of the Ssdbltrp ISA extension.
>>>
>>> Signed-off-by: Clément Léger
>>> Reviewed-by: Alistair Francis
>>> ---
>>> target/riscv/cpu.h | 1 +
>>> target/riscv/cpu_bits.h | 6 ++
>>> target/riscv/cpu_cfg.h | 1 +
>>> target/riscv/cpu_helper.c | 20 +
>>> target/riscv/csr.c | 45 ++-
>>> 5 files changed, 63 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
>>> index a84e719d3f..ee984bf270 100644
>>> --- a/target/riscv/cpu.h
>>> +++ b/target/riscv/cpu.h
>>> @@ -553,6 +553,7 @@ void riscv_cpu_set_geilen(CPURISCVState *env,
>>> target_ulong geilen);
>>> bool riscv_cpu_vector_enabled(CPURISCVState *env);
>>> void riscv_cpu_set_virt_enabled(CPURISCVState *env, bool enable);
>>> int riscv_env_mmu_index(CPURISCVState *env, bool ifetch);
>>> +bool riscv_env_smode_dbltrp_enabled(CPURISCVState *env, bool virt);
>>> G_NORETURN void riscv_cpu_do_unaligned_access(CPUState *cs, vaddr
>>> addr,
>>> MMUAccessType
>>> access_type,
>>> int mmu_idx,
>>> uintptr_t retaddr);
>>> diff --git a/target/riscv/cpu_bits.h b/target/riscv/cpu_bits.h
>>> index da1723496c..3a5588d4df 100644
>>> --- a/target/riscv/cpu_bits.h
>>> +++ b/target/riscv/cpu_bits.h
>>> @@ -558,6 +558,7 @@
>>> #define MSTATUS_TVM 0x0010 /* since: priv-1.10 */
>>> #define MSTATUS_TW 0x0020 /* since: priv-1.10 */
>>> #define MSTATUS_TSR 0x0040 /* since: priv-1.10 */
>>> +#define MSTATUS_SDT 0x0100
>>> #define MSTATUS_GVA 0x40ULL
>>> #define MSTATUS_MPV 0x80ULL
>>> @@ -588,6 +589,7 @@ typedef enum {
>>> #define SSTATUS_XS 0x00018000
>>> #define SSTATUS_SUM 0x0004 /* since: priv-1.10 */
>>> #define SSTATUS_MXR 0x0008
>>> +#define SSTATUS_SDT 0x0100
>>> #define SSTATUS64_UXL 0x0003ULL
>>> @@ -777,11 +779,13 @@ typedef enum RISCVException {
>>> #define MENVCFG_CBIE (3UL << 4)
>>> #define MENVCFG_CBCFE BIT(6)
>>> #define MENVCFG_CBZE BIT(7)
>>> +#define MENVCFG_DTE (1ULL << 59)
>>> #define MENVCFG_ADUE (1ULL << 61)
>>> #define MENVCFG_PBMTE (1ULL << 62)
>>> #define MENVCFG_STCE (1ULL << 63)
>>> /* For RV32 */
>>> +#define MENVCFGH_DTE BIT(27)
>>> #define MENVCFGH_ADUE BIT(29)
>>> #define MENVCFGH_PBMTE BIT(30)
>>> #define MENVCFGH_STCE BIT(31)
>>> @@ -795,11 +799,13 @@ typedef enum RISCVException {
>>> #define HENVCFG_CBIE MENVCFG_CBIE
>>> #define HENVCFG_CBCFE MENVCFG_CBCFE
>>> #define HENVCFG_CBZE MENVCFG_CBZE
>>> +#define HENVCFG_DTE MENVCFG_DTE
>>> #define HENVCFG_ADUE MENVCFG_ADUE
>>> #define HENVCFG_PBMTE MENVCFG_PBMTE
>>> #define HENVCFG_STCE MENVCFG_STCE
>>> /* For RV32 */
>>> +#define HENVCFGH_DTE MENVCFGH_DTE
>>> #define HENVCFGH_ADUE MENVCFGH_ADUE
>>> #define HENVCFGH_PBMTE MENVCFGH_PBMTE
>>> #define HENVCFGH_STCE MENVCFGH_STCE
>>> diff --git a/target/riscv/cpu_cfg.h b/target/riscv/cpu_cfg.h
>>> index ae2a945b5f..dd804f95d4 100644
>>> --- a/target/riscv/cpu_cfg.h
>>> +++ b/target/riscv/cpu_cfg.h
>>> @@ -77,6 +77,7 @@ struct RISCVCPUConfig {
>>> bool ext_smstateen;
>>> bool ext_sstc;
>>> bool ext_smcntrpmf;
>>> + bool ext_ssdbltrp;
>>> bool ext_svadu;
>>> bool ext_svinval;
>>> bool ext_svnapot;
>>> diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
>>> index 9d0400035f..77e7736d8a 100644
>>> --- a/target/riscv/cpu_helper.c
>>> +++ b/target/riscv/cpu_helper.c
>>> @@ -63,6 +63,22 @@ int riscv_env_mmu_index(CPURISCVState *env, bool
>>> ifetch)
>>> #endif
>>> }
>>> +bool riscv_env_smode_dbltrp_enabled(CPURISCVState *env, bool virt)
>>> +{
>>> +#ifdef CONFIG_USER_ONLY
>>> + return false;
>>> +#else
>>> + if (!riscv_cpu_cfg(env)->ext_ssdbltrp) {
>>> + return false;
>>> + }
>>
>> As we have guard the write to henvcfg and menvcfg by ext_ssdbltrp, I
>> think it is enough only check henvcfg or menvcfg.
>>
>> The only miss is we don't guard the writhe to henvcfgh. I think we can
>> add the guard there.
>
>
Re: [PATCH] vhost-user: fix shared object return values
On Thu, Oct 17, 2024 at 10:44 AM Daniel P. Berrangé wrote:
>
> On Wed, Oct 16, 2024 at 11:06:06AM +0200, Albert Esteve wrote:
> > VHOST_USER_BACKEND_SHARED_OBJECT_ADD and
> > VHOST_USER_BACKEND_SHARED_OBJECT_REMOVE state
> > in the spec that they return 0 for successful
> > operations, non-zero otherwise. However,
> > implementation relies on the return types
> > of the virtio-dmabuf library, with opposite
> > semantics (true if everything is correct,
> > false otherwise). Therefore, current implementaion
> > violates the specification.
> >
> > Revert the logic so that the implementation
> > of the vhost-user handling methods matches
> > the specification.
> >
> > Fixes: 043e127a126bb3ceb5fc753deee27d261fd0c5ce
> > Fixes: 160947666276c5b7f6bca4d746bcac2966635d79
> > Signed-off-by: Albert Esteve
> > ---
> > hw/virtio/vhost-user.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
> > index 00561daa06..90917352a4 100644
> > --- a/hw/virtio/vhost-user.c
> > +++ b/hw/virtio/vhost-user.c
> > @@ -1607,7 +1607,7 @@ vhost_user_backend_handle_shared_object_add(struct
> > vhost_dev *dev,
> > QemuUUID uuid;
> >
> > memcpy(uuid.data, object->uuid, sizeof(object->uuid));
> > -return virtio_add_vhost_device(&uuid, dev);
> > +return !virtio_add_vhost_device(&uuid, dev);
> > }
>
> This virtio_add_vhost_device() method returns a bool, but this
> vhost_user_backend_handle_shared_object_add() method returns
> an int, but fills that int with an inverted bool value. The
> caller then assigns the return value to an int, but then
> interprets the int as a bool, and assigns that bool result
> to an u64.
>
> This call chain is madness :-(
TBF most of the madness is part of the already existing
handling infrastructure.
vhost_user_backend_handle_shared_object_add()
returns an int to be consistent with other handling
functions.
>
> Change vhost_user_backend_handle_shared_object_add to return
> a bool to reduce the madness IMHO.
Changing it to bool would make it inconsistent
wrt other handlers, and the casting would happen nonetheless
on assignment. Not sure if that is an improvement.
>
> >
> > static int
> > @@ -1623,16 +1623,16 @@
> > vhost_user_backend_handle_shared_object_remove(struct vhost_dev *dev,
> > struct vhost_dev *owner = virtio_lookup_vhost_device(&uuid);
> > if (dev != owner) {
> > /* Not allowed to remove non-owned entries */
> > -return 0;
> > +return -EPERM;
> > }
> > break;
> > }
> > default:
> > /* Not allowed to remove non-owned entries */
> > -return 0;
> > +return -EPERM;
> > }
> >
> > -return virtio_remove_resource(&uuid);
> > +return !virtio_remove_resource(&uuid);
> > }
>
> These return values are inconsistent.
>
> In some places you're returning a negative errno, but in this
> last place you're returning true or false, by calling
> virtio_remove_resource which is a 'bool' method & inverting it.
Well, specification only distinguish between zero and non-zero values.
But for clarity, I guess I could do something like:
```
if (!virtio_remove_resource(&uuid)) {
return -EINVAL;
}
return 0;
```
Same for the vhost_user_backend_handle_shared_object_add()
handler (in that case there is no inconsistency with positive or negative
return values, but still better to maintain similar strategy for all
handlers).
BR,
Albert.
>
> On top of this inconsistency, it has all the same madness mentioneed
> above.
>
> With regards,
> Daniel
> --
> |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
>
Re: [PULL 13/25] target/i386: convert CMPXCHG8B/CMPXCHG16B to new decoder
On Wed, Oct 16, 2024 at 6:37 PM Philippe Mathieu-Daudé wrote: > On s390x the cdrom-test generates: > > tcg/s390x/tcg-target.c.inc:1284:tgen_cmp2: code should not be reached Backend bug, sent "[PATCH] tcg/s390x: fix constraint for 32-bit TSTEQ/TSTNE" to fix it. Paolo
[PATCH] linux-user: Trace rt_sigprocmask's sigsets
Add a function for formatting target sigsets. It can be useful for
other syscalls in the future, so put it into the beginning of strace.c.
For simplicity, do not implement the strace's ~[] output syntax.
Add a rt_sigprocmask return handler.
Example outputs:
4072707 rt_sigprocmask(SIG_BLOCK,[SIGHUP SIGINT SIGQUIT SIGALRM SIGTERM
SIGTSTP SIGTTIN SIGTTOU],[],8) = 0
4072853 rt_sigprocmask(SIG_UNBLOCK,[32 33],NULL,8) = 0
Signed-off-by: Ilya Leoshkevich
---
linux-user/strace.c| 84 --
linux-user/strace.list | 3 +-
2 files changed, 75 insertions(+), 12 deletions(-)
diff --git a/linux-user/strace.c b/linux-user/strace.c
index c3eb3a2706a..1fdbd9854ba 100644
--- a/linux-user/strace.c
+++ b/linux-user/strace.c
@@ -161,19 +161,20 @@ static const char * const target_signal_name[] = {
};
static void
-print_signal(abi_ulong arg, int last)
+print_signal_1(abi_ulong arg)
{
-const char *signal_name = NULL;
-
if (arg < ARRAY_SIZE(target_signal_name)) {
-signal_name = target_signal_name[arg];
+qemu_log("%s", target_signal_name[arg]);
+} else {
+qemu_log(TARGET_ABI_FMT_lu, arg);
}
+}
-if (signal_name == NULL) {
-print_raw_param("%ld", arg, last);
-return;
-}
-qemu_log("%s%s", signal_name, get_comma(last));
+static void
+print_signal(abi_ulong arg, int last)
+{
+print_signal_1(arg);
+qemu_log("%s", get_comma(last));
}
static void print_si_code(int arg)
@@ -718,6 +719,51 @@ print_ipc(CPUArchState *cpu_env, const struct syscallname
*name,
}
#endif
+#ifdef TARGET_NR_rt_sigprocmask
+static void print_target_sigset_t_1(target_sigset_t *set, int last)
+{
+bool first = true;
+int i, sig = 1;
+
+qemu_log("[");
+for (i = 0; i < TARGET_NSIG_WORDS; i++) {
+abi_ulong bits = 0;
+int j;
+
+__get_user(bits, &set->sig[i]);
+for (j = 0; j < sizeof(bits) * 8; j++) {
+if (bits & ((abi_ulong)1 << j)) {
+if (first) {
+first = false;
+} else {
+qemu_log(" ");
+}
+print_signal_1(sig);
+}
+sig++;
+}
+}
+qemu_log("]%s", get_comma(last));
+}
+
+static void print_target_sigset_t(abi_ulong addr, abi_ulong size, int last)
+{
+if (addr && size == sizeof(target_sigset_t)) {
+target_sigset_t *set;
+
+set = lock_user(VERIFY_READ, addr, sizeof(target_sigset_t), 1);
+if (set) {
+print_target_sigset_t_1(set, last);
+unlock_user(set, addr, 0);
+} else {
+print_pointer(addr, last);
+}
+} else {
+print_pointer(addr, last);
+}
+}
+#endif
+
/*
* Variants for the return value output function
*/
@@ -3312,10 +3358,26 @@ print_rt_sigprocmask(CPUArchState *cpu_env, const
struct syscallname *name,
case TARGET_SIG_SETMASK: how = "SIG_SETMASK"; break;
}
qemu_log("%s,", how);
-print_pointer(arg1, 0);
-print_pointer(arg2, 0);
+print_target_sigset_t(arg1, arg3, 0);
+}
+
+static void
+print_rt_sigprocmask_ret(CPUArchState *cpu_env, const struct syscallname *name,
+ abi_long ret, abi_long arg0, abi_long arg1,
+ abi_long arg2, abi_long arg3, abi_long arg4,
+ abi_long arg5)
+{
+if (is_error(ret)) {
+print_pointer(arg2, 0);
+} else {
+print_target_sigset_t(arg2, arg3, 0);
+}
print_raw_param("%u", arg3, 1);
print_syscall_epilogue(name);
+if (!print_syscall_err(ret)) {
+qemu_log(TARGET_ABI_FMT_ld, ret);
+}
+qemu_log("\n");
}
#endif
diff --git a/linux-user/strace.list b/linux-user/strace.list
index 0d69fb3150d..fdf94ef32ad 100644
--- a/linux-user/strace.list
+++ b/linux-user/strace.list
@@ -1189,7 +1189,8 @@
{ TARGET_NR_rt_sigpending, "rt_sigpending" , NULL, NULL, NULL },
#endif
#ifdef TARGET_NR_rt_sigprocmask
-{ TARGET_NR_rt_sigprocmask, "rt_sigprocmask" , NULL, print_rt_sigprocmask,
NULL },
+{ TARGET_NR_rt_sigprocmask, "rt_sigprocmask" , NULL, print_rt_sigprocmask,
+print_rt_sigprocmask_ret },
#endif
#ifdef TARGET_NR_rt_sigqueueinfo
{ TARGET_NR_rt_sigqueueinfo, "rt_sigqueueinfo" , NULL, print_rt_sigqueueinfo,
NULL },
--
2.47.0
[PATCH] tcg/s390x: fix constraint for 32-bit TSTEQ/TSTNE
32-bit TSTEQ and TSTNE is subject to the same constraints as
for 64-bit, but setcond_i32 and negsetcond_i32 were incorrectly
using TCG_CT_CONST ("i") instead of TCG_CT_CONST_CMP ("C").
Adjust the constraint and make tcg_target_const_match use the
same sequence as tgen_cmp2: first check if the constant is a
valid operand for TSTEQ/TSTNE, then accept everything for 32-bit
non-test comparisons, finally check if the constant is a valid
operand for 64-bit non-test comparisons.
Reported-by: Philippe Mathieu-Daudé
Signed-off-by: Paolo Bonzini
---
tcg/s390x/tcg-target.c.inc | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/tcg/s390x/tcg-target.c.inc b/tcg/s390x/tcg-target.c.inc
index a5d57197a4b..27bccc14e50 100644
--- a/tcg/s390x/tcg-target.c.inc
+++ b/tcg/s390x/tcg-target.c.inc
@@ -565,6 +565,20 @@ static bool tcg_target_const_match(int64_t val, int ct,
}
if (ct & TCG_CT_CONST_CMP) {
+if (is_tst_cond(cond)) {
+if (is_const_p16(uval) >= 0) {
+return true; /* TMxx */
+}
+if (risbg_mask(uval)) {
+return true; /* RISBG */
+}
+return false;
+}
+
+if (type == TCG_TYPE_I32) {
+return true;
+}
+
switch (cond) {
case TCG_COND_EQ:
case TCG_COND_NE:
@@ -584,13 +598,7 @@ static bool tcg_target_const_match(int64_t val, int ct,
break;
case TCG_COND_TSTNE:
case TCG_COND_TSTEQ:
-if (is_const_p16(uval) >= 0) {
-return true; /* TMxx */
-}
-if (risbg_mask(uval)) {
-return true; /* RISBG */
-}
-break;
+/* checked above, fallthru */
default:
g_assert_not_reached();
}
@@ -3231,9 +3239,9 @@ static TCGConstraintSetIndex tcg_target_op_def(TCGOpcode
op)
case INDEX_op_rotl_i64:
case INDEX_op_rotr_i32:
case INDEX_op_rotr_i64:
+return C_O1_I2(r, r, ri);
case INDEX_op_setcond_i32:
case INDEX_op_negsetcond_i32:
-return C_O1_I2(r, r, ri);
case INDEX_op_setcond_i64:
case INDEX_op_negsetcond_i64:
return C_O1_I2(r, r, rC);
--
2.46.2
Re: [PULL 08/20] virtio-net: Add only one queue pair when realizing
On 17/10/2024 11:07, Akihiko Odaki wrote:
On 2024/10/17 16:32, Laurent Vivier wrote:
On 17/10/2024 08:59, Jason Wang wrote:
On Mon, Oct 14, 2024 at 11:16 PM Laurent Vivier wrote:
On 14/10/2024 10:30, Laurent Vivier wrote:
Hi Akihiko,
On 04/06/2024 09:37, Jason Wang wrote:
From: Akihiko Odaki
Multiqueue usage is not negotiated yet when realizing. If more than
one queue is added and the guest never requests to enable multiqueue,
the extra queues will not be deleted when unrealizing and leak.
Fixes: f9d6dbf0bf6e ("virtio-net: remove virtio queues if the guest doesn't
support
multiqueue")
Signed-off-by: Akihiko Odaki
Signed-off-by: Jason Wang
---
hw/net/virtio-net.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 3cee2ef3ac..a8db8bfd9c 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -3743,9 +3743,7 @@ static void virtio_net_device_realize(DeviceState *dev, Error
**errp)
n->net_conf.tx_queue_size = MIN(virtio_net_max_tx_queue_size(n),
n->net_conf.tx_queue_size);
- for (i = 0; i < n->max_queue_pairs; i++) {
- virtio_net_add_queue(n, i);
- }
+ virtio_net_add_queue(n, 0);
n->ctrl_vq = virtio_add_queue(vdev, 64, virtio_net_handle_ctrl);
qemu_macaddr_default_if_unset(&n->nic_conf.macaddr);
This change breaks virtio net migration when multiqueue is enabled.
I think this is because virtqueues are half initialized after migration : they
are
initialized on guest side (kernel is using them) but not on QEMU side (realized
has only
initialized one). After migration, they are not initialized by the call to
virtio_net_set_multiqueue() from virtio_net_set_features() because
virtio_get_num_queues()
reports already n->max_queue_pairs as this value is coming from the source
guest memory.
I don't think we have a way to half-initialize a virtqueue (to initialize them
only on
QEMU side as they are already initialized on kernel side).
I think this change should be reverted to fix the migration issue.
Moreover, if I look in the code of virtio_load() and virtio_add_queue() we can
guess it's
not correct to migrate a virtqueue that is not initialized on the destination side
because
fields like 'vdev->vq[i].handle_output' or 'vdev->vq[i].used_elems' cannot be
initialized
by virtio_load() and neither by virtio_add_queue() after virtio_load() as
fields like
'vring.num' are already initialized by virtio_load().
For instance, in virtio_load() we set:
for (i = 0; i < num; i++) {
vdev->vq[i].vring.num = qemu_get_be32(f);
and in virtio_add_queue() we search for the firt available queue to add with:
for (i = 0; i < VIRTIO_QUEUE_MAX; i++) {
if (vdev->vq[i].vring.num == 0)
break;
}
So virtio_add_queue() cannot be used to set:
vdev->vq[i].handle_output = handle_output;
vdev->vq[i].used_elems = g_new0(VirtQueueElement, queue_size);
Moreover it would overwrite fields already set by virtio_load():
vdev->vq[i].vring.num = queue_size;
vdev->vq[i].vring.align = VIRTIO_PCI_VRING_ALIGN;
It also explains why virtio_net_change_num_queue_pairs() (indirectly called by
virtio_net_set_features()) doesn't update the queue pair numbers: vring.num is already
set
so it thinks there is no more queues to add.
Thanks,
LAurent
I agree.
Laurent, would you like to send a patch to revert this?
Yes. I will also try to fix the leak in unrealize that the patch wanted to fix
initially.
I wrote a fix so I will submit it once internal testing is done. You can see
the change at:
https://gitlab.com/akihiko.odaki/qemu-kvm/-/commit/22161221aa2d2031d7ad1be7701852083aa9109a
It works fine for me but I don't know if it's a good idea to add queues while the state is
loading.
Jason, let me know which solution you prefer (revert or pre_load_queues helper).
CC'ing MST
Thanks,
Laurent
Re: [PATCH] vhost-user: fix shared object return values
On Thu, Oct 17, 2024 at 11:12:32AM +0200, Albert Esteve wrote:
> On Thu, Oct 17, 2024 at 10:44 AM Daniel P. Berrangé
> wrote:
> >
> > On Wed, Oct 16, 2024 at 11:06:06AM +0200, Albert Esteve wrote:
> > > VHOST_USER_BACKEND_SHARED_OBJECT_ADD and
> > > VHOST_USER_BACKEND_SHARED_OBJECT_REMOVE state
> > > in the spec that they return 0 for successful
> > > operations, non-zero otherwise. However,
> > > implementation relies on the return types
> > > of the virtio-dmabuf library, with opposite
> > > semantics (true if everything is correct,
> > > false otherwise). Therefore, current implementaion
> > > violates the specification.
> > >
> > > Revert the logic so that the implementation
> > > of the vhost-user handling methods matches
> > > the specification.
> > >
> > > Fixes: 043e127a126bb3ceb5fc753deee27d261fd0c5ce
> > > Fixes: 160947666276c5b7f6bca4d746bcac2966635d79
> > > Signed-off-by: Albert Esteve
> > > ---
> > > hw/virtio/vhost-user.c | 8
> > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
> > > index 00561daa06..90917352a4 100644
> > > --- a/hw/virtio/vhost-user.c
> > > +++ b/hw/virtio/vhost-user.c
> > > @@ -1607,7 +1607,7 @@ vhost_user_backend_handle_shared_object_add(struct
> > > vhost_dev *dev,
> > > QemuUUID uuid;
> > >
> > > memcpy(uuid.data, object->uuid, sizeof(object->uuid));
> > > -return virtio_add_vhost_device(&uuid, dev);
> > > +return !virtio_add_vhost_device(&uuid, dev);
> > > }
> >
> > This virtio_add_vhost_device() method returns a bool, but this
> > vhost_user_backend_handle_shared_object_add() method returns
> > an int, but fills that int with an inverted bool value. The
> > caller then assigns the return value to an int, but then
> > interprets the int as a bool, and assigns that bool result
> > to an u64.
> >
> > This call chain is madness :-(
>
> TBF most of the madness is part of the already existing
> handling infrastructure.
> vhost_user_backend_handle_shared_object_add()
> returns an int to be consistent with other handling
> functions.
>
> >
> > Change vhost_user_backend_handle_shared_object_add to return
> > a bool to reduce the madness IMHO.
>
> Changing it to bool would make it inconsistent
> wrt other handlers, and the casting would happen nonetheless
> on assignment. Not sure if that is an improvement.
Well when the caller does
payload.u64 = !!ret;
it is saying that it only cares about the values
being 0 or 1. So how about just making these
methods return 0 or 1 then.
>
> >
> > >
> > > static int
> > > @@ -1623,16 +1623,16 @@
> > > vhost_user_backend_handle_shared_object_remove(struct vhost_dev *dev,
> > > struct vhost_dev *owner = virtio_lookup_vhost_device(&uuid);
> > > if (dev != owner) {
> > > /* Not allowed to remove non-owned entries */
> > > -return 0;
> > > +return -EPERM;
> > > }
> > > break;
> > > }
> > > default:
> > > /* Not allowed to remove non-owned entries */
> > > -return 0;
> > > +return -EPERM;
> > > }
> > >
> > > -return virtio_remove_resource(&uuid);
> > > +return !virtio_remove_resource(&uuid);
> > > }
> >
> > These return values are inconsistent.
> >
> > In some places you're returning a negative errno, but in this
> > last place you're returning true or false, by calling
> > virtio_remove_resource which is a 'bool' method & inverting it.
>
> Well, specification only distinguish between zero and non-zero values.
> But for clarity, I guess I could do something like:
> ```
> if (!virtio_remove_resource(&uuid)) {
> return -EINVAL;
> }
>
> return 0;
> ```
>
> Same for the vhost_user_backend_handle_shared_object_add()
> handler (in that case there is no inconsistency with positive or negative
> return values, but still better to maintain similar strategy for all
> handlers).
Returning an errno value, when the caller only wants 0 or 1 is
pointless.
With regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH] vhost-user: fix shared object return values
On Thu, Oct 17, 2024 at 11:18 AM Daniel P. Berrangé wrote:
>
> On Thu, Oct 17, 2024 at 11:12:32AM +0200, Albert Esteve wrote:
> > On Thu, Oct 17, 2024 at 10:44 AM Daniel P. Berrangé
> > wrote:
> > >
> > > On Wed, Oct 16, 2024 at 11:06:06AM +0200, Albert Esteve wrote:
> > > > VHOST_USER_BACKEND_SHARED_OBJECT_ADD and
> > > > VHOST_USER_BACKEND_SHARED_OBJECT_REMOVE state
> > > > in the spec that they return 0 for successful
> > > > operations, non-zero otherwise. However,
> > > > implementation relies on the return types
> > > > of the virtio-dmabuf library, with opposite
> > > > semantics (true if everything is correct,
> > > > false otherwise). Therefore, current implementaion
> > > > violates the specification.
> > > >
> > > > Revert the logic so that the implementation
> > > > of the vhost-user handling methods matches
> > > > the specification.
> > > >
> > > > Fixes: 043e127a126bb3ceb5fc753deee27d261fd0c5ce
> > > > Fixes: 160947666276c5b7f6bca4d746bcac2966635d79
> > > > Signed-off-by: Albert Esteve
> > > > ---
> > > > hw/virtio/vhost-user.c | 8
> > > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
> > > > index 00561daa06..90917352a4 100644
> > > > --- a/hw/virtio/vhost-user.c
> > > > +++ b/hw/virtio/vhost-user.c
> > > > @@ -1607,7 +1607,7 @@
> > > > vhost_user_backend_handle_shared_object_add(struct vhost_dev *dev,
> > > > QemuUUID uuid;
> > > >
> > > > memcpy(uuid.data, object->uuid, sizeof(object->uuid));
> > > > -return virtio_add_vhost_device(&uuid, dev);
> > > > +return !virtio_add_vhost_device(&uuid, dev);
> > > > }
> > >
> > > This virtio_add_vhost_device() method returns a bool, but this
> > > vhost_user_backend_handle_shared_object_add() method returns
> > > an int, but fills that int with an inverted bool value. The
> > > caller then assigns the return value to an int, but then
> > > interprets the int as a bool, and assigns that bool result
> > > to an u64.
> > >
> > > This call chain is madness :-(
> >
> > TBF most of the madness is part of the already existing
> > handling infrastructure.
> > vhost_user_backend_handle_shared_object_add()
> > returns an int to be consistent with other handling
> > functions.
> >
> > >
> > > Change vhost_user_backend_handle_shared_object_add to return
> > > a bool to reduce the madness IMHO.
> >
> > Changing it to bool would make it inconsistent
> > wrt other handlers, and the casting would happen nonetheless
> > on assignment. Not sure if that is an improvement.
>
> Well when the caller does
>
> payload.u64 = !!ret;
>
> it is saying that it only cares about the values
> being 0 or 1. So how about just making these
> methods return 0 or 1 then.
Ah, I see your point. I introduced negative error
values just because I saw other handlers doing
it (e.g., vhost_user_backend_handle_vring_host_notifier()).
>
> >
> > >
> > > >
> > > > static int
> > > > @@ -1623,16 +1623,16 @@
> > > > vhost_user_backend_handle_shared_object_remove(struct vhost_dev *dev,
> > > > struct vhost_dev *owner = virtio_lookup_vhost_device(&uuid);
> > > > if (dev != owner) {
> > > > /* Not allowed to remove non-owned entries */
> > > > -return 0;
> > > > +return -EPERM;
So you are suggesting here it could be `return 1;` instead?
It does not look clear enough that it is an error value.
Maybe I could create a define like:
#define EVHOST_USER 1
and use it here (and probably a good idea to change other
handling functions in a different commit, to be consistent).
WDYT?
BR,
Albert.
> > > > }
> > > > break;
> > > > }
> > > > default:
> > > > /* Not allowed to remove non-owned entries */
> > > > -return 0;
> > > > +return -EPERM;
> > > > }
> > > >
> > > > -return virtio_remove_resource(&uuid);
> > > > +return !virtio_remove_resource(&uuid);
> > > > }
> > >
> > > These return values are inconsistent.
> > >
> > > In some places you're returning a negative errno, but in this
> > > last place you're returning true or false, by calling
> > > virtio_remove_resource which is a 'bool' method & inverting it.
> >
> > Well, specification only distinguish between zero and non-zero values.
> > But for clarity, I guess I could do something like:
> > ```
> > if (!virtio_remove_resource(&uuid)) {
> > return -EINVAL;
> > }
> >
> > return 0;
> > ```
> >
> > Same for the vhost_user_backend_handle_shared_object_add()
> > handler (in that case there is no inconsistency with positive or negative
> > return values, but still better to maintain similar strategy for all
> > handlers).
>
> Returning an errno value, when the caller only wants 0 or 1 is
> pointless.
>
> With regards,
> Daniel
> --
> |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangl
Re: [PATCH v2 1/5] hw/resettable: Add SOFT reset type
On Wed, 16 Oct 2024 at 22:24, Bernhard Beschow wrote:
>
> This is a preparation for the next patch.
>
> Signed-off-by: Bernhard Beschow
> ---
> include/hw/resettable.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/hw/resettable.h b/include/hw/resettable.h
> index fd862f1e9f..0f25beaf21 100644
> --- a/include/hw/resettable.h
> +++ b/include/hw/resettable.h
> @@ -40,6 +40,7 @@ typedef enum ResetType {
> RESET_TYPE_WAKEUP,
> RESET_TYPE_S390_CPU_INITIAL,
> RESET_TYPE_S390_CPU_NORMAL,
> +RESET_TYPE_SOFT,
> } ResetType;
We have in general been avoiding defining a "soft" reset
because it's not clear what the meaning of it should be
or how it applies across devices.
If we want to define a new ResetType then we need
to start with the documentation which says clearly
what the semantics of it should be and when it
will be triggered.
You might prefer to avoid entangling that with this
lan9118 refactoring.
thanks
-- PMM
Re: [PATCH v4 07/19] pc-bios/s390-ccw: Remove panics from ISO IPL path
On 17/10/2024 03.47, jro...@linux.ibm.com wrote:
From: Jared Rossi
Remove panic-on-error from IPL ISO El Torito specific functions so that error
recovery may be possible in the future.
Functions that would previously panic now provide a return code.
Signed-off-by: Jared Rossi
---
...
diff --git a/pc-bios/s390-ccw/bootmap.c b/pc-bios/s390-ccw/bootmap.c
index 414c3f1b47..5477cfe228 100644
--- a/pc-bios/s390-ccw/bootmap.c
+++ b/pc-bios/s390-ccw/bootmap.c
@@ -678,8 +678,10 @@ static bool is_iso_bc_entry_compatible(IsoBcSection *s)
if (s->unused || !s->sector_count) {
return false;
}
-read_iso_sector(bswap32(s->load_rba), magic_sec,
-"Failed to read image sector 0");
+if (virtio_read(bswap32(s->load_rba), magic_sec)) {
+puts("Failed to read image sector 0");
+return false;
+}
/* Checking bytes 8 - 32 for S390 Linux magic */
return !memcmp(magic_sec + 8, linux_s390_magic, 24);
@@ -692,28 +694,35 @@ static uint32_t sec_offset[ISO9660_MAX_DIR_DEPTH];
/* Remained directory space in bytes */
static uint32_t dir_rem[ISO9660_MAX_DIR_DEPTH];
-static inline uint32_t iso_get_file_size(uint32_t load_rba)
+static inline long iso_get_file_size(uint32_t load_rba)
{
IsoVolDesc *vd = (IsoVolDesc *)sec;
IsoDirHdr *cur_record = &vd->vd.primary.rootdir;
uint8_t *temp = sec + ISO_SECTOR_SIZE;
int level = 0;
-read_iso_sector(ISO_PRIMARY_VD_SECTOR, sec,
-"Failed to read ISO primary descriptor");
+if (virtio_read(ISO_PRIMARY_VD_SECTOR, sec)) {
+puts("Failed to read ISO primary descriptor");
+return -EIO;
+}
+
sec_loc[0] = iso_733_to_u32(cur_record->ext_loc);
dir_rem[0] = 0;
sec_offset[0] = 0;
while (level >= 0) {
-IPL_assert(sec_offset[level] <= ISO_SECTOR_SIZE,
- "Directory tree structure violation");
+if (sec_offset[level] > ISO_SECTOR_SIZE) {
+puts("Directory tree structure violation");
+return -EIO;
+}
cur_record = (IsoDirHdr *)(temp + sec_offset[level]);
if (sec_offset[level] == 0) {
-read_iso_sector(sec_loc[level], temp,
-"Failed to read ISO directory");
+if (virtio_read(sec_loc[level], temp)) {
+puts("Failed to read ISO directory");
+return -EIO;
+}
if (dir_rem[level] == 0) {
/* Skip self and parent records */
dir_rem[level] = iso_733_to_u32(cur_record->data_len) -
@@ -758,8 +767,10 @@ static inline uint32_t iso_get_file_size(uint32_t load_rba)
if (dir_rem[level] == 0) {
/* Nothing remaining */
level--;
-read_iso_sector(sec_loc[level], temp,
-"Failed to read ISO directory");
+if (virtio_read(sec_loc[level], temp)) {
+puts("Failed to read ISO directory");
+return -EIO;
+}
}
}
@@ -774,7 +785,7 @@ static void load_iso_bc_entry(IsoBcSection *load)
* is padded and ISO_SECTOR_SIZE bytes aligned
*/
uint32_t blks_to_load = bswap16(s.sector_count) >> ET_SECTOR_SHIFT;
-uint32_t real_size = iso_get_file_size(bswap32(s.load_rba));
+long real_size = iso_get_file_size(bswap32(s.load_rba));
if (real_size) {
/* Round up blocks to load */
I think this check should now be changed to "real_size > 0" ?
And in the "else" path, the function should return immediately?
Thomas
Re: [PATCH] vhost-user: fix shared object return values
On Wed, Oct 16, 2024 at 11:06:06AM +0200, Albert Esteve wrote:
VHOST_USER_BACKEND_SHARED_OBJECT_ADD and
VHOST_USER_BACKEND_SHARED_OBJECT_REMOVE state
in the spec that they return 0 for successful
operations, non-zero otherwise. However,
implementation relies on the return types
of the virtio-dmabuf library, with opposite
semantics (true if everything is correct,
false otherwise). Therefore, current implementaion
s/implementaion/implementation
I hadn't seen it ;-P found with:
./scripts/checkpatch.pl --strict --branch master..HEAD --codespell
violates the specification.
Revert the logic so that the implementation
of the vhost-user handling methods matches
the specification.
Fixes: 043e127a126bb3ceb5fc753deee27d261fd0c5ce
This is in from 9.0 ...
Fixes: 160947666276c5b7f6bca4d746bcac2966635d79
... and this from 8.2, so should we consider stable branches?
I think it depends if the backends are checking that return value.
Signed-off-by: Albert Esteve
---
hw/virtio/vhost-user.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
Thanks for the fix!
Reviewed-by: Stefano Garzarella
diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
index 00561daa06..90917352a4 100644
--- a/hw/virtio/vhost-user.c
+++ b/hw/virtio/vhost-user.c
@@ -1607,7 +1607,7 @@ vhost_user_backend_handle_shared_object_add(struct
vhost_dev *dev,
QemuUUID uuid;
memcpy(uuid.data, object->uuid, sizeof(object->uuid));
-return virtio_add_vhost_device(&uuid, dev);
+return !virtio_add_vhost_device(&uuid, dev);
}
static int
@@ -1623,16 +1623,16 @@ vhost_user_backend_handle_shared_object_remove(struct
vhost_dev *dev,
struct vhost_dev *owner = virtio_lookup_vhost_device(&uuid);
if (dev != owner) {
/* Not allowed to remove non-owned entries */
-return 0;
+return -EPERM;
}
break;
}
default:
/* Not allowed to remove non-owned entries */
-return 0;
+return -EPERM;
}
-return virtio_remove_resource(&uuid);
+return !virtio_remove_resource(&uuid);
}
static bool vhost_user_send_resp(QIOChannel *ioc, VhostUserHeader *hdr,
--
2.46.1
Re: [PATCH v2 3/8] target/riscv: Implement Ssdbltrp exception handling
On 17/10/2024 06:29, Alistair Francis wrote:
> On Mon, Oct 14, 2024 at 5:43 PM Clément Léger wrote:
>>
>>
>>
>> On 11/10/2024 05:22, Alistair Francis wrote:
>>> On Wed, Sep 25, 2024 at 9:59 PM Clément Léger wrote:
When the Ssdbltrp ISA extension is enabled, if a trap happens in S-mode
while SSTATUS.SDT isn't cleared, generate a double trap exception to
M-mode.
Signed-off-by: Clément Léger
---
target/riscv/cpu.c| 2 +-
target/riscv/cpu_bits.h | 1 +
target/riscv/cpu_helper.c | 47 ++-
3 files changed, 43 insertions(+), 7 deletions(-)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index cf06cd741a..65347ccd5a 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -284,7 +284,7 @@ static const char * const riscv_excp_names[] = {
"load_page_fault",
"reserved",
"store_page_fault",
-"reserved",
+"double_trap",
"reserved",
"reserved",
"reserved",
diff --git a/target/riscv/cpu_bits.h b/target/riscv/cpu_bits.h
index 3a5588d4df..5557a86348 100644
--- a/target/riscv/cpu_bits.h
+++ b/target/riscv/cpu_bits.h
@@ -699,6 +699,7 @@ typedef enum RISCVException {
RISCV_EXCP_INST_PAGE_FAULT = 0xc, /* since: priv-1.10.0 */
RISCV_EXCP_LOAD_PAGE_FAULT = 0xd, /* since: priv-1.10.0 */
RISCV_EXCP_STORE_PAGE_FAULT = 0xf, /* since: priv-1.10.0 */
+RISCV_EXCP_DOUBLE_TRAP = 0x10,
RISCV_EXCP_SW_CHECK = 0x12, /* since: priv-1.13.0 */
RISCV_EXCP_HW_ERR = 0x13, /* since: priv-1.13.0 */
RISCV_EXCP_INST_GUEST_PAGE_FAULT = 0x14,
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index 395d8235ce..69da3c3384 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -575,7 +575,9 @@ void riscv_cpu_swap_hypervisor_regs(CPURISCVState *env)
mstatus_mask |= MSTATUS_FS;
}
bool current_virt = env->virt_enabled;
-
+if (riscv_env_smode_dbltrp_enabled(env, current_virt)) {
+mstatus_mask |= MSTATUS_SDT;
+}
g_assert(riscv_has_ext(env, RVH));
if (current_virt) {
@@ -1707,6 +1709,7 @@ void riscv_cpu_do_interrupt(CPUState *cs)
CPURISCVState *env = &cpu->env;
bool virt = env->virt_enabled;
bool write_gva = false;
+bool vsmode_exc;
uint64_t s;
int mode;
@@ -1721,6 +1724,8 @@ void riscv_cpu_do_interrupt(CPUState *cs)
!(env->mip & (1 << cause));
bool vs_injected = env->hvip & (1 << cause) & env->hvien &&
!(env->mip & (1 << cause));
+bool smode_double_trap = false;
+uint64_t hdeleg = async ? env->hideleg : env->hedeleg;
target_ulong tval = 0;
target_ulong tinst = 0;
target_ulong htval = 0;
@@ -1837,13 +1842,35 @@ void riscv_cpu_do_interrupt(CPUState *cs)
!async &&
mode == PRV_M;
+vsmode_exc = env->virt_enabled && (((hdeleg >> cause) & 1) ||
vs_injected);
+/*
+ * Check double trap condition only if already in S-mode and targeting
+ * S-mode
+ */
+if (cpu->cfg.ext_ssdbltrp && env->priv == PRV_S && mode == PRV_S) {
+bool dte = (env->menvcfg & MENVCFG_DTE) != 0;
+bool sdt = (env->mstatus & MSTATUS_SDT) != 0;
+/* In VS or HS */
+if (riscv_has_ext(env, RVH)) {
+if (vsmode_exc) {
+/* VS -> VS */
+/* Stay in VS mode, use henvcfg instead of menvcfg*/
+dte = (env->henvcfg & HENVCFG_DTE) != 0;
+} else if (env->virt_enabled) {
+/* VS -> HS */
+dte = false;
>>>
>>> I don't follow why this is false
>>
>> Hi Alistair,
>>
>> It's indeed probably lacking some comments here. The rationale is that
>> if you are trapping from VS to HS, then at some point, you returned to
>> VS using a sret/mret and thus cleared DTE, so rather than checking the
s/DTE/SDT
>
> Why not just clear it at sret/mret? Instead of having this assumption
It has been cleared but since registers were swapped to enter virt mode,
hypervisor SDT value is stored in mstatus_hs rather than mstatus. So I
could have wrote it this way:
+} else if (env->virt_enabled) {
+/* VS -> HS */
+sdt = (env->mstatus_hs & MSTATUS_SDT);
Since this is always 0 better assume it is 0 (but should be sdt = 0
instead of dte = 0). But if you prefer using mstatus_hs for clarity, I
can use that of course.
Clément
>
> Alistair
>
>> value of mstatus_hs, just assume it is false.
>>
>> Thanks,
>>
>> Clément
>>
>>>
>>> Alistair
>>
Re: [PATCH] crypto/hash-afalg: Fix broken build
Cédric Le Goater writes: > On 10/17/24 08:47, Markus Armbruster wrote: >> Fux build broken by semantic conflict with commit >> 8f525028bc6 (qapi/crypto: Rename QCryptoAFAlg to QCryptoAFAlgo). >> Fixes: 90c3dc60735a (crypto/hash-afalg: Implement new hash API) >> Signed-off-by: Markus Armbruster > > My bad :/ Obviously, I didn't catch this at compile time, nor did CI. Not blaming you; this is something CI should catch. How could we close the CI gap? > Reviewed-by: Cédric Le Goater Thanks!
RE: [PATCH v2] intel_iommu: Introduce property "x-stale-tm" to control Transient Mapping (TM) field
>-Original Message-
>From: Jason Wang
>Subject: Re: [PATCH v2] intel_iommu: Introduce property "x-stale-tm" to control
>Transient Mapping (TM) field
>
>On Thu, Oct 10, 2024 at 3:57 PM Zhenzhong Duan
>wrote:
>>
>> VT-d spec removed Transient Mapping (TM) field from second-level page-tables
>> and treat the field as Reserved(0) since revision 3.2.
>>
>> Changing the field as reserved(0) will break backward compatibility, so
>> introduce a property "x-stale-tm" to allow user to control the setting.
>
>Nit: I think we probably don't need the x prefix? As we try to
>maintain the compatibility via:
>
>> +{ TYPE_INTEL_IOMMU_DEVICE, "x-stale-tm", "on" },
>
>?
I'm fine to remove it. But,
The prefix "x-" is used to indicate that a feature is experimental.
Couldn't we have a property both experimental and compatible?
I see a lot of such properties:
# grep "x-" /sdb/qemu/hw/i386/pc.c
{ "ICH9-LPC", "x-smi-swsmi-timer", "off" },
{ "ICH9-LPC", "x-smi-periodic-timer", "off" },
{ TYPE_INTEL_IOMMU_DEVICE, "x-stale-tm", "on" },
{ TYPE_X86_CPU, "x-amd-topoext-features-only", "false" },
{ TYPE_X86_CPU, "x-l1-cache-per-thread", "false" },
{ "ICH9-LPC", "x-keep-pci-slot-hpc", "false" },
{ TYPE_X86_CPU, "x-vendor-cpuid-only", "off" },
{ "ICH9-LPC", "x-keep-pci-slot-hpc", "true" },
{ "ICH9-LPC", "x-smi-cpu-hotunplug", "off" },
{ "ICH9-LPC", "x-smi-cpu-hotplug", "off" },
{ TYPE_X86_CPU, "x-intel-pt-auto-level", "off" },
{ TYPE_X86_CPU, "x-hv-synic-kvm-only", "on" },
{ TYPE_X86_CPU, "x-migrate-smi-count", "off" },
{ TYPE_X86_CPU, "x-hv-max-vps", "0x40" },
{ "i440FX-pcihost", "x-pci-hole64-fix", "off" },
{ "q35-pcihost", "x-pci-hole64-fix", "off" },
{ "kvmclock", "x-mach-use-reliable-get-clock", "off" },
{ "ICH9-LPC", "x-smi-broadcast", "off" },
Thanks
Zhenzhong
Re: [PATCH] vhost-user: fix shared object return values
Albert Esteve
Senior Software Engineer
Red Hat
aest...@redhat.com
On Thu, Oct 17, 2024 at 9:38 AM Stefano Garzarella wrote:
>
> On Wed, Oct 16, 2024 at 11:06:06AM +0200, Albert Esteve wrote:
> >VHOST_USER_BACKEND_SHARED_OBJECT_ADD and
> >VHOST_USER_BACKEND_SHARED_OBJECT_REMOVE state
> >in the spec that they return 0 for successful
> >operations, non-zero otherwise. However,
> >implementation relies on the return types
> >of the virtio-dmabuf library, with opposite
> >semantics (true if everything is correct,
> >false otherwise). Therefore, current implementaion
>
> s/implementaion/implementation
>
> I hadn't seen it ;-P found with:
> ./scripts/checkpatch.pl --strict --branch master..HEAD --codespell
Never used the checkpatch script for spelling. Thanks!
>
> >violates the specification.
> >
> >Revert the logic so that the implementation
> >of the vhost-user handling methods matches
> >the specification.
> >
> >Fixes: 043e127a126bb3ceb5fc753deee27d261fd0c5ce
>
> This is in from 9.0 ...
>
> >Fixes: 160947666276c5b7f6bca4d746bcac2966635d79
>
> ... and this from 8.2, so should we consider stable branches?
You mean in addition to the commits already reflected here?
>
> I think it depends if the backends are checking that return value.
The return value is optional (requires VHOST_USER_NEED_REPLY),
and I am not aware of any backend using this feature so far,
in general. So iiuc, that'd mean no need to include stable, right?
Best,
Albert.
>
> >Signed-off-by: Albert Esteve
> >---
> > hw/virtio/vhost-user.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
>
> Thanks for the fix!
>
> Reviewed-by: Stefano Garzarella
>
> >
> >diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
> >index 00561daa06..90917352a4 100644
> >--- a/hw/virtio/vhost-user.c
> >+++ b/hw/virtio/vhost-user.c
> >@@ -1607,7 +1607,7 @@ vhost_user_backend_handle_shared_object_add(struct
> >vhost_dev *dev,
> > QemuUUID uuid;
> >
> > memcpy(uuid.data, object->uuid, sizeof(object->uuid));
> >-return virtio_add_vhost_device(&uuid, dev);
> >+return !virtio_add_vhost_device(&uuid, dev);
> > }
> >
> > static int
> >@@ -1623,16 +1623,16 @@
> >vhost_user_backend_handle_shared_object_remove(struct vhost_dev *dev,
> > struct vhost_dev *owner = virtio_lookup_vhost_device(&uuid);
> > if (dev != owner) {
> > /* Not allowed to remove non-owned entries */
> >-return 0;
> >+return -EPERM;
> > }
> > break;
> > }
> > default:
> > /* Not allowed to remove non-owned entries */
> >-return 0;
> >+return -EPERM;
> > }
> >
> >-return virtio_remove_resource(&uuid);
> >+return !virtio_remove_resource(&uuid);
> > }
> >
> > static bool vhost_user_send_resp(QIOChannel *ioc, VhostUserHeader *hdr,
> >--
> >2.46.1
> >
>
Re: [PATCH v3 1/8] target/riscv: Add Ssdbltrp CSRs handling
On 16/10/2024 11:40, LIU Zhiwei wrote:
>
> On 2024/10/14 19:22, Clément Léger wrote:
>> Add ext_ssdbltrp in RISCVCPUConfig and implement MSTATUS.SDT,
>> {H|M}ENVCFG.DTE and modify the availability of MTVAL2 based on the
>> presence of the Ssdbltrp ISA extension.
>>
>> Signed-off-by: Clément Léger
>> Reviewed-by: Alistair Francis
>> ---
>> target/riscv/cpu.h | 1 +
>> target/riscv/cpu_bits.h | 6 ++
>> target/riscv/cpu_cfg.h | 1 +
>> target/riscv/cpu_helper.c | 20 +
>> target/riscv/csr.c | 45 ++-
>> 5 files changed, 63 insertions(+), 10 deletions(-)
>>
>> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
>> index a84e719d3f..ee984bf270 100644
>> --- a/target/riscv/cpu.h
>> +++ b/target/riscv/cpu.h
>> @@ -553,6 +553,7 @@ void riscv_cpu_set_geilen(CPURISCVState *env,
>> target_ulong geilen);
>> bool riscv_cpu_vector_enabled(CPURISCVState *env);
>> void riscv_cpu_set_virt_enabled(CPURISCVState *env, bool enable);
>> int riscv_env_mmu_index(CPURISCVState *env, bool ifetch);
>> +bool riscv_env_smode_dbltrp_enabled(CPURISCVState *env, bool virt);
>> G_NORETURN void riscv_cpu_do_unaligned_access(CPUState *cs, vaddr
>> addr,
>> MMUAccessType
>> access_type,
>> int mmu_idx,
>> uintptr_t retaddr);
>> diff --git a/target/riscv/cpu_bits.h b/target/riscv/cpu_bits.h
>> index da1723496c..3a5588d4df 100644
>> --- a/target/riscv/cpu_bits.h
>> +++ b/target/riscv/cpu_bits.h
>> @@ -558,6 +558,7 @@
>> #define MSTATUS_TVM 0x0010 /* since: priv-1.10 */
>> #define MSTATUS_TW 0x0020 /* since: priv-1.10 */
>> #define MSTATUS_TSR 0x0040 /* since: priv-1.10 */
>> +#define MSTATUS_SDT 0x0100
>> #define MSTATUS_GVA 0x40ULL
>> #define MSTATUS_MPV 0x80ULL
>> @@ -588,6 +589,7 @@ typedef enum {
>> #define SSTATUS_XS 0x00018000
>> #define SSTATUS_SUM 0x0004 /* since: priv-1.10 */
>> #define SSTATUS_MXR 0x0008
>> +#define SSTATUS_SDT 0x0100
>> #define SSTATUS64_UXL 0x0003ULL
>> @@ -777,11 +779,13 @@ typedef enum RISCVException {
>> #define MENVCFG_CBIE (3UL << 4)
>> #define MENVCFG_CBCFE BIT(6)
>> #define MENVCFG_CBZE BIT(7)
>> +#define MENVCFG_DTE (1ULL << 59)
>> #define MENVCFG_ADUE (1ULL << 61)
>> #define MENVCFG_PBMTE (1ULL << 62)
>> #define MENVCFG_STCE (1ULL << 63)
>> /* For RV32 */
>> +#define MENVCFGH_DTE BIT(27)
>> #define MENVCFGH_ADUE BIT(29)
>> #define MENVCFGH_PBMTE BIT(30)
>> #define MENVCFGH_STCE BIT(31)
>> @@ -795,11 +799,13 @@ typedef enum RISCVException {
>> #define HENVCFG_CBIE MENVCFG_CBIE
>> #define HENVCFG_CBCFE MENVCFG_CBCFE
>> #define HENVCFG_CBZE MENVCFG_CBZE
>> +#define HENVCFG_DTE MENVCFG_DTE
>> #define HENVCFG_ADUE MENVCFG_ADUE
>> #define HENVCFG_PBMTE MENVCFG_PBMTE
>> #define HENVCFG_STCE MENVCFG_STCE
>> /* For RV32 */
>> +#define HENVCFGH_DTE MENVCFGH_DTE
>> #define HENVCFGH_ADUE MENVCFGH_ADUE
>> #define HENVCFGH_PBMTE MENVCFGH_PBMTE
>> #define HENVCFGH_STCE MENVCFGH_STCE
>> diff --git a/target/riscv/cpu_cfg.h b/target/riscv/cpu_cfg.h
>> index ae2a945b5f..dd804f95d4 100644
>> --- a/target/riscv/cpu_cfg.h
>> +++ b/target/riscv/cpu_cfg.h
>> @@ -77,6 +77,7 @@ struct RISCVCPUConfig {
>> bool ext_smstateen;
>> bool ext_sstc;
>> bool ext_smcntrpmf;
>> + bool ext_ssdbltrp;
>> bool ext_svadu;
>> bool ext_svinval;
>> bool ext_svnapot;
>> diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
>> index 9d0400035f..77e7736d8a 100644
>> --- a/target/riscv/cpu_helper.c
>> +++ b/target/riscv/cpu_helper.c
>> @@ -63,6 +63,22 @@ int riscv_env_mmu_index(CPURISCVState *env, bool
>> ifetch)
>> #endif
>> }
>> +bool riscv_env_smode_dbltrp_enabled(CPURISCVState *env, bool virt)
>> +{
>> +#ifdef CONFIG_USER_ONLY
>> + return false;
>> +#else
>> + if (!riscv_cpu_cfg(env)->ext_ssdbltrp) {
>> + return false;
>> + }
>
> As we have guard the write to henvcfg and menvcfg by ext_ssdbltrp, I
> think it is enough only check henvcfg or menvcfg.
>
> The only miss is we don't guard the writhe to henvcfgh. I think we can
> add the guard there.
Hi Liu,
Actually, since write_henvcfgh() uses mencvfg & (... | HENVCFG_DTE) as a
mask to write the value, if the MENVCFG_DTE bit is not set in menvcfg,
then i
Re: [PATCH v4 09/19] pc-bios/s390-ccw: Remove panics from SCSI IPL path
On 17/10/2024 03.47, jro...@linux.ibm.com wrote:
From: Jared Rossi
Remove panic-on-error from virtio-scsi IPL specific functions so that error
recovery may be possible in the future.
Functions that would previously panic now provide a return code.
Signed-off-by: Jared Rossi
---
pc-bios/s390-ccw/iplb.h | 2 +
pc-bios/s390-ccw/bootmap.c | 88 +-
pc-bios/s390-ccw/jump2ipl.c | 1 +
pc-bios/s390-ccw/main.c | 2 +-
pc-bios/s390-ccw/virtio-blkdev.c | 4 +-
pc-bios/s390-ccw/virtio-scsi.c | 147 +--
6 files changed, 172 insertions(+), 72 deletions(-)
diff --git a/pc-bios/s390-ccw/iplb.h b/pc-bios/s390-ccw/iplb.h
index 3758698468..639fa34919 100644
--- a/pc-bios/s390-ccw/iplb.h
+++ b/pc-bios/s390-ccw/iplb.h
@@ -94,6 +94,8 @@ struct QemuIplParameters {
typedef struct QemuIplParameters QemuIplParameters;
extern QemuIplParameters qipl;
+extern IplParameterBlock iplb __attribute__((__aligned__(PAGE_SIZE)));
+extern bool have_iplb;
Why do you move these to the header file now here? You don't seem to be
using these in this patch? Should it be done in a later patch?
Also the "extern IplParameterBlock iplb" is already available in this header
file, no need to add it again.
...
diff --git a/pc-bios/s390-ccw/virtio-scsi.c b/pc-bios/s390-ccw/virtio-scsi.c
index 6b4a1caf8a..32fa81a247 100644
--- a/pc-bios/s390-ccw/virtio-scsi.c
+++ b/pc-bios/s390-ccw/virtio-scsi.c
@@ -26,7 +26,7 @@ static uint8_t scsi_inquiry_std_response[256];
static ScsiInquiryEvpdPages scsi_inquiry_evpd_pages_response;
static ScsiInquiryEvpdBl scsi_inquiry_evpd_bl_response;
-static inline void vs_assert(bool term, const char **msgs)
+static inline bool vs_assert(bool term, const char **msgs)
{
if (!term) {
int i = 0;
@@ -35,11 +35,13 @@ static inline void vs_assert(bool term, const char **msgs)
while (msgs[i]) {
printf("%s", msgs[i++]);
}
-panic(" !\n");
+puts(" !");
}
+
+return term;
}
-static void virtio_scsi_verify_response(VirtioScsiCmdResp *resp,
+static bool virtio_scsi_verify_response(VirtioScsiCmdResp *resp,
const char *title)
{
const char *mr[] = {
@@ -56,8 +58,12 @@ static void virtio_scsi_verify_response(VirtioScsiCmdResp
*resp,
0
};
-vs_assert(resp->response == VIRTIO_SCSI_S_OK, mr);
-vs_assert(resp->status == CDB_STATUS_GOOD, ms);
+if (!vs_assert(resp->response == VIRTIO_SCSI_S_OK, mr) ||
+!vs_assert(resp->status == CDB_STATUS_GOOD, ms)) {
+return false;
+}
+
+return true;
Could be simplified to:
return vs_assert(resp->response == VIRTIO_SCSI_S_OK, mr) &&
vs_assert(resp->status == CDB_STATUS_GOOD, ms);
}
...
@@ -110,12 +123,13 @@ static bool scsi_inquiry(VDev *vdev, uint8_t evpd,
uint8_t page,
{ data, data_size, VRING_DESC_F_WRITE },
};
-vs_run("inquiry", inquiry, vdev, &cdb, sizeof(cdb), data, data_size);
+int ret = vs_run("inquiry", inquiry,
+vdev, &cdb, sizeof(cdb), data, data_size);
Please indent the second line with the "(" in the previous line.
-return virtio_scsi_response_ok(&resp);
+return ret ? ret : virtio_scsi_response_ok(&resp);
}
...
if (r->lun_list_len == 0) {
printf("no LUNs for target 0x%X\n", target);
continue;
@@ -283,7 +306,9 @@ int virtio_scsi_read_many(VDev *vdev,
data_size = sector_count * virtio_get_block_size() * f;
if (!scsi_read_10(vdev, sector * f, sector_count * f, load_addr,
data_size)) {
-virtio_scsi_verify_response(&resp, "virtio-scsi:read_many");
+if (!virtio_scsi_verify_response(&resp, "virtio-scsi:read_many")) {
+return 1;
+}
}
load_addr += data_size;
sector += sector_count;
@@ -352,11 +377,16 @@ static int virtio_scsi_setup(VDev *vdev)
uint8_t code = resp.sense[0] & SCSI_SENSE_CODE_MASK;
uint8_t sense_key = resp.sense[2] & SCSI_SENSE_KEY_MASK;
-IPL_assert(resp.sense_len != 0, "virtio-scsi:setup: no SENSE data");
+if (resp.sense_len == 0) {
+puts("virtio-scsi: setup: no SENSE data");
+return -EINVAL;
+}
-IPL_assert(retry_test_unit_ready && code == 0x70 &&
- sense_key == SCSI_SENSE_KEY_UNIT_ATTENTION,
- "virtio-scsi:setup: cannot retry");
+if (!retry_test_unit_ready || code != 0x70 ||
+ sense_key != SCSI_SENSE_KEY_UNIT_ATTENTION) {
+puts("virtio-scsi:setup: cannot retry");
+return -EIO;
+}
/* retry on CHECK_CONDITION/UNIT_ATTENTION as it
* may not designate a real error, but it may
Re: [PATCH] tcg/s390x: fix constraint for 32-bit TSTEQ/TSTNE
On 10/17/24 12:00, Peter Maydell wrote:
On Thu, 17 Oct 2024 at 10:14, Paolo Bonzini wrote:
32-bit TSTEQ and TSTNE is subject to the same constraints as
for 64-bit, but setcond_i32 and negsetcond_i32 were incorrectly
using TCG_CT_CONST ("i") instead of TCG_CT_CONST_CMP ("C").
Adjust the constraint and make tcg_target_const_match use the
same sequence as tgen_cmp2: first check if the constant is a
valid operand for TSTEQ/TSTNE, then accept everything for 32-bit
non-test comparisons, finally check if the constant is a valid
operand for 64-bit non-test comparisons.
Reported-by: Philippe Mathieu-Daudé
Signed-off-by: Paolo Bonzini
Should this cc stable? Does it cause any current problems?
(AIUI the x86 target changes in your pending pullreq do
trigger this.)
Yeah, that's a good idea. It's probably possible to construct x86 code
that triggers it (I'm surprised it wasn't found until now).
Paolo
[PATCH v2] hw/riscv: Add Microblaze V 32bit virt board
Add a basic board with interrupt controller (intc), timer, serial (uartlite), small memory called LMB@0 (128kB) and DDR@0x8000 (configured via command line eg. -m 2g). This is basic configuration which matches HW generated out of AMD Vivado (design tools). But initial configuration is going beyond what it is configured by default because validation should be done on other configurations too. That's why wire also additional uart16500, axi ethernet(with axi dma). GPIOs, i2c and qspi is also listed for completeness. IRQ map is: (addr) 0 - timer (0x41c0) 1 - uartlite (0x4060) 2 - i2c (0x4080) 3 - qspi (0x44a0) 4 - uart16550 (0x44a1) 5 - emaclite (0x40e0) 6 - timer2 (0x41c1) 7 - axi emac (0x40c0) 8 - axi dma (0x41e0) 9 - axi dma 10 - gpio (0x4000) 11 - gpio2 (0x4001) 12 - gpio3 (0x4002) Signed-off-by: Sai Pavan Boddu Signed-off-by: Michal Simek --- Changes for V2: Make changes to support -cpu switch Remove setting of default board Include doc to toctree Remove setting of 'imac' extensions as they are available by default. MAINTAINERS | 6 + docs/system/riscv/microblaze-v-virt.rst | 39 + docs/system/target-riscv.rst| 1 + hw/riscv/microblaze-v-virt.c| 181 hw/riscv/Kconfig| 8 ++ hw/riscv/meson.build| 1 + 6 files changed, 236 insertions(+) create mode 100644 docs/system/riscv/microblaze-v-virt.rst create mode 100644 hw/riscv/microblaze-v-virt.c diff --git a/MAINTAINERS b/MAINTAINERS index d7a11fe6017..b104b6d0f7f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1274,6 +1274,12 @@ M: Edgar E. Iglesias S: Maintained F: hw/microblaze/petalogix_ml605_mmu.c +amd-microblaze-v-virt +M: Sai Pavan Boddu +S: Maintained +F: hw/riscv/microblaze-v-virt.c +F: docs/system/riscv/microblaze-v-virt.rst + MIPS Machines - Overall MIPS Machines diff --git a/docs/system/riscv/microblaze-v-virt.rst b/docs/system/riscv/microblaze-v-virt.rst new file mode 100644 index 000..d2ad6a60266 --- /dev/null +++ b/docs/system/riscv/microblaze-v-virt.rst @@ -0,0 +1,39 @@ +Microblaze-V virt board (``amd-microblaze-v-virt``) +=== +The AMD MicroBlaze™ V processor is a soft-core RISC-V processor IP for AMD adaptive SoCs and FPGAs. +The MicroBlaze V processor is based on a 32-bit RISC-V instruction set architecture (ISA). + +More details here: +https://docs.amd.com/r/en-US/ug1629-microblaze-v-user-guide/MicroBlaze-V-Architecture + +The microblaze-v virt board in QEMU is a virtual board with +following supported devices + +Implemented CPU cores: + +1 RISCV32 core + +Implemented devices: + +- timer +- uartlite +- uart16550 +- emaclite +- timer2 +- axi emac +- axi dma + +Running +""" +Running U-boot + +.. code-block:: bash + + + $ qemu-system-riscv32 -M amd-microblaze-v-virt \ + -display none \ + -device loader,addr=0x8000,file=u-boot-spl.bin,cpu-num=0 \ + -device loader,addr=0x8020,file=u-boot.img \ + -serial mon:stdio \ + -device loader,addr=0x8300,file=system.dtb \ + -m 2g diff --git a/docs/system/target-riscv.rst b/docs/system/target-riscv.rst index ba195f1518a..cd5c5ce1883 100644 --- a/docs/system/target-riscv.rst +++ b/docs/system/target-riscv.rst @@ -66,6 +66,7 @@ undocumented; you can get a complete list by running .. toctree:: :maxdepth: 1 + riscv/microblaze-v-virt riscv/microchip-icicle-kit riscv/shakti-c riscv/sifive_u diff --git a/hw/riscv/microblaze-v-virt.c b/hw/riscv/microblaze-v-virt.c new file mode 100644 index 000..6603e6d6b06 --- /dev/null +++ b/hw/riscv/microblaze-v-virt.c @@ -0,0 +1,181 @@ +/* + * QEMU model of Microblaze V (32bit version) + * + * based on hw/microblaze/petalogix_ml605_mmu.c + * + * Copyright (c) 2011 Michal Simek + * Copyright (c) 2011 PetaLogix + * Copyright (c) 2009 Edgar E. Iglesias. + * Copyright (C) 2024, Advanced Micro Devices, Inc. + * SPDX-License-Identifier: GPL-2.0-or-later + * Written by Sai Pavan Boddu + * and by Michal Simek . + */ + +#include "qemu/osdep.h" +#include "qemu/units.h" +#include "qapi/error.h" +#include "cpu.h" +#include "hw/sysbus.h" +#include "sysemu/sysemu.h" +#include "net/net.h" +#include "hw/boards.h" +#include "hw/char/serial-mm.h" +#include "exec/address-spaces.h" +#include "hw/char/xilinx_uartlite.h" +#include "hw/misc/unimp.h" + +#define LMB_BRAM_SIZE (128 * KiB) +#define MEMORY_BASEADDR 0x8000 +#define INTC_BASEADDR 0x4120 +#define TIMER_BASEADDR 0x41c0 +#define TIMER_BASEADDR2 0x41c1 +#define UARTLITE_BASEADDR 0x4060 +#define ETHLITE_BASEADDR 0x40e0 +#define UART16550_BASEADDR 0x44a1 +#define AXIENET_BASEADDR 0x40c0 +#define AXIDMA_BASEADDR 0x41e0 +#define GPIO_BASEADDR 0x4000 +#define GPIO_BASEADDR2 0x4001 +#define GPIO_BASEADDR3 0x4002 +#def
Re: [PATCH v2] tests/functional: Convert most Aspeed machine tests
On 17/10/2024 09.09, Cédric Le Goater wrote:
On 10/17/24 08:06, Thomas Huth wrote:
On 16/10/2024 22.38, Cédric Le Goater wrote:
This is a simple conversion of the tests with some cleanups and
adjustments to match the new test framework. Replace the zephyr image
MD5 hashes with SHA256 hashes while at it.
The SDK tests depend on a ssh class from avocado.utils which is
difficult to replace. To be addressed separately.
Signed-off-by: Cédric Le Goater
...
- @skipUnless(*has_cmd('swtpm'))
- def test_arm_ast2600_evb_buildroot_tpm(self):
- """
- :avocado: tags=arch:arm
- :avocado: tags=machine:ast2600-evb
- """
-
- image_url = ('https://github.com/legoater/qemu-aspeed-boot/raw/
master/'
- 'images/ast2600-evb/buildroot-2023.02-tpm/flash.img')
- image_hash =
('a46009ae8a5403a0826d607215e731a8c68d27c14c41e55331706b8f9c7bd997')
- image_path = self.fetch_asset(image_url, asset_hash=image_hash,
- algorithm='sha256')
-
- # force creation of VM object, which also defines self._sd
- vm = self.vm
-
- socket = os.path.join(self._sd.name, 'swtpm-socket')
-
- subprocess.run(['swtpm', 'socket', '-d', '--tpm2',
- '--tpmstate', f'dir={self.vm.temp_dir}',
- '--ctrl', f'type=unixio,path={socket}'])
-
- self.vm.add_args('-chardev', f'socket,id=chrtpm,path={socket}')
- self.vm.add_args('-tpmdev', 'emulator,id=tpm0,chardev=chrtpm')
- self.vm.add_args('-device',
- 'tpm-tis-
i2c,tpmdev=tpm0,bus=aspeed.i2c.bus.12,address=0x2e')
- self.do_test_arm_aspeed_buildroot_start(image_path, '0xf00',
'Aspeed AST2600 EVB')
-
- exec_command_and_wait_for_pattern(self,
- 'echo tpm_tis_i2c 0x2e > /sys/bus/i2c/devices/i2c-12/
new_device',
- 'tpm_tis_i2c 12-002e: 2.0 TPM (device-id 0x1, rev-id 1)');
- exec_command_and_wait_for_pattern(self,
- 'cat /sys/class/tpm/tpm0/pcr-sha256/0',
-
'B804724EA13F52A9072BA87FE8FDCC497DFC9DF9AA15B9088694639C431688E0');
-
- self.do_test_arm_aspeed_buildroot_poweroff()
class AST2x00MachineSDK(QemuSystemTest, LinuxSSHMixIn):
You also copied AST2x00MachineMMC but you didn't remove it from the
avocado test yet, so there is a hunk missing here, I think?
oh. yes, I should remove it from the avocado test.
I was initially hesitating on having multiple test_arm_aspeed.py files:
one per machine or one per fw image type. This to set the timeout more
precisely in the meson.build file, since the SDK FW takes longer to
boot, and also to handle more complex test scenarios, like the SDK.
What would be your recommandation ?
If the tests do not share anything at all (neither common python code, nor
the same firmware binary asset), I think it's maybe better to put them into
separate files, indeed. That way we can also run the tests in parallel when
you add "-j$(nproc)" to your "make check-functional" line.
Btw, I have been trying to rewrite the LinuxSSHMixIn class with a
minimal ssh Session class. It is not trivial :/
:-(
Did you peek at tests/vm/basevm.py ? I was hoping we could lent some code
there...
...
+ def test_ast1030_zephyros_1_04(self):
+ kernel_name = "ast1030-evb-demo/zephyr.elf"
+ zip_file = self.ASSET_ZEPHYR_1_04.fetch()
+ with ZipFile(zip_file, 'r') as zf:
+ zf.extract(kernel_name, path=self.workdir)
+ kernel_file = os.path.join(self.workdir, kernel_name)
+
+ self.set_machine('ast1030-evb')
It's slightly better to do the set_machine() at the very top of the
function. set_machine() can cancel the test in case the machine is not
available in the QEMU binary, so this should best be done before fetching
and extracting any assets.
Should set_machine() be the first call of a test function ?
Yes, either set_machine() or require_netdev() should be at the very top,
since they could cancel the test.
Thomas
Re: [PATCH] crypto/hash-afalg: Fix broken build
On Thu, Oct 17, 2024 at 08:54:04AM +0200, Cédric Le Goater wrote:
> On 10/17/24 08:47, Markus Armbruster wrote:
> > Fux build broken by semantic conflict with commit
> > 8f525028bc6 (qapi/crypto: Rename QCryptoAFAlg to QCryptoAFAlgo).
> >
> > Fixes: 90c3dc60735a (crypto/hash-afalg: Implement new hash API)
> > Signed-off-by: Markus Armbruster
>
> My bad :/ Obviously, I didn't catch this at compile time, nor did CI.
Yeah, this is a clear gap in our CI that I will post a patch for.
> Reviewed-by: Cédric Le Goater
Reviewed-by: Daniel P. Berrangé
>
> Thanks,
>
> C.
>
>
> > ---
> > crypto/hash-afalg.c | 10 +-
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/crypto/hash-afalg.c b/crypto/hash-afalg.c
> > index 06e1e4699c..8c0ce5b520 100644
> > --- a/crypto/hash-afalg.c
> > +++ b/crypto/hash-afalg.c
> > @@ -142,7 +142,7 @@ QCryptoHash *qcrypto_afalg_hash_new(QCryptoHashAlgo
> > alg, Error **errp)
> > static
> > void qcrypto_afalg_hash_free(QCryptoHash *hash)
> > {
> > -QCryptoAFAlg *ctx = hash->opaque;
> > +QCryptoAFAlgo *ctx = hash->opaque;
> > if (ctx) {
> > qcrypto_afalg_comm_free(ctx);
> > @@ -159,7 +159,7 @@ void qcrypto_afalg_hash_free(QCryptoHash *hash)
> >* be provided to calculate the final hash.
> >*/
> > static
> > -int qcrypto_afalg_send_to_kernel(QCryptoAFAlg *afalg,
> > +int qcrypto_afalg_send_to_kernel(QCryptoAFAlgo *afalg,
> >const struct iovec *iov,
> >size_t niov,
> >bool more_data,
> > @@ -183,7 +183,7 @@ int qcrypto_afalg_send_to_kernel(QCryptoAFAlg *afalg,
> > }
> > static
> > -int qcrypto_afalg_recv_from_kernel(QCryptoAFAlg *afalg,
> > +int qcrypto_afalg_recv_from_kernel(QCryptoAFAlgo *afalg,
> > QCryptoHashAlgo alg,
> > uint8_t **result,
> > size_t *result_len,
> > @@ -222,7 +222,7 @@ int qcrypto_afalg_hash_update(QCryptoHash *hash,
> > size_t niov,
> > Error **errp)
> > {
> > -return qcrypto_afalg_send_to_kernel((QCryptoAFAlg *) hash->opaque,
> > +return qcrypto_afalg_send_to_kernel((QCryptoAFAlgo *) hash->opaque,
> > iov, niov, true, errp);
> > }
> > @@ -232,7 +232,7 @@ int qcrypto_afalg_hash_finalize(QCryptoHash *hash,
> >size_t *result_len,
> >Error **errp)
> > {
> > -return qcrypto_afalg_recv_from_kernel((QCryptoAFAlg *) hash->opaque,
> > +return qcrypto_afalg_recv_from_kernel((QCryptoAFAlgo *) hash->opaque,
> > hash->alg, result, result_len,
> > errp);
> > }
>
>
With regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH v6] i386/cpu: fixup number of addressable IDs for logical processors in the physical package
On 10/14/2024 11:36 AM, Zhao Liu wrote: On 10/9/2024 11:56 AM, Chuang Xu wrote: When QEMU is started with: -cpu host,migratable=on,host-cache-info=on,l3-cache=off -smp 180,sockets=2,dies=1,cores=45,threads=2 On Intel platform: CPUID.01H.EBX[23:16] is defined as "max number of addressable IDs for logical processors in the physical package". When executing "cpuid -1 -l 1 -r" in the guest, we obtain a value of 90 for CPUID.01H.EBX[23:16], whereas the expected value is 128. Additionally, executing "cpuid -1 -l 4 -r" in the guest yields a value of 63 for CPUID.04H.EAX[31:26], which matches the expected result. As (1+CPUID.04H.EAX[31:26]) rounds up to the nearest power-of-2 integer, we'd beter round up CPUID.01H.EBX[23:16] to the nearest power-of-2 integer too. Otherwise we may encounter unexpected results in guest. For example, when QEMU is started with CLI above and xtopology is disabled, guest kernel 5.15.120 uses CPUID.01H.EBX[23:16]/ (1+CPUID.04H.EAX[31:26]) to calculate threads-per-core in detect_ht(). Then guest will get "90/ (1+63)=1" as the result, even though threads-per-core should actually be 2. It's kernel's bug instead. In 1.5.3 "Sub ID Extraction Parameters for initial APIC ID" of "Intel 64 Architecture Processor Topology Enumeration" [1], it is - SMT_Mask_Width = Log2(RoundToNearestPof2(CPUID.1:EBX[23:16])/ (CPUID.(EAX=4,ECX=0):EAX[31:26]) + 1)) The value of CPUID.1:EBX[23:16] needs to be *rounded* to the neartest power-of-two integer instead of itself being the power-of-two. This also is consistency with the SDM, where the comment for bit 23-16 of CPUID.1:EBX is: The nearest power-of-2 integer that is not smaller than EBX[23:16] is the number of unique initial APIC IDs reserved for addressing different logical processors in a physical package. What I read from this is, the nearest power-of-2 integer that is not smaller than EBX[23:16] is a different thing than EBX[23:16]. i.e., Yes, when I read sdm, I also thought it was a kernel bug. But on my 192ht spr host, the value of CPUID.1:EBX[23:16] was indeed rounded up to the nearest power of 2 by the hardware. After communicating with Intel technical support staff, we thought that perhaps the description in sdm is not so accurate, and rounding up CPUID.1:EBX[23:16] to the power of 2 in qemu may be more in line with the hardware behavior. I think above justification is important. We need to justify our changes with the fact and correct reason. I somehow agree to set EBX[23:16] to a value of power-of-2, because the 1.5.3 "Sub ID Extraction Parameters for initial APIC ID" of "Intel 64 Architecture Processor Topology Enumeration" spec says CPUID.1:EBX[23:16] represents the maximum number of addressable IDs (initial APIC ID) that can be assigned to logical processors in a physical package. The value may not be the same as the number of logical processors that are present in the hardware of a physical package. It uses the word "may not". IMO, I don't quite understand your confusion regarding this. I've already explained the meaning of addressable ID, and the spec you referenced also clarifies its significance. The reason for this modification is not because of the two words "may not". Whether it is "be" or "not be" the same as the number of logical processors, the essence is that due to topology, the actual number of initial IDs that can be accommodated in the APIC ID may exceed the number of logical processors. I have the confusion because no matter from SDM: Bit 23-16: Maximum number of addressable IDs for logical processors in this physical package* * The nearest power-of-2 integer that is not smaller than EBX[23:16] is the number of unique initial APIC IDs reserved for addressing different logical processors in a physical package. or from "Intel 64 Architecture Processor Topology Enumeration" spec，(Jan 2018, revision 1.1), 1.5.3 "sub ID Extraction Parameters for Inital APIC ID" RoundToNearestPof2(CPUID.1:EBX[23:16]) or from "Intel 64 Architecture Processor Topology Enumeration" spec，(April 2023, revision 2.0), 1.6.1 Legacy Extraction Algorithm https://cdrdv2-public.intel.com/775917/intel-64-architecture-processor-topology-enumeration.pdf "MaximumLogicalProcessorIDsPerPackage" is calculated by rounding CPUID.01H.EBX[23:16] to nearest power of 2. what I read from them is that EBX[23:16] is a different thing than pow2ceil(EBX[23:16]) and EBX[23:16] doesn't need to be power-of-2, but the patch are trying to make it power-of-2. Then I consult it with Intel internal architect. I was told that EBX[23:16] used to be that software was to round to the next power of 2. However, software had issues a long time ago because applications could then compute the wrong power of 2 based on APIC ID holes or some applications would use it directly (without round it up to power-of-2). So intel became to report exact power-of-2 and this behavior is not docum
Re: [PATCH v4 2/2] tpm_emulator: Read control channel response in 2 passes
On Wed, Oct 16, 2024 at 01:51:29PM -0400, Stefan Berger wrote:
> Error responses from swtpm are typically only 4 bytes long with the
> exception of a few commands that return more bytes. Therefore, read the
> entire response in 2 steps and stop if the first few bytes indicate an
> error response with no subsequent bytes readable. Read the rest in a 2nd
> step, if needed. This avoids getting stuck while waiting for too many
> bytes in case of an error. The 'getting stuck' condition has not been
> observed in practice so far, though.
>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2615
> Signed-off-by: Stefan Berger
> ---
> backends/tpm/tpm_emulator.c | 61 +++--
> 1 file changed, 45 insertions(+), 16 deletions(-)
Reviewed-by: Daniel P. Berrangé
>
> diff --git a/backends/tpm/tpm_emulator.c b/backends/tpm/tpm_emulator.c
> index b0e2fb3fc7..8ad54f49a5 100644
> --- a/backends/tpm/tpm_emulator.c
> +++ b/backends/tpm/tpm_emulator.c
> @@ -123,12 +123,14 @@ static const char *tpm_emulator_strerror(uint32_t
> tpm_result)
> }
>
> static int tpm_emulator_ctrlcmd(TPMEmulator *tpm, unsigned long cmd, void
> *msg,
> -size_t msg_len_in, size_t msg_len_out)
> +size_t msg_len_in, size_t msg_len_out_err,
> +size_t msg_len_out_total)
> {
> CharBackend *dev = &tpm->ctrl_chr;
> uint32_t cmd_no = cpu_to_be32(cmd);
> ssize_t n = sizeof(uint32_t) + msg_len_in;
> uint8_t *buf = NULL;
> +ptm_res res;
>
> WITH_QEMU_LOCK_GUARD(&tpm->mutex) {
> buf = g_alloca(n);
> @@ -140,8 +142,24 @@ static int tpm_emulator_ctrlcmd(TPMEmulator *tpm,
> unsigned long cmd, void *msg,
> return -1;
> }
>
> -if (msg_len_out != 0) {
> -n = qemu_chr_fe_read_all(dev, msg, msg_len_out);
> +if (msg_len_out_total > 0) {
> +assert(msg_len_out_total >= msg_len_out_err);
> +
> +n = qemu_chr_fe_read_all(dev, (uint8_t *)msg, msg_len_out_err);
> +if (n <= 0) {
> +return -1;
> +}
> +if (msg_len_out_err == msg_len_out_total) {
> +return 0;
> +}
> +/* result error code is always in the first 4 bytes */
> +memcpy(&res, msg, sizeof(res));
Before this memcpy we need
assert(sizeof(res) <= msg_len_out_err);
to sanity-check we're not reading un-initialized memory in 'msg',
or worse, reading out of bounds.
With regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH] meson.build: Remove ncurses workaround for OpenBSD
Cc'ing qemu-trivial
On Fri, Oct 11, 2024 at 11:38:55PM -0400, Brad Smith wrote:
> meson.build: Remove ncurses workaround for OpenBSD
>
> OpenBSD 7.5 has upgraded to ncurses 6.4.
>
> Signed-off-by: Brad Smith
> ---
> meson.build | 2 +-
> ui/curses.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Daniel P. Berrangé
>
> diff --git a/meson.build b/meson.build
> index 4ea1984fc5..22e7629d81 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1374,7 +1374,7 @@ iconv = not_found
> curses = not_found
> if have_system and get_option('curses').allowed()
>curses_test = '''
> -#if defined(__APPLE__) || defined(__OpenBSD__)
> +#ifdef __APPLE__
> #define _XOPEN_SOURCE_EXTENDED 1
> #endif
> #include
> diff --git a/ui/curses.c b/ui/curses.c
> index ec61615f7c..4d0be9b37d 100644
> --- a/ui/curses.c
> +++ b/ui/curses.c
> @@ -38,7 +38,7 @@
> #include "ui/input.h"
> #include "sysemu/sysemu.h"
>
> -#if defined(__APPLE__) || defined(__OpenBSD__)
> +#ifdef __APPLE__
> #define _XOPEN_SOURCE_EXTENDED 1
> #endif
With regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH 0/1] Insert LibSPDM in QEMU enabling in-tree compilation
On Thu, Oct 17, 2024 at 02:00:35PM +1000, Alistair Francis wrote: > On Thu, Oct 17, 2024 at 2:35 AM htafr wrote: > > > > (I) Summary > > === > > > > This patch is the beginning of the support of the Security Protocol and > > Data Model (SPDM). There are some known issues (see II), but it's > > usable and not many users are going to use this functionality for now, > > but for those who will it may facilitate the development. > > > > There are some people working with LibSPDM to implement the SPDM on > > emulated devices, however current works that use QEMU compile LibSPDM > > out-of-tree [1][2][3]. This patch enables the compilation of LibSPDM when > > user pass the parameter '--enable-libspdm' to configure file, this option > > is disabled by default. The following parameters were also added: > > > > --libspdm-crypto=CHOICE set LibSPDM crypto algorithm [mbedtls] (choices: > >mbedtls/openssl) > > --libspdm-toolchain=VALUE > >toolchain to use for LibSPDM compilation [GCC] > > > > In order to facilitate future code development using LibSPDM API, this > > patch also provides the definition of the macro 'CONFIG_LIBSPDM'. > > We have talked about this before, see > https://patchew.org/QEMU/cover.1691509717.git.alistair.fran...@wdc.com/ > > The general agreement seemed to be that it will be hard to do SPDM > configuration inside QEMU, hence the external library (like the QEMU > TPM support). More generally, seeing this libspdm proposed for QEMU, without any corresponding usage of it it dubious. It is hard to judge whether it makes any sense, without seeing how it will be used in real device code inside QEMU. On the cryptography side, I'm not a fan of linking another crypto library to QEMU, that's different from what we already support in our crypto layer. openssl in particular is a problem due to its licensing - people tend to hand-waive away the licensing incompatibility by pretending openssl is a "system library" but I disagree with that interpretation. > > (II) Known Limitations > > === > > > > 1. This patch enables LibSPDM in-tree compilation for Linux systems only. > > 2. LibSPDM compilation uses CMake, so meson build system is making use > >of the CMake module [4]. > > 3. Some problems may occur when compiling LibSPDM with MbedTls such as: > > error: "_GNU_SOURCE" redefined [-Werror] > > 10 | #define _GNU_SOURCE > > > >It's possible to compile using --disable-werror. > > > > (III) Sample configuration > > === > > > > ../configure \ > > --disable-werror \ > > --enable-libspdm \ > > --libspdm-crypto=mbedtls \ > > --enable-gcov > > > > References: > > [1] riscv-spdm > > Link: https://github.com/htafr/riscv-spdm > > [2] spdm-benchmark > > Link: https://github.com/rcaalves/spdm-benchmark > > [3] qemu-spdm-emulation-guide > > Link: https://github.com/twilfredo/qemu-spdm-emulation-guide > > This one has been merged upstream and mainline QEMU supports it now: > > https://www.qemu.org/docs/master/specs/spdm.html So with that merged, is this proposal for linking to libspdm redundant ? With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH] tcg/s390x: fix constraint for 32-bit TSTEQ/TSTNE
On Thu, 17 Oct 2024 at 10:14, Paolo Bonzini wrote:
>
> 32-bit TSTEQ and TSTNE is subject to the same constraints as
> for 64-bit, but setcond_i32 and negsetcond_i32 were incorrectly
> using TCG_CT_CONST ("i") instead of TCG_CT_CONST_CMP ("C").
>
> Adjust the constraint and make tcg_target_const_match use the
> same sequence as tgen_cmp2: first check if the constant is a
> valid operand for TSTEQ/TSTNE, then accept everything for 32-bit
> non-test comparisons, finally check if the constant is a valid
> operand for 64-bit non-test comparisons.
>
> Reported-by: Philippe Mathieu-Daudé
> Signed-off-by: Paolo Bonzini
Should this cc stable? Does it cause any current problems?
(AIUI the x86 target changes in your pending pullreq do
trigger this.)
thanks
-- PMM
Re: [PATCH 10/16] rust: introduce alternative implementation of offset_of!
On Thu, Oct 17, 2024 at 7:35 AM Junjie Mao wrote:
> Paolo Bonzini writes:
> > offset_of! was stabilized in Rust 1.77.0. Use an alternative implemenation
> > that was found on the Rust forums, and whose author agreed to license as
> > MIT for use in QEMU.
> >
> > The alternative allows only one level of field access, but apart
> > from this can be used just by replacing core::mem::offset_of! with
> > qemu_api::offset_of!.
>
> How about a macro like this (which essentially comes from memoffset
> crate [1])? It has the same use as core::mem::offset_of! (except the
> same single-level limitation) and does not need wrapping structures with
> with_offsets!.
Unfortunately offset_from is not available in const context, and
offset_of! is needed to fill in the Property and VMStateDescription
arrays.
That said, I noticed now that declare_properties! does not declare the
resulting array as const, so that would be possible. But if
declare_properties could use a non-mut static, that would be better.
Paolo
> macro_rules! offset_of {
> ($parent:ty, $field:tt) => {{
> let uninit = std::mem::MaybeUninit::<$parent>::uninit();
> let base = uninit.as_ptr();
> // SAFETY:
> //
> // MaybeUninit<$parent> has the same size and alignment as $parent, so
> // projection to $field is in bound.
> //
> // addr_of! does not create intermediate references to the
> uninitialized
> // memory, thus no UB is involved.
> let field = unsafe { std::ptr::addr_of!((*base).$field) };
> // SAFETY:
> //
> // Both base and field point to the MaybeUninit<$parent> and are
> casted
> // to u8 for calculating their distance.
> unsafe { field.cast::().offset_from(base.cast::()) as usize }
> }};
> }
>
> [1] https://docs.rs/memoffset/latest/memoffset/
>
> --
> Best Regards
> Junjie Mao
>
Re: [PATCH] vhost-user: fix shared object return values
On Wed, Oct 16, 2024 at 11:06:06AM +0200, Albert Esteve wrote:
> VHOST_USER_BACKEND_SHARED_OBJECT_ADD and
> VHOST_USER_BACKEND_SHARED_OBJECT_REMOVE state
> in the spec that they return 0 for successful
> operations, non-zero otherwise. However,
> implementation relies on the return types
> of the virtio-dmabuf library, with opposite
> semantics (true if everything is correct,
> false otherwise). Therefore, current implementaion
> violates the specification.
>
> Revert the logic so that the implementation
> of the vhost-user handling methods matches
> the specification.
>
> Fixes: 043e127a126bb3ceb5fc753deee27d261fd0c5ce
> Fixes: 160947666276c5b7f6bca4d746bcac2966635d79
> Signed-off-by: Albert Esteve
> ---
> hw/virtio/vhost-user.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
> index 00561daa06..90917352a4 100644
> --- a/hw/virtio/vhost-user.c
> +++ b/hw/virtio/vhost-user.c
> @@ -1607,7 +1607,7 @@ vhost_user_backend_handle_shared_object_add(struct
> vhost_dev *dev,
> QemuUUID uuid;
>
> memcpy(uuid.data, object->uuid, sizeof(object->uuid));
> -return virtio_add_vhost_device(&uuid, dev);
> +return !virtio_add_vhost_device(&uuid, dev);
> }
This virtio_add_vhost_device() method returns a bool, but this
vhost_user_backend_handle_shared_object_add() method returns
an int, but fills that int with an inverted bool value. The
caller then assigns the return value to an int, but then
interprets the int as a bool, and assigns that bool result
to an u64.
This call chain is madness :-(
Change vhost_user_backend_handle_shared_object_add to return
a bool to reduce the madness IMHO.
>
> static int
> @@ -1623,16 +1623,16 @@ vhost_user_backend_handle_shared_object_remove(struct
> vhost_dev *dev,
> struct vhost_dev *owner = virtio_lookup_vhost_device(&uuid);
> if (dev != owner) {
> /* Not allowed to remove non-owned entries */
> -return 0;
> +return -EPERM;
> }
> break;
> }
> default:
> /* Not allowed to remove non-owned entries */
> -return 0;
> +return -EPERM;
> }
>
> -return virtio_remove_resource(&uuid);
> +return !virtio_remove_resource(&uuid);
> }
These return values are inconsistent.
In some places you're returning a negative errno, but in this
last place you're returning true or false, by calling
virtio_remove_resource which is a 'bool' method & inverting it.
On top of this inconsistency, it has all the same madness mentioneed
above.
With regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH v6] i386/cpu: fixup number of addressable IDs for logical processors in the physical package
On Thu, Oct 17, 2024 at 04:18:06PM +0800, Xiaoyao Li wrote: > Date: Thu, 17 Oct 2024 16:18:06 +0800 > From: Xiaoyao Li > Subject: Re: [PATCH v6] i386/cpu: fixup number of addressable IDs for > logical processors in the physical package > > On 10/14/2024 11:36 AM, Zhao Liu wrote: > > > > > On 10/9/2024 11:56 AM, Chuang Xu wrote: > > > > > > When QEMU is started with: > > > > > > -cpu host,migratable=on,host-cache-info=on,l3-cache=off > > > > > > -smp 180,sockets=2,dies=1,cores=45,threads=2 > > > > > > > > > > > > On Intel platform: > > > > > > CPUID.01H.EBX[23:16] is defined as "max number of addressable IDs > > > > > > for > > > > > > logical processors in the physical package". > > > > > > > > > > > > When executing "cpuid -1 -l 1 -r" in the guest, we obtain a > > > > > > value of 90 for > > > > > > CPUID.01H.EBX[23:16], whereas the expected value is 128. > > > > > > Additionally, > > > > > > executing "cpuid -1 -l 4 -r" in the guest yields a value of 63 for > > > > > > CPUID.04H.EAX[31:26], which matches the expected result. > > > > > > > > > > > > As (1+CPUID.04H.EAX[31:26]) rounds up to the nearest power-of-2 > > > > > > integer, > > > > > > we'd beter round up CPUID.01H.EBX[23:16] to the nearest power-of-2 > > > > > > integer too. Otherwise we may encounter unexpected results in guest. > > > > > > > > > > > > For example, when QEMU is started with CLI above and xtopology > > > > > > is disabled, > > > > > > guest kernel 5.15.120 uses CPUID.01H.EBX[23:16]/ > > > > > > (1+CPUID.04H.EAX[31:26]) to > > > > > > calculate threads-per-core in detect_ht(). Then guest will get > > > > > > "90/ (1+63)=1" > > > > > > as the result, even though threads-per-core should actually be 2. > > > > > > > > > > It's kernel's bug instead. > > > > > > > > > > In 1.5.3 "Sub ID Extraction Parameters for initial APIC ID" of > > > > > "Intel 64 Architecture Processor Topology Enumeration" [1], it is > > > > > > > > > > - SMT_Mask_Width = Log2(RoundToNearestPof2(CPUID.1:EBX[23:16])/ > > > > > (CPUID.(EAX=4,ECX=0):EAX[31:26]) + 1)) > > > > > > > > > > The value of CPUID.1:EBX[23:16] needs to be *rounded* to the > > > > > neartest power-of-two integer instead of itself being the > > > > > power-of-two. > > > > > > > > > > This also is consistency with the SDM, where the comment for bit > > > > > 23-16 of CPUID.1:EBX is: > > > > > > > > > > The nearest power-of-2 integer that is not smaller than EBX[23:16] > > > > > is > > > > > the number of unique initial APIC IDs reserved for addressing > > > > > different logical processors in a physical package. > > > > > > > > > > What I read from this is, the nearest power-of-2 integer that is not > > > > > smaller than EBX[23:16] is a different thing than EBX[23:16]. i.e., > > > > > > > > Yes, when I read sdm, I also thought it was a kernel bug. But on my > > > > 192ht spr host, the value of CPUID.1:EBX[23:16] was indeed rounded up > > > > > > > > to the nearest power of 2 by the hardware. After communicating with > > > > Intel technical support staff, we thought that perhaps the description > > > > in sdm > > > > > > > > is not so accurate, and rounding up CPUID.1:EBX[23:16] to the power of 2 > > > > in qemu may be more in line with the hardware behavior. > > > > > > I think above justification is important. We need to justify our changes > > > with the fact and correct reason. > > > > > > I somehow agree to set EBX[23:16] to a value of power-of-2, because the > > > 1.5.3 "Sub ID Extraction Parameters for initial APIC ID" of "Intel 64 > > > Architecture Processor Topology Enumeration" spec says > > > > > > CPUID.1:EBX[23:16] represents the maximum number of addressable IDs > > > (initial APIC ID) that can be assigned to logical processors in a > > > physical package. The value may not be the same as the number of > > > logical processors that are present in the hardware of a physical > > > package. > > > > > > It uses the word "may not". > > > > IMO, I don't quite understand your confusion regarding this. I've already > > explained the meaning of addressable ID, and the spec you referenced also > > clarifies its significance. The reason for this modification is not > > because of the two words "may not". > > > > Whether it is "be" or "not be" the same as the number of logical > > processors, the essence is that due to topology, the actual number of > > initial IDs that can be accommodated in the APIC ID may exceed the number > > of logical processors. > > I have the confusion because no matter from SDM: > > Bit 23-16: Maximum number of addressable IDs for logical processors in > this physical package* > > * The nearest power-of-2 integer that is not smaller than EBX[23:16] > is the number of unique initial APIC IDs reserved for addressing > different logical processors in a physical package. > > or from "Intel 64 Architecture Processor Topology Enumeration" spec，(Jan > 2018, revision 1.1), 1.5.3 "s
Re: [PATCH RFC V5 00/30] Support of Virtual CPU Hotplug for ARMv8 Arch
Hi Salil, The issues reported against on RFCv3 are still existing. I'm listing them as below. (1) Guest fails to start due to SVE initialization /home/gavin/sandbox/qemu.main/build/qemu-system-aarch64 \ -accel kvm -machine virt,gic-version=host,nvdimm=on \ -cpu host -smp maxcpus=4,cpus=1,sockets=2,clusters=2,cores=1,threads=1 \ -m 4096M,slots=16,maxmem=128G\ -object memory-backend-ram,id=mem0,size=2048M\ -object memory-backend-ram,id=mem1,size=2048M\ : kvm_arch_init_vcpu: Error -22 from kvm_arm_sve_set_vls() qemu-system-aarch64: Failed to initialize host vcpu 1 Workaround: The SVE feature bits in ID_AA64PFR0 need to be masked off in kvm_arm_get_host_cpu_features() after the feature register's value is read from the host. (2) Fail to hot add vCPU whose PMU is turned off /home/gavin/sandbox/qemu.main/build/qemu-system-aarch64 \ -accel kvm -machine virt,gic-version=host,nvdimm=on \ -cpu host -smp maxcpus=4,cpus=1,sockets=2,clusters=2,cores=1,threads=1 \ -m 4096M,slots=16,maxmem=128G\ -object memory-backend-ram,id=mem0,size=2048M\ -object memory-backend-ram,id=mem1,size=2048M\ : (qemu) device_add host-arm-cpu,id=cpu1,socket-id=0,cluster-id=1,core-id=0,thread-id=0,pmu=off kvm_arch_init_vcpu: Error -22 from kvm_arm_vcpu_init() qemu-system-aarch64: kvm_init_vcpu: kvm_arch_init_vcpu failed (1): Invalid argument Workaround: Keep PMU on while the vCPU is hot added. Thanks, Gavin
Re: [PATCH v2] tests/functional: Convert most Aspeed machine tests
On 10/17/24 08:06, Thomas Huth wrote:
On 16/10/2024 22.38, Cédric Le Goater wrote:
This is a simple conversion of the tests with some cleanups and
adjustments to match the new test framework. Replace the zephyr image
MD5 hashes with SHA256 hashes while at it.
The SDK tests depend on a ssh class from avocado.utils which is
difficult to replace. To be addressed separately.
Signed-off-by: Cédric Le Goater
---
Changes in v2:
- define class level Asset variables
tests/avocado/machine_aspeed.py | 252 -
tests/functional/meson.build | 2 +
tests/functional/test_arm_aspeed.py | 277
3 files changed, 279 insertions(+), 252 deletions(-)
create mode 100644 tests/functional/test_arm_aspeed.py
diff --git a/tests/avocado/machine_aspeed.py b/tests/avocado/machine_aspeed.py
index 4e144bde9131..cb163e3a1106 100644
--- a/tests/avocado/machine_aspeed.py
+++ b/tests/avocado/machine_aspeed.py
@@ -19,258 +19,6 @@
from avocado_qemu import has_cmd
from avocado.utils import archive
from avocado import skipUnless
-from avocado import skipUnless
-
-
-class AST1030Machine(QemuSystemTest):
- """Boots the zephyr os and checks that the console is operational"""
-
- timeout = 10
-
- def test_ast1030_zephyros_1_04(self):
- """
- :avocado: tags=arch:arm
- :avocado: tags=machine:ast1030-evb
- :avocado: tags=os:zephyr
- """
- tar_url = ('https://github.com/AspeedTech-BMC'
- '/zephyr/releases/download/v00.01.04/ast1030-evb-demo.zip')
- tar_hash = '4c6a8ce3a8ba76ef1a65dae419ae3409343c4b20'
- tar_path = self.fetch_asset(tar_url, asset_hash=tar_hash)
- archive.extract(tar_path, self.workdir)
- kernel_file = self.workdir + "/ast1030-evb-demo/zephyr.elf"
- self.vm.set_console()
- self.vm.add_args('-kernel', kernel_file,
- '-nographic')
- self.vm.launch()
- wait_for_console_pattern(self, "Booting Zephyr OS")
- exec_command_and_wait_for_pattern(self, "help",
- "Available commands")
-
- def test_ast1030_zephyros_1_07(self):
- """
- :avocado: tags=arch:arm
- :avocado: tags=machine:ast1030-evb
- :avocado: tags=os:zephyr
- """
- tar_url = ('https://github.com/AspeedTech-BMC'
- '/zephyr/releases/download/v00.01.07/ast1030-evb-demo.zip')
- tar_hash = '40ac87eabdcd3b3454ce5aad11fedc72a33ecda2'
- tar_path = self.fetch_asset(tar_url, asset_hash=tar_hash)
- archive.extract(tar_path, self.workdir)
- kernel_file = self.workdir + "/ast1030-evb-demo/zephyr.bin"
- self.vm.set_console()
- self.vm.add_args('-kernel', kernel_file,
- '-nographic')
- self.vm.launch()
- wait_for_console_pattern(self, "Booting Zephyr OS")
- for shell_cmd in [
- 'kernel stacks',
- 'otp info conf',
- 'otp info scu',
- 'hwinfo devid',
- 'crypto aes256_cbc_vault',
- 'random get',
- 'jtag JTAG1 sw_xfer high TMS',
- 'adc ADC0 resolution 12',
- 'adc ADC0 read 42',
- 'adc ADC1 read 69',
- 'i2c scan I2C_0',
- 'i3c attach I3C_0',
- 'hash test',
- 'kernel uptime',
- 'kernel reboot warm',
- 'kernel uptime',
- 'kernel reboot cold',
- 'kernel uptime',
- ]: exec_command_and_wait_for_pattern(self, shell_cmd, "uart:~$")
-
-class AST2x00Machine(QemuSystemTest):
-
- timeout = 180
-
- def wait_for_console_pattern(self, success_message, vm=None):
- wait_for_console_pattern(self, success_message,
- failure_message='Kernel panic - not syncing',
- vm=vm)
You're losing the "failure_message='Kernel panic - not syncing'" check in your
new code. Maybe not worth the effort to copy it over, but still, should be mentioned at
least in the commit description, I think.
Alternatively, you could also use the LinuxKernelTest base class instead which
has this wait_for_console_pattern magic included already.
Ah ! I didn't know. I will use LinuxKernelTest instead.
- def do_test_arm_aspeed(self, image):
- self.vm.set_console()
- self.vm.add_args('-drive', 'file=' + image + ',if=mtd,format=raw',
- '-net', 'nic')
- self.vm.launch()
-
- self.wait_for_console_pattern("U-Boot 2016.07")
- self.wait_for_console_pattern("## Loading kernel from FIT Image at
2008")
- self.wait_for_console_pattern("Starting kernel ...")
- self.wait_for_console_pattern("Booting Linux on physical CPU 0x0")
- wait_for_console_pattern(self,
- "aspeed-smc 1e62.spi:
Re: [PATCH] migration/dirtyrate: Silence warning about strcpy() on OpenBSD
On Thu, Oct 17, 2024 at 1:40 PM Thomas Huth wrote:
> On 16/10/2024 18.22, Daniel P. Berrangé wrote:
> > On Wed, Oct 16, 2024 at 06:07:12PM +0200, Thomas Huth wrote:
> >> The linker on OpenBSD complains:
> >>
> >> ld: warning: dirtyrate.c:447 (../src/migration/dirtyrate.c:447)(...):
> >> warning: strcpy() is almost always misused, please use strlcpy()
> >
> > Is that the only place it complains ? We use 'strcpy' in almost
> > 100 places across the codebase
>
> There are only a fistful of other warnings. I guess most of the spots are
> turned into inlined code by the compiler, so the linker never sees those
> other occurrences.
>
> >> It's currently not a real problem in this case since both arrays
> >> have the same size (256 bytes). But just in case somebody changes
> >> the size of the source array in the future, let's better play safe
> >> and use g_strlcpy() here instead.
> >>
> >> Signed-off-by: Thomas Huth
> >> ---
> >> migration/dirtyrate.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
> >> index 233acb0855..090c76e934 100644
> >> --- a/migration/dirtyrate.c
> >> +++ b/migration/dirtyrate.c
> >> @@ -444,7 +444,7 @@ static void get_ramblock_dirty_info(RAMBlock *block,
> >> info->ramblock_pages = qemu_ram_get_used_length(block) >>
> >> qemu_target_page_bits();
> >> info->ramblock_addr = qemu_ram_get_host_addr(block);
> >> -strcpy(info->idstr, qemu_ram_get_idstr(block));
> >> +g_strlcpy(info->idstr, qemu_ram_get_idstr(block),
> sizeof(info->idstr));
> >> }
> >
> > Reviewed-by: Daniel P. Berrangé
> >
> >
> > Is it worth also adding
> >
> >G_STATIC_ASSERT(sizeof((struct RamblockDirtyInfo){}.idstr) ==
> >sizeof((struct RAMBlock){}.idstr));
> >
> > at the top of this file, since both of these fields are expected to
> > be the same size by this code, to avoid truncation.
>
> ... or alternatively check the return value of g_strlcpy() ? ... but that
> wouldn't work if pstrcpy() if we switch to that function instead.
>
> I don't mind either way - Peter, Fabiano, Hyman, what's your opinion here?
>
> Thomas
>
>
Since RamblockDirtyInfo is only used in dirtyrate.c, I'm inclined to just
check the return value of g_strlcpy to avoid DoS attack, and fix this
warning case by case.
Thanks,
Yong
--
Best regards
Re: [PATCH v2] intel_iommu: Introduce property "x-stale-tm" to control Transient Mapping (TM) field
On Thu, Oct 10, 2024 at 3:57 PM Zhenzhong Duan wrote:
>
> VT-d spec removed Transient Mapping (TM) field from second-level page-tables
> and treat the field as Reserved(0) since revision 3.2.
>
> Changing the field as reserved(0) will break backward compatibility, so
> introduce a property "x-stale-tm" to allow user to control the setting.
Nit: I think we probably don't need the x prefix? As we try to
maintain the compatibility via:
> +{ TYPE_INTEL_IOMMU_DEVICE, "x-stale-tm", "on" },
?
Thanks
Re: [PATCH v4 08/19] pc-bios/s390-ccw: Remove panics from ECKD IPL path
On 17/10/2024 03.47, jro...@linux.ibm.com wrote:
From: Jared Rossi
Remove panic-on-error from ECKD block device IPL specific functions so that
error recovery may be possible in the future.
Functions that would previously panic now provide a return code.
Signed-off-by: Jared Rossi
---
pc-bios/s390-ccw/bootmap.h | 1 +
pc-bios/s390-ccw/bootmap.c | 193 +
2 files changed, 135 insertions(+), 59 deletions(-)
diff --git a/pc-bios/s390-ccw/bootmap.h b/pc-bios/s390-ccw/bootmap.h
index 09f4e6fb40..271dbabbc3 100644
--- a/pc-bios/s390-ccw/bootmap.h
+++ b/pc-bios/s390-ccw/bootmap.h
@@ -16,6 +16,7 @@
typedef uint64_t block_number_t;
#define NULL_BLOCK_NR 0xULL
+#define ERROR_BLOCK_NR 0xfffeULL
#define FREE_SPACE_FILLER '\xAA'
diff --git a/pc-bios/s390-ccw/bootmap.c b/pc-bios/s390-ccw/bootmap.c
index 5477cfe228..dd04bb3384 100644
--- a/pc-bios/s390-ccw/bootmap.c
+++ b/pc-bios/s390-ccw/bootmap.c
@@ -145,14 +145,17 @@ static block_number_t load_eckd_segments(block_number_t
blk, bool ldipl,
bool more_data;
memset(_bprs, FREE_SPACE_FILLER, sizeof(_bprs));
-read_block(blk, bprs, "BPRS read failed");
+if (virtio_read(blk, bprs)) {
+puts("BPRS read failed");
+return ERROR_BLOCK_NR;
+}
do {
more_data = false;
for (j = 0;; j++) {
block_nr = gen_eckd_block_num(&bprs[j].xeckd, ldipl);
if (is_null_block_number(block_nr)) { /* end of chunk */
-break;
+return NULL_BLOCK_NR;
}
/* we need the updated blockno for the next indirect entry
@@ -163,15 +166,20 @@ static block_number_t load_eckd_segments(block_number_t
blk, bool ldipl,
}
/* List directed pointer does not store block size */
-IPL_assert(ldipl || block_size_ok(bprs[j].xeckd.bptr.size),
- "bad chunk block size");
+if (!ldipl && !block_size_ok(bprs[j].xeckd.bptr.size)) {
+puts("Bad chunk block size");
+return NULL_BLOCK_NR;
Shouldn't that be a "return ERROR_BLOCK_NR" instead?
+}
if (!eckd_valid_address(&bprs[j].xeckd, ldipl)) {
/*
* If an invalid address is found during LD-IPL then break and
- * retry as CCW
+ * retry as CCW-IPL, otherwise abort on error
*/
-IPL_assert(ldipl, "bad chunk ECKD addr");
+if (!ldipl) {
+puts("Bad chunk ECKD address");
+return ERROR_BLOCK_NR;
+}
break;
}
@@ -189,7 +197,10 @@ static block_number_t load_eckd_segments(block_number_t blk, bool ldipl,
* I.e. the next ptr must point to the unused memory area
*/
memset(_bprs, FREE_SPACE_FILLER, sizeof(_bprs));
-read_block(block_nr, bprs, "BPRS continuation read failed");
+if (virtio_read(block_nr, bprs)) {
+puts("BPRS continuation read failed");
+return ERROR_BLOCK_NR;
+}
more_data = true;
break;
}
@@ -198,7 +209,10 @@ static block_number_t load_eckd_segments(block_number_t
blk, bool ldipl,
* to memory (address).
*/
rc = virtio_read_many(block_nr, (void *)(*address), count + 1);
-IPL_assert(rc == 0, "code chunk read failed");
+if (rc != 0) {
+puts("Code chunk read failed");
+return ERROR_BLOCK_NR;
+}
*address += (count + 1) * virtio_get_block_size();
}
@@ -232,7 +246,10 @@ static int eckd_get_boot_menu_index(block_number_t
s1b_block_nr)
/* Get Stage1b data */
memset(sec, FREE_SPACE_FILLER, sizeof(sec));
-read_block(s1b_block_nr, s1b, "Cannot read stage1b boot loader");
+if (virtio_read(s1b_block_nr, s1b)) {
+puts("Cannot read stage1b boot loader");
+return -EIO;
+}
memset(_s2, FREE_SPACE_FILLER, sizeof(_s2));
@@ -244,7 +261,10 @@ static int eckd_get_boot_menu_index(block_number_t s1b_block_nr)
break;
}
-read_block(cur_block_nr, s2_cur_blk, "Cannot read stage2 boot loader");
+if (virtio_read(cur_block_nr, s2_cur_blk)) {
+puts("Cannot read stage2 boot loader");
+return -EIO;
+}
if (find_zipl_boot_menu_banner(&banner_offset)) {
/*
@@ -252,8 +272,10 @@ static int eckd_get_boot_menu_index(block_number_t
s1b_block_nr)
* possibility of menu data spanning multiple blocks.
*/
if (prev_block_nr) {
-read_block(prev_block_nr, s2_prev_blk,
-
Re: [PATCH] migration/dirtyrate: Silence warning about strcpy() on OpenBSD
On Thu, 17 Oct 2024 at 06:41, Thomas Huth wrote: > > On 16/10/2024 18.22, Daniel P. Berrangé wrote: > > On Wed, Oct 16, 2024 at 06:07:12PM +0200, Thomas Huth wrote: > >> The linker on OpenBSD complains: > >> > >> ld: warning: dirtyrate.c:447 (../src/migration/dirtyrate.c:447)(...): > >> warning: strcpy() is almost always misused, please use strlcpy() > > > > Is that the only place it complains ? We use 'strcpy' in almost > > 100 places across the codebase > > There are only a fistful of other warnings. I guess most of the spots are > turned into inlined code by the compiler, so the linker never sees those > other occurrences. >From my vm-build-openbsd buildlog: $ < /tmp/par0L_eB.par grep 'almost always misused'| wc -l 305 (I've had these in my "ignore this type of warning" filter for grepping the build logs for years.) -- PMM
Re: [PATCH] vhost-user: fix shared object return values
On Thu, Oct 17, 2024 at 11:28:56AM +0200, Albert Esteve wrote:
> On Thu, Oct 17, 2024 at 11:18 AM Daniel P. Berrangé
> wrote:
> >
> > On Thu, Oct 17, 2024 at 11:12:32AM +0200, Albert Esteve wrote:
> > > On Thu, Oct 17, 2024 at 10:44 AM Daniel P. Berrangé
> > > wrote:
> > > >
> > > > On Wed, Oct 16, 2024 at 11:06:06AM +0200, Albert Esteve wrote:
> > > > > VHOST_USER_BACKEND_SHARED_OBJECT_ADD and
> > > > > VHOST_USER_BACKEND_SHARED_OBJECT_REMOVE state
> > > > > in the spec that they return 0 for successful
> > > > > operations, non-zero otherwise. However,
> > > > > implementation relies on the return types
> > > > > of the virtio-dmabuf library, with opposite
> > > > > semantics (true if everything is correct,
> > > > > false otherwise). Therefore, current implementaion
> > > > > violates the specification.
> > > > >
> > > > > Revert the logic so that the implementation
> > > > > of the vhost-user handling methods matches
> > > > > the specification.
> > > > >
> > > > > Fixes: 043e127a126bb3ceb5fc753deee27d261fd0c5ce
> > > > > Fixes: 160947666276c5b7f6bca4d746bcac2966635d79
> > > > > Signed-off-by: Albert Esteve
> > > > > ---
> > > > > hw/virtio/vhost-user.c | 8
> > > > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
> > > > > index 00561daa06..90917352a4 100644
> > > > > --- a/hw/virtio/vhost-user.c
> > > > > +++ b/hw/virtio/vhost-user.c
> > > > > @@ -1607,7 +1607,7 @@
> > > > > vhost_user_backend_handle_shared_object_add(struct vhost_dev *dev,
> > > > > QemuUUID uuid;
> > > > >
> > > > > memcpy(uuid.data, object->uuid, sizeof(object->uuid));
> > > > > -return virtio_add_vhost_device(&uuid, dev);
> > > > > +return !virtio_add_vhost_device(&uuid, dev);
> > > > > }
> > > >
> > > > This virtio_add_vhost_device() method returns a bool, but this
> > > > vhost_user_backend_handle_shared_object_add() method returns
> > > > an int, but fills that int with an inverted bool value. The
> > > > caller then assigns the return value to an int, but then
> > > > interprets the int as a bool, and assigns that bool result
> > > > to an u64.
> > > >
> > > > This call chain is madness :-(
> > >
> > > TBF most of the madness is part of the already existing
> > > handling infrastructure.
> > > vhost_user_backend_handle_shared_object_add()
> > > returns an int to be consistent with other handling
> > > functions.
> > >
> > > >
> > > > Change vhost_user_backend_handle_shared_object_add to return
> > > > a bool to reduce the madness IMHO.
> > >
> > > Changing it to bool would make it inconsistent
> > > wrt other handlers, and the casting would happen nonetheless
> > > on assignment. Not sure if that is an improvement.
> >
> > Well when the caller does
> >
> > payload.u64 = !!ret;
> >
> > it is saying that it only cares about the values
> > being 0 or 1. So how about just making these
> > methods return 0 or 1 then.
>
> Ah, I see your point. I introduced negative error
> values just because I saw other handlers doing
> it (e.g., vhost_user_backend_handle_vring_host_notifier()).
>
> > > > > static int
> > > > > @@ -1623,16 +1623,16 @@
> > > > > vhost_user_backend_handle_shared_object_remove(struct vhost_dev *dev,
> > > > > struct vhost_dev *owner = virtio_lookup_vhost_device(&uuid);
> > > > > if (dev != owner) {
> > > > > /* Not allowed to remove non-owned entries */
> > > > > -return 0;
> > > > > +return -EPERM;
>
> So you are suggesting here it could be `return 1;` instead?
> It does not look clear enough that it is an error value.
Add API documentation comments to these methods
"Returns: 0 on success, 1 on error"
With regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH] vhost-user: fix shared object return values
On Thu, Oct 17, 2024 at 10:27:30AM +0200, Albert Esteve wrote:
Albert Esteve
Senior Software Engineer
Red Hat
aest...@redhat.com
On Thu, Oct 17, 2024 at 9:38 AM Stefano Garzarella wrote:
On Wed, Oct 16, 2024 at 11:06:06AM +0200, Albert Esteve wrote:
>VHOST_USER_BACKEND_SHARED_OBJECT_ADD and
>VHOST_USER_BACKEND_SHARED_OBJECT_REMOVE state
>in the spec that they return 0 for successful
>operations, non-zero otherwise. However,
>implementation relies on the return types
>of the virtio-dmabuf library, with opposite
>semantics (true if everything is correct,
>false otherwise). Therefore, current implementaion
s/implementaion/implementation
I hadn't seen it ;-P found with:
./scripts/checkpatch.pl --strict --branch master..HEAD --codespell
Never used the checkpatch script for spelling. Thanks!
>violates the specification.
>
>Revert the logic so that the implementation
>of the vhost-user handling methods matches
>the specification.
>
>Fixes: 043e127a126bb3ceb5fc753deee27d261fd0c5ce
This is in from 9.0 ...
>Fixes: 160947666276c5b7f6bca4d746bcac2966635d79
... and this from 8.2, so should we consider stable branches?
You mean in addition to the commits already reflected here?
Nope, I just mean if we need to cc qemu-sta...@nongnu.org in order to
backport this patch on stable branches.
See docs/devel/stable-process.rst
I think it depends if the backends are checking that return value.
The return value is optional (requires VHOST_USER_NEED_REPLY),
and I am not aware of any backend using this feature so far,
in general. So iiuc, that'd mean no need to include stable, right?
Yep, if no one uses it, we can avoid it for now. On the other hand if
the patch is simple, perhaps it might make sense to avoid future issues.
Michael WDYT?
Thanks
Stefano
Best,
Albert.
>Signed-off-by: Albert Esteve
>---
> hw/virtio/vhost-user.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
Thanks for the fix!
Reviewed-by: Stefano Garzarella
>
>diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
>index 00561daa06..90917352a4 100644
>--- a/hw/virtio/vhost-user.c
>+++ b/hw/virtio/vhost-user.c
>@@ -1607,7 +1607,7 @@ vhost_user_backend_handle_shared_object_add(struct
vhost_dev *dev,
> QemuUUID uuid;
>
> memcpy(uuid.data, object->uuid, sizeof(object->uuid));
>-return virtio_add_vhost_device(&uuid, dev);
>+return !virtio_add_vhost_device(&uuid, dev);
> }
>
> static int
>@@ -1623,16 +1623,16 @@ vhost_user_backend_handle_shared_object_remove(struct
vhost_dev *dev,
> struct vhost_dev *owner = virtio_lookup_vhost_device(&uuid);
> if (dev != owner) {
> /* Not allowed to remove non-owned entries */
>-return 0;
>+return -EPERM;
> }
> break;
> }
> default:
> /* Not allowed to remove non-owned entries */
>-return 0;
>+return -EPERM;
> }
>
>-return virtio_remove_resource(&uuid);
>+return !virtio_remove_resource(&uuid);
> }
>
> static bool vhost_user_send_resp(QIOChannel *ioc, VhostUserHeader *hdr,
>--
>2.46.1
>
Re: [PULL 08/20] virtio-net: Add only one queue pair when realizing
On 2024/10/17 18:17, Laurent Vivier wrote:
On 17/10/2024 11:07, Akihiko Odaki wrote:
On 2024/10/17 16:32, Laurent Vivier wrote:
On 17/10/2024 08:59, Jason Wang wrote:
On Mon, Oct 14, 2024 at 11:16 PM Laurent Vivier
wrote:
On 14/10/2024 10:30, Laurent Vivier wrote:
Hi Akihiko,
On 04/06/2024 09:37, Jason Wang wrote:
From: Akihiko Odaki
Multiqueue usage is not negotiated yet when realizing. If more than
one queue is added and the guest never requests to enable
multiqueue,
the extra queues will not be deleted when unrealizing and leak.
Fixes: f9d6dbf0bf6e ("virtio-net: remove virtio queues if the
guest doesn't support
multiqueue")
Signed-off-by: Akihiko Odaki
Signed-off-by: Jason Wang
---
hw/net/virtio-net.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 3cee2ef3ac..a8db8bfd9c 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -3743,9 +3743,7 @@ static void
virtio_net_device_realize(DeviceState *dev, Error **errp)
n->net_conf.tx_queue_size =
MIN(virtio_net_max_tx_queue_size(n),
n->net_conf.tx_queue_size);
- for (i = 0; i < n->max_queue_pairs; i++) {
- virtio_net_add_queue(n, i);
- }
+ virtio_net_add_queue(n, 0);
n->ctrl_vq = virtio_add_queue(vdev, 64,
virtio_net_handle_ctrl);
qemu_macaddr_default_if_unset(&n->nic_conf.macaddr);
This change breaks virtio net migration when multiqueue is enabled.
I think this is because virtqueues are half initialized after
migration : they are
initialized on guest side (kernel is using them) but not on QEMU
side (realized has only
initialized one). After migration, they are not initialized by the
call to
virtio_net_set_multiqueue() from virtio_net_set_features() because
virtio_get_num_queues()
reports already n->max_queue_pairs as this value is coming from
the source guest memory.
I don't think we have a way to half-initialize a virtqueue (to
initialize them only on
QEMU side as they are already initialized on kernel side).
I think this change should be reverted to fix the migration issue.
Moreover, if I look in the code of virtio_load() and
virtio_add_queue() we can guess it's
not correct to migrate a virtqueue that is not initialized on the
destination side because
fields like 'vdev->vq[i].handle_output' or 'vdev->vq[i].used_elems'
cannot be initialized
by virtio_load() and neither by virtio_add_queue() after
virtio_load() as fields like
'vring.num' are already initialized by virtio_load().
For instance, in virtio_load() we set:
for (i = 0; i < num; i++) {
vdev->vq[i].vring.num = qemu_get_be32(f);
and in virtio_add_queue() we search for the firt available queue to
add with:
for (i = 0; i < VIRTIO_QUEUE_MAX; i++) {
if (vdev->vq[i].vring.num == 0)
break;
}
So virtio_add_queue() cannot be used to set:
vdev->vq[i].handle_output = handle_output;
vdev->vq[i].used_elems = g_new0(VirtQueueElement, queue_size);
Moreover it would overwrite fields already set by virtio_load():
vdev->vq[i].vring.num = queue_size;
vdev->vq[i].vring.align = VIRTIO_PCI_VRING_ALIGN;
It also explains why virtio_net_change_num_queue_pairs()
(indirectly called by
virtio_net_set_features()) doesn't update the queue pair numbers:
vring.num is already set
so it thinks there is no more queues to add.
Thanks,
LAurent
I agree.
Laurent, would you like to send a patch to revert this?
Yes. I will also try to fix the leak in unrealize that the patch
wanted to fix initially.
I wrote a fix so I will submit it once internal testing is done. You
can see the change at:
https://gitlab.com/akihiko.odaki/qemu-kvm/-/
commit/22161221aa2d2031d7ad1be7701852083aa9109a
It works fine for me but I don't know if it's a good idea to add queues
while the state is loading.
I couldn't come up with other options. The problem is that the number of
queues added during realization does not match with the loaded state. We
need to add queues after knowing the negotiated feature set and before
loading the queue states to fix this problem.
Reverting will add queues that are used when the multiqueue feature is
negotiated so it will fix migration for such cases, but will also break
the other cases (i.e., the multiqueue feature is not negotiated) as it
adds too many queues.
Regards,
Akihiko Odaki
Jason, let me know which solution you prefer (revert or pre_load_queues
helper).
CC'ing MST
Thanks,
Laurent
Re: [PATCH v4 1/2] tpm: Use new ptm_cap_n structure for PTM_GET_CAPABILITY
On Wed, Oct 16, 2024 at 01:51:28PM -0400, Stefan Berger wrote: > Use the new ptm_cap_n structure for getting the PTM_GET_CAPABILITY response > from swtpm. Previously only 17 bits could possibly have been set in ptm_cap > (=uint64_t) in big endian order and those bits are now found in the 2nd ^^ stray '=' sign > 32bit word in the response in the caps field. > > This data structure makes it now clear that the 1st 32bit word carries the > tpm_result like all the other response structures of all other commands > do. > > The changes are taken from the swtpm project's tpm_ioctl.h. > > Signed-off-by: Stefan Berger > --- > backends/tpm/tpm_emulator.c | 14 -- > backends/tpm/tpm_ioctl.h| 13 - > backends/tpm/trace-events | 2 +- > 3 files changed, 21 insertions(+), 8 deletions(-) Reviewed-by: Daniel P. Berrangé With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PULL 00/25] x86 and KVM patches for 2024-10-15
On Tue, 15 Oct 2024 at 15:17, Paolo Bonzini wrote: > > The following changes since commit aa54f5be44be786636a5d51cc1612ad208a24849: > > tests: update lcitool to fix freebsd py311-yaml rename (2024-10-14 15:54:24 > +0100) > > are available in the Git repository at: > > https://gitlab.com/bonzini/qemu.git tags/for-upstream > > for you to fetch changes up to 4bfdcb24fa5dc0844d0e4ab2cebb6687a233c0ff: > > target/i386: Use only 16 and 32-bit operands for IN/OUT (2024-10-15 > 16:15:47 +0200) > > > * target/i386: Fixes for IN and OUT with REX prefix > * target/i386: New CPUID features and logic fixes > * target/i386: Add support save/load HWCR MSR > * target/i386: Move more instructions to new decoder; separate decoding > and IR generation > * target/i386/tcg: Use DPL-level accesses for interrupts and call gates > * accel/kvm: perform capability checks on VM file descriptor when necessary > * accel/kvm: dynamically sized kvm memslots array > * target/i386: fixes for Hyper-V > * docs/system: Add recommendations to Hyper-V enlightenments doc > > As discussed on irc, this (maybe?) runs into the s390 host bug you posted a patch for, so I'll wait for a v2 of this. -- PMM
Re: [PATCH v4 11/19] pc-bios/s390-ccw: Remove panics from Netboot IPL path
On 17/10/2024 03.47, jro...@linux.ibm.com wrote:
From: Jared Rossi
Remove panic-on-error from Netboot specific functions so that error recovery
may be possible in the future.
Functions that would previously panic now provide a return code.
Signed-off-by: Jared Rossi
---
pc-bios/s390-ccw/s390-ccw.h | 2 +-
pc-bios/s390-ccw/bootmap.c| 1 +
pc-bios/s390-ccw/netmain.c| 17 +++--
pc-bios/s390-ccw/virtio-net.c | 7 +--
4 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/pc-bios/s390-ccw/s390-ccw.h b/pc-bios/s390-ccw/s390-ccw.h
index 3e844abd71..344ad15655 100644
--- a/pc-bios/s390-ccw/s390-ccw.h
+++ b/pc-bios/s390-ccw/s390-ccw.h
@@ -57,7 +57,7 @@ unsigned int get_loadparm_index(void);
void main(void);
/* netmain.c */
-void netmain(void);
+int netmain(void);
/* sclp.c */
void sclp_print(const char *string);
diff --git a/pc-bios/s390-ccw/bootmap.c b/pc-bios/s390-ccw/bootmap.c
index a277fc3431..f1cfb7aaa8 100644
--- a/pc-bios/s390-ccw/bootmap.c
+++ b/pc-bios/s390-ccw/bootmap.c
@@ -1073,6 +1073,7 @@ void zipl_load(void)
if (virtio_get_device_type() == VIRTIO_ID_NET) {
netmain();
+panic("\n! Cannot IPL from this network !\n");
}
if (ipl_scsi()) {
diff --git a/pc-bios/s390-ccw/netmain.c b/pc-bios/s390-ccw/netmain.c
index bc6ad8695f..0bb359e09f 100644
--- a/pc-bios/s390-ccw/netmain.c
+++ b/pc-bios/s390-ccw/netmain.c
@@ -464,7 +464,7 @@ static bool find_net_dev(Schib *schib, int dev_no)
return false;
}
-static void virtio_setup(void)
+static bool virtio_setup(void)
{
Schib schib;
int ssid;
@@ -495,10 +495,10 @@ static void virtio_setup(void)
}
}
-IPL_assert(found, "No virtio net device found");
+return found;
}
-void netmain(void)
+int netmain(void)
{
filename_ip_t fn_ip;
int rc, fnlen;
@@ -506,11 +506,15 @@ void netmain(void)
sclp_setup();
puts("Network boot starting...");
-virtio_setup();
+if (!virtio_setup()) {
+puts("No virtio net device found.");
+return 1;
+}
rc = net_init(&fn_ip);
if (rc) {
-panic("Network initialization failed. Halting.");
+puts("Network initialization failed.");
+return 1;
}
fnlen = strlen(fn_ip.filename);
@@ -528,5 +532,6 @@ void netmain(void)
jump_to_low_kernel();
}
-panic("Failed to load OS from network.");
+puts("Failed to load OS from network.");
+return 1;
}
I'd maybe also change the netmain() function to return -1 in case of errors.
Anyway:
Reviewed-by: Thomas Huth
[PATCH] spapr: nested: Add support for DPDES SPR in GSB for TCG L0
The DPDES support for doorbell emulation and handling for KVM on PAPR
guests was added in Linux via [1]. Subsequently, a new GSB element for
DPDES was added in Linux; the same has been missing in QEMU L0. Add
support for DPDES register's APIv2 GSB element and required handling in
`spapr_nested.c`.
Currently, booting a KVM guest inside a QEMU TCG guest fails with the
below crash. The crash is encountered when GUEST_RUN_VCPU hcall made
into QEMU TCG L0 fails because H_INVALID_ELEMENT_VALUE is returned as
the mapping of the element ID corresponding to DPDES (unknown to QEMU
TCG L0) in GSR (Guest State Request) of TCG guest's KVM to the GSB
(Guest State Buffer) elements of QEMU TCG L0 fails.
KVM: unknown exit, hardware reason ffea
NIP 0100 LR CTR XER
CPU#0
MSR 3000 HID0 HF 6c002000 iidx 3 didx 3
TB DECR 0
GPR00 7fe0
GPR04
GPR08
GPR12
GPR16
GPR20
GPR24
GPR28
CR [ - - - - - - - - ] RES 000@
SRR0 SRR1 PVR 00801200 VRSAVE
SPRG0 SPRG1 SPRG2 SPRG3
SPRG4 SPRG5 SPRG6 SPRG7
HSRR0 HSRR1
CFAR
LPCR 00560413
PTCR DAR DSISR
Fix this by adding the required support and handling in QEMU TCG L0.
[1] https://lore.kernel.org/all/20240605113913.83715-1-gau...@linux.ibm.com/
Fixes: 4a575f9a0567 ("spapr: nested: Initialize the GSB elements lookup table.")
Suggested-by: Harsh Prateek Bora
Reviewed-by: Vaibhav Jain
Signed-off-by: Amit Machhiwal
---
hw/ppc/spapr_nested.c | 3 +++
include/hw/ppc/spapr_nested.h | 3 ++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/hw/ppc/spapr_nested.c b/hw/ppc/spapr_nested.c
index c02785756c1e..b696ad537a77 100644
--- a/hw/ppc/spapr_nested.c
+++ b/hw/ppc/spapr_nested.c
@@ -194,6 +194,7 @@ static void nested_save_state(struct nested_ppc_state
*save, PowerPCCPU *cpu)
save->fscr = env->spr[SPR_FSCR];
save->pspb = env->spr[SPR_PSPB];
save->ctrl = env->spr[SPR_CTRL];
+save->dpdes = env->spr[SPR_DPDES];
save->vrsave = env->spr[SPR_VRSAVE];
save->dar = env->spr[SPR_DAR];
save->dsisr = env->spr[SPR_DSISR];
@@ -293,6 +294,7 @@ static void nested_load_state(PowerPCCPU *cpu, struct
nested_ppc_state *load)
env->spr[SPR_FSCR] = load->fscr;
env->spr[SPR_PSPB] = load->pspb;
env->spr[SPR_CTRL] = load->ctrl;
+env->spr[SPR_DPDES] = load->dpdes;
env->spr[SPR_VRSAVE] = load->vrsave;
env->spr[SPR_DAR] = load->dar;
env->spr[SPR_DSISR] = load->dsisr;
@@ -982,6 +984,7 @@ struct guest_state_element_type guest_state_element_types[]
= {
GUEST_STATE_ELEMENT_ENV_DW(GSB_VCPU_SPR_FSCR, fscr),
GUEST_STATE_ELEMENT_ENV_W(GSB_VCPU_SPR_PSPB, pspb),
GUEST_STATE_ELEMENT_ENV_DW(GSB_VCPU_SPR_CTRL, ctrl),
+GUEST_STATE_ELEMENT_ENV_DW(GSB_VCPU_SPR_DPDES, dpdes),
GUEST_STATE_ELEMENT_ENV_W(GSB_VCPU_SPR_VRSAVE, vrsave),
GUEST_STATE_ELEMENT_ENV_DW(GSB_VCPU_SPR_DAR, dar),
GUEST_STATE_ELEMENT_ENV_W(GSB_VCPU_SPR_DSISR, dsisr),
diff --git a/include/hw/ppc/spapr_nested.h b/include/hw/ppc/spapr_nested.h
index 93ef14adcc5e..3b5cd993c256 100644
--- a/include/hw/ppc/spapr_nested.h
+++ b/include/hw/ppc/spapr_nested.h
@@ -99,7 +99,8 @@
#define GSB_VCPU_SPR_HASHKEYR 0x1050
#define GSB_VCPU_SPR_HASHPKEYR 0x1051
#define GSB_VCPU_SPR_CTRL 0x1052
-/* RESERVED 0x1053 - 0x1FFF */
+#define GSB_VCPU_SPR_DPDES 0x1053
+/* RESERVED 0x1054 - 0x1FFF */
#define GSB_VCPU_SPR_CR 0x2000
#define GSB_VCPU_SPR_PIDR 0x2001
#define GSB_VCPU_SPR_DSISR 0x2002
base-commit: aa54f5be44be786636a5d51cc1612ad208a24849
--
2.47.0
Re: [PATCH v2 3/6] target/riscv: Add support for Control Transfer Records extension CSRs.
On Tue, Aug 27, 2024 at 10:28 AM Frank Chang wrote:
>
> Rajnesh Kanwal 於 2024年6月19日 週三 下午11:27寫道：
> >
> > This commit adds support for [m|s|vs]ctrcontrol, sctrstatus and
> > sctrdepth CSRs handling.
> >
> > Signed-off-by: Rajnesh Kanwal
> > ---
> > target/riscv/cpu.h | 5 ++
> > target/riscv/cpu_cfg.h | 2 +
> > target/riscv/csr.c | 128 +
> > 3 files changed, 135 insertions(+)
> >
> > diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> > index a185e2d494..3d4d5172b8 100644
> > --- a/target/riscv/cpu.h
> > +++ b/target/riscv/cpu.h
> > @@ -263,6 +263,11 @@ struct CPUArchState {
> > target_ulong mcause;
> > target_ulong mtval; /* since: priv-1.10.0 */
> >
> > +uint64_t mctrctl;
> > +uint32_t sctrdepth;
> > +uint32_t sctrstatus;
> > +uint64_t vsctrctl;
> > +
> > /* Machine and Supervisor interrupt priorities */
> > uint8_t miprio[64];
> > uint8_t siprio[64];
> > diff --git a/target/riscv/cpu_cfg.h b/target/riscv/cpu_cfg.h
> > index d9354dc80a..d329a65811 100644
> > --- a/target/riscv/cpu_cfg.h
> > +++ b/target/riscv/cpu_cfg.h
> > @@ -123,6 +123,8 @@ struct RISCVCPUConfig {
> > bool ext_zvfhmin;
> > bool ext_smaia;
> > bool ext_ssaia;
> > +bool ext_smctr;
> > +bool ext_ssctr;
>
> Base on: https://github.com/riscv/riscv-control-transfer-records/pull/29
> Smctr and Ssctr depend on both S-mode and Sscsrind.
> We should add the implied rules for Smctr and Ssctr.
>
> Regards,
> Frank Chang
Hi Frank,
Are you referring to the checks in riscv_cpu_validate_set_extensions()?
These checks are already present in the last patch.
https://lore.kernel.org/qemu-riscv/20240619152708.135991-7-rkan...@rivosinc.com/
>
>
> > bool ext_sscofpmf;
> > bool ext_smepmp;
> > bool rvv_ta_all_1s;
> > diff --git a/target/riscv/csr.c b/target/riscv/csr.c
> > index 2f92e4b717..0b5bf4d050 100644
> > --- a/target/riscv/csr.c
> > +++ b/target/riscv/csr.c
> > @@ -621,6 +621,48 @@ static RISCVException pointer_masking(CPURISCVState
> > *env, int csrno)
> > return RISCV_EXCP_ILLEGAL_INST;
> > }
> >
> > +/*
> > + * M-mode:
> > + * Without ext_smctr raise illegal inst excep.
> > + * Otherwise everything is accessible to m-mode.
> > + *
> > + * S-mode:
> > + * Without ext_ssctr or mstateen.ctr raise illegal inst excep.
> > + * Otherwise everything other than mctrctl is accessible.
> > + *
> > + * VS-mode:
> > + * Without ext_ssctr or mstateen.ctr raise illegal inst excep.
> > + * Without hstateen.ctr raise virtual illegal inst excep.
> > + * Otherwise allow sctrctl (vsctrctl), sctrstatus, 0x200-0x2ff entry range.
> > + * Always raise illegal instruction exception for sctrdepth.
> > + */
> > +static RISCVException ctr_mmode(CPURISCVState *env, int csrno)
> > +{
> > +/* Check if smctr-ext is present */
> > +if (riscv_cpu_cfg(env)->ext_smctr) {
> > +return RISCV_EXCP_NONE;
> > +}
> > +
> > +return RISCV_EXCP_ILLEGAL_INST;
> > +}
> > +
> > +static RISCVException ctr_smode(CPURISCVState *env, int csrno)
> > +{
> > +const RISCVCPUConfig *cfg = riscv_cpu_cfg(env);
> > +
> > +if (!cfg->ext_smctr && !cfg->ext_ssctr) {
> > +return RISCV_EXCP_ILLEGAL_INST;
> > +}
> > +
> > +RISCVException ret = smstateen_acc_ok(env, 0, SMSTATEEN0_CTR);
> > +if (ret == RISCV_EXCP_NONE && csrno == CSR_SCTRDEPTH &&
> > +env->virt_enabled) {
> > +return RISCV_EXCP_VIRT_INSTRUCTION_FAULT;
> > +}
> > +
> > +return ret;
> > +}
> > +
> > static RISCVException aia_hmode(CPURISCVState *env, int csrno)
> > {
> > int ret;
> > @@ -3835,6 +3877,86 @@ static RISCVException write_satp(CPURISCVState *env,
> > int csrno,
> > return RISCV_EXCP_NONE;
> > }
> >
> > +static RISCVException rmw_sctrdepth(CPURISCVState *env, int csrno,
> > +target_ulong *ret_val,
> > +target_ulong new_val, target_ulong
> > wr_mask)
> > +{
> > +uint64_t mask = wr_mask & SCTRDEPTH_MASK;
> > +
> > +if (ret_val) {
> > +*ret_val = env->sctrdepth;
> > +}
> > +
> > +env->sctrdepth = (env->sctrdepth & ~mask) | (new_val & mask);
> > +
> > +/* Correct depth. */
> > +if (wr_mask & SCTRDEPTH_MASK) {
> > +uint64_t depth = get_field(env->sctrdepth, SCTRDEPTH_MASK);
> > +
> > +if (depth > SCTRDEPTH_MAX) {
> > +depth = SCTRDEPTH_MAX;
> > +env->sctrdepth = set_field(env->sctrdepth, SCTRDEPTH_MASK,
> > depth);
> > +}
> > +
> > +/* Update sctrstatus.WRPTR with a legal value */
> > +depth = 16 << depth;
> > +env->sctrstatus =
> > +env->sctrstatus & (~SCTRSTATUS_WRPTR_MASK | (depth - 1));
> > +}
> > +
> > +return RISCV_EXCP_NONE;
> > +}
> > +
> > +static RISCVException rmw_sctrstatus(CPURISCVState *env, int csrno,
> > + target_ulong *ret_val,
> > +
Re: [PATCH v4 19/19] tests/qtest: Add s390x boot order tests to cdrom-test.c
On 17/10/2024 03.47, jro...@linux.ibm.com wrote: From: Jared Rossi Add two new qtests to verify that a valid IPL device can successfully boot after failed IPL attempts from one or more invalid devices. cdrom-test/as-fallback-device: Defines the primary boot target as a device that is invalid for IPL and a second boot target that is valid for IPL. Ensures that the valid device will be selected after the initial failed IPL. cdrom-test/as-last-option: Defines the maximum number of boot devices (8) where only the final entry in the boot order is valid. Ensures that a valid device will be selected even after multiple failed IPL attempts from both virtio-blk and virtio-scsi device types. Signed-off-by: Jared Rossi --- Reviewed-by: Thomas Huth
Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)
On Tue, 15 Oct 2024 at 19:12, Guenter Roeck wrote: > Please let me know if https://github.com/groeck/linux-test-downloads.git > meets your needs. For now I added 'collie'. I'll add more after it is > in a state that is useful for you. Yes, that's great, exactly what we need. I've put together a QEMU 'functional test' case that downloads the collie rootfs and image and checks that they boot. (I'll send the patches for that out in a bit.) (I've coded the test case to pull the binaries for a specific git revision of that repo rather than always-from-head, so we're testing always the same thing against head-of-QEMU.) thanks -- PMM
[PATCH 0/2] linux-user/ppc: Fix sigmask endianness issue in sigreturn
Hi, This series fixes an issue where an emulated ppc64le process running on s390x attempting to wake up a sigwait()ing thread would instead terminate itself. Patch 1 is the fix, patch 2 is a testcase extracted from the real-world scenario. Best regards, Ilya Ilya Leoshkevich (2): linux-user/ppc: Fix sigmask endianness issue in sigreturn tests/tcg: Test that sigreturn() does not corrupt the signal mask linux-user/ppc/signal.c | 2 +- tests/tcg/multiarch/sigreturn-sigmask.c | 51 + 2 files changed, 52 insertions(+), 1 deletion(-) create mode 100644 tests/tcg/multiarch/sigreturn-sigmask.c -- 2.47.0
[PATCH 1/2] linux-user/ppc: Fix sigmask endianness issue in sigreturn
do_setcontext() copies the target sigmask without endianness handling
and then uses target_to_host_sigset_internal(), which expects a
byte-swapped one. Use target_to_host_sigset() instead.
Fixes: bcd4933a23f1 ("linux-user: ppc signal handling")
Signed-off-by: Ilya Leoshkevich
---
linux-user/ppc/signal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/linux-user/ppc/signal.c b/linux-user/ppc/signal.c
index a1d8c0bccc1..24e5a02a782 100644
--- a/linux-user/ppc/signal.c
+++ b/linux-user/ppc/signal.c
@@ -628,7 +628,7 @@ static int do_setcontext(struct target_ucontext *ucp,
CPUPPCState *env, int sig)
if (!lock_user_struct(VERIFY_READ, mcp, mcp_addr, 1))
return 1;
-target_to_host_sigset_internal(&blocked, &set);
+target_to_host_sigset(&blocked, &set);
set_sigmask(&blocked);
restore_user_regs(env, mcp, sig);
--
2.47.0
[PATCH 2/2] tests/tcg: Test that sigreturn() does not corrupt the signal mask
Add a small test to prevent regressions.
Signed-off-by: Ilya Leoshkevich
---
tests/tcg/multiarch/sigreturn-sigmask.c | 51 +
1 file changed, 51 insertions(+)
create mode 100644 tests/tcg/multiarch/sigreturn-sigmask.c
diff --git a/tests/tcg/multiarch/sigreturn-sigmask.c
b/tests/tcg/multiarch/sigreturn-sigmask.c
new file mode 100644
index 000..e6cc904898d
--- /dev/null
+++ b/tests/tcg/multiarch/sigreturn-sigmask.c
@@ -0,0 +1,51 @@
+/*
+ * Test that sigreturn() does not corrupt the signal mask.
+ * Block SIGUSR2 and handle SIGUSR1.
+ * Then sigwait() SIGUSR2, which relies on it remaining blocked.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+#include
+#include
+#include
+#include
+#include
+
+int seen_sig = -1;
+
+static void signal_func(int sig)
+{
+seen_sig = sig;
+}
+
+static void *thread_func(void *arg)
+{
+kill(getpid(), SIGUSR2);
+return NULL;
+}
+
+int main(void)
+{
+struct sigaction act = {
+.sa_handler = signal_func,
+};
+pthread_t thread;
+sigset_t set;
+int sig;
+
+assert(sigaction(SIGUSR1, &act, NULL) == 0);
+
+assert(sigemptyset(&set) == 0);
+assert(sigaddset(&set, SIGUSR2) == 0);
+assert(sigprocmask(SIG_BLOCK, &set, NULL) == 0);
+
+kill(getpid(), SIGUSR1);
+assert(seen_sig == SIGUSR1);
+
+assert(pthread_create(&thread, NULL, thread_func, NULL) == 0);
+assert(sigwait(&set, &sig) == 0);
+assert(sig == SIGUSR2);
+assert(pthread_join(thread, NULL) == 0);
+
+return EXIT_SUCCESS;
+}
--
2.47.0
Re: [PATCH v4 16/19] s390x: Rebuild IPLB for SCSI device directly from DIAG308
On 17/10/2024 03.47, jro...@linux.ibm.com wrote:
From: Jared Rossi
Because virtio-scsi type devices use a non-architected IPLB pbt code they cannot
be set and stored normally. Instead, the IPLB must be rebuilt during re-ipl.
As s390x does not natively support multiple boot devices, the devno field is
used to store the position in the boot order for the device.
Handling the rebuild as part of DIAG308 removes the need to check the devices
for invalid IPLBs later in the IPL.
Signed-off-by: Jared Rossi
---
hw/s390x/ipl.h | 11 --
include/hw/s390x/ipl/qipl.h | 3 +-
hw/s390x/ipl.c | 75 +++--
pc-bios/s390-ccw/jump2ipl.c | 11 --
target/s390x/diag.c | 9 -
5 files changed, 39 insertions(+), 70 deletions(-)
diff --git a/hw/s390x/ipl.h b/hw/s390x/ipl.h
index 54eb48fd6e..aead1d6ae5 100644
--- a/hw/s390x/ipl.h
+++ b/hw/s390x/ipl.h
@@ -24,6 +24,7 @@
void s390_ipl_convert_loadparm(char *ascii_lp, uint8_t *ebcdic_lp);
void s390_ipl_fmt_loadparm(uint8_t *loadparm, char *str, Error **errp);
+void s390_rebuild_iplb(uint16_t index, IplParameterBlock *iplb);
void s390_ipl_update_diag308(IplParameterBlock *iplb);
int s390_ipl_prepare_pv_header(Error **errp);
int s390_ipl_pv_unpack(void);
@@ -65,7 +66,8 @@ struct S390IPLState {
bool enforce_bios;
bool iplb_valid;
bool iplb_valid_pv;
-bool netboot;
+bool rebuilt_iplb;
+uint16_t iplb_index;
/* reset related properties don't have to be migrated or reset */
enum s390_reset reset_type;
int reset_cpu_index;
@@ -172,11 +174,14 @@ static inline bool iplb_valid_pv(IplParameterBlock *iplb)
static inline bool iplb_valid(IplParameterBlock *iplb)
{
+uint32_t len = be32_to_cpu(iplb->len);
+
switch (iplb->pbt) {
case S390_IPL_TYPE_FCP:
-return be32_to_cpu(iplb->len) >= S390_IPLB_MIN_FCP_LEN;
+return len >= S390_IPLB_MIN_FCP_LEN;
case S390_IPL_TYPE_CCW:
-return be32_to_cpu(iplb->len) >= S390_IPLB_MIN_CCW_LEN;
+return (len >= S390_IPLB_MIN_CCW_LEN);
Style inconsistency: In the FCP case, you did the return statement without
parentheses, so I'd suggest to remove them here, too.
+case S390_IPL_TYPE_QEMU_SCSI:
default:
return false;
}
diff --git a/include/hw/s390x/ipl/qipl.h b/include/hw/s390x/ipl/qipl.h
index e56b181298..451f3b1684 100644
--- a/include/hw/s390x/ipl/qipl.h
+++ b/include/hw/s390x/ipl/qipl.h
@@ -28,7 +28,8 @@
*/
struct QemuIplParameters {
uint8_t qipl_flags;
-uint8_t reserved1[3];
+uint8_t index;
+uint8_t reserved1[2];
uint64_t reserved2;
uint32_t boot_menu_timeout;
uint8_t reserved3[2];
diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c
index aec79f41a8..50fde05b67 100644
--- a/hw/s390x/ipl.c
+++ b/hw/s390x/ipl.c
@@ -448,7 +448,6 @@ void s390_ipl_convert_loadparm(char *ascii_lp, uint8_t
*ebcdic_lp)
static bool s390_build_iplb(DeviceState *dev_st, IplParameterBlock *iplb)
{
-S390IPLState *ipl = get_ipl_device();
CcwDevice *ccw_dev = NULL;
SCSIDevice *sd;
int devtype;
@@ -481,9 +480,6 @@ static bool s390_build_iplb(DeviceState *dev_st,
IplParameterBlock *iplb)
iplb->ccw.ssid = ccw_dev->sch->ssid & 3;
break;
case CCW_DEVTYPE_VIRTIO_NET:
-/* The S390IPLState netboot is true if ANY IPLB may use netboot */
-ipl->netboot = true;
-/* Fall through to CCW_DEVTYPE_VIRTIO case */
case CCW_DEVTYPE_VIRTIO:
iplb->len = cpu_to_be32(S390_IPLB_MIN_CCW_LEN);
iplb->blk0_len =
@@ -508,6 +504,17 @@ static bool s390_build_iplb(DeviceState *dev_st,
IplParameterBlock *iplb)
return false;
}
+
Remove the additonal empty line, please.
+void s390_rebuild_iplb(uint16_t dev_index, IplParameterBlock *iplb)
+{
+S390IPLState *ipl = get_ipl_device();
+uint16_t index;
+index = ipl->rebuilt_iplb ? ipl->iplb_index : dev_index;
+
+ipl->rebuilt_iplb = s390_build_iplb(get_boot_device(index), iplb);
+ipl->iplb_index = index;
+}
With the nits fixed:
Acked-by: Thomas Huth
Thomas
Re: [QEMU PATCH] hw/cxl/cxl-mailbox-util: Fix output buffer index update when retrieving DC extents
On Tue, 15 Oct 2024 11:51:26 -0700
nifan@gmail.com wrote:
> From: Fan Ni
>
> In the function of retrieving DC extents (cmd_dcd_get_dyn_cap_ext_list),
> the output buffer index was not correctly updated while iterating the
> extent list on the device, leaving the extents returned incorrect except for
> the first one.
>
> Fixes: 1c9221f19e ("hw/mem/cxl_type3: Add DC extent list representative ...")
> Signed-off-by: Fan Ni
I'll queue this up alongside that other fix.
thanks,
Jonathan
p.s. I'm having some issues with the list servers bouncing my emails so this
may not reach the list.
> ---
> hw/cxl/cxl-mailbox-utils.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/hw/cxl/cxl-mailbox-utils.c b/hw/cxl/cxl-mailbox-utils.c
> index c82ad50ac8..58f8930272 100644
> --- a/hw/cxl/cxl-mailbox-utils.c
> +++ b/hw/cxl/cxl-mailbox-utils.c
> @@ -2233,6 +2233,7 @@ static CXLRetCode cmd_dcd_get_dyn_cap_ext_list(const
> struct cxl_cmd *cmd,
> stw_le_p(&out_rec->shared_seq, ent->shared_seq);
>
> record_done++;
> +out_rec++;
> if (record_done == record_count) {
> break;
> }
[PATCH v2 04/31] block: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to qobject/. Signed-off-by: Daniel P. Berrangé --- block.c | 8 block/blkdebug.c | 6 +++--- block/blkio.c| 2 +- block/blklogwrites.c | 4 ++-- block/blkverify.c| 4 ++-- block/copy-before-write.c| 2 +- block/copy-on-read.c | 2 +- block/curl.c | 4 ++-- block/file-posix.c | 4 ++-- block/file-win32.c | 4 ++-- block/gluster.c | 2 +- block/iscsi.c| 4 ++-- block/monitor/block-hmp-cmds.c | 2 +- block/nbd.c | 2 +- block/nfs.c | 4 ++-- block/null.c | 4 ++-- block/nvme.c | 4 ++-- block/parallels.c| 2 +- block/qapi-sysemu.c | 2 +- block/qapi.c | 10 +- block/qcow.c | 4 ++-- block/qcow2.c| 4 ++-- block/qed.c | 2 +- block/quorum.c | 6 +++--- block/rbd.c | 8 block/replication.c | 2 +- block/snapshot.c | 4 ++-- block/ssh.c | 4 ++-- block/stream.c | 2 +- block/vhdx.c | 2 +- block/vmdk.c | 2 +- block/vpc.c | 2 +- block/vvfat.c| 4 ++-- blockdev.c | 8 qemu-img.c | 4 ++-- qemu-io-cmds.c | 2 +- qemu-io.c| 4 ++-- qemu-nbd.c | 4 ++-- storage-daemon/qemu-storage-daemon.c | 4 ++-- 39 files changed, 74 insertions(+), 74 deletions(-) diff --git a/block.c b/block.c index 7d90007cae..fa3db17dc5 100644 --- a/block.c +++ b/block.c @@ -36,10 +36,10 @@ #include "qemu/main-loop.h" #include "qemu/module.h" #include "qapi/error.h" -#include "qapi/qmp/qdict.h" -#include "qapi/qmp/qjson.h" -#include "qapi/qmp/qnull.h" -#include "qapi/qmp/qstring.h" +#include "qobject/qdict.h" +#include "qobject/qjson.h" +#include "qobject/qnull.h" +#include "qobject/qstring.h" #include "qapi/qobject-output-visitor.h" #include "qapi/qapi-visit-block-core.h" #include "sysemu/block-backend.h" diff --git a/block/blkdebug.c b/block/blkdebug.c index c95c818c38..e560702703 100644 --- a/block/blkdebug.c +++ b/block/blkdebug.c @@ -33,9 +33,9 @@ #include "qemu/module.h" #include "qemu/option.h" #include "qapi/qapi-visit-block-core.h" -#include "qapi/qmp/qdict.h" -#include "qapi/qmp/qlist.h" -#include "qapi/qmp/qstring.h" +#include "qobject/qdict.h" +#include "qobject/qlist.h" +#include "qobject/qstring.h" #include "qapi/qobject-input-visitor.h" #include "sysemu/qtest.h" diff --git a/block/blkio.c b/block/blkio.c index e0e765af63..c99ce6bdf7 100644 --- a/block/blkio.c +++ b/block/blkio.c @@ -16,7 +16,7 @@ #include "qemu/defer-call.h" #include "qapi/error.h" #include "qemu/error-report.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "qemu/module.h" #include "sysemu/block-backend.h" #include "exec/memory.h" /* for ram_block_discard_disable() */ diff --git a/block/blklogwrites.c b/block/blklogwrites.c index ed38a93f21..b0f78c4bc7 100644 --- a/block/blklogwrites.c +++ b/block/blklogwrites.c @@ -14,8 +14,8 @@ #include "qemu/sockets.h" /* for EINPROGRESS on Windows */ #include "block/block-io.h" #include "block/block_int.h" -#include "qapi/qmp/qdict.h" -#include "qapi/qmp/qstring.h" +#include "qobject/qdict.h" +#include "qobject/qstring.h" #include "qemu/cutils.h" #include "qemu/module.h" #include "qemu/option.h" diff --git a/block/blkverify.c b/block/blkverify.c index 5a9bf674d9..db79a36681 100644 --- a/block/blkverify.c +++ b/block/blkverify.c @@ -12,8 +12,8 @@ #include "qemu/sockets.h" /* for EINPROGRESS on Windows */ #include "block/block-io.h" #include "block/block_int.h" -#include "qapi/qmp/qdict.h" -#include "qapi/qmp/qstring.h" +#include "qobject/qdict.h" +#include "qobject/qstring.h" #include "qemu/cutils.h" #include "qemu/module.h" #include "qemu/option.h" diff --git a/block/copy-before-write.c b/block/copy-before-write.c index 81afeff1c7..35a17e9099 100644 --- a/block/copy-before-write.c +++ b/block/copy-before-write.c @@ -24,7 +24,7 @@ */ #include "qemu/osdep.h" -#include "qapi/qmp/qjson.h" +#include "qobject/qjson.h" #include "sysemu/block-backend.h" #include "qemu/cutils.h" diff --git a/block/copy-on-read.c b/block/copy-on-read.c index c36f253d16..accf1402f0 100644 --- a/block/copy-on-read.c +++ b/block/copy-on-read.c @@ -25,7 +25,7 @@ #include "block/block_int.h" #include "qemu/module.h" #include "qapi/error.h" -#i
[PATCH v2 00/31] include: move include/qapi/qmp/ to include/qobject/
To repeat the 1st patch commit message... The general expectation is that header files should follow the same file/path naming scheme as the corresponding source file. There are various historical exceptions to this practice in QEMU, with one of the most notable being the include/qapi/qmp/ directory. Most of the headers there correspond to source files in qobject/. This patch corrects that inconsistency by creating include/qobject/. The only outlier is include/qapi/qmp/dispatch.h which gets renamed to include/qapi/qmp-registry.h. To allow the code to continue to build, symlinks are temporarily added in $QEMU/qapi/qmp/ to point to the new location. This allows git to show a simple 'rename' diff in the 1st patch, which isn't possible if we put the symlinks straight in $QEMU/include/qapi/qmp/. The 27 patches that follow are mechanical updates to each top level sub-directory. The final patch removes the temporary compat symlinks. It was questioned last time whether this should all just be one big bang commit. I don't mind either way, just the end result that matters to me. Changed in v2: - Don't move include/qapi/qmp/qerror.h, as it is not the same kind of thing as the other qobject related headers, and this header is deprecated & (slowly) getting eliminated anyway - Tacked on two trivial patches removing redundant imports of qerror.h. Strictly they're independant of this series, so could just go to qemu-trivial on their own Daniel P. Berrangé (31): include: move include/qapi/qmp/ to include/qobject/ audio: adapt to new import path for qobject data type headers authz: adapt to new import path for qobject data type headers block: adapt to new import path for qobject data type headers backends: adapt to new import path for qobject data type headers chardev: adapt to new import path for qobject data type headers docs: adapt to new import path for qobject data type headers dump: adapt to new import path for qobject data type headers hw: adapt to new import path for qobject data type headers include: adapt to new import path for qobject data type headers migration: adapt to new import path for qobject data type headers monitor: adapt to new import path for qobject data type headers net: adapt to new import path for qobject data type headers qapi: adapt to new import path for qobject data type headers qga: adapt to new import path for qobject data type headers qobject: adapt to new import path for qobject data type headers qom: adapt to new import path for qobject data type headers replay: adapt to new import path for qobject data type headers scripts: adapt to new import path for qobject data type headers scsi: adapt to new import path for qobject data type headers stats: adapt to new import path for qobject data type headers stubs: adapt to new import path for qobject data type headers system: adapt to new import path for qobject data type headers target: adapt to new import path for qobject data type headers tests: adapt to new import path for qobject data type headers trace: adapt to new import path for qobject data type headers ui: adapt to new import path for qobject data type headers util: adapt to new import path for qobject data type headers qapi: remove header file compatibility symlinks qga: remove unused qerror.h header system: remove unused qerror.h header MAINTAINERS | 5 + audio/audio-hmp-cmds.c | 2 +- audio/audio.c | 2 +- authz/listfile.c| 4 ++-- backends/cryptodev-hmp-cmds.c | 2 +- block.c | 8 block/blkdebug.c| 6 +++--- block/blkio.c | 2 +- block/blklogwrites.c| 4 ++-- block/blkverify.c | 4 ++-- block/copy-before-write.c | 2 +- block/copy-on-read.c| 2 +- block/curl.c| 4 ++-- block/file-posix.c | 4 ++-- block/file-win32.c | 4 ++-- block/gluster.c | 2 +- block/iscsi.c | 4 ++-- block/monitor/block-hmp-cmds.c | 2 +- block/nbd.c | 2 +- block/nfs.c | 4 ++-- block/null.c| 4 ++-- block/nvme.c| 4 ++-- block/parallels.c | 2 +- block/qapi-sysemu.c | 2 +- block/qapi.c| 10 +- block/qcow.c| 4 ++-- block/qcow2.c | 4 ++-- blo
[PATCH v2 24/31] target: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to qobject/. Signed-off-by: Daniel P. Berrangé --- target/arm/arm-qmp-cmds.c | 2 +- target/i386/cpu-apic.c| 2 +- target/i386/cpu-sysemu.c | 2 +- target/i386/monitor.c | 2 +- target/loongarch/loongarch-qmp-cmds.c | 2 +- target/ppc/cpu_init.c | 2 +- target/riscv/riscv-qmp-cmds.c | 4 ++-- target/s390x/cpu_models_sysemu.c | 2 +- 8 files changed, 9 insertions(+), 9 deletions(-) diff --git a/target/arm/arm-qmp-cmds.c b/target/arm/arm-qmp-cmds.c index 3cc8cc738b..c89fd3258f 100644 --- a/target/arm/arm-qmp-cmds.c +++ b/target/arm/arm-qmp-cmds.c @@ -28,7 +28,7 @@ #include "qapi/qobject-input-visitor.h" #include "qapi/qapi-commands-machine-target.h" #include "qapi/qapi-commands-misc-target.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "qom/qom-qobject.h" static GICCapability *gic_cap_new(int version) diff --git a/target/i386/cpu-apic.c b/target/i386/cpu-apic.c index d397ec94dc..9fd4d6eab5 100644 --- a/target/i386/cpu-apic.c +++ b/target/i386/cpu-apic.c @@ -7,7 +7,7 @@ */ #include "qemu/osdep.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "qapi/error.h" #include "monitor/monitor.h" #include "monitor/hmp-target.h" diff --git a/target/i386/cpu-sysemu.c b/target/i386/cpu-sysemu.c index 227ac021f6..96b8006b27 100644 --- a/target/i386/cpu-sysemu.c +++ b/target/i386/cpu-sysemu.c @@ -21,7 +21,7 @@ #include "cpu.h" #include "qapi/error.h" #include "qapi/qapi-visit-run-state.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "qapi/qobject-input-visitor.h" #include "qom/qom-qobject.h" #include "qapi/qapi-commands-machine-target.h" diff --git a/target/i386/monitor.c b/target/i386/monitor.c index 2d766b2637..3ea92b066e 100644 --- a/target/i386/monitor.c +++ b/target/i386/monitor.c @@ -27,7 +27,7 @@ #include "monitor/monitor.h" #include "monitor/hmp-target.h" #include "monitor/hmp.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "qapi/error.h" #include "qapi/qapi-commands-misc-target.h" #include "qapi/qapi-commands-misc.h" diff --git a/target/loongarch/loongarch-qmp-cmds.c b/target/loongarch/loongarch-qmp-cmds.c index 8721a5eb13..f45c532e42 100644 --- a/target/loongarch/loongarch-qmp-cmds.c +++ b/target/loongarch/loongarch-qmp-cmds.c @@ -10,7 +10,7 @@ #include "qapi/error.h" #include "qapi/qapi-commands-machine-target.h" #include "cpu.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "qapi/qobject-input-visitor.h" #include "qom/qom-qobject.h" diff --git a/target/ppc/cpu_init.c b/target/ppc/cpu_init.c index 23881d09e9..b62c49b6d5 100644 --- a/target/ppc/cpu_init.c +++ b/target/ppc/cpu_init.c @@ -32,7 +32,7 @@ #include "qemu/module.h" #include "qemu/qemu-print.h" #include "qapi/error.h" -#include "qapi/qmp/qnull.h" +#include "qobject/qnull.h" #include "qapi/visitor.h" #include "hw/qdev-properties.h" #include "hw/ppc/ppc.h" diff --git a/target/riscv/riscv-qmp-cmds.c b/target/riscv/riscv-qmp-cmds.c index d363dc318d..aff59b83c6 100644 --- a/target/riscv/riscv-qmp-cmds.c +++ b/target/riscv/riscv-qmp-cmds.c @@ -26,8 +26,8 @@ #include "qapi/error.h" #include "qapi/qapi-commands-machine-target.h" -#include "qapi/qmp/qbool.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qbool.h" +#include "qobject/qdict.h" #include "qapi/qobject-input-visitor.h" #include "qapi/visitor.h" #include "qom/qom-qobject.h" diff --git a/target/s390x/cpu_models_sysemu.c b/target/s390x/cpu_models_sysemu.c index f6df691b66..ea595a00d4 100644 --- a/target/s390x/cpu_models_sysemu.c +++ b/target/s390x/cpu_models_sysemu.c @@ -18,7 +18,7 @@ #include "qapi/error.h" #include "qapi/visitor.h" #include "qapi/qobject-input-visitor.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "qapi/qapi-commands-machine-target.h" static void list_add_feat(const char *name, void *opaque); -- 2.46.0
[PATCH v2 17/31] qom: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to qobject/. Signed-off-by: Daniel P. Berrangé --- qom/object.c| 10 +- qom/object_interfaces.c | 6 +++--- qom/qom-hmp-cmds.c | 4 ++-- qom/qom-qmp-cmds.c | 2 +- 4 files changed, 11 insertions(+), 11 deletions(-) diff --git a/qom/object.c b/qom/object.c index 11424cf471..f2fd40203e 100644 --- a/qom/object.c +++ b/qom/object.c @@ -23,16 +23,16 @@ #include "qapi/qobject-input-visitor.h" #include "qapi/forward-visitor.h" #include "qapi/qapi-builtin-visit.h" -#include "qapi/qmp/qjson.h" +#include "qobject/qjson.h" #include "trace.h" /* TODO: replace QObject with a simpler visitor to avoid a dependency * of the QOM core on QObject? */ #include "qom/qom-qobject.h" -#include "qapi/qmp/qbool.h" -#include "qapi/qmp/qlist.h" -#include "qapi/qmp/qnum.h" -#include "qapi/qmp/qstring.h" +#include "qobject/qbool.h" +#include "qobject/qlist.h" +#include "qobject/qnum.h" +#include "qobject/qstring.h" #include "qemu/error-report.h" #define MAX_INTERFACES 32 diff --git a/qom/object_interfaces.c b/qom/object_interfaces.c index e0833c8bfe..c752d4f730 100644 --- a/qom/object_interfaces.c +++ b/qom/object_interfaces.c @@ -3,10 +3,10 @@ #include "qemu/cutils.h" #include "qapi/error.h" #include "qapi/qapi-visit-qom.h" -#include "qapi/qmp/qobject.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qobject.h" +#include "qobject/qdict.h" #include "qapi/qmp/qerror.h" -#include "qapi/qmp/qjson.h" +#include "qobject/qjson.h" #include "qapi/qobject-input-visitor.h" #include "qapi/qobject-output-visitor.h" #include "qom/object_interfaces.h" diff --git a/qom/qom-hmp-cmds.c b/qom/qom-hmp-cmds.c index 6e3a2175a4..a00a564b1e 100644 --- a/qom/qom-hmp-cmds.c +++ b/qom/qom-hmp-cmds.c @@ -11,8 +11,8 @@ #include "monitor/monitor.h" #include "qapi/error.h" #include "qapi/qapi-commands-qom.h" -#include "qapi/qmp/qdict.h" -#include "qapi/qmp/qjson.h" +#include "qobject/qdict.h" +#include "qobject/qjson.h" #include "qemu/readline.h" #include "qom/object.h" #include "qom/object_interfaces.h" diff --git a/qom/qom-qmp-cmds.c b/qom/qom-qmp-cmds.c index e91a235347..7880da3566 100644 --- a/qom/qom-qmp-cmds.c +++ b/qom/qom-qmp-cmds.c @@ -20,7 +20,7 @@ #include "qapi/qapi-commands-qdev.h" #include "qapi/qapi-commands-qom.h" #include "qapi/qapi-visit-qom.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "qapi/qmp/qerror.h" #include "qapi/qobject-input-visitor.h" #include "qapi/qobject-output-visitor.h" -- 2.46.0
[PATCH v2 20/31] scsi: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to qobject/. Signed-off-by: Daniel P. Berrangé --- scsi/qemu-pr-helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scsi/qemu-pr-helper.c b/scsi/qemu-pr-helper.c index c6c6347e9b..b69dd982d6 100644 --- a/scsi/qemu-pr-helper.c +++ b/scsi/qemu-pr-helper.c @@ -47,7 +47,7 @@ #include "qemu/log.h" #include "qemu/systemd.h" #include "qapi/util.h" -#include "qapi/qmp/qstring.h" +#include "qobject/qstring.h" #include "io/channel-socket.h" #include "trace/control.h" #include "qemu-version.h" -- 2.46.0
[PATCH v2 23/31] system: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to qobject/. Signed-off-by: Daniel P. Berrangé --- system/device_tree.c | 2 +- system/dirtylimit.c| 2 +- system/qdev-monitor.c | 6 +++--- system/rtc.c | 1 + system/runstate-hmp-cmds.c | 2 +- system/vl.c| 6 +++--- 6 files changed, 10 insertions(+), 9 deletions(-) diff --git a/system/device_tree.c b/system/device_tree.c index 2e38259d34..446e49cef6 100644 --- a/system/device_tree.c +++ b/system/device_tree.c @@ -28,7 +28,7 @@ #include "hw/boards.h" #include "qemu/config-file.h" #include "qapi/qapi-commands-machine.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "monitor/hmp.h" #include diff --git a/system/dirtylimit.c b/system/dirtylimit.c index ab20da34bb..644b0060ce 100644 --- a/system/dirtylimit.c +++ b/system/dirtylimit.c @@ -13,7 +13,7 @@ #include "qemu/osdep.h" #include "qemu/main-loop.h" #include "qapi/qapi-commands-migration.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "qapi/error.h" #include "sysemu/dirtyrate.h" #include "sysemu/dirtylimit.h" diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c index 44994ea0e1..e2f8abed8b 100644 --- a/system/qdev-monitor.c +++ b/system/qdev-monitor.c @@ -25,10 +25,10 @@ #include "sysemu/arch_init.h" #include "qapi/error.h" #include "qapi/qapi-commands-qdev.h" -#include "qapi/qmp/dispatch.h" -#include "qapi/qmp/qdict.h" +#include "qapi/qmp-registry.h" +#include "qobject/qdict.h" #include "qapi/qmp/qerror.h" -#include "qapi/qmp/qstring.h" +#include "qobject/qstring.h" #include "qapi/qobject-input-visitor.h" #include "qemu/config-file.h" #include "qemu/error-report.h" diff --git a/system/rtc.c b/system/rtc.c index 216d2aee3a..e3bc2095f9 100644 --- a/system/rtc.c +++ b/system/rtc.c @@ -25,6 +25,7 @@ #include "qemu/osdep.h" #include "qemu/cutils.h" #include "qapi/error.h" +#include "qapi/qmp/qerror.h" #include "qemu/error-report.h" #include "qemu/option.h" #include "qemu/timer.h" diff --git a/system/runstate-hmp-cmds.c b/system/runstate-hmp-cmds.c index 2df670f0c0..be1d676992 100644 --- a/system/runstate-hmp-cmds.c +++ b/system/runstate-hmp-cmds.c @@ -19,7 +19,7 @@ #include "monitor/monitor.h" #include "qapi/error.h" #include "qapi/qapi-commands-run-state.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "qemu/accel.h" void hmp_info_status(Monitor *mon, const QDict *qdict) diff --git a/system/vl.c b/system/vl.c index e83b3b2608..1e5525c1c7 100644 --- a/system/vl.c +++ b/system/vl.c @@ -31,9 +31,9 @@ #include "hw/qdev-properties.h" #include "qapi/compat-policy.h" #include "qapi/error.h" -#include "qapi/qmp/qdict.h" -#include "qapi/qmp/qstring.h" -#include "qapi/qmp/qjson.h" +#include "qobject/qdict.h" +#include "qobject/qstring.h" +#include "qobject/qjson.h" #include "qemu-version.h" #include "qemu/cutils.h" #include "qemu/help_option.h" -- 2.46.0
[PATCH v2 08/31] dump: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to
qobject/.
Signed-off-by: Daniel P. Berrangé
---
dump/dump-hmp-cmds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dump/dump-hmp-cmds.c b/dump/dump-hmp-cmds.c
index d9340427c3..21023db6fd 100644
--- a/dump/dump-hmp-cmds.c
+++ b/dump/dump-hmp-cmds.c
@@ -10,7 +10,7 @@
#include "monitor/monitor.h"
#include "qapi/error.h"
#include "qapi/qapi-commands-dump.h"
-#include "qapi/qmp/qdict.h"
+#include "qobject/qdict.h"
void hmp_dump_guest_memory(Monitor *mon, const QDict *qdict)
{
--
2.46.0
[PATCH v2 27/31] ui: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to qobject/. Signed-off-by: Daniel P. Berrangé --- ui/ui-hmp-cmds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ui/ui-hmp-cmds.c b/ui/ui-hmp-cmds.c index 26c8ced1f2..980a8bbc51 100644 --- a/ui/ui-hmp-cmds.c +++ b/ui/ui-hmp-cmds.c @@ -21,7 +21,7 @@ #include "monitor/monitor-internal.h" #include "qapi/error.h" #include "qapi/qapi-commands-ui.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "qemu/cutils.h" #include "ui/console.h" #include "ui/input.h" -- 2.46.0
[PATCH v2 30/31] qga: remove unused qerror.h header
Signed-off-by: Daniel P. Berrangé --- qga/commands-bsd.c | 1 - qga/commands-linux.c | 1 - qga/commands-posix.c | 1 - 3 files changed, 3 deletions(-) diff --git a/qga/commands-bsd.c b/qga/commands-bsd.c index 9ce48af311..94ff6fee6a 100644 --- a/qga/commands-bsd.c +++ b/qga/commands-bsd.c @@ -12,7 +12,6 @@ #include "qemu/osdep.h" #include "qga-qapi-commands.h" -#include "qapi/qmp/qerror.h" #include "qapi/error.h" #include "qemu/queue.h" #include "commands-common.h" diff --git a/qga/commands-linux.c b/qga/commands-linux.c index 51d5e3d927..9b1746b24f 100644 --- a/qga/commands-linux.c +++ b/qga/commands-linux.c @@ -15,7 +15,6 @@ #include "qapi/error.h" #include "qga-qapi-commands.h" #include "qapi/error.h" -#include "qapi/qmp/qerror.h" #include "commands-common.h" #include "cutils.h" #include diff --git a/qga/commands-posix.c b/qga/commands-posix.c index c2bd0b4316..389c5eeb5d 100644 --- a/qga/commands-posix.c +++ b/qga/commands-posix.c @@ -18,7 +18,6 @@ #include #include "qga-qapi-commands.h" #include "qapi/error.h" -#include "qapi/qmp/qerror.h" #include "qemu/host-utils.h" #include "qemu/sockets.h" #include "qemu/base64.h" -- 2.46.0
[PATCH v2 26/31] trace: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to qobject/. Signed-off-by: Daniel P. Berrangé --- trace/trace-hmp-cmds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/trace/trace-hmp-cmds.c b/trace/trace-hmp-cmds.c index d38dd600de..45f4335ff5 100644 --- a/trace/trace-hmp-cmds.c +++ b/trace/trace-hmp-cmds.c @@ -27,7 +27,7 @@ #include "monitor/monitor.h" #include "qapi/error.h" #include "qapi/qapi-commands-trace.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "trace/control.h" #ifdef CONFIG_TRACE_SIMPLE #include "trace/simple.h" -- 2.46.0
[PATCH v2 06/31] chardev: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to qobject/. Signed-off-by: Daniel P. Berrangé --- chardev/char-hmp-cmds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chardev/char-hmp-cmds.c b/chardev/char-hmp-cmds.c index 287c2b1bcd..8e9e1c1c02 100644 --- a/chardev/char-hmp-cmds.c +++ b/chardev/char-hmp-cmds.c @@ -19,7 +19,7 @@ #include "monitor/monitor.h" #include "qapi/error.h" #include "qapi/qapi-commands-char.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "qemu/config-file.h" #include "qemu/option.h" -- 2.46.0
[PATCH v2 19/31] scripts: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to
qobject/.
Signed-off-by: Daniel P. Berrangé
---
scripts/qapi/commands.py | 6 +++---
scripts/qapi/events.py | 2 +-
scripts/qapi/introspect.py | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/scripts/qapi/commands.py b/scripts/qapi/commands.py
index 79951a841f..74f341b2c7 100644
--- a/scripts/qapi/commands.py
+++ b/scripts/qapi/commands.py
@@ -320,7 +320,7 @@ def _begin_user_module(self, name: str) -> None:
#include "qemu/osdep.h"
#include "qapi/compat-policy.h"
#include "qapi/visitor.h"
-#include "qapi/qmp/qdict.h"
+#include "qobject/qdict.h"
#include "qapi/dealloc-visitor.h"
#include "qapi/error.h"
#include "%(visit)s.h"
@@ -330,7 +330,7 @@ def _begin_user_module(self, name: str) -> None:
if self._gen_tracing and commands != 'qapi-commands':
self._genc.add(mcgen('''
-#include "qapi/qmp/qjson.h"
+#include "qobject/qjson.h"
#include "trace/trace-%(nm)s_trace_events.h"
''',
nm=c_name(commands, protect=False)))
@@ -346,7 +346,7 @@ def _begin_user_module(self, name: str) -> None:
def visit_begin(self, schema: QAPISchema) -> None:
self._add_module('./init', ' * QAPI Commands initialization')
self._genh.add(mcgen('''
-#include "qapi/qmp/dispatch.h"
+#include "qapi/qmp-registry.h"
void %(c_prefix)sqmp_init_marshal(QmpCommandList *cmds);
''',
diff --git a/scripts/qapi/events.py b/scripts/qapi/events.py
index d1f639981a..d179b0ed69 100644
--- a/scripts/qapi/events.py
+++ b/scripts/qapi/events.py
@@ -194,7 +194,7 @@ def _begin_user_module(self, name: str) -> None:
#include "%(visit)s.h"
#include "qapi/compat-policy.h"
#include "qapi/error.h"
-#include "qapi/qmp/qdict.h"
+#include "qobject/qdict.h"
#include "qapi/qmp-event.h"
''',
events=events, visit=visit,
diff --git a/scripts/qapi/introspect.py b/scripts/qapi/introspect.py
index ac14b20f30..42e5185c7c 100644
--- a/scripts/qapi/introspect.py
+++ b/scripts/qapi/introspect.py
@@ -197,7 +197,7 @@ def visit_end(self) -> None:
# generate C
name = c_name(self._prefix, protect=False) + 'qmp_schema_qlit'
self._genh.add(mcgen('''
-#include "qapi/qmp/qlit.h"
+#include "qobject/qlit.h"
extern const QLitObject %(c_name)s;
''',
--
2.46.0
[PATCH v2 07/31] docs: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to qobject/. Signed-off-by: Daniel P. Berrangé --- docs/devel/qapi-code-gen.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/devel/qapi-code-gen.rst b/docs/devel/qapi-code-gen.rst index 583207a8ec..ea26b8b473 100644 --- a/docs/devel/qapi-code-gen.rst +++ b/docs/devel/qapi-code-gen.rst @@ -1854,7 +1854,7 @@ Example:: #ifndef EXAMPLE_QAPI_INIT_COMMANDS_H #define EXAMPLE_QAPI_INIT_COMMANDS_H -#include "qapi/qmp/dispatch.h" +#include "qapi/qmp-registry.h" void example_qmp_init_marshal(QmpCommandList *cmds); @@ -1985,7 +1985,7 @@ Example:: #ifndef EXAMPLE_QAPI_INTROSPECT_H #define EXAMPLE_QAPI_INTROSPECT_H -#include "qapi/qmp/qlit.h" +#include "qobject/qlit.h" extern const QLitObject example_qmp_schema_qlit; -- 2.46.0
[PATCH v2 10/31] include: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to
qobject/.
Signed-off-by: Daniel P. Berrangé
---
include/block/qdict.h | 2 +-
include/qobject/qbool.h | 2 +-
include/qobject/qdict.h | 2 +-
include/qobject/qlist.h | 2 +-
include/qobject/qnull.h | 2 +-
include/qobject/qnum.h| 2 +-
include/qobject/qobject.h | 2 +-
include/qobject/qstring.h | 2 +-
8 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/block/qdict.h b/include/block/qdict.h
index b4c28d96a9..53c4df4cb2 100644
--- a/include/block/qdict.h
+++ b/include/block/qdict.h
@@ -10,7 +10,7 @@
#ifndef BLOCK_QDICT_H
#define BLOCK_QDICT_H
-#include "qapi/qmp/qdict.h"
+#include "qobject/qdict.h"
QObject *qdict_crumple(const QDict *src, Error **errp);
void qdict_flatten(QDict *qdict);
diff --git a/include/qobject/qbool.h b/include/qobject/qbool.h
index 0d09726939..b348e17867 100644
--- a/include/qobject/qbool.h
+++ b/include/qobject/qbool.h
@@ -14,7 +14,7 @@
#ifndef QBOOL_H
#define QBOOL_H
-#include "qapi/qmp/qobject.h"
+#include "qobject/qobject.h"
struct QBool {
struct QObjectBase_ base;
diff --git a/include/qobject/qdict.h b/include/qobject/qdict.h
index 82e90fc072..903e6e5462 100644
--- a/include/qobject/qdict.h
+++ b/include/qobject/qdict.h
@@ -13,7 +13,7 @@
#ifndef QDICT_H
#define QDICT_H
-#include "qapi/qmp/qobject.h"
+#include "qobject/qobject.h"
#include "qemu/queue.h"
#define QDICT_BUCKET_MAX 512
diff --git a/include/qobject/qlist.h b/include/qobject/qlist.h
index e4e985d435..0377bf824e 100644
--- a/include/qobject/qlist.h
+++ b/include/qobject/qlist.h
@@ -13,7 +13,7 @@
#ifndef QLIST_H
#define QLIST_H
-#include "qapi/qmp/qobject.h"
+#include "qobject/qobject.h"
#include "qemu/queue.h"
typedef struct QListEntry {
diff --git a/include/qobject/qnull.h b/include/qobject/qnull.h
index 7feb7c7d83..4423836a0c 100644
--- a/include/qobject/qnull.h
+++ b/include/qobject/qnull.h
@@ -13,7 +13,7 @@
#ifndef QNULL_H
#define QNULL_H
-#include "qapi/qmp/qobject.h"
+#include "qobject/qobject.h"
struct QNull {
struct QObjectBase_ base;
diff --git a/include/qobject/qnum.h b/include/qobject/qnum.h
index e86788dd2e..1ce24b3668 100644
--- a/include/qobject/qnum.h
+++ b/include/qobject/qnum.h
@@ -15,7 +15,7 @@
#ifndef QNUM_H
#define QNUM_H
-#include "qapi/qmp/qobject.h"
+#include "qobject/qobject.h"
typedef enum {
QNUM_I64,
diff --git a/include/qobject/qobject.h b/include/qobject/qobject.h
index 256d782688..a6244d0ce0 100644
--- a/include/qobject/qobject.h
+++ b/include/qobject/qobject.h
@@ -34,7 +34,7 @@
#include "qapi/qapi-builtin-types.h"
-/* Not for use outside include/qapi/qmp/ */
+/* Not for use outside include/qobject/ */
struct QObjectBase_ {
QType type;
size_t refcnt;
diff --git a/include/qobject/qstring.h b/include/qobject/qstring.h
index 318d815d6a..1e2abe4032 100644
--- a/include/qobject/qstring.h
+++ b/include/qobject/qstring.h
@@ -13,7 +13,7 @@
#ifndef QSTRING_H
#define QSTRING_H
-#include "qapi/qmp/qobject.h"
+#include "qobject/qobject.h"
struct QString {
struct QObjectBase_ base;
--
2.46.0
Re: [PULL 00/33] Endianness cleanup patches for 2024-10-15
On Tue, 15 Oct 2024 at 16:47, Philippe Mathieu-Daudé wrote: > > The following changes since commit c155d13167c6ace099e351e28125f9eb3694ae27: > > Merge tag 'chr-pull-request' of https://gitlab.com/marcandre.lureau/qemu > into staging (2024-10-15 10:30:43 +0100) > > are available in the Git repository at: > > https://github.com/philmd/qemu.git tags/single-binary-20241015 > > for you to fetch changes up to 3e8f019be77d1b648bca0af0121da3bb37766509: > > hw/mips: Have mips_cpu_create_with_clock() take an endianness argument > (2024-10-15 12:21:06 -0300) > > One checkpatch warning due to wide comment: > > WARNING: line over 80 characters > #108: FILE: hw/i386/multiboot.c:380: > +stl_le_p(bootinfo + MBI_BOOT_DEVICE, 0x8000); /* XXX: use the > -boot switch? */ > > > Remove some target-specific endianness knowledge from target/. > > For MIPS, propagate endianness at the board level, using QOM property. > > Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/9.2 for any user-visible changes. -- PMM
[PATCH v2 15/31] qga: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to qobject/. Signed-off-by: Daniel P. Berrangé --- qga/guest-agent-core.h | 2 +- qga/main.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/qga/guest-agent-core.h b/qga/guest-agent-core.h index b4e7c52c61..a536d07d0d 100644 --- a/qga/guest-agent-core.h +++ b/qga/guest-agent-core.h @@ -13,7 +13,7 @@ #ifndef GUEST_AGENT_CORE_H #define GUEST_AGENT_CORE_H -#include "qapi/qmp/dispatch.h" +#include "qapi/qmp-registry.h" #include "qga-qapi-types.h" #define QGA_READ_COUNT_DEFAULT 4096 diff --git a/qga/main.c b/qga/main.c index 50186760bf..e74c14b3fc 100644 --- a/qga/main.c +++ b/qga/main.c @@ -19,9 +19,9 @@ #include #endif #include "qemu/help-texts.h" -#include "qapi/qmp/json-parser.h" -#include "qapi/qmp/qdict.h" -#include "qapi/qmp/qjson.h" +#include "qobject/json-parser.h" +#include "qobject/qdict.h" +#include "qobject/qjson.h" #include "guest-agent-core.h" #include "qga-qapi-init-commands.h" #include "qapi/error.h" -- 2.46.0
Re: [PATCH v4 17/19] pc-bios/s390x: Enable multi-device boot loop
On 17/10/2024 03.47, jro...@linux.ibm.com wrote:
From: Jared Rossi
Allow attempts to boot from multiple IPL devices. If the first device fails to
IPL, select the pre-built IPLB for the next device in the boot order and attempt
to IPL from it. Continue this process until IPL is successful or there are no
devices left to try.
Signed-off-by: Jared Rossi
---
...
diff --git a/pc-bios/s390-ccw/main.c b/pc-bios/s390-ccw/main.c
index 9770290958..da3394de7c 100644
--- a/pc-bios/s390-ccw/main.c
+++ b/pc-bios/s390-ccw/main.c
@@ -55,6 +55,12 @@ void write_iplb_location(void)
}
}
+static void copy_qipl(void)
+{
+QemuIplParameters *early_qipl = (QemuIplParameters *)QIPL_ADDRESS;
+memcpy(&qipl, early_qipl, sizeof(QemuIplParameters));
+}
+
unsigned int get_loadparm_index(void)
{
return atoi(loadparm_str);
@@ -152,6 +158,7 @@ static void menu_setup(void)
/* If loadparm was set to any other value, then do not enable menu */
if (memcmp(loadparm_str, LOADPARM_EMPTY, LOADPARM_LEN) != 0) {
+menu_set_parms(qipl.qipl_flags && ~BOOT_MENU_FLAG_MASK, 0);
That "&&" looks fishy ... should it be a single "&" ?
Thomas
[PATCH v2 28/31] util: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to qobject/. Signed-off-by: Daniel P. Berrangé --- util/keyval.c | 6 +++--- util/qemu-config.c | 4 ++-- util/qemu-option.c | 8 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/util/keyval.c b/util/keyval.c index 66a5b4740f..a70629a481 100644 --- a/util/keyval.c +++ b/util/keyval.c @@ -91,9 +91,9 @@ #include "qemu/osdep.h" #include "qapi/error.h" -#include "qapi/qmp/qdict.h" -#include "qapi/qmp/qlist.h" -#include "qapi/qmp/qstring.h" +#include "qobject/qdict.h" +#include "qobject/qlist.h" +#include "qobject/qstring.h" #include "qemu/cutils.h" #include "qemu/keyval.h" #include "qemu/help_option.h" diff --git a/util/qemu-config.c b/util/qemu-config.c index a90c18dad2..d1fc49c507 100644 --- a/util/qemu-config.c +++ b/util/qemu-config.c @@ -1,8 +1,8 @@ #include "qemu/osdep.h" #include "block/qdict.h" /* for qdict_extract_subqdict() */ #include "qapi/error.h" -#include "qapi/qmp/qdict.h" -#include "qapi/qmp/qlist.h" +#include "qobject/qdict.h" +#include "qobject/qlist.h" #include "qemu/error-report.h" #include "qemu/option.h" #include "qemu/config-file.h" diff --git a/util/qemu-option.c b/util/qemu-option.c index 201f7a87f3..770300dff1 100644 --- a/util/qemu-option.c +++ b/util/qemu-option.c @@ -27,10 +27,10 @@ #include "qapi/error.h" #include "qemu/error-report.h" -#include "qapi/qmp/qbool.h" -#include "qapi/qmp/qdict.h" -#include "qapi/qmp/qnum.h" -#include "qapi/qmp/qstring.h" +#include "qobject/qbool.h" +#include "qobject/qdict.h" +#include "qobject/qnum.h" +#include "qobject/qstring.h" #include "qapi/qmp/qerror.h" #include "qemu/option_int.h" #include "qemu/cutils.h" -- 2.46.0
[PATCH v2 21/31] stats: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to qobject/. Signed-off-by: Daniel P. Berrangé --- stats/stats-hmp-cmds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/stats/stats-hmp-cmds.c b/stats/stats-hmp-cmds.c index 1f91bf8bd5..b93b471b1b 100644 --- a/stats/stats-hmp-cmds.c +++ b/stats/stats-hmp-cmds.c @@ -11,7 +11,7 @@ #include "monitor/monitor.h" #include "qemu/cutils.h" #include "hw/core/cpu.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "qapi/error.h" static void print_stats_schema_value(Monitor *mon, StatsSchemaValue *value) -- 2.46.0
[PATCH v2 16/31] qobject: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to
qobject/.
Signed-off-by: Daniel P. Berrangé
---
qobject/block-qdict.c | 8
qobject/json-parser-int.h | 2 +-
qobject/json-parser.c | 12 ++--
qobject/json-writer.c | 2 +-
qobject/qbool.c| 2 +-
qobject/qdict.c| 10 +-
qobject/qjson.c| 16
qobject/qlist.c| 10 +-
qobject/qlit.c | 14 +++---
qobject/qnull.c| 2 +-
qobject/qnum.c | 2 +-
qobject/qobject-internal.h | 2 +-
qobject/qobject.c | 12 ++--
qobject/qstring.c | 2 +-
14 files changed, 48 insertions(+), 48 deletions(-)
diff --git a/qobject/block-qdict.c b/qobject/block-qdict.c
index 4a83bda2c3..d0e1c63cf6 100644
--- a/qobject/block-qdict.c
+++ b/qobject/block-qdict.c
@@ -9,10 +9,10 @@
#include "qemu/osdep.h"
#include "block/qdict.h"
-#include "qapi/qmp/qbool.h"
-#include "qapi/qmp/qlist.h"
-#include "qapi/qmp/qnum.h"
-#include "qapi/qmp/qstring.h"
+#include "qobject/qbool.h"
+#include "qobject/qlist.h"
+#include "qobject/qnum.h"
+#include "qobject/qstring.h"
#include "qapi/qobject-input-visitor.h"
#include "qemu/cutils.h"
#include "qapi/error.h"
diff --git a/qobject/json-parser-int.h b/qobject/json-parser-int.h
index 16a25d00bb..8c01f23627 100644
--- a/qobject/json-parser-int.h
+++ b/qobject/json-parser-int.h
@@ -14,7 +14,7 @@
#ifndef JSON_PARSER_INT_H
#define JSON_PARSER_INT_H
-#include "qapi/qmp/json-parser.h"
+#include "qobject/json-parser.h"
typedef enum json_token_type {
JSON_ERROR = 0, /* must be zero, see json_lexer[] */
diff --git a/qobject/json-parser.c b/qobject/json-parser.c
index d498db6e70..7483e582fe 100644
--- a/qobject/json-parser.c
+++ b/qobject/json-parser.c
@@ -16,12 +16,12 @@
#include "qemu/cutils.h"
#include "qemu/unicode.h"
#include "qapi/error.h"
-#include "qapi/qmp/qbool.h"
-#include "qapi/qmp/qdict.h"
-#include "qapi/qmp/qlist.h"
-#include "qapi/qmp/qnull.h"
-#include "qapi/qmp/qnum.h"
-#include "qapi/qmp/qstring.h"
+#include "qobject/qbool.h"
+#include "qobject/qdict.h"
+#include "qobject/qlist.h"
+#include "qobject/qnull.h"
+#include "qobject/qnum.h"
+#include "qobject/qstring.h"
#include "json-parser-int.h"
struct JSONToken {
diff --git a/qobject/json-writer.c b/qobject/json-writer.c
index 309a31d57a..aac2c6ab71 100644
--- a/qobject/json-writer.c
+++ b/qobject/json-writer.c
@@ -14,7 +14,7 @@
*/
#include "qemu/osdep.h"
-#include "qapi/qmp/json-writer.h"
+#include "qobject/json-writer.h"
#include "qemu/unicode.h"
struct JSONWriter {
diff --git a/qobject/qbool.c b/qobject/qbool.c
index c7049c0c50..00d7066aae 100644
--- a/qobject/qbool.c
+++ b/qobject/qbool.c
@@ -12,7 +12,7 @@
*/
#include "qemu/osdep.h"
-#include "qapi/qmp/qbool.h"
+#include "qobject/qbool.h"
#include "qobject-internal.h"
/**
diff --git a/qobject/qdict.c b/qobject/qdict.c
index 8faff230d3..a90ac9ae2f 100644
--- a/qobject/qdict.c
+++ b/qobject/qdict.c
@@ -11,11 +11,11 @@
*/
#include "qemu/osdep.h"
-#include "qapi/qmp/qnum.h"
-#include "qapi/qmp/qdict.h"
-#include "qapi/qmp/qbool.h"
-#include "qapi/qmp/qnull.h"
-#include "qapi/qmp/qstring.h"
+#include "qobject/qnum.h"
+#include "qobject/qdict.h"
+#include "qobject/qbool.h"
+#include "qobject/qnull.h"
+#include "qobject/qstring.h"
#include "qobject-internal.h"
/**
diff --git a/qobject/qjson.c b/qobject/qjson.c
index 167fcb429c..c858dafb5e 100644
--- a/qobject/qjson.c
+++ b/qobject/qjson.c
@@ -13,14 +13,14 @@
#include "qemu/osdep.h"
#include "qapi/error.h"
-#include "qapi/qmp/json-parser.h"
-#include "qapi/qmp/json-writer.h"
-#include "qapi/qmp/qjson.h"
-#include "qapi/qmp/qbool.h"
-#include "qapi/qmp/qdict.h"
-#include "qapi/qmp/qlist.h"
-#include "qapi/qmp/qnum.h"
-#include "qapi/qmp/qstring.h"
+#include "qobject/json-parser.h"
+#include "qobject/json-writer.h"
+#include "qobject/qjson.h"
+#include "qobject/qbool.h"
+#include "qobject/qdict.h"
+#include "qobject/qlist.h"
+#include "qobject/qnum.h"
+#include "qobject/qstring.h"
typedef struct JSONParsingState {
JSONMessageParser parser;
diff --git a/qobject/qlist.c b/qobject/qlist.c
index 356ad946b0..41e6876d5b 100644
--- a/qobject/qlist.c
+++ b/qobject/qlist.c
@@ -11,11 +11,11 @@
*/
#include "qemu/osdep.h"
-#include "qapi/qmp/qbool.h"
-#include "qapi/qmp/qlist.h"
-#include "qapi/qmp/qnull.h"
-#include "qapi/qmp/qnum.h"
-#include "qapi/qmp/qstring.h"
+#include "qobject/qbool.h"
+#include "qobject/qlist.h"
+#include "qobject/qnull.h"
+#include "qobject/qnum.h"
+#include "qobject/qstring.h"
#include "qemu/queue.h"
#include "qobject-internal.h"
diff --git a/qobject/qlit.c b/qobject/qlit.c
index a62865b642..a44f47eaa5 100644
--- a/qobject/qlit.c
+++ b/qobject/qlit.c
@@ -15,13 +15,13 @@
#include "qemu/osdep.h"
-#include "qapi/qmp/qlit.h"
-#include "qapi/qmp/qbool.h"
-#include "qapi/qmp/qlist.h"
-#include "qapi/qmp/qnum.h"
-#incl
[PATCH v2 18/31] replay: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to qobject/. Signed-off-by: Daniel P. Berrangé --- replay/replay-debugging.c | 2 +- replay/replay-snapshot.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/replay/replay-debugging.c b/replay/replay-debugging.c index 82c66fff26..fd46a948d2 100644 --- a/replay/replay-debugging.c +++ b/replay/replay-debugging.c @@ -17,7 +17,7 @@ #include "monitor/hmp.h" #include "monitor/monitor.h" #include "qapi/qapi-commands-replay.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "qemu/timer.h" #include "block/snapshot.h" #include "migration/snapshot.h" diff --git a/replay/replay-snapshot.c b/replay/replay-snapshot.c index ccb4d89dda..37394b626e 100644 --- a/replay/replay-snapshot.c +++ b/replay/replay-snapshot.c @@ -14,7 +14,7 @@ #include "sysemu/replay.h" #include "replay-internal.h" #include "monitor/monitor.h" -#include "qapi/qmp/qstring.h" +#include "qobject/qstring.h" #include "qemu/error-report.h" #include "migration/vmstate.h" #include "migration/snapshot.h" -- 2.46.0
[PATCH] pcie: enable Extended tag field capability
PCI has 32 transactions, PCI Express devices can handle 256. SBSA ACS checks for this capability to be enabled on Arm server systems. Signed-off-by: Marcin Juszkiewicz --- SBSA Reference Platform work goes on so I am looking at PCIe related tests. SBSA ACS has test 824 which checks for PCIe device capabilities. BSA specification [1] (SBSA is on top of BSA) in section F.3.2 lists expected values for Device Capabilities Register: Device Capabilities Register Requirement Role based error reporting RCEC and RCiEP: Hardwired to 1 Endpoint L0s acceptable latency RCEC and RCiEP: Hardwired to 0 L1 acceptable latencyRCEC and RCiEP: Hardwired to 0 Captured slot power limit scale RCEC and RCiEP: Hardwired to 0 Captured slot power limit value RCEC and RCiEP: Hardwired to 0 Max payload size value must be compliant with PCIe spec Phantom functionsRCEC and RCiEP: Recommendation is to hardwire this bit to 0. Extended tag field Hardwired to 1 1. https://developer.arm.com/documentation/den0094/c/ QEMU leaves 'Extended tag field' with 0 as value: Capabilities: [e0] Express (v1) Root Complex Integrated Endpoint, IntMsgNum 0 DevCap: MaxPayload 128 bytes, PhantFunc 0 ExtTag- RBE+ FLReset- TEE-IO- >From what I read PCI has 32 transactions, PCI Express devices can handle 256 with Extended tag enabled (spec mentions also larger values but I lack PCIe knowledge). --- hw/pci/pcie.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c index 4b2f0805c6..54c0f1ec67 100644 --- a/hw/pci/pcie.c +++ b/hw/pci/pcie.c @@ -86,7 +86,8 @@ pcie_cap_v1_fill(PCIDevice *dev, uint8_t port, uint8_t type, uint8_t version) * Specification, Revision 1.1., or subsequent PCI Express Base * Specification revisions. */ -pci_set_long(exp_cap + PCI_EXP_DEVCAP, PCI_EXP_DEVCAP_RBER); +pci_set_long(exp_cap + PCI_EXP_DEVCAP, PCI_EXP_DEVCAP_RBER | + PCI_EXP_DEVCAP_EXT_TAG); pci_set_long(exp_cap + PCI_EXP_LNKCAP, (port << PCI_EXP_LNKCAP_PN_SHIFT) | --- base-commit: f774a677507966222624a9b2859f06ede7608100 change-id: 20241017-pcie-extend-a6a9de74dbd0 Best regards, -- Marcin Juszkiewicz
Re: [PATCH 0/1] Insert LibSPDM in QEMU enabling in-tree compilation
On Thu, Oct 17, 2024 at 7:00 AM Daniel P. Berrangé wrote: > On Thu, Oct 17, 2024 at 02:00:35PM +1000, Alistair Francis wrote: > > On Thu, Oct 17, 2024 at 2:35 AM htafr wrote: > > > > > > (I) Summary > > > > === > > > > > > This patch is the beginning of the support of the Security Protocol and > > > Data Model (SPDM). There are some known issues (see II), but it's > > > usable and not many users are going to use this functionality for now, > > > but for those who will it may facilitate the development. > > > > > > There are some people working with LibSPDM to implement the SPDM on > > > emulated devices, however current works that use QEMU compile LibSPDM > > > out-of-tree [1][2][3]. This patch enables the compilation of LibSPDM > when > > > user pass the parameter '--enable-libspdm' to configure file, this > option > > > is disabled by default. The following parameters were also added: > > > > > > --libspdm-crypto=CHOICE set LibSPDM crypto algorithm [mbedtls] > (choices: > > >mbedtls/openssl) > > > --libspdm-toolchain=VALUE > > >toolchain to use for LibSPDM compilation > [GCC] > > > > > > In order to facilitate future code development using LibSPDM API, this > > > patch also provides the definition of the macro 'CONFIG_LIBSPDM'. > > > > We have talked about this before, see > > https://patchew.org/QEMU/cover.1691509717.git.alistair.fran...@wdc.com/ > > > > The general agreement seemed to be that it will be hard to do SPDM > > configuration inside QEMU, hence the external library (like the QEMU > > TPM support). > > More generally, seeing this libspdm proposed for QEMU, without any > corresponding usage of it it dubious. It is hard to judge whether > it makes any sense, without seeing how it will be used in real > device code inside QEMU. > Currently, I'm working with EDK2 and QEMU so I have a branch [1] with ongoing modifications in files backends/spdm.c and hw/nvme/auth.c. Although the current modifications are able to exchange SPDM messages, it's far from being complete and it's not following better code practices yet. I'm making use of Alistair's and Mallawa's previous work in NVMe to authenticate it through PCI [2]. [1] WIP: SPDM integration Link: https://github.com/htafr/qemu/tree/libspdm-dev [2] WIP: SPDM in OVMF Link: https://github.com/htafr/edk2/tree/ovmf-spdm > > On the cryptography side, I'm not a fan of linking another > crypto library to QEMU, that's different from what we already > support in our crypto layer. openssl in particular is a problem > due to its licensing - people tend to hand-waive away the > licensing incompatibility by pretending openssl is a "system library" > but I disagree with that interpretation. > > > > (II) Known Limitations > > > > === > > > > > > 1. This patch enables LibSPDM in-tree compilation for Linux systems > only. > > > 2. LibSPDM compilation uses CMake, so meson build system is making use > > >of the CMake module [4]. > > > 3. Some problems may occur when compiling LibSPDM with MbedTls such as: > > > error: "_GNU_SOURCE" redefined [-Werror] > > > 10 | #define _GNU_SOURCE > > > > > >It's possible to compile using --disable-werror. > > > > > > (III) Sample configuration > > > > === > > > > > > ../configure \ > > > --disable-werror \ > > > --enable-libspdm \ > > > --libspdm-crypto=mbedtls \ > > > --enable-gcov > > > > > > References: > > > [1] riscv-spdm > > > Link: https://github.com/htafr/riscv-spdm > > > [2] spdm-benchmark > > > Link: https://github.com/rcaalves/spdm-benchmark > > > [3] qemu-spdm-emulation-guide > > > Link: https://github.com/twilfredo/qemu-spdm-emulation-guide > > > > This one has been merged upstream and mainline QEMU supports it now: > > > > https://www.qemu.org/docs/master/specs/spdm.html > > So with that merged, is this proposal for linking to libspdm redundant ? > > With regards, > Daniel > -- > |: https://berrange.com -o- > https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- > https://fstop138.berrange.com :| > |: https://entangle-photo.org-o- > https://www.instagram.com/dberrange :| > > I'm not sure if I understood the redundancy. Would it be against QEMU practices to have another openssl as well as mbedtls linked inside it? Also, I didn't know the LibSPDM insertion was already discussed previously as Alistair pointed out. I think I should have sent this patch as RFC instead. As this is my first interaction in any mail list, I'm sorry for any mistakes I made.
Re: [PATCH 0/1] Insert LibSPDM in QEMU enabling in-tree compilation
On Thu, Oct 17, 2024 at 10:37:21AM -0300, Ágatha Freitas wrote: > On Thu, Oct 17, 2024 at 7:00 AM Daniel P. Berrangé > wrote: > > > On Thu, Oct 17, 2024 at 02:00:35PM +1000, Alistair Francis wrote: > > > On Thu, Oct 17, 2024 at 2:35 AM htafr wrote: > > > > > > > > (I) Summary > > > > > > === > > > > > > > > This patch is the beginning of the support of the Security Protocol and > > > > Data Model (SPDM). There are some known issues (see II), but it's > > > > usable and not many users are going to use this functionality for now, > > > > but for those who will it may facilitate the development. > > > > > > > > There are some people working with LibSPDM to implement the SPDM on > > > > emulated devices, however current works that use QEMU compile LibSPDM > > > > out-of-tree [1][2][3]. This patch enables the compilation of LibSPDM > > when > > > > user pass the parameter '--enable-libspdm' to configure file, this > > option > > > > is disabled by default. The following parameters were also added: > > > > > > > > --libspdm-crypto=CHOICE set LibSPDM crypto algorithm [mbedtls] > > (choices: > > > >mbedtls/openssl) > > > > --libspdm-toolchain=VALUE > > > >toolchain to use for LibSPDM compilation > > [GCC] > > > > > > > > In order to facilitate future code development using LibSPDM API, this > > > > patch also provides the definition of the macro 'CONFIG_LIBSPDM'. > > > > > > We have talked about this before, see > > > https://patchew.org/QEMU/cover.1691509717.git.alistair.fran...@wdc.com/ > > > > > > The general agreement seemed to be that it will be hard to do SPDM > > > configuration inside QEMU, hence the external library (like the QEMU > > > TPM support). > > > > More generally, seeing this libspdm proposed for QEMU, without any > > corresponding usage of it it dubious. It is hard to judge whether > > it makes any sense, without seeing how it will be used in real > > device code inside QEMU. > > > > Currently, I'm working with EDK2 and QEMU so I have a branch [1] with > ongoing > modifications in files backends/spdm.c and hw/nvme/auth.c. Although the > current > modifications are able to exchange SPDM messages, it's far from being > complete > and it's not following better code practices yet. I'm making use of > Alistair's and > Mallawa's previous work in NVMe to authenticate it through PCI [2]. > > [1] WIP: SPDM integration > Link: https://github.com/htafr/qemu/tree/libspdm-dev > [2] WIP: SPDM in OVMF > Link: https://github.com/htafr/edk2/tree/ovmf-spdm > > > > > > On the cryptography side, I'm not a fan of linking another > > crypto library to QEMU, that's different from what we already > > support in our crypto layer. openssl in particular is a problem > > due to its licensing - people tend to hand-waive away the > > licensing incompatibility by pretending openssl is a "system library" > > but I disagree with that interpretation. > > > > > > (II) Known Limitations > > > > > > === > > > > > > > > 1. This patch enables LibSPDM in-tree compilation for Linux systems > > only. > > > > 2. LibSPDM compilation uses CMake, so meson build system is making use > > > >of the CMake module [4]. > > > > 3. Some problems may occur when compiling LibSPDM with MbedTls such as: > > > > error: "_GNU_SOURCE" redefined [-Werror] > > > > 10 | #define _GNU_SOURCE > > > > > > > >It's possible to compile using --disable-werror. > > > > > > > > (III) Sample configuration > > > > > > === > > > > > > > > ../configure \ > > > > --disable-werror \ > > > > --enable-libspdm \ > > > > --libspdm-crypto=mbedtls \ > > > > --enable-gcov > > > > > > > > References: > > > > [1] riscv-spdm > > > > Link: https://github.com/htafr/riscv-spdm > > > > [2] spdm-benchmark > > > > Link: https://github.com/rcaalves/spdm-benchmark > > > > [3] qemu-spdm-emulation-guide > > > > Link: https://github.com/twilfredo/qemu-spdm-emulation-guide > > > > > > This one has been merged upstream and mainline QEMU supports it now: > > > > > > https://www.qemu.org/docs/master/specs/spdm.html > > > > So with that merged, is this proposal for linking to libspdm redundant ? > > > > I'm not sure if I understood the redundancy. Would it be against QEMU > practices > to have another openssl as well as mbedtls linked inside it? QEMU doesn't link to either of those libraries. We preferentially use gnutls, with a fallback to gcrypt or nettle, to avoid the murky openssl licensing situation, and to a lesser extent because openssl has an unpleasant API to use. mbedtls isn't used because it is a more niche solution compared to what we already support, so wasn't compelling to support. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr
[PATCH v2 05/31] backends: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to qobject/. Signed-off-by: Daniel P. Berrangé --- backends/cryptodev-hmp-cmds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/backends/cryptodev-hmp-cmds.c b/backends/cryptodev-hmp-cmds.c index 4f7220bb13..01396d227c 100644 --- a/backends/cryptodev-hmp-cmds.c +++ b/backends/cryptodev-hmp-cmds.c @@ -14,7 +14,7 @@ #include "monitor/hmp.h" #include "monitor/monitor.h" #include "qapi/qapi-commands-cryptodev.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" void hmp_info_cryptodev(Monitor *mon, const QDict *qdict) -- 2.46.0
[PATCH v2 31/31] system: remove unused qerror.h header
Signed-off-by: Daniel P. Berrangé --- system/rtc.c | 1 - 1 file changed, 1 deletion(-) diff --git a/system/rtc.c b/system/rtc.c index e3bc2095f9..216d2aee3a 100644 --- a/system/rtc.c +++ b/system/rtc.c @@ -25,7 +25,6 @@ #include "qemu/osdep.h" #include "qemu/cutils.h" #include "qapi/error.h" -#include "qapi/qmp/qerror.h" #include "qemu/error-report.h" #include "qemu/option.h" #include "qemu/timer.h" -- 2.46.0
[PATCH v2 22/31] stubs: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to
qobject/.
Signed-off-by: Daniel P. Berrangé
---
stubs/qmp-command-available.c | 2 +-
stubs/qmp-quit.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/stubs/qmp-command-available.c b/stubs/qmp-command-available.c
index 46540af7bf..8851faced1 100644
--- a/stubs/qmp-command-available.c
+++ b/stubs/qmp-command-available.c
@@ -1,5 +1,5 @@
#include "qemu/osdep.h"
-#include "qapi/qmp/dispatch.h"
+#include "qapi/qmp-registry.h"
bool qmp_command_available(const QmpCommand *cmd, Error **errp)
{
diff --git a/stubs/qmp-quit.c b/stubs/qmp-quit.c
index a3ff47f7bd..8fb523e905 100644
--- a/stubs/qmp-quit.c
+++ b/stubs/qmp-quit.c
@@ -1,6 +1,6 @@
#include "qemu/osdep.h"
#include "qapi/qapi-commands-control.h"
-#include "qapi/qmp/dispatch.h"
+#include "qapi/qmp-registry.h"
void qmp_quit(Error **errp)
{
--
2.46.0
[PATCH v2 01/31] include: move include/qapi/qmp/ to include/qobject/
The general expectation is that header files should follow the same
file/path naming scheme as the corresponding source file. There are
various historical exceptions to this practice in QEMU, with one of
the most notable being the include/qapi/qmp/ directory. Most of the
headers there correspond to source files in qobject/.
This patch corrects that inconsistency by creating include/qobject/.
The only outlier is include/qapi/qmp/dispatch.h which gets renamed
to include/qapi/qmp-registry.h.
To allow the code to continue to build, symlinks are temporarily
added in $QEMU/qapi/qmp/ to point to the new location. They will
be removed in a later commit.
Signed-off-by: Daniel P. Berrangé
---
MAINTAINERS | 5 +
include/qapi/{qmp/dispatch.h => qmp-registry.h} | 0
include/{qapi/qmp => qobject}/json-parser.h | 0
include/{qapi/qmp => qobject}/json-writer.h | 0
include/{qapi/qmp => qobject}/qbool.h | 0
include/{qapi/qmp => qobject}/qdict.h | 0
include/{qapi/qmp => qobject}/qjson.h | 0
include/{qapi/qmp => qobject}/qlist.h | 0
include/{qapi/qmp => qobject}/qlit.h| 0
include/{qapi/qmp => qobject}/qnull.h | 0
include/{qapi/qmp => qobject}/qnum.h| 0
include/{qapi/qmp => qobject}/qobject.h | 0
include/{qapi/qmp => qobject}/qstring.h | 0
qapi/qmp/dispatch.h | 1 +
qapi/qmp/json-parser.h | 1 +
qapi/qmp/json-writer.h | 1 +
qapi/qmp/qbool.h| 1 +
qapi/qmp/qdict.h| 1 +
qapi/qmp/qjson.h| 1 +
qapi/qmp/qlist.h| 1 +
qapi/qmp/qlit.h | 1 +
qapi/qmp/qnull.h| 1 +
qapi/qmp/qnum.h | 1 +
qapi/qmp/qobject.h | 1 +
qapi/qmp/qstring.h | 1 +
25 files changed, 13 insertions(+), 4 deletions(-)
rename include/qapi/{qmp/dispatch.h => qmp-registry.h} (100%)
rename include/{qapi/qmp => qobject}/json-parser.h (100%)
rename include/{qapi/qmp => qobject}/json-writer.h (100%)
rename include/{qapi/qmp => qobject}/qbool.h (100%)
rename include/{qapi/qmp => qobject}/qdict.h (100%)
rename include/{qapi/qmp => qobject}/qjson.h (100%)
rename include/{qapi/qmp => qobject}/qlist.h (100%)
rename include/{qapi/qmp => qobject}/qlit.h (100%)
rename include/{qapi/qmp => qobject}/qnull.h (100%)
rename include/{qapi/qmp => qobject}/qnum.h (100%)
rename include/{qapi/qmp => qobject}/qobject.h (100%)
rename include/{qapi/qmp => qobject}/qstring.h (100%)
create mode 12 qapi/qmp/dispatch.h
create mode 12 qapi/qmp/json-parser.h
create mode 12 qapi/qmp/json-writer.h
create mode 12 qapi/qmp/qbool.h
create mode 12 qapi/qmp/qdict.h
create mode 12 qapi/qmp/qjson.h
create mode 12 qapi/qmp/qlist.h
create mode 12 qapi/qmp/qlit.h
create mode 12 qapi/qmp/qnull.h
create mode 12 qapi/qmp/qnum.h
create mode 12 qapi/qmp/qobject.h
create mode 12 qapi/qmp/qstring.h
diff --git a/MAINTAINERS b/MAINTAINERS
index c21d6a2f9e..656482b2a4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3153,8 +3153,6 @@ S: Supported
F: qapi/
X: qapi/*.json
F: include/qapi/
-X: include/qapi/qmp/
-F: include/qapi/qmp/dispatch.h
F: tests/qapi-schema/
F: tests/unit/test-*-visitor.c
F: tests/unit/test-qapi-*.c
@@ -3178,8 +3176,7 @@ QObject
M: Markus Armbruster
S: Supported
F: qobject/
-F: include/qapi/qmp/
-X: include/qapi/qmp/dispatch.h
+F: include/qobject/
F: scripts/coccinelle/qobject.cocci
F: tests/unit/check-qdict.c
F: tests/unit/check-qjson.c
diff --git a/include/qapi/qmp/dispatch.h b/include/qapi/qmp-registry.h
similarity index 100%
rename from include/qapi/qmp/dispatch.h
rename to include/qapi/qmp-registry.h
diff --git a/include/qapi/qmp/json-parser.h b/include/qobject/json-parser.h
similarity index 100%
rename from include/qapi/qmp/json-parser.h
rename to include/qobject/json-parser.h
diff --git a/include/qapi/qmp/json-writer.h b/include/qobject/json-writer.h
similarity index 100%
rename from include/qapi/qmp/json-writer.h
rename to include/qobject/json-writer.h
diff --git a/include/qapi/qmp/qbool.h b/include/qobject/qbool.h
similarity index 100%
rename from include/qapi/qmp/qbool.h
rename to include/qobject/qbool.h
diff --git a/include/qapi/qmp/qdict.h b/include/qobject/qdict.h
similarity index 100%
rename from include/qapi/qmp/qdict.h
rename to include/qobject/qdict.h
diff --git a/include/qapi/qmp/qjson.h b/include/qobject/qjson.h
similarity index 100%
rename from include/qapi/qmp/qjson.h
rename to include/qobject/qjson.h
diff --git a/include/qapi/qmp/qlist.h b/include/qobject/qlist.h
similarity index 100%
rename from include/qapi/qmp/qlist.h
rename to include/qobject/qlist.h
diff --git a/include/qapi/qmp/qlit.
[PATCH v2 03/31] authz: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to qobject/. Signed-off-by: Daniel P. Berrangé --- authz/listfile.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/authz/listfile.c b/authz/listfile.c index 45a60e987d..d31d9103f7 100644 --- a/authz/listfile.c +++ b/authz/listfile.c @@ -28,8 +28,8 @@ #include "qemu/filemonitor.h" #include "qom/object_interfaces.h" #include "qapi/qapi-visit-authz.h" -#include "qapi/qmp/qjson.h" -#include "qapi/qmp/qobject.h" +#include "qobject/qjson.h" +#include "qobject/qobject.h" #include "qapi/qobject-input-visitor.h" -- 2.46.0
[PATCH v2 02/31] audio: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to qobject/. Signed-off-by: Daniel P. Berrangé --- audio/audio-hmp-cmds.c | 2 +- audio/audio.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/audio/audio-hmp-cmds.c b/audio/audio-hmp-cmds.c index c9608b715b..8774c09f18 100644 --- a/audio/audio-hmp-cmds.c +++ b/audio/audio-hmp-cmds.c @@ -27,7 +27,7 @@ #include "monitor/hmp.h" #include "monitor/monitor.h" #include "qapi/error.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" static QLIST_HEAD (capture_list_head, CaptureState) capture_head; diff --git a/audio/audio.c b/audio/audio.c index af0ae33fed..2067d7e5f8 100644 --- a/audio/audio.c +++ b/audio/audio.c @@ -32,7 +32,7 @@ #include "qapi/qobject-input-visitor.h" #include "qapi/qapi-visit-audio.h" #include "qapi/qapi-commands-audio.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "qemu/cutils.h" #include "qemu/error-report.h" #include "qemu/log.h" -- 2.46.0
[PATCH v2 11/31] migration: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to qobject/. Signed-off-by: Daniel P. Berrangé --- migration/dirtyrate.c | 2 +- migration/migration-hmp-cmds.c | 2 +- migration/migration.c | 2 +- migration/migration.h | 2 +- migration/options.c| 2 +- migration/vmstate.c| 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c index 233acb0855..14b28a59fc 100644 --- a/migration/dirtyrate.c +++ b/migration/dirtyrate.c @@ -24,7 +24,7 @@ #include "dirtyrate.h" #include "monitor/hmp.h" #include "monitor/monitor.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "sysemu/kvm.h" #include "sysemu/runstate.h" #include "exec/memory.h" diff --git a/migration/migration-hmp-cmds.c b/migration/migration-hmp-cmds.c index 20d1a6e219..69c86780e3 100644 --- a/migration/migration-hmp-cmds.c +++ b/migration/migration-hmp-cmds.c @@ -21,7 +21,7 @@ #include "qapi/error.h" #include "qapi/qapi-commands-migration.h" #include "qapi/qapi-visit-migration.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "qapi/string-input-visitor.h" #include "qapi/string-output-visitor.h" #include "qemu/cutils.h" diff --git a/migration/migration.c b/migration/migration.c index 021faee2f3..b615f93a1a 100644 --- a/migration/migration.c +++ b/migration/migration.c @@ -43,7 +43,7 @@ #include "qapi/qapi-commands-migration.h" #include "qapi/qapi-events-migration.h" #include "qapi/qmp/qerror.h" -#include "qapi/qmp/qnull.h" +#include "qobject/qnull.h" #include "qemu/rcu.h" #include "postcopy-ram.h" #include "qemu/thread.h" diff --git a/migration/migration.h b/migration/migration.h index 38aa1402d5..c61c259a1c 100644 --- a/migration/migration.h +++ b/migration/migration.h @@ -17,7 +17,7 @@ #include "exec/cpu-common.h" #include "hw/qdev-core.h" #include "qapi/qapi-types-migration.h" -#include "qapi/qmp/json-writer.h" +#include "qobject/json-writer.h" #include "qemu/thread.h" #include "qemu/coroutine.h" #include "io/channel.h" diff --git a/migration/options.c b/migration/options.c index ad8d6989a8..4bfa2ac236 100644 --- a/migration/options.c +++ b/migration/options.c @@ -19,7 +19,7 @@ #include "qapi/qapi-commands-migration.h" #include "qapi/qapi-visit-migration.h" #include "qapi/qmp/qerror.h" -#include "qapi/qmp/qnull.h" +#include "qobject/qnull.h" #include "sysemu/runstate.h" #include "migration/colo.h" #include "migration/misc.h" diff --git a/migration/vmstate.c b/migration/vmstate.c index ff5d589a6d..82d64a6988 100644 --- a/migration/vmstate.c +++ b/migration/vmstate.c @@ -15,7 +15,7 @@ #include "migration/vmstate.h" #include "savevm.h" #include "qapi/error.h" -#include "qapi/qmp/json-writer.h" +#include "qobject/json-writer.h" #include "qemu-file.h" #include "qemu/bitops.h" #include "qemu/error-report.h" -- 2.46.0
[PATCH v2 09/31] hw: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to
qobject/.
Signed-off-by: Daniel P. Berrangé
---
hw/arm/aspeed_ast27x0.c | 2 +-
hw/arm/mps2-tz.c| 2 +-
hw/arm/mps2.c | 2 +-
hw/arm/mps3r.c | 2 +-
hw/arm/sbsa-ref.c | 2 +-
hw/arm/stellaris.c | 2 +-
hw/arm/vexpress.c | 2 +-
hw/arm/virt.c | 2 +-
hw/arm/xlnx-versal.c| 2 +-
hw/block/xen-block.c| 4 ++--
hw/core/machine-hmp-cmds.c | 2 +-
hw/core/machine-qmp-cmds.c | 2 +-
hw/core/qdev-properties.c | 2 +-
hw/core/qdev.c | 2 +-
hw/hyperv/hv-balloon.c | 2 +-
hw/i386/acpi-build.c| 2 +-
hw/i386/kvm/xen_evtchn.c| 2 +-
hw/i386/monitor.c | 2 +-
hw/i386/pc.c| 2 +-
hw/net/rocker/rocker-hmp-cmds.c | 2 +-
hw/net/virtio-net.c | 2 +-
hw/net/xen_nic.c| 2 +-
hw/pci/pci-hmp-cmds.c | 2 +-
hw/ppc/pegasos2.c | 2 +-
hw/ppc/spapr_drc.c | 2 +-
hw/rx/rx62n.c | 2 +-
hw/s390x/s390-skeys.c | 2 +-
hw/s390x/s390-stattrib.c| 2 +-
hw/usb/xen-usb.c| 4 ++--
hw/vfio/pci.c | 2 +-
hw/virtio/virtio-hmp-cmds.c | 2 +-
hw/virtio/virtio-qmp.c | 4 ++--
hw/xen/xen-bus.c| 2 +-
33 files changed, 36 insertions(+), 36 deletions(-)
diff --git a/hw/arm/aspeed_ast27x0.c b/hw/arm/aspeed_ast27x0.c
index 761ee11657..63686de02b 100644
--- a/hw/arm/aspeed_ast27x0.c
+++ b/hw/arm/aspeed_ast27x0.c
@@ -19,7 +19,7 @@
#include "net/net.h"
#include "sysemu/sysemu.h"
#include "hw/intc/arm_gicv3.h"
-#include "qapi/qmp/qlist.h"
+#include "qobject/qlist.h"
#include "qemu/log.h"
static const hwaddr aspeed_soc_ast2700_memmap[] = {
diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index 8edf57a66d..63aef4922c 100644
--- a/hw/arm/mps2-tz.c
+++ b/hw/arm/mps2-tz.c
@@ -48,7 +48,7 @@
#include "qemu/units.h"
#include "qemu/cutils.h"
#include "qapi/error.h"
-#include "qapi/qmp/qlist.h"
+#include "qobject/qlist.h"
#include "qemu/error-report.h"
#include "hw/arm/boot.h"
#include "hw/arm/armv7m.h"
diff --git a/hw/arm/mps2.c b/hw/arm/mps2.c
index 50919ee46d..d023c231f5 100644
--- a/hw/arm/mps2.c
+++ b/hw/arm/mps2.c
@@ -48,7 +48,7 @@
#include "net/net.h"
#include "hw/watchdog/cmsdk-apb-watchdog.h"
#include "hw/qdev-clock.h"
-#include "qapi/qmp/qlist.h"
+#include "qobject/qlist.h"
#include "qom/object.h"
typedef enum MPS2FPGAType {
diff --git a/hw/arm/mps3r.c b/hw/arm/mps3r.c
index 4d55a6564c..33e6432988 100644
--- a/hw/arm/mps3r.c
+++ b/hw/arm/mps3r.c
@@ -27,7 +27,7 @@
#include "qemu/osdep.h"
#include "qemu/units.h"
#include "qapi/error.h"
-#include "qapi/qmp/qlist.h"
+#include "qobject/qlist.h"
#include "exec/address-spaces.h"
#include "cpu.h"
#include "sysemu/sysemu.h"
diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
index e3195d5449..062c9db229 100644
--- a/hw/arm/sbsa-ref.c
+++ b/hw/arm/sbsa-ref.c
@@ -48,7 +48,7 @@
#include "hw/char/pl011.h"
#include "hw/watchdog/sbsa_gwdt.h"
#include "net/net.h"
-#include "qapi/qmp/qlist.h"
+#include "qobject/qlist.h"
#include "qom/object.h"
#include "target/arm/cpu-qom.h"
#include "target/arm/gtimer.h"
diff --git a/hw/arm/stellaris.c b/hw/arm/stellaris.c
index 376746251e..4540c47d45 100644
--- a/hw/arm/stellaris.c
+++ b/hw/arm/stellaris.c
@@ -31,7 +31,7 @@
#include "hw/timer/stellaris-gptm.h"
#include "hw/qdev-clock.h"
#include "qom/object.h"
-#include "qapi/qmp/qlist.h"
+#include "qobject/qlist.h"
#include "ui/input.h"
#define GPIO_A 0
diff --git a/hw/arm/vexpress.c b/hw/arm/vexpress.c
index de815d84cc..47ccb2db8a 100644
--- a/hw/arm/vexpress.c
+++ b/hw/arm/vexpress.c
@@ -42,7 +42,7 @@
#include "hw/cpu/a15mpcore.h"
#include "hw/i2c/arm_sbcon_i2c.h"
#include "hw/sd/sd.h"
-#include "qapi/qmp/qlist.h"
+#include "qobject/qlist.h"
#include "qom/object.h"
#include "audio/audio.h"
#include "target/arm/cpu-qom.h"
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 8b2b991d97..eb7fd0cd97 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -70,7 +70,7 @@
#include "hw/firmware/smbios.h"
#include "qapi/visitor.h"
#include "qapi/qapi-visit-common.h"
-#include "qapi/qmp/qlist.h"
+#include "qobject/qlist.h"
#include "standard-headers/linux/input.h"
#include "hw/arm/smmuv3.h"
#include "hw/acpi/acpi.h"
diff --git a/hw/arm/xlnx-versal.c b/hw/arm/xlnx-versal.c
index 3a1e2e29f1..346e09a3f3 100644
--- a/hw/arm/xlnx-versal.c
+++ b/hw/arm/xlnx-versal.c
@@ -12,7 +12,7 @@
#include "qemu/osdep.h"
#include "qemu/units.h"
#include "qapi/error.h"
-#include "qapi/qmp/qlist.h"
+#include "qobject/qlist.h"
#include "qemu/module.h"
#include "hw/sysbus.h"
#include "net/net.h"
diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
index aed1d5c330..5c5a5fec19 100644
--- a/hw/block/xen-block.c
+++ b/hw/block/xen-block.c
@@ -16,8 +16,8 @@
#include
[PATCH v2 13/31] net: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to qobject/. Signed-off-by: Daniel P. Berrangé --- net/net-hmp-cmds.c | 2 +- net/net.c | 2 +- net/slirp.c| 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/net/net-hmp-cmds.c b/net/net-hmp-cmds.c index 41d326bf5f..e7c55d2787 100644 --- a/net/net-hmp-cmds.c +++ b/net/net-hmp-cmds.c @@ -22,7 +22,7 @@ #include "qapi/clone-visitor.h" #include "qapi/qapi-commands-net.h" #include "qapi/qapi-visit-net.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "qemu/config-file.h" #include "qemu/help_option.h" #include "qemu/option.h" diff --git a/net/net.c b/net/net.c index d9b23a8f8c..8b4cd01970 100644 --- a/net/net.c +++ b/net/net.c @@ -36,7 +36,7 @@ #include "qemu/help_option.h" #include "qapi/qapi-commands-net.h" #include "qapi/qapi-visit-net.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "qapi/qmp/qerror.h" #include "qemu/error-report.h" #include "qemu/sockets.h" diff --git a/net/slirp.c b/net/slirp.c index eb9a456ed4..9b2784d643 100644 --- a/net/slirp.c +++ b/net/slirp.c @@ -43,7 +43,7 @@ #include "sysemu/sysemu.h" #include "qemu/cutils.h" #include "qapi/error.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "util.h" #include "migration/register.h" #include "migration/vmstate.h" -- 2.46.0
[PATCH v2 12/31] monitor: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to qobject/. Signed-off-by: Daniel P. Berrangé --- monitor/hmp-cmds-target.c | 2 +- monitor/hmp-cmds.c | 2 +- monitor/hmp.c | 4 ++-- monitor/monitor-internal.h | 4 ++-- monitor/monitor.c | 2 +- monitor/qemu-config-qmp.c | 2 +- monitor/qmp.c | 6 +++--- 7 files changed, 11 insertions(+), 11 deletions(-) diff --git a/monitor/hmp-cmds-target.c b/monitor/hmp-cmds-target.c index ff01cf9d8d..a79418f52b 100644 --- a/monitor/hmp-cmds-target.c +++ b/monitor/hmp-cmds-target.c @@ -29,7 +29,7 @@ #include "monitor/hmp-target.h" #include "monitor/monitor-internal.h" #include "qapi/error.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "sysemu/hw_accel.h" /* Set the current CPU defined by the user. Callers must hold BQL. */ diff --git a/monitor/hmp-cmds.c b/monitor/hmp-cmds.c index f601d06ab8..c353c52ec5 100644 --- a/monitor/hmp-cmds.c +++ b/monitor/hmp-cmds.c @@ -25,7 +25,7 @@ #include "qapi/qapi-commands-control.h" #include "qapi/qapi-commands-machine.h" #include "qapi/qapi-commands-misc.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "qemu/cutils.h" #include "qemu/log.h" #include "sysemu/sysemu.h" diff --git a/monitor/hmp.c b/monitor/hmp.c index 460e8832f6..dc33fec8c3 100644 --- a/monitor/hmp.c +++ b/monitor/hmp.c @@ -27,8 +27,8 @@ #include "hw/qdev-core.h" #include "monitor-internal.h" #include "monitor/hmp.h" -#include "qapi/qmp/qdict.h" -#include "qapi/qmp/qnum.h" +#include "qobject/qdict.h" +#include "qobject/qnum.h" #include "qemu/config-file.h" #include "qemu/ctype.h" #include "qemu/cutils.h" diff --git a/monitor/monitor-internal.h b/monitor/monitor-internal.h index cb628f681d..efce002334 100644 --- a/monitor/monitor-internal.h +++ b/monitor/monitor-internal.h @@ -28,8 +28,8 @@ #include "chardev/char-fe.h" #include "monitor/monitor.h" #include "qapi/qapi-types-control.h" -#include "qapi/qmp/dispatch.h" -#include "qapi/qmp/json-parser.h" +#include "qapi/qmp-registry.h" +#include "qobject/json-parser.h" #include "qemu/readline.h" #include "sysemu/iothread.h" diff --git a/monitor/monitor.c b/monitor/monitor.c index db52a9c7ef..928234a608 100644 --- a/monitor/monitor.c +++ b/monitor/monitor.c @@ -28,7 +28,7 @@ #include "qapi/opts-visitor.h" #include "qapi/qapi-emit-events.h" #include "qapi/qapi-visit-control.h" -#include "qapi/qmp/qdict.h" +#include "qobject/qdict.h" #include "qemu/error-report.h" #include "qemu/option.h" #include "sysemu/qtest.h" diff --git a/monitor/qemu-config-qmp.c b/monitor/qemu-config-qmp.c index 24477a0e44..9a3b183602 100644 --- a/monitor/qemu-config-qmp.c +++ b/monitor/qemu-config-qmp.c @@ -2,7 +2,7 @@ #include "qemu/osdep.h" #include "qapi/error.h" #include "qapi/qapi-commands-misc.h" -#include "qapi/qmp/qlist.h" +#include "qobject/qlist.h" #include "qemu/option.h" #include "qemu/config-file.h" #include "hw/boards.h" diff --git a/monitor/qmp.c b/monitor/qmp.c index 5e538f34c0..2f46cf9e49 100644 --- a/monitor/qmp.c +++ b/monitor/qmp.c @@ -28,9 +28,9 @@ #include "monitor-internal.h" #include "qapi/error.h" #include "qapi/qapi-commands-control.h" -#include "qapi/qmp/qdict.h" -#include "qapi/qmp/qjson.h" -#include "qapi/qmp/qlist.h" +#include "qobject/qdict.h" +#include "qobject/qjson.h" +#include "qobject/qlist.h" #include "trace.h" /* -- 2.46.0
[PATCH v2 25/31] tests: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to qobject/. Signed-off-by: Daniel P. Berrangé --- tests/qtest/adm1266-test.c| 4 ++-- tests/qtest/adm1272-test.c| 4 ++-- tests/qtest/ahci-test.c | 2 +- tests/qtest/arm-cpu-features.c| 4 ++-- tests/qtest/aspeed_gpio-test.c| 2 +- tests/qtest/boot-order-test.c | 2 +- tests/qtest/cdrom-test.c | 2 +- tests/qtest/cpu-plug-test.c | 4 ++-- tests/qtest/device-introspect-test.c | 6 +++--- tests/qtest/device-plug-test.c| 4 ++-- tests/qtest/drive_del-test.c | 4 ++-- tests/qtest/emc141x-test.c| 2 +- tests/qtest/fdc-test.c| 2 +- tests/qtest/hd-geo-test.c | 2 +- tests/qtest/ide-test.c| 2 +- tests/qtest/isl_pmbus_vr-test.c | 4 ++-- tests/qtest/libqmp.c | 4 ++-- tests/qtest/libqmp.h | 2 +- tests/qtest/libqos/generic-pcihost.c | 2 +- tests/qtest/libqos/libqos.c | 2 +- tests/qtest/libqos/pci-pc.c | 2 +- tests/qtest/libqos/qos_external.c | 8 tests/qtest/libqtest.c| 10 +- tests/qtest/libqtest.h| 4 ++-- tests/qtest/lsm303dlhc-mag-test.c | 2 +- tests/qtest/machine-none-test.c | 2 +- tests/qtest/max34451-test.c | 4 ++-- tests/qtest/migration-helpers.c | 4 ++-- tests/qtest/migration-test.c | 4 ++-- tests/qtest/netdev-socket.c | 2 +- tests/qtest/npcm7xx_adc-test.c| 2 +- tests/qtest/npcm7xx_emc-test.c| 4 ++-- tests/qtest/npcm7xx_pwm-test.c| 4 ++-- tests/qtest/npcm7xx_watchdog_timer-test.c | 2 +- tests/qtest/numa-test.c | 4 ++-- tests/qtest/pvpanic-pci-test.c| 2 +- tests/qtest/pvpanic-test.c| 3 ++- tests/qtest/q35-test.c| 2 +- tests/qtest/qmp-cmd-test.c| 2 +- tests/qtest/qmp-test.c| 6 +++--- tests/qtest/qom-test.c| 4 ++-- tests/qtest/qos-test.c| 2 +- tests/qtest/readconfig-test.c | 6 +++--- tests/qtest/tco-test.c| 2 +- tests/qtest/test-filter-mirror.c | 2 +- tests/qtest/test-filter-redirector.c | 2 +- tests/qtest/test-netfilter.c | 2 +- tests/qtest/test-x86-cpuid-compat.c | 8 tests/qtest/tmp105-test.c | 2 +- tests/qtest/tpm-emu.c | 4 ++-- tests/qtest/tpm-util.c| 2 +- tests/qtest/vhost-user-test.c | 2 +- tests/qtest/virtio-net-failover.c | 6 +++--- tests/qtest/virtio-net-test.c | 2 +- tests/qtest/vmgenid-test.c| 2 +- tests/qtest/wdt_ib700-test.c | 2 +- tests/unit/check-block-qdict.c| 4 ++-- tests/unit/check-qdict.c | 6 +++--- tests/unit/check-qjson.c | 12 ++-- tests/unit/check-qlist.c | 4 ++-- tests/unit/check-qlit.c | 12 ++-- tests/unit/check-qnull.c | 2 +- tests/unit/check-qnum.c | 2 +- tests/unit/check-qobject.c| 12 ++-- tests/unit/check-qom-proplist.c | 4 ++-- tests/unit/check-qstring.c| 2 +- tests/unit/test-block-iothread.c | 2 +- tests/unit/test-blockjob-txn.c| 2 +- tests/unit/test-blockjob.c| 2 +- tests/unit/test-char.c| 2 +- tests/unit/test-forward-visitor.c | 4 ++-- tests/unit/test-image-locking.c | 2 +- tests/unit/test-keyval.c | 6 +++--- tests/unit/test-qemu-opts.c | 4 ++-- tests/unit/test-qga.c | 4 ++-- tests/unit/test-qmp-cmds.c| 8 tests/unit/test-qmp-event.c | 10 +- tests/unit/test-qobject-input-visitor.c | 12 ++-- tests/unit/test-qobject-output-visitor.c | 12 ++-- tests/unit/test-replication.c | 2 +- tests/unit/test-visitor-serialization.c | 4 ++-- 81 files changed, 160 insertions(+), 159 deletions(-) diff --git a/tests/qtest/adm1266-test.c b/tests/qtest/adm1266-test.c index 6c312c499f..5ae8206234 100644 --- a/tests/qtest/adm1266-test.c +++ b/tests/qtest/adm1266-test.c @@ -13,8 +13,8 @@ #include "libqtest-single.h" #include "libqos/qgraph.h" #include "libqos/i2c.h" -#include "qapi/qmp/qdict.h" -#include "qapi/qmp/qnum.h" +#include "qobject/qdict.h" +#include "qobject/qnum.h" #include "qemu/bitops.h" #define TEST_ID "adm1266-test" diff --git a/tests/qtest/adm1272-test.c b/tests/qtest/adm1272-test.c index 63f8514801..2abda8d5be 1006
[PATCH v2 29/31] qapi: remove header file compatibility symlinks
All code is converted to the new 'qobject/' import path, so the temporary header file compatibility symlinks are now redundant. Signed-off-by: Daniel P. Berrangé --- qapi/qmp/dispatch.h| 1 - qapi/qmp/json-parser.h | 1 - qapi/qmp/json-writer.h | 1 - qapi/qmp/qbool.h | 1 - qapi/qmp/qdict.h | 1 - qapi/qmp/qjson.h | 1 - qapi/qmp/qlist.h | 1 - qapi/qmp/qlit.h| 1 - qapi/qmp/qnull.h | 1 - qapi/qmp/qnum.h| 1 - qapi/qmp/qobject.h | 1 - qapi/qmp/qstring.h | 1 - 12 files changed, 12 deletions(-) delete mode 12 qapi/qmp/dispatch.h delete mode 12 qapi/qmp/json-parser.h delete mode 12 qapi/qmp/json-writer.h delete mode 12 qapi/qmp/qbool.h delete mode 12 qapi/qmp/qdict.h delete mode 12 qapi/qmp/qjson.h delete mode 12 qapi/qmp/qlist.h delete mode 12 qapi/qmp/qlit.h delete mode 12 qapi/qmp/qnull.h delete mode 12 qapi/qmp/qnum.h delete mode 12 qapi/qmp/qobject.h delete mode 12 qapi/qmp/qstring.h diff --git a/qapi/qmp/dispatch.h b/qapi/qmp/dispatch.h deleted file mode 12 index ffedc3971d..00 --- a/qapi/qmp/dispatch.h +++ /dev/null @@ -1 +0,0 @@ -../../include/qapi/qmp-registry.h \ No newline at end of file diff --git a/qapi/qmp/json-parser.h b/qapi/qmp/json-parser.h deleted file mode 12 index 059cb73fa8..00 --- a/qapi/qmp/json-parser.h +++ /dev/null @@ -1 +0,0 @@ -../../include/qobject/json-parser.h \ No newline at end of file diff --git a/qapi/qmp/json-writer.h b/qapi/qmp/json-writer.h deleted file mode 12 index 3e952f4c97..00 --- a/qapi/qmp/json-writer.h +++ /dev/null @@ -1 +0,0 @@ -../../include/qobject/json-writer.h \ No newline at end of file diff --git a/qapi/qmp/qbool.h b/qapi/qmp/qbool.h deleted file mode 12 index 443c881cf8..00 --- a/qapi/qmp/qbool.h +++ /dev/null @@ -1 +0,0 @@ -../../include/qobject/qbool.h \ No newline at end of file diff --git a/qapi/qmp/qdict.h b/qapi/qmp/qdict.h deleted file mode 12 index 8183614eae..00 --- a/qapi/qmp/qdict.h +++ /dev/null @@ -1 +0,0 @@ -../../include/qobject/qdict.h \ No newline at end of file diff --git a/qapi/qmp/qjson.h b/qapi/qmp/qjson.h deleted file mode 12 index 85b48c5bfd..00 --- a/qapi/qmp/qjson.h +++ /dev/null @@ -1 +0,0 @@ -../../include/qobject/qjson.h \ No newline at end of file diff --git a/qapi/qmp/qlist.h b/qapi/qmp/qlist.h deleted file mode 12 index d40db0a12b..00 --- a/qapi/qmp/qlist.h +++ /dev/null @@ -1 +0,0 @@ -../../include/qobject/qlist.h \ No newline at end of file diff --git a/qapi/qmp/qlit.h b/qapi/qmp/qlit.h deleted file mode 12 index 5dd5ac8ccb..00 --- a/qapi/qmp/qlit.h +++ /dev/null @@ -1 +0,0 @@ -../../include/qobject/qlit.h \ No newline at end of file diff --git a/qapi/qmp/qnull.h b/qapi/qmp/qnull.h deleted file mode 12 index 944769d44b..00 --- a/qapi/qmp/qnull.h +++ /dev/null @@ -1 +0,0 @@ -../../include/qobject/qnull.h \ No newline at end of file diff --git a/qapi/qmp/qnum.h b/qapi/qmp/qnum.h deleted file mode 12 index 8038e2f4d6..00 --- a/qapi/qmp/qnum.h +++ /dev/null @@ -1 +0,0 @@ -../../include/qobject/qnum.h \ No newline at end of file diff --git a/qapi/qmp/qobject.h b/qapi/qmp/qobject.h deleted file mode 12 index 89d9118cfd..00 --- a/qapi/qmp/qobject.h +++ /dev/null @@ -1 +0,0 @@ -../../include/qobject/qobject.h \ No newline at end of file diff --git a/qapi/qmp/qstring.h b/qapi/qmp/qstring.h deleted file mode 12 index 24f48de18a..00 --- a/qapi/qmp/qstring.h +++ /dev/null @@ -1 +0,0 @@ -../../include/qobject/qstring.h \ No newline at end of file -- 2.46.0
[PATCH v2 14/31] qapi: adapt to new import path for qobject data type headers
The qobject data type headers have moved from qapi/qmp/ to
qobject/.
Signed-off-by: Daniel P. Berrangé
---
qapi/qapi-clone-visitor.c | 2 +-
qapi/qapi-dealloc-visitor.c | 2 +-
qapi/qapi-forward-visitor.c | 14 +++---
qapi/qmp-dispatch.c | 8
qapi/qmp-event.c | 6 +++---
qapi/qmp-registry.c | 2 +-
qapi/qobject-input-visitor.c | 14 +++---
qapi/qobject-output-visitor.c | 12 ++--
qapi/string-input-visitor.c | 2 +-
9 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/qapi/qapi-clone-visitor.c b/qapi/qapi-clone-visitor.c
index bbf953698f..30997638de 100644
--- a/qapi/qapi-clone-visitor.c
+++ b/qapi/qapi-clone-visitor.c
@@ -12,7 +12,7 @@
#include "qapi/clone-visitor.h"
#include "qapi/visitor-impl.h"
#include "qapi/error.h"
-#include "qapi/qmp/qnull.h"
+#include "qobject/qnull.h"
struct QapiCloneVisitor {
Visitor visitor;
diff --git a/qapi/qapi-dealloc-visitor.c b/qapi/qapi-dealloc-visitor.c
index ef283f2966..57a2c904bb 100644
--- a/qapi/qapi-dealloc-visitor.c
+++ b/qapi/qapi-dealloc-visitor.c
@@ -14,7 +14,7 @@
#include "qemu/osdep.h"
#include "qapi/dealloc-visitor.h"
-#include "qapi/qmp/qnull.h"
+#include "qobject/qnull.h"
#include "qapi/visitor-impl.h"
struct QapiDeallocVisitor
diff --git a/qapi/qapi-forward-visitor.c b/qapi/qapi-forward-visitor.c
index e36d9bc9ba..dea540c3c9 100644
--- a/qapi/qapi-forward-visitor.c
+++ b/qapi/qapi-forward-visitor.c
@@ -14,14 +14,14 @@
#include "qapi/forward-visitor.h"
#include "qapi/visitor-impl.h"
#include "qemu/queue.h"
-#include "qapi/qmp/qjson.h"
-#include "qapi/qmp/qbool.h"
-#include "qapi/qmp/qdict.h"
+#include "qobject/qjson.h"
+#include "qobject/qbool.h"
+#include "qobject/qdict.h"
#include "qapi/qmp/qerror.h"
-#include "qapi/qmp/qlist.h"
-#include "qapi/qmp/qnull.h"
-#include "qapi/qmp/qnum.h"
-#include "qapi/qmp/qstring.h"
+#include "qobject/qlist.h"
+#include "qobject/qnull.h"
+#include "qobject/qnum.h"
+#include "qobject/qstring.h"
#include "qemu/cutils.h"
struct ForwardFieldVisitor {
diff --git a/qapi/qmp-dispatch.c b/qapi/qmp-dispatch.c
index 176b549473..fa95fcceac 100644
--- a/qapi/qmp-dispatch.c
+++ b/qapi/qmp-dispatch.c
@@ -16,12 +16,12 @@
#include "block/aio.h"
#include "qapi/compat-policy.h"
#include "qapi/error.h"
-#include "qapi/qmp/dispatch.h"
-#include "qapi/qmp/qdict.h"
-#include "qapi/qmp/qjson.h"
+#include "qapi/qmp-registry.h"
+#include "qobject/qdict.h"
+#include "qobject/qjson.h"
#include "qapi/qobject-input-visitor.h"
#include "qapi/qobject-output-visitor.h"
-#include "qapi/qmp/qbool.h"
+#include "qobject/qbool.h"
#include "qemu/coroutine.h"
#include "qemu/main-loop.h"
diff --git a/qapi/qmp-event.c b/qapi/qmp-event.c
index 0fe0d0a5a6..11cb6ace99 100644
--- a/qapi/qmp-event.c
+++ b/qapi/qmp-event.c
@@ -14,9 +14,9 @@
#include "qemu/osdep.h"
#include "qapi/qmp-event.h"
-#include "qapi/qmp/qstring.h"
-#include "qapi/qmp/qdict.h"
-#include "qapi/qmp/qjson.h"
+#include "qobject/qstring.h"
+#include "qobject/qdict.h"
+#include "qobject/qjson.h"
static void timestamp_put(QDict *qdict)
{
diff --git a/qapi/qmp-registry.c b/qapi/qmp-registry.c
index 485bc5e6fc..ac989074ed 100644
--- a/qapi/qmp-registry.c
+++ b/qapi/qmp-registry.c
@@ -13,7 +13,7 @@
*/
#include "qemu/osdep.h"
-#include "qapi/qmp/dispatch.h"
+#include "qapi/qmp-registry.h"
void qmp_register_command(QmpCommandList *cmds, const char *name,
QmpCommandFunc *fn, QmpCommandOptions options,
diff --git a/qapi/qobject-input-visitor.c b/qapi/qobject-input-visitor.c
index f110a804b2..93317532be 100644
--- a/qapi/qobject-input-visitor.c
+++ b/qapi/qobject-input-visitor.c
@@ -19,14 +19,14 @@
#include "qapi/qobject-input-visitor.h"
#include "qapi/visitor-impl.h"
#include "qemu/queue.h"
-#include "qapi/qmp/qjson.h"
-#include "qapi/qmp/qbool.h"
-#include "qapi/qmp/qdict.h"
+#include "qobject/qjson.h"
+#include "qobject/qbool.h"
+#include "qobject/qdict.h"
#include "qapi/qmp/qerror.h"
-#include "qapi/qmp/qlist.h"
-#include "qapi/qmp/qnull.h"
-#include "qapi/qmp/qnum.h"
-#include "qapi/qmp/qstring.h"
+#include "qobject/qlist.h"
+#include "qobject/qnull.h"
+#include "qobject/qnum.h"
+#include "qobject/qstring.h"
#include "qemu/cutils.h"
#include "qemu/keyval.h"
diff --git a/qapi/qobject-output-visitor.c b/qapi/qobject-output-visitor.c
index 74770edd73..13d3ae95b7 100644
--- a/qapi/qobject-output-visitor.c
+++ b/qapi/qobject-output-visitor.c
@@ -17,12 +17,12 @@
#include "qapi/qobject-output-visitor.h"
#include "qapi/visitor-impl.h"
#include "qemu/queue.h"
-#include "qapi/qmp/qbool.h"
-#include "qapi/qmp/qdict.h"
-#include "qapi/qmp/qlist.h"
-#include "qapi/qmp/qnull.h"
-#include "qapi/qmp/qnum.h"
-#include "qapi/qmp/qstring.h"
+#include "qobject/qbool.h"
+#include "qobject/qdict.h"
+#include "qobject/qlist.h"
+#include "qobject/qnull.h"
+#include "qobject/qnum.h"
+#include "qobject/qstring.h"
typedef struct QStackEntry {
Re: [PATCH v3 7/7] i386/cpu: add has_caches flag to check smp_cache configuration
RESEND as rejected by server (header issue, hopefully fixed)
On Sat, 12 Oct 2024 18:44:29 +0800
Zhao Liu wrote:
> From: Alireza Sanaee
>
> Add has_caches flag to SMPCompatProps, which helps in avoiding
> extra checks for every single layer of caches in x86 (and ARM in
> future).
>
> Signed-off-by: Alireza Sanaee
> Signed-off-by: Zhao Liu
LGTM
Reviewed-by: Jonathan Cameron
> ---
> Note: Picked from Alireza's series with the changes:
> * Moved the flag to SMPCompatProps with a new name "has_caches".
>This way, it remains consistent with the function and style of
>"has_clusters" in SMPCompatProps.
> * Dropped my previous TODO with the new flag.
> ---
> Changes since Patch v2:
> * Picked a new patch frome Alireza's ARM smp-cache series.
> ---
> hw/core/machine-smp.c | 2 ++
> include/hw/boards.h | 3 +++
> target/i386/cpu.c | 9 -
> 3 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/hw/core/machine-smp.c b/hw/core/machine-smp.c
> index f3edbded2e7b..16e456678cb6 100644
> --- a/hw/core/machine-smp.c
> +++ b/hw/core/machine-smp.c
> @@ -367,6 +367,8 @@ bool machine_parse_smp_cache(MachineState *ms,
> return false;
> }
>
> +mc->smp_props.has_caches = true;
> +
> return true;
> }
>
> diff --git a/include/hw/boards.h b/include/hw/boards.h
> index e4a1035e3fa1..af62b09c89d1 100644
> --- a/include/hw/boards.h
> +++ b/include/hw/boards.h
> @@ -153,6 +153,8 @@ typedef struct {
> * @modules_supported - whether modules are supported by the machine
> * @cache_supported - whether cache (l1d, l1i, l2 and l3) configuration are
> *supported by the machine
> + * @has_caches - whether cache properties are explicitly specified in the
> + * user provided smp-cache configuration
> */
> typedef struct {
> bool prefer_sockets;
> @@ -163,6 +165,7 @@ typedef struct {
> bool drawers_supported;
> bool modules_supported;
> bool cache_supported[CACHE_LEVEL_AND_TYPE__MAX];
> +bool has_caches;
> } SMPCompatProps;
>
> /**
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index c8a04faf3764..6f711e98b527 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -7853,12 +7853,11 @@ static void x86_cpu_realizefn(DeviceState *dev, Error
> **errp)
>
> #ifndef CONFIG_USER_ONLY
> MachineState *ms = MACHINE(qdev_get_machine());
> +MachineClass *mc = MACHINE_GET_CLASS(ms);
>
> -/*
> - * TODO: Add a SMPCompatProps.has_caches flag to avoid useless Updates
> - * if user didn't set smp_cache.
> - */
> -x86_cpu_update_smp_cache_topo(ms, cpu);
> +if (mc->smp_props.has_caches) {
> +x86_cpu_update_smp_cache_topo(ms, cpu);
> +}
>
> qemu_register_reset(x86_cpu_machine_reset_cb, cpu);
>
Re: [PATCH v3 1/7] hw/core: Make CPU topology enumeration arch-agnostic
RESEND (sorry for noise).
Quotes in email address issue meant the server bounced it.
On Thu, 17 Oct 2024 09:52:27 +0100
Jonathan Cameron wrote:
> On Sat, 12 Oct 2024 18:44:23 +0800
> Zhao Liu wrote:
>
> > Cache topology needs to be defined based on CPU topology levels. Thus,
> > define CPU topology enumeration in qapi/machine.json to make it generic
> > for all architectures.
> >
> > To match the general topology naming style, rename CPU_TOPO_LEVEL_* to
> > CPU_TOPOLOGY_LEVEL_*, and rename SMT and package levels to thread and
> > socket.
> >
> > Also, enumerate additional topology levels for non-i386 arches, and add
> > a CPU_TOPOLOGY_LEVEL_DEFAULT to help future smp-cache object to work
> > with compatibility requirement of arch-specific cache topology models.
> >
> > Signed-off-by: Zhao Liu
> > Tested-by: Yongwei Ma
> LGTM with one incredibly trivial comment inline.
>
> Reviewed-by: Jonathan Cameron
>
> > #endif /* HW_I386_TOPOLOGY_H */
> > diff --git a/qapi/machine-common.json b/qapi/machine-common.json
> > index b64e4895cfd7..db3e499fb382 100644
> > --- a/qapi/machine-common.json
> > +++ b/qapi/machine-common.json
> > @@ -5,7 +5,7 @@
> > # See the COPYING file in the top-level directory.
> >
> > ##
> > -# = Machines S390 data types
> > +# = Common machine types
> > ##
> >
> > ##
> > @@ -18,3 +18,47 @@
> > ##
> > { 'enum': 'S390CpuEntitlement',
> >'data': [ 'auto', 'low', 'medium', 'high' ] }
> > +
> > +##
> > +# @CpuTopologyLevel:
> > +#
> > +# An enumeration of CPU topology levels.
> > +#
> > +# @invalid: Invalid topology level.
>
> Really trivial but why a capital I on Invalid here but not the
> t of thread below?
>
> > +#
> > +# @thread: thread level, which would also be called SMT level or
> > +# logical processor level. The @threads option in
> > +# SMPConfiguration is used to configure the topology of this
> > +# level.
>
Re: [PATCH v3 0/7] Introduce SMP Cache Topology
RESEND (again, sorry) as didn't reach list.
Issue some stray " in various email addresses.
On Sat, 12 Oct 2024 18:44:22 +0800
Zhao Liu wrote:
> Hi all,
>
> Compared with v2 [1], the changes in v3 are quite minor, and most of
> patches (except for patch 1 and 7) have received Jonathan’s R/b (thanks
> Jonathan!).
>
> Meanwhile, ARM side has also worked a lot on the smp-cache based on
> this series [2], so I think we are very close to the final merge, to
> catch up with this cycle. :)
This would finally solve a long standing missing control for our
virtualization usecases (TCG and MPAM stuff is an added bonus),
so I'm very keen in this making 9.2 (and maybe even the ARM part
of things happen to move fast enough). Ali is out this week,
but should be back sometime next week. Looks like rebase of his
ARM patches on this should be simple!
I think this set mostly needs a QAPI review (perhaps from Markus?)
>
> This series is based on the commit 7e3b6d8063f2 ("Merge tag 'crypto-
> fixes-pull-request' of https://gitlab.com/berrange/qemu into staging").
>
> Background
> ==
>
> The x86 and ARM (RISCV) need to allow user to configure cache properties
*laughs*. I definitely going to start emailing ARM folk with
ARM (RISCV)
:)
> (current only topology):
> * For x86, the default cache topology model (of max/host CPU) does not
>always match the Host's real physical cache topology. Performance can
>increase when the configured virtual topology is closer to the
>physical topology than a default topology would be.
> * For ARM, QEMU can't get the cache topology information from the CPU
>registers, then user configuration is necessary. Additionally, the
>cache information is also needed for MPAM emulation (for TCG) to
>build the right PPTT. (Originally from Jonathan)
Re: [PATCH v4 0/2] riscv: char: Avoid dropped charecters
On 10/09/2024 06.54, Alistair Francis wrote: This series fixes: https://gitlab.com/qemu-project/qemu/-/issues/2114 This converts the RISC-V charecter device callers of qemu_chr_fe_write() to either use qemu_chr_fe_write_all() or to call qemu_chr_fe_write() async and act on the return value. v4: - Drop the unused char_tx_time - Update the migration in vmstate_sifive_uart v3: - Fixup spelling v2: - Use Fifo8 for the Sifive UART instead of a custom FIFO Alistair Francis (2): hw/char: riscv_htif: Use blocking qemu_chr_fe_write_all hw/char: sifive_uart: Print uart characters async Hi! What's the status of these patches? Are they good to go, or do they still need more work? (I'm asking because I'd like to convert tests/avocado/riscv_opensbi.py to the functional test framework, but it would be good to have the problem with the dropped characters fixed first) Thanks, Thomas
Re: [PATCH v4 7/8] tests/unit/test-char: add unit test for the `mux-be` multiplexer
Hi Marc-André, On Wed, Oct 16, 2024 at 1:36 PM Marc-André Lureau wrote: > > Hi > > On Wed, Oct 16, 2024 at 2:28 PM Roman Penyaev wrote: > > > > The test is trivial: several backends, 1 `mux-be`, 1 frontend > > do the buffer write and read. Pipe is used for EAGAIN verification. > > > > Signed-off-by: Roman Penyaev > > Cc: "Marc-André Lureau" > > Cc: qemu-devel@nongnu.org > > --- > > tests/unit/test-char.c | 306 - > > 1 file changed, 304 insertions(+), 2 deletions(-) > > please fix the few leaks (found with --enable-asan) Did not know about this option. Should be easy, thanks. -- Roman
Re: [PATCH] hw/sd/omap_mmc: Don't use sd_cmd_type_t
On 10/17/24 09:27, Peter Maydell wrote:
In commit 1ab08790bb75e4 we did some refactoring of the SD card
implementation, which included a rearrangement of the sd_cmd_type_t
enum values. Unfortunately we didn't notice that this enum is not
used solely inside the SD card model itself, but is also used by the
OMAP MMC controller device. In the OMAP MMC controller, it is used
to implement the handling of the Type field of the MMC_CMD register,
so changing the enum values so that they no longer lined up with the
bit definitions for that register field broke the controller model.
The effect is that Linux fails to boot from an SD card on the "sx1"
machine.
Give omap-mmc its own enum which we can document as needing to match
the encoding used in this device's register, so it isn't sharing
sd_cmd_type_t with the SD card model any more. We can then move
sd_cmd_type_t's definition out of sd.h and into sd.c, which is the
only place that uses it.
Cc: qemu-sta...@nongnu.org
Fixes: 1ab08790bb75 ("hw/sd/sdcard: Store command type in SDProto")
Signed-off-by: Peter Maydell
Tested-by: Guenter Roeck
Re: [PATCH v4 5/6] migration: Support periodic RAMBlock dirty bitmap sync
On Thu, Oct 17, 2024 at 02:42:54PM +0800, yong.hu...@smartx.com wrote:
> +void cpu_throttle_dirty_sync_timer_tick(void *opaque)
> +{
> +static uint64_t prev_sync_cnt;
We may need to reset this in case migration got cancelled and invoked
again, to make sure it keeps working in the 2nd run.
> +uint64_t sync_cnt = stat64_get(&mig_stats.dirty_sync_count);
> +
> +/*
> + * The first iteration copies all memory anyhow and has no
> + * effect on guest performance, therefore omit it to avoid
> + * paying extra for the sync penalty.
> + */
> +if (sync_cnt <= 1) {
> +goto end;
> +}
> +
> +if (sync_cnt == prev_sync_cnt) {
> +trace_cpu_throttle_dirty_sync();
> +WITH_RCU_READ_LOCK_GUARD() {
> +migration_bitmap_sync_precopy(false);
> +}
> +}
> +
> +end:
> +prev_sync_cnt = stat64_get(&mig_stats.dirty_sync_count);
> +
> +timer_mod(throttle_dirty_sync_timer,
> +qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL_RT) +
> +CPU_THROTTLE_DIRTY_SYNC_TIMESLICE_MS);
> +}
Please both of you have a look on whether you agree I squash below into
this patch when merge:
===8<===
>From 84a2544eab73e35dbd35fed3b1440169915f9aa4 Mon Sep 17 00:00:00 2001
From: Peter Xu
Date: Thu, 17 Oct 2024 15:27:19 -0400
Subject: [PATCH] fixup! migration: Support periodic RAMBlock dirty bitmap sync
Signed-off-by: Peter Xu
---
migration/cpu-throttle.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/migration/cpu-throttle.c b/migration/cpu-throttle.c
index 342681cdd4..3df287d8d3 100644
--- a/migration/cpu-throttle.c
+++ b/migration/cpu-throttle.c
@@ -36,6 +36,7 @@
static QEMUTimer *throttle_timer, *throttle_dirty_sync_timer;
static unsigned int throttle_percentage;
static bool throttle_dirty_sync_timer_active;
+static uint64_t throttle_dirty_sync_count_prev;
#define CPU_THROTTLE_PCT_MIN 1
#define CPU_THROTTLE_PCT_MAX 99
@@ -133,7 +134,6 @@ int cpu_throttle_get_percentage(void)
void cpu_throttle_dirty_sync_timer_tick(void *opaque)
{
-static uint64_t prev_sync_cnt;
uint64_t sync_cnt = stat64_get(&mig_stats.dirty_sync_count);
/*
@@ -145,7 +145,7 @@ void cpu_throttle_dirty_sync_timer_tick(void *opaque)
goto end;
}
-if (sync_cnt == prev_sync_cnt) {
+if (sync_cnt == throttle_dirty_sync_count_prev) {
trace_cpu_throttle_dirty_sync();
WITH_RCU_READ_LOCK_GUARD() {
migration_bitmap_sync_precopy(false);
@@ -153,7 +153,7 @@ void cpu_throttle_dirty_sync_timer_tick(void *opaque)
}
end:
-prev_sync_cnt = stat64_get(&mig_stats.dirty_sync_count);
+throttle_dirty_sync_count_prev = stat64_get(&mig_stats.dirty_sync_count);
timer_mod(throttle_dirty_sync_timer,
qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL_RT) +
@@ -171,6 +171,11 @@ void cpu_throttle_dirty_sync_timer(bool enable)
if (enable) {
if (!cpu_throttle_dirty_sync_active()) {
+/*
+ * Always reset the dirty sync count cache, in case migration
+ * was cancelled once.
+ */
+throttle_dirty_sync_count_prev = 0;
timer_mod(throttle_dirty_sync_timer,
qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL_RT) +
CPU_THROTTLE_DIRTY_SYNC_TIMESLICE_MS);
--
2.45.0
--
Peter Xu
Re: [Stable-9.1.1 00/49] Patch Round-up for stable 9.1.1, freeze on 2024-10-16 (frozen)
On 17.10.2024 20:47, Paolo Bonzini wrote: My next pull request includes a few more: https://gitlab.com/bonzini/qemu/-/commit/15d955975bd484c2c66af0d6daaa02a7d04d2256.patch https://gitlab.com/bonzini/qemu/-/commit/64e0e63ea16aa0122dc0c41a0679da0ae4616208.patch https://gitlab.com/bonzini/qemu/-/commit/615586cb356811e46c2e5f85c36db4b93f8381cd.patch yeah, I noted them already, either earlier or due to Cc: qemu-stable. These will be in the next release though since they missed the freeze date (Oct-16). I also note the wording in my cover letter for the series should be changed a bit, so it is clear the other possible patches will only be considered for the next stable release. Thank you for letting me know, that's the most important part anyway! /mjt
Re: [PATCH] Fix calculation of minimum in colo_compare_tcp
It looks like nobody has sent a pull request for this fix up to now. Is
it trivial enough for qemu-trivial? And maybe qemu-stable could also
apply it to older versions.
Stefan W.
Am 10.09.24 um 04:38 schrieb Zhang, Chen:
-Original Message-
From: Stefan Weil
Sent: Tuesday, September 10, 2024 4:43 AM
To: Zhang, Chen; Li Zhijian;
Jason Wang
Cc:qemu-devel@nongnu.org; Stefan Weil
Subject: [PATCH] Fix calculation of minimum in colo_compare_tcp
GitHub's CodeQL reports a critical error which is fixed by using the MIN
macro:
Unsigned difference expression compared to zero
Signed-off-by: Stefan Weil
Looks good to me.
Reviewed-by: Zhang Chen
Thanks
Chen
---
net/colo-compare.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/colo-compare.c b/net/colo-compare.c index
c4ad0ab71f..39f90c4065 100644
--- a/net/colo-compare.c
+++ b/net/colo-compare.c
@@ -412,8 +412,7 @@ static void colo_compare_tcp(CompareState *s,
Connection *conn)
* can ensure that the packet's payload is acknowledged by
* primary and secondary.
*/
-uint32_t min_ack = conn->pack - conn->sack > 0 ?
- conn->sack : conn->pack;
+uint32_t min_ack = MIN(conn->pack, conn->sack);
pri:
if (g_queue_is_empty(&conn->primary_list)) {
--
2.39.3 (Apple Git-146)
Re: [PATCH v6 09/12] migration/multifd: Enable DSA offloading in multifd sender path.
Yichen Wang writes:
> From: Hao Xiang
>
> Multifd sender path gets an array of pages queued by the migration
> thread. It performs zero page checking on every page in the array.
> The pages are classfied as either a zero page or a normal page. This
> change uses Intel DSA to offload the zero page checking from CPU to
> the DSA accelerator. The sender thread submits a batch of pages to DSA
> hardware and waits for the DSA completion thread to signal for work
> completion.
>
> Signed-off-by: Hao Xiang
> Signed-off-by: Yichen Wang
> ---
> migration/multifd-zero-page.c | 133 ++
> migration/multifd.c | 19 -
> migration/multifd.h | 5 ++
> 3 files changed, 141 insertions(+), 16 deletions(-)
>
> diff --git a/migration/multifd-zero-page.c b/migration/multifd-zero-page.c
> index f1e988a959..e4bfff23a4 100644
> --- a/migration/multifd-zero-page.c
> +++ b/migration/multifd-zero-page.c
> @@ -21,7 +21,9 @@
>
> static bool multifd_zero_page_enabled(void)
> {
> -return migrate_zero_page_detection() == ZERO_PAGE_DETECTION_MULTIFD;
> +ZeroPageDetection curMethod = migrate_zero_page_detection();
> +return (curMethod == ZERO_PAGE_DETECTION_MULTIFD ||
> +curMethod == ZERO_PAGE_DETECTION_DSA_ACCEL);
> }
>
> static void swap_page_offset(ram_addr_t *pages_offset, int a, int b)
> @@ -37,26 +39,49 @@ static void swap_page_offset(ram_addr_t *pages_offset,
> int a, int b)
> pages_offset[b] = temp;
> }
>
> +#ifdef CONFIG_DSA_OPT
> +
> +static void swap_result(bool *results, int a, int b)
> +{
> +bool temp;
> +
> +if (a == b) {
> +return;
> +}
> +
> +temp = results[a];
> +results[a] = results[b];
> +results[b] = temp;
> +}
> +
> /**
> - * multifd_send_zero_page_detect: Perform zero page detection on all pages.
> + * zero_page_detect_dsa: Perform zero page detection using
> + * Intel Data Streaming Accelerator (DSA).
> *
> - * Sorts normal pages before zero pages in p->pages->offset and updates
> - * p->pages->normal_num.
> + * Sorts normal pages before zero pages in pages->offset and updates
> + * pages->normal_num.
> *
> * @param p A pointer to the send params.
> */
> -void multifd_send_zero_page_detect(MultiFDSendParams *p)
> +static void zero_page_detect_dsa(MultiFDSendParams *p)
> {
> MultiFDPages_t *pages = &p->data->u.ram;
> RAMBlock *rb = pages->block;
> -int i = 0;
> -int j = pages->num - 1;
> +bool *results = p->dsa_batch_task->results;
>
> -if (!multifd_zero_page_enabled()) {
> -pages->normal_num = pages->num;
> -goto out;
> +for (int i = 0; i < pages->num; i++) {
> +p->dsa_batch_task->addr[i] =
> +(ram_addr_t)(rb->host + pages->offset[i]);
> }
>
> +buffer_is_zero_dsa_batch_sync(p->dsa_batch_task,
> + (const void **)p->dsa_batch_task->addr,
> + pages->num,
> + multifd_ram_page_size());
> +
> +int i = 0;
> +int j = pages->num - 1;
> +
> /*
> * Sort the page offset array by moving all normal pages to
> * the left and all zero pages to the right of the array.
> @@ -64,23 +89,39 @@ void multifd_send_zero_page_detect(MultiFDSendParams *p)
> while (i <= j) {
> uint64_t offset = pages->offset[i];
>
> -if (!buffer_is_zero(rb->host + offset, multifd_ram_page_size())) {
> +if (!results[i]) {
> i++;
> continue;
> }
>
> +swap_result(results, i, j);
> swap_page_offset(pages->offset, i, j);
> ram_release_page(rb->idstr, offset);
> j--;
> }
>
> pages->normal_num = i;
> +}
>
> -out:
> -stat64_add(&mig_stats.normal_pages, pages->normal_num);
> -stat64_add(&mig_stats.zero_pages, pages->num - pages->normal_num);
> +void multifd_dsa_cleanup(void)
> +{
> +qemu_dsa_cleanup();
> +}
> +
> +#else
> +
> +static void zero_page_detect_dsa(MultiFDSendParams *p)
> +{
> +g_assert_not_reached();
> +}
> +
> +void multifd_dsa_cleanup(void)
> +{
> +g_assert_not_reached();
> }
>
> +#endif
> +
> void multifd_recv_zero_page_process(MultiFDRecvParams *p)
> {
> for (int i = 0; i < p->zero_num; i++) {
> @@ -92,3 +133,67 @@ void multifd_recv_zero_page_process(MultiFDRecvParams *p)
> }
> }
> }
> +
> +/**
> + * zero_page_detect_cpu: Perform zero page detection using CPU.
> + *
> + * Sorts normal pages before zero pages in p->pages->offset and updates
> + * p->pages->normal_num.
> + *
> + * @param p A pointer to the send params.
> + */
> +static void zero_page_detect_cpu(MultiFDSendParams *p)
> +{
> +MultiFDPages_t *pages = &p->data->u.ram;
> +RAMBlock *rb = pages->block;
> +int i = 0;
> +int j = pages->num - 1;
> +
> +if (!multifd_zero_page_enabled()) {
> +pages->normal_num = pages->num;
> +return;
> +}
This is already do
