[Xen-devel] [ovmf test] 129526: regressions - FAIL

[osstest service owner]

flight 129526 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129526/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 129475
 build-amd64   6 xen-buildfail REGR. vs. 129475
 build-i3866 xen-buildfail REGR. vs. 129475
 build-i386-xsm6 xen-buildfail REGR. vs. 129475

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf 328409ce8de7f318ee9c929b64302bd361cd1dbd
baseline version:
 ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188

Last test of basis   129475  2018-11-05 21:13:11 Z1 days
Testing same since   129526  2018-11-06 20:49:26 Z0 days1 attempts


People who touched revisions under test:
  Fu Siyuan 
  Jiaxin Wu 
  Wu Jiaxin 
  yuchenlin 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit 328409ce8de7f318ee9c929b64302bd361cd1dbd
Author: yuchenlin 
Date:   Fri Nov 2 11:24:01 2018 +0800

Revert "OvmfPkg: VMWare SVGA display device register definitions"

This reverts commit 9bcca53fe466cdff397578328d9d87d257aba493.

We reverted VMWare SVGA driver. We don't need these definitions too.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: yuchenlin 
Reviewed-by: Laszlo Ersek 
Regression-tested-by: Laszlo Ersek 

commit 438ada5aa5a1174940795678c2dae07cde8f3869
Author: yuchenlin 
Date:   Fri Nov 2 11:24:00 2018 +0800

Revert "OvmfPkg/QemuVideoDxe: Helper functions for unaligned port I/O."

This reverts commit 05a5379458725234de8a05780fcb5da2c12680e4.

The VMWare SVGA display device implemented by Qemu (-vga vmware) uses
an I/O-type BAR which is laid out such that some register offsets are
not aligned to the read/write width with which they are expected to be
accessed. However, we reverted the initialization of VMWare SVGA device,
we don't need such unaligned I/O.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: yuchenlin 
Reviewed-by: Laszlo Ersek 
Regression-tested-by: Laszlo Ersek 

commit 98856a724c2acdc0094220d4de615a557dad0f88
Author: yuchenlin 
Date:   Fri Nov 2 11:23:59 2018 +0800

Revert "OvmfPkg/QemuVideoDxe: VMWare SVGA device support"

This reverts commit c137d95081690d4877fbeb5f1856972e84ac32f2.

The VMWare SVGA model now -- since commit 104bd1dc70 in QEMU --
falls back to stdvga (that is, Bochs) if we don't setup VMWare SVGA
FIFO.

To simplify QemuVideoDxe, we don't intend to implement the VMWare SVGA
FIFO setup feature. It means our current VMW SVGA driver code is
basically dead. To simplify the problem, we will replace the old
VMWare SVGA driver to Bochs interface. It should work on all QEMU
version.

The first step for using Bochs interface is to revert old driver.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: yuchenlin 
Reviewed-by: Laszlo Ersek 
Regression-tested-by: Laszlo Ersek 

commit e038bde2679bbd200086c25ab43090ad3b8b25a3
Author: yuchenlin 
Date:   Fri Nov 2 11:23:58 2018 

Re: [Xen-devel] [PATCH v8 1/8] xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing

[Jan Beulich]

>>> On 06.11.18 at 23:42,  wrote:
> On Tue, 9 Oct 2018, Jan Beulich wrote:
>> >>> On 09.10.18 at 01:37,  wrote:
>> > --- a/xen/include/xsm/dummy.h
>> > +++ b/xen/include/xsm/dummy.h
>> > @@ -535,6 +535,20 @@ static XSM_INLINE int 
>> > xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain *d, str
>> >  return xsm_default_action(action, d, t);
>> >  }
>> >  
>> > +/*
>> > + * Be aware that this is not an exact default equivalence of its flask
>> > + * variant which also checks if @d and @t "are allowed to share memory
>> > + * pages", for now, we don't have a proper default equivalence of such a
>> > + * check.
>> > + */
>> > +static XSM_INLINE int xsm_map_gmfn_share(XSM_DEFAULT_ARG struct domain *d,
>> > + struct domain *t)
>> > +{
>> > +XSM_ASSERT_ACTION(XSM_TARGET);
>> > +return xsm_default_action(XSM_TARGET, current->domain, d) ?:
>> > +   xsm_default_action(action, current->domain, t);
>> > +}
>> 
>> Does this (specifically xsm/dummy.c)) build with XSM enabled?
>> Afaict "action" is going to be an undefined symbol in that case.
> 
> I tried it and it does build OK

Oh, I see - that because of the way XSM_ASSERT_ACTION() is
defined in that case. It's in fact the other way around: For
consistency with other code, you shouldn't use literal
XSM_TARGET in the first function invocation.

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-4.9-testing test] 129461: tolerable FAIL - PUSHED

[osstest service owner]

flight 129461 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129461/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop   fail blocked in 129090
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 128966
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 128977
 test-amd64-amd64-xl-qemut-ws16-amd64 14 guest-localmigratefail like 129090
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 129090
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 129090
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 129090
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 129090
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 129090
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 129090
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 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-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail 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-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail 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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   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  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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   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-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-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:
 xen  1bd7c17c5e976fec4ad0d8ba785ac78f36eef628
baseline version:
 xen  f294d80e8e43d4cdcc6d4d94b1e9c9b1aadf67d8

Last test of basis   129090  2018-10-28 10:17:24 Z9 days
Testing same since   129461  2018-11-05 14:36:46 Z1 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Kevin Tian 
  Paul Durrant 
  Sergey Dyasli 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  

[Xen-devel] [xen-4.10-testing test] 129462: tolerable FAIL - PUSHED

[osstest service owner]

flight 129462 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129462/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 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-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-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-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   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-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail 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-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  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-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   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-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail 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-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail 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:
 xen  5b15c049b526eadc9bee975a1188260e3543313d
baseline version:
 xen  73788eb585a6dc0d0cfe18b03ba5154f8fe5c468

Last test of basis   128983  2018-10-26 01:21:38 Z   12 days
Testing same since   129462  2018-11-05 14:36:46 Z1 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Kevin Tian 
  Paul Durrant 
  Sergey Dyasli 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 

[Xen-devel] [linux-linus test] 129460: regressions - FAIL

[osstest service owner]

flight 129460 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129460/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 
125898
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 125898
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-xl-qemut-debianhvm-amd64  7 xen-bootfail REGR. vs. 125898
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 125898
 test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
125898
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-xl-qemut-win7-amd64  7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
125898
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 125898
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 125898
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  7 xen-bootfail REGR. vs. 125898
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
125898
 test-amd64-amd64-xl-credit2   7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 125898
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 125898
 test-amd64-amd64-xl-qemut-win10-i386  7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-xl   7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 
125898
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 125898
 test-amd64-amd64-xl-qemuu-win10-i386  7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-qemuu-nested-amd  7 xen-bootfail REGR. vs. 125898
 test-amd64-amd64-xl-pvhv2-amd  7 xen-bootfail REGR. vs. 125898
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 125898
 test-amd64-amd64-xl-qemut-ws16-amd64  7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail 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-pair10 xen-boot/src_hostfail REGR. vs. 125898
 test-amd64-amd64-libvirt-vhd  7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-xl-qemuu-win7-amd64  7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-rumprun-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-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 125898
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 125898
 test-amd64-amd64-libvirt-xsm  7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 125898
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 125898
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-libvirt   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-pair 10 xen-boot/src_hostfail REGR. vs. 125898
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 125898
 

Re: [Xen-devel] Porting XEN hypervisor on iMX8QM

[Peng Fan]

Hi Ravi,

You could find code here
https://source.codeaurora.org/external/imx/imx-xen/

The latest public branch should be 
https://source.codeaurora.org/external/imx/imx-xen/log/?h=imx_4.14.62_1.0.0_beta
 but this has not gone through test, you could take as reference. We have some 
new code still not public now. 

Regards,
Peng.
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 2018年11月7日 3:06
> To: Stefano Stabellini ; Ravi Pichholiya
> 
> Cc: xen-de...@lists.xen.org; Peng Fan 
> Subject: Re: Porting XEN hypervisor on iMX8QM
> 
> Hi,
> 
> I am CCing Peng Fan who is working for NXP and also on Xen. Peng, do you have
> any pointer to getting Xen running on iMX8QM?
> 
> Cheers,
> 
> On 06/11/2018 18:59, Stefano Stabellini wrote:
> > Hi Ravi,
> >
> > Please have a look at our wiki as a reference:
> > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki
> > .xenproject.org%2Fwiki%2FXen_ARM_with_Virtualization_Extensionsd
> a
> >
> ta=02%7C01%7Cpeng.fan%40nxp.com%7C29f2e7554eeb4239e2be08d6441ae9
> e7%7C6
> >
> 86ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636771279731653739
> p;sdata
> >
> =FLKtTp%2FaAk6B7Suv0vUttF04z%2BLo1Gw%2FmaI5p9RV%2BZE%3Dre
> served=0
> >
> > I would start from cross-compiling the Xen hypervisor (the xen/
> > directory), no need to build the Xen userspace tools initially.
> > Make sure to have the right early boot uart driver, see
> > CONFIG_EARLY_PRINTK and docs/misc/arm/early-printk.txt.
> >
> > After you boot the Xen binary from uboot, you should be able to see
> > some console output from the hypervisror. The step after that is
> > booting Dom0.
> >
> > Cheers,
> >
> > Stefano
> >
> > On Mon, 5 Nov 2018, Ravi Pichholiya wrote:
> >> Hi Stefano,
> >> This is in reference to our LinkedIn discussion, in our one of the project 
> >> we
> need to port XEN hypervisor on iMx8QM.
> >>
> >> Request you to share what all visibility we should require from boot
> >> prospective as currently we are having access to Device tree and U-boot
> source code only. Is access to any other files are also required?
> >>
> >> Also some reference to start with the porting of XEN if available with you.
> >>
> >> Thanks & Regards,
> >> Ravi Pichholiya
> >>
> 
> --
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v8 8/8] xen/arm: map reserved-memory regions as normal memory in dom0

[Stefano Stabellini]

On Mon, 22 Oct 2018, Julien Grall wrote:
> Hi,
> 
> On 09/10/2018 00:37, Stefano Stabellini wrote:
> > reserved-memory regions should be mapped as normal memory.
> 
> This is already the case with p2m_mmio_direct_c. The hardware domain should
> have full control on the resulting attributes via its stage-1 mappings. So
> what's wrong with that p2m type?

Shared mappings are prevented for any types other than p2m_ram_rw, see
the p2m_is_ram checks in the implementation of XENMAPSPACE_gmfn_share.

The alternative is to remove or extend the p2m_is_ram check at
xen/arch/arm/mm.c:1283


> >  At the
> > moment, they get remapped as device memory because Xen doesn't know
> > better. Add an explicit check for it.
> > 
> > Signed-off-by: Stefano Stabellini 
> > ---
> >   xen/arch/arm/domain_build.c | 7 +++
> >   1 file changed, 7 insertions(+)
> > 
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index f552154..c7df4cf 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -1307,6 +1307,13 @@ static int __init handle_node(struct domain *d,
> > struct kernel_info *kinfo,
> >  "WARNING: Path %s is reserved, skip the node as we may
> > re-use the path.\n",
> >  path);
> >   +/*
> > + * reserved-memory ranges should be mapped as normal memory in the
> > + * p2m.
> > + */
> > +if ( !strcmp(dt_node_name(node), "reserved-memory") )
> > +p2mt = p2m_ram_rw;
> > +
> >   res = handle_device(d, node, p2mt);
> >   if ( res)
> >   return res;
> > 
> 
> -- 
> Julien Grall
> 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [ovmf baseline-only test] 75576: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 75576 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75576/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install  fail like 75574
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75574

version targeted for testing:
 ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188
baseline version:
 ovmf e40f8efb8b06e023689120452e7ed5db199363de

Last test of basis75574  2018-11-06 06:31:58 Z0 days
Testing same since75576  2018-11-06 20:50:42 Z0 days1 attempts


People who touched revisions under test:
  Zhang, Chao B 

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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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


Push not applicable.


commit 5ae3184d8c59f7bbb84bad482df6b8020ba58188
Author: Zhang, Chao B 
Date:   Mon Nov 5 22:19:24 2018 +0800

Maintainer.txt: Add Chao to be co-maintainer of SignedCapsulePkg

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhang, Chao B 
Reviewed-by: Jiewen Yao 
Cc: Jiewen Yao 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v8 1/8] xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing

[Stefano Stabellini]

On Tue, 9 Oct 2018, Jan Beulich wrote:
> >>> On 09.10.18 at 01:37,  wrote:
> > --- a/xen/include/xsm/dummy.h
> > +++ b/xen/include/xsm/dummy.h
> > @@ -535,6 +535,20 @@ static XSM_INLINE int 
> > xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain *d, str
> >  return xsm_default_action(action, d, t);
> >  }
> >  
> > +/*
> > + * Be aware that this is not an exact default equivalence of its flask
> > + * variant which also checks if @d and @t "are allowed to share memory
> > + * pages", for now, we don't have a proper default equivalence of such a
> > + * check.
> > + */
> > +static XSM_INLINE int xsm_map_gmfn_share(XSM_DEFAULT_ARG struct domain *d,
> > + struct domain *t)
> > +{
> > +XSM_ASSERT_ACTION(XSM_TARGET);
> > +return xsm_default_action(XSM_TARGET, current->domain, d) ?:
> > +   xsm_default_action(action, current->domain, t);
> > +}
> 
> Does this (specifically xsm/dummy.c)) build with XSM enabled?
> Afaict "action" is going to be an undefined symbol in that case.

I tried it and it does build OK


> > --- a/xen/xsm/flask/hooks.c
> > +++ b/xen/xsm/flask/hooks.c
> > @@ -1192,6 +1192,14 @@ static int flask_map_gmfn_foreign(struct domain *d, 
> > struct domain *t)
> >  return domain_has_perm(d, t, SECCLASS_MMU, MMU__MAP_READ | 
> > MMU__MAP_WRITE);
> >  }
> >  
> > +static int flask_map_gmfn_share(struct domain *d, struct domain *t)
> > +{
> > +if ( current_has_perm(d, SECCLASS_MMU, MMU__MAP_READ | MMU__MAP_WRITE) 
> > )
> > +return rc;
> > +return current_has_perm(t, SECCLASS_MMU, MMU__MAP_READ | 
> > MMU__MAP_WRITE) ?:
> > +   domain_has_perm(d, t, SECCLASS_MMU, MMU__SHARE_MEM);
> > +}
> > +
> 
> Same here, for "rc". It looks to me as if the first two lines of the function
> body were wrongly left in place anyway. But please could you at least
> build-test with XSM enabled when you make changes to XSM code?

This is a mistake. You are right the two lines need to be removed. I
build-tested it with XSM correctly.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [linux-4.19 bisection] complete test-amd64-amd64-qemuu-nested-intel

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-qemuu-nested-intel
testid debian-hvm-install/l1/l2

Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  dafd936dddbd7978d4131275ad1112f64457bf64
  Bug not present: 1ecb1ee4d8475475c3ccf72f6654644b242ce856
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/129524/


  commit dafd936dddbd7978d4131275ad1112f64457bf64
  Author: George Dunlap 
  Date:   Mon Oct 29 14:51:51 2018 +
  
  Make credit2 the default scheduler
  
  Credit2 was declared "supported" in 4.8, and as of 4.10 had two other
  critical features implemented (soft affinity / NUMA and caps).
  
  Why change the default?
  
  The code is better: more predictable, less jitter, easier to determine
  how modifications will affect overall behavior, easier in the future
  to make load-balancing behavior more subtle (e.g., taking into account
  the cost of powering up extra cores, ).
  
  Overall performance compared to Credit1 is somewhat of a mixed bag.
  Unfortunately most of what I have are tests using XenServer's internal
  perf testing system, so I can't share the raw data (via links anyway).
  
  Here is a summary of data from an internal e-mail Dario sent in the
  past:
  
  * DVDbench: On underloaded systems, credit2 outperformed credit1 by
  about 4%.  On overloaded systems, credit2 underperformed by about 3%.
  
  * On a range of tests (unixbench, lmbench, ), credit and credit2
  perform within 5% of each other (up and down).
  
  * Credit2 fairly consistently beats credit for TCP-style workloads.
  
  * Credit2 is sometimes equal to, sometimes 5-15% worse than, credit for
  synthetic CPU workloads (e.g., Dhrystone).
  
  * On LoginVSI, credit2 fairly consistently outperforms credit by about 
10%.
  
  Credit2, like credit, has a number of workloads / setups for which
  performance could be improved.  Personally I think networking and
  partially-loaded systems is going to be more representative of what
  Xen is actually used for; so I think credit2 is on the whole the
  better scheduler to use by default.  And in any case, making those
  improvements on credit2 will be easier than on credit.
  
  Signed-off-by: George Dunlap 
  Acked-by: Dario Faggioli 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-4.19/test-amd64-amd64-qemuu-nested-intel.debian-hvm-install--l1--l2.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-4.19/test-amd64-amd64-qemuu-nested-intel.debian-hvm-install--l1--l2
 --summary-out=tmp/129524.bisection-summary --basis-template=129313 
--blessings=real,real-bisect linux-4.19 test-amd64-amd64-qemuu-nested-intel 
debian-hvm-install/l1/l2
Searching for failure / basis pass:
 129428 fail [host=elbling0] / 129313 [host=huxelrebe0] template as basis? 
using template as basis.
Failure / basis pass flights: 129428 / 129313
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 07a03b97b9ce2a6430344386eeab9b16283b893f 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
de5b678ca4dcdfa83e322491d478d66df56c1986 
2cf113891a38cc05434bc9876ffc107a990887be
Basis pass 84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 
de5b678ca4dcdfa83e322491d478d66df56c1986 
92666fdd6e0afab989b2d89759d9b43f2c645ae7
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d-07a03b97b9ce2a6430344386eeab9b16283b893f
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149-d0d8ad39ecb51cd7497cd524484fe09f50876798
 
git://xenbits.xen.org/qemu-xen.git#de5b678ca4dcdfa83e322491d478d66df56c1986-de5b678ca4dcdfa83e322491d478d66df56c1986
 

[Xen-devel] [PATCH v3 3/4] xen: introduce SYMBOL

[Stefano Stabellini]

Introduce a macro, SYMBOL, which is a simple wrapper around RELOC_HIDE
to be used everywhere symbols such as _stext and _etext are used in the
code.

RELOC_HIDE is needed when accessing symbols such as _stext and _etext
because the C standard forbids for both comparisons and substraction
(see C Standard, 6.5.6 [ISO/IEC 9899:2011] and [1]).

forbids comparisons between pointers pointing to
different objects. _stext, _etext, etc. are all pointers to different
objects from ANCI C point of view.

To work around potential C compiler issues (which have actually
been found, see the comment on top of RELOC_HIDE in Linux), and to help
with certifications, let's introduce some syntactic sugar to be used in
following patches.

[1] 
https://wiki.sei.cmu.edu/confluence/display/c/ARR36-C.+Do+not+subtract+or+compare+two+pointers+that+do+not+refer+to+the+same+array

Signed-off-by: Stefano Stabellini 
CC: jbeul...@suse.com
CC: andrew.coop...@citrix.com
CC: wei.l...@citrix.com
---
Changes in v3:
- improve commit message
- rename __symbol to SYMBOL to avoid name space violations

Changes in v2:
- do not cast return to char*
- move to common header
---
 xen/include/xen/compiler.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
index ff6c0f5..b3375f6 100644
--- a/xen/include/xen/compiler.h
+++ b/xen/include/xen/compiler.h
@@ -99,6 +99,12 @@
 __asm__ ("" : "=r"(__ptr) : "0"(ptr));  \
 (typeof(ptr)) (__ptr + (off)); })
 
+/*
+ * Use RELOC_HIDE with symbols such as _stext and _etext to avoid errors
+ * on comparing pointers to different objects
+ */
+#define SYMBOL(x) (RELOC_HIDE((unsigned long)(x), 0))
+
 #ifdef __GCC_ASM_FLAG_OUTPUTS__
 # define ASM_FLAG_OUT(yes, no) yes
 #else
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 1/4] xen/arm: initialize target

[Stefano Stabellini]

Initialize variable target before passing it as a parameter.
It makes the code a bit nicer and it is a safety certification
requirement.

M3CM Rule-9.1: The value of an object with automatic storage duration
shall not be read before it has been set

QAVerify: 2972
Signed-off-by: Stefano Stabellini 
---
Changes in v3:
- add more info to commit messagte

Changes in v2:
- improve comment
---
 xen/arch/arm/vgic-v2.c | 2 +-
 xen/arch/arm/vgic-v3.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index f6c11f1..0099fcf 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -379,6 +379,7 @@ static bool vgic_v2_to_sgi(struct vcpu *v, register_t sgir)
 enum gic_sgi_mode sgi_mode;
 struct sgi_target target;
 
+sgi_target_init();
 irqmode = (sgir & GICD_SGI_TARGET_LIST_MASK) >> GICD_SGI_TARGET_LIST_SHIFT;
 virq = (sgir & GICD_SGI_INTID_MASK);
 
@@ -386,7 +387,6 @@ static bool vgic_v2_to_sgi(struct vcpu *v, register_t sgir)
 switch ( irqmode )
 {
 case GICD_SGI_TARGET_LIST_VAL:
-sgi_target_init();
 target.list = (sgir & GICD_SGI_TARGET_MASK) >> GICD_SGI_TARGET_SHIFT;
 sgi_mode = SGI_TARGET_LIST;
 break;
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index efe824c..c14bcd8 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1474,6 +1474,7 @@ static bool vgic_v3_to_sgi(struct vcpu *v, register_t 
sgir)
 enum gic_sgi_mode sgi_mode;
 struct sgi_target target;
 
+sgi_target_init();
 irqmode = (sgir >> ICH_SGI_IRQMODE_SHIFT) & ICH_SGI_IRQMODE_MASK;
 virq = (sgir >> ICH_SGI_IRQ_SHIFT ) & ICH_SGI_IRQ_MASK;
 
@@ -1481,7 +1482,6 @@ static bool vgic_v3_to_sgi(struct vcpu *v, register_t 
sgir)
 switch ( irqmode )
 {
 case ICH_SGI_TARGET_LIST:
-sgi_target_init();
 /* We assume that only AFF1 is used in ICC_SGI1R_EL1. */
 target.aff1 = (sgir >> ICH_SGI_AFFINITY_LEVEL(1)) & ICH_SGI_AFFx_MASK;
 target.list = sgir & ICH_SGI_TARGETLIST_MASK;
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 0/4] misc safety certification fixes

[Stefano Stabellini]

Hi all,

This short patch series fixes a few issues discovered by the safety
certifications code scanner. The first two patches address simple
variable initializations concerns. The third patch introduces a new
macro that is used throughout the code in patch #4 to access _stext,
_etext pointers and friends.

Cheers,

Stefano


Stefano Stabellini (4):
  xen/arm: initialize target
  xen/arm: initialize access
  xen: introduce SYMBOL
  xen: use SYMBOL everywhere

 xen/arch/arm/alternative.c  |  7 ++--
 xen/arch/arm/arm32/livepatch.c  |  2 +-
 xen/arch/arm/arm64/livepatch.c  |  2 +-
 xen/arch/arm/domain_build.c |  2 +-
 xen/arch/arm/livepatch.c|  6 +--
 xen/arch/arm/mem_access.c   |  1 +
 xen/arch/arm/mm.c   | 17 
 xen/arch/arm/setup.c|  8 ++--
 xen/arch/arm/vgic-v2.c  |  2 +-
 xen/arch/arm/vgic-v3.c  |  2 +-
 xen/arch/x86/setup.c| 79 +++--
 xen/arch/x86/tboot.c| 12 +++---
 xen/arch/x86/x86_64/machine_kexec.c |  4 +-
 xen/drivers/vpci/vpci.c |  7 +++-
 xen/include/asm-arm/grant_table.h   |  3 +-
 xen/include/asm-arm/mm.h|  4 +-
 xen/include/asm-x86/mm.h|  4 +-
 xen/include/xen/compiler.h  |  6 +++
 xen/include/xen/kernel.h| 24 +--
 19 files changed, 106 insertions(+), 86 deletions(-)

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 2/4] xen/arm: initialize access

[Stefano Stabellini]

Initialize variable *access before returning it back to the caller.
It makes the code a bit nicer and it is a safety certification
requirement.

M3CM Rule-9.1: The value of an object with automatic storage duration
shall not be read before it has been set

QAVerify: 2962
Signed-off-by: Stefano Stabellini 
Acked-by: Razvan Cojocaru 
CC: rcojoc...@bitdefender.com
CC: Tamas K Lengyel 
---
Changes in v3:
- add more info to commit messagte

Changes in v2:
- improve comment
- use p2m->default_access
---
 xen/arch/arm/mem_access.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
index ba4ec78..86f0882 100644
--- a/xen/arch/arm/mem_access.c
+++ b/xen/arch/arm/mem_access.c
@@ -47,6 +47,7 @@ static int __p2m_get_mem_access(struct domain *d, gfn_t gfn,
 };
 
 ASSERT(p2m_is_locked(p2m));
+*access = p2m->default_access;
 
 /* If no setting was ever set, just return rwx. */
 if ( !p2m->mem_access_enabled )
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 4/4] xen: use SYMBOL everywhere

[Stefano Stabellini]

