On Fri, May 02, 2025 at 11:48:37PM +0200, Paolo Bonzini wrote:
> These are some improvements to the x86 emulator that I wrote but have no
> way of testing (right now).
>
> I tried to place them in order of importance so that, if something breaks,
> it is possible to commit a subset. I tried to co
On Fri, May 2, 2025 at 7:04 PM Wei Liu wrote:
> I still have my loaner Macbook for a few more days. If I have not
> returned it when Paolo posts his patches I can build test HVF.
I have posted them now
(https://lore.kernel.org/qemu-devel/20250502214841.242584-1-pbonz...@redhat.com/).
They apply o
Just realised that I forgot to CC Paolo and also that I didn't strictly
enforce the tag order of name, version, authors and then alphabetically
like I wanted to.
I hope this is still enough of an improvement over the status quo.
I also considered centralising the `publish = false` but as the h
On 2/5/25 23:47, andrey.drobys...@virtuozzo.com wrote:
From: Andrey Drobyshev
Since the commit 3e6bed61 ("monitor: cleanup detection of qmp_dispatcher_co
shutting down"), coroutine pointer qmp_dispatcher_co is set to NULL upon
cleanup. If a QMP command is sent after monitor_cleanup() (e.g. aft
Replace target_ulong by vaddr or size_t types to match
cpu_memory_rw_debug() prototype in "exec/cpu-common.h":
int cpu_memory_rw_debug(CPUState *cpu, vaddr addr,
void *ptr, size_t len,
bool is_write);
Signed-off-by: Philippe Mathieu-Daudé
---
Replace target_ulong -> vaddr/size_t to compile once.
Philippe Mathieu-Daudé (2):
semihosting/uaccess: Remove uses of target_ulong type
semihosting/uaccess: Compile once
include/semihosting/uaccess.h | 12 ++--
semihosting/uaccess.c | 10 +-
semihosting/meson.build
Signed-off-by: Philippe Mathieu-Daudé
---
semihosting/meson.build | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/semihosting/meson.build b/semihosting/meson.build
index f3d38dda91d..a0a1c081f43 100644
--- a/semihosting/meson.build
+++ b/semihosting/meson.build
@@ -3,9 +3,7
Am 02.05.2025 um 19:52 hat Denis V. Lunev geschrieben:
> On 5/2/25 19:34, Kevin Wolf wrote:
> > Am 24.04.2025 um 19:32 hat Andrey Drobyshev geschrieben:
> > > Hi all,
> > >
> > > There's a bug in block layer which leads to block graph deadlock.
> > > Notably, it takes place when blockdev IO is pro
Just use cc_dst and cc_src for the same purpose.
Signed-off-by: Paolo Bonzini
---
target/i386/cpu.h | 6
target/i386/emulate/x86_emu.c | 4 +--
target/i386/emulate/x86_flags.c | 55 -
3 files changed, 29 insertions(+), 36 deletions(-)
diff
decode->op[N].ptr can contain either a host pointer (!) in CPUState
or a guest virtual address. Pass the whole struct to read_val_ext
and write_val_ext, so that it can decide the contents based on the
operand type.
Signed-off-by: Paolo Bonzini
---
target/i386/emulate/x86_decode.h | 9 ++-
tar
These are some improvements to the x86 emulator that I wrote but have no
way of testing (right now).
I tried to place them in order of importance so that, if something breaks,
it is possible to commit a subset. I tried to compile the resulting code
on Linux but I have not run it.
Patch 1 is just
While Bochs's algorithms are pretty solid, there are small opportunities
to improve them or to make their logic more similar to TCG's handling
of condition codes.
- use a single bit for the difference between bits 0..7 of result and PF.
This is useful because "set only ZF" is not a common case.
-
Do not assume that TARGET_FMT_lx is %llx.
Signed-off-by: Paolo Bonzini
---
target/i386/emulate/x86_decode.c | 2 +-
target/i386/emulate/x86_emu.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/i386/emulate/x86_decode.c b/target/i386/emulate/x86_decode.c
index 7e
From: Andrey Drobyshev
There's a race in monitor cleanup code which might result into SEGFAULT.
When monitor_cleanup() is launched, qmp_dispatcher_co coroutine pointer
is set to NULL (see Paolo's commit 3e6bed61 ("monitor: cleanup detection of
qmp_dispatcher_co shutting down")). If after that we
From: Andrey Drobyshev
Since the commit 3e6bed61 ("monitor: cleanup detection of qmp_dispatcher_co
shutting down"), coroutine pointer qmp_dispatcher_co is set to NULL upon
cleanup. If a QMP command is sent after monitor_cleanup() (e.g. after
shutdown), this may lead to SEGFAULT on aio_co_wake(NU
Check legacy guests support at runtime: instead of evaluating
the VIRTIO_MEM_HAS_LEGACY_GUESTS definition at compile time,
call target_system_arch() to detect which target is being run at
runtime. Register virtio_mem_legacy_guests_properties[] at runtime.
Signed-off-by: Philippe Mathieu-Daudé
---
Use target_system_arch() to check at runtime which target
architecture is being run.
Note, since TARGET_ARM is defined for TARGET_AARCH64, we
check for both ARM & AARCH64 enum values.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/virtio/virtio-mem.c | 23 +++
1 file changed, 1
Signed-off-by: Philippe Mathieu-Daudé
---
include/qemu/target-info.h | 9 +
hw/core/machine-qmp-cmds.c | 6 ++
target-info.c | 12
3 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/include/qemu/target-info.h b/include/qemu/target-info.h
index
Remove unused "system/ram_addr.h" header. This file doesn't
use any target specific definitions anymore, compile it once
by moving it to system_virtio_ss[].
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: David Hildenbrand
---
hw/virtio/virtio-mem.c | 1 -
hw/virtio/meson.build | 2 +-
2 fi
Reviewed-by: Richard Henderson
Signed-off-by: Philippe Mathieu-Daudé
---
include/qemu/target-info-impl.h | 4 +++-
target-info-stub.c | 1 +
target-info.c | 3 +++
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/qemu/target-info-impl.h b/inclu
Since v2:
- Use TargetInfo API (Pierrick)
Since v1:
- Use max extent size of all archs (David)
Based-on: <20250501212113.2961531-1-richard.hender...@linaro.org>
Philippe Mathieu-Daudé (5):
qemu/target-info: Factor target_system_arch() out
qemu/target-info: Add %target_arch field to TargetInf
This commit bundles common config option in the workspace
root and applies them through .workspace = true
Signed-off-by: Stefan Zabka
---
rust/Cargo.toml | 7 +++
rust/hw/char/pl011/Cargo.toml | 11 ++-
rust/hw/timer/hpet/Cargo.toml | 9 ++---
rust/qemu-api-
In the source code of BHyve, there is a reference to qemu. The partial
solution is to ask the qemu poc and development what the CPU machine
parameters would equal the physical CPU. If that is not available, then the
virtualization would need to be the most recent CPU software translation.
I thought
Queued, thanks.
Paolo
Il ven 2 mag 2025, 20:58 Stefan Zabka ha scritto:
> Unrelated to the actual change, but a drive-by observation:
> If you want to keep the MSRV in sync across all workspace members, you
> could use workspace.package.rust-version to define it once and inherit
> it everywhere. (Same goes for edition
The pc_compat_2_7[] array was only used by the pc-q35-2.7
and pc-i440fx-2.7 machines, which got removed. Remove it.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Mark Cave-Ayland
---
include/hw/i386/pc.h | 3 ---
hw/i386/pc.c | 10 --
2 files changed, 13 deletions(-)
diff
The hw_compat_2_7[] array was only used by the pc-q35-2.7 and
pc-i440fx-2.7 machines, which got removed. Remove it.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Mark Cave-Ayland
---
include/hw/boards.h | 3 ---
hw/core/machine.c | 9 -
2 files changed, 12 deletions(-)
diff --gi
The IOAPICCommonState::version integer was only set
in the hw_compat_2_7[] array, via the 'version=0x11'
property. We removed all machines using that array,
lets remove that property, simplify by only using the
default version (defined as IOAPIC_VER_DEF).
For the record, this field was introduced
These machines has been supported for a period of more than 6 years.
According to our versioned machine support policy (see commit
ce80c4fa6ff "docs: document special exception for machine type
deprecation & removal") they can now be removed.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Mar
The PCSpkState::migrate boolean was only set in the
pc_compat_2_7[] array, via the 'migrate=off' property.
We removed all machines using that array, lets remove
that property, simplifying vmstate_spk[].
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Mark Cave-Ayland
---
hw/audio/pcspk.c | 1
The IntelIOMMUState::buggy_eim boolean was only set in
the hw_compat_2_7[] array, via the 'x-buggy-eim=true'
property. We removed all machines using that array, lets
remove that property, simplifying vtd_decide_config().
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Mark Cave-Ayland
---
in
The VIRTIO_CONSOLE_F_EMERG_WRITE feature bit was only set
in the hw_compat_2_7[] array, via the 'emergency-write=off'
property. We removed all machines using that array, lets remove
that property. All instances have this feature bit set and
it can not be disabled. VirtIOSerial::host_features mask i
The VirtIOPCIProxy::ignore_backend_features boolean was only set
in the hw_compat_2_7[] array, via the 'x-ignore-backend-features=on'
property. We removed all machines using that array, lets remove
that property, simplify by only using the default version.
Signed-off-by: Philippe Mathieu-Daudé
Re
Now than all calls to fw_cfg_init_io_dma() pass DMA arguments,
the 'dma_enabled' of the TYPE_FW_CFG_IO type is not used anymore.
Remove it, simplifying fw_cfg_init_io_dma() and fw_cfg_io_realize().
Note, we can not remove the equivalent in fw_cfg_mem_properties[]
because it is still used in HPPA a
The VirtIOMMIOProxy::format_transport_address boolean was only set
in the hw_compat_2_6[] array, via the 'format_transport_address=off'
property. We removed all machines using that array, lets remove
that property, simplifying virtio_mmio_bus_get_dev_path().
Signed-off-by: Philippe Mathieu-Daudé
These machines has been supported for a period of more than 6 years.
According to our versioned machine support policy (see commit
ce80c4fa6ff "docs: document special exception for machine type
deprecation & removal") they can now be removed.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Mar
The APICCommonState::legacy_instance_id boolean was only set
in the pc_compat_2_6[] array, via the 'legacy-instance-id=on'
property. We removed all machines using that array, lets remove
that property, simplifying apic_common_realize().
Because instance_id is initialized as initial_apic_id, we can
Unrelated to the actual change, but a drive-by observation:
If you want to keep the MSRV in sync across all workspace members, you
could use workspace.package.rust-version to define it once and inherit
it everywhere. (Same goes for edition, license, and resolver.)
https://doc.rust-lang.org/car
VIRTIO_PCI_FLAG_PAGE_PER_VQ was only used by the hw_compat_2_7[]
array, via the 'page-per-vq=on' property. We removed all
machines using that array, lets remove all the code around
VIRTIO_PCI_FLAG_PAGE_PER_VQ (see commit 9a4c0e220d8 for similar
VIRTIO_PCI_FLAG_* enum removal).
Signed-off-by: Phili
The hw_compat_2_6[] array was only used by the pc-q35-2.6 and
pc-i440fx-2.6 machines, which got removed. Remove it.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Mark Cave-Ayland
---
include/hw/boards.h | 3 ---
hw/core/machine.c | 8
2 files changed, 11 deletions(-)
diff --git
The X86MachineClass::fwcfg_dma_enabled boolean was only used
by the pc-q35-2.6 and pc-i440fx-2.6 machines, which got
removed. Remove it and simplify.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/x86.h | 2 --
hw/i386/microvm.c | 3 ---
hw/i386/multiboot.c | 7 +--
hw/i386/
The pc_compat_2_6[] array was only used by the pc-q35-2.6
and pc-i440fx-2.6 machines, which got removed. Remove it.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Mark Cave-Ayland
---
include/hw/i386/pc.h | 3 ---
hw/i386/pc.c | 8
2 files changed, 11 deletions(-)
diff --g
Factor fw_cfg_init_mem_internal() out of fw_cfg_init_mem_wide().
In fw_cfg_init_mem_wide(), assert DMA arguments are provided.
Callers without DMA have to use the fw_cfg_init_mem() helper.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/nvram/fw_cfg.c | 20 ++--
1 file changed, 14 i
fw_cfg_init_mem_wide() is prefered to initialize fw_cfg
with DMA support. Without DMA, use fw_cfg_init_mem().
Signed-off-by: Philippe Mathieu-Daudé
---
hw/mips/loongson3_virt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/mips/loongson3_virt.c b/hw/mips/loongson3_virt.c
The PCMachineClass::legacy_cpu_hotplug boolean was only used
by the pc-q35-2.6 and pc-i440fx-2.6 machines, which got
removed. Remove it and simplify build_dsdt(), removing
build_legacy_cpu_hotplug_aml() altogether.
Note, this field was added by commit 679dd1a957d ("pc: use
new CPU hotplug interfac
Since v2:
- Addressed Mark review comments and added his R-b tags
The versioned 'pc' and 'q35' machines up to 2.12 been marked
as deprecated two releases ago, and are older than 6 years,
so according to our support policy we can remove them.
This series only includes the 2.6 and 2.7 machines remo
On 5/2/25 6:27 AM, Shameer Kolothum wrote:
From: Nicolin Chen
This is useful as the subsequent support for new SMMUv3 dev will also
use the same.
Signed-off-by: Nicolin Chen
Signed-off-by: Shameer Kolothum
---
hw/arm/virt.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
On 5/2/25 1:13 PM, Nicolin Chen wrote:
On Fri, May 02, 2025 at 11:27:03AM +0100, Shameer Kolothum wrote:
@@ -43,6 +43,7 @@
#include "hw/acpi/generic_event_device.h"
#include "hw/acpi/tpm.h"
#include "hw/acpi/hmat.h"
+#include "hw/arm/smmuv3.h"
#include "hw/pci/pcie_host.h"
#include
On 5/2/25 6:27 AM, Shameer Kolothum wrote:
Although this change does not affect functionality at present, it lays
the groundwork for enabling user-created SMMUv3 devices in
future patches
Signed-off-by: Shameer Kolothum
---
hw/arm/smmuv3.c | 26 ++
hw/arm/virt.c
On 5/2/25 6:27 AM, Shameer Kolothum wrote:
Hi All,
Changes from v1:
https://lore.kernel.org/qemu-devel/20250415081104.71708-1-shameerali.kolothum.th...@huawei.com/
Addressed feedback on v1. Thanks to all.
1. Retained the same name as the legacy SMMUv3(arm-smmuv3) for new
device type as w
On Fri, May 02, 2025 at 11:27:07AM +0100, Shameer Kolothum wrote:
> Signed-off-by: Shameer Kolothum
Though I think the commit log shouldn't be empty,
Reviewed-by: Nicolin Chen
On 5/2/25 19:34, Kevin Wolf wrote:
Am 24.04.2025 um 19:32 hat Andrey Drobyshev geschrieben:
Hi all,
There's a bug in block layer which leads to block graph deadlock.
Notably, it takes place when blockdev IO is processed within a separate
iothread.
This was initially caught by our tests, and I
On Fri, May 02, 2025 at 11:27:06AM +0100, Shameer Kolothum wrote:
> @@ -2972,6 +3004,21 @@ static void virt_machine_device_plug_cb(HotplugHandler
> *hotplug_dev,
> virtio_md_pci_plug(VIRTIO_MD_PCI(dev), MACHINE(hotplug_dev), errp);
> }
>
> +if (object_dynamic_cast(OBJECT(dev),
Am 24.04.2025 um 19:32 hat Andrey Drobyshev geschrieben:
> Hi all,
>
> There's a bug in block layer which leads to block graph deadlock.
> Notably, it takes place when blockdev IO is processed within a separate
> iothread.
>
> This was initially caught by our tests, and I was able to reduce it to
On Fri, May 02, 2025 at 11:27:02AM +0100, Shameer Kolothum wrote:
> Although this change does not affect functionality at present, it lays
> the groundwork for enabling user-created SMMUv3 devices in
> future patches
>
> Signed-off-by: Shameer Kolothum
Reviewed-by: Nicolin Chen
With some nits:
On Fri, May 02, 2025 at 11:27:04AM +0100, Shameer Kolothum wrote:
> No functional changes intended. This will be useful when we
> add support for user-creatable smmuv3 device.
>
> Signed-off-by: Shameer Kolothum
Reviewed-by: Nicolin Chen
On Fri, May 02, 2025 at 11:27:03AM +0100, Shameer Kolothum wrote:
> @@ -43,6 +43,7 @@
> #include "hw/acpi/generic_event_device.h"
> #include "hw/acpi/tpm.h"
> #include "hw/acpi/hmat.h"
> +#include "hw/arm/smmuv3.h"
> #include "hw/pci/pcie_host.h"
> #include "hw/pci/pci.h"
> #include "hw/pci/p
On Tue, Apr 29, 2025 at 02:17:01PM +0200, Magnus Kulke wrote:
> On Tue, Apr 29, 2025 at 12:02:48PM +0200, Paolo Bonzini wrote:
> > Il mar 29 apr 2025, 11:33 Magnus Kulke ha
> > scritto:
> >
> > > Fixes: c901905ea670 ("target/i386/emulate: remove flags_mask")
> > >
> > > In c901905ea670 rflags hav
On Wed, 2 Apr 2025 at 14:28, Daniel P. Berrangé wrote:
> On Wed, Apr 02, 2025 at 09:33:16AM +, Bernhard Beschow wrote:
> > Am 31. März 2025 09:18:05 UTC schrieb "Daniel P. Berrangé"
> > :
> > >General conceptual question . I've never understood what the dividing
> > >line is between use
From: Thomas Huth
ghes_addr_le has been renamed to hw_error_le in commit 652f6d86cbb
("acpi/ghes: better name the offset of the hardware error firmware").
Adjust the checker script to allow that changed field name.
Signed-off-by: Thomas Huth
Reviewed-by: Peter Xu
Link: https://lore.kernel.org/
From: Li Zhijian
control_save_page() is for RDMA only, unfold it to make the code more
clear.
In addition:
- Similar to other branches style in ram_save_target_page(), involve RDMA
only if the condition 'migrate_rdma()' is true.
- Further simplify the code by removing the RAM_SAVE_CONTROL_NO
From: Li Zhijian
It's believed that RDMA + postcopy-ram has been broken for a while.
Rather than spending time re-enabling it, let's simply disable it as a
trade-off.
Reviewed-by: Peter Xu
Signed-off-by: Li Zhijian
Message-ID: <20250305062825.772629-4-lizhij...@fujitsu.com>
Signed-off-by: Fabi
From: Prasad Pandit
The various logical migration channels don't have a
standardized way of advertising themselves and their
connections may be seen out of order by the migration
destination. When a new connection arrives, the incoming
migration currently make use of heuristics to determine
which
From: Markus Armbruster
migrate_params_test_apply() neglects to apply tls_authz. Currently
harmless, because migrate_params_check() doesn't care. Fix it anyway.
Signed-off-by: Markus Armbruster
Reviewed-by: Fabiano Rosas
Message-ID: <20250407072833.2118928-1-arm...@redhat.com>
Signed-off-by:
From: Li Zhijian
This qtest requires there is a RDMA(RoCE) link in the host.
In order to make the test work smoothly, introduce a
scripts/rdma-migration-helper.sh to detect existing RoCE link before
running the test.
Test will be skipped if there is no available RoCE link.
# Start of rdma tests
From: Jack Wang
I hit following error which testing migration in pure RoCE env:
"-incoming rdma:[::]:8089: RDMA ERROR: You only have RoCE / iWARP devices in
your
systems and your management software has specified '[::]', but IPv6 over RoCE /
iWARP is not supported in Linux.#012'."
In our setup,
The following changes since commit 5134cf9b5d3aee4475fe7e1c1c11b093731073cf:
Merge tag 'block-pull-request' of https://gitlab.com/stefanha/qemu into
staging (2025-04-30 13:34:44 -0400)
are available in the Git repository at:
https://gitlab.com/peterx/qemu.git tags/migration-202
From: Li Zhijian
Depending on the order of starting RDMA and setting capability,
they can be categorized into the following scenarios:
Source:
S1: [set capabilities] -> [Start RDMA outgoing]
Destination:
D1: [set capabilities] -> [Start RDMA incoming]
D2: [Start RDMA incoming] -> [set capabili
From: Prasad Pandit
Move MULTIFD_ macros to the header file so that
they are accessible from other source files.
Reviewed-by: Fabiano Rosas
Signed-off-by: Prasad Pandit
Reviewed-by: Peter Xu
Message-ID: <2025044534.3370816-2-ppan...@redhat.com>
Signed-off-by: Fabiano Rosas
---
migration
The preempt mode postcopy has been introduced for a while. From latency
POV, it should always win the vanilla postcopy.
However there's one thing missing when preempt mode is enabled right now,
which is the spatial locality hint when there're page requests from the
destination side.
In vanilla p
Implement save_postcopy_prepare(), preparing for the enablement
of both multifd and postcopy.
Signed-off-by: Peter Xu
Signed-off-by: Prasad Pandit
Reviewed-by: Fabiano Rosas
Message-ID: <2025044534.3370816-5-ppan...@redhat.com>
Signed-off-by: Fabiano Rosas
---
migration/ram.c | 37 +++
Add a savevm handler for a module to opt-in sending extra sections right
before postcopy starts, and before VM is stopped.
RAM will start to use this new savevm handler in the next patch to do flush
and sync for multifd pages.
Note that we choose to do it before VM stopped because the current onl
From: Li Zhijian
Since we have disabled RDMA + postcopy, it's safe to remove
the migration_in_postcopy() that follows the migrate_rdma().
Reviewed-by: Peter Xu
Signed-off-by: Li Zhijian
Message-ID: <20250305062825.772629-5-lizhij...@fujitsu.com>
Signed-off-by: Fabiano Rosas
---
migration/rdm
From: Prasad Pandit
Migration capabilities are set in multiple '.start_hook'
functions for various tests. Instead, consolidate setting
capabilities in 'migrate_start_set_capabilities()' function
which is called from the 'migrate_start()' function.
While simplifying the capabilities setting, it he
On 5/2/25 6:24 AM, Philippe Mathieu-Daudé wrote:
Legacy VirtIO devices don't have their endianness clearly defined.
QEMU infers it taking the endianness of the (target) binary, or,
when a target support switching endianness at runtime, taking the
endianness of the vCPU accessing the device.
Pr
On 5/2/25 11:55, BALATON Zoltan wrote:
This property was added to preserve previous value when this was fixed
in version 2.1 but the last machine using it was already removed when
adding diva-gsp leaving this property unused and unnecessary.
Signed-off-by: BALATON Zoltan
Reviewed-by: Philippe M
On 4/29/2025 2:02 AM, Markus Armbruster wrote:
Steven Sistare writes:
On 4/28/2025 4:04 AM, Markus Armbruster wrote:
Steven Sistare writes:
On 4/9/2025 3:39 AM, Markus Armbruster wrote:
Hi Steve, I apologize for the slow response.
Steve Sistare writes:
Using qom-list and qom-get to ge
On 5/2/25 6:05 AM, Peter Maydell wrote:
I've queued this series to target-arm.next; thanks.
-- PMM
Thank you Peter :)
On Fri, May 02, 2025 at 10:01:55AM +0100, Jonathan Cameron wrote:
> On Thu, 1 May 2025 20:21:56 +
> Fan Ni wrote:
>
> > On Thu, Apr 24, 2025 at 11:42:59AM +0100, Jonathan Cameron wrote:
> > > On Mon, 17 Mar 2025 16:31:30 +
> > > anisa.su...@gmail.com wrote:
> > >
> > > > From: Anisa Su
Because LSS need not trigger an IRQ shadow, gen_movl_seg can't just use
the destination register to decide whether to inhibit IRQs. Add an
argument.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Paolo Bonzini
---
target/i386/tcg/translate.c | 27 ---
target/i386/tcg/emit.c.i
LSS should not trigger the interrupt shadow, unlike MOV and POP to SS.
STI should trigger the interrupt shadow but only MOV and POP to SS
should block singlestep.
Paolo
Paolo Bonzini (2):
target/i386: do not trigger IRQ shadow for LSS
target/i386: do not block singlestep for STI
target/i38
STI will trigger a singlestep exception even if it has inhibit-IRQ
behavior. Do not suppress single-step for all IRQ-inhibiting
instructions, instead special case MOV SS and POP SS.
Cc: qemu-sta...@nongnu.org
Fixes: f0f0136abba ("target/i386: no single-step exception after MOV or POP
SS", 2024-0
On 3/18/25 04:42, Peter Maydell wrote:
Our KVM code includes backwards compatibility support for ancient
kernels which don't support the KVM_ARM_PREFERRED_TARGET ioctl. This
ioctl was introduced in kernel commit 42c4e0c77ac91 in September
2013 and is in v3.12, so it's reasonable to assume it's p
On Wed, 23 Apr 2025 at 12:31, Philippe Mathieu-Daudé wrote:
>
> Hi Thomas,
>
> On 23/4/25 11:40, Thomas Huth wrote:
> > On 23/04/2025 11.31, Bernhard Beschow wrote:
> >>
> >>
> >> Am 10. April 2025 06:05:35 UTC schrieb Thomas Huth :
> >>> On 09/04/2025 22.26, Bernhard Beschow wrote:
> Introdu
On 2/5/25 15:37, Peter Maydell wrote:
On Thu, 16 Jan 2025 at 14:59, Philippe Mathieu-Daudé wrote:
The versioned 'virt' machines up to 2.12 been marked as deprecated
two releases ago, and are older than 6 years, so according to our
support policy we can remove them. Remove associated dead code.
Adding some vfio people who I hope could give some more insight. The
question I try to find out is why accessing VRAM of a graphics card passed
through with vfio-pci to a PPC guest running on x86_64 host with TCG is
slow.
On Wed, 30 Apr 2025, BALATON Zoltan wrote:
On Wed, 30 Apr 2025, Alex Be
Add vfio_container_group_add to de-dup some code. No functional change.
Signed-off-by: Steve Sistare
Reviewed-by: Cedric Le Goater
---
hw/vfio/container.c | 47 +--
1 file changed, 25 insertions(+), 22 deletions(-)
diff --git a/hw/vfio/container.c b
Replace the proliferation of exit labels in vfio_container_connect with
conditionals for cleaning each piece of state. No functional change.
Signed-off-by: Steve Sistare
Reviewed-by: Cedric Le Goater
---
hw/vfio/container.c | 60 +
1 file cha
Cleanup a few vfio functions prior to the introduction of CPR.
These were extracted from
https://lore.kernel.org/qemu-devel/1739542467-226739-1-git-send-email-steven.sist...@oracle.com/
Changes in V3:
* update to master
Steve Sistare (3):
vfio/container: ram discard disable helper
vfio
Define a helper to set ram discard disable, generate error messages,
and cleanup on failure. The second vfio_ram_block_discard_disable
call site now performs VFIO_GROUP_UNSET_CONTAINER immediately on failure,
instead of relying on the close of the container fd to do so in the kernel,
but this is e
On Thu, 16 Jan 2025 at 14:59, Philippe Mathieu-Daudé wrote:
>
> The versioned 'virt' machines up to 2.12 been marked as deprecated
> two releases ago, and are older than 6 years, so according to our
> support policy we can remove them. Remove associated dead code.
>
> Since v1:
> - Corrected disal
On 18/3/25 12:42, Peter Maydell wrote:
Our KVM code includes backwards compatibility support for ancient
kernels which don't support the KVM_ARM_PREFERRED_TARGET ioctl. This
ioctl was introduced in kernel commit 42c4e0c77ac91 in September
2013 and is in v3.12, so it's reasonable to assume it's p
Legacy VirtIO devices don't have their endianness clearly defined.
QEMU infers it taking the endianness of the (target) binary, or,
when a target support switching endianness at runtime, taking the
endianness of the vCPU accessing the device.
Devices modelling shouldn't really change depending on
Dominik 'Disconnect3d' Czarnota writes:
> This patch adds support for the `qqemu.Pid` packet to the qemu
> gdbstub which can be used by clients to get the QEMU process PID.
>
> This is useful for plugins like Pwndbg [0] or gdb-pt-dump in order to
> inspect the QEMU process memory through the /pro
On Fri, May 2, 2025 at 3:23 PM Paolo Bonzini wrote:
>
> On 5/2/25 13:01, Manos Pitsidianakis wrote:
> > On Fri, 02 May 2025 13:23, Paolo Bonzini wrote:
> >> Signed-off-by: Paolo Bonzini
> >> ---
> >> docs/devel/rust.rst | 4 --
> >> rust/hw/timer/hpet/src/fw_cfg.rs | 6 +-
> >> ru
On Mon, 28 Apr 2025 at 20:34, Pierrick Bouvier
wrote:
>
> On 4/14/25 8:30 AM, Pierrick Bouvier wrote:
> > It was reported that QEMU monitor command gva2gpa was reporting unmapped
> > memory for a valid access (qemu-system-aarch64), during a copy from
> > kernel to user space (__arch_copy_to_user s
On Wed, 2 Apr 2025 at 14:52, Mads Ynddal wrote:
>
> From: Mads Ynddal
>
> In (recent versions of?) macOS, calls to hv_vcpu_set_sys_reg were failing if
> they were issued outside of the specific thread that owns the vCPU.
>
> This caused a crash when attaching a debugger through the GDB stub.
>
>
On Wed, 2 Apr 2025 at 14:52, Mads Ynddal wrote:
>
> From: Mads Ynddal
>
> hv_vcpu_set_sys_reg should only be called from the owning thread of the
> vCPU, so to avoid crashes, the call to hvf_update_guest_debug is
> dispatched to the individual threads.
>
> Tested-by: Daniel Gomez
> Signed-off-by
Dominik 'Disconnect3d' Czarnota writes:
> This commit adds support for the `qGDBServerVersion` packet to the qemu
> gdbstub which could be used by clients to detect the QEMU version
> (and, e.g., use a workaround for known bugs).
>
> This packet is not documented/standarized by GDB but it was im
On Fri, 02 May 2025 13:23, Paolo Bonzini wrote:
>"let ... else" is useful when visiting syntax trees, to avoid multiple
>levels of indentation.
>
>Signed-off-by: Paolo Bonzini
>---
> rust/qemu-api-macros/src/lib.rs | 84 -
> 1 file changed, 40 insertions(+), 44 dele
1 - 100 of 188 matches
Mail list logo
