[Xen-devel] [libvirt test] 114395: tolerable all pass - PUSHED

2017-10-12 Thread osstest service owner 
flight 114395 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114395/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114088
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114088
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114088
 test-amd64-amd64-libvirt-xsm 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-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 12 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-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  764d7d0915422bf8d3608bff078c6c1480d25730
baseline version:
 libvirt  c44b29aacb6a3f445ab06d61899a0308b9d6d0d3

Last test of basis   114088  2017-10-07 04:21:11 Z6 days
Failing since114325  2017-10-11 04:28:10 Z2 days2 attempts
Testing same since   114395  2017-10-12 04:20:04 Z1 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Daniel P. Berrange 
  Jiri Denemark 
  Ján Tomko 
  Kothapally Madhu Pavan 
  Marc Hartmayer 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-amd64-i386-libvirt-qcow2pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



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

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

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

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


Pushing revision :

+ branch=libvirt
+ revision=764d7d0915422bf8d3608bff078c6c1480d25730
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.
 PERLLIB=.:.
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++

[Xen-devel] [qemu-mainline bisection] complete test-amd64-amd64-xl-pvh-amd

2017-10-12 Thread osstest service owner 
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-pvh-amd
testid guest-start

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.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:  c7dfe4ac58dd9c8678126b78da961b233a49f3f9
  Bug not present: 3c44f8ed44ab559c7e5b58316751bea53adfd83b
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/114449/


  commit c7dfe4ac58dd9c8678126b78da961b233a49f3f9
  Author: Roger Pau Monne 
  Date:   Fri Sep 22 16:25:06 2017 +0100
  
  xl: introduce a domain type option
  
  Introduce a new type option to xl configuration files in order to
  specify the domain type. This supersedes the current builder option.
  
  The new option is documented in the xl.cfg man page, and the previous
  builder option is marked as deprecated.
  
  Signed-off-by: Roger Pau Monné 
  Acked-by: Ian Jackson 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-mainline/test-amd64-amd64-xl-pvh-amd.guest-start.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/qemu-mainline/test-amd64-amd64-xl-pvh-amd.guest-start
 --summary-out=tmp/114449.bisection-summary --basis-template=114042 
--blessings=real,real-bisect qemu-mainline test-amd64-amd64-xl-pvh-amd 
guest-start
Searching for failure / basis pass:
 114279 fail [host=pinot0] / 114042 [host=rimava0] 113974 [host=pinot1] 113964 
[host=merlot1] 113876 [host=pinot1] 113864 [host=nocera1] 113852 [host=rimava1] 
113839 [host=merlot0] 113817 [host=rimava0] 113784 [host=nocera0] 113780 
[host=pinot1] 113769 [host=merlot1] 113743 [host=nocera1] 113711 [host=rimava1] 
113689 [host=pinot1] 113659 [host=rimava0] 113646 [host=nocera1] 113626 
[host=merlot1] 113613 ok.
Failure / basis pass flights: 114279 / 113613
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 1852eae92c460813692808234da35d142a405ab7 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
530049bc1dcc24c1178a29d99ca08b6dd08413e0 
dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e
Basis pass 4ad5dcaca7428dd2bc1a6a40c948e3799c1e27ae 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
c51700273ad9802a21c19f8d2b4bcb67c38e74ac 
16b1414de91b5a82a0996c67f6db3af7d7e32873
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#4ad5dcaca7428dd2bc1a6a40c948e3799c1e27ae-1852eae92c460813692808234da35d142a405ab7
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d
 
git://git.qemu.org/qemu.git#c51700273ad9802a21c19f8d2b4bcb67c38e74ac-530049bc1dcc24c1178a29d99ca08b6dd08413e0
 
git://xenbits.xen.org/xen.git#16b1414de91b5a82a0996c67f6db3af7d7e32873-dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e
Loaded 8949 nodes in revision graph
Searching for test results:
 113613 pass 4ad5dcaca7428dd2bc1a6a40c948e3799c1e27ae 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
c51700273ad9802a21c19f8d2b4bcb67c38e74ac 
16b1414de91b5a82a0996c67f6db3af7d7e32873
 113659 [host=rimava0]
 113646 [host=nocera1]
 113626 [host=merlot1]
 113689 [host=pinot1]
 113711 [host=rimava1]
 113769 [host=merlot1]
 113784 [host=nocera0]
 113743 [host=nocera1]
 113780 [host=pinot1]
 113817 [host=rimava0]
 113839 [host=merlot0]
 113852 [host=rimava1]
 113876 [host=pinot1]
 113864 [host=nocera1]
 113964 [host=merlot1]
 113974 [host=pinot1]
 114042 [host=rimava0]
 114083 fail 1852eae92c460813692808234da35d142a405ab7 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
530049bc1dcc24c1178a29d99ca08b6dd08413e0 
dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e
 114106 fail 1852eae92c460813692808234da35d142a405ab7 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
530049bc1dcc24c1178a29d99ca08b6dd08413e0 
dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e
 114148 fail 1852eae92c460813692808234da35d142a405ab7 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d

[Xen-devel] [xen-4.9-testing test] 114372: regressions - FAIL

2017-10-12 Thread osstest service owner 
flight 114372 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114372/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  broken  in 114312
 test-armhf-armhf-xl-multivcpu broken in 114312
 test-armhf-armhf-libvirt-raw broken  in 114312
 build-i386-prev   6 xen-build  fail in 114312 REGR. vs. 114118

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl  4 host-install(4) broken in 114312 pass in 114372
 test-armhf-armhf-libvirt-raw 4 host-install(4) broken in 114312 pass in 114372
 test-armhf-armhf-xl-multivcpu 4 host-install(4) broken in 114312 pass in 114372
 test-armhf-armhf-libvirt  7 xen-boot   fail pass in 114312
 test-amd64-i386-qemut-rhel6hvm-intel 10 redhat-install fail pass in 114312
 test-armhf-armhf-xl-credit2  16 guest-start/debian.repeat  fail pass in 114312

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 114118

Tests which did not succeed, but are not blocking:
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked in 114312 n/a
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail blocked in 
114118
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 114312 like 
114091
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 114312 
like 114118
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 114312 
like 114118
 test-armhf-armhf-libvirt13 migrate-support-check fail in 114312 never pass
 test-armhf-armhf-libvirt 14 saverestore-support-check fail in 114312 never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 114091
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114091
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 114118
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 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-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail 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-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386

Re: [Xen-devel] [PATCH v6 08/16] x86: implement set value flow for MBA

2017-10-12 Thread Yi Sun 
On 17-10-12 03:43:26, Jan Beulich wrote:
> >>> On 12.10.17 at 06:33,  wrote:
> > On 17-10-11 07:38:52, Jan Beulich wrote:
> >> >>> On 08.10.17 at 09:23,  wrote:
> >> > --- a/xen/arch/x86/psr.c
> >> > +++ b/xen/arch/x86/psr.c
> >> > @@ -138,6 +138,12 @@ static const struct feat_props {
> >> >  
> >> >  /* write_msr is used to write out feature MSR register. */
> >> >  void (*write_msr)(unsigned int cos, uint32_t val, enum psr_type 
> >> > type);
> >> > +
> >> > +/*
> >> > + * check_val is used to check if input val fulfills SDM requirement.
> >> > + * Change it to valid value if SDM allows.
> >> > + */
> >> > +bool (*check_val)(const struct feat_node *feat, unsigned long *val);
> >> 
> >> I'm pretty sure I've said so before - "check" to me implies all r/o
> >> inputs. Perhaps sanitize_val() or even just sanitize()?
> >> 
> >> And why unsigned long when the only caller has a uint32_t in its
> >> hands?
> >> 
> > To be compatible with cat_check_cbm (old name is 'psr_check_cbm' in L2 
> > series),
> > the last parameter type is 'unsigned long'. We have discussed it in L2 
> > patch set
> > v9, patch 10.
> 
> Iirc (without checking the old thread) this was for calculations to
> be done as unsigned long ones. If that's the only aspect here,
> then imo this is not a valid reason for the hook's parameter type
> to be unsigned long *.
> 
Because below macros used in cat_check_cbm require the input addr to be unsigned
long, we define the last parameter of cat_check_cbm to be unsigned long.
find_first_bit
find_next_zero_bit
find_next_bit

If you think the unsigned long is not appropriate for 'check_val', I think I
have to define a local variable in cat_check_cbm to do the convertion.

> Jan

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

[Xen-devel] [linux-3.18 test] 114368: regressions - trouble: blocked/broken/fail/pass

2017-10-12 Thread osstest service owner 
flight 114368 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114368/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf  broken
 build-armhf   4 host-install(4)broken REGR. vs. 114034
 test-amd64-amd64-xl-pvh-intel 12 guest-start fail REGR. vs. 114034
 test-amd64-amd64-xl-pvh-amd  12 guest-start  fail REGR. vs. 114034

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-raw 19 guest-start/debian.repeat fail in 114133 pass in 
114368
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail pass in 114133

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt 14 saverestore-support-check fail in 114133 like 
114034
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 114133 like 
114034
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail in 114133 like 
114034
 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 114133 never pass
 test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 114133 never 
pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail in 114133 never 
pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail in 114133 
never pass
 test-armhf-armhf-xl 13 migrate-support-check fail in 114133 never pass
 test-armhf-armhf-libvirt13 migrate-support-check fail in 114133 never pass
 test-armhf-armhf-xl 14 saverestore-support-check fail in 114133 never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail in 114133 never 
pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail in 114133 
never pass
 test-armhf-armhf-xl-credit2 13 migrate-support-check fail in 114133 never pass
 test-armhf-armhf-xl-credit2 14 saverestore-support-check fail in 114133 never 
pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 114133 never pass
 test-armhf-armhf-xl-rtds13 migrate-support-check fail in 114133 never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 114133 never pass
 test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 114133 never pass
 test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 114133 never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail in 114133 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114034
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114034
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114034
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 114034
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail 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-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-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-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10

Re: [Xen-devel] [PATCH 1/2] x86/boot: fix early error display

2017-10-12 Thread Doug Goldstein 

> On Oct 12, 2017, at 4:27 PM, Daniel Kiper  wrote:
> 
>> On Thu, Oct 12, 2017 at 03:50:06PM -0500, Doug Goldstein wrote:
>> From: David Esler 
>> 
>> In 9180f5365524 a change was made to the send_chr function to take in
>> C-strings and print out a character at a time until a NULL was
>> encountered. However there is no code to increment the current character
>> position resulting in an endless loop of the first character. This adds
>> a simple increment.
>> 
>> Reviewed-by: Doug Goldstein 
>> Signed-off-by: David Esler 
>> ---
>> xen/arch/x86/boot/head.S | 1 +
>> 1 file changed, 1 insertion(+)
>> 
>> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
>> index fd6fc337fe..f48bbbd2e5 100644
>> --- a/xen/arch/x86/boot/head.S
>> +++ b/xen/arch/x86/boot/head.S
>> @@ -174,6 +174,7 @@ not_multiboot:
>> mov sym_esi(vga_text_buffer),%edi
>> .Lsend_chr:
>> mov (%esi),%bl
>> +inc %esi
>> test%bl,%bl# Terminate on '\0' sentinel
>> je  .Lhalt
>> mov $0x3f8+5,%dx   # UART Line Status Register
> 
> I have a feeling that you have tested this on machine without
> VGA text buffer available. Then your fix works. However, if VGA
> text buffer is available then %esi is increased twice. First time
> by inc here and once again by movsb below. So, I think that the
> issue have to be fixed in a bit different way.
> 
> Daniel

Correct. It was an EFI machine with serial only where I saw it in action. David 
has put together a new change and I’ll get it submitted tomorrow.

—
Doug
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [linux-linus test] 114362: tolerable FAIL - PUSHED

2017-10-12 Thread osstest service owner 
flight 114362 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114362/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail REGR. vs. 114297

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114297
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114297
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114297
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114297
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114297
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114297
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114297
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 114297
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 114297
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail 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-amd64-i386-libvirt  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-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt 13 migrate-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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-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-libvirt-raw 12 migrate-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-xsm 13 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-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linuxa957fd420ca8774f1a6708c64a867f056e67c46e
baseline version:
 linux7056964a85031f42e2360617b14272593729ce1b

Last test of basis   114297  2017-10-10 20:24:19 Z2 days
Testing same since   114362  2017-10-11 17:01:10 Z1 days1 attempts


People who touched revisions under test:
  Colin Ian King 
  Eric Biggers 
  Eryu Guan 
  J. Bruce Fields 
  Jeff Layton 
  Kees Cook 
  Linus Torvalds 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf

[Xen-devel] [qemu-upstream-unstable bisection] complete test-amd64-amd64-xl-pvh-intel

2017-10-12 Thread osstest service owner 
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-pvh-intel
testid guest-start

Tree: linux git://xenbits.xen.org/linux-pvops.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:  c7dfe4ac58dd9c8678126b78da961b233a49f3f9
  Bug not present: 3c44f8ed44ab559c7e5b58316751bea53adfd83b
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/114437/


  commit c7dfe4ac58dd9c8678126b78da961b233a49f3f9
  Author: Roger Pau Monne 
  Date:   Fri Sep 22 16:25:06 2017 +0100
  
  xl: introduce a domain type option
  
  Introduce a new type option to xl configuration files in order to
  specify the domain type. This supersedes the current builder option.
  
  The new option is documented in the xl.cfg man page, and the previous
  builder option is marked as deprecated.
  
  Signed-off-by: Roger Pau Monné 
  Acked-by: Ian Jackson 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-upstream-unstable/test-amd64-amd64-xl-pvh-intel.guest-start.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/qemu-upstream-unstable/test-amd64-amd64-xl-pvh-intel.guest-start
 --summary-out=tmp/114437.bisection-summary --basis-template=114029 
--blessings=real,real-bisect qemu-upstream-unstable 
test-amd64-amd64-xl-pvh-intel guest-start
Searching for failure / basis pass:
 114273 fail [host=chardonnay1] / 114029 [host=elbling1] 114014 [host=nobling1] 
113699 [host=chardonnay0] 113668 [host=godello1] 113359 [host=huxelrebe0] 
113162 [host=elbling1] 113153 ok.
Failure / basis pass flights: 114273 / 113153
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://xenbits.xen.org/linux-pvops.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 1852eae92c460813692808234da35d142a405ab7 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
5cd7ce5dde3f228b3b669ed9ca432f588947bd40 
dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e
Basis pass 458ca52f1564938c158d271f45bce0bc6ede2b3f 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
c349189772cec43498b0bec8a84146f10b8937af 
ee2c1fc48ac14a4c8b9eb9224753591fa5e7
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#458ca52f1564938c158d271f45bce0bc6ede2b3f-1852eae92c460813692808234da35d142a405ab7
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d
 
git://xenbits.xen.org/qemu-xen.git#c349189772cec43498b0bec8a84146f10b8937af-5cd7ce5dde3f228b3b669ed9ca432f588947bd40
 
git://xenbits.xen.org/xen.git#ee2c1fc48ac14a4c8b9eb9224753591fa5e7-dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e
Loaded 7962 nodes in revision graph
Searching for test results:
 113162 [host=elbling1]
 113153 pass 458ca52f1564938c158d271f45bce0bc6ede2b3f 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
c349189772cec43498b0bec8a84146f10b8937af 
ee2c1fc48ac14a4c8b9eb9224753591fa5e7
 113359 [host=huxelrebe0]
 113668 [host=godello1]
 113699 [host=chardonnay0]
 114029 [host=elbling1]
 114014 [host=nobling1]
 114328 pass 458ca52f1564938c158d271f45bce0bc6ede2b3f 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
c349189772cec43498b0bec8a84146f10b8937af 
ee2c1fc48ac14a4c8b9eb9224753591fa5e7
 114273 fail 1852eae92c460813692808234da35d142a405ab7 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
5cd7ce5dde3f228b3b669ed9ca432f588947bd40 
dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e
 114406 fail d59dabdc4cb380b79c965af28cd4ba001f04834b 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
0b157f8d977a9425e2d8d510aa011c5d4f3ec247 
6ed3559f0666b7a5436ae5a73af48e57425fc452
 114437 fail d59dabdc4cb380b79c965af28cd4ba001f04834b 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
0b157f8d977a9425e2d8d510aa011c5d4f3ec247 
c7dfe4ac58dd9c8678126b78da961b233a49f3f9
 114413 blocked d59dabdc4cb380b79c965af28cd4ba001f04834b 
c530a75c1e6a472b0eb9558310b518f0dfcd8860

[Xen-devel] [xen-unstable test] 114357: regressions - FAIL

2017-10-12 Thread osstest service owner 
flight 114357 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114357/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-cubietruck 17 guest-start.2  fail REGR. vs. 114204

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 12 guest-start  fail like 114204
 test-amd64-amd64-xl-pvh-amd  12 guest-start  fail  like 114204
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114204
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114204
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114204
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114204
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114204
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 114204
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-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-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  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-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-credit2  14 saverestore-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-libvirt 13 migrate-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-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-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-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-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail 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

version targeted for testing:
 xen  3b40cfcd1a1912c2e4c4eb353dc77cbf35c63c3a
baseline version:
 xen  572a78190403e5f2acbd01fa72c35fafe9700169

Last test of basis   114204  2017-10-09 19:19:08 Z3 days
Failing since114288  2017-10-10 17:02:59 Z2 days2 attempts
Testing same since   114357  2017-10-11 14:33:38 Z1 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Julien Grall 
  Julien Grall 
  Kevin Tian 
  Manish Jaggi 
  Stefano Stabellini 
  Tim Deegan 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass

Re: [Xen-devel] [PATCH 2/2] x86/boot: rename send_chr to print_err

2017-10-12 Thread Daniel Kiper 
On Thu, Oct 12, 2017 at 09:56:01PM +0100, Andrew Cooper wrote:
> On 12/10/2017 21:50, Doug Goldstein wrote:
> > From: David Esler 
> >
> > The send_chr function sends an entire C-string and not one character and
> > doesn't necessarily just send it over the serial UART anymore so rename
> > it to print_err so that its closer in name to what it does.
> >
> > Reviewed-by: Doug Goldstein 
> > Signed-off-by: David Esler 
>
> Reviewed-by: Andrew Cooper 

Reviewed-by: Daniel Kiper 

Daniel

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

Re: [Xen-devel] [PATCH 1/2] x86/boot: fix early error display

2017-10-12 Thread Daniel Kiper 
On Thu, Oct 12, 2017 at 03:50:06PM -0500, Doug Goldstein wrote:
> From: David Esler 
>
> In 9180f5365524 a change was made to the send_chr function to take in
> C-strings and print out a character at a time until a NULL was
> encountered. However there is no code to increment the current character
> position resulting in an endless loop of the first character. This adds
> a simple increment.
>
> Reviewed-by: Doug Goldstein 
> Signed-off-by: David Esler 
> ---
>  xen/arch/x86/boot/head.S | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index fd6fc337fe..f48bbbd2e5 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -174,6 +174,7 @@ not_multiboot:
>  mov sym_esi(vga_text_buffer),%edi
>  .Lsend_chr:
>  mov (%esi),%bl
> +inc %esi
>  test%bl,%bl# Terminate on '\0' sentinel
>  je  .Lhalt
>  mov $0x3f8+5,%dx   # UART Line Status Register

I have a feeling that you have tested this on machine without
VGA text buffer available. Then your fix works. However, if VGA
text buffer is available then %esi is increased twice. First time
by inc here and once again by movsb below. So, I think that the
issue have to be fixed in a bit different way.

Daniel

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

Re: [Xen-devel] [PATCH v2 0/2] ARM: ACPI: IORT: Hide SMMU from hardware domain's IORT table

2017-10-12 Thread Manish Jaggi 



On 10/12/2017 5:14 PM, Julien Grall wrote:



On 12/10/17 12:22, Manish Jaggi wrote:

Hi Julien,

Why do you omit parts of mail where I have asked a question , please 
avoid skiping  that removes the context.


I believe I answered it just after because you asked twice the same 
thing. So may I dropped the context but the answer was there...


For your convenience here the replicated answer.

"Why? The generation of IORT is fairly standalone.

And again, this was suggestion to share in the future and an 
expectation for this series. What I care the most is the generation to 
be fully separated from the rest."


I raised a valid point and it was totally ignored and you asked me to 
explain the rationale on a later point.

So if you choose to ignore my first point, how can I put any point.


Well, maybe you should read the e-mail more carefully because your 
point have been addressed. If they are not, then please say it rather 
than accusing the reviewers on spending not enough time on your series...


[...]

Now if you see both the codes are quite similar and there is 
redundancy in libxl and in xen code for preparing ACPI tables for 
dom0 and domU.
The point I am raising is quite clear, if all other tables like MADT, 
XSDT, RSDP, GTDT etc does not share a common generation code with xen 
what is so special about IORT.
Either we move all generation into a common code or keep redundancy 
for IORT.


I hope I have shown the code and made the point quite clear.
Please provide a technical answer rather than a simple "Why".


Why do you still continue arguing on how this is going to interact 
with libxl when your only work now (as I stated in every single 
e-mail) is for Dom0.


If the generation is generic enough, it will require little code to 
interface. After all, you only need:

- informations (e.g DeviceID, MasterID...)
- buffer for writing the generated IORT

So now it is maybe time for you to suggest an interface we can discuss 
on.

Sure. A quick draft is shared on mailing list. [1]

[1] https://marc.info/?l=xen-devel=150784236208192=2


Cheers,




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

[Xen-devel] [RFC] [Draft Design] ACPI/IORT Support in Xen.

2017-10-12 Thread Manish Jaggi 

ACPI/IORT Support in Xen.
--

I had sent out patch series [0] to hide smmu from Dom0 IORT. Extending 
the scope
and including all that is required to support ACPI/IORT in Xen. 
Presenting for review

first _draft_ of design of ACPI/IORT support in Xen. Not complete though.

Discussed is the parsing and generation of IORT table for Dom0 and DomUs.
It is proposed that IORT be parsed and the information in saved into xen 
data-structure
say host_iort_struct and is reused by all xen subsystems like ITS / SMMU 
etc.


Since this is first draft is open to technical comments, modifications
and suggestions. Please be open and feel free to add any missing points 
/ additions.


1. What is IORT. What are its components ?
2. Current Support in Xen
3. IORT for Dom0
4. IORT for DomU
5. Parsing of IORT in Xen
6. Generation of IORT
7. Future Work and TODOs

1. What is IORT. What are its components ?

IORT refers to Input Output remapping table. It is essentially used to find
information about the IO topology (PCIRC-SMMU-ITS) and relationships between
devices.

A general structure of IORT is has nodes which have information about 
PCI RC,

SMMU, ITS and Platform devices. Using an IORT table relationship between
RID -> StreamID -> DeviceId can be obtained. More specifically which 
device is
behind which SMMU and which interrupt controller, this topology is 
described in

IORT Table.

RID is a requester ID in PCI context,
StreamID is the ID of the device in SMMU context,
DeviceID is the ID programmed in ITS.

For a non-pci device RID could be simply an ID.

Each iort_node contains an ID map array to translate from one ID into 
another.

IDmap Entry {input_range, output_range, output_node_ref, id_count}
This array is present in PCI RC node,SMMU node, Named component node etc
and can reference to a SMMU or ITS node.

2. Current Support of IORT
---
Currently Xen passes host IORT table to dom0 without any modifications.
For DomU no IORT table is passed.

3. IORT for Dom0
-
IORT for Dom0 is prepared by xen and it is fairly similar to the host iort.
However few nodes could be removed removed or modified. For instance
- host SMMU nodes should not be present
- ITS group nodes are same as host iort but, no stage2 mapping is done 
for them.
- platform nodes (named components) may be selectively present depending 
on the

case where xen is using some. This could be controlled by  xen command line.
- More items : TODO

4. IORT for DomU
-
IORT for DomU is generated by the toolstack. IORT topology is different when
DomU supports device passthrough.

At a minimum domU IORT should include a single PCIRC and ITS Group.
Similar PCIRC can be added in DSDT.
Additional node can be added if platform device is assigned to domU.
No extra node should be required for PCI device pass-through.

It is proposed that the idrange of PCIRC and ITS group be constant for 
domUs.

In case if PCI PT,using a domctl toolstack can communicate
physical RID: virtual RID, deviceID: virtual deviceID to xen.

It is assumed that domU PCI Config access would be trapped in Xen. The 
RID at

which assigned device is enumerated would be the one provided by the domctl,
domctl_set_deviceid_mapping

TODO: device assign domctl i/f.

Note: This should suffice the virtual deviceID support pointed by Andre. [4]
We might not need this domctl if assign_device hypercall is extended to 
provide this information.


5. Parsing of IORT in Xen
--
IORT nodes can be saved in structures so that IORT table parsing can be done
once and is reused by all xen subsystems like ITS / SMMU etc, domain 
creation.

Proposed are the structures to hold IORT information, very similar to ACPI
structures.

iort_id_map {
range_t input_range;
range_t output_range;
void *output_reference;
...
}
=>output_reference points to object of iort_node.

struct iort_node {
struct list_head id_map;
void *context;
struct list_head list;
}
=> context could be a reference to acpi_iort_node.

struct iort_table_struct {
struct list_head pci_rc_nodes;
struct list_head smmu_nodes;
struct list_head plat_devices;
struct list_head its_group;
}

This structure is created at the point IORT table is parsed say from 
acpi_iort_init.
It is proposed to use this structure information in 
iort_init_platform_devices.

[2] [RFC v2 4/7] ACPI: arm: Support for IORT

6. IORT Generation
---
There would be a common code to generate IORT table from iort_table_struct.

a. For Dom0
the structure (iort_table_struct) be modified to remove smmu nodes
and update id_mappings.
PCIRC idmap -> output refrence to ITS group.
(RID -> DeviceID).

TODO: Describe algo in update_id_mapping function to map RID -> 
DeviceID used

in my earlier patch [3]

b. For DomU
- iort_table_struct would have minimal 2 nodes (1 PCIRC

Re: [Xen-devel] [PATCH 2/2] x86/boot: rename send_chr to print_err

2017-10-12 Thread Andrew Cooper 
On 12/10/2017 21:50, Doug Goldstein wrote:
> From: David Esler 
>
> The send_chr function sends an entire C-string and not one character and
> doesn't necessarily just send it over the serial UART anymore so rename
> it to print_err so that its closer in name to what it does.
>
> Reviewed-by: Doug Goldstein 
> Signed-off-by: David Esler 

Reviewed-by: Andrew Cooper 

This should also be included in 4.10 IMO.

> ---
>  xen/arch/x86/boot/head.S | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index f48bbbd2e5..22348b1bbe 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -161,7 +161,7 @@ not_multiboot:
>   */
>  add $sym_offs(.Lbad_ldr_nbs),%esi   # Error message
>  xor %edi,%edi   # No VGA text buffer
> -jmp .Lsend_chr
> +jmp .Lprint_err
>  .Lmb2_efi_ia_32:
>  /*
>   * Here we are on EFI IA-32 platform. Then reliable vga_text_buffer 
> zap is
> @@ -169,10 +169,10 @@ not_multiboot:
>   */
>  add $sym_offs(.Lbad_efi_msg),%esi   # Error message
>  xor %edi,%edi   # No VGA text buffer
> -jmp .Lsend_chr
> +jmp .Lprint_err
>  .Lget_vtb:
>  mov sym_esi(vga_text_buffer),%edi
> -.Lsend_chr:
> +.Lprint_err:
>  mov (%esi),%bl
>  inc %esi
>  test%bl,%bl# Terminate on '\0' sentinel
> @@ -185,11 +185,11 @@ not_multiboot:
>  mov %bl,%al
>  out %al,%dx# Send a character over the serial line
>  test%edi,%edi  # Is the VGA text buffer available?
> -jz  .Lsend_chr
> +jz  .Lprint_err
>  movsb  # Write a character to the VGA text buffer
>  mov $7,%al
>  stosb  # Write an attribute to the VGA text buffer
> -jmp .Lsend_chr
> +jmp .Lprint_err
>  .Lhalt: hlt
>  jmp .Lhalt
>  


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

Re: [Xen-devel] [PATCH 1/2] x86/boot: fix early error display

2017-10-12 Thread Andrew Cooper 
On 12/10/2017 21:50, Doug Goldstein wrote:
> From: David Esler 
>
> In 9180f5365524 a change was made to the send_chr function to take in
> C-strings and print out a character at a time until a NULL was
> encountered. However there is no code to increment the current character
> position resulting in an endless loop of the first character. This adds
> a simple increment.
>
> Reviewed-by: Doug Goldstein 
> Signed-off-by: David Esler 

Reviewed-by: Andrew Cooper 

CC'ing Julien as release manager. This should be included in 4.10 IMO,
and is a backport candidate.

> ---
>  xen/arch/x86/boot/head.S | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index fd6fc337fe..f48bbbd2e5 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -174,6 +174,7 @@ not_multiboot:
>  mov sym_esi(vga_text_buffer),%edi
>  .Lsend_chr:
>  mov (%esi),%bl
> +inc %esi
>  test%bl,%bl# Terminate on '\0' sentinel
>  je  .Lhalt
>  mov $0x3f8+5,%dx   # UART Line Status Register


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

[Xen-devel] [PATCH 1/2] x86/boot: fix early error display

2017-10-12 Thread Doug Goldstein 
From: David Esler 

In 9180f5365524 a change was made to the send_chr function to take in
C-strings and print out a character at a time until a NULL was
encountered. However there is no code to increment the current character
position resulting in an endless loop of the first character. This adds
a simple increment.

Reviewed-by: Doug Goldstein 
Signed-off-by: David Esler 
---
 xen/arch/x86/boot/head.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index fd6fc337fe..f48bbbd2e5 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -174,6 +174,7 @@ not_multiboot:
 mov sym_esi(vga_text_buffer),%edi
 .Lsend_chr:
 mov (%esi),%bl
+inc %esi
 test%bl,%bl# Terminate on '\0' sentinel
 je  .Lhalt
 mov $0x3f8+5,%dx   # UART Line Status Register
-- 
2.13.5


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

[Xen-devel] [PATCH 2/2] x86/boot: rename send_chr to print_err

2017-10-12 Thread Doug Goldstein 
From: David Esler 

The send_chr function sends an entire C-string and not one character and
doesn't necessarily just send it over the serial UART anymore so rename
it to print_err so that its closer in name to what it does.

Reviewed-by: Doug Goldstein 
Signed-off-by: David Esler 
---
 xen/arch/x86/boot/head.S | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index f48bbbd2e5..22348b1bbe 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -161,7 +161,7 @@ not_multiboot:
  */
 add $sym_offs(.Lbad_ldr_nbs),%esi   # Error message
 xor %edi,%edi   # No VGA text buffer
-jmp .Lsend_chr
+jmp .Lprint_err
 .Lmb2_efi_ia_32:
 /*
  * Here we are on EFI IA-32 platform. Then reliable vga_text_buffer 
zap is
@@ -169,10 +169,10 @@ not_multiboot:
  */
 add $sym_offs(.Lbad_efi_msg),%esi   # Error message
 xor %edi,%edi   # No VGA text buffer
-jmp .Lsend_chr
+jmp .Lprint_err
 .Lget_vtb:
 mov sym_esi(vga_text_buffer),%edi
-.Lsend_chr:
+.Lprint_err:
 mov (%esi),%bl
 inc %esi
 test%bl,%bl# Terminate on '\0' sentinel
@@ -185,11 +185,11 @@ not_multiboot:
 mov %bl,%al
 out %al,%dx# Send a character over the serial line
 test%edi,%edi  # Is the VGA text buffer available?
-jz  .Lsend_chr
+jz  .Lprint_err
 movsb  # Write a character to the VGA text buffer
 mov $7,%al
 stosb  # Write an attribute to the VGA text buffer
-jmp .Lsend_chr
+jmp .Lprint_err
 .Lhalt: hlt
 jmp .Lhalt
 
-- 
2.13.5


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

Re: [Xen-devel] [PATCH v1 15/27] compiler: Option to default to hidden symbols

2017-10-12 Thread Luis R. Rodriguez 
On Wed, Oct 11, 2017 at 01:30:15PM -0700, Thomas Garnier wrote:
> Provide an option to default visibility to hidden except for key
> symbols. This option is disabled by default and will be used by x86_64
> PIE support to remove errors between compilation units.
> 
> The default visibility is also enabled for external symbols that are
> compared as they maybe equals (start/end of sections). In this case,
> older versions of GCC will remove the comparison if the symbols are
> hidden. This issue exists at least on gcc 4.9 and before.
> 
> Signed-off-by: Thomas Garnier 

<-- snip -->

> diff --git a/arch/x86/kernel/cpu/microcode/core.c 
> b/arch/x86/kernel/cpu/microcode/core.c
> index 86e8f0b2537b..8f021783a929 100644
> --- a/arch/x86/kernel/cpu/microcode/core.c
> +++ b/arch/x86/kernel/cpu/microcode/core.c
> @@ -144,8 +144,8 @@ static bool __init check_loader_disabled_bsp(void)
>   return *res;
>  }
>  
> -extern struct builtin_fw __start_builtin_fw[];
> -extern struct builtin_fw __end_builtin_fw[];
> +extern struct builtin_fw __start_builtin_fw[] __default_visibility;
> +extern struct builtin_fw __end_builtin_fw[] __default_visibility;
>  
>  bool get_builtin_firmware(struct cpio_data *cd, const char *name)
>  {

<-- snip -->

> diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
> index e5da44eddd2f..1aa5d6dac9e1 100644
> --- a/include/asm-generic/sections.h
> +++ b/include/asm-generic/sections.h
> @@ -30,6 +30,9 @@
>   *   __irqentry_text_start, __irqentry_text_end
>   *   __softirqentry_text_start, __softirqentry_text_end
>   */
> +#ifdef CONFIG_DEFAULT_HIDDEN
> +#pragma GCC visibility push(default)
> +#endif
>  extern char _text[], _stext[], _etext[];
>  extern char _data[], _sdata[], _edata[];
>  extern char __bss_start[], __bss_stop[];
> @@ -46,6 +49,9 @@ extern char __softirqentry_text_start[], 
> __softirqentry_text_end[];
>  
>  /* Start and end of .ctors section - used for constructor calls. */
>  extern char __ctors_start[], __ctors_end[];
> +#ifdef CONFIG_DEFAULT_HIDDEN
> +#pragma GCC visibility pop
> +#endif
>  
>  extern __visible const void __nosave_begin, __nosave_end;
>  
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index e95a2631e545..6997716f73bf 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -78,6 +78,14 @@ extern void __chk_io_ptr(const volatile void __iomem *);
>  #include 
>  #endif
>  
> +/* Useful for Position Independent Code to reduce global references */
> +#ifdef CONFIG_DEFAULT_HIDDEN
> +#pragma GCC visibility push(hidden)
> +#define __default_visibility  __attribute__((visibility ("default")))

Does this still work with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION ?

> +#else
> +#define __default_visibility
> +#endif
> +
>  /*
>   * Generic compiler-dependent macros required for kernel
>   * build go below this comment. Actual compiler/compiler version
> diff --git a/init/Kconfig b/init/Kconfig
> index ccb1d8daf241..b640201fcff7 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1649,6 +1649,13 @@ config PROFILING
>  config TRACEPOINTS
>   bool
>  
> +#
> +# Default to hidden visibility for all symbols.
> +# Useful for Position Independent Code to reduce global references.
> +#
> +config DEFAULT_HIDDEN
> + bool

Note it is default.

Has 0-day ran through this git tree? It should be easy to get it added for
testing. Also, even though most changes are x86 based there are some generic
changes and I'd love a warm fuzzy this won't break odd / random builds.
Although 0-day does cover a lot of test cases, it only has limited run time
tests. There are some other test beds which also cover some more obscure
architectures. Having a test pass on Guenter's test bed would be nice to
see. For that please coordinate with Guenter if he's willing to run this
a test for you.

  Luis

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

Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure

2017-10-12 Thread Boris Ostrovsky 
On 10/12/2017 03:27 PM, Andrew Cooper wrote:
> On 12/10/17 20:11, Boris Ostrovsky wrote:
>> On 10/06/2017 10:32 AM, Josh Poimboeuf wrote:
>>> On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote:
>  #ifdef CONFIG_PARAVIRT
> +/*
> + * Paravirt alternatives are applied much earlier than normal 
> alternatives.
> + * They are only applied when running on a hypervisor.  They replace some
> + * native instructions with calls to pv ops.
> + */
> +void __init apply_pv_alternatives(void)
> +{
> + setup_force_cpu_cap(X86_FEATURE_PV_OPS);
 Not for Xen HVM guests.
>>> From what I can tell, HVM guests still use pv_time_ops and
>>> pv_mmu_ops.exit_mmap, right?
>>>
> + apply_alternatives(__pv_alt_instructions, __pv_alt_instructions_end);
> +}
 This is a problem (at least for Xen PV guests):
 apply_alternatives()->text_poke_early()->local_irq_save()->...'cli'->death.
>>> Ah, right.
>>>
 It might be possible not to turn off/on the interrupts in this
 particular case since the guest probably won't be able to handle an
 interrupt at this point anyway.
>>> Yeah, that should work.  For Xen and for the other hypervisors, this is
>>> called well before irq init, so interrupts can't be handled yet anyway.
>> There is also another problem:
>>
>> [1.312425] general protection fault:  [#1] SMP
>> [1.312901] Modules linked in:
>> [1.313389] CPU: 0 PID: 1 Comm: init Not tainted 4.14.0-rc4+ #6
>> [1.313878] task: 88003e2c task.stack: c938c000
>> [1.314360] RIP: 1e030:entry_SYSCALL_64_fastpath+0x1/0xa5
>> [1.314854] RSP: e02b:c938ff50 EFLAGS: 00010046
>> [1.315336] RAX: 000c RBX: 55f550168040 RCX:
>> 7fcfc959f59a
>> [1.315827] RDX:  RSI:  RDI:
>> 
>> [1.316315] RBP: 000a R08: 037f R09:
>> 0064
>> [1.316805] R10: 1f89cbf5 R11: 88003e2c R12:
>> 7fcfc958ad60
>> [1.317300] R13:  R14: 55f550185954 R15:
>> 1000
>> [1.317801] FS:  () GS:88003f80()
>> knlGS:
>> [1.318267] CS:  e033 DS:  ES:  CR0: 80050033
>> [1.318750] CR2: 7fcfc97ab218 CR3: 3c88e000 CR4:
>> 00042660
>> [1.319235] Call Trace:
>> [1.319700] Code: 51 50 57 56 52 51 6a da 41 50 41 51 41 52 41 53 48
>> 83 ec 30 65 4c 8b 1c 25 c0 d2 00 00 41 f7 03 df 39 08 90 0f 85 a5 00 00
>> 00 50  15 9c 95 d0 ff 58 48 3d 4c 01 00 00 77 0f 4c 89 d1 ff 14 c5
>> [1.321161] RIP: entry_SYSCALL_64_fastpath+0x1/0xa5 RSP: c938ff50
>> [1.344255] ---[ end trace d7cb8cd6cd7c294c ]---
>> [1.345009] Kernel panic - not syncing: Attempted to kill init!
>> exitcode=0x000b
>>
>>
>> All code
>> 
>>0:51   push   %rcx
>>1:50   push   %rax
>>2:57   push   %rdi
>>3:56   push   %rsi
>>4:52   push   %rdx
>>5:51   push   %rcx
>>6:6a dapushq  $0xffda
>>8:41 50push   %r8
>>a:41 51push   %r9
>>c:41 52push   %r10
>>e:41 53push   %r11
>>   10:48 83 ec 30  sub$0x30,%rsp
>>   14:65 4c 8b 1c 25 c0 d2 mov%gs:0xd2c0,%r11
>>   1b:00 00
>>   1d:41 f7 03 df 39 08 90 testl  $0x900839df,(%r11)
>>   24:0f 85 a5 00 00 00jne0xcf
>>   2a:50   push   %rax
>>   2b:*ff 15 9c 95 d0 ffcallq  *-0x2f6a64(%rip)#
>> 0xffd095cd<-- trapping instruction
>>   31:58   pop%rax
>>   32:48 3d 4c 01 00 00cmp$0x14c,%rax
>>   38:77 0fja 0x49
>>   3a:4c 89 d1 mov%r10,%rcx
>>   3d:ff   .byte 0xff
>>   3e:14 c5adc$0xc5,%al
>>
>>
>> so the original 'cli' was replaced with the pv call but to me the offset
>> looks a bit off, no? Shouldn't it always be positive?
> callq takes a 32bit signed displacement, so jumping back by up to 2G is
> perfectly legitimate.

Yes, but

ostr@workbase> nm vmlinux | grep entry_SYSCALL_64_fastpath
817365dd t entry_SYSCALL_64_fastpath
ostr@workbase> nm vmlinux | grep " pv_irq_ops"
81c2dbc0 D pv_irq_ops
ostr@workbase>

so pv_irq_ops.irq_disable is about 5MB ahead of where we are now. (I
didn't mean that x86 instruction set doesn't allow negative
displacement, I was trying to say that pv_irq_ops always live further down)


>
> The #GP[0] however means that whatever 8 byte value was found at
> -0x2f6a64(%rip) was a non-canonical address.
>
> One option is that the pvops structure hasn't been initialised

Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure

2017-10-12 Thread Andrew Cooper 
On 12/10/17 20:11, Boris Ostrovsky wrote:
> On 10/06/2017 10:32 AM, Josh Poimboeuf wrote:
>> On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote:
  #ifdef CONFIG_PARAVIRT
 +/*
 + * Paravirt alternatives are applied much earlier than normal 
 alternatives.
 + * They are only applied when running on a hypervisor.  They replace some
 + * native instructions with calls to pv ops.
 + */
 +void __init apply_pv_alternatives(void)
 +{
 +  setup_force_cpu_cap(X86_FEATURE_PV_OPS);
>>> Not for Xen HVM guests.
>> From what I can tell, HVM guests still use pv_time_ops and
>> pv_mmu_ops.exit_mmap, right?
>>
 +  apply_alternatives(__pv_alt_instructions, __pv_alt_instructions_end);
 +}
>>> This is a problem (at least for Xen PV guests):
>>> apply_alternatives()->text_poke_early()->local_irq_save()->...'cli'->death.
>> Ah, right.
>>
>>> It might be possible not to turn off/on the interrupts in this
>>> particular case since the guest probably won't be able to handle an
>>> interrupt at this point anyway.
>> Yeah, that should work.  For Xen and for the other hypervisors, this is
>> called well before irq init, so interrupts can't be handled yet anyway.
> There is also another problem:
>
> [1.312425] general protection fault:  [#1] SMP
> [1.312901] Modules linked in:
> [1.313389] CPU: 0 PID: 1 Comm: init Not tainted 4.14.0-rc4+ #6
> [1.313878] task: 88003e2c task.stack: c938c000
> [1.314360] RIP: 1e030:entry_SYSCALL_64_fastpath+0x1/0xa5
> [1.314854] RSP: e02b:c938ff50 EFLAGS: 00010046
> [1.315336] RAX: 000c RBX: 55f550168040 RCX:
> 7fcfc959f59a
> [1.315827] RDX:  RSI:  RDI:
> 
> [1.316315] RBP: 000a R08: 037f R09:
> 0064
> [1.316805] R10: 1f89cbf5 R11: 88003e2c R12:
> 7fcfc958ad60
> [1.317300] R13:  R14: 55f550185954 R15:
> 1000
> [1.317801] FS:  () GS:88003f80()
> knlGS:
> [1.318267] CS:  e033 DS:  ES:  CR0: 80050033
> [1.318750] CR2: 7fcfc97ab218 CR3: 3c88e000 CR4:
> 00042660
> [1.319235] Call Trace:
> [1.319700] Code: 51 50 57 56 52 51 6a da 41 50 41 51 41 52 41 53 48
> 83 ec 30 65 4c 8b 1c 25 c0 d2 00 00 41 f7 03 df 39 08 90 0f 85 a5 00 00
> 00 50  15 9c 95 d0 ff 58 48 3d 4c 01 00 00 77 0f 4c 89 d1 ff 14 c5
> [1.321161] RIP: entry_SYSCALL_64_fastpath+0x1/0xa5 RSP: c938ff50
> [1.344255] ---[ end trace d7cb8cd6cd7c294c ]---
> [1.345009] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x000b
>
>
> All code
> 
>0:51   push   %rcx
>1:50   push   %rax
>2:57   push   %rdi
>3:56   push   %rsi
>4:52   push   %rdx
>5:51   push   %rcx
>6:6a dapushq  $0xffda
>8:41 50push   %r8
>a:41 51push   %r9
>c:41 52push   %r10
>e:41 53push   %r11
>   10:48 83 ec 30  sub$0x30,%rsp
>   14:65 4c 8b 1c 25 c0 d2 mov%gs:0xd2c0,%r11
>   1b:00 00
>   1d:41 f7 03 df 39 08 90 testl  $0x900839df,(%r11)
>   24:0f 85 a5 00 00 00jne0xcf
>   2a:50   push   %rax
>   2b:*ff 15 9c 95 d0 ffcallq  *-0x2f6a64(%rip)#
> 0xffd095cd<-- trapping instruction
>   31:58   pop%rax
>   32:48 3d 4c 01 00 00cmp$0x14c,%rax
>   38:77 0fja 0x49
>   3a:4c 89 d1 mov%r10,%rcx
>   3d:ff   .byte 0xff
>   3e:14 c5adc$0xc5,%al
>
>
> so the original 'cli' was replaced with the pv call but to me the offset
> looks a bit off, no? Shouldn't it always be positive?

callq takes a 32bit signed displacement, so jumping back by up to 2G is
perfectly legitimate.

The #GP[0] however means that whatever 8 byte value was found at
-0x2f6a64(%rip) was a non-canonical address.

One option is that the pvops structure hasn't been initialised properly,
but an alternative is that the relocation wasn't processed correctly,
and the code is trying to reference something which isn't a function
pointer.

~Andrew

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

[Xen-devel] [PATCH for-4.10 v2 2/5] tools/dombuilder: Remove clear_page() from xc_dom_boot.c

2017-10-12 Thread Andrew Cooper 
pfn 0 is a legitimate (albeit unlikely) frame to use, so skipping it is wrong.
This behaviour appears to exists simply to cover the fact that zero is the
default value of an uninitialised field in dom.

ARM already clears the frames at the point that the pfns are allocated,
meaning that the added clear_page() is wasteful.  Alter x86 to match ARM and
clear the page when it is allocated.

Signed-off-by: Andrew Cooper 
Acked-by: Wei Liu 
Tested-by: Julien Grall 
---
CC: Ian Jackson 
CC: Julien Grall 
---
 tools/libxc/xc_dom_arm.c  |  3 ++-
 tools/libxc/xc_dom_boot.c | 26 --
 tools/libxc/xc_dom_x86.c  |  8 
 3 files changed, 10 insertions(+), 27 deletions(-)

diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 7c4997a..fce151d 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -91,7 +91,8 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
 xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_pfn);
 xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_pfn);
 xc_clear_domain_page(dom->xch, dom->guest_domid, base + 
MEMACCESS_PFN_OFFSET);
-xc_clear_domain_page(dom->xch, dom->guest_domid, base + VUART_PFN_OFFSET);
+xc_clear_domain_page(dom->xch, dom->guest_domid, dom->vuart_gfn);
+
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_PFN,
 dom->console_pfn);
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_STORE_PFN,
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 40eb518..2e5681d 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -62,25 +62,6 @@ static int setup_hypercall_page(struct xc_dom_image *dom)
 return rc;
 }
 