Use SYMBOL everywhere _stext, _etext, etc. are used. Technically, it
is required when comparing and subtracting pointers [1], but use it
everywhere to avoid confusion.

M3CM: Rule-18.2: Subtraction between pointers shall only be applied to
pointers that address elements of the same array

[1] 
https://wiki.sei.cmu.edu/confluence/display/c/ARR36-C.+Do+not+subtract+or+compare+two+pointers+that+do+not+refer+to+the+same+array

QAVerify: 2761 (and many others)
Signed-off-by: Stefano Stabellini 
CC: jbeul...@suse.com
CC: andrew.coop...@citrix.com
---
Changes in v3:
- improve commit message
- no hard tabs
- rename __symbol to SYMBOL
- fix __end_vpci_array and __start_vpci_array
- avoid all comparisons between pointers: including (void *) casted
  returns from SYMBOL()
- remove useless casts to (unsigned long)

Changes in v2:
- cast return of SYMBOL to char* when required
- define __pa as unsigned long in is_kernel* functions
---
 xen/arch/arm/alternative.c  |  7 ++--
 xen/arch/arm/arm32/livepatch.c  |  2 +-
 xen/arch/arm/arm64/livepatch.c  |  2 +-
 xen/arch/arm/domain_build.c |  2 +-
 xen/arch/arm/livepatch.c|  6 +--
 xen/arch/arm/mm.c   | 17 
 xen/arch/arm/setup.c|  8 ++--
 xen/arch/x86/setup.c| 79 +++--
 xen/arch/x86/tboot.c| 12 +++---
 xen/arch/x86/x86_64/machine_kexec.c |  4 +-
 xen/drivers/vpci/vpci.c |  7 +++-
 xen/include/asm-arm/grant_table.h   |  3 +-
 xen/include/asm-arm/mm.h|  4 +-
 xen/include/asm-x86/mm.h|  4 +-
 xen/include/xen/kernel.h| 24 +--
 15 files changed, 97 insertions(+), 84 deletions(-)

diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index 52ed7ed..2efa9ca 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -187,8 +187,8 @@ static int __apply_alternatives_multi_stop(void *unused)
 {
 int ret;
 struct alt_region region;
-mfn_t xen_mfn = virt_to_mfn(_start);
-paddr_t xen_size = _end - _start;
+mfn_t xen_mfn = virt_to_mfn(SYMBOL(_start));
+paddr_t xen_size = SYMBOL(_end) - SYMBOL(_start);
 unsigned int xen_order = get_order_from_bytes(xen_size);
 void *xenmap;
 
@@ -206,7 +206,8 @@ static int __apply_alternatives_multi_stop(void *unused)
 region.begin = __alt_instructions;
 region.end = __alt_instructions_end;
 
-ret = __apply_alternatives(, xenmap - (void *)_start);
+ret = __apply_alternatives(,
+   (unsigned long)xenmap - SYMBOL(_start));
 /* The patching is not expected to fail during boot. */
 BUG_ON(ret != 0);
 
diff --git a/xen/arch/arm/arm32/livepatch.c b/xen/arch/arm/arm32/livepatch.c
index 41378a5..6bf9132 100644
--- a/xen/arch/arm/arm32/livepatch.c
+++ b/xen/arch/arm/arm32/livepatch.c
@@ -56,7 +56,7 @@ void arch_livepatch_apply(struct livepatch_func *func)
 else
 insn = 0xe1a0; /* mov r0, r0 */
 
-new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
+new_ptr = func->old_addr - (void *)SYMBOL(_start) + vmap_of_xen_text;
 len = len / sizeof(uint32_t);
 
 /* PATCH! */
diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
index 2247b92..fb1477d 100644
--- a/xen/arch/arm/arm64/livepatch.c
+++ b/xen/arch/arm/arm64/livepatch.c
@@ -43,7 +43,7 @@ void arch_livepatch_apply(struct livepatch_func *func)
 /* Verified in livepatch_verify_distance. */
 ASSERT(insn != AARCH64_BREAK_FAULT);
 
-new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
+new_ptr = func->old_addr - SYMBOL(_start) + vmap_of_xen_text;
 len = len / sizeof(uint32_t);
 
 /* PATCH! */
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f552154..6c03996 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2090,7 +2090,7 @@ static void __init find_gnttab_region(struct domain *d,
  * Only use the text section as it's always present and will contain
  * enough space for a large grant table
  */
-kinfo->gnttab_start = __pa(_stext);
+kinfo->gnttab_start = __pa(SYMBOL(_stext));
 kinfo->gnttab_size = gnttab_dom0_frames() << PAGE_SHIFT;
 
 #ifdef CONFIG_ARM_32
diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 279d52c..609ab35 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -26,8 +26,8 @@ int arch_livepatch_quiesce(void)
 if ( vmap_of_xen_text )
 return -EINVAL;
 
-text_mfn = virt_to_mfn(_start);
-text_order = get_order_from_bytes(_end - _start);
+text_mfn = virt_to_mfn(SYMBOL(_start));
+text_order = get_order_from_bytes(SYMBOL(_end) - SYMBOL(_start));
 
 /*
  * The text section is read-only. So re-map Xen to be able to patch
@@ -78,7 +78,7 @@ void arch_livepatch_revert(const struct livepatch_func *func)
 

Re: [Xen-devel] [PATCH v2 4/4] xen: use __symbol everywhere

[Stefano Stabellini]

On Wed, 17 Oct 2018, Julien Grall wrote:
> Hi,
> 
> On 17/10/2018 15:31, Stefano Stabellini wrote:
> > Use __symbol everywhere _stext, _etext, etc. are used. Technically, it
> > is only required when comparing pointers, but use it everywhere to avoid
> 
> Well no. It is also required when substracting pointers (see [1]).
> 
> > confusion.
> 
> [...]
> 
> > diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
> > index 52ed7ed..305b337 100644
> > --- a/xen/arch/arm/alternative.c
> > +++ b/xen/arch/arm/alternative.c
> > @@ -187,8 +187,8 @@ static int __apply_alternatives_multi_stop(void *unused)
> >   {
> >   int ret;
> >   struct alt_region region;
> > -mfn_t xen_mfn = virt_to_mfn(_start);
> > -paddr_t xen_size = _end - _start;
> > +mfn_t xen_mfn = virt_to_mfn(__symbol(_start));
> > +paddr_t xen_size = __symbol(_end) - __symbol(_start);
> >   unsigned int xen_order = get_order_from_bytes(xen_size);
> >   void *xenmap;
> >   @@ -206,7 +206,7 @@ static int __apply_alternatives_multi_stop(void
> > *unused)
> >   region.begin = __alt_instructions;
> >   region.end = __alt_instructions_end;
> >   -ret = __apply_alternatives(, xenmap - (void *)_start);
> > +ret = __apply_alternatives(, xenmap - (void
> > *)__symbol(_start));
> 
> For instance, I think this line would be contain undefined behavior. There are
> probably others below.

I'll fix


> [...]
> 
> > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> > index 7a06a33..d9d3948 100644
> > --- a/xen/arch/arm/mm.c
> > +++ b/xen/arch/arm/mm.c
> > @@ -620,7 +620,7 @@ void __init setup_pagetables(unsigned long
> > boot_phys_offset, paddr_t xen_paddr)
> >   int i;
> > /* Calculate virt-to-phys offset for the new location */
> > -phys_offset = xen_paddr - (unsigned long) _start;
> > +phys_offset = xen_paddr - (unsigned long) __symbol(_start);
> > #ifdef CONFIG_ARM_64
> >   p = (void *) xen_pgtable;
> > @@ -681,7 +681,8 @@ void __init setup_pagetables(unsigned long
> > boot_phys_offset, paddr_t xen_paddr)
> >   ttbr = (uintptr_t) cpu0_pgtable + phys_offset;
> >   #endif
> >   -relocate_xen(ttbr, _start, (void*)dest_va, _end - _start);
> > +relocate_xen(ttbr, (void*)__symbol(_start), (void*)dest_va,
> > +__symbol(_end) - __symbol(_start));
> 
> No hard tab.
> 
> [...]
> 
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index ea2495a..9d0b915 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -394,7 +394,8 @@ static paddr_t __init get_xen_paddr(void)
> >   paddr_t paddr = 0;
> >   int i;
> >   -min_size = (_end - _start + (XEN_PADDR_ALIGN-1)) &
> > ~(XEN_PADDR_ALIGN-1);
> > +min_size = (__symbol(_end) - __symbol(_start) +
> > +  (XEN_PADDR_ALIGN-1)) & ~(XEN_PADDR_ALIGN-1);
> > /* Find the highest bank with enough space. */
> >   for ( i = 0; i < mi->nr_banks; i++ )
> > @@ -727,8 +728,9 @@ void __init start_xen(unsigned long boot_phys_offset,
> > /* Register Xen's load address as a boot module. */
> >   xen_bootmodule = add_boot_module(BOOTMOD_XEN,
> > - (paddr_t)(uintptr_t)(_start +
> > boot_phys_offset),
> > - (paddr_t)(uintptr_t)(_end - _start + 1),
> > NULL);
> > + (paddr_t)(uintptr_t)(__symbol(_start) +
> > boot_phys_offset),
> > + (paddr_t)(uintptr_t)(__symbol(_end) -
> > +
> > __symbol(_start) + 1), NULL);
> 
> No hard tab.
> 
> >   BUG_ON(!xen_bootmodule);
> > xen_paddr = get_xen_paddr();
> > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> > index 93b79c7..0a7d6c0 100644
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> 
> [...]
> 
> > @@ -1390,22 +1393,22 @@ void __init noreturn __start_xen(unsigned long
> > mbi_p)
> >   {
> >   /* Mark .text as RX (avoiding the first 2M superpage). */
> >   modify_xen_mappings(XEN_VIRT_START + MB(2),
> > -(unsigned long)&__2M_text_end,
> > +(unsigned long)__symbol(&__2M_text_end),
> >   PAGE_HYPERVISOR_RX);
> > /* Mark .rodata as RO. */
> > -modify_xen_mappings((unsigned long)&__2M_rodata_start,
> > -(unsigned long)&__2M_rodata_end,
> > +modify_xen_mappings((unsigned long)__symbol(&__2M_rodata_start),
> > +(unsigned long)__symbol(&__2M_rodata_end),
> 
> AFAICT the return of __symbol should be unsigned long, right? If so, the cast
> could be removed.

I'll fix


> Cheers,
> 
> [1]
> https://wiki.sei.cmu.edu/confluence/display/c/ARR36-C.+Do+not+subtract+or+compare+two+pointers+that+do+not+refer+to+the+same+array
> 
> -- 
> Julien Grall
> 

___
Xen-devel mailing list

Re: [Xen-devel] [PATCH 4/4] xen: use __symbol everywhere

[Stefano Stabellini]

On Thu, 25 Oct 2018, Jan Beulich wrote:
> >>> On 15.10.18 at 11:56,  wrote:
> > Use __symbol everywhere _stext, _etext, etc. are used. Technically, it
> > is only required when comparing pointers, but use it everywhere to avoid
> > confusion.
> 
> While the description slightly limits the scope, I'm not sure that's what
> you mean. What about e.g. __{start,end}_vpci_array? If you say
> "everywhere" in the title, then please change everything.

I forgot about that one, I'll fix it

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Dom0 kernel 4.14 with SMP randomly crashing

[Rishi]

On Wed, Nov 7, 2018 at 12:16 AM Rishi <2rushike...@gmail.com> wrote:

>
>
> On Tue, Nov 6, 2018 at 10:41 PM Rishi <2rushike...@gmail.com> wrote:
>
>>
>>
>> On Tue, Nov 6, 2018 at 5:47 PM Wei Liu  wrote:
>>
>>> On Tue, Nov 06, 2018 at 03:31:31PM +0530, Rishi wrote:
>>> >
>>> > So after knowing the stack trace, it appears that the CPU was getting
>>> stuck
>>> > for xen_hypercall_xen_version
>>>
>>> That hypercall is used when a PV kernel (re-)enables interrupts. See
>>> xen_irq_enable. The purpose is to force the kernel to switch to
>>> hypervisor.
>>>
>>> >
>>> > watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [swapper/0:0]
>>> >
>>> >
>>> > [30569.582740] watchdog: BUG: soft lockup - CPU#0 stuck for 23s!
>>> > [swapper/0:0]
>>> >
>>> > [30569.588186] Kernel panic - not syncing: softlockup: hung tasks
>>> >
>>> > [30569.591307] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G L
>>>   4.19.1
>>> > #1
>>> >
>>> > [30569.595110] Hardware name: Xen HVM domU, BIOS 4.4.1-xs132257
>>> 12/12/2016
>>> >
>>> > [30569.598356] Call Trace:
>>> >
>>> > [30569.599597]  
>>> >
>>> > [30569.600920]  dump_stack+0x5a/0x73
>>> >
>>> > [30569.602998]  panic+0xe8/0x249
>>> >
>>> > [30569.604806]  watchdog_timer_fn+0x200/0x230
>>> >
>>> > [30569.607029]  ? softlockup_fn+0x40/0x40
>>> >
>>> > [30569.609246]  __hrtimer_run_queues+0x133/0x270
>>> >
>>> > [30569.611712]  hrtimer_interrupt+0xfb/0x260
>>> >
>>> > [30569.613800]  xen_timer_interrupt+0x1b/0x30
>>> >
>>> > [30569.616972]  __handle_irq_event_percpu+0x69/0x1a0
>>> >
>>> > [30569.619831]  handle_irq_event_percpu+0x30/0x70
>>> >
>>> > [30569.622382]  handle_percpu_irq+0x34/0x50
>>> >
>>> > [30569.625048]  generic_handle_irq+0x1e/0x30
>>> >
>>> > [30569.627216]  __evtchn_fifo_handle_events+0x163/0x1a0
>>> >
>>> > [30569.629955]  __xen_evtchn_do_upcall+0x41/0x70
>>> >
>>> > [30569.632612]  xen_evtchn_do_upcall+0x27/0x50
>>> >
>>> > [30569.635136]  xen_do_hypervisor_callback+0x29/0x40
>>> >
>>> > [30569.638181] RIP: e030:xen_hypercall_xen_version+0xa/0x20
>>>
>>> What is the asm code for this RIP?
>>>
>>>
>>> Wei.
>>>
>>
>> The issue of crash is getting resolved with appending "noirqbalance" at
>> xen command line. This way all dom0 cpus are available but not irq balanced
>> at xen.
>>
>> Even though I'm running irqbalance service in dom0 the irqs seems to be
>> not moving. <- this is dom0 perspective, I do not know yet, if it follows
>> Xen irq.
>>
>> I tried objdump, while I have  have the function in out but there is no
>> asm code of it. Its just "..."
>>
>> 81001220 :
>>
>> ...
>>
>>
>> 81001240 :
>>
>> ...
>>
>> All "hypercalls" appear similarly.
>>
>
> How frequent can be that hypercall/xen_irq_enable()? Like n/s or once a
> while?
> During my tests, the system runs stable unless I'm downloading a large
> file. Files around a GB size are getting downloaded without crash, but
> system crash comes when its above it. I'm using a 2.1GB file & wget to
> download.
>
> Is there a way I can simulate PV kernel (re-)enable of interrupt using a
> kernel module with a controlled fashion?
>

If this is on right track

8101ab70 :

8101ab70:   31 ff   xor%edi,%edi

8101ab72:   31 f6   xor%esi,%esi

8101ab74:   e8 a7 66 fe ff  callq  81001220


8101ab79:   c3  retq

8101ab7a:   66 0f 1f 44 00 00   nopw   0x0(%rax,%rax,1)

It seems I'm hitting following code from xen_irq_enable

barrier(); /* unmask then check (avoid races) */

if (unlikely(vcpu->evtchn_upcall_pending))
xen_force_evtchn_callback();

The code says unlikely yet, it is being called, And I got following
structure

struct vcpu_info {

/*

 * 'evtchn_upcall_pending' is written non-zero by Xen to indicate

 * a pending notification for a particular VCPU. It is then cleared

 * by the guest OS /before/ checking for pending work, thus avoiding

 * a set-and-check race. Note that the mask is only accessed by Xen

 * on the CPU that is currently hosting the VCPU. This means that
the

 * pending and mask flags can be updated by the guest without
special

 * synchronisation (i.e., no need for the x86 LOCK prefix).


 Let me know if the thread is being spammed with such intermediates.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 8/8] xen: Swich parameter in get_page_from_gfn to use typesafe gfn

[Andrew Cooper]

Hi - just some cosmetic suggestions.

Subject s/Swich/Switch/

> diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
> index f73ea4a163..a529ebcc3f 100644
> --- a/xen/arch/x86/pv/emul-priv-op.c
> +++ b/xen/arch/x86/pv/emul-priv-op.c
> @@ -760,12 +760,12 @@ static int write_cr(unsigned int reg, unsigned long val,
>  case 3: /* Write CR3 */
>  {
>  struct domain *currd = curr->domain;
> -unsigned long gfn;
> +gfn_t gfn;
>  struct page_info *page;
>  int rc;
>  
> -gfn = !is_pv_32bit_domain(currd)
> -  ? xen_cr3_to_pfn(val) : compat_cr3_to_pfn(val);
> +gfn = _gfn(!is_pv_32bit_domain(currd)
> +  ? xen_cr3_to_pfn(val) : compat_cr3_to_pfn(val));

Please re-indent.

>  page = get_page_from_gfn(currd, gfn, NULL, P2M_ALLOC);
>  if ( !page )
>  break;
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index 9471d89022..d967e49432 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -817,13 +817,14 @@ int guest_wrmsr_xen(struct vcpu *v, uint32_t idx, 
> uint64_t val)
>  
>  if ( p2m_is_paging(t) )
>  {
> -p2m_mem_paging_populate(d, gmfn);
> +p2m_mem_paging_populate(d, gfn_x(gfn));
>  return X86EMUL_RETRY;
>  }
>  
>  gdprintk(XENLOG_WARNING,
> - "Bad GMFN %lx (MFN %#"PRI_mfn") to MSR %08x\n",
> - gmfn, mfn_x(page ? page_to_mfn(page) : INVALID_MFN), 
> base);
> + "Bad GMFN %#"PRI_gfn" (MFN %#"PRI_mfn") to MSR %08x\n",

GMFN => GFN.

> + gfn_x(gfn), mfn_x(page ? page_to_mfn(page) : 
> INVALID_MFN),
> + base);
>  return X86EMUL_EXCEPTION;
>  }
>  
> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
> index d08c595887..db1ec37610 100644
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -489,18 +489,21 @@ struct page_info *p2m_get_page_from_gfn(struct 
> p2m_domain *p2m, gfn_t gfn,
>  p2m_query_t q);
>  
>  static inline struct page_info *get_page_from_gfn(
> -struct domain *d, unsigned long gfn, p2m_type_t *t, p2m_query_t q)
> +struct domain *d, gfn_t gfn, p2m_type_t *t, p2m_query_t q)
>  {
>  struct page_info *page;
> +mfn_t mfn;
>  
>  if ( paging_mode_translate(d) )
> -return p2m_get_page_from_gfn(p2m_get_hostp2m(d), _gfn(gfn), t, NULL, 
> q);
> +return p2m_get_page_from_gfn(p2m_get_hostp2m(d), gfn, t, NULL, q);
>  
>  /* Non-translated guests see 1-1 RAM / MMIO mappings everywhere */
>  if ( t )
>  *t = likely(d != dom_io) ? p2m_ram_rw : p2m_mmio_direct;
> -page = mfn_to_page(_mfn(gfn));
> -return mfn_valid(_mfn(gfn)) && get_page(page, d) ? page : NULL;
> +
> +mfn = _mfn(gfn_x(gfn));
> +page = mfn_to_page(mfn);
> +return mfn_valid(mfn) && get_page(page, d) ? page : NULL;

This looks like it would be cleaner by not splitting mfn out into a
separate variable.

page = mfn_to_page(_mfn(gfn_x(gfn)));

return mfn_valid(mfn) && get_page(page, d) ? page : NULL;

The only reason this looks odd is because of the mfn => gfn equality,
but we are just beside a comment explaining that we are non-translated.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable-smoke test] 129519: tolerable all pass - PUSHED

[osstest service owner]

flight 129519 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129519/

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  60529dfeca145a8ec00f5813a4c7179f0c1bfb97
baseline version:
 xen  58f904c4cf9fc5a49e7807fd91cd2523fa8dd191

Last test of basis   129512  2018-11-06 15:00:54 Z0 days
Testing same since   129519  2018-11-06 18:02:04 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Roger Pau Monné 
  Sergey Dyasli 
  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
   58f904c4cf..60529dfeca  60529dfeca145a8ec00f5813a4c7179f0c1bfb97 -> smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-qemuu-rhel6hvm-intel

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-qemuu-rhel6hvm-intel
testid xen-boot

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  71e56028173bc84f01456a5679d8be9d681b49f1
  Bug not present: 58a0228707870c8330917f919804986855443a19
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/129520/


  (Revision log too long, omitted.)


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-i386-qemuu-rhel6hvm-intel.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-qemuu-rhel6hvm-intel.xen-boot
 --summary-out=tmp/129520.bisection-summary --basis-template=125898 
--blessings=real,real-bisect linux-linus test-amd64-i386-qemuu-rhel6hvm-intel 
xen-boot
Searching for failure / basis pass:
 129417 fail [host=albana1] / 128945 ok.
Failure / basis pass flights: 129417 / 128945
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 71e56028173bc84f01456a5679d8be9d681b49f1 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
de5b678ca4dcdfa83e322491d478d66df56c1986 
2cf113891a38cc05434bc9876ffc107a990887be
Basis pass 58a0228707870c8330917f919804986855443a19 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 
de5b678ca4dcdfa83e322491d478d66df56c1986 
92666fdd6e0afab989b2d89759d9b43f2c645ae7
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#58a0228707870c8330917f919804986855443a19-71e56028173bc84f01456a5679d8be9d681b49f1
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149-d0d8ad39ecb51cd7497cd524484fe09f50876798
 
git://xenbits.xen.org/qemu-xen.git#de5b678ca4dcdfa83e322491d478d66df56c1986-de5b678ca4dcdfa83e322491d478d66df56c1986
 
git://xenbits.xen.org/xen.git#92666fdd6e0afab989b2d89759d9b43f2c645ae7-2cf113891a38cc05434bc9876ffc107a990887be
adhoc-revtuple-generator: tree discontiguous: linux-2.6
Loaded 2005 nodes in revision graph
Searching for test results:
 128663 pass irrelevant
 128727 pass irrelevant
 128861 pass irrelevant
 128835 pass irrelevant
 128885 pass irrelevant
 128920 pass irrelevant
 128945 pass 58a0228707870c8330917f919804986855443a19 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 
de5b678ca4dcdfa83e322491d478d66df56c1986 
92666fdd6e0afab989b2d89759d9b43f2c645ae7
 128970 fail irrelevant
 129005 fail irrelevant
 129072 fail irrelevant
 129167 fail irrelevant
 129258 fail irrelevant
 129304 fail irrelevant
 129389 fail irrelevant
 129348 fail irrelevant
 129417 fail 71e56028173bc84f01456a5679d8be9d681b49f1 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
de5b678ca4dcdfa83e322491d478d66df56c1986 
2cf113891a38cc05434bc9876ffc107a990887be
 129515 fail 71e56028173bc84f01456a5679d8be9d681b49f1 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
de5b678ca4dcdfa83e322491d478d66df56c1986 
2cf113891a38cc05434bc9876ffc107a990887be
 129502 pass 58a0228707870c8330917f919804986855443a19 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
de5b678ca4dcdfa83e322491d478d66df56c1986 
b72624aad5b00f2f6e976aef4d62eeda83fd0218
 129488 pass 58a0228707870c8330917f919804986855443a19 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 
de5b678ca4dcdfa83e322491d478d66df56c1986 
92666fdd6e0afab989b2d89759d9b43f2c645ae7
 129503 pass 58a0228707870c8330917f919804986855443a19 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
de5b678ca4dcdfa83e322491d478d66df56c1986 
45cb9a4123b5550eb1f84846fe5482acae1c13a3
 129489 fail 71e56028173bc84f01456a5679d8be9d681b49f1 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
de5b678ca4dcdfa83e322491d478d66df56c1986 
2cf113891a38cc05434bc9876ffc107a990887be
 129507 pass 

[Xen-devel] [PATCH 1/8] xen/page_alloc: Move get_pg_owner()/put_pg_owner() from x86 to common code

[Julien Grall]

From: Benjamin Sanda 

get_pg_owner() and put_pg_owner() will be necessary in a follow-up
commit to support xentrace on Arm. So move the helper to common code.

Note that put_pg_owner() has been turned to a macro rather than static
inline because of inter-dependency between includes.

Signed-off-by: Benjamin Sanda 
[julien: Rework commit title / turn put_pg_owner to a macro]
Signed-off-by: Julien Grall 
---
 xen/arch/x86/mm.c   | 42 --
 xen/common/page_alloc.c | 38 ++
 xen/include/xen/mm.h|  3 +++
 3 files changed, 41 insertions(+), 42 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index f043e43ac7..9363e9bd96 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3100,48 +3100,6 @@ static int vcpumask_to_pcpumask(
 }
 }
 
-static struct domain *get_pg_owner(domid_t domid)
-{
-struct domain *pg_owner = NULL, *curr = current->domain;
-
-if ( likely(domid == DOMID_SELF) )
-{
-pg_owner = rcu_lock_current_domain();
-goto out;
-}
-
-if ( unlikely(domid == curr->domain_id) )
-{
-gdprintk(XENLOG_WARNING, "Cannot specify itself as foreign domain\n");
-goto out;
-}
-
-switch ( domid )
-{
-case DOMID_IO:
-pg_owner = rcu_lock_domain(dom_io);
-break;
-case DOMID_XEN:
-pg_owner = rcu_lock_domain(dom_xen);
-break;
-default:
-if ( (pg_owner = rcu_lock_domain_by_id(domid)) == NULL )
-{
-gdprintk(XENLOG_WARNING, "Unknown domain d%d\n", domid);
-break;
-}
-break;
-}
-
- out:
-return pg_owner;
-}
-
-static void put_pg_owner(struct domain *pg_owner)
-{
-rcu_unlock_domain(pg_owner);
-}
-
 long do_mmuext_op(
 XEN_GUEST_HANDLE_PARAM(mmuext_op_t) uops,
 unsigned int count,
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 16e1b0c357..ef1b4f596a 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -146,6 +146,7 @@
 #include 
 #include 
 #include  /* for highmem_start only */
+#include 
 #else
 #define p2m_pod_offline_or_broken_hit(pg) 0
 #define p2m_pod_offline_or_broken_replace(pg) BUG_ON(pg != NULL)
@@ -2447,6 +2448,43 @@ static __init int register_heap_trigger(void)
 }
 __initcall(register_heap_trigger);
 
+struct domain *get_pg_owner(domid_t domid)
+{
+struct domain *pg_owner = NULL, *curr = current->domain;
+
+if ( likely(domid == DOMID_SELF) )
+{
+pg_owner = rcu_lock_current_domain();
+goto out;
+}
+
+if ( unlikely(domid == curr->domain_id) )
+{
+gdprintk(XENLOG_WARNING, "Cannot specify itself as foreign domain\n");
+goto out;
+}
+
+switch ( domid )
+{
+case DOMID_IO:
+pg_owner = rcu_lock_domain(dom_io);
+break;
+case DOMID_XEN:
+pg_owner = rcu_lock_domain(dom_xen);
+break;
+default:
+if ( (pg_owner = rcu_lock_domain_by_id(domid)) == NULL )
+{
+gdprintk(XENLOG_WARNING, "Unknown domain d%d\n", domid);
+break;
+}
+break;
+}
+
+ out:
+return pg_owner;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 054d02e6c0..dd4d990ae3 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -589,6 +589,9 @@ int xenmem_add_to_physmap_one(struct domain *d, unsigned 
int space,
 int xenmem_add_to_physmap(struct domain *d, struct xen_add_to_physmap *xatp,
   unsigned int start);
 
+struct domain *get_pg_owner(domid_t domid);
+#define put_pg_owner(pg_owner) rcu_unlock_domain(pg_owner)
+
 /* Return 0 on success, or negative on error. */
 int __must_check guest_remove_page(struct domain *d, unsigned long gmfn);
 int __must_check steal_page(struct domain *d, struct page_info *page,
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 5/8] xen/arm: Allow a privileged domain to map foreign page from DOMID_XEN

[Julien Grall]

For auto-translated domain, the only way to map page to itself is the
using foreign map API. The current code does not allow mapping page from
special page (such as DOMID_XEN).

As xentrace buffer are shared using DOMID_XEN, it is not possible to use
tracing for Arm.

This could be solved by using the helper get_pg_owner(). This helper will
be able to get a reference on DOMID_XEN and therefore allow mapping for
privileged domain.

This patch replace the call to rcu_lock_domain_by_any_id() with
get_pg_owner(). For consistency, all the call to rcu_unlock_domain are
replaced by put_pg_owner().

Signed-off-by: Julien grall 
---
 xen/arch/arm/mm.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index e31b47a394..72d0285768 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1249,20 +1249,20 @@ int xenmem_add_to_physmap_one(
 struct domain *od;
 p2m_type_t p2mt;
 
-od = rcu_lock_domain_by_any_id(extra.foreign_domid);
+od = get_pg_owner(extra.foreign_domid);
 if ( od == NULL )
 return -ESRCH;
 
 if ( od == d )
 {
-rcu_unlock_domain(od);
+put_pg_owner(od);
 return -EINVAL;
 }
 
 rc = xsm_map_gmfn_foreign(XSM_TARGET, d, od);
 if ( rc )
 {
-rcu_unlock_domain(od);
+put_pg_owner(od);
 return rc;
 }
 
@@ -1271,21 +1271,21 @@ int xenmem_add_to_physmap_one(
 page = get_page_from_gfn(od, idx, , P2M_ALLOC);
 if ( !page )
 {
-rcu_unlock_domain(od);
+put_pg_owner(od);
 return -EINVAL;
 }
 
 if ( !p2m_is_ram(p2mt) )
 {
 put_page(page);
-rcu_unlock_domain(od);
+put_pg_owner(od);
 return -EINVAL;
 }
 
 mfn = page_to_mfn(page);
 t = (p2mt == p2m_ram_rw) ? p2m_map_foreign_rw : p2m_map_foreign_ro;
 
-rcu_unlock_domain(od);
+put_pg_owner(od);
 break;
 }
 case XENMAPSPACE_dev_mmio:
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 8/8] xen: Swich parameter in get_page_from_gfn to use typesafe gfn

[Julien Grall]

No functional change intended.

Only reasonable clean-ups are done in this patch. The rest will use _gfn
for the time being.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/guestcopy.c |  2 +-
 xen/arch/arm/mm.c|  2 +-
 xen/arch/x86/cpu/vpmu.c  |  2 +-
 xen/arch/x86/domain.c| 12 ++--
 xen/arch/x86/domctl.c|  6 +++---
 xen/arch/x86/hvm/dm.c|  2 +-
 xen/arch/x86/hvm/domain.c|  2 +-
 xen/arch/x86/hvm/hvm.c   |  9 +
 xen/arch/x86/hvm/svm/svm.c   |  8 
 xen/arch/x86/hvm/viridian/viridian.c | 24 
 xen/arch/x86/hvm/vmx/vmx.c   |  4 ++--
 xen/arch/x86/hvm/vmx/vvmx.c  | 12 ++--
 xen/arch/x86/mm.c| 24 ++--
 xen/arch/x86/mm/p2m.c|  2 +-
 xen/arch/x86/mm/shadow/hvm.c |  6 +++---
 xen/arch/x86/physdev.c   |  3 ++-
 xen/arch/x86/pv/descriptor-tables.c  |  5 ++---
 xen/arch/x86/pv/emul-priv-op.c   |  6 +++---
 xen/arch/x86/pv/mm.c |  2 +-
 xen/arch/x86/traps.c | 11 ++-
 xen/common/domain.c  |  2 +-
 xen/common/event_fifo.c  | 12 ++--
 xen/common/memory.c  |  4 ++--
 xen/common/tmem_xen.c|  2 +-
 xen/include/asm-arm/p2m.h|  6 +++---
 xen/include/asm-x86/p2m.h| 11 +++
 26 files changed, 95 insertions(+), 86 deletions(-)

diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
index 7a0f3e9d5f..55892062bb 100644
--- a/xen/arch/arm/guestcopy.c
+++ b/xen/arch/arm/guestcopy.c
@@ -37,7 +37,7 @@ static struct page_info *translate_get_page(copy_info_t info, 
uint64_t addr,
 return get_page_from_gva(info.gva.v, addr,
  write ? GV2M_WRITE : GV2M_READ);
 
-page = get_page_from_gfn(info.gpa.d, paddr_to_pfn(addr), , P2M_ALLOC);
+page = get_page_from_gfn(info.gpa.d, gaddr_to_gfn(addr), , P2M_ALLOC);
 
 if ( !page )
 return NULL;
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 72d0285768..88711096ef 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1268,7 +1268,7 @@ int xenmem_add_to_physmap_one(
 
 /* Take reference to the foreign domain page.
  * Reference will be released in XENMEM_remove_from_physmap */
-page = get_page_from_gfn(od, idx, , P2M_ALLOC);
+page = get_page_from_gfn(od, _gfn(idx), , P2M_ALLOC);
 if ( !page )
 {
 put_pg_owner(od);
diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 8a4f753eae..4d8f153031 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -607,7 +607,7 @@ static int pvpmu_init(struct domain *d, xen_pmu_params_t 
*params)
 struct vcpu *v;
 struct vpmu_struct *vpmu;
 struct page_info *page;
-uint64_t gfn = params->val;
+gfn_t gfn = _gfn(params->val);
 
 if ( (params->vcpu >= d->max_vcpus) || (d->vcpu[params->vcpu] == NULL) )
 return -EINVAL;
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index f6fe954313..c5cce4b38d 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -797,7 +797,7 @@ int arch_set_info_guest(
 unsigned long flags;
 bool compat;
 #ifdef CONFIG_PV
-unsigned long cr3_gfn;
+gfn_t cr3_gfn;
 struct page_info *cr3_page;
 unsigned long cr4;
 int rc = 0;
@@ -1061,9 +1061,9 @@ int arch_set_info_guest(
 set_bit(_VPF_in_reset, >pause_flags);
 
 if ( !compat )
-cr3_gfn = xen_cr3_to_pfn(c.nat->ctrlreg[3]);
+cr3_gfn = _gfn(xen_cr3_to_pfn(c.nat->ctrlreg[3]));
 else
-cr3_gfn = compat_cr3_to_pfn(c.cmp->ctrlreg[3]);
+cr3_gfn = _gfn(compat_cr3_to_pfn(c.cmp->ctrlreg[3]));
 cr3_page = get_page_from_gfn(d, cr3_gfn, NULL, P2M_ALLOC);
 
 if ( !cr3_page )
@@ -1092,7 +1092,7 @@ int arch_set_info_guest(
 case 0:
 if ( !compat && !VM_ASSIST(d, m2p_strict) &&
  !paging_mode_refcounts(d) )
-fill_ro_mpt(_mfn(cr3_gfn));
+fill_ro_mpt(_mfn(gfn_x(cr3_gfn)));
 break;
 default:
 if ( cr3_page == current->arch.old_guest_table )
@@ -1107,7 +1107,7 @@ int arch_set_info_guest(
 v->arch.guest_table = pagetable_from_page(cr3_page);
 if ( c.nat->ctrlreg[1] )
 {
-cr3_gfn = xen_cr3_to_pfn(c.nat->ctrlreg[1]);
+cr3_gfn = _gfn(xen_cr3_to_pfn(c.nat->ctrlreg[1]));
 cr3_page = get_page_from_gfn(d, cr3_gfn, NULL, P2M_ALLOC);
 
 if ( !cr3_page )
@@ -1132,7 +1132,7 @@ int arch_set_info_guest(
 break;
 case 0:
 if ( VM_ASSIST(d, m2p_strict) )
-zap_ro_mpt(_mfn(cr3_gfn));
+zap_ro_mpt(_mfn(gfn_x(cr3_gfn)));
 break;
 }
 

[Xen-devel] [PATCH 4/8] xen/arm: Add support for read-only foreign mappings

[Julien Grall]

Current, foreign mappings can only be read-write. A follow-up patch will
extend foreign mapping for Xen backend memory (via XEN_DOMID), some of
that memory should only be read accessible for the mapping domain.

Introduce a new p2m_type to cater read-only foreign mappings. For now,
the decision between the two foreign mapping type is based on the type
of the guest page mapped.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/mm.c |  2 +-
 xen/arch/arm/p2m.c|  1 +
 xen/include/asm-arm/p2m.h | 42 +++---
 3 files changed, 41 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index cec821c3a3..e31b47a394 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1283,7 +1283,7 @@ int xenmem_add_to_physmap_one(
 }
 
 mfn = page_to_mfn(page);
-t = p2m_map_foreign_rw;
+t = (p2mt == p2m_ram_rw) ? p2m_map_foreign_rw : p2m_map_foreign_ro;
 
 rcu_unlock_domain(od);
 break;
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index b32b16cd94..0941be9e41 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -450,6 +450,7 @@ static void p2m_set_permission(lpae_t *e, p2m_type_t t, 
p2m_access_t a)
 break;
 
 case p2m_iommu_map_ro:
+case p2m_map_foreign_ro:
 case p2m_grant_map_ro:
 case p2m_invalid:
 e->p2m.xn = 1;
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 5f7f31186d..7c67806056 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -118,6 +118,7 @@ enum p2m_type {
 p2m_mmio_direct_nc, /* Read/write mapping of genuine MMIO area 
non-cacheable */
 p2m_mmio_direct_c,  /* Read/write mapping of genuine MMIO area cacheable */
 p2m_map_foreign_rw, /* Read/write RAM pages from foreign domain */
+p2m_map_foreign_ro, /* Read-only RAM pages from foreign domain */
 p2m_grant_map_rw,   /* Read/write grant mapping */
 p2m_grant_map_ro,   /* Read-only grant mapping */
 /* The types below are only used to decide the page attribute in the P2M */
@@ -137,12 +138,16 @@ enum p2m_type {
 #define P2M_GRANT_TYPES (p2m_to_mask(p2m_grant_map_rw) |  \
  p2m_to_mask(p2m_grant_map_ro))
 
+/* Foreign mappings types */
+#define P2M_FOREIGN_TYPES (p2m_to_mask(p2m_map_foreign_rw) | \
+   p2m_to_mask(p2m_map_foreign_ro))
+
 /* Useful predicates */
 #define p2m_is_ram(_t) (p2m_to_mask(_t) & P2M_RAM_TYPES)
-#define p2m_is_foreign(_t) (p2m_to_mask(_t) & p2m_to_mask(p2m_map_foreign_rw))
+#define p2m_is_foreign(_t) (p2m_to_mask(_t) & P2M_FOREIGN_TYPES)
 #define p2m_is_any_ram(_t) (p2m_to_mask(_t) &   \
 (P2M_RAM_TYPES | P2M_GRANT_TYPES |  \
- p2m_to_mask(p2m_map_foreign_rw)))
+ P2M_FOREIGN_TYPES))
 
 static inline
 void p2m_altp2m_check(struct vcpu *v, uint16_t idx)
@@ -275,7 +280,38 @@ struct page_info *p2m_get_page_from_gfn(struct domain *d, 
gfn_t gfn,
 static inline struct page_info *get_page_from_gfn(
 struct domain *d, unsigned long gfn, p2m_type_t *t, p2m_query_t q)
 {
-return p2m_get_page_from_gfn(d, _gfn(gfn), t);
+mfn_t mfn;
+p2m_type_t _t;
+struct page_info *page;
+
+/*
+ * Special case for DOMID_XEN as it is the only domain so far that is
+ * not auto-translated.
+ */
+if ( unlikely(d != dom_xen) )
+return p2m_get_page_from_gfn(d, _gfn(gfn), t);
+
+if ( !t )
+t = &_t;
+
+*t = p2m_invalid;
+
+/*
+ * DOMID_XEN see 1-1 RAM. The p2m_type is based on the type of the
+ * page.
+ */
+mfn = _mfn(gfn);
+page = mfn_to_page(mfn);
+
+if ( !mfn_valid(mfn) || !get_page(page, d) )
+return NULL;
+
+if ( page->u.inuse.type_info & PGT_writable_page )
+*t = p2m_ram_rw;
+else
+*t = p2m_ram_ro;
+
+return page;
 }
 
 int get_page_type(struct page_info *page, unsigned long type);
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 7/8] xenalyze: Build for Both ARM and x86 Platforms

[Julien Grall]

From: Benjamin Sanda 

Modified to provide building of the xenalyze binary for both ARM and
x86 platforms. The xenalyze binary is now built as part of the BIN
list for both platforms.

Signed-off-by: Benjamin Sanda 
Signed-off-by: Julien Grall 
---
 tools/xentrace/Makefile | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/xentrace/Makefile b/tools/xentrace/Makefile
index 0bad942bdf..9fb7fc96e7 100644
--- a/tools/xentrace/Makefile
+++ b/tools/xentrace/Makefile
@@ -9,8 +9,7 @@ LDLIBS += $(LDLIBS_libxenevtchn)
 LDLIBS += $(LDLIBS_libxenctrl)
 LDLIBS += $(ARGP_LDFLAGS)
 
-BIN-$(CONFIG_X86) = xenalyze
-BIN  = $(BIN-y)
+BIN  = xenalyze
 SBIN = xentrace xentrace_setsize
 LIBBIN   = xenctx
 SCRIPTS  = xentrace_format
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 2/8] xen/arm: p2m: Introduce p2m_get_page_from_gfn

[Julien Grall]

In a follow-up patches, we will need to handle get_page_from_gfn
differently for DOMID_XEN. To keep the code simple move the current
content in a new separate helper p2m_get_page_from_gfn.

Note the new helper is a not anymore a static inline function as the helper
is quite complex.

Finally, take the opportunity to use typesafe gfn as the change is
minor.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/p2m.c| 32 
 xen/include/asm-arm/p2m.h | 33 -
 2 files changed, 36 insertions(+), 29 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 30cfb01498..04c8718e9f 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -379,6 +379,38 @@ mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t 
*t)
 return mfn;
 }
 
+struct page_info *p2m_get_page_from_gfn(struct domain *d, gfn_t gfn,
+p2m_type_t *t)
+{
+struct page_info *page;
+p2m_type_t p2mt;
+mfn_t mfn = p2m_lookup(d, gfn, );
+
+if (t)
+*t = p2mt;
+
+if ( !p2m_is_any_ram(p2mt) )
+return NULL;
+
+if ( !mfn_valid(mfn) )
+return NULL;
+page = mfn_to_page(mfn);
+
+/*
+ * get_page won't work on foreign mapping because the page doesn't
+ * belong to the current domain.
+ */
+if ( p2m_is_foreign(p2mt) )
+{
+struct domain *fdom = page_get_owner_and_reference(page);
+ASSERT(fdom != NULL);
+ASSERT(fdom != d);
+return page;
+}
+
+return (get_page(page, d) ? page: NULL);
+}
+
 int guest_physmap_mark_populate_on_demand(struct domain *d,
   unsigned long gfn,
   unsigned int order)
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index c03557544a..a5914136e3 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -269,38 +269,13 @@ typedef unsigned int p2m_query_t;
 #define P2M_ALLOC(1u<<0)   /* Populate PoD and paged-out entries */
 #define P2M_UNSHARE  (1u<<1)   /* Break CoW sharing */
 
+struct page_info *p2m_get_page_from_gfn(struct domain *d, gfn_t gfn,
+p2m_type_t *t);
+
 static inline struct page_info *get_page_from_gfn(
 struct domain *d, unsigned long gfn, p2m_type_t *t, p2m_query_t q)
 {
-struct page_info *page;
-p2m_type_t p2mt;
-mfn_t mfn = p2m_lookup(d, _gfn(gfn), );
-
-if (t)
-*t = p2mt;
-
-if ( !p2m_is_any_ram(p2mt) )
-return NULL;
-
-if ( !mfn_valid(mfn) )
-return NULL;
-page = mfn_to_page(mfn);
-
-/*
- * get_page won't work on foreign mapping because the page doesn't
- * belong to the current domain.
- */
-if ( p2m_is_foreign(p2mt) )
-{
-struct domain *fdom = page_get_owner_and_reference(page);
-ASSERT(fdom != NULL);
-ASSERT(fdom != d);
-return page;
-}
-
-if ( !get_page(page, d) )
-return NULL;
-return page;
+return p2m_get_page_from_gfn(d, _gfn(gfn), t);
 }
 
 int get_page_type(struct page_info *page, unsigned long type);
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 3/8] xen/arm: Rename p2m_map_foreign to p2m_map_foreign_rw

[Julien Grall]

A follow-up patch will introduce another type of foreign mapping. Rename
the type to make clear it is only used for read-write mapping.

No functional changes intended.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/mm.c | 2 +-
 xen/arch/arm/p2m.c| 2 +-
 xen/include/asm-arm/p2m.h | 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 7a06a33e21..cec821c3a3 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1283,7 +1283,7 @@ int xenmem_add_to_physmap_one(
 }
 
 mfn = page_to_mfn(page);
-t = p2m_map_foreign;
+t = p2m_map_foreign_rw;
 
 rcu_unlock_domain(od);
 break;
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 04c8718e9f..b32b16cd94 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -440,7 +440,7 @@ static void p2m_set_permission(lpae_t *e, p2m_type_t t, 
p2m_access_t a)
 break;
 
 case p2m_iommu_map_rw:
-case p2m_map_foreign:
+case p2m_map_foreign_rw:
 case p2m_grant_map_rw:
 case p2m_mmio_direct_dev:
 case p2m_mmio_direct_nc:
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index a5914136e3..5f7f31186d 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -117,7 +117,7 @@ enum p2m_type {
 p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */
 p2m_mmio_direct_nc, /* Read/write mapping of genuine MMIO area 
non-cacheable */
 p2m_mmio_direct_c,  /* Read/write mapping of genuine MMIO area cacheable */
-p2m_map_foreign,/* Ram pages from foreign domain */
+p2m_map_foreign_rw, /* Read/write RAM pages from foreign domain */
 p2m_grant_map_rw,   /* Read/write grant mapping */
 p2m_grant_map_ro,   /* Read-only grant mapping */
 /* The types below are only used to decide the page attribute in the P2M */
@@ -139,10 +139,10 @@ enum p2m_type {
 
 /* Useful predicates */
 #define p2m_is_ram(_t) (p2m_to_mask(_t) & P2M_RAM_TYPES)
-#define p2m_is_foreign(_t) (p2m_to_mask(_t) & p2m_to_mask(p2m_map_foreign))
+#define p2m_is_foreign(_t) (p2m_to_mask(_t) & p2m_to_mask(p2m_map_foreign_rw))
 #define p2m_is_any_ram(_t) (p2m_to_mask(_t) &   \
 (P2M_RAM_TYPES | P2M_GRANT_TYPES |  \
- p2m_to_mask(p2m_map_foreign)))
+ p2m_to_mask(p2m_map_foreign_rw)))
 
 static inline
 void p2m_altp2m_check(struct vcpu *v, uint16_t idx)
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 0/8] xen/arm: Add xentrace support

[Julien Grall]

Hi all,

This patch series is a rework of the series sent by Benjamin Sanda in April
2016 [1]. It finally adds support for xentrace/xenanalyze on Arm.

Cheers,

[1] https://lists.xenproject.org/archives/html/xen-devel/2016-04/msg00464.html

Benjamin Sanda (3):
  xen/page_alloc: Move get_pg_owner()/put_pg_owner() from x86 to common
code
  xen/arm: Initialize trace buffer
  xenalyze: Build for Both ARM and x86 Platforms

Julien Grall (5):
  xen/arm: p2m: Introduce p2m_get_page_from_gfn
  xen/arm: Rename p2m_map_foreign to p2m_map_foreign_rw
  xen/arm: Add support for read-only foreign mappings
  xen/arm: Allow a privileged domain to map foreign page from DOMID_XEN
  xen: Swich parameter in get_page_from_gfn to use typesafe gfn

 tools/xentrace/Makefile  |  3 +-
 xen/arch/arm/guestcopy.c |  2 +-
 xen/arch/arm/mm.c| 16 -
 xen/arch/arm/p2m.c   | 35 ++-
 xen/arch/arm/setup.c |  3 ++
 xen/arch/x86/cpu/vpmu.c  |  2 +-
 xen/arch/x86/domain.c| 12 +++
 xen/arch/x86/domctl.c|  6 ++--
 xen/arch/x86/hvm/dm.c|  2 +-
 xen/arch/x86/hvm/domain.c|  2 +-
 xen/arch/x86/hvm/hvm.c   |  9 ++---
 xen/arch/x86/hvm/svm/svm.c   |  8 ++---
 xen/arch/x86/hvm/viridian/viridian.c | 24 ++---
 xen/arch/x86/hvm/vmx/vmx.c   |  4 +--
 xen/arch/x86/hvm/vmx/vvmx.c  | 12 +++
 xen/arch/x86/mm.c| 66 
 xen/arch/x86/mm/p2m.c|  2 +-
 xen/arch/x86/mm/shadow/hvm.c |  6 ++--
 xen/arch/x86/physdev.c   |  3 +-
 xen/arch/x86/pv/descriptor-tables.c  |  5 ++-
 xen/arch/x86/pv/emul-priv-op.c   |  6 ++--
 xen/arch/x86/pv/mm.c |  2 +-
 xen/arch/x86/traps.c | 11 +++---
 xen/common/domain.c  |  2 +-
 xen/common/event_fifo.c  | 12 +++
 xen/common/memory.c  |  4 +--
 xen/common/page_alloc.c  | 38 +
 xen/common/tmem_xen.c|  2 +-
 xen/include/asm-arm/p2m.h| 57 ++-
 xen/include/asm-x86/p2m.h| 11 +++---
 xen/include/xen/mm.h |  3 ++
 31 files changed, 212 insertions(+), 158 deletions(-)

-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 6/8] xen/arm: Initialize trace buffer

[Julien Grall]

From: Benjamin Sanda 

Now that we allow a privileged domain to map tracing buffer, initialize
them so a user can effectively trace Xen.

Signed-off-by: Benjamin Sanda 
[julien: rework commit message]
Signed-off-by: Julien Grall 
---
 xen/arch/arm/setup.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 80f00286d3..7022904cc3 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -863,6 +864,8 @@ void __init start_xen(unsigned long boot_phys_offset,
 
 heap_init_late();
 
+init_trace_bufs();
+
 init_constructors();
 
 console_endboot();
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Porting XEN hypervisor on iMX8QM

[Julien Grall]

Hi,

I am CCing Peng Fan who is working for NXP and also on Xen. Peng, do you have 
any pointer to getting Xen running on iMX8QM?


Cheers,

On 06/11/2018 18:59, Stefano Stabellini wrote:

Hi Ravi,

Please have a look at our wiki as a reference:
http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions

I would start from cross-compiling the Xen hypervisor (the xen/
directory), no need to build the Xen userspace tools initially.
Make sure to have the right early boot uart driver, see
CONFIG_EARLY_PRINTK and docs/misc/arm/early-printk.txt.

After you boot the Xen binary from uboot, you should be able to see some
console output from the hypervisror. The step after that is booting
Dom0.

Cheers,

Stefano

On Mon, 5 Nov 2018, Ravi Pichholiya wrote:

Hi Stefano,
This is in reference to our LinkedIn discussion, in our one of the project we 
need to port XEN hypervisor on iMx8QM.

Request you to share what all visibility we should require from boot 
prospective as currently we are having access to Device tree
and U-boot source code only. Is access to any other files are also required?

Also some reference to start with the porting of XEN if available with you.

Thanks & Regards,
Ravi Pichholiya



--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Porting XEN hypervisor on iMX8QM

[Stefano Stabellini]

Hi Ravi,

Please have a look at our wiki as a reference:
http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions

I would start from cross-compiling the Xen hypervisor (the xen/
directory), no need to build the Xen userspace tools initially.
Make sure to have the right early boot uart driver, see
CONFIG_EARLY_PRINTK and docs/misc/arm/early-printk.txt.

After you boot the Xen binary from uboot, you should be able to see some
console output from the hypervisror. The step after that is booting
Dom0.

Cheers,

Stefano

On Mon, 5 Nov 2018, Ravi Pichholiya wrote:
> Hi Stefano,
> This is in reference to our LinkedIn discussion, in our one of the project we 
> need to port XEN hypervisor on iMx8QM.
> 
> Request you to share what all visibility we should require from boot 
> prospective as currently we are having access to Device tree
> and U-boot source code only. Is access to any other files are also required?
> 
> Also some reference to start with the porting of XEN if available with you.
> 
> Thanks & Regards,
> Ravi Pichholiya
> 
> ___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Dom0 kernel 4.14 with SMP randomly crashing

[Rishi]

On Tue, Nov 6, 2018 at 10:41 PM Rishi <2rushike...@gmail.com> wrote:

>
>
> On Tue, Nov 6, 2018 at 5:47 PM Wei Liu  wrote:
>
>> On Tue, Nov 06, 2018 at 03:31:31PM +0530, Rishi wrote:
>> >
>> > So after knowing the stack trace, it appears that the CPU was getting
>> stuck
>> > for xen_hypercall_xen_version
>>
>> That hypercall is used when a PV kernel (re-)enables interrupts. See
>> xen_irq_enable. The purpose is to force the kernel to switch to
>> hypervisor.
>>
>> >
>> > watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [swapper/0:0]
>> >
>> >
>> > [30569.582740] watchdog: BUG: soft lockup - CPU#0 stuck for 23s!
>> > [swapper/0:0]
>> >
>> > [30569.588186] Kernel panic - not syncing: softlockup: hung tasks
>> >
>> > [30569.591307] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G L
>>   4.19.1
>> > #1
>> >
>> > [30569.595110] Hardware name: Xen HVM domU, BIOS 4.4.1-xs132257
>> 12/12/2016
>> >
>> > [30569.598356] Call Trace:
>> >
>> > [30569.599597]  
>> >
>> > [30569.600920]  dump_stack+0x5a/0x73
>> >
>> > [30569.602998]  panic+0xe8/0x249
>> >
>> > [30569.604806]  watchdog_timer_fn+0x200/0x230
>> >
>> > [30569.607029]  ? softlockup_fn+0x40/0x40
>> >
>> > [30569.609246]  __hrtimer_run_queues+0x133/0x270
>> >
>> > [30569.611712]  hrtimer_interrupt+0xfb/0x260
>> >
>> > [30569.613800]  xen_timer_interrupt+0x1b/0x30
>> >
>> > [30569.616972]  __handle_irq_event_percpu+0x69/0x1a0
>> >
>> > [30569.619831]  handle_irq_event_percpu+0x30/0x70
>> >
>> > [30569.622382]  handle_percpu_irq+0x34/0x50
>> >
>> > [30569.625048]  generic_handle_irq+0x1e/0x30
>> >
>> > [30569.627216]  __evtchn_fifo_handle_events+0x163/0x1a0
>> >
>> > [30569.629955]  __xen_evtchn_do_upcall+0x41/0x70
>> >
>> > [30569.632612]  xen_evtchn_do_upcall+0x27/0x50
>> >
>> > [30569.635136]  xen_do_hypervisor_callback+0x29/0x40
>> >
>> > [30569.638181] RIP: e030:xen_hypercall_xen_version+0xa/0x20
>>
>> What is the asm code for this RIP?
>>
>>
>> Wei.
>>
>
> The issue of crash is getting resolved with appending "noirqbalance" at
> xen command line. This way all dom0 cpus are available but not irq balanced
> at xen.
>
> Even though I'm running irqbalance service in dom0 the irqs seems to be
> not moving. <- this is dom0 perspective, I do not know yet, if it follows
> Xen irq.
>
> I tried objdump, while I have  have the function in out but there is no
> asm code of it. Its just "..."
>
> 81001220 :
>
> ...
>
>
> 81001240 :
>
> ...
>
> All "hypercalls" appear similarly.
>

How frequent can be that hypercall/xen_irq_enable()? Like n/s or once a
while?
During my tests, the system runs stable unless I'm downloading a large
file. Files around a GB size are getting downloaded without crash, but
system crash comes when its above it. I'm using a 2.1GB file & wget to
download.

Is there a way I can simulate PV kernel (re-)enable of interrupt using a
kernel module with a controlled fashion?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Xen Security Advisory 282 v1 - guest use of HLE constructs may lock up host

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-282

 guest use of HLE constructs may lock up host

ISSUE DESCRIPTION
=

Various Intel CPU models have an erratum listed under the title
"Processor May Hang When Executing Code In an HLE Transaction".  It
describes a potential hang when using instructions with the XACQUIRE
prefix on the host physical memory range covering the first 4 MiB
starting at the 1GiB boundary.

IMPACT
==

A malicious or buggy guest may cause a CPU to hang, resulting in a DoS
(Denial of Service) affecting the entire host.

VULNERABLE SYSTEMS
==

All Xen versions are affected.

Only Intel based x86 systems are affected.  Please refer to Intel
documentation as to which specific CPU models are affected.

AMD x86 systems as well as Arm ones are not affected.

MITIGATION
==

There is no known mitigation.  A BIOS update may be available for some
systems, working around the issue at the firmware level.

RESOLUTION
==

Applying the appropriate pair of attached patches works around this issue
for the CPU models known to be affected at the time of writing.

xsa282-?.patch  xen-unstable
xsa282-4.11-1.patch + xsa282-2.patchXen 4.11.x, Xen 4.10.x
xsa282-4.9-1.patch + xsa282-2.patch Xen 4.9.x
xsa282-4.9-1.patch + xsa282-4.8-2.patch Xen 4.8.x, Xen 4.7.x

$ sha256sum xsa282*
6ef64ca920a58ed9185e81fad3dfa9ca5f6316f1e72ddd4f411f3e79eaf79903  xsa282.meta
ad7093e00b3d6650530c95427ef0e68880883f0cec7229b5f41c9e2dc497ffd5  xsa282-1.patch
7ce7fa105026b189500a31bd3978ec0c6fd9d7c95f688463c25ecce76366be35  xsa282-2.patch
fbff734d678700864563f8214361f391c0cbda9b67ed7256535ed3db388c8feb  
xsa282-4.8-2.patch
df833cbe9b8798104a65d44b737c46f97399b86b0ffd03c99fda4c8ecf5a353c  
xsa282-4.9-1.patch
68eab296a7124662cbe3c6df8835aff9b4a26160fdbe970e206a7a6ef8d27ec7  
xsa282-4.11-1.patch
$

NOTE REGARDING LACK OF EMBARGO
==

The issue has been documented publicly in Specification Updates for at
least some of the affected processors for quite some time.
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAlvh3+0MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZ48QIALQ1hLMewraf+URzsd36EUJNPP+1C8Dg35PavdJ1
mrqBljy/bIYCiLvLm1RwinUPL5vrvkB97/6AjmnpZM83AA3/PLTbh3tpP8fiLUcF
YL7wJogvjv51Q3N8mYHjxGGl5YYVdrgxwxbQIuzRnw2gi/ikd0oAoNce/QIF6iFz
P2I8VjKuQZ6qEzdKXTTiPNQQzL+OfVGQ+RcsthQieWce53p+n1pI1QqbPOwdYtca
/cOhP+vGRzh+4QP50JuN5ikdC/C9KpyjEo5mZVlrZQYPIqzI+vomueCJLPGN3cSY
LBcJc/lT/w/LRgygpbUB/OO8RwK5XB9T4Jm/ssXGpCOTs3Y=
=Ipfd
-END PGP SIGNATURE-


xsa282.meta
Description: Binary data


xsa282-1.patch
Description: Binary data


xsa282-2.patch
Description: Binary data


xsa282-4.8-2.patch
Description: Binary data


xsa282-4.9-1.patch
Description: Binary data


xsa282-4.11-1.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC 16/16] xen/arm: Track page accessed between batch of Set/Way operations

[Stefano Stabellini]

On Tue, 6 Nov 2018, Julien Grall wrote:
> On 06/11/2018 17:43, Stefano Stabellini wrote:
> > On Mon, 5 Nov 2018, Julien Grall wrote:
> > > Hi Stefano,
> > > 
> > > On 11/5/18 9:35 PM, Stefano Stabellini wrote:
> > > > On Mon, 8 Oct 2018, Julien Grall wrote:
> > > > > At the moment, the implementation of Set/Way operations will go
> > > > > through
> > > > > all the entries of the guest P2M and flush them. However, this is very
> > > > > expensive and may render unusable a guest OS using them.
> > > > > 
> > > > > For instance, Linux 32-bit will use Set/Way operations during
> > > > > secondary
> > > > > CPU bring-up. As the implementation is really expensive, it may be
> > > > > possible
> > > > > to hit the CPU bring-up timeout.
> > > > > 
> > > > > To limit the Set/Way impact, we track what pages has been of the guest
> > > > > has been accessed between batch of Set/Way operations. This is done
> > > > > using bit[0] (aka valid bit) of the P2M entry.
> > > > 
> > > > This is going to improve performance of ill-mannered guests at the cost
> > > > of hurting performance of well-mannered guests. Is it really a good
> > > > trade-off? Should this behavior at least be configurable with a Xen
> > > > command line?
> > > 
> > > Well, we have the choice between not been able to boot Linux 32-bit
> > > anymore or
> > > have a slight impact at the boot time for all guests.
> > 
> > Wait -- I thought that with the set/way emulation introduced by patch
> > #15 we would be able to boot Linux 32-bit already. This patch is a
> > performance improvement. Or is it actually needed to boot Linux 32-bit?
> 
> The problem is Linux 32-bit calls a few time set/way during secondary CPU
> bring up. It also has a timeout of 1s to fully boot that CPU. In my testing, I
> can easily hit the timeout even with a small amount of memory.
 
Damn! It is worst than I thought.


> If we don't start tracking the page from the beginning, then you would need to
> clean the full RAM the first time. If you start to track from the beginning,
> you may just have to clean a couple of MB.
>
> > 
> > > As you may have noticed the command line is been suggested below. I didn't
> > > yet
> > > implemented as we agreed at Connect it would be good to start getting
> > > feedback
> > > on it.
> > 
> > Sure. I was thinking about this -- does it make sense to have different
> > defaults for 32bit and 64bit guests?
> > 
> > 32bit -> default p2m_invalidate_root
> > 64bit -> default not
> 
> The decision is not that easy. While Linux arm64 does not contain set/way
> anymore, UEFI still use them (I checked it a couple of months ago).
> 
> I haven't done any benchmark yet. That's my next step.

OK, makes sense


> > > I am not entirely to understand your last sentence, this feature is turned
> > > off
> > > when an IOMMU is present. So what is your use case here?
> >   My sentence was badly written, sorry. I meant to say that even when an
> > IOMMU is NOT present, there are cases where we might not want to call
> > p2m_invalidate_root.
> 
> Before implementing a command line option (or even plumbing that to the guest
> configuration), I want to understand what is the real impact on the boot time
> for "normal" guest.

yes, makes sense

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC 16/16] xen/arm: Track page accessed between batch of Set/Way operations

[Julien Grall]

On 06/11/2018 17:43, Stefano Stabellini wrote:

On Mon, 5 Nov 2018, Julien Grall wrote:

Hi Stefano,

On 11/5/18 9:35 PM, Stefano Stabellini wrote:

On Mon, 8 Oct 2018, Julien Grall wrote:

At the moment, the implementation of Set/Way operations will go through
all the entries of the guest P2M and flush them. However, this is very
expensive and may render unusable a guest OS using them.

For instance, Linux 32-bit will use Set/Way operations during secondary
CPU bring-up. As the implementation is really expensive, it may be
possible
to hit the CPU bring-up timeout.

To limit the Set/Way impact, we track what pages has been of the guest
has been accessed between batch of Set/Way operations. This is done
using bit[0] (aka valid bit) of the P2M entry.


This is going to improve performance of ill-mannered guests at the cost
of hurting performance of well-mannered guests. Is it really a good
trade-off? Should this behavior at least be configurable with a Xen
command line?


Well, we have the choice between not been able to boot Linux 32-bit anymore or
have a slight impact at the boot time for all guests.


Wait -- I thought that with the set/way emulation introduced by patch
#15 we would be able to boot Linux 32-bit already. This patch is a
performance improvement. Or is it actually needed to boot Linux 32-bit?


The problem is Linux 32-bit calls a few time set/way during secondary CPU bring 
up. It also has a timeout of 1s to fully boot that CPU. In my testing, I can 
easily hit the timeout even with a small amount of memory.


If we don't start tracking the page from the beginning, then you would need to 
clean the full RAM the first time. If you start to track from the beginning, you 
may just have to clean a couple of MB.






As you may have noticed the command line is been suggested below. I didn't yet
implemented as we agreed at Connect it would be good to start getting feedback
on it.


Sure. I was thinking about this -- does it make sense to have different
defaults for 32bit and 64bit guests?

32bit -> default p2m_invalidate_root
64bit -> default not


The decision is not that easy. While Linux arm64 does not contain set/way 
anymore, UEFI still use them (I checked it a couple of months ago).


I haven't done any benchmark yet. That's my next step.


I am not entirely to understand your last sentence, this feature is turned off
when an IOMMU is present. So what is your use case here?
  
My sentence was badly written, sorry. I meant to say that even when an

IOMMU is NOT present, there are cases where we might not want to call
p2m_invalidate_root.


Before implementing a command line option (or even plumbing that to the guest 
configuration), I want to understand what is the real impact on the boot time 
for "normal" guest.


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC 10/16] xen/arm: vcpreg: Add wrappers to handle co-proc access trapped by HCR_EL2.TVM

[Stefano Stabellini]

On Tue, 6 Nov 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 06/11/2018 17:36, Stefano Stabellini wrote:
> > On Mon, 5 Nov 2018, Julien Grall wrote:
> > > Hi Stefano,
> > > 
> > > On 11/5/18 7:47 PM, Stefano Stabellini wrote:
> > > > On Mon, 8 Oct 2018, Julien Grall wrote:
> > > > > A follow-up patch will require to emulate some accesses to some
> > > > > co-processors registers trapped by HCR_EL2.TVM. When set, all NS EL1
> > > > > writes
> > > > > to the virtual memory control registers will be trapped to the
> > > > > hypervisor.
> > > > > 
> > > > > This patch adds the infrastructure to passthrough the access to host
> > > > > registers. For convenience a bunch of helpers have been added to
> > > > > generate the different helpers.
> > > > > 
> > > > > Note that HCR_EL2.TVM will be set in a follow-up patch dynamically.
> > > > > 
> > > > > Signed-off-by: Julien Grall 
> > > > > ---
> > > > >xen/arch/arm/vcpreg.c| 144
> > > > > +++
> > > > >xen/include/asm-arm/cpregs.h |   1 +
> > > > >2 files changed, 145 insertions(+)
> > > > > 
> > > > > diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
> > > > > index b04d996fd3..49529b97cd 100644
> > > > > --- a/xen/arch/arm/vcpreg.c
> > > > > +++ b/xen/arch/arm/vcpreg.c
> > > > > @@ -24,6 +24,122 @@
> > > > >#include 
> > > > >#include 
> > > > >+/*
> > > > > + * Macros to help generating helpers for registers trapped when
> > > > > + * HCR_EL2.TVM is set.
> > > > > + *
> > > > > + * Note that it only traps NS write access from EL1.
> > > > > + *
> > > > > + *  - TVM_REG() should not be used outside of the macros. It is there
> > > > > to
> > > > > + *help defining TVM_REG32() and TVM_REG64()
> > > > > + *  - TVM_REG32(regname, xreg) and TVM_REG64(regname, xreg) are used
> > > > > to
> > > > > + *resp. generate helper accessing 32-bit and 64-bit register.
> > > > > "regname"
> > > > > + *been the Arm32 name and "xreg" the Arm64 name.
> > > >^ is
> > > > 
> > > > Please add that we use the Arm64 reg name to call WRITE_SYSREG in the
> > > > Xen source code even on Arm32 in general
> > > 
> > > I am not sure to understand this. It is common use in Xen to use arm64
> > > name
> > > when code is for both architecture. So why would I need a specific comment
> > > here?
> > 
> > Yes, that's our convention, but as I was looking through the code, I
> > couldn't quickly find any places where we wrote the convention down. Is
> > there? I thought it would be good to start somewhere, this could be a
> > good place as any, also given that it directly affects this code.
> 
> include/asm-arm/cpregs.h:
> 
> /* Aliases of AArch64 names for use in common code when building for AArch32
> */

Ops X-)
Maybe add reference to it? Fine either way.


