Re: [Xen-devel] [PATCH v10 08/25] x86: refactor psr: L3 CAT: implement get value flow.

[Yi Sun]

On 17-04-06 08:08:11, Jan Beulich wrote:
> >>> On 06.04.17 at 13:13,  wrote:
> > On 17-04-06 02:40:01, Jan Beulich wrote:
> >> >>> On 06.04.17 at 08:10,  wrote:
> >> > On 17-04-05 09:51:44, Jan Beulich wrote:
> >> >> >>> On 01.04.17 at 15:53,  wrote:
> > 
> > [...]
> >> >> > --- a/xen/arch/x86/psr.c
> >> >> > +++ b/xen/arch/x86/psr.c
> >> >> > @@ -97,6 +97,10 @@ struct feat_node {
> >> >> >  /* get_feat_info is used to get feature HW info. */
> >> >> >  bool (*get_feat_info)(const struct feat_node *feat,
> >> >> >uint32_t data[], unsigned int 
> >> >> > array_len);
> >> >> > +
> >> >> > +/* get_val is used to get feature COS register value. */
> >> >> > +void (*get_val)(const struct feat_node *feat, unsigned int 
> >> >> > cos,
> >> >> > +uint32_t *val);
> >> >> >  } *props;
> >> >> >  
> >> >> >  uint32_t cos_reg_val[MAX_COS_REG_CNT];
> >> >> > @@ -265,10 +269,17 @@ static bool cat_get_feat_info(const struct 
> >> >> > feat_node 
> > *feat,
> >> >> >  return true;
> >> >> >  }
> >> >> >  
> >> >> > +static void cat_get_val(const struct feat_node *feat, unsigned int 
> >> >> > cos,
> >> >> > +uint32_t *val)
> >> >> > +{
> >> >> > +*val = feat->cos_reg_val[cos];
> >> >> > +}
> >> >> 
> >> >> This can be done by the caller - there's nothing feature specific in
> >> >> here, so there's no need for a hook.
> >> >> 
> >> > Hmm, CDP's 'get_val' is different so that we need this hook. Do you mean 
> >> > I
> >> > should create this CAT's 'get_val' hook when implementing CDP patch?
> >> 
> >> No, not really - doesn't the type-to-index mapping array (or
> >> whichever way it ends up being) all take care of the feature
> >> specific aspects here?
> >>
> > For CDP case, the value getting depends on type. If we don't have this hook,
> > we have to do special handling in main flow.
> > 
> > Still use 'fits_cos_max' as example:
> > /* For CDP, DATA is the first item in val[], CODE is the second. */
> > for ( j = 0; j < feat->props->cos_num; j++ )   
> > {  
> > feat->props->get_val(feat, 0, feat->props->type[j],
> >  _val);  
> > if ( val[j] != default_val )  
> > return false;   
> > } 
> > 
> > We want to get CDP DATA and CODE one by one to compare with val[] as the 
> > order.
> > If we do not have 'get_val', how can we handle this case? Getting DATA is
> > different with getting CODE which is shown below. Even we have 
> > type-to-index,
> > we still need the hook to help I think. So far, I cannot figure out a 
> > generic
> > way.
> > Get data: (feat)->cos_reg_val[(cos) * 2]
> > Get code: (feat)->cos_reg_val[(cos) * 2 + 1]
> 
> Which makes it
> 
> for ( i = 0; i < props->cos_num; ++i )
> val[i] = feat->cos_reg_val[cos * props->cos_num + i];
> 
> ?
> 
Great, thanks! Then, I will remove 'get_val' hook.

BRs,
Sun Yi

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

Re: [Xen-devel] [PATCH v10 07/25] x86: refactor psr: L3 CAT: implement get hw info flow.

[Yi Sun]

