[PATCH v2] xen/arm, device-tree: Make static-mem use #{address,size}-cells
In order to keep consistency in the device tree binding, there is
no need for static memory allocation feature to define a specific
set of address and size cells for "xen,static-mem" property.
Therefore, this commit reuses the regular #{address,size}-cells
for parsing the device tree "xen,static-mem" property. Update
the documentation accordingly.
Also, take the chance to remove the unnecessary "#address-cells"
and "#size-cells" in the domU1 node of the device tree to only
emphasize the related part that the example is showing.
Signed-off-by: Henry Wang
---
Changes from v1 to v2:
- Remove the "" addition, as it is unnecessary to this patch.
- Mention the removal of #address-cells and #size-cells in domU1
node in the commit message.
---
docs/misc/arm/device-tree/booting.txt | 11 +--
docs/misc/arm/passthrough-noiommu.txt | 7 +++
xen/arch/arm/bootfdt.c| 5 -
xen/arch/arm/domain_build.c | 16 ++--
4 files changed, 10 insertions(+), 29 deletions(-)
diff --git a/docs/misc/arm/device-tree/booting.txt
b/docs/misc/arm/device-tree/booting.txt
index 5395a1077c..10caf4f1af 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -350,8 +350,8 @@ areas are pre-defined by configuration using physical
address ranges.
Memory can be statically allocated to a domain using the property "xen,static-
mem" defined in the domain configuration. The number of cells for the address
-and the size must be defined using respectively the properties
-"#xen,static-mem-address-cells" and "#xen,static-mem-size-cells".
+and the size must be defined respectively by the parent node properties
+"#address-cells" and "#size-cells".
The property 'memory' is still needed and should match the amount of memory
given to the guest. Currently, it either comes from static memory or lets Xen
@@ -366,14 +366,13 @@ device-tree:
/ {
chosen {
+#address-cells = <0x1>;
+#size-cells = <0x1>;
+...
domU1 {
compatible = "xen,domain";
-#address-cells = <0x2>;
-#size-cells = <0x2>;
cpus = <2>;
memory = <0x0 0x8>;
-#xen,static-mem-address-cells = <0x1>;
-#xen,static-mem-size-cells = <0x1>;
xen,static-mem = <0x3000 0x2000>;
...
};
diff --git a/docs/misc/arm/passthrough-noiommu.txt
b/docs/misc/arm/passthrough-noiommu.txt
index 3e2ef21ad7..69b8de1975 100644
--- a/docs/misc/arm/passthrough-noiommu.txt
+++ b/docs/misc/arm/passthrough-noiommu.txt
@@ -33,14 +33,13 @@ on static allocation in the device-tree:
/ {
chosen {
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+ ...
domU1 {
compatible = "xen,domain";
- #address-cells = <0x2>;
- #size-cells = <0x2>;
cpus = <2>;
memory = <0x0 0x8>;
- #xen,static-mem-address-cells = <0x1>;
- #xen,static-mem-size-cells = <0x1>;
xen,static-mem = <0x3000 0x2000>;
direct-map;
...
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 9e1ea60094..59675f086b 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -370,11 +370,6 @@ static int __init process_domain_node(const void *fdt, int
node,
/* No "xen,static-mem" present. */
return 0;
-address_cells = device_tree_get_u32(fdt, node,
-"#xen,static-mem-address-cells", 0);
-size_cells = device_tree_get_u32(fdt, node,
- "#xen,static-mem-size-cells", 0);
-
return device_tree_get_meminfo(fdt, node, "xen,static-mem", address_cells,
size_cells, _mem,
MEMBANK_STATIC_DOMAIN);
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 7412303d20..9040a8c6cb 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -565,21 +565,9 @@ static int __init parse_static_mem_prop(const struct
dt_device_node *node,
const struct dt_property *prop;
prop = dt_find_property(node, "xen,static-mem", NULL);
-if ( !dt_property_read_u32(node, "#xen,static-mem-address-cells",
- addr_cells) )
-{
-printk(XENLOG_ERR
- "failed to read \"#xen,static-mem-address-cells\".\n");
-return -EINVAL;
-}
-if ( !dt_property_read_u32(node, "#xen,static-mem-size-cells",
- size_cells) )
-{
-printk(XENLOG_ERR
- "failed to read \"#xen,static-mem-size-cells\".\n");
-return -EINVAL;
-
[xen-unstable-smoke test] 173078: tolerable FAIL - PUSHED
flight 173078 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/173078/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a build-amd64-libvirt 6 libvirt-buildfail like 173064 test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen 36e3f41587788c60813b088b373960b7fb88c021 baseline version: xen 6bc1c1aba01f663687d7d2b48ccdf8d9432d92cc Last test of basis 173064 2022-09-08 12:01:50 Z0 days Testing same since 173078 2022-09-09 00:00:26 Z0 days1 attempts People who touched revisions under test: Michal Orzel Stefano Stabellini jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt fail test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 6bc1c1aba0..36e3f41587 36e3f41587788c60813b088b373960b7fb88c021 -> smoke
[ovmf test] 173076: regressions - FAIL
flight 173076 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/173076/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136 version targeted for testing: ovmf 7b8f69d7e10628d473dd225224d8c2122d25a38d baseline version: ovmf 444260d45ec2a84e8f8c192b3539a3cd5591d009 Last test of basis 172136 2022-08-04 06:43:42 Z 35 days Failing since172151 2022-08-05 02:40:28 Z 35 days 271 attempts Testing same since 173070 2022-09-08 19:43:32 Z0 days3 attempts People who touched revisions under test: "Lee, Chun-Yi" Abdul Lateef Attar Abner Chang Annie Li Ard Biesheuvel Bob Feng Chasel Chiu Chen, Xiao X Corvin Köhne Czajkowski, Maciej Dimitrije Pavlov Dun Tan Edward Pickup Feng, Bob C Foster Nong Gerd Hoffmann Gregx Yeh Guo Dong Igor Kulchytskyy James Lu Jeff Brasen Jianyong Wu Jiaxin Wu Jose Marinho KasimX Liu Kavya Konstantin Aladyshev Kun Qin Laszlo Ersek Lee, Chun-Yi Leif Lindholm Liming Gao Liu, Zhiguang Maciej Czajkowski Michael D Kinney Michael Kubacki Min M Xu Min Xu Oliver Steffen Pierre Gondois Pranav Madhu Ray Ni Rebecca Cran Rebecca Cran Rohit Mathew Sainadh Nagolu Sami Mujawar Sebastien Boeuf Shengfengx Xue Wenyi Xie Wu, Jiaxin Xiao X Chen Yuan Yu Yuanhao Xie Zhiguang Liu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 2261 lines long.)
[linux-5.4 test] 173067: regressions - FAIL
flight 173067 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/173067/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-vhd broken in 173048 build-i386-libvirt6 libvirt-buildfail REGR. vs. 172128 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172128 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 172128 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 172128 build-arm64-pvops 6 kernel-build fail REGR. vs. 172128 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-vhd 5 host-install(5) broken in 173048 pass in 173067 test-amd64-i386-qemuu-rhel6hvm-intel 8 xen-boot fail in 173048 pass in 173067 test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail in 173056 pass in 173048 test-amd64-amd64-examine 13 examine-iommufail in 173056 pass in 173067 test-amd64-amd64-xl-rtds 18 guest-localmigrate fail pass in 173056 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 173056 test-armhf-armhf-xl-rtds 14 guest-startfail pass in 173056 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 18 guest-start/debian.repeat fail blocked in 172128 test-armhf-armhf-xl-multivcpu 14 guest-startfail in 173048 like 172128 test-armhf-armhf-xl-credit2 18 guest-start/debian.repeat fail in 173056 like 172108 test-armhf-armhf-xl-credit1 14 guest-start fail in 173056 like 172128 test-armhf-armhf-xl-rtds 18 guest-start/debian.repeat fail in 173056 like 172128 test-arm64-arm64-xl-seattle 15 migrate-support-check fail in 173056 never pass test-arm64-arm64-xl-seattle 16 saverestore-support-check fail in 173056 never pass test-arm64-arm64-xl 15 migrate-support-check fail in 173056 never pass test-arm64-arm64-xl 16 saverestore-support-check fail in 173056 never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail in 173056 never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail in 173056 never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail in 173056 never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail in 173056 never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail in 173056 never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail in 173056 never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail in 173056 never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail in 173056 never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail in 173056 never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail in 173056 never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail in 173056 never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail in 173056 never pass test-armhf-armhf-xl-rtds15 migrate-support-check fail in 173056 never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail in 173056 never pass test-arm64-arm64-xl-vhd 14
Re: Linux pin_user_pages_fast fails on Xen
Adding more people in CC On Thu, 8 Sep 2022, Stefano Stabellini wrote: > Hi Juergen, > > A colleague is seeing a failure on x86 in Linux Dom0. The failure is > pin_user_pages_fast with addresses that correspond to foreign memory > pages: > > - QEMU maps a domU address using dma_memory_map (xen_map_cache) > - QEMU calls an IOCTL to the TEE subsystem with the Virtual Address > returned by dma_memory_map > - Linux tee_shm_register->pin_user_pages_fast Returns -14 - > drivers/tee/tee_shm.c > > Once upon a time it used to be the case that get_user_pages_fast would > fail on Xen because we didn't have a struct page corresponding to > foreign memory mappings. But that hasn't been the case for years now. > > Any other ideas why it would fail? > > Cheers, > > Stefano >
Linux pin_user_pages_fast fails on Xen
Hi Juergen, A colleague is seeing a failure on x86 in Linux Dom0. The failure is pin_user_pages_fast with addresses that correspond to foreign memory pages: - QEMU maps a domU address using dma_memory_map (xen_map_cache) - QEMU calls an IOCTL to the TEE subsystem with the Virtual Address returned by dma_memory_map - Linux tee_shm_register->pin_user_pages_fast Returns -14 - drivers/tee/tee_shm.c Once upon a time it used to be the case that get_user_pages_fast would fail on Xen because we didn't have a struct page corresponding to foreign memory mappings. But that hasn't been the case for years now. Any other ideas why it would fail? Cheers, Stefano
[PATCH v13] xsm/flask: correcting initial sid assignment on context allocation
The current flow for initial SID assignment is that the function
flask_domain_alloc_security() allocates the security context and assigns an
initial SID based on the limited state information it can access. Specifically
the initial SID is determined by the domid of the domain, where it would assign
the label for one of the domains the hypervisor constructed with the exception
of initial domain (dom0). In the case of the initial domain and all other
domains it would use the unlabeled_t SID.
When it came to the SID for the initial domain, its assignment was managed by
flask_domain_create() where it would be switched from unlabeled_t to dom0_t.
This logic worked under the assumption that the first call to
flask_domain_create() would be the hypervisor constructing the initial domain.
After which it would be the toolstack constructing the domain, for which it is
expected to provide an appropriate SID or else unlabeled_t would be used.
The issue is that the assumptions upon which the current flow is built were
weak and are invalid for PV shim and dom0less. Under the current flow even
though the initial domain for PV shim is not set as privileged, flask would
label the domain as dom0_t. For dom0less, the situation is two-fold. First is
that every domain after the first domain creation will fail as they will be
labeled as unlabeled_t. The second is that if the dom0less configuration does
not include a "dom0", the first domain created would be labeled as dom0_t.
This commit only seeks to address the situation for PV shim, by including a
check for xenboot_t context in flask_domain_alloc_security() to determine if
the domain is being constructed at system boot. Then a check for is_privilged
and pv_shim is added to differentiate between a "dom0" initial domain and a PV
shim initial domain.
The logic for flask_domain_create() was altered to allow the incoming SID to
override the initial label. This allows a domain builder, whether it is a
toolstack, dom0less, or hyperlaunch, to provide the correct label for the
domain at construction.
The base policy was adjusted to allow the idle domain under the xenboot_t
context the ability to construct domains of both types, dom0_t and domu_t.
This will enable a hypervisor resident domain builder to construct domains
beyond the initial domain,
Signed-off-by: Daniel P. Smith
---
Split out from series "Adds starting the idle domain privileged", earlier
patches
from series have been committed.
Changes in v13:
After considering the points raised by Jason, a valid point that really stuck
is that changes to FLASK should not be made to address that dom0less did not
include support to work under FLASK. The reality is that both dom0less and
hyperlaunch are solutions that by design provide domain definitions to the
hypervisor for construction. Therefore, they should handle doing domain
construction under FLASK. Thus, the patch was adjusted to address correctly
labeling the initial domain under PV shim.
Changes in v12:
- actually send the changes from v11
Changes in v11:
- put back dom0_created variable in flask_domain_create() to ensure the
enforcement that dom0_t is a singleton label
Changes in v10:
- rewrote commit message
- fixed typos
- reworked logic in flask_domain_create() to be simpler and not result in
changing the domain security struct before the access check fails
tools/flask/policy/modules/dom0.te | 3 ++
tools/flask/policy/modules/domU.te | 3 ++
xen/xsm/flask/hooks.c | 55 +++---
3 files changed, 49 insertions(+), 12 deletions(-)
diff --git a/tools/flask/policy/modules/dom0.te
b/tools/flask/policy/modules/dom0.te
index 0a63ce15b6..f710ff9941 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -75,3 +75,6 @@ admin_device(dom0_t, ioport_t)
admin_device(dom0_t, iomem_t)
domain_comms(dom0_t, dom0_t)
+
+# Allow the hypervisor to build domains of type dom0_t
+xen_build_domain(dom0_t)
diff --git a/tools/flask/policy/modules/domU.te
b/tools/flask/policy/modules/domU.te
index b77df29d56..3f269018f9 100644
--- a/tools/flask/policy/modules/domU.te
+++ b/tools/flask/policy/modules/domU.te
@@ -13,6 +13,9 @@ domain_comms(domU_t, domU_t)
migrate_domain_out(dom0_t, domU_t)
domain_self_comms(domU_t)
+# Allow the hypervisor to build domains of type domU_t
+xen_build_domain(domU_t)
+
# Device model for domU_t. You can define distinct types for device models for
# domains of other types, or add more make_device_model lines for this type.
declare_domain(dm_dom_t)
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 8bd56644ef..e7db7fe07a 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -38,6 +38,12 @@
#include
#include "private.h"
+#ifdef CONFIG_X86
+#include
+#else
+#define pv_shim false
+#endif
+
static uint32_t domain_sid(const struct domain *dom)
{
struct domain_security_struct *dsec = dom->ssid;
@@ -170,6 +176,9 @@ static int cf_check
[ovmf test] 173072: regressions - FAIL
flight 173072 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/173072/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136 version targeted for testing: ovmf 7b8f69d7e10628d473dd225224d8c2122d25a38d baseline version: ovmf 444260d45ec2a84e8f8c192b3539a3cd5591d009 Last test of basis 172136 2022-08-04 06:43:42 Z 35 days Failing since172151 2022-08-05 02:40:28 Z 34 days 270 attempts Testing same since 173070 2022-09-08 19:43:32 Z0 days2 attempts People who touched revisions under test: "Lee, Chun-Yi" Abdul Lateef Attar Abner Chang Annie Li Ard Biesheuvel Bob Feng Chasel Chiu Chen, Xiao X Corvin Köhne Czajkowski, Maciej Dimitrije Pavlov Dun Tan Edward Pickup Feng, Bob C Foster Nong Gerd Hoffmann Gregx Yeh Guo Dong Igor Kulchytskyy James Lu Jeff Brasen Jianyong Wu Jiaxin Wu Jose Marinho KasimX Liu Kavya Konstantin Aladyshev Kun Qin Laszlo Ersek Lee, Chun-Yi Leif Lindholm Liming Gao Liu, Zhiguang Maciej Czajkowski Michael D Kinney Michael Kubacki Min M Xu Min Xu Oliver Steffen Pierre Gondois Pranav Madhu Ray Ni Rebecca Cran Rebecca Cran Rohit Mathew Sainadh Nagolu Sami Mujawar Sebastien Boeuf Shengfengx Xue Wenyi Xie Wu, Jiaxin Xiao X Chen Yuan Yu Yuanhao Xie Zhiguang Liu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 2261 lines long.)
Gitlab breakage: [PATCH] Config.mk: correct PIE-related option(s) in EMBEDDED_EXTRA_CFLAGS
Hi Jan, This patch breaks the gitlab-ci pipeline, specifically it breaks the hvmloader build with clang: https://gitlab.com/xen-project/xen/-/pipelines/634274727 https://gitlab.com/xen-project/xen/-/jobs/2996114313 make[7]: Entering directory '/builds/xen-project/xen/tools/firmware/hvmloader' clang -m32 -march=i686 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MP -MF .hvmloader.o.d -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -DNDEBUG -Werror -fno-pie -no-pie -fno-stack-protector -fno-exceptions -fno-asynchronous-unwind-tables -fcf-protection=none -ffreestanding -msoft-float -nostdinc -I/builds/xen-project/xen/tools/firmware/hvmloader/../../../tools/firmware/include -I/builds/xen-project/xen/tools/firmware/hvmloader/../../../tools/include -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -I../../libacpi -c -o hvmloader.o hvmloader.c clang: error: argument unused during compilation: '-nopie' [-Werror,-Wunused-command-line-argument] Cheers, Stefano On Thu, 25 Aug 2022, Jan Beulich wrote: > I haven't been able to find evidence of "-nopie" ever having been a > supported compiler option. The correct spelling is "-no-pie". > Furthermore like "-pie" this is an option which is solely passed to the > linker. The compiler only recognizes "-fpie" / "-fPIE" / "-fno-pie", and > it doesn't infer these options from "-pie" / "-no-pie". > > Add the compiler recognized form, but for the possible case of the > variable also being used somewhere for linking keep the linker option as > well (with corrected spelling). > > Signed-off-by: Jan Beulich > > --- unstable.orig/Config.mk 2022-04-07 12:23:27.0 +0200 > +++ unstable/Config.mk2022-08-25 08:58:00.044287451 +0200 > @@ -188,7 +188,7 @@ endif > APPEND_LDFLAGS += $(foreach i, $(APPEND_LIB), -L$(i)) > APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i)) > > -EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-stack-protector-all > +EMBEDDED_EXTRA_CFLAGS := -fno-pie -no-pie -fno-stack-protector > -fno-stack-protector-all > EMBEDDED_EXTRA_CFLAGS += -fno-exceptions -fno-asynchronous-unwind-tables > > XEN_EXTFILES_URL ?= http://xenbits.xen.org/xen-extfiles >
Re: [for-4.17 v2 3/3] automation: Add a new job for testing boot time cpupools on arm64
On Thu, 8 Sep 2022, Michal Orzel wrote:
> Add a new test job qemu-smoke-arm64-gcc-boot-cpupools that will execute
> script qemu-smoke-arm64.sh to test boot time cpupools feature.
> Enable CONFIG_BOOT_TIME_CPUPOOLS for the arm64 build and add a new test
> case in qemu-smoke-arm64.sh that if selected will make use of the
> ImageBuilder feature to create cpupool with cpu@1, null scheduler and
> assign it to domU. Add a check in dom0 xen.start to see if domU is
> assigned a Pool-1 with null scheduler.
>
> Take the opportunity to refactor the qemu-smoke-arm64.sh script as
> follows:
> - use domU_check to store the test's commands to be run from domU
> - use dom0_check to store the test's commands to be run from dom0
> - use fdtput instead of sed to perform dtb modifications
> - use more meaningful messages for "passed" variable. This way we can
>grep for messages reported either by domU or dom0 and get rid of
>assumption that tests can only be run from domU
>
> Signed-off-by: Michal Orzel
Reviewed-by: Stefano Stabellini
> ---
> Changes in v2:
> - use ImageBuilder feature to create boot-time cpupools
> - also check if the scheduler is set up properly
> ---
> automation/gitlab-ci/test.yaml | 19 ++
> automation/scripts/build | 3 ++-
> automation/scripts/qemu-smoke-arm64.sh | 36 +++---
> 3 files changed, 48 insertions(+), 10 deletions(-)
>
> diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
> index 07209820b474..d899b3bdbf7a 100644
> --- a/automation/gitlab-ci/test.yaml
> +++ b/automation/gitlab-ci/test.yaml
> @@ -100,6 +100,25 @@ qemu-smoke-arm64-gcc-staticmem:
>tags:
> - arm64
>
> +qemu-smoke-arm64-gcc-boot-cpupools:
> + extends: .test-jobs-common
> + variables:
> +CONTAINER: debian:unstable-arm64v8
> + script:
> +- ./automation/scripts/qemu-smoke-arm64.sh boot-cpupools 2>&1 | tee
> qemu-smoke-arm64.log
> + needs:
> +- alpine-3.12-gcc-arm64
> +- alpine-3.12-arm64-rootfs-export
> +- kernel-5.19-arm64-export
> +- qemu-system-aarch64-6.0.0-arm64-export
> + artifacts:
> +paths:
> + - smoke.serial
> + - '*.log'
> +when: always
> + tags:
> +- arm64
> +
> qemu-smoke-arm32-gcc:
>extends: .test-jobs-common
>variables:
> diff --git a/automation/scripts/build b/automation/scripts/build
> index 2b9f2d2b541a..2f15ab3198e6 100755
> --- a/automation/scripts/build
> +++ b/automation/scripts/build
> @@ -19,7 +19,8 @@ else
> echo "
> CONFIG_EXPERT=y
> CONFIG_UNSUPPORTED=y
> -CONFIG_STATIC_MEMORY=y" > xen/.config
> +CONFIG_STATIC_MEMORY=y
> +CONFIG_BOOT_TIME_CPUPOOLS=y" > xen/.config
> make -j$(nproc) -C xen olddefconfig
> else
> make -j$(nproc) -C xen defconfig
> diff --git a/automation/scripts/qemu-smoke-arm64.sh
> b/automation/scripts/qemu-smoke-arm64.sh
> index 7ac96027760d..f803835779f4 100755
> --- a/automation/scripts/qemu-smoke-arm64.sh
> +++ b/automation/scripts/qemu-smoke-arm64.sh
> @@ -4,20 +4,22 @@ set -ex
>
> test_variant=$1
>
> -passed="passed"
> -check="
> +if [ -z "${test_variant}" ]; then
> +passed="ping test passed"
> +domU_check="
> until ifconfig eth0 192.168.0.2 &> /dev/null && ping -c 10 192.168.0.1; do
> sleep 30
> done
> echo \"${passed}\"
> "
> +fi
>
> if [[ "${test_variant}" == "static-mem" ]]; then
> # Memory range that is statically allocated to DOM1
> domu_base="5000"
> domu_size="1000"
> passed="${test_variant} test passed"
> -check="
> +domU_check="
> current=\$(hexdump -e '16/1 \"%02x\"'
> /proc/device-tree/memory@${domu_base}/reg 2>/dev/null)
> expected=$(printf \"%016x%016x\" 0x${domu_base} 0x${domu_size})
> if [[ \"\${expected}\" == \"\${current}\" ]]; then
> @@ -26,6 +28,16 @@ fi
> "
> fi
>
> +if [[ "${test_variant}" == "boot-cpupools" ]]; then
> +# Check if domU0 (id=1) is assigned to Pool-1 with null scheduler
> +passed="${test_variant} test passed"
> +dom0_check="
> +if xl list -c 1 | grep -q Pool-1 && xl cpupool-list Pool-1 | grep -q Pool-1;
> then
> +echo ${passed}
> +fi
> +"
> +fi
> +
> export DEBIAN_FRONTENT=noninteractive
> apt-get -qy update
> apt-get -qy install --no-install-recommends u-boot-qemu \
> @@ -42,11 +54,9 @@ curl -fsSLO
> https://github.com/qemu/qemu/raw/v5.2.0/pc-bios/efi-virtio.rom
> -cpu cortex-a57 -machine type=virt \
> -m 1024 -smp 2 -display none \
> -machine dumpdtb=binaries/virt-gicv2.dtb
> -# XXX disable pl061 to avoid Linux crash
> -dtc -I dtb -O dts binaries/virt-gicv2.dtb > binaries/virt-gicv2.dts
> -sed 's/compatible = "arm,pl061.*/status = "disabled";/g'
> binaries/virt-gicv2.dts > binaries/virt-gicv2-edited.dts
> -dtc -I dts -O dtb binaries/virt-gicv2-edited.dts > binaries/virt-gicv2.dtb
>
> +# XXX disable pl061 to avoid Linux crash
> +fdtput binaries/virt-gicv2.dtb -p -t s /pl061@903 status disabled
>
> # Busybox
> mkdir -p initrd
> @@
Re: [for-4.17 v2 2/3] automation: qemu-smoke-arm64: Silence ifconfig error messages
On Thu, 8 Sep 2022, Michal Orzel wrote:
> During the ping test, dom1 tries to assign an ip to eth0 in a loop.
> Before setting up the network interface by dom0, this results in
> printing the following error message several times:
> (XEN) DOM1: ifconfig: SIOCSIFADDR: No such device
>
> Silence this by redirecting stderr/stdout to /dev/null as we do not
> care about the output and we should not pollute the log file.
>
> Signed-off-by: Michal Orzel
> Reviewed-by: Luca Fancellu
> Reviewed-by: Ayan Kumar Halder
Acked-by: Stefano Stabellini
> ---
> Changes in v2:
> - none
> ---
> automation/scripts/qemu-smoke-arm64.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/automation/scripts/qemu-smoke-arm64.sh
> b/automation/scripts/qemu-smoke-arm64.sh
> index c80d9b2aee00..7ac96027760d 100755
> --- a/automation/scripts/qemu-smoke-arm64.sh
> +++ b/automation/scripts/qemu-smoke-arm64.sh
> @@ -6,7 +6,7 @@ test_variant=$1
>
> passed="passed"
> check="
> -until ifconfig eth0 192.168.0.2 && ping -c 10 192.168.0.1; do
> +until ifconfig eth0 192.168.0.2 &> /dev/null && ping -c 10 192.168.0.1; do
> sleep 30
> done
> echo \"${passed}\"
> --
> 2.25.1
>
Re: [for-4.17 v2 1/3] automation: qemu-alpine-arm64-gcc: Use kernel 5.19
On Thu, 8 Sep 2022, Michal Orzel wrote: > After qemu-smoke-arm64 was changed to use kernel 5.19 we end up having > two kernel configurations. This is something not needed and maintaining > a single kernel version is always easier. Modify qemu-alpine-arm64-gcc > to use kernel 5.19 and remove kernel 5.9 from tests-artifacts. > > Signed-off-by: Michal Orzel > Reviewed-by: Luca Fancellu > Reviewed-by: Ayan Kumar Halder Acked-by: Stefano Stabellini > --- > Changes in v2: > - none > --- > automation/gitlab-ci/build.yaml | 11 -- > automation/gitlab-ci/test.yaml| 2 +- > .../kernel/5.9.9-arm64v8.dockerfile | 34 --- > 3 files changed, 1 insertion(+), 46 deletions(-) > delete mode 100644 automation/tests-artifacts/kernel/5.9.9-arm64v8.dockerfile > > diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml > index d2f75a090c0f..720ce6e07ba0 100644 > --- a/automation/gitlab-ci/build.yaml > +++ b/automation/gitlab-ci/build.yaml > @@ -586,17 +586,6 @@ alpine-3.12-arm64-rootfs-export: >tags: > - arm64 > > -kernel-5.9.9-arm64-export: > - extends: .test-jobs-artifact-common > - image: > registry.gitlab.com/xen-project/xen/tests-artifacts/kernel:5.9.9-arm64v8 > - script: > -- mkdir binaries && cp /Image binaries/Image > - artifacts: > -paths: > - - binaries/Image > - tags: > -- arm64 > - > kernel-5.19-arm64-export: >extends: .test-jobs-artifact-common >image: > registry.gitlab.com/xen-project/xen/tests-artifacts/kernel:5.19-arm64v8 > diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml > index 2eb6c3866e2c..07209820b474 100644 > --- a/automation/gitlab-ci/test.yaml > +++ b/automation/gitlab-ci/test.yaml > @@ -34,7 +34,7 @@ qemu-alpine-arm64-gcc: >needs: > - alpine-3.12-gcc-arm64 > - alpine-3.12-arm64-rootfs-export > -- kernel-5.9.9-arm64-export > +- kernel-5.19-arm64-export > - qemu-system-aarch64-6.0.0-arm64-export >artifacts: > paths: > diff --git a/automation/tests-artifacts/kernel/5.9.9-arm64v8.dockerfile > b/automation/tests-artifacts/kernel/5.9.9-arm64v8.dockerfile > deleted file mode 100644 > index 053d65a3454e.. > --- a/automation/tests-artifacts/kernel/5.9.9-arm64v8.dockerfile > +++ /dev/null > @@ -1,34 +0,0 @@ > -FROM arm64v8/debian:unstable > -LABEL maintainer.name="The Xen Project" \ > - maintainer.email="xen-devel@lists.xenproject.org" > - > -ENV DEBIAN_FRONTEND=noninteractive > -ENV LINUX_VERSION=5.9.9 > -ENV USER root > - > -RUN mkdir /build > -WORKDIR /build > - > -# build depends > -RUN apt-get update && \ > -apt-get --quiet --yes install \ > -build-essential \ > -libssl-dev \ > -bc \ > -curl \ > -flex \ > -bison \ > -&& \ > -\ > -# Build the kernel > -curl -fsSLO > https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-"$LINUX_VERSION".tar.xz && > \ > -tar xvJf linux-"$LINUX_VERSION".tar.xz && \ > -cd linux-"$LINUX_VERSION" && \ > -make defconfig && \ > -make -j$(nproc) Image.gz && \ > -cp arch/arm64/boot/Image / && \ > -cd /build && \ > -rm -rf linux-"$LINUX_VERSION"* && \ > -apt-get autoremove -y && \ > -apt-get clean && \ > -rm -rf /var/lib/apt/lists* /tmp/* /var/tmp/* > -- > 2.25.1 >
[linux-linus test] 173065: regressions - FAIL
flight 173065 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/173065/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 172133 build-i386-libvirt6 libvirt-buildfail REGR. vs. 172133 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172133 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 172133 build-arm64-pvops 6 kernel-build fail REGR. vs. 172133 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 172133 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 172133 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 172133 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 172133 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 172133 test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass version targeted for testing: linux0066f1b0e27556381402db3ff31f85d2a2265858 baseline version: linuxb44f2fd87919b5ae6e1756d4c7ba2cbba22238e1 Last test of basis 172133 2022-08-04 05:14:48 Z 35 days Failing since172152 2022-08-05 04:01:26 Z 34 days 79 attempts Testing same since 173034 2022-09-07 03:00:08 Z1 days4 attempts 1702 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt fail build-armhf-libvirt fail
[xen-unstable test] 173063: tolerable FAIL - PUSHED
flight 173063 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/173063/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a build-amd64-libvirt 6 libvirt-buildfail like 173054 build-i386-libvirt6 libvirt-buildfail like 173054 build-arm64-libvirt 6 libvirt-buildfail like 173054 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 173054 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 173054 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 173054 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 173054 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 173054 build-armhf-libvirt 6 libvirt-buildfail like 173054 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 173054 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 173054 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 173054 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 173054 test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass version targeted for testing: xen 64e302157a87b246473a31fa104377a6d48eb046 baseline version: xen
Re: [PATCH v2 2/3] xl/libxl: Add ability to specify SMBIOS strings
On Thu, Sep 8, 2022 at 3:51 PM Jason Andryuk wrote:
> @@ -1783,6 +1784,57 @@ void parse_config_data(const char *config_source,
> xlu_cfg_replace_string(config, "acpi_firmware",
> _info->u.hvm.acpi_firmware, 0);
>
> +switch (xlu_cfg_get_list(config, "smbios", , _smbios, 0))
> +{
> +case 0: /* Success */
> +b_info->u.hvm.num_smbios = num_smbios;
...
> +}
> +break;
> +}
Andrew pointed out this stray curly brace breaks bisection - its match
at the beginning of the 'case 0' is introduced in patch 3. Sorry
about that. I'm AFK, but will send out an updated patch tomorrow.
-Jason
> +case ESRCH: /* Option not present */
> +break;
> +default:
> +fprintf(stderr,"xl: Unable to parse smbios options.\n");
> +exit(EXIT_FAILURE);
> +}
> +
> if (!xlu_cfg_get_string(config, "ms_vm_genid", , 0)) {
> if (!strcmp(buf, "generate")) {
> e = libxl_ms_vm_genid_generate(ctx,
> _info->u.hvm.ms_vm_genid);
> --
> 2.37.3
>
Re: [PATCH v5 2/2] xen/pci: replace call to is_memory_hole to pci_check_bar
Hi Stefano,
On 08/09/2022 21:59, Stefano Stabellini wrote:
+/*
+ * TODO: BAR addresses and Root Complex window addresses are not guaranteed
+ * to be page aligned. We should check for alignment but this is not the
+ * right place for alignment check.
+ */
+static int is_bar_valid(const struct dt_device_node *dev,
+uint64_t addr, uint64_t len, void *data)
+{
+struct pdev_bar_check *bar_data = data;
+unsigned long s = bar_data->start;
+unsigned long e = bar_data->end;
+
+if ( (s >= addr) && (e <= (addr + len - 1)) )
+bar_data->is_valid = true;
"s" and "e" are "unsigned long" while "addr" and "len" are uint64_t. Is
that OK?
Good catch. No, physical address on Arm32 can be up to 40 bits.
Specifically, considering a potential arm32 case, shouldn't "s" and "e"
be uint64_t as well? Which means pdev_bar_check.start and end should be
uint64_t?
They should be paddr_t which will be 64-bit on both arm32 and arm64.
Cheers,
--
Julien Grall
[ovmf test] 173070: regressions - FAIL
flight 173070 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/173070/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136 version targeted for testing: ovmf 7b8f69d7e10628d473dd225224d8c2122d25a38d baseline version: ovmf 444260d45ec2a84e8f8c192b3539a3cd5591d009 Last test of basis 172136 2022-08-04 06:43:42 Z 35 days Failing since172151 2022-08-05 02:40:28 Z 34 days 269 attempts Testing same since 173070 2022-09-08 19:43:32 Z0 days1 attempts People who touched revisions under test: "Lee, Chun-Yi" Abdul Lateef Attar Abner Chang Annie Li Ard Biesheuvel Bob Feng Chasel Chiu Chen, Xiao X Corvin Köhne Czajkowski, Maciej Dimitrije Pavlov Dun Tan Edward Pickup Feng, Bob C Foster Nong Gerd Hoffmann Gregx Yeh Guo Dong Igor Kulchytskyy James Lu Jeff Brasen Jianyong Wu Jiaxin Wu Jose Marinho KasimX Liu Kavya Konstantin Aladyshev Kun Qin Laszlo Ersek Lee, Chun-Yi Leif Lindholm Liming Gao Liu, Zhiguang Maciej Czajkowski Michael D Kinney Michael Kubacki Min M Xu Min Xu Oliver Steffen Pierre Gondois Pranav Madhu Ray Ni Rebecca Cran Rebecca Cran Rohit Mathew Sainadh Nagolu Sami Mujawar Sebastien Boeuf Shengfengx Xue Wenyi Xie Wu, Jiaxin Xiao X Chen Yuan Yu Yuanhao Xie Zhiguang Liu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 2261 lines long.)
[qemu-mainline test] 173060: regressions - FAIL
flight 173060 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/173060/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123 build-i386-libvirt6 libvirt-buildfail REGR. vs. 172123 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 172123 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 172123 test-arm64-arm64-xl-vhd 17 guest-start/debian.repeat fail REGR. vs. 172123 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 172123 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 172123 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 172123 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 172123 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 172123 test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: qemuu79dfa177ae348bb5ab5f97c0915359b13d6186e2 baseline version: qemuu2480f3bbd03814b0651a1f74959f5c6631ee5819 Last test of basis 172123 2022-08-03 18:10:07 Z 36 days Failing since172148 2022-08-04 21:39:38 Z 34 days 79 attempts Testing same
Re: [PATCH v8 7/9] xen/arm: create shared memory nodes in guest device tree
On Thu, 8 Sep 2022, Penny Zheng wrote:
> We expose the shared memory to the domU using the "xen,shared-memory-v1"
> reserved-memory binding. See
> Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt
> in Linux for the corresponding device tree binding.
>
> To save the cost of re-parsing shared memory device tree configuration when
> creating shared memory nodes in guest device tree, this commit adds new field
> "shm_mem" to store shm-info per domain.
>
> For each shared memory region, a range is exposed under
> the /reserved-memory node as a child node. Each range sub-node is
> named xen-shmem@ and has the following properties:
> - compatible:
> compatible = "xen,shared-memory-v1"
> - reg:
> the base guest physical address and size of the shared memory region
> - xen,id:
> a string that identifies the shared memory region.
> - xen,offset: (borrower VMs only)
> 64 bit integer offset within the owner virtual machine's shared
> memory region used for the mapping in the borrower VM.
> Currently, we provide "xen,offset=<0x0>" as a temprary placeholder.
^ temporary
Another minor style issue below
> Signed-off-by: Penny Zheng
> Reviewed-by: Stefano Stabellini
> ---
> v8 changes:
> - Fix missing property "xen,offset" for borrower VMs by temporarily
> adding "xen,offset=<0x0>"
> - use >= to avoid thinking about the overflow case for nr_banks
> - check the return value of dt_property_read_string() for parsing
> shm_id
> - struct meminfo *mem and char resvbuf[16] = "reserved-memory" could be
> const
> - change "__be32 reg[4]" to "__be32 reg[GUEST_ROOT_ADDRESS_CELLS +
> GUEST_ROOT_SIZE_CELLS]"
> ---
> v7 changes:
> - allocate reg for worst case addrcells + sizecells
> - replace assert() with BUG_ON() since it is init code
> ---
> v6 change:
> - change "struct meminfo *mem" to "const struct meminfo *mem"
> - change "unsigned long i" to "unsigned int i" to match the type of nr_banks.
> - accroding to the Linux binding, "xen,id" is meant to be a string, not
> an integer
> ---
> v5 change:
> - no change
> ---
> v4 change:
> - no change
> ---
> v3 change:
> - move field "shm_mem" to kernel_info
> ---
> v2 change:
> - using xzalloc
> - shm_id should be uint8_t
> - make reg a local variable
> - add #address-cells and #size-cells properties
> - fix alignment
> ---
> xen/arch/arm/domain_build.c | 160 +-
> xen/arch/arm/include/asm/kernel.h | 1 +
> 2 files changed, 159 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index a10d07266b..cd03370b38 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -914,7 +914,22 @@ static int __init assign_shared_memory(struct domain *d,
> return ret;
> }
>
> -static int __init process_shm(struct domain *d,
> +static int __init append_shm_bank_to_domain(struct kernel_info *kinfo,
> +paddr_t start, paddr_t size,
> +const char *shm_id)
> +{
> +if ( kinfo->shm_mem.nr_banks >= NR_MEM_BANKS )
> +return -ENOMEM;
> +
> +kinfo->shm_mem.bank[kinfo->shm_mem.nr_banks].start = start;
> +kinfo->shm_mem.bank[kinfo->shm_mem.nr_banks].size = size;
> +safe_strcpy(kinfo->shm_mem.bank[kinfo->shm_mem.nr_banks].shm_id, shm_id);
> +kinfo->shm_mem.nr_banks++;
> +
> +return 0;
> +}
> +
> +static int __init process_shm(struct domain *d, struct kernel_info *kinfo,
>const struct dt_device_node *node)
> {
> struct dt_device_node *shm_node;
> @@ -928,6 +943,7 @@ static int __init process_shm(struct domain *d,
> int ret = 0;
> unsigned int i;
> const char *role_str;
> +const char *shm_id;
> bool owner_dom_io = true;
>
> if ( !dt_device_is_compatible(shm_node,
> "xen,domain-shared-memory-v1") )
> @@ -972,6 +988,13 @@ static int __init process_shm(struct domain *d,
> if ( dt_property_read_string(shm_node, "role", _str) == 0 )
> owner_dom_io = false;
>
> +if ( dt_property_read_string(shm_node, "xen,shm-id", _id) )
> +{
> +printk("%pd: invalid \"xen,shm-id\" property", d);
> +return -EINVAL;
> +}
> +BUG_ON((strlen(shm_id) <= 0) || (strlen(shm_id) >=
> MAX_SHM_ID_LENGTH));
> +
> /*
> * DOMID_IO is a fake domain and is not described in the Device-Tree.
> * Therefore when the owner of the shared region is DOMID_IO, we will
> @@ -999,6 +1022,14 @@ static int __init process_shm(struct domain *d,
> if ( ret )
> return ret;
> }
> +
> +/*
> + * Record static shared memory region info for later setting
> + * up shm-node in guest device tree.
> + */
> +ret = append_shm_bank_to_domain(kinfo,
Re: [PATCH v5 2/2] xen/pci: replace call to is_memory_hole to pci_check_bar
On Thu, 8 Sep 2022, Rahul Singh wrote:
> is_memory_hole was implemented for x86 and not for ARM when introduced.
> Replace is_memory_hole call to pci_check_bar as function should check
> if device BAR is in defined memory range. Also, add an implementation
> for ARM which is required for PCI passthrough.
>
> On x86, pci_check_bar will call is_memory_hole which will check if BAR
> is not overlapping with any memory region defined in the memory map.
>
> On ARM, pci_check_bar will go through the host bridge ranges and check
> if the BAR is in the range of defined ranges.
>
> Signed-off-by: Rahul Singh
> Acked-by: Jan Beulich # x86, common
> ---
> Changes in v5:
> - drop use of PFN_UP and PF_DOWN in case addresses are not aligned.
> - As we drop the PFN_UP and PFN_DOWN we need to use the mfn_to_maddr()
>to get the BAR address without page shift.
> - Add TODO comment for address alignment check for ranges.
> - Added Jan Acked-by for x86 and common code.
> Changes in v4:
> - check "s <= e" before callback
> - Add TODO comment for revisiting the function pci_check_bar() when
>ACPI PCI passthrough support is added.
> - Not Added the Jan Acked-by as patch is modified.
> Changes in v3:
> - fix minor comments
> ---
> xen/arch/arm/include/asm/pci.h | 2 ++
> xen/arch/arm/pci/pci-host-common.c | 54 ++
> xen/arch/x86/include/asm/pci.h | 10 ++
> xen/drivers/passthrough/pci.c | 8 ++---
> 4 files changed, 70 insertions(+), 4 deletions(-)
>
> diff --git a/xen/arch/arm/include/asm/pci.h b/xen/arch/arm/include/asm/pci.h
> index 80a2431804..8cb46f6b71 100644
> --- a/xen/arch/arm/include/asm/pci.h
> +++ b/xen/arch/arm/include/asm/pci.h
> @@ -126,6 +126,8 @@ int pci_host_iterate_bridges_and_count(struct domain *d,
>
> int pci_host_bridge_mappings(struct domain *d);
>
> +bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end);
> +
> #else /*!CONFIG_HAS_PCI*/
>
> struct arch_pci_dev { };
> diff --git a/xen/arch/arm/pci/pci-host-common.c
> b/xen/arch/arm/pci/pci-host-common.c
> index 89ef30028e..d51cfdf352 100644
> --- a/xen/arch/arm/pci/pci-host-common.c
> +++ b/xen/arch/arm/pci/pci-host-common.c
> @@ -24,6 +24,16 @@
>
> #include
>
> +/*
> + * struct to hold pci device bar.
> + */
> +struct pdev_bar_check
> +{
> +unsigned long start;
> +unsigned long end;
> +bool is_valid;
> +};
> +
> /*
> * List for all the pci host bridges.
> */
> @@ -363,6 +373,50 @@ int __init pci_host_bridge_mappings(struct domain *d)
> return 0;
> }
>
> +/*
> + * TODO: BAR addresses and Root Complex window addresses are not guaranteed
> + * to be page aligned. We should check for alignment but this is not the
> + * right place for alignment check.
> + */
> +static int is_bar_valid(const struct dt_device_node *dev,
> +uint64_t addr, uint64_t len, void *data)
> +{
> +struct pdev_bar_check *bar_data = data;
> +unsigned long s = bar_data->start;
> +unsigned long e = bar_data->end;
> +
> +if ( (s >= addr) && (e <= (addr + len - 1)) )
> +bar_data->is_valid = true;
"s" and "e" are "unsigned long" while "addr" and "len" are uint64_t. Is
that OK?
Specifically, considering a potential arm32 case, shouldn't "s" and "e"
be uint64_t as well? Which means pdev_bar_check.start and end should be
uint64_t?
> +return 0;
> +}
> +
> +/* TODO: Revisit this function when ACPI PCI passthrough support is added. */
> +bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end)
> +{
> +int ret;
> +const struct dt_device_node *dt_node;
> +unsigned long s = mfn_to_maddr(start);
> +unsigned long e = mfn_to_maddr(end);
> +struct pdev_bar_check bar_data = {
> +.start = s,
> +.end = e,
> +.is_valid = false
> +};
> +
> +if ( s >= e )
> +return false;
> +
> +dt_node = pci_find_host_bridge_node(pdev);
> +if ( !dt_node )
> +return false;
> +
> +ret = dt_for_each_range(dt_node, _bar_valid, _data);
> +if ( ret < 0 )
> +return false;
> +
> +return bar_data.is_valid;
> +}
> /*
> * Local variables:
> * mode: C
> diff --git a/xen/arch/x86/include/asm/pci.h b/xen/arch/x86/include/asm/pci.h
> index c8e1a9ecdb..f4a58c8acf 100644
> --- a/xen/arch/x86/include/asm/pci.h
> +++ b/xen/arch/x86/include/asm/pci.h
> @@ -57,4 +57,14 @@ static always_inline bool is_pci_passthrough_enabled(void)
>
> void arch_pci_init_pdev(struct pci_dev *pdev);
>
> +static inline bool pci_check_bar(const struct pci_dev *pdev,
> + mfn_t start, mfn_t end)
> +{
> +/*
> + * Check if BAR is not overlapping with any memory region defined
> + * in the memory map.
> + */
> +return is_memory_hole(start, end);
> +}
> +
> #endif /* __X86_PCI_H__ */
> diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
> index cdaf5c247f..149f68bb6e 100644
> ---
Re: [PATCH v5 7/7] xen/arm: introduce xen-evtchn dom0less property
On Thu, 8 Sep 2022, Julien Grall wrote: > On 08/09/2022 01:04, Stefano Stabellini wrote: > > On Wed, 7 Sep 2022, Rahul Singh wrote: > > > Introduce a new sub-node under /chosen node to establish static event > > > channel communication between domains on dom0less systems. > > > > > > An event channel will be created beforehand to allow the domains to > > > send notifications to each other. > > > > > > Signed-off-by: Rahul Singh > > > > For the DT binding: > > > > Reviewed-by: Stefano Stabellini > > This is now committed but I didn't notice the "For the DT binding" above. So I > mistakenly interpreted this as you reviewed everything. Let me know if that's > a problem with you. No problems, I looked at the commit now and everything looks good anyway. > For the future may I ask to use suffix with "# DT binding" as this is easier > to spot when using automatic tools (e.g. b4)? I think that's a good idea.
[PATCH v2 2/3] xl/libxl: Add ability to specify SMBIOS strings
hvm_xs_strings.h specifies xenstore entries which can be used to set or
override smbios strings. hvmloader has support for reading them, but
xl/libxl support is not wired up.
Allow specifying the strings with the new xl.cfg option:
smbios=["bios_vendor=Xen Project","system_version=1.0"]
In terms of strings, the SMBIOS specification 3.5 says:
https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.5.0.pdf
"""
Strings must be encoded as UTF-8 with no byte order mark (BOM). For
compatibility with older SMBIOS parsers, US-ASCII characters should be
used. NOTE There is no limit on the length of each individual text
string. However, the length of the entire structure table (including all
strings) must be reported in the Structure Table Length field of the
32-bit Structure Table Entry Point (see 5.2.1) and/or the Structure
Table Maximum Size field of the 64-bit Structure Table Entry Point (see
5.2.2).
"""
The strings aren't checked for utf-8 or length. hvmloader has a sanity
check on the overall length.
The libxl_smbios_type enum starts at 1 since otherwise the 0th key is
not printed in the json output.
Signed-off-by: Jason Andryuk
---
v2:
Update s/_/-/ comment
Update debug print to xs_path = "value"
Error on xlu_cfg_get_listitem failure
Use EXIT_FAILURE consistently
free parsed strings
Move break to new line
The rendered man page and html don't have a newline at the end of the
new section.
"""
battery_device_name=STRING
ms_vm_genid="OPTION"
"""
however the txt format is correct:
"""
battery_device_name=STRING
ms_vm_genid="OPTION"
"""
I'm at a loss as to why this is happening.
---
docs/man/xl.cfg.5.pod.in | 45 +++
tools/golang/xenlight/helpers.gen.go | 51 ++
tools/golang/xenlight/types.gen.go | 27 ++
tools/include/libxl.h| 5 +++
tools/libs/light/libxl_dom.c | 21 +++
tools/libs/light/libxl_types.idl | 26 ++
tools/xl/xl_parse.c | 54 +++-
7 files changed, 228 insertions(+), 1 deletion(-)
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index b2901e04cf..fa78fba361 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -2061,6 +2061,51 @@ number of vendor defined SMBIOS structures (type 128 -
255). Since SMBIOS
structures do not present their overall size, each entry in the file must be
preceded by a 32b integer indicating the size of the following structure.
+=item B
+
+Specifies the SMBIOS values to be provided to the guest. These set or
+override specific entries in the tables provided to the guest.
+
+Each B is a C string from the following list:
+
+=over 4
+
+=item B
+
+=item B
+
+=item B
+
+=item B
+
+=item B
+
+=item B
+
+=item B
+
+=item B
+
+=item B
+
+=item B
+
+=item B
+
+=item B
+
+=item B
+
+=item B
+
+=item B
+
+=item B
+
+=item B
+
+=back
+
=item B
Provide a VM generation ID to the guest.
diff --git a/tools/golang/xenlight/helpers.gen.go
b/tools/golang/xenlight/helpers.gen.go
index fa3cf2ab76..cae14ec6f5 100644
--- a/tools/golang/xenlight/helpers.gen.go
+++ b/tools/golang/xenlight/helpers.gen.go
@@ -589,6 +589,38 @@ xc.build_id = C.CString(x.BuildId)}
return nil
}
+// NewSmbios returns an instance of Smbios initialized with defaults.
+func NewSmbios() (*Smbios, error) {
+var (
+x Smbios
+xc C.libxl_smbios)
+
+C.libxl_smbios_init()
+defer C.libxl_smbios_dispose()
+
+if err := x.fromC(); err != nil {
+return nil, err }
+
+return , nil}
+
+func (x *Smbios) fromC(xc *C.libxl_smbios) error {
+ x.Key = SmbiosType(xc.key)
+x.Value = C.GoString(xc.value)
+
+ return nil}
+
+func (x *Smbios) toC(xc *C.libxl_smbios) (err error){defer func(){
+if err != nil{
+C.libxl_smbios_dispose(xc)}
+}()
+
+xc.key = C.libxl_smbios_type(x.Key)
+if x.Value != "" {
+xc.value = C.CString(x.Value)}
+
+ return nil
+ }
+
// NewDomainCreateInfo returns an instance of DomainCreateInfo initialized
with defaults.
func NewDomainCreateInfo() (*DomainCreateInfo, error) {
var (
@@ -1189,6 +1221,15 @@ return fmt.Errorf("converting field Altp2M: %v", err)
}
x.SystemFirmware = C.GoString(tmp.system_firmware)
x.SmbiosFirmware = C.GoString(tmp.smbios_firmware)
+x.Smbios = nil
+if n := int(tmp.num_smbios); n > 0 {
+cSmbios := (*[1<<28]C.libxl_smbios)(unsafe.Pointer(tmp.smbios))[:n:n]
+x.Smbios = make([]Smbios, n)
+for i, v := range cSmbios {
+if err := x.Smbios[i].fromC(); err != nil {
+return fmt.Errorf("converting field Smbios: %v", err) }
+}
+}
x.AcpiFirmware = C.GoString(tmp.acpi_firmware)
x.Hdtype = Hdtype(tmp.hdtype)
if err := x.Nographic.fromC();err != nil {
@@ -1501,6 +1542,16 @@ if tmp.SystemFirmware != "" {
hvm.system_firmware = C.CString(tmp.SystemFirmware)}
if tmp.SmbiosFirmware != "" {
hvm.smbios_firmware = C.CString(tmp.SmbiosFirmware)}
+if numSmbios := len(tmp.Smbios); numSmbios > 0 {
+hvm.smbios =
[PATCH v2 3/3] xl/libxl: Add OEM string support to smbios
Add support for OEM strings in the SMBIOS type 11.
hvmloader checks them sequentially, so hide the implementation detail.
Allow multiple plain oem= items and assign the numeric values
internally.
Signed-off-by: Jason Andryuk
---
v2:
Move oem= description to be indented in docs
Re-work oem= description
Re-word oem string limit xl error message
Replace OEM_{1,99) with just OEM and handle in libxl
This change re-introduces the newline before ms_vm_genid.
---
docs/man/xl.cfg.5.pod.in | 4
tools/golang/xenlight/types.gen.go | 1 +
tools/libs/light/libxl_dom.c | 15 +--
tools/libs/light/libxl_types.idl | 1 +
tools/xl/xl_parse.c| 12
5 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index fa78fba361..ddba1c3a05 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -2104,6 +2104,10 @@ Each B is a C string from
the following list:
=item B
+=item B
+
+oem= can be specified up to 99 times.
+
=back
=item B
diff --git a/tools/golang/xenlight/types.gen.go
b/tools/golang/xenlight/types.gen.go
index e084c3540b..51076249b4 100644
--- a/tools/golang/xenlight/types.gen.go
+++ b/tools/golang/xenlight/types.gen.go
@@ -405,6 +405,7 @@ SmbiosTypeEnclosureSerialNumber SmbiosType = 14
SmbiosTypeEnclosureAssetTag SmbiosType = 15
SmbiosTypeBatteryManufacturer SmbiosType = 16
SmbiosTypeBatteryDeviceName SmbiosType = 17
+SmbiosTypeOem SmbiosType = 18
)
type Smbios struct {
diff --git a/tools/libs/light/libxl_dom.c b/tools/libs/light/libxl_dom.c
index c3125ed310..0b01e09632 100644
--- a/tools/libs/light/libxl_dom.c
+++ b/tools/libs/light/libxl_dom.c
@@ -753,6 +753,7 @@ static int hvm_build_set_xs_values(libxl__gc *gc,
const libxl_domain_build_info *info)
{
char *path = NULL;
+int num_oem = 1;
int ret = 0;
if (dom->smbios_module.guest_addr_out) {
@@ -773,8 +774,18 @@ static int hvm_build_set_xs_values(libxl__gc *gc,
for (int i = 0; i < info->u.hvm.num_smbios; i++) {
char *p;
-path = GCSPRINTF("/local/domain/%d/"HVM_XS_BIOS_STRINGS"/%s", domid,
- libxl_smbios_type_to_string(info->u.hvm.smbios[i].key));
+if (info->u.hvm.smbios[i].key == LIBXL_SMBIOS_TYPE_OEM) {
+if (num_oem > 99) {
+ret = ERROR_INVAL;
+goto err;
+}
+path = GCSPRINTF("/local/domain/%d/"HVM_XS_OEM_STRINGS, domid,
+ num_oem);
+num_oem++;
+} else {
+path = GCSPRINTF("/local/domain/%d/"HVM_XS_BIOS_STRINGS"/%s",
domid,
+ libxl_smbios_type_to_string(info->u.hvm.smbios[i].key));
+}
/* Convert libxl_smbios_type string to xenstore path that hvmloader
will use, as defined by HVM_XS_*. That is convert the '_' to '-'. */
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
index d04207748e..76651eea43 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -436,6 +436,7 @@ libxl_smbios_type = Enumeration("smbios_type", [
(15, "enclosure_asset_tag"),
(16, "battery_manufacturer"),
(17, "battery_device_name"),
+(18, "oem"),
])
libxl_smbios = Struct("smbios", [
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 5413c36645..d0f8a14827 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -1787,6 +1787,9 @@ void parse_config_data(const char *config_source,
switch (xlu_cfg_get_list(config, "smbios", , _smbios, 0))
{
case 0: /* Success */
+{
+unsigned int num_oem = 1;
+
b_info->u.hvm.num_smbios = num_smbios;
b_info->u.hvm.smbios = xcalloc(num_smbios, sizeof(libxl_smbios));
for (i = 0; i < num_smbios; i++) {
@@ -1823,6 +1826,15 @@ void parse_config_data(const char *config_source,
}
free(option);
+if (v == LIBXL_SMBIOS_TYPE_OEM) {
+if (num_oem > 99) {
+fprintf(stderr,
+"xl: smbios limited to 99 oem strings\n");
+exit(-ERROR_FAIL);
+}
+num_oem++;
+}
+
b_info->u.hvm.smbios[i].key = v;
b_info->u.hvm.smbios[i].value = value;
}
--
2.37.3
[PATCH v2 0/3] libxl smbios support
hvm_xs_strings.h specifies xenstore entries which can be used to set or override smbios strings. hvmloader has support for reading them, but xl/libxl support is not wired up. This patches adds a new xl.cfg option and libxl support to write the xenstore strings. The xl syntax looks like: smbios=["bios_vendor=Xen Project","system_version=1.0"] The Go binding generation needed extending to support Arrays inside a KeyedUnion, which is what the first patch does. The generated go code builds, but it is otherwise untested. There are also oem strings, oem-1..oem-99, that HVM loader supports. xl parse multiple oem strings like smbios=["oem=A,oem=B"], libxl then iterates over them and assigned to the oem-%d entries. Both xl and libxl check that the 99 string limit isn't exceeded. The rendered man page and html don't have a newline at then end of the new section after patch 2. """ battery_device_name=STRING ms_vm_genid="OPTION" """ however the txt format is correct: """ battery_device_name=STRING ms_vm_genid="OPTION" """ It goes away after patch 3 is applied since it adds text about the "oem" option in between the two lines above. I'm at a loss as to why this is happening. Jason Andryuk (3): golang/xenlight: Extend KeyedUnion to support Arrays xl/libxl: Add ability to specify SMBIOS strings xl/libxl: Add OEM string support to smbios docs/man/xl.cfg.5.pod.in | 49 + tools/golang/xenlight/gengotypes.py | 41 ++--- tools/golang/xenlight/helpers.gen.go | 51 + tools/golang/xenlight/types.gen.go | 28 tools/include/libxl.h| 5 +++ tools/libs/light/libxl_dom.c | 32 ++ tools/libs/light/libxl_types.idl | 27 tools/xl/xl_parse.c | 66 +++- 8 files changed, 282 insertions(+), 17 deletions(-) -- 2.37.3
[PATCH v2 1/3] golang/xenlight: Extend KeyedUnion to support Arrays
Generation for KeyedUnion types doesn't support Arrays. The smbios
support will place an smbios array inside the hvm KeyedUnion, and
gentotypes doesn't generate buildable Go code.
Have KeyedUnion add an idl.Array check and issue the approriate
xenlight_golang_array_to_C and xenlight_golang_array_from_C calls when
needed. This matches how it is done in xenlight_golang_define_to_C &
xenlight_golang_define_from_C
xenlight_golang_array_to_C and xenlight_golang_array_from_C need to be
extended to set the cvarname and govarname as approriate for the
KeyedUnion cases to match the surrounding code.
Signed-off-by: Jason Andryuk
---
tools/golang/xenlight/gengotypes.py | 41 ++---
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/tools/golang/xenlight/gengotypes.py
b/tools/golang/xenlight/gengotypes.py
index ac1cf060dd..745a3cb466 100644
--- a/tools/golang/xenlight/gengotypes.py
+++ b/tools/golang/xenlight/gengotypes.py
@@ -374,6 +374,10 @@ def xenlight_golang_union_from_C(ty = None, union_name =
'', struct_name = ''):
s += 'tmp :=
(*C.{0})(unsafe.Pointer({1}[0]))\n'.format(typename,union_name)
for nf in f.type.fields:
+if isinstance(nf.type, idl.Array):
+s += xenlight_golang_array_from_C(nf,cvarname='tmp')
+continue
+
s += xenlight_golang_convert_from_C(nf,cvarname='tmp')
s += 'return nil\n'
@@ -414,7 +418,7 @@ def xenlight_golang_union_from_C(ty = None, union_name =
'', struct_name = ''):
return (s,extras)
-def xenlight_golang_array_from_C(ty = None):
+def xenlight_golang_array_from_C(ty = None, cvarname = 'xc'):
"""
Convert C array to Go slice using the method
described here:
@@ -431,9 +435,9 @@ def xenlight_golang_array_from_C(ty = None):
clenvar= ty.type.lenvar.name
s += 'x.{0} = nil\n'.format(goname)
-s += 'if n := int(xc.{0}); n > 0 {{\n'.format(clenvar)
+s += 'if n := int({0}.{1}); n > 0 {{\n'.format(cvarname,clenvar)
s += '{0} := '.format(cslice)
-s +='(*[1<<28]C.{0})(unsafe.Pointer(xc.{1}))[:n:n]\n'.format(ctypename,
cname)
+s +='(*[1<<28]C.{0})(unsafe.Pointer({1}.{2}))[:n:n]\n'.format(ctypename,
cvarname, cname)
s += 'x.{0} = make([]{1}, n)\n'.format(goname, gotypename)
s += 'for i, v := range {0} {{\n'.format(cslice)
@@ -577,6 +581,11 @@ def xenlight_golang_union_to_C(ty = None, union_name = '',
s += 'var {0} C.{1}\n'.format(f.name,cgotype)
for uf in f.type.fields:
+if isinstance(uf.type, idl.Array):
+s += xenlight_golang_array_to_C(uf, cvarname=f.name,
+govarname="tmp")
+continue
+
s += xenlight_golang_convert_to_C(uf,cvarname=f.name,
govarname='tmp')
@@ -594,7 +603,7 @@ def xenlight_golang_union_to_C(ty = None, union_name = '',
return s
-def xenlight_golang_array_to_C(ty = None):
+def xenlight_golang_array_to_C(ty = None, cvarname="xc", govarname="x"):
s = ''
gotypename = xenlight_golang_fmt_name(ty.type.elem_type.typename)
@@ -606,27 +615,27 @@ def xenlight_golang_array_to_C(ty = None):
is_enum = isinstance(ty.type.elem_type,idl.Enumeration)
if gotypename in go_builtin_types or is_enum:
-s += 'if {0} := len(x.{1}); {2} > 0
{{\n'.format(golenvar,goname,golenvar)
-s += 'xc.{0} =
(*C.{1})(C.malloc(C.size_t({2}*{3})))\n'.format(cname,ctypename,
+s += 'if {0} := len({1}.{2}); {3} > 0
{{\n'.format(golenvar,govarname,goname,golenvar)
+s += '{0}.{1} =
(*C.{2})(C.malloc(C.size_t({3}*{4})))\n'.format(cvarname,cname,ctypename,
golenvar,golenvar)
-s += 'xc.{0} = C.int({1})\n'.format(clenvar,golenvar)
-s += 'c{0} :=
(*[1<<28]C.{1})(unsafe.Pointer(xc.{2}))[:{3}:{4}]\n'.format(goname,
-
ctypename,cname,
+s += '{0}.{1} = C.int({2})\n'.format(cvarname,clenvar,golenvar)
+s += 'c{0} :=
(*[1<<28]C.{1})(unsafe.Pointer({2}.{3}))[:{4}:{5}]\n'.format(goname,
+
ctypename,cvarname,cname,
golenvar,golenvar)
-s += 'for i,v := range x.{0} {{\n'.format(goname)
+s += 'for i,v := range {0}.{1} {{\n'.format(govarname,goname)
s += 'c{0}[i] = C.{1}(v)\n'.format(goname,ctypename)
s += '}\n}\n'
return s
-s += 'if {0} := len(x.{1}); {2} > 0 {{\n'.format(golenvar,goname,golenvar)
-s += 'xc.{0} =
(*C.{1})(C.malloc(C.ulong({2})*C.sizeof_{3}))\n'.format(cname,ctypename,
+s += 'if {0} := len({1}.{2}); {3} > 0
{{\n'.format(golenvar,govarname,goname,golenvar)
+s += '{0}.{1} =
[ovmf test] 173068: regressions - FAIL
flight 173068 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/173068/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136 version targeted for testing: ovmf d82ec90f51f61c914396271d86e64a74121dde24 baseline version: ovmf 444260d45ec2a84e8f8c192b3539a3cd5591d009 Last test of basis 172136 2022-08-04 06:43:42 Z 35 days Failing since172151 2022-08-05 02:40:28 Z 34 days 268 attempts Testing same since 173057 2022-09-08 03:17:03 Z0 days4 attempts People who touched revisions under test: "Lee, Chun-Yi" Abdul Lateef Attar Abner Chang Annie Li Ard Biesheuvel Bob Feng Chasel Chiu Chen, Xiao X Corvin Köhne Czajkowski, Maciej Dimitrije Pavlov Dun Tan Edward Pickup Feng, Bob C Foster Nong Gerd Hoffmann Gregx Yeh Guo Dong Igor Kulchytskyy James Lu Jeff Brasen Jianyong Wu Jiaxin Wu Jose Marinho KasimX Liu Kavya Konstantin Aladyshev Kun Qin Laszlo Ersek Lee, Chun-Yi Liming Gao Liu, Zhiguang Maciej Czajkowski Michael D Kinney Michael Kubacki Min M Xu Min Xu Oliver Steffen Pierre Gondois Pranav Madhu Ray Ni Rebecca Cran Rebecca Cran Rohit Mathew Sainadh Nagolu Sami Mujawar Sebastien Boeuf Shengfengx Xue Wenyi Xie Wu, Jiaxin Xiao X Chen Yuan Yu Yuanhao Xie Zhiguang Liu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 2203 lines long.)
[libvirt test] 173058: regressions - FAIL
flight 173058 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/173058/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a version targeted for testing: libvirt 72cf345bc2de97a5f60f97a09926b9673ea46704 baseline version: libvirt 2c846fa6bcc11929c9fb857a22430fb9945654ad Last test of basis 151777 2020-07-10 04:19:19 Z 790 days Failing since151818 2020-07-11 04:18:52 Z 789 days 771 attempts Testing same since 173058 2022-09-08 04:19:06 Z0 days1 attempts People who touched revisions under test: Adolfo Jayme Barrientos Aleksandr Alekseev Aleksei Zakharov Amneesh Singh Andika Triwidada Andrea Bolognani Andrew Melnychenko Ani Sinha Balázs Meskó Barrett Schonefeld Bastian Germann Bastien Orivel BiaoXiang Ye Bihong Yu Binfeng Wu Bjoern Walk Boris Fiuczynski Brad Laue Brian Turek Bruno Haible Carlos Bilbao Chris Mayo Christian Borntraeger Christian Ehrhardt Christian Kirbach Christian Schoenebeck Christophe de Dinechin Christophe Fergeau Claudio Fontana Cole Robinson Collin Walling Cornelia Huck Cédric Bosdonnat Côme Borsoi Daniel Henrique Barboza Daniel Letai Daniel P. Berrange Daniel P. Berrangé Dario Faggioli David Michael Didik Supriadi dinglimin Divya Garg Dmitrii Shcherbakov Dmytro Linkin Eiichi Tsukata Emilio Herrera Eric Farman Erik Skultety Eugenio Pérez Fabian Affolter Fabian Freyer Fabiano Fidêncio Fangge Jin Farhan Ali Fedora Weblate Translation Florian Schmidt Franck Ridel Gavi Teitz gongwei Guoyi Tu Göran Uddeborg Halil Pasic Han Han Hao Wang Haonan Wang Hela Basa Helmut Grohne Hiroki Narukawa Hyman Huang(黄勇) Ian Wienand Ioanna Alifieraki Ivan Teterevkov Jakob Meng Jamie Strandboge Jamie Strandboge Jan Kuparinen jason lee Jean-Baptiste Holcroft Jia Zhou Jianan Gao jiangjiacheng Jim Fehlig Jin Yan Jing Qi Jinsheng Zhang Jiri Denemark Joachim Falk John Ferlan John Levon John Levon Jonathan Watt Jonathon Jongsma Julio Faracco Justin Gatzen Ján Tomko Kashyap Chamarthy Kevin Locke Kim InSoo Koichi Murase Kristina Hanicova Laine Stump Laszlo Ersek Lee Yarwood Lei Yang Lena Voytek Liang Yan Liang Yan Liao Pingfang Lin Ma Lin Ma Lin Ma Liu Yiding Lubomir Rintel Ludek Janda Luke Yue Luyao Zhong luzhipeng Marc Hartmayer Marc-André Lureau Marek Marczykowski-Górecki Mark Mielke Markus Schade Martin Kletzander Martin Pitt Masayoshi Mizuma Matej Cepl Matt Coleman Matt Coleman Mauro Matteo Cascella Max Goodhart Maxim Nestratov Meina Li Michal Privoznik Michał Smyk Milo Casagrande minglei.liu Moshe Levi Moteen Shah Moteen Shah Muha Aliss Nathan Neal Gompa Nick Chevsky Nick Shyrokovskiy Nickys Music Group Nico Pache Nicolas Lécureuil Nicolas Lécureuil Nikolay Shirokovskiy Nikolay Shirokovskiy Nikolay Shirokovskiy Niteesh Dubey Olaf Hering
Re: [PATCH 3/3] xl/libxl: Add OEM string support to smbios
On Thu, Sep 8, 2022 at 9:14 AM Anthony PERARD wrote:
>
> On Wed, Aug 10, 2022 at 03:48:27PM -0400, Jason Andryuk wrote:
> > Add support for OEM strings in the SMBIOS type 11.
> >
> > hvmloader checks them sequentially, so hide the implementation detail.
> > Allow multiple plain oem= items and assign the numeric values
> > internally.
> >
> > Signed-off-by: Jason Andryuk
> > ---
> > docs/man/xl.cfg.5.pod.in | 4 ++
> > tools/golang/xenlight/types.gen.go | 99 ++
> > tools/libs/light/libxl_types.idl | 99 ++
> > tools/xl/xl_parse.c| 15 +
> > 4 files changed, 217 insertions(+)
> >
> > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> > index 7edf5d23f3..7947bf07ea 100644
> > --- a/docs/man/xl.cfg.5.pod.in
> > +++ b/docs/man/xl.cfg.5.pod.in
> > @@ -2104,8 +2104,12 @@ Each B is a C string
> > from the following list:
> >
> > =item B
> >
> > +=item B
> > +
> > =back
> >
> > +oem= strings can be specified mutiple times up to a limit of 99.
>
> This could be move to just before =back I think.
Moved like you suggest, the man page output is:
"""
oem=STRING
oem= strings can be specified mutiple times up to a limit of
99.
ms_vm_genid="OPTION"
"""
I'll also re-word to "oem= can be specified up to 99 times."
> > +
> > =item B
> >
> > Provide a VM generation ID to the guest.
> > diff --git a/tools/libs/light/libxl_types.idl
> > b/tools/libs/light/libxl_types.idl
> > index d04207748e..58f404af37 100644
> > --- a/tools/libs/light/libxl_types.idl
> > +++ b/tools/libs/light/libxl_types.idl
> > @@ -436,6 +436,105 @@ libxl_smbios_type = Enumeration("smbios_type", [
> > (15, "enclosure_asset_tag"),
> > (16, "battery_manufacturer"),
> > (17, "battery_device_name"),
> > +(18, "oem_1"),
> > +(19, "oem_2"),
> > +(20, "oem_3"),
> [...]
> > +(115, "oem_98"),
> > +(116, "oem_99"),
>
> Instead of this long lists of enum value, could we just have one "oem"
> type, and allow it to be used more than once? I know that would mean
> having a special case in libxl, but that also mean that libxl will be
> the only one to deal with the implementation detail on how to write oem
> string for hvmloader (as opposed to deal with this in every application
> using libxl).
I'll pursue a single "oem" type. Also, I'll check the count in both
libxl and xl. While only the libxl check is needed, it seems better
to detect issues while parsing the config instead of only later during
the domain build.
Thanks,
Jason
[PATCH v8 7/9] xen/arm: create shared memory nodes in guest device tree
We expose the shared memory to the domU using the "xen,shared-memory-v1"
reserved-memory binding. See
Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt
in Linux for the corresponding device tree binding.
To save the cost of re-parsing shared memory device tree configuration when
creating shared memory nodes in guest device tree, this commit adds new field
"shm_mem" to store shm-info per domain.
For each shared memory region, a range is exposed under
the /reserved-memory node as a child node. Each range sub-node is
named xen-shmem@ and has the following properties:
- compatible:
compatible = "xen,shared-memory-v1"
- reg:
the base guest physical address and size of the shared memory region
- xen,id:
a string that identifies the shared memory region.
- xen,offset: (borrower VMs only)
64 bit integer offset within the owner virtual machine's shared
memory region used for the mapping in the borrower VM.
Currently, we provide "xen,offset=<0x0>" as a temprary placeholder.
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
---
v8 changes:
- Fix missing property "xen,offset" for borrower VMs by temporarily
adding "xen,offset=<0x0>"
- use >= to avoid thinking about the overflow case for nr_banks
- check the return value of dt_property_read_string() for parsing
shm_id
- struct meminfo *mem and char resvbuf[16] = "reserved-memory" could be
const
- change "__be32 reg[4]" to "__be32 reg[GUEST_ROOT_ADDRESS_CELLS +
GUEST_ROOT_SIZE_CELLS]"
---
v7 changes:
- allocate reg for worst case addrcells + sizecells
- replace assert() with BUG_ON() since it is init code
---
v6 change:
- change "struct meminfo *mem" to "const struct meminfo *mem"
- change "unsigned long i" to "unsigned int i" to match the type of nr_banks.
- accroding to the Linux binding, "xen,id" is meant to be a string, not
an integer
---
v5 change:
- no change
---
v4 change:
- no change
---
v3 change:
- move field "shm_mem" to kernel_info
---
v2 change:
- using xzalloc
- shm_id should be uint8_t
- make reg a local variable
- add #address-cells and #size-cells properties
- fix alignment
---
xen/arch/arm/domain_build.c | 160 +-
xen/arch/arm/include/asm/kernel.h | 1 +
2 files changed, 159 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index a10d07266b..cd03370b38 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -914,7 +914,22 @@ static int __init assign_shared_memory(struct domain *d,
return ret;
}
-static int __init process_shm(struct domain *d,
+static int __init append_shm_bank_to_domain(struct kernel_info *kinfo,
+paddr_t start, paddr_t size,
+const char *shm_id)
+{
+if ( kinfo->shm_mem.nr_banks >= NR_MEM_BANKS )
+return -ENOMEM;
+
+kinfo->shm_mem.bank[kinfo->shm_mem.nr_banks].start = start;
+kinfo->shm_mem.bank[kinfo->shm_mem.nr_banks].size = size;
+safe_strcpy(kinfo->shm_mem.bank[kinfo->shm_mem.nr_banks].shm_id, shm_id);
+kinfo->shm_mem.nr_banks++;
+
+return 0;
+}
+
+static int __init process_shm(struct domain *d, struct kernel_info *kinfo,
const struct dt_device_node *node)
{
struct dt_device_node *shm_node;
@@ -928,6 +943,7 @@ static int __init process_shm(struct domain *d,
int ret = 0;
unsigned int i;
const char *role_str;
+const char *shm_id;
bool owner_dom_io = true;
if ( !dt_device_is_compatible(shm_node, "xen,domain-shared-memory-v1")
)
@@ -972,6 +988,13 @@ static int __init process_shm(struct domain *d,
if ( dt_property_read_string(shm_node, "role", _str) == 0 )
owner_dom_io = false;
+if ( dt_property_read_string(shm_node, "xen,shm-id", _id) )
+{
+printk("%pd: invalid \"xen,shm-id\" property", d);
+return -EINVAL;
+}
+BUG_ON((strlen(shm_id) <= 0) || (strlen(shm_id) >= MAX_SHM_ID_LENGTH));
+
/*
* DOMID_IO is a fake domain and is not described in the Device-Tree.
* Therefore when the owner of the shared region is DOMID_IO, we will
@@ -999,6 +1022,14 @@ static int __init process_shm(struct domain *d,
if ( ret )
return ret;
}
+
+/*
+ * Record static shared memory region info for later setting
+ * up shm-node in guest device tree.
+ */
+ret = append_shm_bank_to_domain(kinfo, gbase, psize, shm_id);
+if ( ret )
+return ret;
}
return 0;
@@ -1331,6 +1362,126 @@ static int __init make_memory_node(const struct domain
*d,
return res;
}
+#ifdef CONFIG_STATIC_SHM
+static int __init make_shm_memory_node(const struct domain *d,
+ void *fdt,
+ int addrcells,
[PATCH v8 2/9] xen/arm: assign static shared memory to the default owner dom_io
From: Penny Zheng
This commit introduces process_shm to cope with static shared memory in
domain construction.
DOMID_IO will be the default owner of memory pre-shared among multiple domains
at boot time, when no explicit owner is specified.
And DOMID_IO is a fake domain and is not described in the Device-Tree.
Therefore When the owner of the shared region is DOMID_IO, we will only
find the borrowers when parsing the Device-Tree.
When we found the first borrower of the region, we need to assign the region to
DOMID_IO
This commit only considers allocating static shared memory to dom_io
when owner domain is not explicitly defined in device tree, all the left,
including the "borrower" code path, the "explicit owner" code path, shall
be introduced later in the following patches.
Signed-off-by: Penny Zheng
Reviewed-by: Julien Grall
---
v8 changes:
- in-code comment tweak
---
v7 changes:
- page_get_owner() can only be called for pages that are marked inuse,
so use page_get_owner_and_reference() instead
- reference shall be dropped using put_page()
- adjust "d->max_pages" when acquire_domstatic_pages() fails
- switch from assert to BUG_ON() because this is init code
- refine commit message and in-code comments
- rename allocate_shared_memory() to assign_shared_memory()
---
v6 change:
- use if-array to check psize, pbase and gbase are suitably aligned and
valid
- use mfn_valid to check (pbase, pbase + psize)
- check d->max_pages will not overflow
- refine acquire_shared_memory_bank to not reuse acquire_static_memory_bank,
then input pbase and psize do not need to be used as a pointer.
- use if-array to check if page owner is dom_io
- in-code comment refinement
---
v5 change:
- refine in-code comment
---
v4 change:
- no changes
---
v3 change:
- refine in-code comment
---
v2 change:
- instead of introducing a new system domain, reuse the existing dom_io
- make dom_io a non-auto-translated domain, then no need to create P2M
for it
- change dom_io definition and make it wider to support static shm here too
- introduce is_shm_allocated_to_domio to check whether static shm is
allocated yet, instead of using shm_mask bitmap
- add in-code comment
---
xen/arch/arm/domain_build.c | 160
xen/common/domain.c | 3 +
2 files changed, 163 insertions(+)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 0741645014..e30ee65621 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -759,6 +759,160 @@ static void __init assign_static_memory_11(struct domain
*d,
panic("Failed to assign requested static memory for direct-map domain
%pd.",
d);
}
+
+#ifdef CONFIG_STATIC_SHM
+/*
+ * This function checks whether the static shared memory region is
+ * already allocated to dom_io.
+ */
+static bool __init is_shm_allocated_to_domio(paddr_t pbase)
+{
+struct page_info *page;
+struct domain *d;
+
+page = maddr_to_page(pbase);
+d = page_get_owner_and_reference(page);
+if ( d == NULL )
+return false;
+put_page(page);
+
+if ( d != dom_io )
+{
+printk(XENLOG_ERR
+ "shm memory node has already been allocated to a specific owner
%pd, Please check your configuration\n",
+ d);
+return false;
+}
+
+return true;
+}
+
+static mfn_t __init acquire_shared_memory_bank(struct domain *d,
+ paddr_t pbase, paddr_t psize)
+{
+mfn_t smfn;
+unsigned long nr_pfns;
+int res;
+
+/*
+ * Pages of statically shared memory shall be included
+ * into domain_tot_pages().
+ */
+nr_pfns = PFN_DOWN(psize);
+if ( (UINT_MAX - d->max_pages) < nr_pfns )
+{
+printk(XENLOG_ERR "%pd: Over-allocation for d->max_pages: %lu.\n",
+ d, nr_pfns);
+return INVALID_MFN;
+}
+d->max_pages += nr_pfns;
+
+smfn = maddr_to_mfn(pbase);
+res = acquire_domstatic_pages(d, smfn, nr_pfns, 0);
+if ( res )
+{
+printk(XENLOG_ERR
+ "%pd: failed to acquire static memory: %d.\n", d, res);
+d->max_pages -= nr_pfns;
+return INVALID_MFN;
+}
+
+return smfn;
+}
+
+static int __init assign_shared_memory(struct domain *d,
+ uint32_t addr_cells, uint32_t
size_cells,
+ paddr_t pbase, paddr_t psize)
+{
+mfn_t smfn;
+
+dprintk(XENLOG_INFO,
+"%pd: allocate static shared memory BANK
%#"PRIpaddr"-%#"PRIpaddr".\n",
+d, pbase, pbase + psize);
+
+smfn = acquire_shared_memory_bank(d, pbase, psize);
+if ( mfn_eq(smfn, INVALID_MFN) )
+return -EINVAL;
+
+/*
+ * DOMID_IO is not auto-translated (i.e. it sees RAM 1:1). So we do not
need
+ * to create mapping in the P2M.
+ */
+ASSERT(d == dom_io);
+return 0;
+}
+
+static int __init process_shm(struct domain *d,
+
RE: [PATCH v4 2/6] xen/x86: move generically usable NUMA code from x86 to common
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2022年9月8日 19:42
> To: Wei Chen
> Cc: nd ; Andrew Cooper ; Roger Pau
> Monné ; Wei Liu ; George Dunlap
> ; Julien Grall ; Stefano
> Stabellini ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v4 2/6] xen/x86: move generically usable NUMA code
> from x86 to common
>
> On 08.09.2022 12:32, Wei Chen wrote:
> > On 2022/9/8 17:09, Jan Beulich wrote:
> >> On 02.09.2022 05:31, Wei Chen wrote:
> >>> --- /dev/null
> >>> +++ b/xen/common/numa.c
> >>> @@ -0,0 +1,442 @@
> >>> +/*
> >>> + * Generic VM initialization for NUMA setups.
> >>> + * Copyright 2002,2003 Andi Kleen, SuSE Labs.
> >>> + * Adapted for Xen: Ryan Harper
> >>> + */
> >>> +
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +
> >>> +struct node_data __ro_after_init node_data[MAX_NUMNODES];
> >>> +
> >>> +/* Mapping from pdx to node id */
> >>> +unsigned int __ro_after_init memnode_shift;
> >>> +unsigned long __ro_after_init memnodemapsize;
> >>> +uint8_t *__ro_after_init memnodemap;
> >>> +static uint8_t __ro_after_init _memnodemap[64];
> >>
> >> These last two want to use nodeid_t instead of uint8_t. Originally
> >> the latter used typeof(*memnodemap) for (I think - iirc it was me who
> >> made it that way) this reason: That way correcting memnodemap's type
> >> would have propagated without the need for further adjustments.
> >>
> >
> > Thanks for this info, should I need to restore it to use
> > "typeof(*memnodemap)" in next version ?
>
> That would be more in line with the original code, but it's not
> strictly necessary once nodeid_t if properly used for these variables.
> I'd leave it up to you as long as you switch to nodeid_t.
>
Ok, I will think more about it in next version.
> >>> +nodeid_t __read_mostly cpu_to_node[NR_CPUS] = {
> >>> +[0 ... NR_CPUS-1] = NUMA_NO_NODE
> >>> +};
> >>> +
> >>> +cpumask_t __read_mostly node_to_cpumask[MAX_NUMNODES];
> >>> +
> >>> +nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
> >>> +
> >>> +bool __read_mostly numa_off;
> >>
> >> The v3 review discussing this possibly becoming __ro_after_init didn't
> >> really finish (you didn't reply to my latest request there), but you
> >> also didn't change the attribute. Please clarify.
> >>
> >
> > I think I had answered your question by:
> > >> I think yes, it will be used in numa_disabled and numa_disabled will
> > >> be called in cpu_add."
> >
> > And you replied me with:
> > > In the original code I cannot spot such a path - can you please point
> > > out how exactly you see numa_disabled() reachable from cpu_add()? I'm
> > > clearly overlooking something ..."
> >
> > But there is a time difference here, your reply was sent after I sent
> > v3, maybe you didn't notice it
>
> Which suggests you might better have waited with sending v3 until the
> discussion had settled.
>
> > About the new question:
> > cpu_add will call srat_disabled, srat_disabled will access numa_off.
> > srat_disabled is a function without __init.
>
> But the request wasn't to make the variable __initdata. That would be
> wrong of course. Since srat_disabled() only reads numa_off,
> __ro_after_init does look usable to me.
>
Oh, yes, you're right. I had thought wrong. I will correct this.
Cheers,
Wei Chen.
> Jan
Re: [PATCH 2/3] xl/libxl: Add ability to specify SMBIOS strings
On Thu, Sep 8, 2022 at 8:40 AM Anthony PERARD wrote:
> > ---
> > diff --git a/tools/libs/light/libxl_dom.c b/tools/libs/light/libxl_dom.c
> > index 2abaab439c..9034933ea8 100644
> > --- a/tools/libs/light/libxl_dom.c
> > +++ b/tools/libs/light/libxl_dom.c
> > @@ -771,6 +771,26 @@ static int hvm_build_set_xs_values(libxl__gc *gc,
> > goto err;
> > }
> >
> > +for (int i = 0; i < info->u.hvm.num_smbios; i++) {
> > +char *p;
> > +path = GCSPRINTF("/local/domain/%d/"HVM_XS_BIOS_STRINGS"/%s",
> > domid,
> > + libxl_smbios_type_to_string(info->u.hvm.smbios[i].key));
> > +
> > +/* libxl defines are all "_", but the HVM_XS_ strings are "-". */
>
> "libxl defines are all "_"" seems a bit weird to me as a comment in
> the source code, maybe a better comment would the conversion we need to
> do, something like:
>
> Convert libxl_smbios_type string to xenstore path that hvmloader
> will use, as defined by HVM_XS_*. That is convert the '_' to '-'.
I'll use this. All your other comments sound good, and I'll change accordingly.
Thanks for taking a look.
-Jason
[PATCH v8 9/9] xen: Add static memory sharing in SUPPORT.md
on ARM, static memory sharing is tech preview, which shall be documented in SUPPORT.md Signed-off-by: Penny Zheng Reviewed-by: Michal Orzel Acked-by: Julien Grall --- v8 changes: - no change --- v7 changes: - doc refinement --- v6 change: - new commit --- SUPPORT.md | 7 +++ 1 file changed, 7 insertions(+) diff --git a/SUPPORT.md b/SUPPORT.md index 8e040d1c1e..1979824ce5 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -299,6 +299,13 @@ Allow sharing of identical pages between guests Status, x86 HVM: Experimental +### Static Memory Sharing + +Allow to statically set up shared memory on dom0less system, +enabling domains to do shm-based communication + +Status, ARM: Tech Preview + ### Memory Paging Allow pages belonging to guests to be paged to disk -- 2.25.1
[PATCH v8 3/9] xen/arm: allocate static shared memory to a specific owner domain
If owner property is defined, then owner domain of a static shared memory
region is not the default dom_io anymore, but a specific domain.
This commit implements allocating static shared memory to a specific domain
when owner property is defined.
Coding flow for dealing borrower domain will be introduced later in the
following commits.
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
---
v8 changes:
- no change
---
v7 chhanges:
- adapt to the previous commits' changes
---
v6 change:
- fix coding-style
- role_str and owner_dom_io shall be defined within the loop
---
v5 change:
- no change
---
v4 change:
- no changes
---
v3 change:
- simplify the code since o_gbase is not used if the domain is dom_io
---
v2 change:
- P2M mapping is restricted to normal domain
- in-code comment fix
---
xen/arch/arm/domain_build.c | 36 +---
1 file changed, 29 insertions(+), 7 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index e30ee65621..fe0a96764d 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -822,9 +822,11 @@ static mfn_t __init acquire_shared_memory_bank(struct
domain *d,
static int __init assign_shared_memory(struct domain *d,
uint32_t addr_cells, uint32_t
size_cells,
- paddr_t pbase, paddr_t psize)
+ paddr_t pbase, paddr_t psize,
+ paddr_t gbase)
{
mfn_t smfn;
+int ret = 0;
dprintk(XENLOG_INFO,
"%pd: allocate static shared memory BANK
%#"PRIpaddr"-%#"PRIpaddr".\n",
@@ -838,8 +840,18 @@ static int __init assign_shared_memory(struct domain *d,
* DOMID_IO is not auto-translated (i.e. it sees RAM 1:1). So we do not
need
* to create mapping in the P2M.
*/
-ASSERT(d == dom_io);
-return 0;
+if ( d != dom_io )
+{
+ret = guest_physmap_add_pages(d, gaddr_to_gfn(gbase), smfn,
+ PFN_DOWN(psize));
+if ( ret )
+{
+printk(XENLOG_ERR "Failed to map shared memory to %pd.\n", d);
+return ret;
+}
+}
+
+return ret;
}
static int __init process_shm(struct domain *d,
@@ -855,6 +867,8 @@ static int __init process_shm(struct domain *d,
paddr_t gbase, pbase, psize;
int ret = 0;
unsigned int i;
+const char *role_str;
+bool owner_dom_io = true;
if ( !dt_device_is_compatible(shm_node, "xen,domain-shared-memory-v1")
)
continue;
@@ -891,20 +905,28 @@ static int __init process_shm(struct domain *d,
return -EINVAL;
}
-/* TODO: Consider owner domain is not the default dom_io. */
+/*
+ * "role" property is optional and if it is defined explicitly,
+ * then the owner domain is not the default "dom_io" domain.
+ */
+if ( dt_property_read_string(shm_node, "role", _str) == 0 )
+owner_dom_io = false;
+
/*
* DOMID_IO is a fake domain and is not described in the Device-Tree.
* Therefore when the owner of the shared region is DOMID_IO, we will
* only find the borrowers.
*/
-if ( !is_shm_allocated_to_domio(pbase) )
+if ( (owner_dom_io && !is_shm_allocated_to_domio(pbase)) ||
+ (!owner_dom_io && strcmp(role_str, "owner") == 0) )
{
/*
* We found the first borrower of the region, the owner was not
* specified, so they should be assigned to dom_io.
*/
-ret = assign_shared_memory(dom_io, addr_cells, size_cells,
- pbase, psize);
+ret = assign_shared_memory(owner_dom_io ? dom_io : d,
+ addr_cells, size_cells,
+ pbase, psize, gbase);
if ( ret )
return ret;
}
--
2.25.1
[PATCH v8 1/9] xen/arm: introduce static shared memory
This patch series introduces a new feature: setting up static
shared memory on a dom0less system, through device tree configuration.
This commit parses shared memory node at boot-time, and reserve it in
bootinfo.reserved_mem to avoid other use.
This commits proposes a new Kconfig CONFIG_STATIC_SHM to wrap
static-shm-related codes, and this option depends on static memory(
CONFIG_STATIC_MEMORY). That's because that later we want to reuse a few
helpers, guarded with CONFIG_STATIC_MEMORY, like acquire_staticmem_pages, etc,
on static shared memory.
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
---
v8 changes:
- return errno immediately when overflow checks meet
- remove pointless WARN()
---
v7 changes:
- add docs about checking for region overlap, etc
- update docs to reflect that the host physical address is optional
- end/bank_end may end up to be lower than paddr/mem->bank[i].start, So check
that they don't overflow.
- replace strcmp with strncmp since the string has already be validated
- provide a dummy helper for process_shm_node() when !CONFIG_STATIC_SHM
- remove useless #ifdef CONFIG_STATIC_SHM
- change the order of property xen,shared-mem to
xen,shared-mem = < [host physical address] [guest address] [size] >
---
v6 change:
- when host physical address is ommited, output the error message since
xen doesn't support it at the moment
- add the following check: 1) The shm ID matches and the region exactly match
2) The shm ID doesn't match and the region doesn't overlap
- change it to "unsigned int" to be aligned with nr_banks
- check the len of the property to confirm is it big enough to
contain "paddr", "size", and "gaddr"
- shm_id defined before nr_shm_domain, so we could re-use the existing hole and
avoid increasing the size of the structure.
- change "nr_shm_domain" to "nr_shm_borrowers", to not increment if the role
is owner in parsing code
- make "xen,shm_id" property as arbitrary string, with a strict limit on
the number of characters, MAX_SHM_ID_LENGTH
---
v5 change:
- no change
---
v4 change:
- nit fix on doc
---
v3 change:
- make nr_shm_domain unsigned int
---
v2 change:
- document refinement
- remove bitmap and use the iteration to check
- add a new field nr_shm_domain to keep the number of shared domain
---
docs/misc/arm/device-tree/booting.txt | 132
xen/arch/arm/Kconfig | 6 +
xen/arch/arm/bootfdt.c| 167 ++
xen/arch/arm/include/asm/setup.h | 7 ++
4 files changed, 312 insertions(+)
diff --git a/docs/misc/arm/device-tree/booting.txt
b/docs/misc/arm/device-tree/booting.txt
index 5ba7d186aa..0acd42f1a8 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -426,3 +426,135 @@ Below is an example on how to specify the static heap in
device tree:
RAM starting from the host physical address 0x3000 of 1GB size will
be reserved as static heap.
+
+Static Shared Memory
+
+
+The static shared memory device tree nodes allow users to statically set up
+shared memory on dom0less system, enabling domains to do shm-based
+communication.
+
+- compatible
+
+"xen,domain-shared-memory-v1"
+
+- xen,shm-id
+
+An arbitrary string that represents the unique identifier of the shared
+memory region, with a strict limit on the number of characters(\0
included),
+`MAX_SHM_ID_LENGTH(16)`. e.g. "xen,shm-id = "my-shared-mem-1"".
+
+- xen,shared-mem
+
+An array takes a physical address, which is the base address of the
+shared memory region in host physical address space, a size, and a guest
+physical address, as the target address of the mapping.
+e.g. xen,shared-mem = < [host physical address] [guest address] [size] >
+
+It shall also meet the following criteria:
+1) If the SHM ID matches with an existing region, the address range of the
+region shall also exactly match.
+2) If the SHM ID does not match with any other existing region, it should
+also not overlap with any other regions.
+
+The number of cells for the host address (and size) is the same as the
+guest pseudo-physical address and they are inherited from the parent node.
+
+Host physical address is optional, when missing Xen decides the location
+(currently unimplemented).
+
+- role (Optional)
+
+A string property specifying the ownership of a shared memory region,
+the value must be one of the following: "owner", or "borrower"
+A shared memory region could be explicitly backed by one domain, which is
+called "owner domain", and all the other domains who are also sharing
+this region are called "borrower domain".
+If not specified, the default value is "borrower" and owner is
+DOMID_IO, a system domain.
+
+As an example:
+
+chosen {
+#address-cells = <0x1>;
+#size-cells = <0x1>;
+xen,xen-bootargs = "console=dtuart dtuart=serial0 bootscrub=0";
+
+..
+
+/* this is
[ovmf test] 173066: regressions - FAIL
flight 173066 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/173066/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136 version targeted for testing: ovmf d82ec90f51f61c914396271d86e64a74121dde24 baseline version: ovmf 444260d45ec2a84e8f8c192b3539a3cd5591d009 Last test of basis 172136 2022-08-04 06:43:42 Z 35 days Failing since172151 2022-08-05 02:40:28 Z 34 days 267 attempts Testing same since 173057 2022-09-08 03:17:03 Z0 days3 attempts People who touched revisions under test: "Lee, Chun-Yi" Abdul Lateef Attar Abner Chang Annie Li Ard Biesheuvel Bob Feng Chasel Chiu Chen, Xiao X Corvin Köhne Czajkowski, Maciej Dimitrije Pavlov Dun Tan Edward Pickup Feng, Bob C Foster Nong Gerd Hoffmann Gregx Yeh Guo Dong Igor Kulchytskyy James Lu Jeff Brasen Jianyong Wu Jiaxin Wu Jose Marinho KasimX Liu Kavya Konstantin Aladyshev Kun Qin Laszlo Ersek Lee, Chun-Yi Liming Gao Liu, Zhiguang Maciej Czajkowski Michael D Kinney Michael Kubacki Min M Xu Min Xu Oliver Steffen Pierre Gondois Pranav Madhu Ray Ni Rebecca Cran Rebecca Cran Rohit Mathew Sainadh Nagolu Sami Mujawar Sebastien Boeuf Shengfengx Xue Wenyi Xie Wu, Jiaxin Xiao X Chen Yuan Yu Yuanhao Xie Zhiguang Liu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 2203 lines long.)
Re: [PATCH v4 5/6] xen/x86: move NUMA scan nodes codes from x86 to common
On 08.09.2022 17:26, Wei Chen wrote: >> -Original Message- >> From: Jan Beulich >> Sent: 2022年9月8日 21:03 >> >> On 02.09.2022 05:31, Wei Chen wrote: >>> --- a/xen/arch/x86/numa.c >>> +++ b/xen/arch/x86/numa.c >>> @@ -41,9 +41,12 @@ int __init arch_numa_setup(const char *opt) >>> return -EINVAL; >>> } >>> >>> -bool arch_numa_disabled(void) >>> +bool arch_numa_disabled(bool init_as_disable) >> >> I'm afraid my question as to the meaning of the name of the parameter has >> remained unanswered. >> > > Sorry, I might missed some contents of your reply in v3. The name of this > parameter has been bothering me for a long time, and now this is actually > quite awkward. The origin of this parameter is because the current NUMA > implementation will make different judgments under different usage > conditions when using acpi_numa. In acpi_scan_nodes, it uses acpi_numa <= 0 > as the condition for judging that ACPI NUMA is turned off. But only use > acpi_numa < 0 as condition in srat_disabled and elsewhere. I use this > parameter in the hope that we can keep the same semantics as the original > code without changing the code of the caller. The difference is "bad only" vs "bad or no data". Maybe that's easier to express via two functions - arch_numa_disabled() (checking <= 0) and arch_numa_broken() (checking < 0)? With a single function I guess the name of the parameter would always be clumsy at best. Unless someone has a good idea for a suitable name ... >>> --- a/xen/drivers/acpi/Kconfig >>> +++ b/xen/drivers/acpi/Kconfig >>> @@ -7,4 +7,5 @@ config ACPI_LEGACY_TABLES_LOOKUP >>> >>> config ACPI_NUMA >>> bool >>> + select HAS_NUMA_NODE_FWID >> >> Are you selecting an option here which doesn't exist anywhere? Or >> am I overlooking where this new option is being added? >> > > Yes, this is a new Kconfig option. Should I need to introduce in a > separate patch? I don't think that'll need to be in a separate patch; it can simply be another hunk in the one here, adding the needed 2 lines (plus a blank one) to, presumably, common/Kconfig. Jan
RE: [PATCH v4 5/6] xen/x86: move NUMA scan nodes codes from x86 to common
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2022年9月8日 21:03
> To: Wei Chen
> Cc: nd ; Andrew Cooper ; Roger Pau
> Monné ; Wei Liu ; George Dunlap
> ; Julien Grall ; Stefano
> Stabellini ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v4 5/6] xen/x86: move NUMA scan nodes codes from x86
> to common
>
> On 02.09.2022 05:31, Wei Chen wrote:
> > --- a/xen/arch/x86/numa.c
> > +++ b/xen/arch/x86/numa.c
> > @@ -41,9 +41,12 @@ int __init arch_numa_setup(const char *opt)
> > return -EINVAL;
> > }
> >
> > -bool arch_numa_disabled(void)
> > +bool arch_numa_disabled(bool init_as_disable)
>
> I'm afraid my question as to the meaning of the name of the parameter has
> remained unanswered.
>
Sorry, I might missed some contents of your reply in v3. The name of this
parameter has been bothering me for a long time, and now this is actually
quite awkward. The origin of this parameter is because the current NUMA
implementation will make different judgments under different usage
conditions when using acpi_numa. In acpi_scan_nodes, it uses acpi_numa <= 0
as the condition for judging that ACPI NUMA is turned off. But only use
acpi_numa < 0 as condition in srat_disabled and elsewhere. I use this
parameter in the hope that we can keep the same semantics as the original
code without changing the code of the caller.
> > @@ -306,32 +218,27 @@ acpi_numa_processor_affinity_init(const struct
> acpi_srat_cpu_affinity *pa)
> > void __init
> > acpi_numa_memory_affinity_init(const struct acpi_srat_mem_affinity *ma)
> > {
> > - struct node *nd;
> > - paddr_t nd_start, nd_end;
> > - paddr_t start, end;
> > unsigned pxm;
> > nodeid_t node;
> > - unsigned int i;
> >
> > if (numa_disabled())
> > return;
> > if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
> > - bad_srat();
> > + numa_fw_bad();
> > return;
> > }
> > if (!(ma->flags & ACPI_SRAT_MEM_ENABLED))
> > return;
> >
> > - start = ma->base_address;
> > - end = start + ma->length;
> > /* Supplement the heuristics in l1tf_calculations(). */
> > - l1tf_safe_maddr = max(l1tf_safe_maddr, ROUNDUP(end, PAGE_SIZE));
> > + l1tf_safe_maddr = max(l1tf_safe_maddr,
> > + ROUNDUP(ma->base_address + ma->length,
> > + PAGE_SIZE));
>
> Indentation:
>
> l1tf_safe_maddr = max(l1tf_safe_maddr,
> ROUNDUP(ma->base_address + ma->length,
> PAGE_SIZE));
>
Ok.
> > @@ -33,7 +48,309 @@ bool __read_mostly numa_off;
> >
> > bool numa_disabled(void)
> > {
> > -return numa_off || arch_numa_disabled();
> > +return numa_off || arch_numa_disabled(false);
> > +}
> > +
> > +void __init numa_set_processor_nodes_parsed(nodeid_t node)
> > +{
> > +node_set(node, processor_nodes_parsed);
> > +}
> > +
> > +bool valid_numa_range(paddr_t start, paddr_t end, nodeid_t node)
> > +{
> > +unsigned int i;
> > +
> > +for ( i = 0; i < num_node_memblks; i++ )
> > +{
> > +struct node *nd = _memblk_range[i];
>
> const? (This is particularly relevant with __ro_after_init.)
>
Yes, I will fix it.
> > +bool __init numa_update_node_memblks(nodeid_t node, unsigned int
> arch_nid,
> > + paddr_t start, paddr_t size,
> > + const char *prefix,
> > + bool hotplug)
> > +{
> > +unsigned int i;
> > +paddr_t end = start + size;
> > +paddr_t nd_start = start;
> > +paddr_t nd_end = end;
> > +struct node *nd = [node];
> > +
> > +/*
> > + * For the node that already has some memory blocks, we will
> > + * expand the node memory range temporarily to check memory
> > + * interleaves with other nodes. We will not use this node
> > + * temp memory range to check overlaps, because it will mask
> > + * the overlaps in same node.
> > + *
> > + * Node with 0 bytes memory doesn't need this expandsion.
>
> Mind taking the opportunity and drop the 'd' from "expansion"?
>
Ok.
> > + */
> > +if ( nd->start != nd->end )
> > +{
> > +if ( nd_start > nd->start )
> > +nd_start = nd->start;
> > +
> > +if ( nd_end < nd->end )
> > +nd_end = nd->end;
> > +}
> > +
> > +/* It is fine to add this area to the nodes data it will be used
> later */
> > +switch ( conflicting_memblks(node, start, end, nd_start, nd_end,
> ) )
> > +{
> > +case OVERLAP:
> > +if ( memblk_nodeid[i] == node )
> > +{
> > +bool mismatch = !(hotplug) != !test_bit(i, memblk_hotplug);
>
> No need to parenthesize "hotplug" here.
>
Ok
> > +printk("%sNUMA: %s %u [%"PRIpaddr", %"PRIpaddr"] overlaps
> with itself [%"PRIpaddr", %"PRIpaddr"]\n",
> > + mismatch ? KERN_ERR : KERN_WARNING, prefix,
> > +
[xen-unstable-smoke test] 173064: tolerable FAIL - PUSHED
flight 173064 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/173064/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a build-amd64-libvirt 6 libvirt-buildfail like 173061 test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen 6bc1c1aba01f663687d7d2b48ccdf8d9432d92cc baseline version: xen 64e302157a87b246473a31fa104377a6d48eb046 Last test of basis 173061 2022-09-08 08:01:53 Z0 days Testing same since 173064 2022-09-08 12:01:50 Z0 days1 attempts People who touched revisions under test: Henry Wang Jan Beulich Juergen Gross Julien Grall Penny Zheng Rahul Singh Stanislav Kinsburskii jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt fail test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 64e302157a..6bc1c1aba0 6bc1c1aba01f663687d7d2b48ccdf8d9432d92cc -> smoke
[linux-5.4 test] 173056: regressions - FAIL
flight 173056 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/173056/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-vhd broken in 173048 build-i386-libvirt6 libvirt-buildfail REGR. vs. 172128 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172128 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 172128 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 172128 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-vhd 5 host-install(5) broken in 173048 pass in 173056 test-amd64-i386-qemuu-rhel6hvm-intel 8 xen-boot fail in 173048 pass in 173056 test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail pass in 173048 test-amd64-amd64-examine 13 examine-iommu fail pass in 173048 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 18 guest-start/debian.repeat fail in 173048 blocked in 172128 test-armhf-armhf-xl-credit2 14 guest-start fail in 173048 like 172128 test-armhf-armhf-xl-multivcpu 14 guest-startfail in 173048 like 172128 test-armhf-armhf-xl-credit1 15 migrate-support-check fail in 173048 never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail in 173048 never pass test-armhf-armhf-xl-credit2 18 guest-start/debian.repeatfail like 172108 test-armhf-armhf-xl-multivcpu 18 guest-start/debian.repeatfail like 172108 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 172108 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 172128 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 172128 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 172128 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 172128 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 172128 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 172128 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 172128 test-armhf-armhf-xl-credit1 14 guest-start fail like 172128 test-armhf-armhf-xl-rtds 18 guest-start/debian.repeatfail like 172128 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 172128 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl
RE: [PATCH v4 4/6] xen/x86: use arch_get_ram_range to get information from E820 map
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2022年9月8日 20:14
> To: Wei Chen
> Cc: nd ; Andrew Cooper ; Roger Pau
> Monné ; Wei Liu ; George Dunlap
> ; Julien Grall ; Stefano
> Stabellini ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v4 4/6] xen/x86: use arch_get_ram_range to get
> information from E820 map
>
> On 02.09.2022 05:31, Wei Chen wrote:
> > The sanity check of nodes_cover_memory is also a requirement of
> > other architectures that support NUMA. But now, the code of
> > nodes_cover_memory is tied to the x86 E820. In this case, we
> > introduce arch_get_ram_range to decouple architecture specific
> > memory map from this function. This means, other architectures
> > like Arm can also use it to check its node and memory coverage
> > from bootmem info.
> >
> > Depends arch_get_ram_range, we make nodes_cover_memory become
> > architecture independent. We also use neutral words to replace
> > SRAT and E820 in the print message of this function. This will
> > to make the massage seems more common.
> >
> > As arch_get_ram_range use unsigned int for index, we also adjust
> > the index in nodes_cover_memory from int to unsigned int.
> >
> > Signed-off-by: Wei Chen
>
> Reviewed-by: Jan Beulich
> albeit still with a couple of suggestions:
>
Thanks, I will adjust the code comments to address your suggestions.
> > --- a/xen/arch/x86/srat.c
> > +++ b/xen/arch/x86/srat.c
> > @@ -428,37 +428,43 @@ acpi_numa_memory_affinity_init(const struct
> acpi_srat_mem_affinity *ma)
> > Make sure the PXMs cover all memory. */
> > static int __init nodes_cover_memory(void)
> > {
> > - int i;
> > + unsigned int i;
> >
> > - for (i = 0; i < e820.nr_map; i++) {
> > - int j, found;
> > + for (i = 0; ; i++) {
> > + int err;
> > + unsigned int j;
> > + bool found;
> > paddr_t start, end;
> >
> > - if (e820.map[i].type != E820_RAM) {
> > - continue;
> > - }
> > + /* Try to loop memory map from index 0 to end to get RAM
> ranges. */
> > + err = arch_get_ram_range(i, , );
> >
> > - start = e820.map[i].addr;
> > - end = e820.map[i].addr + e820.map[i].size;
> > + /* Reach the end of arch's memory map */
> > + if (err == -ENOENT)
> > + break;
>
> Such a comment ahead of an if() is often better put as a question, e.g.
> "Reached the end of the memory map?" here or, if you dislike using a
> question, "Exit the loop at the end of the memory map".
>
> > + /* Index relate entry is not RAM, skip it. */
> > + if (err)
> > + continue;
>
> And then perhaps "Skip non-RAM entries" here.
>
> > --- a/xen/include/xen/numa.h
> > +++ b/xen/include/xen/numa.h
> > @@ -81,6 +81,19 @@ static inline nodeid_t __attribute_pure__
> phys_to_nid(paddr_t addr)
> > #define node_end_pfn(nid) (NODE_DATA(nid)->node_start_pfn + \
> > NODE_DATA(nid)->node_spanned_pages)
> >
> > +/*
> > + * This function provides the ability for caller to get one RAM entry
> > + * from architectural memory map by index.
> > + *
> > + * This function will return zero if it can return a proper RAM entry.
> > + * otherwise it will return -ENOENT for out of scope index, or return
> > + * -ENODATA for non-RAM type memory entry.
>
> The way you've implemented things, -ENODATA isn't special anymore, so
> better wouldn't be called out as special here. May I suggest to at
> least insert "e.g." in front of it? (An alternative would be to check
> for -ENODATA in nodes_cover_memory() again, followed by ASSERT(!err).)
>
> > + * Note: the range is exclusive at the end, e.g. [start, end).
>
> Perhaps better [*start, *end) to match ...
>
> > + */
> > +extern int arch_get_ram_range(unsigned int idx,
> > + paddr_t *start, paddr_t *end);
>
> ... this?
>
> Jan
[PATCH v8 8/9] xen/arm: enable statically shared memory on Dom0
From: Penny Zheng
To add statically shared memory nodes in Dom0, user shall put according
static shared memory configuration under /chosen node.
This commit adds shm-processing function process_shm in construct_dom0
to enable statically shared memory on Dom0.
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
---
v8 changes:
- no change
---
v7 changes:
- no change
---
v6 change:
- no change
---
v5 change:
- no change
---
v4 change:
- no change
---
v3 change:
- no change
---
v2 change:
- no change
---
xen/arch/arm/domain_build.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index cd03370b38..8c77c764bc 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2705,6 +2705,11 @@ static int __init handle_node(struct domain *d, struct
kernel_info *kinfo,
if ( res )
return res;
}
+
+res = make_resv_memory_node(d, kinfo->fdt, addrcells, sizecells,
+>shm_mem);
+if ( res )
+return res;
}
res = fdt_end_node(kinfo->fdt);
@@ -3780,6 +3785,9 @@ static int __init construct_dom0(struct domain *d)
{
struct kernel_info kinfo = {};
int rc;
+#ifdef CONFIG_STATIC_SHM
+const struct dt_device_node *chosen = dt_find_node_by_path("/chosen");
+#endif
/* Sanity! */
BUG_ON(d->domain_id != 0);
@@ -3814,6 +3822,12 @@ static int __init construct_dom0(struct domain *d)
allocate_memory_11(d, );
find_gnttab_region(d, );
+#ifdef CONFIG_STATIC_SHM
+rc = process_shm(d, , chosen);
+if ( rc < 0 )
+return rc;
+#endif
+
/* Map extra GIC MMIO, irqs and other hw stuffs to dom0. */
rc = gic_map_hwdom_extra_mappings(d);
if ( rc < 0 )
--
2.25.1
[PATCH v8 6/9] xen/arm: set up shared memory foreign mapping for borrower domain
This commit sets up shared memory foreign mapping for borrower domain.
If owner domain is the default dom_io, all shared domain are treated as
borrower domain.
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
---
v8 changes:
- no change
---
v7 change:
- no changes
---
v6 change:
- no change
---
v5 change:
- no change
---
v4 changes:
- no change
---
v3 change:
- use map_regions_p2mt instead
---
v2 change:
- remove guest_physmap_add_shm, since for borrower domain, we only
do P2M foreign memory mapping now.
---
xen/arch/arm/domain_build.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 4aab9b0865..a10d07266b 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -990,6 +990,15 @@ static int __init process_shm(struct domain *d,
if ( ret )
return ret;
}
+
+if ( owner_dom_io || (strcmp(role_str, "borrower") == 0) )
+{
+/* Set up P2M foreign mapping for borrower domain. */
+ret = map_regions_p2mt(d, _gfn(PFN_UP(gbase)), PFN_DOWN(psize),
+ _mfn(PFN_UP(pbase)), p2m_map_foreign_rw);
+if ( ret )
+return ret;
+}
}
return 0;
--
2.25.1
[PATCH v8 4/9] xen/arm: introduce put_page_nr and get_page_nr
Later, we need to add the right amount of references, which should be
the number of borrower domains, to the owner domain. Since we only have
get_page() to increment the page reference by 1, a loop is needed per
page, which is inefficient and time-consuming.
To save the loop time, this commit introduces a set of new helpers
put_page_nr() and get_page_nr() to increment/drop the page reference by nr.
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
Reviewed-by: Julien Grall
---
v8 change
- no change
---
v7 change:
- no change
---
v6 change:
- no change
---
v5 change:
- no change
---
v4 changes:
- fix the assert about checking overflow to make sure that the right equation
return is at least equal to nr
- simplify the assert about checking the underflow
---
v3 changes:
- check overflow with "n"
- remove spurious change
- bring back the check that we enter the loop only when count_info is
greater than 0
---
v2 change:
- new commit
---
xen/arch/arm/include/asm/mm.h | 4
xen/arch/arm/mm.c | 42 +++
2 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
index 7b4f6ce233..d8553ad207 100644
--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -360,6 +360,10 @@ void free_init_memory(void);
int guest_physmap_mark_populate_on_demand(struct domain *d, unsigned long gfn,
unsigned int order);
+extern bool get_page_nr(struct page_info *page, const struct domain *domain,
+unsigned long nr);
+extern void put_page_nr(struct page_info *page, unsigned long nr);
+
extern void put_page_type(struct page_info *page);
static inline void put_page_and_type(struct page_info *page)
{
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 4a70ed2986..535c465672 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1461,21 +1461,29 @@ long arch_memory_op(int op,
XEN_GUEST_HANDLE_PARAM(void) arg)
return 0;
}
-struct domain *page_get_owner_and_reference(struct page_info *page)
+static struct domain *page_get_owner_and_nr_reference(struct page_info *page,
+ unsigned long nr)
{
unsigned long x, y = page->count_info;
struct domain *owner;
+/* Restrict nr to avoid "double" overflow */
+if ( nr >= PGC_count_mask )
+{
+ASSERT_UNREACHABLE();
+return NULL;
+}
+
do {
x = y;
/*
* Count == 0: Page is not allocated, so we cannot take a reference.
* Count == -1: Reference count would wrap, which is invalid.
*/
-if ( unlikely(((x + 1) & PGC_count_mask) <= 1) )
+if ( unlikely(((x + nr) & PGC_count_mask) <= nr) )
return NULL;
}
-while ( (y = cmpxchg(>count_info, x, x + 1)) != x );
+while ( (y = cmpxchg(>count_info, x, x + nr)) != x );
owner = page_get_owner(page);
ASSERT(owner);
@@ -1483,14 +1491,19 @@ struct domain *page_get_owner_and_reference(struct
page_info *page)
return owner;
}
-void put_page(struct page_info *page)
+struct domain *page_get_owner_and_reference(struct page_info *page)
+{
+return page_get_owner_and_nr_reference(page, 1);
+}
+
+void put_page_nr(struct page_info *page, unsigned long nr)
{
unsigned long nx, x, y = page->count_info;
do {
-ASSERT((y & PGC_count_mask) != 0);
+ASSERT((y & PGC_count_mask) >= nr);
x = y;
-nx = x - 1;
+nx = x - nr;
}
while ( unlikely((y = cmpxchg(>count_info, x, nx)) != x) );
@@ -1503,19 +1516,30 @@ void put_page(struct page_info *page)
}
}
-bool get_page(struct page_info *page, const struct domain *domain)
+void put_page(struct page_info *page)
+{
+put_page_nr(page, 1);
+}
+
+bool get_page_nr(struct page_info *page, const struct domain *domain,
+ unsigned long nr)
{
-const struct domain *owner = page_get_owner_and_reference(page);
+const struct domain *owner = page_get_owner_and_nr_reference(page, nr);
if ( likely(owner == domain) )
return true;
if ( owner != NULL )
-put_page(page);
+put_page_nr(page, nr);
return false;
}
+bool get_page(struct page_info *page, const struct domain *domain)
+{
+return get_page_nr(page, domain, 1);
+}
+
/* Common code requires get_page_type and put_page_type.
* We don't care about typecounts so we just do the minimum to make it
* happy. */
--
2.25.1
[PATCH v8 5/9] xen/arm: Add additional reference to owner domain when the owner is allocated
Borrower domain will fail to get a page ref using the owner domain
during allocation, when the owner is created after borrower.
So here, we decide to get and add the right amount of reference, which
is the number of borrowers, when the owner is allocated.
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
Acked-by: Julien Grall
---
v8 changes:
- no change
---
v7 changes:
- change "unsigned long bank" to "unsigned int bank"
---
v6 change:
- adapt to the change of "nr_shm_borrowers"
- add in-code comment to explain if the borrower is created first, we intend to
add pages in the P2M without reference.
---
v5 change:
- no change
---
v4 changes:
- no change
---
v3 change:
- printk rather than dprintk since it is a serious error
---
v2 change:
- new commit
---
xen/arch/arm/domain_build.c | 60 +
1 file changed, 60 insertions(+)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index fe0a96764d..4aab9b0865 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -761,6 +761,30 @@ static void __init assign_static_memory_11(struct domain
*d,
}
#ifdef CONFIG_STATIC_SHM
+static int __init acquire_nr_borrower_domain(struct domain *d,
+ paddr_t pbase, paddr_t psize,
+ unsigned long *nr_borrowers)
+{
+unsigned int bank;
+
+/* Iterate reserved memory to find requested shm bank. */
+for ( bank = 0 ; bank < bootinfo.reserved_mem.nr_banks; bank++ )
+{
+paddr_t bank_start = bootinfo.reserved_mem.bank[bank].start;
+paddr_t bank_size = bootinfo.reserved_mem.bank[bank].size;
+
+if ( (pbase == bank_start) && (psize == bank_size) )
+break;
+}
+
+if ( bank == bootinfo.reserved_mem.nr_banks )
+return -ENOENT;
+
+*nr_borrowers = bootinfo.reserved_mem.bank[bank].nr_shm_borrowers;
+
+return 0;
+}
+
/*
* This function checks whether the static shared memory region is
* already allocated to dom_io.
@@ -827,6 +851,8 @@ static int __init assign_shared_memory(struct domain *d,
{
mfn_t smfn;
int ret = 0;
+unsigned long nr_pages, nr_borrowers, i;
+struct page_info *page;
dprintk(XENLOG_INFO,
"%pd: allocate static shared memory BANK
%#"PRIpaddr"-%#"PRIpaddr".\n",
@@ -840,6 +866,7 @@ static int __init assign_shared_memory(struct domain *d,
* DOMID_IO is not auto-translated (i.e. it sees RAM 1:1). So we do not
need
* to create mapping in the P2M.
*/
+nr_pages = PFN_DOWN(psize);
if ( d != dom_io )
{
ret = guest_physmap_add_pages(d, gaddr_to_gfn(gbase), smfn,
@@ -851,6 +878,39 @@ static int __init assign_shared_memory(struct domain *d,
}
}
+/*
+ * Get the right amount of references per page, which is the number of
+ * borrower domains.
+ */
+ret = acquire_nr_borrower_domain(d, pbase, psize, _borrowers);
+if ( ret )
+return ret;
+
+/*
+ * Instead of letting borrower domain get a page ref, we add as many
+ * additional reference as the number of borrowers when the owner
+ * is allocated, since there is a chance that owner is created
+ * after borrower.
+ * So if the borrower is created first, it will cause adding pages
+ * in the P2M without reference.
+ */
+page = mfn_to_page(smfn);
+for ( i = 0; i < nr_pages; i++ )
+{
+if ( !get_page_nr(page + i, d, nr_borrowers) )
+{
+printk(XENLOG_ERR
+ "Failed to add %lu references to page %"PRI_mfn".\n",
+ nr_borrowers, mfn_x(smfn) + i);
+goto fail;
+}
+}
+
+return 0;
+
+ fail:
+while ( --i >= 0 )
+put_page_nr(page + i, nr_borrowers);
return ret;
}
--
2.25.1
[PATCH v8 0/9] static shared memory on dom0less system
**This series is based on the "Introduce static heap" series[1]** In safety-critical environment, it is not considered safe to dynamically change important configurations at runtime. Everything should be statically defined and statically verified. In this case, if the system configuration knows a priori that there are only 2 VMs and they need to communicate over shared memory, it is safer to pre-configure the shared memory at build time rather than let the VMs attempt to share memory at runtime. And it is faster too. Furthermore, on dom0less system, the legacy way to build up communication channels between domains, like grant table, are normally absent there. So this patch serie introduces a set of static shared memory device tree nodes to allow users to statically set up shared memory on dom0less system, enabling domains to do shm-based communication. The only way to trigger this static shared memory configuration should be via device tree, which is at the same level as the XSM rules. It was inspired by the patch serie of ["xl/libxl-based shared mem]( https://marc.info/?l=xen-devel=154404821731186ory;). Looking into related [design link]( https://lore.kernel.org/all/a50d9fde-1d06-7cda-2779-9eea9e1c0...@xen.org/T/) for more details. [1] https://lore.kernel.org/xen-devel/20220908042538.27076-1-henry.w...@arm.com/ Penny Zheng (9): xen/arm: introduce static shared memory xen/arm: assign static shared memory to the default owner dom_io xen/arm: allocate static shared memory to a specific owner domain xen/arm: introduce put_page_nr and get_page_nr xen/arm: Add additional reference to owner domain when the owner is allocated xen/arm: set up shared memory foreign mapping for borrower domain xen/arm: create shared memory nodes in guest device tree xen/arm: enable statically shared memory on Dom0 xen: Add static memory sharing in SUPPORT.md SUPPORT.md| 7 + docs/misc/arm/device-tree/booting.txt | 132 xen/arch/arm/Kconfig | 6 + xen/arch/arm/bootfdt.c| 167 ++ xen/arch/arm/domain_build.c | 421 ++ xen/arch/arm/include/asm/kernel.h | 1 + xen/arch/arm/include/asm/mm.h | 4 + xen/arch/arm/include/asm/setup.h | 7 + xen/arch/arm/mm.c | 42 ++- xen/common/domain.c | 3 + 10 files changed, 781 insertions(+), 9 deletions(-) -- 2.25.1
Re: [PATCH V5 1/6] libxl: Add support for Virtio I2C device
On Wed, Sep 07, 2022 at 06:02:24PM +0530, Viresh Kumar wrote: > Hi Anthony, > > Thanks a lot for the in-depth review, it is really helpful. > > I don't have much knowledge of the Xen code and wanted this code for I2C and > GPIO to be tested on Xen for the work we are doing around hypervisor agnostic > backends [1]. > > I started looking for a simple device's implementation and began by (blindly) > copying code from Keyboard device and so much of wasted code in here, which > isn't really required. > > On 06-09-22, 17:15, Anthony PERARD wrote: > > On Mon, Aug 22, 2022 at 02:45:13PM +0530, Viresh Kumar wrote: > > > An example of domain configuration for Virtio I2c: > > > i2c = [ "" ] > > > > Is this doing something meaningful (with the whole series applied)? > > If I am not wrong, this is required by parse_i2c_list()'s implementation. > Without this I don't get the I2C device populated in the guest. Sorry, I should have added more context to may question. In my mind, I2C is just a communication protocol between a device and a CPU, like USB or PCI. So to me there is missing information about which device or kind of device to present to a guest in this example. For example, for PCI we give a path to the device (via bdf=), and for USB it can be a kind of device to emulate or select a device based on the path to it (bus, addr). Cheers, -- Anthony PERARD
Re: [PATCH 3/3] xl/libxl: Add OEM string support to smbios
On Wed, Aug 10, 2022 at 03:48:27PM -0400, Jason Andryuk wrote:
> Add support for OEM strings in the SMBIOS type 11.
>
> hvmloader checks them sequentially, so hide the implementation detail.
> Allow multiple plain oem= items and assign the numeric values
> internally.
>
> Signed-off-by: Jason Andryuk
> ---
> docs/man/xl.cfg.5.pod.in | 4 ++
> tools/golang/xenlight/types.gen.go | 99 ++
> tools/libs/light/libxl_types.idl | 99 ++
> tools/xl/xl_parse.c| 15 +
> 4 files changed, 217 insertions(+)
>
> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> index 7edf5d23f3..7947bf07ea 100644
> --- a/docs/man/xl.cfg.5.pod.in
> +++ b/docs/man/xl.cfg.5.pod.in
> @@ -2104,8 +2104,12 @@ Each B is a C string
> from the following list:
>
> =item B
>
> +=item B
> +
> =back
>
> +oem= strings can be specified mutiple times up to a limit of 99.
This could be move to just before =back I think.
> +
> =item B
>
> Provide a VM generation ID to the guest.
> diff --git a/tools/libs/light/libxl_types.idl
> b/tools/libs/light/libxl_types.idl
> index d04207748e..58f404af37 100644
> --- a/tools/libs/light/libxl_types.idl
> +++ b/tools/libs/light/libxl_types.idl
> @@ -436,6 +436,105 @@ libxl_smbios_type = Enumeration("smbios_type", [
> (15, "enclosure_asset_tag"),
> (16, "battery_manufacturer"),
> (17, "battery_device_name"),
> +(18, "oem_1"),
> +(19, "oem_2"),
> +(20, "oem_3"),
[...]
> +(115, "oem_98"),
> +(116, "oem_99"),
Instead of this long lists of enum value, could we just have one "oem"
type, and allow it to be used more than once? I know that would mean
having a special case in libxl, but that also mean that libxl will be
the only one to deal with the implementation detail on how to write oem
string for hvmloader (as opposed to deal with this in every application
using libxl).
> ])
>
> libxl_smbios = Struct("smbios", [
> diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
> index 4f3f962773..fb7f1f6867 100644
> --- a/tools/xl/xl_parse.c
> +++ b/tools/xl/xl_parse.c
> @@ -1787,12 +1787,16 @@ void parse_config_data(const char *config_source,
> switch (xlu_cfg_get_list(config, "smbios", , _smbios, 0))
> {
> case 0: /* Success */
> +{
> +unsigned int num_oem = 1;
> +
> b_info->u.hvm.num_smbios = num_smbios;
> b_info->u.hvm.smbios = xcalloc(num_smbios, sizeof(libxl_smbios));
> for (i = 0; i < num_smbios; i++) {
> char *option_untrimmed, *value_untrimmed;
> char *option, *value;
> libxl_smbios_type v;
> +char oem_buf[] = "oem_99";
>
> buf = xlu_cfg_get_listitem(smbios, i);
> if (!buf) continue;
> @@ -1807,6 +1811,16 @@ void parse_config_data(const char *config_source,
> trim(isspace, option_untrimmed, );
> trim(isspace, value_untrimmed, );
>
> +if (strcmp(option, "oem") == 0) {
> +if (num_oem > 99) {
> +fprintf(stderr, "xl: sbmios oem strings limited to
> 99\n");
> +exit(-ERROR_FAIL);
> +}
> +sprintf(oem_buf, "oem_%d", num_oem);
> +num_oem++;
> +option = oem_buf;
This mean that my proposal to free option in the previous patch isn't
going to work well. But you could free option before assigning a new
value.
An alternative to generate a string to be converted to an enum
value would be to simply do "LIBXL_SMBIOS_TYPE_OEM_1+num_oem-1".
Or just deal with oem string in libxl as proposed above.
> +}
> +
> e = libxl_smbios_type_from_string(option, );
> if (e) {
> fprintf(stderr,
> @@ -1819,6 +1833,7 @@ void parse_config_data(const char *config_source,
> b_info->u.hvm.smbios[i].value = value;
> }
> break;
> +}
> case ESRCH: break; /* Option not present */
> default:
> fprintf(stderr,"xl: Unable to parse smbios options.\n");
Thanks,
--
Anthony PERARD
Re: [PATCH v5 2/2] xen/pci: replace call to is_memory_hole to pci_check_bar
Hi Jan, On 08/09/2022 13:03, Jan Beulich wrote: On 08.09.2022 13:49, Rahul Singh wrote: is_memory_hole was implemented for x86 and not for ARM when introduced. Replace is_memory_hole call to pci_check_bar as function should check if device BAR is in defined memory range. Also, add an implementation for ARM which is required for PCI passthrough. On x86, pci_check_bar will call is_memory_hole which will check if BAR is not overlapping with any memory region defined in the memory map. On ARM, pci_check_bar will go through the host bridge ranges and check if the BAR is in the range of defined ranges. Signed-off-by: Rahul Singh Acked-by: Jan Beulich # x86, common FTAOD: I object to this tagging, and I did not provide the ack with such tags. Quoting docs/process/sending-patches.pandoc: "The `Acked-by:` tag can only be given by a **maintainer** of the modified code, and it only covers the code the maintainer is responsible for." You are part of the REST. So technically, one could assume that your acked-by would also cover the Arm. I agree this would be uncommon but this has been used before when the more specialized maintainer was unresponsive. At least with # x86, common it is clear what you are happy with. The doc provides for tagging here, yes, but such should only be used for the unusual case of an ack restricted to less than what a person's maintainership covers. Otherwise we'd end up seeing overly many tagged acks. I appreciate you may not like them but it helps while committing because you can cross-check easily whether all the files have been covered with the tags. Cheers, -- Julien Grall
Re: [PATCH] xen/locks: add dynamic lock recursion checks
On 08.09.2022 09:46, Juergen Gross wrote: > Add checking of lock recursion to the hypervisor. This is done by using > a percpu data array for storing the address of each taken lock. Any > attempt to take a lock twice (with the exception of recursive > spinlocks) will result in a crash. This is especially meant for > detecting attempts to take a rwlock multiple times as a reader, which > will only result in a deadlock in case of another cpu trying to get the > lock as a writer in between. > > The additional checks are not performance neutral, so they are enabled > only in debug builds per default, as the checks are active only with > CONFIG_DEBUG_LOCKS enabled. The size of the percpu data array can be > selected via a boot parameter. > > Signed-off-by: Juergen Gross > --- > Further possible enhancements: > - record address or file/line of locker, too > - add sanity check when exiting hypervisor or going to idle that all locks > have been released > > Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich But left in the queue for 4.18, ftaod. Jan
Re: [PATCH] docs/device-tree: Place the static-heap dt-binding in proper place
Hi Henry,
On 08/09/2022 13:07, Henry Wang wrote:
The static-heap dt-binding should be placed after the last feature,
namely static-evtchn.
Fixes: 4596329291f5 ("docs, xen/arm: Introduce static heap memory")
Signed-off-by: Henry Wang
Thanks for fixing the mistake I did while committing the patch :).
Acked-by: Julien Grall
Cheers,
--
Julien Grall
Re: [PATCH v4 5/6] xen/x86: move NUMA scan nodes codes from x86 to common
On 02.09.2022 05:31, Wei Chen wrote:
> --- a/xen/arch/x86/numa.c
> +++ b/xen/arch/x86/numa.c
> @@ -41,9 +41,12 @@ int __init arch_numa_setup(const char *opt)
> return -EINVAL;
> }
>
> -bool arch_numa_disabled(void)
> +bool arch_numa_disabled(bool init_as_disable)
I'm afraid my question as to the meaning of the name of the parameter has
remained unanswered.
> @@ -306,32 +218,27 @@ acpi_numa_processor_affinity_init(const struct
> acpi_srat_cpu_affinity *pa)
> void __init
> acpi_numa_memory_affinity_init(const struct acpi_srat_mem_affinity *ma)
> {
> - struct node *nd;
> - paddr_t nd_start, nd_end;
> - paddr_t start, end;
> unsigned pxm;
> nodeid_t node;
> - unsigned int i;
>
> if (numa_disabled())
> return;
> if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
> - bad_srat();
> + numa_fw_bad();
> return;
> }
> if (!(ma->flags & ACPI_SRAT_MEM_ENABLED))
> return;
>
> - start = ma->base_address;
> - end = start + ma->length;
> /* Supplement the heuristics in l1tf_calculations(). */
> - l1tf_safe_maddr = max(l1tf_safe_maddr, ROUNDUP(end, PAGE_SIZE));
> + l1tf_safe_maddr = max(l1tf_safe_maddr,
> + ROUNDUP(ma->base_address + ma->length,
> + PAGE_SIZE));
Indentation:
l1tf_safe_maddr = max(l1tf_safe_maddr,
ROUNDUP(ma->base_address + ma->length,
PAGE_SIZE));
> @@ -33,7 +48,309 @@ bool __read_mostly numa_off;
>
> bool numa_disabled(void)
> {
> -return numa_off || arch_numa_disabled();
> +return numa_off || arch_numa_disabled(false);
> +}
> +
> +void __init numa_set_processor_nodes_parsed(nodeid_t node)
> +{
> +node_set(node, processor_nodes_parsed);
> +}
> +
> +bool valid_numa_range(paddr_t start, paddr_t end, nodeid_t node)
> +{
> +unsigned int i;
> +
> +for ( i = 0; i < num_node_memblks; i++ )
> +{
> +struct node *nd = _memblk_range[i];
const? (This is particularly relevant with __ro_after_init.)
> +bool __init numa_update_node_memblks(nodeid_t node, unsigned int arch_nid,
> + paddr_t start, paddr_t size,
> + const char *prefix,
> + bool hotplug)
> +{
> +unsigned int i;
> +paddr_t end = start + size;
> +paddr_t nd_start = start;
> +paddr_t nd_end = end;
> +struct node *nd = [node];
> +
> +/*
> + * For the node that already has some memory blocks, we will
> + * expand the node memory range temporarily to check memory
> + * interleaves with other nodes. We will not use this node
> + * temp memory range to check overlaps, because it will mask
> + * the overlaps in same node.
> + *
> + * Node with 0 bytes memory doesn't need this expandsion.
Mind taking the opportunity and drop the 'd' from "expansion"?
> + */
> +if ( nd->start != nd->end )
> +{
> +if ( nd_start > nd->start )
> +nd_start = nd->start;
> +
> +if ( nd_end < nd->end )
> +nd_end = nd->end;
> +}
> +
> +/* It is fine to add this area to the nodes data it will be used later */
> +switch ( conflicting_memblks(node, start, end, nd_start, nd_end, ) )
> +{
> +case OVERLAP:
> +if ( memblk_nodeid[i] == node )
> +{
> +bool mismatch = !(hotplug) != !test_bit(i, memblk_hotplug);
No need to parenthesize "hotplug" here.
> +printk("%sNUMA: %s %u [%"PRIpaddr", %"PRIpaddr"] overlaps with
> itself [%"PRIpaddr", %"PRIpaddr"]\n",
> + mismatch ? KERN_ERR : KERN_WARNING, prefix,
> + arch_nid, start, end - 1,
> + node_memblk_range[i].start, node_memblk_range[i].end - 1);
> +if ( mismatch )
> +return false;
> +break;
> +}
> +
> +printk(KERN_ERR
> + "NUMA: %s %u [%"PRIpaddr", %"PRIpaddr"] overlaps with %s %u
> [%"PRIpaddr", %"PRIpaddr"]\n",
> + prefix, arch_nid, start, end - 1, prefix,
> + numa_node_to_arch_nid(memblk_nodeid[i]),
> + node_memblk_range[i].start, node_memblk_range[i].end - 1);
> +return false;
> +
> +
> +case INTERLEAVE:
Please don't add double blank lines anywhere (original code didn't have
these); there's at least one more instance below.
> +static int __init nodes_cover_memory(void)
> +{
> +unsigned int i;
> +
> +for ( i = 0; ; i++ )
> +{
> +int err;
> +bool found;
> +unsigned int j;
> +paddr_t start, end;
> +
> +/* Try to loop memory map from index 0 to end to get RAM ranges. */
> +err = arch_get_ram_range(i, , );
> +
> +/* Reach the end of arch's memory map */
> +if ( err == -ENOENT )
> +
[ovmf test] 173062: regressions - FAIL
flight 173062 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/173062/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136 version targeted for testing: ovmf d82ec90f51f61c914396271d86e64a74121dde24 baseline version: ovmf 444260d45ec2a84e8f8c192b3539a3cd5591d009 Last test of basis 172136 2022-08-04 06:43:42 Z 35 days Failing since172151 2022-08-05 02:40:28 Z 34 days 266 attempts Testing same since 173057 2022-09-08 03:17:03 Z0 days2 attempts People who touched revisions under test: "Lee, Chun-Yi" Abdul Lateef Attar Abner Chang Annie Li Ard Biesheuvel Bob Feng Chasel Chiu Chen, Xiao X Corvin Köhne Czajkowski, Maciej Dimitrije Pavlov Dun Tan Edward Pickup Feng, Bob C Foster Nong Gerd Hoffmann Gregx Yeh Guo Dong Igor Kulchytskyy James Lu Jeff Brasen Jianyong Wu Jiaxin Wu Jose Marinho KasimX Liu Kavya Konstantin Aladyshev Kun Qin Laszlo Ersek Lee, Chun-Yi Liming Gao Liu, Zhiguang Maciej Czajkowski Michael D Kinney Michael Kubacki Min M Xu Min Xu Oliver Steffen Pierre Gondois Pranav Madhu Ray Ni Rebecca Cran Rebecca Cran Rohit Mathew Sainadh Nagolu Sami Mujawar Sebastien Boeuf Shengfengx Xue Wenyi Xie Wu, Jiaxin Xiao X Chen Yuan Yu Yuanhao Xie Zhiguang Liu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 2203 lines long.)
Re: [PATCH 2/3] xl/libxl: Add ability to specify SMBIOS strings
On Wed, Aug 10, 2022 at 03:48:26PM -0400, Jason Andryuk wrote:
> hvm_xs_strings.h specifies xenstore entries which can be used to set or
> override smbios strings. hvmloader has support for reading them, but
> xl/libxl support is not wired up.
>
> Allow specifying the strings with the new xl.cfg option:
> smbios=["bios_vendor=Xen Project","system_version=1.0"]
>
> In terms of strings, the SMBIOS specification 3.5 says:
> https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.5.0.pdf
> """
> Strings must be encoded as UTF-8 with no byte order mark (BOM). For
> compatibility with older SMBIOS parsers, US-ASCII characters should be
> used. NOTE There is no limit on the length of each individual text
> string. However, the length of the entire structure table (including all
> strings) must be reported in the Structure Table Length field of the
> 32-bit Structure Table Entry Point (see 5.2.1) and/or the Structure
> Table Maximum Size field of the 64-bit Structure Table Entry Point (see
> 5.2.2).
> """
>
> The strings aren't checked for utf-8 or length. hvmloader has a sanity
> check on the overall length.
>
> The libxl_smbios_type enum starts at 1 since otherwise the 0th key is
> not printed in the json output.
>
> Signed-off-by: Jason Andryuk
> ---
> The rendered man page and html don't have a newline at then end of the
> new section.
> """
>battery_device_name=STRING
>ms_vm_genid="OPTION"
> """
>
> however the txt format is correct:
> """
> battery_device_name=STRING
>
> ms_vm_genid="OPTION"
> """
>
> I'm at a loss as to why this is happening.
Maybe it's because =back just cancel =over, and pod2man just keeps going
as if it's the same list. Adding some text for the =item or after =back
would help, but that's done in the next patch, so I guess we can live
with that for one commit.
> ---
> diff --git a/tools/libs/light/libxl_dom.c b/tools/libs/light/libxl_dom.c
> index 2abaab439c..9034933ea8 100644
> --- a/tools/libs/light/libxl_dom.c
> +++ b/tools/libs/light/libxl_dom.c
> @@ -771,6 +771,26 @@ static int hvm_build_set_xs_values(libxl__gc *gc,
> goto err;
> }
>
> +for (int i = 0; i < info->u.hvm.num_smbios; i++) {
> +char *p;
> +path = GCSPRINTF("/local/domain/%d/"HVM_XS_BIOS_STRINGS"/%s", domid,
> + libxl_smbios_type_to_string(info->u.hvm.smbios[i].key));
> +
> +/* libxl defines are all "_", but the HVM_XS_ strings are "-". */
"libxl defines are all "_"" seems a bit weird to me as a comment in
the source code, maybe a better comment would the conversion we need to
do, something like:
Convert libxl_smbios_type string to xenstore path that hvmloader
will use, as defined by HVM_XS_*. That is convert the '_' to '-'.
> +p = strrchr(path, '/');
> +for ( ; *p; p++) {
> +if (*p == '_')
> +*p = '-';
> +}
> +
> +LOGD(DEBUG, domid, "Writing %d %s %s\n", i, path,
I don't think printing the value of i would be useful here. Also adding
a '=' before the value and putting the value between double-quote would
be a bit better.
> + info->u.hvm.smbios[i].value);
> +ret = libxl__xs_printf(gc, XBT_NULL, path, "%s",
> + info->u.hvm.smbios[i].value);
> +if (ret)
> +goto err;
> +}
> +
> /* Only one module can be passed. PVHv2 guests do not support this. */
> if (dom->acpi_modules[0].guest_addr_out &&
> info->type == LIBXL_DOMAIN_TYPE_HVM) {
> diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
> index 1b5381cef0..4f3f962773 100644
> --- a/tools/xl/xl_parse.c
> +++ b/tools/xl/xl_parse.c
> @@ -1220,8 +1220,9 @@ void parse_config_data(const char *config_source,
> XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms,
> *usbctrls, *usbdevs, *p9devs, *vdispls, *pvcallsifs_devs;
> XLU_ConfigList *channels, *ioports, *irqs, *iomem, *viridian, *dtdevs,
> - *mca_caps;
> + *mca_caps, *smbios;
> int num_ioports, num_irqs, num_iomem, num_cpus, num_viridian,
> num_mca_caps;
> +int num_smbios;
> int pci_power_mgmt = 0;
> int pci_msitranslate = 0;
> int pci_permissive = 0;
> @@ -1783,6 +1784,47 @@ void parse_config_data(const char *config_source,
> xlu_cfg_replace_string(config, "acpi_firmware",
> _info->u.hvm.acpi_firmware, 0);
>
> +switch (xlu_cfg_get_list(config, "smbios", , _smbios, 0))
> +{
> +case 0: /* Success */
> +b_info->u.hvm.num_smbios = num_smbios;
> +b_info->u.hvm.smbios = xcalloc(num_smbios, sizeof(libxl_smbios));
> +for (i = 0; i < num_smbios; i++) {
> +char *option_untrimmed, *value_untrimmed;
> +char *option, *value;
> +libxl_smbios_type v;
> +
> +buf =
Re: [PATCH v5 2/2] xen/pci: replace call to is_memory_hole to pci_check_bar
Hi Jan, > On 8 Sep 2022, at 1:03 pm, Jan Beulich wrote: > > On 08.09.2022 13:49, Rahul Singh wrote: >> is_memory_hole was implemented for x86 and not for ARM when introduced. >> Replace is_memory_hole call to pci_check_bar as function should check >> if device BAR is in defined memory range. Also, add an implementation >> for ARM which is required for PCI passthrough. >> >> On x86, pci_check_bar will call is_memory_hole which will check if BAR >> is not overlapping with any memory region defined in the memory map. >> >> On ARM, pci_check_bar will go through the host bridge ranges and check >> if the BAR is in the range of defined ranges. >> >> Signed-off-by: Rahul Singh >> Acked-by: Jan Beulich # x86, common > > FTAOD: I object to this tagging, and I did not provide the ack with > such tags. Quoting docs/process/sending-patches.pandoc: "The > `Acked-by:` tag can only be given by a **maintainer** of the modified > code, and it only covers the code the maintainer is responsible for." > The doc provides for tagging here, yes, but such should only be used > for the unusual case of an ack restricted to less than what a > person's maintainership covers. Otherwise we'd end up seeing overly > many tagged acks. (Recall that tagged R-b is also expected to be the > exception, not the common case.) > Ok. I will remove “# x86, common” if I get comments on this patch and there is a need for the the next version, otherwise, I suggest that the committer can remove this while committing the patch. Regards, Rahul
RE: [PATCH] xen/arm, device-tree: Make static-mem use #{address,size}-cells
Hi Julien and Michal,
> -Original Message-
> From: Julien Grall
> >>> / {
> >>> chosen {
> >>> +#address-cells = <0x1>;
> >>> +#size-cells = <0x1>;
> >>> +...
> >>> domU1 {
> >>> compatible = "xen,domain";
> >>> -#address-cells = <0x2>;
> >>> -#size-cells = <0x2>;
> >> Why did you remove this set if it relates to the childs of domU1 (e.g.
> kernel,
> >> ramdisk) and not to domU1 itself?
> >
> > Well, I think here the example is just how we setup the static memory, so
> we just
> > want to emphasize the related part. I agree users can add another
> #address-cells
> > and #size-cells for domU1 node for the parts that you mentioned, but that
> is
> > not reflected by the current example (I can't find anything related to
> > kernel,
> > ramdisk, etc. in current example). I might get it wrong but having two
> #address-cells
> > and #size-cells in that case would be quite misleading from my
> understanding.
>
> I agree with that. As this is only a small part of the DT we want to
> focus on what is necessary for the current section.
>
> > So I decided to remove it.
>
> I would mention it in the commit message because the change seems
> unrelated otherwise.
Sure.
>
> The same apply for replacing adding extra "". But TBH, this change
> feels completely unrelated to this patch. So I think it is better to
> have a separate patch.
I would revert this change for "", as sending a patch adding
"" seems to not make too much sense.
>
> [...]
>
> >>> diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
> >>> index ec81a45de9..cd264793d5 100644
> >>> --- a/xen/arch/arm/bootfdt.c
> >>> +++ b/xen/arch/arm/bootfdt.c
> >>> @@ -352,11 +352,6 @@ static int __init process_domain_node(const
> void
> >> *fdt, int node,
> >>> /* No "xen,static-mem" present. */
> >>> return 0;
> >>>
> >>> -address_cells = device_tree_get_u32(fdt, node,
> >>> -"#xen,static-mem-address-cells",
> >>> 0);
> >>> -size_cells = device_tree_get_u32(fdt, node,
> >>> - "#xen,static-mem-size-cells", 0);
> >>> -
> >>> return device_tree_get_meminfo(fdt, node, "xen,static-mem",
> >> address_cells,
> >>> size_cells, _mem,
> >>> true);
> >>> }
> >>> diff --git a/xen/arch/arm/domain_build.c
> b/xen/arch/arm/domain_build.c
> >>> index b76a84e8f5..258d74699d 100644
> >>> --- a/xen/arch/arm/domain_build.c
> >>> +++ b/xen/arch/arm/domain_build.c
> >>> @@ -563,21 +563,9 @@ static int __init parse_static_mem_prop(const
> >> struct dt_device_node *node,
> >>> const struct dt_property *prop;
> >>>
> >>> prop = dt_find_property(node, "xen,static-mem", NULL);
> >>> -if ( !dt_property_read_u32(node, "#xen,static-mem-address-cells",
> >>> - addr_cells) )
> >>> -{
> >>> -printk(XENLOG_ERR
> >>> - "failed to read \"#xen,static-mem-address-cells\".\n");
> >>> -return -EINVAL;
> >>> -}
> >>>
> >>> -if ( !dt_property_read_u32(node, "#xen,static-mem-size-cells",
> >>> - size_cells) )
> >>> -{
> >>> -printk(XENLOG_ERR
> >>> - "failed to read \"#xen,static-mem-size-cells\".\n");
> >>> -return -EINVAL;
> >>> -}
> >>> +*addr_cells = dt_n_addr_cells(node);
> >>> +*size_cells = dt_n_size_cells(node);
> >> There is a type mismatch here as e.g. addr_cells is u32 and
> dt_n_addr_cells
> >> return type is int.
> >> But I don't think this can be harmful and also it's strange for me that
> >> dt_n_addr_cells
> >> is defined to return int given that it either returns 2 or be32_to_cpup,
> which
> >> means it should return u32.
> >
> > Yeah. I agree. I did a git blame here and found this function is introduced
> > 9
> > years ago in "dbd1243 xen/arm: Add helpers to use the device tree". So I
> think
> > probably it would be easier to ask the author for the following action
> directly :))
>
> The code was imported from Linux where it seems to be more common to
> use
> "int" rather than "unsigned".
>
> >
> > @Julien, what do you think? Shall we modify the return type of these two
> > functions?
>
> I think it would be good to be consistent. However, there are other
> users of d_n_addr_cells() (some are expecting 'int'). So if you switch
> to a different type then this use will be consistent but not the others.
>
> I would only suggest to look at it if you have if you have copious time
> and fancy going down the rabbit hole :).
>
> As to which type to chose, we are phasing out use of uXX in new code. So
> this should be 'uint32_t'. I would also be fine to use 'unsigned int'
> for the outside interface.
>
> I don't have a strong opinion either way.
I personally would like to keep the current way, changing the type to me
sounds
Re: [PATCH v4 4/6] xen/x86: use arch_get_ram_range to get information from E820 map
On 02.09.2022 05:31, Wei Chen wrote:
> The sanity check of nodes_cover_memory is also a requirement of
> other architectures that support NUMA. But now, the code of
> nodes_cover_memory is tied to the x86 E820. In this case, we
> introduce arch_get_ram_range to decouple architecture specific
> memory map from this function. This means, other architectures
> like Arm can also use it to check its node and memory coverage
> from bootmem info.
>
> Depends arch_get_ram_range, we make nodes_cover_memory become
> architecture independent. We also use neutral words to replace
> SRAT and E820 in the print message of this function. This will
> to make the massage seems more common.
>
> As arch_get_ram_range use unsigned int for index, we also adjust
> the index in nodes_cover_memory from int to unsigned int.
>
> Signed-off-by: Wei Chen
Reviewed-by: Jan Beulich
albeit still with a couple of suggestions:
> --- a/xen/arch/x86/srat.c
> +++ b/xen/arch/x86/srat.c
> @@ -428,37 +428,43 @@ acpi_numa_memory_affinity_init(const struct
> acpi_srat_mem_affinity *ma)
> Make sure the PXMs cover all memory. */
> static int __init nodes_cover_memory(void)
> {
> - int i;
> + unsigned int i;
>
> - for (i = 0; i < e820.nr_map; i++) {
> - int j, found;
> + for (i = 0; ; i++) {
> + int err;
> + unsigned int j;
> + bool found;
> paddr_t start, end;
>
> - if (e820.map[i].type != E820_RAM) {
> - continue;
> - }
> + /* Try to loop memory map from index 0 to end to get RAM
> ranges. */
> + err = arch_get_ram_range(i, , );
>
> - start = e820.map[i].addr;
> - end = e820.map[i].addr + e820.map[i].size;
> + /* Reach the end of arch's memory map */
> + if (err == -ENOENT)
> + break;
Such a comment ahead of an if() is often better put as a question, e.g.
"Reached the end of the memory map?" here or, if you dislike using a
question, "Exit the loop at the end of the memory map".
> + /* Index relate entry is not RAM, skip it. */
> + if (err)
> + continue;
And then perhaps "Skip non-RAM entries" here.
> --- a/xen/include/xen/numa.h
> +++ b/xen/include/xen/numa.h
> @@ -81,6 +81,19 @@ static inline nodeid_t __attribute_pure__
> phys_to_nid(paddr_t addr)
> #define node_end_pfn(nid) (NODE_DATA(nid)->node_start_pfn + \
> NODE_DATA(nid)->node_spanned_pages)
>
> +/*
> + * This function provides the ability for caller to get one RAM entry
> + * from architectural memory map by index.
> + *
> + * This function will return zero if it can return a proper RAM entry.
> + * otherwise it will return -ENOENT for out of scope index, or return
> + * -ENODATA for non-RAM type memory entry.
The way you've implemented things, -ENODATA isn't special anymore, so
better wouldn't be called out as special here. May I suggest to at
least insert "e.g." in front of it? (An alternative would be to check
for -ENODATA in nodes_cover_memory() again, followed by ASSERT(!err).)
> + * Note: the range is exclusive at the end, e.g. [start, end).
Perhaps better [*start, *end) to match ...
> + */
> +extern int arch_get_ram_range(unsigned int idx,
> + paddr_t *start, paddr_t *end);
... this?
Jan
[PATCH] docs/device-tree: Place the static-heap dt-binding in proper place
The static-heap dt-binding should be placed after the last feature,
namely static-evtchn.
Fixes: 4596329291f5 ("docs, xen/arm: Introduce static heap memory")
Signed-off-by: Henry Wang
---
docs/misc/arm/device-tree/booting.txt | 86 +--
1 file changed, 43 insertions(+), 43 deletions(-)
diff --git a/docs/misc/arm/device-tree/booting.txt
b/docs/misc/arm/device-tree/booting.txt
index 5395a1077c..93bf6fe577 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -425,49 +425,6 @@ The static event channel node has the following properties:
link-to-foreign-evtchn is a single phandle to a remote evtchn to which
local-evtchn will be connected.
-Static Heap Memory
-==
-
-The static heap memory refers to parts of RAM reserved in the beginning of
-boot time for heap. The memory is reserved by configuration in the device
-tree using physical address ranges.
-
-The static heap memory declared in the device tree defines the memory areas
-that will be reserved to be used exclusively as heap.
-
-- For Arm32, since there are separated heaps, the static heap will be used
-for both domheap and xenheap. The admin should make sure that the static
-heap region should contain enough memory below 4GB to cater 32-bit DMA.
-
-- For Arm64, since there is a single heap, the defined static heap areas
-shall always go to the heap allocator.
-
-The static heap memory is an optional feature and can be enabled by adding
-below device tree property.
-
-- xen,static-heap
-
-Property under the top-level "chosen" node. It specifies the address
-and size of Xen static heap memory. Number of address and size cells
-for the "xen,static-heap" property is determined by the root node
-"#address-cells" and "#size-cells". Note that at least a 64KB alignment
-is required.
-
-Below is an example on how to specify the static heap in device tree:
-
-/ {
-#address-cells = <0x2>;
-#size-cells = <0x2>;
-...
-chosen {
-xen,static-heap = <0x0 0x3000 0x0 0x4000>;
-...
-};
-};
-
-RAM starting from the host physical address 0x3000 of 1GB size will
-be reserved as static heap.
-
Example
===
@@ -523,3 +480,46 @@ chosen {
};
};
};
+
+Static Heap Memory
+==
+
+The static heap memory refers to parts of RAM reserved in the beginning of
+boot time for heap. The memory is reserved by configuration in the device
+tree using physical address ranges.
+
+The static heap memory declared in the device tree defines the memory areas
+that will be reserved to be used exclusively as heap.
+
+- For Arm32, since there are separated heaps, the static heap will be used
+for both domheap and xenheap. The admin should make sure that the static
+heap region should contain enough memory below 4GB to cater 32-bit DMA.
+
+- For Arm64, since there is a single heap, the defined static heap areas
+shall always go to the heap allocator.
+
+The static heap memory is an optional feature and can be enabled by adding
+below device tree property.
+
+- xen,static-heap
+
+Property under the top-level "chosen" node. It specifies the address
+and size of Xen static heap memory. Number of address and size cells
+for the "xen,static-heap" property is determined by the root node
+"#address-cells" and "#size-cells". Note that at least a 64KB alignment
+is required.
+
+Below is an example on how to specify the static heap in device tree:
+
+/ {
+#address-cells = <0x2>;
+#size-cells = <0x2>;
+...
+chosen {
+xen,static-heap = <0x0 0x3000 0x0 0x4000>;
+...
+};
+};
+
+RAM starting from the host physical address 0x3000 of 1GB size will
+be reserved as static heap.
--
2.17.1
Re: [PATCH v5 2/2] xen/pci: replace call to is_memory_hole to pci_check_bar
On 08.09.2022 13:49, Rahul Singh wrote: > is_memory_hole was implemented for x86 and not for ARM when introduced. > Replace is_memory_hole call to pci_check_bar as function should check > if device BAR is in defined memory range. Also, add an implementation > for ARM which is required for PCI passthrough. > > On x86, pci_check_bar will call is_memory_hole which will check if BAR > is not overlapping with any memory region defined in the memory map. > > On ARM, pci_check_bar will go through the host bridge ranges and check > if the BAR is in the range of defined ranges. > > Signed-off-by: Rahul Singh > Acked-by: Jan Beulich # x86, common FTAOD: I object to this tagging, and I did not provide the ack with such tags. Quoting docs/process/sending-patches.pandoc: "The `Acked-by:` tag can only be given by a **maintainer** of the modified code, and it only covers the code the maintainer is responsible for." The doc provides for tagging here, yes, but such should only be used for the unusual case of an ack restricted to less than what a person's maintainership covers. Otherwise we'd end up seeing overly many tagged acks. (Recall that tagged R-b is also expected to be the exception, not the common case.) Jan
[PATCH v5 2/2] xen/pci: replace call to is_memory_hole to pci_check_bar
is_memory_hole was implemented for x86 and not for ARM when introduced.
Replace is_memory_hole call to pci_check_bar as function should check
if device BAR is in defined memory range. Also, add an implementation
for ARM which is required for PCI passthrough.
On x86, pci_check_bar will call is_memory_hole which will check if BAR
is not overlapping with any memory region defined in the memory map.
On ARM, pci_check_bar will go through the host bridge ranges and check
if the BAR is in the range of defined ranges.
Signed-off-by: Rahul Singh
Acked-by: Jan Beulich # x86, common
---
Changes in v5:
- drop use of PFN_UP and PF_DOWN in case addresses are not aligned.
- As we drop the PFN_UP and PFN_DOWN we need to use the mfn_to_maddr()
to get the BAR address without page shift.
- Add TODO comment for address alignment check for ranges.
- Added Jan Acked-by for x86 and common code.
Changes in v4:
- check "s <= e" before callback
- Add TODO comment for revisiting the function pci_check_bar() when
ACPI PCI passthrough support is added.
- Not Added the Jan Acked-by as patch is modified.
Changes in v3:
- fix minor comments
---
xen/arch/arm/include/asm/pci.h | 2 ++
xen/arch/arm/pci/pci-host-common.c | 54 ++
xen/arch/x86/include/asm/pci.h | 10 ++
xen/drivers/passthrough/pci.c | 8 ++---
4 files changed, 70 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/include/asm/pci.h b/xen/arch/arm/include/asm/pci.h
index 80a2431804..8cb46f6b71 100644
--- a/xen/arch/arm/include/asm/pci.h
+++ b/xen/arch/arm/include/asm/pci.h
@@ -126,6 +126,8 @@ int pci_host_iterate_bridges_and_count(struct domain *d,
int pci_host_bridge_mappings(struct domain *d);
+bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end);
+
#else /*!CONFIG_HAS_PCI*/
struct arch_pci_dev { };
diff --git a/xen/arch/arm/pci/pci-host-common.c
b/xen/arch/arm/pci/pci-host-common.c
index 89ef30028e..d51cfdf352 100644
--- a/xen/arch/arm/pci/pci-host-common.c
+++ b/xen/arch/arm/pci/pci-host-common.c
@@ -24,6 +24,16 @@
#include
+/*
+ * struct to hold pci device bar.
+ */
+struct pdev_bar_check
+{
+unsigned long start;
+unsigned long end;
+bool is_valid;
+};
+
/*
* List for all the pci host bridges.
*/
@@ -363,6 +373,50 @@ int __init pci_host_bridge_mappings(struct domain *d)
return 0;
}
+/*
+ * TODO: BAR addresses and Root Complex window addresses are not guaranteed
+ * to be page aligned. We should check for alignment but this is not the
+ * right place for alignment check.
+ */
+static int is_bar_valid(const struct dt_device_node *dev,
+uint64_t addr, uint64_t len, void *data)
+{
+struct pdev_bar_check *bar_data = data;
+unsigned long s = bar_data->start;
+unsigned long e = bar_data->end;
+
+if ( (s >= addr) && (e <= (addr + len - 1)) )
+bar_data->is_valid = true;
+
+return 0;
+}
+
+/* TODO: Revisit this function when ACPI PCI passthrough support is added. */
+bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end)
+{
+int ret;
+const struct dt_device_node *dt_node;
+unsigned long s = mfn_to_maddr(start);
+unsigned long e = mfn_to_maddr(end);
+struct pdev_bar_check bar_data = {
+.start = s,
+.end = e,
+.is_valid = false
+};
+
+if ( s >= e )
+return false;
+
+dt_node = pci_find_host_bridge_node(pdev);
+if ( !dt_node )
+return false;
+
+ret = dt_for_each_range(dt_node, _bar_valid, _data);
+if ( ret < 0 )
+return false;
+
+return bar_data.is_valid;
+}
/*
* Local variables:
* mode: C
diff --git a/xen/arch/x86/include/asm/pci.h b/xen/arch/x86/include/asm/pci.h
index c8e1a9ecdb..f4a58c8acf 100644
--- a/xen/arch/x86/include/asm/pci.h
+++ b/xen/arch/x86/include/asm/pci.h
@@ -57,4 +57,14 @@ static always_inline bool is_pci_passthrough_enabled(void)
void arch_pci_init_pdev(struct pci_dev *pdev);
+static inline bool pci_check_bar(const struct pci_dev *pdev,
+ mfn_t start, mfn_t end)
+{
+/*
+ * Check if BAR is not overlapping with any memory region defined
+ * in the memory map.
+ */
+return is_memory_hole(start, end);
+}
+
#endif /* __X86_PCI_H__ */
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index cdaf5c247f..149f68bb6e 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -304,8 +304,8 @@ static void check_pdev(const struct pci_dev *pdev)
if ( rc < 0 )
/* Unable to size, better leave memory decoding disabled. */
return;
-if ( size && !is_memory_hole(maddr_to_mfn(addr),
- maddr_to_mfn(addr + size - 1)) )
+if ( size && !pci_check_bar(pdev, maddr_to_mfn(addr),
+maddr_to_mfn(addr + size - 1)) )
{
/*
* Return without
Re: [PATCH] xen/arm, device-tree: Make static-mem use #{address,size}-cells
Hi,
On 08/09/2022 11:54, Henry Wang wrote:
-Original Message-
From: Michal Orzel
@@ -362,14 +362,13 @@ device-tree:
/ {
chosen {
+#address-cells = <0x1>;
+#size-cells = <0x1>;
+...
domU1 {
compatible = "xen,domain";
-#address-cells = <0x2>;
-#size-cells = <0x2>;
Why did you remove this set if it relates to the childs of domU1 (e.g. kernel,
ramdisk) and not to domU1 itself?
Well, I think here the example is just how we setup the static memory, so we
just
want to emphasize the related part. I agree users can add another #address-cells
and #size-cells for domU1 node for the parts that you mentioned, but that is
not reflected by the current example (I can't find anything related to kernel,
ramdisk, etc. in current example). I might get it wrong but having two
#address-cells
and #size-cells in that case would be quite misleading from my understanding.
I agree with that. As this is only a small part of the DT we want to
focus on what is necessary for the current section.
So I decided to remove it.
I would mention it in the commit message because the change seems
unrelated otherwise.
The same apply for replacing adding extra "". But TBH, this change
feels completely unrelated to this patch. So I think it is better to
have a separate patch.
[...]
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index ec81a45de9..cd264793d5 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -352,11 +352,6 @@ static int __init process_domain_node(const void
*fdt, int node,
/* No "xen,static-mem" present. */
return 0;
-address_cells = device_tree_get_u32(fdt, node,
-"#xen,static-mem-address-cells", 0);
-size_cells = device_tree_get_u32(fdt, node,
- "#xen,static-mem-size-cells", 0);
-
return device_tree_get_meminfo(fdt, node, "xen,static-mem",
address_cells,
size_cells, _mem, true);
}
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b76a84e8f5..258d74699d 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -563,21 +563,9 @@ static int __init parse_static_mem_prop(const
struct dt_device_node *node,
const struct dt_property *prop;
prop = dt_find_property(node, "xen,static-mem", NULL);
-if ( !dt_property_read_u32(node, "#xen,static-mem-address-cells",
- addr_cells) )
-{
-printk(XENLOG_ERR
- "failed to read \"#xen,static-mem-address-cells\".\n");
-return -EINVAL;
-}
-if ( !dt_property_read_u32(node, "#xen,static-mem-size-cells",
- size_cells) )
-{
-printk(XENLOG_ERR
- "failed to read \"#xen,static-mem-size-cells\".\n");
-return -EINVAL;
-}
+*addr_cells = dt_n_addr_cells(node);
+*size_cells = dt_n_size_cells(node);
There is a type mismatch here as e.g. addr_cells is u32 and dt_n_addr_cells
return type is int.
But I don't think this can be harmful and also it's strange for me that
dt_n_addr_cells
is defined to return int given that it either returns 2 or be32_to_cpup, which
means it should return u32.
Yeah. I agree. I did a git blame here and found this function is introduced 9
years ago in "dbd1243 xen/arm: Add helpers to use the device tree". So I think
probably it would be easier to ask the author for the following action directly
:))
The code was imported from Linux where it seems to be more common to use
"int" rather than "unsigned".
@Julien, what do you think? Shall we modify the return type of these two
functions?
I think it would be good to be consistent. However, there are other
users of d_n_addr_cells() (some are expecting 'int'). So if you switch
to a different type then this use will be consistent but not the others.
I would only suggest to look at it if you have if you have copious time
and fancy going down the rabbit hole :).
As to which type to chose, we are phasing out use of uXX in new code. So
this should be 'uint32_t'. I would also be fine to use 'unsigned int'
for the outside interface.
I don't have a strong opinion either way.
Cheers,
--
Julien Grall
[PATCH v5 1/2] xen/arm: pci: modify pci_find_host_bridge_node argument to const pdev
Modify pci_find_host_bridge_node argument to const pdev to avoid
converting the dev to pdev in pci_find_host_bridge_node and also
constify the return.
Signed-off-by: Rahul Singh
Acked-by: Stefano Stabellini
Reviewed-by: Oleksandr Tyshchenko
---
Changes in v5:
- no changes
Changes in v4:
- no changes
Changes in v3:
- no changes
---
xen/arch/arm/include/asm/pci.h | 3 ++-
xen/arch/arm/pci/pci-host-common.c | 4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/include/asm/pci.h b/xen/arch/arm/include/asm/pci.h
index 7c7449d64f..80a2431804 100644
--- a/xen/arch/arm/include/asm/pci.h
+++ b/xen/arch/arm/include/asm/pci.h
@@ -106,7 +106,8 @@ bool pci_ecam_need_p2m_hwdom_mapping(struct domain *d,
struct pci_host_bridge *bridge,
uint64_t addr);
struct pci_host_bridge *pci_find_host_bridge(uint16_t segment, uint8_t bus);
-struct dt_device_node *pci_find_host_bridge_node(struct device *dev);
+const struct dt_device_node *
+pci_find_host_bridge_node(const struct pci_dev *pdev);
int pci_get_host_bridge_segment(const struct dt_device_node *node,
uint16_t *segment);
diff --git a/xen/arch/arm/pci/pci-host-common.c
b/xen/arch/arm/pci/pci-host-common.c
index fd8c0f837a..89ef30028e 100644
--- a/xen/arch/arm/pci/pci-host-common.c
+++ b/xen/arch/arm/pci/pci-host-common.c
@@ -243,10 +243,10 @@ err_exit:
/*
* Get host bridge node given a device attached to it.
*/
-struct dt_device_node *pci_find_host_bridge_node(struct device *dev)
+const struct dt_device_node *
+pci_find_host_bridge_node(const struct pci_dev *pdev)
{
struct pci_host_bridge *bridge;
-struct pci_dev *pdev = dev_to_pci(dev);
bridge = pci_find_host_bridge(pdev->seg, pdev->bus);
if ( unlikely(!bridge) )
--
2.25.1
Re: [PATCH for-stable-5.10.y] xen-blkfront: Cache feature_persistent value before advertisement
On Tue, Sep 06, 2022 at 04:24:14PM +, SeongJae Park wrote:
> commit fe8f65b018effbf473f53af3538d0c1878b8b329 upstream.
>
> Xen blkfront advertises its support of the persistent grants feature
> when it first setting up and when resuming in 'talk_to_blkback()'.
> Then, blkback reads the advertised value when it connects with blkfront
> and decides if it will use the persistent grants feature or not, and
> advertises its decision to blkfront. Blkfront reads the blkback's
> decision and it also makes the decision for the use of the feature.
>
> Commit 402c43ea6b34 ("xen-blkfront: Apply 'feature_persistent' parameter
> when connect"), however, made the blkfront's read of the parameter for
> disabling the advertisement, namely 'feature_persistent', to be done
> when it negotiate, not when advertise. Therefore blkfront advertises
> without reading the parameter. As the field for caching the parameter
> value is zero-initialized, it always advertises as the feature is
> disabled, so that the persistent grants feature becomes always disabled.
>
> This commit fixes the issue by making the blkfront does parmeter caching
> just before the advertisement.
>
> Fixes: 402c43ea6b34 ("xen-blkfront: Apply 'feature_persistent' parameter when
> connect")
> Cc: # 5.10.x
> Reported-by: Marek Marczykowski-Górecki
> Signed-off-by: SeongJae Park
> Tested-by: Marek Marczykowski-Górecki
> Reviewed-by: Juergen Gross
> Link: https://lore.kernel.org/r/20220831165824.94815-4...@kernel.org
> Signed-off-by: Juergen Gross
> ---
>
> This patch is a manual backport of the upstream commit on the 5.10.y
> kernel. Please note that this patch can be applied on the latest 5.10.y
> only after the preceding patch[1] is applied.
>
> [1]
> https://lore.kernel.org/stable/20220906132819.016040...@linuxfoundation.org/
Now queued up, thanks.
greg k-h
[PATCH v5 0/2] xen/pci: implement is_memory_hole for ARM
This patch series is to implement something like is_memory_hole function for ARM. Rahul Singh (2): xen/arm: pci: modify pci_find_host_bridge_node argument to const pdev xen/pci: replace call to is_memory_hole to pci_check_bar xen/arch/arm/include/asm/pci.h | 5 ++- xen/arch/arm/pci/pci-host-common.c | 58 -- xen/arch/x86/include/asm/pci.h | 10 ++ xen/drivers/passthrough/pci.c | 8 ++--- 4 files changed, 74 insertions(+), 7 deletions(-) -- 2.25.1
[linux-linus test] 173055: regressions - FAIL
flight 173055 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/173055/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 172133 build-i386-libvirt6 libvirt-buildfail REGR. vs. 172133 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172133 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 172133 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-arndale 12 debian-install fail in 173046 pass in 173034 test-armhf-armhf-xl 12 debian-install fail in 173046 pass in 173055 test-armhf-armhf-xl-arndale 8 xen-boot fail pass in 173046 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 15 migrate-support-check fail in 173034 never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail in 173034 never pass test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 172133 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 172133 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 172133 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 172133 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 172133 test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass version targeted for testing: linux0066f1b0e27556381402db3ff31f85d2a2265858 baseline version: linuxb44f2fd87919b5ae6e1756d4c7ba2cbba22238e1 Last test of basis 172133 2022-08-04 05:14:48 Z 35 days Failing since172152 2022-08-05 04:01:26 Z 34 days 78 attempts Testing same since 173034 2022-09-07 03:00:08 Z1 days3 attempts 1702 people touched revisions under test,
Re: [PATCH v4 2/6] xen/x86: move generically usable NUMA code from x86 to common
On 08.09.2022 12:32, Wei Chen wrote:
> On 2022/9/8 17:09, Jan Beulich wrote:
>> On 02.09.2022 05:31, Wei Chen wrote:
>>> --- /dev/null
>>> +++ b/xen/common/numa.c
>>> @@ -0,0 +1,442 @@
>>> +/*
>>> + * Generic VM initialization for NUMA setups.
>>> + * Copyright 2002,2003 Andi Kleen, SuSE Labs.
>>> + * Adapted for Xen: Ryan Harper
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +struct node_data __ro_after_init node_data[MAX_NUMNODES];
>>> +
>>> +/* Mapping from pdx to node id */
>>> +unsigned int __ro_after_init memnode_shift;
>>> +unsigned long __ro_after_init memnodemapsize;
>>> +uint8_t *__ro_after_init memnodemap;
>>> +static uint8_t __ro_after_init _memnodemap[64];
>>
>> These last two want to use nodeid_t instead of uint8_t. Originally
>> the latter used typeof(*memnodemap) for (I think - iirc it was me who
>> made it that way) this reason: That way correcting memnodemap's type
>> would have propagated without the need for further adjustments.
>>
>
> Thanks for this info, should I need to restore it to use
> "typeof(*memnodemap)" in next version ?
That would be more in line with the original code, but it's not
strictly necessary once nodeid_t if properly used for these variables.
I'd leave it up to you as long as you switch to nodeid_t.
>>> +nodeid_t __read_mostly cpu_to_node[NR_CPUS] = {
>>> +[0 ... NR_CPUS-1] = NUMA_NO_NODE
>>> +};
>>> +
>>> +cpumask_t __read_mostly node_to_cpumask[MAX_NUMNODES];
>>> +
>>> +nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
>>> +
>>> +bool __read_mostly numa_off;
>>
>> The v3 review discussing this possibly becoming __ro_after_init didn't
>> really finish (you didn't reply to my latest request there), but you
>> also didn't change the attribute. Please clarify.
>>
>
> I think I had answered your question by:
> >> I think yes, it will be used in numa_disabled and numa_disabled will
> >> be called in cpu_add."
>
> And you replied me with:
> > In the original code I cannot spot such a path - can you please point
> > out how exactly you see numa_disabled() reachable from cpu_add()? I'm
> > clearly overlooking something ..."
>
> But there is a time difference here, your reply was sent after I sent
> v3, maybe you didn't notice it
Which suggests you might better have waited with sending v3 until the
discussion had settled.
> About the new question:
> cpu_add will call srat_disabled, srat_disabled will access numa_off.
> srat_disabled is a function without __init.
But the request wasn't to make the variable __initdata. That would be
wrong of course. Since srat_disabled() only reads numa_off,
__ro_after_init does look usable to me.
Jan
Re: [PATCH v6 0/4] Introduce static heap
Hi Henry, On 08/09/2022 12:09, Henry Wang wrote: The static heap, or statically configured heap, refers to parts of RAM reserved in the beginning for heap. Like the static memory allocation, such static heap regions are reserved by configuration in the device tree using physical address ranges. This feature is useful to run Xen on Arm MPU systems, where only a finite number of memory protection regions are available. The limited number of protection regions places requirement on planning the use of MPU protection regions and one or more MPU protection regions needs to be reserved only for heap. The first patch enhances the error handling in processing the dts chosen node. The second patch introduces the static heap and the device tree parsing code. The third patch renames xenheap_* to directmap_* for better readablity. The fourth patch adds the implementation of the static heap pages handling in boot and heap allocator for Arm. Changes from v5 to v6: - Refine doc. - Drop duplicated code. - Add Julien's Reviewed-by. Henry Wang (4): xen/arm: bootfdt: Make process_chosen_node() return int docs, xen/arm: Introduce static heap memory xen/arm: mm: Rename xenheap_* variable to directmap_* xen/arm: Handle static heap pages in boot and heap allocator I have now committed the series. This required a small tweak in booting.txt because I merged it after Rahul event channel's series which also modifies booting.txt. Cheers, -- Julien Grall
Re: [PATCH v5 7/7] xen/arm: introduce xen-evtchn dom0less property
Hi, On 08/09/2022 01:04, Stefano Stabellini wrote: On Wed, 7 Sep 2022, Rahul Singh wrote: Introduce a new sub-node under /chosen node to establish static event channel communication between domains on dom0less systems. An event channel will be created beforehand to allow the domains to send notifications to each other. Signed-off-by: Rahul Singh For the DT binding: Reviewed-by: Stefano Stabellini This is now committed but I didn't notice the "For the DT binding" above. So I mistakenly interpreted this as you reviewed everything. Let me know if that's a problem with you. For the future may I ask to use suffix with "# DT binding" as this is easier to spot when using automatic tools (e.g. b4)? Cheers, -- Julien Grall
Re: [PATCH v5] tools/xenstore: add migration stream extensions for new features
On 08/09/2022 11:12, Julien Grall wrote: Hi Juergen, On 08/09/2022 09:15, Juergen Gross wrote: Extend the definition of the Xenstore migration stream to cover new features: - per domain features - extended watches (watch depth) - per domain quota Some of those additions (per domain features and extended watches) require bumping the migration stream version to "2", as usage of those features will require to transport mandatory new information in the migration stream. One note regarding the GLOBAL_QUOTA_DATA record: the split of quota between global and per-domain ones is meant to support the possibility to pass on unknown quota settings for newly created domains to other Xenstore instances: Imagine Xenstore A knows about global quota g and domain quota d, while Xenstore B doesn't know both. Initially I'm running Xenstore A on a host, then I'm live-updating to B. B gets the information that g is global, and d is per-domain, but has no other idea what to do with the values of g and d. OTOH it knows that each new domain should get d with the related value, so it can set d for each newly created domain. When B is either downgraded to A again, or a domain is migrated to another host running A, B can add the quota information of d for all domains. Signed-off-by: Juergen Gross Reviewed-by: Julien Grall I have committed it. Cheers, -- Julien Grall
[PATCH v6 3/4] xen/arm: mm: Rename xenheap_* variable to directmap_*
With the static heap setup, keep using xenheap_* in the function
setup_xenheap_mappings() will make the code confusing to read,
because we always need to map the full RAM on Arm64. Therefore,
renaming all "xenheap_*" variables to "directmap_*" to make clear
the area is used to access the RAM easily.
On Arm32, only the xenheap is direct mapped today. So the renaming
to "directmap_*" would be still valid for Arm32.
As the xenheap_* is renamed to directmap_*, rename the function
setup_xenheap_mappings() to setup_directmap_mappings() to reflect
the variable renaming, also change the code comment and printed
error message in the function accordingly.
No functional change is intended.
Signed-off-by: Henry Wang
Acked-by: Julien Grall
---
Changes from v5 to v6:
- No changes.
Changes from v4 to v5:
- Mention the function and code comment rename in commit mesg.
- Add Julien's Acked-by.
Changes from v3 to v4:
- Also rename the setup_xenheap_mappings() function name and
printed messages inside the function.
- Update more comments.
Changes from v2 to v3:
- Adjust the order of this patch, make it #3.
Changes from v1 to v2:
- New commit.
---
xen/arch/arm/bootfdt.c| 2 +-
xen/arch/arm/include/asm/config.h | 2 +-
xen/arch/arm/include/asm/mm.h | 31 ++-
xen/arch/arm/mm.c | 50 +--
xen/arch/arm/setup.c | 36 +++---
5 files changed, 64 insertions(+), 57 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 0ca7b6..c39aacbd60 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -494,7 +494,7 @@ size_t __init boot_fdt_info(const void *fdt, paddr_t paddr)
device_tree_for_each_node((void *)fdt, 0, early_scan_node, NULL);
/*
- * On Arm64 setup_xenheap_mappings() expects to be called with the lowest
+ * On Arm64 setup_directmap_mappings() expects to be called with the lowest
* bank in memory first. There is no requirement that the DT will provide
* the banks sorted in ascending order. So sort them through.
*/
diff --git a/xen/arch/arm/include/asm/config.h
b/xen/arch/arm/include/asm/config.h
index 2fafb9f228..0fefed1b8a 100644
--- a/xen/arch/arm/include/asm/config.h
+++ b/xen/arch/arm/include/asm/config.h
@@ -160,7 +160,7 @@
#define DIRECTMAP_SIZE (SLOT0_ENTRY_SIZE * (265-256))
#define DIRECTMAP_VIRT_END (DIRECTMAP_VIRT_START + DIRECTMAP_SIZE - 1)
-#define XENHEAP_VIRT_START xenheap_virt_start
+#define XENHEAP_VIRT_START directmap_virt_start
#define HYPERVISOR_VIRT_ENDDIRECTMAP_VIRT_END
diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
index 749fbefa0c..7d21120f98 100644
--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -154,19 +154,19 @@ struct page_info
#define _PGC_need_scrub _PGC_allocated
#define PGC_need_scrubPGC_allocated
-extern mfn_t xenheap_mfn_start, xenheap_mfn_end;
-extern vaddr_t xenheap_virt_end;
+extern mfn_t directmap_mfn_start, directmap_mfn_end;
+extern vaddr_t directmap_virt_end;
#ifdef CONFIG_ARM_64
-extern vaddr_t xenheap_virt_start;
-extern unsigned long xenheap_base_pdx;
+extern vaddr_t directmap_virt_start;
+extern unsigned long directmap_base_pdx;
#endif
#ifdef CONFIG_ARM_32
#define is_xen_heap_page(page) is_xen_heap_mfn(page_to_mfn(page))
#define is_xen_heap_mfn(mfn) ({ \
unsigned long mfn_ = mfn_x(mfn);\
-(mfn_ >= mfn_x(xenheap_mfn_start) &&\
- mfn_ < mfn_x(xenheap_mfn_end));\
+(mfn_ >= mfn_x(directmap_mfn_start) && \
+ mfn_ < mfn_x(directmap_mfn_end)); \
})
#else
#define is_xen_heap_page(page) ((page)->count_info & PGC_xen_heap)
@@ -203,9 +203,12 @@ extern void remove_early_mappings(void);
extern int init_secondary_pagetables(int cpu);
/* Switch secondary CPUS to its own pagetables and finalise MMU setup */
extern void mmu_init_secondary_cpu(void);
-/* Set up the xenheap: up to 1GB of contiguous, always-mapped memory.
- * Base must be 32MB aligned and size a multiple of 32MB. */
-extern void setup_xenheap_mappings(unsigned long base_mfn, unsigned long
nr_mfns);
+/*
+ * For Arm32, set up the direct-mapped xenheap: up to 1GB of contiguous,
+ * always-mapped memory. Base must be 32MB aligned and size a multiple of 32MB.
+ * For Arm64, map the region in the directmap area.
+ */
+extern void setup_directmap_mappings(unsigned long base_mfn, unsigned long
nr_mfns);
/* Map a frame table to cover physical addresses ps through pe */
extern void setup_frametable_mappings(paddr_t ps, paddr_t pe);
/* map a physical range in virtual memory */
@@ -267,16 +270,16 @@ static inline paddr_t __virt_to_maddr(vaddr_t va)
static inline void *maddr_to_virt(paddr_t ma)
{
ASSERT(is_xen_heap_mfn(maddr_to_mfn(ma)));
-ma -=
[PATCH v6 4/4] xen/arm: Handle static heap pages in boot and heap allocator
This commit firstly adds a bool field `static_heap` to bootinfo.
This newly introduced field is set at the device tree parsing time
if the static heap ranges are defined in the device tree chosen
node.
For Arm32, In `setup_mm`, if the static heap is enabled, we use the
static heap region for both domheap and xenheap allocation. Note
that the xenheap on Arm32 should be always contiguous, so also add
a helper fit_xenheap_in_static_heap() for Arm32 to find the required
xenheap in the static heap regions.
For Arm64, In `setup_mm`, if the static heap is enabled and used,
we make sure that only these static heap pages are added to the boot
allocator. These static heap pages in the boot allocator are
added to the heap allocator at `end_boot_allocator()`.
If the static heap is disabled, we stick to current page allocation
strategy at boot time.
Also, take the chance to correct a "double not" print in Arm32
`setup_mm()` and replace the open-coding address ~0 by INVALID_PADDR.
Signed-off-by: Henry Wang
Reviewed-by: Julien Grall
---
Changes from v5 to v6:
- No changes.
Changes from v4 to v5:
- No changes.
Changes from v3 to v4:
- Add Julien's Reviewed-by.
Changes from v2 to v3:
- Adjustment of the terminology change to "static heap".
- Change of wording in comments.
- int i -> unsigned int i.
- Avoid extra indentation by reverting the check of MEMBANK_RSVD_HEAP.
- Use MB(32).
- Drop unnecessary panic and unused variables.
- Avoid the ternary operation in assigning the heap_pages.
- Rework populate_boot_allocator() for static heap.
Changes from v1 to v2:
- Move the global bool `reserved_heap` to bootinfo.
- Replace the open open-coding address ~0 by INVALID_PADDR.
- Do not use reverted logic in heap_pages calculation.
- Remove unused Arm32 reserved_heap_start variable.
- Decouple the arm32 reserved heap too small size check with region
end check.
- Reuse the arm32 original xenheap finding logic with the new helper
to make sure xenheap on arm32 is contiguous.
Changes from RFC to v1:
- Rebase on top of latest `setup_mm()` changes.
- Added Arm32 logic in `setup_mm()`.
---
xen/arch/arm/bootfdt.c | 2 +
xen/arch/arm/include/asm/setup.h | 1 +
xen/arch/arm/setup.c | 118 +++
3 files changed, 107 insertions(+), 14 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index c39aacbd60..9e1ea60094 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -313,6 +313,8 @@ static int __init process_chosen_node(const void *fdt, int
node,
MEMBANK_STATIC_HEAP);
if ( rc )
return rc;
+
+bootinfo.static_heap = true;
}
printk("Checking for initrd in /chosen\n");
diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index 09188acae8..5b86cf0245 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -97,6 +97,7 @@ struct bootinfo {
#ifdef CONFIG_ACPI
struct meminfo acpi;
#endif
+bool static_heap;
};
struct map_range_data
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 9f3838d004..e0f9809d7e 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -556,6 +556,44 @@ static paddr_t __init consider_modules(paddr_t s, paddr_t
e,
}
return e;
}
+
+/*
+ * Find a contiguous region that fits in the static heap region with
+ * required size and alignment, and return the end address of the region
+ * if found otherwise 0.
+ */
+static paddr_t __init fit_xenheap_in_static_heap(uint32_t size, paddr_t align)
+{
+unsigned int i;
+paddr_t end = 0, aligned_start, aligned_end;
+paddr_t bank_start, bank_size, bank_end;
+
+for ( i = 0 ; i < bootinfo.reserved_mem.nr_banks; i++ )
+{
+if ( bootinfo.reserved_mem.bank[i].type != MEMBANK_STATIC_HEAP )
+continue;
+
+bank_start = bootinfo.reserved_mem.bank[i].start;
+bank_size = bootinfo.reserved_mem.bank[i].size;
+bank_end = bank_start + bank_size;
+
+if ( bank_size < size )
+continue;
+
+aligned_end = bank_end & ~(align - 1);
+aligned_start = (aligned_end - size) & ~(align - 1);
+
+if ( aligned_start > bank_start )
+/*
+ * Allocate the xenheap as high as possible to keep low-memory
+ * available (assuming the admin supplied region below 4GB)
+ * for other use (e.g. domain memory allocation).
+ */
+end = max(end, aligned_end);
+}
+
+return end;
+}
#endif
/*
@@ -661,22 +699,51 @@ static void __init init_staticmem_pages(void)
}
/*
- * Populate the boot allocator. All the RAM but the following regions
- * will be added:
+ * Populate the boot allocator.
+ * If a static heap was not provided by the admin, all the RAM but the
+ * following regions will be added:
* - Modules (e.g., Xen, Kernel)
* - Reserved regions
* - Xenheap (arm32
[PATCH v6 2/4] docs, xen/arm: Introduce static heap memory
This commit introduces the static heap memory, which is parts of RAM
reserved in the beginning of the boot time for heap.
Firstly, since a new type of memory bank is needed for marking the
memory bank solely as the heap, this commit defines `enum membank_type`
and use this enum in function device_tree_get_meminfo(). Changes of
code are done accordingly following the introduction of this enum.
Also, this commit introduces the logic to parse the static heap
configuration in device tree. If the memory bank is reserved as heap
through `xen,static-heap` property in device tree `chosen` node, the
memory will be marked as static heap type.
A documentation section is added, describing the definition of static
heap memory and the method of enabling the static heap memory through
device tree at boot time.
Signed-off-by: Henry Wang
Signed-off-by: Penny Zheng
Reviewed-by: Julien Grall
---
Changes from v5 to v6:
- Refine doc.
- Drop duplicated code.
- Add Julien's Reviewed-by.
Changes from v4 to v5:
- Use #address-cells and #size-cells for static heap, do not introduce
new address/size cells. Update the dt-binding accordingly.
- Correct a typo in code comments.
- Drop Stefano's acked-by as it is not valid.
Changes from v3 to v4:
- Change of wording in comments.
- Add the static heap feature in SUPPORT.md as tech preview.
Changes from v2 to v3:
- Define `enum membank_type` properly, drop the typedef.
- Rename the feature terminology to static heap.
- Rename MEMBANK_MEMORY to MEMBANK_DEFAULT and MEMBANK_XEN_DOMAIN to
MEMBANK_STATIC_DOMAIN. Add comments to `enum membank_type`.
- Correct typo, add the clarification of the static heap region
should contain enough memory below 4GB to cater 32-bit DMA for Arm32,
and add the 64KB alignment requirement in doc.
- Add Stefano's Acked-by for device tree interface.
Changes from v1 to v2:
- Rename the device tree property to xen,static-heap to avoid confusion.
- Change of commit msg and doc wording, correct typo in commit msg.
- Do not change the process_chosen_node() return type.
- Add an empty line in make_memory_node() memory type check to improve
readability.
- Use enum membank_type to make the memory type cleaner.
Changes from RFC to v1:
- Rename the terminology to reserved heap.
---
SUPPORT.md| 7 +
docs/misc/arm/device-tree/booting.txt | 44 +++
xen/arch/arm/bootfdt.c| 23 +++---
xen/arch/arm/domain_build.c | 8 +++--
xen/arch/arm/include/asm/setup.h | 22 +-
xen/arch/arm/setup.c | 2 +-
6 files changed, 97 insertions(+), 9 deletions(-)
diff --git a/SUPPORT.md b/SUPPORT.md
index 8e040d1c1e..b02a5d25ca 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -293,6 +293,13 @@ pre-defined by configuration using physical address ranges.
Status, ARM: Tech Preview
+### Static Heap
+
+Allow reserving parts of RAM through the device tree using physical
+address ranges as heap.
+
+Status, ARM: Tech Preview
+
### Memory Sharing
Allow sharing of identical pages between guests
diff --git a/docs/misc/arm/device-tree/booting.txt
b/docs/misc/arm/device-tree/booting.txt
index 98253414b8..d71f59b63c 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -378,3 +378,47 @@ device-tree:
This will reserve a 512MB region starting at the host physical address
0x3000 to be exclusively used by DomU1.
+
+
+Static Heap Memory
+==
+
+The static heap memory refers to parts of RAM reserved in the beginning of
+boot time for heap. The memory is reserved by configuration in the device
+tree using physical address ranges.
+
+The static heap memory declared in the device tree defines the memory areas
+that will be reserved to be used exclusively as heap.
+
+- For Arm32, since there are separated heaps, the static heap will be used
+for both domheap and xenheap. The admin should make sure that the static
+heap region should contain enough memory below 4GB to cater 32-bit DMA.
+
+- For Arm64, since there is a single heap, the defined static heap areas
+shall always go to the heap allocator.
+
+The static heap memory is an optional feature and can be enabled by adding
+below device tree property.
+
+- xen,static-heap
+
+Property under the top-level "chosen" node. It specifies the address
+and size of Xen static heap memory. Number of address and size cells
+for the "xen,static-heap" property is determined by the root node
+"#address-cells" and "#size-cells". Note that at least a 64KB alignment
+is required.
+
+Below is an example on how to specify the static heap in device tree:
+
+/ {
+#address-cells = <0x2>;
+#size-cells = <0x2>;
+...
+chosen {
+xen,static-heap = <0x0 0x3000 0x0 0x4000>;
+...
+};
+};
+
+RAM starting from the host physical address 0x3000 of 1GB size will
+be reserved as static
[PATCH v6 0/4] Introduce static heap
The static heap, or statically configured heap, refers to parts of RAM reserved in the beginning for heap. Like the static memory allocation, such static heap regions are reserved by configuration in the device tree using physical address ranges. This feature is useful to run Xen on Arm MPU systems, where only a finite number of memory protection regions are available. The limited number of protection regions places requirement on planning the use of MPU protection regions and one or more MPU protection regions needs to be reserved only for heap. The first patch enhances the error handling in processing the dts chosen node. The second patch introduces the static heap and the device tree parsing code. The third patch renames xenheap_* to directmap_* for better readablity. The fourth patch adds the implementation of the static heap pages handling in boot and heap allocator for Arm. Changes from v5 to v6: - Refine doc. - Drop duplicated code. - Add Julien's Reviewed-by. Henry Wang (4): xen/arm: bootfdt: Make process_chosen_node() return int docs, xen/arm: Introduce static heap memory xen/arm: mm: Rename xenheap_* variable to directmap_* xen/arm: Handle static heap pages in boot and heap allocator SUPPORT.md| 7 ++ docs/misc/arm/device-tree/booting.txt | 44 xen/arch/arm/bootfdt.c| 47 +--- xen/arch/arm/domain_build.c | 8 +- xen/arch/arm/include/asm/config.h | 2 +- xen/arch/arm/include/asm/mm.h | 31 ++--- xen/arch/arm/include/asm/setup.h | 23 +++- xen/arch/arm/mm.c | 50 + xen/arch/arm/setup.c | 156 -- 9 files changed, 279 insertions(+), 89 deletions(-) -- 2.17.1
[PATCH v6 1/4] xen/arm: bootfdt: Make process_chosen_node() return int
At the boot time, it is saner to stop booting early if an error occurs
when parsing the device tree chosen node, rather than seeing random
behavior afterwards. Therefore, this commit changes the return type of
the process_chosen_node() from void to int, and return correct errno
based on the error type.
Signed-off-by: Henry Wang
Reviewed-by: Michal Orzel
Acked-by: Julien Grall
---
Changes from v5 to v6:
- No changes.
Changes from v4 to v5:
- No changes.
Changes from v3 to v4:
- Add Reviewed-by from Michal and Acked-by from Julien.
Changes from v2 to v3:
- Adjust the order of this patch, make it the #1.
Changes from v1 to v2:
- New commit.
---
xen/arch/arm/bootfdt.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index ec81a45de9..1a79b969af 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -293,9 +293,9 @@ static void __init process_multiboot_node(const void *fdt,
int node,
kind, start, domU);
}
-static void __init process_chosen_node(const void *fdt, int node,
- const char *name,
- u32 address_cells, u32 size_cells)
+static int __init process_chosen_node(const void *fdt, int node,
+ const char *name,
+ u32 address_cells, u32 size_cells)
{
const struct fdt_property *prop;
paddr_t start, end;
@@ -306,11 +306,11 @@ static void __init process_chosen_node(const void *fdt,
int node,
prop = fdt_get_property(fdt, node, "linux,initrd-start", );
if ( !prop )
/* No initrd present. */
-return;
+return 0;
if ( len != sizeof(u32) && len != sizeof(u64) )
{
printk("linux,initrd-start property has invalid length %d\n", len);
-return;
+return -EINVAL;
}
start = dt_read_number((void *)>data, dt_size_to_cells(len));
@@ -318,12 +318,12 @@ static void __init process_chosen_node(const void *fdt,
int node,
if ( !prop )
{
printk("linux,initrd-end not present but -start was\n");
-return;
+return -EINVAL;
}
if ( len != sizeof(u32) && len != sizeof(u64) )
{
printk("linux,initrd-end property has invalid length %d\n", len);
-return;
+return -EINVAL;
}
end = dt_read_number((void *)>data, dt_size_to_cells(len));
@@ -331,12 +331,14 @@ static void __init process_chosen_node(const void *fdt,
int node,
{
printk("linux,initrd limits invalid: %"PRIpaddr" >= %"PRIpaddr"\n",
start, end);
-return;
+return -EINVAL;
}
printk("Initrd %"PRIpaddr"-%"PRIpaddr"\n", start, end);
add_boot_module(BOOTMOD_RAMDISK, start, end-start, false);
+
+return 0;
}
static int __init process_domain_node(const void *fdt, int node,
@@ -383,7 +385,7 @@ static int __init early_scan_node(const void *fdt,
device_tree_node_compatible(fdt, node, "multiboot,module" )))
process_multiboot_node(fdt, node, name, address_cells, size_cells);
else if ( depth == 1 && device_tree_node_matches(fdt, node, "chosen") )
-process_chosen_node(fdt, node, name, address_cells, size_cells);
+rc = process_chosen_node(fdt, node, name, address_cells, size_cells);
else if ( depth == 2 && device_tree_node_compatible(fdt, node,
"xen,domain") )
rc = process_domain_node(fdt, node, name, address_cells, size_cells);
--
2.17.1
RE: [PATCH] xen/arm, device-tree: Make static-mem use #{address,size}-cells
Hi Michal,
Thank you very much for your review, as always :))
> -Original Message-
> From: Michal Orzel
> > @@ -362,14 +362,13 @@ device-tree:
> >
> > / {
> > chosen {
> > +#address-cells = <0x1>;
> > +#size-cells = <0x1>;
> > +...
> > domU1 {
> > compatible = "xen,domain";
> > -#address-cells = <0x2>;
> > -#size-cells = <0x2>;
> Why did you remove this set if it relates to the childs of domU1 (e.g. kernel,
> ramdisk) and not to domU1 itself?
Well, I think here the example is just how we setup the static memory, so we
just
want to emphasize the related part. I agree users can add another #address-cells
and #size-cells for domU1 node for the parts that you mentioned, but that is
not reflected by the current example (I can't find anything related to kernel,
ramdisk, etc. in current example). I might get it wrong but having two
#address-cells
and #size-cells in that case would be quite misleading from my understanding.
So I decided to remove it.
But I am open to other opinions. So shall we let the discussion go on for a bit
longer?
I will revert this change if most people think this removing is unnecessary.
>
> > cpus = <2>;
> > memory = <0x0 0x8>;
> > -#xen,static-mem-address-cells = <0x1>;
> > -#xen,static-mem-size-cells = <0x1>;
> > xen,static-mem = <0x3000 0x2000>;
> > ...
> > };
> > diff --git a/docs/misc/arm/passthrough-noiommu.txt
> b/docs/misc/arm/passthrough-noiommu.txt
> > index 3e2ef21ad7..69b8de1975 100644
> > --- a/docs/misc/arm/passthrough-noiommu.txt
> > +++ b/docs/misc/arm/passthrough-noiommu.txt
> > @@ -33,14 +33,13 @@ on static allocation in the device-tree:
> >
> > / {
> > chosen {
> > + #address-cells = <0x1>;
> > + #size-cells = <0x1>;
> > + ...
> > domU1 {
> > compatible = "xen,domain";
> > - #address-cells = <0x2>;
> > - #size-cells = <0x2>;
> The same here.
Same as above.
>
> > cpus = <2>;
> > memory = <0x0 0x8>;
> > - #xen,static-mem-address-cells = <0x1>;
> > - #xen,static-mem-size-cells = <0x1>;
> > xen,static-mem = <0x3000 0x2000>;
> > direct-map;
> > ...
> > diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
> > index ec81a45de9..cd264793d5 100644
> > --- a/xen/arch/arm/bootfdt.c
> > +++ b/xen/arch/arm/bootfdt.c
> > @@ -352,11 +352,6 @@ static int __init process_domain_node(const void
> *fdt, int node,
> > /* No "xen,static-mem" present. */
> > return 0;
> >
> > -address_cells = device_tree_get_u32(fdt, node,
> > -"#xen,static-mem-address-cells",
> > 0);
> > -size_cells = device_tree_get_u32(fdt, node,
> > - "#xen,static-mem-size-cells", 0);
> > -
> > return device_tree_get_meminfo(fdt, node, "xen,static-mem",
> address_cells,
> > size_cells, _mem,
> > true);
> > }
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index b76a84e8f5..258d74699d 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -563,21 +563,9 @@ static int __init parse_static_mem_prop(const
> struct dt_device_node *node,
> > const struct dt_property *prop;
> >
> > prop = dt_find_property(node, "xen,static-mem", NULL);
> > -if ( !dt_property_read_u32(node, "#xen,static-mem-address-cells",
> > - addr_cells) )
> > -{
> > -printk(XENLOG_ERR
> > - "failed to read \"#xen,static-mem-address-cells\".\n");
> > -return -EINVAL;
> > -}
> >
> > -if ( !dt_property_read_u32(node, "#xen,static-mem-size-cells",
> > - size_cells) )
> > -{
> > -printk(XENLOG_ERR
> > - "failed to read \"#xen,static-mem-size-cells\".\n");
> > -return -EINVAL;
> > -}
> > +*addr_cells = dt_n_addr_cells(node);
> > +*size_cells = dt_n_size_cells(node);
> There is a type mismatch here as e.g. addr_cells is u32 and dt_n_addr_cells
> return type is int.
> But I don't think this can be harmful and also it's strange for me that
> dt_n_addr_cells
> is defined to return int given that it either returns 2 or be32_to_cpup, which
> means it should return u32.
Yeah. I agree. I did a git blame here and found this function is introduced 9
years ago in "dbd1243 xen/arm: Add helpers to use the device tree". So I think
probably it would be easier to ask the author for the following action directly
:))
@Julien, what do you think?
Re: [PATCH v7 7/9] xen/arm: create shared memory nodes in guest device tree
Hi,
Replying to Penny and Stefano answer in the same e-mail.
On 08/09/2022 04:21, Penny Zheng wrote:
-Original Message-
From: Stefano Stabellini
Sent: Thursday, September 8, 2022 8:16 AM
To: Julien Grall
Cc: Penny Zheng ; xen-devel@lists.xenproject.org;
Wei Chen ; Stefano Stabellini
; Bertrand Marquis ;
Volodymyr Babchuk
Subject: Re: [PATCH v7 7/9] xen/arm: create shared memory nodes in guest
device tree
On Wed, 7 Sep 2022, Julien Grall wrote:
On 06/09/2022 09:59, Penny Zheng wrote:
We expose the shared memory to the domU using the "xen,shared-
memory-v1"
reserved-memory binding. See
Documentation/devicetree/bindings/reserved-memory/xen,shared-
memory.
txt in Linux for the corresponding device tree binding.
To save the cost of re-parsing shared memory device tree
configuration when creating shared memory nodes in guest device
tree, this commit adds new field "shm_mem" to store shm-info per
domain.
For each shared memory region, a range is exposed under the
/reserved-memory node as a child node. Each range sub-node is named
xen-shmem@ and has the following properties:
- compatible:
compatible = "xen,shared-memory-v1"
- reg:
the base guest physical address and size of the shared
memory region
- xen,id:
a string that identifies the shared memory region.
So technically, there is a property "xen,offset" that should be
specified for the borrowers.
TBH, I don't quite understand what this property is used for. So it is
not quite clear why this is skipped.
The Stefano is the author of the binding. So maybe he can explain the
purpose of the property and help to document it in the commit message
why this is ignored.
It looks like it is something we introduced to handle the case where memory
from the owner is shared with multiple borrowers. Each borrower would
have its own offset within the region shared by the owner:
https://marc.info/?l=xen-devel=154110446604365=2
Thanks for the pointer :). Now, I remember what this was meant for.
IMHO, "xen,offset" more fits in the xen dts? We configure it in borrower memory
node,
then later we shall only set up foreign memory map starting at the offset?
Yes and Yes.
'''
domU1-shared-mem@1000 {
compatible = "xen,domain-shared-memory-v1";
role = "borrower";
xen,shm-id = "my-shared-mem-0";
xen,shared-mem = <0x1000 0x5000 0x1000>;
xen,offset = <0x0 0x0100>;
}
'''
For borrower domain, only [0x1100, 0x2000) need to get mapped...
Of course, we could limit the memory map in related Linux driver, but for
safety,
it should be at Xen?
Correct.
The use-case is a bit of a corner case but it looks valid. If I had to do it
now, I
would at least mark "xen,offset" as "optional".
I think we have two options here and I am happy with either one:
1) we add xen,offset = <0x0>;
I will let v8 stay with this configuration, and a TODO for actual
implementation.
Agree. It sounds the best approach for now.
Cheers,
--
Julien Grall
[xen-unstable-smoke test] 173061: tolerable FAIL - PUSHED
flight 173061 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/173061/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a build-amd64-libvirt 6 libvirt-buildfail like 173029 test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen 64e302157a87b246473a31fa104377a6d48eb046 baseline version: xen 172015009a6acc20357a2698800e13058ba1d3db Last test of basis 173029 2022-09-06 19:01:53 Z1 days Testing same since 173061 2022-09-08 08:01:53 Z0 days1 attempts People who touched revisions under test: Jan Beulich Juergen Gross Julien Grall Leo Yan Viresh Kumar jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt fail test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 172015009a..64e302157a 64e302157a87b246473a31fa104377a6d48eb046 -> smoke
Re: [PATCH] xen/arm, device-tree: Make static-mem use #{address,size}-cells
Hi Henry,
On 08/09/2022 11:31, Henry Wang wrote:
>
> In order to keep consistency in the device tree binding, there is
> no need for static memory allocation feature to define a specific
> set of address and size cells for "xen,static-mem" property.
>
> Therefore, this commit reuses the regular #{address,size}-cells
> for parsing the device tree "xen,static-mem" property. Update
> the documentation accordingly.
>
> Signed-off-by: Henry Wang
> ---
> docs/misc/arm/device-tree/booting.txt | 13 ++---
> docs/misc/arm/passthrough-noiommu.txt | 7 +++
> xen/arch/arm/bootfdt.c| 5 -
> xen/arch/arm/domain_build.c | 16 ++--
> 4 files changed, 11 insertions(+), 30 deletions(-)
>
> diff --git a/docs/misc/arm/device-tree/booting.txt
> b/docs/misc/arm/device-tree/booting.txt
> index 98253414b8..12d77e3b26 100644
> --- a/docs/misc/arm/device-tree/booting.txt
> +++ b/docs/misc/arm/device-tree/booting.txt
> @@ -339,15 +339,15 @@ kernel will be able to discover the device.
>
>
> Static Allocation
> -=
> +=
>
> Static Allocation refers to system or sub-system(domains) for which memory
> areas are pre-defined by configuration using physical address ranges.
>
> Memory can be statically allocated to a domain using the property
> "xen,static-
> mem" defined in the domain configuration. The number of cells for the address
> -and the size must be defined using respectively the properties
> -"#xen,static-mem-address-cells" and "#xen,static-mem-size-cells".
> +and the size must be defined respectively by the parent node properties
> +"#address-cells" and "#size-cells".
>
> The property 'memory' is still needed and should match the amount of memory
> given to the guest. Currently, it either comes from static memory or lets Xen
> @@ -362,14 +362,13 @@ device-tree:
>
> / {
> chosen {
> +#address-cells = <0x1>;
> +#size-cells = <0x1>;
> +...
> domU1 {
> compatible = "xen,domain";
> -#address-cells = <0x2>;
> -#size-cells = <0x2>;
Why did you remove this set if it relates to the childs of domU1 (e.g. kernel,
ramdisk) and not to domU1 itself?
> cpus = <2>;
> memory = <0x0 0x8>;
> -#xen,static-mem-address-cells = <0x1>;
> -#xen,static-mem-size-cells = <0x1>;
> xen,static-mem = <0x3000 0x2000>;
> ...
> };
> diff --git a/docs/misc/arm/passthrough-noiommu.txt
> b/docs/misc/arm/passthrough-noiommu.txt
> index 3e2ef21ad7..69b8de1975 100644
> --- a/docs/misc/arm/passthrough-noiommu.txt
> +++ b/docs/misc/arm/passthrough-noiommu.txt
> @@ -33,14 +33,13 @@ on static allocation in the device-tree:
>
> / {
> chosen {
> + #address-cells = <0x1>;
> + #size-cells = <0x1>;
> + ...
> domU1 {
> compatible = "xen,domain";
> - #address-cells = <0x2>;
> - #size-cells = <0x2>;
The same here.
> cpus = <2>;
> memory = <0x0 0x8>;
> - #xen,static-mem-address-cells = <0x1>;
> - #xen,static-mem-size-cells = <0x1>;
> xen,static-mem = <0x3000 0x2000>;
> direct-map;
> ...
> diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
> index ec81a45de9..cd264793d5 100644
> --- a/xen/arch/arm/bootfdt.c
> +++ b/xen/arch/arm/bootfdt.c
> @@ -352,11 +352,6 @@ static int __init process_domain_node(const void *fdt,
> int node,
> /* No "xen,static-mem" present. */
> return 0;
>
> -address_cells = device_tree_get_u32(fdt, node,
> -"#xen,static-mem-address-cells", 0);
> -size_cells = device_tree_get_u32(fdt, node,
> - "#xen,static-mem-size-cells", 0);
> -
> return device_tree_get_meminfo(fdt, node, "xen,static-mem",
> address_cells,
> size_cells, _mem, true);
> }
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index b76a84e8f5..258d74699d 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -563,21 +563,9 @@ static int __init parse_static_mem_prop(const struct
> dt_device_node *node,
> const struct dt_property *prop;
>
> prop = dt_find_property(node, "xen,static-mem", NULL);
> -if ( !dt_property_read_u32(node, "#xen,static-mem-address-cells",
> - addr_cells) )
> -{
> -printk(XENLOG_ERR
> - "failed to read \"#xen,static-mem-address-cells\".\n");
> -return -EINVAL;
> -}
>
> -if ( !dt_property_read_u32(node, "#xen,static-mem-size-cells",
> -
Re: [PATCH] Config.mk: correct PIE-related option(s) in EMBEDDED_EXTRA_CFLAGS
On 08/09/2022 07:10, Jan Beulich wrote: > On 07.09.2022 16:33, Julien Grall wrote: >> On 25/08/2022 08:17, Jan Beulich wrote: >>> I haven't been able to find evidence of "-nopie" ever having been a >>> supported compiler option. The correct spelling is "-no-pie". >>> Furthermore like "-pie" this is an option which is solely passed to the >>> linker. The compiler only recognizes "-fpie" / "-fPIE" / "-fno-pie", and >>> it doesn't infer these options from "-pie" / "-no-pie". >> OOI, how did you find out this issue? > By reviewing Andrew's "x86/hvmloader: Don't build as PIC/PIE". It was actually first discussed here: https://lore.kernel.org/xen-devel/7b129a01-07c7-e856-fb5b-0c7b44a8d...@citrix.com/ The reason why I hadn't got back around to this patch yet is because the commit message is wrong (not helped to some appalling GCC/Binutils documentation). The -f forms are to do with GCC code generation. These are CFLAGS, but they want want specifying (or not) together, and not split across EMBEDDED_EXTRA_CFLAGS and something else like this. The non-f forms are LDFLAGS but do behave as described. Passing -no-pie causes GCC to cancel passing -pie to LD; it does not pass -no-pie. But it does other things too, because different cr0 objects get passed. This matters for hosted binaries, but not for freestanding. ~Andrew
Re: [PATCH v4 2/6] xen/x86: move generically usable NUMA code from x86 to common
Hi Jan,
On 2022/9/8 17:09, Jan Beulich wrote:
On 02.09.2022 05:31, Wei Chen wrote:
--- /dev/null
+++ b/xen/common/numa.c
@@ -0,0 +1,442 @@
+/*
+ * Generic VM initialization for NUMA setups.
+ * Copyright 2002,2003 Andi Kleen, SuSE Labs.
+ * Adapted for Xen: Ryan Harper
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct node_data __ro_after_init node_data[MAX_NUMNODES];
+
+/* Mapping from pdx to node id */
+unsigned int __ro_after_init memnode_shift;
+unsigned long __ro_after_init memnodemapsize;
+uint8_t *__ro_after_init memnodemap;
+static uint8_t __ro_after_init _memnodemap[64];
These last two want to use nodeid_t instead of uint8_t. Originally
the latter used typeof(*memnodemap) for (I think - iirc it was me who
made it that way) this reason: That way correcting memnodemap's type
would have propagated without the need for further adjustments.
Thanks for this info, should I need to restore it to use
"typeof(*memnodemap)" in next version ?
+nodeid_t __read_mostly cpu_to_node[NR_CPUS] = {
+[0 ... NR_CPUS-1] = NUMA_NO_NODE
+};
+
+cpumask_t __read_mostly node_to_cpumask[MAX_NUMNODES];
+
+nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
+
+bool __read_mostly numa_off;
The v3 review discussing this possibly becoming __ro_after_init didn't
really finish (you didn't reply to my latest request there), but you
also didn't change the attribute. Please clarify.
I think I had answered your question by:
>> I think yes, it will be used in numa_disabled and numa_disabled will
>> be called in cpu_add."
And you replied me with:
> In the original code I cannot spot such a path - can you please point
> out how exactly you see numa_disabled() reachable from cpu_add()? I'm
> clearly overlooking something ..."
But there is a time difference here, your reply was sent after I sent
v3, maybe you didn't notice it
About the new question:
cpu_add will call srat_disabled, srat_disabled will access numa_off.
srat_disabled is a function without __init.
+static int __init populate_memnodemap(const struct node *nodes,
+ unsigned int numnodes, unsigned int
shift,
+ nodeid_t *nodeids)
Can't this be pointer-to-const, and then also in the caller?
Yes, it's possible, I will fix it.
+static unsigned int __init extract_lsb_from_nodes(const struct node *nodes,
+ nodeid_t numnodes)
+{
+unsigned int i;
+nodeid_t nodes_used = 0;
This once again is a variable which doesn't really hold a node ID (but
instead is a counter), and hence would better be unsigned int (see
./CODING_STYLE).
Ok.
+unsigned long spdx, epdx;
+unsigned long bitfield = 0, memtop = 0;
+
+for ( i = 0; i < numnodes; i++ )
+{
+spdx = paddr_to_pdx(nodes[i].start);
+epdx = paddr_to_pdx(nodes[i].end - 1) + 1;
+if ( spdx >= epdx )
+continue;
+bitfield |= spdx;
+nodes_used++;
+if ( epdx > memtop )
+memtop = epdx;
+}
+if ( nodes_used <= 1 )
+i = BITS_PER_LONG - 1;
+else
+i = find_first_bit(, sizeof(unsigned long)*8);
Please add the missing blanks around * .
Ok.
+memnodemapsize = (memtop >> i) + 1;
+return i;
Please add the missing blank line before the (main) return statement
of the function.
I'll fix him and other places, if there are any.
+int __init compute_hash_shift(const struct node *nodes,
+ nodeid_t numnodes, nodeid_t *nodeids)
While I agree that nodeid_t can hold all necessary values, I still
don't think a cound should be expressed by nodeid_t. As above - see
./CODING_STYLE.
Ok.
+{
+unsigned int shift;
+
+shift = extract_lsb_from_nodes(nodes, numnodes);
+if ( memnodemapsize <= ARRAY_SIZE(_memnodemap) )
+memnodemap = _memnodemap;
+else if ( allocate_cachealigned_memnodemap() )
+return -1;
+printk(KERN_DEBUG "NUMA: Using %d for the hash shift.\n", shift);
This wants to be %u now. I'd also like to ask to drop the full stop
at this occasion.
Ok, that makes sense.
+if ( populate_memnodemap(nodes, numnodes, shift, nodeids) != 1 )
+{
+printk(KERN_INFO "Your memory is not aligned you need to "
+ "rebuild your hypervisor with a bigger NODEMAPSIZE "
+ "shift=%d\n", shift);
Again %u please.
Ack.
+/* initialize NODE_DATA given nodeid and start/end */
+void __init setup_node_bootmem(nodeid_t nodeid, paddr_t start, paddr_t end)
Please capitalize the first letter of the comment (see ./CODING_STYLE).
Ok.
+void __init numa_init_array(void)
+{
+unsigned int i;
+nodeid_t rr;
+
+/*
+ * There are unfortunately some poorly designed mainboards around
+ * that only connect memory to a single CPU. This breaks the 1:1 cpu->node
+ * mapping. To avoid this fill in the mapping
Re: [PATCH v5 2/4] docs, xen/arm: Introduce static heap memory
Hi Henry, On 08/09/2022 05:25, Henry Wang wrote: This commit introduces the static heap memory, which is parts of RAM reserved in the beginning of the boot time for heap. Firstly, since a new type of memory bank is needed for marking the memory bank solely as the heap, this commit defines `enum membank_type` and use this enum in function device_tree_get_meminfo(). Changes of code are done accordingly following the introduction of this enum. Also, this commit introduces the logic to parse the static heap configuration in device tree. If the memory bank is reserved as heap through `xen,static-heap` property in device tree `chosen` node, the memory will be marked as static heap type. A documentation section is added, describing the definition of static heap memory and the method of enabling the static heap memory through device tree at boot time. Signed-off-by: Henry Wang Signed-off-by: Penny Zheng With Michal's comments addressed: Reviewed-by: Julien Grall Cheers, -- Julien Grall
Re: [PATCH v5] tools/xenstore: add migration stream extensions for new features
Hi Juergen, On 08/09/2022 09:15, Juergen Gross wrote: Extend the definition of the Xenstore migration stream to cover new features: - per domain features - extended watches (watch depth) - per domain quota Some of those additions (per domain features and extended watches) require bumping the migration stream version to "2", as usage of those features will require to transport mandatory new information in the migration stream. One note regarding the GLOBAL_QUOTA_DATA record: the split of quota between global and per-domain ones is meant to support the possibility to pass on unknown quota settings for newly created domains to other Xenstore instances: Imagine Xenstore A knows about global quota g and domain quota d, while Xenstore B doesn't know both. Initially I'm running Xenstore A on a host, then I'm live-updating to B. B gets the information that g is global, and d is per-domain, but has no other idea what to do with the values of g and d. OTOH it knows that each new domain should get d with the related value, so it can set d for each newly created domain. When B is either downgraded to A again, or a domain is migrated to another host running A, B can add the quota information of d for all domains. Signed-off-by: Juergen Gross Reviewed-by: Julien Grall Cheers, -- Julien Grall
[xen-unstable test] 173054: tolerable FAIL
flight 173054 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/173054/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-migrupgrade 11 xen-install/dst_host fail pass in 173044 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a build-amd64-libvirt 6 libvirt-buildfail like 173044 build-i386-libvirt6 libvirt-buildfail like 173044 build-arm64-libvirt 6 libvirt-buildfail like 173044 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 173044 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 173044 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 173044 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 173044 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 173044 build-armhf-libvirt 6 libvirt-buildfail like 173044 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 173044 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 173044 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 173044 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 173044 test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass version targeted for
[PATCH] xen/arm, device-tree: Make static-mem use #{address,size}-cells
In order to keep consistency in the device tree binding, there is
no need for static memory allocation feature to define a specific
set of address and size cells for "xen,static-mem" property.
Therefore, this commit reuses the regular #{address,size}-cells
for parsing the device tree "xen,static-mem" property. Update
the documentation accordingly.
Signed-off-by: Henry Wang
---
docs/misc/arm/device-tree/booting.txt | 13 ++---
docs/misc/arm/passthrough-noiommu.txt | 7 +++
xen/arch/arm/bootfdt.c| 5 -
xen/arch/arm/domain_build.c | 16 ++--
4 files changed, 11 insertions(+), 30 deletions(-)
diff --git a/docs/misc/arm/device-tree/booting.txt
b/docs/misc/arm/device-tree/booting.txt
index 98253414b8..12d77e3b26 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -339,15 +339,15 @@ kernel will be able to discover the device.
Static Allocation
-=
+=
Static Allocation refers to system or sub-system(domains) for which memory
areas are pre-defined by configuration using physical address ranges.
Memory can be statically allocated to a domain using the property "xen,static-
mem" defined in the domain configuration. The number of cells for the address
-and the size must be defined using respectively the properties
-"#xen,static-mem-address-cells" and "#xen,static-mem-size-cells".
+and the size must be defined respectively by the parent node properties
+"#address-cells" and "#size-cells".
The property 'memory' is still needed and should match the amount of memory
given to the guest. Currently, it either comes from static memory or lets Xen
@@ -362,14 +362,13 @@ device-tree:
/ {
chosen {
+#address-cells = <0x1>;
+#size-cells = <0x1>;
+...
domU1 {
compatible = "xen,domain";
-#address-cells = <0x2>;
-#size-cells = <0x2>;
cpus = <2>;
memory = <0x0 0x8>;
-#xen,static-mem-address-cells = <0x1>;
-#xen,static-mem-size-cells = <0x1>;
xen,static-mem = <0x3000 0x2000>;
...
};
diff --git a/docs/misc/arm/passthrough-noiommu.txt
b/docs/misc/arm/passthrough-noiommu.txt
index 3e2ef21ad7..69b8de1975 100644
--- a/docs/misc/arm/passthrough-noiommu.txt
+++ b/docs/misc/arm/passthrough-noiommu.txt
@@ -33,14 +33,13 @@ on static allocation in the device-tree:
/ {
chosen {
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+ ...
domU1 {
compatible = "xen,domain";
- #address-cells = <0x2>;
- #size-cells = <0x2>;
cpus = <2>;
memory = <0x0 0x8>;
- #xen,static-mem-address-cells = <0x1>;
- #xen,static-mem-size-cells = <0x1>;
xen,static-mem = <0x3000 0x2000>;
direct-map;
...
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index ec81a45de9..cd264793d5 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -352,11 +352,6 @@ static int __init process_domain_node(const void *fdt, int
node,
/* No "xen,static-mem" present. */
return 0;
-address_cells = device_tree_get_u32(fdt, node,
-"#xen,static-mem-address-cells", 0);
-size_cells = device_tree_get_u32(fdt, node,
- "#xen,static-mem-size-cells", 0);
-
return device_tree_get_meminfo(fdt, node, "xen,static-mem", address_cells,
size_cells, _mem, true);
}
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b76a84e8f5..258d74699d 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -563,21 +563,9 @@ static int __init parse_static_mem_prop(const struct
dt_device_node *node,
const struct dt_property *prop;
prop = dt_find_property(node, "xen,static-mem", NULL);
-if ( !dt_property_read_u32(node, "#xen,static-mem-address-cells",
- addr_cells) )
-{
-printk(XENLOG_ERR
- "failed to read \"#xen,static-mem-address-cells\".\n");
-return -EINVAL;
-}
-if ( !dt_property_read_u32(node, "#xen,static-mem-size-cells",
- size_cells) )
-{
-printk(XENLOG_ERR
- "failed to read \"#xen,static-mem-size-cells\".\n");
-return -EINVAL;
-}
+*addr_cells = dt_n_addr_cells(node);
+*size_cells = dt_n_size_cells(node);
*cell = (const __be32 *)prop->value;
*length = prop->length;
--
2.17.1
Re: [PATCH v2 2/2] live migration: use superpages for physmap population on restore when possible
Hi Olaf, On 07/09/2022 08:45, Olaf Hering wrote: Wed, 7 Sep 2022 09:40:41 +0200 Jan Beulich : Olaf - I recall you've done some similar work before. Do you have any thoughts here, perhaps going as far as merging your and Andrei's work? > My variant is in the archives, for reference. You are referring to [1], is that correct? > I have no hope that any such work will be merged. Is this because it was lack of review or are there any technical difficulties/disagreements? If the former, this is not unsolvable. Depending on which approach we go, one of you could review the series of the other. With my AWS hat on, I would also be interested with the optimization in the LM code. So I would be willing to help reviewing it. That said, I can't promise any in-depth review before 4.17 is out. Cheers, [1] https://lore.kernel.org/xen-devel/20210713180605.12096-1-o...@aepfle.de -- Julien Grall
[for-4.17 v2 2/3] automation: qemu-smoke-arm64: Silence ifconfig error messages
During the ping test, dom1 tries to assign an ip to eth0 in a loop.
Before setting up the network interface by dom0, this results in
printing the following error message several times:
(XEN) DOM1: ifconfig: SIOCSIFADDR: No such device
Silence this by redirecting stderr/stdout to /dev/null as we do not
care about the output and we should not pollute the log file.
Signed-off-by: Michal Orzel
Reviewed-by: Luca Fancellu
Reviewed-by: Ayan Kumar Halder
---
Changes in v2:
- none
---
automation/scripts/qemu-smoke-arm64.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/automation/scripts/qemu-smoke-arm64.sh
b/automation/scripts/qemu-smoke-arm64.sh
index c80d9b2aee00..7ac96027760d 100755
--- a/automation/scripts/qemu-smoke-arm64.sh
+++ b/automation/scripts/qemu-smoke-arm64.sh
@@ -6,7 +6,7 @@ test_variant=$1
passed="passed"
check="
-until ifconfig eth0 192.168.0.2 && ping -c 10 192.168.0.1; do
+until ifconfig eth0 192.168.0.2 &> /dev/null && ping -c 10 192.168.0.1; do
sleep 30
done
echo \"${passed}\"
--
2.25.1
[for-4.17 v2 3/3] automation: Add a new job for testing boot time cpupools on arm64
Add a new test job qemu-smoke-arm64-gcc-boot-cpupools that will execute
script qemu-smoke-arm64.sh to test boot time cpupools feature.
Enable CONFIG_BOOT_TIME_CPUPOOLS for the arm64 build and add a new test
case in qemu-smoke-arm64.sh that if selected will make use of the
ImageBuilder feature to create cpupool with cpu@1, null scheduler and
assign it to domU. Add a check in dom0 xen.start to see if domU is
assigned a Pool-1 with null scheduler.
Take the opportunity to refactor the qemu-smoke-arm64.sh script as
follows:
- use domU_check to store the test's commands to be run from domU
- use dom0_check to store the test's commands to be run from dom0
- use fdtput instead of sed to perform dtb modifications
- use more meaningful messages for "passed" variable. This way we can
grep for messages reported either by domU or dom0 and get rid of
assumption that tests can only be run from domU
Signed-off-by: Michal Orzel
---
Changes in v2:
- use ImageBuilder feature to create boot-time cpupools
- also check if the scheduler is set up properly
---
automation/gitlab-ci/test.yaml | 19 ++
automation/scripts/build | 3 ++-
automation/scripts/qemu-smoke-arm64.sh | 36 +++---
3 files changed, 48 insertions(+), 10 deletions(-)
diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index 07209820b474..d899b3bdbf7a 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -100,6 +100,25 @@ qemu-smoke-arm64-gcc-staticmem:
tags:
- arm64
+qemu-smoke-arm64-gcc-boot-cpupools:
+ extends: .test-jobs-common
+ variables:
+CONTAINER: debian:unstable-arm64v8
+ script:
+- ./automation/scripts/qemu-smoke-arm64.sh boot-cpupools 2>&1 | tee
qemu-smoke-arm64.log
+ needs:
+- alpine-3.12-gcc-arm64
+- alpine-3.12-arm64-rootfs-export
+- kernel-5.19-arm64-export
+- qemu-system-aarch64-6.0.0-arm64-export
+ artifacts:
+paths:
+ - smoke.serial
+ - '*.log'
+when: always
+ tags:
+- arm64
+
qemu-smoke-arm32-gcc:
extends: .test-jobs-common
variables:
diff --git a/automation/scripts/build b/automation/scripts/build
index 2b9f2d2b541a..2f15ab3198e6 100755
--- a/automation/scripts/build
+++ b/automation/scripts/build
@@ -19,7 +19,8 @@ else
echo "
CONFIG_EXPERT=y
CONFIG_UNSUPPORTED=y
-CONFIG_STATIC_MEMORY=y" > xen/.config
+CONFIG_STATIC_MEMORY=y
+CONFIG_BOOT_TIME_CPUPOOLS=y" > xen/.config
make -j$(nproc) -C xen olddefconfig
else
make -j$(nproc) -C xen defconfig
diff --git a/automation/scripts/qemu-smoke-arm64.sh
b/automation/scripts/qemu-smoke-arm64.sh
index 7ac96027760d..f803835779f4 100755
--- a/automation/scripts/qemu-smoke-arm64.sh
+++ b/automation/scripts/qemu-smoke-arm64.sh
@@ -4,20 +4,22 @@ set -ex
test_variant=$1
-passed="passed"
-check="
+if [ -z "${test_variant}" ]; then
+passed="ping test passed"
+domU_check="
until ifconfig eth0 192.168.0.2 &> /dev/null && ping -c 10 192.168.0.1; do
sleep 30
done
echo \"${passed}\"
"
+fi
if [[ "${test_variant}" == "static-mem" ]]; then
# Memory range that is statically allocated to DOM1
domu_base="5000"
domu_size="1000"
passed="${test_variant} test passed"
-check="
+domU_check="
current=\$(hexdump -e '16/1 \"%02x\"'
/proc/device-tree/memory@${domu_base}/reg 2>/dev/null)
expected=$(printf \"%016x%016x\" 0x${domu_base} 0x${domu_size})
if [[ \"\${expected}\" == \"\${current}\" ]]; then
@@ -26,6 +28,16 @@ fi
"
fi
+if [[ "${test_variant}" == "boot-cpupools" ]]; then
+# Check if domU0 (id=1) is assigned to Pool-1 with null scheduler
+passed="${test_variant} test passed"
+dom0_check="
+if xl list -c 1 | grep -q Pool-1 && xl cpupool-list Pool-1 | grep -q Pool-1;
then
+echo ${passed}
+fi
+"
+fi
+
export DEBIAN_FRONTENT=noninteractive
apt-get -qy update
apt-get -qy install --no-install-recommends u-boot-qemu \
@@ -42,11 +54,9 @@ curl -fsSLO
https://github.com/qemu/qemu/raw/v5.2.0/pc-bios/efi-virtio.rom
-cpu cortex-a57 -machine type=virt \
-m 1024 -smp 2 -display none \
-machine dumpdtb=binaries/virt-gicv2.dtb
-# XXX disable pl061 to avoid Linux crash
-dtc -I dtb -O dts binaries/virt-gicv2.dtb > binaries/virt-gicv2.dts
-sed 's/compatible = "arm,pl061.*/status = "disabled";/g'
binaries/virt-gicv2.dts > binaries/virt-gicv2-edited.dts
-dtc -I dts -O dtb binaries/virt-gicv2-edited.dts > binaries/virt-gicv2.dtb
+# XXX disable pl061 to avoid Linux crash
+fdtput binaries/virt-gicv2.dtb -p -t s /pl061@903 status disabled
# Busybox
mkdir -p initrd
@@ -66,7 +76,7 @@ echo "#!/bin/sh
mount -t proc proc /proc
mount -t sysfs sysfs /sys
mount -t devtmpfs devtmpfs /dev
-${check}
+${domU_check}
/bin/sh" > initrd/init
chmod +x initrd/init
cd initrd
@@ -98,6 +108,7 @@ ifconfig xenbr0 up
ifconfig xenbr0 192.168.0.1
xl network-attach 1 type=vif
+${dom0_check}
" > etc/local.d/xen.start
chmod +x
[for-4.17 v2 0/3] GitLab CI cleanup and boot time cpupools test
This patch series performs a small cleanup before the release and adds a test for validating boot time cpupools feature introduced in 4.17. Notes for the release manager: Benefits: - improved dom0less test coverage - tested feature that is introduced in 4.17 Risks: - CI pipeline failure Michal Orzel (3): automation: qemu-alpine-arm64-gcc: Use kernel 5.19 automation: qemu-smoke-arm64: Silence ifconfig error messages automation: Add a new job for testing boot time cpupools on arm64 automation/gitlab-ci/build.yaml | 11 -- automation/gitlab-ci/test.yaml| 21 +- automation/scripts/build | 3 +- automation/scripts/qemu-smoke-arm64.sh| 38 ++- .../kernel/5.9.9-arm64v8.dockerfile | 34 - 5 files changed, 50 insertions(+), 57 deletions(-) delete mode 100644 automation/tests-artifacts/kernel/5.9.9-arm64v8.dockerfile -- 2.25.1
[for-4.17 v2 1/3] automation: qemu-alpine-arm64-gcc: Use kernel 5.19
After qemu-smoke-arm64 was changed to use kernel 5.19 we end up having two kernel configurations. This is something not needed and maintaining a single kernel version is always easier. Modify qemu-alpine-arm64-gcc to use kernel 5.19 and remove kernel 5.9 from tests-artifacts. Signed-off-by: Michal Orzel Reviewed-by: Luca Fancellu Reviewed-by: Ayan Kumar Halder --- Changes in v2: - none --- automation/gitlab-ci/build.yaml | 11 -- automation/gitlab-ci/test.yaml| 2 +- .../kernel/5.9.9-arm64v8.dockerfile | 34 --- 3 files changed, 1 insertion(+), 46 deletions(-) delete mode 100644 automation/tests-artifacts/kernel/5.9.9-arm64v8.dockerfile diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml index d2f75a090c0f..720ce6e07ba0 100644 --- a/automation/gitlab-ci/build.yaml +++ b/automation/gitlab-ci/build.yaml @@ -586,17 +586,6 @@ alpine-3.12-arm64-rootfs-export: tags: - arm64 -kernel-5.9.9-arm64-export: - extends: .test-jobs-artifact-common - image: registry.gitlab.com/xen-project/xen/tests-artifacts/kernel:5.9.9-arm64v8 - script: -- mkdir binaries && cp /Image binaries/Image - artifacts: -paths: - - binaries/Image - tags: -- arm64 - kernel-5.19-arm64-export: extends: .test-jobs-artifact-common image: registry.gitlab.com/xen-project/xen/tests-artifacts/kernel:5.19-arm64v8 diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml index 2eb6c3866e2c..07209820b474 100644 --- a/automation/gitlab-ci/test.yaml +++ b/automation/gitlab-ci/test.yaml @@ -34,7 +34,7 @@ qemu-alpine-arm64-gcc: needs: - alpine-3.12-gcc-arm64 - alpine-3.12-arm64-rootfs-export -- kernel-5.9.9-arm64-export +- kernel-5.19-arm64-export - qemu-system-aarch64-6.0.0-arm64-export artifacts: paths: diff --git a/automation/tests-artifacts/kernel/5.9.9-arm64v8.dockerfile b/automation/tests-artifacts/kernel/5.9.9-arm64v8.dockerfile deleted file mode 100644 index 053d65a3454e.. --- a/automation/tests-artifacts/kernel/5.9.9-arm64v8.dockerfile +++ /dev/null @@ -1,34 +0,0 @@ -FROM arm64v8/debian:unstable -LABEL maintainer.name="The Xen Project" \ - maintainer.email="xen-devel@lists.xenproject.org" - -ENV DEBIAN_FRONTEND=noninteractive -ENV LINUX_VERSION=5.9.9 -ENV USER root - -RUN mkdir /build -WORKDIR /build - -# build depends -RUN apt-get update && \ -apt-get --quiet --yes install \ -build-essential \ -libssl-dev \ -bc \ -curl \ -flex \ -bison \ -&& \ -\ -# Build the kernel -curl -fsSLO https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-"$LINUX_VERSION".tar.xz && \ -tar xvJf linux-"$LINUX_VERSION".tar.xz && \ -cd linux-"$LINUX_VERSION" && \ -make defconfig && \ -make -j$(nproc) Image.gz && \ -cp arch/arm64/boot/Image / && \ -cd /build && \ -rm -rf linux-"$LINUX_VERSION"* && \ -apt-get autoremove -y && \ -apt-get clean && \ -rm -rf /var/lib/apt/lists* /tmp/* /var/tmp/* -- 2.25.1
Re: [for-4.17 1/3] automation: qemu-alpine-arm64-gcc: Use kernel 5.19
Hi Ayan, On 08/09/2022 11:07, Ayan Kumar Halder wrote: > Hi Michal, > > On 02/09/2022 08:09, Michal Orzel wrote: >> After qemu-smoke-arm64 was changed to use kernel 5.19 we end up having >> two kernel configurations. This is something not needed and maintaining >> a single kernel version is always easier. Modify qemu-alpine-arm64-gcc >> to use kernel 5.19 and remove kernel 5.9 from tests-artifacts. >> >> Signed-off-by: Michal Orzel > Reviewed-by: Ayan Kumar Halder > > Question unrelated to the patch. > > When do we decide that we need to upgrade the kernel version ? Usually when we need a feature from the newer kernel version. Upgrade to 5.19 was done so that we can test dom0less enhanced as this kernel introduced late xenstore initialization. ~Michal
Re: [for-4.17 2/3] automation: qemu-smoke-arm64: Silence ifconfig error messages
On 02/09/2022 08:09, Michal Orzel wrote:
During the ping test, dom1 tries to assign an ip to eth0 in a loop.
Before setting up the network interface by dom0, this results in
printing the following error message several times:
(XEN) DOM1: ifconfig: SIOCSIFADDR: No such device
Silence this by redirecting stderr/stdout to /dev/null as we do not
care about the output and we should not pollute the log file.
Signed-off-by: Michal Orzel
Reviewed-by: Ayan Kumar Halder
---
automation/scripts/qemu-smoke-arm64.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/automation/scripts/qemu-smoke-arm64.sh
b/automation/scripts/qemu-smoke-arm64.sh
index c80d9b2aee00..7ac96027760d 100755
--- a/automation/scripts/qemu-smoke-arm64.sh
+++ b/automation/scripts/qemu-smoke-arm64.sh
@@ -6,7 +6,7 @@ test_variant=$1
passed="passed"
check="
-until ifconfig eth0 192.168.0.2 && ping -c 10 192.168.0.1; do
+until ifconfig eth0 192.168.0.2 &> /dev/null && ping -c 10 192.168.0.1; do
sleep 30
done
echo \"${passed}\"
Re: [PATCH v4 2/6] xen/x86: move generically usable NUMA code from x86 to common
On 02.09.2022 05:31, Wei Chen wrote:
> --- /dev/null
> +++ b/xen/common/numa.c
> @@ -0,0 +1,442 @@
> +/*
> + * Generic VM initialization for NUMA setups.
> + * Copyright 2002,2003 Andi Kleen, SuSE Labs.
> + * Adapted for Xen: Ryan Harper
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct node_data __ro_after_init node_data[MAX_NUMNODES];
> +
> +/* Mapping from pdx to node id */
> +unsigned int __ro_after_init memnode_shift;
> +unsigned long __ro_after_init memnodemapsize;
> +uint8_t *__ro_after_init memnodemap;
> +static uint8_t __ro_after_init _memnodemap[64];
These last two want to use nodeid_t instead of uint8_t. Originally
the latter used typeof(*memnodemap) for (I think - iirc it was me who
made it that way) this reason: That way correcting memnodemap's type
would have propagated without the need for further adjustments.
> +nodeid_t __read_mostly cpu_to_node[NR_CPUS] = {
> +[0 ... NR_CPUS-1] = NUMA_NO_NODE
> +};
> +
> +cpumask_t __read_mostly node_to_cpumask[MAX_NUMNODES];
> +
> +nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
> +
> +bool __read_mostly numa_off;
The v3 review discussing this possibly becoming __ro_after_init didn't
really finish (you didn't reply to my latest request there), but you
also didn't change the attribute. Please clarify.
> +static int __init populate_memnodemap(const struct node *nodes,
> + unsigned int numnodes, unsigned int
> shift,
> + nodeid_t *nodeids)
Can't this be pointer-to-const, and then also in the caller?
> +static unsigned int __init extract_lsb_from_nodes(const struct node *nodes,
> + nodeid_t numnodes)
> +{
> +unsigned int i;
> +nodeid_t nodes_used = 0;
This once again is a variable which doesn't really hold a node ID (but
instead is a counter), and hence would better be unsigned int (see
./CODING_STYLE).
> +unsigned long spdx, epdx;
> +unsigned long bitfield = 0, memtop = 0;
> +
> +for ( i = 0; i < numnodes; i++ )
> +{
> +spdx = paddr_to_pdx(nodes[i].start);
> +epdx = paddr_to_pdx(nodes[i].end - 1) + 1;
> +if ( spdx >= epdx )
> +continue;
> +bitfield |= spdx;
> +nodes_used++;
> +if ( epdx > memtop )
> +memtop = epdx;
> +}
> +if ( nodes_used <= 1 )
> +i = BITS_PER_LONG - 1;
> +else
> +i = find_first_bit(, sizeof(unsigned long)*8);
Please add the missing blanks around * .
> +memnodemapsize = (memtop >> i) + 1;
> +return i;
Please add the missing blank line before the (main) return statement
of the function.
> +int __init compute_hash_shift(const struct node *nodes,
> + nodeid_t numnodes, nodeid_t *nodeids)
While I agree that nodeid_t can hold all necessary values, I still
don't think a cound should be expressed by nodeid_t. As above - see
./CODING_STYLE.
> +{
> +unsigned int shift;
> +
> +shift = extract_lsb_from_nodes(nodes, numnodes);
> +if ( memnodemapsize <= ARRAY_SIZE(_memnodemap) )
> +memnodemap = _memnodemap;
> +else if ( allocate_cachealigned_memnodemap() )
> +return -1;
> +printk(KERN_DEBUG "NUMA: Using %d for the hash shift.\n", shift);
This wants to be %u now. I'd also like to ask to drop the full stop
at this occasion.
> +if ( populate_memnodemap(nodes, numnodes, shift, nodeids) != 1 )
> +{
> +printk(KERN_INFO "Your memory is not aligned you need to "
> + "rebuild your hypervisor with a bigger NODEMAPSIZE "
> + "shift=%d\n", shift);
Again %u please.
> +/* initialize NODE_DATA given nodeid and start/end */
> +void __init setup_node_bootmem(nodeid_t nodeid, paddr_t start, paddr_t end)
Please capitalize the first letter of the comment (see ./CODING_STYLE).
> +void __init numa_init_array(void)
> +{
> +unsigned int i;
> +nodeid_t rr;
> +
> +/*
> + * There are unfortunately some poorly designed mainboards around
> + * that only connect memory to a single CPU. This breaks the 1:1
> cpu->node
> + * mapping. To avoid this fill in the mapping for all possible
> + * CPUs, as the number of CPUs is not known yet.
> + * We round robin the existing nodes.
> + */
Along with the style correction re-flowing of the text would have been
nice, such the lines aren't wrapped seemingly randomly without utilizing
permitted line length.
> +void __init numa_initmem_init(unsigned long start_pfn, unsigned long end_pfn)
> +{
> +unsigned int i;
> +paddr_t start = pfn_to_paddr(start_pfn);
> +paddr_t end = pfn_to_paddr(end_pfn);
> +
> +#ifdef CONFIG_NUMA_EMU
> +if ( numa_fake && !numa_emulation(start_pfn, end_pfn) )
> +return;
> +#endif
> +
> +#ifdef CONFIG_NUMA
> +if ( !numa_off && !numa_scan_nodes(start, end) )
> +return;
> +#endif
RE: [PATCH v5 2/4] docs, xen/arm: Introduce static heap memory
Hi Michal,
> -Original Message-
> From: Michal Orzel
> > +- #address-cells and #size-cells
> > +
> > +Specify the number of cells used for the address and size of the
> > +"xen,static-heap" property. Note that according to the device tree
> > +specification, the number of address cells and size cells of
> > +"xen,static-heap" is determined by the parent #address-cells and
> > +#size-cells of the top-level "chosen" node.
> I am not sure we should put the information about #address-cells and #size-
> cells in that form.
> Firstly because /chosen node is always a child of / node and according to
> specs [1]
> the #address-cells and #size-cells are required properties for the root node.
>
> If we want to still mention it I would just write under xen,static-heap:
> "Number of address and size cells for the xen,static-heap property is
> determined
> by the root node #address-cells/#size-cells".
Thanks, I will address this comments and ...
>
> > +printk("Checking for static heap in /chosen\n");
> > +if ( address_cells < 1 || size_cells < 1 )
> > +{
> > +printk("fdt: node `%s': invalid #address-cells or
> > #size-cells\n",
> > + name);
> > +return -EINVAL;
> > +}
> This check is now the direct copy of the one in device_tree_get_meminfo so
> please remove it
> to avoid code duplication.
...this in v6, but I want to see if there would be more comments before sending
it.
Kind regards,
Henry
>
> ~Michal
>
> [1] https://devicetree-
> specification.readthedocs.io/en/v0.3/devicenodes.html
Re: [for-4.17 1/3] automation: qemu-alpine-arm64-gcc: Use kernel 5.19
Hi Michal, On 02/09/2022 08:09, Michal Orzel wrote: After qemu-smoke-arm64 was changed to use kernel 5.19 we end up having two kernel configurations. This is something not needed and maintaining a single kernel version is always easier. Modify qemu-alpine-arm64-gcc to use kernel 5.19 and remove kernel 5.9 from tests-artifacts. Signed-off-by: Michal Orzel Reviewed-by: Ayan Kumar Halder Question unrelated to the patch. When do we decide that we need to upgrade the kernel version ? --- automation/gitlab-ci/build.yaml | 11 -- automation/gitlab-ci/test.yaml| 2 +- .../kernel/5.9.9-arm64v8.dockerfile | 34 --- 3 files changed, 1 insertion(+), 46 deletions(-) delete mode 100644 automation/tests-artifacts/kernel/5.9.9-arm64v8.dockerfile diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml index d2f75a090c0f..720ce6e07ba0 100644 --- a/automation/gitlab-ci/build.yaml +++ b/automation/gitlab-ci/build.yaml @@ -586,17 +586,6 @@ alpine-3.12-arm64-rootfs-export: tags: - arm64 -kernel-5.9.9-arm64-export: - extends: .test-jobs-artifact-common - image: registry.gitlab.com/xen-project/xen/tests-artifacts/kernel:5.9.9-arm64v8 - script: -- mkdir binaries && cp /Image binaries/Image - artifacts: -paths: - - binaries/Image - tags: -- arm64 - kernel-5.19-arm64-export: extends: .test-jobs-artifact-common image: registry.gitlab.com/xen-project/xen/tests-artifacts/kernel:5.19-arm64v8 diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml index 2eb6c3866e2c..07209820b474 100644 --- a/automation/gitlab-ci/test.yaml +++ b/automation/gitlab-ci/test.yaml @@ -34,7 +34,7 @@ qemu-alpine-arm64-gcc: needs: - alpine-3.12-gcc-arm64 - alpine-3.12-arm64-rootfs-export -- kernel-5.9.9-arm64-export +- kernel-5.19-arm64-export - qemu-system-aarch64-6.0.0-arm64-export artifacts: paths: diff --git a/automation/tests-artifacts/kernel/5.9.9-arm64v8.dockerfile b/automation/tests-artifacts/kernel/5.9.9-arm64v8.dockerfile deleted file mode 100644 index 053d65a3454e.. --- a/automation/tests-artifacts/kernel/5.9.9-arm64v8.dockerfile +++ /dev/null @@ -1,34 +0,0 @@ -FROM arm64v8/debian:unstable -LABEL maintainer.name="The Xen Project" \ - maintainer.email="xen-devel@lists.xenproject.org" - -ENV DEBIAN_FRONTEND=noninteractive -ENV LINUX_VERSION=5.9.9 -ENV USER root - -RUN mkdir /build -WORKDIR /build - -# build depends -RUN apt-get update && \ -apt-get --quiet --yes install \ -build-essential \ -libssl-dev \ -bc \ -curl \ -flex \ -bison \ -&& \ -\ -# Build the kernel -curl -fsSLO https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-"$LINUX_VERSION".tar.xz && \ -tar xvJf linux-"$LINUX_VERSION".tar.xz && \ -cd linux-"$LINUX_VERSION" && \ -make defconfig && \ -make -j$(nproc) Image.gz && \ -cp arch/arm64/boot/Image / && \ -cd /build && \ -rm -rf linux-"$LINUX_VERSION"* && \ -apt-get autoremove -y && \ -apt-get clean && \ -rm -rf /var/lib/apt/lists* /tmp/* /var/tmp/*
[PATCH v3 08/10] x86/mtrr: let cache_aps_delayed_init replace mtrr_aps_delayed_init
In order to prepare decoupling MTRR and PAT replace the MTRR specific
mtrr_aps_delayed_init flag with a more generic cache_aps_delayed_init
one.
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
arch/x86/include/asm/cacheinfo.h | 2 ++
arch/x86/include/asm/mtrr.h | 2 --
arch/x86/kernel/cpu/cacheinfo.c | 2 ++
arch/x86/kernel/cpu/mtrr/mtrr.c | 17 -
arch/x86/kernel/smpboot.c| 5 +++--
5 files changed, 11 insertions(+), 17 deletions(-)
diff --git a/arch/x86/include/asm/cacheinfo.h b/arch/x86/include/asm/cacheinfo.h
index 563d9cb5fcf5..e80ed3c523c8 100644
--- a/arch/x86/include/asm/cacheinfo.h
+++ b/arch/x86/include/asm/cacheinfo.h
@@ -7,6 +7,8 @@ extern unsigned int cache_generic;
#define CACHE_GENERIC_MTRR 0x01
#define CACHE_GENERIC_PAT 0x02
+extern bool cache_aps_delayed_init;
+
void cacheinfo_amd_init_llc_id(struct cpuinfo_x86 *c, int cpu);
void cacheinfo_hygon_init_llc_id(struct cpuinfo_x86 *c, int cpu);
diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
index 986249a2b9b6..5d31219c8529 100644
--- a/arch/x86/include/asm/mtrr.h
+++ b/arch/x86/include/asm/mtrr.h
@@ -43,7 +43,6 @@ extern int mtrr_del(int reg, unsigned long base, unsigned
long size);
extern int mtrr_del_page(int reg, unsigned long base, unsigned long size);
extern void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi);
extern void mtrr_ap_init(void);
-extern void set_mtrr_aps_delayed_init(void);
extern void mtrr_aps_init(void);
extern void mtrr_bp_restore(void);
extern int mtrr_trim_uncached_memory(unsigned long end_pfn);
@@ -87,7 +86,6 @@ static inline void mtrr_centaur_report_mcr(int mcr, u32 lo,
u32 hi)
{
}
#define mtrr_ap_init() do {} while (0)
-#define set_mtrr_aps_delayed_init() do {} while (0)
#define mtrr_aps_init() do {} while (0)
#define mtrr_bp_restore() do {} while (0)
#define mtrr_disable() do {} while (0)
diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index 36378604ec61..c6e7c93e45e8 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -1139,3 +1139,5 @@ void cache_cpu_init(void)
cache_enable();
local_irq_restore(flags);
}
+
+bool cache_aps_delayed_init;
diff --git a/arch/x86/kernel/cpu/mtrr/mtrr.c b/arch/x86/kernel/cpu/mtrr/mtrr.c
index 956838bb4481..a47d46035240 100644
--- a/arch/x86/kernel/cpu/mtrr/mtrr.c
+++ b/arch/x86/kernel/cpu/mtrr/mtrr.c
@@ -65,7 +65,6 @@ unsigned int mtrr_usage_table[MTRR_MAX_VAR_RANGES];
static DEFINE_MUTEX(mtrr_mutex);
u64 size_or_mask, size_and_mask;
-static bool mtrr_aps_delayed_init;
static const struct mtrr_ops *mtrr_ops[X86_VENDOR_NUM] __ro_after_init;
@@ -172,7 +171,7 @@ static int mtrr_rendezvous_handler(void *info)
if (data->smp_reg != ~0U) {
mtrr_if->set(data->smp_reg, data->smp_base,
data->smp_size, data->smp_type);
- } else if (mtrr_aps_delayed_init || !cpu_online(smp_processor_id())) {
+ } else if (cache_aps_delayed_init || !cpu_online(smp_processor_id())) {
cache_cpu_init();
}
return 0;
@@ -784,7 +783,7 @@ void __init mtrr_bp_init(void)
void mtrr_ap_init(void)
{
- if (!cache_generic || mtrr_aps_delayed_init)
+ if (!cache_generic || cache_aps_delayed_init)
return;
/*
@@ -818,14 +817,6 @@ void mtrr_save_state(void)
smp_call_function_single(first_cpu, mtrr_save_fixed_ranges, NULL, 1);
}
-void set_mtrr_aps_delayed_init(void)
-{
- if (!cache_generic)
- return;
-
- mtrr_aps_delayed_init = true;
-}
-
/*
* Delayed MTRR initialization for all AP's
*/
@@ -839,11 +830,11 @@ void mtrr_aps_init(void)
* by doing set_mtrr_aps_delayed_init(), prior to this point. If not,
* then we are done.
*/
- if (!mtrr_aps_delayed_init)
+ if (!cache_aps_delayed_init)
return;
set_mtrr(~0U, 0, 0, 0);
- mtrr_aps_delayed_init = false;
+ cache_aps_delayed_init = false;
}
void mtrr_bp_restore(void)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index f24227bc3220..ef7bce21cbe8 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -58,6 +58,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1428,7 +1429,7 @@ void __init native_smp_prepare_cpus(unsigned int max_cpus)
uv_system_init();
- set_mtrr_aps_delayed_init();
+ cache_aps_delayed_init = true;
smp_quirk_init_udelay();
@@ -1439,7 +1440,7 @@ void __init native_smp_prepare_cpus(unsigned int max_cpus)
void arch_thaw_secondary_cpus_begin(void)
{
- set_mtrr_aps_delayed_init();
+ cache_aps_delayed_init = true;
}
void arch_thaw_secondary_cpus_end(void)
--
2.35.3
[PATCH v3 10/10] x86: decouple pat and mtrr handling
Today PAT is usable only with MTRR being active, with some nasty tweaks
to make PAT usable when running as Xen PV guest, which doesn't support
MTRR.
The reason for this coupling is, that both, PAT MSR changes and MTRR
changes, require a similar sequence and so full PAT support was added
using the already available MTRR handling.
Xen PV PAT handling can work without MTRR, as it just needs to consume
the PAT MSR setting done by the hypervisor without the ability and need
to change it. This in turn has resulted in a convoluted initialization
sequence and wrong decisions regarding cache mode availability due to
misguiding PAT availability flags.
Fix all of that by allowing to use PAT without MTRR and by reworking
the current PAT initialization sequence to match better with the newly
introduced generic cache initialization.
This removes the need of the recently added pat_force_disabled flag, so
remove the remnants of the patch adding it.
Signed-off-by: Juergen Gross
---
V2:
- former patch 3 completely reworked
---
arch/x86/include/asm/memtype.h | 5 +-
arch/x86/kernel/cpu/cacheinfo.c | 3 +-
arch/x86/kernel/cpu/mtrr/mtrr.c | 13 +---
arch/x86/kernel/setup.c | 13 +---
arch/x86/mm/pat/memtype.c | 127 ++--
5 files changed, 45 insertions(+), 116 deletions(-)
diff --git a/arch/x86/include/asm/memtype.h b/arch/x86/include/asm/memtype.h
index 9ca760e430b9..113b2fa51849 100644
--- a/arch/x86/include/asm/memtype.h
+++ b/arch/x86/include/asm/memtype.h
@@ -6,9 +6,8 @@
#include
extern bool pat_enabled(void);
-extern void pat_disable(const char *reason);
-extern void pat_init(void);
-extern void init_cache_modes(void);
+extern void pat_bp_init(void);
+extern void pat_cpu_init(void);
extern int memtype_reserve(u64 start, u64 end,
enum page_cache_mode req_pcm, enum page_cache_mode *ret_pcm);
diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index 4946f93eb16f..08130919d55d 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -1135,7 +1135,7 @@ static void cache_cpu_init(void)
/* Set PAT. */
if (cache_generic & CACHE_GENERIC_PAT)
- pat_init();
+ pat_cpu_init();
cache_enable();
local_irq_restore(flags);
@@ -1154,6 +1154,7 @@ static int cache_rendezvous_handler(void *unused)
void __init cache_bp_init(void)
{
mtrr_bp_init();
+ pat_bp_init();
if (cache_generic)
cache_cpu_init();
diff --git a/arch/x86/kernel/cpu/mtrr/mtrr.c b/arch/x86/kernel/cpu/mtrr/mtrr.c
index 5e8be11d1873..921f425fe7b3 100644
--- a/arch/x86/kernel/cpu/mtrr/mtrr.c
+++ b/arch/x86/kernel/cpu/mtrr/mtrr.c
@@ -727,24 +727,15 @@ void __init mtrr_bp_init(void)
mtrr_enabled = get_mtrr_state();
if (mtrr_enabled) {
- cache_generic |= CACHE_GENERIC_MTRR |
-CACHE_GENERIC_PAT;
+ cache_generic |= CACHE_GENERIC_MTRR;
changed_by_mtrr_cleanup =
mtrr_cleanup(phys_addr);
}
}
}
- if (!mtrr_enabled) {
+ if (!mtrr_enabled)
pr_info("Disabled\n");
-
- /*
-* PAT initialization relies on MTRR's rendezvous handler.
-* Skip PAT init until the handler can initialize both
-* features independently.
-*/
- pat_disable("MTRRs disabled, skipping PAT initialization too.");
- }
}
/**
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index e0e185ee0229..aacaa96f0195 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1075,23 +1075,12 @@ void __init setup_arch(char **cmdline_p)
max_pfn = e820__end_of_ram_pfn();
/* update e820 for memory not covered by WB MTRRs */
- if (IS_ENABLED(CONFIG_MTRR))
- cache_bp_init();
- else
- pat_disable("PAT support disabled because CONFIG_MTRR is
disabled in the kernel.");
-
+ cache_bp_init();
if (mtrr_trim_uncached_memory(max_pfn))
max_pfn = e820__end_of_ram_pfn();
max_possible_pfn = max_pfn;
- /*
-* This call is required when the CPU does not support PAT. If
-* mtrr_bp_init() invoked it already via pat_init() the call has no
-* effect.
-*/
- init_cache_modes();
-
/*
* Define random base addresses for memory sections after max_pfn is
* defined and before each memory section base is used.
diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c
index 66a209f7eb86..1f62fc40e6df 100644
--- a/arch/x86/mm/pat/memtype.c
+++ b/arch/x86/mm/pat/memtype.c
@@ -43,6 +43,7 @@
#include
#include
+#include
#include
[PATCH v3 09/10] x86/mtrr: add a stop_machine() handler calling only cache_cpu_init()
Instead of having a stop_machine() handler for either a specific MTRR
register or all state at once, add a handler just for calling
cache_cpu_init() if appropriate.
Add functions for calling stop_machine() with this handler as well.
Add a generic replacements for mtrr_bp_restore() and a wrapper for
mtrr_bp_init().
Signed-off-by: Juergen Gross
---
V2:
- completely new replacement of former patch 2
---
arch/x86/include/asm/cacheinfo.h | 5 +-
arch/x86/include/asm/mtrr.h | 4 --
arch/x86/kernel/cpu/cacheinfo.c | 59 +-
arch/x86/kernel/cpu/common.c | 3 +-
arch/x86/kernel/cpu/mtrr/mtrr.c | 87 +---
arch/x86/kernel/setup.c | 3 +-
arch/x86/kernel/smpboot.c| 4 +-
arch/x86/power/cpu.c | 3 +-
8 files changed, 72 insertions(+), 96 deletions(-)
diff --git a/arch/x86/include/asm/cacheinfo.h b/arch/x86/include/asm/cacheinfo.h
index e80ed3c523c8..a122a1aad936 100644
--- a/arch/x86/include/asm/cacheinfo.h
+++ b/arch/x86/include/asm/cacheinfo.h
@@ -14,6 +14,9 @@ void cacheinfo_hygon_init_llc_id(struct cpuinfo_x86 *c, int
cpu);
void cache_disable(void);
void cache_enable(void);
-void cache_cpu_init(void);
+void cache_bp_init(void);
+void cache_bp_restore(void);
+void cache_ap_init(void);
+void cache_aps_init(void);
#endif /* _ASM_X86_CACHEINFO_H */
diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
index 5d31219c8529..ec73d1e5bafb 100644
--- a/arch/x86/include/asm/mtrr.h
+++ b/arch/x86/include/asm/mtrr.h
@@ -42,8 +42,6 @@ extern int mtrr_add_page(unsigned long base, unsigned long
size,
extern int mtrr_del(int reg, unsigned long base, unsigned long size);
extern int mtrr_del_page(int reg, unsigned long base, unsigned long size);
extern void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi);
-extern void mtrr_ap_init(void);
-extern void mtrr_aps_init(void);
extern void mtrr_bp_restore(void);
extern int mtrr_trim_uncached_memory(unsigned long end_pfn);
extern int amd_special_default_mtrr(void);
@@ -85,8 +83,6 @@ static inline int mtrr_trim_uncached_memory(unsigned long
end_pfn)
static inline void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi)
{
}
-#define mtrr_ap_init() do {} while (0)
-#define mtrr_aps_init() do {} while (0)
#define mtrr_bp_restore() do {} while (0)
#define mtrr_disable() do {} while (0)
#define mtrr_enable() do {} while (0)
diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index c6e7c93e45e8..4946f93eb16f 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1121,7 +1122,7 @@ void cache_enable(void) __releases(cache_disable_lock)
raw_spin_unlock(_disable_lock);
}
-void cache_cpu_init(void)
+static void cache_cpu_init(void)
{
unsigned long flags;
@@ -1141,3 +1142,59 @@ void cache_cpu_init(void)
}
bool cache_aps_delayed_init;
+
+static int cache_rendezvous_handler(void *unused)
+{
+ if (cache_aps_delayed_init || !cpu_online(smp_processor_id()))
+ cache_cpu_init();
+
+ return 0;
+}
+
+void __init cache_bp_init(void)
+{
+ mtrr_bp_init();
+
+ if (cache_generic)
+ cache_cpu_init();
+}
+
+void cache_bp_restore(void)
+{
+ if (cache_generic)
+ cache_cpu_init();
+}
+
+void cache_ap_init(void)
+{
+ if (!cache_generic || cache_aps_delayed_init)
+ return;
+
+ /*
+* Ideally we should hold mtrr_mutex here to avoid mtrr entries
+* changed, but this routine will be called in cpu boot time,
+* holding the lock breaks it.
+*
+* This routine is called in two cases:
+*
+* 1. very early time of software resume, when there absolutely
+* isn't mtrr entry changes;
+*
+* 2. cpu hotadd time. We let mtrr_add/del_page hold cpuhotplug
+* lock to prevent mtrr entry changes
+*/
+ stop_machine_from_inactive_cpu(cache_rendezvous_handler, NULL,
+ cpu_callout_mask);
+}
+
+/*
+ * Delayed cache initialization for all AP's
+ */
+void cache_aps_init(void)
+{
+ if (!cache_generic || !cache_aps_delayed_init)
+ return;
+
+ stop_machine(cache_rendezvous_handler, NULL, cpu_online_mask);
+ cache_aps_delayed_init = false;
+}
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 3e508f239098..fd058b547f8d 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -52,6 +52,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1948,7 +1949,7 @@ void identify_secondary_cpu(struct cpuinfo_x86 *c)
#ifdef CONFIG_X86_32
enable_sep_cpu();
#endif
- mtrr_ap_init();
+ cache_ap_init();
validate_apic_and_package_id(c);
x86_spec_ctrl_setup_ap();
[PATCH V6 3/3] libxl: arm: make creation of iommu node independent of disk device
The iommu node will be required for other virtio device types too, not
just disk device.
Move the call to make_xen_iommu_node(), out of the disk device specific
block and rename "iommu_created" variable to "iommu_needed", and set it
to true for virtio disk device.
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 55aee15c10b4..2637acafa358 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -1157,7 +1157,7 @@ static int libxl__prepare_dtb(libxl__gc *gc,
libxl_domain_config *d_config,
size_t fdt_size = 0;
int pfdt_size = 0;
libxl_domain_build_info *const info = _config->b_info;
-bool iommu_created;
+bool iommu_needed;
unsigned int i;
const libxl_version_info *vers;
@@ -1265,22 +1265,26 @@ static int libxl__prepare_dtb(libxl__gc *gc,
libxl_domain_config *d_config,
if (d_config->num_pcidevs)
FDT( make_vpci_node(gc, fdt, ainfo, dom) );
-iommu_created = false;
+iommu_needed = false;
for (i = 0; i < d_config->num_disks; i++) {
libxl_device_disk *disk = _config->disks[i];
if (disk->specification == LIBXL_DISK_SPECIFICATION_VIRTIO) {
-if (disk->backend_domid != LIBXL_TOOLSTACK_DOMID &&
-!iommu_created) {
-FDT( make_xen_iommu_node(gc, fdt) );
-iommu_created = true;
-}
+if (disk->backend_domid != LIBXL_TOOLSTACK_DOMID)
+iommu_needed = true;
FDT( make_virtio_mmio_node(gc, fdt, disk->base, disk->irq,
disk->backend_domid) );
}
}
+/*
+ * Note, this should be only called after creating all virtio-mmio
+ * device nodes
+ */
+if (iommu_needed)
+FDT( make_xen_iommu_node(gc, fdt) );
+
if (pfdt)
FDT( copy_partial_fdt(gc, fdt, pfdt) );
--
2.31.1.272.g89b43f80a514
[PATCH V6 2/3] libxl: arm: Split make_virtio_mmio_node()
make_virtio_mmio_node() creates the DT node for simple MMIO devices
currently, i.e. the ones that don't require any additional properties.
In order to allow using it for other complex device types, split the
functionality into two, one where the fdt node isn't closed and the
other one to create a simple DT node.
Reviewed-by: Oleksandr Tyshchenko
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index cc30ba124918..55aee15c10b4 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -907,9 +907,9 @@ static int make_xen_iommu_node(libxl__gc *gc, void *fdt)
return 0;
}
-static int make_virtio_mmio_node(libxl__gc *gc, void *fdt,
- uint64_t base, uint32_t irq,
- uint32_t backend_domid)
+/* The caller is responsible to complete / close the fdt node */
+static int make_virtio_mmio_node_common(libxl__gc *gc, void *fdt, uint64_t
base,
+uint32_t irq, uint32_t backend_domid)
{
int res;
gic_interrupt intr;
@@ -942,10 +942,18 @@ static int make_virtio_mmio_node(libxl__gc *gc, void *fdt,
if (res) return res;
}
-res = fdt_end_node(fdt);
+return res;
+}
+
+static int make_virtio_mmio_node(libxl__gc *gc, void *fdt, uint64_t base,
+ uint32_t irq, uint32_t backend_domid)
+{
+int res;
+
+res = make_virtio_mmio_node_common(gc, fdt, base, irq, backend_domid);
if (res) return res;
-return 0;
+return fdt_end_node(fdt);
}
static const struct arch_info *get_arch_info(libxl__gc *gc,
--
2.31.1.272.g89b43f80a514
[PATCH V6 1/3] libxl: arm: Create alloc_virtio_mmio_params()
In order to prepare for adding support for more device types, create a
separate routine to allocate base and irq for a device as the same code
will be required for other device types too.
Also move updates to virtio_irq and virtio_enabled out of the disk
device specific block, as they will depend on other device types too.
Suggested-by: Oleksandr Tyshchenko
Reviewed-by: Oleksandr Tyshchenko
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 47 +---
1 file changed, 33 insertions(+), 14 deletions(-)
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 1a3ac1646e94..cc30ba124918 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -48,6 +48,24 @@ static uint32_t alloc_virtio_mmio_irq(libxl__gc *gc,
uint32_t *virtio_mmio_irq)
return irq;
}
+static int alloc_virtio_mmio_params(libxl__gc *gc, uint64_t *base,
+uint32_t *irq, uint64_t *virtio_mmio_base,
+uint32_t *virtio_mmio_irq)
+{
+*base = alloc_virtio_mmio_base(gc, virtio_mmio_base);
+if (!*base)
+return ERROR_FAIL;
+
+*irq = alloc_virtio_mmio_irq(gc, virtio_mmio_irq);
+if (!*irq)
+return ERROR_FAIL;
+
+LOG(DEBUG, "Allocate Virtio MMIO params: IRQ %u BASE 0x%"PRIx64, *irq,
+*base);
+
+return 0;
+}
+
static const char *gicv_to_string(libxl_gic_version gic_version)
{
switch (gic_version) {
@@ -70,6 +88,7 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
bool vuart_enabled = false, virtio_enabled = false;
uint64_t virtio_mmio_base = GUEST_VIRTIO_MMIO_BASE;
uint32_t virtio_mmio_irq = GUEST_VIRTIO_MMIO_SPI_FIRST;
+int rc;
/*
* If pl011 vuart is enabled then increment the nr_spis to allow allocation
@@ -85,20 +104,12 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
libxl_device_disk *disk = _config->disks[i];
if (disk->specification == LIBXL_DISK_SPECIFICATION_VIRTIO) {
-disk->base = alloc_virtio_mmio_base(gc, _mmio_base);
-if (!disk->base)
-return ERROR_FAIL;
-
-disk->irq = alloc_virtio_mmio_irq(gc, _mmio_irq);
-if (!disk->irq)
-return ERROR_FAIL;
-
-if (virtio_irq < disk->irq)
-virtio_irq = disk->irq;
-virtio_enabled = true;
+rc = alloc_virtio_mmio_params(gc, >base, >irq,
+ _mmio_base,
+ _mmio_irq);
-LOG(DEBUG, "Allocate Virtio MMIO params for Vdev %s: IRQ %u BASE
0x%"PRIx64,
-disk->vdev, disk->irq, disk->base);
+if (rc)
+return rc;
}
}
@@ -107,8 +118,16 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
* present, make sure that we allocate enough SPIs for them.
* The resulting "nr_spis" needs to cover the highest possible SPI.
*/
-if (virtio_enabled)
+if (virtio_mmio_irq != GUEST_VIRTIO_MMIO_SPI_FIRST) {
+virtio_enabled = true;
+
+/*
+ * Assumes that "virtio_mmio_irq" is the highest allocated irq, which
is
+ * updated from alloc_virtio_mmio_irq() currently.
+ */
+virtio_irq = virtio_mmio_irq - 1;
nr_spis = max(nr_spis, virtio_irq - 32 + 1);
+}
for (i = 0; i < d_config->b_info.num_irqs; i++) {
uint32_t irq = d_config->b_info.irqs[i];
--
2.31.1.272.g89b43f80a514