-static int clear_page(struct xc_dom_image *dom, xen_pfn_t pfn)
-{
-xen_pfn_t dst;
-int rc;
-
-if ( pfn == 0 )
-return 0;
-
-dst = xc_dom_p2m(dom, pfn);
-DOMPRINTF("%s: pfn 0x%" PRIpfn ", mfn 0x%" PRIpfn "",
-  __FUNCTION__, pfn, dst);
-rc = xc_clear_domain_page(dom->xch, dom->guest_domid, dst);
-if ( rc != 0 )
-xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
- "%s: xc_clear_domain_page failed (pfn 0x%" PRIpfn
- ", rc=%d)", __FUNCTION__, pfn, rc);
-return rc;
-}
-
 
 /*  */
 
@@ -222,13 +203,6 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
 if ( (rc = dom->arch_hooks->setup_pgtables(dom)) != 0 )
 return rc;
 
-if ( (rc = clear_page(dom, dom->console_pfn)) != 0 )
-return rc;
-if ( (rc = clear_page(dom, dom->xenstore_pfn)) != 0 )
-return rc;
-if ( (rc = clear_page(dom, dom->vuart_gfn)) != 0 )
-return rc;
-
 /* start info page */
 if ( dom->arch_hooks->start_info )
 dom->arch_hooks->start_info(dom);
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 47db218..bff68a0 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -543,10 +543,14 @@ static int alloc_magic_pages_pv(struct xc_dom_image *dom)
 dom->xenstore_pfn = xc_dom_alloc_page(dom, "xenstore");
 if ( dom->xenstore_pfn == INVALID_PFN )
 return -1;
+xc_clear_domain_page(dom->xch, dom->guest_domid,
+ xc_dom_p2m(dom, dom->xenstore_pfn));
 
 dom->console_pfn = xc_dom_alloc_page(dom, "console");
 if ( dom->console_pfn == INVALID_PFN )
 return -1;
+xc_clear_domain_page(dom->xch, dom->guest_domid,
+ xc_dom_p2m(dom, dom->console_pfn));
 
 dom->alloc_bootstack = 1;
 
@@ -696,7 +700,11 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
  special_pfn(SPECIALPAGE_IDENT_PT) << PAGE_SHIFT);
 
 dom->console_pfn = special_pfn(SPECIALPAGE_CONSOLE);
+xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_pfn);
+
 dom->xenstore_pfn = special_pfn(SPECIALPAGE_XENSTORE);
+xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_pfn);
+
 dom->parms.virt_hypercall = -1;
 
 rc = 0;
-- 
2.1.4


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

[Xen-devel] [PATCH for-4.10 v2 4/5] tools/dombuilder: Fix asymmetry when setting up console and xenstore rings

2017-10-12 Thread Andrew Cooper 
libxl always uses xc_dom_gnttab_init(), which internally calls
xc_dom_gnttab{_hvm,}_seed() to set up the grants point at the console and
xenstore rings.  For HVM guests, libxl then asks Xen for the information set
up previously, and calls xc_dom_gnttab_hvm_seed() a second time, which is
wasteful.  ARM construction expects libxl to have set up
dom->{console,xenstore}_evtchn earlier, so only actually functions because of
this second call.

Rationalise everything and make it consistent for all guests.

 1) Users of the domain builder are expected to provide
dom->{console,xenstore}_{evtchn,domid} unconditionally.  This is checked
by setting invalid values in xc_dom_allocate(), and checking in
xc_dom_boot_image().

 2) For x86 HVM and ARM guests, the event channels are given to Xen at the
same time as the ring gfns.  ARM already did this, but x86 is updated to
match.  x86 PV already provides this information in the start_info page.

 3) Libxl is updated to drop all relevant functionality from
hvm_build_set_params(), and behave consistently with PV guests when it
comes to the handling of dom->{console,xenstore}_{evtchn,domid,gfn}.

This removes several redundant hypercalls (including a foreign mapping) from
the x86 HVM and ARM construction paths.

Signed-off-by: Andrew Cooper 
Reviewed-by: Roger Pau Monné 
Acked-by: Wei Liu 
Tested-by: Julien Grall 
---
CC: Ian Jackson 
CC: Julien Grall 

v2:
 * use ~0 for INVALID_DOMID to avoid
   [-Werror,-Wtautological-constant-out-of-range-compare] from Clang
 * Set errno to EINVAL in xc_dom_check_required_fields()
---
 tools/libxc/include/xc_dom.h  | 12 
 tools/libxc/xc_dom_arm.c  |  2 +-
 tools/libxc/xc_dom_boot.c | 39 +++
 tools/libxc/xc_dom_compat_linux.c |  2 ++
 tools/libxc/xc_dom_core.c |  5 +
 tools/libxc/xc_dom_x86.c  |  4 
 tools/libxl/libxl_dom.c   | 28 ++--
 tools/libxl/libxl_internal.h  |  1 -
 8 files changed, 69 insertions(+), 24 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 5907559..a1c3de2 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -20,6 +20,8 @@
 #include 
 
 #define INVALID_PFN ((xen_pfn_t)-1)
+#define INVALID_EVTCHN (~0u)
+#define INVALID_DOMID  (~0)
 #define X86_HVM_NR_SPECIAL_PAGES8
 #define X86_HVM_END_SPECIAL_REGION  0xff000u
 
@@ -104,10 +106,16 @@ struct xc_dom_image {
  * Details for the toolstack-prepared rings.
  *
  * *_gfn fields are allocated by the domain builder.
+ * *_{evtchn,domid} fields must be provided by the caller.
  */
 xen_pfn_t console_gfn;
 xen_pfn_t xenstore_gfn;
 
+unsigned int console_evtchn;
+unsigned int xenstore_evtchn;
+uint32_t console_domid;
+uint32_t xenstore_domid;
+
 /*
  * initrd parameters as specified in start_info page
  * Depending on capabilities of the booted kernel this may be a virtual
@@ -165,10 +173,6 @@ struct xc_dom_image {
 
 /* misc xen domain config stuff */
 unsigned long flags;
-unsigned int console_evtchn;
-unsigned int xenstore_evtchn;
-uint32_t console_domid;
-uint32_t xenstore_domid;
 xen_pfn_t shared_info_mfn;
 
 xc_interface *xch;
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 2fe75cd..2134ce4 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -99,7 +99,7 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
 dom->xenstore_gfn);
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_MONITOR_RING_PFN,
 base + MEMACCESS_PFN_OFFSET);
-/* allocated by toolstack */
+
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_EVTCHN,
 dom->console_evtchn);
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_STORE_EVTCHN,
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index bbf98b6..75836bd 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -163,6 +163,42 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, 
xen_pfn_t pfn,
 return ptr;
 }
 