On 17-04-06 08:04:16, Jan Beulich wrote:
> >>> On 06.04.17 at 13:16,  wrote:
> > On 17-04-06 02:36:19, Jan Beulich wrote:
> >> >>> On 06.04.17 at 08:05,  wrote:
> >> > On 17-04-05 09:37:44, Jan Beulich wrote:
> >> >> >>> On 01.04.17 at 15:53,  wrote:
> >> >> > @@ -183,6 +187,22 @@ static bool feat_init_done(const struct 
> > psr_socket_info *info)
> >> >> >  return false;
> >> >> >  }
> >> >> >  
> >> >> > +static enum psr_feat_type psr_cbm_type_to_feat_type(enum cbm_type 
> >> >> > type)
> >> >> > +{
> >> >> > +enum psr_feat_type feat_type;
> >> >> > +
> >> >> > +switch ( type )
> >> >> > +{
> >> >> > +case PSR_CBM_TYPE_L3:
> >> >> > +feat_type = PSR_SOCKET_L3_CAT;
> >> >> > +break;
> >> >> > +default:
> >> >> > +ASSERT_UNREACHABLE();
> >> >> > +}
> >> >> > +
> >> >> > +return feat_type;
> >> >> 
> >> >> I'm pretty certain this will (validly) produce an uninitialized variable
> >> >> warning at least in a non-debug build. Not how I did say "add
> >> >> ASSERT_UNREACHABLE()" in the v9 review.
> >> >> 
> >> > Do you mean to init feat_type to 'PSR_SOCKET_MAX_FEAT' and then check it
> >> > at the end of function using ASSERT?
> >> 
> >> That's a (less desirable) option, but what I really mean is take v9
> >> code and _add_ ASSERT_UNREACHABLE() first thing in the default
> >> case.
> > 
> > DYM we should initialize 'feat_type' to a valid value, e.g. 
> > PSR_SOCKET_L3_CAT
> > and keep ASSERT_UNREACHABLE() in default case?
> 
> Yi, please. Did you read my previous reply, where I think I did say
> very precisely what I mean? Why would you pick some random
> valid type here?
> 
Sorry, I mis-understood your intention before. In v9 codes, I defined
'PSR_SOCKET_UNKNOWN' which is returned in default case. I thought you
wanted me to remove it.

I will add ASSERT_UNREACHABLE() and keep 'feat_type = PSR_SOCKET_UNKNOWN;'
in default case.

BRs,
Sun Yi

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

Re: [Xen-devel] [PATCH v10 05/25] x86: refactor psr: L3 CAT: implement CPU init and free flow.

[Yi Sun]

On 17-04-06 08:02:15, Jan Beulich wrote:
> >>> On 06.04.17 at 12:02,  wrote:
> > On 17-04-06 03:34:27, Jan Beulich wrote:
> >> >>> On 06.04.17 at 11:22,  wrote:
> >> > On 17-04-06 02:32:04, Jan Beulich wrote:
> >> >> >>> On 06.04.17 at 07:49,  wrote:
> >> >> > On 17-04-05 09:10:58, Jan Beulich wrote:
> >> >> >> >>> On 01.04.17 at 15:53,  wrote:
> >> >> >> > +static void cat_init_feature(const struct cpuid_leaf *regs,
> >> >> >> > + struct feat_node *feat,
> >> >> >> > + struct psr_socket_info *info,
> >> >> >> > + enum psr_feat_type type)
> >> >> >> > +{
> >> >> >> > +unsigned int socket, i;
> >> >> >> > +
> >> >> >> > +/* No valid value so do not enable feature. */
> >> >> >> > +if ( !regs->a || !regs->d )
> >> >> >> > +return;
> >> >> >> > +
> >> >> >> > +feat->props->cbm_len = (regs->a & CAT_CBM_LEN_MASK) + 1;
> >> >> >> > +feat->props->cos_max = min(opt_cos_max, regs->d & 
> >> >> >> > CAT_COS_MAX_MASK);
> >> >> >> > +
> >> >> >> > +switch ( type )
> >> >> >> > +{
> >> >> >> > +case PSR_SOCKET_L3_CAT:
> >> >> >> > +/* cos=0 is reserved as default cbm(all bits within 
> >> >> >> > cbm_len are 1). */
> >> >> >> > +feat->cos_reg_val[0] = 
> >> >> >> > cat_default_val(feat->props->cbm_len);
> >> >> >> > +
> >> >> >> > +/*
> >> >> >> > + * To handle cpu offline and then online case, we need 
> >> >> >> > restore MSRs to
> >> >> >> > + * default values.
> >> >> >> > + */
> >> >> >> > +for ( i = 1; i <= feat->props->cos_max; i++ )
> >> >> >> > +{
> >> >> >> > +wrmsrl(MSR_IA32_PSR_L3_MASK(i), feat->cos_reg_val[0]);
> >> >> >> > +feat->cos_reg_val[i] = feat->cos_reg_val[0];
> >> >> >> > +}
> >> >> >> 
> >> >> >> I continue to have difficulty with this: Why is offline-then-online
> >> >> >> any different from first-time-online? Why wouldn't setting the
> >> >> > 
> >> >> > May remove this comment. Per current codes, the MSRs are written to 
> >> >> > default
> >> >> > values no matter first time or not.
> >> >> > 
> >> >> >> registers to their intended values not be taken care of by
> >> >> >> context switch code, once vCPU-s get scheduled onto the newly
> >> >> >> onlined CPU?
> >> >> >> 
> >> >> > cat_init_feature is only called when the first CPU on a socket is 
> >> >> > online.
> >> >> > The MSRs to set are per socket. So, we only need set it once when 
> >> >> > socket
> >> >> > is online.
> >> >> 
> >> >> This does not answer my question. Once again - why does this need
> >> >> doing here explicitly, rather than relying on the needed values being
> >> >> loaded when the first vCPU gets scheduled onto one of the pCPU-s
> >> >> of this socket?
> >> >> 
> >> > I do not know if I understand your question correctly. Let me try to 
> >> > explain
> >> > again. As we discussed in v9, the MSRs values may be wrong values when 
> >> > socket
> >> > is online. That is the reason we have to restore them. 
> >> > 
> >> > The MSRs are per socket. That means only one group of MSRs on one 
> >> > socket. So
> >> > the setting on one CPU can make it valid on whole socket. The 
> >> > 'cat_init_feature'
> >> > is executed when the first CPU on a socket is online so we restore them 
> >> > here.
> >> 
> >> All understood. But you write the MSRs with the needed values in
> >> the context switch path, don't you? Why is that writing not
> >> sufficient?
> >> 
> > No, in context switch path, we only set ASSOC register to set COS ID into 
> > it so
> > that the corresponding COS MSR value (CBM) can work.
> 
> Okay, so not the context switch path then, But you must be
> changing the MSRs _somewhere_, and the question is why this
> somewhere isn't sufficient.
> 
Besides the restore behavior in init process, I restore the MSRs when ref[cos]
is reduced to 0. This behavior happens in two scenarios:
1. In a value setting process, restore MSR if the ref[old_cos] is reduced to 0.
2. When a domain is destroyed, its ref[cos] is reduced too.

Reason to restore is below:
  For features,  e.g. CDP, which cos_num is more than 1, we have to
  restore the old_cos value back to default when ref[old_cos] is 0.
  Otherwise, user will see wrong values when this COS ID is reused. E.g.
  user wants to set DATA to 0x3ff for a new domain. He hopes to see the
  DATA is set to 0x3ff and CODE should be the default value, 0x7ff. But
  if the COS ID picked for this action is the one that has been used by
  other domain and the CODE has been set to 0x1ff. Then, user will see
  DATA: 0x3ff, CODE: 0x1ff. So, we have to restore COS values for features
  using multiple COSs.

BRs,
Sun Yi

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

[Xen-devel] [qemu-mainline baseline-only test] 71158: trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 71158 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71158/

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  3 host-install(3) broken REGR. vs. 71151
 test-armhf-armhf-libvirt  3 host-install(3) broken REGR. vs. 71151
 test-armhf-armhf-xl   3 host-install(3) broken REGR. vs. 71151
 test-armhf-armhf-xl-midway3 host-install(3) broken REGR. vs. 71151

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  3 host-install(3) broken REGR. vs. 71151
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   like 71151
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 71151
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 71151

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 qemuu1fde6ee885d3e778acb326cab9f7037939839537
baseline version:
 qemuufa902c8ca0f3b83e0e3dda1e9e00f0b1d28e718a

Last test of basis71151  2017-04-05 15:44:42 Z1 days
Testing same since71158  2017-04-06 17:19:52 Z0 days1 attempts


People who touched revisions under test:
  Alexey Kardashevskiy 
  Greg Kurz 
  John Snow 
  Michael S. Tsirkin 
  Paolo Bonzini 
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt 

[Xen-devel] [xen-4.4-testing test] 107232: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-multivcpu 11 guest-start fail REGR. vs. 106822
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 
106822
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
106822
 test-amd64-i386-xend-qemut-winxpsp3  9 windows-install   fail REGR. vs. 106822

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop  fail blocked in 106822
 test-xtf-amd64-amd64-3   20 xtf/test-hvm32-invlpg~shadow fail  like 106822
 test-xtf-amd64-amd64-3 33 xtf/test-hvm32pae-invlpg~shadow fail like 106822
 test-xtf-amd64-amd64-3   44 xtf/test-hvm64-invlpg~shadow fail  like 106822
 test-xtf-amd64-amd64-2   54 leak-check/check fail  like 106822
 test-xtf-amd64-amd64-4   54 leak-check/check fail  like 106822
 test-xtf-amd64-amd64-1   54 leak-check/check fail  like 106822
 test-xtf-amd64-amd64-5   54 leak-check/check fail  like 106822
 test-xtf-amd64-amd64-3   54 leak-check/check fail  like 106822
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 106822
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 106822

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-2   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-2   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-1   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-4   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 31 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 37 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   41 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4 31 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1 31 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4 37 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   41 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1 37 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   41 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5   10 xtf-fep  fail   never pass
 build-i386-rumprun7 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-amd64-rumprun   7 xen-buildfail   never pass
 test-xtf-amd64-amd64-3   10 xtf-fep  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-xtf-amd64-amd64-2   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-4   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-1   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-xtf-amd64-amd64-5   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-xtf-amd64-amd64-3   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 11 guest-start  fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  6bf0560e123ec50dd0fab3850effe448504d8604
baseline version:
 xen   

[Xen-devel] [xen-4.8-testing test] 107234: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 107210
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 107210
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 107210
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 107210
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 107210

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 xen  e1c62cdf782085605ea1186912fc419dd9464027
baseline version:
 xen  ec7f9e1df2aa6cf8376d26eafca554c6521d2e7c

Last test of basis   107210  2017-04-05 05:29:32 Z1 days
Testing same since   107234  2017-04-06 10:19:41 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Ian Jackson 
  Jonathan Davies 
  Juergen Gross 
  Paul Durrant 
  Thomas Sanders 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  fail
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-i386-libvirt

[Xen-devel] [xen-unstable-smoke test] 107257: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  91ef7364933037b6a8d825405a1c809a72e6152f
baseline version:
 xen  db7b5b0c50b238ca259b83af3aca102701c4abac

Last test of basis   107252  2017-04-06 18:01:30 Z0 days
Testing same since   107257  2017-04-07 00:24:43 Z0 days1 attempts


People who touched revisions under test:
  Stefano Stabellini 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=91ef7364933037b6a8d825405a1c809a72e6152f
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
91ef7364933037b6a8d825405a1c809a72e6152f
+ branch=xen-unstable-smoke
+ revision=91ef7364933037b6a8d825405a1c809a72e6152f
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ 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
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' x91ef7364933037b6a8d825405a1c809a72e6152f = 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
++ : 

[Xen-devel] [PATCH v2 5/5] tools: sched: add support for 'null' scheduler

[Dario Faggioli]

It being very very basic, also means this scheduler does
not need much support at the tools level (for now).

Basically, just the definition of the symbol of the
scheduler itself and a couple of stubs.

Signed-off-by: Dario Faggioli 
Acked-by: Wei Liu 
Acked-by: Stefano Stabellini 
---
Cc: Ian Jackson 
Cc: George Dunlap 
Cc: Julien Grall 
---
 tools/libxl/libxl.h |6 ++
 tools/libxl/libxl_sched.c   |   24 
 tools/libxl/libxl_types.idl |1 +
 3 files changed, 31 insertions(+)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index a402236..cf8687a 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -210,6 +210,12 @@
 #define LIBXL_HAVE_SCHED_RTDS 1
 
 /*
+ * LIBXL_HAVE_SCHED_NULL indicates that the 'null' static scheduler
+ * is available.
+ */
+#define LIBXL_HAVE_SCHED_NULL 1
+
+/*
  * libxl_domain_build_info has u.hvm.viridian_enable and _disable bitmaps
  * of the specified width.
  */
diff --git a/tools/libxl/libxl_sched.c b/tools/libxl/libxl_sched.c
index 84d3837..d44fbe1 100644
--- a/tools/libxl/libxl_sched.c
+++ b/tools/libxl/libxl_sched.c
@@ -178,6 +178,20 @@ static int sched_arinc653_domain_set(libxl__gc *gc, 
uint32_t domid,
 return 0;
 }
 
+static int sched_null_domain_set(libxl__gc *gc, uint32_t domid,
+ const libxl_domain_sched_params *scinfo)
+{
+/* The null scheduler doesn't take any domain-specific parameters. */
+return 0;
+}
+
+static int sched_null_domain_get(libxl__gc *gc, uint32_t domid,
+   libxl_domain_sched_params *scinfo)
+{
+/* The null scheduler doesn't have any domain-specific parameters. */
+return ERROR_INVAL;
+}
+
 static int sched_credit_domain_get(libxl__gc *gc, uint32_t domid,
libxl_domain_sched_params *scinfo)
 {
@@ -730,6 +744,9 @@ int libxl_domain_sched_params_set(libxl_ctx *ctx, uint32_t 
domid,
 case LIBXL_SCHEDULER_RTDS:
 ret=sched_rtds_domain_set(gc, domid, scinfo);
 break;
+case LIBXL_SCHEDULER_NULL:
+ret=sched_null_domain_set(gc, domid, scinfo);
+break;
 default:
 LOGD(ERROR, domid, "Unknown scheduler");
 ret=ERROR_INVAL;
@@ -758,6 +775,7 @@ int libxl_vcpu_sched_params_set(libxl_ctx *ctx, uint32_t 
domid,
 case LIBXL_SCHEDULER_CREDIT:
 case LIBXL_SCHEDULER_CREDIT2:
 case LIBXL_SCHEDULER_ARINC653:
+case LIBXL_SCHEDULER_NULL:
 LOGD(ERROR, domid, "per-VCPU parameter setting not supported for this 
scheduler");
 rc = ERROR_INVAL;
 break;
@@ -792,6 +810,7 @@ int libxl_vcpu_sched_params_set_all(libxl_ctx *ctx, 
uint32_t domid,
 case LIBXL_SCHEDULER_CREDIT:
 case LIBXL_SCHEDULER_CREDIT2:
 case LIBXL_SCHEDULER_ARINC653:
+case LIBXL_SCHEDULER_NULL:
 LOGD(ERROR, domid, "per-VCPU parameter setting not supported for this 
scheduler");
 rc = ERROR_INVAL;
 break;
@@ -832,6 +851,9 @@ int libxl_domain_sched_params_get(libxl_ctx *ctx, uint32_t 
domid,
 case LIBXL_SCHEDULER_RTDS:
 ret=sched_rtds_domain_get(gc, domid, scinfo);
 break;
+case LIBXL_SCHEDULER_NULL:
+ret=sched_null_domain_get(gc, domid, scinfo);
+break;
 default:
 LOGD(ERROR, domid, "Unknown scheduler");
 ret=ERROR_INVAL;
@@ -858,6 +880,7 @@ int libxl_vcpu_sched_params_get(libxl_ctx *ctx, uint32_t 
domid,
 case LIBXL_SCHEDULER_CREDIT:
 case LIBXL_SCHEDULER_CREDIT2:
 case LIBXL_SCHEDULER_ARINC653:
+case LIBXL_SCHEDULER_NULL:
 LOGD(ERROR, domid, "per-VCPU parameter getting not supported for this 
scheduler");
 rc = ERROR_INVAL;
 break;
@@ -890,6 +913,7 @@ int libxl_vcpu_sched_params_get_all(libxl_ctx *ctx, 
uint32_t domid,
 case LIBXL_SCHEDULER_CREDIT:
 case LIBXL_SCHEDULER_CREDIT2:
 case LIBXL_SCHEDULER_ARINC653:
+case LIBXL_SCHEDULER_NULL:
 LOGD(ERROR, domid, "per-VCPU parameter getting not supported for this 
scheduler");
 rc = ERROR_INVAL;
 break;
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index d970284..d42f6a1 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -191,6 +191,7 @@ libxl_scheduler = Enumeration("scheduler", [
 (6, "credit2"),
 (7, "arinc653"),
 (8, "rtds"),
+(9, "null"),
 ])
 
 # Consistent with SHUTDOWN_* in sched.h (apart from UNKNOWN)


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

[Xen-devel] [PATCH v2 3/5] xen: sched: introduce the 'null' semi-static scheduler

[Dario Faggioli]

In cases where one is absolutely sure that there will be
less vCPUs than pCPUs, having to pay the cose, mostly in
terms of overhead, of an advanced scheduler may be not
desirable.

The simple scheduler implemented here could be a solution.
Here how it works:
 - each vCPU is statically assigned to a pCPU;
 - if there are pCPUs without any vCPU assigned, they
   stay idle (as in, the run their idle vCPU);
 - if there are vCPUs which are not assigned to any
   pCPU (e.g., because there are more vCPUs than pCPUs)
   they *don't* run, until they get assigned;
 - if a vCPU assigned to a pCPU goes away, one of the
   waiting to be assigned vCPU, if any, gets assigned
   to the pCPU and can run there.

This scheduler, therefore, if used in configurations
where every vCPUs can be assigned to a pCPU, guarantees
low overhead, low latency, and consistent performance.

If used as default scheduler, at Xen boot, it is
recommended to limit the number of Dom0 vCPUs (e.g., with
'dom0_max_vcpus=x'). Otherwise, all the pCPUs will have
one Dom0's vCPU assigned, and there won't be room for
running efficiently (if at all) any guest.

Target use cases are embedded and HPC, but it may well
be interesting also in circumnstances.

Kconfig and documentation are update accordingly.

While there, also document the availability of sched=rtds
as boot parameter, which apparently had been forgotten.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Jonathan Davies 
Cc: Marcus Granado 
---
Changed from v1:
- coding style fixes (removed some hard tabs);
- removed the null_vcpu->ndom up pointer, as suggested during review. It's
  actually a pattern to have it in the schedulers, but in this one, it was
  basically never used (only exception was NULL_VCPU_CHECK());
- removed the redundant pcpu field in null_vcpu, as suggested during review;
- factored common out code from null_vcpu_remove() and null_vcpu_migrate(),
  as suggested during review;
- use dprintk() for logging (as we don't care who current is), but with
  XENLOG_G_, because we do want rate limiting;
- add a warning when a vCPU is put in the waitqueue;
- fixed null_vcpu_insert() locking, so that we hold change the value of
  v->processor while holding the lock on the original pCPU, as it should
  be done;
- triggering SCHEDULE_SOFTIRQ in schedule.c:schedule_cpu_switch() moved
  to its own patch.
---
 docs/misc/xen-command-line.markdown |2 
 xen/common/Kconfig  |   11 
 xen/common/Makefile |1 
 xen/common/sched_null.c |  786 +++
 xen/include/public/domctl.h |1 
 5 files changed, 800 insertions(+), 1 deletion(-)
 create mode 100644 xen/common/sched_null.c

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 5815d87..4c8fe2f 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1423,7 +1423,7 @@ Map the HPET page as read only in Dom0. If disabled the 
page will be mapped
 with read and write permissions.
 
 ### sched
-> `= credit | credit2 | arinc653`
+> `= credit | credit2 | arinc653 | rtds | null`
 
 > Default: `sched=credit`
 
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index afbc0e9..dc8e876 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -187,6 +187,14 @@ config SCHED_ARINC653
  The ARINC653 scheduler is a hard real-time scheduler for single
  cores, targeted for avionics, drones, and medical devices.
 
+config SCHED_NULL
+   bool "Null scheduler support (EXPERIMENTAL)"
+   default y
+   ---help---
+ The null scheduler is a static, zero overhead scheduler,
+ for when there always are less vCPUs than pCPUs, typically
+ in embedded or HPC scenarios.
+
 choice
prompt "Default Scheduler?"
default SCHED_CREDIT_DEFAULT
@@ -199,6 +207,8 @@ choice
bool "RT Scheduler" if SCHED_RTDS
config SCHED_ARINC653_DEFAULT
bool "ARINC653 Scheduler" if SCHED_ARINC653
+   config SCHED_NULL_DEFAULT
+   bool "Null Scheduler" if SCHED_NULL
 endchoice
 
 config SCHED_DEFAULT
@@ -207,6 +217,7 @@ config SCHED_DEFAULT
default "credit2" if SCHED_CREDIT2_DEFAULT
default "rtds" if SCHED_RTDS_DEFAULT
default "arinc653" if SCHED_ARINC653_DEFAULT
+   default "null" if SCHED_NULL_DEFAULT
default "credit"
 
 endmenu
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 0fed30b..26c5a64 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_SCHED_ARINC653) += sched_arinc653.o
 obj-$(CONFIG_SCHED_CREDIT) += sched_credit.o
 obj-$(CONFIG_SCHED_CREDIT2) += sched_credit2.o
 obj-$(CONFIG_SCHED_RTDS) += sched_rt.o

[Xen-devel] [PATCH v2 1/5] xen: sched: improve robustness (and rename) DOM2OP()

[Dario Faggioli]

Clarify and enforce (with ASSERTs) when the function
is called on the idle domain, and explain in comments
what it means and when it is ok to do so.

While there, change the name of the function to a more
self-explanatory one, and do the same to VCPU2OP.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Juergen Gross 
Cc: Jan Beulich 
---
Changes from v1:
 - new patch;
 - renamed VCPU2OP, as suggested during v1's review of patch 1.

Changes from v1 of the null scheduler series:
 - renamed the helpers to dom_scheduler() and vcpu_scheduler().
---
 xen/common/schedule.c |   56 -
 1 file changed, 37 insertions(+), 19 deletions(-)

diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index d344b7c..d67227f 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -77,8 +77,25 @@ static struct scheduler __read_mostly ops;
  (( (opsptr)->fn != NULL ) ? (opsptr)->fn(opsptr, ##__VA_ARGS__ )  \
   : (typeof((opsptr)->fn(opsptr, ##__VA_ARGS__)))0 )
 
-#define DOM2OP(_d)(((_d)->cpupool == NULL) ?  : ((_d)->cpupool->sched))
-static inline struct scheduler *VCPU2OP(const struct vcpu *v)
+static inline struct scheduler *dom_scheduler(const struct domain *d)
+{
+if ( likely(d->cpupool != NULL) )
+return d->cpupool->sched;
+
+/*
+ * If d->cpupool is NULL, this is the idle domain. This is special
+ * because the idle domain does not really bolong to any cpupool, and,
+ * hence, does not really have a scheduler.
+ *
+ * This is (should be!) only called like this for allocating the idle
+ * vCPUs for the first time, during boot, in which case what we want
+ * is the default scheduler that has been, choosen at boot.
+ */
+ASSERT(is_idle_domain(d));
+return 
+}
+
+static inline struct scheduler *vcpu_scheduler(const struct vcpu *v)
 {
 struct domain *d = v->domain;
 
@@ -260,7 +277,8 @@ int sched_init_vcpu(struct vcpu *v, unsigned int processor)
 init_timer(>poll_timer, poll_timer_fn,
v, v->processor);
 
-v->sched_priv = SCHED_OP(DOM2OP(d), alloc_vdata, v, d->sched_priv);
+v->sched_priv = SCHED_OP(dom_scheduler(d), alloc_vdata, v,
+d->sched_priv);
 if ( v->sched_priv == NULL )
 return 1;
 
@@ -272,7 +290,7 @@ int sched_init_vcpu(struct vcpu *v, unsigned int processor)
 }
 else
 {
-SCHED_OP(DOM2OP(d), insert_vcpu, v);
+SCHED_OP(dom_scheduler(d), insert_vcpu, v);
 }
 
 return 0;
@@ -326,7 +344,7 @@ int sched_move_domain(struct domain *d, struct cpupool *c)
 
 domain_pause(d);
 
-old_ops = DOM2OP(d);
+old_ops = dom_scheduler(d);
 old_domdata = d->sched_priv;
 
 for_each_vcpu ( d, v )
@@ -389,8 +407,8 @@ void sched_destroy_vcpu(struct vcpu *v)
 kill_timer(>poll_timer);
 if ( test_and_clear_bool(v->is_urgent) )
 atomic_dec(_cpu(schedule_data, v->processor).urgent_count);
-SCHED_OP(VCPU2OP(v), remove_vcpu, v);
-SCHED_OP(VCPU2OP(v), free_vdata, v->sched_priv);
+SCHED_OP(vcpu_scheduler(v), remove_vcpu, v);
+SCHED_OP(vcpu_scheduler(v), free_vdata, v->sched_priv);
 }
 
 int sched_init_domain(struct domain *d, int poolid)
@@ -404,7 +422,7 @@ int sched_init_domain(struct domain *d, int poolid)
 
 SCHED_STAT_CRANK(dom_init);
 TRACE_1D(TRC_SCHED_DOM_ADD, d->domain_id);
-return SCHED_OP(DOM2OP(d), init_domain, d);
+return SCHED_OP(dom_scheduler(d), init_domain, d);
 }
 
 void sched_destroy_domain(struct domain *d)
@@ -413,7 +431,7 @@ void sched_destroy_domain(struct domain *d)
 
 SCHED_STAT_CRANK(dom_destroy);
 TRACE_1D(TRC_SCHED_DOM_REM, d->domain_id);
-SCHED_OP(DOM2OP(d), destroy_domain, d);
+SCHED_OP(dom_scheduler(d), destroy_domain, d);
 
 cpupool_rm_domain(d);
 }
@@ -432,7 +450,7 @@ void vcpu_sleep_nosync(struct vcpu *v)
 if ( v->runstate.state == RUNSTATE_runnable )
 vcpu_runstate_change(v, RUNSTATE_offline, NOW());
 
-SCHED_OP(VCPU2OP(v), sleep, v);
+SCHED_OP(vcpu_scheduler(v), sleep, v);
 }
 
 vcpu_schedule_unlock_irqrestore(lock, flags, v);
@@ -461,7 +479,7 @@ void vcpu_wake(struct vcpu *v)
 {
 if ( v->runstate.state >= RUNSTATE_blocked )
 vcpu_runstate_change(v, RUNSTATE_runnable, NOW());
-SCHED_OP(VCPU2OP(v), wake, v);
+SCHED_OP(vcpu_scheduler(v), wake, v);
 }
 else if ( !(v->pause_flags & VPF_blocked) )
 {
@@ -516,8 +534,8 @@ static void vcpu_move_locked(struct vcpu *v, unsigned int 
new_cpu)
  * Actual CPU switch to new CPU.  This is safe because the lock
  * pointer cant' change while the current lock is held.
  */
-if ( VCPU2OP(v)->migrate )
-SCHED_OP(VCPU2OP(v), migrate, v, new_cpu);
+if ( vcpu_scheduler(v)->migrate )
+SCHED_OP(vcpu_scheduler(v), migrate, v, new_cpu);
 

[Xen-devel] [PATCH v2 4/5] xen: sched_null: support for hard affinity

[Dario Faggioli]

As a (rudimental) way of directing and affecting the
placement logic implemented by the scheduler, support
vCPU hard affinity.

Basically, a vCPU will now be assigned only to a pCPU
that is part of its own hard affinity. If such pCPU(s)
is (are) busy, the vCPU will wait, like it happens
when there are no free pCPUs.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Jonathan Davies 
Cc: Marcus Granado 
---
Changes from v1:
- coding style fixes (removed some hard tabs);
- better signature for check_nvc_affinity() (also renamed in
  vcpu_check_affinity());
- fixed bug in null_vcpu_remove() using uninitialized cpumask.
---
 xen/common/sched_null.c |   50 ---
 1 file changed, 34 insertions(+), 16 deletions(-)

diff --git a/xen/common/sched_null.c b/xen/common/sched_null.c
index c2c4182..96652a0 100644
--- a/xen/common/sched_null.c
+++ b/xen/common/sched_null.c
@@ -115,6 +115,14 @@ static inline struct null_dom *null_dom(const struct 
domain *d)
 return d->sched_priv;
 }
 
+static inline bool vcpu_check_affinity(struct vcpu *v, unsigned int cpu)
+{
+cpumask_and(cpumask_scratch_cpu(cpu), v->cpu_hard_affinity,
+cpupool_domain_cpumask(v->domain));
+
+return cpumask_test_cpu(cpu, cpumask_scratch_cpu(cpu));
+}
+
 static int null_init(struct scheduler *ops)
 {
 struct null_private *prv;
@@ -276,16 +284,22 @@ static unsigned int pick_cpu(struct null_private *prv, 
struct vcpu *v)
 
 ASSERT(spin_is_locked(per_cpu(schedule_data, cpu).schedule_lock));
 
+cpumask_and(cpumask_scratch_cpu(cpu), v->cpu_hard_affinity, cpus);
+
 /*
- * If our processor is free, or we are assigned to it, and it is
- * also still valid, just go for it.
+ * If our processor is free, or we are assigned to it, and it is also
+ * still valid and part of our affinity, just go for it.
+ * (Note that we may call vcpu_check_affinity(), but we deliberately
+ * don't, so we get to keep in the scratch cpumask what we have just
+ * put in it.)
  */
 if ( likely((per_cpu(npc, cpu).vcpu == NULL || per_cpu(npc, cpu).vcpu == v)
-&& cpumask_test_cpu(cpu, cpus)) )
+&& cpumask_test_cpu(cpu, cpumask_scratch_cpu(cpu))) )
 return cpu;
 
-/* If not, just go for a valid free pCPU, if any */
-cpumask_and(cpumask_scratch_cpu(cpu), >cpus_free, cpus);
+/* If not, just go for a free pCPU, within our affinity, if any */
+cpumask_and(cpumask_scratch_cpu(cpu), cpumask_scratch_cpu(cpu),
+>cpus_free);
 new_cpu = cpumask_first(cpumask_scratch_cpu(cpu));
 
 if ( likely(new_cpu != nr_cpu_ids) )
@@ -302,7 +316,8 @@ static unsigned int pick_cpu(struct null_private *prv, 
struct vcpu *v)
  * as we will actually assign the vCPU to the pCPU we return from here,
  * only if the pCPU is free.
  */
-return cpumask_any(cpus);
+cpumask_and(cpumask_scratch_cpu(cpu), cpus, v->cpu_hard_affinity);
+return cpumask_any(cpumask_scratch_cpu(cpu));
 }
 
 static void vcpu_assign(struct null_private *prv, struct vcpu *v,
@@ -361,6 +376,7 @@ static void null_vcpu_insert(const struct scheduler *ops, 
struct vcpu *v)
 {
 struct null_private *prv = null_priv(ops);
 struct null_vcpu *nvc = null_vcpu(v);
+unsigned int cpu;
 spinlock_t *lock;
 
 ASSERT(!is_idle_vcpu(v));
@@ -368,23 +384,25 @@ static void null_vcpu_insert(const struct scheduler *ops, 
struct vcpu *v)
 lock = vcpu_schedule_lock_irq(v);
  retry:
 
-v->processor = pick_cpu(prv, v);
+cpu = v->processor = pick_cpu(prv, v);
 
 spin_unlock(lock);
 
 lock = vcpu_schedule_lock(v);
 
+cpumask_and(cpumask_scratch_cpu(cpu), v->cpu_hard_affinity,
+cpupool_domain_cpumask(v->domain));
+
 /* If the pCPU is free, we assign v to it */
-if ( likely(per_cpu(npc, v->processor).vcpu == NULL) )
+if ( likely(per_cpu(npc, cpu).vcpu == NULL) )
 {
 /*
  * Insert is followed by vcpu_wake(), so there's no need to poke
  * the pcpu with the SCHEDULE_SOFTIRQ, as wake will do that.
  */
-vcpu_assign(prv, v, v->processor);
+vcpu_assign(prv, v, cpu);
 }
-else if ( cpumask_intersects(>cpus_free,
- cpupool_domain_cpumask(v->domain)) )
+else if ( cpumask_intersects(>cpus_free, cpumask_scratch_cpu(cpu)) )
 {
 /*
  * If the pCPU is not free (e.g., because we raced with another
@@ -413,7 +431,6 @@ static void null_vcpu_insert(const struct scheduler *ops, 
struct vcpu *v)
 static void _vcpu_remove(struct null_private *prv, struct vcpu *v)
 {
 unsigned int cpu = v->processor;
-struct domain *d = v->domain;
 struct null_vcpu *wvc;
 
 

[Xen-devel] [PATCH v2 0/5] The 'null' Scheduler

[Dario Faggioli]

Hello,

here it comes v2 of this series about the 'null' scheduler.

v1, with much details about the idea and the goal of this scheduler is here:
 https://lists.xen.org/archives/html/xen-devel/2017-03/msg02316.html

In this version, I'm basically addressing the review comments I received.

There are 5 patches now, instead of 3, because:
 - I've added "xen: sched: improve robustness (and rename) DOM2OP()" at the
   beginning of the series. That is totally independent from the series itself,
   I just needed to repost it, and did it like this for convenience;
 - patch 2 is new as it contains what was an hunk of another patch in v1,
   but it really wanted to live in its own separate patches (that was also
   one of the review comments).

Finally, about last patch. Wei and Stefano acked it in v1, so I've kept it as
it was, and added their Acked-by tags. Since then, there has been some
discussion with George about changing the behavior of libxl's scheduling
parameter getting function.

If what George is proposing is considered better, I'm happy to do it and
resend. Just let me know.

A git branch is available here:
 git://xenbits.xen.org/people/dariof/xen.git  rel/sched/null-sched-v2
 https://travis-ci.org/fdario/xen/builds/219505940  [*]

Thanks and Regards,
Dario

[*] Clang build are failing, but that's a known issue for current staging,
independent from this series.
---
Dario Faggioli (5):
  xen: sched: improve robustness (and rename) DOM2OP()
  xen: sched: make sure a pCPU added to a pool runs the scheduler ASAP
  xen: sched: introduce the 'null' semi-static scheduler
  xen: sched_null: support for hard affinity
  tools: sched: add support for 'null' scheduler

 docs/misc/xen-command-line.markdown |2 
 tools/libxl/libxl.h |6 
 tools/libxl/libxl_sched.c   |   24 +
 tools/libxl/libxl_types.idl |1 
 xen/common/Kconfig  |   11 
 xen/common/Makefile |1 
 xen/common/sched_null.c |  804 +++
 xen/common/schedule.c   |   59 ++-
 xen/include/public/domctl.h |1 
 9 files changed, 889 insertions(+), 20 deletions(-)
 create mode 100644 xen/common/sched_null.c
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

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

[Xen-devel] [PATCH v2 2/5] xen: sched: make sure a pCPU added to a pool runs the scheduler ASAP

[Dario Faggioli]

When a pCPU is added to a cpupool, the pool's scheduler
should immediately run on it so, for instance, any runnable
but not running vCPU can start executing there.

This currently does not happen. Make it happen by raising
the scheduler softirq directly from the function that
sets up the new scheduler for the pCPU.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Stefano Stabellini 
---
 xen/common/schedule.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index d67227f..4aae423 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -1823,6 +1823,9 @@ int schedule_cpu_switch(unsigned int cpu, struct cpupool 
*c)
 
  out:
 per_cpu(cpupool, cpu) = c;
+/* When a cpu is added to a pool, trigger it to go pick up some work */
+if ( c != NULL )
+cpu_raise_softirq(cpu, SCHEDULE_SOFTIRQ);
 
 return 0;
 }


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

Re: [Xen-devel] [PATCH v2 2/2] xen: sched: improve robustness (and rename) DOM2OP()

[Dario Faggioli]

On Thu, 2017-04-06 at 13:06 +0200, Juergen Gross wrote:
> On 06/04/17 12:59, Dario Faggioli wrote:
> > Maybe:
> > 
> > domain_scheduler()
> > vcpu_scheduler()
> > 
> > or
> > 
> > dom_scheduler()
> > vcpu_scheduler()
> > 
> > Or, also trading 'scheduler' for 'ops':
> > 
> > dom_ops()
> > vcpu_ops()
> 
> sched_ops_dom()
> sched_ops_vcpu()
> 
> or
> 
> sched_dom_ops()
> sched_vcpu_ops()
> 
Yeah, these too.

So, for now, I've resent using dom_scheduler() and vcpu_scheduler().

But I'm happy to change them to whatever and re-send again, as soon as
George tells me which one is his preferred solution. :-D

Thanks and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-4.7-testing test] 107233: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 107185
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 107209
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 107209
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 107209
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 107209
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 107209
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 107209

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  6cf0da59518356b399cf178b36e5af7403ee5ece
baseline version:
 xen  ada9e109d7539ec93e1b554805721110d2807521

Last test of basis   107209  2017-04-05 05:27:53 Z1 days
Testing same since   107233  2017-04-06 10:18:59 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Ian Jackson 
  Jonathan Davies 
  Juergen Gross 
  Paul Durrant 
  Thomas Sanders 
  Wei Liu 

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

Re: [Xen-devel] [GSoc] GSoc Introduction : Xen on ARM: create multiple guests from device tree

[Methuku Karthik]

Hi Stefano,

I have used attached bin2c.c convert the contents of .config file to hex.

(echo "static const char xen_config_data[] __attribute__((used)) =
./bin2c.o  xen_config.h

the above command will generate the header file which will contain the
contents of config file in hex form.

i wrote a tester code to check if i .config is output correctly.

any inputs on makefile modification would be of great help.

Will addition of below rules to makefile suffice
1.Add rule to compile bin2c.c always.
2.add the above mentioned shell command to make file to generate the
header file.
3. which object file should include the header file ?

I am thinking to add bin2c.c file in scripts folder, access .config
file from xen folder to give it as input to bin2.o. and generate
xen_config.h

As you mentioned that it would be nice to add hyper call, where should
the generated xen_config.h file be added and which file should have
the include?

I am attaching bin2c.c file and sample xen_config.h file, with tester
for your reference.

If the procedure seems fine , i will go ahead and change the makefile
accordingly and commit the changes.

On Tue, Apr 4, 2017 at 1:29 PM, Stefano Stabellini
 wrote:
> One more thing: the deadline for microtasks (the patch submission below
> to fix XEN-38) is technically Monday the 10th of April, but in practice
> the patch needs to be sent this week to be able to follow up review
> comments appropriately. Ideally the patch should be already committed by
> Monday the 10th.
>
> On Mon, 3 Apr 2017, Methuku Karthik wrote:
>> Hi Stefano,
>>
>> I have asked questions in inline. Clarification below questions would really 
>> help me in contribution. Please look into the questions. I am highlighting 
>> them in this mail.
>>
>>  For example, Dom1 should be able to share a page with Dom2 and a
>>   different page with Dom3. It needs to be clear which page is shared with
>> which VM from the VM config files.
>>
>>
>> when we create vms using xl create , for example if i am planning create 
>> three VMs,
>>
>> Dom1, Dom2 and Dom3, because of the page sharing are we imposing any order of
>>   creating VMs.
>>
>>   I am asking this question to clarify this point, while creation of Dom1 if 
>> its
>>   sharing pages with Dom 2 and Dom 3 , should Xen already be aware of Dom2 
>> and Dom3?
>>
>>   I am referring to following links to understand about mem sharing.
>>
>>   
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/tests/mem-sharing/memshrtoo
>>   l.c;h=8e5e22b9e95d91f1441d8eb226b64852eca075d5;hb=HEAD
>>   http://xenbits.xen.org/docs/unstable/misc/grant-tables.txt
>>
>>   I also want to figure out how domains are created and how xl tool parses 
>> the file
>>   and passes on the information to domain creation . Let me know if i am 
>> thinking in
>>   right direction.
>>
>>   suggest any resource or work which would help with designing config file 
>> options.
>>
>>
>>  I will start with Xen-38 that would help me in exploring init code. Correct 
>> me if i
>>   am wrong.
>>
>>   I have a few questions and clarifications before proceeding further. I 
>> have checked
>>   how config.gz file is generated in linux kernel source.
>>   In linux kernel sources, if CONFIG_IKCONFIG_PROC option is set, .conifg 
>> file which
>>   is generated after choosing options with lets say from make menuconfig  is 
>> read into
>>   a variable, this way its part of build.
>>
>>   during init time proc_create service is used to create this file config.gz.
>>   http://lxr.free-electrons.com/source/kernel/configs.c
>>
>>
>>   I guess i have to do something similar.
>>
>>   Questions :
>>
>>   1. When Xen is build using the make command, we effectively set 
>> XEN_COMPILE_ARCH,
>>   XEN_OS, XEN_TARGET which allow using corresponding .mk file from config 
>> folder.
>>   These variable in turn decide what are the config options. I wasnt able to 
>> find any
>>   .config. Please direct me to find the file or if i am missing something.
>>
>>   2. Where and how this config file should be accessible to  User once in 
>> Dom0. Is the
>>   xen folder created to keep the information about guest domains like proc 
>> for process
>>   in linux kernel ? Will that be suitable location to have config file.
>>
>>   3. if i assume that i will approach similarly, i have to add services to 
>> be called
>>   during init stage. As am not acquainted with code base, i could just grep 
>> with
>>   _start or _init or similar strings to find out initialization code. Any
>>   input(function name or filename) to look for will be of great help.
>>
>> On Mon, Apr 3, 2017 at 3:35 PM, Stefano Stabellini  
>> wrote:
>>   Thank you! I am looking forward to your contribution on the list! If 
>> you
>>   encounter any issues, please let us know.
>>
>>   The code contribution is more important, but if you find the time in 
>> the
>>   next few days, it would be nice to add more details to 

Re: [Xen-devel] [PATCH v7 2/2] vgic: refuse irq migration when one is already in progress

[Julien Grall]

Hi Stefano,

On 04/05/2017 09:28 PM, Stefano Stabellini wrote:

When an irq migration is already in progress, but not yet completed
(GIC_IRQ_GUEST_MIGRATING is set), refuse any other irq migration
requests for the same irq.

This patch implements this approach by returning success or failure from
vgic_migrate_irq, and avoiding irq target changes on failure. It prints
a warning in case the irq migration fails.

It also moves the clear_bit of GIC_IRQ_GUEST_MIGRATING to after the
physical irq affinity has been changed so that all operations regarding
irq migration are completed.

Signed-off-by: Stefano Stabellini 


Reviewed-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5] boot allocator: Use arch helper for virt_to_mfn on DIRECTMAP_VIRT region

[Julien Grall]

Hi Vijay,

On 04/06/2017 11:13 AM, vijay.kil...@gmail.com wrote:

[...]


On ARM64 this arch helper will return true, because currently all RAM
is direct mapped in Xen.
On ARM32, Only a limited amount of RAM, called xenheap, is always mapped


NIT: s/Only/only/


and DIRECTMAP_VIRT region is not mapped. Hence return false.
For x86 this helper does virt_to_mfn.

Signed-off-by: Vijaya Kumar K 
Reviewed-by: Jan Beulich 



[...]


diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 68dba19..9e41fb4 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -520,9 +520,6 @@ static unsigned long init_node_heap(int node, unsigned long 
mfn,
 unsigned long needed = (sizeof(**_heap) +
 sizeof(**avail) * NR_ZONES +
 PAGE_SIZE - 1) >> PAGE_SHIFT;
-#ifdef DIRECTMAP_VIRT_END
-unsigned long eva = min(DIRECTMAP_VIRT_END, HYPERVISOR_VIRT_END);
-#endif
 int i, j;

 if ( !first_node_initialised )
@@ -532,9 +529,8 @@ static unsigned long init_node_heap(int node, unsigned long 
mfn,
 first_node_initialised = 1;
 needed = 0;
 }
-#ifdef DIRECTMAP_VIRT_END


This is common code change and new in this version. As you keep Jan 
Beulich's (x86 and common code maintainer) reviewed-by I would like to 
confirm he is happy with that.



 else if ( *use_tail && nr >= needed &&
-  (mfn + nr) <= (virt_to_mfn(eva - 1) + 1) &&
+  arch_mfn_in_directmap(mfn + nr) &&
   (!xenheap_bits ||
!((mfn + nr - 1) >> (xenheap_bits - PAGE_SHIFT))) )
 {
@@ -543,7 +539,7 @@ static unsigned long init_node_heap(int node, unsigned long 
mfn,
   PAGE_SIZE - sizeof(**avail) * NR_ZONES;
 }
 else if ( nr >= needed &&
-  (mfn + needed) <= (virt_to_mfn(eva - 1) + 1) &&
+  arch_mfn_in_directmap(mfn + needed) &&
   (!xenheap_bits ||
!((mfn + needed - 1) >> (xenheap_bits - PAGE_SHIFT))) )
 {
@@ -552,7 +548,6 @@ static unsigned long init_node_heap(int node, unsigned long 
mfn,
   PAGE_SIZE - sizeof(**avail) * NR_ZONES;
 *use_tail = 0;
 }
-#endif
 else if ( get_order_from_bytes(sizeof(**_heap)) ==
   get_order_from_pages(needed) )
 {


Reviewed-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 30/30] ARM: vGIC: advertise LPI support

[André Przywara]

On 06/04/17 12:42, Julien Grall wrote:
> Hi,
> 
> On 06/04/17 11:21, Andre Przywara wrote:
>> Hi,
>>
>> On 06/04/17 02:04, Stefano Stabellini wrote:
>>> On Thu, 6 Apr 2017, Andre Przywara wrote:
 To let a guest know about the availability of virtual LPIs, set the
 respective bits in the virtual GIC registers and let a guest control
 the LPI enable bit.
 Only report the LPI capability if the host has initialized at least
 one ITS.
 This removes a "TBD" comment, as we now populate the processor number
 in the GICR_TYPE register.
 Advertise 24 bits worth of LPIs to the guest.

 Signed-off-by: Andre Przywara 
 ---
  xen/arch/arm/vgic-v3.c | 46
 +-
  1 file changed, 41 insertions(+), 5 deletions(-)

 diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
 index 3b01247..ba0e79f 100644
 --- a/xen/arch/arm/vgic-v3.c
 +++ b/xen/arch/arm/vgic-v3.c
 @@ -168,8 +168,12 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct
 vcpu *v, mmio_info_t *info,
  switch ( gicr_reg )
  {
  case VREG32(GICR_CTLR):
 -/* We have not implemented LPI's, read zero */
 -goto read_as_zero_32;
 +if ( dabt.size != DABT_WORD ) goto bad_width;
 +spin_lock(>arch.vgic.lock);
 +*r = vgic_reg32_extract(!!(v->arch.vgic.flags &
 VGIC_V3_LPIS_ENABLED),
 +info);
 +spin_unlock(>arch.vgic.lock);
 +return 1;

  case VREG32(GICR_IIDR):
  if ( dabt.size != DABT_WORD ) goto bad_width;
 @@ -181,16 +185,20 @@ static int
 __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, mmio_info_t *info,
  uint64_t typer, aff;

  if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
 -/* TBD: Update processor id in [23:8] when ITS support is
 added */
  aff = (MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 3) << 56 |
 MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 2) << 48 |
 MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 1) << 40 |
 MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 0) << 32);
  typer = aff;
 +/* We use the VCPU ID as the redistributor ID in bits[23:8] */
 +typer |= (v->vcpu_id & 0x) << 8;

  if ( v->arch.vgic.flags & VGIC_V3_RDIST_LAST )
  typer |= GICR_TYPER_LAST;

 +if ( v->domain->arch.vgic.has_its )
 +typer |= GICR_TYPER_PLPIS;
 +
  *r = vgic_reg64_extract(typer, info);

  return 1;
 @@ -411,6 +419,17 @@ static uint64_t sanitize_pendbaser(uint64_t reg)
  return reg;
  }

 +static void vgic_vcpu_enable_lpis(struct vcpu *v)
 +{
 +uint64_t reg = v->domain->arch.vgic.rdist_propbase;
 +unsigned int nr_lpis = BIT((reg & 0x1f) + 1) - LPI_OFFSET;
 +
 +if ( !v->domain->arch.vgic.nr_lpis )
 +v->domain->arch.vgic.nr_lpis = nr_lpis;
>>>
>>> What if nr_lpis was already set and the nr_lpis has changed?
>>
>> I think this can never happen:
>> 1) vgic.rdist_propbase is only writeable when the redistributor has not
>> been enabled yet:
>> /* Writing PROPBASER with LPIs enabled is UNPREDICTABLE. */
>> if ( !(v->arch.vgic.flags & VGIC_V3_LPIS_ENABLED) )
>> {
>> reg = v->domain->arch.vgic.rdist_propbase;
>> vgic_reg64_update(, r, info);
>> reg = sanitize_propbaser(reg);
>> v->domain->arch.vgic.rdist_propbase = reg;
> 
> This will be called until VGIC_V3_LPIS_ENABLED will be set for the vCPU.
> However rdist_propbase is part of struct domain. So ...
> 
>> }
>> 
>> 2) This function above can only be called once:
> 
> ... as this function will be called multiple per domain (once per vCPU).
> You could end up having nr_lpis not in sync with propbase.
> 
>> 
>> spin_lock(>arch.vgic.lock);
>>
>> /* LPIs can only be enabled once, but never disabled again. */
>> if ( (r & GICR_CTLR_ENABLE_LPIS) &&
>>  !(v->arch.vgic.flags & VGIC_V3_LPIS_ENABLED) )
>> vgic_vcpu_enable_lpis(v);
>> 
>>
>> Does that sound safe? Sorry if the architecture is a bit awkward in this
>> regard ;-)
> 
> I am afraid that this is not safe. Tĥis is fine to have propbase stored
> in the domain because the spec (8.11.9 in ARM IHI 0069C) says:
> 
> "Setting different values in different copies of GICR_PROPBASER on
> Redistributors that are required to use a common LPI Configuration table".
> 
> But you need to keep Xen internal state consistent.

Ah, the lovely GIC architecture. So technically GICR_PROPBASER is per
redistributor (so per VCPU in our case), that's why I was mechanically
using the VCPU lock. But as you rightly mention, the spec goes into
great details 

Re: [Xen-devel] [PATCH v5 18/30] ARM: vITS: introduce translation table walks

[Julien Grall]

Hi Andre,

On 04/06/2017 12:19 AM, Andre Przywara wrote:

The ITS stores the target (v)CPU and the (virtual) LPI number in tables.
Introduce functions to walk those tables and translate an device ID -
event ID pair into a pair of virtual LPI and vCPU.
We map those tables on demand - which is cheap on arm64. Also we take
care of the locking on the way, since we can't easily protect those ITTs
from being altered by the guest.

To allow compiling without warnings, we declare two functions as
non-static for the moment, which two later patches will fix.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic.c |   2 +
 xen/arch/arm/vgic-v3-its.c | 179 +
 2 files changed, 181 insertions(+)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index a56be34..5000b0d 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -491,6 +491,8 @@ static void gic_update_one_lr(struct vcpu *v, int i)
 {
 gic_hw_ops->clear_lr(i);
 clear_bit(i, _cpu(lr_mask));
+if ( is_lpi(irq) )
+clear_bit(GIC_IRQ_GUEST_LPI_PENDING, >status);


I am struggling to understand why this change is introduced in this 
patch. This does not look related to the translation table.




 if ( p->desc != NULL )
 clear_bit(_IRQ_INPROGRESS, >desc->status);
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index f6bf1ee..a145666 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -67,6 +67,8 @@ struct vits_itte
 uint16_t pad;
 };

+#define UNMAPPED_COLLECTION  ((uint16_t)~0)
+
 void vgic_v3_its_init_domain(struct domain *d)
 {
 spin_lock_init(>arch.vgic.its_devices_lock);
@@ -78,6 +80,183 @@ void vgic_v3_its_free_domain(struct domain *d)
 ASSERT(RB_EMPTY_ROOT(>arch.vgic.its_devices));
 }

+/*
+ * The physical address is encoded slightly differently depending on
+ * the used page size: the highest four bits are stored in the lowest
+ * four bits of the field for 64K pages.
+ */
+static paddr_t get_baser_phys_addr(uint64_t reg)
+{
+if ( reg & BIT(9) )
+return (reg & GENMASK_ULL(47, 16)) |
+((reg & GENMASK_ULL(15, 12)) << 36);
+else
+return reg & GENMASK_ULL(47, 12);
+}
+
+/* Must be called with the ITS lock held. */
+static struct vcpu *get_vcpu_from_collection(struct virt_its *its,
+ uint16_t collid)
+{
+paddr_t addr = get_baser_phys_addr(its->baser_coll);
+uint16_t vcpu_id;
+int ret;
+
+ASSERT(spin_is_locked(>its_lock));
+
+if ( collid >= its->max_collections )
+return NULL;
+
+ret = vgic_access_guest_memory(its->d, addr + collid * sizeof(uint16_t),
+   _id, sizeof(vcpu_id), false);
+if ( ret )
+return NULL;
+
+if ( vcpu_id == UNMAPPED_COLLECTION || vcpu_id >= its->d->max_vcpus )
+return NULL;
+
+return its->d->vcpu[vcpu_id];
+}
+
+/*
+ * Our device table encodings:
+ * Contains the guest physical address of the Interrupt Translation Table in
+ * bits [51:8], and the size of it is encoded as the number of bits minus one
+ * in the lowest 8 bits of the word.
+ */
+#define DEV_TABLE_ITT_ADDR(x) ((x) & GENMASK_ULL(51, 8))
+#define DEV_TABLE_ITT_SIZE(x) (BIT(((x) & GENMASK_ULL(7, 0)) + 1))
+#define DEV_TABLE_ENTRY(addr, bits) \
+(((addr) & GENMASK_ULL(51, 8)) | (((bits) - 1) & GENMASK_ULL(7, 0)))
+
+/*
+ * Lookup the address of the Interrupt Translation Table associated with
+ * a device ID and return the address of the ITTE belonging to the event ID
+ * (which is an index into that table).


You likely want a TODO support two-level table here.


+ */
+static paddr_t its_get_itte_address(struct virt_its *its,
+uint32_t devid, uint32_t evid)
+{
+paddr_t addr = get_baser_phys_addr(its->baser_dev);
+uint64_t itt;
+
+if ( devid >= its->max_devices )
+return INVALID_PADDR;
+
+if ( vgic_access_guest_memory(its->d, addr + devid * sizeof(uint64_t),
+  , sizeof(itt), false) )
+return INVALID_PADDR;
+
+if ( evid >= DEV_TABLE_ITT_SIZE(itt) ||
+ DEV_TABLE_ITT_ADDR(itt) == INVALID_PADDR )
+return INVALID_PADDR;
+
+return DEV_TABLE_ITT_ADDR(itt) + evid * sizeof(struct vits_itte);
+}
+
+/*
+ * Queries the collection and device tables to get the vCPU and virtual
+ * LPI number for a given guest event. This first accesses the guest memory
+ * to resolve the address of the ITTE, then reads the ITTE entry at this
+ * address and puts the result in vcpu_ptr and vlpi_ptr.
+ * Requires the ITS lock to be held.
+ */
+static bool read_itte_locked(struct virt_its *its, uint32_t devid,
+ uint32_t evid, struct vcpu **vcpu_ptr,
+ uint32_t *vlpi_ptr)
+{
+paddr_t addr;
+struct vits_itte itte;
+struct vcpu 

[Xen-devel] [xen-4.8-testing baseline-only test] 71155: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 71155 xen-4.8-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71155/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. vs. 
71134

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 71134
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 71134
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 71134

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-armhf-armhf-libvirt-raw  3 host-install(3)  broken never pass
 test-armhf-armhf-xl-xsm   3 host-install(3)  broken never pass
 test-armhf-armhf-xl-credit2   3 host-install(3)  broken never pass
 test-armhf-armhf-xl-rtds  3 host-install(3)  broken never pass
 test-armhf-armhf-xl   3 host-install(3)  broken never pass
 test-armhf-armhf-xl-midway3 host-install(3)  broken never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-intel 17 capture-logs/l1(17) fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  ec7f9e1df2aa6cf8376d26eafca554c6521d2e7c
baseline version:
 xen  f3623bdbe5f7ff63e728865a8b986b2312231685

Last test of basis71134  2017-03-31 13:18:36 Z6 days
Testing same since71155  2017-04-06 06:20:09 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Jan Beulich 
  Juergen Gross 

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

Re: [Xen-devel] [PATCH v5 17/30] ARM: vITS: add command handling stub and MMIO emulation

[Julien Grall]

Hi Andre,

Another thing I missed.

On 04/06/2017 12:19 AM, Andre Przywara wrote:

+case VREG64(GITS_BASER0):   /* device table */
+if ( !vgic_reg64_check_access(info->dabt) ) goto bad_width;
+
+spin_lock(>its_lock);
+
+/*
+ * Changing base registers with the ITS enabled is UNPREDICTABLE,
+ * we choose to ignore it, but warn.
+ */
+if ( its->enabled )
+{
+spin_unlock(>its_lock);
+gdprintk(XENLOG_WARNING, "ITS: tried to change BASER with the ITS 
enabled.\n");
+
+return 1;
+}
+
+reg = its->baser_dev;
+vgic_reg64_update(, r, info);
+
+reg &= ~GITS_BASER_RO_MASK;
+reg |= (sizeof(uint64_t) - 1) << GITS_BASER_ENTRY_SIZE_SHIFT;
+reg |= GITS_BASER_TYPE_DEVICE << GITS_BASER_TYPE_SHIFT;
+sanitize_its_base_reg();
+
+if ( reg & GITS_VALID_BIT )
+its->max_devices = its_baser_nr_entries(reg);


Should not you validate this against the maximum number of device 
supported by the ITS (i.e devid)?



+else
+its->max_devices = 0;
+
+its->baser_dev = reg;
+spin_unlock(>its_lock);
+return 1;
+case VREG64(GITS_BASER1):   /* collection table */
+if ( !vgic_reg64_check_access(info->dabt) ) goto bad_width;
+
+spin_lock(>its_lock);
+/*
+ * Changing base registers with the ITS enabled is UNPREDICTABLE,
+ * we choose to ignore it, but warn.
+ */
+if ( its->enabled )
+{
+spin_unlock(>its_lock);
+gdprintk(XENLOG_INFO, "ITS: tried to change BASER with the ITS 
enabled.\n");
+return 1;
+}
+
+reg = its->baser_coll;
+vgic_reg64_update(, r, info);
+reg &= ~GITS_BASER_RO_MASK;
+reg |= (sizeof(uint16_t) - 1) << GITS_BASER_ENTRY_SIZE_SHIFT;
+reg |= GITS_BASER_TYPE_COLLECTION << GITS_BASER_TYPE_SHIFT;
+sanitize_its_base_reg();
+
+if ( reg & GITS_VALID_BIT )
+its->max_collections = its_baser_nr_entries(reg);


Similar question for the collection. Although, I am not sure against what.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 17/30] ARM: vITS: add command handling stub and MMIO emulation

[Julien Grall]

Hi Andre,

On 04/06/2017 11:22 PM, André Przywara wrote:

On 06/04/17 22:43, Julien Grall wrote:

On 04/06/2017 12:19 AM, Andre Przywara wrote:

+static int vgic_v3_its_mmio_read(struct vcpu *v, mmio_info_t *info,
+ register_t *r, void *priv)
+{
+struct virt_its *its = priv;
+uint64_t reg;
+
+switch ( info->gpa & 0x )
+{
+case VREG32(GITS_CTLR):
+if ( info->dabt.size != DABT_WORD ) goto bad_width;
+
+spin_lock(>vcmd_lock);
+spin_lock(>its_lock);
+if ( its->enabled )
+reg = GITS_CTLR_ENABLE;
+else
+reg = 0;
+
+if ( its->cwriter == its->creadr )


I think it would be better if you can read atomically cwriter and
creadr.


What do you mean by "atomically" here? For reading and comparing *both*
registers I have to hold a lock, isn't it?


This would avoid to take the vcmd_lock here, as this would
prevent a guest vCPU to access this register while you are processing
the command queue.


That's a noble goal, but I don't know if this is easily feasible.
I wonder if one can use spin_trylock(>vcmd_lock) here, and assume
not quiescent if that fails? My understanding is that an OS would poll
CTLR until it becomes quiescent (Linux does so), so it would try again,
returning here until the lock becomes actually free.
Would that work?
But looking at the Linux code again I see that this is only done once at
probe time (before the ITS is enabled), so at least from that side it's
not really worth optimizing.


As you may know, I don't buy the reason: "Linux is only doing it once".

In this case my worry is not about optimizing because a guest could call 
it often but the fact the you might end up in all the vCPUs but one 
reading GITS_CTLR and one handling the command queue. So formers will 
wait on the lock which will monopolize the pCPUs.


The command queue handling is not ideal (it can take a bit of time), but 
this is going to be worst. And I really don't want to see that.



+*r = vgic_reg64_extract(its->cwriter, info);
+spin_unlock(>vcmd_lock);
+break;
+case VREG64(GITS_CREADR):
+if ( !vgic_reg64_check_access(info->dabt) ) goto bad_width;
+spin_lock(>vcmd_lock);


Ditto.


Currently this does not work because it could read it when creadr
reaches the end of the buffer (before the code above resets it to 0).
But by rewriting that code using a local variable this should be doable.


Please do it.


+
+static int vgic_v3_its_mmio_write(struct vcpu *v, mmio_info_t *info,
+  register_t r, void *priv)
+{
+struct domain *d = v->domain;
+struct virt_its *its = priv;
+uint64_t reg;
+uint32_t reg32, ctlr;
+
+switch ( info->gpa & 0x )
+{
+case VREG32(GITS_CTLR):
+if ( info->dabt.size != DABT_WORD ) goto bad_width;
+
+spin_lock(>vcmd_lock);


I am not sure to understand why taking the vcmd_lock here.


To prevent a nasty guest from turning off the ITS while commands are
still handled.


Please document it.




+spin_lock(>its_lock);
+ctlr = its->enabled ? GITS_CTLR_ENABLE : 0;
+reg32 = ctlr;
+vgic_reg32_update(, r, info);
+
+if ( ctlr ^ reg32 )
+its->enabled = vgic_v3_verify_its_status(its,
+ reg32 &
GITS_CTLR_ENABLE);


Should not you print a warning to help a user debugging if you don't
enable ITS as expected?


Good idea.


Also, how do you disable it?


Not sure what you mean? vgic_v3_verify_its_status() returns false if the
ENABLE_BIT has been cleared, so its->enabled becomes false.
Or what do I miss?


I think I wrote the question and answered myself before sending the 
e-mail. Though I forgot to drop it.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 06/30] ARM: GICv3 ITS: allocate device and collection table

[André Przywara]

On 06/04/17 23:19, Julien Grall wrote:
> Hi Andre,
> 
> On 04/06/2017 12:18 AM, Andre Przywara wrote:
>> Each ITS maps a pair of a DeviceID (for instance derived from a PCI
>> b/d/f triplet) and an EventID (the MSI payload or interrupt ID) to a
>> pair of LPI number and collection ID, which points to the target CPU.
>> This mapping is stored in the device and collection tables, which
>> software
>> has to provide for the ITS to use.
>> Allocate the required memory and hand it over to the ITS.
>>
>> Signed-off-by: Andre Przywara 
>> Reviewed-by: Stefano Stabellini 
>> ---
>>  xen/arch/arm/gic-v3-its.c| 132
>> +++
>>  xen/include/asm-arm/gic_v3_its.h |  32 ++
>>  2 files changed, 164 insertions(+)
>>
>> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
>> index 0298866..eef2933 100644
>> --- a/xen/arch/arm/gic-v3-its.c
>> +++ b/xen/arch/arm/gic-v3-its.c
>> @@ -35,9 +35,109 @@ bool gicv3_its_host_has_its(void)
>>  return !list_empty(_its_list);
>>  }
>>
>> +#define BASER_ATTR_MASK   \
>> +((0x3UL << GITS_BASER_SHAREABILITY_SHIFT)   | \
>> + (0x7UL << GITS_BASER_OUTER_CACHEABILITY_SHIFT) | \
>> + (0x7UL << GITS_BASER_INNER_CACHEABILITY_SHIFT))
>> +#define BASER_RO_MASK   (GENMASK_ULL(58, 56) | GENMASK_ULL(52, 48))
> 
> It is a bit odd that you have defined BASER_RO_MASK and ...
> 
> [...]
> 
>> diff --git a/xen/include/asm-arm/gic_v3_its.h
>> b/xen/include/asm-arm/gic_v3_its.h
>> index 295eb22..6e51b98 100644
>> --- a/xen/include/asm-arm/gic_v3_its.h
>> +++ b/xen/include/asm-arm/gic_v3_its.h
> 
> [...]
> 
>> +#define GITS_BASER_OUTER_CACHEABILITY_SHIFT53
>> +#define GITS_BASER_TYPE_NONE0UL
>> +#define GITS_BASER_TYPE_DEVICE  1UL
>> +#define GITS_BASER_TYPE_VCPU2UL
>> +#define GITS_BASER_TYPE_CPU 3UL
>> +#define GITS_BASER_TYPE_COLLECTION  4UL
>> +#define GITS_BASER_TYPE_RESERVED5   5UL
>> +#define GITS_BASER_TYPE_RESERVED6   6UL
>> +#define GITS_BASER_TYPE_RESERVED7   7UL
>> +#define GITS_BASER_ENTRY_SIZE_SHIFT 48
>> +#define
>> GITS_BASER_ENTRY_SIZE(reg)   \
>> +(((reg >> GITS_BASER_ENTRY_SIZE_SHIFT) &
>> 0x1f) + 1)
>> +#define GITS_BASER_SHAREABILITY_SHIFT   10
>> +#define GITS_BASER_PAGE_SIZE_SHIFT  8
>> +#define GITS_BASER_RO_MASK  (GITS_BASER_TYPE_MASK | \
>> +(31UL <<
>> GITS_BASER_ENTRY_SIZE_SHIFT) |\
>> +GITS_BASER_INDIRECT)
> 
> ... GITS_BASER_RO_MASK which from my understand covers the same
> registers but for different purpose.
> 
> Looking more closely, this last definition should belong to vgic-v3-its.c

Doh, good catch.

Cheers,
Andre


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

Re: [Xen-devel] [PATCH v5 17/30] ARM: vITS: add command handling stub and MMIO emulation

[Julien Grall]

Hi Andre,

On 04/06/2017 12:19 AM, Andre Przywara wrote:

+case VREG64(GITS_BASER0):   /* device table */
+if ( !vgic_reg64_check_access(info->dabt) ) goto bad_width;
+
+spin_lock(>its_lock);
+
+/*
+ * Changing base registers with the ITS enabled is UNPREDICTABLE,
+ * we choose to ignore it, but warn.
+ */
+if ( its->enabled )
+{
+spin_unlock(>its_lock);
+gdprintk(XENLOG_WARNING, "ITS: tried to change BASER with the ITS 
enabled.\n");
+
+return 1;
+}
+
+reg = its->baser_dev;
+vgic_reg64_update(, r, info);
+
+reg &= ~GITS_BASER_RO_MASK;


It took me a bit of time to understand how you ensure the guest will not 
hand over two-level table. But this is hidden in the GITS_BASER_RO_MASK 
as you always mask the indirect bit.


I would prefer if you make clear that two-level table are not currently 
supported with a comment.




+reg |= (sizeof(uint64_t) - 1) << GITS_BASER_ENTRY_SIZE_SHIFT;
+reg |= GITS_BASER_TYPE_DEVICE << GITS_BASER_TYPE_SHIFT;
+sanitize_its_base_reg();
+
+if ( reg & GITS_VALID_BIT )
+its->max_devices = its_baser_nr_entries(reg);
+else
+its->max_devices = 0;
+
+its->baser_dev = reg;
+spin_unlock(>its_lock);
+return 1;
+case VREG64(GITS_BASER1):   /* collection table */
+if ( !vgic_reg64_check_access(info->dabt) ) goto bad_width;
+
+spin_lock(>its_lock);
+/*
+ * Changing base registers with the ITS enabled is UNPREDICTABLE,
+ * we choose to ignore it, but warn.
+ */
+if ( its->enabled )
+{
+spin_unlock(>its_lock);
+gdprintk(XENLOG_INFO, "ITS: tried to change BASER with the ITS 
enabled.\n");
+return 1;
+}
+
+reg = its->baser_coll;
+vgic_reg64_update(, r, info);
+reg &= ~GITS_BASER_RO_MASK;


Ditto.


+reg |= (sizeof(uint16_t) - 1) << GITS_BASER_ENTRY_SIZE_SHIFT;
+reg |= GITS_BASER_TYPE_COLLECTION << GITS_BASER_TYPE_SHIFT;
+sanitize_its_base_reg();
+
+if ( reg & GITS_VALID_BIT )
+its->max_collections = its_baser_nr_entries(reg);
+else
+its->max_collections = 0;
+its->baser_coll = reg;
+spin_unlock(>its_lock);
+return 1;
+case VRANGE64(GITS_BASER2, GITS_BASER7):
+goto write_ignore_64;
+default:
+gdprintk(XENLOG_G_WARNING, "ITS: unhandled ITS register 0x%lx\n",
+ info->gpa & 0x);
+return 0;
+}



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 17/30] ARM: vITS: add command handling stub and MMIO emulation

[André Przywara]

On 06/04/17 22:43, Julien Grall wrote:

Salut Julien,

> On 04/06/2017 12:19 AM, Andre Przywara wrote:
>> Emulate the memory mapped ITS registers and provide a stub to introduce
>> the ITS command handling framework (but without actually emulating any
>> commands at this time).
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/vgic-v3-its.c| 416
>> ++
>>  xen/arch/arm/vgic-v3.c|   9 -
>>  xen/include/asm-arm/gic_v3_defs.h |   9 +
>>  xen/include/asm-arm/gic_v3_its.h  |   3 +
>>  4 files changed, 428 insertions(+), 9 deletions(-)
>>
>> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
>> index 9dfda59..f6bf1ee 100644
>> --- a/xen/arch/arm/vgic-v3-its.c
>> +++ b/xen/arch/arm/vgic-v3-its.c
>> @@ -78,6 +78,422 @@ void vgic_v3_its_free_domain(struct domain *d)
>>  ASSERT(RB_EMPTY_ROOT(>arch.vgic.its_devices));
>>  }
>>
>> +/**
>> + * Functions that handle ITS commands *
>> + **/
>> +
>> +static uint64_t its_cmd_mask_field(uint64_t *its_cmd, unsigned int word,
>> +   unsigned int shift, unsigned int
>> size)
>> +{
>> +return (le64_to_cpu(its_cmd[word]) >> shift) & (BIT(size) - 1);
>> +}
>> +
>> +#define its_cmd_get_command(cmd)its_cmd_mask_field(cmd, 0, 
>> 0,  8)
>> +#define its_cmd_get_deviceid(cmd)   its_cmd_mask_field(cmd, 0,
>> 32, 32)
>> +#define its_cmd_get_size(cmd)   its_cmd_mask_field(cmd, 1, 
>> 0,  5)
>> +#define its_cmd_get_id(cmd) its_cmd_mask_field(cmd, 1, 
>> 0, 32)
>> +#define its_cmd_get_physical_id(cmd)its_cmd_mask_field(cmd, 1,
>> 32, 32)
>> +#define its_cmd_get_collection(cmd) its_cmd_mask_field(cmd, 2, 
>> 0, 16)
>> +#define its_cmd_get_target_addr(cmd)its_cmd_mask_field(cmd, 2,
>> 16, 32)
>> +#define its_cmd_get_validbit(cmd)   its_cmd_mask_field(cmd, 2,
>> 63,  1)
>> +#define its_cmd_get_ittaddr(cmd)(its_cmd_mask_field(cmd, 2,
>> 8, 44) << 8)
>> +
>> +#define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
>> +
>> +/*
>> + * Requires the vcmd_lock to be held.
>> + * TODO: Investigate whether we can be smarter here and don't need to
>> hold
>> + * the lock all of the time.
>> + */
>> +static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its)
>> +{
>> +paddr_t addr = its->cbaser & GENMASK_ULL(51, 12);
>> +uint64_t command[4];
>> +
>> +ASSERT(spin_is_locked(>vcmd_lock));
>> +
>> +if ( its->cwriter >= ITS_CMD_BUFFER_SIZE(its->cbaser) )
>> +return -1;
>> +
>> +while ( its->creadr != its->cwriter )
>> +{
>> +int ret;
>> +
>> +ret = vgic_access_guest_memory(d, addr + its->creadr,
>> +   command, sizeof(command), false);
>> +if ( ret )
>> +return ret;
>> +
>> +switch ( its_cmd_get_command(command) )
>> +{
>> +case GITS_CMD_SYNC:
>> +/* We handle ITS commands synchronously, so we ignore
>> SYNC. */
>> +break;
>> +default:
>> +gdprintk(XENLOG_WARNING, "ITS: unhandled ITS command %lu\n",
>> + its_cmd_get_command(command));
>> +break;
>> +}
>> +
>> +its->creadr += ITS_CMD_SIZE;
>> +if ( its->creadr == ITS_CMD_BUFFER_SIZE(its->cbaser) )
>> +its->creadr = 0;
>> +
>> +if ( ret )
>> +gdprintk(XENLOG_WARNING,
>> + "ITS: ITS command error %d while handling
>> command %lu\n",
>> + ret, its_cmd_get_command(command));
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +/*
>> + * ITS registers read access *
>> + */
>> +
>> +static int vgic_v3_its_mmio_read(struct vcpu *v, mmio_info_t *info,
>> + register_t *r, void *priv)
>> +{
>> +struct virt_its *its = priv;
>> +uint64_t reg;
>> +
>> +switch ( info->gpa & 0x )
>> +{
>> +case VREG32(GITS_CTLR):
>> +if ( info->dabt.size != DABT_WORD ) goto bad_width;
>> +
>> +spin_lock(>vcmd_lock);
>> +spin_lock(>its_lock);
>> +if ( its->enabled )
>> +reg = GITS_CTLR_ENABLE;
>> +else
>> +reg = 0;
>> +
>> +if ( its->cwriter == its->creadr )
> 
> I think it would be better if you can read atomically cwriter and
> creadr.

What do you mean by "atomically" here? For reading and comparing *both*
registers I have to hold a lock, isn't it?

> This would avoid to take the vcmd_lock here, as this would
> prevent a guest vCPU to access this register while you are processing
> the command queue.

That's a noble goal, but I don't know if this is easily feasible.
I wonder if one can use spin_trylock(>vcmd_lock) here, and assume
not quiescent if that fails? My understanding is that an OS would poll
CTLR until it 

Re: [Xen-devel] [PATCH v5 06/30] ARM: GICv3 ITS: allocate device and collection table

[Julien Grall]

Hi Andre,

On 04/06/2017 12:18 AM, Andre Przywara wrote:

Each ITS maps a pair of a DeviceID (for instance derived from a PCI
b/d/f triplet) and an EventID (the MSI payload or interrupt ID) to a
pair of LPI number and collection ID, which points to the target CPU.
This mapping is stored in the device and collection tables, which software
has to provide for the ITS to use.
Allocate the required memory and hand it over to the ITS.

Signed-off-by: Andre Przywara 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/gic-v3-its.c| 132 +++
 xen/include/asm-arm/gic_v3_its.h |  32 ++
 2 files changed, 164 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 0298866..eef2933 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -35,9 +35,109 @@ bool gicv3_its_host_has_its(void)
 return !list_empty(_its_list);
 }

+#define BASER_ATTR_MASK   \
+((0x3UL << GITS_BASER_SHAREABILITY_SHIFT)   | \
+ (0x7UL << GITS_BASER_OUTER_CACHEABILITY_SHIFT) | \
+ (0x7UL << GITS_BASER_INNER_CACHEABILITY_SHIFT))
+#define BASER_RO_MASK   (GENMASK_ULL(58, 56) | GENMASK_ULL(52, 48))


It is a bit odd that you have defined BASER_RO_MASK and ...

[...]


diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index 295eb22..6e51b98 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h


[...]


+#define GITS_BASER_OUTER_CACHEABILITY_SHIFT53
+#define GITS_BASER_TYPE_NONE0UL
+#define GITS_BASER_TYPE_DEVICE  1UL
+#define GITS_BASER_TYPE_VCPU2UL
+#define GITS_BASER_TYPE_CPU 3UL
+#define GITS_BASER_TYPE_COLLECTION  4UL
+#define GITS_BASER_TYPE_RESERVED5   5UL
+#define GITS_BASER_TYPE_RESERVED6   6UL
+#define GITS_BASER_TYPE_RESERVED7   7UL
+#define GITS_BASER_ENTRY_SIZE_SHIFT 48
+#define GITS_BASER_ENTRY_SIZE(reg)   \
+(((reg >> GITS_BASER_ENTRY_SIZE_SHIFT) & 0x1f) + 1)
+#define GITS_BASER_SHAREABILITY_SHIFT   10
+#define GITS_BASER_PAGE_SIZE_SHIFT  8
+#define GITS_BASER_RO_MASK  (GITS_BASER_TYPE_MASK | \
+(31UL << GITS_BASER_ENTRY_SIZE_SHIFT) 
|\
+GITS_BASER_INDIRECT)


... GITS_BASER_RO_MASK which from my understand covers the same 
registers but for different purpose.


Looking more closely, this last definition should belong to vgic-v3-its.c

Cheers,

--
Julien Grall

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 80c4b236389fb246dfd5c4f28e625600974a575d
baseline version:
 ovmf 83ae7589b08a0d11592527cf45fd1ad8d62118ab

Last test of basis71150  2017-04-05 10:47:00 Z1 days
Testing same since71157  2017-04-06 07:47:55 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Dandan Bi 
  Hess Chen 
  Jeff Fan 
  Laszlo Ersek 
  Ruiyu Ni 

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 80c4b236389fb246dfd5c4f28e625600974a575d
Author: Jeff Fan 
Date:   Wed Apr 5 16:33:16 2017 +0800

UefiCpuPkg/CpuFeatures: Change files format to DOS

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
Reviewed-by: Star Zeng 

commit 028db58d1f5aebb973a00dd30118f05f6284e5c4
Author: Ruiyu Ni 
Date:   Wed Apr 5 13:56:30 2017 +0800

ShellPkg/setvar: Add assertion indicating TempData shouldn't be NULL

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 

commit 3ff1e8987b0b6dd82cdda8f02127582caace57d6
Author: Dandan Bi 
Date:   Wed Apr 5 09:00:01 2017 +0800

UefiCpuPkg/MtrrLib:Fix VS2012 build failure

Cc: Ruiyu Ni 
Cc: Jeff Fan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Ruiyu Ni 

commit fe4a28ccbfd33cae9e1f56b174d46b4eb2329efd
Author: Dandan Bi 
Date:   Sat Apr 1 10:31:14 2017 +0800

MdeModulePkg/UefiHiiLib:Fix incorrect comparison expression

Fix the incorrect comparison between pointer and constant zero character.

https://bugzilla.tianocore.org/show_bug.cgi?id=416

V2: The pointer StringPtr points to a string returned
by ExtractConfig/ExportConfig, if it is NULL, function
InternalHiiIfrValueAction will return FALSE. So in
current usage model, the StringPtr can not be NULL before
using it, so we can add ASSERT here.

Cc: Eric Dong 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Eric Dong 

commit 490433ab847cf318f31f73bbbc1a503ae47370a4
Author: Hess Chen 
Date:   Sat Apr 1 13:33:05 2017 +0800

BaseTools/UPT: Fix a parser issue

Update the method to get PCD information and support empty section.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hess Chen 
Reviewed-by: Yonghong Zhu 

commit 09e27ac559c5538a0b86afb0b056ef2a3f705483
Author: Hess Chen 
Date:   Sat Apr 1 13:33:04 2017 +0800

BaseTools/UPT: Support Unicode path

Update the IpiDb.py to support Unicode path for localization

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hess Chen 
Reviewed-by: Yonghong Zhu 

commit 5692fa883f4e2583bbef9aae4082b87515ae51e1
Author: Hess Chen 
Date:   Sat Apr 1 13:33:03 2017 +0800

BaseTools/UPT: Use a simple way to get package path

Instead of parsing all content of DEC file, just 

Re: [Xen-devel] [PATCH v5 17/30] ARM: vITS: add command handling stub and MMIO emulation

[Julien Grall]

Hi Andre,

On 04/06/2017 12:19 AM, Andre Przywara wrote:

Emulate the memory mapped ITS registers and provide a stub to introduce
the ITS command handling framework (but without actually emulating any
commands at this time).

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c| 416 ++
 xen/arch/arm/vgic-v3.c|   9 -
 xen/include/asm-arm/gic_v3_defs.h |   9 +
 xen/include/asm-arm/gic_v3_its.h  |   3 +
 4 files changed, 428 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 9dfda59..f6bf1ee 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -78,6 +78,422 @@ void vgic_v3_its_free_domain(struct domain *d)
 ASSERT(RB_EMPTY_ROOT(>arch.vgic.its_devices));
 }

+/**
+ * Functions that handle ITS commands *
+ **/
+
+static uint64_t its_cmd_mask_field(uint64_t *its_cmd, unsigned int word,
+   unsigned int shift, unsigned int size)
+{
+return (le64_to_cpu(its_cmd[word]) >> shift) & (BIT(size) - 1);
+}
+
+#define its_cmd_get_command(cmd)its_cmd_mask_field(cmd, 0,  0,  8)
+#define its_cmd_get_deviceid(cmd)   its_cmd_mask_field(cmd, 0, 32, 32)
+#define its_cmd_get_size(cmd)   its_cmd_mask_field(cmd, 1,  0,  5)
+#define its_cmd_get_id(cmd) its_cmd_mask_field(cmd, 1,  0, 32)
+#define its_cmd_get_physical_id(cmd)its_cmd_mask_field(cmd, 1, 32, 32)
+#define its_cmd_get_collection(cmd) its_cmd_mask_field(cmd, 2,  0, 16)
+#define its_cmd_get_target_addr(cmd)its_cmd_mask_field(cmd, 2, 16, 32)
+#define its_cmd_get_validbit(cmd)   its_cmd_mask_field(cmd, 2, 63,  1)
+#define its_cmd_get_ittaddr(cmd)(its_cmd_mask_field(cmd, 2, 8, 44) << 
8)
+
+#define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
+
+/*
+ * Requires the vcmd_lock to be held.
+ * TODO: Investigate whether we can be smarter here and don't need to hold
+ * the lock all of the time.
+ */
+static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its)
+{
+paddr_t addr = its->cbaser & GENMASK_ULL(51, 12);
+uint64_t command[4];
+
+ASSERT(spin_is_locked(>vcmd_lock));
+
+if ( its->cwriter >= ITS_CMD_BUFFER_SIZE(its->cbaser) )
+return -1;
+
+while ( its->creadr != its->cwriter )
+{
+int ret;
+
+ret = vgic_access_guest_memory(d, addr + its->creadr,
+   command, sizeof(command), false);
+if ( ret )
+return ret;
+
+switch ( its_cmd_get_command(command) )
+{
+case GITS_CMD_SYNC:
+/* We handle ITS commands synchronously, so we ignore SYNC. */
+break;
+default:
+gdprintk(XENLOG_WARNING, "ITS: unhandled ITS command %lu\n",
+ its_cmd_get_command(command));
+break;
+}
+
+its->creadr += ITS_CMD_SIZE;
+if ( its->creadr == ITS_CMD_BUFFER_SIZE(its->cbaser) )
+its->creadr = 0;
+
+if ( ret )
+gdprintk(XENLOG_WARNING,
+ "ITS: ITS command error %d while handling command %lu\n",
+ ret, its_cmd_get_command(command));
+}
+
+return 0;
+}
+
+/*
+ * ITS registers read access *
+ */
+
+static int vgic_v3_its_mmio_read(struct vcpu *v, mmio_info_t *info,
+ register_t *r, void *priv)
+{
+struct virt_its *its = priv;
+uint64_t reg;
+
+switch ( info->gpa & 0x )
+{
+case VREG32(GITS_CTLR):
+if ( info->dabt.size != DABT_WORD ) goto bad_width;
+
+spin_lock(>vcmd_lock);
+spin_lock(>its_lock);
+if ( its->enabled )
+reg = GITS_CTLR_ENABLE;
+else
+reg = 0;
+
+if ( its->cwriter == its->creadr )


I think it would be better if you can read atomically cwriter and 
creadr. This would avoid to take the vcmd_lock here, as this would 
prevent a guest vCPU to access this register while you are processing 
the command queue.



+reg |= GITS_CTLR_QUIESCENT;
+spin_unlock(>its_lock);
+spin_unlock(>vcmd_lock);
+
+*r = vgic_reg32_extract(reg, info);
+break;
+case VREG32(GITS_IIDR):
+if ( info->dabt.size != DABT_WORD ) goto bad_width;
+*r = vgic_reg32_extract(GITS_IIDR_VALUE, info);
+break;
+case VREG64(GITS_TYPER):
+if ( !vgic_reg64_check_access(info->dabt) ) goto bad_width;
+
+reg = GITS_TYPER_PHYSICAL;
+reg |= (sizeof(struct vits_itte) - 1) << GITS_TYPER_ITT_SIZE_SHIFT;
+reg |= (its->intid_bits - 1) << GITS_TYPER_IDBITS_SHIFT;
+reg |= (its->devid_bits - 1) << GITS_TYPER_DEVIDS_SHIFT;
+*r = vgic_reg64_extract(reg, info);
+break;
+case 

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

[Stefano Stabellini]

On Thu, 6 Apr 2017, Volodymyr Babchuk wrote:
> Hello all,
> 
> I want to discuss EL0 (native) applications for XEN. This will be relatively
> long e-mail with requirements, proposed design and my PoC results.
> 
> So, why we want XEN native applications in the first place? I see the 
> following
> reasons:
> 
> 1. Isolation. I see XEN as a sort of micro-kernel, so there are no place for
> device drivers, emulators, specific SMC handlers, hypervisor extension, etc..
> 
> 2. Modularity. Just look at Linux kernel. Obviously, for different devices we
> can load different drivers.
> 
> 3. Performance. Native application should be faster than stub domain, or there
> will be no sense in it.
> 
> 4. Ease of use. I want to make call to EL0 app as easy as possible.
> Ideally - as a function call.
> 
> Actually, no one wants extra code in hypervisor, so reasons (1) and (2) are 
> most
> important. I know that there was tries to do such thing in x86 but with
> different approach. I want describe my idea for arm64.
> 
> Native application is an another domain type. It has own vCPU (only one at 
> this
> moment) Native app is loaded as any other kernel, using ELF loader.
> It looks like another stub-domain such as MiniOS, but there are two big
> differences:

Could you describe the reason why you are suggesting it? Unless strictly
necessary, I wouldn't go down the vcpu route, because as soon as we
bring a vcpu into the picture, we have a number of problems, including
scheduling, affinity, etc. It is also user-visible (xl vcpu-list) which
I don't think it should be.

I understand that one of the goals is "Modularity", which makes us think
of an ELF loader, such as the one for a new domain. I agree that
modularity is important, but I would solve it as a second step. In first
instance, I would limit the scope to run some code under
/xen/arch/arm/apps or, better, /apps (for example) in a lower privilege
mode. After that is done and working, I am sure we can find a way to
dynamically load more apps at run time.

 
> 1. MiniOS has event loop that serves requests from hypervisor. Native
> application does not has such loop. It has one entry point where you jump 
> every
> time when you need something from it.
> 
> 2. Native application runs in EL0 mode, so it does not have access to MMU,
> it can't handle vIQRs, exceptions and so on. XEN does all this for it.
>
> You can find example native application at [1]. I used exactly this one to
> benchmark my implementation. Mostly it is inspired by approach used in TEE.
> Actually, I took some code directly from OP-TEE Trusted Application library.
> In app_entry.c you can find entry point - __app_entry(). It takes function
> number and some parameters that will be passed to a function. I probably going
> to change ABI a bit, but basic idea will be the same.
> 
> Function number will be something like APP_INIT, APP_HANDLE_SMC
> or APP_HANDLE_MMIO... I think you got the idea. I also implemented two 
> syscalls
> (via old plain SVC instruction). app_log() writes to XEN log, app_return() 
> exits
> from application back to hypervisor. We will need other syscalls like
> app_call_smc(), app_map_guest_page(), app_map_io(), etc.
> 
> Now, back to XEN. Classic way to handle something with stubdomain is to
> write request to a ring buffer, fire an event through event channel, that will
> trigger vIRQ in stubdomain and stubdomain's vCPU will be scheduled to handle
> a request. Problem it that you can't control scheduler, so you don't know
> when your request will be really handled, which in not fine in some
> embedded use cases.
> 
> There is how I see handling requests with native application:
> 
> 0. Hypervisor pauses requester vCPU
> 1. Hypervisor either passes parameters via registers or writes request to a
> shared page/ring buffer.
> 2. Then in sets PC of native app vCPU to entry point and initializes r0-r7
> with function code and other parameters.
> 3. Hypervisor switches context to native app vCPU
> 4. When native app finishes request handling it calls special syscall 
> app_exit()
> 5. Hypervisor analyses return code, updates requester vCPU state (if needed),
> switches back to that vCPU, unpauses it.
> 
> Most of that was done at [2]. Most interesting part is in arch/arm/domain.c
> There are functions call_el0_app() and return_from_el0_app() that do most
> of the work. Also I have added syscalls handlers (in the same way,
> as hypercalls are handled). You can find them at xen/arch/arm/syscall.c

This workflow is actually kind of OK. I would not use the term "vcpu"
for anything related to an el0 app. Maybe we need to introduce a new
concept, such as "app_context" for example. But I would not want to
confuse "vcpu" which is the runtime environment exposed to guests, with
the el0 Xen context.

A vcpu is expected to be running simultenously with other vcpus of the
same domain or different domains. The scheduler is expected to choose
when it is supposed to be running. On the other end, 

[Xen-devel] [distros-debian-wheezy test] 71156: tolerable trouble: broken/pass

[Platform Team regression test user]

flight 71156 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71156/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass

baseline version:
 flight   71123

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass
 test-amd64-i386-i386-wheezy-netboot-pvgrub   pass
 test-amd64-i386-amd64-wheezy-netboot-pygrub  pass
 test-amd64-amd64-i386-wheezy-netboot-pygrub  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.


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

Re: [Xen-devel] [PATCH v5 16/30] ARM: vGICv3: handle disabled LPIs

[Julien Grall]

Hi Andre,

On 04/06/2017 12:19 AM, Andre Przywara wrote:

If a guest disables an LPI, we do not forward this to the associated
host LPI to avoid queueing commands to the host ITS command queue.
So it may happen that an LPI fires nevertheless on the host. In this
case we can bail out early, but have to save the pending state on the
virtual side. We do this by storing the pending bit in struct
pending_irq, which is assiociated with mapped LPIs.


s/assiociated/associated/

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 16/30] ARM: vGICv3: handle disabled LPIs

[Stefano Stabellini]

On Thu, 6 Apr 2017, Andre Przywara wrote:
> On 06/04/17 00:58, Stefano Stabellini wrote:
> > On Thu, 6 Apr 2017, Andre Przywara wrote:
> >> If a guest disables an LPI, we do not forward this to the associated
> >> host LPI to avoid queueing commands to the host ITS command queue.
> >> So it may happen that an LPI fires nevertheless on the host. In this
> >> case we can bail out early, but have to save the pending state on the
> >> virtual side. We do this by storing the pending bit in struct
> >> pending_irq, which is assiociated with mapped LPIs.
> >>
> >> Signed-off-by: Andre Przywara 
> >> ---
> >>  xen/arch/arm/gic-v3-lpi.c | 26 +-
> >>  1 file changed, 25 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
> >> index d8baebc..7d20986 100644
> >> --- a/xen/arch/arm/gic-v3-lpi.c
> >> +++ b/xen/arch/arm/gic-v3-lpi.c
> >> @@ -136,6 +136,22 @@ uint64_t gicv3_get_redist_address(unsigned int cpu, 
> >> bool use_pta)
> >>  return per_cpu(lpi_redist, cpu).redist_id << 16;
> >>  }
> >>  
> >> +static bool vgic_can_inject_lpi(struct vcpu *vcpu, uint32_t vlpi)
> >> +{
> >> +struct pending_irq *p;
> >> +
> >> +p = vcpu->domain->arch.vgic.handler->lpi_to_pending(vcpu->domain, 
> >> vlpi);
> >> +if ( !p )
> >> +return false;
> >> +
> >> +if ( test_bit(GIC_IRQ_GUEST_ENABLED, >status) )
> >> +return true;
> >> +
> >> +set_bit(GIC_IRQ_GUEST_LPI_PENDING, >status);
> > 
> > See alpine.DEB.2.10.1701051422020.2866@sstabellini-ThinkPad-X260
> 
> (from this email:)
> > I suggest vgic_can_inject_lpi doesn't only return true or false, but
> > also if the vlpi is already set to pending. In that case, I think we
> > should disable the plpi to avoid storms (also see
> > http://marc.info/?l=xen-devel=148055519432739).
> 
> So I can surely change the function to return that information, but I
> think we don't have a good way of handling the storm easily.
> First sending the required INV command to let the host know about our
> change to the property table might take some time (we have a timeout in
> there), also takes a spinlock. Which doesn't sound too good in the
> interrupt injection path.
> But secondly re-enabling the interrupt is not easily possible currently.
> Ideally one would expect this to happen when the guest enables the
> corresponding virtual LPI, but that would again require to send an INV
> command to the host ITS, which is something that we avoid when triggered
> by a guest (the MAPD exception is only for Dom0 and will hopefully go
> away later).
> So a guest could send virtual INVs (disabling and enabling the virtual
> LPI) and trying to flood the host command queue.

I was thinking of clearing the enable bit in the LPI configuration table
for the physical LPI, and clearing GIC_IRQ_GUEST_ENABLED. We need to set
a new flag to say "this LPI has been forcefully disabled." Re- enabling
the LPI is not as important, but it could be done on EOI
(gic_update_one_lr).


> So shall I change the function anyway and add a TODO comment, so that we
> can later revisit this scenario?

That would be the minimum requirement for me, adding a reference to
http://marc.info/?l=xen-devel=148055519432739.

 
> >> +return false;
> >> +}
> >> +
> >>  /*
> >>   * Handle incoming LPIs, which are a bit special, because they are 
> >> potentially
> >>   * numerous and also only get injected into guests. Treat them specially 
> >> here,
> >> @@ -187,7 +203,15 @@ void gicv3_do_LPI(unsigned int lpi)
> >>  
> >>  /* Check if the VCPU is ready to receive LPIs. */
> >>  if ( vcpu->arch.vgic.flags & VGIC_V3_LPIS_ENABLED )
> >> -vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);
> >> +{
> >> +/*
> >> + * We keep all host LPIs enabled, so check if it's disabled on the
> >> + * guest side and just record this LPI in the virtual pending 
> >> table
> >> + * in this case. The guest picks it up once it gets enabled again.
> >> + */
> >> +if ( vgic_can_inject_lpi(vcpu, hlpi.virt_lpi) )
> >> +vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);
> >> +}
> >>  
> >>  rcu_unlock_domain(d);
> >>  }
> >> -- 
> >> 2.8.2
> >>
> 

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