> > 
> > 
> > > > > + *  - UPDATE_REG32_COMBINED(lowreg, hireg, xreg) are used to generate
> > > > > a
> > > > 
> > > > TVM_REG32_COMBINED
> > > > 
> > > > 
> > > > > + *  pair of registers share the same Arm32 registers. "lowreg" and
> > > > > + *  "higreg" been resp. the Arm32 name and "xreg" the Arm64 name.
> > > > > "lowreg"
> > > > > + *  will use xreg[31:0] and "hireg" will use xreg[63:32].
> > > > 
> > > > Please add that xreg is unused in the Arm32 case.
> > > 
> > > Why do you think that? xreg is actually used. It will get expanded to
> > > whatever
> > > is the co-processor encoding and caught by reg... in TVM_REG().
> > 
> > It is unused in the TVM_REG32_COMBINED case, which is the comment part I
> > was replying about. This is the code:
> > 
> >#define TVM_REG32_COMBINED(lowreg, hireg, xreg) \
> >/* Use TVM_REG directly to workaround macro expansion. */   \
> >TVM_REG(32, vreg_emulate_##lowreg, lowreg)  \
> >TVM_REG(32, vreg_emulate_##hireg, hireg)
> > 
> > xreg is not used?
> 
> Hrm it is used in that case. I am got confused. How about the following:
> 
> TVM_REG32_COMBINED(lowreg, hireg, xreg) are used to generate a
> pair of register sharing the same Arm64 register, but are 2 distinct Arm32
> registers. "lowreg" and "hireg" contains the name for on Arm32 registers,
> "xreg" contains the name for the combined register on Arm64. The definition of
> "lowreg" and "higreg" match the Armv8 specification, this means "lowreg" is an
> alias to xreg[31:0] and "high" is an alias to xreg[63:32].

Sounds good

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC 10/16] xen/arm: vcpreg: Add wrappers to handle co-proc access trapped by HCR_EL2.TVM

[Julien Grall]

Hi Stefano,

On 06/11/2018 17:36, Stefano Stabellini wrote:

On Mon, 5 Nov 2018, Julien Grall wrote:

Hi Stefano,

On 11/5/18 7:47 PM, Stefano Stabellini wrote:

On Mon, 8 Oct 2018, Julien Grall wrote:

A follow-up patch will require to emulate some accesses to some
co-processors registers trapped by HCR_EL2.TVM. When set, all NS EL1
writes
to the virtual memory control registers will be trapped to the hypervisor.

This patch adds the infrastructure to passthrough the access to host
registers. For convenience a bunch of helpers have been added to
generate the different helpers.

Note that HCR_EL2.TVM will be set in a follow-up patch dynamically.

Signed-off-by: Julien Grall 
---
   xen/arch/arm/vcpreg.c| 144
+++
   xen/include/asm-arm/cpregs.h |   1 +
   2 files changed, 145 insertions(+)

diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
index b04d996fd3..49529b97cd 100644
--- a/xen/arch/arm/vcpreg.c
+++ b/xen/arch/arm/vcpreg.c
@@ -24,6 +24,122 @@
   #include 
   #include 
   +/*
+ * Macros to help generating helpers for registers trapped when
+ * HCR_EL2.TVM is set.
+ *
+ * Note that it only traps NS write access from EL1.
+ *
+ *  - TVM_REG() should not be used outside of the macros. It is there to
+ *help defining TVM_REG32() and TVM_REG64()
+ *  - TVM_REG32(regname, xreg) and TVM_REG64(regname, xreg) are used to
+ *resp. generate helper accessing 32-bit and 64-bit register.
"regname"
+ *been the Arm32 name and "xreg" the Arm64 name.

   ^ is

Please add that we use the Arm64 reg name to call WRITE_SYSREG in the
Xen source code even on Arm32 in general


I am not sure to understand this. It is common use in Xen to use arm64 name
when code is for both architecture. So why would I need a specific comment
here?


Yes, that's our convention, but as I was looking through the code, I
couldn't quickly find any places where we wrote the convention down. Is
there? I thought it would be good to start somewhere, this could be a
good place as any, also given that it directly affects this code.


include/asm-arm/cpregs.h:

/* Aliases of AArch64 names for use in common code when building for AArch32 */





+ *  - UPDATE_REG32_COMBINED(lowreg, hireg, xreg) are used to generate a


TVM_REG32_COMBINED



+ *  pair of registers share the same Arm32 registers. "lowreg" and
+ *  "higreg" been resp. the Arm32 name and "xreg" the Arm64 name.
"lowreg"
+ *  will use xreg[31:0] and "hireg" will use xreg[63:32].


Please add that xreg is unused in the Arm32 case.


Why do you think that? xreg is actually used. It will get expanded to whatever
is the co-processor encoding and caught by reg... in TVM_REG().


It is unused in the TVM_REG32_COMBINED case, which is the comment part I
was replying about. This is the code:

   #define TVM_REG32_COMBINED(lowreg, hireg, xreg) \
   /* Use TVM_REG directly to workaround macro expansion. */   \
   TVM_REG(32, vreg_emulate_##lowreg, lowreg)  \
   TVM_REG(32, vreg_emulate_##hireg, hireg)

xreg is not used?


Hrm it is used in that case. I am got confused. How about the following:

TVM_REG32_COMBINED(lowreg, hireg, xreg) are used to generate a
pair of register sharing the same Arm64 register, but are 2 distinct Arm32 
registers. "lowreg" and "hireg" contains the name for on Arm32 registers,
"xreg" contains the name for the combined register on Arm64. The definition of 
"lowreg" and "higreg" match the Armv8 specification, this means "lowreg" is an 
alias to xreg[31:0] and "high" is an alias to xreg[63:32].


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC 16/16] xen/arm: Track page accessed between batch of Set/Way operations

[Stefano Stabellini]

On Mon, 5 Nov 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 11/5/18 9:35 PM, Stefano Stabellini wrote:
> > On Mon, 8 Oct 2018, Julien Grall wrote:
> > > At the moment, the implementation of Set/Way operations will go through
> > > all the entries of the guest P2M and flush them. However, this is very
> > > expensive and may render unusable a guest OS using them.
> > > 
> > > For instance, Linux 32-bit will use Set/Way operations during secondary
> > > CPU bring-up. As the implementation is really expensive, it may be
> > > possible
> > > to hit the CPU bring-up timeout.
> > > 
> > > To limit the Set/Way impact, we track what pages has been of the guest
> > > has been accessed between batch of Set/Way operations. This is done
> > > using bit[0] (aka valid bit) of the P2M entry.
> > 
> > This is going to improve performance of ill-mannered guests at the cost
> > of hurting performance of well-mannered guests. Is it really a good
> > trade-off? Should this behavior at least be configurable with a Xen
> > command line?
> 
> Well, we have the choice between not been able to boot Linux 32-bit anymore or
> have a slight impact at the boot time for all guests.

Wait -- I thought that with the set/way emulation introduced by patch
#15 we would be able to boot Linux 32-bit already. This patch is a
performance improvement. Or is it actually needed to boot Linux 32-bit?


> As you may have noticed the command line is been suggested below. I didn't yet
> implemented as we agreed at Connect it would be good to start getting feedback
> on it.

Sure. I was thinking about this -- does it make sense to have different
defaults for 32bit and 64bit guests?

32bit -> default p2m_invalidate_root
64bit -> default not


> > 
> > > This patch adds a new per-arch helper is introduced to perform actions
> > > just
> > > before the guest is first unpaused. This will be used to invalidate the
> > > P2M to track access from the start of the guest.
> > > 
> > > Signed-off-by: Julien Grall 
> > > 
> > > ---
> > > 
> > > Cc: Stefano Stabellini 
> > > Cc: Julien Grall 
> > > Cc: Andrew Cooper 
> > > Cc: George Dunlap 
> > > Cc: Ian Jackson 
> > > Cc: Jan Beulich 
> > > Cc: Konrad Rzeszutek Wilk 
> > > Cc: Tim Deegan 
> > > Cc: Wei Liu 
> > > ---
> > >   xen/arch/arm/domain.c   | 14 ++
> > >   xen/arch/arm/domain_build.c |  7 +++
> > >   xen/arch/arm/p2m.c  | 32 +++-
> > >   xen/arch/x86/domain.c   |  4 
> > >   xen/common/domain.c |  5 -
> > >   xen/include/asm-arm/p2m.h   |  2 ++
> > >   xen/include/xen/domain.h|  2 ++
> > >   7 files changed, 64 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > > index feebbf5a92..f439f4657a 100644
> > > --- a/xen/arch/arm/domain.c
> > > +++ b/xen/arch/arm/domain.c
> > > @@ -738,6 +738,20 @@ int arch_domain_soft_reset(struct domain *d)
> > >   return -ENOSYS;
> > >   }
> > >   +void arch_domain_creation_finished(struct domain *d)
> > > +{
> > > +/*
> > > + * To avoid flushing the whole guest RAM on the first Set/Way, we
> > > + * invalidate the P2M to track what has been accessed.
> > > + *
> > > + * This is only turned when IOMMU is not used or the page-table are
> > > + * not shared because bit[0] (e.g valid bit) unset will result
> > > + * IOMMU fault that could be not fixed-up.
> > > + */
> > > +if ( !iommu_use_hap_pt(d) )
> > > +p2m_invalidate_root(p2m_get_hostp2m(d));
> > > +}
> > > +
> > >   static int is_guest_pv32_psr(uint32_t psr)
> > >   {
> > >   switch (psr & PSR_MODE_MASK)
> > > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > > index f552154e93..de96516faa 100644
> > > --- a/xen/arch/arm/domain_build.c
> > > +++ b/xen/arch/arm/domain_build.c
> > > @@ -2249,6 +2249,13 @@ int __init construct_dom0(struct domain *d)
> > >   v->is_initialised = 1;
> > >   clear_bit(_VPF_down, >pause_flags);
> > >   +/*
> > > + * XXX: We probably want a command line option to invalidate or not
> > > + * the P2M. This is because invalidating the P2M will not work with
> > > + * IOMMU, however if this is not done there will be an impact.
> > 
> > Why can't we check on iommu_use_hap_pt(d) like in
> > arch_domain_creation_finished?
> > 
> > In any case, I agree it is a good idea to introduce a command line
> > parameter to toggle the p2m_invalidate_root call at domain creation
> > on/off. There are cases where it should be off even if an IOMMU is
> > present.
> 
> I actually forgot to remove that code as Dom0 should be covered by the change
> below.

Makes sense now


> I am not entirely to understand your last sentence, this feature is turned off
> when an IOMMU is present. So what is your use case here?
 
My sentence was badly written, sorry. I meant to say that even when an
IOMMU is NOT present, there are cases where we might not want to call
p2m_invalidate_root.

Re: [Xen-devel] [RFC 15/16] xen/arm: Implement Set/Way operations

[Stefano Stabellini]

On Tue, 6 Nov 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 06/11/2018 17:31, Stefano Stabellini wrote:
> > On Mon, 5 Nov 2018, Julien Grall wrote:
> > > > This will affect all the registers trapped with TVM. Shouldn't we only
> > > > call p2m_toggle_cache when relevant? i.e. when changing SCTLR?
> > > > I think it would be better to only modify the SCTLR emulation handler.
> > > 
> > > This is made on purpose, you increase the chance to disable TVM as soon as
> > > possible. If you only rely on SCTLR, you may end up to trap a lot of
> > > registers
> > > for a long time.
> > > 
> > > FWIW, as I already wrote in the commit message, this is based on what KVM
> > > does.
> > 
> > I missed that. As you explain it, it makes sense. Maybe worth adding an
> > explicit statement about it: "On ARM64, we call p2m_toggle_cache from on
> > the TVM-trapped register handlers to increase the chances of disabling
> > TVM as soon as possible."
> 
> I am assuming you meant arm32 here? 

Yes, I did


> Looking at the code, it looks like I
> implemented the arm64 differently. But we probably want apply to call
> p2m_toggle_cache in all TVM trapped registers.
> 
> This would keep the logic everywhere the same.

Right, good idea

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC 10/16] xen/arm: vcpreg: Add wrappers to handle co-proc access trapped by HCR_EL2.TVM

[Stefano Stabellini]

On Mon, 5 Nov 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 11/5/18 7:47 PM, Stefano Stabellini wrote:
> > On Mon, 8 Oct 2018, Julien Grall wrote:
> > > A follow-up patch will require to emulate some accesses to some
> > > co-processors registers trapped by HCR_EL2.TVM. When set, all NS EL1
> > > writes
> > > to the virtual memory control registers will be trapped to the hypervisor.
> > > 
> > > This patch adds the infrastructure to passthrough the access to host
> > > registers. For convenience a bunch of helpers have been added to
> > > generate the different helpers.
> > > 
> > > Note that HCR_EL2.TVM will be set in a follow-up patch dynamically.
> > > 
> > > Signed-off-by: Julien Grall 
> > > ---
> > >   xen/arch/arm/vcpreg.c| 144
> > > +++
> > >   xen/include/asm-arm/cpregs.h |   1 +
> > >   2 files changed, 145 insertions(+)
> > > 
> > > diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
> > > index b04d996fd3..49529b97cd 100644
> > > --- a/xen/arch/arm/vcpreg.c
> > > +++ b/xen/arch/arm/vcpreg.c
> > > @@ -24,6 +24,122 @@
> > >   #include 
> > >   #include 
> > >   +/*
> > > + * Macros to help generating helpers for registers trapped when
> > > + * HCR_EL2.TVM is set.
> > > + *
> > > + * Note that it only traps NS write access from EL1.
> > > + *
> > > + *  - TVM_REG() should not be used outside of the macros. It is there to
> > > + *help defining TVM_REG32() and TVM_REG64()
> > > + *  - TVM_REG32(regname, xreg) and TVM_REG64(regname, xreg) are used to
> > > + *resp. generate helper accessing 32-bit and 64-bit register.
> > > "regname"
> > > + *been the Arm32 name and "xreg" the Arm64 name.
> >   ^ is
> > 
> > Please add that we use the Arm64 reg name to call WRITE_SYSREG in the
> > Xen source code even on Arm32 in general
> 
> I am not sure to understand this. It is common use in Xen to use arm64 name
> when code is for both architecture. So why would I need a specific comment
> here?

Yes, that's our convention, but as I was looking through the code, I
couldn't quickly find any places where we wrote the convention down. Is
there? I thought it would be good to start somewhere, this could be a
good place as any, also given that it directly affects this code.


> > > + *  - UPDATE_REG32_COMBINED(lowreg, hireg, xreg) are used to generate a
> > 
> > TVM_REG32_COMBINED
> > 
> > 
> > > + *  pair of registers share the same Arm32 registers. "lowreg" and
> > > + *  "higreg" been resp. the Arm32 name and "xreg" the Arm64 name.
> > > "lowreg"
> > > + *  will use xreg[31:0] and "hireg" will use xreg[63:32].
> > 
> > Please add that xreg is unused in the Arm32 case.
> 
> Why do you think that? xreg is actually used. It will get expanded to whatever
> is the co-processor encoding and caught by reg... in TVM_REG().

It is unused in the TVM_REG32_COMBINED case, which is the comment part I
was replying about. This is the code:

  #define TVM_REG32_COMBINED(lowreg, hireg, xreg) \
  /* Use TVM_REG directly to workaround macro expansion. */   \
  TVM_REG(32, vreg_emulate_##lowreg, lowreg)  \
  TVM_REG(32, vreg_emulate_##hireg, hireg)

xreg is not used?

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC 15/16] xen/arm: Implement Set/Way operations

[Julien Grall]

Hi Stefano,

On 06/11/2018 17:31, Stefano Stabellini wrote:

On Mon, 5 Nov 2018, Julien Grall wrote:

This will affect all the registers trapped with TVM. Shouldn't we only
call p2m_toggle_cache when relevant? i.e. when changing SCTLR?
I think it would be better to only modify the SCTLR emulation handler.


This is made on purpose, you increase the chance to disable TVM as soon as
possible. If you only rely on SCTLR, you may end up to trap a lot of registers
for a long time.

FWIW, as I already wrote in the commit message, this is based on what KVM
does.


I missed that. As you explain it, it makes sense. Maybe worth adding an
explicit statement about it: "On ARM64, we call p2m_toggle_cache from on
the TVM-trapped register handlers to increase the chances of disabling
TVM as soon as possible."


I am assuming you meant arm32 here? Looking at the code, it looks like I 
implemented the arm64 differently. But we probably want apply to call 
p2m_toggle_cache in all TVM trapped registers.


This would keep the logic everywhere the same.

Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC 15/16] xen/arm: Implement Set/Way operations

[Stefano Stabellini]

On Mon, 5 Nov 2018, Julien Grall wrote:
> > > +void p2m_set_way_flush(struct vcpu *v)
> > > +{
> > > +/* This function can only work with the current vCPU. */
> > > +ASSERT(v == current);
> > 
> > NIT: if it can only operate on current, it makes sense to remove the
> > struct vcpu* parameter
> 
> I prefer to keep struct vcpu *v here. This makes more straightforward to know
> on what the function is working on.
> 
> Furthermore, current is actually quite expensive to use in some circumstance.
> 
> For instance, in nested case, TPIDR_EL2 will get trapped to the host
> hypervisor.
> 
> So it would be best if we start avoid current whenever it is possible.

That's OK


> > 
> > 
> > > +if ( !(v->arch.hcr_el2 & HCR_TVM) )
> > > +{
> > > +p2m_flush_vm(v);
> > > +vcpu_hcr_set_flags(v, HCR_TVM);
> > > +}
> > > +}
> > > +
> > > +void p2m_toggle_cache(struct vcpu *v, bool was_enabled)
> > > +{
> > > +bool now_enabled = vcpu_has_cache_enabled(v);
> > > +
> > > +/* This function can only work with the current vCPU. */
> > > +ASSERT(v == current);
> > 
> > NIT: same about struct vcpu* as parameter when only current can be used
> > 
> > 
> > > +/*
> > > + * If switching the MMU+caches on, need to invalidate the caches.
> > > + * If switching it off, need to clean the caches.
> > > + * Clean + invalidate does the trick always.
> > > + */
> > > +if ( was_enabled != now_enabled )
> > > +p2m_flush_vm(v);
> > > +
> > > +/* Caches are now on, stop trapping VM ops (until a S/W op) */
> > > +if ( now_enabled )
> > > +vcpu_hcr_clear_flags(v, HCR_TVM);
> > > +}
> > > +
> > >   mfn_t gfn_to_mfn(struct domain *d, gfn_t gfn)
> > >   {
> > >   return p2m_lookup(d, gfn, NULL);
> > > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > > index 169b57cb6b..cdc10eee5a 100644
> > > --- a/xen/arch/arm/traps.c
> > > +++ b/xen/arch/arm/traps.c
> > > @@ -98,7 +98,7 @@ register_t get_default_hcr_flags(void)
> > >   {
> > >   return  (HCR_PTW|HCR_BSU_INNER|HCR_AMO|HCR_IMO|HCR_FMO|HCR_VM|
> > >(vwfi != NATIVE ? (HCR_TWI|HCR_TWE) : 0) |
> > > - HCR_TSC|HCR_TAC|HCR_SWIO|HCR_TIDCP|HCR_FB);
> > > + HCR_TSC|HCR_TAC|HCR_SWIO|HCR_TIDCP|HCR_FB|HCR_TSW);
> > >   }
> > > static enum {
> > > diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
> > > index 49529b97cd..dc46d9d0d7 100644
> > > --- a/xen/arch/arm/vcpreg.c
> > > +++ b/xen/arch/arm/vcpreg.c
> > > @@ -45,9 +45,14 @@
> > >   #define TVM_REG(sz, func, reg...)
> > > \
> > >   static bool func(struct cpu_user_regs *regs, uint##sz##_t *r, bool read)
> > > \
> > >   {
> > > \
> > > +struct vcpu *v = current;
> > > \
> > > +bool cache_enabled = vcpu_has_cache_enabled(v);
> > > \
> > > +
> > > \
> > >   GUEST_BUG_ON(read);
> > > \
> > >   WRITE_SYSREG##sz(*r, reg);
> > > \
> > >   
> > > \
> > > +p2m_toggle_cache(v, cache_enabled);
> > > \
> > 
> > This will affect all the registers trapped with TVM. Shouldn't we only
> > call p2m_toggle_cache when relevant? i.e. when changing SCTLR?
> > I think it would be better to only modify the SCTLR emulation handler.
> 
> This is made on purpose, you increase the chance to disable TVM as soon as
> possible. If you only rely on SCTLR, you may end up to trap a lot of registers
> for a long time.
> 
> FWIW, as I already wrote in the commit message, this is based on what KVM
> does.

I missed that. As you explain it, it makes sense. Maybe worth adding an
explicit statement about it: "On ARM64, we call p2m_toggle_cache from on
the TVM-trapped register handlers to increase the chances of disabling
TVM as soon as possible."

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable-smoke test] 129512: tolerable all pass - PUSHED

[osstest service owner]

flight 129512 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129512/

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  58f904c4cf9fc5a49e7807fd91cd2523fa8dd191
baseline version:
 xen  2347a9b639b0ee3988f07e2227a6ca6e2e945418

Last test of basis   129505  2018-11-06 11:01:06 Z0 days
Testing same since   129512  2018-11-06 15:00:54 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  Paul Durrant 
  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
   2347a9b639..58f904c4cf  58f904c4cf9fc5a49e7807fd91cd2523fa8dd191 -> smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v8] arch/x86: Add registers to vm_event

[Tamas K Lengyel]

On Mon, Nov 5, 2018 at 2:54 AM Alexandru Stefan ISAILA
 wrote:
>
> This patch adds a couple of regs to the vm_event that are used by
> the introspection. The base, limit and ar
> bits are compressed into a uint64_t union so as not to enlarge the
> vm_event.
>
> Signed-off-by: Alexandru Isaila 

Acked-by: Tamas K Lengyel 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Does XEN ARM support RTC in domu?

[Stefano Stabellini]

On Tue, 6 Nov 2018, Peng Fan wrote:
> Hi Julien,
> 
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> > Peng Fan
> > Sent: 2018年11月5日 10:11
> > To: Julien Grall ; xen-devel@lists.xenproject.org;
> > Stefano Stabellini 
> > Subject: Re: [Xen-devel] Does XEN ARM support RTC in domu?
> > 
> > Hi Julien,
> > 
> > > >>
> > > >>>
> > > >>> Just have a question, does XEN ARM support RTC in domu? To support
> > > >>> Android
> > > >> in DomU, RTC is needed for alarm, but I did not find information
> > > >> about RTC on xen for domu. So this need a new RTC paravirtualization
> > driver?
> > > Any suggestions?
> > > >>
> > > >> By RTC, do you mean Real-Time Clock? Something like PL031? Or do
> > > >> you have something else in mind?
> > > >
> > > > Yes, Real Time Clock like PL031 in DomU. I do not have a good idea
> > > > support RTC in ARM DomU, KVM and XEN x86 seems use emulated RTC in
> > > > qemu. Thinking of paravirtual RTC, and dom0 control the expire time
> > > > for
> > > alarm.
> > >
> > > The PL031 is quite small (based on the QEMU version). So I think it
> > > would be fine to provide an emulation in the hypervisor.
> > 
> > Ok. Just like the hvm x86, implement emulate PL031 inside XEN. I'll give a 
> > try.
> 
> Just a follow up question, emulating PL031 in xen, do you have idea how to 
> inject virtual interrupt to domu?
> The interrupt should be only cpu interface interrupt, I think.

Have a loop at the existing virtual timer: xen/arch/arm/vtimer.c
It should give you a decent idea.___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Dom0 kernel 4.14 with SMP randomly crashing

[Rishi]

On Tue, Nov 6, 2018 at 5:47 PM Wei Liu  wrote:

> On Tue, Nov 06, 2018 at 03:31:31PM +0530, Rishi wrote:
> >
> > So after knowing the stack trace, it appears that the CPU was getting
> stuck
> > for xen_hypercall_xen_version
>
> That hypercall is used when a PV kernel (re-)enables interrupts. See
> xen_irq_enable. The purpose is to force the kernel to switch to
> hypervisor.
>
> >
> > watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [swapper/0:0]
> >
> >
> > [30569.582740] watchdog: BUG: soft lockup - CPU#0 stuck for 23s!
> > [swapper/0:0]
> >
> > [30569.588186] Kernel panic - not syncing: softlockup: hung tasks
> >
> > [30569.591307] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G L
> 4.19.1
> > #1
> >
> > [30569.595110] Hardware name: Xen HVM domU, BIOS 4.4.1-xs132257
> 12/12/2016
> >
> > [30569.598356] Call Trace:
> >
> > [30569.599597]  
> >
> > [30569.600920]  dump_stack+0x5a/0x73
> >
> > [30569.602998]  panic+0xe8/0x249
> >
> > [30569.604806]  watchdog_timer_fn+0x200/0x230
> >
> > [30569.607029]  ? softlockup_fn+0x40/0x40
> >
> > [30569.609246]  __hrtimer_run_queues+0x133/0x270
> >
> > [30569.611712]  hrtimer_interrupt+0xfb/0x260
> >
> > [30569.613800]  xen_timer_interrupt+0x1b/0x30
> >
> > [30569.616972]  __handle_irq_event_percpu+0x69/0x1a0
> >
> > [30569.619831]  handle_irq_event_percpu+0x30/0x70
> >
> > [30569.622382]  handle_percpu_irq+0x34/0x50
> >
> > [30569.625048]  generic_handle_irq+0x1e/0x30
> >
> > [30569.627216]  __evtchn_fifo_handle_events+0x163/0x1a0
> >
> > [30569.629955]  __xen_evtchn_do_upcall+0x41/0x70
> >
> > [30569.632612]  xen_evtchn_do_upcall+0x27/0x50
> >
> > [30569.635136]  xen_do_hypervisor_callback+0x29/0x40
> >
> > [30569.638181] RIP: e030:xen_hypercall_xen_version+0xa/0x20
>
> What is the asm code for this RIP?
>
>
> Wei.
>

The issue of crash is getting resolved with appending "noirqbalance" at xen
command line. This way all dom0 cpus are available but not irq balanced at
xen.

Even though I'm running irqbalance service in dom0 the irqs seems to be not
moving. <- this is dom0 perspective, I do not know yet, if it follows Xen
irq.

I tried objdump, while I have  have the function in out but there is no asm
code of it. Its just "..."

81001220 :

...


81001240 :

...

All "hypercalls" appear similarly.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] x86 Community Call: Nov 14 - 15:00 - 16:00 UTC - Call for Agenda Items

[Jan Beulich]

>>> On 02.11.18 at 18:59,  wrote:
> It’s time again for the x86 community call: for the agenda see 
> https://docs.google.com/document/d/1RxW-iwcFFuKzNjjEqLEtiwFVHgAUlk35c0EtTkRE1 
> k4/edit#
> 
> Please propose new agenda items by next Friday (feel free to just add them 
> to the document or reply to this mail)

I've just added a TMEM item, and seeing only Daniel from Oracle on the
Cc list here I've added Konrad so he might arrange for someone to
attend to clarify their intentions with it.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] p2m: move p2m-common.h inclusion point

[George Dunlap]

On 10/05/2018 11:14 AM, Jan Beulich wrote:
> The header is (hence its name) supposed to be a helper for the per-arch
> p2m.h files. It was never supposed to be included directly, and for the
> purpose of putting common function declarations into the common header
> it is more helpful if things like p2m_t are already available at the
> inclusion point.
> 
> Take the opportunity and also ditch a duplicate public/memory.h from the
> ARM header.
> 
> Signed-off-by: Jan Beulich 

Acked-by: George Dunlap 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Ping: [PATCH] p2m: move p2m-common.h inclusion point

[Jan Beulich]

>>> On 05.10.18 at 12:14,  wrote:
> The header is (hence its name) supposed to be a helper for the per-arch
> p2m.h files. It was never supposed to be included directly, and for the
> purpose of putting common function declarations into the common header
> it is more helpful if things like p2m_t are already available at the
> inclusion point.
> 
> Take the opportunity and also ditch a duplicate public/memory.h from the
> ARM header.
> 
> Signed-off-by: Jan Beulich 

Can I get an ack or otherwise from one of you two, please?

Thanks, Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] p2m: move p2m-common.h inclusion point

