IGD pass-through failures since 4.10.
Good morning, I hope the week is starting well for everyone. We've made extensive use of PCI based graphics pass through for many years, since around Xen 4.2. In fact, we maintained a set of patches for ATI cards against qemu-traditional that have seen a lot of downloads from our FTP site. We ended up switching to IGD based graphics a couple of years ago and built a stack on top of Xen 4.10 using qemu-traditional. That coincided with our transition from Windows 7 to Windows 10. We've never enjoyed anywhere near the stability with IGD/Windows-10 that we had with the ATI/Windows-7 desktops, ie. we see fairly frequent crashes, lockups, reduced performance etc. The ATI/Windows-y desktops were almost astonishingly reliable, ie. hundreds of consecutive Windows VM boot/passthrough cycles. In order to try and address this issue we set out to upgrade our workstation infrastructure. Unfortunately we haven't found anything that has worked post 4.10. To be precise, 4.11 with qemu-traditional works, but upon exit from the virtual machine, to which the graphics adapter and USB controller are passed through to, both the USB controller and the graphics controller cannot be re-initialized and re-attached to the Dom0 instance. It appears to be a problem with mapping interrupts back to dom0 given that we see the following: Feb 10 08:16:05 hostname kernel: xhci_hcd :00:14.0: xen map irq failed -19 for 32752 domain Feb 10 08:16:05 hostname kernel: i915 :00:02.0: xen map irq failed -19 for 32752 domain Feb 10 08:16:12 hostname kernel: xhci_hcd :00:14.0: Error while assigning device slot ID At which point the monitor has green and block bars on it and the USB controller doesn't function. Upstream QEMU doesn't work at all, the qemu-system-i386 process fails and is caught by xl and then tries to re-start the domain, which remains dead to the world and has to be destroyed. We revved up to the most current 4.14.x release, but that acts exactly the same way that 4.11.x does. We've built up the most recent 4.15.x release, so that we would be testing the most current release that still supports qemu-traditional, but haven't been able to get the testing done yet. Given our current experiences, I would be surpised if it would work. We've tentatively tracked the poor Windows 10 performance down to the hypervisor emitting hundreds of thousands of IOMMU/DMA violations. We made those go away by disabling the IGD IOMMU but that doesn't fix the problem with upstream QEMU being able to boot the Windows instance, nor does it fix the problem with remapping the device interrupts back to Dom0 on domain exit. The 4.10 based stack had been running with 16 GIG of memory in the DomU Windows instances. Based on some online comments, we tested guests with 4 GIG of RAM but that doesn't impact the issues we are seeing. We've tested with the most recent 5.4 and 5.10 Linux kernels but the Dom0 kernel version doesn't seem to have any impact on the issues we are seeing. We'd be interested in any comments/suggestions the group may have. We have the in-house skills to do fairly significant investigations and would like to improve the performance of IGD pass-through for other users of what is fairly useful and ubiquitious (IGD) technology. Have a good day. Dr. Greg As always, Dr. Greg Wettstein, Ph.D, Worker Autonomously self-defensive Enjellic Systems Development, LLC IOT platforms and edge devices. 4206 N. 19th Ave. Fargo, ND 58102 PH: 701-281-1686 EMAIL: d...@enjellic.com -- "My thoughts on the composition and effectiveness of the advisory committee? I think they are destined to accomplish about the same thing as what you would get from locking 9 chimpanzees in a room with an armed thermonuclear weapon and a can opener with orders to disarm it." -- Dr. Greg Wettstein Resurrection
Re: [PATCH] vpci: introduce per-domain lock to protect vpci structure
On 11.02.22 17:44, Roger Pau Monné wrote:
> On Fri, Feb 11, 2022 at 12:13:38PM +, Oleksandr Andrushchenko wrote:
>>
>> On 11.02.22 13:40, Roger Pau Monné wrote:
>>> On Fri, Feb 11, 2022 at 07:27:39AM +, Oleksandr Andrushchenko wrote:
Hi, Roger!
On 10.02.22 18:16, Roger Pau Monné wrote:
> On Wed, Feb 09, 2022 at 03:36:27PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Introduce a per-domain read/write lock to check whether vpci is present,
>> so we are sure there are no accesses to the contents of the vpci struct
>> if not. This lock can be used (and in a few cases is used right away)
>> so that vpci removal can be performed while holding the lock in write
>> mode. Previously such removal could race with vpci_read for example.
> Sadly there's still a race in the usage of pci_get_pdev_by_domain wrt
> pci_remove_device, and likely when vPCI gets also used in
> {de}assign_device I think.
Yes, this is indeed an issue, but I was not trying to solve it in
context of vPCI locking yet. I think we should discuss how do
we approach pdev locking, so I can create a patch for that.
that being said, I would like not to solve pdev in this patch yet
...I do understand we do want to avoid that, but at the moment
a single reliable way for making sure pdev is alive seems to
be pcidevs_lock
>>> I think we will need to make pcidevs_lock a rwlock and take it in read
>>> mode for pci_get_pdev_by_domain.
>>>
>>> We didn't have this scenario before where PCI emulation is done in the
>>> hypervisor, and hence the locking around those data structures has not
>>> been designed for those use-cases.
>> Yes, I do understand that.
>> I hope pcidevs lock move to rwlock can be done as a separate
>> patch. While this is not done, do you think we can proceed with
>> vPCI series and pcidevs locking re-work being done after?
> Ideally we would like to sort out the locking once and for all. I
> would like to be sure that what we introduce now doesn't turn out to
> interact badly when we decide to look at the pcidevs locking issue.
Ok, so I'll start converting pcidevs into rwlock then
>
> Thanks, Roger.
Thank you,
Oleksandr
[linux-linus test] 168103: trouble: blocked/broken/fail/pass
flight 168103 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/168103/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-pvopsbroken build-arm64-xsm broken test-armhf-armhf-libvirt-qcow2 broken build-arm64-xsm 4 host-install(4)broken REGR. vs. 168080 build-arm64 4 host-install(4)broken REGR. vs. 168080 build-arm64-pvops 4 host-install(4)broken REGR. vs. 168080 test-armhf-armhf-libvirt-qcow2 5 host-install(5) broken REGR. vs. 168080 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 168080 test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 168080 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168080 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 168080 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 168080 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 168080 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168080 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 168080 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 168080 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail 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-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-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: linux754e0b0e35608ed5206d6a67a791563c631cec07 baseline version: linuxf1baf68e1383f6ed93eb9cff2866d46562607a43 Last test of basis 168080 2022-02-11 00:09:22 Z3 days Failing since168086 2022-02-11 20:11:19 Z2 days6 attempts Testing same since 168103 2022-02-13 21:41:20 Z0 days1 attempts People who touched revisions under test: Aaron Liu Adam Ford Al Cooper Alex Deucher Alexander Egorenkov Alexander Gordeev Alexander Stein Alexandre Ghiti Alim Akhtar Alviro Iskandar Setiawan Ammar Faizi Andreas Gruenbacher Andrew
[PATCH v6 09/11] xen/arm: if direct-map domain use native addresses for GICv3
From: Stefano Stabellini
Today we use native addresses to map the GICv3 for Dom0 and fixed
addresses for DomUs.
This patch changes the behavior so that native addresses are used for
all domain which is using the host memory layout
Considering that DOM0 may not always be directly mapped in the future,
this patch introduces a new helper "domain_use_host_layout()" that
wraps both two check "is_domain_direct_mapped(d) || is_hardware_domain(d)"
for more flexible usage.
Signed-off-by: Stefano Stabellini
Signed-off-by: Penny Zheng
Reviewed-by: Julien Grall
Tested-by: Stefano Stabellini
---
v2 changes:
- remove redistributor accessor
- introduce new helper "is_domain_use_host_layout()"
- comment fix
---
v3 changes:
- the comment on top of 'buf' to explain how 38 was found
- fix res getting overwritten
- drop 'cells += (GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS)'
- free 'reg' right way
- fix comment
- rename 'is_domain_use_host_layout()' to 'domain_use_host_layout()'
---
v4 changes:
- refine comment
---
v5 changes:
- nothing changed
---
v6 changes:
- refine comment
---
xen/arch/arm/domain_build.c | 34 +++
xen/arch/arm/include/asm/domain.h | 14 +
xen/arch/arm/vgic-v3.c| 30 ++-
3 files changed, 56 insertions(+), 22 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index a01dc60b55..cff2cb93cc 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2327,10 +2327,16 @@ static int __init make_gicv3_domU_node(struct
kernel_info *kinfo)
{
void *fdt = kinfo->fdt;
int res = 0;
-__be32 reg[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) * 2];
-__be32 *cells;
+__be32 *reg, *cells;
+const struct domain *d = kinfo->d;
+/* Placeholder for interrupt-controller@ + a 64-bit number + \0 */
+char buf[38];
+unsigned int i, len = 0;
+
+snprintf(buf, sizeof(buf), "interrupt-controller@%"PRIx64,
+ vgic_dist_base(>arch.vgic));
-res = fdt_begin_node(fdt,
"interrupt-controller@"__stringify(GUEST_GICV3_GICD_BASE));
+res = fdt_begin_node(fdt, buf);
if ( res )
return res;
@@ -2350,13 +2356,25 @@ static int __init make_gicv3_domU_node(struct
kernel_info *kinfo)
if ( res )
return res;
-cells = [0];
-dt_child_set_range(, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
- GUEST_GICV3_GICD_BASE, GUEST_GICV3_GICD_SIZE);
+/* reg specifies all re-distributors and Distributor. */
+len = (GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) *
+ (d->arch.vgic.nr_regions + 1) * sizeof(__be32);
+reg = xmalloc_bytes(len);
+if ( reg == NULL )
+return -ENOMEM;
+cells = reg;
+
dt_child_set_range(, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
- GUEST_GICV3_GICR0_BASE, GUEST_GICV3_GICR0_SIZE);
+ vgic_dist_base(>arch.vgic), GUEST_GICV3_GICD_SIZE);
-res = fdt_property(fdt, "reg", reg, sizeof(reg));
+for ( i = 0; i < d->arch.vgic.nr_regions; i++ )
+dt_child_set_range(,
+ GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
+ d->arch.vgic.rdist_regions[i].base,
+ d->arch.vgic.rdist_regions[i].size);
+
+res = fdt_property(fdt, "reg", reg, len);
+xfree(reg);
if (res)
return res;
diff --git a/xen/arch/arm/include/asm/domain.h
b/xen/arch/arm/include/asm/domain.h
index aabe942cde..c56f6e4398 100644
--- a/xen/arch/arm/include/asm/domain.h
+++ b/xen/arch/arm/include/asm/domain.h
@@ -31,6 +31,20 @@ enum domain_type {
#define is_domain_direct_mapped(d) (d)->arch.directmap
+/*
+ * Is the domain using the host memory layout?
+ *
+ * Direct-mapped domain will always have the RAM mapped with GFN == MFN.
+ * To avoid any trouble finding space, it is easier to force using the
+ * host memory layout.
+ *
+ * The hardware domain will use the host layout regardless of
+ * direct-mapped because some OS may rely on a specific address ranges
+ * for the devices.
+ */
+#define domain_use_host_layout(d) (is_domain_direct_mapped(d) || \
+ is_hardware_domain(d))
+
struct vtimer {
struct vcpu *v;
int irq;
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 65bb7991a6..e4ba9a6476 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1640,14 +1640,15 @@ static inline unsigned int
vgic_v3_max_rdist_count(struct domain *d)
* Normally there is only one GICv3 redistributor region.
* The GICv3 DT binding provisions for multiple regions, since there are
* platforms out there which need those (multi-socket systems).
- * For Dom0 we have to live with the MMIO layout the hardware provides,
- * so we have to copy the multiple regions - as the first region may not
- * provide enough space to hold all
[PATCH v6 11/11] xen/docs: Document how to do passthrough without IOMMU
From: Stefano Stabellini
This commit creates a new doc to document how to do passthrough without IOMMU.
Signed-off-by: Stefano Stabellini
Signed-off-by: Penny Zheng
Acked-by: Julien Grall
Tested-by: Stefano Stabellini
---
v2 changes:
- nothing changed
---
v3 changes:
- nothing changed
---
v4 changes:
- nothing changed
---
v5 changes:
- nothing changed
---
v6 changes:
- nothing changed
---
docs/misc/arm/passthrough-noiommu.txt | 52 +++
1 file changed, 52 insertions(+)
create mode 100644 docs/misc/arm/passthrough-noiommu.txt
diff --git a/docs/misc/arm/passthrough-noiommu.txt
b/docs/misc/arm/passthrough-noiommu.txt
new file mode 100644
index 00..3e2ef21ad7
--- /dev/null
+++ b/docs/misc/arm/passthrough-noiommu.txt
@@ -0,0 +1,52 @@
+Request Device Assignment without IOMMU support
+===
+
+*WARNING:
+Users should be aware that it is not always secure to assign a device without
+IOMMU protection.
+When the device is not protected by the IOMMU, the administrator should make
+sure that:
+ 1. The device is assigned to a trusted guest.
+ 2. Users have additional security mechanism on the platform.
+
+This document assumes that the IOMMU is absent from the system or it is
+disabled (status = "disabled" in device tree).
+
+Add xen,force-assign-without-iommu; to the device tree snippet:
+
+ethernet: ethernet@ff0e {
+ compatible = "cdns,zynqmp-gem";
+ xen,path = "/amba/ethernet@ff0e";
+ xen,reg = <0x0 0xff0e 0x1000 0x0 0xff0e>;
+ xen,force-assign-without-iommu;
+};
+
+Request 1:1 memory mapping for the domain on static allocation
+==
+
+Add a direct-map property under the appropriate /chosen/domU node which
+is also statically allocated with physical memory ranges through
+xen,static-mem property as its guest RAM.
+
+Below is an example on how to specify the 1:1 memory mapping for the domain
+on static allocation in the device-tree:
+
+/ {
+ chosen {
+ domU1 {
+ compatible = "xen,domain";
+ #address-cells = <0x2>;
+ #size-cells = <0x2>;
+ cpus = <2>;
+ memory = <0x0 0x8>;
+ #xen,static-mem-address-cells = <0x1>;
+ #xen,static-mem-size-cells = <0x1>;
+ xen,static-mem = <0x3000 0x2000>;
+ direct-map;
+ ...
+ };
+ };
+};
+
+Besides reserving a 512MB region starting at the host physical address
+0x3000 to DomU1, it also requests 1:1 memory mapping.
--
2.25.1
[PATCH v6 08/11] xen/arm: gate make_gicv3_domU_node with CONFIG_GICV3
This commit gates function make_gicv3_domU_node with CONFIG_GICV3.
Signed-off-by: Penny Zheng
Acked-by: Stefano Stabellini
Tested-by: Stefano Stabellini
---
v4 changes:
- remove ASSERT_UNREACHABLE() to avoid breaking compilation on prod build with
CONFIG_GICV3=n
---
v5 changes:
- nothing changed
---
v6 changes:
- nothing changed
---
xen/arch/arm/domain_build.c | 4
1 file changed, 4 insertions(+)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 87391adde6..a01dc60b55 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2322,6 +2322,7 @@ static int __init make_gicv2_domU_node(struct kernel_info
*kinfo)
return res;
}
+#ifdef CONFIG_GICV3
static int __init make_gicv3_domU_node(struct kernel_info *kinfo)
{
void *fdt = kinfo->fdt;
@@ -2371,13 +2372,16 @@ static int __init make_gicv3_domU_node(struct
kernel_info *kinfo)
return res;
}
+#endif
static int __init make_gic_domU_node(struct kernel_info *kinfo)
{
switch ( kinfo->d->arch.vgic.version )
{
+#ifdef CONFIG_GICV3
case GIC_V3:
return make_gicv3_domU_node(kinfo);
+#endif
case GIC_V2:
return make_gicv2_domU_node(kinfo);
default:
--
2.25.1
[PATCH v6 10/11] xen/arm: if direct-map domain use native UART address and IRQ number for vPL011
From: Stefano Stabellini
We always use a fix address to map the vPL011 to domains. The address
could be a problem for direct-map domains.
So, for domains that are directly mapped, reuse the address of the
physical UART on the platform to avoid potential clashes.
Do the same for the virtual IRQ number: instead of always using
GUEST_VPL011_SPI, try to reuse the physical SPI number if possible.
Signed-off-by: Stefano Stabellini
Signed-off-by: Penny Zheng
Reviewed-by: Julien Grall
Tested-by: Stefano Stabellini
---
v2 changes:
- explain why vpl011 initialization before creating its device tree node
- error out if the domain is direct-mapped and the IRQ is not found
- harden the code and add a check/comment when the hardware UART region
is smaller than GUEST_VPL011_SIZE.
---
v3 changes:
- explain how the '27' was found for 'buf'
- fix checking before dereferencing
- refine comment message
---
v4 changes:
- refine comment message
---
v5 changes:
- nothing changed
---
v6 changes:
- nothing changed
---
xen/arch/arm/domain_build.c | 44 +++
xen/arch/arm/include/asm/vpl011.h | 2 ++
xen/arch/arm/vpl011.c | 60 +++
3 files changed, 92 insertions(+), 14 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index cff2cb93cc..8be01678de 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -30,6 +30,7 @@
#include
#include
+#include
static unsigned int __initdata opt_dom0_max_vcpus;
integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
@@ -2415,8 +2416,12 @@ static int __init make_vpl011_uart_node(struct
kernel_info *kinfo)
gic_interrupt_t intr;
__be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS];
__be32 *cells;
+struct domain *d = kinfo->d;
+/* Placeholder for sbsa-uart@ + a 64-bit number + \0 */
+char buf[27];
-res = fdt_begin_node(fdt, "sbsa-uart@"__stringify(GUEST_PL011_BASE));
+snprintf(buf, sizeof(buf), "sbsa-uart@%"PRIx64, d->arch.vpl011.base_addr);
+res = fdt_begin_node(fdt, buf);
if ( res )
return res;
@@ -2426,14 +2431,14 @@ static int __init make_vpl011_uart_node(struct
kernel_info *kinfo)
cells = [0];
dt_child_set_range(, GUEST_ROOT_ADDRESS_CELLS,
- GUEST_ROOT_SIZE_CELLS, GUEST_PL011_BASE,
+ GUEST_ROOT_SIZE_CELLS, d->arch.vpl011.base_addr,
GUEST_PL011_SIZE);
res = fdt_property(fdt, "reg", reg, sizeof(reg));
if ( res )
return res;
-set_interrupt(intr, GUEST_VPL011_SPI, 0xf, DT_IRQ_TYPE_LEVEL_HIGH);
+set_interrupt(intr, d->arch.vpl011.virq, 0xf, DT_IRQ_TYPE_LEVEL_HIGH);
res = fdt_property(fdt, "interrupts", intr, sizeof (intr));
if ( res )
@@ -3145,6 +3150,14 @@ static int __init construct_domU(struct domain *d,
else
assign_static_memory_11(d, , node);
+/*
+ * Base address and irq number are needed when creating vpl011 device
+ * tree node in prepare_dtb_domU, so initialization on related variables
+ * shall be done first.
+ */
+if ( kinfo.vpl011 )
+rc = domain_vpl011_init(d, NULL);
+
rc = prepare_dtb_domU(d, );
if ( rc < 0 )
return rc;
@@ -3153,9 +3166,6 @@ static int __init construct_domU(struct domain *d,
if ( rc < 0 )
return rc;
-if ( kinfo.vpl011 )
-rc = domain_vpl011_init(d, NULL);
-
return rc;
}
@@ -3200,15 +3210,35 @@ void __init create_domUs(void)
if ( !dt_property_read_u32(node, "nr_spis", _cfg.arch.nr_spis) )
{
+unsigned int vpl011_virq = GUEST_VPL011_SPI;
+
d_cfg.arch.nr_spis = gic_number_lines() - 32;
+/*
+ * The VPL011 virq is GUEST_VPL011_SPI, unless direct-map is
+ * set, in which case it'll match the hardware.
+ *
+ * Since the domain is not yet created, we can't use
+ * d->arch.vpl011.irq. So the logic to find the vIRQ has to
+ * be hardcoded.
+ * The logic here shall be consistent with the one in
+ * domain_vpl011_init().
+ */
+if ( flags & CDF_directmap )
+{
+vpl011_virq = serial_irq(SERHND_DTUART);
+if ( vpl011_virq < 0 )
+panic("Error getting IRQ number for this serial port %d\n",
+ SERHND_DTUART);
+}
+
/*
* vpl011 uses one emulated SPI. If vpl011 is requested, make
* sure that we allocate enough SPIs for it.
*/
if ( dt_property_read_bool(node, "vpl011") )
d_cfg.arch.nr_spis = MAX(d_cfg.arch.nr_spis,
- GUEST_VPL011_SPI - 32 + 1);
+ vpl011_virq - 32 + 1);
}
/*
diff --git a/xen/arch/arm/include/asm/vpl011.h
[PATCH v6 06/11] xen/arm: add ASSERT_UNREACHABLE in allocate_static_memory
Helper allocate_static_memory is not meant to be reachable when built with
!CONFIG_STATIC_MEMORY, so this commit adds ASSERT_UNREACHABLE in it to catch
potential misuse.
Signed-off-by: Penny Zheng
Acked-by: Julien Grall
Tested-by: Stefano Stabellini
---
v3 changes:
- new commit
---
v4 changes:
- nothing changed
---
v5 changes:
- nothing changed
---
v6 changes:
- nothing changed
---
xen/arch/arm/domain_build.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index ec29bd302c..52f256de9c 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -755,6 +755,7 @@ static void __init allocate_static_memory(struct domain *d,
struct kernel_info *kinfo,
const struct dt_device_node *node)
{
+ASSERT_UNREACHABLE();
}
static void __init assign_static_memory_11(struct domain *d,
--
2.25.1
[PATCH v6 07/11] xen/arm: if direct-map domain use native addresses for GICv2
From: Stefano Stabellini
Today we use native addresses to map the GICv2 for Dom0 and fixed
addresses for DomUs.
This patch changes the behavior so that native addresses are used for
all domains that are direct-mapped.
NEW VGIC has different naming schemes, like referring distributor base
address as vgic_dist_base, other than the dbase. So this patch also introduces
vgic_dist_base/vgic_cpu_base accessor to access correct distributor base
address/cpu interface base address on varied scenarios,
Signed-off-by: Stefano Stabellini
Signed-off-by: Penny Zheng
Reviewed-by: Julien Grall
Tested-by: Stefano Stabellini
---
v2 changes
- combine all changes in patch 4-6 here
---
v3 changes
- refine comment message
- add a comment explaining how the 38 was found of "char buf[38]"
- simply map the CPU interface at the GPA vgic_v2_hw.cbase
- remove a spurious change
---
v4 changes:
- refine comment to let it be a summary of the if/else if/else.
---
v5 changes:
- nothing changed
---
v6 changes:
- nothing changed
---
xen/arch/arm/domain_build.c | 11 +++---
xen/arch/arm/include/asm/new_vgic.h | 10 +
xen/arch/arm/include/asm/vgic.h | 11 ++
xen/arch/arm/vgic-v2.c | 34 +++--
xen/arch/arm/vgic/vgic-v2.c | 34 +++--
5 files changed, 83 insertions(+), 17 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 52f256de9c..87391adde6 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2273,8 +2273,13 @@ static int __init make_gicv2_domU_node(struct
kernel_info *kinfo)
int res = 0;
__be32 reg[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) * 2];
__be32 *cells;
+const struct domain *d = kinfo->d;
+/* Placeholder for interrupt-controller@ + a 64-bit number + \0 */
+char buf[38];
-res = fdt_begin_node(fdt,
"interrupt-controller@"__stringify(GUEST_GICD_BASE));
+snprintf(buf, sizeof(buf), "interrupt-controller@%"PRIx64,
+ vgic_dist_base(>arch.vgic));
+res = fdt_begin_node(fdt, buf);
if ( res )
return res;
@@ -2296,9 +2301,9 @@ static int __init make_gicv2_domU_node(struct kernel_info
*kinfo)
cells = [0];
dt_child_set_range(, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
- GUEST_GICD_BASE, GUEST_GICD_SIZE);
+ vgic_dist_base(>arch.vgic), GUEST_GICD_SIZE);
dt_child_set_range(, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
- GUEST_GICC_BASE, GUEST_GICC_SIZE);
+ vgic_cpu_base(>arch.vgic), GUEST_GICC_SIZE);
res = fdt_property(fdt, "reg", reg, sizeof(reg));
if (res)
diff --git a/xen/arch/arm/include/asm/new_vgic.h
b/xen/arch/arm/include/asm/new_vgic.h
index 97d622bff6..ab57fcd91d 100644
--- a/xen/arch/arm/include/asm/new_vgic.h
+++ b/xen/arch/arm/include/asm/new_vgic.h
@@ -186,6 +186,16 @@ struct vgic_cpu {
uint32_t num_id_bits;
};
+static inline paddr_t vgic_cpu_base(const struct vgic_dist *vgic)
+{
+return vgic->vgic_cpu_base;
+}
+
+static inline paddr_t vgic_dist_base(const struct vgic_dist *vgic)
+{
+return vgic->vgic_dist_base;
+}
+
#endif /* __ASM_ARM_NEW_VGIC_H */
/*
diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/vgic.h
index ade427a808..d2a9fc7d83 100644
--- a/xen/arch/arm/include/asm/vgic.h
+++ b/xen/arch/arm/include/asm/vgic.h
@@ -152,6 +152,7 @@ struct vgic_dist {
struct pending_irq *pending_irqs;
/* Base address for guest GIC */
paddr_t dbase; /* Distributor base address */
+paddr_t cbase; /* CPU interface base address */
#ifdef CONFIG_GICV3
/* GIC V3 addressing */
/* List of contiguous occupied by the redistributors */
@@ -271,6 +272,16 @@ static inline int REG_RANK_NR(int b, uint32_t n)
enum gic_sgi_mode;
+static inline paddr_t vgic_cpu_base(const struct vgic_dist *vgic)
+{
+return vgic->cbase;
+}
+
+static inline paddr_t vgic_dist_base(const struct vgic_dist *vgic)
+{
+return vgic->dbase;
+}
+
/*
* Offset of GICD_ with its rank, for GICD_ size with
* -bits-per-interrupt.
diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 589c033eda..b1bd7a46ad 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -654,12 +654,16 @@ static int vgic_v2_vcpu_init(struct vcpu *v)
static int vgic_v2_domain_init(struct domain *d)
{
int ret;
-paddr_t cbase, csize;
+paddr_t csize;
paddr_t vbase;
/*
- * The hardware domain gets the hardware address.
- * Guests get the virtual platform layout.
+ * The hardware domain and direct-mapped domain both get the hardware
+ * address.
+ * We have to handle them separately because the hwdom is re-using the
+ * same Device-Tree as the host (see more details below).
+ *
+ * Other domains get the virtual platform layout.
*/
if ( is_hardware_domain(d) )
{
@@
[PATCH v6 05/11] xen/arm: introduce direct-map for domUs
Cases where domU needs direct-map memory map:
* IOMMU not present in the system.
* IOMMU disabled if it doesn't cover a specific device and all the guests
are trusted. Thinking a mixed scenario, where a few devices with IOMMU and
a few without, then guest DMA security still could not be totally guaranteed.
So users may want to disable the IOMMU, to at least gain some performance
improvement from IOMMU disabled.
* IOMMU disabled as a workaround when it doesn't have enough bandwidth.
To be specific, in a few extreme situation, when multiple devices do DMA
concurrently, these requests may exceed IOMMU's transmission capacity.
* IOMMU disabled when it adds too much latency on DMA. For example,
TLB may be missing in some IOMMU hardware, which may bring latency in DMA
progress, so users may want to disable it in some realtime scenario.
* Guest OS relies on the host memory layout
This commit introduces a new helper assign_static_memory_11 to allocate
static memory as guest RAM for direct-map domain.
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
Tested-by: Stefano Stabellini
---
v2 changes:
- split the common codes into two helpers: parse_static_mem_prop and
acquire_static_memory_bank to deduce complexity.
- introduce a new helper allocate_static_memory_11 for allocating static
memory for direct-map guests
- remove redundant use "bool direct_map", to be replaced by
d_cfg.flags & XEN_DOMCTL_CDF_directmap
- remove panic action since it is fine to assign a non-DMA capable device when
IOMMU and direct-map both off
---
v3 changes:
- doc refinement
- drop the pointless gbank
- add check of the size of nr_banks shall not exceed NR_MEM_BANKS
- add ASSERT_UNREACHABLE to catch any misuse
- add another check of validating flag XEN_DOMCTL_CDF_INTERNAL_directmap only
when CONFIG_STATIC_MEMORY is set.
---
v4 changes:
- comment refinement
- rename function allocate_static_memory_11() to assign_static_memory_11()
to make clear there is actually no allocation done. Instead we are only
mapping pre-defined host regions to pre-defined guest regions.
- remove tot_size to directly substract psize from kinfo->unassigned_mem
- check kinfo->unassigned_mem doesn't underflow or overflow
- remove nested if/else
- refine "panic" info
---
v5 changes:
- fix coding style
---
v6 changes:
- no changes
---
xen/arch/arm/domain_build.c | 97 +++--
1 file changed, 94 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index e61d2d53ba..ec29bd302c 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -494,8 +494,17 @@ static bool __init append_static_memory_to_bank(struct
domain *d,
{
int res;
unsigned int nr_pages = PFN_DOWN(size);
-/* Infer next GFN. */
-gfn_t sgfn = gaddr_to_gfn(bank->start + bank->size);
+gfn_t sgfn;
+
+/*
+ * For direct-mapped domain, the GFN match the MFN.
+ * Otherwise, this is inferred on what has already been allocated
+ * in the bank.
+ */
+if ( !is_domain_direct_mapped(d) )
+sgfn = gaddr_to_gfn(bank->start + bank->size);
+else
+sgfn = gaddr_to_gfn(mfn_to_maddr(smfn));
res = guest_physmap_add_pages(d, sgfn, smfn, nr_pages);
if ( res )
@@ -668,12 +677,92 @@ static void __init allocate_static_memory(struct domain
*d,
fail:
panic("Failed to allocate requested static memory for domain %pd.", d);
}
+
+/*
+ * Allocate static memory as RAM for one specific domain d.
+ * The static memory will be directly mapped in the guest(Guest Physical
+ * Address == Physical Address).
+ */
+static void __init assign_static_memory_11(struct domain *d,
+ struct kernel_info *kinfo,
+ const struct dt_device_node *node)
+{
+u32 addr_cells, size_cells, reg_cells;
+unsigned int nr_banks, bank = 0;
+const __be32 *cell;
+paddr_t pbase, psize;
+mfn_t smfn;
+int length;
+
+if ( parse_static_mem_prop(node, _cells, _cells, , )
)
+{
+printk(XENLOG_ERR
+ "%pd: failed to parse \"xen,static-mem\" property.\n", d);
+goto fail;
+}
+reg_cells = addr_cells + size_cells;
+nr_banks = length / (reg_cells * sizeof(u32));
+
+if ( nr_banks > NR_MEM_BANKS )
+{
+printk(XENLOG_ERR
+ "%pd: exceed max number of supported guest memory banks.\n", d);
+goto fail;
+}
+
+for ( ; bank < nr_banks; bank++ )
+{
+smfn = acquire_static_memory_bank(d, , addr_cells, size_cells,
+ , );
+if ( mfn_eq(smfn, INVALID_MFN) )
+goto fail;
+
+printk(XENLOG_INFO "%pd: STATIC BANK[%u] %#"PRIpaddr"-%#"PRIpaddr"\n",
+ d, bank, pbase, pbase + psize);
+
+/* One guest memory bank is matched with one physical memory bank. */
+kinfo->mem.bank[bank].start = pbase;
+if (
[PATCH v6 00/11] direct-map memory map
"direct-map" property shall be added under the appropriate domain node, when users requesting direct-map memory mapping for the domain. Right now, direct-map is only supported when domain on Static Allocation, that is, "xen,static-mem" is also necessary in the domain configuration. Looking into related [design link]( https://lists.xenproject.org/archives/html/xen-devel/2021-05/msg00882.html) for more details. The whole design is about Static Allocation and direct-map, and this Patch Serie only covers parts of it, which are direct-map memory map. Other features will be delievered through different patch series. See https://lists.xenproject.org/archives/html/xen-devel/2021-09/msg00855.html for Domain on Static Allocation. This patch serie is based on https://lists.xenproject.org/archives/html/xen-devel/2021-10/msg00822.html\ --- v6 changes: - comment, commit message and coding style fix - protect CDF_directmap with #ifdef CONFIG_ARM --- v5 changes: - remove const constraint and strict "static allocation" check - fix coding style --- v4 changes: - introduce internal const CDF_xxx flags for domain creation - introduce internal flag CDF_privileged - introduce new internal flag CDF_directmap - add a directmap flag under struct arch_domain and use it to reimplement is_domain_direct_mapped. - expand arch_domain_create/domain_create to include internal-only parameter "const unsigned int flags" - use mfn_eq() instead, because it is the only value used to indicate there is an error and this is more lightweight than mfn_valid() - rename function allocate_static_memory_11() to assign_static_memory_11() to make clear there is actually no allocation done. Instead we are only mapping pre-defined host regions to pre-defined guest regions. - remove tot_size to directly substract psize from kinfo->unassigned_mem - check kinfo->unassigned_mem doesn't underflow or overflow - remove nested if/else - remove ASSERT_UNREACHABLE() to avoid breaking compilation on prod build with CONFIG_GICV3=n - comment and commit message refinement --- v3 changes: - move flag XEN_DOMCTL_CDF_INTERNAL_directmap back to xen/include/xen/domain.h, to let it be only available for domain created by XEN. - name it with extra "INTERNAL" and add comments to warn developers not to accidently use its bitfield when introducing new XEN_DOMCTL_CDF_xxx flag. - reject this flag in x86'es arch_sanitise_domain_config() - add ASSERT_UNREACHABLE to catch any misuse in allocate_static_memory() and allocate_static_memory_11() - add another check of validating flag XEN_DOMCTL_CDF_INTERNAL_directmap only when CONFIG_STATIC_MEMORY is set. - simply map the CPU interface at the GPA vgic_v2_hw.cbase - drop 'cells += (GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS)' - rename 'is_domain_use_host_layout()' to 'domain_use_host_layout()' --- v2 changes: - remove the introduce of internal flag - Refine is_domain_direct_mapped to check whether the flag XEN_DOMCTL_CDF_directmap is set - reword "1:1 direct-map" to just "direct-map" - split the common codes into two helpers: parse_static_mem_prop and acquire_static_memory_bank to deduce complexity. - introduce a new helper allocate_static_memory_11 for allocating static memory for direct-map guests - remove panic action since it is fine to assign a non-DMA capable device when IOMMU and direct-map both off - remove redistributor accessor - introduce new helper "is_domain_use_host_layout()" - explain why vpl011 initialization before creating its device tree node - error out if the domain is direct-mapped and the IRQ is not found - harden the code and add a check/comment when the hardware UART region is smaller than CUEST_VPL011_SIZE. Penny Zheng (4): xen/arm: introduce new helper parse_static_mem_prop and acquire_static_memory_bank xen/arm: introduce direct-map for domUs xen/arm: add ASSERT_UNREACHABLE in allocate_static_memory xen/arm: gate make_gicv3_domU_node with CONFIG_GICV3 Stefano Stabellini (7): xen: introduce internal CDF_xxx flags for domain creation xen: introduce CDF_directmap xen/arm: Allow device-passthrough even the IOMMU is off xen/arm: if direct-map domain use native addresses for GICv2 xen/arm: if direct-map domain use native addresses for GICv3 xen/arm: if direct-map domain use native UART address and IRQ number for vPL011 xen/docs: Document how to do passthrough without IOMMU docs/misc/arm/device-tree/booting.txt | 6 + docs/misc/arm/passthrough-noiommu.txt | 52 + xen/arch/arm/domain.c | 5 +- xen/arch/arm/domain_build.c | 308 +- xen/arch/arm/include/asm/domain.h | 19 +- xen/arch/arm/include/asm/new_vgic.h | 10 + xen/arch/arm/include/asm/vgic.h | 11 + xen/arch/arm/include/asm/vpl011.h | 2 + xen/arch/arm/vgic-v2.c| 34 ++- xen/arch/arm/vgic-v3.c| 30 +-- xen/arch/arm/vgic/vgic-v2.c | 34 ++- xen/arch/arm/vpl011.c | 60 -
[PATCH v6 03/11] xen/arm: Allow device-passthrough even the IOMMU is off
From: Stefano Stabellini
At the moment, we are only supporting device-passthrough when Xen has
enabled the IOMMU. There are some use cases where it is not possible to
use the IOMMU (e.g. doesn't exist, hardware limitation, performance) yet
it would be OK to assign a device to trusted domain so long they are
direct-mapped or the device doesn't do DMA.
Note that when the IOMMU is disabled, it will be necessary to add
xen,force-assign-without-iommu for every device that needs to be assigned.
Signed-off-by: Stefano Stabellini
Signed-off-by: Penny Zheng
Tested-by: Stefano Stabellini
---
v3 changes:
- new commit, split from the original "[PATCH v2 2/6] xen/arm: introduce
direct-map for domUs"
---
v4 changes:
- explain briefly in the commit message why we want to do device assignment
without IOMMU.
---
v5 changes:
- nothing changed
---
v6 changes
- commit message refinement
---
xen/arch/arm/domain_build.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 6467e8ee32..c1e8c99f64 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -3047,7 +3047,8 @@ void __init create_domUs(void)
panic("Missing property 'cpus' for domain %s\n",
dt_node_name(node));
-if ( dt_find_compatible_node(node, NULL, "multiboot,device-tree") )
+if ( dt_find_compatible_node(node, NULL, "multiboot,device-tree") &&
+ iommu_enabled )
d_cfg.flags |= XEN_DOMCTL_CDF_iommu;
if ( !dt_property_read_u32(node, "nr_spis", _cfg.arch.nr_spis) )
--
2.25.1
[PATCH v6 04/11] xen/arm: introduce new helper parse_static_mem_prop and acquire_static_memory_bank
Later, we will introduce assign_static_memory_11 for allocating static
memory for direct-map domains, and it will share a lot common codes with
the existing allocate_static_memory.
In order not to bring a lot of duplicate codes, and also to make the whole
code more readable, this commit extracts common codes into two new helpers
parse_static_mem_prop and acquire_static_memory_bank.
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
Tested-by: Stefano Stabellini
---
v3 changes:
- new commit, split from the original "[PATCH v2 2/6] xen/arm: introduce
direct-map for domUs"
---
v4 changes
- explain briefly in the commit message why we want to do device assignment
without IOMMU.
---
v5 changes
- fix coding style
---
v6 changes
- no changes
---
xen/arch/arm/domain_build.c | 100 +++-
1 file changed, 64 insertions(+), 36 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c1e8c99f64..e61d2d53ba 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -509,12 +509,69 @@ static bool __init append_static_memory_to_bank(struct
domain *d,
return true;
}
+static mfn_t __init acquire_static_memory_bank(struct domain *d,
+ const __be32 **cell,
+ u32 addr_cells, u32 size_cells,
+ paddr_t *pbase, paddr_t *psize)
+{
+mfn_t smfn;
+int res;
+
+device_tree_get_reg(cell, addr_cells, size_cells, pbase, psize);
+ASSERT(IS_ALIGNED(*pbase, PAGE_SIZE) && IS_ALIGNED(*psize, PAGE_SIZE));
+if ( PFN_DOWN(*psize) > UINT_MAX )
+{
+printk(XENLOG_ERR "%pd: static memory size too large: %#"PRIpaddr,
+ d, *psize);
+return INVALID_MFN;
+}
+
+smfn = maddr_to_mfn(*pbase);
+res = acquire_domstatic_pages(d, smfn, PFN_DOWN(*psize), 0);
+if ( res )
+{
+printk(XENLOG_ERR
+ "%pd: failed to acquire static memory: %d.\n", d, res);
+return INVALID_MFN;
+}
+
+return smfn;
+}
+
+static int __init parse_static_mem_prop(const struct dt_device_node *node,
+u32 *addr_cells, u32 *size_cells,
+int *length, const __be32 **cell)
+{
+const struct dt_property *prop;
+
+prop = dt_find_property(node, "xen,static-mem", NULL);
+if ( !dt_property_read_u32(node, "#xen,static-mem-address-cells",
+ addr_cells) )
+{
+printk(XENLOG_ERR
+ "failed to read \"#xen,static-mem-address-cells\".\n");
+return -EINVAL;
+}
+
+if ( !dt_property_read_u32(node, "#xen,static-mem-size-cells",
+ size_cells) )
+{
+printk(XENLOG_ERR
+ "failed to read \"#xen,static-mem-size-cells\".\n");
+return -EINVAL;
+}
+
+*cell = (const __be32 *)prop->value;
+*length = prop->length;
+
+return 0;
+}
+
/* Allocate memory from static memory as RAM for one specific domain d. */
static void __init allocate_static_memory(struct domain *d,
struct kernel_info *kinfo,
const struct dt_device_node *node)
{
-const struct dt_property *prop;
u32 addr_cells, size_cells, reg_cells;
unsigned int nr_banks, gbank, bank = 0;
const uint64_t rambase[] = GUEST_RAM_BANK_BASES;
@@ -523,24 +580,10 @@ static void __init allocate_static_memory(struct domain
*d,
u64 tot_size = 0;
paddr_t pbase, psize, gsize;
mfn_t smfn;
-int res;
-
-prop = dt_find_property(node, "xen,static-mem", NULL);
-if ( !dt_property_read_u32(node, "#xen,static-mem-address-cells",
- _cells) )
-{
-printk(XENLOG_ERR
- "%pd: failed to read \"#xen,static-mem-address-cells\".\n", d);
-goto fail;
-}
+int length;
-if ( !dt_property_read_u32(node, "#xen,static-mem-size-cells",
- _cells) )
-{
-printk(XENLOG_ERR
- "%pd: failed to read \"#xen,static-mem-size-cells\".\n", d);
+if ( parse_static_mem_prop(node, _cells, _cells, , )
)
goto fail;
-}
reg_cells = addr_cells + size_cells;
/*
@@ -551,29 +594,14 @@ static void __init allocate_static_memory(struct domain
*d,
gbank = 0;
gsize = ramsize[gbank];
kinfo->mem.bank[gbank].start = rambase[gbank];
-
-cell = (const __be32 *)prop->value;
-nr_banks = (prop->length) / (reg_cells * sizeof (u32));
+nr_banks = length / (reg_cells * sizeof (u32));
for ( ; bank < nr_banks; bank++ )
{
-device_tree_get_reg(, addr_cells, size_cells, , );
-ASSERT(IS_ALIGNED(pbase, PAGE_SIZE) && IS_ALIGNED(psize, PAGE_SIZE));
-
-if ( PFN_DOWN(psize) > UINT_MAX )
-{
-printk(XENLOG_ERR
[PATCH v6 02/11] xen: introduce CDF_directmap
From: Stefano Stabellini
This commit introduces a new arm-specific flag CDF_directmap to specify
that a domain should have its memory direct-map(guest physical address
== host physical address) at domain creation.
Also, add a directmap flag under struct arch_domain and use it to
reimplement is_domain_direct_mapped.
For now, direct-map is only available when statically allocated memory is
used for the domain, that is, "xen,static-mem" must be also defined in the
domain configuration.
Signed-off-by: Stefano Stabellini
Signed-off-by: Penny Zheng
Acked-by: Jan Beulich
Tested-by: Stefano Stabellini
---
CC: andrew.coop...@citrix.com
CC: jbeul...@suse.com
CC: George Dunlap
CC: Ian Jackson
CC: Wei Liu
CC: "Roger Pau Monné"
---
v2 changes
- remove the introduce of internal flag
- remove flag direct_map since we already store this flag in d->options
- Refine is_domain_direct_mapped to check whether the flag
XEN_DOMCTL_CDF_directmap is set
- reword "1:1 direct-map" to just "direct-map"
---
v3 changes
- move flag back to xen/include/xen/domain.h, to let it be only available for
domain created by XEN.
- name it with extra "INTERNAL" and add comments to warn developers not
to accidently use its bitfield when introducing new XEN_DOMCTL_CDF_xxx flag.
- reject this flag in x86'es arch_sanitise_domain_config()
---
v4 changes
- introduce new internal flag CDF_directmap
- add a directmap flag under struct arch_domain and use it to
reimplement is_domain_direct_mapped.
- expand arch_domain_create to include internal-only parameter "const unsigned
int flags"
---
v5 changes
- remove const constraint
---
v6 changes
- comment and coding style fix
- protect CDF_directmap with #ifdef CONFIG_ARM
---
docs/misc/arm/device-tree/booting.txt | 6 ++
xen/arch/arm/domain.c | 5 -
xen/arch/arm/domain_build.c | 14 --
xen/arch/arm/include/asm/domain.h | 5 +++--
xen/arch/x86/domain.c | 3 ++-
xen/common/domain.c | 2 +-
xen/include/xen/domain.h | 7 ++-
7 files changed, 34 insertions(+), 8 deletions(-)
diff --git a/docs/misc/arm/device-tree/booting.txt
b/docs/misc/arm/device-tree/booting.txt
index 71895663a4..a94125394e 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -182,6 +182,12 @@ with the following properties:
Both #address-cells and #size-cells need to be specified because
both sub-nodes (described shortly) have reg properties.
+- direct-map
+
+Only available when statically allocated memory is used for the domain.
+An empty property to request the memory of the domain to be
+direct-map (guest physical address == physical address).
+
Under the "xen,domain" compatible node, one or more sub-nodes are present
for the DomU kernel and ramdisk.
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 92a6c509e5..8110c1df86 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -692,7 +692,8 @@ int arch_sanitise_domain_config(struct
xen_domctl_createdomain *config)
}
int arch_domain_create(struct domain *d,
- struct xen_domctl_createdomain *config)
+ struct xen_domctl_createdomain *config,
+ unsigned int flags)
{
int rc, count = 0;
@@ -708,6 +709,8 @@ int arch_domain_create(struct domain *d,
ioreq_domain_init(d);
#endif
+d->arch.directmap = flags & CDF_directmap;
+
/* p2m_init relies on some value initialized by the IOMMU subsystem */
if ( (rc = iommu_domain_init(d, config->iommu_opts)) != 0 )
goto fail;
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 0fab8604de..6467e8ee32 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -3029,10 +3029,20 @@ void __init create_domUs(void)
.max_maptrack_frames = -1,
.grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version),
};
+unsigned int flags = 0U;
if ( !dt_device_is_compatible(node, "xen,domain") )
continue;
+if ( dt_property_read_bool(node, "direct-map") )
+{
+if ( !IS_ENABLED(CONFIG_STATIC_MEMORY) || !dt_find_property(node,
"xen,static-mem", NULL) )
+panic("direct-map is not valid for domain %s without static
allocation.\n",
+ dt_node_name(node));
+
+flags |= CDF_directmap;
+}
+
if ( !dt_property_read_u32(node, "cpus", _cfg.max_vcpus) )
panic("Missing property 'cpus' for domain %s\n",
dt_node_name(node));
@@ -3058,7 +3068,7 @@ void __init create_domUs(void)
* very important to use the pre-increment operator to call
* domain_create() with a domid > 0. (domid == 0 is reserved for Dom0)
*/
-d = domain_create(++max_init_domid, _cfg, 0);
+d = domain_create(++max_init_domid, _cfg,
[PATCH v6 01/11] xen: introduce internal CDF_xxx flags for domain creation
From: Stefano Stabellini
We are passing an internal-only boolean flag at domain creation to
specify whether we want the domain to be privileged (i.e. dom0) or
not. Another flag will be introduced later in this series.
This commit extends original "boolean" to an "unsigned int" covering both
the existing "is_priv" and our new "directmap", which will be introduced later.
To make visible the relationship, we name the respective constants CDF_xxx
(with no XEN_DOMCTL_ prefix) to represent the difference with the public
constants XEN_DOMCTL_CDF_xxx.
Allocate bit 0 as CDF_privileged: whether a domain is privileged or not.
Signed-off-by: Stefano Stabellini
Signed-off-by: Penny Zheng
Reviewed-by: Jan Beulich
Reviewed-by: Julien Grall
Tested-by: Stefano Stabellini
---
v4 changes:
- new commit
---
v5 changes
- remove const constraint
---
v6 changes
- no changes
---
xen/arch/arm/domain_build.c | 4 ++--
xen/arch/x86/setup.c| 2 +-
xen/common/domain.c | 10 +-
xen/common/sched/core.c | 2 +-
xen/include/xen/domain.h| 4
xen/include/xen/sched.h | 2 +-
6 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 6931c022a2..0fab8604de 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -3058,7 +3058,7 @@ void __init create_domUs(void)
* very important to use the pre-increment operator to call
* domain_create() with a domid > 0. (domid == 0 is reserved for Dom0)
*/
-d = domain_create(++max_init_domid, _cfg, false);
+d = domain_create(++max_init_domid, _cfg, 0);
if ( IS_ERR(d) )
panic("Error creating domain %s\n", dt_node_name(node));
@@ -3160,7 +3160,7 @@ void __init create_dom0(void)
if ( iommu_enabled )
dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
-dom0 = domain_create(0, _cfg, true);
+dom0 = domain_create(0, _cfg, CDF_privileged);
if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
panic("Error creating domain 0\n");
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 115f8f6517..624b53ded4 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -789,7 +789,7 @@ static struct domain *__init create_dom0(const module_t
*image,
/* Create initial domain. Not d0 for pvshim. */
domid = get_initial_domain_id();
-d = domain_create(domid, _cfg, !pv_shim);
+d = domain_create(domid, _cfg, pv_shim ? 0 : CDF_privileged);
if ( IS_ERR(d) )
panic("Error creating d%u: %ld\n", domid, PTR_ERR(d));
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 2048ebad86..a79103e04a 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -552,7 +552,7 @@ static int sanitise_domain_config(struct
xen_domctl_createdomain *config)
struct domain *domain_create(domid_t domid,
struct xen_domctl_createdomain *config,
- bool is_priv)
+ unsigned int flags)
{
struct domain *d, **pd, *old_hwdom = NULL;
enum { INIT_watchdog = 1u<<1,
@@ -578,7 +578,7 @@ struct domain *domain_create(domid_t domid,
}
/* Sort out our idea of is_control_domain(). */
-d->is_privileged = is_priv;
+d->is_privileged = flags & CDF_privileged;
/* Sort out our idea of is_hardware_domain(). */
if ( domid == 0 || domid == hardware_domid )
@@ -772,7 +772,7 @@ void __init setup_system_domains(void)
* Hidden PCI devices will also be associated with this domain
* (but be [partly] controlled by Dom0 nevertheless).
*/
-dom_xen = domain_create(DOMID_XEN, NULL, false);
+dom_xen = domain_create(DOMID_XEN, NULL, 0);
if ( IS_ERR(dom_xen) )
panic("Failed to create d[XEN]: %ld\n", PTR_ERR(dom_xen));
@@ -782,7 +782,7 @@ void __init setup_system_domains(void)
* array. Mappings occur at the priv of the caller.
* Quarantined PCI devices will be associated with this domain.
*/
-dom_io = domain_create(DOMID_IO, NULL, false);
+dom_io = domain_create(DOMID_IO, NULL, 0);
if ( IS_ERR(dom_io) )
panic("Failed to create d[IO]: %ld\n", PTR_ERR(dom_io));
@@ -791,7 +791,7 @@ void __init setup_system_domains(void)
* Initialise our COW domain.
* This domain owns sharable pages.
*/
-dom_cow = domain_create(DOMID_COW, NULL, false);
+dom_cow = domain_create(DOMID_COW, NULL, 0);
if ( IS_ERR(dom_cow) )
panic("Failed to create d[COW]: %ld\n", PTR_ERR(dom_cow));
#endif
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 8f4b1ca10d..f5c819349b 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -3021,7 +3021,7 @@ void __init scheduler_init(void)
sched_ratelimit_us = SCHED_DEFAULT_RATELIMIT_US;
}
-idle_domain = domain_create(DOMID_IDLE, NULL, false);
+idle_domain = domain_create(DOMID_IDLE,
[linux-5.4 test] 168102: trouble: blocked/broken/fail/pass
flight 168102 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/168102/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-pvopsbroken build-arm64-xsm broken build-arm64-xsm 4 host-install(4)broken REGR. vs. 168060 build-arm64-pvops 4 host-install(4)broken REGR. vs. 168060 build-arm64 4 host-install(4)broken REGR. vs. 168060 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-rtds 18 guest-start/debian.repeat fail pass in 168093 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168060 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 168060 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168060 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 168060 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 168060 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 168060 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 168060 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 168060 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 168060 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 168060 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 168060 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 168060 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-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: linux52871671099d1bb3fca5ed076029e4b937bfc053 baseline version: linux
RE: [PATCH V2 00/13] use time_is_xxx() instead of jiffies judgment
>>On Thu, Feb 10, 2022 at 06:30:23PM -0800, Qing Wang wrote:
>> From: Wang Qing
>>
>> It is better to use time_is_xxx() directly instead of jiffies judgment
>> for understanding.
>
>Hi Wang,
>
>"judgement" doesn't really make sense as a description to an English
>speaker. The following a commit desription (for all of these series)
>is probably going to be a bit more understable:
>
>Use the helper function time_is_{before,after}_jiffies() to improve
>code readability.
>
>Cheers,
>
> - Ted
I see, it will be corrected in V3.
I'll wait a few days if there are any other disagreements.
Thanks,
Qing
[qemu-mainline test] 168101: trouble: blocked/broken/fail/pass
flight 168101 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/168101/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-pvopsbroken build-arm64-xsm broken build-arm64-pvops 4 host-install(4)broken REGR. vs. 168059 build-arm64-xsm 4 host-install(4)broken REGR. vs. 168059 build-arm64 4 host-install(4)broken REGR. vs. 168059 Tests which are failing intermittently (not blocking): test-amd64-amd64-qemuu-freebsd11-amd64 8 xen-boot fail pass in 168095 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-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168059 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 168059 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 168059 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 168059 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 168059 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 168059 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 168059 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 168059 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail 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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-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-libvirt 15 migrate-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-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-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-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-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: qemuuda36afa2d8dc9c778292ff172083caba9558b4fa baseline version: qemuu0a301624c2f4ced3331ffd5bce85b4274fe132af Last test of basis 168059 2022-02-08 15:36:56 Z5 days Testing same since 168095 2022-02-12 22:37:11 Z1 days2 attempts People who touched revisions under test: Alex Bennée Cédric Le Goater Ivanov Arkady Michael Tokarev Peter Maydell Philippe
[linux-linus test] 168099: trouble: blocked/broken/fail/pass
flight 168099 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/168099/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-pvopsbroken build-arm64-xsm broken build-arm64-xsm 4 host-install(4)broken REGR. vs. 168080 build-arm64 4 host-install(4)broken REGR. vs. 168080 build-arm64-pvops 4 host-install(4)broken REGR. vs. 168080 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168080 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 168080 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 168080 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 168080 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168080 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail like 168080 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 168080 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 168080 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 168080 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail 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-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass version targeted for testing: linuxb81b1829e7e39f6cebdf6e4d5484eacbceda8554 baseline version: linuxf1baf68e1383f6ed93eb9cff2866d46562607a43 Last test of basis 168080 2022-02-11 00:09:22 Z2 days Failing since168086 2022-02-11 20:11:19 Z2 days5 attempts Testing same since 168094 2022-02-12 21:42:38 Z0 days2 attempts People who touched revisions under test: Aaron Liu Adam Ford Al Cooper Alex Deucher Alexander Egorenkov Alexander Gordeev Alexander Stein Alexandre Ghiti Alim Akhtar Alviro Iskandar Setiawan Ammar Faizi Andreas Gruenbacher Andrew Morton Andrey Konovalov Andrzej Pietrasiewicz Andy Shevchenko Arnd Bergmann Aswath Govindraju
Re: [PATCH V5] xen/gnttab: Store frame GFN in struct page_info on Arm
On 13.02.22 18:06, Julien Grall wrote:
> Hi Oleksandr,
Hi Julien
>
> On 10/02/2022 16:55, Oleksandr wrote:
>>
>> On 10.02.22 11:46, Julien Grall wrote:
>>>
>>>
>>> On 08/02/2022 19:50, Oleksandr Tyshchenko wrote:
On 08.02.22 13:58, Julien Grall wrote:
Below the diff I have locally:
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 5646343..90d7563 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1315,11 +1315,32 @@ static inline int p2m_remove_mapping(struct
domain *d,
mfn_t mfn)
{
struct p2m_domain *p2m = p2m_get_hostp2m(d);
+ unsigned long i;
int rc;
p2m_write_lock(p2m);
+ for ( i = 0; i < nr; )
+ {
+ unsigned int cur_order;
+ bool valid;
+ mfn_t mfn_return = p2m_get_entry(p2m, gfn_add(start_gfn, i),
NULL, NULL,
+ _order, ); > +
+ if ( valid &&
>>>
>>> valid is a copy of the LPAE bit valid. This may be 0 if Xen decided
>>> to clear it (i.e when emulating set/way). Yet the mapping itself is
>>> considered valid from Xen PoV.
>>>
>>> So you want to replace with a different check (see below).
>>
>>
>> Hmm, I got it, so ...
>>
>>
>>>
>>>
+ (!mfn_valid(mfn) || !mfn_eq(mfn_add(mfn, i),
mfn_return)) )
+ {
+ rc = -EILSEQ;
+ goto out;
+ }
+
+ i += (1UL << cur_order) -
+ ((gfn_x(start_gfn) + i) & ((1UL << cur_order) - 1));
+ }
+
rc = p2m_set_entry(p2m, start_gfn, nr, INVALID_MFN,
p2m_invalid, p2m_access_rwx);
+
+out:
p2m_write_unlock(p2m);
return rc;
Could you please clarify, is it close to what you had in mind? If
yes, I
am wondering, don't we need this check to be only executed for xenheap
pages (and, probably, which P2M's entry type in RAM?) rather than for
all pages?
>>>
>>> From my understanding, for the purpose of this work, we only
>>> strictly need to check that for xenheap pages.
>>
>>
>> ... yes, but ...
>>
>>
>>>
>>>
>>> But I think it would be a good opportunity to harden the P2M code.
>>> At the moment, on Arm, you can remove any mappings you want (even
>>> with the wrong helpers). This lead us to a few issues when mapping
>>> were overriden silently (in particular when building dom0).
>>> So I would say we should enforce it for every RAM mapping.
>>
>>
>> ... I think this makes sense, so the proper check in that case, I
>> assume, should contain p2m_is_any_ram() macro:
>
>
> Correct, p2m_is_any_ram() looks the macro we want to use here.
Good, thank you for the clarification! FYI, I have already re-checked
with p2m_is_any_ram(). DomU with PV devices (display, sound, net) and
Virtio (block) boots without any issues, the reboot and destroy also
work. To be clear, all backends in my environment reside in DomD.
>
>>> Note that, I would like to see this change in a separate commit. It
>>> will be easier to review.
>>
>>
>> ok, I will introduce this check by a separate patch.
>
> Thank you!
>
> [...]
>
It is going to be a non-protected write to GFN portion of type_info.
>>>
>>> Well no. You are using a Read-Modify-Write operation on type_info.
>>> This is not atomic and will overwrite any change (if any) done on
>>> other part of the type_info.
>>
>>
>> I am confused a bit, to which my comment your comment above belongs
>> (to the diff for page_set_xenheap_gfn() above or to sentence right
>> after it)?
>> The "It is going to be a non-protected write to GFN portion of
>> type_info." sentence is related to the diff for alloc_heap_pages()
>> below. Sorry if I didn't separate the comments properly.
>
> Ok. So it will be a write operation, but I still don't understand why
> you think it is just the GFN portion.
>
> The code is using "...type_info = PGT_TYPE_INFO_INITIALIZER". So the
> full 64-bit (assuming arm64) will be modified.
You are right, I wasn't precise, sorry.
>
>
> In general, the GFN takes 60 of the 64-bits. So any time you need to
> modify the GFN (or the count_info), you will end up to modify the
> entire of type_info (and vice-versa). If this is becoming we problem
> (e.g. the count_info is actively used) we will need to use cmpxchg()
> to modify the GFN portion.
I got it, as I understood from your explanation about
share_xen_page_with_guest() at [1] this is not a problem yet within
current code base.
[1]
https://lore.kernel.org/xen-devel/a104d3ea-170e-8175-ac04-abfcebb4a...@xen.org/
>
>
> Cheers,
>
--
Regards,
Oleksandr Tyshchenko
[linux-5.4 test] 168097: trouble: blocked/broken/fail/pass
flight 168097 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/168097/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-pvopsbroken build-arm64-xsm broken build-arm64-xsm 4 host-install(4)broken REGR. vs. 168060 build-arm64-pvops 4 host-install(4)broken REGR. vs. 168060 build-arm64 4 host-install(4)broken REGR. vs. 168060 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-rtds 14 guest-startfail pass in 168093 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 168093 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds15 migrate-support-check fail in 168093 never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail in 168093 never pass test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168060 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 168060 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168060 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 168060 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 168060 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 168060 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 168060 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 168060 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 168060 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 168060 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 168060 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 168060 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-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-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-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: linux
Re: [PATCH V5] xen/gnttab: Store frame GFN in struct page_info on Arm
Hi Oleksandr,
On 10/02/2022 16:55, Oleksandr wrote:
On 10.02.22 11:46, Julien Grall wrote:
On 08/02/2022 19:50, Oleksandr Tyshchenko wrote:
On 08.02.22 13:58, Julien Grall wrote:
Below the diff I have locally:
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 5646343..90d7563 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1315,11 +1315,32 @@ static inline int p2m_remove_mapping(struct
domain *d,
mfn_t mfn)
{
struct p2m_domain *p2m = p2m_get_hostp2m(d);
+ unsigned long i;
int rc;
p2m_write_lock(p2m);
+ for ( i = 0; i < nr; )
+ {
+ unsigned int cur_order;
+ bool valid;
+ mfn_t mfn_return = p2m_get_entry(p2m, gfn_add(start_gfn, i),
NULL, NULL,
+ _order, ); > +
+ if ( valid &&
valid is a copy of the LPAE bit valid. This may be 0 if Xen decided to
clear it (i.e when emulating set/way). Yet the mapping itself is
considered valid from Xen PoV.
So you want to replace with a different check (see below).
Hmm, I got it, so ...
+ (!mfn_valid(mfn) || !mfn_eq(mfn_add(mfn, i),
mfn_return)) )
+ {
+ rc = -EILSEQ;
+ goto out;
+ }
+
+ i += (1UL << cur_order) -
+ ((gfn_x(start_gfn) + i) & ((1UL << cur_order) - 1));
+ }
+
rc = p2m_set_entry(p2m, start_gfn, nr, INVALID_MFN,
p2m_invalid, p2m_access_rwx);
+
+out:
p2m_write_unlock(p2m);
return rc;
Could you please clarify, is it close to what you had in mind? If yes, I
am wondering, don't we need this check to be only executed for xenheap
pages (and, probably, which P2M's entry type in RAM?) rather than for
all pages?
From my understanding, for the purpose of this work, we only strictly
need to check that for xenheap pages.
... yes, but ...
But I think it would be a good opportunity to harden the P2M code. At
the moment, on Arm, you can remove any mappings you want (even with
the wrong helpers). This lead us to a few issues when mapping were
overriden silently (in particular when building dom0).
So I would say we should enforce it for every RAM mapping.
... I think this makes sense, so the proper check in that case, I
assume, should contain p2m_is_any_ram() macro:
Correct, p2m_is_any_ram() looks the macro we want to use here.
Note that, I would like to see this change in a separate commit. It
will be easier to review.
ok, I will introduce this check by a separate patch.
Thank you!
[...]
It is going to be a non-protected write to GFN portion of type_info.
Well no. You are using a Read-Modify-Write operation on type_info.
This is not atomic and will overwrite any change (if any) done on
other part of the type_info.
I am confused a bit, to which my comment your comment above belongs (to
the diff for page_set_xenheap_gfn() above or to sentence right after it)?
The "It is going to be a non-protected write to GFN portion of
type_info." sentence is related to the diff for alloc_heap_pages()
below. Sorry if I didn't separate the comments properly.
Ok. So it will be a write operation, but I still don't understand why
you think it is just the GFN portion.
The code is using "...type_info = PGT_TYPE_INFO_INITIALIZER". So the
full 64-bit (assuming arm64) will be modified.
In general, the GFN takes 60 of the 64-bits. So any time you need to
modify the GFN (or the count_info), you will end up to modify the entire
of type_info (and vice-versa). If this is becoming we problem (e.g. the
count_info is actively used) we will need to use cmpxchg() to modify the
GFN portion.
Cheers,
--
Julien Grall
[xen-unstable test] 168096: trouble: blocked/broken/fail/pass
flight 168096 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/168096/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-pvopsbroken build-arm64-xsm broken build-arm64-pvops 4 host-install(4)broken REGR. vs. 168081 build-arm64-xsm 4 host-install(4)broken REGR. vs. 168081 build-arm64 4 host-install(4)broken REGR. vs. 168081 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168088 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 168088 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 168088 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 168088 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 168088 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 168088 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 168088 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 168088 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 168088 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 168088 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168088 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 168088 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-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-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-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-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-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass version targeted for testing: xen 87319afb96973213ec0a76270d93696f3b8d6743 baseline version: xen 87319afb96973213ec0a76270d93696f3b8d6743 Last test of basis 168096 2022-02-13 01:53:06 Z0 days Testing same since
[libvirt test] 168098: regressions - trouble: blocked/broken/fail/pass
flight 168098 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/168098/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-pvopsbroken build-arm64-xsm broken build-arm64-pvops 4 host-install(4)broken REGR. vs. 151777 build-arm64 4 host-install(4)broken REGR. vs. 151777 build-arm64-xsm 4 host-install(4)broken 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: build-arm64-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-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 6ccafcb53e2bdf50695c151cf768a36fc5697bab baseline version: libvirt 2c846fa6bcc11929c9fb857a22430fb9945654ad Last test of basis 151777 2020-07-10 04:19:19 Z 583 days Failing since151818 2020-07-11 04:18:52 Z 582 days 564 attempts Testing same since 168090 2022-02-12 04:18:54 Z1 days2 attempts People who touched revisions under test: Adolfo Jayme Barrientos Aleksandr Alekseev Aleksei Zakharov Andika Triwidada Andrea Bolognani 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 Cole Robinson Collin Walling Cornelia Huck Cédric Bosdonnat Côme Borsoi Daniel Henrique Barboza Daniel Letai Daniel P. Berrange Daniel P. Berrangé Didik Supriadi dinglimin Divya Garg Dmitrii Shcherbakov Dmytro Linkin Eiichi Tsukata Emilio Herrera Eric Farman Erik Skultety Fabian Affolter Fabian Freyer Fabiano Fidêncio Fangge Jin Farhan Ali Fedora Weblate Translation Franck Ridel Gavi Teitz gongwei Guoyi Tu Göran Uddeborg Halil Pasic Han Han Hao 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 Jonathan Watt Jonathon Jongsma Julio Faracco Justin Gatzen Ján Tomko Kashyap Chamarthy Kevin Locke Koichi Murase Kristina Hanicova Laine Stump Laszlo Ersek Lee Yarwood Lei Yang Liao Pingfang Lin Ma Lin Ma Lin Ma Liu Yiding Lubomir Rintel Luke Yue Luyao Zhong Marc Hartmayer Marc-André Lureau Marek Marczykowski-Górecki Markus Schade Martin Kletzander Masayoshi Mizuma Matej Cepl Matt Coleman Matt Coleman Mauro Matteo Cascella Meina Li Michal Privoznik Michał Smyk Milo Casagrande Moshe Levi Muha Aliss Nathan Neal Gompa Nick Chevsky Nick Shyrokovskiy Nickys Music Group Nico Pache Nicolas Lécureuil Nicolas Lécureuil Nikolay Shirokovskiy Olaf Hering Olesya Gerasimenko Or Ozeri Orion Poplawski Pany Patrick Magauran Paulo de
Re: [XEN v8 2/2] xen/arm64: io: Support instructions (for which ISS is not valid) on emulated MMIO region using MMIO/ioreq handler
Hi,
On 12/02/2022 23:34, Ayan Kumar Halder wrote:
xen/arch/arm/arm32/traps.c| 7 +++
xen/arch/arm/arm64/traps.c| 47 +++
xen/arch/arm/decode.c | 1 +
xen/arch/arm/include/asm/domain.h | 4 ++
xen/arch/arm/include/asm/mmio.h | 15 -
xen/arch/arm/include/asm/traps.h | 2 +
xen/arch/arm/io.c | 98 ---
xen/arch/arm/ioreq.c | 7 ++-
xen/arch/arm/traps.c | 80 +
xen/arch/x86/include/asm/ioreq.h | 3 +
This change technically needs an ack from the x86 maintainers. And...
xen/include/xen/sched.h | 2 +
this one for anyone from THE REST (Stefano and I are part of it). Please
use scripts/add_maintainers.pl to automatically add the relevant
maintainers in CC.
11 files changed, 217 insertions(+), 49 deletions(-)
diff --git a/xen/arch/arm/arm32/traps.c b/xen/arch/arm/arm32/traps.c
index 9c9790a6d1..70c6238196 100644
--- a/xen/arch/arm/arm32/traps.c
+++ b/xen/arch/arm/arm32/traps.c
@@ -18,9 +18,11 @@
#include
#include
+#include
#include
+#include
#include
#include
@@ -82,6 +84,11 @@ void do_trap_data_abort(struct cpu_user_regs *regs)
do_unexpected_trap("Data Abort", regs);
}
+void post_increment_register(const struct instr_details *instr)
+{
+domain_crash(current->domain);
Please add a comment explaning why this is resulting to a domain crash.
AFAICT, this is because this should not be reachable (yet) for 32-bit.
+}
+
/*
* Local variables:
* mode: C
diff --git a/xen/arch/arm/arm64/traps.c b/xen/arch/arm/arm64/traps.c
index 9113a15c7a..a6766689b3 100644
--- a/xen/arch/arm/arm64/traps.c
+++ b/xen/arch/arm/arm64/traps.c
@@ -23,6 +23,7 @@
#include
#include
+#include
The headers should ordered so are first, then , then
. They should then be ordered alphabetically within each of
the category.
So, this new header should be included right after
[...]
diff --git a/xen/arch/arm/include/asm/mmio.h b/xen/arch/arm/include/asm/mmio.h
index 3354d9c635..745130b7fe 100644
--- a/xen/arch/arm/include/asm/mmio.h
+++ b/xen/arch/arm/include/asm/mmio.h
@@ -26,12 +26,22 @@
#define MAX_IO_HANDLER 16
+enum instr_decode_state
+{
+INSTR_ERROR,/* Error encountered while decoding instr
*/
+INSTR_VALID,/* ISS is valid, so no need to decode */
+INSTR_LDR_STR_POSTINDEXING, /* Instruction is decoded successfully.
+ It is ldr/str post indexing */
Coding style: multiple-line comments for Xen should be:
/*
* ...
* ...
*/
In this case, I would simply move the comment on top.
[...]
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index a289d393f9..203466b869 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -95,57 +95,87 @@ static const struct mmio_handler *find_mmio_handler(struct
domain *d,
return handler;
}
+void try_decode_instruction(const struct cpu_user_regs *regs,
+mmio_info_t *info)
+{
+int rc;
+
+/*
+ * Erratum 766422: Thumb store translation fault to Hypervisor may
+ * not have correct HSR Rt value.
+ */
+if ( check_workaround_766422() && (regs->cpsr & PSR_THUMB) &&
+ info->dabt.write )
+{
+rc = decode_instruction(regs, info);
+if ( rc )
+{
+gprintk(XENLOG_DEBUG, "Unable to decode instruction\n");
+info->dabt_instr.state = INSTR_ERROR;
+return;
+}
+}
At the moment, the errata would only be handled when the ISS is valid.
Now, you are moving it before we know if it is valid. Can you explain why?
[...]
enum io_state try_handle_mmio(struct cpu_user_regs *regs,
- const union hsr hsr,
- paddr_t gpa)
+ mmio_info_t *info)
{
struct vcpu *v = current;
const struct mmio_handler *handler = NULL;
-const struct hsr_dabt dabt = hsr.dabt;
-mmio_info_t info = {
-.gpa = gpa,
-.dabt = dabt
-};
+int rc;
-ASSERT(hsr.ec == HSR_EC_DATA_ABORT_LOWER_EL);
+ASSERT(info->dabt.ec == HSR_EC_DATA_ABORT_LOWER_EL);
-handler = find_mmio_handler(v->domain, info.gpa);
+handler = find_mmio_handler(v->domain, info->gpa);
if ( !handler )
{
-int rc;
-
-rc = try_fwd_ioserv(regs, v, );
+rc = try_fwd_ioserv(regs, v, info);
if ( rc == IO_HANDLED )
return handle_ioserv(regs, v);
return rc;
}
-/* All the instructions used on emulated MMIO region should be valid */
-if ( !dabt.valid )
-return IO_ABORT;
-
AFAIU, the assumption is now try_handle_mmio() and try_fwd_ioserv() will
always be called when dabt.valid == 1. I think it would still be good to
check that assumption.
So I would
[qemu-mainline test] 168095: trouble: blocked/broken/fail/pass
flight 168095 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/168095/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-pvopsbroken build-arm64-xsm broken build-arm64-pvops 4 host-install(4)broken REGR. vs. 168059 build-arm64-xsm 4 host-install(4)broken REGR. vs. 168059 build-arm64 4 host-install(4)broken REGR. vs. 168059 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-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 168059 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 168059 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168059 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 168059 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 168059 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 168059 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 168059 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 168059 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail 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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-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 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-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-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-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: qemuuda36afa2d8dc9c778292ff172083caba9558b4fa baseline version: qemuu0a301624c2f4ced3331ffd5bce85b4274fe132af Last test of basis 168059 2022-02-08 15:36:56 Z4 days Testing same since 168095 2022-02-12 22:37:11 Z0 days1 attempts People who touched revisions under test: Alex Bennée Cédric Le Goater Ivanov Arkady Michael Tokarev Peter Maydell Philippe Mathieu-Daudé Stefan Hajnoczi Thomas Huth jobs: build-amd64-xsm pass
[xen-unstable-coverity test] 168100: all pass - PUSHED
flight 168100 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/168100/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 87319afb96973213ec0a76270d93696f3b8d6743 baseline version: xen 52ce1c97844db213de01c5300eaaa8cf101a285f Last test of basis 168068 2022-02-09 09:21:03 Z4 days Testing same since 168100 2022-02-13 09:18:29 Z0 days1 attempts People who touched revisions under test: Jan Beulich Juergen Gross Julien Grall Roger Pau Monné Volodymyr Babchuk jobs: coverity-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 Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 52ce1c9784..87319afb96 87319afb96973213ec0a76270d93696f3b8d6743 -> coverity-tested/smoke