Re: [Xen-devel] Shattering superpages impact on IOMMU in Xen

[Julien Grall]

Hi Oleksandr,

Please try to configure the mail client to quote with '>'. Using tab for 
quoting make it quite difficult to follow.


On 04/06/2017 09:36 PM, Oleksandr Tyshchenko wrote:

6 апр. 2017 г. 22:22 пользователь "Julien Grall" > написал:
If the IOMMU is not able to snoop the cache, then the way forward is
to use a clean_dcache operation after writing a page table entry.
This is how we deal in the p2m code.

Agree.

As we update page table in an atomic way (no BBM sequence) and the
reason caused page faults was found, I think that the IPMMU driver can
declare superpage capability?


Yes for the IPMMU driver. Although we would have to do some things for 
the SMMU driver.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] Shattering superpages impact on IOMMU in Xen

[Oleksandr Tyshchenko]

6 апр. 2017 г. 22:22 пользователь "Julien Grall" 
написал:

Hi Oleksandr,

Hi Julien.



On 04/06/2017 07:59 PM, Oleksandr Tyshchenko wrote:

> Hi, guys.
>
> Seems, it was only my fault. The issue wasn't exactly in shattering,
> the shattering just increased probability for IOMMU page faults to
> occur. I didn't do clean_dcache for the page table entry after
> updating it. So, with clean_dcache I don't see page faults when
> shattering superpages!
> BTW, can I configure domheap pages (which I am using for the IOMMU
> page table) to be uncached? What do you think?
>

I am not sure if you suggest to configure all the domheap pages to be
uncached or only a limited number.

I meant a limited number. Only pages the IOMMU page table was built from.


In the case where you switch all domheap to uncached, you will have some
trouble when copy data to/from the guest in hypercall because of mismatch
attribute.

In the case where you only configure some of the domheap pages, you will
remove the advantage of 1GB mapping of the domheap in the hypervisor table
and will increase the memory usage of Xen. Also, you will have to be
careful when switching back and forth the domheap memory attribute between
cache and uncache.

I got it. For me this means that performing cache flush after updating page
table entry is the safest and easiest way.


If the IOMMU is not able to snoop the cache, then the way forward is to use
a clean_dcache operation after writing a page table entry. This is how we
deal in the p2m code.

Agree.

As we update page table in an atomic way (no BBM sequence) and the reason
caused page faults was found, I think that the IPMMU driver can declare
superpage capability?

Thank you.


Cheers,

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

Re: [Xen-devel] [PATCH v5 15/30] ARM: vGICv3: handle virtual LPI pending and property tables

[Julien Grall]

Hi Andre,

On 04/06/2017 12:19 AM, Andre Przywara wrote:

Allow a guest to provide the address and size for the memory regions
it has reserved for the GICv3 pending and property tables.
We sanitise the various fields of the respective redistributor
registers and map those pages into Xen's address space to have easy
access.
This introduces a function to read and write from and to guest memory,
to be later able to access the tables located there.
This vgic_access_guest_memory() function has been written by Vijaya Kumar
as part of an earlier series.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3.c   | 152 ++-
 xen/arch/arm/vgic.c  |  39 +++
 xen/include/asm-arm/domain.h |   6 +-
 xen/include/asm-arm/vgic.h   |   3 +
 4 files changed, 182 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 2a14305..0623803 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -19,12 +19,14 @@
  */

 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -228,12 +230,21 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 goto read_reserved;

 case VREG64(GICR_PROPBASER):
-/* LPI's not implemented */
-goto read_as_zero_64;
+if ( !vgic_reg64_check_access(dabt) ) goto bad_width;


As discussed f2f, I would like to see this code gated with "if has_its" 
for now.


By that I mean:

if ( !has_its )
  goto read_as_zero_64;


+
+spin_lock(>arch.vgic.lock);


The locking looks wrong to me. rdist_probase is per domain but you take 
the vCPU vgic lock.


You likely want to take the domain vgic lock. e.g:

vgic_lock(v);


+*r = vgic_reg64_extract(v->domain->arch.vgic.rdist_propbase, info);


NIT: It would simplify the code if you introduce a temporary variable d 
to store v->domain.



+spin_unlock(>arch.vgic.lock);
+return 1;

 case VREG64(GICR_PENDBASER):
-/* LPI's not implemented */
-goto read_as_zero_64;


Same here.


+if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
+
+spin_lock(>arch.vgic.lock);
+*r = vgic_reg64_extract(v->arch.vgic.rdist_pendbase, info);
+*r &= ~GICR_PENDBASER_PTZ;   /* WO, reads as 0 */
+spin_unlock(>arch.vgic.lock);
+return 1;

 case 0x0080:
 goto read_reserved;
@@ -301,11 +312,6 @@ bad_width:
 domain_crash_synchronous();
 return 0;

-read_as_zero_64:
-if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
-*r = 0;
-return 1;
-
 read_as_zero_32:
 if ( dabt.size != DABT_WORD ) goto bad_width;
 *r = 0;
@@ -330,11 +336,95 @@ read_unknown:
 return 1;
 }