[Jan Beulich]

>>> On 05.10.18 at 12:21,  wrote:
>>  -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 05 October 2018 11:14
>> To: xen-devel 
>> Cc: Julien Grall ; Andrew Cooper
>> ; Paul Durrant ; Wei
>> Liu ; George Dunlap ; Ian
>> Jackson ; Stefano Stabellini
>> ; Konrad Rzeszutek Wilk ;
>> Tim (Xen.org) 
>> Subject: [PATCH] p2m: move p2m-common.h inclusion point
>> 
>> The header is (hence its name) supposed to be a helper for the per-arch
>> p2m.h files. It was never supposed to be included directly, and for the
>> purpose of putting common function declarations into the common header
>> it is more helpful if things like p2m_t are already available at the
>> inclusion point.
>> 
>> Take the opportunity and also ditch a duplicate public/memory.h from the
>> ARM header.
>> 
>> Signed-off-by: Jan Beulich 
> 
> I suppose you could now drop the 'forward enum declaration' part of my patch 
> now that it is no longer forwards (depending on which is committed first of 
> course).

Could you remind me which patch and/or header this was in?
I can't seem to be able to locate it ...

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/6] libx86: Split x86_cpuid_policy_fill_native() out of calculate_raw_policy()

[Roger Pau Monné]

On Mon, Nov 05, 2018 at 11:21:03AM +, Andrew Cooper wrote:
> This will shortly be wanted by the userspace emulator harnesses as well.
> 
> Consolidate the cpuid{,_count}_leaf() helpers beside the structure definition,
> rather than having them scattered throughout Xen.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Roger Pau Monné 

I'm slightly worried about the _native prefix in the function name, if
this is run on Dom0 userspace the _native part of this is dubious,
since the policy returned is going to be provided by Xen, and thus
might not match the host one. I don't have a better name
recommendation, so I'm fine with this.

