Hello Peter,
On Mon, 3 Mar 2025 at 20:20, Peter Xu wrote:
> We need the header.
* We need a section type, which is sent by qemu_savevm_command_send()
as 'QEMU_VM_COMMAND'.
> Maybe the easiest as of now is one more hook like
> qemu_savevm_state_complete_precopy_prepare(), and only use it in RAM
The following changes since commit b69801dd6b1eb4d107f7c2f643adf0a4e3ec9124:
Merge tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu
into staging (2025-02-22 05:06:39 +0800)
are available in the Git repository at:
https://repo.or.cz/qemu/armbru.git tags/pull-qapi-2025-0
On Tue, Mar 04, 2025 at 11:33:44AM +, Alex Bennée wrote:
> Daniel P. Berrangé writes:
>
> > On Mon, Mar 03, 2025 at 10:17:03PM +, Alex Bennée wrote:
> >> This option is supported by both gcc (since 4.7) and clang (since
> >> 7.0). Not only does this make the linkers job easier by reducing
Daniel P. Berrangé writes:
> On Mon, Mar 03, 2025 at 10:17:03PM +, Alex Bennée wrote:
>> This option is supported by both gcc (since 4.7) and clang (since
>> 7.0). Not only does this make the linkers job easier by reducing the
>> amount of ELF it needs to parse it also reduces the total build
Peter Maydell writes:
> GCC versions at least 12 through 15 incorrectly report a warning
> about code in sha1.c:
>
> tests/tcg/multiarch/sha1.c:161:13: warning: ‘SHA1Transform’ reading 64 bytes
> from a region of size 0 [-Wstringop-overread]
> 161 | SHA1Transform(context->state, &d
Add trace events for debugging and trouble shooting.
Signed-off-by: Gerd Hoffmann
Message-ID: <20250225163031.1409078-16-kra...@redhat.com>
---
hw/uefi/trace-events | 17 +
1 file changed, 17 insertions(+)
create mode 100644 hw/uefi/trace-events
diff --git a/hw/uefi/trace-event
On Tue, Mar 04, 2025 at 12:11:25PM +, Daniel P. Berrangé wrote:
> On Tue, Mar 04, 2025 at 11:33:44AM +, Alex Bennée wrote:
> > Daniel P. Berrangé writes:
> >
> > > On Mon, Mar 03, 2025 at 10:17:03PM +, Alex Bennée wrote:
> > >> This option is supported by both gcc (since 4.7) and clan
Signed-off-by: Mauro Carvalho Chehab
---
hw/i386/acpi-build.c | 42 ++
hw/i386/pc.c | 7 +++
include/hw/i386/x86.h | 2 ++
3 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index cf11
A bunch of #defines and structs copied over from edk2,
mostly needed to decode and encode the messages in the
communication buffer.
Signed-off-by: Gerd Hoffmann
Message-ID: <20250225163031.1409078-4-kra...@redhat.com>
---
include/hw/uefi/var-service-edk2.h | 227 +
1
The following changes since commit 661c2e1ab29cd9c4d268ae3f44712e8d421c0e56:
scripts/checkpatch: Fix a typo (2025-03-04 09:30:26 +0800)
are available in the Git repository at:
https://gitlab.com/kraxel/qemu.git tags/firmware-20250304-pull-request
for you to fetch changes up to
edk2 looks for the etc/hardware-info fw_cfg file to discover hardware
which can not easily be found in other ways. Entries consist of a
header with hardware type and entry size (HARDWARE_INFO_HEADER),
followed by the actual hardware description (which is type specific).
The file can have multiple
Add variables for a bunch of UEFI GUIDs we will need.
Signed-off-by: Gerd Hoffmann
Message-ID: <20250225163031.1409078-6-kra...@redhat.com>
---
hw/uefi/var-service-guid.c | 99 ++
1 file changed, 99 insertions(+)
create mode 100644 hw/uefi/var-service-guid.c
This is the core code for guest <-> host communication. This accepts
request messages from the guest, dispatches them to the service called,
and sends back the response message.
Signed-off-by: Gerd Hoffmann
Message-ID: <20250225163031.1409078-11-kra...@redhat.com>
---
hw/uefi/var-service-core.c
This file defines the register interface of the uefi-vars device.
It's only a handful of registers: magic value, command and status
registers, location and size of the communication buffer.
Reviewed-by: Laszlo Ersek
Signed-off-by: Gerd Hoffmann
Message-ID: <20250225163031.1409078-3-kra...@redhat
Add and register function to create an device tree entry when
the device is added to the qemu platform bus.
Signed-off-by: Gerd Hoffmann
Message-ID: <20250225163031.1409078-20-kra...@redhat.com>
---
hw/core/sysbus-fdt.c | 24
hw/uefi/var-service-sysbus.c | 1 +
Signed-off-by: Gerd Hoffmann
Message-ID: <20250225163031.1409078-24-kra...@redhat.com>
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2e7fc6fa912a..27cdfbebddef 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2820,6 +2820,12 @@ F: hw/misc/
Add state structs and function declarations for the uefi-vars device.
Signed-off-by: Gerd Hoffmann
Message-ID: <20250225163031.1409078-5-kra...@redhat.com>
---
include/hw/uefi/var-service.h | 191 ++
1 file changed, 191 insertions(+)
create mode 100644 include/hw
On Tue, 4 Mar 2025 at 13:44, Alex Bennée wrote:
>
> Peter Maydell writes:
> > I think it's new-ish (gcc 11?). On the other hand
> > -Wno-unknown-warning-option is quite old, and would suppress
> > this error. If we do
> > CFLAGS+=-Wno-unknown-warning-option -Wno-stringop-overread
> >
> > does th
Two fixes for 9p server's v9fs_reclaim_fd() function:
* Patch 1 fixes a concurrency issue.
* Patch 2 optimizes overall latency. On a test machine with ~800,000 FIDs, this
reduced execution duration of v9fs_reclaim_fd() from 30ms to 1ms.
Christian Schoenebeck (2):
9pfs: fix concurrent v9fs_re
Even though this function is serialized to be always called from main
thread, v9fs_reclaim_fd() is dispatching the coroutine to a worker thread
in between via its v9fs_co_*() calls, hence leading to the situation where
v9fs_reclaim_fd() is effectively executed multiple times simultaniously,
which r
Hi Brian,
On 1/3/25 18:20, Brian Cain wrote:
Signed-off-by: Brian Cain
---
MAINTAINERS | 1 +
configs/devices/hexagon-softmmu/default.mak | 7 +++
configs/targets/hexagon-softmmu.mak | 6 ++
target/Kconfig | 1 +
This function calls v9fs_co_close() and v9fs_co_closedir() in a loop. Each
one of the calls adds two thread hops (between main thread and a fs driver
background thread). Each thread hop adds latency, which sums up in
function's loop to a significant duration.
Reduce overall latency by open coding
On Mon, Feb 24, 2025 at 04:24:12PM +0800, Yong-Xuan Wang wrote:
> Rewrite the kvm_riscv_handle_csr() to support additional CSR emulation
> in user space with KVM acceleration. This update reuses the TCG CSR
> emulation function to simplify the implementation and reduce the
> redundant work. Also it
On 1/3/25 18:20, Brian Cain wrote:
From: Brian Cain
Signed-off-by: Brian Cain
---
configs/devices/hexagon-softmmu/default.mak | 1 +
configs/targets/hexagon-softmmu.mak | 1 +
include/hw/hexagon/virt.h | 41 ++
hw/hexagon/virt.c | 3
Hi Brian,
On 1/3/25 18:20, Brian Cain wrote:
From: Brian Cain
A bit opaque...
Signed-off-by: Brian Cain
---
MAINTAINERS | 1 +
tests/functional/meson.build| 8 +
tests/functional/test_hexagon_minivm.py | 42 +
3 fil
Define qapi schema for the uefi variable store state.
Use it and the generated visitor helper functions to store persistent
(EFI_VARIABLE_NON_VOLATILE) variables in JSON format on disk.
Acked-by: Markus Armbruster
Signed-off-by: Gerd Hoffmann
Message-ID: <20250225163031.1409078-15-kra...@redhat
pkcs7 stub which is used in case gnutls is not available.
It throws EFI_WRITE_PROTECTED errors unconditionally, so all
authenticated variables are readonly for the guest.
Signed-off-by: Gerd Hoffmann
Message-ID: <20250225163031.1409078-13-kra...@redhat.com>
---
hw/uefi/var-service-pkcs7-stub.c
Signed-off-by: Gerd Hoffmann
Message-ID: <20250225163031.1409078-25-kra...@redhat.com>
---
docs/devel/index-internals.rst | 1 +
docs/devel/uefi-vars.rst | 68 ++
hw/uefi/LIMITATIONS.md | 7
3 files changed, 76 insertions(+)
create mode 100644
Add utility functions. Helpers for UEFI (ucs2) string handling.
Helpers for readable trace messages. Compare UEFI time stamps.
Signed-off-by: Gerd Hoffmann
Message-ID: <20250225163031.1409078-7-kra...@redhat.com>
---
hw/uefi/var-service-utils.c | 241
1 fil
Wire up uefi-vars in the build system.
Signed-off-by: Gerd Hoffmann
Message-ID: <20250225163031.1409078-18-kra...@redhat.com>
---
hw/meson.build | 1 +
hw/uefi/meson.build | 19 +++
meson.build | 1 +
3 files changed, 21 insertions(+)
diff --git a/hw/meson.build b
This implements pkcs7 signature verification using gnutls.
Needed to check authenticated variable updates.
Signed-off-by: Gerd Hoffmann
Message-ID: <20250225163031.1409078-12-kra...@redhat.com>
---
hw/uefi/var-service-pkcs7.c | 436
1 file changed, 436 insert
Peter Maydell writes:
> On Tue, 4 Mar 2025 at 11:56, Alex Bennée wrote:
>>
>> Peter Maydell writes:
>> > +# GCC versions 12/13/14/15 at least incorrectly complain about
>> > +# "'SHA1Transform' reading 64 bytes from a region of size 0"; see the gcc
>> > bug
>> > +# https://gcc.gnu.org/bugzilla
On Tue, Mar 04, 2025 at 02:40:31PM +0100, Philippe Mathieu-Daudé wrote:
> On 4/3/25 13:11, Daniel P. Berrangé wrote:
> > On Tue, Mar 04, 2025 at 11:33:44AM +, Alex Bennée wrote:
> > > Daniel P. Berrangé writes:
> > >
> > > > On Mon, Mar 03, 2025 at 10:17:03PM +, Alex Bennée wrote:
> > > >
Add UEFI_VARS config option, enable by default for x86_64 and aarch64.
Signed-off-by: Gerd Hoffmann
Message-ID: <20250225163031.1409078-17-kra...@redhat.com>
---
hw/Kconfig | 1 +
hw/uefi/Kconfig | 3 +++
2 files changed, 4 insertions(+)
create mode 100644 hw/uefi/Kconfig
diff --git a/hw/
Allow the device being added to x86_64 pc and q35 VMs.
Signed-off-by: Gerd Hoffmann
Message-ID: <20250225163031.1409078-23-kra...@redhat.com>
---
hw/i386/pc_piix.c | 2 ++
hw/i386/pc_q35.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 04d2957
The x86 variant of the device is mapped on the fixed address 0xfef1
and uses etc/hardware-info instead of FDT to pass the mapping location
to the edk2 firmware. The latter allows to move the device to a
different location should that turn out to be necessary in the future.
Signed-off-by: Gerd
This is the uefi variable service (EfiSmmVariableProtocol), providing
functions for listing, reading and updating variables.
Signed-off-by: Gerd Hoffmann
Message-ID: <20250225163031.1409078-8-kra...@redhat.com>
---
hw/uefi/var-service-vars.c | 725 +
1 file ch
Daniel P. Berrangé writes:
> On Tue, Mar 04, 2025 at 12:11:25PM +, Daniel P. Berrangé wrote:
>> On Tue, Mar 04, 2025 at 11:33:44AM +, Alex Bennée wrote:
>> > Daniel P. Berrangé writes:
>> >
>> > > On Mon, Mar 03, 2025 at 10:17:03PM +, Alex Bennée wrote:
>> > >> This option is suppor
On 3/4/2025 12:27 AM, Markus Armbruster wrote:
Brian Cain writes:
From: Brian Cain
Co-authored-by: Mike Lambert
Co-authored-by: Sid Manning
Signed-off-by: Brian Cain
[...]
diff --git a/qapi/machine.json b/qapi/machine.json
index a6b8795b09..a7070bad4d 100644
--- a/qapi/machine.json
+
On 4/3/25 13:11, Daniel P. Berrangé wrote:
On Tue, Mar 04, 2025 at 11:33:44AM +, Alex Bennée wrote:
Daniel P. Berrangé writes:
On Mon, Mar 03, 2025 at 10:17:03PM +, Alex Bennée wrote:
This option is supported by both gcc (since 4.7) and clang (since
7.0). Not only does this make the
Current amd-iommu model internally creates an AMDVI-PCI device. Here is
a snippet from info qtree:
bus: main-system-bus
type System
dev: amd-iommu, id ""
xtsup = false
pci-id = ""
intremap = "on"
device-iotlb = false
pt = true
...
dev: q35-pcihost, i
Add migration support for AMD IOMMU model by saving necessary AMDVIState
parameters for MMIO registers, device table, command buffer, and event
buffers.
Also change devtab_len type from size_t to uint64_t to avoid 32-bit build
issue.
Signed-off-by: Suravee Suthikulpanit
---
hw/i386/amd_iommu.c
Hi,
Thank you so much for your inputs. I was able to create the .so file of QEMU.
Actually, what we are trying is to understand and explore possibilities of
Virtual Time Control in QEMU. In short, what I mean to say is an approach via
which I can tell QEMU to emulate for XYZ time when the I g
Currently, amd-iommu device does not support migration. This series addresses
an issue due hidden AMDVI-PCI device enumeration. Then introduces migratable
VMStateDescription, which saves necessary parameters for the device.
Changes from v2:
(https://lore.kernel.org/all/20250212054450.578449-1-sura
Peter Maydell writes:
> On Tue, 4 Mar 2025 at 13:44, Alex Bennée wrote:
>>
>> Peter Maydell writes:
>> > I think it's new-ish (gcc 11?). On the other hand
>> > -Wno-unknown-warning-option is quite old, and would suppress
>> > this error. If we do
>> > CFLAGS+=-Wno-unknown-warning-option -Wno-s
Implement variable policies (Edk2VariablePolicyProtocol).
This EFI protocol allows to define restrictions for variables.
It also allows to lock down variables (disallow write access).
Signed-off-by: Gerd Hoffmann
Message-ID: <20250225163031.1409078-10-kra...@redhat.com>
---
hw/uefi/var-service-
This adds sysbus bindings for the variable service.
Signed-off-by: Gerd Hoffmann
Message-ID: <20250225163031.1409078-19-kra...@redhat.com>
---
hw/uefi/var-service-sysbus.c | 91
hw/uefi/meson.build | 3 +-
2 files changed, 93 insertions(+), 1 deleti
The only reason why we're passing ags to acpi HEST table build
is to check if migration will be used or not.
Well, we only need migration for arm, as other architectures
will only use the new code. So, move this out of acpi_build_hest(),
as otherwise we can't use it for x86, as the hotplug logic t
Hi Igor,
This patch series comes after:
https://lore.kernel.org/qemu-devel/cover.1740903110.git.mchehab+hua...@kernel.org/
I'm basically trying to add support for error injection for x86,
without success so far.
On x86, the notification mechanism is different: it is via QMP.
Yet, from what I
Can be tested by setting machine to:
q35,ras=on
E.g.:
qemu-system-x86_64 --enable-kvm -cpu host -m 4g,maxmem=8G,slots=8 \
-M q35,nvdimm=on,ras=on \
-monitor stdio -no-reboot -drive if=pflash,file=OVMF_CODE.fd,format=raw
\
-kernel ../linux/arch/x86_64/boot/bzImage
On Tue, 4 Mar 2025 at 11:56, Alex Bennée wrote:
>
> Peter Maydell writes:
> > +# GCC versions 12/13/14/15 at least incorrectly complain about
> > +# "'SHA1Transform' reading 64 bytes from a region of size 0"; see the gcc
> > bug
> > +# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106709
> > +# S
This implements authenticated variable handling (see AuthVariableLib in
edk2).
The by far most common use case for auth variables is secure boot. The
secure boot certificate databases ('PK', 'KEK', 'db' and 'dbx') are
authenticated variables, with update rules being specified in the UEFI
specific
Functions to serialize and de-serialize EFI signature databases. This
is needed to merge signature databases (happens in practice when
appending dbx updates) and also to extract the certificates for
pkcs7 signature verification.
Signed-off-by: Gerd Hoffmann
Message-ID: <20250225163031.1409078-14
Allow the device being added to aarch64 virt VMs.
Signed-off-by: Gerd Hoffmann
Message-ID: <20250225163031.1409078-22-kra...@redhat.com>
---
hw/arm/virt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index ee69081ef421..904c698b1406 100644
--- a/hw/arm/virt
Hello Michael,
Could you please re-ack (or not) v2 ?
Thanks
C.
On 2/25/25 22:52, Alex Williamson wrote:
v2:
Eric noted in v1 that one of the drivers had a redundant wmask setting
since pci_pm_init() enabled writes to the power state field. This was
added because vfio-pci was not setting wma
On Mon, Feb 24, 2025 at 04:24:13PM +0800, Yong-Xuan Wang wrote:
> Support user-space emulation of SIREG and STOPEI CSR with KVM
> acceleration. For SIREG emulation, the SISELECT CSR value and iprio
> array must be loaded before handling, and since the iprio array might
> be modified, it must be wri
Peter Maydell writes:
> On Tue, 4 Mar 2025 at 14:29, Alex Bennée wrote:
>>
>> Peter Maydell writes:
>>
>> > On Tue, 4 Mar 2025 at 13:44, Alex Bennée wrote:
>> >>
>> >> Peter Maydell writes:
>> >> > I think it's new-ish (gcc 11?). On the other hand
>> >> > -Wno-unknown-warning-option is quite
FUA emulation code is already is place.
Signed-off-by: Alberto Faria
---
hw/scsi/scsi-disk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
index e7f738b484..8cf50845ab 100644
--- a/hw/scsi/scsi-disk.c
+++ b/hw/scsi/scsi-disk.c
@@ -3
Avoid emulating FUA when the driver supports it natively. This should
provide better performance than a full flush after the write.
Signed-off-by: Alberto Faria
---
hw/scsi/scsi-disk.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/hw/scsi/scsi-disk.c b/hw
On 2/26/25 11:48, Thomas Huth wrote:
The kernel that is used in the sx1 test prints the usual Linux log
onto the serial console, but this test currently ignores it. To
make sure that the serial device is working properly, let's check
for some strings in the output here.
While we're at it, also a
On 26.02.2025 17:43, Peter Xu wrote:
On Wed, Feb 19, 2025 at 09:33:59PM +0100, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
This SaveVMHandler helps device provide its own asynchronous transmission
of the remaining data at the end of a precopy phase via multifd channels,
in parallel
On 4.03.2025 12:29, Avihai Horon wrote:
On 04/03/2025 0:17, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
On 2.03.2025 15:48, Avihai Horon wrote:
On 19/02/2025 22:34, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
On 4.03.2025 08:41, Cédric Le Goater wrote:
@@ -728,6 +728,12 @@ static int vfio_load_state(QEMUFile *f, void *opaque, int
version_id)
switch (data) {
case VFIO_MIG_FLAG_DEV_CONFIG_STATE:
{
+ if (vfio_multifd_transfer_enabled(vbasedev)) {
+
From: "Maciej S. Szmigiero"
This is an updated v6 patch series of the v5 series located here:
https://lore.kernel.org/qemu-devel/cover.1739994627.git.maciej.szmigi...@oracle.com/
What this patch set is about?
Current live migration device state transfer is done via the main (single)
migration ch
From: "Maciej S. Szmigiero"
This QEMU_VM_COMMAND sub-command and its switchover_start SaveVMHandler is
used to mark the switchover point in main migration stream.
It can be used to inform the destination that all pre-switchover main
migration stream data has been sent/received so it can start to
From: "Maciej S. Szmigiero"
These names conflict with ones used by future generic thread pool
equivalents.
Generic names should belong to the generic pool type, not specific (AIO)
type.
Acked-by: Fabiano Rosas
Reviewed-by: Cédric Le Goater
Reviewed-by: Peter Xu
Signed-off-by: Maciej S. Szmigi
On Tue, Mar 04, 2025 at 10:50:29PM +0100, Maciej S. Szmigiero wrote:
> On 26.02.2025 17:43, Peter Xu wrote:
> > On Wed, Feb 19, 2025 at 09:33:59PM +0100, Maciej S. Szmigiero wrote:
> > > From: "Maciej S. Szmigiero"
> > >
> > > This SaveVMHandler helps device provide its own asynchronous transmiss
From: "Maciej S. Szmigiero"
Migration code wants to manage device data sending threads in one place.
QEMU has an existing thread pool implementation, however it is limited
to queuing AIO operations only and essentially has a 1:1 mapping between
the current AioContext and the AIO ThreadPool in us
From: "Maciej S. Szmigiero"
It's possible for {load,save}_cleanup SaveVMHandlers to get called without
the corresponding {load,save}_setup handler being called first.
One such example is if {load,save}_setup handler of a proceeding device
returns error.
In this case the migration core cleanup co
From: "Maciej S. Szmigiero"
Read packet header first so in the future we will be able to
differentiate between a RAM multifd packet and a device state multifd
packet.
Since these two are of different size we can't read the packet body until
we know which packet type it is.
Reviewed-by: Fabiano
From: "Maciej S. Szmigiero"
This way if there are fields there that needs explicit disposal (like, for
example, some attached buffers) they will be handled appropriately.
Add a related assert to multifd_set_payload_type() in order to make sure
that this function is only used to fill a previously
From: "Maciej S. Szmigiero"
qemu_loadvm_load_state_buffer() and its load_state_buffer
SaveVMHandler allow providing device state buffer to explicitly
specified device via its idstr and instance id.
Reviewed-by: Fabiano Rosas
Reviewed-by: Peter Xu
Signed-off-by: Maciej S. Szmigiero
---
includ
From: "Maciej S. Szmigiero"
multifd_send() function is currently not thread safe, make it thread safe
by holding a lock during its execution.
This way it will be possible to safely call it concurrently from multiple
threads.
Reviewed-by: Peter Xu
Signed-off-by: Maciej S. Szmigiero
---
migrat
On Mon, Mar 03, 2025 at 04:41:56PM +0800, Stefan Hajnoczi wrote:
> On Fri, Feb 28, 2025 at 09:57:08PM +0200, Nir Soffer wrote:
> > This test depends on TarFile.addfile() to add tar member header without
> > writing the member data, which we write ourself using qemu-nbd. Python
> > 3.13 changed the
On Thu, Feb 27, 2025 at 01:14:12PM -0600, Eric Blake wrote:
> On Tue, Feb 25, 2025 at 08:06:50AM +0100, Thomas Huth wrote:
> > Test 162 recently started failing for me for no obvious reasons (I
> > did not spot any suspicious commits in this area), but looking in
> > the 162.out.bad log file, there
On 3/4/25 14:24, Alex Bennée wrote:
The main multiarch tests should compile for any POSIX system, however
test-vma's usage of MAP_NORESERVE makes it a linux-only test. Simply
moving the source file is enough for the build logic to skip on BSD's.
Message-Id: <20250226140343.3907080-12-alex.ben...
On 3/4/25 14:24, Alex Bennée wrote:
Trim through the includes and remove everything not needed for the
core. Only include tcg-op-common.h to remove the need to
TARGET_LONG_BITS and move the build unit into the common set.
Signed-off-by: Alex Bennée
---
plugins/core.c | 10 +-
pl
On Tue, Mar 04, 2025 at 01:40:02PM +0530, Prasad Pandit wrote:
> Hello Peter,
>
> On Mon, 3 Mar 2025 at 20:20, Peter Xu wrote:
> > We need the header.
>
> * We need a section type, which is sent by qemu_savevm_command_send()
> as 'QEMU_VM_COMMAND'.
I think we need the header, the ram is a modul
On Tue, 4 Mar 2025 at 14:29, Alex Bennée wrote:
>
> Peter Maydell writes:
>
> > On Tue, 4 Mar 2025 at 13:44, Alex Bennée wrote:
> >>
> >> Peter Maydell writes:
> >> > I think it's new-ish (gcc 11?). On the other hand
> >> > -Wno-unknown-warning-option is quite old, and would suppress
> >> > thi
On 3/3/2025 6:00 AM, Dongli Zhang wrote:
When the PERFCORE is disabled with "-cpu host,-perfctr-core", it is
reflected in in guest dmesg.
[0.285136] Performance Events: AMD PMU driver.
I'm a little confused. wWhen no perfctr-core, AMD PMU driver can still
be probed? (forgive me if I ask a
On Tue, Mar 04, 2025 at 03:17:14PM +0530, Prasad Pandit wrote:
> Hi,
>
> On Mon, 3 Mar 2025 at 19:42, Peter Xu wrote:
> > On Mon, Mar 03, 2025 at 04:17:53PM +0530, Prasad Pandit wrote:
> > > * I think we (you, me, Peter) are all looking at things differently.
> > > - In my view Patch-2 is the
Hi Stefan,
On 17/2/25 10:27, Jeuk Kim wrote:
From: Jeuk Kim
The following changes since commit db7aa99ef894e88fc5eedf02ca2579b8c344b2ec:
Merge tag 'hw-misc-20250216' of https://github.com/philmd/qemu into staging
(2025-02-16 20:48:06 -0500)
are available in the Git repository at:
htt
On 04/03/25, Philippe Mathieu-Daudé wrote:
>
> On default macOS I get:
>
> Program bison found: NO found 2.3 but need: '>=3.0' (/usr/bin/bison)
>
> Fixed by installing via brew and:
>
> export PATH=/opt/homebrew/opt/bison/bin:$PATH
>
> > @@ -401,3 +409,4 @@ analyze_funcs_generated = custom_
On Fri, Feb 28, 2025 at 09:58:31AM +0100, Paolo Bonzini wrote:
> Date: Fri, 28 Feb 2025 09:58:31 +0100
> From: Paolo Bonzini
> Subject: [PATCH] rust: qom: remove operations on &mut
> X-Mailer: git-send-email 2.48.1
>
> The dubious casts of mutable references to objects are not used
> anymore: the
The QEMU-emulated AMD IOMMU PCI device is implemented based on the AMD I/O
Virtualization Technology (IOMMU) Specification [1]. The PCI id for this
device is platform-specific.
Currently, the QEMU-emulated AMD IOMMU device is using AMD vendor id and
undefined device id.
Therefore, change the vend
On 3/4/2025 9:46 AM, Philippe Mathieu-Daudé wrote:
Hi Brian,
On 1/3/25 18:20, Brian Cain wrote:
From: Brian Cain
A bit opaque...
Whoops -- will fix it.
Signed-off-by: Brian Cain
---
MAINTAINERS | 1 +
tests/functional/meson.build | 8 +
Add NVRAM and hint on how to make it persistent. Also update Linux
boot section which should now boot automatically with the new NVRAM
defaults so manual settings in menu may not be needed normally.
Signed-off-by: BALATON Zoltan
---
Based-on:
docs/system/ppc/amigang.rst | 17 +
On 3/4/2025 9:46 AM, Philippe Mathieu-Daudé wrote:
Hi Brian,
On 1/3/25 18:20, Brian Cain wrote:
From: Brian Cain
A bit opaque...
Whoops -- will fix it.
Signed-off-by: Brian Cain
---
MAINTAINERS | 1 +
tests/functional/meson.build | 8 +
On Tue, Mar 04, 2025 at 03:52:31PM +, Alberto Faria wrote:
> FUA emulation code is already is place.
>
> Signed-off-by: Alberto Faria
> ---
> hw/scsi/scsi-disk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
> index e7f738
Add support for Force Unit Access (FUA) writes. The first patch makes scsi-disk
devices advertise FUA support by default; FUA requests will be emulated through
a regular write followed by a flush. The second patch lets us avoid FUA
emulation when the underlying block driver supports it natively.
A
> +//! ### Example
> +//!
> +//! ```
> +//! # use qemu_api::prelude::*;
> +//! # use qemu_api::{c_str, cell::BqlRefCell, irq::InterruptSource,
> irq::IRQState};
> +//! # use qemu_api::{sysbus::SysBusDevice, qom::Owned, qom::ParentField};
> +//! # const N_GPIOS: usize = 8;
> +//! # struct PL061Regi
Am 23. Februar 2025 11:47:08 UTC schrieb Bernhard Beschow :
>The implementation just allows Linux to determine date and time.
>
>Signed-off-by: Bernhard Beschow
>---
> MAINTAINERS| 2 +
> hw/rtc/rs5c372.c | 236 +
> tests/qtest/rs5c3
> -Original Message-
> From: Philippe Mathieu-Daudé
> Sent: Tuesday, March 4, 2025 6:19 PM
> To: ltaylorsimp...@gmail.com; richard.hender...@linaro.org; 'Brian Cain'
> ; qemu-devel@nongnu.org
> Cc: quic_mathb...@quicinc.com; a...@rev.ng; a...@rev.ng;
> quic_mlie...@quicinc.com; alex.ben
Hi Taylor,
On 5/3/25 00:09, ltaylorsimp...@gmail.com wrote:
-Original Message-
From: Brian Cain
Sent: Monday, March 3, 2025 10:24 AM
To: qemu-devel@nongnu.org
Cc: richard.hender...@linaro.org; phi...@linaro.org;
quic_mathb...@quicinc.com; a...@rev.ng; a...@rev.ng;
quic_mlie...@quicin
Replace all TARGET_NAME uses by target_name() runtime,
then remove the definition and poison it.
While is looks like another cleanup, it is a small step
required for the single binary project.
Alex Bennée (1):
plugins/loader: populate target_name with target_name()
Philippe Mathieu-Daudé (10):
No need to include the huge "hw/core/cpu.h" header to
get a simple prototype declaration such target_name().
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/core/cpu.h | 2 --
include/qemu/arch_info.h | 2 ++
arch_info-target.c | 5 +
cpu-target.c | 5 -
Declare QEMU_ARCH_BIT_$target as QemuArchBit enum.
Use them to declare QEMU_ARCH_$target bitmasks.
Signed-off-by: Philippe Mathieu-Daudé
---
meson.build| 4 +--
include/system/arch_init.h | 65 +-
system/arch_init.c | 2 +-
3 files ch
qemu_arch_available() is a bit simpler to understand while
reviewing than the undocumented arch_type variable.
Signed-off-by: Philippe Mathieu-Daudé
---
include/system/arch_init.h | 2 +-
hw/scsi/scsi-disk.c| 2 +-
system/arch_init.c | 5 -
system/qdev-monitor.c | 4 ++--
Introduce a generic helper to get the target name of a QemuArchBit.
(This will be used for single / heterogeneous binaries).
Use it in target_name(), removing the last use of the TARGET_NAME
definition.
Signed-off-by: Philippe Mathieu-Daudé
---
include/qemu/arch_info.h | 2 ++
arch_info-target.
We shouldn't use target specific globals for machine properties.
These ones could be desugarized, as explained in [*]. While
certainly doable, not trivial nor my priority for now. Just move
them to a different file to clarify they are *globals*, like the
generic globals residing in system/globals.c
1 - 100 of 465 matches
Mail list logo