+static uint64_t vgic_sanitise_field(uint64_t reg, uint64_t field_mask,
+int field_shift,
+uint64_t (*sanitise_fn)(uint64_t))
+{
+uint64_t field = (reg & field_mask) >> field_shift;
+
+field = sanitise_fn(field) << field_shift;
+
+return (reg & ~field_mask) | field;
+}
+
+/* We want to avoid outer shareable. */
+static uint64_t vgic_sanitise_shareability(uint64_t field)
+{
+switch ( field )
+{
+case GIC_BASER_OuterShareable:
+return GIC_BASER_InnerShareable;
+default:
+return field;
+}
+}
+
+/* Avoid any inner non-cacheable mapping. */
+static uint64_t vgic_sanitise_inner_cacheability(uint64_t field)
+{
+switch ( field )
+{
+case GIC_BASER_CACHE_nCnB:
+case GIC_BASER_CACHE_nC:
+return GIC_BASER_CACHE_RaWb;
+default:
+return field;
+}
+}
+
+/* Non-cacheable or same-as-inner are OK. */
+static uint64_t vgic_sanitise_outer_cacheability(uint64_t field)
+{
+switch ( field )
+{
+case GIC_BASER_CACHE_SameAsInner:
+case GIC_BASER_CACHE_nC:
+return field;
+default:
+return GIC_BASER_CACHE_nC;
+}
+}
+
+static uint64_t sanitize_propbaser(uint64_t reg)
+{
+reg = vgic_sanitise_field(reg, GICR_PROPBASER_SHAREABILITY_MASK,
+  GICR_PROPBASER_SHAREABILITY_SHIFT,
+  vgic_sanitise_shareability);
+reg = vgic_sanitise_field(reg, GICR_PROPBASER_INNER_CACHEABILITY_MASK,
+  GICR_PROPBASER_INNER_CACHEABILITY_SHIFT,
+  vgic_sanitise_inner_cacheability);
+reg = vgic_sanitise_field(reg, GICR_PROPBASER_OUTER_CACHEABILITY_MASK,
+  GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT,
+  vgic_sanitise_outer_cacheability);
+
+reg &= ~GICR_PROPBASER_RES0_MASK;
+
+return reg;
+}
+
+static uint64_t sanitize_pendbaser(uint64_t reg)
+{
+reg = vgic_sanitise_field(reg, GICR_PENDBASER_SHAREABILITY_MASK,
+  GICR_PENDBASER_SHAREABILITY_SHIFT,
+ 

Re: [Xen-devel] [PATCH v5 13/30] ARM: GICv3: forward pending LPIs to guests

[Stefano Stabellini]

On Thu, 6 Apr 2017, Julien Grall wrote:
> Hi Stefano,
> 
> On 04/06/2017 08:47 PM, Stefano Stabellini wrote:
> > On Thu, 6 Apr 2017, Julien Grall wrote:
> > > On 04/06/2017 07:47 PM, Stefano Stabellini wrote:
> > > > On Thu, 6 Apr 2017, Andre Przywara wrote:
> > > > > > >  unsigned long status;
> > > > > > >  struct irq_desc *desc; /* only set it the irq corresponds to
> > > > > > > a
> > > > > > > physical irq */
> > > > > > >  unsigned int irq;
> > > > > > >  #define GIC_INVALID_LR (uint8_t)~0
> > > > > > >  uint8_t lr;
> > > > > > >  uint8_t priority;
> > > > > > > +uint8_t lpi_priority;   /* Caches the priority if this is
> > > > > > > an
> > > > > > > LPI. */
> > > > > > 
> > > > > > The commit message says: "we enhance struct pending_irq to cache the
> > > > > > pending bit and the priority information for LPIs, as we can't
> > > > > > afford to
> > > > > > walk the tables in guest memory every time we handle an incoming
> > > > > > LPI." I
> > > > > > thought it would be direct access, having the vlpi number in our
> > > > > > hands?
> > > > > > Why is it a problem?
> > > > > > 
> > > > > > If there has been a conversation about this that I am missing,
> > > > > > please
> > > > > > provide a link, I'll go back and read it.
> > > > > 
> > > > > Well, the property table is in guest memory as the other ITS tables
> > > > > and
> > > > > we now access this in a new way (vgic_access_guest_memory()), which is
> > > > > quite costly: we need to do the p2m lookup, map the page, access the
> > > > > data, unmap the page and put the page back.
> > > > 
> > > > map, unmap and put are (almost) nop. The only operation is the
> > > > p2m_lookup that could be easily avoided by storing the struct page_info*
> > > > or mfn corresponding to the guest-provided data structures. We should be
> > > > able to do this in a very small number of steps, right?
> > > 
> > > The property table could be really big (up to the number of LPIs supported
> > > by
> > > the guest). The memory is contiguous from a domain point of view but not
> > > necessarily on the host. So you would have to store a big number of MFN.
> > > IIRC
> > > the property table can be up to 4GB, so we would need an array of 8MB.
> > 
> > Yes, but in that scenario, with so many LPIs, the new lpi_priority field
> > will use overall 4GB. In comparison 8MB sounds awesome. But I didn't
> > notice that it was using the padding space.
> > 
> > 
> > > Also reading from the guest would require some safety which is not
> > > necessary
> > > here.
> > > 
> > > Furthermore, we have space in pending_irq because of padding.
> > > 
> > > So why bothering doing that?
> > 
> > I didn't notice that it was taking over some of the padding. That is
> > much better. I can live with it then.
> 
> Would a comment /* This field is only used for caching LPI priority. This
> could be removed and read from the guest memory if we need space. */ be
> useful?

No need for a comment but the following sentence in the commit message
is a bit misleading:

"as we can't afford to walk the tables in guest memory every time we
handle an incoming LPI."

I would just rewrite it to say that it's faster than accessing guest
tables, and it doesn't require any more memory as we are exploiting some
of the bytes used for padding.

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

[Xen-devel] [ARM] Native application design and discussion (I hope)

[Volodymyr Babchuk]

Hello all,

I want to discuss EL0 (native) applications for XEN. This will be relatively
long e-mail with requirements, proposed design and my PoC results.

So, why we want XEN native applications in the first place? I see the following
reasons:

1. Isolation. I see XEN as a sort of micro-kernel, so there are no place for
device drivers, emulators, specific SMC handlers, hypervisor extension, etc..

2. Modularity. Just look at Linux kernel. Obviously, for different devices we
can load different drivers.

3. Performance. Native application should be faster than stub domain, or there
will be no sense in it.

4. Ease of use. I want to make call to EL0 app as easy as possible.
Ideally - as a function call.

Actually, no one wants extra code in hypervisor, so reasons (1) and (2) are most
important. I know that there was tries to do such thing in x86 but with
different approach. I want describe my idea for arm64.

Native application is an another domain type. It has own vCPU (only one at this
moment) Native app is loaded as any other kernel, using ELF loader.
It looks like another stub-domain such as MiniOS, but there are two big
differences:

1. MiniOS has event loop that serves requests from hypervisor. Native
application does not has such loop. It has one entry point where you jump every
time when you need something from it.

2. Native application runs in EL0 mode, so it does not have access to MMU,
it can't handle vIQRs, exceptions and so on. XEN does all this for it.

You can find example native application at [1]. I used exactly this one to
benchmark my implementation. Mostly it is inspired by approach used in TEE.
Actually, I took some code directly from OP-TEE Trusted Application library.
In app_entry.c you can find entry point - __app_entry(). It takes function
number and some parameters that will be passed to a function. I probably going
to change ABI a bit, but basic idea will be the same.

Function number will be something like APP_INIT, APP_HANDLE_SMC
or APP_HANDLE_MMIO... I think you got the idea. I also implemented two syscalls
(via old plain SVC instruction). app_log() writes to XEN log, app_return() exits
from application back to hypervisor. We will need other syscalls like
app_call_smc(), app_map_guest_page(), app_map_io(), etc.

Now, back to XEN. Classic way to handle something with stubdomain is to
write request to a ring buffer, fire an event through event channel, that will
trigger vIRQ in stubdomain and stubdomain's vCPU will be scheduled to handle
a request. Problem it that you can't control scheduler, so you don't know
when your request will be really handled, which in not fine in some
embedded use cases.

There is how I see handling requests with native application:

0. Hypervisor pauses requester vCPU
1. Hypervisor either passes parameters via registers or writes request to a
shared page/ring buffer.
2. Then in sets PC of native app vCPU to entry point and initializes r0-r7
with function code and other parameters.
3. Hypervisor switches context to native app vCPU
4. When native app finishes request handling it calls special syscall app_exit()
5. Hypervisor analyses return code, updates requester vCPU state (if needed),
switches back to that vCPU, unpauses it.

Most of that was done at [2]. Most interesting part is in arch/arm/domain.c
There are functions call_el0_app() and return_from_el0_app() that do most
of the work. Also I have added syscalls handlers (in the same way,
as hypercalls are handled). You can find them at xen/arch/arm/syscall.c

At this moment entry point is hardcoded and you need to update it every time
you rebuild native application. Also there are no actual parameters passed.
Also, whole code is a piece of gosa, because it was first time I hacked XEN.

I don't want to repeat benchmark results, because they already was posted in ML.
You can find them at [3].

I understand that I have missed many things:

1. How to ship and load native app, because some of them will be needed even
before dom0 is created.

2. How to distinguish multiple native apps

3. Concurrency in native apps

4. How to restart misbehaved apps.

But at this moment I want to discuss basic approach. If there are will be no
objections against basic concept, then we can develop details.

[1] https://github.com/lorc/xen_app_stub - native app
[2] https://github.com/lorc/xen/tree/el0_app - my branch with PoC
[3] http://marc.info/?l=xen-devel=149088856116797=2 - benchmark results


-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babc...@gmail.com

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 11 guest-start  fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale  11 guest-start   fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-armhf-armhf-libvirt-raw  9 debian-di-install   fail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 11 guest-start  fail   never pass
 test-arm64-arm64-xl-xsm  11 guest-start  fail   never pass
 test-arm64-arm64-xl-multivcpu 11 guest-start  fail  never pass
 test-arm64-arm64-xl  11 guest-start  fail   never pass
 test-arm64-arm64-xl-credit2  11 guest-start  fail   never pass
 test-arm64-arm64-xl-rtds 11 guest-start  fail   never pass
 test-arm64-arm64-libvirt-xsm 11 guest-start  fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2  9 debian-di-installfail never pass

version targeted for testing:
 linuxaeb4a5768179f525dd7ec9393f34012c147e78cf
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  637 days
Failing since 59348  2015-07-10 04:24:05 Z  636 days  378 attempts
Testing same since   107221  2017-04-06 00:12:18 Z0 days1 attempts


8136 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  pass
 build-i386-rumprun   pass
 test-amd64-amd64-xl  pass
 test-arm64-arm64-xl  fail
 test-armhf-armhf-xl  fail
 test-amd64-i386-xl   pass
 

Re: [Xen-devel] [PATCH v5 13/30] ARM: GICv3: forward pending LPIs to guests

[Julien Grall]

Hi Stefano,

On 04/06/2017 08:47 PM, Stefano Stabellini wrote:

On Thu, 6 Apr 2017, Julien Grall wrote:

On 04/06/2017 07:47 PM, Stefano Stabellini wrote:

On Thu, 6 Apr 2017, Andre Przywara wrote:

 unsigned long status;
 struct irq_desc *desc; /* only set it the irq corresponds to a
physical irq */
 unsigned int irq;
 #define GIC_INVALID_LR (uint8_t)~0
 uint8_t lr;
 uint8_t priority;
+uint8_t lpi_priority;   /* Caches the priority if this is an
LPI. */


The commit message says: "we enhance struct pending_irq to cache the
pending bit and the priority information for LPIs, as we can't afford to
walk the tables in guest memory every time we handle an incoming LPI." I
thought it would be direct access, having the vlpi number in our hands?
Why is it a problem?

If there has been a conversation about this that I am missing, please
provide a link, I'll go back and read it.


Well, the property table is in guest memory as the other ITS tables and
we now access this in a new way (vgic_access_guest_memory()), which is
quite costly: we need to do the p2m lookup, map the page, access the
data, unmap the page and put the page back.


map, unmap and put are (almost) nop. The only operation is the
p2m_lookup that could be easily avoided by storing the struct page_info*
or mfn corresponding to the guest-provided data structures. We should be
able to do this in a very small number of steps, right?


The property table could be really big (up to the number of LPIs supported by
the guest). The memory is contiguous from a domain point of view but not
necessarily on the host. So you would have to store a big number of MFN. IIRC
the property table can be up to 4GB, so we would need an array of 8MB.


Yes, but in that scenario, with so many LPIs, the new lpi_priority field
will use overall 4GB. In comparison 8MB sounds awesome. But I didn't
notice that it was using the padding space.



Also reading from the guest would require some safety which is not necessary
here.

Furthermore, we have space in pending_irq because of padding.

So why bothering doing that?


I didn't notice that it was taking over some of the padding. That is
much better. I can live with it then.


Would a comment /* This field is only used for caching LPI priority. 
This could be removed and read from the guest memory if we need space. 
*/ be useful?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] tools/golang: Add myself as maintainer

[Konrad Rzeszutek Wilk]

On Thu, Apr 06, 2017 at 03:57:06PM +0100, George Dunlap wrote:
> Signed-off-by: George Dunlap 
> ---
> Andrew Cooper 
> Ian Jackson 
> Jan Beulich 
> Konrad Rzeszutek Wilk 
> Stefano Stabellini 
> Tim Deegan 
> Wei Liu 
> ---
>  MAINTAINERS | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c38bcd4..050cb35 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -206,6 +206,13 @@ S:   Supported
>  F:   xen/arch/x86/debug.c
>  F:   tools/debugger/gdbsx/
>  
> +GOLANG BINDINGS
> +M:  George Dunlap 
> +M:   Ian Jackson 
> +M:   Wei Liu 

Something is off with the spaces/tabs?

> +S:  Supported
> +F:  tools/golang
> +
>  INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
>  M:   Gang Wei 
>  M:   Shane Wang 
> -- 
> 2.1.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

[Xen-devel] [PATCH 6/6] xen/arm: platforms/tegra: Ensure the hwdom can only affect its own interrupts

[Chris Patterson]

From: Chris Patterson 

Several Tegra hardware devices, and the Tegra device tree, expect
the presence of a Tegra Legacy Interrupt Controller (LIC) in the hardware
domain. Accordingly, we'll need to expose (most of) the LIC's registers
to the hardware domain.

As the Tegra LIC provides the ability to modify interrupt delivery (e.g.
by masking interrupts, forcing asserting/clearing them, or adjusting
their prority), it's important that the hardware domain's access be
mediated. This commit adds read/write handlers that prohibit
modification of register sections corresponding to interrupts not owned
by the hardware domain.

Note that this is written to be domain agnostic; this allows the
potential to e.g. map the ictlr into multiple domains if this is desired
for passthrough in the future.

Authored-by: Kyle Temkin 
Signed-off-by: Kyle Temkin 
Signed-off-by: Chris Patterson 
---

changes since rfc:
- documentation, formatting & code style cleanup
- drop tegra_init changes (folded into patch 4)

---
 xen/arch/arm/platforms/Makefile|   2 +
 xen/arch/arm/platforms/tegra-mlic.c| 261 +
 xen/arch/arm/platforms/tegra.c |  13 ++
 xen/include/asm-arm/platforms/tegra-mlic.h |  34 
 4 files changed, 310 insertions(+)
 create mode 100644 xen/arch/arm/platforms/tegra-mlic.c
 create mode 100644 xen/include/asm-arm/platforms/tegra-mlic.h

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index d7033d2..5701e62 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_ARM_32) += rcar2.o
 obj-$(CONFIG_ARM_64) += seattle.o
 obj-$(CONFIG_ARM_32) += sunxi.o
 obj-$(CONFIG_ARM_32) += tegra.o
+obj-$(CONFIG_ARM_32) += tegra-mlic.o
 obj-$(CONFIG_ARM_64) += tegra.o
+obj-$(CONFIG_ARM_64) += tegra-mlic.o
 obj-$(CONFIG_ARM_64) += xgene-storm.o
 obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o
