[linux-linus test] 170810: regressions - FAIL
flight 170810 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/170810/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-libvirt-raw 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-xl-seattle 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-freebsd12-amd64 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-libvirt-qcow2 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-xl 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-examine 8 reboot fail REGR. vs. 170714 test-arm64-arm64-xl-credit2 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-libvirt-pair 12 xen-boot/src_host fail REGR. vs. 170714 test-amd64-amd64-libvirt-pair 13 xen-boot/dst_host fail REGR. vs. 170714 test-amd64-amd64-examine-uefi 8 reboot fail REGR. vs. 170714 test-amd64-amd64-examine-bios 8 reboot fail REGR. vs. 170714 test-amd64-amd64-examine 8 reboot fail REGR. vs. 170714 test-arm64-arm64-libvirt-xsm 8 xen-boot fail REGR. vs. 170714 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 170714 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 170714 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 170714 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 170714 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 170714 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 170714 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 170714 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 170714 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt 15 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-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-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass version targeted for testing: linux58f9d52ff689a262bec7f5713c07f5a79e115168 baseline version: linuxd6ecaa0024485effd065124fe774de2e22095f2d Last test of basis 170714 2022-05-24 03:27:44 Z 10 days Failing since170716 2022-05-24 11:12:06 Z9 days 28 attempts Testing same since 170810 2022-06-02 22:12:29 Z0 days1 attempts 2055 people touched revisions under test, not
Re: [PATCH v5 7/9] xen/arm: unpopulate memory when domain is static
On Tue, 31 May 2022, Penny Zheng wrote:
> Today when a domain unpopulates the memory on runtime, they will always
> hand the memory back to the heap allocator. And it will be a problem if domain
> is static.
>
> Pages as guest RAM for static domain shall be reserved to only this domain
> and not be used for any other purposes, so they shall never go back to heap
> allocator.
>
> This commit puts reserved pages on the new list resv_page_list only after
> having taken them off the "normal" list, when the last ref dropped.
>
> Signed-off-by: Penny Zheng
ARM bits:
Acked-by: Stefano Stabellini
> ---
> v5 changes:
> - adapt this patch for PGC_staticmem
> ---
> v4 changes:
> - no changes
> ---
> v3 changes:
> - have page_list_del() just once out of the if()
> - remove resv_pages counter
> - make arch_free_heap_page be an expression, not a compound statement.
> ---
> v2 changes:
> - put reserved pages on resv_page_list after having taken them off
> the "normal" list
> ---
> xen/arch/arm/include/asm/mm.h | 12
> xen/common/domain.c | 4
> xen/include/xen/sched.h | 3 +++
> 3 files changed, 19 insertions(+)
>
> diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
> index 56d0939318..ca384a3939 100644
> --- a/xen/arch/arm/include/asm/mm.h
> +++ b/xen/arch/arm/include/asm/mm.h
> @@ -360,6 +360,18 @@ void clear_and_clean_page(struct page_info *page);
>
> unsigned int arch_get_dma_bitsize(void);
>
> +/*
> + * Put free pages on the resv page list after having taken them
> + * off the "normal" page list, when pages from static memory
> + */
> +#ifdef CONFIG_STATIC_MEMORY
> +#define arch_free_heap_page(d, pg) ({ \
> +page_list_del(pg, page_to_list(d, pg)); \
> +if ( (pg)->count_info & PGC_staticmem ) \
> +page_list_add_tail(pg, &(d)->resv_page_list); \
> +})
> +#endif
> +
> #endif /* __ARCH_ARM_MM__ */
> /*
> * Local variables:
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index a3ef991bd1..a49574fa24 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -604,6 +604,10 @@ struct domain *domain_create(domid_t domid,
> INIT_PAGE_LIST_HEAD(&d->page_list);
> INIT_PAGE_LIST_HEAD(&d->extra_page_list);
> INIT_PAGE_LIST_HEAD(&d->xenpage_list);
> +#ifdef CONFIG_STATIC_MEMORY
> +INIT_PAGE_LIST_HEAD(&d->resv_page_list);
> +#endif
> +
>
> spin_lock_init(&d->node_affinity_lock);
> d->node_affinity = NODE_MASK_ALL;
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 5191853c18..3e22c77333 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -381,6 +381,9 @@ struct domain
> struct page_list_head page_list; /* linked list */
> struct page_list_head extra_page_list; /* linked list (size extra_pages)
> */
> struct page_list_head xenpage_list; /* linked list (size xenheap_pages)
> */
> +#ifdef CONFIG_STATIC_MEMORY
> +struct page_list_head resv_page_list; /* linked list (size resv_pages) */
> +#endif
>
> /*
> * This field should only be directly accessed by
> domain_adjust_tot_pages()
> --
> 2.25.1
>
Re: [PATCH v5 6/9] xen/arm: introduce CDF_staticmem
On Tue, 31 May 2022, Penny Zheng wrote:
> In order to have an easy and quick way to find out whether this domain memory
> is statically configured, this commit introduces a new flag CDF_staticmem and
> a
> new helper is_domain_using_staticmem() to tell.
>
> Signed-off-by: Penny Zheng
I realize Jan asked for improvements but I just wanted to say that on my
side it looks good.
> ---
> v5 changes:
> - guard "is_domain_using_staticmem" under CONFIG_STATIC_MEMORY
> - #define is_domain_using_staticmem zero if undefined
> ---
> v4 changes:
> - no changes
> ---
> v3 changes:
> - change name from "is_domain_static()" to "is_domain_using_staticmem"
> ---
> v2 changes:
> - change name from "is_domain_on_static_allocation" to "is_domain_static()"
> ---
> xen/arch/arm/domain_build.c | 5 -
> xen/arch/arm/include/asm/domain.h | 4
> xen/include/xen/domain.h | 6 ++
> 3 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 7ddd16c26d..f6e2e44c1e 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -3287,9 +3287,12 @@ void __init create_domUs(void)
> if ( !dt_device_is_compatible(node, "xen,domain") )
> continue;
>
> +if ( dt_find_property(node, "xen,static-mem", NULL) )
> +flags |= CDF_staticmem;
> +
> if ( dt_property_read_bool(node, "direct-map") )
> {
> -if ( !IS_ENABLED(CONFIG_STATIC_MEMORY) ||
> !dt_find_property(node, "xen,static-mem", NULL) )
> +if ( !IS_ENABLED(CONFIG_STATIC_MEMORY) || !(flags &
> CDF_staticmem) )
> panic("direct-map is not valid for domain %s without static
> allocation.\n",
>dt_node_name(node));
>
> diff --git a/xen/arch/arm/include/asm/domain.h
> b/xen/arch/arm/include/asm/domain.h
> index fe7a029ebf..6bb999aff0 100644
> --- a/xen/arch/arm/include/asm/domain.h
> +++ b/xen/arch/arm/include/asm/domain.h
> @@ -31,6 +31,10 @@ enum domain_type {
>
> #define is_domain_direct_mapped(d) ((d)->cdf & CDF_directmap)
>
> +#ifdef CONFIG_STATIC_MEMORY
> +#define is_domain_using_staticmem(d) ((d)->cdf & CDF_staticmem)
> +#endif
> +
> /*
> * Is the domain using the host memory layout?
> *
> diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
> index 1c3c88a14d..c613afa57e 100644
> --- a/xen/include/xen/domain.h
> +++ b/xen/include/xen/domain.h
> @@ -34,6 +34,12 @@ void arch_get_domain_info(const struct domain *d,
> #ifdef CONFIG_ARM
> /* Should domain memory be directly mapped? */
> #define CDF_directmap(1U << 1)
> +/* Is domain memory on static allocation? */
> +#define CDF_staticmem(1U << 2)
> +#endif
> +
> +#ifndef is_domain_using_staticmem
> +#define is_domain_using_staticmem(d) ((void)(d), false)
> #endif
>
> /*
> --
> 2.25.1
>
Re: [PATCH v5 3/9] xen: update SUPPORT.md for static allocation
On Tue, 31 May 2022, Penny Zheng wrote: > SUPPORT.md doesn't seem to explicitly say whether static memory is > supported, so this commit updates SUPPORT.md to add feature static > allocation tech preview for now. > > Signed-off-by: Penny Zheng > --- > v5 changes: > - new commit > --- > SUPPORT.md | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/SUPPORT.md b/SUPPORT.md > index ee2cd319e2..5980a82c4b 100644 > --- a/SUPPORT.md > +++ b/SUPPORT.md > @@ -278,6 +278,13 @@ to boot with memory < maxmem. > > Status, x86 HVM: Supported > > +### Static Allocation > + > +Static allocation refers to system or sub-system(domains) for which memory > +areas are pre-defined by configuration using physical address ranges. Although I completely understand what you mean I would rather not use the word "sub-system" as we haven't used it before in a Xen context. So instead I would only use domains. I would write it like this: ### Static Allocation Static allocation refers to domains for which memory areas are pre-defined by configuration using physical address ranges. Status, ARM: Tech Preview With that you can add Reviewed-by: Stefano Stabellini > +Status, ARM: Tech Preview > + > ### Memory Sharing > > Allow sharing of identical pages between guests > -- > 2.25.1 >
Re: [PATCH v2 0/4] Spectre BHB follow up
I reviewed patches #1 and #3. Julien had already started reviewing the other patches in details so it is probably better if he continues his reviews on those. So I skipped them for now. Let me know if you'd like me to review them. On Tue, 31 May 2022, Bertrand Marquis wrote: > Following up the handling of Spectre BHB on Arm (XSA-398), this serie > contain several changes which were not needed in the XSA patches but > should be done in Xen: > - Sync sysregs and cpuinfo with latest version of Linux (5.18-rc3) > - Add new fields inside cpufeature > - Add sb instruction support. Some newer generations of CPU > (Neoverse-N2) do support the instruction so add support for it in Xen. > - Create hidden Kconfig entries for CONFIG_ values actually used in > arm64 cpufeature. > > Changes in v2 > - remove patch which was merged (workaround 1 when workaround 3 is done) > - split sync with linux and update of cpufeatures > - add patch to define kconfig entries used by arm64 cpufeature > > Bertrand Marquis (4): > xen/arm: Sync sysregs and cpuinfo with Linux 5.18-rc3 > xen/arm: Add sb instruction support > arm: add ISAR2, MMFR0 and MMFR1 fields in cpufeature > arm: Define kconfig symbols used by arm64 cpufeatures > > xen/arch/arm/Kconfig | 28 + > xen/arch/arm/arm64/cpufeature.c | 18 +- > xen/arch/arm/cpufeature.c| 28 + > xen/arch/arm/include/asm/arm64/sysregs.h | 76 > xen/arch/arm/include/asm/cpufeature.h| 34 +-- > xen/arch/arm/include/asm/macros.h| 33 +++--- > xen/arch/arm/setup.c | 3 + > xen/arch/arm/smpboot.c | 1 + > 8 files changed, 193 insertions(+), 28 deletions(-) > > -- > 2.25.1 >
Re: [PATCH v2 1/4] xen/arm: Sync sysregs and cpuinfo with Linux 5.18-rc3
On Tue, 31 May 2022, Bertrand Marquis wrote:
> Sync existing ID registers sanitization with the status of Linux kernel
> version 5.18-rc3 and add sanitization of ISAR2 registers.
>
> Sync sysregs.h bit shift defintions with the status of Linux kernel
> version 5.18-rc3.
>
> Changes in this patch are splitted in a number of patches in Linux
> kernel and, as the previous synchronisation point was not clear, the
> changes are done in one patch with a status possible to compare easily
> by diffing Xen files to Linux kernel files.
>
> Origin: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> b2d229d4ddb1
> Signed-off-by: Bertrand Marquis
Reviewed-by: Stefano Stabellini
> ---
> Changes in v2
> - move changes in cpufeature.h in an independent patch
> - add proper origin tag in the commit
> - rework the commit message
> ---
> xen/arch/arm/arm64/cpufeature.c | 18 +-
> xen/arch/arm/include/asm/arm64/sysregs.h | 76
> 2 files changed, 80 insertions(+), 14 deletions(-)
>
> diff --git a/xen/arch/arm/arm64/cpufeature.c b/xen/arch/arm/arm64/cpufeature.c
> index 6e5d30dc7b..d9039d37b2 100644
> --- a/xen/arch/arm/arm64/cpufeature.c
> +++ b/xen/arch/arm/arm64/cpufeature.c
> @@ -143,6 +143,16 @@ static const struct arm64_ftr_bits ftr_id_aa64isar1[] = {
> ARM64_FTR_END,
> };
>
> +static const struct arm64_ftr_bits ftr_id_aa64isar2[] = {
> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_HIGHER_SAFE,
> ID_AA64ISAR2_CLEARBHB_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
> +FTR_STRICT, FTR_EXACT, ID_AA64ISAR2_APA3_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
> +FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR2_GPA3_SHIFT, 4,
> 0),
> + ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE,
> ID_AA64ISAR2_RPRES_SHIFT, 4, 0),
> + ARM64_FTR_END,
> +};
> +
> static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
> ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE,
> ID_AA64PFR0_CSV3_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE,
> ID_AA64PFR0_CSV2_SHIFT, 4, 0),
> @@ -158,8 +168,8 @@ static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
> S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
> ID_AA64PFR0_FP_SHIFT, 4, ID_AA64PFR0_FP_NI),
> ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE,
> ID_AA64PFR0_EL3_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE,
> ID_AA64PFR0_EL2_SHIFT, 4, 0),
> - ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE,
> ID_AA64PFR0_EL1_SHIFT, 4, ID_AA64PFR0_EL1_64BIT_ONLY),
> - ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE,
> ID_AA64PFR0_EL0_SHIFT, 4, ID_AA64PFR0_EL0_64BIT_ONLY),
> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE,
> ID_AA64PFR0_EL1_SHIFT, 4, ID_AA64PFR0_ELx_64BIT_ONLY),
> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE,
> ID_AA64PFR0_EL0_SHIFT, 4, ID_AA64PFR0_ELx_64BIT_ONLY),
> ARM64_FTR_END,
> };
>
> @@ -197,7 +207,7 @@ static const struct arm64_ftr_bits ftr_id_aa64zfr0[] = {
> };
>
> static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = {
> - ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE,
> ID_AA64MMFR0_ECV_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
> ID_AA64MMFR0_ECV_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE,
> ID_AA64MMFR0_FGT_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE,
> ID_AA64MMFR0_EXS_SHIFT, 4, 0),
> /*
> @@ -243,6 +253,7 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = {
> };
>
> static const struct arm64_ftr_bits ftr_id_aa64mmfr1[] = {
> + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
> ID_AA64MMFR1_AFP_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE,
> ID_AA64MMFR1_ETS_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE,
> ID_AA64MMFR1_TWED_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE,
> ID_AA64MMFR1_XNX_SHIFT, 4, 0),
> @@ -588,6 +599,7 @@ void update_system_features(const struct cpuinfo_arm *new)
>
> SANITIZE_ID_REG(isa64, 0, aa64isar0);
> SANITIZE_ID_REG(isa64, 1, aa64isar1);
> + SANITIZE_ID_REG(isa64, 2, aa64isar2);
>
> SANITIZE_ID_REG(zfr64, 0, aa64zfr0);
>
> diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h
> b/xen/arch/arm/include/asm/arm64/sysregs.h
> index eac08ed33f..54670084c3 100644
> --- a/xen/arch/arm/include/asm/arm64/sysregs.h
> +++ b/xen/arch/arm/include/asm/arm64/sysregs.h
> @@ -144,6 +144,30 @@
>
> /* id_aa64isar2 */
> #define ID_AA64ISAR2_CLEARBHB_SHIFT 28
> +#define ID_AA64ISAR2_APA3_SHIFT 12
> +#define ID_AA64ISAR2_GPA3_SHIFT 8
> +#define ID_AA64ISAR2_RPRES_SHIFT4
> +#define ID_AA64ISAR2_WFXT_SHIFT
Re: [PATCH v2 3/4] arm: add ISAR2, MMFR0 and MMFR1 fields in cpufeature
On Tue, 31 May 2022, Bertrand Marquis wrote:
> Complete AA64ISAR2 and AA64MMFR[0-1] with more fields.
> While there add a comment for MMFR bitfields as for other registers in
> the cpuinfo structure definition.
>
> Signed-off-by: Bertrand Marquis
> ---
> Changes in v2:
> - patch introduced to isolate changes in cpufeature.h
> - complete MMFR0 and ISAR2 to sync with sysregs.h status
> ---
> xen/arch/arm/include/asm/cpufeature.h | 28 ++-
> 1 file changed, 23 insertions(+), 5 deletions(-)
>
> diff --git a/xen/arch/arm/include/asm/cpufeature.h
> b/xen/arch/arm/include/asm/cpufeature.h
> index 9649a7afee..57eb6773d3 100644
> --- a/xen/arch/arm/include/asm/cpufeature.h
> +++ b/xen/arch/arm/include/asm/cpufeature.h
> @@ -234,6 +234,7 @@ struct cpuinfo_arm {
> union {
> register_t bits[3];
> struct {
> +/* MMFR0 */
> unsigned long pa_range:4;
> unsigned long asid_bits:4;
> unsigned long bigend:4;
> @@ -242,18 +243,31 @@ struct cpuinfo_arm {
> unsigned long tgranule_16K:4;
> unsigned long tgranule_64K:4;
> unsigned long tgranule_4K:4;
> -unsigned long __res0:32;
> -
> +unsigned long tgranule_16k_2:4;
> +unsigned long tgranule_64k_2:4;
> +unsigned long tgranule_4k:4;
Should be tgranule_4k_2:4
> +unsigned long exs:4;
> +unsigned long __res0:8;
> +unsigned long fgt:4;
> +unsigned long ecv:4;
> +
> +/* MMFR1 */
> unsigned long hafdbs:4;
> unsigned long vmid_bits:4;
> unsigned long vh:4;
> unsigned long hpds:4;
> unsigned long lo:4;
> unsigned long pan:4;
> -unsigned long __res1:8;
> -unsigned long __res2:28;
> +unsigned long specsei:4;
> +unsigned long xnx:4;
> +unsigned long twed:4;
> +unsigned long ets:4;
> +unsigned long __res1:4;
hcx?
> +unsigned long afp:4;
> +unsigned long __res2:12;
ntlbpa
tidcp1
cmow
> unsigned long ecbhb:4;
Strangely enough I am looking at DDI0487H and ecbhb is not there
(D13.2.65). Am I looking at the wrong location?
> +/* MMFR2 */
> unsigned long __res3:64;
> };
> } mm64;
> @@ -297,7 +311,11 @@ struct cpuinfo_arm {
> unsigned long __res2:8;
>
> /* ISAR2 */
> -unsigned long __res3:28;
> +unsigned long wfxt:4;
> +unsigned long rpres:4;
> +unsigned long gpa3:4;
> +unsigned long apa3:4;
> +unsigned long __res3:12;
mops
bc
pac_frac
> unsigned long clearbhb:4;
And again this is not described at D13.2.63. Probably the bhb stuff
didn't make it into the ARM ARM yet.
>
> unsigned long __res4:32;
> --
> 2.25.1
>
[qemu-mainline test] 170809: tolerable FAIL - PUSHED
flight 170809 qemu-mainline real [real] flight 170811 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/170809/ http://logs.test-lab.xenproject.org/osstest/logs/170811/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-libvirt-vhd 16 guest-saverestore fail pass in 170811-retest Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 170802 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 170802 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 170802 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 170802 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 170802 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 170802 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 170802 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 170802 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 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-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-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-qcow2 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 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 version targeted for testing: qemuu1e62a82574fc28e64deca589a23cf55ada2e1a7d baseline version: qemuue2c2d575991cbccc39da81f1b54e78523a24ed11 Last test of basis 170802 2022-06-01 21:38:16 Z
Re: [PATCH V9 2/2] libxl: Introduce basic virtio-mmio support on Arm
On Wed, 1 Jun 2022, Oleksandr Tyshchenko wrote:
> From: Julien Grall
>
> This patch introduces helpers to allocate Virtio MMIO params
> (IRQ and memory region) and create specific device node in
> the Guest device-tree with allocated params. In order to deal
> with multiple Virtio devices, reserve corresponding ranges.
> For now, we reserve 1MB for memory regions and 10 SPIs.
>
> As these helpers should be used for every Virtio device attached
> to the Guest, call them for Virtio disk(s).
>
> Please note, with statically allocated Virtio IRQs there is
> a risk of a clash with a physical IRQs of passthrough devices.
> For the first version, it's fine, but we should consider allocating
> the Virtio IRQs automatically. Thankfully, we know in advance which
> IRQs will be used for passthrough to be able to choose non-clashed
> ones.
>
> Signed-off-by: Julien Grall
> Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Stefano Stabellini
> ---
> Please note, this is a split/cleanup/hardening of Julien's PoC:
> "Add support for Guest IO forwarding to a device emulator"
>
> Changes RFC -> V1:
>- was squashed with:
> "[RFC PATCH V1 09/12] libxl: Handle virtio-mmio irq in more correct way"
> "[RFC PATCH V1 11/12] libxl: Insert "dma-coherent" property into
> virtio-mmio device node"
> "[RFC PATCH V1 12/12] libxl: Fix duplicate memory node in DT"
>- move VirtIO MMIO #define-s to xen/include/public/arch-arm.h
>
> Changes V1 -> V2:
>- update the author of a patch
>
> Changes V2 -> V3:
>- no changes
>
> Changes V3 -> V4:
>- no changes
>
> Changes V4 -> V5:
>- split the changes, change the order of the patches
>- drop an extra "virtio" configuration option
>- update patch description
>- use CONTAINER_OF instead of own implementation
>- reserve ranges for Virtio MMIO params and put them
> in correct location
>- create helpers to allocate Virtio MMIO params, add
> corresponding sanity-сhecks
>- add comment why MMIO size 0x200 is chosen
>- update debug print
>- drop Wei's T-b
>
> Changes V5 -> V6:
>- rebase on current staging
>
> Changes V6 -> V7:
>- rebase on current staging
>- add T-b and R-b tags
>- update according to the recent changes to
> "libxl: Add support for Virtio disk configuration"
>
> Changes V7 -> V8:
>- drop T-b and R-b tags
>- make virtio_mmio_base/irq global variables to be local in
> libxl__arch_domain_prepare_config() and initialize them at
> the beginning of the function, then rework alloc_virtio_mmio_base/irq()
> to take a pointer to virtio_mmio_base/irq variables as an argument
>- update according to the recent changes to
> "libxl: Add support for Virtio disk configuration"
>
> Changes V8 -> V9:
>- Stefano already gave his Reviewed-by, I dropped it due to the changes
>- remove the second set of parentheses for check in
> alloc_virtio_mmio_base()
>- clarify the updating of "nr_spis" right after num_disks loop in
> libxl__arch_domain_prepare_config() and add a comment on top of it
>- use GCSPRINTF() instead of using a buffer of a static size
> calculated by hand in make_virtio_mmio_node()
> ---
> tools/libs/light/libxl_arm.c | 121
> +-
> xen/include/public/arch-arm.h | 7 +++
> 2 files changed, 126 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
> index eef1de0..9be9b2a 100644
> --- a/tools/libs/light/libxl_arm.c
> +++ b/tools/libs/light/libxl_arm.c
> @@ -8,6 +8,46 @@
> #include
> #include
>
> +/*
> + * There is no clear requirements for the total size of Virtio MMIO region.
> + * The size of control registers is 0x100 and device-specific configuration
> + * registers starts at the offset 0x100, however it's size depends on the
> device
> + * and the driver. Pick the biggest known size at the moment to cover most
> + * of the devices (also consider allowing the user to configure the size via
> + * config file for the one not conforming with the proposed value).
> + */
> +#define VIRTIO_MMIO_DEV_SIZE xen_mk_ullong(0x200)
> +
> +static uint64_t alloc_virtio_mmio_base(libxl__gc *gc, uint64_t
> *virtio_mmio_base)
> +{
> +uint64_t base = *virtio_mmio_base;
> +
> +/* Make sure we have enough reserved resources */
> +if (base + VIRTIO_MMIO_DEV_SIZE >
> +GUEST_VIRTIO_MMIO_BASE + GUEST_VIRTIO_MMIO_SIZE) {
> +LOG(ERROR, "Ran out of reserved range for Virtio MMIO BASE
> 0x%"PRIx64"\n",
> +base);
> +return 0;
> +}
> +*virtio_mmio_base += VIRTIO_MMIO_DEV_SIZE;
> +
> +return base;
> +}
> +
> +static uint32_t alloc_virtio_mmio_irq(libxl__gc *gc, uint32_t
> *virtio_mmio_irq)
> +{
> +uint32_t irq = *virtio_mmio_irq;
> +
> +/* Make sure we have enough reserved resources */
> +if (irq > GUEST_VIRTIO_MMIO_SPI_LAST) {
> +LOG(ERROR, "Ran out of reserved ra
[PATCH v3] xen/gntdev: Avoid blocking in unmap_grant_pages()
unmap_grant_pages() currently waits for the pages to no longer be used.
In https://github.com/QubesOS/qubes-issues/issues/7481, this lead to a
deadlock against i915: i915 was waiting for gntdev's MMU notifier to
finish, while gntdev was waiting for i915 to free its pages. I also
believe this is responsible for various deadlocks I have experienced in
the past.
Avoid these problems by making unmap_grant_pages async. This requires
making it return void, as any errors will not be available when the
function returns. Fortunately, the only use of the return value is a
WARN_ON(), which can be replaced by a WARN_ON when the error is
detected. Additionally, a failed call will not prevent further calls
from being made, but this is harmless.
Because unmap_grant_pages is now async, the grant handle will be sent to
INVALID_GRANT_HANDLE too late to prevent multiple unmaps of the same
handle. Instead, a separate bool array is allocated for this purpose.
This wastes memory, but stuffing this information in padding bytes is
too fragile. Furthermore, it is necessary to grab a reference to the
map before making the asynchronous call, and release the reference when
the call returns.
It is also necessary to guard against reentrancy in gntdev_map_put(),
and to handle the case where userspace tries to map a mapping whose
contents have not all been freed yet.
Fixes: 745282256c75 ("xen/gntdev: safely unmap grants in case they are still in
use")
Cc: sta...@vger.kernel.org
Signed-off-by: Demi Marie Obenour
---
drivers/xen/gntdev-common.h | 7 ++
drivers/xen/gntdev.c| 153
2 files changed, 109 insertions(+), 51 deletions(-)
diff --git a/drivers/xen/gntdev-common.h b/drivers/xen/gntdev-common.h
index 20d7d059dadb..15c2e3afcc2b 100644
--- a/drivers/xen/gntdev-common.h
+++ b/drivers/xen/gntdev-common.h
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
struct gntdev_dmabuf_priv;
@@ -56,6 +57,7 @@ struct gntdev_grant_map {
struct gnttab_unmap_grant_ref *unmap_ops;
struct gnttab_map_grant_ref *kmap_ops;
struct gnttab_unmap_grant_ref *kunmap_ops;
+ bool *being_removed;
struct page **pages;
unsigned long pages_vm_start;
@@ -73,6 +75,11 @@ struct gntdev_grant_map {
/* Needed to avoid allocation in gnttab_dma_free_pages(). */
xen_pfn_t *frames;
#endif
+
+ /* Number of live grants */
+ atomic_long_t live_grants;
+ /* Needed to avoid allocation in __unmap_grant_pages */
+ struct gntab_unmap_queue_data unmap_data;
};
struct gntdev_grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count,
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 59ffea800079..e8b83ea1eacd 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
@@ -60,10 +61,11 @@ module_param(limit, uint, 0644);
MODULE_PARM_DESC(limit,
"Maximum number of grants that may be mapped by one mapping request");
+/* True in PV mode, false otherwise */
static int use_ptemod;
-static int unmap_grant_pages(struct gntdev_grant_map *map,
-int offset, int pages);
+static void unmap_grant_pages(struct gntdev_grant_map *map,
+ int offset, int pages);
static struct miscdevice gntdev_miscdev;
@@ -120,6 +122,7 @@ static void gntdev_free_map(struct gntdev_grant_map *map)
kvfree(map->unmap_ops);
kvfree(map->kmap_ops);
kvfree(map->kunmap_ops);
+ kvfree(map->being_removed);
kfree(map);
}
@@ -140,10 +143,13 @@ struct gntdev_grant_map *gntdev_alloc_map(struct
gntdev_priv *priv, int count,
add->unmap_ops = kvmalloc_array(count, sizeof(add->unmap_ops[0]),
GFP_KERNEL);
add->pages = kvcalloc(count, sizeof(add->pages[0]), GFP_KERNEL);
+ add->being_removed =
+ kvcalloc(count, sizeof(add->being_removed[0]), GFP_KERNEL);
if (NULL == add->grants||
NULL == add->map_ops ||
NULL == add->unmap_ops ||
- NULL == add->pages)
+ NULL == add->pages ||
+ NULL == add->being_removed)
goto err;
if (use_ptemod) {
add->kmap_ops = kvmalloc_array(count,
sizeof(add->kmap_ops[0]),
@@ -250,9 +256,34 @@ void gntdev_put_map(struct gntdev_priv *priv, struct
gntdev_grant_map *map)
if (!refcount_dec_and_test(&map->users))
return;
- if (map->pages && !use_ptemod)
+ if (map->pages && !use_ptemod) {
+ /*
+* Increment the reference count. This ensures that the
+* subsequent call to unmap_grant_pages() will not wind up
+* re-entering itself. It *can* wind up calling
+* gntdev_put_map() recursively, but such calls will be with a
+* non
[linux-linus test] 170808: regressions - FAIL
flight 170808 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/170808/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-dom0pvh-xl-amd 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-dom0pvh-xl-intel 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-libvirt 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-libvirt-raw 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-xl-seattle 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-freebsd12-amd64 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-libvirt-qcow2 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-xl-pvhv2-intel 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-xl 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-libvirt-xsm 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-xl-pvhv2-amd 14 guest-start fail REGR. vs. 170714 test-arm64-arm64-xl 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-examine 8 reboot fail REGR. vs. 170714 test-arm64-arm64-xl-credit2 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-freebsd11-amd64 13 guest-start fail REGR. vs. 170714 test-amd64-amd64-xl-pvshim 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-pair25 guest-start/debian fail REGR. vs. 170714 test-amd64-amd64-xl-credit1 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-xl-credit2 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-xl-multivcpu 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-xl-xsm 14 guest-start fail REGR. vs. 170714 test-amd64-coresched-amd64-xl 14 guest-start fail REGR. vs. 170714 test-arm64-arm64-xl-credit1 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. vs. 170714 test-arm64-arm64-xl-thunderx 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-libvirt-pair 12 xen-boot/src_host fail REGR. vs. 170714 test-amd64-amd64-libvirt-pair 13 xen-boot/dst_host fail REGR. vs. 170714 test-arm64-arm64-xl-xsm 14 guest-start fail REGR. vs. 170714 test-armhf-armhf-xl-arndale 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 12 debian-hvm-install fail REGR. vs. 170714 test-amd64-amd64-xl-shadow 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-qemuu-nested-amd 12 debian-hvm-install fail REGR. vs. 170714 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 12 debian-hvm-install fail REGR. vs. 170714 test-armhf-armhf-xl-multivcpu 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. vs. 170714 test-amd64-amd64-examine-uefi 8 reboot fail REGR. vs. 170714 test-amd64-amd64-examine-bios 8 reboot fail REGR. vs. 170714 test-amd64-amd64-xl-qemut-debianhvm-amd64 12 debian-hvm-install fail REGR. vs. 170714 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 12 debian-hvm-install fail REGR. vs. 170714 test-amd64-amd64-qemuu-nested-intel 12 debian-hvm-install fail REGR. vs. 170714 test-amd64-amd64-xl-qemuu-debianhvm-amd64 12 debian-hvm-install fail REGR. vs. 170714 test-armhf-armhf-xl-credit2 14 guest-start fail REGR. vs. 170714 test-armhf-armhf-xl-credit1 14 guest-start fail REGR. vs. 170714 test-armhf-armhf-xl-cubietruck 14 guest-startfail REGR. vs. 170714 test-amd64-amd64-examine 8 reboot fail REGR. vs. 170714 test-arm64-arm64-libvirt-xsm 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 12 debian-hvm-install fail REGR. vs. 170714 test-amd64-amd64-pygrub 12 debian-di-installfail REGR. vs. 170714 test-amd64-amd64-xl-vhd 12 debian-di-installfail REGR. vs. 170714 test-armhf-armhf-libvirt 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 170714 test-arm64-arm64-xl-vhd 12 debian-di-installfail REGR. vs. 170714 test-arm64-arm64-libvirt-raw 12 debian-di-installfail REGR. vs. 170714 test-armhf-armhf-libvirt-qcow2 12 debian-di-install fail REGR. vs. 170714 test-armhf-armhf-xl 14 guest-start fail REGR. vs. 170714 test-armhf-armhf-xl-vhd 12 debian-di-installfail REGR. vs. 170714 test-armhf-armhf-libvirt-raw 12 debian-di-install fail in 170805 REGR. vs. 170714 Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-raw 10 host-ping-check-xenfail p
Re: [PATCH v2 0/3] PIIX3-IDE XEN cleanup
On Saturday, May 28, 2022, Bernhard Beschow wrote: > Am 13. Mai 2022 18:09:54 UTC schrieb Bernhard Beschow : >>v2: >>* Have pci_xen_ide_unplug() return void (Paul Durrant) >>* CC Xen maintainers (Michael S. Tsirkin) >> >>v1: >>This patch series first removes the redundant "piix3-ide-xen" device class and >>then moves a XEN-specific helper function from PIIX3 code to XEN code. The idea >>is to decouple PIIX3-IDE and XEN and to compile XEN-specific bits only if XEN >>support is enabled. >> >>Testing done: >>'qemu-system-x86_64 -M pc -m 1G -cdrom archlinux-2022.05.01-x86_64.iso" boots >>successfully and a 'poweroff' inside the VM also shuts it down correctly. >> >>XEN mode wasn't tested for the time being since its setup procedure seems quite >>sophisticated. Please let me know in case this is an obstacle. >> >>Bernhard Beschow (3): >> hw/ide/piix: Remove redundant "piix3-ide-xen" device class >> hw/ide/piix: Add some documentation to pci_piix3_xen_ide_unplug() >> include/hw/ide: Unexport pci_piix3_xen_ide_unplug() >> >> hw/i386/pc_piix.c | 3 +-- >> hw/i386/xen/xen_platform.c | 48 +- >> hw/ide/piix.c | 42 - >> include/hw/ide.h | 3 --- >> 4 files changed, 48 insertions(+), 48 deletions(-) >> > > Ping > > Whole series is reviewed/acked. Ping 2
Re: [PATCH v8 2/2] flask: implement xsm_set_system_active
On 6/2/22 16:32, Daniel P. Smith wrote: > On 5/31/22 10:56, Daniel P. Smith wrote: >> This commit implements full support for starting the idle domain privileged >> by >> introducing a new flask label xenboot_t which the idle domain is labeled with >> at creation. It then provides the implementation for the XSM hook >> xsm_set_system_active to relabel the idle domain to the existing xen_t flask >> label. >> >> In the reference flask policy a new macro, xen_build_domain(target), is >> introduced for creating policies for dom0less/hyperlaunch allowing the >> hypervisor to create and assign the necessary resources for domain >> construction. >> >> Signed-off-by: Daniel P. Smith >> Reviewed-by: Jason Andryuk >> Reviewed-by: Luca Fancellu >> Tested-by: Luca Fancellu > > I am still debugging, but I now have a dom0 crashing due to an AVC that > is being tripped with this patch applied to the tip of staging. I just > wanted to give a heads-up, and I will follow back up once I can > determine the root cause. Please ignore and my apologies for the noise. The updated policy file was not getting synced into the test environment. v/r, dps
Re: [PATCH v8 2/2] flask: implement xsm_set_system_active
On 5/31/22 10:56, Daniel P. Smith wrote: > This commit implements full support for starting the idle domain privileged by > introducing a new flask label xenboot_t which the idle domain is labeled with > at creation. It then provides the implementation for the XSM hook > xsm_set_system_active to relabel the idle domain to the existing xen_t flask > label. > > In the reference flask policy a new macro, xen_build_domain(target), is > introduced for creating policies for dom0less/hyperlaunch allowing the > hypervisor to create and assign the necessary resources for domain > construction. > > Signed-off-by: Daniel P. Smith > Reviewed-by: Jason Andryuk > Reviewed-by: Luca Fancellu > Tested-by: Luca Fancellu I am still debugging, but I now have a dom0 crashing due to an AVC that is being tripped with this patch applied to the tip of staging. I just wanted to give a heads-up, and I will follow back up once I can determine the root cause. v/r, dps
Re: [PATCH V2] libxl/arm: Create specific IOMMU node to be referred by virtio-mmio device
On 01.06.22 23:39, Stefano Stabellini wrote:
Hello Stefano
On Wed, 1 Jun 2022, Oleksandr wrote:
On 01.06.22 04:04, Stefano Stabellini wrote:
On Tue, 31 May 2022, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Reuse generic IOMMU device tree bindings to communicate Xen specific
information for the virtio devices for which the restricted memory
access using Xen grant mappings need to be enabled.
Insert "iommus" property pointed to the IOMMU node with "xen,grant-dma"
compatible to all virtio devices which backends are going to run in
non-hardware domains (which are non-trusted by default).
Based on device-tree binding from Linux:
Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
The example of generated nodes:
xen_iommu {
compatible = "xen,grant-dma";
#iommu-cells = <0x01>;
phandle = <0xfde9>;
};
virtio@200 {
compatible = "virtio,mmio";
reg = <0x00 0x200 0x00 0x200>;
interrupts = <0x00 0x01 0xf01>;
interrupt-parent = <0xfde8>;
dma-coherent;
iommus = <0xfde9 0x01>;
};
virtio@2000200 {
compatible = "virtio,mmio";
reg = <0x00 0x2000200 0x00 0x200>;
interrupts = <0x00 0x02 0xf01>;
interrupt-parent = <0xfde8>;
dma-coherent;
iommus = <0xfde9 0x01>;
};
Signed-off-by: Oleksandr Tyshchenko
---
!!! This patch is based on non upstreamed yet “Virtio support for
toolstack
on Arm” V8 series which is on review now:
https://lore.kernel.org/xen-devel/1651598763-12162-1-git-send-email-olekst...@gmail.com/
New device-tree binding (commit #5) is a part of solution to restrict
memory
access under Xen using xen-grant DMA-mapping layer (which is also on
review):
https://lore.kernel.org/xen-devel/1653944417-17168-1-git-send-email-olekst...@gmail.com/
Changes RFC -> V1:
- update commit description
- rebase according to the recent changes to
"libxl: Introduce basic virtio-mmio support on Arm"
Changes V1 -> V2:
- Henry already gave his Reviewed-by, I dropped it due to the changes
- use generic IOMMU device tree bindings instead of custom property
"xen,dev-domid"
- change commit subject and description, was
"libxl/arm: Insert "xen,dev-domid" property to virtio-mmio device
node"
---
tools/libs/light/libxl_arm.c | 49
---
xen/include/public/device_tree_defs.h | 1 +
2 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 9be9b2a..72da3b1 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -865,9 +865,32 @@ static int make_vpci_node(libxl__gc *gc, void *fdt,
return 0;
}
+static int make_xen_iommu_node(libxl__gc *gc, void *fdt)
+{
+int res;
+
+/* See Linux
Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml */
+res = fdt_begin_node(fdt, "xen_iommu");
+if (res) return res;
+
+res = fdt_property_compat(gc, fdt, 1, "xen,grant-dma");
+if (res) return res;
+
+res = fdt_property_cell(fdt, "#iommu-cells", 1);
+if (res) return res;
+
+res = fdt_property_cell(fdt, "phandle", GUEST_PHANDLE_IOMMU);
+if (res) return res;
+
+res = fdt_end_node(fdt);
+if (res) return res;
+
+return 0;
+}
static int make_virtio_mmio_node(libxl__gc *gc, void *fdt,
- uint64_t base, uint32_t irq)
+ uint64_t base, uint32_t irq,
+ uint32_t backend_domid)
{
int res;
gic_interrupt intr;
@@ -890,6 +913,16 @@ static int make_virtio_mmio_node(libxl__gc *gc, void
*fdt,
res = fdt_property(fdt, "dma-coherent", NULL, 0);
if (res) return res;
+if (backend_domid != LIBXL_TOOLSTACK_DOMID) {
+uint32_t iommus_prop[2];
+
+iommus_prop[0] = cpu_to_fdt32(GUEST_PHANDLE_IOMMU);
+iommus_prop[1] = cpu_to_fdt32(backend_domid);
+
+res = fdt_property(fdt, "iommus", iommus_prop,
sizeof(iommus_prop));
+if (res) return res;
+}
+
res = fdt_end_node(fdt);
if (res) return res;
@@ -1097,6 +1130,7 @@ static int libxl__prepare_dtb(libxl__gc *gc,
libxl_domain_config *d_config,
size_t fdt_size = 0;
int pfdt_size = 0;
libxl_domain_build_info *const info = &d_config->b_info;
+bool iommu_created;
unsigned int i;
const libxl_version_info *vers;
@@ -1204,11 +1238,20 @@ next_resize:
if (d_config->num_pcidevs)
FDT( make_vpci_node(gc, fdt, ainfo, dom) );
+iommu_created = false;
for (i = 0; i < d_config->num_disks; i++) {
libxl_device_disk *disk = &d_config->disks[i];
-if (disk->specification == LIBXL_DISK_SPECIFICATION_VIRTIO)
-FDT( make_virtio_mmio_node(gc, fdt, disk->base,
disk->irq) );
+if (disk->specification == LIBXL_DISK_SPECIFICATION_VIRTIO) {
+if (disk->back
[PATCH V4 7/8] xen/grant-dma-ops: Retrieve the ID of backend's domain for DT devices
From: Oleksandr Tyshchenko
Use the presence of "iommus" property pointed to the IOMMU node with
recently introduced "xen,grant-dma" compatible as a clear indicator
of enabling Xen grant mappings scheme for that device and read the ID
of Xen domain where the corresponding backend is running. The domid
(domain ID) is used as an argument to the Xen grant mapping APIs.
To avoid the deferred probe timeout which takes place after reusing
generic IOMMU device tree bindings (because the IOMMU device never
becomes available) enable recently introduced stub IOMMU driver by
selecting XEN_GRANT_DMA_IOMMU.
Also introduce xen_is_grant_dma_device() to check whether xen-grant
DMA ops need to be set for a passed device.
Remove the hardcoded domid 0 in xen_grant_setup_dma_ops().
Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Stefano Stabellini
---
Changes RFC -> V1:
- new patch, split required changes from commit:
"[PATCH 4/6] virtio: Various updates to xen-virtio DMA ops layer"
- update checks in xen_virtio_setup_dma_ops() to only support
DT devices for now
- remove the "virtio,mmio" check from xen_is_virtio_device()
- remane everything according to the new naming scheme:
s/virtio/grant_dma
Changes V1 -> V2:
- remove dev_is_pci() check in xen_grant_setup_dma_ops()
- remove EXPORT_SYMBOL_GPL(xen_is_grant_dma_device);
Changes V2 -> V3:
- Stefano already gave his Reviewed-by, I dropped it due to the changes
(significant)
- update commit description
- reuse generic IOMMU device tree bindings, select XEN_GRANT_DMA_IOMMU
to avoid the deferred probe timeout
Changes V3 -> V4:
- add Stefano's R-b
---
drivers/xen/Kconfig | 1 +
drivers/xen/grant-dma-ops.c | 48 ++---
include/xen/xen-ops.h | 5 +
3 files changed, 47 insertions(+), 7 deletions(-)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 35d20d9..bfd5f4f 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -347,6 +347,7 @@ config XEN_VIRTIO
bool "Xen virtio support"
depends on VIRTIO
select XEN_GRANT_DMA_OPS
+ select XEN_GRANT_DMA_IOMMU if OF
help
Enable virtio support for running as Xen guest. Depending on the
guest type this will require special support on the backend side
diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index 44659f4..6586152 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -55,11 +55,6 @@ static struct xen_grant_dma_data
*find_xen_grant_dma_data(struct device *dev)
* Such a DMA address is formed by using the grant reference as a frame
* number and setting the highest address bit (this bit is for the backend
* to be able to distinguish it from e.g. a mmio address).
- *
- * Note that for now we hard wire dom0 to be the backend domain. In order
- * to support any domain as backend we'd need to add a way to communicate
- * the domid of this backend, e.g. via Xenstore, via the PCI-device's
- * config space or DT/ACPI.
*/
static void *xen_grant_dma_alloc(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t gfp,
@@ -275,9 +270,26 @@ static const struct dma_map_ops xen_grant_dma_ops = {
.dma_supported = xen_grant_dma_supported,
};
+bool xen_is_grant_dma_device(struct device *dev)
+{
+ struct device_node *iommu_np;
+ bool has_iommu;
+
+ /* XXX Handle only DT devices for now */
+ if (!dev->of_node)
+ return false;
+
+ iommu_np = of_parse_phandle(dev->of_node, "iommus", 0);
+ has_iommu = iommu_np && of_device_is_compatible(iommu_np,
"xen,grant-dma");
+ of_node_put(iommu_np);
+
+ return has_iommu;
+}
+
void xen_grant_setup_dma_ops(struct device *dev)
{
struct xen_grant_dma_data *data;
+ struct of_phandle_args iommu_spec;
data = find_xen_grant_dma_data(dev);
if (data) {
@@ -285,12 +297,34 @@ void xen_grant_setup_dma_ops(struct device *dev)
return;
}
+ /* XXX ACPI device unsupported for now */
+ if (!dev->of_node)
+ goto err;
+
+ if (of_parse_phandle_with_args(dev->of_node, "iommus", "#iommu-cells",
+ 0, &iommu_spec)) {
+ dev_err(dev, "Cannot parse iommus property\n");
+ goto err;
+ }
+
+ if (!of_device_is_compatible(iommu_spec.np, "xen,grant-dma") ||
+ iommu_spec.args_count != 1) {
+ dev_err(dev, "Incompatible IOMMU node\n");
+ of_node_put(iommu_spec.np);
+ goto err;
+ }
+
+ of_node_put(iommu_spec.np);
+
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
goto err;
- /* XXX The dom0 is hardcoded as the backend domain for now */
- data->backend_domid = 0;
+ /*
+* The endpoint ID here means the ID of
[PATCH V4 5/8] dt-bindings: Add xen,grant-dma IOMMU description for xen-grant DMA ops
From: Oleksandr Tyshchenko
The main purpose of this binding is to communicate Xen specific
information using generic IOMMU device tree bindings (which is
a good fit here) rather than introducing a custom property.
Introduce Xen specific IOMMU for the virtualized device (e.g. virtio)
to be used by Xen grant DMA-mapping layer in the subsequent commit.
The reference to Xen specific IOMMU node using "iommus" property
indicates that Xen grant mappings need to be enabled for the device,
and it specifies the ID of the domain where the corresponding backend
resides. The domid (domain ID) is used as an argument to the Xen grant
mapping APIs.
This is needed for the option to restrict memory access using Xen grant
mappings to work which primary goal is to enable using virtio devices
in Xen guests.
Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Stefano Stabellini
---
Changes RFC -> V1:
- update commit subject/description and text in description
- move to devicetree/bindings/arm/
Changes V1 -> V2:
- update text in description
- change the maintainer of the binding
- fix validation issue
- reference xen,dev-domid.yaml schema from virtio/mmio.yaml
Change V2 -> V3:
- Stefano already gave his Reviewed-by, I dropped it due to the changes
(significant)
- use generic IOMMU device tree bindings instead of custom property
"xen,dev-domid"
- change commit subject and description, was
"dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops"
Changes V3 -> V4:
- add Stefano's R-b
- remove underscore in iommu node name
- remove consumer example virtio@3000
- update text for two descriptions
---
.../devicetree/bindings/iommu/xen,grant-dma.yaml | 39 ++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
diff --git a/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
b/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
new file mode 100644
index ..be1539d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iommu/xen,grant-dma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xen specific IOMMU for virtualized devices (e.g. virtio)
+
+maintainers:
+ - Stefano Stabellini
+
+description:
+ The Xen IOMMU represents the Xen grant table interface. Grant mappings
+ are to be used with devices connected to the Xen IOMMU using the "iommus"
+ property, which also specifies the ID of the backend domain.
+ The binding is required to restrict memory access using Xen grant mappings.
+
+properties:
+ compatible:
+const: xen,grant-dma
+
+ '#iommu-cells':
+const: 1
+description:
+ The single cell is the domid (domain ID) of the domain where the backend
+ is running.
+
+required:
+ - compatible
+ - "#iommu-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+iommu {
+compatible = "xen,grant-dma";
+#iommu-cells = <1>;
+};
--
2.7.4
[PATCH V4 8/8] arm/xen: Assign xen-grant DMA ops for xen-grant DMA devices
From: Oleksandr Tyshchenko
By assigning xen-grant DMA ops we will restrict memory access for
passed device using Xen grant mappings. This is needed for using any
virtualized device (e.g. virtio) in Xen guests in a safe manner.
Please note, for the virtio devices the XEN_VIRTIO config should
be enabled (it forces ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS).
Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Stefano Stabellini
---
Changes RFC -> V1:
- update commit subject/description
- remove #ifdef CONFIG_XEN_VIRTIO
- re-organize the check taking into the account that
swiotlb and virtio cases are mutually exclusive
- update according to the new naming scheme:
s/virtio/grant_dma
Changes V1 -> V2:
- add Stefano's R-b
- remove arch_has_restricted_virtio_memory_access() check
- update commit description
- remove the inclusion of virtio_config.h
Changes V2 -> V3:
- no changes
Changes V3 -> V4:
- no changes
---
include/xen/arm/xen-ops.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/xen/arm/xen-ops.h b/include/xen/arm/xen-ops.h
index 288deb1..b0766a6 100644
--- a/include/xen/arm/xen-ops.h
+++ b/include/xen/arm/xen-ops.h
@@ -3,11 +3,14 @@
#define _ASM_ARM_XEN_OPS_H
#include
+#include
static inline void xen_setup_dma_ops(struct device *dev)
{
#ifdef CONFIG_XEN
- if (xen_swiotlb_detect())
+ if (xen_is_grant_dma_device(dev))
+ xen_grant_setup_dma_ops(dev);
+ else if (xen_swiotlb_detect())
dev->dma_ops = &xen_swiotlb_dma_ops;
#endif
}
--
2.7.4
[PATCH V4 3/8] xen/grant-dma-ops: Add option to restrict memory access under Xen
From: Juergen Gross
Introduce Xen grant DMA-mapping layer which contains special DMA-mapping
routines for providing grant references as DMA addresses to be used by
frontends (e.g. virtio) in Xen guests.
Add the needed functionality by providing a special set of DMA ops
handling the needed grant operations for the I/O pages.
The subsequent commit will introduce the use case for xen-grant DMA ops
layer to enable using virtio devices in Xen guests in a safe manner.
Signed-off-by: Juergen Gross
Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Stefano Stabellini
---
Changes RFC -> V1:
- squash with almost all changes from commit (except handling "xen,dev-domid"
property):
"[PATCH 4/6] virtio: Various updates to xen-virtio DMA ops layer"
- update commit subject/description and comments in code
- leave only single Kconfig option XEN_VIRTIO and remove architectural
dependencies
- introduce common xen_has_restricted_virtio_memory_access() in xen.h
and update arch_has_restricted_virtio_memory_access() for both
Arm and x86 to call new helper
- use (1ULL << 63) instead of 0x8000ULL for XEN_GRANT_ADDR_OFF
- implement xen_virtio_dma_map(unmap)_sg() using example in swiotlb-xen.c
- optimize padding by moving "broken" field in struct xen_virtio_data
- remove unneeded per-device spinlock
- remove the inclusion of virtio_config.h
- remane everything according to the new naming scheme:
s/virtio/grant_dma
- add new hidden config option XEN_GRANT_DMA_OPS
Changes V1 -> V2:
- fix checkpatch.pl warnings
- remove the inclusion of linux/pci.h
- rework to use xarray for data context
- remove EXPORT_SYMBOL_GPL(xen_grant_setup_dma_ops);
- remove the line of * after SPDX-License-Identifier
- split changes into grant-dma-ops.c and
arch_has_restricted_virtio_memory_access()
and update commit subject/description accordingly
- remove "default n" for config XEN_VIRTIO
- implement xen_grant_dma_alloc(free)_pages()
Changes V2 -> V3:
- Stefano already gave his Reviewed-by, I dropped it due to the changes
(minor)
- remane field "dev_domid" in struct xen_grant_dma_data to "backend_domid"
- remove local variable "domid" in xen_grant_setup_dma_ops()
Changes V3 -> V4:
- add Stefano's R-b
---
---
drivers/xen/Kconfig | 4 +
drivers/xen/Makefile| 1 +
drivers/xen/grant-dma-ops.c | 311
include/xen/xen-ops.h | 8 ++
4 files changed, 324 insertions(+)
create mode 100644 drivers/xen/grant-dma-ops.c
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 120d32f..313a9127 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -335,4 +335,8 @@ config XEN_UNPOPULATED_ALLOC
having to balloon out RAM regions in order to obtain physical memory
space to create such mappings.
+config XEN_GRANT_DMA_OPS
+ bool
+ select DMA_OPS
+
endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 5aae66e..1a23cb0 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -39,3 +39,4 @@ xen-gntalloc-y:= gntalloc.o
xen-privcmd-y := privcmd.o privcmd-buf.o
obj-$(CONFIG_XEN_FRONT_PGDIR_SHBUF)+= xen-front-pgdir-shbuf.o
obj-$(CONFIG_XEN_UNPOPULATED_ALLOC)+= unpopulated-alloc.o
+obj-$(CONFIG_XEN_GRANT_DMA_OPS)+= grant-dma-ops.o
diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
new file mode 100644
index ..44659f4
--- /dev/null
+++ b/drivers/xen/grant-dma-ops.c
@@ -0,0 +1,311 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Xen grant DMA-mapping layer - contains special DMA-mapping routines
+ * for providing grant references as DMA addresses to be used by frontends
+ * (e.g. virtio) in Xen guests
+ *
+ * Copyright (c) 2021, Juergen Gross
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct xen_grant_dma_data {
+ /* The ID of backend domain */
+ domid_t backend_domid;
+ /* Is device behaving sane? */
+ bool broken;
+};
+
+static DEFINE_XARRAY(xen_grant_dma_devices);
+
+#define XEN_GRANT_DMA_ADDR_OFF (1ULL << 63)
+
+static inline dma_addr_t grant_to_dma(grant_ref_t grant)
+{
+ return XEN_GRANT_DMA_ADDR_OFF | ((dma_addr_t)grant << PAGE_SHIFT);
+}
+
+static inline grant_ref_t dma_to_grant(dma_addr_t dma)
+{
+ return (grant_ref_t)((dma & ~XEN_GRANT_DMA_ADDR_OFF) >> PAGE_SHIFT);
+}
+
+static struct xen_grant_dma_data *find_xen_grant_dma_data(struct device *dev)
+{
+ struct xen_grant_dma_data *data;
+
+ xa_lock(&xen_grant_dma_devices);
+ data = xa_load(&xen_grant_dma_devices, (unsigned long)dev);
+ xa_unlock(&xen_grant_dma_devices);
+
+ return data;
+}
+
+/*
+ * DMA ops for Xen frontends (e.g. virtio).
+ *
+ * Used to act as a kind of software IOMMU for Xen guests by using grants as
+ * DMA addresses.
+
[PATCH V4 4/8] xen/virtio: Enable restricted memory access using Xen grant mappings
From: Juergen Gross
In order to support virtio in Xen guests add a config option XEN_VIRTIO
enabling the user to specify whether in all Xen guests virtio should
be able to access memory via Xen grant mappings only on the host side.
Also set PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS feature from the guest
initialization code on Arm and x86 if CONFIG_XEN_VIRTIO is enabled.
Signed-off-by: Juergen Gross
Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
---
Changes V1 -> V2:
- new patch, split required changes from commit:
"[PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen"
- rework according to new platform_has() infrastructure
Changes V2 -> V3:
- add Stefano's R-b
Changes V3 -> V4:
- add Boris' R-b
---
arch/arm/xen/enlighten.c | 2 ++
arch/x86/xen/enlighten_hvm.c | 2 ++
arch/x86/xen/enlighten_pv.c | 2 ++
drivers/xen/Kconfig | 11 +++
include/xen/xen.h| 8
5 files changed, 25 insertions(+)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 07eb69f..1f9c3ba 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -443,6 +443,8 @@ static int __init xen_guest_init(void)
if (!xen_domain())
return 0;
+ xen_set_restricted_virtio_memory_access();
+
if (!acpi_disabled)
xen_acpi_guest_init();
else
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index 517a9d8..8b71b1d 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -195,6 +195,8 @@ static void __init xen_hvm_guest_init(void)
if (xen_pv_domain())
return;
+ xen_set_restricted_virtio_memory_access();
+
init_hvm_pv_info();
reserve_shared_info();
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index ca85d14..30d24fe 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -108,6 +108,8 @@ static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
static void __init xen_pv_init_platform(void)
{
+ xen_set_restricted_virtio_memory_access();
+
populate_extra_pte(fix_to_virt(FIX_PARAVIRT_BOOTMAP));
set_fixmap(FIX_PARAVIRT_BOOTMAP, xen_start_info->shared_info);
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 313a9127..a7bd8ce 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -339,4 +339,15 @@ config XEN_GRANT_DMA_OPS
bool
select DMA_OPS
+config XEN_VIRTIO
+ bool "Xen virtio support"
+ depends on VIRTIO
+ select XEN_GRANT_DMA_OPS
+ help
+ Enable virtio support for running as Xen guest. Depending on the
+ guest type this will require special support on the backend side
+ (qemu or kernel, depending on the virtio device types used).
+
+ If in doubt, say n.
+
endmenu
diff --git a/include/xen/xen.h b/include/xen/xen.h
index a99bab8..0780a81 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -52,6 +52,14 @@ bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
extern u64 xen_saved_max_mem_size;
#endif
+#include
+
+static inline void xen_set_restricted_virtio_memory_access(void)
+{
+ if (IS_ENABLED(CONFIG_XEN_VIRTIO) && xen_domain())
+ platform_set(PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS);
+}
+
#ifdef CONFIG_XEN_UNPOPULATED_ALLOC
int xen_alloc_unpopulated_pages(unsigned int nr_pages, struct page **pages);
void xen_free_unpopulated_pages(unsigned int nr_pages, struct page **pages);
--
2.7.4
[PATCH V4 0/8] virtio: Solution to restrict memory access under Xen using xen-grant DMA-mapping layer
From: Oleksandr Tyshchenko Hello all. The purpose of this patch series is to add support for restricting memory access under Xen using specific grant table [1] based DMA-mapping layer. Patch series is based on Juergen Gross’ initial work [2] which implies using grant references instead of raw guest physical addresses (GPA) for the virtio communications (some kind of the software IOMMU). You can find RFC-V3 patch series (and previous discussions) at [3]. !!! Please note, the only diff between V3 and V4 is in commit #5, also I have collected the acks (commits ##4-7). The high level idea is to create new Xen’s grant table based DMA-mapping layer for the guest Linux whose main purpose is to provide a special 64-bit DMA address which is formed by using the grant reference (for a page to be shared with the backend) with offset and setting the highest address bit (this is for the backend to be able to distinguish grant ref based DMA address from normal GPA). For this to work we need the ability to allocate contiguous (consecutive) grant references for multi-page allocations. And the backend then needs to offer VIRTIO_F_ACCESS_PLATFORM and VIRTIO_F_VERSION_1 feature bits (it must support virtio-mmio modern transport for 64-bit addresses in the virtqueue). Xen's grant mapping mechanism is the secure and safe solution to share pages between domains which proven to work and works for years (in the context of traditional Xen PV drivers for example). So far, the foreign mapping is used for the virtio backend to map and access guest memory. With the foreign mapping, the backend is able to map arbitrary pages from the guest memory (or even from Dom0 memory). And as the result, the malicious backend which runs in a non-trusted domain can take advantage of this. Instead, with the grant mapping the backend is only allowed to map pages which were explicitly granted by the guest before and nothing else. According to the discussions in various mainline threads this solution would likely be welcome because it perfectly fits in the security model Xen provides. What is more, the grant table based solution requires zero changes to the Xen hypervisor itself at least with virtio-mmio and DT (in comparison, for example, with "foreign mapping + virtio-iommu" solution which would require the whole new complex emulator in hypervisor in addition to new functionality/hypercall to pass IOVA from the virtio backend running elsewhere to the hypervisor and translate it to the GPA before mapping into P2M or denying the foreign mapping request if no corresponding IOVA-GPA mapping present in the IOMMU page table for that particular device). We only need to update toolstack to insert "xen,grant-dma" IOMMU node (to be referred by the virtio-mmio device using "iommus" property) when creating a guest device-tree (this is an indicator for the guest to use Xen grant mappings scheme for that device with the endpoint ID being used as ID of Xen domain where the corresponding backend is running, the backend domid is used as an argument to the grant mapping APIs). It worth mentioning that toolstack patch is based on non upstreamed yet “Virtio support for toolstack on Arm” series which is on review now [4]. Please note the following: - Patch series only covers Arm and virtio-mmio (device-tree) for now. To enable the restricted memory access feature on Arm the following option should be set: CONFIG_XEN_VIRTIO=y - Patch series is based on "kernel: add new infrastructure for platform_has() support" patch series which is on review now [5] - Xen should be built with the following options: CONFIG_IOREQ_SERVER=y CONFIG_EXPERT=y Patch series is rebased on "for-linus-5.19" branch [1] with "platform_has()" series applied and tested on Renesas Salvator-X board + H3 ES3.0 SoC (Arm64) with standalone userspace (non-Qemu) virtio-mmio based virtio-disk backend running in Driver domain and Linux guest running on existing virtio-blk driver (frontend). No issues were observed. Guest domain 'reboot/destroy' use-cases work properly. I have also tested other use-cases such as assigning several virtio block devices or a mix of virtio and Xen PV block devices to the guest. Patch series was build-tested on Arm32 and x86. 1. Xen changes located at (last patch): https://github.com/otyshchenko1/xen/commits/libxl_virtio_next2_1 2. Linux changes located at (last 8 patches): https://github.com/otyshchenko1/linux/commits/virtio_grant9 3. virtio-disk changes located at: https://github.com/otyshchenko1/virtio-disk/commits/virtio_grant Any feedback/help would be highly appreciated. [1] https://xenbits.xenproject.org/docs/4.16-testing/misc/grant-tables.txt [2] https://www.youtube.com/watch?v=IrlEdaIUDPk [3] https://lore.kernel.org/xen-devel/1649963973-22879-1-git-send-email-olekst...@gmail.com/ https://lore.kernel.org/xen-devel/1650646263-22047-1-git-send-email-olekst...@gmail.com/ https://lore.kernel.org/xen-devel/1651947548
[PATCH V4 6/8] xen/grant-dma-iommu: Introduce stub IOMMU driver
From: Oleksandr Tyshchenko
In order to reuse generic IOMMU device tree bindings by Xen grant
DMA-mapping layer we need to add this stub driver from a fw_devlink
perspective (grant-dma-ops cannot be converted into the proper
IOMMU driver).
Otherwise, just reusing IOMMU bindings (without having a corresponding
driver) leads to the deferred probe timeout afterwards, because
the IOMMU device never becomes available.
This stub driver does nothing except registering empty iommu_ops,
the upper layer "of_iommu" will treat this as NO_IOMMU condition
and won't return -EPROBE_DEFER.
As this driver is quite different from the most hardware IOMMU
implementations and only needed in Xen guests, place it in drivers/xen
directory. The subsequent commit will make use of it.
Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Stefano Stabellini
---
According to the discussion at:
https://lore.kernel.org/xen-devel/c0f78aab-e723-fe00-a310-9fe52ec75...@gmail.com/
Change V2 -> V3:
- new patch
Changes V3 -> V4:
- add Stefano's R-b
---
drivers/xen/Kconfig | 4 +++
drivers/xen/Makefile | 1 +
drivers/xen/grant-dma-iommu.c | 78 +++
3 files changed, 83 insertions(+)
create mode 100644 drivers/xen/grant-dma-iommu.c
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index a7bd8ce..35d20d9 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -335,6 +335,10 @@ config XEN_UNPOPULATED_ALLOC
having to balloon out RAM regions in order to obtain physical memory
space to create such mappings.
+config XEN_GRANT_DMA_IOMMU
+ bool
+ select IOMMU_API
+
config XEN_GRANT_DMA_OPS
bool
select DMA_OPS
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 1a23cb0..c0503f1 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -40,3 +40,4 @@ xen-privcmd-y := privcmd.o
privcmd-buf.o
obj-$(CONFIG_XEN_FRONT_PGDIR_SHBUF)+= xen-front-pgdir-shbuf.o
obj-$(CONFIG_XEN_UNPOPULATED_ALLOC)+= unpopulated-alloc.o
obj-$(CONFIG_XEN_GRANT_DMA_OPS)+= grant-dma-ops.o
+obj-$(CONFIG_XEN_GRANT_DMA_IOMMU) += grant-dma-iommu.o
diff --git a/drivers/xen/grant-dma-iommu.c b/drivers/xen/grant-dma-iommu.c
new file mode 100644
index ..16b8bc0
--- /dev/null
+++ b/drivers/xen/grant-dma-iommu.c
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Stub IOMMU driver which does nothing.
+ * The main purpose of it being present is to reuse generic IOMMU device tree
+ * bindings by Xen grant DMA-mapping layer.
+ *
+ * Copyright (C) 2022 EPAM Systems Inc.
+ */
+
+#include
+#include
+#include
+
+struct grant_dma_iommu_device {
+ struct device *dev;
+ struct iommu_device iommu;
+};
+
+/* Nothing is really needed here */
+static const struct iommu_ops grant_dma_iommu_ops;
+
+static const struct of_device_id grant_dma_iommu_of_match[] = {
+ { .compatible = "xen,grant-dma" },
+ { },
+};
+
+static int grant_dma_iommu_probe(struct platform_device *pdev)
+{
+ struct grant_dma_iommu_device *mmu;
+ int ret;
+
+ mmu = devm_kzalloc(&pdev->dev, sizeof(*mmu), GFP_KERNEL);
+ if (!mmu)
+ return -ENOMEM;
+
+ mmu->dev = &pdev->dev;
+
+ ret = iommu_device_register(&mmu->iommu, &grant_dma_iommu_ops,
&pdev->dev);
+ if (ret)
+ return ret;
+
+ platform_set_drvdata(pdev, mmu);
+
+ return 0;
+}
+
+static int grant_dma_iommu_remove(struct platform_device *pdev)
+{
+ struct grant_dma_iommu_device *mmu = platform_get_drvdata(pdev);
+
+ platform_set_drvdata(pdev, NULL);
+ iommu_device_unregister(&mmu->iommu);
+
+ return 0;
+}
+
+static struct platform_driver grant_dma_iommu_driver = {
+ .driver = {
+ .name = "grant-dma-iommu",
+ .of_match_table = grant_dma_iommu_of_match,
+ },
+ .probe = grant_dma_iommu_probe,
+ .remove = grant_dma_iommu_remove,
+};
+
+static int __init grant_dma_iommu_init(void)
+{
+ struct device_node *iommu_np;
+
+ iommu_np = of_find_matching_node(NULL, grant_dma_iommu_of_match);
+ if (!iommu_np)
+ return 0;
+
+ of_node_put(iommu_np);
+
+ return platform_driver_register(&grant_dma_iommu_driver);
+}
+subsys_initcall(grant_dma_iommu_init);
--
2.7.4
[PATCH V4 1/8] arm/xen: Introduce xen_setup_dma_ops()
From: Oleksandr Tyshchenko
This patch introduces new helper and places it in new header.
The helper's purpose is to assign any Xen specific DMA ops in
a single place. For now, we deal with xen-swiotlb DMA ops only.
The one of the subsequent commits in current series will add
xen-grant DMA ops case.
Also re-use the xen_swiotlb_detect() check on Arm32.
Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Stefano Stabellini
[For arm64]
Acked-by: Catalin Marinas
---
Changes RFC -> V1:
- update commit description
- move commit to the beginning of the series
- move #ifdef CONFIG_XEN from dma-mapping.c to xen-ops.h
Changes V1 -> V2:
- add Stefano's R-b
- add missing SPDX-License-Identifier to xen-ops.h
Changes V2 -> V3:
- add Catalin's A-b
Changes V3 -> V4:
- no changes
---
arch/arm/include/asm/xen/xen-ops.h | 2 ++
arch/arm/mm/dma-mapping.c| 7 ++-
arch/arm64/include/asm/xen/xen-ops.h | 2 ++
arch/arm64/mm/dma-mapping.c | 7 ++-
include/xen/arm/xen-ops.h| 15 +++
5 files changed, 23 insertions(+), 10 deletions(-)
create mode 100644 arch/arm/include/asm/xen/xen-ops.h
create mode 100644 arch/arm64/include/asm/xen/xen-ops.h
create mode 100644 include/xen/arm/xen-ops.h
diff --git a/arch/arm/include/asm/xen/xen-ops.h
b/arch/arm/include/asm/xen/xen-ops.h
new file mode 100644
index ..7ebb7eb
--- /dev/null
+++ b/arch/arm/include/asm/xen/xen-ops.h
@@ -0,0 +1,2 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#include
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 82ffac6..059cce0 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -33,7 +33,7 @@
#include
#include
#include
-#include
+#include
#include "dma.h"
#include "mm.h"
@@ -2287,10 +2287,7 @@ void arch_setup_dma_ops(struct device *dev, u64
dma_base, u64 size,
set_dma_ops(dev, dma_ops);
-#ifdef CONFIG_XEN
- if (xen_initial_domain())
- dev->dma_ops = &xen_swiotlb_dma_ops;
-#endif
+ xen_setup_dma_ops(dev);
dev->archdata.dma_ops_setup = true;
}
diff --git a/arch/arm64/include/asm/xen/xen-ops.h
b/arch/arm64/include/asm/xen/xen-ops.h
new file mode 100644
index ..7ebb7eb
--- /dev/null
+++ b/arch/arm64/include/asm/xen/xen-ops.h
@@ -0,0 +1,2 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#include
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 6719f9e..6099c81 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -9,9 +9,9 @@
#include
#include
#include
-#include
#include
+#include
void arch_sync_dma_for_device(phys_addr_t paddr, size_t size,
enum dma_data_direction dir)
@@ -52,8 +52,5 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64
size,
if (iommu)
iommu_setup_dma_ops(dev, dma_base, dma_base + size - 1);
-#ifdef CONFIG_XEN
- if (xen_swiotlb_detect())
- dev->dma_ops = &xen_swiotlb_dma_ops;
-#endif
+ xen_setup_dma_ops(dev);
}
diff --git a/include/xen/arm/xen-ops.h b/include/xen/arm/xen-ops.h
new file mode 100644
index ..288deb1
--- /dev/null
+++ b/include/xen/arm/xen-ops.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_ARM_XEN_OPS_H
+#define _ASM_ARM_XEN_OPS_H
+
+#include
+
+static inline void xen_setup_dma_ops(struct device *dev)
+{
+#ifdef CONFIG_XEN
+ if (xen_swiotlb_detect())
+ dev->dma_ops = &xen_swiotlb_dma_ops;
+#endif
+}
+
+#endif /* _ASM_ARM_XEN_OPS_H */
--
2.7.4
[PATCH V4 2/8] xen/grants: support allocating consecutive grants
From: Juergen Gross
For support of virtio via grant mappings in rare cases larger mappings
using consecutive grants are needed. Support those by adding a bitmap
of free grants.
As consecutive grants will be needed only in very rare cases (e.g. when
configuring a virtio device with a multi-page ring), optimize for the
normal case of non-consecutive allocations.
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
---
Changes RFC -> V1:
- no changes
Changes V1 -> V2:
- no changes
Changes V2 -> V3:
- rebase, move "if (unlikely(ref < GNTTAB_NR_RESERVED_ENTRIES))"
to put_free_entry_locked()
- do not overwrite "i" in gnttab_init(), introduce local max_nr_grefs
- add a comment on top of "while (from < to)" in get_free_seq()
- add Boris' R-b
Changes V3 -> V4:
- no changes
---
drivers/xen/grant-table.c | 251 +++---
include/xen/grant_table.h | 4 +
2 files changed, 219 insertions(+), 36 deletions(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 7a18292..738029d 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -33,6 +33,7 @@
#define pr_fmt(fmt) "xen:" KBUILD_MODNAME ": " fmt
+#include
#include
#include
#include
@@ -70,9 +71,32 @@
static grant_ref_t **gnttab_list;
static unsigned int nr_grant_frames;
+
+/*
+ * Handling of free grants:
+ *
+ * Free grants are in a simple list anchored in gnttab_free_head. They are
+ * linked by grant ref, the last element contains GNTTAB_LIST_END. The number
+ * of free entries is stored in gnttab_free_count.
+ * Additionally there is a bitmap of free entries anchored in
+ * gnttab_free_bitmap. This is being used for simplifying allocation of
+ * multiple consecutive grants, which is needed e.g. for support of virtio.
+ * gnttab_last_free is used to add free entries of new frames at the end of
+ * the free list.
+ * gnttab_free_tail_ptr specifies the variable which references the start
+ * of consecutive free grants ending with gnttab_last_free. This pointer is
+ * updated in a rather defensive way, in order to avoid performance hits in
+ * hot paths.
+ * All those variables are protected by gnttab_list_lock.
+ */
static int gnttab_free_count;
-static grant_ref_t gnttab_free_head;
+static unsigned int gnttab_size;
+static grant_ref_t gnttab_free_head = GNTTAB_LIST_END;
+static grant_ref_t gnttab_last_free = GNTTAB_LIST_END;
+static grant_ref_t *gnttab_free_tail_ptr;
+static unsigned long *gnttab_free_bitmap;
static DEFINE_SPINLOCK(gnttab_list_lock);
+
struct grant_frames xen_auto_xlat_grant_frames;
static unsigned int xen_gnttab_version;
module_param_named(version, xen_gnttab_version, uint, 0);
@@ -168,16 +192,116 @@ static int get_free_entries(unsigned count)
ref = head = gnttab_free_head;
gnttab_free_count -= count;
- while (count-- > 1)
- head = gnttab_entry(head);
+ while (count--) {
+ bitmap_clear(gnttab_free_bitmap, head, 1);
+ if (gnttab_free_tail_ptr == __gnttab_entry(head))
+ gnttab_free_tail_ptr = &gnttab_free_head;
+ if (count)
+ head = gnttab_entry(head);
+ }
gnttab_free_head = gnttab_entry(head);
gnttab_entry(head) = GNTTAB_LIST_END;
+ if (!gnttab_free_count) {
+ gnttab_last_free = GNTTAB_LIST_END;
+ gnttab_free_tail_ptr = NULL;
+ }
+
spin_unlock_irqrestore(&gnttab_list_lock, flags);
return ref;
}
+static int get_seq_entry_count(void)
+{
+ if (gnttab_last_free == GNTTAB_LIST_END || !gnttab_free_tail_ptr ||
+ *gnttab_free_tail_ptr == GNTTAB_LIST_END)
+ return 0;
+
+ return gnttab_last_free - *gnttab_free_tail_ptr + 1;
+}
+
+/* Rebuilds the free grant list and tries to find count consecutive entries. */
+static int get_free_seq(unsigned int count)
+{
+ int ret = -ENOSPC;
+ unsigned int from, to;
+ grant_ref_t *last;
+
+ gnttab_free_tail_ptr = &gnttab_free_head;
+ last = &gnttab_free_head;
+
+ for (from = find_first_bit(gnttab_free_bitmap, gnttab_size);
+from < gnttab_size;
+from = find_next_bit(gnttab_free_bitmap, gnttab_size, to + 1)) {
+ to = find_next_zero_bit(gnttab_free_bitmap, gnttab_size,
+ from + 1);
+ if (ret < 0 && to - from >= count) {
+ ret = from;
+ bitmap_clear(gnttab_free_bitmap, ret, count);
+ from += count;
+ gnttab_free_count -= count;
+ if (from == to)
+ continue;
+ }
+
+ /*
+* Recreate the free list in order to have it properly sorted.
+* This is needed to make sure that the free tail has the
maximum
+* possible size.
Re: [PATCH V3 4/8] xen/virtio: Enable restricted memory access using Xen grant mappings
On 6/2/22 8:49 AM, Oleksandr wrote: On 31.05.22 00:00, Oleksandr Tyshchenko wrote: Hello all. From: Juergen Gross In order to support virtio in Xen guests add a config option XEN_VIRTIO enabling the user to specify whether in all Xen guests virtio should be able to access memory via Xen grant mappings only on the host side. Also set PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS feature from the guest initialization code on Arm and x86 if CONFIG_XEN_VIRTIO is enabled. Signed-off-by: Juergen Gross Signed-off-by: Oleksandr Tyshchenko Reviewed-by: Stefano Stabellini --- Changes V1 -> V2: - new patch, split required changes from commit: "[PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen" - rework according to new platform_has() infrastructure Changes V2 -> V3: - add Stefano's R-b May I please ask for the ack or comments for x86 side here? Reviewed-by: Boris Ostrovsky
[xen-unstable test] 170806: tolerable FAIL
flight 170806 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/170806/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-examine-uefi 6 xen-installfail pass in 170801 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-install fail like 170801 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 170801 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 170801 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 170801 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 170801 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 170801 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 170801 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 170801 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 170801 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 170801 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 170801 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 170801 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 170801 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 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-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail 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-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-ar
[linux-linus test] 170805: regressions - FAIL
flight 170805 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/170805/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-dom0pvh-xl-amd 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-dom0pvh-xl-intel 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-libvirt 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-libvirt-raw 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-xl-seattle 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-freebsd12-amd64 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-libvirt-qcow2 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-xl-pvhv2-intel 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-xl 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-libvirt-xsm 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-xl-pvhv2-amd 14 guest-start fail REGR. vs. 170714 test-arm64-arm64-examine 8 reboot fail REGR. vs. 170714 test-arm64-arm64-xl 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-xl-credit2 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-freebsd11-amd64 13 guest-start fail REGR. vs. 170714 test-amd64-amd64-xl-pvshim 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-pair25 guest-start/debian fail REGR. vs. 170714 test-amd64-amd64-xl-credit1 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-xl-credit2 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-xl-multivcpu 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-xl-xsm 14 guest-start fail REGR. vs. 170714 test-amd64-coresched-amd64-xl 14 guest-start fail REGR. vs. 170714 test-arm64-arm64-xl-credit1 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. vs. 170714 test-arm64-arm64-xl-thunderx 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-libvirt-pair 12 xen-boot/src_host fail REGR. vs. 170714 test-amd64-amd64-libvirt-pair 13 xen-boot/dst_host fail REGR. vs. 170714 test-arm64-arm64-xl-xsm 14 guest-start fail REGR. vs. 170714 test-armhf-armhf-xl-arndale 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 12 debian-hvm-install fail REGR. vs. 170714 test-amd64-amd64-xl-shadow 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-qemuu-nested-amd 12 debian-hvm-install fail REGR. vs. 170714 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 12 debian-hvm-install fail REGR. vs. 170714 test-armhf-armhf-xl-multivcpu 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. vs. 170714 test-amd64-amd64-examine-uefi 8 reboot fail REGR. vs. 170714 test-amd64-amd64-examine-bios 8 reboot fail REGR. vs. 170714 test-amd64-amd64-xl-qemut-debianhvm-amd64 12 debian-hvm-install fail REGR. vs. 170714 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 12 debian-hvm-install fail REGR. vs. 170714 test-amd64-amd64-qemuu-nested-intel 12 debian-hvm-install fail REGR. vs. 170714 test-amd64-amd64-xl-qemuu-debianhvm-amd64 12 debian-hvm-install fail REGR. vs. 170714 test-armhf-armhf-xl-credit2 14 guest-start fail REGR. vs. 170714 test-armhf-armhf-xl-credit1 14 guest-start fail REGR. vs. 170714 test-armhf-armhf-xl-cubietruck 14 guest-startfail REGR. vs. 170714 test-amd64-amd64-examine 8 reboot fail REGR. vs. 170714 test-arm64-arm64-libvirt-xsm 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 12 debian-hvm-install fail REGR. vs. 170714 test-amd64-amd64-pygrub 12 debian-di-installfail REGR. vs. 170714 test-amd64-amd64-xl-vhd 12 debian-di-installfail REGR. vs. 170714 test-armhf-armhf-libvirt 14 guest-start fail REGR. vs. 170714 test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 170714 test-arm64-arm64-xl-vhd 12 debian-di-installfail REGR. vs. 170714 test-armhf-armhf-libvirt-raw 12 debian-di-installfail REGR. vs. 170714 test-arm64-arm64-libvirt-raw 12 debian-di-installfail REGR. vs. 170714 test-armhf-armhf-libvirt-qcow2 12 debian-di-install fail REGR. vs. 170714 test-armhf-armhf-xl 14 guest-start fail REGR. vs. 170714 test-armhf-armhf-xl-vhd 12 debian-di-installfail REGR. vs. 170714 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 14 guest-start fail RE
Re: [PATCH V3 4/8] xen/virtio: Enable restricted memory access using Xen grant mappings
On 31.05.22 00:00, Oleksandr Tyshchenko wrote:
Hello all.
From: Juergen Gross
In order to support virtio in Xen guests add a config option XEN_VIRTIO
enabling the user to specify whether in all Xen guests virtio should
be able to access memory via Xen grant mappings only on the host side.
Also set PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS feature from the guest
initialization code on Arm and x86 if CONFIG_XEN_VIRTIO is enabled.
Signed-off-by: Juergen Gross
Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Stefano Stabellini
---
Changes V1 -> V2:
- new patch, split required changes from commit:
"[PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen"
- rework according to new platform_has() infrastructure
Changes V2 -> V3:
- add Stefano's R-b
May I please ask for the ack or comments for x86 side here?
---
arch/arm/xen/enlighten.c | 2 ++
arch/x86/xen/enlighten_hvm.c | 2 ++
arch/x86/xen/enlighten_pv.c | 2 ++
drivers/xen/Kconfig | 11 +++
include/xen/xen.h| 8
5 files changed, 25 insertions(+)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 07eb69f..1f9c3ba 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -443,6 +443,8 @@ static int __init xen_guest_init(void)
if (!xen_domain())
return 0;
+ xen_set_restricted_virtio_memory_access();
+
if (!acpi_disabled)
xen_acpi_guest_init();
else
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index 517a9d8..8b71b1d 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -195,6 +195,8 @@ static void __init xen_hvm_guest_init(void)
if (xen_pv_domain())
return;
+ xen_set_restricted_virtio_memory_access();
+
init_hvm_pv_info();
reserve_shared_info();
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index ca85d14..30d24fe 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -108,6 +108,8 @@ static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
static void __init xen_pv_init_platform(void)
{
+ xen_set_restricted_virtio_memory_access();
+
populate_extra_pte(fix_to_virt(FIX_PARAVIRT_BOOTMAP));
set_fixmap(FIX_PARAVIRT_BOOTMAP, xen_start_info->shared_info);
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 313a9127..a7bd8ce 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -339,4 +339,15 @@ config XEN_GRANT_DMA_OPS
bool
select DMA_OPS
+config XEN_VIRTIO
+ bool "Xen virtio support"
+ depends on VIRTIO
+ select XEN_GRANT_DMA_OPS
+ help
+ Enable virtio support for running as Xen guest. Depending on the
+ guest type this will require special support on the backend side
+ (qemu or kernel, depending on the virtio device types used).
+
+ If in doubt, say n.
+
endmenu
diff --git a/include/xen/xen.h b/include/xen/xen.h
index a99bab8..0780a81 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -52,6 +52,14 @@ bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
extern u64 xen_saved_max_mem_size;
#endif
+#include
+
+static inline void xen_set_restricted_virtio_memory_access(void)
+{
+ if (IS_ENABLED(CONFIG_XEN_VIRTIO) && xen_domain())
+ platform_set(PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS);
+}
+
#ifdef CONFIG_XEN_UNPOPULATED_ALLOC
int xen_alloc_unpopulated_pages(unsigned int nr_pages, struct page **pages);
void xen_free_unpopulated_pages(unsigned int nr_pages, struct page **pages);
--
Regards,
Oleksandr Tyshchenko
Re: [PATCH] xen-blkfront: Handle NULL gendisk
On 01.06.22 21:53, Jason Andryuk wrote: When a VBD is not fully created and then closed, the kernel can have a NULL pointer dereference: The reproducer is trivial: [user@dom0 ~]$ sudo xl block-attach work backend=sys-usb vdev=xvdi target=/dev/sdz [user@dom0 ~]$ xl block-list work Vdev BE handle state evt-ch ring-ref BE-path 51712 0 2414 -1 -1 /local/domain/0/backend/vbd/241/51712 51728 0 2414 -1 -1 /local/domain/0/backend/vbd/241/51728 51744 0 2414 -1 -1 /local/domain/0/backend/vbd/241/51744 51760 0 2414 -1 -1 /local/domain/0/backend/vbd/241/51760 51840 3 2413 -1 -1 /local/domain/3/backend/vbd/241/51840 ^ note state, the /dev/sdz doesn't exist in the backend [user@dom0 ~]$ sudo xl block-detach work xvdi [user@dom0 ~]$ xl block-list work Vdev BE handle state evt-ch ring-ref BE-path work is an invalid domain identifier And its console has: BUG: kernel NULL pointer dereference, address: 0050 PGD 8000edebb067 P4D 8000edebb067 PUD edec2067 PMD 0 Oops: [#1] PREEMPT SMP PTI CPU: 1 PID: 52 Comm: xenwatch Not tainted 5.16.18-2.43.fc32.qubes.x86_64 #1 RIP: 0010:blk_mq_stop_hw_queues+0x5/0x40 Code: 00 48 83 e0 fd 83 c3 01 48 89 85 a8 00 00 00 41 39 5c 24 50 77 c0 5b 5d 41 5c 41 5d c3 c3 0f 1f 80 00 00 00 00 0f 1f 44 00 00 <8b> 47 50 85 c0 74 32 41 54 49 89 fc 55 53 31 db 49 8b 44 24 48 48 RSP: 0018:c9bcfe98 EFLAGS: 00010293 RAX: c0008370 RBX: 0005 RCX: RDX: RSI: 0005 RDI: RBP: 88800775f000 R08: 0001 R09: 888006e620b8 R10: 888006e620b0 R11: f000 R12: 8880bff39000 R13: 8880bff39000 R14: R15: 88800604be00 FS: () GS:8880f330() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0050 CR3: e932e002 CR4: 003706e0 Call Trace: blkback_changed+0x95/0x137 [xen_blkfront] ? read_reply+0x160/0x160 xenwatch_thread+0xc0/0x1a0 ? do_wait_intr_irq+0xa0/0xa0 kthread+0x16b/0x190 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x22/0x30 Modules linked in: snd_seq_dummy snd_hrtimer snd_seq snd_seq_device snd_timer snd soundcore ipt_REJECT nf_reject_ipv4 xt_state xt_conntrack nft_counter nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables nfnetlink intel_rapl_msr intel_rapl_common crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel xen_netfront pcspkr xen_scsiback target_core_mod xen_netback xen_privcmd xen_gntdev xen_gntalloc xen_blkback xen_evtchn ipmi_devintf ipmi_msghandler fuse bpf_preload ip_tables overlay xen_blkfront CR2: 0050 ---[ end trace 7bc9597fd06ae89d ]--- RIP: 0010:blk_mq_stop_hw_queues+0x5/0x40 Code: 00 48 83 e0 fd 83 c3 01 48 89 85 a8 00 00 00 41 39 5c 24 50 77 c0 5b 5d 41 5c 41 5d c3 c3 0f 1f 80 00 00 00 00 0f 1f 44 00 00 <8b> 47 50 85 c0 74 32 41 54 49 89 fc 55 53 31 db 49 8b 44 24 48 48 RSP: 0018:c9bcfe98 EFLAGS: 00010293 RAX: c0008370 RBX: 0005 RCX: RDX: RSI: 0005 RDI: RBP: 88800775f000 R08: 0001 R09: 888006e620b8 R10: 888006e620b0 R11: f000 R12: 8880bff39000 R13: 8880bff39000 R14: R15: 88800604be00 FS: () GS:8880f330() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0050 CR3: e932e002 CR4: 003706e0 Kernel panic - not syncing: Fatal exception Kernel Offset: disabled info->rq and info->gd are only set in blkfront_connect(), which is called for state 4 (XenbusStateConnected). Guard against using NULL variables in blkfront_closing() to avoid the issue. The rest of blkfront_closing looks okay. If info->nr_rings is 0, then for_each_rinfo won't do anything. blkfront_remove also needs to check for non-NULL pointers before cleaning up the gendisk and request queue. Fixes: 05d69d950d9d "xen-blkfront: sanitize the removal state machine" Reported-by: Marek Marczykowski-Górecki Signed-off-by: Jason Andryuk Reviewed-by: Juergen Gross Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH] xen-blkfront: Handle NULL gendisk
On Thu, Jun 2, 2022 at 2:02 AM Christoph Hellwig wrote: > > On Wed, Jun 01, 2022 at 03:53:41PM -0400, Jason Andryuk wrote: > > When a VBD is not fully created and then closed, the kernel can have a > > NULL pointer dereference: > > > > > > info->rq and info->gd are only set in blkfront_connect(), which is > > called for state 4 (XenbusStateConnected). Guard against using NULL > > variables in blkfront_closing() to avoid the issue. > > > > The rest of blkfront_closing looks okay. If info->nr_rings is 0, then > > for_each_rinfo won't do anything. > > > > blkfront_remove also needs to check for non-NULL pointers before > > cleaning up the gendisk and request queue. > > > > Fixes: 05d69d950d9d "xen-blkfront: sanitize the removal state machine" > > Reported-by: Marek Marczykowski-Górecki > > Signed-off-by: Jason Andryuk > > Tis looks ok, but do we have anything that prevents races between > blkfront_connect, blkfront_closing and blkfront_remove? Thanks for taking a look, Christoph. blkfront_connect and blkfront_closing are called by the state machine in blkback_changed. blkback_changed is the xenbus_driver .otherend_changed callback. The xenwatch kthread calls callbacks synchronously and one at a time, so that seems okay today. blkfront_remove is the xenbus_driver .remove callback, so it is tied to the life cycle of the device. It's called after the otherend_changed callback is unregistered, so those won't run when blkfront_remove is running. Given that, I think it's okay. Regards, Jason
[ovmf test] 170807: all pass - PUSHED
flight 170807 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/170807/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 64706ef761273ba403f9cb3b7a986bfb804c0a87 baseline version: ovmf 62044aa99bcf0a7b1581b24ad8e8f105e48fa15a Last test of basis 170798 2022-06-01 13:11:48 Z0 days Testing same since 170807 2022-06-02 09:13:22 Z0 days1 attempts People who touched revisions under test: Gerd Hoffmann Min Xu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 62044aa99b..64706ef761 64706ef761273ba403f9cb3b7a986bfb804c0a87 -> xen-tested-master
Re: [PATCH v5 6/9] xen/arm: introduce CDF_staticmem
On 02.06.2022 12:07, Penny Zheng wrote:
>> From: Jan Beulich
>> Sent: Tuesday, May 31, 2022 4:41 PM
>>
>> On 31.05.2022 05:12, Penny Zheng wrote:
>>> --- a/xen/arch/arm/include/asm/domain.h
>>> +++ b/xen/arch/arm/include/asm/domain.h
>>> @@ -31,6 +31,10 @@ enum domain_type {
>>>
>>> #define is_domain_direct_mapped(d) ((d)->cdf & CDF_directmap)
>>>
>>> +#ifdef CONFIG_STATIC_MEMORY
>>> +#define is_domain_using_staticmem(d) ((d)->cdf & CDF_staticmem)
>>> +#endif
>>
>> Why is this in the Arm header, rather than ...
>>
>>> --- a/xen/include/xen/domain.h
>>> +++ b/xen/include/xen/domain.h
>>> @@ -34,6 +34,12 @@ void arch_get_domain_info(const struct domain *d,
>>> #ifdef CONFIG_ARM
>>> /* Should domain memory be directly mapped? */
>>> #define CDF_directmap(1U << 1)
>>> +/* Is domain memory on static allocation? */
>>> +#define CDF_staticmem(1U << 2)
>>> +#endif
>>> +
>>> +#ifndef is_domain_using_staticmem
>>> +#define is_domain_using_staticmem(d) ((void)(d), false)
>>> #endif
>>
>> ... here (with what you have here now simply becoming the #else part)?
>> Once living here, I expect it also can be an inline function rather than a
>> macro,
>> with the #ifdef merely inside its body.
>>
>
> In order to avoid bring the chicken and egg problem in
> xen/include/xen/domain.h,
> I may need to move the static inline function to xen/include/xen/sched.h(which
> has already included domain.h header).
Hmm, yes, if made an inline function it would need to move to sched.h.
But as a macro it could live here (without one half needing to live
in the Arm header).
Jan
Re: [PATCH v5 12/15] VT-d: replace all-contiguous page tables by superpage mappings
On Thu, Jun 02, 2022 at 11:58:48AM +0200, Jan Beulich wrote: > On 02.06.2022 11:35, Roger Pau Monné wrote: > > On Fri, May 27, 2022 at 01:19:55PM +0200, Jan Beulich wrote: > >> When a page table ends up with all contiguous entries (including all > >> identical attributes), it can be replaced by a superpage entry at the > >> next higher level. The page table itself can then be scheduled for > >> freeing. > >> > >> The adjustment to LEVEL_MASK is merely to avoid leaving a latent trap > >> for whenever we (and obviously hardware) start supporting 512G mappings. > >> > >> Note that cache sync-ing is likely more strict than necessary. This is > >> both to be on the safe side as well as to maintain the pattern of all > >> updates of (potentially) live tables being accompanied by a flush (if so > >> needed). > >> > >> Signed-off-by: Jan Beulich > >> Reviewed-by: Kevin Tian > > > > Reviewed-by: Roger Pau Monné > > Thanks. > > >> --- > >> Unlike the freeing of all-empty page tables, this causes quite a bit of > >> back and forth for PV domains, due to their mapping/unmapping of pages > >> when they get converted to/from being page tables. It may therefore be > >> worth considering to delay re-coalescing a little, to avoid doing so > >> when the superpage would otherwise get split again pretty soon. But I > >> think this would better be the subject of a separate change anyway. > >> > >> Of course this could also be helped by more "aware" kernel side > >> behavior: They could avoid immediately mapping freed page tables > >> writable again, in anticipation of re-using that same page for another > >> page table elsewhere. > > > > Could we provide an option to select whether to use super-pages for > > IOMMU, so that PV domains could keep the previous behavior? > > Hmm, I did (a while ago) consider adding a command line option, largely > to have something in case of problems, but here you're asking about a > per-domain setting. Possible, sure, but I have to admit I'm always > somewhat hesitant when it comes to changes requiring to touch the tool > stack in non-trivial ways (required besides a separate Dom0 control). Well, per-domain is always better IMO, but I don't want to block you on this, so I guess a command line option would be OK. Per-domain would IMO be helpful in this case because an admin might wish to disable IOMMU super-pages just for PV guests, in order to prevent the back-and-forth in that case. We could also do so with a command line option but it's not the most user-friendly approach. > It's also not clear what granularity we'd want to allow control at: > Just yes/no, or also an upper bound on the page sizes permitted, or > even a map of (dis)allowed page sizes? I would be fine with just yes/no. I don't think we need to complicate the logic, this should be a fallback in case things don't work as expected. > Finally, what would the behavior be for HVM guests using shared page > tables? Should the IOMMU option there also suppress CPU-side large > pages? Or should the IOMMU option, when not fulfillable with shared > page tables, lead to use of separate page tables (and an error if > shared page tables were explicitly requested)? I think the option should error out (or be ignored?) when used with shared page tables, there are already options to control the page sizes for the CPU side page tables, and those should be used when using shared page tables. Thanks, Roger.
[PATCH] x86emul/test: encourage compiler to use more embedded broadcast
For one it was an oversight to leave dup_{hi,lo}() undefined for 512-bit
vector size. And then in FMA testing we can also arrange for the
compiler to (hopefully) recognize broadcasting potential.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/simd.c
+++ b/tools/tests/x86_emulator/simd.c
@@ -912,6 +912,13 @@ static inline vec_t movlhps(vec_t x, vec
})
# endif
# endif
+#elif VEC_SIZE == 64
+# if FLOAT_SIZE == 4
+# define dup_hi(x) B(movshdup, _mask, x, undef(), ~0)
+# define dup_lo(x) B(movsldup, _mask, x, undef(), ~0)
+# elif FLOAT_SIZE == 8
+# define dup_lo(x) B(movddup, _mask, x, undef(), ~0)
+# endif
#endif
#if VEC_SIZE == 16 && defined(__SSSE3__) && !defined(__AVX512VL__)
# if INT_SIZE == 1
--- a/tools/tests/x86_emulator/simd-fma.c
+++ b/tools/tests/x86_emulator/simd-fma.c
@@ -63,6 +63,9 @@ int fma_test(void)
{
unsigned int i;
vec_t x, y, z, src, inv, one;
+#ifdef __AVX512F__
+typeof(one[0]) one_ = 1;
+#endif
for ( i = 0; i < ELEM_COUNT; ++i )
{
@@ -71,6 +74,10 @@ int fma_test(void)
one[i] = 1;
}
+#ifdef __AVX512F__
+# define one one_
+#endif
+
x = (src + one) * inv;
y = (src - one) * inv;
touch(src);
@@ -93,22 +100,28 @@ int fma_test(void)
x = src + inv;
y = src - inv;
touch(inv);
+touch(one);
z = src * one + inv;
if ( !eq(x, z) ) return __LINE__;
touch(inv);
+touch(one);
z = -src * one - inv;
if ( !eq(-x, z) ) return __LINE__;
touch(inv);
+touch(one);
z = src * one - inv;
if ( !eq(y, z) ) return __LINE__;
touch(inv);
+touch(one);
z = -src * one + inv;
if ( !eq(-y, z) ) return __LINE__;
touch(inv);
+#undef one
+
#if defined(addsub) && defined(fmaddsub)
x = addsub(src * inv, one);
y = addsub(src * inv, -one);
[PATCH v2 2/2] x86/mwait-idle: add core C6 optimization for SPR
From: Artem Bityutskiy
Add a Sapphire Rapids Xeon C6 optimization, similar to what we have for Sky Lake
Xeon: if package C6 is disabled, adjust C6 exit latency and target residency to
match core C6 values, instead of using the default package C6 values.
Signed-off-by: Artem Bityutskiy
Signed-off-by: Rafael J. Wysocki
Origin: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
3a9cf77b60dc
Make sure a contradictory "preferred-cstates" wouldn't cause bypassing
of the added logic.
Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
---
v2: Sync with the Linux side fix to the noticed issue. Re-base over
change to earlier patch.
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -1273,18 +1273,31 @@ static void __init skx_idle_state_table_
*/
static void __init spr_idle_state_table_update(void)
{
- /* Check if user prefers C1E over C1. */
- if (preferred_states_mask & BIT(2, U)) {
- if (preferred_states_mask & BIT(1, U))
- /* Both can't be enabled, stick to the defaults. */
- return;
+ uint64_t msr;
+ /* Check if user prefers C1E over C1. */
+ if (preferred_states_mask & BIT(2, U) &&
+ !(preferred_states_mask & BIT(1, U))) {
+ /* Disable C1 and enable C1E. */
spr_cstates[0].flags |= CPUIDLE_FLAG_DISABLED;
spr_cstates[1].flags &= ~CPUIDLE_FLAG_DISABLED;
/* Request enabling C1E using the "C1E promotion" bit. */
idle_cpu_spr.c1e_promotion = C1E_PROMOTION_ENABLE;
}
+
+ /*
+* By default, the C6 state assumes the worst-case scenario of package
+* C6. However, if PC6 is disabled, we update the numbers to match
+* core C6.
+*/
+ rdmsrl(MSR_PKG_CST_CONFIG_CONTROL, msr);
+
+ /* Limit value 2 and above allow for PC6. */
+ if ((msr & 0x7) < 2) {
+ spr_cstates[2].exit_latency = 190;
+ spr_cstates[2].target_residency = 600;
+ }
}
/*
[PATCH v2 1/2] x86/mwait-idle: add 'preferred-cstates' command line option
From: Artem Bityutskiy
On Sapphire Rapids Xeon (SPR) the C1 and C1E states are basically mutually
exclusive - only one of them can be enabled. By default, 'intel_idle' driver
enables C1 and disables C1E. However, some users prefer to use C1E instead of
C1, because it saves more energy.
This patch adds a new module parameter ('preferred_cstates') for enabling C1E
and disabling C1. Here is the idea behind it.
1. This option has effect only for "mutually exclusive" C-states like C1 and
C1E on SPR.
2. It does not have any effect on independent C-states, which do not require
other C-states to be disabled (most states on most platforms as of today).
3. For mutually exclusive C-states, the 'intel_idle' driver always has a
reasonable default, such as enabling C1 on SPR by default. On other
platforms, the default may be different.
4. Users can override the default using the 'preferred_cstates' parameter.
5. The parameter accepts the preferred C-states bit-mask, similarly to the
existing 'states_off' parameter.
6. This parameter is not limited to C1/C1E, and leaves room for supporting
other mutually exclusive C-states, if they come in the future.
Today 'intel_idle' can only be compiled-in, which means that on SPR, in order
to disable C1 and enable C1E, users should boot with the following kernel
argument: intel_idle.preferred_cstates=4
Signed-off-by: Artem Bityutskiy
Signed-off-by: Rafael J. Wysocki
Origin: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
da0e58c038e6
Enable C1E (if requested) not only on the BSP's socket / package. Alter
command line option to fit our model, and extend it to also accept
string form arguments.
Signed-off-by: Jan Beulich
---
v2: Also accept string form arguments for command line option. Restore
C1E-control related enum from Linux, despite our somewhat different
use (and bigger code churn).
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -1885,6 +1885,12 @@ paging controls access to usermode addre
### ple_window (Intel)
> `= `
+### preferred-cstates (x86)
+> `= ( | List of ( C1 | C1E | C2 | ... )`
+
+This is a mask of C-states which are to be used preferably. This option is
+applicable only on hardware were certain C-states are exclusive of one another.
+
### psr (Intel)
> `= List of ( cmt: | rmid_max: | cat: |
> cos_max: | cdp: )`
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -82,10 +82,29 @@ boolean_param("mwait-idle", opt_mwait_id
static unsigned int mwait_substates;
+/*
+ * Some platforms come with mutually exclusive C-states, so that if one is
+ * enabled, the other C-states must not be used. Example: C1 and C1E on
+ * Sapphire Rapids platform. This parameter allows for selecting the
+ * preferred C-states among the groups of mutually exclusive C-states - the
+ * selected C-states will be registered, the other C-states from the mutually
+ * exclusive group won't be registered. If the platform has no mutually
+ * exclusive C-states, this parameter has no effect.
+ */
+static unsigned int __ro_after_init preferred_states_mask;
+static char __initdata preferred_states[64];
+string_param("preferred-cstates", preferred_states);
+
#define LAPIC_TIMER_ALWAYS_RELIABLE 0x
/* Reliable LAPIC Timer States, bit 1 for C1 etc. Default to only C1. */
static unsigned int lapic_timer_reliable_states = (1 << 1);
+enum c1e_promotion {
+ C1E_PROMOTION_PRESERVE,
+ C1E_PROMOTION_ENABLE,
+ C1E_PROMOTION_DISABLE
+};
+
struct idle_cpu {
const struct cpuidle_state *state_table;
@@ -95,7 +114,7 @@ struct idle_cpu {
*/
unsigned long auto_demotion_disable_flags;
bool byt_auto_demotion_disable_flag;
- bool disable_promotion_to_c1e;
+ enum c1e_promotion c1e_promotion;
};
static const struct idle_cpu *icpu;
@@ -924,6 +943,15 @@ static void cf_check byt_auto_demotion_d
wrmsrl(MSR_MC6_DEMOTION_POLICY_CONFIG, 0);
}
+static void cf_check c1e_promotion_enable(void *dummy)
+{
+ uint64_t msr_bits;
+
+ rdmsrl(MSR_IA32_POWER_CTL, msr_bits);
+ msr_bits |= 0x2;
+ wrmsrl(MSR_IA32_POWER_CTL, msr_bits);
+}
+
static void cf_check c1e_promotion_disable(void *dummy)
{
u64 msr_bits;
@@ -936,7 +964,7 @@ static void cf_check c1e_promotion_disab
static const struct idle_cpu idle_cpu_nehalem = {
.state_table = nehalem_cstates,
.auto_demotion_disable_flags = NHM_C1_AUTO_DEMOTE | NHM_C3_AUTO_DEMOTE,
- .disable_promotion_to_c1e = true,
+ .c1e_promotion = C1E_PROMOTION_DISABLE,
};
static const struct idle_cpu idle_cpu_atom = {
@@ -954,64 +982,64 @@ static const struct idle_cpu idle_cpu_li
static const struct idle_cpu idle_cpu_snb = {
.state_table = snb_cstates,
- .disable_promotion_to_c1e = true,
+ .c1e_promotion = C1E_PROMOTION_DISABLE,
};
static const struct idle_cpu idle_cpu_byt = {
.state_table = byt_cstates
[PATCH v2 0/2] x86/mwait-idle: (remaining) SPR support
Still pretty fresh from Linux 5.18 (and with adjustments to address issues noticed while porting. 1: add 'preferred_cstates' module argument 2: add core C6 optimization for SPR Jan
RE: [PATCH v5 6/9] xen/arm: introduce CDF_staticmem
Hi Jan
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, May 31, 2022 4:41 PM
> To: Penny Zheng
> Cc: Wei Chen ; Stefano Stabellini
> ; Julien Grall ; Bertrand Marquis
> ; Volodymyr Babchuk
> ; Andrew Cooper
> ; George Dunlap ;
> Wei Liu ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v5 6/9] xen/arm: introduce CDF_staticmem
>
> On 31.05.2022 05:12, Penny Zheng wrote:
> > --- a/xen/arch/arm/include/asm/domain.h
> > +++ b/xen/arch/arm/include/asm/domain.h
> > @@ -31,6 +31,10 @@ enum domain_type {
> >
> > #define is_domain_direct_mapped(d) ((d)->cdf & CDF_directmap)
> >
> > +#ifdef CONFIG_STATIC_MEMORY
> > +#define is_domain_using_staticmem(d) ((d)->cdf & CDF_staticmem)
> > +#endif
>
> Why is this in the Arm header, rather than ...
>
> > --- a/xen/include/xen/domain.h
> > +++ b/xen/include/xen/domain.h
> > @@ -34,6 +34,12 @@ void arch_get_domain_info(const struct domain *d,
> > #ifdef CONFIG_ARM
> > /* Should domain memory be directly mapped? */
> > #define CDF_directmap(1U << 1)
> > +/* Is domain memory on static allocation? */
> > +#define CDF_staticmem(1U << 2)
> > +#endif
> > +
> > +#ifndef is_domain_using_staticmem
> > +#define is_domain_using_staticmem(d) ((void)(d), false)
> > #endif
>
> ... here (with what you have here now simply becoming the #else part)?
> Once living here, I expect it also can be an inline function rather than a
> macro,
> with the #ifdef merely inside its body.
>
In order to avoid bring the chicken and egg problem in xen/include/xen/domain.h,
I may need to move the static inline function to xen/include/xen/sched.h(which
has already included domain.h header).
> Jan
Re: [PATCH v5 12/15] VT-d: replace all-contiguous page tables by superpage mappings
On 02.06.2022 11:35, Roger Pau Monné wrote: > On Fri, May 27, 2022 at 01:19:55PM +0200, Jan Beulich wrote: >> When a page table ends up with all contiguous entries (including all >> identical attributes), it can be replaced by a superpage entry at the >> next higher level. The page table itself can then be scheduled for >> freeing. >> >> The adjustment to LEVEL_MASK is merely to avoid leaving a latent trap >> for whenever we (and obviously hardware) start supporting 512G mappings. >> >> Note that cache sync-ing is likely more strict than necessary. This is >> both to be on the safe side as well as to maintain the pattern of all >> updates of (potentially) live tables being accompanied by a flush (if so >> needed). >> >> Signed-off-by: Jan Beulich >> Reviewed-by: Kevin Tian > > Reviewed-by: Roger Pau Monné Thanks. >> --- >> Unlike the freeing of all-empty page tables, this causes quite a bit of >> back and forth for PV domains, due to their mapping/unmapping of pages >> when they get converted to/from being page tables. It may therefore be >> worth considering to delay re-coalescing a little, to avoid doing so >> when the superpage would otherwise get split again pretty soon. But I >> think this would better be the subject of a separate change anyway. >> >> Of course this could also be helped by more "aware" kernel side >> behavior: They could avoid immediately mapping freed page tables >> writable again, in anticipation of re-using that same page for another >> page table elsewhere. > > Could we provide an option to select whether to use super-pages for > IOMMU, so that PV domains could keep the previous behavior? Hmm, I did (a while ago) consider adding a command line option, largely to have something in case of problems, but here you're asking about a per-domain setting. Possible, sure, but I have to admit I'm always somewhat hesitant when it comes to changes requiring to touch the tool stack in non-trivial ways (required besides a separate Dom0 control). It's also not clear what granularity we'd want to allow control at: Just yes/no, or also an upper bound on the page sizes permitted, or even a map of (dis)allowed page sizes? Finally, what would the behavior be for HVM guests using shared page tables? Should the IOMMU option there also suppress CPU-side large pages? Or should the IOMMU option, when not fulfillable with shared page tables, lead to use of separate page tables (and an error if shared page tables were explicitly requested)? Jan
Re: [PATCH v2] xen/gntdev: Avoid blocking in unmap_grant_pages()
On 30.05.22 19:50, Demi Marie Obenour wrote: On Mon, May 30, 2022 at 08:41:20AM +0200, Juergen Gross wrote: On 25.05.22 20:41, Demi Marie Obenour wrote: unmap_grant_pages() currently waits for the pages to no longer be used. In https://github.com/QubesOS/qubes-issues/issues/7481, this lead to a deadlock against i915: i915 was waiting for gntdev's MMU notifier to finish, while gntdev was waiting for i915 to free its pages. I also believe this is responsible for various deadlocks I have experienced in the past. Avoid these problems by making unmap_grant_pages async. This requires making it return void, as any errors will not be available when the function returns. Fortunately, the only use of the return value is a WARN_ON(), which can be replaced by a WARN_ON when the error is detected. Additionally, a failed call will not prevent further calls from being made, but this is harmless. Because unmap_grant_pages is now async, the grant handle will be sent to INVALID_GRANT_HANDLE too late to prevent multiple unmaps of the same handle. Instead, a separate bool array is allocated for this purpose. This wastes memory, but stuffing this information in padding bytes is too fragile. Furthermore, it is necessary to grab a reference to the map before making the asynchronous call, and release the reference when the call returns. I think there is even more syncing needed: - In the error path of gntdev_mmap() unmap_grant_pages() is being called and it is assumed, map is available afterwards again. This should be rather easy to avoid by adding a counter of active mappings to struct gntdev_grant_map (number of pages not being unmapped yet). In case this counter is not zero gntdev_mmap() should bail out early. Is it possible to just unmap the pages directly here? I don’t think there can be any other users of these pages yet. Userspace could race against the unmap and cause a page fault, but that should just cause userspace to get SIGSEGV or SIGBUS. In any case this code can use the sync version; if it gets blocked that’s userspace’s problem. - gntdev_put_map() is calling unmap_grant_pages() in case the refcount has dropped to zero. This call can set the refcount to 1 again, so there is another delay needed before freeing map. I think unmap_grant_pages() should return in case the count of mapped pages is zero (see above), thus avoiding to increment the refcount of map if nothing is to be done. This would enable gntdev_put_map() to just return after the call of unmap_grant_pages() in case the refcount has been incremented again. I will change this in v3, but I do wonder if gntdev is using the wrong MMU notifier callback. It seems that the appropriate callback is actually release(): if I understand correctly, release() is called precisely when the refcount on the physical page is about to drop to 0, and that is what we want. No, I don't think this is correct. release() is being called when the refcount of the address space is about to drop to 0. It has no page granularity. Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v4 2/3] xsm: consolidate loading the policy buffer
On 31.05.2022 20:20, Daniel P. Smith wrote:
> Previously, initializing the policy buffer was split between two functions,
> xsm_{multiboot,dt}_policy_init() and xsm_core_init(). The latter for loading
> the policy from boot modules and the former for falling back to built-in
> policy.
>
> This patch moves all policy buffer initialization logic under the
> xsm_{multiboot,dt}_policy_init() functions. It then ensures that an error
> message is printed for every error condition that may occur in the functions.
> With all policy buffer init contained and only called when the policy buffer
> must be populated, the respective xsm_{mb,dt}_init() functions will panic for
> all errors except ENOENT. An ENOENT signifies that a policy file could not be
> located. Since it is not possible to know if late loading of the policy file
> is
> intended, a warning is reported and XSM initialization is continued.
Is it really not possible to know? flask_init() panics in the one case
where a policy is strictly required. And I'm not convinced it is
appropriate to issue both an error and a warning in most (all?) of the
other cases (and it should be at most one of the two anyway imo).
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -775,7 +775,7 @@ int xsm_multiboot_init(
> unsigned long *module_map, const multiboot_info_t *mbi);
> int xsm_multiboot_policy_init(
> unsigned long *module_map, const multiboot_info_t *mbi,
> -void **policy_buffer, size_t *policy_size);
> +const unsigned char *policy_buffer[], size_t *policy_size);
See my v3 comment on the use of [] here. And that comment was actually
made before you sent v4 (unlike the later comment on patch 1). Oh,
actually you did change this in the function definition, just not here.
> @@ -32,14 +32,21 @@
> #ifdef CONFIG_MULTIBOOT
> int __init xsm_multiboot_policy_init(
> unsigned long *module_map, const multiboot_info_t *mbi,
> -void **policy_buffer, size_t *policy_size)
> +const unsigned char **policy_buffer, size_t *policy_size)
> {
> int i;
> module_t *mod = (module_t *)__va(mbi->mods_addr);
> -int rc = 0;
> +int rc = -ENOENT;
> u32 *_policy_start;
> unsigned long _policy_len;
>
> +#ifdef CONFIG_XSM_FLASK_POLICY
> +/* Initially set to builtin policy, overriden if boot module is found. */
Nit: "overridden"
Jan
Re: [PATCH v5 12/15] VT-d: replace all-contiguous page tables by superpage mappings
On Fri, May 27, 2022 at 01:19:55PM +0200, Jan Beulich wrote: > When a page table ends up with all contiguous entries (including all > identical attributes), it can be replaced by a superpage entry at the > next higher level. The page table itself can then be scheduled for > freeing. > > The adjustment to LEVEL_MASK is merely to avoid leaving a latent trap > for whenever we (and obviously hardware) start supporting 512G mappings. > > Note that cache sync-ing is likely more strict than necessary. This is > both to be on the safe side as well as to maintain the pattern of all > updates of (potentially) live tables being accompanied by a flush (if so > needed). > > Signed-off-by: Jan Beulich > Reviewed-by: Kevin Tian Reviewed-by: Roger Pau Monné > --- > Unlike the freeing of all-empty page tables, this causes quite a bit of > back and forth for PV domains, due to their mapping/unmapping of pages > when they get converted to/from being page tables. It may therefore be > worth considering to delay re-coalescing a little, to avoid doing so > when the superpage would otherwise get split again pretty soon. But I > think this would better be the subject of a separate change anyway. > > Of course this could also be helped by more "aware" kernel side > behavior: They could avoid immediately mapping freed page tables > writable again, in anticipation of re-using that same page for another > page table elsewhere. Could we provide an option to select whether to use super-pages for IOMMU, so that PV domains could keep the previous behavior? Thanks, Roger.
Re: [PATCH v4 1/3] xsm: only search for a policy file when needed
On 31.05.2022 20:20, Daniel P. Smith wrote: > It is possible to select a few different build configurations that results in > the unnecessary walking of the boot module list looking for a policy module. > This specifically occurs when the flask policy is enabled but either the dummy > or the SILO policy is selected as the enforcing policy. This is not ideal for > configurations like hyperlaunch and dom0less when there could be a number of > modules to be walked or doing an unnecessary device tree lookup. > > This patch introduces the policy_file_required flag for tracking when an XSM > policy module requires a policy file. Only when the policy_file_required flag > is set to true, will XSM search the boot modules for a policy file. > > Signed-off-by: Daniel P. Smith > Reviewed-by: Jan Beulich > --- > xen/xsm/xsm_core.c | 16 ++-- > 1 file changed, 14 insertions(+), 2 deletions(-) FTAOD my (later) v3 comments still apply; v4 simply appeared too quickly. Jan
Re: [PATCH v5 2/9] xen: do not free reserved memory into heap
On 02.06.2022 04:18, Penny Zheng wrote: >> From: Jan Beulich >> Sent: Tuesday, May 31, 2022 4:37 PM >> >> On 31.05.2022 05:12, Penny Zheng wrote: >>> --- a/xen/common/page_alloc.c >>> +++ b/xen/common/page_alloc.c >>> @@ -151,10 +151,6 @@ >>> #define p2m_pod_offline_or_broken_replace(pg) BUG_ON(pg != NULL) >>> #endif >>> >>> -#ifndef PGC_staticmem >>> -#define PGC_staticmem 0 >>> -#endif >>> - >> >> Is the moving of this into the header really a necessary part of this change? >> Afaics the symbol is still only ever used in this one C file. > > Later, in commit "xen/arm: unpopulate memory when domain is static", > we will use this flag in xen/arch/arm/include/asm/mm.h IOW you want to move this change there. Jan
Re: [XEN PATCH 4/4] build: remove auto.conf prerequisite from compat/xlat.h target
On 01.06.2022 18:59, Anthony PERARD wrote: > Now that the command line generating "xlat.h" is check on rebuild, the > header will be regenerated whenever the list of xlat headers changes > due to change in ".config". We don't need to force a regeneration for > every changes in ".config". This looks to be dependent on only patch 1; I wonder if it shouldn't be viewed as an integral part of that adjustment. Anyway - if you want to keep it on its own: Acked-by: Jan Beulich Jan
Re: [XEN PATCH 1/4] build: xen/include: use if_changed
On 01.06.2022 18:59, Anthony PERARD wrote: > Use "define" for the headers*_chk commands as otherwise the "#" > is interpreted as a comment and make can't find the end of > $(foreach,). In cmd_xlat_lst you use $(pound) - any reason this doesn't work in these rules? Note that I don't mind the use of "define", just that I'm puzzled by the justification. Jan
Re: [XEN PATCH 2/4] build: set PERL
On 01.06.2022 18:59, Anthony PERARD wrote: > --- a/xen/Makefile > +++ b/xen/Makefile > @@ -22,6 +22,7 @@ PYTHON_INTERPRETER := $(word 1,$(shell which python3 > python python2 2>/dev/null) > export PYTHON?= $(PYTHON_INTERPRETER) > > export CHECKPOLICY ?= checkpolicy > +export PERL ?= perl For the intended use, is there a minimum version requirement? If so, it needs documenting in ./README (and it preferably wouldn't be any newer than from around the times our other dependencies are). And even when the uses are fully backwards compatible, I think the need for the tool wants mentioning there. Jan
Re: [PATCH v5 03/15] IOMMU/x86: support freeing of pagetables
On Wed, Jun 01, 2022 at 05:25:16PM +0200, Jan Beulich wrote:
> On 01.06.2022 11:24, Roger Pau Monné wrote:
> > On Wed, Jun 01, 2022 at 09:32:44AM +0200, Jan Beulich wrote:
> >> On 31.05.2022 18:25, Roger Pau Monné wrote:
> >>> On Fri, May 27, 2022 at 01:13:09PM +0200, Jan Beulich wrote:
> @@ -566,6 +567,98 @@ struct page_info *iommu_alloc_pgtable(st
> return pg;
> }
>
> +/*
> + * Intermediate page tables which get replaced by large pages may only
> be
> + * freed after a suitable IOTLB flush. Hence such pages get queued on a
> + * per-CPU list, with a per-CPU tasklet processing the list on the
> assumption
> + * that the necessary IOTLB flush will have occurred by the time
> tasklets get
> + * to run. (List and tasklet being per-CPU has the benefit of accesses
> not
> + * requiring any locking.)
> + */
> +static DEFINE_PER_CPU(struct page_list_head, free_pgt_list);
> +static DEFINE_PER_CPU(struct tasklet, free_pgt_tasklet);
> +
> +static void free_queued_pgtables(void *arg)
> +{
> +struct page_list_head *list = arg;
> +struct page_info *pg;
> +unsigned int done = 0;
> +
> +while ( (pg = page_list_remove_head(list)) )
> +{
> +free_domheap_page(pg);
> +
> +/* Granularity of checking somewhat arbitrary. */
> +if ( !(++done & 0x1ff) )
> + process_pending_softirqs();
> >>>
> >>> Hm, I'm wondering whether we really want to process pending softirqs
> >>> here.
> >>>
> >>> Such processing will prevent the watchdog from triggering, which we
> >>> likely want in production builds. OTOH in debug builds we should make
> >>> sure that free_queued_pgtables() doesn't take longer than a watchdog
> >>> window, or else it's likely to cause issues to guests scheduled on
> >>> this same pCPU (and calling process_pending_softirqs() will just mask
> >>> it).
> >>
> >> Doesn't this consideration apply to about every use of the function we
> >> already have in the code base?
> >
> > Not really, at least when used by init code or by the debug key
> > handlers. This use is IMO different than what I would expect, as it's
> > a guest triggered path that we believe do require such processing.
> > Normally we would use continuations for such long going guest
> > triggered operations.
>
> So what do you suggest I do? Putting the call inside #ifndef CONFIG_DEBUG
> is not a good option imo. Re-scheduling the tasklet wouldn't help, aiui
> (it would still run again right away). Moving the work to another CPU so
> this one can do other things isn't very good either - what if other CPUs
> are similarly busy? Remains making things more complicated here by
> involving a timer, the handler of which would re-schedule the tasklet. I
> have to admit I don't like that very much either. The more that the
> use of process_pending_softirqs() is "just in case" here anyway - if lots
> of page tables were to be queued, I'd expect the queuing entity to be
> preempted before a rather large pile could accumulate.
I would be fine with adding a comment here that we don't expect the
processing of softirqs to be necessary, but it's added merely as a
safety guard.
Long term I think we want to do with the approach of freeing such
pages in guest context before resuming execution, much like how we
defer vPCI BAR mappings using vpci_process_pending. But this requires
some extra work, and we would also need to handle the case of the
freeing being triggered in a remote domain context.
> Maybe I could make iommu_queue_free_pgtable() return non-void, to instruct
> the caller to bubble up a preemption notification once a certain number
> of pages have been queued for freeing. This might end up intrusive ...
Hm, it will end up being pretty arbitrary, as the time taken to free
the pages is very variable depending on the contention on the heap
lock, and hence setting a limit in number of pages will be hard.
Thanks, Roger.
Re: [RFC PATCH 1/4] kconfig: allow configuration of maximum modules
On 01.06.2022 19:35, Julien Grall wrote: > > > On 31/05/2022 11:53, Daniel P. Smith wrote: >> On 5/31/22 05:25, Julien Grall wrote: >>> Hi, >>> >>> On 31/05/2022 03:41, Daniel P. Smith wrote: diff --git a/xen/arch/Kconfig b/xen/arch/Kconfig index f16eb0df43..57b14e22c9 100644 --- a/xen/arch/Kconfig +++ b/xen/arch/Kconfig @@ -17,3 +17,15 @@ config NR_CPUS For CPU cores which support Simultaneous Multi-Threading or similar technologies, this the number of logical threads which Xen will support. + +config NR_BOOTMODS + int "Maximum number of boot modules that a loader can pass" + range 1 64 >>> >>> OOI, any reason to limit the size? >> >> I modelled this entirely after NR_CPUS, which applied a limit > > The limit for NR_CPUS makes sense because there are scalability issues > after that (although 4095 seems quite high) and/or the HW impose a limit. The 4095 is actually a software limit (due to how spinlocks are implemented). >> , and it >> seemed reasonable to me at the time. I choose 64 since it was double >> currently what Arm had set for MAX_MODULES. As such, I have no hard >> reason for there to be a limit. It can easily be removed or adjusted to >> whatever the reviewers feel would be appropriate. > > Ok. In which case I would drop the limit beause it also prevent a users > to create more 64 dom0less domUs (actually a bit less because some > modules are used by Xen). I don't think there are a strong reason to > prevent that, right? At least as per the kconfig language doc the upper bound is not optional, so if a range is specified (which I think it should be, to enforce the lower limit of 1) and upper bound is needed. To address your concern with dom0less - 32768 maybe? Jan
[PATCH v3] SUPPORT.md: extend security support for x86 hosts to 12 TiB of memory
c49ee0329ff3 ("SUPPORT.md: limit security support for hosts with very
much memory"), as a result of XSA-385, restricted security support to
8 TiB of host memory. While subsequently further restricted for Arm,
extend this to 12 TiB on x86, putting in place a guest restriction to
8 TiB (or yet less for Arm) in exchange.
A 12 TiB x86 host was certified successfully for use with Xen 4.14 as
per https://www.suse.com/nbswebapp/yesBulletin.jsp?bulletinNumber=150753.
This in particular included running as many guests (2 TiB each) as
possible in parallel, to actually prove that all the memory can be used
like this. It may be relevant to note that the Optane memory there was
used in memory-only mode, with DRAM acting as cache.
Signed-off-by: Jan Beulich
Acked-by: George Dunlap
---
v3: Correct Arm32 guest value. Restrict guest "leeway" to x86.
v2: Rebase over new host limits for Arm. Refine new guest values for
Arm.
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -50,7 +50,7 @@ For the Cortex A57 r0p0 - r1p1, see Erra
### Physical Memory
-Status, x86: Supported up to 8 TiB. Hosts with more memory are supported,
but not security supported.
+Status, x86: Supported up to 12 TiB. Hosts with more memory are supported,
but not security supported.
Status, Arm32: Supported up to 12 GiB
Status, Arm64: Supported up to 2 TiB
@@ -121,6 +121,14 @@ ARM only has one guest type at the momen
Status: Supported
+## Guest Limits
+
+### Memory
+
+Status, x86: Supported up to 8 TiB. Guests with more memory, but less than
16 TiB, are supported, but not security supported.
+Status, Arm32: Supported up to 12 GiB
+Status, Arm64: Supported up to 1 TiB
+
## Hypervisor file system
### Build info
Re: MOVING COMMUNITY CALL Call for agenda items for 9 June Community Call @ 1500 UTC
On 01.06.2022 22:27, Stefano Stabellini wrote: > Reducing CC and adding fusa-sig > > Actually Jun 9 at 8AM California / 4PM UK doesn't work for some of you, > so it is either: > 1) Jun 9 at 7AM California / 3PM UK > 2) Jun 14 at 8AM California / 4PM UK > > My preference is the first option because it is sooner but let me know > if it doesn't work and we'll try the second option. I don't think I was aware that another call is needed. Was that said somewhere earlier where I did miss it? In any event, either option looks to be okay here. Jan
Re: [PATCH v4 7/8] xen/x86: add detection of memory interleaves for different nodes
On 02.06.2022 06:10, Wei Chen wrote:
> Hi Jan,
>
> On 2022/5/31 21:21, Jan Beulich wrote:
>> On 23.05.2022 08:25, Wei Chen wrote:
>>> @@ -119,20 +125,45 @@ int valid_numa_range(paddr_t start, paddr_t end,
>>> nodeid_t node)
>>> return 0;
>
>>
>> To limit indentation depth, on of the two sides of the conditional can
>> be moved out, by omitting the unnecessary "else". To reduce the diff
>> it may be worthwhile to invert the if() condition, allowing the (then
>> implicit) "else" case to remain (almost) unchanged from the original.
>>
>>> - } else {
>>> + }
>>> +
>>> + case INTERLEAVE:
>>> + {
>>> printk(KERN_ERR
>>> - "SRAT: PXM %u (%"PRIpaddr"-%"PRIpaddr") overlaps with
>>> PXM %u (%"PRIpaddr"-%"PRIpaddr")\n",
>>> - pxm, start, end, node_to_pxm(memblk_nodeid[i]),
>>> + "SRAT： PXM %u: (%"PRIpaddr"-%"PRIpaddr") interleaves
>>> with PXM %u memblk (%"PRIpaddr"-%"PRIpaddr")\n",
>>> + node, nd_start, nd_end, node_to_pxm(memblk_nodeid[i]),
>>
>> Hmm, you have PXM in the log message text, but you still pass "node" as
>> first argument.
>>
>> Since you're touching all these messages, could I ask you to convert
>> all ranges to proper mathematical interval representation? I.e.
>> [start,end) here aiui as the end addresses look to be non-inclusive.
>>
>
> Sorry, I want to confirm with you about this comment again. Now the
> messages look like:
> (XEN) NUMA： PXM 0: (8000-0008d800) interleaves...
>
> So I want to know, is it [8000-0008d800) or
> (8000-0008d7ff) addressed your comment?
> Literally, I think it's case#1?
The former or [8000-0008d7ff]. Parentheses stand for
exclusive boundaries, while square brackets stand for inclusive ones.
Jan
[libvirt test] 170803: regressions - FAIL
flight 170803 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/170803/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: 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 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a version targeted for testing: libvirt 215b2466cd45bd00d4d71db40364384c0bf9313d baseline version: libvirt 2c846fa6bcc11929c9fb857a22430fb9945654ad Last test of basis 151777 2020-07-10 04:19:19 Z 692 days Failing since151818 2020-07-11 04:18:52 Z 691 days 673 attempts Testing same since 170803 2022-06-02 04:20:24 Z0 days1 attempts People who touched revisions under test: Adolfo Jayme Barrientos Aleksandr Alekseev Aleksei Zakharov Amneesh Singh Andika Triwidada Andrea Bolognani Andrew Melnychenko Ani Sinha Balázs Meskó Barrett Schonefeld Bastian Germann Bastien Orivel BiaoXiang Ye Bihong Yu Binfeng Wu Bjoern Walk Boris Fiuczynski Brad Laue Brian Turek Bruno Haible Chris Mayo Christian Borntraeger Christian Ehrhardt Christian Kirbach Christian Schoenebeck Christophe Fergeau Claudio Fontana Cole Robinson Collin Walling Cornelia Huck Cédric Bosdonnat Côme Borsoi Daniel Henrique Barboza Daniel Letai Daniel P. Berrange Daniel P. Berrangé 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 Haonan Wang Hela Basa Helmut Grohne Hiroki Narukawa Hyman Huang(黄勇) Ian Wienand Ioanna Alifieraki Ivan Teterevkov Jakob Meng Jamie Strandboge Jamie Strandboge Jan Kuparinen jason lee Jean-Baptiste Holcroft Jia Zhou Jianan Gao Jim Fehlig Jin Yan Jing Qi Jinsheng Zhang Jiri Denemark Joachim Falk John Ferlan John Levon John Levon Jonathan Watt Jonathon Jongsma Julio Faracco Justin Gatzen Ján Tomko Kashyap Chamarthy Kevin Locke Kim InSoo Koichi Murase Kristina Hanicova Laine Stump Laszlo Ersek Lee Yarwood Lei Yang Lena Voytek Liang Yan Liang Yan Liao Pingfang Lin Ma Lin Ma Lin Ma Liu Yiding Lubomir Rintel Luke Yue Luyao Zhong luzhipeng Marc Hartmayer Marc-André Lureau Marek Marczykowski-Górecki Markus Schade Martin Kletzander Martin Pitt Masayoshi Mizuma Matej Cepl Matt Coleman Matt Coleman Mauro Matteo Cascella Max Goodhart Maxim Nestratov Meina Li Michal Privoznik Michał Smyk Milo Casagrande Moshe Levi Moteen Shah Moteen Shah Muha Aliss Nathan Neal Gompa Nick Chevsky Nick Shyrokovskiy Nickys Music Group Nico Pache Nicolas Lécureuil Nicolas Lécureuil Nikolay Shirokovskiy Nikolay Shirokovskiy Nikolay Shirokovskiy Niteesh Dubey Olaf Hering Olesya Gerasimenko Or Ozeri Orion Poplawski Pany Paolo Bonzini Patrick Magauran Paulo de Rezende Pinatti Pavel Hrdina Peng Liang Peter Krempa Pino Toscano
[qemu-mainline test] 170802: tolerable FAIL - PUSHED
flight 170802 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/170802/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 170783 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 170783 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 170783 test-armhf-armhf-xl-rtds 18 guest-start/debian.repeatfail like 170783 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 170783 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 170783 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 170783 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 170783 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 170783 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-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-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 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-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-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-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass version targeted for testing: qemuue2c2d575991cbccc39da81f1b54e78523a24ed11 baseline version: qemuu7077fcb9b68f058809c9dd9fd1dacae1881e886c Last test of basis 170783 2022-05-31 04:03:50 Z2 days Testing same since 170802 2022-06-01 21:38:16 Z0 days1 attempts People who touc
[xen-unstable test] 170801: tolerable FAIL - PUSHED
flight 170801 xen-unstable real [real] flight 170804 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/170801/ http://logs.test-lab.xenproject.org/osstest/logs/170804/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-install fail pass in 170804-retest Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 170797 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 170797 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 170797 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 170797 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 170797 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 170797 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 170797 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 170797 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 170797 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 170797 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 170797 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 170797 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 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-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail 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-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-