+static int xc_dom_check_required_fields(struct xc_dom_image *dom)
+{
+int rc = 0;
+
+if ( dom->console_evtchn == INVALID_EVTCHN )
+{
+xc_dom_panic(dom->xch, XC_INVALID_PARAM,
+ "%s: Caller didn't set dom->console_evtchn", __func__);
+rc = -1;
+}
+if ( dom->console_domid == INVALID_DOMID )
+{
+xc_dom_panic(dom->xch, XC_INVALID_PARAM,
+ "%s: Caller didn't set dom->console_domid", __func__);
+rc = -1;
+}
+
+if ( dom->xenstore_evtchn == INVALID_EVTCHN )
+{
+xc_dom_panic(dom->xch, XC_INVALID_PARAM,
+ "%s: Caller

[Xen-devel] [PATCH for-4.10 v2 1/5] tools/dombuilder: Drop more PVH v1 leftovers

2017-10-12 Thread Andrew Cooper 
alloc_magic_pages() is renamed to alloc_magic_pages_pv() to mirror its
alloc_magic_pages_hvm() counterpart.  Delete a redundant comment, introduce
some newlines clarity, and remove a logically dead allocation of shared info.

Signed-off-by: Andrew Cooper 
Reviewed-by: Roger Pau Monné 
Acked-by: Wei Liu 
Tested-by: Julien Grall 
---
CC: Ian Jackson 
CC: Julien Grall 
---
 tools/libxc/xc_dom_x86.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index bac584f..47db218 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -534,24 +534,20 @@ static int alloc_p2m_list_x86_64(struct xc_dom_image *dom)
 
 /*  */
 
-static int alloc_magic_pages(struct xc_dom_image *dom)
+static int alloc_magic_pages_pv(struct xc_dom_image *dom)
 {
-/* allocate special pages */
 dom->start_info_pfn = xc_dom_alloc_page(dom, "start info");
 if ( dom->start_info_pfn == INVALID_PFN )
 return -1;
+
 dom->xenstore_pfn = xc_dom_alloc_page(dom, "xenstore");
 if ( dom->xenstore_pfn == INVALID_PFN )
 return -1;
+
 dom->console_pfn = xc_dom_alloc_page(dom, "console");
 if ( dom->console_pfn == INVALID_PFN )
 return -1;
-if ( xc_dom_translated(dom) )
-{
-dom->shared_info_pfn = xc_dom_alloc_page(dom, "shared info");
-if ( dom->shared_info_pfn == INVALID_PFN )
-return -1;
-}
+
 dom->alloc_bootstack = 1;
 
 return 0;
@@ -1756,7 +1752,7 @@ static struct xc_dom_arch xc_dom_32_pae = {
 .sizeof_pfn = 4,
 .p2m_base_supported = 0,
 .arch_private_size = sizeof(struct xc_dom_image_x86),
-.alloc_magic_pages = alloc_magic_pages,
+.alloc_magic_pages = alloc_magic_pages_pv,
 .alloc_pgtables = alloc_pgtables_x86_32_pae,
 .alloc_p2m_list = alloc_p2m_list_x86_32,
 .setup_pgtables = setup_pgtables_x86_32_pae,
@@ -1775,7 +1771,7 @@ static struct xc_dom_arch xc_dom_64 = {
 .sizeof_pfn = 8,
 .p2m_base_supported = 1,
 .arch_private_size = sizeof(struct xc_dom_image_x86),
-.alloc_magic_pages = alloc_magic_pages,
+.alloc_magic_pages = alloc_magic_pages_pv,
 .alloc_pgtables = alloc_pgtables_x86_64,
 .alloc_p2m_list = alloc_p2m_list_x86_64,
 .setup_pgtables = setup_pgtables_x86_64,
-- 
2.1.4


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

[Xen-devel] [PATCH for-4.10 v2 0/5] tools/dombuilder: Fixes and improvements to grant handling

2017-10-12 Thread Andrew Cooper 
A git tree version is available:

http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/dombuilder-gnt-v2

Changes in v2: Mainly a rebase over c/s 5b42c82f "tools/libxc: Fix domid
parameter types", and fixup from review comments.  See individual patches for
details

Andrew Cooper (5):
  tools/dombuilder: Drop more PVH v1 leftovers
  tools/dombuilder: Remove clear_page() from xc_dom_boot.c
  tools/dombuilder: Switch to using gfn terminology for console and
xenstore rings
  tools/dombuilder: Fix asymmetry when setting up console and xenstore
rings
  tools/dombuilder: Prevent failures of xc_dom_gnttab_init()

 tools/libxc/include/xc_dom.h  |  26 ++--
 tools/libxc/xc_dom_arm.c  |  17 ++---
 tools/libxc/xc_dom_boot.c | 126 +++---
 tools/libxc/xc_dom_compat_linux.c |   6 +-
 tools/libxc/xc_dom_core.c |   8 +++
 tools/libxc/xc_dom_x86.c  |  57 +
 tools/libxl/libxl_dom.c   |  51 ++-
 tools/libxl/libxl_internal.h  |   1 -
 8 files changed, 169 insertions(+), 123 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH for-4.10 v2 5/5] tools/dombuilder: Prevent failures of xc_dom_gnttab_init()

2017-10-12 Thread Andrew Cooper 
Recent changes in grant table configuration have caused calls to
xc_dom_gnttab_init() to fail if not proceeded with a call to
xc_domain_set_gnttab_limits().  This is backwards from the point of view of
3rd party dombuilder users.

Add max_{grant,maptrack}_frames parameters to struct xc_dom_image, and require
them to be set by callers using xc_dom_gnttab_init().  Libxl, which uses
xc_dom_gnttab_init() itself is updated appropriately.

Signed-off-by: Andrew Cooper 
Acked-by: Wei Liu 
Tested-by: Julien Grall 
---
CC: Ian Jackson 
CC: Julien Grall 

v2:
 * Set errno to EINVAL if max_{grant,maptrack}_frames are not provided
---
 tools/libxc/include/xc_dom.h |  4 
 tools/libxc/xc_dom_boot.c| 16 
 tools/libxc/xc_dom_core.c|  3 +++
 tools/libxl/libxl_dom.c  | 12 ++--
 4 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index a1c3de2..5292424 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -116,6 +116,10 @@ struct xc_dom_image {
 uint32_t console_domid;
 uint32_t xenstore_domid;
 
+/* Grant limit configuration; mandatory if calling xc_dom_gnttab_init(). */
+unsigned int max_grant_frames;
+unsigned int max_maptrack_frames;
+
 /*
  * initrd parameters as specified in start_info page
  * Depending on capabilities of the booted kernel this may be a virtual
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 75836bd..7c21fea 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -420,6 +420,22 @@ int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t 
domid,
 
 int xc_dom_gnttab_init(struct xc_dom_image *dom)
 {
+int rc;
+
+if ( dom->max_grant_frames == -1 || dom->max_maptrack_frames == -1 )
+{
+xc_dom_panic(dom->xch, XC_INVALID_PARAM,
+ "%s: Caller didn't set grant limit information", 
__func__);
+errno = EINVAL;
+
+return -1;
+}
+
+if ( (rc = xc_domain_set_gnttab_limits(dom->xch, dom->guest_domid,
+   dom->max_grant_frames,
+   dom->max_maptrack_frames)) != 0 )
+return rc;
+
 if ( xc_dom_translated(dom) ) {
 return xc_dom_gnttab_hvm_seed(dom->xch, dom->guest_domid,
   dom->console_gfn, dom->xenstore_gfn,
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index 7087c50..d660651 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -784,6 +784,9 @@ struct xc_dom_image *xc_dom_allocate(xc_interface *xch,
 dom->console_domid = INVALID_DOMID;
 dom->xenstore_domid = INVALID_DOMID;
 
+dom->max_grant_frames = -1;
+dom->max_maptrack_frames = -1;
+
 dom->flags = SIF_VIRT_P2M_4TOOLS;
 
 dom->alloc_malloc += sizeof(*dom);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index fcdeef0..fa5319d 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -358,12 +358,6 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
 return ERROR_FAIL;
 }
 
-if (xc_domain_set_gnttab_limits(ctx->xch, domid, info->max_grant_frames,
-info->max_maptrack_frames) != 0) {
-LOG(ERROR, "Couldn't set grant table limits");
-return ERROR_FAIL;
-}
-
 /*
  * Check if the domain has any CPU or node affinity already. If not, try
  * to build up the latter via automatic NUMA placement. In fact, in case
@@ -815,6 +809,9 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
 dom->xenstore_domid = state->store_domid;
 dom->claim_enabled = libxl_defbool_val(info->claim_mode);
 
+dom->max_grant_frames= info->max_grant_frames;
+dom->max_maptrack_frames = info->max_maptrack_frames;
+
 if (info->num_vnuma_nodes != 0) {
 unsigned int i;
 
@@ -1151,6 +1148,9 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
 dom->xenstore_evtchn = state->store_port;
 dom->xenstore_domid = state->store_domid;
 
+dom->max_grant_frames= info->max_grant_frames;
+dom->max_maptrack_frames = info->max_maptrack_frames;
+
 /* The params from the configuration file are in Mb, which are then
  * multiplied by 1 Kb. This was then divided off when calling
  * the old xc_hvm_build_target_mem() which then turned them to bytes.
-- 
2.1.4


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

[Xen-devel] [PATCH for-4.10 v2 3/5] tools/dombuilder: Switch to using gfn terminology for console and xenstore rings

2017-10-12 Thread Andrew Cooper 
The sole use of xc_dom_translated() and xc_dom_p2m() outside of the domain
builder is for libxl_dom() to translate the console and xenstore pfns back
into useful values.  PV guest pfns are only interesting to the domain builder,
and gfns are the address space used by all other hypercalls.

Renaming the fields in xc_dom_image is deliberate, as it will cause
out-of-tree users of the dombuilder to notice the different semantics.

Correct the terminology throughout xc_dom_gnttab{_hvm,}_seed(), which are all
using gfns despite the existing variable names.

Signed-off-by: Andrew Cooper 
Reviewed-by: Roger Pau Monné 
Acked-by: Wei Liu 
Tested-by: Julien Grall 
---
CC: Ian Jackson 
CC: Julien Grall 

v2:
 * More style fixes
---
 tools/libxc/include/xc_dom.h  | 10 +++--
 tools/libxc/xc_dom_arm.c  | 12 +--
 tools/libxc/xc_dom_boot.c | 45 ++-
 tools/libxc/xc_dom_compat_linux.c |  4 ++--
 tools/libxc/xc_dom_x86.c  | 45 ---
 tools/libxl/libxl_dom.c   | 11 +++---
 6 files changed, 63 insertions(+), 64 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index cdcdd07..5907559 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -94,8 +94,6 @@ struct xc_dom_image {
 struct xc_dom_seg devicetree_seg;
 struct xc_dom_seg start_info_seg; /* HVMlite only */
 xen_pfn_t start_info_pfn;
-xen_pfn_t console_pfn;
-xen_pfn_t xenstore_pfn;
 xen_pfn_t shared_info_pfn;
 xen_pfn_t bootstack_pfn;
 xen_pfn_t pfn_alloc_end;
@@ -103,6 +101,14 @@ struct xc_dom_image {
 xen_vaddr_t bsd_symtab_start;
 
 /*
+ * Details for the toolstack-prepared rings.
+ *
+ * *_gfn fields are allocated by the domain builder.
+ */
+xen_pfn_t console_gfn;
+xen_pfn_t xenstore_gfn;
+
+/*
  * initrd parameters as specified in start_info page
  * Depending on capabilities of the booted kernel this may be a virtual
  * address or a pfn. Type is neutral and large enough to hold a virtual
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index fce151d..2fe75cd 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -84,19 +84,19 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
 if ( rc < 0 )
 return rc;
 
-dom->console_pfn = base + CONSOLE_PFN_OFFSET;
-dom->xenstore_pfn = base + XENSTORE_PFN_OFFSET;
+dom->console_gfn = base + CONSOLE_PFN_OFFSET;
+dom->xenstore_gfn = base + XENSTORE_PFN_OFFSET;
 dom->vuart_gfn = base + VUART_PFN_OFFSET;
 
-xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_pfn);
-xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_pfn);
+xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_gfn);
+xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_gfn);
 xc_clear_domain_page(dom->xch, dom->guest_domid, base + 
MEMACCESS_PFN_OFFSET);
 xc_clear_domain_page(dom->xch, dom->guest_domid, dom->vuart_gfn);
 
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_PFN,
-dom->console_pfn);
+dom->console_gfn);
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_STORE_PFN,
-dom->xenstore_pfn);
+dom->xenstore_gfn);
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_MONITOR_RING_PFN,
 base + MEMACCESS_PFN_OFFSET);
 /* allocated by toolstack */
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 2e5681d..bbf98b6 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -257,24 +257,23 @@ static xen_pfn_t xc_dom_gnttab_setup(xc_interface *xch, 
uint32_t domid)
 }
 
 int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
-   xen_pfn_t console_gmfn,
-   xen_pfn_t xenstore_gmfn,
+   xen_pfn_t console_gfn,
+   xen_pfn_t xenstore_gfn,
uint32_t console_domid,
uint32_t xenstore_domid)
 {
-
-xen_pfn_t gnttab_gmfn;
+xen_pfn_t gnttab_gfn;
 grant_entry_v1_t *gnttab;
 
-gnttab_gmfn = xc_dom_gnttab_setup(xch, domid);
-if ( gnttab_gmfn == -1 )
+gnttab_gfn = xc_dom_gnttab_setup(xch, domid);
+if ( gnttab_gfn == -1 )
 return -1;
 
 gnttab = xc_map_foreign_range(xch,
   domid,
   PAGE_SIZE,
   PROT_READ|PROT_WRITE,
-  gnttab_gmfn);
+  gnttab_gfn);
 if ( gnttab == NULL )
 {
 xc_dom_panic(xch, XC_INTERNAL_ERROR,
@@ -284,17 +283,17 @@ int xc_dom_gnttab_seed(xc_interface *xch, uint32_t

Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure

2017-10-12 Thread Boris Ostrovsky 
On 10/06/2017 10:32 AM, Josh Poimboeuf wrote:
> On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote:
>>>  #ifdef CONFIG_PARAVIRT
>>> +/*
>>> + * Paravirt alternatives are applied much earlier than normal alternatives.
>>> + * They are only applied when running on a hypervisor.  They replace some
>>> + * native instructions with calls to pv ops.
>>> + */
>>> +void __init apply_pv_alternatives(void)
>>> +{
>>> +   setup_force_cpu_cap(X86_FEATURE_PV_OPS);
>> Not for Xen HVM guests.
> From what I can tell, HVM guests still use pv_time_ops and
> pv_mmu_ops.exit_mmap, right?
>
>>> +   apply_alternatives(__pv_alt_instructions, __pv_alt_instructions_end);
>>> +}
>>
>> This is a problem (at least for Xen PV guests):
>> apply_alternatives()->text_poke_early()->local_irq_save()->...'cli'->death.
> Ah, right.
>
>> It might be possible not to turn off/on the interrupts in this
>> particular case since the guest probably won't be able to handle an
>> interrupt at this point anyway.
> Yeah, that should work.  For Xen and for the other hypervisors, this is
> called well before irq init, so interrupts can't be handled yet anyway.

There is also another problem:

[1.312425] general protection fault:  [#1] SMP
[1.312901] Modules linked in:
[1.313389] CPU: 0 PID: 1 Comm: init Not tainted 4.14.0-rc4+ #6
[1.313878] task: 88003e2c task.stack: c938c000
[1.314360] RIP: 1e030:entry_SYSCALL_64_fastpath+0x1/0xa5
[1.314854] RSP: e02b:c938ff50 EFLAGS: 00010046
[1.315336] RAX: 000c RBX: 55f550168040 RCX:
7fcfc959f59a
[1.315827] RDX:  RSI:  RDI:

[1.316315] RBP: 000a R08: 037f R09:
0064
[1.316805] R10: 1f89cbf5 R11: 88003e2c R12:
7fcfc958ad60
[1.317300] R13:  R14: 55f550185954 R15:
1000
[1.317801] FS:  () GS:88003f80()
knlGS:
[1.318267] CS:  e033 DS:  ES:  CR0: 80050033
[1.318750] CR2: 7fcfc97ab218 CR3: 3c88e000 CR4:
00042660
[1.319235] Call Trace:
[1.319700] Code: 51 50 57 56 52 51 6a da 41 50 41 51 41 52 41 53 48
83 ec 30 65 4c 8b 1c 25 c0 d2 00 00 41 f7 03 df 39 08 90 0f 85 a5 00 00
00 50  15 9c 95 d0 ff 58 48 3d 4c 01 00 00 77 0f 4c 89 d1 ff 14 c5
[1.321161] RIP: entry_SYSCALL_64_fastpath+0x1/0xa5 RSP: c938ff50
[1.344255] ---[ end trace d7cb8cd6cd7c294c ]---
[1.345009] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b


All code

   0:51   push   %rcx
   1:50   push   %rax
   2:57   push   %rdi
   3:56   push   %rsi
   4:52   push   %rdx
   5:51   push   %rcx
   6:6a dapushq  $0xffda
   8:41 50push   %r8
   a:41 51push   %r9
   c:41 52push   %r10
   e:41 53push   %r11
  10:48 83 ec 30  sub$0x30,%rsp
  14:65 4c 8b 1c 25 c0 d2 mov%gs:0xd2c0,%r11
  1b:00 00
  1d:41 f7 03 df 39 08 90 testl  $0x900839df,(%r11)
  24:0f 85 a5 00 00 00jne0xcf
  2a:50   push   %rax
  2b:*ff 15 9c 95 d0 ffcallq  *-0x2f6a64(%rip)#
0xffd095cd<-- trapping instruction
  31:58   pop%rax
  32:48 3d 4c 01 00 00cmp$0x14c,%rax
  38:77 0fja 0x49
  3a:4c 89 d1 mov%r10,%rcx
  3d:ff   .byte 0xff
  3e:14 c5adc$0xc5,%al


so the original 'cli' was replaced with the pv call but to me the offset
looks a bit off, no? Shouldn't it always be positive?


-boris

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

Re: [Xen-devel] ARM32 - build-issues with xen/arm: vpl011: Add a new vuart node in the xenstore

2017-10-12 Thread Andrew Cooper 
On 12/10/17 19:54, Bhupinder Thakur wrote:
> On 5 October 2017 at 15:07, Wei Liu  wrote:
>> On Wed, Oct 04, 2017 at 09:58:32PM -0400, Konrad Rzeszutek Wilk wrote:
>>> I get this when compiling under ARM32 (Ubuntu 15.04,
>>> gcc (Ubuntu/Linaro 4.9.2-10ubuntu13) 4.9.2):
>>>
>>> libxl_console.c: In function ‘libxl__device_vuart_add’:
>>> libxl_console.c:379:5: error: format ‘%lu’ expects argument of type ‘long 
>>> unsigned int’, but argument 3 has type ‘xen_pfn_t’ [-Werror=format=]
>>>  flexarray_append(ro_front, GCSPRINTF("%lu", state->vuart_gfn));
>>>  ^
>>> ;
>> My Wheezy 32bit chroot didn't catch this, sigh.
>>
>> Does the following patch work?
>>
>> From ae531197382bf0bc003606a9712075bdd22cfc24 Mon Sep 17 00:00:00 2001
>> From: Wei Liu 
>> Date: Thu, 5 Oct 2017 10:35:28 +0100
>> Subject: [PATCH] libxl: use correct type modifier for vuart_gfn
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 8bit
>>
>> Fixes compilation error like:
>>
>> libxl_console.c: In function ‘libxl__device_vuart_add’:
>> libxl_console.c:379:5: error: format ‘%lu’ expects argument of type ‘long 
>> unsigned int’, but argument 3 has type ‘xen_pfn_t’ [-Werror=format=]
>>   flexarray_append(ro_front, GCSPRINTF("%lu", state->vuart_gfn));
>>
>> Reported-by: Konrad Rzeszutek Wilk 
>> Signed-off-by: Wei Liu 
>> ---
>>  tools/libxl/libxl_console.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
>> index 13ecf128e2..c05dc28b99 100644
>> --- a/tools/libxl/libxl_console.c
>> +++ b/tools/libxl/libxl_console.c
>> @@ -376,7 +376,7 @@ int libxl__device_vuart_add(libxl__gc *gc, uint32_t 
>> domid,
>>  flexarray_append(ro_front, "port");
>>  flexarray_append(ro_front, GCSPRINTF("%"PRIu32, state->vuart_port));
>>  flexarray_append(ro_front, "ring-ref");
>> -flexarray_append(ro_front, GCSPRINTF("%lu", state->vuart_gfn));
>> +flexarray_append(ro_front, GCSPRINTF("%"PRI_xen_pfn, state->vuart_gfn));
> Unfortunately, this is causing an issue as PRI_xen_pfn formats the
> value as a hexadecimal value but xenconsole later reads it as a
> decimal value and tries to map it, which fails and therefore vuart
> console initialization fails.
>
> Earlier, I verified only 32-bit compilation but did not test the
> change. It was a miss from my side. I have tested now with the format
> string changed to PRIu64 and the vuart console is working fine.

That however, would break x86.

andrewcoop@andrewcoop:/local/xen.git/xen$ git grep 'define PRI_xen_pfn' -- :/
include/public/arch-arm.h:276:#define PRI_xen_pfn PRIx64
include/public/arch-x86/xen.h:77:#define PRI_xen_pfn "lx"

The best way to fix this is to introduce a new define for both
architectures which is PRIu64 and "lu" as appropriate.

Suggestions:

PRI_xen_pfn_dec
PRIu_xen_pfn

Neither are great, but the latter does follow the PRI nomenclature.

~Andrew

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

Re: [Xen-devel] ARM32 - build-issues with xen/arm: vpl011: Add a new vuart node in the xenstore

2017-10-12 Thread Bhupinder Thakur 
On 5 October 2017 at 15:07, Wei Liu  wrote:
> On Wed, Oct 04, 2017 at 09:58:32PM -0400, Konrad Rzeszutek Wilk wrote:
>> I get this when compiling under ARM32 (Ubuntu 15.04,
>> gcc (Ubuntu/Linaro 4.9.2-10ubuntu13) 4.9.2):
>>
>> libxl_console.c: In function ‘libxl__device_vuart_add’:
>> libxl_console.c:379:5: error: format ‘%lu’ expects argument of type ‘long 
>> unsigned int’, but argument 3 has type ‘xen_pfn_t’ [-Werror=format=]
>>  flexarray_append(ro_front, GCSPRINTF("%lu", state->vuart_gfn));
>>  ^
>> ;
>
> My Wheezy 32bit chroot didn't catch this, sigh.
>
> Does the following patch work?
>
> From ae531197382bf0bc003606a9712075bdd22cfc24 Mon Sep 17 00:00:00 2001
> From: Wei Liu 
> Date: Thu, 5 Oct 2017 10:35:28 +0100
> Subject: [PATCH] libxl: use correct type modifier for vuart_gfn
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Fixes compilation error like:
>
> libxl_console.c: In function ‘libxl__device_vuart_add’:
> libxl_console.c:379:5: error: format ‘%lu’ expects argument of type ‘long 
> unsigned int’, but argument 3 has type ‘xen_pfn_t’ [-Werror=format=]
>   flexarray_append(ro_front, GCSPRINTF("%lu", state->vuart_gfn));
>
> Reported-by: Konrad Rzeszutek Wilk 
> Signed-off-by: Wei Liu 
> ---
>  tools/libxl/libxl_console.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
> index 13ecf128e2..c05dc28b99 100644
> --- a/tools/libxl/libxl_console.c
> +++ b/tools/libxl/libxl_console.c
> @@ -376,7 +376,7 @@ int libxl__device_vuart_add(libxl__gc *gc, uint32_t domid,
>  flexarray_append(ro_front, "port");
>  flexarray_append(ro_front, GCSPRINTF("%"PRIu32, state->vuart_port));
>  flexarray_append(ro_front, "ring-ref");
> -flexarray_append(ro_front, GCSPRINTF("%lu", state->vuart_gfn));
> +flexarray_append(ro_front, GCSPRINTF("%"PRI_xen_pfn, state->vuart_gfn));

Unfortunately, this is causing an issue as PRI_xen_pfn formats the
value as a hexadecimal value but xenconsole later reads it as a
decimal value and tries to map it, which fails and therefore vuart
console initialization fails.

Earlier, I verified only 32-bit compilation but did not test the
change. It was a miss from my side. I have tested now with the format
string changed to PRIu64 and the vuart console is working fine.

Regards,
Bhupinder

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

Re: [Xen-devel] preparations for 4.9.1 and 4.7.4

2017-10-12 Thread Christopher Clark 
On Fri, Oct 6, 2017 at 6:54 AM, Andrew Cooper  wrote:
> On 06/10/17 14:33, Jan Beulich wrote:
>> All,
>>
>> with the goal of releasing around the end of the month, please point
>> out backport candidates you find missing from the respective staging
>> branches, but which you consider relevant. Note that commits
>>
>> 1c2ea5ee05 x86/hvm/dmop: fix EFAULT condition
>> 4e383df865 x86/PV: fix/generalize guest nul selector handling
>
> dbc4b6e13a5 x86/msr: Correct the definition of MSR_IA32_APICBASE_BASE
> 3164f2f9db1 x86/svm: Fix a livelock when trying to run shadowed unpaged
> guests

88bfbf90e3 tools/libxc/xc_dom_arm: add missing variable initialization

thanks

Christopher

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

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

2017-10-12 Thread osstest service owner 
flight 114426 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114426/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-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  cc08c73c8c1f5ba5ed0f8274548db6725e1c3157
baseline version:
 xen  3b40cfcd1a1912c2e4c4eb353dc77cbf35c63c3a

Last test of basis   114299  2017-10-10 21:02:54 Z1 days
Failing since114308  2017-10-10 23:01:10 Z1 days   17 attempts
Testing same since   114421  2017-10-12 14:02:25 Z0 days2 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Andre Przywara 
  Andrew Cooper 
  Boris Ostrovsky 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Meng Xu 
  Ross Lagerwall 
  Stefano Stabellini 
  Tim Deegan 
  Vitaly Kuznetsov 
  Volodymyr Babchuk 
  Wei Liu 
  Yi Sun 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  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 :

+ branch=xen-unstable-smoke
+ revision=cc08c73c8c1f5ba5ed0f8274548db6725e1c3157
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.
 PERLLIB=.:.
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
cc08c73c8c1f5ba5ed0f8274548db6725e1c3157
+ branch=xen-unstable-smoke
+ revision=cc08c73c8c1f5ba5ed0f8274548db6725e1c3157
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.:.
 PERLLIB=.:.:.
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
+++ export PERLLIB=.:.:.:.
+++ PERLLIB=.:.:.:.
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.9-testing
+ '[' xcc08c73c8c1f5ba5ed0f8274548db6725e1c3157 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ :

Re: [Xen-devel] [Qemu-devel] [RFC QEMU PATCH v3 00/10] Implement vNVDIMM for Xen HVM guest

2017-10-12 Thread Konrad Rzeszutek Wilk 
On Thu, Oct 12, 2017 at 08:45:44PM +0800, Haozhong Zhang wrote:
> On 10/10/17 12:05 -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, Sep 12, 2017 at 11:15:09AM +0800, Haozhong Zhang wrote:
> > > On 09/11/17 11:52 -0700, Stefano Stabellini wrote:
> > > > CC'ing xen-devel, and the Xen tools and x86 maintainers.
> > > > 
> > > > On Mon, 11 Sep 2017, Igor Mammedov wrote:
> > > > > On Mon, 11 Sep 2017 12:41:47 +0800
> > > > > Haozhong Zhang  wrote:
> > > > > 
> > > > > > This is the QEMU part patches that works with the associated Xen
> > > > > > patches to enable vNVDIMM support for Xen HVM domains. Xen relies on
> > > > > > QEMU to build guest NFIT and NVDIMM namespace devices, and allocate
> > > > > > guest address space for vNVDIMM devices.
> > > > > > 
> > > > > > All patches can be found at
> > > > > >   Xen:  https://github.com/hzzhan9/xen.git nvdimm-rfc-v3
> > > > > >   QEMU: https://github.com/hzzhan9/qemu.git xen-nvdimm-rfc-v3
> > > > > > 
> > > > > > Patch 1 is to avoid dereferencing the NULL pointer to non-existing
> > > > > > label data, as the Xen side support for labels is not implemented 
> > > > > > yet.
> > > > > > 
> > > > > > Patch 2 & 3 add a memory backend dedicated for Xen usage and a 
> > > > > > hotplug
> > > > > > memory region for Xen guest, in order to make the existing nvdimm
> > > > > > device plugging path work on Xen.
> > > > > > 
> > > > > > Patch 4 - 10 build and cooy NFIT from QEMU to Xen guest, when QEMU 
> > > > > > is
> > > > > > used as the Xen device model.
> > > > > 
> > > > > I've skimmed over patch-set and can't say that I'm happy with
> > > > > number of xen_enabled() invariants it introduced as well as
> > > > > with partial blobs it creates.
> > > > 
> > > > I have not read the series (Haozhong, please CC me, Anthony and
> > > > xen-devel to the whole series next time), but yes, indeed. Let's not add
> > > > more xen_enabled() if possible.
> > > > 
> > > > Haozhong, was there a design document thread on xen-devel about this? If
> > > > so, did it reach a conclusion? Was the design accepted? If so, please
> > > > add a link to the design doc in the introductory email, so that
> > > > everybody can read it and be on the same page.
> > > 
> > > Yes, there is a design [1] discussed and reviewed. Section 4.3 discussed
> > > the guest ACPI.
> > > 
> > > [1] 
> > > https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg01921.html
> > 
> > Igor, did you have a chance to read it?
> > 
> > .. see below
> > > 
> > > > 
> > > > 
> > > > > I'd like to reduce above and a way to do this might be making xen 
> > > > >  1. use fw_cfg
> > > > >  2. fetch QEMU build acpi tables from fw_cfg
> > > > >  3. extract nvdim tables (which is trivial) and use them
> > > > > 
> > > > > looking at xen_load_linux(), it seems possible to use fw_cfg.
> > > > > 
> > > > > So what's stopping xen from using it elsewhere?,
> > > > > instead of adding more xen specific code to do 'the same'
> > > > > job and not reusing/sharing common code with tcg/kvm.
> > > > 
> > > > So far, ACPI tables have not been generated by QEMU. Xen HVM machines
> > > > rely on a firmware-like application called "hvmloader" that runs in
> > > > guest context and generates the ACPI tables. I have no opinions on
> > > > hvmloader and I'll let the Xen maintainers talk about it. However, keep
> > > > in mind that with an HVM guest some devices are emulated by Xen and/or
> > > > by other device emulators that can run alongside QEMU. QEMU doesn't have
> > > > a full few of the system.
> > > > 
> > > > Here the question is: does it have to be QEMU the one to generate the
> > > > ACPI blobs for the nvdimm? It would be nicer if it was up to hvmloader
> > > > like the rest, instead of introducing this split-brain design about
> > > > ACPI. We need to see a design doc to fully understand this.
> > > >
> > > 
> > > hvmloader runs in the guest and is responsible to build/load guest
> > > ACPI. However, it's not capable to build AML at runtime (for the lack
> > > of AML builder). If any guest ACPI object is needed (e.g. by guest
> > > DSDT), it has to be generated from ASL by iasl at Xen compile time and
> > > then be loaded by hvmloader at runtime.
> > > 
> > > Xen includes an OperationRegion "BIOS" in the static generated guest
> > > DSDT, whose address is hardcoded and which contains a list of values
> > > filled by hvmloader at runtime. Other ACPI objects can refer to those
> > > values (e.g., the number of vCPUs). But it's not enough for generating
> > > guest NVDIMM ACPI objects at compile time and then being customized
> > > and loaded by hvmload, because its structure (i.e., the number of
> > > namespace devices) cannot be decided util the guest config is known.
> > > 
> > > Alternatively, we may introduce an AML builder in hvmloader and build
> > > all guest ACPI completely in hvmloader. Looking at the similar
> > > implementation in QEMU, it would not be small, compared to the current
> > > size

Re: [Xen-devel] [PATCH v1] x86/hvm: Add MSR old value

2017-10-12 Thread Tamas K Lengyel 
On Thu, Oct 12, 2017 at 3:10 AM, Alexandru Isaila
 wrote:
> This patch adds the old value param and the onchangeonly option
> to the VM_EVENT_REASON_MOV_TO_MSR event.
>
> The param was added to the vm_event_mov_to_msr struct and to the
> hvm_monitor_msr function. Finally I've changed the bool_t param
> to a bool for the hvm_msr_write_intercept function.
>
> Signed-off-by: Alexandru Isaila 

Acked-by: Tamas K Lengyel 

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

Re: [Xen-devel] [PATCH 3/3 v4] xenfb: Add [feature|request]-raw-pointer

2017-10-12 Thread Stefano Stabellini 
On Thu, 12 Oct 2017, Paul Durrant wrote:
> > -Original Message-
> > From: Gerd Hoffmann [mailto:kra...@redhat.com]
> > Sent: 12 October 2017 10:26
> > To: Paul Durrant ; 'Stefano Stabellini'
> > ; Anthony Perard 
> > Cc: qemu-de...@nongnu.org; xen-de...@lists.xenproject.org; Owen Smith
> > 
> > Subject: Re: [Xen-devel] [PATCH 3/3 v4] xenfb: Add [feature|request]-raw-
> > pointer
> > 
> >   Hi,
> > 
> > > It's probably OS specific though. I guess the behaviour changed
> > > because the OS favours absolute pointing devices over relative ones
> > > and how it has two absolute ones to choose from. How it reconciles
> > > those, who knows?
> > 
> > Typically hid emulation calls qemu_input_handler_activate() when the
> > guest initializes the device, which moves the device to the top of the
> > priority list.
> > 
> > Visible effect on a typical guest with ps/2 mouse and usb-tablet is
> > that qemu switches from relative mode (mouse) to absolute mode (tablet)
> >  when the guest loads the usb hid driver.
> > 
> > I suspect pvmouse is doing the same thing.  So it may simply depend on
> > guest driver load order whenever pvmouse or usb-tablet is used.
> > 
> > Simplest fix is probably to only attach the device you plan to use to
> > the guest.  If you can't turn off pvmouse for xen guests then you might
> > want drop the qemu_input_handler_activate() call, so it behaves simliar
> > to the ps/2 mouse (is used in case no other pointer device is present).
> 
> Avoiding the activate call sounds reasonable and should avoid the behavioural 
> change.

+1

Owen, are you up for resubmitting the series with this small change?

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

Re: [Xen-devel] preparations for 4.9.1 and 4.7.4

2017-10-12 Thread Lars Kurth 
Hi all,

for 4.9.1 the XSA status is

XSA 226 : Some patches not applied => check
There is an extra chunk in the tree: see xsa226.png

XSA 227 : All patches found (no need to check)
XSA 228 : All patches found (no need to check)

XSA 229 : No patch found => check
Linux only => no issue

XSA 230 : All patches found (no need to check)
XSA 231 : All patches found (no need to check)
XSA 232 : All patches found (no need to check)
XSA 233 : All patches found (no need to check)
XSA 234 : All patches found (no need to check)
XSA 235 : All patches found (no need to check)

XSA 237 : No patch found => check
XSA 238 : No patch found => check
XSA 239 : No patch found => check
XSA 240 : No patch found => check
XSA 241 : No patch found => check
XSA 242 : No patch found => check
XSA 243 : No patch found => check
XSA 244 : No patch found => check
These have only been released today and have not yet been applied

XSA 245 : Some patches not applied => check
This is a minor change to a comment at check-in => no issue

For 4.7.4 the XSA status is

XSA 226 : Some patches not applied => check
There is an extra chunk in the tree: see xsa226.png

XSA 227 : All patches found (no need to check)
XSA 228 : All patches found (no need to check)

XSA 229 : No patch found => check
XSA 229 : No patch found => check
Linux only => no issue

XSA 230 : All patches found (no need to check)
XSA 231 : All patches found (no need to check)
XSA 232 : All patches found (no need to check)
XSA 233 : All patches found (no need to check)

XSA 234 : No patch found => check
ISSUE: This is genuinely missing (aka xsa234-4.8.patch)

XSA 235 : All patches found (no need to check)

XSA 237 : No patch found => check
XSA 238 : No patch found => check
XSA 239 : No patch found => check
XSA 240 : No patch found => check
XSA 241 : No patch found => check
XSA 242 : No patch found => check
XSA 243 : No patch found => check
XSA 244 : No patch found => check
These have only been released today and have not yet been applied

XSA 245 : Some patches not applied => check
This is missing 
xsa245/0002-xen-arm-Correctly-report-the-memory-region-in-the-du.patch

Best Regards
Lars

On 06/10/2017, 14:33, "Jan Beulich"  wrote:

All,

with the goal of releasing around the end of the month, please point
out backport candidates you find missing from the respective staging
branches, but which you consider relevant. Note that commits

1c2ea5ee05 x86/hvm/dmop: fix EFAULT condition
4e383df865 x86/PV: fix/generalize guest nul selector handling

are already on my list.

Jan



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

Re: [Xen-devel] [Xen-users] UEFI Secure Boot Xen 4.9

2017-10-12 Thread Bill Jacobs (billjac) 
Hi
What is the status of creating a shim to abstract secure boot signing for Xen 
(to leverage MSFT 3rd party, e.g)?
Thanks
-Bill

> -Original Message-
> From: Daniel Kiper [mailto:daniel.ki...@oracle.com]
> Sent: Tuesday, May 16, 2017 4:05 AM
> To: Bill Jacobs (billjac) 
> Cc: george.dun...@citrix.com; xen-devel@lists.xen.org; xen-
> us...@lists.xen.org
> Subject: Re: [Xen-users] UEFI Secure Boot Xen 4.9
> 
> On Mon, May 15, 2017 at 07:09:54PM +, Bill Jacobs (billjac) wrote:
> > > -Original Message-
> > > From: Daniel Kiper [mailto:daniel.ki...@oracle.com]
> > > Sent: Monday, May 15, 2017 6:13 AM
> > > To: Bill Jacobs (billjac) ;
> > > george.dun...@citrix.com
> > > Cc: xen-devel@lists.xen.org; xen-us...@lists.xen.org
> > > Subject: Re: [Xen-users] UEFI Secure Boot Xen 4.9
> > >
> > > Hey,
> > >
> > > CC-ing Xen-devel to spread some knowledge about the issue.
> > >
> > > On Mon, May 15, 2017 at 10:42:23AM +0100, George Dunlap wrote:
> > > > On Wed, May 10, 2017 at 11:36 PM, Bill Jacobs (billjac)
> > > >  wrote:
> > > > > Hi all
> > > > >
> > > > > I gather that with 4.9, UEFI secure boot of Xen should be possible.
> > > > >
> > > > > Is this true?
> > > > >
> > > > > If so, what are the options for utilizing UEFI secure boot? Do I
> > > > > need a MSFT-signed shim or grub? Any special changes required
> > > > > for Xen kernel
> > > > > (signing?) or has that been done?
> > > >
> > > > Bill,
> > > >
> > > > I guess in part it depends on what you mean by "utilizing UEFI
> > > > secure boot".  If you simply want to boot an unsigned Xen on a
> > > > UEFI system with SecureBoot enabled, then grub would probably
> > > > work.  If you want to actually do the full SecureBoot thing --
> > > > where you have grub check Xen's signature and that of the kernel
> > > > and initrd, you probably need a bit more.
> > > >
> > > > Daniel,
> > > >
> > > > Is there any good documentation on this?  The Xen EFI guide
> > > > (https://wiki.xenproject.org/wiki/Xen_EFI) mentions the shim, but
> > > > doesn't go into detail about how to sign a binary 
> > >
> > > Unfortunately I do not know anything like that. As you said in
> > > general shim is supported. Sadly, it works only if you load xen.efi 
> > > directly
> from EFI.
> > > __Upstream__ GRUB2 has not have support for shim yet. I am working
> > > on it (shim support via GRUB2 requires also some changes in Xen). I
> > > hope that I will have something which works before Xen conf in Budapest.
> > >
> > > If you wish to use shim with xen.efi then you have to sign xen.efi
> > > and vmlinux with your key using sbsign or pesign. The process works
> > > in the same way like in case vmlinux alone. Of course you have to
> > > install your public key into MOK before enabling secure boot.
> > >
> > > Daniel
> >
> > Yes, there are options in how this is achievable, and the solutions may be
> different.
> >
> > We are targeting a secure boot chain from UEFI fw to .ko, using same 
> > signing.
> > In our case would skip shim and reduce attack surface, but it appears
> > that the mechanisms 'out there' for passing pub key (cert) from UEFI
> > db to Linux chainring require shim to do the work. Is that accurate? Does it
> have to be the case? I don't see why.
> 
> AIUI, if EFI secure boot is enabled then EFI verifies signatures of every
> loaded/executed PE file. Unfortunately, you are not able to use secure boot
> protocol directly to verify yourself PE's loaded from your app. So, this is 
> one of
> reasons why shim was introduced. It exposes protocol which can be used by
> you to do verification.
> 
> > For us, ideal case is :
> > UEFI fw -> (signed)GRUB2.efi->Multiboot2->Xen(signed .ko)
> 
> AFAICT, it is not possible. We should do following thing:
> 
>   UEFI -> shim -> GRUB2 -> Multiboot2 -> Xen/Linux/etc.
> 
> UEFI will verify shim secure boot signature then shim will verify GRUB2
> signature then GRUB2 will verify (with shim protocol) Xen signature and 
> finally
> Xen will verify (with shim protocol) Linux kernel signature. Then your kernel
> can verify modules using whatever you want.
> 
> > I would be happy to work to help achieve this.
> 
> There is a chance that I will have something very raw at the beginning of 
> June.
> If you wish to do tests drop me a line.
> 
> Daniel

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

Re: [Xen-devel] [RFC v2 7/7] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

2017-10-12 Thread Julien Grall 

Hi Sameer,

Given this is all Arm specific. I am not sure why people like Andrew, 
Jan have been added.


Please use scripts/get_maintainers to find the list of maintainers per 
patches and avoid to CC all of them on each patches.


On 21/09/17 01:37, Sameer Goel wrote:

This driver follows an approach similar to smmu driver. The intent here
is to reuse as much Linux code as possible.
- Glue code has been introduced to bridge the API calls.
- Called Linux functions from the Xen IOMMU function calls.
- Xen modifications are preceded by /*Xen: comment */

Signed-off-by: Sameer Goel 
---
  xen/drivers/passthrough/arm/Makefile  |   1 +
  xen/drivers/passthrough/arm/smmu-v3.c | 853 +-


This is based on an old SMMUv3 version and I have been told there are 
some changes may benefits Xen (such as increasing the timeout for sync) 
and some optimisations also exist on the ML and will be queued soon.


So maybe you want to re-sync at least to master.


  2 files changed, 738 insertions(+), 116 deletions(-)

diff --git a/xen/drivers/passthrough/arm/Makefile 
b/xen/drivers/passthrough/arm/Makefile
index f4cd26e..57a6da6 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,2 +1,3 @@
  obj-y += iommu.o
  obj-y += smmu.o
+obj-y += smmu-v3.o


Do we want SMMUv3 to be built on Arm32? Maybe we should introduce a new 
Kconfig to let the user select.



diff --git a/xen/drivers/passthrough/arm/smmu-v3.c 
b/xen/drivers/passthrough/arm/smmu-v3.c
index 380969a..8f3b43d 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -18,28 +18,266 @@
   * Author: Will Deacon 
   *
   * This driver is powered by bad coffee and bombay mix.
+ *
+ *
+ * Based on Linux drivers/iommu/arm-smmu-v3.c
+ * => commit bdf95923086fb359ccb44c815724c3ace1611c90
+ *
+ * Xen modifications:
+ * Sameer Goel 
+ * Copyright (C) 2017, The Linux Foundation, All rights reserved.
+ *
   */
  
-#include 

-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-#include "io-pgtable.h"
+#include 


This is not necessary.


+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 


Please order the includes alphabetically with xen/* first then asm/*


+
+typedef paddr_t phys_addr_t;
+typedef paddr_t dma_addr_t;
+
+/* Alias to Xen device tree helpers */
+#define device_node dt_device_node
+#define of_phandle_args dt_phandle_args
+#define of_device_id dt_device_match
+#define of_match_node dt_match_node
+#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, pname, 
out))
+#define of_property_read_bool dt_property_read_bool
+#define of_parse_phandle_with_args dt_parse_phandle_with_args
+#define mutex spinlock_t
+#define mutex_init spin_lock_init
+#define mutex_lock spin_lock
+#define mutex_unlock spin_unlock


mutex and spinlock are not the same. The former is sleeping whilst the 
later is not.


Can you please explain why this is fine and possibly add that in a comment?


+
+/* Xen: Helpers to get device MMIO and IRQs */
+struct resource {
+   u64 addr;
+   u64 size;
+   unsigned int type;
+};


Likely we want a compat header for defining Linux helpers. This would 
avoid replicating it everywhere.



+
+#define resource_size(res) ((res)->size)
+
+#define platform_device device
+
+#define IORESOURCE_MEM 0
+#define IORESOURCE_IRQ 1
+
+static struct resource *platform_get_resource(struct platform_device *pdev,
+ unsigned int type,
+ unsigned int num)
+{
+   /*
+* The resource is only used between 2 calls of platform_get_resource.
+* It's quite ugly but it's avoid to add too much code in the part
+* imported from Linux
+*/
+   static struct resource res;
+   struct acpi_iort_node *iort_node;
+   struct acpi_iort_smmu_v3 *node_smmu_data;
+   int ret = 0;
+
+   res.type = type;
+
+   switch (type) {
+   case IORESOURCE_MEM:
+   if (pdev->type == DEV_ACPI) {
+   ret = 1;
+   iort_node = pdev->acpi_node;
+   node_smmu_data =
+   (struct acpi_iort_smmu_v3 
*)iort_node->node_data;
+
+   if (node_smmu_data != NULL) {
+   res.addr = node_smmu_data->base_address;
+   res.size = SZ_128K;
+   ret = 0;
+   }
+   } else {
+   ret = dt_device_get_address(dev_to_dt(pdev), num,
+   , );
+

Re: [Xen-devel] [PATCH v1 00/27] x86: PIE support and option to extend KASLR randomization

2017-10-12 Thread Tom Lendacky 

On 10/12/2017 10:34 AM, Thomas Garnier wrote:

On Wed, Oct 11, 2017 at 2:34 PM, Tom Lendacky  wrote:

On 10/11/2017 3:30 PM, Thomas Garnier wrote:

Changes:
   - patch v1:
 - Simplify ftrace implementation.
 - Use gcc mstack-protector-guard-reg=%gs with PIE when possible.
   - rfc v3:
 - Use --emit-relocs instead of -pie to reduce dynamic relocation space on
   mapped memory. It also simplifies the relocation process.
 - Move the start the module section next to the kernel. Remove the need for
   -mcmodel=large on modules. Extends module space from 1 to 2G maximum.
 - Support for XEN PVH as 32-bit relocations can be ignored with
   --emit-relocs.
 - Support for GOT relocations previously done automatically with -pie.
 - Remove need for dynamic PLT in modules.
 - Support dymamic GOT for modules.
   - rfc v2:
 - Add support for global stack cookie while compiler default to fs without
   mcmodel=kernel
 - Change patch 7 to correctly jump out of the identity mapping on kexec 
load
   preserve.

These patches make the changes necessary to build the kernel as Position
Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below
the top 2G of the virtual address space. It allows to optionally extend the
KASLR randomization range from 1G to 3G.


Hi Thomas,

I've applied your patches so that I can verify that SME works with PIE.
Unfortunately, I'm running into build warnings and errors when I enable
PIE.

With CONFIG_STACK_VALIDATION=y I receive lots of messages like this:

   drivers/scsi/libfc/fc_exch.o: warning: objtool: fc_destroy_exch_mgr()+0x0: 
call without frame pointer save/setup

Disabling CONFIG_STACK_VALIDATION suppresses those.


I ran into that, I plan to fix it in the next iteration.



But near the end of the build, I receive errors like this:

   arch/x86/kernel/setup.o: In function `dump_kernel_offset':
   .../arch/x86/kernel/setup.c:801:(.text+0x32): relocation truncated to fit: 
R_X86_64_32S against symbol `_text' defined in .text section in .tmp_vmlinux1
   .
   . about 10 more of the above type messages
   .
   make: *** [vmlinux] Error 1
   Error building kernel, exiting

Are there any config options that should or should not be enabled when
building with PIE enabled?  Is there a compiler requirement for PIE (I'm
using gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5))?


I never ran into these ones and I tested compilers older and newer.
What was your exact configuration?


I'll send you the config in a separate email.

Thanks,
Tom





Thanks,
Tom



Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler
changes, PIE support and KASLR in general. Thanks to Roland McGrath on his
feedback for using -pie versus --emit-relocs and details on compiler code
generation.

The patches:
   - 1-3, 5-1#, 17-18: Change in assembly code to be PIE compliant.
   - 4: Add a new _ASM_GET_PTR macro to fetch a symbol address generically.
   - 14: Adapt percpu design to work correctly when PIE is enabled.
   - 15: Provide an option to default visibility to hidden except for key 
symbols.
 It removes errors between compilation units.
   - 16: Adapt relocation tool to handle PIE binary correctly.
   - 19: Add support for global cookie.
   - 20: Support ftrace with PIE (used on Ubuntu config).
   - 21: Fix incorrect address marker on dump_pagetables.
   - 22: Add option to move the module section just after the kernel.
   - 23: Adapt module loading to support PIE with dynamic GOT.
   - 24: Make the GOT read-only.
   - 25: Add the CONFIG_X86_PIE option (off by default).
   - 26: Adapt relocation tool to generate a 64-bit relocation table.
   - 27: Add the CONFIG_RANDOMIZE_BASE_LARGE option to increase relocation range
 from 1G to 3G (off by default).

Performance/Size impact:

Size of vmlinux (Default configuration):
   File size:
   - PIE disabled: +0.31%
   - PIE enabled: -3.210% (less relocations)
   .text section:
   - PIE disabled: +0.000644%
   - PIE enabled: +0.837%

Size of vmlinux (Ubuntu configuration):
   File size:
   - PIE disabled: -0.201%
   - PIE enabled: -0.082%
   .text section:
   - PIE disabled: same
   - PIE enabled: +1.319%

Size of vmlinux (Default configuration + ORC):
   File size:
   - PIE enabled: -3.167%
   .text section:
   - PIE enabled: +0.814%

Size of vmlinux (Ubuntu configuration + ORC):
   File size:
   - PIE enabled: -3.167%
   .text section:
   - PIE enabled: +1.26%

The size increase is mainly due to not having access to the 32-bit signed
relocation that can be used with mcmodel=kernel. A small part is due to reduced
optimization for PIE code. This bug [1] was opened with gcc to provide a better
code generation for kernel PIE.

Hackbench (50% and 1600% on thread/process for pipe/sockets):
   - PIE disabled: no significant change (avg +0.1% on latest test).
   - PIE enabled: between -0.50% to +0.86% in average (default and Ubuntu

[Xen-devel] [PATCH v11 11/11] tools/libxenctrl: use new xenforeignmemory API to seed grant table

2017-10-12 Thread Paul Durrant 
A previous patch added support for priv-mapping guest resources directly
(rather than having to foreign-map, which requires P2M modification for
HVM guests).

This patch makes use of the new API to seed the guest grant table unless
the underlying infrastructure (i.e. privcmd) doesn't support it, in which
case the old scheme is used.

NOTE: The call to xc_dom_gnttab_hvm_seed() in hvm_build_set_params() was
  actually unnecessary, as the grant table has already been seeded
  by a prior call to xc_dom_gnttab_init() made by libxl__build_dom().

Signed-off-by: Paul Durrant 
Acked-by: Marek Marczykowski-Górecki 
Reviewed-by: Roger Pau Monné 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 

v10:
 - Use new id constant for grant table.

v4:
 - Minor cosmetic fix suggested by Roger.

v3:
 - Introduced xc_dom_set_gnttab_entry() to avoid duplicated code.
---
 tools/libxc/include/xc_dom.h|   8 +--
 tools/libxc/xc_dom_boot.c   | 114 +---
 tools/libxc/xc_sr_restore_x86_hvm.c |  10 ++--
 tools/libxc/xc_sr_restore_x86_pv.c  |   2 +-
 tools/libxl/libxl_dom.c |   1 -
 tools/python/xen/lowlevel/xc/xc.c   |   6 +-
 6 files changed, 92 insertions(+), 49 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 6e06ef1dec..4216d63462 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -325,12 +325,8 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, 
xen_pfn_t pfn,
 int xc_dom_boot_image(struct xc_dom_image *dom);
 int xc_dom_compat_check(struct xc_dom_image *dom);
 int xc_dom_gnttab_init(struct xc_dom_image *dom);
-int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
-   xen_pfn_t console_gmfn,
-   xen_pfn_t xenstore_gmfn,
-   domid_t console_domid,
-   domid_t xenstore_domid);
-int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
+int xc_dom_gnttab_seed(xc_interface *xch, domid_t guest_domid,
+   bool is_hvm,
xen_pfn_t console_gmfn,
xen_pfn_t xenstore_gmfn,
domid_t console_domid,
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 8a376d097c..0fe94aa255 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -282,11 +282,29 @@ static xen_pfn_t xc_dom_gnttab_setup(xc_interface *xch, 
domid_t domid)
 return gmfn;
 }
 
-int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
-   xen_pfn_t console_gmfn,
-   xen_pfn_t xenstore_gmfn,
-   domid_t console_domid,
-   domid_t xenstore_domid)
+static void xc_dom_set_gnttab_entry(xc_interface *xch,
+grant_entry_v1_t *gnttab,
+unsigned int idx,
+domid_t guest_domid,
+domid_t backend_domid,
+xen_pfn_t backend_gmfn)
+{
+if ( guest_domid == backend_domid || backend_gmfn == -1)
+return;
+
+xc_dom_printf(xch, "%s: [%u] -> 0x%"PRI_xen_pfn,
+  __FUNCTION__, idx, backend_gmfn);
+
+gnttab[idx].flags = GTF_permit_access;
+gnttab[idx].domid = backend_domid;
+gnttab[idx].frame = backend_gmfn;
+}
+
+static int compat_gnttab_seed(xc_interface *xch, domid_t domid,
+  xen_pfn_t console_gmfn,
+  xen_pfn_t xenstore_gmfn,
+  domid_t console_domid,
+  domid_t xenstore_domid)
 {
 
 xen_pfn_t gnttab_gmfn;
@@ -310,18 +328,10 @@ int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
 return -1;
 }
 
-if ( domid != console_domid  && console_gmfn != -1)
-{
-gnttab[GNTTAB_RESERVED_CONSOLE].flags = GTF_permit_access;
-gnttab[GNTTAB_RESERVED_CONSOLE].domid = console_domid;
-gnttab[GNTTAB_RESERVED_CONSOLE].frame = console_gmfn;
-}
-if ( domid != xenstore_domid && xenstore_gmfn != -1)
-{
-gnttab[GNTTAB_RESERVED_XENSTORE].flags = GTF_permit_access;
-gnttab[GNTTAB_RESERVED_XENSTORE].domid = xenstore_domid;
-gnttab[GNTTAB_RESERVED_XENSTORE].frame = xenstore_gmfn;
-}
+xc_dom_set_gnttab_entry(xch, gnttab, GNTTAB_RESERVED_CONSOLE,
+domid, console_domid, console_gmfn);
+xc_dom_set_gnttab_entry(xch, gnttab, GNTTAB_RESERVED_XENSTORE,
+domid, xenstore_domid, xenstore_gmfn);
 
 if ( munmap(gnttab, PAGE_SIZE) == -1 )
 {
@@ -339,11 +349,11 @@ int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
 return 0;
 }
 
-int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t

[Xen-devel] [PATCH v11 10/11] common: add a new mappable resource type: XENMEM_resource_grant_table

2017-10-12 Thread Paul Durrant 
This patch allows grant table frames to be mapped using the
XENMEM_acquire_resource memory op.

Signed-off-by: Paul Durrant 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 

v10:
 - Addressed comments from Jan.

v8:
 - The functionality was originally incorporated into the earlier patch
   "x86/mm: add HYPERVISOR_memory_op to acquire guest resources".
---
 xen/common/grant_table.c  | 63 ++-
 xen/common/memory.c   | 44 +-
 xen/include/public/memory.h   |  6 +
 xen/include/xen/grant_table.h |  4 +++
 4 files changed, 110 insertions(+), 7 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 6d20b17739..e42c1b6bf3 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1608,7 +1608,8 @@ fault:
 }
 
 static int
-gnttab_populate_status_frames(struct domain *d, struct grant_table *gt,
+gnttab_populate_status_frames(struct domain *d,
+  struct grant_table *gt,
   unsigned int req_nr_frames)
 {
 unsigned i;
@@ -3756,13 +3757,12 @@ int mem_sharing_gref_to_gfn(struct grant_table *gt, 
grant_ref_t ref,
 }
 #endif
 
-int gnttab_map_frame(struct domain *d, unsigned long idx, gfn_t gfn,
- mfn_t *mfn)
+/* Caller must hold write lock as version may change and table may grow */
+static int gnttab_get_frame(struct domain *d, unsigned long idx,
+mfn_t *mfn)
 {
-int rc = 0;
 struct grant_table *gt = d->grant_table;
-
-grant_write_lock(gt);
+int rc = 0;
 
 if ( gt->gt_version == 0 )
 gt->gt_version = 1;
@@ -3787,6 +3787,19 @@ int gnttab_map_frame(struct domain *d, unsigned long 
idx, gfn_t gfn,
 rc = -EINVAL;
 }
 
+return rc;
+}
+
+int gnttab_map_frame(struct domain *d, unsigned long idx, gfn_t gfn,
+ mfn_t *mfn)
+{
+struct grant_table *gt = d->grant_table;
+int rc;
+
+grant_write_lock(gt);
+
+rc = gnttab_get_frame(d, idx, mfn);
+
 if ( !rc )
 gnttab_set_frame_gfn(gt, idx, gfn);
 
@@ -3795,6 +3808,44 @@ int gnttab_map_frame(struct domain *d, unsigned long 
idx, gfn_t gfn,
 return rc;
 }
 
+int gnttab_get_grant_frame(struct domain *d, unsigned long idx,
+   mfn_t *mfn)
+{
+struct grant_table *gt = d->grant_table;
+int rc;
+
+/* write lock required as version may change and/or table may grow */
+grant_write_lock(gt);
+
+rc = (gt->gt_version == 2 &&
+  idx > XENMAPIDX_grant_table_status) ?
+-EINVAL :
+gnttab_get_frame(d, idx, mfn);
+
+grant_write_unlock(gt);
+
+return rc;
+}
+
+int gnttab_get_status_frame(struct domain *d, unsigned long idx,
+mfn_t *mfn)
+{
+struct grant_table *gt = d->grant_table;
+int rc;
+
+/* write lock required as version may change and/or table may grow */
+grant_write_lock(gt);
+
+rc = (gt->gt_version != 2 ||
+  idx > XENMAPIDX_grant_table_status) ?
+-EINVAL :
+gnttab_get_frame(d, idx & XENMAPIDX_grant_table_status, mfn);
+
+grant_write_unlock(gt);
+
+return rc;
+}
+
 static void gnttab_usage_print(struct domain *rd)
 {
 int first = 1;
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 1a9872b75c..a50d93d006 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -965,11 +966,47 @@ static long xatp_permission_check(struct domain *d, 
unsigned int space)
 return xsm_add_to_physmap(XSM_TARGET, current->domain, d);
 }
 
+static int acquire_grant_table(struct domain *d, unsigned int id,
+   unsigned long frame,
+   unsigned int nr_frames,
+   unsigned long mfn_list[])
+{
+unsigned int i = nr_frames;
+
+while ( i-- != 0 )
+{
+mfn_t mfn = INVALID_MFN;
+int rc;
+
+switch ( id )
+{
+case XENMEM_resource_grant_table_id_grant:
+rc = gnttab_get_grant_frame(d, frame + i, );
+break;
+
+case XENMEM_resource_grant_table_id_status:
+rc = gnttab_get_status_frame(d, frame + i, );
+break;
+
+default:
+rc = -EINVAL;
+break;
+}
+
+if ( rc )
+return rc;
+
+mfn_list[i] = mfn_x(mfn);
+}
+
+return 0;
+}
+
 static int acquire_resource(XEN_GUEST_HANDLE_PARAM(void) arg)
 {
 struct domain *d, *currd = current->domain;
 xen_mem_acquire_resource_t

[Xen-devel] [PATCH v11 01/11] x86/hvm/ioreq: maintain an array of ioreq servers rather than a list

2017-10-12 Thread Paul Durrant 
A subsequent patch will remove the current implicit limitation on creation
of ioreq servers which is due to the allocation of gfns for the ioreq
structures and buffered ioreq ring.

It will therefore be necessary to introduce an explicit limit and, since
this limit should be small, it simplifies the code to maintain an array of
that size rather than using a list.

Also, by reserving an array slot for the default server and populating
array slots early in create, the need to pass an 'is_default' boolean
to sub-functions can be avoided.

Some function return values are changed by this patch: Specifically, in
the case where the id of the default ioreq server is passed in, -EOPNOTSUPP
is now returned rather than -ENOENT.

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
Reviewed-by: Jan Beulich 
---
Cc: Andrew Cooper 

v10:
 - modified FOR_EACH... macro as suggested by Jan.
 - check for NULL in IS_DEFAULT macro as suggested by Jan.

v9:
 - modified FOR_EACH... macro as requested by Andrew.

v8:
 - Addressed various comments from Jan.

v7:
 - Fixed assertion failure found in testing.

v6:
 - Updated according to comments made by Roger on v4 that I'd missed.

v5:
 - Switched GET/SET_IOREQ_SERVER() macros to get/set_ioreq_server()
   functions to avoid possible double-evaluation issues.

v4:
 - Introduced more helper macros and relocated them to the top of the
   code.

v3:
 - New patch (replacing "move is_default into struct hvm_ioreq_server") in
   response to review comments.
---
 xen/arch/x86/hvm/ioreq.c | 502 +++
 xen/include/asm-x86/hvm/domain.h |  10 +-
 2 files changed, 245 insertions(+), 267 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index f2e0b3f74a..e6ccc7572a 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -33,6 +33,37 @@
 
 #include 
 
+static void set_ioreq_server(struct domain *d, unsigned int id,
+ struct hvm_ioreq_server *s)
+{
+ASSERT(id < MAX_NR_IOREQ_SERVERS);
+ASSERT(!s || !d->arch.hvm_domain.ioreq_server.server[id]);
+
+d->arch.hvm_domain.ioreq_server.server[id] = s;
+}
+
+#define GET_IOREQ_SERVER(d, id) \
+(d)->arch.hvm_domain.ioreq_server.server[id]
+
+static struct hvm_ioreq_server *get_ioreq_server(const struct domain *d,
+ unsigned int id)
+{
+if ( id >= MAX_NR_IOREQ_SERVERS )
+return NULL;
+
+return GET_IOREQ_SERVER(d, id);
+}
+
+#define IS_DEFAULT(s) \
+((s) && (s) == GET_IOREQ_SERVER((s)->domain, DEFAULT_IOSERVID))
+
+/* Iterate over all possible ioreq servers */
+#define FOR_EACH_IOREQ_SERVER(d, id, s) \
+for ( (id) = 0; (id) < MAX_NR_IOREQ_SERVERS; (id)++ ) \
+if ( !(s = GET_IOREQ_SERVER(d, id)) ) \
+continue; \
+else
+
 static ioreq_t *get_ioreq(struct hvm_ioreq_server *s, struct vcpu *v)
 {
 shared_iopage_t *p = s->ioreq.va;
@@ -47,10 +78,9 @@ bool hvm_io_pending(struct vcpu *v)
 {
 struct domain *d = v->domain;
 struct hvm_ioreq_server *s;
+unsigned int id;
 
-list_for_each_entry ( s,
-  >arch.hvm_domain.ioreq_server.list,
-  list_entry )
+FOR_EACH_IOREQ_SERVER(d, id, s)
 {
 struct hvm_ioreq_vcpu *sv;
 
@@ -127,10 +157,9 @@ bool handle_hvm_io_completion(struct vcpu *v)
 struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
 struct hvm_ioreq_server *s;
 enum hvm_io_completion io_completion;
+unsigned int id;
 
-  list_for_each_entry ( s,
-  >arch.hvm_domain.ioreq_server.list,
-  list_entry )
+FOR_EACH_IOREQ_SERVER(d, id, s)
 {
 struct hvm_ioreq_vcpu *sv;
 
@@ -243,13 +272,12 @@ static int hvm_map_ioreq_page(
 bool is_ioreq_server_page(struct domain *d, const struct page_info *page)
 {
 const struct hvm_ioreq_server *s;
+unsigned int id;
 bool found = false;
 
 spin_lock_recursive(>arch.hvm_domain.ioreq_server.lock);
 
-list_for_each_entry ( s,
-  >arch.hvm_domain.ioreq_server.list,
-  list_entry )
+FOR_EACH_IOREQ_SERVER(d, id, s)
 {
 if ( (s->ioreq.va && s->ioreq.page == page) ||
  (s->bufioreq.va && s->bufioreq.page == page) )
@@ -302,7 +330,7 @@ static void hvm_update_ioreq_evtchn(struct hvm_ioreq_server 
*s,
 }
 
 static int hvm_ioreq_server_add_vcpu(struct hvm_ioreq_server *s,
- bool is_default, struct vcpu *v)
+ struct vcpu *v)
 {
 struct hvm_ioreq_vcpu *sv;
 int rc;
@@ -331,7 +359,7 @@ static int hvm_ioreq_server_add_vcpu(struct 
hvm_ioreq_server *s,
 goto fail3;
 
 s->bufioreq_evtchn = rc;
-if ( is_default )
+if ( IS_DEFAULT(s) )

[Xen-devel] [PATCH v11 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

2017-10-12 Thread Paul Durrant 
Certain memory resources associated with a guest are not necessarily
present in the guest P2M.

This patch adds the boilerplate for new memory op to allow such a resource
to be priv-mapped directly, by either a PV or HVM tools domain.

NOTE: Whilst the new op is not intrinsicly specific to the x86 architecture,
  I have no means to test it on an ARM platform and so cannot verify
  that it functions correctly. Hence it is currently only implemented
  for x86.

Signed-off-by: Paul Durrant 
---
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 

v11:
 - Addressed more comments from Jan.

v9:
 - Addressed more comments from Jan.

v8:
 - Move the code into common as requested by Jan.
 - Make the gmfn_list handle a 64-bit type to avoid limiting the MFN
   range for a 32-bit tools domain.
 - Add missing pad.
 - Add compat code.
 - Make this patch deal with purely boilerplate.
 - Drop George's A-b and Wei's R-b because the changes are non-trivial,
   and update Cc list now the boilerplate is common.

v5:
 - Switched __copy_to/from_guest_offset() to copy_to/from_guest_offset().
---
 tools/flask/policy/modules/xen.if   |   4 +-
 xen/arch/x86/mm/p2m.c   |   3 +-
 xen/common/compat/memory.c  | 145 ++--
 xen/common/memory.c |  90 ++
 xen/include/asm-x86/p2m.h   |   3 +
 xen/include/public/memory.h |  43 ++-
 xen/include/xlat.lst|   1 +
 xen/include/xsm/dummy.h |   6 ++
 xen/include/xsm/xsm.h   |   6 ++
 xen/xsm/dummy.c |   1 +
 xen/xsm/flask/hooks.c   |   6 ++
 xen/xsm/flask/policy/access_vectors |   2 +
 12 files changed, 300 insertions(+), 10 deletions(-)

diff --git a/tools/flask/policy/modules/xen.if 
b/tools/flask/policy/modules/xen.if
index 55437496f6..07cba8a15d 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -52,7 +52,8 @@ define(`create_domain_common', `
settime setdomainhandle getvcpucontext set_misc_info };
allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
-   psr_cmt_op psr_cat_op soft_reset set_gnttab_limits };
+   psr_cmt_op psr_cat_op soft_reset set_gnttab_limits
+   resource_map };
allow $1 $2:security check_context;
allow $1 $2:shadow enable;
allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage 
mmuext_op updatemp };
@@ -152,6 +153,7 @@ define(`device_model', `
allow $1 $2_target:domain { getdomaininfo shutdown };
allow $1 $2_target:mmu { map_read map_write adjust physmap target_hack 
};
allow $1 $2_target:hvm { getparam setparam hvmctl cacheattr dm };
+   allow $1 $2_target:domain2 resource_map;
 ')
 
 # make_device_model(priv, dm_dom, hvm_dom)
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index c72a3cdebb..71bb9b4f93 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1132,8 +1132,7 @@ static int set_typed_p2m_entry(struct domain *d, unsigned 
long gfn_l,
 }
 
 /* Set foreign mfn in the given guest's p2m table. */
-static int set_foreign_p2m_entry(struct domain *d, unsigned long gfn,
- mfn_t mfn)
+int set_foreign_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn)
 {
 return set_typed_p2m_entry(d, gfn, mfn, PAGE_ORDER_4K, p2m_map_foreign,
p2m_get_hostp2m(d)->default_access);
diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index 35bb259808..031d1a48ae 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -71,6 +71,7 @@ int compat_memory_op(unsigned int cmd, 
XEN_GUEST_HANDLE_PARAM(void) compat)
 struct xen_remove_from_physmap *xrfp;
 struct xen_vnuma_topology_info *vnuma;
 struct xen_mem_access_op *mao;
+struct xen_mem_acquire_resource *mar;
 } nat;
 union {
 struct compat_memory_reservation rsrv;
@@ -79,6 +80,7 @@ int compat_memory_op(unsigned int cmd, 
XEN_GUEST_HANDLE_PARAM(void) compat)
 struct compat_add_to_physmap_batch atpb;
 struct compat_vnuma_topology_info vnuma;
 struct compat_mem_access_op mao;
+struct compat_mem_acquire_resource mar;
 } cmp;
 
 set_xen_guest_handle(nat.hnd, COMPAT_ARG_XLAT_VIRT_BASE);
@@ -395,6 +397,71 @@ int compat_memory_op(unsigned int cmd,

[Xen-devel] [PATCH v11 02/11] x86/hvm/ioreq: simplify code and use consistent naming

2017-10-12 Thread Paul Durrant 
This patch re-works much of the ioreq server initialization and teardown
code:

- The hvm_map/unmap_ioreq_gfn() functions are expanded to call through
  to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called
  separately by outer functions.
- Several functions now test the validity of the hvm_ioreq_page gfn value
  to determine whether they need to act. This means can be safely called
  for the bufioreq page even when it is not used.
- hvm_add/remove_ioreq_gfn() simply return in the case of the default
  IOREQ server so callers no longer need to test before calling.
- hvm_ioreq_server_setup_pages() is renamed to hvm_ioreq_server_map_pages()
  to mirror the existing hvm_ioreq_server_unmap_pages().

All of this significantly shortens the code.

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
Reviewed-by: Wei Liu 
Acked-by: Jan Beulich 
---
Cc: Andrew Cooper 

v3:
 - Rebased on top of 's->is_default' to 'IS_DEFAULT(s)' changes.
 - Minor updates in response to review comments from Roger.
---
 xen/arch/x86/hvm/ioreq.c | 182 ++-
 1 file changed, 69 insertions(+), 113 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index e6ccc7572a..6d81018369 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -210,63 +210,75 @@ bool handle_hvm_io_completion(struct vcpu *v)
 return true;
 }
 
-static int hvm_alloc_ioreq_gfn(struct domain *d, unsigned long *gfn)
+static unsigned long hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s)
 {
+struct domain *d = s->domain;
 unsigned int i;
-int rc;
 
-rc = -ENOMEM;
+ASSERT(!IS_DEFAULT(s));
+
 for ( i = 0; i < sizeof(d->arch.hvm_domain.ioreq_gfn.mask) * 8; i++ )
 {
 if ( test_and_clear_bit(i, >arch.hvm_domain.ioreq_gfn.mask) )
-{
-*gfn = d->arch.hvm_domain.ioreq_gfn.base + i;
-rc = 0;
-break;
-}
+return d->arch.hvm_domain.ioreq_gfn.base + i;
 }
 
-return rc;
+return gfn_x(INVALID_GFN);
 }
 
-static void hvm_free_ioreq_gfn(struct domain *d, unsigned long gfn)
+static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s,
+   unsigned long gfn)
 {
+struct domain *d = s->domain;
 unsigned int i = gfn - d->arch.hvm_domain.ioreq_gfn.base;
 
-if ( gfn != gfn_x(INVALID_GFN) )
-set_bit(i, >arch.hvm_domain.ioreq_gfn.mask);
+ASSERT(!IS_DEFAULT(s));
+ASSERT(gfn != gfn_x(INVALID_GFN));
+
+set_bit(i, >arch.hvm_domain.ioreq_gfn.mask);
 }
 
-static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s, bool buf)
+static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
 {
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
 
+if ( iorp->gfn == gfn_x(INVALID_GFN) )
+return;
+
 destroy_ring_for_helper(>va, iorp->page);
+iorp->page = NULL;
+
+if ( !IS_DEFAULT(s) )
+hvm_free_ioreq_gfn(s, iorp->gfn);
+
+iorp->gfn = gfn_x(INVALID_GFN);
 }
 
-static int hvm_map_ioreq_page(
-struct hvm_ioreq_server *s, bool buf, unsigned long gfn)
+static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
 {
 struct domain *d = s->domain;
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
-struct page_info *page;
-void *va;
 int rc;
 
-if ( (rc = prepare_ring_for_helper(d, gfn, , )) )
-return rc;
-
-if ( (iorp->va != NULL) || d->is_dying )
-{
-destroy_ring_for_helper(, page);
+if ( d->is_dying )
 return -EINVAL;
-}
 
-iorp->va = va;
-iorp->page = page;
-iorp->gfn = gfn;
+if ( IS_DEFAULT(s) )
+iorp->gfn = buf ?
+d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_PFN] :
+d->arch.hvm_domain.params[HVM_PARAM_IOREQ_PFN];
+else
+iorp->gfn = hvm_alloc_ioreq_gfn(s);
 
-return 0;
+if ( iorp->gfn == gfn_x(INVALID_GFN) )
+return -ENOMEM;
+
+rc = prepare_ring_for_helper(d, iorp->gfn, >page, >va);
+
+if ( rc )
+hvm_unmap_ioreq_gfn(s, buf);
+
+return rc;
 }
 
 bool is_ioreq_server_page(struct domain *d, const struct page_info *page)
@@ -279,8 +291,7 @@ bool is_ioreq_server_page(struct domain *d, const struct 
page_info *page)
 
 FOR_EACH_IOREQ_SERVER(d, id, s)
 {
-if ( (s->ioreq.va && s->ioreq.page == page) ||
- (s->bufioreq.va && s->bufioreq.page == page) )
+if ( (s->ioreq.page == page) || (s->bufioreq.page == page) )
 {
 found = true;
 break;
@@ -292,20 +303,30 @@ bool is_ioreq_server_page(struct domain *d, const struct 
page_info *page)
 return found;
 }
 
-static void hvm_remove_ioreq_gfn(
-struct domain *d, struct hvm_ioreq_page *iorp)
+static void hvm_remove_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
+
 {
+

[Xen-devel] [PATCH v11 06/11] x86/hvm/ioreq: add a new mappable resource type...

2017-10-12 Thread Paul Durrant 
... XENMEM_resource_ioreq_server

This patch adds support for a new resource type that can be mapped using
the XENMEM_acquire_resource memory op.

If an emulator makes use of this resource type then, instead of mapping
gfns, the IOREQ server will allocate pages from the heap. These pages
will never be present in the P2M of the guest at any point and so are
not vulnerable to any direct attack by the guest. They are only ever
accessible by Xen and any domain that has mapping privilege over the
guest (which may or may not be limited to the domain running the emulator).

NOTE: Use of the new resource type is not compatible with use of
  XEN_DMOP_get_ioreq_server_info unless the XEN_DMOP_no_gfns flag is
  set.

Signed-off-by: Paul Durrant 
Acked-by: George Dunlap 
Reviewed-by: Wei Liu 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 

v11:
 - Addressed more comments from Jan.

v10:
 - Addressed comments from Jan.

v8:
 - Re-base on new boilerplate.
 - Adjust function signature of hvm_get_ioreq_server_frame(), and test
   whether the bufioreq page is present.

v5:
 - Use get_ioreq_server() function rather than indexing array directly.
 - Add more explanation into comments to state than mapping guest frames
   and allocation of pages for ioreq servers are not simultaneously
   permitted.
 - Add a comment into asm/ioreq.h stating the meaning of the index
   value passed to hvm_get_ioreq_server_frame().
---
 xen/arch/x86/hvm/ioreq.c| 154 
 xen/arch/x86/mm.c   |  22 ++
 xen/common/memory.c |   5 ++
 xen/include/asm-x86/hvm/ioreq.h |   2 +
 xen/include/asm-x86/mm.h|   5 ++
 xen/include/public/hvm/dm_op.h  |   4 ++
 xen/include/public/memory.h |   9 +++
 7 files changed, 201 insertions(+)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index f654e7796c..ff41312455 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -259,6 +259,19 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
 int rc;
 
+if ( iorp->page )
+{
+/*
+ * If a page has already been allocated (which will happen on
+ * demand if hvm_get_ioreq_server_frame() is called), then
+ * mapping a guest frame is not permitted.
+ */
+if ( gfn_eq(iorp->gfn, INVALID_GFN) )
+return -EPERM;
+
+return 0;
+}
+
 if ( d->is_dying )
 return -EINVAL;
 
@@ -281,6 +294,69 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 return rc;
 }
 
+static int hvm_alloc_ioreq_mfn(struct hvm_ioreq_server *s, bool buf)
+{
+struct domain *currd = current->domain;
+struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
+
+if ( iorp->page )
+{
+/*
+ * If a guest frame has already been mapped (which may happen
+ * on demand if hvm_get_ioreq_server_info() is called), then
+ * allocating a page is not permitted.
+ */
+if ( !gfn_eq(iorp->gfn, INVALID_GFN) )
+return -EPERM;
+
+return 0;
+}
+
+/*
+ * Allocated IOREQ server pages are assigned to the emulating
+ * domain, not the target domain. This is because the emulator is
+ * likely to be destroyed after the target domain has been torn
+ * down, and we must use MEMF_no_refcount otherwise page allocation
+ * could fail if the emulating domain has already reached its
+ * maximum allocation.
+ */
+iorp->page = alloc_domheap_page(currd, MEMF_no_refcount);
+if ( !iorp->page )
+return -ENOMEM;
+
+if ( !get_page_type(iorp->page, PGT_writable_page) )
+{
+put_page(iorp->page);
+iorp->page = NULL;
+return -ENOMEM;
+}
+
+iorp->va = __map_domain_page_global(iorp->page);
+if ( !iorp->va )
+{
+put_page_and_type(iorp->page);
+iorp->page = NULL;
+return -ENOMEM;
+}
+
+clear_page(iorp->va);
+return 0;
+}
+
+static void hvm_free_ioreq_mfn(struct hvm_ioreq_server *s, bool buf)
+{
+struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
+
+if ( !iorp->page )
+return;
+
+unmap_domain_page_global(iorp->va);
+iorp->va = NULL;
+
+put_page_and_type(iorp->page);
+iorp->page = NULL;
+}
+
 bool is_ioreq_server_page(struct domain *d, const struct page_info *page)
 {
 const struct hvm_ioreq_server *s;
@@ -484,6 +560,27 @@ static void hvm_ioreq_server_unmap_pages(struct 
hvm_ioreq_server *s)
 hvm_unmap_ioreq_gfn(s, false);
 }
 
+static int hvm_ioreq_server_alloc_pages(struct hvm_ioreq_server *s)
+{
+int rc;

[Xen-devel] [PATCH v11 08/11] tools/libxenforeignmemory: add support for resource mapping

2017-10-12 Thread Paul Durrant 
A previous patch introduced a new HYPERVISOR_memory_op to acquire guest
resources for direct priv-mapping.

This patch adds new functionality into libxenforeignmemory to make use
of a new privcmd ioctl [1] that uses the new memory op to make such
resources available via mmap(2).

[1] 
http://xenbits.xen.org/gitweb/?p=people/pauldu/linux.git;a=commit;h=ce59a05e6712

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
Reviewed-by: Wei Liu 
---
Cc: Ian Jackson 

v4:
 - Fixed errno and removed single-use label
 - The unmap call now returns a status
 - Use C99 initialization for ioctl struct

v2:
 - Bump minor version up to 3.
---
 tools/include/xen-sys/Linux/privcmd.h  | 11 +
 tools/libs/foreignmemory/Makefile  |  2 +-
 tools/libs/foreignmemory/core.c| 53 ++
 .../libs/foreignmemory/include/xenforeignmemory.h  | 41 +
 tools/libs/foreignmemory/libxenforeignmemory.map   |  5 ++
 tools/libs/foreignmemory/linux.c   | 45 ++
 tools/libs/foreignmemory/private.h | 31 +
 7 files changed, 187 insertions(+), 1 deletion(-)

diff --git a/tools/include/xen-sys/Linux/privcmd.h 
b/tools/include/xen-sys/Linux/privcmd.h
index 732ff7c15a..9531b728f9 100644
--- a/tools/include/xen-sys/Linux/privcmd.h
+++ b/tools/include/xen-sys/Linux/privcmd.h
@@ -86,6 +86,15 @@ typedef struct privcmd_dm_op {
const privcmd_dm_op_buf_t __user *ubufs;
 } privcmd_dm_op_t;
 
+typedef struct privcmd_mmap_resource {
+   domid_t dom;
+   __u32 type;
+   __u32 id;
+   __u32 idx;
+   __u64 num;
+   __u64 addr;
+} privcmd_mmap_resource_t;
+
 /*
  * @cmd: IOCTL_PRIVCMD_HYPERCALL
  * @arg: _hypercall_t
@@ -103,5 +112,7 @@ typedef struct privcmd_dm_op {
_IOC(_IOC_NONE, 'P', 5, sizeof(privcmd_dm_op_t))
 #define IOCTL_PRIVCMD_RESTRICT \
_IOC(_IOC_NONE, 'P', 6, sizeof(domid_t))
+#define IOCTL_PRIVCMD_MMAP_RESOURCE\
+   _IOC(_IOC_NONE, 'P', 7, sizeof(privcmd_mmap_resource_t))
 
 #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
diff --git a/tools/libs/foreignmemory/Makefile 
b/tools/libs/foreignmemory/Makefile
index ab7f873f26..5c7f78f61d 100644
--- a/tools/libs/foreignmemory/Makefile
+++ b/tools/libs/foreignmemory/Makefile
@@ -2,7 +2,7 @@ XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 MAJOR= 1
-MINOR= 2
+MINOR= 3
 SHLIB_LDFLAGS += -Wl,--version-script=libxenforeignmemory.map
 
 CFLAGS   += -Werror -Wmissing-prototypes
diff --git a/tools/libs/foreignmemory/core.c b/tools/libs/foreignmemory/core.c
index a6897dc561..8d3f9f178f 100644
--- a/tools/libs/foreignmemory/core.c
+++ b/tools/libs/foreignmemory/core.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 
+#include 
+
 #include "private.h"
 
 xenforeignmemory_handle *xenforeignmemory_open(xentoollog_logger *logger,
@@ -120,6 +122,57 @@ int xenforeignmemory_restrict(xenforeignmemory_handle 
*fmem,
 return osdep_xenforeignmemory_restrict(fmem, domid);
 }
 
+xenforeignmemory_resource_handle *xenforeignmemory_map_resource(
+xenforeignmemory_handle *fmem, domid_t domid, unsigned int type,
+unsigned int id, unsigned long frame, unsigned long nr_frames,
+void **paddr, int prot, int flags)
+{
+xenforeignmemory_resource_handle *fres;
+int rc;
+
+/* Check flags only contains POSIX defined values */
+if ( flags & ~(MAP_SHARED | MAP_PRIVATE) )
+{
+errno = EINVAL;
+return NULL;
+}
+
+fres = calloc(1, sizeof(*fres));
+if ( !fres )
+{
+errno = ENOMEM;
+return NULL;
+}
+
+fres->domid = domid;
+fres->type = type;
+fres->id = id;
+fres->frame = frame;
+fres->nr_frames = nr_frames;
+fres->addr = *paddr;
+fres->prot = prot;
+fres->flags = flags;
+
+rc = osdep_xenforeignmemory_map_resource(fmem, fres);
+if ( rc )
+{
+free(fres);
+fres = NULL;
+} else
+*paddr = fres->addr;
+
+return fres;
+}
+
+int xenforeignmemory_unmap_resource(
+xenforeignmemory_handle *fmem, xenforeignmemory_resource_handle *fres)
+{
+int rc = osdep_xenforeignmemory_unmap_resource(fmem, fres);
+
+free(fres);
+return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h 
b/tools/libs/foreignmemory/include/xenforeignmemory.h
index f4814c390f..d594be8df0 100644
--- a/tools/libs/foreignmemory/include/xenforeignmemory.h
+++ b/tools/libs/foreignmemory/include/xenforeignmemory.h
@@ -138,6 +138,47 @@ int xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
 int xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
   domid_t domid);
 
+typedef struct xenforeignmemory_resource_handle 
xenforeignmemory_resource_handle;
+
+/**
+ * This

[Xen-devel] [PATCH v11 07/11] x86/mm: add an extra command to HYPERVISOR_mmu_update...

2017-10-12 Thread Paul Durrant 
...to allow the calling domain to prevent translation of specified l1e
value.

Despite what the comment in public/xen.h might imply, specifying a
command value of MMU_NORMAL_PT_UPDATE will not simply update an l1e with
the specified value. Instead, mod_l1_entry() tests whether foreign_dom
has PG_translate set in its paging mode and, if it does, assumes that the
the pfn value in the l1e is a gfn rather than an mfn.

To allow PV tools domain to map mfn values from a previously issued
HYPERVISOR_memory_op:XENMEM_acquire_resource, there needs to be a way
to tell HYPERVISOR_mmu_update that the specific l1e value does not
require translation regardless of the paging mode of foreign_dom. This
patch therefore defines a new command value, MMU_PT_UPDATE_NO_TRANSLATE,
which has the same semantics as MMU_NORMAL_PT_UPDATE except that the
paging mode of foreign_dom is ignored and the l1e value is used verbatim.

Signed-off-by: Paul Durrant 
Reviewed-by: Jan Beulich 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 

v8:
 - New in this version, replacing "allow a privileged PV domain to map
   guest mfns".
---
 xen/arch/x86/mm.c| 17 ++---
 xen/include/public/xen.h | 12 +---
 2 files changed, 19 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index c9bc4a4e92..3dd5b2c00f 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1619,9 +1619,10 @@ void page_unlock(struct page_info *page)
 
 /* Update the L1 entry at pl1e to new value nl1e. */
 static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t nl1e,
-unsigned long gl1mfn, int preserve_ad,
+unsigned long gl1mfn, unsigned int cmd,
 struct vcpu *pt_vcpu, struct domain *pg_dom)
 {
+bool preserve_ad = (cmd == MMU_PT_UPDATE_PRESERVE_AD);
 l1_pgentry_t ol1e;
 struct domain *pt_dom = pt_vcpu->domain;
 int rc = 0;
@@ -1643,7 +1644,8 @@ static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t 
nl1e,
 return -EINVAL;
 }
 
-if ( paging_mode_translate(pg_dom) )
+if ( cmd != MMU_PT_UPDATE_NO_TRANSLATE &&
+ paging_mode_translate(pg_dom) )
 {
 page = get_page_from_gfn(pg_dom, l1e_get_pfn(nl1e), NULL, 
P2M_ALLOC);
 if ( !page )
@@ -3258,6 +3260,7 @@ long do_mmu_update(
  */
 case MMU_NORMAL_PT_UPDATE:
 case MMU_PT_UPDATE_PRESERVE_AD:
+case MMU_PT_UPDATE_NO_TRANSLATE:
 {
 p2m_type_t p2mt;
 
@@ -3323,7 +3326,8 @@ long do_mmu_update(
 p2m_query_t q = (l1e_get_flags(l1e) & _PAGE_RW) ?
 P2M_UNSHARE : P2M_ALLOC;
 
-if ( paging_mode_translate(pg_owner) )
+if ( cmd != MMU_PT_UPDATE_NO_TRANSLATE &&
+ paging_mode_translate(pg_owner) )
 target = get_page_from_gfn(pg_owner, l1e_get_pfn(l1e),
_p2mt, q);
 
@@ -3350,9 +3354,7 @@ long do_mmu_update(
 break;
 }
 
-rc = mod_l1_entry(va, l1e, mfn,
-  cmd == MMU_PT_UPDATE_PRESERVE_AD, v,
-  pg_owner);
+rc = mod_l1_entry(va, l1e, mfn, cmd, v, pg_owner);
 if ( target )
 put_page(target);
 }
@@ -3630,7 +3632,8 @@ static int __do_update_va_mapping(
 goto out;
 }
 
-rc = mod_l1_entry(pl1e, val, mfn_x(gl1mfn), 0, v, pg_owner);
+rc = mod_l1_entry(pl1e, val, mfn_x(gl1mfn), MMU_NORMAL_PT_UPDATE, v,
+  pg_owner);
 
 page_unlock(gl1pg);
 put_page(gl1pg);
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 2ac6b1e24d..d2014a39eb 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -268,6 +268,10 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
  * As MMU_NORMAL_PT_UPDATE above, but A/D bits currently in the PTE are ORed
  * with those in @val.
  *
+ * ptr[1:0] == MMU_PT_UPDATE_NO_TRANSLATE:
+ * As MMU_NORMAL_PT_UPDATE above, but @val is not translated though FD
+ * page tables.
+ *
  * @val is usually the machine frame number along with some attributes.
  * The attributes by default follow the architecture defined bits. Meaning that
  * if this is a X86_64 machine and four page table layout is used, the layout
@@ -334,9 +338,11 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
  *
  * PAT (bit 7 on) --> PWT (bit 3 on) and clear bit 7.
  */
-#define MMU_NORMAL_PT_UPDATE  0 /* checked '*ptr = val'. ptr is MA.

[Xen-devel] [PATCH v11 04/11] x86/hvm/ioreq: defer mapping gfns until they are actually requsted

2017-10-12 Thread Paul Durrant 
A subsequent patch will introduce a new scheme to allow an emulator to
map ioreq server pages directly from Xen rather than the guest P2M.

This patch lays the groundwork for that change by deferring mapping of
gfns until their values are requested by an emulator. To that end, the
pad field of the xen_dm_op_get_ioreq_server_info structure is re-purposed
to a flags field and new flag, XEN_DMOP_no_gfns, defined which modifies the
behaviour of XEN_DMOP_get_ioreq_server_info to allow the caller to avoid
requesting the gfn values.

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
Acked-by: Wei Liu 
Reviewed-by: Jan Beulich 
---
Cc: Ian Jackson 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 

v8:
 - For safety make all of the pointers passed to
   hvm_get_ioreq_server_info() optional.
 - Shrink bufioreq_handling down to a uint8_t.

v3:
 - Updated in response to review comments from Wei and Roger.
 - Added a HANDLE_BUFIOREQ macro to make the code neater.
 - This patch no longer introduces a security vulnerability since there
   is now an explicit limit on the number of ioreq servers that may be
   created for any one domain.
---
 tools/libs/devicemodel/core.c   |  8 +
 tools/libs/devicemodel/include/xendevicemodel.h |  6 ++--
 xen/arch/x86/hvm/dm.c   |  9 +++--
 xen/arch/x86/hvm/ioreq.c| 47 ++---
 xen/include/asm-x86/hvm/domain.h|  2 +-
 xen/include/public/hvm/dm_op.h  | 32 ++---
 6 files changed, 63 insertions(+), 41 deletions(-)

diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c
index 0f2c1a791f..91c69d103b 100644
--- a/tools/libs/devicemodel/core.c
+++ b/tools/libs/devicemodel/core.c
@@ -188,6 +188,14 @@ int xendevicemodel_get_ioreq_server_info(
 
 data->id = id;
 
+/*
+ * If the caller is not requesting gfn values then instruct the
+ * hypercall not to retrieve them as this may cause them to be
+ * mapped.
+ */
+if (!ioreq_gfn && !bufioreq_gfn)
+data->flags |= XEN_DMOP_no_gfns;
+
 rc = xendevicemodel_op(dmod, domid, 1, , sizeof(op));
 if (rc)
 return rc;
diff --git a/tools/libs/devicemodel/include/xendevicemodel.h 
b/tools/libs/devicemodel/include/xendevicemodel.h
index 13216db04a..d73a76da35 100644
--- a/tools/libs/devicemodel/include/xendevicemodel.h
+++ b/tools/libs/devicemodel/include/xendevicemodel.h
@@ -61,11 +61,11 @@ int xendevicemodel_create_ioreq_server(
  * @parm domid the domain id to be serviced
  * @parm id the IOREQ Server id.
  * @parm ioreq_gfn pointer to a xen_pfn_t to receive the synchronous ioreq
- *  gfn
+ *  gfn. (May be NULL if not required)
  * @parm bufioreq_gfn pointer to a xen_pfn_t to receive the buffered ioreq
- *gfn
+ *gfn. (May be NULL if not required)
  * @parm bufioreq_port pointer to a evtchn_port_t to receive the buffered
- * ioreq event channel
+ * ioreq event channel. (May be NULL if not required)
  * @return 0 on success, -1 on failure.
  */
 int xendevicemodel_get_ioreq_server_info(
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index 9cf53b551c..22fa5b51e3 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -416,16 +416,19 @@ static int dm_op(const struct dmop_args *op_args)
 {
 struct xen_dm_op_get_ioreq_server_info *data =
 _ioreq_server_info;
+const uint16_t valid_flags = XEN_DMOP_no_gfns;
 
 const_op = false;
 
 rc = -EINVAL;
-if ( data->pad )
+if ( data->flags & ~valid_flags )
 break;
 
 rc = hvm_get_ioreq_server_info(d, data->id,
-   >ioreq_gfn,
-   >bufioreq_gfn,
+   (data->flags & XEN_DMOP_no_gfns) ?
+   NULL : >ioreq_gfn,
+   (data->flags & XEN_DMOP_no_gfns) ?
+   NULL : >bufioreq_gfn,
>bufioreq_port);
 break;
 }
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 64bb13cec9..f654e7796c 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -350,6 +350,9 @@ static void hvm_update_ioreq_evtchn(struct hvm_ioreq_server 
*s,
 }
 }
 
+#define HANDLE_BUFIOREQ(s) \
+((s)->bufioreq_handling != HVM_IOREQSRV_BUFIOREQ_OFF)
+
 static int hvm_ioreq_server_add_vcpu(struct hvm_ioreq_server *s,
  struct vcpu *v)
 {
@@

[Xen-devel] [PATCH v11 00/11] x86: guest resource mapping

2017-10-12 Thread Paul Durrant 
This series introduces support for direct mapping of guest resources.
The resources are:
 - IOREQ server pages
 - Grant tables

v10:
 - Responded to comments from Jan.

v9:
 - Change to patch #1 only.

v8:
 - Re-ordered series and dropped two patches that have already been
committed.

v7:
 - Fixed assertion failure hit during domain destroy.

v6:
 - Responded to missed comments from Roger.

v5:
 - Responded to review comments from Wei.

v4:
 - Responded to further review comments from Roger.

v3:
 - Dropped original patch #1 since it is covered by Juergen's patch.
 - Added new xenforeignmemorycleanup patch (#4).
 - Replaced the patch introducing the ioreq server 'is_default' flag with
   one that changes the ioreq server list into an array (#8).
  
Paul Durrant (11):
  x86/hvm/ioreq: maintain an array of ioreq servers rather than a list
  x86/hvm/ioreq: simplify code and use consistent naming
  x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page
  x86/hvm/ioreq: defer mapping gfns until they are actually requsted
  x86/mm: add HYPERVISOR_memory_op to acquire guest resources
  x86/hvm/ioreq: add a new mappable resource type...
  x86/mm: add an extra command to HYPERVISOR_mmu_update...
  tools/libxenforeignmemory: add support for resource mapping
  tools/libxenforeignmemory: reduce xenforeignmemory_restrict code
footprint
  common: add a new mappable resource type: XENMEM_resource_grant_table
  tools/libxenctrl: use new xenforeignmemory API to seed grant table

 tools/flask/policy/modules/xen.if  |   4 +-
 tools/include/xen-sys/Linux/privcmd.h  |  11 +
 tools/libs/devicemodel/core.c  |   8 +
 tools/libs/devicemodel/include/xendevicemodel.h|   6 +-
 tools/libs/foreignmemory/Makefile  |   2 +-
 tools/libs/foreignmemory/core.c|  53 ++
 tools/libs/foreignmemory/freebsd.c |   7 -
 .../libs/foreignmemory/include/xenforeignmemory.h  |  41 +
 tools/libs/foreignmemory/libxenforeignmemory.map   |   5 +
 tools/libs/foreignmemory/linux.c   |  45 ++
 tools/libs/foreignmemory/minios.c  |   7 -
 tools/libs/foreignmemory/netbsd.c  |   7 -
 tools/libs/foreignmemory/private.h |  43 +-
 tools/libs/foreignmemory/solaris.c |   7 -
 tools/libxc/include/xc_dom.h   |   8 +-
 tools/libxc/xc_dom_boot.c  | 114 ++-
 tools/libxc/xc_sr_restore_x86_hvm.c|  10 +-
 tools/libxc/xc_sr_restore_x86_pv.c |   2 +-
 tools/libxl/libxl_dom.c|   1 -
 tools/python/xen/lowlevel/xc/xc.c  |   6 +-
 xen/arch/x86/hvm/dm.c  |   9 +-
 xen/arch/x86/hvm/ioreq.c   | 829 -
 xen/arch/x86/mm.c  |  39 +-
 xen/arch/x86/mm/p2m.c  |   3 +-
 xen/common/compat/memory.c | 145 +++-
 xen/common/grant_table.c   |  63 +-
 xen/common/memory.c| 137 
 xen/include/asm-x86/hvm/domain.h   |  14 +-
 xen/include/asm-x86/hvm/ioreq.h|   2 +
 xen/include/asm-x86/mm.h   |   5 +
 xen/include/asm-x86/p2m.h  |   3 +
 xen/include/public/hvm/dm_op.h |  36 +-
 xen/include/public/memory.h|  58 +-
 xen/include/public/xen.h   |  12 +-
 xen/include/xen/grant_table.h  |   4 +
 xen/include/xlat.lst   |   1 +
 xen/include/xsm/dummy.h|   6 +
 xen/include/xsm/xsm.h  |   6 +
 xen/xsm/dummy.c|   1 +
 xen/xsm/flask/hooks.c  |   6 +
 xen/xsm/flask/policy/access_vectors|   2 +
 41 files changed, 1267 insertions(+), 501 deletions(-)

---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 

-- 
2.11.0


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

[Xen-devel] [PATCH v11 03/11] x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page

2017-10-12 Thread Paul Durrant 
This patch adjusts the ioreq server code to use type-safe gfn_t values
where possible. No functional change.

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
Reviewed-by: Wei Liu 
Acked-by: Jan Beulich 
---
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/ioreq.c | 44 
 xen/include/asm-x86/hvm/domain.h |  2 +-
 2 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 6d81018369..64bb13cec9 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -210,7 +210,7 @@ bool handle_hvm_io_completion(struct vcpu *v)
 return true;
 }
 
-static unsigned long hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s)
+static gfn_t hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s)
 {
 struct domain *d = s->domain;
 unsigned int i;
@@ -220,20 +220,19 @@ static unsigned long hvm_alloc_ioreq_gfn(struct 
hvm_ioreq_server *s)
 for ( i = 0; i < sizeof(d->arch.hvm_domain.ioreq_gfn.mask) * 8; i++ )
 {
 if ( test_and_clear_bit(i, >arch.hvm_domain.ioreq_gfn.mask) )
-return d->arch.hvm_domain.ioreq_gfn.base + i;
+return _gfn(d->arch.hvm_domain.ioreq_gfn.base + i);
 }
 
-return gfn_x(INVALID_GFN);
+return INVALID_GFN;
 }
 
-static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s,
-   unsigned long gfn)
+static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s, gfn_t gfn)
 {
 struct domain *d = s->domain;
-unsigned int i = gfn - d->arch.hvm_domain.ioreq_gfn.base;
+unsigned int i = gfn_x(gfn) - d->arch.hvm_domain.ioreq_gfn.base;
 
 ASSERT(!IS_DEFAULT(s));
-ASSERT(gfn != gfn_x(INVALID_GFN));
+ASSERT(!gfn_eq(gfn, INVALID_GFN));
 
 set_bit(i, >arch.hvm_domain.ioreq_gfn.mask);
 }
@@ -242,7 +241,7 @@ static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 {
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
 
-if ( iorp->gfn == gfn_x(INVALID_GFN) )
+if ( gfn_eq(iorp->gfn, INVALID_GFN) )
 return;
 
 destroy_ring_for_helper(>va, iorp->page);
@@ -251,7 +250,7 @@ static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 if ( !IS_DEFAULT(s) )
 hvm_free_ioreq_gfn(s, iorp->gfn);
 
-iorp->gfn = gfn_x(INVALID_GFN);
+iorp->gfn = INVALID_GFN;
 }
 
 static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
@@ -264,16 +263,17 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 return -EINVAL;
 
 if ( IS_DEFAULT(s) )
-iorp->gfn = buf ?
-d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_PFN] :
-d->arch.hvm_domain.params[HVM_PARAM_IOREQ_PFN];
+iorp->gfn = _gfn(buf ?
+ d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_PFN] :
+ d->arch.hvm_domain.params[HVM_PARAM_IOREQ_PFN]);
 else
 iorp->gfn = hvm_alloc_ioreq_gfn(s);
 
-if ( iorp->gfn == gfn_x(INVALID_GFN) )
+if ( gfn_eq(iorp->gfn, INVALID_GFN) )
 return -ENOMEM;
 
-rc = prepare_ring_for_helper(d, iorp->gfn, >page, >va);
+rc = prepare_ring_for_helper(d, gfn_x(iorp->gfn), >page,
+ >va);
 
 if ( rc )
 hvm_unmap_ioreq_gfn(s, buf);
@@ -309,10 +309,10 @@ static void hvm_remove_ioreq_gfn(struct hvm_ioreq_server 
*s, bool buf)
 struct domain *d = s->domain;
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
 
-if ( IS_DEFAULT(s) || iorp->gfn == gfn_x(INVALID_GFN) )
+if ( IS_DEFAULT(s) || gfn_eq(iorp->gfn, INVALID_GFN) )
 return;
 
-if ( guest_physmap_remove_page(d, _gfn(iorp->gfn),
+if ( guest_physmap_remove_page(d, iorp->gfn,
_mfn(page_to_mfn(iorp->page)), 0) )
 domain_crash(d);
 clear_page(iorp->va);
@@ -324,12 +324,12 @@ static int hvm_add_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
 int rc;
 
-if ( IS_DEFAULT(s) || iorp->gfn == gfn_x(INVALID_GFN) )
+if ( IS_DEFAULT(s) || gfn_eq(iorp->gfn, INVALID_GFN) )
 return 0;
 
 clear_page(iorp->va);
 
-rc = guest_physmap_add_page(d, _gfn(iorp->gfn),
+rc = guest_physmap_add_page(d, iorp->gfn,
 _mfn(page_to_mfn(iorp->page)), 0);
 if ( rc == 0 )
 paging_mark_dirty(d, _mfn(page_to_mfn(iorp->page)));
@@ -590,8 +590,8 @@ static int hvm_ioreq_server_init(struct hvm_ioreq_server *s,
 INIT_LIST_HEAD(>ioreq_vcpu_list);
 spin_lock_init(>bufioreq_lock);
 
-s->ioreq.gfn = gfn_x(INVALID_GFN);
-s->bufioreq.gfn = gfn_x(INVALID_GFN);
+s->ioreq.gfn = INVALID_GFN;
+s->bufioreq.gfn = INVALID_GFN;
 
 rc = hvm_ioreq_server_alloc_rangesets(s, id);
 if ( rc )
@@ -757,11 +757,11 @@ int

[Xen-devel] [PATCH v11 09/11] tools/libxenforeignmemory: reduce xenforeignmemory_restrict code footprint

2017-10-12 Thread Paul Durrant 
By using a static inline stub in private.h for OS where this functionality
is not implemented, the various duplicate stubs in the OS-specific source
modules can be avoided.

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 

v4:
 - Removed extraneous freebsd code.

v3:
 - Patch added in response to review comments.
---
 tools/libs/foreignmemory/freebsd.c |  7 ---
 tools/libs/foreignmemory/minios.c  |  7 ---
 tools/libs/foreignmemory/netbsd.c  |  7 ---
 tools/libs/foreignmemory/private.h | 12 +---
 tools/libs/foreignmemory/solaris.c |  7 ---
 5 files changed, 9 insertions(+), 31 deletions(-)

diff --git a/tools/libs/foreignmemory/freebsd.c 
b/tools/libs/foreignmemory/freebsd.c
index dec447485a..6e6bc4b11f 100644
--- a/tools/libs/foreignmemory/freebsd.c
+++ b/tools/libs/foreignmemory/freebsd.c
@@ -95,13 +95,6 @@ int osdep_xenforeignmemory_unmap(xenforeignmemory_handle 
*fmem,
 return munmap(addr, num << PAGE_SHIFT);
 }
 
-int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
-domid_t domid)
-{
-errno = -EOPNOTSUPP;
-return -1;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/foreignmemory/minios.c 
b/tools/libs/foreignmemory/minios.c
index 75f340122e..43341ca301 100644
--- a/tools/libs/foreignmemory/minios.c
+++ b/tools/libs/foreignmemory/minios.c
@@ -58,13 +58,6 @@ int osdep_xenforeignmemory_unmap(xenforeignmemory_handle 
*fmem,
 return munmap(addr, num << PAGE_SHIFT);
 }
 
-int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
-domid_t domid)
-{
-errno = -EOPNOTSUPP;
-return -1;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/foreignmemory/netbsd.c 
b/tools/libs/foreignmemory/netbsd.c
index 9bf95ef4f0..54a418ebd6 100644
--- a/tools/libs/foreignmemory/netbsd.c
+++ b/tools/libs/foreignmemory/netbsd.c
@@ -100,13 +100,6 @@ int osdep_xenforeignmemory_unmap(xenforeignmemory_handle 
*fmem,
 return munmap(addr, num*XC_PAGE_SIZE);
 }
 
-int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
-domid_t domid)
-{
-errno = -EOPNOTSUPP;
-return -1;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/foreignmemory/private.h 
b/tools/libs/foreignmemory/private.h
index 80b22bdbfc..b5d5f0a354 100644
--- a/tools/libs/foreignmemory/private.h
+++ b/tools/libs/foreignmemory/private.h
@@ -32,9 +32,6 @@ void *osdep_xenforeignmemory_map(xenforeignmemory_handle 
*fmem,
 int osdep_xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
  void *addr, size_t num);
 
-int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
-domid_t domid);
-
 #if defined(__NetBSD__) || defined(__sun__)
 /* Strictly compat for those two only only */
 void *compat_mapforeign_batch(xenforeignmem_handle *fmem, uint32_t dom,
@@ -54,6 +51,13 @@ struct xenforeignmemory_resource_handle {
 };
 
 #ifndef __linux__
+static inline int osdep_xenforeignmemory_restrict(xenforeignmemory_handle 
*fmem,
+  domid_t domid)
+{
+errno = EOPNOTSUPP;
+return -1;
+}
+
 static inline int osdep_xenforeignmemory_map_resource(
 xenforeignmemory_handle *fmem, xenforeignmemory_resource_handle *fres)
 {
@@ -67,6 +71,8 @@ static inline int osdep_xenforeignmemory_unmap_resource(
 return 0;
 }
 #else
+int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
+domid_t domid);
 int osdep_xenforeignmemory_map_resource(
 xenforeignmemory_handle *fmem, xenforeignmemory_resource_handle *fres);
 int osdep_xenforeignmemory_unmap_resource(
diff --git a/tools/libs/foreignmemory/solaris.c 
b/tools/libs/foreignmemory/solaris.c
index a33decb4ae..ee8aae4fbd 100644
--- a/tools/libs/foreignmemory/solaris.c
+++ b/tools/libs/foreignmemory/solaris.c
@@ -97,13 +97,6 @@ int osdep_xenforeignmemory_unmap(xenforeignmemory_handle 
*fmem,
 return munmap(addr, num*XC_PAGE_SIZE);
 }
 
-int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
-domid_t domid)
-{
-errno = -EOPNOTSUPP;
-return -1;
-}
-
 /*
  * Local variables:
  * mode: C
-- 
2.11.0


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

Re: [Xen-devel] [PATCH for-next 2/3] xen/x86: Introduce static inline wrappers for l{idt, gdt, ldt, tr}()

2017-10-12 Thread Andrew Cooper 
On 12/10/17 16:53, Jan Beulich wrote:
 On 02.10.17 at 18:13,  wrote:
>> The triple-fault reboot method stays as is, to avoid the int3 possibly 
>> getting
>> moved relative to the lidt.
> Aren't asm volatile()s ordered wrt to one another?

>From the docs

"Note that the compiler can move even volatile |asm| instructions
relative to other code, including across jump instructions."

Also, I seem to recall Tim finding an example where GCC 6 did reorder
two asm volatiles relative to each other, due to their output operands
not being causally linked.

On that note however, these should gain memory clobbers to make them
full barriers.  l{i,g}dt() are serialising, while nothing good will come
of having a segment register access reordered with respect to l{g,l}dt().

>
>> --- a/xen/include/asm-x86/desc.h
>> +++ b/xen/include/asm-x86/desc.h
>> @@ -197,6 +197,26 @@ DECLARE_PER_CPU(struct desc_struct *, compat_gdt_table);
>>  
>>  extern void load_TR(void);
>>  
>> +static inline void lgdt(const struct desc_ptr *gdtr)
>> +{
>> +asm volatile ("lgdt %0" :: "m" (*gdtr));
>> +}
>> +
>> +static inline void lidt(const struct desc_ptr *idtr)
>> +{
>> +asm volatile ("lidt %0" :: "m" (*idtr));
>> +}
>> +
>> +static inline void lldt(unsigned int sel)
>> +{
>> +asm volatile ("lldt %w0" :: "rm" (sel));
>> +}
>> +
>> +static inline void ltr(unsigned int sel)
>> +{
>> +asm volatile ("ltr %w0" :: "rm" (sel));
>> +}
> As can be seen from the code you replace in ldt.h, in headers we
> generally prefer to use __asm__ (and __volatile__ where needed).
> I'm sure this isn't consistent, so I won't insist. However, style-wise
> please add blanks immediately inside the parentheses. With at least
> this last point taken care of

Will do.

> Reviewed-by: Jan Beulich 

Does this still stand in light of the barrier change above?

~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-next 3/3] x86/ldt: Alter how invalidate_shadow_ldt() deals with TLB flushes

2017-10-12 Thread Jan Beulich 
>>> On 02.10.17 at 18:13,  wrote:
> @@ -518,26 +522,29 @@ static void invalidate_shadow_ldt(struct vcpu *v, int 
> flush)
>  if ( v->arch.pv_vcpu.shadow_ldt_mapcnt == 0 )
>  goto out;
>  
> -v->arch.pv_vcpu.shadow_ldt_mapcnt = 0;
>  pl1e = pv_ldt_ptes(v);
>  
>  for ( i = 0; i < 16; i++ )
>  {
>  if ( !(l1e_get_flags(pl1e[i]) & _PAGE_PRESENT) )
>  continue;
> +
>  page = l1e_get_page(pl1e[i]);
>  l1e_write([i], l1e_empty());
> +mappings_dropped++;
> +
>  ASSERT_PAGE_IS_TYPE(page, PGT_seg_desc_page);
>  ASSERT_PAGE_IS_DOMAIN(page, v->domain);
>  put_page_and_type(page);
>  }
>  
> -/* Rid TLBs of stale mappings (guest mappings and shadow mappings). */
> -if ( flush )
> -flush_tlb_mask(v->vcpu_dirty_cpumask);
> +ASSERT(v->arch.pv_vcpu.shadow_ldt_mapcnt == mappings_dropped);
> +v->arch.pv_vcpu.shadow_ldt_mapcnt = 0;
>  
>   out:
>  spin_unlock(>arch.pv_vcpu.shadow_ldt_lock);
> +
> +return !!mappings_dropped;

You don't need the !! here. With that
Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH for-next 2/3] xen/x86: Introduce static inline wrappers for l{idt, gdt, ldt, tr}()

2017-10-12 Thread Jan Beulich 
>>> On 02.10.17 at 18:13,  wrote:
> The triple-fault reboot method stays as is, to avoid the int3 possibly getting
> moved relative to the lidt.

Aren't asm volatile()s ordered wrt to one another?

> --- a/xen/include/asm-x86/desc.h
> +++ b/xen/include/asm-x86/desc.h
> @@ -197,6 +197,26 @@ DECLARE_PER_CPU(struct desc_struct *, compat_gdt_table);
>  
>  extern void load_TR(void);
>  
> +static inline void lgdt(const struct desc_ptr *gdtr)
> +{
> +asm volatile ("lgdt %0" :: "m" (*gdtr));
> +}
> +
> +static inline void lidt(const struct desc_ptr *idtr)
> +{
> +asm volatile ("lidt %0" :: "m" (*idtr));
> +}
> +
> +static inline void lldt(unsigned int sel)
> +{
> +asm volatile ("lldt %w0" :: "rm" (sel));
> +}
> +
> +static inline void ltr(unsigned int sel)
> +{
> +asm volatile ("ltr %w0" :: "rm" (sel));
> +}

As can be seen from the code you replace in ldt.h, in headers we
generally prefer to use __asm__ (and __volatile__ where needed).
I'm sure this isn't consistent, so I won't insist. However, style-wise
please add blanks immediately inside the parentheses. With at least
this last point taken care of
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH v1 00/27] x86: PIE support and option to extend KASLR randomization

2017-10-12 Thread Markus Trippelsdorf 
On 2017.10.12 at 08:34 -0700, Thomas Garnier wrote:
> On Wed, Oct 11, 2017 at 2:34 PM, Tom Lendacky  wrote:
> > On 10/11/2017 3:30 PM, Thomas Garnier wrote:
> >> Changes:
> >>   - patch v1:
> >> - Simplify ftrace implementation.
> >> - Use gcc mstack-protector-guard-reg=%gs with PIE when possible.
> >>   - rfc v3:
> >> - Use --emit-relocs instead of -pie to reduce dynamic relocation space 
> >> on
> >>   mapped memory. It also simplifies the relocation process.
> >> - Move the start the module section next to the kernel. Remove the 
> >> need for
> >>   -mcmodel=large on modules. Extends module space from 1 to 2G maximum.
> >> - Support for XEN PVH as 32-bit relocations can be ignored with
> >>   --emit-relocs.
> >> - Support for GOT relocations previously done automatically with -pie.
> >> - Remove need for dynamic PLT in modules.
> >> - Support dymamic GOT for modules.
> >>   - rfc v2:
> >> - Add support for global stack cookie while compiler default to fs 
> >> without
> >>   mcmodel=kernel
> >> - Change patch 7 to correctly jump out of the identity mapping on 
> >> kexec load
> >>   preserve.
> >>
> >> These patches make the changes necessary to build the kernel as Position
> >> Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below
> >> the top 2G of the virtual address space. It allows to optionally extend the
> >> KASLR randomization range from 1G to 3G.
> >
> > Hi Thomas,
> >
> > I've applied your patches so that I can verify that SME works with PIE.
> > Unfortunately, I'm running into build warnings and errors when I enable
> > PIE.
> >
> > With CONFIG_STACK_VALIDATION=y I receive lots of messages like this:
> >
> >   drivers/scsi/libfc/fc_exch.o: warning: objtool: 
> > fc_destroy_exch_mgr()+0x0: call without frame pointer save/setup
> >
> > Disabling CONFIG_STACK_VALIDATION suppresses those.
> 
> I ran into that, I plan to fix it in the next iteration.
> 
> >
> > But near the end of the build, I receive errors like this:
> >
> >   arch/x86/kernel/setup.o: In function `dump_kernel_offset':
> >   .../arch/x86/kernel/setup.c:801:(.text+0x32): relocation truncated to 
> > fit: R_X86_64_32S against symbol `_text' defined in .text section in 
> > .tmp_vmlinux1
> >   .
> >   . about 10 more of the above type messages
> >   .
> >   make: *** [vmlinux] Error 1
> >   Error building kernel, exiting
> >
> > Are there any config options that should or should not be enabled when
> > building with PIE enabled?  Is there a compiler requirement for PIE (I'm
> > using gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5))?
> 
> I never ran into these ones and I tested compilers older and newer.
> What was your exact configuration?

I get with gcc trunk and CONFIG_RANDOMIZE_BASE_LARGE=y:

...
  MODPOST vmlinux.o 
  ld: failed to convert GOTPCREL relocation; relink with --no-relax

and after adding --no-relax to vmlinux_link() in scripts/link-vmlinux.sh:

  MODPOST vmlinux.o
virt/kvm/vfio.o: In function `kvm_vfio_update_coherency.isra.4':
vfio.c:(.text+0x63): relocation truncated to fit: R_X86_64_PLT32 against 
undefined symbol `vfio_external_check_extension'
virt/kvm/vfio.o: In function `kvm_vfio_destroy':
vfio.c:(.text+0xf7): relocation truncated to fit: R_X86_64_PLT32 against 
undefined symbol `vfio_group_set_kvm'
vfio.c:(.text+0x10a): relocation truncated to fit: R_X86_64_PLT32 against 
undefined symbol `vfio_group_put_external_user'
virt/kvm/vfio.o: In function `kvm_vfio_set_attr':
vfio.c:(.text+0x2bc): relocation truncated to fit: R_X86_64_PLT32 against 
undefined symbol `vfio_external_group_match_file'
vfio.c:(.text+0x307): relocation truncated to fit: R_X86_64_PLT32 against 
undefined symbol `vfio_group_set_kvm'
vfio.c:(.text+0x31a): relocation truncated to fit: R_X86_64_PLT32 against 
undefined symbol `vfio_group_put_external_user'
vfio.c:(.text+0x3b9): relocation truncated to fit: R_X86_64_PLT32 against 
undefined symbol `vfio_group_get_external_user'
vfio.c:(.text+0x462): relocation truncated to fit: R_X86_64_PLT32 against 
undefined symbol `vfio_group_set_kvm'
vfio.c:(.text+0x4bd): relocation truncated to fit: R_X86_64_PLT32 against 
undefined symbol `vfio_group_put_external_user'
make: *** [Makefile:1000: vmlinux] Error 1

Works fine with CONFIG_RANDOMIZE_BASE_LARGE unset.

-- 
Markus


config.gz
Description: application/gunzip
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] [RFC QEMU PATCH v3 00/10] Implement vNVDIMM for Xen HVM guest

2017-10-12 Thread Paolo Bonzini 
On 12/10/2017 14:45, Haozhong Zhang wrote:
> Basically, QEMU builds two ROMs for guest, /rom@etc/acpi/tables and
> /rom@etc/table-loader. The former is unstructured to guest, and
> contains all data of guest ACPI. The latter is a BIOSLinkerLoader
> organized as a set of commands, which direct the guest (e.g., SeaBIOS
> on KVM/QEMU) to relocate data in the former file, recalculate checksum
> of specified area, and fill guest address in specified ACPI field.
> 
> One part of my patches is to implement a mechanism to tell Xen which
> part of ACPI data is a table (NFIT), and which part defines a
> namespace device and what the device name is. I can add two new loader
> commands for them respectively.
> 
> Because they just provide information and SeaBIOS in non-xen
> environment ignores unrecognized commands, they will not break SeaBIOS
> in non-xen environment.
> 
> On QEMU side, most Xen-specific hacks in ACPI builder could be
> dropped, and replaced by adding the new loader commands (though they
> may be used only by Xen).
> 
> On Xen side, a fw_cfg driver and a BIOSLinkerLoader command executor
> are needed in, perhaps, hvmloader.

If Xen has to parse BIOSLinkerLoader, it can use the existing commands
to process a reduced set of ACPI tables.  In other words,
etc/acpi/tables would only include the NFIT, the SSDT with namespace
devices, and the XSDT.  etc/acpi/rsdp would include the RSDP table as usual.

hvmloader can then:

1) allocate some memory for where the XSDT will go

2) process the BIOSLinkerLoader like SeaBIOS would do

3) find the RSDP in low memory, since the loader script must have placed
it there.  If it cannot find it, allocate some low memory, fill it with
the RSDP header and revision, and and jump to step 6

4) If it found QEMU's RSDP, use it to find QEMU's XSDT

5) Copy ACPI table pointers from QEMU to hvmloader's RSDT and/or XSDT.

6) build hvmloader tables and link them into the RSDT and/or XSDT as usual.

7) overwrite the RSDP in low memory with a pointer to hvmloader's own
RSDT and/or XSDT, and updated the checksums

QEMU's XSDT remains there somewhere in memory, unused but harmless.

Paolo

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

Re: [Xen-devel] [PATCH for-next 1/3] x86/smp: Rework cpu_smpboot_alloc() to cope with more than just -ENOMEM

2017-10-12 Thread Jan Beulich 
>>> On 02.10.17 at 18:13,  wrote:
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH 3/3] x86/mm: Consolidate all Xen L4 slot writing into init_xen_l4_slots()

2017-10-12 Thread Jan Beulich 
>>> On 12.10.17 at 17:24,  wrote:
> On 12/10/17 16:08, Jan Beulich wrote:
> On 12.10.17 at 15:54,  wrote:
>>> --- a/xen/arch/x86/mm/hap/hap.c
>>> +++ b/xen/arch/x86/mm/hap/hap.c
>>> @@ -391,41 +391,24 @@ int hap_set_allocation(struct domain *d, unsigned int 
> pages, bool *preempted)
>>>  return 0;
>>>  }
>>>  
>>> -static void hap_install_xen_entries_in_l4(struct vcpu *v, mfn_t l4mfn)
>>> -{
>>> -struct domain *d = v->domain;
>>> -l4_pgentry_t *l4e;
>>> -
>>> -l4e = map_domain_page(l4mfn);
>>> -
>>> -/* Copy the common Xen mappings from the idle domain */
>>> -memcpy([ROOT_PAGETABLE_FIRST_XEN_SLOT],
>>> -   _pg_table[ROOT_PAGETABLE_FIRST_XEN_SLOT],
>>> -   ROOT_PAGETABLE_XEN_SLOTS * sizeof(l4_pgentry_t));
>>> -
>>> -/* Install the per-domain mappings for this domain */
>>> -l4e[l4_table_offset(PERDOMAIN_VIRT_START)] =
>>> -l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW);
>>> -
>>> -/* Install a linear mapping */
>>> -l4e[l4_table_offset(LINEAR_PT_VIRT_START)] =
>>> -l4e_from_mfn(l4mfn, __PAGE_HYPERVISOR_RW);
>>> -
>>> -unmap_domain_page(l4e);
>>> -}
>>> -
>>>  static mfn_t hap_make_monitor_table(struct vcpu *v)
>>>  {
>>>  struct domain *d = v->domain;
>>>  struct page_info *pg;
>>> +l4_pgentry_t *l4e;
>>>  mfn_t m4mfn;
>>>  
>>>  ASSERT(pagetable_get_pfn(v->arch.monitor_table) == 0);
>>>  
>>>  if ( (pg = hap_alloc(d)) == NULL )
>>>  goto oom;
>>> +
>>>  m4mfn = page_to_mfn(pg);
>>> -hap_install_xen_entries_in_l4(v, m4mfn);
>>> +l4e = __map_domain_page(pg);
>> If you obtain the MFN anyway, map_domain_page() is cheaper
>> generated code wise.
> 
> Ah yes.  Given that __map_domain_page() is a define, I'd hope the
> compiler can spot and optimise away the double page_to_mfn().

Considering this is a non-trivial operation, I'm afraid many (if not
all) compiler versions won't be smart enough.

>>> --- a/xen/arch/x86/pv/domain.c
>>> +++ b/xen/arch/x86/pv/domain.c
>>> @@ -35,7 +35,7 @@ static int setup_compat_l4(struct vcpu *v)
>>>  
>>>  l4tab = __map_domain_page(pg);
>>>  clear_page(l4tab);
>>> -init_guest_l4_table(l4tab, v->domain, 1);
>>> +init_xen_l4_slots(l4tab, page_to_mfn(pg), v->domain, INVALID_MFN, 
> false);
>> Perhaps worth avoiding the double translation here too.
>>
>> In any event
>> Reviewed-by: Jan Beulich 
> 
> Just to confirm, the additional delta is:

Yes, looks fine, thanks.

Jan


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

Re: [Xen-devel] [PATCH v4 11/12] fuzz/x86_emulate: Set and fuzz more CPU state

2017-10-12 Thread Jan Beulich 
>>> On 11.10.17 at 19:52,  wrote:
> The Intel manual claims that, "If [certain CPUID bits] are set, the
> processor deprecates FCS and FDS, and the field is saved as h";
> but experimentally it would be more accurate to say, "the field is
> occasionally saved as h".  This causes the --rerun checking to
> trip non-deterministically.  Sanitize them to zero.

I think we've meanwhile settled on the field being saved as zero
being a side effect of using 32-bit fxsave plus a context switch in
the OS kernel.

> @@ -594,6 +595,75 @@ static const struct x86_emulate_ops all_fuzzer_ops = {
>  };
>  #undef SET
>  
> +/*
> + * This funciton will read or write fxsave to the fpu.  When writing,
> + * it 'sanitizes' the state: It will mask off the appropriate bits in
> + * the mxcsr, 'restore' the state to the fpu, then 'save' it again so
> + * that the data in fxsave reflects what's actually in the FPU.
> + *
> + * TODO: Extend state beyond just FPU (ymm registers, )
> + */
> +static void _set_fpu_state(char *fxsave, bool write)
> +{
> +if ( cpu_has_fxsr )
> +{
> +static union __attribute__((__aligned__(16))) {
> +char x[512];
> +struct {
> +uint16_t cw, sw;
> +uint8_t  tw, _rsvd1;
> +uint16_t op;
> +uint32_t ip;
> +uint16_t cs, _rsvd2;
> +uint32_t dp;
> +uint16_t ds, _rsvd3;
> +uint32_t mxcsr;
> +uint32_t mxcsr_mask;
> +/* ... */
> +};
> +} *fxs;
> +
> +fxs = (typeof(fxs))fxsave;
> +
> +if ( write )
> +{
> +/* 
> + * Clear reserved bits to make sure we don't get any
> + * exceptions
> + */
> +fxs->mxcsr &= mxcsr_mask;
> +
> +/*
> + * The Intel manual says that on newer models CS/DS are
> + * deprecated and that these fields "are saved as h".
> + * Experimentally, however, at least on my test box,
> + * whether this saved as h or as the previously
> + * written value is random; meaning that when run with
> + * --rerun, we occasionally detect a "state mismatch" in these
> + * bytes.  Instead, simply sanitize them to zero.
> + *
> + * TODO Check CPUID as specified in the manual before
> + * clearing
> + */
> +fxs->cs = fxs->ds = 0;

Shouldn't be needed anymore with ...

> +asm volatile( "fxrstor %0" :: "m" (*fxs) );

rex64 (or fxrstor64) used here and ...

> +}
> +
> +asm volatile( "fxsave %0" : "=m" (*fxs) );

... here (of course the alternative here then is fxsave64).

Also please add blanks before the opening parentheses.

> @@ -732,6 +806,18 @@ static void setup_state(struct x86_emulate_ctxt *ctxt)
>  printf("Setting cpu_user_regs offset %x\n", offset);
>  continue;
>  }
> +offset -= sizeof(struct cpu_user_regs);
> +
> +/* Fuzz fxsave state */
> +if ( offset < sizeof(s->fxsave) / 4 )

You've switched to sizeof() here but ...

> +{
> +/* 32-bit size is arbitrary; see comment above */
> +if ( !input_read(s, s->fxsave + (offset * 4), 4) )
> +return;
> +printf("Setting fxsave offset %x\n", offset * 4);
> +continue;
> +}
> +offset -= 128;

... not here.

> @@ -1008,6 +1098,16 @@ static void compare_states(struct fuzz_state state[2])
>  if ( memcmp([0].ops, [1].ops, sizeof(state[0].ops)) )
>  printf("ops differ!\n");
>  
> +if ( memcmp([0].fxsave, [1].fxsave, 
> sizeof(state[0].fxsave)) )
> +{
> +printf("fxsave differs!\n");
> +for ( i = 0;  i < sizeof(state[0].fxsave)/sizeof(unsigned); i++ )

Blanks around / again please.

> +{
> +printf("[%04lu] %08x %08x\n",

I think I've indicated before that I consider leading zeros on decimal
numbers misleading. Could I talk you into using %4lu instead (or
really %4zu, considering the expression type) in places like this one
(i.e. also in the earlier patch, where I notice only now the l -> z
conversion wasn't done consistently either)?

> +i * sizeof(unsigned), ((unsigned 
> *)[0].fxsave)[i], ((unsigned *)[1].fxsave)[i]);

Long line.

Jan

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

[Xen-devel] [xen-unstable-smoke test] 114421: trouble: blocked/broken/pass

2017-10-12 Thread osstest service owner 
flight 114421 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114421/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf  broken
 build-armhf   4 host-install(4)broken REGR. vs. 114299

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  cc08c73c8c1f5ba5ed0f8274548db6725e1c3157
baseline version:
 xen  3b40cfcd1a1912c2e4c4eb353dc77cbf35c63c3a

Last test of basis   114299  2017-10-10 21:02:54 Z1 days
Failing since114308  2017-10-10 23:01:10 Z1 days   16 attempts
Testing same since   114421  2017-10-12 14:02:25 Z0 days1 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Andre Przywara 
  Andrew Cooper 
  Boris Ostrovsky 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Meng Xu 
  Ross Lagerwall 
  Stefano Stabellini 
  Tim Deegan 
  Vitaly Kuznetsov 
  Volodymyr Babchuk 
  Wei Liu 
  Yi Sun 

jobs:
 build-amd64  pass
 build-armhf  broken  
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  blocked 
 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

broken-job build-armhf broken
broken-step build-armhf host-install(4)

Not pushing.

(No revision log; it would be 1466 lines long.)

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

Re: [Xen-devel] [PATCH v1 00/27] x86: PIE support and option to extend KASLR randomization

2017-10-12 Thread Thomas Garnier 
On Wed, Oct 11, 2017 at 2:34 PM, Tom Lendacky  wrote:
> On 10/11/2017 3:30 PM, Thomas Garnier wrote:
>> Changes:
>>   - patch v1:
>> - Simplify ftrace implementation.
>> - Use gcc mstack-protector-guard-reg=%gs with PIE when possible.
>>   - rfc v3:
>> - Use --emit-relocs instead of -pie to reduce dynamic relocation space on
>>   mapped memory. It also simplifies the relocation process.
>> - Move the start the module section next to the kernel. Remove the need 
>> for
>>   -mcmodel=large on modules. Extends module space from 1 to 2G maximum.
>> - Support for XEN PVH as 32-bit relocations can be ignored with
>>   --emit-relocs.
>> - Support for GOT relocations previously done automatically with -pie.
>> - Remove need for dynamic PLT in modules.
>> - Support dymamic GOT for modules.
>>   - rfc v2:
>> - Add support for global stack cookie while compiler default to fs 
>> without
>>   mcmodel=kernel
>> - Change patch 7 to correctly jump out of the identity mapping on kexec 
>> load
>>   preserve.
>>
>> These patches make the changes necessary to build the kernel as Position
>> Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below
>> the top 2G of the virtual address space. It allows to optionally extend the
>> KASLR randomization range from 1G to 3G.
>
> Hi Thomas,
>
> I've applied your patches so that I can verify that SME works with PIE.
> Unfortunately, I'm running into build warnings and errors when I enable
> PIE.
>
> With CONFIG_STACK_VALIDATION=y I receive lots of messages like this:
>
>   drivers/scsi/libfc/fc_exch.o: warning: objtool: fc_destroy_exch_mgr()+0x0: 
> call without frame pointer save/setup
>
> Disabling CONFIG_STACK_VALIDATION suppresses those.

I ran into that, I plan to fix it in the next iteration.

>
> But near the end of the build, I receive errors like this:
>
>   arch/x86/kernel/setup.o: In function `dump_kernel_offset':
>   .../arch/x86/kernel/setup.c:801:(.text+0x32): relocation truncated to fit: 
> R_X86_64_32S against symbol `_text' defined in .text section in .tmp_vmlinux1
>   .
>   . about 10 more of the above type messages
>   .
>   make: *** [vmlinux] Error 1
>   Error building kernel, exiting
>
> Are there any config options that should or should not be enabled when
> building with PIE enabled?  Is there a compiler requirement for PIE (I'm
> using gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5))?

I never ran into these ones and I tested compilers older and newer.
What was your exact configuration?

>
> Thanks,
> Tom
>
>>
>> Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler
>> changes, PIE support and KASLR in general. Thanks to Roland McGrath on his
>> feedback for using -pie versus --emit-relocs and details on compiler code
>> generation.
>>
>> The patches:
>>   - 1-3, 5-1#, 17-18: Change in assembly code to be PIE compliant.
>>   - 4: Add a new _ASM_GET_PTR macro to fetch a symbol address generically.
>>   - 14: Adapt percpu design to work correctly when PIE is enabled.
>>   - 15: Provide an option to default visibility to hidden except for key 
>> symbols.
>> It removes errors between compilation units.
>>   - 16: Adapt relocation tool to handle PIE binary correctly.
>>   - 19: Add support for global cookie.
>>   - 20: Support ftrace with PIE (used on Ubuntu config).
>>   - 21: Fix incorrect address marker on dump_pagetables.
>>   - 22: Add option to move the module section just after the kernel.
>>   - 23: Adapt module loading to support PIE with dynamic GOT.
>>   - 24: Make the GOT read-only.
>>   - 25: Add the CONFIG_X86_PIE option (off by default).
>>   - 26: Adapt relocation tool to generate a 64-bit relocation table.
>>   - 27: Add the CONFIG_RANDOMIZE_BASE_LARGE option to increase relocation 
>> range
>> from 1G to 3G (off by default).
>>
>> Performance/Size impact:
>>
>> Size of vmlinux (Default configuration):
>>   File size:
>>   - PIE disabled: +0.31%
>>   - PIE enabled: -3.210% (less relocations)
>>   .text section:
>>   - PIE disabled: +0.000644%
>>   - PIE enabled: +0.837%
>>
>> Size of vmlinux (Ubuntu configuration):
>>   File size:
>>   - PIE disabled: -0.201%
>>   - PIE enabled: -0.082%
>>   .text section:
>>   - PIE disabled: same
>>   - PIE enabled: +1.319%
>>
>> Size of vmlinux (Default configuration + ORC):
>>   File size:
>>   - PIE enabled: -3.167%
>>   .text section:
>>   - PIE enabled: +0.814%
>>
>> Size of vmlinux (Ubuntu configuration + ORC):
>>   File size:
>>   - PIE enabled: -3.167%
>>   .text section:
>>   - PIE enabled: +1.26%
>>
>> The size increase is mainly due to not having access to the 32-bit signed
>> relocation that can be used with mcmodel=kernel. A small part is due to 
>> reduced
>> optimization for PIE code. This bug [1] was opened with gcc to provide a 
>> better
>> code generation for kernel PIE.
>>
>> Hackbench (50% and 1600% on thread/process for pipe/sockets):
>>

Re: [Xen-devel] [PATCH 3/3] x86/mm: Consolidate all Xen L4 slot writing into init_xen_l4_slots()

2017-10-12 Thread Andrew Cooper 
On 12/10/17 16:08, Jan Beulich wrote:
 On 12.10.17 at 15:54,  wrote:
>> --- a/xen/arch/x86/mm/hap/hap.c
>> +++ b/xen/arch/x86/mm/hap/hap.c
>> @@ -391,41 +391,24 @@ int hap_set_allocation(struct domain *d, unsigned int 
>> pages, bool *preempted)
>>  return 0;
>>  }
>>  
>> -static void hap_install_xen_entries_in_l4(struct vcpu *v, mfn_t l4mfn)
>> -{
>> -struct domain *d = v->domain;
>> -l4_pgentry_t *l4e;
>> -
>> -l4e = map_domain_page(l4mfn);
>> -
>> -/* Copy the common Xen mappings from the idle domain */
>> -memcpy([ROOT_PAGETABLE_FIRST_XEN_SLOT],
>> -   _pg_table[ROOT_PAGETABLE_FIRST_XEN_SLOT],
>> -   ROOT_PAGETABLE_XEN_SLOTS * sizeof(l4_pgentry_t));
>> -
>> -/* Install the per-domain mappings for this domain */
>> -l4e[l4_table_offset(PERDOMAIN_VIRT_START)] =
>> -l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW);
>> -
>> -/* Install a linear mapping */
>> -l4e[l4_table_offset(LINEAR_PT_VIRT_START)] =
>> -l4e_from_mfn(l4mfn, __PAGE_HYPERVISOR_RW);
>> -
>> -unmap_domain_page(l4e);
>> -}
>> -
>>  static mfn_t hap_make_monitor_table(struct vcpu *v)
>>  {
>>  struct domain *d = v->domain;
>>  struct page_info *pg;
>> +l4_pgentry_t *l4e;
>>  mfn_t m4mfn;
>>  
>>  ASSERT(pagetable_get_pfn(v->arch.monitor_table) == 0);
>>  
>>  if ( (pg = hap_alloc(d)) == NULL )
>>  goto oom;
>> +
>>  m4mfn = page_to_mfn(pg);
>> -hap_install_xen_entries_in_l4(v, m4mfn);
>> +l4e = __map_domain_page(pg);
> If you obtain the MFN anyway, map_domain_page() is cheaper
> generated code wise.

Ah yes.  Given that __map_domain_page() is a define, I'd hope the
compiler can spot and optimise away the double page_to_mfn().

Either way, fixed.

>
>> --- a/xen/arch/x86/pv/domain.c
>> +++ b/xen/arch/x86/pv/domain.c
>> @@ -35,7 +35,7 @@ static int setup_compat_l4(struct vcpu *v)
>>  
>>  l4tab = __map_domain_page(pg);
>>  clear_page(l4tab);
>> -init_guest_l4_table(l4tab, v->domain, 1);
>> +init_xen_l4_slots(l4tab, page_to_mfn(pg), v->domain, INVALID_MFN, 
>> false);
> Perhaps worth avoiding the double translation here too.
>
> In any event
> Reviewed-by: Jan Beulich 

Just to confirm, the additional delta is:

andrewcoop@andrewcoop:/local/xen.git/xen$ git diff
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 1e7e8d0..41deb90 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -404,7 +404,7 @@ static mfn_t hap_make_monitor_table(struct vcpu *v)
 goto oom;
 
 m4mfn = page_to_mfn(pg);
-l4e = __map_domain_page(pg);
+l4e = map_domain_page(m4mfn);
 
 init_xen_l4_slots(l4e, m4mfn, d, INVALID_MFN, false);
 unmap_domain_page(l4e);
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index a242037..2fb1996 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -28,14 +28,16 @@ static int setup_compat_l4(struct vcpu *v)
 {
 struct page_info *pg;
 l4_pgentry_t *l4tab;
+mfn_t mfn;
 
 pg = alloc_domheap_page(v->domain, MEMF_no_owner);
 if ( pg == NULL )
 return -ENOMEM;
 
-l4tab = __map_domain_page(pg);
+mfn = page_to_mfn(pg);
+l4tab = map_domain_page(mfn);
 clear_page(l4tab);
-init_xen_l4_slots(l4tab, page_to_mfn(pg), v->domain, INVALID_MFN, false);
+init_xen_l4_slots(l4tab, mfn, v->domain, INVALID_MFN, false);
 unmap_domain_page(l4tab);
 
 /* This page needs to look like a pagetable so that it can be shadowed */


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

Re: [Xen-devel] [PATCH v4 10/12] fuzz/x86_emulate: Add --rerun option to try to track down instability

2017-10-12 Thread Jan Beulich 
>>> On 11.10.17 at 19:52,  wrote:
> @@ -884,20 +891,146 @@ int LLVMFuzzerInitialize(int *argc, char ***argv)
>  return 0;
>  }
>  
> -int LLVMFuzzerTestOneInput(const uint8_t *data_p, size_t size)
> +static void setup_fuzz_state(struct fuzz_state *state, const void *data_p, 
> size_t size)
>  {
> -struct fuzz_state state = {
> -.ops = all_fuzzer_ops,
> -};
> -struct x86_emulate_ctxt ctxt = {
> -.data = ,
> -.regs = ,
> -.addr_size = 8 * sizeof(void *),
> -.sp_size = 8 * sizeof(void *),
> -};
> +memset(state, 0, sizeof(*state));
> +state->corpus = data_p;
> +state->data_num = size;
> +}
> +
> +static int runtest(struct fuzz_state *state) {
>  int rc;
>  
> -if ( size <= fuzz_minimal_input_size() )
> +struct x86_emulate_ctxt *ctxt = >ctxt;

Please don't leave a blank line between declarations.

> +static void compare_states(struct fuzz_state state[2])
> +{
> +/* First zero any "internal" pointers */
> +state[0].corpus = state[1].corpus = NULL;
> +state[0].ctxt.data = state[1].ctxt.data = NULL;
> +state[0].ctxt.regs = state[1].ctxt.regs = NULL;
> +
> +if ( memcmp([0], [1], sizeof(struct fuzz_state)) )
> +{
> +unsigned int i;
> +
> +printf("State mismatch\n");
> +
> +for ( i = 0; i < ARRAY_SIZE(state[0].cr); i++ )
> +if ( state[0].cr[i] != state[1].cr[i] )
> +printf("cr[%u]: %lx != %lx\n",
> +   i, state[0].cr[i], state[1].cr[i]);
> +
> +for ( i = 0; i < ARRAY_SIZE(state[0].msr); i++ )
> +if ( state[0].msr[i] != state[1].msr[i] )
> +printf("msr[%u]: %lx != %lx\n",
> +   i, state[0].msr[i], state[1].msr[i]);
> +
> +for ( i = 0; i < ARRAY_SIZE(state[0].segments); i++ )
> +if ( memcmp([0].segments[i], [1].segments[i],
> +sizeof(state[0].segments[0])) )
> +printf("segments[%u]: [%x:%x:%x:%lx] != [%x:%x:%x:%lx]!\n", 
> i,
> +   (unsigned)state[0].segments[i].sel,
> +   (unsigned)state[0].segments[i].attr,
> +   state[0].segments[i].limit,
> +   state[0].segments[i].base,
> +   (unsigned)state[1].segments[i].sel,
> +   (unsigned)state[1].segments[i].attr,
> +   state[1].segments[i].limit,
> +   state[1].segments[i].base);
> +
> +if ( state[0].data_num != state[1].data_num )
> +printf("data_num: %lx !=  %lx\n", state[0].data_num,
> +   state[1].data_num);
> +if ( state[0].data_index != state[1].data_index )
> +printf("data_index: %lx !=  %lx\n", state[0].data_index,
> +   state[1].data_index);
> +
> +if ( memcmp([0].regs, [1].regs, sizeof(state[0].regs)) )
> +{
> +printf("registers differ!\n");
> +/* Print If Not Equal */
> +#define PRINT_NE(elem)\
> +if ( state[0].elem != state[1].elem ) \
> +printf(#elem " differ: %lx != %lx\n", \
> +   (unsigned long)state[0].elem, \
> +   (unsigned long)state[1].elem)
> +PRINT_NE(regs.r15);
> +PRINT_NE(regs.r14);
> +PRINT_NE(regs.r13);
> +PRINT_NE(regs.r12);
> +PRINT_NE(regs.rbp);
> +PRINT_NE(regs.rbx);
> +PRINT_NE(regs.r10);
> +PRINT_NE(regs.r11);
> +PRINT_NE(regs.r9);
> +PRINT_NE(regs.r8);
> +PRINT_NE(regs.rax);
> +PRINT_NE(regs.rcx);
> +PRINT_NE(regs.rdx);
> +PRINT_NE(regs.rsi);
> +PRINT_NE(regs.rdi);

Aren't these register fields all of the same type? If so, why do you
need to casts to unsigned long in the macro?

Additionally iirc Andrew had asked for eflags (and perhaps also
selector register values) to be printed separately for ease of
recognition - I support this request.

> +for ( i = offsetof(struct cpu_user_regs, error_code) / 
> sizeof(unsigned);
> +  i < sizeof(state[1].regs)/sizeof(unsigned); i++ )

Blanks around binary operators please (also elsewhere).

Jan

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

Re: [Xen-devel] [PATCH v4 08/12] fuzz/x86_emulate: Move all state into fuzz_state

2017-10-12 Thread Jan Beulich 
>>> On 11.10.17 at 19:52,  wrote:
> --- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
> +++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
> @@ -22,34 +22,31 @@
>  
>  #define SEG_NUM x86_seg_none
>  
> -/* Layout of data expected as fuzzing input. */
> -struct fuzz_corpus
> +/*
> + * State of the fuzzing harness and emulated cpu.  Calculated
> + * initially from the input corpus, and later mutated by the emulation
> + * callbacks (and the emulator itself, in the case of regs).
> + */
> +struct fuzz_state
>  {
> +/* Emulated CPU state */
> +unsigned long options;
>  unsigned long cr[5];
>  uint64_t msr[MSR_INDEX_MAX];
> -struct cpu_user_regs regs;
>  struct segment_register segments[SEG_NUM];
> -unsigned long options;
> -unsigned char data[INPUT_SIZE];
> -} input;
> -#define DATA_OFFSET offsetof(struct fuzz_corpus, data)
> +struct cpu_user_regs regs;
>  
> -/*
> - * Internal state of the fuzzing harness.  Calculated initially from the 
> input
> - * corpus, and later mutates by the emulation callbacks.
> - */
> -struct fuzz_state
> -{
>  /* Fuzzer's input data. */
> -struct fuzz_corpus *corpus;
> +#define DATA_OFFSET offsetof(struct fuzz_state, corpus)
> +const unsigned char * corpus;

Stray blank after *. Also any reason this can't be uint8_t,
matching LLVMFuzzerTestOneInput()'s parameter and making
it possible to avoid the cast you currently use on that
assignment?

> @@ -646,11 +634,20 @@ static void set_sizes(struct x86_emulate_ctxt *ctxt)
>  ctxt->addr_size = ctxt->sp_size = 64;
>  else
>  {
> -ctxt->addr_size = c->segments[x86_seg_cs].db ? 32 : 16;
> -ctxt->sp_size   = c->segments[x86_seg_ss].db ? 32 : 16;
> +ctxt->addr_size = s->segments[x86_seg_cs].db ? 32 : 16;
> +ctxt->sp_size   = s->segments[x86_seg_ss].db ? 32 : 16;
>  }
>  }
>  
> +static void setup_state(struct x86_emulate_ctxt *ctxt)
> +{
> +struct fuzz_state *s = ctxt->data;
> +
> +/* Fuzz all of the emulated state in one go */
> +if (!input_read(s, s, DATA_OFFSET))

Missing blanks.

> @@ -761,12 +757,11 @@ static void disable_hooks(struct x86_emulate_ctxt *ctxt)
>  static void sanitize_input(struct x86_emulate_ctxt *ctxt)
>  {
>  struct fuzz_state *s = ctxt->data;
> -struct fuzz_corpus *c = s->corpus;
> -struct cpu_user_regs *regs = >regs;
> -unsigned long bitmap = c->options;
> +struct cpu_user_regs *regs = ctxt->regs;
> +unsigned long bitmap = s->options;
>  
>  /* Some hooks can't be disabled. */
> -c->options &= ~((1< +s->options &= ~((1< @@ -834,10 +826,10 @@ int LLVMFuzzerTestOneInput(const uint8_t *data_p, 
> size_t size)
>  return 1;
>  }
>  
> -memcpy(, data_p, size);
> +state.corpus = (void*)data_p;

If for any reason the suggested type change can't or shouldn't be
done (and hence the cast needs to stay), then please add a blank
before * and don't cast away const-ness.

Jan


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

Re: [Xen-devel] [osstest test] 114342: regressions - trouble: blocked/broken/fail/pass

2017-10-12 Thread Roger Pau Monné 
On Thu, Oct 12, 2017 at 02:24:23PM +, Ian Jackson wrote:
> osstest service owner writes ("[osstest test] 114342: regressions - trouble: 
> blocked/broken/fail/pass"):
> > flight 114342 osstest real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/114342/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-armhf-armhf-xl-vhd  broken
> >  test-armhf-armhf-xl-vhd   4 host-install(4)broken REGR. vs. 
> > 114191
> >  test-armhf-armhf-examine  4 host-install   broken REGR. vs. 
> > 114191
> >  test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
> > 114191
> >  build-armhf-xsm   6 xen-buildfail REGR. vs. 
> > 114191
> 
> None of these are related to the only osstest patch under test,
> 
>  pvh: rename pvh tests to pvhv2
> 
> The armhf build failure looks like the armhf node crashing.
> 
> I have therefore force pushed this:
> 
> > version targeted for testing:
> >  osstest  2fe57c885d0290caf2d707893bb3bf3f5e8165f5

Thanks, hopefully this will unblock the branches stuck because of the
pvh "regression".

Roger.

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

Re: [Xen-devel] [PATCH 3/3] x86/mm: Consolidate all Xen L4 slot writing into init_xen_l4_slots()

2017-10-12 Thread Wei Liu 
On Thu, Oct 12, 2017 at 02:54:22PM +0100, Andrew Cooper wrote:
> There are currently three functions which write L4 pagetables for Xen, but
> they all behave subtly differently.  sh_install_xen_entries_in_l4() in
> particular is catering for two different usecases, which makes the safety of
> the linear mappings hard to follow.
> 
> By consolidating the L4 pagetable writing in a single function, the resulting
> setup of Xen's virtual layout is easier to understand.
> 
> No practical changes to the resulting L4, although the logic has been
> rearranged to avoid rewriting some slots.  This changes the zap_ro_mpt
> parameter to simply ro_mpt.
> 
> Both {hap,sh}_install_xen_entries_in_l4() get folded into their callers.  The
> hap side only a single caller, while the shadow side has two.  The shadow
> split helps highlight the correctness of the linear slots.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 3/3] x86/mm: Consolidate all Xen L4 slot writing into init_xen_l4_slots()

2017-10-12 Thread Jan Beulich 
>>> On 12.10.17 at 15:54,  wrote:
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -391,41 +391,24 @@ int hap_set_allocation(struct domain *d, unsigned int 
> pages, bool *preempted)
>  return 0;
>  }
>  
> -static void hap_install_xen_entries_in_l4(struct vcpu *v, mfn_t l4mfn)
> -{
> -struct domain *d = v->domain;
> -l4_pgentry_t *l4e;
> -
> -l4e = map_domain_page(l4mfn);
> -
> -/* Copy the common Xen mappings from the idle domain */
> -memcpy([ROOT_PAGETABLE_FIRST_XEN_SLOT],
> -   _pg_table[ROOT_PAGETABLE_FIRST_XEN_SLOT],
> -   ROOT_PAGETABLE_XEN_SLOTS * sizeof(l4_pgentry_t));
> -
> -/* Install the per-domain mappings for this domain */
> -l4e[l4_table_offset(PERDOMAIN_VIRT_START)] =
> -l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW);
> -
> -/* Install a linear mapping */
> -l4e[l4_table_offset(LINEAR_PT_VIRT_START)] =
> -l4e_from_mfn(l4mfn, __PAGE_HYPERVISOR_RW);
> -
> -unmap_domain_page(l4e);
> -}
> -
>  static mfn_t hap_make_monitor_table(struct vcpu *v)
>  {
>  struct domain *d = v->domain;
>  struct page_info *pg;
> +l4_pgentry_t *l4e;
>  mfn_t m4mfn;
>  
>  ASSERT(pagetable_get_pfn(v->arch.monitor_table) == 0);
>  
>  if ( (pg = hap_alloc(d)) == NULL )
>  goto oom;
> +
>  m4mfn = page_to_mfn(pg);
> -hap_install_xen_entries_in_l4(v, m4mfn);
> +l4e = __map_domain_page(pg);

If you obtain the MFN anyway, map_domain_page() is cheaper
generated code wise.

> --- a/xen/arch/x86/pv/domain.c
> +++ b/xen/arch/x86/pv/domain.c
> @@ -35,7 +35,7 @@ static int setup_compat_l4(struct vcpu *v)
>  
>  l4tab = __map_domain_page(pg);
>  clear_page(l4tab);
> -init_guest_l4_table(l4tab, v->domain, 1);
> +init_xen_l4_slots(l4tab, page_to_mfn(pg), v->domain, INVALID_MFN, false);

Perhaps worth avoiding the double translation here too.

In any event
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH 2/3] x86/mm: Consolidate all Xen L2 slot writing into init_xen_pae_l2_slots()

2017-10-12 Thread Wei Liu 
On Thu, Oct 12, 2017 at 02:54:21PM +0100, Andrew Cooper wrote:
> Having all of this logic together makes it easier to follow Xen's virtual
> setup across the whole system.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 2/3] x86/mm: Consolidate all Xen L2 slot writing into init_xen_pae_l2_slots()

2017-10-12 Thread Jan Beulich 
>>> On 12.10.17 at 15:54,  wrote:
> Having all of this logic together makes it easier to follow Xen's virtual
> setup across the whole system.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH 1/3] Revert "x86/mm: move PV l4 table setup code" and "x86/mm: factor out pv_arch_init_memory"

2017-10-12 Thread Jan Beulich 
>>> On 12.10.17 at 15:54,  wrote:
> This reverts commit f3b95fd07fdb55b1db091fede1b9a7c71f1eaa1b and
> 1bd39738a5a34f529a610fb275cc83ee5ac7547a.
> 
> The following patches (post XSA-243 fixes) requires init_guest_l4_table()
> being common code.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [RFC 3/6] Introduce _xrealloc

2017-10-12 Thread Wei Liu 
On Thu, Oct 12, 2017 at 02:33:04PM +0100, Julien Grall wrote:
> Hi,
> 
> Bringing back this discussion.
> 
> On 28/08/17 22:39, Goel, Sameer wrote:
> > 
> > 
> > On 6/9/2017 3:44 AM, Wei Liu wrote:
> > > On Thu, Jun 08, 2017 at 08:49:01PM +0100, Julien Grall wrote:
> > > > CC the REST maintainers
> > > > 
> > > > On 08/06/2017 20:30, Sameer Goel wrote:
> > > > > Introduce a memory realloc function.
> > > > > 
> > > > > Signed-off-by: Sameer Goel 
> > > > > ---
> > > > >   xen/common/xmalloc_tlsf.c | 13 +
> > > > >   xen/include/xen/xmalloc.h |  1 +
> > > > >   2 files changed, 14 insertions(+)
> > > > > 
> > > > > diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c
> > > > > index b256dc5..52385a8 100644
> > > > > --- a/xen/common/xmalloc_tlsf.c
> > > > > +++ b/xen/common/xmalloc_tlsf.c
> > > > > @@ -612,6 +612,19 @@ void *_xzalloc(unsigned long size, unsigned long 
> > > > > align)
> > > > >   return p ? memset(p, 0, size) : p;
> > > > >   }
> > > > > 
> > > > > +void *_xrealloc(void *p, unsigned long new_size, unsigned long align)
> > > > > +{
> > > > > +void *new_p = _xmalloc(new_size, align);
> > > > > +
> > > > > +if(new_p && p)
> > > > 
> > > > Coding style: if ( ... )
> > > > 
> > > > > +{
> > > > > +memcpy(new_p, p, new_size);
> > > 
> > > This is wrong. How can you know if the area pointed to by p is at least
> > > new_size bytes long?
> > > 
> > Agreed, I revisited the code and will remove _xrealloc and use xfree and 
> > _xmalloc instead.
> 
> I am not sure why you choose to drop it completely. xfree is able to know
> the size of the buffer to free.
> 
> So you could find out the size and copy the right amount of data.
> 
> Note that having _xrealloc would be my preference over an open-coded version
> in the code.

I would vouch for a properly implemented _xrealloc. :-)

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

Re: [Xen-devel] [PATCH 1/3] Revert "x86/mm: move PV l4 table setup code" and "x86/mm: factor out pv_arch_init_memory"

2017-10-12 Thread Wei Liu 
On Thu, Oct 12, 2017 at 02:54:20PM +0100, Andrew Cooper wrote:
> This reverts commit f3b95fd07fdb55b1db091fede1b9a7c71f1eaa1b and
> 1bd39738a5a34f529a610fb275cc83ee5ac7547a.
> 
> The following patches (post XSA-243 fixes) requires init_guest_l4_table()
> being common code.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v4 0/5] Towards work-conserving RTDS

2017-10-12 Thread Meng Xu 
On Thu, Oct 12, 2017 at 5:02 AM, Wei Liu  wrote:
>
> FYI all patches except the xentrace one were committed yesterday.


Thank you very much, Wei!

Best,

Meng

-- 
Meng Xu
Ph.D. Candidate in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [osstest test] 114342: regressions - trouble: blocked/broken/fail/pass

2017-10-12 Thread Ian Jackson 
osstest service owner writes ("[osstest test] 114342: regressions - trouble: 
blocked/broken/fail/pass"):
> flight 114342 osstest real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/114342/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-armhf-armhf-xl-vhd  broken
>  test-armhf-armhf-xl-vhd   4 host-install(4)broken REGR. vs. 
> 114191
>  test-armhf-armhf-examine  4 host-install   broken REGR. vs. 
> 114191
>  test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
> 114191
>  build-armhf-xsm   6 xen-buildfail REGR. vs. 
> 114191

None of these are related to the only osstest patch under test,

 pvh: rename pvh tests to pvhv2

The armhf build failure looks like the armhf node crashing.

I have therefore force pushed this:

> version targeted for testing:
>  osstest  2fe57c885d0290caf2d707893bb3bf3f5e8165f5

Ian.

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

Re: [Xen-devel] [RFC v2 5/7] acpi:arm64: Add support for parsing IORT table

2017-10-12 Thread Julien Grall 

Hi Sameer,

On 21/09/17 01:37, Sameer Goel wrote:

@@ -583,14 +631,13 @@ const struct iommu_ops *iort_iommu_configure(struct 
device *dev)
u32 streamid = 0;
  
  	if (dev_is_pci(dev)) {

-   struct pci_bus *bus = to_pci_dev(dev)->bus;
+   struct pci_dev *pci_device = to_pci_dev(dev);
u32 rid;
  
-		pci_for_each_dma_alias(to_pci_dev(dev), __get_pci_rid,

-  );
+   rid = PCI_BDF2(pci_device->bus, pci_device->devfn);


I forgot to answer on this bit. On the previous it was mentioned this 
was wrong, but still there.


Whilst I can understand that implementing pci_for_each_dma_alias could 
require some work in Xen, I don't want to see rid = PCI_BDF2(...) 
spreading the code. So what's the plan?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC v2 5/7] acpi:arm64: Add support for parsing IORT table

2017-10-12 Thread Julien Grall 

Hi Sameer,

On 21/09/17 01:37, Sameer Goel wrote:

Add support for parsing IORT table to initialize SMMU devices.
* The code for creating an SMMU device has been modified, so that the SMMU
device can be initialized.
* The NAMED NODE code has been commented out as this will need DOM0 kernel
support.
* ITS code has been included but it has not been tested.

Signed-off-by: Sameer Goel 
---
  xen/arch/arm/setup.c   |   3 +
  xen/drivers/acpi/Makefile  |   1 +
  xen/drivers/acpi/arm/Makefile  |   1 +
  xen/drivers/acpi/arm/iort.c| 173 +
  xen/drivers/passthrough/arm/smmu.c |   1 +
  xen/include/acpi/acpi_iort.h   |  17 ++--
  xen/include/asm-arm/device.h   |   2 +
  xen/include/xen/acpi.h |  21 +
  xen/include/xen/pci.h  |   8 ++
  9 files changed, 146 insertions(+), 81 deletions(-)
  create mode 100644 xen/drivers/acpi/arm/Makefile

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 92f173b..4ba09b2 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -49,6 +49,7 @@
  #include 
  #include 
  #include 
+#include 
  
  struct bootinfo __initdata bootinfo;
  
@@ -796,6 +797,8 @@ void __init start_xen(unsigned long boot_phys_offset,
  
  tasklet_subsys_init();
  
+/* Parse the ACPI iort data */

+acpi_iort_init();
  
  xsm_dt_init();
  
diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile

index 444b11d..e7ffd82 100644
--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -1,5 +1,6 @@
  subdir-y += tables
  subdir-y += utilities
+subdir-$(CONFIG_ARM) += arm
  subdir-$(CONFIG_X86) += apei
  
  obj-bin-y += tables.init.o

diff --git a/xen/drivers/acpi/arm/Makefile b/xen/drivers/acpi/arm/Makefile
new file mode 100644
index 000..7c039bb
--- /dev/null
+++ b/xen/drivers/acpi/arm/Makefile
@@ -0,0 +1 @@
+obj-y += iort.o
diff --git a/xen/drivers/acpi/arm/iort.c b/xen/drivers/acpi/arm/iort.c
index 2e368a6..7f54062 100644
--- a/xen/drivers/acpi/arm/iort.c
+++ b/xen/drivers/acpi/arm/iort.c
@@ -14,17 +14,47 @@
   * This file implements early detection/parsing of I/O mapping
   * reported to OS through firmware via I/O Remapping Table (IORT)
   * IORT document number: ARM DEN 0049A
+ *
+ * Based on Linux drivers/acpi/arm64/iort.c
+ * => commit ca78d3173cff3503bcd15723b049757f75762d15
+ *
+ * Xen modification:
+ * Sameer Goel 
+ * Copyright (C) 2017, The Linux Foundation, All rights reserved.
+ *
   */
  
-#define pr_fmt(fmt)	"ACPI: IORT: " fmt

-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 


Why do you need to include there? Can't this be done after all the  ?


+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* Xen: Define compatibility functions */
+#define FW_BUG "[Firmware Bug]: "
+#define pr_err(fmt, ...) printk(XENLOG_ERR fmt, ## __VA_ARGS__)
+#define pr_warn(fmt, ...) printk(XENLOG_WARNING fmt, ## __VA_ARGS__)
+
+/* Alias to Xen allocation helpers */
+#define kfree xfree
+#define kmalloc(size, flags)_xmalloc(size, sizeof(void *))
+#define kzalloc(size, flags)_xzalloc(size, sizeof(void *))


Likely you would need the same macros in the SMMUv3 driver. Could we 
think of a common headers implementing the Linux compat layer?



+
+/* Redefine WARN macros */
+#undef WARN
+#undef WARN_ON
+#define WARN(condition, format...) ({  \
+   int __ret_warn_on = !!(condition);  \
+   if (unlikely(__ret_warn_on))\
+   printk(format); \
+   unlikely(__ret_warn_on);\
+})


Again, you should at least try to modify the common code version before 
deciding to redefine it here.



+#define WARN_TAINT(cond, taint, format...) WARN(cond, format)
+#define WARN_ON(cond)  (!!cond)
  
  #define IORT_TYPE_MASK(type)	(1 << (type))

  #define IORT_MSI_TYPE (1 << ACPI_IORT_NODE_ITS_GROUP)
@@ -256,6 +286,13 @@ static acpi_status iort_match_node_callback(struct 
acpi_iort_node *node,
acpi_status status;
  
  	if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT) {

+   status = AE_NOT_IMPLEMENTED;
+/*
+ * We need the namespace object name from dsdt to match the iort node, this


Please add a "Xen: TODO:" in front.


+ * will need additions to the kernel xen bus notifiers.
+ * So, disabling the named node code till a proposal is approved.
+ */
+#if 0
struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER, NULL };
struct acpi_device *adev = to_acpi_device_node(dev->fwnode);
struct acpi_iort_named_component *ncomp;
@@ -275,11 +312,12 @@ static acpi_status iort_match_node_callback(struct 
acpi_iort_node *node,
status =

[Xen-devel] [PATCH 3/3] x86/mm: Consolidate all Xen L4 slot writing into init_xen_l4_slots()

2017-10-12 Thread Andrew Cooper 
There are currently three functions which write L4 pagetables for Xen, but
they all behave subtly differently.  sh_install_xen_entries_in_l4() in
particular is catering for two different usecases, which makes the safety of
the linear mappings hard to follow.

By consolidating the L4 pagetable writing in a single function, the resulting
setup of Xen's virtual layout is easier to understand.

No practical changes to the resulting L4, although the logic has been
rearranged to avoid rewriting some slots.  This changes the zap_ro_mpt
parameter to simply ro_mpt.

Both {hap,sh}_install_xen_entries_in_l4() get folded into their callers.  The
hap side only a single caller, while the shadow side has two.  The shadow
split helps highlight the correctness of the linear slots.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Tim Deegan 
CC: George Dunlap 
CC: Wei Liu 
CC: Julien Grall 
---
 xen/arch/x86/mm.c  |  87 +
 xen/arch/x86/mm/hap/hap.c  |  31 +++-
 xen/arch/x86/mm/shadow/multi.c | 106 ++---
 xen/arch/x86/pv/dom0_build.c   |   3 +-
 xen/arch/x86/pv/domain.c   |   2 +-
 xen/include/asm-x86/mm.h   |   4 +-
 6 files changed, 105 insertions(+), 128 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index ea4af16..5097958 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1521,37 +1521,85 @@ void init_xen_pae_l2_slots(l2_pgentry_t *l2t, const 
struct domain *d)
 }
 
 /*
+ * Fill an L4 with Xen entries.
+ *
  * This function must write all ROOT_PAGETABLE_PV_XEN_SLOTS, to clobber any
  * values a guest may have left there from alloc_l4_table().
+ *
+ * l4t and l4mfn are mandatory, but l4mfn doesn't need to be the mfn under
+ * *l4t.  All other parameters are optional and will either fill or zero the
+ * appropriate slots.  Pagetables not shared with guests will gain the
+ * extended directmap.
  */
-void init_guest_l4_table(l4_pgentry_t l4tab[], const struct domain *d,
- bool zap_ro_mpt)
+void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn,
+   const struct domain *d, mfn_t sl4mfn, bool ro_mpt)
 {
-/* Xen private mappings. */
-memcpy([ROOT_PAGETABLE_FIRST_XEN_SLOT],
-   _pg_table[ROOT_PAGETABLE_FIRST_XEN_SLOT],
-   root_pgt_pv_xen_slots * sizeof(l4_pgentry_t));
+/*
+ * PV vcpus need a shortened directmap.  HVM and Idle vcpus get the full
+ * directmap.
+ */
+bool short_directmap = d && !paging_mode_external(d);
+
+/* Slot 256: RO M2P (if applicable). */
+l4t[l4_table_offset(RO_MPT_VIRT_START)] =
+ro_mpt ? idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)]
+   : l4e_empty();
+
+/* Slot 257: PCI MMCFG. */
+l4t[l4_table_offset(PCI_MCFG_VIRT_START)] =
+idle_pg_table[l4_table_offset(PCI_MCFG_VIRT_START)];
+
+/* Slot 258: Self linear mappings. */
+ASSERT(!mfn_eq(l4mfn, INVALID_MFN));
+l4t[l4_table_offset(LINEAR_PT_VIRT_START)] =
+l4e_from_mfn(l4mfn, __PAGE_HYPERVISOR_RW);
+
+/* Slot 259: Shadow linear mappings (if applicable) .*/
+l4t[l4_table_offset(SH_LINEAR_PT_VIRT_START)] =
+mfn_eq(sl4mfn, INVALID_MFN) ? l4e_empty() :
+l4e_from_mfn(sl4mfn, __PAGE_HYPERVISOR_RW);
+
+/* Slot 260: Per-domain mappings (if applicable). */
+l4t[l4_table_offset(PERDOMAIN_VIRT_START)] =
+d ? l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW)
+  : l4e_empty();
+
+/* Slot 261-: text/data/bss, RW M2P, vmap, frametable, directmap. */
 #ifndef NDEBUG
-if ( unlikely(root_pgt_pv_xen_slots < ROOT_PAGETABLE_PV_XEN_SLOTS) )
+if ( short_directmap &&
+ unlikely(root_pgt_pv_xen_slots < ROOT_PAGETABLE_PV_XEN_SLOTS) )
 {
-l4_pgentry_t *next = [ROOT_PAGETABLE_FIRST_XEN_SLOT +
-root_pgt_pv_xen_slots];
+/*
+ * If using highmem-start=, artificially shorten the directmap to
+ * simulate very large machines.
+ */
+l4_pgentry_t *next;
+
+memcpy([l4_table_offset(XEN_VIRT_START)],
+   _pg_table[l4_table_offset(XEN_VIRT_START)],
+   (ROOT_PAGETABLE_FIRST_XEN_SLOT + root_pgt_pv_xen_slots -
+l4_table_offset(XEN_VIRT_START)) * sizeof(*l4t));
+
+next = [ROOT_PAGETABLE_FIRST_XEN_SLOT + root_pgt_pv_xen_slots];
 
 if ( l4e_get_intpte(split_l4e) )
 *next++ = split_l4e;
 
 memset(next, 0,
-   _p([ROOT_PAGETABLE_LAST_XEN_SLOT + 1]) - _p(next));
+   _p([ROOT_PAGETABLE_LAST_XEN_SLOT + 1]) - _p(next));
 }
-#else
-BUILD_BUG_ON(root_pgt_pv_xen_slots != ROOT_PAGETABLE_PV_XEN_SLOTS);
+else
 #endif
-l4tab[l4_table_offset(LINEAR_PT_VIRT_START)] =
-

[Xen-devel] [PATCH 1/3] Revert "x86/mm: move PV l4 table setup code" and "x86/mm: factor out pv_arch_init_memory"

2017-10-12 Thread Andrew Cooper 
This reverts commit f3b95fd07fdb55b1db091fede1b9a7c71f1eaa1b and
1bd39738a5a34f529a610fb275cc83ee5ac7547a.

The following patches (post XSA-243 fixes) requires init_guest_l4_table()
being common code.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Julien Grall 

These pagetable fixes have been pending for longer than the mm cleanup being
reverted here.  Had I been in the office when these patches were proposed, I
would have quietly arranged for them not to be committed.
---
 xen/arch/x86/mm.c| 77 +++--
 xen/arch/x86/pv/dom0_build.c |  2 --
 xen/arch/x86/pv/domain.c |  5 ---
 xen/arch/x86/pv/mm.c | 82 
 xen/arch/x86/pv/mm.h |  3 --
 xen/include/asm-x86/mm.h |  2 ++
 xen/include/asm-x86/pv/mm.h  |  4 ---
 7 files changed, 77 insertions(+), 98 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 5628bc7..f90a42a 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -125,7 +125,6 @@
 
 #include 
 #include 
-#include 
 
 #include "pv/mm.h"
 
@@ -243,6 +242,14 @@ void __init init_frametable(void)
 memset(end_pg, -1, (unsigned long)top_pg - (unsigned long)end_pg);
 }
 
+#ifndef NDEBUG
+static unsigned int __read_mostly root_pgt_pv_xen_slots
+= ROOT_PAGETABLE_PV_XEN_SLOTS;
+static l4_pgentry_t __read_mostly split_l4e;
+#else
+#define root_pgt_pv_xen_slots ROOT_PAGETABLE_PV_XEN_SLOTS
+#endif
+
 void __init arch_init_memory(void)
 {
 unsigned long i, pfn, rstart_pfn, rend_pfn, iostart_pfn, ioend_pfn;
@@ -338,7 +345,39 @@ void __init arch_init_memory(void)
 
 mem_sharing_init();
 
-pv_arch_init_memory();
+#ifndef NDEBUG
+if ( highmem_start )
+{
+unsigned long split_va = (unsigned long)__va(highmem_start);
+
+if ( split_va < HYPERVISOR_VIRT_END &&
+ split_va - 1 == (unsigned long)__va(highmem_start - 1) )
+{
+root_pgt_pv_xen_slots = l4_table_offset(split_va) -
+ROOT_PAGETABLE_FIRST_XEN_SLOT;
+ASSERT(root_pgt_pv_xen_slots < ROOT_PAGETABLE_PV_XEN_SLOTS);
+if ( l4_table_offset(split_va) == l4_table_offset(split_va - 1) )
+{
+l3_pgentry_t *l3tab = alloc_xen_pagetable();
+
+if ( l3tab )
+{
+const l3_pgentry_t *l3idle =
+l4e_to_l3e(idle_pg_table[l4_table_offset(split_va)]);
+
+for ( i = 0; i < l3_table_offset(split_va); ++i )
+l3tab[i] = l3idle[i];
+for ( ; i < L3_PAGETABLE_ENTRIES; ++i )
+l3tab[i] = l3e_empty();
+split_l4e = l4e_from_pfn(virt_to_mfn(l3tab),
+ __PAGE_HYPERVISOR_RW);
+}
+else
+++root_pgt_pv_xen_slots;
+}
+}
+}
+#endif
 }
 
 int page_is_ram_type(unsigned long mfn, unsigned long mem_type)
@@ -1479,6 +1518,40 @@ static int alloc_l3_table(struct page_info *page)
 return rc > 0 ? 0 : rc;
 }
 
+/*
+ * This function must write all ROOT_PAGETABLE_PV_XEN_SLOTS, to clobber any
+ * values a guest may have left there from alloc_l4_table().
+ */
+void init_guest_l4_table(l4_pgentry_t l4tab[], const struct domain *d,
+ bool zap_ro_mpt)
+{
+/* Xen private mappings. */
+memcpy([ROOT_PAGETABLE_FIRST_XEN_SLOT],
+   _pg_table[ROOT_PAGETABLE_FIRST_XEN_SLOT],
+   root_pgt_pv_xen_slots * sizeof(l4_pgentry_t));
+#ifndef NDEBUG
+if ( unlikely(root_pgt_pv_xen_slots < ROOT_PAGETABLE_PV_XEN_SLOTS) )
+{
+l4_pgentry_t *next = [ROOT_PAGETABLE_FIRST_XEN_SLOT +
+root_pgt_pv_xen_slots];
+
+if ( l4e_get_intpte(split_l4e) )
+*next++ = split_l4e;
+
+memset(next, 0,
+   _p([ROOT_PAGETABLE_LAST_XEN_SLOT + 1]) - _p(next));
+}
+#else
+BUILD_BUG_ON(root_pgt_pv_xen_slots != ROOT_PAGETABLE_PV_XEN_SLOTS);
+#endif
+l4tab[l4_table_offset(LINEAR_PT_VIRT_START)] =
+l4e_from_pfn(domain_page_map_to_mfn(l4tab), __PAGE_HYPERVISOR_RW);
+l4tab[l4_table_offset(PERDOMAIN_VIRT_START)] =
+l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW);
+if ( zap_ro_mpt || is_pv_32bit_domain(d) )
+l4tab[l4_table_offset(RO_MPT_VIRT_START)] = l4e_empty();
+}
+
 bool fill_ro_mpt(mfn_t mfn)
 {
 l4_pgentry_t *l4tab = map_domain_page(mfn);
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index dcbee43..ec7f96d 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -20,8 +20,6 @@
 #include 
 #include 
 
-#include "mm.h"
-
 /* Allow ring-3 access in long mode as guest cannot use ring 1 ... */
 #define BASE_PROT

[Xen-devel] [PATCH for 4.10 0/3] XSA-243 followup

2017-10-12 Thread Andrew Cooper 
The important change here is in patch 3, which is intended to remove the
correct-but-dangerous-looking construction of linear pagetables slots for
shadowed guests.

Andrew Cooper (3):
  Revert "x86/mm: move PV l4 table setup code" and "x86/mm: factor out
pv_arch_init_memory"
  x86/mm: Consolidate all Xen L2 slot writing into
init_xen_pae_l2_slots()
  x86/mm: Consolidate all Xen L4 slot writing into init_xen_l4_slots()

 xen/arch/x86/mm.c  | 144 ---
 xen/arch/x86/mm/hap/hap.c  |  31 ++---
 xen/arch/x86/mm/shadow/multi.c | 148 +++--
 xen/arch/x86/pv/dom0_build.c   |   5 +-
 xen/arch/x86/pv/domain.c   |   7 +-
 xen/arch/x86/pv/mm.c   |  82 ---
 xen/arch/x86/pv/mm.h   |   3 -
 xen/include/asm-x86/mm.h   |   3 +
 xen/include/asm-x86/pv/mm.h|   4 --
 9 files changed, 187 insertions(+), 240 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH 2/3] x86/mm: Consolidate all Xen L2 slot writing into init_xen_pae_l2_slots()

2017-10-12 Thread Andrew Cooper 
Having all of this logic together makes it easier to follow Xen's virtual
setup across the whole system.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Tim Deegan 
CC: George Dunlap 
CC: Wei Liu 
CC: Julien Grall 
---
 xen/arch/x86/mm.c  | 16 +---
 xen/arch/x86/mm/shadow/multi.c | 42 +++---
 xen/include/asm-x86/mm.h   |  1 +
 3 files changed, 25 insertions(+), 34 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index f90a42a..ea4af16 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1433,13 +1433,7 @@ static int alloc_l2_table(struct page_info *page, 
unsigned long type,
 }
 
 if ( rc >= 0 && (type & PGT_pae_xen_l2) )
-{
-/* Xen private mappings. */
-memcpy([COMPAT_L2_PAGETABLE_FIRST_XEN_SLOT(d)],
-   _idle_pg_table_l2[
-   l2_table_offset(HIRO_COMPAT_MPT_VIRT_START)],
-   COMPAT_L2_PAGETABLE_XEN_SLOTS(d) * sizeof(*pl2e));
-}
+init_xen_pae_l2_slots(pl2e, d);
 
 unmap_domain_page(pl2e);
 return rc > 0 ? 0 : rc;
@@ -1518,6 +1512,14 @@ static int alloc_l3_table(struct page_info *page)
 return rc > 0 ? 0 : rc;
 }
 
+void init_xen_pae_l2_slots(l2_pgentry_t *l2t, const struct domain *d)
+{
+memcpy([COMPAT_L2_PAGETABLE_FIRST_XEN_SLOT(d)],
+   _idle_pg_table_l2[
+   l2_table_offset(HIRO_COMPAT_MPT_VIRT_START)],
+   COMPAT_L2_PAGETABLE_XEN_SLOTS(d) * sizeof(*l2t));
+}
+
 /*
  * This function must write all ROOT_PAGETABLE_PV_XEN_SLOTS, to clobber any
  * values a guest may have left there from alloc_l4_table().
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index d540af1..1b76e0c 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -1521,31 +1521,6 @@ void sh_install_xen_entries_in_l4(struct domain *d, 
mfn_t gl4mfn, mfn_t sl4mfn)
 }
 #endif
 
-#if GUEST_PAGING_LEVELS >= 3
-// For 3-on-3 PV guests, we need to make sure the xen mappings are in
-// place, which means that we need to populate the l2h entry in the l3
-// table.
-
-static void sh_install_xen_entries_in_l2h(struct domain *d, mfn_t sl2hmfn)
-{
-shadow_l2e_t *sl2e;
-
-if ( !is_pv_32bit_domain(d) )
-return;
-
-sl2e = map_domain_page(sl2hmfn);
-BUILD_BUG_ON(sizeof (l2_pgentry_t) != sizeof (shadow_l2e_t));
-
-/* Copy the common Xen mappings from the idle domain */
-memcpy(
-[COMPAT_L2_PAGETABLE_FIRST_XEN_SLOT(d)],
-_idle_pg_table_l2[l2_table_offset(HIRO_COMPAT_MPT_VIRT_START)],
-COMPAT_L2_PAGETABLE_XEN_SLOTS(d) * sizeof(*sl2e));
-
-unmap_domain_page(sl2e);
-}
-#endif
-
 
 /**/
 /* Create a shadow of a given guest page.
@@ -1610,7 +1585,14 @@ sh_make_shadow(struct vcpu *v, mfn_t gmfn, u32 
shadow_type)
 #endif
 #if GUEST_PAGING_LEVELS >= 3
 case SH_type_l2h_shadow:
-sh_install_xen_entries_in_l2h(v->domain, smfn);
+BUILD_BUG_ON(sizeof(l2_pgentry_t) != sizeof(shadow_l2e_t));
+if ( is_pv_32bit_domain(d) )
+{
+shadow_l2e_t *l2t = map_domain_page(smfn);
+
+init_xen_pae_l2_slots(l2t, d);
+unmap_domain_page(l2t);
+}
 break;
 #endif
 default: /* Do nothing */ break;
@@ -1677,6 +1659,8 @@ sh_make_monitor_table(struct vcpu *v)
 
 if ( is_pv_32bit_domain(d) )
 {
+l2_pgentry_t *l2t;
+
 /* For 32-bit PV guests, we need to map the 32-bit Xen
  * area into its usual VAs in the monitor tables */
 m3mfn = shadow_alloc(d, SH_type_monitor_table, 0);
@@ -1687,7 +1671,11 @@ sh_make_monitor_table(struct vcpu *v)
 mfn_to_page(m2mfn)->shadow_flags = 2;
 l3e = map_domain_page(m3mfn);
 l3e[3] = l3e_from_mfn(m2mfn, _PAGE_PRESENT);
-sh_install_xen_entries_in_l2h(d, m2mfn);
+
+l2t = map_domain_page(m2mfn);
+init_xen_pae_l2_slots(l2t, d);
+unmap_domain_page(l2t);
+
 unmap_domain_page(l3e);
 }
 
diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h
index eeac4d7..da3c5e2 100644
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -340,6 +340,7 @@ static inline void *__page_to_virt(const struct page_info 
*pg)
 int free_page_type(struct page_info *page, unsigned long type,
int preemptible);
 
+void init_xen_pae_l2_slots(l2_pgentry_t *l2t, const struct domain *d);
 void init_guest_l4_table(l4_pgentry_t[], const struct domain *,
  bool_t zap_ro_mpt);
 bool fill_ro_mpt(mfn_t mfn);
-- 
2.1.4

[Xen-devel] [xen-unstable-smoke test] 114418: regressions - FAIL

2017-10-12 Thread osstest service owner 
flight 114418 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114418/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 12 guest-start  fail REGR. vs. 114299

Tests which did not succeed, but are not blocking:
 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  c4e365a0eb3cb6c9dedfaf0c13b0a2ce62f49cf6
baseline version:
 xen  3b40cfcd1a1912c2e4c4eb353dc77cbf35c63c3a

Last test of basis   114299  2017-10-10 21:02:54 Z1 days
Failing since114308  2017-10-10 23:01:10 Z1 days   15 attempts
Testing same since   114376  2017-10-11 23:01:15 Z0 days6 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Andre Przywara 
  Andrew Cooper 
  Boris Ostrovsky 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Meng Xu 
  Ross Lagerwall 
  Stefano Stabellini 
  Volodymyr Babchuk 
  Wei Liu 
  Yi Sun 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt fail



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

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

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

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


Not pushing.

(No revision log; it would be 1175 lines long.)

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

Re: [Xen-devel] [RFC v2 3/7] xen/passthrough/arm: Introduce iommu_fwspec

2017-10-12 Thread Julien Grall 

Hi,

On 12/10/17 14:05, Julien Grall wrote:

Hi,

On 21/09/17 01:37, Sameer Goel wrote:

Introduce a common structure to hold the fw (ACPI or DT) defined
configuration for SMMU hw. The current use case is for arm SMMUs. So,
making this architecture specific.

Based on Linux kernel commit 57f98d2f61e1: iommu: Introduce iommu_fwspec
Signed-off-by: Sameer Goel 
---
  xen/drivers/passthrough/arm/iommu.c | 66 
+

  xen/include/asm-arm/device.h    |  1 +
  xen/include/xen/iommu.h | 29 
  3 files changed, 96 insertions(+)

diff --git a/xen/drivers/passthrough/arm/iommu.c 
b/xen/drivers/passthrough/arm/iommu.c

index 95b1abb..41c6497 100644
--- a/xen/drivers/passthrough/arm/iommu.c
+++ b/xen/drivers/passthrough/arm/iommu.c
@@ -73,3 +73,69 @@ int arch_iommu_populate_page_table(struct domain *d)
  /* The IOMMU shares the p2m with the CPU */
  return -ENOSYS;
  }
+
+const struct iommu_ops *iommu_ops_from_fwnode(struct fwnode_handle 
*fwnode)

+{
+    return iommu_get_ops();


Can you please add a comment explain why you always return iommu_get_ops()?

Would it be possible that the device is not behind an IOMMU?


+}
+
+int iommu_fwspec_init(struct device *dev, struct fwnode_handle 
*iommu_fwnode,

+    const struct iommu_ops *ops)
+{
+    struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+
+    if ( fwspec )
+    return ops == fwspec->ops ? 0 : -EINVAL;
+
+    fwspec = _xzalloc(sizeof(struct iommu_fwspec), sizeof(void *));


On the previous version this was xzalloc(struct iommu_fwspec), why?

I also don't understand the align on sizeof(void *).


+    if ( !fwspec )
+    return -ENOMEM;
+
+    fwspec->iommu_fwnode = iommu_fwnode;
+    fwspec->ops = ops;
+    dev->iommu_fwspec = fwspec;
+
+    return 0;
+}
+
+void iommu_fwspec_free(struct device *dev)
+{
+    struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+
+    if ( fwspec )
+    {


Linux is dropping the reference on the iommu_fwnode. Are we never 
expecting to take reference on the it in Xen?



+    xfree(fwspec);
+    dev->iommu_fwspec = NULL;
+    }
+}
+
+int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids)
+{
+    struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+    struct iommu_fwspec *fwspec_n = NULL;
+    size_t size, size_n;
+    int i;
+
+    if ( !fwspec )
+    return -EINVAL;
+
+    size = offsetof(struct iommu_fwspec, ids[fwspec->num_ids]);
+    size_n = offsetof(struct iommu_fwspec, ids[fwspec->num_ids + 
num_ids]);

+    if ( size_n > size )
+    { > +    fwspec_n = _xzalloc(size_n, sizeof(void *));


Same question about _xzalloc() here.


Also, please see the comment I just made on "[RFC 3/6] Introduce _xrealloc".

I would prefer to explore the possibility of a generic helper rather 
than open-coding it. I think we have enough information in hand to get 
the size of the old region.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC 3/6] Introduce _xrealloc

2017-10-12 Thread Julien Grall 

Hi,

Bringing back this discussion.

On 28/08/17 22:39, Goel, Sameer wrote:



On 6/9/2017 3:44 AM, Wei Liu wrote:

On Thu, Jun 08, 2017 at 08:49:01PM +0100, Julien Grall wrote:

CC the REST maintainers

On 08/06/2017 20:30, Sameer Goel wrote:

Introduce a memory realloc function.

Signed-off-by: Sameer Goel 
---
  xen/common/xmalloc_tlsf.c | 13 +
  xen/include/xen/xmalloc.h |  1 +
  2 files changed, 14 insertions(+)

diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c
index b256dc5..52385a8 100644
--- a/xen/common/xmalloc_tlsf.c
+++ b/xen/common/xmalloc_tlsf.c
@@ -612,6 +612,19 @@ void *_xzalloc(unsigned long size, unsigned long align)
  return p ? memset(p, 0, size) : p;
  }

+void *_xrealloc(void *p, unsigned long new_size, unsigned long align)
+{
+void *new_p = _xmalloc(new_size, align);
+
+if(new_p && p)


Coding style: if ( ... )


+{
+memcpy(new_p, p, new_size);


This is wrong. How can you know if the area pointed to by p is at least
new_size bytes long?


Agreed, I revisited the code and will remove _xrealloc and use xfree and 
_xmalloc instead.


I am not sure why you choose to drop it completely. xfree is able to 
know the size of the buffer to free.


So you could find out the size and copy the right amount of data.

Note that having _xrealloc would be my preference over an open-coded 
version in the code.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC v2 3/7] xen/passthrough/arm: Introduce iommu_fwspec

2017-10-12 Thread Julien Grall 

Hi,

On 21/09/17 01:37, Sameer Goel wrote:

Introduce a common structure to hold the fw (ACPI or DT) defined
configuration for SMMU hw. The current use case is for arm SMMUs. So,
making this architecture specific.

Based on Linux kernel commit 57f98d2f61e1: iommu: Introduce iommu_fwspec
Signed-off-by: Sameer Goel 
---
  xen/drivers/passthrough/arm/iommu.c | 66 +
  xen/include/asm-arm/device.h|  1 +
  xen/include/xen/iommu.h | 29 
  3 files changed, 96 insertions(+)

diff --git a/xen/drivers/passthrough/arm/iommu.c 
b/xen/drivers/passthrough/arm/iommu.c
index 95b1abb..41c6497 100644
--- a/xen/drivers/passthrough/arm/iommu.c
+++ b/xen/drivers/passthrough/arm/iommu.c
@@ -73,3 +73,69 @@ int arch_iommu_populate_page_table(struct domain *d)
  /* The IOMMU shares the p2m with the CPU */
  return -ENOSYS;
  }
+
+const struct iommu_ops *iommu_ops_from_fwnode(struct fwnode_handle *fwnode)
+{
+return iommu_get_ops();


Can you please add a comment explain why you always return iommu_get_ops()?

Would it be possible that the device is not behind an IOMMU?


+}
+
+int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
+const struct iommu_ops *ops)
+{
+struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+
+if ( fwspec )
+return ops == fwspec->ops ? 0 : -EINVAL;
+
+fwspec = _xzalloc(sizeof(struct iommu_fwspec), sizeof(void *));


On the previous version this was xzalloc(struct iommu_fwspec), why?

I also don't understand the align on sizeof(void *).


+if ( !fwspec )
+return -ENOMEM;
+
+fwspec->iommu_fwnode = iommu_fwnode;
+fwspec->ops = ops;
+dev->iommu_fwspec = fwspec;
+
+return 0;
+}
+
+void iommu_fwspec_free(struct device *dev)
+{
+struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+
+if ( fwspec )
+{


Linux is dropping the reference on the iommu_fwnode. Are we never 
expecting to take reference on the it in Xen?



+xfree(fwspec);
+dev->iommu_fwspec = NULL;
+}
+}
+
+int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids)
+{
+struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+struct iommu_fwspec *fwspec_n = NULL;
+size_t size, size_n;
+int i;
+
+if ( !fwspec )
+return -EINVAL;
+
+size = offsetof(struct iommu_fwspec, ids[fwspec->num_ids]);
+size_n = offsetof(struct iommu_fwspec, ids[fwspec->num_ids + num_ids]);
+if ( size_n > size )
+{ > +fwspec_n = _xzalloc(size_n, sizeof(void *));


Same question about _xzalloc() here.


+if ( !fwspec_n )
+return -ENOMEM;
+
+memcpy(fwspec_n, fwspec, size);
+xfree(fwspec);
+}
+
+for (i = 0; i < num_ids; i++)
+fwspec_n->ids[fwspec_n->num_ids + i] = ids[i];
+
+fwspec_n->num_ids += num_ids;
+dev->iommu_fwspec = fwspec_n;
+
+return 0;
+}
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 78c38fe..5027c87 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -21,6 +21,7 @@ struct device
  struct dt_device_node *of_node; /* Used by drivers imported from Linux */
  #endif
  struct fwnode_handle *fwnode; /*fw device node identifier */
