This introduces virt_set_high_memmap() helper. The logic of high
memory region address assignment is moved to the helper. The intention
is to make the subsequent optimization for high memory region address
assignment easier.
No functional change intended.
Signed-off-by: Gavin Shan
Reviewed-by
(Marc)
* Use 'bool fits' in virt_set_high_memmap() (Eric)
Gavin Shan (7):
hw/arm/virt: Introduce virt_set_high_memmap() helper
hw/arm/virt: Rename variable size to region_size in
virt_set_high_memmap
This introduces virt_get_high_memmap_enabled() helper, which returns
the pointer to vms->highmem_{redists, ecam, mmio}. The pointer will
be used in the subsequent patches.
No functional change intended.
Signed-off-by: Gavin Shan
Reviewed-by: Eric Auger
Reviewed-by: Cornelia Huck
Tested
This introduces variable 'region_base' for the base address of the
specific high memory region. It's the preparatory work to optimize
high memory region address assignment.
No functional change intended.
Signed-off-by: Gavin Shan
Reviewed-by: Eric Auger
Reviewed-by: Cornelia
This renames variable 'size' to 'region_size' in virt_set_high_memmap().
Its counterpart ('region_base') will be introduced in next patch.
No functional change intended.
Signed-off-by: Gavin Shan
Reviewed-by: Eric Auger
Reviewed-by: Cornelia Huck
Tested-by: Zh
n machine, which is virt-7.1 or ealier than it. It
means the optimization is enabled by default from virt-7.2. Besides,
'compact-highmem' property is added so that the optimization can be
explicitly enabled or disabled on all machine types by users.
Signed-off-by: Gavin Shan
Reviewed-by: Co
Hi Peter and Marc,
On 10/24/22 11:54 AM, Gavin Shan wrote:
There are three high memory regions, which are VIRT_HIGH_REDIST2,
VIRT_HIGH_PCIE_ECAM and VIRT_HIGH_PCIE_MMIO. Their base addresses
are floating on highest RAM address. However, they can be disabled
in several cases.
(1) One specific
Hi Eric,
On 10/26/22 12:29 AM, Eric Auger wrote:
On 10/24/22 05:54, Gavin Shan wrote:
There are three high memory regions, which are VIRT_HIGH_REDIST2,
VIRT_HIGH_PCIE_ECAM and VIRT_HIGH_PCIE_MMIO. Their base addresses
are floating on highest RAM address. However, they can be disabled
in
Hi Connie,
On 10/25/22 6:30 PM, Cornelia Huck wrote:
On Mon, Oct 24 2022, Gavin Shan wrote:
After the improvement to high memory region address assignment is
applied, the memory layout can be changed, introducing possible
migration breakage. For example, VIRT_HIGH_PCIE_MMIO memory region
is
Hi Connie,
On 10/25/22 6:54 PM, Cornelia Huck wrote:
On Mon, Oct 24 2022, Gavin Shan wrote:
These 3 high memory regions are usually enabled by default, but
s/These 3/The/ ?
Ok.
they may be not used. For example, VIRT_HIGH_GIC_REDIST2 isn't
needed by GICv2. This leads to waste i
Hi Connie,
On 10/26/22 6:43 PM, Cornelia Huck wrote:
On Wed, Oct 26 2022, Gavin Shan wrote:
On 10/26/22 12:29 AM, Eric Auger wrote:
On 10/24/22 05:54, Gavin Shan wrote:
There are three high memory regions, which are VIRT_HIGH_REDIST2,
VIRT_HIGH_PCIE_ECAM and VIRT_HIGH_PCIE_MMIO. Their base
Hi Connie,
On 10/26/22 7:10 PM, Cornelia Huck wrote:
On Wed, Oct 26 2022, Gavin Shan wrote:
On 10/25/22 6:54 PM, Cornelia Huck wrote:
On Mon, Oct 24 2022, Gavin Shan wrote:
These 3 high memory regions are usually enabled by default, but
s/These 3/The/ ?
Ok.
they may be not used
This introduces virt_set_high_memmap() helper. The logic of high
memory region address assignment is moved to the helper. The intention
is to make the subsequent optimization for high memory region address
assignment easier.
No functional change intended.
Signed-off-by: Gavin Shan
Reviewed-by
This renames variable 'size' to 'region_size' in virt_set_high_memmap().
Its counterpart ('region_base') will be introduced in next patch.
No functional change intended.
Signed-off-by: Gavin Shan
Reviewed-by: Eric Auger
Reviewed-by: Cornelia Huck
Reviewed-by: M
This introduces variable 'region_base' for the base address of the
specific high memory region. It's the preparatory work to optimize
high memory region address assignment.
No functional change intended.
Signed-off-by: Gavin Shan
Reviewed-by: Eric Auger
Reviewed-by: Cornelia Hu
This introduces virt_get_high_memmap_enabled() helper, which returns
the pointer to vms->highmem_{redists, ecam, mmio}. The pointer will
be used in the subsequent patches.
No functional change intended.
Signed-off-by: Gavin Shan
Reviewed-by: Eric Auger
Reviewed-by: Cornelia Huck
Reviewed
log and source code (Eric)
v3:
* Reorder the patches(Gavin)
* Add 'highmem-compact' property for backwards compatibility (Eric)
v2:
* Split the patches for easier review(Gavin)
* Improved changelog
n machine, which is virt-7.1 or ealier than it. It
means the optimization is enabled by default from virt-7.2. Besides,
'compact-highmem' property is added so that the optimization can be
explicitly enabled or disabled on all machine types by users.
Signed-off-by: Gavin Shan
Reviewed-by: E
ement should be applied. For now, 'vms->highmem_compact' is
set to false, meaning that we don't have memory layout change until it
becomes configurable through property 'compact-highmem' in next patch.
Signed-off-by: Gavin Shan
Reviewed-by: Eric Auger
Reviewed-by
high memory region for GICv3 and GICv4 has been
enabled or not.
Suggested-by: Marc Zyngier
Signed-off-by: Gavin Shan
Reviewed-by: Marc Zyngier
---
docs/system/arm/virt.rst | 13 +++
hw/arm/virt.c| 75 ++--
2 files changed, 86 insertions(
Hi Marc,
On 10/29/22 7:29 PM, Marc Zyngier wrote:
On Wed, 26 Oct 2022 01:29:56 +0100,
Gavin Shan wrote:
On 10/24/22 11:54 AM, Gavin Shan wrote:
There are three high memory regions, which are VIRT_HIGH_REDIST2,
VIRT_HIGH_PCIE_ECAM and VIRT_HIGH_PCIE_MMIO. Their base addresses
are floating on
Hi Peter,
On 10/29/22 2:06 AM, Peter Maydell wrote:
On Wed, 26 Oct 2022 at 01:30, Gavin Shan wrote:
On 10/24/22 11:54 AM, Gavin Shan wrote:
There are three high memory regions, which are VIRT_HIGH_REDIST2,
VIRT_HIGH_PCIE_ECAM and VIRT_HIGH_PCIE_MMIO. Their base addresses
are floating on
Hi Igor,
On 6/10/22 12:00 AM, Igor Mammedov wrote:
On Thu, 26 May 2022 22:40:05 +0800
Gavin Shan wrote:
On 5/26/22 8:25 PM, Igor Mammedov wrote:
On Wed, 18 May 2022 17:21:40 +0800
Gavin Shan wrote:
The {socket, cluster, core} IDs detected from Linux guest aren't
matching with what
ended.
Signed-off-by: Gavin Shan
---
accel/kvm/kvm-all.c | 2 +-
include/exec/memory.h | 5 +++--
migration/dirtyrate.c | 4 ++--
migration/ram.c | 6 +++---
softmmu/memory.c | 10 +-
5 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/accel/kvm/kvm-all.c b/acce
v=net0,mac=52:54:00:f1:26:a0
-netdev tap,id=vnet0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \
-device virtio-net-pci,bus=pcie.6,netdev=vnet0,mac=52:54:00:f1:26:b0
Gavin Shan (8):
linux-headers: Update for dirty ring
memory: Add last stage indicator to global dirty log synchro
Signed-off-by: Gavin Shan
---
linux-headers/asm-arm64/kvm.h | 1 +
linux-headers/linux/kvm.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/linux-headers/asm-arm64/kvm.h b/linux-headers/asm-arm64/kvm.h
index 4bf2d7246e..a7cfefb3a8 100644
--- a/linux-headers/asm-arm64/kvm.h
+++ b
For the pre-copy live migration scenario, the last stage indicator
is needed for KVM backend to collect the dirty pages from the backup
bitmap when dirty ring is used. The indicator isn't used so far.
No functional change intended.
Signed-off-by: Gavin Shan
---
migration/ram.c
.
Signed-off-by: Gavin Shan
---
accel/kvm/kvm-all.c | 50 ++--
include/sysemu/kvm_int.h | 1 +
2 files changed, 39 insertions(+), 12 deletions(-)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 01a6a026af..1a93985574 100644
--- a/accel/kvm/kvm
arm64 has different capability from x86 to enable the dirty ring, which
is KVM_CAP_DIRTY_LOG_RING_ACQ_REL. To enable it in kvm_dirty_ring_init()
when KVM_CAP_DIRTY_LOG_RING isn't supported.
Signed-off-by: Gavin Shan
---
accel/kvm/kvm-all.c | 10 --
1 file changed, 8 insertions(
When KVM device "kvm-arm-gicv3" or "arm-its-kvm" is used, we have to
enable the backup bitmap for the dirty ring. Otherwise, the migration
will fail because those two devices are using the backup bitmap to track
dirty guest memory, corresponding to various hardware tables.
In the last stage of live migration or memory slot removal, the
backup bitmap needs to be synchronized.
Signed-off-by: Gavin Shan
---
accel/kvm/kvm-all.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 1a93985574..9ec117c441 100644
ring. With this,
the code looks a bit clean.
No functional change intended.
Signed-off-by: Gavin Shan
---
accel/kvm/kvm-all.c | 73 -
1 file changed, 46 insertions(+), 27 deletions(-)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index
On 2/9/23 9:07 AM, Juan Quintela wrote:
Gavin Shan wrote:
When dirty ring is enabled on ARM64, the backup bitmap may be used
to track the dirty pages in no-running-vcpu situations. The original
bitmap is the primary one, used for the dirty ring buffer. We need
the secondary bitmap to collect
On 2/9/23 9:11 AM, Juan Quintela wrote:
Gavin Shan wrote:
Due to multiple capabilities associated with the dirty ring for different
architectures: KVM_CAP_DIRTY_{LOG_RING, LOG_RING_ACQ_REL} for x86 and
arm64 separately. There will be more to be done in order to support the
dirty ring for arm64
On 2/10/23 6:48 AM, Peter Xu wrote:
On Mon, Feb 06, 2023 at 07:20:04PM +0800, Gavin Shan wrote:
The global dirty log synchronization is used when KVM and dirty ring
are enabled. There is a particularity for ARM64 where the backup
bitmap is used to track dirty pages in non-running-vcpu
()
(Juan)
Gavin Shan (6):
linux-headers: Update for dirty ring
migration: Add last stage indicator to global dirty log
synchronization
kvm: Synchronize the backup bitmap in the last stage
kvm: Add helper kvm_dirty_ring_init()
hw/arm/virt: Enable backup bitmap
Signed-off-by: Gavin Shan
---
linux-headers/asm-arm64/kvm.h | 1 +
linux-headers/linux/kvm.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/linux-headers/asm-arm64/kvm.h b/linux-headers/asm-arm64/kvm.h
index 4bf2d7246e..a7cfefb3a8 100644
--- a/linux-headers/asm-arm64/kvm.h
+++ b
arm64 has different capability from x86 to enable the dirty ring, which
is KVM_CAP_DIRTY_LOG_RING_ACQ_REL. To enable it in kvm_dirty_ring_init()
when KVM_CAP_DIRTY_LOG_RING isn't supported.
Signed-off-by: Gavin Shan
Reviewed-by: Juan Quintela
---
accel/kvm/kvm-all.c | 10 --
1
In the last stage of live migration or memory slot removal, the
backup bitmap needs to be synchronized when it has been enabled.
Signed-off-by: Gavin Shan
---
accel/kvm/kvm-all.c | 11 +++
include/sysemu/kvm_int.h | 1 +
2 files changed, 12 insertions(+)
diff --git a/accel/kvm
When KVM device "kvm-arm-gicv3" or "arm-its-kvm" is used, we have to
enable the backup bitmap for the dirty ring. Otherwise, the migration
will fail because those two devices are using the backup bitmap to track
dirty guest memory, corresponding to various hardware tables.
n the subsequent patches.
No functional change intended.
Signed-off-by: Gavin Shan
---
accel/kvm/kvm-all.c | 2 +-
include/exec/memory.h | 5 +++--
migration/dirtyrate.c | 4 ++--
migration/ram.c | 20 ++--
softmmu/memory.c | 10 +-
5 files changed, 21 inser
ring. With this,
the code looks a bit clean.
No functional change intended.
Signed-off-by: Gavin Shan
---
accel/kvm/kvm-all.c | 76 -
1 file changed, 47 insertions(+), 29 deletions(-)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index
On 2/23/23 2:54 AM, Peter Maydell wrote:
On Wed, 22 Feb 2023 at 04:36, Gavin Shan wrote:
On 2/22/23 3:27 AM, Peter Maydell wrote:
Why does this need to be board-specific code? Is there
some way we can just do the right thing automatically?
Why does the GIC/ITS matter?
The kernel should
There are two ARM machines where NUMA is aware: 'virt' and 'sbsa-ref'.
Both of them are required to follow socket-NUMA-node boundary. To
enable the validation to reject incorrect configuration.
Signed-off-by: Gavin Shan
---
hw/arm/sbsa-ref.c | 2 ++
hw/arm/virt.c | 2 ++
After socket-to-NUMA-node boundary is applied to aarch64 in the subsequent
patches, we need to explicitly specify 'smp.sockets=2' for 'test_mon_explicit'
and 'test_query_cpus' test cases. Besides, 'test_mon_partial' isn't applied
to aarch64 any more.
There are two RISCV machines where NUMA is aware: 'virt' and 'spike'.
Both of them are required to follow socket-NUMA-node boundary. To
enable the validation to reject incorrect configuration.
Signed-off-by: Gavin Shan
---
hw/riscv/spike.c | 1 +
hw/riscv/virt.c | 1 +
* Add helper set_numa_socket_boundary() and validate the
boundary in the generic path (Philippe)
Gavin Shan (4):
qtest/numa-test: Follow socket-NUMA-node boundary for aarch64
numa: Validate socket and NUMA node boundary if required
hw/arm: Validate socket and NUMA node boun
e the sitation to reject the configuration where multiple CPUs
in one socket have been associated with different NUMA nodes. The
newly introduced helper set_numa_socket_boundary() is expected to
called by specific machines (boards) where the boundary is required.
Signed-off-by: Gavin Shan
---
hw
On 2/23/23 8:05 PM, Philippe Mathieu-Daudé wrote:
On 23/2/23 09:13, Gavin Shan wrote:
For some architectures like ARM64, multiple CPUs in one socket can't be
associated with different NUMA nodes. Otherwise, the guest kernel is confused
about the CPU topology. For example, the following wa
On 2/23/23 11:57 PM, Daniel P. Berrangé wrote:
On Thu, Feb 23, 2023 at 04:13:57PM +0800, Gavin Shan wrote:
For arm64 and RiscV architecture, the driver (/base/arch_topology.c) is
used to populate the CPU topology in the Linux guest. It's required that
the CPUs in one socket can't sp
On 2/24/23 12:18 AM, Daniel Henrique Barboza wrote:
On 2/23/23 05:13, Gavin Shan wrote:
For arm64 and RiscV architecture, the driver (/base/arch_topology.c) is
used to populate the CPU topology in the Linux guest. It's required that
the CPUs in one socket can't span mutiple
Hi Drew,
On 2/23/23 11:25 PM, Andrew Jones wrote:
On Thu, Feb 23, 2023 at 04:13:57PM +0800, Gavin Shan wrote:
For arm64 and RiscV architecture, the driver (/base/arch_topology.c) is
used to populate the CPU topology in the Linux guest. It's required that
the CPUs in one socket can&#
On 2/24/23 8:26 PM, Daniel Henrique Barboza wrote:
On 2/24/23 04:09, Gavin Shan wrote:
On 2/24/23 12:18 AM, Daniel Henrique Barboza wrote:
On 2/23/23 05:13, Gavin Shan wrote:
For arm64 and RiscV architecture, the driver (/base/arch_topology.c) is
used to populate the CPU topology in the Linux
On 2/23/23 10:51 PM, Peter Maydell wrote:
On Thu, 23 Feb 2023 at 00:52, Gavin Shan wrote:
On 2/23/23 2:54 AM, Peter Maydell wrote:
But we might have to for other boards we add later. We shouldn't
put code in per-board if it's not really board specific.
Moreover, I think "we
On 2/25/23 1:20 AM, Igor Mammedov wrote:
On Fri, 24 Feb 2023 21:16:39 +1100
Gavin Shan wrote:
On 2/24/23 8:26 PM, Daniel Henrique Barboza wrote:
On 2/24/23 04:09, Gavin Shan wrote:
On 2/24/23 12:18 AM, Daniel Henrique Barboza wrote:
On 2/23/23 05:13, Gavin Shan wrote:
For arm64 and RiscV
0x140
ret_from_fork+0x10/0x20
Improve the situation to warn when multiple CPUs in one cluster have
been associated with different NUMA nodes. However, one NUMA node is
allowed to be associated with different clusters.
Signed-off-by: Gavin Shan
---
hw/core/machine.c
odes.
Signed-off-by: Gavin Shan
---
hw/riscv/spike.c | 2 ++
hw/riscv/virt.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/hw/riscv/spike.c b/hw/riscv/spike.c
index cc3f6dac17..b09b993634 100644
--- a/hw/riscv/spike.c
+++ b/hw/riscv/spike.c
@@ -357,6 +357,8 @@ static void spike_machine_cl
* Drop PATCH[v2 1/4] related to qtests/numa-test(Gavin)
v2:
* Fix socket-NUMA-node boundary issues in qtests/numa-test (Gavin)
* Add helper set_numa_socket_boundary() and validate the
boundary in the generic path (Philippe)
Gavin Shan (3):
A
nodes.
Signed-off-by: Gavin Shan
---
hw/arm/sbsa-ref.c | 2 ++
hw/arm/virt.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
index f778cb6d09..91d38af94c 100644
--- a/hw/arm/sbsa-ref.c
+++ b/hw/arm/sbsa-ref.c
@@ -864,6 +864,8 @@ static void
In the last stage of live migration or memory slot removal, the
backup bitmap needs to be synchronized when it has been enabled.
Signed-off-by: Gavin Shan
Reviewed-by: Peter Xu
Tested-by: Zhenyu Zhang
---
accel/kvm/kvm-all.c | 11 +++
include/sysemu/kvm_int.h | 1 +
2 files
s always enabled
and the unnecessary overhead to do the last stage of dirty log synchronization
when those two devices aren't used is introduced, but the overhead should
be very small and acceptable. The benefit is cover future cases where those
two devices are used without modifying the code.
(PeterM)
v1:
* Combine two patches into one PATCH[v1 2/6] for the last stage indicator
(PeterX)
* Drop the secondary bitmap and use the original one directly
(Juan)
* Avoid "goto out" in helper kvm_dirty_ring_init()
n the subsequent patches.
No functional change intended.
Signed-off-by: Gavin Shan
Reviewed-by: Peter Xu
Tested-by: Zhenyu Zhang
---
accel/kvm/kvm-all.c | 2 +-
include/exec/memory.h | 7 +--
migration/dirtyrate.c | 4 ++--
migration/ram.c | 20 ++--
softmmu/mem
ring. With this,
the code looks a bit clean.
No functional change intended.
Signed-off-by: Gavin Shan
Reviewed-by: Peter Xu
Tested-by: Zhenyu Zhang
---
accel/kvm/kvm-all.c | 76 -
1 file changed, 47 insertions(+), 29 deletions(-)
diff --git a/accel
Hi Salil and Igor,
On 6/26/24 9:51 AM, Salil Mehta wrote:
On Wed, Jun 5, 2024 at 3:03 PM Igor Mammedov mailto:imamm...@redhat.com>> wrote:
On Sun, 2 Jun 2024 18:03:05 -0400
"Michael S. Tsirkin" mailto:m...@redhat.com>> wrote:
> On Thu, May 30, 2024 at 12:42:33AM +0100, Salil Mehta
Hi Salil,
With this series and latest upstream Linux kernel (host), I ran into core dump
as below.
I'm not sure if it's a known issue or not.
# uname -r
6.11.0-rc2-gavin+
# /home/gavin/sandbox/qemu.main/build/qemu-system-aarch64 -accel kvm \
-machine virt,gic-version=host,nvdimm=on -cpu host
Hi Salil,
On 8/7/24 11:27 PM, Salil Mehta wrote:
Let me figure out this. Have you also included the below patch along with the
architecture agnostic patch-set accepted in this Qemu cycle?
https://lore.kernel.org/all/20240801142322.3948866-3-peter.mayd...@linaro.org/
There are no vCPU fd to
Hi Salil,
On 8/8/24 9:48 AM, Salil Mehta wrote:
On 8/7/24 11:27 PM, Salil Mehta wrote:
>
> Let me figure out this. Have you also included the below patch along
> with the architecture agnostic patch-set accepted in this Qemu cycle?
>
> https://lore.kernel.org/all/20240801142322.39488
Hi Salil,
On 8/8/24 10:29 AM, Gavin Shan wrote:
On 8/8/24 9:48 AM, Salil Mehta wrote:
However, I'm unable to hot-add a vCPU and haven't get a chance to look
at it closely.
(qemu) device_add host-arm-cpu,id=cpu,socket-id=1
(qemu) [ 258.901027] Unable to handle kernel write to read-o
Hi Salil,
On 8/8/24 2:07 AM, Salil Mehta wrote:
I tested ARM arch specific patches with the latest Qemu which contains below
mentioned
fix and I cannot reproduce the crash. I used kernel linux-6.11-rc2 and it
booted successfully.
Though I did see a kernel crash on attempting to hotplug first v
Remove kvm_arm_get_max_vm_ipa_size() after its logics are moved
to its only caller kvm_arch_get_default_type().
Signed-off-by: Gavin Shan
---
target/arm/kvm.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/target/arm/kvm.c b/target/arm/kvm.c
index 65893c9c12
virt_kvm_type() and mc->kvm_type() are only needed when CONFIG_KVM
is enabled. It's reasonable to hide them when CONFIG_KVM is disabled.
Signed-off-by: Gavin Shan
---
hw/arm/virt.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 719e83e6a1..83
, kvm_arm_get_max_vm_ipa_size() needn't to be a public API
any more.
Signed-off-by: Gavin Shan
---
hw/arm/virt.c| 14 ++
target/arm/kvm.c | 2 +-
target/arm/kvm_arm.h | 15 ---
3 files changed, 7 insertions(+), 24 deletions(-)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
The comment needn't to span multiple lines and can be merged to
one line perfectly.
Signed-off-by: Gavin Shan
---
hw/arm/virt.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 83be57db37..09b7a158a9 100644
--- a/hw/arm/virt.c
+++
e KVM type and
IPA size (bits).
Gavin Shan (4):
hw/arm/virt: hide virt_kvm_type() on !CONFIG_KVM
hw/arm/virt: Avoid multiple lines of comments in virt_kvm_type()
hw/arm/virt: Use kvm_arch_get_default_type()
target/arm/kvm: Remove kvm_arm_get_max_vm_ipa_size()
hw/arm/virt.c
On 8/9/24 7:00 PM, Peter Maydell wrote:
On Fri, 9 Aug 2024 at 04:52, Gavin Shan wrote:
virt_kvm_type() and mc->kvm_type() are only needed when CONFIG_KVM
is enabled. It's reasonable to hide them when CONFIG_KVM is disabled.
Signed-off-by: Gavin Shan
---
hw/arm/virt.c | 4
On 8/9/24 6:59 PM, Peter Maydell wrote:
On Fri, 9 Aug 2024 at 04:52, Gavin Shan wrote:
kvm_arch_get_default_type() and kvm_arm_get_max_vm_ipa_size() are
interchangeable since the type is equivalent to IPA size (bits)
with one exception that IPA size (bits) is 40 when the type is zero.
Well
On 8/9/24 1:51 PM, Gavin Shan wrote:
kvm_arch_get_default_type() and kvm_arm_get_max_vm_ipa_size() are
interchangeable since the type is equivalent to IPA size (bits)
with one exception that IPA size (bits) is 40 when the type is zero.
Replace kvm_arm_get_max_vm_ipa_size() with
On 6/14/24 9:36 AM, Salil Mehta wrote:
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
On 6/14/24 9:36 AM, Salil Mehta wrote:
This patch adds various utility functions that may be required to fetch or check
the state of possible vCPUs. It also introduces the concept of *disabled* vCPUs,
which are part of the *possible* vCPUs but are not enabled. This state will be
used during machi
On 6/14/24 9:36 AM, Salil Mehta wrote:
If Virtual CPU Hotplug support does not exist on a particular Accel platform or
ARM GIC version, we should limit the possible vCPUs to those available during
boot time (i.e SMP CPUs) and explicitly disable Virtual CPU Hotplug support.
Signed-off-by: Salil M
On 6/14/24 9:36 AM, Salil Mehta wrote:
Factor out CPU properties code common for {hot,cold}-plugged CPUs. This allows
code reuse.
Signed-off-by: Salil Mehta
---
hw/arm/virt.c | 261 --
include/hw/arm/virt.h | 4 +
2 files changed, 182 insert
On 8/12/24 6:15 PM, Igor Mammedov wrote:
On Mon, 12 Aug 2024 14:35:56 +1000
Gavin Shan wrote:
On 6/14/24 9:36 AM, Salil Mehta wrote:
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-in
On 6/14/24 9:36 AM, Salil Mehta wrote:
In the ARMv8 architecture, the GIC must know all the CPUs it is connected to
during its initialization, and this cannot change afterward. This must be
ensured during the initialization of the VGIC as well in KVM, which requires all
vCPUs to be created and pr
On 6/14/24 9:36 AM, Salil Mehta wrote:
ACPI CPU hotplug state (is_present=_STA.PRESENT, is_enabled=_STA.ENABLED) for
all the possible vCPUs MUST be initialized during machine init. This is done
during the creation of the GED device. VMM/Qemu MUST expose/fake the ACPI state
of the disabled vCPUs t
On 6/14/24 9:36 AM, Salil Mehta wrote:
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 initi
On 6/14/24 9:36 AM, Salil Mehta wrote:
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 approac
On 6/14/24 9:36 AM, Salil Mehta wrote:
In the ARMv8 architecture, the GIC must know all the CPUs it is connected to
during its initialization, and this cannot change afterward. This must be
ensured during the initialization of the VGIC as well in KVM, which requires all
vCPUs to be created and pr
Hi Salil,
On 8/19/24 10:21 PM, Salil Mehta wrote:
From: Gavin Shan
Sent: Tuesday, August 13, 2024 2:17 AM
To: Salil Mehta ; qemu-devel@nongnu.org;
qemu-...@nongnu.org; m...@redhat.com
On 6/14/24 9:36 AM, Salil Mehta wrote:
> During `machvirt_init()`, QOM ARMCPU objects are
Hi Salil,
On 8/19/24 10:10 PM, Salil Mehta wrote:
From: Gavin Shan
Sent: Tuesday, August 13, 2024 2:05 AM
To: Salil Mehta ; qemu-devel@nongnu.org;
qemu-...@nongnu.org; m...@redhat.com
On 6/14/24 9:36 AM, Salil Mehta wrote:
> ACPI CPU hotplug state (is_present=_STA.PRES
Hi Salil,
On 8/21/24 2:40 AM, Salil Mehta wrote:
I don’t understand this clearly. Are you suggesting to reuse only single
vCPU object to initialize all KVM vCPUs not yet plugged? If yes, then
I'm not sure what do we gain here by adding this complexity? It does
not consume time or resources bec
Hi Salil,
On 8/21/24 8:23 PM, Salil Mehta wrote:
On 8/21/24 2:40 AM, Salil Mehta wrote:
>
> I don’t understand this clearly. Are you suggesting to reuse only
> single vCPU object to initialize all KVM vCPUs not yet plugged? If
> yes, then I'm not sure what do we gain here by adding
Hi Sail,
On 8/22/24 8:58 PM, Salil Mehta wrote:
On 8/21/24 8:23 PM, Salil Mehta wrote:
>>
>> On 8/21/24 2:40 AM, Salil Mehta wrote:
>> >
>> > I don’t understand this clearly. Are you suggesting to reuse only
>> > single vCPU object to initialize all KVM vCPUs not yet plugged
On 5/31/24 14:19, Itaru Kitayama wrote:
On May 30, 2024, at 22:30, Philippe Mathieu-Daudé wrote:
Cc'ing more developers
On 30/5/24 06:30, Itaru Kitayama wrote:
Hi,
When I see a Realm VM creation fails with:
Unexpected error in rme_configure_one() at ../target/arm/kvm-rme.c:159:
qemu-system-aar
Hi Jean and Ard,
On 6/1/24 01:09, Jean-Philippe Brucker wrote:
On Fri, May 31, 2024 at 04:23:13PM +1000, Gavin Shan wrote:
I got a chance to try CCA software components, suggested by [1]. However, the
edk2
is stuck somewhere. I didn't reach to stage of loading guest kernel yet. I'm
Hi Jean,
On 6/3/24 18:24, Jean-Philippe Brucker wrote:
On Sat, Jun 01, 2024 at 08:14:46PM +1000, Gavin Shan wrote:
---> guest edk2
# git clone https://git.codelinaro.org/linaro/dcap/edk2.git edk2-guest
# cd edk2-guest; git checkout origin/cca/v2 -b cca/v2
# git submodule update --i
Hi Jean,
On 6/4/24 21:15, Jean-Philippe Brucker wrote:
On Tue, Jun 04, 2024 at 01:02:08PM +1000, Gavin Shan wrote:
On 6/3/24 18:24, Jean-Philippe Brucker wrote:
On Sat, Jun 01, 2024 at 08:14:46PM +1000, Gavin Shan wrote:
---> guest edk2
# git clone https://git.codelinaro.org/linaro/d
On 6/6/24 01:56, Jean-Philippe Brucker wrote:
On Wed, Jun 05, 2024 at 11:28:47AM +1000, Gavin Shan wrote:
WriteSections64():
/home/gavin/sandbox/CCA/edk2-guest/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore/DEBUG/ArmPlatformPrePeiCore.dll
On 6/6/24 15:05, Gavin Shan wrote:
Even the edk2 for the guest can be built successfully, but I'm not able to try
it
because I'm unable to bring up the host now. I tried to rebuild the environment
from scratch, the host runs into crash inside EDK2 unfortunately...
TF-RM
On 1/24/24 08:25, Philippe Mathieu-Daudé wrote:
QDev objects created with qdev_new() need to manually add
their parent relationship with object_property_add_child().
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/exynos4210.c | 1 +
1 file changed, 1 insertion(+)
Reviewed-by: Gavin
401 - 500 of 1041 matches
Mail list logo
