Hi Igor,
Thanks for the email and reminding the points we discussed last year. I'm
mostly in
sync with what you've mentioned. Please find my replies inline for more details.
Best regards
Salil.
> From: Igor Mammedov
> Sent: Thursday, May 22, 2025 1:40 PM
> To: Gustavo Romero
> Cc: Gavin Shan
HI Gavin,
> -Original Message-
> From: Gavin Shan
> Sent: Thursday, May 22, 2025 12:54 AM
> To: Gustavo Romero ; Salil Mehta
> ; qemu-devel@nongnu.org; qemu-
> a...@nongnu.org; m...@redhat.com; Jonathan Cameron
> ; Igor Mammedov
> ; Eric Auger
[..]
>
> Hi Gustavo and Salil,
>
> On 5/
Hi Gustavo,
> From: Gustavo Romero
> Sent: Wednesday, May 21, 2025 4:07 PM
> To: Gavin Shan ; Salil Mehta
> ; qemu-devel@nongnu.org; qemu-
> a...@nongnu.org; m...@redhat.com; Jonathan Cameron
> ; Igor Mammedov
> ; Eric Auger
[...]
>
> Hi Salil, Gavin, and folks,
>
> On 5/20/25 21:22, Gavin S
Hi Gavin,
Thanks for your email and sorry for the delay in reply as I was in transit and
on
annual leave since Monday.
Please check my replies inline.
Best regards
Salil
> From: Gavin Shan
> Sent: Wednesday, May 21, 2025 1:22 AM
> To: Salil Mehta ; qemu-devel@nongnu.org;
> qemu-...@nongnu.or
Checking `is_present` first can break x86 migration from new Qemu
version to old Qemu. This is because CPRS Bit is not defined in the
older Qemu register block and will always be 0 resulting in check always
failing. Remove CPU_PRESENT Bit to preserve older ABI.
-If ((\_SB.PCI0.PRES
Update the DSDT golden master files for the x86/pc and x86/q35 platforms
to address recent changes in the architecture-agnostic CPU AML code,
which impacted the backward compatibility of the migration feature on
the x86 platform. Additionally, initialize CPU's presence statically
within the CPU AML
list changed files in tests/qtest/bios-tables-test-allowed-diff.h
Suggested-by: Igor Mammedov
Message-ID: <20241106100047.18901...@imammedo.users.ipa.redhat.com>
Signed-off-by: Salil Mehta
---
tests/qtest/bios-tables-test-allowed-diff.h | 41 +
1 file changed, 41 insertions(
Fixes the the CPUs AML code and its corresponding golden masters ACPI
tables files for backward compatability of live migration on x86 platforms
i.e. when newer Qemu is migrated to older Qemu without `CPRS` Bit present
in the register block. This also reverts the ACPI ABI change introduced for
chec
Hi Igor,
Many thanks for taking time to reply.
> From: qemu-arm-bounces+salil.mehta=huawei@nongnu.org arm-bounces+salil.mehta=huawei@nongnu.org> On Behalf Of Igor
> Mammedov
> Sent: Thursday, November 7, 2024 4:57 PM
> To: Salil Mehta
>
> On Wed, 6 Nov 2024 19:05:15 +
> Sal
Hi Igor,
Thanks for replying back and the reviews. Please find my replies
inline.
> From: Igor Mammedov
> Sent: Wednesday, November 6, 2024 4:08 PM
> To: Salil Mehta
>
> On Wed, 6 Nov 2024 14:45:42 +
> Salil Mehta wrote:
>
> > Hi Igor,
> >
> > > From: qemu-arm-bounces+salil.me
Fixes the the CPUs AML code and its corresponding golden masters ACPI
tables files for backward compatability of live migration on x86 platforms
i.e. when newer Qemu is migrated to older Qemu without `CPRS` Bit present
in the register block.
Fixes [PULL 60/65], [PULL 61/65]:
Message-ID:
Message-
Update DSDT golden master files for x86/pc and x86/q35 platforms to fix
the earlier changes made in the architecture-agnostic CPU AML. These
updates notify the guest OS of vCPU hot-plug and hot-unplug status using
the ACPI `_STA.Enabled` bit. Earlier order of checking `presence` and
`enabled` broke
list changed files in tests/qtest/bios-tables-test-allowed-diff.h
Suggested-by: Igor Mammedov
Message-ID: <20241106100047.18901...@imammedo.users.ipa.redhat.com>
Signed-off-by: Salil Mehta
---
tests/qtest/bios-tables-test-allowed-diff.h | 41 +
1 file changed, 41 insertions(
Hi Igor,
> From: qemu-arm-bounces+salil.mehta=huawei@nongnu.org arm-bounces+salil.mehta=huawei@nongnu.org> On Behalf Of Igor
> Mammedov
> Sent: Wednesday, November 6, 2024 1:57 PM
> To: Salil Mehta
>
> On Wed, 6 Nov 2024 13:03:30 +
> Salil Mehta wrote:
>
> > Checking `is
Checking `is_present` first can break x86 migration from new Qemu
version to old Qemu. This is because CPRS Bit is not defined in the
older Qemu register block and will always be 0 resulting in check always
failing. Reversing the logic to first check `is_enabled` can alleviate
below problem:
-
HI Igor,
Thank for you replying back.
> From: qemu-devel-bounces+salil.mehta=huawei@nongnu.org devel-bounces+salil.mehta=huawei@nongnu.org> On Behalf Of Igor
> Mammedov
> Sent: Wednesday, November 6, 2024 9:01 AM
> To: Salil Mehta
>
> On Tue, 5 Nov 2024 21:12:00 +
> Salil M
HI Peter,
> From: Peter Maydell
> Sent: Wednesday, November 6, 2024 1:01 PM
> To: Salil Mehta
>
> On Tue, 5 Nov 2024 at 22:20, Salil Mehta wrote:
> >
> > HI Peter,
> >
> > > From: Peter Maydell
> > > Sent: Monday, November 4, 2024 1:27 PM
> > > To: Salil Mehta
> > >
> > > On
HI Peter,
> From: Peter Maydell
> Sent: Monday, November 4, 2024 1:27 PM
> To: Salil Mehta
>
> On Sun, 3 Nov 2024 at 15:25, Salil Mehta wrote:
> >
> > Extract common GIC and CPU interrupt wiring code to improve code
> > readability and modularity, supporting reuse in future patch sets.
Hi Gavin,
Thanks for the valuable comments. I will address them but it looks peter has
already
pulled ARM changes for this cycle?
Thanks
Salil.
> From: Gavin Shan
> Sent: Tuesday, November 5, 2024 12:01 AM
> To: Salil Mehta ; qemu-devel@nongnu.org;
> qemu-...@nongnu.org; m...@redhat.com; r
> From: Igor Mammedov
> Sent: Tuesday, November 5, 2024 12:50 PM
> To: Michael S. Tsirkin
> Cc: qemu-devel@nongnu.org; Peter Maydell ;
> Salil Mehta ; Ani Sinha ;
> Eduardo Habkost ; Marcel Apfelbaum
> ; Philippe Mathieu-Daudé
> ; wangyanan (Y) ; Zhao
> Liu
> Subject: Re: [PULL 60/65]
HI Miguel,
> From: Miguel Luis
> Sent: Monday, November 4, 2024 12:55 PM
> To: Salil Mehta
>
> Hi Salil,
>
> > On 3 Nov 2024, at 09:24, Salil Mehta via
> wrote:
> >
> > Change Log
> > ==
> >
> > Patch V2 -> V3:
Hi Igor,
I've fixed most of the x86 problems you had commented in the V1 patch-set in the
recently floated V3 ACPI patch-set. This includes removing the
`is_{enabled,present}`
ACPI CPU States for which you expressed apprehensions. Sorry, there was a miss
from my side in the V2 related to the CPU
Extract common GIC and CPU interrupt wiring code to improve code
readability and modularity, supporting reuse in future patch sets. This
refactor is benign and introduces *no* functional changes.
Note: This patch has been isolated from a larger patch set to facilitate
early merging and reduce the
Refactor GICv3 code for TCG and KVM to initialize the GIC CPU interface
register information by introducing a new common hook
`ARMGICv3CommonClass::init_cpu_reginfo`. This hook can be assigned to
the respective TCG or KVM variants during the GICv3 initialization
phase and invoked during the GICv3 r
Refactor vCPU properties code from the `machvirt_init()` main loop with
the following goals:
1. Enable code reuse in future patch sets.
2. Improve code readability.
3. Separate out the one-time initialization of (secure-)Tagged memory,
handling potential failures early.
Note: This is a cosmeti
Hello,
Please ignore this patch-set as there was some issue w.r.t x86. Details are in
the V3 patch-set sent for review today. V3 has fixed almost all of the issues
identified by Igor in the V1 patch-set in relation to x86.
Please have a look at the below V3 patch-set:
[PATCH V3 0/5] Arch agnost
list changed files in tests/qtest/bios-tables-test-allowed-diff.h
Reported-by: Zhao Liu
Signed-off-by: Salil Mehta
---
tests/qtest/bios-tables-test-allowed-diff.h | 41 +
1 file changed, 41 insertions(+)
diff --git a/tests/qtest/bios-tables-test-allowed-diff.h
b/tests/qtes
The ACPI CPU hotplug states must be migrated along with other vCPU
hotplug states to the destination VM. Update the GED's VM State
Description (VMSD) table subsection to conditionally include the CPU
Hotplug VM State Description (VMSD).
Excerpt of GED VMSD State Dump at Source:
"acpi-ged (16)
On most architectures, during vCPU hot-plug and hot-unplug actions, the
firmware or VMM/QEMU can update the OS on vCPU status by toggling the
ACPI method `_STA.Present` bit. However, certain CPU architectures
prohibit [1] modifications to a CPU’s `presence` status after the kernel
has booted.
This
Update DSDT golden master files for x86/pc and x86/q35 platforms to
accommodate changes made in the architecture-agnostic CPU AML. These
updates notify the guest OS of vCPU hot-plug and hot-unplug status
using the ACPI `_STA.Enabled` bit.
The following is a diff of the changes in the .dsl file gen
Reflect the QOM vCPUs ACPI CPU hotplug states in the `_STA.Present` and
and `_STA.Enabled` bits when the guest kernel evaluates the ACPI
`_STA` method during initialization, as well as when vCPUs are
hot-plugged or hot-unplugged. If the CPU is present then the its
`enabled` status can be fetched us
Change Log
==
Patch V2 -> V3:
1. Addressed left over issues of x86 suggested by Igor Mammedov (Redhat):
- Removed the `ACPICPUstatus::is_enabled` State as well as it was
breaking the x86 migration
- Above is in addition to `is_present` state which was removed in V2
- Dropped
Hi Igor,
Thanks for replying back and sorry for the late reply. I wanted to make sure
that I've addressed your comments internally and I've at-least one solution
fully tested and working with adjusted main series (upcoming RFC V6) after
addressing your major comments. I'm further open to your sugg
The ACPI CPU hotplug state `is_enabled` must be migrated along with
other vCPU hotplug states to the destination VM. Update the GED's VM
State Description (VMSD) table subsection to include the CPU Hotplug
VM State Description (VMSD).
Question: How to stop `is_enabled` state being migrated in case
Update DSDT golden master files for x86/pc and x86/q35 platforms to accommodate
changes made in the architecture-agnostic CPU AML. These updates notify the
guest OS of vCPU hot-plug and hot-unplug status using the ACPI `_STA.Enabled`
bit.
The following is a diff of the changes in the .dsl file gen
list changed files in tests/qtest/bios-tables-test-allowed-diff.h
Reported-by: Zhao Liu
Signed-off-by: Salil Mehta
---
tests/qtest/bios-tables-test-allowed-diff.h | 41 +
1 file changed, 41 insertions(+)
diff --git a/tests/qtest/bios-tables-test-allowed-diff.h
b/tests/qtes
Update the CPUs AML code to reflect the ACPI CPU Hotplug `is_enabled`
state in the `_STA.Enabled` Bit when the ACPI `_STA` method is evaluated
by the Guest Kernel during initialization, as well as when vCPUs are
hot-plugged or hot-unplugged.
Signed-off-by: Salil Mehta
Reviewed-by: Gustavo Romero
Update the `is_enabled` state in `AcpiCpuStatus` when vCPUs are
hot-plugged or hot-unplugged.
Signed-off-by: Salil Mehta
Reviewed-by: Gustavo Romero
---
hw/acpi/cpu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/acpi/cpu.c b/hw/acpi/cpu.c
index 238a0edbc1..8940687f90 100644
--- a/hw
On most architectures, during vCPU hot-plug and hot-unplug actions,
firmware or the VMM/QEMU can convey vCPU status to the OS by
toggling the ACPI method `_STA.Present` Bit. However, certain CPU
architecture specifications prohibit [1] modifications to CPU's
`presence` after the kernel has booted.
Change Log
==
Patch V1 -> V2:
1. Addressed Igor Mammedov's (Redhat) raised issues:
- Removed `ACPICPUstatus::is_present` State and its handling in the
ACPI APUs AML code and now all QOM vCPUs are present.
- Dropped the concept of `acpi_persistent` because now QOM vCPUs
stat
Hi Igor,
Thanks for taking time to review the series. Please find my replies inline.
> From: qemu-devel-bounces+salil.mehta=huawei@nongnu.org devel-bounces+salil.mehta=huawei@nongnu.org> On Behalf Of Igor
> Mammedov
> Sent: Friday, October 18, 2024 3:46 PM
> To: Salil Mehta
>
>
Hi Gustavo,
> From: Gustavo Romero
> Sent: Monday, October 21, 2024 3:10 AM
> To: Salil Mehta ; qemu-devel@nongnu.org;
> qemu-...@nongnu.org; m...@redhat.com
>
> Hi Salil,
>
> On 10/14/24 16:22, Salil Mehta wrote:
> > Reflect the ACPI CPU hotplug `is_{present, enabled}` states in the
>
Hi Igor,
> From: Igor Mammedov
> Sent: Friday, October 18, 2024 3:25 PM
> To: Salil Mehta
> Cc: qemu-devel@nongnu.org; qemu-...@nongnu.org; m...@redhat.com;
> m...@kernel.org; jean-phili...@linaro.org; Jonathan Cameron
> ; lpieral...@kernel.org;
> peter.mayd...@linaro.org; richard.hender.
> From: Igor Mammedov
> Sent: Friday, October 18, 2024 3:19 PM
> To: Zhao Liu
> Cc: Salil Mehta ; qemu-devel@nongnu.org;
> qemu-...@nongnu.org; m...@redhat.com; m...@kernel.org; jean-
> phili...@linaro.org; Jonathan Cameron
> ; lpieral...@kernel.org;
> peter.mayd...@linaro.org; richard.h
Hi Zhao,
Sorry, for the late reply. I was away last week with only intermittent access
to the mails.
> From: Zhao Liu
> Sent: Friday, October 18, 2024 6:13 AM
> To: Salil Mehta
>
> Hi Salil,
>
> On Mon, Oct 14, 2024 at 08:22:04PM +0100, Salil Mehta wrote:
> > Date: Mon, 14 Oct 2024 20
Hi Igor,
> From: Igor Mammedov
> Sent: Friday, October 18, 2024 3:31 PM
> To: Salil Mehta
>
> On Mon, 14 Oct 2024 20:22:05 +0100
> Salil Mehta wrote:
>
> > The ACPI CPU hotplug states `is_{present, enabled}` must be migrated
> > alongside other vCPU hotplug states to the destination
Hi Igor,
> From: Igor Mammedov
> Sent: Friday, October 18, 2024 3:18 PM
> To: Salil Mehta
>
> On Mon, 14 Oct 2024 20:22:03 +0100
> Salil Mehta wrote:
>
> > Update the `AcpiCpuStatus` for `is_enabled` and `is_present`
> > accordingly when vCPUs are hot-plugged or hot-unplugged, taking
Hi Igor,
> From: Igor Mammedov
> Sent: Tuesday, October 15, 2024 3:34 PM
> To: Salil Mehta
>
> On Tue, 15 Oct 2024 09:41:24 +
> Salil Mehta wrote:
>
> > HI Igor,
> >
> > > From: Igor Mammedov
> > > Sent: Tuesday, October 15, 2024 10:31 AM
> > > To: Salil Mehta
> > > Cc:
alil.
>
> Regards
> Bibo Mao
>
> On 2024/10/15 上午3:22, Salil Mehta via wrote:
> > Certain CPU architecture specifications [1][2][3] prohibit changes to
> > the CPUs
> > *presence* after the kernel has booted. This is because many system
> > initializ
Hotpluggable vCPUs must be exposed as "online-capable" according to the new UEFI
specification [1][2]. However, marking cold-booted vCPUs as "online-capable"
during boot may cause them to go undetected by legacy operating systems,
potentially leading to compatibility issues. Hence, both 'online-cap
vCPU reset can result in device access to VGIC CPU system registers using the
`IOCTL KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS` interface. When accessing these
registers in the KVM host, it is necessary to acquire a lock on all vCPUs during
the `vgic_v3_attr_regs_access()` operation.
This operation may fai
The QOM `GICv3CPUState` (and consequently the corresponding KVM VGIC `ICC_*_EL1`
registers) can be either 'accessible' or 'inaccessible', depending on the state
of the associated QOM vCPUs. This `gicc_accessible` state should be saved during
migration at the source and restored at the destination.
From: Jean-Philippe Brucker
Previously, all `PSCI_CPU_{ON, OFF}` calls were handled directly by KVM.
However, with the introduction of vCPU hotplug, these hypervisor calls are now
trapped to QEMU for policy checks. This shift can lead to inconsistent vCPU
states between KVM and QEMU, particularly
From: Author Salil Mehta
To support vCPU hotplug, we must trap any `HVC`/`SMC` `PSCI_CPU_{ON,OFF}`
hypercalls from the host KVM to QEMU for policy checks. This ensures the
following when a vCPU is brought online:
1. The vCPU is actually plugged in (i.e., present).
2. The vCPU is not disabled.
I
From: Miguel Luis
Introduce the TCG thread unregistration leg which shall be called in context to
TCG/vCPU unrealize.
Reported-by: Salil Mehta
Signed-off-by: Miguel Luis
Signed-off-by: Salil Mehta
---
accel/tcg/tcg-accel-ops-mttcg.c | 1 +
include/tcg/startup.h | 7 +++
tcg/t
vCPU Hot-unplug will result in QOM CPU object unrealization which will do away
with all the vCPU thread creations, allocations, registrations that happened
as part of the realization process. This change introduces the ARM CPU unrealize
function taking care of exactly that.
Note, initialized KVM v
Updates the firmware config with the next boot cpus information and also
registers the reset callback to be called when guest reboots to reset the cpu.
Co-developed-by: Keqian Zhu
Signed-off-by: Keqian Zhu
Signed-off-by: Salil Mehta
---
hw/arm/boot.c | 2 +-
hw/arm/virt.c | 18
The TCG code cache consists of multiple regions shared among vCPUs in
multi-threaded TCG mode. For cold-plugged vCPUs, these regions are sized and
allocated during initialization in the `tcg_register_thread()` function when the
vCPUs are realized. Later, these regions must be reallocated for hot-pl
The ARM extensions configuration *must* match the existing vCPUs already
initialized in KVM at VM initialization. ARM does not allow any per-vCPU
features to be changed once the system has fully initialized. This is an
immutable constraint of the ARM CPU architecture.
Signed-off-by: Salil Mehta
-
During any vCPU hot-(un)plug operation, the running guest VM must be notified
about the addition of a new vCPU or the removal of an existing vCPU. This
notification is handled via an ACPI GED event, which is eventually demultiplexed
into a vCPU hotplug event, and then further into a specific hot-(u
Virtual CPU hot-(un)plug events must be communicated to the GIC. Introduce a
notification mechanism to ensure these events are properly relayed to the GIC,
allowing it to update the accessibility of the GIC CPU interface and adjust the
vCPU-to-GIC CPU interface association accordingly.
This approa
Refactors the existing GIC create code to extract common code to wire the
vcpu<->gic interrupts. This function could be used with cold-plug case and also
used when vCPU is hot-plugged. It also introduces a new function to unwire the
vcpu<->gic interrupts for the vCPU hot-unplug cases.
Co-developed
Add CPU hot-unplug hooks and update hotplug hooks with additional sanity checks
for use in hotplug paths.
Note: The functional contents of the hooks (currently left with TODO comments)
will be gradually filled in subsequent patches in an incremental approach to
patch and logic building, which woul
The ARM CPU architecture does not permit changes to CPU presence after the
kernel has booted. This is an immutable requirement from ARM and represents a
strict architectural constraint [1][2].
The ACPI update [3] reinforces this by specifying that the `_STA.Present` bit
in the ACPI specification c
When QEMU builds the MADT table, modifications are needed to include information
about possible vCPUs that are exposed as ACPI-disabled (i.e., `_STA.Enabled=0`).
This new information will help the guest kernel pre-size its resources during
boot time. Pre-sizing based on possible vCPUs will facilita
Support for Virtual CPU Hotplug requires a sequence of ACPI handshakes between
QEMU and the guest kernel when a vCPU is plugged or unplugged. Most of the AML
code to support these handshakes already exists. This AML needs to be built
during VM initialization for the ARM architecture as well, if GED
From: Jean-Philippe Brucker
The GICC interface on arm64 vCPUs is statically defined in the MADT, and
doesn't require a _MAT entry. Although the GICC is indicated as present
by the MADT entry, it can only be used from vCPU sysregs, which aren't
accessible until hot-add.
Signed-off-by: Jean-Philip
During `machvirt_init()`, QOM ARMCPU objects are pre-created along with the
corresponding KVM vCPUs in the host for all possible vCPUs. This is necessary
due to the architectural constraint that KVM restricts the deferred creation of
KVM vCPUs and VGIC initialization/sizing after VM initialization.
The PMU for all possible vCPUs must be initialized during VM initialization.
Refactor the existing code to accommodate possible vCPUs. This assumes that all
processors being used are identical. It is an architectural constraint of ARM
CPUs that all vCPUs MUST have identical feature sets, at least u
During GED device creation at Virt Machine initialization, add a new vCPU
hotplug event to the existing set of supported GED device events. Additionally,
initialize the memory map for the vCPU hotplug *control device*, which will
provide an interface to exchange ACPI events between QEMU/VMM and the
ACPI is required to interface QEMU with the guest. Roughly falls into below
cases,
1. Convey the possible vCPUs config at the machine init time to the guest
using various DSDT tables like MADT etc.
2. Convey vCPU hotplug events to guest(using GED)
3. Assist in evaluation of various ACPI methods
The GICv3 CPU interface must be (re)initialized when a vCPU is either cold- or
hot-plugged. System registers need to be defined and registered with the
associated vCPU. For cold-plugged vCPUs, this occurs during the GICv3
realization phase, while for hot-plugged vCPUs, it happens during the GICv3
u
ARM CPU architecture does not allows CPU to be plugged after system has
initialized. This is an constraint. Hence, Kernel must know all the CPUs being
booted during its initialization. This applies to the Guest Kernel as well and
therefore, number of KVM vCPUs need to be fixed at the VM initializat
Introduce a `gicc_accessible` flag to indicate whether it is safe to access the
GICv3 CPU interface. This flag will determine the availability of the GICv3 CPU
interface based on whether the associated QOM vCPUs are enabled or disabled.
Additionally, implement checks throughout the GICv3 codebase
The GIC must be pre-sized with the possible vCPUs during initialization. This is
essential because:
1. Memory regions and resources associated with GICC/GICR cannot be modified
(i.e., added, deleted, or changed) once the VM has been initialized.
2. Additionally, the `GIC_TYPER` must be initiali
Introduce the common logic required during the initialization of both cold and
hot-plugged vCPUs. Additionally, initialize the *disabled* state of the vCPUs,
which will be used further during the initialization phases of various other
components like GIC, PMU, ACPI, etc., as part of the virtual mac
This shall be used to store user specified topology{socket,cluster,core,thread}
and shall be converted to a unique 'vcpu-id' which is used as slot-index during
hot(un)plug of vCPU.
Co-developed-by: Keqian Zhu
Signed-off-by: Keqian Zhu
Signed-off-by: Salil Mehta
---
hw/arm/virt.c | 10 +
PROLOGUE
To assist in review and set the right expectations from this RFC, please first
read the sections *APPENDED AT THE END* of this cover letter:
1. Important *DISCLAIMER* [Section (X)]
2. Work presented at KVMForum Conference (slides available) [Section (V)F]
3. Organization of patc
Factor out vCPU properties code common for {hot,cold}-plugged vCPUs in the
machvirt_init(). This allows code reuse.
Signed-off-by: Salil Mehta
---
hw/arm/virt.c | 219 ++
include/hw/arm/virt.h | 4 +
2 files changed, 139 insertions(+), 84 deletio
For unsupported acceleration types and GIC versions, explicitly disable vCPU
hotplug support and limit the number of possible vCPUs to those available at
boot time (i.e., SMP CPUs). This flag will be referenced at various points in
the code to verify the presence of vCPU hotplug functionality on th
HI Igor,
> From: Igor Mammedov
> Sent: Tuesday, October 15, 2024 10:31 AM
> To: Salil Mehta
> Cc: maobibo ; qemu-devel@nongnu.org; Michael
> S. Tsirkin ; Peter Maydell ;
> zhukeqian ; Jonathan Cameron
> ; Gavin Shan ;
> Vishnu Pajjuri ; Xianglai Li
> ; Miguel Luis ; Shaoqin
> Huang ; Z
Hi Bibo,
> From: maobibo
> Sent: Tuesday, October 15, 2024 2:20 AM
> To: Salil Mehta ; qemu-devel@nongnu.org
>
> Hi Salil,
>
> On 2024/10/15 上午3:59, Salil Mehta wrote:
> > Hi Bibo,
> >
> >> From: maobibo
> >> Sent: Monday, October 14, 2024 9:53 AM
> >> To: qemu-devel@nongnu.o
Hi Igor,
> From: qemu-devel-bounces+salil.mehta=huawei@nongnu.org devel-bounces+salil.mehta=huawei@nongnu.org> On Behalf Of Igor
> Mammedov
> Sent: Monday, October 14, 2024 10:38 AM
>
> On Mon, 14 Oct 2024 16:52:55 +0800
> maobibo wrote:
>
> > Hi Salil,
> >
> > When I debug
Hi Bibo,
> From: maobibo
> Sent: Monday, October 14, 2024 9:53 AM
> To: qemu-devel@nongnu.org; Salil Mehta
> Cc: Michael S. Tsirkin ; Peter Maydell
> ; Salil Mehta ;
> zhukeqian ; Jonathan Cameron
> ; Gavin Shan ;
> Vishnu Pajjuri ; Xianglai Li
> ; Miguel Luis ; Shaoqin
> Huang ; Zhao
The ACPI CPU hotplug states `is_{present, enabled}` must be migrated alongside
other vCPU hotplug states to the destination VM. Therefore, they should be
integrated into the existing CPU Hotplug VM State Description (VMSD) table.
Depending on the architecture and its implementation of CPU hotplug e
Update the `AcpiCpuStatus` for `is_enabled` and `is_present` accordingly when
vCPUs are hot-plugged or hot-unplugged, taking into account the *persistence*
of the vCPUs.
Signed-off-by: Salil Mehta
---
hw/acpi/cpu.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/hw/acpi/cpu.c b/hw/acp
Reflect the ACPI CPU hotplug `is_{present, enabled}` states in the `_STA.PRES`
(presence) and `_STA.ENA` (enabled) bits when the guest kernel evaluates the
ACPI `_STA` method during initialization, as well as when vCPUs are hot-plugged
or hot-unplugged. The presence of unplugged vCPUs may need to b
Certain CPU architecture specifications [1][2][3] prohibit changes to CPU
presence after the kernel has booted. This limitation exists because many system
initializations rely on the exact CPU count at boot time and do not expect it to
change later. For example, components like interrupt controller
Certain CPU architecture specifications [1][2][3] prohibit changes to the CPUs
*presence* after the kernel has booted. This is because many system
initializations depend on the exact CPU count at boot time and do not expect it
to change afterward. For example, components like interrupt controllers
HI Miguel,
> From: Miguel Luis
> Sent: Thursday, October 10, 2024 3:47 PM
> To: Salil Mehta
>
> Hi Salil,
>
> > On 9 Oct 2024, at 03:17, Salil Mehta wrote:
> >
> > This patch adds various utility functions that may be required to
> > fetch or check the state of possible vCPUs. It al
Hotpluggable vCPUs must be exposed as "online-capable" according to the new UEFI
specification [1][2]. However, marking cold-booted vCPUs as "online-capable"
during boot may cause them to go undetected by legacy operating systems,
potentially leading to compatibility issues. Hence, both 'online-cap
From: Jean-Philippe Brucker
Previously, all `PSCI_CPU_{ON, OFF}` calls were handled directly by KVM.
However, with the introduction of vCPU hotplug, these hypervisor calls are now
trapped to QEMU for policy checks. This shift can lead to inconsistent vCPU
states between KVM and QEMU, particularly
vCPU reset can result in device access to VGIC CPU system registers using the
`IOCTL KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS` interface. When accessing these
registers in the KVM host, it is necessary to acquire a lock on all vCPUs during
the `vgic_v3_attr_regs_access()` operation.
This operation may fai
From: Author Salil Mehta
To support vCPU hotplug, we must trap any `HVC`/`SMC` `PSCI_CPU_{ON,OFF}`
hypercalls from the host KVM to QEMU for policy checks. This ensures the
following when a vCPU is brought online:
1. The vCPU is actually plugged in (i.e., present).
2. The vCPU is not disabled.
I
The QOM `GICv3CPUState` (and consequently the corresponding KVM VGIC `ICC_*_EL1`
registers) can be either 'accessible' or 'inaccessible', depending on the state
of the associated QOM vCPUs. This `gicc_accessible` state should be saved during
migration at the source and restored at the destination.
From: Miguel Luis
Introduce the TCG thread unregistration leg which shall be called in context to
TCG/vCPU unrealize.
Reported-by: Salil Mehta
Signed-off-by: Miguel Luis
Signed-off-by: Salil Mehta
---
accel/tcg/tcg-accel-ops-mttcg.c | 1 +
include/tcg/startup.h | 7 +++
tcg/t
vCPU Hot-unplug will result in QOM CPU object unrealization which will do away
with all the vCPU thread creations, allocations, registrations that happened
as part of the realization process. This change introduces the ARM CPU unrealize
function taking care of exactly that.
Note, initialized KVM v
The TCG code cache consists of multiple regions shared among vCPUs in
multi-threaded TCG mode. For cold-plugged vCPUs, these regions are sized and
allocated during initialization in the `tcg_register_thread()` function when the
vCPUs are realized. Later, these regions must be reallocated for hot-pl
The ARM extensions configuration *must* match the existing vCPUs already
initialized in KVM at VM initialization. ARM does not allow any per-vCPU
features to be changed once the system has fully initialized. This is an
immutable constraint of the ARM CPU architecture.
Signed-off-by: Salil Mehta
-
During any vCPU hot-(un)plug operation, the running guest VM must be notified
about the addition of a new vCPU or the removal of an existing vCPU. This
notification is handled via an ACPI GED event, which is eventually demultiplexed
into a vCPU hotplug event, and then further into a specific hot-(u
1 - 100 of 536 matches
Mail list logo