> diff --git a/xen/lib/x86/cpuid.c b/xen/lib/x86/cpuid.c
> index a63e42b..ddd3821 100644
> --- a/xen/lib/x86/cpuid.c
> +++ b/xen/lib/x86/cpuid.c
> @@ -2,6 +2,114 @@
>  
>  #include 
>  
> +void x86_cpuid_policy_fill_native(struct cpuid_policy *p)
> +{
> +unsigned int i;
> +
> +cpuid_leaf(0, >basic.raw[0]);
> +for ( i = 1; i < min(ARRAY_SIZE(p->basic.raw),
> + p->basic.max_leaf + 1ul); ++i )
> +{
> +switch ( i )
> +{
> +case 0x4: case 0x7: case 0xb: case 0xd:
> +/* Multi-invocation leaves.  Deferred. */
> +continue;
> +}
> +
> +cpuid_leaf(i, >basic.raw[i]);
> +}
> +
> +if ( p->basic.max_leaf >= 4 )
> +{
> +for ( i = 0; i < ARRAY_SIZE(p->cache.raw); ++i )
> +{
> +union {
> +struct cpuid_leaf l;
> +struct cpuid_cache_leaf c;
> +} u;
> +
> +cpuid_count_leaf(4, i, );
> +
> +if ( u.c.type == 0 )
> +break;
> +
> +p->cache.subleaf[i] = u.c;
> +}
> +
> +/*
> + * The choice of CPUID_GUEST_NR_CACHE is arbitrary.  It is expected
> + * that it will eventually need increasing for future hardware.
> + */
> +#ifdef __XEN__
> +if ( i == ARRAY_SIZE(p->cache.raw) )
> +printk(XENLOG_WARNING
> +   "CPUID: Insufficient Leaf 4 space for this hardware\n");

It would be good to provide some logging abstraction that can be used
by both the tools and Xen, ie:

printf(LIBX86_WARN, "...");

And then add a couple of defines for __XEN__ and __XEN_TOOLS__ as
required. Can be done in a followup patch IMO.

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 6/6] x86/emul: dedup hvmemul_cpuid() and pv_emul_cpuid()

[Jan Beulich]

>>> On 06.11.18 at 16:52,  wrote:
> On 06/11/18 15:38, Jan Beulich wrote:
> On 05.11.18 at 12:21,  wrote:
>>> They are identical, so provide a single x86emul_cpuid() instead.
>>>
>>> As x86_emulate() now only uses the ->cpuid() hook for real CPUID 
> instructions,
>>> the hook can be omitted from all special-purpose emulation ops.
>> So I was expecting the hook to go away altogether, but I
>> now realize that it can't because of some of the customization
>> that's needed. That, in turn, means that the removal of the
>> hook specification as per above will get us into problems the
>> moment we need to check a feature that can't be taken
>> straight from the policy object. I'm therefore unconvinced we
>> actually want to go this far. It'll require enough care already
>> to not blindly clone a new vcpu_has_...() wrongly from the
>> many pre-existing examples in such a case. Thoughts?
> 
> All dynamic bits in CPUID are derived from other control state.  e.g. we
> check CR4.OSXSAVE, not CPUID.OSXSAVE.  The other dynamic bits are APIC,
> which comes from MSR_APIC_BASE, and OSPKE which also comes from CR4.
> 
> In the emulator itself, I think it would be a bug if we ever had
> vcpu_has_osxsave etc, because that isn't how pipelines actually behave. 
> The feature checks here are semantically equivalent to "do the
> instruction decode and execution units have silicon to cope with these
> instructions".

I agree that vcpu_has_os* makes no sense, but the APIC bit for
example isn't really pipeline / decoder related. However, one
issue already might be that in order for bits in a (sub)leaf above
(guest) limits to come out all clear, it is guest_cpuid() which cuts
things off. Neither cpuid_featureset_to_policy() nor its inverse
nor sanitise_featureset() look to zap fields above limits, in case
they've been previously set to non-zero values. Am I overlooking
something?

Furthermore I wouldn't exclude that we may need to look at a
hypervisor or Viridian leaf at some point. The dynamic vPMU
adjustments also look potentially problematic, if we were to
emulate RDPMC (albeit they're DS-related only right now). And
then there's the dynamic exposing of MONITOR for PV; granted
I don't expect us to ever emulate this for PV, but it shows the
general issue. Plus there's SYSCALL, the insn emulation of which
currently doesn't check the (dynamically adjusted) CPUID bit.
And finally LWP, which again we can only hope we'll never have
to emulate.

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 8/8] tools/libvchan: libxenvchan_client_init: use ENOENT for no server

[Ian Jackson]

Marek Marczykowski-Górecki writes ("Re: [PATCH 8/8] tools/libvchan: 
libxenvchan_client_init: use ENOENT for no server"):
> On Tue, Nov 06, 2018 at 11:45:47AM +, Ian Jackson wrote:
> > Right.  Marek, this series was intended to help with vchan for qmp.
> > But obviously I don't want to break anything else.  I don't think this
> > should break anything but I would appreciate a review or at least an
> > opinion...
> 
> Does xentoollog require any explicit configuration? If yes, that would
> break non-xen-tools users (including Qubes). Otherwise looks good.
> Thanks!

Hrm.

libvchan already takes an xtl logger as an argument, and passes that
on to lower-layer libraries.  So it's already in there.  The only
difference is that it is used directly by libchan now.

But I tried to make an argument that the new log message could cause
no problem and I think that's actually wrong.  libvchan right now
passes that logger to xengntshr_open and xenevtchn_open, but those
both tolerate NULL (and make up their own logger which writes to
stderr).

But with my change, NULL will cause a crash if new error condition
occurs.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 6/6] x86/emul: dedup hvmemul_cpuid() and pv_emul_cpuid()

[Andrew Cooper]

On 06/11/18 15:38, Jan Beulich wrote:
 On 05.11.18 at 12:21,  wrote:
>> They are identical, so provide a single x86emul_cpuid() instead.
>>
>> As x86_emulate() now only uses the ->cpuid() hook for real CPUID 
>> instructions,
>> the hook can be omitted from all special-purpose emulation ops.
> So I was expecting the hook to go away altogether, but I
> now realize that it can't because of some of the customization
> that's needed. That, in turn, means that the removal of the
> hook specification as per above will get us into problems the
> moment we need to check a feature that can't be taken
> straight from the policy object. I'm therefore unconvinced we
> actually want to go this far. It'll require enough care already
> to not blindly clone a new vcpu_has_...() wrongly from the
> many pre-existing examples in such a case. Thoughts?

All dynamic bits in CPUID are derived from other control state.  e.g. we
check CR4.OSXSAVE, not CPUID.OSXSAVE.  The other dynamic bits are APIC,
which comes from MSR_APIC_BASE, and OSPKE which also comes from CR4.

In the emulator itself, I think it would be a bug if we ever had
vcpu_has_osxsave etc, because that isn't how pipelines actually behave. 
The feature checks here are semantically equivalent to "do the
instruction decode and execution units have silicon to cope with these
instructions".

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 10/12] IOMMU: introduce IOMMU_MIXED config option

[Jan Beulich]

>>> On 02.10.18 at 12:38,  wrote:
> On 02/10/2018 11:18, Jan Beulich wrote:
>> ARM is intended to gain support for heterogeneous IOMMUs on a single
>> system. This not only disallows boot time replacement of respective
>> indirect calls (handling of which is the main goal of the introduction
>> here), but more generally disallows calls using the iommu_ops() return
>> value directly - all such calls need to have means (commonly a domain
>> pointer) to know the targeted IOMMU.
>> 
>> Disallow all hooks lacking such context for the time being, which in
>> effect is some dead code elimination for ARM. Once extended suitably,
>> individual of these hooks can be moved out of their guards again in the
>> future.
> 
> While in theory it is possible to have platform with hetereneous IOMMUs. 
>   I don't see such such support coming in Xen for the foreseeable 
> future. Note that even Linux does not support such case.
> 
> This patch is going to make more complicate to unshare page-tables as 
> now we would need to care of mixed case. So I would rather not set 
> IOMMU_MIXED on Arm until we have a use case for it.

So if I drop this here, how would you want iommu_get_ops()
get handled on Arm (patch 11)? Right now I'd mean to leave it
alone, but it could also be switched to the (new) x86 way (but
that would then perhaps make mixed mode introduction more
difficult down the road), allowing to get away with fewer
#ifdef-s.

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 6/6] x86/emul: dedup hvmemul_cpuid() and pv_emul_cpuid()

[Jan Beulich]

>>> On 05.11.18 at 12:21,  wrote:
> They are identical, so provide a single x86emul_cpuid() instead.
> 
> As x86_emulate() now only uses the ->cpuid() hook for real CPUID instructions,
> the hook can be omitted from all special-purpose emulation ops.

So I was expecting the hook to go away altogether, but I
now realize that it can't because of some of the customization
that's needed. That, in turn, means that the removal of the
hook specification as per above will get us into problems the
moment we need to check a feature that can't be taken
straight from the policy object. I'm therefore unconvinced we
actually want to go this far. It'll require enough care already
to not blindly clone a new vcpu_has_...() wrongly from the
many pre-existing examples in such a case. Thoughts?

Folding the two identical implementations, otoh, is fine with me.

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [qemu-mainline test] 129453: regressions - trouble: broken/fail/pass

[osstest service owner]

flight 129453 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129453/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale  broken
 test-armhf-armhf-xl-arndale   4 host-install(4)broken REGR. vs. 129405
 test-armhf-armhf-libvirt-raw 16 guest-start.2fail REGR. vs. 129405

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 129405
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 129405
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 129405
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 129405
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 129405
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-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-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-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-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-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-libvirt 13 migrate-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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  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  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-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-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail 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

version targeted for testing:
 qemuub2f7a038bb4c4fc5ce6b8486e8513dfd97665e2a
baseline version:
 qemuu7d56239f159afc2e7bd42623947e56ba48f37836

Last test of basis   129405  2018-11-04 09:16:39 Z2 days
Testing same since   129453  2018-11-05 11:37:04 Z1 days1 attempts


People who touched revisions under test:
  Peter Maydell 
  Richard Henderson 

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  

Re: [Xen-devel] [PATCH 5/6] x86/emul: Don't use the ->cpuid() hook for feature checks

[Jan Beulich]

>>> On 05.11.18 at 12:21,  wrote:
> For a release build of xen, this removes almost 4k of code volume, and removes
> a function pointer call from every instantiation.
> 
>   add/remove: 0/1 grow/shrink: 0/3 up/down: 0/-3877 (-3877)
>   Function old new   delta
>   adjust_bnd   227 205 -22
>   x86_decode  81368096 -40
>   vcpu_has.isra133   --133
>   x86_emulate   118687  115005   -3682
>   Total: Before=3309200, After=3305323, chg -0.12%
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 4/6] x86/emul: Pass a full cpuid_policy into x86_emulate()

[Jan Beulich]

>>> On 05.11.18 at 12:21,  wrote:
> This will be used to simplify feature checking.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 3/6] tools/x86emul: Use struct cpuid_policy in the userspace test harnesses

[Jan Beulich]

>>> On 05.11.18 at 12:21,  wrote:
> +#define cache_line_size() (cp.basic.clflush_size * 8)

While the parentheses are indeed needed here, ...

> +#define cpu_has_mmx   (cp.basic.mmx)

... they could be omitted here. I'd prefer if they were dropped,
but whichever way you decide to do
Acked-by: Jan Beulich 

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 2/8] x86/nestedhvm: introduce vvmcx_valid()

[Boris Ostrovsky]

On 11/6/18 7:07 AM, Sergey Dyasli wrote:
> As a convenient helper function and refactor the code to use it.
>
> No functional change.
>
> Signed-off-by: Sergey Dyasli 
> ---
> CC: Boris Ostrovsky 
> CC: Suravee Suthikulpanit 
> CC: Brian Woods 
>
> v2:
> - Use the new helper in nestedsvm.c

Reviewed-by: Boris Ostrovsky 



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/emul: Assert the STI shadow when POPF sets the interrupt flag

[Jan Beulich]

>>> On 06.11.18 at 15:09,  wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -4061,6 +4061,12 @@ x86_emulate(
>  }
>  }
>  dst.val &= EFLAGS_MODIFIABLE;
> +
> +/* When IF transitions from 0 to 1, assert the STI shadow. */
> +if ( !(_regs.eflags & X86_EFLAGS_IF) &&
> + ((dst.val & ~mask) & X86_EFLAGS_IF) )
> +ctxt->retire.sti = true;

I'm entirely unaware that POPF behaves the same way as STI in this
regard. Therefore: Are you sure? Can you point me to where this is
spelled out?

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 0/3] x86emul: VME/PVI mode fixes

[Jan Beulich]

>>> On 06.11.18 at 15:21,  wrote:
> On 06/11/18 13:33, Jan Beulich wrote:
>> 1: skip VIF processing in VME mode for 16-bit POPF at IOPL 3
>> 2: raise #GP(0) in VME mode for POPF with TF set in new value
> 
> I'm afraid that I think there is still a bug with PVI emulation.
> 
> We only ever read cr4 when operating in vm86, which means that the later
> logic checking VME doesn't apply to 16bit protected mode execution.

And where on the instruction page in the SDM do you see CR4.PVI
mattering for POPF? Quite the opposite - there is:

"(The protected-mode virtual-interrupt feature — enabled by
 setting CR4.PVI — affects the CLI and STI instructions in the
 same manner as the virtual-8086 mode extensions. POPF,
 however, is not affected by CR4.PVI.)"

Even if there was a further issue, it would be orthogonal to the
changes here, i.e. you'd only make me add yet another patch.
IOW I don't think the comment affects the patches currently in
this series.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 0/3] x86emul: VME/PVI mode fixes

[Andrew Cooper]

On 06/11/18 13:33, Jan Beulich wrote:
> 1: skip VIF processing in VME mode for 16-bit POPF at IOPL 3
> 2: raise #GP(0) in VME mode for POPF with TF set in new value

I'm afraid that I think there is still a bug with PVI emulation.

We only ever read cr4 when operating in vm86, which means that the later
logic checking VME doesn't apply to 16bit protected mode execution.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC 09/16] xen/arm: p2m: Introduce a function to resolve translation fault

[Julien Grall]

Hi Stefano,

On 05/11/2018 17:56, Stefano Stabellini wrote:

On Mon, 5 Nov 2018, Julien Grall wrote:

On 02/11/2018 23:27, Stefano Stabellini wrote:

On Mon, 8 Oct 2018, Julien Grall wrote:

Currently a Stage-2 translation fault could happen:
  1) MMIO emulation
  2) When the page-tables is been updated using Break-Before-Make

^ have


  3) Page not mapped

A follow-up patch will re-purpose the valid bit in an entry to generate
translation fault. This would be used to do an action on each entries to

  ^entry


track page used for a given period.

  ^pages




A new function is introduced to try to resolve a translation fault. This
will include 2) and the new way to generate fault explained above.


I can see the code does what you describe, but I don't understand why we
are doing this. What is missing in the commit message is the explanation
of the relationship between the future goal of repurposing the valid bit
and the introduction of a function to handle Break-Before-Make stage2
faults. Does it fix an issue with Break-Before-Make that we currently
have? Or it becomes needed due to the repurposing of valid? If so, why?


This does not fix any issue with BBM. The valid bit adds a 4th reasons for
translation fault. Both BBM and the valid bit will require to walk the
page-tables.

For the valid bit, we will need to walk the page-table in order to fixup the
entry (i.e set valid bit). We also can't use p2m_lookup(...) has it only tell
you the mapping exists, the valid bit may still not be set.

So we need to provide a new helper to walk the page-table and fixup an entry.


OK. Please expand a bit the commit message.


Sure.




+break;
+}
+
+/*
+ * If the valid bit of the entry is set, it means someone was playing
with
+ * the Stage-2 page table. Nothing to do and mark the fault as
resolved.
+ */
+if ( lpae_is_valid(entry) )
+{
+resolved = true;
+goto out_unmap;
+}
+
+/*
+ * The valid bit is unset. If the entry is still not valid then the
fault
+ * cannot be resolved, exit and report it.
+ */
+if ( !p2m_is_valid(entry) )
+goto out_unmap;
+
+/*
+ * Now we have an entry with valid bit unset, but still valid from
+ * the P2M point of view.
+ *
+ * For entry pointing to a table, the table will be invalidated.

^ entries



+ * For entry pointing to a block/page, no work to do for now.

^ entries


I am not entirely sure why it should be plural here. We are dealing with only
one entry it.


I was trying to make the grammar work as a generic sentence. To make it
singular we would have to remove "For":

   If an entry is pointing to a table, the table will be invalidated.
   If an entry is pointing to a block/page, no work to do for now.


I will use the singular version.







+ */
+if ( lpae_is_table(entry, level) )
+p2m_invalidate_table(p2m, lpae_get_mfn(entry));


Maybe because I haven't read the rest of the patches, it is not clear to
me why in the case of an entry pointing to a table we need to invalidate
it, and otherwise set valid to 1.


This was written in the commit message:

"To avoid invalidating all the page-tables entries in one go. It is
possible to invalidate the top-level table and then on trap invalidate
the table one-level down. This will be repeated until a block/page entry
has been reached."

It is mostly to spread the cost of invalidating the page-tables. With this
solution, you only need to clear the valid bit of the top-level entries to
invalidate the full P2M.

On the first access, you will trap, set the entry of the first "invalid
entry", and invalidate the next level if necessary.

The access will then be retried. If trapped, the process is repeated until all
the entries are valid.

It is possible to optimize it, avoiding intermediate trap when necessary. But
I would not bother looking at that for now. Indeed, this will be used for
lowering down the cost of set/way cache maintenance emulation. Any guest using
that already knows that a big cost will incur.


So instead of walking the page table in Xen, finding all the leaf
(level==3) entries that we need to set !valid, we just set !valid one of
the higher levels entries. On access, we'll trap in Xen, then set the
higher level entry back to valid but the direct children to !valid. And
we'll cycle again through this until the table entries are valid and the
leaf entry is the only invalid one: at that point we'll only set it to
valid and the whole translation for that address is valid again.


That's correct.



Very inefficient, but very simple to implement in Xen. A good way to > penalize 
guests that are using instructions they should not be using :-)


I am not convinced you will see a major slowdown. As you will quickly go through 
all the level, ending to only 

[Xen-devel] [PATCH] x86/emul: Assert the STI shadow when POPF sets the interrupt flag

[Andrew Cooper]

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
---
 xen/arch/x86/x86_emulate/x86_emulate.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
b/xen/arch/x86/x86_emulate/x86_emulate.c
index e69dfdd..e93532d 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4061,6 +4061,12 @@ x86_emulate(
 }
 }
 dst.val &= EFLAGS_MODIFIABLE;
+
+/* When IF transitions from 0 to 1, assert the STI shadow. */
+if ( !(_regs.eflags & X86_EFLAGS_IF) &&
+ ((dst.val & ~mask) & X86_EFLAGS_IF) )
+ctxt->retire.sti = true;
+
 _regs.eflags &= mask;
 _regs.eflags |= (dst.val & ~mask) | X86_EFLAGS_MBS;
 break;
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable-smoke test] 129505: tolerable all pass - PUSHED

[osstest service owner]

flight 129505 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129505/

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  2347a9b639b0ee3988f07e2227a6ca6e2e945418
baseline version:
 xen  ec651bd24603aacd4843008bd6f2e395ce92adae

Last test of basis   129473  2018-11-05 20:00:57 Z0 days
Testing same since   129505  2018-11-06 11:01:06 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  Juergen Gross 
  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
   ec651bd246..2347a9b639  2347a9b639b0ee3988f07e2227a6ca6e2e945418 -> smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 3/3] x86emul: consolidate CR4 handling

[Jan Beulich]

Now that there's an almost unconditional CR4 read right at the beginning
of x86_emulate(), centralize its reading there and use result and value
everywhere else without further invoking the hook.

Subsequently we may want to consider having the callers provide
whichever value they deem appropriate in their contexts, to avoid
invoking the hook altogether for this purpose.

Signed-off-by: Jan Beulich 
---
v2: Don't allow 32-bit PUSHF/POPF in VME mode to get away without
#GP(0).

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1163,10 +1163,19 @@ do {
 ops->write_segment(x86_seg_cs, cs, ctxt);   \
 })
 