+struct iommu_fwspec *iommu_fwspec;
  struct dev_archdata archdata;
  };
  
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h

index 0dac4f3..34e8d68 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -208,4 +208,33 @@ DECLARE_PER_CPU(bool_t, iommu_dont_flush_iotlb);
  extern struct spinlock iommu_pt_cleanup_lock;
  extern struct page_list_head iommu_pt_cleanup_list;
  
+/**

+ * Following block was ported from Linux to help with the implementation of
+ * arm64 iommu devices. Hence the architecture specific compile
+ */
+
+#if defined(CONFIG_ARM)


If it is Arm only, then it should be moved in asm-arm/iommu.h.


+/**
+ * struct iommu_fwspec - per-device IOMMU instance data
+ * @ops: ops for this device's IOMMU
+ * @iommu_fwnode: firmware handle for this device's IOMMU
+ * @iommu_priv: IOMMU driver private data for this device
+ * @num_ids: number of associated device IDs
+ * @ids: IDs which this device may present to the IOMMU
+ */
+struct iommu_fwspec {
+const struct iommu_ops *ops;
+struct fwnode_handle   *iommu_fwnode;
+void   *iommu_priv;
+unsigned int   num_ids;
+u32ids[1];
+};
+
+int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
+ const struct iommu_ops *ops);
+void iommu_fwspec_free(struct device *dev);
+int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids);
+const struct iommu_ops *iommu_ops_from_fwnode(struct fwnode_handle *fwnode);
+
+#endif
  #endif /* _IOMMU_H_ */



Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org

