[qemu-mainline test] 172307: regressions - FAIL
flight 172307 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/172307/ 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 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-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-amd64-xl-qemuu-win7-amd64 19 guest-stopfail 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-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-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 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-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 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-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-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-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 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 15 migrate-support-checkfail never pass test-armhf-armhf-xl 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: qemuu0b86b4e0dabbef15ba8d50e13bfecc582df70653 baseline version: qemuu2480f3bbd03814b0651a1f74959f5c6631ee5819 Last test of basis 172123 2022-08-03 18:10:07 Z5 days Failing since172148 2022-08-04 21:39:38 Z4 days 12 attempts Testing same since 172307 2022-08-08 19:40:02 Z0 days1 attempts
[ovmf test] 172316: regressions - FAIL
flight 172316 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/172316/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136 build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136 version targeted for testing: ovmf 1da2012d938f141821740324e2dceee1b4cfa76d baseline version: ovmf 444260d45ec2a84e8f8c192b3539a3cd5591d009 Last test of basis 172136 2022-08-04 06:43:42 Z4 days Failing since172151 2022-08-05 02:40:28 Z4 days 40 attempts Testing same since 172311 2022-08-08 23:40:26 Z0 days3 attempts People who touched revisions under test: Czajkowski, Maciej Edward Pickup Jose Marinho Konstantin Aladyshev Maciej Czajkowski Sami Mujawar 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. commit 1da2012d938f141821740324e2dceee1b4cfa76d Author: Jose Marinho Date: Tue Jul 26 17:54:42 2022 +0100 PrmPkg: Add details on AArch64 build to the Readme. Specify how to build the PrmPkg for the AArch64 architecture. Make the 2 following notes: - the PrmPkg has only been tested on AArch64 using the GCC5 toolchain. - All symbols to be listed in the PRMT as well as the PrmModuleExportDescriptor must be explicitly preserved by resorting to the --require-defined linker flag. Signed-off-by: Jose Marinho Signed-off-by: Sami Mujawar Reviewed-by: Michael Kubacki Reviewed-by: Ard Biesheuvel commit 57faeb782a505935363936ab2edce282d3afc4d5 Author: Jose Marinho Date: Fri Dec 18 14:01:55 2020 + PrmPkg: Support AArch64 builds using GCC Add support to build PrmPkg for AArch64 using the GCC compiler. Add AARCH64 architecture to the list of supported architectures. Add BaseStackCheck library to allow for Prm module builds on AARCH64. Also update the CI to add dependency on ArmPkg. Signed-off-by: Jose Marinho Signed-off-by: Sami Mujawar Reviewed-by: Michael Kubacki Reviewed-by: Ard Biesheuvel commit 21200d9fe6d5b8078b93dbddfbcdf536308b67e4 Author: Jose Marinho Date: Tue Apr 5 18:57:23 2022 +0100 PrmPkg: Build Prm Samples with GCC for AARCH64 - Add the --prm flag to the GENFW_FLAGS - Add the --no-gc-section to the linker flags so that apparently unreferenced symbols are not prematurely removed from the .dll which is used to generate the Prm module .efi. - Force the linker to maintain the PrmModuleExportDescriptor symbol. - Force the linker to maintain the PRM handler funtion's symbol. Signed-off-by: Jose Marinho Signed-off-by: Sami Mujawar Reviewed-by: Michael Kubacki Reviewed-by: Ard Biesheuvel commit 9f197e44b102a8d7d457d2cb4f54967681c858a9 Author: Jose Marinho Date: Tue Apr 5 18:53:25 2022 +0100 PrmPkg: Enable external visibility on PRM symbols Enable GCC compilations to keep external symbols when generating a PRM module. Signed-off-by: Jose Marinho Signed-off-by: Sami Mujawar Reviewed-by: Michael Kubacki Reviewed-by: Ard Biesheuvel commit 1ee162281710650d444c554f9fdbbd404abd9677 Author: Jose Marinho Date: Fri Oct 29 17:48:26 2021 +0100 Basetools/GenFw: Allow AARCH64 builds to use the --prm flag The GenFw invocation with the --prm flag was previously reserved for X64. AArch64 platforms, built with GCC5, can also deploy PRM modules, hence the --prm flag is also
Re: [PATCH V3 3/6] libxl: arm: Create alloc_virtio_mmio_params()
On 09-08-22, 09:59, Viresh Kumar wrote: > There is only one use of virtio_enabled after this patch, i.e. do > check for vpl011. Maybe we can drop the variable and use > virtio_mmio_irq != GUEST_VIRTIO_MMIO_SPI_FIRST ? Nevermind, after modifying code I decided to keep the variable instead. -- viresh
[PATCH V4 0/6] Virtio toolstack support for I2C and GPIO on Arm
Hello,
This patchset adds toolstack support for I2C and GPIO virtio devices. This is
inspired from the work done by Oleksandr for the Disk device.
This is developed as part of Linaro's Project Stratos, where we are working
towards Hypervisor agnostic Rust based backend [1].
This is based of origin/staging (commit 01ca29f0b17a ("sched: dom0_vcpus_pin
should only affect dom0")) which already has Oleksandr's patches applied.
V3->V4:
- Update virtio_enabled independently of all devices, so we don't miss setting
it to true.
- Add iommu handling for i2c/gpio and move it as part of
make_virtio_mmio_node_common(), which gets backend_domid parameter as a
result.
V2->V3:
- Rebased over latest tree and made changes according to changes in Oleksandr's
patches from sometime back.
- Minor cleanups.
V1->V2:
- Patches 3/6 and 4/6 are new.
- Patches 5/6 and 6/6 updated based on the above two patches.
- Added link to the bindings for I2C and GPIO.
- Rebased over latest master branch.
Thanks.
--
Viresh
[1]
https://lore.kernel.org/xen-devel/20220414092358.kepxbmnrtycz7mhe@vireshk-i7/
Viresh Kumar (6):
libxl: Add support for Virtio I2C device
libxl: Add support for Virtio GPIO device
libxl: arm: Create alloc_virtio_mmio_params()
libxl: arm: Split make_virtio_mmio_node()
libxl: Allocate MMIO params for I2c device and update DT
libxl: Allocate MMIO params for GPIO device and update DT
tools/golang/xenlight/helpers.gen.go | 212
tools/golang/xenlight/types.gen.go| 54 ++
tools/include/libxl.h | 64 ++
tools/include/libxl_utils.h | 6 +
tools/libs/light/Makefile | 2 +
tools/libs/light/libxl_arm.c | 166 +---
tools/libs/light/libxl_create.c | 26 +++
tools/libs/light/libxl_dm.c | 34 +++-
tools/libs/light/libxl_gpio.c | 226 ++
tools/libs/light/libxl_i2c.c | 226 ++
tools/libs/light/libxl_internal.h | 2 +
tools/libs/light/libxl_types.idl | 48 +
tools/libs/light/libxl_types_internal.idl | 2 +
tools/ocaml/libs/xl/genwrap.py| 2 +
tools/ocaml/libs/xl/xenlight_stubs.c | 2 +
tools/xl/Makefile | 2 +-
tools/xl/xl.h | 6 +
tools/xl/xl_cmdtable.c| 30 +++
tools/xl/xl_gpio.c| 142 ++
tools/xl/xl_i2c.c | 142 ++
tools/xl/xl_parse.c | 160 +++
tools/xl/xl_parse.h | 2 +
tools/xl/xl_sxp.c | 4 +
23 files changed, 1530 insertions(+), 30 deletions(-)
create mode 100644 tools/libs/light/libxl_gpio.c
create mode 100644 tools/libs/light/libxl_i2c.c
create mode 100644 tools/xl/xl_gpio.c
create mode 100644 tools/xl/xl_i2c.c
--
2.31.1.272.g89b43f80a514
[PATCH V4 6/6] libxl: Allocate MMIO params for GPIO device and update DT
This patch allocates Virtio MMIO params (IRQ and memory region) and pass
them to the backend, also update Guest device-tree based on Virtio GPIO
DT bindings [1].
[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio-virtio.yaml
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 51
1 file changed, 51 insertions(+)
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 93ea8e3d3fa3..c0ffb7f179d4 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -119,6 +119,15 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
return rc;
}
+for (i = 0; i < d_config->num_gpios; i++) {
+libxl_device_gpio *gpio = _config->gpios[i];
+
+int rc = alloc_virtio_mmio_params(gc, >base, >irq,
+_mmio_base, _mmio_irq);
+if (rc)
+return rc;
+}
+
/*
* Every virtio-mmio device uses one emulated SPI. If Virtio devices are
* present, make sure that we allocate enough SPIs for them.
@@ -976,6 +985,38 @@ static int make_virtio_mmio_node_i2c(libxl__gc *gc, void
*fdt, uint64_t base,
return fdt_end_node(fdt);
}
+static int make_virtio_mmio_node_gpio(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;
+
+res = fdt_begin_node(fdt, "gpio");
+if (res) return res;
+
+res = fdt_property_compat(gc, fdt, 1, "virtio,device29");
+if (res) return res;
+
+res = fdt_property(fdt, "gpio-controller", NULL, 0);
+if (res) return res;
+
+res = fdt_property_cell(fdt, "#gpio-cells", 2);
+if (res) return res;
+
+res = fdt_property(fdt, "interrupt-controller", NULL, 0);
+if (res) return res;
+
+res = fdt_property_cell(fdt, "#interrupt-cells", 2);
+if (res) return res;
+
+res = fdt_end_node(fdt);
+if (res) return res;
+
+return fdt_end_node(fdt);
+}
+
static const struct arch_info *get_arch_info(libxl__gc *gc,
const struct xc_dom_image *dom)
{
@@ -1308,6 +1349,16 @@ static int libxl__prepare_dtb(libxl__gc *gc,
libxl_domain_config *d_config,
i2c->backend_domid) );
}
+for (i = 0; i < d_config->num_gpios; i++) {
+libxl_device_gpio *gpio = _config->gpios[i];
+
+if (gpio->backend_domid != LIBXL_TOOLSTACK_DOMID)
+iommu_needed = true;
+
+FDT( make_virtio_mmio_node_gpio(gc, fdt, gpio->base, gpio->irq,
+gpio->backend_domid) );
+}
+
/*
* Note, this should be only called after creating all virtio-mmio
* device nodes
--
2.31.1.272.g89b43f80a514
[PATCH V4 5/6] libxl: Allocate MMIO params for I2c device and update DT
This patch allocates Virtio MMIO params (IRQ and memory region) and pass
them to the backend, also update Guest device-tree based on Virtio I2C
DT bindings [1].
[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/i2c/i2c-virtio.yaml
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 57 +++-
1 file changed, 50 insertions(+), 7 deletions(-)
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 891cb6ef2674..93ea8e3d3fa3 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -110,6 +110,15 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
}
}
+for (i = 0; i < d_config->num_i2cs; i++) {
+libxl_device_i2c *i2c = _config->i2cs[i];
+
+int rc = alloc_virtio_mmio_params(gc, >base, >irq,
+_mmio_base, _mmio_irq);
+if (rc)
+return rc;
+}
+
/*
* Every virtio-mmio device uses one emulated SPI. If Virtio devices are
* present, make sure that we allocate enough SPIs for them.
@@ -947,6 +956,26 @@ static int make_virtio_mmio_node_simple(libxl__gc *gc,
void *fdt, uint64_t base,
return fdt_end_node(fdt);
}
+static int make_virtio_mmio_node_i2c(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;
+
+res = fdt_begin_node(fdt, "i2c");
+if (res) return res;
+
+res = fdt_property_compat(gc, fdt, 1, "virtio,device22");
+if (res) return res;
+
+res = fdt_end_node(fdt);
+if (res) return res;
+
+return fdt_end_node(fdt);
+}
+
static const struct arch_info *get_arch_info(libxl__gc *gc,
const struct xc_dom_image *dom)
{
@@ -1148,7 +1177,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;
@@ -1256,22 +1285,36 @@ 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_simple(gc, fdt, disk->base,
disk->irq, disk->backend_domid) );
}
}
+for (i = 0; i < d_config->num_i2cs; i++) {
+libxl_device_i2c *i2c = _config->i2cs[i];
+
+if (i2c->backend_domid != LIBXL_TOOLSTACK_DOMID)
+iommu_needed = true;
+
+FDT( make_virtio_mmio_node_i2c(gc, fdt, i2c->base, i2c->irq,
+ i2c->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 V4 4/6] 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.
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 4a750852b671..891cb6ef2674 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -899,9 +899,8 @@ 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)
+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;
@@ -934,10 +933,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_simple(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,
@@ -1260,8 +1267,8 @@ static int libxl__prepare_dtb(libxl__gc *gc,
libxl_domain_config *d_config,
iommu_created = true;
}
-FDT( make_virtio_mmio_node(gc, fdt, disk->base, disk->irq,
- disk->backend_domid) );
+FDT( make_virtio_mmio_node_simple(gc, fdt, disk->base,
+disk->irq, disk->backend_domid) );
}
}
--
2.31.1.272.g89b43f80a514
[PATCH V4 3/6] libxl: arm: Create alloc_virtio_mmio_params()
Create a separate routine to allocate base and irq for a device as the
same code will be required for each device type.
Suggested-by: Oleksandr Tyshchenko
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 41 +++-
1 file changed, 26 insertions(+), 15 deletions(-)
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 1a3ac1646e94..4a750852b671 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) {
@@ -85,20 +103,10 @@ 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;
-
-LOG(DEBUG, "Allocate Virtio MMIO params for Vdev %s: IRQ %u BASE
0x%"PRIx64,
-disk->vdev, disk->irq, disk->base);
+int rc = alloc_virtio_mmio_params(gc, >base, >irq,
+_mmio_base, _mmio_irq);
+if (rc)
+return rc;
}
}
@@ -107,8 +115,11 @@ 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;
+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
[PATCH V4 2/6] libxl: Add support for Virtio GPIO device
This patch adds basic support for configuring and assisting virtio-mmio
based virtio-gpio backend (emualator) which is intended to run out of
Qemu and could be run in any domain.
An example of domain configuration for Virtio Gpio:
gpio = [ "" ]
Please note, this patch is not enough for virtio-gpio to work on Xen
(Arm), as for every Virtio device we need to allocate Virtio MMIO params
(IRQ and memory region) and pass them to the backend, also update Guest
device-tree. A subsequent patch will add these missing bits. For the
current patch, the default "irq" and "base" are just written to the
Xenstore.
Signed-off-by: Viresh Kumar
---
tools/golang/xenlight/helpers.gen.go | 108 ++-
tools/golang/xenlight/types.gen.go| 27 +++
tools/include/libxl.h | 32 +++
tools/include/libxl_utils.h | 3 +
tools/libs/light/Makefile | 1 +
tools/libs/light/libxl_create.c | 13 ++
tools/libs/light/libxl_dm.c | 17 +-
tools/libs/light/libxl_gpio.c | 226 ++
tools/libs/light/libxl_internal.h | 1 +
tools/libs/light/libxl_types.idl | 24 +++
tools/libs/light/libxl_types_internal.idl | 1 +
tools/ocaml/libs/xl/genwrap.py| 1 +
tools/ocaml/libs/xl/xenlight_stubs.c | 1 +
tools/xl/Makefile | 2 +-
tools/xl/xl.h | 3 +
tools/xl/xl_cmdtable.c| 15 ++
tools/xl/xl_gpio.c| 142 ++
tools/xl/xl_parse.c | 80
tools/xl/xl_parse.h | 1 +
tools/xl/xl_sxp.c | 2 +
20 files changed, 696 insertions(+), 4 deletions(-)
create mode 100644 tools/libs/light/libxl_gpio.c
create mode 100644 tools/xl/xl_gpio.c
diff --git a/tools/golang/xenlight/helpers.gen.go
b/tools/golang/xenlight/helpers.gen.go
index 4c7b60439bf0..2f41ace71c61 100644
--- a/tools/golang/xenlight/helpers.gen.go
+++ b/tools/golang/xenlight/helpers.gen.go
@@ -1221,6 +1221,9 @@ x.Usbdevice = C.GoString(tmp.usbdevice)
if err := x.VkbDevice.fromC(_device);err != nil {
return fmt.Errorf("converting field VkbDevice: %v", err)
}
+if err := x.GpioDevice.fromC(_device);err != nil {
+return fmt.Errorf("converting field GpioDevice: %v", err)
+}
if err := x.I2cDevice.fromC(_device);err != nil {
return fmt.Errorf("converting field I2cDevice: %v", err)
}
@@ -1541,6 +1544,9 @@ hvm.usbdevice = C.CString(tmp.Usbdevice)}
if err := tmp.VkbDevice.toC(_device); err != nil {
return fmt.Errorf("converting field VkbDevice: %v", err)
}
+if err := tmp.GpioDevice.toC(_device); err != nil {
+return fmt.Errorf("converting field GpioDevice: %v", err)
+}
if err := tmp.I2cDevice.toC(_device); err != nil {
return fmt.Errorf("converting field I2cDevice: %v", err)
}
@@ -1740,6 +1746,46 @@ xc.multi_touch_num_contacts =
C.uint32_t(x.MultiTouchNumContacts)
return nil
}
+// NewDeviceGpio returns an instance of DeviceGpio initialized with defaults.
+func NewDeviceGpio() (*DeviceGpio, error) {
+var (
+x DeviceGpio
+xc C.libxl_device_gpio)
+
+C.libxl_device_gpio_init()
+defer C.libxl_device_gpio_dispose()
+
+if err := x.fromC(); err != nil {
+return nil, err }
+
+return , nil}
+
+func (x *DeviceGpio) fromC(xc *C.libxl_device_gpio) error {
+ x.BackendDomid = Domid(xc.backend_domid)
+x.BackendDomname = C.GoString(xc.backend_domname)
+x.Devid = Devid(xc.devid)
+x.BackendType = GpioBackend(xc.backend_type)
+x.Irq = uint32(xc.irq)
+x.Base = uint64(xc.base)
+
+ return nil}
+
+func (x *DeviceGpio) toC(xc *C.libxl_device_gpio) (err error){defer func(){
+if err != nil{
+C.libxl_device_gpio_dispose(xc)}
+}()
+
+xc.backend_domid = C.libxl_domid(x.BackendDomid)
+if x.BackendDomname != "" {
+xc.backend_domname = C.CString(x.BackendDomname)}
+xc.devid = C.libxl_devid(x.Devid)
+xc.backend_type = C.libxl_gpio_backend(x.BackendType)
+xc.irq = C.uint32_t(x.Irq)
+xc.base = C.uint64_t(x.Base)
+
+ return nil
+ }
+
// NewDeviceI2c returns an instance of DeviceI2c initialized with defaults.
func NewDeviceI2c() (*DeviceI2c, error) {
var (
@@ -2913,6 +2959,15 @@ if err := x.Vkbs[i].fromC(); err != nil {
return fmt.Errorf("converting field Vkbs: %v", err) }
}
}
+x.Gpios = nil
+if n := int(xc.num_gpios); n > 0 {
+cGpios := (*[1<<28]C.libxl_device_gpio)(unsafe.Pointer(xc.gpios))[:n:n]
+x.Gpios = make([]DeviceGpio, n)
+for i, v := range cGpios {
+if err := x.Gpios[i].fromC(); err != nil {
+return fmt.Errorf("converting field Gpios: %v", err) }
+}
+}
x.I2cs = nil
if n := int(xc.num_i2cs); n > 0 {
cI2cs := (*[1<<28]C.libxl_device_i2c)(unsafe.Pointer(xc.i2cs))[:n:n]
@@ -3083,6 +3138,16 @@ return fmt.Errorf("converting field Vkbs: %v", err)
}
}
}
+if numGpios := len(x.Gpios); numGpios > 0 {
+xc.gpios =
(*C.libxl_device_gpio)(C.malloc(C.ulong(numGpios)*C.sizeof_libxl_device_gpio))
+xc.num_gpios = C.int(numGpios)
+cGpios :=
[PATCH V4 1/6] libxl: Add support for Virtio I2C device
This patch adds basic support for configuring and assisting virtio-mmio
based virtio-i2c backend (emualator) which is intended to run out of
Qemu and could be run in any domain.
An example of domain configuration for Virtio I2c:
i2c = [ "" ]
Please note, this patch is not enough for virtio-i2c to work on Xen
(Arm), as for every Virtio device we need to allocate Virtio MMIO params
(IRQ and memory region) and pass them to the backend, also update Guest
device-tree. A subsequent patch will add these missing bits. For the
current patch, the default "irq" and "base" are just written to the
Xenstore.
Signed-off-by: Viresh Kumar
---
tools/golang/xenlight/helpers.gen.go | 108 +++
tools/golang/xenlight/types.gen.go| 27 +++
tools/include/libxl.h | 32 +++
tools/include/libxl_utils.h | 3 +
tools/libs/light/Makefile | 1 +
tools/libs/light/libxl_create.c | 13 ++
tools/libs/light/libxl_dm.c | 19 +-
tools/libs/light/libxl_i2c.c | 226 ++
tools/libs/light/libxl_internal.h | 1 +
tools/libs/light/libxl_types.idl | 24 +++
tools/libs/light/libxl_types_internal.idl | 1 +
tools/ocaml/libs/xl/genwrap.py| 1 +
tools/ocaml/libs/xl/xenlight_stubs.c | 1 +
tools/xl/Makefile | 2 +-
tools/xl/xl.h | 3 +
tools/xl/xl_cmdtable.c| 15 ++
tools/xl/xl_i2c.c | 142 ++
tools/xl/xl_parse.c | 80
tools/xl/xl_parse.h | 1 +
tools/xl/xl_sxp.c | 2 +
20 files changed, 699 insertions(+), 3 deletions(-)
create mode 100644 tools/libs/light/libxl_i2c.c
create mode 100644 tools/xl/xl_i2c.c
diff --git a/tools/golang/xenlight/helpers.gen.go
b/tools/golang/xenlight/helpers.gen.go
index fa3cf2ab7658..4c7b60439bf0 100644
--- a/tools/golang/xenlight/helpers.gen.go
+++ b/tools/golang/xenlight/helpers.gen.go
@@ -1221,6 +1221,9 @@ x.Usbdevice = C.GoString(tmp.usbdevice)
if err := x.VkbDevice.fromC(_device);err != nil {
return fmt.Errorf("converting field VkbDevice: %v", err)
}
+if err := x.I2cDevice.fromC(_device);err != nil {
+return fmt.Errorf("converting field I2cDevice: %v", err)
+}
x.Soundhw = C.GoString(tmp.soundhw)
if err := x.XenPlatformPci.fromC(_platform_pci);err != nil {
return fmt.Errorf("converting field XenPlatformPci: %v", err)
@@ -1538,6 +1541,9 @@ hvm.usbdevice = C.CString(tmp.Usbdevice)}
if err := tmp.VkbDevice.toC(_device); err != nil {
return fmt.Errorf("converting field VkbDevice: %v", err)
}
+if err := tmp.I2cDevice.toC(_device); err != nil {
+return fmt.Errorf("converting field I2cDevice: %v", err)
+}
if tmp.Soundhw != "" {
hvm.soundhw = C.CString(tmp.Soundhw)}
if err := tmp.XenPlatformPci.toC(_platform_pci); err != nil {
@@ -1734,6 +1740,46 @@ xc.multi_touch_num_contacts =
C.uint32_t(x.MultiTouchNumContacts)
return nil
}
+// NewDeviceI2c returns an instance of DeviceI2c initialized with defaults.
+func NewDeviceI2c() (*DeviceI2c, error) {
+var (
+x DeviceI2c
+xc C.libxl_device_i2c)
+
+C.libxl_device_i2c_init()
+defer C.libxl_device_i2c_dispose()
+
+if err := x.fromC(); err != nil {
+return nil, err }
+
+return , nil}
+
+func (x *DeviceI2c) fromC(xc *C.libxl_device_i2c) error {
+ x.BackendDomid = Domid(xc.backend_domid)
+x.BackendDomname = C.GoString(xc.backend_domname)
+x.Devid = Devid(xc.devid)
+x.BackendType = I2cBackend(xc.backend_type)
+x.Irq = uint32(xc.irq)
+x.Base = uint64(xc.base)
+
+ return nil}
+
+func (x *DeviceI2c) toC(xc *C.libxl_device_i2c) (err error){defer func(){
+if err != nil{
+C.libxl_device_i2c_dispose(xc)}
+}()
+
+xc.backend_domid = C.libxl_domid(x.BackendDomid)
+if x.BackendDomname != "" {
+xc.backend_domname = C.CString(x.BackendDomname)}
+xc.devid = C.libxl_devid(x.Devid)
+xc.backend_type = C.libxl_i2c_backend(x.BackendType)
+xc.irq = C.uint32_t(x.Irq)
+xc.base = C.uint64_t(x.Base)
+
+ return nil
+ }
+
// NewDeviceDisk returns an instance of DeviceDisk initialized with defaults.
func NewDeviceDisk() (*DeviceDisk, error) {
var (
@@ -2867,6 +2913,15 @@ if err := x.Vkbs[i].fromC(); err != nil {
return fmt.Errorf("converting field Vkbs: %v", err) }
}
}
+x.I2cs = nil
+if n := int(xc.num_i2cs); n > 0 {
+cI2cs := (*[1<<28]C.libxl_device_i2c)(unsafe.Pointer(xc.i2cs))[:n:n]
+x.I2cs = make([]DeviceI2c, n)
+for i, v := range cI2cs {
+if err := x.I2cs[i].fromC(); err != nil {
+return fmt.Errorf("converting field I2cs: %v", err) }
+}
+}
x.Vtpms = nil
if n := int(xc.num_vtpms); n > 0 {
cVtpms := (*[1<<28]C.libxl_device_vtpm)(unsafe.Pointer(xc.vtpms))[:n:n]
@@ -3028,6 +3083,16 @@ return fmt.Errorf("converting field Vkbs: %v", err)
}
}
}
+if numI2cs := len(x.I2cs); numI2cs > 0 {
+xc.i2cs =
(*C.libxl_device_i2c)(C.malloc(C.ulong(numI2cs)*C.sizeof_libxl_device_i2c))
+xc.num_i2cs = C.int(numI2cs)
+cI2cs :=
Re: [PATCH V3 3/6] libxl: arm: Create alloc_virtio_mmio_params()
On 08-08-22, 21:39, Oleksandr wrote:
>
> On 04.08.22 10:01, Viresh Kumar wrote:
>
> Hello Viresh
>
>
> > Create a separate routine to allocate base and irq for a device as the
> > same code will be required for each device type.
> >
> > Suggested-by: Oleksandr Tyshchenko
> > Signed-off-by: Viresh Kumar
> > ---
> > tools/libs/light/libxl_arm.c | 38
> > 1 file changed, 25 insertions(+), 13 deletions(-)
> >
> > diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
> > index 1a3ac1646e94..2f64b9f0ebee 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) {
> > @@ -85,20 +103,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;
> > +int rc = alloc_virtio_mmio_params(gc, >base, >irq,
> > +_mmio_base, _mmio_irq);
> > +if (rc)
> > +return rc;
> > -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;
>
> I think that "virtio_enabled = true;" should be moved ...
>
>
> > -
> > -LOG(DEBUG, "Allocate Virtio MMIO params for Vdev %s: IRQ %u
> > BASE 0x%"PRIx64,
> > -disk->vdev, disk->irq, disk->base);
> > }
> > }
> > @@ -107,8 +117,10 @@ 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_irq = virtio_mmio_irq - 1;
> > nr_spis = max(nr_spis, virtio_irq - 32 + 1);
>
> ... here. Otherwise after applying all patches "virtio_enabled" only gets
> set if there is a virtio disk device. So it won't be set for virtio i2c,
> etc.
>
> I see that in V2 it was there, but in V3 is not. Or maybe there is some
> reason for doing that which I am not aware of?
There is only one use of virtio_enabled after this patch, i.e. do
check for vpl011. Maybe we can drop the variable and use
virtio_mmio_irq != GUEST_VIRTIO_MMIO_SPI_FIRST ?
--
viresh
[ovmf test] 172314: regressions - FAIL
flight 172314 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/172314/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136 build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136 version targeted for testing: ovmf 1da2012d938f141821740324e2dceee1b4cfa76d baseline version: ovmf 444260d45ec2a84e8f8c192b3539a3cd5591d009 Last test of basis 172136 2022-08-04 06:43:42 Z4 days Failing since172151 2022-08-05 02:40:28 Z4 days 39 attempts Testing same since 172311 2022-08-08 23:40:26 Z0 days2 attempts People who touched revisions under test: Czajkowski, Maciej Edward Pickup Jose Marinho Konstantin Aladyshev Maciej Czajkowski Sami Mujawar 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. commit 1da2012d938f141821740324e2dceee1b4cfa76d Author: Jose Marinho Date: Tue Jul 26 17:54:42 2022 +0100 PrmPkg: Add details on AArch64 build to the Readme. Specify how to build the PrmPkg for the AArch64 architecture. Make the 2 following notes: - the PrmPkg has only been tested on AArch64 using the GCC5 toolchain. - All symbols to be listed in the PRMT as well as the PrmModuleExportDescriptor must be explicitly preserved by resorting to the --require-defined linker flag. Signed-off-by: Jose Marinho Signed-off-by: Sami Mujawar Reviewed-by: Michael Kubacki Reviewed-by: Ard Biesheuvel commit 57faeb782a505935363936ab2edce282d3afc4d5 Author: Jose Marinho Date: Fri Dec 18 14:01:55 2020 + PrmPkg: Support AArch64 builds using GCC Add support to build PrmPkg for AArch64 using the GCC compiler. Add AARCH64 architecture to the list of supported architectures. Add BaseStackCheck library to allow for Prm module builds on AARCH64. Also update the CI to add dependency on ArmPkg. Signed-off-by: Jose Marinho Signed-off-by: Sami Mujawar Reviewed-by: Michael Kubacki Reviewed-by: Ard Biesheuvel commit 21200d9fe6d5b8078b93dbddfbcdf536308b67e4 Author: Jose Marinho Date: Tue Apr 5 18:57:23 2022 +0100 PrmPkg: Build Prm Samples with GCC for AARCH64 - Add the --prm flag to the GENFW_FLAGS - Add the --no-gc-section to the linker flags so that apparently unreferenced symbols are not prematurely removed from the .dll which is used to generate the Prm module .efi. - Force the linker to maintain the PrmModuleExportDescriptor symbol. - Force the linker to maintain the PRM handler funtion's symbol. Signed-off-by: Jose Marinho Signed-off-by: Sami Mujawar Reviewed-by: Michael Kubacki Reviewed-by: Ard Biesheuvel commit 9f197e44b102a8d7d457d2cb4f54967681c858a9 Author: Jose Marinho Date: Tue Apr 5 18:53:25 2022 +0100 PrmPkg: Enable external visibility on PRM symbols Enable GCC compilations to keep external symbols when generating a PRM module. Signed-off-by: Jose Marinho Signed-off-by: Sami Mujawar Reviewed-by: Michael Kubacki Reviewed-by: Ard Biesheuvel commit 1ee162281710650d444c554f9fdbbd404abd9677 Author: Jose Marinho Date: Fri Oct 29 17:48:26 2021 +0100 Basetools/GenFw: Allow AARCH64 builds to use the --prm flag The GenFw invocation with the --prm flag was previously reserved for X64. AArch64 platforms, built with GCC5, can also deploy PRM modules, hence the --prm flag is also
[xen-unstable-smoke test] 172310: tolerable FAIL - PUSHED
flight 172310 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/172310/ 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 172199 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 89805b35ce6a0cf402563ebe2f09b03f27152474 baseline version: xen 6d6aee437e37fced0c49be97e08c30da873690fc Last test of basis 172199 2022-08-05 18:03:04 Z3 days Testing same since 172310 2022-08-08 23:01:46 Z0 days1 attempts People who touched revisions under test: Xenia Ragiadakou 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 6d6aee437e..89805b35ce 89805b35ce6a0cf402563ebe2f09b03f27152474 -> smoke
[ovmf test] 172311: regressions - FAIL
flight 172311 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/172311/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136 build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136 version targeted for testing: ovmf 1da2012d938f141821740324e2dceee1b4cfa76d baseline version: ovmf 444260d45ec2a84e8f8c192b3539a3cd5591d009 Last test of basis 172136 2022-08-04 06:43:42 Z4 days Failing since172151 2022-08-05 02:40:28 Z3 days 38 attempts Testing same since 172311 2022-08-08 23:40:26 Z0 days1 attempts People who touched revisions under test: Czajkowski, Maciej Edward Pickup Jose Marinho Konstantin Aladyshev Maciej Czajkowski Sami Mujawar 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. commit 1da2012d938f141821740324e2dceee1b4cfa76d Author: Jose Marinho Date: Tue Jul 26 17:54:42 2022 +0100 PrmPkg: Add details on AArch64 build to the Readme. Specify how to build the PrmPkg for the AArch64 architecture. Make the 2 following notes: - the PrmPkg has only been tested on AArch64 using the GCC5 toolchain. - All symbols to be listed in the PRMT as well as the PrmModuleExportDescriptor must be explicitly preserved by resorting to the --require-defined linker flag. Signed-off-by: Jose Marinho Signed-off-by: Sami Mujawar Reviewed-by: Michael Kubacki Reviewed-by: Ard Biesheuvel commit 57faeb782a505935363936ab2edce282d3afc4d5 Author: Jose Marinho Date: Fri Dec 18 14:01:55 2020 + PrmPkg: Support AArch64 builds using GCC Add support to build PrmPkg for AArch64 using the GCC compiler. Add AARCH64 architecture to the list of supported architectures. Add BaseStackCheck library to allow for Prm module builds on AARCH64. Also update the CI to add dependency on ArmPkg. Signed-off-by: Jose Marinho Signed-off-by: Sami Mujawar Reviewed-by: Michael Kubacki Reviewed-by: Ard Biesheuvel commit 21200d9fe6d5b8078b93dbddfbcdf536308b67e4 Author: Jose Marinho Date: Tue Apr 5 18:57:23 2022 +0100 PrmPkg: Build Prm Samples with GCC for AARCH64 - Add the --prm flag to the GENFW_FLAGS - Add the --no-gc-section to the linker flags so that apparently unreferenced symbols are not prematurely removed from the .dll which is used to generate the Prm module .efi. - Force the linker to maintain the PrmModuleExportDescriptor symbol. - Force the linker to maintain the PRM handler funtion's symbol. Signed-off-by: Jose Marinho Signed-off-by: Sami Mujawar Reviewed-by: Michael Kubacki Reviewed-by: Ard Biesheuvel commit 9f197e44b102a8d7d457d2cb4f54967681c858a9 Author: Jose Marinho Date: Tue Apr 5 18:53:25 2022 +0100 PrmPkg: Enable external visibility on PRM symbols Enable GCC compilations to keep external symbols when generating a PRM module. Signed-off-by: Jose Marinho Signed-off-by: Sami Mujawar Reviewed-by: Michael Kubacki Reviewed-by: Ard Biesheuvel commit 1ee162281710650d444c554f9fdbbd404abd9677 Author: Jose Marinho Date: Fri Oct 29 17:48:26 2021 +0100 Basetools/GenFw: Allow AARCH64 builds to use the --prm flag The GenFw invocation with the --prm flag was previously reserved for X64. AArch64 platforms, built with GCC5, can also deploy PRM modules, hence the --prm flag is also
[linux-linus test] 172305: regressions - FAIL
flight 172305 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/172305/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172133 build-i386-libvirt6 libvirt-buildfail REGR. vs. 172133 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 172133 test-arm64-arm64-xl-vhd 17 guest-start/debian.repeat fail REGR. vs. 172133 build-armhf-libvirt 6 libvirt-buildfail 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-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-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 172133 test-amd64-amd64-xl-qemuu-ws16-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-win7-amd64 19 guest-stopfail like 172133 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 172133 test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 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-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 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 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 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-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-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 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-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-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 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: linux3466f49dd0dd9d30fe1e916b49fca1f4f99a3b66 baseline version: linuxb44f2fd87919b5ae6e1756d4c7ba2cbba22238e1 Last test of basis 172133 2022-08-04 05:14:48 Z4 days Failing since172152 2022-08-05 04:01:26 Z3 days 12 attempts Testing same since 172305 2022-08-08 18:41:36 Z0 days1 attempts 1083 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm
[ovmf test] 172309: regressions - FAIL
flight 172309 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/172309/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136 build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136 version targeted for testing: ovmf cf02322c984a16fc2af252124df96564e574f3a7 baseline version: ovmf 444260d45ec2a84e8f8c192b3539a3cd5591d009 Last test of basis 172136 2022-08-04 06:43:42 Z4 days Failing since172151 2022-08-05 02:40:28 Z3 days 37 attempts Testing same since 172247 2022-08-06 15:41:48 Z2 days 23 attempts People who touched revisions under test: Czajkowski, Maciej Edward Pickup Konstantin Aladyshev Maciej Czajkowski 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. commit cf02322c984a16fc2af252124df96564e574f3a7 Author: Konstantin Aladyshev Date: Wed Jul 20 22:08:12 2022 +0800 BaseTools/GenSec: Support EFI_SECTION_FREEFORM_SUBTYPE_GUID sections Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit d241a09afbe4f472a5d7da5090dfc85046f2250f Author: Konstantin Aladyshev Date: Wed Jul 20 20:00:39 2022 +0800 BaseTools/VolInfo: Parse EFI_SECTION_FREEFORM_SUBTYPE_GUID header Print 'SubtypeGuid' field from the EFI_FREEFORM_SUBTYPE_GUID_SECTION structure. This value describes the raw data inside the section. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit f5f8c08db92d15c7a359a5eb3b0cc2545c945942 Author: Konstantin Aladyshev Date: Tue Jul 19 23:45:52 2022 +0800 BaseTools/VolInfo: Show FV section boundaries Currently there is no labels for start and end of the EFI_SECTION_FIRMWARE_VOLUME_IMAGE type section. Therefore it is not possible to see where the FV section ends and another section starts. Add labels for start and end of the FV sections to fix the issue. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit a0a03b51548e6fc7524b5aa9f8042cbabce6da1c Author: Konstantin Aladyshev Date: Tue Jul 19 22:27:10 2022 +0800 BaseTools/GenSec: Fix typo Fix typo in the help message. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit 3e599bbc105ff089b21b6024100d585a8c781328 Author: Edward Pickup Date: Thu Aug 4 10:20:50 2022 +0100 DynamicTablesPkg: Fix using RmrNodeCount unitlitialised Fix using RmrNodeCount uninitliased by initliasing it to zero. Also, add an additional check for ACPI version. This fixes a crash running on kvmtool. Signed-off-by: Edward Pickup Reviewed-by: Sami Mujawar commit a8f59e2eb44199040d2e1f747a6d950a25ed0984 Author: Czajkowski, Maciej Date: Tue Aug 2 01:00:09 2022 +0800 MdeModulePkg/AhciPei: Use PCI_DEVICE_PPI to manage AHCI device REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3907 This change modifies AhciPei library to allow usage both EDKII_PCI_DEVICE_PPI and EDKII_PEI_ATA_AHCI_HOST_CONTROLLER_PPI to manage ATA HDD working under AHCI mode. Cc: Hao A Wu Cc: Ray Ni Cc: Liming Gao Signed-off-by: Maciej Czajkowski Reviewed-by: Hao A Wu commit 86757f0b4750f672f346d955f89e5b76430ba6b4 Author: Czajkowski, Maciej Date: Tue Aug 2 01:00:08 2022 +0800 MdeModulePkg: Add EDKII_PCI_DEVICE_PPI definition REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3907 This commit introduces
Re: [PATCH v2 0/2] automation: Test a pv network interface under dom0less enhanced
On Mon, 8 Aug 2022, Xenia Ragiadakou wrote: > Xenia Ragiadakou (2): > automation: qemu-smoke-arm64: Use kernel 5.19 > automation: qemu-smoke-arm64: Run ping test over a pv network > interface > > automation/gitlab-ci/build.yaml | 11 + > automation/gitlab-ci/test.yaml| 10 +++-- > automation/scripts/qemu-smoke-arm64.sh| 44 --- > .../kernel/5.19-arm64v8.dockerfile| 37 > 4 files changed, 93 insertions(+), 9 deletions(-) > create mode 100644 automation/tests-artifacts/kernel/5.19-arm64v8.dockerfile Reviewed-by: Stefano Stabellini
[ovmf test] 172306: regressions - FAIL
flight 172306 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/172306/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136 build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136 version targeted for testing: ovmf cf02322c984a16fc2af252124df96564e574f3a7 baseline version: ovmf 444260d45ec2a84e8f8c192b3539a3cd5591d009 Last test of basis 172136 2022-08-04 06:43:42 Z4 days Failing since172151 2022-08-05 02:40:28 Z3 days 36 attempts Testing same since 172247 2022-08-06 15:41:48 Z2 days 22 attempts People who touched revisions under test: Czajkowski, Maciej Edward Pickup Konstantin Aladyshev Maciej Czajkowski 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. commit cf02322c984a16fc2af252124df96564e574f3a7 Author: Konstantin Aladyshev Date: Wed Jul 20 22:08:12 2022 +0800 BaseTools/GenSec: Support EFI_SECTION_FREEFORM_SUBTYPE_GUID sections Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit d241a09afbe4f472a5d7da5090dfc85046f2250f Author: Konstantin Aladyshev Date: Wed Jul 20 20:00:39 2022 +0800 BaseTools/VolInfo: Parse EFI_SECTION_FREEFORM_SUBTYPE_GUID header Print 'SubtypeGuid' field from the EFI_FREEFORM_SUBTYPE_GUID_SECTION structure. This value describes the raw data inside the section. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit f5f8c08db92d15c7a359a5eb3b0cc2545c945942 Author: Konstantin Aladyshev Date: Tue Jul 19 23:45:52 2022 +0800 BaseTools/VolInfo: Show FV section boundaries Currently there is no labels for start and end of the EFI_SECTION_FIRMWARE_VOLUME_IMAGE type section. Therefore it is not possible to see where the FV section ends and another section starts. Add labels for start and end of the FV sections to fix the issue. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit a0a03b51548e6fc7524b5aa9f8042cbabce6da1c Author: Konstantin Aladyshev Date: Tue Jul 19 22:27:10 2022 +0800 BaseTools/GenSec: Fix typo Fix typo in the help message. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit 3e599bbc105ff089b21b6024100d585a8c781328 Author: Edward Pickup Date: Thu Aug 4 10:20:50 2022 +0100 DynamicTablesPkg: Fix using RmrNodeCount unitlitialised Fix using RmrNodeCount uninitliased by initliasing it to zero. Also, add an additional check for ACPI version. This fixes a crash running on kvmtool. Signed-off-by: Edward Pickup Reviewed-by: Sami Mujawar commit a8f59e2eb44199040d2e1f747a6d950a25ed0984 Author: Czajkowski, Maciej Date: Tue Aug 2 01:00:09 2022 +0800 MdeModulePkg/AhciPei: Use PCI_DEVICE_PPI to manage AHCI device REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3907 This change modifies AhciPei library to allow usage both EDKII_PCI_DEVICE_PPI and EDKII_PEI_ATA_AHCI_HOST_CONTROLLER_PPI to manage ATA HDD working under AHCI mode. Cc: Hao A Wu Cc: Ray Ni Cc: Liming Gao Signed-off-by: Maciej Czajkowski Reviewed-by: Hao A Wu commit 86757f0b4750f672f346d955f89e5b76430ba6b4 Author: Czajkowski, Maciej Date: Tue Aug 2 01:00:08 2022 +0800 MdeModulePkg: Add EDKII_PCI_DEVICE_PPI definition REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3907 This commit introduces
Re: [PATCH V3 0/6] Virtio toolstack support for I2C and GPIO on Arm
On 04.08.22 10:01, Viresh Kumar wrote:
Hello,
Hello Viresh
This patchset adds toolstack support for I2C and GPIO virtio devices. This is
inspired from the work done by Oleksandr for the Disk device.
This is developed as part of Linaro's Project Stratos, where we are working
towards Hypervisor agnostic Rust based backend [1].
This is based of origin/staging (commit 01ca29f0b17a ("sched: dom0_vcpus_pin
should only affect dom0")) which already has Oleksandr's patches applied.
V2->V3:
- Rebased over latest tree and made changes according to changes in Oleksandr's
patches from sometime back.
Thanks, I have reviewed all patches that touch libxl_arm.c (##3-6)
- Minor cleanups.
V1->V2:
- Patches 3/6 and 4/6 are new.
- Patches 5/6 and 6/6 updated based on the above two patches.
- Added link to the bindings for I2C and GPIO.
- Rebased over latest master branch.
Thanks.
--
Viresh
[1]
https://lore.kernel.org/xen-devel/20220414092358.kepxbmnrtycz7mhe@vireshk-i7/
Viresh Kumar (6):
libxl: Add support for Virtio I2C device
libxl: Add support for Virtio GPIO device
libxl: arm: Create alloc_virtio_mmio_params()
libxl: arm: Split make_virtio_mmio_node()
libxl: Allocate MMIO params for I2c device and update DT
libxl: Allocate MMIO params for GPIO device and update DT
tools/golang/xenlight/helpers.gen.go | 212
tools/golang/xenlight/types.gen.go| 54 ++
tools/include/libxl.h | 64 ++
tools/include/libxl_utils.h | 6 +
tools/libs/light/Makefile | 2 +
tools/libs/light/libxl_arm.c | 138 +++--
tools/libs/light/libxl_create.c | 26 +++
tools/libs/light/libxl_dm.c | 34 +++-
tools/libs/light/libxl_gpio.c | 226 ++
tools/libs/light/libxl_i2c.c | 226 ++
tools/libs/light/libxl_internal.h | 2 +
tools/libs/light/libxl_types.idl | 48 +
tools/libs/light/libxl_types_internal.idl | 2 +
tools/ocaml/libs/xl/genwrap.py| 2 +
tools/ocaml/libs/xl/xenlight_stubs.c | 2 +
tools/xl/Makefile | 2 +-
tools/xl/xl.h | 6 +
tools/xl/xl_cmdtable.c| 30 +++
tools/xl/xl_gpio.c| 142 ++
tools/xl/xl_i2c.c | 142 ++
tools/xl/xl_parse.c | 160 +++
tools/xl/xl_parse.h | 2 +
tools/xl/xl_sxp.c | 4 +
23 files changed, 1509 insertions(+), 23 deletions(-)
create mode 100644 tools/libs/light/libxl_gpio.c
create mode 100644 tools/libs/light/libxl_i2c.c
create mode 100644 tools/xl/xl_gpio.c
create mode 100644 tools/xl/xl_i2c.c
--
Regards,
Oleksandr Tyshchenko
Re: [PATCH V3 6/6] libxl: Allocate MMIO params for GPIO device and update DT
On 04.08.22 10:01, Viresh Kumar wrote:
Hello Viresh
This patch allocates Virtio MMIO params (IRQ and memory region) and pass
them to the backend, also update Guest device-tree based on Virtio GPIO
DT bindings [1].
[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio-virtio.yaml
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 47
1 file changed, 47 insertions(+)
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 08a1499c9523..14b95087f027 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -121,6 +121,15 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
return rc;
}
+for (i = 0; i < d_config->num_gpios; i++) {
+libxl_device_gpio *gpio = _config->gpios[i];
+
+int rc = alloc_virtio_mmio_params(gc, >base, >irq,
+_mmio_base, _mmio_irq);
+if (rc)
+return rc;
+}
+
/*
* Every virtio-mmio device uses one emulated SPI. If Virtio devices are
* present, make sure that we allocate enough SPIs for them.
@@ -974,6 +983,38 @@ static int make_virtio_mmio_node_i2c(libxl__gc *gc, void
*fdt, uint64_t base,
return fdt_end_node(fdt);
}
+static int make_virtio_mmio_node_gpio(libxl__gc *gc, void *fdt, uint64_t base,
+ uint32_t irq)
+{
+int res;
+
+res = make_virtio_mmio_node_common(gc, fdt, base, irq);
+if (res) return res;
+
+res = fdt_begin_node(fdt, "gpio");
+if (res) return res;
+
+res = fdt_property_compat(gc, fdt, 1, "virtio,device29");
+if (res) return res;
+
+res = fdt_property(fdt, "gpio-controller", NULL, 0);
+if (res) return res;
+
+res = fdt_property_cell(fdt, "#gpio-cells", 2);
+if (res) return res;
+
+res = fdt_property(fdt, "interrupt-controller", NULL, 0);
+if (res) return res;
+
+res = fdt_property_cell(fdt, "#interrupt-cells", 2);
+if (res) return res;
+
+res = fdt_end_node(fdt);
+if (res) return res;
+
+return fdt_end_node(fdt);
+}
+
static const struct arch_info *get_arch_info(libxl__gc *gc,
const struct xc_dom_image *dom)
{
@@ -1305,6 +1346,12 @@ static int libxl__prepare_dtb(libxl__gc *gc,
libxl_domain_config *d_config,
FDT( make_virtio_mmio_node_i2c(gc, fdt, i2c->base, i2c->irq) );
}
+for (i = 0; i < d_config->num_gpios; i++) {
+libxl_device_gpio *gpio = _config->gpios[i];
+
+FDT( make_virtio_mmio_node_gpio(gc, fdt, gpio->base, gpio->irq) );
+}
+
if (pfdt)
FDT( copy_partial_fdt(gc, fdt, pfdt) );
I think that patch needs to be updated taking into the account
suggestions provided for two previous patches (of course, if you agree
with them).
If so, the make_virtio_mmio_node_gpio() should gain "uint32_t
backend_domid" argument, etc. And we need to make sure that
make_xen_iommu_node() will be called for virtio gpio.
Something like the diff on top of current patch below (not tested):
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 9bd8d49f3c..54756b3dd5 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -986,11 +986,11 @@ static int make_virtio_mmio_node_i2c(libxl__gc
*gc, void *fdt, uint64_t base,
}
static int make_virtio_mmio_node_gpio(libxl__gc *gc, void *fdt,
uint64_t base,
- uint32_t irq)
+ uint32_t irq, uint32_t backend_domid)
{
int res;
- res = make_virtio_mmio_node_common(gc, fdt, base, irq);
+ res = make_virtio_mmio_node_common(gc, fdt, base, irq, backend_domid);
if (res) return res;
res = fdt_begin_node(fdt, "gpio");
@@ -1350,8 +1350,11 @@ next_resize:
for (i = 0; i < d_config->num_gpios; i++) {
libxl_device_gpio *gpio = _config->gpios[i];
+ if (gpio->backend_domid != LIBXL_TOOLSTACK_DOMID)
+ iommu_needed = true;
- FDT( make_virtio_mmio_node_gpio(gc, fdt, gpio->base,
gpio->irq) );
+ FDT( make_virtio_mmio_node_gpio(gc, fdt, gpio->base, gpio->irq,
+ gpio->backend_domid) );
}
/*
Other changes look good.
--
Regards,
Oleksandr Tyshchenko
Re: [PATCH V3 5/6] libxl: Allocate MMIO params for I2c device and update DT
On 04.08.22 10:01, Viresh Kumar wrote:
Hello Viresh
This patch allocates Virtio MMIO params (IRQ and memory region) and pass
them to the backend, also update Guest device-tree based on Virtio I2C
DT bindings [1].
[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/i2c/i2c-virtio.yaml
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 6a8c4d042bd9..08a1499c9523 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -112,6 +112,15 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
}
}
+for (i = 0; i < d_config->num_i2cs; i++) {
+libxl_device_i2c *i2c = _config->i2cs[i];
+
+int rc = alloc_virtio_mmio_params(gc, >base, >irq,
+_mmio_base, _mmio_irq);
+if (rc)
+return rc;
+}
+
/*
* Every virtio-mmio device uses one emulated SPI. If Virtio devices are
* present, make sure that we allocate enough SPIs for them.
@@ -945,6 +954,26 @@ static int make_virtio_mmio_node_simple(libxl__gc *gc,
void *fdt, uint64_t base,
return fdt_end_node(fdt);
}
+static int make_virtio_mmio_node_i2c(libxl__gc *gc, void *fdt, uint64_t base,
+ uint32_t irq)
+{
+int res;
+
+res = make_virtio_mmio_node_common(gc, fdt, base, irq);
+if (res) return res;
+
+res = fdt_begin_node(fdt, "i2c");
+if (res) return res;
+
+res = fdt_property_compat(gc, fdt, 1, "virtio,device22");
+if (res) return res;
+
+res = fdt_end_node(fdt);
+if (res) return res;
+
+return fdt_end_node(fdt);
+}
+
static const struct arch_info *get_arch_info(libxl__gc *gc,
const struct xc_dom_image *dom)
{
@@ -1270,6 +1299,12 @@ static int libxl__prepare_dtb(libxl__gc *gc,
libxl_domain_config *d_config,
}
}
+for (i = 0; i < d_config->num_i2cs; i++) {
+libxl_device_i2c *i2c = _config->i2cs[i];
+
+FDT( make_virtio_mmio_node_i2c(gc, fdt, i2c->base, i2c->irq) );
+}
+
if (pfdt)
FDT( copy_partial_fdt(gc, fdt, pfdt) );
I think that patch needs to be updated according to the suggestion
provided for "[PATCH V3 4/6] libxl: arm: Split make_virtio_mmio_node()"
(of course, if you agree with it).
If so, the make_virtio_mmio_node_i2c() should gain "uint32_t
backend_domid" argument, etc. And with introducing new virtio i2c the
make_xen_iommu_node() should also be called for it if not created yet
(or maybe better to have only single invocation of make_xen_iommu_node()
at the end)
Something like the diff on top of current patch below (not tested):
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 0e448c486b..725ccb5f3f 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -957,11 +957,11 @@ static int make_virtio_mmio_node_simple(libxl__gc
*gc, void *fdt, uint64_t base,
}
static int make_virtio_mmio_node_i2c(libxl__gc *gc, void *fdt,
uint64_t base,
- uint32_t irq)
+ uint32_t irq, uint32_t backend_domid)
{
int res;
- res = make_virtio_mmio_node_common(gc, fdt, base, irq);
+ res = make_virtio_mmio_node_common(gc, fdt, base, irq, backend_domid);
if (res) return res;
res = fdt_begin_node(fdt, "i2c");
@@ -1177,7 +1177,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;
@@ -1285,16 +1285,13 @@ next_resize:
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_simple(gc, fdt, disk->base,
disk->irq,
disk->backend_domid) );
@@ -1303,10 +1300,20 @@ next_resize:
for (i = 0; i < d_config->num_i2cs; i++) {
libxl_device_i2c *i2c = _config->i2cs[i];
+ if (i2c->backend_domid != LIBXL_TOOLSTACK_DOMID)
+
Re: [PATCH V3 4/6] libxl: arm: Split make_virtio_mmio_node()
On 04.08.22 10:01, Viresh Kumar wrote:
Hello Viresh
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.
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 2f64b9f0ebee..6a8c4d042bd9 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -900,9 +900,8 @@ 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)
+static int make_virtio_mmio_node_common(libxl__gc *gc, void *fdt, uint64_t
base,
+uint32_t irq)
{
int res;
gic_interrupt intr;
@@ -922,7 +921,15 @@ static int make_virtio_mmio_node(libxl__gc *gc, void *fdt,
res = fdt_property_interrupts(gc, fdt, , 1);
if (res) return res;
-res = fdt_property(fdt, "dma-coherent", NULL, 0);
+return fdt_property(fdt, "dma-coherent", NULL, 0);
+}
+
+static int make_virtio_mmio_node_simple(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);
if (res) return res;
if (backend_domid != LIBXL_TOOLSTACK_DOMID) {
@@ -935,10 +942,7 @@ static int make_virtio_mmio_node(libxl__gc *gc, void *fdt,
if (res) return res;
}
-res = fdt_end_node(fdt);
-if (res) return res;
-
-return 0;
+return fdt_end_node(fdt);
}
static const struct arch_info *get_arch_info(libxl__gc *gc,
@@ -1261,8 +1265,8 @@ static int libxl__prepare_dtb(libxl__gc *gc,
libxl_domain_config *d_config,
iommu_created = true;
}
-FDT( make_virtio_mmio_node(gc, fdt, disk->base, disk->irq,
- disk->backend_domid) );
+FDT( make_virtio_mmio_node_simple(gc, fdt, disk->base,
+disk->irq, disk->backend_domid) );
}
}
[I failed to find a better place where to make a comment]
I think that the following chunk should be also moved to
make_virtio_mmio_node_common() since it is not a virtio disk specific
action, this "iommus" property pointing to "xen,grant-dma" IOMMU node is
used to inform a guest that restricted memory access using Xen grant
mappings needs to be enabled for the virtio device if it's backend is
going to run in a non hardware domain, which I assume also applies for
virtio i2c, etc.
if (backend_domid != LIBXL_TOOLSTACK_DOMID) {
uint32_t iommus_prop[2];
iommus_prop[0] = cpu_to_fdt32(GUEST_PHANDLE_IOMMU);
iommus_prop[1] = cpu_to_fdt32(backend_domid);
res = fdt_property(fdt, "iommus", iommus_prop,
sizeof(iommus_prop));
if (res) return res;
}
This means that "uint32_t backend_domid" should be also passed as
argument to make_virtio_mmio_node_common()
Something like the diff on top of current patch below (not tested):
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index a98cfe708b..1a6ace3d8d 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -900,7 +900,7 @@ static int make_xen_iommu_node(libxl__gc *gc, void *fdt)
}
static int make_virtio_mmio_node_common(libxl__gc *gc, void *fdt,
uint64_t base,
- uint32_t irq)
+ uint32_t irq, uint32_t
backend_domid)
{
int res;
gic_interrupt intr;
@@ -920,15 +920,7 @@ static int make_virtio_mmio_node_common(libxl__gc
*gc, void *fdt, uint64_t base,
res = fdt_property_interrupts(gc, fdt, , 1);
if (res) return res;
- return fdt_property(fdt, "dma-coherent", NULL, 0);
-}
-
-static int make_virtio_mmio_node_simple(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);
+ res = fdt_property(fdt, "dma-coherent", NULL, 0);
if (res) return res;
if (backend_domid != LIBXL_TOOLSTACK_DOMID) {
@@ -941,6 +933,17 @@ static int make_virtio_mmio_node_simple(libxl__gc
*gc, void *fdt, uint64_t base,
if (res) return res;
}
+ return res;
+}
+
+static int make_virtio_mmio_node_simple(libxl__gc *gc, void *fdt,
uint64_t base,
+ uint32_t irq,
[qemu-mainline test] 172298: regressions - FAIL
flight 172298 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/172298/ 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 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qcow2 21 guest-start/debian.repeat fail in 172290 pass in 172298 test-amd64-i386-xl-vhd 21 guest-start/debian.repeat fail in 172290 pass in 172298 test-amd64-amd64-qemuu-nested-intel 12 debian-hvm-install fail pass in 172290 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-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-amd64-xl-qemuu-win7-amd64 19 guest-stopfail 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-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-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 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-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 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-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-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-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 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 15 migrate-support-checkfail never pass test-armhf-armhf-xl 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: qemuuc669f22f1a47897e8d1d595d6b8a59a572f9158c
[PATCH v2 0/2] automation: Test a pv network interface under dom0less enhanced
Xenia Ragiadakou (2): automation: qemu-smoke-arm64: Use kernel 5.19 automation: qemu-smoke-arm64: Run ping test over a pv network interface automation/gitlab-ci/build.yaml | 11 + automation/gitlab-ci/test.yaml| 10 +++-- automation/scripts/qemu-smoke-arm64.sh| 44 --- .../kernel/5.19-arm64v8.dockerfile| 37 4 files changed, 93 insertions(+), 9 deletions(-) create mode 100644 automation/tests-artifacts/kernel/5.19-arm64v8.dockerfile -- 2.34.1
[PATCH v2 1/2] automation: qemu-smoke-arm64: Use kernel 5.19
Use kernel 5.19 to unblock testing dom0less enhanced. This kernel version has the necessary patches for deferring xenbus probe until xenstore is fully initialized. Also, build kernel with bridging and xen netback support enabled because it will be used for testing network connectivity between Dom0 and Dom1 over a pv network interface. Signed-off-by: Xenia Ragiadakou --- Changes in v2: - none automation/gitlab-ci/build.yaml | 11 ++ automation/gitlab-ci/test.yaml| 4 +- .../kernel/5.19-arm64v8.dockerfile| 37 +++ 3 files changed, 50 insertions(+), 2 deletions(-) create mode 100644 automation/tests-artifacts/kernel/5.19-arm64v8.dockerfile diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml index 23b306e7d0..d2f75a090c 100644 --- a/automation/gitlab-ci/build.yaml +++ b/automation/gitlab-ci/build.yaml @@ -597,6 +597,17 @@ kernel-5.9.9-arm64-export: 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 + script: +- mkdir binaries && cp /Image binaries/Image + artifacts: +paths: + - binaries/Image + tags: +- arm64 + qemu-system-aarch64-6.0.0-arm64-export: extends: .test-jobs-artifact-common image: registry.gitlab.com/xen-project/xen/tests-artifacts/qemu-system-aarch64:6.0.0-arm64v8 diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml index 6f9f64a8da..aa633fb655 100644 --- a/automation/gitlab-ci/test.yaml +++ b/automation/gitlab-ci/test.yaml @@ -70,7 +70,7 @@ qemu-smoke-arm64-gcc: - ./automation/scripts/qemu-smoke-arm64.sh 2>&1 | tee qemu-smoke-arm64.log needs: - debian-unstable-gcc-arm64 -- kernel-5.9.9-arm64-export +- kernel-5.19-arm64-export - qemu-system-aarch64-6.0.0-arm64-export artifacts: paths: @@ -88,7 +88,7 @@ qemu-smoke-arm64-gcc-staticmem: - ./automation/scripts/qemu-smoke-arm64.sh static-mem 2>&1 | tee qemu-smoke-arm64.log needs: - debian-unstable-gcc-arm64 -- 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.19-arm64v8.dockerfile b/automation/tests-artifacts/kernel/5.19-arm64v8.dockerfile new file mode 100644 index 00..e445c1f03a --- /dev/null +++ b/automation/tests-artifacts/kernel/5.19-arm64v8.dockerfile @@ -0,0 +1,37 @@ +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.19 +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 && \ +sed -i 's/CONFIG_IPV6=m/CONFIG_IPV6=y/g' .config && \ +sed -i 's/CONFIG_BRIDGE=m/CONFIG_BRIDGE=y/g' .config && \ +sed -i 's/# CONFIG_XEN_NETDEV_BACKEND is not set/CONFIG_XEN_NETDEV_BACKEND=y/g' .config && \ +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.34.1
[PATCH v2 2/2] automation: qemu-smoke-arm64: Run ping test over a pv network interface
This patch modified the test in the following way
- Dom0 is booted with an alpine linux rootfs with the xen tools.
- Once Dom0 is booted, it starts xenstored, calls init-dom0less to setup
the xenstore interface for the dom0less Dom1, setups the bridged network
and attaches a pv network interface to Dom1.
- In the meantime, Dom1 in its init script tries to assign an ip to eth0
and ping Dom0,
- If Dom1 manages to ping Dom0, it prints 'passed'.
Signed-off-by: Xenia Ragiadakou
---
Changes in v2:
- rebase against the latest changes on staging
- search for 'Welcome to Alpine Linux' instead of 'Welcome to Alpine Linux 3.12'
so that the test is not bound to a specific Alpine Linux version
- do not disable dom0less enhanced in the ImageBuilder script
automation/gitlab-ci/test.yaml | 6 ++--
automation/scripts/qemu-smoke-arm64.sh | 44 +++---
2 files changed, 43 insertions(+), 7 deletions(-)
diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index aa633fb655..2eb6c3866e 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -69,7 +69,8 @@ qemu-smoke-arm64-gcc:
script:
- ./automation/scripts/qemu-smoke-arm64.sh 2>&1 | tee qemu-smoke-arm64.log
needs:
-- debian-unstable-gcc-arm64
+- 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:
@@ -87,7 +88,8 @@ qemu-smoke-arm64-gcc-staticmem:
script:
- ./automation/scripts/qemu-smoke-arm64.sh static-mem 2>&1 | tee
qemu-smoke-arm64.log
needs:
-- debian-unstable-gcc-arm64
+- 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:
diff --git a/automation/scripts/qemu-smoke-arm64.sh
b/automation/scripts/qemu-smoke-arm64.sh
index 497dbee15f..c80d9b2aee 100755
--- a/automation/scripts/qemu-smoke-arm64.sh
+++ b/automation/scripts/qemu-smoke-arm64.sh
@@ -4,8 +4,13 @@ set -ex
test_variant=$1
-passed="BusyBox"
-check=""
+passed="passed"
+check="
+until ifconfig eth0 192.168.0.2 && ping -c 10 192.168.0.1; do
+sleep 30
+done
+echo \"${passed}\"
+"
if [[ "${test_variant}" == "static-mem" ]]; then
# Memory range that is statically allocated to DOM1
@@ -68,6 +73,36 @@ cd initrd
find . | cpio --create --format='newc' | gzip > ../binaries/initrd
cd ..
+# DOM0 rootfs
+mkdir -p rootfs
+cd rootfs
+tar xzf ../binaries/initrd.tar.gz
+mkdir proc
+mkdir run
+mkdir srv
+mkdir sys
+rm var/run
+cp -ar ../binaries/dist/install/* .
+
+echo "#!/bin/bash
+
+export LD_LIBRARY_PATH=/usr/local/lib
+bash /etc/init.d/xencommons start
+
+/usr/local/lib/xen/bin/init-dom0less
+
+brctl addbr xenbr0
+brctl addif xenbr0 eth0
+ifconfig eth0 up
+ifconfig xenbr0 up
+ifconfig xenbr0 192.168.0.1
+
+xl network-attach 1 type=vif
+" > etc/local.d/xen.start
+chmod +x etc/local.d/xen.start
+echo "rc_verbose=yes" >> etc/rc.conf
+find . | cpio -H newc -o | gzip > ../binaries/dom0-rootfs.cpio.gz
+cd ..
# ImageBuilder
echo 'MEMORY_START="0x4000"
@@ -76,14 +111,13 @@ MEMORY_END="0x8000"
DEVICE_TREE="virt-gicv2.dtb"
XEN="xen"
DOM0_KERNEL="Image"
-DOM0_RAMDISK="initrd"
+DOM0_RAMDISK="dom0-rootfs.cpio.gz"
XEN_CMD="console=dtuart dom0_mem=512M"
NUM_DOMUS=1
DOMU_KERNEL[0]="Image"
DOMU_RAMDISK[0]="initrd"
DOMU_MEM[0]="256"
-DOMU_ENHANCED[0]=0
LOAD_CMD="tftpb"
UBOOT_SOURCE="boot.source"
@@ -114,5 +148,5 @@ timeout -k 1 240 \
-bios /usr/lib/u-boot/qemu_arm64/u-boot.bin |& tee smoke.serial
set -e
-(grep -q "^BusyBox" smoke.serial && grep -q "DOM1: ${passed}" smoke.serial) ||
exit 1
+(grep -q "^Welcome to Alpine Linux" smoke.serial && grep -q "DOM1: ${passed}"
smoke.serial) || exit 1
exit 0
--
2.34.1
Re: [PATCH V3 3/6] libxl: arm: Create alloc_virtio_mmio_params()
On 04.08.22 10:01, Viresh Kumar wrote:
Hello Viresh
Create a separate routine to allocate base and irq for a device as the
same code will be required for each device type.
Suggested-by: Oleksandr Tyshchenko
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 38
1 file changed, 25 insertions(+), 13 deletions(-)
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 1a3ac1646e94..2f64b9f0ebee 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) {
@@ -85,20 +103,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;
+int rc = alloc_virtio_mmio_params(gc, >base, >irq,
+_mmio_base, _mmio_irq);
+if (rc)
+return rc;
-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;
I think that "virtio_enabled = true;" should be moved ...
-
-LOG(DEBUG, "Allocate Virtio MMIO params for Vdev %s: IRQ %u BASE
0x%"PRIx64,
-disk->vdev, disk->irq, disk->base);
}
}
@@ -107,8 +117,10 @@ 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_irq = virtio_mmio_irq - 1;
nr_spis = max(nr_spis, virtio_irq - 32 + 1);
... here. Otherwise after applying all patches "virtio_enabled" only
gets set if there is a virtio disk device. So it won't be set for virtio
i2c, etc.
I see that in V2 it was there, but in V3 is not. Or maybe there is some
reason for doing that which I am not aware of?
Other changes look good.
+}
for (i = 0; i < d_config->b_info.num_irqs; i++) {
uint32_t irq = d_config->b_info.irqs[i];
--
Regards,
Oleksandr Tyshchenko
[linux-linus test] 172293: regressions - FAIL
flight 172293 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/172293/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172133 build-i386-libvirt6 libvirt-buildfail REGR. vs. 172133 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 172133 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 172133 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 17 guest-saverestorefail 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-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-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 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-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 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-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 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-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-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 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-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-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 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: linux4e23eeebb2e57f5a28b36221aa776b5a1122dde5 baseline version: linuxb44f2fd87919b5ae6e1756d4c7ba2cbba22238e1 Last test of basis 172133 2022-08-04 05:14:48 Z4 days Failing since172152 2022-08-05 04:01:26 Z3 days 11 attempts Testing same since 172293 2022-08-08 06:55:39 Z0 days1 attempts 1074 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm
[ovmf test] 172302: regressions - FAIL
flight 172302 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/172302/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136 build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136 version targeted for testing: ovmf cf02322c984a16fc2af252124df96564e574f3a7 baseline version: ovmf 444260d45ec2a84e8f8c192b3539a3cd5591d009 Last test of basis 172136 2022-08-04 06:43:42 Z4 days Failing since172151 2022-08-05 02:40:28 Z3 days 35 attempts Testing same since 172247 2022-08-06 15:41:48 Z2 days 21 attempts People who touched revisions under test: Czajkowski, Maciej Edward Pickup Konstantin Aladyshev Maciej Czajkowski 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. commit cf02322c984a16fc2af252124df96564e574f3a7 Author: Konstantin Aladyshev Date: Wed Jul 20 22:08:12 2022 +0800 BaseTools/GenSec: Support EFI_SECTION_FREEFORM_SUBTYPE_GUID sections Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit d241a09afbe4f472a5d7da5090dfc85046f2250f Author: Konstantin Aladyshev Date: Wed Jul 20 20:00:39 2022 +0800 BaseTools/VolInfo: Parse EFI_SECTION_FREEFORM_SUBTYPE_GUID header Print 'SubtypeGuid' field from the EFI_FREEFORM_SUBTYPE_GUID_SECTION structure. This value describes the raw data inside the section. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit f5f8c08db92d15c7a359a5eb3b0cc2545c945942 Author: Konstantin Aladyshev Date: Tue Jul 19 23:45:52 2022 +0800 BaseTools/VolInfo: Show FV section boundaries Currently there is no labels for start and end of the EFI_SECTION_FIRMWARE_VOLUME_IMAGE type section. Therefore it is not possible to see where the FV section ends and another section starts. Add labels for start and end of the FV sections to fix the issue. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit a0a03b51548e6fc7524b5aa9f8042cbabce6da1c Author: Konstantin Aladyshev Date: Tue Jul 19 22:27:10 2022 +0800 BaseTools/GenSec: Fix typo Fix typo in the help message. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit 3e599bbc105ff089b21b6024100d585a8c781328 Author: Edward Pickup Date: Thu Aug 4 10:20:50 2022 +0100 DynamicTablesPkg: Fix using RmrNodeCount unitlitialised Fix using RmrNodeCount uninitliased by initliasing it to zero. Also, add an additional check for ACPI version. This fixes a crash running on kvmtool. Signed-off-by: Edward Pickup Reviewed-by: Sami Mujawar commit a8f59e2eb44199040d2e1f747a6d950a25ed0984 Author: Czajkowski, Maciej Date: Tue Aug 2 01:00:09 2022 +0800 MdeModulePkg/AhciPei: Use PCI_DEVICE_PPI to manage AHCI device REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3907 This change modifies AhciPei library to allow usage both EDKII_PCI_DEVICE_PPI and EDKII_PEI_ATA_AHCI_HOST_CONTROLLER_PPI to manage ATA HDD working under AHCI mode. Cc: Hao A Wu Cc: Ray Ni Cc: Liming Gao Signed-off-by: Maciej Czajkowski Reviewed-by: Hao A Wu commit 86757f0b4750f672f346d955f89e5b76430ba6b4 Author: Czajkowski, Maciej Date: Tue Aug 2 01:00:08 2022 +0800 MdeModulePkg: Add EDKII_PCI_DEVICE_PPI definition REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3907 This commit introduces
[ovmf test] 172301: regressions - FAIL
flight 172301 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/172301/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136 build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-install fail pass in 172299 version targeted for testing: ovmf cf02322c984a16fc2af252124df96564e574f3a7 baseline version: ovmf 444260d45ec2a84e8f8c192b3539a3cd5591d009 Last test of basis 172136 2022-08-04 06:43:42 Z4 days Failing since172151 2022-08-05 02:40:28 Z3 days 34 attempts Testing same since 172247 2022-08-06 15:41:48 Z2 days 20 attempts People who touched revisions under test: Czajkowski, Maciej Edward Pickup Konstantin Aladyshev Maciej Czajkowski 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 fail 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. commit cf02322c984a16fc2af252124df96564e574f3a7 Author: Konstantin Aladyshev Date: Wed Jul 20 22:08:12 2022 +0800 BaseTools/GenSec: Support EFI_SECTION_FREEFORM_SUBTYPE_GUID sections Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit d241a09afbe4f472a5d7da5090dfc85046f2250f Author: Konstantin Aladyshev Date: Wed Jul 20 20:00:39 2022 +0800 BaseTools/VolInfo: Parse EFI_SECTION_FREEFORM_SUBTYPE_GUID header Print 'SubtypeGuid' field from the EFI_FREEFORM_SUBTYPE_GUID_SECTION structure. This value describes the raw data inside the section. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit f5f8c08db92d15c7a359a5eb3b0cc2545c945942 Author: Konstantin Aladyshev Date: Tue Jul 19 23:45:52 2022 +0800 BaseTools/VolInfo: Show FV section boundaries Currently there is no labels for start and end of the EFI_SECTION_FIRMWARE_VOLUME_IMAGE type section. Therefore it is not possible to see where the FV section ends and another section starts. Add labels for start and end of the FV sections to fix the issue. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit a0a03b51548e6fc7524b5aa9f8042cbabce6da1c Author: Konstantin Aladyshev Date: Tue Jul 19 22:27:10 2022 +0800 BaseTools/GenSec: Fix typo Fix typo in the help message. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit 3e599bbc105ff089b21b6024100d585a8c781328 Author: Edward Pickup Date: Thu Aug 4 10:20:50 2022 +0100 DynamicTablesPkg: Fix using RmrNodeCount unitlitialised Fix using RmrNodeCount uninitliased by initliasing it to zero. Also, add an additional check for ACPI version. This fixes a crash running on kvmtool. Signed-off-by: Edward Pickup Reviewed-by: Sami Mujawar commit a8f59e2eb44199040d2e1f747a6d950a25ed0984 Author: Czajkowski, Maciej Date: Tue Aug 2 01:00:09 2022 +0800 MdeModulePkg/AhciPei: Use PCI_DEVICE_PPI to manage AHCI device REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3907 This change modifies AhciPei library to allow usage both EDKII_PCI_DEVICE_PPI and EDKII_PEI_ATA_AHCI_HOST_CONTROLLER_PPI to manage ATA HDD working under AHCI mode. Cc: Hao A Wu Cc: Ray Ni Cc: Liming Gao Signed-off-by: Maciej Czajkowski Reviewed-by: Hao A Wu commit 86757f0b4750f672f346d955f89e5b76430ba6b4 Author: Czajkowski, Maciej Date: Tue Aug 2 01:00:08 2022 +0800 MdeModulePkg: Add
Re: [XEN PATCH v3 11/25] tools/xentrace: rework Makefile
On Fri, Jul 22, 2022 at 01:30:53PM +, Luca Fancellu wrote: > > On 24 Jun 2022, at 17:04, Anthony PERARD wrote: > > .PHONY: uninstall > > uninstall: > > rm -f $(addprefix $(DESTDIR)$(LIBEXEC_BIN)/, $(LIBBIN)) > > rm -f $(addprefix $(DESTDIR)$(bindir)/, $(SCRIPTS)) > > rm -f $(addprefix $(DESTDIR)$(sbindir)/, $(SBIN)) > > -ifneq ($(BIN),) > > rm -f $(addprefix $(DESTDIR)$(bindir)/, $(BIN)) > > -endif > > Why here don’t we use $(RM) ? Well, I don't think it matters which is used between $(RM) and rm -f, beside consistency maybe. So I don't think introducing changes on those line would be useful. (Also, it seems that the use of $(RM) for "uninstall" targets are exceptional so far.) -- Anthony PERARD
Re: [PATCH] xen/pci: replace call to is_memory_hole to pci_check_bar
On 05.08.22 18:43, Rahul Singh wrote:
Hello Rahul
Thank you very much for that patch!
From: Oleksandr Andrushchenko
I am not 100% sure regarding that. This is *completely* different patch
from what Oleksandr initially made here:
https://lore.kernel.org/xen-devel/20220719174253.541965-2-olekst...@gmail.com/
Copy below for the convenience:
+bool is_memory_hole(mfn_t start, mfn_t end)
+{
+ /* TODO: this needs to be properly implemented. */
+ return true;
+}
Patch looks good, just a couple of minor comments/nits.
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
---
xen/arch/arm/include/asm/pci.h | 12 ++
xen/arch/arm/pci/pci-host-common.c | 35 ++
xen/arch/x86/include/asm/pci.h | 10 +
xen/drivers/passthrough/pci.c | 8 +++
4 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/include/asm/pci.h b/xen/arch/arm/include/asm/pci.h
index 7c7449d64f..5c4ab2c4dc 100644
--- a/xen/arch/arm/include/asm/pci.h
+++ b/xen/arch/arm/include/asm/pci.h
@@ -91,6 +91,16 @@ struct pci_ecam_ops {
int (*init)(struct pci_config_window *);
};
+/*
+ * struct to hold pci device bar.
+ */
+struct pdev_bar
+{
+mfn_t start;
+mfn_t end;
+bool is_valid;
+};
Nit: This is only used by pci-host-common.c, so I think it could be
declared there.
+
/* Default ECAM ops */
extern const struct pci_ecam_ops pci_generic_ecam_ops;
@@ -125,6 +135,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 fd8c0f837a..8ea1aaeece 100644
--- a/xen/arch/arm/pci/pci-host-common.c
+++ b/xen/arch/arm/pci/pci-host-common.c
@@ -363,6 +363,41 @@ int __init pci_host_bridge_mappings(struct domain *d)
return 0;
}
+static int is_bar_valid(const struct dt_device_node *dev,
+u64 addr, u64 len, void *data)
+{
+struct pdev_bar *bar_data = data;
+unsigned long s = mfn_x(bar_data->start);
+unsigned long e = mfn_x(bar_data->end);
+
+if ( (s < e) && (s >= PFN_DOWN(addr)) && (e<= PFN_DOWN(addr + len - 1)) )
Nit: white space after 'e' is missed in the last part of the check
+bar_data->is_valid = true;
+
+return 0;
+}
+
+bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end)
+{
+int ret;
+struct dt_device_node *dt_node;
+struct device *dev = (struct device *)pci_to_dev(pdev);
The cast is present here because of the const?
I would consider passing "const struct pci_dev *pdev" instead of "struct
device *dev" to pci_find_host_bridge_node() and dropping conversion
(pci<->dev) in both functions.
Something like below (not tested):
diff --git a/xen/arch/arm/include/asm/pci.h b/xen/arch/arm/include/asm/pci.h
index 5c4ab2c4dc..a17ef32252 100644
--- a/xen/arch/arm/include/asm/pci.h
+++ b/xen/arch/arm/include/asm/pci.h
@@ -116,7 +116,7 @@ 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);
+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 8ea1aaeece..3a64a7350f 100644
--- a/xen/arch/arm/pci/pci-host-common.c
+++ b/xen/arch/arm/pci/pci-host-common.c
@@ -243,10 +243,9 @@ err_exit:
/*
* Get host bridge node given a device attached to it.
*/
-struct dt_device_node *pci_find_host_bridge_node(struct device *dev)
+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) )
@@ -380,14 +379,13 @@ bool pci_check_bar(const struct pci_dev *pdev,
mfn_t start, mfn_t end)
{
int ret;
struct dt_device_node *dt_node;
- struct device *dev = (struct
[ovmf test] 172299: regressions - FAIL
flight 172299 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/172299/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136 build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136 version targeted for testing: ovmf cf02322c984a16fc2af252124df96564e574f3a7 baseline version: ovmf 444260d45ec2a84e8f8c192b3539a3cd5591d009 Last test of basis 172136 2022-08-04 06:43:42 Z4 days Failing since172151 2022-08-05 02:40:28 Z3 days 33 attempts Testing same since 172247 2022-08-06 15:41:48 Z1 days 19 attempts People who touched revisions under test: Czajkowski, Maciej Edward Pickup Konstantin Aladyshev Maciej Czajkowski 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. commit cf02322c984a16fc2af252124df96564e574f3a7 Author: Konstantin Aladyshev Date: Wed Jul 20 22:08:12 2022 +0800 BaseTools/GenSec: Support EFI_SECTION_FREEFORM_SUBTYPE_GUID sections Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit d241a09afbe4f472a5d7da5090dfc85046f2250f Author: Konstantin Aladyshev Date: Wed Jul 20 20:00:39 2022 +0800 BaseTools/VolInfo: Parse EFI_SECTION_FREEFORM_SUBTYPE_GUID header Print 'SubtypeGuid' field from the EFI_FREEFORM_SUBTYPE_GUID_SECTION structure. This value describes the raw data inside the section. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit f5f8c08db92d15c7a359a5eb3b0cc2545c945942 Author: Konstantin Aladyshev Date: Tue Jul 19 23:45:52 2022 +0800 BaseTools/VolInfo: Show FV section boundaries Currently there is no labels for start and end of the EFI_SECTION_FIRMWARE_VOLUME_IMAGE type section. Therefore it is not possible to see where the FV section ends and another section starts. Add labels for start and end of the FV sections to fix the issue. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit a0a03b51548e6fc7524b5aa9f8042cbabce6da1c Author: Konstantin Aladyshev Date: Tue Jul 19 22:27:10 2022 +0800 BaseTools/GenSec: Fix typo Fix typo in the help message. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit 3e599bbc105ff089b21b6024100d585a8c781328 Author: Edward Pickup Date: Thu Aug 4 10:20:50 2022 +0100 DynamicTablesPkg: Fix using RmrNodeCount unitlitialised Fix using RmrNodeCount uninitliased by initliasing it to zero. Also, add an additional check for ACPI version. This fixes a crash running on kvmtool. Signed-off-by: Edward Pickup Reviewed-by: Sami Mujawar commit a8f59e2eb44199040d2e1f747a6d950a25ed0984 Author: Czajkowski, Maciej Date: Tue Aug 2 01:00:09 2022 +0800 MdeModulePkg/AhciPei: Use PCI_DEVICE_PPI to manage AHCI device REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3907 This change modifies AhciPei library to allow usage both EDKII_PCI_DEVICE_PPI and EDKII_PEI_ATA_AHCI_HOST_CONTROLLER_PPI to manage ATA HDD working under AHCI mode. Cc: Hao A Wu Cc: Ray Ni Cc: Liming Gao Signed-off-by: Maciej Czajkowski Reviewed-by: Hao A Wu commit 86757f0b4750f672f346d955f89e5b76430ba6b4 Author: Czajkowski, Maciej Date: Tue Aug 2 01:00:08 2022 +0800 MdeModulePkg: Add EDKII_PCI_DEVICE_PPI definition REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3907 This commit introduces
[xen-unstable test] 172287: tolerable FAIL
flight 172287 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/172287/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-shadow 7 xen-install fail in 172262 pass in 172287 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 18 guest-localmigrate/x10 fail in 172262 pass in 172287 test-amd64-i386-xl-qemuu-ovmf-amd64 18 guest-localmigrate/x10 fail in 172262 pass in 172287 test-armhf-armhf-xl-vhd 17 guest-start/debian.repeat fail in 172262 pass in 172287 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-install fail pass in 172262 test-amd64-amd64-qemuu-nested-intel 12 debian-hvm-install fail pass in 172262 test-amd64-amd64-xl-qcow212 debian-di-install fail pass in 172262 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-i386-libvirt6 libvirt-buildfail like 172262 build-amd64-libvirt 6 libvirt-buildfail like 172262 build-arm64-libvirt 6 libvirt-buildfail like 172262 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 172262 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 172262 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 172262 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 172262 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 172262 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 172262 build-armhf-libvirt 6 libvirt-buildfail like 172262 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 172262 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 172262 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 172262 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-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-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-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 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-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-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16
[ovmf test] 172296: regressions - FAIL
flight 172296 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/172296/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136 build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136 version targeted for testing: ovmf cf02322c984a16fc2af252124df96564e574f3a7 baseline version: ovmf 444260d45ec2a84e8f8c192b3539a3cd5591d009 Last test of basis 172136 2022-08-04 06:43:42 Z4 days Failing since172151 2022-08-05 02:40:28 Z3 days 32 attempts Testing same since 172247 2022-08-06 15:41:48 Z1 days 18 attempts People who touched revisions under test: Czajkowski, Maciej Edward Pickup Konstantin Aladyshev Maciej Czajkowski 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. commit cf02322c984a16fc2af252124df96564e574f3a7 Author: Konstantin Aladyshev Date: Wed Jul 20 22:08:12 2022 +0800 BaseTools/GenSec: Support EFI_SECTION_FREEFORM_SUBTYPE_GUID sections Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit d241a09afbe4f472a5d7da5090dfc85046f2250f Author: Konstantin Aladyshev Date: Wed Jul 20 20:00:39 2022 +0800 BaseTools/VolInfo: Parse EFI_SECTION_FREEFORM_SUBTYPE_GUID header Print 'SubtypeGuid' field from the EFI_FREEFORM_SUBTYPE_GUID_SECTION structure. This value describes the raw data inside the section. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit f5f8c08db92d15c7a359a5eb3b0cc2545c945942 Author: Konstantin Aladyshev Date: Tue Jul 19 23:45:52 2022 +0800 BaseTools/VolInfo: Show FV section boundaries Currently there is no labels for start and end of the EFI_SECTION_FIRMWARE_VOLUME_IMAGE type section. Therefore it is not possible to see where the FV section ends and another section starts. Add labels for start and end of the FV sections to fix the issue. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit a0a03b51548e6fc7524b5aa9f8042cbabce6da1c Author: Konstantin Aladyshev Date: Tue Jul 19 22:27:10 2022 +0800 BaseTools/GenSec: Fix typo Fix typo in the help message. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit 3e599bbc105ff089b21b6024100d585a8c781328 Author: Edward Pickup Date: Thu Aug 4 10:20:50 2022 +0100 DynamicTablesPkg: Fix using RmrNodeCount unitlitialised Fix using RmrNodeCount uninitliased by initliasing it to zero. Also, add an additional check for ACPI version. This fixes a crash running on kvmtool. Signed-off-by: Edward Pickup Reviewed-by: Sami Mujawar commit a8f59e2eb44199040d2e1f747a6d950a25ed0984 Author: Czajkowski, Maciej Date: Tue Aug 2 01:00:09 2022 +0800 MdeModulePkg/AhciPei: Use PCI_DEVICE_PPI to manage AHCI device REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3907 This change modifies AhciPei library to allow usage both EDKII_PCI_DEVICE_PPI and EDKII_PEI_ATA_AHCI_HOST_CONTROLLER_PPI to manage ATA HDD working under AHCI mode. Cc: Hao A Wu Cc: Ray Ni Cc: Liming Gao Signed-off-by: Maciej Czajkowski Reviewed-by: Hao A Wu commit 86757f0b4750f672f346d955f89e5b76430ba6b4 Author: Czajkowski, Maciej Date: Tue Aug 2 01:00:08 2022 +0800 MdeModulePkg: Add EDKII_PCI_DEVICE_PPI definition REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3907 This commit introduces
[qemu-mainline test] 172290: regressions - FAIL
flight 172290 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/172290/ 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 Tests which are failing intermittently (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-install fail in 172281 pass in 172290 test-amd64-amd64-xl-qcow221 guest-start/debian.repeat fail pass in 172281 test-amd64-i386-xl-vhd 21 guest-start/debian.repeat fail pass in 172281 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-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-amd64-xl-qemuu-win7-amd64 19 guest-stopfail 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-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-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 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-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 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-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-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-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 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 15 migrate-support-checkfail never pass test-armhf-armhf-xl 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: qemuuc669f22f1a47897e8d1d595d6b8a59a572f9158c baseline
Re: [PATCH v3 5/5] tools/xenstore: add migration stream extensions for new features
On 08.08.22 13:00, Julien Grall wrote:
Hi Juergen,
On 08/08/2022 07:33, Juergen Gross wrote:
On 04.08.22 21:28, Julien Grall wrote:
On 03/08/2022 12:59, 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
Signed-off-by: Juergen Gross
---
V3:
- new patch
---
docs/designs/xenstore-migration.md | 85 --
1 file changed, 82 insertions(+), 3 deletions(-)
diff --git a/docs/designs/xenstore-migration.md
b/docs/designs/xenstore-migration.md
index efa526f420..b2b1d3d5c7 100644
--- a/docs/designs/xenstore-migration.md
+++ b/docs/designs/xenstore-migration.md
@@ -43,7 +43,13 @@ the setting of the endianness bit.
|---|---|
| `ident` | 0x78656e73746f7265 ('xenstore' in ASCII) |
| | |
-| `version` | 0x0001 (the version of the specification) |
+| `version` | The version of the specification, defined values: |
+| | 0x0001: all fields without any explicitly |
+| | mentioned version dependency are |
+| | valid. |
+| | 0x0002: all fields valid for version 1 plus |
+| | fields explicitly stated to be |
+| | supported in version 2 are valid. |
I am a bit concerned with the bump of the versions. It means, it will be
necessary for Xenstored to know whether the new Xenstored speaks v1 or v2.
This is less an issue when Live-Migration (although there is a fleet
management problem) but it will be one for Live-Update if we need to rollback.
So I am wondering if we can avoid to bump the version and use other means to
detect the difference.
In the end this is exactly what the version was meant to be used for.
I think it would make much more sense to think about the way to handle a
bump of the version in a compatible way.
My idea was to add a xenstored command line parameter for limiting the
migration stream version to be used to a specified version, causing new
features probably to not be available, though.
I think this is fine. Someone that cares about rollback will also likely care
about fleet diversity. So they will want to avoid enabling a feature until they
know it can work everywhere.
That was the idea, yes.
I don't see how e.g. a rollback would be doable in case a domain already
started to use a new feature like the third parameter when setting a watch.
Even if we'd drop the depth information when rolling back a watch set
afterwards with an additional depth added would be rejected by the older
xenstored, which would be unexpected failure for the guest.
See above.
It might make sense to try to use the V1 stream when doing a live update,
e.g. covering the case when the SET_FEATURE command was used for each
active guest to limit the features to V1 compatible ones. A force parameter
might be used to use the V1 stream even if guests are using V2 features,
risking breakage of those guests.
I don't have a strong opinion on this yet. I might have some when seen the code
:).
[...]
This would even be possible using the global record of V1, as
the length information of the record allows to add new fields without
having to bump the version.
I was actually thinking about this when writing the e-mail last week. There are
no dynamic length array in the global records so far, so using the length
information would be ok. I am more concerned about the others because we are
mixing fixed and dynamic length.
This means it is more difficult to read the code and the layout.
+| `n-glob-quota` | Number of quota values which apply globally |
+| | only. Valid only for version 2 and later. |
+| | |
+| `quota-val` | Quota values, first the ones applying per |
+| | domain, then the ones applying globally. A |
+| | value of 0 has the semantics of "unlimited". |
+| | Valid only for version 2 and later. |
+| | |
+| `quota-names` | 0 delimited strings of the quota names in |
+| | the same sequence as the `quota-val` values. | >
+| | Valid only for version 2 and later. |
From my understanding, both version of Xenstored needs to agree on the quota
names. So it means the name have to be defined as part of the spec. At which
point, I think it would be better to use ID.
I don't think so. For one the minimal set of quota names has been defined
already in patch 3.
Someone reading the migration stream will not necessarily read the Xenstore
protocol. So I think we should either make them explicit in the
[XEN PATCH 2/2] tools/libxl: Replace deprecated -soundhw on QEMU command line
-soundhw is deprecated since 825ff02911c9 ("audio: add soundhw
deprecation notice"), QEMU v5.1, and is been remove for upcoming v7.1
by 039a68373c45 ("introduce -audio as a replacement for -soundhw").
Instead we can just add the sound card with "-device", for most option
that "-soundhw" could handle. "-device" is an option that existed
before QEMU 1.0, and could already be used to add audio hardware.
The list of possible option for libxl's "soundhw" is taken the list
from QEMU 7.0.
The list of options for "soundhw" are listed in order of preference in
the manual. The first three (hda, ac97, es1370) are PCI devices and
easy to test on Linux, and the last four are ISA devices which doesn't
seems to work out of the box on linux.
The sound card 'pcspk' isn't listed even if it used to be accepted by
'-soundhw' because QEMU crash when trying to add it to a Xen domain.
Also, it wouldn't work with "-device" might need to be "-machine
pcspk-audiodev=default" instead.
Signed-off-by: Anthony PERARD
---
docs/man/xl.cfg.5.pod.in | 6 +++---
tools/libs/light/libxl_types_internal.idl | 10 ++
tools/libs/light/libxl_dm.c | 19 ++-
3 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 6d98d73d76..b2901e04cf 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -2555,9 +2555,9 @@ The form serial=DEVICE is also accepted for backwards
compatibility.
=item B
-Select the virtual sound card to expose to the guest. The valid
-devices are defined by the device model configuration, please see the
-B manpage for details. The default is not to export any sound
+Select the virtual sound card to expose to the guest. The valid devices are
+B, B, B, B, B, B, B if there are
+available with the device model QEMU. The default is not to export any sound
device.
=item B
diff --git a/tools/libs/light/libxl_types_internal.idl
b/tools/libs/light/libxl_types_internal.idl
index 8f71980aec..fb0f4f23d7 100644
--- a/tools/libs/light/libxl_types_internal.idl
+++ b/tools/libs/light/libxl_types_internal.idl
@@ -56,3 +56,13 @@ libxl__device_action = Enumeration("device_action", [
(1, "ADD"),
(2, "REMOVE"),
])
+
+libxl__qemu_soundhw = Enumeration("qemu_soundhw", [
+(1, "ac97"),
+(2, "adlib"),
+(3, "cs4231a"),
+(4, "es1370"),
+(5, "gus"),
+(6, "hda"),
+(7, "sb16"),
+])
diff --git a/tools/libs/light/libxl_dm.c b/tools/libs/light/libxl_dm.c
index 04bf5d8563..fc264a3a13 100644
--- a/tools/libs/light/libxl_dm.c
+++ b/tools/libs/light/libxl_dm.c
@@ -1204,6 +1204,7 @@ static int libxl__build_device_model_args_new(libxl__gc
*gc,
uint64_t ram_size;
const char *path, *chardev;
bool is_stubdom = libxl_defbool_val(b_info->device_model_stubdomain);
+int rc;
dm_args = flexarray_make(gc, 16, 1);
dm_envs = flexarray_make(gc, 16, 1);
@@ -1531,7 +1532,23 @@ static int libxl__build_device_model_args_new(libxl__gc
*gc,
}
}
if (b_info->u.hvm.soundhw) {
-flexarray_vappend(dm_args, "-soundhw", b_info->u.hvm.soundhw,
NULL);
+libxl__qemu_soundhw soundhw;
+
+rc = libxl__qemu_soundhw_from_string(b_info->u.hvm.soundhw,
);
+if (rc) {
+LOGD(ERROR, guest_domid, "Unknown soundhw option '%s'",
b_info->u.hvm.soundhw);
+return ERROR_INVAL;
+}
+
+switch (soundhw) {
+case LIBXL__QEMU_SOUNDHW_HDA:
+flexarray_vappend(dm_args, "-device", "intel-hda",
+ "-device", "hda-duplex", NULL);
+break;
+default:
+flexarray_append_pair(dm_args, "-device",
+
(char*)libxl__qemu_soundhw_to_string(soundhw));
+}
}
if (!libxl__acpi_defbool_val(b_info)) {
flexarray_append(dm_args, "-no-acpi");
--
Anthony PERARD
[XEN PATCH 1/2] tools/libxl: Replace deprecated -sdl option on QEMU command line
"-sdl" is deprecated upstream since 6695e4c0fd9e ("softmmu/vl:
Deprecate the -sdl and -curses option"), QEMU v6.2, and the option is
removed by 707d93d4abc6 ("ui: Remove deprecated options "-sdl" and
"-curses""), in upcoming QEMU v7.1.
Instead, use "-display sdl", available since 1472a95bab1e ("Introduce
-display argument"), before QEMU v1.0.
Signed-off-by: Anthony PERARD
---
tools/libs/light/libxl_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libs/light/libxl_dm.c b/tools/libs/light/libxl_dm.c
index 1864ee30f0..04bf5d8563 100644
--- a/tools/libs/light/libxl_dm.c
+++ b/tools/libs/light/libxl_dm.c
@@ -1349,7 +1349,7 @@ static int libxl__build_device_model_args_new(libxl__gc
*gc,
flexarray_append_pair(dm_args, "-display", "none");
if (sdl && !is_stubdom) {
-flexarray_append(dm_args, "-sdl");
+flexarray_append_pair(dm_args, "-display", "sdl");
if (sdl->display)
flexarray_append_pair(dm_envs, "DISPLAY", sdl->display);
if (sdl->xauthority)
--
Anthony PERARD
[XEN PATCH 0/2] libxl: replace deprecated -sdl and -soundhw qemu options
Patch series available in this git branch: https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git br.qemu-deprecated-soundhw-v1 Hi, There's some more QEMU options that are deprecated. We still don't need to figure out which QEMU version we are going to run as the options that replace them already existed in QEMU 1.0, so all the version QEMU upstream that we could possible use as device model. Thanks, Anthony PERARD (2): tools/libxl: Replace deprecated -sdl option on QEMU command line tools/libxl: Replace deprecated -soundhw on QEMU command line docs/man/xl.cfg.5.pod.in | 6 +++--- tools/libs/light/libxl_types_internal.idl | 10 ++ tools/libs/light/libxl_dm.c | 21 +++-- 3 files changed, 32 insertions(+), 5 deletions(-) -- Anthony PERARD
Re: [PATCH v3 5/5] tools/xenstore: add migration stream extensions for new features
Hi Juergen,
On 08/08/2022 07:33, Juergen Gross wrote:
On 04.08.22 21:28, Julien Grall wrote:
On 03/08/2022 12:59, 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
Signed-off-by: Juergen Gross
---
V3:
- new patch
---
docs/designs/xenstore-migration.md | 85 --
1 file changed, 82 insertions(+), 3 deletions(-)
diff --git a/docs/designs/xenstore-migration.md
b/docs/designs/xenstore-migration.md
index efa526f420..b2b1d3d5c7 100644
--- a/docs/designs/xenstore-migration.md
+++ b/docs/designs/xenstore-migration.md
@@ -43,7 +43,13 @@ the setting of the endianness bit.
|---|---|
| `ident` | 0x78656e73746f7265 ('xenstore' in ASCII) |
| | |
-| `version` | 0x0001 (the version of the specification) |
+| `version` | The version of the specification, defined values: |
+| | 0x0001: all fields without any explicitly |
+| | mentioned version dependency are |
+| | valid. |
+| | 0x0002: all fields valid for version 1 plus |
+| | fields explicitly stated to be |
+| | supported in version 2 are valid. |
I am a bit concerned with the bump of the versions. It means, it will
be necessary for Xenstored to know whether the new Xenstored speaks v1
or v2. This is less an issue when Live-Migration (although there is a
fleet management problem) but it will be one for Live-Update if we
need to rollback.
So I am wondering if we can avoid to bump the version and use other
means to detect the difference.
In the end this is exactly what the version was meant to be used for.
I think it would make much more sense to think about the way to handle a
bump of the version in a compatible way.
My idea was to add a xenstored command line parameter for limiting the
migration stream version to be used to a specified version, causing new
features probably to not be available, though.
I think this is fine. Someone that cares about rollback will also likely
care about fleet diversity. So they will want to avoid enabling a
feature until they know it can work everywhere.
I don't see how e.g. a rollback would be doable in case a domain already
started to use a new feature like the third parameter when setting a watch.
Even if we'd drop the depth information when rolling back a watch set
afterwards with an additional depth added would be rejected by the older
xenstored, which would be unexpected failure for the guest.
See above.
It might make sense to try to use the V1 stream when doing a live update,
e.g. covering the case when the SET_FEATURE command was used for each
active guest to limit the features to V1 compatible ones. A force parameter
might be used to use the V1 stream even if guests are using V2 features,
risking breakage of those guests.
I don't have a strong opinion on this yet. I might have some when seen
the code :).
[...]
This would even be possible using the global record of V1, as
the length information of the record allows to add new fields without
having to bump the version.
I was actually thinking about this when writing the e-mail last week.
There are no dynamic length array in the global records so far, so using
the length information would be ok. I am more concerned about the others
because we are mixing fixed and dynamic length.
This means it is more difficult to read the code and the layout.
+| `n-glob-quota` | Number of quota values which apply globally |
+| | only. Valid only for version 2 and later. |
+| | |
+| `quota-val` | Quota values, first the ones applying per |
+| | domain, then the ones applying globally. A |
+| | value of 0 has the semantics of "unlimited". |
+| | Valid only for version 2 and later. |
+| | |
+| `quota-names` | 0 delimited strings of the quota names in |
+| | the same sequence as the `quota-val` values. | >
+| | Valid only for version 2 and later. |
From my understanding, both version of Xenstored needs to agree on
the quota names. So it means the name have to be defined as part of
the spec. At which point, I think it would be better to use ID.
I don't think so. For one the minimal set of quota names has been defined
already in patch 3.
Someone reading the migration stream will not necessarily read the
Xenstore protocol. So I think we should either make them explicit in the
documentation or have a link to the other document.
And even with
Re: [PATCH] xen/arm: regs: Fix MISRA C 2012 Rule 20.7 violation
Hi Xenia, > On 8 Aug 2022, at 10:48 am, Xenia Ragiadakou wrote: > > In macro psr_mode(), the macro parameter 'm' is used as expression and > therefore it is good to be enclosed in parentheses to prevent against > unintended expansions. > > Signed-off-by: Xenia Ragiadakou Reviewed-by: Rahul Singh Regards, Rahul
Re: [PATCH 3/3] xen/sched: fix cpu hotplug
On 03.08.22 11:53, Jan Beulich wrote:
On 02.08.2022 15:36, Juergen Gross wrote:
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -419,6 +419,8 @@ static int cpupool_alloc_affin_masks(struct affinity_masks
*masks)
return 0;
free_cpumask_var(masks->hard);
+memset(masks, 0, sizeof(*masks));
FREE_CPUMASK_VAR()?
Oh, yes.
@@ -1031,10 +1041,23 @@ static int cf_check cpu_callback(
{
unsigned int cpu = (unsigned long)hcpu;
int rc = 0;
+static struct cpu_rm_data *mem;
When you mentioned your plan, I was actually envisioning a slightly
different model: Instead of doing the allocation at CPU_DOWN_PREPARE,
allocate a single instance during boot, which would never be freed.
Did you consider such, and it turned out worse? I guess the main
obstacle would be figuring an upper bound for sr->granularity, but
of course schedule_cpu_rm_alloc(), besides the allocations, also
does quite a bit of filling in values, which can't be done up front.
With sched-gran=socket sr->granularity can grow to above 100, so I'm
not sure we'd want to do that.
switch ( action )
{
case CPU_DOWN_FAILED:
+if ( system_state <= SYS_STATE_active )
+{
+if ( mem )
+{
+if ( memchr_inv(>affinity, 0, sizeof(mem->affinity)) )
+cpupool_free_affin_masks(>affinity);
I don't think the conditional is really needed - it merely avoids two
xfree(NULL) invocations at the expense of readability here. Plus -
Okay.
wouldn't this better be part of ...
+schedule_cpu_rm_free(mem, cpu);
... this anyway?
This would add a layering violation IMHO.
@@ -1042,12 +1065,32 @@ static int cf_check cpu_callback(
case CPU_DOWN_PREPARE:
/* Suspend/Resume don't change assignments of cpus to cpupools. */
if ( system_state <= SYS_STATE_active )
+{
rc = cpupool_cpu_remove_prologue(cpu);
+if ( !rc )
+{
+ASSERT(!mem);
+mem = schedule_cpu_rm_alloc(cpu);
+rc = mem ? cpupool_alloc_affin_masks(>affinity) : -ENOMEM;
Ah - here you actually want a non-boolean return value. No need to
change that then in the earlier patch (albeit of course a change
there could be easily accommodated here).
Along the lines of the earlier comment this 2nd allocation may also
want to move into schedule_cpu_rm_alloc(). If other users of the
function don't need the extra allocations, perhaps by adding a bool
parameter.
I could do that, but I still think this would pull cpupool specific needs
into sched/core.c.
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
[libvirt test] 172291: regressions - FAIL
flight 172291 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/172291/ 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 70768cda9740d1fbc4b95460247bc5384d7e31a1 baseline version: libvirt 2c846fa6bcc11929c9fb857a22430fb9945654ad Last test of basis 151777 2020-07-10 04:19:19 Z 759 days Failing since151818 2020-07-11 04:18:52 Z 758 days 740 attempts Testing same since 172221 2022-08-06 04:19:00 Z2 days3 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 Chris Mayo Christian Borntraeger Christian Ehrhardt Christian Kirbach Christian Schoenebeck 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 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 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 Olesya Gerasimenko Or Ozeri Orion Poplawski Pany Paolo Bonzini
Re: [PATCH 2/3] xen/sched: carve out memory allocation and freeing from schedule_cpu_rm()
On 03.08.22 11:25, Jan Beulich wrote:
On 02.08.2022 15:27, Juergen Gross wrote:
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -3190,6 +3190,66 @@ out:
return ret;
}
+static struct cpu_rm_data *schedule_cpu_rm_alloc(unsigned int cpu)
+{
+struct cpu_rm_data *data;
+struct sched_resource *sr;
const?
Yes.
+int idx;
While code is supposedly only being moved, I still question this not
being "unsigned int", the more that sr->granularity is "unsigned int"
as well. (Same then for the retained instance ofthe variable in the
original function.) Of course the loop in the error path then needs
writing differently.
I considered that and didn't want to change the loop. OTOH this seems
to be rather trivial, so I can do the switch.
+rcu_read_lock(_res_rculock);
+
+sr = get_sched_res(cpu);
+data = xzalloc_flex_struct(struct cpu_rm_data, sr, sr->granularity - 1);
Afaict xmalloc_flex_struct() would do here, as you fill all fields.
Okay.
+if ( !data )
+goto out;
+
+data->old_ops = sr->scheduler;
+data->vpriv_old = idle_vcpu[cpu]->sched_unit->priv;
+data->ppriv_old = sr->sched_priv;
At least from an abstract perspective, doesn't reading fields from
sr require the RCU lock to be held continuously (i.e. not dropping
it at the end of this function and re-acquiring it in the caller)?
+for ( idx = 0; idx < sr->granularity - 1; idx++ )
+{
+data->sr[idx] = sched_alloc_res();
+if ( data->sr[idx] )
+{
+data->sr[idx]->sched_unit_idle = sched_alloc_unit_mem();
+if ( !data->sr[idx]->sched_unit_idle )
+{
+sched_res_free(>sr[idx]->rcu);
+data->sr[idx] = NULL;
+}
+}
+if ( !data->sr[idx] )
+{
+for ( idx--; idx >= 0; idx-- )
+sched_res_free(>sr[idx]->rcu);
+xfree(data);
+data = NULL;
XFREE()?
Oh, right. Forgot about that possibility.
@@ -3198,53 +3258,22 @@ out:
*/
int schedule_cpu_rm(unsigned int cpu)
{
-void *ppriv_old, *vpriv_old;
-struct sched_resource *sr, **sr_new = NULL;
+struct sched_resource *sr;
+struct cpu_rm_data *data;
struct sched_unit *unit;
-struct scheduler *old_ops;
spinlock_t *old_lock;
unsigned long flags;
-int idx, ret = -ENOMEM;
+int idx = 0;
unsigned int cpu_iter;
+data = schedule_cpu_rm_alloc(cpu);
+if ( !data )
+return -ENOMEM;
+
rcu_read_lock(_res_rculock);
sr = get_sched_res(cpu);
-old_ops = sr->scheduler;
-if ( sr->granularity > 1 )
-{
This conditional is lost afaict, resulting in potentially wrong behavior
in the new helper. Considering its purpose I expect there's a guarantee
that the field's value can never be zero, but then I guess an ASSERT()
would be nice next to the potentially problematic uses in the helper.
I'll add the ASSERT().
--- a/xen/common/sched/private.h
+++ b/xen/common/sched/private.h
@@ -598,6 +598,14 @@ struct affinity_masks {
cpumask_var_t soft;
};
+/* Memory allocation related data for schedule_cpu_rm(). */
+struct cpu_rm_data {
+struct scheduler *old_ops;
const?
Yes.
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v1 7/7] tools/ocaml/libs/eventchn: do not leak event channels and OCaml 5.0 compat
On 08/08/2022 09:28, Edwin Torok wrote:
>> On 5 Aug 2022, at 19:06, Andrew Cooper wrote:
>>
>> On 29/07/2022 18:53, Edwin Török wrote:
>>> +};
>>>
>>> CAMLprim value stub_eventchn_init(void)
>>> {
>>> @@ -48,7 +71,9 @@ CAMLprim value stub_eventchn_init(void)
>>> if (xce == NULL)
>>> caml_failwith("open failed");
>>>
>>> - result = (value)xce;
>>> + /* contains file descriptors, trigger full GC at least every 128
>>> allocations */
>>> + result = caml_alloc_custom(_ops, sizeof(xce), 1, 128);
>> The memory allocated for xce is tiny (48 bytes) and invariant for the
>> lifetime of the evtchn object, which we've already established tends to
>> operate as a singleton anyway.
>>
>> Don't we want to use the recommended 0 and 1 here?
> It is not just about the memory itself, but also about the file descriptors:
> those are a limited resource,
> and if we use the 0 and 1 it means that this will be garbage collected very
> infrequently since the allocation itself is very small,
> and you could potentially run out of file descriptors if you keep opening new
> event channels.
> Notice there is no API for the user to close the event channel, so it has to
> rely on the GC, which is not ideal.
>
> The mirage version of the eventchn lib does provide a close function:
> https://github.com/mirage/ocaml-evtchn/blob/main/lib/eventchn.mli,
> although its implementation just leaks it (to avoid use-after-free):
> https://github.com/mirage/ocaml-evtchn/blob/main/lib/eventchn.ml#L42
>
> Are event channel always expected to be singletons, is there a valid use case
> where you'd want more than 1 event channel/process?
Careful on terminology. We're discussing an open /dev/xen/evtchn file
handle, upon which an arbitrary number of event channels are muliplexed.
There's no good reason to have more than one file handle open, and
there's no good reason to close it except during shutdown.
So 0 and 1 are probably the right values in this case.
~Andrew
[ovmf test] 172294: regressions - FAIL
flight 172294 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/172294/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136 build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136 version targeted for testing: ovmf cf02322c984a16fc2af252124df96564e574f3a7 baseline version: ovmf 444260d45ec2a84e8f8c192b3539a3cd5591d009 Last test of basis 172136 2022-08-04 06:43:42 Z4 days Failing since172151 2022-08-05 02:40:28 Z3 days 31 attempts Testing same since 172247 2022-08-06 15:41:48 Z1 days 17 attempts People who touched revisions under test: Czajkowski, Maciej Edward Pickup Konstantin Aladyshev Maciej Czajkowski 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. commit cf02322c984a16fc2af252124df96564e574f3a7 Author: Konstantin Aladyshev Date: Wed Jul 20 22:08:12 2022 +0800 BaseTools/GenSec: Support EFI_SECTION_FREEFORM_SUBTYPE_GUID sections Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit d241a09afbe4f472a5d7da5090dfc85046f2250f Author: Konstantin Aladyshev Date: Wed Jul 20 20:00:39 2022 +0800 BaseTools/VolInfo: Parse EFI_SECTION_FREEFORM_SUBTYPE_GUID header Print 'SubtypeGuid' field from the EFI_FREEFORM_SUBTYPE_GUID_SECTION structure. This value describes the raw data inside the section. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit f5f8c08db92d15c7a359a5eb3b0cc2545c945942 Author: Konstantin Aladyshev Date: Tue Jul 19 23:45:52 2022 +0800 BaseTools/VolInfo: Show FV section boundaries Currently there is no labels for start and end of the EFI_SECTION_FIRMWARE_VOLUME_IMAGE type section. Therefore it is not possible to see where the FV section ends and another section starts. Add labels for start and end of the FV sections to fix the issue. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit a0a03b51548e6fc7524b5aa9f8042cbabce6da1c Author: Konstantin Aladyshev Date: Tue Jul 19 22:27:10 2022 +0800 BaseTools/GenSec: Fix typo Fix typo in the help message. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit 3e599bbc105ff089b21b6024100d585a8c781328 Author: Edward Pickup Date: Thu Aug 4 10:20:50 2022 +0100 DynamicTablesPkg: Fix using RmrNodeCount unitlitialised Fix using RmrNodeCount uninitliased by initliasing it to zero. Also, add an additional check for ACPI version. This fixes a crash running on kvmtool. Signed-off-by: Edward Pickup Reviewed-by: Sami Mujawar commit a8f59e2eb44199040d2e1f747a6d950a25ed0984 Author: Czajkowski, Maciej Date: Tue Aug 2 01:00:09 2022 +0800 MdeModulePkg/AhciPei: Use PCI_DEVICE_PPI to manage AHCI device REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3907 This change modifies AhciPei library to allow usage both EDKII_PCI_DEVICE_PPI and EDKII_PEI_ATA_AHCI_HOST_CONTROLLER_PPI to manage ATA HDD working under AHCI mode. Cc: Hao A Wu Cc: Ray Ni Cc: Liming Gao Signed-off-by: Maciej Czajkowski Reviewed-by: Hao A Wu commit 86757f0b4750f672f346d955f89e5b76430ba6b4 Author: Czajkowski, Maciej Date: Tue Aug 2 01:00:08 2022 +0800 MdeModulePkg: Add EDKII_PCI_DEVICE_PPI definition REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3907 This commit introduces
[PATCH] xen/arm: regs: Fix MISRA C 2012 Rule 20.7 violation
In macro psr_mode(), the macro parameter 'm' is used as expression and
therefore it is good to be enclosed in parentheses to prevent against
unintended expansions.
Signed-off-by: Xenia Ragiadakou
---
xen/arch/arm/include/asm/regs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/include/asm/regs.h b/xen/arch/arm/include/asm/regs.h
index 794721a103..0693a68131 100644
--- a/xen/arch/arm/include/asm/regs.h
+++ b/xen/arch/arm/include/asm/regs.h
@@ -11,7 +11,7 @@
#include
#include
-#define psr_mode(psr,m) (((psr) & PSR_MODE_MASK) == m)
+#define psr_mode(psr,m) (((psr) & PSR_MODE_MASK) == (m))
static inline bool regs_mode_is_32bit(const struct cpu_user_regs *regs)
{
--
2.34.1
Re: [PATCH 7/8] xen: introduce xen-evtchn dom0less property
Hi Julien, > On 5 Aug 2022, at 5:14 pm, Julien Grall wrote: > > > > On 05/08/2022 17:10, Rahul Singh wrote: >> Hi , > > Hi Rahul, > >>> On 22 Jun 2022, at 3:38 pm, 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 >>> --- >>> docs/misc/arm/device-tree/booting.txt | 62 +++- >>> xen/arch/arm/domain_build.c | 139 ++ >>> xen/arch/arm/include/asm/domain.h | 1 + >>> xen/arch/arm/include/asm/setup.h | 1 + >>> xen/arch/arm/setup.c | 2 + >>> 5 files changed, 204 insertions(+), 1 deletion(-) >> I am waiting for a review for this patch and the next patch in the series >> before >> I send the next version. Sending this email as a gentle reminder. > > I wasn't planning to review this patch and the next one yet because this > looks mostly parsing. I think this is more important to get patch #1-#6 > correct first. Make sense, then I will send the next version of patches #1-#6 for review. Regards, Rahul > > Cheers, > > -- > Julien Grall
Re: [PATCH v1 7/7] tools/ocaml/libs/eventchn: do not leak event channels and OCaml 5.0 compat
> On 5 Aug 2022, at 19:06, Andrew Cooper wrote:
>
> On 29/07/2022 18:53, Edwin Török wrote:
>> Add a finalizer on the event channel value, so that it calls
>> `xenevtchn_close` when the value would be GCed.
>>
>> In practice oxenstored seems to be the only user of this,
>> and it creates a single global event channel only,
>> but freeing this could still be useful when run with OCAMLRUNPARAM=c
>>
>> The code was previously casting a C pointer to an OCaml value,
>> which should be avoided: OCaml 5.0 won't support it.
>> (all "naked" C pointers must be wrapped inside an OCaml value,
>> either an Abstract tag, or Nativeint, see the manual
>> https://ocaml.org/manual/intfc.html#ss:c-outside-head)
>>
>> Signed-off-by: Edwin Török
>
> So while this looks like a good improvement, don't we need to do it for
> all libraries, not just evtchn?
>
> It doesn't look as if Ocaml 5.0 is very far away.
There are 2 ways to make it safe: use a block with Abstract_tag, or a block
with Custom_tag:
https://v2.ocaml.org/manual/intfc.html#ss:c-outside-head
(technically it only ever was safe to use naked pointers for word-aligned
pointers previously, although malloc usually
ensures some minimal alignment).
There is a mode where the runtime can warn on stderr whenever naked pointers
are used (there is an opam switch for it,
or one can specify a flag during the compiler build time), but it only does so
when that codepath is hit,
not at build/link time.
A quick look at the libs:
* libs/mmap: uses Abstract_tag
* eventchn: fixed here to use Custom_tag
* libs/xc: needs fixing, stub_xc_interface_open
* libs/xl: uses Custom_tag (although it has other known issues (it should never
use caml_callbackN directly, but use caml_callbackN_exn, see
https://v2.ocaml.org/manual/intfc.html#ss:c-callbacks)
* libs/xentoollog: uses Custom_tag
So we need a patch for libs/xc.
>
>> ---
>> tools/ocaml/libs/eventchn/xeneventchn_stubs.c | 29 +--
>> 1 file changed, 27 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/ocaml/libs/eventchn/xeneventchn_stubs.c
>> b/tools/ocaml/libs/eventchn/xeneventchn_stubs.c
>> index f889a7a2e4..c0d57e2954 100644
>> --- a/tools/ocaml/libs/eventchn/xeneventchn_stubs.c
>> +++ b/tools/ocaml/libs/eventchn/xeneventchn_stubs.c
>> @@ -33,7 +33,30 @@
>> #include
>> #include
>>
>> -#define _H(__h) ((xenevtchn_handle *)(__h))
>> +/* We want to close the event channel when it is no longer in use,
>> + which can only be done safely with a finalizer.
>> + Event channels are typically long lived, so we don't need tighter
>> control over resource deallocation.
>> + Use a custom block
>> +*/
>> +
>> +/* Access the xenevtchn_t* part of the OCaml custom block */
>> +#define _H(__h) (*((xenevtchn_handle**)Data_custom_val(__h)))
>> +
>> +static void stub_evtchn_finalize(value v)
>> +{
>> +/* docs say to not use any CAMLparam* macros here */
>> +xenevtchn_close(_H(v));
>> +}
>> +
>> +static struct custom_operations xenevtchn_ops = {
>> +"xenevtchn",
>> +stub_evtchn_finalize,
>> +custom_compare_default, /* raises Failure, cannot compare */
>> +custom_hash_default, /* ignored */
>> +custom_serialize_default, /* raises Failure, can't serialize */
>> +custom_deserialize_default, /* raises Failure, can't deserialize */
>> +custom_compare_ext_default /* raises Failure */
>
> This wants to gain a trailing comma.
>
>> +};
>>
>> CAMLprim value stub_eventchn_init(void)
>> {
>> @@ -48,7 +71,9 @@ CAMLprim value stub_eventchn_init(void)
>> if (xce == NULL)
>> caml_failwith("open failed");
>>
>> -result = (value)xce;
>> +/* contains file descriptors, trigger full GC at least every 128
>> allocations */
>> +result = caml_alloc_custom(_ops, sizeof(xce), 1, 128);
>
> The memory allocated for xce is tiny (48 bytes) and invariant for the
> lifetime of the evtchn object, which we've already established tends to
> operate as a singleton anyway.
>
> Don't we want to use the recommended 0 and 1 here?
It is not just about the memory itself, but also about the file descriptors:
those are a limited resource,
and if we use the 0 and 1 it means that this will be garbage collected very
infrequently since the allocation itself is very small,
and you could potentially run out of file descriptors if you keep opening new
event channels.
Notice there is no API for the user to close the event channel, so it has to
rely on the GC, which is not ideal.
The mirage version of the eventchn lib does provide a close function:
https://github.com/mirage/ocaml-evtchn/blob/main/lib/eventchn.mli,
although its implementation just leaks it (to avoid use-after-free):
https://github.com/mirage/ocaml-evtchn/blob/main/lib/eventchn.ml#L42
Are event channel always expected to be singletons, is there a valid use case
where you'd want more than 1 event channel/process?
Best regards,
--Edwin
[ovmf test] 172292: regressions - FAIL
flight 172292 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/172292/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172136 build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136 version targeted for testing: ovmf cf02322c984a16fc2af252124df96564e574f3a7 baseline version: ovmf 444260d45ec2a84e8f8c192b3539a3cd5591d009 Last test of basis 172136 2022-08-04 06:43:42 Z4 days Failing since172151 2022-08-05 02:40:28 Z3 days 30 attempts Testing same since 172247 2022-08-06 15:41:48 Z1 days 16 attempts People who touched revisions under test: Czajkowski, Maciej Edward Pickup Konstantin Aladyshev Maciej Czajkowski 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. commit cf02322c984a16fc2af252124df96564e574f3a7 Author: Konstantin Aladyshev Date: Wed Jul 20 22:08:12 2022 +0800 BaseTools/GenSec: Support EFI_SECTION_FREEFORM_SUBTYPE_GUID sections Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit d241a09afbe4f472a5d7da5090dfc85046f2250f Author: Konstantin Aladyshev Date: Wed Jul 20 20:00:39 2022 +0800 BaseTools/VolInfo: Parse EFI_SECTION_FREEFORM_SUBTYPE_GUID header Print 'SubtypeGuid' field from the EFI_FREEFORM_SUBTYPE_GUID_SECTION structure. This value describes the raw data inside the section. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit f5f8c08db92d15c7a359a5eb3b0cc2545c945942 Author: Konstantin Aladyshev Date: Tue Jul 19 23:45:52 2022 +0800 BaseTools/VolInfo: Show FV section boundaries Currently there is no labels for start and end of the EFI_SECTION_FIRMWARE_VOLUME_IMAGE type section. Therefore it is not possible to see where the FV section ends and another section starts. Add labels for start and end of the FV sections to fix the issue. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit a0a03b51548e6fc7524b5aa9f8042cbabce6da1c Author: Konstantin Aladyshev Date: Tue Jul 19 22:27:10 2022 +0800 BaseTools/GenSec: Fix typo Fix typo in the help message. Signed-off-by: Konstantin Aladyshev Reviewed-by: Bob Feng commit 3e599bbc105ff089b21b6024100d585a8c781328 Author: Edward Pickup Date: Thu Aug 4 10:20:50 2022 +0100 DynamicTablesPkg: Fix using RmrNodeCount unitlitialised Fix using RmrNodeCount uninitliased by initliasing it to zero. Also, add an additional check for ACPI version. This fixes a crash running on kvmtool. Signed-off-by: Edward Pickup Reviewed-by: Sami Mujawar commit a8f59e2eb44199040d2e1f747a6d950a25ed0984 Author: Czajkowski, Maciej Date: Tue Aug 2 01:00:09 2022 +0800 MdeModulePkg/AhciPei: Use PCI_DEVICE_PPI to manage AHCI device REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3907 This change modifies AhciPei library to allow usage both EDKII_PCI_DEVICE_PPI and EDKII_PEI_ATA_AHCI_HOST_CONTROLLER_PPI to manage ATA HDD working under AHCI mode. Cc: Hao A Wu Cc: Ray Ni Cc: Liming Gao Signed-off-by: Maciej Czajkowski Reviewed-by: Hao A Wu commit 86757f0b4750f672f346d955f89e5b76430ba6b4 Author: Czajkowski, Maciej Date: Tue Aug 2 01:00:08 2022 +0800 MdeModulePkg: Add EDKII_PCI_DEVICE_PPI definition REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3907 This commit introduces
[linux-linus test] 172285: regressions - FAIL
flight 172285 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/172285/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172133 build-i386-libvirt6 libvirt-buildfail REGR. vs. 172133 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 172133 build-armhf-libvirt 6 libvirt-buildfail 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-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-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 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-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 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-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 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-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-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 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-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-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 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: linux3bc1bc0b59d04e997db25b84babf459ca1cd80b7 baseline version: linuxb44f2fd87919b5ae6e1756d4c7ba2cbba22238e1 Last test of basis 172133 2022-08-04 05:14:48 Z4 days Failing since172152 2022-08-05 04:01:26 Z3 days 10 attempts Testing same since 172285 2022-08-08 00:39:37 Z0 days1 attempts 1071 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64
Re: [PATCH v3 5/5] tools/xenstore: add migration stream extensions for new features
On 04.08.22 21:28, Julien Grall wrote:
Hi,
On 03/08/2022 12:59, 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
Signed-off-by: Juergen Gross
---
V3:
- new patch
---
docs/designs/xenstore-migration.md | 85 --
1 file changed, 82 insertions(+), 3 deletions(-)
diff --git a/docs/designs/xenstore-migration.md
b/docs/designs/xenstore-migration.md
index efa526f420..b2b1d3d5c7 100644
--- a/docs/designs/xenstore-migration.md
+++ b/docs/designs/xenstore-migration.md
@@ -43,7 +43,13 @@ the setting of the endianness bit.
|---|---|
| `ident` | 0x78656e73746f7265 ('xenstore' in ASCII) |
| | |
-| `version` | 0x0001 (the version of the specification) |
+| `version` | The version of the specification, defined values: |
+| | 0x0001: all fields without any explicitly |
+| | mentioned version dependency are |
+| | valid. |
+| | 0x0002: all fields valid for version 1 plus |
+| | fields explicitly stated to be |
+| | supported in version 2 are valid. |
I am a bit concerned with the bump of the versions. It means, it will be
necessary for Xenstored to know whether the new Xenstored speaks v1 or v2. This
is less an issue when Live-Migration (although there is a fleet management
problem) but it will be one for Live-Update if we need to rollback.
So I am wondering if we can avoid to bump the version and use other means to
detect the difference.
In the end this is exactly what the version was meant to be used for.
I think it would make much more sense to think about the way to handle a
bump of the version in a compatible way.
My idea was to add a xenstored command line parameter for limiting the
migration stream version to be used to a specified version, causing new
features probably to not be available, though.
I don't see how e.g. a rollback would be doable in case a domain already
started to use a new feature like the third parameter when setting a watch.
Even if we'd drop the depth information when rolling back a watch set
afterwards with an additional depth added would be rejected by the older
xenstored, which would be unexpected failure for the guest.
It might make sense to try to use the V1 stream when doing a live update,
e.g. covering the case when the SET_FEATURE command was used for each
active guest to limit the features to V1 compatible ones. A force parameter
might be used to use the V1 stream even if guests are using V2 features,
risking breakage of those guests.
| | |
| `flags` | 0 (LSB): Endianness: 0 = little, 1 = big |
| | |
@@ -117,7 +123,17 @@ xenstored state that needs to be restored.
| rw-socket-fd |
+---+
| evtchn-fd |
++---+---+
+| n-dom-quota | n-glob-quota |
++---+---+
+| quota-val 1 |
++---+
+...
+---+
+| quota-val N |
++---+
+| quota-names
+...
```
@@ -128,6 +144,22 @@ xenstored state that needs to be restored.
| | |
| `evtchn-fd` | The file descriptor used to communicate with |
| | the event channel driver |
+| | |
+| `n-dom-quota` | Number of quota values which apply per |
+| | domain. Valid only for version 2 and later. |
+| | |
I think we can avoid extending the structure here by creating a separate record
for the quota.
With that, the new Xenstored don't need specific code to deal with rollback
because, as AFAICT, unimplemented records are ignored by existing Xenstored.
For quota this would be possible regarding the functionality, but there are
use cases which might suffer in case quota are not being accepted by the
new instance (e.g. driver domains needing higher quota).
OTOH this is no guest visible interface, so I'm on the edge to add this
data to V1. This would even be possible using the global record of V1, as
the length information of the record allows to add new fields without
having to bump the version.
+| `n-glob-quota` | Number of quota values which apply globally |
+| | only. Valid only for version 2 and later. |
+| |