+#define check_cr4() ({  \
+if ( unlikely(cr4_rc != X86EMUL_OKAY) ) \
+{   \
+rc = cr4_rc;\
+goto done;  \
+}   \
+})
+
 static int _get_fpu(
 enum x86_emulate_fpu_type type,
 struct x86_emulate_ctxt *ctxt,
-const struct x86_emulate_ops *ops)
+const struct x86_emulate_ops *ops,
+unsigned long cr4, int cr4_rc)
 {
 uint64_t xcr0;
 int rc;
@@ -1208,11 +1217,7 @@ static int _get_fpu(
 fail_if(!ops->read_cr);
 if ( type >= X86EMUL_FPU_xmm )
 {
-unsigned long cr4;
-
-rc = ops->read_cr(4, , ctxt);
-if ( rc != X86EMUL_OKAY )
-return rc;
+check_cr4();
 generate_exception_if(!(cr4 & ((type == X86EMUL_FPU_xmm)
? X86_CR4_OSFXSR : 
X86_CR4_OSXSAVE)),
   EXC_UD);
@@ -1243,7 +1248,7 @@ static int _get_fpu(
 
 #define get_fpu(type)   \
 do {\
-rc = _get_fpu(fpu_type = (type), ctxt, ops);\
+rc = _get_fpu(fpu_type = (type), ctxt, ops, cr4, cr4_rc);   \
 if ( rc ) goto done;\
 } while (0)
 
@@ -1603,13 +1608,9 @@ _mode_iopl(
 _iopl;  \
 })
 #define mode_vif() ({\
-cr4 = 0; \
-if ( ops->read_cr && get_cpl(ctxt, ops) == 3 )   \
-{\
-rc = ops->read_cr(4, , ctxt);\
-if ( rc != X86EMUL_OKAY ) goto done; \
-}\
-!!(cr4 & (_regs.eflags & X86_EFLAGS_VM ? X86_CR4_VME : X86_CR4_PVI)); \
+check_cr4(); \
+get_cpl(ctxt, ops) == 3 &&   \
+(cr4 & (_regs.eflags & X86_EFLAGS_VM ? X86_CR4_VME : X86_CR4_PVI)); \
 })
 
 static int ioport_access_check(
@@ -2185,14 +2186,11 @@ static bool is_branch_step(struct x86_em
 }
 
 static bool umip_active(struct x86_emulate_ctxt *ctxt,
-const struct x86_emulate_ops *ops)
+const struct x86_emulate_ops *ops,
+unsigned long cr4)
 {
-unsigned long cr4;
-
 /* Intentionally not using mode_ring0() here to avoid its fail_if(). */
-return get_cpl(ctxt, ops) > 0 &&
-   ops->read_cr && ops->read_cr(4, , ctxt) == X86EMUL_OKAY &&
-   (cr4 & X86_CR4_UMIP);
+return get_cpl(ctxt, ops) > 0 && (cr4 & X86_CR4_UMIP);
 }
 
 static void adjust_bnd(struct x86_emulate_ctxt *ctxt,
@@ -3226,7 +3224,7 @@ x86_emulate(
 /* Shadow copy of register state. Committed on successful emulation. */
 struct cpu_user_regs _regs = *ctxt->regs;
 struct x86_emulate_state state;
-int rc;
+int rc, cr4_rc;
 uint8_t b, d, *opc = NULL;
 unsigned int first_byte = 0, insn_bytes = 0;
 bool singlestep = (_regs.eflags & X86_EFLAGS_TF) &&
@@ -3234,7 +3232,7 @@ x86_emulate(
 bool sfence = false;
 struct operand src = { .reg = PTR_POISON };
 struct operand dst = { .reg = PTR_POISON };
-unsigned long cr4;
+unsigned long cr4 = 0;
 enum x86_emulate_fpu_type fpu_type = X86EMUL_FPU_none;
 struct x86_emulate_stub stub = {};
 DECLARE_ALIGNED(mmval_t, mmval);
@@ -3247,6 +3245,8 @@ x86_emulate(
 
 ASSERT(ops->read);
 
+cr4_rc = ops->read_cr ? ops->read_cr(4, , ctxt) : X86EMUL_OKAY;
+
 generate_exception_if((mode_vif() &&
(_regs.eflags & X86_EFLAGS_VIF) &&
(_regs.eflags & X86_EFLAGS_VIP)),
@@ -4000,13 +4000,10 @@ x86_emulate(
 if ( (_regs.eflags & X86_EFLAGS_VM) &&
  MASK_EXTR(_regs.eflags, X86_EFLAGS_IOPL) != 3 )
 {
-cr4 = 0;
-if ( op_bytes == 2 && ops->read_cr )
-{
-rc = ops->read_cr(4, , ctxt);
-if ( rc != X86EMUL_OKAY )
-

[Xen-devel] [PATCH v2 2/3] x86emul: raise #GP(0) in VME mode for POPF with TF set in new value

[Jan Beulich]

This is a check explicitly listed by the instruction page in the SDM.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4050,6 +4050,7 @@ x86_emulate(
 if ( (cr4 & X86_CR4_VME) &&
  MASK_EXTR(_regs.eflags, X86_EFLAGS_IOPL) != 3 )
 {
+generate_exception_if(dst.val & X86_EFLAGS_TF, EXC_GP, 0);
 if ( dst.val & X86_EFLAGS_IF )
 {
 generate_exception_if(_regs.eflags & X86_EFLAGS_VIP,



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 1/3] x86emul: skip VIF processing in VME mode for 16-bit POPF at IOPL 3

[Jan Beulich]

At IOPL 3 CR4.VME is irrelevant.

Reported-by: Andrew Cooper 
Signed-off-by: Jan Beulich 
---
v2: New.

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4047,7 +4047,8 @@ x86_emulate(
 if ( op_bytes == 2 )
 {
 dst.val = (uint16_t)dst.val | (_regs.eflags & 0xu);
-if ( cr4 & X86_CR4_VME )
+if ( (cr4 & X86_CR4_VME) &&
+ MASK_EXTR(_regs.eflags, X86_EFLAGS_IOPL) != 3 )
 {
 if ( dst.val & X86_EFLAGS_IF )
 {



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/6] libx86: Split x86_cpuid_policy_fill_native() out of calculate_raw_policy()

[Jan Beulich]

>>> On 05.11.18 at 12:21,  wrote:
> --- a/xen/include/xen/lib/x86/cpuid.h
> +++ b/xen/include/xen/lib/x86/cpuid.h
> @@ -20,6 +20,21 @@ struct cpuid_leaf
>  uint32_t a, b, c, d;
>  };
>  
> +static inline void cpuid_leaf(uint32_t leaf, struct cpuid_leaf *l)
> +{
> +asm volatile ( "cpuid"
> +   : "=a" (l->a), "=b" (l->b), "=c" (l->c), "=d" (l->d)
> +   : "a" (leaf) );
> +}
> +
> +static inline void cpuid_count_leaf(
> +uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *l)
> +{
> +asm volatile ( "cpuid"
> +   : "=a" (l->a), "=b" (l->b), "=c" (l->c), "=d" (l->d)
> +   : "a" (leaf), "c" (subleaf) );
> +}

Especially with this now being library code (i.e. side effects like
serialization not being supposed to be of interest): Why
volatile?

> --- a/xen/lib/x86/cpuid.c
> +++ b/xen/lib/x86/cpuid.c
> @@ -2,6 +2,114 @@
>  
>  #include 
>  
> +void x86_cpuid_policy_fill_native(struct cpuid_policy *p)
> +{
> +unsigned int i;
> +
> +cpuid_leaf(0, >basic.raw[0]);
> +for ( i = 1; i < min(ARRAY_SIZE(p->basic.raw),
> + p->basic.max_leaf + 1ul); ++i )
> +{
> +switch ( i )
> +{
> +case 0x4: case 0x7: case 0xb: case 0xd:
> +/* Multi-invocation leaves.  Deferred. */
> +continue;
> +}
> +
> +cpuid_leaf(i, >basic.raw[i]);
> +}
> +
> +if ( p->basic.max_leaf >= 4 )
> +{
> +for ( i = 0; i < ARRAY_SIZE(p->cache.raw); ++i )
> +{
> +union {
> +struct cpuid_leaf l;
> +struct cpuid_cache_leaf c;
> +} u;
> +
> +cpuid_count_leaf(4, i, );
> +
> +if ( u.c.type == 0 )
> +break;
> +
> +p->cache.subleaf[i] = u.c;
> +}
> +
> +/*
> + * The choice of CPUID_GUEST_NR_CACHE is arbitrary.  It is expected
> + * that it will eventually need increasing for future hardware.
> + */
> +#ifdef __XEN__
> +if ( i == ARRAY_SIZE(p->cache.raw) )
> +printk(XENLOG_WARNING
> +   "CPUID: Insufficient Leaf 4 space for this hardware\n");
> +#endif

There being another similar instance further down, and possibly
new ones to appear later, plus such a warning potentially also
being of interest in the harness - would you mind abstracting
(could be as simple as making printk() and XENLOG_* available
where needed, provided there's no consumer which would
rather not want such logging) this so it can go without #ifdef-ary?

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 0/3] x86emul: VME/PVI mode fixes

[Jan Beulich]

1: skip VIF processing in VME mode for 16-bit POPF at IOPL 3
2: raise #GP(0) in VME mode for POPF with TF set in new value
3: consolidate CR4 handling

Jan




___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Dom0 kernel 4.14 with SMP randomly crashing

[Wei Liu]

On Tue, Nov 06, 2018 at 03:31:31PM +0530, Rishi wrote:
> 
> So after knowing the stack trace, it appears that the CPU was getting stuck
> for xen_hypercall_xen_version

That hypercall is used when a PV kernel (re-)enables interrupts. See
xen_irq_enable. The purpose is to force the kernel to switch to
hypervisor.

> 
> watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [swapper/0:0]
> 
> 
> [30569.582740] watchdog: BUG: soft lockup - CPU#0 stuck for 23s!
> [swapper/0:0]
> 
> [30569.588186] Kernel panic - not syncing: softlockup: hung tasks
> 
> [30569.591307] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G L
> 4.19.1
> #1
> 
> [30569.595110] Hardware name: Xen HVM domU, BIOS 4.4.1-xs132257 12/12/2016
> 
> [30569.598356] Call Trace:
> 
> [30569.599597]  
> 
> [30569.600920]  dump_stack+0x5a/0x73
> 
> [30569.602998]  panic+0xe8/0x249
> 
> [30569.604806]  watchdog_timer_fn+0x200/0x230
> 
> [30569.607029]  ? softlockup_fn+0x40/0x40
> 
> [30569.609246]  __hrtimer_run_queues+0x133/0x270
> 
> [30569.611712]  hrtimer_interrupt+0xfb/0x260
> 
> [30569.613800]  xen_timer_interrupt+0x1b/0x30
> 
> [30569.616972]  __handle_irq_event_percpu+0x69/0x1a0
> 
> [30569.619831]  handle_irq_event_percpu+0x30/0x70
> 
> [30569.622382]  handle_percpu_irq+0x34/0x50
> 
> [30569.625048]  generic_handle_irq+0x1e/0x30
> 
> [30569.627216]  __evtchn_fifo_handle_events+0x163/0x1a0
> 
> [30569.629955]  __xen_evtchn_do_upcall+0x41/0x70
> 
> [30569.632612]  xen_evtchn_do_upcall+0x27/0x50
> 
> [30569.635136]  xen_do_hypervisor_callback+0x29/0x40
> 
> [30569.638181] RIP: e030:xen_hypercall_xen_version+0xa/0x20

What is the asm code for this RIP?


Wei.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 2/6] SUPPORT.md: Add qemu-depriv section

[George Dunlap]

On 11/06/2018 09:08 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of George Dunlap
>> Sent: 05 November 2018 18:07
>> To: xen-devel@lists.xenproject.org
>> Cc: Stefano Stabellini ; Wei Liu
>> ; Konrad Wilk ; Andrew Cooper
>> ; Tim (Xen.org) ; George Dunlap
>> ; Ross Lagerwall ;
>> Julien Grall ; Jan Beulich ;
>> Anthony Perard ; Ian Jackson
>> 
>> Subject: [Xen-devel] [PATCH v4 2/6] SUPPORT.md: Add qemu-depriv section
>>
>> Signed-off-by: George Dunlap 
>> ---
>> Changes since v3:
>> - Moved from the qemu-depriv doc patches.
>> - Reword to include the possibility of having a non-dom0 "devicemodel"
>>   domain which may want to be protected
>> - Specify `Linux dom0` as the currently-tech-supported window
>>
>> 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 
>>  1 file changed, 20 insertions(+)
>>
>> diff --git a/SUPPORT.md b/SUPPORT.md
>> index 4f203da84a..1f0f5857a7 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 dom0: Tech Preview, with limited support
>> +
>> +This means adding extra restrictions to a device model in order to
>> +prevent a compromised device model from attack the rest of the domain
> 
> s/attack/attacking/

Yeah, this paragraph in particular seems to have challenged by ability
to form grammatically-correct English sentences... anyway thanks, I'll
fix it up on check-in.

 -George

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 8/8] tools/libvchan: libxenvchan_client_init: use ENOENT for no server

[Marek Marczykowski-Górecki]

On Tue, Nov 06, 2018 at 11:45:47AM +, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH 8/8] tools/libvchan: libxenvchan_client_init: use 
> ENOENT for no server"):
> > On Fri, Nov 02, 2018 at 05:01:13PM +, Ian Jackson wrote:
> > > * Promise that we will set errno to ENOENT if the server is not
> > >   yet set up.
> > > * Arrange that all ENOENT returns other than from the read of ring-ref
> > >   are turned into EIO, logging when we do so.
> > 
> > This sounds reasonable to me, but I would like to hear from Marek that
> > this doesn't break Qubes.
> 
> Right.  Marek, this series was intended to help with vchan for qmp.
> But obviously I don't want to break anything else.  I don't think this
> should break anything but I would appreciate a review or at least an
> opinion...

Does xentoollog require any explicit configuration? If yes, that would
break non-xen-tools users (including Qubes). Otherwise looks good.
Thanks!

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 7/8] x86/vvmx: correctly report vvmcs size

[Sergey Dyasli]

The size of Xen's virtual vmcs region is 4096 bytes (see comment about
Virtual VMCS layout in include/asm-x86/hvm/vmx/vvmx.h). Correctly report
it to the guest in case when VMCS shadowing is not available instead of
providing H/W value (which is usually smaller).

Signed-off-by: Sergey Dyasli 
---
v2:
- slight commit message change
---
 xen/arch/x86/hvm/vmx/vvmx.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 2f5370ceed..37d3cdd859 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -2101,6 +2101,14 @@ int nvmx_msr_read_intercept(unsigned int msr, u64 
*msr_content)
 data = (host_data & (~0ul << 32)) |
(vmcs->vmcs_revision_id & 0x7fff);
 unmap_domain_page(vmcs);
+
+if ( !cpu_has_vmx_vmcs_shadowing )
+{
+/* Report vmcs_region_size as 4096 */
+data &= ~VMX_BASIC_VMCS_SIZE_MASK;
+data |= 1ULL << 44;
+}
+
 break;
 }
 case MSR_IA32_VMX_PINBASED_CTLS:
-- 
2.17.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 2/8] x86/nestedhvm: introduce vvmcx_valid()

[Sergey Dyasli]

As a convenient helper function and refactor the code to use it.

No functional change.

Signed-off-by: Sergey Dyasli 
---
CC: Boris Ostrovsky 
CC: Suravee Suthikulpanit 
CC: Brian Woods 

v2:
- Use the new helper in nestedsvm.c
---
 xen/arch/x86/hvm/svm/nestedsvm.c|  2 +-
 xen/arch/x86/hvm/vmx/vvmx.c | 17 -
 xen/include/asm-x86/hvm/nestedhvm.h |  5 +
 3 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index 088b3fd562..9660202210 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -68,7 +68,7 @@ int nestedsvm_vmcb_map(struct vcpu *v, uint64_t vmcbaddr)
 struct nestedvcpu *nv = _nestedhvm(v);
 
 if (nv->nv_vvmcx != NULL && nv->nv_vvmcxaddr != vmcbaddr) {
-ASSERT(nv->nv_vvmcxaddr != INVALID_PADDR);
+ASSERT(vvmcx_valid(v));
 hvm_unmap_guest_frame(nv->nv_vvmcx, 1);
 nv->nv_vvmcx = NULL;
 nv->nv_vvmcxaddr = INVALID_PADDR;
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index c8bc8e6d11..d437f33193 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -489,8 +489,7 @@ static void vmfail(struct cpu_user_regs *regs, enum 
vmx_insn_errno errno)
 if ( errno == VMX_INSN_SUCCEED )
 return;
 
-if ( vcpu_nestedhvm(current).nv_vvmcxaddr != INVALID_PADDR &&
- errno != VMX_INSN_FAIL_INVALID )
+if ( vvmcx_valid(current) && errno != VMX_INSN_FAIL_INVALID )
 vmfail_valid(regs, errno);
 else
 vmfail_invalid(regs);
@@ -773,7 +772,7 @@ static void nvmx_purge_vvmcs(struct vcpu *v)
 int i;
 
 __clear_current_vvmcs(v);
-if ( nvcpu->nv_vvmcxaddr != INVALID_PADDR )
+if ( vvmcx_valid(v) )
 hvm_unmap_guest_frame(nvcpu->nv_vvmcx, 1);
 nvcpu->nv_vvmcx = NULL;
 nvcpu->nv_vvmcxaddr = INVALID_PADDR;
@@ -1564,7 +1563,7 @@ static int nvmx_vmresume(struct vcpu *v, struct 
cpu_user_regs *regs)
 struct nestedvcpu *nvcpu = _nestedhvm(v);
 
 /* check VMCS is valid and IO BITMAP is set */
-if ( (nvcpu->nv_vvmcxaddr != INVALID_PADDR) &&
+if ( vvmcx_valid(v) &&
 ((nvmx->iobitmap[0] && nvmx->iobitmap[1]) ||
 !(__n2_exec_control(v) & CPU_BASED_ACTIVATE_IO_BITMAP) ) )
 nvcpu->nv_vmentry_pending = 1;
@@ -1581,7 +1580,7 @@ static int nvmx_handle_vmresume(struct cpu_user_regs 
*regs)
 struct nestedvmx *nvmx = _2_nvmx(v);
 unsigned long intr_shadow;
 
-if ( vcpu_nestedhvm(v).nv_vvmcxaddr == INVALID_PADDR )
+if ( !vvmcx_valid(v) )
 {
 vmfail_invalid(regs);
 return X86EMUL_OKAY;
@@ -1612,7 +1611,7 @@ static int nvmx_handle_vmlaunch(struct cpu_user_regs 
*regs)
 unsigned long intr_shadow;
 int rc;
 
-if ( vcpu_nestedhvm(v).nv_vvmcxaddr == INVALID_PADDR )
+if ( !vvmcx_valid(v) )
 {
 vmfail_invalid(regs);
 return X86EMUL_OKAY;
@@ -1665,7 +1664,7 @@ static int nvmx_handle_vmptrld(struct cpu_user_regs *regs)
 if ( nvcpu->nv_vvmcxaddr != gpa )
 nvmx_purge_vvmcs(v);
 
-if ( nvcpu->nv_vvmcxaddr == INVALID_PADDR )
+if ( !vvmcx_valid(v) )
 {
 bool_t writable;
 void *vvmcx = hvm_map_guest_frame_rw(paddr_to_pfn(gpa), 1, );
@@ -1804,7 +1803,7 @@ static int nvmx_handle_vmread(struct cpu_user_regs *regs)
 if ( rc != X86EMUL_OKAY )
 return rc;
 
-if ( vcpu_nestedhvm(v).nv_vvmcxaddr == INVALID_PADDR )
+if ( !vvmcx_valid(v) )
 {
 vmfail_invalid(regs);
 return X86EMUL_OKAY;
@@ -1846,7 +1845,7 @@ static int nvmx_handle_vmwrite(struct cpu_user_regs *regs)
 if ( decode_vmx_inst(regs, , ) != X86EMUL_OKAY )
 return X86EMUL_EXCEPTION;
 
-if ( vcpu_nestedhvm(v).nv_vvmcxaddr == INVALID_PADDR )
+if ( !vvmcx_valid(v) )
 {
 vmfail_invalid(regs);
 return X86EMUL_OKAY;
diff --git a/xen/include/asm-x86/hvm/nestedhvm.h 
b/xen/include/asm-x86/hvm/nestedhvm.h
index 9d1c2742b5..e09fa9d47d 100644
--- a/xen/include/asm-x86/hvm/nestedhvm.h
+++ b/xen/include/asm-x86/hvm/nestedhvm.h
@@ -92,4 +92,9 @@ static inline void nestedhvm_set_cr(struct vcpu *v, unsigned 
int cr,
 v->arch.hvm.nvcpu.guest_cr[cr] = value;
 }
 
+static inline bool vvmcx_valid(const struct vcpu *v)
+{
+return vcpu_nestedhvm(v).nv_vvmcxaddr != INVALID_PADDR;
+}
+
 #endif /* _HVM_NESTEDHVM_H */
-- 
2.17.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 5/8] x86/vvmx: add VMX_INSN_VMPTRLD_WITH_VMXON_PTR errno

[Sergey Dyasli]

And make nvmx_handle_vmptrld() return the new errno in case the provided
address is the same as vmxon region address.

While at it, correct the return value for not-4KB-aligned case.

Signed-off-by: Sergey Dyasli 
Acked-by: Kevin Tian 
---
v2:
- Added Acked-by
---
 xen/arch/x86/hvm/vmx/vvmx.c| 10 --
 xen/include/asm-x86/hvm/vmx/vmcs.h |  1 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index cc6942cb79..af661b3180 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1660,9 +1660,15 @@ static int nvmx_handle_vmptrld(struct cpu_user_regs 
*regs)
 if ( rc != X86EMUL_OKAY )
 return rc;
 
-if ( gpa == vcpu_2_nvmx(v).vmxon_region_pa || gpa & 0xfff )
+if ( gpa & 0xfff )
 {
-vmfail_invalid(regs);
+vmfail(regs, VMX_INSN_VMPTRLD_INVALID_PHYADDR);
+goto out;
+}
+
+if ( gpa == vcpu_2_nvmx(v).vmxon_region_pa )
+{
+vmfail(regs, VMX_INSN_VMPTRLD_WITH_VMXON_PTR);
 goto out;
 }
 
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h 
b/xen/include/asm-x86/hvm/vmx/vmcs.h
index 6d0ae56fc1..eae4e5397e 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -534,6 +534,7 @@ enum vmx_insn_errno
 VMX_INSN_INVALID_CONTROL_STATE = 7,
 VMX_INSN_INVALID_HOST_STATE= 8,
 VMX_INSN_VMPTRLD_INVALID_PHYADDR   = 9,
+VMX_INSN_VMPTRLD_WITH_VMXON_PTR= 10,
 VMX_INSN_VMPTRLD_INCORRECT_VMCS_ID = 11,
 VMX_INSN_UNSUPPORTED_VMCS_COMPONENT= 12,
 VMX_INSN_VMXON_IN_VMX_ROOT = 15,
-- 
2.17.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 0/8] x86/vvmx: various fixes

[Sergey Dyasli]

These were found by running nested VMX tests from kvm-unit-tests.

Sergey Dyasli (8):
  x86/vvmx: introduce nvmx_vcpu_preinit()
  x86/nestedhvm: introduce vvmcx_valid()
  x86/vvmx: add VMX_INSN_INVEPT_INVVPID_INVALID_OP errno
  x86/vvmx: correct vmfail() usage for vmptrld and vmclear
  x86/vvmx: add VMX_INSN_VMPTRLD_WITH_VMXON_PTR errno
  x86/vvmx: refactor nvmx_handle_vmclear()
  x86/vvmx: correctly report vvmcs size
  x86/vvmx: fix I/O and MSR bitmaps mapping

 xen/arch/x86/hvm/svm/nestedsvm.c|   2 +-
 xen/arch/x86/hvm/vmx/vmx.c  |   4 +-
 xen/arch/x86/hvm/vmx/vvmx.c | 211 ++--
 xen/include/asm-x86/hvm/nestedhvm.h |   5 +
 xen/include/asm-x86/hvm/vmx/vmcs.h  |   3 +
 xen/include/asm-x86/hvm/vmx/vvmx.h  |   1 +
 6 files changed, 150 insertions(+), 76 deletions(-)

-- 
2.17.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 8/8] x86/vvmx: fix I/O and MSR bitmaps mapping

[Sergey Dyasli]

Currently Xen tries to map bitmaps during emulation of vmptrld and
vmwrite. This is wrong: a guest can store arbitrary values in those
fields.

Make bitmaps mapping happen only during a nested vmentry and only if
the appropriate execution controls are turned on by L1 hypervisor.

For performance reasons, Xen maps bitmaps only:

1. During the first nested vmentry
2. After L1 has changed an appropriate vmcs field
3. After nvmx_purge_vvmcs() was previously called

Signed-off-by: Sergey Dyasli 
---
v2:
- slight commit message change
---
 xen/arch/x86/hvm/vmx/vvmx.c | 105 +++-
 1 file changed, 68 insertions(+), 37 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 37d3cdd859..37dbd1abb7 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -717,6 +717,17 @@ static void __clear_current_vvmcs(struct vcpu *v)
 __vmpclear(nvcpu->nv_n2vmcx_pa);
 }
 
+static void unmap_msr_bitmap(struct vcpu *v)
+{
+struct nestedvmx *nvmx = _2_nvmx(v);
+
+if ( nvmx->msrbitmap )
+{
+hvm_unmap_guest_frame(nvmx->msrbitmap, 1);
+nvmx->msrbitmap = NULL;
+}
+}
+
 /*
  * Refreshes the MSR bitmap mapping for the current nested vcpu.  Returns true
  * for a successful mapping, and returns false for MSR_BITMAP parameter errors
@@ -727,12 +738,7 @@ static bool __must_check _map_msr_bitmap(struct vcpu *v)
 struct nestedvmx *nvmx = _2_nvmx(v);
 uint64_t gpa;
 
-if ( nvmx->msrbitmap )
-{
-hvm_unmap_guest_frame(nvmx->msrbitmap, 1);
-nvmx->msrbitmap = NULL;
-}
-
+unmap_msr_bitmap(v);
 gpa = get_vvmcs(v, MSR_BITMAP);
 
 if ( !IS_ALIGNED(gpa, PAGE_SIZE) )
@@ -743,6 +749,17 @@ static bool __must_check _map_msr_bitmap(struct vcpu *v)
 return nvmx->msrbitmap != NULL;
 }
 
+static void unmap_io_bitmap(struct vcpu *v, unsigned int idx)
+{
+struct nestedvmx *nvmx = _2_nvmx(v);
+
+if ( nvmx->iobitmap[idx] )
+{
+hvm_unmap_guest_frame(nvmx->iobitmap[idx], 1);
+nvmx->iobitmap[idx] = NULL;
+}
+}
+
 static bool_t __must_check _map_io_bitmap(struct vcpu *v, u64 vmcs_reg)
 {
 struct nestedvmx *nvmx = _2_nvmx(v);
@@ -750,8 +767,7 @@ static bool_t __must_check _map_io_bitmap(struct vcpu *v, 
u64 vmcs_reg)
 int index;
 
 index = vmcs_reg == IO_BITMAP_A ? 0 : 1;
-if (nvmx->iobitmap[index])
-hvm_unmap_guest_frame(nvmx->iobitmap[index], 1);
+unmap_io_bitmap(v, index);
 gpa = get_vvmcs(v, vmcs_reg);
 nvmx->iobitmap[index] = hvm_map_guest_frame_ro(gpa >> PAGE_SHIFT, 1);
 
@@ -766,7 +782,6 @@ static inline bool_t __must_check map_io_bitmap_all(struct 
vcpu *v)
 
 static void nvmx_purge_vvmcs(struct vcpu *v)
 {
-struct nestedvmx *nvmx = _2_nvmx(v);
 struct nestedvcpu *nvcpu = _nestedhvm(v);
 int i;
 
@@ -776,16 +791,11 @@ static void nvmx_purge_vvmcs(struct vcpu *v)
 nvcpu->nv_vvmcx = NULL;
 nvcpu->nv_vvmcxaddr = INVALID_PADDR;
 v->arch.hvm.vmx.vmcs_shadow_maddr = 0;
-for (i=0; i<2; i++) {
-if ( nvmx->iobitmap[i] ) {
-hvm_unmap_guest_frame(nvmx->iobitmap[i], 1);
-nvmx->iobitmap[i] = NULL;
-}
-}
-if ( nvmx->msrbitmap ) {
-hvm_unmap_guest_frame(nvmx->msrbitmap, 1);
-nvmx->msrbitmap = NULL;
-}
+
+for ( i = 0; i < 2; i++ )
+unmap_io_bitmap(v, i);
+
+unmap_msr_bitmap(v);
 }
 
 u64 nvmx_get_tsc_offset(struct vcpu *v)
@@ -1556,20 +1566,34 @@ static void clear_vvmcs_launched(struct list_head 
*launched_list,
 }
 }
 
-static int nvmx_vmresume(struct vcpu *v, struct cpu_user_regs *regs)
+static enum vmx_insn_errno nvmx_vmresume(struct vcpu *v)
 {
 struct nestedvmx *nvmx = _2_nvmx(v);
 struct nestedvcpu *nvcpu = _nestedhvm(v);
+unsigned int exec_ctrl;
 
-/* check VMCS is valid and IO BITMAP is set */
-if ( vvmcx_valid(v) &&
-((nvmx->iobitmap[0] && nvmx->iobitmap[1]) ||
-!(__n2_exec_control(v) & CPU_BASED_ACTIVATE_IO_BITMAP) ) )
-nvcpu->nv_vmentry_pending = 1;
-else
-vmfail_invalid(regs);
+ASSERT(vvmcx_valid(v));
+exec_ctrl = __n2_exec_control(v);
 
-return X86EMUL_OKAY;
+if ( exec_ctrl & CPU_BASED_ACTIVATE_IO_BITMAP )
+{
+if ( (nvmx->iobitmap[0] == NULL || nvmx->iobitmap[1] == NULL) &&
+ !map_io_bitmap_all(v) )
+goto invalid_control_state;
+}
+
+if ( exec_ctrl & CPU_BASED_ACTIVATE_MSR_BITMAP )
+{
+if ( nvmx->msrbitmap == NULL && !_map_msr_bitmap(v) )
+goto invalid_control_state;
+}
+
+nvcpu->nv_vmentry_pending = 1;
+
+return VMX_INSN_SUCCEED;
+
+invalid_control_state:
+return VMX_INSN_INVALID_CONTROL_STATE;
 }
 
 static int nvmx_handle_vmresume(struct cpu_user_regs *regs)
@@ -1578,6 +1602,7 @@ static int nvmx_handle_vmresume(struct cpu_user_regs 
*regs)
 struct vcpu *v = current;
 struct nestedvmx *nvmx = _2_nvmx(v);
 unsigned long 

[Xen-devel] [PATCH v2 4/8] x86/vvmx: correct vmfail() usage for vmptrld and vmclear

[Sergey Dyasli]

Calling vmfail_valid() is correct only if vvmcx is valid. Modify
functions to use vmfail() instead which performs the necessary check.

While at it, add ASSERTs into vmfail_valid/invalid() to quickly catch
an incorrect usage in the future.

Signed-off-by: Sergey Dyasli 
---
v2:
- Added ASSERTs
---
 xen/arch/x86/hvm/vmx/vvmx.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index ba4f6d67fe..cc6942cb79 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -473,14 +473,19 @@ static void vmfail_valid(struct cpu_user_regs *regs, enum 
vmx_insn_errno errno)
 struct vcpu *v = current;
 unsigned int eflags = regs->eflags;
 
+ASSERT(vvmcx_valid(v));
+
 regs->eflags = (eflags & ~X86_EFLAGS_ARITH_MASK) | X86_EFLAGS_ZF;
 set_vvmcs(v, VM_INSTRUCTION_ERROR, errno);
 }
 
 static void vmfail_invalid(struct cpu_user_regs *regs)
 {
+struct vcpu *v = current;
 unsigned int eflags = regs->eflags;
 
+ASSERT(!vvmcx_valid(v));
+
 regs->eflags = (eflags & ~X86_EFLAGS_ARITH_MASK) | X86_EFLAGS_CF;
 }
 
@@ -1700,7 +1705,7 @@ static int nvmx_handle_vmptrld(struct cpu_user_regs *regs)
  !map_io_bitmap_all(v) ||
  !_map_msr_bitmap(v) )
 {
-vmfail_valid(regs, VMX_INSN_VMPTRLD_INVALID_PHYADDR);
+vmfail(regs, VMX_INSN_VMPTRLD_INVALID_PHYADDR);
 goto out;
 }
 }
@@ -1784,7 +1789,7 @@ static int nvmx_handle_vmclear(struct cpu_user_regs *regs)
 if ( rc == VMSUCCEED )
 vmsucceed(regs);
 else if ( rc == VMFAIL_VALID )
-vmfail_valid(regs, VMX_INSN_VMCLEAR_INVALID_PHYADDR);
+vmfail(regs, VMX_INSN_VMCLEAR_INVALID_PHYADDR);
 else
 vmfail_invalid(regs);
 
-- 
2.17.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 1/8] x86/vvmx: introduce nvmx_vcpu_preinit()

[Sergey Dyasli]

And call it during vmx_vcpu_initialise(). This allows to safely use
vvmx functions that rely on the values inside struct nestedvmx and
struct nestedvcpu, independently of the nested virtualisation
(HVM_PARAM_NESTEDHVM) status of a domain.

Signed-off-by: Sergey Dyasli 
---
v2:
- new patch
---
 xen/arch/x86/hvm/vmx/vmx.c |  4 ++--
 xen/arch/x86/hvm/vmx/vvmx.c| 10 ++
 xen/include/asm-x86/hvm/vmx/vvmx.h |  1 +
 3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index e065f8bbdb..b33a3d6abd 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -429,8 +429,6 @@ static int vmx_vcpu_initialise(struct vcpu *v)
 
 INIT_LIST_HEAD(>arch.hvm.vmx.pi_blocking.list);
 
-vcpu_2_nvmx(v).vmxon_region_pa = INVALID_PADDR;
-
 if ( (rc = vmx_create_vmcs(v)) != 0 )
 {
 dprintk(XENLOG_WARNING,
@@ -464,6 +462,8 @@ static int vmx_vcpu_initialise(struct vcpu *v)
 
 vmx_install_vlapic_mapping(v);
 
+nvmx_vcpu_preinit(v);
+
 return 0;
 }
 
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index dfd08e2d0a..c8bc8e6d11 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -57,6 +57,16 @@ void nvmx_cpu_dead(unsigned int cpu)
 per_cpu(vvmcs_buf, cpu) = NULL;
 }
 
+/* This function initialises fields that are not 0 by default */
+void nvmx_vcpu_preinit(struct vcpu *v)
+{
+struct nestedvmx *nvmx = _2_nvmx(v);
+struct nestedvcpu *nvcpu = _nestedhvm(v);
+
+nvmx->vmxon_region_pa = INVALID_PADDR;
+nvcpu->nv_vvmcxaddr = INVALID_PADDR;
+}
+
 int nvmx_vcpu_initialise(struct vcpu *v)
 {
 struct nestedvmx *nvmx = _2_nvmx(v);
diff --git a/xen/include/asm-x86/hvm/vmx/vvmx.h 
b/xen/include/asm-x86/hvm/vmx/vvmx.h
index 6b9c4ae0b2..199dfa1432 100644
--- a/xen/include/asm-x86/hvm/vmx/vvmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vvmx.h
@@ -83,6 +83,7 @@ union vmx_inst_info {
 u32 word;
 };
 
+void nvmx_vcpu_preinit(struct vcpu *v);
 int nvmx_vcpu_initialise(struct vcpu *v);
 void nvmx_vcpu_destroy(struct vcpu *v);
 int nvmx_vcpu_reset(struct vcpu *v);
-- 
2.17.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 3/8] x86/vvmx: add VMX_INSN_INVEPT_INVVPID_INVALID_OP errno

[Sergey Dyasli]

And use it in nvmx_handle_invept() and nvmx_handle_invvpid().

Signed-off-by: Sergey Dyasli 
---
v2:
- new patch
---
 xen/arch/x86/hvm/vmx/vvmx.c| 4 ++--
 xen/include/asm-x86/hvm/vmx/vmcs.h | 1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index d437f33193..ba4f6d67fe 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1901,7 +1901,7 @@ static int nvmx_handle_invept(struct cpu_user_regs *regs)
 __invept(INVEPT_ALL_CONTEXT, 0);
 break;
 default:
-vmfail_invalid(regs);
+vmfail(regs, VMX_INSN_INVEPT_INVVPID_INVALID_OP);
 return X86EMUL_OKAY;
 }
 vmsucceed(regs);
@@ -1926,7 +1926,7 @@ static int nvmx_handle_invvpid(struct cpu_user_regs *regs)
 hvm_asid_flush_vcpu_asid(_nestedhvm(current).nv_n2asid);
 break;
 default:
-vmfail_invalid(regs);
+vmfail(regs, VMX_INSN_INVEPT_INVVPID_INVALID_OP);
 return X86EMUL_OKAY;
 }
 
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h 
b/xen/include/asm-x86/hvm/vmx/vmcs.h
index 76dd04a72d..6d0ae56fc1 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -538,6 +538,7 @@ enum vmx_insn_errno
 VMX_INSN_UNSUPPORTED_VMCS_COMPONENT= 12,
 VMX_INSN_VMXON_IN_VMX_ROOT = 15,
 VMX_INSN_VMENTRY_BLOCKED_BY_MOV_SS = 26,
+VMX_INSN_INVEPT_INVVPID_INVALID_OP = 28,
 VMX_INSN_FAIL_INVALID  = ~0,
 };
 
-- 
2.17.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 6/8] x86/vvmx: refactor nvmx_handle_vmclear()

[Sergey Dyasli]

1. Add VMX_INSN_VMCLEAR_WITH_VMXON_PTR errno and add the appropriate
   check to the function.

2. Correct the return value for not-4KB-aligned case and for invalid
   physaddr (when hvm_map_guest_frame_rw() fails).

3. Remove enum vmx_ops_result and use vmfail/vmsucceed() calls directly.

Signed-off-by: Sergey Dyasli 
---
v2:
- Removal of enum vmx_ops_result and refactoring
---
 xen/arch/x86/hvm/vmx/vvmx.c| 52 +-
 xen/include/asm-x86/hvm/vmx/vmcs.h |  1 +
 2 files changed, 30 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index af661b3180..2f5370ceed 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -217,12 +217,6 @@ struct vmx_inst_decoded {
 unsigned int reg2;
 };
 
-enum vmx_ops_result {
-VMSUCCEED,
-VMFAIL_VALID,
-VMFAIL_INVALID,
-};
-
 #define CASE_SET_REG(REG, reg)  \
 case VMX_REG_ ## REG: regs->reg = value; break
 #define CASE_GET_REG(REG, reg)  \
@@ -1764,16 +1758,26 @@ static int nvmx_handle_vmclear(struct cpu_user_regs 
*regs)
 if ( rc != X86EMUL_OKAY )
 return rc;
 
-BUILD_BUG_ON(X86EMUL_OKAY != VMSUCCEED); /* rc = VMSUCCEED; */
+if ( gpa == vcpu_2_nvmx(v).vmxon_region_pa )
+{
+vmfail(regs, VMX_INSN_VMCLEAR_WITH_VMXON_PTR);
+goto out;
+}
+
 if ( gpa & 0xfff )
-rc = VMFAIL_INVALID;
-else if ( gpa == nvcpu->nv_vvmcxaddr )
+{
+vmfail(regs, VMX_INSN_VMCLEAR_INVALID_PHYADDR);
+goto out;
+}
+
+if ( gpa == nvcpu->nv_vvmcxaddr )
 {
 if ( cpu_has_vmx_vmcs_shadowing )
 nvmx_clear_vmcs_pointer(v, nvcpu->nv_vvmcx);
 clear_vvmcs_launched(>launched_list,
  PFN_DOWN(v->arch.hvm.vmx.vmcs_shadow_maddr));
 nvmx_purge_vvmcs(v);
+vmsucceed(regs);
 }
 else 
 {
@@ -1781,24 +1785,26 @@ static int nvmx_handle_vmclear(struct cpu_user_regs 
*regs)
 bool_t writable;
 
 vvmcs = hvm_map_guest_frame_rw(paddr_to_pfn(gpa), 0, );
-if ( vvmcs ) 
+
+if ( !vvmcs )
 {
-if ( writable )
-clear_vvmcs_launched(>launched_list,
- mfn_x(domain_page_map_to_mfn(vvmcs)));
-else
-rc = VMFAIL_VALID;
-hvm_unmap_guest_frame(vvmcs, 0);
+vmfail(regs, VMX_INSN_VMCLEAR_INVALID_PHYADDR);
+goto out;
 }
-}
 
-if ( rc == VMSUCCEED )
-vmsucceed(regs);
-else if ( rc == VMFAIL_VALID )
-vmfail(regs, VMX_INSN_VMCLEAR_INVALID_PHYADDR);
-else
-vmfail_invalid(regs);
+if ( writable )
+{
+clear_vvmcs_launched(>launched_list,
+ mfn_x(domain_page_map_to_mfn(vvmcs)));
+vmsucceed(regs);
+}
+else
+vmfail(regs, VMX_INSN_VMCLEAR_INVALID_PHYADDR);
 
+hvm_unmap_guest_frame(vvmcs, 0);
+}
+
+out:
 return X86EMUL_OKAY;
 }
 
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h 
b/xen/include/asm-x86/hvm/vmx/vmcs.h
index eae4e5397e..b3e800138e 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -529,6 +529,7 @@ enum vmx_insn_errno
 {
 VMX_INSN_SUCCEED   = 0,
 VMX_INSN_VMCLEAR_INVALID_PHYADDR   = 2,
+VMX_INSN_VMCLEAR_WITH_VMXON_PTR= 3,
 VMX_INSN_VMLAUNCH_NONCLEAR_VMCS= 4,
 VMX_INSN_VMRESUME_NONLAUNCHED_VMCS = 5,
 VMX_INSN_INVALID_CONTROL_STATE = 7,
-- 
2.17.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [distros-debian-snapshot test] 75575: trouble: broken/fail/pass

[Platform Team regression test user]

flight 75575 distros-debian-snapshot real [real]
http://osstest.xensource.com/osstest/logs/75575/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-amd64-daily-netboot-pygrub  broken
 test-amd64-i386-amd64-daily-netboot-pygrub 4 host-install(4) broken REGR. vs. 
75544

Tests which did not succeed, but are not blocking:
 test-amd64-i386-i386-daily-netboot-pvgrub 11 guest-start fail blocked in 75544
 test-amd64-amd64-i386-current-netinst-pygrub 10 debian-di-install fail blocked 
in 75544
 test-amd64-i386-i386-current-netinst-pygrub 10 debian-di-install fail blocked 
in 75544
 test-amd64-amd64-i386-daily-netboot-pygrub 11 guest-start  fail like 75544
 test-amd64-amd64-i386-weekly-netinst-pygrub 10 debian-di-install fail like 
75544
 test-amd64-i386-i386-weekly-netinst-pygrub 10 debian-di-install fail like 75544
 test-amd64-i386-amd64-current-netinst-pygrub 10 debian-di-install fail like 
75544
 test-amd64-i386-amd64-weekly-netinst-pygrub 10 debian-di-install fail like 
75544
 test-amd64-amd64-amd64-weekly-netinst-pygrub 10 debian-di-install fail like 
75544
 test-amd64-amd64-amd64-current-netinst-pygrub 10 debian-di-install fail like 
75544
 test-amd64-amd64-amd64-daily-netboot-pvgrub 10 debian-di-install fail like 
75544
 test-armhf-armhf-armhf-daily-netboot-pygrub 10 debian-di-install fail like 
75544

baseline version:
 flight   75544

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubfail
 test-amd64-i386-amd64-daily-netboot-pygrub   broken  
 test-armhf-armhf-armhf-daily-netboot-pygrub  fail
 test-amd64-amd64-i386-daily-netboot-pygrub   fail
 test-amd64-amd64-amd64-current-netinst-pygrubfail
 test-amd64-i386-amd64-current-netinst-pygrub fail
 test-amd64-amd64-i386-current-netinst-pygrub fail
 test-amd64-i386-i386-current-netinst-pygrub  fail
 test-amd64-amd64-amd64-weekly-netinst-pygrub fail
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  fail
 test-amd64-i386-i386-weekly-netinst-pygrub   fail



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


Push not applicable.


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 5/6] tools/dm_depriv: Add first cut RLIMITs