Re: [Xen-devel] [Qemu-devel] [RFC QEMU PATCH v3 00/10] Implement vNVDIMM for Xen HVM guest

2017-10-12 Thread Haozhong Zhang 
On 10/10/17 12:05 -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Sep 12, 2017 at 11:15:09AM +0800, Haozhong Zhang wrote:
> > On 09/11/17 11:52 -0700, Stefano Stabellini wrote:
> > > CC'ing xen-devel, and the Xen tools and x86 maintainers.
> > > 
> > > On Mon, 11 Sep 2017, Igor Mammedov wrote:
> > > > On Mon, 11 Sep 2017 12:41:47 +0800
> > > > Haozhong Zhang  wrote:
> > > > 
> > > > > This is the QEMU part patches that works with the associated Xen
> > > > > patches to enable vNVDIMM support for Xen HVM domains. Xen relies on
> > > > > QEMU to build guest NFIT and NVDIMM namespace devices, and allocate
> > > > > guest address space for vNVDIMM devices.
> > > > > 
> > > > > All patches can be found at
> > > > >   Xen:  https://github.com/hzzhan9/xen.git nvdimm-rfc-v3
> > > > >   QEMU: https://github.com/hzzhan9/qemu.git xen-nvdimm-rfc-v3
> > > > > 
> > > > > Patch 1 is to avoid dereferencing the NULL pointer to non-existing
> > > > > label data, as the Xen side support for labels is not implemented yet.
> > > > > 
> > > > > Patch 2 & 3 add a memory backend dedicated for Xen usage and a hotplug
> > > > > memory region for Xen guest, in order to make the existing nvdimm
> > > > > device plugging path work on Xen.
> > > > > 
> > > > > Patch 4 - 10 build and cooy NFIT from QEMU to Xen guest, when QEMU is
> > > > > used as the Xen device model.
> > > > 
> > > > I've skimmed over patch-set and can't say that I'm happy with
> > > > number of xen_enabled() invariants it introduced as well as
> > > > with partial blobs it creates.
> > > 
> > > I have not read the series (Haozhong, please CC me, Anthony and
> > > xen-devel to the whole series next time), but yes, indeed. Let's not add
> > > more xen_enabled() if possible.
> > > 
> > > Haozhong, was there a design document thread on xen-devel about this? If
> > > so, did it reach a conclusion? Was the design accepted? If so, please
> > > add a link to the design doc in the introductory email, so that
> > > everybody can read it and be on the same page.
> > 
> > Yes, there is a design [1] discussed and reviewed. Section 4.3 discussed
> > the guest ACPI.
> > 
> > [1] 
> > https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg01921.html
> 
> Igor, did you have a chance to read it?
> 
> .. see below
> > 
> > > 
> > > 
> > > > I'd like to reduce above and a way to do this might be making xen 
> > > >  1. use fw_cfg
> > > >  2. fetch QEMU build acpi tables from fw_cfg
> > > >  3. extract nvdim tables (which is trivial) and use them
> > > > 
> > > > looking at xen_load_linux(), it seems possible to use fw_cfg.
> > > > 
> > > > So what's stopping xen from using it elsewhere?,
> > > > instead of adding more xen specific code to do 'the same'
> > > > job and not reusing/sharing common code with tcg/kvm.
> > > 
> > > So far, ACPI tables have not been generated by QEMU. Xen HVM machines
> > > rely on a firmware-like application called "hvmloader" that runs in
> > > guest context and generates the ACPI tables. I have no opinions on
> > > hvmloader and I'll let the Xen maintainers talk about it. However, keep
> > > in mind that with an HVM guest some devices are emulated by Xen and/or
> > > by other device emulators that can run alongside QEMU. QEMU doesn't have
> > > a full few of the system.
> > > 
> > > Here the question is: does it have to be QEMU the one to generate the
> > > ACPI blobs for the nvdimm? It would be nicer if it was up to hvmloader
> > > like the rest, instead of introducing this split-brain design about
> > > ACPI. We need to see a design doc to fully understand this.
> > >
> > 
> > hvmloader runs in the guest and is responsible to build/load guest
> > ACPI. However, it's not capable to build AML at runtime (for the lack
> > of AML builder). If any guest ACPI object is needed (e.g. by guest
> > DSDT), it has to be generated from ASL by iasl at Xen compile time and
> > then be loaded by hvmloader at runtime.
> > 
> > Xen includes an OperationRegion "BIOS" in the static generated guest
> > DSDT, whose address is hardcoded and which contains a list of values
> > filled by hvmloader at runtime. Other ACPI objects can refer to those
> > values (e.g., the number of vCPUs). But it's not enough for generating
> > guest NVDIMM ACPI objects at compile time and then being customized
> > and loaded by hvmload, because its structure (i.e., the number of
> > namespace devices) cannot be decided util the guest config is known.
> > 
> > Alternatively, we may introduce an AML builder in hvmloader and build
> > all guest ACPI completely in hvmloader. Looking at the similar
> > implementation in QEMU, it would not be small, compared to the current
> > size of hvmloader. Besides, I'm still going to let QEMU handle guest
> > NVDIMM _DSM and _FIT calls, which is another reason I use QEMU to
> > build NVDIMM ACPI.
> > 
> > > If the design doc thread led into thinking that it has to be QEMU to
> > > generate them, then would it make the code nicer if

