Without it, it seems the data gets garbage at the end of the string.
Signed-off-by: Valentin David
---
hw/smbios/smbios.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index 02a09eb9cd..7522e9a172 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios
On Thu, Apr 3, 2025 at 9:37 PM Philippe Mathieu-Daudé
wrote:
> Also I was hoping I could get feedback from Valentin.
>
>
Sorry, I did not realize that you wanted my feedback. Daan's patch looks
fine to me. I have manually tested it and it fixes my issue.
Yes.
On Fri, Apr 4, 2025 at 5:02 PM Philippe Mathieu-Daudé
wrote:
> On 4/4/25 16:46, Valentin David wrote:
> > On Thu, Apr 3, 2025 at 9:37 PM Philippe Mathieu-Daudé > <mailto:phi...@linaro.org>> wrote:
> >
> > Also I was hoping I could get feedback from V
Re-opened as https://gitlab.com/qemu-project/qemu/-/issues/285
** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #285
https://gitlab.com/qemu-project/qemu/-/issues/285
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https:
Public bug reported:
I and others have recently been using qemu-user for RISCV64 extensively. We
have had many hangs. We have found that hangs happen in process with multiple
threads and forking. For example
`cargo` (a tool for the Rust compiler).
It does not matter if there are a lot of calls
Public bug reported:
I have a bootable image where GNOME Shell fails because it hits a limit
in virtio-gpu.
In `hw/display/virtio-gpu.c`, there is a limit for `nr_entries` at
16384. There is no explanation for that limit. But there does not seem
to be any limit on the kernel side.
Raising this l
