On 5/27/25 21:45, Pierrick Bouvier wrote:
On 5/24/25 7:40 AM, Richard Henderson wrote:
When we moved TLB_MMIO and TLB_DISCARD_WRITE to TLB_SLOW_FLAGS_MASK,
we failed to update atomic_mmu_lookup to properly reconstruct flags.
Fixes: 24b5e0fdb543 ("include/exec: Move TLB_MMIO, TLB_DISCARD_WRITE t
Peter Xu writes:
> Unfortunately, it was never correctly shown..
>
> This is only found when I started to look into making the blocktime feature
> more useful (so as to avoid using bpftrace, even though I'm not sure which
> one will be harder to use..).
>
> So the old dump would look like this:
>
Eric Blake writes:
> On Tue, Apr 29, 2025 at 01:31:44PM +0200, Markus Armbruster wrote:
>> > In the context of qemu that might suggest having separate
>> > multi_conn_requested and multi_conn fields, where the latter can be
>> > queried over QMP to find out what is actually going on. Could even
Enhance HostIOMMUDeviceIOMMUFD object with 3 new members, specific
to the iommufd BE + 2 new class functions.
IOMMUFD BE includes IOMMUFD handle, devid and hwpt_id. IOMMUFD handle
and devid are used to allocate/free ioas and hwpt. hwpt_id is used to
re-attach IOMMUFD backed device to its default V
Hi,
The first 6 patches of [1] are all VFIO or IOMMUFD related additions.
Split them out per Cédric and seek for quick acceptance.
I didn't copy changelog from [1] as it's a mix of the whole nesting series.
Compared to rfcv3 in [1], changed to save raw data in VendorCaps, so we can
keep all vendo
Implement query of HOST_IOMMU_DEVICE_CAP_[NESTING|FS1GP|ERRATA] for IOMMUFD
backed host VTD IOMMU device.
Query on these capabilities is not supported for legacy backend because there
is no plan to support nesting with legacy backend backed host device.
Signed-off-by: Zhenzhong Duan
---
hw/i386
Some device information returned by ioctl(IOMMU_GET_HW_INFO) are vendor
specific. Save them as raw data in a union supporting different vendors,
then get_cap() can provide a general interface for querying capability
and hide different vendor data format under it.
Because IOMMU_GET_HW_INFO is only
Implement [at|de]tach_hwpt handlers in VFIO subsystem. vIOMMU
utilizes them to attach to or detach from hwpt on host side.
Signed-off-by: Yi Liu
Signed-off-by: Zhenzhong Duan
---
hw/vfio/iommufd.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/hw/vfio/iommufd.c b/hw
This helper passes cache invalidation request from guest to invalidate
stage-1 page table cache in host hardware.
Signed-off-by: Nicolin Chen
Signed-off-by: Zhenzhong Duan
---
include/system/iommufd.h | 4
backends/iommufd.c | 33 +
backends/trace-eve
There are three iommufd specific members in HostIOMMUDeviceIOMMUFD
that need to be initialized after attachment, they will all be used
by vIOMMU.
Signed-off-by: Zhenzhong Duan
---
hw/vfio/iommufd.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/hw/vfio/iommufd.c b/hw/vfio/iommufd.c
in
On 28/05/2025 05:58, Peter Xu wrote:
> Dave suggested the HMP output for "info migrate" can not only leverage the
> lines but also better grouping:
>
>https://lore.kernel.org/r/aC4_-nMc7FwsMf9p@gallifrey
>
> I followed Dave's suggestion, and some more modifications on top:
>
>- Added a
Pierrick Bouvier writes:
> On 5/27/25 4:26 AM, Markus Armbruster wrote:
[...]
> All good for me.
> The only question that crossed my mind when you asked for those changes
> previously was: "Why does QAPI has it's own style, and not simply following
> the QEMU official style?"
Fair question!
On Wed, May 28, 2025 at 10:09:56AM +0800, Xiaoyao Li wrote:
> Date: Wed, 28 May 2025 10:09:56 +0800
> From: Xiaoyao Li
> Subject: Re: [PATCH v4 04/19] target/i386/cpu: Remove X86CPU::check_cpuid
> field
>
> On 5/12/2025 4:39 PM, Philippe Mathieu-Daudé wrote:
> > The X86CPU::check_cpuid boolean w
Pierrick Bouvier writes:
> On 5/27/25 6:00 AM, Markus Armbruster wrote:
>> Pierrick Bouvier writes:
>>
>>> This series exposes all qmp commands for any target unconditionally,
>>> allowing to
>>> compile QAPI generated code without any TARGET conditionals.
>>>
>>> Based on original RFC from Da
Pierrick Bouvier writes:
> On 5/27/25 4:20 AM, Markus Armbruster wrote:
>> Pierrick Bouvier writes:
>>
>>> Signed-off-by: Pierrick Bouvier
>>
>> My comment on the previous patch applies.
>>
>
> I'm not sure to which comment exactly you refer to.
Should've been explicit :)
I'd squash this in
Pierrick Bouvier writes:
> On 5/27/25 4:38 AM, Markus Armbruster wrote:
>> You took authorship from Daniel. Intentional?
>> Pierrick Bouvier writes:
>>
>>> This removes the TARGET_* conditions from all the CPU commands
>>> that are conceptually target independent. Top level stubs are
>>> provi
Eric Blake writes:
> On Wed, May 21, 2025 at 08:37:08AM +0200, Markus Armbruster via Devel wrote:
>> Commit 4d8b0f0a9536 (v6.2.0) deprecate incorrectly typed device_add
>
> deprecated
Yes. Thank you!
>> arguments. Commit be93fd53723c (qdev-monitor: avoid QemuOpts in QMP
>> device_add) fixed t
On 5/28/2025 11:48 AM, Zhao Liu wrote:
On Wed, May 28, 2025 at 11:22:57AM +0800, Xiaoyao Li wrote:
Date: Wed, 28 May 2025 11:22:57 +0800
From: Xiaoyao Li
Subject: Re: [PATCH] Revert "i386/cpu: Set up CPUID_HT in
x86_cpu_expand_features() instead of cpu_x86_cpuid()"
On 5/28/2025 11:25 AM, Zha
I will leave ByteDance in the next days. Update email to stay reachable.
Signed-off-by: zhenwei pi
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7060cf49b9..2da7cf76b7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3278,7 +327
On 2025/05/27 22:46, Peter Xu wrote:
On Tue, May 27, 2025 at 11:09:08AM +0900, Akihiko Odaki wrote:
On 2025/05/26 23:48, Peter Xu wrote:
On Mon, May 26, 2025 at 02:29:10PM +0900, Akihiko Odaki wrote:
Akihiko Odaki (11):
futex: Check value after qemu_futex_wait()
futex: Support
On Wed, May 28, 2025 at 11:22:57AM +0800, Xiaoyao Li wrote:
> Date: Wed, 28 May 2025 11:22:57 +0800
> From: Xiaoyao Li
> Subject: Re: [PATCH] Revert "i386/cpu: Set up CPUID_HT in
> x86_cpu_expand_features() instead of cpu_x86_cpuid()"
>
> On 5/28/2025 11:25 AM, Zhao Liu wrote:
> > Hi Elisey,
> >
On 2025/05/28 0:01, Paolo Bonzini wrote:
On Tue, May 27, 2025 at 5:01 AM Akihiko Odaki wrote:
I'd like to submit it with "[PATCH v4 05/11] qemu-thread: Avoid futex
abstraction for non-Linux" because it aligns the implementations of
Linux and non-Linux versions to rely on a store-release of EV_S
On 5/28/2025 11:25 AM, Zhao Liu wrote:
Hi Elisey,
Thank you for your patch! I'm sorry I previously noticed #2894 [*] but
missed your report.
Recently there's a fix (commit 5979f50fa9fd ("i386/tcg: Make CPUID_HT
and CPUID_EXT3_CMP_LEG supported")). Does that fix address this bug?
[*]: https://l
Tested this series of patches with vhost-net regression tests,
everything works fine.
Tested-by: Lei Yang
On Fri, May 23, 2025 at 4:24 PM Akihiko Odaki wrote:
>
> On 2025/05/21 20:34, Paolo Abeni wrote:
> > When the GSO over UDP tunnel offload is enabled, the virtio net
> > header includes addi
Hi Elisey,
Thank you for your patch! I'm sorry I previously noticed #2894 [*] but
missed your report.
Recently there's a fix (commit 5979f50fa9fd ("i386/tcg: Make CPUID_HT
and CPUID_EXT3_CMP_LEG supported")). Does that fix address this bug?
[*]: https://lore.kernel.org/qemu-devel/acwdhiqziu4q+..
On 5/12/2025 4:39 PM, Philippe Mathieu-Daudé wrote:
(series reviewed)
Since v3:
- Fixed 2 issues noticed by Thomas (floppy fallback, e1000)
Since v2:
- Removed qtest in test-x86-cpuid-compat.c
Since v1:
- Fixed issues noticed by Thomas
The versioned 'pc' and 'q35' machines up to 2.12 been mar
On 5/12/2025 4:39 PM, Philippe Mathieu-Daudé wrote:
Simplify merging vmxnet3_realize() within vmxnet3_instance_init(),
removing the need for device_class_set_parent_realize().
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Daniel P. Berrangé
Reviewed-by: Zhao Liu
Reviewed-by: Xiaoyao Li
On 5/12/2025 4:39 PM, Philippe Mathieu-Daudé wrote:
VMXNET3_COMPAT_FLAG_DISABLE_PCIE was only used by the
hw_compat_2_5[] array, via the 'x-disable-pcie=on' property.
We removed all machines using that array, lets remove all the
code around VMXNET3_COMPAT_FLAG_DISABLE_PCIE.
Signed-off-by: Philip
On 5/12/2025 4:39 PM, Philippe Mathieu-Daudé wrote:
VMXNET3_COMPAT_FLAG_OLD_MSI_OFFSETS was only used by the
hw_compat_2_5[] array, via the 'x-old-msi-offsets=on' property.
We removed all machines using that array, lets remove all the
code around VMXNET3_COMPAT_FLAG_OLD_MSI_OFFSETS.
Signed-off-b
On 5/12/2025 4:39 PM, Philippe Mathieu-Daudé wrote:
Simplify replacing pvscsi_realize() by pvscsi_instance_init(),
removing the need for device_class_set_parent_realize().
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Daniel P. Berrangé
Reviewed-by: Zhao Liu
Reviewed-by: Xiaoyao Li
On 5/12/2025 4:39 PM, Philippe Mathieu-Daudé wrote:
PVSCSI_COMPAT_DISABLE_PCIE_BIT was only used by the
hw_compat_2_5[] array, via the 'x-disable-pcie=on' property.
We removed all machines using that array, lets remove all the
code around PVSCSI_COMPAT_DISABLE_PCIE_BIT, including the now
unused P
On 5/12/2025 4:39 PM, Philippe Mathieu-Daudé wrote:
PVSCSI_COMPAT_OLD_PCI_CONFIGURATION was only used by the
hw_compat_2_5[] array, via the 'x-old-pci-configuration=on'
property. We removed all machines using that array, lets remove
all the code around PVSCSI_COMPAT_OLD_PCI_CONFIGURATION.
Signed
On 5/12/2025 4:39 PM, Philippe Mathieu-Daudé wrote:
The MachineClass::legacy_fw_cfg_order boolean was only used
by the pc-q35-2.5 and pc-i440fx-2.5 machines, which got
removed. Remove it along with:
- FW_CFG_ORDER_OVERRIDE_* definitions
- fw_cfg_set_order_override()
- fw_cfg_reset_order_override
On 5/12/2025 4:39 PM, Philippe Mathieu-Daudé wrote:
VIRTIO_PCI_FLAG_DISABLE_PCIE was only used by the hw_compat_2_4[]
array, via the 'x-disable-pcie=false' property. We removed all
machines using that array, lets remove all the code around
VIRTIO_PCI_FLAG_DISABLE_PCIE (see commit 9a4c0e220d8 for
On 5/12/2025 4:39 PM, Philippe Mathieu-Daudé wrote:
The X86MachineClass::save_tsc_khz boolean was only used
by the pc-q35-2.5 and pc-i440fx-2.5 machines, which got
removed. Remove it and simplify tsc_khz_needed().
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Daniel P. Berrangé
Reviewed-b
On 5/12/2025 4:39 PM, Philippe Mathieu-Daudé wrote:
The X86CPU::check_cpuid boolean was only set in the
pc_compat_2_4[] array, via the 'check=off' property.
We removed all machines using that array, lets remove
that CPU property and simplify x86_cpu_realizefn().
No.
We cannot do this. Because
On 5/12/2025 4:39 PM, Philippe Mathieu-Daudé wrote:
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.
R
On 5/12/2025 4:39 PM, Philippe Mathieu-Daudé wrote:
The hw_compat_2_5[] array was only used by the pc-q35-2.5 and
pc-i440fx-2.5 machines, which got removed. Remove it.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Daniel P. Berrangé
Reviewed-by: Zhao Liu
Reviewed-by: Xiaoyao Li
On 5/27/25 12:02, Gustavo Romero wrote:
Currently, test_aarch64_hotplug_pci only tests PCI hotplug using the
native PCI hotplug mechanism. Now that aarch64 supports PCI hotplug via
the ACPI mechanism it's time to support it in the test as well.
Signed-off-by: Gustavo Romero
---
tests/funct
On 5/12/2025 4:39 PM, Philippe Mathieu-Daudé wrote:
The hw_compat_2_4[] array was only used by the pc-q35-2.4 and
pc-i440fx-2.4 machines, which got removed. Remove it.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Daniel P. Berrangé
Reviewed-by: Zhao Liu
Reviewed-by: Xiaoyao Li
---
Hi Thomas,
On 5/27/25 12:11, Thomas Huth wrote:
On 27/05/2025 17.02, Gustavo Romero wrote:
Update SHA for 'linux' and 'initrd.gz' images.
Signed-off-by: Gustavo Romero
---
tests/functional/test_aarch64_hotplug_pci.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t
On 5/12/2025 4:39 PM, Philippe Mathieu-Daudé wrote:
The pc_compat_2_4[] array was only used by the pc-q35-2.4
and pc-i440fx-2.4 machines, which got removed. Remove it.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Daniel P. Berrangé
Reviewed-by: Zhao Liu
Reviewed-by: Xiaoyao Li
---
On 5/27/2025 7:20 PM, David Hildenbrand wrote:
> On 27.05.25 07:47, Chenyi Qiang wrote:
>>
>>
>> On 5/26/2025 5:08 PM, David Hildenbrand wrote:
>>> On 20.05.25 12:28, Chenyi Qiang wrote:
As guest_memfd is now managed by RamBlockAttribute with
RamDiscardManager, only block uncoordinated
On 5/12/2025 4:39 PM, Philippe Mathieu-Daudé wrote:
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.
R
On 5/12/2025 4:39 PM, Philippe Mathieu-Daudé wrote:
The PCMachineClass::broken_reserved_end field was only used
by the pc-q35-2.4 and pc-i440fx-2.4 machines, which got removed.
Remove it and simplify pc_memory_init().
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Daniel P. Berrangé
Review
Currently, test_aarch64_hotplug_pci only tests PCI hotplug using the
native PCI hotplug mechanism. Now that aarch64 supports PCI hotplug via
the ACPI mechanism it's time to support it in the test as well.
Signed-off-by: Gustavo Romero
---
tests/functional/test_aarch64_hotplug_pci.py | 24 +++
The current links for the Linux and initrd.gz images are not truly
immutable, so let's change them to point to immutable versions, to avoid
having to keep updating their SHAs.
Signed-off-by: Gustavo Romero
---
tests/functional/test_aarch64_hotplug_pci.py | 8
1 file changed, 4 insertion
> On 27 May 2025, at 16:52, Marc Zyngier wrote:
>
> On Tue, 27 May 2025 16:55:32 +0100,
> Miguel Luis wrote:
>>
>> Hi Marc,
>>
>>> On 27 May 2025, at 13:46, Marc Zyngier wrote:
>>>
>>> On Tue, 27 May 2025 14:24:31 +0100,
>>> Miguel Luis wrote:
> On 27 May 2025, at 12
On Tue, May 27, 2025 at 01:56:52PM -0700, Steve Sistare wrote:
> If vfio_realize fails after vfio_device_attach, it should call
> vfio_device_detach during error recovery. If it fails after
> vfio_device_get_name, it should free vbasedev->name. If it fails
> after vfio_pci_config_setup, it shoul
Now with 64bits, the offseting using start_time is not needed anymore,
because the array can always remember the whole timestamp.
Then drop the unused parameter in get_low_time_offset() altogether.
Signed-off-by: Peter Xu
---
migration/postcopy-ram.c | 10 --
1 file changed, 4 insertion
Currently, the postcopy blocktime feature maintains vCPU fault information
using an array (vcpu_addr[]). It has two issues.
Issue 1: Performance Concern
The old algorithm was almost OK and fast on inserts, except that the lookup
is slow and won't scale if there are a
Looking up the vCPU index for each fault can be expensive when there're
hundreds of vCPUs. Provide a cache for tid->vcpu instead with a hash
table, then lookup from there.
When at it, add another counter to record how many non-vCPU faults it gets.
For example, the main thread can also access a gu
Before this patch, the blocktime context can be created very early, because
postcopy_ram_supported_by_host() <- migrate_caps_check() can happen during
migration object init.
The trick here is the blocktime context needs system vCPU information,
which seems to be possible to change after that point
Add a field to count how many remote faults one vCPU has taken. So far
it's still not used, but will be soon.
Signed-off-by: Peter Xu
---
migration/postcopy-ram.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
index 5cbc7aa77e..46a8f
When used to report page fault latencies, the blocktime feature can be
almost useless when KVM async page fault is enabled, because in most cases
such remote fault will kickoff async page faults, then it's not trackable
from blocktime layer.
After all these recent rewrites to blocktime layer, it's
I am guessing it was used to be 32bits because of the atomic ops. Now all
the atomic ops are gone and we're protected by a mutex instead, it's ok we
can switch to 64 bits.
Reasons to move over:
- Allow further patches to change the unit from ms to us: with postcopy
preempt mode, we're really
Blocktime so far only cares about the time one vcpu (or the whole system)
got blocked. It would be also be helpful if it can also report the latency
of page requests, which could be very sensitive during postcopy.
Blocktime itself is sometimes not very important, especially when one
thinks about
This series is based on the other series I posted here:
Based-on: <20250527215850.1271072-1-pet...@redhat.com>
https://lore.kernel.org/r/20250527215850.1271072-1-pet...@redhat.com
Overview
This series almost rewrites the blocktime feature. It is a postcopy
feature which can track how l
The postcopy blocktime feature was tricky that it used quite some atomic
operations over quite a few arrays and vars, without explaining how that
would be thread safe. The thread safety here is about concurrency between
the fault thread and the fault resolution threads, possible to access the
same
Add a global property to allow enabling postcopy-blocktime feature.
Signed-off-by: Peter Xu
---
migration/options.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/migration/options.c b/migration/options.c
index 162c72cda4..4e923a2e07 100644
--- a/migration/options.c
+++ b/migration/option
The variable vcpu_total_blocktime isn't easy to follow. In reality, it
wants to capture the case where all vCPUs are stopped, and now there will
be some vCPUs starts running.
The name now starts to conflict with vcpu_blocktime_total[], meanwhile it's
actually not necessary to have the variable at
Now with the mutex protection it's not needed anymore.
Signed-off-by: Peter Xu
---
migration/postcopy-ram.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
index 9db3eefec4..0b4efdb7fe 100644
--- a/
With 64-bit fields, it is trivial. The caution is when exposing any values
in QMP, it was still declared with milliseconds (ms). Hence it's needed to
do the convertion when exporting the values to existing QMP queries.
Signed-off-by: Peter Xu
---
migration/postcopy-ram.c | 26 ++---
On 5/27/2025 10:42 AM, Paolo Bonzini wrote:
On 5/8/25 21:57, Babu Moger wrote:
Following changes are implemented in this series.
1. Fixed the cache(L2,L3) property details in all the EPYC models.
2. Add RAS feature bits (SUCCOR, McaOverflowRecov) on all EPYC models
3. Add missing SVM featur
The series is based on a small patch from Yanfei Xu here:
Based-on: <20250514115827.3216082-1-yanfei...@bytedance.com>
https://lore.kernel.org/r/20250514115827.3216082-1-yanfei...@bytedance.com
This is a series that collected many of either enhancements or cleanups I
got for QEMU 10.1, which almo
Markus Armbruster writes:
> Fabiano Rosas writes:
>
>> Add the QMP commands query-migrate-config and migrate-set-config to
>> read and write the migration configuration options.
>
> These supersede query-migrate-capabilities, query-migrate-parameters,
> migrate-set-capabilities, and migrate-set-
On Tue, Apr 29, 2025 at 01:31:44PM +0200, Markus Armbruster wrote:
> > In the context of qemu that might suggest having separate
> > multi_conn_requested and multi_conn fields, where the latter can be
> > queried over QMP to find out what is actually going on. Could even
> > add multi_conn_max to
Unfortunately, it was never correctly shown..
This is only found when I started to look into making the blocktime feature
more useful (so as to avoid using bpftrace, even though I'm not sure which
one will be harder to use..).
So the old dump would look like this:
Postcopy vCPU Blocktime: 0-1,
Dave suggested the HMP output for "info migrate" can not only leverage the
lines but also better grouping:
https://lore.kernel.org/r/aC4_-nMc7FwsMf9p@gallifrey
I followed Dave's suggestion, and some more modifications on top:
- Added all elements into the picture
- Use size_to_str() and d
Since we use the same save_complete() hook for both precopy and postcopy,
add a set of helpers to invoke the hook() to dedup the code.
Signed-off-by: Peter Xu
---
migration/savevm.c | 78 ++
1 file changed, 44 insertions(+), 34 deletions(-)
diff --git
Now after merging the precopy and postcopy version of complete() hook,
rename the precopy version from save_live_complete_precopy() to
save_complete().
Dropping the "live" when at it, because it's in most cases not live when
happening (in precopy).
No functional change intended.
Signed-off-by: P
The check over PAGE_DIRTY_FOUND isn't necessary. We could indent one less
and assert that instead.
Signed-off-by: Peter Xu
---
migration/ram.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/migration/ram.c b/migration/ram.c
index ed380ac86f..c66ad3cf8b
This is a follow up on the other commit "migration/ram: avoid to do log
clear in the last round" but for postcopy.
https://lore.kernel.org/r/20250514115827.3216082-1-yanfei...@bytedance.com
I can observe more than 10% reduction of average page fault latency during
postcopy phase with this optimiz
There're a few things off here in that logic, rewrite it. When at it, add
rich comment to explain each of the decisions.
Since this is very sensitive path for migration, below are the list of
things changed with their reasonings.
(1) Exact pending size is only needed for precopy not postcopy
Move it out of vanilla postcopy session, but instead a standalone feature.
When at it, removing the NOTE because it's incorrect now after introduction
of max-postcopy-bandwidth, which can control the throughput even for
postcopy phase.
Signed-off-by: Peter Xu
---
docs/devel/migration/postcopy.rs
The hook is only defined in two vmstate users ("ram" and "block dirty
bitmap"), meanwhile both of them define the hook exactly the same as the
precopy version. Hence, this postcopy version isn't needed.
No functional change intended.
Signed-off-by: Peter Xu
---
include/migration/register.h |
Take notes on start/end state of dirty pages for the whole system.
Signed-off-by: Peter Xu
---
migration/ram.c| 5 +
migration/trace-events | 1 +
2 files changed, 6 insertions(+)
diff --git a/migration/ram.c b/migration/ram.c
index c66ad3cf8b..a1d0e8ada2 100644
--- a/migration/ram.
It's not possible to happen in bg-snapshot case.
Signed-off-by: Peter Xu
---
migration/migration.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/migration/migration.c b/migration/migration.c
index 4697732bef..7bd78dd524 100644
--- a/migration/migration.c
+++ b/migratio
The following changes since commit 80db93b2b88f9b3ed8927ae7ac74ca30e643a83e:
Merge tag 'pull-aspeed-20250526' of https://github.com/legoater/qemu into
staging (2025-05-26 10:16:59 -0400)
are available in the Git repository at:
https://github.com/mcayland/qemu.git tags/qemu-spar
From: Clément Chigot
FSR_NVA should be set when one of the operands is a signaling NaN or
when using FCMPEx instructions. But those cases are already handled
within check_ieee_exception or floatxx_compare functions.
Otherwise, it should be left untouched.
FTR, this was detected by inf-compare-[5
On Tue, 27 May 2025 09:40:11 +0200
Eric Auger wrote:
> gpex build_host_bridge_osc() and x86 originated
> build_pci_host_bridge_osc_method() are mostly identical.
>
> In GPEX, SUPP is set to CDW2 but is not further used. CTRL
> is same as Local0.
>
> So let gpex code reuse build_pci_host_bridge_
Hi Hikalium,
I am wondering if you had a chance to take a look at this - DPI upscaling case?
> Subject: RE: Some regression due to "ui/gtk: Fix mouse/motion event scaling
> issue with GTK display backend"
>
> Hi Hikalium,
>
> One easy way to observe the problem is to try to boot ubuntu image
>
If vfio_realize fails after vfio_device_attach, it should call
vfio_device_detach during error recovery. If it fails after
vfio_device_get_name, it should free vbasedev->name. If it fails
after vfio_pci_config_setup, it should free vdev->msix.
To fix all, call vfio_pci_put_device().
Signed-off-
On Tue, May 27, 2025 at 04:42:16PM -0400, Steven Sistare wrote:
>
>
> On 5/24/2025 5:34 AM, Michael S. Tsirkin wrote:
> > On Fri, May 16, 2025 at 10:19:09AM +0200, Cédric Le Goater wrote:
> > > On 5/12/25 17:32, Steve Sistare wrote:
> > > > Do not reset a vfio-pci device during CPR.
> > > >
> >
On 5/12/25 6:06 PM, Daniel Borkmann wrote:
> Extend 'inhibit=on' setting with the option to specify a pinned XSK map
> path along with a starting index (default 0) to push the created XSK
> sockets into. Example usage:
>
> # ./build/qemu-system-x86_64 [...] \
>-netdev
> af-xdp,ifname=enp2s0
On 5/24/25 7:40 AM, Richard Henderson wrote:
When we moved TLB_MMIO and TLB_DISCARD_WRITE to TLB_SLOW_FLAGS_MASK,
we failed to update atomic_mmu_lookup to properly reconstruct flags.
Fixes: 24b5e0fdb543 ("include/exec: Move TLB_MMIO, TLB_DISCARD_WRITE to slow
flags")
Reported-by: Jonathan Camer
On 5/24/25 7:40 AM, Richard Henderson wrote:
When we moved TLB_MMIO and TLB_DISCARD_WRITE to TLB_SLOW_FLAGS_MASK,
we failed to update atomic_mmu_lookup to properly reconstruct flags.
Fixes: 24b5e0fdb543 ("include/exec: Move TLB_MMIO, TLB_DISCARD_WRITE to slow
flags")
Reported-by: Jonathan Camer
On 5/24/2025 5:34 AM, Michael S. Tsirkin wrote:
On Fri, May 16, 2025 at 10:19:09AM +0200, Cédric Le Goater wrote:
On 5/12/25 17:32, Steve Sistare wrote:
Do not reset a vfio-pci device during CPR.
Signed-off-by: Steve Sistare
---
hw/pci/pci.c | 13 +
1 file changed, 13 inse
On 27/05/2025 18:19, Paolo Bonzini wrote:
On 5/26/25 16:20, Philippe Mathieu-Daudé wrote:
On 26/5/25 15:18, BALATON Zoltan wrote:
On Mon, 26 May 2025, Philippe Mathieu-Daudé wrote:
Only add default devices checking defaults_enabled().
Remove the unused usb_disabled field in MachineState.
At
Hi Eric,
On 5/27/25 04:18, Eric Auger wrote:
On 5/21/25 10:19 PM, Gustavo Romero wrote:
Hi Eric,
On 5/21/25 13:24, Gustavo Romero wrote:
Hi Eric,
On 5/21/25 12:56, Eric Auger wrote:
Hi Gustavo,
On 5/21/25 5:26 PM, Gustavo Romero wrote:
Hi Eric,
On 5/14/25 14:01, Eric Auger wrote:
Move
On 25/04/2025 10:35, Clément Chigot wrote:
FSR_NVA should be set when one of the operands is a signaling NaN or
when using FCMPEx instructions. But those cases are already handled
within check_ieee_exception or floatxx_compare functions.
Otherwise, it should be left untouched.
FTR, this was det
On Thu, 22 May 2025 23:16:36 +0800
Tomita Moeko wrote:
> In vfio_pci_igd_opregion_detect(), errp will be set when the device does
> not have OpRegion or is hotplugged. This errp will be propagated to
> pci_qdev_realize(), which interprets it as failure, causing unexpected
> termination on devices
From e2f3eab60e9b9787c5c8f87bea5d1bd7079d982e Mon Sep 17 00:00:00 2001
From: Elisey
Date: Tue, 27 May 2025 17:17:35 +0300
Subject: [PATCH] Revert "i386/cpu: Set up CPUID_HT in x86_cpu_expand_features()
instead of cpu_x86_cpuid()"
This reverts commit c6bd2dd634208ca717b6dc010064fe34d1359080.
The
This reverts commit c6bd2dd634208ca717b6dc010064fe34d1359080.
---
target/i386/cpu.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 9689f6374e..c648a1cf04 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -6859
On 5/27/25 13:44, Gustavo Romero wrote:
Hi folks,
On 5/27/25 12:56, Igor Mammedov wrote:
On Tue, 27 May 2025 09:40:24 +0200
Eric Auger wrote:
Set up the IO registers used to communicate between QEMU
and ACPI.
Move the create_pcie() call after the creation of the acpi
ged device since
Doctests are weird. They are essentially integration tests, but they're
"ran" by executing rustdoc --test, which takes a compiler-ish
command line. This is supported by Meson 1.8.0.
Because they run the linker and need all the .o files, run them in the
build jobs rather than the test jobs.
Sign
Pierrick Bouvier writes:
> This series exposes all qmp commands for any target unconditionally, allowing
> to
> compile QAPI generated code without any TARGET conditionals.
>
> Based on original RFC from Daniel P. Berrangé:
> https://lore.kernel.org/qemu-devel/20250508135816.673087-1-berra...@re
On Sat, 24 May 2025 23:31:02 +0800
Tomita Moeko wrote:
> Introduce x-pci-class-code option to allow users to override PCI class
> code of a device, similar to the existing x-pci-vendor-id option. Only
> the lower 24 bits of this option are used, though a uint32 is used here
> for determining whet
On Wed, May 21, 2025 at 5:18 PM Juraj Marcin wrote:
>
> From: Juraj Marcin
>
> If a virtual machine is paused for an extended period time, for example,
> due to an incoming migration, there are also no changes on the screen.
> VNC in such case increases the display update interval by
> VNC_REFRES
Am 26.05.2025 um 15:21 hat Fiona Ebner geschrieben:
> The quorum_del_child() callback runs under the graph lock, so it is
> not allowed to drain. It is only called as the .bdrv_del_child()
> callback, which is only called in the bdrv_del_child() function, which
> also runs under the graph lock.
>
1 - 100 of 312 matches
Mail list logo