diff --git a/xen/arch/arm/platforms/tegra-mlic.c 
b/xen/arch/arm/platforms/tegra-mlic.c
new file mode 100644
index 000..ad77766
--- /dev/null
+++ b/xen/arch/arm/platforms/tegra-mlic.c
@@ -0,0 +1,260 @@
+/*
+ * xen/arch/arm/tegra_mlic.c
+ *
+ * Mediator for Tegra Legacy Interrupt Controller
+ *
+ * This module allow the hardware domain to have access to the sections of
+ * the legacy interrupt controller that correspond to its devices,
+ * but disallow access to the sections controlled by other domains
+ * or by Xen.
+ *
+ * Kyle Temkin; Copyright (c) 2016 Assured Information Security, Inc.
+ * Chris Patterson; Copyright (c) 2016 Assured Information Security, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int tegra_mlic_mmio_read(struct vcpu *v, mmio_info_t *info,
+   register_t *r, void *priv);
+static int tegra_mlic_mmio_write(struct vcpu *v, mmio_info_t *info,
+register_t r, void *priv);
+
+static const struct mmio_handler_ops tegra_mlic_mmio_handler = {
+.read  = tegra_mlic_mmio_read,
+.write = tegra_mlic_mmio_write,
+};
+
+/*
+ * Parses a LIC MMIO read or write, and extracts the information needed to
+ * complete the request.
+ *
+ * info: Information describing the MMIO read/write being performed
+ * ictlr_index: The interrupt controller number in the ictlr (e.g. 0-5)
+ * register_offset: The register offset into the specified interrupt controller
+ *(e.g. TEGRA_ICTLR_CPU_IER_SET)
+ * irq_base: The number of the first IRQ represented by the given ictlr.
+ */
+static void tegra_mlic_parse_mmio_request(mmio_info_t *info,
+uint32_t *ictlr_index, uint32_t *register_offset, uint32_t *irq_base)
+{
+/* Determine the offset of the access into the ICTLR region. */
+uint32_t offset = info->gpa - TEGRA_ICTLR_BASE;
+uint32_t ictlr = offset / TEGRA_ICTLR_SIZE;
+uint32_t reg = offset % TEGRA_ICTLR_SIZE;
+
+if ( ictlr_index )
+*ictlr_index = ictlr;
+
+if ( register_offset )
+*register_offset = reg;
+
+if ( irq_base )
+*irq_base = (ictlr * TEGRA_IRQS_PER_ICTLR) + NR_LOCAL_IRQS;
+
+/* Ensure that we've only been handed a valid offset within our region. */
+BUG_ON(ictlr >= TEGRA_ICTLR_COUNT);
+BUG_ON(offset >= (TEGRA_ICTLR_COUNT * TEGRA_ICTLR_SIZE));
+BUG_ON((ictlr * 

[Xen-devel] [PATCH 1/6] xen/arm: platforms: Add earlyprintk and serial support for Tegra boards.

[Chris Patterson]

From: Chris Patterson 

Tegra boards feature a NS16550-compatible serial mapped into the MMIO
space. Add support for its use both as a full-featured serial port and
as an earlyprintk driver.

This patch adds a quirk for platforms, such as the Tegra, which require
require the NS16550 Rx timeout interrupt to be enabled for receive to
function properly. The same quirk is applied in the eqvuialent Linux
driver [1].

This quirk is selectively enabled for the platform using a new "hw_quirks"
member with a corresponding set of bitmasks.  The existing quirk,
dw_usr_bsy was updated to match this approach as well.

[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4539c24fe4f92c09ee668ef959d3e8180df619b9

Signed-off-by: Kyle Temkin 
Signed-off-by: Chris Patterson 
---

changes from rfc:
- use bitmask for quirks in ns1660, including dw_usr_bsy

---
 xen/arch/arm/Rules.mk   |  1 +
 xen/drivers/char/ns16550.c  | 28 
 xen/include/xen/8250-uart.h |  1 +
 3 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 569a0ba..43b32d0 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -44,6 +44,7 @@ EARLY_PRINTK_vexpress   := pl011,0x1c09
 EARLY_PRINTK_xgene-mcdivitt := 8250,0x1c021000,2
 EARLY_PRINTK_xgene-storm:= 8250,0x1c02,2
 EARLY_PRINTK_zynqmp := cadence,0xff00
+EARLY_PRINTK_tegra  := 8250,0x70006000,2
 
 ifneq ($(EARLY_PRINTK_$(CONFIG_EARLY_PRINTK)),)
 EARLY_PRINTK_CFG := $(subst $(comma), ,$(EARLY_PRINTK_$(CONFIG_EARLY_PRINTK)))
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index e4de3b4..1b75e89 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -62,7 +62,7 @@ static struct ns16550 {
 struct timer resume_timer;
 unsigned int timeout_ms;
 bool_t intr_works;
-bool_t dw_usr_bsy;
+uint8_t hw_quirks;
 #ifdef CONFIG_HAS_PCI
 /* PCI card parameters. */
 bool_t pb_bdf_enable;   /* if =1, pb-bdf effective, port behind bridge */
@@ -414,6 +414,10 @@ static const struct ns16550_config __initconst 
uart_config[] =
 };
 #endif
 
+/* Various hardware quirks/features that may be need be enabled per device */
+#define HW_QUIRKS_DW_USR_BSY (1<<0)
+#define HW_QUIRKS_USE_RTOIE  (1<<1)
+
 static void ns16550_delayed_resume(void *data);
 
 static u8 ns_read_reg(struct ns16550 *uart, unsigned int reg)
@@ -578,7 +582,7 @@ static void ns16550_setup_preirq(struct ns16550 *uart)
 /* No interrupts. */
 ns_write_reg(uart, UART_IER, 0);
 
-if ( uart->dw_usr_bsy &&
+if ( (uart->hw_quirks & HW_QUIRKS_DW_USR_BSY) &&
  (ns_read_reg(uart, UART_IIR) & UART_IIR_BSY) == UART_IIR_BSY )
 {
 /* DesignWare 8250 detects if LCR is written while the UART is
@@ -651,12 +655,23 @@ static void ns16550_setup_postirq(struct ns16550 *uart)
 {
 if ( uart->irq > 0 )
 {
+u8 ier_value = 0;
+
 /* Master interrupt enable; also keep DTR/RTS asserted. */
 ns_write_reg(uart,
  UART_MCR, UART_MCR_OUT2 | UART_MCR_DTR | UART_MCR_RTS);
 
 /* Enable receive interrupts. */
-ns_write_reg(uart, UART_IER, UART_IER_ERDAI);
+ier_value = UART_IER_ERDAI;
+
+/*
+ * If we're on a platform that needs Rx timeouts enabled, also
+ * set Rx TimeOut Interrupt Enable (RTOIE).
+ */
+if ( uart->hw_quirks & HW_QUIRKS_USE_RTOIE )
+  ier_value |= UART_IER_RTOIE;
+
+ns_write_reg(uart, UART_IER, ier_value);
 }
 
 if ( uart->irq >= 0 )
@@ -1271,7 +1286,11 @@ static int __init ns16550_uart_dt_init(struct 
dt_device_node *dev,
 return -EINVAL;
 uart->irq = res;
 
-uart->dw_usr_bsy = dt_device_is_compatible(dev, "snps,dw-apb-uart");
+if ( dt_device_is_compatible(dev, "snps,dw-apb-uart") )
+uart->hw_quirks |= HW_QUIRKS_DW_USR_BSY;
+
+if ( dt_device_is_compatible(dev, "nvidia,tegra20-uart") )
+uart->hw_quirks |= HW_QUIRKS_USE_RTOIE;
 
 uart->vuart.base_addr = uart->io_base;
 uart->vuart.size = uart->io_size;
@@ -1292,6 +1311,7 @@ static const struct dt_device_match ns16550_dt_match[] 
__initconst =
 DT_MATCH_COMPATIBLE("ns16550"),
 DT_MATCH_COMPATIBLE("ns16550a"),
 DT_MATCH_COMPATIBLE("snps,dw-apb-uart"),
+DT_MATCH_COMPATIBLE("nvidia,tegra20-uart"),
 { /* sentinel */ },
 };
 
diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
index c6b62c8..2ad0ee6 100644
--- a/xen/include/xen/8250-uart.h
+++ b/xen/include/xen/8250-uart.h
@@ -41,6 +41,7 @@
 #define UART_IER_ETHREI   0x02/* tx reg. empty*/
 #define UART_IER_ELSI 0x04/* rx line status   */
 #define UART_IER_EMSI 0x08/* MODEM status */
+#define UART_IER_RTOIE0x10/* rx timeout   */
 
 /* Interrupt Identificatiegister */
 

[Xen-devel] [PATCH 3/6] xen/arm: Allow platforms to hook IRQ routing

[Chris Patterson]

From: "Chris Patterson" 

Some common platforms (e.g. Tegra) have non-traditional IRQ controllers
that must be programmed in addition to their primary GICs-- and which
can come in unusual topologies. Device trees for targets that feature
these controllers often deviate from the conventions that Xen expects.

This commit provides a foundation for support of these platforms, by
allowing the platform to decide which IRQs can be routed by Xen, rather
than assuming that only GIC-connected IRQs can be routed.  This enables
platform specific logic to routing the IRQ to Xen and Guest.

As dt_irq_translate() is presently hard-coded to just support the
primary interrupt controller, instead rely on the newly added
platform_irq_is_routable() check instead.  The default behaviour of this
new function should be consistent with the previous checks for platforms
that do not implement it.

Authored-by: Kyle Temkin 
Signed-off-by: Kyle Temkin 
Signed-off-by: Chris Patterson 
---

changes since rfc:
- use bool instead of bool_t
- formatting & code style cleanup
- reuse dt_irq_translate() path and drop platform_irq_for_device() approach
- use const qualifier for platform_irq_is_routable rirq argument

---

 xen/arch/arm/domain_build.c| 12 
 xen/arch/arm/irq.c |  5 +++--
 xen/arch/arm/platform.c| 30 ++
 xen/common/device_tree.c   |  8 +++-
 xen/include/asm-arm/platform.h | 12 
 5 files changed, 56 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index cb66304..92536dd 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1120,12 +1120,16 @@ static int handle_device(struct domain *d, struct 
dt_device_node *dev,
 
 /*
  * Don't map IRQ that have no physical meaning
- * ie: IRQ whose controller is not the GIC
+ * ie: IRQ that does not wind up being controlled by the GIC
+ * (Note that we can't just check to see if an IRQ is owned by the GIC,
+ *  as some platforms have a controller between the device irq and the 
GIC,
+ *  such as the Tegra legacy interrupt controller.)
  */
-if ( rirq.controller != dt_interrupt_controller )
+if ( !platform_irq_is_routable() )
 {
-dt_dprintk("irq %u not connected to primary controller. Connected 
to %s\n",
-  i, dt_node_full_name(rirq.controller));
+dt_dprintk("irq %u not (directly or indirectly) connected to 
primary"
+"controller. Connected to %s\n", i,
+dt_node_full_name(rirq.controller));
 continue;
 }
 
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index f3f20a6..0b4eaa9 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -26,6 +26,7 @@
 
 #include 
 #include 
+#include 
 
 static unsigned int local_irqs_type[NR_LOCAL_IRQS];
 static DEFINE_SPINLOCK(local_irqs_type_lock);
@@ -369,7 +370,7 @@ int setup_irq(unsigned int irq, unsigned int irqflags, 
struct irqaction *new)
 /* First time the IRQ is setup */
 if ( disabled )
 {
-gic_route_irq_to_xen(desc, GIC_PRI_IRQ);
+platform_route_irq_to_xen(desc, GIC_PRI_IRQ);
 /* It's fine to use smp_processor_id() because:
  * For PPI: irq_desc is banked
  * For SPI: we don't care for now which CPU will receive the
@@ -506,7 +507,7 @@ int route_irq_to_guest(struct domain *d, unsigned int virq,
 if ( retval )
 goto out;
 
-retval = gic_route_irq_to_guest(d, virq, desc, GIC_PRI_IRQ);
+retval = platform_route_irq_to_guest(d, virq, desc, GIC_PRI_IRQ);
 
 spin_unlock_irqrestore(>lock, flags);
 
diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
index 0af6d57..539ee3b 100644
--- a/xen/arch/arm/platform.c
+++ b/xen/arch/arm/platform.c
@@ -147,6 +147,36 @@ bool_t platform_device_is_blacklisted(const struct 
dt_device_node *node)
 return (dt_match_node(blacklist, node) != NULL);
 }
 
+int platform_route_irq_to_guest(struct domain *d, unsigned int virq,
+struct irq_desc *desc, unsigned int priority)
+{
+if ( platform && platform->route_irq_to_guest )
+return platform->route_irq_to_guest(d, virq, desc, priority);
+else
+return gic_route_irq_to_guest(d, virq, desc, priority);
+}
+
+void platform_route_irq_to_xen(struct irq_desc *desc, unsigned int priority)
+{
+if ( platform && platform->route_irq_to_xen )
+platform->route_irq_to_xen(desc, priority);
+else
+gic_route_irq_to_xen(desc, priority);
+}
+
+bool platform_irq_is_routable(const struct dt_raw_irq * rirq)
+{
+/*
+ * If we have a platform-specific method to determine if an IRQ is 
routable,
+ * check that; otherwise fall back to checking to see if an IRQ belongs to
+   

[Xen-devel] [PATCH 0/6] Initial Tegra platform support

[Chris Patterson]

The attached patch-set adds support for 32-bit and 64-bit Tegra SoCs; including
support for the Jetson TK1 and Jetson TX1 boards, as well as the Pixel C tablet.
Previous revisions have been tested against the TK1, TX1, and Pixel C.  This
current patch set has only been tested against the TX1 due to my curent hardware
availability, but should be OK on the other platforms.

Many thanks to Ian Campbell, whose original Jetson TK1 patchset contained a lot
of pointers in the right direction, and helped us to get started on this one!

This patch set includes:
  - A minor serial quirk to get the NS16550 on the Tegra working.
  - Support for the Tegra Legacy Interrupt Controller, which is necessary to get
interrupt routing working correctly on Tegra devices. In this version of the
patchset, the interrupt controller is supported via platform quirks.
  - A few additional minor features and logic fixes to support the Tegra. An
example would be the Tegra-specific reset logic.

This patch set does NOT include:
  - Support for the Tegra-specific IOMMU. This means this platform doesn't yet
support device passthrough.

This patch set includes fixes and cleanup requested from the original RFC
posted by Kyle Temkin. Kyle has done most of the authoring on this, but I am
picking it up to address the RFC reviews and push it though.

Chris Patterson (6):
  xen/arm: platforms: Add earlyprintk and serial support for Tegra
boards.
  xen/arm: domain_build: Inherit GIC's interrupt-parent from host device
tree
  xen/arm: Allow platforms to hook IRQ routing
  xen/arm: platforms: Add Tegra platform to support basic IRQ routing
  xen/arm: Add function to query IRQ 'ownership'
  xen/arm: platforms/tegra: Ensure the hwdom can only affect its own
interrupts

 xen/arch/arm/Rules.mk  |   1 +
 xen/arch/arm/domain_build.c|  29 ++-
 xen/arch/arm/irq.c |  15 +-
 xen/arch/arm/platform.c|  30 +++
 xen/arch/arm/platforms/Makefile|   4 +
 xen/arch/arm/platforms/tegra-mlic.c| 261 +++
 xen/arch/arm/platforms/tegra.c | 326 +
 xen/common/device_tree.c   |   8 +-
 xen/drivers/char/ns16550.c |  28 ++-
 xen/include/asm-arm/irq.h  |   2 +
 xen/include/asm-arm/platform.h |  12 ++
 xen/include/asm-arm/platforms/tegra-mlic.h |  34 +++
 xen/include/asm-arm/platforms/tegra.h  |  54 +
 xen/include/xen/8250-uart.h|   1 +
 14 files changed, 788 insertions(+), 17 deletions(-)
 create mode 100644 xen/arch/arm/platforms/tegra-mlic.c
 create mode 100644 xen/arch/arm/platforms/tegra.c
 create mode 100644 xen/include/asm-arm/platforms/tegra-mlic.h
 create mode 100644 xen/include/asm-arm/platforms/tegra.h

-- 
2.1.4


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

[Xen-devel] [PATCH 4/6] xen/arm: platforms: Add Tegra platform to support basic IRQ routing

[Chris Patterson]

From: "Chris Patterson" 

Tegra devices have a legacy interrupt controller (lic, or ictlr) that
must be programmed in parallel with their primary GIC. For all intents
and purposes, we treat these devices attached to this controller as
connected to the primary GIC, as it will be handling their interrupts.

This commit adds support for exposing the ictlr to the hardware domain;
but a future commit will extend this to support exposing a virtualized
version of the ictlr to the hardware domain, and to ensure that
interrupts are unmasked properly when routed to a Xen, or to a domain
other than the hardware domain.

Authored-by: Kyle Temkin 
Signed-off-by: Kyle Temkin 
Signed-off-by: Chris Patterson 
---

changes since rfc:
- use bool instead of bool_t
- formatting & code style cleanup
- fix dt compat label (nvidia,tegra120 -> nvidia,tegra124) for K1
- separate mediated legacy interrupt controller into its own module
- split tegra_ictlr_set_interrupt_enable() into
  tegra_lic_set_interrupt_type_normal() and
  tegra_lic_set_interrupt_enable()
- added a couple helper functions to reduce duplicated logic
- added wrapper tegra_lic_readl and writel functions for external use (mlic)
- re-order defines in tegra.h
- cleanup tegra_init() that was previously in patch 6

---

 xen/arch/arm/platforms/Makefile   |   2 +
 xen/arch/arm/platforms/tegra.c| 313 ++
 xen/include/asm-arm/platforms/tegra.h |  54 ++
 3 files changed, 369 insertions(+)
 create mode 100644 xen/arch/arm/platforms/tegra.c
 create mode 100644 xen/include/asm-arm/platforms/tegra.h

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index 49fa683..d7033d2 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -6,5 +6,7 @@ obj-$(CONFIG_ARM_32) += omap5.o
 obj-$(CONFIG_ARM_32) += rcar2.o
 obj-$(CONFIG_ARM_64) += seattle.o
 obj-$(CONFIG_ARM_32) += sunxi.o
+obj-$(CONFIG_ARM_32) += tegra.o
+obj-$(CONFIG_ARM_64) += tegra.o
 obj-$(CONFIG_ARM_64) += xgene-storm.o
 obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o
diff --git a/xen/arch/arm/platforms/tegra.c b/xen/arch/arm/platforms/tegra.c
new file mode 100644
index 000..bdd9966
--- /dev/null
+++ b/xen/arch/arm/platforms/tegra.c
@@ -0,0 +1,312 @@
+/*
+ * NVIDIA Tegra specific settings
+ *
+ * Ian Campbell; Copyright (c) 2014 Citrix Systems
+ * Kyle Temkin; Copyright (c) 2016 Assured Information Security, Inc.
+ * Chris Patterson; Copyright (c) 2016 Assured Information Security, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/* Permanent mapping to the Tegra legacy interrupt controller. */
+static void __iomem *tegra_ictlr_base;
+
+/*
+ * List of legacy interrupt controllers that can be used to route
+ * Tegra interrupts.
+ */
+static const char * const tegra_interrupt_compat[] __initconst =
+{
+"nvidia,tegra124-ictlr",  /* Tegra K1 controllers */
+"nvidia,tegra210-ictlr"   /* Tegra X1 controllers */
+};
+
+/*
+ * Returns true iff the given IRQ belongs to a supported tegra interrupt
+ * controller.
+ */
+static bool tegra_irq_belongs_to_ictlr(const struct dt_raw_irq * rirq)  {
+int i;
+
+for ( i = 0; i < ARRAY_SIZE(tegra_interrupt_compat); i++ ) {
+if ( dt_device_is_compatible(rirq->controller, 
tegra_interrupt_compat[i]) )
+return true;
+}
+
+return false;
+}
+
+/*
+ * Returns true iff the given IRQ is routable -- that is, if it is descended
+ * from the platform's primary GIC.
+ */
+static bool tegra_irq_is_routable(const struct dt_raw_irq * rirq)
+{
+/* If the IRQ connects directly to our GIC, it's trivially routable. */
+if ( rirq->controller == dt_interrupt_controller )
+return true;
+
+/*
+ * If the IRQ belongs to a legacy interrupt controller, then it's
+ * effectively owned by the GIC, and is routable.
+ */
+if ( tegra_irq_belongs_to_ictlr(rirq) )
+return true;
+
+return false;
+}
+
+/*
+ * Platform-specific reset code for the Tegra devices.
+ * Should not return.
+ */
+static void tegra_reset(void)
+{
+void __iomem *addr;
+u32 val;
+
+addr = ioremap_nocache(TEGRA_RESET_BASE, TEGRA_RESET_SIZE);
+if ( !addr )
+{
+printk(XENLOG_ERR "Tegra: Unable to map tegra reset address. Reset 
failed!\n");
+return;
+}
+
+/* Write into the 

[Xen-devel] [PATCH 5/6] xen/arm: Add function to query IRQ 'ownership'

[Chris Patterson]

From: "Chris Patterson" 

The addition of new IRQ-related platform hooks now allow platforms to
perform platform-specific interrupt logic, such as allowing virtualization
of platform-specific interrupt controller hardware.

This commit adds the ability for the platform to identify the domain
a given IRQ is routed to, allowing platform logic to deny access to
registers associated with a given IRQ unless the requesting domain
'owns' the IRQ. This will be used on Tegra platforms, where the hardware
domain needs access to its legacy interrupt controller, but should not
be able to control registers that correspond to other domains' IRQs, or
sections associated with IRQs routed to Xen.

Authored-by: Kyle Temkin 
Signed-off-by: Kyle Temkin 
Signed-off-by: Chris Patterson 
Reviewed-by: Stefano Stabellini 
---

changes since rfc:
- formatting & code style cleanup

---

 xen/arch/arm/irq.c| 10 ++
 xen/include/asm-arm/irq.h |  2 ++
 2 files changed, 12 insertions(+)

diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 0b4eaa9..51bce58 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -143,6 +143,16 @@ static inline struct domain *irq_get_domain(struct 
irq_desc *desc)
 return irq_get_guest_info(desc)->d;
 }
 
+domid_t irq_get_domain_id(struct irq_desc *desc)
+{
+/* If this domain isn't routed to a guest, return DOMID_XEN. */
+if ( !test_bit(_IRQ_GUEST, >status) )
+return DOMID_XEN;
+
+/* Otherise, get the guest domain's information. */
+return irq_get_domain(desc)->domain_id;
+}
+
 void irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_mask)
 {
 if ( desc != NULL )
diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
index 4849f16..d0fd6db 100644
--- a/xen/include/asm-arm/irq.h
+++ b/xen/include/asm-arm/irq.h
@@ -44,6 +44,8 @@ int route_irq_to_guest(struct domain *d, unsigned int virq,
unsigned int irq, const char *devname);
 int release_guest_irq(struct domain *d, unsigned int irq);
 
+domid_t irq_get_domain_id(struct irq_desc *desc);
+
 void arch_move_irqs(struct vcpu *v);
 
 #define arch_evtchn_bind_pirq(d, pirq) ((void)((d) + (pirq)))
-- 
2.1.4


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

[Xen-devel] [PATCH 2/6] xen/arm: domain_build: Inherit GIC's interrupt-parent from host device tree

[Chris Patterson]

From: "Chris Patterson" 

Currently, the interrupt parent is left undefined during creation in
make_gic_node().  In cases where a non-GIC interrupt controller is present,
this can lead to incorrect assignment of interrupt parents.

On the Tegra, the gic's interrupt parent is set to itself:

gic: interrupt-controller@0,50041000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
interrupt-controller;
reg = <0x0 0x50041000 0x0 0x1000>,
  <0x0 0x50042000 0x0 0x2000>,
  <0x0 0x50044000 0x0 0x2000>,
  <0x0 0x50046000 0x0 0x2000>;
interrupts = ;
interrupt-parent = <>;
};

To prevent the hardware domain from assuming the Legacy Interrupt Controller
(lic) as the GIC's interrupt-parent, this change explicitly assigns
the interrupt-parent property from the host device tree.

Authored-by: Kyle Temkin 
Signed-off-by: Kyle Temkin 
Signed-off-by: Chris Patterson 
Reviewed-by: Stefano Stabellini 
---

changes from rfc:
- commit message documentation improvements

---
 xen/arch/arm/domain_build.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index de59e5f..cb66304 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -778,8 +778,8 @@ static int make_gic_node(const struct domain *d, void *fdt,
 {
 const struct dt_device_node *gic = dt_interrupt_controller;
 int res = 0;
-const void *addrcells, *sizecells;
-u32 addrcells_len, sizecells_len;
+const void *addrcells, *sizecells, *iparent;
+u32 addrcells_len, sizecells_len, iparent_len;
 
 /*
  * Xen currently supports only a single GIC. Discard any secondary
@@ -809,6 +809,19 @@ static int make_gic_node(const struct domain *d, void *fdt,
 return res;
 }
 
+/*
+ * If available, explicitly inherit interrupt-parent property from host
+ * device tree.  This will prevent the risk of incorrect identification
+ * of the parent on platforms with more than one interrupt controller.
+ */
+iparent = dt_get_property(gic, "interrupt-parent", _len);
+if ( iparent )
+{
+res = fdt_property(fdt, "interrupt-parent", iparent, iparent_len);
+if ( res )
+  return res;
+}
+
 addrcells = dt_get_property(gic, "#address-cells", _len);
 if ( addrcells )
 {
-- 
2.1.4


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

[Xen-devel] [xen-unstable-smoke test] 107252: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  db7b5b0c50b238ca259b83af3aca102701c4abac
baseline version:
 xen  4feb9779c92783c47ef1d75b5ab3823888313aac

Last test of basis   107245  2017-04-06 15:01:20 Z0 days
Testing same since   107252  2017-04-06 18:01:30 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Ian Jackson 
  Tim Deegan 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=db7b5b0c50b238ca259b83af3aca102701c4abac
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
db7b5b0c50b238ca259b83af3aca102701c4abac
+ branch=xen-unstable-smoke
+ revision=db7b5b0c50b238ca259b83af3aca102701c4abac
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ 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
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' xdb7b5b0c50b238ca259b83af3aca102701c4abac = 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
++ : 

Re: [Xen-devel] Shattering superpages impact on IOMMU in Xen

[Julien Grall]

Hi Oleksandr,

On 04/06/2017 07:59 PM, Oleksandr Tyshchenko wrote:

Hi, guys.

Seems, it was only my fault. The issue wasn't exactly in shattering,
the shattering just increased probability for IOMMU page faults to
occur. I didn't do clean_dcache for the page table entry after
updating it. So, with clean_dcache I don't see page faults when
shattering superpages!
BTW, can I configure domheap pages (which I am using for the IOMMU
page table) to be uncached? What do you think?


I am not sure if you suggest to configure all the domheap pages to be 
uncached or only a limited number.


In the case where you switch all domheap to uncached, you will have some 
trouble when copy data to/from the guest in hypercall because of 
mismatch attribute.


In the case where you only configure some of the domheap pages, you will 
remove the advantage of 1GB mapping of the domheap in the hypervisor 
table and will increase the memory usage of Xen. Also, you will have to 
be careful when switching back and forth the domheap memory attribute 
between cache and uncache.


If the IOMMU is not able to snoop the cache, then the way forward is to 
use a clean_dcache operation after writing a page table entry. This is 
how we deal in the p2m code.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 13/30] ARM: GICv3: forward pending LPIs to guests

[Julien Grall]

Hi Stefano,

On 04/06/2017 07:47 PM, Stefano Stabellini wrote:

On Thu, 6 Apr 2017, Andre Przywara wrote:

 unsigned long status;
 struct irq_desc *desc; /* only set it the irq corresponds to a physical 
irq */
 unsigned int irq;
 #define GIC_INVALID_LR (uint8_t)~0
 uint8_t lr;
 uint8_t priority;
+uint8_t lpi_priority;   /* Caches the priority if this is an LPI. */


The commit message says: "we enhance struct pending_irq to cache the
pending bit and the priority information for LPIs, as we can't afford to
walk the tables in guest memory every time we handle an incoming LPI." I
thought it would be direct access, having the vlpi number in our hands?
Why is it a problem?

If there has been a conversation about this that I am missing, please
provide a link, I'll go back and read it.


Well, the property table is in guest memory as the other ITS tables and
we now access this in a new way (vgic_access_guest_memory()), which is
quite costly: we need to do the p2m lookup, map the page, access the
data, unmap the page and put the page back.


map, unmap and put are (almost) nop. The only operation is the
p2m_lookup that could be easily avoided by storing the struct page_info*
or mfn corresponding to the guest-provided data structures. We should be
able to do this in a very small number of steps, right?


The property table could be really big (up to the number of LPIs 
supported by the guest). The memory is contiguous from a domain point of 
view but not necessarily on the host. So you would have to store a big 
number of MFN. IIRC the property table can be up to 4GB, so we would 
need an array of 8MB.


Also reading from the guest would require some safety which is not 
necessary here.


Furthermore, we have space in pending_irq because of padding.

So why bothering doing that?





Everything on itself is not
really too demanding (on arm64), but doing this in the interrupt
handling path to learn the priority value sounds a bit over the top.
For the *ITS* emulation (command handling) we can cope with this
overhead (because this is only needing during the virtual command
handling), but I wanted to avoid this in the generic GIC code, which is
also a hot path, as I understand.
Since the GICv3 architecture explicitly allows caching this information,
I wanted to use this opportunity.

Does that make sense?


Yes, I see your reasoning and you are right that it is very important to
keep the hot path very fast. However, I think we should be able to do
that without duplicating information and adding another field to
pending_irq.


Why? We should not trust information living in the guest memory. This is 
a call to attack Xen. So this means more safety.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] Outreachy project - Xen Code Review Dashboard

[Jesus M. Gonzalez-Barahona]

On Wed, 2017-04-05 at 16:43 -0700, Heather Booker wrote:
> Hi!
> 
> I'd love to work on the Code Review Dashboard project for this round
> of Outreachy.

Great!!

> Are the steps outlined
> here http://markmail.org/message/7adkmords3imkswd still the first
> contribution you'd like to see?

Yes.

> So is this a project that has been worked on in previous rounds of
> GSOC/Outreachy also?
> If so is there a place to find links to the previous participants
> blogs? :)

No. We had one participation at some point, but couldn't even start for
personal reasons. There are some people considering working on this for
this next round of Outreachy, however. You'll see their messages in
this mailing list.

> Should questions about how the specifications/completion of the
> microtask be addressed to
> IRC or this list? If IRC, which channel - #xen-opw or #metrics-
> grimoire? On that note, I'm 
> curious why #metrics-grimoire is the listed channel on the project
> page - are main contributors
> involved in both projects? Or is it just because the Xen dashboard
> doesn't have a channel?

The code review is for the Xen project, but it is done with (I mean,
the ssoftware used for it is) GrimoireLab, which for historical reasons
uses the #metrics-grimoire channel. That's why it is likely that you
find somebody from the project there.

If you have questions, and find me around in IRC, please ping me. If
I'm not available, please send an email message.

Saludos,

Jesus.

> Thanks!
> 
> Heather
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
-- 
Bitergia: http://bitergia.com
/me at Twitter: https://twitter.com/jgbarah


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

Re: [Xen-devel] [PATCH v5 16/30] ARM: vGICv3: handle disabled LPIs

[Andre Przywara]

Hi,

On 06/04/17 00:58, Stefano Stabellini wrote:
> On Thu, 6 Apr 2017, Andre Przywara wrote:
>> If a guest disables an LPI, we do not forward this to the associated
>> host LPI to avoid queueing commands to the host ITS command queue.
>> So it may happen that an LPI fires nevertheless on the host. In this
>> case we can bail out early, but have to save the pending state on the
>> virtual side. We do this by storing the pending bit in struct
>> pending_irq, which is assiociated with mapped LPIs.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/gic-v3-lpi.c | 26 +-
>>  1 file changed, 25 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
>> index d8baebc..7d20986 100644
>> --- a/xen/arch/arm/gic-v3-lpi.c
>> +++ b/xen/arch/arm/gic-v3-lpi.c
>> @@ -136,6 +136,22 @@ uint64_t gicv3_get_redist_address(unsigned int cpu, 
>> bool use_pta)
>>  return per_cpu(lpi_redist, cpu).redist_id << 16;
>>  }
>>  
>> +static bool vgic_can_inject_lpi(struct vcpu *vcpu, uint32_t vlpi)
>> +{
>> +struct pending_irq *p;
>> +
>> +p = vcpu->domain->arch.vgic.handler->lpi_to_pending(vcpu->domain, vlpi);
>> +if ( !p )
>> +return false;
>> +
>> +if ( test_bit(GIC_IRQ_GUEST_ENABLED, >status) )
>> +return true;
>> +
>> +set_bit(GIC_IRQ_GUEST_LPI_PENDING, >status);
> 
> See alpine.DEB.2.10.1701051422020.2866@sstabellini-ThinkPad-X260

(from this email:)
> I suggest vgic_can_inject_lpi doesn't only return true or false, but
> also if the vlpi is already set to pending. In that case, I think we
> should disable the plpi to avoid storms (also see
> http://marc.info/?l=xen-devel=148055519432739).

So I can surely change the function to return that information, but I
think we don't have a good way of handling the storm easily.
First sending the required INV command to let the host know about our
change to the property table might take some time (we have a timeout in
there), also takes a spinlock. Which doesn't sound too good in the
interrupt injection path.
But secondly re-enabling the interrupt is not easily possible currently.
Ideally one would expect this to happen when the guest enables the
corresponding virtual LPI, but that would again require to send an INV
command to the host ITS, which is something that we avoid when triggered
by a guest (the MAPD exception is only for Dom0 and will hopefully go
away later).
So a guest could send virtual INVs (disabling and enabling the virtual
LPI) and trying to flood the host command queue.

So shall I change the function anyway and add a TODO comment, so that we
can later revisit this scenario?

Cheers,
Andre.

> 
>> +return false;
>> +}
>> +
>>  /*
>>   * Handle incoming LPIs, which are a bit special, because they are 
>> potentially
>>   * numerous and also only get injected into guests. Treat them specially 
>> here,
>> @@ -187,7 +203,15 @@ void gicv3_do_LPI(unsigned int lpi)
>>  
>>  /* Check if the VCPU is ready to receive LPIs. */
>>  if ( vcpu->arch.vgic.flags & VGIC_V3_LPIS_ENABLED )
>> -vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);
>> +{
>> +/*
>> + * We keep all host LPIs enabled, so check if it's disabled on the
>> + * guest side and just record this LPI in the virtual pending table
>> + * in this case. The guest picks it up once it gets enabled again.
>> + */
>> +if ( vgic_can_inject_lpi(vcpu, hlpi.virt_lpi) )
>> +vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);
>> +}
>>  
>>  rcu_unlock_domain(d);
>>  }
>> -- 
>> 2.8.2
>>

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

Re: [Xen-devel] Shattering superpages impact on IOMMU in Xen

[Oleksandr Tyshchenko]

On Tue, Apr 4, 2017 at 12:28 PM, Oleksandr Tyshchenko
 wrote:
> Hi, Stefano.
>
> On Mon, Apr 3, 2017 at 11:33 PM, Stefano Stabellini
>  wrote:
>> On Mon, 3 Apr 2017, Oleksandr Tyshchenko wrote:
>>> On Mon, Apr 3, 2017 at 9:06 PM, Julien Grall  wrote:
>>> > Hi Andrew,
>>> >
>>> >
>>> > On 03/04/17 18:16, Andrew Cooper wrote:
>>> >>
>>> >> On 03/04/17 18:02, Julien Grall wrote:
>>> >>>
>>> >>> Hi Andrew,
>>> >>>
>>> >>> On 03/04/17 17:42, Andrew Cooper wrote:
>>> 
>>>  On 03/04/17 17:24, Oleksandr Tyshchenko wrote:
>>> >
>>> > Hi, all.
>>> >
>>> > Playing with non-shared IOMMU in Xen on ARM I faced one interesting
>>> > thing. I found out that the superpages were shattered during domain
>>> > life cycle.
>>> > This is the result of mapping of foreign pages, ballooning memory,
>>> > even if domain maps Xen shared pages, etc.
>>> > I don't bother with the memory fragmentation at the moment. But,
>>> > shattering bothers me from the IOMMU point of view.
>>> > As the Xen owns IOMMU it might manipulate IOMMU page tables when
>>> > passthoughed/protected device doing DMA in Linux. It is hard to detect
>>> > when the DMA transaction isn't in progress
>>> > in order to prevent this race. So, if we have inflight transaction
>>> > from a device when changing IOMMU mapping we might get into trouble.
>>> > Unfortunately, not in all the cases the
>>> > faulting transaction can be restarted. The chance to hit the problem
>>> > increases during shattering.
>>> >
>>> > I did next test:
>>> > The dom0 on my setup contains ethernet IP that are protected by IOMMU.
>>> > What is more, as the IOMMU I am playing with supports superpages (2M,
>>> > 1G) the IOMMU driver
>>> > takes into account these capabilities when building page tables. As I
>>> > gave 256 MB for dom0, the IOMMU mapping was built by 2M memory blocks
>>> > only. As I am using NFS for both dom0 and domU the ethernet IP
>>> > performs DMA transactions almost all the time.
>>> > Sometimes, I see the IOMMU page faults during creating guest domain. I
>>> > think, it happens during Xen is shattering 2M mappings 4K mappings (it
>>> > unmaps dom0 pages by one 4K page at a time, then maps domU pages there
>>> > for copying domU images).
>>> > But, I don't see any page faults when the IOMMU page table was built
>>> > by 4K pages only.
>>> >
>>> > I had a talk with Julien on IIRC and we came to conclusion that the
>>> > safest way would be to use 4K pages to prevent shattering, so the
>>> > IOMMU shouldn't report superpage capability.
>>> > On the other hand, if we build IOMMU from 4K pages we will have
>>> > performance drop (during building, walking page tables), TLB pressure,
>>> > etc.
>>> > Another possible solution Julien was suggesting is to always
>>> > ballooning with 2M, 1G, and not using 4K. That would help us to
>>> > prevent shattering effect.
>>> > The discussion was moved to the ML since it seems to be a generic
>>> > issue and the right solution should be think of.
>>> >
>>> > What do you think is the right way to follow? Use 4K pages and don't
>>> > bother with shattering or try to optimize? And if the idea to make
>>> > balloon mechanism smarter makes sense how to teach balloon to do so?
>>> > Thank you.
>>> 
>>> 
>>>  Ballooning and foreign mappings are terrible for trying to retain
>>>  superpage mappings.  No OS, not even Linux, can sensibly provide victim
>>>  pages in a useful way to avoid shattering.
>>> 
>>>  If you care about performance, don't ever balloon.  Foreign mappings in
>>>  translated guests should start from the top of RAM, and work upwards.
>>> >>>
>>> >>>
>>> >>> I am not sure to understand this. Can you extend?
>>> >>
>>> >>
>>> >> I am not sure what is unclear.  Handing random frames of RAM back to the
>>> >> hypervisor is what exacerbates host superpage fragmentation, and all
>>> >> balloon drivers currently do it.
>>> >>
>>> >> If you want to avoid host superpage fragmentation, don't use a
>>> >> scattergun approach of handing frames back to Xen.  However, because
>>> >> even Linux doesn't provide enough hooks into the physical memory
>>> >> management logic, the only solution is to not balloon at all, and to use
>>> >> already-unoccupied frames for foreign mappings.
>>> >
>>> >
>>> > Do you have any pointer in the Linux code?
>>> >
>>> >
>>> >>
>>> >>>
>>> 
>>> 
>>>  As for the IOMMU specifically, things are rather easier.  It is the
>>>  guests responsibility to ensure that frames offered up for ballooning 
>>>  or
>>>  foreign mappings are unused.  Therefore, if anything cares about the
>>>  specific 4K region becoming non-present in the IOMMU mappings, it is 
>>>  the
>>>  guest kernels 

Re: [Xen-devel] [PATCH v5 03/30] ARM: GICv3 ITS: parse and store ITS subnodes from hardware DT

[Andre Przywara]

Hi,

On 06/04/17 00:26, Stefano Stabellini wrote:
> On Thu, 6 Apr 2017, Andre Przywara wrote:
>> Parse the GIC subnodes in the device tree to find every ITS MSI controller
>> the hardware offers. Store that information in a list to both propagate
>> all of them later to Dom0, but also to be able to iterate over all ITSes.
>> This introduces an ITS Kconfig option (as an EXPERT option), use
>> XEN_CONFIG_EXPERT=y on the make command line to see and use the option.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/Kconfig |  5 +++
>>  xen/arch/arm/Makefile|  1 +
>>  xen/arch/arm/gic-v3-its.c| 77 
>> 
>>  xen/arch/arm/gic-v3.c| 10 +++---
>>  xen/include/asm-arm/gic_v3_its.h | 67 ++
>>  5 files changed, 156 insertions(+), 4 deletions(-)
>>  create mode 100644 xen/arch/arm/gic-v3-its.c
>>  create mode 100644 xen/include/asm-arm/gic_v3_its.h
>>
>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>> index 43123e6..d46b98c 100644
>> --- a/xen/arch/arm/Kconfig
>> +++ b/xen/arch/arm/Kconfig
>> @@ -45,6 +45,11 @@ config ACPI
>>  config HAS_GICV3
>>  bool
>>  
>> +config HAS_ITS
>> +bool
>> +prompt "GICv3 ITS MSI controller support" if EXPERT = "y"
>> +depends on HAS_GICV3
>> +
>>  endmenu
>>  
>>  menu "ARM errata workaround via the alternative framework"
>> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
>> index 0ce94a8..39c0a03 100644
>> --- a/xen/arch/arm/Makefile
>> +++ b/xen/arch/arm/Makefile
>> @@ -18,6 +18,7 @@ obj-$(EARLY_PRINTK) += early_printk.o
>>  obj-y += gic.o
>>  obj-y += gic-v2.o
>>  obj-$(CONFIG_HAS_GICV3) += gic-v3.o
>> +obj-$(CONFIG_HAS_ITS) += gic-v3-its.o
>>  obj-y += guestcopy.o
>>  obj-y += hvm.o
>>  obj-y += io.o
>> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
>> new file mode 100644
>> index 000..6b02349
>> --- /dev/null
>> +++ b/xen/arch/arm/gic-v3-its.c
>> @@ -0,0 +1,77 @@
>> +/*
>> + * xen/arch/arm/gic-v3-its.c
>> + *
>> + * ARM GICv3 Interrupt Translation Service (ITS) support
>> + *
>> + * Copyright (C) 2016,2017 - ARM Ltd
>> + *
>> + * 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; under version 2 of the License.
>> + *
>> + * 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.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; If not, see .
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/*
>> + * No lock here, as this list gets only populated upon boot while scanning
>> + * firmware tables for all host ITSes, and only gets iterated afterwards.
>> + */
>> +LIST_HEAD(host_its_list);
>> +
>> +bool gicv3_its_host_has_its(void)
>> +{
>> +return !list_empty(_its_list);
>> +}
>> +
>> +/* Scan the DT for any ITS nodes and create a list of host ITSes out of it. 
>> */
>> +void gicv3_its_dt_init(const struct dt_device_node *node)
>> +{
>> +const struct dt_device_node *its = NULL;
>> +struct host_its *its_data;
>> +
>> +/*
>> + * Check for ITS MSI subnodes. If any, add the ITS register
>> + * frames to the ITS list.
>> + */
>> +dt_for_each_child_node(node, its)
>> +{
>> +uint64_t addr, size;
>> +
>> +if ( !dt_device_is_compatible(its, "arm,gic-v3-its") )
>> +continue;
>> +
>> +if ( dt_device_get_address(its, 0, , ) )
>> +panic("GICv3: Cannot find a valid ITS frame address");
>> +
>> +its_data = xzalloc(struct host_its);
>> +if ( !its_data )
>> +panic("GICv3: Cannot allocate memory for ITS frame");
>> +
>> +its_data->addr = addr;
>> +its_data->size = size;
>> +its_data->dt_node = its;
>> +
>> +printk("GICv3: Found ITS @0x%lx\n", addr);
>> +
>> +list_add_tail(_data->entry, _its_list);
>> +}
>> +}
>> +
>> +/*
>> + * Local variables:
>> + * mode: C
>> + * c-file-style: "BSD"
>> + * c-basic-offset: 4
>> + * indent-tabs-mode: nil
>> + * End:
>> + */
>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
>> index 695f01f..b626298 100644
>> --- a/xen/arch/arm/gic-v3.c
>> +++ b/xen/arch/arm/gic-v3.c
>> @@ -42,6 +42,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  
>> @@ -1227,11 +1228,12 @@ static void __init gicv3_dt_init(void)
>>   */
>>  res = dt_device_get_address(node, 1 + gicv3.rdist_count,
>>  , );
>> -if ( res )
>> -return;
>> +if ( !res )
>> +dt_device_get_address(node, 1 

Re: [Xen-devel] [PATCH v5 13/30] ARM: GICv3: forward pending LPIs to guests

[Stefano Stabellini]

On Thu, 6 Apr 2017, Andre Przywara wrote:
> Hi Stefano,
> 
> thanks for spending your brain cells on this nasty code.
> 
> ...
> 
> On 06/04/17 00:45, Stefano Stabellini wrote:
> > On Thu, 6 Apr 2017, Andre Przywara wrote:
> >> Upon receiving an LPI on the host, we need to find the right VCPU and
> >> virtual IRQ number to get this IRQ injected.
> >> Iterate our two-level LPI table to find this information quickly when
> >> the host takes an LPI. Call the existing injection function to let the
> >> GIC emulation deal with this interrupt.
> >> Also we enhance struct pending_irq to cache the pending bit and the
> >> priority information for LPIs, as we can't afford to walk the tables in
> >> guest memory every time we handle an incoming LPI.
> >> This introduces a do_LPI() as a hardware gic_ops and a function to
> >> retrieve the (cached) priority value of an LPI and a vgic_ops.
> >>
> >> Signed-off-by: Andre Przywara 
> >>
> >> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
> >> index 7c86f5b..08d6294 100644
> >> --- a/xen/include/asm-arm/vgic.h
> >> +++ b/xen/include/asm-arm/vgic.h
> >> @@ -66,12 +66,14 @@ struct pending_irq
> >>  #define GIC_IRQ_GUEST_VISIBLE  2
> >>  #define GIC_IRQ_GUEST_ENABLED  3
> >>  #define GIC_IRQ_GUEST_MIGRATING   4
> >> +#define GIC_IRQ_GUEST_LPI_PENDING 5 /* Caches the pending bit of an 
> >> LPI. */
> > 
> > I don't think we need GIC_IRQ_GUEST_LPI_PENDING, you can reuse
> > GIC_IRQ_GUEST_QUEUED and list_empty(>inflight): if you call
> > vgic_vcpu_inject_irq passing an irq as argument that is not enabled, it
> > will get GIC_IRQ_GUEST_QUEUED and added to inflight, but not injected.
> 
> Mmh, that's an interesting suggestion.
> The neat thing about piggy-backing on those status bits is that we can
> use the atomic set_bit/clear_bit to set and clear the pending state,
> independently from any code accessing the structure, even without taking
> any lock. Especially since the existing VGIC code does not care about
> this bit.
> However looking at all users of GUEST_LPI_PENDING, I see that we either
> already hold the VGIC lock and we are able to take it, so we might be
> able to use the combination you suggested.
> 
> I tried to make some sense of what "inflight" *really* means, can you
> shed some light on this?

See the comment in xen/include/asm-arm/vgic.h.

vgic_vcpu_inject_irq(irq) is called:
- GIC_IRQ_GUEST_QUEUED is set
- pending_irq is added to the inflight list

At this stage the irq is tracked as being inflight, but not really
injected into the guest yet.

Once/If the irq is enabled, we try to inject it into the guest.
gic_raise_guest_irq(irq) is called:
- if there is a free LR
  - clear GIC_IRQ_GUEST_QUEUED
  - set GIC_IRQ_GUEST_VISIBLE
- otherwise
  - add pending_irq to lr_pending
- pending_irq is still on the inflight list too
- pending_irq will be removed from lr_pending, and the irq added to an LR 
when
  available

When the guest finishes with the irq and EOIes it:
gic_update_one_lr is called:
- clear LR
- clear GIC_IRQ_GUEST_VISIBLE
- pending_irq is removed from inflight


Thus, you can use list_empty(>inflight) and QUEUED to check if the
LPI has been set to PENDING but it hasn't been injected yet, because the
corresponding pending_irq remains on the inflight list until the LPI has
been EOIed. but QUEUED is cleared as soon as the irq is added to an LR.

It is possible to set an interrupt as QUEUED, even if pending_irq is
already inflight and the irq is VISIBLE. That just means that the
physical irq has been reasserted after the virq becomes ACTIVE and
before the EOI.


> My understanding is that it's about IRQs that should be injected, but
> are not ready (because they are disabled). Are there other cases IRQs
> are in the "inflight" list? Is that also the spillover in case all LRs
> are used (in this case they would GIC_IRQ_GUEST_ENABLED)?

No. If all LRs are used, pending_irq is added to lr_pending. However,
pending_irq *also* remains in the inflight list until EOI.

If (ENABLED && QUEUED && inflight) is the condition to try to inject the
irq into the guest. If list_empty(>arch.vgic.lr_pending) is the
condition to actually be able to add the irq to an lr.


> >>  unsigned long status;
> >>  struct irq_desc *desc; /* only set it the irq corresponds to a 
> >> physical irq */
> >>  unsigned int irq;
> >>  #define GIC_INVALID_LR (uint8_t)~0
> >>  uint8_t lr;
> >>  uint8_t priority;
> >> +uint8_t lpi_priority;   /* Caches the priority if this is an LPI. 
> >> */
> > 
> > The commit message says: "we enhance struct pending_irq to cache the
> > pending bit and the priority information for LPIs, as we can't afford to
> > walk the tables in guest memory every time we handle an incoming LPI." I
> > thought it would be direct access, having the vlpi number in our hands?
> > Why is it a problem?
> > 
> > If there has been a conversation about this that I am missing, please
> > 

Re: [Xen-devel] [PATCH for-4.9] xen: use a dummy file in C99 header check

[Andrew Cooper]

On 06/04/17 19:33, Wei Liu wrote:
> The check builds header file as if it is a C file. Clang doesn't like
> the idea of having dead code in C file. The check as-is fails on Clang
> with unused function warnings.
>
> Use a dummy file like the C++ header check to fix this.
>
> Signed-off-by: Wei Liu 

Acked-by: Andrew Cooper 

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

[Xen-devel] [PATCH for-4.9] xen: use a dummy file in C99 header check

[Wei Liu]

The check builds header file as if it is a C file. Clang doesn't like
the idea of having dead code in C file. The check as-is fails on Clang
with unused function warnings.

Use a dummy file like the C++ header check to fix this.

Signed-off-by: Wei Liu 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/include/Makefile | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/xen/include/Makefile b/xen/include/Makefile
index 65a732a707..cd271dde0a 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -111,9 +111,10 @@ headers.chk: $(PUBLIC_ANSI_HEADERS) Makefile
 headers99.chk: $(PUBLIC_C99_HEADERS) Makefile
rm -f $@.new
$(foreach i, $(filter %.h,$^),\
-   $(CC) -x c -std=c99 -Wall -Werror \
-   -include stdint.h $(foreach j, $($(i)-prereq), -include $(j).h)   \
-   -S -o /dev/null $(i)  \
+   echo "#include "\"$(i)\"  \
+   | $(CC) -x c -std=c99 -Wall -Werror   \
+ -include stdint.h $(foreach j, $($(i)-prereq), -include $(j).h) \
+ -S -o /dev/null -   \
|| exit $$?; echo $(i) >> $@.new;)
mv $@.new $@
 
-- 
2.11.0


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

Re: [Xen-devel] [OSSTEST PATCH] ts-xtf-run: Understand ./xtf-runner returning CRASH

[Andrew Cooper]

On 07/03/17 15:38, Ian Jackson wrote:
> Andrew Cooper writes ("[OSSTEST PATCH] ts-xtf-run: Understand ./xtf-runner 
> returning CRASH"):
>> ./xtf-runner wants to distinguish between a clean and unclean exits of the
>> test.  OSSTest doesn't care, so map unclean exit to failure.
> Acked-by: Ian Jackson 

Ping on this getting accepted?  I have some XTF improvements queued
behind not breaking OSSTest.

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

Re: [Xen-devel] [PATCH v5 13/30] ARM: GICv3: forward pending LPIs to guests

[Julien Grall]

Hi Andre,

On 06/04/17 00:19, Andre Przywara wrote:

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 270a136..f4d7949 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -1217,6 +1217,12 @@ static int __init gicv2_init(void)
 return 0;
 }

+void gicv2_do_LPI(unsigned int lpi)


This should be static.


+{
+/* No LPIs in a GICv2 */
+BUG();
+}
+


[...]


diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index 0785701..d8baebc 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -136,6 +136,62 @@ uint64_t gicv3_get_redist_address(unsigned int cpu, bool 
use_pta)
 return per_cpu(lpi_redist, cpu).redist_id << 16;
 }

+/*
+ * Handle incoming LPIs, which are a bit special, because they are potentially
+ * numerous and also only get injected into guests. Treat them specially here,
+ * by just looking up their target vCPU and virtual LPI number and hand it
+ * over to the injection function.
+ * Please note that LPIs are edge-triggered only, also have no active state,
+ * so spurious interrupts on the host side are no issue (we can just ignore
+ * them).
+ * Also a guest cannot expect that firing interrupts that haven't been
+ * fully configured yet will reach the CPU, so we don't need to care about
+ * this special case.
+ */
+void gicv3_do_LPI(unsigned int lpi)


Ditto.


+{
+struct domain *d;
+union host_lpi *hlpip, hlpi;
+struct vcpu *vcpu;
+


As mentioned on the previous version, you will need irq_enter and 
irq_exit in the return path. So the common code know you are in an 
interrupt handler (see in_irq()).


[...]


diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 5128f13..2a14305 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1548,12 +1548,24 @@ struct pending_irq *vgic_v3_lpi_to_pending(struct 
domain *d, unsigned int lpi)
 return pirq;
 }

+/* Retrieve the priority of an LPI from its struct pending_irq. */
+int vgic_v3_lpi_get_priority(struct domain *d, uint32_t vlpi)


This should be static.


+{
+struct pending_irq *p = vgic_v3_lpi_to_pending(d, vlpi);
+
+if ( !p )
+return GIC_PRI_IRQ;
+
+return p->lpi_priority;
+}
+
 static const struct vgic_ops v3_ops = {
 .vcpu_init   = vgic_v3_vcpu_init,
 .domain_init = vgic_v3_domain_init,
 .domain_free = vgic_v3_domain_free,
 .emulate_reg  = vgic_v3_emulate_reg,
 .lpi_to_pending = vgic_v3_lpi_to_pending,
+.lpi_get_priority = vgic_v3_lpi_get_priority,
 /*
  * We use both AFF1 and AFF0 in (v)MPIDR. Thus, the max number of CPU
  * that can be supported is up to 4096(==256*16) in theory.


[...]


diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 7c86f5b..08d6294 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -66,12 +66,14 @@ struct pending_irq
 #define GIC_IRQ_GUEST_VISIBLE  2
 #define GIC_IRQ_GUEST_ENABLED  3
 #define GIC_IRQ_GUEST_MIGRATING   4
+#define GIC_IRQ_GUEST_LPI_PENDING 5 /* Caches the pending bit of an LPI. */


Please use the big comment above to describe GUEST_LPI_PENDING.


 unsigned long status;
 struct irq_desc *desc; /* only set it the irq corresponds to a physical 
irq */
 unsigned int irq;
 #define GIC_INVALID_LR (uint8_t)~0
 uint8_t lr;
 uint8_t priority;
+uint8_t lpi_priority;   /* Caches the priority if this is an LPI. */
 /* inflight is used to append instances of pending_irq to
  * vgic.inflight_irqs */
 struct list_head inflight;
@@ -136,6 +138,7 @@ struct vgic_ops {
 bool (*emulate_reg)(struct cpu_user_regs *regs, union hsr hsr);
 /* lookup the struct pending_irq for a given LPI interrupt */
 struct pending_irq *(*lpi_to_pending)(struct domain *d, unsigned int vlpi);
+int (*lpi_get_priority)(struct domain *d, uint32_t vlpi);
 /* Maximum number of vCPU supported */
 const unsigned int max_vcpus;
 };



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 11/30] ARM: GICv3 ITS: introduce device mapping

[Julien Grall]

Hi Andre,

On 06/04/17 17:10, Andre Przywara wrote:

On 06/04/17 16:34, Julien Grall wrote:

+if ( ret )
+{
+do {
+i--;
+gicv3_free_host_lpi_block(dev->host_lpi_blocks[i]);
+if ( i == 0 )
+break;
+} while (1);


This could be  } while ( i > 0 ) saving 3 lines.


Argh, I rewrote this sucker three times because "i" is unsigned and I
apparently missed the easiest solution ;-)
And still there is a bug in there (if the first allocation fails already
above). Do you mind if I revert "i" back to a signed int? That would
allow me to do write "while ( i >= 0 )" here or a for loop.


I was about to say that you can have up 2^32 events (it is silly I 
know), but i represent the block. So I would be ok.


May I ask to add comment? So someone (to not say me) does not go over 
the code and switched to unsigned in the future :).



+
+goto out;
+}
+
+return 0;
+
+out_unlock:
+spin_unlock(>arch.vgic.its_devices_lock);
+
+out:
+if ( dev )
+{
+xfree(dev->pend_irqs);
+xfree(dev->host_lpi_blocks);
+}
+xfree(itt_addr);
+xfree(dev);
+
+return ret;
+}
+


Cheers,




Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 24/30] ARM: vITS: handle MOVI command

[Stefano Stabellini]

