On 22.01.25 11:10, David Hildenbrand wrote:
On 22.01.25 11:07, Philippe Mathieu-Daudé wrote:
Hi David,
On 20/1/25 12:14, David Hildenbrand wrote:
As documented in commit 4a2e242bbb306 ("memory: Don't use memcpy for
ram_device regions"), we disallow direct access to RAM DEVICE regions.
Let's f
On 22.01.25 11:18, David Hildenbrand wrote:
On 22.01.25 11:17, Philippe Mathieu-Daudé wrote:
On 22/1/25 11:13, David Hildenbrand wrote:
On 22.01.25 11:10, David Hildenbrand wrote:
On 22.01.25 11:07, Philippe Mathieu-Daudé wrote:
Hi David,
On 20/1/25 12:14, David Hildenbrand wrote:
As docume
Now that everything has been cleaned up, look at DF and prefixes
in a single function, and call that one from gen_repz and gen_repz_nz.
Signed-off-by: Paolo Bonzini
---
target/i386/tcg/translate.c | 34 ++
1 file changed, 14 insertions(+), 20 deletions(-)
diff --
Now that everything has been cleaned up, look at DF and prefixes
in a single function, and call that one from gen_repz and gen_repz_nz.
Based-on: <20241215090613.89588-1-pbonz...@redhat.com>
Suggested-by: Richard Henderson
Signed-off-by: Paolo Bonzini
---
This was requested in the review
Both CPUClass::gdb_read_register() and CPUClass::gdb_write_register()
handlers are called from common gdbstub code, and won't be called with
register index over CPUClass::gdb_num_core_regs:
int gdb_read_register(CPUState *cpu, GByteArray *buf, int reg)
{
CPUClass *cc = CPU_GET_CLASS(cpu)
CpuState caches its CPUClass since commit 6fbdff87062
("cpu: cache CPUClass in CPUState for hot code paths"),
use it.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
gdbstub/gdbstub.c | 26 +-
gdbstub/system.c | 7 ++-
gdbstub/user-
Missing review: 1 & 2
v1 cover:
Use cached CPUState::cc to get CPUClass.
Main rationale is overall code style.
Philippe Mathieu-Daudé (10):
hw/core/generic-loader: Do not open-code cpu_set_pc()
gdbstub: Clarify no more than @gdb_num_core_regs can be accessed
cpus: Cache CPUClass early in in
On 17/1/25 10:00, Paolo Bonzini wrote:
Place struct_name before field_name, similar to offset_of.
Signed-off-by: Paolo Bonzini
---
rust/hw/char/pl011/src/device_class.rs | 2 +-
rust/qemu-api/src/vmstate.rs | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Ph
On Wed, Jan 22, 2025 at 11:32:23AM +0100, Philippe Mathieu-Daudé wrote:
> As Daniel mentioned:
>
> "The number of instances of MachineClass is not large enough
> that we save a useful amount of memory through bitfields."
>
> Also, see recent commit ecbf3567e21 ("docs/devel/style: add a
> secti
Roman Penyaev writes:
> This patch implements a new chardev backend `hub` device, which
> aggregates input from multiple backend devices and forwards it to a
> single frontend device. Additionally, `hub` device takes the output
> from the frontend device and sends it back to all the connected
> b
On Fri, 17 Jan 2025 at 12:42, Daniel P. Berrangé wrote:
>
> We expect all new code to be contributed with the "GPL-2.0-or-later"
> license tag. Divergence is permitted if the new file is derived from
> pre-existing code under a different license, whether from elsewhere
> in QEMU codebase, or outsi
Hi Gavin,
On Fri, Dec 13, 2024 at 10:03:08PM +1000, Gavin Shan wrote:
> Hi Jean,
>
> On 11/26/24 5:56 AM, Jean-Philippe Brucker wrote:
> > When RME is enabled, the upper GPA bit is used to distinguish protected
> > from unprotected addresses. Reserve it when setting up the guest memory
> > map.
>
On 1/22/25 15:34, Zhao Liu wrote:
On Fri, Jan 17, 2025 at 10:26:50AM +0100, Paolo Bonzini wrote:
Date: Fri, 17 Jan 2025 10:26:50 +0100
From: Paolo Bonzini
Subject: [PATCH 03/10] rust: pl011: extract conversion to RegisterOffset
X-Mailer: git-send-email 2.47.1
As an added bonus, this also makes
On 1/22/25 15:59, Zhao Liu wrote:
if size > 0 {
debug_assert!(!buf.is_null());
-state.as_mut().put_fifo(c_uint::from(buf.read_volatile()))
An extra question...here I'm not sure, do we really need read_volatile?
No, the buffer is not guest visible. It will
Peter Maydell writes:
> On Wed, 18 Dec 2024 at 18:15, Alex Bennée wrote:
>>
>> Signed-off-by: Alex Bennée
>> Cc: qemu-sta...@nongnu.org
>> ---
>> hw/arm/virt.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index 333eaf67ea..5e3589dc6a 100644
>>
On Fri, Jan 17, 2025 at 10:00:39AM +0100, Paolo Bonzini wrote:
> Date: Fri, 17 Jan 2025 10:00:39 +0100
> From: Paolo Bonzini
> Subject: [PATCH 03/10] rust: vmstate: add varray support to vmstate_of!
> X-Mailer: git-send-email 2.47.1
>
> Signed-off-by: Paolo Bonzini
> ---
> rust/qemu-api/src/vms
On Sat, Jan 18, 2025 at 10:04:37AM +, Marc Zyngier wrote:
> On Fri, 17 Jan 2025 19:11:06 +,
> Kashyap Chamarthy wrote:
> >
> > PAuth (Pointer Authentication), a security feature in software, is
> > relevant for both KVM and QEMU. Relect this fact into the docs:
> >
> > - For KVM, `pau
On Fri, Jan 17, 2025 at 10:26:49AM +0100, Paolo Bonzini wrote:
> Date: Fri, 17 Jan 2025 10:26:49 +0100
> From: Paolo Bonzini
> Subject: [PATCH 02/10] rust: pl011: hide unnecessarily "pub" items from
> outside pl011::device
> X-Mailer: git-send-email 2.47.1
>
> The only public interfaces for pl01
On Fri, Jan 17, 2025 at 10:26:48AM +0100, Paolo Bonzini wrote:
> Date: Fri, 17 Jan 2025 10:26:48 +0100
> From: Paolo Bonzini
> Subject: [PATCH 01/10] rust: pl011: remove unnecessary "extern crate"
> X-Mailer: git-send-email 2.47.1
>
> Signed-off-by: Paolo Bonzini
> ---
> rust/hw/char/pl011/src/
On Wed, Jan 22, 2025 at 01:26:21PM +0530, Prasad Pandit wrote:
> Hi,
> On Tue, 21 Jan 2025 at 21:17, Peter Xu wrote:
> > https://lore.kernel.org/qemu-devel/ZykJBq7ME5jgSzCA@x1n/
> > Would you please add all the tests mentioned there?
>
> /x86_64/migration/multifd/file/mapped-ram/
> /x86_6
On 22/1/25 08:09, Cédric Le Goater wrote:
When the -nodefaults option is set, sd devices should not be
automatically created by the machine. Instead they should be defined
on the command line.
Note that it is not currently possible to define which bus an
"sd-card" device is attached to:
-blo
The open-coded form of this filter has been copied into enough tests
that it's better to move it into iotests.py.
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/iotests.py | 4
tests/qemu-iotests/041| 4 +---
tests/qemu-iotests/165
commit 0788a56bd1ae3 ("i386: Make unversioned CPU models be aliases")
introduced 'default_cpu_version' for PCMachineClass. This created three
categories of CPU models:
- Most unversioned CPU models would use version 1 by default.
- For machines 4.0.1 and older that do not support cpu model aliase
Many of the new decorators of the functional tests don't work as
expected (and simply always allow to run the tests). Let's fix them!
v2:
- Use importlib.import_module() to check whether we can import a module
- Split the import check into a separate patch
Thomas Huth (2):
tests/functional/qemu
The decorators that use a lambda function are currently broken
and do not properly skip the test if the condition is not met.
Using "return skipUnless(lambda: ...)" does not work as expected.
To fix it, rewrite the decorators without lambda, it's simpler
that way anyway.
Reviewed-by: Daniel P. Ber
skipIfMissingImports should use importlib.import_module() for checking
whether a module with the name stored in the "impname" variable is
available or not, otherwise the code tries to import a module with
the name "impname" instead.
(This bug hasn't been noticed before since there is another issue
On Tue, Jan 21, 2025 at 11:00:29AM +0100, Laurent Vivier wrote:
In vhost_user_receive() if vhost_net_notify_migration_done() reports
an error we display on the console:
Vhost user backend fails to broadcast fake RARP
This message can be useful if there is a problem to execute
VHOST_USER_SEND_R
On 2025/1/21 20:25, Yong Huang wrote:
On Tue, Dec 31, 2024 at 9:56 AM fuqiang wang wrote:
Using the current algorithm, there are issues with precision not being
handled correctly during division operations. (Even though double type
casting is used in the function, it does not seem to have an
On Wed, Jan 22, 2025 at 02:43:13PM +0100, Thomas Huth wrote:
> skipIfMissingImports should use importlib.import_module() for checking
> whether a module with the name stored in the "impname" variable is
> available or not, otherwise the code tries to import a module with
> the name "impname" instea
Am 12.12.2024 um 21:47 hat Peter Xu geschrieben:
> v1: https://lore.kernel.org/r/20241211201739.1380222-1-pet...@redhat.com
>
> Changelog: in previous v1, I got a wrong cut-off accident in commit
> message, which is now fixed (along with some small touchup elsewhere).
> When at it, I also tried to
On 1/21/25 12:25 PM, Eugenio Perez Martin wrote:
On Tue, Jan 21, 2025 at 3:53 PM Jonah Palmer wrote:
On 1/16/25 11:44 AM, Eugenio Perez Martin wrote:
On Fri, Jan 10, 2025 at 6:09 PM Jonah Palmer wrote:
Decouples the IOVA allocator from the full IOVA->HVA tree to support a
SVQ IOVA->HV
On Wed, Jan 22, 2025 at 05:20:06PM +0100, Stefano Garzarella wrote:
> On Wed, Jan 22, 2025 at 08:59:22AM -0500, Michael S. Tsirkin wrote:
> > On Wed, Jan 22, 2025 at 02:42:14PM +0100, Stefano Garzarella wrote:
> > > On Tue, Jan 21, 2025 at 11:00:29AM +0100, Laurent Vivier wrote:
> > > > In vhost_us
Applied, thanks.
Please update the changelog at https://wiki.qemu.org/ChangeLog/10.0 for any
user-visible changes.
signature.asc
Description: PGP signature
On Wed, Jan 22, 2025 at 08:59:22AM -0500, Michael S. Tsirkin wrote:
On Wed, Jan 22, 2025 at 02:42:14PM +0100, Stefano Garzarella wrote:
On Tue, Jan 21, 2025 at 11:00:29AM +0100, Laurent Vivier wrote:
> In vhost_user_receive() if vhost_net_notify_migration_done() reports
> an error we display on
On Fri, Jan 17, 2025 at 10:26:52AM +0100, Paolo Bonzini wrote:
> Date: Fri, 17 Jan 2025 10:26:52 +0100
> From: Paolo Bonzini
> Subject: [PATCH 05/10] rust: pl011: pull interrupt updates out of
> read/write ops
> X-Mailer: git-send-email 2.47.1
>
> qemu_irqs are not part of the vmstate, therefore
On Fri, Jan 17, 2025 at 10:00:38AM +0100, Paolo Bonzini wrote:
> Date: Fri, 17 Jan 2025 10:00:38 +0100
> From: Paolo Bonzini
> Subject: [PATCH 02/10] rust: vmstate: implement VMState for non-leaf types
> X-Mailer: git-send-email 2.47.1
>
> Arrays, pointers and cells use a VMStateField that is bas
On Tue, Jan 21, 2025 at 10:59:34AM +, Titus Rwantare wrote:
> This has been useful when debugging and unsure if the guest is
> generating i2c traffic.
Acked-by: Corey Minyard
>
> Signed-off-by: Titus Rwantare
> ---
> hw/misc/i2c-echo.c | 8
> hw/misc/trace-events | 5 +
> 2
On Fri, Jan 17, 2025 at 10:00:46AM +0100, Paolo Bonzini wrote:
> Date: Fri, 17 Jan 2025 10:00:46 +0100
> From: Paolo Bonzini
> Subject: [PATCH 10/10] rust: vmstate: make order of parameters consistent
> in vmstate_clock
> X-Mailer: git-send-email 2.47.1
>
> Place struct_name before field_name, s
On Fri, Jan 17, 2025 at 10:00:43AM +0100, Paolo Bonzini wrote:
> Date: Fri, 17 Jan 2025 10:00:43 +0100
> From: Paolo Bonzini
> Subject: [PATCH 07/10] rust: qemu_api: add vmstate_struct
> X-Mailer: git-send-email 2.47.1
>
> It is not type safe, but it's the best that can be done without
> const_re
The current code is actually dependent on having just one error
structure with a single source.
As the number of sources should be arch-dependent, as it will depend on
what kind of synchronous/assynchronous notifications will exist, change
the logic to dynamically build the table.
Yet, for a prop
Some error injection notify methods are async, like GPIO
notify. Add a notifier to be used when the error record is
ready to be sent to the guest OS.
Signed-off-by: Mauro Carvalho Chehab
---
hw/acpi/ghes.c | 5 -
include/hw/acpi/ghes.h | 3 +++
2 files changed, 7 insertions(+), 1 del
There are two pointers that are needed during error injection:
1. The start address of the CPER block to be stored;
2. The address of the ack, which needs a reset before next error.
It is preferable to calculate them from the HEST table. This allows
checking the source ID, the size of the table
Store HEST table address at GPA, placing its content at
hest_addr_le variable.
Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Jonathan Cameron
---
Change from v8:
- hest_addr_lr is now pointing to the error source size and data.
Signed-off-by: Mauro Carvalho Chehab
---
hw/acpi/ghes.c
The GHES migration logic at GED should now support HEST table
location too.
Signed-off-by: Mauro Carvalho Chehab
---
hw/acpi/generic_event_device.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/hw/acpi/generic_event_device.c b/hw/acpi/generic_event_device.c
i
Create a new property (x-has-hest-addr) and use it to detect if
the GHES table offsets can be calculated from the HEST address
(qemu 9.2 and upper) or via the legacy way via an offset obtained
from the hardware_errors firmware file.
Signed-off-by: Mauro Carvalho Chehab
---
hw/acpi/generic_event_
Creates a QMP command to be used for generic ACPI APEI hardware error
injection (HEST) via GHESv2, and add support for it for ARM guests.
Error injection uses ACPI_HEST_SRC_ID_QMP source ID to be platform
independent. This is mapped at arch virt bindings, depending on the
types supported by QEMU a
Move the check logic into a common function and simplify the
code which checks if GHES is enabled and was properly setup.
Signed-off-by: Mauro Carvalho Chehab
---
hw/acpi/ghes-stub.c| 4 ++--
hw/acpi/ghes.c | 33 +++--
include/hw/acpi/ghes.h | 9 +---
Now that the ghes preparation patches were merged, let's add support
for error injection.
I'm opting to fold two patch series into one here:
1.
https://lore.kernel.org/qemu-devel/20250113130854.848688-1-mchehab+hua...@kernel.org/
It is the first 5 patches containing changes to the math used to
Using the QMP GHESv2 API requires preparing a raw data array
containing a CPER record.
Add a helper script with subcommands to prepare such data.
Currently, only ARM Processor error CPER record is supported.
Signed-off-by: Mauro Carvalho Chehab
---
MAINTAINERS| 3 +
scrip
Adds a generic error device to handle generic hardware error
events as specified at ACPI 6.5 specification at 18.3.2.7.2:
https://uefi.org/specs/ACPI/6.5/18_Platform_Error_Interfaces.html#event-notification-for-generic-error-sources
using HID PNP0C33.
The PNP0C33 device is used to report hardware
Adds support to ARM virtualization to allow handling
generic error ACPI Event via GED & error source device.
It is aligned with Linux Kernel patch:
https://lore.kernel.org/lkml/1272350481-27951-8-git-send-email-ying.hu...@intel.com/
Co-authored-by: Mauro Carvalho Chehab
Co-authored-by: Jonathan
In order to support running an NBD export on inactive nodes, we must
make sure to return errors for any operations that aren't allowed on
inactive nodes. Reads are the only operation we know we need for
inactive images, so to err on the side of caution, return errors for
everything else, even if so
The system emulator tries to automatically activate and inactivate block
nodes at the right point during migration. However, there are still
cases where it's necessary that the user can do this manually.
Images are only activated on the destination VM of a migration when the
VM is actually resumed
Test that it's possible to migrate a VM that uses an image on shared
storage through qemu-storage-daemon.
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/tests/qsd-migrate | 132 +++
tests/qemu-iotests/tests/qsd-migrate.out | 51 +
2 files changed, 183 insertion
This series adds a mechanism that allows the user or management tool to
manually activate and inactivate block nodes instead of fully relying on
the automatic management in the migration code.
One case where this is needed is for migration with shared storage and
devices backed by qemu-storage-dae
In QEMU, nodes are automatically created inactive while expecting an
incoming migration (i.e. RUN_STATE_INMIGRATE). In qemu-storage-daemon,
the notion of runstates doesn't exist. It also wouldn't necessarily make
sense to introduce it because a single daemon can serve multiple VMs
that can be in di
Currently, block jobs can't handle inactive images correctly. Incoming
write requests would run into assertion failures. Make sure that we
return an error when creating an export can't activate the image.
Signed-off-by: Kevin Wolf
---
block/export/export.c | 6 +-
1 file changed, 5 insertion
Add an option in BlockExportOptions to allow creating an export on an
inactive node without activating the node. This mode needs to be
explicitly supported by the export type (so that it doesn't perform any
operations that are forbidden for inactive nodes), so this patch alone
doesn't allow this op
Device models have a relatively complex way to set up their block
backends, in which blk_attach_dev() sets blk->disable_perm = true.
We want to support inactive images in exports, too, so that
qemu-storage-daemon can be used with migration. Because they don't use
blk_attach_dev(), they need another
On Fri, Jan 17, 2025 at 10:00:41AM +0100, Paolo Bonzini wrote:
> Date: Fri, 17 Jan 2025 10:00:41 +0100
> From: Paolo Bonzini
> Subject: [PATCH 05/10] rust: vmstate: implement VMState for scalar types
> X-Mailer: git-send-email 2.47.1
>
> Scalar types are those that have their own VMStateInfo. Th
On Wed, 22 Jan 2025, Philippe Mathieu-Daudé wrote:
As Daniel mentioned:
"The number of instances of MachineClass is not large enough
that we save a useful amount of memory through bitfields."
Also, see recent commit ecbf3567e21 ("docs/devel/style: add a
section about bitfield, and disallow the
On Tue, Jan 21, 2025 at 4:58 PM Zhao Liu wrote:
>
> Hi Ani,
>
> Sorry for late reply.
>
> On Thu, Jan 16, 2025 at 09:04:18AM +0530, Ani Sinha wrote:
> > Date: Thu, 16 Jan 2025 09:04:18 +0530
> > From: Ani Sinha
> > Subject: [PATCH v3] hw/i386/cpu: remove default_cpu_version and simplify
> > X-Mai
What we wanted to catch with the assertion is cases where the recursion
finds that a child was inactive before its parent. This should never
happen. But if the user tries to inactivate an image that is already
inactive, that's harmless and we don't want to fail the assertion.
Signed-off-by: Kevin
On 1/20/25 16:56, Alex Bennée wrote:
...
>> @@ -972,15 +973,29 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
>>
>> trace_virtio_gpu_fence_ctrl(cmd->cmd_hdr.fence_id, cmd->cmd_hdr.type);
>>
>> -/*
>> - * Unlike other virglrenderer functions, this one returns a positive
>> -
On Wed, 22 Jan 2025, Michael Tokarev wrote:
22.01.2025 02:14, Pierrick Bouvier wrote:
..
I agree the existing code (and this patch) is pretty cryptic for anyone not
familiar with FAT format.
However, I think it could be a good thing to first merge this one (which is
correct, and works), and ref
On 1/20/25 18:41, Alex Bennée wrote:
> Dmitry Osipenko writes:
>
>> This patchset adds DRM native context support to VirtIO-GPU on Qemu.
>>
>> Contarary to Virgl and Venus contexts that mediates high level GFX APIs,
>> DRM native context [1] mediates lower level kernel driver UAPI, which
>> refle
On 22/01/2025 15.33, Peter Maydell wrote:
On Wed, 22 Jan 2025 at 12:36, Thomas Huth wrote:
On 22/01/2025 11.32, Philippe Mathieu-Daudé wrote:
As Daniel mentioned:
"The number of instances of MachineClass is not large enough
that we save a useful amount of memory through bitfields."
A
Unfortunately, this test had not been added to meson.build, so we did
not notice a regression: Looking for 'Kernel panic - not syncing: VFS:'
as the indication for the final boot state of the kernel was a bad
idea since 'Kernel panic - not syncing' is the default failure
message of the LinuxKernelT
Cache CPUClass as early as possible, when the instance
is initialized.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
cpu-target.c | 3 ---
hw/core/cpu-common.c | 3 +++
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/cpu-target.c b/cpu-target.c
On 13 Jan 2025, at 9:59 PM, Peter Xu wrote:
!---|
CAUTION: External Email
|---!
On Fri, Jan 10, 2025 at 10:09:38AM -0300, Fabiano Rosas wrote:
Shivam Kumar writes:
On 22/01/2025 11.32, Philippe Mathieu-Daudé wrote:
As Daniel mentioned:
"The number of instances of MachineClass is not large enough
that we save a useful amount of memory through bitfields."
Also, see recent commit ecbf3567e21 ("docs/devel/style: add a
section about bitfield, and disallow
22.01.2025 15:19, BALATON Zoltan wrote:
On Wed, 22 Jan 2025, Michael Tokarev wrote:
22.01.2025 02:14, Pierrick Bouvier wrote:
..
I agree the existing code (and this patch) is pretty cryptic for anyone not
familiar with FAT format.
However, I think it could be a good thing to first merge this o
Applied, thanks.
Please update the changelog at https://wiki.qemu.org/ChangeLog/10.0 for any
user-visible changes.
signature.asc
Description: PGP signature
The Intel CPU has a complex history regarding setting of the physical
address space width on KVM. A 'phys_bits' field and a "phys-bits"
property were added by commit af45907a1328 ("target-i386: Allow
physical address bits to be set") to tune this value.
In certain circumstances, it is interesting
Print a warning if IOMMU address space width is smaller than the
physical address width. In this case, PCI peer-to-peer transactions on
BARs are not supported and failures of device MMIO regions are to be
expected.
This can occur with the 39-bit IOMMU address space width as found on
consumer grade
On Wed, Jan 22, 2025 at 3:44 PM Alex Bennée wrote:
>
> Roman Penyaev writes:
>
> > This patch implements a new chardev backend `hub` device, which
> > aggregates input from multiple backend devices and forwards it to a
> > single frontend device. Additionally, `hub` device takes the output
> > fr
This is to be consistent with other reported errors related to vIOMMU
devices.
Signed-off-by: Cédric Le Goater
---
hw/vfio/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index
cf14987e42bd9188d5040b51a2f84cfa959f632d..ad326839db49cf3a5052
We plan to use vfio_viommu_preset() in MemoryListener handlers which
operate at the container level. Change the parameter to VFIOContainerBase
to ease future changes.
Signed-off-by: Cédric Le Goater
---
include/hw/vfio/vfio-common.h | 2 +-
hw/vfio/common.c | 4 ++--
hw/vfio/migrati
Hello,
Under certain circumstances, a MMIO region of a device fails to map
because the region is outside the supported IOVA ranges of the VM. In
this case, PCI peer-to-peer transactions on BARs are not supported.
This typically occurs when the IOMMU address space width is less than
the physical ad
When the IOMMU address space width is smaller than the physical
address width, a MMIO region of a device can fail to map because the
region is outside the supported IOVA ranges of the VM. In this case,
PCI peer-to-peer transactions on BARs are not supported.
This can occur with the 39-bit IOMMU ad
On 22/1/25 11:13, David Hildenbrand wrote:
On 22.01.25 11:10, David Hildenbrand wrote:
On 22.01.25 11:07, Philippe Mathieu-Daudé wrote:
Hi David,
On 20/1/25 12:14, David Hildenbrand wrote:
As documented in commit 4a2e242bbb306 ("memory: Don't use memcpy for
ram_device regions"), we disallow d
On 22.01.25 11:17, Philippe Mathieu-Daudé wrote:
On 22/1/25 11:13, David Hildenbrand wrote:
On 22.01.25 11:10, David Hildenbrand wrote:
On 22.01.25 11:07, Philippe Mathieu-Daudé wrote:
Hi David,
On 20/1/25 12:14, David Hildenbrand wrote:
As documented in commit 4a2e242bbb306 ("memory: Don't
KVM_SET_PMU_EVENT_FILTER of x86 KVM supports masked events mode, which
accepts masked entry format event to flexibly represent a group of PMU
events.
Support masked entry format in kvm-pmu-filter object and handle this in
i386 kvm codes.
Signed-off-by: Zhao Liu
---
Changes since RFC v1:
* Bump
CpuState caches its CPUClass since commit 6fbdff87062
("cpu: cache CPUClass in CPUState for hot code paths"),
use it.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
include/hw/core/cpu.h | 10 +++-
cpu-common.c | 10
cpu-target.c | 6 ++-
CpuState caches its CPUClass since commit 6fbdff87062
("cpu: cache CPUClass in CPUState for hot code paths"),
use it.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
target/arm/cpu.c | 3 +--
target/arm/tcg/cpu-v7m.c | 3 +--
2 files changed, 2 insertions(+), 4
As Daniel mentioned:
"The number of instances of MachineClass is not large enough
that we save a useful amount of memory through bitfields."
Also, see recent commit ecbf3567e21 ("docs/devel/style: add a
section about bitfield, and disallow them for packed structures").
Convert the MachineClas
On Thu, 16 Jan 2025 19:05:46 +0100
Philippe Mathieu-Daudé wrote:
> On 28/11/23 17:42, Igor Mammedov wrote:
> > On Mon, 18 Sep 2023 18:02:39 +0200
> > Philippe Mathieu-Daudé wrote:
> >
> >> While create_vcpu_thread() creates a vCPU thread, its counterpart
> >> is cpu_remove_sync(), which join
On Wed, 22 Jan 2025 at 12:36, Thomas Huth wrote:
>
> On 22/01/2025 11.32, Philippe Mathieu-Daudé wrote:
> > As Daniel mentioned:
> >
> > "The number of instances of MachineClass is not large enough
> >that we save a useful amount of memory through bitfields."
> >
> > Also, see recent commit
On Fri, Jan 17, 2025 at 10:26:51AM +0100, Paolo Bonzini wrote:
> Date: Fri, 17 Jan 2025 10:26:51 +0100
> From: Paolo Bonzini
> Subject: [PATCH 04/10] rust: pl011: extract CharBackend receive logic into
> a separate function
> X-Mailer: git-send-email 2.47.1
>
> Prepare for moving all references
CpuState caches its CPUClass since commit 6fbdff87062
("cpu: cache CPUClass in CPUState for hot code paths"),
use it.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
accel/accel-target.c | 12 +---
accel/tcg/tcg-accel-ops.c | 3 +--
accel/tcg/translate-all
CpuState caches its CPUClass since commit 6fbdff87062
("cpu: cache CPUClass in CPUState for hot code paths"),
use it.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
linux-user/alpha/target_proc.h | 2 +-
bsd-user/signal.c | 4 ++--
linux-user/signal.c
CpuState caches its CPUClass since commit 6fbdff87062
("cpu: cache CPUClass in CPUState for hot code paths"),
use it.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
disas/disas-common.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/disas/disa
CpuState caches its CPUClass since commit 6fbdff87062
("cpu: cache CPUClass in CPUState for hot code paths"),
use it.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
hw/acpi/cpu.c | 4 ++--
hw/acpi/cpu_hotplug.c | 3 +--
2 files changed, 3 insertions(+), 4 delet
Directly call cpu_set_pc() instead of open-coding it.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/core/generic-loader.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/hw/core/generic-loader.c b/hw/core/generic-loader.c
index fb354693aff..1b9ab600c9c 100644
--- a/hw/core
On 22/1/25 10:30, Philippe Mathieu-Daudé wrote:
Both CPUClass::gdb_read_register() and CPUClass::gdb_write_register()
handlers are called from common gdbstub code, and won't be called with
register index over CPUClass::gdb_num_core_regs:
int gdb_read_register(CPUState *cpu, GByteArray *buf, i
On Wed, Jan 22, 2025 at 03:30:05PM +1100, Alexey Kardashevskiy wrote:
>
>
> On 22/1/25 02:18, Peter Xu wrote:
> > On Tue, Jun 25, 2024 at 12:31:13AM +0800, Xu Yilun wrote:
> > > On Mon, Jan 20, 2025 at 03:46:15PM -0500, Peter Xu wrote:
> > > > On Mon, Jan 20, 2025 at 09:22:50PM +1100, Alexey Kard
On Tue, Jan 21, 2025 at 07:58:14AM +0100, Thomas Huth wrote:
> The decorators that use a lambda function are currently broken
> and do not properly skip the test if the condition is not met.
> Using "return skipUnless(lambda: ...)" does not work as expected.
> To fix it, rewrite the decorators with
Hi David,
On 20/1/25 12:14, David Hildenbrand wrote:
As documented in commit 4a2e242bbb306 ("memory: Don't use memcpy for
ram_device regions"), we disallow direct access to RAM DEVICE regions.
Let's factor out the "supports direct access" check from
memory_access_is_direct() so we can reuse it,
On 20/1/25 12:15, David Hildenbrand wrote:
We don't need the MemTxAttrs, so let's simply use the simpler function
variant.
Signed-off-by: David Hildenbrand
---
monitor/hmp-cmds-target.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé
On 22.01.25 11:07, Philippe Mathieu-Daudé wrote:
Hi David,
On 20/1/25 12:14, David Hildenbrand wrote:
As documented in commit 4a2e242bbb306 ("memory: Don't use memcpy for
ram_device regions"), we disallow direct access to RAM DEVICE regions.
Let's factor out the "supports direct access" check
1 - 100 of 181 matches
Mail list logo
