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

2017-10-11 Thread Yi Sun
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.

> > @@ -274,30 +280,30 @@ static enum psr_feat_type psr_type_to_feat_type(enum 
> > psr_type type)
> >  return feat_type;
> >  }
> >  
> > -static bool psr_check_cbm(unsigned int cbm_len, unsigned long cbm)
> > +/* Implementation of allocation features' functions. */
> > +static bool cat_check_cbm(const struct feat_node *feat, unsigned long *cbm)
> >  {
> >  unsigned int first_bit, zero_bit;
> > +unsigned int cbm_len = feat->cat.cbm_len;
> >  
> > -/* Set bits should only in the range of [0, cbm_len]. */
> > -if ( cbm & (~0ul << cbm_len) )
> > -return false;
> > -
> > -/* At least one bit need to be set. */
> > -if ( cbm == 0 )
> > +/*
> > + * Set bits should only in the range of [0, cbm_len].
> 
> As you alter the comment anyway, please also add the missing "be".
> Also - isn't the upper bound of the range exclusive, i.e. shouldn't
> this be [0, cbm_len)?
> 
Thanks!

> > + * And, at least one bit need to be set.
> > + */
> > +if ( *cbm & (~0ul << cbm_len) || *cbm == 0 )
> 
> Parentheses missing for the left side operand of || and if you omit
> != 0 on the left part (which I appreciate) please also use ! instead
> of == 0 on the right side.
> 
Got it.

> > +static bool mba_check_thrtl(const struct feat_node *feat, unsigned long 
> > *thrtl)
> > +{
> > +if ( *thrtl > feat->mba.thrtl_max )
> > +return false;
> > +
> > +/*
> > + * Per SDM (chapter "Memory Bandwidth Allocation Configuration"):
> > + * 1. Linear mode: In the linear mode the input precision is defined
> > + *as 100-(MBA_MAX). For instance, if the MBA_MAX value is 90, the
> > + *input precision is 10%. Values not an even multiple of the
> > + *precision (e.g., 12%) will be rounded down (e.g., to 10% delay
> > + *applied).
> > + * 2. Non-linear mode: Input delay values are powers-of-two from zero
> > + *to the MBA_MAX value from CPUID. In this case any values not a
> > + *power of two will be rounded down the next nearest power of two.
> > + */
> > +if ( feat->mba.linear )
> > +{
> > +unsigned int mod;
> > +
> > +if ( feat->mba.thrtl_max >= 100 )
> > +return false;
> 
> Don't you check this right after collecting CPUID output? If so,
> this should be at most an ASSERT().
> 
Yes, I have checked this in mba_init_feature. Will remove this check.

> > +mod = *thrtl % (100 - feat->mba.thrtl_max);
> > +*thrtl -= mod;
> 
> Do you really need the intermediate variable?
> 
Will remove 'mod'.

> > +}
> > +else
> > +{
> > +/* Not power of 2. */
> > +if ( *thrtl & (*thrtl - 1) )
> > +*thrtl = *thrtl & (1 << (flsl(*thrtl) - 1));
> 
> &= or even simply =.
> 
Ok, thanks!

> > @@ -950,6 +997,7 @@ static int insert_val_into_array(uint32_t val[],
> >  const struct feat_node *feat;
> >  const struct feat_props *props;
> >  unsigned int i;
> > +unsigned long check_val = new_val;
> >  int ret;
> >  
> >  ASSERT(feat_type < FEAT_TYPE_NUM);
> > @@ -974,9 +1022,11 @@ static int insert_val_into_array(uint32_t val[],
> >  if ( array_len < props->cos_num )
> >  return -ENOSPC;
> >  
> > -if ( !psr_check_cbm(feat->cat.cbm_len, new_val) )
> > +if ( !props->check_val(feat, _val) )
> >  return -EINVAL;
> >  
> > +new_val = check_val;
> 
> When the function pointer's parameter changes to uint32_t *
> you won't need the intermediate variable anymore afaict.
> 
> Jan

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


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

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

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   11 attempts
Testing same since   114376  2017-10-11 23:01:15 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 
  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


[Xen-devel] [linux-4.9 bisection] complete test-amd64-amd64-xl-pvh-amd

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

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

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  c7dfe4ac58dd9c8678126b78da961b233a49f3f9
  Bug not present: 3c44f8ed44ab559c7e5b58316751bea53adfd83b
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/114387/


  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/linux-4.9/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/linux-4.9/test-amd64-amd64-xl-pvh-amd.guest-start
 --summary-out=tmp/114387.bisection-summary --basis-template=114036 
--blessings=real,real-bisect linux-4.9 test-amd64-amd64-xl-pvh-amd guest-start
Searching for failure / basis pass:
 114230 fail [host=merlot1] / 114036 [host=rimava0] 113872 [host=merlot0] 
113860 [host=nocera0] 113736 ok.
Failure / basis pass flights: 114230 / 113736
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest f37eb7b586f1dd24a86c50278c65322fc6787722 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
7434775abf8fb2ca3b9e805d30656f4da8c08816 
dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e
Basis pass 089d7720383d7bc9ca6b8824a05dfa66f80d1f41 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
0b157f8d977a9425e2d8d510aa011c5d4f3ec247 
16b1414de91b5a82a0996c67f6db3af7d7e32873
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#089d7720383d7bc9ca6b8824a05dfa66f80d1f41-f37eb7b586f1dd24a86c50278c65322fc6787722
 
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#0b157f8d977a9425e2d8d510aa011c5d4f3ec247-7434775abf8fb2ca3b9e805d30656f4da8c08816
 
git://xenbits.xen.org/xen.git#16b1414de91b5a82a0996c67f6db3af7d7e32873-dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e
Loaded 9281 nodes in revision graph
Searching for test results:
 113680 [host=rimava1]
 113736 pass 089d7720383d7bc9ca6b8824a05dfa66f80d1f41 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
0b157f8d977a9425e2d8d510aa011c5d4f3ec247 
16b1414de91b5a82a0996c67f6db3af7d7e32873
 113860 [host=nocera0]
 113872 [host=merlot0]
 114036 [host=rimava0]
 114185 fail f37eb7b586f1dd24a86c50278c65322fc6787722 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
7434775abf8fb2ca3b9e805d30656f4da8c08816 
dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e
 114134 fail f37eb7b586f1dd24a86c50278c65322fc6787722 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
7434775abf8fb2ca3b9e805d30656f4da8c08816 
dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e
 114230 fail f37eb7b586f1dd24a86c50278c65322fc6787722 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
7434775abf8fb2ca3b9e805d30656f4da8c08816 
dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e
 114310 pass 089d7720383d7bc9ca6b8824a05dfa66f80d1f41 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
0b157f8d977a9425e2d8d510aa011c5d4f3ec247 
16b1414de91b5a82a0996c67f6db3af7d7e32873
 114326 pass 3806cea5c1c509ef66f2cc8a183021ca4f871923 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
0b157f8d977a9425e2d8d510aa011c5d4f3ec247 

Re: [Xen-devel] [PATCH v5] x86: psr: support co-exist features' values setting

2017-10-11 Thread Yi Sun
Many thanks for the changes! The changes look good to me and pass the test.

On 17-10-11 06:06:49, Jan Beulich wrote:
> >>> On 11.10.17 at 09:20,  wrote:
> > --- a/xen/arch/x86/psr.c
> > +++ b/xen/arch/x86/psr.c
> > @@ -,25 +,43 @@ static unsigned int get_socket_cpu(unsigned int 
> > socket)
> >  struct cos_write_info
> >  {
> >  unsigned int cos;
> > -struct feat_node *feature;
> >  const uint32_t *val;
> > -const struct feat_props *props;
> > +unsigned int array_len;
> >  };
> 
> The addition wants to go into the hole after "cos".
> 
> >  static void do_write_psr_msrs(void *data)
> >  {
> > -const struct cos_write_info *info = data;
> > -struct feat_node *feat = info->feature;
> > -const struct feat_props *props = info->props;
> > -unsigned int i, cos = info->cos, cos_num = props->cos_num;
> > +struct cos_write_info *info = data;
> 
> const
> 
> > +unsigned int i, index = 0, cos = info->cos;
> > +struct psr_socket_info *socket_info =
> 
> const
> 
> > +
> > get_socket_info(cpu_to_socket(smp_processor_id()));
> >  
> > -for ( i = 0; i < cos_num; i++ )
> > +/*
> > + * Iterate all featuers to write different value (not same as MSR) for
> > + * each feature.
> > + */
> > +for ( i = 0; i < ARRAY_SIZE(feat_props); i++ )
> >  {
> > -if ( feat->cos_reg_val[cos * cos_num + i] != info->val[i] )
> > +struct feat_node *feat = socket_info->features[i];
> > +const struct feat_props *props = feat_props[i];
> > +unsigned int cos_num, j;
> > +
> > +if ( !feat || !props )
> > +continue;
> > +
> > +cos_num = props->cos_num;
> > +ASSERT(info->array_len >= index + cos_num);
> 
> While this transformation from the original -ENOSPC return looks to
> be correct, but not obviously so, it would have been a good idea
> to mention this in the commit message. After all the above can be
> correct only if the original -ENOSPC return path could have been
> an ASSERT() as well.
> 
> > +for ( j = 0; j < cos_num; j++ )
> >  {
> > -feat->cos_reg_val[cos * cos_num + i] = info->val[i];
> > -props->write_msr(cos, info->val[i], props->type[i]);
> > +if ( feat->cos_reg_val[cos * cos_num + j] != info->val[index + 
> > j] )
> > +{
> > +feat->cos_reg_val[cos * cos_num + j] = info->val[index + 
> > j];
> > +props->write_msr(cos, info->val[index + j], 
> > props->type[j]);
> > +}
> >  }
> > +
> > +index += cos_num;
> 
> Looks like I only meant to comment on the uses of index above:
> If you incremented it alongside j, you could use just index in the
> respective array accesses, and you'd avoid the last statement
> above altogether.
> 
> In the interest of getting the patch in I'll see to make the
> adjustments myself. Please double check the result in case I end
> up committing what I've come up with.
> 
> Jan

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


[Xen-devel] [libvirt test] 114325: trouble: broken/pass

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

Failures and problems with tests :-(

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

Tests which did not succeed, but are not blocking:
 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 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  20e3217a54fa8fa25a3420ec8cfaeed343739f6f
baseline version:
 libvirt  c44b29aacb6a3f445ab06d61899a0308b9d6d0d3

Last test of basis   114088  2017-10-07 04:21:11 Z4 days
Testing same since   114325  2017-10-11 04:28:10 Z0 days1 attempts


People who touched revisions under test:
  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 broken  
 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

broken-job test-armhf-armhf-libvirt-xsm broken
broken-step test-armhf-armhf-libvirt-xsm host-install(4)

Not pushing.


commit 20e3217a54fa8fa25a3420ec8cfaeed343739f6f
Author: Marc Hartmayer 
Date:   Mon Oct 9 21:14:58 2017 +0200

lxc: Fixed indentation

Signed-off-by: Marc Hartmayer 
Reviewed-by: Bjoern Walk 
Reviewed-by: Boris Fiuczynski 

commit 7596b29fd1712384085dfa317a37941b78787cff
Author: Marc Hartmayer 
Date:   Mon Oct 9 21:14:57 2017 +0200

lxc: Fixed a typo

Signed-off-by: Marc Hartmayer 

[Xen-devel] [ovmf baseline-only test] 72229: all pass

2017-10-11 Thread Platform Team regression test user
This run is configured for baseline tests only.

flight 72229 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72229/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf a63be426f8e327181dda369348eae2768439536b
baseline version:
 ovmf 3673214c6e0eb94de9e52221cca454a3ba5976ab

Last test of basis72226  2017-10-11 02:23:02 Z0 days
Testing same since72229  2017-10-11 23:48:00 Z0 days1 attempts


People who touched revisions under test:
  Alexei Fedorov 
  Alexei Fedorov 
  Evan Lloyd 
  Star Zeng 

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



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


commit a63be426f8e327181dda369348eae2768439536b
Author: Alexei Fedorov 
Date:   Thu Jun 8 15:40:09 2017 +0100

ArmPlatformPkg: Store initial timer value

This commit adds support for storing initial timer value
logged at the beginning of firmware image execution.
This timer value is required for firmware basic boot performance
data record referenced by Firmware Performance Data Table (FPDT).

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Alexei Fedorov 
Signed-off-by: Evan Lloyd 
Reviewed-by: Graeme Gregory 
Reviewed-by: Leif Lindholm 

commit 234dbceff130e105aecd7e15227a8b03b0b96182
Author: Star Zeng 
Date:   Thu Oct 5 14:03:35 2017 +0800

ArmVirtPkg ArmVirtDxeHobLib: Implement BuildFv3Hob

Cc: Ard Biesheuvel 
Cc: Laszlo Ersek 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
Reviewed-by: Laszlo Ersek 

commit e39e40caa099dea852b9b190c0d148fed2472f3f
Author: Star Zeng 
Date:   Thu Oct 5 14:02:51 2017 +0800

EmbeddedPkg PrePiHobLib: Implement BuildFv3Hob

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Laszlo Ersek 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
Reviewed-by: Ard Biesheuvel 

commit 2331cab7d44f50d2ec4ed60ab5cc794131d7c0c2
Author: Star Zeng 
Date:   Tue Oct 3 21:33:04 2017 +0800

IntelFrameworkModulePkg FwVolDxe: Get FV auth status propagated from PEI

FV3 HOB was introduced by new (>= 1.5) PI spec, it is intended to
be used to propagate PEI-phase FV authentication status to DXE.
This patch is to update FwVolDxe to get the authentication status
propagated from PEI-phase to DXE by FV3 HOB when producing FV
protocol.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
Reviewed-by: Liming Gao 

commit c60370454e95be8d4a84b1dbb66c407efb729134
Author: Star Zeng 
Date:   Tue Oct 3 21:48:47 2017 +0800

MdeModulePkg Core: Propagate PEI-phase FV authentication status to DXE

FV3 HOB was introduced by new (>= 1.5) PI spec, it is intended to
be used to propagate PEI-phase FV authentication status to DXE.
This patch is to update PeiCore to build FV3 HOB with the
authentication status and DxeCore to get the authentication
status from FV3 HOB when producing FVB Protocol.

Cc: Liming Gao 
Contributed-under: TianoCore 

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

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

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   10 attempts
Testing same since   114376  2017-10-11 23:01:15 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 
  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


[Xen-devel] [xen-4.8-testing test] 114313: regressions - trouble: broken/fail/pass

2017-10-11 Thread osstest service owner
flight 114313 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114313/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-multivcpu broken
 test-armhf-armhf-xl-multivcpu  4 host-install(4)   broken REGR. vs. 114173
 test-xtf-amd64-amd64-5 48 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 114173
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
114173

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-1  48 xtf/test-hvm64-lbr-tsx-vmentry fail like 114093
 test-xtf-amd64-amd64-4  48 xtf/test-hvm64-lbr-tsx-vmentry fail like 114126
 test-xtf-amd64-amd64-3  48 xtf/test-hvm64-lbr-tsx-vmentry fail like 114173
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 114173
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114173
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114173
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 114173
 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-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 build-i386-prev   7 xen-build/dist-test  fail   never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 build-amd64-prev  7 xen-build/dist-test  fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-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  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail 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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-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
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install 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

version targeted for testing:
 xen  9f092f57d2829a271233aef1d1df0bff84275122
baseline version:
 xen  667f70e658c4c382672056ebaf1505b4c5cdb0aa

Last test of basis   114173  2017-10-09 03:27:38 Z2 days
Testing same since   114313  2017-10-11 00:46:14 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 
  Stefano Stabellini 

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

[Xen-devel] [ovmf test] 114319: all pass - PUSHED

2017-10-11 Thread osstest service owner
flight 114319 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114319/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf a63be426f8e327181dda369348eae2768439536b
baseline version:
 ovmf 3673214c6e0eb94de9e52221cca454a3ba5976ab

Last test of basis   114270  2017-10-10 11:02:07 Z1 days
Testing same since   114319  2017-10-11 02:22:41 Z0 days1 attempts


People who touched revisions under test:
  Alexei Fedorov 
  Alexei Fedorov 
  Evan Lloyd 
  Star Zeng 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=a63be426f8e327181dda369348eae2768439536b
+ . ./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 ovmf 
a63be426f8e327181dda369348eae2768439536b
+ branch=ovmf
+ revision=a63be426f8e327181dda369348eae2768439536b
+ . ./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=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.9-testing
+ '[' xa63be426f8e327181dda369348eae2768439536b = 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
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : 

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

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

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  a02bb8da9397d4d949dd74dbe5a7d850becd5736
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 Z0 days9 attempts
Testing same since   114371  2017-10-11 21:01:19 Z0 days1 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Andre Przywara 
  Andrew Cooper 
  Boris Ostrovsky 
  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 1038 lines long.)

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


[Xen-devel] [xen-4.9-testing test] 114312: regressions - trouble: blocked/broken/fail/pass

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  broken
 test-armhf-armhf-xl-multivcpu broken
 test-armhf-armhf-libvirt-raw broken
 test-armhf-armhf-xl   4 host-install(4)broken REGR. vs. 114118
 test-armhf-armhf-libvirt-raw  4 host-install(4)broken REGR. vs. 114118
 test-armhf-armhf-xl-multivcpu  4 host-install(4)   broken REGR. vs. 114118
 build-i386-prev   6 xen-buildfail REGR. vs. 114118

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  n/a
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 114091
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 114091
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 114118
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 114118
 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-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-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-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-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-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-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  d1b64ccd9694c32e6b499d8380507c22dcdef4e1
baseline version:
 xen  9cde7a833db53c9c3a88b767af8c7cb07053a6fd

Last test of basis   114118  2017-10-08 03:30:54 Z3 days
Testing same since   114312  2017-10-11 00:44:07 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 
  Stefano Stabellini 

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

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

2017-10-11 Thread Tom Lendacky
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.

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))?

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 
> config).
> 
> slab_test (average of 10 runs):
>   - PIE disabled: no significant change (-2% on latest run, likely noise).
>   - PIE enabled: between -1% and +0.8% on latest runs.
> 
> Kernbench (average of 10 Half and Optimal runs):
>   

Re: [Xen-devel] [PATCH v8 07/11] arm: smccc: handle SMCs according to SMCCC

2017-10-11 Thread Stefano Stabellini
On Tue, 10 Oct 2017, Volodymyr Babchuk wrote:
> SMCCC (SMC Call Convention) describes how to handle both HVCs and SMCs.
> SMCCC states that both HVC and SMC are valid conduits to call to different
> firmware functions. Thus, for example, PSCI calls can be made both by
> SMC or HVC. Also SMCCC defines function number coding for such calls.
> Besides functional calls there are query calls, which allows underling
> OS determine version, UUID and number of functions provided by service
> provider.
> 
> This patch adds new file `vsmc.c`, which handles both generic SMCs
> and HVC according to SMCCC. At this moment it implements only one
> service: Standard Hypervisor Service.
> 
> At this time Standard Hypervisor Service only supports query calls,
> so caller can ask about hypervisor UID and determine that it is XEN running.
> 
> This change allows more generic handling for SMCs and HVCs and it can
> be easily extended to support new services and functions.
> 
> But, before SMC is forwarded to standard SMCCC handler, it can be routed
> to a domain monitor, if one is installed.
> 
> Signed-off-by: Volodymyr Babchuk 
> Reviewed-by: Oleksandr Andrushchenko 
> Reviewed-by: Oleksandr Tyshchenko 
> Acked-by: Julien Grall 
> ---
>  xen/arch/arm/Makefile   |   1 +
>  xen/arch/arm/traps.c|  17 
>  xen/arch/arm/vsmc.c | 191 
> 
>  xen/include/asm-arm/traps.h |   3 +
>  xen/include/public/arch-arm/smccc.h |  58 +++
>  5 files changed, 253 insertions(+), 17 deletions(-)
>  create mode 100644 xen/arch/arm/vsmc.c
>  create mode 100644 xen/include/public/arch-arm/smccc.h
> 
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 424580b..30a2a65 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -53,6 +53,7 @@ obj-$(CONFIG_HAS_ITS) += vgic-v3-its.o
>  obj-y += vm_event.o
>  obj-y += vtimer.o
>  obj-$(CONFIG_SBSA_VUART_CONSOLE) += vpl011.o
> +obj-y += vsmc.o
>  obj-y += vpsci.o
>  obj-y += vuart.o
>  
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 5b91e6c..6ea0090 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2195,23 +2195,6 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>  inject_dabt_exception(regs, info.gva, hsr.len);
>  }
>  
> -static void do_trap_smc(struct cpu_user_regs *regs, const union hsr hsr)
> -{
> -int rc = 0;
> -
> -if ( !check_conditional_instr(regs, hsr) )
> -{
> -advance_pc(regs, hsr);
> -return;
> -}
> -
> -if ( current->domain->arch.monitor.privileged_call_enabled )
> -rc = monitor_smc();
> -
> -if ( rc != 1 )
> -inject_undef_exception(regs, hsr);
> -}
> -
>  static void enter_hypervisor_head(struct cpu_user_regs *regs)
>  {
>  if ( guest_mode(regs) )
> diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
> new file mode 100644
> index 000..38df821
> --- /dev/null
> +++ b/xen/arch/arm/vsmc.c
> @@ -0,0 +1,191 @@
> +/*
> + * xen/arch/arm/vsmc.c
> + *
> + * Generic handler for SMC and HVC calls according to
> + * ARM SMC calling convention
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Number of functions currently supported by Hypervisor Service. */
> +#define XEN_SMCCC_FUNCTION_COUNT 3
> +
> +static bool fill_uid(struct cpu_user_regs *regs, xen_uuid_t uuid)
> +{
> +int n;
> +
> +/*
> + * UID is returned in registers r0..r3, four bytes per register,
> + * first byte is stored in low-order bits of a register.
> + * (ARM DEN 0028B page 14)
> + */
> +for (n = 0; n < 4; n++)
> +{
> +const uint8_t *bytes = uuid.a + n * 4;
> +uint32_t r;
> +
> +r = bytes[0];
> +r |= bytes[1] << 8;
> +r |= bytes[2] << 16;
> +r |= bytes[3] << 24;
> +
> +set_user_reg(regs, n, r);
> +}
> +
> +return true;
> +}
> +
> +static bool fill_revision(struct cpu_user_regs *regs, uint32_t major,
> + uint32_t minor)
> +{
> +/*
> + * Revision is returned in registers r0 and r1.
> + * r0 stores major part of the version
> + * r1 stores minor part of the version
> + * (ARM DEN 0028B page 15)
> + */
> +set_user_reg(regs, 0, major);
> +set_user_reg(regs, 1, minor);
> +
> +return true;
> +}
> +

[Xen-devel] [PATCH v1 23/27] x86/modules: Adapt module loading for PIE support

2017-10-11 Thread Thomas Garnier
Adapt module loading to support PIE relocations. Generate dynamic GOT if
a symbol requires it but no entry exist in the kernel GOT.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/Makefile   |   4 +
 arch/x86/include/asm/module.h   |  11 +++
 arch/x86/include/asm/sections.h |   4 +
 arch/x86/kernel/module.c| 182 ++--
 arch/x86/kernel/module.lds  |   3 +
 5 files changed, 199 insertions(+), 5 deletions(-)
 create mode 100644 arch/x86/kernel/module.lds

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index de228200ef2a..b592d57c531b 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -134,7 +134,11 @@ else
 KBUILD_CFLAGS += $(cflags-y)
 
 KBUILD_CFLAGS += -mno-red-zone
+ifdef CONFIG_X86_PIE
+KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/x86/kernel/module.lds
+else
 KBUILD_CFLAGS += -mcmodel=kernel
+endif
 
 # -funit-at-a-time shrinks the kernel .text considerably
 # unfortunately it makes reading oopses harder.
diff --git a/arch/x86/include/asm/module.h b/arch/x86/include/asm/module.h
index 9eb7c718aaf8..21e0e02c0343 100644
--- a/arch/x86/include/asm/module.h
+++ b/arch/x86/include/asm/module.h
@@ -4,12 +4,23 @@
 #include 
 #include 
 
+#ifdef CONFIG_X86_PIE
+struct mod_got_sec {
+   struct elf64_shdr   *got;
+   int got_num_entries;
+   int got_max_entries;
+};
+#endif
+
 struct mod_arch_specific {
 #ifdef CONFIG_ORC_UNWINDER
unsigned int num_orcs;
int *orc_unwind_ip;
struct orc_entry *orc_unwind;
 #endif
+#ifdef CONFIG_X86_PIE
+   struct mod_got_sec  core;
+#endif
 };
 
 #ifdef CONFIG_X86_64
diff --git a/arch/x86/include/asm/sections.h b/arch/x86/include/asm/sections.h
index 6b2d496cf1aa..92d796109da1 100644
--- a/arch/x86/include/asm/sections.h
+++ b/arch/x86/include/asm/sections.h
@@ -15,4 +15,8 @@ extern char __end_rodata_hpage_align[];
 extern char __start_got[], __end_got[];
 #endif
 
+#if defined(CONFIG_X86_PIE)
+extern char __start_got[], __end_got[];
+#endif
+
 #endif /* _ASM_X86_SECTIONS_H */
diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
index 62e7d70aadd5..aed24dfac1d3 100644
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -77,6 +78,173 @@ static unsigned long int get_module_load_offset(void)
 }
 #endif
 
+#ifdef CONFIG_X86_PIE
+static u64 find_got_kernel_entry(Elf64_Sym *sym, const Elf64_Rela *rela)
+{
+   u64 *pos;
+
+   for (pos = (u64*)__start_got; pos < (u64*)__end_got; pos++) {
+   if (*pos == sym->st_value)
+   return (u64)pos + rela->r_addend;
+   }
+
+   return 0;
+}
+
+static u64 module_emit_got_entry(struct module *mod, void *loc,
+const Elf64_Rela *rela, Elf64_Sym *sym)
+{
+   struct mod_got_sec *gotsec = >arch.core;
+   u64 *got = (u64*)gotsec->got->sh_addr;
+   int i = gotsec->got_num_entries;
+   u64 ret;
+
+   /* Check if we can use the kernel GOT */
+   ret = find_got_kernel_entry(sym, rela);
+   if (ret)
+   return ret;
+
+   got[i] = sym->st_value;
+
+   /*
+* Check if the entry we just created is a duplicate. Given that the
+* relocations are sorted, this will be the last entry we allocated.
+* (if one exists).
+*/
+   if (i > 0 && got[i] == got[i - 2]) {
+   ret = (u64)[i - 1];
+   } else {
+   gotsec->got_num_entries++;
+   BUG_ON(gotsec->got_num_entries > gotsec->got_max_entries);
+   ret = (u64)[i];
+   }
+
+   return ret + rela->r_addend;
+}
+
+#define cmp_3way(a,b)  ((a) < (b) ? -1 : (a) > (b))
+
+static int cmp_rela(const void *a, const void *b)
+{
+   const Elf64_Rela *x = a, *y = b;
+   int i;
+
+   /* sort by type, symbol index and addend */
+   i = cmp_3way(ELF64_R_TYPE(x->r_info), ELF64_R_TYPE(y->r_info));
+   if (i == 0)
+   i = cmp_3way(ELF64_R_SYM(x->r_info), ELF64_R_SYM(y->r_info));
+   if (i == 0)
+   i = cmp_3way(x->r_addend, y->r_addend);
+   return i;
+}
+
+static bool duplicate_rel(const Elf64_Rela *rela, int num)
+{
+   /*
+* Entries are sorted by type, symbol index and addend. That means
+* that, if a duplicate entry exists, it must be in the preceding
+* slot.
+*/
+   return num > 0 && cmp_rela(rela + num, rela + num - 1) == 0;
+}
+
+static unsigned int count_gots(Elf64_Sym *syms, Elf64_Rela *rela, int num)
+{
+   unsigned int ret = 0;
+   Elf64_Sym *s;
+   int i;
+
+   for (i = 0; i < num; i++) {
+   switch (ELF64_R_TYPE(rela[i].r_info)) {
+   

[Xen-devel] [PATCH v1 19/27] x86: Support global stack cookie

2017-10-11 Thread Thomas Garnier
Add an off-by-default configuration option to use a global stack cookie
instead of the default TLS. This configuration option will only be used
with PIE binaries.

For kernel stack cookie, the compiler uses the mcmodel=kernel to switch
between the fs segment to gs segment. A PIE binary does not use
mcmodel=kernel because it can be relocated anywhere, therefore the
compiler will default to the fs segment register. This is going to be
fixed with a compiler change allowing to pick the segment register as
done on PowerPC. In the meantime, this configuration can be used to
support older compilers.

Signed-off-by: Thomas Garnier 
---
 arch/x86/Kconfig  | 11 +++
 arch/x86/Makefile |  9 +
 arch/x86/entry/entry_32.S |  3 ++-
 arch/x86/entry/entry_64.S |  3 ++-
 arch/x86/include/asm/processor.h  |  3 ++-
 arch/x86/include/asm/stackprotector.h | 19 ++-
 arch/x86/kernel/asm-offsets.c |  3 ++-
 arch/x86/kernel/asm-offsets_32.c  |  3 ++-
 arch/x86/kernel/asm-offsets_64.c  |  3 ++-
 arch/x86/kernel/cpu/common.c  |  3 ++-
 arch/x86/kernel/head_32.S |  3 ++-
 arch/x86/kernel/process.c |  5 +
 12 files changed, 55 insertions(+), 13 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 063f1e0d51aa..772ff3e0f623 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2133,6 +2133,17 @@ config RANDOMIZE_MEMORY_PHYSICAL_PADDING
 
   If unsure, leave at the default value.
 
+config X86_GLOBAL_STACKPROTECTOR
+   bool "Stack cookie using a global variable"
+   select CC_STACKPROTECTOR
+   ---help---
+  This option turns on the "stack-protector" GCC feature using a global
+  variable instead of a segment register. It is useful when the
+  compiler does not support custom segment registers when building a
+  position independent (PIE) binary.
+
+  If unsure, say N
+
 config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 6276572259c8..de228200ef2a 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -141,6 +141,15 @@ else
 KBUILD_CFLAGS += $(call cc-option,-funit-at-a-time)
 endif
 
+ifdef CONFIG_X86_GLOBAL_STACKPROTECTOR
+ifeq ($(call cc-option, -mstack-protector-guard=global),)
+$(error Cannot use CONFIG_X86_GLOBAL_STACKPROTECTOR: \
+-mstack-protector-guard=global not supported \
+by compiler)
+endif
+KBUILD_CFLAGS += -mstack-protector-guard=global
+endif
+
 ifdef CONFIG_X86_X32
x32_ld_ok := $(call try-run,\
/bin/echo -e '1: .quad 1b' | \
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index 8a13d468635a..ab3e5056722f 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -237,7 +237,8 @@ ENTRY(__switch_to_asm)
movl%esp, TASK_threadsp(%eax)
movlTASK_threadsp(%edx), %esp
 
-#ifdef CONFIG_CC_STACKPROTECTOR
+#if defined(CONFIG_CC_STACKPROTECTOR) && \
+   !defined(CONFIG_X86_GLOBAL_STACKPROTECTOR)
movlTASK_stack_canary(%edx), %ebx
movl%ebx, PER_CPU_VAR(stack_canary)+stack_canary_offset
 #endif
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index d3a52d2342af..01be62c1b436 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -390,7 +390,8 @@ ENTRY(__switch_to_asm)
movq%rsp, TASK_threadsp(%rdi)
movqTASK_threadsp(%rsi), %rsp
 
-#ifdef CONFIG_CC_STACKPROTECTOR
+#if defined(CONFIG_CC_STACKPROTECTOR) && \
+   !defined(CONFIG_X86_GLOBAL_STACKPROTECTOR)
movqTASK_stack_canary(%rsi), %rbx
movq%rbx, PER_CPU_VAR(irq_stack_union + stack_canary_offset)
 #endif
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index b09bd50b06c7..e3a7ef8d5fb8 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -394,7 +394,8 @@ DECLARE_PER_CPU(char *, irq_stack_ptr);
 DECLARE_PER_CPU(unsigned int, irq_count);
 extern asmlinkage void ignore_sysret(void);
 #else  /* X86_64 */
-#ifdef CONFIG_CC_STACKPROTECTOR
+#if defined(CONFIG_CC_STACKPROTECTOR) && \
+   defined(CONFIG_X86_GLOBAL_STACKPROTECTOR)
 /*
  * Make sure stack canary segment base is cached-aligned:
  *   "For Intel Atom processors, avoid non zero segment base address
diff --git a/arch/x86/include/asm/stackprotector.h 
b/arch/x86/include/asm/stackprotector.h
index 8abedf1d650e..66462d778dc5 100644
--- a/arch/x86/include/asm/stackprotector.h
+++ b/arch/x86/include/asm/stackprotector.h
@@ -51,6 +51,10 @@
 #define GDT_STACK_CANARY_INIT  \
[GDT_ENTRY_STACK_CANARY] = GDT_ENTRY_INIT(0x4090, 0, 0x18),
 
+#ifdef CONFIG_X86_GLOBAL_STACKPROTECTOR
+extern 

[Xen-devel] [PATCH v1 17/27] xen: Adapt assembly for PIE support

2017-10-11 Thread Thomas Garnier
Change the assembly code to use the new _ASM_GET_PTR macro which get a
symbol reference while being PIE compatible. Adapt the relocation tool
to ignore 32-bit Xen code.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/tools/relocs.c | 16 +++-
 arch/x86/xen/xen-head.S |  9 +
 arch/x86/xen/xen-pvh.S  | 13 +
 3 files changed, 29 insertions(+), 9 deletions(-)

diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index 5d3eb2760198..bc032ad88b22 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -831,6 +831,16 @@ static int is_percpu_sym(ElfW(Sym) *sym, const char 
*symname)
strncmp(symname, "init_per_cpu_", 13);
 }
 
+/*
+ * Check if the 32-bit relocation is within the xenpvh 32-bit code.
+ * If so, ignores it.
+ */
+static int is_in_xenpvh_assembly(ElfW(Addr) offset)
+{
+   ElfW(Sym) *sym = sym_lookup("pvh_start_xen");
+   return sym && (offset >= sym->st_value) &&
+   (offset < (sym->st_value + sym->st_size));
+}
 
 static int do_reloc64(struct section *sec, Elf_Rel *rel, ElfW(Sym) *sym,
  const char *symname)
@@ -892,8 +902,12 @@ static int do_reloc64(struct section *sec, Elf_Rel *rel, 
ElfW(Sym) *sym,
 * the relocations are processed.
 * Make sure that the offset will fit.
 */
-   if (r_type != R_X86_64_64 && (int32_t)offset != (int64_t)offset)
+   if (r_type != R_X86_64_64 &&
+   (int32_t)offset != (int64_t)offset) {
+   if (is_in_xenpvh_assembly(offset))
+   break;
die("Relocation offset doesn't fit in 32 bits\n");
+   }
 
if (r_type == R_X86_64_64)
add_reloc(, offset);
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 124941d09b2b..e5b7b9566191 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -25,14 +25,15 @@ ENTRY(startup_xen)
 
/* Clear .bss */
xor %eax,%eax
-   mov $__bss_start, %_ASM_DI
-   mov $__bss_stop, %_ASM_CX
+   _ASM_GET_PTR(__bss_start, %_ASM_DI)
+   _ASM_GET_PTR(__bss_stop, %_ASM_CX)
sub %_ASM_DI, %_ASM_CX
shr $__ASM_SEL(2, 3), %_ASM_CX
rep __ASM_SIZE(stos)
 
-   mov %_ASM_SI, xen_start_info
-   mov $init_thread_union+THREAD_SIZE, %_ASM_SP
+   _ASM_GET_PTR(xen_start_info, %_ASM_AX)
+   mov %_ASM_SI, (%_ASM_AX)
+   _ASM_GET_PTR(init_thread_union+THREAD_SIZE, %_ASM_SP)
 
jmp xen_start_kernel
 END(startup_xen)
diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S
index e1a5fbeae08d..43e234c7c2de 100644
--- a/arch/x86/xen/xen-pvh.S
+++ b/arch/x86/xen/xen-pvh.S
@@ -101,8 +101,8 @@ ENTRY(pvh_start_xen)
call xen_prepare_pvh
 
/* startup_64 expects boot_params in %rsi. */
-   mov $_pa(pvh_bootparams), %rsi
-   mov $_pa(startup_64), %rax
+   movabs $_pa(pvh_bootparams), %rsi
+   movabs $_pa(startup_64), %rax
jmp *%rax
 
 #else /* CONFIG_X86_64 */
@@ -137,10 +137,15 @@ END(pvh_start_xen)
 
.section ".init.data","aw"
.balign 8
+   /*
+* Use a quad for _pa(gdt_start) because PIE does not understand a
+* long is enough. The resulting value will still be in the lower long
+* part.
+*/
 gdt:
.word gdt_end - gdt_start
-   .long _pa(gdt_start)
-   .word 0
+   .quad _pa(gdt_start)
+   .balign 8
 gdt_start:
.quad 0x/* NULL descriptor */
.quad 0x/* reserved */
-- 
2.15.0.rc0.271.g36b669edcc-goog


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


[Xen-devel] [PATCH v1 25/27] x86/pie: Add option to build the kernel as PIE

2017-10-11 Thread Thomas Garnier
Add the CONFIG_X86_PIE option which builds the kernel as a Position
Independent Executable (PIE). The kernel is currently build with the
mcmodel=kernel option which forces it to stay on the top 2G of the
virtual address space. With PIE, the kernel will be able to move below
the current limit.

The --emit-relocs linker option was kept instead of using -pie to limit
the impact on mapped sections. Any incompatible relocation will be
catch by the arch/x86/tools/relocs binary at compile time.

If segment based stack cookies are enabled, try to use the compiler
option to select the segment register. If not available, automatically
enabled global stack cookie in auto mode. Otherwise, recommend
compiler update or global stack cookie option.

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 config).

slab_test (average of 10 runs):
 - PIE disabled: no significant change (-2% on latest run, likely noise).
 - PIE enabled: between -1% and +0.8% on latest runs.

Kernbench (average of 10 Half and Optimal runs):
 Elapsed Time:
 - PIE disabled: no significant change (avg -0.239%)
 - PIE enabled: average +0.07%
 System Time:
 - PIE disabled: no significant change (avg -0.277%)
 - PIE enabled: average +0.7%

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303

Signed-off-by: Thomas Garnier 

merge PIE
---
 arch/x86/Kconfig  |  7 +++
 arch/x86/Makefile | 27 +++
 2 files changed, 34 insertions(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 1f2b731c9ec3..bbd28a46ab55 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2148,6 +2148,13 @@ config X86_GLOBAL_STACKPROTECTOR
 
   If unsure, say N
 
+config X86_PIE
+   bool
+   depends on X86_64
+   select DEFAULT_HIDDEN
+   select DYNAMIC_MODULE_BASE
+   select MODULE_REL_CRCS if MODVERSIONS
+
 config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index b592d57c531b..beae9504c3f4 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -135,7 +135,34 @@ else
 
 KBUILD_CFLAGS += -mno-red-zone
 ifdef CONFIG_X86_PIE
+KBUILD_CFLAGS += -fPIC
 KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/x86/kernel/module.lds
+
+ifndef CONFIG_CC_STACKPROTECTOR_NONE
+ifndef CONFIG_X86_GLOBAL_STACKPROTECTOR
+stackseg-flag := -mstack-protector-guard-reg=%gs
+ifeq ($(call cc-option-yn,$(stackseg-flag)),n)
+ifdef CONFIG_CC_STACKPROTECTOR_AUTO
+$(warning Cannot use CONFIG_CC_STACKPROTECTOR_* while \
+building a position independent kernel. \
+Default to global stack protector \
+(CONFIG_X86_GLOBAL_STACKPROTECTOR).)
+CONFIG_X86_GLOBAL_STACKPROTECTOR := y
+KBUILD_CFLAGS += -DCONFIG_X86_GLOBAL_STACKPROTECTOR
+KBUILD_AFLAGS += -DCONFIG_X86_GLOBAL_STACKPROTECTOR
+else
+$(error echo Cannot use \
+CONFIG_CC_STACKPROTECTOR_(REGULAR|STRONG) \
+while building a position independent binary \
+Update your compiler or use \
+CONFIG_X86_GLOBAL_STACKPROTECTOR)
+endif
+else
+KBUILD_CFLAGS += $(stackseg-flag)
+endif
+endif
+endif
+
 else
 KBUILD_CFLAGS += -mcmodel=kernel
 endif
-- 
2.15.0.rc0.271.g36b669edcc-goog


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


[Xen-devel] [PATCH v1 27/27] x86/kaslr: Add option to extend KASLR range from 1GB to 3GB

2017-10-11 Thread Thomas Garnier
Add a new CONFIG_RANDOMIZE_BASE_LARGE option to benefit from PIE
support. It increases the KASLR range from 1GB to 3GB. The new range
stars at 0x just above the EFI memory region. This
option is off by default.

The boot code is adapted to create the appropriate page table spanning
three PUD pages.

The relocation table uses 64-bit integers generated with the updated
relocation tool with the large-reloc option.

Signed-off-by: Thomas Garnier 
---
 arch/x86/Kconfig | 21 +
 arch/x86/boot/compressed/Makefile|  5 +
 arch/x86/boot/compressed/misc.c  | 10 +-
 arch/x86/include/asm/page_64_types.h |  9 +
 arch/x86/kernel/head64.c | 15 ---
 arch/x86/kernel/head_64.S| 11 ++-
 6 files changed, 66 insertions(+), 5 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bbd28a46ab55..54627dd06348 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2155,6 +2155,27 @@ config X86_PIE
select DYNAMIC_MODULE_BASE
select MODULE_REL_CRCS if MODVERSIONS
 
+config RANDOMIZE_BASE_LARGE
+   bool "Increase the randomization range of the kernel image"
+   depends on X86_64 && RANDOMIZE_BASE
+   select X86_PIE
+   select X86_MODULE_PLTS if MODULES
+   default n
+   ---help---
+ Build the kernel as a Position Independent Executable (PIE) and
+ increase the available randomization range from 1GB to 3GB.
+
+ This option impacts performance on kernel CPU intensive workloads up
+ to 10% due to PIE generated code. Impact on user-mode processes and
+ typical usage would be significantly less (0.50% when you build the
+ kernel).
+
+ The kernel and modules will generate slightly more assembly (1 to 2%
+ increase on the .text sections). The vmlinux binary will be
+ significantly smaller due to less relocations.
+
+ If unsure say N
+
 config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP
diff --git a/arch/x86/boot/compressed/Makefile 
b/arch/x86/boot/compressed/Makefile
index 8a958274b54c..94dfee5a7cd2 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -112,7 +112,12 @@ $(obj)/vmlinux.bin: vmlinux FORCE
 
 targets += $(patsubst $(obj)/%,%,$(vmlinux-objs-y)) vmlinux.bin.all 
vmlinux.relocs
 
+# Large randomization require bigger relocation table
+ifeq ($(CONFIG_RANDOMIZE_BASE_LARGE),y)
+CMD_RELOCS = arch/x86/tools/relocs --large-reloc
+else
 CMD_RELOCS = arch/x86/tools/relocs
+endif
 quiet_cmd_relocs = RELOCS  $@
   cmd_relocs = $(CMD_RELOCS) $< > $@;$(CMD_RELOCS) --abs-relocs $<
 $(obj)/vmlinux.relocs: vmlinux FORCE
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index c14217cd0155..c1ac9f2e283d 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -169,10 +169,18 @@ void __puthex(unsigned long value)
 }
 
 #if CONFIG_X86_NEED_RELOCS
+
+/* Large randomization go lower than -2G and use large relocation table */
+#ifdef CONFIG_RANDOMIZE_BASE_LARGE
+typedef long rel_t;
+#else
+typedef int rel_t;
+#endif
+
 static void handle_relocations(void *output, unsigned long output_len,
   unsigned long virt_addr)
 {
-   int *reloc;
+   rel_t *reloc;
unsigned long delta, map, ptr;
unsigned long min_addr = (unsigned long)output;
unsigned long max_addr = min_addr + (VO___bss_start - VO__text);
diff --git a/arch/x86/include/asm/page_64_types.h 
b/arch/x86/include/asm/page_64_types.h
index 3f5f08b010d0..6b65f846dd64 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -48,7 +48,11 @@
 #define __PAGE_OFFSET   __PAGE_OFFSET_BASE
 #endif /* CONFIG_RANDOMIZE_MEMORY */
 
+#ifdef CONFIG_RANDOMIZE_BASE_LARGE
+#define __START_KERNEL_map _AC(0x, UL)
+#else
 #define __START_KERNEL_map _AC(0x8000, UL)
+#endif /* CONFIG_RANDOMIZE_BASE_LARGE */
 
 /* See Documentation/x86/x86_64/mm.txt for a description of the memory map. */
 #ifdef CONFIG_X86_5LEVEL
@@ -65,9 +69,14 @@
  * 512MiB by default, leaving 1.5GiB for modules once the page tables
  * are fully set up. If kernel ASLR is configured, it can extend the
  * kernel page table mapping, reducing the size of the modules area.
+ * On PIE, we relocate the binary 2G lower so add this extra space.
  */
 #if defined(CONFIG_RANDOMIZE_BASE)
+#ifdef CONFIG_RANDOMIZE_BASE_LARGE
+#define KERNEL_IMAGE_SIZE  (_AC(3, UL) * 1024 * 1024 * 1024)
+#else
 #define KERNEL_IMAGE_SIZE  (1024 * 1024 * 1024)
+#endif
 #else
 #define KERNEL_IMAGE_SIZE  (512 * 1024 * 1024)
 #endif
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index b6363f0d11a7..d603d0f5a40a 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -39,6 +39,7 @@ static 

[Xen-devel] [PATCH v1 26/27] x86/relocs: Add option to generate 64-bit relocations

2017-10-11 Thread Thomas Garnier
The x86 relocation tool generates a list of 32-bit signed integers. There
was no need to use 64-bit integers because all addresses where above the 2G
top of the memory.

This change add a large-reloc option to generate 64-bit unsigned integers.
It can be used when the kernel plan to go below the top 2G and 32-bit
integers are not enough.

Signed-off-by: Thomas Garnier 
---
 arch/x86/tools/relocs.c| 60 +-
 arch/x86/tools/relocs.h|  4 +--
 arch/x86/tools/relocs_common.c | 15 +++
 3 files changed, 60 insertions(+), 19 deletions(-)

diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index bc032ad88b22..e7497ea1fe76 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -12,8 +12,14 @@
 
 static Elf_Ehdr ehdr;
 
+#if ELF_BITS == 64
+typedef uint64_t rel_off_t;
+#else
+typedef uint32_t rel_off_t;
+#endif
+
 struct relocs {
-   uint32_t*offset;
+   rel_off_t   *offset;
unsigned long   count;
unsigned long   size;
 };
@@ -684,7 +690,7 @@ static void print_absolute_relocs(void)
printf("\n");
 }
 
-static void add_reloc(struct relocs *r, uint32_t offset)
+static void add_reloc(struct relocs *r, rel_off_t offset)
 {
if (r->count == r->size) {
unsigned long newsize = r->size + 5;
@@ -1058,26 +1064,48 @@ static void sort_relocs(struct relocs *r)
qsort(r->offset, r->count, sizeof(r->offset[0]), cmp_relocs);
 }
 
-static int write32(uint32_t v, FILE *f)
+static int write32(rel_off_t rel, FILE *f)
 {
-   unsigned char buf[4];
+   unsigned char buf[sizeof(uint32_t)];
+   uint32_t v = (uint32_t)rel;
 
put_unaligned_le32(v, buf);
-   return fwrite(buf, 1, 4, f) == 4 ? 0 : -1;
+   return fwrite(buf, 1, sizeof(buf), f) == sizeof(buf) ? 0 : -1;
 }
 
-static int write32_as_text(uint32_t v, FILE *f)
+static int write32_as_text(rel_off_t rel, FILE *f)
 {
+   uint32_t v = (uint32_t)rel;
return fprintf(f, "\t.long 0x%08"PRIx32"\n", v) > 0 ? 0 : -1;
 }
 
-static void emit_relocs(int as_text, int use_real_mode)
+static int write64(rel_off_t rel, FILE *f)
+{
+   unsigned char buf[sizeof(uint64_t)];
+   uint64_t v = (uint64_t)rel;
+
+   put_unaligned_le64(v, buf);
+   return fwrite(buf, 1, sizeof(buf), f) == sizeof(buf) ? 0 : -1;
+}
+
+static int write64_as_text(rel_off_t rel, FILE *f)
+{
+   uint64_t v = (uint64_t)rel;
+   return fprintf(f, "\t.quad 0x%016"PRIx64"\n", v) > 0 ? 0 : -1;
+}
+
+static void emit_relocs(int as_text, int use_real_mode, int use_large_reloc)
 {
int i;
-   int (*write_reloc)(uint32_t, FILE *) = write32;
+   int (*write_reloc)(rel_off_t, FILE *);
int (*do_reloc)(struct section *sec, Elf_Rel *rel, Elf_Sym *sym,
const char *symname);
 
+   if (use_large_reloc)
+   write_reloc = write64;
+   else
+   write_reloc = write32;
+
 #if ELF_BITS == 64
if (!use_real_mode)
do_reloc = do_reloc64;
@@ -1088,6 +1116,9 @@ static void emit_relocs(int as_text, int use_real_mode)
do_reloc = do_reloc32;
else
do_reloc = do_reloc_real;
+
+   /* Large relocations only for 64-bit */
+   use_large_reloc = 0;
 #endif
 
/* Collect up the relocations */
@@ -,8 +1142,13 @@ static void emit_relocs(int as_text, int use_real_mode)
 * gas will like.
 */
printf(".section \".data.reloc\",\"a\"\n");
-   printf(".balign 4\n");
-   write_reloc = write32_as_text;
+   if (use_large_reloc) {
+   printf(".balign 8\n");
+   write_reloc = write64_as_text;
+   } else {
+   printf(".balign 4\n");
+   write_reloc = write32_as_text;
+   }
}
 
if (use_real_mode) {
@@ -1180,7 +1216,7 @@ static void print_reloc_info(void)
 
 void process(FILE *fp, int use_real_mode, int as_text,
 int show_absolute_syms, int show_absolute_relocs,
-int show_reloc_info)
+int show_reloc_info, int use_large_reloc)
 {
regex_init(use_real_mode);
read_ehdr(fp);
@@ -1203,5 +1239,5 @@ void process(FILE *fp, int use_real_mode, int as_text,
print_reloc_info();
return;
}
-   emit_relocs(as_text, use_real_mode);
+   emit_relocs(as_text, use_real_mode, use_large_reloc);
 }
diff --git a/arch/x86/tools/relocs.h b/arch/x86/tools/relocs.h
index 1d23bf953a4a..cb771cc4412d 100644
--- a/arch/x86/tools/relocs.h
+++ b/arch/x86/tools/relocs.h
@@ -30,8 +30,8 @@ enum symtype {
 
 void process_32(FILE *fp, int use_real_mode, int as_text,
int show_absolute_syms, int show_absolute_relocs,
-   int show_reloc_info);
+   int show_reloc_info, int 

[Xen-devel] [PATCH v1 22/27] x86/modules: Add option to start module section after kernel

2017-10-11 Thread Thomas Garnier
Add an option so the module section is just after the mapped kernel. It
will ensure position independent modules are always at the right
distance from the kernel and do not require mcmodule=large. It also
optimize the available size for modules by getting rid of the empty
space on kernel randomization range.

Signed-off-by: Thomas Garnier 
---
 Documentation/x86/x86_64/mm.txt | 3 +++
 arch/x86/Kconfig| 4 
 arch/x86/include/asm/pgtable_64_types.h | 6 +-
 arch/x86/kernel/head64.c| 5 -
 arch/x86/mm/dump_pagetables.c   | 4 ++--
 5 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
index b0798e281aa6..b51d66386e32 100644
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -73,4 +73,7 @@ Note that if CONFIG_RANDOMIZE_MEMORY is enabled, the direct 
mapping of all
 physical memory, vmalloc/ioremap space and virtual memory map are randomized.
 Their order is preserved but their base will be offset early at boot time.
 
+If CONFIG_DYNAMIC_MODULE_BASE is enabled, the module section follows the end of
+the mapped kernel.
+
 -Andi Kleen, Jul 2004
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 772ff3e0f623..1f2b731c9ec3 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2133,6 +2133,10 @@ config RANDOMIZE_MEMORY_PHYSICAL_PADDING
 
   If unsure, leave at the default value.
 
+# Module section starts just after the end of the kernel module
+config DYNAMIC_MODULE_BASE
+   bool
+
 config X86_GLOBAL_STACKPROTECTOR
bool "Stack cookie using a global variable"
select CC_STACKPROTECTOR
diff --git a/arch/x86/include/asm/pgtable_64_types.h 
b/arch/x86/include/asm/pgtable_64_types.h
index 06470da156ba..e00fc429b898 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -6,6 +6,7 @@
 #ifndef __ASSEMBLY__
 #include 
 #include 
+#include 
 
 /*
  * These are used to make use of C type-checking..
@@ -18,7 +19,6 @@ typedef unsigned long pgdval_t;
 typedef unsigned long  pgprotval_t;
 
 typedef struct { pteval_t pte; } pte_t;
-
 #endif /* !__ASSEMBLY__ */
 
 #define SHARED_KERNEL_PMD  0
@@ -93,7 +93,11 @@ typedef struct { pteval_t pte; } pte_t;
 #define VMEMMAP_START  __VMEMMAP_BASE
 #endif /* CONFIG_RANDOMIZE_MEMORY */
 #define VMALLOC_END(VMALLOC_START + _AC((VMALLOC_SIZE_TB << 40) - 1, UL))
+#ifdef CONFIG_DYNAMIC_MODULE_BASE
+#define MODULES_VADDR   ALIGN(((unsigned long)_end + PAGE_SIZE), PMD_SIZE)
+#else
 #define MODULES_VADDR(__START_KERNEL_map + KERNEL_IMAGE_SIZE)
+#endif
 /* The module sections ends with the start of the fixmap */
 #define MODULES_END   __fix_to_virt(__end_of_fixed_addresses + 1)
 #define MODULES_LEN   (MODULES_END - MODULES_VADDR)
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 675f1dba3b21..b6363f0d11a7 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -321,12 +321,15 @@ asmlinkage __visible void __init x86_64_start_kernel(char 
* real_mode_data)
 * Build-time sanity checks on the kernel image and module
 * area mappings. (these are purely build-time and produce no code)
 */
+#ifndef CONFIG_DYNAMIC_MODULE_BASE
BUILD_BUG_ON(MODULES_VADDR < __START_KERNEL_map);
BUILD_BUG_ON(MODULES_VADDR - __START_KERNEL_map < KERNEL_IMAGE_SIZE);
-   BUILD_BUG_ON(MODULES_LEN + KERNEL_IMAGE_SIZE > 2*PUD_SIZE);
+   BUILD_BUG_ON(!IS_ENABLED(CONFIG_RANDOMIZE_BASE_LARGE) &&
+MODULES_LEN + KERNEL_IMAGE_SIZE > 2*PUD_SIZE);
BUILD_BUG_ON((__START_KERNEL_map & ~PMD_MASK) != 0);
BUILD_BUG_ON((MODULES_VADDR & ~PMD_MASK) != 0);
BUILD_BUG_ON(!(MODULES_VADDR > __START_KERNEL));
+#endif
BUILD_BUG_ON(!(((MODULES_END - 1) & PGDIR_MASK) ==
(__START_KERNEL & PGDIR_MASK)));
BUILD_BUG_ON(__fix_to_virt(__end_of_fixed_addresses) <= MODULES_END);
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 8691a57da63e..8565b2b45848 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -95,7 +95,7 @@ static struct addr_marker address_markers[] = {
{ EFI_VA_END,   "EFI Runtime Services" },
 # endif
{ __START_KERNEL_map,   "High Kernel Mapping" },
-   { MODULES_VADDR,"Modules" },
+   { 0/* MODULES_VADDR */, "Modules" },
{ MODULES_END,  "End Modules" },
 #else
{ PAGE_OFFSET,  "Kernel Mapping" },
@@ -529,7 +529,7 @@ static int __init pt_dump_init(void)
 # endif
address_markers[FIXADDR_START_NR].start_address = FIXADDR_START;
 #endif
-
+   address_markers[MODULES_VADDR_NR].start_address = MODULES_VADDR;
return 0;
 }
 __initcall(pt_dump_init);
-- 
2.15.0.rc0.271.g36b669edcc-goog


___
Xen-devel mailing list

[Xen-devel] [PATCH v1 07/27] x86: pm-trace - Adapt assembly for PIE support

2017-10-11 Thread Thomas Garnier
Change assembly to use the new _ASM_GET_PTR macro instead of _ASM_MOV for
the assembly to be PIE compatible.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/pm-trace.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/pm-trace.h b/arch/x86/include/asm/pm-trace.h
index 7b7ac42c3661..a3801261f0dd 100644
--- a/arch/x86/include/asm/pm-trace.h
+++ b/arch/x86/include/asm/pm-trace.h
@@ -7,7 +7,7 @@
 do {   \
if (pm_trace_enabled) { \
const void *tracedata;  \
-   asm volatile(_ASM_MOV " $1f,%0\n"   \
+   asm volatile(_ASM_GET_PTR(1f, %0) "\n"  \
 ".section .tracedata,\"a\"\n"  \
 "1:\t.word %c1\n\t"\
 _ASM_PTR " %c2\n"  \
-- 
2.15.0.rc0.271.g36b669edcc-goog


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


[Xen-devel] [PATCH v1 11/27] x86/power/64: Adapt assembly for PIE support

2017-10-11 Thread Thomas Garnier
Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/power/hibernate_asm_64.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/power/hibernate_asm_64.S 
b/arch/x86/power/hibernate_asm_64.S
index ce8da3a0412c..6fdd7bbc3c33 100644
--- a/arch/x86/power/hibernate_asm_64.S
+++ b/arch/x86/power/hibernate_asm_64.S
@@ -24,7 +24,7 @@
 #include 
 
 ENTRY(swsusp_arch_suspend)
-   movq$saved_context, %rax
+   leaqsaved_context(%rip), %rax
movq%rsp, pt_regs_sp(%rax)
movq%rbp, pt_regs_bp(%rax)
movq%rsi, pt_regs_si(%rax)
@@ -115,7 +115,7 @@ ENTRY(restore_registers)
movq%rax, %cr4;  # turn PGE back on
 
/* We don't restore %rax, it must be 0 anyway */
-   movq$saved_context, %rax
+   leaqsaved_context(%rip), %rax
movqpt_regs_sp(%rax), %rsp
movqpt_regs_bp(%rax), %rbp
movqpt_regs_si(%rax), %rsi
-- 
2.15.0.rc0.271.g36b669edcc-goog


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


[Xen-devel] [PATCH v1 10/27] x86/boot/64: Adapt assembly for PIE support

2017-10-11 Thread Thomas Garnier
Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Early at boot, the kernel is mapped at a temporary address while preparing
the page table. To know the changes needed for the page table with KASLR,
the boot code calculate the difference between the expected address of the
kernel and the one chosen by KASLR. It does not work with PIE because all
symbols in code are relatives. Instead of getting the future relocated
virtual address, you will get the current temporary mapping. The solution
is using global variables that will be relocated as expected.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/kernel/head_64.S | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 42e32c2e51bb..32d1899f48df 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -86,8 +86,21 @@ startup_64:
popq%rsi
 
/* Form the CR3 value being sure to include the CR3 modifier */
-   addq$(early_top_pgt - __START_KERNEL_map), %rax
+   addq_early_top_pgt_offset(%rip), %rax
jmp 1f
+
+   /*
+* Position Independent Code takes only relative references in code
+* meaning a global variable address is relative to RIP and not its
+* future virtual address. Global variables can be used instead as they
+* are still relocated on the expected kernel mapping address.
+*/
+   .align 8
+_early_top_pgt_offset:
+   .quad early_top_pgt - __START_KERNEL_map
+_init_top_offset:
+   .quad init_top_pgt - __START_KERNEL_map
+
 ENTRY(secondary_startup_64)
UNWIND_HINT_EMPTY
/*
@@ -116,7 +129,7 @@ ENTRY(secondary_startup_64)
popq%rsi
 
/* Form the CR3 value being sure to include the CR3 modifier */
-   addq$(init_top_pgt - __START_KERNEL_map), %rax
+   addq_init_top_offset(%rip), %rax
 1:
 
/* Enable PAE mode, PGE and LA57 */
@@ -131,7 +144,7 @@ ENTRY(secondary_startup_64)
movq%rax, %cr3
 
/* Ensure I am executing from virtual addresses */
-   movq$1f, %rax
+   movabs  $1f, %rax
jmp *%rax
 1:
UNWIND_HINT_EMPTY
@@ -230,11 +243,12 @@ ENTRY(secondary_startup_64)
 *  REX.W + FF /5 JMP m16:64 Jump far, absolute indirect,
 *  address given in m16:64.
 */
-   pushq   $.Lafter_lret   # put return address on stack for unwinder
+   leaq.Lafter_lret(%rip), %rax
+   pushq   %rax# put return address on stack for unwinder
xorq%rbp, %rbp  # clear frame pointer
-   movqinitial_code(%rip), %rax
+   leaqinitial_code(%rip), %rax
pushq   $__KERNEL_CS# set correct cs
-   pushq   %rax# target address in negative space
+   pushq   (%rax)  # target address in negative space
lretq
 .Lafter_lret:
 END(secondary_startup_64)
-- 
2.15.0.rc0.271.g36b669edcc-goog


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


[Xen-devel] [PATCH v1 24/27] x86/mm: Make the x86 GOT read-only

2017-10-11 Thread Thomas Garnier
The GOT is changed during early boot when relocations are applied. Make
it read-only directly. This table exists only for PIE binary.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 include/asm-generic/vmlinux.lds.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index e549bff87c5b..a2301c292e26 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -279,6 +279,17 @@
VMLINUX_SYMBOL(__end_ro_after_init) = .;
 #endif
 
+#ifdef CONFIG_X86_PIE
+#define RO_GOT_X86 \
+   .got: AT(ADDR(.got) - LOAD_OFFSET) {\
+   VMLINUX_SYMBOL(__start_got) = .;\
+   *(.got);\
+   VMLINUX_SYMBOL(__end_got) = .;  \
+   }
+#else
+#define RO_GOT_X86
+#endif
+
 /*
  * Read only Data
  */
@@ -335,6 +346,7 @@
VMLINUX_SYMBOL(__end_builtin_fw) = .;   \
}   \
\
+   RO_GOT_X86  \
TRACEDATA   \
\
/* Kernel symbol table: Normal symbols */   \
-- 
2.15.0.rc0.271.g36b669edcc-goog


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


[Xen-devel] [PATCH v1 21/27] x86/mm/dump_pagetables: Fix address markers index on x86_64

2017-10-11 Thread Thomas Garnier
The address_markers_idx enum is not aligned with the table when EFI is
enabled. Add an EFI_VA_END_NR entry in this case.

Signed-off-by: Thomas Garnier 
---
 arch/x86/mm/dump_pagetables.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 5e3ac6fe6c9e..8691a57da63e 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -52,12 +52,15 @@ enum address_markers_idx {
LOW_KERNEL_NR,
VMALLOC_START_NR,
VMEMMAP_START_NR,
-#ifdef CONFIG_KASAN
+# ifdef CONFIG_KASAN
KASAN_SHADOW_START_NR,
KASAN_SHADOW_END_NR,
-#endif
+# endif
 # ifdef CONFIG_X86_ESPFIX64
ESPFIX_START_NR,
+# endif
+# ifdef CONFIG_EFI
+   EFI_VA_END_NR,
 # endif
HIGH_KERNEL_NR,
MODULES_VADDR_NR,
-- 
2.15.0.rc0.271.g36b669edcc-goog


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


[Xen-devel] [PATCH v1 02/27] x86: Use symbol name on bug table for PIE support

2017-10-11 Thread Thomas Garnier
Replace the %c constraint with %P. The %c is incompatible with PIE
because it implies an immediate value whereas %P reference a symbol.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/bug.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
index aa6b2023d8f8..1210d22ad547 100644
--- a/arch/x86/include/asm/bug.h
+++ b/arch/x86/include/asm/bug.h
@@ -37,7 +37,7 @@ do {  
\
asm volatile("1:\t" ins "\n"\
 ".pushsection __bug_table,\"aw\"\n"\
 "2:\t" __BUG_REL(1b) "\t# bug_entry::bug_addr\n"   \
-"\t"  __BUG_REL(%c0) "\t# bug_entry::file\n"   \
+"\t"  __BUG_REL(%P0) "\t# bug_entry::file\n"   \
 "\t.word %c1""\t# bug_entry::line\n"   \
 "\t.word %c2""\t# bug_entry::flags\n"  \
 "\t.org 2b+%c3\n"  \
-- 
2.15.0.rc0.271.g36b669edcc-goog


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


[Xen-devel] [PATCH v1 05/27] x86: relocate_kernel - Adapt assembly for PIE support

2017-10-11 Thread Thomas Garnier
Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/kernel/relocate_kernel_64.S | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/relocate_kernel_64.S 
b/arch/x86/kernel/relocate_kernel_64.S
index 307d3bac5f04..2ecbdcbe985b 100644
--- a/arch/x86/kernel/relocate_kernel_64.S
+++ b/arch/x86/kernel/relocate_kernel_64.S
@@ -200,9 +200,11 @@ identity_mapped:
movq%rax, %cr3
lea PAGE_SIZE(%r8), %rsp
callswap_pages
-   movq$virtual_mapped, %rax
-   pushq   %rax
-   ret
+   jmp *virtual_mapped_addr(%rip)
+
+   /* Absolute value for PIE support */
+virtual_mapped_addr:
+   .quad virtual_mapped
 
 virtual_mapped:
movqRSP(%r8), %rsp
-- 
2.15.0.rc0.271.g36b669edcc-goog


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


[Xen-devel] [PATCH v1 20/27] x86/ftrace: Adapt function tracing for PIE support

2017-10-11 Thread Thomas Garnier
When using -fPIE/PIC with function tracing, the compiler generates a
call through the GOT (call *__fentry__@GOTPCREL). This instruction
takes 6 bytes instead of 5 on the usual relative call.

If PIE is enabled, replace the 6th byte of the GOT call by a 1-byte nop
so ftrace can handle the previous 5-bytes as before.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/ftrace.h   |  6 --
 arch/x86/include/asm/sections.h |  4 
 arch/x86/kernel/ftrace.c| 42 +++--
 3 files changed, 48 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
index eccd0ac6bc38..183990157a5e 100644
--- a/arch/x86/include/asm/ftrace.h
+++ b/arch/x86/include/asm/ftrace.h
@@ -24,9 +24,11 @@ extern void __fentry__(void);
 static inline unsigned long ftrace_call_adjust(unsigned long addr)
 {
/*
-* addr is the address of the mcount call instruction.
-* recordmcount does the necessary offset calculation.
+* addr is the address of the mcount call instruction. PIE has always a
+* byte added to the start of the function.
 */
+   if (IS_ENABLED(CONFIG_X86_PIE))
+   addr -= 1;
return addr;
 }
 
diff --git a/arch/x86/include/asm/sections.h b/arch/x86/include/asm/sections.h
index 2f75f30cb2f6..6b2d496cf1aa 100644
--- a/arch/x86/include/asm/sections.h
+++ b/arch/x86/include/asm/sections.h
@@ -11,4 +11,8 @@ extern struct exception_table_entry __stop___ex_table[];
 extern char __end_rodata_hpage_align[];
 #endif
 
+#if defined(CONFIG_X86_PIE)
+extern char __start_got[], __end_got[];
+#endif
+
 #endif /* _ASM_X86_SECTIONS_H */
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index 9bef1bbeba63..a253601e783b 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -101,7 +101,7 @@ static const unsigned char *ftrace_nop_replace(void)
 
 static int
 ftrace_modify_code_direct(unsigned long ip, unsigned const char *old_code,
-  unsigned const char *new_code)
+ unsigned const char *new_code)
 {
unsigned char replaced[MCOUNT_INSN_SIZE];
 
@@ -134,6 +134,44 @@ ftrace_modify_code_direct(unsigned long ip, unsigned const 
char *old_code,
return 0;
 }
 
+/* Bytes before call GOT offset */
+const unsigned char got_call_preinsn[] = { 0xff, 0x15 };
+
+static int
+ftrace_modify_initial_code(unsigned long ip, unsigned const char *old_code,
+  unsigned const char *new_code)
+{
+   unsigned char replaced[MCOUNT_INSN_SIZE + 1];
+
+   ftrace_expected = old_code;
+
+   /*
+* If PIE is not enabled or no GOT call was found, default to the
+* original approach to code modification.
+*/
+   if (!IS_ENABLED(CONFIG_X86_PIE)
+   || probe_kernel_read(replaced, (void *)ip, sizeof(replaced))
+   || memcmp(replaced, got_call_preinsn, sizeof(got_call_preinsn)))
+   return ftrace_modify_code_direct(ip, old_code, new_code);
+
+   /*
+* Build a nop slide with a 5-byte nop and 1-byte nop to keep the ftrace
+* hooking algorithm working with the expected 5 bytes instruction.
+*/
+   memcpy(replaced, new_code, MCOUNT_INSN_SIZE);
+   replaced[MCOUNT_INSN_SIZE] = ideal_nops[1][0];
+
+   ip = text_ip_addr(ip);
+
+   if (probe_kernel_write((void *)ip, replaced, sizeof(replaced)))
+   return -EPERM;
+
+   sync_core();
+
+   return 0;
+
+}
+
 int ftrace_make_nop(struct module *mod,
struct dyn_ftrace *rec, unsigned long addr)
 {
@@ -152,7 +190,7 @@ int ftrace_make_nop(struct module *mod,
 * just modify the code directly.
 */
if (addr == MCOUNT_ADDR)
-   return ftrace_modify_code_direct(rec->ip, old, new);
+   return ftrace_modify_initial_code(rec->ip, old, new);
 
ftrace_expected = NULL;
 
-- 
2.15.0.rc0.271.g36b669edcc-goog


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


[Xen-devel] [PATCH v1 06/27] x86/entry/64: Adapt assembly for PIE support

2017-10-11 Thread Thomas Garnier
Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/entry/entry_64.S | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 49167258d587..15bd5530d2ae 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -194,12 +194,15 @@ entry_SYSCALL_64_fastpath:
ja  1f  /* return -ENOSYS (already in 
pt_regs->ax) */
movq%r10, %rcx
 
+   /* Ensures the call is position independent */
+   leaqsys_call_table(%rip), %r11
+
/*
 * This call instruction is handled specially in stub_ptregs_64.
 * It might end up jumping to the slow path.  If it jumps, RAX
 * and all argument registers are clobbered.
 */
-   call*sys_call_table(, %rax, 8)
+   call*(%r11, %rax, 8)
 .Lentry_SYSCALL_64_after_fastpath_call:
 
movq%rax, RAX(%rsp)
@@ -334,7 +337,8 @@ ENTRY(stub_ptregs_64)
 * RAX stores a pointer to the C function implementing the syscall.
 * IRQs are on.
 */
-   cmpq$.Lentry_SYSCALL_64_after_fastpath_call, (%rsp)
+   leaq.Lentry_SYSCALL_64_after_fastpath_call(%rip), %r11
+   cmpq%r11, (%rsp)
jne 1f
 
/*
@@ -1172,7 +1176,8 @@ ENTRY(error_entry)
movl%ecx, %eax  /* zero extend */
cmpq%rax, RIP+8(%rsp)
je  .Lbstep_iret
-   cmpq$.Lgs_change, RIP+8(%rsp)
+   leaq.Lgs_change(%rip), %rcx
+   cmpq%rcx, RIP+8(%rsp)
jne .Lerror_entry_done
 
/*
@@ -1383,10 +1388,10 @@ ENTRY(nmi)
 * resume the outer NMI.
 */
 
-   movq$repeat_nmi, %rdx
+   leaqrepeat_nmi(%rip), %rdx
cmpq8(%rsp), %rdx
ja  1f
-   movq$end_repeat_nmi, %rdx
+   leaqend_repeat_nmi(%rip), %rdx
cmpq8(%rsp), %rdx
ja  nested_nmi_out
 1:
@@ -1440,7 +1445,8 @@ nested_nmi:
pushq   %rdx
pushfq
pushq   $__KERNEL_CS
-   pushq   $repeat_nmi
+   leaqrepeat_nmi(%rip), %rdx
+   pushq   %rdx
 
/* Put stack back */
addq$(6*8), %rsp
@@ -1479,7 +1485,9 @@ first_nmi:
addq$8, (%rsp)  /* Fix up RSP */
pushfq  /* RFLAGS */
pushq   $__KERNEL_CS/* CS */
-   pushq   $1f /* RIP */
+   pushq   %rax/* Support Position Independent Code */
+   leaq1f(%rip), %rax  /* RIP */
+   xchgq   %rax, (%rsp)/* Restore RAX, put 1f */
INTERRUPT_RETURN/* continues at repeat_nmi below */
UNWIND_HINT_IRET_REGS
 1:
-- 
2.15.0.rc0.271.g36b669edcc-goog


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


[Xen-devel] [PATCH v1 14/27] x86/percpu: Adapt percpu for PIE support

2017-10-11 Thread Thomas Garnier
Perpcu uses a clever design where the .percu ELF section has a virtual
address of zero and the relocation code avoid relocating specific
symbols. It makes the code simple and easily adaptable with or without
SMP support.

This design is incompatible with PIE because generated code always try to
access the zero virtual address relative to the default mapping address.
It becomes impossible when KASLR is configured to go below -2G. This
patch solves this problem by removing the zero mapping and adapting the GS
base to be relative to the expected address. These changes are done only
when PIE is enabled. The original implementation is kept as-is
by default.

The assembly and PER_CPU macros are changed to use relative references
when PIE is enabled.

The KALLSYMS_ABSOLUTE_PERCPU configuration is disabled with PIE given
percpu symbols are not absolute in this case.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/entry/entry_64.S  |  4 ++--
 arch/x86/include/asm/percpu.h  | 25 +++--
 arch/x86/kernel/cpu/common.c   |  4 +++-
 arch/x86/kernel/head_64.S  |  4 
 arch/x86/kernel/setup_percpu.c |  2 +-
 arch/x86/kernel/vmlinux.lds.S  | 13 +++--
 arch/x86/lib/cmpxchg16b_emu.S  |  8 
 arch/x86/xen/xen-asm.S | 12 ++--
 init/Kconfig   |  2 +-
 9 files changed, 51 insertions(+), 23 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 15bd5530d2ae..d3a52d2342af 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -392,7 +392,7 @@ ENTRY(__switch_to_asm)
 
 #ifdef CONFIG_CC_STACKPROTECTOR
movqTASK_stack_canary(%rsi), %rbx
-   movq%rbx, PER_CPU_VAR(irq_stack_union)+stack_canary_offset
+   movq%rbx, PER_CPU_VAR(irq_stack_union + stack_canary_offset)
 #endif
 
/* restore callee-saved registers */
@@ -808,7 +808,7 @@ apicinterrupt IRQ_WORK_VECTOR   
irq_work_interrupt  smp_irq_work_interrupt
 /*
  * Exception entry points.
  */
-#define CPU_TSS_IST(x) PER_CPU_VAR(cpu_tss) + (TSS_ist + ((x) - 1) * 8)
+#define CPU_TSS_IST(x) PER_CPU_VAR(cpu_tss + (TSS_ist + ((x) - 1) * 8))
 
 .macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1
 ENTRY(\sym)
diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
index b21a475fd7ed..07250f1099b5 100644
--- a/arch/x86/include/asm/percpu.h
+++ b/arch/x86/include/asm/percpu.h
@@ -4,9 +4,11 @@
 #ifdef CONFIG_X86_64
 #define __percpu_seg   gs
 #define __percpu_mov_opmovq
+#define __percpu_rel   (%rip)
 #else
 #define __percpu_seg   fs
 #define __percpu_mov_opmovl
+#define __percpu_rel
 #endif
 
 #ifdef __ASSEMBLY__
@@ -27,10 +29,14 @@
 #define PER_CPU(var, reg)  \
__percpu_mov_op %__percpu_seg:this_cpu_off, reg;\
lea var(reg), reg
-#define PER_CPU_VAR(var)   %__percpu_seg:var
+/* Compatible with Position Independent Code */
+#define PER_CPU_VAR(var)   %__percpu_seg:(var)##__percpu_rel
+/* Rare absolute reference */
+#define PER_CPU_VAR_ABS(var)   %__percpu_seg:var
 #else /* ! SMP */
 #define PER_CPU(var, reg)  __percpu_mov_op $var, reg
-#define PER_CPU_VAR(var)   var
+#define PER_CPU_VAR(var)   (var)##__percpu_rel
+#define PER_CPU_VAR_ABS(var)   var
 #endif /* SMP */
 
 #ifdef CONFIG_X86_64_SMP
@@ -208,27 +214,34 @@ do {  
\
pfo_ret__;  \
 })
 
+/* Position Independent code uses relative addresses only */
+#ifdef CONFIG_X86_PIE
+#define __percpu_stable_arg __percpu_arg(a1)
+#else
+#define __percpu_stable_arg __percpu_arg(P1)
+#endif
+
 #define percpu_stable_op(op, var)  \
 ({ \
typeof(var) pfo_ret__;  \
switch (sizeof(var)) {  \
case 1: \
-   asm(op "b "__percpu_arg(P1)",%0"\
+   asm(op "b "__percpu_stable_arg ",%0"\
: "=q" (pfo_ret__)  \
: "p" (&(var)));\
break;  \
case 2: \
-   asm(op "w "__percpu_arg(P1)",%0"\
+   asm(op "w "__percpu_stable_arg ",%0"\
: "=r" (pfo_ret__)  \
: "p" (&(var)));\
break;  \
case 4: \
-   asm(op "l "__percpu_arg(P1)",%0"

[Xen-devel] [PATCH v1 18/27] kvm: Adapt assembly for PIE support

2017-10-11 Thread Thomas Garnier
Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible. The new __ASM_GET_PTR_PRE macro is used to
get the address of a symbol on both 32 and 64-bit with PIE support.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/kvm_host.h | 6 --
 arch/x86/kernel/kvm.c   | 6 --
 arch/x86/kvm/svm.c  | 4 ++--
 3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 9d7d856b2d89..14073fda75fb 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1342,9 +1342,11 @@ asmlinkage void kvm_spurious_fault(void);
".pushsection .fixup, \"ax\" \n" \
"667: \n\t" \
cleanup_insn "\n\t"   \
-   "cmpb $0, kvm_rebooting \n\t" \
+   "cmpb $0, kvm_rebooting" __ASM_SEL(,(%%rip)) " \n\t" \
"jne 668b \n\t"   \
-   __ASM_SIZE(push) " $666b \n\t"\
+   __ASM_SIZE(push) "%%" _ASM_AX " \n\t"   \
+   __ASM_GET_PTR_PRE(666b) "%%" _ASM_AX "\n\t" \
+   "xchg %%" _ASM_AX ", (%%" _ASM_SP ") \n\t"  \
"call kvm_spurious_fault \n\t"\
".popsection \n\t" \
_ASM_EXTABLE(666b, 667b)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 8bb9594d0761..4464c3667831 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -627,8 +627,10 @@ asm(
 ".global __raw_callee_save___kvm_vcpu_is_preempted;"
 ".type __raw_callee_save___kvm_vcpu_is_preempted, @function;"
 "__raw_callee_save___kvm_vcpu_is_preempted:"
-"movq  __per_cpu_offset(,%rdi,8), %rax;"
-"cmpb  $0, " __stringify(KVM_STEAL_TIME_preempted) "+steal_time(%rax);"
+"leaq  __per_cpu_offset(%rip), %rax;"
+"movq  (%rax,%rdi,8), %rax;"
+"addq  " __stringify(KVM_STEAL_TIME_preempted) "+steal_time(%rip), %rax;"
+"cmpb  $0, (%rax);"
 "setne %al;"
 "ret;"
 ".popsection");
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 0e68f0b3cbf7..364536080438 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -568,12 +568,12 @@ static u32 svm_msrpm_offset(u32 msr)
 
 static inline void clgi(void)
 {
-   asm volatile (__ex(SVM_CLGI));
+   asm volatile (__ex(SVM_CLGI) : :);
 }
 
 static inline void stgi(void)
 {
-   asm volatile (__ex(SVM_STGI));
+   asm volatile (__ex(SVM_STGI) : :);
 }
 
 static inline void invlpga(unsigned long addr, u32 asid)
-- 
2.15.0.rc0.271.g36b669edcc-goog


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


[Xen-devel] [PATCH v1 13/27] x86/boot/64: Use _text in a global for PIE support

2017-10-11 Thread Thomas Garnier
By default PIE generated code create only relative references so _text
points to the temporary virtual address. Instead use a global variable
so the relocation is done as expected.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/kernel/head64.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index bab4fa579450..675f1dba3b21 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -45,8 +45,14 @@ static void __head *fixup_pointer(void *ptr, unsigned long 
physaddr)
return ptr - (void *)_text + (void *)physaddr;
 }
 
-unsigned long __head __startup_64(unsigned long physaddr,
- struct boot_params *bp)
+/*
+ * Use a global variable to properly calculate _text delta on PIE. By default
+ * a PIE binary do a RIP relative difference instead of the relocated address.
+ */
+unsigned long _text_offset = (unsigned long)(_text - __START_KERNEL_map);
+
+unsigned long __head notrace __startup_64(unsigned long physaddr,
+ struct boot_params *bp)
 {
unsigned long load_delta, *p;
unsigned long pgtable_flags;
@@ -65,7 +71,7 @@ unsigned long __head __startup_64(unsigned long physaddr,
 * Compute the delta between the address I am compiled to run at
 * and the address I am actually running at.
 */
-   load_delta = physaddr - (unsigned long)(_text - __START_KERNEL_map);
+   load_delta = physaddr - _text_offset;
 
/* Is the address not 2M aligned? */
if (load_delta & ~PMD_PAGE_MASK)
-- 
2.15.0.rc0.271.g36b669edcc-goog


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


[Xen-devel] [PATCH v1 16/27] x86/relocs: Handle PIE relocations

2017-10-11 Thread Thomas Garnier
Change the relocation tool to correctly handle relocations generated by
-fPIE option:

 - Add relocation for each entry of the .got section given the linker does not
   generate R_X86_64_GLOB_DAT on a simple link.
 - Ignore R_X86_64_GOTPCREL and R_X86_64_PLT32.

Signed-off-by: Thomas Garnier 
---
 arch/x86/tools/relocs.c | 94 -
 1 file changed, 93 insertions(+), 1 deletion(-)

diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index 73eb7fd4aec4..5d3eb2760198 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -31,6 +31,7 @@ struct section {
Elf_Sym*symtab;
Elf_Rel*reltab;
char   *strtab;
+   Elf_Addr   *got;
 };
 static struct section *secs;
 
@@ -292,6 +293,35 @@ static Elf_Sym *sym_lookup(const char *symname)
return 0;
 }
 
+static Elf_Sym *sym_lookup_addr(Elf_Addr addr, const char **name)
+{
+   int i;
+   for (i = 0; i < ehdr.e_shnum; i++) {
+   struct section *sec = [i];
+   long nsyms;
+   Elf_Sym *symtab;
+   Elf_Sym *sym;
+
+   if (sec->shdr.sh_type != SHT_SYMTAB)
+   continue;
+
+   nsyms = sec->shdr.sh_size/sizeof(Elf_Sym);
+   symtab = sec->symtab;
+
+   for (sym = symtab; --nsyms >= 0; sym++) {
+   if (sym->st_value == addr) {
+   if (name) {
+   *name = sym_name(sec->link->strtab,
+sym);
+   }
+   return sym;
+   }
+   }
+   }
+   return 0;
+}
+
+
 #if BYTE_ORDER == LITTLE_ENDIAN
 #define le16_to_cpu(val) (val)
 #define le32_to_cpu(val) (val)
@@ -512,6 +542,33 @@ static void read_relocs(FILE *fp)
}
 }
 
+static void read_got(FILE *fp)
+{
+   int i;
+   for (i = 0; i < ehdr.e_shnum; i++) {
+   struct section *sec = [i];
+   sec->got = NULL;
+   if (sec->shdr.sh_type != SHT_PROGBITS ||
+   strcmp(sec_name(i), ".got")) {
+   continue;
+   }
+   sec->got = malloc(sec->shdr.sh_size);
+   if (!sec->got) {
+   die("malloc of %d bytes for got failed\n",
+   sec->shdr.sh_size);
+   }
+   if (fseek(fp, sec->shdr.sh_offset, SEEK_SET) < 0) {
+   die("Seek to %d failed: %s\n",
+   sec->shdr.sh_offset, strerror(errno));
+   }
+   if (fread(sec->got, 1, sec->shdr.sh_size, fp)
+   != sec->shdr.sh_size) {
+   die("Cannot read got: %s\n",
+   strerror(errno));
+   }
+   }
+}
+
 
 static void print_absolute_symbols(void)
 {
@@ -642,6 +699,32 @@ static void add_reloc(struct relocs *r, uint32_t offset)
r->offset[r->count++] = offset;
 }
 
+/*
+ * The linker does not generate relocations for the GOT for the kernel.
+ * If a GOT is found, simulate the relocations that should have been included.
+ */
+static void walk_got_table(int (*process)(struct section *sec, Elf_Rel *rel,
+ Elf_Sym *sym, const char *symname),
+  struct section *sec)
+{
+   int i;
+   Elf_Addr entry;
+   Elf_Sym *sym;
+   const char *symname;
+   Elf_Rel rel;
+
+   for (i = 0; i < sec->shdr.sh_size/sizeof(Elf_Addr); i++) {
+   entry = sec->got[i];
+   sym = sym_lookup_addr(entry, );
+   if (!sym)
+   die("Could not found got symbol for entry %d\n", i);
+   rel.r_offset = sec->shdr.sh_addr + i * sizeof(Elf_Addr);
+   rel.r_info = ELF_BITS == 64 ? R_X86_64_GLOB_DAT
+: R_386_GLOB_DAT;
+   process(sec, , sym, symname);
+   }
+}
+
 static void walk_relocs(int (*process)(struct section *sec, Elf_Rel *rel,
Elf_Sym *sym, const char *symname))
 {
@@ -655,6 +738,8 @@ static void walk_relocs(int (*process)(struct section *sec, 
Elf_Rel *rel,
struct section *sec = [i];
 
if (sec->shdr.sh_type != SHT_REL_TYPE) {
+   if (sec->got)
+   walk_got_table(process, sec);
continue;
}
sec_symtab  = sec->link;
@@ -764,6 +849,8 @@ static int do_reloc64(struct section *sec, Elf_Rel *rel, 
ElfW(Sym) *sym,
offset += per_cpu_load_addr;
 
switch (r_type) {
+   case R_X86_64_PLT32:
+   case R_X86_64_GOTPCREL:
case R_X86_64_NONE:
/* NONE can be ignored. */
break;
@@ -805,7 

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

2017-10-11 Thread Thomas Garnier
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 
---
 arch/x86/boot/boot.h |  2 +-
 arch/x86/include/asm/setup.h |  2 +-
 arch/x86/kernel/cpu/microcode/core.c |  4 ++--
 drivers/base/firmware_class.c|  4 ++--
 include/asm-generic/sections.h   |  6 ++
 include/linux/compiler.h |  8 
 init/Kconfig |  7 +++
 kernel/kallsyms.c| 16 
 kernel/trace/trace.h |  4 ++--
 lib/dynamic_debug.c  |  4 ++--
 10 files changed, 39 insertions(+), 18 deletions(-)

diff --git a/arch/x86/boot/boot.h b/arch/x86/boot/boot.h
index ef5a9cc66fb8..d726c35bdd96 100644
--- a/arch/x86/boot/boot.h
+++ b/arch/x86/boot/boot.h
@@ -193,7 +193,7 @@ static inline bool memcmp_gs(const void *s1, addr_t s2, 
size_t len)
 }
 
 /* Heap -- available for dynamic lists. */
-extern char _end[];
+extern char _end[] __default_visibility;
 extern char *HEAP;
 extern char *heap_end;
 #define RESET_HEAP() ((void *)( HEAP = _end ))
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index a65cf544686a..7e0b54f605c6 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -67,7 +67,7 @@ static inline void x86_ce4100_early_setup(void) { }
  * This is set up by the setup-routine at boot-time
  */
 extern struct boot_params boot_params;
-extern char _text[];
+extern char _text[] __default_visibility;
 
 static inline bool kaslr_enabled(void)
 {
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)
 {
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 4b57cf5bc81d..77d4727f6594 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -45,8 +45,8 @@ MODULE_LICENSE("GPL");
 
 #ifdef CONFIG_FW_LOADER
 
-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;
 
 static bool fw_get_builtin_firmware(struct firmware *fw, const char *name,
void *buf, size_t size)
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")))
+#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 

[Xen-devel] [PATCH v1 01/27] x86/crypto: Adapt assembly for PIE support

2017-10-11 Thread Thomas Garnier
Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/crypto/aes-x86_64-asm_64.S  | 45 -
 arch/x86/crypto/aesni-intel_asm.S| 14 ++--
 arch/x86/crypto/aesni-intel_avx-x86_64.S |  6 +-
 arch/x86/crypto/camellia-aesni-avx-asm_64.S  | 42 ++--
 arch/x86/crypto/camellia-aesni-avx2-asm_64.S | 44 ++---
 arch/x86/crypto/camellia-x86_64-asm_64.S |  8 ++-
 arch/x86/crypto/cast5-avx-x86_64-asm_64.S| 50 ---
 arch/x86/crypto/cast6-avx-x86_64-asm_64.S| 44 +++--
 arch/x86/crypto/des3_ede-asm_64.S| 96 ++--
 arch/x86/crypto/ghash-clmulni-intel_asm.S|  4 +-
 arch/x86/crypto/glue_helper-asm-avx.S|  4 +-
 arch/x86/crypto/glue_helper-asm-avx2.S   |  6 +-
 12 files changed, 211 insertions(+), 152 deletions(-)

diff --git a/arch/x86/crypto/aes-x86_64-asm_64.S 
b/arch/x86/crypto/aes-x86_64-asm_64.S
index 8739cf7795de..86fa068e5e81 100644
--- a/arch/x86/crypto/aes-x86_64-asm_64.S
+++ b/arch/x86/crypto/aes-x86_64-asm_64.S
@@ -48,8 +48,12 @@
 #define R10%r10
 #define R11%r11
 
+/* Hold global for PIE suport */
+#define RBASE  %r12
+
 #define prologue(FUNC,KEY,B128,B192,r1,r2,r5,r6,r7,r8,r9,r10,r11) \
ENTRY(FUNC);\
+   pushq   RBASE;  \
movqr1,r2;  \
leaqKEY+48(r8),r9;  \
movqr10,r11;\
@@ -74,54 +78,63 @@
movlr6 ## E,4(r9);  \
movlr7 ## E,8(r9);  \
movlr8 ## E,12(r9); \
+   popqRBASE;  \
ret;\
ENDPROC(FUNC);
 
+#define round_mov(tab_off, reg_i, reg_o) \
+   leaqtab_off(%rip), RBASE; \
+   movl(RBASE,reg_i,4), reg_o;
+
+#define round_xor(tab_off, reg_i, reg_o) \
+   leaqtab_off(%rip), RBASE; \
+   xorl(RBASE,reg_i,4), reg_o;
+
 #define round(TAB,OFFSET,r1,r2,r3,r4,r5,r6,r7,r8,ra,rb,rc,rd) \
movzbl  r2 ## H,r5 ## E;\
movzbl  r2 ## L,r6 ## E;\
-   movlTAB+1024(,r5,4),r5 ## E;\
+   round_mov(TAB+1024, r5, r5 ## E)\
movwr4 ## X,r2 ## X;\
-   movlTAB(,r6,4),r6 ## E; \
+   round_mov(TAB, r6, r6 ## E) \
roll$16,r2 ## E;\
shrl$16,r4 ## E;\
movzbl  r4 ## L,r7 ## E;\
movzbl  r4 ## H,r4 ## E;\
xorlOFFSET(r8),ra ## E; \
xorlOFFSET+4(r8),rb ## E;   \
-   xorlTAB+3072(,r4,4),r5 ## E;\
-   xorlTAB+2048(,r7,4),r6 ## E;\
+   round_xor(TAB+3072, r4, r5 ## E)\
+   round_xor(TAB+2048, r7, r6 ## E)\
movzbl  r1 ## L,r7 ## E;\
movzbl  r1 ## H,r4 ## E;\
-   movlTAB+1024(,r4,4),r4 ## E;\
+   round_mov(TAB+1024, r4, r4 ## E)\
movwr3 ## X,r1 ## X;\
roll$16,r1 ## E;\
shrl$16,r3 ## E;\
-   xorlTAB(,r7,4),r5 ## E; \
+   round_xor(TAB, r7, r5 ## E) \
movzbl  r3 ## L,r7 ## E;\
movzbl  r3 ## H,r3 ## E;\
-   xorlTAB+3072(,r3,4),r4 ## E;\
-   xorlTAB+2048(,r7,4),r5 ## E;\
+   round_xor(TAB+3072, r3, r4 ## E)\
+   round_xor(TAB+2048, r7, r5 ## E)\
movzbl  r1 ## L,r7 ## E;\
movzbl  r1 ## H,r3 ## E;\
shrl$16,r1 ## E;\
-   xorlTAB+3072(,r3,4),r6 ## E;\
-   movlTAB+2048(,r7,4),r3 ## E;\
+   round_xor(TAB+3072, r3, r6 ## E)\
+   round_mov(TAB+2048, r7, r3 ## E)\
movzbl  r1 ## L,r7 ## E;\
movzbl  r1 ## H,r1 ## E;\
-   xorlTAB+1024(,r1,4),r6 ## E;\
-   xorlTAB(,r7,4),r3 ## E; \
+   round_xor(TAB+1024, r1, r6 ## E)\
+   round_xor(TAB, r7, r3 ## E) \
movzbl  r2 ## H,r1 ## E;\
movzbl  r2 ## L,r7 ## E;\
shrl$16,r2 ## E;\
-   xorlTAB+3072(,r1,4),r3 ## E;\
-   xorlTAB+2048(,r7,4),r4 ## E;\
+   round_xor(TAB+3072, r1, r3 ## E)\
+   round_xor(TAB+2048, r7, r4 ## E)\
movzbl  r2 ## H,r1 ## E;\
movzbl  r2 ## L,r2 ## E;\
xorlOFFSET+8(r8),rc ## E;   \
xorlOFFSET+12(r8),rd ## E;  \
-   xorlTAB+1024(,r1,4),r3 ## E;\
-   xorlTAB(,r2,4),r4 ## E;
+   round_xor(TAB+1024, r1, r3 ## E)\
+   round_xor(TAB, r2, r4 ## E)
 
 #define move_regs(r1,r2,r3,r4) \
movlr3 ## E,r1 ## E;\
diff --git a/arch/x86/crypto/aesni-intel_asm.S 
b/arch/x86/crypto/aesni-intel_asm.S
index 16627fec80b2..5f73201dff32 100644
--- 

[Xen-devel] [PATCH v1 09/27] x86/acpi: Adapt assembly for PIE support

2017-10-11 Thread Thomas Garnier
Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/kernel/acpi/wakeup_64.S | 31 ---
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/arch/x86/kernel/acpi/wakeup_64.S b/arch/x86/kernel/acpi/wakeup_64.S
index 50b8ed0317a3..472659c0f811 100644
--- a/arch/x86/kernel/acpi/wakeup_64.S
+++ b/arch/x86/kernel/acpi/wakeup_64.S
@@ -14,7 +14,7 @@
 * Hooray, we are in Long 64-bit mode (but still running in low memory)
 */
 ENTRY(wakeup_long64)
-   movqsaved_magic, %rax
+   movqsaved_magic(%rip), %rax
movq$0x123456789abcdef0, %rdx
cmpq%rdx, %rax
jne bogus_64_magic
@@ -25,14 +25,14 @@ ENTRY(wakeup_long64)
movw%ax, %es
movw%ax, %fs
movw%ax, %gs
-   movqsaved_rsp, %rsp
+   movqsaved_rsp(%rip), %rsp
 
-   movqsaved_rbx, %rbx
-   movqsaved_rdi, %rdi
-   movqsaved_rsi, %rsi
-   movqsaved_rbp, %rbp
+   movqsaved_rbx(%rip), %rbx
+   movqsaved_rdi(%rip), %rdi
+   movqsaved_rsi(%rip), %rsi
+   movqsaved_rbp(%rip), %rbp
 
-   movqsaved_rip, %rax
+   movqsaved_rip(%rip), %rax
jmp *%rax
 ENDPROC(wakeup_long64)
 
@@ -45,7 +45,7 @@ ENTRY(do_suspend_lowlevel)
xorl%eax, %eax
callsave_processor_state
 
-   movq$saved_context, %rax
+   leaqsaved_context(%rip), %rax
movq%rsp, pt_regs_sp(%rax)
movq%rbp, pt_regs_bp(%rax)
movq%rsi, pt_regs_si(%rax)
@@ -64,13 +64,14 @@ ENTRY(do_suspend_lowlevel)
pushfq
popqpt_regs_flags(%rax)
 
-   movq$.Lresume_point, saved_rip(%rip)
+   leaq.Lresume_point(%rip), %rax
+   movq%rax, saved_rip(%rip)
 
-   movq%rsp, saved_rsp
-   movq%rbp, saved_rbp
-   movq%rbx, saved_rbx
-   movq%rdi, saved_rdi
-   movq%rsi, saved_rsi
+   movq%rsp, saved_rsp(%rip)
+   movq%rbp, saved_rbp(%rip)
+   movq%rbx, saved_rbx(%rip)
+   movq%rdi, saved_rdi(%rip)
+   movq%rsi, saved_rsi(%rip)
 
addq$8, %rsp
movl$3, %edi
@@ -82,7 +83,7 @@ ENTRY(do_suspend_lowlevel)
.align 4
 .Lresume_point:
/* We don't restore %rax, it must be 0 anyway */
-   movq$saved_context, %rax
+   leaqsaved_context(%rip), %rax
movqsaved_context_cr4(%rax), %rbx
movq%rbx, %cr4
movqsaved_context_cr3(%rax), %rbx
-- 
2.15.0.rc0.271.g36b669edcc-goog


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


[Xen-devel] [PATCH v1 08/27] x86/CPU: Adapt assembly for PIE support

2017-10-11 Thread Thomas Garnier
Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible. Use the new _ASM_GET_PTR macro instead of
the 'mov $symbol, %dst' construct to not have an absolute reference.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/processor.h | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index b446c5a082ad..b09bd50b06c7 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -49,7 +49,7 @@ static inline void *current_text_addr(void)
 {
void *pc;
 
-   asm volatile("mov $1f, %0; 1:":"=r" (pc));
+   asm volatile(_ASM_GET_PTR(1f, %0) "; 1:":"=r" (pc));
 
return pc;
 }
@@ -695,6 +695,7 @@ static inline void sync_core(void)
: ASM_CALL_CONSTRAINT : : "memory");
 #else
unsigned int tmp;
+   unsigned long tmp2;
 
asm volatile (
UNWIND_HINT_SAVE
@@ -705,11 +706,13 @@ static inline void sync_core(void)
"pushfq\n\t"
"mov %%cs, %0\n\t"
"pushq %q0\n\t"
-   "pushq $1f\n\t"
+   "leaq 1f(%%rip), %1\n\t"
+   "pushq %1\n\t"
"iretq\n\t"
UNWIND_HINT_RESTORE
"1:"
-   : "=" (tmp), ASM_CALL_CONSTRAINT : : "cc", "memory");
+   : "=" (tmp), "=" (tmp2), ASM_CALL_CONSTRAINT
+   : : "cc", "memory");
 #endif
 }
 
-- 
2.15.0.rc0.271.g36b669edcc-goog


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


[Xen-devel] [PATCH v1 12/27] x86/paravirt: Adapt assembly for PIE support

2017-10-11 Thread Thomas Garnier
if PIE is enabled, switch the paravirt assembly constraints to be
compatible. The %c/i constrains generate smaller code so is kept by
default.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/paravirt_types.h | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index 280d94c36dad..e6961f8a74aa 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -335,9 +335,17 @@ extern struct pv_lock_ops pv_lock_ops;
 #define PARAVIRT_PATCH(x)  \
(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
 
+#ifdef CONFIG_X86_PIE
+#define paravirt_opptr_call "a"
+#define paravirt_opptr_type "p"
+#else
+#define paravirt_opptr_call "c"
+#define paravirt_opptr_type "i"
+#endif
+
 #define paravirt_type(op)  \
[paravirt_typenum] "i" (PARAVIRT_PATCH(op)),\
-   [paravirt_opptr] "i" (&(op))
+   [paravirt_opptr] paravirt_opptr_type (&(op))
 #define paravirt_clobber(clobber)  \
[paravirt_clobber] "i" (clobber)
 
@@ -391,7 +399,7 @@ int paravirt_disable_iospace(void);
  * offset into the paravirt_patch_template structure, and can therefore be
  * freely converted back into a structure offset.
  */
-#define PARAVIRT_CALL  "call *%c[paravirt_opptr];"
+#define PARAVIRT_CALL  "call *%" paravirt_opptr_call "[paravirt_opptr];"
 
 /*
  * These macros are intended to wrap calls through one of the paravirt
-- 
2.15.0.rc0.271.g36b669edcc-goog


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


[Xen-devel] [PATCH v1 04/27] x86: Add macro to get symbol address for PIE support

2017-10-11 Thread Thomas Garnier
Add a new _ASM_GET_PTR macro to fetch a symbol address. It will be used
to replace "_ASM_MOV $, %dst" code construct that are not compatible
with PIE.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/asm.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/x86/include/asm/asm.h b/arch/x86/include/asm/asm.h
index b0dc91f4bedc..6de365b8e3fd 100644
--- a/arch/x86/include/asm/asm.h
+++ b/arch/x86/include/asm/asm.h
@@ -57,6 +57,19 @@
 # define CC_OUT(c) [_cc_ ## c] "=qm"
 #endif
 
+/* Macros to get a global variable address with PIE support on 64-bit */
+#ifdef CONFIG_X86_32
+#define __ASM_GET_PTR_PRE(_src) __ASM_FORM_COMMA(movl $##_src)
+#else
+#ifdef __ASSEMBLY__
+#define __ASM_GET_PTR_PRE(_src) __ASM_FORM_COMMA(leaq (_src)(%rip))
+#else
+#define __ASM_GET_PTR_PRE(_src) __ASM_FORM_COMMA(leaq (_src)(%%rip))
+#endif
+#endif
+#define _ASM_GET_PTR(_src, _dst) \
+   __ASM_GET_PTR_PRE(_src) __ASM_FORM(_dst)
+
 /* Exception table entry */
 #ifdef __ASSEMBLY__
 # define _ASM_EXTABLE_HANDLE(from, to, handler)\
-- 
2.15.0.rc0.271.g36b669edcc-goog


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


[Xen-devel] [PATCH v1 03/27] x86: Use symbol name in jump table for PIE support

2017-10-11 Thread Thomas Garnier
Replace the %c constraint with %P. The %c is incompatible with PIE
because it implies an immediate value whereas %P reference a symbol.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/jump_label.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/jump_label.h 
b/arch/x86/include/asm/jump_label.h
index adc54c12cbd1..6e558e4524dc 100644
--- a/arch/x86/include/asm/jump_label.h
+++ b/arch/x86/include/asm/jump_label.h
@@ -36,9 +36,9 @@ static __always_inline bool arch_static_branch(struct 
static_key *key, bool bran
".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t"
".pushsection __jump_table,  \"aw\" \n\t"
_ASM_ALIGN "\n\t"
-   _ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t"
+   _ASM_PTR "1b, %l[l_yes], %P0 \n\t"
".popsection \n\t"
-   : :  "i" (key), "i" (branch) : : l_yes);
+   : :  "X" (&((char *)key)[branch]) : : l_yes);
 
return false;
 l_yes:
@@ -52,9 +52,9 @@ static __always_inline bool arch_static_branch_jump(struct 
static_key *key, bool
"2:\n\t"
".pushsection __jump_table,  \"aw\" \n\t"
_ASM_ALIGN "\n\t"
-   _ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t"
+   _ASM_PTR "1b, %l[l_yes], %P0 \n\t"
".popsection \n\t"
-   : :  "i" (key), "i" (branch) : : l_yes);
+   : :  "X" (&((char *)key)[branch]) : : l_yes);
 
return false;
 l_yes:
-- 
2.15.0.rc0.271.g36b669edcc-goog


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


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

2017-10-11 Thread Thomas Garnier
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.

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 config).

slab_test (average of 10 runs):
 - PIE disabled: no significant change (-2% on latest run, likely noise).
 - PIE enabled: between -1% and +0.8% on latest runs.

Kernbench (average of 10 Half and Optimal runs):
 Elapsed Time:
 - PIE disabled: no significant change (avg -0.239%)
 - PIE enabled: average +0.07%
 System Time:
 - PIE disabled: no significant change (avg -0.277%)
 - PIE enabled: average +0.7%

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303

diffstat:
 Documentation/x86/x86_64/mm.txt  |3 
 arch/x86/Kconfig |   43 ++
 arch/x86/Makefile|   40 +
 arch/x86/boot/boot.h |2 
 arch/x86/boot/compressed/Makefile|5 
 arch/x86/boot/compressed/misc.c  |   10 +
 arch/x86/crypto/aes-x86_64-asm_64.S  |   45 --
 arch/x86/crypto/aesni-intel_asm.S|   14 +-
 arch/x86/crypto/aesni-intel_avx-x86_64.S |6 
 arch/x86/crypto/camellia-aesni-avx-asm_64.S  |   42 +++---
 arch/x86/crypto/camellia-aesni-avx2-asm_64.S |   44 +++---
 arch/x86/crypto/camellia-x86_64-asm_64.S |8 -
 arch/x86/crypto/cast5-avx-x86_64-asm_64.S|   50 ---
 arch/x86/crypto/cast6-avx-x86_64-asm_64.S|   44 +++---
 arch/x86/crypto/des3_ede-asm_64.S|   96 +-
 arch/x86/crypto/ghash-clmulni-intel_asm.S|4 
 arch/x86/crypto/glue_helper-asm-avx.S|4 
 arch/x86/crypto/glue_helper-asm-avx2.S   |6 
 arch/x86/entry/entry_32.S 

[Xen-devel] [xen-unstable-smoke test] 114365: regressions - trouble: blocked/broken/fail/pass

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

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. 114299
 test-amd64-amd64-libvirt 12 guest-start  fail REGR. vs. 114299

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a

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

Last test of basis   114299  2017-10-10 21:02:54 Z0 days
Failing since114308  2017-10-10 23:01:10 Z0 days8 attempts
Testing same since   114365  2017-10-11 19:01:12 Z0 days1 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Andre Przywara 
  Andrew Cooper 
  Boris Ostrovsky 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Julien Grall 
  Meng Xu 
  Ross Lagerwall 
  Stefano Stabellini 
  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 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

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

Not pushing.

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

___
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-11 Thread Stefano Stabellini
On Wed, 11 Oct 2017, Anthony PERARD wrote:
> On Tue, Oct 10, 2017 at 04:52:48PM -0700, Stefano Stabellini wrote:
> > On Mon, 2 Oct 2017, Anthony PERARD wrote:
> > > On Tue, Sep 26, 2017 at 02:43:39PM +, Owen Smith wrote:
> > > > Writes "feature-raw-pointer" during init to indicate the backend
> > > > can pass raw unscaled values for absolute axes to the frontend.
> > > > Frontends set "request-raw-pointer" to indicate the backend should
> > > > not attempt to scale absolute values to console size.
> > > > "request-raw-pointer" is only valid if "request-abs-pointer" is
> > > > also set. Raw unscaled pointer values are in the range [0, 0x7fff]
> > > > 
> > > > Signed-off-by: Owen Smith 
> > > 
> > > Hi Owen,
> > > 
> > > Why did you remove the following from the commit description?
> > > > "feature-raw-pointer" and "request-raw-pointer" added to Xen
> > > > header in commit 7868654ff7fe5e4a2eeae2b277644fa884a5031e
> > > 
> > > I think that with it, you could have kept stefano's reviewed-by tag.
> > 
> > Hi Anthony,
> > 
> > Have you tested this series with a few of different guests? Do you
> > consider it safe to merge? If so, we can send it upstream (either via
> > xen or via ui as Gerd kindly offered). 
> 
> Yes, I think it's fine.
> 
> The only observation I have is that on a Linux guest, when I have
> usbdevice=tablet, with this series the pv mouse seems to become the
> primary way of gueting mouse events (without, the tablet is primary).
> So, on my VNC client instead of having both mouse in the guest and on my
> desktop being at the same place, there is like a zoom of the mouse (the
> zoom centered on the top-left corner). (That's better than relative
> mouse event that we can get with the emulation.)

Thanks for testing. I am not completely sure about what should be the
right behavior when both usbdevice=tablet and pvmouse are present.
Typically, PV devices take precedence over emulated devices, so maybe
it is OK that PV mouse is the primary device in this case.

But we would need to document this behavioral change in the commit
descriptions.

The other question is whether the "zoom of the mouse" you are seeing is
normal or whether we can "fix" it somehow. I guess it has always been
the case for PV mouse? It is not something new, is it?

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


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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-cubietruck broken
 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-armhf-armhf-xl-cubietruck  4 host-install(4)broken pass in 114225
 test-amd64-i386-xl-raw 19 guest-start/debian.repeat fail in 114133 pass in 
114304
 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-cubietruck 13 migrate-support-check fail in 114225 never 
pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail in 114225 
never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114034
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114034
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114034
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114034
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  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-libvirt 13 migrate-support-checkfail   never pass
 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  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-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-amd64-i386-xl-qemuu-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-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 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-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linuxac0058305d83e8e50a9652a003bc2ec468df9f87
baseline version:
 linuxffc97d4dde1d3c77beebddbbd2a0be5f8f18236a

Last test of basis   114034  2017-10-05 07:56:53 Z6 days
Testing same since   114133  2017-10-08 09:26:23 Z3 days4 attempts


People who touched revisions under test:
  Afzal Mohammed 
  Alden Tondettar 
  Alexander Potapenko 
  Andrey Ryabinin 
  Archit Taneja 
  Ard Biesheuvel 
  Arnd Bergmann 
  Arvind Yadav 

Re: [Xen-devel] [PATCH 27/27 v10] xen/arm: vpl011: Correct the logic for asserting/de-asserting SBSA UART TX interrupt

2017-10-11 Thread Dave Martin
On Wed, Oct 11, 2017 at 07:21:43PM +0530, Bhupinder Thakur wrote:
> On 11 October 2017 at 15:38, Dave Martin  wrote:
> > On Wed, Oct 11, 2017 at 01:28:44PM +0530, Bhupinder Thakur wrote:
> >> Hi Dave,
> >>
> >> On 26 September 2017 at 20:08, Dave Martin  wrote:
> >> > On Fri, Sep 22, 2017 at 01:53:26PM +0530, Bhupinder Thakur wrote:
> >> >> This patch fixes the issue observed when pl011 patches were tested on
> >> >> the junos hardware by Andre/Julien. It was observed that when large 
> >> >> output is
> >> >> generated such as on running 'find /', output was getting truncated 
> >> >> intermittently
> >> >> due to OUT ring buffer getting full.
> >> >>
> >> >> This issue was due to the fact that the SBSA UART driver expects that 
> >> >> when
> >> >> a TX interrupt is asserted then the FIFO queue should be atleast half 
> >> >> empty and
> >> >> that it can write N bytes in the FIFO, where N is half the FIFO queue 
> >> >> size, without
> >> >> the bytes getting dropped due to FIFO getting full.
> >> >>
> >> >> The SBSA UART emulation logic was asserting the TX interrupt as soon as
> >> >> any space became available in the FIFO and the SBSA UART driver tried 
> >> >> to write
> >> >> more data (upto 16 bytes) in the FIFO expecting that there is enough 
> >> >> space
> >> >> available leading to dropped bytes.
> >> >>
> >> >> The SBSA spec [1] does not specify when the TX interrupt should be 
> >> >> asserted
> >> >> or de-asserted. Due to lack of clarity on the expected behavior, it is
> >> >> assumed for now that TX interrupt should be asserted only when the FIFO 
> >> >> goes
> >> >> half empty.
> >> >>
> >> >> TBD: Once the SBSA spec is updated with the expected behavior, the 
> >> >> implementation
> >> >> will be modified to align with the spec requirement.
> >> >>
> >> >> [1] 
> >> >> http://infocenter.arm.com/help/topic/com.arm.doc.ddi0183f/DDI0183.pdf
> >> >>
> >> >> Signed-off-by: Bhupinder Thakur 
> >> >> ---
> >> >> CC: Julien Grall 
> >> >> CC: Andre Przywara 
> >> >> CC: Stefano Stabellini 
> >> >
> >> > (Taking a quick look at this because I remember fighthing with FIFO
> >> > behaviour issues when hacking the Linux driver -- but beware, I'm not a
> >> > Xen guy...)
> >> >
> >> >
> >> > Should this patch be flattened into the patches is fixes?  Keeping
> >> > known-wrong code in the series does not help reviewers (but maybe it's
> >> > the Xen way).
> >> >
> >> >> Changes since v8:
> >> >> - Used variables fifo_level/fifo_threshold for more clarity
> >> >> - Added a new macro SBSA_UART_FIFO_SIZE instead of using a magic number
> >> >
> >> > What's sizeof(intf->in), sizeof(intf->out)?
> >> >
> >> > For correct operation, you assume that the total ring buffer size is >=
> >> > SBSA_UART_FIFO_SIZE, but nothing enforces this.  If the xencons ring
> >> > buffer size is set elsewhere and can't be chosen by a driver, you may at
> >> > least add a build-time assert to check that it's big enough.
> >> >
> >> I will add an assert to check this condition.
> >>
> >> > [...]
> >> >
> >> >> @@ -144,28 +148,41 @@ static void vpl011_write_data(struct domain *d, 
> >> >> uint8_t data)
> >> >
> >> > [...]
> >> >
> >> >> + * Clear the TXI bit if the fifo level exceeds fifo_size/2 
> >> >> mark which
> >> >> + * is the trigger level for asserting/de-assterting the TX 
> >> >> interrupt.
> >> >>   */
> >> >> -vpl011->uartfr |= BUSY;
> >> >> +fifo_threshold = sizeof (intf->out) - SBSA_UART_FIFO_SIZE/2;
> >> >> +
> >> >> +if ( fifo_level <= fifo_threshold )
> >> >> +vpl011->uartris |= TXI;
> >> >> +else
> >> >> +vpl011->uartris &= ~TXI;
> >> >>  }
> >> >> +else
> >> >> +gprintk(XENLOG_ERR, "vpl011: Unexpected OUT ring buffer 
> >> >> full\n");
> >> >>
> >> >>  vpl011->uartfr &= ~TXFE;
> >> >>
> >> >
> >> > [...]
> >> >
> >> >> @@ -353,37 +370,51 @@ static void vpl011_data_avail(struct domain *d)
> >> >>
> >> >>  smp_rmb();
> >> >>
> >> >> -in_ring_qsize = xencons_queued(in_prod,
> >> >> +in_fifo_level = xencons_queued(in_prod,
> >> >> in_cons,
> >> >> sizeof(intf->in));
> >> >>
> >> >> -out_ring_qsize = xencons_queued(out_prod,
> >> >> +out_fifo_level = xencons_queued(out_prod,
> >> >>  out_cons,
> >> >>  sizeof(intf->out));
> >> >>
> >> >>  /* Update the uart rx state if the buffer is not empty. */
> >> >> -if ( in_ring_qsize != 0 )
> >> >> +if ( in_fifo_level != 0 )
> >> >>  {
> >> >>  vpl011->uartfr &= ~RXFE;
> >> >> -if ( in_ring_qsize == sizeof(intf->in) )
> >> >> +
> >> >> +if ( in_fifo_level == sizeof(intf->in) )
> >> >>  vpl011->uartfr |= RXFF;
> >> >> +
> 

[Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

2017-10-11 Thread Volodymyr Babchuk
Hello all,

I want to present TEE mediator, that was discussed earlier ([1]).

I selected design with built-in mediators. This is easiest way,
it removes many questions, it is easy to implement and maintain
(at least I hope so).

So, user can use Kconfig to build one or multiple mediators. During
boot, XEN will determine which TEE is running and initialize
corresponding mediator.

Framework puts a few hooks into other substems in order to be able
to work properly. It will be called during domain creation and
destruction and, obviously, to handle TEE SMCs.

Current implementation of OP-TEE mediator support only calls
from Dom0, but does this in full extent. All OP-TEE tests was
passed. I tested this on my Renesas Salvator X M3 board.

Also, I'm ready to be maintainer of this TEE mediators, if there
are no objections.

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

Volodymyr Babchuk (4):
  arm: add SMC wrapper that is compatible with SMCCC
  arm: add generic TEE mediator framework
  arm: tee: add OP-TEE header files
  arm: tee: add basic OP-TEE mediator

 MAINTAINERS |   5 +
 xen/arch/arm/Kconfig|  10 +
 xen/arch/arm/Makefile   |   1 +
 xen/arch/arm/arm32/Makefile |   1 +
 xen/arch/arm/arm32/smc.S|  32 +++
 xen/arch/arm/arm64/Makefile |   1 +
 xen/arch/arm/arm64/smc.S|  29 +++
 xen/arch/arm/domain.c   |   7 +
 xen/arch/arm/setup.c|   4 +
 xen/arch/arm/tee/Kconfig|   4 +
 xen/arch/arm/tee/Makefile   |   2 +
 xen/arch/arm/tee/optee.c| 178 
 xen/arch/arm/tee/optee_msg.h| 444 ++
 xen/arch/arm/tee/optee_smc.h| 457 
 xen/arch/arm/tee/tee.c  | 134 
 xen/arch/arm/vsmc.c |   5 +
 xen/arch/arm/xen.lds.S  |   7 +
 xen/include/asm-arm/processor.h |   4 +
 xen/include/asm-arm/tee.h   |  79 +++
 19 files changed, 1404 insertions(+)
 create mode 100644 xen/arch/arm/arm32/smc.S
 create mode 100644 xen/arch/arm/arm64/smc.S
 create mode 100644 xen/arch/arm/tee/Kconfig
 create mode 100644 xen/arch/arm/tee/Makefile
 create mode 100644 xen/arch/arm/tee/optee.c
 create mode 100644 xen/arch/arm/tee/optee_msg.h
 create mode 100644 xen/arch/arm/tee/optee_smc.h
 create mode 100644 xen/arch/arm/tee/tee.c
 create mode 100644 xen/include/asm-arm/tee.h

-- 
2.7.4


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


[Xen-devel] [RFC 3/4] arm: tee: add OP-TEE header files

2017-10-11 Thread Volodymyr Babchuk
This header files describe protocol between OP-TEE and OP-TEE client
driver in Linux. They are needed for upcomient OP-TEE mediator, which
is added in the next patch.
Reason to add those headers in separate patch is to ease up review.
Those files were taken from linux tree (drivers/tee/optee/) and mangled
a bit to compile with XEN.

Signed-off-by: Volodymyr Babchuk 
---
 xen/arch/arm/tee/optee_msg.h | 444 +
 xen/arch/arm/tee/optee_smc.h | 457 +++
 2 files changed, 901 insertions(+)
 create mode 100644 xen/arch/arm/tee/optee_msg.h
 create mode 100644 xen/arch/arm/tee/optee_smc.h

diff --git a/xen/arch/arm/tee/optee_msg.h b/xen/arch/arm/tee/optee_msg.h
new file mode 100644
index 000..10747b2
--- /dev/null
+++ b/xen/arch/arm/tee/optee_msg.h
@@ -0,0 +1,444 @@
+/*
+ * Copyright (c) 2015-2016, Linaro Limited
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright notice,
+ * this list of conditions and the following disclaimer.
+ *
+ * 2. Redistributions in binary form must reproduce the above copyright notice,
+ * this list of conditions and the following disclaimer in the documentation
+ * and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+#ifndef _OPTEE_MSG_H
+#define _OPTEE_MSG_H
+
+#include 
+#include 
+
+/*
+ * This file defines the OP-TEE message protocol used to communicate
+ * with an instance of OP-TEE running in secure world.
+ *
+ * This file is divided into three sections.
+ * 1. Formatting of messages.
+ * 2. Requests from normal world
+ * 3. Requests from secure world, Remote Procedure Call (RPC), handled by
+ *tee-supplicant.
+ */
+
+/*
+ * Part 1 - formatting of messages
+ */
+
+#define OPTEE_MSG_ATTR_TYPE_NONE   0x0
+#define OPTEE_MSG_ATTR_TYPE_VALUE_INPUT0x1
+#define OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT   0x2
+#define OPTEE_MSG_ATTR_TYPE_VALUE_INOUT0x3
+#define OPTEE_MSG_ATTR_TYPE_RMEM_INPUT 0x5
+#define OPTEE_MSG_ATTR_TYPE_RMEM_OUTPUT0x6
+#define OPTEE_MSG_ATTR_TYPE_RMEM_INOUT 0x7
+#define OPTEE_MSG_ATTR_TYPE_TMEM_INPUT 0x9
+#define OPTEE_MSG_ATTR_TYPE_TMEM_OUTPUT0xa
+#define OPTEE_MSG_ATTR_TYPE_TMEM_INOUT 0xb
+
+#define OPTEE_MSG_ATTR_TYPE_MASK   GENMASK(7, 0)
+
+/*
+ * Meta parameter to be absorbed by the Secure OS and not passed
+ * to the Trusted Application.
+ *
+ * Currently only used with OPTEE_MSG_CMD_OPEN_SESSION.
+ */
+#define OPTEE_MSG_ATTR_METABIT(8)
+
+/*
+ * Pointer to a list of pages used to register user-defined SHM buffer.
+ * Used with OPTEE_MSG_ATTR_TYPE_TMEM_*.
+ * buf_ptr should point to the beginning of the buffer. Buffer will contain
+ * list of page addresses. OP-TEE core can reconstruct contiguous buffer from
+ * that page addresses list. Page addresses are stored as 64 bit values.
+ * Last entry on a page should point to the next page of buffer.
+ * Every entry in buffer should point to a 4k page beginning (12 least
+ * significant bits must be equal to zero).
+ *
+ * 12 least significant bints of optee_msg_param.u.tmem.buf_ptr should hold 
page
+ * offset of the user buffer.
+ *
+ * So, entries should be placed like members of this structure:
+ *
+ * struct page_data {
+ *   uint64_t pages_array[OPTEE_MSG_NONCONTIG_PAGE_SIZE/sizeof(uint64_t) - 1];
+ *   uint64_t next_page_data;
+ * };
+ *
+ * Structure is designed to exactly fit into the page size
+ * OPTEE_MSG_NONCONTIG_PAGE_SIZE which is a standard 4KB page.
+ *
+ * The size of 4KB is chosen because this is the smallest page size for ARM
+ * architectures. If REE uses larger pages, it should divide them to 4KB ones.
+ */
+#define OPTEE_MSG_ATTR_NONCONTIG   BIT(9)
+
+/*
+ * Memory attributes for caching passed 

[Xen-devel] [RFC 2/4] arm: add generic TEE mediator framework

2017-10-11 Thread Volodymyr Babchuk
This patch adds basic framework for TEE mediators. Guests can't talk
to TEE directly, we need some entity that will intercept request
and decide what to do with them. "TEE mediaor" is a such entity.

This is how it works: user can build XEN with multiple TEE mediators
(see the next patches, where OP-TEE mediator is introduced).
TEE mediator register self with REGISTER_TEE_MEDIATOR() macro in the
same way, as device drivers use DT_DEVICE_START()/DT_DEVICE_END()
macros.
In runtime, during initialization, XEN issues standard SMC to read
TEE UID. Using this UID it selects and initializes one of built-in
mediators. Then generic vSMC handler will call selected mediator
when it intercept SMC that belongs to TEE OS or TEE application.

Also, there are hooks for domain construction and destruction, so
TEE mediator can inform TEE about VM lifecycle.

Signed-off-by: Volodymyr Babchuk 
---
 MAINTAINERS   |   5 ++
 xen/arch/arm/Kconfig  |  10 
 xen/arch/arm/Makefile |   1 +
 xen/arch/arm/domain.c |   7 +++
 xen/arch/arm/setup.c  |   4 ++
 xen/arch/arm/tee/Kconfig  |   0
 xen/arch/arm/tee/Makefile |   1 +
 xen/arch/arm/tee/tee.c| 134 ++
 xen/arch/arm/vsmc.c   |   5 ++
 xen/arch/arm/xen.lds.S|   7 +++
 xen/include/asm-arm/tee.h |  79 +++
 11 files changed, 253 insertions(+)
 create mode 100644 xen/arch/arm/tee/Kconfig
 create mode 100644 xen/arch/arm/tee/Makefile
 create mode 100644 xen/arch/arm/tee/tee.c
 create mode 100644 xen/include/asm-arm/tee.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 77b1e11..ede00c5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -357,6 +357,11 @@ F: config/Stubdom.mk.in
 F: m4/stubdom.m4
 F: stubdom/
 
+TEE MEDIATORS
+M: Volodymyr Babchuk 
+S: Supported
+F: xen/arch/arm/tee/*
+
 TOOLSTACK
 M: Ian Jackson 
 M: Wei Liu 
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index d46b98c..e1f112a 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -50,6 +50,14 @@ config HAS_ITS
 prompt "GICv3 ITS MSI controller support" if EXPERT = "y"
 depends on HAS_GICV3
 
+config ARM_TEE
+   bool "Enable TEE mediators support"
+   default n
+   depends on ARM
+   help
+ This option enables generic TEE mediators support. It allows guests
+ to access real TEE via one of TEE mediators implemented in XEN
+
 endmenu
 
 menu "ARM errata workaround via the alternative framework"
@@ -167,3 +175,5 @@ endmenu
 source "common/Kconfig"
 
 source "drivers/Kconfig"
+
+source "arch/arm/tee/Kconfig"
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index ede21fd..2710e0e 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -3,6 +3,7 @@ subdir-$(CONFIG_ARM_64) += arm64
 subdir-y += platforms
 subdir-$(CONFIG_ARM_64) += efi
 subdir-$(CONFIG_ACPI) += acpi
+subdir-$(CONFIG_ARM_TEE) += tee
 
 obj-$(CONFIG_HAS_ALTERNATIVE) += alternative.o
 obj-y += bootfdt.init.o
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 784ae39..3290d39 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -673,6 +674,9 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 if ( is_hardware_domain(d) && (rc = domain_vuart_init(d)) )
 goto fail;
 
+/* Notify TEE that new domain was created */
+tee_domain_create(d);
+
 return 0;
 
 fail:
@@ -684,6 +688,9 @@ fail:
 
 void arch_domain_destroy(struct domain *d)
 {
+/* Notify TEE that domain is being destroyed */
+tee_domain_destroy(d);
+
 /* IOMMU page table is shared with P2M, always call
  * iommu_domain_destroy() before p2m_teardown().
  */
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 92f173b..8a4fcd8 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -47,6 +47,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -846,6 +847,9 @@ void __init start_xen(unsigned long boot_phys_offset,
  */
 apply_alternatives_all();
 
+/* Initialize TEE mediator */
+tee_init();
+
 /* Create initial domain 0. */
 /* The vGIC for DOM0 is exactly emulating the hardware GIC */
 config.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig
new file mode 100644
index 000..e69de29
diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
new file mode 100644
index 000..c54d479
--- /dev/null
+++ b/xen/arch/arm/tee/Makefile
@@ -0,0 +1 @@
+obj-y += tee.o
diff --git a/xen/arch/arm/tee/tee.c b/xen/arch/arm/tee/tee.c
new file mode 100644
index 000..7f7a846
--- /dev/null
+++ b/xen/arch/arm/tee/tee.c
@@ -0,0 +1,134 @@
+/*
+ * xen/arch/arm/tee/tee.c
+ *
+ * Generic part of TEE 

[Xen-devel] [RFC 4/4] arm: tee: add basic OP-TEE mediator

2017-10-11 Thread Volodymyr Babchuk
Add basic OP-TEE mediator as an example how TEE mediator framework
works.

Currently it support only calls from Dom0. Calls from other guests
will be declined. It maps OP-TEE static shared memory region into
Dom0 address space, so Dom0 is the only domain which can work with
older versions of OP-TEE.

Also it alters SMC requests by\ adding domain id to request. OP-TEE
can use this information to track requesters.

Albeit being in early development stages, this mediator already can
be used on systems where only Dom0 interacts with OP-TEE.

It was tested on RCAR Salvator-M3 board.

Signed-off-by: Volodymyr Babchuk 
---
 xen/arch/arm/tee/Kconfig  |   4 ++
 xen/arch/arm/tee/Makefile |   1 +
 xen/arch/arm/tee/optee.c  | 178 ++
 3 files changed, 183 insertions(+)
 create mode 100644 xen/arch/arm/tee/optee.c

diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig
index e69de29..7c6b5c6 100644
--- a/xen/arch/arm/tee/Kconfig
+++ b/xen/arch/arm/tee/Kconfig
@@ -0,0 +1,4 @@
+config ARM_OPTEE
+   bool "Enable OP-TEE mediator"
+   default n
+   depends on ARM_TEE
diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
index c54d479..9d93b42 100644
--- a/xen/arch/arm/tee/Makefile
+++ b/xen/arch/arm/tee/Makefile
@@ -1 +1,2 @@
 obj-y += tee.o
+obj-$(CONFIG_ARM_OPTEE) += optee.o
diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c
new file mode 100644
index 000..0220691
--- /dev/null
+++ b/xen/arch/arm/tee/optee.c
@@ -0,0 +1,178 @@
+/*
+ * xen/arch/arm/tee/optee.c
+ *
+ * OP-TEE mediator
+ *
+ * Volodymyr Babchuk 
+ * Copyright (c) 2017 EPAM Systems.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+
+#include "optee_msg.h"
+#include "optee_smc.h"
+
+/*
+ * OP-TEE violates SMCCC when it defines own UID. So we need
+ * to place bytes in correct order.
+ */
+#define OPTEE_UID  (xen_uuid_t){{  
 \
+(uint8_t)(OPTEE_MSG_UID_0 >>  0), (uint8_t)(OPTEE_MSG_UID_0 >>  8),
 \
+(uint8_t)(OPTEE_MSG_UID_0 >> 16), (uint8_t)(OPTEE_MSG_UID_0 >> 24),
 \
+(uint8_t)(OPTEE_MSG_UID_1 >>  0), (uint8_t)(OPTEE_MSG_UID_1 >>  8),
 \
+(uint8_t)(OPTEE_MSG_UID_1 >> 16), (uint8_t)(OPTEE_MSG_UID_1 >> 24),
 \
+(uint8_t)(OPTEE_MSG_UID_2 >>  0), (uint8_t)(OPTEE_MSG_UID_2 >>  8),
 \
+(uint8_t)(OPTEE_MSG_UID_2 >> 16), (uint8_t)(OPTEE_MSG_UID_2 >> 24),
 \
+(uint8_t)(OPTEE_MSG_UID_3 >>  0), (uint8_t)(OPTEE_MSG_UID_3 >>  8),
 \
+(uint8_t)(OPTEE_MSG_UID_3 >> 16), (uint8_t)(OPTEE_MSG_UID_3 >> 24),
 \
+}}
+
+static int optee_init(void)
+{
+printk("OP-TEE mediator init done\n");
+return 0;
+}
+
+static void optee_domain_create(struct domain *d)
+{
+/*
+ * Do nothing at this time.
+ * In the future this function will notify that new VM is started.
+ */
+}
+
+static void optee_domain_destroy(struct domain *d)
+{
+/*
+ * Do nothing at this time.
+ * In the future this function will notify that VM is being destroyed.
+ */
+}
+
+static bool forward_call(struct cpu_user_regs *regs)
+{
+register_t resp[4];
+
+call_smccc_smc(get_user_reg(regs, 0),
+   get_user_reg(regs, 1),
+   get_user_reg(regs, 2),
+   get_user_reg(regs, 3),
+   get_user_reg(regs, 4),
+   get_user_reg(regs, 5),
+   get_user_reg(regs, 6),
+   /* VM id 0 is reserved for hypervisor itself */
+   current->domain->domain_id +1,
+   resp);
+
+set_user_reg(regs, 0, resp[0]);
+set_user_reg(regs, 1, resp[1]);
+set_user_reg(regs, 2, resp[2]);
+set_user_reg(regs, 3, resp[3]);
+
+return true;
+}
+
+static bool handle_get_shm_config(struct cpu_user_regs *regs)
+{
+paddr_t shm_start;
+size_t shm_size;
+int rc;
+
+printk("handle_get_shm_config\n");
+/* Give all static SHM region to the Dom0 */
+if ( current->domain->domain_id != 0 )
+return false;
+
+forward_call(regs);
+
+/* Return error back to the guest */
+if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK)
+return true;
+
+shm_start = get_user_reg(regs, 1);
+shm_size = get_user_reg(regs, 2);
+
+/* Dom0 is mapped 1:1 */
+rc = map_regions_p2mt(current->domain, gaddr_to_gfn(shm_start),
+  shm_size / PAGE_SIZE,
+  

[Xen-devel] [RFC 1/4] arm: add SMC wrapper that is compatible with SMCCC

2017-10-11 Thread Volodymyr Babchuk
Existing SMC wrapper call_smc() allows only 4 parameters and
returns only one value. This is enough for existing
use in PSCI code, but TEE mediator will need a call that is
fully compatible with ARM SMCCC.
This patch adds this call for both arm32 and arm64.

There was similar patch by Edgar E. Iglesias ([1]), but looks
like it is abandoned.

[1] https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00636.html

CC: "Edgar E. Iglesias" 

Signed-off-by: Volodymyr Babchuk 
---
 xen/arch/arm/arm32/Makefile |  1 +
 xen/arch/arm/arm32/smc.S| 32 
 xen/arch/arm/arm64/Makefile |  1 +
 xen/arch/arm/arm64/smc.S| 29 +
 xen/include/asm-arm/processor.h |  4 
 5 files changed, 67 insertions(+)
 create mode 100644 xen/arch/arm/arm32/smc.S
 create mode 100644 xen/arch/arm/arm64/smc.S

diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
index 0ac254f..c69f35e 100644
--- a/xen/arch/arm/arm32/Makefile
+++ b/xen/arch/arm/arm32/Makefile
@@ -10,4 +10,5 @@ obj-y += proc-v7.o proc-caxx.o
 obj-y += smpboot.o
 obj-y += traps.o
 obj-y += vfp.o
+obj-y += smc.o
 
diff --git a/xen/arch/arm/arm32/smc.S b/xen/arch/arm/arm32/smc.S
new file mode 100644
index 000..1cc9528
--- /dev/null
+++ b/xen/arch/arm/arm32/smc.S
@@ -0,0 +1,32 @@
+/*
+ * xen/arch/arm/arm32/smc.S
+ *
+ * Wrapper for Secure Monitors Calls
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+
+/*
+ * void call_smccc_smc(register_t a0, register_t a1, register_t a2,
+ * register_t a3, register_t a4, register_t a5,
+ * register_t a6, register_t a7, register_t res[4])
+ */
+ENTRY(call_smccc_smc)
+mov r12, sp
+push{r4-r7}
+ldm r12, {r4-r7}
+smc #0
+pop {r4-r7}
+ldr r12, [sp, #(4 * 4)]
+stm r12, {r0-r3}
+bx  lr
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index 718fe44..58a8ddd 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -8,6 +8,7 @@ obj-y += entry.o
 obj-y += insn.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o
 obj-y += smpboot.o
+obj-y += smc.o
 obj-y += traps.o
 obj-y += vfp.o
 obj-y += vsysreg.o
diff --git a/xen/arch/arm/arm64/smc.S b/xen/arch/arm/arm64/smc.S
new file mode 100644
index 000..aa44fba
--- /dev/null
+++ b/xen/arch/arm/arm64/smc.S
@@ -0,0 +1,29 @@
+/*
+ * xen/arch/arm/arm64/smc.S
+ *
+ * Wrapper for Secure Monitors Calls
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+
+/*
+ * void call_smccc_smc(register_t a0, register_t a1, register_t a2,
+ * register_t a3, register_t a4, register_t a5,
+ * register_t a6, register_t a7, register_t res[4])
+ */
+ENTRY(call_smccc_smc)
+smc #0
+ldr x4, [sp]
+stp x0, x1, [x4, 0]
+stp x2, x3, [x4, 16]
+ret
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index dc6ab62..71f3e60 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -787,6 +787,10 @@ void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
 int call_smc(register_t function_id, register_t arg0, register_t arg1,
  register_t arg2);
 
+void call_smccc_smc(register_t a0, register_t a1, register_t a2,
+register_t a3, register_t a4, register_t a5,
+register_t a6, register_t a7, register_t res[4]);
+
 void do_trap_hyp_serror(struct cpu_user_regs *regs);
 
 void do_trap_guest_serror(struct cpu_user_regs *regs);
-- 
2.7.4


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


Re: [Xen-devel] [PATCHv2 for-4.10] xen/arm: guest_walk: Fix check again the IPS

2017-10-11 Thread Stefano Stabellini
On Wed, 11 Oct 2017, Sergej Proskurin wrote:
> Hi Julien,
> 
> On 10/11/2017 04:57 PM, Julien Grall wrote:
> > 
> > 
> > On 11/10/17 15:51, Sergej Proskurin wrote:
> >> Hi Julien,
> > 
> > Hi,
> > 
> >> On 10/11/2017 04:29 PM, Julien Grall wrote:
> >>> The function get_ipa_output_size is check whether the input size
> >>> configured by the guest is valid and will return it.
> >>>
> >>> The check is done with the IPS already shifted against
> >>> TCR_EL1_IPS_48_BIT. However the constant has been defined with the
> >>> shift included, resulting the check always been false.
> >>>
> >>> Fix it by doing the check on the non-shifted value.
> >>>
> >>> This was introduced by commit 7d623b358a "arm/mem_access: Add
> >>> long-descriptor
> >>> based gpt" introduced software page-table walk for stage-1.
> >>>
> >>> Note that the IPS code is now surrounded with #ifdef CONFIG_ARM_64
> >>> because the Arm32 compiler will complain of shift bigger than the width
> >>> of the variable. This is fine as the code is executed for 64-bit
> >>> domain only.
> >>
> >> This is a bit controversial as compared to your review comments to the
> >> initial implementation. You did not want to see any #define
> >> CONFIG_ARM_64 within the code. TCR_EL1 is a 64-bit Register: to prevent
> >> compilation issues for Aarch32 systems, why don't you use uint64_t for
> >> ips instead of register_t?
> > 
> > I am fully aware what I said in the previous reviews and I still took
> > this decision because you will mix uint64_t and register_t. #ifdef
> > CONFIG_ARM_64 is much nicer than mixing types.
> > 
> > Another way to fix it would be to rework completely the way you did
> > introduce TCR_EL1_IPS_*_BIT so you stick with non-shifted value rather
> > than shifted one.
> > 
> > But I don't have time for that and I don't want to see a latent security
> > bug in the release.
> > 
> > Cheers,
> > 
> >> Thanks,
> >> ~Sergej
> >>
> >>>
> >>> Coverity-ID: 1457707
> >>> Signed-off-by: Julien Grall 
> >>>
> 
> Reviewed-by: Sergej Proskurin 

Thanks Sergej, Julien. The patch is committed.


> >>> ---
> >>>
> >>> Cc: Sergej Proskurin 
> >>>
> >>>  Changes in v2:
> >>>  - Fix compilation on Arm32
> >>> ---
> >>>   xen/arch/arm/guest_walk.c | 8 +---
> >>>   1 file changed, 5 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
> >>> index c38bedcf65..4d1ea0cdc1 100644
> >>> --- a/xen/arch/arm/guest_walk.c
> >>> +++ b/xen/arch/arm/guest_walk.c
> >>> @@ -185,7 +185,8 @@ static int guest_walk_sd(const struct vcpu *v,
> >>>   static int get_ipa_output_size(struct domain *d, register_t tcr,
> >>>  unsigned int *output_size)
> >>>   {
> >>> -    unsigned int ips;
> >>> +#ifdef CONFIG_ARM_64
> >>> +    register_t ips;
> >>>     static const unsigned int ipa_sizes[7] = {
> >>>   TCR_EL1_IPS_32_BIT_VAL,
> >>> @@ -200,7 +201,7 @@ static int get_ipa_output_size(struct domain *d,
> >>> register_t tcr,
> >>>   if ( is_64bit_domain(d) )
> >>>   {
> >>>   /* Get the intermediate physical address size. */
> >>> -    ips = (tcr & TCR_EL1_IPS_MASK) >> TCR_EL1_IPS_SHIFT;
> >>> +    ips = tcr & TCR_EL1_IPS_MASK;
> >>>     /*
> >>>    * Return an error on reserved IPA output-sizes and if the IPA
> >>> @@ -211,9 +212,10 @@ static int get_ipa_output_size(struct domain *d,
> >>> register_t tcr,
> >>>   if ( ips > TCR_EL1_IPS_48_BIT )
> >>>   return -EFAULT;
> >>>   -    *output_size = ipa_sizes[ips];
> >>> +    *output_size = ipa_sizes[ips >> TCR_EL1_IPS_SHIFT];
> >>>   }
> >>>   else
> >>> +#endif
> >>>   *output_size = TCR_EL1_IPS_40_BIT_VAL;
> >>>     return 0;
> >>
> > 
> ___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH for-4.10] xen/arm: mm: Rework MAIR* definitions to handle 32-bit compilation environment

2017-10-11 Thread Stefano Stabellini
On Wed, 11 Oct 2017, Julien Grall wrote:
> Commit a0543df403 "xen/arm: page: Clean-up the definition of MAIRVAL"
> combined the definition of MAIR0VAL and MAIR1VAL in MAIRVAL. Sadly, when
> building in 32-bit environment, the assembler is unable to compute
> 64-bit constant and will ignore the 32-bit most-significants bits. This
> will result of MAIR1 set 0.
> 
> Rather than fully reverting the offending commit, the code is reworked
> to still avoid hardcoded values but split the definition in 2.
> 
> Lastly, a comment is added to avoid trying to blindly combine the both
> definition again in the future.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/include/asm-arm/page.h | 23 ++-
>  1 file changed, 14 insertions(+), 9 deletions(-)
> 
> diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> index f558184e10..d948250a4a 100644
> --- a/xen/include/asm-arm/page.h
> +++ b/xen/include/asm-arm/page.h
> @@ -52,18 +52,23 @@
>   *   ??   101
>   *   reserved 110
>   *   MT_NORMAL111      -- Write-back write-allocate
> + *
> + * /!\ It is not possible to combine the definition in MAIRVAL and then
> + * split because it would result to a 64-bit value that some assembler
> + * doesn't understand.
>   */
> -#define MAIR(attr, mt) (_AC(attr, ULL) << ((mt) * 8))
> +#define _MAIR0(attr, mt) (_AC(attr, ULL) << ((mt) * 8))
> +#define _MAIR1(attr, mt) (_AC(attr, ULL) << (((mt) * 8) - 32))
> +
> +#define MAIR0VAL (_MAIR0(0x00, MT_DEVICE_nGnRnE)| \
> +  _MAIR0(0x44, MT_NORMAL_NC)| \
> +  _MAIR0(0xaa, MT_NORMAL_WT)| \
> +  _MAIR0(0xee, MT_NORMAL_WB))
>  
> -#define MAIRVAL (MAIR(0x00, MT_DEVICE_nGnRnE)| \
> - MAIR(0x44, MT_NORMAL_NC)| \
> - MAIR(0xaa, MT_NORMAL_WT)| \
> - MAIR(0xee, MT_NORMAL_WB)| \
> - MAIR(0x04, MT_DEVICE_nGnRE) | \
> - MAIR(0xff, MT_NORMAL))
> +#define MAIR1VAL (_MAIR1(0x04, MT_DEVICE_nGnRE) | \
> +  _MAIR1(0xff, MT_NORMAL))
>  
> -#define MAIR0VAL (MAIRVAL & 0x)
> -#define MAIR1VAL (MAIRVAL >> 32)
> +#define MAIRVAL (MAIR1VAL << 32 | MAIR0VAL)
>  
>  /*
>   * Layout of the flags used for updating the hypervisor page tables
> -- 
> 2.11.0
> 

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


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

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

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
 test-armhf-armhf-xl   7 xen-boot fail REGR. vs. 114299

version targeted for testing:
 xen  56a53ee1c11b778e79e2ad7ee7e309e9917fd13c
baseline version:
 xen  3b40cfcd1a1912c2e4c4eb353dc77cbf35c63c3a

Last test of basis   114299  2017-10-10 21:02:54 Z0 days
Failing since114308  2017-10-10 23:01:10 Z0 days7 attempts
Testing same since   114360  2017-10-11 16:01:29 Z0 days1 attempts


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

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  fail
 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 749 lines long.)

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


[Xen-devel] [PATCH v4 3/5] xl: enable per-VCPU extratime flag for RTDS

2017-10-11 Thread Meng Xu
Change main_sched_rtds and related output functions to support
per-VCPU extratime flag.

Signed-off-by: Meng Xu 
Reviewed-by: Dario Faggioli 
Acked-by: Wei Liu 

---
Changes from v2
Validate the -e option input that can only be 0 or 1
Update docs/man/xl.pod.1.in
Change EXTRATIME to Extratime

Changes from v1
No change because we agree on using -e 0/1 option to
set if a vcpu will get extra time or not

Changes from RFC v1
Changes work_conserving flag to extratime flag
---
 docs/man/xl.pod.1.in   | 59 +--
 tools/xl/xl_cmdtable.c |  3 ++-
 tools/xl/xl_sched.c| 62 +++---
 3 files changed, 78 insertions(+), 46 deletions(-)

diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in
index cd8bb1c..486a24f 100644
--- a/docs/man/xl.pod.1.in
+++ b/docs/man/xl.pod.1.in
@@ -1117,11 +1117,11 @@ as B<--ratelimit_us> in B
 Set or get rtds (Real Time Deferrable Server) scheduler parameters.
 This rt scheduler applies Preemptive Global Earliest Deadline First
 real-time scheduling algorithm to schedule VCPUs in the system.
-Each VCPU has a dedicated period and budget.
-VCPUs in the same domain have the same period and budget.
+Each VCPU has a dedicated period, budget and extratime.
 While scheduled, a VCPU burns its budget.
 A VCPU has its budget replenished at the beginning of each period;
 Unused budget is discarded at the end of each period.
+A VCPU with extratime set gets extra time from the unreserved system resource.
 
 B
 
@@ -1145,6 +1145,11 @@ Period of time, in microseconds, over which to replenish 
the budget.
 Amount of time, in microseconds, that the VCPU will be allowed
 to run every period.
 
+=item B<-e Extratime>, B<--extratime=Extratime>
+
+Binary flag to decide if the VCPU will be allowed to get extra time from
+the unreserved system resource.
+
 =item B<-c CPUPOOL>, B<--cpupool=CPUPOOL>
 
 Restrict output to domains in the specified cpupool.
@@ -1160,57 +1165,57 @@ all the domains:
 
 xl sched-rtds -v all
 Cpupool Pool-0: sched=RTDS
-NameID VCPUPeriodBudget
-Domain-0 00 1  4000
-vm1  10   300   150
-vm1  11   400   200
-vm1  12 1  4000
-vm1  13  1000   500
-vm2  20 1  4000
-vm2  21 1  4000
+NameID VCPUPeriodBudget  Extratime
+Domain-0 00 1  4000yes
+vm1  20   300   150yes
+vm1  21   400   200yes
+vm1  22 1  4000yes
+vm1  23  1000   500yes
+vm2  40 1  4000yes
+vm2  41 1  4000yes
 
 Without any arguments, it will output the default scheduling
 parameters for each domain:
 
 xl sched-rtds
 Cpupool Pool-0: sched=RTDS
-NameIDPeriodBudget
-Domain-0 0 1  4000
-vm1  1 1  4000
-vm2  2 1  4000
+NameIDPeriodBudget  Extratime
+Domain-0 0 1  4000yes
+vm1  2 1  4000yes
+vm2  4 1  4000yes
 
 
-2) Use, for instancei, B<-d vm1, -v all> to see the budget and
+2) Use, for instance, B<-d vm1, -v all> to see the budget and
 period of all VCPUs of a specific domain (B):
 
 xl sched-rtds -d vm1 -v all
-NameID VCPUPeriodBudget
-vm1  10   300   150
-vm1  11   400   200
-vm1  12 1  4000
-vm1  13  1000   500
+NameID VCPUPeriodBudget  Extratime
+vm1  20   300   150yes
+vm1  21   400   200yes
+vm1  22 1  4000yes
+vm1  23  1000   500yes
 
 To see the parameters of a subset of the VCPUs of a domain, use:
 
 xl sched-rtds -d vm1 -v 0 -v 3
-NameID VCPUPeriodBudget
-vm1  10   300   150
-vm1  13  1000   

Re: [Xen-devel] [PATCHv2 for-4.10] xen/arm: guest_walk: Fix check again the IPS

2017-10-11 Thread Sergej Proskurin
Hi Julien,

On 10/11/2017 04:57 PM, Julien Grall wrote:
> 
> 
> On 11/10/17 15:51, Sergej Proskurin wrote:
>> Hi Julien,
> 
> Hi,
> 
>> On 10/11/2017 04:29 PM, Julien Grall wrote:
>>> The function get_ipa_output_size is check whether the input size
>>> configured by the guest is valid and will return it.
>>>
>>> The check is done with the IPS already shifted against
>>> TCR_EL1_IPS_48_BIT. However the constant has been defined with the
>>> shift included, resulting the check always been false.
>>>
>>> Fix it by doing the check on the non-shifted value.
>>>
>>> This was introduced by commit 7d623b358a "arm/mem_access: Add
>>> long-descriptor
>>> based gpt" introduced software page-table walk for stage-1.
>>>
>>> Note that the IPS code is now surrounded with #ifdef CONFIG_ARM_64
>>> because the Arm32 compiler will complain of shift bigger than the width
>>> of the variable. This is fine as the code is executed for 64-bit
>>> domain only.
>>
>> This is a bit controversial as compared to your review comments to the
>> initial implementation. You did not want to see any #define
>> CONFIG_ARM_64 within the code. TCR_EL1 is a 64-bit Register: to prevent
>> compilation issues for Aarch32 systems, why don't you use uint64_t for
>> ips instead of register_t?
> 
> I am fully aware what I said in the previous reviews and I still took
> this decision because you will mix uint64_t and register_t. #ifdef
> CONFIG_ARM_64 is much nicer than mixing types.
> 
> Another way to fix it would be to rework completely the way you did
> introduce TCR_EL1_IPS_*_BIT so you stick with non-shifted value rather
> than shifted one.
> 
> But I don't have time for that and I don't want to see a latent security
> bug in the release.
> 
> Cheers,
> 
>> Thanks,
>> ~Sergej
>>
>>>
>>> Coverity-ID: 1457707
>>> Signed-off-by: Julien Grall 
>>>

Reviewed-by: Sergej Proskurin 

>>> ---
>>>
>>> Cc: Sergej Proskurin 
>>>
>>>  Changes in v2:
>>>  - Fix compilation on Arm32
>>> ---
>>>   xen/arch/arm/guest_walk.c | 8 +---
>>>   1 file changed, 5 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
>>> index c38bedcf65..4d1ea0cdc1 100644
>>> --- a/xen/arch/arm/guest_walk.c
>>> +++ b/xen/arch/arm/guest_walk.c
>>> @@ -185,7 +185,8 @@ static int guest_walk_sd(const struct vcpu *v,
>>>   static int get_ipa_output_size(struct domain *d, register_t tcr,
>>>  unsigned int *output_size)
>>>   {
>>> -    unsigned int ips;
>>> +#ifdef CONFIG_ARM_64
>>> +    register_t ips;
>>>     static const unsigned int ipa_sizes[7] = {
>>>   TCR_EL1_IPS_32_BIT_VAL,
>>> @@ -200,7 +201,7 @@ static int get_ipa_output_size(struct domain *d,
>>> register_t tcr,
>>>   if ( is_64bit_domain(d) )
>>>   {
>>>   /* Get the intermediate physical address size. */
>>> -    ips = (tcr & TCR_EL1_IPS_MASK) >> TCR_EL1_IPS_SHIFT;
>>> +    ips = tcr & TCR_EL1_IPS_MASK;
>>>     /*
>>>    * Return an error on reserved IPA output-sizes and if the IPA
>>> @@ -211,9 +212,10 @@ static int get_ipa_output_size(struct domain *d,
>>> register_t tcr,
>>>   if ( ips > TCR_EL1_IPS_48_BIT )
>>>   return -EFAULT;
>>>   -    *output_size = ipa_sizes[ips];
>>> +    *output_size = ipa_sizes[ips >> TCR_EL1_IPS_SHIFT];
>>>   }
>>>   else
>>> +#endif
>>>   *output_size = TCR_EL1_IPS_40_BIT_VAL;
>>>     return 0;
>>
> 

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


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

2017-10-11 Thread Meng Xu
This series of patches make RTDS scheduler work-conserving
without breaking real-time guarantees.
VCPUs with extratime flag set can get extra time
from the unreserved system resource.
System administrators can decide which VCPUs have extratime flag set.

Example:
Set the extratime bit of all VCPUs of domain 1:
# xl sched-rtds -d 1 -v all -p 1 -b 2000 -e 1
Each VCPU of domain 1 will be guaranteed to have 2000ms every 1ms
(if the system is schedulable).
If there is a CPU having no work to do,
domain 1's VCPUs will be scheduled onto the CPU,
even though the VCPUs have got 2000ms in 1ms.

Clear the extra bit of all VCPUs of domain 1:
# xl sched-rtds -d 1 -v all -p 1 -b 2000 -e 0

Set/Clear the extratime bit of one specific VCPU of domain 1:
# xl sched-rtds -d 1 -v 1 -p 1 -b 2000 -e 1
# xl sched-rtds -d 1 -v 1 -p 1 -b 2000 -e 0


The original design of the work-conserving RTDS was discussed at
https://www.mail-archive.com/xen-devel@lists.xen.org/msg77150.html

The first version was discussed at
https://www.mail-archive.com/xen-devel@lists.xen.org/msg117361.html

The second version was discussed at
https://www.mail-archive.com/xen-devel@lists.xen.org/msg120618.html

The third version has been mostly reviewed by Dario Faggioli and
acked by Wei Liu, except
[PATCH v4 4/5] xentrace: enable per-VCPU extratime flag for RTDS

The series of patch can be found at github:
https://github.com/PennPanda/RT-Xen
under the branch:
xenbits/rtds/work-conserving-v4

Changes from v3
Handle burn_budget event in xentrace and xenanalyze.
Tested the change with three VMs

Changes from v2
Sanity check the input of -e option which can only be 0 or 1
Set -e to 1 by default if 3rd party library does not set -e option
Set vcpu extratime in sched_rtds_vcpu_get function function, which
fixes a bug in previous version.
Change EXTRATIME to Extratime in the xl output

Changes from v1
Change XEN_DOMCTL_SCHED_RTDS_extratime to XEN_DOMCTL_SCHEDRT_extra
Revise xentrace, xenalyze, and docs
Add LIBXL_HAVE_SCHED_RTDS_VCPU_EXTRA symbol in libxl.h

Changes from RFC v1
Merge changes in sched_rt.c into one patch;
Minor change in variable name and comments.

Signed-off-by: Meng Xu 

[PATCH v4 1/5] xen:rtds: towards work conserving RTDS
[PATCH v4 2/5] libxl: enable per-VCPU extratime flag for RTDS
[PATCH v4 3/5] xl: enable per-VCPU extratime flag for RTDS
[PATCH v4 4/5] xentrace: enable per-VCPU extratime flag for RTDS
[PATCH v4 5/5] docs: enable per-VCPU extratime flag for RTDS


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


[Xen-devel] [PATCH v4 2/5] libxl: enable per-VCPU extratime flag for RTDS

2017-10-11 Thread Meng Xu
Modify libxl_vcpu_sched_params_get/set and sched_rtds_vcpu_get/set
functions to support per-VCPU extratime flag

Signed-off-by: Meng Xu 
Reviewed-by: Dario Faggioli 
Acked-by: Wei Liu 

---
Changes from v2
1) Move extratime out of the section
   that is marked as depreciated in libxl_domain_sched_params.
2) Set vcpu extratime in sched_rtds_vcpu_get function function;
   This fix a bug in previous version
   when run command "xl sched-rtds -d 0 -v 1" which
   outputs vcpu extratime value incorrectly.

Changes from v1
1) Add LIBXL_HAVE_SCHED_RTDS_VCPU_EXTRA to indicate if extratime flag is
supported
2) Change flag name in domctl.h from XEN_DOMCTL_SCHED_RTDS_extratime to
XEN_DOMCTL_SCHEDRT_extra

Changes from RFC v1
Change work_conserving flag to extratime flag
---
 tools/libxl/libxl.h |  6 ++
 tools/libxl/libxl_sched.c   | 17 +
 tools/libxl/libxl_types.idl |  8 
 3 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index f82b91e..5e9aed7 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -257,6 +257,12 @@
 #define LIBXL_HAVE_SCHED_RTDS_VCPU_PARAMS 1
 
 /*
+ * LIBXL_HAVE_SCHED_RTDS_VCPU_EXTRA indicates RTDS scheduler
+ * now supports per-vcpu extratime settings.
+ */
+#define LIBXL_HAVE_SCHED_RTDS_VCPU_EXTRA 1
+
+/*
  * libxl_domain_build_info has the arm.gic_version field.
  */
 #define LIBXL_HAVE_BUILDINFO_ARM_GIC_VERSION 1
diff --git a/tools/libxl/libxl_sched.c b/tools/libxl/libxl_sched.c
index 7d144d0..512788f 100644
--- a/tools/libxl/libxl_sched.c
+++ b/tools/libxl/libxl_sched.c
@@ -532,6 +532,8 @@ static int sched_rtds_vcpu_get(libxl__gc *gc, uint32_t 
domid,
 for (i = 0; i < num_vcpus; i++) {
 scinfo->vcpus[i].period = vcpus[i].u.rtds.period;
 scinfo->vcpus[i].budget = vcpus[i].u.rtds.budget;
+scinfo->vcpus[i].extratime =
+!!(vcpus[i].u.rtds.flags & XEN_DOMCTL_SCHEDRT_extra);
 scinfo->vcpus[i].vcpuid = vcpus[i].vcpuid;
 }
 rc = 0;
@@ -579,6 +581,8 @@ static int sched_rtds_vcpu_get_all(libxl__gc *gc, uint32_t 
domid,
 for (i = 0; i < num_vcpus; i++) {
 scinfo->vcpus[i].period = vcpus[i].u.rtds.period;
 scinfo->vcpus[i].budget = vcpus[i].u.rtds.budget;
+scinfo->vcpus[i].extratime =
+!!(vcpus[i].u.rtds.flags & XEN_DOMCTL_SCHEDRT_extra);
 scinfo->vcpus[i].vcpuid = vcpus[i].vcpuid;
 }
 rc = 0;
@@ -628,6 +632,10 @@ static int sched_rtds_vcpu_set(libxl__gc *gc, uint32_t 
domid,
 vcpus[i].vcpuid = scinfo->vcpus[i].vcpuid;
 vcpus[i].u.rtds.period = scinfo->vcpus[i].period;
 vcpus[i].u.rtds.budget = scinfo->vcpus[i].budget;
+if (scinfo->vcpus[i].extratime)
+vcpus[i].u.rtds.flags |= XEN_DOMCTL_SCHEDRT_extra;
+else
+vcpus[i].u.rtds.flags &= ~XEN_DOMCTL_SCHEDRT_extra;
 }
 
 r = xc_sched_rtds_vcpu_set(CTX->xch, domid,
@@ -676,6 +684,10 @@ static int sched_rtds_vcpu_set_all(libxl__gc *gc, uint32_t 
domid,
 vcpus[i].vcpuid = i;
 vcpus[i].u.rtds.period = scinfo->vcpus[0].period;
 vcpus[i].u.rtds.budget = scinfo->vcpus[0].budget;
+if (scinfo->vcpus[0].extratime)
+vcpus[i].u.rtds.flags |= XEN_DOMCTL_SCHEDRT_extra;
+else
+vcpus[i].u.rtds.flags &= ~XEN_DOMCTL_SCHEDRT_extra;
 }
 
 r = xc_sched_rtds_vcpu_set(CTX->xch, domid,
@@ -726,6 +738,11 @@ static int sched_rtds_domain_set(libxl__gc *gc, uint32_t 
domid,
 sdom.period = scinfo->period;
 if (scinfo->budget != LIBXL_DOMAIN_SCHED_PARAM_BUDGET_DEFAULT)
 sdom.budget = scinfo->budget;
+/* Set extratime by default */
+if (scinfo->extratime)
+sdom.flags |= XEN_DOMCTL_SCHEDRT_extra;
+else
+sdom.flags &= ~XEN_DOMCTL_SCHEDRT_extra;
 if (sched_rtds_validate_params(gc, sdom.period, sdom.budget))
 return ERROR_INVAL;
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 2d0bb8a..dd7d364 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -421,14 +421,14 @@ libxl_domain_sched_params = Struct("domain_sched_params",[
 ("cap",  integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_CAP_DEFAULT'}),
 ("period",   integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT'}),
 ("budget",   integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_BUDGET_DEFAULT'}),
+("extratime",integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT'}),
 
-# The following three parameters ('slice', 'latency' and 'extratime') are 
deprecated,
+# The following three parameters ('slice' and 'latency') are deprecated,
 # and will have no effect if used, since the SEDF scheduler has been 
removed.
-# Note that 'period' was an SDF parameter too, but it is still effective 
as it is
-# now used (together with 'budget') by the RTDS 

[Xen-devel] [PATCH v4 1/5] xen:rtds: towards work conserving RTDS

2017-10-11 Thread Meng Xu
Make RTDS scheduler work conserving without breaking the real-time guarantees.

VCPU model:
Each real-time VCPU is extended to have an extratime flag
and a priority_level field.
When a VCPU's budget is depleted in the current period,
if it has extratime flag set,
its priority_level will increase by 1 and its budget will be refilled;
othewrise, the VCPU will be moved to the depletedq.

Scheduling policy is modified global EDF:
A VCPU v1 has higher priority than another VCPU v2 if
(i) v1 has smaller priority_leve; or
(ii) v1 has the same priority_level but has a smaller deadline

Queue management:
Run queue holds VCPUs with extratime flag set and VCPUs with
remaining budget. Run queue is sorted in increasing order of VCPUs priorities.
Depleted queue holds VCPUs which have extratime flag cleared and depleted 
budget.
Replenished queue is not modified.

Distribution of spare bandwidth
Spare bandwidth is distributed among all VCPUs with extratime flag set,
proportional to these VCPUs utilizations

Signed-off-by: Meng Xu 
Reviewed-by: Dario Faggioli 

---
Changes from v2
Explain how to distribute spare bandwidth in commit log
Minor change in has_extratime function without functionality change.

Changes from v1
Change XEN_DOMCTL_SCHED_RTDS_extratime to XEN_DOMCTL_SCHEDRT_extra as
suggested by Dario

Changes from RFC v1
Rewording comments and commit message
Remove is_work_conserving field from rt_vcpu structure
Use one bit in VCPU's flag to indicate if a VCPU will have extra time
Correct comments style
---
 xen/common/sched_rt.c   | 90 ++---
 xen/include/public/domctl.h |  4 ++
 2 files changed, 80 insertions(+), 14 deletions(-)

diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 5c51cd9..b770287 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -49,13 +49,15 @@
  * A PCPU is feasible if the VCPU can run on this PCPU and (the PCPU is idle or
  * has a lower-priority VCPU running on it.)
  *
- * Each VCPU has a dedicated period and budget.
+ * Each VCPU has a dedicated period, budget and a extratime flag
  * The deadline of a VCPU is at the end of each period;
  * A VCPU has its budget replenished at the beginning of each period;
  * While scheduled, a VCPU burns its budget.
  * The VCPU needs to finish its budget before its deadline in each period;
  * The VCPU discards its unused budget at the end of each period.
- * If a VCPU runs out of budget in a period, it has to wait until next period.
+ * When a VCPU runs out of budget in a period, if its extratime flag is set,
+ * the VCPU increases its priority_level by 1 and refills its budget; 
otherwise,
+ * it has to wait until next period.
  *
  * Each VCPU is implemented as a deferable server.
  * When a VCPU has a task running on it, its budget is continuously burned;
@@ -63,7 +65,8 @@
  *
  * Queue scheme:
  * A global runqueue and a global depletedqueue for each CPU pool.
- * The runqueue holds all runnable VCPUs with budget, sorted by deadline;
+ * The runqueue holds all runnable VCPUs with budget,
+ * sorted by priority_level and deadline;
  * The depletedqueue holds all VCPUs without budget, unsorted;
  *
  * Note: cpumask and cpupool is supported.
@@ -151,6 +154,14 @@
 #define RTDS_depleted (1<<__RTDS_depleted)
 
 /*
+ * RTDS_extratime: Can the vcpu run in the time that is
+ * not part of any real-time reservation, and would therefore
+ * be otherwise left idle?
+ */
+#define __RTDS_extratime4
+#define RTDS_extratime (1<<__RTDS_extratime)
+
+/*
  * rt tracing events ("only" 512 available!). Check
  * include/public/trace.h for more details.
  */
@@ -201,6 +212,8 @@ struct rt_vcpu {
 struct rt_dom *sdom;
 struct vcpu *vcpu;
 
+unsigned priority_level;
+
 unsigned flags;  /* mark __RTDS_scheduled, etc.. */
 };
 
@@ -245,6 +258,11 @@ static inline struct list_head *rt_replq(const struct 
scheduler *ops)
 return _priv(ops)->replq;
 }
 
+static inline bool has_extratime(const struct rt_vcpu *svc)
+{
+return svc->flags & RTDS_extratime;
+}
+
 /*
  * Helper functions for manipulating the runqueue, the depleted queue,
  * and the replenishment events queue.
@@ -274,6 +292,21 @@ vcpu_on_replq(const struct rt_vcpu *svc)
 }
 
 /*
+ * If v1 priority >= v2 priority, return value > 0
+ * Otherwise, return value < 0
+ */
+static s_time_t
+compare_vcpu_priority(const struct rt_vcpu *v1, const struct rt_vcpu *v2)
+{
+int prio = v2->priority_level - v1->priority_level;
+
+if ( prio == 0 )
+return v2->cur_deadline - v1->cur_deadline;
+
+return prio;
+}
+
+/*
  * Debug related code, dump vcpu/cpu information
  */
 static void
@@ -303,6 +336,7 @@ rt_dump_vcpu(const struct scheduler *ops, const struct 
rt_vcpu *svc)
 cpulist_scnprintf(keyhandler_scratch, sizeof(keyhandler_scratch), mask);
 printk("[%5d.%-2u] cpu %u, (%"PRI_stime", %"PRI_stime"),"
" cur_b=%"PRI_stime" cur_d=%"PRI_stime" 

[Xen-devel] [PATCH v4 5/5] docs: enable per-VCPU extratime flag for RTDS

2017-10-11 Thread Meng Xu
Revise xl tool use case by adding -e option
Remove work-conserving from TODO list

Signed-off-by: Meng Xu 
Reviewed-by: Dario Faggioli 
Acked-by: Wei Liu 

---
No change from v2

Changes from v1
Revise rtds docs
---
 docs/features/sched_rtds.pandoc | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/docs/features/sched_rtds.pandoc b/docs/features/sched_rtds.pandoc
index 354097b..d51b499 100644
--- a/docs/features/sched_rtds.pandoc
+++ b/docs/features/sched_rtds.pandoc
@@ -40,7 +40,7 @@ as follows:
 
 It is possible, for a multiple vCPUs VM, to change the parameters of
 each vCPU individually:
-* `xl sched-rtds -d vm-rt -v 0 -p 2 -b 1 -v 1 -p 45000 -b 12000`
+* `xl sched-rtds -d vm-rt -v 0 -p 2 -b 1 -e 1 -v 1 -p 45000 -b 
12000 -e 0`
 
 # Technical details
 
@@ -53,7 +53,8 @@ the presence of the LIBXL\_HAVE\_SCHED\_RTDS symbol. The 
ability of
 specifying different scheduling parameters for each vcpu has been
 introduced later, and is available if the following symbols are defined:
 * `LIBXL\_HAVE\_VCPU\_SCHED\_PARAMS`,
-* `LIBXL\_HAVE\_SCHED\_RTDS\_VCPU\_PARAMS`.
+* `LIBXL\_HAVE\_SCHED\_RTDS\_VCPU\_PARAMS`,
+* `LIBXL\_HAVE\_SCHED\_RTDS\_VCPU\_EXTRA`.
 
 # Limitations
 
@@ -95,7 +96,6 @@ at a macroscopic level), the following should be done:
 
 # Areas for improvement
 
-* Work-conserving mode to be added;
 * performance assessment, especially focusing on what level of real-time
   behavior the scheduler enables.
 
@@ -118,4 +118,5 @@ at a macroscopic level), the following should be done:
 Date   Revision Version  Notes
 --   ---
 2016-10-14 1Xen 4.8  Document written
+2017-08-31 2Xen 4.10 Revise for work conserving feature
 --   ---
-- 
1.9.1


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


[Xen-devel] [PATCH v4 4/5] xentrace: enable per-VCPU extratime flag for RTDS

2017-10-11 Thread Meng Xu
Change repl_budget event output for xentrace formats and xenalyze

Signed-off-by: Meng Xu 

---
Changes from v3
Handle burn_budget event

No changes from v2

Changes from v1
Add this changes from v1
---
 tools/xentrace/formats|  4 ++--
 tools/xentrace/xenalyze.c | 16 +++-
 2 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/tools/xentrace/formats b/tools/xentrace/formats
index d6e7e3f..8b286c3 100644
--- a/tools/xentrace/formats
+++ b/tools/xentrace/formats
@@ -74,8 +74,8 @@
 
 0x00022801  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:tickle[ cpu = 
%(1)d ]
 0x00022802  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:runq_pick [ dom:vcpu 
= 0x%(1)08x, cur_deadline = 0x%(3)08x%(2)08x, cur_budget = 0x%(5)08x%(4)08x ]
-0x00022803  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:burn_budget   [ dom:vcpu 
= 0x%(1)08x, cur_budget = 0x%(3)08x%(2)08x, delta = %(4)d ]
-0x00022804  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:repl_budget   [ dom:vcpu 
= 0x%(1)08x, cur_deadline = 0x%(3)08x%(2)08x, cur_budget = 0x%(5)08x%(4)08x ]
+0x00022803  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:burn_budget   [ dom:vcpu 
= 0x%(1)08x, cur_budget = 0x%(3)08x%(2)08x, delta = %(4)d, priority_level = 
%(5)d, has_extratime = %(6)x ]
+0x00022804  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:repl_budget   [ dom:vcpu 
= 0x%(1)08x, priority_level = 0x%(2)08d cur_deadline = 0x%(4)08x%(3)08x, 
cur_budget = 0x%(6)08x%(5)08x ]
 0x00022805  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:sched_tasklet
 0x00022806  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:schedule  [ 
cpu[16]:tasklet[8]:idle[4]:tickled[4] = %(1)08x ]
 
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index 79bdba7..19e050f 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -7935,23 +7935,29 @@ void sched_process(struct pcpu_info *p)
 unsigned int vcpuid:16, domid:16;
 uint64_t cur_bg;
 int delta;
+unsigned priority_level;
+unsigned has_extratime;
 } __attribute__((packed)) *r = (typeof(r))ri->d;
 
 printf(" %s rtds:burn_budget d%uv%u, budget = %"PRIu64", "
-   "delta = %d\n", ri->dump_header, r->domid,
-   r->vcpuid, r->cur_bg, r->delta);
+   "delta = %d, priority_level = %d, has_extratime = %d\n",
+   ri->dump_header, r->domid,
+   r->vcpuid, r->cur_bg, r->delta,
+   r->priority_level, !!r->has_extratime);
 }
 break;
 case TRC_SCHED_CLASS_EVT(RTDS, 4): /* BUDGET_REPLENISH */
 if(opt.dump_all) {
 struct {
 unsigned int vcpuid:16, domid:16;
+unsigned int priority_level;
 uint64_t cur_dl, cur_bg;
 } __attribute__((packed)) *r = (typeof(r))ri->d;
 
-printf(" %s rtds:repl_budget d%uv%u, deadline = %"PRIu64", "
-   "budget = %"PRIu64"\n", ri->dump_header,
-   r->domid, r->vcpuid, r->cur_dl, r->cur_bg);
+printf(" %s rtds:repl_budget d%uv%u, priority_level = %u,"
+   "deadline = %"PRIu64", budget = %"PRIu64"\n",
+   ri->dump_header, r->domid, r->vcpuid,
+   r->priority_level, r->cur_dl, r->cur_bg);
 }
 break;
 case TRC_SCHED_CLASS_EVT(RTDS, 5): /* SCHED_TASKLET*/
-- 
1.9.1


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


[Xen-devel] [PATCH v4 12/12] fuzz/x86_emulate: Add an option to limit the number of instructions executed

2017-10-11 Thread George Dunlap
AFL considers a testcase to be a useful addition not only if there are
tuples exercised by that testcase which were not exercised otherwise,
but also if the *number* of times an individual tuple is exercised
changes significantly; in particular, if the number of the highest
non-zero bit changes (i.e., if it is run 1, 2-3, 4-7, 8-15, ).

One simple way to increase these stats it to execute the same (or
similar) instructions multiple times: If executing a given instruction
once hits a particular tuple 2 times, executing it twice will hit the
tuple 4 times, four times will hit the tuple 8 times, and so on.  All
of these will look different to AFL, and so it is likely that many of
the "unique test cases" will simply be the same instruction repeated
powers of 2 times until the tuple counts max out (at 128).

It is unlikely that executing a single instruction more than a handful
of times will generate any state we actually care about; but such long
testcases take exponentially longer to fuzz: the fuzzer spends more
time flipping bits looking for meaningful changes, and each execution
takes longer because it is doing more things.  So long paths which add
nothing to the actual code coverage but effectively "distract" the
fuzzer, making it less effective.

Experiments have shown that not allowing infinite number of
instruction retries for the old (non-compact) format does indeed speed
up and increase code coverage.  However, it has also shown that on the
new, more compact format, having no instruction limit causes the highest
throughput in code coverage.

So leave the option in, but have it default to 0 (no limit).

Signed-off-by: George Dunlap 
Acked-by: Jan Beulich 
---
v3:
- Change opt_instruction_limit to unsigned, default to UINT_MAX
- Simplify limit checking (now that the actual variable itself will never be 0)
- Change counter to unsigned
- Update changelog to try to be a bit more clear


CC: Ian Jackson 
CC: Wei Liu 
CC: Andrew Cooper 
CC: Jan Beulich 
---
 tools/fuzz/x86_instruction_emulator/afl-harness.c | 11 ++-
 tools/fuzz/x86_instruction_emulator/fuzz-emul.c   |  5 -
 tools/fuzz/x86_instruction_emulator/fuzz-emul.h   |  1 +
 3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/tools/fuzz/x86_instruction_emulator/afl-harness.c 
b/tools/fuzz/x86_instruction_emulator/afl-harness.c
index 0489034642..375bad 100644
--- a/tools/fuzz/x86_instruction_emulator/afl-harness.c
+++ b/tools/fuzz/x86_instruction_emulator/afl-harness.c
@@ -1,4 +1,5 @@
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -24,11 +25,13 @@ int main(int argc, char **argv)
 OPT_MIN_SIZE,
 OPT_COMPACT,
 OPT_RERUN,
+OPT_INSTRUCTION_LIMIT,
 };
 static const struct option lopts[] = {
 { "min-input-size", no_argument, NULL, OPT_MIN_SIZE },
 { "compact", required_argument, NULL, OPT_COMPACT },
 { "rerun", no_argument, NULL, OPT_RERUN },
+{ "instruction-limit", required_argument, NULL, 
OPT_INSTRUCTION_LIMIT },
 { 0, 0, 0, 0 }
 };
 int c = getopt_long_only(argc, argv, "", lopts, NULL);
@@ -51,8 +54,14 @@ int main(int argc, char **argv)
 opt_rerun = true;
 break;
 
+case OPT_INSTRUCTION_LIMIT:
+opt_instruction_limit = atoi(optarg);
+if ( !opt_instruction_limit )
+opt_instruction_limit = UINT_MAX;
+break;
+
 case '?':
-printf("Usage: %s [--compact=0|1] [--rerun] $FILE [$FILE...] | 
[--min-input-size]\n", argv[0]);
+printf("Usage: %s [--compact=0|1] [--rerun] 
[--instruction-limit=N] $FILE [$FILE...] | [--min-input-size]\n", argv[0]);
 exit(-1);
 break;
 
diff --git a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c 
b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
index 881c4d03c1..d2198e71c9 100644
--- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
+++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
@@ -984,10 +984,13 @@ static void setup_fuzz_state(struct fuzz_state *state, 
const void *data_p, size_
 state->data_num = size;
 }
 
+unsigned int opt_instruction_limit = UINT_MAX;
+
 static int runtest(struct fuzz_state *state) {
 int rc;
 
 struct x86_emulate_ctxt *ctxt = >ctxt;
+unsigned int icount = 0;
 
 state->ops = all_fuzzer_ops;
 
@@ -1011,7 +1014,7 @@ static int runtest(struct fuzz_state *state) {
 
 rc = x86_emulate(ctxt, >ops);
 printf("Emulation result: %d\n", rc);
-} while ( rc == X86EMUL_OKAY );
+} while ( rc == X86EMUL_OKAY && ++icount < opt_instruction_limit );
 
 save_fpu_state(state->fxsave);
 
diff --git a/tools/fuzz/x86_instruction_emulator/fuzz-emul.h 
b/tools/fuzz/x86_instruction_emulator/fuzz-emul.h
index 4863bf2166..746e1b542d 

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

2017-10-11 Thread George Dunlap
x86_emulate() operates not only on state passed to it in
cpu_user_regs, but also on state currently found on the cpu: namely,
the FPU and XMM registers.  At the moment, we re-zero (and/or
re-initialize) cpu_user_regs on every invocation, but leave the
cpu-stored state alone.  In "persistent mode", this causes test cases
to behave differently -- sometimes significantly so -- depending on
which test cases have been run beforehand.

Zero out the state before each test run, and then fuzz it based on the
corpus input.

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.

Signed-off-by: George Dunlap 
---
v4:
- Remove ineffective fxrstor
- Sanitize fcs and fds elements
v3:
- Make type 512 bytes rather than 464
- Style changes
- Change argument from 'store' to 'write'
- Add a comment explaining why we always 'save' even for a write
- Sanitize mxcsr with mxcrs_mask when writing instead of zeroing it in 
sanitize_state
- Get rid of redundant mxcsr_mask setting
- Add comments explaining why we're arbitrarily writing 32 bits
v2: Rebase on top of previous changes

CC: Ian Jackson 
CC: Wei Liu 
CC: Andrew Cooper 
CC: Jan Beulich 
---
 tools/fuzz/x86_instruction_emulator/fuzz-emul.c | 102 +++-
 1 file changed, 101 insertions(+), 1 deletion(-)

diff --git a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c 
b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
index f1621f98da..881c4d03c1 100644
--- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
+++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
@@ -36,6 +36,7 @@ struct fuzz_state
 uint64_t msr[MSR_INDEX_MAX];
 struct segment_register segments[SEG_NUM];
 struct cpu_user_regs regs;
+char fxsave[512] __attribute__((aligned(16)));
 
 /* Fuzzer's input data. */
 #define DATA_SIZE_FULL offsetof(struct fuzz_state, corpus)
@@ -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;
+
+asm volatile( "fxrstor %0" :: "m" (*fxs) );
+}
+
+asm volatile( "fxsave %0" : "=m" (*fxs) );
+}
+}
+
+static void set_fpu_state(char *fxsave)
+{
+_set_fpu_state(fxsave, true);
+}
+
+static void save_fpu_state(char *fxsave)
+{
+_set_fpu_state(fxsave, false);
+}
+
 static void setup_fpu_exception_handler(void)
 {
 /* FIXME - just disable exceptions for now */
@@ -669,7 +739,11 @@ static void setup_state(struct x86_emulate_ctxt *ctxt)
 return;
 }
 
-/* Modify only select bits of state */
+/*
+ * Modify only select bits of state.  In general, try not to fuzz less
+ * than 32 bits at a time; otherwise we're reading 2 bytes in order to 
fuzz only
+ * one byte. 
+ */
 
 /* Always read 'options' */
 if ( !input_read(s, s, DATA_SIZE_COMPACT) )
@@ -732,6 +806,18 @@ static void setup_state(struct 

[Xen-devel] [PATCH v4 09/12] fuzz/x86_emulate: Make input more compact

2017-10-11 Thread George Dunlap
At the moment, AFL reckons that for any given input, 87% of it is
completely irrelevant: that is, it can change it as much as it wants
but have no impact on the result of the test; and yet it can't remove
it.

This is largely because we interpret the blob handed to us as a large
struct, including CR values, MSR values, segment registers, and a full
cpu_user_regs.

Instead, modify our interpretation to have a "set state" stanza at the
front.  Begin by reading a 16-bit value; if it is lower than a certain
threshold, set some state according to what byte it is, and repeat.
Continue until the byte is above a certain threshold.

This allows AFL to compact any given test case much smaller; to the
point where now it reckons there is not a single byte of the test file
which becomes irrelevant.  Testing have shown that this option both
allows AFL to reach coverage much faster, and to have a total coverage
higher than with the old format.

Make this an option (rather than a unilateral change) to enable
side-by-side performance comparison of the old and new formats.

Signed-off-by: George Dunlap 
Acked-by: Ian Jackson 
Acked-by: Jan Beulich 
---
v4:
 - Rebase over previous changes
v3:
 - Set default for opt_compact statically in fuzz-emul.c rather than afl-harness
 - Make input size / unconditional input reading more consistent
 - Require only minimum input read, not first instruction byte
 - Use ARRAY_SIZE() for hardcoded values
 - Use `for ( ; ; )` rather than `while(1)`
 - Some style issues
 - Move opt_compact declaration into fuzz-emul.h
v2: Port over previous changes

CC: Ian Jackson 
CC: Wei Liu 
CC: Andrew Cooper 
CC: Jan Beulich 
---
 tools/fuzz/x86_instruction_emulator/afl-harness.c |   9 +-
 tools/fuzz/x86_instruction_emulator/fuzz-emul.c   | 103 +++---
 tools/fuzz/x86_instruction_emulator/fuzz-emul.h   |   2 +
 3 files changed, 99 insertions(+), 15 deletions(-)

diff --git a/tools/fuzz/x86_instruction_emulator/afl-harness.c 
b/tools/fuzz/x86_instruction_emulator/afl-harness.c
index d514468dd2..23a77a73c0 100644
--- a/tools/fuzz/x86_instruction_emulator/afl-harness.c
+++ b/tools/fuzz/x86_instruction_emulator/afl-harness.c
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "fuzz-emul.h"
 
 static uint8_t input[INPUT_SIZE];
@@ -21,9 +22,11 @@ int main(int argc, char **argv)
 {
 enum {
 OPT_MIN_SIZE,
+OPT_COMPACT,
 };
 static const struct option lopts[] = {
 { "min-input-size", no_argument, NULL, OPT_MIN_SIZE },
+{ "compact", required_argument, NULL, OPT_COMPACT },
 { 0, 0, 0, 0 }
 };
 int c = getopt_long_only(argc, argv, "", lopts, NULL);
@@ -38,8 +41,12 @@ int main(int argc, char **argv)
 exit(0);
 break;
 
+case OPT_COMPACT:
+opt_compact = atoi(optarg);
+break;
+
 case '?':
-printf("Usage: %s $FILE [$FILE...] | [--min-input-size]\n", 
argv[0]);
+printf("Usage: %s [--compact=0|1] $FILE [$FILE...] | 
[--min-input-size]\n", argv[0]);
 exit(-1);
 break;
 
diff --git a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c 
b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
index 4e3751ce50..3ea8a8b726 100644
--- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
+++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
@@ -31,14 +31,15 @@ struct fuzz_state
 {
 /* Emulated CPU state */
 unsigned long options;
+#define DATA_SIZE_COMPACT offsetof(struct fuzz_state, cr)
 unsigned long cr[5];
 uint64_t msr[MSR_INDEX_MAX];
 struct segment_register segments[SEG_NUM];
 struct cpu_user_regs regs;
 
 /* Fuzzer's input data. */
-#define DATA_OFFSET offsetof(struct fuzz_state, corpus)
-const unsigned char * corpus;
+#define DATA_SIZE_FULL offsetof(struct fuzz_state, corpus)
+const unsigned char *corpus;
 
 /* Real amount of data backing corpus[]. */
 size_t data_num;
@@ -50,6 +51,15 @@ struct fuzz_state
 struct x86_emulate_ops ops;
 };
 
+bool opt_compact = true;
+
+unsigned int fuzz_minimal_input_size(void)
+{
+BUILD_BUG_ON(DATA_SIZE_FULL > INPUT_SIZE);
+
+return opt_compact ? DATA_SIZE_COMPACT : DATA_SIZE_FULL;
+}
+
 static inline bool input_avail(const struct fuzz_state *s, size_t size)
 {
 return s->data_index + size <= s->data_num;
@@ -643,9 +653,82 @@ 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))
-exit(-1);
+if ( !opt_compact )
+{
+/* Fuzz all of the emulated state in one go */
+if ( !input_read(s, s, DATA_SIZE_FULL) )
+exit(-1);
+return;
+}
+
+/* 

[Xen-devel] [PATCH v4 02/12] fuzz/x86_emulate: Improve failure descriptions in x86_emulate harness

2017-10-11 Thread George Dunlap
- Print the symbolic name rather than the number
- Explicitly state when data_read() fails due to EOI

Signed-off-by: George Dunlap 
Reviewed-by: Wei Liu 
Reviewed-by: Jan Beulich 
---
Changes in v4:
- Make array 'static const char* const'
Changes in v2:
- Add spaces around '='

CC: Ian Jackson 
CC: Wei Liu 
CC: Andrew Cooper 
CC: Jan Beulich 
---
 tools/fuzz/x86_instruction_emulator/fuzz-emul.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c 
b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
index 48a879cc88..999f417716 100644
--- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
+++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
@@ -52,6 +52,14 @@ struct fuzz_state
 struct x86_emulate_ops ops;
 };
 
+static const char* const x86emul_return_string[] = {
+[X86EMUL_OKAY] = "X86EMUL_OKAY",
+[X86EMUL_UNHANDLEABLE] = "X86EMUL_UNHANDLEABLE",
+[X86EMUL_EXCEPTION] = "X86EMUL_EXCEPTION",
+[X86EMUL_RETRY] = "X86EMUL_RETRY",
+[X86EMUL_DONE] = "X86EMUL_DONE",
+};
+
 /*
  * Randomly return success or failure when processing data.  If
  * `exception` is false, this function turns _EXCEPTION to _OKAY.
@@ -84,7 +92,7 @@ static int maybe_fail(struct x86_emulate_ctxt *ctxt,
 if ( rc == X86EMUL_EXCEPTION && !exception )
 rc = X86EMUL_OKAY;
 
-printf("maybe_fail %s: %d\n", why, rc);
+printf("maybe_fail %s: %s\n", why, x86emul_return_string[rc]);
 
 if ( rc == X86EMUL_EXCEPTION )
 /* Fake up a pagefault. */
@@ -113,6 +121,7 @@ static int data_read(struct x86_emulate_ctxt *ctxt,
 x86_emul_hw_exception(13, 0, ctxt);
 
 rc = X86EMUL_EXCEPTION;
+printf("data_read %s: X86EMUL_EXCEPTION (end of input)\n", why);
 }
 else
 rc = maybe_fail(ctxt, why, true);
-- 
2.14.2


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


[Xen-devel] [PATCH v4 06/12] fuzz/x86_emulate: Take multiple test files for inputs

2017-10-11 Thread George Dunlap
Finding aggregate coverage for a set of test files means running each
afl-generated test case through the harness.  At the moment, this is
done by re-executing afl-harness-cov with each input file.  When a
large number of test cases have been generated, this can take a
significant amonut of time; a recent test with 30k total files
generated by 4 parallel fuzzers took over 7 minutes.

The vast majority of this time is taken up with 'exec', however.
Since the harness is already designed to loop over multiple inputs for
llvm "persistent mode", just allow it to take a large number of inputs
on the same when *not* running in llvm "persistent mode"..  Then the
command can be efficiently executed like this:

  ls */queue/id* | xargs $path/afl-harness-cov

For the above-mentioned test on 30k files, the time to generate
coverage data was reduced from 7 minutes to under 30 seconds.

Signed-off-by: George Dunlap 
Acked-by: Jan Beulich 
Acked-by: Andrew Cooper 
---
v4:
- Fix printf to print the right filename
v3:
- Combine some variable declarations
- Make sure that count is set only once no matter how it's compiled
v2:
- Make check for batch processing more clear

Jan: I took the liberty of retaining your Ack on this, since it was a
simple and obvious fix (which I think you had also suggested).

CC: Ian Jackson 
CC: Wei Liu 
CC: Andrew Cooper 
CC: Jan Beulich 
---
 tools/fuzz/README.afl |  7 +++
 tools/fuzz/x86_instruction_emulator/afl-harness.c | 25 +++
 2 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/tools/fuzz/README.afl b/tools/fuzz/README.afl
index 8b58b8cdea..a59564985a 100644
--- a/tools/fuzz/README.afl
+++ b/tools/fuzz/README.afl
@@ -49,6 +49,13 @@ generate coverage data.  To do this, use the target 
`afl-cov`:
 
 $ make afl-cov #produces afl-harness-cov
 
+In order to speed up the process of checking total coverage,
+`afl-harness-cov` can take several test inputs on its command-line;
+the speed-up effect should be similar to that of using afl-clang-fast.
+You can use xargs to do this most efficiently, like so:
+
+$ ls queue/id* | xargs $path/afl-harness-cov
+
 NOTE: Please also note that the coverage instrumentation hard-codes
 the absolute path for the instrumentation read and write files in the
 binary; so coverage data will always show up in the build directory no
diff --git a/tools/fuzz/x86_instruction_emulator/afl-harness.c 
b/tools/fuzz/x86_instruction_emulator/afl-harness.c
index 31ae1daef1..e0c56aadf7 100644
--- a/tools/fuzz/x86_instruction_emulator/afl-harness.c
+++ b/tools/fuzz/x86_instruction_emulator/afl-harness.c
@@ -16,6 +16,7 @@ int main(int argc, char **argv)
 {
 size_t size;
 FILE *fp = NULL;
+int max, count;
 
 setbuf(stdin, NULL);
 setbuf(stdout, NULL);
@@ -42,8 +43,7 @@ int main(int argc, char **argv)
 break;
 
 case '?':
-usage:
-printf("Usage: %s $FILE | [--min-input-size]\n", argv[0]);
+printf("Usage: %s $FILE [$FILE...] | [--min-input-size]\n", 
argv[0]);
 exit(-1);
 break;
 
@@ -54,10 +54,13 @@ int main(int argc, char **argv)
 }
 }
 
-if ( optind == argc ) /* No positional parameters.  Use stdin. */
+max = argc - optind;
+
+if ( !max ) /* No positional parameters.  Use stdin. */
+{
+max = 1;
 fp = stdin;
-else if ( optind != (argc - 1) )
-goto usage;
+}
 
 if ( LLVMFuzzerInitialize(, ) )
 exit(-1);
@@ -65,12 +68,15 @@ int main(int argc, char **argv)
 #ifdef __AFL_HAVE_MANUAL_CONTROL
 __AFL_INIT();
 
-while ( __AFL_LOOP(1000) )
+for( count = 0; __AFL_LOOP(1000); )
+#else
+for( count = 0; count < max; count++ )
 #endif
 {
 if ( fp != stdin ) /* If not using stdin, open the provided file. */
 {
-fp = fopen(argv[optind], "rb");
+printf("Opening file %s\n", argv[optind + count]);
+fp = fopen(argv[optind + count], "rb");
 if ( fp == NULL )
 {
 perror("fopen");
@@ -100,7 +106,10 @@ int main(int argc, char **argv)
 if ( !feof(fp) )
 {
 printf("Input too large\n");
-exit(-1);
+/* Don't exit if we're doing batch processing */
+if ( max == 1 )
+exit(-1);
+continue;
 }
 
 if ( fp != stdin )
-- 
2.14.2


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


[Xen-devel] [PATCH v4 04/12] fuzz/x86_emulate: Rename the file containing the wrapper code

2017-10-11 Thread George Dunlap
When generating coverage output, by default gcov generates output
filenames based only on the coverage file and the "leaf" source file,
not the full path.  As a result, it uses the same name for
x86_emulate.c and x86_emulate/x86_emulate.c, generally overwriting the
second (which we actually are about) with the first (which is just a
wrapper).

Rename the user-space wrapper helpers to x86-emulate.[ch], so
that it generates separate files.

There is actually an option to gcov, `--preserve-paths`, which will
cause the full path name to be included in the filename, properly
distinguishing between the two.  However, given that the user-space
wrapper doesn't actually do any emulation (and the poor state of gcov
documentation making it difficult to find the option in the first
place), it seems to make more sense to rename the file anyway.

Signed-off-by: George Dunlap 
Acked-by: Wei Liu 
Acked-by: Jan Beulich 
---
v3:
- x86-emulate.* rather than x86_emulate_user.*
- Also update .gitignore to ignore the new files

NB: I discovered the `-p` option to gcov after writing this patch.
But I think the patch itself still makes sense.

CC: Ian Jackson 
CC: Wei Liu 
CC: Andrew Cooper 
CC: Jan Beulich 
---
 .gitignore|  3 ++-
 tools/fuzz/x86_instruction_emulator/Makefile  | 12 ++--
 tools/fuzz/x86_instruction_emulator/fuzz-emul.c   |  2 +-
 tools/tests/x86_emulator/Makefile |  6 +++---
 tools/tests/x86_emulator/test_x86_emulator.c  |  2 +-
 tools/tests/x86_emulator/{x86_emulate.c => x86-emulate.c} |  2 +-
 tools/tests/x86_emulator/{x86_emulate.h => x86-emulate.h} |  0
 7 files changed, 14 insertions(+), 13 deletions(-)
 rename tools/tests/x86_emulator/{x86_emulate.c => x86-emulate.c} (99%)
 rename tools/tests/x86_emulator/{x86_emulate.h => x86-emulate.h} (100%)

diff --git a/.gitignore b/.gitignore
index 95f40f19c8..b3587f3809 100644
--- a/.gitignore
+++ b/.gitignore
@@ -163,7 +163,8 @@ tools/flask/utils/flask-set-bool
 tools/flask/utils/flask-label-pci
 tools/fuzz/libelf/afl-libelf-fuzzer
 tools/fuzz/x86_instruction_emulator/asm
-tools/fuzz/x86_instruction_emulator/x86_emulate*
+tools/fuzz/x86_instruction_emulator/x86_emulate
+tools/fuzz/x86_instruction_emulator/x86-emulate.[ch]
 tools/fuzz/x86_instruction_emulator/afl-harness
 tools/helpers/_paths.h
 tools/helpers/init-xenstore-domain
diff --git a/tools/fuzz/x86_instruction_emulator/Makefile 
b/tools/fuzz/x86_instruction_emulator/Makefile
index a3f6b2c754..107bf62a21 100644
--- a/tools/fuzz/x86_instruction_emulator/Makefile
+++ b/tools/fuzz/x86_instruction_emulator/Makefile
@@ -18,22 +18,22 @@ asm:
 
 asm/%: asm ;
 
-x86_emulate.c x86_emulate.h: %:
+x86-emulate.c x86-emulate.h: %:
[ -L $* ] || ln -sf $(XEN_ROOT)/tools/tests/x86_emulator/$*
 
 CFLAGS += $(CFLAGS_xeninclude) -D__XEN_TOOLS__ -I.
 
 x86.h := asm/x86-vendors.h asm/x86-defns.h asm/msr-index.h
-x86_emulate.h := x86_emulate.h x86_emulate/x86_emulate.h $(x86.h)
+x86_emulate.h := x86-emulate.h x86_emulate/x86_emulate.h $(x86.h)
 
-x86_emulate.o: x86_emulate.c x86_emulate/x86_emulate.c $(x86_emulate.h)
+x86-emulate.o: x86-emulate.c x86_emulate/x86_emulate.c $(x86_emulate.h)
 
 fuzz-emul.o: $(x86_emulate.h)
 
-x86-insn-fuzzer.a: fuzz-emul.o x86_emulate.o
+x86-insn-fuzzer.a: fuzz-emul.o x86-emulate.o
$(AR) rc $@ $^
 
-afl-harness: afl-harness.o fuzz-emul.o x86_emulate.o
+afl-harness: afl-harness.o fuzz-emul.o x86-emulate.o
$(CC) $(CFLAGS) $^ -o $@
 
 # Common targets
@@ -42,7 +42,7 @@ all: x86-insn-fuzz-all
 
 .PHONY: distclean
 distclean: clean
-   rm -f x86_emulate x86_emulate.c x86_emulate.h asm
+   rm -f x86_emulate x86-emulate.c x86-emulate.h asm
 
 .PHONY: clean
 clean:
diff --git a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c 
b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
index 5fb8586955..8998f21fe1 100644
--- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
+++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
@@ -15,7 +15,7 @@
 #include 
 #include 
 
-#include "x86_emulate.h"
+#include "x86-emulate.h"
 
 #define MSR_INDEX_MAX 16
 
diff --git a/tools/tests/x86_emulator/Makefile 
b/tools/tests/x86_emulator/Makefile
index d7be77d98a..ed0fd9710e 100644
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -77,7 +77,7 @@ $(addsuffix .h,$(TESTCASES)): %.h: %.c testcase.mk Makefile
 $(addsuffix .c,$(SIMD)) $(addsuffix -avx.c,$(filter sse%,$(SIMD))):
ln -sf simd.c $@
 
-$(TARGET): x86_emulate.o test_x86_emulator.o
+$(TARGET): x86-emulate.o test_x86_emulator.o
$(HOSTCC) $(HOSTCFLAGS) -o $@ $^
 
 .PHONY: clean
@@ -105,9 +105,9 @@ $(call cc-option-add,HOSTCFLAGS-x86_64,HOSTCC,-no-pie)
 HOSTCFLAGS += $(CFLAGS_xeninclude) -I. $(HOSTCFLAGS-$(XEN_COMPILE_ARCH))
 
 x86.h := 

[Xen-devel] [PATCH v4 05/12] fuzz/x86_emulate: Add 'afl-cov' target

2017-10-11 Thread George Dunlap
...to generate a "normal" coverage-instrumented binary, suitable for
use with gcov or afl-cov.

This is slightly annoying because:

 - Every object file needs to have been instrumented to work
   effectively

 - You generally want to have both an afl-instrumented binary and a
   gcov-instrumented binary at the same time, but

 - gcov instrumentation and afl instrumentation are mutually exclusive

So when making the `afl-cov` target, generate a second set of object
files and a second binary with the `-cov` suffix.

While we're here, remove the redundant x86-emulate.c dependency for
x86-emulate.o.

Signed-off-by: George Dunlap 
Acked-by: Andrew Cooper 
---
v3:
- Rebase on new versions of previous patch (mainly x86-emulate.* rename)
- Tighten up build rules
- Add newline at the end of README.afl
- Use := for GCOV_FLAGS in Makefile
Changes in v2:
- Pull 'inputs' to x86_emulate_user* into a make variable to avoid duplication

CC: Ian Jackson 
CC: Wei Liu 
CC: Andrew Cooper 
CC: Jan Beulich 
---
 .gitignore   |  1 +
 tools/fuzz/README.afl| 14 ++
 tools/fuzz/x86_instruction_emulator/Makefile | 17 ++---
 3 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index b3587f3809..d64b03d06c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -166,6 +166,7 @@ tools/fuzz/x86_instruction_emulator/asm
 tools/fuzz/x86_instruction_emulator/x86_emulate
 tools/fuzz/x86_instruction_emulator/x86-emulate.[ch]
 tools/fuzz/x86_instruction_emulator/afl-harness
+tools/fuzz/x86_instruction_emulator/afl-harness-cov
 tools/helpers/_paths.h
 tools/helpers/init-xenstore-domain
 tools/helpers/xen-init-dom0
diff --git a/tools/fuzz/README.afl b/tools/fuzz/README.afl
index 4758de2490..8b58b8cdea 100644
--- a/tools/fuzz/README.afl
+++ b/tools/fuzz/README.afl
@@ -41,3 +41,17 @@ Use the x86 instruction emulator fuzzer as an example.
$ $AFLPATH/afl-fuzz -t 1000 -i testcase_dir -o findings_dir -- ./afl-harness
 
 Please see AFL documentation for more information.
+
+# GENERATING COVERAGE INFORMATION
+
+To use afl-cov or gcov, you need a separate binary instrumented to
+generate coverage data.  To do this, use the target `afl-cov`:
+
+$ make afl-cov #produces afl-harness-cov
+
+NOTE: Please also note that the coverage instrumentation hard-codes
+the absolute path for the instrumentation read and write files in the
+binary; so coverage data will always show up in the build directory no
+matter where you run the binary from.
+
+Please see afl-cov and/or gcov documentation for more information.
diff --git a/tools/fuzz/x86_instruction_emulator/Makefile 
b/tools/fuzz/x86_instruction_emulator/Makefile
index 107bf62a21..cb561aec3f 100644
--- a/tools/fuzz/x86_instruction_emulator/Makefile
+++ b/tools/fuzz/x86_instruction_emulator/Makefile
@@ -23,12 +23,17 @@ x86-emulate.c x86-emulate.h: %:
 
 CFLAGS += $(CFLAGS_xeninclude) -D__XEN_TOOLS__ -I.
 
+GCOV_FLAGS := --coverage
+%-cov.o: %.c
+   $(CC) -c $(CFLAGS) $(GCOV_FLAGS) $< -o $@
+
 x86.h := asm/x86-vendors.h asm/x86-defns.h asm/msr-index.h
 x86_emulate.h := x86-emulate.h x86_emulate/x86_emulate.h $(x86.h)
 
-x86-emulate.o: x86-emulate.c x86_emulate/x86_emulate.c $(x86_emulate.h)
+# x86-emulate.c will be implicit for both
+x86-emulate.o x86-emulate-cov.o: x86_emulate/x86_emulate.c $(x86_emulate.h)
 
-fuzz-emul.o: $(x86_emulate.h)
+fuzz-emul.o fuzz-emulate-cov.o: $(x86_emulate.h)
 
 x86-insn-fuzzer.a: fuzz-emul.o x86-emulate.o
$(AR) rc $@ $^
@@ -36,6 +41,9 @@ x86-insn-fuzzer.a: fuzz-emul.o x86-emulate.o
 afl-harness: afl-harness.o fuzz-emul.o x86-emulate.o
$(CC) $(CFLAGS) $^ -o $@
 
+afl-harness-cov: afl-harness-cov.o fuzz-emul-cov.o x86-emulate-cov.o
+   $(CC) $(CFLAGS) $(GCOV_FLAGS) $^ -o $@
+
 # Common targets
 .PHONY: all
 all: x86-insn-fuzz-all
@@ -46,7 +54,7 @@ distclean: clean
 
 .PHONY: clean
 clean:
-   rm -f *.a *.o .*.d afl-harness
+   rm -f *.a *.o .*.d afl-harness afl-harness-cov *.gcda *.gcno *.gcov
 
 .PHONY: install
 install: all
@@ -55,3 +63,6 @@ install: all
 
 .PHONY: afl
 afl: afl-harness
+
+.PHONY: afl-cov
+afl-cov: afl-harness-cov
-- 
2.14.2


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


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

2017-10-11 Thread George Dunlap
Current stability numbers are not 100%.  In order to help track this
down, add a --rerun option which will run the same input twice,
resetting the state between each run, and comparing the state
afterwards.  If the state differs, call abort().

This allows AFL to help the process of tracking down what state is not
being reset properly between runs by proving testcases that
demonstrate the behavior.

To do this:

- Move ctxt into struct fuzz-state to simplify handling

- Rather than copying the data into input, treat the data handed as
  immutable and point each "copy" to it

- Factor out various steps (setting up fuzz state, running an
  individual test) so that they can be efficiently run either once or
  twice (as necessary)

- Compare the states afterwards, printing what's different and calling
  abort() if anything is found.

Signed-off-by: George Dunlap 
---
v4:
- Fix some stylistic issues
- Rename PINE macro to PRINT_NE
- Remove unnecessary printf
- Fix size_t format string
v3:
- Make new local functions static
- Avoid losing const-ness of pointer in setup_fuzz_state()
- Remove useless *_size initialization
- Remove extra blank line
- Use ARRAY_SIZE() when appropriate
- Move opt_rerun declaration into fuzz-emul.h
- Change loop variable to unsigned int
- Print segment contents when segments differ
v2:
- Fix some coding style issues
- Port over previous changes

CC: Ian Jackson 
CC: Wei Liu 
CC: Andrew Cooper 
CC: Jan Beulich 
---
 tools/fuzz/x86_instruction_emulator/afl-harness.c |   8 +-
 tools/fuzz/x86_instruction_emulator/fuzz-emul.c   | 188 ++
 tools/fuzz/x86_instruction_emulator/fuzz-emul.h   |   1 +
 3 files changed, 168 insertions(+), 29 deletions(-)

diff --git a/tools/fuzz/x86_instruction_emulator/afl-harness.c 
b/tools/fuzz/x86_instruction_emulator/afl-harness.c
index 23a77a73c0..0489034642 100644
--- a/tools/fuzz/x86_instruction_emulator/afl-harness.c
+++ b/tools/fuzz/x86_instruction_emulator/afl-harness.c
@@ -23,10 +23,12 @@ int main(int argc, char **argv)
 enum {
 OPT_MIN_SIZE,
 OPT_COMPACT,
+OPT_RERUN,
 };
 static const struct option lopts[] = {
 { "min-input-size", no_argument, NULL, OPT_MIN_SIZE },
 { "compact", required_argument, NULL, OPT_COMPACT },
+{ "rerun", no_argument, NULL, OPT_RERUN },
 { 0, 0, 0, 0 }
 };
 int c = getopt_long_only(argc, argv, "", lopts, NULL);
@@ -45,8 +47,12 @@ int main(int argc, char **argv)
 opt_compact = atoi(optarg);
 break;
 
+case OPT_RERUN:
+opt_rerun = true;
+break;
+
 case '?':
-printf("Usage: %s [--compact=0|1] $FILE [$FILE...] | 
[--min-input-size]\n", argv[0]);
+printf("Usage: %s [--compact=0|1] [--rerun] $FILE [$FILE...] | 
[--min-input-size]\n", argv[0]);
 exit(-1);
 break;
 
diff --git a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c 
b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
index 3ea8a8b726..f1621f98da 100644
--- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
+++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
@@ -49,6 +49,7 @@ struct fuzz_state
 
 /* Emulation ops, some of which are disabled based on options. */
 struct x86_emulate_ops ops;
+struct x86_emulate_ctxt ctxt;
 };
 
 bool opt_compact = true;
@@ -493,6 +494,12 @@ static int fuzz_read_msr(
 const struct fuzz_state *s = ctxt->data;
 unsigned int idx;
 
+/* 
+ * NB at the moment dump_state() relies on the fact that this
+ * cannot fail.  If we add in fuzzed failures we'll have to handle
+ * that differently.
+ */
+
 switch ( reg )
 {
 case MSR_TSC_AUX:
@@ -613,6 +620,7 @@ static void dump_state(struct x86_emulate_ctxt *ctxt)
 
 printf(" rip: %"PRIx64"\n", regs->rip);
 
+/* read_msr() never fails at the moment */
 fuzz_read_msr(MSR_EFER, , ctxt);
 printf("EFER: %"PRIx64"\n", val);
 }
@@ -787,9 +795,8 @@ enum {
 printf("Disabling hook "#h"\n");   \
 }
 
-static void disable_hooks(struct x86_emulate_ctxt *ctxt)
+static void disable_hooks(struct fuzz_state *s)
 {
-struct fuzz_state *s = ctxt->data;
 unsigned long bitmap = s->options;
 
 /* See also sanitize_input, some hooks can't be disabled. */
@@ -837,7 +844,7 @@ static void disable_hooks(struct x86_emulate_ctxt *ctxt)
  *  - ...bases to below 1Mb, 16-byte aligned
  *  - ...selectors to (base >> 4)
  */
-static void sanitize_input(struct x86_emulate_ctxt *ctxt)
+static void sanitize_state(struct x86_emulate_ctxt *ctxt)
 {
 struct fuzz_state *s = ctxt->data;
 struct cpu_user_regs *regs = ctxt->regs;
@@ -884,20 +891,146 @@ int LLVMFuzzerInitialize(int *argc, char ***argv)
 return 0;
 }
 
-int LLVMFuzzerTestOneInput(const 

[Xen-devel] [PATCH v4 01/12] fuzz/x86_emulate: Clear errors in the officially sanctioned way

2017-10-11 Thread George Dunlap
Commit 849a1f10c9 was checked in inappropriately; review flagged up
that clearerr() was too big a hammer, as it would clear both the EOF
flag and stream errors.

Stream errors shouldn't be cleared; we only want the EOF and other
stream-related state reset.  To do this, it is sufficient to fseek()
to zero.

Signed-off-by: George Dunlap 
Acked-by: Andrew Cooper 
---
This is a candidate for backport to 4.9 (probably merged with 849a1f10c9).

CC: Ian Jackson 
CC: Wei Liu 
CC: Andrew Cooper 
CC: Jan Beulich 
---
 tools/fuzz/x86_instruction_emulator/afl-harness.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/tools/fuzz/x86_instruction_emulator/afl-harness.c 
b/tools/fuzz/x86_instruction_emulator/afl-harness.c
index b4d15451b5..31ae1daef1 100644
--- a/tools/fuzz/x86_instruction_emulator/afl-harness.c
+++ b/tools/fuzz/x86_instruction_emulator/afl-harness.c
@@ -77,6 +77,17 @@ int main(int argc, char **argv)
 exit(-1);
 }
 }
+#ifdef __AFL_HAVE_MANUAL_CONTROL
+else
+{
+/* 
+ * This will ensure we're dealing with a clean stream
+ * state after the afl-fuzz process messes with the open
+ * file handle.
+ */
+fseek(fp, 0, SEEK_SET);
+}
+#endif
 
 size = fread(input, 1, INPUT_SIZE, fp);
 
@@ -97,8 +108,6 @@ int main(int argc, char **argv)
 fclose(fp);
 fp = NULL;
 }
-else
-clearerr(fp);
 
 LLVMFuzzerTestOneInput(input, size);
 }
-- 
2.14.2


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


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

2017-10-11 Thread George Dunlap
At the moment we copy data from the input into a struct named
'corpus', then read and write this state (so that it no longer
resembles the corpus that we read from).

Instead, move all "emulated cpu" state into fuzz_state, and explicitly
state that we are expecting to change it.  Get rid of 'input', and
always read data directly from the pointer passed into the fuzzer.

Signed-off-by: George Dunlap 
---
v4:
 - Reword commit message to make it clear it's not just about the compact state
 - Get rid of fuzz_corpus entirely, and avoid the unnecessary copy
v3:
 - Move DATA_OFFSET inside the structure
 - Remove a stray blank line
v2: Port over previous changes

CC: Ian Jackson 
CC: Wei Liu 
CC: Andrew Cooper 
CC: Jan Beulich 
---
 tools/fuzz/x86_instruction_emulator/fuzz-emul.c | 114 +++-
 1 file changed, 53 insertions(+), 61 deletions(-)

diff --git a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c 
b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
index 964682aa1a..4e3751ce50 100644
--- 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;
 
-/* Real amount of data backing corpus->data[]. */
+/* Real amount of data backing corpus[]. */
 size_t data_num;
 
-/* Amount of corpus->data[] consumed thus far. */
+/* Amount of corpus[] data consumed thus far. */
 size_t data_index;
 
-/* Emulation ops, some of which are disabled based on corpus->options. */
+/* Emulation ops, some of which are disabled based on options. */
 struct x86_emulate_ops ops;
 };
 
@@ -63,7 +60,7 @@ static inline bool input_read(struct fuzz_state *s, void 
*dst, size_t size)
 if ( !input_avail(s, size) )
 return false;
 
-memcpy(dst, >corpus->data[s->data_index], size);
+memcpy(dst, >corpus[s->data_index], size);
 s->data_index += size;
 
 return true;
@@ -393,11 +390,10 @@ static int fuzz_read_segment(
 struct x86_emulate_ctxt *ctxt)
 {
 const struct fuzz_state *s = ctxt->data;
-const struct fuzz_corpus *c = s->corpus;
 
 assert(is_x86_user_segment(seg) || is_x86_system_segment(seg));
 
-*reg = c->segments[seg];
+*reg = s->segments[seg];
 
 return X86EMUL_OKAY;
 }
@@ -408,7 +404,6 @@ static int fuzz_write_segment(
 struct x86_emulate_ctxt *ctxt)
 {
 struct fuzz_state *s = ctxt->data;
-struct fuzz_corpus *c = s->corpus;
 int rc;
 
 assert(is_x86_user_segment(seg) || is_x86_system_segment(seg));
@@ -416,7 +411,7 @@ static int fuzz_write_segment(
 rc = maybe_fail(ctxt, "write_segment", true);
 
 if ( rc == X86EMUL_OKAY )
-c->segments[seg] = *reg;
+s->segments[seg] = *reg;
 
 return rc;
 }
@@ -427,12 +422,11 @@ static int fuzz_read_cr(
 struct x86_emulate_ctxt *ctxt)
 {
 const struct fuzz_state *s = ctxt->data;
-const struct fuzz_corpus *c = s->corpus;
 
-if ( reg >= ARRAY_SIZE(c->cr) )
+if ( reg >= ARRAY_SIZE(s->cr) )
 return X86EMUL_UNHANDLEABLE;
 
-*val = c->cr[reg];
+*val = s->cr[reg];
 
 return X86EMUL_OKAY;
 }
@@ -443,17 +437,16 @@ static int fuzz_write_cr(
 struct x86_emulate_ctxt *ctxt)
 {
 struct fuzz_state *s = ctxt->data;
-struct fuzz_corpus *c = s->corpus;
 int rc;
 
-if ( reg >= ARRAY_SIZE(c->cr) )
+if ( reg >= ARRAY_SIZE(s->cr) )
 return X86EMUL_UNHANDLEABLE;
 
 rc = maybe_fail(ctxt, "write_cr", true);
 if ( rc != X86EMUL_OKAY )
 return rc;
 
-c->cr[reg] = val;
+s->cr[reg] = val;
 
 return X86EMUL_OKAY;
 }
@@ -488,7 +481,6 @@ static int fuzz_read_msr(
 struct x86_emulate_ctxt *ctxt)
 {
 const struct fuzz_state *s = ctxt->data;
-const struct fuzz_corpus *c = s->corpus;
 unsigned int idx;
 
 switch ( reg )
@@ -502,10 +494,10 @@ static int fuzz_read_msr(
  */
 

[Xen-devel] [PATCH v4 03/12] fuzz/x86_emulate: Implement input_read() and input_avail()

2017-10-11 Thread George Dunlap
Rather than open-coding the "read" from the input file.

Signed-off-by: George Dunlap 
Acked-by: Andrew Cooper 
Reviewed-by: Ian Jackson 
---
v3:
 - s/input_available/input_avail/;
 - Constify argument to input_avail
 - Fix off-by-one error in input_avail
 - Return false / true rather than 0 / 1 in input_read
v2:
- Use less dread-ful names
- Return bool rather than int

CC: Ian Jackson 
CC: Wei Liu 
CC: Andrew Cooper 
CC: Jan Beulich 
---
 tools/fuzz/x86_instruction_emulator/fuzz-emul.c | 31 ++---
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c 
b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
index 999f417716..5fb8586955 100644
--- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
+++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
@@ -52,6 +52,22 @@ struct fuzz_state
 struct x86_emulate_ops ops;
 };
 
+static inline bool input_avail(const struct fuzz_state *s, size_t size)
+{
+return s->data_index + size <= s->data_num;
+}
+
+static inline bool input_read(struct fuzz_state *s, void *dst, size_t size)
+{
+if ( !input_avail(s, size) )
+return false;
+
+memcpy(dst, >corpus->data[s->data_index], size);
+s->data_index += size;
+
+return true;
+}
+
 static const char* const x86emul_return_string[] = {
 [X86EMUL_OKAY] = "X86EMUL_OKAY",
 [X86EMUL_UNHANDLEABLE] = "X86EMUL_UNHANDLEABLE",
@@ -68,10 +84,10 @@ static int maybe_fail(struct x86_emulate_ctxt *ctxt,
   const char *why, bool exception)
 {
 struct fuzz_state *s = ctxt->data;
-const struct fuzz_corpus *c = s->corpus;
+unsigned char c;
 int rc;
 
-if ( s->data_index >= s->data_num )
+if ( !input_read(s, , sizeof(c)) )
 rc = X86EMUL_EXCEPTION;
 else
 {
@@ -80,13 +96,12 @@ static int maybe_fail(struct x86_emulate_ctxt *ctxt,
  * 25% unhandlable
  * 25% exception
  */
-if ( c->data[s->data_index] > 0xc0 )
+if ( c > 0xc0 )
 rc = X86EMUL_EXCEPTION;
-else if ( c->data[s->data_index] > 0x80 )
+else if ( c > 0x80 )
 rc = X86EMUL_UNHANDLEABLE;
 else
 rc = X86EMUL_OKAY;
-s->data_index++;
 }
 
 if ( rc == X86EMUL_EXCEPTION && !exception )
@@ -106,11 +121,10 @@ static int data_read(struct x86_emulate_ctxt *ctxt,
  const char *why, void *dst, unsigned int bytes)
 {
 struct fuzz_state *s = ctxt->data;
-const struct fuzz_corpus *c = s->corpus;
 unsigned int i;
 int rc;
 
-if ( s->data_index + bytes > s->data_num )
+if ( !input_avail(s, bytes) )
 {
 /*
  * Fake up a segment limit violation.  System segment limit volations
@@ -128,8 +142,7 @@ static int data_read(struct x86_emulate_ctxt *ctxt,
 
 if ( rc == X86EMUL_OKAY )
 {
-memcpy(dst, >data[s->data_index], bytes);
-s->data_index += bytes;
+input_read(s, dst, bytes);
 
 printf("%s: ", why);
 for ( i = 0; i < bytes; i++ )
-- 
2.14.2


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


[Xen-devel] [PATCH v4 07/12] fuzz/x86_emulate: Move definitions into a header

2017-10-11 Thread George Dunlap
Move fuzz-emul.c function prototypes into a header.  Also share the
definition of the input size (rather than hard-coding it in
fuzz-emul.c).

Signed-off-by: George Dunlap 
---
RFC: Worth trying to BUILD_BUG_ON(INPUT_SIZE < DATA_SIZE_FULL)?

v4:
- Move earlier in the queue.
- Rebase over previous patch (getting rid of fuzz_corpus struct)
- Add build-time assert
v3:
- New in this version

CC: Ian Jackson 
CC: Wei Liu 
CC: Andrew Cooper 
CC: Jan Beulich 
---
 tools/fuzz/x86_instruction_emulator/afl-harness.c |  6 +-
 tools/fuzz/x86_instruction_emulator/fuzz-emul.c   |  7 +--
 tools/fuzz/x86_instruction_emulator/fuzz-emul.h   | 10 ++
 3 files changed, 16 insertions(+), 7 deletions(-)
 create mode 100644 tools/fuzz/x86_instruction_emulator/fuzz-emul.h

diff --git a/tools/fuzz/x86_instruction_emulator/afl-harness.c 
b/tools/fuzz/x86_instruction_emulator/afl-harness.c
index e0c56aadf7..d514468dd2 100644
--- a/tools/fuzz/x86_instruction_emulator/afl-harness.c
+++ b/tools/fuzz/x86_instruction_emulator/afl-harness.c
@@ -4,12 +4,8 @@
 #include 
 #include 
 #include 
+#include "fuzz-emul.h"
 
-extern int LLVMFuzzerInitialize(int *argc, char ***argv);
-extern int LLVMFuzzerTestOneInput(const uint8_t *data_p, size_t size);
-extern unsigned int fuzz_minimal_input_size(void);
-
-#define INPUT_SIZE  4096
 static uint8_t input[INPUT_SIZE];
 
 int main(int argc, char **argv)
diff --git a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c 
b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
index 8998f21fe1..964682aa1a 100644
--- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
+++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
@@ -16,6 +16,7 @@
 #include 
 
 #include "x86-emulate.h"
+#include "fuzz-emul.h"
 
 #define MSR_INDEX_MAX 16
 
@@ -29,7 +30,7 @@ struct fuzz_corpus
 struct cpu_user_regs regs;
 struct segment_register segments[SEG_NUM];
 unsigned long options;
-unsigned char data[4096];
+unsigned char data[INPUT_SIZE];
 } input;
 #define DATA_OFFSET offsetof(struct fuzz_corpus, data)
 
@@ -827,7 +828,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data_p, size_t 
size)
 return 1;
 }
 
-if ( size > sizeof(input) )
+if ( size > INPUT_SIZE )
 {
 printf("Input too large\n");
 return 1;
@@ -858,6 +859,8 @@ int LLVMFuzzerTestOneInput(const uint8_t *data_p, size_t 
size)
 
 unsigned int fuzz_minimal_input_size(void)
 {
+BUILD_BUG_ON(DATA_OFFSET > INPUT_SIZE);
+
 return DATA_OFFSET + 1;
 }
 
diff --git a/tools/fuzz/x86_instruction_emulator/fuzz-emul.h 
b/tools/fuzz/x86_instruction_emulator/fuzz-emul.h
new file mode 100644
index 00..30dd8de21e
--- /dev/null
+++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.h
@@ -0,0 +1,10 @@
+#ifndef FUZZ_EMUL_H
+# define FUZZ_EMUL_H
+
+extern int LLVMFuzzerInitialize(int *argc, char ***argv);
+extern int LLVMFuzzerTestOneInput(const uint8_t *data_p, size_t size);
+extern unsigned int fuzz_minimal_input_size(void);
+
+#define INPUT_SIZE  4096
+
+#endif /* ifdef FUZZ_EMUL_H */
-- 
2.14.2


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


Re: [Xen-devel] How to prepare the COLO test environment

2017-10-11 Thread Zhang Chen
Hi, Yamamoto.

The Xen COLO wiki has been updated, you can try it.
https://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping

Because the COLO proxy module and the block replication module share with
KVM COLO,
you can read related part from KVM COLO wiki maybe easier to understand
COLO.
Some detail you can get from here.
https://wiki.qemu.org/Features/COLO

Thanks
Zhang Chen


On Mon, Oct 9, 2017 at 9:23 AM, Zhang Chen  wrote:

>
>
> On Thu, Oct 5, 2017 at 5:57 AM, 山本真吾  wrote:
>
>> 2017/09/19 午後10:11 "Zhang Chen" :
>>
>> >
>> > On 09/19/2017 04:32 PM, Dario Faggioli wrote:
>> > > On Mon, 2017-09-18 at 18:52 +, Zhang Chen wrote:
>> > >> 山本真吾 于2017年9月18日周一 下午6:27写道:
>> > >>> I have read the following documents:
>> > >>>
>> > >>> COLO - Coarse Grain Lock Stepping
>> > >>> https://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping
>> > >>>
>> > >>> Mailing list
>> > >>> https://lists.xen.org/archives/html/xen-devel/2016-03/msg00376.html
>> > >>>
>> > >>> If there are some mistakes in English, I'd like apologize.
>> > >>> Thank you.
>> > >>>
>> > >> Unfortunately, wiki and the mail can't be updated. Latest COLO use
>> > >> user space COLO-Proxy in qemu,
>> > >> Wiki just guide you to setup kernel space COLO-Proxy(this version
>> > >> COLO-proxy not being maintained).
>> > >>
>> > > I'm not sure what you mean with "wiki...can't be updated". If you're
>> > > saying that neither you nor anyone that you know have the time or the
>> > > knowledge to update it, then fine.
>> > >
>> > > But, technically, the Wiki can be updated and, if possible, it should
>> > > be.
>> >
>> > Yes, I means we forgot to update COLO wiki.
>> > So, I will rewrite it lately.
>> >
>> > Thanks
>> > Zhang Chen
>> >
>> > >
>> > > Regards,
>> > > Dario
>> >
>> > --
>> > Thanks
>> > Zhang Chen
>>
>> HELLO,
>>
>> Thank for your reply.
>> I'm grateful that there is a way to prerare the test environment.
>>
>> I'd like to test while checking how to construct COLO,  so I'm wating for
>> wating for updates on wiki.
>>
>> Could your tell me when the wiki update to come around?
>>
>
> Sorry, I'm on vacation recently.
> I will update the wiki in this week.
>
> Thanks
> Zhang Chen
>

>
>> Thank you.
>>
>> Yamamoto
>>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH v3 4/5] xentrace: enable per-VCPU extratime flag for RTDS

2017-10-11 Thread Meng Xu
On Wed, Oct 11, 2017 at 6:57 AM, Dario Faggioli  wrote:
> On Tue, 2017-10-10 at 19:17 -0400, Meng Xu wrote:
>> --- a/tools/xentrace/formats
>> +++ b/tools/xentrace/formats
>> @@ -75,7 +75,7 @@
>>  0x00022801  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:tickle[
>> cpu = %(1)d ]
>>  0x00022802  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:runq_pick [
>> dom:vcpu = 0x%(1)08x, cur_deadline = 0x%(3)08x%(2)08x, cur_budget =
>> 0x%(5)08x%(4)08x ]
>>  0x00022803  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:burn_budget   [
>> dom:vcpu = 0x%(1)08x, cur_budget = 0x%(3)08x%(2)08x, delta = %(4)d ]
>> -0x00022804  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:repl_budget   [
>> dom:vcpu = 0x%(1)08x, cur_deadline = 0x%(3)08x%(2)08x, cur_budget =
>> 0x%(5)08x%(4)08x ]
>> +0x00022804  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:repl_budget   [
>> dom:vcpu = 0x%(1)08x, priority_level = 0x%(2)08d cur_deadline =
>> 0x%(4)08x%(3)08x, cur_budget = 0x%(6)08x%(5)08x ]
>>  0x00022805  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:sched_tasklet
>>  0x00022806  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:schedule  [
>> cpu[16]:tasklet[8]:idle[4]:tickled[4] = %(1)08x ]
>>
> But, both in case of this file and below in xenalyze.c, you update 1
> record (the one of REPL_BUDGET). However, in patch 1, you added the
> priority_level field to two records: REPL_BUDGET and BURN_BUDGET.
>
> Or am I missing something?

OMG, my fault. I forgot to check this. I will add this and double
check it by running some tests.

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] [PATCH v3 11/12] fuzz/x86_emulate: Set and fuzz more CPU state

2017-10-11 Thread George Dunlap
On 10/11/2017 10:31 AM, Jan Beulich wrote:
 On 10.10.17 at 18:20,  wrote:
>> --- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
>> +++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
>> @@ -40,6 +40,8 @@ struct fuzz_state
>>  uint64_t msr[MSR_INDEX_MAX];
>>  struct segment_register segments[SEG_NUM];
>>  struct cpu_user_regs regs;
>> +char fxsave[512] __attribute__((aligned(16)));
>> +
>>  
>>  /* Fuzzer's input data. */
> 
> No double blank lines please.



> 
>> @@ -596,6 +598,54 @@ 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 {
>> +uint32_t other[6];
>> +uint32_t mxcsr;
>> +uint32_t mxcsr_mask;
>> +/* ... */
>> +};
>> +} *fxs;
>> +
>> +fxs = (typeof(fxs)) fxsave;
> 
> Stray blank after the cast.
> 
>> +if ( write )
>> +{
>> +char null[512] __attribute__((aligned(16))) = { };
>> +
>> +fxs->mxcsr &= mxcsr_mask;
>> +
>> +asm volatile( "fxrstor %0" :: "m" (*null) );
>> +asm volatile( "fxrstor %0" :: "m" (*fxs) );
> 
> Without a comment I still don't really understand what good this
> double load is intended to do. In particular I don't think there are
> any state components that the first may alter but the second
> won't. Quite the opposite, on AMD I think you may end up not
> altering FIP/FDP/FOP despite this double load (iirc they're being
> loaded only when an exception is indicated to be pending in the
> status word; see fpu_fxrstor() in the hypervisor).

As I said, somewhere online I think I read that doing an fxrstor with a
certain part of the state as all zeros would "reset" the fpu.  But I
don't see that in the manual, so it's probably wrong (or at least not
architectural); in which case I should just remove the first fxrstor.

But you haven't given me clear direction about what I should do instead.
 Should I attempt to copy the functionality of fpu_fxrstor() somehow?

>> @@ -737,6 +791,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 < 128 )
> 
> sizeof(s->fxsave) / 4

Ack.

 -George

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


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

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

Failures :-/ but no regressions.

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-libvirt 14 saverestore-support-checkfail  like 114175
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114175
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114175
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114175
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114175
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114175
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 114175
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 114175
 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-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-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-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:
 linux7056964a85031f42e2360617b14272593729ce1b
baseline version:
 linux8a5776a5f49812d29fe4b2d0a2d71675c3facf3f

Last test of basis   114175  2017-10-09 04:18:47 Z2 days
Failing since114218  2017-10-09 23:00:07 Z1 days2 attempts
Testing same since   114297  2017-10-10 20:24:19 Z0 days1 attempts


People who touched revisions under test:
  Aleksander Morgado 
  Alexander Duyck 
  Alexei Starovoitov 
  Alexei Starovoitov 
  Alexey Kodanev 
  Andrew Bowers 
  Artem Savkov 
  Arvind Yadav 
  Axel Beckert 
  Benjamin Coddington 
  Breno Leitao 
  Chao Yu 
  Colin Ian King 
  Cyril Bur 
  Dan Carpenter 
  Daniel Borkmann 

[Xen-devel] [PATCH v5] x86/altp2m: Added xc_altp2m_set_mem_access_multi()

2017-10-11 Thread Petre Pircalabu
From: Razvan Cojocaru 

For the default EPT view we have xc_set_mem_access_multi(), which
is able to set an array of pages to an array of access rights with
a single hypercall. However, this functionality was lacking for the
altp2m subsystem, which could only set page restrictions for one
page at a time. This patch addresses the gap.

HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart (and
hence with the original altp2m design, where domains are allowed - with the
proper altp2m access rights - to alter these settings), in the absence of an
official position on the issue from the original altp2m designers.

Signed-off-by: Razvan Cojocaru 
Signed-off-by: Petre Pircalabu 

---

Changed since v2:
* Added support for compat arguments translation

Changed since v3:
* Replaced  __copy_to_guest with __copy_field_to_guest
* Removed the un-needed parentheses.
* Fixed xlat.lst ordering
* Added comment to patch description explaining why the
functionality was added as an HVMOP.
* Guard using XEN_GENERATING_COMPAT_HEADERS the hvmmem_type_t definition.
This will prevent suplicate definitions to be generated for the
compat equivalent.
* Added comment describing the manual translation of
xen_hvm_altp2m_op_t generic fields from compat_hvm_altp2m_op_t.

Changed since v4:
* Changed the mask parameter to 0x3Fa.
* Split long lines.
* Added "improperly named HVMMEM_(*)" to the comment explaining the
XEN_GENERATING_COMPAT_HEADERS guard.
* Removed typedef and XEN_GUEST_HANDLE for 
xen_hvm_altp2m_set_mem_access_multi.
* Copied the "opaque" field to guest in compat_altp2m_op.
* Added build time test to check if the size of
xen_hvm_altp2m_set_mem_access_multi at least equal to the size of
compat_hvm_altp2m_set_mem_access_multi.
---
 tools/libxc/include/xenctrl.h   |   3 ++
 tools/libxc/xc_altp2m.c |  41 
 xen/arch/x86/hvm/hvm.c  | 105 +++-
 xen/include/Makefile|   1 +
 xen/include/public/hvm/hvm_op.h |  36 --
 xen/include/xlat.lst|   1 +
 6 files changed, 181 insertions(+), 6 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 3bcab3c..4e2ce64 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1971,6 +1971,9 @@ int xc_altp2m_switch_to_view(xc_interface *handle, 
domid_t domid,
 int xc_altp2m_set_mem_access(xc_interface *handle, domid_t domid,
  uint16_t view_id, xen_pfn_t gfn,
  xenmem_access_t access);
+int xc_altp2m_set_mem_access_multi(xc_interface *handle, domid_t domid,
+   uint16_t view_id, uint8_t *access,
+   uint64_t *pages, uint32_t nr);
 int xc_altp2m_change_gfn(xc_interface *handle, domid_t domid,
  uint16_t view_id, xen_pfn_t old_gfn,
  xen_pfn_t new_gfn);
diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
index 0639632..f202ca1 100644
--- a/tools/libxc/xc_altp2m.c
+++ b/tools/libxc/xc_altp2m.c
@@ -188,6 +188,47 @@ int xc_altp2m_set_mem_access(xc_interface *handle, domid_t 
domid,
 return rc;
 }
 
+int xc_altp2m_set_mem_access_multi(xc_interface *xch, domid_t domid,
+   uint16_t view_id, uint8_t *access,
+   uint64_t *pages, uint32_t nr)
+{
+int rc;
+
+DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
+DECLARE_HYPERCALL_BOUNCE(access, nr, XC_HYPERCALL_BUFFER_BOUNCE_IN);
+DECLARE_HYPERCALL_BOUNCE(pages, nr * sizeof(uint64_t),
+ XC_HYPERCALL_BUFFER_BOUNCE_IN);
+
+arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
+if ( arg == NULL )
+return -1;
+
+arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
+arg->cmd = HVMOP_altp2m_set_mem_access_multi;
+arg->domain = domid;
+arg->u.set_mem_access_multi.view = view_id;
+arg->u.set_mem_access_multi.nr = nr;
+
+if ( xc_hypercall_bounce_pre(xch, pages) ||
+ xc_hypercall_bounce_pre(xch, access) )
+{
+PERROR("Could not bounce memory for 
HVMOP_altp2m_set_mem_access_multi");
+return -1;
+}
+
+set_xen_guest_handle(arg->u.set_mem_access_multi.pfn_list, pages);
+set_xen_guest_handle(arg->u.set_mem_access_multi.access_list, access);
+
+rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
+ HYPERCALL_BUFFER_AS_ARG(arg));
+
+xc_hypercall_buffer_free(xch, arg);
+xc_hypercall_bounce_post(xch, access);
+xc_hypercall_bounce_post(xch, pages);
+
+return rc;
+}
+
 int xc_altp2m_change_gfn(xc_interface *handle, domid_t domid,
  

Re: [Xen-devel] [PATCH for-4.10] xen: Fix XEN_DMOP_remote_shutdown return value

2017-10-11 Thread Andrew Cooper
On 11/10/17 16:41, Ross Lagerwall wrote:
> Return 0 to indicate success rather than whatever rc was previously set
> to (-EINVAL).
>
> Signed-off-by: Ross Lagerwall 
> ---
>  xen/arch/x86/hvm/dm.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
> index 82addea..32ade95 100644
> --- a/xen/arch/x86/hvm/dm.c
> +++ b/xen/arch/x86/hvm/dm.c
> @@ -636,6 +636,7 @@ static int dm_op(const struct dmop_args *op_args)
>  _shutdown;
>  
>  domain_shutdown(d, data->reason);
> +rc = 0;

Ideally with a newline here (can be fixed on commit).

Reviewed-by: Andrew Cooper 

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


Re: [Xen-devel] [PATCH for-4.10] common/gnttab: Improve logging message by including relevent domid

2017-10-11 Thread Julien Grall

Hi,

On 10/10/17 21:24, Andrew Cooper wrote:

Several logging messages cite "bad ref %#x", without identifying which domain
the ref belongs to.  Add a domain back-pointer to struct grant_table to
improve the debugability.

While editing the messages, clean up some others:

  * Remove extranious punctuation
  * Use d%d rather than Dom%d
  * Remove "gnttab_transfer:" prefixes, as it is included by the gdprintk()
  * Reflow several messages to not be split across multiple lines

Signed-off-by: Andrew Cooper 


Release-acked-by: Julien Grall 

Cheers,


---
CC: George Dunlap 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 
CC: Julien Grall 
---
  xen/common/grant_table.c | 91 +---
  1 file changed, 48 insertions(+), 43 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 6d20b17..3a7a7e4 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -76,6 +76,9 @@ struct grant_table {
  /* Mapping tracking table per vcpu. */
  struct grant_mapping **maptrack;
  
+/* Domain to which this struct grant_table belongs. */

+struct domain *domain;
+
  struct grant_table_arch arch;
  };
  
@@ -651,7 +654,7 @@ static int _set_status_v1(domid_t  domid,

 GTF_permit_access) ||
(scombo.shorts.domid != domid)) )
  PIN_FAIL(done, GNTST_general_error,
- "Bad flags (%x) or dom (%d). (expected dom %d)\n",
+ "Bad flags (%x) or dom (%d); expected d%d\n",
   scombo.shorts.flags, scombo.shorts.domid,
   domid);
  
@@ -663,7 +666,7 @@ static int _set_status_v1(domid_t  domid,

  new_scombo.shorts.flags |= GTF_writing;
  if ( unlikely(scombo.shorts.flags & GTF_readonly) )
  PIN_FAIL(done, GNTST_general_error,
- "Attempt to write-pin a r/o grant entry.\n");
+ "Attempt to write-pin a r/o grant entry\n");
  }
  
  prev_scombo.word = cmpxchg((u32 *)shah,

@@ -673,7 +676,7 @@ static int _set_status_v1(domid_t  domid,
  
  if ( retries++ == 4 )

  PIN_FAIL(done, GNTST_general_error,
- "Shared grant entry is unstable.\n");
+ "Shared grant entry is unstable\n");
  
  scombo = prev_scombo;

  }
@@ -715,7 +718,7 @@ static int _set_status_v2(domid_t  domid,
  ((flags & mask) != GTF_transitive)) ||
(id != domid)) )
  PIN_FAIL(done, GNTST_general_error,
- "Bad flags (%x) or dom (%d). (expected dom %d, flags %x)\n",
+ "Bad flags (%x) or dom (%d); expected d%d, flags %x\n",
   flags, id, domid, mask);
  
  if ( readonly )

@@ -726,7 +729,7 @@ static int _set_status_v2(domid_t  domid,
  {
  if ( unlikely(flags & GTF_readonly) )
  PIN_FAIL(done, GNTST_general_error,
- "Attempt to write-pin a r/o grant entry.\n");
+ "Attempt to write-pin a r/o grant entry\n");
  *status |= GTF_reading | GTF_writing;
  }
  
@@ -749,8 +752,7 @@ static int _set_status_v2(domid_t  domid,

  gnttab_clear_flag(_GTF_writing, status);
  gnttab_clear_flag(_GTF_reading, status);
  PIN_FAIL(done, GNTST_general_error,
- "Unstable flags (%x) or dom (%d). (expected dom %d) "
- "(r/w: %d)\n",
+ "Unstable flags (%x) or dom (%d); expected d%d (r/w: 
%d)\n",
   flags, id, domid, !readonly);
  }
  }
@@ -896,7 +898,7 @@ map_grant_ref(
  
  if ( unlikely((op->flags & (GNTMAP_device_map|GNTMAP_host_map)) == 0) )

  {
-gdprintk(XENLOG_INFO, "Bad flags in grant map op (%x).\n", op->flags);
+gdprintk(XENLOG_INFO, "Bad flags in grant map op: %x\n", op->flags);
  op->status = GNTST_bad_gntref;
  return;
  }
@@ -905,7 +907,7 @@ map_grant_ref(
(op->flags & (GNTMAP_device_map|GNTMAP_application_map|
  GNTMAP_contains_pte))) )
  {
-gdprintk(XENLOG_INFO, "No device mapping in HVM domain.\n");
+gdprintk(XENLOG_INFO, "No device mapping in HVM domain\n");
  op->status = GNTST_general_error;
  return;
  }
@@ -930,7 +932,7 @@ map_grant_ref(
  if ( unlikely(handle == INVALID_MAPTRACK_HANDLE) )
  {
  rcu_unlock_domain(rd);
-gdprintk(XENLOG_INFO, "Failed to obtain maptrack handle.\n");
+gdprintk(XENLOG_INFO, "Failed to obtain maptrack handle\n");
  op->status = GNTST_no_device_space;
  return;
 

Re: [Xen-devel] xl mem-set for domain 0 regression

2017-10-11 Thread Wei Liu
On Tue, Oct 10, 2017 at 04:03:32PM +0100, James Dingwall wrote:
> Hi,
> 
> We are migrating from xen 4.4 to xen 4.8.  At the moment we boot our system
> with a xen command line that includes "dom0_mem=8192m,min:1728m,max:8192m".
> We have autoballoon of dom0 disabled in xl.conf and instead call xl mem-set
> 0  to change the dom0 memory allocation.  (We shrink before
> starting guest domains and then increase it when all are stopped.)
> 
> In xen 4.8.2 the xl mem-set command fails with this error:
> 
> # xl mem-set 0 3990
> libxl: error: libxl.c:4196:libxl_set_memory_target: unable to retrieve
> domain configuration: No such file or directory
> cannot set domid 0 dynamic max memory to : 3990
> 
> I think it was the following commit that made it necessary to access the
> configuration file but perhaps for the case domid == 0 this should be
> skipped?  If it is that simple I could try a patch which includes that test.

There should be a stub configuration file generated for Dom0.

Check if there is /var/lib/xen/userdata-d.0.-*000.libxl-json ?

If not, check if xen-init-dom0 service is run?

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


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

2017-10-11 Thread George Dunlap
On 10/10/2017 07:44 PM, Andrew Cooper wrote:
> On 10/10/17 17:20, George Dunlap wrote:
>> @@ -659,7 +667,10 @@ static void setup_state(struct x86_emulate_ctxt *ctxt)
>>  {
>>  /* Fuzz all of the state in one go */
>>  if ( !input_read(s, s, DATA_SIZE_FULL) )
>> +{
>> +printf("Input size too small\n");
>>  exit(-1);
>> +}
> 
> Is this hunk intended to be in the previous patch?

Looking more into it, I suppose it shouldn't be needed at all, since we
check the input size in the main fuzzing function.

> 
>> @@ -886,21 +896,144 @@ 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;
>>  
>> -/* Reset all global state variables */
>> -memset(, 0, sizeof(input));
>> +struct x86_emulate_ctxt *ctxt = >ctxt;
>> +
>> +state->ops = all_fuzzer_ops;
>> +
>> +ctxt->data = state;
>> +ctxt->regs = >regs;
>> +
>> +setup_state(ctxt);
>> +
>> +sanitize_state(ctxt);
>> +
>> +disable_hooks(state);
>> +
>> +do {
>> +/* FIXME: Until we actually implement SIGFPE handling properly */
>> +setup_fpu_exception_handler();
>> +
>> +set_sizes(ctxt);
>> +dump_state(ctxt);
>> +
>> +rc = x86_emulate(ctxt, >ops);
>> +printf("Emulation result: %d\n", rc);
>> +} while ( rc == X86EMUL_OKAY );
>> +
>> +return 0;
>> +}
>> +
>> +static void compare_states(struct fuzz_state state[2])
>> +{
>> +// First zero any "internal" pointers
> 
> /* */

Ack

> 
>> +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 
> Various spaces.

Ack

> 
>> +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> +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> +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 PINE(elem)\
> 
> PRINT_NE() ?

OK.

> 
>> +if ( state[0].elem != state[1].elem ) \
>> +printf(#elem " differ: %lx != %lx\n", \
>> +   (unsigned long)state[0].elem, \
>> +   (unsigned long)state[1].elem)
>> +PINE(regs.r15);
> 
> Hmm - this is going to cause problems for the 32bit build.  I can't
> think of an easy suggestion to fix it.
> 
>> +PINE(regs.r14);
>> +PINE(regs.r13);
>> +PINE(regs.r12);
>> +PINE(regs.rbp);
>> +PINE(regs.rbx);
>> +PINE(regs.r10);
>> +PINE(regs.r11);
>> +PINE(regs.r9);
>> +PINE(regs.r8);
>> +PINE(regs.rax);
>> +  

Re: [Xen-devel] [PATCH for-4.10] xen: Fix XEN_DMOP_remote_shutdown return value

2017-10-11 Thread Ian Jackson
Andrew Cooper writes ("Re: [PATCH for-4.10] xen: Fix XEN_DMOP_remote_shutdown 
return value"):
> On 11/10/17 16:41, Ross Lagerwall wrote:
> > Return 0 to indicate success rather than whatever rc was previously set
> > to (-EINVAL).
> >
> > Signed-off-by: Ross Lagerwall 
> > ---
> >  xen/arch/x86/hvm/dm.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
> > index 82addea..32ade95 100644
> > --- a/xen/arch/x86/hvm/dm.c
> > +++ b/xen/arch/x86/hvm/dm.c
> > @@ -636,6 +636,7 @@ static int dm_op(const struct dmop_args *op_args)
> >  _shutdown;
> >  
> >  domain_shutdown(d, data->reason);
> > +rc = 0;
> 
> Ideally with a newline here (can be fixed on commit).

Thanks to Ross for spotting this, and to whoever committed it so
speedily.

Ian.

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


Re: [Xen-devel] [PATCH for-4.10] xen: Fix XEN_DMOP_remote_shutdown return value

2017-10-11 Thread Wei Liu
On Wed, Oct 11, 2017 at 04:41:57PM +0100, Ross Lagerwall wrote:
> Return 0 to indicate success rather than whatever rc was previously set
> to (-EINVAL).
> 
> Signed-off-by: Ross Lagerwall 

Reviewed-by: Wei Liu 

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


Re: [Xen-devel] [PATCH for-4.10] xen: Fix XEN_DMOP_remote_shutdown return value

2017-10-11 Thread Jan Beulich
>>> On 11.10.17 at 17:41,  wrote:
> Return 0 to indicate success rather than whatever rc was previously set
> to (-EINVAL).
> 
> Signed-off-by: Ross Lagerwall 

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 v4] xenfb: Add [feature|request]-raw-pointer

2017-10-11 Thread Anthony PERARD
On Tue, Oct 10, 2017 at 04:52:48PM -0700, Stefano Stabellini wrote:
> On Mon, 2 Oct 2017, Anthony PERARD wrote:
> > On Tue, Sep 26, 2017 at 02:43:39PM +, Owen Smith wrote:
> > > Writes "feature-raw-pointer" during init to indicate the backend
> > > can pass raw unscaled values for absolute axes to the frontend.
> > > Frontends set "request-raw-pointer" to indicate the backend should
> > > not attempt to scale absolute values to console size.
> > > "request-raw-pointer" is only valid if "request-abs-pointer" is
> > > also set. Raw unscaled pointer values are in the range [0, 0x7fff]
> > > 
> > > Signed-off-by: Owen Smith 
> > 
> > Hi Owen,
> > 
> > Why did you remove the following from the commit description?
> > > "feature-raw-pointer" and "request-raw-pointer" added to Xen
> > > header in commit 7868654ff7fe5e4a2eeae2b277644fa884a5031e
> > 
> > I think that with it, you could have kept stefano's reviewed-by tag.
> 
> Hi Anthony,
> 
> Have you tested this series with a few of different guests? Do you
> consider it safe to merge? If so, we can send it upstream (either via
> xen or via ui as Gerd kindly offered). 

Yes, I think it's fine.

The only observation I have is that on a Linux guest, when I have
usbdevice=tablet, with this series the pv mouse seems to become the
primary way of gueting mouse events (without, the tablet is primary).
So, on my VNC client instead of having both mouse in the guest and on my
desktop being at the same place, there is like a zoom of the mouse (the
zoom centered on the top-left corner). (That's better than relative
mouse event that we can get with the emulation.)

-- 
Anthony PERARD

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


[Xen-devel] [PATCH for-4.10] xen: Fix XEN_DMOP_remote_shutdown return value

2017-10-11 Thread Ross Lagerwall
Return 0 to indicate success rather than whatever rc was previously set
to (-EINVAL).

Signed-off-by: Ross Lagerwall 
---
 xen/arch/x86/hvm/dm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index 82addea..32ade95 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -636,6 +636,7 @@ static int dm_op(const struct dmop_args *op_args)
 _shutdown;
 
 domain_shutdown(d, data->reason);
+rc = 0;
 break;
 }
 
-- 
2.9.5


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


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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 114299
 test-armhf-armhf-xl   7 xen-boot fail REGR. vs. 114299

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

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

Last test of basis   114299  2017-10-10 21:02:54 Z0 days
Failing since114308  2017-10-10 23:01:10 Z0 days6 attempts
Testing same since   114354  2017-10-11 14:01:13 Z0 days1 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Andre Przywara 
  Andrew Cooper 
  Boris Ostrovsky 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Meng Xu 
  Stefano Stabellini 
  Wei Liu 
  Yi Sun 

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



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

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

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

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


Not pushing.

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

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


Re: [Xen-devel] [PATCH v10 04/11] public: xen.h: add definitions for UUID handling

2017-10-11 Thread Konrad Rzeszutek Wilk
On Wed, Oct 11, 2017 at 02:57:59PM +0300, Volodymyr Babchuk wrote:
> Added type xen_uuid_t. This type represents UUID as an array of 16
> bytes in big endian format.
> 
> Added macro XEN_DEFINE_UUID that constructs UUID in the usual way:
> 
>  XEN_DEFINE_UUID(0x00112233, 0x4455, 0x6677, 0x8899,
>   0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff)
> 
> will construct UUID 00112233-4455-6677-8899-aabbccddeeff presented as
>  {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88,
>   0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff}
> 
> NB: We define a new structure here rather than re-using EFI_GUID.
> EFI_GUID uses a Microsoft-style encoding which, among other things,
> mixes little-endian and big-endian. The structure defined in this
> patch, unlike EFI_GUID, is compatible with the Linux kernel and libuuid.
> 
> Signed-off-by: Volodymyr Babchuk 

Acked-by: Konrad Rzeszutek Wilk 

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


Re: [Xen-devel] [PATCH v9 3/3] tools/libxc: use superpages during restore of HVM guest

2017-10-11 Thread Olaf Hering
On Wed, Oct 11, Olaf Hering wrote:

> -#define MAX_BATCH_SIZE 1024   /* up to 1024 pages (4MB) at a time */
> +#define MAX_BATCH_SIZE SUPERPAGE_1GB_NR_PFNS   /* up to 1GB at a time */

Actually the error is something else, I missed this in the debug output:

xc: error: Failed to get types for pfn batch (7 = Argument list too long): 
Internal error

write_batch() should probably split the requests when filling types[] because
Xen has "1024" hardcoded in XEN_DOMCTL_getpageframeinfo3...


Olaf


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


Re: [Xen-devel] [PATCHv2 for-4.10] xen/arm: guest_walk: Fix check again the IPS

2017-10-11 Thread Julien Grall



On 11/10/17 15:51, Sergej Proskurin wrote:

Hi Julien,


Hi,


On 10/11/2017 04:29 PM, Julien Grall wrote:

The function get_ipa_output_size is check whether the input size
configured by the guest is valid and will return it.

The check is done with the IPS already shifted against
TCR_EL1_IPS_48_BIT. However the constant has been defined with the
shift included, resulting the check always been false.

Fix it by doing the check on the non-shifted value.

This was introduced by commit 7d623b358a "arm/mem_access: Add long-descriptor
based gpt" introduced software page-table walk for stage-1.

Note that the IPS code is now surrounded with #ifdef CONFIG_ARM_64
because the Arm32 compiler will complain of shift bigger than the width
of the variable. This is fine as the code is executed for 64-bit domain only.


This is a bit controversial as compared to your review comments to the
initial implementation. You did not want to see any #define
CONFIG_ARM_64 within the code. TCR_EL1 is a 64-bit Register: to prevent
compilation issues for Aarch32 systems, why don't you use uint64_t for
ips instead of register_t?


I am fully aware what I said in the previous reviews and I still took 
this decision because you will mix uint64_t and register_t. #ifdef 
CONFIG_ARM_64 is much nicer than mixing types.


Another way to fix it would be to rework completely the way you did 
introduce TCR_EL1_IPS_*_BIT so you stick with non-shifted value rather 
than shifted one.


But I don't have time for that and I don't want to see a latent security 
bug in the release.


Cheers,


Thanks,
~Sergej



Coverity-ID: 1457707
Signed-off-by: Julien Grall 

---

Cc: Sergej Proskurin 

 Changes in v2:
 - Fix compilation on Arm32
---
  xen/arch/arm/guest_walk.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
index c38bedcf65..4d1ea0cdc1 100644
--- a/xen/arch/arm/guest_walk.c
+++ b/xen/arch/arm/guest_walk.c
@@ -185,7 +185,8 @@ static int guest_walk_sd(const struct vcpu *v,
  static int get_ipa_output_size(struct domain *d, register_t tcr,
 unsigned int *output_size)
  {
-unsigned int ips;
+#ifdef CONFIG_ARM_64
+register_t ips;
  
  static const unsigned int ipa_sizes[7] = {

  TCR_EL1_IPS_32_BIT_VAL,
@@ -200,7 +201,7 @@ static int get_ipa_output_size(struct domain *d, register_t 
tcr,
  if ( is_64bit_domain(d) )
  {
  /* Get the intermediate physical address size. */
-ips = (tcr & TCR_EL1_IPS_MASK) >> TCR_EL1_IPS_SHIFT;
+ips = tcr & TCR_EL1_IPS_MASK;
  
  /*

   * Return an error on reserved IPA output-sizes and if the IPA
@@ -211,9 +212,10 @@ static int get_ipa_output_size(struct domain *d, 
register_t tcr,
  if ( ips > TCR_EL1_IPS_48_BIT )
  return -EFAULT;
  
-*output_size = ipa_sizes[ips];

+*output_size = ipa_sizes[ips >> TCR_EL1_IPS_SHIFT];
  }
  else
+#endif
  *output_size = TCR_EL1_IPS_40_BIT_VAL;
  
  return 0;




--
Julien Grall

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


Re: [Xen-devel] [PATCHv2 for-4.10] xen/arm: guest_walk: Fix check again the IPS

2017-10-11 Thread Sergej Proskurin
Hi Julien,


On 10/11/2017 04:29 PM, Julien Grall wrote:
> The function get_ipa_output_size is check whether the input size
> configured by the guest is valid and will return it.
>
> The check is done with the IPS already shifted against
> TCR_EL1_IPS_48_BIT. However the constant has been defined with the
> shift included, resulting the check always been false.
>
> Fix it by doing the check on the non-shifted value.
>
> This was introduced by commit 7d623b358a "arm/mem_access: Add long-descriptor
> based gpt" introduced software page-table walk for stage-1.
>
> Note that the IPS code is now surrounded with #ifdef CONFIG_ARM_64
> because the Arm32 compiler will complain of shift bigger than the width
> of the variable. This is fine as the code is executed for 64-bit domain only.

This is a bit controversial as compared to your review comments to the
initial implementation. You did not want to see any #define
CONFIG_ARM_64 within the code. TCR_EL1 is a 64-bit Register: to prevent
compilation issues for Aarch32 systems, why don't you use uint64_t for
ips instead of register_t?

Thanks,
~Sergej

>
> Coverity-ID: 1457707
> Signed-off-by: Julien Grall 
>
> ---
>
> Cc: Sergej Proskurin 
>
> Changes in v2:
> - Fix compilation on Arm32
> ---
>  xen/arch/arm/guest_walk.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
> index c38bedcf65..4d1ea0cdc1 100644
> --- a/xen/arch/arm/guest_walk.c
> +++ b/xen/arch/arm/guest_walk.c
> @@ -185,7 +185,8 @@ static int guest_walk_sd(const struct vcpu *v,
>  static int get_ipa_output_size(struct domain *d, register_t tcr,
> unsigned int *output_size)
>  {
> -unsigned int ips;
> +#ifdef CONFIG_ARM_64
> +register_t ips;
>  
>  static const unsigned int ipa_sizes[7] = {
>  TCR_EL1_IPS_32_BIT_VAL,
> @@ -200,7 +201,7 @@ static int get_ipa_output_size(struct domain *d, 
> register_t tcr,
>  if ( is_64bit_domain(d) )
>  {
>  /* Get the intermediate physical address size. */
> -ips = (tcr & TCR_EL1_IPS_MASK) >> TCR_EL1_IPS_SHIFT;
> +ips = tcr & TCR_EL1_IPS_MASK;
>  
>  /*
>   * Return an error on reserved IPA output-sizes and if the IPA
> @@ -211,9 +212,10 @@ static int get_ipa_output_size(struct domain *d, 
> register_t tcr,
>  if ( ips > TCR_EL1_IPS_48_BIT )
>  return -EFAULT;
>  
> -*output_size = ipa_sizes[ips];
> +*output_size = ipa_sizes[ips >> TCR_EL1_IPS_SHIFT];
>  }
>  else
> +#endif
>  *output_size = TCR_EL1_IPS_40_BIT_VAL;
>  
>  return 0;

-- 
Sergej Proskurin, M.Sc.
Wissenschaftlicher Mitarbeiter

Technische Universität München
Fakultät für Informatik
Lehrstuhl für Sicherheit in der Informatik

Boltzmannstraße 3
85748 Garching (bei München)

Tel. +49 (0)89 289-18592
Fax +49 (0)89 289-18579



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


Re: [Xen-devel] [PATCH for-4.10] common/gnttab: Improve logging message by including relevent domid

2017-10-11 Thread Andrew Cooper
On 11/10/17 11:03, Jan Beulich wrote:
 On 10.10.17 at 22:24,  wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -76,6 +76,9 @@ struct grant_table {
>>  /* Mapping tracking table per vcpu. */
>>  struct grant_mapping **maptrack;
>>  
>> +/* Domain to which this struct grant_table belongs. */
>> +struct domain *domain;
> As you're after only the domain ID, why not just domid_t? Or
> otherwise at least const-qualify the pointer?

Lets go with const qualified pointer.  (This isn't the first time I've
had to add a backpointer like this for debugging purposes.)

>
>> @@ -2027,7 +2034,7 @@ gnttab_transfer(
>>  /* Read from caller address space. */
>>  if ( unlikely(__copy_from_guest(, uop, 1)) )
>>  {
>> -gdprintk(XENLOG_INFO, "gnttab_transfer: error reading req 
>> %d/%d\n",
>> +gdprintk(XENLOG_INFO, "error reading req %d/%d\n",
>>  i, count);
> "i" (wrongly) is plain int, so %d is fine, but "count" wants %u.
>
>> @@ -2076,8 +2081,7 @@ gnttab_transfer(
>>  /* Find the target domain. */
>>  if ( unlikely((e = rcu_lock_domain_by_id(gop.domid)) == NULL) )
>>  {
>> -gdprintk(XENLOG_INFO, "gnttab_transfer: can't find domain %d\n",
>> -gop.domid);
>> +gdprintk(XENLOG_INFO, "can't find domain %d\n", gop.domid);
> d%d here too?
>
> If you decide to take care of all of the above, then
> Acked-by: Jan Beulich 

Will do, thanks.

~Andrew

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


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

2017-10-11 Thread George Dunlap
On 10/11/2017 12:30 PM, George Dunlap wrote:
> On 10/10/2017 07:20 PM, Andrew Cooper wrote:
>> On 10/10/17 17:20, George Dunlap wrote:
>>> This is in preparation for adding the option for a more "compact"
>>> interpretation of the fuzzing data, in which we only change select
>>> bits of the state.
>>>
>>> Signed-off-by: George Dunlap 
>>> Acked-by: Jan Beulich 
>>> ---
>>> v3:
>>>  - Move DATA_OFFSET inside the structure
>>>  - Remove a stray blank line
>>> v2: Port over previous changes
>>>
>>> CC: Ian Jackson 
>>> CC: Wei Liu 
>>> CC: Andrew Cooper 
>>> CC: Jan Beulich 
>>> ---
>>>  tools/fuzz/x86_instruction_emulator/fuzz-emul.c | 89 
>>> +
>>>  1 file changed, 45 insertions(+), 44 deletions(-)
>>>
>>> diff --git a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c 
>>> b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
>>> index 8998f21fe1..20d52b33f8 100644
>>> --- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
>>> +++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
>>> @@ -24,14 +24,8 @@
>>>  /* Layout of data expected as fuzzing input. */
>>>  struct fuzz_corpus
>>>  {
>>> -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[4096];
>>>  } input;
>>> -#define DATA_OFFSET offsetof(struct fuzz_corpus, data)
>>>  
>>>  /*
>>>   * Internal state of the fuzzing harness.  Calculated initially from the 
>>> input
>>> @@ -39,7 +33,14 @@ struct fuzz_corpus
>>>   */
>>
>> You've invalidated a number of the comments describing behaviours,
>> including the description of the difference between fuzz_state and
>> fuzz_corpus.
> 
> Well completely apart from the 'compact' format, I think this move makes
> sense.  The state moved is actually the state of the "emulated cpu" --
> the emulator actually modifies this state as instructions are executed.
> I think it makes sense to keep the "current state of the virtual
> processor" separate from "input we get from a file".

It's also necessary for when we add the `--rerun` parameter: We have to
make sure we leave the input data alone, and have two parallel states
that we set up and can compare.

 -George

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


Re: [Xen-devel] [PATCH for-4.9 v2] x86: avoid #GP for PV guest MSR accesses

2017-10-11 Thread Andrew Cooper
On 09/10/17 11:07, Jan Beulich wrote:
 On 09.10.17 at 11:49,  wrote:
>> On 09/10/17 08:48, Jan Beulich wrote:
>>> Halfway recent Linux kernels probe MISC_FEATURES_ENABLES on all CPUs,
>>> leading to ugly recovered #GP fault messages with debug builds on older
>>> systems. We can do better, so introduce synthetic feature flags for
>>> both this and PLATFORM_INFO to avoid the rdmsr_safe() altogether.
>>>
>>> Note that the r/o nature of PLATFORM_INFO is now also being enforced.
>>>
>>> The rdmsr_safe() uses for MISC_ENABLE are left in place as benign - it
>>> exists for all 64-bit capable Intel CPUs (see e.g. early_init_intel()).
>>>
>>> Signed-off-by: Jan Beulich 
>>> ---
>>> v2: Force PLATFORM_INFO writes to fail.
>>>
>>> --- a/xen/arch/x86/cpu/intel.c
>>> +++ b/xen/arch/x86/cpu/intel.c
>>> @@ -21,10 +21,19 @@ static bool __init probe_intel_cpuid_fau
>>>  {
>>> uint64_t x;
>>>  
>>> -   if (rdmsr_safe(MSR_INTEL_PLATFORM_INFO, x) ||
>>> -   !(x & MSR_PLATFORM_INFO_CPUID_FAULTING))
>>> +   if (rdmsr_safe(MSR_INTEL_PLATFORM_INFO, x))
>>> return 0;
>>>  
>>> +   setup_force_cpu_cap(X86_FEATURE_MSR_PLATFORM_INFO);
>>> +
>>> +   if (!(x & MSR_PLATFORM_INFO_CPUID_FAULTING)) {
>>> +   if (!rdmsr_safe(MSR_INTEL_MISC_FEATURES_ENABLES, x))
>>> +   setup_force_cpu_cap(X86_FEATURE_MSR_MISC_FEATURES);
>>> +   return 0;
>>> +   }
>>> +
>>> +   setup_force_cpu_cap(X86_FEATURE_MSR_MISC_FEATURES);
>> Why this odd arrangement with the double setup_force_cpu_cap()?  As
>> neither of these MSRs are architectural, would it not be better to probe
>> both of them, rather than assuming MISC_FEATURES_ENABLES is available if
>> faulting is reported?
> Since faulting being available means it can be enabled, and since
> enabling works by writing MISC_FEATURES_ENABLES, I don't see
> why we need to probe that second register in that case.
> set_cpuid_faulting() makes this very assumption already.

Ok.  Acked-by: Andrew Cooper 

___
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-11 Thread Andre Przywara
Hi,

On 11/10/17 15:33, Andre Przywara wrote:
> Hi,
> 
> (CC:ing some KVM/ARM folks involved in the VGIC)
> 
> 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].

and that link should point to:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/virt/kvm/arm/vgic

Cheers,
Andre.

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


Re: [Xen-devel] [PATCH for-4.10] xen/arm: mm: Rework MAIR* definitions to handle 32-bit compilation environment

2017-10-11 Thread Andre Przywara
Hi,

On 11/10/17 15:15, Julien Grall wrote:
> Commit a0543df403 "xen/arm: page: Clean-up the definition of MAIRVAL"
> combined the definition of MAIR0VAL and MAIR1VAL in MAIRVAL. Sadly, when
> building in 32-bit environment, the assembler is unable to compute
> 64-bit constant and will ignore the 32-bit most-significants bits. This
> will result of MAIR1 set 0.
> 
> Rather than fully reverting the offending commit, the code is reworked
> to still avoid hardcoded values but split the definition in 2.

Nasty issue, but given the circumstances the workaround seems not too
bad for me.

> Lastly, a comment is added to avoid trying to blindly combine the both
> definition again in the future.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
>  xen/include/asm-arm/page.h | 23 ++-
>  1 file changed, 14 insertions(+), 9 deletions(-)
> 
> diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> index f558184e10..d948250a4a 100644
> --- a/xen/include/asm-arm/page.h
> +++ b/xen/include/asm-arm/page.h
> @@ -52,18 +52,23 @@
>   *   ??   101
>   *   reserved 110
>   *   MT_NORMAL111      -- Write-back write-allocate
> + *
> + * /!\ It is not possible to combine the definition in MAIRVAL and then
> + * split because it would result to a 64-bit value that some assembler
> + * doesn't understand.
>   */
> -#define MAIR(attr, mt) (_AC(attr, ULL) << ((mt) * 8))
> +#define _MAIR0(attr, mt) (_AC(attr, ULL) << ((mt) * 8))
> +#define _MAIR1(attr, mt) (_AC(attr, ULL) << (((mt) * 8) - 32))
> +
> +#define MAIR0VAL (_MAIR0(0x00, MT_DEVICE_nGnRnE)| \
> +  _MAIR0(0x44, MT_NORMAL_NC)| \
> +  _MAIR0(0xaa, MT_NORMAL_WT)| \
> +  _MAIR0(0xee, MT_NORMAL_WB))
>  
> -#define MAIRVAL (MAIR(0x00, MT_DEVICE_nGnRnE)| \
> - MAIR(0x44, MT_NORMAL_NC)| \
> - MAIR(0xaa, MT_NORMAL_WT)| \
> - MAIR(0xee, MT_NORMAL_WB)| \
> - MAIR(0x04, MT_DEVICE_nGnRE) | \
> - MAIR(0xff, MT_NORMAL))
> +#define MAIR1VAL (_MAIR1(0x04, MT_DEVICE_nGnRE) | \
> +  _MAIR1(0xff, MT_NORMAL))
>  
> -#define MAIR0VAL (MAIRVAL & 0x)
> -#define MAIR1VAL (MAIRVAL >> 32)
> +#define MAIRVAL (MAIR1VAL << 32 | MAIR0VAL)
>  
>  /*
>   * Layout of the flags used for updating the hypervisor page tables
> 

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


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

2017-10-11 Thread Andre Przywara
Hi,

(CC:ing some KVM/ARM folks involved in the VGIC)

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 emulation approach should thus focus on tracking the virtual
interrupt state efficiently, allowing quick handling of incoming and EOI-ed
interrupts.

The actual interrupt state tracking can be quite tricky in parts. Interrupt
injections can be independent from the guest entry/exit points, also MMIO
configuration accesses could be triggered by any VCPU at any point in 

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

2017-10-11 Thread Julien Grall

Hi,

On 11/10/17 08:30, Roger Pau Monné wrote:

Adding Julien and Stefano.

On Wed, Oct 11, 2017 at 07:17:59AM +, osstest service owner wrote:

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
  test-armhf-armhf-xl   7 xen-boot fail REGR. vs. 114299


Seems like Xen is not able to start on the Exynos or Cubietrucks
anymore:


I have posted a fix few minutes ago (see [1]). It is because on 32 
environment, the assembler does seem to support 64-bit constant and will 
ignore the top 32-bit.


Cheers,

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2017-10/msg01394.html


--
Julien Grall

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


[Xen-devel] [PATCHv2 for-4.10] xen/arm: guest_walk: Fix check again the IPS

2017-10-11 Thread Julien Grall
The function get_ipa_output_size is check whether the input size
configured by the guest is valid and will return it.

The check is done with the IPS already shifted against
TCR_EL1_IPS_48_BIT. However the constant has been defined with the
shift included, resulting the check always been false.

Fix it by doing the check on the non-shifted value.

This was introduced by commit 7d623b358a "arm/mem_access: Add long-descriptor
based gpt" introduced software page-table walk for stage-1.

Note that the IPS code is now surrounded with #ifdef CONFIG_ARM_64
because the Arm32 compiler will complain of shift bigger than the width
of the variable. This is fine as the code is executed for 64-bit domain only.

Coverity-ID: 1457707
Signed-off-by: Julien Grall 

---

Cc: Sergej Proskurin 

Changes in v2:
- Fix compilation on Arm32
---
 xen/arch/arm/guest_walk.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
index c38bedcf65..4d1ea0cdc1 100644
--- a/xen/arch/arm/guest_walk.c
+++ b/xen/arch/arm/guest_walk.c
@@ -185,7 +185,8 @@ static int guest_walk_sd(const struct vcpu *v,
 static int get_ipa_output_size(struct domain *d, register_t tcr,
unsigned int *output_size)
 {
-unsigned int ips;
+#ifdef CONFIG_ARM_64
+register_t ips;
 
 static const unsigned int ipa_sizes[7] = {
 TCR_EL1_IPS_32_BIT_VAL,
@@ -200,7 +201,7 @@ static int get_ipa_output_size(struct domain *d, register_t 
tcr,
 if ( is_64bit_domain(d) )
 {
 /* Get the intermediate physical address size. */
-ips = (tcr & TCR_EL1_IPS_MASK) >> TCR_EL1_IPS_SHIFT;
+ips = tcr & TCR_EL1_IPS_MASK;
 
 /*
  * Return an error on reserved IPA output-sizes and if the IPA
@@ -211,9 +212,10 @@ static int get_ipa_output_size(struct domain *d, 
register_t tcr,
 if ( ips > TCR_EL1_IPS_48_BIT )
 return -EFAULT;
 
-*output_size = ipa_sizes[ips];
+*output_size = ipa_sizes[ips >> TCR_EL1_IPS_SHIFT];
 }
 else
+#endif
 *output_size = TCR_EL1_IPS_40_BIT_VAL;
 
 return 0;
-- 
2.11.0


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


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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumprun8 xen-buildfail REGR. vs. 114204

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 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-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114204
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail 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  3c1ca29bd53570ffce049a297d18956f5d93ec8a
baseline version:
 xen  572a78190403e5f2acbd01fa72c35fafe9700169

Last test of basis   114204  2017-10-09 19:19:08 Z1 days
Testing same since   114288  2017-10-10 17:02:59 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Kevin Tian 
  Tim Deegan 

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

  1   2   >