Re: [Xen-devel] [RFC v2 2/7] arm64: Add definitions for fwnode_handle

2017-10-12 Thread Julien Grall 

Hi,

On 21/09/17 01:37, Sameer Goel wrote:

This will be used as a device property to match the DMA capable devices
with the associated SMMU. The header file is a port from linux. The code
was changed to remove the types that were not needed for Xen.


I think you probably want a bit more context in the commit message about 
implement fwnode.h in common code.


Within this series, fwnode seems to only be used by Arm. So what would 
be the advantage to get that in xen/? Is it going to be used by x86 or 
taken advantage in common code?




Linux ChangeId:ce793486e23e: driver core / ACPI: Represent ACPI
companions using fwnode_handle

Signed-off-by: Sameer Goel 
---
  xen/include/asm-arm/device.h |  2 ++
  xen/include/xen/fwnode.h | 33 +
  2 files changed, 35 insertions(+)
  create mode 100644 xen/include/xen/fwnode.h

diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 6734ae8..78c38fe 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -2,6 +2,7 @@
  #define __ASM_ARM_DEVICE_H
  
  #include 

+#include 
  
  enum device_type

  {
@@ -19,6 +20,7 @@ struct device
  #ifdef CONFIG_HAS_DEVICE_TREE
  struct dt_device_node *of_node; /* Used by drivers imported from Linux */


I was expecting a todo in the code after the discussion about leave 
of_node here.



  #endif
+struct fwnode_handle *fwnode; /*fw device node identifier */


Space missing before "fw".


  struct dev_archdata archdata;
  };
  