[Ian Jackson]

George Dunlap writes ("[PATCH v4 5/6] 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)
...
> Suggested-by: Ross Lagerwall 
> Signed-off-by: George Dunlap 

Acked-by: Ian Jackson 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 2/6] SUPPORT.md: Add qemu-depriv section

[Ian Jackson]

George Dunlap writes ("[PATCH v4 2/6] SUPPORT.md: Add qemu-depriv section"):
> Signed-off-by: George Dunlap 

Acked-by: Ian Jackson 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 1/6] docs/qemu-deprivilege: Revise and update with status and future plans

[Ian Jackson]

George Dunlap writes ("[PATCH v4 1/6] 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.

Acked-by: Ian Jackson 

(Assuming you fix the commit message to drop the mention of
nonexistent SUPPORT.md changes...)

Thanks,
Ian.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 8/8] tools/libvchan: libxenvchan_client_init: use ENOENT for no server

[Ian Jackson]

Wei Liu writes ("Re: [PATCH 8/8] tools/libvchan: libxenvchan_client_init: use 
ENOENT for no server"):
> On Fri, Nov 02, 2018 at 05:01:13PM +, Ian Jackson wrote:
> > * Promise that we will set errno to ENOENT if the server is not
> >   yet set up.
> > * Arrange that all ENOENT returns other than from the read of ring-ref
> >   are turned into EIO, logging when we do so.
> 
> This sounds reasonable to me, but I would like to hear from Marek that
> this doesn't break Qubes.

Right.  Marek, this series was intended to help with vchan for qmp.
But obviously I don't want to break anything else.  I don't think this
should break anything but I would appreciate a review or at least an
opinion...

Thanks,
Ian.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 4/8] tools/libvchan: init_xs_srv: Simplify error handling (2)

[Ian Jackson]

Wei Liu writes ("Re: [PATCH 4/8] tools/libvchan: init_xs_srv: Simplify error 
handling (2)"):
> On Fri, Nov 02, 2018 at 05:01:09PM +, Ian Jackson wrote:
> > * Abolish fail_xs_open which is now exactly the same as fail.
> > * Change all gotos to refer to fail instead.
> > No functional change.
> 
> Oh  here it is.

Right :-).  Separating the patches like this made the first half a lot
clearer, I found.

> Feel free to add my ack to your previous patch.

Thanks.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 3/6] tools/dm_restrict: Ask QEMU to chroot

[Paul Durrant]

> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 06 November 2018 11:11
> To: Paul Durrant 
> Cc: George Dunlap ; xen-
> de...@lists.xenproject.org; Ian Jackson ; Wei Liu
> 
> Subject: Re: [Xen-devel] [PATCH v4 3/6] tools/dm_restrict: Ask QEMU to
> chroot
> 
> On Tue, Nov 06, 2018 at 10:53:48AM +, Paul Durrant wrote:
> > Ok. The trace backend is set at build time in tools/Makefile:
> >
> > if $$source/scripts/tracetool.py --check-backend --backend log ;
> then \
> > enable_trace_backend='--enable-trace-backend=log';
> > elif $$source/scripts/tracetool.py --check-backend --backend
> stderr ; then \
> > enable_trace_backend='--enable-trace-backend=stderr'; \
> > else \
> > enable_trace_backend='' ; \
> > fi ; \
> >
> > and log appears to favoured. Is this still going to work with the
> > chroot? We rely on the tracing in xen_platform to get log messages out
> > of PV drivers.
> 
> log vs stderr are just different names for the same thing. "stderr"
> doesn't exist anymore in recent version of QEMU and as been renamed
> "log".

Oh yes, I'd forgotten... That's fine then :-)

  Paul

> 
> --
> Anthony PERARD

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 3/6] tools/dm_restrict: Ask QEMU to chroot

[Anthony PERARD]

On Tue, Nov 06, 2018 at 10:53:48AM +, Paul Durrant wrote:
> Ok. The trace backend is set at build time in tools/Makefile:
> 
> if $$source/scripts/tracetool.py --check-backend --backend log ; then 
> \
> enable_trace_backend='--enable-trace-backend=log'; 
> elif $$source/scripts/tracetool.py --check-backend --backend stderr ; 
> then \
> enable_trace_backend='--enable-trace-backend=stderr'; \
> else \
> enable_trace_backend='' ; \
> fi ; \
> 
> and log appears to favoured. Is this still going to work with the
> chroot? We rely on the tracing in xen_platform to get log messages out
> of PV drivers.

log vs stderr are just different names for the same thing. "stderr"
doesn't exist anymore in recent version of QEMU and as been renamed
"log".

-- 
Anthony PERARD

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 1/6] docs/qemu-deprivilege: Revise and update with status and future plans

[Anthony PERARD]

On Tue, Nov 06, 2018 at 09:07:12AM +, Paul Durrant wrote:
> > +## Migration
> > +
> > +When calling xen-save-devices-state, since QEMU is running in a chroot
> > +it is not useful to pass a filename (it doesn't even have write access
> > +inside the chroot). Instead, give it an open fd using the add-fd
> > +mechanism.
> > +
> > +Additionally, all the restrictions need to be applied to the qemu
> > +started up on the post-migration side.  One issue that needs to be
> > +solved is how to signal the toolstack on restore that qemu is ready
> > +for the domain to be started (since this is normally done via
> > +xenstore, and at this point the xenstore connections will have been
> > +closed).
> 
> I thought Anthony had fixed this now?
> 

It's work in progress. (libxl__ev_qmp_* patch series.)

-- 
Anthony PERARD

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 3/6] tools/dm_restrict: Ask QEMU to chroot

[Paul Durrant]

> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: 06 November 2018 10:28
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Anthony Perard ; Ian Jackson
> ; Wei Liu 
> Subject: Re: [Xen-devel] [PATCH v4 3/6] tools/dm_restrict: Ask QEMU to
> chroot
> 
> On 11/06/2018 09:14 AM, Paul Durrant wrote:
> >> -Original Message-
> >> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On
> Behalf
> >> Of George Dunlap
> >> Sent: 05 November 2018 18:07
> >> To: xen-devel@lists.xenproject.org
> >> Cc: Anthony Perard ; Ian Jackson
> >> ; Wei Liu ; George Dunlap
> >> 
> >> Subject: [Xen-devel] [PATCH v4 3/6] 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)
> >
> > This does not appear to match the code: the path should be
> /var/run/qemu-root- AFAICT
> 
> Indeed, I forgot to update this.  I can fix this up on check-in.
> 
> >> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> >> index 26eb16af34..ad3efcc783 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
> >
> > Maybe '' in the comment rather than '%d'?
> 
> Maybe. :-)
> 
> >> + *
> >> + * 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.
> >
> > How does logging work if QEMU can't write to the chroot? I assume we are
> relying on stderr? Does using syslog still work?
> 
> Everything QEMU needs access to (including vnc sockets, qmp sockets, )
> must either be opened before the chroot happens, or passed to QEMU as an
> fd via qmp.  In the case of logging, this happens through stderr; but if
> you search for 'chroot' in the design document you'll get a couple of
> examples of different issues that need to be addressed (including
> inserting a cd-rom and dealing with migration).

Ok. The trace backend is set at build time in tools/Makefile:

if $$source/scripts/tracetool.py --check-backend --backend log ; then \
enable_trace_backend='--enable-trace-backend=log'; 
elif $$source/scripts/tracetool.py --check-backend --backend stderr ; 
then \
enable_trace_backend='--enable-trace-backend=stderr'; \
else \
enable_trace_backend='' ; \
fi ; \

and log appears to favoured. Is this still going to work with the chroot? We 
rely on the tracing in xen_platform to get log messages out of PV drivers.

  Paul

> 
>  -George

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] dom0/pvh: Dom0 PVH with PCI passthrough support status

[Wei Liu]

On Mon, Nov 05, 2018 at 04:17:56PM +0200, Alexandru Vasile wrote:
> On Mon, Nov 05, 2018 at 12:57 PM, Wei Liu wrote:
> > On Mon, Nov 05, 2018 at 11:58:09AM +0200, Alexandru Vasile wrote:
> > > Hello,
> > > (XEN) event_channel.c:319:d0v1 EVTCHNOP failure: domain 1, error -22
> > > (XEN) event_channel.c:319:d0v3 EVTCHNOP failure: domain 1, error -22
> > Do you perhaps have more than one xenstored / xenconsoled running?
> 
> The processes listed by 'ps -aux | grep xen' immediately after dom0 boots
> are oxenstored, xenconsoled and xenwatchdogd.
> 
> I did start 'xencommons ' from my install folder due to xl showing the name
> of Dom0 as '(null)' and also because of a difference in output error from xl
> when creating a HVM DomU with passthrough (the output is captured in files
> xl_output_clean[0] and xl_output_xencommons[1]).

Roger has already answered  your questions, I just want to add to this:
running xencommons manually is likely to start a second instance of some
services. You can fix this by configure your system properly. If you use
systemd, just enable all xen related units.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 03/24] hw: acpi: The RSDP build API can return void

[Samuel Ortiz]

On Tue, Nov 06, 2018 at 11:23:39AM +0100, Paolo Bonzini wrote:
> On 05/11/2018 02:40, Samuel Ortiz wrote:
> >  /* RSDP */
> > -static GArray *
> > +static void
> >  build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned 
> > xsdt_tbl_offset)
> >  {
> >  AcpiRsdpDescriptor *rsdp = acpi_data_push(rsdp_table, sizeof *rsdp);
> > @@ -392,8 +392,6 @@ build_rsdp(GArray *rsdp_table, BIOSLinker *linker, 
> > unsigned xsdt_tbl_offset)
> >  bios_linker_loader_add_checksum(linker, ACPI_BUILD_RSDP_FILE,
> >  (char *)rsdp - rsdp_table->data, sizeof *rsdp,
> >  (char *)>checksum - rsdp_table->data);
> > -
> > -return rsdp_table;
> >  }
> >  
> 
> Better than v4. :)
Right, I followed Philippe's advice and it does make things clearer :)

Cheers,
Samuel.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 6/6] RFC: test/depriv: Add a tool to check process-level depriv

[George Dunlap]

On 11/06/2018 09:34 AM, Paul Durrant wrote:
>> +# 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"
> 
> This patter occurs many times. Could you not just have a boolean 'failed' 
> value and a supporting 'reason' (which might be empty) then you can just test 
> 'reason' at the end to decide what to echo?

Yes, Ian also suggested that, and if I end up leaving it as a bash
script I'll certainly do something like that.  However:

>> NB this patch is included for reference only, 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).  Reviews of the general detection algorithm
>> are welcome, but there's no need for a detailed review of the code
>> until the script is in its final form.

Sorry you missed that!  If I end up leaving this as a bash script I'll
take your comments about tabs/spaces and the value of "failed" into account.

 -George

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 5/6] tools/dm_depriv: Add first cut RLIMITs

[George Dunlap]

On 11/06/2018 09:22 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of George Dunlap
>> Sent: 05 November 2018 18:07
>> To: xen-devel@lists.xenproject.org
>> Cc: Anthony Perard ; Ian Jackson
>> ; Wei Liu ; George Dunlap
>> 
>> Subject: [Xen-devel] [PATCH v4 5/6] 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 v3:
>> - Align RLIMIT_ENTRY list for easier reading
>> - Fix wrong format string specifier
>> - Get rid of some trailing whitespace
>>
>> 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| 42 ++--
>>  2 files changed, 46 insertions(+), 8 deletions(-)
>>
>> diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-
>> deprivilege.md
>> index a461ebbadd..e984064da6 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 c7a345f4bb..ac9526d731 100644
>> --- a/tools/libxl/libxl_linux.c
>> +++ b/tools/libxl/libxl_linux.c
>> @@ -12,11 +12,12 @@
>>   * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>   * GNU Lesser General Public License for more details.
>>   */
>> -
>> +
> 
> Stray whitespace change?

Got rid of trailing witespace; I mentioned it under "Changes since v3".

>>  #include "libxl_osdeps.h" /* must come before any other headers */
>>
>>  #include "libxl_internal.h"
>> -
>> +#include 
>> +
> 
> Personally I tend to put local includes after ones from the include path. Is 
> there a reason it needs to come afterwards?

No reason; just habit to add things to the end.  I'll move it earlier
unless Ian objects.

>> +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
> 
>  The undef should come before the brace to get the scoping correct. 
> 

Sure.

>> +
>>  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,21 @@ 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, );
>> +if (r < 0) {
>> +LOGE(ERROR, "Setting rlimit %d to %llu failed\n",
>> +  rlimits[i].resource,
>> +  (unsigned long long)rlimits[i].limit);
> 
> 

Re: [Xen-devel] [PATCH] docs: remove ChangeLog file

[Wei Liu]

On Tue, Oct 30, 2018 at 05:10:18PM +, Wei Liu wrote:
> On Fri, Oct 26, 2018 at 12:38:06PM +0200, Juergen Gross wrote:
> > docs/ChangeLog has been updated for Xen 3.3 last time. It seems to be
> > interesting for archaeologists only today.
> > 
> > Remove it.
> > 
> > Signed-off-by: Juergen Gross 
> 
> I wouldn't mind removing it. Nowadays I mostly use git to do
> archaeology, so:
> 
> Acked-by: Wei Liu 
> 
> But let's wait some time in case there is objection.

No one objected so I have applied this patch.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel