Re: [PATCH v3] hw/audio/virtio-snd: Use device endianness instead of target one
On Mon, Apr 22, 2024 at 11:07:21PM +0200, Philippe Mathieu-Daudé wrote:
> On 22/4/24 23:02, Michael S. Tsirkin wrote:
> > On Mon, Apr 22, 2024 at 04:20:56PM +0200, Philippe Mathieu-Daudé wrote:
> > > Since VirtIO devices can change endianness at runtime,
> > > we need to use the device endianness, not the target
> > > one.
> > >
> > > Cc: qemu-sta...@nongnu.org
> > > Fixes: eb9ad377bb ("virtio-sound: handle control messages and streams")
> > > Signed-off-by: Philippe Mathieu-Daudé
> >
> >
> >
> > This is all completely bogus. Virtio SND is from Virtio 1.0 only.
> > It is unconditionally little endian.
>
> Oh, then the fix is as simple as:
>
> -as->endianness = target_words_bigendian() ? 1 : 0;
> +as->endianness = 0; /* VIRTIO 1.0: always LE. */
Makes sense. Pls clarify in commit log whether the incorrect
value leads to any failures or this was found by code review.
> > If it's not it's a guest bug pls just fix it there.
> >
> >
> > > ---
> > > v2: Use virtio_is_big_endian()
> > > v3: Remove "hw/core/cpu.h
> > > ---
> > > hw/audio/virtio-snd.c | 9 +
> > > 1 file changed, 5 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/hw/audio/virtio-snd.c b/hw/audio/virtio-snd.c
> > > index c80b58bf5d..939cd78026 100644
> > > --- a/hw/audio/virtio-snd.c
> > > +++ b/hw/audio/virtio-snd.c
> > > @@ -24,7 +24,6 @@
> > > #include "trace.h"
> > > #include "qapi/error.h"
> > > #include "hw/audio/virtio-snd.h"
> > > -#include "hw/core/cpu.h"
> > > #define VIRTIO_SOUND_VM_VERSION 1
> > > #define VIRTIO_SOUND_JACK_DEFAULT 0
> > > @@ -395,13 +394,15 @@ static uint32_t virtio_snd_get_qemu_freq(uint32_t
> > > rate)
> > >* Get QEMU Audiosystem compatible audsettings from virtio based pcm
> > > stream
> > >* params.
> > >*/
> > > -static void virtio_snd_get_qemu_audsettings(audsettings *as,
> > > +static void virtio_snd_get_qemu_audsettings(VirtIOSound *s, audsettings
> > > *as,
> > > virtio_snd_pcm_set_params
> > > *params)
> > > {
> > > +VirtIODevice *vdev = VIRTIO_DEVICE(s);
> > > +
> > > as->nchannels = MIN(AUDIO_MAX_CHANNELS, params->channels);
> > > as->fmt = virtio_snd_get_qemu_format(params->format);
> > > as->freq = virtio_snd_get_qemu_freq(params->rate);
> > > -as->endianness = target_words_bigendian() ? 1 : 0;
> > > +as->endianness = virtio_is_big_endian(vdev) ? 1 : 0;
> > > }
> > > /*
> > > @@ -464,7 +465,7 @@ static uint32_t virtio_snd_pcm_prepare(VirtIOSound
> > > *s, uint32_t stream_id)
> > > s->pcm->streams[stream_id] = stream;
> > > }
> > > -virtio_snd_get_qemu_audsettings(, params);
> > > +virtio_snd_get_qemu_audsettings(s, , params);
> > > stream->info.direction = stream_id < s->snd_conf.streams / 2 +
> > > (s->snd_conf.streams & 1) ? VIRTIO_SND_D_OUTPUT :
> > > VIRTIO_SND_D_INPUT;
> > > stream->info.hdr.hda_fn_nid = VIRTIO_SOUND_HDA_FN_NID;
> > > --
> > > 2.41.0
> >
Re: [PATCH v3] hw/audio/virtio-snd: Use device endianness instead of target one
On Mon, Apr 22, 2024 at 04:20:56PM +0200, Philippe Mathieu-Daudé wrote:
> Since VirtIO devices can change endianness at runtime,
> we need to use the device endianness, not the target
> one.
>
> Cc: qemu-sta...@nongnu.org
> Fixes: eb9ad377bb ("virtio-sound: handle control messages and streams")
> Signed-off-by: Philippe Mathieu-Daudé
This is all completely bogus. Virtio SND is from Virtio 1.0 only.
It is unconditionally little endian.
If it's not it's a guest bug pls just fix it there.
> ---
> v2: Use virtio_is_big_endian()
> v3: Remove "hw/core/cpu.h
> ---
> hw/audio/virtio-snd.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/hw/audio/virtio-snd.c b/hw/audio/virtio-snd.c
> index c80b58bf5d..939cd78026 100644
> --- a/hw/audio/virtio-snd.c
> +++ b/hw/audio/virtio-snd.c
> @@ -24,7 +24,6 @@
> #include "trace.h"
> #include "qapi/error.h"
> #include "hw/audio/virtio-snd.h"
> -#include "hw/core/cpu.h"
>
> #define VIRTIO_SOUND_VM_VERSION 1
> #define VIRTIO_SOUND_JACK_DEFAULT 0
> @@ -395,13 +394,15 @@ static uint32_t virtio_snd_get_qemu_freq(uint32_t rate)
> * Get QEMU Audiosystem compatible audsettings from virtio based pcm stream
> * params.
> */
> -static void virtio_snd_get_qemu_audsettings(audsettings *as,
> +static void virtio_snd_get_qemu_audsettings(VirtIOSound *s, audsettings *as,
> virtio_snd_pcm_set_params
> *params)
> {
> +VirtIODevice *vdev = VIRTIO_DEVICE(s);
> +
> as->nchannels = MIN(AUDIO_MAX_CHANNELS, params->channels);
> as->fmt = virtio_snd_get_qemu_format(params->format);
> as->freq = virtio_snd_get_qemu_freq(params->rate);
> -as->endianness = target_words_bigendian() ? 1 : 0;
> +as->endianness = virtio_is_big_endian(vdev) ? 1 : 0;
> }
>
> /*
> @@ -464,7 +465,7 @@ static uint32_t virtio_snd_pcm_prepare(VirtIOSound *s,
> uint32_t stream_id)
> s->pcm->streams[stream_id] = stream;
> }
>
> -virtio_snd_get_qemu_audsettings(, params);
> +virtio_snd_get_qemu_audsettings(s, , params);
> stream->info.direction = stream_id < s->snd_conf.streams / 2 +
> (s->snd_conf.streams & 1) ? VIRTIO_SND_D_OUTPUT : VIRTIO_SND_D_INPUT;
> stream->info.hdr.hda_fn_nid = VIRTIO_SOUND_HDA_FN_NID;
> --
> 2.41.0
Re: [PATCH] vhost-user-test: no set non-blocking for cal fd less than 0.
On Thu, Apr 11, 2024 at 03:35:55PM +0800, Yuxue Liu yuxue@jaguarmicro.com
wrote:
> From: Yuxue Liu
>
> In the scenario where vhost-user sets eventfd to -1,
> qemu_chr_fe_get_msgfds retrieves fd as -1. When vhost_user_read
> receives, it does not perform blocking operations on the descriptor
> with fd=-1, so non-blocking operations should not be performed here
> either.This is a normal use case. Calling g_unix_set_fd_nonblocking
> at this point will cause the test to interrupt.
>
> When vhost_user_write sets the call fd to -1, it sets the number of
> fds to 0, so the fds obtained by qemu_chr_fe_get_msgfds will also
> be 0.
>
> Signed-off-by: Yuxue Liu
A bit more detail here please.
When does all this happen?
> ---
> tests/qtest/vhost-user-test.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/tests/qtest/vhost-user-test.c b/tests/qtest/vhost-user-test.c
> index d4e437265f..7c8ef6268d 100644
> --- a/tests/qtest/vhost-user-test.c
> +++ b/tests/qtest/vhost-user-test.c
> @@ -458,7 +458,10 @@ static void chr_read(void *opaque, const uint8_t *buf,
> int size)
> case VHOST_USER_SET_VRING_KICK:
> case VHOST_USER_SET_VRING_CALL:
> /* consume the fd */
> -qemu_chr_fe_get_msgfds(chr, , 1);
> +if (!qemu_chr_fe_get_msgfds(chr, , 1) && fd < 0) {
> +qos_printf("call fd :%d, no set non-blocking\n", fd);
> +break;
> +}
> /*
> * This is a non-blocking eventfd.
> * The receive function forces it to be blocking,
> --
> 2.43.0
Re: [PATCH] virtio-pci: Fix the failure process in kvm_virtio_pci_vector_use_one()
On Tue, Apr 16, 2024 at 02:14:57PM +0100, Peter Maydell wrote:
> On Tue, 16 Apr 2024 at 13:41, Cindy Lu wrote:
> >
> > On Tue, Apr 16, 2024 at 8:30 PM Peter Maydell
> > wrote:
> > >
> > > On Tue, 16 Apr 2024 at 13:29, Cindy Lu wrote:
> > > >
> > > > In function kvm_virtio_pci_vector_use_one(), in the undo label,
> > > > the function will get the vector incorrectly while using
> > > > VIRTIO_CONFIG_IRQ_IDX
> > > > To fix this, we remove this label and simplify the failure process
And then what happens? It's unclear whether it's a real or
theoretical issue.
> > > > Fixes: f9a09ca3ea ("vhost: add support for configure interrupt")
> > > > Cc: qemu-sta...@nongnu.org
> > > > Signed-off-by: Cindy Lu
> > > > ---
> > > > hw/virtio/virtio-pci.c | 19 +++
> > > > 1 file changed, 3 insertions(+), 16 deletions(-)
> > > >
> > > > diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> > > > index b138fa127a..565bdb0897 100644
> > > > --- a/hw/virtio/virtio-pci.c
> > > > +++ b/hw/virtio/virtio-pci.c
> > > > @@ -892,7 +892,7 @@ static int
> > > > kvm_virtio_pci_vector_use_one(VirtIOPCIProxy *proxy, int queue_no)
> > > > }
> > > > ret = kvm_virtio_pci_vq_vector_use(proxy, vector);
> > > > if (ret < 0) {
> > > > -goto undo;
> > > > +return ret;
> > > > }
> > > > /*
> > > > * If guest supports masking, set up irqfd now.
> > > > @@ -902,25 +902,12 @@ static int
> > > > kvm_virtio_pci_vector_use_one(VirtIOPCIProxy *proxy, int queue_no)
> > > > ret = kvm_virtio_pci_irqfd_use(proxy, n, vector);
> > > > if (ret < 0) {
> > > > kvm_virtio_pci_vq_vector_release(proxy, vector);
> > > > -goto undo;
> > > > +kvm_virtio_pci_irqfd_release(proxy, n, vector);
> > >
> > > Are you sure this is right? The kvm_virtio_pci_irqfd_use()
> > > just failed, so why do we need to call
> > > kvm_virtio_pci_irqfd_release() ?
>
> > This version should be correct. when kvm_virtio_pci_irqfd_use() fail
> > we need to call kvm_virtio_pci_vq_vector_release() and
> > kvm_virtio_pci_irqfd_release()
> > but for kvm_virtio_pci_vq_vector_use fail we can simple return,
>
> But *why* do we need to call kvm_virtio_pci_irqfd_release()?
>
> In most API designs, this kind of pairing of "get/use/allocate
> something" and "free/release something" function only
> requires you to do the "release" if the "get" succeeded,
> because if the "get" fails it's supposed to fail in way that
> means "I didn't do anything". Is this API not following that
> standard pattern ?
I am just as puzzled.
> > in old version there is a error in failure process.
> > while the kvm_virtio_pci_vq_vector_use fail it call the
> > kvm_virtio_pci_irqfd_release,but at this time this is irqfd
> > is not using now
>
> thanks
> -- PMM
[PULL 1/1] virtio-pci: fix use of a released vector
From: Cindy Lu
During the booting process of the non-standard image, the behavior of the
called function in qemu is as follows:
1. vhost_net_stop() was triggered by guest image. This will call the function
virtio_pci_set_guest_notifiers() with assgin= false,
virtio_pci_set_guest_notifiers(） will release the irqfd for vector 0
2. virtio_reset() was triggered, this will set configure vector to
VIRTIO_NO_VECTOR
3.vhost_net_start() was called (at this time, the configure vector is
still VIRTIO_NO_VECTOR) and then call virtio_pci_set_guest_notifiers() with
assgin=true, so the irqfd for vector 0 is still not "init" during this process
4. The system continues to boot and sets the vector back to 0. After that
msix_fire_vector_notifier() was triggered to unmask the vector 0 and meet the
crash
To fix the issue, we need to support changing the vector after
VIRTIO_CONFIG_S_DRIVER_OK is set.
(gdb) bt
0 __pthread_kill_implementation (threadid=,
signo=signo@entry=6, no_tid=no_tid@entry=0)
at pthread_kill.c:44
1 0x7fc87148ec53 in __pthread_kill_internal (signo=6, threadid=) at pthread_kill.c:78
2 0x7fc87143e956 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
3 0x7fc8714287f4 in __GI_abort () at abort.c:79
4 0x7fc87142871b in __assert_fail_base
(fmt=0x7fc8715bbde0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=0x5606413efd53 "ret == 0", file=0x5606413ef87d
"../accel/kvm/kvm-all.c", line=1837, function=) at assert.c:92
5 0x7fc871437536 in __GI___assert_fail
(assertion=0x5606413efd53 "ret == 0", file=0x5606413ef87d
"../accel/kvm/kvm-all.c", line=1837, function=0x5606413f06f0
<__PRETTY_FUNCTION__.19> "kvm_irqchip_commit_routes") at assert.c:101
6 0x560640f884b5 in kvm_irqchip_commit_routes (s=0x560642cae1f0) at
../accel/kvm/kvm-all.c:1837
7 0x560640c98f8e in virtio_pci_one_vector_unmask
(proxy=0x560643c65f00, queue_no=4294967295, vector=0, msg=...,
n=0x560643c6e4c8)
at ../hw/virtio/virtio-pci.c:1005
8 0x560640c99201 in virtio_pci_vector_unmask (dev=0x560643c65f00,
vector=0, msg=...)
at ../hw/virtio/virtio-pci.c:1070
9 0x560640bc402e in msix_fire_vector_notifier (dev=0x560643c65f00,
vector=0, is_masked=false)
at ../hw/pci/msix.c:120
10 0x560640bc40f1 in msix_handle_mask_update (dev=0x560643c65f00, vector=0,
was_masked=true)
at ../hw/pci/msix.c:140
11 0x560640bc4503 in msix_table_mmio_write (opaque=0x560643c65f00, addr=12,
val=0, size=4)
at ../hw/pci/msix.c:231
12 0x560640f26d83 in memory_region_write_accessor
(mr=0x560643c66540, addr=12, value=0x7fc86b7bc628, size=4, shift=0,
mask=4294967295, attrs=...)
at ../system/memory.c:497
13 0x560640f270a6 in access_with_adjusted_size
(addr=12, value=0x7fc86b7bc628, size=4, access_size_min=1,
access_size_max=4, access_fn=0x560640f26c8d ,
mr=0x560643c66540, attrs=...) at ../system/memory.c:573
14 0x560640f2a2b5 in memory_region_dispatch_write (mr=0x560643c66540,
addr=12, data=0, op=MO_32, attrs=...)
at ../system/memory.c:1521
15 0x560640f37bac in flatview_write_continue
(fv=0x7fc65805e0b0, addr=4273803276, attrs=..., ptr=0x7fc871e9c028, len=4,
addr1=12, l=4, mr=0x560643c66540)
at ../system/physmem.c:2714
16 0x560640f37d0f in flatview_write
(fv=0x7fc65805e0b0, addr=4273803276, attrs=..., buf=0x7fc871e9c028, len=4)
at ../system/physmem.c:2756
17 0x560640f380bf in address_space_write
(as=0x560642161ae0 , addr=4273803276, attrs=...,
buf=0x7fc871e9c028, len=4)
at ../system/physmem.c:2863
18 0x560640f3812c in address_space_rw
(as=0x560642161ae0 , addr=4273803276, attrs=...,
buf=0x7fc871e9c028, len=4, is_write=true) at ../system/physmem.c:2873
--Type for more, q to quit, c to continue without paging--
19 0x560640f8aa55 in kvm_cpu_exec (cpu=0x560642f205e0) at
../accel/kvm/kvm-all.c:2915
20 0x560640f8d731 in kvm_vcpu_thread_fn (arg=0x560642f205e0) at
../accel/kvm/kvm-accel-ops.c:51
21 0x5606411949f4 in qemu_thread_start (args=0x560642f292b0) at
../util/qemu-thread-posix.c:541
22 0x7fc87148cdcd in start_thread (arg=) at
pthread_create.c:442
23 0x7fc871512630 in clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb)
MST: coding style and typo fixups
Fixes: f9a09ca3ea ("vhost: add support for configure interrupt")
Cc: qemu-sta...@nongnu.org
Signed-off-by: Cindy Lu
Message-ID:
<2321ade5f601367efe7380c04e3f61379c59b48f.1713173550.git@redhat.com>
Cc: Lei Yang
Cc: Jason Wang
Signed-off-by: Michael S. Tsirkin
Tested-by: Cindy Lu
---
hw/virtio/virtio-pci.c | 37 +++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index cb6940fc0e..cb159fd078 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1424,6 +1424,38 @@ static int virtio_pci_ad
[PULL 0/1] virtio: bugfix
The following changes since commit e104a960c33b68fedf26dfb7b8e00abab8f2: qdev-monitor: fix error message in find_device_state() (2024-04-09 02:31:33 -0400) are available in the Git repository at: https://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream for you to fetch changes up to 2ce6cff94df2650c460f809e5ad263f1d22507c0: virtio-pci: fix use of a released vector (2024-04-15 06:50:44 -0400) virtio: bugfix A last minute fix for a use of a vector after it's released. Signed-off-by: Michael S. Tsirkin Cindy Lu (1): virtio-pci: fix use of a released vector hw/virtio/virtio-pci.c | 37 +++-- 1 file changed, 35 insertions(+), 2 deletions(-)
Re: [PATCH v2] hw/i386/acpi: Set PCAT_COMPAT bit only when pic is not disabled
On Mon, Apr 15, 2024 at 05:51:56AM -0400, Michael S. Tsirkin wrote: > On Mon, Apr 15, 2024 at 11:44:50AM +0200, Paolo Bonzini wrote: > > Queued, thanks. > > > > Paolo > > I actually had it queued too - it's not 9.0 material though. > If you queue it don't forget to tweak the commit log manually. oh and then you can add my Reviewed-by: Michael S. Tsirkin > -- > MST
Re: [PATCH v2] hw/i386/acpi: Set PCAT_COMPAT bit only when pic is not disabled
On Mon, Apr 15, 2024 at 11:44:50AM +0200, Paolo Bonzini wrote: > Queued, thanks. > > Paolo I actually had it queued too - it's not 9.0 material though. If you queue it don't forget to tweak the commit log manually. -- MST
[PATCH v8] virtio-pci: fix use of a released vector
From: Cindy Lu
During the booting process of the non-standard image, the behavior of the
called function in qemu is as follows:
1. vhost_net_stop() was triggered by guest image. This will call the function
virtio_pci_set_guest_notifiers() with assgin= false,
virtio_pci_set_guest_notifiers(） will release the irqfd for vector 0
2. virtio_reset() was triggered, this will set configure vector to
VIRTIO_NO_VECTOR
3.vhost_net_start() was called (at this time, the configure vector is
still VIRTIO_NO_VECTOR) and then call virtio_pci_set_guest_notifiers() with
assgin=true, so the irqfd for vector 0 is still not "init" during this process
4. The system continues to boot and sets the vector back to 0. After that
msix_fire_vector_notifier() was triggered to unmask the vector 0 and meet the
crash
To fix the issue, we need to support changing the vector after
VIRTIO_CONFIG_S_DRIVER_OK is set.
(gdb) bt
0 __pthread_kill_implementation (threadid=,
signo=signo@entry=6, no_tid=no_tid@entry=0)
at pthread_kill.c:44
1 0x7fc87148ec53 in __pthread_kill_internal (signo=6, threadid=) at pthread_kill.c:78
2 0x7fc87143e956 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
3 0x7fc8714287f4 in __GI_abort () at abort.c:79
4 0x7fc87142871b in __assert_fail_base
(fmt=0x7fc8715bbde0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=0x5606413efd53 "ret == 0", file=0x5606413ef87d
"../accel/kvm/kvm-all.c", line=1837, function=) at assert.c:92
5 0x7fc871437536 in __GI___assert_fail
(assertion=0x5606413efd53 "ret == 0", file=0x5606413ef87d
"../accel/kvm/kvm-all.c", line=1837, function=0x5606413f06f0
<__PRETTY_FUNCTION__.19> "kvm_irqchip_commit_routes") at assert.c:101
6 0x560640f884b5 in kvm_irqchip_commit_routes (s=0x560642cae1f0) at
../accel/kvm/kvm-all.c:1837
7 0x560640c98f8e in virtio_pci_one_vector_unmask
(proxy=0x560643c65f00, queue_no=4294967295, vector=0, msg=...,
n=0x560643c6e4c8)
at ../hw/virtio/virtio-pci.c:1005
8 0x560640c99201 in virtio_pci_vector_unmask (dev=0x560643c65f00,
vector=0, msg=...)
at ../hw/virtio/virtio-pci.c:1070
9 0x560640bc402e in msix_fire_vector_notifier (dev=0x560643c65f00,
vector=0, is_masked=false)
at ../hw/pci/msix.c:120
10 0x560640bc40f1 in msix_handle_mask_update (dev=0x560643c65f00, vector=0,
was_masked=true)
at ../hw/pci/msix.c:140
11 0x560640bc4503 in msix_table_mmio_write (opaque=0x560643c65f00, addr=12,
val=0, size=4)
at ../hw/pci/msix.c:231
12 0x560640f26d83 in memory_region_write_accessor
(mr=0x560643c66540, addr=12, value=0x7fc86b7bc628, size=4, shift=0,
mask=4294967295, attrs=...)
at ../system/memory.c:497
13 0x560640f270a6 in access_with_adjusted_size
(addr=12, value=0x7fc86b7bc628, size=4, access_size_min=1,
access_size_max=4, access_fn=0x560640f26c8d ,
mr=0x560643c66540, attrs=...) at ../system/memory.c:573
14 0x560640f2a2b5 in memory_region_dispatch_write (mr=0x560643c66540,
addr=12, data=0, op=MO_32, attrs=...)
at ../system/memory.c:1521
15 0x560640f37bac in flatview_write_continue
(fv=0x7fc65805e0b0, addr=4273803276, attrs=..., ptr=0x7fc871e9c028, len=4,
addr1=12, l=4, mr=0x560643c66540)
at ../system/physmem.c:2714
16 0x560640f37d0f in flatview_write
(fv=0x7fc65805e0b0, addr=4273803276, attrs=..., buf=0x7fc871e9c028, len=4)
at ../system/physmem.c:2756
17 0x560640f380bf in address_space_write
(as=0x560642161ae0 , addr=4273803276, attrs=...,
buf=0x7fc871e9c028, len=4)
at ../system/physmem.c:2863
18 0x560640f3812c in address_space_rw
(as=0x560642161ae0 , addr=4273803276, attrs=...,
buf=0x7fc871e9c028, len=4, is_write=true) at ../system/physmem.c:2873
--Type for more, q to quit, c to continue without paging--
19 0x560640f8aa55 in kvm_cpu_exec (cpu=0x560642f205e0) at
../accel/kvm/kvm-all.c:2915
20 0x560640f8d731 in kvm_vcpu_thread_fn (arg=0x560642f205e0) at
../accel/kvm/kvm-accel-ops.c:51
21 0x5606411949f4 in qemu_thread_start (args=0x560642f292b0) at
../util/qemu-thread-posix.c:541
22 0x7fc87148cdcd in start_thread (arg=) at
pthread_create.c:442
23 0x7fc871512630 in clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb)
MST: coding style and typo fixups
Fixes: f9a09ca3ea ("vhost: add support for configure interrupt")
Cc: qemu-sta...@nongnu.org
Signed-off-by: Cindy Lu
Message-Id: <20240412062750.475180-1-l...@redhat.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
hw/virtio/virtio-pci.c | 37 +++--
1 file changed, 35 insertions(+), 2 deletions(-)
v7->v8:
more cleanups, suggested by Philip
still untested, i just got involved to help address coding style
issues
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index cb6940fc0e..cb159fd078 100
Re: [PATCH v7] virtio-pci: Fix the crash that the vector was used after released.
On Mon, Apr 15, 2024 at 11:23:46AM +0200, Philippe Mathieu-Daudé wrote:
> On 15/4/24 11:19, Michael S. Tsirkin wrote:
> > From: Cindy Lu
> >
> > During the booting process of the non-standard image, the behavior of the
> > called function in qemu is as follows:
> >
> > 1. vhost_net_stop() was triggered by guest image. This will call the
> > function
> > virtio_pci_set_guest_notifiers() with assgin= false,
> > virtio_pci_set_guest_notifiers(） will release the irqfd for vector 0
> >
> > 2. virtio_reset() was triggered, this will set configure vector to
> > VIRTIO_NO_VECTOR
> >
> > 3.vhost_net_start() was called (at this time, the configure vector is
> > still VIRTIO_NO_VECTOR) and then call virtio_pci_set_guest_notifiers() with
> > assgin=true, so the irqfd for vector 0 is still not "init" during this
> > process
> >
> > 4. The system continues to boot and sets the vector back to 0. After that
> > msix_fire_vector_notifier() was triggered to unmask the vector 0 and meet
> > the crash
> >
> > To fix the issue, we need to support changing the vector after
> > VIRTIO_CONFIG_S_DRIVER_OK is set.
>
>
> > MST: coding style and typo fixups
> >
> > Fixes: f9a09ca3ea ("vhost: add support for configure interrupt")
> > Cc: qemu-sta...@nongnu.org
> > Signed-off-by: Cindy Lu
> > Message-Id: <20240412062750.475180-1-l...@redhat.com>
> > Reviewed-by: Michael S. Tsirkin
> > Signed-off-by: Michael S. Tsirkin
> > Signed-off-by: Michael S. Tsirkin
> > ---
> >
> > To expedite fixed lots of style issues myself.
> > Completely untested - guys can you pls test and ack?
> >
> >
> > hw/virtio/virtio-pci.c | 41 +++--
> > 1 file changed, 39 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> > index cb6940fc0e..e9edd57339 100644
> > --- a/hw/virtio/virtio-pci.c
> > +++ b/hw/virtio/virtio-pci.c
> > @@ -1424,6 +1424,34 @@ static int virtio_pci_add_mem_cap(VirtIOPCIProxy
> > *proxy,
> > return offset;
> > }
> > +static void virtio_pci_set_and_change_vector(VirtIODevice *vdev,
> > + VirtIOPCIProxy *proxy,
> > + int queue_no, uint16_t
> > old_vector,
> > + uint16_t new_vector)
> > +{
>
> Alternatively:
>
>if (new_vector == old_vector) {
>return;
>}
True. And in fact callers do not need check this.
Let me do v8.
> > +bool kvm_irqfd = (vdev->status & VIRTIO_CONFIG_S_DRIVER_OK) &&
> > +msix_enabled(>pci_dev) && kvm_msi_via_irqfd_enabled();
> > +
> > +/*
> > + * If the device uses irqfd and the vector changes after DRIVER_OK is
> > + * set, we need to release the old vector and set up the new one.
> > + * Otherwise just need to set the new vector on the device.
> > + */
> > +if (kvm_irqfd && old_vector != VIRTIO_NO_VECTOR) {
> > +kvm_virtio_pci_vector_release_one(proxy, queue_no);
> > +}
> > +/* Set the new vector on the device. */
> > +if (queue_no == VIRTIO_CONFIG_IRQ_IDX) {
> > +vdev->config_vector = new_vector;
> > +} else {
> > +virtio_queue_set_vector(vdev, queue_no, new_vector);
> > +}
> > +/* If the new vector changed need to set it up. */
> > +if (kvm_irqfd && new_vector != VIRTIO_NO_VECTOR) {
> > +kvm_virtio_pci_vector_use_one(proxy, queue_no);
> > +}
> > +}
> > +
> > int virtio_pci_add_shm_cap(VirtIOPCIProxy *proxy,
> > uint8_t bar, uint64_t offset, uint64_t length,
> > uint8_t id)
> > @@ -1570,7 +1598,12 @@ static void virtio_pci_common_write(void *opaque,
> > hwaddr addr,
> > } else {
> > val = VIRTIO_NO_VECTOR;
> > }
> > -vdev->config_vector = val;
> > +vector = vdev->config_vector;
> > +/* Check if we need to change the vector. */
> > +if (val != vector) {
> > +virtio_pci_set_and_change_vector(vdev, proxy,
> > VIRTIO_CONFIG_IRQ_IDX,
> > + vector, val);
> > +}
> > break;
Re: [PATCH v6] virtio-pci: Fix the crash that the vector was used after released.
On Mon, Apr 15, 2024 at 05:11:05PM +0800, Cindy Lu wrote: > On Mon, Apr 15, 2024 at 4:32 PM Michael S. Tsirkin wrote: > > > > On Fri, Apr 12, 2024 at 02:26:55PM +0800, Cindy Lu wrote: > > > During the booting process of the non-standard image, the behavior of the > > > called function in qemu is as follows: > > > > > > 1. vhost_net_stop() was triggered by guest image. This will call the > > > function > > > virtio_pci_set_guest_notifiers() with assgin= false, > > > virtio_pci_set_guest_notifiers(） will release the irqfd for vector 0 > > > > > > 2. virtio_reset() was triggered, this will set configure vector to > > > VIRTIO_NO_VECTOR > > > > > > 3.vhost_net_start() was called (at this time, the configure vector is > > > still VIRTIO_NO_VECTOR) and then call virtio_pci_set_guest_notifiers() > > > with > > > assgin=true, so the irqfd for vector 0 is still not "init" during this > > > process > > > > > > 4. The system continues to boot and sets the vector back to 0. After that > > > msix_fire_vector_notifier() was triggered to unmask the vector 0 and > > > meet the crash > > > > > > To fix the issue, we need to support changing the vector after > > > VIRTIO_CONFIG_S_DRIVER_OK is set. > > > > > > (gdb) bt > > > 0 __pthread_kill_implementation (threadid=, > > > signo=signo@entry=6, no_tid=no_tid@entry=0) > > > at pthread_kill.c:44 > > > 1 0x7fc87148ec53 in __pthread_kill_internal (signo=6, > > > threadid=) at pthread_kill.c:78 > > > 2 0x7fc87143e956 in __GI_raise (sig=sig@entry=6) at > > > ../sysdeps/posix/raise.c:26 > > > 3 0x7fc8714287f4 in __GI_abort () at abort.c:79 > > > 4 0x7fc87142871b in __assert_fail_base > > > (fmt=0x7fc8715bbde0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", > > > assertion=0x5606413efd53 "ret == 0", file=0x5606413ef87d > > > "../accel/kvm/kvm-all.c", line=1837, function=) at > > > assert.c:92 > > > 5 0x7fc871437536 in __GI___assert_fail > > > (assertion=0x5606413efd53 "ret == 0", file=0x5606413ef87d > > > "../accel/kvm/kvm-all.c", line=1837, function=0x5606413f06f0 > > > <__PRETTY_FUNCTION__.19> "kvm_irqchip_commit_routes") at assert.c:101 > > > 6 0x560640f884b5 in kvm_irqchip_commit_routes (s=0x560642cae1f0) at > > > ../accel/kvm/kvm-all.c:1837 > > > 7 0x560640c98f8e in virtio_pci_one_vector_unmask > > > (proxy=0x560643c65f00, queue_no=4294967295, vector=0, msg=..., > > > n=0x560643c6e4c8) > > > at ../hw/virtio/virtio-pci.c:1005 > > > 8 0x560640c99201 in virtio_pci_vector_unmask (dev=0x560643c65f00, > > > vector=0, msg=...) > > > at ../hw/virtio/virtio-pci.c:1070 > > > 9 0x560640bc402e in msix_fire_vector_notifier (dev=0x560643c65f00, > > > vector=0, is_masked=false) > > > at ../hw/pci/msix.c:120 > > > 10 0x560640bc40f1 in msix_handle_mask_update (dev=0x560643c65f00, > > > vector=0, was_masked=true) > > > at ../hw/pci/msix.c:140 > > > 11 0x560640bc4503 in msix_table_mmio_write (opaque=0x560643c65f00, > > > addr=12, val=0, size=4) > > > at ../hw/pci/msix.c:231 > > > 12 0x560640f26d83 in memory_region_write_accessor > > > (mr=0x560643c66540, addr=12, value=0x7fc86b7bc628, size=4, shift=0, > > > mask=4294967295, attrs=...) > > > at ../system/memory.c:497 > > > 13 0x560640f270a6 in access_with_adjusted_size > > > > > > (addr=12, value=0x7fc86b7bc628, size=4, access_size_min=1, > > > access_size_max=4, access_fn=0x560640f26c8d > > > , mr=0x560643c66540, attrs=...) at > > > ../system/memory.c:573 > > > 14 0x560640f2a2b5 in memory_region_dispatch_write (mr=0x560643c66540, > > > addr=12, data=0, op=MO_32, attrs=...) > > > at ../system/memory.c:1521 > > > 15 0x560640f37bac in flatview_write_continue > > > (fv=0x7fc65805e0b0, addr=4273803276, attrs=..., ptr=0x7fc871e9c028, > > > len=4, addr1=12, l=4, mr=0x560643c66540) > > > at ../system/physmem.c:2714 > > > 16 0x560640f37d0f in flatview_write > > > (fv=0x7fc65805e0b0, addr=4273803276, attrs=..., buf=0x7fc871e9c028, > > > len=4) at ../system/physmem.c:2756 > > > 17 0x560640f380bf in address_space_write > > > (as=0x560642161ae0 , addr=4273803276, >
[PATCH v7] virtio-pci: Fix the crash that the vector was used after released.
From: Cindy Lu
During the booting process of the non-standard image, the behavior of the
called function in qemu is as follows:
1. vhost_net_stop() was triggered by guest image. This will call the function
virtio_pci_set_guest_notifiers() with assgin= false,
virtio_pci_set_guest_notifiers(） will release the irqfd for vector 0
2. virtio_reset() was triggered, this will set configure vector to
VIRTIO_NO_VECTOR
3.vhost_net_start() was called (at this time, the configure vector is
still VIRTIO_NO_VECTOR) and then call virtio_pci_set_guest_notifiers() with
assgin=true, so the irqfd for vector 0 is still not "init" during this process
4. The system continues to boot and sets the vector back to 0. After that
msix_fire_vector_notifier() was triggered to unmask the vector 0 and meet the
crash
To fix the issue, we need to support changing the vector after
VIRTIO_CONFIG_S_DRIVER_OK is set.
(gdb) bt
0 __pthread_kill_implementation (threadid=,
signo=signo@entry=6, no_tid=no_tid@entry=0)
at pthread_kill.c:44
1 0x7fc87148ec53 in __pthread_kill_internal (signo=6, threadid=) at pthread_kill.c:78
2 0x7fc87143e956 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
3 0x7fc8714287f4 in __GI_abort () at abort.c:79
4 0x7fc87142871b in __assert_fail_base
(fmt=0x7fc8715bbde0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=0x5606413efd53 "ret == 0", file=0x5606413ef87d
"../accel/kvm/kvm-all.c", line=1837, function=) at assert.c:92
5 0x7fc871437536 in __GI___assert_fail
(assertion=0x5606413efd53 "ret == 0", file=0x5606413ef87d
"../accel/kvm/kvm-all.c", line=1837, function=0x5606413f06f0
<__PRETTY_FUNCTION__.19> "kvm_irqchip_commit_routes") at assert.c:101
6 0x560640f884b5 in kvm_irqchip_commit_routes (s=0x560642cae1f0) at
../accel/kvm/kvm-all.c:1837
7 0x560640c98f8e in virtio_pci_one_vector_unmask
(proxy=0x560643c65f00, queue_no=4294967295, vector=0, msg=...,
n=0x560643c6e4c8)
at ../hw/virtio/virtio-pci.c:1005
8 0x560640c99201 in virtio_pci_vector_unmask (dev=0x560643c65f00,
vector=0, msg=...)
at ../hw/virtio/virtio-pci.c:1070
9 0x560640bc402e in msix_fire_vector_notifier (dev=0x560643c65f00,
vector=0, is_masked=false)
at ../hw/pci/msix.c:120
10 0x560640bc40f1 in msix_handle_mask_update (dev=0x560643c65f00, vector=0,
was_masked=true)
at ../hw/pci/msix.c:140
11 0x560640bc4503 in msix_table_mmio_write (opaque=0x560643c65f00, addr=12,
val=0, size=4)
at ../hw/pci/msix.c:231
12 0x560640f26d83 in memory_region_write_accessor
(mr=0x560643c66540, addr=12, value=0x7fc86b7bc628, size=4, shift=0,
mask=4294967295, attrs=...)
at ../system/memory.c:497
13 0x560640f270a6 in access_with_adjusted_size
(addr=12, value=0x7fc86b7bc628, size=4, access_size_min=1,
access_size_max=4, access_fn=0x560640f26c8d ,
mr=0x560643c66540, attrs=...) at ../system/memory.c:573
14 0x560640f2a2b5 in memory_region_dispatch_write (mr=0x560643c66540,
addr=12, data=0, op=MO_32, attrs=...)
at ../system/memory.c:1521
15 0x560640f37bac in flatview_write_continue
(fv=0x7fc65805e0b0, addr=4273803276, attrs=..., ptr=0x7fc871e9c028, len=4,
addr1=12, l=4, mr=0x560643c66540)
at ../system/physmem.c:2714
16 0x560640f37d0f in flatview_write
(fv=0x7fc65805e0b0, addr=4273803276, attrs=..., buf=0x7fc871e9c028, len=4)
at ../system/physmem.c:2756
17 0x560640f380bf in address_space_write
(as=0x560642161ae0 , addr=4273803276, attrs=...,
buf=0x7fc871e9c028, len=4)
at ../system/physmem.c:2863
18 0x560640f3812c in address_space_rw
(as=0x560642161ae0 , addr=4273803276, attrs=...,
buf=0x7fc871e9c028, len=4, is_write=true) at ../system/physmem.c:2873
--Type for more, q to quit, c to continue without paging--
19 0x560640f8aa55 in kvm_cpu_exec (cpu=0x560642f205e0) at
../accel/kvm/kvm-all.c:2915
20 0x560640f8d731 in kvm_vcpu_thread_fn (arg=0x560642f205e0) at
../accel/kvm/kvm-accel-ops.c:51
21 0x5606411949f4 in qemu_thread_start (args=0x560642f292b0) at
../util/qemu-thread-posix.c:541
22 0x7fc87148cdcd in start_thread (arg=) at
pthread_create.c:442
23 0x7fc871512630 in clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb)
MST: coding style and typo fixups
Fixes: f9a09ca3ea ("vhost: add support for configure interrupt")
Cc: qemu-sta...@nongnu.org
Signed-off-by: Cindy Lu
Message-Id: <20240412062750.475180-1-l...@redhat.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
To expedite fixed lots of style issues myself.
Completely untested - guys can you pls test and ack?
hw/virtio/virtio-pci.c | 41 +++--
1 file changed, 39 insertions(+), 2 deletions(-)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index cb6940fc0e..e9edd57339 100644
Re: [PATCH v6] virtio-pci: Fix the crash that the vector was used after released.
On Fri, Apr 12, 2024 at 02:26:55PM +0800, Cindy Lu wrote:
> During the booting process of the non-standard image, the behavior of the
> called function in qemu is as follows:
>
> 1. vhost_net_stop() was triggered by guest image. This will call the function
> virtio_pci_set_guest_notifiers() with assgin= false,
> virtio_pci_set_guest_notifiers(） will release the irqfd for vector 0
>
> 2. virtio_reset() was triggered, this will set configure vector to
> VIRTIO_NO_VECTOR
>
> 3.vhost_net_start() was called (at this time, the configure vector is
> still VIRTIO_NO_VECTOR) and then call virtio_pci_set_guest_notifiers() with
> assgin=true, so the irqfd for vector 0 is still not "init" during this process
>
> 4. The system continues to boot and sets the vector back to 0. After that
> msix_fire_vector_notifier() was triggered to unmask the vector 0 and meet
> the crash
>
> To fix the issue, we need to support changing the vector after
> VIRTIO_CONFIG_S_DRIVER_OK is set.
>
> (gdb) bt
> 0 __pthread_kill_implementation (threadid=,
> signo=signo@entry=6, no_tid=no_tid@entry=0)
> at pthread_kill.c:44
> 1 0x7fc87148ec53 in __pthread_kill_internal (signo=6,
> threadid=) at pthread_kill.c:78
> 2 0x7fc87143e956 in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/posix/raise.c:26
> 3 0x7fc8714287f4 in __GI_abort () at abort.c:79
> 4 0x7fc87142871b in __assert_fail_base
> (fmt=0x7fc8715bbde0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
> assertion=0x5606413efd53 "ret == 0", file=0x5606413ef87d
> "../accel/kvm/kvm-all.c", line=1837, function=) at assert.c:92
> 5 0x7fc871437536 in __GI___assert_fail
> (assertion=0x5606413efd53 "ret == 0", file=0x5606413ef87d
> "../accel/kvm/kvm-all.c", line=1837, function=0x5606413f06f0
> <__PRETTY_FUNCTION__.19> "kvm_irqchip_commit_routes") at assert.c:101
> 6 0x560640f884b5 in kvm_irqchip_commit_routes (s=0x560642cae1f0) at
> ../accel/kvm/kvm-all.c:1837
> 7 0x560640c98f8e in virtio_pci_one_vector_unmask
> (proxy=0x560643c65f00, queue_no=4294967295, vector=0, msg=...,
> n=0x560643c6e4c8)
> at ../hw/virtio/virtio-pci.c:1005
> 8 0x560640c99201 in virtio_pci_vector_unmask (dev=0x560643c65f00,
> vector=0, msg=...)
> at ../hw/virtio/virtio-pci.c:1070
> 9 0x560640bc402e in msix_fire_vector_notifier (dev=0x560643c65f00,
> vector=0, is_masked=false)
> at ../hw/pci/msix.c:120
> 10 0x560640bc40f1 in msix_handle_mask_update (dev=0x560643c65f00,
> vector=0, was_masked=true)
> at ../hw/pci/msix.c:140
> 11 0x560640bc4503 in msix_table_mmio_write (opaque=0x560643c65f00,
> addr=12, val=0, size=4)
> at ../hw/pci/msix.c:231
> 12 0x560640f26d83 in memory_region_write_accessor
> (mr=0x560643c66540, addr=12, value=0x7fc86b7bc628, size=4, shift=0,
> mask=4294967295, attrs=...)
> at ../system/memory.c:497
> 13 0x560640f270a6 in access_with_adjusted_size
>
> (addr=12, value=0x7fc86b7bc628, size=4, access_size_min=1,
> access_size_max=4, access_fn=0x560640f26c8d ,
> mr=0x560643c66540, attrs=...) at ../system/memory.c:573
> 14 0x560640f2a2b5 in memory_region_dispatch_write (mr=0x560643c66540,
> addr=12, data=0, op=MO_32, attrs=...)
> at ../system/memory.c:1521
> 15 0x560640f37bac in flatview_write_continue
> (fv=0x7fc65805e0b0, addr=4273803276, attrs=..., ptr=0x7fc871e9c028,
> len=4, addr1=12, l=4, mr=0x560643c66540)
> at ../system/physmem.c:2714
> 16 0x560640f37d0f in flatview_write
> (fv=0x7fc65805e0b0, addr=4273803276, attrs=..., buf=0x7fc871e9c028,
> len=4) at ../system/physmem.c:2756
> 17 0x560640f380bf in address_space_write
> (as=0x560642161ae0 , addr=4273803276, attrs=...,
> buf=0x7fc871e9c028, len=4)
> at ../system/physmem.c:2863
> 18 0x560640f3812c in address_space_rw
> (as=0x560642161ae0 , addr=4273803276, attrs=...,
> buf=0x7fc871e9c028, len=4, is_write=true) at ../system/physmem.c:2873
> --Type for more, q to quit, c to continue without paging--
> 19 0x560640f8aa55 in kvm_cpu_exec (cpu=0x560642f205e0) at
> ../accel/kvm/kvm-all.c:2915
> 20 0x560640f8d731 in kvm_vcpu_thread_fn (arg=0x560642f205e0) at
> ../accel/kvm/kvm-accel-ops.c:51
> 21 0x5606411949f4 in qemu_thread_start (args=0x560642f292b0) at
> ../util/qemu-thread-posix.c:541
> 22 0x00007fc87148cdcd in start_thread (arg=) at
> pthread_create.c:442
> 23 0x7fc871512630 in clone3 () at
> ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
> (gdb)
>
> Fixes: f9a09ca3ea ("vhost: add support for configure interrupt")
> Cc: qemu-sta...@nongnu.org
>
empty line not needed here
> Si
Re: Discrepancy between mmap call on DPDK/libvduse and rust vm-memory crate
On Fri, Apr 12, 2024 at 12:15:40PM +0200, Eugenio Perez Martin wrote:
> Hi!
>
> I'm building a bridge to expose vhost-user devices through VDUSE. The
> code is still immature but I'm able to forward packets using
> dpdk-l2fwd through VDUSE to VM. I'm now developing exposing virtiofsd,
> but I've hit an error I'd like to discuss.
>
> VDUSE devices can get all the memory regions the driver is using by
> VDUSE_IOTLB_GET_FD ioctl. It returns a file descriptor with a memory
> region associated that can be mapped with mmap, and an information
> entry about the map it contains:
> * Start and end addresses from the driver POV
> * Offset within the mmaped region of these start and end
> * Device permissions over that region.
>
> [start=0xc3000][last=0xe7fff][offset=0xc3000][perm=1]
>
> Now when I try to map it, it is impossible for the userspace device to
> call mmap with any offset different than 0.
How exactly did you allocate memory? hugetlbfs?
> So the "straightforward"
> mmap with size = entry.last-entry.start and offset = entry.offset does
> not work. I don't know if this is a limitation of Linux or VDUSE.
>
> Checking QEMU's
> subprojects/libvduse/libvduse.c:vduse_iova_add_region() I see it
> handles the offset by adding it up to the size, instead of using it
> directly as a parameter in the mmap:
>
> void *mmap_addr = mmap(0, size + offset, prot, MAP_SHARED, fd, 0);
CC Xie Yongji who wrote this code, too.
> I can replicate it on the bridge for sure.
>
> Now I send the VhostUserMemoryRegion to the vhost-user application.
> The struct has these members:
> struct VhostUserMemoryRegion {
> uint64_t guest_phys_addr;
> uint64_t memory_size;
> uint64_t userspace_addr;
> uint64_t mmap_offset;
> };
>
> So I can send the offset to the vhost-user device. I can check that
> dpdk-l2fwd uses the same trick of adding offset to the size of the
> mapping region [1], at
> lib/vhost/vhost_user.c:vhost_user_mmap_region():
>
> mmap_size = region->size + mmap_offset;
> mmap_addr = mmap(NULL, mmap_size, PROT_READ | PROT_WRITE,
> MAP_SHARED | populate, region->fd, 0);
>
> So mmap is called with offset == 0 and everybody is happy.
>
> Now I'm moving to virtiofsd, and vm-memory crate in particular. And it
> performs the mmap without the size += offset trick, at
> MmapRegionBuilder:build() [2].
>
> I can try to apply the offset + size trick in my bridge but I don't
> think it is the right solution. At first glance, the right solution is
> to mmap with the offset as vm-memory crate do. But having libvduse and
> DPDK apply the same trick sounds to me like it is a known limitation /
> workaround I don't know about. What is the history of this? Can VDUSE
> problem (if any) be solved? Am I missing something?
>
> Thanks!
>
> [1]
> https://github.com/DPDK/dpdk/blob/e2e546ab5bf5e024986ccb5310ab43982f3bb40c/lib/vhost/vhost_user.c#L1305
> [2] https://github.com/rust-vmm/vm-memory/blob/main/src/mmap_unix.rs#L128
Re: [PATCH v4] virtio-pci: Fix the crash that the vector was used after released.
On Thu, Apr 11, 2024 at 12:11:30PM +0800, Cindy Lu wrote:
> During the booting process of the non-standard image, the behavior of the
> called function in qemu is as follows:
>
> 1. vhost_net_stop() was triggered by guest image. This will call the function
> virtio_pci_set_guest_notifiers() with assgin= false,
> virtio_pci_set_guest_notifiers(） will release the irqfd for vector 0
>
> 2. virtio_reset() was triggered, this will set configure vector to
> VIRTIO_NO_VECTOR
>
> 3.vhost_net_start() was called (at this time, the configure vector is
> still VIRTIO_NO_VECTOR) and then call virtio_pci_set_guest_notifiers() with
> assgin=true, so the irqfd for vector 0 is still not "init" during this process
>
> 4. The system continues to boot and sets the vector back to 0. After that
> msix_fire_vector_notifier() was triggered to unmask the vector 0 and meet
> the crash
>
> To fix the issue, we need to support changing the vector after
> VIRTIO_CONFIG_S_DRIVER_OK is set.
>
> (gdb) bt
> 0 __pthread_kill_implementation (threadid=,
> signo=signo@entry=6, no_tid=no_tid@entry=0)
> at pthread_kill.c:44
> 1 0x7fc87148ec53 in __pthread_kill_internal (signo=6,
> threadid=) at pthread_kill.c:78
> 2 0x7fc87143e956 in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/posix/raise.c:26
> 3 0x7fc8714287f4 in __GI_abort () at abort.c:79
> 4 0x7fc87142871b in __assert_fail_base
> (fmt=0x7fc8715bbde0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
> assertion=0x5606413efd53 "ret == 0", file=0x5606413ef87d
> "../accel/kvm/kvm-all.c", line=1837, function=) at assert.c:92
> 5 0x7fc871437536 in __GI___assert_fail
> (assertion=0x5606413efd53 "ret == 0", file=0x5606413ef87d
> "../accel/kvm/kvm-all.c", line=1837, function=0x5606413f06f0
> <__PRETTY_FUNCTION__.19> "kvm_irqchip_commit_routes") at assert.c:101
> 6 0x560640f884b5 in kvm_irqchip_commit_routes (s=0x560642cae1f0) at
> ../accel/kvm/kvm-all.c:1837
> 7 0x560640c98f8e in virtio_pci_one_vector_unmask
> (proxy=0x560643c65f00, queue_no=4294967295, vector=0, msg=...,
> n=0x560643c6e4c8)
> at ../hw/virtio/virtio-pci.c:1005
> 8 0x560640c99201 in virtio_pci_vector_unmask (dev=0x560643c65f00,
> vector=0, msg=...)
> at ../hw/virtio/virtio-pci.c:1070
> 9 0x560640bc402e in msix_fire_vector_notifier (dev=0x560643c65f00,
> vector=0, is_masked=false)
> at ../hw/pci/msix.c:120
> 10 0x560640bc40f1 in msix_handle_mask_update (dev=0x560643c65f00,
> vector=0, was_masked=true)
> at ../hw/pci/msix.c:140
> 11 0x560640bc4503 in msix_table_mmio_write (opaque=0x560643c65f00,
> addr=12, val=0, size=4)
> at ../hw/pci/msix.c:231
> 12 0x560640f26d83 in memory_region_write_accessor
> (mr=0x560643c66540, addr=12, value=0x7fc86b7bc628, size=4, shift=0,
> mask=4294967295, attrs=...)
> at ../system/memory.c:497
> 13 0x560640f270a6 in access_with_adjusted_size
>
> (addr=12, value=0x7fc86b7bc628, size=4, access_size_min=1,
> access_size_max=4, access_fn=0x560640f26c8d ,
> mr=0x560643c66540, attrs=...) at ../system/memory.c:573
> 14 0x560640f2a2b5 in memory_region_dispatch_write (mr=0x560643c66540,
> addr=12, data=0, op=MO_32, attrs=...)
> at ../system/memory.c:1521
> 15 0x560640f37bac in flatview_write_continue
> (fv=0x7fc65805e0b0, addr=4273803276, attrs=..., ptr=0x7fc871e9c028,
> len=4, addr1=12, l=4, mr=0x560643c66540)
> at ../system/physmem.c:2714
> 16 0x560640f37d0f in flatview_write
> (fv=0x7fc65805e0b0, addr=4273803276, attrs=..., buf=0x7fc871e9c028,
> len=4) at ../system/physmem.c:2756
> 17 0x560640f380bf in address_space_write
> (as=0x560642161ae0 , addr=4273803276, attrs=...,
> buf=0x7fc871e9c028, len=4)
> at ../system/physmem.c:2863
> 18 0x560640f3812c in address_space_rw
> (as=0x560642161ae0 , addr=4273803276, attrs=...,
> buf=0x7fc871e9c028, len=4, is_write=true) at ../system/physmem.c:2873
> --Type for more, q to quit, c to continue without paging--
> 19 0x560640f8aa55 in kvm_cpu_exec (cpu=0x560642f205e0) at
> ../accel/kvm/kvm-all.c:2915
> 20 0x560640f8d731 in kvm_vcpu_thread_fn (arg=0x560642f205e0) at
> ../accel/kvm/kvm-accel-ops.c:51
> 21 0x5606411949f4 in qemu_thread_start (args=0x560642f292b0) at
> ../util/qemu-thread-posix.c:541
> 22 0x7fc87148cdcd in start_thread (arg=) at
> pthread_create.c:442
> 23 0x7fc871512630 in clone3 () at
> ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
> (gdb)
> Signed-off-by: Cindy Lu
Empty line is needed before the signature :)
> ---
> hw/virtio/virtio-pci.c | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> index 1a7039fb0c..f124a9e20b 100644
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
> @@ -1570,7 +1570,22 @@ static void virtio_pci_common_write(void *opaque,
> hwaddr addr,
> } else {
> val = VIRTIO_NO_VECTOR;
> }
> +
Re: [PATCH v3] virtio-pci: Fix the crash that the vector was used after released.
On Thu, Apr 11, 2024 at 12:12:00AM +0800, Cindy Lu wrote:
> During the booting process of the non-standard image, the behavior of the
> called function in qemu is as follows:
>
> 1. vhost_net_stop() was triggered by guest image. This will call the function
> virtio_pci_set_guest_notifiers() with assgin= false,
> virtio_pci_set_guest_notifiers(） will release the irqfd for vector 0
>
> 2. virtio_reset() was triggered, this will set configure vector to
> VIRTIO_NO_VECTOR
>
> 3.vhost_net_start() was called (at this time, the configure vector is
> still VIRTIO_NO_VECTOR) and then call virtio_pci_set_guest_notifiers() with
> assgin=true, so the irqfd for vector 0 is still not "init" during this process
>
> 4. The system continues to boot and sets the vector back to 0. After that
> msix_fire_vector_notifier() was triggered to unmask the vector 0 and meet
> the crash
>
> To fix the issue, we need to support changing the vector after
> VIRTIO_CONFIG_S_DRIVER_OK is set.
>
> (gdb) bt
> 0 __pthread_kill_implementation (threadid=,
> signo=signo@entry=6, no_tid=no_tid@entry=0)
> at pthread_kill.c:44
> 1 0x7fc87148ec53 in __pthread_kill_internal (signo=6,
> threadid=) at pthread_kill.c:78
> 2 0x7fc87143e956 in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/posix/raise.c:26
> 3 0x7fc8714287f4 in __GI_abort () at abort.c:79
> 4 0x7fc87142871b in __assert_fail_base
> (fmt=0x7fc8715bbde0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
> assertion=0x5606413efd53 "ret == 0", file=0x5606413ef87d
> "../accel/kvm/kvm-all.c", line=1837, function=) at assert.c:92
> 5 0x7fc871437536 in __GI___assert_fail
> (assertion=0x5606413efd53 "ret == 0", file=0x5606413ef87d
> "../accel/kvm/kvm-all.c", line=1837, function=0x5606413f06f0
> <__PRETTY_FUNCTION__.19> "kvm_irqchip_commit_routes") at assert.c:101
> 6 0x560640f884b5 in kvm_irqchip_commit_routes (s=0x560642cae1f0) at
> ../accel/kvm/kvm-all.c:1837
> 7 0x560640c98f8e in virtio_pci_one_vector_unmask
> (proxy=0x560643c65f00, queue_no=4294967295, vector=0, msg=...,
> n=0x560643c6e4c8)
> at ../hw/virtio/virtio-pci.c:1005
> 8 0x560640c99201 in virtio_pci_vector_unmask (dev=0x560643c65f00,
> vector=0, msg=...)
> at ../hw/virtio/virtio-pci.c:1070
> 9 0x560640bc402e in msix_fire_vector_notifier (dev=0x560643c65f00,
> vector=0, is_masked=false)
> at ../hw/pci/msix.c:120
> 10 0x560640bc40f1 in msix_handle_mask_update (dev=0x560643c65f00,
> vector=0, was_masked=true)
> at ../hw/pci/msix.c:140
> 11 0x560640bc4503 in msix_table_mmio_write (opaque=0x560643c65f00,
> addr=12, val=0, size=4)
> at ../hw/pci/msix.c:231
> 12 0x560640f26d83 in memory_region_write_accessor
> (mr=0x560643c66540, addr=12, value=0x7fc86b7bc628, size=4, shift=0,
> mask=4294967295, attrs=...)
> at ../system/memory.c:497
> 13 0x560640f270a6 in access_with_adjusted_size
>
> (addr=12, value=0x7fc86b7bc628, size=4, access_size_min=1,
> access_size_max=4, access_fn=0x560640f26c8d ,
> mr=0x560643c66540, attrs=...) at ../system/memory.c:573
> 14 0x560640f2a2b5 in memory_region_dispatch_write (mr=0x560643c66540,
> addr=12, data=0, op=MO_32, attrs=...)
> at ../system/memory.c:1521
> 15 0x560640f37bac in flatview_write_continue
> (fv=0x7fc65805e0b0, addr=4273803276, attrs=..., ptr=0x7fc871e9c028,
> len=4, addr1=12, l=4, mr=0x560643c66540)
> at ../system/physmem.c:2714
> 16 0x560640f37d0f in flatview_write
> (fv=0x7fc65805e0b0, addr=4273803276, attrs=..., buf=0x7fc871e9c028,
> len=4) at ../system/physmem.c:2756
> 17 0x560640f380bf in address_space_write
> (as=0x560642161ae0 , addr=4273803276, attrs=...,
> buf=0x7fc871e9c028, len=4)
> at ../system/physmem.c:2863
> 18 0x560640f3812c in address_space_rw
> (as=0x560642161ae0 , addr=4273803276, attrs=...,
> buf=0x7fc871e9c028, len=4, is_write=true) at ../system/physmem.c:2873
> --Type for more, q to quit, c to continue without paging--
> 19 0x560640f8aa55 in kvm_cpu_exec (cpu=0x560642f205e0) at
> ../accel/kvm/kvm-all.c:2915
> 20 0x560640f8d731 in kvm_vcpu_thread_fn (arg=0x560642f205e0) at
> ../accel/kvm/kvm-accel-ops.c:51
> 21 0x5606411949f4 in qemu_thread_start (args=0x560642f292b0) at
> ../util/qemu-thread-posix.c:541
> 22 0x7fc87148cdcd in start_thread (arg=) at
> pthread_create.c:442
> 23 0x7fc871512630 in clone3 () at
> ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
> (gdb)
> Signed-off-by: Cindy Lu
> ---
> hw/virtio/virtio-pci.c | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> index 1a7039fb0c..b3b1a4a66f 100644
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
> @@ -1570,7 +1570,22 @@ static void virtio_pci_common_write(void *opaque,
> hwaddr addr,
> } else {
> val = VIRTIO_NO_VECTOR;
> }
> +vector = vdev->config_vector;
>
Re: secure boot & direct kernel load (was: Re: [PATCH] x86/loader: only patch linux kernels)
On Wed, Apr 10, 2024 at 12:35:13PM +0200, Gerd Hoffmann wrote: > On Wed, Apr 10, 2024 at 03:26:29AM -0400, Michael S. Tsirkin wrote: > > On Wed, Apr 10, 2024 at 09:21:26AM +0200, Gerd Hoffmann wrote: > > > If the binary loaded via -kernel is *not* a linux kernel (in which > > > case protocol == 0), do not patch the linux kernel header fields. > > > > > > It's (a) pointless and (b) might break binaries by random patching > > > and (c) changes the binary hash which in turn breaks secure boot > > > verification. > > > > > > Background: OVMF happily loads and runs not only linux kernels but > > > any efi binary via direct kernel boot. > > > > > > Note: Breaking the secure boot verification is a problem for linux > > > kernels too, but fixed that is left for another day ... > > > > Um we kind of care about Linux ;) > > > > What's the plan? I suspect we should just add a command line flag > > to skip patching? And once we do that, it seems safer to just > > always rely on the flag? > > Well, there are more problems to solve here than just the patching. So > lets have a look at the bigger picture before discussion the details ... > > [ Cc'ing Daniel + Cole ] > > Current state of affairs is that OVMF supports two ways to boot a linux > kernel: > > (1) Just load it as EFI binary and boot via linux kernel EFI stub, > which is the modern way to load a linux kernel (which is why you > can boot not only linux kernels but any efi binary). > > (2) Use the old EFI handover protocol. Which is the RHEL-6 era way to > boot a linux kernel on EFI. > > For method (1) secure boot verification must pass. For (2) not. So if > you try to use direct kernel boot with secure boot enabled OVMF will > first try (1), which will fail, then go fallback to (2). > > The reason for the failure is not only the patching, but also the fact > that the linux kernel is typically verified by shim.efi (and the distro > keys compiled into the binary) instead of the firmware. > > Going though (2) is not ideal for multiple reasons, so we need some > strategy how we'll go handle direct kernel load with uefi and secure > boot in a way that (1) works. > > Options I see: > > (a) Stop using direct kernel boot, let virt-install & other tools > create vfat boot media with shim+kernel+initrd instead. > > (b) Enroll the distro signing keys in the efi variable store, so > booting the kernel without shim.efi works. > > (c) Add support for loading shim to qemu (and ovmf), for example > with a new '-shim' command line option which stores shim.efi > in some new fw_cfg file. > > (b) + (c) both require a fix for the patching issue. The options > I see here are: > > (A) Move the patching from qemu to the linuxboot option rom. > Strictly speaking it belongs there anyway. It doesn't look > that easy though, for qemu it is easier to gather all > information needed ... > > (B) Provide both patched and unpatched setup header, so the > guest can choose what it needs. > > (C) When implementing (c) above we can piggyback on the -shim > switch and skip patching in case it is present. > > (D) Add a flag to skip the patching. > > Comments? Other/better ideas? > > take care, > Gerd So if you didn't decide whether to do b or c then I guess D is easiest and covers both cases? -- MST
Re: [PATCH] x86/loader: only patch linux kernels
On Wed, Apr 10, 2024 at 09:21:26AM +0200, Gerd Hoffmann wrote:
> If the binary loaded via -kernel is *not* a linux kernel (in which
> case protocol == 0), do not patch the linux kernel header fields.
>
> It's (a) pointless and (b) might break binaries by random patching
> and (c) changes the binary hash which in turn breaks secure boot
> verification.
>
> Background: OVMF happily loads and runs not only linux kernels but
> any efi binary via direct kernel boot.
>
> Note: Breaking the secure boot verification is a problem for linux
> kernels too, but fixed that is left for another day ...
Um we kind of care about Linux ;)
What's the plan? I suspect we should just add a command line flag
to skip patching? And once we do that, it seems safer to just
always rely on the flag?
> Signed-off-by: Gerd Hoffmann
> ---
> hw/i386/x86.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/i386/x86.c b/hw/i386/x86.c
> index ffbda48917fd..765899eebe43 100644
> --- a/hw/i386/x86.c
> +++ b/hw/i386/x86.c
> @@ -1108,7 +1108,7 @@ void x86_load_linux(X86MachineState *x86ms,
> * kernel on the other side of the fw_cfg interface matches the hash of
> the
> * file the user passed in.
> */
> -if (!sev_enabled()) {
> +if (!sev_enabled() && protocol > 0) {
> memcpy(setup, header, MIN(sizeof(header), setup_size));
> }
>
> --
> 2.44.0
Re: [PATCH 1/1] virtio-net: fix bug 1451 aka "assert(!virtio_net_get_subqueue(nc)->async_tx.elem);"
On Tue, Apr 09, 2024 at 07:37:04PM +0300, Alexey Dobriyan wrote:
> On Tue, Apr 09, 2024 at 02:51:38AM -0400, Michael S. Tsirkin wrote:
> > On Fri, Apr 05, 2024 at 02:20:15PM +0300, Alexey Dobriyan wrote:
> > > Don't send zero length packets in virtio_net_flush_tx().
> > >
> > > Reproducer from https://gitlab.com/qemu-project/qemu/-/issues/1451
> > > creates small packet (1 segment, len = 10 == n->guest_hdr_len),
> > > destroys queue.
> > >
> > > "if (n->host_hdr_len != n->guest_hdr_len)" is triggered, if body creates
> > > zero length/zero segment packet, because there is nothing after guest
> > > header.
> > >
> > > qemu_sendv_packet_async() tries to send it.
> > >
> > > slirp discards it because it is smaller than Ethernet header,
> > > but returns 0.
> >
> > won't the same issue trigger with a 1 byte packet
> > as opposed to a 0 byte packet though?
>
> I don't think so. Only "return 0" is problematic from
> qemu_sendv_packet_async().
> ->deliver hooks are supposed to return total length, so 1 should be fine.
But you said it's smaller than Ethernet is the problem?
> > > 0 length is propagated upwards and is interpreted as "packet has been
> > > sent"
> > > which is terrible because queue is being destroyed, nothing has been sent,
> > > nobody is waiting for TX to complete and assert it triggered.
> > >
> > > Signed-off-by: Alexey Dobriyan
> > > ---
> > > hw/net/virtio-net.c | 18 --
> > > 1 file changed, 12 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > > index 58014a92ad..258633f885 100644
> > > --- a/hw/net/virtio-net.c
> > > +++ b/hw/net/virtio-net.c
> > > @@ -2765,18 +2765,14 @@ static int32_t virtio_net_flush_tx(VirtIONetQueue
> > > *q)
> > > out_sg = elem->out_sg;
> > > if (out_num < 1) {
> > > virtio_error(vdev, "virtio-net header not in first element");
> > > -virtqueue_detach_element(q->tx_vq, elem, 0);
> > > -g_free(elem);
> > > -return -EINVAL;
> > > +goto detach;
> > > }
> > >
> > > if (n->has_vnet_hdr) {
> > > if (iov_to_buf(out_sg, out_num, 0, , n->guest_hdr_len) <
> > > n->guest_hdr_len) {
> > > virtio_error(vdev, "virtio-net header incorrect");
> > > -virtqueue_detach_element(q->tx_vq, elem, 0);
> > > -g_free(elem);
> > > -return -EINVAL;
> > > +goto detach;
> > > }
> > > if (n->needs_vnet_hdr_swap) {
> > > virtio_net_hdr_swap(vdev, (void *) );
> > > @@ -2807,6 +2803,11 @@ static int32_t virtio_net_flush_tx(VirtIONetQueue
> > > *q)
> > > n->guest_hdr_len, -1);
> > > out_num = sg_num;
> > > out_sg = sg;
> > > +
> > > +if (iov_size(out_sg, out_num) == 0) {
> > > +virtio_error(vdev, "virtio-net nothing to send");
> > > +goto detach;
> > > +}
> > > }
> > >
> > > ret = qemu_sendv_packet_async(qemu_get_subqueue(n->nic,
> > > queue_index),
> > > @@ -2827,6 +2828,11 @@ drop:
> > > }
> > > }
> > > return num_packets;
> > > +
> > > +detach:
> > > +virtqueue_detach_element(q->tx_vq, elem, 0);
> > > +g_free(elem);
> > > +return -EINVAL;
> > > }
> > >
> > > static void virtio_net_tx_timer(void *opaque);
> > > --
> > > 2.34.1
> >
Re: [PATCH-for-9.0 v2 0/4] hw/virtio: Protect from more DMA re-entrancy bugs
On Tue, Apr 09, 2024 at 12:55:33PM +0200, Philippe Mathieu-Daudé wrote: > Fixes for CVE-2024-3446. > > Gerd suggested to use the transport guard to protect the > device from DMA re-entrancy abuses. > > Since v1: > - Take a DeviceState argument, not VirtIODevice, so it > works seamlessly with CCW devices (actually the original > code from Gerd). > - Build and test :> > > I'll send a PR with these patches later today. I reviewed these too now Reviewed-by: Michael S. Tsirkin > Regards, > > Phil. > > Philippe Mathieu-Daudé (4): > hw/virtio: Introduce virtio_bh_new_guarded() helper > hw/display/virtio-gpu: Protect from DMA re-entrancy bugs > hw/char/virtio-serial-bus: Protect from DMA re-entrancy bugs > hw/virtio/virtio-crypto: Protect from DMA re-entrancy bugs > > include/hw/virtio/virtio.h | 7 +++ > hw/char/virtio-serial-bus.c | 3 +-- > hw/display/virtio-gpu.c | 6 ++ > hw/virtio/virtio-crypto.c | 4 ++-- > hw/virtio/virtio.c | 10 ++ > 5 files changed, 22 insertions(+), 8 deletions(-) > > -- > 2.41.0
Re: [PATCH v2] vhost: don't set vring call if guest notifiers is not enabled
On Mon, Apr 08, 2024 at 03:33:11PM +0800, lyx634449800 wrote:
> When conducting performance testing using testpmd in the guest os,
> it was observed that the performance was lower compared to the
> scenario of direct vfio-pci usage.
>
> In the commit 96a3d98d2cdbd897ff5ab33427aa4cfb94077665, the author
> provided a good solution. However, because the guest OS's
> driver(e.g., virtio-net pmd) may not enable the msix capability, the
> function k->query_guest_notifiers(qbus->parent) may return false,
> resulting in the expected effect not being achieved. To address this
> issue, modify the conditional statement.
>
> Signed-off-by: Yuxue Liu
I tested v1 and it fails. Sent as reply on that patch.
Since all you did is tweak description and title the
problem is probably still there in v2.
> ---
> V2: Update commit description and title
>
> hw/virtio/vhost.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
> index f50180e60e..b972c84e67 100644
> --- a/hw/virtio/vhost.c
> +++ b/hw/virtio/vhost.c
> @@ -1266,13 +1266,15 @@ int vhost_virtqueue_start(struct vhost_dev *dev,
> vhost_virtqueue_mask(dev, vdev, idx, false);
> }
>
> -if (k->query_guest_notifiers &&
> -k->query_guest_notifiers(qbus->parent) &&
> -virtio_queue_vector(vdev, idx) == VIRTIO_NO_VECTOR) {
> -file.fd = -1;
> -r = dev->vhost_ops->vhost_set_vring_call(dev, );
> -if (r) {
> -goto fail_vector;
> +if (k->query_guest_notifiers) {
> +if (!k->query_guest_notifiers(qbus->parent) ||
> +(k->query_guest_notifiers(qbus->parent) &&
> +virtio_queue_vector(vdev, idx) == VIRTIO_NO_VECTOR)) {
> +file.fd = -1;
> +r = dev->vhost_ops->vhost_set_vring_call(dev, );
> +if (r) {
> +goto fail_vector;
> +}
> }
> }
>
> --
> 2.43.0
Re: [PATCH] vhost: don't set vring call if no enabled msix
On Mon, Apr 08, 2024 at 02:08:42PM +0800, lyx634449800 wrote:
> When conducting performance testing using testpmd in the guest os,
> it was observed that the performance was lower compared to the
> scenario of direct vfio-pci usage.
>
> In the virtual machine operating system, even if the virtio device
> does not use msix interrupts, vhost still sets vring call fd. This
> leads to unnecessary performance overhead. If the guest driver does
> not enable msix capability (e.g virtio-net pmd), we should also
> check and clear the vring call fd.
>
> Signed-off-by: Yuxue Liu
Fails testing under cross-i686-tci:
https://gitlab.com/mstredhat/qemu/-/jobs/6578881990
36/258 qemu:qtest+qtest-i386 / qtest-i386/ioh3420-testOK
0.15s 1 subtests passed
▶ 37/258 ERROR:../tests/qtest/qos-test.c:191:subprocess_run_one_test: child
process
(/aarch64/virt/generic-pcihost/pci-bus-generic/pci-bus/virtio-net-pci/virtio-net/virtio-net-tests/vhost-user/migrate/subprocess
[22197]) failed unexpectedly ERROR
38/258 qemu:qtest+qtest-i386 / qtest-i386/lpc-ich9-test OK
0.16s 1 subtests passed
37/258 qemu:qtest+qtest-aarch64 / qtest-aarch64/qos-test
ERROR 13.20s killed by signal 6 SIGABRT
>>> G_TEST_DBUS_DAEMON=/builds/mstredhat/qemu/tests/dbus-vmstate-daemon.sh
>>> PYTHON=/builds/mstredhat/qemu/build/pyvenv/bin/python3 MALLOC_PERTURB_=144
>>> QTEST_QEMU_BINARY=./qemu-system-aarch64
>>> /builds/mstredhat/qemu/build/tests/qtest/qos-test --tap -k
― ✀ ―
stderr:
**
ERROR:../tests/qtest/vhost-user-test.c:468:chr_read: assertion failed (err ==
NULL): Bad file descriptor (g-unix-error-quark, 0)
**
ERROR:../tests/qtest/qos-test.c:191:subprocess_run_one_test: child process
(/aarch64/virt/generic-pcihost/pci-bus-generic/pci-bus/virtio-net-pci/virtio-net/virtio-net-tests/vhost-user/migrate/subprocess
[22197]) failed unexpectedly
(test program exited with status code -6)
――
> ---
> hw/virtio/vhost.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
> index f50180e60e..b972c84e67 100644
> --- a/hw/virtio/vhost.c
> +++ b/hw/virtio/vhost.c
> @@ -1266,13 +1266,15 @@ int vhost_virtqueue_start(struct vhost_dev *dev,
> vhost_virtqueue_mask(dev, vdev, idx, false);
> }
>
> -if (k->query_guest_notifiers &&
> -k->query_guest_notifiers(qbus->parent) &&
> -virtio_queue_vector(vdev, idx) == VIRTIO_NO_VECTOR) {
> -file.fd = -1;
> -r = dev->vhost_ops->vhost_set_vring_call(dev, );
> -if (r) {
> -goto fail_vector;
> +if (k->query_guest_notifiers) {
> +if (!k->query_guest_notifiers(qbus->parent) ||
> +(k->query_guest_notifiers(qbus->parent) &&
> +virtio_queue_vector(vdev, idx) == VIRTIO_NO_VECTOR)) {
> +file.fd = -1;
> +r = dev->vhost_ops->vhost_set_vring_call(dev, );
> +if (r) {
> +goto fail_vector;
> +}
> }
> }
>
> --
> 2.43.0
[PULL 6/7] vhost-user-blk: simplify and fix vhost_user_blk_handle_config_change
From: Vladimir Sementsov-Ogievskiy
Let's not care about what was changed and update the whole config,
reasons:
1. config->geometry should be updated together with capacity, so we fix
a bug.
2. Vhost-user protocol doesn't say anything about config change
limitation. Silent ignore of changes doesn't seem to be correct.
3. vhost-user-vsock reads the whole config
4. on realize we don't do any checks on retrieved config, so no reason
to care here
Comment "valid for resize only" exists since introduction the whole
hw/block/vhost-user-blk.c in commit
00343e4b54ba0685e9ebe928ec5713b0cf7f1d1c
"vhost-user-blk: introduce a new vhost-user-blk host device",
seems it was just an extra limitation.
Also, let's notify guest unconditionally:
1. So does vhost-user-vsock
2. We are going to reuse the functionality in new cases when we do want
to notify the guest unconditionally. So, no reason to create extra
branches in the logic.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Acked-by: Raphael Norwitz
Message-Id: <20240329183758.3360733-2-vsement...@yandex-team.ru>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
hw/block/vhost-user-blk.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c
index 6a856ad51a..9e6bbc6950 100644
--- a/hw/block/vhost-user-blk.c
+++ b/hw/block/vhost-user-blk.c
@@ -91,7 +91,6 @@ static void vhost_user_blk_set_config(VirtIODevice *vdev,
const uint8_t *config)
static int vhost_user_blk_handle_config_change(struct vhost_dev *dev)
{
int ret;
-struct virtio_blk_config blkcfg;
VirtIODevice *vdev = dev->vdev;
VHostUserBlk *s = VHOST_USER_BLK(dev->vdev);
Error *local_err = NULL;
@@ -100,19 +99,15 @@ static int vhost_user_blk_handle_config_change(struct
vhost_dev *dev)
return 0;
}
-ret = vhost_dev_get_config(dev, (uint8_t *),
+ret = vhost_dev_get_config(dev, (uint8_t *)>blkcfg,
vdev->config_len, _err);
if (ret < 0) {
error_report_err(local_err);
return ret;
}
-/* valid for resize only */
-if (blkcfg.capacity != s->blkcfg.capacity) {
-s->blkcfg.capacity = blkcfg.capacity;
-memcpy(dev->vdev->config, >blkcfg, vdev->config_len);
-virtio_notify_config(dev->vdev);
-}
+memcpy(dev->vdev->config, >blkcfg, vdev->config_len);
+virtio_notify_config(dev->vdev);
return 0;
}
--
MST
[PULL 3/7] virtio-snd: rewrite invalid tx/rx message handling
From: Manos Pitsidianakis
The current handling of invalid virtqueue elements inside the TX/RX virt
queue handlers is wrong.
They are added in a per-stream invalid queue to be processed after the
handler is done examining each message, but the invalid message might
not be specifying any stream_id; which means it's invalid to add it to
any stream->invalid queue since stream could be NULL at this point.
This commit moves the invalid queue to the VirtIOSound struct which
guarantees there will always be a valid temporary place to store them
inside the tx/rx handlers. The queue will be emptied before the handler
returns, so the queue must be empty at any other point of the device's
lifetime.
Signed-off-by: Manos Pitsidianakis
Message-Id:
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
include/hw/audio/virtio-snd.h | 16 +++-
hw/audio/virtio-snd.c | 137 +++---
2 files changed, 77 insertions(+), 76 deletions(-)
diff --git a/include/hw/audio/virtio-snd.h b/include/hw/audio/virtio-snd.h
index 3d79181364..8dafedb276 100644
--- a/include/hw/audio/virtio-snd.h
+++ b/include/hw/audio/virtio-snd.h
@@ -151,7 +151,6 @@ struct VirtIOSoundPCMStream {
QemuMutex queue_mutex;
bool active;
QSIMPLEQ_HEAD(, VirtIOSoundPCMBuffer) queue;
-QSIMPLEQ_HEAD(, VirtIOSoundPCMBuffer) invalid;
};
/*
@@ -223,6 +222,21 @@ struct VirtIOSound {
QemuMutex cmdq_mutex;
QTAILQ_HEAD(, virtio_snd_ctrl_command) cmdq;
bool processing_cmdq;
+/*
+ * Convenience queue to keep track of invalid tx/rx queue messages inside
+ * the tx/rx callbacks.
+ *
+ * In the callbacks as a first step we are emptying the virtqueue to handle
+ * each message and we cannot add an invalid message back to the queue: we
+ * would re-process it in subsequent loop iterations.
+ *
+ * Instead, we add them to this queue and after finishing examining every
+ * virtqueue element, we inform the guest for each invalid message.
+ *
+ * This queue must be empty at all times except for inside the tx/rx
+ * callbacks.
+ */
+QSIMPLEQ_HEAD(, VirtIOSoundPCMBuffer) invalid;
};
struct virtio_snd_ctrl_command {
diff --git a/hw/audio/virtio-snd.c b/hw/audio/virtio-snd.c
index 30493f06a8..90d9a2796e 100644
--- a/hw/audio/virtio-snd.c
+++ b/hw/audio/virtio-snd.c
@@ -456,7 +456,6 @@ static uint32_t virtio_snd_pcm_prepare(VirtIOSound *s,
uint32_t stream_id)
stream->s = s;
qemu_mutex_init(>queue_mutex);
QSIMPLEQ_INIT(>queue);
-QSIMPLEQ_INIT(>invalid);
/*
* stream_id >= s->snd_conf.streams was checked before so this is
@@ -611,9 +610,6 @@ static size_t
virtio_snd_pcm_get_io_msgs_count(VirtIOSoundPCMStream *stream)
QSIMPLEQ_FOREACH_SAFE(buffer, >queue, entry, next) {
count += 1;
}
-QSIMPLEQ_FOREACH_SAFE(buffer, >invalid, entry, next) {
-count += 1;
-}
}
return count;
}
@@ -831,47 +827,36 @@ static void virtio_snd_handle_event(VirtIODevice *vdev,
VirtQueue *vq)
trace_virtio_snd_handle_event();
}
+/*
+ * Must only be called if vsnd->invalid is not empty.
+ */
static inline void empty_invalid_queue(VirtIODevice *vdev, VirtQueue *vq)
{
VirtIOSoundPCMBuffer *buffer = NULL;
-VirtIOSoundPCMStream *stream = NULL;
virtio_snd_pcm_status resp = { 0 };
VirtIOSound *vsnd = VIRTIO_SND(vdev);
-bool any = false;
-for (uint32_t i = 0; i < vsnd->snd_conf.streams; i++) {
-stream = vsnd->pcm->streams[i];
-if (stream) {
-any = false;
-WITH_QEMU_LOCK_GUARD(>queue_mutex) {
-while (!QSIMPLEQ_EMPTY(>invalid)) {
-buffer = QSIMPLEQ_FIRST(>invalid);
-if (buffer->vq != vq) {
-break;
-}
-any = true;
-resp.status = cpu_to_le32(VIRTIO_SND_S_BAD_MSG);
-iov_from_buf(buffer->elem->in_sg,
- buffer->elem->in_num,
- 0,
- ,
- sizeof(virtio_snd_pcm_status));
-virtqueue_push(vq,
- buffer->elem,
- sizeof(virtio_snd_pcm_status));
-QSIMPLEQ_REMOVE_HEAD(>invalid, entry);
-virtio_snd_pcm_buffer_free(buffer);
-}
-if (any) {
-/*
- * Notify vq about virtio_snd_pcm_status responses.
- * Buffer responses must be notified separately later.
- */
-virtio_notify(vdev, vq);
-}
-}
-}
+g_assert(!QSIMPLEQ_EMPTY(>invalid));
+
+wh
[PULL 5/7] vdpa-dev: Fix the issue of device status not updating when configuration interruption is triggered
From: lyx634449800
The set_config callback function vhost_vdpa_device_get_config in
vdpa-dev does not fetch the current device status from the hardware
device, causing the guest os to not receive the latest device status
information.
The hardware updates the config status of the vdpa device and then
notifies the os. The guest os receives an interrupt notification,
triggering a get_config access in the kernel, which then enters qemu
internally. Ultimately, the vhost_vdpa_device_get_config function of
vdpa-dev is called
One scenario encountered is when the device needs to bring down the
vdpa net device. After modifying the status field of virtio_net_config
in the hardware, it sends an interrupt notification. However, the guest
os always receives the STATUS field as VIRTIO_NET_S_LINK_UP.
Signed-off-by: Yuxue Liu
Acked-by: Jason Wang
Message-Id: <20240408020003.1979-1-yuxue@jaguarmicro.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
hw/virtio/vdpa-dev.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/hw/virtio/vdpa-dev.c b/hw/virtio/vdpa-dev.c
index 13e87f06f6..64b96b226c 100644
--- a/hw/virtio/vdpa-dev.c
+++ b/hw/virtio/vdpa-dev.c
@@ -195,7 +195,14 @@ static void
vhost_vdpa_device_get_config(VirtIODevice *vdev, uint8_t *config)
{
VhostVdpaDevice *s = VHOST_VDPA_DEVICE(vdev);
+int ret;
+ret = vhost_dev_get_config(>dev, s->config, s->config_size,
+NULL);
+if (ret < 0) {
+error_report("get device config space failed");
+return;
+}
memcpy(config, s->config, s->config_size);
}
--
MST
[PULL 4/7] hw/virtio: Fix packed virtqueue flush used_idx
From: Wafer
In the event of writing many chains of descriptors, the device must
write just the id of the last buffer in the descriptor chain, skip
forward the number of descriptors in the chain, and then repeat the
operations for the rest of chains.
Current QEMU code writes all the buffer ids consecutively, and then
skips all the buffers altogether. This is a bug, and can be reproduced
with a VirtIONet device with _F_MRG_RXBUB and without
_F_INDIRECT_DESC:
If a virtio-net device has the VIRTIO_NET_F_MRG_RXBUF feature
but not the VIRTIO_RING_F_INDIRECT_DESC feature,
'VirtIONetQueue->rx_vq' will use the merge feature
to store data in multiple 'elems'.
The 'num_buffers' in the virtio header indicates how many elements are merged.
If the value of 'num_buffers' is greater than 1,
all the merged elements will be filled into the descriptor ring.
The 'idx' of the elements should be the value of 'vq->used_idx' plus 'ndescs'.
Fixes: 86044b24e8 ("virtio: basic packed virtqueue support")
Acked-by: Eugenio Pérez
Signed-off-by: Wafer
Message-Id: <20240407015451.5228-2-wa...@jaguarmicro.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
hw/virtio/virtio.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index d229755eae..c5bedca848 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -957,12 +957,20 @@ static void virtqueue_packed_flush(VirtQueue *vq,
unsigned int count)
return;
}
+/*
+ * For indirect element's 'ndescs' is 1.
+ * For all other elemment's 'ndescs' is the
+ * number of descriptors chained by NEXT (as set in virtqueue_packed_pop).
+ * So When the 'elem' be filled into the descriptor ring,
+ * The 'idx' of this 'elem' shall be
+ * the value of 'vq->used_idx' plus the 'ndescs'.
+ */
+ndescs += vq->used_elems[0].ndescs;
for (i = 1; i < count; i++) {
-virtqueue_packed_fill_desc(vq, >used_elems[i], i, false);
+virtqueue_packed_fill_desc(vq, >used_elems[i], ndescs, false);
ndescs += vq->used_elems[i].ndescs;
}
virtqueue_packed_fill_desc(vq, >used_elems[0], 0, true);
-ndescs += vq->used_elems[0].ndescs;
vq->inuse -= ndescs;
vq->used_idx += ndescs;
--
MST
[PULL 2/7] virtio-snd: Enhance error handling for invalid transfers
From: Zheyu Ma
This patch improves error handling in virtio_snd_handle_tx_xfer()
and virtio_snd_handle_rx_xfer() in the VirtIO sound driver. Previously,
'goto' statements were used for error paths, leading to unnecessary
processing and potential null pointer dereferences. Now, 'continue' is
used to skip the rest of the current loop iteration for errors such as
message size discrepancies or null streams, reducing crash risks.
ASAN log illustrating the issue addressed:
ERROR: AddressSanitizer: SEGV on unknown address 0x00b4
#0 0x57cea39967b8 in qemu_mutex_lock_impl qemu/util/qemu-thread-posix.c:92:5
#1 0x57cea128c462 in qemu_mutex_lock qemu/include/qemu/thread.h:122:5
#2 0x57cea128d72f in qemu_lockable_lock qemu/include/qemu/lockable.h:95:5
#3 0x57cea128c294 in qemu_lockable_auto_lock
qemu/include/qemu/lockable.h:105:5
#4 0x57cea1285eb2 in virtio_snd_handle_rx_xfer
qemu/hw/audio/virtio-snd.c:1026:9
#5 0x57cea2caebbc in virtio_queue_notify_vq qemu/hw/virtio/virtio.c:2268:9
#6 0x57cea2cae412 in virtio_queue_host_notifier_read
qemu/hw/virtio/virtio.c:3671:9
#7 0x57cea39822f1 in aio_dispatch_handler qemu/util/aio-posix.c:372:9
#8 0x57cea3979385 in aio_dispatch_handlers qemu/util/aio-posix.c:414:20
#9 0x57cea3978eb1 in aio_dispatch qemu/util/aio-posix.c:424:5
#10 0x57cea3a1eede in aio_ctx_dispatch qemu/util/async.c:360:5
Signed-off-by: Zheyu Ma
Reviewed-by: Manos Pitsidianakis
Message-Id: <20240322110827.568412-1-zheyum...@gmail.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
hw/audio/virtio-snd.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/audio/virtio-snd.c b/hw/audio/virtio-snd.c
index e604d8f30c..30493f06a8 100644
--- a/hw/audio/virtio-snd.c
+++ b/hw/audio/virtio-snd.c
@@ -913,13 +913,13 @@ static void virtio_snd_handle_tx_xfer(VirtIODevice *vdev,
VirtQueue *vq)
,
sizeof(virtio_snd_pcm_xfer));
if (msg_sz != sizeof(virtio_snd_pcm_xfer)) {
-goto tx_err;
+continue;
}
stream_id = le32_to_cpu(hdr.stream_id);
if (stream_id >= s->snd_conf.streams
|| s->pcm->streams[stream_id] == NULL) {
-goto tx_err;
+continue;
}
stream = s->pcm->streams[stream_id];
@@ -995,13 +995,13 @@ static void virtio_snd_handle_rx_xfer(VirtIODevice *vdev,
VirtQueue *vq)
,
sizeof(virtio_snd_pcm_xfer));
if (msg_sz != sizeof(virtio_snd_pcm_xfer)) {
-goto rx_err;
+continue;
}
stream_id = le32_to_cpu(hdr.stream_id);
if (stream_id >= s->snd_conf.streams
|| !s->pcm->streams[stream_id]) {
-goto rx_err;
+continue;
}
stream = s->pcm->streams[stream_id];
--
MST
[PULL 7/7] qdev-monitor: fix error message in find_device_state()
From: Vladimir Sementsov-Ogievskiy
This "hotpluggable" here is misleading. Actually we check is object a
device or not. Let's drop the word.
Suggested-by: Markus Armbruster
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Markus Armbruster
Message-Id: <20240329183758.3360733-3-vsement...@yandex-team.ru>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
system/qdev-monitor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
index c1243891c3..840177d19f 100644
--- a/system/qdev-monitor.c
+++ b/system/qdev-monitor.c
@@ -891,7 +891,7 @@ static DeviceState *find_device_state(const char *id, Error
**errp)
dev = (DeviceState *)object_dynamic_cast(obj, TYPE_DEVICE);
if (!dev) {
-error_setg(errp, "%s is not a hotpluggable device", id);
+error_setg(errp, "%s is not a device", id);
return NULL;
}
--
MST
[PULL 1/7] Revert "hw/virtio: Add support for VDPA network simulation devices"
This reverts commit cd341fd1ffded978b2aa0b5309b00be7c42e347c.
The patch adds non-upstream code in
include/standard-headers/linux/virtio_pci.h
which would make maintainance harder.
Revert for now.
Suggested-by: Jason Wang
Message-Id:
Acked-by: Jason Wang
Signed-off-by: Michael S. Tsirkin
---
include/hw/virtio/virtio-pci.h | 5 -
include/hw/virtio/virtio.h | 19 --
include/standard-headers/linux/virtio_pci.h | 7 -
hw/net/virtio-net.c | 16 --
hw/virtio/virtio-pci.c | 189 +---
hw/virtio/virtio.c | 39
MAINTAINERS | 5 -
docs/system/device-emulation.rst| 1 -
docs/system/devices/vdpa-net.rst| 121 -
9 files changed, 3 insertions(+), 399 deletions(-)
delete mode 100644 docs/system/devices/vdpa-net.rst
diff --git a/include/hw/virtio/virtio-pci.h b/include/hw/virtio/virtio-pci.h
index 4d57a9c751..59d88018c1 100644
--- a/include/hw/virtio/virtio-pci.h
+++ b/include/hw/virtio/virtio-pci.h
@@ -43,7 +43,6 @@ enum {
VIRTIO_PCI_FLAG_INIT_FLR_BIT,
VIRTIO_PCI_FLAG_AER_BIT,
VIRTIO_PCI_FLAG_ATS_PAGE_ALIGNED_BIT,
-VIRTIO_PCI_FLAG_VDPA_BIT,
};
/* Need to activate work-arounds for buggy guests at vmstate load. */
@@ -90,9 +89,6 @@ enum {
#define VIRTIO_PCI_FLAG_ATS_PAGE_ALIGNED \
(1 << VIRTIO_PCI_FLAG_ATS_PAGE_ALIGNED_BIT)
-/* VDPA supported flags */
-#define VIRTIO_PCI_FLAG_VDPA (1 << VIRTIO_PCI_FLAG_VDPA_BIT)
-
typedef struct {
MSIMessage msg;
int virq;
@@ -144,7 +140,6 @@ struct VirtIOPCIProxy {
};
VirtIOPCIRegion regs[5];
};
-VirtIOPCIRegion lm;
MemoryRegion modern_bar;
MemoryRegion io_bar;
uint32_t legacy_io_bar_idx;
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index b3c74a1bca..c8f72850bc 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -35,9 +35,6 @@
(0x1ULL << VIRTIO_F_NOTIFY_ON_EMPTY) | \
(0x1ULL << VIRTIO_F_ANY_LAYOUT))
-#define LM_DISABLE 0x00
-#define LM_ENABLE 0x01
-
struct VirtQueue;
static inline hwaddr vring_align(hwaddr addr,
@@ -98,11 +95,6 @@ enum virtio_device_endian {
VIRTIO_DEVICE_ENDIAN_BIG,
};
-typedef struct BitmapMemoryRegionCaches {
-struct rcu_head rcu;
-MemoryRegionCache bitmap;
-} BitmapMemoryRegionCaches;
-
/**
* struct VirtIODevice - common VirtIO structure
* @name: name of the device
@@ -136,14 +128,6 @@ struct VirtIODevice
uint32_t generation;
int nvectors;
VirtQueue *vq;
-uint8_t lm_logging_ctrl;
-uint32_t lm_base_addr_low;
-uint32_t lm_base_addr_high;
-uint32_t lm_end_addr_low;
-uint32_t lm_end_addr_high;
-
-BitmapMemoryRegionCaches *caches;
-
MemoryListener listener;
uint16_t device_id;
/* @vm_running: current VM running state via virtio_vmstate_change() */
@@ -395,11 +379,8 @@ hwaddr virtio_queue_get_desc_size(VirtIODevice *vdev, int
n);
hwaddr virtio_queue_get_avail_size(VirtIODevice *vdev, int n);
hwaddr virtio_queue_get_used_size(VirtIODevice *vdev, int n);
unsigned int virtio_queue_get_last_avail_idx(VirtIODevice *vdev, int n);
-unsigned int virtio_queue_get_vring_states(VirtIODevice *vdev, int n);
void virtio_queue_set_last_avail_idx(VirtIODevice *vdev, int n,
unsigned int idx);
-void virtio_queue_set_vring_states(VirtIODevice *vdev, int n,
- unsigned int idx);
void virtio_queue_restore_last_avail_idx(VirtIODevice *vdev, int n);
void virtio_queue_invalidate_signalled_used(VirtIODevice *vdev, int n);
void virtio_queue_update_used_idx(VirtIODevice *vdev, int n);
diff --git a/include/standard-headers/linux/virtio_pci.h
b/include/standard-headers/linux/virtio_pci.h
index 86733278ba..3e2bc2c97e 100644
--- a/include/standard-headers/linux/virtio_pci.h
+++ b/include/standard-headers/linux/virtio_pci.h
@@ -221,13 +221,6 @@ struct virtio_pci_cfg_cap {
#define VIRTIO_PCI_COMMON_ADM_Q_IDX60
#define VIRTIO_PCI_COMMON_ADM_Q_NUM62
-#define LM_LOGGING_CTRL 0
-#define LM_BASE_ADDR_LOW4
-#define LM_BASE_ADDR_HIGH 8
-#define LM_END_ADDR_LOW 12
-#define LM_END_ADDR_HIGH16
-#define LM_VRING_STATE_OFFSET 0x20
-
#endif /* VIRTIO_PCI_NO_MODERN */
/* Admin command status. */
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 58014a92ad..24e5e7d347 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -2039,22 +2039,6 @@ static ssize_t virtio_net_receive_rcu(NetClientState
*nc, const uint8_t *buf,
goto err;
}
-/* Mark dirty page's bitmap of guest memory */
-if (vdev->lm_logging_ctrl == LM_ENABLE) {
-uint64_t chunk = elem-&g
[PULL 0/7] virtio,pc,pci: bugfixes
The following changes since commit ce64e6224affb8b4e4b019f76d2950270b391af5: Merge tag 'qemu-sparc-20240404' of https://github.com/mcayland/qemu into staging (2024-04-04 15:28:06 +0100) are available in the Git repository at: https://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream for you to fetch changes up to e104a960c33b68fedf26dfb7b8e00abab8f2: qdev-monitor: fix error message in find_device_state() (2024-04-09 02:31:33 -0400) virtio,pc,pci: bugfixes Tiny fixes: important but mostly obvious ones. Revert VDPA network sim for this release as there are questions around it's maintainatiblity. Signed-off-by: Michael S. Tsirkin Manos Pitsidianakis (1): virtio-snd: rewrite invalid tx/rx message handling Michael S. Tsirkin (1): Revert "hw/virtio: Add support for VDPA network simulation devices" Vladimir Sementsov-Ogievskiy (2): vhost-user-blk: simplify and fix vhost_user_blk_handle_config_change qdev-monitor: fix error message in find_device_state() Wafer (1): hw/virtio: Fix packed virtqueue flush used_idx Zheyu Ma (1): virtio-snd: Enhance error handling for invalid transfers lyx634449800 (1): vdpa-dev: Fix the issue of device status not updating when configuration interruption is triggered include/hw/audio/virtio-snd.h | 16 ++- include/hw/virtio/virtio-pci.h | 5 - include/hw/virtio/virtio.h | 19 --- include/standard-headers/linux/virtio_pci.h | 7 -- hw/audio/virtio-snd.c | 129 +-- hw/block/vhost-user-blk.c | 11 +- hw/net/virtio-net.c | 16 --- hw/virtio/vdpa-dev.c| 7 ++ hw/virtio/virtio-pci.c | 189 +--- hw/virtio/virtio.c | 51 ++-- system/qdev-monitor.c | 2 +- MAINTAINERS | 5 - docs/system/device-emulation.rst| 1 - docs/system/devices/vdpa-net.rst| 121 -- 14 files changed, 97 insertions(+), 482 deletions(-) delete mode 100644 docs/system/devices/vdpa-net.rst
Re: [PATCH 1/1] virtio-net: fix bug 1451 aka "assert(!virtio_net_get_subqueue(nc)->async_tx.elem);"
On Fri, Apr 05, 2024 at 02:20:15PM +0300, Alexey Dobriyan wrote:
> Don't send zero length packets in virtio_net_flush_tx().
>
> Reproducer from https://gitlab.com/qemu-project/qemu/-/issues/1451
> creates small packet (1 segment, len = 10 == n->guest_hdr_len),
> destroys queue.
>
> "if (n->host_hdr_len != n->guest_hdr_len)" is triggered, if body creates
> zero length/zero segment packet, because there is nothing after guest
> header.
>
> qemu_sendv_packet_async() tries to send it.
>
> slirp discards it because it is smaller than Ethernet header,
> but returns 0.
won't the same issue trigger with a 1 byte packet
as opposed to a 0 byte packet though?
> 0 length is propagated upwards and is interpreted as "packet has been sent"
> which is terrible because queue is being destroyed, nothing has been sent,
> nobody is waiting for TX to complete and assert it triggered.
>
> Signed-off-by: Alexey Dobriyan
> ---
> hw/net/virtio-net.c | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index 58014a92ad..258633f885 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -2765,18 +2765,14 @@ static int32_t virtio_net_flush_tx(VirtIONetQueue *q)
> out_sg = elem->out_sg;
> if (out_num < 1) {
> virtio_error(vdev, "virtio-net header not in first element");
> -virtqueue_detach_element(q->tx_vq, elem, 0);
> -g_free(elem);
> -return -EINVAL;
> +goto detach;
> }
>
> if (n->has_vnet_hdr) {
> if (iov_to_buf(out_sg, out_num, 0, , n->guest_hdr_len) <
> n->guest_hdr_len) {
> virtio_error(vdev, "virtio-net header incorrect");
> -virtqueue_detach_element(q->tx_vq, elem, 0);
> -g_free(elem);
> -return -EINVAL;
> +goto detach;
> }
> if (n->needs_vnet_hdr_swap) {
> virtio_net_hdr_swap(vdev, (void *) );
> @@ -2807,6 +2803,11 @@ static int32_t virtio_net_flush_tx(VirtIONetQueue *q)
> n->guest_hdr_len, -1);
> out_num = sg_num;
> out_sg = sg;
> +
> +if (iov_size(out_sg, out_num) == 0) {
> +virtio_error(vdev, "virtio-net nothing to send");
> +goto detach;
> +}
> }
>
> ret = qemu_sendv_packet_async(qemu_get_subqueue(n->nic, queue_index),
> @@ -2827,6 +2828,11 @@ drop:
> }
> }
> return num_packets;
> +
> +detach:
> +virtqueue_detach_element(q->tx_vq, elem, 0);
> +g_free(elem);
> +return -EINVAL;
> }
>
> static void virtio_net_tx_timer(void *opaque);
> --
> 2.34.1
Re: [PATCH 1/1] virtio-net: fix bug 1451 aka "assert(!virtio_net_get_subqueue(nc)->async_tx.elem);"
On Fri, Apr 05, 2024 at 02:20:15PM +0300, Alexey Dobriyan wrote:
> Don't send zero length packets in virtio_net_flush_tx().
>
> Reproducer from https://gitlab.com/qemu-project/qemu/-/issues/1451
> creates small packet (1 segment, len = 10 == n->guest_hdr_len),
> destroys queue.
>
> "if (n->host_hdr_len != n->guest_hdr_len)" is triggered, if body creates
> zero length/zero segment packet, because there is nothing after guest
> header.
>
> qemu_sendv_packet_async() tries to send it.
>
> slirp discards it because it is smaller than Ethernet header,
> but returns 0.
>
> 0 length is propagated upwards and is interpreted as "packet has been sent"
> which is terrible because queue is being destroyed, nothing has been sent,
> nobody is waiting for TX to complete and assert it triggered.
>
> Signed-off-by: Alexey Dobriyan
> ---
> hw/net/virtio-net.c | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index 58014a92ad..258633f885 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -2765,18 +2765,14 @@ static int32_t virtio_net_flush_tx(VirtIONetQueue *q)
> out_sg = elem->out_sg;
> if (out_num < 1) {
> virtio_error(vdev, "virtio-net header not in first element");
> -virtqueue_detach_element(q->tx_vq, elem, 0);
> -g_free(elem);
> -return -EINVAL;
> +goto detach;
> }
>
> if (n->has_vnet_hdr) {
> if (iov_to_buf(out_sg, out_num, 0, , n->guest_hdr_len) <
> n->guest_hdr_len) {
> virtio_error(vdev, "virtio-net header incorrect");
> -virtqueue_detach_element(q->tx_vq, elem, 0);
> -g_free(elem);
> -return -EINVAL;
> +goto detach;
> }
> if (n->needs_vnet_hdr_swap) {
> virtio_net_hdr_swap(vdev, (void *) );
> @@ -2807,6 +2803,11 @@ static int32_t virtio_net_flush_tx(VirtIONetQueue *q)
> n->guest_hdr_len, -1);
> out_num = sg_num;
> out_sg = sg;
> +
> +if (iov_size(out_sg, out_num) == 0) {
calling iov_size an extra time on data path and scanning
a potentially long s/g list just so we can check
it's not 0 is not welcome, though.
won't the previous iov_copy return 0 in this case?
> +virtio_error(vdev, "virtio-net nothing to send");
> +goto detach;
> +}
> }
>
> ret = qemu_sendv_packet_async(qemu_get_subqueue(n->nic, queue_index),
> @@ -2827,6 +2828,11 @@ drop:
> }
> }
> return num_packets;
> +
> +detach:
> +virtqueue_detach_element(q->tx_vq, elem, 0);
> +g_free(elem);
> +return -EINVAL;
> }
>
> static void virtio_net_tx_timer(void *opaque);
> --
> 2.34.1
Re: [PATCH] virtio-iommu: Do not process commands with bad size
On Thu, Apr 04, 2024 at 02:45:05PM +0200, Zheyu Ma wrote: > The device should not handle the commands which have bad request/reply > size, it should just report the error instead of raising an assertation. > > Signed-off-by: Zheyu Ma This fails test for cross-i686-tci https://gitlab.com/mstredhat/qemu/-/jobs/6578222837 57/258 ERROR:../tests/qtest/libqos/virtio.c:230:qvirtio_wait_used_elem: assertion failed: (g_get_monotonic_time() - start_time <= timeout_us) ERROR 57/258 qemu:qtest+qtest-i386 / qtest-i386/qos-test ERROR 56.69s killed by signal 6 SIGABRT >>> QTEST_QEMU_BINARY=./qemu-system-i386 >>> PYTHON=/builds/mstredhat/qemu/build/pyvenv/bin/python3 MALLOC_PERTURB_=112 >>> G_TEST_DBUS_DAEMON=/builds/mstredhat/qemu/tests/dbus-vmstate-daemon.sh >>> /builds/mstredhat/qemu/build/tests/qtest/qos-test --tap -k ― ✀ ― stderr: Vhost user backend fails to broadcast fake RARP qemu-system-i386: -chardev socket,id=chr-reconnect,path=/tmp/vhost-test-80QXL2/reconnect.sock,server=on: info: QEMU waiting for connection on: disconnected:unix:/tmp/vhost-test-80QXL2/reconnect.sock,server=on qemu-system-i386: Failed to set msg fds. qemu-system-i386: vhost VQ 0 ring restore failed: -22: Invalid argument (22) qemu-system-i386: Failed to set msg fds. qemu-system-i386: vhost VQ 1 ring restore failed: -22: Invalid argument (22) qemu-system-i386: Failed to set msg fds. qemu-system-i386: vhost VQ 0 ring restore failed: -22: Invalid argument (22) qemu-system-i386: Failed to set msg fds. qemu-system-i386: vhost VQ 1 ring restore failed: -22: Invalid argument (22) qemu-system-i386: -chardev socket,id=chr-connect-fail,path=/tmp/vhost-test-CZMWL2/connect-fail.sock,server=on: info: QEMU waiting for connection on: disconnected:unix:/tmp/vhost-test-CZMWL2/connect-fail.sock,server=on qemu-system-i386: -netdev vhost-user,id=hs0,chardev=chr-connect-fail,vhostforce=on: Failed to read msg header. Read 0 instead of 12. Original request 1. qemu-system-i386: -netdev vhost-user,id=hs0,chardev=chr-connect-fail,vhostforce=on: vhost_backend_init failed: Protocol error qemu-system-i386: -netdev vhost-user,id=hs0,chardev=chr-connect-fail,vhostforce=on: failed to init vhost_net for queue 0 qemu-system-i386: -netdev vhost-user,id=hs0,chardev=chr-connect-fail,vhostforce=on: info: QEMU waiting for connection on: disconnected:unix:/tmp/vhost-test-CZMWL2/connect-fail.sock,server=on qemu-system-i386: Failed to write msg. Wrote -1 instead of 20. qemu-system-i386: vhost VQ 0 ring restore failed: -22: Invalid argument (22) qemu-system-i386: Failed to set msg fds. qemu-system-i386: vhost VQ 1 ring restore failed: -22: Invalid argument (22) qemu-system-i386: -chardev socket,id=chr-flags-mismatch,path=/tmp/vhost-test-CBHDM2/flags-mismatch.sock,server=on: info: QEMU waiting for connection on: disconnected:unix:/tmp/vhost-test-CBHDM2/flags-mismatch.sock,server=on qemu-system-i386: Failed to write msg. Wrote -1 instead of 84. qemu-system-i386: vhost_set_mem_table failed: Invalid argument (22) qemu-system-i386: unable to start vhost net: 22: falling back on userspace virtio vhost lacks feature mask 0x4000 for backend qemu-system-i386: failed to init vhost_net for queue 0 qemu-system-i386: Failed to set msg fds. qemu-system-i386: vhost VQ 0 ring restore failed: -22: Invalid argument (22) qemu-system-i386: Failed to set msg fds. qemu-system-i386: vhost VQ 1 ring restore failed: -22: Invalid argument (22) qemu-system-i386: Failed to write msg. Wrote -1 instead of 20. qemu-system-i386: vhost VQ 0 ring restore failed: -22: Invalid argument (22) qemu-system-i386: Failed to set msg fds. qemu-system-i386: vhost VQ 1 ring restore failed: -22: Invalid argument (22) qemu-system-i386: Failed to set msg fds. qemu-system-i386: vhost VQ 2 ring restore failed: -22: Invalid argument (22) qemu-system-i386: Failed to set msg fds. qemu-system-i386: vhost VQ 3 ring restore failed: -22: Invalid argument (22) qemu-system-i386: Failed to set msg fds. qemu-system-i386: vhost VQ 0 ring restore failed: -22: Invalid argument (22) qemu-system-i386: Failed to set msg fds. qemu-system-i386: vhost VQ 1 ring restore failed: -22: Invalid argument (22) qemu-system-i386: Failed to set msg fds. qemu-system-i386: vhost VQ 0 ring restore failed: -22: Invalid argument (22) qemu-system-i386: Failed to set msg fds. qemu-system-i386: vhost VQ 1 ring restore failed: -22: Invalid argument (22) qemu-system-i386: virtio-iommu bad head/tail size ** ERROR:../tests/qtest/libqos/virtio.c:230:qvirtio_wait_used_elem: assertion failed: (g_get_monotonic_time() - start_time <= timeout_us) (test program exited with status code -6) ―― So we hit the error where we did not previously hit the assert. Dropped for now. Pls figure it out and resubmit. > --- > hw/virtio/virtio-iommu.c | 10 +++--- >
Re: [PATCH] Revert "hw/virtio: Add support for VDPA network simulation devices"
On Mon, Apr 08, 2024 at 10:11:18PM +0200, Paolo Bonzini wrote: > > > Il lun 8 apr 2024, 12:18 Michael S. Tsirkin ha scritto: > > On Mon, Apr 08, 2024 at 10:51:57AM +0100, Peter Maydell wrote: > > On Mon, 8 Apr 2024 at 10:48, Michael S. Tsirkin wrote: > > > > > > This reverts commit cd341fd1ffded978b2aa0b5309b00be7c42e347c. > > > > > > The patch adds non-upstream code in > > > include/standard-headers/linux/virtio_pci.h > > > which would make maintainance harder. > > > > > > Revert for now. > > > As long as it is part of the spec, why not just move the problematic parts to > a > QEMU specific header? As far as I understand the kernel is never going to > consume these constants anyway. > > Paolo I expect the contributor to do fixups like this though, not myself. > > > > Suggested-by: Jason Wang > > > Signed-off-by: Michael S. Tsirkin > > > > Are you intending to target this revert for 9.0 ? > > > > -- PMM > > Yes. > >
Re: [PATCH-for-9.0 3/4] hw/char/virtio-serial-bus: Protect from DMA re-entrancy bugs
On Mon, Apr 08, 2024 at 01:04:11PM +0200, Philippe Mathieu-Daudé wrote: > On 8/4/24 12:08, Michael S. Tsirkin wrote: > > On Mon, Apr 08, 2024 at 09:14:39AM +0200, Philippe Mathieu-Daudé wrote: > > > On 4/4/24 21:13, Philippe Mathieu-Daudé wrote: > > > > Replace qemu_bh_new_guarded() by virtio_bh_new_guarded() > > > > so the bus and device use the same guard. Otherwise the > > > > DMA-reentrancy protection can be bypassed. > > > > > > > > Cc: qemu-sta...@nongnu.org > > > > Suggested-by: Alexander Bulekov > > > > Signed-off-by: Philippe Mathieu-Daudé > > > > --- > > > >hw/char/virtio-serial-bus.c | 3 +-- > > > >1 file changed, 1 insertion(+), 2 deletions(-) > > > > > > > > diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c > > > > index 016aba6374..cd0e3a11f7 100644 > > > > --- a/hw/char/virtio-serial-bus.c > > > > +++ b/hw/char/virtio-serial-bus.c > > > > @@ -985,8 +985,7 @@ static void virtser_port_device_realize(DeviceState > > > > *dev, Error **errp) > > > >return; > > > >} > > > > -port->bh = qemu_bh_new_guarded(flush_queued_data_bh, port, > > > > - >mem_reentrancy_guard); > > > > +port->bh = virtio_bh_new_guarded(vdev, flush_queued_data_bh, port); > > > > > > Missing: > > > -- >8 -- > > > -port->bh = virtio_bh_new_guarded(vdev, flush_queued_data_bh, port); > > > +port->bh = virtio_bh_new_guarded(VIRTIO_DEVICE(dev), > > > + flush_queued_data_bh, port); > > > --- > > > > I don't get it. vdev is already the correct type. Why do you need > > VIRTIO_DEVICE here? > > This function doesn't declare vdev. > > > > > > >port->elem = NULL; > > > >} > > But it seems clear it wasn't really tested, right? Philipe here's my ack: Acked-by: Michael S. Tsirkin Feel free to merge these after testing. -- MST
Re: [PATCH] Revert "hw/virtio: Add support for VDPA network simulation devices"
On Mon, Apr 08, 2024 at 10:51:57AM +0100, Peter Maydell wrote: > On Mon, 8 Apr 2024 at 10:48, Michael S. Tsirkin wrote: > > > > This reverts commit cd341fd1ffded978b2aa0b5309b00be7c42e347c. > > > > The patch adds non-upstream code in > > include/standard-headers/linux/virtio_pci.h > > which would make maintainance harder. > > > > Revert for now. > > > > Suggested-by: Jason Wang > > Signed-off-by: Michael S. Tsirkin > > Are you intending to target this revert for 9.0 ? > > -- PMM Yes.
Re: [PATCH 1/2] virtio-net: Fix vhost virtqueue notifiers for RSS
On Tue, Mar 26, 2024 at 07:06:29PM +0900, Akihiko Odaki wrote:
> virtio_net_guest_notifier_pending() and virtio_net_guest_notifier_mask()
> checked VIRTIO_NET_F_MQ to know there are multiple queues, but
> VIRTIO_NET_F_RSS also enables multiple queues. Refer to n->multiqueue,
> which is set to true either of VIRTIO_NET_F_MQ or VIRTIO_NET_F_RSS is
> enabled.
>
> Fixes: 68b0a6395f36 ("virtio-net: align ctrl_vq index for non-mq guest for
> vhost_vdpa")
> Signed-off-by: Akihiko Odaki
Reviewed-by: Michael S. Tsirkin
Jason, are you merging this?
> ---
> hw/net/virtio-net.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index 9959f1932b1b..a6ff000cd9d3 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -3426,7 +3426,7 @@ static bool
> virtio_net_guest_notifier_pending(VirtIODevice *vdev, int idx)
> VirtIONet *n = VIRTIO_NET(vdev);
> NetClientState *nc;
> assert(n->vhost_started);
> -if (!virtio_vdev_has_feature(vdev, VIRTIO_NET_F_MQ) && idx == 2) {
> +if (!n->multiqueue && idx == 2) {
> /* Must guard against invalid features and bogus queue index
> * from being set by malicious guest, or penetrated through
> * buggy migration stream.
> @@ -3458,7 +3458,7 @@ static void virtio_net_guest_notifier_mask(VirtIODevice
> *vdev, int idx,
> VirtIONet *n = VIRTIO_NET(vdev);
> NetClientState *nc;
> assert(n->vhost_started);
> -if (!virtio_vdev_has_feature(vdev, VIRTIO_NET_F_MQ) && idx == 2) {
> +if (!n->multiqueue && idx == 2) {
> /* Must guard against invalid features and bogus queue index
> * from being set by malicious guest, or penetrated through
> * buggy migration stream.
>
> --
> 2.44.0
Re: [PATCH-for-9.0 3/4] hw/char/virtio-serial-bus: Protect from DMA re-entrancy bugs
On Mon, Apr 08, 2024 at 09:14:39AM +0200, Philippe Mathieu-Daudé wrote: > On 4/4/24 21:13, Philippe Mathieu-Daudé wrote: > > Replace qemu_bh_new_guarded() by virtio_bh_new_guarded() > > so the bus and device use the same guard. Otherwise the > > DMA-reentrancy protection can be bypassed. > > > > Cc: qemu-sta...@nongnu.org > > Suggested-by: Alexander Bulekov > > Signed-off-by: Philippe Mathieu-Daudé > > --- > > hw/char/virtio-serial-bus.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c > > index 016aba6374..cd0e3a11f7 100644 > > --- a/hw/char/virtio-serial-bus.c > > +++ b/hw/char/virtio-serial-bus.c > > @@ -985,8 +985,7 @@ static void virtser_port_device_realize(DeviceState > > *dev, Error **errp) > > return; > > } > > -port->bh = qemu_bh_new_guarded(flush_queued_data_bh, port, > > - >mem_reentrancy_guard); > > +port->bh = virtio_bh_new_guarded(vdev, flush_queued_data_bh, port); > > Missing: > -- >8 -- > -port->bh = virtio_bh_new_guarded(vdev, flush_queued_data_bh, port); > +port->bh = virtio_bh_new_guarded(VIRTIO_DEVICE(dev), > + flush_queued_data_bh, port); > --- I don't get it. vdev is already the correct type. Why do you need VIRTIO_DEVICE here? > > port->elem = NULL; > > }
[PATCH] Revert "hw/virtio: Add support for VDPA network simulation devices"
This reverts commit cd341fd1ffded978b2aa0b5309b00be7c42e347c.
The patch adds non-upstream code in
include/standard-headers/linux/virtio_pci.h
which would make maintainance harder.
Revert for now.
Suggested-by: Jason Wang
Signed-off-by: Michael S. Tsirkin
---
include/hw/virtio/virtio-pci.h | 5 -
include/hw/virtio/virtio.h | 19 --
include/standard-headers/linux/virtio_pci.h | 7 -
hw/net/virtio-net.c | 16 --
hw/virtio/virtio-pci.c | 189 +---
hw/virtio/virtio.c | 39
MAINTAINERS | 5 -
docs/system/device-emulation.rst| 1 -
docs/system/devices/vdpa-net.rst| 121 -
9 files changed, 3 insertions(+), 399 deletions(-)
delete mode 100644 docs/system/devices/vdpa-net.rst
diff --git a/include/hw/virtio/virtio-pci.h b/include/hw/virtio/virtio-pci.h
index 4d57a9c751..59d88018c1 100644
--- a/include/hw/virtio/virtio-pci.h
+++ b/include/hw/virtio/virtio-pci.h
@@ -43,7 +43,6 @@ enum {
VIRTIO_PCI_FLAG_INIT_FLR_BIT,
VIRTIO_PCI_FLAG_AER_BIT,
VIRTIO_PCI_FLAG_ATS_PAGE_ALIGNED_BIT,
-VIRTIO_PCI_FLAG_VDPA_BIT,
};
/* Need to activate work-arounds for buggy guests at vmstate load. */
@@ -90,9 +89,6 @@ enum {
#define VIRTIO_PCI_FLAG_ATS_PAGE_ALIGNED \
(1 << VIRTIO_PCI_FLAG_ATS_PAGE_ALIGNED_BIT)
-/* VDPA supported flags */
-#define VIRTIO_PCI_FLAG_VDPA (1 << VIRTIO_PCI_FLAG_VDPA_BIT)
-
typedef struct {
MSIMessage msg;
int virq;
@@ -144,7 +140,6 @@ struct VirtIOPCIProxy {
};
VirtIOPCIRegion regs[5];
};
-VirtIOPCIRegion lm;
MemoryRegion modern_bar;
MemoryRegion io_bar;
uint32_t legacy_io_bar_idx;
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index b3c74a1bca..c8f72850bc 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -35,9 +35,6 @@
(0x1ULL << VIRTIO_F_NOTIFY_ON_EMPTY) | \
(0x1ULL << VIRTIO_F_ANY_LAYOUT))
-#define LM_DISABLE 0x00
-#define LM_ENABLE 0x01
-
struct VirtQueue;
static inline hwaddr vring_align(hwaddr addr,
@@ -98,11 +95,6 @@ enum virtio_device_endian {
VIRTIO_DEVICE_ENDIAN_BIG,
};
-typedef struct BitmapMemoryRegionCaches {
-struct rcu_head rcu;
-MemoryRegionCache bitmap;
-} BitmapMemoryRegionCaches;
-
/**
* struct VirtIODevice - common VirtIO structure
* @name: name of the device
@@ -136,14 +128,6 @@ struct VirtIODevice
uint32_t generation;
int nvectors;
VirtQueue *vq;
-uint8_t lm_logging_ctrl;
-uint32_t lm_base_addr_low;
-uint32_t lm_base_addr_high;
-uint32_t lm_end_addr_low;
-uint32_t lm_end_addr_high;
-
-BitmapMemoryRegionCaches *caches;
-
MemoryListener listener;
uint16_t device_id;
/* @vm_running: current VM running state via virtio_vmstate_change() */
@@ -395,11 +379,8 @@ hwaddr virtio_queue_get_desc_size(VirtIODevice *vdev, int
n);
hwaddr virtio_queue_get_avail_size(VirtIODevice *vdev, int n);
hwaddr virtio_queue_get_used_size(VirtIODevice *vdev, int n);
unsigned int virtio_queue_get_last_avail_idx(VirtIODevice *vdev, int n);
-unsigned int virtio_queue_get_vring_states(VirtIODevice *vdev, int n);
void virtio_queue_set_last_avail_idx(VirtIODevice *vdev, int n,
unsigned int idx);
-void virtio_queue_set_vring_states(VirtIODevice *vdev, int n,
- unsigned int idx);
void virtio_queue_restore_last_avail_idx(VirtIODevice *vdev, int n);
void virtio_queue_invalidate_signalled_used(VirtIODevice *vdev, int n);
void virtio_queue_update_used_idx(VirtIODevice *vdev, int n);
diff --git a/include/standard-headers/linux/virtio_pci.h
b/include/standard-headers/linux/virtio_pci.h
index 86733278ba..3e2bc2c97e 100644
--- a/include/standard-headers/linux/virtio_pci.h
+++ b/include/standard-headers/linux/virtio_pci.h
@@ -221,13 +221,6 @@ struct virtio_pci_cfg_cap {
#define VIRTIO_PCI_COMMON_ADM_Q_IDX60
#define VIRTIO_PCI_COMMON_ADM_Q_NUM62
-#define LM_LOGGING_CTRL 0
-#define LM_BASE_ADDR_LOW4
-#define LM_BASE_ADDR_HIGH 8
-#define LM_END_ADDR_LOW 12
-#define LM_END_ADDR_HIGH16
-#define LM_VRING_STATE_OFFSET 0x20
-
#endif /* VIRTIO_PCI_NO_MODERN */
/* Admin command status. */
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 58014a92ad..24e5e7d347 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -2039,22 +2039,6 @@ static ssize_t virtio_net_receive_rcu(NetClientState
*nc, const uint8_t *buf,
goto err;
}
-/* Mark dirty page's bitmap of guest memory */
-if (vdev->lm_logging_ctrl == LM_ENABLE) {
-uint64_t chunk = elem->in_addr[i] / VHOST_LOG_CHUNK;
-
Re: [PATCH 1/1] virtio-pci: Fix the crash when the vector changes back from VIRTIO_NO_VECTOR
On Sun, Apr 07, 2024 at 12:19:57PM +0800, Jason Wang wrote:
> On Tue, Apr 2, 2024 at 11:02 PM Cindy Lu wrote:
> >
> > When the guest calls virtio_stop and then virtio_reset,
>
> Guests could not call those functions directly, it is triggered by for
> example writing to some of the registers like reset or others.
>
> > the vector will change
> > to VIRTIO_NO_VECTOR and the IRQFD for this vector will be released. After
> > that
> > If you want to change the vector back,
>
> What do you mean by "change the vector back"? Something like
>
> assign VIRTIO_MSI_NO_VECTOR to vector 0
> assign X to vector 0
>
> And I guess what you meant is to configure the vector after DRIVER_OK.
>
>
> > it will cause a crash.
> >
> > To fix this, we need to call the function "kvm_virtio_pci_vector_use_one()"
> > when the vector changes back from VIRTIO_NO_VECTOR
> >
> > Signed-off-by: Cindy Lu
> > ---
> > hw/virtio/virtio-pci.c | 31 ---
> > 1 file changed, 28 insertions(+), 3 deletions(-)
> >
> > diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> > index e433879542..45f3ab38c3 100644
> > --- a/hw/virtio/virtio-pci.c
> > +++ b/hw/virtio/virtio-pci.c
> > @@ -874,12 +874,14 @@ static int virtio_pci_get_notifier(VirtIOPCIProxy
> > *proxy, int queue_no,
> > return 0;
> > }
> >
> > -static int kvm_virtio_pci_vector_use_one(VirtIOPCIProxy *proxy, int
> > queue_no)
> > +static int kvm_virtio_pci_vector_use_one(VirtIOPCIProxy *proxy, int
> > queue_no,
> > + bool recovery)
> > {
> > unsigned int vector;
> > int ret;
> > EventNotifier *n;
> > PCIDevice *dev = >pci_dev;
> > +VirtIOIRQFD *irqfd;
> > VirtIODevice *vdev = virtio_bus_get_device(>bus);
> > VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(vdev);
> >
> > @@ -890,10 +892,21 @@ static int
> > kvm_virtio_pci_vector_use_one(VirtIOPCIProxy *proxy, int queue_no)
> > if (vector >= msix_nr_vectors_allocated(dev)) {
> > return 0;
> > }
> > +/*
> > + * if this is recovery and irqfd still in use, means the irqfd was not
> > + * release before and don't need to set up again
> > + */
> > +if (recovery) {
> > +irqfd = >vector_irqfd[vector];
> > +if (irqfd->users != 0) {
> > +return 0;
> > +}
> > +}
> > ret = kvm_virtio_pci_vq_vector_use(proxy, vector);
> > if (ret < 0) {
> > goto undo;
> > }
> > +
> > /*
> > * If guest supports masking, set up irqfd now.
> > * Otherwise, delay until unmasked in the frontend.
> > @@ -932,14 +945,14 @@ static int
> > kvm_virtio_pci_vector_vq_use(VirtIOPCIProxy *proxy, int nvqs)
> > if (!virtio_queue_get_num(vdev, queue_no)) {
> > return -1;
> > }
> > -ret = kvm_virtio_pci_vector_use_one(proxy, queue_no);
> > +ret = kvm_virtio_pci_vector_use_one(proxy, queue_no, false);
> > }
> > return ret;
> > }
> >
> > static int kvm_virtio_pci_vector_config_use(VirtIOPCIProxy *proxy)
> > {
> > -return kvm_virtio_pci_vector_use_one(proxy, VIRTIO_CONFIG_IRQ_IDX);
> > +return kvm_virtio_pci_vector_use_one(proxy, VIRTIO_CONFIG_IRQ_IDX,
> > false);
> > }
> >
> > static void kvm_virtio_pci_vector_release_one(VirtIOPCIProxy *proxy,
> > @@ -1570,7 +1583,13 @@ static void virtio_pci_common_write(void *opaque,
> > hwaddr addr,
> > } else {
> > val = VIRTIO_NO_VECTOR;
> > }
> > +vector = vdev->config_vector;
> > vdev->config_vector = val;
> > +/*check if the vector need to recovery*/
> > +if ((val != VIRTIO_NO_VECTOR) && (vector == VIRTIO_NO_VECTOR) &&
> > +(vdev->status & VIRTIO_CONFIG_S_DRIVER_OK)) {
> > +kvm_virtio_pci_vector_use_one(proxy, VIRTIO_CONFIG_IRQ_IDX,
> > true);
> > +}
>
> This looks too tricky.
>
> Think hard of this. I think it's better to split this into two parts:
>
> 1) a series that disables config irqfd for vhost-net, this series
> needs to be backported to -stable which needs to be conservative. It
> looks more like your V1, but let's add a boolean for pci proxy.
I don't get it. Looks like a huge change to do in stable.
All as a replacement to a small 20 line patch?
Generally I think irqfd is best used everywhere.
> 2) a series that deal with the msix vector configuration after
> driver_ok, we probably need some refactoring to do per vq use instead
> of the current loop in DRIVER_OK
>
> Does this make sense?
>
> Thanks
Not really let's fix the bug for starters, refactoring can be done later
as appropriate.
> > break;
> > case VIRTIO_PCI_COMMON_STATUS:
> > if (!(val & VIRTIO_CONFIG_S_DRIVER_OK)) {
> > @@ -1611,6 +1630,12 @@ static void virtio_pci_common_write(void *opaque,
> > hwaddr addr,
> > val = VIRTIO_NO_VECTOR;
> > }
> > virtio_queue_set_vector(vdev, vdev->queue_sel, val);
> > +
Re: [RFC QEMU PATCH v8 2/2] virtio-pci: implement No_Soft_Reset bit
On Sun, Apr 07, 2024 at 11:20:57AM +0800, Jason Wang wrote:
> On Tue, Apr 2, 2024 at 11:03 AM Chen, Jiqian wrote:
> >
> > On 2024/3/29 18:44, Michael S. Tsirkin wrote:
> > > On Fri, Mar 29, 2024 at 03:20:59PM +0800, Jason Wang wrote:
> > >> On Fri, Mar 29, 2024 at 3:07 PM Chen, Jiqian wrote:
> > >>>
> > >>> On 2024/3/28 20:36, Michael S. Tsirkin wrote:
> > >>>>>>> +}
> > >>>>>>> +
> > >>>>>>> static void virtio_pci_bus_reset_hold(Object *obj)
> > >>>>>>> {
> > >>>>>>> PCIDevice *dev = PCI_DEVICE(obj);
> > >>>>>>> DeviceState *qdev = DEVICE(obj);
> > >>>>>>>
> > >>>>>>> +if (virtio_pci_no_soft_reset(dev)) {
> > >>>>>>> +return;
> > >>>>>>> +}
> > >>>>>>> +
> > >>>>>>> virtio_pci_reset(qdev);
> > >>>>>>>
> > >>>>>>> if (pci_is_express(dev)) {
> > >>>>>>> @@ -2484,6 +2511,8 @@ static Property virtio_pci_properties[] = {
> > >>>>>>> VIRTIO_PCI_FLAG_INIT_LNKCTL_BIT, true),
> > >>>>>>> DEFINE_PROP_BIT("x-pcie-pm-init", VirtIOPCIProxy, flags,
> > >>>>>>> VIRTIO_PCI_FLAG_INIT_PM_BIT, true),
> > >>>>>>> +DEFINE_PROP_BIT("x-pcie-pm-no-soft-reset", VirtIOPCIProxy,
> > >>>>>>> flags,
> > >>>>>>> +VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET_BIT, false),
> > >>
> > >> Why does it come with an x prefix?
> > >>
> > >>>>>>> DEFINE_PROP_BIT("x-pcie-flr-init", VirtIOPCIProxy, flags,
> > >>>>>>> VIRTIO_PCI_FLAG_INIT_FLR_BIT, true),
> > >>>>>>> DEFINE_PROP_BIT("aer", VirtIOPCIProxy, flags,
> > >>>>>>
> > >>>>>> I am a bit confused about this part.
> > >>>>>> Do you want to make this software controllable?
> > >>>>> Yes, because even the real hardware, this bit is not always set.
> > >>
> > >> We are talking about emulated devices here.
> > >>
> > >>>>
> > >>>> So which virtio devices should and which should not set this bit?
> > >>> This depends on the scenario the virtio-device is used, if we want to
> > >>> trigger an internal soft reset for the virtio-device during S3, this
> > >>> bit shouldn't be set.
> > >>
> > >> If the device doesn't need reset, why bother the driver for this?
> > >>
> > >> Btw, no_soft_reset is insufficient for some cases, there's a proposal
> > >> for the virtio-spec. I think we need to wait until it is done.
> > >
> > > That seems orthogonal or did I miss something?
> > Yes, I looked the detail of the proposal, I also think they are unrelated.
>
> The point is the proposal said
>
> """
> Without a mechanism to
> suspend/resume virtio devices when the driver is suspended/resumed in
> the early phase of suspend/late phase of resume, there is a window where
> interrupts can be lost.
> """
>
> It looks safe to enable it with the suspend bit. Or if you think it's
> wrong, please comment on the virtio spec patch.
>
> > I will set the default value of No_Soft_Reset bit to true in next version
> > according to your opinion.
> > About the compatibility of old machine types, which types should I
> > consider? Does the same as x-pcie-pm-init(hw_compat_2_8)?
> > Forgive me for not knowing much about compatibility.
>
> "x" means no compatibility at all, please drop the "x" prefix. And it
> looks more safe to start as "false" by default.
>
> Thanks
Not sure I agree. External flags are for when users want to tweak them.
When would users want it to be off?
What is done here is I feel sane, just add machine compat machinery
to change to off for old machine types.
> > >
> > >>> In my use case on my environment, I don't want to reset virtio-gpu
> > >>> during S3,
> > >>> because once the display resources are destroyed, there are not enough
> > >>> information to re-create them, so this bit should be set.
> > >>> Making this bit software controllable is convenient for users to take
> > >>> their own choices.
> > >>
> > >> Thanks
> > >>
> > >>>
> > >>>>
> > >>>>>> Or should this be set to true by default and then
> > >>>>>> changed to false for old machine types?
> > >>>>> How can I do so?
> > >>>>> Do you mean set this to true by default, and if old machine types
> > >>>>> don't need this bit, they can pass false config to qemu when running
> > >>>>> qemu?
> > >>>>
> > >>>> No, you would use compat machinery. See how is x-pcie-flr-init handled.
> > >>>>
> > >>>>
> > >>>
> > >>> --
> > >>> Best regards,
> > >>> Jiqian Chen.
> > >
> >
> > --
> > Best regards,
> > Jiqian Chen.
Re: [PATCH v1 0/1] virtio-snd: fix invalid tx/rx message handling logic
On Fri, Apr 05, 2024 at 01:54:46PM +0300, Manos Pitsidianakis wrote: > ping confused at this point. Do you mind sending a patchset with everything in the correct order? Tag it PATCH repost so people know nothing changed. Thanks! -- MST
Re: [PATCH] virtio-iommu: Do not process commands with bad size
On Thu, Apr 04, 2024 at 02:45:05PM +0200, Zheyu Ma wrote:
> The device should not handle the commands which have bad request/reply
> size, it should just report the error instead of raising an assertation.
>
> Signed-off-by: Zheyu Ma
I do not get what problem you are trying to solve here.
Can guest trigger this assert? I do not see how.
> ---
> hw/virtio/virtio-iommu.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/hw/virtio/virtio-iommu.c b/hw/virtio/virtio-iommu.c
> index 1326c6ec41..3a7cdfe777 100644
> --- a/hw/virtio/virtio-iommu.c
> +++ b/hw/virtio/virtio-iommu.c
> @@ -770,8 +770,8 @@ static void virtio_iommu_handle_command(VirtIODevice
> *vdev, VirtQueue *vq)
> return;
> }
>
> -if (iov_size(elem->in_sg, elem->in_num) < sizeof(tail) ||
> -iov_size(elem->out_sg, elem->out_num) < sizeof(head)) {
> +if (iov_size(elem->in_sg, elem->in_num) != sizeof(tail) ||
> +iov_size(elem->out_sg, elem->out_num) != sizeof(head)) {
> virtio_error(vdev, "virtio-iommu bad head/tail size");
> virtqueue_detach_element(vq, elem, 0);
> g_free(elem);
> @@ -818,8 +818,6 @@ static void virtio_iommu_handle_command(VirtIODevice
> *vdev, VirtQueue *vq)
> out:
> sz = iov_from_buf(elem->in_sg, elem->in_num, 0,
>buf ? buf : , output_size);
> -assert(sz == output_size);
> -
> virtqueue_push(vq, elem, sz);
> virtio_notify(vdev, vq);
> g_free(elem);
> @@ -852,7 +850,7 @@ static void virtio_iommu_report_fault(VirtIOIOMMU
> *viommu, uint8_t reason,
> return;
> }
>
> -if (iov_size(elem->in_sg, elem->in_num) < sizeof(fault)) {
> +if (iov_size(elem->in_sg, elem->in_num) != sizeof(fault)) {
> virtio_error(vdev, "error buffer of wrong size");
> virtqueue_detach_element(vq, elem, 0);
> g_free(elem);
> @@ -861,8 +859,6 @@ static void virtio_iommu_report_fault(VirtIOIOMMU
> *viommu, uint8_t reason,
>
> sz = iov_from_buf(elem->in_sg, elem->in_num, 0,
>, sizeof(fault));
> -assert(sz == sizeof(fault));
> -
> trace_virtio_iommu_report_fault(reason, flags, endpoint, address);
> virtqueue_push(vq, elem, sz);
> virtio_notify(vdev, vq);
> --
> 2.34.1
Re: [PATCH] hw/virtio: Fix packed virtqueue flush used_idx
On Wed, Mar 27, 2024 at 02:15:18PM +0800, Wafer wrote:
> For indirect descriptors the elelm->ndescs was one,
> For direct descriptors the elele->ndesc was the numbe of entries.
> elem->ndescs = (desc_cache == _desc_cache) ? 1 : elem_entries;
>
> When flushing multiple elemes,
> the used_idx should be added to all the privious numeric entry value.
>
> Signed-off-by: Wafer
Thanks for the patch.
It's kind of hard to figure out what you are trying to say
with all the typos and grammar errors in the commit log.
What's up with that?
Please describe the following in the commit log:
- current behaviour is abc
- this is wrong because the virtio spec says def
- as a result we observed guest doing pqr and then stu
- to fix do ghi
- with this fix the guest does xyz as expected
- tested by klm
Also I think you might want to add:
Fixes: 86044b24e8 ("virtio: basic packed virtqueue support")
Cc: "Jason Wang"
> ---
> hw/virtio/virtio.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> index d229755eae..44f1d2fcfc 100644
> --- a/hw/virtio/virtio.c
> +++ b/hw/virtio/virtio.c
> @@ -957,12 +957,17 @@ static void virtqueue_packed_flush(VirtQueue *vq,
> unsigned int count)
> return;
> }
>
> +/*
> + * When the descriptor's flag was 'INDIRECT', the value of 'ndescs' is
> one.
> + * When the descriptor's flag was 'chain', the value of 'ndescs'
> + * is the number of entries.
> + */
There's no such thing as "the flag" - descriptors do have a "flags" field
though. And there's no 'chain' value either.
maybe just "
For indirect elems, ndescs is 1. For all other elems, ndescs is the
number of descriptors chained by NEXT (as set in virtqueue_packed_pop).
> +ndescs += vq->used_elems[0].ndescs;
> for (i = 1; i < count; i++) {
> -virtqueue_packed_fill_desc(vq, >used_elems[i], i, false);
> +virtqueue_packed_fill_desc(vq, >used_elems[i], ndescs, false);
> ndescs += vq->used_elems[i].ndescs;
> }
> virtqueue_packed_fill_desc(vq, >used_elems[0], 0, true);
> -ndescs += vq->used_elems[0].ndescs;
>
> vq->inuse -= ndescs;
> vq->used_idx += ndescs;
The patch itself seems correct to me.
> --
> 2.27.0
Re: [PATCH] hw/i386/acpi: Set PCAT_COMPAT bit only when pic is not disabled
On Tue, Apr 02, 2024 at 09:18:44PM +0800, Xiaoyao Li wrote:
> On 4/2/2024 6:02 PM, Michael S. Tsirkin wrote:
> > On Tue, Apr 02, 2024 at 04:25:16AM -0400, Xiaoyao Li wrote:
> > > Set MADT.FLAGS[bit 0].PCAT_COMPAT based on x86ms->pic.
> > >
> > > Signed-off-by: Xiaoyao Li
> >
> > Please include more info in the commit log:
> > what is the behaviour you observe, why it is wrong,
> > how does the patch fix it, what is guest behaviour
> > before and after.
>
> Sorry, I thought it was straightforward.
>
> A value 1 of PCAT_COMPAT (bit 0) of MADT.Flags indicates that the system
> also has a PC-AT-compatible dual-8259 setup, i.e., the PIC.
>
> When PIC is not enabled for x86 machine, the PCAT_COMPAT bit needs to be
> cleared. Otherwise, the guest thinks there is a present PIC even it is
> booted with pic=off on QEMU.
>
> (I haven't seen real issue from Linux guest. The user of PIC inside guest
> seems only the pit calibration. Whether pit calibration is triggered depends
> on other things. But logically, current code is wrong, we need to fix it
> anyway.
>
> @Isaku, please share more info if you have)
>
That's sufficient, thanks! Pls put this in commit log and resubmit.
> > The commit log and the subject should not repeat
> > what the diff already states.
> >
> > > ---
> > > hw/i386/acpi-common.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/hw/i386/acpi-common.c b/hw/i386/acpi-common.c
> > > index 20f19269da40..0cc2919bb851 100644
> > > --- a/hw/i386/acpi-common.c
> > > +++ b/hw/i386/acpi-common.c
> > > @@ -107,7 +107,9 @@ void acpi_build_madt(GArray *table_data, BIOSLinker
> > > *linker,
> > > acpi_table_begin(, table_data);
> > > /* Local APIC Address */
> > > build_append_int_noprefix(table_data, APIC_DEFAULT_ADDRESS, 4);
> > > -build_append_int_noprefix(table_data, 1 /* PCAT_COMPAT */, 4); /*
> > > Flags */
> > > +/* Flags. bit 0: PCAT_COMPAT */
> > > +build_append_int_noprefix(table_data,
> > > + x86ms->pic != ON_OFF_AUTO_OFF ? 1 : 0 , 4);
> > > for (i = 0; i < apic_ids->len; i++) {
> > > pc_madt_cpu_entry(i, apic_ids, table_data, false);
> > > --
> > > 2.34.1
> >
Re: [PATCH] hw/i386/acpi: Set PCAT_COMPAT bit only when pic is not disabled
On Tue, Apr 02, 2024 at 04:25:16AM -0400, Xiaoyao Li wrote:
> Set MADT.FLAGS[bit 0].PCAT_COMPAT based on x86ms->pic.
>
> Signed-off-by: Xiaoyao Li
Please include more info in the commit log:
what is the behaviour you observe, why it is wrong,
how does the patch fix it, what is guest behaviour
before and after.
The commit log and the subject should not repeat
what the diff already states.
> ---
> hw/i386/acpi-common.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/hw/i386/acpi-common.c b/hw/i386/acpi-common.c
> index 20f19269da40..0cc2919bb851 100644
> --- a/hw/i386/acpi-common.c
> +++ b/hw/i386/acpi-common.c
> @@ -107,7 +107,9 @@ void acpi_build_madt(GArray *table_data, BIOSLinker
> *linker,
> acpi_table_begin(, table_data);
> /* Local APIC Address */
> build_append_int_noprefix(table_data, APIC_DEFAULT_ADDRESS, 4);
> -build_append_int_noprefix(table_data, 1 /* PCAT_COMPAT */, 4); /* Flags
> */
> +/* Flags. bit 0: PCAT_COMPAT */
> +build_append_int_noprefix(table_data,
> + x86ms->pic != ON_OFF_AUTO_OFF ? 1 : 0 , 4);
>
> for (i = 0; i < apic_ids->len; i++) {
> pc_madt_cpu_entry(i, apic_ids, table_data, false);
> --
> 2.34.1
Re: [PATCH] virtio-net: fix qemu set used ring flag even vhost started
On Tue, Apr 02, 2024 at 12:51:09PM +0800, Yajun Wu wrote:
> When vhost-user or vhost-kernel is handling virtio net datapath, qemu
> should not touch used ring.
>
> But with vhost-user socket reconnect scenario, in a very rare case (has
> pending kick event). VRING_USED_F_NO_NOTIFY is set by qemu in
> following code path:
>
> #0 virtio_queue_split_set_notification (vq=0x7ff5f4c920a8, enable=0)
> at ../hw/virtio/virtio.c:511
> #1 0x559d6dbf033b in virtio_queue_set_notification
> (vq=0x7ff5f4c920a8, enable=0) at ../hw/virtio/virtio.c:576
> #2 0x559d6dbbbdbc in virtio_net_handle_tx_bh (vdev=0x559d703a6aa0,
> vq=0x7ff5f4c920a8) at ../hw/net/virtio-net.c:2801
> #3 0x559d6dbf4791 in virtio_queue_notify_vq (vq=0x7ff5f4c920a8) at
> ../hw/virtio/virtio.c:2248
> #4 0x559d6dbf79da in virtio_queue_host_notifier_read
> (n=0x7ff5f4c9211c) at ../hw/virtio/virtio.c:3525
> #5 0x559d6d9a5814 in virtio_bus_cleanup_host_notifier
> (bus=0x559d703a6a20, n=1) at ../hw/virtio/virtio-bus.c:321
> #6 0x559d6dbf83c9 in virtio_device_stop_ioeventfd_impl
> (vdev=0x559d703a6aa0) at ../hw/virtio/virtio.c:3774
> #7 0x559d6d9a55c8 in virtio_bus_stop_ioeventfd
> (bus=0x559d703a6a20) at ../hw/virtio/virtio-bus.c:259
> #8 0x559d6d9a53e8 in virtio_bus_grab_ioeventfd
> (bus=0x559d703a6a20) at ../hw/virtio/virtio-bus.c:199
> #9 0x559d6dbf841c in virtio_device_grab_ioeventfd
> (vdev=0x559d703a6aa0) at ../hw/virtio/virtio.c:3783
> #10 0x559d6d9bde18 in vhost_dev_enable_notifiers
> (hdev=0x559d707edd70, vdev=0x559d703a6aa0) at ../hw/virtio/vhost.c:1592
> #11 0x559d6d89a0b8 in vhost_net_start_one (net=0x559d707edd70,
> dev=0x559d703a6aa0) at ../hw/net/vhost_net.c:266
> #12 0x559d6d89a6df in vhost_net_start (dev=0x559d703a6aa0,
> ncs=0x559d7048d890, data_queue_pairs=31, cvq=0) at ../hw/net/vhost_net.c:412
> #13 0x559d6dbb5b89 in virtio_net_vhost_status (n=0x559d703a6aa0,
> status=15 '\017') at ../hw/net/virtio-net.c:311
> #14 0x559d6dbb5e34 in virtio_net_set_status (vdev=0x559d703a6aa0,
> status=15 '\017') at ../hw/net/virtio-net.c:392
> #15 0x559d6dbb60d8 in virtio_net_set_link_status
> (nc=0x559d7048d890) at ../hw/net/virtio-net.c:455
> #16 0x559d6da64863 in qmp_set_link (name=0x559d6f0b83d0 "hostnet1",
> up=true, errp=0x7ffdd76569f0) at ../net/net.c:1459
> #17 0x559d6da7226e in net_vhost_user_event (opaque=0x559d6f0b83d0,
> event=CHR_EVENT_OPENED) at ../net/vhost-user.c:301
> #18 0x559d6ddc7f63 in chr_be_event (s=0x559d6f2ffea0,
> event=CHR_EVENT_OPENED) at ../chardev/char.c:62
> #19 0x559d6ddc7fdc in qemu_chr_be_event (s=0x559d6f2ffea0,
> event=CHR_EVENT_OPENED) at ../chardev/char.c:82
>
> This issue causes guest kernel stop kicking device and traffic stop.
>
> Add vhost_started check in virtio_net_handle_tx_bh to fix this wrong
> VRING_USED_F_NO_NOTIFY set.
>
> Signed-off-by: Yajun Wu
> Reviewed-by: Jiri Pirko
Acked-by: Michael S. Tsirkin
> ---
> hw/net/virtio-net.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index a6ff000cd9..8035e01fdf 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -2865,6 +2865,10 @@ static void virtio_net_handle_tx_bh(VirtIODevice
> *vdev, VirtQueue *vq)
> VirtIONet *n = VIRTIO_NET(vdev);
> VirtIONetQueue *q = >vqs[vq2q(virtio_get_queue_index(vq))];
>
> +if (n->vhost_started) {
> +return;
> +}
> +
> if (unlikely((n->status & VIRTIO_NET_S_LINK_UP) == 0)) {
> virtio_net_drop_tx_queue_data(vdev, vq);
> return;
> --
> 2.27.0
Re: vhost-user-blk reconnect issue
On Mon, Apr 01, 2024 at 10:08:10AM +0800, Yajun Wu wrote: > > On 3/27/2024 6:47 PM, Stefano Garzarella wrote: > > External email: Use caution opening links or attachments > > > > > > Hi Yajun, > > > > On Mon, Mar 25, 2024 at 10:54:13AM +, Yajun Wu wrote: > > > Hi experts, > > > > > > With latest QEMU (8.2.90), we find two vhost-user-blk backend reconnect > > > failure scenarios: > > Do you know if has it ever worked and so it's a regression, or have we > > always had this problem? > > I am afraid this commit: "71e076a07d (2022-12-01 02:30:13 -0500) hw/virtio: > generalise CHR_EVENT_CLOSED handling" caused both failures. Previous hash > is good. CC Alex who wrote that commit. > I suspect the "if (vhost->vdev)" in vhost_user_async_close_bh is the cause, > previous code doesn't have this check? > > > > > Thanks, > > Stefano > > > > > 1. Disconnect vhost-user-blk backend before guest driver probe vblk > > > device, then reconnect backend after guest driver probe device. QEMU > > > won't send out any vhost messages to restore backend. > > > This is because vhost->vdev is NULL before guest driver probe vblk > > > device, so vhost_user_blk_disconnect won't be called, s->connected is > > > still true. Next vhost_user_blk_connect will simply return without doing > > > anything. > > > > > > 2. modprobe -r virtio-blk inside VM, then disconnect backend, then > > > reconnect backend, then modprobe virtio-blk. QEMU won't send messages in > > > vhost_dev_init. > > > This is because rmmod will let qemu call vhost_user_blk_stop, vhost->vdev > > > also become NULL(in vhost_dev_stop), vhost_user_blk_disconnect won't be > > > called. Again s->connected is still true, even chr connect is closed. > > > > > > I think even vhost->vdev is NULL, vhost_user_blk_disconnect should be > > > called when chr connect close? > > > Hope we can have a fix soon. > > > > > > > > > Thanks, > > > Yajun > > >
Re: [PATCH net v3] virtio_net: Do not send RSS key if it is not supported
On Fri, Mar 29, 2024 at 10:16:41AM -0700, Breno Leitao wrote:
> There is a bug when setting the RSS options in virtio_net that can break
> the whole machine, getting the kernel into an infinite loop.
>
> Running the following command in any QEMU virtual machine with virtionet
> will reproduce this problem:
>
> # ethtool -X eth0 hfunc toeplitz
>
> This is how the problem happens:
>
> 1) ethtool_set_rxfh() calls virtnet_set_rxfh()
>
> 2) virtnet_set_rxfh() calls virtnet_commit_rss_command()
>
> 3) virtnet_commit_rss_command() populates 4 entries for the rss
> scatter-gather
>
> 4) Since the command above does not have a key, then the last
> scatter-gatter entry will be zeroed, since rss_key_size == 0.
> sg_buf_size = vi->rss_key_size;
>
> 5) This buffer is passed to qemu, but qemu is not happy with a buffer
> with zero length, and do the following in virtqueue_map_desc() (QEMU
> function):
>
> if (!sz) {
> virtio_error(vdev, "virtio: zero sized buffers are not allowed");
>
> 6) virtio_error() (also QEMU function) set the device as broken
>
> vdev->broken = true;
>
> 7) Qemu bails out, and do not repond this crazy kernel.
>
> 8) The kernel is waiting for the response to come back (function
> virtnet_send_command())
>
> 9) The kernel is waiting doing the following :
>
> while (!virtqueue_get_buf(vi->cvq, ) &&
>!virtqueue_is_broken(vi->cvq))
> cpu_relax();
>
> 10) None of the following functions above is true, thus, the kernel
> loops here forever. Keeping in mind that virtqueue_is_broken() does
> not look at the qemu `vdev->broken`, so, it never realizes that the
> vitio is broken at QEMU side.
>
> Fix it by not sending RSS commands if the feature is not available in
> the device.
>
> Fixes: c7114b1249fa ("drivers/net/virtio_net: Added basic RSS support.")
> Cc: sta...@vger.kernel.org
net has its own stable process, don't CC stable on net patches.
> Cc: qemu-devel@nongnu.org
> Signed-off-by: Breno Leitao
> ---
> Changelog:
>
> V2:
> * Moved from creating a valid packet, by rejecting the request
> completely
> V3:
> * Got some good feedback from and Xuan Zhuo and Heng Qi, and reworked
> the rejection path.
>
> ---
> drivers/net/virtio_net.c | 22 ++
> 1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index c22d1118a133..c4a21ec51adf 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -3807,6 +3807,7 @@ static int virtnet_set_rxfh(struct net_device *dev,
> struct netlink_ext_ack *extack)
> {
> struct virtnet_info *vi = netdev_priv(dev);
> + bool update = false;
> int i;
>
> if (rxfh->hfunc != ETH_RSS_HASH_NO_CHANGE &&
> @@ -3814,13 +3815,24 @@ static int virtnet_set_rxfh(struct net_device *dev,
> return -EOPNOTSUPP;
>
> if (rxfh->indir) {
> + if (!vi->has_rss)
> + return -EOPNOTSUPP;
> +
> for (i = 0; i < vi->rss_indir_table_size; ++i)
> vi->ctrl->rss.indirection_table[i] = rxfh->indir[i];
> + update = true;
> }
> - if (rxfh->key)
> +
> + if (rxfh->key) {
> + if (!vi->has_rss && !vi->has_rss_hash_report)
> + return -EOPNOTSUPP;
What's the logic here? Is it || or &&? A comment can't hurt.
> +
> memcpy(vi->ctrl->rss.key, rxfh->key, vi->rss_key_size);
> + update = true;
> + }
>
> - virtnet_commit_rss_command(vi);
> + if (update)
> + virtnet_commit_rss_command(vi);
>
> return 0;
> }
> @@ -4729,13 +4741,15 @@ static int virtnet_probe(struct virtio_device *vdev)
> if (virtio_has_feature(vdev, VIRTIO_NET_F_HASH_REPORT))
> vi->has_rss_hash_report = true;
>
> - if (virtio_has_feature(vdev, VIRTIO_NET_F_RSS))
> + if (virtio_has_feature(vdev, VIRTIO_NET_F_RSS)) {
> vi->has_rss = true;
>
> - if (vi->has_rss || vi->has_rss_hash_report) {
> vi->rss_indir_table_size =
> virtio_cread16(vdev, offsetof(struct virtio_net_config,
> rss_max_indirection_table_length));
> + }
> +
> + if (vi->has_rss || vi->has_rss_hash_report) {
> vi->rss_key_size =
> virtio_cread8(vdev, offsetof(struct virtio_net_config,
> rss_max_key_size));
>
> --
> 2.43.0
Re: [RFC QEMU PATCH v8 2/2] virtio-pci: implement No_Soft_Reset bit
On Fri, Mar 29, 2024 at 03:20:59PM +0800, Jason Wang wrote:
> On Fri, Mar 29, 2024 at 3:07 PM Chen, Jiqian wrote:
> >
> > On 2024/3/28 20:36, Michael S. Tsirkin wrote:
> > >>>> +}
> > >>>> +
> > >>>> static void virtio_pci_bus_reset_hold(Object *obj)
> > >>>> {
> > >>>> PCIDevice *dev = PCI_DEVICE(obj);
> > >>>> DeviceState *qdev = DEVICE(obj);
> > >>>>
> > >>>> +if (virtio_pci_no_soft_reset(dev)) {
> > >>>> +return;
> > >>>> +}
> > >>>> +
> > >>>> virtio_pci_reset(qdev);
> > >>>>
> > >>>> if (pci_is_express(dev)) {
> > >>>> @@ -2484,6 +2511,8 @@ static Property virtio_pci_properties[] = {
> > >>>> VIRTIO_PCI_FLAG_INIT_LNKCTL_BIT, true),
> > >>>> DEFINE_PROP_BIT("x-pcie-pm-init", VirtIOPCIProxy, flags,
> > >>>> VIRTIO_PCI_FLAG_INIT_PM_BIT, true),
> > >>>> +DEFINE_PROP_BIT("x-pcie-pm-no-soft-reset", VirtIOPCIProxy, flags,
> > >>>> +VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET_BIT, false),
>
> Why does it come with an x prefix?
>
> > >>>> DEFINE_PROP_BIT("x-pcie-flr-init", VirtIOPCIProxy, flags,
> > >>>> VIRTIO_PCI_FLAG_INIT_FLR_BIT, true),
> > >>>> DEFINE_PROP_BIT("aer", VirtIOPCIProxy, flags,
> > >>>
> > >>> I am a bit confused about this part.
> > >>> Do you want to make this software controllable?
> > >> Yes, because even the real hardware, this bit is not always set.
>
> We are talking about emulated devices here.
>
> > >
> > > So which virtio devices should and which should not set this bit?
> > This depends on the scenario the virtio-device is used, if we want to
> > trigger an internal soft reset for the virtio-device during S3, this bit
> > shouldn't be set.
>
> If the device doesn't need reset, why bother the driver for this?
>
> Btw, no_soft_reset is insufficient for some cases, there's a proposal
> for the virtio-spec. I think we need to wait until it is done.
That seems orthogonal or did I miss something?
> > In my use case on my environment, I don't want to reset virtio-gpu during
> > S3,
> > because once the display resources are destroyed, there are not enough
> > information to re-create them, so this bit should be set.
> > Making this bit software controllable is convenient for users to take their
> > own choices.
>
> Thanks
>
> >
> > >
> > >>> Or should this be set to true by default and then
> > >>> changed to false for old machine types?
> > >> How can I do so?
> > >> Do you mean set this to true by default, and if old machine types don't
> > >> need this bit, they can pass false config to qemu when running qemu?
> > >
> > > No, you would use compat machinery. See how is x-pcie-flr-init handled.
> > >
> > >
> >
> > --
> > Best regards,
> > Jiqian Chen.
Re: [PATCH-for-9.1 v2 0/3] rdma: Remove RDMA subsystem and pvrdma device
On Thu, Mar 28, 2024 at 02:02:52PM +0100, Philippe Mathieu-Daudé wrote: > Since v1: > - split in 3 (Thomas) > - justify gluster removal Reviewed-by: Michael S. Tsirkin > Philippe Mathieu-Daudé (3): > hw/rdma: Remove pvrdma device and rdmacm-mux helper > migration: Remove RDMA protocol handling > block/gluster: Remove RDMA protocol handling > > MAINTAINERS | 17 - > docs/about/deprecated.rst |9 - > docs/about/removed-features.rst |4 + > docs/devel/migration/main.rst |6 - > docs/pvrdma.txt | 345 -- > docs/rdma.txt | 420 -- > docs/system/device-url-syntax.rst.inc |4 +- > docs/system/loongarch/virt.rst|2 +- > docs/system/qemu-block-drivers.rst.inc|1 - > meson.build | 59 - > qapi/machine.json | 17 - > qapi/migration.json | 31 +- > qapi/qapi-schema.json |1 - > qapi/rdma.json| 38 - > contrib/rdmacm-mux/rdmacm-mux.h | 61 - > hw/rdma/rdma_backend.h| 129 - > hw/rdma/rdma_backend_defs.h | 76 - > hw/rdma/rdma_rm.h | 97 - > hw/rdma/rdma_rm_defs.h| 146 - > hw/rdma/rdma_utils.h | 63 - > hw/rdma/trace.h |1 - > hw/rdma/vmw/pvrdma.h | 144 - > hw/rdma/vmw/pvrdma_dev_ring.h | 46 - > hw/rdma/vmw/pvrdma_qp_ops.h | 28 - > hw/rdma/vmw/trace.h |1 - > include/hw/rdma/rdma.h| 37 - > include/monitor/hmp.h |1 - > .../infiniband/hw/vmw_pvrdma/pvrdma_dev_api.h | 685 --- > .../infiniband/hw/vmw_pvrdma/pvrdma_verbs.h | 348 -- > .../standard-headers/rdma/vmw_pvrdma-abi.h| 310 -- > migration/migration-stats.h |6 +- > migration/migration.h |9 - > migration/options.h |2 - > migration/rdma.h | 69 - > block/gluster.c | 39 - > contrib/rdmacm-mux/main.c | 831 > hw/core/machine-qmp-cmds.c| 32 - > hw/rdma/rdma.c| 30 - > hw/rdma/rdma_backend.c| 1401 -- > hw/rdma/rdma_rm.c | 812 > hw/rdma/rdma_utils.c | 126 - > hw/rdma/vmw/pvrdma_cmd.c | 815 > hw/rdma/vmw/pvrdma_dev_ring.c | 141 - > hw/rdma/vmw/pvrdma_main.c | 735 --- > hw/rdma/vmw/pvrdma_qp_ops.c | 298 -- > migration/migration-stats.c |5 +- > migration/migration.c | 31 - > migration/options.c | 16 - > migration/qemu-file.c |1 - > migration/ram.c | 86 +- > migration/rdma.c | 4184 - > migration/savevm.c|2 +- > monitor/qmp-cmds.c|1 - > Kconfig.host |3 - > contrib/rdmacm-mux/meson.build|7 - > hmp-commands-info.hx | 13 - > hw/Kconfig|1 - > hw/meson.build|1 - > hw/rdma/Kconfig |3 - > hw/rdma/meson.build | 12 - > hw/rdma/trace-events | 31 - > hw/rdma/vmw/trace-events | 17 - > meson_options.txt |4 - > migration/meson.build |1 - > migration/trace-events| 68 +- > qapi/meson.build |1 - > qemu-options.hx |6 - > .../org.centos/stream/8/build-environment.yml |1 - > .../ci/org.centos/stream/8/x86_64/configure |3 - > scripts/ci/setup/build-environment.yml|4 - > scripts/coverity-scan/run-coverity-scan |2 +- > scripts/meson-buildoptions.sh |6 - > scripts/update-linux-headers.sh | 27 - > tests/lcitool/projects/qemu.yml |3 - > tests/migration/guestperf/engine.py |
Re: [RFC QEMU PATCH v8 2/2] virtio-pci: implement No_Soft_Reset bit
On Thu, Mar 28, 2024 at 11:08:58AM +, Chen, Jiqian wrote:
> On 2024/3/28 18:57, Michael S. Tsirkin wrote:
> > On Thu, Mar 28, 2024 at 06:39:03PM +0800, Jiqian Chen wrote:
> >> In current code, when guest does S3, virtio devices are reset due to
> >> the bit No_Soft_Reset is not set. After resetting, the display resources
> >> of virtio-gpu are destroyed, then the display can't come back and only
> >> show blank after resuming.
> >>
> >> Implement No_Soft_Reset bit of PCI_PM_CTRL register, then guest can check
> >> this bit, if this bit is set, the devices resetting will not be done, and
> >> then the display can work after resuming.
> >>
> >> Signed-off-by: Jiqian Chen
> >> ---
> >> hw/virtio/virtio-pci.c | 29 +
> >> include/hw/virtio/virtio-pci.h | 5 +
> >> 2 files changed, 34 insertions(+)
> >>
> >> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> >> index 05dd03758d9f..8d9fab855c7d 100644
> >> --- a/hw/virtio/virtio-pci.c
> >> +++ b/hw/virtio/virtio-pci.c
> >> @@ -2378,6 +2378,11 @@ static void virtio_pci_realize(PCIDevice *pci_dev,
> >> Error **errp)
> >> pcie_cap_lnkctl_init(pci_dev);
> >> }
> >>
> >> +if (proxy->flags & VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET) {
> >> +pci_set_word(pci_dev->config + pos + PCI_PM_CTRL,
> >> + PCI_PM_CTRL_NO_SOFT_RESET);
> >> +}
> >> +
> >> if (proxy->flags & VIRTIO_PCI_FLAG_INIT_PM) {
> >> /* Init Power Management Control Register */
> >> pci_set_word(pci_dev->wmask + pos + PCI_PM_CTRL,
> >> @@ -2440,11 +2445,33 @@ static void virtio_pci_reset(DeviceState *qdev)
> >> }
> >> }
> >>
> >> +static bool virtio_pci_no_soft_reset(PCIDevice *dev)
> >> +{
> >> +uint16_t pmcsr;
> >> +
> >> +if (!pci_is_express(dev) || !dev->exp.pm_cap) {
> >> +return false;
> >> +}
> >> +
> >> +pmcsr = pci_get_word(dev->config + dev->exp.pm_cap + PCI_PM_CTRL);
> >> +
> >> +/*
> >> + * When No_Soft_Reset bit is set and the device
> >> + * is in D3hot state, don't reset device
> >> + */
> >> +return ((pmcsr & PCI_PM_CTRL_NO_SOFT_RESET) &&
> >> +(pmcsr & PCI_PM_CTRL_STATE_MASK) == 3);
> >
> >
> > No need for () around return value.
> Ok, will delete in next version.
>
> >
> >> +}
> >> +
> >> static void virtio_pci_bus_reset_hold(Object *obj)
> >> {
> >> PCIDevice *dev = PCI_DEVICE(obj);
> >> DeviceState *qdev = DEVICE(obj);
> >>
> >> +if (virtio_pci_no_soft_reset(dev)) {
> >> +return;
> >> +}
> >> +
> >> virtio_pci_reset(qdev);
> >>
> >> if (pci_is_express(dev)) {
> >> @@ -2484,6 +2511,8 @@ static Property virtio_pci_properties[] = {
> >> VIRTIO_PCI_FLAG_INIT_LNKCTL_BIT, true),
> >> DEFINE_PROP_BIT("x-pcie-pm-init", VirtIOPCIProxy, flags,
> >> VIRTIO_PCI_FLAG_INIT_PM_BIT, true),
> >> +DEFINE_PROP_BIT("x-pcie-pm-no-soft-reset", VirtIOPCIProxy, flags,
> >> +VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET_BIT, false),
> >> DEFINE_PROP_BIT("x-pcie-flr-init", VirtIOPCIProxy, flags,
> >> VIRTIO_PCI_FLAG_INIT_FLR_BIT, true),
> >> DEFINE_PROP_BIT("aer", VirtIOPCIProxy, flags,
> >
> > I am a bit confused about this part.
> > Do you want to make this software controllable?
> Yes, because even the real hardware, this bit is not always set.
So which virtio devices should and which should not set this bit?
> > Or should this be set to true by default and then
> > changed to false for old machine types?
> How can I do so?
> Do you mean set this to true by default, and if old machine types don't need
> this bit, they can pass false config to qemu when running qemu?
No, you would use compat machinery. See how is x-pcie-flr-init handled.
> >
> >
> >> diff --git a/include/hw/virtio/virtio-pci.h
> >> b/include/hw/virtio/virtio-pci.h
> >> index 4d57a9c75130..c758eb738234 100644
> >> --- a/include/hw/virtio/virtio-pci.h
> >> +++ b/include/hw/virtio/virtio-pci.h
> >> @@ -44,6 +44,7 @@ enum {
> >> VIRTIO_PCI_FLAG_AER_BIT,
> >> VIRTIO_PCI_FLAG_ATS_PAGE_ALIGNED_BIT,
> >> VIRTIO_PCI_FLAG_VDPA_BIT,
> >> +VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET_BIT,
> >> };
> >>
> >> /* Need to activate work-arounds for buggy guests at vmstate load. */
> >> @@ -80,6 +81,10 @@ enum {
> >> /* Init Power Management */
> >> #define VIRTIO_PCI_FLAG_INIT_PM (1 << VIRTIO_PCI_FLAG_INIT_PM_BIT)
> >>
> >> +/* Init The No_Soft_Reset bit of Power Management */
> >> +#define VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET \
> >> + (1 << VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET_BIT)
> >> +
> >> /* Init Function Level Reset capability */
> >> #define VIRTIO_PCI_FLAG_INIT_FLR (1 << VIRTIO_PCI_FLAG_INIT_FLR_BIT)
> >>
> >> --
> >> 2.34.1
> >
>
> --
> Best regards,
> Jiqian Chen.
Re: [RFC QEMU PATCH v8 2/2] virtio-pci: implement No_Soft_Reset bit
On Thu, Mar 28, 2024 at 06:39:03PM +0800, Jiqian Chen wrote:
> In current code, when guest does S3, virtio devices are reset due to
> the bit No_Soft_Reset is not set. After resetting, the display resources
> of virtio-gpu are destroyed, then the display can't come back and only
> show blank after resuming.
>
> Implement No_Soft_Reset bit of PCI_PM_CTRL register, then guest can check
> this bit, if this bit is set, the devices resetting will not be done, and
> then the display can work after resuming.
>
> Signed-off-by: Jiqian Chen
> ---
> hw/virtio/virtio-pci.c | 29 +
> include/hw/virtio/virtio-pci.h | 5 +
> 2 files changed, 34 insertions(+)
>
> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> index 05dd03758d9f..8d9fab855c7d 100644
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
> @@ -2378,6 +2378,11 @@ static void virtio_pci_realize(PCIDevice *pci_dev,
> Error **errp)
> pcie_cap_lnkctl_init(pci_dev);
> }
>
> +if (proxy->flags & VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET) {
> +pci_set_word(pci_dev->config + pos + PCI_PM_CTRL,
> + PCI_PM_CTRL_NO_SOFT_RESET);
> +}
> +
> if (proxy->flags & VIRTIO_PCI_FLAG_INIT_PM) {
> /* Init Power Management Control Register */
> pci_set_word(pci_dev->wmask + pos + PCI_PM_CTRL,
> @@ -2440,11 +2445,33 @@ static void virtio_pci_reset(DeviceState *qdev)
> }
> }
>
> +static bool virtio_pci_no_soft_reset(PCIDevice *dev)
> +{
> +uint16_t pmcsr;
> +
> +if (!pci_is_express(dev) || !dev->exp.pm_cap) {
> +return false;
> +}
> +
> +pmcsr = pci_get_word(dev->config + dev->exp.pm_cap + PCI_PM_CTRL);
> +
> +/*
> + * When No_Soft_Reset bit is set and the device
> + * is in D3hot state, don't reset device
> + */
> +return ((pmcsr & PCI_PM_CTRL_NO_SOFT_RESET) &&
> +(pmcsr & PCI_PM_CTRL_STATE_MASK) == 3);
No need for () around return value.
> +}
> +
> static void virtio_pci_bus_reset_hold(Object *obj)
> {
> PCIDevice *dev = PCI_DEVICE(obj);
> DeviceState *qdev = DEVICE(obj);
>
> +if (virtio_pci_no_soft_reset(dev)) {
> +return;
> +}
> +
> virtio_pci_reset(qdev);
>
> if (pci_is_express(dev)) {
> @@ -2484,6 +2511,8 @@ static Property virtio_pci_properties[] = {
> VIRTIO_PCI_FLAG_INIT_LNKCTL_BIT, true),
> DEFINE_PROP_BIT("x-pcie-pm-init", VirtIOPCIProxy, flags,
> VIRTIO_PCI_FLAG_INIT_PM_BIT, true),
> +DEFINE_PROP_BIT("x-pcie-pm-no-soft-reset", VirtIOPCIProxy, flags,
> +VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET_BIT, false),
> DEFINE_PROP_BIT("x-pcie-flr-init", VirtIOPCIProxy, flags,
> VIRTIO_PCI_FLAG_INIT_FLR_BIT, true),
> DEFINE_PROP_BIT("aer", VirtIOPCIProxy, flags,
I am a bit confused about this part.
Do you want to make this software controllable?
Or should this be set to true by default and then
changed to false for old machine types?
> diff --git a/include/hw/virtio/virtio-pci.h b/include/hw/virtio/virtio-pci.h
> index 4d57a9c75130..c758eb738234 100644
> --- a/include/hw/virtio/virtio-pci.h
> +++ b/include/hw/virtio/virtio-pci.h
> @@ -44,6 +44,7 @@ enum {
> VIRTIO_PCI_FLAG_AER_BIT,
> VIRTIO_PCI_FLAG_ATS_PAGE_ALIGNED_BIT,
> VIRTIO_PCI_FLAG_VDPA_BIT,
> +VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET_BIT,
> };
>
> /* Need to activate work-arounds for buggy guests at vmstate load. */
> @@ -80,6 +81,10 @@ enum {
> /* Init Power Management */
> #define VIRTIO_PCI_FLAG_INIT_PM (1 << VIRTIO_PCI_FLAG_INIT_PM_BIT)
>
> +/* Init The No_Soft_Reset bit of Power Management */
> +#define VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET \
> + (1 << VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET_BIT)
> +
> /* Init Function Level Reset capability */
> #define VIRTIO_PCI_FLAG_INIT_FLR (1 << VIRTIO_PCI_FLAG_INIT_FLR_BIT)
>
> --
> 2.34.1
Re: [PATCH-for-9.1] rdma: Remove RDMA subsystem and pvrdma device
On Thu, Mar 28, 2024 at 07:43:06AM +0100, Thomas Huth wrote:
> On 27/03/2024 11.55, Philippe Mathieu-Daudé wrote:
> > The whole RDMA subsystem was deprecated in commit e9a54265f5
> > ("hw/rdma: Deprecate the pvrdma device and the rdma subsystem")
> > released in v8.2. Time to remove it.
> >
> > Keep the RAM_SAVE_FLAG_HOOK definition since it might appears
> > in old migration streams.
> >
> > Remove the dependencies on libibumad and libibverbs.
> >
> > Remove the generated vmw_pvrdma/ directory from linux-headers.
> >
> > Remove RDMA handling from migration.
> >
> > Remove RDMA handling in GlusterFS block driver.
> >
> > Remove rdmacm-mux tool from contrib/.
> >
> > Remove PVRDMA device.
> >
> > Cc: Peter Xu
> > Cc: Li Zhijian
> > Cc: Yuval Shaia
> > Cc: Marcel Apfelbaum
> > Signed-off-by: Philippe Mathieu-Daudé
> > ---
> > MAINTAINERS | 17 -
> > docs/about/deprecated.rst |9 -
> > docs/about/removed-features.rst |4 +
> > docs/devel/migration/main.rst |6 -
> > docs/pvrdma.txt | 345 --
> > docs/rdma.txt | 420 --
> > docs/system/device-url-syntax.rst.inc |4 +-
> > docs/system/loongarch/virt.rst|2 +-
> > docs/system/qemu-block-drivers.rst.inc|1 -
> > meson.build | 59 -
> > qapi/machine.json | 17 -
> > qapi/migration.json | 31 +-
> > qapi/qapi-schema.json |1 -
> > qapi/rdma.json| 38 -
> > contrib/rdmacm-mux/rdmacm-mux.h | 61 -
> > hw/rdma/rdma_backend.h| 129 -
> > hw/rdma/rdma_backend_defs.h | 76 -
> > hw/rdma/rdma_rm.h | 97 -
> > hw/rdma/rdma_rm_defs.h| 146 -
> > hw/rdma/rdma_utils.h | 63 -
> > hw/rdma/trace.h |1 -
> > hw/rdma/vmw/pvrdma.h | 144 -
> > hw/rdma/vmw/pvrdma_dev_ring.h | 46 -
> > hw/rdma/vmw/pvrdma_qp_ops.h | 28 -
> > hw/rdma/vmw/trace.h |1 -
> > include/hw/rdma/rdma.h| 37 -
> > include/monitor/hmp.h |1 -
> > .../infiniband/hw/vmw_pvrdma/pvrdma_dev_api.h | 685 ---
> > .../infiniband/hw/vmw_pvrdma/pvrdma_verbs.h | 348 --
> > .../standard-headers/rdma/vmw_pvrdma-abi.h| 310 --
> > migration/migration-stats.h |6 +-
> > migration/migration.h |9 -
> > migration/options.h |2 -
> > migration/rdma.h | 69 -
> > block/gluster.c | 39 -
> > contrib/rdmacm-mux/main.c | 831
> > hw/core/machine-qmp-cmds.c| 32 -
> > hw/rdma/rdma.c| 30 -
> > hw/rdma/rdma_backend.c| 1401 --
> > hw/rdma/rdma_rm.c | 812
> > hw/rdma/rdma_utils.c | 126 -
> > hw/rdma/vmw/pvrdma_cmd.c | 815
> > hw/rdma/vmw/pvrdma_dev_ring.c | 141 -
> > hw/rdma/vmw/pvrdma_main.c | 735 ---
> > hw/rdma/vmw/pvrdma_qp_ops.c | 298 --
> > migration/migration-stats.c |5 +-
> > migration/migration.c | 31 -
> > migration/options.c | 16 -
> > migration/qemu-file.c |1 -
> > migration/ram.c | 86 +-
> > migration/rdma.c | 4184 -
> > migration/savevm.c|2 +-
> > monitor/qmp-cmds.c|1 -
> > Kconfig.host |3 -
> > contrib/rdmacm-mux/meson.build|7 -
> > hmp-commands-info.hx | 13 -
> > hw/Kconfig|1 -
> > hw/meson.build|1 -
> > hw/rdma/Kconfig |3 -
> > hw/rdma/meson.build | 12 -
> > hw/rdma/trace-events | 31 -
> > hw/rdma/vmw/trace-events | 17 -
> > meson_options.txt |4 -
> > migration/meson.build |1 -
> > migration/trace-events| 68 +-
> > qapi/meson.build |1 -
> > qemu-options.hx |6 -
> >
Re: [RFC QEMU PATCH v7 1/1] virtio-pci: implement No_Soft_Reset bit
On Thu, Mar 28, 2024 at 09:02:28AM +, Chen, Jiqian wrote:
>
> On 2024/3/28 16:11, Michael S. Tsirkin wrote:
> >
> >> +VirtIOPCIProxy *proxy = VIRTIO_PCI(dev);
> >> +
> >> pcie_cap_deverr_reset(dev);
> >> pcie_cap_lnkctl_reset(dev);
> >>
> >> -pci_set_word(dev->config + dev->exp.pm_cap + PCI_PM_CTRL, 0);
> >> +if (proxy->flags & VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET) {
> >> +val |= PCI_PM_CTRL_NO_SOFT_RESET;
> >> +}
> >> +pci_set_word(dev->config + dev->exp.pm_cap + PCI_PM_CTRL, val);
> >
> >
> > There is no need to do it like this - only state is writeable
> > anyway. So simply
> > pci_word_test_and_clear_mask(dev->config + dev->exp.pm_cap +
> > PCI_PM_CTRL, PCI_PM_CTRL_STATE_MASK)
> >
> >
> > maybe we should actually check here:
> >if (proxy->flags & VIRTIO_PCI_FLAG_INIT_PM)
> > there's a chance commit 27ce0f3afc9 broke things for old machines
> > and we never noticed. If so that should be a separate bugfix patch though.
> Make sense. It is actually a bug imported by 27ce0f3afc9.
> According to your comments, I think here should be a separate patch, like:
>if (pci_is_express(dev)) {
> VirtIOPCIProxy *proxy = VIRTIO_PCI(dev);
>
> pcie_cap_deverr_reset(dev);
> pcie_cap_lnkctl_reset(dev);
>
> if (proxy->flags & VIRTIO_PCI_FLAG_INIT_PM) {
> pci_word_test_and_clear_mask(
> dev->config + dev->exp.pm_cap + PCI_PM_CTRL,
> PCI_PM_CTRL_STATE_MASK);
> }
> }
> Right?
Works for me.
> >
> >
>
> --
> Best regards,
> Jiqian Chen.
Re: [RFC QEMU PATCH v7 1/1] virtio-pci: implement No_Soft_Reset bit
On Mon, Mar 25, 2024 at 03:07:24PM +0800, Jiqian Chen wrote:
> In current code, when guest does S3, virtio devices are reset due to
> the bit No_Soft_Reset is not set. After resetting, the display resources
> of virtio-gpu are destroyed, then the display can't come back and only
> show blank after resuming.
>
> Implement No_Soft_Reset bit of PCI_PM_CTRL register, then guest can check
> this bit, if this bit is set, the devices resetting will not be done, and
> then the display can work after resuming.
>
> Signed-off-by: Jiqian Chen
> ---
> hw/virtio/virtio-pci.c | 38 +-
> include/hw/virtio/virtio-pci.h | 5 +
> 2 files changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> index 1a7039fb0c68..daafda315f8c 100644
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
> @@ -2197,6 +2197,11 @@ static void virtio_pci_realize(PCIDevice *pci_dev,
> Error **errp)
> pcie_cap_lnkctl_init(pci_dev);
> }
>
> +if (proxy->flags & VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET) {
> +pci_set_word(pci_dev->config + pos + PCI_PM_CTRL,
> + PCI_PM_CTRL_NO_SOFT_RESET);
> +}
> +
> if (proxy->flags & VIRTIO_PCI_FLAG_INIT_PM) {
> /* Init Power Management Control Register */
> pci_set_word(pci_dev->wmask + pos + PCI_PM_CTRL,
> @@ -2259,18 +2264,47 @@ static void virtio_pci_reset(DeviceState *qdev)
> }
> }
>
> +static bool device_no_need_reset(PCIDevice *dev)
I'd just call it virtio_pci_no_soft_reset() .
> +{
> +if (pci_is_express(dev)) {
A cleaner way to structure this is by reversing the test:
if (!pci_is_express(dev)) {
return false;
}
I would also check that pm_cap is actually set here.
> +uint16_t pmcsr;
> +
> +pmcsr = pci_get_word(dev->config + dev->exp.pm_cap + PCI_PM_CTRL);
> +/*
> + * When No_Soft_Reset bit is set and the device
> + * is in D3hot state, don't reset device
> + */
> +if ((pmcsr & PCI_PM_CTRL_NO_SOFT_RESET) &&
> +(pmcsr & PCI_PM_CTRL_STATE_MASK) == 3) {
> +return true;
And then here it will be
return (pmcsr & PCI_PM_CTRL_NO_SOFT_RESET) &&
(pmcsr & PCI_PM_CTRL_STATE_MASK) == 3;
> +}
> +}
> +
> +return false;
> +}
> +
> static void virtio_pci_bus_reset_hold(Object *obj)
> {
> PCIDevice *dev = PCI_DEVICE(obj);
> DeviceState *qdev = DEVICE(obj);
>
> +if (device_no_need_reset(dev)) {
> +return;
> +}
> +
> virtio_pci_reset(qdev);
>
> if (pci_is_express(dev)) {
> +uint16_t val = 0;
call it pm_ctrl
> +VirtIOPCIProxy *proxy = VIRTIO_PCI(dev);
> +
> pcie_cap_deverr_reset(dev);
> pcie_cap_lnkctl_reset(dev);
>
> -pci_set_word(dev->config + dev->exp.pm_cap + PCI_PM_CTRL, 0);
> +if (proxy->flags & VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET) {
> +val |= PCI_PM_CTRL_NO_SOFT_RESET;
> +}
> +pci_set_word(dev->config + dev->exp.pm_cap + PCI_PM_CTRL, val);
There is no need to do it like this - only state is writeable
anyway. So simply
pci_word_test_and_clear_mask(dev->config + dev->exp.pm_cap +
PCI_PM_CTRL, PCI_PM_CTRL_STATE_MASK)
maybe we should actually check here:
if (proxy->flags & VIRTIO_PCI_FLAG_INIT_PM)
there's a chance commit 27ce0f3afc9 broke things for old machines
and we never noticed. If so that should be a separate bugfix patch though.
> }
> }
>
> @@ -2297,6 +2331,8 @@ static Property virtio_pci_properties[] = {
> VIRTIO_PCI_FLAG_INIT_LNKCTL_BIT, true),
> DEFINE_PROP_BIT("x-pcie-pm-init", VirtIOPCIProxy, flags,
> VIRTIO_PCI_FLAG_INIT_PM_BIT, true),
> +DEFINE_PROP_BIT("x-pcie-pm-no-soft-reset", VirtIOPCIProxy, flags,
> +VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET_BIT, false),
> DEFINE_PROP_BIT("x-pcie-flr-init", VirtIOPCIProxy, flags,
> VIRTIO_PCI_FLAG_INIT_FLR_BIT, true),
> DEFINE_PROP_BIT("aer", VirtIOPCIProxy, flags,
> diff --git a/include/hw/virtio/virtio-pci.h b/include/hw/virtio/virtio-pci.h
> index 59d88018c16a..9e67ba38c748 100644
> --- a/include/hw/virtio/virtio-pci.h
> +++ b/include/hw/virtio/virtio-pci.h
> @@ -43,6 +43,7 @@ enum {
> VIRTIO_PCI_FLAG_INIT_FLR_BIT,
> VIRTIO_PCI_FLAG_AER_BIT,
> VIRTIO_PCI_FLAG_ATS_PAGE_ALIGNED_BIT,
> +VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET_BIT,
> };
>
> /* Need to activate work-arounds for buggy guests at vmstate load. */
> @@ -79,6 +80,10 @@ enum {
> /* Init Power Management */
> #define VIRTIO_PCI_FLAG_INIT_PM (1 << VIRTIO_PCI_FLAG_INIT_PM_BIT)
>
> +/* Init The No_Soft_Reset bit of Power Management */
> +#define VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET \
> + (1 << VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET_BIT)
> +
> /* Init Function Level Reset capability */
Re: [PATCH v1 3/6] intel_iommu: Add a framework to check and sync host IOMMU cap/ecap
On Mon, Mar 18, 2024 at 02:20:50PM +0100, Eric Auger wrote:
> Hi Michael,
>
> On 3/13/24 12:17, Michael S. Tsirkin wrote:
> > On Wed, Mar 13, 2024 at 07:54:11AM +, Duan, Zhenzhong wrote:
> >>
> >>> -----Original Message-
> >>> From: Michael S. Tsirkin
> >>> Subject: Re: [PATCH v1 3/6] intel_iommu: Add a framework to check and
> >>> sync host IOMMU cap/ecap
> >>>
> >>> On Wed, Mar 13, 2024 at 02:52:39AM +, Duan, Zhenzhong wrote:
> >>>> Hi Michael,
> >>>>
> >>>>> -Original Message-
> >>>>> From: Michael S. Tsirkin
> >>>>> Subject: Re: [PATCH v1 3/6] intel_iommu: Add a framework to check and
> >>>>> sync host IOMMU cap/ecap
> >>>>>
> >>>>> On Wed, Feb 28, 2024 at 05:44:29PM +0800, Zhenzhong Duan wrote:
> >>>>>> From: Yi Liu
> >>>>>>
> >>>>>> Add a framework to check and synchronize host IOMMU cap/ecap with
> >>>>>> vIOMMU cap/ecap.
> >>>>>>
> >>>>>> The sequence will be:
> >>>>>>
> >>>>>> vtd_cap_init() initializes iommu->cap/ecap.
> >>>>>> vtd_check_hdev() update iommu->cap/ecap based on host cap/ecap.
> >>>>>> iommu->cap_frozen set when machine create done, iommu->cap/ecap
> >>>>> become readonly.
> >>>>>> Implementation details for different backends will be in following
> >>> patches.
> >>>>>> Signed-off-by: Yi Liu
> >>>>>> Signed-off-by: Yi Sun
> >>>>>> Signed-off-by: Zhenzhong Duan
> >>>>>> ---
> >>>>>> include/hw/i386/intel_iommu.h | 1 +
> >>>>>> hw/i386/intel_iommu.c | 50
> >>>>> ++-
> >>>>>> 2 files changed, 50 insertions(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git a/include/hw/i386/intel_iommu.h
> >>>>> b/include/hw/i386/intel_iommu.h
> >>>>>> index bbc7b96add..c71a133820 100644
> >>>>>> --- a/include/hw/i386/intel_iommu.h
> >>>>>> +++ b/include/hw/i386/intel_iommu.h
> >>>>>> @@ -283,6 +283,7 @@ struct IntelIOMMUState {
> >>>>>>
> >>>>>> uint64_t cap; /* The value of capability reg */
> >>>>>> uint64_t ecap; /* The value of extended
> >>>>>> capability reg */
> >>>>>> +bool cap_frozen;/* cap/ecap become read-only after
> >>> frozen */
> >>>>>> uint32_t context_cache_gen; /* Should be in [1,MAX] */
> >>>>>> GHashTable *iotlb; /* IOTLB */
> >>>>>> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> >>>>>> index ffa1ad6429..a9f9dfd6a7 100644
> >>>>>> --- a/hw/i386/intel_iommu.c
> >>>>>> +++ b/hw/i386/intel_iommu.c
> >>>>>> @@ -35,6 +35,8 @@
> >>>>>> #include "sysemu/kvm.h"
> >>>>>> #include "sysemu/dma.h"
> >>>>>> #include "sysemu/sysemu.h"
> >>>>>> +#include "hw/vfio/vfio-common.h"
> >>>>>> +#include "sysemu/iommufd.h"
> >>>>>> #include "hw/i386/apic_internal.h"
> >>>>>> #include "kvm/kvm_i386.h"
> >>>>>> #include "migration/vmstate.h"
> >>>>>> @@ -3819,6 +3821,38 @@ VTDAddressSpace
> >>>>> *vtd_find_add_as(IntelIOMMUState *s, PCIBus *bus,
> >>>>>> return vtd_dev_as;
> >>>>>> }
> >>>>>>
> >>>>>> +static int vtd_check_legacy_hdev(IntelIOMMUState *s,
> >>>>>> + IOMMULegacyDevice *ldev,
> >>>>>> + Error **errp)
> >>>>>> +{
> >>>>>> +return 0;
> >>>>>> +}
> >>>>>> +
> >>>>>> +static int vtd_check_iommufd_hdev(IntelIOMMUState *s,
> >>>>>> + IOMMUFDDevice *idev,
> >>>>>> +
Re: [PATCH v3] vfio/pci: migration: Skip config space check for Vendor Specific Information in VSC during restore/load
On Wed, Mar 27, 2024 at 11:39:15AM -0600, Alex Williamson wrote:
> On Fri, 22 Mar 2024 12:12:10 +0530
> Vinayak Kale wrote:
>
> > In case of migration, during restore operation, qemu checks config space of
> > the
> > pci device with the config space in the migration stream captured during
> > save
> > operation. In case of config space data mismatch, restore operation is
> > failed.
> >
> > config space check is done in function get_pci_config_device(). By default
> > VSC
> > (vendor-specific-capability) in config space is checked.
> >
> > Due to qemu's config space check for VSC, live migration is broken across
> > NVIDIA
> > vGPU devices in situation where source and destination host driver is
> > different.
> > In this situation, Vendor Specific Information in VSC varies on the
> > destination
> > to ensure vGPU feature capabilities exposed to the guest driver are
> > compatible
> > with destination host.
> >
> > If a vfio-pci device is migration capable and vfio-pci vendor driver is OK
> > with
> > volatile Vendor Specific Info in VSC then qemu should exempt config space
> > check
> > for Vendor Specific Info. It is vendor driver's responsibility to ensure
> > that
> > VSC is consistent across migration. Here consistency could mean that VSC
> > format
> > should be same on source and destination, however actual Vendor Specific
> > Info
> > may not be byte-to-byte identical.
> >
> > This patch skips the check for Vendor Specific Information in VSC for
> > VFIO-PCI
> > device by clearing pdev->cmask[] offsets. Config space check is still
> > enforced
> > for 3 byte VSC header. If cmask[] is not set for an offset, then qemu skips
> > config space check for that offset.
> >
> > Signed-off-by: Vinayak Kale
> > ---
> > Version History
> > v2->v3:
> > - Config space check skipped only for Vendor Specific Info in VSC,
> > check is
> > still enforced for 3 byte VSC header.
> > - Updated commit description with live migration failure scenario.
> > v1->v2:
> > - Limited scope of change to vfio-pci devices instead of all pci
> > devices.
> >
> > hw/vfio/pci.c | 24
> > 1 file changed, 24 insertions(+)
>
>
> Acked-by: Alex Williamson
A very reasonable way to do it.
Reviewed-by: Michael S. Tsirkin
Merge through the VFIO tree I presume?
>
> > diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> > index d7fe06715c..1026cdba18 100644
> > --- a/hw/vfio/pci.c
> > +++ b/hw/vfio/pci.c
> > @@ -2132,6 +2132,27 @@ static void vfio_check_af_flr(VFIOPCIDevice *vdev,
> > uint8_t pos)
> > }
> > }
> >
> > +static int vfio_add_vendor_specific_cap(VFIOPCIDevice *vdev, int pos,
> > +uint8_t size, Error **errp)
> > +{
> > +PCIDevice *pdev = >pdev;
> > +
> > +pos = pci_add_capability(pdev, PCI_CAP_ID_VNDR, pos, size, errp);
> > +if (pos < 0) {
> > +return pos;
> > +}
> > +
> > +/*
> > + * Exempt config space check for Vendor Specific Information during
> > restore/load.
> > + * Config space check is still enforced for 3 byte VSC header.
> > + */
> > +if (size > 3) {
> > +memset(pdev->cmask + pos + 3, 0, size - 3);
> > +}
> > +
> > +return pos;
> > +}
> > +
> > static int vfio_add_std_cap(VFIOPCIDevice *vdev, uint8_t pos, Error **errp)
> > {
> > PCIDevice *pdev = >pdev;
> > @@ -2199,6 +2220,9 @@ static int vfio_add_std_cap(VFIOPCIDevice *vdev,
> > uint8_t pos, Error **errp)
> > vfio_check_af_flr(vdev, pos);
> > ret = pci_add_capability(pdev, cap_id, pos, size, errp);
> > break;
> > +case PCI_CAP_ID_VNDR:
> > +ret = vfio_add_vendor_specific_cap(vdev, pos, size, errp);
> > +break;
> > default:
> > ret = pci_add_capability(pdev, cap_id, pos, size, errp);
> > break;
Re: [PULL 32/68] hw/virtio: Add support for VDPA network simulation devices
On Wed, Mar 20, 2024 at 09:58:40AM +0100, Paolo Bonzini wrote:
> On 3/12/24 23:27, Michael S. Tsirkin wrote:
> > diff --git a/include/standard-headers/linux/virtio_pci.h
> > b/include/standard-headers/linux/virtio_pci.h
> > index 3e2bc2c97e..86733278ba 100644
> > --- a/include/standard-headers/linux/virtio_pci.h
> > +++ b/include/standard-headers/linux/virtio_pci.h
> > @@ -221,6 +221,13 @@ struct virtio_pci_cfg_cap {
> > #define VIRTIO_PCI_COMMON_ADM_Q_IDX 60
> > #define VIRTIO_PCI_COMMON_ADM_Q_NUM 62
> > +#define LM_LOGGING_CTRL 0
> > +#define LM_BASE_ADDR_LOW4
> > +#define LM_BASE_ADDR_HIGH 8
> > +#define LM_END_ADDR_LOW 12
> > +#define LM_END_ADDR_HIGH16
> > +#define LM_VRING_STATE_OFFSET 0x20
>
> I cannot find these constants in upstream Linux (what will be 6.9). Is there
> a tree that defines these constants, or should they be moved to
> include/hw/virtio/vdpa-dev.h (or something like that)?
>
> Thanks,
>
> Paolo
They should be moved. If the contributor doesn't do that soon
I will revert the change. Thanks!
--
MST
[PULL 21/24] tests: acpi/smbios: whitelist expected blobs
From: Igor Mammedov Signed-off-by: Igor Mammedov Acked-by: Ani Sinha Message-Id: <20240314152302.2324164-19-imamm...@redhat.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- tests/qtest/bios-tables-test-allowed-diff.h | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/qtest/bios-tables-test-allowed-diff.h b/tests/qtest/bios-tables-test-allowed-diff.h index dfb8523c8b..81148a604f 100644 --- a/tests/qtest/bios-tables-test-allowed-diff.h +++ b/tests/qtest/bios-tables-test-allowed-diff.h @@ -1 +1,2 @@ /* List of comma-separated changed AML files to ignore */ +"tests/data/acpi/q35/SSDT.dimmpxm", -- MST
[PULL 19/24] smbios: in case of entry point is 'auto' try to build v2 tables 1st
From: Igor Mammedov
QEMU for some time now uses SMBIOS 3.0 for PC/Q35 machines by
default, however Windows has a bug in locating SMBIOS 3.0
entrypoint and fails to find tables when booted on SeaBIOS
(on UEFI SMBIOS 3.0 tables work fine since firmware hands
over tables in another way)
Missing SMBIOS tables may lead to some issues for guest
though (worst are: possible reactiveation, inability to
get virtio drivers from 'Windows Update')
It's unclear at this point if MS will fix the issue on their
side. So instead of it (or rather in addition) this patch
will try to workaround the issue.
aka, use smbios-entry-point-type=auto to make QEMU try
generating conservative SMBIOS 2.0 tables and if that
fails (due to limits/requested configuration) fallback
to SMBIOS 3.0 tables.
With this in place majority of users will use SMBIOS 2.0
tables which work fine with (Windows + legacy BIOS).
The configurations that is not to possible to describe
with SMBIOS 2.0 will switch automatically to SMBIOS 3.0
(which will trigger Windows bug but there is nothing
QEMU can do here, so go and aks Microsoft to real fix).
Signed-off-by: Igor Mammedov
Reviewed-by: Ani Sinha
Tested-by: Fiona Ebner
Message-Id: <20240314152302.2324164-17-imamm...@redhat.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
hw/smbios/smbios.c | 52 +++---
1 file changed, 49 insertions(+), 3 deletions(-)
diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index 48713aa505..b0467347c5 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -1082,7 +1082,7 @@ static void smbios_entry_point_setup(SmbiosEntryPointType
ep_type)
}
}
-void smbios_get_tables(MachineState *ms,
+static bool smbios_get_tables_ep(MachineState *ms,
SmbiosEntryPointType ep_type,
const struct smbios_phys_mem_area *mem_array,
const unsigned int mem_array_size,
@@ -1091,6 +1091,7 @@ void smbios_get_tables(MachineState *ms,
Error **errp)
{
unsigned i, dimm_cnt, offset;
+ERRP_GUARD();
assert(ep_type == SMBIOS_ENTRY_POINT_TYPE_32 ||
ep_type == SMBIOS_ENTRY_POINT_TYPE_64);
@@ -1177,11 +1178,56 @@ void smbios_get_tables(MachineState *ms,
abort();
}
-return;
+return true;
err_exit:
g_free(smbios_tables);
smbios_tables = NULL;
-return;
+return false;
+}
+
+void smbios_get_tables(MachineState *ms,
+ SmbiosEntryPointType ep_type,
+ const struct smbios_phys_mem_area *mem_array,
+ const unsigned int mem_array_size,
+ uint8_t **tables, size_t *tables_len,
+ uint8_t **anchor, size_t *anchor_len,
+ Error **errp)
+{
+Error *local_err = NULL;
+bool is_valid;
+ERRP_GUARD();
+
+switch (ep_type) {
+case SMBIOS_ENTRY_POINT_TYPE_AUTO:
+case SMBIOS_ENTRY_POINT_TYPE_32:
+is_valid = smbios_get_tables_ep(ms, SMBIOS_ENTRY_POINT_TYPE_32,
+mem_array, mem_array_size,
+tables, tables_len,
+anchor, anchor_len,
+_err);
+if (is_valid || ep_type != SMBIOS_ENTRY_POINT_TYPE_AUTO) {
+break;
+}
+/*
+ * fall through in case AUTO endpoint is selected and
+ * SMBIOS 2.x tables can't be generated, to try if SMBIOS 3.x
+ * tables would work
+ */
+case SMBIOS_ENTRY_POINT_TYPE_64:
+error_free(local_err);
+local_err = NULL;
+is_valid = smbios_get_tables_ep(ms, SMBIOS_ENTRY_POINT_TYPE_64,
+mem_array, mem_array_size,
+tables, tables_len,
+anchor, anchor_len,
+_err);
+break;
+default:
+abort();
+}
+if (!is_valid) {
+error_propagate(errp, local_err);
+}
}
static void save_opt(const char **dest, QemuOpts *opts, const char *name)
--
MST
[PULL 11/24] smbios: don't check type4 structures in legacy mode
From: Igor Mammedov
legacy mode doesn't support structures of type 2 and more,
and CLI has a check for '-smbios type' option, however it's
still possible to sneak in type4 as a blob with '-smbios file'
option. However doing the later makes SMBIOS tables broken
since SeaBIOS doesn't expect that.
Rather than trying to add support for type4 to legacy code
(both QEMU and SeaBIOS), simplify smbios_get_table_legacy()
by dropping not relevant check in legacy code and error out
on type4 blob.
Signed-off-by: Igor Mammedov
Reviewed-by: Ani Sinha
Tested-by: Fiona Ebner
Message-Id: <20240314152302.2324164-9-imamm...@redhat.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
include/hw/firmware/smbios.h | 2 +-
hw/i386/fw_cfg.c | 3 +--
hw/smbios/smbios.c | 18 ++
3 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/include/hw/firmware/smbios.h b/include/hw/firmware/smbios.h
index 7b42e7b4ac..0f0dca8f83 100644
--- a/include/hw/firmware/smbios.h
+++ b/include/hw/firmware/smbios.h
@@ -313,7 +313,7 @@ void smbios_set_defaults(const char *manufacturer, const
char *product,
const char *version,
bool uuid_encoded, SmbiosEntryPointType ep_type);
void smbios_set_default_processor_family(uint16_t processor_family);
-uint8_t *smbios_get_table_legacy(uint32_t expected_t4_count, size_t *length);
+uint8_t *smbios_get_table_legacy(size_t *length);
void smbios_get_tables(MachineState *ms,
const struct smbios_phys_mem_area *mem_array,
const unsigned int mem_array_size,
diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
index c1e9c0fd9c..d1281066f4 100644
--- a/hw/i386/fw_cfg.c
+++ b/hw/i386/fw_cfg.c
@@ -71,8 +71,7 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState
*fw_cfg)
smbios_set_cpuid(cpu->env.cpuid_version, cpu->env.features[FEAT_1_EDX]);
if (pcmc->smbios_legacy_mode) {
-smbios_tables = smbios_get_table_legacy(ms->smp.cpus,
-_tables_len);
+smbios_tables = smbios_get_table_legacy(_tables_len);
fw_cfg_add_bytes(fw_cfg, FW_CFG_SMBIOS_ENTRIES,
smbios_tables, smbios_tables_len);
return;
diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index aab4ffb4cb..30196d2911 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -545,14 +545,17 @@ opts_init(smbios_register_config);
*/
#define SMBIOS_21_MAX_TABLES_LEN 0x
-static void smbios_validate_table(uint32_t expected_t4_count)
+static void smbios_check_type4_count(uint32_t expected_t4_count)
{
if (smbios_type4_count && smbios_type4_count != expected_t4_count) {
error_report("Expected %d SMBIOS Type 4 tables, got %d instead",
expected_t4_count, smbios_type4_count);
exit(1);
}
+}
+static void smbios_validate_table(void)
+{
if (smbios_ep_type == SMBIOS_ENTRY_POINT_TYPE_32 &&
smbios_tables_len > SMBIOS_21_MAX_TABLES_LEN) {
error_report("SMBIOS 2.1 table length %zu exceeds %d",
@@ -637,7 +640,7 @@ static void smbios_build_type_1_fields(void)
}
}
-uint8_t *smbios_get_table_legacy(uint32_t expected_t4_count, size_t *length)
+uint8_t *smbios_get_table_legacy(size_t *length)
{
int i;
size_t usr_offset;
@@ -650,6 +653,12 @@ uint8_t *smbios_get_table_legacy(uint32_t
expected_t4_count, size_t *length)
exit(1);
}
+if (test_bit(4, have_binfile_bitmap)) {
+error_report("can't process table for smbios "
+ "type 4 on machine versions < 2.1!");
+exit(1);
+}
+
g_free(smbios_entries);
smbios_entries_len = sizeof(uint16_t);
smbios_entries = g_malloc0(smbios_entries_len);
@@ -676,7 +685,7 @@ uint8_t *smbios_get_table_legacy(uint32_t
expected_t4_count, size_t *length)
smbios_build_type_0_fields();
smbios_build_type_1_fields();
-smbios_validate_table(expected_t4_count);
+smbios_validate_table();
*length = smbios_entries_len;
return smbios_entries;
}
@@ -1304,7 +1313,8 @@ void smbios_get_tables(MachineState *ms,
smbios_build_type_41_table(errp);
smbios_build_type_127_table();
-smbios_validate_table(ms->smp.sockets);
+smbios_check_type4_count(ms->smp.sockets);
+smbios_validate_table();
smbios_entry_point_setup();
/* return tables blob and entry point (anchor), and their sizes */
--
MST
[PULL 02/24] qapi: document PCIe Gen5/Gen6 speeds since 9.0
Document that PCIe Gen5/Gen6 speeds are only in QAPI
since 9.0 - the rest is since 4.0.
Cc: Lukas Stockner
Cc: Marcel Apfelbaum
Fixes: c08da86dc4 ("pcie: Support PCIe Gen5/Gen6 link speeds")
Suggested-by: Markus Armbruster
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Philippe Mathieu-Daudé
---
qapi/common.json | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/qapi/common.json b/qapi/common.json
index 867a9ad9b0..7558ce5430 100644
--- a/qapi/common.json
+++ b/qapi/common.json
@@ -107,9 +107,9 @@
#
# @16: 16.0GT/s
#
-# @32: 32.0GT/s
+# @32: 32.0GT/s (since 9.0)
#
-# @64: 64.0GT/s
+# @64: 64.0GT/s (since 9.0)
#
# Since: 4.0
##
--
MST
[PULL 17/24] smbios: clear smbios_type4_count before building tables
From: Igor Mammedov it will help to keep type 4 tables accounting correct in case SMBIOS tables are built multiple times. Signed-off-by: Igor Mammedov Tested-by: Fiona Ebner Message-Id: <20240314152302.2324164-15-imamm...@redhat.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- hw/smbios/smbios.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c index 0ab77b5ec8..48713aa505 100644 --- a/hw/smbios/smbios.c +++ b/hw/smbios/smbios.c @@ -1096,6 +1096,7 @@ void smbios_get_tables(MachineState *ms, ep_type == SMBIOS_ENTRY_POINT_TYPE_64); g_free(smbios_tables); +smbios_type4_count = 0; smbios_tables = g_memdup2(usr_blobs, usr_blobs_len); smbios_tables_len = usr_blobs_len; smbios_table_max = usr_table_max; -- MST
[PULL 22/24] pc/q35: set SMBIOS entry point type to 'auto' by default
From: Igor Mammedov
Use smbios-entry-point-type='auto' for newer machine types as a workaround
for Windows not detecting SMBIOS tables. Which makes QEMU pick SMBIOS tables
based on configuration (with 2.x preferred and fallback to 3.x if the former
isn't compatible with configuration)
Default compat setting of smbios-entry-point-type after series
for pc/q35 machines:
* 9.0-newer: 'auto'
* 8.1-8.2: '64'
* 8.0-older: '32'
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2008
Signed-off-by: Igor Mammedov
Reviewed-by: Ani Sinha
Tested-by: Fiona Ebner
Message-Id: <20240314152302.2324164-20-imamm...@redhat.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
hw/i386/pc.c | 2 +-
hw/i386/pc_piix.c | 4
hw/i386/pc_q35.c | 3 +++
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 44eb073abd..e80f02bef4 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1832,7 +1832,7 @@ static void pc_machine_class_init(ObjectClass *oc, void
*data)
mc->nvdimm_supported = true;
mc->smp_props.dies_supported = true;
mc->default_ram_id = "pc.ram";
-pcmc->default_smbios_ep_type = SMBIOS_ENTRY_POINT_TYPE_64;
+pcmc->default_smbios_ep_type = SMBIOS_ENTRY_POINT_TYPE_AUTO;
object_class_property_add(oc, PC_MACHINE_MAX_RAM_BELOW_4G, "size",
pc_machine_get_max_ram_below_4g, pc_machine_set_max_ram_below_4g,
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index c9a6c0aa68..18ba076609 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -525,12 +525,16 @@ DEFINE_I440FX_MACHINE(v9_0, "pc-i440fx-9.0", NULL,
static void pc_i440fx_8_2_machine_options(MachineClass *m)
{
+PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
+
pc_i440fx_9_0_machine_options(m);
m->alias = NULL;
m->is_default = false;
compat_props_add(m->compat_props, hw_compat_8_2, hw_compat_8_2_len);
compat_props_add(m->compat_props, pc_compat_8_2, pc_compat_8_2_len);
+/* For pc-i44fx-8.2 and 8.1, use SMBIOS 3.X by default */
+pcmc->default_smbios_ep_type = SMBIOS_ENTRY_POINT_TYPE_64;
}
DEFINE_I440FX_MACHINE(v8_2, "pc-i440fx-8.2", NULL,
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 8a427c4647..b5922b44af 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -376,11 +376,14 @@ DEFINE_Q35_MACHINE(v9_0, "pc-q35-9.0", NULL,
static void pc_q35_8_2_machine_options(MachineClass *m)
{
+PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
pc_q35_9_0_machine_options(m);
m->alias = NULL;
m->max_cpus = 1024;
compat_props_add(m->compat_props, hw_compat_8_2, hw_compat_8_2_len);
compat_props_add(m->compat_props, pc_compat_8_2, pc_compat_8_2_len);
+/* For pc-q35-8.2 and 8.1, use SMBIOS 3.X by default */
+pcmc->default_smbios_ep_type = SMBIOS_ENTRY_POINT_TYPE_64;
}
DEFINE_Q35_MACHINE(v8_2, "pc-q35-8.2", NULL,
--
MST
[PULL 20/24] smbios: error out when building type 4 table is not possible
From: Igor Mammedov
If SMBIOS v2 version is requested but number of cores/threads
are more than it's possible to describe with v2, error out
instead of silently ignoring the fact and filling core/thread
count with bogus values.
This will help caller to decide if it should fallback to
SMBIOSv3 when smbios-entry-point-type='auto'
Signed-off-by: Igor Mammedov
Reviewed-by: Ani Sinha
Tested-by: Fiona Ebner
Message-Id: <20240314152302.2324164-18-imamm...@redhat.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
hw/smbios/smbios.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index b0467347c5..eed5787b15 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -669,7 +669,8 @@ static void smbios_build_type_3_table(void)
}
static void smbios_build_type_4_table(MachineState *ms, unsigned instance,
- SmbiosEntryPointType ep_type)
+ SmbiosEntryPointType ep_type,
+ Error **errp)
{
char sock_str[128];
size_t tbl_len = SMBIOS_TYPE_4_LEN_V28;
@@ -723,6 +724,12 @@ static void smbios_build_type_4_table(MachineState *ms,
unsigned instance,
if (tbl_len == SMBIOS_TYPE_4_LEN_V30) {
t->core_count2 = t->core_enabled2 = cpu_to_le16(cores_per_socket);
t->thread_count2 = cpu_to_le16(threads_per_socket);
+} else if (t->core_count == 0xFF || t->thread_count == 0xFF) {
+error_setg(errp, "SMBIOS 2.0 doesn't support number of processor "
+ "cores/threads more than 255, use "
+ "-machine smbios-entry-point-type=64 option to enable
"
+ "SMBIOS 3.0 support");
+return;
}
SMBIOS_BUILD_TABLE_POST;
@@ -,7 +1118,10 @@ static bool smbios_get_tables_ep(MachineState *ms,
assert(ms->smp.sockets >= 1);
for (i = 0; i < ms->smp.sockets; i++) {
-smbios_build_type_4_table(ms, i, ep_type);
+smbios_build_type_4_table(ms, i, ep_type, errp);
+if (*errp) {
+goto err_exit;
+}
}
smbios_build_type_8_table();
--
MST
[PULL 05/24] tests: smbios: add test for -smbios type=11 option
From: Igor Mammedov
Signed-off-by: Igor Mammedov
Reviewed-by: Ani Sinha
Tested-by: Fiona Ebner
Message-Id: <20240314152302.2324164-3-imamm...@redhat.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
tests/qtest/bios-tables-test.c | 17 +
tests/data/smbios/type11_blob | Bin 0 -> 11 bytes
2 files changed, 17 insertions(+)
create mode 100644 tests/data/smbios/type11_blob
diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
index b2992bafa8..a116f88e1d 100644
--- a/tests/qtest/bios-tables-test.c
+++ b/tests/qtest/bios-tables-test.c
@@ -2091,6 +2091,21 @@ static void test_acpi_pc_smbios_options(void)
free_test_data();
}
+static void test_acpi_pc_smbios_blob(void)
+{
+uint8_t req_type11[] = { 11 };
+test_data data = {
+.machine = MACHINE_PC,
+.variant = ".pc_smbios_blob",
+.required_struct_types = req_type11,
+.required_struct_types_len = ARRAY_SIZE(req_type11),
+};
+
+test_smbios("-machine smbios-entry-point-type=32 "
+"-smbios file=tests/data/smbios/type11_blob", );
+free_test_data();
+}
+
static void test_oem_fields(test_data *data)
{
int i;
@@ -2244,6 +2259,8 @@ int main(int argc, char *argv[])
#endif
qtest_add_func("acpi/piix4/smbios-options",
test_acpi_pc_smbios_options);
+qtest_add_func("acpi/piix4/smbios-blob",
+ test_acpi_pc_smbios_blob);
}
if (qtest_has_machine(MACHINE_Q35)) {
qtest_add_func("acpi/q35", test_acpi_q35_tcg);
diff --git a/tests/data/smbios/type11_blob b/tests/data/smbios/type11_blob
new file mode 100644
index
..1d8fea4b0c6f040a13ba99c3fad762538b795614
GIT binary patch
literal 11
Scmd;PW!S(N;u;*nzyJUX)?m
literal 0
HcmV?d1
--
MST
[PULL 12/24] smbios: add smbios_add_usr_blob_size() helper
From: Igor Mammedov
it will be used by follow up patch when legacy handling
is moved out into a separate file.
Signed-off-by: Igor Mammedov
Reviewed-by: Ani Sinha
Message-Id: <20240314152302.2324164-10-imamm...@redhat.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
hw/smbios/smbios.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index 30196d2911..090a6eb018 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -1411,6 +1411,14 @@ static bool save_opt_list(size_t *ndest, char ***dest,
QemuOpts *opts,
return true;
}
+static void smbios_add_usr_blob_size(size_t size)
+{
+if (!usr_blobs_sizes) {
+usr_blobs_sizes = g_array_new(false, false, sizeof(size_t));
+}
+g_array_append_val(usr_blobs_sizes, size);
+}
+
void smbios_entry_add(QemuOpts *opts, Error **errp)
{
const char *val;
@@ -1458,10 +1466,12 @@ void smbios_entry_add(QemuOpts *opts, Error **errp)
smbios_type4_count++;
}
-if (!usr_blobs_sizes) {
-usr_blobs_sizes = g_array_new(false, false, sizeof(size_t));
-}
-g_array_append_val(usr_blobs_sizes, size);
+/*
+ * preserve blob size for legacy mode so it could build its
+ * blobs flavor from 'usr_blobs'
+ */
+smbios_add_usr_blob_size(size);
+
usr_blobs_len += size;
if (size > usr_table_max) {
usr_table_max = size;
--
MST
[PULL 24/24] smbios: add extra comments to smbios_get_table_legacy()
From: Igor Mammedov
Signed-off-by: Igor Mammedov
Message-Id: <20240314152302.2324164-22-imamm...@redhat.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
hw/smbios/smbios_legacy.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/hw/smbios/smbios_legacy.c b/hw/smbios/smbios_legacy.c
index 06907cd16c..c37a8ee821 100644
--- a/hw/smbios/smbios_legacy.c
+++ b/hw/smbios/smbios_legacy.c
@@ -151,6 +151,9 @@ uint8_t *smbios_get_table_legacy(size_t *length, Error
**errp)
smbios_entries_len = sizeof(uint16_t);
smbios_entries = g_malloc0(smbios_entries_len);
+/*
+ * build a set of legacy smbios_table entries using user provided blobs
+ */
for (i = 0, usr_offset = 0; usr_blobs_sizes && i < usr_blobs_sizes->len;
i++)
{
@@ -166,6 +169,10 @@ uint8_t *smbios_get_table_legacy(size_t *length, Error
**errp)
table->header.length = cpu_to_le16(sizeof(*table) + size);
memcpy(table->data, header, size);
smbios_entries_len += sizeof(*table) + size;
+/*
+ * update number of entries in the blob,
+ * see SeaBIOS: qemu_cfg_legacy():QEMU_CFG_SMBIOS_ENTRIES
+ */
(*(uint16_t *)smbios_entries) =
cpu_to_le16(le16_to_cpu(*(uint16_t *)smbios_entries) + 1);
usr_offset += size;
--
MST
[PULL 10/24] smbios: avoid mangling user provided tables
From: Igor Mammedov
currently smbios_entry_add() preserves internally '-smbios type='
options but tables provided with '-smbios file=' are stored directly
into blob that eventually will be exposed to VM. And then later
QEMU adds default/'-smbios type' entries on top into the same blob.
It makes impossible to generate tables more than once, hence
'immutable' guard was used.
Make it possible to regenerate final blob by storing user provided
blobs into a dedicated area (usr_blobs) and then copy it when
composing final blob. Which also makes handling of -smbios
options consistent.
As side effect of this and previous commits there is no need to
generate legacy smbios_entries at the time options are parsed.
Instead compose smbios_entries on demand from usr_blobs like
it is done for non-legacy SMBIOS tables.
Signed-off-by: Igor Mammedov
Tested-by: Fiona Ebner
Reviewed-by: Ani Sinha
Message-Id: <20240314152302.2324164-8-imamm...@redhat.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
hw/smbios/smbios.c | 187 +++--
1 file changed, 96 insertions(+), 91 deletions(-)
diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index 9f9087601c..aab4ffb4cb 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -57,6 +57,14 @@ static size_t smbios_entries_len;
static bool smbios_uuid_encoded = true;
/* end: legacy structures & constants for <= 2.0 machines */
+/*
+ * SMBIOS tables provided by user with '-smbios file=' option
+ */
+uint8_t *usr_blobs;
+size_t usr_blobs_len;
+static GArray *usr_blobs_sizes;
+static unsigned usr_table_max;
+static unsigned usr_table_cnt;
uint8_t *smbios_tables;
size_t smbios_tables_len;
@@ -67,7 +75,6 @@ static SmbiosEntryPointType smbios_ep_type =
SMBIOS_ENTRY_POINT_TYPE_32;
static SmbiosEntryPoint ep;
static int smbios_type4_count = 0;
-static bool smbios_immutable;
static bool smbios_have_defaults;
static uint32_t smbios_cpuid_version, smbios_cpuid_features;
@@ -632,9 +639,8 @@ static void smbios_build_type_1_fields(void)
uint8_t *smbios_get_table_legacy(uint32_t expected_t4_count, size_t *length)
{
-/* drop unwanted version of command-line file blob(s) */
-g_free(smbios_tables);
-smbios_tables = NULL;
+int i;
+size_t usr_offset;
/* also complain if fields were given for types > 1 */
if (find_next_bit(have_fields_bitmap,
@@ -644,12 +650,33 @@ uint8_t *smbios_get_table_legacy(uint32_t
expected_t4_count, size_t *length)
exit(1);
}
-if (!smbios_immutable) {
-smbios_build_type_0_fields();
-smbios_build_type_1_fields();
-smbios_validate_table(expected_t4_count);
-smbios_immutable = true;
+g_free(smbios_entries);
+smbios_entries_len = sizeof(uint16_t);
+smbios_entries = g_malloc0(smbios_entries_len);
+
+for (i = 0, usr_offset = 0; usr_blobs_sizes && i < usr_blobs_sizes->len;
+ i++)
+{
+struct smbios_table *table;
+struct smbios_structure_header *header;
+size_t size = g_array_index(usr_blobs_sizes, size_t, i);
+
+header = (struct smbios_structure_header *)(usr_blobs + usr_offset);
+smbios_entries = g_realloc(smbios_entries, smbios_entries_len +
+ size + sizeof(*table));
+table = (struct smbios_table *)(smbios_entries + smbios_entries_len);
+table->header.type = SMBIOS_TABLE_ENTRY;
+table->header.length = cpu_to_le16(sizeof(*table) + size);
+memcpy(table->data, header, size);
+smbios_entries_len += sizeof(*table) + size;
+(*(uint16_t *)smbios_entries) =
+cpu_to_le16(le16_to_cpu(*(uint16_t *)smbios_entries) + 1);
+usr_offset += size;
}
+
+smbios_build_type_0_fields();
+smbios_build_type_1_fields();
+smbios_validate_table(expected_t4_count);
*length = smbios_entries_len;
return smbios_entries;
}
@@ -1217,69 +1244,69 @@ void smbios_get_tables(MachineState *ms,
{
unsigned i, dimm_cnt, offset;
-/* drop unwanted (legacy) version of command-line file blob(s) */
-g_free(smbios_entries);
-smbios_entries = NULL;
+g_free(smbios_tables);
+smbios_tables = g_memdup2(usr_blobs, usr_blobs_len);
+smbios_tables_len = usr_blobs_len;
+smbios_table_max = usr_table_max;
+smbios_table_cnt = usr_table_cnt;
-if (!smbios_immutable) {
-smbios_build_type_0_table();
-smbios_build_type_1_table();
-smbios_build_type_2_table();
-smbios_build_type_3_table();
+smbios_build_type_0_table();
+smbios_build_type_1_table();
+smbios_build_type_2_table();
+smbios_build_type_3_table();
-assert(ms->smp.sockets >= 1);
+assert(ms->smp.sockets >= 1);
-for (i = 0; i < ms->smp.sockets; i++) {
-smbios_build_type_4_table(ms, i);
-}
+for (i = 0; i < ms-&
[PULL 01/24] SMBIOS: fix long lines
Break up long lines to fit under 80/90 char limit.
Fixes: 04f143d828 ("Implement SMBIOS type 9 v2.6")
Fixes: 735eee07d1 ("Implement base of SMBIOS type 9 descriptor.")
Cc: "Felix Wu"
Cc: Nabih Estefan
Reviewed-by: Ani Sinha
Signed-off-by: Michael S. Tsirkin
---
hw/smbios/smbios.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index e3d5d8f2e2..949c2d74a1 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -1592,12 +1592,15 @@ void smbios_entry_add(QemuOpts *opts, Error **errp)
t = g_new0(struct type9_instance, 1);
save_opt(>slot_designation, opts, "slot_designation");
t->slot_type = qemu_opt_get_number(opts, "slot_type", 0);
-t->slot_data_bus_width = qemu_opt_get_number(opts,
"slot_data_bus_width", 0);
+t->slot_data_bus_width =
+qemu_opt_get_number(opts, "slot_data_bus_width", 0);
t->current_usage = qemu_opt_get_number(opts, "current_usage", 0);
t->slot_length = qemu_opt_get_number(opts, "slot_length", 0);
t->slot_id = qemu_opt_get_number(opts, "slot_id", 0);
-t->slot_characteristics1 = qemu_opt_get_number(opts,
"slot_characteristics1", 0);
-t->slot_characteristics2 = qemu_opt_get_number(opts,
"slot_characteristics2", 0);
+t->slot_characteristics1 =
+qemu_opt_get_number(opts, "slot_characteristics1", 0);
+t->slot_characteristics2 =
+qemu_opt_get_number(opts, "slot_characteristics2", 0);
save_opt(>pcidev, opts, "pcidev");
QTAILQ_INSERT_TAIL(, t, next);
return;
--
MST
[PULL 08/24] smbios: get rid of smbios_smp_sockets global
From: Igor Mammedov
it makes smbios_validate_table() independent from
smbios_smp_sockets global, which in turn lets
smbios_get_tables() avoid using not related legacy code.
Signed-off-by: Igor Mammedov
Reviewed-by: Ani Sinha
Tested-by: Fiona Ebner
Message-Id: <20240314152302.2324164-6-imamm...@redhat.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
include/hw/firmware/smbios.h | 2 +-
hw/i386/fw_cfg.c | 2 +-
hw/smbios/smbios.c | 22 +-
3 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/include/hw/firmware/smbios.h b/include/hw/firmware/smbios.h
index c21b8d3285..36744b6cc9 100644
--- a/include/hw/firmware/smbios.h
+++ b/include/hw/firmware/smbios.h
@@ -313,7 +313,7 @@ void smbios_set_defaults(const char *manufacturer, const
char *product,
const char *version, bool legacy_mode,
bool uuid_encoded, SmbiosEntryPointType ep_type);
void smbios_set_default_processor_family(uint16_t processor_family);
-uint8_t *smbios_get_table_legacy(MachineState *ms, size_t *length);
+uint8_t *smbios_get_table_legacy(uint32_t expected_t4_count, size_t *length);
void smbios_get_tables(MachineState *ms,
const struct smbios_phys_mem_area *mem_array,
const unsigned int mem_array_size,
diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
index a635234e68..fcb4fb0769 100644
--- a/hw/i386/fw_cfg.c
+++ b/hw/i386/fw_cfg.c
@@ -70,7 +70,7 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState
*fw_cfg)
/* tell smbios about cpuid version and features */
smbios_set_cpuid(cpu->env.cpuid_version, cpu->env.features[FEAT_1_EDX]);
-smbios_tables = smbios_get_table_legacy(ms, _tables_len);
+smbios_tables = smbios_get_table_legacy(ms->smp.cpus, _tables_len);
if (smbios_tables) {
fw_cfg_add_bytes(fw_cfg, FW_CFG_SMBIOS_ENTRIES,
smbios_tables, smbios_tables_len);
diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index a1741a64a6..003c539d76 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -70,7 +70,7 @@ static SmbiosEntryPoint ep;
static int smbios_type4_count = 0;
static bool smbios_immutable;
static bool smbios_have_defaults;
-static uint32_t smbios_cpuid_version, smbios_cpuid_features,
smbios_smp_sockets;
+static uint32_t smbios_cpuid_version, smbios_cpuid_features;
static DECLARE_BITMAP(have_binfile_bitmap, SMBIOS_MAX_TYPE+1);
static DECLARE_BITMAP(have_fields_bitmap, SMBIOS_MAX_TYPE+1);
@@ -539,14 +539,11 @@ opts_init(smbios_register_config);
*/
#define SMBIOS_21_MAX_TABLES_LEN 0x
-static void smbios_validate_table(MachineState *ms)
+static void smbios_validate_table(uint32_t expected_t4_count)
{
-uint32_t expect_t4_count = smbios_legacy ?
-ms->smp.cpus : smbios_smp_sockets;
-
-if (smbios_type4_count && smbios_type4_count != expect_t4_count) {
+if (smbios_type4_count && smbios_type4_count != expected_t4_count) {
error_report("Expected %d SMBIOS Type 4 tables, got %d instead",
- expect_t4_count, smbios_type4_count);
+ expected_t4_count, smbios_type4_count);
exit(1);
}
@@ -634,7 +631,7 @@ static void smbios_build_type_1_fields(void)
}
}
-uint8_t *smbios_get_table_legacy(MachineState *ms, size_t *length)
+uint8_t *smbios_get_table_legacy(uint32_t expected_t4_count, size_t *length)
{
if (!smbios_legacy) {
*length = 0;
@@ -644,7 +641,7 @@ uint8_t *smbios_get_table_legacy(MachineState *ms, size_t
*length)
if (!smbios_immutable) {
smbios_build_type_0_fields();
smbios_build_type_1_fields();
-smbios_validate_table(ms);
+smbios_validate_table(expected_t4_count);
smbios_immutable = true;
}
*length = smbios_entries_len;
@@ -1235,10 +1232,9 @@ void smbios_get_tables(MachineState *ms,
smbios_build_type_2_table();
smbios_build_type_3_table();
-smbios_smp_sockets = ms->smp.sockets;
-assert(smbios_smp_sockets >= 1);
+assert(ms->smp.sockets >= 1);
-for (i = 0; i < smbios_smp_sockets; i++) {
+for (i = 0; i < ms->smp.sockets; i++) {
smbios_build_type_4_table(ms, i);
}
@@ -1284,7 +1280,7 @@ void smbios_get_tables(MachineState *ms,
smbios_build_type_41_table(errp);
smbios_build_type_127_table();
-smbios_validate_table(ms);
+smbios_validate_table(ms->smp.sockets);
smbios_entry_point_setup();
smbios_immutable = true;
}
--
MST
[PULL 23/24] tests: acpi: update expected SSDT.dimmpxm blob
From: Igor Mammedov address shift is caused by switch to 32-bit SMBIOS entry point which has slightly different size from 64-bit one and happens to trigger a bit different memory layout. Expected diff: -Name (MEMA, 0x07FFE000) +Name (MEMA, 0x07FFF000) Signed-off-by: Igor Mammedov Acked-by: Ani Sinha Message-Id: <20240314152302.2324164-21-imamm...@redhat.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- tests/qtest/bios-tables-test-allowed-diff.h | 1 - tests/data/acpi/q35/SSDT.dimmpxm| Bin 1815 -> 1815 bytes 2 files changed, 1 deletion(-) diff --git a/tests/qtest/bios-tables-test-allowed-diff.h b/tests/qtest/bios-tables-test-allowed-diff.h index 81148a604f..dfb8523c8b 100644 --- a/tests/qtest/bios-tables-test-allowed-diff.h +++ b/tests/qtest/bios-tables-test-allowed-diff.h @@ -1,2 +1 @@ /* List of comma-separated changed AML files to ignore */ -"tests/data/acpi/q35/SSDT.dimmpxm", diff --git a/tests/data/acpi/q35/SSDT.dimmpxm b/tests/data/acpi/q35/SSDT.dimmpxm index 70f133412f5e0aa128ab210245a8de7304eeb843..9ea4e0d0ceaa8a5cbd706afb6d49de853fafe654 100644 GIT binary patch delta 23 ecmbQvH=U0wIM^jboSlJzam_|9E_UV*|JeaVTLvQl delta 23 ecmbQvH=U0wIM^jboSlJzanD9BE_UVz|JeaVy9Ofw -- MST
[PULL 18/24] smbios: extend smbios-entry-point-type with 'auto' value
From: Igor Mammedov
later patches will use it to pick SMBIOS version at runtime
depending on configuration.
Signed-off-by: Igor Mammedov
Acked-by: Markus Armbruster
Reviewed-by: Ani Sinha
Tested-by: Fiona Ebner
Message-Id: <20240314152302.2324164-16-imamm...@redhat.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
qapi/machine.json | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/qapi/machine.json b/qapi/machine.json
index bb5a178909..0840c91e70 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -1797,10 +1797,13 @@
#
# @64: SMBIOS version 3.0 (64-bit) Entry Point
#
+# @auto: Either 2.x or 3.x SMBIOS version, 2.x if configuration can be
+# described by it and 3.x otherwise (since: 9.0)
+#
# Since: 7.0
##
{ 'enum': 'SmbiosEntryPointType',
- 'data': [ '32', '64' ] }
+ 'data': [ '32', '64', 'auto' ] }
##
# @MemorySizeConfiguration:
--
MST
[PULL 07/24] smbios: cleanup smbios_get_tables() from legacy handling
From: Igor Mammedov
smbios_get_tables() bails out right away if leagacy mode is enabled
and won't generate any SMBIOS tables. At the same time x86 specific
fw_cfg_build_smbios() will genarate legacy tables and then proceed
to preparing temporary mem_array for useless call to
smbios_get_tables() and then discard it.
Drop legacy related check in smbios_get_tables() and return from
fw_cfg_build_smbios() early if legacy tables where built without
proceeding to non legacy part of the function.
Signed-off-by: Igor Mammedov
Reviewed-by: Ani Sinha
Tested-by: Fiona Ebner
Message-Id: <20240314152302.2324164-5-imamm...@redhat.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
hw/i386/fw_cfg.c | 1 +
hw/smbios/smbios.c | 6 --
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
index 98a478c276..a635234e68 100644
--- a/hw/i386/fw_cfg.c
+++ b/hw/i386/fw_cfg.c
@@ -74,6 +74,7 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState
*fw_cfg)
if (smbios_tables) {
fw_cfg_add_bytes(fw_cfg, FW_CFG_SMBIOS_ENTRIES,
smbios_tables, smbios_tables_len);
+return;
}
/* build the array of physical mem area from e820 table */
diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index 949c2d74a1..a1741a64a6 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -1229,12 +1229,6 @@ void smbios_get_tables(MachineState *ms,
{
unsigned i, dimm_cnt, offset;
-if (smbios_legacy) {
-*tables = *anchor = NULL;
-*tables_len = *anchor_len = 0;
-return;
-}
-
if (!smbios_immutable) {
smbios_build_type_0_table();
smbios_build_type_1_table();
--
MST
[PULL 15/24] smbios: handle errors consistently
From: Igor Mammedov
Current code uses mix of error_report()+exit(1)
and error_setg() to handle errors.
Use newer error_setg() everywhere, beside consistency
it will allow to detect error condition without killing
QEMU and attempt switch-over to SMBIOS3.x tables/entrypoint
in follow up patch.
while at it, clear smbios_tables pointer after freeing.
that will avoid double free if smbios_get_tables() is called
multiple times.
Signed-off-by: Igor Mammedov
Reviewed-by: Ani Sinha
Message-Id: <20240314152302.2324164-13-imamm...@redhat.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
include/hw/firmware/smbios.h | 4 ++--
hw/i386/fw_cfg.c | 3 ++-
hw/smbios/smbios.c | 34 ++
hw/smbios/smbios_legacy.c| 22 ++
4 files changed, 40 insertions(+), 23 deletions(-)
diff --git a/include/hw/firmware/smbios.h b/include/hw/firmware/smbios.h
index ccc51e72f5..d4b91d5a14 100644
--- a/include/hw/firmware/smbios.h
+++ b/include/hw/firmware/smbios.h
@@ -326,7 +326,7 @@ struct smbios_type_127 {
struct smbios_structure_header header;
} QEMU_PACKED;
-void smbios_validate_table(void);
+bool smbios_validate_table(Error **errp);
void smbios_add_usr_blob_size(size_t size);
void smbios_entry_add(QemuOpts *opts, Error **errp);
void smbios_set_cpuid(uint32_t version, uint32_t features);
@@ -334,7 +334,7 @@ void smbios_set_defaults(const char *manufacturer, const
char *product,
const char *version,
bool uuid_encoded, SmbiosEntryPointType ep_type);
void smbios_set_default_processor_family(uint16_t processor_family);
-uint8_t *smbios_get_table_legacy(size_t *length);
+uint8_t *smbios_get_table_legacy(size_t *length, Error **errp);
void smbios_get_tables(MachineState *ms,
const struct smbios_phys_mem_area *mem_array,
const unsigned int mem_array_size,
diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
index d1281066f4..e387bf50d0 100644
--- a/hw/i386/fw_cfg.c
+++ b/hw/i386/fw_cfg.c
@@ -71,7 +71,8 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState
*fw_cfg)
smbios_set_cpuid(cpu->env.cpuid_version, cpu->env.features[FEAT_1_EDX]);
if (pcmc->smbios_legacy_mode) {
-smbios_tables = smbios_get_table_legacy(_tables_len);
+smbios_tables = smbios_get_table_legacy(_tables_len,
+_fatal);
fw_cfg_add_bytes(fw_cfg, FW_CFG_SMBIOS_ENTRIES,
smbios_tables, smbios_tables_len);
return;
diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index 242106fd87..f7ca7d77e3 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -19,7 +19,6 @@
#include "qemu/units.h"
#include "qapi/error.h"
#include "qemu/config-file.h"
-#include "qemu/error-report.h"
#include "qemu/module.h"
#include "qemu/option.h"
#include "sysemu/sysemu.h"
@@ -511,23 +510,25 @@ opts_init(smbios_register_config);
*/
#define SMBIOS_21_MAX_TABLES_LEN 0x
-static void smbios_check_type4_count(uint32_t expected_t4_count)
+static bool smbios_check_type4_count(uint32_t expected_t4_count, Error **errp)
{
if (smbios_type4_count && smbios_type4_count != expected_t4_count) {
-error_report("Expected %d SMBIOS Type 4 tables, got %d instead",
- expected_t4_count, smbios_type4_count);
-exit(1);
+error_setg(errp, "Expected %d SMBIOS Type 4 tables, got %d instead",
+ expected_t4_count, smbios_type4_count);
+return false;
}
+return true;
}
-void smbios_validate_table(void)
+bool smbios_validate_table(Error **errp)
{
if (smbios_ep_type == SMBIOS_ENTRY_POINT_TYPE_32 &&
smbios_tables_len > SMBIOS_21_MAX_TABLES_LEN) {
-error_report("SMBIOS 2.1 table length %zu exceeds %d",
- smbios_tables_len, SMBIOS_21_MAX_TABLES_LEN);
-exit(1);
+error_setg(errp, "SMBIOS 2.1 table length %zu exceeds %d",
+ smbios_tables_len, SMBIOS_21_MAX_TABLES_LEN);
+return false;
}
+return true;
}
bool smbios_skip_table(uint8_t type, bool required_table)
@@ -1151,15 +1152,18 @@ void smbios_get_tables(MachineState *ms,
smbios_build_type_41_table(errp);
smbios_build_type_127_table();
-smbios_check_type4_count(ms->smp.sockets);
-smbios_validate_table();
+if (!smbios_check_type4_count(ms->smp.sockets, errp)) {
+goto err_exit;
+}
+if (!smbios_validate_table(errp)) {
+goto err_exit;
+}
smbios_entry_point_setup();
/* return tables blob and entry point (anchor), and their sizes */
*tables = smbios_tables;
*tables_len = smbios_tables_len;
*anchor = (uint8_t *)
-
/* calculate lengt
[PULL 13/24] smbios: rename/expose structures/bitmaps used by both legacy and modern code
From: Igor Mammedov
As a preparation to move legacy handling into a separate file,
add prefix 'smbios_' to type0/type1/have_binfile_bitmap/have_fields_bitmap
and expose them in smbios.h so that they can be reused in
legacy and modern code.
Doing it as a separate patch to avoid rename cluttering follow-up
patch which will move legacy code into a separate file.
Signed-off-by: Igor Mammedov
Reviewed-by: Ani Sinha
Message-Id: <20240314152302.2324164-11-imamm...@redhat.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
include/hw/firmware/smbios.h | 16 +
hw/smbios/smbios.c | 113 ---
2 files changed, 69 insertions(+), 60 deletions(-)
diff --git a/include/hw/firmware/smbios.h b/include/hw/firmware/smbios.h
index 0f0dca8f83..05707c6341 100644
--- a/include/hw/firmware/smbios.h
+++ b/include/hw/firmware/smbios.h
@@ -2,6 +2,7 @@
#define QEMU_SMBIOS_H
#include "qapi/qapi-types-machine.h"
+#include "qemu/bitmap.h"
/*
* SMBIOS Support
@@ -16,8 +17,23 @@
*
*/
+typedef struct {
+const char *vendor, *version, *date;
+bool have_major_minor, uefi;
+uint8_t major, minor;
+} smbios_type0_t;
+extern smbios_type0_t smbios_type0;
+
+typedef struct {
+const char *manufacturer, *product, *version, *serial, *sku, *family;
+/* uuid is in qemu_uuid */
+} smbios_type1_t;
+extern smbios_type1_t smbios_type1;
#define SMBIOS_MAX_TYPE 127
+extern DECLARE_BITMAP(smbios_have_binfile_bitmap, SMBIOS_MAX_TYPE + 1);
+extern DECLARE_BITMAP(smbios_have_fields_bitmap, SMBIOS_MAX_TYPE + 1);
+
#define offsetofend(TYPE, MEMBER) \
(offsetof(TYPE, MEMBER) + sizeof_field(TYPE, MEMBER))
diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index 090a6eb018..6c24fb75d3 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -78,19 +78,11 @@ static int smbios_type4_count = 0;
static bool smbios_have_defaults;
static uint32_t smbios_cpuid_version, smbios_cpuid_features;
-static DECLARE_BITMAP(have_binfile_bitmap, SMBIOS_MAX_TYPE+1);
-static DECLARE_BITMAP(have_fields_bitmap, SMBIOS_MAX_TYPE+1);
+DECLARE_BITMAP(smbios_have_binfile_bitmap, SMBIOS_MAX_TYPE + 1);
+DECLARE_BITMAP(smbios_have_fields_bitmap, SMBIOS_MAX_TYPE + 1);
-static struct {
-const char *vendor, *version, *date;
-bool have_major_minor, uefi;
-uint8_t major, minor;
-} type0;
-
-static struct {
-const char *manufacturer, *product, *version, *serial, *sku, *family;
-/* uuid is in qemu_uuid */
-} type1;
+smbios_type0_t smbios_type0;
+smbios_type1_t smbios_type1;
static struct {
const char *manufacturer, *product, *version, *serial, *asset, *location;
@@ -599,36 +591,36 @@ static void smbios_maybe_add_str(int type, int offset,
const char *data)
static void smbios_build_type_0_fields(void)
{
smbios_maybe_add_str(0, offsetof(struct smbios_type_0, vendor_str),
- type0.vendor);
+ smbios_type0.vendor);
smbios_maybe_add_str(0, offsetof(struct smbios_type_0, bios_version_str),
- type0.version);
+ smbios_type0.version);
smbios_maybe_add_str(0, offsetof(struct smbios_type_0,
bios_release_date_str),
- type0.date);
-if (type0.have_major_minor) {
+ smbios_type0.date);
+if (smbios_type0.have_major_minor) {
smbios_add_field(0, offsetof(struct smbios_type_0,
system_bios_major_release),
- , 1);
+ _type0.major, 1);
smbios_add_field(0, offsetof(struct smbios_type_0,
system_bios_minor_release),
- , 1);
+ _type0.minor, 1);
}
}
static void smbios_build_type_1_fields(void)
{
smbios_maybe_add_str(1, offsetof(struct smbios_type_1, manufacturer_str),
- type1.manufacturer);
+ smbios_type1.manufacturer);
smbios_maybe_add_str(1, offsetof(struct smbios_type_1, product_name_str),
- type1.product);
+ smbios_type1.product);
smbios_maybe_add_str(1, offsetof(struct smbios_type_1, version_str),
- type1.version);
+ smbios_type1.version);
smbios_maybe_add_str(1, offsetof(struct smbios_type_1, serial_number_str),
- type1.serial);
+ smbios_type1.serial);
smbios_maybe_add_str(1, offsetof(struct smbios_type_1, sku_number_str),
- type1.sku);
+ smbios_type1.sku);
smbios_maybe_add_str(1, offsetof(struct smbios_type_1, family_str),
- type1.family);
+ smbios_type1.family);
if (qemu_uuid_set) {
/* We don't encode the UUID
[PULL 14/24] smbios: build legacy mode code only for 'pc' machine
From: Igor Mammedov
basically moving code around without functional change.
And exposing some symbols so that they could be shared
between smbbios.c and new smbios_legacy.c
plus some meson magic to build smbios_legacy.c only
for 'pc' machine and otherwise replace it with stub
if not selected.
Signed-off-by: Igor Mammedov
Reviewed-by: Ani Sinha
Message-Id: <20240314152302.2324164-12-imamm...@redhat.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
include/hw/firmware/smbios.h | 5 +
hw/smbios/smbios.c | 164 +-
hw/smbios/smbios_legacy.c | 179 +
hw/smbios/smbios_legacy_stub.c | 15 +++
hw/i386/Kconfig| 1 +
hw/smbios/Kconfig | 2 +
hw/smbios/meson.build | 4 +
7 files changed, 207 insertions(+), 163 deletions(-)
create mode 100644 hw/smbios/smbios_legacy.c
create mode 100644 hw/smbios/smbios_legacy_stub.c
diff --git a/include/hw/firmware/smbios.h b/include/hw/firmware/smbios.h
index 05707c6341..ccc51e72f5 100644
--- a/include/hw/firmware/smbios.h
+++ b/include/hw/firmware/smbios.h
@@ -17,6 +17,9 @@
*
*/
+extern uint8_t *usr_blobs;
+extern GArray *usr_blobs_sizes;
+
typedef struct {
const char *vendor, *version, *date;
bool have_major_minor, uefi;
@@ -323,6 +326,8 @@ struct smbios_type_127 {
struct smbios_structure_header header;
} QEMU_PACKED;
+void smbios_validate_table(void);
+void smbios_add_usr_blob_size(size_t size);
void smbios_entry_add(QemuOpts *opts, Error **errp);
void smbios_set_cpuid(uint32_t version, uint32_t features);
void smbios_set_defaults(const char *manufacturer, const char *product,
diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index 6c24fb75d3..242106fd87 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -31,38 +31,12 @@
#include "hw/pci/pci_device.h"
#include "smbios_build.h"
-/* legacy structures and constants for <= 2.0 machines */
-struct smbios_header {
-uint16_t length;
-uint8_t type;
-} QEMU_PACKED;
-
-struct smbios_field {
-struct smbios_header header;
-uint8_t type;
-uint16_t offset;
-uint8_t data[];
-} QEMU_PACKED;
-
-struct smbios_table {
-struct smbios_header header;
-uint8_t data[];
-} QEMU_PACKED;
-
-#define SMBIOS_FIELD_ENTRY 0
-#define SMBIOS_TABLE_ENTRY 1
-
-static uint8_t *smbios_entries;
-static size_t smbios_entries_len;
static bool smbios_uuid_encoded = true;
-/* end: legacy structures & constants for <= 2.0 machines */
-
/*
* SMBIOS tables provided by user with '-smbios file=' option
*/
uint8_t *usr_blobs;
size_t usr_blobs_len;
-static GArray *usr_blobs_sizes;
static unsigned usr_table_max;
static unsigned usr_table_cnt;
@@ -546,7 +520,7 @@ static void smbios_check_type4_count(uint32_t
expected_t4_count)
}
}
-static void smbios_validate_table(void)
+void smbios_validate_table(void)
{
if (smbios_ep_type == SMBIOS_ENTRY_POINT_TYPE_32 &&
smbios_tables_len > SMBIOS_21_MAX_TABLES_LEN) {
@@ -556,134 +530,6 @@ static void smbios_validate_table(void)
}
}
-
-/* legacy setup functions for <= 2.0 machines */
-static void smbios_add_field(int type, int offset, const void *data, size_t
len)
-{
-struct smbios_field *field;
-
-if (!smbios_entries) {
-smbios_entries_len = sizeof(uint16_t);
-smbios_entries = g_malloc0(smbios_entries_len);
-}
-smbios_entries = g_realloc(smbios_entries, smbios_entries_len +
- sizeof(*field) + len);
-field = (struct smbios_field *)(smbios_entries + smbios_entries_len);
-field->header.type = SMBIOS_FIELD_ENTRY;
-field->header.length = cpu_to_le16(sizeof(*field) + len);
-
-field->type = type;
-field->offset = cpu_to_le16(offset);
-memcpy(field->data, data, len);
-
-smbios_entries_len += sizeof(*field) + len;
-(*(uint16_t *)smbios_entries) =
-cpu_to_le16(le16_to_cpu(*(uint16_t *)smbios_entries) + 1);
-}
-
-static void smbios_maybe_add_str(int type, int offset, const char *data)
-{
-if (data) {
-smbios_add_field(type, offset, data, strlen(data) + 1);
-}
-}
-
-static void smbios_build_type_0_fields(void)
-{
-smbios_maybe_add_str(0, offsetof(struct smbios_type_0, vendor_str),
- smbios_type0.vendor);
-smbios_maybe_add_str(0, offsetof(struct smbios_type_0, bios_version_str),
- smbios_type0.version);
-smbios_maybe_add_str(0, offsetof(struct smbios_type_0,
- bios_release_date_str),
- smbios_type0.date);
-if (smbios_type0.have_major_minor) {
-smbios_add_field(0, offsetof(struct smbios_type_0,
- system_bios_major_release),
- _type0.majo
[PULL 06/24] tests: smbios: add test for legacy mode CLI options
From: Igor Mammedov
Unfortunately having 2.0 machine type deprecated is not enough
to get rid of legacy SMBIOS handling since 'isapc' also uses
that and it's staying around.
Hence add test for CLI options handling to be sure that it
ain't broken during SMBIOS code refactoring.
Signed-off-by: Igor Mammedov
Reviewed-by: Ani Sinha
Tested-by: Fiona Ebner
Message-Id: <20240314152302.2324164-4-imamm...@redhat.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
tests/qtest/bios-tables-test.c | 17 +
tests/data/smbios/type11_blob.legacy | Bin 0 -> 10 bytes
2 files changed, 17 insertions(+)
create mode 100644 tests/data/smbios/type11_blob.legacy
diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
index a116f88e1d..d1ff4db7a2 100644
--- a/tests/qtest/bios-tables-test.c
+++ b/tests/qtest/bios-tables-test.c
@@ -2106,6 +2106,21 @@ static void test_acpi_pc_smbios_blob(void)
free_test_data();
}
+static void test_acpi_isapc_smbios_legacy(void)
+{
+uint8_t req_type11[] = { 1, 11 };
+test_data data = {
+.machine = "isapc",
+.variant = ".pc_smbios_legacy",
+.required_struct_types = req_type11,
+.required_struct_types_len = ARRAY_SIZE(req_type11),
+};
+
+test_smbios("-smbios file=tests/data/smbios/type11_blob.legacy "
+"-smbios type=1,family=TEST", );
+free_test_data();
+}
+
static void test_oem_fields(test_data *data)
{
int i;
@@ -2261,6 +2276,8 @@ int main(int argc, char *argv[])
test_acpi_pc_smbios_options);
qtest_add_func("acpi/piix4/smbios-blob",
test_acpi_pc_smbios_blob);
+qtest_add_func("acpi/piix4/smbios-legacy",
+ test_acpi_isapc_smbios_legacy);
}
if (qtest_has_machine(MACHINE_Q35)) {
qtest_add_func("acpi/q35", test_acpi_q35_tcg);
diff --git a/tests/data/smbios/type11_blob.legacy
b/tests/data/smbios/type11_blob.legacy
new file mode 100644
index
..aef463aab903405958b0a85f85c5980671c08bee
GIT binary patch
literal 10
Rcmd;PW!S(N;u;*n000Tp0s;U4
literal 0
HcmV?d1
--
MST
[PULL 16/24] smbios: get rid of global smbios_ep_type
From: Igor Mammedov
Signed-off-by: Igor Mammedov
Acked-by: Daniel Henrique Barboza
Reviewed-by: Ani Sinha
Tested-by: Fiona Ebner
Message-Id: <20240314152302.2324164-14-imamm...@redhat.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
hw/i386/fw_cfg.h | 3 ++-
include/hw/firmware/smbios.h | 5 +++--
hw/arm/virt.c| 4 ++--
hw/i386/fw_cfg.c | 8
hw/i386/pc.c | 2 +-
hw/loongarch/virt.c | 7 ---
hw/riscv/virt.c | 6 +++---
hw/smbios/smbios.c | 27 +++
hw/smbios/smbios_legacy.c| 2 +-
9 files changed, 35 insertions(+), 29 deletions(-)
diff --git a/hw/i386/fw_cfg.h b/hw/i386/fw_cfg.h
index 1e1de6b4a3..92e310f5fd 100644
--- a/hw/i386/fw_cfg.h
+++ b/hw/i386/fw_cfg.h
@@ -23,7 +23,8 @@
FWCfgState *fw_cfg_arch_create(MachineState *ms,
uint16_t boot_cpus,
uint16_t apic_id_limit);
-void fw_cfg_build_smbios(PCMachineState *ms, FWCfgState *fw_cfg);
+void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState *fw_cfg,
+ SmbiosEntryPointType ep_type);
void fw_cfg_build_feature_control(MachineState *ms, FWCfgState *fw_cfg);
void fw_cfg_add_acpi_dsdt(Aml *scope, FWCfgState *fw_cfg);
diff --git a/include/hw/firmware/smbios.h b/include/hw/firmware/smbios.h
index d4b91d5a14..8d3fb2fb3b 100644
--- a/include/hw/firmware/smbios.h
+++ b/include/hw/firmware/smbios.h
@@ -326,16 +326,17 @@ struct smbios_type_127 {
struct smbios_structure_header header;
} QEMU_PACKED;
-bool smbios_validate_table(Error **errp);
+bool smbios_validate_table(SmbiosEntryPointType ep_type, Error **errp);
void smbios_add_usr_blob_size(size_t size);
void smbios_entry_add(QemuOpts *opts, Error **errp);
void smbios_set_cpuid(uint32_t version, uint32_t features);
void smbios_set_defaults(const char *manufacturer, const char *product,
const char *version,
- bool uuid_encoded, SmbiosEntryPointType ep_type);
+ bool uuid_encoded);
void smbios_set_default_processor_family(uint16_t processor_family);
uint8_t *smbios_get_table_legacy(size_t *length, Error **errp);
void smbios_get_tables(MachineState *ms,
+ SmbiosEntryPointType ep_type,
const struct smbios_phys_mem_area *mem_array,
const unsigned int mem_array_size,
uint8_t **tables, size_t *tables_len,
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index b634c908a7..a9a913aead 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1651,13 +1651,13 @@ static void virt_build_smbios(VirtMachineState *vms)
smbios_set_defaults("QEMU", product,
vmc->smbios_old_sys_ver ? "1.0" : mc->name,
-true, SMBIOS_ENTRY_POINT_TYPE_64);
+true);
/* build the array of physical mem area from base_memmap */
mem_array.address = vms->memmap[VIRT_MEM].base;
mem_array.length = ms->ram_size;
-smbios_get_tables(ms, _array, 1,
+smbios_get_tables(ms, SMBIOS_ENTRY_POINT_TYPE_64, _array, 1,
_tables, _tables_len,
_anchor, _anchor_len,
_fatal);
diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
index e387bf50d0..d802d2787f 100644
--- a/hw/i386/fw_cfg.c
+++ b/hw/i386/fw_cfg.c
@@ -48,7 +48,8 @@ const char *fw_cfg_arch_key_name(uint16_t key)
return NULL;
}
-void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState *fw_cfg)
+void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState *fw_cfg,
+ SmbiosEntryPointType ep_type)
{
#ifdef CONFIG_SMBIOS
uint8_t *smbios_tables, *smbios_anchor;
@@ -63,8 +64,7 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState
*fw_cfg)
if (pcmc->smbios_defaults) {
/* These values are guest ABI, do not change */
smbios_set_defaults("QEMU", mc->desc, mc->name,
-pcmc->smbios_uuid_encoded,
-pcms->smbios_entry_point_type);
+pcmc->smbios_uuid_encoded);
}
/* tell smbios about cpuid version and features */
@@ -89,7 +89,7 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState
*fw_cfg)
array_count++;
}
}
-smbios_get_tables(ms, mem_array, array_count,
+smbios_get_tables(ms, ep_type, mem_array, array_count,
_tables, _tables_len,
_anchor, _anchor_len,
_fatal);
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index feb7a93083..44eb073abd 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -672,7 +672,7 @@ void pc_machine_done(Notifier *notifier, void *data)
acpi_setup();
if (x86ms->fw_cfg) {
-fw_cfg
[PULL 00/24] virtio,pc,pci: bugfixes
The following changes since commit ba49d760eb04630e7b15f423ebecf6c871b8f77b: Merge tag 'pull-maintainer-final-130324-1' of https://gitlab.com/stsquad/qemu into staging (2024-03-13 15:12:14 +) are available in the Git repository at: https://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream for you to fetch changes up to bb949df637bdb6136a9acca55a2371fe1721e109: smbios: add extra comments to smbios_get_table_legacy() (2024-03-18 08:42:46 -0400) virtio,pc,pci: bugfixes Some minor fixes plus a big patchset from Igor fixing a regression with windows. Signed-off-by: Michael S. Tsirkin Igor Mammedov (21): tests: smbios: make it possible to write SMBIOS only test tests: smbios: add test for -smbios type=11 option tests: smbios: add test for legacy mode CLI options smbios: cleanup smbios_get_tables() from legacy handling smbios: get rid of smbios_smp_sockets global smbios: get rid of smbios_legacy global smbios: avoid mangling user provided tables smbios: don't check type4 structures in legacy mode smbios: add smbios_add_usr_blob_size() helper smbios: rename/expose structures/bitmaps used by both legacy and modern code smbios: build legacy mode code only for 'pc' machine smbios: handle errors consistently smbios: get rid of global smbios_ep_type smbios: clear smbios_type4_count before building tables smbios: extend smbios-entry-point-type with 'auto' value smbios: in case of entry point is 'auto' try to build v2 tables 1st smbios: error out when building type 4 table is not possible tests: acpi/smbios: whitelist expected blobs pc/q35: set SMBIOS entry point type to 'auto' by default tests: acpi: update expected SSDT.dimmpxm blob smbios: add extra comments to smbios_get_table_legacy() Michael S. Tsirkin (2): SMBIOS: fix long lines qapi: document PCIe Gen5/Gen6 speeds since 9.0 Thomas Weißschuh (1): docs/specs/pvpanic: mark shutdown event as not implemented qapi/common.json | 4 +- qapi/machine.json| 5 +- hw/i386/fw_cfg.h | 3 +- include/hw/firmware/smbios.h | 28 +- hw/arm/virt.c| 6 +- hw/i386/fw_cfg.c | 14 +- hw/i386/pc.c | 4 +- hw/i386/pc_piix.c| 4 + hw/i386/pc_q35.c | 3 + hw/loongarch/virt.c | 7 +- hw/riscv/virt.c | 6 +- hw/smbios/smbios.c | 508 +++ hw/smbios/smbios_legacy.c| 192 + hw/smbios/smbios_legacy_stub.c | 15 ++ tests/qtest/bios-tables-test.c | 81 +- docs/specs/pvpanic.rst | 2 +- hw/i386/Kconfig | 1 + hw/smbios/Kconfig| 2 + hw/smbios/meson.build| 4 + tests/data/acpi/q35/SSDT.dimmpxm | Bin 1815 -> 1815 bytes tests/data/smbios/type11_blob| Bin 0 -> 11 bytes tests/data/smbios/type11_blob.legacy | Bin 0 -> 10 bytes 22 files changed, 558 insertions(+), 331 deletions(-) create mode 100644 hw/smbios/smbios_legacy.c create mode 100644 hw/smbios/smbios_legacy_stub.c create mode 100644 tests/data/smbios/type11_blob create mode 100644 tests/data/smbios/type11_blob.legacy
[PULL 09/24] smbios: get rid of smbios_legacy global
From: Igor Mammedov
clean up smbios_set_defaults() which is reused by legacy
and non legacy machines from being aware of 'legacy' notion
and need to turn it off. And push legacy handling up to
PC machine code where it's relevant.
Signed-off-by: Igor Mammedov
Reviewed-by: Ani Sinha
Acked-by: Daniel Henrique Barboza
Tested-by: Fiona Ebner
Message-Id: <20240314152302.2324164-7-imamm...@redhat.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
include/hw/firmware/smbios.h | 2 +-
hw/arm/virt.c| 2 +-
hw/i386/fw_cfg.c | 7 ---
hw/loongarch/virt.c | 2 +-
hw/riscv/virt.c | 2 +-
hw/smbios/smbios.c | 35 +++
6 files changed, 23 insertions(+), 27 deletions(-)
diff --git a/include/hw/firmware/smbios.h b/include/hw/firmware/smbios.h
index 36744b6cc9..7b42e7b4ac 100644
--- a/include/hw/firmware/smbios.h
+++ b/include/hw/firmware/smbios.h
@@ -310,7 +310,7 @@ struct smbios_type_127 {
void smbios_entry_add(QemuOpts *opts, Error **errp);
void smbios_set_cpuid(uint32_t version, uint32_t features);
void smbios_set_defaults(const char *manufacturer, const char *product,
- const char *version, bool legacy_mode,
+ const char *version,
bool uuid_encoded, SmbiosEntryPointType ep_type);
void smbios_set_default_processor_family(uint16_t processor_family);
uint8_t *smbios_get_table_legacy(uint32_t expected_t4_count, size_t *length);
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index e5cd935232..b634c908a7 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1650,7 +1650,7 @@ static void virt_build_smbios(VirtMachineState *vms)
}
smbios_set_defaults("QEMU", product,
-vmc->smbios_old_sys_ver ? "1.0" : mc->name, false,
+vmc->smbios_old_sys_ver ? "1.0" : mc->name,
true, SMBIOS_ENTRY_POINT_TYPE_64);
/* build the array of physical mem area from base_memmap */
diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
index fcb4fb0769..c1e9c0fd9c 100644
--- a/hw/i386/fw_cfg.c
+++ b/hw/i386/fw_cfg.c
@@ -63,15 +63,16 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState
*fw_cfg)
if (pcmc->smbios_defaults) {
/* These values are guest ABI, do not change */
smbios_set_defaults("QEMU", mc->desc, mc->name,
-pcmc->smbios_legacy_mode,
pcmc->smbios_uuid_encoded,
+pcmc->smbios_uuid_encoded,
pcms->smbios_entry_point_type);
}
/* tell smbios about cpuid version and features */
smbios_set_cpuid(cpu->env.cpuid_version, cpu->env.features[FEAT_1_EDX]);
-smbios_tables = smbios_get_table_legacy(ms->smp.cpus, _tables_len);
-if (smbios_tables) {
+if (pcmc->smbios_legacy_mode) {
+smbios_tables = smbios_get_table_legacy(ms->smp.cpus,
+_tables_len);
fw_cfg_add_bytes(fw_cfg, FW_CFG_SMBIOS_ENTRIES,
smbios_tables, smbios_tables_len);
return;
diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
index efce112310..53bfdcee61 100644
--- a/hw/loongarch/virt.c
+++ b/hw/loongarch/virt.c
@@ -355,7 +355,7 @@ static void virt_build_smbios(LoongArchMachineState *lams)
return;
}
-smbios_set_defaults("QEMU", product, mc->name, false,
+smbios_set_defaults("QEMU", product, mc->name,
true, SMBIOS_ENTRY_POINT_TYPE_64);
smbios_get_tables(ms, NULL, 0, _tables, _tables_len,
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index a094af97c3..535fd047ba 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -1275,7 +1275,7 @@ static void virt_build_smbios(RISCVVirtState *s)
product = "KVM Virtual Machine";
}
-smbios_set_defaults("QEMU", product, mc->name, false,
+smbios_set_defaults("QEMU", product, mc->name,
true, SMBIOS_ENTRY_POINT_TYPE_64);
if (riscv_is_32bit(>soc[0])) {
diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index 003c539d76..9f9087601c 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -54,7 +54,6 @@ struct smbios_table {
static uint8_t *smbios_entries;
static size_t smbios_entries_len;
-static bool smbios_legacy = true;
static bool smbios_uuid_encoded = true;
/* end: legacy structures & constants for <= 2.0 machines */
@@ -633,9 +632,16 @@ static void smbios_build_type_1_fields(void)
uint8_t *smbios_get_table_legacy(uint32_t expected_t4_count, size_t *length)
{
-if (!smbios_legacy) {
-*length = 0;
-return NULL;
+/* drop unwanted version of command-line file blob(s) */
+g_free(smbios_tables);
+smbios
[PULL 03/24] docs/specs/pvpanic: mark shutdown event as not implemented
From: Thomas Weißschuh Mention the fact that this event is not yet implemented to avoid confusion. As requested by Michael. Signed-off-by: Thomas Weißschuh Message-Id: <20240313-pvpanic-note-v1-1-7f2571cda...@t-8ch.de> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- docs/specs/pvpanic.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/specs/pvpanic.rst b/docs/specs/pvpanic.rst index 61a80480ed..b0f27860ec 100644 --- a/docs/specs/pvpanic.rst +++ b/docs/specs/pvpanic.rst @@ -29,7 +29,7 @@ bit 1 a guest panic has happened and will be handled by the guest; the host should record it or report it, but should not affect the execution of the guest. -bit 2 +bit 2 (to be implemented) a regular guest shutdown has happened and should be processed by the host PCI Interface -- MST
[PULL 04/24] tests: smbios: make it possible to write SMBIOS only test
From: Igor Mammedov
Cureently it not possible to run SMBIOS test without ACPI one,
which gets into the way when testing ACPI-less configs.
Extract SMBIOS testing into separate routines that could also
be run without ACPI dependency and use that for testing SMBIOS.
As the 1st user add "acpi/piix4/smbios-options" test case.
Signed-off-by: Igor Mammedov
Reviewed-by: Ani Sinha
Tested-by: Fiona Ebner
Message-Id: <20240314152302.2324164-2-imamm...@redhat.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
tests/qtest/bios-tables-test.c | 47 +++---
1 file changed, 38 insertions(+), 9 deletions(-)
diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
index 21811a1ab5..b2992bafa8 100644
--- a/tests/qtest/bios-tables-test.c
+++ b/tests/qtest/bios-tables-test.c
@@ -858,6 +858,27 @@ static void test_vm_prepare(const char *params, test_data
*data)
g_free(args);
}
+static void process_smbios_tables_noexit(test_data *data)
+{
+/*
+ * TODO: make SMBIOS tests work with UEFI firmware,
+ * Bug on uefi-test-tools to provide entry point:
+ * https://bugs.launchpad.net/qemu/+bug/1821884
+ */
+if (!(data->uefi_fl1 && data->uefi_fl2)) {
+SmbiosEntryPointType ep_type = test_smbios_entry_point(data);
+test_smbios_structs(data, ep_type);
+}
+}
+
+static void test_smbios(const char *params, test_data *data)
+{
+test_vm_prepare(params, data);
+boot_sector_test(data->qts);
+process_smbios_tables_noexit(data);
+qtest_quit(data->qts);
+}
+
static void process_acpi_tables_noexit(test_data *data)
{
test_acpi_load_tables(data);
@@ -868,15 +889,7 @@ static void process_acpi_tables_noexit(test_data *data)
test_acpi_asl(data);
}
-/*
- * TODO: make SMBIOS tests work with UEFI firmware,
- * Bug on uefi-test-tools to provide entry point:
- * https://bugs.launchpad.net/qemu/+bug/1821884
- */
-if (!(data->uefi_fl1 && data->uefi_fl2)) {
-SmbiosEntryPointType ep_type = test_smbios_entry_point(data);
-test_smbios_structs(data, ep_type);
-}
+process_smbios_tables_noexit(data);
}
static void process_acpi_tables(test_data *data)
@@ -2064,6 +2077,20 @@ static void test_acpi_q35_pvpanic_isa(void)
free_test_data();
}
+static void test_acpi_pc_smbios_options(void)
+{
+uint8_t req_type11[] = { 11 };
+test_data data = {
+.machine = MACHINE_PC,
+.variant = ".pc_smbios_options",
+.required_struct_types = req_type11,
+.required_struct_types_len = ARRAY_SIZE(req_type11),
+};
+
+test_smbios("-smbios type=11,value=TEST", );
+free_test_data();
+}
+
static void test_oem_fields(test_data *data)
{
int i;
@@ -2215,6 +2242,8 @@ int main(int argc, char *argv[])
#ifdef CONFIG_POSIX
qtest_add_func("acpi/piix4/acpierst", test_acpi_piix4_acpi_erst);
#endif
+qtest_add_func("acpi/piix4/smbios-options",
+ test_acpi_pc_smbios_options);
}
if (qtest_has_machine(MACHINE_Q35)) {
qtest_add_func("acpi/q35", test_acpi_q35_tcg);
--
MST
Re: [PATCH] hw/virtio: Add support for VDPA network simulation devices
On Thu, Mar 14, 2024 at 11:24:33AM +0800, Jason Wang wrote:
> On Thu, Mar 14, 2024 at 3:52 AM Michael S. Tsirkin wrote:
> >
> > On Wed, Mar 13, 2024 at 07:51:08PM +0100, Thomas Weißschuh wrote:
> > > On 2024-02-21 15:38:02+0800, Hao Chen wrote:
> > > > This patch adds support for VDPA network simulation devices.
> > > > The device is developed based on virtio-net and tap backend,
> > > > and supports hardware live migration function.
> > > >
> > > > For more details, please refer to "docs/system/devices/vdpa-net.rst"
> > > >
> > > > Signed-off-by: Hao Chen
> > > > ---
> > > > MAINTAINERS | 5 +
> > > > docs/system/device-emulation.rst| 1 +
> > > > docs/system/devices/vdpa-net.rst| 121 +
> > > > hw/net/virtio-net.c | 16 ++
> > > > hw/virtio/virtio-pci.c | 189 +++-
>
> I think those modifications should belong to a separate file as it
> might conflict with virito features in the future.
>
> > > > hw/virtio/virtio.c | 39
> > > > include/hw/virtio/virtio-pci.h | 5 +
> > > > include/hw/virtio/virtio.h | 19 ++
> > > > include/standard-headers/linux/virtio_pci.h | 7 +
> > > > 9 files changed, 399 insertions(+), 3 deletions(-)
> > > > create mode 100644 docs/system/devices/vdpa-net.rst
> > >
> > > [..]
> > >
> > > > diff --git a/include/standard-headers/linux/virtio_pci.h
> > > > b/include/standard-headers/linux/virtio_pci.h
> > > > index b7fdfd0668..fb5391cef6 100644
> > > > --- a/include/standard-headers/linux/virtio_pci.h
> > > > +++ b/include/standard-headers/linux/virtio_pci.h
> > > > @@ -216,6 +216,13 @@ struct virtio_pci_cfg_cap {
> > > > #define VIRTIO_PCI_COMMON_Q_NDATA 56
> > > > #define VIRTIO_PCI_COMMON_Q_RESET 58
> > > >
> > > > +#define LM_LOGGING_CTRL 0
> > > > +#define LM_BASE_ADDR_LOW4
> > > > +#define LM_BASE_ADDR_HIGH 8
> > > > +#define LM_END_ADDR_LOW 12
> > > > +#define LM_END_ADDR_HIGH16
> > > > +#define LM_VRING_STATE_OFFSET 0x20
> > >
> > > These changes are not in upstream Linux and will be undone by
> > > ./scripts/update-linux-headers.sh.
> > >
> > > Are they intentionally in this header?
> >
> >
> > Good point. Pls move.
>
> Right and this part, it's not a part of standard virtio.
>
> Thanks
I'm thinking of reverting this patch unless there's a resolution
soon, and reapplying later after the release.
> >
> > > > +
> > > > #endif /* VIRTIO_PCI_NO_MODERN */
> > > >
> > > > #endif
> >
Re: [PATCH for-9.0 v3] vdpa-dev: Fix initialisation order to restore VDUSE compatibility
On Fri, Mar 15, 2024 at 04:59:49PM +0100, Kevin Wolf wrote:
> VDUSE requires that virtqueues are first enabled before the DRIVER_OK
> status flag is set; with the current API of the kernel module, it is
> impossible to enable the opposite order in our block export code because
> userspace is not notified when a virtqueue is enabled.
>
> This requirement also mathces the normal initialisation order as done by
> the generic vhost code in QEMU. However, commit 6c482547 accidentally
> changed the order for vdpa-dev and broke access to VDUSE devices with
> this.
>
> This changes vdpa-dev to use the normal order again and use the standard
> vhost callback .vhost_set_vring_enable for this. VDUSE devices can be
> used with vdpa-dev again after this fix.
>
> vhost_net intentionally avoided enabling the vrings for vdpa and does
> this manually later while it does enable them for other vhost backends.
> Reflect this in the vhost_net code and return early for vdpa, so that
> the behaviour doesn't change for this device.
>
> Cc: qemu-sta...@nongnu.org
> Fixes: 6c4825476a4351530bcac17abab72295b75ffe98
Wrong format for the fixes tag.
Fixes: 6c4825476a ("vdpa: move vhost_vdpa_set_vring_ready to the caller")
is the right one.
> Signed-off-by: Kevin Wolf
> ---
> v2:
> - Actually make use of the @enable parameter
> - Change vhost_net to preserve the current behaviour
>
> v3:
> - Updated trace point [Stefano]
> - Fixed typo in comment [Stefano]
>
> hw/net/vhost_net.c | 10 ++
> hw/virtio/vdpa-dev.c | 5 +
> hw/virtio/vhost-vdpa.c | 29 ++---
> hw/virtio/vhost.c | 8 +++-
> hw/virtio/trace-events | 2 +-
> 5 files changed, 45 insertions(+), 9 deletions(-)
>
> diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c
> index e8e1661646..fd1a93701a 100644
> --- a/hw/net/vhost_net.c
> +++ b/hw/net/vhost_net.c
> @@ -541,6 +541,16 @@ int vhost_set_vring_enable(NetClientState *nc, int
> enable)
> VHostNetState *net = get_vhost_net(nc);
> const VhostOps *vhost_ops = net->dev.vhost_ops;
>
> +/*
> + * vhost-vdpa network devices need to enable dataplane virtqueues after
> + * DRIVER_OK, so they can recover device state before starting dataplane.
> + * Because of that, we don't enable virtqueues here and leave it to
> + * net/vhost-vdpa.c.
> + */
> +if (nc->info->type == NET_CLIENT_DRIVER_VHOST_VDPA) {
> +return 0;
> +}
> +
> nc->vring_enable = enable;
>
> if (vhost_ops && vhost_ops->vhost_set_vring_enable) {
> diff --git a/hw/virtio/vdpa-dev.c b/hw/virtio/vdpa-dev.c
> index eb9ecea83b..13e87f06f6 100644
> --- a/hw/virtio/vdpa-dev.c
> +++ b/hw/virtio/vdpa-dev.c
> @@ -253,14 +253,11 @@ static int vhost_vdpa_device_start(VirtIODevice *vdev,
> Error **errp)
>
> s->dev.acked_features = vdev->guest_features;
>
> -ret = vhost_dev_start(>dev, vdev, false);
> +ret = vhost_dev_start(>dev, vdev, true);
> if (ret < 0) {
> error_setg_errno(errp, -ret, "Error starting vhost");
> goto err_guest_notifiers;
> }
> -for (i = 0; i < s->dev.nvqs; ++i) {
> -vhost_vdpa_set_vring_ready(>vdpa, i);
> -}
> s->started = true;
>
> /*
> diff --git a/hw/virtio/vhost-vdpa.c b/hw/virtio/vhost-vdpa.c
> index ddae494ca8..31453466af 100644
> --- a/hw/virtio/vhost-vdpa.c
> +++ b/hw/virtio/vhost-vdpa.c
> @@ -886,19 +886,41 @@ static int vhost_vdpa_get_vq_index(struct vhost_dev
> *dev, int idx)
> return idx;
> }
>
> -int vhost_vdpa_set_vring_ready(struct vhost_vdpa *v, unsigned idx)
> +static int vhost_vdpa_set_vring_enable_one(struct vhost_vdpa *v, unsigned
> idx,
> + int enable)
> {
> struct vhost_dev *dev = v->dev;
> struct vhost_vring_state state = {
> .index = idx,
> -.num = 1,
> +.num = enable,
> };
> int r = vhost_vdpa_call(dev, VHOST_VDPA_SET_VRING_ENABLE, );
>
> -trace_vhost_vdpa_set_vring_ready(dev, idx, r);
> +trace_vhost_vdpa_set_vring_enable_one(dev, idx, enable, r);
> return r;
> }
>
> +static int vhost_vdpa_set_vring_enable(struct vhost_dev *dev, int enable)
> +{
> +struct vhost_vdpa *v = dev->opaque;
> +unsigned int i;
> +int ret;
> +
> +for (i = 0; i < dev->nvqs; ++i) {
> +ret = vhost_vdpa_set_vring_enable_one(v, i, enable);
> +if (ret < 0) {
> +return ret;
> +}
> +}
> +
> +return 0;
> +}
> +
> +int vhost_vdpa_set_vring_ready(struct vhost_vdpa *v, unsigned idx)
> +{
> +return vhost_vdpa_set_vring_enable_one(v, idx, 1);
> +}
> +
> static int vhost_vdpa_set_config_call(struct vhost_dev *dev,
> int fd)
> {
> @@ -1514,6 +1536,7 @@ const VhostOps vdpa_ops = {
> .vhost_set_features = vhost_vdpa_set_features,
> .vhost_reset_device = vhost_vdpa_reset_device,
> .vhost_get_vq_index = vhost_vdpa_get_vq_index,
> +
Re: [PATCH for-9.0 v3] vdpa-dev: Fix initialisation order to restore VDUSE compatibility
On Mon, Mar 18, 2024 at 12:31:26PM +0800, Jason Wang wrote:
> On Fri, Mar 15, 2024 at 11:59 PM Kevin Wolf wrote:
> >
> > VDUSE requires that virtqueues are first enabled before the DRIVER_OK
> > status flag is set; with the current API of the kernel module, it is
> > impossible to enable the opposite order in our block export code because
> > userspace is not notified when a virtqueue is enabled.
> >
> > This requirement also mathces the normal initialisation order as done by
> > the generic vhost code in QEMU. However, commit 6c482547 accidentally
> > changed the order for vdpa-dev and broke access to VDUSE devices with
> > this.
> >
> > This changes vdpa-dev to use the normal order again and use the standard
> > vhost callback .vhost_set_vring_enable for this. VDUSE devices can be
> > used with vdpa-dev again after this fix.
> >
> > vhost_net intentionally avoided enabling the vrings for vdpa and does
> > this manually later while it does enable them for other vhost backends.
> > Reflect this in the vhost_net code and return early for vdpa, so that
> > the behaviour doesn't change for this device.
> >
> > Cc: qemu-sta...@nongnu.org
> > Fixes: 6c4825476a4351530bcac17abab72295b75ffe98
> > Signed-off-by: Kevin Wolf
> > ---
> > v2:
> > - Actually make use of the @enable parameter
> > - Change vhost_net to preserve the current behaviour
> >
> > v3:
> > - Updated trace point [Stefano]
> > - Fixed typo in comment [Stefano]
> >
> > hw/net/vhost_net.c | 10 ++
> > hw/virtio/vdpa-dev.c | 5 +
> > hw/virtio/vhost-vdpa.c | 29 ++---
> > hw/virtio/vhost.c | 8 +++-
> > hw/virtio/trace-events | 2 +-
> > 5 files changed, 45 insertions(+), 9 deletions(-)
> >
> > diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c
> > index e8e1661646..fd1a93701a 100644
> > --- a/hw/net/vhost_net.c
> > +++ b/hw/net/vhost_net.c
> > @@ -541,6 +541,16 @@ int vhost_set_vring_enable(NetClientState *nc, int
> > enable)
> > VHostNetState *net = get_vhost_net(nc);
> > const VhostOps *vhost_ops = net->dev.vhost_ops;
> >
> > +/*
> > + * vhost-vdpa network devices need to enable dataplane virtqueues after
> > + * DRIVER_OK, so they can recover device state before starting
> > dataplane.
> > + * Because of that, we don't enable virtqueues here and leave it to
> > + * net/vhost-vdpa.c.
> > + */
> > +if (nc->info->type == NET_CLIENT_DRIVER_VHOST_VDPA) {
> > +return 0;
> > +}
>
> I think we need some inputs from Eugenio, this is only needed for
> shadow virtqueue during live migration but not other cases.
>
> Thanks
Yes I think we had a backend flag for this, right? Eugenio can you
comment please?
Re: [QEMU PATCH v6 1/1] virtio-pci: implement No_Soft_Reset bit
On Thu, Feb 22, 2024 at 11:40:10AM +0800, Jiqian Chen wrote:
> In current code, when guest does S3, virtio devices are reset due to
> the bit No_Soft_Reset is not set. After resetting, the display resources
> of virtio-gpu are destroyed, then the display can't come back and only
> show blank after resuming.
>
> Implement No_Soft_Reset bit of PCI_PM_CTRL register, then guest can check
> this bit, if this bit is set, the devices resetting will not be done, and
> then the display can work after resuming.
>
> Signed-off-by: Jiqian Chen
> ---
> hw/virtio/virtio-pci.c | 37 +-
> include/hw/virtio/virtio-pci.h | 5 +
> 2 files changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> index 1a7039fb0c68..da5312010345 100644
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
> @@ -2197,6 +2197,11 @@ static void virtio_pci_realize(PCIDevice *pci_dev,
> Error **errp)
> pcie_cap_lnkctl_init(pci_dev);
> }
>
> +if (proxy->flags & VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET) {
> +pci_set_word(pci_dev->config + pos + PCI_PM_CTRL,
> + PCI_PM_CTRL_NO_SOFT_RESET);
> +}
> +
> if (proxy->flags & VIRTIO_PCI_FLAG_INIT_PM) {
> /* Init Power Management Control Register */
> pci_set_word(pci_dev->wmask + pos + PCI_PM_CTRL,
Don't we need compat machinery to avoid breaking migration for
existing machine types?
> @@ -2259,18 +2264,46 @@ static void virtio_pci_reset(DeviceState *qdev)
> }
> }
>
> +static bool device_no_need_reset(PCIDevice *dev)
> +{
> +if (pci_is_express(dev)) {
> +uint16_t pmcsr;
> +
> +pmcsr = pci_get_word(dev->config + dev->exp.pm_cap + PCI_PM_CTRL);
> +/*
> + * When No_Soft_Reset bit is set and device
the device
> + * is in D3hot state, can't reset device
can't? or don't?
> + */
> +if ((pmcsr & PCI_PM_CTRL_NO_SOFT_RESET) &&
> +(pmcsr & PCI_PM_CTRL_STATE_MASK) == 3)
> +return true;
coding style violation
> +}
> +
> +return false;
> +}
> +
> static void virtio_pci_bus_reset_hold(Object *obj)
> {
> PCIDevice *dev = PCI_DEVICE(obj);
> DeviceState *qdev = DEVICE(obj);
>
> +if (device_no_need_reset(dev))
> +return;
> +
> virtio_pci_reset(qdev);
>
> if (pci_is_express(dev)) {
> +uint16_t pmcsr;
> +uint16_t val = 0;
> +
> pcie_cap_deverr_reset(dev);
> pcie_cap_lnkctl_reset(dev);
>
> -pci_set_word(dev->config + dev->exp.pm_cap + PCI_PM_CTRL, 0);
> +/* don't reset the RO bits */
> +pmcsr = pci_get_word(dev->config + dev->exp.pm_cap + PCI_PM_CTRL);
> +val = val | (pmcsr & PCI_PM_CTRL_NO_SOFT_RESET) |
> +(pmcsr & PCI_PM_CTRL_DATA_SCALE_MASK);
> +pci_set_word(dev->config + dev->exp.pm_cap + PCI_PM_CTRL, val);
First, we have test and clear for this.
Second, this has to be conditional on the flag, no?
Without the flag don't we reset everything?
Or you can reuse wmask for this, also an option.
Also what's going on with PCI_PM_CTRL_DATA_SCALE_MASK?
Where does that come from?
> }
> }
>
> @@ -2297,6 +2330,8 @@ static Property virtio_pci_properties[] = {
> VIRTIO_PCI_FLAG_INIT_LNKCTL_BIT, true),
> DEFINE_PROP_BIT("x-pcie-pm-init", VirtIOPCIProxy, flags,
> VIRTIO_PCI_FLAG_INIT_PM_BIT, true),
> +DEFINE_PROP_BIT("x-pcie-pm-no-soft-reset", VirtIOPCIProxy, flags,
> +VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET_BIT, true),
> DEFINE_PROP_BIT("x-pcie-flr-init", VirtIOPCIProxy, flags,
> VIRTIO_PCI_FLAG_INIT_FLR_BIT, true),
> DEFINE_PROP_BIT("aer", VirtIOPCIProxy, flags,
> diff --git a/include/hw/virtio/virtio-pci.h b/include/hw/virtio/virtio-pci.h
> index 59d88018c16a..9e67ba38c748 100644
> --- a/include/hw/virtio/virtio-pci.h
> +++ b/include/hw/virtio/virtio-pci.h
> @@ -43,6 +43,7 @@ enum {
> VIRTIO_PCI_FLAG_INIT_FLR_BIT,
> VIRTIO_PCI_FLAG_AER_BIT,
> VIRTIO_PCI_FLAG_ATS_PAGE_ALIGNED_BIT,
> +VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET_BIT,
> };
>
> /* Need to activate work-arounds for buggy guests at vmstate load. */
> @@ -79,6 +80,10 @@ enum {
> /* Init Power Management */
> #define VIRTIO_PCI_FLAG_INIT_PM (1 << VIRTIO_PCI_FLAG_INIT_PM_BIT)
>
> +/* Init The No_Soft_Reset bit of Power Management */
> +#define VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET \
> + (1 << VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET_BIT)
> +
> /* Init Function Level Reset capability */
> #define VIRTIO_PCI_FLAG_INIT_FLR (1 << VIRTIO_PCI_FLAG_INIT_FLR_BIT)
>
> --
> 2.34.1
Re: [PATCH v4 00/21] Workaround Windows failing to find 64bit SMBIOS entry point with SeaBIOS
On Thu, Mar 14, 2024 at 04:22:41PM +0100, Igor Mammedov wrote: > Changelog: > v4: >* rebase on top of current master due to conflict with > new SMBIOS table 9 commits >* add extra patch with comments about obscure legacy entries counting Thanks a lot for the quick turnaround Igor! > v3: >* whitespace missed by checkpatch >* fix idndent in QAPI >* reorder 17/20 before 1st 'auto' can be used >* pick up acks > v2: >* QAPI style fixes (Markus Armbruster ) >* squash 11/19 into 10/19 (Ani Sinha ) >* split '[PATCH 09/19] smbios: build legacy mode code only for 'pc' > machine' > in 3 smaller patches, to make it more readable >smbios: add smbios_add_usr_blob_size() helper > >smbios: rename/expose structures/bitmaps used by both legacy and > modern code >smbios: build legacy mode code only for 'pc' machine >* pick up acks > > Windows (10) bootloader when running on top of SeaBIOS, fails to find > SMBIOSv3 entry point. Tracing it shows that it looks for v2 anchor markers > only and not v3. Tricking it into believing that entry point is found > lets Windows successfully locate and parse SMBIOSv3 tables. Whether it > will be fixed on Windows side is not clear so here goes a workaround. > > Idea is to try build v2 tables if QEMU configuration permits, > and fallback to v3 tables otherwise. That will mask Windows issue > form majority of users. > However if VM configuration can't be described (typically large VMs) > by v2 tables, QEMU will use SMBIOSv3 and Windows will hit the issue > again. In this case complain to Microsoft and/or use UEFI instead of > SeaBIOS (requires reinstall). > > Default compat setting of smbios-entry-point-type after series > for pc/q35 machines: > * 9.0-newer: 'auto' > * 8.1-8.2: '64' > * 8.0-older: '32' > > Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2008 > > Igor Mammedov (21): > tests: smbios: make it possible to write SMBIOS only test > tests: smbios: add test for -smbios type=11 option > tests: smbios: add test for legacy mode CLI options > smbios: cleanup smbios_get_tables() from legacy handling > smbios: get rid of smbios_smp_sockets global > smbios: get rid of smbios_legacy global > smbios: avoid mangling user provided tables > smbios: don't check type4 structures in legacy mode > smbios: add smbios_add_usr_blob_size() helper > smbios: rename/expose structures/bitmaps used by both legacy and > modern code > smbios: build legacy mode code only for 'pc' machine > smbios: handle errors consistently > smbios: get rid of global smbios_ep_type > smbios: clear smbios_type4_count before building tables > smbios: extend smbios-entry-point-type with 'auto' value > smbios: in case of entry point is 'auto' try to build v2 tables 1st > smbios: error out when building type 4 table is not possible > tests: acpi/smbios: whitelist expected blobs > pc/q35: set SMBIOS entry point type to 'auto' by default > tests: acpi: update expected SSDT.dimmpxm blob > smbios: add extra comments to smbios_get_table_legacy() > > hw/i386/fw_cfg.h | 3 +- > include/hw/firmware/smbios.h | 28 +- > hw/arm/virt.c| 6 +- > hw/i386/Kconfig | 1 + > hw/i386/fw_cfg.c | 14 +- > hw/i386/pc.c | 4 +- > hw/i386/pc_piix.c| 4 + > hw/i386/pc_q35.c | 3 + > hw/loongarch/virt.c | 7 +- > hw/riscv/virt.c | 6 +- > hw/smbios/Kconfig| 2 + > hw/smbios/meson.build| 4 + > hw/smbios/smbios.c | 483 +++ > hw/smbios/smbios_legacy.c| 192 +++ > hw/smbios/smbios_legacy_stub.c | 15 + > qapi/machine.json| 5 +- > tests/data/acpi/q35/SSDT.dimmpxm | Bin 1815 -> 1815 bytes > tests/data/smbios/type11_blob| Bin 0 -> 11 bytes > tests/data/smbios/type11_blob.legacy | Bin 0 -> 10 bytes > tests/qtest/bios-tables-test.c | 81 - > 20 files changed, 541 insertions(+), 317 deletions(-) > create mode 100644 hw/smbios/smbios_legacy.c > create mode 100644 hw/smbios/smbios_legacy_stub.c > create mode 100644 tests/data/smbios/type11_blob > create mode 100644 tests/data/smbios/type11_blob.legacy > > -- > 2.39.3
Re: [PATCH v3 00/20] Workaround Windows failing to find 64bit SMBIOS entry point with SeaBIOS
On Wed, Mar 13, 2024 at 09:49:39AM +0100, Igor Mammedov wrote: > On Tue, 12 Mar 2024 13:31:39 -0400 > "Michael S. Tsirkin" wrote: > > > On Tue, Mar 12, 2024 at 05:10:30PM +0100, Igor Mammedov wrote: > > > Changelog: > > > v3: > > >* whitespace missed by checkpatch > > >* fix idndent in QAPI > > >* reorder 17/20 before 1st 'auto' can be used > > >* pick up acks > > > v2: > > >* QAPI style fixes (Markus Armbruster ) > > >* squash 11/19 into 10/19 (Ani Sinha ) > > >* split '[PATCH 09/19] smbios: build legacy mode code only for 'pc' > > > machine' > > > in 3 smaller patches, to make it more readable > > >smbios: add smbios_add_usr_blob_size() helper > > > > > >smbios: rename/expose structures/bitmaps used by both legacy and > > > modern code > > > > > >smbios: build legacy mode code only for 'pc' machine > > >* pick up acks > > > > thanks! > > of course this conflicts with > > SMBIOS type 9 > > and I am trying to figure out how to resolve this again. > > I'll rebase once your pull req is merged. Note it's merged already. > > Do you ack SMBIOS type 9 btw? > nope, and it seems it's too late do so now. > > > > > > Windows (10) bootloader when running on top of SeaBIOS, fails to find > > > > > > SMBIOSv3 entry point. Tracing it shows that it looks for v2 anchor > > > markers > > > only and not v3. Tricking it into believing that entry point is found > > > > > > lets Windows successfully locate and parse SMBIOSv3 tables. Whether it > > > > > > will be fixed on Windows side is not clear so here goes a workaround. > > > > > > > > > > > > Idea is to try build v2 tables if QEMU configuration permits, > > > > > > and fallback to v3 tables otherwise. That will mask Windows issue > > > > > > form majority of users. > > > > > > However if VM configuration can't be described (typically large VMs) > > > > > > by v2 tables, QEMU will use SMBIOSv3 and Windows will hit the issue > > > > > > again. In this case complain to Microsoft and/or use UEFI instead of > > > > > > SeaBIOS (requires reinstall). > > > > > > > > > > > > Default compat setting of smbios-entry-point-type after series > > > > > > for pc/q35 machines: > > > > > > * 9.0-newer: 'auto' > > > > > > * 8.1-8.2: '64' > > > > > > * 8.0-older: '32' > > > > > > > > > > > > Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2008 > > > > > > CC: imamm...@redhat.com > > > > > > CC: m...@redhat.com > > > > > > Igor Mammedov (20): > > > tests: smbios: make it possible to write SMBIOS only test > > > tests: smbios: add test for -smbios type=11 option > > > tests: smbios: add test for legacy mode CLI options > > > smbios: cleanup smbios_get_tables() from legacy handling > > > smbios: get rid of smbios_smp_sockets global > > > smbios: get rid of smbios_legacy global > > > smbios: avoid mangling user provided tables > > > smbios: don't check type4 structures in legacy mode > > > smbios: add smbios_add_usr_blob_size() helper > > > smbios: rename/expose structures/bitmaps used by both legacy and > > > modern code > > > smbios: build legacy mode code only for 'pc' machine > > > smbios: handle errors consistently > > > smbios: get rid of global s
Re: [PATCH] hw/virtio: Add support for VDPA network simulation devices
On Wed, Mar 13, 2024 at 07:51:08PM +0100, Thomas Weißschuh wrote:
> On 2024-02-21 15:38:02+0800, Hao Chen wrote:
> > This patch adds support for VDPA network simulation devices.
> > The device is developed based on virtio-net and tap backend,
> > and supports hardware live migration function.
> >
> > For more details, please refer to "docs/system/devices/vdpa-net.rst"
> >
> > Signed-off-by: Hao Chen
> > ---
> > MAINTAINERS | 5 +
> > docs/system/device-emulation.rst| 1 +
> > docs/system/devices/vdpa-net.rst| 121 +
> > hw/net/virtio-net.c | 16 ++
> > hw/virtio/virtio-pci.c | 189 +++-
> > hw/virtio/virtio.c | 39
> > include/hw/virtio/virtio-pci.h | 5 +
> > include/hw/virtio/virtio.h | 19 ++
> > include/standard-headers/linux/virtio_pci.h | 7 +
> > 9 files changed, 399 insertions(+), 3 deletions(-)
> > create mode 100644 docs/system/devices/vdpa-net.rst
>
> [..]
>
> > diff --git a/include/standard-headers/linux/virtio_pci.h
> > b/include/standard-headers/linux/virtio_pci.h
> > index b7fdfd0668..fb5391cef6 100644
> > --- a/include/standard-headers/linux/virtio_pci.h
> > +++ b/include/standard-headers/linux/virtio_pci.h
> > @@ -216,6 +216,13 @@ struct virtio_pci_cfg_cap {
> > #define VIRTIO_PCI_COMMON_Q_NDATA 56
> > #define VIRTIO_PCI_COMMON_Q_RESET 58
> >
> > +#define LM_LOGGING_CTRL 0
> > +#define LM_BASE_ADDR_LOW4
> > +#define LM_BASE_ADDR_HIGH 8
> > +#define LM_END_ADDR_LOW 12
> > +#define LM_END_ADDR_HIGH16
> > +#define LM_VRING_STATE_OFFSET 0x20
>
> These changes are not in upstream Linux and will be undone by
> ./scripts/update-linux-headers.sh.
>
> Are they intentionally in this header?
Good point. Pls move.
> > +
> > #endif /* VIRTIO_PCI_NO_MODERN */
> >
> > #endif
Re: [PATCH v1 3/6] intel_iommu: Add a framework to check and sync host IOMMU cap/ecap
On Wed, Mar 13, 2024 at 07:54:11AM +, Duan, Zhenzhong wrote:
>
>
> >-Original Message-----
> >From: Michael S. Tsirkin
> >Subject: Re: [PATCH v1 3/6] intel_iommu: Add a framework to check and
> >sync host IOMMU cap/ecap
> >
> >On Wed, Mar 13, 2024 at 02:52:39AM +, Duan, Zhenzhong wrote:
> >> Hi Michael,
> >>
> >> >-Original Message-
> >> >From: Michael S. Tsirkin
> >> >Subject: Re: [PATCH v1 3/6] intel_iommu: Add a framework to check and
> >> >sync host IOMMU cap/ecap
> >> >
> >> >On Wed, Feb 28, 2024 at 05:44:29PM +0800, Zhenzhong Duan wrote:
> >> >> From: Yi Liu
> >> >>
> >> >> Add a framework to check and synchronize host IOMMU cap/ecap with
> >> >> vIOMMU cap/ecap.
> >> >>
> >> >> The sequence will be:
> >> >>
> >> >> vtd_cap_init() initializes iommu->cap/ecap.
> >> >> vtd_check_hdev() update iommu->cap/ecap based on host cap/ecap.
> >> >> iommu->cap_frozen set when machine create done, iommu->cap/ecap
> >> >become readonly.
> >> >>
> >> >> Implementation details for different backends will be in following
> >patches.
> >> >>
> >> >> Signed-off-by: Yi Liu
> >> >> Signed-off-by: Yi Sun
> >> >> Signed-off-by: Zhenzhong Duan
> >> >> ---
> >> >> include/hw/i386/intel_iommu.h | 1 +
> >> >> hw/i386/intel_iommu.c | 50
> >> >++-
> >> >> 2 files changed, 50 insertions(+), 1 deletion(-)
> >> >>
> >> >> diff --git a/include/hw/i386/intel_iommu.h
> >> >b/include/hw/i386/intel_iommu.h
> >> >> index bbc7b96add..c71a133820 100644
> >> >> --- a/include/hw/i386/intel_iommu.h
> >> >> +++ b/include/hw/i386/intel_iommu.h
> >> >> @@ -283,6 +283,7 @@ struct IntelIOMMUState {
> >> >>
> >> >> uint64_t cap; /* The value of capability reg */
> >> >> uint64_t ecap; /* The value of extended
> >> >> capability reg */
> >> >> +bool cap_frozen;/* cap/ecap become read-only after
> >frozen */
> >> >>
> >> >> uint32_t context_cache_gen; /* Should be in [1,MAX] */
> >> >> GHashTable *iotlb; /* IOTLB */
> >> >> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> >> >> index ffa1ad6429..a9f9dfd6a7 100644
> >> >> --- a/hw/i386/intel_iommu.c
> >> >> +++ b/hw/i386/intel_iommu.c
> >> >> @@ -35,6 +35,8 @@
> >> >> #include "sysemu/kvm.h"
> >> >> #include "sysemu/dma.h"
> >> >> #include "sysemu/sysemu.h"
> >> >> +#include "hw/vfio/vfio-common.h"
> >> >> +#include "sysemu/iommufd.h"
> >> >> #include "hw/i386/apic_internal.h"
> >> >> #include "kvm/kvm_i386.h"
> >> >> #include "migration/vmstate.h"
> >> >> @@ -3819,6 +3821,38 @@ VTDAddressSpace
> >> >*vtd_find_add_as(IntelIOMMUState *s, PCIBus *bus,
> >> >> return vtd_dev_as;
> >> >> }
> >> >>
> >> >> +static int vtd_check_legacy_hdev(IntelIOMMUState *s,
> >> >> + IOMMULegacyDevice *ldev,
> >> >> + Error **errp)
> >> >> +{
> >> >> +return 0;
> >> >> +}
> >> >> +
> >> >> +static int vtd_check_iommufd_hdev(IntelIOMMUState *s,
> >> >> + IOMMUFDDevice *idev,
> >> >> + Error **errp)
> >> >> +{
> >> >> +return 0;
> >> >> +}
> >> >> +
> >> >> +static int vtd_check_hdev(IntelIOMMUState *s,
> >VTDHostIOMMUDevice
> >> >*vtd_hdev,
> >> >> + Error **errp)
> >> >> +{
> >> >> +HostIOMMUDevice *base_dev = vtd_hdev->dev;
> >> >> +IOMMUFDDevice *idev;
> >> >> +
> >> >> +if (base_dev->type == HID_LEGACY) {
> >> >> +IOMMULegacyDevice *ldev = container_of(base_dev,
>
Re: [PATCH v4 0/3] Adjust the output of x-query-virtio-status
On Wed, Mar 13, 2024 at 10:40:21AM +0100, Markus Armbruster wrote:
> I could be awkward for the use case described in PATCH 1's commit
> message:
>
> However, we sometimes want to compare features and status bits without
> caring for their exact meaning. Say we want to verify the correctness
> of the virtio negotiation between guest, QEMU, and OVS-DPDK. We can use
> QMP command x-query-virtio-status to retrieve vhost-user net device
> features, and the "ovs-vsctl list interface" command to retrieve
> interface features. Without commit f3034ad71fc, we could then simply
> compare the numbers. With this commit, we first have to map from the
> strings back to the numeric encoding.
So, consider how guest kernel presents features then. Do you happen to know?
It's actually a binary string:
static ssize_t features_show(struct device *_d,
struct device_attribute *attr, char *buf)
{
struct virtio_device *dev = dev_to_virtio(_d);
unsigned int i;
ssize_t len = 0;
/* We actually represent this as a bitstring, as it could be
* arbitrary length in future. */
for (i = 0; i < sizeof(dev->features)*8; i++)
len += sysfs_emit_at(buf, len, "%c",
__virtio_test_bit(dev, i) ? '1' : '0');
len += sysfs_emit_at(buf, len, "\n");
return len;
}
static DEVICE_ATTR_RO(features);
--
MST
Re: [PATCH v4 0/3] Adjust the output of x-query-virtio-status
On Wed, Mar 13, 2024 at 10:40:21AM +0100, Markus Armbruster wrote:
> "Michael S. Tsirkin" writes:
>
> > On Wed, Mar 13, 2024 at 09:20:08AM +0100, Markus Armbruster wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >> > On Wed, Feb 21, 2024 at 10:28:50PM +0800, Hyman Huang wrote:
> >> >> v4:
> >> >> - Rebase on master
> >> >> - Fix the syntax mistake within the commit message of [PATCH v3 1/3]
> >> >> - Adjust the linking file in hw/virtio/meson.build suggested by Markus
> >> >>
> >> >> Please review,
> >> >> Yong
> >> >
> >> > I'm still not excited about this.
> >> > For one this will not scale when we add more than 64 feature bits.
> >>
> >> x-query-virtio-status is meant to be a low effort, low level debugging
> >> aid. Its feature set members correspond 1:1 to uint64_t members of the
> >> C struct, which I figure correspond 1:1 to 64-bit words in the binary
> >> virtio interface.
> >> If we run out of bits in the binary virtio interface, I guess we'd add
> >> another 64-bit word. The C struct acquires another uint64_t member, and
> >> so does x-query-virtio-status.
> >>
> >> What's wrong with that?
> >
> > Nope, that last part about virtio binary interface is wrong. virtio does
> > not have a 64-bit word in it's ABI, it has an array of bits represented,
> > depending on a transport, as a dynamically sized array of 32-bit words
> > (PCI, MMIO) or a dynamically sized array of bytes (CCW).
>
> Then have x-query-virtio-status return a suitable array of unsigned
> numbers. Look ma, no invention!
Then with bit 53 in spec user has to squint hard and do okay
53/32=1 so array entry 1 and 53%32=21 so bit 21 there.
And for ccw it's just completely weird they have a byte array.
No one wants these words everyone works with bit #s this
is what's in spec.
> > We are beginning to get closer to filling up 64 bits for some devices
> > so I'm already looking at not baking 64 bit in new code.
> >
> >>
> >> > As long as we are changing this let's address this please.
> >> > I would also suggest just keeping the name in there, so
> >> > a decoded feature will be
> >> > [0, NAME]
> >> > and a non-decoded will be just
> >> > [23]
> >> >
> >> > will make for a smaller change.
> >>
> >> I'm not sure I understand your suggestion.
> >>
> >> [...]
> >
> > For example, for the balloon device:
> >
> > instead of e.g. 0x201 as this patch would do,
> > I propose [ [{0, "VIRTIO_BALLOON_F_MUST_TELL_HOST" }, {9, ""}] ].
>
> Syntactially invalid. I guess you mean something like
>
> [{"bit": 0, "name": "VIRTIO_BALLOON_F_MUST_TELL_HOST"},
> {"bit": 9, "name": ""}]
>
> or with optional @name
>
> [{"bit": 0, "name": "VIRTIO_BALLOON_F_MUST_TELL_HOST"},
> {"bit": 9}]
>
> This is an awfully verbose encoding of an n-bit number, even if we omit
> "VIRTIO_BALLOON_F_" as noise.
>
> I could be awkward for the use case described in PATCH 1's commit
> message:
>
> However, we sometimes want to compare features and status bits without
> caring for their exact meaning. Say we want to verify the correctness
> of the virtio negotiation between guest, QEMU, and OVS-DPDK. We can use
> QMP command x-query-virtio-status to retrieve vhost-user net device
> features, and the "ovs-vsctl list interface" command to retrieve
> interface features. Without commit f3034ad71fc, we could then simply
> compare the numbers. With this commit, we first have to map from the
> strings back to the numeric encoding.
>
> It next describes the patch's solution:
>
> Revert the decoding for QMP, but keep it for HMP.
>
> This makes the QMP command easier to use for use cases where we
> don't need to decode, like the comparison above. For use cases
> where we need to decode, we replace parsing undocumented strings by
> decoding virtio's well-known binary encoding.
>
> Since this is not a stable interface, instead of a perfect (and to my
> subjective self overengineered) solution at some future point, I'd
> prefer to get in a simple one *now*, even if we may have to evolve it
> later.
Re: [PATCH] qapi: document PCIe Gen5/Gen6 speeds since 9.0
On Wed, Mar 13, 2024 at 11:22:43AM +0100, Philippe Mathieu-Daudé wrote:
> On 13/3/24 11:14, Philippe Mathieu-Daudé wrote:
> > On 13/3/24 07:50, Michael S. Tsirkin wrote:
> > > Document that PCIe Gen5/Gen6 speeds are only in QAPI
> > > since 9.0 - the rest is since 4.0.
> > >
> > > Cc: Lukas Stockner
> > > Cc: Marcel Apfelbaum
> > > Fixes: c08da86dc4 ("pcie: Support PCIe Gen5/Gen6 link speeds")
>
> (BTW if you have to repost your pullreq as v2, you could
> squash this change).
Does not break bisect in any way, it's a comment so I do
not see a reason to squash.
> > > Suggested-by: Markus Armbruster
> > > Signed-off-by: Michael S. Tsirkin
> > > ---
> > > qapi/common.json | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > Reviewed-by: Philippe Mathieu-Daudé
> >
> >
Re: [PATCH v4 0/3] Adjust the output of x-query-virtio-status
On Wed, Mar 13, 2024 at 09:20:08AM +0100, Markus Armbruster wrote:
> "Michael S. Tsirkin" writes:
>
> > On Wed, Feb 21, 2024 at 10:28:50PM +0800, Hyman Huang wrote:
> >> v4:
> >> - Rebase on master
> >> - Fix the syntax mistake within the commit message of [PATCH v3 1/3]
> >> - Adjust the linking file in hw/virtio/meson.build suggested by Markus
> >>
> >> Please review,
> >> Yong
> >
> > I'm still not excited about this.
> > For one this will not scale when we add more than 64 feature bits.
>
> x-query-virtio-status is meant to be a low effort, low level debugging
> aid. Its feature set members correspond 1:1 to uint64_t members of the
> C struct, which I figure correspond 1:1 to 64-bit words in the binary
> virtio interface.
> If we run out of bits in the binary virtio interface, I guess we'd add
> another 64-bit word. The C struct acquires another uint64_t member, and
> so does x-query-virtio-status.
>
> What's wrong with that?
Nope, that last part about virtio binary interface is wrong. virtio does
not have a 64-bit word in it's ABI, it has an array of bits represented,
depending on a transport, as a dynamically sized array of 32-bit words
(PCI, MMIO) or a dynamically sized array of bytes (CCW).
We are beginning to get closer to filling up 64 bits for some devices
so I'm already looking at not baking 64 bit in new code.
>
> > As long as we are changing this let's address this please.
> > I would also suggest just keeping the name in there, so
> > a decoded feature will be
> > [0, NAME]
> > and a non-decoded will be just
> > [23]
> >
> > will make for a smaller change.
>
> I'm not sure I understand your suggestion.
>
> [...]
For example, for the balloon device:
instead of e.g. 0x201 as this patch would do,
I propose [ [{0, "VIRTIO_BALLOON_F_MUST_TELL_HOST" }, {9, ""}] ].
--
MST
Re: [PATCH v3 00/20] Workaround Windows failing to find 64bit SMBIOS entry point with SeaBIOS
On Wed, Mar 13, 2024 at 09:49:39AM +0100, Igor Mammedov wrote: > On Tue, 12 Mar 2024 13:31:39 -0400 > "Michael S. Tsirkin" wrote: > > > On Tue, Mar 12, 2024 at 05:10:30PM +0100, Igor Mammedov wrote: > > > Changelog: > > > v3: > > >* whitespace missed by checkpatch > > >* fix idndent in QAPI > > >* reorder 17/20 before 1st 'auto' can be used > > >* pick up acks > > > v2: > > >* QAPI style fixes (Markus Armbruster ) > > >* squash 11/19 into 10/19 (Ani Sinha ) > > >* split '[PATCH 09/19] smbios: build legacy mode code only for 'pc' > > > machine' > > > in 3 smaller patches, to make it more readable > > >smbios: add smbios_add_usr_blob_size() helper > > > > > >smbios: rename/expose structures/bitmaps used by both legacy and > > > modern code > > > > > >smbios: build legacy mode code only for 'pc' machine > > >* pick up acks > > > > thanks! > > of course this conflicts with > > SMBIOS type 9 > > and I am trying to figure out how to resolve this again. > > I'll rebase once your pull req is merged. > > > Do you ack SMBIOS type 9 btw? > nope, and it seems it's too late do so now. I mean if there's a big problem I can always revert after freeze or we can apply a fixup. > > > > > Windows (10) bootloader when running on top of SeaBIOS, fails to find > > > > > > SMBIOSv3 entry point. Tracing it shows that it looks for v2 anchor > > > markers > > > only and not v3. Tricking it into believing that entry point is found > > > > > > lets Windows successfully locate and parse SMBIOSv3 tables. Whether it > > > > > > will be fixed on Windows side is not clear so here goes a workaround. > > > > > > > > > > > > Idea is to try build v2 tables if QEMU configuration permits, > > > > > > and fallback to v3 tables otherwise. That will mask Windows issue > > > > > > form majority of users. > > > > > > However if VM configuration can't be described (typically large VMs) > > > > > > by v2 tables, QEMU will use SMBIOSv3 and Windows will hit the issue > > > > > > again. In this case complain to Microsoft and/or use UEFI instead of > > > > > > SeaBIOS (requires reinstall). > > > > > > > > > > > > Default compat setting of smbios-entry-point-type after series > > > > > > for pc/q35 machines: > > > > > > * 9.0-newer: 'auto' > > > > > > * 8.1-8.2: '64' > > > > > > * 8.0-older: '32' > > > > > > > > > > > > Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2008 > > > > > > CC: imamm...@redhat.com > > > > > > CC: m...@redhat.com > > > > > > Igor Mammedov (20): > > > tests: smbios: make it possible to write SMBIOS only test > > > tests: smbios: add test for -smbios type=11 option > > > tests: smbios: add test for legacy mode CLI options > > > smbios: cleanup smbios_get_tables() from legacy handling > > > smbios: get rid of smbios_smp_sockets global > > > smbios: get rid of smbios_legacy global > > > smbios: avoid mangling user provided tables > > > smbios: don't check type4 structures in legacy mode > > > smbios: add smbios_add_usr_blob_size() helper > > > smbios: rename/expose structures/bitmaps used by both legacy and > > > modern code > > > smbios: build legacy mode code only for 'pc' machine > > > smbios:
Re: [PATCH v1 3/6] intel_iommu: Add a framework to check and sync host IOMMU cap/ecap
On Wed, Mar 13, 2024 at 02:52:39AM +, Duan, Zhenzhong wrote:
> Hi Michael,
>
> >-Original Message-----
> >From: Michael S. Tsirkin
> >Subject: Re: [PATCH v1 3/6] intel_iommu: Add a framework to check and
> >sync host IOMMU cap/ecap
> >
> >On Wed, Feb 28, 2024 at 05:44:29PM +0800, Zhenzhong Duan wrote:
> >> From: Yi Liu
> >>
> >> Add a framework to check and synchronize host IOMMU cap/ecap with
> >> vIOMMU cap/ecap.
> >>
> >> The sequence will be:
> >>
> >> vtd_cap_init() initializes iommu->cap/ecap.
> >> vtd_check_hdev() update iommu->cap/ecap based on host cap/ecap.
> >> iommu->cap_frozen set when machine create done, iommu->cap/ecap
> >become readonly.
> >>
> >> Implementation details for different backends will be in following patches.
> >>
> >> Signed-off-by: Yi Liu
> >> Signed-off-by: Yi Sun
> >> Signed-off-by: Zhenzhong Duan
> >> ---
> >> include/hw/i386/intel_iommu.h | 1 +
> >> hw/i386/intel_iommu.c | 50
> >++-
> >> 2 files changed, 50 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/include/hw/i386/intel_iommu.h
> >b/include/hw/i386/intel_iommu.h
> >> index bbc7b96add..c71a133820 100644
> >> --- a/include/hw/i386/intel_iommu.h
> >> +++ b/include/hw/i386/intel_iommu.h
> >> @@ -283,6 +283,7 @@ struct IntelIOMMUState {
> >>
> >> uint64_t cap; /* The value of capability reg */
> >> uint64_t ecap; /* The value of extended capability
> >> reg */
> >> +bool cap_frozen;/* cap/ecap become read-only after
> >> frozen */
> >>
> >> uint32_t context_cache_gen; /* Should be in [1,MAX] */
> >> GHashTable *iotlb; /* IOTLB */
> >> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> >> index ffa1ad6429..a9f9dfd6a7 100644
> >> --- a/hw/i386/intel_iommu.c
> >> +++ b/hw/i386/intel_iommu.c
> >> @@ -35,6 +35,8 @@
> >> #include "sysemu/kvm.h"
> >> #include "sysemu/dma.h"
> >> #include "sysemu/sysemu.h"
> >> +#include "hw/vfio/vfio-common.h"
> >> +#include "sysemu/iommufd.h"
> >> #include "hw/i386/apic_internal.h"
> >> #include "kvm/kvm_i386.h"
> >> #include "migration/vmstate.h"
> >> @@ -3819,6 +3821,38 @@ VTDAddressSpace
> >*vtd_find_add_as(IntelIOMMUState *s, PCIBus *bus,
> >> return vtd_dev_as;
> >> }
> >>
> >> +static int vtd_check_legacy_hdev(IntelIOMMUState *s,
> >> + IOMMULegacyDevice *ldev,
> >> + Error **errp)
> >> +{
> >> +return 0;
> >> +}
> >> +
> >> +static int vtd_check_iommufd_hdev(IntelIOMMUState *s,
> >> + IOMMUFDDevice *idev,
> >> + Error **errp)
> >> +{
> >> +return 0;
> >> +}
> >> +
> >> +static int vtd_check_hdev(IntelIOMMUState *s, VTDHostIOMMUDevice
> >*vtd_hdev,
> >> + Error **errp)
> >> +{
> >> +HostIOMMUDevice *base_dev = vtd_hdev->dev;
> >> +IOMMUFDDevice *idev;
> >> +
> >> +if (base_dev->type == HID_LEGACY) {
> >> +IOMMULegacyDevice *ldev = container_of(base_dev,
> >> + IOMMULegacyDevice, base);
> >> +
> >> +return vtd_check_legacy_hdev(s, ldev, errp);
> >> +}
> >> +
> >> +idev = container_of(base_dev, IOMMUFDDevice, base);
> >> +
> >> +return vtd_check_iommufd_hdev(s, idev, errp);
> >> +}
> >> +
> >> static int vtd_dev_set_iommu_device(PCIBus *bus, void *opaque, int
> >devfn,
> >> HostIOMMUDevice *base_dev, Error
> >> **errp)
> >> {
> >> @@ -3829,6 +3863,7 @@ static int vtd_dev_set_iommu_device(PCIBus
> >*bus, void *opaque, int devfn,
> >> .devfn = devfn,
> >> };
> >> struct vtd_as_key *new_key;
> >> +int ret;
> >>
> >> assert(base_dev);
> >>
> >> @@ -3848,6 +3883,13 @@ static int vtd_dev_set_iommu_device(PCIBus
> >*bus, void *opaque, int devfn,
> >> vtd
[PATCH] qapi: document PCIe Gen5/Gen6 speeds since 9.0
Document that PCIe Gen5/Gen6 speeds are only in QAPI
since 9.0 - the rest is since 4.0.
Cc: Lukas Stockner
Cc: Marcel Apfelbaum
Fixes: c08da86dc4 ("pcie: Support PCIe Gen5/Gen6 link speeds")
Suggested-by: Markus Armbruster
Signed-off-by: Michael S. Tsirkin
---
qapi/common.json | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/qapi/common.json b/qapi/common.json
index 867a9ad9b0..7558ce5430 100644
--- a/qapi/common.json
+++ b/qapi/common.json
@@ -107,9 +107,9 @@
#
# @16: 16.0GT/s
#
-# @32: 32.0GT/s
+# @32: 32.0GT/s (since 9.0)
#
-# @64: 64.0GT/s
+# @64: 64.0GT/s (since 9.0)
#
# Since: 4.0
##
--
MST
[PATCH repost] SMBIOS: fix long lines
Break up long lines to fit under 80/90 char limit.
Fixes: 04f143d828 ("Implement SMBIOS type 9 v2.6")
Fixes: 735eee07d1 ("Implement base of SMBIOS type 9 descriptor.")
Cc: "Felix Wu"
Cc: Nabih Estefan
Reviewed-by: Ani Sinha
Signed-off-by: Michael S. Tsirkin
---
hw/smbios/smbios.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index e3d5d8f2e2..949c2d74a1 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -1592,12 +1592,15 @@ void smbios_entry_add(QemuOpts *opts, Error **errp)
t = g_new0(struct type9_instance, 1);
save_opt(>slot_designation, opts, "slot_designation");
t->slot_type = qemu_opt_get_number(opts, "slot_type", 0);
-t->slot_data_bus_width = qemu_opt_get_number(opts,
"slot_data_bus_width", 0);
+t->slot_data_bus_width =
+qemu_opt_get_number(opts, "slot_data_bus_width", 0);
t->current_usage = qemu_opt_get_number(opts, "current_usage", 0);
t->slot_length = qemu_opt_get_number(opts, "slot_length", 0);
t->slot_id = qemu_opt_get_number(opts, "slot_id", 0);
-t->slot_characteristics1 = qemu_opt_get_number(opts,
"slot_characteristics1", 0);
-t->slot_characteristics2 = qemu_opt_get_number(opts,
"slot_characteristics2", 0);
+t->slot_characteristics1 =
+qemu_opt_get_number(opts, "slot_characteristics1", 0);
+t->slot_characteristics2 =
+qemu_opt_get_number(opts, "slot_characteristics2", 0);
save_opt(>pcidev, opts, "pcidev");
QTAILQ_INSERT_TAIL(, t, next);
return;
--
MST
