[Xen-devel] [ovmf baseline-only test] 75359: trouble: blocked/broken
This run is configured for baseline tests only. flight 75359 ovmf real [real] http://osstest.xensource.com/osstest/logs/75359/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm broken build-i386 broken build-amd64-pvopsbroken build-i386-xsm broken build-amd64 broken build-i386-pvops broken Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a build-amd64 4 host-install(4) broken baseline untested build-amd64-xsm 4 host-install(4) broken baseline untested build-i386-pvops 4 host-install(4) broken baseline untested build-i3864 host-install(4) broken baseline untested build-amd64-pvops 4 host-install(4) broken baseline untested build-i386-xsm4 host-install(4) broken baseline untested version targeted for testing: ovmf d20ae95a13e851d56c6618108b18c93526505ca2 baseline version: ovmf c0b1f749ef1304810ed4ea58ded65b7f41d79d3e Last test of basis75347 2018-10-04 00:50:33 Z2 days Testing same since75359 2018-10-06 00:50:37 Z0 days1 attempts People who touched revisions under test: Anthony PERARD Marc-André Lureau jobs: build-amd64-xsm broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary broken-job build-amd64-xsm broken broken-job build-i386 broken broken-job build-amd64-pvops broken broken-job build-i386-xsm broken broken-job build-amd64 broken broken-job build-i386-pvops broken broken-step build-amd64 host-install(4) broken-step build-amd64-xsm host-install(4) broken-step build-i386-pvops host-install(4) broken-step build-i386 host-install(4) broken-step build-amd64-pvops host-install(4) broken-step build-i386-xsm host-install(4) Push not applicable. commit d20ae95a13e851d56c6618108b18c93526505ca2 Author: Marc-André Lureau Date: Tue Oct 2 16:17:25 2018 +0400 OvmfPkg/PlatformPei: clear CPU caches This is for conformance with the TCG "Platform Reset Attack Mitigation Specification". Because clearing the CPU caches at boot doesn't impact performance significantly, do it unconditionally, for simplicity's sake. Flush the cache on all logical processors, thanks to EFI_PEI_MP_SERVICES_PPI and CacheMaintenanceLib. Cc: Jordan Justen Cc: Laszlo Ersek Cc: Ard Biesheuvel Cc: Anthony Perard Cc: Julien Grall Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marc-André Lureau Tested-by: Anthony PERARD Reviewed-by: Laszlo Ersek Regression-tested-by: Laszlo Ersek Reviewed-by: Michael D Kinney [ler...@redhat.com: remove bogus Message-Id line from commit msg] ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ARM] Display passthrough
Hi, We want to passthrough the display to the guest OS.We are using Xen-4.8 and Hikey960. Is it possible to do pass through of display?If yes please provide reference. -- This message contains confidential information and is intended only for the individual(s) named. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this mail and attached file/s is strictly prohibited. Please notify the sender immediately and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secured or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus test] 128407: regressions - FAIL
flight 128407 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/128407/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 125898 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 125898 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-rumprun-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 125898 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 125898 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-multivcpu 7 xen-bootfail REGR. vs. 125898 test-amd64-amd64-xl-pvhv2-intel 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail REGR. vs. 125898 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host fail REGR. vs. 125898 test-amd64-i386-examine 8 reboot fail REGR. vs. 125898 test-amd64-amd64-libvirt-vhd 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-libvirt-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 125898 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 125898 test-amd64-i386-rumprun-i386 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl7 xen-boot fail REGR. vs. 125898 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 125898 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 125898 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 125898 test-amd64-amd64-examine 8 reboot fail REGR. vs. 125898 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 7 xen-boot fail REGR. vs. 125898 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-credit1 7 xen-bootfail baseline untested test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125898 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125898 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125898 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125898 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125898 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125898 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-su
[Xen-devel] [ovmf test] 128433: all pass - PUSHED
flight 128433 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/128433/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf d20ae95a13e851d56c6618108b18c93526505ca2 baseline version: ovmf c0b1f749ef1304810ed4ea58ded65b7f41d79d3e Last test of basis 128351 2018-10-03 18:40:50 Z2 days Testing same since 128433 2018-10-05 21:10:49 Z0 days1 attempts People who touched revisions under test: Anthony PERARD Marc-André Lureau 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 c0b1f749ef..d20ae95a13 d20ae95a13e851d56c6618108b18c93526505ca2 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] flask: sort io{port,mem}con entries
> -Daniel De Graaf wrote: -
> To: xen-devel@lists.xenproject.org, Nicolas Poirot
> From: Daniel De Graaf
> Date: 05/10/2018 18:33
> Cc: George Dunlap , Jan Beulich ,
> Daniel De Graaf
> Subject: [PATCH v2] flask: sort io{port,mem}con entries
>
> These entries are not always sorted by checkpolicy, so sort them during
> policy load (as is already done for later ocontext additions).
>
> Reported-by: Nicolas Poirot
> Signed-off-by: Daniel De Graaf
> ---
> xen/xsm/flask/ss/policydb.c | 35 +--
> 1 file changed, 29 insertions(+), 6 deletions(-)
>
> diff --git a/xen/xsm/flask/ss/policydb.c b/xen/xsm/flask/ss/policydb.c
> index 3a12d96ef9..9426164353 100644
> --- a/xen/xsm/flask/ss/policydb.c
> +++ b/xen/xsm/flask/ss/policydb.c
> @@ -1737,7 +1737,7 @@ int policydb_read(struct policydb *p, void *fp)
> {
> struct role_allow *ra, *lra;
> struct role_trans *tr, *ltr;
> -struct ocontext *l, *c /*, *newc*/;
> +struct ocontext *l, *c, **pn;
> int i, j, rc;
> __le32 buf[8];
> u32 len, /*len2,*/ config, nprim, nel /*, nel2*/;
> @@ -1994,6 +1994,7 @@ int policydb_read(struct policydb *p, void *fp)
> if ( rc < 0 )
> goto bad;
> nel = le32_to_cpu(buf[0]);
> +pn = &p->ocontexts[i];
> l = NULL;
> for ( j = 0; j < nel; j++ )
> {
> @@ -2003,11 +2004,6 @@ int policydb_read(struct policydb *p, void *fp)
> rc = -ENOMEM;
> goto bad;
> }
> -if ( l )
> -l->next = c;
> -else
> -p->ocontexts[i] = c;
> -l = c;
> rc = -EINVAL;
> switch ( i )
> {
> @@ -2050,6 +2046,18 @@ int policydb_read(struct policydb *p, void *fp)
> rc = context_read_and_validate(&c->context, p, fp);
> if ( rc )
> goto bad;
> +
> +if ( *pn || ( l && l->u.ioport.high_ioport >=
> c->u.ioport.low_ioport ) )
> +{
> +pn = &p->ocontexts[i];
> +l = *pn;
> +while ( l && l->u.ioport.high_ioport <
> c->u.ioport.low_ioport ) {
> +pn = &l->next;
> +l = *pn;
> +}
> +c->next = l;
> +}
> +l = c;
> break;
> case OCON_IOMEM:
> if ( p->target_type != TARGET_XEN )
> @@ -2078,6 +2086,18 @@ int policydb_read(struct policydb *p, void *fp)
> rc = context_read_and_validate(&c->context, p, fp);
> if ( rc )
> goto bad;
> +
> +if ( *pn || ( l && l->u.iomem.high_iomem >=
> c->u.iomem.low_iomem ) )
> +{
> +pn = &p->ocontexts[i];
> +l = *pn;
> +while ( l && l->u.iomem.high_iomem <
> c->u.iomem.low_iomem ) {
> +pn = &l->next;
> +l = *pn;
> +}
> +c->next = l;
> +}
> +l = c;
> break;
> case OCON_DEVICE:
> if ( p->target_type != TARGET_XEN )
> @@ -2123,6 +2143,9 @@ int policydb_read(struct policydb *p, void *fp)
> rc = -EINVAL;
> goto bad;
> }
> +
> +*pn = c;
> +pn = &c->next;
> }
> }
>
> --
> 2.14.4
Tested on the same conditions as the previous patch, looks good.
Thank you.
Tested-by: Nicolas Poirot
Reviewed-by: Nicolas Poirot
1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] flask: sort io{port,mem}con entries
> -Daniel De Graaf wrote: -
> To: xen-devel@lists.xenproject.org, Nicolas Poirot
> From: Daniel De Graaf
> Date: 10/05/2018 06:33PM
> Cc: George Dunlap , Jan Beulich ,
> Daniel De Graaf
> Subject: [PATCH v2] flask: sort io{port,mem}con entries
>
> These entries are not always sorted by checkpolicy, so sort them during
> policy load (as is already done for later ocontext additions).
>
> Reported-by: Nicolas Poirot
> Signed-off-by: Daniel De Graaf
> ---
> xen/xsm/flask/ss/policydb.c | 35 +--
> 1 file changed, 29 insertions(+), 6 deletions(-)
>
> diff --git a/xen/xsm/flask/ss/policydb.c b/xen/xsm/flask/ss/policydb.c
> index 3a12d96ef9..9426164353 100644
> --- a/xen/xsm/flask/ss/policydb.c
> +++ b/xen/xsm/flask/ss/policydb.c
> @@ -1737,7 +1737,7 @@ int policydb_read(struct policydb *p, void *fp)
> {
> struct role_allow *ra, *lra;
> struct role_trans *tr, *ltr;
> - struct ocontext *l, *c /*, *newc*/;
> + struct ocontext *l, *c, **pn;
> int i, j, rc;
> __le32 buf[8];
> u32 len, /*len2,*/ config, nprim, nel /*, nel2*/;
> @@ -1994,6 +1994,7 @@ int policydb_read(struct policydb *p, void *fp)
> if ( rc < 0 )
> goto bad;
> nel = le32_to_cpu(buf[0]);
> + pn = &p->ocontexts[i];
> l = NULL;
> for ( j = 0; j < nel; j++ )
> {
> @@ -2003,11 +2004,6 @@ int policydb_read(struct policydb *p, void *fp)
> rc = -ENOMEM;
> goto bad;
> }
> - if ( l )
> - l->next = c;
> - else
> - p->ocontexts[i] = c;
> - l = c;
> rc = -EINVAL;
> switch ( i )
> {
> @@ -2050,6 +2046,18 @@ int policydb_read(struct policydb *p, void *fp)
> rc = context_read_and_validate(&c->context, p, fp);
> if ( rc )
> goto bad;
> +
> + if ( *pn || ( l && l->u.ioport.high_ioport >=
> c->u.ioport.low_ioport ) )
> + {
> + pn = &p->ocontexts[i];
> + l = *pn;
> + while ( l && l->u.ioport.high_ioport <
> c->u.ioport.low_ioport ) {
> + pn = &l->next;
> + l = *pn;
> + }
> + c->next = l;
> + }
> + l = c;
> break;
> case OCON_IOMEM:
> if ( p->target_type != TARGET_XEN )
> @@ -2078,6 +2086,18 @@ int policydb_read(struct policydb *p, void *fp)
> rc = context_read_and_validate(&c->context, p, fp);
> if ( rc )
> goto bad;
> +
> + if ( *pn || ( l && l->u.iomem.high_iomem >=
> c->u.iomem.low_iomem ) )
> + {
> + pn = &p->ocontexts[i];
> + l = *pn;
> + while ( l && l->u.iomem.high_iomem <
> c->u.iomem.low_iomem ) {
> + pn = &l->next;
> + l = *pn;
> + }
> + c->next = l;
> + }
> + l = c;
> break;
> case OCON_DEVICE:
> if ( p->target_type != TARGET_XEN )
> @@ -2123,6 +2143,9 @@ int policydb_read(struct policydb *p, void *fp)
> rc = -EINVAL;
> goto bad;
> }
> +
> + *pn = c;
> + pn = &c->next;
> }
> }
>
> --
> 2.14.4
Tested in the same conditions as the previous patch, looks good.
Thank you.
Tested-by: Nicolas Poirot
Reviewed-by: Nicolas Poirot
1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] xen:arm: Populate arm64 image header
On 11/09/2018 17:48, Amit Singh Tomar wrote: > diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S > index d63734f..ef87b5c 100644 > --- a/xen/arch/arm/arm64/head.S > +++ b/xen/arch/arm/arm64/head.S > @@ -120,8 +127,8 @@ efi_head: > add x13, x18, #0x16 > b real_start /* branch to kernel start */ > .quad 0/* Image load offset from start of RAM > */ > -.quad 0/* reserved */ > -.quad 0/* reserved */ > +.quad _end - start /* Effective size of kernel image, > little-endian */ > +.quad __HEAD_FLAGS /* Informative flags, little-endian */ > .quad 0/* reserved */ > .quad 0/* reserved */ > .quad 0/* reserved */ Since 17bd254a xen:arm: Populate arm64 image header, qemu-system-aarch64 has not been too happy about booting Xen. Trying to launch qemu-system-aarch64 gives the following error: rom: requested regions overlap (rom bootloader. free=0x400d0150, addr=0x4000) qemu-system-aarch64: rom check and register reset failed Reverting 17bd254a allowed it to boot again. Alternatively, setting the image offset to some value allowed it to boot again. diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S index ef87b5c..8879c77 100644 --- a/xen/arch/arm/arm64/head.S +++ b/xen/arch/arm/arm64/head.S @@ -126,7 +126,7 @@ efi_head: */ add x13, x18, #0x16 b real_start /* branch to kernel start */ -.quad 0/* Image load offset from start of RAM */ +.quad 0x0008 /* Image load offset from start of RAM */ .quad _end - start /* Effective size of kernel image, little-endian */ .quad __HEAD_FLAGS /* Informative flags, little-endian */ .quad 0/* reserved */ I'm not sure if this is a fault of qemu, or if Xen should put some value in the image load offset field? For reference, I'm using the following script to build and launch qemu+Xen https://gist.github.com/stewdk/110f43e0cc1d905fc6ed4c7e10d8d35e ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 128402: regressions - FAIL
flight 128402 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/128402/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 128367 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 128367 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 128367 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass version targeted for testing: libvirt e7730d196b075b0415afe7c4700755874dc92cfb baseline version: libvirt 8ba65c4d95712b54362fd81c34bae99f51d45a0b Last test of basis 128367 2018-10-04 04:18:43 Z1 days Testing same since 128402 2018-10-05 04:18:40 Z0 days1 attempts People who touched revisions under test: Ján Tomko jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt fail build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt blocked test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair blocked test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit e7730d196b075b0415afe7c4700755874dc92cfb Author: Ján Tomko Date: Wed Oct 3 14:49
[Xen-devel] [PATCH v4 20/23] xen: support console_switching between Dom0 and DomUs on ARM
Today Ctrl-AAA is used to switch between Xen and Dom0. Extend the
mechanism to allow for switching between Xen, Dom0, and any of the
initial DomU created from Xen alongside Dom0 out of information provided
via device tree.
Rename xen_rx to console_rx to match the new behavior.
Clarify existing comment about "notify the guest", making it clear that
it is only about the hardware domain.
Signed-off-by: Stefano Stabellini
CC: andrew.coop...@citrix.com
CC: george.dun...@eu.citrix.com
CC: ian.jack...@eu.citrix.com
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
CC: t...@xen.org
CC: wei.l...@citrix.com
---
Changes in v4:
- handle console_rx == 0 in console_input_domain
- use rcu_lock_by_domain instead of get_domain_by_id
- handle the case where the returned domain is NULL
- send_global_virq(VIRQ_CONSOLE) only when chars are for Dom0
- make console_rx unsigned int
- fix comment
- code readability improvement
- fix opt_conswitch[1] == 'x' case
- move console_input_domain to next patch
Changes in v3:
- only call vpl011 functions ifdef CONFIG_SBSA_VUART_CONSOLE
- add blank line and spaces
- remove xen_rx from print messages
- rename xen_rx to console_rx
- keep switch_serial_input() at boot
- add better comments
- fix existing comment
- add warning if no guests console/uart is available
- add console_input_domain function
Changes in v2:
- only call vpl011_rx_char if the vpl011 has been initialized
---
xen/drivers/char/console.c | 73 +-
1 file changed, 59 insertions(+), 14 deletions(-)
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 3b75f7a..0808bac 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -31,10 +31,13 @@
#include
#include
#include
+#include
#ifdef CONFIG_X86
#include
#include
+#else
+#include
#endif
/* console: comma-separated list of console outputs. */
@@ -391,31 +394,73 @@ static void dump_console_ring_key(unsigned char key)
free_xenheap_pages(buf, order);
}
-/* CTRL- switches input direction between Xen and DOM0. */
+/*
+ * CTRL- switches input direction between Xen, Dom0 and
+ * DomUs.
+ */
#define switch_code (opt_conswitch[0]-'a'+1)
-static int __read_mostly xen_rx = 1; /* FALSE => input passed to domain 0. */
+/*
+ * console_rx=0 => input to xen
+ * console_rx=1 => input to dom0
+ * console_rx=N => input dom(N-1)
+ */
+static unsigned int __read_mostly console_rx = 0;
static void switch_serial_input(void)
{
-static char *input_str[2] = { "DOM0", "Xen" };
-xen_rx = !xen_rx;
-printk("*** Serial input -> %s", input_str[xen_rx]);
+if ( console_rx++ == max_init_domid + 1 )
+console_rx = 0;
+
+if ( !console_rx )
+printk("*** Serial input to Xen");
+else
+printk("*** Serial input to DOM%d", console_rx - 1);
+
if ( switch_code )
-printk(" (type 'CTRL-%c' three times to switch input to %s)",
- opt_conswitch[0], input_str[!xen_rx]);
+printk(" (type 'CTRL-%c' three times to switch input)",
+ opt_conswitch[0]);
printk("\n");
}
static void __serial_rx(char c, struct cpu_user_regs *regs)
{
-if ( xen_rx )
+if ( console_rx == 0 )
return handle_keypress(c, regs);
-/* Deliver input to guest buffer, unless it is already full. */
-if ( (serial_rx_prod-serial_rx_cons) != SERIAL_RX_SIZE )
-serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
-/* Always notify the guest: prevents receive path from getting stuck. */
-send_global_virq(VIRQ_CONSOLE);
+if ( console_rx == 1 )
+{
+/* Deliver input to hardware domain, unless it is already full. */
+if ( (serial_rx_prod - serial_rx_cons) != SERIAL_RX_SIZE )
+serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
+
+/*
+ * Always notify the hardware domain: prevents receive path from
+ * getting stuck.
+ */
+send_global_virq(VIRQ_CONSOLE);
+}
+#ifdef CONFIG_SBSA_VUART_CONSOLE
+else
+{
+struct domain *d = rcu_lock_domain_by_any_id(console_rx - 1);
+
+/*
+ * If we have a properly initialized vpl011 console for the
+ * domain, without a full PV ring to Dom0 (in that case input
+ * comes from the PV ring), then send the character to it.
+ */
+if ( d != NULL &&
+ !d->arch.vpl011.backend_in_domain &&
+ d->arch.vpl011.backend.xen != NULL )
+vpl011_rx_char_xen(d, c);
+else
+printk("Cannot send chars to Dom%d: no UART available\n",
+ console_rx - 1);
+
+if ( d != NULL )
+rcu_unlock_domain(d);
+}
+#endif
#ifdef CONFIG_X86
if ( pv_shim && pv_console )
@@ -943,7 +988,7 @@ void __init console_endboot(void)
* a useful 'how to switch' message.
*/
if ( opt_conswitch[1] == 'x' )
-xen_rx = !xen_rx;
+console_rx = max_init_domid + 1;
[Xen-devel] [PATCH v4 23/23] xen/arm: split domain_build.c
domain_build.c is too large.
Move all the ACPI specific device tree generating functions from
domain_build.c to acpi/domain_build.c.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- rename acpi_dt_build to domain_build.c
- add copyright header
- remove useless #include
- remove acpi_dt_build.h, add domain_build.h
---
xen/arch/arm/acpi/Makefile | 1 +
xen/arch/arm/acpi/domain_build.c | 592 +
xen/arch/arm/domain_build.c| 585 +---
xen/include/asm-arm/domain_build.h | 31 ++
4 files changed, 629 insertions(+), 580 deletions(-)
create mode 100644 xen/arch/arm/acpi/domain_build.c
create mode 100644 xen/include/asm-arm/domain_build.h
diff --git a/xen/arch/arm/acpi/Makefile b/xen/arch/arm/acpi/Makefile
index 23963f8..94ae249 100644
--- a/xen/arch/arm/acpi/Makefile
+++ b/xen/arch/arm/acpi/Makefile
@@ -1,2 +1,3 @@
obj-y += lib.o
+obj-y += domain_build.o
obj-y += boot.init.o
diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c
new file mode 100644
index 000..44d3ad1
--- /dev/null
+++ b/xen/arch/arm/acpi/domain_build.c
@@ -0,0 +1,592 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Override macros from asm/page.h to make them work with mfn_t */
+#undef virt_to_mfn
+#define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
+
+#define ACPI_DOM0_FDT_MIN_SIZE 4096
+
+static int __init acpi_iomem_deny_access(struct domain *d)
+{
+acpi_status status;
+struct acpi_table_spcr *spcr = NULL;
+unsigned long mfn;
+int rc;
+
+/* Firstly permit full MMIO capabilities. */
+rc = iomem_permit_access(d, 0UL, ~0UL);
+if ( rc )
+return rc;
+
+/* TODO: Deny MMIO access for SMMU, GIC ITS */
+status = acpi_get_table(ACPI_SIG_SPCR, 0,
+(struct acpi_table_header **)&spcr);
+
+if ( ACPI_FAILURE(status) )
+{
+printk("Failed to get SPCR table\n");
+return -EINVAL;
+}
+
+mfn = spcr->serial_port.address >> PAGE_SHIFT;
+/* Deny MMIO access for UART */
+rc = iomem_deny_access(d, mfn, mfn + 1);
+if ( rc )
+return rc;
+
+/* Deny MMIO access for GIC regions */
+return gic_iomem_deny_access(d);
+}
+
+static int __init acpi_route_spis(struct domain *d)
+{
+int i, res;
+struct irq_desc *desc;
+
+/*
+ * Route the IRQ to hardware domain and permit the access.
+ * The interrupt type will be set by set by the hardware domain.
+ */
+for( i = NR_LOCAL_IRQS; i < vgic_num_irqs(d); i++ )
+{
+/*
+ * TODO: Exclude the SPIs SMMU uses which should not be routed to
+ * the hardware domain.
+ */
+desc = irq_to_desc(i);
+if ( desc->action != NULL)
+continue;
+
+/* XXX: Shall we use a proper devname? */
+res = map_irq_to_domain(d, i, true, "ACPI");
+if ( res )
+return res;
+}
+
+return 0;
+}
+
+static int __init acpi_make_hypervisor_node(const struct kernel_info *kinfo,
+struct membank tbl_add[])
+{
+const char compat[] =
+"xen,xen-"__stringify(XEN_VERSION)"."__stringify(XEN_SUBVERSION)"\0"
+"xen,xen";
+int res;
+/* Convenience alias */
+void *fdt = kinfo->fdt;
+
+dt_dprintk("Create hypervisor node\n");
+
+/* See linux Documentation/devicetree/bindings/arm/xen.txt */
+res = fdt_begin_node(fdt, "hypervisor");
+if ( res )
+return res;
+
+/* Cannot use fdt_property_string due to embedded nulls */
+res = fdt_property(fdt, "compatible", compat, sizeof(compat));
+if ( res )
+return res;
+
+res = acpi_make_efi_nodes(fdt, tbl_add);
+if ( res )
+return res;
+
+res = fdt_end_node(fdt);
+
+return res;
+}
+
+/*
+ * Prepare a minimal DTB for Dom0 which contains bootargs, initrd, memory
+ * information, EFI table.
+ */
+static int __init create_acpi_dtb(struct kernel_info *kinfo,
+ struct membank tbl_add[])
+{
+int new_size;
+int ret;
+
+dt_dprintk("Prepare a min DTB for DOM0\n");
+
+/* Allocate min size for DT */
+new_size = ACPI_DOM0_FDT_MIN_SIZE;
+kinfo->fdt = xmalloc_bytes(new_size);
+
+if ( kinfo->fdt == NULL )
+return -ENOMEM;
+
+/* Create a new empty DT for DOM0 */
+ret = fdt_create(kinfo->fd
[Xen-devel] [PATCH v4 14/23] xen/arm: generate a simple device tree for domUs
Introduce functions to generate a basic domU device tree, similar to the
existing functions in tools/libxl/libxl_arm.c.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- code style
- two separate functions for gicv2 and gicv3
- remove useless local variables
- fix typos
- do not use host address and size cells for the guest DT
- use #define for addrcells and sizecells
Changes in v3:
- remove CONFIG_ACPI for make_chosen_node
- remove make_hypervisor_node until all Xen related functionalities
(evtchns, grant table, etc.) work correctly
Changes in v2:
- move prepare_dtb rename to previous patch
- use switch for the gic version
- use arm,gic-400 instead of arm,cortex-a15-gic
- add @unit-address in the gic node name
- add comment on DOMU_DTB_SIZE
---
xen/arch/arm/domain_build.c | 235 +++-
1 file changed, 233 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index efb530a..bf8aeca 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1017,7 +1017,6 @@ static int __init make_timer_node(const struct domain *d,
void *fdt,
return res;
}
-#ifdef CONFIG_ACPI
/*
* This function is used as part of the device tree generation for Dom0
* on ACPI systems, and DomUs started directly from Xen based on device
@@ -1063,7 +1062,6 @@ static int __init make_chosen_node(const struct
kernel_info *kinfo)
return res;
}
-#endif
static int __init map_irq_to_domain(struct domain *d, unsigned int irq,
bool need_mapping, const char *devname)
@@ -1455,6 +1453,235 @@ static int __init handle_node(struct domain *d, struct
kernel_info *kinfo,
return res;
}
+static int __init make_gicv2_domU_node(const struct domain *d, void *fdt)
+{
+int res = 0;
+__be32 reg[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) * 2];
+__be32 *cells;
+
+res = fdt_begin_node(fdt,
"interrupt-controller@"__stringify(GUEST_GICD_BASE));
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "#address-cells", 0);
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "#interrupt-cells", 3);
+if ( res )
+return res;
+
+res = fdt_property(fdt, "interrupt-controller", NULL, 0);
+if ( res )
+return res;
+
+res = fdt_property_string(fdt, "compatible", "arm,gic-400");
+if ( res )
+return res;
+
+cells = ®[0];
+dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
+ GUEST_GICD_BASE, GUEST_GICD_SIZE);
+dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
+ GUEST_GICC_BASE, GUEST_GICC_SIZE);
+
+res = fdt_property(fdt, "reg", reg, sizeof(reg));
+if (res)
+return res;
+
+res = fdt_property_cell(fdt, "linux,phandle", GUEST_PHANDLE_GIC);
+if (res)
+return res;
+
+res = fdt_property_cell(fdt, "phandle", GUEST_PHANDLE_GIC);
+if (res)
+return res;
+
+res = fdt_end_node(fdt);
+
+return res;
+}
+
+static int __init make_gicv3_domU_node(const struct domain *d, void *fdt)
+{
+int res = 0;
+__be32 reg[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) * 2];
+__be32 *cells;
+
+res = fdt_begin_node(fdt,
"interrupt-controller@"__stringify(GUEST_GICV3_GICD_BASE));
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "#address-cells", 0);
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "#interrupt-cells", 3);
+if ( res )
+return res;
+
+res = fdt_property(fdt, "interrupt-controller", NULL, 0);
+if ( res )
+return res;
+
+res = fdt_property_string(fdt, "compatible", "arm,gic-v3");
+if ( res )
+return res;
+
+cells = ®[0];
+dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
+ GUEST_GICV3_GICD_BASE, GUEST_GICV3_GICD_SIZE);
+dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
+ GUEST_GICV3_GICR0_BASE, GUEST_GICV3_GICR0_SIZE);
+
+res = fdt_property(fdt, "reg", reg, sizeof(reg));
+if (res)
+return res;
+
+res = fdt_property_cell(fdt, "linux,phandle", GUEST_PHANDLE_GIC);
+if (res)
+return res;
+
+res = fdt_property_cell(fdt, "phandle", GUEST_PHANDLE_GIC);
+if (res)
+return res;
+
+res = fdt_end_node(fdt);
+
+return res;
+}
+
+static int __init make_gic_domU_node(const struct domain *d, void *fdt)
+{
+switch ( gic_hw_version() )
+{
+case GIC_V3:
+return make_gicv3_domU_node(d, fdt);
+case GIC_V2:
+return make_gicv2_domU_node(d, fdt);
+default:
+panic("Unsupported GIC version");
+}
+}
+
+static int __init make_timer_domU_node(const struct domain *d, void *fdt)
+{
+int res;
+gic_interrupt_t intrs[3];
+
+res = fdt_begin_node(fdt, "timer")
[Xen-devel] [PATCH v4 13/23] xen/arm: implement construct_domU
Similar to construct_dom0, construct_domU creates a barebone DomU guest.
The device tree node passed as argument is compatible "xen,domain", see
docs/misc/arm/device-tree/booting.txt.
Add const to kernel_probe dt_device_node parameter.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- constify kernel_probe
- change title
- better error messages and printed info
- 64bit memory
Changes in v3:
- move setting type before allocate_memory
- add ifdef around it and a comment
Changes in v2:
- rename mem to memory
- make cpus and memory mandatory
- remove wront comment from commit message
- cpus and memory are read as integers
- read the vpl011 option
---
xen/arch/arm/domain_build.c | 37 ++---
xen/arch/arm/kernel.c | 3 ++-
xen/arch/arm/kernel.h | 2 +-
3 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 547b624..efb530a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -369,7 +369,6 @@ static void __init allocate_memory_11(struct domain *d,
}
}
-#if 0
static bool __init allocate_bank_memory(struct domain *d,
struct kernel_info *kinfo,
gfn_t sgfn,
@@ -450,7 +449,6 @@ fail:
(unsigned long)kinfo->unassigned_mem >> 10);
BUG();
}
-#endif
static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
const struct dt_device_node *node)
@@ -2294,7 +2292,40 @@ static int __init __construct_domain(struct domain *d,
struct kernel_info *kinfo
static int __init construct_domU(struct domain *d,
const struct dt_device_node *node)
{
-return -ENOSYS;
+struct kernel_info kinfo = {};
+int rc;
+u64 mem;
+
+rc = dt_property_read_u64(node, "memory", &mem);
+if ( !rc )
+{
+printk("Error building DomU: cannot read \"memory\" property\n");
+return -EINVAL;
+}
+kinfo.unassigned_mem = (paddr_t)mem << 10;
+
+printk("*** LOADING DOMU cpus=%u memory=%luKB ***\n", d->max_vcpus, mem);
+
+d->vcpu = xzalloc_array(struct vcpu *, d->max_vcpus);
+if ( !d->vcpu )
+return -ENOMEM;;
+if ( vcpu_create(d, 0, 0) == NULL )
+return -ENOMEM;
+d->max_pages = ~0U;
+
+kinfo.d = d;
+
+rc = kernel_probe(&kinfo, node);
+if ( rc < 0 )
+return rc;
+
+#ifdef CONFIG_ARM_64
+/* type must be set before allocate memory */
+d->arch.type = kinfo.type;
+#endif
+allocate_memory(d, &kinfo);
+
+return __construct_domain(d, &kinfo);
}
void __init create_domUs(void)
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index e5b8213..2239a07 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -421,7 +421,8 @@ static int __init kernel_zimage32_probe(struct kernel_info
*info,
return 0;
}
-int __init kernel_probe(struct kernel_info *info, struct dt_device_node
*domain)
+int __init kernel_probe(struct kernel_info *info,
+const struct dt_device_node *domain)
{
struct bootmodule *mod = NULL;
struct bootcmdline *cmd = NULL;
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
index 4a65289..4320f72 100644
--- a/xen/arch/arm/kernel.h
+++ b/xen/arch/arm/kernel.h
@@ -55,7 +55,7 @@ struct kernel_info {
* ->type
* ->load hook, and sets loader specific variables ->zimage
*/
-int kernel_probe(struct kernel_info *info, struct dt_device_node *domain);
+int kernel_probe(struct kernel_info *info, const struct dt_device_node
*domain);
/*
* Loads the kernel into guest RAM.
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 02/23] xen/arm: extend device tree based multiboot protocol
Extend the existing device tree based multiboot protocol to include
information regarding multiple domains to boot.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- memory is 64bit
Changes in v3:
- remove "xen,initial-domain" for now
- make vpl011 an empty property
- memory in KBs
Changes in v2:
- lower case kernel
- rename mem to memory
- mandate cpus and memory
- replace domU-kernel with kernel and domU-ramdisk with ramdisk
- rename xen,domU with xen,domain
- add info about dom0
- switch memory and cpus to integers
- remove defaults
- add vpl011
---
docs/misc/arm/device-tree/booting.txt | 107 ++
1 file changed, 107 insertions(+)
diff --git a/docs/misc/arm/device-tree/booting.txt
b/docs/misc/arm/device-tree/booting.txt
index ce2d0dc..317a9e9 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -119,3 +119,110 @@ For those you would hardcode the Xen commandline in the
DTB under
line by writing bootargs (as for native Linux).
A Xen-aware bootloader would set xen,xen-bootargs for Xen, xen,dom0-bootargs
for Dom0 and bootargs for native Linux.
+
+
+Creating Multiple Domains directly from Xen
+===
+
+It is possible to have Xen create other domains, in addition to dom0,
+out of the information provided via device tree. A kernel and initrd
+(optional) need to be specified for each guest.
+
+For each domain to be created there needs to be one node under /chosen
+with the following properties:
+
+- compatible
+
+For domUs: "xen,domain"
+
+- memory
+
+ A 64-bit integer specifying the amount of kilobytes of RAM to
+allocate to the guest.
+
+- cpus
+
+An integer specifying the number of vcpus to allocate to the guest.
+
+- vpl011
+
+An empty property to enable/disable a virtual pl011 for the guest to use.
+
+- #address-cells and #size-cells
+
+Both #address-cells and #size-cells need to be specified because
+both sub-nodes (described shortly) have reg properties.
+
+Under the "xen,domain" compatible node, one or more sub-nodes are present
+for the DomU kernel and ramdisk.
+
+The kernel sub-node has the following properties:
+
+- compatible
+
+"multiboot,kernel"
+
+- reg
+
+Specifies the physical address of the kernel in RAM and its
+length.
+
+- bootargs (optional)
+
+Command line parameters for the guest kernel.
+
+The ramdisk sub-node has the following properties:
+
+- compatible
+
+"multiboot,ramdisk"
+
+- reg
+
+Specifies the physical address of the ramdisk in RAM and its
+length.
+
+
+Example
+===
+
+chosen {
+domU1 {
+compatible = "xen,domain";
+#address-cells = <0x2>;
+#size-cells = <0x1>;
+memory = <0 131072>;
+cpus = <2>;
+vpl011;
+
+module@0x4a00 {
+compatible = "multiboot,kernel";
+reg = <0x0 0x4a00 0xff>;
+bootargs = "console=ttyAMA0 init=/bin/sh";
+};
+
+module@0x4b00 {
+compatible = "multiboot,ramdisk";
+reg = <0x0 0x4b00 0xff>;
+};
+};
+
+domU2 {
+compatible = "xen,domain";
+#address-cells = <0x2>;
+#size-cells = <0x1>;
+memory = <0 65536>;
+cpus = <1>;
+
+module@0x4c00 {
+compatible = "multiboot,kernel";
+reg = <0x0 0x4c00 0xff>;
+bootargs = "console=ttyAMA0 init=/bin/sh";
+};
+
+module@0x4d00 {
+compatible = "multiboot,ramdisk";
+reg = <0x0 0x4d00 0xff>;
+};
+};
+};
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 11/23] xen/arm: refactor construct_dom0
Move generic initializations out of construct_dom0 so that they can be
reused.
Rename prepare_dtb to prepare_dtb_hwdom to avoid confusion.
No functional changes in this patch.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- newline and style changes
Changes in v3:
- move setting type before allocate_memory
- add ifdef around it and a comment
Changes in v2:
- move discard_initial_modules() after __construct_domain()
- remove useless blank line
- leave safety BUG_ONs in __construct_domain
- rename prepare_dtb to prepare_dtb_hwdom
---
xen/arch/arm/domain_build.c | 126
1 file changed, 68 insertions(+), 58 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index fddfd82..ba3dad1 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1456,7 +1456,7 @@ static int __init handle_node(struct domain *d, struct
kernel_info *kinfo,
return res;
}
-static int __init prepare_dtb(struct domain *d, struct kernel_info *kinfo)
+static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info
*kinfo)
{
const p2m_type_t default_p2mt = p2m_mmio_direct_c;
const void *fdt;
@@ -2191,75 +2191,29 @@ static void __init find_gnttab_region(struct domain *d,
kinfo->gnttab_start, kinfo->gnttab_start + kinfo->gnttab_size);
}
-int __init construct_dom0(struct domain *d)
+static int __init __construct_domain(struct domain *d, struct kernel_info
*kinfo)
{
-const struct bootcmdline *kernel =
boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
-struct kernel_info kinfo = {};
struct vcpu *saved_current;
-int rc, i, cpu;
-
+int i, cpu;
struct vcpu *v = d->vcpu[0];
struct cpu_user_regs *regs = &v->arch.cpu_info->guest_cpu_user_regs;
-/* Sanity! */
-BUG_ON(d->domain_id != 0);
BUG_ON(d->vcpu[0] == NULL);
BUG_ON(v->is_initialised);
-printk("*** LOADING DOMAIN 0 ***\n");
-if ( dom0_mem <= 0 )
-{
-warning_add("PLEASE SPECIFY dom0_mem PARAMETER - USING 512M FOR
NOW\n");
-dom0_mem = MB(512);
-}
-
-
-iommu_hwdom_init(d);
-
-d->max_pages = ~0U;
-
-kinfo.unassigned_mem = dom0_mem;
-kinfo.d = d;
-
-rc = kernel_probe(&kinfo, NULL);
-if ( rc < 0 )
-return rc;
-
#ifdef CONFIG_ARM_64
/* if aarch32 mode is not supported at EL1 do not allow 32-bit domain */
-if ( !(cpu_has_el1_32) && kinfo.type == DOMAIN_32BIT )
+if ( !(cpu_has_el1_32) && kinfo->type == DOMAIN_32BIT )
{
printk("Platform does not support 32-bit domain\n");
return -EINVAL;
}
-d->arch.type = kinfo.type;
if ( is_64bit_domain(d) )
vcpu_switch_to_aarch64_mode(v);
#endif
-kinfo.cmdline = kernel != NULL ? &kernel->cmdline[0] : NULL;
-allocate_memory_11(d, &kinfo);
-find_gnttab_region(d, &kinfo);
-
-/* Map extra GIC MMIO, irqs and other hw stuffs to dom0. */
-rc = gic_map_hwdom_extra_mappings(d);
-if ( rc < 0 )
-return rc;
-
-rc = platform_specific_mapping(d);
-if ( rc < 0 )
-return rc;
-
-if ( acpi_disabled )
-rc = prepare_dtb(d, &kinfo);
-else
-rc = prepare_acpi(d, &kinfo);
-
-if ( rc < 0 )
-return rc;
-
/*
* The following loads use the domain's p2m and require current to
* be a vcpu of the domain, temporarily switch
@@ -2272,20 +2226,18 @@ int __init construct_dom0(struct domain *d)
* kernel_load will determine the placement of the kernel as well
* as the initrd & fdt in RAM, so call it first.
*/
-kernel_load(&kinfo);
+kernel_load(kinfo);
/* initrd_load will fix up the fdt, so call it before dtb_load */
-initrd_load(&kinfo);
-dtb_load(&kinfo);
+initrd_load(kinfo);
+dtb_load(kinfo);
/* Now that we are done restore the original p2m and current. */
set_current(saved_current);
p2m_restore_state(saved_current);
-discard_initial_modules();
-
memset(regs, 0, sizeof(*regs));
-regs->pc = (register_t)kinfo.entry;
+regs->pc = (register_t)kinfo->entry;
if ( is_32bit_domain(d) )
{
@@ -2303,14 +2255,14 @@ int __init construct_dom0(struct domain *d)
*/
regs->r0 = 0; /* SBZ */
regs->r1 = 0x; /* We use DTB therefore no machine id */
-regs->r2 = kinfo.dtb_paddr;
+regs->r2 = kinfo->dtb_paddr;
}
#ifdef CONFIG_ARM_64
else
{
regs->cpsr = PSR_GUEST64_INIT;
/* From linux/Documentation/arm64/booting.txt */
-regs->x0 = kinfo.dtb_paddr;
+regs->x0 = kinfo->dtb_paddr;
regs->x1 = 0; /* Reserved for future use */
regs->x2 = 0; /* Reserved for future use */
regs->x3 = 0; /* Reserved for future use */
@@ -2338,6 +2290,64 @@ int __init construct_dom0(struct domain *d)
return 0;
}
+int __init construct_dom0(struct domain *d)
+{
+const struct bootcmdline *kernel =
boot_
[Xen-devel] [PATCH v4 15/23] xen/arm: make set_interrupt_ppi able to handle non-PPI
also rename it to set_interrupt.
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/domain_build.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index bf8aeca..760ebf8 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -577,19 +577,20 @@ static int __init write_properties(struct domain *d,
struct kernel_info *kinfo,
typedef __be32 gic_interrupt_t[3];
-static void __init set_interrupt_ppi(gic_interrupt_t interrupt,
- unsigned int irq,
- unsigned int cpumask,
- unsigned int level)
+static void __init set_interrupt(gic_interrupt_t interrupt,
+ unsigned int irq,
+ unsigned int cpumask,
+ unsigned int level)
{
__be32 *cells = interrupt;
+bool is_ppi = !!(irq < 32);
BUG_ON(irq < 16);
-BUG_ON(irq >= 32);
+irq -= (is_ppi) ? 16: 32; /* PPIs start at 16, SPIs at 32 */
/* See linux
Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt */
-dt_set_cell(&cells, 1, 1); /* is a PPI */
-dt_set_cell(&cells, 1, irq - 16); /* PPIs start at 16 */
+dt_set_cell(&cells, 1, is_ppi); /* is a PPI? */
+dt_set_cell(&cells, 1, irq);
dt_set_cell(&cells, 1, (cpumask << 8) | level);
}
@@ -712,7 +713,7 @@ static int __init make_hypervisor_node(struct domain *d,
* - All CPUs
* TODO: Handle properly the cpumask;
*/
-set_interrupt_ppi(intr, d->arch.evtchn_irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intr, d->arch.evtchn_irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
res = fdt_property_interrupts(fdt, &intr, 1);
if ( res )
return res;
@@ -989,15 +990,15 @@ static int __init make_timer_node(const struct domain *d,
void *fdt,
irq = timer_get_irq(TIMER_PHYS_SECURE_PPI);
dt_dprintk(" Secure interrupt %u\n", irq);
-set_interrupt_ppi(intrs[0], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[0], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
irq = timer_get_irq(TIMER_PHYS_NONSECURE_PPI);
dt_dprintk(" Non secure interrupt %u\n", irq);
-set_interrupt_ppi(intrs[1], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[1], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
irq = timer_get_irq(TIMER_VIRT_PPI);
dt_dprintk(" Virt interrupt %u\n", irq);
-set_interrupt_ppi(intrs[2], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[2], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
res = fdt_property_interrupts(fdt, intrs, 3);
if ( res )
@@ -1586,9 +1587,9 @@ static int __init make_timer_domU_node(const struct
domain *d, void *fdt)
return res;
}
-set_interrupt_ppi(intrs[0], GUEST_TIMER_PHYS_S_PPI, 0xf,
DT_IRQ_TYPE_LEVEL_LOW);
-set_interrupt_ppi(intrs[1], GUEST_TIMER_PHYS_NS_PPI, 0xf,
DT_IRQ_TYPE_LEVEL_LOW);
-set_interrupt_ppi(intrs[2], GUEST_TIMER_VIRT_PPI, 0xf,
DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[0], GUEST_TIMER_PHYS_S_PPI, 0xf,
DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[1], GUEST_TIMER_PHYS_NS_PPI, 0xf,
DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[2], GUEST_TIMER_VIRT_PPI, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
res = fdt_property(fdt, "interrupts", intrs, sizeof (intrs[0]) * 3);
if ( res )
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 22/23] xen/arm: move kernel.h to asm-arm/
It will be #included by a file in a xen/arch/arm subdirectory.
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/domain_build.c | 2 +-
xen/arch/arm/kernel.c| 3 +-
xen/arch/arm/kernel.h| 86
xen/include/asm-arm/kernel.h | 86
4 files changed, 88 insertions(+), 89 deletions(-)
delete mode 100644 xen/arch/arm/kernel.h
create mode 100644 xen/include/asm-arm/kernel.h
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 4379538..dc9b46e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -24,7 +25,6 @@
#include
#include
-#include "kernel.h"
static unsigned int __initdata opt_dom0_max_vcpus;
integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 2239a07..b56aa79 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -16,8 +16,7 @@
#include
#include
-
-#include "kernel.h"
+#include
#define UIMAGE_MAGIC 0x27051956
#define UIMAGE_NMLEN 32
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
deleted file mode 100644
index 33f3e72..000
--- a/xen/arch/arm/kernel.h
+++ /dev/null
@@ -1,86 +0,0 @@
-/*
- * Kernel image loading.
- *
- * Copyright (C) 2011 Citrix Systems, Inc.
- */
-#ifndef __ARCH_ARM_KERNEL_H__
-#define __ARCH_ARM_KERNEL_H__
-
-#include
-#include
-
-struct kernel_info {
-#ifdef CONFIG_ARM_64
-enum domain_type type;
-#endif
-
-struct domain *d;
-
-void *fdt; /* flat device tree */
-paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
-struct meminfo mem;
-
-/* kernel entry point */
-paddr_t entry;
-
-/* grant table region */
-paddr_t gnttab_start;
-paddr_t gnttab_size;
-
-/* boot blob load addresses */
-const struct bootmodule *kernel_bootmodule, *initrd_bootmodule;
-const char* cmdline;
-paddr_t dtb_paddr;
-paddr_t initrd_paddr;
-
-/* Enable pl011 emulation */
-bool vpl011;
-
-/* loader to use for this kernel */
-void (*load)(struct kernel_info *info);
-/* loader specific state */
-union {
-struct {
-paddr_t kernel_addr;
-paddr_t len;
-#ifdef CONFIG_ARM_64
-paddr_t text_offset; /* 64-bit Image only */
-#endif
-paddr_t start; /* 32-bit zImage only */
-} zimage;
-};
-};
-
-/*
- * Probe the kernel to detemine its type and select a loader.
- *
- * Sets in info:
- * ->type
- * ->load hook, and sets loader specific variables ->zimage
- */
-int kernel_probe(struct kernel_info *info, const struct dt_device_node
*domain);
-
-/*
- * Loads the kernel into guest RAM.
- *
- * Expects to be set in info when called:
- * ->mem
- * ->fdt
- *
- * Sets in info:
- * ->entry
- * ->dtb_paddr
- * ->initrd_paddr
- */
-void kernel_load(struct kernel_info *info);
-
-#endif /* #ifdef __ARCH_ARM_KERNEL_H__ */
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/include/asm-arm/kernel.h b/xen/include/asm-arm/kernel.h
new file mode 100644
index 000..33f3e72
--- /dev/null
+++ b/xen/include/asm-arm/kernel.h
@@ -0,0 +1,86 @@
+/*
+ * Kernel image loading.
+ *
+ * Copyright (C) 2011 Citrix Systems, Inc.
+ */
+#ifndef __ARCH_ARM_KERNEL_H__
+#define __ARCH_ARM_KERNEL_H__
+
+#include
+#include
+
+struct kernel_info {
+#ifdef CONFIG_ARM_64
+enum domain_type type;
+#endif
+
+struct domain *d;
+
+void *fdt; /* flat device tree */
+paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
+struct meminfo mem;
+
+/* kernel entry point */
+paddr_t entry;
+
+/* grant table region */
+paddr_t gnttab_start;
+paddr_t gnttab_size;
+
+/* boot blob load addresses */
+const struct bootmodule *kernel_bootmodule, *initrd_bootmodule;
+const char* cmdline;
+paddr_t dtb_paddr;
+paddr_t initrd_paddr;
+
+/* Enable pl011 emulation */
+bool vpl011;
+
+/* loader to use for this kernel */
+void (*load)(struct kernel_info *info);
+/* loader specific state */
+union {
+struct {
+paddr_t kernel_addr;
+paddr_t len;
+#ifdef CONFIG_ARM_64
+paddr_t text_offset; /* 64-bit Image only */
+#endif
+paddr_t start; /* 32-bit zImage only */
+} zimage;
+};
+};
+
+/*
+ * Probe the kernel to detemine its type and select a loader.
+ *
+ * Sets in info:
+ * ->type
+ * ->load hook, and sets loader specific variables ->zimage
+ */
+int kernel_probe(struct kernel_info *info, const struct dt_device_node
*domain);
+
+/*
+ * Loads the kernel into guest RAM.
+ *
+ * Expects to be set in info when called:
+ * ->mem
+ * ->fdt
+ *
+ * Sets in info:
+ * ->entry
+ * ->dtb_paddr
+ * ->initrd_paddr
+
[Xen-devel] [PATCH v4 03/23] xen/arm: document dom0less
Add a new document to provide information on how to use dom0less related features and their current limitations. Signed-off-by: Stefano Stabellini --- Changes in v4: - rename to .txt - improve wording Changes in v3: - add patch --- docs/misc/arm/dom0less.txt | 47 ++ 1 file changed, 47 insertions(+) create mode 100644 docs/misc/arm/dom0less.txt diff --git a/docs/misc/arm/dom0less.txt b/docs/misc/arm/dom0less.txt new file mode 100644 index 000..df96b41 --- /dev/null +++ b/docs/misc/arm/dom0less.txt @@ -0,0 +1,47 @@ +Dom0less + + +"Dom0less" is a set of Xen features that enable the deployment of a Xen +system without an hardware domain (often referred to as "dom0"). Each +feature can be used independently from the others, unless otherwise +stated. + +Booting Multiple Domains from Device Tree += + +This feature enables Xen to create a set of DomUs alongside Dom0 at boot +time. Information about the DomUs to be created by Xen is passed to the +hypervisor via Device Tree. Specifically, the existing Device Tree based +Multiboot specification has been extended to allow for multiple domains +to be passed to Xen. See docs/misc/arm/device-tree/booting.txt for more +information about the Multiboot specification and how to use it. + +Instead of waiting for Dom0 to be fully booted and the Xen tools to +become available, domains created by Xen this way are started in +parallel to Dom0. Hence, their boot time is typically much shorter. + +Domains started by Xen at boot time currently have the following +limitations: + +- they cannot be properly shutdown or rebooted using xl +If one of them crashes, the whole platform should be rebooted. + +- some xl operations might not work as expected +xl is meant to be used with domains that have been created by it. Using +xl with domains started by Xen at boot might not work as expected. + +- the GIC version is the native version +In absence of other information, the GIC version exposed to the domains +started by Xen at boot is the same as the native GIC version. + +- no PV drivers +There is no support for PV devices at the moment. All devices need to be +statically assigned to guests. + +- vCPU pinning +Pinning vCPUs of domains started by Xen at boot can be done from dom0, +using `xl vcpu-pin' as usual. It is not currently possible to configure +vCPU pinning for domains other than dom0 without dom0. However, the NULL +scheduler can be selected by passing `sched=null' to the Xen command +line. The NULL scheduler automatically assigns and pins vCPUs to pCPUs, +but the vCPU-pCPU assignments cannot be configured. -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 17/23] xen/arm: introduce a union in vpl011
Introduce a union in struct vpl011 to contain the console ring members.
A later patch will add another member of the union for the case where
the backend is in Xen.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- name union "backend"
Changes in v3:
- rename ring field to dom
Changes in v2:
- new patch
---
xen/arch/arm/vpl011.c| 22 --
xen/include/asm-arm/vpl011.h | 8 ++--
2 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index a281eab..ebc045e 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -82,7 +82,7 @@ static uint8_t vpl011_read_data(struct domain *d)
unsigned long flags;
uint8_t data = 0;
struct vpl011 *vpl011 = &d->arch.vpl011;
-struct xencons_interface *intf = vpl011->ring_buf;
+struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
XENCONS_RING_IDX in_cons, in_prod;
VPL011_LOCK(d, flags);
@@ -145,7 +145,7 @@ static uint8_t vpl011_read_data(struct domain *d)
static void vpl011_update_tx_fifo_status(struct vpl011 *vpl011,
unsigned int fifo_level)
{
-struct xencons_interface *intf = vpl011->ring_buf;
+struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
unsigned int fifo_threshold = sizeof(intf->out) - SBSA_UART_FIFO_LEVEL;
BUILD_BUG_ON(sizeof(intf->out) < SBSA_UART_FIFO_SIZE);
@@ -164,7 +164,7 @@ static void vpl011_write_data(struct domain *d, uint8_t
data)
{
unsigned long flags;
struct vpl011 *vpl011 = &d->arch.vpl011;
-struct xencons_interface *intf = vpl011->ring_buf;
+struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
XENCONS_RING_IDX out_cons, out_prod;
VPL011_LOCK(d, flags);
@@ -382,7 +382,7 @@ static void vpl011_data_avail(struct domain *d)
{
unsigned long flags;
struct vpl011 *vpl011 = &d->arch.vpl011;
-struct xencons_interface *intf = vpl011->ring_buf;
+struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
XENCONS_RING_IDX in_cons, in_prod, out_cons, out_prod;
XENCONS_RING_IDX in_fifo_level, out_fifo_level;
@@ -459,14 +459,14 @@ int domain_vpl011_init(struct domain *d, struct
vpl011_init_info *info)
int rc;
struct vpl011 *vpl011 = &d->arch.vpl011;
-if ( vpl011->ring_buf )
+if ( vpl011->backend.dom.ring_buf )
return -EINVAL;
/* Map the guest PFN to Xen address space. */
rc = prepare_ring_for_helper(d,
gfn_x(info->gfn),
- &vpl011->ring_page,
- &vpl011->ring_buf);
+ &vpl011->backend.dom.ring_page,
+ &vpl011->backend.dom.ring_buf);
if ( rc < 0 )
goto out;
@@ -495,7 +495,8 @@ out2:
vgic_free_virq(d, GUEST_VPL011_SPI);
out1:
-destroy_ring_for_helper(&vpl011->ring_buf, vpl011->ring_page);
+destroy_ring_for_helper(&vpl011->backend.dom.ring_buf,
+ vpl011->backend.dom.ring_page);
out:
return rc;
@@ -505,11 +506,12 @@ void domain_vpl011_deinit(struct domain *d)
{
struct vpl011 *vpl011 = &d->arch.vpl011;
-if ( !vpl011->ring_buf )
+if ( !vpl011->backend.dom.ring_buf )
return;
free_xen_event_channel(d, vpl011->evtchn);
-destroy_ring_for_helper(&vpl011->ring_buf, vpl011->ring_page);
+destroy_ring_for_helper(&vpl011->backend.dom.ring_buf,
+ vpl011->backend.dom.ring_page);
}
/*
diff --git a/xen/include/asm-arm/vpl011.h b/xen/include/asm-arm/vpl011.h
index db95ff8..42d7a24 100644
--- a/xen/include/asm-arm/vpl011.h
+++ b/xen/include/asm-arm/vpl011.h
@@ -31,8 +31,12 @@
#define SBSA_UART_FIFO_SIZE 32
struct vpl011 {
-void *ring_buf;
-struct page_info *ring_page;
+union {
+struct {
+void *ring_buf;
+struct page_info *ring_page;
+} dom;
+} backend;
uint32_tuartfr; /* Flag register */
uint32_tuartcr; /* Control register */
uint32_tuartimsc; /* Interrupt mask register*/
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 09/23] xen/arm: rename allocate_memory to allocate_memory_11
allocate_memory only deals with directly mapped memory. Rename it to
allocate_memory_11.
Signed-off-by: Stefano Stabellini
---
Changes in v3:
- add patch
---
xen/arch/arm/domain_build.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d0aff35..41f2f27 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -243,7 +243,8 @@ fail:
* (as described above) we allow higher allocations and continue until
* that runs out (or we have allocated sufficient dom0 memory).
*/
-static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
+static void __init allocate_memory_11(struct domain *d,
+ struct kernel_info *kinfo)
{
const unsigned int min_low_order =
get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
@@ -2156,7 +2157,7 @@ int __init construct_dom0(struct domain *d)
#endif
kinfo.cmdline = kernel != NULL ? &kernel->cmdline[0] : NULL;
-allocate_memory(d, &kinfo);
+allocate_memory_11(d, &kinfo);
find_gnttab_region(d, &kinfo);
/* Map extra GIC MMIO, irqs and other hw stuffs to dom0. */
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 06/23] xen/arm: don't add duplicate boot modules, introduce domU flag
Don't add duplicate boot modules (same kind and same start address),
they are freed later, we don't want to introduce double-free errors.
Introduce a domU flag in struct bootmodule and struct bootcmdline. Set
it for kernels and ramdisks of "xen,domain" nodes to avoid getting
confused in kernel_probe, where we try to guess which is the dom0 kernel
and initrd to be compatible with older versions of the multiboot spec.
boot_module_find_by_kind and boot_cmdline_find_by_kind automatically
check for !domU entries (they are only used for non-domU modules).
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- use unsigned int
- better commit message
- introduce domU flag and usage
Changes in v2:
- new patch
---
xen/arch/arm/bootfdt.c | 14 +-
xen/arch/arm/setup.c| 21 +
xen/include/asm-arm/setup.h | 4 +++-
3 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 273032b..349aa9d 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -164,7 +164,8 @@ static void __init process_memory_node(const void *fdt, int
node,
}
static void __init add_boot_cmdline(const void *fdt, int node,
-const char *name, bootmodule_kind kind)
+const char *name, bootmodule_kind kind,
+bool domU)
{
struct bootcmdlines *cmds = &bootinfo.cmdlines;
struct bootcmdline *cmd;
@@ -184,6 +185,7 @@ static void __init add_boot_cmdline(const void *fdt, int
node,
cmd = &cmds->cmdline[cmds->nr_mods++];
cmd->kind = kind;
+cmd->domU = domU;
ASSERT(strlen(name) <= DT_MAX_NAME);
safe_strcpy(cmd->dt_name, name);
@@ -206,6 +208,7 @@ static void __init process_multiboot_node(const void *fdt,
int node,
int len = sizeof("/chosen");
char path[8]; /* sizeof "/chosen" */
int parent_node;
+bool domU;
parent_node = fdt_parent_offset(fdt, node);
ASSERT(parent_node >= 0);
@@ -263,8 +266,9 @@ static void __init process_multiboot_node(const void *fdt,
int node,
kind = BOOTMOD_XSM;
}
-add_boot_module(kind, start, size);
-add_boot_cmdline(fdt, node, fdt_get_name(fdt, parent_node, &len), kind);
+domU = fdt_node_check_compatible(fdt, parent_node, "xen,domain") == 0;
+add_boot_module(kind, start, size, domU);
+add_boot_cmdline(fdt, node, fdt_get_name(fdt, parent_node, &len), kind,
domU);
}
static void __init process_chosen_node(const void *fdt, int node,
@@ -310,7 +314,7 @@ static void __init process_chosen_node(const void *fdt, int
node,
printk("Initrd %"PRIpaddr"-%"PRIpaddr"\n", start, end);
-add_boot_module(BOOTMOD_RAMDISK, start, end-start);
+add_boot_module(BOOTMOD_RAMDISK, start, end-start, false);
}
static int __init early_scan_node(const void *fdt,
@@ -381,7 +385,7 @@ size_t __init boot_fdt_info(const void *fdt, paddr_t paddr)
if ( ret < 0 )
panic("No valid device tree\n");
-add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt));
+add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt), false);
device_tree_for_each_node((void *)fdt, early_scan_node, NULL);
early_print_info();
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index bc7dd97..dbab232 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -201,10 +201,12 @@ void __init dt_unreserved_regions(paddr_t s, paddr_t e,
}
struct bootmodule __init *add_boot_module(bootmodule_kind kind,
- paddr_t start, paddr_t size)
+ paddr_t start, paddr_t size,
+ bool domU)
{
struct bootmodules *mods = &bootinfo.modules;
struct bootmodule *mod;
+unsigned int i;
if ( mods->nr_mods == MAX_MODULES )
{
@@ -212,11 +214,22 @@ struct bootmodule __init *add_boot_module(bootmodule_kind
kind,
boot_module_kind_as_string(kind), start, start + size);
return NULL;
}
+for ( i = 0 ; i < mods->nr_mods ; i++ )
+{
+mod = &mods->module[i];
+if ( mod->kind == kind && mod->start == start )
+{
+if ( !domU )
+mod->domU = false;
+return mod;
+}
+}
mod = &mods->module[mods->nr_mods++];
mod->kind = kind;
mod->start = start;
mod->size = size;
+mod->domU = domU;
return mod;
}
@@ -229,7 +242,7 @@ struct bootmodule * __init
boot_module_find_by_kind(bootmodule_kind kind)
for (i = 0 ; i < mods->nr_mods ; i++ )
{
mod = &mods->module[i];
-if ( mod->kind == kind )
+if ( mod->kind == kind && !mod->domU )
return mod;
}
return NULL;
@@ -244,7 +257,7 @@ struct bootcmdline * __init
boot_cmdline_find_by_kind(bootmodule_kind kind)
for ( i = 0 ; i < cmds->nr_mods ; i++ )
{
[Xen-devel] [PATCH v4 05/23] xen/arm: introduce bootcmdlines
Introduce a new array to store the cmdline of each boot module. It is
separate from struct bootmodules. Remove the cmdline field from struct
boot_module. This way, kernels and initrds with the same address in
memory can share struct bootmodule (important because we want them to be
free'd only once), but they can still have their separate bootcmdline
entries.
Add a dt_name field to struct bootcmdline to make it easier to find the
correct entry. Store the name of the "xen,domain" compatible node (for
example "Dom1"). This is a better choice compared to the name of the
"multiboot,kernel" compatible node, because their names are not unique.
For instance there can be more than one "module@0x4c00" in the
system, but there can only be one "/chosen/Dom1".
Add a pointer to struct kernel_info to point to the cmdline for a given
kernel.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- check that the multiboot node is under /chosen
- use cmd and cmds as variable names for struct bootcmdline and struct
bootcmdline*
- fix printk
- use ASSERT instea of panic
- do not add empty cmdline entries
- add more debug printks to early_print_info
- code style fixes
- add comment on DT_MAX_NAME
- increase DT_MAX_NAME to 41
- make nr_mods unsigned int
Changes in v3:
- introduce bootcmdlines
- do not modify boot_fdt_cmdline
- add comments
Changes in v2:
- new patch
---
xen/arch/arm/bootfdt.c | 82 +
xen/arch/arm/domain_build.c | 8 +++--
xen/arch/arm/kernel.h | 1 +
xen/arch/arm/setup.c| 24 +
xen/include/asm-arm/setup.h | 17 --
5 files changed, 99 insertions(+), 33 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 8eba42c..273032b 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -163,6 +163,37 @@ static void __init process_memory_node(const void *fdt,
int node,
}
}
+static void __init add_boot_cmdline(const void *fdt, int node,
+const char *name, bootmodule_kind kind)
+{
+struct bootcmdlines *cmds = &bootinfo.cmdlines;
+struct bootcmdline *cmd;
+const struct fdt_property *prop;
+int len;
+const char *cmdline;
+
+if ( cmds->nr_mods == MAX_MODULES )
+{
+printk("Ignoring %s cmdline (too many)\n", name);
+return;
+}
+
+prop = fdt_get_property(fdt, node, "bootargs", &len);
+if ( !prop )
+return;
+
+cmd = &cmds->cmdline[cmds->nr_mods++];
+cmd->kind = kind;
+
+ASSERT(strlen(name) <= DT_MAX_NAME);
+safe_strcpy(cmd->dt_name, name);
+
+if ( len > BOOTMOD_MAX_CMDLINE )
+panic("module %s command line too long\n", name);
+cmdline = prop->data;
+safe_strcpy(cmd->cmdline, cmdline);
+}
+
static void __init process_multiboot_node(const void *fdt, int node,
const char *name,
u32 address_cells, u32 size_cells)
@@ -172,8 +203,20 @@ static void __init process_multiboot_node(const void *fdt,
int node,
const __be32 *cell;
bootmodule_kind kind;
paddr_t start, size;
-const char *cmdline;
-int len;
+int len = sizeof("/chosen");
+char path[8]; /* sizeof "/chosen" */
+int parent_node;
+
+parent_node = fdt_parent_offset(fdt, node);
+ASSERT(parent_node >= 0);
+
+/* Check that the node is under "chosen" */
+fdt_get_path(fdt, node, path, len);
+if ( strncmp(path, "/chosen", len - 1) )
+{
+printk("DEBUG %s %s\n",name,path);
+return;
+}
prop = fdt_get_property(fdt, node, "reg", &len);
if ( !prop )
@@ -220,17 +263,8 @@ static void __init process_multiboot_node(const void *fdt,
int node,
kind = BOOTMOD_XSM;
}
-prop = fdt_get_property(fdt, node, "bootargs", &len);
-if ( prop )
-{
-if ( len > BOOTMOD_MAX_CMDLINE )
-panic("module %s command line too long\n", name);
-cmdline = prop->data;
-}
-else
-cmdline = NULL;
-
-add_boot_module(kind, start, size, cmdline);
+add_boot_module(kind, start, size);
+add_boot_cmdline(fdt, node, fdt_get_name(fdt, parent_node, &len), kind);
}
static void __init process_chosen_node(const void *fdt, int node,
@@ -276,7 +310,7 @@ static void __init process_chosen_node(const void *fdt, int
node,
printk("Initrd %"PRIpaddr"-%"PRIpaddr"\n", start, end);
-add_boot_module(BOOTMOD_RAMDISK, start, end-start, NULL);
+add_boot_module(BOOTMOD_RAMDISK, start, end-start);
}
static int __init early_scan_node(const void *fdt,
@@ -299,6 +333,7 @@ static void __init early_print_info(void)
{
struct meminfo *mi = &bootinfo.mem;
struct bootmodules *mods = &bootinfo.modules;
+struct bootcmdlines *cmds = &bootinfo.cmdlines;
int i, nr_rsvd;
for ( i = 0; i < mi->nr_banks; i++ )
@@ -307,12 +342,12 @@ static void __init early_print_info(void)
[Xen-devel] [PATCH v4 07/23] xen/arm: probe domU kernels and initrds
Find addresses, sizes on device tree from kernel_probe.
Find the cmdline from the bootcmdlines array.
Introduce a new boot_module_find_by_addr_and_kind function to match not
just on boot module kind, but also by address so that we can support
multiple domains.
Introduce a boot_cmdline_find_by_name function to find the right struct
cmdline based on the device tree node name of the "xen,domain"
compatible node.
Signed-off-by: Stefano Stabellini
---
Changes in v3:
- retrieve cmdline from bootcmdlines array
Changes in v2:
- fix indentation
- unify kernel_probe with kernel_probe_domU
- find cmdline on device_tree from kernel_probe
---
xen/arch/arm/domain_build.c | 2 +-
xen/arch/arm/kernel.c | 52 +++--
xen/arch/arm/kernel.h | 2 +-
xen/arch/arm/setup.c| 29 +
xen/include/asm-arm/setup.h | 3 +++
5 files changed, 79 insertions(+), 9 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 64f8d6b..f073e6d 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2137,7 +2137,7 @@ int __init construct_dom0(struct domain *d)
kinfo.unassigned_mem = dom0_mem;
kinfo.d = d;
-rc = kernel_probe(&kinfo);
+rc = kernel_probe(&kinfo, NULL);
if ( rc < 0 )
return rc;
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index da8410e..e5b8213 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -421,22 +421,60 @@ static int __init kernel_zimage32_probe(struct
kernel_info *info,
return 0;
}
-int __init kernel_probe(struct kernel_info *info)
+int __init kernel_probe(struct kernel_info *info, struct dt_device_node
*domain)
{
-struct bootmodule *mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
+struct bootmodule *mod = NULL;
+struct bootcmdline *cmd = NULL;
+struct dt_device_node *node;
+u64 kernel_addr, initrd_addr, size;
+const char *name = NULL;
int rc;
+if ( domain == NULL )
+{
+mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
+
+info->kernel_bootmodule = mod;
+info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK);
+} else {
+dt_for_each_child_node(domain, node)
+{
+if ( dt_device_is_compatible(node, "multiboot,kernel") )
+{
+u32 len;
+const __be32 *val;
+val = dt_get_property(node, "reg", &len);
+dt_get_range(&val, node, &kernel_addr, &size);
+}
+else if ( dt_device_is_compatible(node, "multiboot,ramdisk") )
+{
+u32 len;
+const __be32 *val;
+val = dt_get_property(node, "reg", &len);
+dt_get_range(&val, node, &initrd_addr, &size);
+}
+else
+continue;
+}
+if ( kernel_addr )
+info->kernel_bootmodule = mod = boot_module_find_by_addr_and_kind(
+ BOOTMOD_KERNEL, kernel_addr);
+if ( initrd_addr )
+info->initrd_bootmodule = boot_module_find_by_addr_and_kind(
+ BOOTMOD_RAMDISK, initrd_addr);
+name = dt_node_name(domain);
+cmd = boot_cmdline_find_by_name(name);
+if ( cmd )
+info->cmdline = &cmd->cmdline[0];
+}
if ( !mod || !mod->size )
{
printk(XENLOG_ERR "Missing kernel boot module?\n");
return -ENOENT;
}
-info->kernel_bootmodule = mod;
-
-printk("Loading kernel from boot module @ %"PRIpaddr"\n", mod->start);
-
-info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK);
+printk("Loading DomU kernel from boot module @ %"PRIpaddr"\n",
+ info->kernel_bootmodule->start);
if ( info->initrd_bootmodule )
printk("Loading ramdisk from boot module @ %"PRIpaddr"\n",
info->initrd_bootmodule->start);
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
index 39b7828..4a65289 100644
--- a/xen/arch/arm/kernel.h
+++ b/xen/arch/arm/kernel.h
@@ -55,7 +55,7 @@ struct kernel_info {
* ->type
* ->load hook, and sets loader specific variables ->zimage
*/
-int kernel_probe(struct kernel_info *info);
+int kernel_probe(struct kernel_info *info, struct dt_device_node *domain);
/*
* Loads the kernel into guest RAM.
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index dbab232..d6d1546 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -263,6 +263,35 @@ struct bootcmdline * __init
boot_cmdline_find_by_kind(bootmodule_kind kind)
return NULL;
}
+struct bootcmdline * __init boot_cmdline_find_by_name(const char *name)
+{
+struct bootcmdlines *mods = &bootinfo.cmdlines;
+struct bootcmdline *mod;
+int i;
+for (i = 0 ; i < mods->nr_mods ; i++ )
+{
+mod = &mods->cmdline[i];
+if ( strcmp(mod->dt_name,
[Xen-devel] [PATCH v4 04/23] xen/arm: increase MAX_MODULES
Xen boot modules need to account not just for Dom0 but also for a few
potential DomUs, each of them coming with their own kernel and initrd.
Increase MAX_MODULES to 32 to allow for more DomUs.
Signed-off-by: Stefano Stabellini
Reviewed-by: Doug Goldstein
---
xen/include/asm-arm/setup.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 0cc3330..f1e4a3f 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -8,7 +8,7 @@
#define NR_MEM_BANKS 128
-#define MAX_MODULES 5 /* Current maximum useful modules */
+#define MAX_MODULES 32 /* Current maximum useful modules */
typedef enum {
BOOTMOD_XEN,
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 19/23] xen/arm: Allow vpl011 to be used by DomU
Make vpl011 being able to be used without a userspace component in Dom0.
In that case, output is printed to the Xen serial and input is received
from the Xen serial one character at a time.
Call domain_vpl011_init during construct_domU if vpl011 is enabled.
Introduce a new ring struct with only the ring array to avoid a waste of
memory. Introduce separate read_data and write_data functions for
initial domains: vpl011_write_data_xen is very simple and just writes
to the console, while vpl011_read_data_xen is a duplicate of
vpl011_read_data. Although textually almost identical, we are forced to
duplicate the functions because the struct layout is different.
Output characters are printed one by one, potentially leading to
intermixed output of different domains on the console. A follow-up patch
will solve the issue by introducing buffering.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- code style
Changes in v3:
- add in-code comments
- improve existing comments
- remove ifdef around domain_vpl011_init in construct_domU
- add ASSERT
- use SBSA_UART_FIFO_SIZE for in buffer size
- rename ring_enable to backend_in_domain
- rename struct xencons_in to struct vpl011_xen_backend
- rename inring field to xen
- rename helper functions accordingly
- remove unnecessary stub implementation of vpl011_rx_char
- move vpl011_rx_char_xen within the file to avoid the need of a forward
declaration of vpl011_data_avail
- fix small bug in vpl011_rx_char_xen: increment in_prod before using it
to check xencons_queued.
Changes in v2:
- only init if vpl011
- rename vpl011_read_char to vpl011_rx_char
- remove spurious change
- fix coding style
- use different ring struct
- move the write_data changes to their own function
(vpl011_write_data_noring)
- duplicate vpl011_read_data
---
xen/arch/arm/domain_build.c | 9 +-
xen/arch/arm/vpl011.c| 200 +--
xen/include/asm-arm/vpl011.h | 8 ++
3 files changed, 192 insertions(+), 25 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 049ab84..4379538 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2618,7 +2618,14 @@ static int __init construct_domU(struct domain *d,
if ( rc < 0 )
return rc;
-return __construct_domain(d, &kinfo);
+rc = __construct_domain(d, &kinfo);
+if ( rc < 0 )
+return rc;
+
+if ( kinfo.vpl011 )
+rc = domain_vpl011_init(d, NULL);
+
+return rc;
}
void __init create_domUs(void)
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 68452a8..131507e 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -77,6 +77,91 @@ static void vpl011_update_interrupt_status(struct domain *d)
#endif
}
+/*
+ * vpl011_write_data_xen writes chars from the vpl011 out buffer to the
+ * console. Only to be used when the backend is Xen.
+ */
+static void vpl011_write_data_xen(struct domain *d, uint8_t data)
+{
+unsigned long flags;
+struct vpl011 *vpl011 = &d->arch.vpl011;
+
+VPL011_LOCK(d, flags);
+
+printk("%c", data);
+if (data == '\n')
+printk("DOM%u: ", d->domain_id);
+
+vpl011->uartris |= TXI;
+vpl011->uartfr &= ~TXFE;
+vpl011_update_interrupt_status(d);
+
+VPL011_UNLOCK(d, flags);
+}
+
+/*
+ * vpl011_read_data_xen reads data when the backend is xen. Characters
+ * are added to the vpl011 receive buffer by vpl011_rx_char_xen.
+ */
+static uint8_t vpl011_read_data_xen(struct domain *d)
+{
+unsigned long flags;
+uint8_t data = 0;
+struct vpl011 *vpl011 = &d->arch.vpl011;
+struct vpl011_xen_backend *intf = vpl011->backend.xen;
+XENCONS_RING_IDX in_cons, in_prod;
+
+VPL011_LOCK(d, flags);
+
+in_cons = intf->in_cons;
+in_prod = intf->in_prod;
+
+smp_rmb();
+
+/*
+ * It is expected that there will be data in the ring buffer when this
+ * function is called since the guest is expected to read the data register
+ * only if the TXFE flag is not set.
+ * If the guest still does read when TXFE bit is set then 0 will be
returned.
+ */
+if ( xencons_queued(in_prod, in_cons, sizeof(intf->in)) > 0 )
+{
+unsigned int fifo_level;
+
+data = intf->in[xencons_mask(in_cons, sizeof(intf->in))];
+in_cons += 1;
+smp_mb();
+intf->in_cons = in_cons;
+
+fifo_level = xencons_queued(in_prod, in_cons, sizeof(intf->in));
+
+/* If the FIFO is now empty, we clear the receive timeout interrupt. */
+if ( fifo_level == 0 )
+{
+vpl011->uartfr |= RXFE;
+vpl011->uartris &= ~RTI;
+}
+
+/* If the FIFO is more than half empty, we clear the RX interrupt. */
+if ( fifo_level < sizeof(intf->in) - SBSA_UART_FIFO_LEVEL )
+vpl011->uartris &= ~RXI;
+
+vpl011_update_interrupt_status(d);
+}
+else
+gprintk(XENLOG_ERR, "vpl011: Unexpected IN ring buffer empty\n
[Xen-devel] [PATCH v4 18/23] xen/arm: refactor vpl011_data_avail
Move the code to calculate in_fifo_level and out_fifo_level out of
vpl011_data_avail, to the caller.
This change will make it possible to reuse vpl011_data_avail with
different ring structures in a later patch.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v3:
- remove forward declaration of vpl011_data_avail
Changes in v2:
- new patch
---
xen/arch/arm/vpl011.c | 64 +--
1 file changed, 36 insertions(+), 28 deletions(-)
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index ebc045e..68452a8 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -378,30 +378,13 @@ static const struct mmio_handler_ops vpl011_mmio_handler
= {
.write = vpl011_mmio_write,
};
-static void vpl011_data_avail(struct domain *d)
+static void vpl011_data_avail(struct domain *d,
+ XENCONS_RING_IDX in_fifo_level,
+ XENCONS_RING_IDX in_size,
+ XENCONS_RING_IDX out_fifo_level,
+ XENCONS_RING_IDX out_size)
{
-unsigned long flags;
struct vpl011 *vpl011 = &d->arch.vpl011;
-struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
-XENCONS_RING_IDX in_cons, in_prod, out_cons, out_prod;
-XENCONS_RING_IDX in_fifo_level, out_fifo_level;
-
-VPL011_LOCK(d, flags);
-
-in_cons = intf->in_cons;
-in_prod = intf->in_prod;
-out_cons = intf->out_cons;
-out_prod = intf->out_prod;
-
-smp_rmb();
-
-in_fifo_level = xencons_queued(in_prod,
- in_cons,
- sizeof(intf->in));
-
-out_fifo_level = xencons_queued(out_prod,
-out_cons,
-sizeof(intf->out));
/ Update the UART RX state /
@@ -410,11 +393,11 @@ static void vpl011_data_avail(struct domain *d)
vpl011->uartfr &= ~RXFE;
/* Set the FIFO_FULL bit if the Xen buffer is full. */
-if ( in_fifo_level == sizeof(intf->in) )
+if ( in_fifo_level == in_size )
vpl011->uartfr |= RXFF;
/* Assert the RX interrupt if the FIFO is more than half way filled. */
-if ( in_fifo_level >= sizeof(intf->in) - SBSA_UART_FIFO_LEVEL )
+if ( in_fifo_level >= in_size - SBSA_UART_FIFO_LEVEL )
vpl011->uartris |= RXI;
/*
@@ -427,7 +410,7 @@ static void vpl011_data_avail(struct domain *d)
/ Update the UART TX state /
-if ( out_fifo_level != sizeof(intf->out) )
+if ( out_fifo_level != out_size )
{
vpl011->uartfr &= ~TXFF;
@@ -445,13 +428,38 @@ static void vpl011_data_avail(struct domain *d)
if ( out_fifo_level == 0 )
vpl011->uartfr |= TXFE;
-
-VPL011_UNLOCK(d, flags);
}
static void vpl011_notification(struct vcpu *v, unsigned int port)
{
-vpl011_data_avail(v->domain);
+unsigned long flags;
+struct domain *d = v->domain;
+struct vpl011 *vpl011 = &d->arch.vpl011;
+struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
+XENCONS_RING_IDX in_cons, in_prod, out_cons, out_prod;
+XENCONS_RING_IDX in_fifo_level, out_fifo_level;
+
+VPL011_LOCK(d, flags);
+
+in_cons = intf->in_cons;
+in_prod = intf->in_prod;
+out_cons = intf->out_cons;
+out_prod = intf->out_prod;
+
+smp_rmb();
+
+in_fifo_level = xencons_queued(in_prod,
+ in_cons,
+ sizeof(intf->in));
+
+out_fifo_level = xencons_queued(out_prod,
+out_cons,
+sizeof(intf->out));
+
+vpl011_data_avail(v->domain, in_fifo_level, sizeof(intf->in),
+ out_fifo_level, sizeof(intf->out));
+
+VPL011_UNLOCK(d, flags);
}
int domain_vpl011_init(struct domain *d, struct vpl011_init_info *info)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 10/23] xen/arm: introduce allocate_memory
Introduce an allocate_memory function able to allocate memory for DomUs
and map it at the right guest addresses, according to the guest memory
map: GUEST_RAM0_BASE and GUEST_RAM1_BASE.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- move earlier, add #if 0
- introduce allocate_bank_memory, remove insert_bank
- allocate_bank_memory allocate memory and inserts the bank, while
allocate_memory specifies where to do that
Changes in v3:
- new patch
---
xen/arch/arm/domain_build.c | 83 +
1 file changed, 83 insertions(+)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 41f2f27..fddfd82 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -368,6 +368,89 @@ static void __init allocate_memory_11(struct domain *d,
}
}
+#if 0
+static bool __init allocate_bank_memory(struct domain *d,
+struct kernel_info *kinfo,
+gfn_t sgfn,
+unsigned int order)
+{
+int res;
+struct page_info *pg;
+struct membank *bank;
+paddr_t gaddr = gfn_to_gaddr(sgfn), size = pfn_to_paddr(1UL << order);
+
+pg = alloc_domheap_pages(d, order, 0);
+if ( !pg )
+return false;
+
+res = guest_physmap_add_page(d, sgfn, page_to_mfn(pg), order);
+if ( res )
+{
+dprintk(XENLOG_ERR, "Failed map pages to DOMU: %d", res);
+goto fail;
+}
+
+bank = &kinfo->mem.bank[kinfo->mem.nr_banks];
+bank->start = gaddr;
+bank->size = size;
+kinfo->mem.nr_banks++;
+kinfo->unassigned_mem -= size;
+return true;
+
+fail:
+free_domheap_pages(pg, order);
+return false;
+}
+
+static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
+{
+unsigned int order = get_allocation_size(kinfo->unassigned_mem);
+unsigned int order_req;
+int i;
+
+dprintk(XENLOG_INFO, "Allocating mappings totalling %ldMB for dom%d:\n",
+/* Don't want format this as PRIpaddr (16 digit hex) */
+(unsigned long)(kinfo->unassigned_mem >> 20), d->domain_id);
+
+kinfo->mem.nr_banks = 0;
+
+order = get_allocation_size(kinfo->unassigned_mem);
+if ( order > get_order_from_bytes(GUEST_RAM0_SIZE) )
+order_req = get_order_from_bytes(GUEST_RAM0_SIZE);
+else
+order_req = order;
+if ( !allocate_bank_memory(d, kinfo, gaddr_to_gfn(GUEST_RAM0_BASE),
order_req) )
+goto fail;
+
+order -= order_req;
+if ( order > 0 )
+{
+if ( !allocate_bank_memory(d, kinfo, gaddr_to_gfn(GUEST_RAM1_BASE),
order) )
+goto fail;
+}
+
+for( i = 0; i < kinfo->mem.nr_banks; i++ )
+{
+dprintk(XENLOG_INFO, "Dom%d BANK[%d] %#"PRIpaddr"-%#"PRIpaddr"
(%ldMB)\n",
+d->domain_id,
+i,
+kinfo->mem.bank[i].start,
+kinfo->mem.bank[i].start + kinfo->mem.bank[i].size,
+/* Don't want format this as PRIpaddr (16 digit hex) */
+(unsigned long)(kinfo->mem.bank[i].size >> 20));
+}
+
+return;
+
+fail:
+dprintk(XENLOG_ERR, "Failed to allocate requested domain memory."
+/* Don't want format this as PRIpaddr (16 digit hex) */
+" %ldKB unallocated. Fix the VMs configurations.\n",
+(unsigned long)kinfo->unassigned_mem >> 10);
+BUG();
+}
+#endif
+
static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
const struct dt_device_node *node)
{
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 21/23] xen/vpl011: buffer out chars when the backend is xen
To avoid mixing the output of different domains on the console, buffer
the output chars and print line by line. Unless the domain has input
from the serial, in which case we want to print char by char for a
smooth user experience.
The size of SBSA_UART_OUT_BUF_SIZE is arbitrary, choose the same size
as VUART_BUT_SIZE used in vuart.c.
Export a function named console_input_domain() to allow others to know
which domains has input at a given time.
Signed-off-by: Stefano Stabellini
CC: andrew.coop...@citrix.com
CC: george.dun...@eu.citrix.com
CC: ian.jack...@eu.citrix.com
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
CC: t...@xen.org
CC: wei.l...@citrix.com
---
XXX: merge this patch with "xen/arm: Allow vpl011 to be used by DomU" on
commit
Changes in v4:
- make SBSA_UART_OUT_BUF_SIZE the same size of VUART_BUT_SIZE
- rearrange the code to be clearer input and != input cases
- code style
- add \n when printing the out buffer because is full
- don't print prefix for input domain
---
xen/arch/arm/vpl011.c| 35 ---
xen/drivers/char/console.c | 7 +++
xen/include/asm-arm/vpl011.h | 4
xen/include/xen/console.h| 2 ++
4 files changed, 45 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 131507e..5e57ada 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -85,12 +86,40 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t
data)
{
unsigned long flags;
struct vpl011 *vpl011 = &d->arch.vpl011;
+struct vpl011_xen_backend *intf = vpl011->backend.xen;
+struct domain *input = console_input_domain();
VPL011_LOCK(d, flags);
-printk("%c", data);
-if (data == '\n')
-printk("DOM%u: ", d->domain_id);
+intf->out[intf->out_prod++] = data;
+if ( d == input )
+{
+if ( intf->out_prod == 1 )
+{
+printk("%c", data);
+intf->out_prod = 0;
+}
+else
+{
+if ( data != '\n' )
+intf->out[intf->out_prod++] = '\n';
+intf->out[intf->out_prod++] = '\0';
+printk("%s", intf->out);
+intf->out_prod = 0;
+}
+}
+else
+{
+if ( intf->out_prod == SBSA_UART_OUT_BUF_SIZE - 2 ||
+ data == '\n' )
+{
+if ( data != '\n' )
+intf->out[intf->out_prod++] = '\n';
+intf->out[intf->out_prod++] = '\0';
+printk("DOM%u: %s", d->domain_id, intf->out);
+intf->out_prod = 0;
+}
+}
vpl011->uartris |= TXI;
vpl011->uartfr &= ~TXFE;
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 0808bac..9a2b29a 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -406,6 +406,13 @@ static void dump_console_ring_key(unsigned char key)
*/
static unsigned int __read_mostly console_rx = 0;
+struct domain *console_input_domain(void)
+{
+if ( console_rx == 0 )
+return NULL;
+return get_domain_by_id(console_rx - 1);
+}
+
static void switch_serial_input(void)
{
if ( console_rx++ == max_init_domid + 1 )
diff --git a/xen/include/asm-arm/vpl011.h b/xen/include/asm-arm/vpl011.h
index 5eb6d25..ab6fd79 100644
--- a/xen/include/asm-arm/vpl011.h
+++ b/xen/include/asm-arm/vpl011.h
@@ -30,9 +30,13 @@
#define VPL011_UNLOCK(d,flags) spin_unlock_irqrestore(&(d)->arch.vpl011.lock,
flags)
#define SBSA_UART_FIFO_SIZE 32
+/* Same size as VUART_BUT_SIZE, used in vuart.c */
+#define SBSA_UART_OUT_BUF_SIZE 128
struct vpl011_xen_backend {
char in[SBSA_UART_FIFO_SIZE];
+char out[SBSA_UART_OUT_BUF_SIZE];
XENCONS_RING_IDX in_cons, in_prod;
+XENCONS_RING_IDX out_prod;
};
struct vpl011 {
diff --git a/xen/include/xen/console.h b/xen/include/xen/console.h
index 70c9911..c5a85c8 100644
--- a/xen/include/xen/console.h
+++ b/xen/include/xen/console.h
@@ -31,6 +31,8 @@ void console_end_sync(void);
void console_start_log_everything(void);
void console_end_log_everything(void);
+struct domain *console_input_domain(void);
+
/*
* Steal output from the console. Returns +ve identifier, else -ve error.
* Takes the handle of the serial line to steal, and steal callback function.
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 12/23] xen/arm: introduce create_domUs
Call a new function, "create_domUs", from setup_xen to start DomU VMs.
Introduce support for the "xen,domU" compatible node on device tree.
Create new DomU VMs based on the information found on device tree under
"xen,domU". Calls construct_domU for each domain.
Introduce a simple global variable named max_init_domid to keep track of
the initial allocated domids. It holds the max domid among the initial
domains.
Move the discard_initial_modules after DomUs have been built.
First create domUs, then start dom0 -- no point in trying to start dom0
when the cpu is busy.
Signed-off-by: Stefano Stabellini
Acked-by: Jan Beulich
CC: andrew.coop...@citrix.com
CC: jbeul...@suse.com
---
Changes in v4:
- constify parameters
- nr_spis to 0 or GUEST_VPL011_SPI - 32 + 1 depending on vpl011
- remove pointless initializer
- remove change to domain_create for dom0 (useless)
- make construct_domU return error
Changes in v3:
- move patch earlier and introduce empty construct_domU to fix bisection
builds
- fix max_init_domid to actually hold the max domid among initial
domains (instead of max_domid + 1)
- move domain_unpause_by_systemcontroller(dom0) after creating domUs
Changes in v2:
- coding style
- set nr_spis to 32
- introduce create_domUs
---
xen/arch/arm/domain_build.c | 51 +
xen/arch/arm/setup.c| 5 +
xen/include/asm-arm/setup.h | 3 +++
xen/include/asm-x86/setup.h | 2 ++
4 files changed, 57 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index ba3dad1..547b624 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2290,6 +2291,51 @@ static int __init __construct_domain(struct domain *d,
struct kernel_info *kinfo
return 0;
}
+static int __init construct_domU(struct domain *d,
+ const struct dt_device_node *node)
+{
+return -ENOSYS;
+}
+
+void __init create_domUs(void)
+{
+struct dt_device_node *node;
+const struct dt_device_node *chosen = dt_find_node_by_name(dt_host,
+ "chosen");
+BUG_ON(chosen == NULL);
+dt_for_each_child_node(chosen, node)
+{
+u32 len;
+struct domain *d;
+struct xen_domctl_createdomain d_cfg = {
+.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE,
+.arch.nr_spis = 0,
+.max_vcpus = 1,
+.max_evtchn_port = -1,
+.max_grant_frames = 64,
+.max_maptrack_frames = 1024,
+};
+
+if ( !dt_device_is_compatible(node, "xen,domain") )
+continue;
+
+if ( dt_get_property(node, "vpl011", &len) != NULL )
+d_cfg.arch.nr_spis = GUEST_VPL011_SPI - 32 + 1;
+dt_property_read_u32(node, "cpus", &d_cfg.max_vcpus);
+
+d = domain_create(++max_init_domid, &d_cfg, false);
+if ( IS_ERR(d) )
+panic("Error creating domain %s", dt_node_name(node));
+
+d->is_console = 1;
+
+if ( construct_domU(d, node) != 0 )
+panic("Could not set up domain %s", dt_node_name(node));
+
+domain_unpause_by_systemcontroller(d);
+}
+}
+
int __init construct_dom0(struct domain *d)
{
const struct bootcmdline *kernel =
boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
@@ -2342,10 +2388,7 @@ int __init construct_dom0(struct domain *d)
if ( rc < 0 )
return rc;
-rc = __construct_domain(d, &kinfo);
-discard_initial_modules();
-
-return rc;
+return __construct_domain(d, &kinfo);
}
/*
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index d6d1546..8d8f180 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -64,8 +64,11 @@ static unsigned long opt_xenheap_megabytes __initdata;
integer_param("xenheap_megabytes", opt_xenheap_megabytes);
#endif
+domid_t __read_mostly max_init_domid;
+
static __used void init_done(void)
{
+discard_initial_modules();
free_init_memory();
startup_cpu_idle_loop();
}
@@ -926,6 +929,8 @@ void __init start_xen(unsigned long boot_phys_offset,
/* Must be done past setting system_state. */
unregister_init_virtual_region();
+create_domUs();
+
domain_unpause_by_systemcontroller(dom0);
/* Switch on to the dynamically allocated stack for the idle vcpu
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 177e8db..5620fe7 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -68,6 +68,8 @@ struct bootinfo {
extern struct bootinfo bootinfo;
+extern domid_t max_init_domid;
+
void arch_init_memory(void);
void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
@@ -84,6 +86,7 @@ void acpi_create_efi_mmap_table(struct domain *d,
int acpi_make_efi_nodes(void *fdt, struct membank tbl_add[]);
int construct_do
[Xen-devel] [PATCH v4 16/23] xen/arm: generate vpl011 node on device tree for domU
Introduce vpl011 support to guests started from Xen: it provides a
simple way to print output from a guest, as most guests come with a
pl011 driver. It is also able to provide a working console with
interrupt support.
The UART exposed to the guest is a SBSA compatible UART and not a PL011.
SBSA UART is a subset of PL011 r1p5. A full PL011 implementation in Xen
would just be too difficult, so guests may require some drivers changes.
Enable vpl011 conditionally if the user requested it.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- move rename set_interrupt_ppi and making set_interrupt_ppi generic to
a separate patch
- properly name the vpl011 device node name
- code style
- use #define for addrcells and sizecells
Changes in v3:
- use bool
- retain BUG_ON(irq < 16)
- add vpl011 bool to kinfo
- return error of vpl011 is required but CONFIG_SBSA_VUART_CONSOLE is
missing
Changes in v2:
- code style fixes
- make set_interrupt_ppi generic
- rename set_interrupt_ppi to set_interrupt
- only make the vpl011 node if the option was enabled
---
xen/arch/arm/domain_build.c | 61 +
xen/arch/arm/kernel.h | 3 +++
2 files changed, 64 insertions(+)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 760ebf8..049ab84 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1605,6 +1605,54 @@ static int __init make_timer_domU_node(const struct
domain *d, void *fdt)
return res;
}
+#ifdef CONFIG_SBSA_VUART_CONSOLE
+static int __init make_vpl011_uart_node(const struct domain *d, void *fdt)
+{
+int res;
+gic_interrupt_t intr;
+__be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS];
+__be32 *cells;
+
+res = fdt_begin_node(fdt, "sbsa-uart@"__stringify(GUEST_PL011_BASE));
+if ( res )
+return res;
+
+res = fdt_property_string(fdt, "compatible", "arm,sbsa-uart");
+if ( res )
+return res;
+
+cells = ®[0];
+dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS,
+ GUEST_ROOT_SIZE_CELLS, GUEST_PL011_BASE,
+ GUEST_PL011_SIZE);
+if ( res )
+return res;
+res = fdt_property(fdt, "reg", reg, sizeof(reg));
+if ( res )
+return res;
+
+set_interrupt(intr, GUEST_VPL011_SPI, 0xf, DT_IRQ_TYPE_LEVEL_HIGH);
+
+res = fdt_property(fdt, "interrupts", intr, sizeof (intr));
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "interrupt-parent",
+GUEST_PHANDLE_GIC);
+if ( res )
+return res;
+
+/* Use a default baud rate of 115200. */
+fdt_property_u32(fdt, "current-speed", 115200);
+
+res = fdt_end_node(fdt);
+if ( res )
+return res;
+
+return 0;
+}
+#endif
+
/*
* The max size for DT is 2MB. However, the generated DT is small, 4KB
* are enough for now, but we might have to increase it in the future.
@@ -1666,6 +1714,16 @@ static int __init prepare_dtb_domU(struct domain *d,
struct kernel_info *kinfo)
if ( ret )
goto err;
+if ( kinfo->vpl011 )
+{
+ret = -EINVAL;
+#ifdef CONFIG_SBSA_VUART_CONSOLE
+ret = make_vpl011_uart_node(d, kinfo->fdt);
+#endif
+if ( ret )
+goto err;
+}
+
ret = fdt_end_node(kinfo->fdt);
if ( ret < 0 )
goto err;
@@ -2523,6 +2581,7 @@ static int __init construct_domU(struct domain *d,
struct kernel_info kinfo = {};
int rc;
u64 mem;
+u32 len;
rc = dt_property_read_u64(node, "memory", &mem);
if ( !rc )
@@ -2534,6 +2593,8 @@ static int __init construct_domU(struct domain *d,
printk("*** LOADING DOMU cpus=%u memory=%luKB ***\n", d->max_vcpus, mem);
+kinfo.vpl011 = dt_get_property(node, "vpl011", &len) != NULL;
+
d->vcpu = xzalloc_array(struct vcpu *, d->max_vcpus);
if ( !d->vcpu )
return -ENOMEM;;
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
index 4320f72..33f3e72 100644
--- a/xen/arch/arm/kernel.h
+++ b/xen/arch/arm/kernel.h
@@ -33,6 +33,9 @@ struct kernel_info {
paddr_t dtb_paddr;
paddr_t initrd_paddr;
+/* Enable pl011 emulation */
+bool vpl011;
+
/* loader to use for this kernel */
void (*load)(struct kernel_info *info);
/* loader specific state */
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 08/23] xen/arm: rename get_11_allocation_size to get_allocation_size
No functional changes.
Signed-off-by: Stefano Stabellini
---
Changes in v3:
- no change in print messages
- do not remove BUG_ON
Changes in v2:
- new patch
---
xen/arch/arm/domain_build.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f073e6d..d0aff35 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -77,7 +77,7 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
return vcpu_create(dom0, 0, 0);
}
-static unsigned int __init get_11_allocation_size(paddr_t size)
+static unsigned int __init get_allocation_size(paddr_t size)
{
/*
* get_order_from_bytes returns the order greater than or equal to
@@ -249,7 +249,7 @@ static void __init allocate_memory(struct domain *d, struct
kernel_info *kinfo)
get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
const unsigned int min_order = get_order_from_bytes(MB(4));
struct page_info *pg;
-unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
+unsigned int order = get_allocation_size(kinfo->unassigned_mem);
int i;
bool lowmem = true;
@@ -301,7 +301,7 @@ static void __init allocate_memory(struct domain *d, struct
kernel_info *kinfo)
* If we failed to allocate bank0 under 4GB, continue allocating
* memory from above 4GB and fill in banks.
*/
-order = get_11_allocation_size(kinfo->unassigned_mem);
+order = get_allocation_size(kinfo->unassigned_mem);
while ( kinfo->unassigned_mem && kinfo->mem.nr_banks < NR_MEM_BANKS )
{
pg = alloc_domheap_pages(d, order, lowmem ? MEMF_bits(32) : 0);
@@ -312,7 +312,7 @@ static void __init allocate_memory(struct domain *d, struct
kernel_info *kinfo)
if ( lowmem && order < min_low_order)
{
D11PRINT("Failed at min_low_order, allow high allocations\n");
-order = get_11_allocation_size(kinfo->unassigned_mem);
+order = get_allocation_size(kinfo->unassigned_mem);
lowmem = false;
continue;
}
@@ -332,7 +332,7 @@ static void __init allocate_memory(struct domain *d, struct
kernel_info *kinfo)
if ( lowmem )
{
D11PRINT("Allocation below bank 0, allow high allocations\n");
-order = get_11_allocation_size(kinfo->unassigned_mem);
+order = get_allocation_size(kinfo->unassigned_mem);
lowmem = false;
continue;
}
@@ -347,7 +347,7 @@ static void __init allocate_memory(struct domain *d, struct
kernel_info *kinfo)
* Success, next time around try again to get the largest order
* allocation possible.
*/
-order = get_11_allocation_size(kinfo->unassigned_mem);
+order = get_allocation_size(kinfo->unassigned_mem);
}
if ( kinfo->unassigned_mem )
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 01/23] xen: allow console_io hypercalls from certain DomUs
Introduce an is_console option to allow certain classes of domUs to use
the Xen console. Specifically, it will be used to give console access to
all domUs started from Xen from information on device tree.
Signed-off-by: Stefano Stabellini
Acked-by: Daniel De Graaf
CC: andrew.coop...@citrix.com
CC: george.dun...@eu.citrix.com
CC: ian.jack...@eu.citrix.com
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
CC: t...@xen.org
CC: wei.l...@citrix.com
CC: dgde...@tycho.nsa.gov
---
Changes in v3:
- remove changes to hooks.c
Changes in v2:
- introduce is_console
- remove #ifdefs
---
xen/include/xen/sched.h | 2 ++
xen/include/xsm/dummy.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 0ba80cb..abcc74e 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -379,6 +379,8 @@ struct domain
bool auto_node_affinity;
/* Is this guest fully privileged (aka dom0)? */
bool is_privileged;
+/* Can this guest access the Xen console? */
+bool is_console;
/* Is this a xenstore domain (not dom0)? */
bool is_xenstore;
/* Domain's VCPUs are pinned 1:1 to physical CPUs? */
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index b0ac1f6..29d7b50 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -230,6 +230,8 @@ static XSM_INLINE int
xsm_memory_stat_reservation(XSM_DEFAULT_ARG struct domain
static XSM_INLINE int xsm_console_io(XSM_DEFAULT_ARG struct domain *d, int cmd)
{
XSM_ASSERT_ACTION(XSM_OTHER);
+if ( d->is_console )
+return xsm_default_action(XSM_HOOK, d, NULL);
#ifdef CONFIG_VERBOSE_DEBUG
if ( cmd == CONSOLEIO_write )
return xsm_default_action(XSM_HOOK, d, NULL);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 00/23] dom0less step1: boot multiple domains from device tree
Hi all,
This is first step toward "dom0less" as discussed in the various
certifications related threads and discussions.
The goal of this series is to enable Xen to boot multiple domains in
parallel, in addition to dom0, out of information found on device tree.
The device tree based boot protocol is extended to carry information
about DomUs. Based on that information, Xen creates and starts one or
more DomUs. DomUs created this way don't have access to xenstore for the
moment. This is actually OK, because this is meant for mission critical
applications that typically only access directly assigned devices. They
cannot tolerate interference or increased IRQ latency due to PV
protocols. Device assignment is not actually covered by this series, it
will be added later.
DomUs can print to the Xen serial using the CONSOLEIO hypercalls. A
virtual PL011 is also emulated for them so that they can use their
regular PL011 driver. This allows unmodified guests to run as Xen on ARM
guests -- no Xen support needed at all. Console input also comes from
the Xen serial: the Ctrl-AAA switching mechanism is extended to switch
among domUs, dom0, and Xen.
In this version of the series, I reordered the patches to make sure they
are all bisectable.
Cheers,
Stefano
The following changes since commit 359970fd8b781fac2ddcbc84dd5b890075fa08ef:
tools/libxl: Switch Arm guest type to PVH (2018-10-03 15:58:02 +0100)
are available in the git repository at:
http://xenbits.xenproject.org/git-http/people/sstabellini/xen-unstable.git
dom0less-v4
for you to fetch changes up to ad670c5672597613f4153f356e44e55e8b37a0cd:
xen/arm: split domain_build.c (2018-10-05 11:40:26 -0700)
Stefano Stabellini (23):
xen: allow console_io hypercalls from certain DomUs
xen/arm: extend device tree based multiboot protocol
xen/arm: document dom0less
xen/arm: increase MAX_MODULES
xen/arm: introduce bootcmdlines
xen/arm: don't add duplicate boot modules, introduce domU flag
xen/arm: probe domU kernels and initrds
xen/arm: rename get_11_allocation_size to get_allocation_size
xen/arm: rename allocate_memory to allocate_memory_11
xen/arm: introduce allocate_memory
xen/arm: refactor construct_dom0
xen/arm: introduce create_domUs
xen/arm: implement construct_domU
xen/arm: generate a simple device tree for domUs
xen/arm: make set_interrupt_ppi able to handle non-PPI
xen/arm: generate vpl011 node on device tree for domU
xen/arm: introduce a union in vpl011
xen/arm: refactor vpl011_data_avail
xen/arm: Allow vpl011 to be used by DomU
xen: support console_switching between Dom0 and DomUs on ARM
xen/vpl011: buffer out chars when the backend is xen
xen/arm: move kernel.h to asm-arm/
xen/arm: split domain_build.c
docs/misc/arm/device-tree/booting.txt | 107 +++
docs/misc/arm/dom0less.txt | 47 ++
xen/arch/arm/acpi/Makefile |1 +
xen/arch/arm/acpi/domain_build.c | 592 +++
xen/arch/arm/bootfdt.c | 86 ++-
xen/arch/arm/domain_build.c| 1073 +---
xen/arch/arm/kernel.c | 56 +-
xen/arch/arm/setup.c | 71 +-
xen/arch/arm/vpl011.c | 295 ++--
xen/drivers/char/console.c | 80 ++-
xen/include/asm-arm/domain_build.h | 31 +
xen/{arch/arm => include/asm-arm}/kernel.h |6 +-
xen/include/asm-arm/setup.h| 27 +-
xen/include/asm-arm/vpl011.h | 20 +-
xen/include/asm-x86/setup.h|2 +
xen/include/xen/console.h |2 +
xen/include/xen/sched.h|2 +
xen/include/xsm/dummy.h|2 +
18 files changed, 1802 insertions(+), 698 deletions(-)
create mode 100644 docs/misc/arm/dom0less.txt
create mode 100644 xen/arch/arm/acpi/domain_build.c
create mode 100644 xen/include/asm-arm/domain_build.h
rename xen/{arch/arm => include/asm-arm}/kernel.h (91%)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 23/25] xen: support console_switching between Dom0 and DomUs on ARM
On Fri, 5 Oct 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 10/04/2018 10:52 PM, Stefano Stabellini wrote:
> > On Wed, 1 Aug 2018, Jan Beulich wrote:
> > > > > > On 01.08.18 at 01:28, wrote:
> > > > Today Ctrl-AAA is used to switch between Xen and Dom0. Extend the
> > > > mechanism to allow for switching between Xen, Dom0, and any of the
> > > > initial DomU created from Xen alongside Dom0 out of information provided
> > > > via device tree.
> > > >
> > > > Rename xen_rx to console_rx to match the new behavior.
> > > >
> > > > Clarify existing comment about "notify the guest", making it clear that
> > > > it is only about the hardware domain.
> > > >
> > > > Export a function named console_input_domain() to allow others to know
> > > > which domains has input at a given time.
> > >
> > > As always in such cases I don't think such functions should be added
> > > without any caller.
> >
> > I'll add console_input_domain within an #if 0 and remove the #if 0 in
> > the following patch. If you are OK with it, the two patches can be
> > merged on commit (Julien already agreed to it.) They are separate only
> > to make them easier to review.
>
> Which two patches? I agreed to merge #24 and #22. Not #23. Merging the 3 of
> them is going to make a massive patch which is not going to help understand
> patches after they get merged.
No, you are right, I got confused. That's correct #22 and #24 are the
ones to be merged, I'll add a note about this to the patches. Sorry
about that.
> >
> > > > @@ -389,30 +392,72 @@ static void dump_console_ring_key(unsigned char
> > > > key)
> > > > free_xenheap_pages(buf, order);
> > > > }
> > > > -/* CTRL- switches input direction between Xen and DOM0.
> > > > */
> > > > +/*
> > > > + * CTRL- switches input direction between Xen, Dom0 and
> > > > + * DomUs.
> > > > + */
> > > > #define switch_code (opt_conswitch[0]-'a'+1)
> > > > -static int __read_mostly xen_rx = 1; /* FALSE => input passed to domain
> > > > 0. */
> > > > +/*
> > > > + * console_rx=0 => input to xen
> > > > + * console_rx=1 => input to dom0
> > > > + * console_rx=N => input dom(N-1)
> > > > + */
> > > > +static int __read_mostly console_rx = 0;
> > >
> > > Originally this was supposed to be bool, but didn't get switched yet.
> > > With your current scheme it can't go negative and hence should be
> > > unsigned int. However, I still wonder whether it wouldn't be better
> > > (especially for readers of the code) is this was an actual domid_t.
> > > But as clarified before, I'm not meaning to make this a requirement.
> >
> > I'll use unsigned int
> >
> >
> > > > +struct domain *console_input_domain(void)
> > > > +{
> > > > +return get_domain_by_id(console_rx - 1);
> > > > +}
> > >
> > > And this is exactly the reason for the above remark: This is (or at
> > > least looks) broken for console_rx == 0.
> >
> > I'll fix
> >
> >
> > > > static void switch_serial_input(void)
> > > > {
> > > > -static char *input_str[2] = { "DOM0", "Xen" };
> > > > -xen_rx = !xen_rx;
> > > > -printk("*** Serial input -> %s", input_str[xen_rx]);
> > > > +console_rx++;
> > > > +if ( console_rx == max_init_domid + 2 )
> > > > +console_rx = 0;
> > >
> > > Same here - the literal 2 at least raises questions. I think it would
> > > at least be a little less confusing if you had
> > >
> > > if ( console_rx++ == max_init_domid + 1 )
> > > console_rx = 0;
> >
> > I'll do
> >
> >
> > > > static void __serial_rx(char c, struct cpu_user_regs *regs)
> > > > {
> > > > -if ( xen_rx )
> > > > +if ( console_rx == 0 )
> > > > return handle_keypress(c, regs);
> > > > -/* Deliver input to guest buffer, unless it is already full. */
> > > > -if ( (serial_rx_prod-serial_rx_cons) != SERIAL_RX_SIZE )
> > > > -serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
> > > > -/* Always notify the guest: prevents receive path from getting
> > > > stuck. */
> > >
> > > Just like you adjust "guest" in this comment, I think you'd better ...
> > >
> > > > +if ( console_rx == 1 )
> > > > +{
> > > > +/* Deliver input to guest buffer, unless it is already full. */
> > >
> > > ... adjust it here too.
> >
> > I'll fix
> >
> >
> > > > +if ( (serial_rx_prod - serial_rx_cons) != SERIAL_RX_SIZE )
> > > > +serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
> > > > +}
> > > > +#ifdef CONFIG_SBSA_VUART_CONSOLE
> > > > +else
> > > > +{
> > > > +struct domain *d = get_domain_by_id(console_rx - 1);
> > > > +
> > > > +/*
> > > > + * If we have a properly initialized vpl011 console for the
> > > > + * domain, without a full PV ring to Dom0 (in that case input
> > > > + * comes from the PV ring), then send the character to it.
> > > > + */
> > > > +if ( !d->arch.vpl011.backend_in_domain && d->arch.vpl011.xen !=
> > > > NULL )
> > > > +vpl011
Re: [Xen-devel] [PATCH v3 23/25] xen: support console_switching between Dom0 and DomUs on ARM
On Fri, 5 Oct 2018, Julien Grall wrote: > On 10/05/2018 10:25 AM, Julien Grall wrote: > > On 10/04/2018 10:52 PM, Stefano Stabellini wrote: > > > On Wed, 1 Aug 2018, Jan Beulich wrote: > > > > > > > On 01.08.18 at 01:28, wrote: > > > > > Today Ctrl-AAA is used to switch between Xen and Dom0. Extend the > > > > > mechanism to allow for switching between Xen, Dom0, and any of the > > > > > initial DomU created from Xen alongside Dom0 out of information > > > > > provided > > > > > via device tree. > > > > > > > > > > Rename xen_rx to console_rx to match the new behavior. > > > > > > > > > > Clarify existing comment about "notify the guest", making it clear > > > > > that > > > > > it is only about the hardware domain. > > > > > > > > > > Export a function named console_input_domain() to allow others to know > > > > > which domains has input at a given time. > > > > > > > > As always in such cases I don't think such functions should be added > > > > without any caller. > > > > > > I'll add console_input_domain within an #if 0 and remove the #if 0 in > > > the following patch. If you are OK with it, the two patches can be > > > merged on commit (Julien already agreed to it.) They are separate only > > > to make them easier to review. > > > > Which two patches? I agreed to merge #24 and #22. Not #23. Merging the 3 of > > them is going to make a massive patch which is not going to help understand > > patches after they get merged. > > Thinking a bit more. Why does it need to be under #if 0 and then merging the 2 > patches? There are nothing prevent a 2 line function to be moved from one > patch to another. I'll move console_input_domain to the following patch (#24). ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 128426: tolerable all pass - PUSHED
flight 128426 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/128426/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 91d4eca7add6a7a114bc05cc6d38223a0c0b5575 baseline version: xen cc6e309c6e4368a1094b5e7593cf8cf5803ed709 Last test of basis 128422 2018-10-05 13:06:06 Z0 days Testing same since 128426 2018-10-05 16:00:58 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Boris Ostrovsky Brian Woods George Dunlap Jan Beulich Julien Grall Paul Durrant Razvan Cojocaru Suravee Suthikulpanit Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git cc6e309c6e..91d4eca7ad 91d4eca7add6a7a114bc05cc6d38223a0c0b5575 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 17/18] xenmon: Install as xenmon, not xenmon.py
Adding the implementation language as a suffix to a program name is poor practice. Signed-off-by: Ian Jackson --- tools/xenmon/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/xenmon/Makefile b/tools/xenmon/Makefile index e45c5b8c14..e1712304d0 100644 --- a/tools/xenmon/Makefile +++ b/tools/xenmon/Makefile @@ -32,13 +32,13 @@ install: build $(INSTALL_DIR) $(DESTDIR)$(sbindir) $(INSTALL_PROG) xenbaked $(DESTDIR)$(sbindir)/xenbaked $(INSTALL_PROG) xentrace_setmask $(DESTDIR)$(sbindir)/xentrace_setmask - $(INSTALL_PROG) xenmon.py $(DESTDIR)$(sbindir)/xenmon.py + $(INSTALL_PROG) xenmon.py $(DESTDIR)$(sbindir)/xenmon .PHONY: uninstall uninstall: rm -f $(DESTDIR)$(sbindir)/xenbaked rm -f $(DESTDIR)$(sbindir)/xentrace_setmask - rm -f $(DESTDIR)$(sbindir)/xenmon.py + rm -f $(DESTDIR)$(sbindir)/xenmon .PHONY: clean clean: -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 14/18] gdbsx: Honour LDFLAGS when linking
This command does the link, so it needs LDFLAGS. Signed-off-by: Ian Jackson --- tools/debugger/gdbsx/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/debugger/gdbsx/Makefile b/tools/debugger/gdbsx/Makefile index 723a2743cc..8d7cd94a31 100644 --- a/tools/debugger/gdbsx/Makefile +++ b/tools/debugger/gdbsx/Makefile @@ -26,7 +26,7 @@ uninstall: rm -f $(DESTDIR)$(sbindir)/gdbsx gdbsx: gx/gx_all.a xg/xg_all.a - $(CC) -o $@ $^ + $(CC) $(LDFLAGS) -o $@ $^ xg/xg_all.a: $(MAKE) -C xg -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 13/18] tools/xenstat: Fix shared library version
From: Bastian Blank libxenstat does not have a stable ABI. Set its version to the current Xen release version. Signed-off-by: Ian Jackson --- tools/xenstat/libxenstat/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/xenstat/libxenstat/Makefile b/tools/xenstat/libxenstat/Makefile index 8979fa1583..8c6ddf86e8 100644 --- a/tools/xenstat/libxenstat/Makefile +++ b/tools/xenstat/libxenstat/Makefile @@ -18,7 +18,7 @@ include $(XEN_ROOT)/tools/Rules.mk LDCONFIG=ldconfig MAKE_LINK=ln -sf -MAJOR=0 +MAJOR=4.11 MINOR=0 LIB=src/libxenstat.a -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 18/18] tools/debugger/kdd: Install as `xen-kdd', not just `kdd'
`kdd' is an unfortunate namespace landgrab. Signed-off-by: Ian Jackson --- tools/debugger/kdd/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/debugger/kdd/Makefile b/tools/debugger/kdd/Makefile index 5509eee68c..26116949d4 100644 --- a/tools/debugger/kdd/Makefile +++ b/tools/debugger/kdd/Makefile @@ -24,8 +24,8 @@ distclean: clean .PHONY: install install: all [ -d $(DESTDIR)$(sbindir) ] || $(INSTALL_DIR) $(DESTDIR)$(sbindir) - $(INSTALL_PROG) kdd $(DESTDIR)$(sbindir)/kdd + $(INSTALL_PROG) kdd $(DESTDIR)$(sbindir)/xen-kdd .PHONY: uninstall uninstall: - rm -f $(DESTDIR)$(sbindir)/kdd + rm -f $(DESTDIR)$(sbindir)/xen-kdd -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 16/18] pygrub fsimage.so: Honour LDFLAGS when building
This seems to have been simply omitted. Obviously this is needed when building and not just when installing. Passing only when installing is ineffective. Signed-off-by: Ian Jackson --- tools/pygrub/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/pygrub/Makefile b/tools/pygrub/Makefile index 536af07932..3063c4998f 100644 --- a/tools/pygrub/Makefile +++ b/tools/pygrub/Makefile @@ -10,7 +10,7 @@ INSTALL_LOG = build/installed_files.txt all: build .PHONY: build build: - CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py build + CC="$(CC)" CFLAGS="$(PY_CFLAGS)" LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) setup.py build .PHONY: install install: all -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 10/18] INSTALL: Mention kconfig
Firstly, add a reference to the documentation for the kconfig system. Secondly, warn the user about the XEN_CONFIG_EXPERT problem. CC: Doug Goldstein CC: Wei Liu CC: Jan Beulich CC: Andrew Cooper Signed-off-by: Ian Jackson --- INSTALL | 20 1 file changed, 20 insertions(+) diff --git a/INSTALL b/INSTALL index 9aa9ebdddc..62b0162864 100644 --- a/INSTALL +++ b/INSTALL @@ -19,6 +19,26 @@ following compile process. Once configure is done, make(1) has to be called. Also make(1) recognizes certain arguments. The following sections will give an overview. +Xen Hypervisor +== + +Xen itself is configured via a `kconfig' system borrowed from Linux. +See docs/misc/kconfig.txt. + +Note that unlike with Linux, and contrary to that document, you cannot +look at Kconfig files, or the default or generated config files etc., +to find available configuration options. This is because it is only +supported (and security supported) by the Xen Project, to change a +small subset of the options. Attempts to change other options will be +silently overriden. The only way to find which configuration options +are available is to run `make menuconfig' or the like. + +You can counter-override this behaviour by setting XEN_CONFIG_EXPERT=y +in your environment. However, doing this is not supported and the +resulting configurations do not receive security support. If you set +this varible there is nothing stopping you setting dangerously +experimental combinations of features - not even any warnings. + Options recognized by configure === -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 15/18] libfsimage: Honour general LDFLAGS
Do not reset LDFLAGS to empty. Instead, append the fsimage-special LDFLAGS. Signed-off-by: Ian Jackson --- tools/libfsimage/common/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libfsimage/common/Makefile b/tools/libfsimage/common/Makefile index 0791fc9923..a4655c421c 100644 --- a/tools/libfsimage/common/Makefile +++ b/tools/libfsimage/common/Makefile @@ -6,7 +6,7 @@ MINOR = 0 LDFLAGS-$(CONFIG_SunOS) = -Wl,-M -Wl,mapfile-SunOS LDFLAGS-$(CONFIG_Linux) = -Wl,mapfile-GNU -LDFLAGS = $(LDFLAGS-y) +LDFLAGS += $(LDFLAGS-y) CFLAGS += $(PTHREAD_CFLAGS) LDFLAGS += $(PTHREAD_LDFLAGS) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 12/18] docs/man/xen-pv-channel.pod.7: Remove a spurious blank line
No functional change. Signed-off-by: Ian Jackson --- docs/man/xen-pv-channel.pod.7 | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/man/xen-pv-channel.pod.7 b/docs/man/xen-pv-channel.pod.7 index f9f0108488..07898f6dde 100644 --- a/docs/man/xen-pv-channel.pod.7 +++ b/docs/man/xen-pv-channel.pod.7 @@ -1,6 +1,5 @@ =encoding utf8 - =head1 NAME xen-pv-channel - Xen PV Channels -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 11/18] docs/man: Provide properly-formatted NAME sections
A manpage `foo.7.pod' must start with =head NAME foo - some summary of what foo is or what this manpage is because otherwise manpage catalogue systems cannot generate a proper `whatis' entry. Signed-off-by: Ian Jackson --- docs/man/xen-pci-device-reservations.pod.7 | 4 docs/man/xen-pv-channel.pod.7 | 2 +- docs/man/xen-tscmode.pod.7 | 4 docs/man/xen-vtpm.pod.7| 6 ++ docs/man/xen-vtpmmgr.pod.7 | 4 docs/man/xl-numa-placement.pod.7 | 2 +- 6 files changed, 20 insertions(+), 2 deletions(-) diff --git a/docs/man/xen-pci-device-reservations.pod.7 b/docs/man/xen-pci-device-reservations.pod.7 index dac92764fc..049e47410f 100644 --- a/docs/man/xen-pci-device-reservations.pod.7 +++ b/docs/man/xen-pci-device-reservations.pod.7 @@ -1,3 +1,7 @@ +=head1 NAME + +xen-pci-device-reservations - Xen PCI device ID registry + =head1 Description PCI vendor ID 0x5853 has been reserved for use by Xen systems in order to diff --git a/docs/man/xen-pv-channel.pod.7 b/docs/man/xen-pv-channel.pod.7 index 7229b26d06..f9f0108488 100644 --- a/docs/man/xen-pv-channel.pod.7 +++ b/docs/man/xen-pv-channel.pod.7 @@ -3,7 +3,7 @@ =head1 NAME -Xen PV Channels +xen-pv-channel - Xen PV Channels =head1 DESCRIPTION diff --git a/docs/man/xen-tscmode.pod.7 b/docs/man/xen-tscmode.pod.7 index 3bbc96f201..819c61dd05 100644 --- a/docs/man/xen-tscmode.pod.7 +++ b/docs/man/xen-tscmode.pod.7 @@ -1,3 +1,7 @@ +=head1 NAME + +xen-tscmode - Xen TSC (time stamp counter) and timekeeping discussion + =head1 OVERVIEW As of Xen 4.0, a new config option called tsc_mode may be specified diff --git a/docs/man/xen-vtpm.pod.7 b/docs/man/xen-vtpm.pod.7 index 8de67f4d94..1d8185616a 100644 --- a/docs/man/xen-vtpm.pod.7 +++ b/docs/man/xen-vtpm.pod.7 @@ -1,3 +1,9 @@ +=head1 NAME + +xen-vtpm - Xen virtual Trusted Platform Module (vTPM) subsystem + +=head1 RUBRIC + Copyright (c) 2010-2012 United States Government, as represented by the Secretary of Defense. All rights reserved. November 12 2012 diff --git a/docs/man/xen-vtpmmgr.pod.7 b/docs/man/xen-vtpmmgr.pod.7 index 2c3a2de8aa..af825a7ffe 100644 --- a/docs/man/xen-vtpmmgr.pod.7 +++ b/docs/man/xen-vtpmmgr.pod.7 @@ -1,3 +1,7 @@ +=head1 NAME + +xen-vtpmgr - Xen virtual TPM stubdomain + =head1 Authors =over 4 diff --git a/docs/man/xl-numa-placement.pod.7 b/docs/man/xl-numa-placement.pod.7 index 54a444172e..ae8330207e 100644 --- a/docs/man/xl-numa-placement.pod.7 +++ b/docs/man/xl-numa-placement.pod.7 @@ -2,7 +2,7 @@ =head1 NAME -Guest Automatic NUMA Placement in libxl and xl +xl-numa-placement - Guest Automatic NUMA Placement in libxl and xl =head1 DESCRIPTION -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 05/18] Various: Fix typo `reseting'
Signed-off-by: Ian Jackson
---
tools/misc/xenlockprof.c | 2 +-
tools/misc/xenperf.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/misc/xenlockprof.c b/tools/misc/xenlockprof.c
index df23c82912..11f43a35e3 100644
--- a/tools/misc/xenlockprof.c
+++ b/tools/misc/xenlockprof.c
@@ -46,7 +46,7 @@ int main(int argc, char *argv[])
{
if ( xc_lockprof_reset(xc_handle) != 0 )
{
-fprintf(stderr, "Error reseting profile data: %d (%s)\n",
+fprintf(stderr, "Error resetting profile data: %d (%s)\n",
errno, strerror(errno));
return 1;
}
diff --git a/tools/misc/xenperf.c b/tools/misc/xenperf.c
index 07e584a5eb..a5fbdaa45f 100644
--- a/tools/misc/xenperf.c
+++ b/tools/misc/xenperf.c
@@ -123,7 +123,7 @@ int main(int argc, char *argv[])
{
if ( xc_perfc_reset(xc_handle) != 0 )
{
-fprintf(stderr, "Error reseting performance counters: %d (%s)\n",
+fprintf(stderr, "Error resetting performance counters: %d (%s)\n",
errno, strerror(errno));
return 1;
}
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 01/18] docs/man: Fix two typos detected by the Debian lintian tool
Signed-off-by: Ian Jackson --- docs/man/xenstore.pod.1 | 2 +- docs/man/xl.pod.1.in| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/man/xenstore.pod.1 b/docs/man/xenstore.pod.1 index 74172891e2..dd8f80647d 100644 --- a/docs/man/xenstore.pod.1 +++ b/docs/man/xenstore.pod.1 @@ -18,7 +18,7 @@ Sets the permissions of keys. =item B(1) -Test for the existance of a key. +Test for the existence of a key. =item B(1) diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in index b74764dcd3..18006880d6 100644 --- a/docs/man/xl.pod.1.in +++ b/docs/man/xl.pod.1.in @@ -1398,7 +1398,7 @@ Creates a new network device in the domain specified by I. I describes the device to attach, using the same format as the B string in the domain config file. See L and L -for more informations. +for more information. Note that only attaching PV network interfaces is supported. -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 09/18] tools/Rules.mk: Honour PREPEND_LDFLAGS_XEN_TOOLS
This allows the caller to provide some LDFLAGS to the Xen build system. Signed-off-by: Ian Jackson --- tools/Rules.mk | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/Rules.mk b/tools/Rules.mk index 296b722372..68f2ed7ce1 100644 --- a/tools/Rules.mk +++ b/tools/Rules.mk @@ -9,6 +9,8 @@ include $(XEN_ROOT)/Config.mk export _INSTALL := $(INSTALL) INSTALL = $(XEN_ROOT)/tools/cross-install +LDFLAGS += $(PREPEND_LDFLAGS_XEN_TOOLS) + XEN_INCLUDE= $(XEN_ROOT)/tools/include XEN_LIBXENTOOLCORE = $(XEN_ROOT)/tools/libs/toolcore XEN_LIBXENTOOLLOG = $(XEN_ROOT)/tools/libs/toollog -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 07/18] Various: Fix typo `infomation'
Signed-off-by: Ian Jackson
---
tools/libxl/libxl_internal.h | 2 +-
tools/python/xen/lowlevel/xc/xc.c | 2 +-
tools/xenstat/libxenstat/src/xenstat_qmp.c | 2 +-
xen/common/sched_rt.c | 2 +-
xen/drivers/acpi/apei/erst.c | 2 +-
xen/include/public/domctl.h| 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 802382c704..43947b1b07 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2604,7 +2604,7 @@ struct libxl__multidev {
* Once finished, aodev->callback will be executed.
*/
/*
- * As of Xen 4.5 we maintain various infomation, including hotplug
+ * As of Xen 4.5 we maintain various information, including hotplug
* device information, in JSON files, so that we can use this JSON
* file as a template to reconstruct domain configuration.
*
diff --git a/tools/python/xen/lowlevel/xc/xc.c
b/tools/python/xen/lowlevel/xc/xc.c
index 6f5b8a6fa8..ebef92cd50 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -2200,7 +2200,7 @@ static PyMethodDef pyxc_methods[] = {
{ "get_device_group",
(PyCFunction)pyxc_get_device_group,
METH_VARARGS, "\n"
- "get sibling devices infomation.\n"
+ "get sibling devices information.\n"
" dom [int]: Domain to assign device to.\n"
" seg [int]: PCI segment.\n"
" bus [int]: PCI bus.\n"
diff --git a/tools/xenstat/libxenstat/src/xenstat_qmp.c
b/tools/xenstat/libxenstat/src/xenstat_qmp.c
index 3fda487d49..19b236e7b6 100644
--- a/tools/xenstat/libxenstat/src/xenstat_qmp.c
+++ b/tools/xenstat/libxenstat/src/xenstat_qmp.c
@@ -59,7 +59,7 @@ enum query_block {
/* Given the qmp device name, get the image filename associated with it
- QMP Syntax for querying block infomation:
+ QMP Syntax for querying block information:
In: { "execute": "query-block" }
Out: {"return": [{
"device": 'str, "locked": 'bool', "removable": bool,
diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index ac79f15dc3..59fbfa625f 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -203,7 +203,7 @@ struct rt_vcpu {
s_time_t period;
s_time_t budget;
-/* VCPU current infomation in nanosecond */
+/* VCPU current information in nanosecond */
s_time_t cur_budget; /* current budget */
s_time_t last_start; /* last start time */
s_time_t cur_deadline; /* current deadline for EDF */
diff --git a/xen/drivers/acpi/apei/erst.c b/xen/drivers/acpi/apei/erst.c
index 7fc4de5de9..3a2e403173 100644
--- a/xen/drivers/acpi/apei/erst.c
+++ b/xen/drivers/acpi/apei/erst.c
@@ -2,7 +2,7 @@
* APEI Error Record Serialization Table support
*
* ERST is a way provided by APEI to save and retrieve hardware error
- * infomation to and from a persistent store.
+ * information to and from a persistent store.
*
* For more information about ERST, please refer to ACPI Specification
* version 4.0, section 17.4.
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 82b696798c..1bbdcd9f8a 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -508,7 +508,7 @@ struct xen_domctl_assign_device {
} u;
};
-/* Retrieve sibling devices infomation of machine_sbdf */
+/* Retrieve sibling devices information of machine_sbdf */
/* XEN_DOMCTL_get_device_group */
struct xen_domctl_get_device_group {
uint32_t machine_sbdf; /* IN */
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 02/18] tools/xentrace/xenalyze: Fix typos detected by lintian
Signed-off-by: Ian Jackson
---
tools/xentrace/xenalyze.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index 5ed0a12327..aa894673ad 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -9224,7 +9224,7 @@ void process_cpu_change(struct pcpu_info *p) {
/* File sanity check */
if(p->file_offset != p->next_cpu_change_offset) {
-fprintf(warn, "Strange, pcpu %d expected offet %llx, actual %llx!\n",
+fprintf(warn, "Strange, pcpu %d expected offset %llx, actual %llx!\n",
p->pid, (unsigned long long)p->next_cpu_change_offset,
(unsigned long long)p->file_offset);
}
@@ -9673,7 +9673,7 @@ ssize_t read_record(struct pcpu_info * p) {
}
/*
- * This funciton gets called for every record when doing dump. Try to
+ * This function gets called for every record when doing dump. Try to
* make it efficient by changing the minimum amount from the last
* call. Do this by:
* - Keeping track of the last pcpu called, so we can just set that to -
@@ -10629,7 +10629,7 @@ const struct argp_option cmd_opts[] = {
.key = OPT_SCATTERPLOT_EXTINT_CYCLES,
.arg = "vector",
.group = OPT_GROUP_EXTRA,
- .doc = "Output a scatterplot of vmexit cycles for external interrupts of
the given vector as a funciton of time.", },
+ .doc = "Output a scatterplot of vmexit cycles for external interrupts of
the given vector as a function of time.", },
{ .name = "scatterplot-unpin-promote",
.key = OPT_SCATTERPLOT_UNPIN_PROMOTE,
@@ -10756,7 +10756,7 @@ const struct argp_option cmd_opts[] = {
.key = OPT_MMIO_ENUMERATION_SKIP_VGA,
.arg = "[0|1]",
.group = OPT_GROUP_SUMMARY,
- .doc = "Control whether we enumerate MMIO accesses to the VGA area,
which can be extremly high during boot. Default: 0", },
+ .doc = "Control whether we enumerate MMIO accesses to the VGA area,
which can be extremely high during boot. Default: 0", },
{ .name = "sample-size",
.key = OPT_SAMPLE_SIZE,
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 00/18] Miscellaneous build and docs, fixes from Debian
Bastian Blank (1): tools/xenstat: Fix shared library version Ian Jackson (17): docs/man: Fix two typos detected by the Debian lintian tool tools/xentrace/xenalyze: Fix typos detected by lintian Various: Fix typos `unkown', `retreive' (detected by lintian) Various: Fix typo `occured' Various: Fix typo `reseting' tools/python/xen/lowlevel: Fix typo `sucess' Various: Fix typo `infomation' Various: Fix typo `mappping' tools/Rules.mk: Honour PREPEND_LDFLAGS_XEN_TOOLS INSTALL: Mention kconfig docs/man: Provide properly-formatted NAME sections docs/man/xen-pv-channel.pod.7: Remove a spurious blank line gdbsx: Honour LDFLAGS when linking libfsimage: Honour general LDFLAGS pygrub fsimage.so: Honour LDFLAGS when building xenmon: Install as xenmon, not xenmon.py tools/debugger/kdd: Install as `xen-kdd', not just `kdd' INSTALL| 20 docs/man/xen-pci-device-reservations.pod.7 | 4 docs/man/xen-pv-channel.pod.7 | 3 +-- docs/man/xen-tscmode.pod.7 | 4 docs/man/xen-vtpm.pod.7| 6 ++ docs/man/xen-vtpmmgr.pod.7 | 4 docs/man/xenstore.pod.1| 2 +- docs/man/xl-numa-placement.pod.7 | 2 +- docs/man/xl.pod.1.in | 2 +- tools/Rules.mk | 2 ++ tools/debugger/gdbsx/Makefile | 2 +- tools/debugger/kdd/Makefile| 4 ++-- tools/hotplug/Linux/block-drbd-probe | 2 +- tools/libfsimage/common/Makefile | 2 +- tools/libxc/xc_dom_elfloader.c | 2 +- tools/libxl/libxl_dm.c | 2 +- tools/libxl/libxl_event.h | 2 +- tools/libxl/libxl_internal.h | 2 +- tools/libxl/libxl_qmp.c| 2 +- tools/misc/xenlockprof.c | 2 +- tools/misc/xenperf.c | 2 +- tools/pygrub/Makefile | 2 +- tools/python/xen/lowlevel/xc/xc.c | 6 +++--- tools/xenmon/Makefile | 4 ++-- tools/xenstat/libxenstat/Makefile | 2 +- tools/xenstat/libxenstat/src/xenstat_qmp.c | 2 +- tools/xentrace/xenalyze.c | 8 tools/xl/xl_flask.c| 2 +- xen/arch/arm/arm64/lib/memcmp.S| 2 +- xen/arch/x86/hvm/hvm.c | 2 +- xen/arch/x86/hvm/svm/intr.c| 2 +- xen/common/sched_rt.c | 2 +- xen/drivers/acpi/apei/erst.c | 2 +- xen/drivers/passthrough/arm/smmu.c | 2 +- xen/drivers/passthrough/vtd/iommu.h| 2 +- xen/include/efi/efiprot.h | 2 +- xen/include/public/domctl.h| 2 +- xen/include/public/xen.h | 2 +- xen/include/xen/libfdt/libfdt.h| 2 +- xen/include/xen/sched.h| 2 +- 40 files changed, 81 insertions(+), 42 deletions(-) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 06/18] tools/python/xen/lowlevel: Fix typo `sucess'
Signed-off-by: Ian Jackson
---
tools/python/xen/lowlevel/xc/xc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/python/xen/lowlevel/xc/xc.c
b/tools/python/xen/lowlevel/xc/xc.c
index b137d5a839..6f5b8a6fa8 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -2178,7 +2178,7 @@ static PyMethodDef pyxc_methods[] = {
" xenstore_gmfn [int]: \n"
" console_domid [int]: \n"
" xenstore_domid [int]: \n"
- "Returns: None on sucess. Raises exception on error.\n" },
+ "Returns: None on success. Raises exception on error.\n" },
{ "hvm_get_param",
(PyCFunction)pyxc_hvm_param_get,
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 03/18] Various: Fix typos `unkown', `retreive' (detected by lintian)
Signed-off-by: Ian Jackson
---
tools/hotplug/Linux/block-drbd-probe | 2 +-
tools/libxc/xc_dom_elfloader.c | 2 +-
tools/libxl/libxl_dm.c | 2 +-
tools/libxl/libxl_event.h| 2 +-
tools/libxl/libxl_qmp.c | 2 +-
xen/include/xen/libfdt/libfdt.h | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/hotplug/Linux/block-drbd-probe
b/tools/hotplug/Linux/block-drbd-probe
index 635d9f9a52..7b2968b6d9 100755
--- a/tools/hotplug/Linux/block-drbd-probe
+++ b/tools/hotplug/Linux/block-drbd-probe
@@ -20,7 +20,7 @@
# Return value:
# 0: the device is drbd device
# 1: the device is not drbd device
-# 2: unkown error
+# 2: unknown error
# 3: the drbd device does not use protocol D
# 4: the drbd device is not ready
diff --git a/tools/libxc/xc_dom_elfloader.c b/tools/libxc/xc_dom_elfloader.c
index 26b2846365..82b5f2ee79 100644
--- a/tools/libxc/xc_dom_elfloader.c
+++ b/tools/libxc/xc_dom_elfloader.c
@@ -87,7 +87,7 @@ static char *xc_dom_guest_type(struct xc_dom_image *dom,
return "xen-3.0-x86_64";
default:
xc_dom_panic(dom->xch, XC_INVALID_KERNEL,
- "%s: unkown image type %"PRIu64,
+ "%s: unknown image type %"PRIu64,
__FUNCTION__, machine);
return NULL;
}
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index abd31ee6f2..26eb16af34 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -992,7 +992,7 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
/*
* Do not use any of the user-provided config files in sysconfdir,
- * avoiding unkown and uncontrolled configuration.
+ * avoiding unknown and uncontrolled configuration.
*/
flexarray_append(dm_args, "-no-user-config");
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 1ea789e231..d1517f7456 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -169,7 +169,7 @@ void libxl_event_register_callbacks(libxl_ctx *ctx,
*
* Applications should ensure that they eventually retrieve every
* event using libxl_event_check or libxl_event_wait, since events
- * which occur but are not retreived by the application will be queued
+ * which occur but are not retrieved by the application will be queued
* inside libxl indefinitely. libxl_event_check/_wait may be O(n)
* where n is the number of queued events which do not match the
* criteria specified in the arguments to check/wait.
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index bdf1778cf1..6a5c997546 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -238,7 +238,7 @@ static int qmp_register_vnc_callback(libxl__qmp_handler
*qmp,
port = libxl__json_object_get_string(obj);
if (!addr || !port) {
-LOGD(ERROR, qmp->domid, "Failed to retreive VNC connect information.");
+LOGD(ERROR, qmp->domid, "Failed to retrieve VNC connect information.");
goto out;
}
diff --git a/xen/include/xen/libfdt/libfdt.h b/xen/include/xen/libfdt/libfdt.h
index d6b94a1836..7c75688a39 100644
--- a/xen/include/xen/libfdt/libfdt.h
+++ b/xen/include/xen/libfdt/libfdt.h
@@ -594,7 +594,7 @@ const char *fdt_get_alias_namelen(const void *fdt,
const char *name, int namelen);
/**
- * fdt_get_alias - retreive the path referenced by a given alias
+ * fdt_get_alias - retrieve the path referenced by a given alias
* @fdt: pointer to the device tree blob
* @name: name of the alias th look up
*
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 04/18] Various: Fix typo `occured'
Signed-off-by: Ian Jackson
---
tools/xl/xl_flask.c| 2 +-
xen/arch/arm/arm64/lib/memcmp.S| 2 +-
xen/arch/x86/hvm/hvm.c | 2 +-
xen/arch/x86/hvm/svm/intr.c| 2 +-
xen/drivers/passthrough/arm/smmu.c | 2 +-
xen/include/efi/efiprot.h | 2 +-
xen/include/public/xen.h | 2 +-
xen/include/xen/sched.h| 2 +-
8 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/tools/xl/xl_flask.c b/tools/xl/xl_flask.c
index 523769750b..6b11f091cc 100644
--- a/tools/xl/xl_flask.c
+++ b/tools/xl/xl_flask.c
@@ -75,7 +75,7 @@ int main_setenforce(int argc, char **argv)
fprintf(stderr, "Flask XSM disabled\n");
}
else
-fprintf(stderr, "error occured while setting enforcing mode
(%i)\n", ret);
+fprintf(stderr, "error occurred while setting enforcing mode
(%i)\n", ret);
}
return ret;
diff --git a/xen/arch/arm/arm64/lib/memcmp.S b/xen/arch/arm/arm64/lib/memcmp.S
index 2eb81565ef..87c2537ffe 100644
--- a/xen/arch/arm/arm64/lib/memcmp.S
+++ b/xen/arch/arm/arm64/lib/memcmp.S
@@ -210,7 +210,7 @@ CPU_LE( lsr tmp2, tmp2, tmp1 )
.Lunequal_proc:
cbz diff, .Lremain8
-/*There is differnence occured in the latest comparison.*/
+/*There is differnence occurred in the latest comparison.*/
.Lnot_limit:
/*
* For little endian,reverse the low significant equal bits into MSB,then
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index fa994a36a4..6c1301df42 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1696,7 +1696,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long
gla,
case NESTEDHVM_PAGEFAULT_RETRY:
return 1;
case NESTEDHVM_PAGEFAULT_L1_ERROR:
-/* An error occured while translating gpa from
+/* An error occurred while translating gpa from
* l2 guest address to l1 guest address. */
return 0;
case NESTEDHVM_PAGEFAULT_INJECT:
diff --git a/xen/arch/x86/hvm/svm/intr.c b/xen/arch/x86/hvm/svm/intr.c
index ed5b100790..79673535d1 100644
--- a/xen/arch/x86/hvm/svm/intr.c
+++ b/xen/arch/x86/hvm/svm/intr.c
@@ -159,7 +159,7 @@ void svm_intr_assist(void)
int rc;
/* l2 guest was running when an interrupt for
- * the l1 guest occured.
+ * the l1 guest occurred.
*/
rc = nestedsvm_vcpu_interrupt(v, intack);
switch (rc) {
diff --git a/xen/drivers/passthrough/arm/smmu.c
b/xen/drivers/passthrough/arm/smmu.c
index 53e5823d05..b51039943c 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -2278,7 +2278,7 @@ MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
/*
* Xen: We don't have refcount for allocated memory so manually free memory
- * when an error occured.
+ * when an error occurred.
*/
static int arm_smmu_device_dt_probe(struct platform_device *pdev)
{
diff --git a/xen/include/efi/efiprot.h b/xen/include/efi/efiprot.h
index 05d3afb8d9..8cf04df437 100644
--- a/xen/include/efi/efiprot.h
+++ b/xen/include/efi/efiprot.h
@@ -691,7 +691,7 @@ typedef enum {
@retval EFI_SUCCESS The Blt operation completed.
@retval EFI_INVALID_PARAMETER BltOperation is not valid.
- @retval EFI_DEVICE_ERROR A hardware error occured writting to the video
buffer.
+ @retval EFI_DEVICE_ERROR A hardware error occurred writting to the
video buffer.
**/
typedef
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index fb1df8f293..68ee09810f 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -177,7 +177,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
#define VIRQ_XENOPROF 7 /* V. XenOprofile interrupt: new sample available */
#define VIRQ_CON_RING 8 /* G. (DOM0) Bytes received on console*/
#define VIRQ_PCPU_STATE 9 /* G. (DOM0) PCPU state changed */
-#define VIRQ_MEM_EVENT 10 /* G. (DOM0) A memory event has occured */
+#define VIRQ_MEM_EVENT 10 /* G. (DOM0) A memory event has occurred */
#define VIRQ_XC_RESERVED 11 /* G. Reserved for XenClient */
#define VIRQ_ENOMEM 12 /* G. (DOM0) Low on heap memory */
#define VIRQ_XENPMU 13 /* V. PMC interrupt */
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index a2334ddeff..c5540fa32f 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -615,7 +615,7 @@ void __domain_crash(struct domain *d);
/*
* Called from assembly code, with an optional address to help indicate why
- * the crash occured. If addr is 0, look up address from last extable
+ * the crash occurred. If addr is 0, look up address from last extable
* redirection.
*/
void noreturn asm_domain_crash_synchronous(unsigned long addr);
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.or
[Xen-devel] [PATCH 08/18] Various: Fix typo `mappping'
Signed-off-by: Ian Jackson
---
tools/python/xen/lowlevel/xc/xc.c | 2 +-
xen/drivers/passthrough/vtd/iommu.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/python/xen/lowlevel/xc/xc.c
b/tools/python/xen/lowlevel/xc/xc.c
index ebef92cd50..484b790c75 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -2385,7 +2385,7 @@ static PyMethodDef pyxc_methods[] = {
{ "domain_set_memmap_limit",
(PyCFunction)pyxc_domain_set_memmap_limit,
METH_VARARGS, "\n"
- "Set a domain's physical memory mappping limit\n"
+ "Set a domain's physical memory mapping limit\n"
" dom [int]: Identifier of domain.\n"
" map_limitkb [int]: .\n"
"Returns: [int] 0 on success; -1 on error.\n" },
diff --git a/xen/drivers/passthrough/vtd/iommu.h
b/xen/drivers/passthrough/vtd/iommu.h
index 47bdfcb5ea..1a992f72d6 100644
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -513,7 +513,7 @@ struct qi_ctrl {
struct ir_ctrl {
u64 iremap_maddr;/* interrupt remap table machine address */
int iremap_num; /* total num of used interrupt remap entry */
-spinlock_t iremap_lock; /* lock for irq remappping table */
+spinlock_t iremap_lock; /* lock for irq remapping table */
};
struct iommu_flush {
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86/svm: Fix svm_update_guest_efer() for domains using shadow paging
When using shadow paging, EFER.NX is a Xen controlled bit, and is required by
the shadow pagefault handler to distinguish instruction fetches from data
accesses.
This can be observed by a guest which has NX and SMEP clear but SMAP active by
attempting to execute code on a user mapping. The first attempt to build the
target shadow will #PF so is handled by the shadow code, but when walking the
the guest pagetables, the lack of PFEC_insn_fetch being signalled causes the
shadow code to mistake the instruction fetch for a data fetch, and believe
that it is a real guest fault. As a result, the guest receives #PF[-d-srP]
for an action which should complete successfully.
The suspicious-looking gymnastics with LME is actually a subtle corner case
with shadow paging. When dropping out of Long Mode, a guests choice of LME
and Xen's choice of CR0.PG cause hardware to operate in Long Mode, but the
shadow code to operate in 2-on-3 mode.
In addition to describing this corner case in the SVM side, extend the comment
for the same fix on the VT-x side. (I have a suspicion that I've just worked
out why VT-x doesn't tolerate LMA != LME when Unrestricted Guest is clear.)
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Tim Deegan
CC: Boris Ostrovsky
CC: Suravee Suthikulpanit
CC: Brian Woods
CC: Jun Nakajima
CC: Kevin Tian
Unlike the VT-x side, there is no point playing with the conditional intercept
of EFER reads. The SVME requirement means that only L1 hypervisors would
benefit from accelerated reads.
---
xen/arch/x86/hvm/svm/svm.c | 31 +--
xen/arch/x86/hvm/vmx/vmx.c | 6 ++
2 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index c98cfc2..2ab2c54 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -649,13 +649,32 @@ void svm_update_guest_cr(struct vcpu *v, unsigned int cr,
unsigned int flags)
static void svm_update_guest_efer(struct vcpu *v)
{
struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
-bool lma = v->arch.hvm.guest_efer & EFER_LMA;
-uint64_t new_efer;
+unsigned long guest_efer = v->arch.hvm.guest_efer,
+xen_efer = read_efer();
-new_efer = (v->arch.hvm.guest_efer | EFER_SVME) & ~EFER_LME;
-if ( lma )
-new_efer |= EFER_LME;
-vmcb_set_efer(vmcb, new_efer);
+if ( paging_mode_shadow(v->domain) )
+{
+/* EFER.NX is a Xen-owned bit and is not under guest control. */
+guest_efer &= ~EFER_NX;
+guest_efer |= xen_efer & EFER_NX;
+
+/*
+ * CR0.PG is a Xen-owned bit, and remains set even when the guest has
+ * logically disabled paging.
+ *
+ * LMA was calculated using the guest CR0.PG setting, but LME needs
+ * clearing to avoid interacting with Xen's CR0.PG setting. As writes
+ * to CR0 are intercepted, it is safe to leave LME clear at this
+ * point, and fix up both LME and LMA when CR0.PG is set.
+ */
+if ( !(guest_efer & EFER_LMA) )
+guest_efer &= ~EFER_LME;
+}
+
+/* SVME must remain set in non-root mode. */
+guest_efer |= EFER_SVME;
+
+vmcb_set_efer(vmcb, guest_efer);
ASSERT(nestedhvm_enabled(v->domain) ||
!(v->arch.hvm.guest_efer & EFER_SVME));
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index bf90e22..eea6330 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1666,6 +1666,12 @@ static void vmx_update_guest_efer(struct vcpu *v)
* not tolerate the LME and LMA settings being different. As writes
* to CR0 are intercepted, it is safe to leave LME clear at this
* point, and fix up both LME and LMA when CR0.PG is set.
+ *
+ * Furthermore, when using shadow pagetables (subsumed by the
+ * Unrestricted Guest check), CR0.PG is a Xen-owned bit, and remains
+ * set even when the guest has logically disabled paging. LMA was
+ * calculated using the guest CR0.PG setting, but LME needs clearing
+ * to avoid interacting with Xen's CR0.PG setting.
*/
if ( !(guest_efer & EFER_LMA) )
guest_efer &= ~EFER_LME;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/5] tools/dm_restrict: Ask QEMU to chroot
When dm_restrict is enabled, ask QEMU to chroot into an empty directory.
* Create /var/run/qemu/root-domid (deleting the old one if it's there)
* Pass the -chroot option to QEMU
Rather than running `rm -rf` on the directory before creating it
(since there is no library function to do this), simply rmdir the
directory, relying on the fact that the previous QEMU instance, if
properly restricted, shouldn't have been able to write anything
anyway.
Suggested-by: Ross Lagerwall
Signed-off-by: George Dunlap
---
Changes since v2:
- Style fixes
- Testing moved to a different patch
CC: Ian Jackson
CC: Wei Liu
CC: Anthony Perard
---
docs/designs/qemu-deprivilege.md | 12 +-
tools/libxl/libxl_dm.c | 41 +++-
2 files changed, 46 insertions(+), 7 deletions(-)
diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-deprivilege.md
index d3c6495030..6dc3c6d149 100644
--- a/docs/designs/qemu-deprivilege.md
+++ b/docs/designs/qemu-deprivilege.md
@@ -61,12 +61,6 @@ source tree.)
'''Testing status''': Tested
-# Restrictions / improvements still to do
-
-This lists potential restrictions still to do. It is meant to be
-listed in order of ease of implementation, with low-hanging fruit
-first.
-
## Chroot
'''Description''': Qemu runs in its own chroot, such that even if it
@@ -84,6 +78,12 @@ Then adds the following to the qemu command-line:
'''Tested''': Not tested
+## Restrictions / improvements still to do
+
+This lists potential restrictions still to do. It is meant to be
+listed in order of ease of implementation, with low-hanging fruit
+first.
+
## Namespaces for unused functionality (Linux only)
'''Description''': QEMU doesn't use the functionality associated with
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index abd31ee6f2..385643b52c 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1410,9 +1410,48 @@ static int libxl__build_device_model_args_new(libxl__gc
*gc,
}
}
-if (libxl_defbool_val(b_info->dm_restrict))
+if (libxl_defbool_val(b_info->dm_restrict)) {
+char *chroot_dir = GCSPRINTF("%s/qemu-root-%d",
+ libxl__run_dir_path(), guest_domid);
+int r;
+
flexarray_append(dm_args, "-xen-domid-restrict");
+/*
+ * Run QEMU in a chroot at XEN_RUN_DIR/qemu-root-%d
+ *
+ * There is no library function to do the equivalent of `rm
+ * -rf`. However deprivileged QEMU in theory shouldn't be
+ * able to write any files, as the chroot would be owned by
+ * root, but it would be running as an unprivileged process.
+ * So in theory, old chroots should always be empty.
+ *
+ * rmdir the directory before attempting to create
+ * it; if it returns anything other than ENOENT, fail domain
+ * creation.
+ */
+r = rmdir(chroot_dir);
+if (r != 0 && errno != ENOENT) {
+LOGED(ERROR, guest_domid,
+ "failed to remove existing chroot dir %s", chroot_dir);
+return ERROR_FAIL;
+}
+
+for (;;) {
+r = mkdir(chroot_dir, );
+if (!r)
+break;
+if (errno == EINTR) continue;
+LOGED(ERROR, guest_domid,
+ "failed to create chroot dir %s", chroot_dir);
+return ERROR_FAIL;
+}
+
+/* Add "-chroot [dir]" to command-line */
+flexarray_append(dm_args, "-chroot");
+flexarray_append(dm_args, chroot_dir);
+}
+
if (state->saved_state) {
/* This file descriptor is meant to be used by QEMU */
*dm_state_fd = open(state->saved_state, O_RDONLY);
--
2.19.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 5/5] RFC: test/depriv: Add a tool to check process-level depriv
Add a tool to check whether the various process-level deprivileging
operations have actually taken place on the process.
The tool takes a domname or domid, and returns success or failure.
Signed-off-by: George Dunlap
---
Changes since v2:
- Make grep for Uid line more strict
- Fix Gid grep, make more strict
- Match strictly more than one space
- Look up the group ID for `nobody` rather than hard-coding it
- Move tests from other patches into one patch
- Remove suffix (in case we change the language)
- Install in the path
NB that a number of other requested changes (such as using `set -e`,
changing the output, &c) have not been made, while I consider whether
to leave this as a stand-alone script, or whether to merge osstest's
fd checker functionality into it (perhaps changing the language to perl
at the same time).
CC: Ian Jackson
CC: Wei Liu
CC: Stefano Stabellini
CC: Anthony Perard
CC: Ross Lagerwall
---
tools/tests/depriv/Makefile | 2 +-
tools/tests/depriv/depriv-process-checker | 146 ++
2 files changed, 147 insertions(+), 1 deletion(-)
create mode 100755 tools/tests/depriv/depriv-process-checker
diff --git a/tools/tests/depriv/Makefile b/tools/tests/depriv/Makefile
index 3cba28da25..1b3d09e97d 100644
--- a/tools/tests/depriv/Makefile
+++ b/tools/tests/depriv/Makefile
@@ -23,7 +23,7 @@ LDLIBS += $(LDLIBS_libxendevicemodel)
LDLIBS += $(LDLIBS_libxentoolcore)
LDLIBS += $(LDLIBS_libxentoollog)
-INSTALL_PRIVBIN-y += depriv-fd-checker
+INSTALL_PRIVBIN-y += depriv-fd-checker depriv-process-checker
INSTALL_PRIVBIN := $(INSTALL_PRIVBIN-y)
TARGETS += $(INSTALL_PRIVBIN)
diff --git a/tools/tests/depriv/depriv-process-checker
b/tools/tests/depriv/depriv-process-checker
new file mode 100755
index 00..18a3c9b45c
--- /dev/null
+++ b/tools/tests/depriv/depriv-process-checker
@@ -0,0 +1,146 @@
+#!/bin/bash
+
+domain="$1"
+
+if [[ "$domain" =~ ^[0-9]+$ ]] ; then
+domid="$domain"
+else
+domid=$(xl domid "$domain")
+fi
+
+dmpid=$(xenstore-read /local/domain/$domid/image/device-model-pid 2>/dev/null)
+if [[ -z "$dmpid" ]] ; then
+echo "xenstore-read failed"
+exit 1
+fi
+
+failed="false"
+
+# TEST: Process / group id
+#
+# Read /proc//status, checking Uid and Gid lines
+#
+# Uid should be xen-qemuuser-range-base+$domid
+# Gid should be 65534 ("nobody")
+# FIXME: deal with other UID configurations?
+echo -n "Process UID: "
+tgt_uid=$(id -u xen-qemuuser-range-base)
+tgt_uid=$(( $tgt_uid + $domid ))
+
+# Example input:
+# Uid: 1193119311931193
+input=$(grep ^Uid: /proc/$dmpid/status)
+if [[ "$input" =~
^Uid:[[:space:]]+([0-9]+)[[:space:]]+([0-9]+)[[:space:]]+([0-9]+)[[:space:]]+([0-9]+)$
]] ; then
+result="PASSED"
+for i in {1..4}; do
+ if [[ "${BASH_REMATCH[$i]}" != "$tgt_uid" ]] ; then
+ result="FAILED"
+ failed="true"
+ break
+ fi
+done
+else
+result="FAILED"
+failed="true"
+fi
+echo $result
+
+# Example input:
+# Gid: 10020 10020 10020 10020
+echo -n "Process GID: "
+tgt_gid=$(id -g nobody)
+input=$(grep ^Gid: /proc/$dmpid/status)
+if [[ "$input" =~
^Gid:[[:space:]]+([0-9]+)[[:space:]]+([0-9]+)[[:space:]]+([0-9]+)[[:space:]]+([0-9]+)$
]] ; then
+result="PASSED"
+for i in {1..4}; do
+ if [[ "${BASH_REMATCH[$i]}" != "$tgt_gid" ]] ; then
+ result="FAILED"
+ failed="true"
+ break
+ fi
+done
+else
+result="FAILED"
+failed="true"
+fi
+echo $result
+
+# TEST: chroot
+#
+# Read /proc//root to see if it's correct.
+echo -n "Chroot: "
+if [[ -n "$XEN_RUN_DIR" ]] ; then
+tgt_chroot=$XEN_RUN_DIR/qemu-root-$domid
+root=$(readlink /proc/$dmpid/root)
+if [[ "$root" != "$tgt_chroot" ]] ; then
+ echo "FAILED"
+ failed="true"
+else
+ echo "PASSED"
+fi
+else
+echo "FAILED (XEN_RUN_DIR undefined)"
+failed="true"
+fi
+
+# TEST: Namespace unsharing
+#
+# Read /proc//ns/ and make sure it's not equal to
+# the current processes' value
+for nsname in ipc mnt; do
+echo -n "Unshare namespace $nsname: "
+dmns=$(readlink /proc/$dmpid/ns/$nsname)
+myns=$(readlink /proc/self/ns/$nsname)
+
+if [[ "$dmns" == "$myns" ]] ; then
+ echo "FAILED"
+ failed="true"
+else
+ echo "PASSED"
+fi
+done
+
+# TEST: RLIMITs
+#
+# Read /proc//limits
+function check_rlimit() {
+limit_name=$1
+limit_string=$2
+tgt=$3
+
+echo -n "rlimit $limit_name: "
+input=$(grep "^$limit_string" /proc/$dmpid/limits)
+
+if [[ -z "$input" ]] ; then
+ echo "Couldn't find limit $limit"
+ echo FAILED
+ failed="true"
+ return
+fi
+
+if [[ "$input" =~
^$limit_string[[:space:]]*([^[:space:]]+)[[:space:]]*([^[:space:]]+)[[:space:]]*[^[:space:]]+
]] ; then
+ if [[ "${BASH_REMATCH[1]}" != $tgt ||
+ "${BASH_REMATCH[2]}" != $tgt ]] ; then
+ echo "FAILED"
+ failed="true"
+ else
+
[Xen-devel] [PATCH 3/5] tools/dm_restrict: Unshare mount and IPC namespaces on Linux
QEMU running under Xen doesn't need mount or IPC functionality.
Create and enter separate namespaces for each of these before
executing QEMU, so that in the event that other restrictions fail, the
process won't be able to even name system mount points or exsting
non-file-based IPC descriptors to attempt to attack them.
Unsharing is something a process can only do to itself (it would
seem); so add an os-specific "dm_preexec_restrict()" hook just before
we exec() the device model.
Also add checks to depriv-process-checker.sh to verify that dm is
running in a new namespace (or at least, a different one than the
caller).
Suggested-by: Ross Lagerwall
Signed-off-by: George Dunlap
---
Changes in v2:
- Return an error rather than calling exit()
- Use LOGE() and print to the current stderr fd, rather than
printing to the new stderr fd via write()
- Use r for external return values rather than rc.
CC: Ian Jackson
CC: Wei Liu
CC: Anthony Perard
---
docs/designs/qemu-deprivilege.md | 12 ++--
tools/libxl/libxl_dm.c | 6 ++
tools/libxl/libxl_freebsd.c | 5 +
tools/libxl/libxl_internal.h | 5 +
tools/libxl/libxl_linux.c| 14 ++
tools/libxl/libxl_netbsd.c | 5 +
6 files changed, 41 insertions(+), 6 deletions(-)
diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-deprivilege.md
index 6dc3c6d149..e1c9763a71 100644
--- a/docs/designs/qemu-deprivilege.md
+++ b/docs/designs/qemu-deprivilege.md
@@ -78,12 +78,6 @@ Then adds the following to the qemu command-line:
'''Tested''': Not tested
-## Restrictions / improvements still to do
-
-This lists potential restrictions still to do. It is meant to be
-listed in order of ease of implementation, with low-hanging fruit
-first.
-
## Namespaces for unused functionality (Linux only)
'''Description''': QEMU doesn't use the functionality associated with
@@ -111,6 +105,12 @@ call:
[qemu-namespaces]:
https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg04723.html
+# Restrictions / improvements still to do
+
+This lists potential restrictions still to do. It is meant to be
+listed in order of ease of implementation, with low-hanging fruit
+first.
+
### Basic RLIMITs
'''Description''': A number of limits on the resources that a given
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 385643b52c..702ea75149 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2393,6 +2393,12 @@ retry_transaction:
goto out_close;
if (!rc) { /* inner child */
setsid();
+if (libxl_defbool_val(b_info->dm_restrict))
+{
+rc = libxl__local_dm_preexec_restrict(gc);
+if (rc != 0)
+_exit(-1);
+}
libxl__exec(gc, null, logfile_w, logfile_w, dm, args, envs);
}
diff --git a/tools/libxl/libxl_freebsd.c b/tools/libxl/libxl_freebsd.c
index 6442ccec72..f7ef4a8910 100644
--- a/tools/libxl/libxl_freebsd.c
+++ b/tools/libxl/libxl_freebsd.c
@@ -245,3 +245,8 @@ int libxl__pci_topology_init(libxl__gc *gc,
{
return ERROR_NI;
}
+
+int libxl__local_dm_preexec_restrict(libxl__gc *gc)
+{
+return 0;
+}
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 802382c704..df85ddff27 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3782,6 +3782,11 @@ struct libxl__dm_spawn_state {
_hidden void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state*);
+/*
+ * Called after forking but before executing the local devicemodel.
+ */
+_hidden int libxl__local_dm_preexec_restrict(libxl__gc *gc);
+
/* Stubdom device models. */
typedef struct {
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 6ef0abc693..34af2e0d90 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -307,6 +307,20 @@ int libxl__pci_topology_init(libxl__gc *gc,
return err;
}
+int libxl__local_dm_preexec_restrict(libxl__gc *gc)
+{
+int r;
+
+/* Unshare mount and IPC namespaces. These are unused by QEMU. */
+r = unshare(CLONE_NEWNS | CLONE_NEWIPC);
+if (r < 0) {
+LOGE(ERROR, "libxl: Mount and IPC namespace unfailed");
+return ERROR_FAIL;
+}
+
+return 0;
+}
+
/*
* Local variables:
* mode: C
diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
index 2edfb00641..dce3f1fdce 100644
--- a/tools/libxl/libxl_netbsd.c
+++ b/tools/libxl/libxl_netbsd.c
@@ -124,3 +124,8 @@ int libxl__pci_topology_init(libxl__gc *gc,
{
return ERROR_NI;
}
+
+void libxl__local_dm_preexec_restrict(libxl__gc *gc, int stderrfd)
+{
+return;
+}
--
2.19.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4/5] tools/dm_depriv: Add first cut RLIMITs
Limit the ability of a potentially compromised QEMU to consume system
resources. Key limits:
- RLIMIT_FSIZE (file size): 256KiB
- RLIMIT_NPROC (after uid changes to a unique uid)
Probably unnecessary limits but why not:
- RLIMIT_CORE: 0
- RLIMIT_MSGQUEUE: 0
- RLIMIT_LOCKS: 0
- RLIMIT_MEMLOCK: 0
NB that we do not yet set RLIMIT_AS (total virtual memory) or
RLIMIT_NOFILES (number of open files), since these require more care
and/or more coordination with QEMU to implement.
Suggested-by: Ross Lagerwall
Signed-off-by: George Dunlap
---
Changes since v2:
- Use a macro to define rlimit entries
- Use RLIMIT_NLIMITS as an end-of-list marker, rather than -1
- Various style clean-ups
CC: Ian Jackson
CC: Wei Liu
CC: Anthony Perard
---
docs/designs/qemu-deprivilege.md | 12 +-
tools/libxl/libxl_linux.c| 39
2 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-deprivilege.md
index e1c9763a71..9028e68460 100644
--- a/docs/designs/qemu-deprivilege.md
+++ b/docs/designs/qemu-deprivilege.md
@@ -105,12 +105,6 @@ call:
[qemu-namespaces]:
https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg04723.html
-# Restrictions / improvements still to do
-
-This lists potential restrictions still to do. It is meant to be
-listed in order of ease of implementation, with low-hanging fruit
-first.
-
### Basic RLIMITs
'''Description''': A number of limits on the resources that a given
@@ -137,6 +131,12 @@ are specified; this does not apply to QEMU running as a
Xen DM.
'''Tested''': Not tested
+# Restrictions / improvements still to do
+
+This lists potential restrictions still to do. It is meant to be
+listed in order of ease of implementation, with low-hanging fruit
+first.
+
### Further RLIMITs
RLIMIT_AS limits the total amount of memory; but this includes the
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 34af2e0d90..bd28f9271b 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -16,6 +16,7 @@
#include "libxl_osdeps.h" /* must come before any other headers */
#include "libxl_internal.h"
+#include
int libxl__try_phy_backend(mode_t st_mode)
{
@@ -307,9 +308,31 @@ int libxl__pci_topology_init(libxl__gc *gc,
return err;
}
+static struct {
+int resource;
+rlim_t limit;
+} rlimits[] = {
+#define RLIMIT_ENTRY(r, l) \
+{ .resource = r, .limit = l }
+/* Big enough for log files, not big enough for a DoS */
+RLIMIT_ENTRY(RLIMIT_FSIZE, 256*1024),
+
+/* Shouldn't need any of these */
+RLIMIT_ENTRY(RLIMIT_NPROC, 0),
+RLIMIT_ENTRY(RLIMIT_CORE, 0),
+RLIMIT_ENTRY(RLIMIT_MSGQUEUE, 0),
+RLIMIT_ENTRY(RLIMIT_LOCKS, 0),
+RLIMIT_ENTRY(RLIMIT_MEMLOCK, 0),
+
+/* End-of-list marker */
+RLIMIT_ENTRY(RLIMIT_NLIMITS, 0),
+};
+#undef RLIMIT_ENTRY
+
int libxl__local_dm_preexec_restrict(libxl__gc *gc)
{
int r;
+unsigned i;
/* Unshare mount and IPC namespaces. These are unused by QEMU. */
r = unshare(CLONE_NEWNS | CLONE_NEWIPC);
@@ -318,6 +341,22 @@ int libxl__local_dm_preexec_restrict(libxl__gc *gc)
return ERROR_FAIL;
}
+/* Set various "easy" rlimits */
+for (i = 0; rlimits[i].resource != RLIMIT_NLIMITS; i++) {
+struct rlimit rlim;
+
+rlim.rlim_cur = rlim.rlim_max = rlimits[i].limit;
+
+r = setrlimit(rlimits[i].resource, &rlim);
+if (r < 0) {
+LOGE(ERROR, "Setting rlimit %d to %lld failed\n",
+ rlimits[i].resource,
+ (unsigned long long)rlimits[i].limit);
+return ERROR_FAIL;
+}
+
+}
+
return 0;
}
--
2.19.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/5] docs/qemu-deprivilege: Revise and update with status and future plans
docs/qemu-deprivilege.txt had some basic instructions for using dm_restrict, but it was incomplete, misleading, and stale. Update the docs in a number of ways. First, separate user-facing documentation and technical description into docs/features and docs/design, respectively. In the feature doc: * Introduce a section mentioning minimim versions of Linux, Xen, and qemu required (TBD) * Fix the discussion of qemu userid. Mention xen-qemuuser-range-base, and provide example shell code that actually has some hope of working (instead of failing out after creating 900 userids). * Describe how to enable restrictions, as well as features which probably don't or definitely don't work. In the design doc, introduce a "Technical Details" section which describes specifically what restrictions are currently done, and also what restrictions we are looking at doing in the future. The idea here is that as we implement the various items for the future, we move them from "Restrictions still to do" to "Restrictions done". This can also act as a design document -- a place for public discussion of what can or should be done and how. Also add an entry to SUPPORT.md. Signed-off-by: George Dunlap --- Changes since v2: - Extraneous privcmd / evtchn instances aren't closed - Expand description of how to test fd deprivileging - Rework and clarify two namespace sections, give reference for QEMU NAK - Add more information about migration technical challenges - In UID section, mention possibility of container ID collisions. - Fix name of design document. - Add SUPPORT.md statement. Specify Linux, to make sure that FreeBSD is evaluated separately. - Mention that `-sandbox` is a blacklist and why Changes since v1: - Break into two, and move into appropriate directories (rather than 'misc') - Updated version requirements - Distinguish between features which "don't yet work" and features which we never expect to work - Update description of xen-restrict functionality - Reorder and expand further restrictions - Make it more clear which restrictions are available on Linux only - Include detailed description of how to kill a process - Add RLIMIT_NPROC as something we can do without further changes to qemu - Document the need to check for the sandbox feature before using it Thank you to Ross Lagerwall, whose description of what XenServer is doing formed much of the basis for the text here. CC: Ian Jackson CC: Wei Liu CC: Andrew Cooper CC: Jan Beulich CC: Tim Deegan CC: Konrad Wilk CC: Stefano Stabellini CC: Julien Grall CC: Anthony Perard CC: Ross Lagerwall --- SUPPORT.md| 20 ++ docs/designs/qemu-deprivilege.md | 322 ++ docs/features/qemu-deprivilege.pandoc | 94 docs/misc/qemu-deprivilege.txt| 36 --- 4 files changed, 436 insertions(+), 36 deletions(-) create mode 100644 docs/designs/qemu-deprivilege.md create mode 100644 docs/features/qemu-deprivilege.pandoc delete mode 100644 docs/misc/qemu-deprivilege.txt diff --git a/SUPPORT.md b/SUPPORT.md index 3727446b83..b5e7e44fb3 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -525,6 +525,26 @@ Vulnerabilities of a device model stub domain to a hostile driver domain (either compromised or untrusted) are excluded from security support. +### Device Model Deprivileging + +Status, Linux: Tech Preview, with limited support + +This means adding extra restrictions to a device model running in +domain 0 in order to prevent a compromised device model to attack the +rest of the system. + +"Tech preview with limited support" means we will not issue XSAs for +the _additional_ functionality provided by the feature; but we will +issue XSAs in the event that enabling this feature opens up a security +hole that would not be present without the feature disabled. + +For example, while this is classified as tech preview, a bug in libxl +which failed to change the user ID of QEMU would not receive an XSA, +since without this feature the user ID wouldn't be changed. But a +change which made it possible for a compromised guest to read +arbitrary files on the host filesystem without compromising QEMU would +be issued an XSA, since that does weaken security. + ### KCONFIG Expert Status: Experimental diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-deprivilege.md new file mode 100644 index 00..d3c6495030 --- /dev/null +++ b/docs/designs/qemu-deprivilege.md @@ -0,0 +1,322 @@ +# Introduction + +The goal of deprilvileging qemu is this: Even if there is a bug (for +example in qemu) which permits a domain to gain control of the device +model, the compromised device model process is prevented from +violating the system's overall security properties. Ie, a guest +cannot "escape" from the virtualisation by using a qemu bug. + +This document lists the various technical measures which we either +have taken, or plan to take to effect this goal. Some of them are +required to be conside
[Xen-devel] [PATCH v2] flask: sort io{port,mem}con entries
These entries are not always sorted by checkpolicy, so sort them during
policy load (as is already done for later ocontext additions).
Reported-by: Nicolas Poirot
Signed-off-by: Daniel De Graaf
---
xen/xsm/flask/ss/policydb.c | 35 +--
1 file changed, 29 insertions(+), 6 deletions(-)
diff --git a/xen/xsm/flask/ss/policydb.c b/xen/xsm/flask/ss/policydb.c
index 3a12d96ef9..9426164353 100644
--- a/xen/xsm/flask/ss/policydb.c
+++ b/xen/xsm/flask/ss/policydb.c
@@ -1737,7 +1737,7 @@ int policydb_read(struct policydb *p, void *fp)
{
struct role_allow *ra, *lra;
struct role_trans *tr, *ltr;
-struct ocontext *l, *c /*, *newc*/;
+struct ocontext *l, *c, **pn;
int i, j, rc;
__le32 buf[8];
u32 len, /*len2,*/ config, nprim, nel /*, nel2*/;
@@ -1994,6 +1994,7 @@ int policydb_read(struct policydb *p, void *fp)
if ( rc < 0 )
goto bad;
nel = le32_to_cpu(buf[0]);
+pn = &p->ocontexts[i];
l = NULL;
for ( j = 0; j < nel; j++ )
{
@@ -2003,11 +2004,6 @@ int policydb_read(struct policydb *p, void *fp)
rc = -ENOMEM;
goto bad;
}
-if ( l )
-l->next = c;
-else
-p->ocontexts[i] = c;
-l = c;
rc = -EINVAL;
switch ( i )
{
@@ -2050,6 +2046,18 @@ int policydb_read(struct policydb *p, void *fp)
rc = context_read_and_validate(&c->context, p, fp);
if ( rc )
goto bad;
+
+if ( *pn || ( l && l->u.ioport.high_ioport >=
c->u.ioport.low_ioport ) )
+{
+pn = &p->ocontexts[i];
+l = *pn;
+while ( l && l->u.ioport.high_ioport <
c->u.ioport.low_ioport ) {
+pn = &l->next;
+l = *pn;
+}
+c->next = l;
+}
+l = c;
break;
case OCON_IOMEM:
if ( p->target_type != TARGET_XEN )
@@ -2078,6 +2086,18 @@ int policydb_read(struct policydb *p, void *fp)
rc = context_read_and_validate(&c->context, p, fp);
if ( rc )
goto bad;
+
+if ( *pn || ( l && l->u.iomem.high_iomem >=
c->u.iomem.low_iomem ) )
+{
+pn = &p->ocontexts[i];
+l = *pn;
+while ( l && l->u.iomem.high_iomem < c->u.iomem.low_iomem
) {
+pn = &l->next;
+l = *pn;
+}
+c->next = l;
+}
+l = c;
break;
case OCON_DEVICE:
if ( p->target_type != TARGET_XEN )
@@ -2123,6 +2143,9 @@ int policydb_read(struct policydb *p, void *fp)
rc = -EINVAL;
goto bad;
}
+
+*pn = c;
+pn = &c->next;
}
}
--
2.14.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v14 8/9] mm / iommu: include need_iommu() test in iommu_use_hap_pt()
> -Original Message- > From: Wei Liu [mailto:wei.l...@citrix.com] > Sent: 05 October 2018 17:04 > To: Paul Durrant > Cc: xen-devel@lists.xenproject.org; Stefano Stabellini > ; Jun Nakajima ; George > Dunlap ; Andrew Cooper > ; Jan Beulich ; Wei Liu > > Subject: Re: [Xen-devel] [PATCH v14 8/9] mm / iommu: include need_iommu() > test in iommu_use_hap_pt() > > This patch has broken my PVH Dom0 setup. Hmm. This is probably a bug in the need_iommu() setting for dom0. Do you still see the problem with the subsequent patch " mm / iommu: split need_iommu() into has_iommu_pt()..." applied too? Paul > > [2.515159] igb :02:00.1: added PHC on eth1 > [2.519539] igb :02:00.1: Intel(R) Gigabit Ethernet Network > Connection > [2.526469] igb :02:00.1: eth1: (PCIe:5.0Gb/s:Width x4) > 0c:c4:7a:e7:b6:53 > [2.533733] igb :02:00.1: eth1: PBA No: 010A00-000 > [2.538860] igb :02:00.1: Using MSI-X interrupts. 8 rx queue(s), 8 > tx queue(s) > [2.649191] ata8: SATA link down (SStatus 0 SControl 300) > [2.654467] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > [2.660730] ata7: SATA link down (SStatus 0 SControl 300) > [2.666166] ata5: SATA link down (SStatus 0 SControl 300) > [2.671619] ata3: SATA link down (SStatus 0 SControl 300) > [2.677073] ata6: SATA link down (SStatus 0 SControl 300) > [2.682538] ata2: SATA link down (SStatus 0 SControl 300) > [2.687988] ata4: SATA link down (SStatus 0 SControl 300) > [2.694632] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x100) > [8.215728] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > [8.222945] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x100) > [8.229052] ata1: limiting SATA link speed to 1.5 Gbps > [ 13.590991] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) > [ 13.597142] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x100) > > Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v14 8/9] mm / iommu: include need_iommu() test in iommu_use_hap_pt()
This patch has broken my PVH Dom0 setup. [2.515159] igb :02:00.1: added PHC on eth1 [2.519539] igb :02:00.1: Intel(R) Gigabit Ethernet Network Connection [2.526469] igb :02:00.1: eth1: (PCIe:5.0Gb/s:Width x4) 0c:c4:7a:e7:b6:53 [2.533733] igb :02:00.1: eth1: PBA No: 010A00-000 [2.538860] igb :02:00.1: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s) [2.649191] ata8: SATA link down (SStatus 0 SControl 300) [2.654467] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [2.660730] ata7: SATA link down (SStatus 0 SControl 300) [2.666166] ata5: SATA link down (SStatus 0 SControl 300) [2.671619] ata3: SATA link down (SStatus 0 SControl 300) [2.677073] ata6: SATA link down (SStatus 0 SControl 300) [2.682538] ata2: SATA link down (SStatus 0 SControl 300) [2.687988] ata4: SATA link down (SStatus 0 SControl 300) [2.694632] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x100) [8.215728] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [8.222945] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x100) [8.229052] ata1: limiting SATA link speed to 1.5 Gbps [ 13.590991] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 13.597142] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x100) Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 128422: tolerable all pass - PUSHED
flight 128422 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/128422/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen cc6e309c6e4368a1094b5e7593cf8cf5803ed709 baseline version: xen d36b7704586c232388da8b170a111cc98127cdad Last test of basis 128415 2018-10-05 10:00:38 Z0 days Testing same since 128422 2018-10-05 13:06:06 Z0 days1 attempts People who touched revisions under test: Andrew Cooper jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git d36b770458..cc6e309c6e cc6e309c6e4368a1094b5e7593cf8cf5803ed709 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v14 9/9] mm / iommu: split need_iommu() into has_iommu_pt() and need_iommu_pt_sync()
> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 05 October 2018 15:51 > To: Paul Durrant > Cc: Brian Woods ; Suravee Suthikulpanit > ; Julien Grall ; > Andrew Cooper ; Wei Liu ; > George Dunlap ; Ian Jackson > ; Jun Nakajima ; Kevin > Tian ; Stefano Stabellini ; > xen-devel ; Konrad Rzeszutek Wilk > ; Tamas K Lengyel ; Tim > (Xen.org) > Subject: Re: [PATCH v14 9/9] mm / iommu: split need_iommu() into > has_iommu_pt() and need_iommu_pt_sync() > > >>> On 04.10.18 at 12:45, wrote: > > The name 'need_iommu()' is a little confusing as it suggests a domain > needs > > to use the IOMMU but something might not be set up yet, when in fact it > > represents a tri-state value (not a boolean as might be expected) where > > -1 means 'IOMMU mappings being set up' and 1 means 'IOMMU mappings have > > been fully set up'. > > > > Two different meanings are also inferred from the macro it in various > > places in the code: > > > > - Some callers want to test whether a domain has IOMMU mappings at all > > - Some callers want to test whether they need to synchronize the > domain's > > P2M and IOMMU mappings > > > > This patch replaces the 'need_iommu' tri-state value with a defined > > enumeration and adds a boolean flag 'need_sync' to separate these > meanings, > > and places both of these in struct domain_iommu, rather than directly in > > struct domain. > > This patch also creates two new boolean macros: > > > > - 'has_iommu_pt()' evaluates to true if a domain has IOMMU mappings, > even > > if they are still under construction. > > - 'need_iommu_pt_sync()' evaluates to true if a domain requires explicit > > synchronization of the P2M and IOMMU mappings. > > > > All callers of need_iommu() are then modified to use the macro > appropriate > > to what they are trying to test, except for the instance in > > xen/drivers/passthrough/pci.c:assign_device() which has simply been > > removed since it appears to be unnecessary. > > > > NOTE: There are some callers of need_iommu() that strictly operate on > > the hardware domain. In some of these case a more global flag is > > used instead. > > > > Signed-off-by: Paul Durrant > > Acked-by: Razvan Cojocaru > > Presumably as a result of leaving out patch 4, this patch had quite a > bit of fuzz when applying. Would you please double check that I > didn't screw things up? > Certainly the commit looks fine. I'll re-base my PV-IOMMU series and re-test it... probably not until next week though. Paul > Jan > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 5/6] tools/dm_depriv: Add first cut RLIMITs
[resending]
On Fri, Oct 5, 2018 at 4:17 PM George Dunlap wrote:
>
> On Mon, Sep 24, 2018 at 9:35 AM Paul Durrant wrote:
> > > +{
> > > +.resource = -1
> >
> > Is -1 guaranteed not to clash with any defined resource type?
>
> Hmm... well at the moment /usr/include/bits/resource.h seems to have
> them defined as non-negative integers (i.e., starting at 0). But
> there's nothing I can see which prevents a new one being defined as -1
> if someone in the Linux community decides to. The POSIX merely
> defines this as a int, and I couldn't find anything which says it had
> to be non-negative in the spec.
>
> Linux seems to define RLIMIT_NLIMITS as the total number of limits so
> far defined; I'll use that instead. (That also sort of implies they
> expect you to use that as an array sizer, and the various limits as
> indexes into the array, and thus be non-negative; but whatever.)
>
> > > +
> > > +/* Set various "easy" rlimits */
> > > +for (i=0; rlimits[i].resource != -1; i++) {
> >
> > Couldn't figure out whether this is a coding style violation or not but I
> > think 'i=0' should be 'i = 0'
>
> Ack.
>
> -George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 01/12] x86: infrastructure to allow converting certain indirect calls to direct ones
>>> On 05.10.18 at 16:49, wrote: > On 05/10/18 14:43, Jan Beulich wrote: > On 05.10.18 at 14:39, wrote: >>> On 03/10/18 19:38, Andrew Cooper wrote: Makefile:136: recipe for target '/local/xen.git/xen/xen' failed make[1]: *** [/local/xen.git/xen/xen] Error 2 Makefile:45: recipe for target 'build' failed make: *** [build] Error 2 Using LD 2.30 built from source is fine, but I'm not sure exactly what is going on here. >>> Actually, I've just encountered this failure to link on staging as well, >>> so it is clearly not related to this series. Sorry for the noise (but >>> I'm still non-the-wiser as to what is actually broken). >> Could you try 2.31.1? Of course I did use 2.30 until 2.31 went out, >> and still didn't see this. Yet then again my variant is not exactly >> vanilla. > > I could (when I've got time to recompile my non-default compilers), but > what is this going to demonstrate? I wouldn't expect 2.31 to be broken > when 2.30 works fine. Oh, sorry - I mis-read your original statement. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/5] xen/domain: Introduce a new arch_check_domain_config() helper
On the ARM side, lift the code to select the appropriate GIC version when
NATIVE is requested.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
---
xen/arch/arm/domain.c | 44
xen/arch/x86/domain.c | 5 +
xen/common/domain.c | 2 +-
xen/include/xen/sched.h | 6 ++
4 files changed, 36 insertions(+), 21 deletions(-)
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index feebbf5..43593a4 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -599,6 +599,29 @@ void vcpu_switch_to_aarch64_mode(struct vcpu *v)
v->arch.hcr_el2 |= HCR_RW;
}
+int arch_check_domain_config(struct xen_domctl_createdomain *config)
+{
+/* Fill in the native GIC version, passed back to the toolstack. */
+if ( config->arch.gic_version == XEN_DOMCTL_CONFIG_GIC_NATIVE )
+{
+switch ( gic_hw_version() )
+{
+case GIC_V2:
+config->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
+break;
+
+case GIC_V3:
+config->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
+break;
+
+default:
+BUG();
+}
+}
+
+return 0;
+}
+
int arch_domain_create(struct domain *d,
struct xen_domctl_createdomain *config)
{
@@ -629,24 +652,6 @@ int arch_domain_create(struct domain *d,
switch ( config->arch.gic_version )
{
-case XEN_DOMCTL_CONFIG_GIC_NATIVE:
-switch ( gic_hw_version () )
-{
-case GIC_V2:
-config->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
-d->arch.vgic.version = GIC_V2;
-break;
-
-case GIC_V3:
-config->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
-d->arch.vgic.version = GIC_V3;
-break;
-
-default:
-BUG();
-}
-break;
-
case XEN_DOMCTL_CONFIG_GIC_V2:
d->arch.vgic.version = GIC_V2;
break;
@@ -656,8 +661,7 @@ int arch_domain_create(struct domain *d,
break;
default:
-rc = -EOPNOTSUPP;
-goto fail;
+BUG();
}
if ( (rc = domain_vgic_register(d, &count)) != 0 )
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index d67a047..26cab7c 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -401,6 +401,11 @@ void arch_vcpu_destroy(struct vcpu *v)
pv_vcpu_destroy(v);
}
+int arch_check_domain_config(struct xen_domctl_createdomain *config)
+{
+return 0;
+}
+
static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
{
#ifdef CONFIG_HVM
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 3f09a57..236c2ad 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -297,7 +297,7 @@ static int check_domain_config(struct
xen_domctl_createdomain *config)
XEN_DOMCTL_CDF_xs_domain) )
return -EINVAL;
-return 0;
+return arch_check_domain_config(config);
}
struct domain *domain_create(domid_t domid,
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 0ba80cb..7a35e53 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -542,6 +542,12 @@ int domain_set_node_affinity(struct domain *d, const
nodemask_t *affinity);
void domain_update_node_affinity(struct domain *d);
/*
+ * To be implemented by each architecture, sanity checking the configuration
+ * and filling in any appropriate defaults.
+ */
+int arch_check_domain_config(struct xen_domctl_createdomain *config);
+
+/*
* Create a domain: the configuration is only necessary for real domain
* (domid < DOMID_FIRST_RESERVED).
*/
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/5] xen/domain: Introduce a new check_domain_config() helper
Call it from the head of domain_create() (before doing any memory
allocations), which will apply the checks to dom0 as well as domU's.
For now, just subsume the XEN_DOMCTL_CDF_* check from XEN_DOMCTL_createdomain.
This means that the corner case of the toolstack providing bad configuration
will burn a domid, but production setups shouldn't ever get into this
situation.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
---
xen/common/domain.c | 15 +++
xen/common/domctl.c | 9 -
2 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 65151e2..3f09a57 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -288,6 +288,18 @@ static void _domain_destroy(struct domain *d)
free_domain_struct(d);
}
+static int check_domain_config(struct xen_domctl_createdomain *config)
+{
+if ( config->flags & ~(XEN_DOMCTL_CDF_hvm_guest |
+ XEN_DOMCTL_CDF_hap |
+ XEN_DOMCTL_CDF_s3_integrity |
+ XEN_DOMCTL_CDF_oos_off |
+ XEN_DOMCTL_CDF_xs_domain) )
+return -EINVAL;
+
+return 0;
+}
+
struct domain *domain_create(domid_t domid,
struct xen_domctl_createdomain *config,
bool is_priv)
@@ -297,6 +309,9 @@ struct domain *domain_create(domid_t domid,
INIT_evtchn = 1u<<3, INIT_gnttab = 1u<<4, INIT_arch = 1u<<5 };
int err, init_status = 0;
+if ( config && (err = check_domain_config(config)) )
+return ERR_PTR(err);
+
if ( (d = alloc_domain_struct()) == NULL )
return ERR_PTR(-ENOMEM);
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index b294881..d08b627 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -498,15 +498,6 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
u_domctl)
domid_tdom;
static domid_t rover = 0;
-ret = -EINVAL;
-if ( (op->u.createdomain.flags &
- ~(XEN_DOMCTL_CDF_hvm_guest
- | XEN_DOMCTL_CDF_hap
- | XEN_DOMCTL_CDF_s3_integrity
- | XEN_DOMCTL_CDF_oos_off
- | XEN_DOMCTL_CDF_xs_domain)) )
-break;
-
dom = op->domain;
if ( (dom > 0) && (dom < DOMID_FIRST_RESERVED) )
{
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 3/5] xen/domain: Audit config->max_vcpus during {, arch_}check_domain_config()
The purpose of this is to move the auduting to be earlier than
arch_domain_create().
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
The max_vcpus setting for GIC_V3 is somewhat confusing. The current GIC_V3
driver claims to support 4096 cpus, while the newer GIC_V3 driver uses 255.
In both cases, this gets clipped to 128 or 8 by the MAX_VIRT_CPUS setting.
---
xen/arch/arm/domain.c | 18 ++
xen/arch/x86/domain.c | 6 ++
xen/common/domain.c | 3 +++
3 files changed, 27 insertions(+)
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 43593a4..9676893 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -601,6 +601,8 @@ void vcpu_switch_to_aarch64_mode(struct vcpu *v)
int arch_check_domain_config(struct xen_domctl_createdomain *config)
{
+unsigned int max_vcpus = 0;
+
/* Fill in the native GIC version, passed back to the toolstack. */
if ( config->arch.gic_version == XEN_DOMCTL_CONFIG_GIC_NATIVE )
{
@@ -619,6 +621,22 @@ int arch_check_domain_config(struct
xen_domctl_createdomain *config)
}
}
+/* Calculate the maximum number of vcpus from the selected GIC version...
*/
+switch ( config->arch.gic_version )
+{
+case GIC_V2: max_vcpus = 8; break;
+case GIC_V3: max_vcpus = 255; break;
+
+default:
+return -EOPNOTSUPP;
+}
+
+/* ... clipped at the maximum value Xen has been configured for. */
+max_vcpus = min(max_vcpus, MAX_VIRT_CPUS + 0u);
+
+if ( config->max_vcpus > max_vcpus )
+return -EINVAL;
+
return 0;
}
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 26cab7c..19023d4 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -403,6 +403,12 @@ void arch_vcpu_destroy(struct vcpu *v)
int arch_check_domain_config(struct xen_domctl_createdomain *config)
{
+unsigned int max_vcpus = ((config->flags & XEN_DOMCTL_CDF_hvm_guest)
+ ? HVM_MAX_VCPUS : MAX_VIRT_CPUS);
+
+if ( config->max_vcpus > max_vcpus )
+return -EINVAL;
+
return 0;
}
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 236c2ad..9882550 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -297,6 +297,9 @@ static int check_domain_config(struct
xen_domctl_createdomain *config)
XEN_DOMCTL_CDF_xs_domain) )
return -EINVAL;
+if ( config->max_vcpus < 1 )
+return -EINVAL;
+
return arch_check_domain_config(config);
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 5/5] Revert "xen/arm: vgic-v3: Delay the initialization of the domain information"
This reverts commit 703d9d5ec13a0f487e7415174ba54e0e3ca158db. The domain
creation logic has been adjusted to set up d->max_vcpus early enough to be
usable in vgic_v3_domain_init().
Signed-off-by: Andrew Cooper
---
CC: Stefano Stabellini
CC: Julien Grall
---
xen/arch/arm/vgic-v3.c | 29 ++---
1 file changed, 2 insertions(+), 27 deletions(-)
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index b4476f3..e909502 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1573,11 +1573,9 @@ static const struct mmio_handler_ops
vgic_distr_mmio_handler = {
.write = vgic_v3_distr_mmio_write,
};
-static int vgic_v3_real_domain_init(struct domain *d);
-
static int vgic_v3_vcpu_init(struct vcpu *v)
{
-int i, rc;
+int i;
paddr_t rdist_base;
struct vgic_rdist_region *region;
unsigned int last_cpu;
@@ -1586,19 +1584,6 @@ static int vgic_v3_vcpu_init(struct vcpu *v)
struct domain *d = v->domain;
/*
- * This is the earliest place where the number of vCPUs is
- * known. This is required to initialize correctly the vGIC v3
- * domain structure. We only to do that when vCPU 0 is
- * initilialized.
- */
-if ( v->vcpu_id == 0 )
-{
-rc = vgic_v3_real_domain_init(d);
-if ( rc )
-return rc;
-}
-
-/*
* Find the region where the re-distributor lives. For this purpose,
* we look one region ahead as we have only the first CPU in hand.
*/
@@ -1660,7 +1645,7 @@ static inline unsigned int vgic_v3_max_rdist_count(struct
domain *d)
GUEST_GICV3_RDIST_REGIONS;
}
-static int vgic_v3_real_domain_init(struct domain *d)
+static int vgic_v3_domain_init(struct domain *d)
{
struct vgic_rdist_region *rdist_regions;
int rdist_count, i, ret;
@@ -1763,16 +1748,6 @@ static int vgic_v3_real_domain_init(struct domain *d)
return 0;
}
-static int vgic_v3_domain_init(struct domain *d)
-{
-/*
- * The domain initialization for vGIC v3 is delayed until the first vCPU
- * is created. This because the initialization may require to know the
- * number of vCPUs that is not known when creating the domain.
- */
-return 0;
-}
-
static void vgic_v3_domain_free(struct domain *d)
{
vgic_v3_its_free_domain(d);
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4/5] xen/domain: Allocate d->vcpu[] earlier during domain_create()
With config->max_vcpus now being audited by the check_domain_config() path, we
can alloate d->vcpu[] before calling arch_domain_create().
Doing do allows for the removal of domain_max_vcpus(), which on the ARM side
removes vgic_max_vcpus() and the .max_vcpus field from vgic_ops.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
---
xen/arch/arm/vgic-v2.c| 1 -
xen/arch/arm/vgic-v3.c| 5 -
xen/arch/arm/vgic.c | 5 -
xen/arch/arm/vgic/vgic-init.c | 3 ---
xen/arch/arm/vgic/vgic.c | 16
xen/common/domain.c | 27 ++-
xen/include/asm-arm/domain.h | 6 --
xen/include/asm-arm/vgic.h| 4
xen/include/asm-x86/domain.h | 2 --
9 files changed, 14 insertions(+), 55 deletions(-)
diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index f6c11f1..055a30a 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -724,7 +724,6 @@ static const struct vgic_ops vgic_v2_ops = {
.domain_free = vgic_v2_domain_free,
.lpi_to_pending = vgic_v2_lpi_to_pending,
.lpi_get_priority = vgic_v2_lpi_get_priority,
-.max_vcpus = 8,
};
int vgic_v2_init(struct domain *d, int *mmio_count)
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index efe824c..b4476f3 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1822,11 +1822,6 @@ static const struct vgic_ops v3_ops = {
.emulate_reg = vgic_v3_emulate_reg,
.lpi_to_pending = vgic_v3_lpi_to_pending,
.lpi_get_priority = vgic_v3_lpi_get_priority,
-/*
- * We use both AFF1 and AFF0 in (v)MPIDR. Thus, the max number of CPU
- * that can be supported is up to 4096(==256*16) in theory.
- */
-.max_vcpus = 4096,
};
int vgic_v3_init(struct domain *d, int *mmio_count)
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 5a4f082..664aa0b 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -667,11 +667,6 @@ void vgic_free_virq(struct domain *d, unsigned int virq)
clear_bit(virq, d->arch.vgic.allocated_irqs);
}
-unsigned int vgic_max_vcpus(const struct domain *d)
-{
-return min_t(unsigned int, MAX_VIRT_CPUS, d->arch.vgic.handler->max_vcpus);
-}
-
/*
* Local variables:
* mode: C
diff --git a/xen/arch/arm/vgic/vgic-init.c b/xen/arch/arm/vgic/vgic-init.c
index bfd3d09..62ae553 100644
--- a/xen/arch/arm/vgic/vgic-init.c
+++ b/xen/arch/arm/vgic/vgic-init.c
@@ -112,9 +112,6 @@ int domain_vgic_register(struct domain *d, int *mmio_count)
BUG();
}
-if ( d->max_vcpus > domain_max_vcpus(d) )
-return -E2BIG;
-
d->arch.vgic.vgic_dist_base = VGIC_ADDR_UNDEF;
d->arch.vgic.vgic_cpu_base = VGIC_ADDR_UNDEF;
d->arch.vgic.vgic_redist_base = VGIC_ADDR_UNDEF;
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 7c3cfc5..e1ee216 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -949,22 +949,6 @@ void vgic_sync_hardware_irq(struct domain *d,
spin_unlock_irqrestore(&desc->lock, flags);
}
-unsigned int vgic_max_vcpus(const struct domain *d)
-{
-unsigned int vgic_vcpu_limit;
-
-switch ( d->arch.vgic.version )
-{
-case GIC_V2:
-vgic_vcpu_limit = VGIC_V2_MAX_CPUS;
-break;
-default:
-BUG();
-}
-
-return min_t(unsigned int, MAX_VIRT_CPUS, vgic_vcpu_limit);
-}
-
#ifdef CONFIG_GICV3
/* Dummy implementation to allow building without actual vGICv3 support. */
void vgic_v3_setup_hw(paddr_t dbase,
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 9882550..ee7b889 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -354,6 +354,20 @@ struct domain *domain_create(domid_t domid,
TRACE_1D(TRC_DOM0_DOM_ADD, d->domain_id);
+/*
+ * Allocate d->vcpu[] and set ->max_vcpus up early. Various per-domain
+ * resources want to be sized based on max_vcpus.
+ */
+if ( !is_system_domain(d) )
+{
+err = -ENOMEM;
+d->vcpu = xzalloc_array(struct vcpu *, config->max_vcpus);
+if ( !d->vcpu )
+goto fail;
+
+d->max_vcpus = config->max_vcpus;
+}
+
lock_profile_register_struct(LOCKPROF_TYPE_PERDOM, d, domid, "Domain");
if ( (err = xsm_alloc_security_domain(d)) != 0 )
@@ -405,19 +419,6 @@ struct domain *domain_create(domid_t domid,
if ( !is_idle_domain(d) )
{
-/* Check d->max_vcpus and allocate d->vcpu[]. */
-err = -EINVAL;
-if ( config->max_vcpus < 1 ||
- config->max_vcpus > domain_max_vcpus(d) )
-goto fail;
-
-err = -ENOMEM;
-d->vcpu = xzalloc_array(struct vcpu *, config->max_vcpus);
-if ( !d->vcpu )
-goto fail;
-
-d->max_vcpus = config->max_vcpus;
-
watchdog_domain_init(d);
init_status |= INIT_watchdog;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index d68230
[Xen-devel] [PATCH RFC 0/5] xen/domain: Allocate d->vcpu[] earlier during domain construction
To fix an order-of-construction issue with gic-v3 on ARM, arrange for
d->max_vcpus to be auditied and set up prior to arch_domain_create()
This is RFC because all of the interesting changes are in ARM, and therefore
only compile tested by me at this point.
This can be found in git tree from from:
http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/xen-alloc-vcpus
Andrew Cooper (5):
xen/domain: Introduce a new check_domain_config() helper
xen/domain: Introduce a new arch_check_domain_config() helper
xen/domain: Audit config->max_vcpus during {,arch_}check_domain_config()
xen/domain: Allocate d->vcpu[] earlier during domain_create()
Revert "xen/arm: vgic-v3: Delay the initialization of the domain information"
xen/arch/arm/domain.c | 62 +--
xen/arch/arm/vgic-v2.c| 1 -
xen/arch/arm/vgic-v3.c| 34 ++--
xen/arch/arm/vgic.c | 5
xen/arch/arm/vgic/vgic-init.c | 3 ---
xen/arch/arm/vgic/vgic.c | 16 ---
xen/arch/x86/domain.c | 11
xen/common/domain.c | 45 ++-
xen/common/domctl.c | 9 ---
xen/include/asm-arm/domain.h | 6 -
xen/include/asm-arm/vgic.h| 4 ---
xen/include/asm-x86/domain.h | 2 --
xen/include/xen/sched.h | 6 +
13 files changed, 93 insertions(+), 111 deletions(-)
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 01/12] x86: infrastructure to allow converting certain indirect calls to direct ones
On 05/10/18 14:43, Jan Beulich wrote: On 05.10.18 at 14:39, wrote: >> On 03/10/18 19:38, Andrew Cooper wrote: >>> Finally, this series doesn't link with the default Debian toolchain. >>> >>> andrewcoop@andrewcoop:/local/xen.git/xen$ ld --version >>> GNU ld (GNU Binutils for Debian) 2.25 >>> >>> andrewcoop@andrewcoop:/local/xen.git/xen$ make -s build -j8 >>> XEN_TARGET_ARCH=x86_64 KCONFIG_CONFIG=.config-release >>> __ ___ __ __ _ >>> \ \/ /___ _ __ | || | / |___ \_ _ _ __ ___| |_ __ _| |__ | | ___ >>> \ // _ \ '_ \ | || |_ | | __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ >>> / \ __/ | | | |__ _|| |/ __/|__| |_| | | | \__ \ || (_| | |_) | | __/ >>> /_/\_\___|_| |_||_|(_)_|_| \__,_|_| |_|___/\__\__,_|_.__/|_|\___| >>> >>> prelink.o:(.debug_aranges+0x3c94): relocation truncated to fit: R_X86_64_32 >>> against `.debug_info' >>> prelink.o:(.debug_info+0x225fa): relocation truncated to fit: R_X86_64_32 >>> against `.debug_str' >>> prelink.o:(.debug_info+0x22b57): relocation truncated to fit: R_X86_64_32 >>> against `.debug_str' >>> prelink.o:(.debug_info+0x1b92da): relocation truncated to fit: R_X86_64_32 >>> against `.debug_str' >>> prelink.o:(.debug_info+0x21e976): relocation truncated to fit: R_X86_64_32 >>> against `.debug_str' >>> prelink.o:(.debug_info+0x21ec31): relocation truncated to fit: R_X86_64_32 >>> against `.debug_str' >>> prelink.o:(.debug_info+0x21f03b): relocation truncated to fit: R_X86_64_32 >>> against `.debug_str' >>> prelink.o:(.debug_info+0x2b2ac3): relocation truncated to fit: R_X86_64_32 >>> against `.debug_loc' >>> prelink.o:(.debug_info+0x2b37f6): relocation truncated to fit: R_X86_64_32 >>> against `.debug_str' >>> prelink.o:(.debug_info+0x448fab): relocation truncated to fit: R_X86_64_32 >>> against `.debug_str' >>> prelink.o:(.debug_info+0x44b856): additional relocation overflows omitted >>> from the output >>> ld: prelink.o: access beyond end of merged section (6617683) >>> ld: prelink.o: access beyond end of merged section (6617630) >>> ld: prelink.o: access beyond end of merged section (6617579) >>> ld: prelink.o: access beyond end of merged section (6617558) >>> ld: prelink.o: access beyond end of merged section (6617544) >>> ld: prelink.o: access beyond end of merged section (6617605) >>> ld: prelink.o: access beyond end of merged section (6617718) >>> ld: prelink.o: access beyond end of merged section (6617570) >>> ld: prelink.o: access beyond end of merged section (6617665) >>> ld: prelink.o: access beyond end of merged section (6617671) >>> ld: prelink.o: access beyond end of merged section (6617624) >>> ld: prelink.o: access beyond end of merged section (6617748) >>> ld: prelink.o: access beyond end of merged section (6617771) >>> ld: prelink.o: access beyond end of merged section (6617592) >>> ld: prelink.o: access beyond end of merged section (6617635) >>> ld: prelink.o: access beyond end of merged section (6617652) >>> ld: prelink.o: access beyond end of merged section (6617766) >>> ld: prelink.o: access beyond end of merged section (6617742) > Something along the lines of one or both of the above kinds I've > happened to run into when using a gas producing compressed > debug sections together with an objcopy which doesn't know > about such section (iirc older objcopy silently dropped some > section flag in this case). I've tracked the issues down Olaf's DEBUG_INFO patch. Having DEBUG_INFO set when DEBUG is clear (which is the default for release builds) results in this breakage. Another diagnostic has come to light: ld: Dwarf Error: found dwarf version '0', this reader only handles version 2, 3 and 4 information. prelink.o:(.debug_info+0x1bcee4): relocation truncated to fit: R_X86_64_32 against `.debug_str' > >>> ld: prelink.o(.debug_info+0xc962ed): reloc against `.debug_loc': error 2 >>> Makefile:134: recipe for target '/local/xen.git/xen/xen-syms' failed >>> make[2]: *** [/local/xen.git/xen/xen-syms] Error 1 >>> make[2]: *** Waiting for unfinished jobs >>> /local/xen.git/xen/.xen.efi.0s.S: Assembler messages: >>> /local/xen.git/xen/.xen.efi.0s.S:21: Warning: value 0x7d2f8544 >>> truncated to 0x8544 >>> /local/xen.git/xen/.xen.efi.0s.S:22: Warning: value 0x7d2f88dc >>> truncated to 0x88dc >>> /local/xen.git/xen/.xen.efi.0s.S:23: Warning: value 0x7d2f88de >>> truncated to 0x88de >>> /local/xen.git/xen/.xen.efi.0s.S:24: Warning: value 0x7d2f88e3 >>> truncated to 0x88e3 >>> /local/xen.git/xen/.xen.efi.0s.S:25: Warning: value 0x7d2f80001086 >>> truncated to 0x80001086 >>> /local/xen.git/xen/.xen.efi.0s.S:26: Warning: value 0x7d2f8000108a >>> truncated to 0x8000108a >>> /local/xen.git/xen/.xen.efi.0s.S:27: Warning: value 0x7d2f8000108e >>> truncated to 0x8000108e >>> /local/xen.git/xen/.xen.efi.0s.S:28: Warning: value 0x7d2f800010dc >>
Re: [Xen-devel] [PATCH v14 9/9] mm / iommu: split need_iommu() into has_iommu_pt() and need_iommu_pt_sync()
>>> On 04.10.18 at 12:45, wrote: > The name 'need_iommu()' is a little confusing as it suggests a domain needs > to use the IOMMU but something might not be set up yet, when in fact it > represents a tri-state value (not a boolean as might be expected) where > -1 means 'IOMMU mappings being set up' and 1 means 'IOMMU mappings have > been fully set up'. > > Two different meanings are also inferred from the macro it in various > places in the code: > > - Some callers want to test whether a domain has IOMMU mappings at all > - Some callers want to test whether they need to synchronize the domain's > P2M and IOMMU mappings > > This patch replaces the 'need_iommu' tri-state value with a defined > enumeration and adds a boolean flag 'need_sync' to separate these meanings, > and places both of these in struct domain_iommu, rather than directly in > struct domain. > This patch also creates two new boolean macros: > > - 'has_iommu_pt()' evaluates to true if a domain has IOMMU mappings, even > if they are still under construction. > - 'need_iommu_pt_sync()' evaluates to true if a domain requires explicit > synchronization of the P2M and IOMMU mappings. > > All callers of need_iommu() are then modified to use the macro appropriate > to what they are trying to test, except for the instance in > xen/drivers/passthrough/pci.c:assign_device() which has simply been > removed since it appears to be unnecessary. > > NOTE: There are some callers of need_iommu() that strictly operate on > the hardware domain. In some of these case a more global flag is > used instead. > > Signed-off-by: Paul Durrant > Acked-by: Razvan Cojocaru Presumably as a result of leaving out patch 4, this patch had quite a bit of fuzz when applying. Would you please double check that I didn't screw things up? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.9 test] 128388: tolerable FAIL - PUSHED
flight 128388 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/128388/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail in 128363 pass in 128388 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10 fail pass in 128363 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 128226 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 128226 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 128226 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128226 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 128226 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: linuxcdd48f386d7e6671e7cc21e517ae258b298ec877 baseline version
Re: [Xen-devel] [PATCH v5 0/2][XTF] FPU test improvements
>>> On 05.10.18 at 15:39, wrote: > On 05/10/18 14:28, Jan Beulich wrote: >> 1: add FPU/SIMD register state test >> 2: extend FPU exception tests >> >> Signed-off-by: Jan Beulich > > Thanks. However, I need to get the incremental test version logic > working first, or OSSTest will block this on older versions of Xen, due > to (falsely) believing that there has been a regression. I can see why patch 2 has such a dependency, but patch 1 introduces a brand new test. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 01/12] x86: infrastructure to allow converting certain indirect calls to direct ones
>>> On 05.10.18 at 14:39, wrote: > On 03/10/18 19:38, Andrew Cooper wrote: >> Finally, this series doesn't link with the default Debian toolchain. >> >> andrewcoop@andrewcoop:/local/xen.git/xen$ ld --version >> GNU ld (GNU Binutils for Debian) 2.25 >> >> andrewcoop@andrewcoop:/local/xen.git/xen$ make -s build -j8 >> XEN_TARGET_ARCH=x86_64 KCONFIG_CONFIG=.config-release >> __ ___ __ __ _ >> \ \/ /___ _ __ | || | / |___ \_ _ _ __ ___| |_ __ _| |__ | | ___ >> \ // _ \ '_ \ | || |_ | | __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ >> / \ __/ | | | |__ _|| |/ __/|__| |_| | | | \__ \ || (_| | |_) | | __/ >> /_/\_\___|_| |_||_|(_)_|_| \__,_|_| |_|___/\__\__,_|_.__/|_|\___| >> >> prelink.o:(.debug_aranges+0x3c94): relocation truncated to fit: R_X86_64_32 >> against `.debug_info' >> prelink.o:(.debug_info+0x225fa): relocation truncated to fit: R_X86_64_32 >> against `.debug_str' >> prelink.o:(.debug_info+0x22b57): relocation truncated to fit: R_X86_64_32 >> against `.debug_str' >> prelink.o:(.debug_info+0x1b92da): relocation truncated to fit: R_X86_64_32 >> against `.debug_str' >> prelink.o:(.debug_info+0x21e976): relocation truncated to fit: R_X86_64_32 >> against `.debug_str' >> prelink.o:(.debug_info+0x21ec31): relocation truncated to fit: R_X86_64_32 >> against `.debug_str' >> prelink.o:(.debug_info+0x21f03b): relocation truncated to fit: R_X86_64_32 >> against `.debug_str' >> prelink.o:(.debug_info+0x2b2ac3): relocation truncated to fit: R_X86_64_32 >> against `.debug_loc' >> prelink.o:(.debug_info+0x2b37f6): relocation truncated to fit: R_X86_64_32 >> against `.debug_str' >> prelink.o:(.debug_info+0x448fab): relocation truncated to fit: R_X86_64_32 >> against `.debug_str' >> prelink.o:(.debug_info+0x44b856): additional relocation overflows omitted >> from the output >> ld: prelink.o: access beyond end of merged section (6617683) >> ld: prelink.o: access beyond end of merged section (6617630) >> ld: prelink.o: access beyond end of merged section (6617579) >> ld: prelink.o: access beyond end of merged section (6617558) >> ld: prelink.o: access beyond end of merged section (6617544) >> ld: prelink.o: access beyond end of merged section (6617605) >> ld: prelink.o: access beyond end of merged section (6617718) >> ld: prelink.o: access beyond end of merged section (6617570) >> ld: prelink.o: access beyond end of merged section (6617665) >> ld: prelink.o: access beyond end of merged section (6617671) >> ld: prelink.o: access beyond end of merged section (6617624) >> ld: prelink.o: access beyond end of merged section (6617748) >> ld: prelink.o: access beyond end of merged section (6617771) >> ld: prelink.o: access beyond end of merged section (6617592) >> ld: prelink.o: access beyond end of merged section (6617635) >> ld: prelink.o: access beyond end of merged section (6617652) >> ld: prelink.o: access beyond end of merged section (6617766) >> ld: prelink.o: access beyond end of merged section (6617742) Something along the lines of one or both of the above kinds I've happened to run into when using a gas producing compressed debug sections together with an objcopy which doesn't know about such section (iirc older objcopy silently dropped some section flag in this case). >> ld: prelink.o(.debug_info+0xc962ed): reloc against `.debug_loc': error 2 >> Makefile:134: recipe for target '/local/xen.git/xen/xen-syms' failed >> make[2]: *** [/local/xen.git/xen/xen-syms] Error 1 >> make[2]: *** Waiting for unfinished jobs >> /local/xen.git/xen/.xen.efi.0s.S: Assembler messages: >> /local/xen.git/xen/.xen.efi.0s.S:21: Warning: value 0x7d2f8544 truncated >> to 0x8544 >> /local/xen.git/xen/.xen.efi.0s.S:22: Warning: value 0x7d2f88dc truncated >> to 0x88dc >> /local/xen.git/xen/.xen.efi.0s.S:23: Warning: value 0x7d2f88de truncated >> to 0x88de >> /local/xen.git/xen/.xen.efi.0s.S:24: Warning: value 0x7d2f88e3 truncated >> to 0x88e3 >> /local/xen.git/xen/.xen.efi.0s.S:25: Warning: value 0x7d2f80001086 truncated >> to 0x80001086 >> /local/xen.git/xen/.xen.efi.0s.S:26: Warning: value 0x7d2f8000108a truncated >> to 0x8000108a >> /local/xen.git/xen/.xen.efi.0s.S:27: Warning: value 0x7d2f8000108e truncated >> to 0x8000108e >> /local/xen.git/xen/.xen.efi.0s.S:28: Warning: value 0x7d2f800010dc truncated >> to 0x800010dc >> /local/xen.git/xen/.xen.efi.0s.S:29: Warning: value 0x7d2f80001172 truncated >> to 0x80001172 >> /local/xen.git/xen/.xen.efi.1s.S: Assembler messages: >> /local/xen.git/xen/.xen.efi.1s.S:21: Warning: value 0x7d2f8544 truncated >> to 0x8544 >> /local/xen.git/xen/.xen.efi.1s.S:22: Warning: value 0x7d2f88dc truncated >> to 0x88dc >> /local/xen.git/xen/.xen.efi.1s.S:23: Warning: value 0x7d2f88de truncated >> to 0x88de >> /local/xen.git/xen/.xen.efi.1s.S:24: Warning: val
[Xen-devel] [PATCH 1/2] x86/hvm: make sure HVM_PARAM_[BUF]IOREQ_PFN can only be set once
These parameters should have always been in the 'set once' category
but this has, so far, not been enforced.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
xen/arch/x86/hvm/hvm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 51fc3ec07f..07ec20fb52 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4083,6 +4083,8 @@ static int hvm_allow_set_param(struct domain *d,
{
/* The following parameters should only be changed once. */
case HVM_PARAM_VIRIDIAN:
+case HVM_PARAM_IOREQ_PFN:
+case HVM_PARAM_BUFIOREQ_PFN:
case HVM_PARAM_IOREQ_SERVER_PFN:
case HVM_PARAM_NR_IOREQ_SERVER_PAGES:
case HVM_PARAM_ALTP2M:
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 0/2] ioreq: make use of 'legacy' GFNs
Paul Durrant (2): x86/hvm: make sure HVM_PARAM_[BUF]IOREQ_PFN can only be set once x86/hvm/ioreq: allow ioreq servers to use HVM_PARAM_[BUF]IOREQ_PFN xen/arch/x86/hvm/hvm.c | 2 ++ xen/arch/x86/hvm/ioreq.c | 50 ++-- xen/include/asm-x86/hvm/domain.h | 3 ++- 3 files changed, 52 insertions(+), 3 deletions(-) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/2] x86/hvm/ioreq: allow ioreq servers to use HVM_PARAM_[BUF]IOREQ_PFN
Since commit 2c257bd6 "x86/hvm: remove default ioreq server (again)" the
GFNs allocated by the toolstack and set in HVM_PARAM_IOREQ_PFN and
HVM_PARAM_BUFIOREQ_PFN have been unused. This patch allows them to be used
by (non-default) ioreq servers.
NOTE: This fixes a compatibility issue. A guest created on a version of
Xen that pre-dates the initial ioreq server implementation and then
migrated in will currently fail to resume because its migration
stream will lack values for HVM_PARAM_IOREQ_SERVER_PFN and
HVM_PARAM_NR_IOREQ_SERVER_PAGES *unless* the system has an
emulator domain that uses direct resource mapping (which depends
on the version of privcmd it happens to have) in which case it
will not require use of GFNs for the ioreq server shared
pages.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
A similar compatibility issue with migrated-in VMs exists with Xen 4.11
because the upstream QEMU fall-back to use legacy ioreq server was broken
when direct resource mapping was introduced.
This is because, prior to the resource mapping patches, it was the creation
of the non-default ioreq server that failed if GFNs were not available
whereas, as of 4.11, it is retrieval of the info that fails which does not
trigger the fall-back.
---
xen/arch/x86/hvm/ioreq.c | 50 ++--
xen/include/asm-x86/hvm/domain.h | 3 ++-
2 files changed, 50 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 3569beaad5..4bac0a100c 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -237,6 +237,26 @@ bool handle_hvm_io_completion(struct vcpu *v)
return true;
}
+static gfn_t hvm_alloc_legacy_ioreq_gfn(struct hvm_ioreq_server *s)
+{
+struct domain *d = s->target;
+unsigned int i;
+
+BUILD_BUG_ON(HVM_PARAM_IOREQ_PFN >
+ sizeof(d->arch.hvm.ioreq_gfn.legacy_mask) * 8);
+BUILD_BUG_ON(HVM_PARAM_BUFIOREQ_PFN >
+ sizeof(d->arch.hvm.ioreq_gfn.legacy_mask) * 8);
+BUILD_BUG_ON(HVM_PARAM_BUFIOREQ_PFN != HVM_PARAM_IOREQ_PFN + 1);
+
+for ( i = HVM_PARAM_IOREQ_PFN; i <= HVM_PARAM_BUFIOREQ_PFN; i++ )
+{
+if ( !test_and_set_bit(i, &d->arch.hvm.ioreq_gfn.legacy_mask) )
+return _gfn(d->arch.hvm.params[i]);
+}
+
+return INVALID_GFN;
+}
+
static gfn_t hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s)
{
struct domain *d = s->target;
@@ -248,7 +268,29 @@ static gfn_t hvm_alloc_ioreq_gfn(struct hvm_ioreq_server
*s)
return _gfn(d->arch.hvm.ioreq_gfn.base + i);
}
-return INVALID_GFN;
+/*
+ * If we are out of 'normal' GFNs then we may still have a 'legacy'
+ * GFN available.
+ */
+return hvm_alloc_legacy_ioreq_gfn(s);
+}
+
+static bool hvm_free_legacy_ioreq_gfn(struct hvm_ioreq_server *s,
+ gfn_t gfn)
+{
+struct domain *d = s->target;
+unsigned int i;
+
+for ( i = HVM_PARAM_IOREQ_PFN; i <= HVM_PARAM_BUFIOREQ_PFN; i++ )
+{
+if ( gfn_eq(gfn, _gfn(d->arch.hvm.params[i])) )
+ break;
+}
+if ( i > HVM_PARAM_BUFIOREQ_PFN )
+return false;
+
+clear_bit(i, &d->arch.hvm.ioreq_gfn.legacy_mask);
+return true;
}
static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s, gfn_t gfn)
@@ -258,7 +300,11 @@ static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s,
gfn_t gfn)
ASSERT(!gfn_eq(gfn, INVALID_GFN));
-set_bit(i, &d->arch.hvm.ioreq_gfn.mask);
+if ( !hvm_free_legacy_ioreq_gfn(s, gfn) )
+{
+ASSERT(i < sizeof(d->arch.hvm.ioreq_gfn.mask) * 8);
+set_bit(i, &d->arch.hvm.ioreq_gfn.mask);
+}
}
static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h
index 80b2ab041e..a9f68d9571 100644
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -95,7 +95,8 @@ struct hvm_domain {
/* Guest page range used for non-default ioreq servers */
struct {
unsigned long base;
-unsigned long mask;
+unsigned long mask; /* clear to allocate */
+unsigned long legacy_mask; /* set to allocate */
} ioreq_gfn;
/* Lock protects all other values in the sub-struct and the default */
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 0/2][XTF] FPU test improvements
On 05/10/18 14:28, Jan Beulich wrote: > 1: add FPU/SIMD register state test > 2: extend FPU exception tests > > Signed-off-by: Jan Beulich Thanks. However, I need to get the incremental test version logic working first, or OSSTest will block this on older versions of Xen, due to (falsely) believing that there has been a regression. I'll queue these changes once the requisite infrastructure is in place. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [freebsd-master test] 128413: all pass - PUSHED
flight 128413 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/128413/ Perfect :-) All tests in this flight passed as required version targeted for testing: freebsd 8f45b071b58d4a00be551ddcc52e78a06ed6fbc7 baseline version: freebsd a16e14a2bb879c082d379f9ca2f201e993960b85 Last test of basis 128339 2018-10-03 09:19:05 Z2 days Testing same since 128413 2018-10-05 09:19:12 Z0 days1 attempts People who touched revisions under test: 0mp <0...@freebsd.org> andreast brooks emaste gjb glebius gonzo markj mjg mmacy pjd rstone jobs: build-amd64-freebsd-againpass build-amd64-freebsd pass build-amd64-xen-freebsd 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/freebsd.git a16e14a2bb8..8f45b071b58 8f45b071b58d4a00be551ddcc52e78a06ed6fbc7 -> tested/master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v5 2/2][XTF] x86: extend FPU exception tests
Also test #MF and #XM handling.
Signed-off-by: Jan Beulich
---
v4: Re-base.
v3: New.
--- /dev/null
+++ b/arch/x86/include/arch/simd.h
@@ -0,0 +1,32 @@
+#ifndef XTF_X86_SIMD_H
+#define XTF_X86_SIMD_H
+
+#define X86_MXCSR_IE 0x0001
+#define X86_MXCSR_DE 0x0002
+#define X86_MXCSR_ZE 0x0004
+#define X86_MXCSR_OE 0x0008
+#define X86_MXCSR_UE 0x0010
+#define X86_MXCSR_PE 0x0020
+#define X86_MXCSR_DAZ 0x0040
+#define X86_MXCSR_IM 0x0080
+#define X86_MXCSR_DM 0x0100
+#define X86_MXCSR_ZM 0x0200
+#define X86_MXCSR_OM 0x0400
+#define X86_MXCSR_UM 0x0800
+#define X86_MXCSR_PM 0x1000
+#define X86_MXCSR_RC_MASK 0x6000
+#define X86_MXCSR_FZ 0x8000
+
+#define X86_MXCSR_DEFAULT 0x1f80
+
+#endif /* XTF_X86_SIMD_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--- a/arch/x86/include/arch/x87.h
+++ b/arch/x86/include/arch/x87.h
@@ -3,6 +3,27 @@
#include
+#define X86_FCW_IM 0x0001
+#define X86_FCW_DM 0x0002
+#define X86_FCW_ZM 0x0004
+#define X86_FCW_OM 0x0008
+#define X86_FCW_UM 0x0010
+#define X86_FCW_PM 0x0020
+#define X86_FCW_PC_MASK 0x0300
+#define X86_FCW_RC_MASK 0x0c00
+
+#define X86_PC_SINGLE 0
+#define X86_PC_DOUBLE 2
+#define X86_PC_EXTENDED 3
+
+/* These also apply to MXCSR. */
+#define X86_RC_NEAREST 0
+#define X86_RC_DOWN 1
+#define X86_RC_UP 2
+#define X86_RC_ZERO 3
+
+#define X86_FCW_DEFAULT 0x037f
+
struct x87_env_pm32 {
uint16_t cw, :16;
uint16_t sw, :16;
--- a/tests/fpu-exception-emulation/main.c
+++ b/tests/fpu-exception-emulation/main.c
@@ -22,27 +22,37 @@
* checking that appropriate exceptions are raised (@#NM or @#UD), or that no
* exception is raised.
*
+ * Additionally #MF and #XM behavior is being tested.
+ *
* Each test is run against real hardware, and forced through the x86
* instruction emulator (if FEP is available).
*
* This test covers XSA-190, where @#NM was not being raised appropriately,
* therefore interfering with lazy FPU task switching in the guest.
*
- * @todo Extend to include unmasked pending exceptions. There is definitely
- * work required in the instruction emulator to support this properly.
- *
* @see tests/fpu-exception-emulation/main.c
*/
#include
+#include
+#include
const char test_title[] = "FPU Exception Emulation";
#define CR0_SYM(...) TOK_OR(X86_CR0_, ##__VA_ARGS__)
-#define CR0_MASK CR0_SYM(EM, MP, TS)
+#define CR0_MASK CR0_SYM(EM, MP, TS, NE)
+
+#define CR4_SYM(...) TOK_OR(X86_CR4_OS, ##__VA_ARGS__)
+#define CR4_MASK CR4_SYM(FXSR, XMMEXCPT, XSAVE)
+
+#define FCW_SYM(...) TOK_OR(X86_FCW_, ##__VA_ARGS__)
+
+#define MXCSR_SYM(...) TOK_OR(X86_MXCSR_, ##__VA_ARGS__)
struct test_cfg
{
unsigned long cr0;
+unsigned long cr4;
+unsigned int control;
exinfo_t fault;
};
@@ -54,20 +64,27 @@ static unsigned long default_cr0;
*/
static const struct test_cfg x87[] =
{
-{ CR0_SYM( ), 0 },
-{ CR0_SYM(TS), EXINFO_SYM(NM, 0) },
-{ CR0_SYM(MP), 0 },
-{ CR0_SYM(MP, TS), EXINFO_SYM(NM, 0) },
-{ CR0_SYM(EM), EXINFO_SYM(NM, 0) },
-{ CR0_SYM(EM, TS), EXINFO_SYM(NM, 0) },
-{ CR0_SYM(EM, MP), EXINFO_SYM(NM, 0) },
-{ CR0_SYM(EM, MP, TS), EXINFO_SYM(NM, 0) },
+{ CR0_SYM( ), 0, 0, 0 },
+{ CR0_SYM(TS), 0, 0, EXINFO_SYM(NM, 0) },
+{ CR0_SYM(MP), 0, 0, 0 },
+{ CR0_SYM(MP, TS), 0, 0, EXINFO_SYM(NM, 0) },
+{ CR0_SYM(EM), 0, 0, EXINFO_SYM(NM, 0) },
+{ CR0_SYM(EM, TS), 0, 0, EXINFO_SYM(NM, 0) },
+{ CR0_SYM(EM, MP), 0, 0, EXINFO_SYM(NM, 0) },
+{ CR0_SYM(EM, MP, TS), 0, 0, EXINFO_SYM(NM, 0) },
+{ CR0_SYM(NE), 0, FCW_SYM(IM), EXINFO_SYM(MF, 0) },
};
-exinfo_t probe_x87(bool force)
+exinfo_t probe_x87(unsigned int control, bool force)
{
exinfo_t fault = 0;
+if ( control )
+{
+control = X86_FCW_DEFAULT & ~control;
+asm volatile ("fninit; fldcw %0; faddp" :: "m" (control));
+}
+
asm volatile ("test %[fep], %[fep];"
"jz 1f;"
_ASM_XEN_FEP
@@ -77,6 +94,9 @@ exinfo_t probe_x87(bool force)
: [fep] "q" (force),
"X" (ex_record_fault_eax));
+if ( control )
+asm volatile ("fnclex");
+
return fault;
}
@@ -87,20 +107,27 @@ exinfo_t probe_x87(bool force)
*/
static const struct test_cfg x87_wait[] =
{
-{ CR0_SYM( ), 0 },
-{ CR0_SYM(TS), 0 },
-{ CR0_SYM(MP), 0 },
-{ CR0_SYM(MP, TS), EXINFO_SYM(NM, 0) },
-{ CR0_SYM(EM), 0 },
-{ CR0_SYM(EM, TS), 0 },
-{ CR0_SYM(EM, MP), 0 },
-{ CR0_SYM(EM, MP, TS), EXINFO_SYM(NM, 0) }
[Xen-devel] [PATCH v5 1/2][XTF] add FPU/SIMD register state test
Add tests to verify that
- FPU insns leave correct (guest) values in FIP/FDP/FOP/FCS/FDS (at the
example for FSTPS),
- FPU insns writing memory don't update FPU register state when the
write faults (at the example of FISTPS),
- VCVTPS2PH doesn't update MXCSR if its write faults (VCVTPS2PH is one
of the very few SIMD insns writing to memory _and_ updating register
state; the scatter family of insns also falls into this category).
Signed-off-by: Jan Beulich
---
v5: Add AVX512F variant of VCVTPS2PH test. Guard FDP check with
!cpu_has_fdp_excp_only.
v3: Re-base. Add entry to all-tests.dox.
v2: Introduce and use x87.h. Tolerate VCVTPS2PH misbehavior on Intel
hardware. Tolerate AMD oddities in probe_fstp() and probe_fistp().
--- a/arch/x86/include/arch/cpuid.h
+++ b/arch/x86/include/arch/cpuid.h
@@ -80,6 +80,7 @@ static inline bool cpu_has(unsigned int
#define cpu_has_x2apic cpu_has(X86_FEATURE_X2APIC)
#define cpu_has_xsave cpu_has(X86_FEATURE_XSAVE)
#define cpu_has_avx cpu_has(X86_FEATURE_AVX)
+#define cpu_has_f16ccpu_has(X86_FEATURE_F16C)
#define cpu_has_syscall cpu_has(X86_FEATURE_SYSCALL)
#define cpu_has_nx cpu_has(X86_FEATURE_NX)
@@ -90,6 +91,8 @@ static inline bool cpu_has(unsigned int
#define cpu_has_fsgsbasecpu_has(X86_FEATURE_FSGSBASE)
#define cpu_has_smepcpu_has(X86_FEATURE_SMEP)
+#define cpu_has_fdp_excp_only cpu_has(X86_FEATURE_FDP_EXCP_ONLY)
+#define cpu_has_avx512f cpu_has(X86_FEATURE_AVX512F)
#define cpu_has_smapcpu_has(X86_FEATURE_SMAP)
#define cpu_has_umipcpu_has(X86_FEATURE_UMIP)
--- /dev/null
+++ b/arch/x86/include/arch/x87.h
@@ -0,0 +1,27 @@
+#ifndef XTF_X86_X87_H
+#define XTF_X86_X87_H
+
+#include
+
+struct x87_env_pm32 {
+uint16_t cw, :16;
+uint16_t sw, :16;
+uint16_t tw, :16;
+uint32_t ip;
+uint16_t cs;
+uint16_t op:11, :5;
+uint32_t dp;
+uint16_t ds, :16;
+};
+
+#endif /* XTF_X86_X87_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--- a/docs/all-tests.dox
+++ b/docs/all-tests.dox
@@ -20,6 +20,8 @@ and functionality.
@subpage test-fpu-exception-emulation - FPU Exception Emulation. Covers
XSA-190.
+@subpage test-fpu-state - FPU state Emulation.
+
@subpage test-invlpg - `invlpg` instruction behaviour.
@subpage test-lbr-tsx-vmentry - Haswell and later LBR/TSX Vmentry failure test.
--- a/include/xen/arch-x86/cpufeatureset.h
+++ b/include/xen/arch-x86/cpufeatureset.h
@@ -134,6 +134,7 @@
#define X86_FEATURE_NO_FPU_SEL(5*32+13) /* FPU CS/DS stored as zero */
#define X86_FEATURE_MPX (5*32+14) /* Memory Protection Extensions */
#define X86_FEATURE_PQE (5*32+15) /* Platform QoS Enforcement */
+#define X86_FEATURE_AVX512F (5*32+16) /* AVX-512 Foundation Instructions
*/
#define X86_FEATURE_RDSEED(5*32+18) /* RDSEED instruction */
#define X86_FEATURE_ADX (5*32+19) /* ADCX, ADOX instructions */
#define X86_FEATURE_SMAP (5*32+20) /* Supervisor Mode Access
Prevention */
--- a/include/xen/arch-x86/xen.h
+++ b/include/xen/arch-x86/xen.h
@@ -15,6 +15,16 @@
#include "cpuid.h"
+/*
+ * A number of GDT entries are reserved by Xen. These are not situated at the
+ * start of the GDT because some stupid OSes export hard-coded selector values
+ * in their ABI. These hard-coded values are always near the start of the GDT,
+ * so Xen places itself out of the way, at the far end of the GDT.
+ *
+ * NB The LDT is set using the MMUEXT_SET_LDT op of HYPERVISOR_mmuext_op
+ */
+#define FIRST_RESERVED_GDT_PAGE 14
+
#ifndef __ASSEMBLY__
typedef unsigned long xen_pfn_t;
--- /dev/null
+++ b/tests/fpu-state/Makefile
@@ -0,0 +1,9 @@
+include $(ROOT)/build/common.mk
+
+NAME := fpu-state
+CATEGORY := functional
+TEST-ENVS := hvm64 hvm32pse
+
+obj-perenv += main.o
+
+include $(ROOT)/build/gen.mk
--- /dev/null
+++ b/tests/fpu-state/main.c
@@ -0,0 +1,272 @@
+/**
+ * @file tests/fpu-state/main.c
+ * @ref test-fpu-state - Emulation of FPU state
+ *
+ * @page test-fpu-state FPU State Emulation
+ *
+ * FPU code/data pointers and opcode must not be the ones resulting
+ * from the stub execution in the hypervisor.
+ *
+ * FPU and SIMD instructions faulting during memory write must not
+ * update the respective register files.
+ *
+ * @see tests/fpu-state/main.c
+ */
+#include
+
+#include
+#include
+
+const char test_title[] = "FPU State";
+
+void probe_fstp(bool force)
+{
+const uint8_t *fstp_offs;
+uint32_t flt;
+struct x87_env_pm32 fenv;
+
+fenv.cw = 0x35f; /* unmask PE */
+asm volatile ( "fninit;"
+ "fldcw %[cw];"
+ "fldpi;"
+ "mov $1f, %[offs];"
+ "test %[fep], %[fep];"
+ "jz 1f;"
+ _ASM_XEN_FEP
+ "1: fstps %[data]; 2:"
+
Re: [Xen-devel] [PATCH] x86/HVM: move vendor independent CPU save/restore logic to shared code
>>> On 05.10.18 at 14:18, wrote: > On 05/10/18 12:31, Jan Beulich wrote: >> A few pieces of the handling here are (no longer?) vendor specific, and >> hence there's no point in replicating the code. > > EFER probably was vendor specific originally. The control registers > really shouldn't have been... > >> Make sure not otherwise >> pre-filled fields of struct hvm_hw_cpu instances are zero filled before >> calling the vendor "save" hook, eliminating the need for the hook >> functions to zero individual fields. > > The start of this sentence is rather hard to parse. How about "Zero the > full structure before calling the save hook, eliminating the need to > zero individual fields." ? Fine with me, changed. >> Signed-off-by: Jan Beulich > > Code wise, this looks fine. Reviewed-by: Andrew Cooper > Thanks. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v5 0/2][XTF] FPU test improvements
1: add FPU/SIMD register state test 2: extend FPU exception tests Signed-off-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] ARM64: PCIe in DOM0
Hi,
On 05/10/2018 12:06, Bharat Bhushan wrote:
Further update:
If I change Kconfig to enable this default
CONFIG_HAS_ITS is in tech preview. For having access to it, you need to
pass XEN_CONFIG_EXPERT on *all* the make command line.
Then DOM0 Linux Boots but MSIs are not still working,
Getting below error:
- pci 0001:00:00.0: Failed to add - passthrough or MSI/MSI-X might fail!
This is a red-herring. This lines happen because
PHYSDEVOP_pci_device_add is not implemented on Xen Arm.
Any help is very useful,!!
Can you please provide the full log?
-Original Message-
From: Bharat Bhushan
Sent: Friday, October 5, 2018 2:09 PM
To: Xen-devel@lists.xenproject.org
Subject: ARM64: PCIe in DOM0
Hi All,
I am booting XEN for the first time on my platform and observing that
PCIe are not working.
Here are my observations on this.
1) "git-its" node (below) from device tree is not available in DOM0
device tree.
its: gic-its@602 {
compatible = "arm,gic-v3-its";
msi-controller;
reg = <0x0 0x602 0 0x2>;
};
We have "msi-parent" property in PCIe controller node which provides
phandle of above mentioned node.
Linux (DOM0) error out if it does find a valid msi-parent.
First question I have is, What is the reason for removing gic-its node?
If CONFIG_HAS_ITS is disabled, then the virtual ITS is not built.
Therefore the node is removed to prevent Dom0 using ITS.
2) Use Legacy interrupts rather than MSI
Used "pci=nomsi" in DOM0 bootargs to move away from MSIs,
Legacy interrupts are also not received and see netdev-watchdog.
Did you check whether legacy interrupts are routed to Dom0?
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/HVM: move vendor independent CPU save/restore logic to shared code
On 10/5/18 7:31 AM, Jan Beulich wrote: > A few pieces of the handling here are (no longer?) vendor specific, and > hence there's no point in replicating the code. Make sure not otherwise > pre-filled fields of struct hvm_hw_cpu instances are zero filled before > calling the vendor "save" hook, eliminating the need for the hook > functions to zero individual fields. > > Signed-off-by: Jan Beulich Reviewed-by: Boris Ostrovsky https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 128415: tolerable all pass - PUSHED
flight 128415 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/128415/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen d36b7704586c232388da8b170a111cc98127cdad baseline version: xen 81946a73dc975a7dafe9017a8e61d1e64fdbedbf Last test of basis 128380 2018-10-04 15:00:46 Z0 days Testing same since 128415 2018-10-05 10:00:38 Z0 days1 attempts People who touched revisions under test: Jan Beulich Razvan Cojocaru Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 81946a73dc..d36b770458 d36b7704586c232388da8b170a111cc98127cdad -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 01/12] x86: infrastructure to allow converting certain indirect calls to direct ones
On 03/10/18 19:38, Andrew Cooper wrote: > Finally, this series doesn't link with the default Debian toolchain. > > andrewcoop@andrewcoop:/local/xen.git/xen$ ld --version > GNU ld (GNU Binutils for Debian) 2.25 > > andrewcoop@andrewcoop:/local/xen.git/xen$ make -s build -j8 > XEN_TARGET_ARCH=x86_64 KCONFIG_CONFIG=.config-release > __ ___ __ __ _ > \ \/ /___ _ __ | || | / |___ \_ _ _ __ ___| |_ __ _| |__ | | ___ > \ // _ \ '_ \ | || |_ | | __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ > / \ __/ | | | |__ _|| |/ __/|__| |_| | | | \__ \ || (_| | |_) | | __/ > /_/\_\___|_| |_||_|(_)_|_| \__,_|_| |_|___/\__\__,_|_.__/|_|\___| > > prelink.o:(.debug_aranges+0x3c94): relocation truncated to fit: R_X86_64_32 > against `.debug_info' > prelink.o:(.debug_info+0x225fa): relocation truncated to fit: R_X86_64_32 > against `.debug_str' > prelink.o:(.debug_info+0x22b57): relocation truncated to fit: R_X86_64_32 > against `.debug_str' > prelink.o:(.debug_info+0x1b92da): relocation truncated to fit: R_X86_64_32 > against `.debug_str' > prelink.o:(.debug_info+0x21e976): relocation truncated to fit: R_X86_64_32 > against `.debug_str' > prelink.o:(.debug_info+0x21ec31): relocation truncated to fit: R_X86_64_32 > against `.debug_str' > prelink.o:(.debug_info+0x21f03b): relocation truncated to fit: R_X86_64_32 > against `.debug_str' > prelink.o:(.debug_info+0x2b2ac3): relocation truncated to fit: R_X86_64_32 > against `.debug_loc' > prelink.o:(.debug_info+0x2b37f6): relocation truncated to fit: R_X86_64_32 > against `.debug_str' > prelink.o:(.debug_info+0x448fab): relocation truncated to fit: R_X86_64_32 > against `.debug_str' > prelink.o:(.debug_info+0x44b856): additional relocation overflows omitted > from the output > ld: prelink.o: access beyond end of merged section (6617683) > ld: prelink.o: access beyond end of merged section (6617630) > ld: prelink.o: access beyond end of merged section (6617579) > ld: prelink.o: access beyond end of merged section (6617558) > ld: prelink.o: access beyond end of merged section (6617544) > ld: prelink.o: access beyond end of merged section (6617605) > ld: prelink.o: access beyond end of merged section (6617718) > ld: prelink.o: access beyond end of merged section (6617570) > ld: prelink.o: access beyond end of merged section (6617665) > ld: prelink.o: access beyond end of merged section (6617671) > ld: prelink.o: access beyond end of merged section (6617624) > ld: prelink.o: access beyond end of merged section (6617748) > ld: prelink.o: access beyond end of merged section (6617771) > ld: prelink.o: access beyond end of merged section (6617592) > ld: prelink.o: access beyond end of merged section (6617635) > ld: prelink.o: access beyond end of merged section (6617652) > ld: prelink.o: access beyond end of merged section (6617766) > ld: prelink.o: access beyond end of merged section (6617742) > ld: prelink.o(.debug_info+0xc962ed): reloc against `.debug_loc': error 2 > Makefile:134: recipe for target '/local/xen.git/xen/xen-syms' failed > make[2]: *** [/local/xen.git/xen/xen-syms] Error 1 > make[2]: *** Waiting for unfinished jobs > /local/xen.git/xen/.xen.efi.0s.S: Assembler messages: > /local/xen.git/xen/.xen.efi.0s.S:21: Warning: value 0x7d2f8544 truncated > to 0x8544 > /local/xen.git/xen/.xen.efi.0s.S:22: Warning: value 0x7d2f88dc truncated > to 0x88dc > /local/xen.git/xen/.xen.efi.0s.S:23: Warning: value 0x7d2f88de truncated > to 0x88de > /local/xen.git/xen/.xen.efi.0s.S:24: Warning: value 0x7d2f88e3 truncated > to 0x88e3 > /local/xen.git/xen/.xen.efi.0s.S:25: Warning: value 0x7d2f80001086 truncated > to 0x80001086 > /local/xen.git/xen/.xen.efi.0s.S:26: Warning: value 0x7d2f8000108a truncated > to 0x8000108a > /local/xen.git/xen/.xen.efi.0s.S:27: Warning: value 0x7d2f8000108e truncated > to 0x8000108e > /local/xen.git/xen/.xen.efi.0s.S:28: Warning: value 0x7d2f800010dc truncated > to 0x800010dc > /local/xen.git/xen/.xen.efi.0s.S:29: Warning: value 0x7d2f80001172 truncated > to 0x80001172 > /local/xen.git/xen/.xen.efi.1s.S: Assembler messages: > /local/xen.git/xen/.xen.efi.1s.S:21: Warning: value 0x7d2f8544 truncated > to 0x8544 > /local/xen.git/xen/.xen.efi.1s.S:22: Warning: value 0x7d2f88dc truncated > to 0x88dc > /local/xen.git/xen/.xen.efi.1s.S:23: Warning: value 0x7d2f88de truncated > to 0x88de > /local/xen.git/xen/.xen.efi.1s.S:24: Warning: value 0x7d2f88e3 truncated > to 0x88e3 > /local/xen.git/xen/.xen.efi.1s.S:25: Warning: value 0x7d2f80001086 truncated > to 0x80001086 > /local/xen.git/xen/.xen.efi.1s.S:26: Warning: value 0x7d2f8000108a truncated > to 0x8000108a > /local/xen.git/xen/.xen.efi.1s.S:27: Warning: value 0x7d2f8000108e truncated > to 0x8000108e > /local/xen.git/xen/.xen.efi.1s.S:28: Warning: value 0x7d2f8
Re: [Xen-devel] [PATCH] x86/HVM: move vendor independent CPU save/restore logic to shared code
On 05/10/18 12:31, Jan Beulich wrote: > A few pieces of the handling here are (no longer?) vendor specific, and > hence there's no point in replicating the code. EFER probably was vendor specific originally. The control registers really shouldn't have been... > Make sure not otherwise > pre-filled fields of struct hvm_hw_cpu instances are zero filled before > calling the vendor "save" hook, eliminating the need for the hook > functions to zero individual fields. The start of this sentence is rather hard to parse. How about "Zero the full structure before calling the save hook, eliminating the need to zero individual fields." ? > Signed-off-by: Jan Beulich Code wise, this looks fine. Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86: restrict HVMOP_pagetable_dying to current
>>> On 05.10.18 at 13:58, wrote: > On 05/10/18 12:29, Jan Beulich wrote: >> This is not used (and probably was never meant to be) by the tool stack. >> Limiting it to the current domain in particular allows to eliminate a >> bogus use of vCPU 0 in pagetable_dying(). >> >> Remove the now unnecessary domain/vCPU parameters from the wrapper/hook >> functions at the same time. >> >> Signed-off-by: Jan Beulich >> >> --- a/xen/arch/x86/hvm/hvm.c >> +++ b/xen/arch/x86/hvm/hvm.c >> @@ -4895,10 +4895,12 @@ long do_hvm_op(unsigned long op, XEN_GUE >> return -ESRCH; >> >> rc = -EINVAL; >> -if ( is_hvm_domain(d) && paging_mode_shadow(d) ) >> +if ( unlikely(d != current->domain) ) >> +rc = -EOPNOTSUPP; >> +else if ( is_hvm_domain(d) && paging_mode_shadow(d) ) >> rc = xsm_hvm_param(XSM_TARGET, d, op); > > As we're switching to current-only, shouldn't this turn to XSM_HOOK ? Not sure - I simply didn't want to fiddle with any of the semantics, and keeping it as it is may be sub-optimal, but is certainly not going to be wromg. > Everything else LGTM, with one small suggestion > >> if ( !rc ) >> -pagetable_dying(d, a.gpa); >> +pagetable_dying(a.gpa); >> >> rcu_unlock_domain(d); >> break; >> --- a/xen/include/asm-x86/paging.h >> +++ b/xen/include/asm-x86/paging.h >> @@ -345,7 +345,7 @@ void paging_write_p2m_entry(struct p2m_d >> >> /* Called from the guest to indicate that the a process is being >> * torn down and its pagetables will soon be discarded */ >> -void pagetable_dying(struct domain *d, paddr_t gpa); >> +void pagetable_dying(paddr_t gpa); > > Fix the comment style while in this area? Well, I can certainly do so - I didn't because I didn't touch the comment itself. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] pass-through: provide two !HVM stubs
On 05/10/18 12:26, Jan Beulich wrote: On 05.10.18 at 13:14, wrote: >> On Fri, Oct 05, 2018 at 05:11:55AM -0600, Jan Beulich wrote: >>> Older gcc, despite eliminating pci_clean_dpci_irqs() when !HVM, does >>> not manage to also eliminate pci_clean_dpci_irq(). Cope with this. >> Would be helpful to call out the version of gcc is the commit message. > It was 4.3 in this case, but I didn't think it was overly important. > Since you ask, I've added it. > >> Reviewed-by: Wei Liu Acked-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/HVM: move vendor independent CPU save/restore logic to shared code
On 10/5/18 2:31 PM, Jan Beulich wrote: > A few pieces of the handling here are (no longer?) vendor specific, and > hence there's no point in replicating the code. Make sure not otherwise > pre-filled fields of struct hvm_hw_cpu instances are zero filled before > calling the vendor "save" hook, eliminating the need for the hook > functions to zero individual fields. > > Signed-off-by: Jan Beulich Acked-by: Razvan Cojocaru Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86: restrict HVMOP_pagetable_dying to current
On 05/10/18 12:29, Jan Beulich wrote: > This is not used (and probably was never meant to be) by the tool stack. > Limiting it to the current domain in particular allows to eliminate a > bogus use of vCPU 0 in pagetable_dying(). > > Remove the now unnecessary domain/vCPU parameters from the wrapper/hook > functions at the same time. > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -4895,10 +4895,12 @@ long do_hvm_op(unsigned long op, XEN_GUE > return -ESRCH; > > rc = -EINVAL; > -if ( is_hvm_domain(d) && paging_mode_shadow(d) ) > +if ( unlikely(d != current->domain) ) > +rc = -EOPNOTSUPP; > +else if ( is_hvm_domain(d) && paging_mode_shadow(d) ) > rc = xsm_hvm_param(XSM_TARGET, d, op); As we're switching to current-only, shouldn't this turn to XSM_HOOK ? Everything else LGTM, with one small suggestion > if ( !rc ) > -pagetable_dying(d, a.gpa); > +pagetable_dying(a.gpa); > > rcu_unlock_domain(d); > break; > --- a/xen/include/asm-x86/paging.h > +++ b/xen/include/asm-x86/paging.h > @@ -345,7 +345,7 @@ void paging_write_p2m_entry(struct p2m_d > > /* Called from the guest to indicate that the a process is being > * torn down and its pagetables will soon be discarded */ > -void pagetable_dying(struct domain *d, paddr_t gpa); > +void pagetable_dying(paddr_t gpa); Fix the comment style while in this area? ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] fix uninitialized variable error in do_poll()
>>> On 05.10.18 at 13:43, wrote: > On 05/10/18 12:25, Wei Liu wrote: >> On Fri, Oct 05, 2018 at 05:22:29AM -0600, Jan Beulich wrote: >> On 05.10.18 at 12:28, wrote: On Fri, Oct 05, 2018 at 04:12:10AM -0600, Jan Beulich wrote: > Now that CONFIG_HVM can (and should) be turned off for the shim, gcc 8.2 > apparently is no longer sure that "port" is indeed initialized at > > if ( sched_poll->nr_ports == 1 ) > v->poll_evtchn = port; > > It doesn't look to be impossible for the compiler to prove it is not, > but we also can't rely on that to be the case. Add an initializer. > > Signed-off-by: Jan Beulich TBH I fail to see how CONFIG_HVM would affect do_poll. Also there is already build test with gcc 8.2 which never discovered the issue you described. >>> I can't explain the sudden diagnostic too (without taking apart what >>> exactly the compiler does), but the same config (just with HVM=y) >>> built fine before. Without any further insight (which I don't think is >>> worth the time) I don't see how I could improve the description. >> Oh well. >> >> Acked-by: Wei Liu > > TBH, I'm not sure that relying on DCE is a good longterm option. Well, we'll have too see how well it fares. If we get into increasing trouble, we may indeed want to ... > It will almost certainly break the build at -O0, ... allow for this. > and our code really should build at all optimisation levels. I'd say it is us to establish how much optimization we want to support being enabled. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v14 4/9] iommu: don't domain_crash() inside iommu_map/unmap_page()
> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 05 October 2018 12:18 > To: George Dunlap ; Paul Durrant > > Cc: Andrew Cooper ; Ian Jackson > ; Wei Liu ; Stefano > Stabellini ; xen-devel de...@lists.xenproject.org>; Konrad Rzeszutek Wilk > ; Tim (Xen.org) > Subject: RE: [Xen-devel] [PATCH v14 4/9] iommu: don't domain_crash() > inside iommu_map/unmap_page() > > >>> On 05.10.18 at 12:38, wrote: > >> From: George Dunlap > >> Sent: 05 October 2018 11:35 > >> > >> > On Oct 5, 2018, at 11:27 AM, Paul Durrant > >> wrote: > >> > But for mapping too? It seems unnecessary to crash the domain in that > >> case. > >> > >> ISTR that the domain_crash() was added only a few years ago; I’d have > to > >> go back and see the reasoning for it being added in the first place. > I’ll > >> do that Monday if Jan doesn’t beat me to it. > >> > > > > I was added by the following commit: > > > > commit 834c97baebb3743c54bcae228e984ae1b9692e6a > > Author: Quan Xu > > Date: Tue Jun 14 15:10:57 2016 +0200 > > > > IOMMU: handle IOMMU mapping and unmapping failures > > > > Treat IOMMU mapping and unmapping failures as a fatal to the DomU > > If IOMMU mapping and unmapping failed, crash the DomU and propagate > > the error up to the call trees. > > > > No spamming of the log can occur. For DomU, we avoid logging any > > message for already dying domains. For Dom0, that'll still be more > > verbose than we'd really like, but it at least wouldn't outright > > flood the console. > > > > Signed-off-by: Quan Xu > > Reviewed-by: Kevin Tian > > Reviewed-by: Jan Beulich > > > > So the justification appears to be to avoid log spam. > > Iirc that part of the description only exists because early version of > that patch did introduce log spam. > > The problem iirc is mainly proper error handling, in particular proper > unwinding of earlier mappings that may have got installed > successfully in the context of the same hypercall (or whatever). > Ok. In the interest of making progress let's just drop this patch altogether. I'll add a patch to introduce a no-crash variant for map into my series implementing PV-IOMMU. Paul > Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] fix uninitialized variable error in do_poll()
On 05/10/18 12:25, Wei Liu wrote: > On Fri, Oct 05, 2018 at 05:22:29AM -0600, Jan Beulich wrote: > On 05.10.18 at 12:28, wrote: >>> On Fri, Oct 05, 2018 at 04:12:10AM -0600, Jan Beulich wrote: Now that CONFIG_HVM can (and should) be turned off for the shim, gcc 8.2 apparently is no longer sure that "port" is indeed initialized at if ( sched_poll->nr_ports == 1 ) v->poll_evtchn = port; It doesn't look to be impossible for the compiler to prove it is not, but we also can't rely on that to be the case. Add an initializer. Signed-off-by: Jan Beulich >>> TBH I fail to see how CONFIG_HVM would affect do_poll. Also there is >>> already build test with gcc 8.2 which never discovered the issue you >>> described. >> I can't explain the sudden diagnostic too (without taking apart what >> exactly the compiler does), but the same config (just with HVM=y) >> built fine before. Without any further insight (which I don't think is >> worth the time) I don't see how I could improve the description. > Oh well. > > Acked-by: Wei Liu TBH, I'm not sure that relying on DCE is a good longterm option. It will almost certainly break the build at -O0, and our code really should build at all optimisation levels. (There is still a fair chunk of work to make -O3 work, which I haven't got time for atm). ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] One-off crash on staging d36b770458
On Fri, Oct 05, 2018 at 05:35:13AM -0600, Jan Beulich wrote: > >>> On 05.10.18 at 12:48, wrote: > > Let me know what else is needed. > > The simple addition on top of what Andrew has said: A reliable > repro ;-) If I had managed to find one I would have debugged this myself. :-) Wei. > > Jan > > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