On Thu, 6 Apr 2017, Andre Przywara wrote:
> On 06/04/17 01:47, Stefano Stabellini wrote:
> > On Thu, 6 Apr 2017, Andre Przywara wrote:
> >> The MOVI command moves the interrupt affinity from one redistributor
> >> (read: VCPU) to another.
> >> For now migration of "live" LPIs is not yet implemented, but we store
> >> the changed affinity in the host LPI structure and in our virtual ITTE.
> >>
> >> Signed-off-by: Andre Przywara 
> >> ---
> >>  xen/arch/arm/gic-v3-its.c| 24 
> >>  xen/arch/arm/gic-v3-lpi.c| 15 +
> >>  xen/arch/arm/vgic-v3-its.c   | 47 
> >> 
> >>  xen/include/asm-arm/gic_v3_its.h |  4 
> >>  4 files changed, 90 insertions(+)
> >>
> >> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> >> index d970119..a57e63a 100644
> >> --- a/xen/arch/arm/gic-v3-its.c
> >> +++ b/xen/arch/arm/gic-v3-its.c
> >> @@ -851,6 +851,30 @@ struct pending_irq *gicv3_assign_guest_event(struct 
> >> domain *d,
> >>  return pirq;
> >>  }
> >>  
> >> +/* Changes the target VCPU for a given host LPI assigned to a domain. */
> >> +int gicv3_lpi_change_vcpu(struct domain *d, paddr_t vdoorbell,
> >> +  uint32_t vdevid, uint32_t veventid,
> >> +  unsigned int vcpu_id)
> >> +{
> >> +uint32_t host_lpi;
> >> +struct its_devices *dev;
> >> +
> >> +spin_lock(>arch.vgic.its_devices_lock);
> >> +dev = get_its_device(d, vdoorbell, vdevid);
> >> +if ( dev )
> >> +host_lpi = get_host_lpi(dev, veventid);
> >> +else
> >> +host_lpi = 0;
> >> +spin_unlock(>arch.vgic.its_devices_lock);
> >> +
> >> +if ( !host_lpi )
> >> +return -ENOENT;
> >> +
> >> +gicv3_lpi_update_host_vcpuid(host_lpi, vcpu_id);
> > 
> > we need to call vgic_migrate_irq
> 
> Mmmh, are you sure? The very first statement there reads:
> 
> /* nothing to do for virtual interrupts */
> if ( p->desc == NULL )
> return;
> 
> Also my understanding of this command is that it only affects future
> MSIs, so ITS translations. If an MSI has already been translated to a
> certain redistributor and the ITS signaled it already, this command has
> no effect on this particular one.
> Also we don't care about benign races, so if this command comes in a tad
> to late for a just happening MSI, this is the same problem on real hardware.

It is more complicated than I thought. I would add a in-code comment
here like this:

  TODO: we do not change physical irq affinity, in response to a virtual
  movi command. In other words, the physical LPI will still be delivered
  to the same pcpu.

In addition to the comment, I wouldn't mind if also a warning was
printed (with gdprintk).


> >> +return 0;
> >> +}
> >> +
> >>  /* Scan the DT for any ITS nodes and create a list of host ITSes out of 
> >> it. */
> >>  void gicv3_its_dt_init(const struct dt_device_node *node)
> >>  {
> >> diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
> >> index c997ed5..b9960aa 100644
> >> --- a/xen/arch/arm/gic-v3-lpi.c
> >> +++ b/xen/arch/arm/gic-v3-lpi.c
> >> @@ -234,6 +234,21 @@ void gicv3_lpi_update_host_entry(uint32_t host_lpi, 
> >> int domain_id,
> >>  write_u64_atomic(>data, hlpi.data);
> >>  }
> >>  
> >> +int gicv3_lpi_update_host_vcpuid(uint32_t host_lpi, unsigned int vcpu_id)
> >> +{
> >> +union host_lpi *hlpip;
> >> +
> >> +ASSERT(host_lpi >= LPI_OFFSET);
> >> +
> >> +host_lpi -= LPI_OFFSET;
> >> +
> >> +hlpip = _data.host_lpis[host_lpi / HOST_LPIS_PER_PAGE][host_lpi % 
> >> HOST_LPIS_PER_PAGE];
> >> +
> >> +write_u16_atomic(>vcpu_id, vcpu_id);
> >> +
> >> +return 0;
> >> +}
> >> +
> >>  static int gicv3_lpi_allocate_pendtable(uint64_t *reg)
> >>  {
> >>  uint64_t val;
> >> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
> >> index 079dd44..6afb915 100644
> >> --- a/xen/arch/arm/vgic-v3-its.c
> >> +++ b/xen/arch/arm/vgic-v3-its.c
> >> @@ -508,6 +508,47 @@ static int its_handle_mapti(struct virt_its *its, 
> >> uint64_t *cmdptr)
> >>  return 0;
> >>  }
> >>  
> >> +static int its_handle_movi(struct virt_its *its, uint64_t *cmdptr)
> >> +{
> >> +uint32_t devid = its_cmd_get_deviceid(cmdptr);
> >> +uint32_t eventid = its_cmd_get_id(cmdptr);
> >> +int collid = its_cmd_get_collection(cmdptr);
> >> +struct pending_irq *p;
> >> +struct vcpu *vcpu;
> >> +uint32_t vlpi;
> >> +int ret = -1;
> >> +
> >> +spin_lock(>its_lock);
> >> +/* Check for a mapped LPI and get the LPI number. */
> >> +if ( !read_itte_locked(its, devid, eventid, , ) )
> >> +goto out_unlock;
> >> +
> >> +/* Check the new collection ID and get the new VCPU pointer */
> >> +vcpu = get_vcpu_from_collection(its, collid);
> >> +if ( !vcpu )
> >> +goto out_unlock;
> >> +
> >> +/* Update our cached vcpu_id in the pending_irq. */
> >> +p = 

Re: [Xen-devel] [PATCH for-4.9] xen: append -Wno-unused-function to C99 header check

[Wei Liu]

On Thu, Apr 06, 2017 at 09:51:32AM -0700, Stefano Stabellini wrote:
> On Thu, 6 Apr 2017, Jan Beulich wrote:
> > >>> On 06.04.17 at 14:54,  wrote:
> > > --- a/xen/include/Makefile
> > > +++ b/xen/include/Makefile
> > > @@ -111,7 +111,7 @@ headers.chk: $(PUBLIC_ANSI_HEADERS) Makefile
> > >  headers99.chk: $(PUBLIC_C99_HEADERS) Makefile
> > >   rm -f $@.new
> > >   $(foreach i, $(filter %.h,$^),\
> > > - $(CC) -x c -std=c99 -Wall -Werror \
> > > + $(CC) -x c -std=c99 -Wall -Werror -Wno-unused-function\
> > >   -include stdint.h $(foreach j, $($(i)-prereq), -include $(j).h)   \
> > >   -S -o /dev/null $(i)  \
> > >   || exit $$?; echo $(i) >> $@.new;)
> > 
> > I think it would be better to make this match the C++ check, where
> > a source file is being generated on the fly (and quite possibly for a
> > similar reason).
>  
> I don't have an opinion on what is the best way to fix this. However,
> I'll say that it is expected to have unused functions in header files
> (it would be a problem if there weren't), so -Wno-unused-function looks
> fine to me.
> 
> Wei, given that the problem was introduced by my patch, let me know if
> you need any help fixing this.
> 

No need. I have another patch queued up for posting -- waiting for
report from travis.

Wei.

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

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

[Xen-devel] Release-ack before the code freeze

[Julien Grall]

Hi all

It looks like there a lot of patch waiting on the mailing list for a 
release-ack.


To simplify things, I will forgo the requirement of release-ack until 
the code freeze and leave the call to the committers.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 13/30] ARM: GICv3: forward pending LPIs to guests

[Andre Przywara]

Hi Stefano,

thanks for spending your brain cells on this nasty code.

...

On 06/04/17 00:45, Stefano Stabellini wrote:
> On Thu, 6 Apr 2017, Andre Przywara wrote:
>> Upon receiving an LPI on the host, we need to find the right VCPU and
>> virtual IRQ number to get this IRQ injected.
>> Iterate our two-level LPI table to find this information quickly when
>> the host takes an LPI. Call the existing injection function to let the
>> GIC emulation deal with this interrupt.
>> Also we enhance struct pending_irq to cache the pending bit and the
>> priority information for LPIs, as we can't afford to walk the tables in
>> guest memory every time we handle an incoming LPI.
>> This introduces a do_LPI() as a hardware gic_ops and a function to
>> retrieve the (cached) priority value of an LPI and a vgic_ops.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/gic-v2.c|  7 +
>>  xen/arch/arm/gic-v3-lpi.c| 56 
>> 
>>  xen/arch/arm/gic-v3.c|  1 +
>>  xen/arch/arm/gic.c   |  8 +-
>>  xen/arch/arm/vgic-v2.c   |  7 +
>>  xen/arch/arm/vgic-v3.c   | 12 +
>>  xen/arch/arm/vgic.c  |  7 -
>>  xen/include/asm-arm/gic.h|  2 ++
>>  xen/include/asm-arm/gic_v3_its.h |  8 ++
>>  xen/include/asm-arm/vgic.h   |  3 +++
>>  10 files changed, 109 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> index 270a136..f4d7949 100644
>> --- a/xen/arch/arm/gic-v2.c
>> +++ b/xen/arch/arm/gic-v2.c
>> @@ -1217,6 +1217,12 @@ static int __init gicv2_init(void)
>>  return 0;
>>  }
>>  
>> +void gicv2_do_LPI(unsigned int lpi)
>> +{
>> +/* No LPIs in a GICv2 */
>> +BUG();
>> +}
>> +
>>  const static struct gic_hw_operations gicv2_ops = {
>>  .info= _info,
>>  .init= gicv2_init,
>> @@ -1244,6 +1250,7 @@ const static struct gic_hw_operations gicv2_ops = {
>>  .make_hwdom_madt = gicv2_make_hwdom_madt,
>>  .map_hwdom_extra_mappings = gicv2_map_hwdown_extra_mappings,
>>  .iomem_deny_access   = gicv2_iomem_deny_access,
>> +.do_LPI  = gicv2_do_LPI,
>>  };
>>  
>>  /* Set up the GIC */
>> diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
>> index 0785701..d8baebc 100644
>> --- a/xen/arch/arm/gic-v3-lpi.c
>> +++ b/xen/arch/arm/gic-v3-lpi.c
>> @@ -136,6 +136,62 @@ uint64_t gicv3_get_redist_address(unsigned int cpu, 
>> bool use_pta)
>>  return per_cpu(lpi_redist, cpu).redist_id << 16;
>>  }
>>  
>> +/*
>> + * Handle incoming LPIs, which are a bit special, because they are 
>> potentially
>> + * numerous and also only get injected into guests. Treat them specially 
>> here,
>> + * by just looking up their target vCPU and virtual LPI number and hand it
>> + * over to the injection function.
>> + * Please note that LPIs are edge-triggered only, also have no active state,
>> + * so spurious interrupts on the host side are no issue (we can just ignore
>> + * them).
>> + * Also a guest cannot expect that firing interrupts that haven't been
>> + * fully configured yet will reach the CPU, so we don't need to care about
>> + * this special case.
>> + */
>> +void gicv3_do_LPI(unsigned int lpi)
>> +{
>> +struct domain *d;
>> +union host_lpi *hlpip, hlpi;
>> +struct vcpu *vcpu;
>> +
>> +/* EOI the LPI already. */
>> +WRITE_SYSREG32(lpi, ICC_EOIR1_EL1);
>> +
>> +/* Find out if a guest mapped something to this physical LPI. */
>> +hlpip = gic_get_host_lpi(lpi);
>> +if ( !hlpip )
>> +return;
>> +
>> +hlpi.data = read_u64_atomic(>data);
>> +
>> +/*
>> + * Unmapped events are marked with an invalid LPI ID. We can safely
>> + * ignore them, as they have no further state and no-one can expect
>> + * to see them if they have not been mapped.
>> + */
>> +if ( hlpi.virt_lpi == INVALID_LPI )
>> +return;
>> +
>> +d = rcu_lock_domain_by_id(hlpi.dom_id);
>> +if ( !d )
>> +return;
>> +
>> +/* Make sure we don't step beyond the vcpu array. */
>> +if ( hlpi.vcpu_id >= d->max_vcpus )
>> +{
>> +rcu_unlock_domain(d);
>> +return;
>> +}
>> +
>> +vcpu = d->vcpu[hlpi.vcpu_id];
>> +
>> +/* Check if the VCPU is ready to receive LPIs. */
>> +if ( vcpu->arch.vgic.flags & VGIC_V3_LPIS_ENABLED )
>> +vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);
>> +
>> +rcu_unlock_domain(d);
>> +}
>> +
>>  static int gicv3_lpi_allocate_pendtable(uint64_t *reg)
>>  {
>>  uint64_t val;
>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
>> index a559e5e..63dbc21 100644
>> --- a/xen/arch/arm/gic-v3.c
>> +++ b/xen/arch/arm/gic-v3.c
>> @@ -1670,6 +1670,7 @@ static const struct gic_hw_operations gicv3_ops = {
>>  .make_hwdom_dt_node  = gicv3_make_hwdom_dt_node,
>>  .make_hwdom_madt = gicv3_make_hwdom_madt,
>>  

Re: [Xen-devel] [PATCH] arm64: xen: Implement EFI reset_system callback

[Juergen Gross]

On 06/04/17 18:43, Daniel Kiper wrote:
> On Thu, Apr 06, 2017 at 06:22:44PM +0200, Juergen Gross wrote:
>> On 06/04/17 18:06, Daniel Kiper wrote:
>>> Hi Julien,
>>>
>>> On Thu, Apr 06, 2017 at 04:39:13PM +0100, Julien Grall wrote:
 Hi Daniel,

 On 06/04/17 16:20, Daniel Kiper wrote:
> On Thu, Apr 06, 2017 at 04:38:24PM +0200, Juergen Gross wrote:
>> On 06/04/17 16:27, Daniel Kiper wrote:
>>> On Thu, Apr 06, 2017 at 09:32:32AM +0100, Julien Grall wrote:
 Hi Juergen,

 On 06/04/17 07:23, Juergen Gross wrote:
> On 05/04/17 21:49, Boris Ostrovsky wrote:
>> On 04/05/2017 02:14 PM, Julien Grall wrote:
>>> The x86 code has theoritically a similar issue, altought EFI does 
>>> not
>>> seem to be the preferred method. I have left it unimplemented on 
>>> x86 and
>>> CCed Linux Xen x86 maintainers to know their view here.
>>
>> (+Daniel)
>>
>> This could be a problem for x86 as well, at least theoretically.
>> xen_machine_power_off() may call pm_power_off(), which is 
>> efi.reset_system.
>>
>> So I think we should have a similar routine there.
>
> +1
>
> I don't see any problem with such a routine added, in contrast to
> potential "reboots" instead of power off without it.
>
> So I think this dummy xen_efi_reset_system() should be added to
> drivers/xen/efi.c instead.

 I will resend the patch during day with xen_efi_reset_system moved
 to common code and implement the x86 counterpart (thought, I will
 not be able to test it).
>>>
>>> I think that this is ARM specific issue. On x86 machine_restart() calls
>>> xen_restart(). Hence, everything works. So, I think that it should be
>>> fixed only for ARM. Anyway, please CC me when you send a patch.
>>
>> What about xen_machine_power_off() (as stated in Boris' mail)?
>
> Guys what do you think about that:
>
> --- a/drivers/firmware/efi/reboot.c
> +++ b/drivers/firmware/efi/reboot.c
> @@ -55,7 +55,7 @@ static void efi_power_off(void)
>
> static int __init efi_shutdown_init(void)
> {
> -   if (!efi_enabled(EFI_RUNTIME_SERVICES))
> +   if (!efi_enabled(EFI_RUNTIME_SERVICES) || 
> efi_enabled(EFI_PARAVIRT))
>return -ENODEV;
>
>if (efi_poweroff_required())
>
>
> Julien, for ARM64 please take a look at 
> arch/arm64/kernel/efi.c:efi_poweroff_required(void).
>
> I hope that tweaks for both files should solve our problem.

 This sounds good for power off (I haven't tried to power off DOM0
 yet). But this will not solve the restart problem (see
 machine_restart in arch/arm64/kernel/process.c) which call directly
 efi_reboot.
>>>
>>> Hmmm... It seems to me that efi.reset_system override with empty function
>>> in arch/arm/xen/efi.c is the best solution. So, I see three patches here.
>>> One for drivers/firmware/efi/reboot.c, one for arch/arm/xen/efi.c and one
>>> for arch/arm64/kernel/efi.c. Does it make sense?
>>
>> I still think the empty function should be in drivers/xen/efi.c and we
>> should use it in arch/x86/xen/efi.c, too.
> 
> If you wish we can go that way too. Though I thing that we should fix
> drivers/firmware/efi/reboot.c:efi_shutdown_init() too. Just in case.

Sure, go ahead. I won't object.


Juergen


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

[Xen-devel] [OSSTEST PATCH 2/4] proxy config: Add ability to install MITM TLS cert

[Ian Jackson]

We want things like build jobs to be able to download things via
https.  But we want them to be cached.  To this end, we are having our
squid treat CONNECT as a request to MITM the TLS connection.

But this means that clients will see squid's cert, not the real one.
So placate them by installing the cert on each test box.

(The squid becomes part of the TCB for our coverity upload password,
but that is fine.)

Signed-off-by: Ian Jackson 
---
 Osstest/TestSupport.pm | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 1cc09be..ac9726c 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -2587,6 +2587,7 @@ sub host_install_postboot_complete ($) {
 my ($ho) = @_;
 target_core_dump_setup($ho);
 target_cmd_root($ho, "update-rc.d osstest-confirm-booted start 99 2 .");
+target_https_mitm_proxy_setup($ho);
 }
 
 sub target_core_dump_setup ($) {
@@ -2607,4 +2608,13 @@ END
'/etc/security/limits.d/coredumps.conf');
 }
 
+sub target_https_mitm_proxy_setup ($) {
+my ($ho) = @_;
+my $cert = $c{HttpsProxyMITMCert};
+return unless length $cert;
+target_putfilecontents_root_stash($ho,30,$cert,
+  '/usr/local/share/ca-certificates/osstest.crt');
+target_cmd_root($ho, 'update-ca-certificates', 300);
+}
+
 1;
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 3/4] proxy config: Add MITM cert for Massachusetts

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
 production-config | 25 +
 1 file changed, 25 insertions(+)

diff --git a/production-config b/production-config
index a95e243..07cf5a6 100644
--- a/production-config
+++ b/production-config
@@ -140,3 +140,28 @@ ssh-rsa 
B3NzaC1yc2EDAQABAAABAQDY+wyHPeVjiqPzmKZxSxA0fxQ8r0zKMN1cYxJrryE6
 ssh-rsa 
B3NzaC1yc2EDAQABAAABgQCxArew0DKa3mGEx73adSfaWowq0At3+QbA/LYh/lIw1Wn4YkgxXh2OS1/7NUjNu0IGjnHLelG+HHhUv1fH5JunNJj+GLRsU09dag8LVmbmX0fkebJg6a4iKSXREgoM7NcDn3lA5HXTiNq1Q0To7fb09tZ5wG2inaDvt8PMhVF+CsJXbfPGqJcnKyYosNMCIj6HVwvUl4UAyfyil3CfhklV8Dk1Wd626R93Q39TRrnV3Cm+xVSX2MEfY5mIaqYGeHSPhybqI/h6J6fVTRGNc2Y4oEwWd0ElZbRpCJ5OQx5oV4qMcCh4MSdOC5ZcSv1j3KLaehkwbLjKzpm4hf+2+bkRvua/4nMRWlDNG2C/k05Lt363OJkmUUR2DT+2Cf5P44WmhZeo3ekTN2Z19x8TGGU60UznbscPn/ri0F0bfAtLjlXgxG8W/L7i885uxTrETin6jrY/BBj7G/Fqu6ZffIQvhrww53vv3a/0VYYKBJ9c7HvTI0C5UugbV7oyHbT/2l0=
 ianc@osstest-ansible-generated
 
 END
+
+HttpsProxyMITMCert= <<'END'
+-BEGIN CERTIFICATE-
+MIIDtzCCAp+gAwIBAgIJAKYOfDsTZAKAMA0GCSqGSIb3DQEBCwUAMHIxCzAJBgNV
+BAYTAlVTMQswCQYDVQQIDAJNQTETMBEGA1UECgwKeGVucHJvamVjdDEZMBcGA1UE
+CwwQeGVucHJvamVjdF9zcXVpZDEmMCQGA1UEAwwdY2FjaGUudGVzdC1sYWIueGVu
+cHJvamVjdC5vcmcwHhcNMTcwMzA5MTI0NTI3WhcNMTkwMzA5MTI0NTI3WjByMQsw
+CQYDVQQGEwJVUzELMAkGA1UECAwCTUExEzARBgNVBAoMCnhlbnByb2plY3QxGTAX
+BgNVBAsMEHhlbnByb2plY3Rfc3F1aWQxJjAkBgNVBAMMHWNhY2hlLnRlc3QtbGFi
+LnhlbnByb2plY3Qub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
+9WoZTo/f0bLYz+BAWGVt5f1Wycj05Mil3DU875Sql80giqU2b80rzwB60Puf/0Sp
+5kx8twY8QvR+JthLS4mfSddDq+W+ZwMbrEpp5E8Le+mdrw4YDkdu9bx47NrWOKqF
+z7Q+WONCq75YAWaa0b1Jp6fqQichNbkCdZY3hvemB7ZI+CFWuirOhzcqrZlS88qu
+iF9W0Oj+0O31ZThNVaINUqfrYO3xIbOwJl6qEcp/cAGvFr7ux3KiAg/Tc69xRn+U
+Heh4kbqOlkE8W5wn+0wiei0sEbgi9zxPVnu1XQY1LBh9zh7gbFt7X9ZKka7YlM4H
++IzRHcZl33kY2aVCNF4c6QIDAQABo1AwTjAdBgNVHQ4EFgQUpkoT3BVZ14oKu6qe
+Tt6aMvZ3sKEwHwYDVR0jBBgwFoAUpkoT3BVZ14oKu6qeTt6aMvZ3sKEwDAYDVR0T
+BAUwAwEB/zANBgkqhkiG9w0BAQsFAAOCAQEAgKYcfH8ykXgnXJVSv1U7carxV/O/
+Io76jrXi3NtqXSugadzakFEOgjkNAfeOrtmQRAF6JuFhPfhweWvnfYGXV/QrxF7N
+nkCVhvNTsyNM2WDeuBtzj/CBoyk0jBkwxdcG3SLEx/sHKPkTPziFuXcPvITdaP2a
+DC+NgIdL3FmEfzaabbDdrgGRt+/vfvu877atvrX1/B5/NOL+7mXaTR6jzuJRQeXK
+ftnS+ZW/GlbttfovPgFN/FjUioenfS9IS1IBwCJ4d9uHDbgOgL6uhEQ0Iq8Ou68f
+L6qOW4qBJldqxl9VX2RqcJExP0YwrvqmdsdC+xsTmXnOtpUkAYKNrvh7dg==
+-END CERTIFICATE-
+END
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 4/4] proxy config: Set https_proxy too

[Ian Jackson]

Clients including curl honour https_proxy (not http_proxy) in the
environment for https:// urls.

Signed-off-by: Ian Jackson 
---
 Osstest/TestSupport.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index ac9726c..4ced6c0 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1891,7 +1891,7 @@ sub http_proxy_envsettings ($) {
 my $proxy = $c{HttpProxy};
 return unless $proxy;
 my @script;
-foreach my $var (qw(http_proxy)) {
+foreach my $var (qw(http_proxy https_proxy)) {
 push @script, "http_proxy=$proxy", "export http_proxy";
 }
 return (join '; ', @script).';';
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 1/4] proxy config: Factor out http_proxy_envsettings

[Ian Jackson]

No overall functional change, other than slight syntax changes to
generated shell runes.

Signed-off-by: Ian Jackson 
---
 Osstest/TestSupport.pm | 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 6ca8076..1cc09be 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -60,6 +60,7 @@ BEGIN {
  target_putfilecontents_root_stash
   target_put_guest_image target_editfile
   target_editfile_cancel target_fetchurl
+  http_proxy_envsettings
   target_editfile_root target_file_exists
   target_editfile_kvp_replace
   target_run_apt
@@ -625,15 +626,13 @@ sub target_cmd_build () {
 export CCACHE_PREFIX DISTCC_FALLBACK DISTCC_HOSTS
 END
 
-my $httpproxy = defined($c{HttpProxy}) ? 

[Xen-devel] [PATCH for-next 3/7] x86/traps: lift do_guest_trap to traps.h

[Wei Liu]

And rename it to pv_inject_guest_trap. It will be needed later when some
PV specific code is moved.

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/traps.c | 61 ++--
 xen/include/asm-x86/domain.h | 12 +
 2 files changed, 37 insertions(+), 36 deletions(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 0d54baf20e..a1981289a4 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -684,18 +684,6 @@ void pv_inject_event(const struct x86_event *event)
 }
 }
 
-static inline void do_guest_trap(unsigned int trapnr,
- const struct cpu_user_regs *regs)
-{
-const struct x86_event event = {
-.vector = trapnr,
-.error_code = (((trapnr < 32) && (TRAP_HAVE_EC & (1u << trapnr)))
-   ? regs->error_code : X86_EVENT_NO_EC),
-};
-
-pv_inject_event();
-}
-
 static void instruction_done(struct cpu_user_regs *regs, unsigned long rip)
 {
 regs->rip = rip;
@@ -703,7 +691,7 @@ static void instruction_done(struct cpu_user_regs *regs, 
unsigned long rip)
 if ( regs->eflags & X86_EFLAGS_TF )
 {
 current->arch.debugreg[6] |= DR_STEP | DR_STATUS_RESERVED_ONE;
-do_guest_trap(TRAP_debug, regs);
+pv_inject_guest_trap(TRAP_debug, regs);
 }
 }
 
@@ -751,7 +739,7 @@ int set_guest_machinecheck_trapbounce(void)
 struct vcpu *v = current;
 struct trap_bounce *tb = >arch.pv_vcpu.trap_bounce;
  
-do_guest_trap(TRAP_machine_check, guest_cpu_user_regs());
+pv_inject_guest_trap(TRAP_machine_check, guest_cpu_user_regs());
 tb->flags &= ~TBF_EXCEPTION; /* not needed for MCE delivery path */
 return !null_trap_bounce(v, tb);
 }
@@ -764,7 +752,7 @@ int set_guest_nmi_trapbounce(void)
 {
 struct vcpu *v = current;
 struct trap_bounce *tb = >arch.pv_vcpu.trap_bounce;
-do_guest_trap(TRAP_nmi, guest_cpu_user_regs());
+pv_inject_guest_trap(TRAP_nmi, guest_cpu_user_regs());
 tb->flags &= ~TBF_EXCEPTION; /* not needed for NMI delivery path */
 return !null_trap_bounce(v, tb);
 }
@@ -794,7 +782,7 @@ void do_trap(struct cpu_user_regs *regs)
 
 if ( guest_mode(regs) )
 {
-do_guest_trap(trapnr, regs);
+pv_inject_guest_trap(trapnr, regs);
 return;
 }
 
@@ -1060,7 +1048,7 @@ static int emulate_forced_invalid_op(struct cpu_user_regs 
*regs)
 if ( current->arch.cpuid_faulting && !guest_kernel_mode(current, regs) )
 {
 regs->rip = eip;
-do_guest_trap(TRAP_gp_fault, regs);
+pv_inject_guest_trap(TRAP_gp_fault, regs);
 return EXCRET_fault_fixed;
 }
 
@@ -1096,7 +1084,7 @@ void do_invalid_op(struct cpu_user_regs *regs)
 {
 if ( !emulate_invalid_rdtscp(regs) &&
  !emulate_forced_invalid_op(regs) )
-do_guest_trap(TRAP_invalid_op, regs);
+pv_inject_guest_trap(TRAP_invalid_op, regs);
 return;
 }
 
@@ -1210,7 +1198,7 @@ void do_int3(struct cpu_user_regs *regs)
 return;
 } 
 
-do_guest_trap(TRAP_int3, regs);
+pv_inject_guest_trap(TRAP_int3, regs);
 }
 
 static void reserved_bit_page_fault(
@@ -3023,7 +3011,7 @@ static int emulate_privileged_op(struct cpu_user_regs 
*regs)
 {
 curr->arch.debugreg[6] |= ctxt.bpmatch | DR_STATUS_RESERVED_ONE;
 if ( !(curr->arch.pv_vcpu.trap_bounce.flags & TBF_EXCEPTION) )
-do_guest_trap(TRAP_debug, regs);
+pv_inject_guest_trap(TRAP_debug, regs);
 }
 /* fall through */
 case X86EMUL_RETRY:
@@ -3138,12 +3126,12 @@ static void emulate_gate_op(struct cpu_user_regs *regs)
  (((ar >> 13) & 3) < (regs->cs & 3)) ||
  ((ar & _SEGMENT_TYPE) != 0xc00) )
 {
-do_guest_trap(TRAP_gp_fault, regs);
+pv_inject_guest_trap(TRAP_gp_fault, regs);
 return;
 }
 if ( !(ar & _SEGMENT_P) )
 {
-do_guest_trap(TRAP_no_segment, regs);
+pv_inject_guest_trap(TRAP_no_segment, regs);
 return;
 }
 dpl = (ar >> 13) & 3;
@@ -3159,7 +3147,7 @@ static void emulate_gate_op(struct cpu_user_regs *regs)
  !(ar & _SEGMENT_P) ||
  !(ar & _SEGMENT_CODE) )
 {
-do_guest_trap(TRAP_gp_fault, regs);
+pv_inject_guest_trap(TRAP_gp_fault, regs);
 return;
 }
 
@@ -3177,7 +3165,7 @@ static void emulate_gate_op(struct cpu_user_regs *regs)
 else
 {
 ASSERT(!ctxt.ctxt.event_pending);
-do_guest_trap(TRAP_gp_fault, regs);
+pv_inject_guest_trap(TRAP_gp_fault, regs);
 }
 return;
 }
@@ -3231,7 +3219,7 @@ static void emulate_gate_op(struct cpu_user_regs *regs)
  (opnd_sel & ~3) != regs->error_code ||
  dpl < (opnd_sel & 3) )
 {
-do_guest_trap(TRAP_gp_fault, regs);
+pv_inject_guest_trap(TRAP_gp_fault, regs);
 return;
 }
 
@@ -3279,7 

[Xen-devel] [PATCH for-next 7/7] x86: clean up traps.c

[Wei Liu]

Delete all trailing white spaces. Replace bool_t with bool.

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/traps.c | 50 +-
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 351bb950d8..4481615e2c 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1,18 +1,18 @@
 /**
  * arch/x86/traps.c
- * 
+ *
  * Modifications to Linux original are copyright (c) 2002-2004, K A Fraser
- * 
+ *
  * 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.
- * 
+ *
  * You should have received a copy of the GNU General Public License
  * along with this program; If not, see .
  */
@@ -110,7 +110,7 @@ void (*ioemul_handle_quirk)(
 static int debug_stack_lines = 20;
 integer_param("debug_stack_lines", debug_stack_lines);
 
-static bool_t opt_ler;
+static bool opt_ler;
 boolean_param("ler", opt_ler);
 
 #define stack_words_per_line 4
@@ -525,7 +525,7 @@ void vcpu_show_execution_state(struct vcpu *v)
 }
 
 static cpumask_t show_state_mask;
-static bool_t opt_show_all;
+static bool opt_show_all;
 boolean_param("async-show-all", opt_show_all);
 
 static int nmi_show_execution_state(const struct cpu_user_regs *regs, int cpu)
@@ -548,7 +548,7 @@ static int nmi_show_execution_state(const struct 
cpu_user_regs *regs, int cpu)
  * are disabled). In such situations we can't do much that is safe. We try to
  * print out some tracing and then we just spin.
  */
-void fatal_trap(const struct cpu_user_regs *regs, bool_t show_remote)
+void fatal_trap(const struct cpu_user_regs *regs, bool show_remote)
 {
 static DEFINE_PER_CPU(char, depth);
 unsigned int trapnr = regs->entry_vector;
@@ -978,7 +978,7 @@ void do_int3(struct cpu_user_regs *regs)
 {
 debugger_trap_fatal(TRAP_int3, regs);
 return;
-} 
+}
 
 pv_inject_guest_trap(TRAP_int3, regs);
 }
@@ -1328,9 +1328,9 @@ void do_page_fault(struct cpu_user_regs *regs)
 
 /*
  * Early #PF handler to print CR2, error code, and stack.
- * 
+ *
  * We also deal with spurious faults here, even though they should never happen
- * during early boot (an issue was seen once, but was most likely a hardware 
+ * during early boot (an issue was seen once, but was most likely a hardware
  * problem).
  */
 void __init do_early_page_fault(struct cpu_user_regs *regs)
@@ -1374,7 +1374,7 @@ void do_general_protection(struct cpu_user_regs *regs)
 
 /*
  * Cunning trick to allow arbitrary "INT n" handling.
- * 
+ *
  * We set DPL == 0 on all vectors in the IDT. This prevents any INT 
  * instruction from trapping to the appropriate vector, when that might not
  * be expected by Xen or the guest OS. For example, that entry might be for
@@ -1382,12 +1382,12 @@ void do_general_protection(struct cpu_user_regs *regs)
  * expect an error code on the stack (which a software trap never
  * provides), or might be a hardware interrupt handler that doesn't like
  * being called spuriously.
- * 
+ *
  * Instead, a GPF occurs with the faulting IDT vector in the error code.
- * Bit 1 is set to indicate that an IDT entry caused the fault. Bit 0 is 
+ * Bit 1 is set to indicate that an IDT entry caused the fault. Bit 0 is
  * clear (which got already checked above) to indicate that it's a software
  * fault, not a hardware one.
- * 
+ *
  * NOTE: Vectors 3 and 4 are dealt with from their own handler. This is
  * okay because they can only be triggered by an explicit DPL-checked
  * instruction. The DPL specified by the guest OS for these vectors is NOT
@@ -1586,14 +1586,14 @@ static int dummy_nmi_callback(const struct 
cpu_user_regs *regs, int cpu)
 {
 return 0;
 }
- 
+
 static nmi_callback_t *nmi_callback = dummy_nmi_callback;
 
 void do_nmi(const struct cpu_user_regs *regs)
 {
 unsigned int cpu = smp_processor_id();
 unsigned char reason;
-bool_t handle_unknown = 0;
+bool handle_unknown = false;
 
 ++nmi_count(cpu);
 
@@ -1602,7 +1602,7 @@ void do_nmi(const struct cpu_user_regs *regs)
 
 if ( (nmi_watchdog == NMI_NONE) ||
  (!nmi_watchdog_tick(regs) && watchdog_force) )
-handle_unknown = 1;
+handle_unknown = true;
 
 /* Only the BSP gets external NMIs from the system. */
 if ( cpu == 0 )
@@ -1982,28 +1982,28 @@ long 

[Xen-devel] [PATCH for-next 5/7] x86_64: move PV specific code under pv/x86_64

[Wei Liu]

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/Makefile|   1 +
 xen/arch/x86/pv/x86_64/Makefile |   1 +
 xen/arch/x86/{ => pv}/x86_64/compat/traps.c |   0
 xen/arch/x86/pv/x86_64/traps.c  | 398 
 xen/arch/x86/x86_64/traps.c | 377 --
 5 files changed, 400 insertions(+), 377 deletions(-)
 create mode 100644 xen/arch/x86/pv/x86_64/Makefile
 rename xen/arch/x86/{ => pv}/x86_64/compat/traps.c (100%)
 create mode 100644 xen/arch/x86/pv/x86_64/traps.c

diff --git a/xen/arch/x86/pv/Makefile b/xen/arch/x86/pv/Makefile
index c996dcc149..d4aca44c06 100644
--- a/xen/arch/x86/pv/Makefile
+++ b/xen/arch/x86/pv/Makefile
@@ -1,4 +1,5 @@
 subdir-y += compat
+subdir-y += x86_64
 
 obj-y += hypercall.o
 obj-bin-y += dom0_build.init.o