diff --git a/xen/include/xen/fwnode.h b/xen/include/xen/fwnode.h

new file mode 100644
index 000..0fed958
--- /dev/null
+++ b/xen/include/xen/fwnode.h
@@ -0,0 +1,33 @@
+/*
+ * fwnode.h - Firmware device node object handle type definition.
+ *
+ * Copyright (C) 2015, Intel Corporation
+ * Author: Rafael J. Wysocki 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Ported from Linux include/linux/fwnode.h
+ *  => commit ce793486e23e0162a732c605189c8028e0910e86
+ *
+ * No functional Xen modifications.
+ */
+
+#ifndef __XEN_FWNODE_H_
+#define __XEN_FWNODE_H_
+
+enum fwnode_type {
+   FWNODE_INVALID = 0,
+   FWNODE_OF,
+   FWNODE_ACPI,
+   FWNODE_ACPI_STATIC,
+   FWNODE_IRQCHIP
+};
+


Looking at Linux code, the fwnode_type already disappeared from Linux 
(see commit db3e50f3234b "device property: Get rid of struct 
fwnode_handle type field").


I understand the goal on using fwnode is to help porting drivers from 
Linux. So how much this has changed now?


Cheers,


+struct fwnode_handle {
+   enum fwnode_type type;
+   struct fwnode_handle *secondary;
+};
+
+#endif



--
Julien Grall

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

[Xen-devel] [linux-next test] 114338: regressions - FAIL

2017-10-12 Thread osstest service owner 
flight 114338 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114338/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 114175
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 114175
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 114175
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 114175
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 114175
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 114175
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 114175
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 114175
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 114175
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
114175
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 114175
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 114175
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
114175
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 114175
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 114175
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 114175
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 114175
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 114175
 test-amd64-i386-examine   7 reboot   fail REGR. vs. 114175
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 114175
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 114175
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 114175
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 114175
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 114175
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 114175
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 114175
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 114175
 test-amd64-i386-libvirt-qcow2  7 xen-bootfail REGR. vs. 114175
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 114175
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 114175
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 114175
 test-amd64-amd64-xl-qcow2   19 guest-start/debian.repeat fail REGR. vs. 114175
 build-armhf-pvops 6 kernel-build fail REGR. vs. 114175

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop   fail REGR. vs. 114175

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114175
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail 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

version targeted for testing:
 linux49827b977a2e374540bc1bb1dcd9cf72952967d7
baseline version:
 linux8a5776a5f49812d29fe4b2d0a2d71675c3facf3f

Last test of basis  (not found)

[Xen-devel] [PATCH 4/3] x86: don't ignore foreigndom on L2/L3/L4 page table updates

2017-10-12 Thread Jan Beulich 
Silently assuming DOMID_SELF is unlikely to be a good idea for page
table updates. For PGT_writable pages, though, it seems better to allow
the writes, so the same check isn't being applied there.

Also add blank lines between the individual case blocks.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3542,18 +3542,28 @@ long do_mmu_update(
   cmd == MMU_PT_UPDATE_PRESERVE_AD, v,
   pg_owner);
 break;
+
 case PGT_l2_page_table:
+if ( unlikely(pg_owner != pt_owner) )
+break;
 rc = mod_l2_entry(va, l2e_from_intpte(req.val), mfn,
   cmd == MMU_PT_UPDATE_PRESERVE_AD, v);
 break;
+
 case PGT_l3_page_table:
+if ( unlikely(pg_owner != pt_owner) )
+break;
 rc = mod_l3_entry(va, l3e_from_intpte(req.val), mfn,
   cmd == MMU_PT_UPDATE_PRESERVE_AD, v);
 break;
+
 case PGT_l4_page_table:
+if ( unlikely(pg_owner != pt_owner) )
+break;
 rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn,
   cmd == MMU_PT_UPDATE_PRESERVE_AD, v);
 break;
+
 case PGT_writable_page:
 perfc_incr(writable_mmu_updates);
 if ( paging_write_guest_entry(v, va, req.val, _mfn(mfn)) )




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

[Xen-devel] Xen Security Advisory 238 - DMOP map/unmap missing argument checks

2017-10-12 Thread Xen . org security team 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-238
  version 2

DMOP map/unmap missing argument checks

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

DMOPs (which were a subgroup of HVMOPs in older releases) allow guests
to control and drive other guests.  The I/O request server page mapping
interface uses range sets to represent I/O resources the emulation of
which is provided by a given I/O request server.  The internals of the
range set implementation require that ranges have a starting value no
lower than the ending one.  Checks for this fact were missing.

IMPACT
==

Malicious or buggy stub domain kernels or tool stacks otherwise living
outside of Domain0 can mount a denial of service attack which, if
successful, can affect the whole system.

