. 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.json | 6 --
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/arm/virt: Consider SMP conf
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 based
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
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
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 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 based
nly 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
--- a
DE#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/virt.c
@@ -2497,7 +
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.
. 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 | 6 --
2 files
ing 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 configuration in
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 c
ed, 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/hw/arm/virt.c b/hw/a
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
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 broken CPU
Hi Gerd,
On 3/1/22 7:42 PM, Gerd Hoffmann wrote:
Unless it architecturally wrong thing i.e. (node size less than 128Mb)
,in which case limiting it in QEMU would be justified, I'd prefer
firmware being fixed or it reporting more useful for user error message.
[include EDK2 developers]
I don't
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.
Linux guest. The 6 CPUs are 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 | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 46bf7ceddf..dee02b60fc
->possible_cpus. However, the cluster ID for the CPU instance
has to be calculated dynamically because there is no corresponding
field in struct CpuInstanceProperties. Currently, the only user of
build_pptt() is arm/virt machine.
Signed-off-by: Gavin Shan
---
hw/acpi/aml-build.c |
(Gavin)
Gavin Shan (3):
hw/arm/virt: Fix CPU's default NUMA node ID
hw/acpi/aml-build: Use existing CPU topology to build PPTT table
hw/arm/virt: Unify ACPI processor ID in MADT and SRAT table
hw/acpi/aml-build.c | 106
Hi Igor,
On 2/28/22 5:08 PM, Igor Mammedov wrote:
On Mon, 28 Feb 2022 15:52:03 +0800
Gavin Shan wrote:
When the memory size on the first NUMA node is less than 128MB, the
guest hangs inside EDK2 as the following logs show.
/home/gavin/sandbox/qemu.main/build/qemu-system-aarch64
Hi Igor,
On 2/28/22 6:54 PM, Igor Mammedov wrote:
On Mon, 28 Feb 2022 12:26:53 +0800
Gavin Shan wrote:
On 2/25/22 6:03 PM, Igor Mammedov wrote:
On Fri, 25 Feb 2022 16:41:43 +0800
Gavin Shan wrote:
On 2/17/22 10:14 AM, Gavin Shan wrote:
On 1/26/22 5:14 PM, Igor Mammedov wrote:
On Wed, 26
son is given for this specific case.
Signed-off-by: Gavin Shan
---
hw/arm/virt.c | 9 +
hw/core/numa.c | 5 +
include/hw/boards.h | 1 +
3 files changed, 15 insertions(+)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 46bf7ceddf..234e7fca28 100644
--- a/hw/arm/virt.c
+++ b
Hi Igor,
On 2/25/22 6:03 PM, Igor Mammedov wrote:
On Fri, 25 Feb 2022 16:41:43 +0800
Gavin Shan wrote:
On 2/17/22 10:14 AM, Gavin Shan wrote:
On 1/26/22 5:14 PM, Igor Mammedov wrote:
On Wed, 26 Jan 2022 13:24:10 +0800
Gavin Shan wrote:
The default CPU-to-NUMA association is given by mc
Hi Igor,
On 2/17/22 10:14 AM, Gavin Shan wrote:
On 1/26/22 5:14 PM, Igor Mammedov wrote:
On Wed, 26 Jan 2022 13:24:10 +0800
Gavin Shan wrote:
The default CPU-to-NUMA association is given by mc->get_default_cpu_node_id()
when it isn't provided explicitly. However, the CPU topology is
On 1/26/22 5:14 PM, Igor Mammedov wrote:
On Wed, 26 Jan 2022 13:24:10 +0800
Gavin Shan wrote:
The default CPU-to-NUMA association is given by mc->get_default_cpu_node_id()
when it isn't provided explicitly. However, the CPU topology isn't fully
considered in the default associat
On 2/15/22 4:32 PM, Andrew Jones wrote:
On Tue, Feb 15, 2022 at 04:19:01PM +0800, Gavin Shan wrote:
The issue isn't related to CPU topology directly. It's actually related
to the fact: the default NUMA node ID will be picked for one particular
CPU if the associated NUMA node ID isn't provided
On 1/28/22 3:05 PM, wangyanan (Y) via wrote
On 2022/1/26 17:14, Igor Mammedov wrote:
On Wed, 26 Jan 2022 13:24:10 +0800
Gavin Shan wrote:
The default CPU-to-NUMA association is given by mc->get_default_cpu_node_id()
when it isn't provided explicitly. However, the CPU topology isn't fu
ed-off-by: Gavin Shan
---
hw/arm/virt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 141350bf21..b4a95522d3 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -2499,7 +2499,7 @@ virt_cpu_index_to_props(MachineState *ms, unsigned
cpu_index)
denbrand
Signed-off-by: Gavin Shan
Reviewed-by: Jonathan Cameron
Reviewed-by: David Hildenbrand
---
hw/virtio/virtio-mem.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/hw/virtio/virtio-mem.c b/hw/virtio/virtio-mem.c
index 04c223b0c9..1ca453
-developed-by: Jonathan Cameron
Signed-off-by: Gavin Shan
Reviewed-by: Jonathan Cameron
Reviewed-by: David Hildenbrand
---
hw/arm/Kconfig | 1 +
hw/arm/virt.c | 70 ++
hw/virtio/virtio-mem.c | 4 ++-
3 files changed, 74 insertions(+), 1 deletio
on ARM64 in PATCH[1/2] (David)
* PATCH[2/2] is added to correct the THP sizes on ARM64 (David)
Gavin Shan (2):
virtio-mem: Correct default THP size for ARM64
hw/arm/virt: Support for virtio-mem-pci
hw/arm/Kconfig | 1 +
hw/arm/virt.c | 70
Hi Peter,
On 1/8/22 12:40 AM, Peter Maydell wrote:
On Fri, 3 Dec 2021 at 23:34, Gavin Shan wrote:
This supports virtio-mem-pci device on "virt" platform, by simply
following the implementation on x86.
* This implements the hotplug handlers to support virtio-mem-pci
devi
On 12/4/21 5:16 AM, David Hildenbrand wrote:
On 03.12.21 04:35, Gavin Shan wrote:
The default block size is same as to the THP size, which is either
retrieved from "/sys/kernel/mm/transparent_hugepage/hpage_pmd_size"
or hardcoded to 2MB. There are flaws in both mechanisms and th
denbrand
Signed-off-by: Gavin Shan
Reviewed-by: Jonathan Cameron
Reviewed-by: David Hildenbrand
---
hw/virtio/virtio-mem.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/hw/virtio/virtio-mem.c b/hw/virtio/virtio-mem.c
index d5a578142b..b20595
on ARM64 (David)
Gavin Shan (2):
virtio-mem: Correct default THP size for ARM64
hw/arm/virt: Support for virtio-mem-pci
hw/arm/Kconfig | 1 +
hw/arm/virt.c | 68 +-
hw/virtio/virtio-mem.c | 36 ++
3
-developed-by: Jonathan Cameron
Signed-off-by: Gavin Shan
Reviewed-by: Jonathan Cameron
Reviewed-by: David Hildenbrand
---
hw/arm/Kconfig | 1 +
hw/arm/virt.c | 68 +-
hw/virtio/virtio-mem.c | 4 ++-
3 files changed, 71 insertions(+), 2 deletion
On 12/4/21 5:18 AM, David Hildenbrand wrote:
On 03.12.21 04:35, Gavin Shan wrote:
This supports virtio-mem-pci device on "virt" platform, by simply
following the implementation on x86.
* This implements the hotplug handlers to support virtio-mem-pci
device hot-add, whi
Hi Jonathan,
On 12/4/21 1:10 AM, Jonathan Cameron wrote:
On Fri, 3 Dec 2021 11:35:20 +0800
Gavin Shan wrote:
This series supports virtio-mem-pci device, by simply following the
implementation on x86. The exception is the block size is 512MB on
ARM64 instead of 128MB on x86, compatible
On 12/1/21 8:03 PM, David Hildenbrand wrote:
* It has been passing the tests with various combinations like 64KB
and 4KB page sizes on host and guest, different memory device
backends like normal, transparent huge page and HugeTLB, plus
migration.
Perfect. A note
denbrand
Signed-off-by: Gavin Shan
---
hw/virtio/virtio-mem.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/hw/virtio/virtio-mem.c b/hw/virtio/virtio-mem.c
index ac7a40f514..8f3c95300f 100644
--- a/hw/virtio/virtio-mem.c
+++ b/hw/virtio/vi
-developed-by: Jonathan Cameron
Signed-off-by: Gavin Shan
---
hw/arm/Kconfig | 1 +
hw/arm/virt.c | 68 +-
hw/virtio/virtio-mem.c | 4 ++-
3 files changed, 71 insertions(+), 2 deletions(-)
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index
] (David)
* PATCH[2/2] is added to correct the THP sizes on ARM64 (David)
Gavin Shan (2):
hw/arm/virt: Support for virtio-mem-pci
virtio-mem: Correct default THP size for ARM64
hw/arm/Kconfig | 1 +
hw/arm/virt.c | 68
On 11/30/21 8:37 PM, David Hildenbrand wrote:
On 30.11.21 01:33, Gavin Shan wrote:
This supports virtio-mem-pci device on "virt" platform, by simply
following the implementation on x86.
Thanks for picking this up!
Thanks, David.
* The patch was written by David H
huge page and HugeTLB, plus
migration.
Signed-off-by: Gavin Shan
---
hw/arm/Kconfig | 1 +
hw/arm/virt.c | 68 +-
hw/virtio/virtio-mem.c | 2 ++
3 files changed, 70 insertions(+), 1 deletion(-)
diff --git a/hw/arm/Kconfig b/hw/arm/Kco
-vm1 requested-size 0
(qemu) qom-set hp-vm1 requested-size 512M
Gavin Shan (1):
hw/arm/virt: Support for virtio-mem-pci
hw/arm/Kconfig | 1 +
hw/arm/virt.c | 68 +-
hw/virtio/virtio-mem.c | 2 ++
3 files changed, 70 insertions(+), 1
Hi Drew and Igor,
On 11/2/21 6:39 PM, Andrew Jones wrote:
On Tue, Nov 02, 2021 at 10:44:08AM +1100, Gavin Shan wrote:
Yeah, I agree. I don't have strong sense to expose these empty nodes
for now. Please ignore the patch.
So were describing empty numa nodes on the command line ever
On 11/1/21 7:44 PM, Igor Mammedov wrote:
On Thu, 28 Oct 2021 22:32:09 +1100
Gavin Shan wrote:
On 10/28/21 2:40 AM, Igor Mammedov wrote:
On Wed, 27 Oct 2021 13:29:58 +0800
Gavin Shan wrote:
The empty NUMA nodes, where no memory resides, aren't exposed
through ACPI SRAT table. It's
On 10/28/21 2:40 AM, Igor Mammedov wrote:
On Wed, 27 Oct 2021 13:29:58 +0800
Gavin Shan wrote:
The empty NUMA nodes, where no memory resides, aren't exposed
through ACPI SRAT table. It's not user preferred behaviour because
the corresponding memory node devices are missed from the guest
:0 kB
(qemu) object_add memory-backend-ram,id=hp-mem0,size=1G
(qemu) device_add pc-dimm,id=hp-dimm0,node=3,memdev=hp-mem0
guest# cat /sys/devices/system/node/node3/meminfo | grep MemTotal
Node 3 MemTotal:1048576 kB
Signed-off-by: Gavin Shan
Reviewed-by: Andrew Jones
---
v2: Improved
On 10/26/21 8:47 PM, Igor Mammedov wrote:
On Tue, 26 Oct 2021 07:41:01 +0800
Gavin Shan wrote:
The empty NUMA nodes, where no memory resides, aren't exposed
through ACPI SRAT table. It's not user preferred behaviour because
the corresponding memory node devices are missed from the guest
On 10/26/21 5:25 PM, Andrew Jones wrote:
On Tue, Oct 26, 2021 at 07:41:01AM +0800, Gavin Shan wrote:
The empty NUMA nodes, where no memory resides, aren't exposed
through ACPI SRAT table. It's not user preferred behaviour because
the corresponding memory node devices are missed from the guest
to these empty NUMA nodes for sake of completeness.
guest# ls /sys/devices/system/node | grep node
node0
node1
node2
node3
Signed-off-by: Gavin Shan
---
hw/arm/virt-acpi-build.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/hw/arm/virt-acpi-build.c b/hw
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
-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 @@ int arm_load_dtb
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 device-tree CPU
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 hotplug through
:
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 by user
nitialized, 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 a/hw/core/machine.c
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/hw/arm
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 empty node exists
hw/arm/virt
:
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, where no memory
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
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 platform
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/hw/arm
t 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.c | 13 +++--
1 file c
)
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
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
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 option
Hi Drew,
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 option isn't provided by user. In this case, the
distance map isn't populated and exposed to platform
o generate
the default distance map, where the local and remote distances
are 10 and 20 separately. This adds an extra parameter to the
exiting complete_init_numa_distance() to generate the default
distance map for this case.
Signed-off-by: Gavin Shan
---
hw/core/numa.c | 13 +++--
1 fi
aren't created for the empty NUMA nodes, but their
NUMA IDs and distance map matrix should be included in the distance-map
device-tree node.
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
nodes to avoid the error, so that QEMU can be
started successfully.
Signed-off-by: Gavin Shan
---
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/hw/arm/boot.c
@@ -603,6 +603,10
On 6/23/21 6:16 PM, Andrew Jones wrote:
On Wed, Jun 23, 2021 at 10:07:36AM +0200, Andrew Jones wrote:
On Wed, Jun 23, 2021 at 02:43:49PM +1000, Gavin Shan wrote:
On 6/22/21 5:13 PM, Andrew Jones wrote:
On Tue, Jun 22, 2021 at 06:53:41PM +1000, Gavin Shan wrote:
On 6/3/21 2:48 PM, Gavin Shan
Hi Drew,
On 6/22/21 5:13 PM, Andrew Jones wrote:
On Tue, Jun 22, 2021 at 06:53:41PM +1000, Gavin Shan wrote:
On 6/3/21 2:48 PM, Gavin Shan wrote:
On 6/2/21 9:36 PM, Andrew Jones wrote:
On Wed, Jun 02, 2021 at 11:09:32AM +1000, Gavin Shan wrote:
On 6/1/21 5:50 PM, Andrew Jones wrote:
On Tue
Hi Drew,
On 6/3/21 2:48 PM, Gavin Shan wrote:
On 6/2/21 9:36 PM, Andrew Jones wrote:
On Wed, Jun 02, 2021 at 11:09:32AM +1000, Gavin Shan wrote:
On 6/1/21 5:50 PM, Andrew Jones wrote:
On Tue, Jun 01, 2021 at 03:30:04PM +0800, Gavin Shan wrote:
We possibly populate empty nodes where memory
Hi Drew,
On 6/2/21 9:36 PM, Andrew Jones wrote:
On Wed, Jun 02, 2021 at 11:09:32AM +1000, Gavin Shan wrote:
On 6/1/21 5:50 PM, Andrew Jones wrote:
On Tue, Jun 01, 2021 at 03:30:04PM +0800, Gavin Shan wrote:
We possibly populate empty nodes where memory isn't included and might
be hot added
Hi Drew,
On 6/1/21 5:50 PM, Andrew Jones wrote:
On Tue, Jun 01, 2021 at 03:30:04PM +0800, Gavin Shan wrote:
We possibly populate empty nodes where memory isn't included and might
be hot added at late time. The FDT memory nodes can't be created due
to conflicts on their names if multiple empty
names. With this applied, the
VM can boot successfully with above command lines.
Signed-off-by: Gavin Shan
---
hw/arm/boot.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index d7b059225e..3169bdf595 100644
--- a/hw/arm/boot.c
+++ b/hw/arm
Hi Peter,
On 4/7/21 5:38 PM, Peter Maydell wrote:
On Wed, 7 Apr 2021 at 03:01, Gavin Shan wrote:
If the scratch vCPU is initialized without PMU feature, we receive
error on reading PMCR_EL0 as it's invisible in this case. It leads
to host probing failure.
This fixes the issue
is set according to the detected target.
Fixes: f7fb73b8cdd3 ("target/arm: Make number of counters in PMCR follow the
CPU")
Signed-off-by: Gavin Shan
---
target/arm/kvm64.c | 32 +++-
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/target/arm
@init->target is always -1 and preferred target is retrieved from
host when @init isn't NULL in kvm_arm_create_scratch_host_vcpu().
So we can have the assumption that preferred target retrived from
host is tried prior to the specified target list.
Signed-off-by: Gavin Shan
---
target/arm/kv
Hi Richard,
On 3/23/21 7:59 AM, Richard Henderson wrote:
On 3/22/21 4:54 AM, Gavin Shan wrote:
It looks this issue can be avoided after "volatile" is applied to
@target_page. However, I'm not sure if it's the correct fix to have.
Certainly not.
That is the exact opposite of wh
value
of TARGET_PAGE_BITS_MIN.
Reported-by: Gavin Shan
Signed-off-by: Richard Henderson
---
configure| 19 ---
meson.build | 18 ++-
include/exec/cpu-all.h | 15 ++
include/exec/page-vary.h | 34
exec-vary.c | 108
Hi Richard and Paolo,
On 3/22/21 5:23 AM, Richard Henderson wrote:
On 3/21/21 11:46 AM, Paolo Bonzini wrote:
HRM, what about biting the bullet and making exec-vary.c a C++ source?... Then
instead of making it conditional an attribute((alias)), we make it conditional
on having a C++ compiler.
s disabled
for the cross-compiling case as the compiled binary isn't executable.
Signed-off-by: Gavin Shan
---
v2: Disable gcc alias attribute for cross-compiling case.
Return 0 on success from test program.
Wrap lines of test program and improved commit log.
---
conf
Hi Paolo and Richard,
On 3/21/21 9:33 AM, Richard Henderson wrote:
On 3/20/21 11:52 AM, Paolo Bonzini wrote:
+int main(void)
+{
+ return read_y();
+}
I think this should be "read_y() == 1 ? 0 : 1".
As a testcase returning 0 on success, yes.
Ok. I will include the changes in v2. Also,
Hi Thomas,
On 3/20/21 3:48 PM, Thomas Huth wrote:
On 20/03/2021 05.27, Gavin Shan wrote:
It's still possible that the wrong value is returned from the alias
of variable even if the program can be compiled without issue. This
improves the check by executing the binary to check the result
zeroes when we have the following gcc
version.
# gcc --version
gcc (GCC) 11.0.0 20210210 (Red Hat 11.0.0-0)
This abstracts the code from exec-vary.c and use it as indicator to
enable gcc alias attribute or not.
Signed-off-by: Gavin Shan
---
configure | 34
-a64.cc:20:1: note: ‘extern "C"’ linkage started here
20 | extern "C" {
| ^~~~~~
Signed-off-by: Gavin Shan
---
disas/arm-a64.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/disas/arm-a64.cc b/disas/arm-a64.cc
index 9fa779e175..8545c0403
s: aac63e0e6ea3 ("hw/char/pl011: add a clock input")
Suggested-by: Andrew Jones
Signed-off-by: Gavin Shan
---
hw/char/pl011.c | 9 +
hw/core/machine.c | 1 +
include/hw/char/pl011.h | 1 +
3 files changed, 11 insertions(+)
diff --git a/hw/char/pl011.c b/hw
Hi Drew,
On 3/17/21 11:54 PM, Andrew Jones wrote:
On Wed, Mar 17, 2021 at 11:14:56AM +, Peter Maydell wrote:
On Wed, 17 Mar 2021 at 10:59, Gavin Shan wrote:
On 3/17/21 9:40 PM, Peter Maydell wrote:
On Wed, 17 Mar 2021 at 10:37, Gavin Shan wrote:
On 3/17/21 8:09 PM, Peter Maydell wrote
Hi Peter,
On 3/17/21 9:40 PM, Peter Maydell wrote:
On Wed, 17 Mar 2021 at 10:37, Gavin Shan wrote:
On 3/17/21 8:09 PM, Peter Maydell wrote:
On Wed, 17 Mar 2021 at 04:44, Gavin Shan wrote:
static const VMStateDescription vmstate_pl011 = {
.name = "pl011",
.vers
Hi Peter,
On 3/17/21 8:09 PM, Peter Maydell wrote:
On Wed, 17 Mar 2021 at 04:44, Gavin Shan wrote:
There is a added clock to trace buad rate change since v5.2.0 by
commit aac63e0e6ea3 ("hw/char/pl011: add a clock input"). The added
clock causes migration failure. For example, migr
ub-section to avoid the
migration failure.
Cc: qemu-sta...@nongnu.org
Fixes: aac63e0e6ea3 ("hw/char/pl011: add a clock input")
Signed-off-by: Gavin Shan
---
hw/char/pl011.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/hw/char/pl011.c b/h
On 3/11/20 3:09 PM, Gavin Shan wrote:
The depth of TxFIFO can be 1 or 16 depending on LCR[4]. The TxFIFO is
disabled when its depth is 1. It's nice to have TxFIFO enabled if
possible because more characters can be piled and transmitted at once,
which would have less overhead. Besides, we can
On 3/11/20 3:43 PM, no-re...@patchew.org wrote:
[...]
http://patchew.org/logs/20200311040923.29115-1-gs...@redhat.com/testing.asan/?type=message.
Is it possible to be a false alarm? The detailed errors extracted from above
link is shown as below, and I'm unable to reproduce it at local:
Error
(), which isn't nice.
This enables TxFIFO if possible. On ther other hand, the asynchronous
transmission is enabled if needed, as we did in hw/char/cadence_uart.c
Signed-off-by: Gavin Shan
---
v3: Use PL011() to do data type conversion
Return G_SOURCE_REMOVE when the backend is disconnected
On 3/6/20 10:15 PM, Marc-André Lureau wrote:
On Mon, Feb 24, 2020 at 4:13 AM Gavin Shan wrote:
The depth of TxFIFO can be 1 or 16 depending on LCR[4]. The TxFIFO is
disabled when its depth is 1. It's nice to have TxFIFO enabled if
possible because more characters can be piled and transmitted
601 - 700 of 971 matches
Mail list logo