diff --git a/xen/arch/x86/pv/x86_64/Makefile b/xen/arch/x86/pv/x86_64/Makefile
new file mode 100644
index 00..c55c340bc1
--- /dev/null
+++ b/xen/arch/x86/pv/x86_64/Makefile
@@ -0,0 +1 @@
+obj-y += traps.o
diff --git a/xen/arch/x86/x86_64/compat/traps.c 
b/xen/arch/x86/pv/x86_64/compat/traps.c
similarity index 100%
rename from xen/arch/x86/x86_64/compat/traps.c
rename to xen/arch/x86/pv/x86_64/compat/traps.c
diff --git a/xen/arch/x86/pv/x86_64/traps.c b/xen/arch/x86/pv/x86_64/traps.c
new file mode 100644
index 00..ec7d23eaf7
--- /dev/null
+++ b/xen/arch/x86/pv/x86_64/traps.c
@@ -0,0 +1,398 @@
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+void toggle_guest_mode(struct vcpu *v)
+{
+if ( is_pv_32bit_vcpu(v) )
+return;
+if ( cpu_has_fsgsbase )
+{
+if ( v->arch.flags & TF_kernel_mode )
+v->arch.pv_vcpu.gs_base_kernel = __rdgsbase();
+else
+v->arch.pv_vcpu.gs_base_user = __rdgsbase();
+}
+v->arch.flags ^= TF_kernel_mode;
+asm volatile ( "swapgs" );
+update_cr3(v);
+/* Don't flush user global mappings from the TLB. Don't tick TLB clock. */
+asm volatile ( "mov %0, %%cr3" : : "r" (v->arch.cr3) : "memory" );
+if ( !(v->arch.flags & TF_kernel_mode) )
+return;
+
+if ( v->arch.pv_vcpu.need_update_runstate_area &&
+ update_runstate_area(v) )
+v->arch.pv_vcpu.need_update_runstate_area = 0;
+
+if ( v->arch.pv_vcpu.pending_system_time.version &&
+ update_secondary_system_time(v,
+  >arch.pv_vcpu.pending_system_time) )
+v->arch.pv_vcpu.pending_system_time.version = 0;
+}
+
+unsigned long do_iret(void)
+{
+struct cpu_user_regs *regs = guest_cpu_user_regs();
+struct iret_context iret_saved;
+struct vcpu *v = current;
+
+if ( unlikely(copy_from_user(_saved, (void *)regs->rsp,
+ sizeof(iret_saved))) )
+{
+gprintk(XENLOG_ERR,
+"Fault while reading IRET context from guest stack\n");
+goto exit_and_crash;
+}
+
+/* Returning to user mode? */
+if ( (iret_saved.cs & 3) == 3 )
+{
+if ( unlikely(pagetable_is_null(v->arch.guest_table_user)) )
+{
+gprintk(XENLOG_ERR,
+"Guest switching to user mode with no user page tables\n");
+goto exit_and_crash;
+}
+toggle_guest_mode(v);
+}
+
+if ( VM_ASSIST(v->domain, architectural_iopl) )
+v->arch.pv_vcpu.iopl = iret_saved.rflags & X86_EFLAGS_IOPL;
+
+regs->rip= iret_saved.rip;
+regs->cs = iret_saved.cs | 3; /* force guest privilege */
+regs->rflags = ((iret_saved.rflags & ~(X86_EFLAGS_IOPL|X86_EFLAGS_VM))
+| X86_EFLAGS_IF);
+regs->rsp= iret_saved.rsp;
+regs->ss = iret_saved.ss | 3; /* force guest privilege */
+
+if ( !(iret_saved.flags & VGCF_in_syscall) )
+{
+regs->entry_vector &= ~TRAP_syscall;
+regs->r11 = iret_saved.r11;
+regs->rcx = iret_saved.rcx;
+}
+
+/* Restore upcall mask from supplied EFLAGS.IF. */
+vcpu_info(v, evtchn_upcall_mask) = !(iret_saved.rflags & X86_EFLAGS_IF);
+
+async_exception_cleanup(v);
+
+/* Saved %rax gets written back to regs->rax in entry.S. */
+return iret_saved.rax;
+
+ exit_and_crash:
+domain_crash(v->domain);
+return 0;
+}
+
+static unsigned int write_stub_trampoline(
+unsigned char *stub, unsigned long stub_va,
+unsigned long stack_bottom, unsigned long target_va)
+{
+/* movabsq %rax, stack_bottom - 8 */
+stub[0] = 0x48;
+stub[1] = 0xa3;
+*(uint64_t *)[2] = stack_bottom - 8;
+
+/* movq %rsp, %rax */
+stub[10] = 0x48;
+stub[11] = 0x89;
+stub[12] = 0xe0;
+
+/* movabsq $stack_bottom - 8, %rsp */
+stub[13] = 0x48;
+stub[14] = 0xbc;
+*(uint64_t *)[15] = stack_bottom - 8;
+
+/* pushq %rax */
+stub[23] = 0x50;
+
+/* jmp target_va */
+stub[24] = 0xe9;
+*(int32_t *)[25] = target_va - 

[Xen-devel] [PATCH for-next 0/7] Refactor x86 trap handling code

[Wei Liu]

This series splits PV code related to trap handling to files under pv
directory.

The final two patches are clean-up that seem easy enough to do.

Wei Liu (7):
  x86: move x86_64/entry.S to pv directory
  x86: move x86_64/compat/entry.S to pv/compat
  x86/traps: lift do_guest_trap to traps.h
  x86/traps: move all PV emulation and hypercalls to pv/traps.c
  x86_64: move PV specific code under pv/x86_64
  x86: s/bool_t/bool/g in pv/traps.c
  x86: clean up traps.c

 xen/arch/x86/pv/Makefile|5 +
 xen/arch/x86/{x86_64 => pv}/compat/Makefile |0
 xen/arch/x86/{x86_64 => pv}/compat/entry.S  |0
 xen/arch/x86/{x86_64 => pv}/entry.S |0
 xen/arch/x86/pv/traps.c | 2152 
 xen/arch/x86/pv/x86_64/Makefile |1 +
 xen/arch/x86/{ => pv}/x86_64/compat/traps.c |0
 xen/arch/x86/pv/x86_64/traps.c  |  398 +
 xen/arch/x86/traps.c| 2346 ++-
 xen/arch/x86/x86_64/Makefile|3 -
 xen/arch/x86/x86_64/traps.c |  377 -
 xen/include/asm-x86/domain.h|   12 +
 xen/include/asm-x86/traps.h |   19 +
 13 files changed, 2699 insertions(+), 2614 deletions(-)
 rename xen/arch/x86/{x86_64 => pv}/compat/Makefile (100%)
 rename xen/arch/x86/{x86_64 => pv}/compat/entry.S (100%)
 rename xen/arch/x86/{x86_64 => pv}/entry.S (100%)
 create mode 100644 xen/arch/x86/pv/traps.c
 create mode 100644 xen/arch/x86/pv/x86_64/Makefile
 rename xen/arch/x86/{ => pv}/x86_64/compat/traps.c (100%)
 create mode 100644 xen/arch/x86/pv/x86_64/traps.c

-- 
2.11.0


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

[Xen-devel] [PATCH for-next 6/7] x86: s/bool_t/bool/g in pv/traps.c

[Wei Liu]

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/traps.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index 0f09d858f6..64f2ffbd69 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -373,7 +373,7 @@ static int read_descriptor(unsigned int sel,
unsigned long *base,
unsigned long *limit,
unsigned int *ar,
-   bool_t insn_fetch)
+   bool insn_fetch)
 {
 struct desc_struct desc;
 
@@ -640,7 +640,7 @@ static int priv_op_read_segment(enum x86_segment seg,
 }
 
 /* Perform IOPL check between the vcpu's shadowed IOPL, and the assumed cpl. */
-static bool_t iopl_ok(const struct vcpu *v, const struct cpu_user_regs *regs)
+static bool iopl_ok(const struct vcpu *v, const struct cpu_user_regs *regs)
 {
 unsigned int cpl = guest_kernel_mode(v, regs) ?
 (VM_ASSIST(v->domain, architectural_iopl) ? 0 : 1) : 3;
@@ -690,8 +690,8 @@ static int guest_io_okay(
 }
 
 /* Has the administrator granted sufficient permission for this I/O access? */
-static bool_t admin_io_okay(unsigned int port, unsigned int bytes,
-const struct domain *d)
+static bool admin_io_okay(unsigned int port, unsigned int bytes,
+  const struct domain *d)
 {
 /*
  * Port 0xcf8 (CONFIG_ADDRESS) is only visible for DWORD accesses.
@@ -707,8 +707,8 @@ static bool_t admin_io_okay(unsigned int port, unsigned int 
bytes,
 return ioports_access_permitted(d, port, port + bytes - 1);
 }
 
-static bool_t pci_cfg_ok(struct domain *currd, unsigned int start,
- unsigned int size, uint32_t *write)
+static bool pci_cfg_ok(struct domain *currd, unsigned int start,
+   unsigned int size, uint32_t *write)
 {
 uint32_t machine_bdf;
 
-- 
2.11.0


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

[Xen-devel] [PATCH for-next 2/7] x86: move x86_64/compat/entry.S to pv/compat

[Wei Liu]

That file contains 32 bit PV guest entry points.

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/Makefile| 2 ++
 xen/arch/x86/{x86_64 => pv}/compat/Makefile | 0
 xen/arch/x86/{x86_64 => pv}/compat/entry.S  | 0
 xen/arch/x86/x86_64/Makefile| 2 --
 4 files changed, 2 insertions(+), 2 deletions(-)
 rename xen/arch/x86/{x86_64 => pv}/compat/Makefile (100%)
 rename xen/arch/x86/{x86_64 => pv}/compat/entry.S (100%)

diff --git a/xen/arch/x86/pv/Makefile b/xen/arch/x86/pv/Makefile
index 08b6a3af64..d8fc13f6fe 100644
--- a/xen/arch/x86/pv/Makefile
+++ b/xen/arch/x86/pv/Makefile
@@ -1,3 +1,5 @@
+subdir-y += compat
+
 obj-y += hypercall.o
 obj-bin-y += dom0_build.init.o
 obj-bin-y += entry.o
diff --git a/xen/arch/x86/x86_64/compat/Makefile 
b/xen/arch/x86/pv/compat/Makefile
similarity index 100%
rename from xen/arch/x86/x86_64/compat/Makefile
rename to xen/arch/x86/pv/compat/Makefile
diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/pv/compat/entry.S
similarity index 100%
rename from xen/arch/x86/x86_64/compat/entry.S
rename to xen/arch/x86/pv/compat/entry.S
diff --git a/xen/arch/x86/x86_64/Makefile b/xen/arch/x86/x86_64/Makefile
index 1f0a4f7bb2..53e2f95e77 100644
--- a/xen/arch/x86/x86_64/Makefile
+++ b/xen/arch/x86/x86_64/Makefile
@@ -1,5 +1,3 @@
-subdir-y += compat
-
 obj-bin-y += gpr_switch.o
 obj-y += traps.o
 obj-$(CONFIG_KEXEC) += machine_kexec.o
-- 
2.11.0


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

[Xen-devel] [PATCH for-next 1/7] x86: move x86_64/entry.S to pv directory

[Wei Liu]

That file contains 64 bit PV guest entry points.

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/Makefile| 1 +
 xen/arch/x86/{x86_64 => pv}/entry.S | 0
 xen/arch/x86/x86_64/Makefile| 1 -
 3 files changed, 1 insertion(+), 1 deletion(-)
 rename xen/arch/x86/{x86_64 => pv}/entry.S (100%)

diff --git a/xen/arch/x86/pv/Makefile b/xen/arch/x86/pv/Makefile
index ea94599438..08b6a3af64 100644
--- a/xen/arch/x86/pv/Makefile
+++ b/xen/arch/x86/pv/Makefile
@@ -1,2 +1,3 @@
 obj-y += hypercall.o
 obj-bin-y += dom0_build.init.o
+obj-bin-y += entry.o
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/pv/entry.S
similarity index 100%
rename from xen/arch/x86/x86_64/entry.S
rename to xen/arch/x86/pv/entry.S
diff --git a/xen/arch/x86/x86_64/Makefile b/xen/arch/x86/x86_64/Makefile
index d8815e78b0..1f0a4f7bb2 100644
--- a/xen/arch/x86/x86_64/Makefile
+++ b/xen/arch/x86/x86_64/Makefile
@@ -1,6 +1,5 @@
 subdir-y += compat
 
-obj-bin-y += entry.o
 obj-bin-y += gpr_switch.o
 obj-y += traps.o
 obj-$(CONFIG_KEXEC) += machine_kexec.o
-- 
2.11.0


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

[Xen-devel] Immediate reboot on Xen kernel 4.9.13 ->4.9.20 load, but non-Xen is OK

[PJ Welsh]

I started off my attempt to figure out what's going on with the centos-virt
group as that is the Xen entry point I use for server. It was recommended
to me to put my issue here. This is the beginging of the thread:
https://lists.centos.org/pipermail/centos-virt/2017-March/005411.html
George suggested I seek help from xen-devel:
https://lists.centos.org/pipermail/centos-virt/2017-March/005442.html

Summary:
Within about 2 seconds of starting the servers with the Xen enabled kernel,
the server will reboot:
The last few lines are
NMI watchdog: disabled CPU0 hardware events not enabled
NMI watchdog: shutting down hard lockup detector on all CPUS
installing Xen timer for CPU1
installing Xen timer for CPU2
installing Xen timer for CPU3
installing Xen timer for CPU4
installing Xen timer for CPU5
installing Xen timer for CPU6

Here is the screen shot:
https://goo.gl/photos/yNQqaQY9bJBWQ84X8
It stops at CPU6. This is a dual socket server with 2x 6core L5639 CPUs (HT
disabled). I'm surprised to see it stop at 6.

There are 2 Dell R710 servers that have exhibited this issue now. One was
running CentOS 6.8 the other CentOS 7.3. The R710 server has a clean
install of CentOS 7.3 and still exhibits the issue described. I have 2
other R710 that are not being updated because they are more critical.

The non-Xen enabled kernel 4.9.13-22.el7.x86_64 *does* boot, however:
# awk -F\' '$1=="menuentry " {print i++ " : " $2}' /etc/grub2.cfg
0 : CentOS Linux, with Xen hypervisor
1 : CentOS Linux (4.9.13-22.el7.x86_64) 7 (Core)
2 : CentOS Linux (3.10.0-514.10.2.el7.x86_64) 7 (Core)
3 : CentOS Linux (0-rescue-ae7068154184447486235b0dbb9c2422) 7 (Core)

So, "0" kernel option just goes into a reboot, but "1" boots correctly.

I have one of the Dell R710's having this issue set aside to do any
diagnosis that may need to be done.

Is there any insight into this issue?

Please forgive me if I have posted to the wrong list section and inform me
of the proper location.

Thanks in advance.

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

Re: [Xen-devel] [PATCH v5 11/30] ARM: GICv3 ITS: introduce device mapping

[Julien Grall]

On 06/04/17 17:42, Stefano Stabellini wrote:

On Thu, 6 Apr 2017, Julien Grall wrote:

Hi Stefano,

On 06/04/17 00:41, Stefano Stabellini wrote:

+/* An Interrupt Translation Table needs to be 256-byte aligned. */
+itt_addr = _xzalloc(nr_events * hw_its->itte_size, 256);
+if ( !itt_addr )
+goto out_unlock;
+
+dev = xzalloc(struct its_devices);
+if ( !dev )
+goto out_unlock;
+
+/*
+ * Allocate the pending_irqs for each virtual LPI. They will be put
+ * into the domain's radix tree upon the guest's MAPTI command.
+ */


Please expand the comment with a link to the xen-devel conversation
about allocation strategy and a TODO saying that we shouldn't need to
preallocate all pending_irq struct, but we do it for simplicity at the
moment.


It would have been useful to provide a link of the conversation you mention to
allow us answering properly rather than loosing a day for confirmation.
Anyway, I guess you are speaking about [1].
[1] https://lists.xenproject.org/archives/html/xen-devel/2017-03/msg03758.html


Yes, that's right.



I agree that we would need to take into account the memory to the guest, but
this is a work beyond GICv3 ITS support as it is not
supported by Xen today.

Even if you do memory accounting, this would have to be reserved in advance to
avoid failure afterwards. Which is very similar to memory allocation...

So can you explain what you would do here?


I don't think we need a full plan written down in a comment, but I think
it is fair to say that there is room for improvement, especially given
that we are already introducing other data structures such as the host
LPI array. I would write the following:

  Allocate the pending_irqs for each virtual LPI. They will be put into
  the domain's radix tree upon the guest's MAPTI command.

  TODO. For now, allocate all pending_irqs immediately.  However,
  delayed allocation strategies are possible, see this discussion:
  https://lists.xenproject.org/archives/html/xen-devel/2017-03/msg03758.html


Sounds good to me. We can discuss about the strategies later on.

Cheers,

--
Julien Grall

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

[Xen-devel] [xen-unstable-smoke test] 107245: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  4feb9779c92783c47ef1d75b5ab3823888313aac
baseline version:
 xen  de5f36a266b41cafc47c876700a9c1a494aa296f

Last test of basis   107242  2017-04-06 13:02:00 Z0 days
Testing same since   107245  2017-04-06 15:01:20 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Ian Jackson 
  Ronald Rojas 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=4feb9779c92783c47ef1d75b5ab3823888313aac
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
4feb9779c92783c47ef1d75b5ab3823888313aac
+ branch=xen-unstable-smoke
+ revision=4feb9779c92783c47ef1d75b5ab3823888313aac
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ 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
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' x4feb9779c92783c47ef1d75b5ab3823888313aac = 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
++ : 

[Xen-devel] [qemu-mainline test] 107219: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 107196
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 107196
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 107196
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 107196
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 107196
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 107196

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu1fde6ee885d3e778acb326cab9f7037939839537
baseline version:
 qemuufa902c8ca0f3b83e0e3dda1e9e00f0b1d28e718a

Last test of basis   107196  2017-04-04 16:43:03 Z1 days
Testing same since   107219  2017-04-05 15:36:01 Z1 days1 attempts


People who touched revisions under test:
  Alexey Kardashevskiy 
  Greg Kurz 
  John Snow 
  Michael S. Tsirkin 
  Paolo Bonzini 
  Peter Maydell 

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

Re: [Xen-devel] [PATCH for-4.9] xen: append -Wno-unused-function to C99 header check

[Stefano Stabellini]

On Thu, 6 Apr 2017, Jan Beulich wrote:
> >>> On 06.04.17 at 14:54,  wrote:
> > --- a/xen/include/Makefile
> > +++ b/xen/include/Makefile
> > @@ -111,7 +111,7 @@ headers.chk: $(PUBLIC_ANSI_HEADERS) Makefile
> >  headers99.chk: $(PUBLIC_C99_HEADERS) Makefile
> > rm -f $@.new
> > $(foreach i, $(filter %.h,$^),\
> > -   $(CC) -x c -std=c99 -Wall -Werror \
> > +   $(CC) -x c -std=c99 -Wall -Werror -Wno-unused-function\
> > -include stdint.h $(foreach j, $($(i)-prereq), -include $(j).h)   \
> > -S -o /dev/null $(i)  \
> > || exit $$?; echo $(i) >> $@.new;)
> 
> I think it would be better to make this match the C++ check, where
> a source file is being generated on the fly (and quite possibly for a
> similar reason).
 
I don't have an opinion on what is the best way to fix this. However,
I'll say that it is expected to have unused functions in header files
(it would be a problem if there weren't), so -Wno-unused-function looks
fine to me.

Wei, given that the problem was introduced by my patch, let me know if
you need any help fixing this.

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

Re: [Xen-devel] [PATCH v12 5/6] x86/ioreq server: Asynchronously reset outstanding p2m_ioreq_server entries.

[George Dunlap]

On 06/04/17 16:53, Yu Zhang wrote:
> After an ioreq server has unmapped, the remaining p2m_ioreq_server
> entries need to be reset back to p2m_ram_rw. This patch does this
> asynchronously with the current p2m_change_entry_type_global()
> interface.
> 
> New field entry_count is introduced in struct p2m_domain, to record
> the number of p2m_ioreq_server p2m page table entries. One nature of
> these entries is that they only point to 4K sized page frames, because
> all p2m_ioreq_server entries are originated from p2m_ram_rw ones in
> p2m_change_type_one(). We do not need to worry about the counting for
> 2M/1G sized pages.
> 
> This patch disallows mapping of an ioreq server, when there's still
> p2m_ioreq_server entry left, in case another mapping occurs right after
> the current one being unmapped, releases its lock, with p2m table not
> synced yet.
> 
> This patch also disallows live migration, when there's remaining
> p2m_ioreq_server entry in p2m table. The core reason is our current
> implementation of p2m_change_entry_type_global() lacks information
> to resync p2m_ioreq_server entries correctly if global_logdirty is
> on.
> 
> Signed-off-by: Yu Zhang 
> Reviewed-by: Paul Durrant 
> ---
> Cc: Paul Durrant 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Jun Nakajima 
> Cc: Kevin Tian 
> 
> changes in v7:
>   - According to comments from George: add code to increase the
> entry_count.
>   - Comment changes in {ept,p2m_pt}_set_entry.
> 
> changes in v6:
>   - According to comments from Jan & George: move the count from
> p2m_change_type_one() to {ept,p2m_pt}_set_entry.
>   - According to comments from George: comments change.
> 
> changes in v5:
>   - According to comments from Jan: use unsigned long for entry_count;
>   - According to comments from Jan: refuse mapping requirement when
> there's p2m_ioreq_server remained in p2m table.
>   - Added "Reviewed-by: Paul Durrant "
> 
> changes in v4:
>   - According to comments from Jan: use ASSERT() instead of 'if'
> condition in p2m_change_type_one().
>   - According to comments from Jan: commit message changes to mention
> the p2m_ioreq_server are all based on 4K sized pages.
> 
> changes in v3:
>   - Move the synchronously resetting logic into patch 5.
>   - According to comments from Jan: introduce p2m_check_changeable()
> to clarify the p2m type change code.
>   - According to comments from George: use locks in the same order
> to avoid deadlock, call p2m_change_entry_type_global() after unmap
> of the ioreq server is finished.
> 
> changes in v2:
>   - Move the calculation of ioreq server page entry_cout into
> p2m_change_type_one() so that we do not need a seperate lock.
> Note: entry_count is also calculated in resolve_misconfig()/
> do_recalc(), fortunately callers of both routines have p2m
> lock protected already.
>   - Simplify logic in hvmop_set_mem_type().
>   - Introduce routine p2m_finish_type_change() to walk the p2m
> table and do the p2m reset.
> ---
>  xen/arch/x86/hvm/ioreq.c  |  8 
>  xen/arch/x86/mm/hap/hap.c |  9 +
>  xen/arch/x86/mm/p2m-ept.c | 24 +++-
>  xen/arch/x86/mm/p2m-pt.c  | 30 --
>  xen/arch/x86/mm/p2m.c |  9 +
>  xen/include/asm-x86/p2m.h |  9 -
>  6 files changed, 85 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
> index 5bf3b6d..07a6c26 100644
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -955,6 +955,14 @@ int hvm_map_mem_type_to_ioreq_server(struct domain *d, 
> ioservid_t id,
>  
>  spin_unlock_recursive(>arch.hvm_domain.ioreq_server.lock);
>  
> +if ( rc == 0 && flags == 0 )
> +{
> +struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +
> +if ( read_atomic(>ioreq.entry_count) )
> +p2m_change_entry_type_global(d, p2m_ioreq_server, p2m_ram_rw);
> +}
> +
>  return rc;
>  }
>  
> diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
> index a57b385..4b591fe 100644
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -187,6 +187,15 @@ out:
>   */
>  static int hap_enable_log_dirty(struct domain *d, bool_t log_global)
>  {
> +struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +
> +/*
> + * Refuse to turn on global log-dirty mode if
> + * there are outstanding p2m_ioreq_server pages.
> + */
> +if ( log_global && read_atomic(>ioreq.entry_count) )
> +return -EBUSY;
> +
>  /* turn on PG_log_dirty bit in paging mode */
>  paging_lock(d);
>  d->arch.paging.mode |= PG_log_dirty;
> diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
> index 

Re: [Xen-devel] [PATCH] arm64: xen: Implement EFI reset_system callback

[Daniel Kiper]

On Thu, Apr 06, 2017 at 06:22:44PM +0200, Juergen Gross wrote:
> On 06/04/17 18:06, Daniel Kiper wrote:
> > Hi Julien,
> >
> > On Thu, Apr 06, 2017 at 04:39:13PM +0100, Julien Grall wrote:
> >> Hi Daniel,
> >>
> >> On 06/04/17 16:20, Daniel Kiper wrote:
> >>> On Thu, Apr 06, 2017 at 04:38:24PM +0200, Juergen Gross wrote:
>  On 06/04/17 16:27, Daniel Kiper wrote:
> > On Thu, Apr 06, 2017 at 09:32:32AM +0100, Julien Grall wrote:
> >> Hi Juergen,
> >>
> >> On 06/04/17 07:23, Juergen Gross wrote:
> >>> On 05/04/17 21:49, Boris Ostrovsky wrote:
>  On 04/05/2017 02:14 PM, Julien Grall wrote:
> > The x86 code has theoritically a similar issue, altought EFI does 
> > not
> > seem to be the preferred method. I have left it unimplemented on 
> > x86 and
> > CCed Linux Xen x86 maintainers to know their view here.
> 
>  (+Daniel)
> 
>  This could be a problem for x86 as well, at least theoretically.
>  xen_machine_power_off() may call pm_power_off(), which is 
>  efi.reset_system.
> 
>  So I think we should have a similar routine there.
> >>>
> >>> +1
> >>>
> >>> I don't see any problem with such a routine added, in contrast to
> >>> potential "reboots" instead of power off without it.
> >>>
> >>> So I think this dummy xen_efi_reset_system() should be added to
> >>> drivers/xen/efi.c instead.
> >>
> >> I will resend the patch during day with xen_efi_reset_system moved
> >> to common code and implement the x86 counterpart (thought, I will
> >> not be able to test it).
> >
> > I think that this is ARM specific issue. On x86 machine_restart() calls
> > xen_restart(). Hence, everything works. So, I think that it should be
> > fixed only for ARM. Anyway, please CC me when you send a patch.
> 
>  What about xen_machine_power_off() (as stated in Boris' mail)?
> >>>
> >>> Guys what do you think about that:
> >>>
> >>> --- a/drivers/firmware/efi/reboot.c
> >>> +++ b/drivers/firmware/efi/reboot.c
> >>> @@ -55,7 +55,7 @@ static void efi_power_off(void)
> >>>
> >>> static int __init efi_shutdown_init(void)
> >>> {
> >>> -   if (!efi_enabled(EFI_RUNTIME_SERVICES))
> >>> +   if (!efi_enabled(EFI_RUNTIME_SERVICES) || 
> >>> efi_enabled(EFI_PARAVIRT))
> >>>return -ENODEV;
> >>>
> >>>if (efi_poweroff_required())
> >>>
> >>>
> >>> Julien, for ARM64 please take a look at 
> >>> arch/arm64/kernel/efi.c:efi_poweroff_required(void).
> >>>
> >>> I hope that tweaks for both files should solve our problem.
> >>
> >> This sounds good for power off (I haven't tried to power off DOM0
> >> yet). But this will not solve the restart problem (see
> >> machine_restart in arch/arm64/kernel/process.c) which call directly
> >> efi_reboot.
> >
> > Hmmm... It seems to me that efi.reset_system override with empty function
> > in arch/arm/xen/efi.c is the best solution. So, I see three patches here.
> > One for drivers/firmware/efi/reboot.c, one for arch/arm/xen/efi.c and one
> > for arch/arm64/kernel/efi.c. Does it make sense?
>
> I still think the empty function should be in drivers/xen/efi.c and we
> should use it in arch/x86/xen/efi.c, too.

If you wish we can go that way too. Though I thing that we should fix
drivers/firmware/efi/reboot.c:efi_shutdown_init() too. Just in case.

Daniel

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

Re: [Xen-devel] [PATCH v5 11/30] ARM: GICv3 ITS: introduce device mapping

[Stefano Stabellini]

On Thu, 6 Apr 2017, Julien Grall wrote:
> Hi Stefano,
> 
> On 06/04/17 00:41, Stefano Stabellini wrote:
> > > +/* An Interrupt Translation Table needs to be 256-byte aligned. */
> > > +itt_addr = _xzalloc(nr_events * hw_its->itte_size, 256);
> > > +if ( !itt_addr )
> > > +goto out_unlock;
> > > +
> > > +dev = xzalloc(struct its_devices);
> > > +if ( !dev )
> > > +goto out_unlock;
> > > +
> > > +/*
> > > + * Allocate the pending_irqs for each virtual LPI. They will be put
> > > + * into the domain's radix tree upon the guest's MAPTI command.
> > > + */
> > 
> > Please expand the comment with a link to the xen-devel conversation
> > about allocation strategy and a TODO saying that we shouldn't need to
> > preallocate all pending_irq struct, but we do it for simplicity at the
> > moment.
> 
> It would have been useful to provide a link of the conversation you mention to
> allow us answering properly rather than loosing a day for confirmation.
> Anyway, I guess you are speaking about [1].
> [1] https://lists.xenproject.org/archives/html/xen-devel/2017-03/msg03758.html

Yes, that's right.


> I agree that we would need to take into account the memory to the guest, but
> this is a work beyond GICv3 ITS support as it is not
> supported by Xen today.
> 
> Even if you do memory accounting, this would have to be reserved in advance to
> avoid failure afterwards. Which is very similar to memory allocation...
> 
> So can you explain what you would do here?

I don't think we need a full plan written down in a comment, but I think
it is fair to say that there is room for improvement, especially given
that we are already introducing other data structures such as the host
LPI array. I would write the following:

  Allocate the pending_irqs for each virtual LPI. They will be put into
  the domain's radix tree upon the guest's MAPTI command.

  TODO. For now, allocate all pending_irqs immediately.  However,
  delayed allocation strategies are possible, see this discussion:
  https://lists.xenproject.org/archives/html/xen-devel/2017-03/msg03758.html

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

Re: [Xen-devel] [PATCH for 4.9 6/6] x86/emul: Require callers to provide LMA in the emulation context

[Andrew Cooper]

On 06/04/17 15:14, Jan Beulich wrote:
 On 06.04.17 at 11:47,  wrote:
>> On 06/04/17 07:58, Jan Beulich wrote:
>> On 05.04.17 at 18:24,  wrote:
 On 03/04/17 11:10, Jan Beulich wrote:
 On 31.03.17 at 21:50,  wrote:
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -5410,6 +5410,7 @@ int ptwr_do_page_fault(struct vcpu *v, unsigned 
>> long 
>> addr,
>>  .ctxt = {
>>  .regs = regs,
>>  .vendor = d->arch.cpuid->x86_vendor,
>> +.lma = true,
>>  .addr_size = is_pv_32bit_domain(d) ? 32 : BITS_PER_LONG,
>>  .sp_size   = is_pv_32bit_domain(d) ? 32 : BITS_PER_LONG,
>>  },
>> @@ -5564,6 +5565,7 @@ int mmio_ro_do_page_fault(struct vcpu *v, unsigned 
>> long 
>> addr,
>>  struct x86_emulate_ctxt ctxt = {
>>  .regs = regs,
>>  .vendor = v->domain->arch.cpuid->x86_vendor,
>> +.lma = true,
> Hmm, both of these are correct from Xen's pov, but potentially
> wrong from the guest's. Since system segments aren't being
> dealt with here, I think this difference is benign, but I think it
> warrants at least a comment. If we ever meant to emulate
> LLDT, this would become at active problem, as the guest's view
> on gate descriptor layout would differ from that resulting from
> setting .lma to true here. Same for emulate_privileged_op() then.
 As discovered in the meantime, things like LLDT/LTR and call gates are
 far more complicated.

 Still, setting LMA to true here is the right thing to do, as it is an
 accurate statement of processor state.  Despite the level of
 compatibility for 32bit, a 32bit PV guest isn't entirely isolated from
 the fact that Xen is 64bit.
>>> Yes, but still call gates (which we don't currently handle in the
>>> emulator itself) require 32-bit treatment for 32-bit guests, so
>>> setting lma to true would still seem wrong.
>> I thought you said that a compatibility mode `call $gate` still checked
>> the type in the high 8 bytes.
> Right.
>
>> A 32bit PV guest therefore needs to be aware that it can't position call
>> gates adjacently, or it will suffer #GP[sel] for a failed typecheck.
> That's not the conclusion I would draw. There is a reason we emulate
> call gate accesses already now for 32-bit guests (just not via
> x86_emulate()) - precisely to guarantee guests need _not_ be aware.
>
>> Now, in this specific case we are in a position to cope, because either
>> way we end up in the gate op code, but if we wanted to override hardware
>> behaviour, it should be the validate function, which positively
>> identifies a far call/jmp, which should choose to override lma for the
>> purposes of faking up legacy mode behaviour.
> I don't think the validate function should do any such overriding.
> Specifically it shouldn't alter ctxt->lma, risking to surprise x86_emulate().

I have folded:

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index d010aa3..96bc280 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5412,7 +5412,7 @@ int ptwr_do_page_fault(struct vcpu *v, unsigned
long addr,
 .vendor = d->arch.cpuid->x86_vendor,
 .addr_size = is_pv_32bit_domain(d) ? 32 : BITS_PER_LONG,
 .sp_size   = is_pv_32bit_domain(d) ? 32 : BITS_PER_LONG,
-.lma = true,
+.lma   = !is_pv_32bit_domain(d),
 },
 };
 int rc;
@@ -5567,7 +5567,7 @@ int mmio_ro_do_page_fault(struct vcpu *v, unsigned
long addr,
 .vendor = v->domain->arch.cpuid->x86_vendor,
 .addr_size = addr_size,
 .sp_size = addr_size,
-.lma = true,
+.lma = !is_pv_32bit_vcpu(v),
 .data = _ro_ctxt
 };
 int rc;
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 09dc2f1..5b9bf21 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2966,7 +2966,7 @@ static int emulate_privileged_op(struct
cpu_user_regs *regs)
 struct priv_op_ctxt ctxt = {
 .ctxt.regs = regs,
 .ctxt.vendor = currd->arch.cpuid->x86_vendor,
-.ctxt.lma = true,
+.ctxt.lma = !is_pv_32bit_domain(currd),
 };
 int rc;
 unsigned int eflags, ar;


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

Re: [Xen-devel] [OSSTEST PATCH v9 1/3] ts-openstack-deploy: Deploy OpenStack on a host with devstack

[Ian Jackson]

Anthony PERARD writes ("[OSSTEST PATCH v9 1/3] ts-openstack-deploy: Deploy 
OpenStack on a host with devstack"):
> This script installs any necessary packages and clones all of the OpenStack
> trees which are used by devstack to deploy OpenStack.
> 
> Signed-off-by: Anthony PERARD 
> Acked-by: Ian Jackson 

I found in one of my working trees this diff to this patch:

> +sub deploy() {
> +target_cmd($ho, < +cd $builddir/devstack
> +./stack.sh
> +END

diff --git a/ts-openstack-deploy b/ts-openstack-deploy
index 6542da8..85197b0 100755
--- a/ts-openstack-deploy
+++ b/ts-openstack-deploy
@@ -127,6 +127,7 @@ END
 
 sub deploy() {
 target_cmd($ho, <

[Xen-devel] [PATCH] x86emul: correct compat mode system descriptor handling

[Jan Beulich]

There are some oddities to take care of here - see the code comment.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1818,11 +1818,24 @@ protmode_load_seg(
 
 if ( !is_x86_user_segment(seg) )
 {
-int lm = (desc.b & (1u << 12)) ? 0 : in_longmode(ctxt, ops);
+/*
+ * Whether to use an 8- or 16-byte descriptor in long mode depends
+ * on sub-mode, descriptor type, and vendor:
+ * - non-system descriptors are always 8-byte ones,
+ * - system descriptors are always 16-byte ones in 64-bit mode,
+ * - (call) gates are always 16-byte ones,
+ * - other system descriptors in compatibility mode have
+ *   - only their low 8-byte bytes read on Intel,
+ *   - all 16 bytes read with the high 8 bytes ignored on AMD.
+ */
+int wide = desc.b & 0x1000
+   ? 0 : (desc.b & 0xf00) != 0xc00 &&
+ ctxt->vendor != X86_VENDOR_AMD
+ ? mode_64bit() : in_longmode(ctxt, ops);
 
-if ( lm < 0 )
+if ( wide < 0 )
 return X86EMUL_UNHANDLEABLE;
-if ( lm )
+if ( wide )
 {
 switch ( rc = ops->read(sel_seg, (sel & 0xfff8) + 8,
 _hi, sizeof(desc_hi), ctxt) )
@@ -1837,6 +1850,9 @@ protmode_load_seg(
 default:
 return rc;
 }
+if ( !mode_64bit() && ctxt->vendor == X86_VENDOR_AMD &&
+ (desc.b & 0xf00) != 0xc00 )
+desc_hi.b = desc_hi.a = 0;
 if ( (desc_hi.b & 0x1f00) ||
  (seg != x86_seg_none &&
   !is_canonical_address((uint64_t)desc_hi.a << 32)) )



x86emul: correct compat mode system descriptor handling

There are some oddities to take care of here - see the code comment.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1818,11 +1818,24 @@ protmode_load_seg(
 
 if ( !is_x86_user_segment(seg) )
 {
-int lm = (desc.b & (1u << 12)) ? 0 : in_longmode(ctxt, ops);
+/*
+ * Whether to use an 8- or 16-byte descriptor in long mode depends
+ * on sub-mode, descriptor type, and vendor:
+ * - non-system descriptors are always 8-byte ones,
+ * - system descriptors are always 16-byte ones in 64-bit mode,
+ * - (call) gates are always 16-byte ones,
+ * - other system descriptors in compatibility mode have
+ *   - only their low 8-byte bytes read on Intel,
+ *   - all 16 bytes read with the high 8 bytes ignored on AMD.
+ */
+int wide = desc.b & 0x1000
+   ? 0 : (desc.b & 0xf00) != 0xc00 &&
+ ctxt->vendor != X86_VENDOR_AMD
+ ? mode_64bit() : in_longmode(ctxt, ops);
 
-if ( lm < 0 )
+if ( wide < 0 )
 return X86EMUL_UNHANDLEABLE;
-if ( lm )
+if ( wide )
 {
 switch ( rc = ops->read(sel_seg, (sel & 0xfff8) + 8,
 _hi, sizeof(desc_hi), ctxt) )
@@ -1837,6 +1850,9 @@ protmode_load_seg(
 default:
 return rc;
 }
+if ( !mode_64bit() && ctxt->vendor == X86_VENDOR_AMD &&
+ (desc.b & 0xf00) != 0xc00 )
+desc_hi.b = desc_hi.a = 0;
 if ( (desc_hi.b & 0x1f00) ||
  (seg != x86_seg_none &&
   !is_canonical_address((uint64_t)desc_hi.a << 32)) )
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64: xen: Implement EFI reset_system callback

[Juergen Gross]

On 06/04/17 18:06, Daniel Kiper wrote:
> Hi Julien,
> 
> On Thu, Apr 06, 2017 at 04:39:13PM +0100, Julien Grall wrote:
>> Hi Daniel,
>>
>> On 06/04/17 16:20, Daniel Kiper wrote:
>>> On Thu, Apr 06, 2017 at 04:38:24PM +0200, Juergen Gross wrote:
 On 06/04/17 16:27, Daniel Kiper wrote:
> On Thu, Apr 06, 2017 at 09:32:32AM +0100, Julien Grall wrote:
>> Hi Juergen,
>>
>> On 06/04/17 07:23, Juergen Gross wrote:
>>> On 05/04/17 21:49, Boris Ostrovsky wrote:
 On 04/05/2017 02:14 PM, Julien Grall wrote:
> The x86 code has theoritically a similar issue, altought EFI does not
> seem to be the preferred method. I have left it unimplemented on x86 
> and
> CCed Linux Xen x86 maintainers to know their view here.

 (+Daniel)

 This could be a problem for x86 as well, at least theoretically.
 xen_machine_power_off() may call pm_power_off(), which is 
 efi.reset_system.

 So I think we should have a similar routine there.
>>>
>>> +1
>>>
>>> I don't see any problem with such a routine added, in contrast to
>>> potential "reboots" instead of power off without it.
>>>
>>> So I think this dummy xen_efi_reset_system() should be added to
>>> drivers/xen/efi.c instead.
>>
>> I will resend the patch during day with xen_efi_reset_system moved
>> to common code and implement the x86 counterpart (thought, I will
>> not be able to test it).
>
> I think that this is ARM specific issue. On x86 machine_restart() calls
> xen_restart(). Hence, everything works. So, I think that it should be
> fixed only for ARM. Anyway, please CC me when you send a patch.

 What about xen_machine_power_off() (as stated in Boris' mail)?
>>>
>>> Guys what do you think about that:
>>>
>>> --- a/drivers/firmware/efi/reboot.c
>>> +++ b/drivers/firmware/efi/reboot.c
>>> @@ -55,7 +55,7 @@ static void efi_power_off(void)
>>>
>>> static int __init efi_shutdown_init(void)
>>> {
>>> -   if (!efi_enabled(EFI_RUNTIME_SERVICES))
>>> +   if (!efi_enabled(EFI_RUNTIME_SERVICES) || efi_enabled(EFI_PARAVIRT))
>>>return -ENODEV;
>>>
>>>if (efi_poweroff_required())
>>>
>>>
>>> Julien, for ARM64 please take a look at 
>>> arch/arm64/kernel/efi.c:efi_poweroff_required(void).
>>>
>>> I hope that tweaks for both files should solve our problem.
>>
>> This sounds good for power off (I haven't tried to power off DOM0
>> yet). But this will not solve the restart problem (see
>> machine_restart in arch/arm64/kernel/process.c) which call directly
>> efi_reboot.
> 
> Hmmm... It seems to me that efi.reset_system override with empty function
> in arch/arm/xen/efi.c is the best solution. So, I see three patches here.
> One for drivers/firmware/efi/reboot.c, one for arch/arm/xen/efi.c and one
> for arch/arm64/kernel/efi.c. Does it make sense?

I still think the empty function should be in drivers/xen/efi.c and we
should use it in arch/x86/xen/efi.c, too.


Juergen


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pair 9 xen-boot/src_hostfail REGR. vs. 107169
 test-amd64-amd64-pair10 xen-boot/dst_hostfail REGR. vs. 107169
 test-amd64-amd64-libvirt  6 xen-boot fail REGR. vs. 107169
 test-amd64-i386-pair  9 xen-boot/src_hostfail REGR. vs. 107169
 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 107169
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 107169
 test-amd64-amd64-xl-pvh-amd   6 xen-boot fail REGR. vs. 107169
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-boot   fail REGR. vs. 107179
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-bootfail REGR. vs. 107179
 test-amd64-i386-freebsd10-amd64  6 xen-boot  fail REGR. vs. 107179
 test-amd64-amd64-rumprun-amd64  6 xen-boot   fail REGR. vs. 107179
 test-amd64-i386-xl-qemut-win7-amd64  6 xen-boot  fail REGR. vs. 107179
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail REGR. vs. 107179
 test-amd64-amd64-qemuu-nested-intel  6 xen-boot  fail REGR. vs. 107179
 test-amd64-i386-libvirt-pair  9 xen-boot/src_hostfail REGR. vs. 107179
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_hostfail REGR. vs. 107179
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_host   fail REGR. vs. 107179
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host   fail REGR. vs. 107179
 test-amd64-amd64-xl-multivcpu  6 xen-bootfail REGR. vs. 107179
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-boot   fail REGR. vs. 107179
 test-amd64-amd64-xl   6 xen-boot fail REGR. vs. 107179
 test-amd64-i386-libvirt-xsm   6 xen-boot fail REGR. vs. 107179
 test-amd64-i386-libvirt   6 xen-boot fail REGR. vs. 107179
 test-amd64-amd64-xl-pvh-intel  6 xen-bootfail REGR. vs. 107179
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-bootfail REGR. vs. 107179
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 107179
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 107179
 test-amd64-amd64-i386-pvgrub  6 xen-boot fail REGR. vs. 107179
 test-amd64-amd64-libvirt-xsm  6 xen-boot fail REGR. vs. 107179
 test-amd64-amd64-amd64-pvgrub  6 xen-bootfail REGR. vs. 107179
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
107179
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. 
vs. 107179
 test-amd64-i386-xl6 xen-boot fail REGR. vs. 107179
 test-amd64-i386-xl-xsm6 xen-boot fail REGR. vs. 107179
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 107179
 test-amd64-i386-freebsd10-i386  6 xen-boot   fail REGR. vs. 107179
 test-amd64-i386-xl-raw6 xen-boot fail REGR. vs. 107179
 test-amd64-amd64-pygrub   6 xen-boot fail REGR. vs. 107179
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot fail REGR. vs. 107179
 test-amd64-amd64-xl-xsm   6 xen-boot fail REGR. vs. 107179
 test-amd64-amd64-libvirt-vhd  6 xen-boot fail REGR. vs. 107179
 test-amd64-amd64-xl-credit2   6 xen-boot fail REGR. vs. 107179
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot fail REGR. vs. 107179
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 107179
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 107179
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot fail REGR. vs. 107179
 test-amd64-i386-rumprun-i386  6 xen-boot fail REGR. vs. 107179
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-bootfail REGR. vs. 107179
 test-amd64-i386-qemut-rhel6hvm-amd  6 xen-boot   fail REGR. vs. 107179
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot fail REGR. vs. 107179
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
107179
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 107179
 test-amd64-amd64-xl-qemut-win7-amd64  6 xen-boot fail REGR. vs. 107179
 test-amd64-amd64-xl-qemut-debianhvm-amd64  6 xen-bootfail REGR. vs. 107179
 test-amd64-amd64-xl-qemuu-win7-amd64  6 xen-boot fail REGR. vs. 107179
 test-amd64-i386-qemuu-rhel6hvm-amd  6 xen-boot   fail REGR. vs. 107179
 test-amd64-i386-xl-qemuu-win7-amd64  6 xen-boot  fail REGR. vs. 107179
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
107179
 test-amd64-amd64-xl-qcow2 6 xen-boot fail REGR. vs. 107179
 test-amd64-amd64-qemuu-nested-amd  6 xen-boot   

[Xen-devel] [PATCH v12 6/6] x86/ioreq server: Synchronously reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

[Yu Zhang]

After an ioreq server has unmapped, the remaining p2m_ioreq_server
entries need to be reset back to p2m_ram_rw. This patch does this
synchronously by iterating the p2m table.

The synchronous resetting is necessary because we need to guarantee
the p2m table is clean before another ioreq server is mapped. And
since the sweeping of p2m table could be time consuming, it is done
with hypercall continuation.

Signed-off-by: Yu Zhang 
Reviewed-by: Paul Durrant 
Reviewed-by: Jan Beulich 
Reviewed-by: George Dunlap 
---
Cc: Paul Durrant 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 

changes in v4: 
  - Added "Reviewed-by: Paul Durrant "
  - Added "Reviewed-by: Jan Beulich "
  - Added "Reviewed-by: George Dunlap "

changes in v3: 
  - According to comments from Paul: use mar_nr, instead of
last_gfn for p2m_finish_type_change().
  - According to comments from Jan: use gfn_t as type of
first_gfn in p2m_finish_type_change().
  - According to comments from Jan: simplify the if condition
before using p2m_finish_type_change().

changes in v2: 
  - According to comments from Jan and Andrew: do not use the 
HVMOP type hypercall continuation method. Instead, adding
an opaque in xen_dm_op_map_mem_type_to_ioreq_server to
store the gfn.
  - According to comments from Jan: change routine's comments
and name of parameters of p2m_finish_type_change().

changes in v1:
  - This patch is splitted from patch 4 of last version.
  - According to comments from Jan: update the gfn_start for
when use hypercall continuation to reset the p2m type.
  - According to comments from Jan: use min() to compare gfn_end
and max mapped pfn in p2m_finish_type_change()
---
 xen/arch/x86/hvm/dm.c | 41 ++---
 xen/arch/x86/mm/p2m.c | 29 +
 xen/include/asm-x86/p2m.h |  6 ++
 3 files changed, 73 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index 7e0da81..d72b7bd 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -384,15 +384,50 @@ static int dm_op(domid_t domid,
 
 case XEN_DMOP_map_mem_type_to_ioreq_server:
 {
-const struct xen_dm_op_map_mem_type_to_ioreq_server *data =
+struct xen_dm_op_map_mem_type_to_ioreq_server *data =
 _mem_type_to_ioreq_server;
+unsigned long first_gfn = data->opaque;
+
+const_op = false;
 
 rc = -EOPNOTSUPP;
 if ( !hap_enabled(d) )
 break;
 
-rc = hvm_map_mem_type_to_ioreq_server(d, data->id,
-  data->type, data->flags);
+if ( first_gfn == 0 )
+rc = hvm_map_mem_type_to_ioreq_server(d, data->id,
+  data->type, data->flags);
+else
+rc = 0;
+
+/*
+ * Iterate p2m table when an ioreq server unmaps from p2m_ioreq_server,
+ * and reset the remaining p2m_ioreq_server entries back to p2m_ram_rw.
+ */
+if ( rc == 0 && data->flags == 0 )
+{
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+while ( read_atomic(>ioreq.entry_count) &&
+first_gfn <= p2m->max_mapped_pfn )
+{
+/* Iterate p2m table for 256 gfns each time. */
+p2m_finish_type_change(d, _gfn(first_gfn), 256,
+   p2m_ioreq_server, p2m_ram_rw);
+
+first_gfn += 256;
+
+/* Check for continuation if it's not the last iteration. */
+if ( first_gfn <= p2m->max_mapped_pfn &&
+ hypercall_preempt_check() )
+{
+rc = -ERESTART;
+data->opaque = first_gfn;
+break;
+}
+}
+}
+
 break;
 }
 
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 4169d18..1d57e5c 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1011,6 +1011,35 @@ void p2m_change_type_range(struct domain *d,
 p2m_unlock(p2m);
 }
 
+/* Synchronously modify the p2m type for a range of gfns from ot to nt. */
+void p2m_finish_type_change(struct domain *d,
+gfn_t first_gfn, unsigned long max_nr,
+p2m_type_t ot, p2m_type_t nt)
+{
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+p2m_type_t t;
+unsigned long gfn = gfn_x(first_gfn);
+unsigned long last_gfn = gfn + max_nr - 1;
+
+ASSERT(ot != nt);
+ASSERT(p2m_is_changeable(ot) && p2m_is_changeable(nt));
+
+p2m_lock(p2m);
+
+last_gfn = min(last_gfn, 

[Xen-devel] [PATCH v12 5/6] x86/ioreq server: Asynchronously reset outstanding p2m_ioreq_server entries.

[Yu Zhang]

After an ioreq server has unmapped, the remaining p2m_ioreq_server
entries need to be reset back to p2m_ram_rw. This patch does this
asynchronously with the current p2m_change_entry_type_global()
interface.

New field entry_count is introduced in struct p2m_domain, to record
the number of p2m_ioreq_server p2m page table entries. One nature of
these entries is that they only point to 4K sized page frames, because
all p2m_ioreq_server entries are originated from p2m_ram_rw ones in
p2m_change_type_one(). We do not need to worry about the counting for
2M/1G sized pages.

This patch disallows mapping of an ioreq server, when there's still
p2m_ioreq_server entry left, in case another mapping occurs right after
the current one being unmapped, releases its lock, with p2m table not
synced yet.

This patch also disallows live migration, when there's remaining
p2m_ioreq_server entry in p2m table. The core reason is our current
implementation of p2m_change_entry_type_global() lacks information
to resync p2m_ioreq_server entries correctly if global_logdirty is
on.

Signed-off-by: Yu Zhang 
Reviewed-by: Paul Durrant 
---
Cc: Paul Durrant 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Jun Nakajima 
Cc: Kevin Tian 

changes in v7:
  - According to comments from George: add code to increase the
entry_count.
  - Comment changes in {ept,p2m_pt}_set_entry.

changes in v6:
  - According to comments from Jan & George: move the count from
p2m_change_type_one() to {ept,p2m_pt}_set_entry.
  - According to comments from George: comments change.

changes in v5:
  - According to comments from Jan: use unsigned long for entry_count;
  - According to comments from Jan: refuse mapping requirement when
there's p2m_ioreq_server remained in p2m table.
  - Added "Reviewed-by: Paul Durrant "

changes in v4:
  - According to comments from Jan: use ASSERT() instead of 'if'
condition in p2m_change_type_one().
  - According to comments from Jan: commit message changes to mention
the p2m_ioreq_server are all based on 4K sized pages.

changes in v3:
  - Move the synchronously resetting logic into patch 5.
  - According to comments from Jan: introduce p2m_check_changeable()
to clarify the p2m type change code.
  - According to comments from George: use locks in the same order
to avoid deadlock, call p2m_change_entry_type_global() after unmap
of the ioreq server is finished.

changes in v2:
  - Move the calculation of ioreq server page entry_cout into
p2m_change_type_one() so that we do not need a seperate lock.
Note: entry_count is also calculated in resolve_misconfig()/
do_recalc(), fortunately callers of both routines have p2m
lock protected already.
  - Simplify logic in hvmop_set_mem_type().
  - Introduce routine p2m_finish_type_change() to walk the p2m
table and do the p2m reset.
---
 xen/arch/x86/hvm/ioreq.c  |  8 
 xen/arch/x86/mm/hap/hap.c |  9 +
 xen/arch/x86/mm/p2m-ept.c | 24 +++-
 xen/arch/x86/mm/p2m-pt.c  | 30 --
 xen/arch/x86/mm/p2m.c |  9 +
 xen/include/asm-x86/p2m.h |  9 -
 6 files changed, 85 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 5bf3b6d..07a6c26 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -955,6 +955,14 @@ int hvm_map_mem_type_to_ioreq_server(struct domain *d, 
ioservid_t id,
 
 spin_unlock_recursive(>arch.hvm_domain.ioreq_server.lock);
 
+if ( rc == 0 && flags == 0 )
+{
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+if ( read_atomic(>ioreq.entry_count) )
+p2m_change_entry_type_global(d, p2m_ioreq_server, p2m_ram_rw);
+}
+
 return rc;
 }
 
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index a57b385..4b591fe 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -187,6 +187,15 @@ out:
  */
 static int hap_enable_log_dirty(struct domain *d, bool_t log_global)
 {
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+/*
+ * Refuse to turn on global log-dirty mode if
+ * there are outstanding p2m_ioreq_server pages.
+ */
+if ( log_global && read_atomic(>ioreq.entry_count) )
+return -EBUSY;
+
 /* turn on PG_log_dirty bit in paging mode */
 paging_lock(d);
 d->arch.paging.mode |= PG_log_dirty;
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index cc1eb21..ecd5ceb 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -544,6 +544,12 @@ static int resolve_misconfig(struct p2m_domain *p2m, 
unsigned long gfn)
 e.ipat = ipat;
 if ( e.recalc && p2m_is_changeable(e.sa_p2mt) )
 

[Xen-devel] [PATCH v12 4/6] x86/ioreq server: Handle read-modify-write cases for p2m_ioreq_server pages.

[Yu Zhang]

In ept_handle_violation(), write violations are also treated as
read violations. And when a VM is accessing a write-protected
address with read-modify-write instructions, the read emulation
process is triggered first.

For p2m_ioreq_server pages, current ioreq server only forwards
the write operations to the device model. Therefore when such page
is being accessed by a read-modify-write instruction, the read
operations should be emulated here in hypervisor. This patch provides
such a handler to copy the data to the buffer.

Note: MMIOs with p2m_mmio_dm type do not need such special treatment
because both reads and writes will go to the device mode.

Signed-off-by: Paul Durrant 
Signed-off-by: Yu Zhang 
Reviewed-by: Jan Beulich 
---
Cc: Paul Durrant 
Cc: Jan Beulich 
Cc: Andrew Cooper 

changes in v4: 
  - Added "Reviewed-by: Jan Beulich " with one comment
change in hvmemul_do_io().

changes in v3: 
  - According to comments from Jan: clarify comments in hvmemul_do_io().

changes in v2: 
  - According to comments from Jan: rename mem_ops to ioreq_server_ops.
  - According to comments from Jan: use hvm_copy_from_guest_phys() in
ioreq_server_read(), instead of do it by myself.
---
 xen/arch/x86/hvm/emulate.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index dc6f1f2..4de3936 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -95,6 +95,26 @@ static const struct hvm_io_handler null_handler = {
 .ops = _ops
 };
 
+static int ioreq_server_read(const struct hvm_io_handler *io_handler,
+uint64_t addr,
+uint32_t size,
+uint64_t *data)
+{
+if ( hvm_copy_from_guest_phys(data, addr, size) != HVMCOPY_okay )
+return X86EMUL_UNHANDLEABLE;
+
+return X86EMUL_OKAY;
+}
+
+static const struct hvm_io_ops ioreq_server_ops = {
+.read = ioreq_server_read,
+.write = null_write
+};
+
+static const struct hvm_io_handler ioreq_server_handler = {
+.ops = _server_ops
+};
+
 static int hvmemul_do_io(
 bool_t is_mmio, paddr_t addr, unsigned long *reps, unsigned int size,
 uint8_t dir, bool_t df, bool_t data_is_addr, uintptr_t data)
@@ -195,6 +215,9 @@ static int hvmemul_do_io(
  *   a race with an unmap operation on the ioreq server, so re-try the
  *   instruction.
  *
+ *   - If the accesss is a read, this could be part of a
+ *   read-modify-write instruction, emulate the read first.
+ *
  * Note: Even when an ioreq server is found, its value could become
  * stale later, because it is possible that
  *
@@ -228,6 +251,17 @@ static int hvmemul_do_io(
 vio->io_req.state = STATE_IOREQ_NONE;
 break;
 }
+
+/*
+ * This is part of a read-modify-write instruction.
+ * Emulate the read part so we have the value available.
+ */
+if ( dir == IOREQ_READ )
+{
+rc = hvm_process_io_intercept(_server_handler, );
+vio->io_req.state = STATE_IOREQ_NONE;
+break;
+}
 }
 }
 
-- 
1.9.1


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

[Xen-devel] [PATCH v12 2/6] x86/ioreq server: Add DMOP to map guest ram with p2m_ioreq_server to an ioreq server.

[Yu Zhang]

Previously, p2m_ioreq_server is used to write-protect guest ram
pages, which are tracked with ioreq server's rangeset. However,
number of ram pages to be tracked may exceed the upper limit of
rangeset.

Now, a new DMOP - XEN_DMOP_map_mem_type_to_ioreq_server, is added
to let one ioreq server claim/disclaim its responsibility for the
handling of guest pages with p2m type p2m_ioreq_server. Users of
this DMOP can specify which kind of operation is supposed to be
emulated in a parameter named flags. Currently, this DMOP only
support the emulation of write operations. And it can be further
extended to support the emulation of read ones if an ioreq server
has such requirement in the future.

For now, we only support one ioreq server for this p2m type, so
once an ioreq server has claimed its ownership, subsequent calls
of the XEN_DMOP_map_mem_type_to_ioreq_server will fail. Users can
also disclaim the ownership of guest ram pages with p2m_ioreq_server,
by triggering this new DMOP, with ioreq server id set to the current
owner's and flags parameter set to 0.

Note:
a> both XEN_DMOP_map_mem_type_to_ioreq_server and p2m_ioreq_server
are only supported for HVMs with HAP enabled.

b> only after one ioreq server claims its ownership of p2m_ioreq_server,
will the p2m type change to p2m_ioreq_server be allowed.

Signed-off-by: Paul Durrant 
Signed-off-by: Yu Zhang 
Acked-by: Tim Deegan 
Reviewed-by: Jan Beulich 
Reviewed-by: George Dunlap 
---
Note: this patch shall be accepted together with the following ones in
this series.

Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Paul Durrant 
Cc: George Dunlap 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Tim Deegan 

changes in v11:
  - According to comments from Jan: commit message change.
  - Added "Reviewed-by: Jan Beulich "
  - Added "Reviewed-by: George Dunlap "

changes in v10:
  - According to comments from Jan: add a new patch for the libdevicemodel and 
libxc interface.
  - According to comments from Jan: remove p2m_destroy_ioreq_server(), use 
p2m_set_ioreq_server(d, 0, s) instead.
  - According to comments from Jan & Kevin: comments changes in hvmemul_do_io().
  - According to comments from Jan & Kevin: commit message  changes.

changes in v8:
  - According to comments from Jan & Paul: comments changes in hvmemul_do_io().
  - According to comments from Jan: remove the redundant code which would only
be useful for read emulations.
  - According to comments from Jan: change interface which maps mem type to
ioreq server, removed uint16_t pad and added an uint64_t opaque.
  - Address other comments from Jan, i.e. correct return values; remove stray
cast.

changes in v7:
  - Use new ioreq server interface - XEN_DMOP_map_mem_type_to_ioreq_server.
  - According to comments from George: removed domain_pause/unpause() in
hvm_map_mem_type_to_ioreq_server(), because it's too expensive,
and we can avoid the:
a> deadlock issue existed in v6 patch, between p2m lock and ioreq server
   lock by using these locks in the same order - solved in patch 4;
b> for race condition between vm exit and ioreq server unbinding, we can
   just retry this instruction.
  - According to comments from Jan and George: continue to clarify logic in
hvmemul_do_io().
  - According to comments from Jan: clarify comment in p2m_set_ioreq_server().

changes in v6:
  - Clarify logic in hvmemul_do_io().
  - Use recursive lock for ioreq server lock.
  - Remove debug print when mapping ioreq server.
  - Clarify code in ept_p2m_type_to_flags() for consistency.
  - Remove definition of P2M_IOREQ_HANDLE_WRITE_ACCESS.
  - Add comments for HVMMEM_ioreq_server to note only changes
to/from HVMMEM_ram_rw are permitted.
  - Add domain_pause/unpause() in hvm_map_mem_type_to_ioreq_server()
to avoid the race condition when a vm exit happens on a write-
protected page, just to find the ioreq server has been unmapped
already.
  - Introduce a seperate patch to delay the release of p2m
lock to avoid the race condition.
  - Introduce a seperate patch to handle the read-modify-write
operations on a write protected page.

changes in v5:
  - Simplify logic in hvmemul_do_io().
  - Use natual width types instead of fixed width types when possible.
  - Do not grant executable permission for p2m_ioreq_server entries.
  - Clarify comments and commit message.
  - Introduce a seperate patch to recalculate the p2m types after
the ioreq server unmaps the p2m_ioreq_server.

changes in v4:
  - According to Paul's advice, add comments around the definition
of HVMMEM_iore_server in hvm_op.h.
  - According to Wei Liu's comments, change the format of the commit

[Xen-devel] [PATCH v12 3/6] x86/ioreq server: Add device model wrappers for new DMOP

[Yu Zhang]

A new device model wrapper is added for the newly introduced
DMOP - XEN_DMOP_map_mem_type_to_ioreq_server.

Since currently this DMOP only supports the emulation of write
operations, attempts to trigger the DMOP with values other than
XEN_DMOP_IOREQ_MEM_ACCESS_WRITE or 0(to unmap the ioreq server)
shall fail. The wrapper shall be updated once read operations
are also to be emulated in the future.

Also note currently this DMOP only supports one memory type,
and can be extended in the future to map multiple memory types
to multiple ioreq servers, e.g. mapping HVMMEM_ioreq_serverX to
ioreq server X, This wrapper shall be updated when such change
is made.

Signed-off-by: Yu Zhang 
Reviewed-by: Paul Durrant 
Acked-by: Wei Liu 
---
Cc: Paul Durrant 
Cc: Ian Jackson 
Cc: Wei Liu 

changes in v3: 
  - Added "Acked-by: Wei Liu ".

changes in v2: 
  - According to Paul and Wei's comments: drop the compat wrapper changes.
  - Added "Reviewed-by: Paul Durrant ".
---
 tools/libs/devicemodel/core.c   | 25 +
 tools/libs/devicemodel/include/xendevicemodel.h | 18 ++
 tools/libs/devicemodel/libxendevicemodel.map|  1 +
 3 files changed, 44 insertions(+)

diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c
index a85cb49..ff09819 100644
--- a/tools/libs/devicemodel/core.c
+++ b/tools/libs/devicemodel/core.c
@@ -244,6 +244,31 @@ int xendevicemodel_unmap_io_range_from_ioreq_server(
 return xendevicemodel_op(dmod, domid, 1, , sizeof(op));
 }
 
+int xendevicemodel_map_mem_type_to_ioreq_server(
+xendevicemodel_handle *dmod, domid_t domid, ioservid_t id, uint16_t type,
+uint32_t flags)
+{
+struct xen_dm_op op;
+struct xen_dm_op_map_mem_type_to_ioreq_server *data;
+
+if (type != HVMMEM_ioreq_server ||
+flags & ~XEN_DMOP_IOREQ_MEM_ACCESS_WRITE) {
+errno = EINVAL;
+return -1;
+}
+
+memset(, 0, sizeof(op));
+
+op.op = XEN_DMOP_map_mem_type_to_ioreq_server;
+data = _mem_type_to_ioreq_server;
+
+data->id = id;
+data->type = type;
+data->flags = flags;
+
+return xendevicemodel_op(dmod, domid, 1, , sizeof(op));
+}
+
 int xendevicemodel_map_pcidev_to_ioreq_server(
 xendevicemodel_handle *dmod, domid_t domid, ioservid_t id,
 uint16_t segment, uint8_t bus, uint8_t device, uint8_t function)
diff --git a/tools/libs/devicemodel/include/xendevicemodel.h 
b/tools/libs/devicemodel/include/xendevicemodel.h
index b3f600e..1da216f 100644
--- a/tools/libs/devicemodel/include/xendevicemodel.h
+++ b/tools/libs/devicemodel/include/xendevicemodel.h
@@ -104,6 +104,24 @@ int xendevicemodel_unmap_io_range_from_ioreq_server(
 uint64_t start, uint64_t end);
 
 /**
+ * This function registers/deregisters a memory type for emulation.
+ *
+ * @parm dmod a handle to an open devicemodel interface.
+ * @parm domid the domain id to be serviced.
+ * @parm id the IOREQ Server id.
+ * @parm type the memory type to be emulated. For now, only HVMMEM_ioreq_server
+ *is supported, and in the future new types can be introduced, e.g.
+ *HVMMEM_ioreq_serverX mapped to ioreq server X.
+ * @parm flags operations to be emulated; 0 for unmap. For now, only write
+ * operations will be emulated and can be extended to emulate
+ * read ones in the future.
+ * @return 0 on success, -1 on failure.
+ */
+int xendevicemodel_map_mem_type_to_ioreq_server(
+xendevicemodel_handle *dmod, domid_t domid, ioservid_t id, uint16_t type,
+uint32_t flags);
+
+/**
  * This function registers a PCI device for config space emulation.
  *
  * @parm dmod a handle to an open devicemodel interface.
diff --git a/tools/libs/devicemodel/libxendevicemodel.map 
b/tools/libs/devicemodel/libxendevicemodel.map
index 45c773e..130222c 100644
--- a/tools/libs/devicemodel/libxendevicemodel.map
+++ b/tools/libs/devicemodel/libxendevicemodel.map
@@ -5,6 +5,7 @@ VERS_1.0 {
xendevicemodel_get_ioreq_server_info;
xendevicemodel_map_io_range_to_ioreq_server;
xendevicemodel_unmap_io_range_from_ioreq_server;
+   xendevicemodel_map_mem_type_to_ioreq_server;
xendevicemodel_map_pcidev_to_ioreq_server;
xendevicemodel_unmap_pcidev_from_ioreq_server;
xendevicemodel_destroy_ioreq_server;
-- 
1.9.1


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

[Xen-devel] [PATCH v12 1/6] x86/ioreq server: Release the p2m lock after mmio is handled.

[Yu Zhang]

Routine hvmemul_do_io() may need to peek the p2m type of a gfn to
select the ioreq server. For example, operations on gfns with
p2m_ioreq_server type will be delivered to a corresponding ioreq
server, and this requires that the p2m type not be switched back
to p2m_ram_rw during the emulation process. To avoid this race
condition, we delay the release of p2m lock in hvm_hap_nested_page_fault()
until mmio is handled.

Note: previously in hvm_hap_nested_page_fault(), put_gfn() was moved
before the handling of mmio, due to a deadlock risk between the p2m
lock and the event lock(in commit 77b8dfe). Later, a per-event channel
lock was introduced in commit de6acb7, to send events. So we do not
need to worry about the deadlock issue.

Signed-off-by: Yu Zhang 
Reviewed-by: Jan Beulich 
---
Cc: Paul Durrant 
Cc: Jan Beulich 
Cc: Andrew Cooper 

changes in v4: 
  - According to comments from Jan: remove the redundant "rc = 0" code.
---
 xen/arch/x86/hvm/hvm.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index eba6e9d..ac7deff 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1829,15 +1829,10 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned 
long gla,
  (npfec.write_access &&
   (p2m_is_discard_write(p2mt) || (p2mt == p2m_ioreq_server))) )
 {
-__put_gfn(p2m, gfn);
-if ( ap2m_active )
-__put_gfn(hostp2m, gfn);
-
-rc = 0;
 if ( !handle_mmio_with_translation(gla, gpa >> PAGE_SHIFT, npfec) )
 hvm_inject_hw_exception(TRAP_gp_fault, 0);
 rc = 1;
-goto out;
+goto out_put_gfn;
 }
 
 /* Check if the page has been paged out */
-- 
1.9.1


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

[Xen-devel] [PATCH v12 0/6] x86/ioreq server: Introduce HVMMEM_ioreq_server mem type.

[Yu Zhang]

XenGT leverages ioreq server to track and forward the accesses to GPU 
I/O resources, e.g. the PPGTT(per-process graphic translation tables).
Currently, ioreq server uses rangeset to track the BDF/ PIO/MMIO ranges
to be emulated. To select an ioreq server, the rangeset is searched to
see if the I/O range is recorded. However, number of ram pages to be
tracked may exceed the upper limit of rangeset.

Previously, one solution was proposed to refactor the rangeset, and 
extend its upper limit. However, after 12 rounds discussion, we have
decided to drop this approach due to security concerns. Now this new 
patch series introduces a new mem type, HVMMEM_ioreq_server, and added
hvm operations to let one ioreq server to claim its ownership of ram 
pages with this type. Accesses to a page of this type will be handled
by the specified ioreq server directly.


Yu Zhang (6):
  x86/ioreq server: Release the p2m lock after mmio is handled.
  x86/ioreq server: Add DMOP to map guest ram with p2m_ioreq_server to
an ioreq server.
  x86/ioreq server: Add device model wrappers for new DMOP
  x86/ioreq server: Handle read-modify-write cases for p2m_ioreq_server
pages.
  x86/ioreq server: Asynchronously reset outstanding p2m_ioreq_server
entries.
  x86/ioreq server: Synchronously reset outstanding p2m_ioreq_server
entries when an ioreq server unmaps.

 tools/libs/devicemodel/core.c   | 25 +++
 tools/libs/devicemodel/include/xendevicemodel.h | 18 +
 tools/libs/devicemodel/libxendevicemodel.map|  1 +
 xen/arch/x86/hvm/dm.c   | 70 +-
 xen/arch/x86/hvm/emulate.c  | 95 ++--
 xen/arch/x86/hvm/hvm.c  |  7 +-
 xen/arch/x86/hvm/ioreq.c| 52 ++
 xen/arch/x86/mm/hap/hap.c   |  9 +++
 xen/arch/x86/mm/p2m-ept.c   | 32 -
 xen/arch/x86/mm/p2m-pt.c| 49 ++---
 xen/arch/x86/mm/p2m.c   | 96 +
 xen/arch/x86/mm/shadow/multi.c  |  3 +-
 xen/include/asm-x86/hvm/ioreq.h |  2 +
 xen/include/asm-x86/p2m.h   | 40 +--
 xen/include/public/hvm/dm_op.h  | 28 
 xen/include/public/hvm/hvm_op.h |  8 ++-
 16 files changed, 506 insertions(+), 29 deletions(-)

-- 
1.9.1


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

Re: [Xen-devel] [PATCH v5 11/30] ARM: GICv3 ITS: introduce device mapping

[Andre Przywara]

Hi,

On 06/04/17 16:34, Julien Grall wrote:
> Hi Andre,
> 
> On 06/04/17 00:19, Andre Przywara wrote:
>> The ITS uses device IDs to map LPIs to a device. Dom0 will later use
>> those IDs, which we directly pass on to the host.
>> For this we have to map each device that Dom0 may request to a host
>> ITS device with the same identifier.
>> Allocate the respective memory and enter each device into an rbtree to
>> later be able to iterate over it or to easily teardown guests.
>> Because device IDs are per ITS, we need to identify a virtual ITS. We
>> use the doorbell address for that purpose, as it is a nice architectural
>> MSI property and spares us handling with opaque pointer or break
>> the VGIC abstraction.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/gic-v3-its.c| 263
>> +++
>>  xen/arch/arm/vgic-v3-its.c   |   3 +
>>  xen/include/asm-arm/domain.h |   3 +
>>  xen/include/asm-arm/gic_v3_its.h |  13 ++
>>  4 files changed, 282 insertions(+)
>>
>> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
>> index eb47c9d..45bbfa7 100644
>> --- a/xen/arch/arm/gic-v3-its.c
>> +++ b/xen/arch/arm/gic-v3-its.c
>> @@ -21,6 +21,8 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -36,6 +38,26 @@
>>   */
>>  LIST_HEAD(host_its_list);
>>
>> +/*
>> + * Describes a device which is using the ITS and is used by a guest.
>> + * Since device IDs are per ITS (in contrast to vLPIs, which are per
>> + * guest), we have to differentiate between different virtual ITSes.
>> + * We use the doorbell address here, since this is a nice architectural
>> + * property of MSIs in general and we can easily get to the base address
>> + * of the ITS and look that up.
>> + */
>> +struct its_devices {
> 
> Again, why its_devices? You only store the information for one device.

You are right, and actually I fixed that already an hour ago.

>> +struct rb_node rbnode;
>> +struct host_its *hw_its;
>> +void *itt_addr;
>> +paddr_t guest_doorbell; /* Identifies the virtual ITS */
>> +uint32_t host_devid;
>> +uint32_t guest_devid;
>> +uint32_t eventids;  /* Number of event IDs (MSIs) */
>> +uint32_t *host_lpi_blocks;  /* Which LPIs are used on the
>> host */
>> +struct pending_irq *pend_irqs;  /* One struct per event */
>> +};
> 
> [...]
> 
>> +static int remove_mapped_guest_device(struct its_devices *dev)
>> +{
>> +int ret = 0;
>> +unsigned int i;
>> +
>> +if ( dev->hw_its )
>> +/* MAPD also discards all events with this device ID. */
>> +ret = its_send_cmd_mapd(dev->hw_its, dev->host_devid, 0, 0,
>> false);
>> +
>> +for ( i = 0; i < dev->eventids / LPI_BLOCK; i++ )
>> +gicv3_free_host_lpi_block(dev->host_lpi_blocks[i]);
>> +
>> +/* Make sure the MAPD command above is really executed. */
>> +if ( !ret )
>> +ret = gicv3_its_wait_commands(dev->hw_its);
>> +
>> +/* This should never happen, but just in case ... */
>> +if ( ret )
>> +printk(XENLOG_WARNING "Can't unmap host ITS device 0x%x\n",
>> +   dev->host_devid);
> 
> I think we want to ratelimit this.

OK.

>> +
>> +xfree(dev->itt_addr);
>> +xfree(dev->pend_irqs);
>> +xfree(dev->host_lpi_blocks);
>> +xfree(dev);
>> +
>> +return 0;
>> +}
> 
> [...]
> 
>> +/*
>> + * Map a hardware device, identified by a certain host ITS and its
>> device ID
>> + * to domain d, a guest ITS (identified by its doorbell address) and
>> device ID.
>> + * Also provide the number of events (MSIs) needed for that device.
>> + * This does not check if this particular hardware device is already
>> mapped
>> + * at another domain, it is expected that this would be done by the
>> caller.
>> + */
>> +int gicv3_its_map_guest_device(struct domain *d,
>> +   paddr_t host_doorbell, uint32_t
>> host_devid,
>> +   paddr_t guest_doorbell, uint32_t
>> guest_devid,
>> +   uint32_t nr_events, bool valid)
>> +{
>> +void *itt_addr = NULL;
>> +struct host_its *hw_its;
>> +struct its_devices *dev = NULL;
>> +struct rb_node **new = >arch.vgic.its_devices.rb_node, *parent
>> = NULL;
>> +unsigned int i;
>> +int ret = -ENOENT;
>> +
>> +hw_its = gicv3_its_find_by_doorbell(host_doorbell);
>> +if ( !hw_its )
>> +return ret;
>> +
>> +/* Sanitise the provided hardware values against the host ITS. */
>> +if ( host_devid >= BIT(hw_its->devid_bits) )
>> +return -EINVAL;
>> +
>> +/* We allocate events and LPIs in chunks of LPI_BLOCK (=32). */
>> +nr_events = ROUNDUP(nr_events, LPI_BLOCK);
> 
> I think it is still not enough. The MAPD command will use the number of
> bits, so you want to make sure you cover all the events in the table.
> 
> For instance, if 

Re: [Xen-devel] [PATCH] arm64: xen: Implement EFI reset_system callback

[Daniel Kiper]

Hi Julien,

On Thu, Apr 06, 2017 at 04:39:13PM +0100, Julien Grall wrote:
> Hi Daniel,
>
> On 06/04/17 16:20, Daniel Kiper wrote:
> >On Thu, Apr 06, 2017 at 04:38:24PM +0200, Juergen Gross wrote:
> >>On 06/04/17 16:27, Daniel Kiper wrote:
> >>>On Thu, Apr 06, 2017 at 09:32:32AM +0100, Julien Grall wrote:
> Hi Juergen,
> 
> On 06/04/17 07:23, Juergen Gross wrote:
> >On 05/04/17 21:49, Boris Ostrovsky wrote:
> >>On 04/05/2017 02:14 PM, Julien Grall wrote:
> >>>The x86 code has theoritically a similar issue, altought EFI does not
> >>>seem to be the preferred method. I have left it unimplemented on x86 
> >>>and
> >>>CCed Linux Xen x86 maintainers to know their view here.
> >>
> >>(+Daniel)
> >>
> >>This could be a problem for x86 as well, at least theoretically.
> >>xen_machine_power_off() may call pm_power_off(), which is 
> >>efi.reset_system.
> >>
> >>So I think we should have a similar routine there.
> >
> >+1
> >
> >I don't see any problem with such a routine added, in contrast to
> >potential "reboots" instead of power off without it.
> >
> >So I think this dummy xen_efi_reset_system() should be added to
> >drivers/xen/efi.c instead.
> 
> I will resend the patch during day with xen_efi_reset_system moved
> to common code and implement the x86 counterpart (thought, I will
> not be able to test it).
> >>>
> >>>I think that this is ARM specific issue. On x86 machine_restart() calls
> >>>xen_restart(). Hence, everything works. So, I think that it should be
> >>>fixed only for ARM. Anyway, please CC me when you send a patch.
> >>
> >>What about xen_machine_power_off() (as stated in Boris' mail)?
> >
> >Guys what do you think about that:
> >
> >--- a/drivers/firmware/efi/reboot.c
> >+++ b/drivers/firmware/efi/reboot.c
> >@@ -55,7 +55,7 @@ static void efi_power_off(void)
> >
> > static int __init efi_shutdown_init(void)
> > {
> >-   if (!efi_enabled(EFI_RUNTIME_SERVICES))
> >+   if (!efi_enabled(EFI_RUNTIME_SERVICES) || efi_enabled(EFI_PARAVIRT))
> >return -ENODEV;
> >
> >if (efi_poweroff_required())
> >
> >
> >Julien, for ARM64 please take a look at 
> >arch/arm64/kernel/efi.c:efi_poweroff_required(void).
> >
> >I hope that tweaks for both files should solve our problem.
>
> This sounds good for power off (I haven't tried to power off DOM0
> yet). But this will not solve the restart problem (see
> machine_restart in arch/arm64/kernel/process.c) which call directly
> efi_reboot.

Hmmm... It seems to me that efi.reset_system override with empty function
in arch/arm/xen/efi.c is the best solution. So, I see three patches here.
One for drivers/firmware/efi/reboot.c, one for arch/arm/xen/efi.c and one
for arch/arm64/kernel/efi.c. Does it make sense?

Daniel

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

Re: [Xen-devel] [PATCH v5 12/30] ARM: GICv3: introduce separate pending_irq structs for LPIs

[Julien Grall]

Hi Andre,

On 06/04/17 00:19, Andre Przywara wrote:

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 142eb64..5128f13 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1451,6 +1451,9 @@ static int vgic_v3_domain_init(struct domain *d)

 vgic_v3_its_init_domain(d);

+rwlock_init(>arch.vgic.pend_lpi_tree_lock);
+radix_tree_init(>arch.vgic.pend_lpi_tree);
+
 /*
  * Domain 0 gets the hardware address.
  * Guests get the virtual platform layout.
@@ -1524,14 +1527,33 @@ static int vgic_v3_domain_init(struct domain *d)
 static void vgic_v3_domain_free(struct domain *d)
 {
 vgic_v3_its_free_domain(d);
+radix_tree_destroy(>arch.vgic.pend_lpi_tree, NULL);
 xfree(d->arch.vgic.rdist_regions);
 }

+/*
+ * Looks up a virtual LPI number in our tree of mapped LPIs. This will return
+ * the corresponding struct pending_irq, which we also use to store the
+ * enabled and pending bit plus the priority.
+ * Returns NULL if an LPI cannot be found (or no LPIs are supported).


I asked few questions on the previous version about when lpi_to_pending 
returns NULL and the fact that none of the vGIC code is able to handle 
that. I was hoping a bit of documentation/ASSERT in the code rather than 
hiding the problem as you seem to do in this version.


Looking at the whole code, I see that you insert the pending_irq in the 
radix when on MAPTI. But never remove it. However the command DISCARD or 
MAPD (V=0) will remove the mapping from the ITT.


Which means it is never possible to re-use the same vLPI again. However 
if you remove from the radix tree you may end up having the LPI still in 
LR but lpi_to_pending return NULL and make Xen segfault.


So what will protect Xen against segfault? What is the plan?



diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 503a3cf..6ee7538 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -111,6 +111,8 @@ struct arch_domain
 uint32_t rdist_stride;  /* Re-Distributor stride */
 struct rb_root its_devices; /* Devices mapped to an ITS */
 spinlock_t its_devices_lock;/* Protects the its_devices tree */
+struct radix_tree_root pend_lpi_tree; /* Stores struct pending_irq's */
+rwlock_t pend_lpi_tree_lock;/* Protects the pend_lpi_tree */
 #endif
 } vgic;

diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 894c3f1..7c86f5b 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -134,6 +134,8 @@ struct vgic_ops {
 void (*domain_free)(struct domain *d);
 /* vGIC sysreg/cpregs emulate */
 bool (*emulate_reg)(struct cpu_user_regs *regs, union hsr hsr);
+/* lookup the struct pending_irq for a given LPI interrupt */
+struct pending_irq *(*lpi_to_pending)(struct domain *d, unsigned int vlpi);
 /* Maximum number of vCPU supported */
 const unsigned int max_vcpus;
 };



Cheers,

--
Julien Grall

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