ned-off-by: Philippe Mathieu-Daudé
---
hw/arm/exynos4_boards.c | 8
1 file changed, 8 insertions(+)
Reviewed-by: Gavin Shan
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/highbank.c | 1 +
1 file changed, 1 insertion(+)
Reviewed-by: Gavin Shan
pe Mathieu-Daudé
---
hw/arm/highbank.c | 10 ++
1 file changed, 10 insertions(+)
Reviewed-by: Gavin Shan
On 1/24/24 08:25, Philippe Mathieu-Daudé wrote:
Restrict MachineClass::valid_cpu_types[] to the single
valid CPU types.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/vexpress.c | 10 ++
1 file changed, 10 insertions(+)
Reviewed-by: Gavin Shan
On 1/24/24 08:25, Philippe Mathieu-Daudé wrote:
Restrict MachineClass::valid_cpu_types[] to the single
valid CPU type.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/xilinx_zynq.c | 5 +
1 file changed, 5 insertions(+)
Reviewed-by: Gavin Shan
On 1/24/24 08:48, Philippe Mathieu-Daudé wrote:
Remove copy/paste typo from commit 6c323aba40 ("hw/arm/aspeed:
Adding new machine Tiogapass in QEMU").
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/aspeed.c | 1 -
1 file changed, 1 deletion(-)
Reviewed-by: Gavin Shan
oc:
Add AST1030 support") and supermicrox11-bmc (commit 40a38df55e
"hw/arm/aspeed: Add board model for Supermicro X11 BMC") machines.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/aspeed.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Reviewed-by: Gavin Shan
insertions(+), 43 deletions(-)
One nit needs to be addressed:
Reviewed-by: Gavin Shan
diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 5b01a4dd28..636a6269aa 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -1141,10 +1141,14 @@ static void aspeed_machine_class_props_init(ObjectClass
*oc
/arm/aspeed_ast10x0.c | 2 +-
hw/arm/aspeed_ast2400.c | 3 ++-
hw/arm/aspeed_ast2600.c | 3 ++-
hw/arm/aspeed_soc_common.c | 5 +
5 files changed, 11 insertions(+), 3 deletions(-)
Reviewed-by: Gavin Shan
-
hw/arm/aspeed_ast2600.c | 6 +-
hw/arm/aspeed_soc_common.c | 5 -
6 files changed, 27 insertions(+), 6 deletions(-)
Reviewed-by: Gavin Shan
-tree root
node, meaning all devices are capable of DMA coherent by default.
Signed-off-by: Zhenyu Zhang
---
v3: Add comments explaining why we add 'dma-coherent' property (Peter)
---
hw/arm/virt.c | 11 +++
1 file changed, 11 insertions(+)
Reviewed-by: Gavin Shan
Hi Salil,
On 8/23/24 11:17 PM, Salil Mehta wrote:
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
>
e entirely.
Signed-off-by: Peter Maydell
---
A small once-only leak, so this is 9.2 material. Spotted
with clang leak-sanitizer.
hw/arm/sbsa-ref.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
Reviewed-by: Gavin Shan
efault THP size.
Cc: "Michael S. Tsirkin"
Cc: Gavin Shan
Cc: Juraj Marcin
Signed-off-by: David Hildenbrand
---
hw/virtio/virtio-mem.c | 7 +++
1 file changed, 7 insertions(+)
Reviewed-by: Gavin Shan
system/memory.c:2419: memory_region_get_ram_ptr: \
Assertion `mr->ram_block' failed.
Fix it by applying the merge property only when the memory region is
initialized.
Fixes: 5becdc0ab083 ("hostmem: simplify the code for merge and dump properties")
Reported-by: Zhenyu
Hi Igor,
On 3/3/22 11:11 AM, Gavin Shan wrote:
When the CPU-to-NUMA association isn't provided by user, the default NUMA
node ID for the specific CPU is returned from virt_get_default_cpu_node_id().
Unfortunately, the default NUMA node ID breaks socket boundary and leads to
the broke
Hi Igor, Yanan and maintainers,
On 5/18/22 5:21 PM, Gavin Shan wrote:
The {socket, cluster, core} IDs detected from Linux guest aren't
matching with what have been provided in PPTT. The flag used for
'ACPI Processor ID valid' is missed for {socket, cluster, core}
nodes. In t
Hi Igor,
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 have been provided in PPTT. The flag used for
'ACPI Processor ID valid' is missed for {
On 5/26/22 8:27 PM, Igor Mammedov wrote:
On Thu, 26 May 2022 19:37:47 +0800
Gavin Shan wrote:
On 5/18/22 5:21 PM, Gavin Shan wrote:
The {socket, cluster, core} IDs detected from Linux guest aren't
matching with what have been provided in PPTT. The flag used for
'ACPI Processor ID
| 2 +-
8 files changed, 18 insertions(+), 18 deletions(-)
Reviewed-by: Gavin Shan
diff --git a/tests/avocado/boot_xen.py b/tests/avocado/boot_xen.py
index fc2faeedb559..899c396bd55c 100644
--- a/tests/avocado/boot_xen.py
+++ b/tests/avocado/boot_xen.py
@@ -66,7 +66,7 @@ def
Hi Yanan and Igor,
On 3/21/22 10:28 AM, wangyanan (Y) wrote:
On 2022/3/18 21:27, Igor Mammedov wrote:
On Fri, 18 Mar 2022 21:00:35 +0800
"wangyanan (Y)" wrote:
On 2022/3/18 17:56, Igor Mammedov wrote:
On Fri, 18 Mar 2022 14:23:34 +0800
"wangyanan (Y)" wrote:
On 2022/3
cpu_arch_ids,
Agreed, I will do in v3. Sorry that I forgot to mention it in last reply.
Thanks,
Gavin
and the other fixes the numa node ID issue.
Signed-off-by: Gavin Shan
---
hw/arm/virt.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/
Hi Igor and Yanan,
On 3/18/22 9:28 PM, Igor Mammedov wrote:
On Fri, 18 Mar 2022 14:34:12 +0800
"wangyanan (Y)" wrote:
On 2022/3/3 11:11, Gavin Shan wrote:
When the PPTT table is built, the CPU topology is re-calculated, but
it's unecessary because the CPU topology, except
the existing CPU topology when the
PPTT table is built(Igor)
* Added PATCH[3/3] to take thread ID as ACPI processor ID
in MADT and SRAT table (Gavin)
Gavin Shan (4):
hw/arm/virt: Consider SMP configu
lated. The die ID for the given CPU isn't assigned since
it's not supported on arm/virt machine yet. Besides, the cluster
ID for the given CPU is assigned because it has been supported
on arm/virt machine.
Signed-off-by: Gavin Shan
---
hw/arm/virt.c | 11 +++
qapi/machine.json
The value of the following field has been used in ACPI PPTT table
to identify the corresponding processor. This takes the same field
as the ACPI processor ID in MADT and SRAT tables.
ms->possible_cpus->cpus[i].props.thread_id
Signed-off-by: Gavin Shan
---
hw/arm/virt-acpi-build.
e associated with NODE#0/1, but
there are no CPUs associated with NODE#2/3/4/5.
Signed-off-by: Gavin Shan
---
hw/arm/virt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 064eac42f7..3286915229 100644
--- a/hw/arm/virt.c
+++ b/hw/arm
the only user of build_pptt() is
arm/virt machine.
Signed-off-by: Gavin Shan
---
hw/acpi/aml-build.c | 96 +
1 file changed, 72 insertions(+), 24 deletions(-)
diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
index 4086879ebf..10a2d63b96 100644
Hi Igor,
On 3/25/22 9:19 PM, Igor Mammedov wrote:
On Wed, 23 Mar 2022 15:24:35 +0800
Gavin Shan wrote:
Currently, the SMP configuration isn't considered when the CPU
topology is populated. In this case, it's impossible to provide
the default CPU-to-NUMA mapping or association ba
Hi Igor,
On 3/25/22 10:00 PM, Igor Mammedov wrote:
On Wed, 23 Mar 2022 15:24:38 +0800
Gavin Shan wrote:
The value of the following field has been used in ACPI PPTT table
to identify the corresponding processor. This takes the same field
as the ACPI processor ID in MADT and SRAT tables
Hi Drew,
On 10/6/21 10:56 PM, Andrew Jones wrote:
On Wed, Oct 06, 2021 at 10:03:25PM +1100, Gavin Shan wrote:
On 10/6/21 9:35 PM, Andrew Jones wrote:
On Wed, Oct 06, 2021 at 06:22:08PM +0800, Gavin Shan wrote:
The following option is used to specify the distance map. It's
possible the o
Hi Drew,
On 10/8/21 5:07 PM, Andrew Jones wrote:
On Fri, Oct 08, 2021 at 10:51:24AM +1100, Gavin Shan wrote:
On 10/6/21 10:56 PM, Andrew Jones wrote:
On Wed, Oct 06, 2021 at 10:03:25PM +1100, Gavin Shan wrote:
On 10/6/21 9:35 PM, Andrew Jones wrote:
On Wed, Oct 06, 2021 at 06:22:08PM +0800
distance map (Drew)
Gavin Shan (2):
numa: Set default distance map if needed
hw/arm/virt: Don't create device-tree node for empty NUMA node
hw/arm/boot.c | 4
hw/core/numa.c | 13 +++--
2 files changed, 15 insertions(+), 2 deletions(-)
--
2.23.0
e
map completely or parse it properly by following the device-tree
specification.
This introduces an extra parameter to the exiting function
complete_init_numa_distance() to generate the default distance
map when no node pair distances are provided by user.
Signed-off-by: Gavin Shan
---
hw/core/numa.
NUMA nodes to avoid the error, so that QEMU can be
started successfully.
Signed-off-by: Gavin Shan
Reviewed-by: Andrew Jones
---
hw/arm/boot.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index 57efb61ee4..4e5898fcdc 100644
--- a/hw/arm/boot.c
+++ b/h
Hi Igor,
On 10/12/21 8:40 PM, Igor Mammedov wrote:
On Wed, 6 Oct 2021 18:22:08 +0800
Gavin Shan wrote:
The following option is used to specify the distance map. It's
possible the option isn't provided by user. In this case, the
distance map isn't populated and exposed to p
Hi Drew and Igor,
On 10/13/21 12:05 AM, Andrew Jones wrote:
On Tue, Oct 12, 2021 at 02:34:30PM +0200, Igor Mammedov wrote:
On Tue, 12 Oct 2021 13:48:02 +0200
On Tue, Oct 12, 2021 at 09:31:55PM +1100, Gavin Shan wrote:
On 10/12/21 8:40 PM, Igor Mammedov wrote:
On Wed, 6 Oct 2021 18:22:08
:
On Wed, 6 Oct 2021 18:22:08 +0800
Gavin Shan wrote:
The following option is used to specify the distance map. It's
possible the option isn't provided by user. In this case, the
distance map isn't populated and exposed to platform. On the
other hand, the empty NUMA node,
tance map won't
be generated any more(Igor/Drew)
v2:
* Amend PATCH[01/02]'s changelog to explain why we needn't
switch to disable generating the default distance map(Drew)
Gavin Shan (2):
numa: Require distance map when e
NUMA nodes to avoid the error, so that QEMU can be
started successfully.
Signed-off-by: Gavin Shan
Reviewed-by: Andrew Jones
---
hw/arm/boot.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index 57efb61ee4..4e5898fcdc 100644
--- a/hw/arm/boot.c
+++ b/h
ter the machine is initialized, to
ask for the distance map from user when empty nodes exist in
device-tree.
Signed-off-by: Gavin Shan
---
hw/core/machine.c | 4
hw/core/numa.c| 24
include/sysemu/numa.h | 1 +
3 files changed, 29 insertions(+)
diff --git
:
On Wed, 13 Oct 2021 13:35:44 +0200
Andrew Jones wrote:
On Wed, Oct 13, 2021 at 01:30:11PM +0200, Igor Mammedov wrote:
On Wed, 13 Oct 2021 12:58:04 +0800
Gavin Shan wrote:
The following option is used to specify the distance map. It's
possible the option isn't provided b
far, it's pointless to expose the empty NUMA nodes through device-tree.
So this simply skips populating the device-tree nodes for these empty
NUMA nodes to avoid the error, so that QEMU can be started successfully.
Signed-off-by: Gavin Shan
---
v4: Drop patch to enforce distance-map as memory
Hi Drew,
On 10/15/21 7:33 PM, Andrew Jones wrote:
On Fri, Oct 15, 2021 at 07:22:05PM +1100, Gavin Shan wrote:
It's possible that the empty NUMA nodes aren't referred by any CPUs,
as the following command line indicate. In this case, the empty NUMA
node IDs aren't existing in
Signed-off-by: Gavin Shan
---
v5: Improved commit log and comments as Drew suggested.
---
hw/arm/boot.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index 57efb61ee4..74ad397b1f 100644
--- a/hw/arm/boot.c
+++ b/hw/arm/boot.c
@@ -599,10 +599,23 @@ i
On 10/15/21 11:22 PM, Andrew Jones wrote:
On Fri, Oct 15, 2021 at 06:49:09PM +0800, Gavin Shan wrote:
The empty NUMA node, where no memory resides, are allowed. For
example, the following command line specifies two empty NUMA nodes.
With this, QEMU fails to boot because of the conflicting
Hi Igor,
On 3/30/22 8:52 PM, Igor Mammedov wrote:
On Sat, 26 Mar 2022 03:08:19 +0800
Gavin Shan wrote:
On 3/25/22 10:00 PM, Igor Mammedov wrote:
On Wed, 23 Mar 2022 15:24:38 +0800
Gavin Shan wrote:
The value of the following field has been used in ACPI PPTT table
to identify the
Hi Igor,
On 3/30/22 8:50 PM, Igor Mammedov wrote:
On Sat, 26 Mar 2022 02:49:59 +0800
Gavin Shan wrote:
On 3/25/22 9:19 PM, Igor Mammedov wrote:
On Wed, 23 Mar 2022 15:24:35 +0800
Gavin Shan wrote:
Currently, the SMP configuration isn't considered when the CPU
topology is populated. In
Hi Igor,
On 3/30/22 9:18 PM, Igor Mammedov wrote:
On Wed, 23 Mar 2022 15:24:35 +0800
Gavin Shan wrote:
Currently, the SMP configuration isn't considered when the CPU
topology is populated. In this case, it's impossible to provide
the default CPU-to-NUMA mapping or association ba
lated. The die ID for the given CPU isn't assigned since
it's not supported on arm/virt machine yet. Besides, the cluster
ID for the given CPU is assigned because it has been supported
on arm/virt machine.
Signed-off-by: Gavin Shan
---
hw/arm/virt.c | 15 ++-
qapi/machine
Igor)
* Added PATCH[2/3] to use the existing CPU topology when the
PPTT table is built(Igor)
* Added PATCH[3/3] to take thread ID as ACPI processor ID
in MADT and SRAT table (Gavin)
Gavin Shan (3):
hw/ar
the only user of build_pptt() is
arm/virt machine.
Signed-off-by: Gavin Shan
---
hw/acpi/aml-build.c | 95 +
1 file changed, 71 insertions(+), 24 deletions(-)
diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
index 4086879ebf..8f02d77375 100644
e associated with NODE#0/1, but
there are no CPUs associated with NODE#2/3/4/5.
Signed-off-by: Gavin Shan
Reviewed-by: Igor Mammedov
---
hw/arm/virt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index f628e86f78..558bd59e8b 100644
--- a/
Hi Yanan,
On 4/2/22 10:17 AM, wangyanan (Y) wrote:
On 2022/3/23 15:24, Gavin Shan wrote:
Currently, the SMP configuration isn't considered when the CPU
topology is populated. In this case, it's impossible to provide
the default CPU-to-NUMA mapping or association based on the socket
Hi Yanan,
On 4/2/22 10:02 AM, wangyanan (Y) wrote:
On 2022/3/23 15:24, Gavin Shan wrote:
When CPU-to-NUMA association isn't explicitly provided by users,
the default on is given by mc->get_default_cpu_node_id(). However,
s/on/one
Will be corrected in v5.
the CPU topology isn
Hi Igor and Yanan,
On 4/3/22 7:00 PM, Gavin Shan wrote:
When the CPU-to-NUMA association isn't provided by user, the default NUMA
node ID for the specific CPU is returned from virt_get_default_cpu_node_id().
Unfortunately, the default NUMA node ID breaks socket boundary and leads to
the b
Hi Igor,
On 3/30/22 10:10 PM, Igor Mammedov wrote:
On Wed, 23 Mar 2022 15:24:37 +0800
Gavin Shan wrote:
When the PPTT table is built, the CPU topology is re-calculated, but
it's unecessary because the CPU topology has been populated in
virt_possible_cpu_arch_ids() on arm/virt machine.
reused in virt_get_default_cpu_node_id() (Igor)
* Added PATCH[2/3] to use the existing CPU topology when the
PPTT table is built(Igor)
* Added PATCH[3/3] to take thread ID as ACPI processor ID
in MADT and SRAT table
::machine_numa_finish_cpu_init() to associate
CPU with NUMA node when no default association isn't provided.
* hw/core/machine-hmp-cmds.c::hmp_hotpluggable_cpus() to dump
cluster-id.
Signed-off-by: Gavin Shan
---
hw/core/machine-hmp-cmds.c | 4
hw/core/machine.c | 16
e associated with NODE#0/1, but
there are no CPUs associated with NODE#2/3/4/5.
Signed-off-by: Gavin Shan
Reviewed-by: Igor Mammedov
Reviewed-by: Yanan Wang
---
hw/arm/virt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 3174526730..d8b6
lated. The die ID for the given CPU isn't assigned since
it's not supported on arm/virt machine yet.
Signed-off-by: Gavin Shan
---
hw/arm/virt.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index d2e5ecd234..3174526730
user of build_pptt() is
arm/virt machine.
Signed-off-by: Gavin Shan
---
hw/acpi/aml-build.c | 100 +---
1 file changed, 38 insertions(+), 62 deletions(-)
diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
index 4086879ebf..4b0f9df3e3 100644
--- a/hw/
Hi Daniel,
On 4/4/22 4:40 PM, Daniel P. Berrangé wrote:
On Mon, Apr 04, 2022 at 09:37:10AM +0100, Daniel P. Berrangé wrote:
On Sun, Apr 03, 2022 at 10:59:50PM +0800, Gavin Shan wrote:
This adds cluster-id in CPU instance properties, which will be used
by arm/virt machine. Besides, the cluster
Hi Daniel,
On 4/4/22 4:39 PM, Daniel P. Berrangé wrote:
On Sun, Apr 03, 2022 at 10:59:51PM +0800, Gavin Shan wrote:
Currently, the SMP configuration isn't considered when the CPU
topology is populated. In this case, it's impossible to provide
the default CPU-to-NUMA mapping or a
Hi Igor and Yanan,
On 4/3/22 10:59 PM, Gavin Shan wrote:
When the CPU-to-NUMA association isn't provided by user, the default NUMA
node ID for the specific CPU is returned from virt_get_default_cpu_node_id().
Unfortunately, the default NUMA node ID breaks socket boundary and leads to
the b
e. So the old direct addressing mechanism and new
indirect addressing mechanism can co-exist and interchangeable,
even in migration circumstance.
Signed-off-by: Gavin Shan
---
target/arm/cpu.h| 12 ++--
target/arm/helper.c | 27 +++
2 files changed, 29 inserti
t addressing mode. Each coprocessor register
is still having 8 bytes fixed storage space, so that thd old mechanism
(direct addressing mode) and indirect address mode can co-exist, event in
migration circumstance. PATCH[4] migrates the additional array. PATCH[5]
initializes @cpreg_value_indexes for KVM
circumstance.
Signed-off-by: Gavin Shan
---
target/arm/hvf/hvf.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/target/arm/hvf/hvf.c b/target/arm/hvf/hvf.c
index 8c34f86792..8cca26a59c 100644
--- a/target/arm/hvf/hvf.c
+++ b/target/arm/hvf/hvf.c
circumstance.
Signed-off-by: Gavin Shan
---
target/arm/kvm.c | 34 --
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/target/arm/kvm.c b/target/arm/kvm.c
index bbf1ce7ba3..5d1ce431b0 100644
--- a/target/arm/kvm.c
+++ b/target/arm/kvm.c
@@ -429,12
This migrates @cpreg_value_array_len and @cpreg_value_indexes, which
are used to indirectly addressing the storage space for the corresponding
coprocessor register.
Signed-off-by: Gavin Shan
---
target/arm/machine.c | 30 --
1 file changed, 24 insertions(+), 6
are less than 8 bytes, we always
reserve 8 bytes storage space for it, to gurantee the storage
space address is aligned to 8 bytes. On the other hand, the storage
space size for other registers are allocated based on their sizes.
Signed-off-by: Gavin Shan
---
target/arm/kvm.c | 55
Hi Peter,
On 4/11/22 5:22 PM, Peter Maydell wrote:
On Mon, 11 Apr 2022 at 07:59, Gavin Shan wrote:
There are two arrays for each CPU, to store the indexes and values of the
coprocessor registers. Currently, 8 bytes fixed storage space is reserved
for each coprocessor register. However
Hi Peter,
On 4/11/22 6:05 PM, Peter Maydell wrote:
On Mon, 11 Apr 2022 at 10:50, Gavin Shan wrote:
On 4/11/22 5:22 PM, Peter Maydell wrote:
So, can you give an example of coprocessor registers which are
not 8 bytes in size? How are they accessed by the guest?
If we need to support them then
Hi Drew,
On 4/11/22 8:02 PM, Andrew Jones wrote:
On Mon, Apr 11, 2022 at 10:22:59AM +0100, Peter Maydell wrote:
On Mon, 11 Apr 2022 at 07:59, Gavin Shan wrote:
There are two arrays for each CPU, to store the indexes and values of the
coprocessor registers. Currently, 8 bytes fixed storage
Hi Jonathan,
On 4/12/22 11:40 PM, Jonathan Cameron wrote:
On Sun, 3 Apr 2022 22:59:53 +0800
Gavin Shan wrote:
When the PPTT table is built, the CPU topology is re-calculated, but
it's unecessary because the CPU topology has been populated in
virt_possible_cpu_arch_ids() on arm/virt ma
Hi Peter,
On 4/11/22 8:10 PM, Peter Maydell wrote:
On Mon, 11 Apr 2022 at 13:02, Andrew Jones wrote:
On Mon, Apr 11, 2022 at 10:22:59AM +0100, Peter Maydell wrote:
Also, we support SVE today, and we don't have variable size
coprocessor registers. Is there a bug here that we would be
fixing ?
Hi Yanan,
On 4/13/22 7:49 PM, wangyanan (Y) wrote:
On 2022/4/3 22:59, Gavin Shan wrote:
This adds cluster-id in CPU instance properties, which will be used
by arm/virt machine. Besides, the cluster-id is also verified or
dumped in various spots:
* hw/core/machine.c
Hi Yanan,
On 4/13/22 8:39 PM, wangyanan (Y) wrote:
On 2022/4/3 22:59, Gavin Shan wrote:
Currently, the SMP configuration isn't considered when the CPU
topology is populated. In this case, it's impossible to provide
the default CPU-to-NUMA mapping or association based on the socket
Hi Igor,
On 4/13/22 9:52 PM, Igor Mammedov wrote:
On Sun, 3 Apr 2022 22:59:53 +0800
Gavin Shan wrote:
When the PPTT table is built, the CPU topology is re-calculated, but
it's unecessary because the CPU topology has been populated in
virt_possible_cpu_arch_ids() on arm/virt machine.
Hi Yanan,
On 4/14/22 10:27 AM, wangyanan (Y) wrote:
On 2022/4/14 8:08, Gavin Shan wrote:
On 4/13/22 8:39 PM, wangyanan (Y) wrote:
On 2022/4/3 22:59, Gavin Shan wrote:
Currently, the SMP configuration isn't considered when the CPU
topology is populated. In this case, it's imp
Hi Yanan,
On 4/14/22 10:49 AM, wangyanan (Y) wrote:
On 2022/4/14 10:37, Gavin Shan wrote:
On 4/14/22 10:27 AM, wangyanan (Y) wrote:
On 2022/4/14 8:08, Gavin Shan wrote:
On 4/13/22 8:39 PM, wangyanan (Y) wrote:
On 2022/4/3 22:59, Gavin Shan wrote:
Currently, the SMP configuration isn&#
Hi Yanan,
On 4/14/22 10:56 AM, wangyanan (Y) wrote:
On 2022/4/14 8:33, Gavin Shan wrote:
On 4/13/22 9:52 PM, Igor Mammedov wrote:
On Sun, 3 Apr 2022 22:59:53 +0800
Gavin Shan wrote:
When the PPTT table is built, the CPU topology is re-calculated, but
it's unecessary because th
Hi Yanan,
On 4/14/22 11:09 AM, wangyanan (Y) wrote:
On 2022/4/3 22:59, Gavin Shan wrote:
When the PPTT table is built, the CPU topology is re-calculated, but
it's unecessary because the CPU topology has been populated in
virt_possible_cpu_arch_ids() on arm/virt machine.
This re
Hi Yanan,
On 4/14/22 10:27 AM, wangyanan (Y) wrote:
On 2022/4/14 8:06, Gavin Shan wrote:
On 4/13/22 7:49 PM, wangyanan (Y) wrote:
On 2022/4/3 22:59, Gavin Shan wrote:
This adds cluster-id in CPU instance properties, which will be used
by arm/virt machine. Besides, the cluster-id is also
Hi Yanan,
On 4/14/22 5:29 PM, wangyanan (Y) wrote:
On 2022/4/14 15:35, Gavin Shan wrote:
On 4/14/22 10:49 AM, wangyanan (Y) wrote:
On 2022/4/14 10:37, Gavin Shan wrote:
On 4/14/22 10:27 AM, wangyanan (Y) wrote:
On 2022/4/14 8:08, Gavin Shan wrote:
On 4/13/22 8:39 PM, wangyanan (Y) wrote
Hi Jonathan,
On 4/14/22 5:33 PM, Jonathan Cameron wrote:
On Thu, 14 Apr 2022 15:35:41 +0800
Gavin Shan wrote:
On 4/14/22 10:49 AM, wangyanan (Y) wrote:
On 2022/4/14 10:37, Gavin Shan wrote:
On 4/14/22 10:27 AM, wangyanan (Y) wrote:
On 2022/4/14 8:08, Gavin Shan wrote:
On 4/13/22 8:39 PM
Hi Eric,
On 8/24/22 6:06 PM, Eric Auger wrote:
On 8/24/22 05:29, Gavin Shan wrote:
On 8/15/22 4:29 PM, 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
On 8/27/22 6:22 PM, Paolo Bonzini wrote:
The KVM_DIRTY_GFN_F_DIRTY flag ensures that the entry is valid. If
the read of the fields are not ordered after the read of the flag,
QEMU might see stale values.
Cc: Peter Xu
Cc: Gavin Shan
Signed-off-by: Paolo Bonzini
---
accel/kvm/kvm-all.c | 6
scenario
CPU1 must read the correct value of gfn2's fields.
Therefore RESET must be set with a store-release, that will synchronize
with KVM's load-acquire in CPU1.
Cc: Gavin Shan
Cc: Peter Xu
Signed-off-by: Paolo Bonzini
---
accel/kvm/kvm-all.c | 18 +-
1 file chan
c)
* Use 'bool fits' in virt_set_high_memmap() (Eric)
Gavin Shan (5):
hw/arm/virt: Introduce virt_set_high_memmap() helper
hw/arm/virt: Rename variable size to region_size in
virt_set_high_memmap()
hw/arm/virt: Introduce variable region_base in virt_set_high_me
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
---
hw/arm/virt.c | 15 ---
1 file changed, 8 inser
n disabled in case (1), (2) and (3).
Signed-off-by: Gavin Shan
---
hw/arm/virt.c | 44 ++--
1 file changed, 26 insertions(+), 18 deletions(-)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index b0b679d1f4..b702f8f2b5 100644
--- a/hw/arm/virt.c
+++
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
---
hw/arm
on machines, which is virt-7.1 or ealier than it. It
means the optimization is enabled by default from virt-7.2. Besides,
'highmem-compact' property is added so that the optimization can be
explicitly enabled or disabled on all machine types by users.
Signed-off-by: Gavin Shan
---
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
---
hw/arm/virt.c | 12 ++--
1
On 10/12/22 12:45 AM, Eric Auger wrote:
On 10/5/22 00:47, Gavin Shan wrote:
On 10/4/22 6:41 PM, Cornelia Huck wrote:
On Tue, Oct 04 2022, Gavin Shan wrote:
This introduces virt_get_high_memmap_enabled() helper, which returns
the pointer to vms->highmem_{redists, ecam, mmio}. The poin
#x27;highmem-compact' property for backwards compatibility (Eric)
v2:
* Split the patches for easier review(Gavin)
* Improved changelog (Marc)
* Use 'bool fits' in virt_set_high_memmap() (Eric)
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 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
s added so that the optimization can be
explicitly enabled or disabled on all machine types by users.
Signed-off-by: Gavin Shan
Tested-by: Zhenyu Zhang
---
docs/system/arm/virt.rst | 4
hw/arm/virt.c| 47
include/hw/arm/virt.h| 1 +
501 - 600 of 1041 matches
Mail list logo