Only domains controlling HVM guests can exploit this vulnerability.
(This includes domains providing hardware emulation services to HVM
guests.)

VULNERABLE SYSTEMS
==

Xen versions 4.5 and later are vulnerable.  Xen versions 4.4 and
earlier are not vulnerable.

Only x86 systems are affected.  ARM systems are not affected.

This vulnerability is only applicable to Xen systems using stub domains
or other forms of disaggregation of control domains for HVM guests.

MITIGATION
==

Running only PV guests will avoid this issue.

(The security of a Xen system using stub domains is still better than
with a qemu-dm running as an unrestricted dom0 process.  Therefore
users with these configurations should not switch to an unrestricted
dom0 qemu-dm.)

CREDITS
===

This issue was discovered by Vitaly Kuznetsov of RedHat.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa238.patch   xen-unstable, Xen 4.9.x, Xen 4.8.x, Xen 4.7.x
xsa238-4.6.patch   Xen 4.6.x
xsa238-4.5.patch   Xen 4.5.x

$ sha256sum xsa238*
3cced09a1fb2936644d654c568f38580952328b84e28601b019ea7418c36  xsa238.meta
85d3f9713bef1bc86c682857dbd7388a1d1f20089363ddfc4cb9ecbd88eaffec  xsa238.patch
034e91c234f6831dbaa1aaf29f4f90de2e822f99301424f7f3527f9da883ff68  
xsa238-4.5.patch
29255a81729b24866e594426167de5fbef70de21ef62a95ba95de191d2a7fd54  
xsa238-4.6.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJZ31v7AAoJEIP+FMlX6CvZrBgIAMg3C1Gvc3rnrPjT+0Im7gdQ
vBXGAWViWDs7EC1Vl5IU6lQQKETNmx40kRPyOYOVSdPzWamOotXOSadpJ49mbTX1
CA2iSJ8OAdqcPhgKjdUYVJXkybujNp6WkdlcT6ZXvEs6DLuvKJXZBaRoX2vYtObq
JjwUfGgpHcOc8vLhaEjEZTWRnKJotqQPaPaDHzrtGJAkHB0F+gwqpM4lBD6Q18+/
DzyBWlDENEcoSwzDldZ/4Ktl/rOXDOPoYYZfnFmYA2puWP7ujonio8iofOy+6GH3
GoKSPs1ciC4ax1WdJqbuxM0TCStz4QFOselVQ0hEJNdH6k3mmA4wMg+6kPNDf2U=
=9idj
-END PGP SIGNATURE-


xsa238.meta
Description: Binary data


xsa238.patch
Description: Binary data


xsa238-4.5.patch
Description: Binary data


xsa238-4.6.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Xen Security Advisory 237 - multiple MSI mapping issues on x86

2017-10-12 Thread Xen . org security team 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-237
  version 2

  multiple MSI mapping issues on x86

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

Multiple issues exist with the setup of PCI MSI interrupts:
- - unprivileged guests were permitted access to devices not owned by
  them, in particular allowing them to disable MSI or MSI-X on any
  device
- - HVM guests can trigger a codepath intended only for PV guests
- - some failure paths partially tear down previously configured
  interrupts, leaving inconsistent state
- - with XSM enabled, caller and callee of a hook disagreed about the
  data structure pointed to by a type-less argument

IMPACT
==

A malicious or buggy guest may cause the hypervisor to crash, resulting
in Denial of Service (DoS) affecting the entire host.  Privilege
escalation and information leaks cannot be excluded.

VULNERABLE SYSTEMS
==

All Xen versions from at 3.3 onwards are vulnerable.  Xen versions 3.2
and earlier are not vulnerable.

Only x86 systems are affected.  ARM systems are not affected.

Only guests which have a physical device assigned to them can exploit
the vulnerability.

MITIGATION
==

Not passing through physical devices to untrusted guests will avoid
the vulnerability.

The vulnerability can be avoided if the guest kernel is controlled by
the host rather than guest administrator, provided that further steps
are taken to prevent the guest administrator from loading code into the
kernel (e.g. by disabling loadable modules etc) or from using other
mechanisms which allow them to run code at kernel privilege.

CREDITS
===

This issue was discovered by Simon Gaiser of Qubes OS Project.

RESOLUTION
==

Applying the appropriate attached set of patches resolves this issue.

xsa237-unstable/*.patch xen-unstable
xsa237-4.9/*.patch  Xen 4.9.x
xsa237-4.8/*.patch  Xen 4.8.x, Xen 4.7.x
xsa237-4.6/*.patch  Xen 4.6.x
xsa237-4.5/*.patch  Xen 4.5.x

$ sha256sum xsa237* xsa237*/*
1d4d3fa452e91d235fd688761d695752bde2f2e91fd9b17f566c4cee23ae26d0  xsa237.meta
3259cd514ea80e3cbac5b72376b4e964afb3b2cabee347440ec2bdd6e585c513  
xsa237-unstable/0001-x86-dont-allow-MSI-pIRQ-mapping-on-unowned-device.patch
7ef53f6a5f3fc6952cb8411e31e0a670de5a78ab2c8176037db32cf147438aa6  
xsa237-unstable/0002-x86-enforce-proper-privilege-when-mapping-pIRQ-s.patch
494a79332fc5f854f0dc7606669201717a41e5b89b44db2fb30607a326930bfb  
xsa237-unstable/0003-x86-MSI-disallow-redundant-enabling.patch
503b58512c5336aff9692c0d0768f38ee956c0988fa3fad4d439f13814736e06  
xsa237-unstable/0004-x86-IRQ-conditionally-preserve-irq-pirq-mapping-on-error.patch
dc5f27245e44582db682ac53f24007685ea2f8cb104bad9b4d6afeaa7c4e73d2  
xsa237-unstable/0005-x86-FLASK-fix-unmap-domain-IRQ-XSM-hook.patch
cd9cd248c4564552bbe847462d247b78ff6af1052198e6b6529178a8a624e1f6  
xsa237-4.5/0001-x86-dont-allow-MSI-pIRQ-mapping-on-unowned-device.patch
87bbb240323b3cce9767da73961d58436c436db6da614c62ade7640f87f748dd  
xsa237-4.5/0002-x86-enforce-proper-privilege-when-mapping-pIRQ-s.patch
6a2e6772fa7b7a1683f7b1041f0675756268635aedb8c760ebcd9ad0ff7a  
xsa237-4.5/0003-x86-MSI-disallow-redundant-enabling.patch
c558ca347b6df9b430fbdaf9c9b8e3b203c273be1e2bb01aa3424773b88df91d  
xsa237-4.5/0004-x86-IRQ-conditionally-preserve-irq-pirq-mapping-on-error.patch
60169e2016451e1c479c4f873ee6798b6abc46e3223a60a4b83bac20a7a3d27c  
xsa237-4.5/0005-x86-FLASK-fix-unmap-domain-IRQ-XSM-hook.patch
cd9cd248c4564552bbe847462d247b78ff6af1052198e6b6529178a8a624e1f6  
xsa237-4.6/0001-x86-dont-allow-MSI-pIRQ-mapping-on-unowned-device.patch
d39d1c0eaf2ba169b6596520b05930d280721c397fafa3414b6da6168e8b73ca  
xsa237-4.6/0002-x86-enforce-proper-privilege-when-mapping-pIRQ-s.patch
494a79332fc5f854f0dc7606669201717a41e5b89b44db2fb30607a326930bfb  
xsa237-4.6/0003-x86-MSI-disallow-redundant-enabling.patch
c558ca347b6df9b430fbdaf9c9b8e3b203c273be1e2bb01aa3424773b88df91d  
xsa237-4.6/0004-x86-IRQ-conditionally-preserve-irq-pirq-mapping-on-error.patch
4cdcd71758d9e5b392c38aeafc9960a4f3ef5c109508e69b2218a8d8394edf0b  
xsa237-4.6/0005-x86-FLASK-fix-unmap-domain-IRQ-XSM-hook.patch
1ae6aefb86ba0c48a45ecc14ff56ea0bc3d9d354937668bcacadaed1225017a8  
xsa237-4.8/0001-x86-dont-allow-MSI-pIRQ-mapping-on-unowned-device.patch
bf2ca9cb99ee64d7db77d628cec1a84684c360fd36de433cbc78fbcde8095319  
xsa237-4.8/0002-x86-enforce-proper-privilege-when-mapping-pIRQ-s.patch
494a79332fc5f854f0dc7606669201717a41e5b89b44db2fb30607a326930bfb  
xsa237-4.8/0003-x86-MSI-disallow-redundant-enabling.patch
9a38899afd728d504382954de28657aa82af7da352eb4e45a5e615bd646834c5  
xsa237-4.8/0004-x86-IRQ-conditionally-preserve-irq-pirq-mapping-on-error.patch
fef5c77f19e2c6229912f1fd19cbcb41c1ce554ff53be22198b2f34ea7a27314  
xsa237-4.8/0005-x86-FLASK-fix-unmap-domain-IRQ-XSM-hook.patch

[Xen-devel] Xen Security Advisory 242 - page type reference leak on x86

2017-10-12 Thread Xen . org security team 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-242
  version 2

page type reference leak on x86

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

The page type system of Xen requires cleanup when the last reference
for a given page is being dropped.  In order to exclude simultaneous
updates to a given page by multiple parties, pages which are updated
are locked beforehand.  This locking includes temporarily increasing
the type reference count by one.  When the page is later unlocked, the
context precludes cleanup, so the reference that is then dropped must
not be the last one.  This was not properly enforced.

IMPACT
==

A malicious or buggy PV guest may cause a memory leak upon shutdown
of the guest, ultimately perhaps resulting in Denial of Service (DoS)
affecting the entire host.

VULNERABLE SYSTEMS
==

All Xen versions from 3.4 onwards are vulnerable.  Xen versions 3.3 and
earlier are not vulnerable.

Only x86 systems are affected.  ARM systems are not affected.

Only x86 PV guests can leverage the vulnerability.  x86 HVM guests
cannot leverage the vulnerability.

MITIGATION
==

Running only HVM guests will avoid this vulnerability.

For PV guests, the vulnerability can be avoided if the guest kernel is
controlled by the host rather than guest administrator, provided that
further steps are taken to prevent the guest administrator from loading
code into the kernel (e.g. by disabling loadable modules etc) or from
using other mechanisms which allow them to run code at kernel privilege.

CREDITS
===

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa242.patch   xen-unstable
xsa242-4.9.patch   Xen 4.9.x, Xen 4.8.x, Xen 4.7.x, Xen 4.6.x, Xen 4.5.x

$ sha256sum xsa242*
168db3aef00806025afa255dee35cd0c042706a27a0256744e4d63f3ee86a2e8  xsa242.meta
16848f71311c2fd6a38afd7602e59211c89a3daf29b874097dba0b1e31ba6eec  xsa242.patch
5e66b6b1d1cd400905d3abd3478144539c3afa24f5a744a11809d9c5eb517b98  
xsa242-4.9.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJZ31wBAAoJEIP+FMlX6CvZs4YH+QH5lTpge4JLyHQRJbLry52Z
70oB+1vZIsoWg9/XONE9/l1kei0WOGPh4Pt2AWUZOXy8I/euHlMUeGZchl7cQ73M
6EOPjQ1+EXv+vIePwyjZiZmjKQJYQDZ5IsNZ3lz2oV27SkppSW6KKPFlj9G3Dc+E
Fv0JwawHNBruGQu9RYWukLbCKn9g4Z0OD/4OwpzF0PY3c/zqk9aYjg318i2Na5zu
tWDI9+srfzgvT9N2+om/hVBQYHp48OOIUIGtMz7M4A33LBySsETigpBaCiNmyNeG
+l3ONWKF8XNeJbpYGtd3jClgXLg8Hy5MgalSCKOyB2XAgl0y2BSX3tyhOnQZKcs=
=tqOh
-END PGP SIGNATURE-


xsa242.meta
Description: Binary data


xsa242.patch
Description: Binary data


xsa242-4.9.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Xen Security Advisory 243 - x86: Incorrect handling of self-linear shadow mappings with translated guests

2017-10-12 Thread Xen . org security team 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-243
  version 3

 x86: Incorrect handling of self-linear shadow mappings with translated guests

UPDATES IN VERSION 3


Public release.

ISSUE DESCRIPTION
=

The shadow pagetable code uses linear mappings to inspect and modify the
shadow pagetables.  A linear mapping which points back to itself is known as
self-linear.  For translated guests, the shadow linear mappings (being in a
separate address space) are not intended to be self-linear.  For
non-translated guests, the shadow linear mappings (being the same
address space) are intended to be self-linear.

When constructing a monitor pagetable for Xen to run on a vcpu with, the shadow
linear slot is filled with a self-linear mapping, and for translated guests,
shortly thereafter replaced with a non-self-linear mapping, when the guest's
%cr3 is shadowed.

However when writeable heuristics are used, the shadow mappings are used as
part of shadowing %cr3, causing the heuristics to be applied to Xen's
pagetables, not the guest shadow pagetables.

While investigating, it was also identified that PV auto-translate mode was
insecure.  This mode was removed in Xen 4.7 due to being unused, unmaintained
and presumed broken.  We are not aware of any guest implementation of PV
auto-translate mode.

IMPACT
==

A malicious or buggy HVM guest may cause a hypervisor crash, resulting in a
Denial of Service (DoS) affecting the entire host, or cause hypervisor memory
corruption.  We cannot rule out a guest being able to escalate its privilege.

VULNERABLE SYSTEMS
==

All versions of Xen are vulnerable.

HVM guests using shadow mode paging can exploit this vulnerability.
HVM guests using Hardware Assisted Paging (HAP) as well as PV guests
cannot exploit this vulnerability.

ARM systems are not vulnerable.

MITIGATION
==

Running only PV guests will avoid this vulnerability.

Where the HVM guest is explicitly configured to use shadow paging (eg
via the `hap=0' xl domain configuration file parameter), changing to
HAP (eg by setting `hap=1') will avoid exposing the vulnerability to
those guests.  HAP is the default (in upstream Xen), where the
hardware supports it; so this mitigation is only applicable if HAP has
been disabled by configuration.

CREDITS
===

This issue was discovered by Andrew Cooper of Citrix.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa243.patch xen-unstable, Xen 4.9.x
xsa243-4.8.patch Xen 4.8.x
xsa243-4.7.patch Xen 4.7.x
xsa243-4.6-[1,2].patch   Xen 4.6.x
xsa243-4.{6-1,5-2}.patch Xen 4.5.x

$ sha256sum xsa243*
61b05e2d6655f5d18cd53b16e03499152c603162584f64d68fad31b088cc5cd2  xsa243.meta
a5b484db80346f7e75c7921ee4780567f04b9f9b4620c0cde4bfa1df3ac0f87f  xsa243.patch
79e1c5e088eee8e78aa67895a29d611352c64251854e4c5129e33c85988a47a5  
xsa243-4.5-2.patch
722073aad1e734e24b0b79d03a1957e491f3616fe6e244a89050f7a50f8f356b  
xsa243-4.6-1.patch
94cb346c486f88f2f4f701564017e1997e518a5a14218f0e38ff882c60fb382c  
xsa243-4.6-2.patch
465ba9e3293591a3c84c122ffd73474fe96483f5e21565440d5fbc207fa4c4a9  
xsa243-4.7.patch
f8e471b42502905a442d43934ac339663a6124118c9762b31f2ad930fd532e64  
xsa243-4.8.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJZ31wCAAoJEIP+FMlX6CvZfZIH/i6Ict2HQ3HPT8yLY6e+Lab4
XXRUutCRqiBYoxes4vsOs8SqVEBQ/AI/Ds5jpByNQqUrK/dH7CdTOthy3bsOSmHQ
UcUveuMyJ7IDCjJhFYmIA6o7Bc1OiBDoA3yg1pFn4tb1eAn/3mq4OCSNhqnCPiFy
MxnsQ023yCLUdHwPvNagLOwycOelD1CdZQPae8e1fuasABJfuTZ+MdREMcsJWfOo
rcH5++We9yWKttJqV9om7NsyEBdiQYRJHepJb0dJwm+ZMp46A5NaqNd6/PpFmoP9
L7sgweOd/Z2taJOrDiSTAuaoKuxA0sZstUaE+BCb7Xp2aqFmnSp85gsaqdvAkCs=
=ktEr
-END PGP SIGNATURE-


xsa243.meta
Description: Binary data


xsa243.patch
Description: Binary data


xsa243-4.5-2.patch
Description: Binary data


xsa243-4.6-1.patch
Description: Binary data


xsa243-4.6-2.patch
Description:

[Xen-devel] Xen Security Advisory 244 - x86: Incorrect handling of IST settings during CPU hotplug

2017-10-12 Thread Xen . org security team 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-244
  version 2

  x86: Incorrect handling of IST settings during CPU hotplug

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

The x86-64 architecture allows interrupts to be run on distinct stacks.
The choice of stack is encoded in a field of the corresponding
interrupt descriptor in the Interrupt Descriptor Table (IDT).  That
field selects an entry from the active Task State Segment (TSS).

Since, on AMD hardware, Xen switches to an HVM guest's TSS before
actually entering the guest, with the Global Interrupt Flag still set,
the selectors in the IDT entry are switched when guest context is
loaded/unloaded.

When a new CPU is brought online, its IDT is copied from CPU0's IDT,
including those selector fields.  If CPU0 happens at that moment to be
in HVM context, wrong values for those IDT fields would be installed
for the new CPU.  If the first guest vCPU to be run on that CPU
belongs to a PV guest, it will then have the ability to escalate its
privilege or crash the hypervisor.

IMPACT
==

A malicious or buggy x86 PV guest could escalate its privileges or
crash the hypervisor.

VULNERABLE SYSTEMS
==

All Xen versions from at least 3.2 onwards are vulnerable.  Earlier
versions have not been checked.

Only PV guests can exploit the vulnerability.  HVM guests cannot
exploit the vulnerability, but their presence is necessary for the
exposure of the vulnerability to PV guests.

Only x86 systems using SVM (AMD virtualisation extensions) rather than
VMX (Intel virtualisation extensions) are vulnerable.  Therefore AMD
x86 hardware is vulnerable; Intel hardware is not vulnerable.

ARM systems are not vulnerable.

MITIGATION
==

Avoiding to online CPUs at runtime will avoid this vulnerability.

Running only HVM or only PV guests on any individual host will also
avoid this vulnerability.

CREDITS
===

This issue was discovered by Andrew Cooper of Citrix.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa244.patch   xen-unstable, Xen 4.9.x, Xen 4.8.x
xsa244-4.7.patch   Xen 4.7.x
xsa244-4.6.patch   Xen 4.6.x
xsa244-4.5.patch   Xen 4.5.x

$ sha256sum xsa244*
5b663620a1b0d5f07e7ae4d1d3506d925515d5f85830ca49dda75cab1218506f  xsa244.meta
bcf22b332bf3f6fe8c86e4de67f82628c9b8e257d9513c3bf5c7f5dd71d86c33  xsa244.patch
4c4543fdfd25b4a8ea7d53f3f45011ec137798e7d4e690d8f3ea58d77afb5f06  
xsa244-4.5.patch
eaa3ba303980d783813db7aee948a9cb2723328da5fa5650ffca7b825c21bab6  
xsa244-4.6.patch
4d8cf754f760ef05488e9fb25a7ebd9a7e46f3742e91eee1a8385fd1e611ea8c  
xsa244-4.7.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJZ31wEAAoJEIP+FMlX6CvZixEIALXqWn6ShR2MCMeiGHy1ewsX
S80m2OFqHYgZuawTuA3TN3mYfQONLNpobpchU5Y/RoWxS70sfV5PqLf6IHYPlSSC
3VI+U+Q3nhPhudQo4RFkyFeDGg6dKEnver+Bfik1pHsTBB0o0ojAdgqbW+K4HEoE
flqPaXuQSFSFE5mYzQ+UxI7nE9I7IwDRD+eDSE/JRtTmXuoJPB8bC4De68dM4BbM
+nfaNR95PvyNTToKluYdcST7pq/jRal5/O8GSxNsolgcd6C4IZrX1wB2ibMoa1wh
ElLmcw/gyT/DfvO0STjvVQ/Ryaoj3ZLjMrNRt7pA8IQ1gig312f7vCGpF0/EeYM=
=9+du
-END PGP SIGNATURE-


xsa244.meta
Description: Binary data


xsa244.patch
Description: Binary data


xsa244-4.5.patch
Description: Binary data


xsa244-4.6.patch
Description: Binary data


xsa244-4.7.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Xen Security Advisory 241 - Stale TLB entry due to page type release race

2017-10-12 Thread Xen . org security team 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-241
  version 3

 Stale TLB entry due to page type release race

UPDATES IN VERSION 3


Fix ARM build issue in patches.

Public release.

ISSUE DESCRIPTION
=

x86 PV guests effect TLB flushes by way of a hypercall.  Xen tries to
reduce the number of TLB flushes by delaying them as much as possible.
When the last type reference of a page is dropped, the need for a TLB
flush (before the page is re-used) is recorded.  If a guest TLB flush
request involves an Inter Processor Interrupt (IPI) to a CPU in which
is the process of dropping the last type reference of some page, and
if that IPI arrives at exactly the right instruction boundary, a stale
time stamp may be recorded, possibly resulting in the later omission
of the necessary TLB flush for that page.

IMPACT
==

A malicious x86 PV guest may be able to access all of system memory,
allowing for all of privilege escalation, host crashes, and
information leaks.

VULNERABLE SYSTEMS
==

All Xen versions from at least 3.2 onwards are vulnerable.  Earlier
versions have not been checked.

Only x86 systems are affected.  ARM systems are not affected.

Only x86 PV guests can leverage the vulnerability.  x86 HVM guests
cannot leverage the vulnerability.

RISK ASSESSMENT
===

A successful attack would require introducing an extended delay between
two adjacent operations on one cpu -- long enough for two hypercalls to
complete on another cpu.  The security team currently has no
proof-of-concept for this vulnerability.

However, techniques for these sorts of timing-based attacks are
continually advancing, so we still recommend users potentially affected
by this issue apply the patch as soon as reasonably possible.

MITIGATION
==

Running only HVM guests will avoid this vulnerability.

For PV guests, the vulnerability can be avoided if the guest kernel is
controlled by the host rather than guest administrator, provided that
further steps are taken to prevent the guest administrator from loading
code into the kernel (e.g. by disabling loadable modules etc) or from
using other mechanisms which allow them to run code at kernel privilege.

CREDITS
===

This issue was discovered by Jann Horn of Google Project Zero.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa241.patch   xen-unstable
xsa241-4.9.patch   Xen 4.9.x
xsa241-4.8.patch   Xen 4.8.x, Xen 4.7.x, Xen 4.6.x, Xen 4.5.x

$ sha256sum xsa241*
5e239ba4dbd74fd61e59a27f9abc8ea6ba32532bdf81eeb2d7e66f0fd53e40b4  xsa241.meta
b8db933d53e7e289652ffda6c46ce284a0254a9f8bc9e1be6793e388009f49ce  xsa241.patch
443a5b0818045ada44fad0370ac01af0c96181be5a4078ae3b2575799e4a4e5b  
xsa241-4.8.patch
927ef14d875556481c38d4065f501211a78eec1c2396a954a4a4abfb9255960f  
xsa241-4.9.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJZ31v/AAoJEIP+FMlX6CvZsNgIALcJ/DeUN5nv8duBvC3hbAX6
NABBtlVJ6K7qZpAf+04Eztym4bEWXWGtJ1BQVCJ6aPwPZ4aOUodA/zRBEQS7Xp8F
5P5U3Qwa/C+slqLh7QfYdwlkgdMRG67yWIo2xMOEcfORlPjc1wDxohtCQZT9uiMs
Y9Xllt/sLhGgYq4+TpNvJyYMzvPp1+oBEuqcR58IZ2aepQJAlPl3LnLdYyN8TAqv
MBmli7cRO/vYn5z7aII9NbuF8XEnx0Vfqp7EufLU1LQyG4S9jYXd0xvD6BjjkGWM
N/dvJTMq8HXS00VUAoONOv+blq2AdRs9oYD8yeMCglUhpeK8cIaEsYzhOHbCvlI=
=1uZK
-END PGP SIGNATURE-


xsa241.meta
Description: Binary data


xsa241.patch
Description: Binary data


xsa241-4.8.patch
Description: Binary data


xsa241-4.9.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Xen Security Advisory 239 - hypervisor stack leak in x86 I/O intercept code

2017-10-12 Thread Xen . org security team 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-239
  version 2

hypervisor stack leak in x86 I/O intercept code

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

Intercepted I/O operations may deal with less than a full machine
word's worth of data.  While read paths had been the subject of earlier
XSAs (and hence have been fixed), at least one write path was found
where the data stored into an internal structure could contain bits
from an uninitialized hypervisor stack slot.  A subsequent emulated
read would then be able to retrieve these bits.

IMPACT
==

A malicious unprivileged x86 HVM guest may be able to obtain sensitive
information from the host or other guests.

VULNERABLE SYSTEMS
==

All Xen versions are vulnerable.

Only x86 systems are affected.  ARM systems are not affected.

Only HVM guests can leverage this vulnerability.  PV guests cannot
leverage this vulnerability.

MITIGATION
==

Running only PV guests will avoid this issue.

CREDITS
===

This issue was discovered by Roger Pau Monné of Citrix.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa239.patch   xen-unstable, Xen 4.9.x, Xen 4.8.x, Xen 4.7.x, Xen 4.6.x
xsa239-4.5.patch   Xen 4.5.x

$ sha256sum xsa239*
eb7971be89199eb3ff510f4f5650fd5a8ec588b9fcb8f89230216fac4214ef21  xsa239.meta
087a8b3cf7ecbdbde593033c127cbcf6c37f532bf33d90f72c19e493970a799c  xsa239.patch
b91a68fe67240f2a5bb9460c5b650e9595364afa180f8702aef783815e3d7dcd  
xsa239-4.5.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJZ31v8AAoJEIP+FMlX6CvZ1AQIAMmN4FghnJvlec7xsPQBgPBs
nlOItkaXMYZnIajohG2/U5zfFU02oj0GmCz4CDODaKiaZem2p69LzVeVOkqAqQ4p
osYMy918GROxrvfHo+36gCBDfwlB7TWr6dQzM50nHh+6O1l1+QlpCw3k+gb5CnNT
Rkn/V1ZZGVy7ycwGiMK1mP0C9hsGyuC5xxwCR9XxK01X0x+NTEXZWAS+GbPHBJAS
HyopB9W+PkQ0qL/j7VjfGdUWTGquBPffnDGQFBN7CqQ+Pt6Mpv4RvkHiS3NTP5qd
8rp5M0xjVBnpCC/JAQXL9oLK+LZf99oIal1zbQ1FrECYFXIIyf/hUMxguBbsON4=
=8UQF
-END PGP SIGNATURE-


xsa239.meta
Description: Binary data


xsa239.patch
Description: Binary data


xsa239-4.5.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 3/3] x86: tighten MMU_*PT_UPDATE* check and combine error paths

2017-10-12 Thread Jan Beulich 
>>> On 12.10.17 at 13:31,  wrote:
> On 12/10/17 11:01, Jan Beulich wrote:
>> Don't accept anything other than r/w RAM pages and move the paged-out
>> check into the (unlikely) error path following that check.
>>
>> Signed-off-by: Jan Beulich 
> 
> How does dom0 boot with this change in place?  You appear to have
> prohibited mapping MMIO frames.

The page in question is a page table one, which can't be MMIO.
Dom0 is booting fine.

Jan

>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -3507,18 +3507,18 @@ long do_mmu_update(
>>  gmfn = req.ptr >> PAGE_SHIFT;
>>  page = get_page_from_gfn(pt_owner, gmfn, , P2M_ALLOC);
>>  
>> -if ( p2m_is_paged(p2mt) )
>> +if ( unlikely(!page) || p2mt != p2m_ram_rw )
>>  {
>> -ASSERT(!page);
>> -p2m_mem_paging_populate(pt_owner, gmfn);
>> -rc = -ENOENT;
>> -break;
>> -}
>> -
>> -if ( unlikely(!page) )
>> -{
>> -gdprintk(XENLOG_WARNING,
>> - "Could not get page for normal update\n");
>> +if ( page )
>> +put_page(page);
>> +if ( p2m_is_paged(p2mt) )
>> +{
>> +p2m_mem_paging_populate(pt_owner, gmfn);
>> +rc = -ENOENT;
>> +}
>> +else
>> +gdprintk(XENLOG_WARNING,
>> + "Could not get page for normal update\n");
>>  break;
>>  }
>>  
>>
>>
>>




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

Re: [Xen-devel] [RFC] ARM: New (Xen) VGIC design document

2017-10-12 Thread Christoffer Dall 
Hi Andre,

On Wed, Oct 11, 2017 at 03:33:03PM +0100, Andre Przywara wrote:
> Hi,
> 
> (CC:ing some KVM/ARM folks involved in the VGIC)

Very nice writeup!

I added a bunch of comments, mostly for the writing and clarity, I hope
it helps.

> 
> starting with the addition of the ITS support we were seeing more and
> more issues with the current implementation of our ARM Generic Interrupt
> Controller (GIC) emulation, the VGIC.
> Among other approaches to fix those issues it was proposed to copy the
> VGIC emulation used in KVM. This one was suffering from very similar
> issues, and a clean design from scratch lead to a very robust and
> capable re-implementation. Interestingly this implementation is fairly
> self-contained, so it seems feasible to copy it. Hopefully we only need
> minor adjustments, possibly we can even copy it verbatim with some
> additional glue layer code.
> Stefano asked for getting a design overview, to assess the feasibility
> of copying the KVM code without reviewing tons of code in the first
> place.
> So to follow Xen rules for new features, this design document below is
> an attempt to describe the current KVM VGIC design - in a hypervisor
> agnostic session. It is a bit of a retro-fit design description, as it
> is not strictly forward-looking only, but actually describing the
> existing implemenation [1].
> 
> Please have a look and let me know:
> 1) if this document has the right scope
> 2) if this document has the right level of detail
> 3) if there are points missing from the document
> 3) if the design in general is a fit
> 
> Appreciate any feedback!
> 
> Cheers,
> Andre.
> 
> ---
> 
> VGIC design
> ===
> 
> This document describes the design of an ARM Generic Interrupt Controller 
> (GIC)
> emulation. It is meant to emulate a GIC for a guest in an virtual machine,
> the common name for that is VGIC (from "virtual GIC").
> 
> This design was the result of a one-week-long design session with some
> engineers in a room, triggered by ever-increasing difficulties in maintaining
> the existing GIC emulation in the KVM hypervisor. The design eventually
> materialised as an alternative VGIC implementation in the Linux kernel
> (merged into Linux v4.7). As of Linux v4.8 the previous VGIC implementation
> was removed, so it is now the current code used by Linux.
> Although being used in KVM, the actual design of this VGIC is rather 
> hypervisor
> agnostic and can be used by other hypervisors as well, in particular for Xen.
> 
> GIC hardware virtualization support
> ---
> 
> The ARM Generic Interrupt Controller (since v2) supports the virtualization
> extensions, which allows some parts of the interrupt life cycle to be handled
> purely inside the guest without exiting into the hypervisor.
> In the GICv2 and GICv3 architecture this covers mostly the "interrupt
> acknowledgement", "priority drop" and "interrupt deactivate" actions.
> So a guest can handle most of the interrupt processing code without
> leaving EL1 and trapping into the hypervisor. To accomplish
> this, the GIC holds so called "list registers" (LRs), which shadow the
> interrupt state for any virtual interrupt. Injecting an interrupt to a guest
> involves setting up one LR with the interrupt number, its priority and initial
> state (mostly "pending"), then entering the guest. Any EOI related action
> from within the guest just acts on those LRs, the hypervisor can later update
> the virtual interrupt state when the guest exists the next time (for whatever
> reason).
> But despite the GIC hardware helping out here, the whole interrupt
> configuration management is not virtualized at all and needs to be emulated
> by the hypervisor - or another related software component, for instance a
> userland emulator. This so called "distributor" part of the GIC consists of
> memory mapped registers, which can be trapped by the hypervisor, so any guest
> access can be emulated in the usual way.
> 
> VGIC design motivation
> --
> 
> A GIC emulation thus needs to take care of those bits:
> 
> - trap GIC distributor MMIO accesses and shadow the configuration setup
>   (enabled/disabled, level/edge, priority, affinity) for virtual interrupts
> - handle incoming hardware and virtual interrupt requests and inject the
>   associated virtual interrupt by manipulating one of the list registers
> - track the state of a virtual interrupt by inspecting the LRs after the
>   guest has exited, possibly adjusting the shadowed virtual interrupt state
> 
> Despite the distributor MMIO register emulation being a sizeable chunk of
> the emulation, it is actually not dominant if looking at the frequency at
> which it is accessed. Normally the interrupt configuration is done at boot
> time or upon initialising the device (driver), but rarely during the actual
> run time of a system. Injecting and EOI-ing interrupts however happens much
> more often. A good

[Xen-devel] [PATCH v2 2/2] xl: dm_restrict: Document that it does not work with PV

2017-10-12 Thread Ian Jackson 
Signed-off-by: Ian Jackson 
Reported-by: Roger Pau Monné 
Acked-by: Wei Liu 
---
 docs/man/xl.cfg.pod.5.in | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 9b27233..b7b91d8 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -1270,7 +1270,7 @@ connectors=id0:1920x1080;id1:800x600;id2:640x480
 
 =item

[Xen-devel] [PATCH v2 1/2] libxl: dm_restrict: Move to domain_build_info

2017-10-12 Thread Ian Jackson 
Right now, this is broken because libxl__build_device_model_args_new
is used also for the qemu run for pv guests for qdisk devices, pvfb,
etc.

We can either make this option properly HVM-specific, or make it
generic.

In principle it is a reasonable request, to make the PV qemu
deprivileged (even though it is not likely to be implemented any time
soon).  So make this option generic.

We retain the name "device model" even though it is arguably
inaccurate, because the xl docs already say, for example
  For a PV guest a device-model is sometimes used to provide backends
  for certain PV devices

The documentation patch here is pure code motion.  For ease of review
we will fix up the docs, so the wording to be right for the new
context, in the next patch.

Signed-off-by: Ian Jackson 
Reported-by: Roger Pau Monné 
Acked-by: Wei Liu 
---
v2: Change xl too, to avoid breaking the build.
Fix manpage pod syntax.
---
 docs/man/xl.cfg.pod.5.in| 198 ++--
 tools/libxl/libxl_create.c  |   2 +-
 tools/libxl/libxl_dm.c  |   6 +-
 tools/libxl/libxl_types.idl |   2 +-
 tools/xl/xl_parse.c |   5 +-
 5 files changed, 106 insertions(+), 107 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index cf3fa0e..9b27233 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -1268,6 +1268,105 @@ connectors=id0:1920x1080;id1:800x600;id2:640x480
 
 =back
 
+=item

Re: [Xen-devel] [PATCH 2/2] xl: dm_restrict: Document that it does not work with PV

2017-10-12 Thread Roger Pau Monné 
On Thu, Oct 12, 2017 at 11:21:07AM +, Ian Jackson wrote:
> Signed-off-by: Ian Jackson 
> Reported-by: Roger Pau Monné 

Reviewed-by: Roger Pau Monné 

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v2 0/2] ARM: ACPI: IORT: Hide SMMU from hardware domain's IORT table

2017-10-12 Thread Julien Grall 



On 12/10/17 12:22, Manish Jaggi wrote:

Hi Julien,

Why do you omit parts of mail where I have asked a question , please 
avoid skiping  that removes the context.


I believe I answered it just after because you asked twice the same 
thing. So may I dropped the context but the answer was there...


For your convenience here the replicated answer.

"Why? The generation of IORT is fairly standalone.

And again, this was suggestion to share in the future and an expectation 
for this series. What I care the most is the generation to be fully 
separated from the rest."


I raised a valid point and it was totally ignored and you asked me to 
explain the rationale on a later point.

So if you choose to ignore my first point, how can I put any point.


Well, maybe you should read the e-mail more carefully because your point 
have been addressed. If they are not, then please say it rather than 
accusing the reviewers on spending not enough time on your series...


[...]

Now if you see both the codes are quite similar and there is redundancy 
in libxl and in xen code for preparing ACPI tables for dom0 and domU.
The point I am raising is quite clear, if all other tables like MADT, 
XSDT, RSDP, GTDT etc does not share a common generation code with xen 
what is so special about IORT.
Either we move all generation into a common code or keep redundancy for 
IORT.


I hope I have shown the code and made the point quite clear.
Please provide a technical answer rather than a simple "Why".


Why do you still continue arguing on how this is going to interact with 
libxl when your only work now (as I stated in every single e-mail) is 
for Dom0.


If the generation is generic enough, it will require little code to 
interface. After all, you only need:

- informations (e.g DeviceID, MasterID...)
- buffer for writing the generated IORT

So now it is maybe time for you to suggest an interface we can discuss on.

Cheers,

--
Julien Grall

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

  1   2   >