Re: [Xen-devel] [PATCH v12 16/23] x86: L2 CAT: implement CPU init flow.

[Jan Beulich]

>>> Yi Sun  06/14/17 3:26 AM >>>
> @@ -279,10 +281,14 @@ static void cat_init_feature(const struct cpuid_leaf 
> *regs,
>  switch ( type )
>  {
>  case PSR_SOCKET_L3_CAT:
> +case PSR_SOCKET_L2_CAT:
>  /* cos=0 is reserved as default cbm(all bits within cbm_len are 1). 
> */
>  feat->cos_reg_val[0] = cat_default_val(feat->cbm_len);
>  
> -wrmsrl(MSR_IA32_PSR_L3_MASK(0), cat_default_val(feat->cbm_len));
> +if ( type == PSR_SOCKET_L3_CAT )
> +wrmsrl(MSR_IA32_PSR_L3_MASK(0), cat_default_val(feat->cbm_len));
> +else
> +wrmsrl(MSR_IA32_PSR_L2_MASK(0), cat_default_val(feat->cbm_len));

Once again I think a conditional expression would yield in easier to read code,
as that would make even more obvious that the second argument is the same for
both cases.

> @@ -317,7 +323,8 @@ static void cat_init_feature(const struct cpuid_leaf 
> *regs,
>  return;
>  
>  printk(XENLOG_INFO "%s: enabled on socket %u, cos_max:%u, cbm_len:%u\n",
> -   ((type == PSR_SOCKET_L3_CDP) ? "CDP" : "L3 CAT"),
> +   ((type == PSR_SOCKET_L3_CDP) ? "CDP" :
> +((type == PSR_SOCKET_L3_CAT) ? "L3 CAT": "L2 CAT")),

At this point it would probably be better to have a static const lookup array
for the types, or for this descriptive string to be passed into the function.

> @@ -375,6 +382,12 @@ static const struct feat_props l3_cdp_props = {
>  .write_msr = l3_cdp_write_msr,
>  };
>  
> +/* L2 CAT props */
> +static const struct feat_props l2_cat_props = {
> +.cos_num = 1,
> +.type[0] = PSR_CBM_TYPE_L2,
> +};

Same remark as for CDP regarding the NULL function pointers left around here
until the later patches populate them.

> @@ -1407,6 +1424,19 @@ static void psr_cpu_init(void)
>  info->feat_init = true;
>  }
>  
> +cpuid_count_leaf(PSR_CPUID_LEVEL_CAT, 0, ®s);
> +if ( regs.b & PSR_RESOURCE_TYPE_L2 )
> +{
> +cpuid_count_leaf(PSR_CPUID_LEVEL_CAT, 2, ®s);
> +
> +feat = feat_l2_cat;
> +feat_l2_cat = NULL;
> +feat_props[PSR_SOCKET_L2_CAT] = &l2_cat_props;
> +cat_init_feature(®s, feat, info, PSR_SOCKET_L2_CAT);
> +
> +info->feat_init = true;

This recurring setting of feat_init starts looking suspicious here. Why can't
this be done once at the end of the function, outside of any if()-s?

> --- a/xen/include/asm-x86/psr.h
> +++ b/xen/include/asm-x86/psr.h
> @@ -23,6 +23,7 @@
>  
>  /* Resource Type Enumeration */
>  #define PSR_RESOURCE_TYPE_L30x2
> +#define PSR_RESOURCE_TYPE_L20x4

These are used in psr.c only afaics, so shouldn't be put in a header.

Jan

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

Re: [Xen-devel] [PATCH v12 12/23] x86: refactor psr: L3 CAT: set value: implement write msr flow.

[Jan Beulich]

>>> Yi Sun  06/30/17 7:46 AM >>>
>On 17-06-29 12:00:12, Jan Beulich wrote:
>> >>> Yi Sun  06/14/17 3:25 AM >>>
>> > +struct cos_write_info
>> > +{
>> > +unsigned int cos;
>> > +struct feat_node *feature;
>> > +uint32_t *val;
>> 
>> const?
>> 
>The member of feature, 'cos_reg_val', will be written in 'do_write_psr_msrs'.
>So, I cannot use const here.

cos_reg_val is a member of struct feat_node, not struct cos_write_info. Note 
also
the difference in field names.

Jan


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

Re: [Xen-devel] [PATCH v12 15/23] x86: refactor psr: CDP: implement set value callback function.

[Jan Beulich]

>>> Yi Sun  06/14/17 3:26 AM >>>
> This patch implements L3 CDP set value related callback function.
> 
> With this patch, 'psr-cat-cbm-set' command can work for L3 CDP.
> 
> Signed-off-by: Yi Sun 
> ---
> v12:
> - add comment to explain how to deal with the case that user set new val
>   for both DATA and CODE at same time.
> - add parameter for 'psr_cbm_type_to_feat_type' to return the feature type
>   according to it.
> - use the feature type returned by 'psr_cbm_type_to_feat_type' to check
>   if we need insert the new value into all items of the feature value 
> array.
> - use conditional expression for wrmsrl.
>   (suggested by Jan Beulich)
> ---
>  xen/arch/x86/psr.c | 36 +++-
>  1 file changed, 27 insertions(+), 9 deletions(-)
> 
> diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
> index aee6e3e..91b2122 100644
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -209,7 +209,8 @@ static void free_socket_resources(unsigned int socket)
>  bitmap_zero(info->dom_set, DOMID_IDLE + 1);
>  }
>  
> -static enum psr_feat_type psr_cbm_type_to_feat_type(enum cbm_type type)
> +static enum psr_feat_type psr_cbm_type_to_feat_type(enum cbm_type type,
> +bool strict)
>  {
>  enum psr_feat_type feat_type = PSR_SOCKET_FEAT_UNKNOWN;
>  
> @@ -222,7 +223,7 @@ static enum psr_feat_type psr_cbm_type_to_feat_type(enum 
> cbm_type type)
>   * If type is L3 CAT but we cannot find it in feat_props array,
>   * try CDP.
>   */
> -if ( !feat_props[feat_type] )
> +if ( !feat_props[feat_type] && !strict )
>  feat_type = PSR_SOCKET_L3_CDP;
>  
>  break;
> @@ -358,11 +359,20 @@ static bool l3_cdp_get_feat_info(const struct feat_node 
> *feat,
>  return true;
>  }
>  
> +static void l3_cdp_write_msr(unsigned int cos, uint32_t val, enum cbm_type 
> type)
> +{
> +wrmsrl(((type == PSR_CBM_TYPE_L3_DATA) ?
> +MSR_IA32_PSR_L3_MASK_DATA(cos) :
> +MSR_IA32_PSR_L3_MASK_CODE(cos)),
> +   val);
> +}
> +
>  static const struct feat_props l3_cdp_props = {
>  .cos_num = 2,
>  .type[0] = PSR_CBM_TYPE_L3_DATA,
>  .type[1] = PSR_CBM_TYPE_L3_CODE,
>  .get_feat_info = l3_cdp_get_feat_info,
> +.write_msr = l3_cdp_write_msr,

Adding this hook only now means the earlier CDP patches must not be applied on
their own. You should state this prominently (in the patch introducing
l3_cdp_props) for whoever is going to eventually commit (parts of) this series.

> @@ -805,17 +816,24 @@ static int insert_val_into_array(uint32_t val[],
>  if ( !psr_check_cbm(feat->cbm_len, new_val) )
>  return -EINVAL;
>  
> -/* Value setting position is same as feature array. */
> +/*
> + * Value setting position is same as feature array.
> + * For CDP, user may set both DATA and CODE to same value. For such case,
> + * user input 'PSR_CBM_TYPE_L3' as type. The strict feature type of
> + * 'PSR_CBM_TYPE_L3' is L3 CAT. So, we should set new_val to both of DATA
> + * and CODE under such case.
> + */
>  for ( i = 0; i < props->cos_num; i++ )
>  {
> -if ( type == props->type[i] )
> +if ( type == props->type[i] ||
> + feat_type != psr_cbm_type_to_feat_type(type, true) )

While I think it is correct (at least up to the L2 CAT additions), it still
seems fragile to me to use != here (effectively allowing any other type to
come back). Couldn't props gain a field indicating the permitted alternative
type?

>  {
>  val[i] = new_val;
> -return 0;
> +ret = 0;
>  }

Wouldn't it be better to return -EINVAL in a to be added else branch here
and ...

>  }
>  
> -return -EINVAL;
> +return ret;
>  }

... to return zero here?

Jan

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

Re: [Xen-devel] [PATCH v12 14/23] x86: refactor psr: CDP: implement get hw info flow.

[Jan Beulich]

>>> Yi Sun  06/14/17 3:26 AM >>>
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -217,7 +217,21 @@ static enum psr_feat_type psr_cbm_type_to_feat_type(enum 
> cbm_type type)
>  {
>  case PSR_CBM_TYPE_L3:
>  feat_type = PSR_SOCKET_L3_CAT;
> +
> +/*
> + * If type is L3 CAT but we cannot find it in feat_props array,
> + * try CDP.
> + */
> +if ( !feat_props[feat_type] )
> +feat_type = PSR_SOCKET_L3_CDP;
> +
>  break;
> +
> +case PSR_CBM_TYPE_L3_DATA:
> +case PSR_CBM_TYPE_L3_CODE:
> +feat_type = PSR_SOCKET_L3_CDP;
> +break;

I think the CAT part here would better be done as a fall-through to the CDP
cases, but I won't insist on it, i.e.
Reviewed-by: Jan Beulich 
either way.

Jan

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

Re: [Xen-devel] [PATCH v12 13/23] x86: refactor psr: CDP: implement CPU init flow.

[Jan Beulich]

>>> Yi Sun  06/14/17 3:26 AM >>>
> @@ -253,6 +271,26 @@ static void cat_init_feature(const struct cpuid_leaf 
> *regs,
>  
>  break;
>  
> +case PSR_SOCKET_L3_CDP:
> +{
> +uint64_t val;
> +
> +/* Cut half of cos_max when CDP is enabled. */
> +feat->cos_max >>= 1;

I'm afraid this is off by one in the unusual but possible case of cos_max
being an even number.

> +wrmsrl(MSR_IA32_PSR_L3_MASK(0), cat_default_val(feat->cbm_len));
> +wrmsrl(MSR_IA32_PSR_L3_MASK(1), cat_default_val(feat->cbm_len));
> +rdmsrl(MSR_IA32_PSR_L3_QOS_CFG, val);
> +wrmsrl(MSR_IA32_PSR_L3_QOS_CFG,
> +   val | (1ull << PSR_L3_QOS_CDP_ENABLE_BIT));
> +
> +/* cos=0 is reserved as default cbm(all bits within cbm_len are 1). 
> */

Along the lines of a comment to an earlier patch, please add a blank ahead of
the opeing paren.

> +get_cdp_code(feat, 0) = cat_default_val(feat->cbm_len);
> +get_cdp_data(feat, 0) = cat_default_val(feat->cbm_len);

Wouldn't you better do this prior to enabling CDP?

> @@ -1294,11 +1344,21 @@ static void psr_cpu_init(void)
>  {
>  cpuid_count_leaf(PSR_CPUID_LEVEL_CAT, 1, ®s);
>  
> -feat = feat_l3_cat;
> -feat_l3_cat = NULL;
> -feat_props[PSR_SOCKET_L3_CAT] = &l3_cat_props;
> -
> -cat_init_feature(®s, feat, info, PSR_SOCKET_L3_CAT);
> +if ( (regs.c & PSR_CAT_CDP_CAPABILITY) && (opt_psr & PSR_CDP) &&
> + !info->features[PSR_SOCKET_L3_CDP] )

Doesn't this last check mean you'd set up CAT in case would come here for
the 2nd CPU on a socket? In the end the check is simplky pointless afaict,
due to psr_cpu_init() calling cat_init_feature() only if ->feat_init is still
false. But please remove it as being potentially confusing (and inconsistent
with the else branch).

Jan

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

[Xen-devel] [linux-3.18 test] 111191: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 110441
 test-armhf-armhf-xl-vhd   6 xen-install  fail REGR. vs. 110441

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

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-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110441
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110441
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 110441
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail like 110441
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 110441
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110441
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 build-arm64-pvops 6 kernel-build fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux985c6fe6e0357c79642bc506f15932983571ce93
baseline version:
 linux8366868460f8784e30302f441546a9d72ffe1236

Last test of basis   110441  2017-06-14 13:16:35 Z   15 days
Failing since111069  2017-06-26 05:55:00 Z3 days5 attempts
Testing same since   91  2017-06-29 14:22:51 Z0 days1 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Alan Stern 
  Amit Pundir 
  Andrew Morton 
  Anssi Hannula 
  Anton Bondarenko 
  Ard Biesheuvel 
  Arnd Bergmann 
  Bart Van Assche 
  Bryant G. Ly 
  Chris Brandt 
  Christoph Hellwig 
  Christophe JAILLET 
  Chu Yuan Lin 
  Corentin Labbe 
  Cyrille Pitchen 
  Dan Carpenter 
  Daniel Drake 
  David Howells 
  David S. Miller

Re: [Xen-devel] [PATCH v12 12/23] x86: refactor psr: L3 CAT: set value: implement write msr flow.

[Yi Sun]

On 17-06-29 12:00:12, Jan Beulich wrote:
> >>> Yi Sun  06/14/17 3:25 AM >>>
> > +struct cos_write_info
> > +{
> > +unsigned int cos;
> > +struct feat_node *feature;
> > +uint32_t *val;
> 
> const?
> 
The member of feature, 'cos_reg_val', will be written in 'do_write_psr_msrs'.
So, I cannot use const here.

> >  static int write_psr_msrs(unsigned int socket, unsigned int cos,
> >uint32_t val[], unsigned int array_len,
> >enum psr_feat_type feat_type)
> >  {
> > -return -ENOENT;
> > +unsigned int i;
> > +struct psr_socket_info *info = get_socket_info(socket);
> > +struct cos_write_info data =
> > +{
> > +.cos = cos,
> > +.feature = info->features[feat_type],
> > +.props = feat_props[feat_type],
> > +};
> > +
> > +if ( cos > info->features[feat_type]->cos_max )
> > +return -EINVAL;
> > +
> > +/* Skip to the feature's value head. */
> > +for ( i = 0; i < feat_type; i++ )
> > +{
> > +if ( !info->features[i] )
> > +continue;
> > +
> > +if ( !feat_props[i] )
> > +{
> > +ASSERT_UNREACHABLE();
> > +return -ENOENT;
> > +}
> > +
> > +if ( array_len <= feat_props[feat_type]->cos_num )
> > +return -ENOSPC;
> > +
> > +array_len -= feat_props[feat_type]->cos_num;
> > +
> > +val += feat_props[feat_type]->cos_num;
> 
> Well, you guess it. But additionally - doesn't the array index in all three
> cases above need to be i? If so, please also check other patches (including

Very sorry for this obvious error!

> earlier ones, where I then may have overlooked this). It is anyway worth to
> consider making this skip-prior-features loop a helper function, as this isn't
> the first time this occurs. Otoh this would involve quite a bit of passing
> return values via pointers, so maybe that wouldn't be too efficient. And I
> guess macroizing this may end up looking a little clumsy / convoluted.
> 
Will implement 'skip-prior-features' function to do this. Thanks!

> Jan

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 0ad564ffe76f5a9286dd61a7b9e021e4b5cd0c0e
baseline version:
 ovmf 03a5572bed61a5e0af83d634962c869f89730d75

Last test of basis   89  2017-06-29 13:21:14 Z0 days
Testing same since   98  2017-06-29 20:16:20 Z0 days1 attempts


People who touched revisions under test:
  Jun Nie 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=0ad564ffe76f5a9286dd61a7b9e021e4b5cd0c0e
+ . ./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 ovmf 
0ad564ffe76f5a9286dd61a7b9e021e4b5cd0c0e
+ branch=ovmf
+ revision=0ad564ffe76f5a9286dd61a7b9e021e4b5cd0c0e
+ . ./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=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.9-testing
+ '[' x0ad564ffe76f5a9286dd61a7b9e021e4b5cd0c0e = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git

[Xen-devel] [qemu-mainline test] 111177: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-xsm  4 host-install(4) broken in 42 pass in 77
 test-armhf-armhf-xl-vhd   4 host-install(4)  broken pass in 42
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail 
pass in 42

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail in 42 like 111031
 test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 42 never pass
 test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 42 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 111065
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 111065
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 111065
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 111065
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 111065
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 111065
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 111065
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuu577caa2672ccde7352fda3ef17e44993de862f0e
baseline version:
 qemuu931892e8a691a8a4151cc5fe1e13c14294bb28fb

Last test of basis   111065  2017-06-26 00:16:25 Z4 days
Failing since111092  2017-06-27 10:02:56 Z2 days3 attempts
Testing same since   42  2017-06-28 10:17:18 Z1 days2 attempts


People who touched revisions under test:
  Alberto Garcia 
  Edgar E. Iglesias 
  Kevin Wolf 
  KONRAD Frederic 
  Laszlo Ersek 
  Manos Pitsidianakis 
  Max Reitz 
  Peter Maydell 
  sochin.jiang 
  Stefan Hajnoczi 
  Stephen Bates 

jobs:
 build-amd64-xsm

[Xen-devel] [PATCH 0/2] Add support parse PCI iommu bindings for Xen SMMU

[Wei Chen]

The legacy IOMMU bindings will be deprecated in future. Instead, device
tree provide generic IOMMU bindings and PCI IOMMU bindings. Currently,
the PCI support hasn't been enabled on ARM Xen. So in this series, we
just add the support of parsing PCI IOMMU bindings.

Wei Chen (2):
  xen: devicetree: Introduce a helper to translate PCI requester ID
  xen/arm: smmu: Parse generic iommu binding for PCI devices

 xen/common/device_tree.c   | 89 ++
 xen/drivers/passthrough/arm/smmu.c | 73 ++-
 xen/include/xen/device_tree.h  | 23 ++
 3 files changed, 183 insertions(+), 2 deletions(-)

-- 
2.7.4


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

[Xen-devel] [PATCH 1/2] xen: devicetree: Introduce a helper to translate PCI requester ID

[Wei Chen]

Each PCI(e) device under a root complex is uniquely identified by its
Requester ID (AKA RID). A Requester ID is a triplet of a Bus number,
Device number, and Function number. IOMMUs may distinguish PCI devices
through sideband data derived from the Requester ID. While a given PCI
device can only master through one IOMMU, a root complex may split
masters across a set of IOMMUs.

The generic 'iommus' property is using to describe this relationship.
This helper will be used to parse and map PCI Requester ID to IOMMU
match ID in later patches.

This patch is based on Linux of_pci.c:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/of/of_pci.c
The commit id is: 987068fcbdb7a085bb11151b91dc6f4c956c4a1b

Signed-off-by: Wei Chen 
---
 xen/common/device_tree.c  | 89 +++
 xen/include/xen/device_tree.h | 23 +++
 2 files changed, 112 insertions(+)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 7b009ea..bf95cda 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -1663,6 +1663,95 @@ int dt_parse_phandle_with_args(const struct 
dt_device_node *np,
 index, out_args);
 }
 
+#define pr_err(fmt, ...) printk(XENLOG_ERR fmt, ## __VA_ARGS__)
+#define pr_info(fmt, ...) printk(XENLOG_INFO fmt, ## __VA_ARGS__)
+#define pr_debug(fmt, ...) printk(XENLOG_DEBUG fmt, ## __VA_ARGS__)
+
+int dt_pci_map_rid(struct dt_device_node *np, u32 rid,
+   const char *map_name, const char *map_mask_name,
+   struct dt_device_node **target, u32 *id_out)
+{
+u32 map_mask, masked_rid, map_len;
+const __be32 *map = NULL;
+
+if ( !np || !map_name || (!target && !id_out) )
+return -EINVAL;
+
+map = dt_get_property(np, map_name, &map_len);
+if ( !map )
+{
+if (target)
+return -ENODEV;
+/* Otherwise, no map implies no translation */
+*id_out = rid;
+return 0;
+}
+
+if ( !map_len || map_len % (4 * sizeof(*map)) )
+{
+pr_err("%s: Error: Bad %s length: %d\n", np->full_name,
+   map_name, map_len);
+return -EINVAL;
+}
+
+/*
+ * Can be overridden by "{iommu,msi}-map-mask" property.
+ * If of_property_read_u32() fails, the default is used.
+ */
+if ( !map_mask_name ||
+ !dt_property_read_u32(np, map_mask_name, &map_mask) )
+/* The default is to select all bits. */
+map_mask = 0x;
+
+masked_rid = map_mask & rid;
+for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4 )
+{
+struct dt_device_node *phandle_node;
+u32 rid_base = be32_to_cpup(map + 0);
+u32 phandle = be32_to_cpup(map + 1);
+u32 out_base = be32_to_cpup(map + 2);
+u32 rid_len = be32_to_cpup(map + 3);
+
+if ( rid_base & ~map_mask )
+{
+pr_err("%s: Invalid %s translation - %s-mask (0x%x) ignores 
rid-base (0x%x)\n",
+np->full_name, map_name, map_name,
+map_mask, rid_base);
+return -EFAULT;
+}
+
+if ( masked_rid < rid_base || masked_rid >= rid_base + rid_len )
+continue;
+
+phandle_node = dt_find_node_by_phandle(phandle);
+if ( !phandle_node )
+return -ENODEV;
+
+if ( target )
+{
+if ( *target == NULL )
+*target = phandle_node;
+
+if ( *target != phandle_node )
+continue;
+}
+
+if ( id_out )
+*id_out = masked_rid - rid_base + out_base;
+
+pr_info("%s: %s, using mask %08x, rid-base: %08x, out-base: %08x, 
length: %08x, rid: %08x -> %08x\n",
+np->full_name, map_name, map_mask, rid_base, out_base,
+rid_len, rid, *id_out);
+return 0;
+}
+
+pr_err("%s: Invalid %s translation - no match for rid 0x%x on %s\n",
+   np->full_name, map_name, rid,
+   target && *target ? (*target)->full_name : "any target");
+
+return -EFAULT;
+}
+
 /**
  * unflatten_dt_node - Alloc and populate a device_node from the flat tree
  * @fdt: The parent device tree blob
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 0aecbe0..0bddd7f 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -486,6 +486,29 @@ int dt_find_node_by_gpath(XEN_GUEST_HANDLE(char) u_path, 
uint32_t u_plen,
   struct dt_device_node **node);
 
 /**
+ * dt_pci_map_rid - Translate a requester ID through a downstream mapping.
+ * @np: root complex device node.
+ * @rid: PCI requester ID to map.
+ * @map_name: property name of the map to use.
+ * @map_mask_name: optional property name of the mask to use.
+ * @target: optional pointer to a target device node.
+ * @id_out: optional pointer to receive the translated ID.
+ *
+ * Given a PCI requester ID, look up the appropriate imple

[Xen-devel] [PATCH 2/2] xen/arm: smmu: Parse generic iommu binding for PCI devices

[Wei Chen]

The legacy smmu binding will be deprecated in favour of the generic
"iommus" binding. So we need a new helper to parse generic iommu
bindings. When the system detects the SMMU is using generic iommu
binding, this helper will be called when this platform device is
assiged to a guest.

This patch is based on Linux of_iommu.c:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iommu/of_iommu.c
The commit id is:
2a0c57545a291f257cd231b1c4b18285b84608d8

Signed-off-by: Wei Chen 
---
 xen/drivers/passthrough/arm/smmu.c | 73 --
 1 file changed, 71 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 25f2207..50ff997 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -2750,7 +2750,72 @@ static int arm_smmu_platform_iommu_init(struct device 
*dev)
return 0;
 }
 
-static int arm_smmu_xen_add_device(u8 devfn, struct device*dev)
+/*
+ * Currently, we haven't supported PCI device on ARM. So this is the
+ * temporary function to get device node of pci bridge device for
+ * function verification only
+ */
+static struct device_node *pci_get_bridge_device_node(struct device *dev)
+{
+   struct device_node *dt_dev;
+   const char *type_str;
+
+   dt_for_each_device_node(dt_host, dt_dev) {
+   /* Return the first pci bridge device node simply */
+   if (!dt_property_read_string(dt_dev, "device_type", &type_str) 
&&
+   !strcmp(type_str, "pci"))
+   return dt_dev;
+   }
+
+   return NULL;
+}
+
+#define PCI_DEVID(bus, devfn)  u16)(bus)) << 8) | (devfn))
+
+static int arm_smmu_pci_iommu_init(struct device *dev, u8 devfn)
+{
+   struct device_node *bridge_np;
+   struct of_phandle_args iommu_spec;
+   struct pci_dev *pdev = to_pci_dev(dev);
+   int ret;
+
+   bridge_np = pci_get_bridge_device_node(dev);
+   if (!bridge_np) {
+   dev_err(dev, "Cloud not find the pci bridge device node!\n");
+   return -ENODEV;
+   }
+
+   /*
+* Start by tracing the RID alias down the PCI topology as
+* far as the host bridge whose OF node we have...
+* (we're not even attempting to handle multi-alias devices yet)
+*/
+   iommu_spec.args_count = 1;
+   iommu_spec.np = bridge_np;
+   ret = __arm_smmu_get_pci_sid(pdev, PCI_DEVID(pdev->bus, devfn),
+   &iommu_spec.args[0]);
+   if (ret) {
+   dev_err(dev, "Get pci requester ID failed, err=%d!\n", ret);
+   return ret;
+   }
+
+   /*
+* ...then find out what that becomes once it escapes the PCI
+* bus into the system beyond, and which IOMMU it ends up at.
+*/
+   iommu_spec.np = NULL;
+   ret = dt_pci_map_rid(bridge_np, iommu_spec.args[0], "iommu-map",
+   "iommu-map-mask", &iommu_spec.np,
+   iommu_spec.args);
+   if (ret) {
+   dev_err(dev, "Do pci map rid failed, err=%d\n", ret);
+   return ret;
+   }
+
+   return arm_smmu_of_xlate(dev, &iommu_spec);
+}
+
+static int arm_smmu_xen_add_device(u8 devfn, struct device *dev)
 {
int ret;
 
@@ -2760,7 +2825,11 @@ static int arm_smmu_xen_add_device(u8 devfn, struct 
device*dev)
 * register Master IDs while this function had been invoked.
 */
if (using_generic_binding) {
-   ret = arm_smmu_platform_iommu_init(dev);
+   if (dev_is_pci(dev))
+   ret = arm_smmu_pci_iommu_init(dev, devfn);
+   else
+   ret = arm_smmu_platform_iommu_init(dev);
+
if (ret)
return ret;
}
-- 
2.7.4


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

[Xen-devel] [PATCH 4/7] xen/arm: SMMU: Detect types of device tree binding

[Wei Chen]

The device tree provides two types of IOMMU bindings, one is legacy
another is generic. The legacy bindings will be depercated in favour
of the generic bindings. But in the transitional period, we have to
support both of them.

The codes to handle these two types of bindings are very differnet,
so we have to detect the binding types while doing SMMU probing.

This detect code is based on Linux ARM SMMUv2 driver:
https://github.com/torvalds/linux/blob/master/drivers/iommu/arm-smmu.c

Signed-off-by: Wei Chen 
---
 xen/drivers/passthrough/arm/smmu.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 2efa52d..441c296 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -143,6 +143,8 @@ typedef enum irqreturn irqreturn_t;
 
 #define dev_name(dev) dt_node_full_name(dev_to_dt(dev))
 
+#define pr_notice(fmt, ...) printk(XENLOG_INFO fmt, ## __VA_ARGS__)
+
 /* Alias to Xen allocation helpers */
 #define kfree xfree
 #define kmalloc(size, flags)   _xmalloc(size, sizeof(void *))
@@ -681,6 +683,8 @@ struct arm_smmu_option_prop {
const char *prop;
 };
 
+static bool using_legacy_binding, using_generic_binding;
+
 static struct arm_smmu_option_prop arm_smmu_options[] = {
{ ARM_SMMU_OPT_SECURE_CFG_ACCESS, "calxeda,smmu-secure-config-access" },
{ 0, NULL},
@@ -2289,6 +2293,25 @@ static int arm_smmu_device_dt_probe(struct 
platform_device *pdev)
struct rb_node *node;
struct of_phandle_args masterspec;
int num_irqs, i, err;
+   bool legacy_binding;
+
+   /*
+* Xen: Do the same check as Linux. Checking the SMMU device tree 
bindings
+* are either using generic or legacy one.
+*
+* The "mmu-masters" property is only existed in legacy bindings.
+*/
+   legacy_binding = dt_find_property(dev->of_node, "mmu-masters", NULL);
+   if (legacy_binding && !using_generic_binding) {
+   if (!using_legacy_binding)
+   pr_notice("deprecated \"mmu-masters\" DT property in 
use\n");
+   using_legacy_binding = true;
+   } else if (!legacy_binding && !using_legacy_binding) {
+   using_generic_binding = true;
+   } else {
+   dev_err(dev, "not probing due to mismatched DT properties\n");
+   return -ENODEV;
+   }
 
smmu = devm_kzalloc(dev, sizeof(*smmu), GFP_KERNEL);
if (!smmu) {
-- 
2.7.4


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

[Xen-devel] [PATCH 1/7] xen/arm: SMMU: Implement the add_device callback in SMMU

[Wei Chen]

This add_device callback function is taking care of adding a device
to SMMU and make sure it is fully prepare to be used by the SMMU
afterwards.

In previous code, we don't implement the add_device callback in
iommu_ops for ARM SMMU. We placed the work of add_device to
assign_device callback. The function assign_device should not care
about adding the device to an iommu_group. It might not even be
able to decide how to do that. In this patch, we move this work
back to add_device callback.

This add_device callback is only called while we are handling all
devices for constructing the Domain0.

Signed-off-by: Wei Chen 
---
 xen/drivers/passthrough/arm/smmu.c | 34 +++---
 1 file changed, 23 insertions(+), 11 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 74c09b0..2efa52d 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -2591,6 +2591,26 @@ static void arm_smmu_destroy_iommu_domain(struct 
iommu_domain *domain)
xfree(domain);
 }
 
+static int arm_smmu_xen_add_device(u8 devfn, struct device*dev)
+{
+   if (dt_device_is_protected(dev->of_node)) {
+   if (!dev->archdata.iommu) {
+   dev->archdata.iommu = xzalloc(struct 
arm_smmu_xen_device);
+   if (!dev->archdata.iommu)
+   return -ENOMEM;
+   }
+
+   if (!dev_iommu_group(dev))
+   return arm_smmu_add_device(dev);
+   }
+
+   /*
+* Return 0 if the device is not protected to follow the behavior
+* of PCI add device.
+*/
+   return 0;
+}
+
 static int arm_smmu_assign_dev(struct domain *d, u8 devfn,
   struct device *dev, u32 flag)
 {
@@ -2600,17 +2620,8 @@ static int arm_smmu_assign_dev(struct domain *d, u8 
devfn,
 
xen_domain = dom_iommu(d)->arch.priv;
 
-   if (!dev->archdata.iommu) {
-   dev->archdata.iommu = xzalloc(struct arm_smmu_xen_device);
-   if (!dev->archdata.iommu)
-   return -ENOMEM;
-   }
-
-   if (!dev_iommu_group(dev)) {
-   ret = arm_smmu_add_device(dev);
-   if (ret)
-   return ret;
-   }
+   if (!dev_iommu_group(dev))
+   return -ENODEV;
 
spin_lock(&xen_domain->lock);
 
@@ -2784,6 +2795,7 @@ static const struct iommu_ops arm_smmu_iommu_ops = {
 .teardown = arm_smmu_iommu_domain_teardown,
 .iotlb_flush = arm_smmu_iotlb_flush,
 .iotlb_flush_all = arm_smmu_iotlb_flush_all,
+.add_device = arm_smmu_xen_add_device,
 .assign_device = arm_smmu_assign_dev,
 .reassign_device = arm_smmu_reassign_dev,
 .map_page = arm_smmu_map_page,
-- 
2.7.4


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

[Xen-devel] [PATCH 3/7] xen/arm: Prepare SMMU resources for protected devices

[Wei Chen]

In previous code, while we are constructing Dom0, we will assign
all devices except passthrough devices to Dom0. In the later, when
we start the DomU, the assign_device will prepare SMMU resources
for the devices passthrough to DomU. This is ok when we kept the
add_device code in assign_device. But currently, we have separated
add_device from assign_device. If we don't prepare SMMU resources
for passthrough devices, these devices would not work properly in
DomU.

So, while we are handling all devices DT node in construction Dom0,
we will call add_device to prepare SMMU resources for all protected
devices, regardless of passthrough or not.

Signed-off-by: Wei Chen 
---
 xen/arch/arm/domain_build.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c6776d7..6aea427 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1082,6 +1082,18 @@ static int handle_device(struct domain *d, struct 
dt_device_node *dev,
 dt_dprintk("%s passthrough = %d nirq = %d naddr = %u\n",
dt_node_full_name(dev), need_mapping, nirq, naddr);
 
+/*
+ * If this device is behind the SMMU, the add_device callback will
+ * prepare resource for it. Otherwise, add_device has no effect.
+ */
+res = iommu_add_dt_device(d, dev);
+if ( res )
+{
+printk(XENLOG_ERR "Failed to add device to IOMMU for %s\n",
+   dt_node_full_name(dev));
+return res;
+}
+
 if ( dt_device_is_protected(dev) && need_mapping )
 {
 dt_dprintk("%s setup iommu\n", dt_node_full_name(dev));
-- 
2.7.4


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

[Xen-devel] [PATCH 6/7] xen/arm: SMMU: Support generic IOMMU bindings

[Wei Chen]

The SMMU MasterIDs are placed at the master devices' DT node while
using the generic bindings. In this case, it's very hard for us to
register SMMU masters while probing SMMU as we had done for legacy
bindings. Because we have to go through whole device tree for all
SMMU devices to find their master devices.

It's better to register SMMU master for generic bindings in add_device
callback. This callback will only be called while constructing Dom0.

Signed-off-by: Wei Chen 
---
 xen/drivers/passthrough/arm/smmu.c | 144 -
 1 file changed, 143 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 895024c..25f2207 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -2621,8 +2621,150 @@ static void arm_smmu_destroy_iommu_domain(struct 
iommu_domain *domain)
xfree(domain);
 }
 
+static int arm_smmu_add_generic_master_id(struct arm_smmu_device *smmu,
+   struct device *master_dev, u16 fwid)
+{
+   struct arm_smmu_master *master;
+   struct device_node *master_np = master_dev->of_node;
+
+   master = find_smmu_master(smmu, master_np);
+   if (!master) {
+   dev_notice(smmu->dev,
+   "This smmu master [%s] hasn't been registered, creating 
now!\n",
+   master_np->full_name);
+   master = devm_kzalloc(smmu->dev, sizeof(*master), GFP_KERNEL);
+   if (!master)
+   return -ENOMEM;
+
+   master->of_node = master_np;
+   master->cfg.num_streamids = 0;
+
+   /*
+* Xen: Let Xen know that the device is protected by a SMMU.
+* Only do while registering the master.
+*/
+   dt_device_set_protected(master_np);
+   }
+
+   /*
+* If the smmu is using the stream index mode, check whether
+* the streamid exceeds the max allowed id,
+*/
+   if (!(smmu->features & ARM_SMMU_FEAT_STREAM_MATCH) &&
+   (fwid >= smmu->num_mapping_groups)) {
+   dev_err(smmu->dev,
+   "Stream ID for master device %s greater than maximum 
allowed (%d)\n",
+   master_np->name, smmu->num_mapping_groups);
+   return -ERANGE;
+   }
+
+   if (master->cfg.num_streamids >= MAX_MASTER_STREAMIDS) {
+   dev_err(smmu->dev,
+   "Reached maximum number (%d) of stream IDs for master 
device %s\n",
+   MAX_MASTER_STREAMIDS, master_np->name);
+   return -ENOSPC;
+   }
+
+   /*
+* If this is the first time we add id to this master,
+* we have to register this master to rb tree.
+*/
+   if (!master->cfg.num_streamids) {
+   int ret;
+   ret = insert_smmu_master(smmu, master);
+   if ( ret && ret != -EEXIST ) {
+   dev_err(smmu->dev,
+   "Insert %s to smmu's master rb tree failed\n", 
master_np->name);
+   return ret;
+   }
+   }
+
+   master->cfg.streamids[master->cfg.num_streamids] = fwid;
+   master->cfg.num_streamids++;
+   dev_dbg(smmu->dev,
+   "Add new streamid [%d] to smmu [%s] for master [%s]!\n",
+   fwid, smmu->dev->of_node->name, master_np->name);
+
+   return 0;
+}
+
+static struct arm_smmu_device *find_smmu(const struct device *dev);
+
+static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
+{
+   struct arm_smmu_device *smmu;
+   u32 mask = 0, fwid = 0;
+
+   smmu = find_smmu(dt_to_dev(args->np));
+   if (!smmu) {
+   dev_err(dev, "Could not find smmu device!\n");
+   return -ENODEV;
+   }
+
+   if (args->args_count > 0)
+   fwid |= (u16)args->args[0];
+
+   if (args->args_count > 1)
+   fwid |= (u16)args->args[1] << SMR_MASK_SHIFT;
+   else if (!of_property_read_u32(args->np, "stream-match-mask", &mask))
+   fwid |= (u16)mask << SMR_MASK_SHIFT;
+
+   dev_dbg(dev, "%s fwid:%08x mask:%08x args_count:%d\n",
+  args->np->full_name, fwid,
+  mask, args->args_count);
+
+   return arm_smmu_add_generic_master_id(smmu, dev, (u16)fwid);
+}
+
+/*
+ * Parse "iommus" information from generic bindings of platfomr master
+ * device, and then xlate to master IDs and register to SMMU device.
+ */
+static int arm_smmu_platform_iommu_init(struct device *dev)
+{
+   struct of_phandle_args iommu_spec;
+   int idx = 0, ret;
+
+   /*
+* We don't currently walk up the tree looking for a parent IOMMU.
+* See the `Notes:' section of
+* Documentation/devicetree/bindings/iommu/iommu.txt
+*/
+   while (!of_parse_phandle_

[Xen-devel] [PATCH 2/7] xen/arm: SMMU: Introduce a helper to add DT device to SMMU

[Wei Chen]

In current code, we only have the iommu_add_device to add PCI device
to IOMMU. But for ARM SMMU, we don't have a separate helper to add
platform device with device tree to SMMU. This work was included in
the iommu_assign_dt_device. But sometimes, we just want to add device
to SMMU to do some preparation for further use. In this case, we can't
call iommu_assign_dt_device.

In previous patch, we have implement the add_device callback for SMMU,
so we can separate this work from assign_device now.

Signed-off-by: Wei Chen 
---
 xen/drivers/passthrough/device_tree.c | 20 
 xen/include/xen/iommu.h   |  1 +
 2 files changed, 21 insertions(+)

diff --git a/xen/drivers/passthrough/device_tree.c 
b/xen/drivers/passthrough/device_tree.c
index 99ed49e..a8f403a 100644
--- a/xen/drivers/passthrough/device_tree.c
+++ b/xen/drivers/passthrough/device_tree.c
@@ -24,6 +24,26 @@
 
 static spinlock_t dtdevs_lock = SPIN_LOCK_UNLOCKED;
 
+int iommu_add_dt_device(struct domain *d, struct dt_device_node *dev)
+{
+int rc;
+
+struct domain_iommu *hd = dom_iommu(d);
+
+if ( !iommu_enabled || !hd->platform_ops ||
+ !hd->platform_ops->add_device )
+return 0;
+
+spin_lock(&dtdevs_lock);
+
+/* The devfn field doesn't matter to DT device. */
+rc = hd->platform_ops->add_device(0, dt_to_dev(dev));
+
+spin_unlock(&dtdevs_lock);
+
+return rc;
+}
+
 int iommu_assign_dt_device(struct domain *d, struct dt_device_node *dev)
 {
 int rc = -EBUSY;
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 5803e3f..ec03faa 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -132,6 +132,7 @@ void iommu_read_msi_from_ire(struct msi_desc *msi_desc, 
struct msi_msg *msg);
 #ifdef CONFIG_HAS_DEVICE_TREE
 #include 
 
+int iommu_add_dt_device(struct domain *d, struct dt_device_node *dev);
 int iommu_assign_dt_device(struct domain *d, struct dt_device_node *dev);
 int iommu_deassign_dt_device(struct domain *d, struct dt_device_node *dev);
 int iommu_dt_domain_init(struct domain *d);
-- 
2.7.4


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

[Xen-devel] [PATCH 0/7] Generic IOMMU bindings support for Xen platform devices

[Wei Chen]

The "mmu-masters" is a property of ARM legacy SMMU dt-binding. This
property will be deprecated in favour of the generic IOMMU bindings.
In this case we have to add the generic IOMMU bindings support for
Xen platform devices.

---
This series has been tested on Seattle SoftIron server. The platform device
can be passthrough to guest with both Legacy and Generic IOMMU bindings.
I noticed that Sameer has a iommu_fwspec series in review. It would be nice
to look at it and see if we can re-use it in this series.

Wei Chen (7):
  xen/arm: SMMU: Implement the add_device callback in SMMU
  xen/arm: SMMU: Introduce a helper to add DT device to SMMU
  xen/arm: Prepare SMMU resources for protected devices
  xen/arm: SMMU: Detect types of device tree binding
  xen/arm: SMMU: Keep registering legacy master in SMMU probe
  xen/arm: SMMU: Support generic IOMMU bindings
  xen: Fix a typo in error message of iommu_do_dt_domctl

 xen/arch/arm/domain_build.c   |  12 ++
 xen/drivers/passthrough/arm/smmu.c| 232 ++
 xen/drivers/passthrough/device_tree.c |  24 +++-
 xen/include/xen/iommu.h   |   1 +
 4 files changed, 243 insertions(+), 26 deletions(-)

-- 
2.7.4


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

[Xen-devel] [PATCH 5/7] xen/arm: SMMU: Keep registering legacy master in SMMU probe

[Wei Chen]

The legacy IOMMU bindings place the SMMU MasterIDs in the SMMU device
tree node. In current code, we register the SMMU masters while probing
SMMU. It's better to keep registering legacy masters in the SMMU probing
progress. If we move registering legacy SMMU masters to add_device or
assign_device, we have to go through all SMMUs to find correct SMMU for
master device. It's inefficient and doesn't bring any enhancement.

Similarly, if we want to register generic masters in SMMU probing, we
have to go through whole device tree to find master devices for all
SMMUs. So we only keep registering legacy master in SMMU probing.

Signed-off-by: Wei Chen 
---
 xen/drivers/passthrough/arm/smmu.c | 31 +++
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 441c296..895024c 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -2375,21 +2375,28 @@ static int arm_smmu_device_dt_probe(struct 
platform_device *pdev)
if (err)
return err;
 
-   i = 0;
smmu->masters = RB_ROOT;
-   while (!of_parse_phandle_with_args(dev->of_node, "mmu-masters",
-  "#stream-id-cells", i,
-  &masterspec)) {
-   err = register_smmu_master(smmu, dev, &masterspec);
-   if (err) {
-   dev_err(dev, "failed to add master %s\n",
-   masterspec.np->name);
-   goto out_put_masters;
-   }
+   /*
+* The SMMU MasterIDs are listed in SMMU device tree node while using
+* the legacy IOMMU bindins. So in the SMMU probing progress, we will
+* register the SMMU master only for legacy bindings.
+*/
+   if (using_legacy_binding) {
+   i = 0;
+   while (!of_parse_phandle_with_args(dev->of_node, "mmu-masters",
+   "#stream-id-cells", i,
+   &masterspec)) {
+   err = register_smmu_master(smmu, dev, &masterspec);
+   if (err) {
+   dev_err(dev, "failed to add master %s\n",
+   masterspec.np->name);
+   goto out_put_masters;
+   }
 
-   i++;
+   i++;
+   }
+   dev_notice(dev, "registered %d legacy master devices\n", i);
}
-   dev_notice(dev, "registered %d master devices\n", i);
 
parse_driver_options(smmu);
 
-- 
2.7.4


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

[Xen-devel] [PATCH 7/7] xen: Fix a typo in error message of iommu_do_dt_domctl

[Wei Chen]

It's a error message about XEN_DOMCTL_deassign_device, but the
print message is XEN_DOMCTL_assign_device.

Signed-off-by: Wei Chen 
---
 xen/drivers/passthrough/device_tree.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/device_tree.c 
b/xen/drivers/passthrough/device_tree.c
index a8f403a..92adea6 100644
--- a/xen/drivers/passthrough/device_tree.c
+++ b/xen/drivers/passthrough/device_tree.c
@@ -209,8 +209,8 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct 
domain *d,
 ret = iommu_deassign_dt_device(d, dev);
 
 if ( ret )
-printk(XENLOG_G_ERR "XEN_DOMCTL_assign_dt_device: assign \"%s\""
-   " to dom%u failed (%d)\n",
+printk(XENLOG_G_ERR "XEN_DOMCTL_deassign_device: deassign \"%s\""
+   " from dom%u failed (%d)\n",
dt_node_full_name(dev), d->domain_id, ret);
 break;
 
-- 
2.7.4


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

[Xen-devel] [libvirt test] 111171: regressions - FAIL

[osstest service owner]

flight 71 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/71/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-libvirt-qcow2 10 debian-di-install  fail REGR. vs. 111061

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 111061
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 111061
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 111061
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  f914b3f2d24d05615095e5ab5b0c91560c4dc903
baseline version:
 libvirt  2065499b607a8df771761dc4249eff6ebc3adb5a

Last test of basis   111061  2017-06-25 20:57:28 Z4 days
Failing since111084  2017-06-27 05:51:54 Z2 days3 attempts
Testing same since   71  2017-06-29 04:20:45 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Cole Robinson 
  Daniel Liu 
  Erik Skultety 
  Jiri Denemark 
  John Ferlan 
  Julio Faracco 
  Lily Zhu 
  Martin Kletzander 
  Michal Privoznik 
  Peter Krempa 
  Roman Bogorodskiy 

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
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



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

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

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

[Xen-devel] [PATCH v4] VT-d: fix VF of RC integrated PF matched to wrong VT-d unit

[Chao Gao]

The problem is for a VF of RC integrated PF (e.g. PF's BDF is 00:02.0),
we would wrongly use 00:00.0 to search VT-d unit.

From SRIOV spec REV 1.0 section 3.7.3, it says:
"ARI is not applicable to Root Complex integrated Endpoints; all other
SR-IOV Capable Devices (Devices that include at least one PF) shall
implement the ARI Capability in each Function.". So PFs can be classified to
two kinds: one is RC integrated PF and the other is non-RC integrated PF. The
former can't support ARI and the latter shall support ARI. For Extended
Functions, one traditional function's BDF should be used to search VT-d unit.
And according to PCIe spec, Extened Function means within an ARI device, a
Function whose Function Number is greater than 7. Thus, the former can't be an
extended function, while the latter is as long as its devfn > 7, this check is
exactly what the original code did; The original code wasn't aware the former.

This patch directly looks up the 'is_extfn' field of PF's struct pci_dev
to decide whether the PF is a extended function.

Reported-by: Crawford, Eric R 
Signed-off-by: Chao Gao 
---
v3:
 - access pf's struct pci_pdev between pcidevs_lock() and pcidevs_unlock()
---
 xen/drivers/passthrough/vtd/dmar.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/vtd/dmar.c 
b/xen/drivers/passthrough/vtd/dmar.c
index 82040dd..27ff471 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -218,8 +218,17 @@ struct acpi_drhd_unit *acpi_find_matched_drhd_unit(const 
struct pci_dev *pdev)
 }
 else if ( pdev->info.is_virtfn )
 {
+struct pci_dev *physfn;
+
 bus = pdev->info.physfn.bus;
-devfn = PCI_SLOT(pdev->info.physfn.devfn) ? 0 : 
pdev->info.physfn.devfn;
+/*
+ * Use 0 as 'devfn' to search VT-d unit when the physical function
+ * is an Extended Function.
+ */
+pcidevs_lock();
+physfn = pci_get_pdev(pdev->seg, bus, pdev->info.physfn.devfn);
+devfn = (physfn && physfn->info.is_extfn) ? 0 : 
pdev->info.physfn.devfn;
+pcidevs_unlock();
 }
 else
 {
-- 
1.8.3.1


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

Re: [Xen-devel] [PATCH v3] VT-d: fix VF of RC integrated PF matched to wrong VT-d unit

[Chao Gao]

On Thu, Jun 29, 2017 at 04:42:33PM +0100, Roger Pau Monné wrote:
>On Thu, Jun 29, 2017 at 11:21:53AM +0800, Chao Gao wrote:
>> The problem is for a VF of RC integrated PF (e.g. PF's BDF is 00:02.0),
>> we would wrongly use 00:00.0 to search VT-d unit.
>> 
>> From SRIOV spec REV 1.0 section 3.7.3, it says:
>> "ARI is not applicable to Root Complex integrated Endpoints; all other
>> SR-IOV Capable Devices (Devices that include at least one PF) shall
>> implement the ARI Capability in each Function.". So PFs can be classified to
>> two kinds: one is RC integrated PF and the other is non-RC integrated PF. The
>> former can't support ARI and the latter shall support ARI. For Extended
>> Functions, one traditional function's BDF should be used to search VT-d unit.
>> And according to PCIe spec, Extened Function means within an ARI device, a
>> Function whose Function Number is greater than 7. Thus, the former can't be 
>> an
>> extended function, while the latter is as long as its devfn > 7, this check 
>> is
>> exactly what the original code did; The original code wasn't aware the 
>> former.
>> 
>> This patch directly looks up the 'is_extfn' field of PF's struct pci_dev
>> to decide whether the PF is a extended function.
>> 
>> Reported-by: Crawford, Eric R 
>> Signed-off-by: Chao Gao 
>> ---
>>  xen/drivers/passthrough/vtd/dmar.c | 11 ++-
>>  1 file changed, 10 insertions(+), 1 deletion(-)
>> 
>> diff --git a/xen/drivers/passthrough/vtd/dmar.c 
>> b/xen/drivers/passthrough/vtd/dmar.c
>> index 82040dd..27ff471 100644
>> --- a/xen/drivers/passthrough/vtd/dmar.c
>> +++ b/xen/drivers/passthrough/vtd/dmar.c
>> @@ -218,8 +218,17 @@ struct acpi_drhd_unit 
>> *acpi_find_matched_drhd_unit(const struct pci_dev *pdev)
>>  }
>>  else if ( pdev->info.is_virtfn )
>>  {
>> +struct pci_dev *physfn;
>> +
>>  bus = pdev->info.physfn.bus;
>> -devfn = PCI_SLOT(pdev->info.physfn.devfn) ? 0 : 
>> pdev->info.physfn.devfn;
>> +/*
>> + * Use 0 as 'devfn' to search VT-d unit when the physical function
>> + * is an Extended Function.
>> + */
>> +pcidevs_lock();
>> +physfn = pci_get_pdev(pdev->seg, bus, pdev->info.physfn.devfn);
>> +pcidevs_unlock();
>> +devfn = (physfn && physfn->info.is_extfn) ? 0 : 
>> pdev->info.physfn.devfn;
>
>AFAICT you should only release the pcidevs lock when you are done with
>the device, so that a concurrent call to pci_remove_device doesn't
>free the device while you are poking at it.

Yes. Thank you, Roger.

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

Re: [Xen-devel] [PATCH v2 0/2] libxl: cpuid bits

[Marek Marczykowski-Górecki]

On Wed, Jun 28, 2017 at 06:55:58PM +0100, Wei Liu wrote:
> On Wed, Jun 28, 2017 at 12:10:20PM +0200, Marek Marczykowski-Górecki wrote:
> > This adds handling more cpuid bits by name. Mostly based on cpu_map.xml from
> > libvirt.
> > 
> > Marek Marczykowski-Górecki (2):
> >   libxl: add more cpuid flags handling
> >   libxl: drop osvw cpuid flag
> 
> Given that I prefer to have v1 of the second patch, please resubmit a
> final version when you collect all the acks. Thanks.

Should I read this as "Acked-by: Wei Liu " on v1 of
the second patch?

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


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

[Xen-devel] [xtf test] 111193: regressions - trouble: broken/pass

[osstest service owner]

flight 93 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-1   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-3   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-2   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-4   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-5   59 leak-check/check fail REGR. vs. 111074

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-1   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-3   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-2   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-4   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-5   58 xtf/test-hvm64-xsa-221   fail   never pass

version targeted for testing:
 xtf  e8e2cf8f9b2862cef7111a66c52aa2f83a3c541d
baseline version:
 xtf  6723a66fe3e2a60793ec4fdbcd67250c954fe5d9

Last test of basis   111074  2017-06-26 14:44:07 Z3 days
Failing since44  2017-06-28 10:53:08 Z1 days4 attempts
Testing same since   67  2017-06-28 22:15:34 Z1 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  Haozhong Zhang 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   broken  
 test-xtf-amd64-amd64-2   broken  
 test-xtf-amd64-amd64-3   broken  
 test-xtf-amd64-amd64-4   broken  
 test-xtf-amd64-amd64-5   broken  



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

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

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

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


Not pushing.


commit e8e2cf8f9b2862cef7111a66c52aa2f83a3c541d
Author: Andrew Cooper 
Date:   Thu Jun 1 12:13:22 2017 +0100

Don't automatically recover from traps

While this property is useful for swint-emulation, it is unhelpful in other
situations, as it causes unexpected traps to get swallowed silently.

Reuse the existing extable logic (with fault == fixup) to recover, and
introduce _ASM_TRAP_OK() to introduce such an extable entry.

Adjust the swint-emulation and selftest logic following this behaviour 
change,
which removes the test_int3_breakpoint() case entirely.

Signed-off-by: Andrew Cooper 

commit 246fb45b1e8edb036e20c8703687f779b13ae679
Author: Andrew Cooper 
Date:   Wed Jun 28 14:51:06 2017 +

Clean up extable.h

Factor _ASM_EXTABLE() out of the C/ASM logic, and implement it in terms of
_ASM_EXTABLE_HANDLER().

No functional change.

Signed-off-by: Andrew Cooper 

commit ac6151c03b14df45c2852bf52f6905e407ecd901
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:34 2016 +0800

vvmx: test whether MSR_FEATURE_CONTROL is set correctly

Guest MSR_FEATURE_CONTROL is set by Xen hypervisor instead by
guest firmware or hvmloader, so this test instead checks whether bits
in MSR_FEATURE_CONTROL are set correctly, rather than requiring
they are all zeroed.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit b8021169a0a8611d9552b6b24e3250769e5064eb
Author: Andrew Cooper 
Date:   Wed Jun 28 13:17:41 2017 +0100

Bare-bones in-development test for nested VT-x

Based loosely on previous work from Haozhong Zhang, but rebased over
substantial upstream development work, altered to be more consistent with
existing tests, and extended to all HVM environments (rather than just 
hvm64)
to cover more test scenarios.

Signed-off-by: Andrew Cooper 

commit 4aedda03ca7e1e237cf9b3de8473303aadb8d112
Author: Andrew Cooper 
Date:   Wed Jun 28 11:24:55 2017 +0100

Test basic driver initialisation in the selftests

Signed-off-by: Andrew Cooper 

commit 1f8291174e0d5b0f6c9ecb2a588d2ba261c96a58
Author: 

Re: [Xen-devel] EL0 app, stubdoms on ARM conf call

[Volodymyr Babchuk]

Hello Dario,

On 30 June 2017 at 00:26, Dario Faggioli  wrote:
> On Thu, 2017-06-29 at 22:04 +0300, Volodymyr Babchuk wrote:
>> Hello all,
>>
> Hello,
>
>> 1. OP-TEE use case: DRM playback (secure data path).
>>
>> User wants to play a DRM-protected media file. Rights holders don't
>> want to give user any means to get DRM-free copy of that media file.
>> If you ever heard about Widevine on Android - that it is. Long story
>> short, it is possible to decrypt, decode and display a video frame in
>> a such way, that decrypted data will never be accessible to
>> userspace,
>> kernel or even to hypervisor. This is possible only when all data
>> processing is done in secure mode, which leads us to OP-TEE or
>> (another TEE).
>> So, for each video frame media player should call OP-TEE with
>> encrypted frame data.
>>
>> Good case: 24FPS movie, optimized data path: media player registers
>> shared buffers in OP-TEE only once and then reuses them during every
>> invocation. That would be one OP-TEE call per frame or 24 calls per
>> second.
>> Worst case: High frame rate movie (60 FPS), data path in not
>> optimized. Media player registers shared buffer in OP-TEE, then asks
>> it to process frame, then unregisters buffer. 60 * 3 = 180 calls per
>> second.
>>
>> Сall is done using SMC instruction. Let's assume that OP-TEE mediator
>> lives in Stubdom. There is how call sequence can look like:
>>
>> 1. DomU issues SMC, which is trapped by Hypervisor
>> 2. Hypervisor uses standard approach with ring buffer and event
>> mechanism to call Stubdom. Also it blocks DomU's vCPU which caused
>> this trap.
>> 3a. Stubdom mangles request and asks Hypervisor to issue real SMC
>> (3b. Stubdom mangles request and issues SMC by itself - potentially
>> insecure)
>> 4. After real SMC, Hypervisor returns control back to Stubdom
>> 5. Stubdom mangles return value and returns response to Hypervisor in
>> a ring buffer
>> 6. Hypervisor unblocks DomU's VCPU and schedules it.
>>
>> As you can see, there are 6 context switches
>> (DomU->HYP->Stubdom->HYP->Stubdom->HYP->DomU). There are 2 VCPU
>> switches (DomU->Stubdom->DomU). Both VCPU switches are governed by a
>> scheduler.
>> When I say "governed by scheduler" I imply that there are no
>> guarantees that needed domain will be scheduled right now.
>> This is sequence for one call. As you remember, there can be up to
>> 180
>> such calls per second in this use case. That gives us 180 * 6 ~= 1000
>> context switches per second.
>>
> Ok. This is a quite detailed, well done, and useful description of the
> specific characteristics of your workflow.

> If possible, though, I'd like to know even more. Specifically, on a
> somewhat typical system:
> - how much pCPUs will you have?
Four on our target platform. Probably, we can crank up four A53 cores,
that will gave us 8 pCPUs in total, and will ease up things. But lets
assume that we have 4 pCPUs for now.

> - how much vCPUs will Dom0 have?
Four for now. Probably it won't need so much. I think 2 will be enough.

> - what would Dom0 be doing (as in, what components of your overall
> platform would be running there), and how busy, at least roughly, do
> you expect it would be?
It runs all hardware drivers and all backends (display, input,
network, block, sound)

> - how many vCPUs will DomU have?
It depends on DomU type. Let's say from 2 to 4.

> - how many vCPUs will Stubdom have? (I'm guessing one, as there's only
> 1 OP-TEE, does that make sense?)
Unfortunately, no. OP-TEE is SMP-capable. Every pCPU can call OP-TEE
at the same time. We want to preserve this feature.

> - how many other domains will there be? How many vCPUs will each one of
> them have?
There will be third domain, which runs background jobs. I think, those
are low-priority jobs (Artem can correct me). But they will require
all computational power, that is left.

>
> I understand it's a lot of questions, but it's quite important to have
> these info, IMO. They don't have to be super-precise and totally match
> the final look and setup of your final product, it "just" have to be a
> representative enough example.
>
> I'll try to explain why I think it would be useful to know all these
> things. So, for instance, in the scenario you describe above, if you:
> - have only 1 pCPUs
> - Dom0 has 1 vCPU, and it runs the standard backeds. Which means,
> unless when DomU is doing either disk or network I/O, it's mostly idle
No. It also does composition for all (2 or 3) displays. Also it plays
sound and so on.

> - DomU has 1 vCPU
One of possible DomUs is Android. You know, that Android is very
hungry for resources. I don't expect that it will run smoothly on one
vCPU.

> - Stubdom has 1 vCPU
> - there's no other domain
>
> What I think will happen most of the time will be something like this:
>
> [1]  DomU runs
>  .
>  .
> [2]  DomU calls SMC
>  Xen blocks DomU
>  Xen wakes Stubdom
> [3]  Stubdom runs, does SMC
>  .
>  SMC done, Stubdom blocks
>  Xen wakes Dom

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-i386-libvirt5 libvirt-buildfail   like 71615
 build-amd64-libvirt   5 libvirt-buildfail   like 71615

version targeted for testing:
 ovmf 03a5572bed61a5e0af83d634962c869f89730d75
baseline version:
 ovmf 8cf19dc7a5305007bd33934838c67a7b1640f633

Last test of basis71615  2017-06-29 13:16:42 Z0 days
Testing same since71616  2017-06-29 20:20:03 Z0 days1 attempts


People who touched revisions under test:
  Tapan Shah 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-i386-libvirt   fail
 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 03a5572bed61a5e0af83d634962c869f89730d75
Author: Tapan Shah 
Date:   Wed Jun 28 02:17:24 2017 +0800

ShellPkg: Update dh command to reflect correct driver field information

dh command gets driver name and wrongly prints it as 'Child [handle]'.
It should print it as 'Driver Name [handle]'.

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

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110465
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110465
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail 
REGR. vs. 110465

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop  fail blocked in 110465
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110465
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110465
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110465
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 110465
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 110465
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  2d7021cfd7b962cc4af71e6f7b79716680da39f2
baseline version:
 xen  695bb5f504ab48c1d546446f104c1b6c0ead126d

Last test of basis   110465  2017-06-15 09:46:33 Z   14 days
Failing since110484  2017-06-16 09:32:22 Z   13 days   14 attempts
Testing same since   68  2017-06-28 23:17:25 Z0 days1 attempts

---

Re: [Xen-devel] EL0 app, stubdoms on ARM conf call

[Dario Faggioli]

On Thu, 2017-06-29 at 22:04 +0300, Volodymyr Babchuk wrote:
> Hello all,
> 
Hello,

> 1. OP-TEE use case: DRM playback (secure data path).
> 
> User wants to play a DRM-protected media file. Rights holders don't
> want to give user any means to get DRM-free copy of that media file.
> If you ever heard about Widevine on Android - that it is. Long story
> short, it is possible to decrypt, decode and display a video frame in
> a such way, that decrypted data will never be accessible to
> userspace,
> kernel or even to hypervisor. This is possible only when all data
> processing is done in secure mode, which leads us to OP-TEE or
> (another TEE).
> So, for each video frame media player should call OP-TEE with
> encrypted frame data.
> 
> Good case: 24FPS movie, optimized data path: media player registers
> shared buffers in OP-TEE only once and then reuses them during every
> invocation. That would be one OP-TEE call per frame or 24 calls per
> second.
> Worst case: High frame rate movie (60 FPS), data path in not
> optimized. Media player registers shared buffer in OP-TEE, then asks
> it to process frame, then unregisters buffer. 60 * 3 = 180 calls per
> second.
> 
> Сall is done using SMC instruction. Let's assume that OP-TEE mediator
> lives in Stubdom. There is how call sequence can look like:
> 
> 1. DomU issues SMC, which is trapped by Hypervisor
> 2. Hypervisor uses standard approach with ring buffer and event
> mechanism to call Stubdom. Also it blocks DomU's vCPU which caused
> this trap.
> 3a. Stubdom mangles request and asks Hypervisor to issue real SMC
> (3b. Stubdom mangles request and issues SMC by itself - potentially
> insecure)
> 4. After real SMC, Hypervisor returns control back to Stubdom
> 5. Stubdom mangles return value and returns response to Hypervisor in
> a ring buffer
> 6. Hypervisor unblocks DomU's VCPU and schedules it.
> 
> As you can see, there are 6 context switches
> (DomU->HYP->Stubdom->HYP->Stubdom->HYP->DomU). There are 2 VCPU
> switches (DomU->Stubdom->DomU). Both VCPU switches are governed by a
> scheduler.
> When I say "governed by scheduler" I imply that there are no
> guarantees that needed domain will be scheduled right now.
> This is sequence for one call. As you remember, there can be up to
> 180
> such calls per second in this use case. That gives us 180 * 6 ~= 1000
> context switches per second.
> 
Ok. This is a quite detailed, well done, and useful description of the
specific characteristics of your workflow.

If possible, though, I'd like to know even more. Specifically, on a
somewhat typical system:
- how much pCPUs will you have?
- how much vCPUs will Dom0 have?
- what would Dom0 be doing (as in, what components of your overall
platform would be running there), and how busy, at least roughly, do
you expect it would be?
- how many vCPUs will DomU have?
- how many vCPUs will Stubdom have? (I'm guessing one, as there's only
1 OP-TEE, does that make sense?)
- how many other domains will there be? How many vCPUs will each one of
them have?

I understand it's a lot of questions, but it's quite important to have
these info, IMO. They don't have to be super-precise and totally match
the final look and setup of your final product, it "just" have to be a
representative enough example.

I'll try to explain why I think it would be useful to know all these
things. So, for instance, in the scenario you describe above, if you:
- have only 1 pCPUs
- Dom0 has 1 vCPU, and it runs the standard backeds. Which means,
unless when DomU is doing either disk or network I/O, it's mostly idle
- DomU has 1 vCPU
- Stubdom has 1 vCPU
- there's no other domain

What I think will happen most of the time will be something like this:

[1]  DomU runs
 .
 .
[2]  DomU calls SMC
 Xen blocks DomU
 Xen wakes Stubdom
[3]  Stubdom runs, does SMC
 .
 SMC done, Stubdom blocks
 Xen wakes DomU
[4]  DomU runs
 .
 .

At [1], Dom0 and Stubdom are idle, and DomU is the only running domain
(or, to be precise, vCPU), and so it runs. When, at [2], it calls SMC,
it also blocks. Therefore, at [3], it's Stubdom that is the only
runnable domain, and in fact, the scheduler let it run. Finally, at
[4], since Stubdom has blocked again, while DomU has been woken up, the
only thing the scheduler can do is to run it (DomU).

So, as you say, even with just 1 pCPU available, if the scenario is
like I described above, there would not be the need for any fancy or
advanced improvement in the scheduler. Actually, the scheduler does
very few... It always choose to run the only vCPU that is runnable.

On the other hand if, with still only one pCPU, there are more domains
(and hence more vCPUs) around, doing other things, and/or, if Dom0 runs
some other workload, in addition to the backends for DomU, then indeed
things may get more complicated. For example, at [4], the scheduler may
choose a different vCPU than the one of DomU, and this would probably
be a problem.

What I was saying during the ca

Re: [Xen-devel] q35 support in Xen

[Stefano Stabellini]

On Fri, 30 Jun 2017, Alexey G wrote:
> Hi,
> 
> > I saw Anthony's patch, but your extension patch seems still in
> > development. Do you have plan to upstream it? I'm also interested in
> > this basically I want full PCI-e passthru capability (Current Xen does
> > support passthru a PCI-e device but guest can't see configuration offset
> > 256-4095 for example). I'm glad to collaborate on this.
> 
> Yes, I have plans to send patches for Q35 to the list. I've never
> contributed to Xen/QEMU so far but I guess it's worth to try. It might be
> a good idea to send them in batches -- split to separate parts for
> libacpi, hvmloader and QEMU. There is also a number of minor
> prerequisites which are required for Q35 support, ex. separating Xen
> Platform device support from a selected machine (as it implemented
> currently). It should be an independent option, not to be bound to a
> pc/xenfv/etc machine. 
> 
> Right now many features require the emulation of something newer than a
> i440 system, ex. MMCONFIG support will benefit from Q35 (or some other
> PCIe-specific feature).
> 
> There still a lot of work towards a complete Q35 support in Xen of course,
> but until we have a working minimum to move from there probably will be no
> progress. So upstreaming a possibility to turn on the Q35 emulation and
> actually run a guest on a Q35 system with some PCIe device passed through
> might be a good start (if there will be no objections from maintainers).

Sure, it is fine by me. Patches are very welcome!


> Fixing (well, testing actually) the xen-mapcache DMA bug or validating
> Stefano's patch for it is the first goal. The bug naturally affects Q35 but
> in theory might be reproduced using a pc/xenfv machine (much harder though),
> so it's a good candidate to start with.

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

Re: [Xen-devel] q35 support in Xen

[Alexey G]

Hi,

> I saw Anthony's patch, but your extension patch seems still in
> development. Do you have plan to upstream it? I'm also interested in
> this basically I want full PCI-e passthru capability (Current Xen does
> support passthru a PCI-e device but guest can't see configuration offset
> 256-4095 for example). I'm glad to collaborate on this.

Yes, I have plans to send patches for Q35 to the list. I've never
contributed to Xen/QEMU so far but I guess it's worth to try. It might be
a good idea to send them in batches -- split to separate parts for
libacpi, hvmloader and QEMU. There is also a number of minor
prerequisites which are required for Q35 support, ex. separating Xen
Platform device support from a selected machine (as it implemented
currently). It should be an independent option, not to be bound to a
pc/xenfv/etc machine. 

Right now many features require the emulation of something newer than a
i440 system, ex. MMCONFIG support will benefit from Q35 (or some other
PCIe-specific feature).

There still a lot of work towards a complete Q35 support in Xen of course,
but until we have a working minimum to move from there probably will be no
progress. So upstreaming a possibility to turn on the Q35 emulation and
actually run a guest on a Q35 system with some PCIe device passed through
might be a good start (if there will be no objections from maintainers).

Fixing (well, testing actually) the xen-mapcache DMA bug or validating
Stefano's patch for it is the first goal. The bug naturally affects Q35 but
in theory might be reproduced using a pc/xenfv machine (much harder though),
so it's a good candidate to start with.



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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 03a5572bed61a5e0af83d634962c869f89730d75
baseline version:
 ovmf 8cf19dc7a5305007bd33934838c67a7b1640f633

Last test of basis   72  2017-06-29 04:49:41 Z0 days
Testing same since   89  2017-06-29 13:21:14 Z0 days1 attempts


People who touched revisions under test:
  Tapan Shah 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=03a5572bed61a5e0af83d634962c869f89730d75
+ . ./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 ovmf 
03a5572bed61a5e0af83d634962c869f89730d75
+ branch=ovmf
+ revision=03a5572bed61a5e0af83d634962c869f89730d75
+ . ./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=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.9-testing
+ '[' x03a5572bed61a5e0af83d634962c869f89730d75 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.g

Re: [Xen-devel] [PATCH v1] xen/input: add multi-touch support

[Dmitry Torokhov]

On June 29, 2017 11:40:30 AM PDT, Oleksandr Andrushchenko  
wrote:
>Hi, Dmitry!
>
>First of all thank you for both the comments and the patch
>
>On 06/29/2017 11:17 AM, Dmitry Torokhov wrote:
>> Hi Oleksandr,
>>
>> On Fri, Jun 23, 2017 at 09:09:55AM +0300, Oleksandr Andrushchenko
>wrote:
>>> +   switch (event->mtouch.event_type) {
>>> +   case XENKBD_MT_EV_DOWN:
>>> +   input_mt_report_slot_state(dev, MT_TOOL_FINGER,
>>> +  true);
>>> +   input_event(dev, EV_ABS, ABS_MT_POSITION_X,
>>> +   event->mtouch.u.pos.abs_x);
>>> +   input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
>>> +   event->mtouch.u.pos.abs_y);
>>> +   input_event(dev, EV_ABS, ABS_X,
>>> +   event->mtouch.u.pos.abs_x);
>>> +   input_event(dev, EV_ABS, ABS_Y,
>>> +   event->mtouch.u.pos.abs_y);
>> I was looking at this and realized that this breaks the single touch
>> emulation for MT interface: for ST you are supposed to report the
>oldest
>> contact, here you report data for all of them. Luckily
>> input_mt_report_pointer_emulation() that is called as part of
>> input_mt_sync_frame() reports the correct ABS_X/ABS_Y data and fixes
>> that for you.
>>
>> We should simply remove reporting ABS_X/ABS_Y here and in
>> XENKBD_MT_EV_MOTION as well.
>>
>>> +
>>> +   input_set_capability(mtouch, EV_KEY, BTN_TOUCH);
>>> +   input_set_abs_params(mtouch, ABS_X,
>>> +0, width, 0, 0);
>>> +   input_set_abs_params(mtouch, ABS_Y,
>>> +0, height, 0, 0);
>>> +   input_set_abs_params(mtouch, ABS_PRESSURE,
>>> +0, 255, 0, 0);
>> This is done automatically by input_mt_init_slots() when called with
>> INPUT_MT_DIRECT (as in your case) or INPUT_MT_POINTER, so this can be
>> removed as well.
>Great, I was not actually convinced that ABS is really needed
>to be put here while dealing with MT devices,
>so the above can be removed
>> Does the patch below (on top of yours) work for you?
>Unfortunately I didn't have time to test the patch today, but will try
>to do so tomorrow.
>
>Beside that, do you think that the removals above should go into my
>patch
>and the rest of yours (it looks like needed refactoring to me) should
>go 
>into
>a separate one, not named "MT support fixups", but rather "Xen input
>driver refactoring"? Because part of the changes seems to be MT
>relevant
>and part is pure refactoring.
>If so, do you want me to rework your patch with these changes and add
>on
>top of mine (I will put your signed off) or you will handle it on your
>own?

I was planning on simply folding my changes into your patch and calling it a 
day, unless your testing would show there is an issue. It wasn't intended to be 
a separate patch in it's own right, I simply sent it out this way to show what 
exactly I was changing.


Thanks.

-- 
Dmitry

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

Re: [Xen-devel] EL0 app, stubdoms on ARM conf call

[Volodymyr Babchuk]

Hello all,

Thank you all for the call.

As was agreed, I'll to provide some details on our use cases. I want
to tell you about four cases: one is OP-TEE related, while other three
shows various aspects of virtualized coprocesssors workflow.

1. OP-TEE use case: DRM playback (secure data path).

User wants to play a DRM-protected media file. Rights holders don't
want to give user any means to get DRM-free copy of that media file.
If you ever heard about Widevine on Android - that it is. Long story
short, it is possible to decrypt, decode and display a video frame in
a such way, that decrypted data will never be accessible to userspace,
kernel or even to hypervisor. This is possible only when all data
processing is done in secure mode, which leads us to OP-TEE or
(another TEE).
So, for each video frame media player should call OP-TEE with
encrypted frame data.

Good case: 24FPS movie, optimized data path: media player registers
shared buffers in OP-TEE only once and then reuses them during every
invocation. That would be one OP-TEE call per frame or 24 calls per
second.
Worst case: High frame rate movie (60 FPS), data path in not
optimized. Media player registers shared buffer in OP-TEE, then asks
it to process frame, then unregisters buffer. 60 * 3 = 180 calls per
second.

Сall is done using SMC instruction. Let's assume that OP-TEE mediator
lives in Stubdom. There is how call sequence can look like:

1. DomU issues SMC, which is trapped by Hypervisor
2. Hypervisor uses standard approach with ring buffer and event
mechanism to call Stubdom. Also it blocks DomU's vCPU which caused
this trap.
3a. Stubdom mangles request and asks Hypervisor to issue real SMC
(3b. Stubdom mangles request and issues SMC by itself - potentially insecure)
4. After real SMC, Hypervisor returns control back to Stubdom
5. Stubdom mangles return value and returns response to Hypervisor in
a ring buffer
6. Hypervisor unblocks DomU's VCPU and schedules it.

As you can see, there are 6 context switches
(DomU->HYP->Stubdom->HYP->Stubdom->HYP->DomU). There are 2 VCPU
switches (DomU->Stubdom->DomU). Both VCPU switches are governed by a
scheduler.
When I say "governed by scheduler" I imply that there are no
guarantees that needed domain will be scheduled right now.
This is sequence for one call. As you remember, there can be up to 180
such calls per second in this use case. That gives us 180 * 6 ~= 1000
context switches per second.


2. Coprocessor use case: coprocessor context switch.

Lets assume that coprocessor was used by Dom1 and now it is time to
switch context, so Dom2 can use it. Returning back to GPU case, if we
want to show 60 FPS, then we need at least 60*N context switches,
where N is number of domains that use GPU. This is lower margin,
obviously. Context switch is done in two parts: "context switch from"
and "context switch to". Context switch procedure is device-specific,
so there should be driver for every supported device. This driver does
actual work. We can't have this driver in hypervisor. Let's assume
that driver is running in a Stubdom.
Context switch is requested by the hypervisor. So, best-case scenario
is following:

1. Hypervisor asks Stubdom to do "context switch from"
2. Stubdom sends event back to hypervisor when task is done
(Hypervisor reconfigures IOMMU)
3. Hypervisor asks Stubdom to do "context switch to"
4. Stubdom sends event back to hypervisor when task is done

You can't merge Stubdomain call to "context switch from/to", because
between p.2 and p.3 hypervisor needs to reconfigure IOMMU for GPU.
So, there are 4 context switches, two of them are governed by
scheduler. Or this is 240 context switches per second per domain per
coprocessor. As was said, this is lower margin.

3. Coprocessor use case: MMIO access from domain to a virtualized device.

Usually communication between processor and coprocessor is done in the
following way: processor writes command into a shared memory and than
kick interrupt in coprocessor, coprocessor processes task, writes
response back to a shared memory and issues IRQ to a processor.
Coprocessor is kicked by writing to one of its registers that are
mapped to a memory.

In case if vcoproc is active right now, we *might* can pass this MMIO
access right to it. But in our current case, we nevertheless need to
trap this access and route them to the driver. If vcoproc is not
active, we always need to route this MMIO access to the driver,
because only driver knows what to do with this requests right now.

So, summarizing, domain will write to MMIO range every time it wants
something from coprocessor. There can be hundreds such calls for *one*
frame (e.g. load texture, load shader, load geometry, run shader,
repeat). How it looks:
1. DomU writes or reads to/from MMIO register.
2. XEN traps this access and notifies Stubdom (also it blocks DomU vcpu)
3. Stubdom analyzes request and does actual write (or stores value internally).
4. Stubdom sends event back to XEN
5. XEN unblocks DomU vc

Re: [Xen-devel] [PATCH v1] xen/input: add multi-touch support

[Oleksandr Andrushchenko]

Hi, Dmitry!

First of all thank you for both the comments and the patch

On 06/29/2017 11:17 AM, Dmitry Torokhov wrote:

Hi Oleksandr,

On Fri, Jun 23, 2017 at 09:09:55AM +0300, Oleksandr Andrushchenko wrote:

+   switch (event->mtouch.event_type) {
+   case XENKBD_MT_EV_DOWN:
+   input_mt_report_slot_state(dev, MT_TOOL_FINGER,
+  true);
+   input_event(dev, EV_ABS, ABS_MT_POSITION_X,
+   event->mtouch.u.pos.abs_x);
+   input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
+   event->mtouch.u.pos.abs_y);
+   input_event(dev, EV_ABS, ABS_X,
+   event->mtouch.u.pos.abs_x);
+   input_event(dev, EV_ABS, ABS_Y,
+   event->mtouch.u.pos.abs_y);

I was looking at this and realized that this breaks the single touch
emulation for MT interface: for ST you are supposed to report the oldest
contact, here you report data for all of them. Luckily
input_mt_report_pointer_emulation() that is called as part of
input_mt_sync_frame() reports the correct ABS_X/ABS_Y data and fixes
that for you.

We should simply remove reporting ABS_X/ABS_Y here and in
XENKBD_MT_EV_MOTION as well.


+
+   input_set_capability(mtouch, EV_KEY, BTN_TOUCH);
+   input_set_abs_params(mtouch, ABS_X,
+0, width, 0, 0);
+   input_set_abs_params(mtouch, ABS_Y,
+0, height, 0, 0);
+   input_set_abs_params(mtouch, ABS_PRESSURE,
+0, 255, 0, 0);

This is done automatically by input_mt_init_slots() when called with
INPUT_MT_DIRECT (as in your case) or INPUT_MT_POINTER, so this can be
removed as well.

Great, I was not actually convinced that ABS is really needed
to be put here while dealing with MT devices,
so the above can be removed

Does the patch below (on top of yours) work for you?

Unfortunately I didn't have time to test the patch today, but will try
to do so tomorrow.

Beside that, do you think that the removals above should go into my patch
and the rest of yours (it looks like needed refactoring to me) should go 
into

a separate one, not named "MT support fixups", but rather "Xen input
driver refactoring"? Because part of the changes seems to be MT relevant
and part is pure refactoring.
If so, do you want me to rework your patch with these changes and add on
top of mine (I will put your signed off) or you will handle it on your own?

Thanks.


Thank you,
Oleksandr

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

Re: [Xen-devel] [PATCH v12 12/23] x86: refactor psr: L3 CAT: set value: implement write msr flow.

[Jan Beulich]

>>> Yi Sun  06/14/17 3:25 AM >>>
> +struct cos_write_info
> +{
> +unsigned int cos;
> +struct feat_node *feature;
> +uint32_t *val;

const?

>  static int write_psr_msrs(unsigned int socket, unsigned int cos,
>uint32_t val[], unsigned int array_len,
>enum psr_feat_type feat_type)
>  {
> -return -ENOENT;
> +unsigned int i;
> +struct psr_socket_info *info = get_socket_info(socket);
> +struct cos_write_info data =
> +{
> +.cos = cos,
> +.feature = info->features[feat_type],
> +.props = feat_props[feat_type],
> +};
> +
> +if ( cos > info->features[feat_type]->cos_max )
> +return -EINVAL;
> +
> +/* Skip to the feature's value head. */
> +for ( i = 0; i < feat_type; i++ )
> +{
> +if ( !info->features[i] )
> +continue;
> +
> +if ( !feat_props[i] )
> +{
> +ASSERT_UNREACHABLE();
> +return -ENOENT;
> +}
> +
> +if ( array_len <= feat_props[feat_type]->cos_num )
> +return -ENOSPC;
> +
> +array_len -= feat_props[feat_type]->cos_num;
> +
> +val += feat_props[feat_type]->cos_num;

Well, you guess it. But additionally - doesn't the array index in all three
cases above need to be i? If so, please also check other patches (including
earlier ones, where I then may have overlooked this). It is anyway worth to
consider making this skip-prior-features loop a helper function, as this isn't
the first time this occurs. Otoh this would involve quite a bit of passing
return values via pointers, so maybe that wouldn't be too efficient. And I
guess macroizing this may end up looking a little clumsy / convoluted.

Jan

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

Re: [Xen-devel] [PATCH v12 11/23] x86: refactor psr: L3 CAT: set value: implement cos id picking flow.

[Jan Beulich]

>>> Yi Sun  06/14/17 3:25 AM >>>
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -845,12 +845,97 @@ static int find_cos(const uint32_t val[], unsigned int 
> array_len,
>  return -ENOENT;
>  }
>  
> +static bool fits_cos_max(const uint32_t val[],
> + uint32_t array_len,
> + const struct psr_socket_info *info,
> + unsigned int cos)
> +{
> +unsigned int i;
> +
> +for ( i = 0; i < ARRAY_SIZE(info->features); i++ )
> +{
> +const struct feat_node *feat = info->features[i];
> +const struct feat_props *props = feat_props[i];
> +
> +if ( !feat )
> +continue;
> +
> +if ( !props )
> +{
> +ASSERT_UNREACHABLE();
> +return false;
> +}
> +
> +if ( array_len < props->cos_num )
> +return false;
> +
> +if ( cos > feat->cos_max )
> +{
> +unsigned int j;
> +
> +for ( j = 0; j < props->cos_num; j++ )
> +{
> +/*
> + * Get default value which cos id is 0.

"Get default value, the COS ID of which is zero" perhaps?

> + * For CDP:
> + * - DATA default value stored in cos_reg_val[0];
> + * - CODE default value stored in cos_reg_val[1].

Strictly speaking this doesn't belong into this patch, as you're not at CDP
yet. In fact I wonder whether this couldn't be dropped altogether.

> + */
> +uint32_t default_val = feat->cos_reg_val[j];
> +
> +if ( val[j] != default_val )
> +return false;
> +}
> +}
> +
> +array_len -= props->cos_num;
> +
> +val += props->cos_num;

Well, you already know my comment here by now, I guess.

In any case again
Reviewed-by: Jan Beulich 

Jan

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

Re: [Xen-devel] [PATCH v12 10/23] x86: refactor psr: L3 CAT: set value: implement cos finding flow.

[Jan Beulich]

>>> Yi Sun  06/14/17 3:25 AM >>>
>  static int find_cos(const uint32_t val[], unsigned int array_len,
>  enum psr_feat_type feat_type,
>  const struct psr_socket_info *info)
>  {
> +unsigned int cos, cos_max;
> +const unsigned int *ref = info->cos_ref;
> +const struct feat_node *feat;
> +
> +/* cos_max is the one of the feature which is being set. */
> +feat = info->features[feat_type];
> +if ( !feat )
> +return -ENOENT;
> +
> +cos_max = feat->cos_max;
> +
> +for ( cos = 0; cos <= cos_max; cos++ )
> +{
> +const uint32_t *val_ptr = val;
> +unsigned int len = array_len, i;
> +int rc = 0;
> +
> +if ( cos && !ref[cos] )
> +continue;
> +
> +for ( i = 0; i < ARRAY_SIZE(info->features); i++ )
> +{
> +const struct feat_props *props = feat_props[i];
> +
> +feat = info->features[i];
> +if ( !feat )
> +continue;
> +
> +if ( !props )
> +{
> +ASSERT_UNREACHABLE();
> +return -ENOENT;
> +}
> +
> +if ( len < props->cos_num )
> +return -ENOSPC;
> +
> +/*
> + * Compare value according to feature array order.
> + * We must follow this order because value array is assembled
> + * as this order.
> + */
> +rc = compare_val(val_ptr, feat, props, cos);
> +if ( rc < 0 )
> +return rc;
> +
> +/* If fail to match, go to next cos to compare. */
> +if ( !rc )
> +break;
> +
> +len -= props->cos_num;
> +
> +val_ptr += props->cos_num;

Unnecessary blank line again between these two. With that once again
Reviewed-by: Jan Beulich 

Jan

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

Re: [Xen-devel] [PATCH v12 09/23] x86: refactor psr: L3 CAT: set value: assemble features value array.

[Jan Beulich]

>>> Yi Sun  06/14/17 3:25 AM >>>
> @@ -592,7 +615,14 @@ int psr_get_val(struct domain *d, unsigned int socket,
>  /* Set value functions */
>  static unsigned int get_cos_num(const struct psr_socket_info *info)
>  {
> -return 0;
> +unsigned int num = 0, i;
> +
> +/* Get all features total amount. */
> +for ( i = 0; i < ARRAY_SIZE(feat_props); i++ )
> +if ( feat_props[i] )
> +num += feat_props[i]->cos_num;
> +
> +return num;
>  }

The function parameter isn't being used afaics (neither by later patches), so
please drop it (in the earlier patch introducing the function).

> @@ -600,7 +630,47 @@ static int gather_val_array(uint32_t val[],
>  const struct psr_socket_info *info,
>  unsigned int old_cos)
>  {
> -return -EINVAL;
> +unsigned int i;
> +
> +if ( !val )
> +return -EINVAL;
> +
> +/* Get all features current values according to old_cos. */
> +for ( i = 0; i < ARRAY_SIZE(info->features); i++ )
> +{
> +unsigned int cos = old_cos, j;
> +const struct feat_node *feat = info->features[i];
> +const struct feat_props *props = feat_props[i];
> +
> +if ( !feat )
> +continue;
> +
> +if ( !props )
> +{
> +ASSERT_UNREACHABLE();
> +return -ENOENT;
> +}
> +
> +if ( array_len < props->cos_num )
> +return -ENOSPC;
> +
> +/*
> + * If old_cos exceeds current feature's cos_max, we should get
> + * default value. So assign cos to 0 which stores default value.
> + */
> +if ( cos > feat->cos_max )
> +cos = 0;
> +
> +/* Value getting order is same as feature array. */
> +for ( j = 0; j < props->cos_num; j++ )
> +val[j] = feat->cos_reg_val[cos * props->cos_num + j];
> +
> +array_len -= props->cos_num;
> +
> +val += props->cos_num;

I don't think there should be a blank line between these two ones.

> @@ -610,6 +680,60 @@ static int insert_val_into_array(uint32_t val[],
>   enum cbm_type type,
>   uint32_t new_val)
>  {
> +const struct feat_node *feat;
> +const struct feat_props *props;
> +unsigned int i;
> +
> +ASSERT(feat_type < PSR_SOCKET_FEAT_NUM);
> +
> +/* Insert new value into array according to feature's position in array. 
> */
> +for ( i = 0; i < feat_type; i++ )
> +{
> +if ( !info->features[i] )
> +continue;
> +
> +props = feat_props[i];
> +if ( !props )
> +{
> +ASSERT_UNREACHABLE();
> +return -ENOENT;

How about you use "continue" here and drop the info->features[i] check above?

In any event
Reviewed-by: Jan Beulich 

Jan

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

Re: [Xen-devel] [PATCH 3/6] libxc: Add wrappers for new commands

[Wei Liu]

On Tue, Jun 27, 2017 at 12:14:55PM -0500, Venu Busireddy wrote:
> libxc: Add wrappers for new commands

Extraneous line here.

> 
> Add wrappers for the newly introduced commands "pci-assignable-hide",
> "pci-assignable-unhide", and "pci-assignable-list-hidden".
> 
> Signed-off-by: Venu Busireddy 
> ---
>  tools/libxc/include/xenctrl.h |  4 
>  tools/libxc/xc_domain.c   | 38 ++
>  2 files changed, 42 insertions(+)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 1629f41..9730285 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1670,6 +1670,10 @@ int xc_assign_device(xc_interface *xch,
>   uint32_t machine_sbdf,
>   uint32_t flag);
>  
> +int xc_hide_device(xc_interface *xch, uint32_t machine_bdf);
> +int xc_unhide_device(xc_interface *xch, uint32_t machine_bdf);
> +int xc_test_hidden_device(xc_interface *xch, uint32_t machine_bdf);
> +
>  int xc_get_device_group(xc_interface *xch,
>   uint32_t domid,
>   uint32_t machine_sbdf,
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index 00909ad4..714d632 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -1501,6 +1501,44 @@ int xc_assign_device(
>  return do_domctl(xch, &domctl);
>  }
>  
> +int xc_hide_device(
> +xc_interface *xch,
> +uint32_t machine_sbdf)


  int xc_hide_device(xc_interface *xch, uint32_t machine_sbdf)

Otherwise this patch looks good.

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

[Xen-devel] New Design Sessions for the Developer Summit

[Lars Kurth]

Hi all, (proposers CC'ed)

I added several new design sessions today: people on the CC list may want to 
propose different time-slots

* 
https://xendeveloperanddesignsummit2017.sched.com/event/AjEI/design-session-the-missing-toolstack-side-of-pvh-domu
* 
https://xendeveloperanddesignsummit2017.sched.com/event/AjB3/do-we-need-more-community-meetings
* 
https://xendeveloperanddesignsummit2017.sched.com/event/AjES/making-releases-lessons-learned-improving-our-release-process-and-tooling
* 
https://xendeveloperanddesignsummit2017.sched.com/event/AjHP/open-session-testing-process-testing-improvements-x86armembedded-testing-etc-does-what-we-do-today-work
* 
https://xendeveloperanddesignsummit2017.sched.com/event/AjHl/design-session-loose-ends-for-becoming-a-cna-cve-numbering-authorities

You can still submit sessions via 
http://events.linuxfoundation.org/events/xen-developer-and-design-summit/program/cfp-design-session
 until next Friday. After that, it is possible to submit sessions on the day, 
but it would be easier if we got as many as possible raised before.

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

Re: [Xen-devel] [PATCH v3 00/11] libxl: add PV display device driver interface

[Wei Liu]

Can you push this series to a git tree? It would be easier for me to
check your changes to the device framework. The device specific handlers
mostly look OK to me.

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

Re: [Xen-devel] [PATCH v3 01/11] libxl: add vdispl structures to idl

[Wei Liu]

On Tue, Jun 27, 2017 at 01:03:17PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 
> 
> Add libxl_device_vdispl and libxl_vdisplinfo to libxl_types.idl
> Add VDISPL to libxl__device_kind enumerator
> 
> Signed-off-by: Oleksandr Grytsov 
> ---
>  tools/libxl/libxl_types.idl  | 38 
> +++-
>  tools/libxl/libxl_types_internal.idl |  1 +
>  2 files changed, 38 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 2204425..25563cf 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -755,7 +755,21 @@ libxl_device_vtpm = Struct("device_vtpm", [
>  ("backend_domname",  string),
>  ("devid",libxl_devid),
>  ("uuid", libxl_uuid),
> -])
> +])
> +
> +libxl_connector_param = Struct("connector_param", [
> +("id", string),
> +("width", uint32),
> +("height", uint32)
> +])
> +
> +libxl_device_vdispl = Struct("device_vdispl", [
> +("backend_domid", libxl_domid),
> +("backend_domname", string),
> +("devid", libxl_devid),
> +("be_alloc", bool),

After reading the doc -- use "allocator" for this field?

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

Re: [Xen-devel] [PATCH v3 11/11] docs: add PV display driver information

[Wei Liu]

On Tue, Jun 27, 2017 at 01:03:27PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 
> 
> Signed-off-by: Oleksandr Grytsov 
> ---
>  docs/man/xl.cfg.pod.5.in | 54 
> 
>  docs/man/xl.pod.1.in | 42 +
>  2 files changed, 96 insertions(+)
> 
> diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
> index 13167ff..f181f34 100644
> --- a/docs/man/xl.cfg.pod.5.in
> +++ b/docs/man/xl.cfg.pod.5.in
> @@ -1096,6 +1096,60 @@ FIFO-based event channel ABI support up to 131,071 
> event channels.
>  Other guests are limited to 4095 (64-bit x86 and ARM) or 1023 (32-bit
>  x86).
>  
> +=item B
> +
> +Specifies the virtual display devices to be provided to the guest.
> +
> +Each B is a comma-separated list of C
> +settings, from the following list:
> +
> +=over 4
> +
> +=item C
> +
> +Specifies the backend domain name or id. If not specified Domain-0 is used.
> +
> +=item C
> +

Can we avoid camel case?

> +Specified virtual display device ID. If not specified will be assigned
> +automatically.
> +
> +=item C
> +

Just "allocator"?

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

Re: [Xen-devel] [PATCH v3 04/11] libxl: add generic function to add device

[Wei Liu]

On Tue, Jun 27, 2017 at 01:03:20PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 
> 
> Add libxl__device_add functio.

function

> Almost all devices have similar libxl__device__add function.
> This generic function implements same functionality but
> using the device handling framework. The device specific
> part this is setting xen store configuration. This part
> is moved to set_xenstore_config callback of the device framework.
> 

Right. I think this is a good idea in general.

I don't see exiting device ported to the new framework, why?

We really don't want two sets of code that does the same thing in libxl.
That's a recipe for bugs.

> Signed-off-by: Oleksandr Grytsov 
[...]
>  /*
> diff --git a/tools/libxl/libxl_vdispl.c b/tools/libxl/libxl_vdispl.c
> index a628adc..c79bcda 100644
> --- a/tools/libxl/libxl_vdispl.c
> +++ b/tools/libxl/libxl_vdispl.c
> @@ -14,6 +14,21 @@
>  
>  #include "libxl_internal.h"
>  
> +static int libxl__device_vdispl_setdefault(libxl__gc *gc, uint32_t domid,
> +   libxl_device_vdispl *vdispl)
> +{
> +int rc;
> +
> +rc = libxl__resolve_domid(gc, vdispl->backend_domname,
> +  &vdispl->backend_domid);
> +
> +if (vdispl->devid == -1) {
> +vdispl->devid = libxl__device_nextid(gc, domid, "vdispl");
> +}
> +

No need to have {}.

> +return rc;
> +}
> +
>  static int libxl__device_from_vdispl(libxl__gc *gc, uint32_t domid,
>   libxl_device_vdispl *vdispl,
>   libxl__device *device)
> @@ -47,7 +62,7 @@ static void libxl__device_vdispl_add(libxl__egc *egc, 
> uint32_t domid,
>   libxl_device_vdispl *vdispl,
>   libxl__ao_device *aodev)
>  {
> -
> +libxl__device_add(egc, domid, &libxl__vdispl_devtype, vdispl, aodev);
>  }
>  
>  libxl_device_vdispl *libxl_device_vdispl_list(libxl_ctx *ctx, uint32_t domid,
> -- 
> 2.7.4
> 

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

Re: [Xen-devel] [PATCH v3 03/11] libxl: add generic function to get and free device list

[Wei Liu]

On Tue, Jun 27, 2017 at 01:03:19PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 
> 
> Add libxl__device_list, libxl__device_list_free.
> Device list is created from libxl xen store entries.
> In order to fill libxl device structure from xen store,
> the device handling framework extended with from_xenstore callback.
> On this callback libxl_device shall be filled with data from
> be xen store directory.
> 
> Signed-off-by: Oleksandr Grytsov 
> ---
>  tools/libxl/libxl_device.c   | 76 
> 
>  tools/libxl/libxl_internal.h |  8 +
>  tools/libxl/libxl_vdispl.c   | 17 --
>  3 files changed, 98 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index 00356af..8bcfa2b 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -1793,6 +1793,82 @@ out:
>  return AO_CREATE_FAIL(rc);
>  }
>  
> +void* libxl__device_list(const struct libxl_device_type *dt,
> + libxl_ctx *ctx, uint32_t domid, int *num)

void *libxl_...

> +{
> +GC_INIT(ctx);
> +
> +void *r = NULL;
> +void *list = NULL;
> +void *item = NULL;
> +char *libxl_path;
> +char *be_path;
> +char** dir = NULL;

char **dir

> +unsigned int ndirs = 0;
> +int rc;
> +
> +*num = 0;
> +
> +libxl_path = GCSPRINTF("%s/device/%s",
> +   libxl__xs_libxl_path(gc, domid), dt->type);
> +
> +dir = libxl__xs_directory(gc, XBT_NULL, libxl_path, &ndirs);
> +
> +if (dir && ndirs) {
> +list = malloc(dt->dev_elem_size * ndirs);
> +void *end = (uint8_t*)list + ndirs * dt->dev_elem_size;

(uint8_t *)

> +item = list;
> +
> +while(item < end) {
> +be_path = libxl__xs_read(gc, XBT_NULL,
> + GCSPRINTF("%s/%s/backend",
> + libxl_path, *dir));
> +
> +dt->init(item);
> +
> +if (dt->from_xenstore)
> +{

Move { to previous line.

> +rc = dt->from_xenstore(gc, be_path, atoi(*dir), item);
> +if (rc) goto out;
> +}
> +
> +item = (uint8_t*)item + dt->dev_elem_size;
> +++dir;
> +}
> +}
> +
> +*num = ndirs;
> +r = list;
> +list = NULL;
> +
> +out:
> +
> +if (list) {
> +*num = 0;
> +while(item >= list) {

Space after while.

> +item = (uint8_t*)item - dt->dev_elem_size;
> +dt->dispose(item);
> +}
> +free(list);
> +}
> +
> +GC_FREE;
> +
> +return r;
> +}
> +
> +void libxl__device_list_free(const struct libxl_device_type *dt,
> + void *list, int num)
> +{
> +int i;
> +
> +for (i = 0; i < num; i++) {
> +dt->dispose((uint8_t*)list + i * dt->dev_elem_size);
> +}
> +

No need to have {}.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
31

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 31

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 31
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 31
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 31
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  0fada059a7948153976cc152e36633dee3d5b273
baseline version:
 xen  c30bf55594a53fae8aae08aabf16fc192faad7da

Last test of basis   31  2017-06-28 03:19:29 Z1 days
Testing same since   62  2017-06-28 19:43:16 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Jackson 
  Julien Grall 
  Konrad Rzeszutek Wilk  [x86 and arm32]
  Stefano Stabellini 

jobs:
 build-amd64-xsm   

Re: [Xen-devel] [PATCH 2/2] xen/mm: Introduce {G, M}FN_INVALID_INITIALIZER

[Andrew Cooper]

On 29/06/17 17:30, Julien Grall wrote:
> Hi,
>
> On 06/27/2017 10:47 AM, Julien Grall wrote:
>>
>>
>> On 27/06/2017 10:46, Tim Deegan wrote:
>>> At 10:33 +0100 on 27 Jun (1498559600), Julien Grall wrote:
 The current implementation of {G,M}FN_INVALID cannot be used to
 initialize global variable because the initializer element is not a
 constant.

 Due to a bug in GCC 4.9 and older ([1]), it is not easy to find a
 common
 value to initialize a variable and directly passed as an argument.

 Introduce 2 news define {G,M}FN_INVALID_INITIALIZER to be used for
 initializing a variable.

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

 Signed-off-by: Julien Grall 
>>>
>>> Acked-by: Tim Deegan  (and Ack for the revert too)
>>> but please choose either { ~0UL } or {~0UL} and use it for both.
>>
>> Whoops. Sorry for that. I will stick to {~0UL} unless someone prefer
>> the { ~0UL }.
>
> Also, shall I resent a patch with this change? Or will it get taken
> care on commit? (assuming there are no other changes).

I'll sort it out on commit, when I do my next sweep (if someone doesn't
beat me to it).

~Andrew

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

Re: [Xen-devel] [PATCH 2/2] xen/mm: Introduce {G, M}FN_INVALID_INITIALIZER

[Julien Grall]

Hi,

On 06/27/2017 10:47 AM, Julien Grall wrote:



On 27/06/2017 10:46, Tim Deegan wrote:

At 10:33 +0100 on 27 Jun (1498559600), Julien Grall wrote:

The current implementation of {G,M}FN_INVALID cannot be used to
initialize global variable because the initializer element is not a
constant.

Due to a bug in GCC 4.9 and older ([1]), it is not easy to find a common
value to initialize a variable and directly passed as an argument.

Introduce 2 news define {G,M}FN_INVALID_INITIALIZER to be used for
initializing a variable.

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

Signed-off-by: Julien Grall 


Acked-by: Tim Deegan  (and Ack for the revert too)
but please choose either { ~0UL } or {~0UL} and use it for both.


Whoops. Sorry for that. I will stick to {~0UL} unless someone prefer the 
{ ~0UL }.


Also, shall I resent a patch with this change? Or will it get taken care 
on commit? (assuming there are no other changes).


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC] Live migration for VMs with QEMU backed local storage

[Wei Liu]

On Thu, Jun 29, 2017 at 03:34:37PM +0100, Roger Pau Monné wrote:
> On Thu, Jun 29, 2017 at 02:56:55PM +0100, Wei Liu wrote:
> > On Thu, Jun 29, 2017 at 09:33:07AM -0400, Bruno Alvisio wrote:
> > > Thanks Wei. Currently it is started after the memory is streamed from
> > > source to destination (for migration) and the booting functions are
> > > completed.I was going to ask to the list if there is a specific reason the
> > > QEMU process needs to be started at that point.
> > 
> > I _think_ it is because we don't want QEMU to touch guest memory / state
> > too early. Note I haven't checked the code. Do ask on the list if you
> > aren't sure.
> 
> I would have thought that's because you need the QEMU state, and
> that's not saved until the guest on the other end is paused (ie:
> rather at the end of the memory copy).
> 

This is also a plausible cause. This can also be worked around I think.
The principle is same -- start QEMU first and load state later. But then
this begs the question how you can handle the mirroring and state
transfer concurrently.

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

Re: [Xen-devel] [PATCH for-4.9 v2] livepatch: Declare live patching as a supported feature

[Jan Beulich]

>>> Julien Grall  06/29/17 4:31 PM >>>
>On 06/29/2017 07:47 AM, Jan Beulich wrote:
> Ross Lagerwall  06/28/17 6:14 PM >>>
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -226,7 +226,7 @@ config CRYPTO
>>  >bool
>>   >
>>   >config LIVEPATCH
>>> -   bool "Live patching support (TECH PREVIEW)"
>>> +   bool "Live patching support"
>>  >default n
>> 
>> I think the patch shouldn't be tagged for 4.9 anymore now that is has gone 
>> out,
>> and the default be changed as discussed. The backport to 4.9 then should 
>> discard
>> that default adjustment.
>
>Based on this patch, livepatch will be declared supported on x86. So it 
>sounds a bit odd to provide a default configuration for ARM that will 
>contain non-supported feature.

Perhaps a simple misunderstanding? By "as discussed" I meant "default X86",
not "default y".

Jan


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

Re: [Xen-devel] [PATCH v3] VT-d: fix VF of RC integrated PF matched to wrong VT-d unit

[Roger Pau Monné]

On Thu, Jun 29, 2017 at 11:21:53AM +0800, Chao Gao wrote:
> The problem is for a VF of RC integrated PF (e.g. PF's BDF is 00:02.0),
> we would wrongly use 00:00.0 to search VT-d unit.
> 
> From SRIOV spec REV 1.0 section 3.7.3, it says:
> "ARI is not applicable to Root Complex integrated Endpoints; all other
> SR-IOV Capable Devices (Devices that include at least one PF) shall
> implement the ARI Capability in each Function.". So PFs can be classified to
> two kinds: one is RC integrated PF and the other is non-RC integrated PF. The
> former can't support ARI and the latter shall support ARI. For Extended
> Functions, one traditional function's BDF should be used to search VT-d unit.
> And according to PCIe spec, Extened Function means within an ARI device, a
> Function whose Function Number is greater than 7. Thus, the former can't be an
> extended function, while the latter is as long as its devfn > 7, this check is
> exactly what the original code did; The original code wasn't aware the former.
> 
> This patch directly looks up the 'is_extfn' field of PF's struct pci_dev
> to decide whether the PF is a extended function.
> 
> Reported-by: Crawford, Eric R 
> Signed-off-by: Chao Gao 
> ---
>  xen/drivers/passthrough/vtd/dmar.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/dmar.c 
> b/xen/drivers/passthrough/vtd/dmar.c
> index 82040dd..27ff471 100644
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -218,8 +218,17 @@ struct acpi_drhd_unit *acpi_find_matched_drhd_unit(const 
> struct pci_dev *pdev)
>  }
>  else if ( pdev->info.is_virtfn )
>  {
> +struct pci_dev *physfn;
> +
>  bus = pdev->info.physfn.bus;
> -devfn = PCI_SLOT(pdev->info.physfn.devfn) ? 0 : 
> pdev->info.physfn.devfn;
> +/*
> + * Use 0 as 'devfn' to search VT-d unit when the physical function
> + * is an Extended Function.
> + */
> +pcidevs_lock();
> +physfn = pci_get_pdev(pdev->seg, bus, pdev->info.physfn.devfn);
> +pcidevs_unlock();
> +devfn = (physfn && physfn->info.is_extfn) ? 0 : 
> pdev->info.physfn.devfn;

AFAICT you should only release the pcidevs lock when you are done with
the device, so that a concurrent call to pci_remove_device doesn't
free the device while you are poking at it.

Roger.

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

Re: [Xen-devel] Containing unrecoverable AER errors...

[Venu Busireddy]

On 2017-06-20 12:56:34 +0100, Wei Liu wrote:
> On Wed, Jun 07, 2017 at 02:24:32PM -0500, Venu Busireddy wrote:
> > 
> > Hi,
> > 
> > I am working on creating a patch to aid in containing the unrecoverable
> > AER errors generated by PCI devices assigned to guests in passthrough
> > mode.
> > 
> > The overall approach is as follows:
> > 
> > 1. Change the BIOS settings such that the AER error handling is delegated
> >to the host.
> > 
> > 2. Change the xen_pciback driver to store the name (SBDF) of the erring
> >device in xenstore.
> > 
> > 3. At the time of creating the guest, setup a watcher for such writes to
> >the xenstore.
> > 
> > 4. When the watcher is kicked off due to errors, *shutdown* the guest and
> >mark the erring device unassignable until administrative intervention.
> > 
> > I got all of this working, but I was advised that shutting down the
> > guest is not the correct approach, because the guest may or may not
> > respond to the shutdown. The suggestion was to destroy the guest.
> > 
> > I ran into a problem with that. libxl_domain_destroy() is not
> > callable from within libxl. I tried to create a new wrapper to call
> > libxl__domain_destroy(), but the callback function never gets called!
> > Not surprisingly, because the description in libxl/libxl_internal.h
> > about asynchronous operations does prohibit this!
> > 
> > What is the best way to kill/destroy a guest from within libxl? Could you
> > please advise? I am including the patches below for reference (please
> > ignore the few debug statements). The problem part is the function
> > aer_backend_watch_callback() in tools/libxl/libxl_pci.c.
> > 
> [...]
> > +
> > +/* Handler of events for device driver domains */
> > +int libxl_reg_aer_events_handler(libxl_ctx *ctx, uint32_t domid)
> > +{
> > +int rc;
> > +char *be_path;
> > +GC_INIT(ctx);
> > +
> 
> You can probably create an AO here, stash it somewhere, and the use it
> in your callback to destroy the domain.
> 
> See also: libxl_device_events_handler

Thanks, Wei! This suggestion worked great. Implemented it, and I sent
the patches for review!

Venu


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

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

[Vikram Sethi]

Hi Julien, 
My thoughts are that while it is not essential to recover from AER and DPC 
initially, it is critical to at least take the slot offline and notify drivers 
so they quiesce.
Without this basic handling, it is possible to create backups in some hardware 
that result in CPU hangs for loads to adapter MMIO/cfg space and we don't want 
that.
i.e it is probably OK to lose the slot/adapter in initial implementation, but 
IMO it is NOT ok to crash/reboot the system by having watchdog kick in.
We do need to minimally describe what we will do with the AER and DPC 
interrupts: are they first handled by Xen and sent as "emulated" interrupt to 
owning domain?
Or are the interrupts ignored in initial implementation (not a good idea IMO)?

Hotplug also does not need to be solved right away. But we need to at least 
walk through the flows and convince ourselves we are not painting ourselves in 
a corner.
I will be in Budapest for Xen developer summit and we can walk through the ACPI 
hotplug flow and see how that *could* fit into proposed Xen design.

Thanks,
Vikram

-Original Message-
From: Julien Grall [mailto:julien.gr...@linaro.org] 
Sent: Wednesday, June 28, 2017 10:23 AM
To: Vikram Sethi ; Stefano Stabellini 

Cc: xen-devel ; edgar.igles...@xilinx.com; 
Steve Capper ; punit.agra...@arm.com; Wei Chen 
; Dave P Martin ; Sameer Goel 
; Sinan Kaya ; 
roger@citrix.com; manish.ja...@caviumnetworks.com; Vijaya Kumar K 
; Andre Przywara 
Subject: Re: [RFC] ARM PCI Passthrough design document



On 20/06/17 01:19, Vikram Sethi wrote:
> Hi Julien,

Hi Vikram,

Thank you for your feedbacks.

> Thanks for posting this. I think some additional topics need to be covered in 
> the design document, under 3 main topics:

I wanted to limit the scope of the PCI passthrough work to the strict minimum. 
I didn't consider hotplug and AER in the scope because it is optional feature.

>
> Hotplug: how will Xen support hotplug? Many rootports may require firmware 
> hooks such as ACPI ASL to take care of platform specific MMIO initialization 
> on hotplug. Normally firmware (UEFI) would have done that platform specific 
> setup at boot.

We don't have ASL support in Xen. So I would expect the hotplug to be 
handled by the hardware domain and then report it to Xen.

This would also fit quite well to the current design as the hardware 
domain will scan PCI devices at boot and then register them to Xen via 
an hypercall.

>
> AER: Will PCIe non-fatal and fatal errors (secondary bus reset for fatal) be 
> recoverable in Xen?
> Will drivers in doms be notified about fatal errors so they can be quiesced 
> before doing secondary bus reset in Xen?
> Will Xen support Firmware First Error handling for AER? i.e When platform 
> does Firmware first error handling for AER and/or filtering of AER, sends 
> associated ACPI HEST logs to Xen
> How will AER notification and logs be propagated to the doms: injected ACPI 
> HEST?
>
> PCIe DPC (Downstream Port Containment): will it be supported in Xen, and Xen 
> will register for DPC interrupt? When Xen brings the link back up will it 
> send a simulated hotplug to dom0 to show link back up?

I don't feel it is necessary to look at AER for the first work of PCI 
passthrough. I consider it as a separate feature that could probably 
come with the RAS story.

At the moment, I don't know who is going to handle the error and even 
how they will be reported to the guest. But I don't think this will have 
any impact on our design choice here.

Let me know if you think it may have an impact.

Cheers,

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

[Xen-devel] [ovmf baseline-only test] 71615: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 71613

Regressions which are regarded as allowable (not blocking):
 build-i386-libvirt5 libvirt-buildfail   like 71613
 build-amd64-libvirt   5 libvirt-buildfail   like 71613

version targeted for testing:
 ovmf 8cf19dc7a5305007bd33934838c67a7b1640f633
baseline version:
 ovmf 1fb805b1eb5b6039cb12375f8594aba65bf60a44

Last test of basis71613  2017-06-29 03:17:33 Z0 days
Testing same since71615  2017-06-29 13:16:42 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 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 8cf19dc7a5305007bd33934838c67a7b1640f633
Author: Dandan Bi 
Date:   Wed Jun 28 10:33:32 2017 +0800

UefiCpuPkg: Fix coding style issues

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

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

Re: [Xen-devel] [PATCH RFC] Live migration for VMs with QEMU backed local storage

[Roger Pau Monné]

On Thu, Jun 29, 2017 at 02:56:55PM +0100, Wei Liu wrote:
> On Thu, Jun 29, 2017 at 09:33:07AM -0400, Bruno Alvisio wrote:
> > Thanks Wei. Currently it is started after the memory is streamed from
> > source to destination (for migration) and the booting functions are
> > completed.I was going to ask to the list if there is a specific reason the
> > QEMU process needs to be started at that point.
> 
> I _think_ it is because we don't want QEMU to touch guest memory / state
> too early. Note I haven't checked the code. Do ask on the list if you
> aren't sure.

I would have thought that's because you need the QEMU state, and
that's not saved until the guest on the other end is paused (ie:
rather at the end of the memory copy).

Roger

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

Re: [Xen-devel] [PATCH for-4.9 v2] livepatch: Declare live patching as a supported feature

[Julien Grall]

Hi,

On 06/29/2017 07:47 AM, Jan Beulich wrote:

Ross Lagerwall  06/28/17 6:14 PM >>>

--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -226,7 +226,7 @@ config CRYPTO

>bool
  >
  >config LIVEPATCH

-   bool "Live patching support (TECH PREVIEW)"
+   bool "Live patching support"

>default n

I think the patch shouldn't be tagged for 4.9 anymore now that is has gone out,
and the default be changed as discussed. The backport to 4.9 then should discard
that default adjustment.


Based on this patch, livepatch will be declared supported on x86. So it 
sounds a bit odd to provide a default configuration for ARM that will 
contain non-supported feature.


Any opinions?

Cheers,

--
Julien Grall

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

[Xen-devel] [xtf test] 111180: regressions - trouble: broken/pass

[osstest service owner]

flight 80 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/80/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-1   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-4   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-3   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-2   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-5   59 leak-check/check fail REGR. vs. 111074

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-1   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-4   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-3   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-2   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-5   58 xtf/test-hvm64-xsa-221   fail   never pass

version targeted for testing:
 xtf  e8e2cf8f9b2862cef7111a66c52aa2f83a3c541d
baseline version:
 xtf  6723a66fe3e2a60793ec4fdbcd67250c954fe5d9

Last test of basis   111074  2017-06-26 14:44:07 Z2 days
Failing since44  2017-06-28 10:53:08 Z1 days3 attempts
Testing same since   67  2017-06-28 22:15:34 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Haozhong Zhang 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   broken  
 test-xtf-amd64-amd64-2   broken  
 test-xtf-amd64-amd64-3   broken  
 test-xtf-amd64-amd64-4   broken  
 test-xtf-amd64-amd64-5   broken  



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

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

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

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


Not pushing.


commit e8e2cf8f9b2862cef7111a66c52aa2f83a3c541d
Author: Andrew Cooper 
Date:   Thu Jun 1 12:13:22 2017 +0100

Don't automatically recover from traps

While this property is useful for swint-emulation, it is unhelpful in other
situations, as it causes unexpected traps to get swallowed silently.

Reuse the existing extable logic (with fault == fixup) to recover, and
introduce _ASM_TRAP_OK() to introduce such an extable entry.

Adjust the swint-emulation and selftest logic following this behaviour 
change,
which removes the test_int3_breakpoint() case entirely.

Signed-off-by: Andrew Cooper 

commit 246fb45b1e8edb036e20c8703687f779b13ae679
Author: Andrew Cooper 
Date:   Wed Jun 28 14:51:06 2017 +

Clean up extable.h

Factor _ASM_EXTABLE() out of the C/ASM logic, and implement it in terms of
_ASM_EXTABLE_HANDLER().

No functional change.

Signed-off-by: Andrew Cooper 

commit ac6151c03b14df45c2852bf52f6905e407ecd901
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:34 2016 +0800

vvmx: test whether MSR_FEATURE_CONTROL is set correctly

Guest MSR_FEATURE_CONTROL is set by Xen hypervisor instead by
guest firmware or hvmloader, so this test instead checks whether bits
in MSR_FEATURE_CONTROL are set correctly, rather than requiring
they are all zeroed.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit b8021169a0a8611d9552b6b24e3250769e5064eb
Author: Andrew Cooper 
Date:   Wed Jun 28 13:17:41 2017 +0100

Bare-bones in-development test for nested VT-x

Based loosely on previous work from Haozhong Zhang, but rebased over
substantial upstream development work, altered to be more consistent with
existing tests, and extended to all HVM environments (rather than just 
hvm64)
to cover more test scenarios.

Signed-off-by: Andrew Cooper 

commit 4aedda03ca7e1e237cf9b3de8473303aadb8d112
Author: Andrew Cooper 
Date:   Wed Jun 28 11:24:55 2017 +0100

Test basic driver initialisation in the selftests

Signed-off-by: Andrew Cooper 

commit 1f8291174e0d5b0f6c9ecb2a588d2ba261c96a58
Author: 

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

[osstest service owner]

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

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
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  989563f97b3b255152c85c12b180a128e7c9202e
baseline version:
 xen  2d7021cfd7b962cc4af71e6f7b79716680da39f2

Last test of basis   59  2017-06-28 19:01:53 Z0 days
Testing same since   87  2017-06-29 12:03:55 Z0 days1 attempts


People who touched revisions under test:
  Marek Marczykowski-Górecki 
  Wei Liu 
  Zhongze Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 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=989563f97b3b255152c85c12b180a128e7c9202e
+ . ./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 
989563f97b3b255152c85c12b180a128e7c9202e
+ branch=xen-unstable-smoke
+ revision=989563f97b3b255152c85c12b180a128e7c9202e
+ . ./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.9-testing
+ '[' x989563f97b3b255152c85c12b180a128e7c9202e = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/o

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-examine  4 host-install   broken REGR. vs. 110441
 build-armhf-pvops5 host-build-prep fail in 34 REGR. vs. 110441
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 34 
REGR. vs. 110441
 test-amd64-amd64-xl-rtds  3 syslog-serverrunning

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail in 34 
pass in 55
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail pass in 
34

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

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

Re: [Xen-devel] [PATCH RFC] Live migration for VMs with QEMU backed local storage

[Wei Liu]

On Thu, Jun 29, 2017 at 09:33:07AM -0400, Bruno Alvisio wrote:
> Thanks Wei. Currently it is started after the memory is streamed from
> source to destination (for migration) and the booting functions are
> completed.I was going to ask to the list if there is a specific reason the
> QEMU process needs to be started at that point.

I _think_ it is because we don't want QEMU to touch guest memory / state
too early. Note I haven't checked the code. Do ask on the list if you
aren't sure.

> 
> Also, if the start point of the QEMU process is moved to an earlier part of
> the domain creation process, how can I run a basic set of tests to validate
> that I am not breaking any functionality and causing a regression?
> 

Doing some local migration tests as a starter.

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

Re: [Xen-devel] [PATCH RFC] Live migration for VMs with QEMU backed local storage

[Bruno Alvisio]

Thanks Wei. Currently it is started after the memory is streamed from
source to destination (for migration) and the booting functions are
completed.I was going to ask to the list if there is a specific reason the
QEMU process needs to be started at that point.

Also, if the start point of the QEMU process is moved to an earlier part of
the domain creation process, how can I run a basic set of tests to validate
that I am not breaking any functionality and causing a regression?

Thanks,

Bruno

On Thu, Jun 29, 2017 at 7:58 AM, Wei Liu  wrote:

> On Fri, Jun 23, 2017 at 03:42:20AM -0400, Bruno Alvisio wrote:
> > This patch is the first attempt on adding live migration of instances
> with local
> > storage to Xen. This patch just handles very restricted case of fully
> > virtualized HVMs. The code uses the "drive-mirror" capability provided
> by QEMU.
> > A new "-l" option is introduced to "xl migrate" command. If provided,
> the local
> > disk should be mirrored during the migration process. If the option is
> set,
> > during the VM creation a qemu NBD server is started on the destination.
> After
> > the instance is suspended on the source, the QMP "disk-mirror" command
> is issued
> > to mirror the disk to destination. Once the mirroring job is complete,
> the
> > migration process continues as before. Finally, the NBD server is
> stopped after
> > the instance is successfully resumed on the destination node.
> >
> > A major problem with this patch is that the mirroring of the disk is
> performed
> > only after the memory stream is completed and the VM is suspended on the
> source;
> > thus the instance is frozen for a long period of time. The reason this
> happens
> > is that the QEMU process (needed for the disk mirroring) is started on
> the
> > destination node only after the memory copying is completed. One
> possibility I
> > was considering to solve this issue (if it is decided that this
> capability
> > should be used): Could a "helper" QEMU process be started on the
> destination
> > node at the beginning of the migration sequence with the sole purpose of
> > handling the disk mirroring and kill it at the end of the migration
> sequence?
> >
>
> In theory we could, but I am very cautious about this. I _think_ we can
> change the timing QEMU is started. It can be started earlier, but take
> precaution that it shouldn't resume the guest.
>
> In any case, start with the simple setup first.
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] q35 support in Xen

[Chao Peng]

> Anthony Perard did a great job providing patches which add a partial
> Q35
> support. I tried extending his patches to include missing features for
> Q35 in
> hvmloader, libacpi and QEMU and so far the Xen+Q35 experience is quite
> positive

Hi Alexey, 

I saw Anthony's patch, but your extension patch seems still in
development. Do you have plan to upstream it? I'm also interested in
this basically I want full PCI-e passthru capability (Current Xen does
support passthru a PCI-e device but guest can't see configuration offset
256-4095 for example). I'm glad to collaborate on this.

Thanks,
Chao


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

Re: [Xen-devel] [xtf test] 111167: regressions - trouble: broken/pass

[Andrew Cooper]

On 29/06/17 09:54, osstest service owner wrote:
> flight 67 xtf real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/67/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-xtf-amd64-amd64-1   59 leak-check/check fail REGR. vs. 
> 111074
>  test-xtf-amd64-amd64-4   59 leak-check/check fail REGR. vs. 
> 111074
>  test-xtf-amd64-amd64-3   59 leak-check/check fail REGR. vs. 
> 111074
>  test-xtf-amd64-amd64-2   59 leak-check/check fail REGR. vs. 
> 111074
>  test-xtf-amd64-amd64-5   59 leak-check/check fail REGR. vs. 
> 111074
>
> Tests which did not succeed, but are not blocking:
>  test-xtf-amd64-amd64-1   58 xtf/test-hvm64-xsa-221   fail   never 
> pass
>  test-xtf-amd64-amd64-4   58 xtf/test-hvm64-xsa-221   fail   never 
> pass
>  test-xtf-amd64-amd64-3   58 xtf/test-hvm64-xsa-221   fail   never 
> pass
>  test-xtf-amd64-amd64-2   58 xtf/test-hvm64-xsa-221   fail   never 
> pass
>  test-xtf-amd64-amd64-5   58 xtf/test-hvm64-xsa-221   fail   never 
> pass

FYI, this is because the fix for XSA-221 hasn't yet passed the master
push gate.

The problem will resolve itself when master moves forwards.

~Andrew

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

[Xen-devel] livepatch-tools: Handle new files in patch sets

[Bitweasil .]

Reference: https://xenproject.atlassian.net/browse/XEN-90

If you create a Xen patch for livepatch that adds additional files to the
build (adds the files and patches the Makefile to include them), the
livepatch tools (from https://github.com/rosslagerwall/livepatch-build-tools)
do not properly handle this.  They ignore the new files in the patched/
output directory, as the script only lists object files from the original/
directory.

After some investigation and experimenting, it seems the easiest way to
resolve this issue is to list the object files in the patched/ directory
(instead of the original/ directory), and if the source object file does
not exist in the original/ directory, create an object file of the proper
name from an empty .c file.  The create-diff-object step works properly
against this.  Note that this method does not handle the removal of object
files via the patching process.

I've created a simple patch to livepatch-build that adds this capability.
Directly calling gcc may not be the correct approach in all situations (the
patch tools require the compiler version to match between object files),
but it works for my environment (a XenServer build system using the system
gcc).

Please let me know if you have any other questions about this particular
issue.  I am happy to provide additional information if needed.

-Bit

=

+++ livepatch-build2017-06-28 15:20:31.797362000 -0600
@@ -117,7 +117,7 @@
 [[ -e "${OUTPUT}/original/changed_objs" ]] || die "no changed objects
found"
 [[ -e "${OUTPUT}/patched/changed_objs" ]] || die "no changed objects
found"

-cd "${OUTPUT}/original" || die
+cd "${OUTPUT}/patched" || die
 FILES="$(find xen -type f -name "*.o")"
 cd "${OUTPUT}" || die
 CHANGED=0
@@ -129,6 +129,15 @@
 mkdir -p "output/$(dirname $i)" || die
 echo "Processing ${i}"
 echo "Run create-diff-object on $i" >>
"${OUTPUT}/create-diff-object.log"
+# Create an empty object file if none exists.
+if [[ ! -e "original/$i" ]]; then
+echo "Creating object file original/$i with no content."
+TEMPPATH="$(mktemp -d /tmp/xenbuild.XX)"
+touch "${TEMPPATH}/empty.c"
+gcc -g -m64 -ffunction-sections -fdata-sections -c
"${TEMPPATH}/empty.c" -o "original/$i"
+rm "${TEMPPATH}/empty.c"
+rmdir "${TEMPPATH}"
+fi
 "${TOOLSDIR}"/create-diff-object $debugopt $PRELINK "original/$i"
"patched/$i" "$XENSYMS" "output/$i" &>> "${OUTPUT}/create-diff-object.log"
 rc="${PIPESTATUS[0]}"
 if [[ $rc = 139 ]]; then
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 08/11] x86/vmce, tools/libxl: expose LMCE capability in guest MSR_IA32_MCG_CAP

[Wei Liu]

On Mon, Jun 26, 2017 at 05:16:22PM +0800, Haozhong Zhang wrote:
> If LMCE is supported by host and ' mca_caps = [ "lmce" ] ' is present
> in xl config, the LMCE capability will be exposed in guest MSR_IA32_MCG_CAP.
> By default, LMCE is not exposed to guest so as to keep the backwards migration
> compatibility.
> 
> Signed-off-by: Haozhong Zhang 
> Reviewed-by: Jan Beulich  for hypervisor side

I suppose you already trid a local migration:

Acked-by: Wei Liu 

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

[Xen-devel] [PATCH 5/5] tools: tracing: handle null scheduler's events

[Dario Faggioli]

In both xentrace and xenalyze.

Signed-off-by: Dario Faggioli 
---
George Dunlap 
---
 tools/xentrace/formats|7 +
 tools/xentrace/xenalyze.c |   65 +
 2 files changed, 72 insertions(+)

diff --git a/tools/xentrace/formats b/tools/xentrace/formats
index 8b31780..c1f584f 100644
--- a/tools/xentrace/formats
+++ b/tools/xentrace/formats
@@ -79,6 +79,13 @@
 0x00022805  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:sched_tasklet
 0x00022806  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:schedule  [ 
cpu[16]:tasklet[8]:idle[4]:tickled[4] = %(1)08x ]
 
+0x00022A01  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  null:pick_cpu  [ dom:vcpu 
= 0x%(1)08x, new_cpu = %(2)d ]
+0x00022A02  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  null:assign[ dom:vcpu 
= 0x%(1)08x, cpu = %(2)d ]
+0x00022A03  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  null:deassign  [ dom:vcpu 
= 0x%(1)08x, cpu = %(2)d ]
+0x00022A04  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  null:migrate   [ dom:vcpu 
= 0x%(1)08x, new_cpu:cpu = 0x%(2)08x ]
+0x00022A05  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  null:schedule  [ 
cpu[16]:tasklet[16] = %(1)08x, dom:vcpu = 0x%(2)08x ]
+0x00022A06  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  null:sched_tasklet
+
 0x00041001  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  domain_create   [ dom = 
0x%(1)08x ]
 0x00041002  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  domain_destroy  [ dom = 
0x%(1)08x ]
 
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index fa608ad..24cce2a 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -7968,6 +7968,71 @@ void sched_process(struct pcpu_info *p)
r->tickled ? ", tickled" : ", not tickled");
 }
 break;
+case TRC_SCHED_CLASS_EVT(SNULL, 1): /* PICKED_CPU */
+if (opt.dump_all) {
+struct {
+uint16_t vcpuid, domid;
+uint32_t new_cpu;
+} *r = (typeof(r))ri->d;
+
+printf(" %s null:picked_cpu d%uv%u, cpu %u\n",
+   ri->dump_header, r->domid, r->vcpuid, r->new_cpu);
+}
+break;
+case TRC_SCHED_CLASS_EVT(SNULL, 2): /* VCPU_ASSIGN */
+if (opt.dump_all) {
+struct {
+uint16_t vcpuid, domid;
+uint32_t cpu;
+} *r = (typeof(r))ri->d;
+
+printf(" %s null:vcpu_assign d%uv%u to cpu %u\n",
+   ri->dump_header, r->domid, r->vcpuid, r->cpu);
+}
+break;
+case TRC_SCHED_CLASS_EVT(SNULL, 3): /* VCPU_DEASSIGN */
+if (opt.dump_all) {
+struct {
+uint16_t vcpuid, domid;
+uint32_t cpu;
+} *r = (typeof(r))ri->d;
+
+printf(" %s null:vcpu_deassign d%uv%u from cpu %u\n",
+   ri->dump_header, r->domid, r->vcpuid, r->cpu);
+}
+break;
+case TRC_SCHED_CLASS_EVT(SNULL, 4): /* MIGRATE */
+if (opt.dump_all) {
+struct {
+uint16_t vcpuid, domid;
+uint16_t cpu, new_cpu;
+} *r = (typeof(r))ri->d;
+
+printf(" %s null:migrate d%uv%u, cpu %u, new_cpu %u\n",
+   ri->dump_header, r->domid, r->vcpuid,
+   r->cpu, r->new_cpu);
+}
+break;
+case TRC_SCHED_CLASS_EVT(SNULL, 5): /* SCHEDULE */
+if (opt.dump_all) {
+struct {
+uint16_t tasklet, cpu;
+int16_t vcpuid, domid;
+} *r = (typeof(r))ri->d;
+
+printf(" %s null:schedule cpu %u%s",
+   ri->dump_header, r->cpu,
+   r->tasklet ? ", tasklet scheduled" : "");
+if (r->vcpuid != -1)
+printf(", vcpu d%uv%d\n", r->domid, r->vcpuid);
+else
+printf(", no vcpu\n");
+}
+break;
+case TRC_SCHED_CLASS_EVT(SNULL, 6): /* TASKLET */
+if (opt.dump_all)
+printf(" %s null:sched_tasklet\n", ri->dump_header);
+break;
 default:
 process_generic(ri);
 }


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

[Xen-devel] [PATCH 4/5] xen: sched_null: add some tracing

[Dario Faggioli]

In line with what is there in all the other schedulers.

Signed-off-by: Dario Faggioli 
---
George Dunlap 
---
 xen/common/sched_null.c|   94 +++-
 xen/include/public/trace.h |1 
 2 files changed, 92 insertions(+), 3 deletions(-)

diff --git a/xen/common/sched_null.c b/xen/common/sched_null.c
index 19c7f0f..b4a24ba 100644
--- a/xen/common/sched_null.c
+++ b/xen/common/sched_null.c
@@ -32,7 +32,17 @@
 #include 
 #include 
 #include 
+#include 
 
+/*
+ * null tracing events. Check include/public/trace.h for more details.
+ */
+#define TRC_SNULL_PICKED_CPUTRC_SCHED_CLASS_EVT(SNULL, 1)
+#define TRC_SNULL_VCPU_ASSIGN   TRC_SCHED_CLASS_EVT(SNULL, 2)
+#define TRC_SNULL_VCPU_DEASSIGN TRC_SCHED_CLASS_EVT(SNULL, 3)
+#define TRC_SNULL_MIGRATE   TRC_SCHED_CLASS_EVT(SNULL, 4)
+#define TRC_SNULL_SCHEDULE  TRC_SCHED_CLASS_EVT(SNULL, 5)
+#define TRC_SNULL_TASKLET   TRC_SCHED_CLASS_EVT(SNULL, 6)
 
 /*
  * Locking:
@@ -305,7 +315,10 @@ static unsigned int pick_cpu(struct null_private *prv, 
struct vcpu *v)
  */
 if ( likely((per_cpu(npc, cpu).vcpu == NULL || per_cpu(npc, cpu).vcpu 
== v)
 && cpumask_test_cpu(cpu, cpumask_scratch_cpu(cpu))) )
-return cpu;
+{
+new_cpu = cpu;
+goto out;
+}
 
 /* If not, just go for a free pCPU, within our affinity, if any */
 cpumask_and(cpumask_scratch_cpu(cpu), cpumask_scratch_cpu(cpu),
@@ -313,7 +326,7 @@ static unsigned int pick_cpu(struct null_private *prv, 
struct vcpu *v)
 new_cpu = cpumask_first(cpumask_scratch_cpu(cpu));
 
 if ( likely(new_cpu != nr_cpu_ids) )
-return new_cpu;
+goto out;
 }
 
 /*
@@ -328,7 +341,22 @@ static unsigned int pick_cpu(struct null_private *prv, 
struct vcpu *v)
  * only if the pCPU is free.
  */
 cpumask_and(cpumask_scratch_cpu(cpu), cpus, v->cpu_hard_affinity);
-return cpumask_any(cpumask_scratch_cpu(cpu));
+new_cpu = cpumask_any(cpumask_scratch_cpu(cpu));
+
+ out:
+if ( unlikely(tb_init_done) )
+{
+struct {
+uint16_t vcpu, dom;
+uint32_t new_cpu;
+} d;
+d.dom = v->domain->domain_id;
+d.vcpu = v->vcpu_id;
+d.new_cpu = new_cpu;
+__trace_var(TRC_SNULL_PICKED_CPU, 1, sizeof(d), &d);
+}
+
+return new_cpu;
 }
 
 static void vcpu_assign(struct null_private *prv, struct vcpu *v,
@@ -339,6 +367,18 @@ static void vcpu_assign(struct null_private *prv, struct 
vcpu *v,
 cpumask_clear_cpu(cpu, &prv->cpus_free);
 
 dprintk(XENLOG_G_INFO, "%d <-- d%dv%d\n", cpu, v->domain->domain_id, 
v->vcpu_id);
+
+if ( unlikely(tb_init_done) )
+{
+struct {
+uint16_t vcpu, dom;
+uint32_t cpu;
+} d;
+d.dom = v->domain->domain_id;
+d.vcpu = v->vcpu_id;
+d.cpu = cpu;
+__trace_var(TRC_SNULL_VCPU_ASSIGN, 1, sizeof(d), &d);
+}
 }
 
 static void vcpu_deassign(struct null_private *prv, struct vcpu *v,
@@ -348,6 +388,18 @@ static void vcpu_deassign(struct null_private *prv, struct 
vcpu *v,
 cpumask_set_cpu(cpu, &prv->cpus_free);
 
 dprintk(XENLOG_G_INFO, "%d <-- NULL (d%dv%d)\n", cpu, 
v->domain->domain_id, v->vcpu_id);
+
+if ( unlikely(tb_init_done) )
+{
+struct {
+uint16_t vcpu, dom;
+uint32_t cpu;
+} d;
+d.dom = v->domain->domain_id;
+d.vcpu = v->vcpu_id;
+d.cpu = cpu;
+__trace_var(TRC_SNULL_VCPU_DEASSIGN, 1, sizeof(d), &d);
+}
 }
 
 /* Change the scheduler of cpu to us (null). */
@@ -562,6 +614,19 @@ static void null_vcpu_migrate(const struct scheduler *ops, 
struct vcpu *v,
 if ( v->processor == new_cpu )
 return;
 
+if ( unlikely(tb_init_done) )
+{
+struct {
+uint16_t vcpu, dom;
+uint16_t cpu, new_cpu;
+} d;
+d.dom = v->domain->domain_id;
+d.vcpu = v->vcpu_id;
+d.cpu = v->processor;
+d.new_cpu = new_cpu;
+__trace_var(TRC_SNULL_MIGRATE, 1, sizeof(d), &d);
+}
+
 /*
  * v is either assigned to a pCPU, or in the waitqueue.
  *
@@ -663,8 +728,31 @@ static struct task_slice null_schedule(const struct 
scheduler *ops,
 SCHED_STAT_CRANK(schedule);
 NULL_VCPU_CHECK(current);
 
+if ( unlikely(tb_init_done) )
+{
+struct {
+uint16_t tasklet, cpu;
+int16_t vcpu, dom;
+} d;
+d.cpu = cpu;
+d.tasklet = tasklet_work_scheduled;
+if ( per_cpu(npc, cpu).vcpu == NULL )
+{
+d.vcpu = d.dom = -1;
+}
+else
+{
+d.vcpu = per_cpu(npc, cpu).vcpu->vcpu_id;
+d.dom = per_cpu(npc, cpu).vcpu->domain->domain_id;
+}
+__trace_var(TRC_SNULL_SCHEDULE, 1, sizeof(d), &d);
+}
+
 if ( tasklet_work_scheduled )
+{
+trace_var(TRC_SNULL_TASK

[Xen-devel] [PATCH 2/5] xen: sched_null: check for pending tasklet work a bit earlier

[Dario Faggioli]

Whether or not there's pending tasklet work to do, it's
something we know from the tasklet_work_scheduled parameter.

Deal with that as soon as possible, like all other schedulers
do.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
---
 xen/common/sched_null.c |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/xen/common/sched_null.c b/xen/common/sched_null.c
index 705c00a..610a150 100644
--- a/xen/common/sched_null.c
+++ b/xen/common/sched_null.c
@@ -641,7 +641,10 @@ static struct task_slice null_schedule(const struct 
scheduler *ops,
 SCHED_STAT_CRANK(schedule);
 NULL_VCPU_CHECK(current);
 
-ret.task = per_cpu(npc, cpu).vcpu;
+if ( tasklet_work_scheduled )
+ret.task = idle_vcpu[cpu];
+else
+ret.task = per_cpu(npc, cpu).vcpu;
 ret.migrated = 0;
 ret.time = -1;
 
@@ -663,9 +666,7 @@ static struct task_slice null_schedule(const struct 
scheduler *ops,
 spin_unlock(&prv->waitq_lock);
 }
 
-if ( unlikely(tasklet_work_scheduled ||
-  ret.task == NULL ||
-  !vcpu_runnable(ret.task)) )
+if ( unlikely(ret.task == NULL || !vcpu_runnable(ret.task)) )
 ret.task = idle_vcpu[cpu];
 
 NULL_VCPU_CHECK(ret.task);


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

[Xen-devel] [PATCH 3/5] xen: sched-null: support soft-affinity

[Dario Faggioli]

The null scheduler does not really use hard-affinity for
scheduling, it uses it for 'placement', i.e., for deciding
to what pCPU to statically assign a vCPU.

Let's use soft-affinity in the same way, of course with the
difference that, if there's no free pCPU within the vCPU's
soft-affinity, we go checking the hard-affinity, instead of
putting the vCPU in the waitqueue.

This does has no impact on the scheduling overhead, because
soft-affinity is only considered in cold-path (like when a
vCPU joins the scheduler for the first time, or is manually
moved between pCPUs by the user).

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
---
 xen/common/sched_null.c |  110 +--
 1 file changed, 77 insertions(+), 33 deletions(-)

diff --git a/xen/common/sched_null.c b/xen/common/sched_null.c
index 610a150..19c7f0f 100644
--- a/xen/common/sched_null.c
+++ b/xen/common/sched_null.c
@@ -115,9 +115,11 @@ 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)
+static inline bool vcpu_check_affinity(struct vcpu *v, unsigned int cpu,
+   unsigned int balance_step)
 {
-cpumask_and(cpumask_scratch_cpu(cpu), v->cpu_hard_affinity,
+affinity_balance_cpumask(v, balance_step, cpumask_scratch_cpu(cpu));
+cpumask_and(cpumask_scratch_cpu(cpu), cpumask_scratch_cpu(cpu),
 cpupool_domain_cpumask(v->domain));
 
 return cpumask_test_cpu(cpu, cpumask_scratch_cpu(cpu));
@@ -279,31 +281,40 @@ static void null_dom_destroy(const struct scheduler *ops, 
struct domain *d)
  */
 static unsigned int pick_cpu(struct null_private *prv, struct vcpu *v)
 {
+unsigned int bs;
 unsigned int cpu = v->processor, new_cpu;
 cpumask_t *cpus = cpupool_domain_cpumask(v->domain);
 
 ASSERT(spin_is_locked(per_cpu(schedule_data, cpu).schedule_lock));
 
-cpumask_and(cpumask_scratch_cpu(cpu), v->cpu_hard_affinity, cpus);
+for_each_affinity_balance_step( bs )
+{
+if ( bs == BALANCE_SOFT_AFFINITY &&
+ !has_soft_affinity(v, v->cpu_hard_affinity) )
+continue;
 
-/*
- * 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, cpumask_scratch_cpu(cpu))) )
-return cpu;
+affinity_balance_cpumask(v, bs, cpumask_scratch_cpu(cpu));
+cpumask_and(cpumask_scratch_cpu(cpu), cpumask_scratch_cpu(cpu), cpus);
 
-/* If not, just go for a free pCPU, within our affinity, if any */
-cpumask_and(cpumask_scratch_cpu(cpu), cpumask_scratch_cpu(cpu),
-&prv->cpus_free);
-new_cpu = cpumask_first(cpumask_scratch_cpu(cpu));
+/*
+ * 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, cpumask_scratch_cpu(cpu))) )
+return cpu;
 
-if ( likely(new_cpu != nr_cpu_ids) )
-return new_cpu;
+/* If not, just go for a free pCPU, within our affinity, if any */
+cpumask_and(cpumask_scratch_cpu(cpu), cpumask_scratch_cpu(cpu),
+&prv->cpus_free);
+new_cpu = cpumask_first(cpumask_scratch_cpu(cpu));
+
+if ( likely(new_cpu != nr_cpu_ids) )
+return new_cpu;
+}
 
 /*
  * If we didn't find any free pCPU, just pick any valid pcpu, even if
@@ -430,6 +441,7 @@ 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 bs;
 unsigned int cpu = v->processor;
 struct null_vcpu *wvc;
 
@@ -441,19 +453,27 @@ static void _vcpu_remove(struct null_private *prv, struct 
vcpu *v)
 
 /*
  * If v is assigned to a pCPU, let's see if there is someone waiting,
- * suitable to be assigned to it.
+ * suitable to be assigned to it (prioritizing vcpus that have
+ * soft-affinity with cpu).
  */
-list_for_each_entry( wvc, &prv->waitq, waitq_elem )
+for_each_affinity_balance_step( bs )
 {
-if ( vcpu_check_affinity(wvc->vcpu, cpu) )
+list_for_each_entry( wvc, &prv->waitq, waitq_elem )
 {
-list_del_init(&wvc->waitq_elem);
-vcpu_

[Xen-devel] [PATCH 1/5] xen: sched: factor affinity helpers out of sched_credit.c

[Dario Faggioli]

In fact, we want to be able to use them from any scheduler.

While there, make the moved code use 'v' for struct_vcpu*
variable, like it should be done everywhere.

No functional change intended.

Signed-off-by: Dario Faggioli 
Signed-off-by: Justin T. Weaver 
Reviewed-by: George Dunlap 
---
Cc: Anshul Makkar 
---
 xen/common/sched_credit.c  |   97 +++-
 xen/include/xen/sched-if.h |   64 +
 2 files changed, 79 insertions(+), 82 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index efdf6bf..53773df 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -136,27 +136,6 @@
 #define TRC_CSCHED_RATELIMIT TRC_SCHED_CLASS_EVT(CSCHED, 10)
 #define TRC_CSCHED_STEAL_CHECK   TRC_SCHED_CLASS_EVT(CSCHED, 11)
 
-
-/*
- * Hard and soft affinity load balancing.
- *
- * Idea is each vcpu has some pcpus that it prefers, some that it does not
- * prefer but is OK with, and some that it cannot run on at all. The first
- * set of pcpus are the ones that are both in the soft affinity *and* in the
- * hard affinity; the second set of pcpus are the ones that are in the hard
- * affinity but *not* in the soft affinity; the third set of pcpus are the
- * ones that are not in the hard affinity.
- *
- * We implement a two step balancing logic. Basically, every time there is
- * the need to decide where to run a vcpu, we first check the soft affinity
- * (well, actually, the && between soft and hard affinity), to see if we can
- * send it where it prefers to (and can) run on. However, if the first step
- * does not find any suitable and free pcpu, we fall back checking the hard
- * affinity.
- */
-#define CSCHED_BALANCE_SOFT_AFFINITY0
-#define CSCHED_BALANCE_HARD_AFFINITY1
-
 /*
  * Boot parameters
  */
@@ -331,52 +310,6 @@ runq_remove(struct csched_vcpu *svc)
 __runq_remove(svc);
 }
 
-#define for_each_csched_balance_step(step) \
-for ( (step) = 0; (step) <= CSCHED_BALANCE_HARD_AFFINITY; (step)++ )
-
-
-/*
- * Hard affinity balancing is always necessary and must never be skipped.
- * But soft affinity need only be considered when it has a functionally
- * different effect than other constraints (such as hard affinity, cpus
- * online, or cpupools).
- *
- * Soft affinity only needs to be considered if:
- * * The cpus in the cpupool are not a subset of soft affinity
- * * The hard affinity is not a subset of soft affinity
- * * There is an overlap between the soft affinity and the mask which is
- *   currently being considered.
- */
-static inline int __vcpu_has_soft_affinity(const struct vcpu *vc,
-   const cpumask_t *mask)
-{
-return !cpumask_subset(cpupool_domain_cpumask(vc->domain),
-   vc->cpu_soft_affinity) &&
-   !cpumask_subset(vc->cpu_hard_affinity, vc->cpu_soft_affinity) &&
-   cpumask_intersects(vc->cpu_soft_affinity, mask);
-}
-
-/*
- * Each csched-balance step uses its own cpumask. This function determines
- * which one (given the step) and copies it in mask. For the soft affinity
- * balancing step, the pcpus that are not part of vc's hard affinity are
- * filtered out from the result, to avoid running a vcpu where it would
- * like, but is not allowed to!
- */
-static void
-csched_balance_cpumask(const struct vcpu *vc, int step, cpumask_t *mask)
-{
-if ( step == CSCHED_BALANCE_SOFT_AFFINITY )
-{
-cpumask_and(mask, vc->cpu_soft_affinity, vc->cpu_hard_affinity);
-
-if ( unlikely(cpumask_empty(mask)) )
-cpumask_copy(mask, vc->cpu_hard_affinity);
-}
-else /* step == CSCHED_BALANCE_HARD_AFFINITY */
-cpumask_copy(mask, vc->cpu_hard_affinity);
-}
-
 static void burn_credits(struct csched_vcpu *svc, s_time_t now)
 {
 s_time_t delta;
@@ -441,18 +374,18 @@ static inline void __runq_tickle(struct csched_vcpu *new)
  * Soft and hard affinity balancing loop. For vcpus without
  * a useful soft affinity, consider hard affinity only.
  */
-for_each_csched_balance_step( balance_step )
+for_each_affinity_balance_step( balance_step )
 {
 int new_idlers_empty;
 
-if ( balance_step == CSCHED_BALANCE_SOFT_AFFINITY
- && !__vcpu_has_soft_affinity(new->vcpu,
-  new->vcpu->cpu_hard_affinity) )
+if ( balance_step == BALANCE_SOFT_AFFINITY
+ && !has_soft_affinity(new->vcpu,
+   new->vcpu->cpu_hard_affinity) )
 continue;
 
 /* Are there idlers suitable for new (for this balance step)? */
-csched_balance_cpumask(new->vcpu, balance_step,
-   cpumask_scratch_cpu(cpu));
+affinity_balance_cpumask(new->vcpu, balance_step,
+ cpumask_scratch_cpu(cpu));
 cpumask_

[Xen-devel] [PATCH 0/5] xen: sched_null: support soft affinity

[Dario Faggioli]

In the null scheduler, we don't need either hard or soft affinity during online
scheduling operations.  In fact, the vCPUs are statically assigned to the
pCPUs, and hence there's no scope for checking or enforcing any affinity.

We, however, use hard-affinity for 'placement', i.e., for deciding to what pCPU
to statically assign a vCPU.  Let's, therefore, use soft-affinity too, for the
same purpose. Of course, in this case, if there's no free pCPU within the
vCPU's soft-affinity, we go checking the hard-affinity, instead of putting the
vCPU in the waitqueue.

This is particularly important because, as of now, libxl uses set a domain's
soft-affinity, if the automatic NUMA placement logic run at domain creation
succeds to find an ideal collocation for the domain, and Xen uses that for
allocating the domain's memory.

Supporting soft-affinity like this would therefore mean that, even when using
the null scheduler, we try to keep the vCPUs close to their memory (on NUMA
hosts, of course).

Note also that this does has no impact on the online scheduling overhead,
because soft-affinity is only considered in cold-paths (like when a vCPU joins
the scheduler for the first time, or is manually moved between pCPUs by the
user).

Note that what is patch 1 in this series, is the same patch 1 of the 'Soft
affinity for Credit2' series:
 https://lists.xenproject.org/archives/html/xen-devel/2017-06/msg01795.html
 https://lists.xenproject.org/archives/html/xen-devel/2017-06/msg01796.html

Regards,
Dario
---
Dario Faggioli (5):
  xen: sched: factor affinity helpers out of sched_credit.c
  xen: sched_null: check for pending tasklet work a bit earlier
  xen: sched-null: support soft-affinity
  xen: sched_null: add some tracing
  tools: tracing: handle null scheduler's events

 tools/xentrace/formats |7 +
 tools/xentrace/xenalyze.c  |   65 ++
 xen/common/sched_credit.c  |   97 +++-
 xen/common/sched_null.c|  209 
 xen/include/public/trace.h |1 
 xen/include/xen/sched-if.h |   64 +
 6 files changed, 323 insertions(+), 120 deletions(-)
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 8cf19dc7a5305007bd33934838c67a7b1640f633
baseline version:
 ovmf 1fb805b1eb5b6039cb12375f8594aba65bf60a44

Last test of basis   53  2017-06-28 13:20:49 Z0 days
Testing same since   72  2017-06-29 04:49:41 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=8cf19dc7a5305007bd33934838c67a7b1640f633
+ . ./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 ovmf 
8cf19dc7a5305007bd33934838c67a7b1640f633
+ branch=ovmf
+ revision=8cf19dc7a5305007bd33934838c67a7b1640f633
+ . ./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=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.9-testing
+ '[' x8cf19dc7a5305007bd33934838c67a7b1640f633 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.gi

Re: [Xen-devel] [PATCH 0/3] please pull xen-20170627-tag

[Peter Maydell]

On 27 June 2017 at 23:04, Stefano Stabellini  wrote:
> The following changes since commit 577caa2672ccde7352fda3ef17e44993de862f0e:
>
>   Merge remote-tracking branch 
> 'remotes/edgar/tags/edgar/mmio-exec-v2.for-upstream' into staging (2017-06-27 
> 16:56:55 +0100)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20170627-tag
>
> for you to fetch changes up to 3284fad7283596033cb810b4788fd1bb43312dbd:
>
>   xen-disk: add support for multi-page shared rings (2017-06-27 15:01:56 
> -0700)
>
> 
> Xen 2017/06/27
>
> 
> Paul Durrant (2):
>   xen-disk: only advertize feature-persistent if grant copy is not 
> available
>   xen-disk: add support for multi-page shared rings
>
> Stefano Stabellini (1):
>   xen/disk: don't leak stack data via response ring
>
>  hw/block/xen_disk.c | 184 
> +---
>  1 file changed, 133 insertions(+), 51 deletions(-)


Applied, thanks.

-- PMM

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

Re: [Xen-devel] [PATCH RFC] Live migration for VMs with QEMU backed local storage

[Wei Liu]

On Fri, Jun 23, 2017 at 03:42:20AM -0400, Bruno Alvisio wrote:
> This patch is the first attempt on adding live migration of instances with 
> local
> storage to Xen. This patch just handles very restricted case of fully
> virtualized HVMs. The code uses the "drive-mirror" capability provided by 
> QEMU.
> A new "-l" option is introduced to "xl migrate" command. If provided, the 
> local
> disk should be mirrored during the migration process. If the option is set,
> during the VM creation a qemu NBD server is started on the destination. After
> the instance is suspended on the source, the QMP "disk-mirror" command is 
> issued
> to mirror the disk to destination. Once the mirroring job is complete, the
> migration process continues as before. Finally, the NBD server is stopped 
> after
> the instance is successfully resumed on the destination node.
> 
> A major problem with this patch is that the mirroring of the disk is performed
> only after the memory stream is completed and the VM is suspended on the 
> source;
> thus the instance is frozen for a long period of time. The reason this happens
> is that the QEMU process (needed for the disk mirroring) is started on the
> destination node only after the memory copying is completed. One possibility I
> was considering to solve this issue (if it is decided that this capability
> should be used): Could a "helper" QEMU process be started on the destination
> node at the beginning of the migration sequence with the sole purpose of
> handling the disk mirroring and kill it at the end of the migration sequence? 
> 

In theory we could, but I am very cautious about this. I _think_ we can
change the timing QEMU is started. It can be started earlier, but take
precaution that it shouldn't resume the guest.

In any case, start with the simple setup first.

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

[Xen-devel] [PATCH 24/25] x86/vvtd: Add queued invalidation (QI) support

[Lan Tianyu]

From: Chao Gao 

Queued Invalidation Interface is an expanded invalidation interface with
extended capabilities. Hardware implementations report support for queued
invalidation interface through the Extended Capability Register. The queued
invalidation interface uses an Invalidation Queue (IQ), which is a circular
buffer in system memory. Software submits commands by writing Invalidation
Descriptors to the IQ.

In this patch, a new function viommu_process_iq() is used for emulating how
hardware handles invalidation requests through QI.

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
 xen/drivers/passthrough/vtd/iommu.h |  29 -
 xen/drivers/passthrough/vtd/vvtd.c  | 244 
 2 files changed, 272 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.h 
b/xen/drivers/passthrough/vtd/iommu.h
index a9e905b..eac0fbe 100644
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -204,6 +204,32 @@
 #define DMA_IRTA_S(val) (val & 0xf)
 #define DMA_IRTA_SIZE(val)  (1UL << (DMA_IRTA_S(val) + 1))
 
+/* IQH_REG */
+#define DMA_IQH_QH_SHIFT4
+#define DMA_IQH_QH(val) ((val >> 4) & 0x7fffULL)
+
+/* IQT_REG */
+#define DMA_IQT_QT_SHIFT4
+#define DMA_IQT_QT(val) ((val >> 4) & 0x7fffULL)
+#define DMA_IQT_RSVD0xfff80007ULL
+
+/* IQA_REG */
+#define DMA_MGAW39  /* Maximum Guest Address Width */
+#define DMA_IQA_ADDR(val)   (val & ~0xfffULL)
+#define DMA_IQA_QS(val) (val & 0x7)
+#define DMA_IQA_ENTRY_PER_PAGE  (1 << 8)
+#define DMA_IQA_RSVD(~((1ULL << DMA_MGAW) -1 ) | 0xff8ULL)
+
+/* IECTL_REG */
+#define DMA_IECTL_IM_BIT 31
+#define DMA_IECTL_IM(1 << DMA_IECTL_IM_BIT)
+#define DMA_IECTL_IP_BIT 30
+#define DMA_IECTL_IP (((u64)1) << DMA_IECTL_IP_BIT)
+
+/* ICS_REG */
+#define DMA_ICS_IWC_BIT 0
+#define DMA_ICS_IWC (1 << DMA_ICS_IWC_BIT)
+
 /* PMEN_REG */
 #define DMA_PMEN_EPM(((u32)1) << 31)
 #define DMA_PMEN_PRS(((u32)1) << 0)
@@ -238,7 +264,8 @@
 #define DMA_FSTS_PPF (1U << DMA_FSTS_PPF_BIT)
 #define DMA_FSTS_AFO (1U << 2)
 #define DMA_FSTS_APF (1U << 3)
-#define DMA_FSTS_IQE (1U << 4)
+#define DMA_FSTS_IQE_BIT 4
+#define DMA_FSTS_IQE (1U << DMA_FSTS_IQE_BIT)
 #define DMA_FSTS_ICE (1U << 5)
 #define DMA_FSTS_ITE (1U << 6)
 #define DMA_FSTS_PRO_BIT 7
diff --git a/xen/drivers/passthrough/vtd/vvtd.c 
b/xen/drivers/passthrough/vtd/vvtd.c
index bea5315..6e5cfdf 100644
--- a/xen/drivers/passthrough/vtd/vvtd.c
+++ b/xen/drivers/passthrough/vtd/vvtd.c
@@ -428,6 +428,185 @@ static int vvtd_record_fault(struct vvtd *vvtd,
 return X86EMUL_OKAY;
 }
 
+/*
+ * Process a invalidation descriptor. Currently, only two types descriptors,
+ * Interrupt Entry Cache Invalidation Descritor and Invalidation Wait
+ * Descriptor are handled.
+ * @vvtd: the virtual vtd instance
+ * @i: the index of the invalidation descriptor to be processed
+ *
+ * If success return 0, or return -1 when failure.
+ */
+static int process_iqe(struct vvtd *vvtd, int i)
+{
+uint64_t iqa, addr;
+struct qinval_entry *qinval_page;
+void *pg;
+int ret;
+
+vvtd_get_reg_quad(vvtd, DMAR_IQA_REG, iqa);
+ret = map_guest_page(vvtd->domain, DMA_IQA_ADDR(iqa)>>PAGE_SHIFT,
+ (void**)&qinval_page);
+if ( ret )
+{
+gdprintk(XENLOG_ERR, "Can't map guest IRT (rc %d)", ret);
+return -1;
+}
+
+switch ( qinval_page[i].q.inv_wait_dsc.lo.type )
+{
+case TYPE_INVAL_WAIT:
+if ( qinval_page[i].q.inv_wait_dsc.lo.sw )
+{
+addr = (qinval_page[i].q.inv_wait_dsc.hi.saddr << 2);
+ret = map_guest_page(vvtd->domain, addr >> PAGE_SHIFT, &pg);
+if ( ret )
+{
+gdprintk(XENLOG_ERR, "Can't map guest memory to inform guest "
+ "IWC completion (rc %d)", ret);
+goto error;
+}
+*(uint32_t *)((uint64_t)pg + (addr & ~PAGE_MASK)) =
+qinval_page[i].q.inv_wait_dsc.lo.sdata;
+unmap_guest_page(pg);
+}
+
+/*
+ * The following code generates an invalidation completion event
+ * indicating the invalidation wait descriptor completion. Note that
+ * the following code fragment is not tested properly.
+ */
+if ( qinval_page[i].q.inv_wait_dsc.lo.iflag )
+{
+uint32_t ie_data, ie_addr;
+if ( !vvtd_test_and_set_bit(vvtd, DMAR_ICS_REG, DMA_ICS_IWC_BIT) )
+{
+__vvtd_set_bit(vvtd, DMAR_IECTL_REG, DMA_IECTL_IP_BIT);
+if ( !vvtd_test_bit(vvtd, DMAR_IECTL_REG, DMA_IECTL_IM_BIT) )
+{
+ie_data = vvtd_get_reg(vvtd, DMAR_IEDATA_REG);
+ie_addr = vvtd_get_reg(vvtd, DMAR_IEADDR_REG);
+vvtd_generate_interrupt(vvtd, ie_addr, ie_data);
+   

[Xen-devel] [PATCH 25/25] x86/vvtd: save and restore emulated VT-d

[Lan Tianyu]

From: Chao Gao 

Wrap some useful status in a new structure hvm_hw_vvtd, following
the customs of vlapic, vioapic and etc. Provide two save-restore
pairs to save/restore registers and non-register status.

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
 xen/drivers/passthrough/vtd/vvtd.c | 98 ++
 xen/include/public/arch-x86/hvm/save.h | 24 -
 2 files changed, 88 insertions(+), 34 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/vvtd.c 
b/xen/drivers/passthrough/vtd/vvtd.c
index 6e5cfdf..8d99c42 100644
--- a/xen/drivers/passthrough/vtd/vvtd.c
+++ b/xen/drivers/passthrough/vtd/vvtd.c
@@ -20,6 +20,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -33,38 +34,25 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "iommu.h"
 #include "vtd.h"
 
-struct hvm_hw_vvtd_regs {
-uint8_t data[1024];
-};
-
 /* Status field of struct vvtd */
 #define VIOMMU_STATUS_IRQ_REMAPPING_ENABLED (1 << 0)
 #define VIOMMU_STATUS_DMA_REMAPPING_ENABLED (1 << 1)
 
 #define vvtd_irq_remapping_enabled(vvtd) \
-(vvtd->status & VIOMMU_STATUS_IRQ_REMAPPING_ENABLED)
+(vvtd->hw.status & VIOMMU_STATUS_IRQ_REMAPPING_ENABLED)
 
 struct vvtd {
-/* VIOMMU_STATUS_XXX_REMAPPING_ENABLED */
-int status;
-/* Fault Recording index */
-int frcd_idx;
 /* Address range of remapping hardware register-set */
 uint64_t base_addr;
 uint64_t length;
 /* Point back to the owner domain */
 struct domain *domain;
-/* Is in Extended Interrupt Mode? */
-bool eim;
-/* Max remapping entries in IRT */
-int irt_max_entry;
-/* Interrupt remapping table base gfn */
-uint64_t irt;
-
+struct hvm_hw_vvtd hw;
 struct hvm_hw_vvtd_regs *regs;
 struct page_info *regs_page;
 };
@@ -370,12 +358,12 @@ static int vvtd_alloc_frcd(struct vvtd *vvtd)
 int prev;
 
 /* Set the F bit to indicate the FRCD is in use. */
-if ( vvtd_test_and_set_bit(vvtd, DMA_FRCD(vvtd->frcd_idx, 
DMA_FRCD3_OFFSET),
+if ( vvtd_test_and_set_bit(vvtd, DMA_FRCD(vvtd->hw.frcd_idx, 
DMA_FRCD3_OFFSET),
DMA_FRCD_F_BIT) )
 {
-prev = vvtd->frcd_idx;
-vvtd->frcd_idx = (prev + 1) % DMA_FRCD_REG_NR;
-return vvtd->frcd_idx;
+prev = vvtd->hw.frcd_idx;
+vvtd->hw.frcd_idx = (prev + 1) % DMA_FRCD_REG_NR;
+return vvtd->hw.frcd_idx;
 }
 return -1;
 }
@@ -712,12 +700,12 @@ static int vvtd_handle_gcmd_ire(struct vvtd *vvtd, 
uint32_t val)
 
 if ( val & DMA_GCMD_IRE )
 {
-vvtd->status |= VIOMMU_STATUS_IRQ_REMAPPING_ENABLED;
+vvtd->hw.status |= VIOMMU_STATUS_IRQ_REMAPPING_ENABLED;
 __vvtd_set_bit(vvtd, DMAR_GSTS_REG, DMA_GSTS_IRES_BIT);
 }
 else
 {
-vvtd->status |= ~VIOMMU_STATUS_IRQ_REMAPPING_ENABLED;
+vvtd->hw.status |= ~VIOMMU_STATUS_IRQ_REMAPPING_ENABLED;
 __vvtd_clear_bit(vvtd, DMAR_GSTS_REG, DMA_GSTS_IRES_BIT);
 }
 
@@ -736,11 +724,11 @@ static int vvtd_handle_gcmd_sirtp(struct vvtd *vvtd, 
uint32_t val)
"active." );
 
 vvtd_get_reg_quad(vvtd, DMAR_IRTA_REG, irta);
-vvtd->irt = DMA_IRTA_ADDR(irta) >> PAGE_SHIFT;
-vvtd->irt_max_entry = DMA_IRTA_SIZE(irta);
-vvtd->eim = DMA_IRTA_EIME(irta);
+vvtd->hw.irt = DMA_IRTA_ADDR(irta) >> PAGE_SHIFT;
+vvtd->hw.irt_max_entry = DMA_IRTA_SIZE(irta);
+vvtd->hw.eim = DMA_IRTA_EIME(irta);
 VVTD_DEBUG(VVTD_DBG_RW, "Update IR info (addr=%lx eim=%d size=%d).",
-   vvtd->irt, vvtd->eim, vvtd->irt_max_entry);
+   vvtd->hw.irt, vvtd->hw.eim, vvtd->hw.irt_max_entry);
 __vvtd_set_bit(vvtd, DMAR_GSTS_REG, DMA_GSTS_SIRTPS_BIT);
 
 return X86EMUL_OKAY;
@@ -948,13 +936,13 @@ static int vvtd_get_entry(struct vvtd *vvtd,
 
 VVTD_DEBUG(VVTD_DBG_TRANS, "interpret a request with index %x", entry);
 
-if ( entry > vvtd->irt_max_entry )
+if ( entry > vvtd->hw.irt_max_entry )
 {
 ret = VTD_FR_IR_INDEX_OVER;
 goto handle_fault;
 }
 
-ret = map_guest_page(vvtd->domain, vvtd->irt + (entry >> 
IREMAP_ENTRY_ORDER),
+ret = map_guest_page(vvtd->domain, vvtd->hw.irt + (entry >> 
IREMAP_ENTRY_ORDER),
  (void**)&irt_page);
 if ( ret )
 {
@@ -1078,6 +1066,49 @@ static int vvtd_get_irq_info(struct domain *d,
 return 0;
 }
 
+static int vvtd_load_regs(struct domain *d, hvm_domain_context_t *h)
+{
+if ( !domain_vvtd(d) )
+return -ENODEV;
+
+if ( hvm_load_entry(IOMMU_REGS, h, domain_vvtd(d)->regs) )
+return -EINVAL;
+
+return 0;
+}
+
+static int vvtd_save_regs(struct domain *d, hvm_domain_context_t *h)
+{
+if ( !domain_vvtd(d) )
+return 0;
+
+return hvm_save_entry(IOMMU_REGS, 0, h, domain_vvtd(d)->regs);
+}
+
+static int vvtd_load_hidden(struct domain *d, hvm_domain_context_t *h)
+{
+if ( !domain_vvtd(d) )
+return -ENODEV;
+
+if ( hvm_load_entry(IOMMU, 

[Xen-devel] [PATCH 21/25] Tools/libxc: Add a new interface to bind remapping format msi with pirq

[Lan Tianyu]

From: Chao Gao 

Introduce a new binding relationship and provide a new interface to
manage the new relationship.

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
 tools/libxc/include/xenctrl.h |  17 ++
 tools/libxc/xc_domain.c   |  53 +
 xen/drivers/passthrough/io.c  | 135 +++---
 xen/include/public/domctl.h   |   7 +++
 xen/include/xen/hvm/irq.h |   7 +++
 5 files changed, 198 insertions(+), 21 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 51ceeb9..75aaa9c 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1710,6 +1710,15 @@ int xc_domain_ioport_mapping(xc_interface *xch,
  uint32_t nr_ports,
  uint32_t add_mapping);
 
+int xc_domain_update_msi_irq_remapping(
+xc_interface *xch,
+uint32_t domid,
+uint32_t pirq,
+uint32_t source_id,
+uint32_t data,
+uint64_t addr,
+uint64_t gtable);
+
 int xc_domain_update_msi_irq(
 xc_interface *xch,
 uint32_t domid,
@@ -1724,6 +1733,14 @@ int xc_domain_unbind_msi_irq(xc_interface *xch,
  uint32_t pirq,
  uint32_t gflags);
 
+int xc_domain_unbind_msi_irq_remapping(
+xc_interface *xch,
+uint32_t domid,
+uint32_t pirq,
+uint32_t source_id,
+uint32_t data,
+uint64_t addr);
+
 int xc_domain_bind_pt_irq(xc_interface *xch,
   uint32_t domid,
   uint8_t machine_irq,
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 5d192ea..58623af 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1657,8 +1657,34 @@ int xc_deassign_dt_device(
 return rc;
 }
 
+int xc_domain_update_msi_irq_remapping(
+xc_interface *xch,
+uint32_t domid,
+uint32_t pirq,
+uint32_t source_id,
+uint32_t data,
+uint64_t addr,
+uint64_t gtable)
+{
+int rc;
+xen_domctl_bind_pt_irq_t *bind;
+
+DECLARE_DOMCTL;
 
+domctl.cmd = XEN_DOMCTL_bind_pt_irq;
+domctl.domain = (domid_t)domid;
 
+bind = &(domctl.u.bind_pt_irq);
+bind->irq_type = PT_IRQ_TYPE_MSI_IR;
+bind->machine_irq = pirq;
+bind->u.msi_ir.source_id = source_id;
+bind->u.msi_ir.data = data;
+bind->u.msi_ir.addr = addr;
+bind->u.msi_ir.gtable = gtable;
+
+rc = do_domctl(xch, &domctl);
+return rc;
+}
 
 int xc_domain_update_msi_irq(
 xc_interface *xch,
@@ -1687,6 +1713,33 @@ int xc_domain_update_msi_irq(
 return rc;
 }
 
+int xc_domain_unbind_msi_irq_remapping(
+xc_interface *xch,
+uint32_t domid,
+uint32_t pirq,
+uint32_t source_id,
+uint32_t data,
+uint64_t addr)
+{
+int rc;
+xen_domctl_bind_pt_irq_t *bind;
+
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_unbind_pt_irq;
+domctl.domain = (domid_t)domid;
+
+bind = &(domctl.u.bind_pt_irq);
+bind->irq_type = PT_IRQ_TYPE_MSI_IR;
+bind->machine_irq = pirq;
+bind->u.msi_ir.source_id = source_id;
+bind->u.msi_ir.data = data;
+bind->u.msi_ir.addr = addr;
+
+rc = do_domctl(xch, &domctl);
+return rc;
+}
+
 int xc_domain_unbind_msi_irq(
 xc_interface *xch,
 uint32_t domid,
diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 2158a11..599f481 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -259,6 +259,92 @@ static struct vcpu *vector_hashing_dest(const struct 
domain *d,
 return dest;
 }
 
+static inline void set_hvm_gmsi_info(struct hvm_gmsi_info *msi,
+ xen_domctl_bind_pt_irq_t *pt_irq_bind)
+{
+if ( pt_irq_bind->irq_type == PT_IRQ_TYPE_MSI )
+{
+msi->legacy.gvec = pt_irq_bind->u.msi.gvec;
+msi->legacy.gflags = pt_irq_bind->u.msi.gflags;
+}
+else if ( pt_irq_bind->irq_type == PT_IRQ_TYPE_MSI_IR )
+{
+msi->intremap.source_id = pt_irq_bind->u.msi_ir.source_id;
+msi->intremap.data = pt_irq_bind->u.msi_ir.data;
+msi->intremap.addr = pt_irq_bind->u.msi_ir.addr;
+}
+else
+BUG();
+}
+
+static inline void clear_hvm_gmsi_info(struct hvm_gmsi_info *msi, int irq_type)
+{
+if ( irq_type == PT_IRQ_TYPE_MSI )
+{
+msi->legacy.gvec = 0;
+msi->legacy.gflags = 0;
+}
+else if ( irq_type == PT_IRQ_TYPE_MSI_IR )
+{
+msi->intremap.source_id = 0;
+msi->intremap.data = 0;
+msi->intremap.addr = 0;
+}
+else
+BUG();
+}
+
+static inline bool hvm_gmsi_info_need_update(struct hvm_gmsi_info *msi,
+ xen_domctl_bind_pt_irq_t *pt_irq_bind)
+{
+if ( pt_irq_bind->irq_type == PT_IRQ_TYPE_MSI )
+return ((msi->legacy.gvec != pt_irq_bind->u.msi.gvec) ||
+(msi->legacy.gflags != pt_irq_bind->u.msi.gflags));
+else if ( pt_irq_bind->irq_type == PT_IRQ_TYPE_MSI_IR )
+

[Xen-devel] [PATCH 7/25] Tools/libacpi: Add DMA remapping reporting (DMAR) ACPI table structures

[Lan Tianyu]

From: Chao Gao 

Add dmar table structure according Chapter 8 "BIOS Considerations" of
VTd spec Rev. 2.4.

VTd 
spec:http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/vt-directed-io-spec.pdf

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
 tools/libacpi/acpi2_0.h | 45 +
 1 file changed, 45 insertions(+)

diff --git a/tools/libacpi/acpi2_0.h b/tools/libacpi/acpi2_0.h
index 2619ba3..8f942b5 100644
--- a/tools/libacpi/acpi2_0.h
+++ b/tools/libacpi/acpi2_0.h
@@ -421,6 +421,49 @@ struct acpi_20_slit {
 uint8_t entry[0];
 };
 
+/* DMA Remapping Table in VTd spec Rev. 2.4. */
+struct acpi_dmar {
+struct acpi_header header;
+uint8_t host_address_width;
+uint8_t flags;
+uint8_t reserved[10]; /* reserved(0) */
+};
+
+/* Remapping Structure Types */
+enum {
+ACPI_DMAR_TYPE_HARDWARE_UNIT = 0,   /* DRHD */
+ACPI_DMAR_TYPE_RESERVED_MEMORY = 1, /* RMRR */
+ACPI_DMAR_TYPE_ATSR = 2,/* ATSR */
+ACPI_DMAR_TYPE_HARDWARE_AFFINITY = 3,   /* RHSR */
+ACPI_DMAR_TYPE_ANDD = 4,/* ANDD */
+ACPI_DMAR_TYPE_RESERVED = 5 /* Reserved for furture use */
+};
+
+struct dmar_device_scope {
+uint8_t type;
+uint8_t length;
+uint8_t reserved[2]; /* reserved(0) */
+uint8_t enumeration_id;
+uint8_t bus;
+uint16_t path[0];
+};
+
+struct acpi_dmar_hardware_unit {
+uint16_t type;
+uint16_t length;
+uint8_t flags;
+uint8_t reserved; /* reserved(0) */
+uint16_t pci_segment; /* The PCI segment associated with this unit */
+uint64_t address; /* Base address of remapping hardware register-set */
+struct dmar_device_scope scope[0];
+};
+
+/* Device scope type */
+#define ACPI_DMAR_DEVICE_SCOPE_IOAPIC   0x03
+
+/* Masks for flags field of struct acpi_dmar_hardware_unit */
+#define ACPI_DMAR_INCLUDE_PCI_ALL   1
+
 /*
  * Table Signatures.
  */
@@ -435,6 +478,7 @@ struct acpi_20_slit {
 #define ACPI_2_0_WAET_SIGNATURE ASCII32('W','A','E','T')
 #define ACPI_2_0_SRAT_SIGNATURE ASCII32('S','R','A','T')
 #define ACPI_2_0_SLIT_SIGNATURE ASCII32('S','L','I','T')
+#define ACPI_2_0_DMAR_SIGNATURE ASCII32('D','M','A','R')
 
 /*
  * Table revision numbers.
@@ -449,6 +493,7 @@ struct acpi_20_slit {
 #define ACPI_1_0_FADT_REVISION 0x01
 #define ACPI_2_0_SRAT_REVISION 0x01
 #define ACPI_2_0_SLIT_REVISION 0x01
+#define ACPI_2_0_DMAR_REVISION 0x01
 
 #pragma pack ()
 
-- 
1.8.3.1


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

[Xen-devel] [PATCH 15/25] x86/vvtd: decode interrupt attribute from IRTE

[Lan Tianyu]

From: Chao Gao 

Previously, interrupt attributes can be extracted from msi message or
IOAPIC RTE. However, with interrupt remapping enabled, the attributes
are enclosed in the associated IRTE. This callback is for cases in
which the caller wants to acquire interrupt attributes.

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
 xen/drivers/passthrough/vtd/vvtd.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/vtd/vvtd.c 
b/xen/drivers/passthrough/vtd/vvtd.c
index e8aeb60..c6d7014 100644
--- a/xen/drivers/passthrough/vtd/vvtd.c
+++ b/xen/drivers/passthrough/vtd/vvtd.c
@@ -533,6 +533,25 @@ static int vvtd_handle_irq_request(struct domain *d,
 return -EFAULT;
 }
 
+static int vvtd_get_irq_info(struct domain *d,
+ struct irq_remapping_request *irq,
+ struct irq_remapping_info *info)
+{
+int ret;
+struct iremap_entry irte;
+struct vvtd *vvtd = domain_vvtd(d);
+
+ret = vvtd_get_entry(vvtd, irq, &irte, false);
+if ( ret )
+return ret;
+
+info->vector = irte.remap.vector;
+info->dest = irte_dest(vvtd, irte.remap.dst);
+info->dest_mode = irte.remap.dm;
+info->delivery_mode = irte.remap.dlm;
+return 0;
+}
+
 static void vvtd_reset(struct vvtd *vvtd, uint64_t capability)
 {
 uint64_t cap, ecap;
@@ -610,7 +629,8 @@ struct viommu_ops vvtd_hvm_vmx_ops = {
 .query_caps = vvtd_query_caps,
 .create = vvtd_create,
 .destroy = vvtd_destroy,
-.handle_irq_request = vvtd_handle_irq_request
+.handle_irq_request = vvtd_handle_irq_request,
+.get_irq_info = vvtd_get_irq_info
 };
 
 static int vvtd_register(void)
-- 
1.8.3.1


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

[Xen-devel] [PATCH 10/25] libxl: create vIOMMU during domain construction

[Lan Tianyu]

From: Chao Gao 

If guest is configured to have a vIOMMU, create it during domain construction.

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
 tools/libxl/libxl_arch.h   |  5 +
 tools/libxl/libxl_arm.c|  7 +++
 tools/libxl/libxl_create.c |  6 ++
 tools/libxl/libxl_x86.c| 24 
 4 files changed, 42 insertions(+)

diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index 5e1fc60..7f9fc9a 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -71,6 +71,11 @@ int libxl__arch_extra_memory(libxl__gc *gc,
  const libxl_domain_build_info *info,
  uint64_t *out);
 
+_hidden
+int libxl__arch_create_viommu(libxl__gc *gc,
+  const libxl_domain_config *d_config,
+  uint32_t domid);
+
 #if defined(__i386__) || defined(__x86_64__)
 
 #define LAPIC_BASE_ADDRESS  0xfee0
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index d842d88..f5bf5dd 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -1065,6 +1065,13 @@ void libxl__arch_domain_build_info_acpi_setdefault(
 libxl_defbool_setdefault(&b_info->acpi, false);
 }
 
+int libxl__arch_create_viommu(libxl__gc *gc,
+ const libxl_domain_config *d_config,
+ uint32_t domid)
+{
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index bffbc45..55119e2 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -557,6 +557,12 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config 
*d_config,
 }
 }
 
+rc = libxl__arch_create_viommu(gc, d_config, *domid);
+if (rc < 0) {
+LOGED(ERROR, *domid, "create vIOMMU fail");
+goto out;
+}
+
 rc = libxl__arch_domain_save_config(gc, d_config, xc_config);
 if (rc < 0)
 goto out;
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 455f6f0..819ee0a 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -2,6 +2,7 @@
 #include "libxl_arch.h"
 
 #include 
+#include 
 
 int libxl__arch_domain_prepare_config(libxl__gc *gc,
   libxl_domain_config *d_config,
@@ -587,6 +588,29 @@ void libxl__arch_domain_build_info_acpi_setdefault(
 libxl_defbool_setdefault(&b_info->acpi, true);
 }
 
+int libxl__arch_create_viommu(libxl__gc *gc,
+  const libxl_domain_config *d_config,
+  uint32_t domid)
+{
+int rc = 0;
+libxl_ctx *ctx = libxl__gc_owner(gc);
+libxl_viommu_info viommu = d_config->b_info.u.hvm.viommu;
+
+if (viommu.type == VIOMMU_TYPE_INTEL_VTD) {
+uint32_t id;
+uint64_t cap;
+
+rc = xc_viommu_query_cap(ctx->xch, domid, viommu.type, &cap);
+if (rc || ((cap & viommu.cap) != cap))
+return rc;
+
+rc = xc_viommu_create(ctx->xch, domid, viommu.type,
+  viommu.base_addr, viommu.length, viommu.cap, 
&id);
+}
+
+return rc;
+}
+
 /*
  * Local variables:
  * mode: C
-- 
1.8.3.1


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

[Xen-devel] [PATCH 23/25] x86/vvtd: Handle interrupt translation faults

[Lan Tianyu]

From: Chao Gao 

Interrupt translation faults are non-recoverable fault. When faults
are triggered, it needs to populate fault info to Fault Recording
Registers and inject vIOMMU msi interrupt to notify guest IOMMU driver
to deal with faults.

This patch emulates hardware's handling interrupt translation
faults (more information about the process can be found in VT-d spec,
chipter "Translation Faults", section "Non-Recoverable Fault
Reporting" and section "Non-Recoverable Logging").
Specifically, viommu_record_fault() records the fault information and
viommu_report_non_recoverable_fault() reports faults to software.
Currently, only Primary Fault Logging is supported and the Number of
Fault-recording Registers is 1.

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
 xen/drivers/passthrough/vtd/iommu.h |  60 +++--
 xen/drivers/passthrough/vtd/vvtd.c  | 238 +++-
 2 files changed, 286 insertions(+), 12 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.h 
b/xen/drivers/passthrough/vtd/iommu.h
index e323352..a9e905b 100644
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -226,26 +226,66 @@
 #define DMA_CCMD_CAIG_MASK(x) (((u64)x) & ((u64) 0x3 << 59))
 
 /* FECTL_REG */
-#define DMA_FECTL_IM (((u64)1) << 31)
+#define DMA_FECTL_IM_BIT 31
+#define DMA_FECTL_IM (1U << DMA_FECTL_IM_BIT)
+#define DMA_FECTL_IP_BIT 30
+#define DMA_FECTL_IP (1U << DMA_FECTL_IP_BIT)
 
 /* FSTS_REG */
-#define DMA_FSTS_PFO ((u64)1 << 0)
-#define DMA_FSTS_PPF ((u64)1 << 1)
-#define DMA_FSTS_AFO ((u64)1 << 2)
-#define DMA_FSTS_APF ((u64)1 << 3)
-#define DMA_FSTS_IQE ((u64)1 << 4)
-#define DMA_FSTS_ICE ((u64)1 << 5)
-#define DMA_FSTS_ITE ((u64)1 << 6)
-#define DMA_FSTS_FAULTSDMA_FSTS_PFO | DMA_FSTS_PPF | DMA_FSTS_AFO | 
DMA_FSTS_APF | DMA_FSTS_IQE | DMA_FSTS_ICE | DMA_FSTS_ITE
+#define DMA_FSTS_PFO_BIT 0
+#define DMA_FSTS_PFO (1U << DMA_FSTS_PFO_BIT)
+#define DMA_FSTS_PPF_BIT 1
+#define DMA_FSTS_PPF (1U << DMA_FSTS_PPF_BIT)
+#define DMA_FSTS_AFO (1U << 2)
+#define DMA_FSTS_APF (1U << 3)
+#define DMA_FSTS_IQE (1U << 4)
+#define DMA_FSTS_ICE (1U << 5)
+#define DMA_FSTS_ITE (1U << 6)
+#define DMA_FSTS_PRO_BIT 7
+#define DMA_FSTS_PRO (1U << DMA_FSTS_PRO_BIT)
+#define DMA_FSTS_FAULTS(DMA_FSTS_PFO | DMA_FSTS_PPF | DMA_FSTS_AFO | 
DMA_FSTS_APF | DMA_FSTS_IQE | DMA_FSTS_ICE | DMA_FSTS_ITE | DMA_FSTS_PRO)
+#define DMA_FSTS_RW1CS (DMA_FSTS_PFO | DMA_FSTS_AFO | DMA_FSTS_APF | 
DMA_FSTS_IQE | DMA_FSTS_ICE | DMA_FSTS_ITE | DMA_FSTS_PRO)
 #define dma_fsts_fault_record_index(s) (((s) >> 8) & 0xff)
 
 /* FRCD_REG, 32 bits access */
-#define DMA_FRCD_F (((u64)1) << 31)
+#define DMA_FRCD_LEN0x10
+#define DMA_FRCD0_OFFSET0x0
+#define DMA_FRCD1_OFFSET0x4
+#define DMA_FRCD2_OFFSET0x8
+#define DMA_FRCD3_OFFSET0xc
+#define DMA_FRCD3_FR_MASK   0xffUL
+#define DMA_FRCD_F_BIT 31
+#define DMA_FRCD_F ((u64)1 << DMA_FRCD_F_BIT)
+#define DMA_FRCD(idx, offset) (DMA_CAP_FRO_OFFSET + DMA_FRCD_LEN * idx + 
offset)
 #define dma_frcd_type(d) ((d >> 30) & 1)
 #define dma_frcd_fault_reason(c) (c & 0xff)
 #define dma_frcd_source_id(c) (c & 0x)
 #define dma_frcd_page_addr(d) (d & (((u64)-1) << 12)) /* low 64 bit */
 
+struct vtd_fault_record_register
+{
+union {
+struct {
+u64 lo;
+u64 hi;
+} bits;
+struct {
+u64 rsvd0   :12,
+FI  :52; /* Fault Info */
+u64 SID :16, /* Source Identifier */
+rsvd1   :9,
+PRIV:1,  /* Privilege Mode Requested */
+EXE :1,  /* Execute Permission Requested */
+PP  :1,  /* PASID Present */
+FR  :8,  /* Fault Reason */
+PV  :20, /* PASID Value */
+AT  :2,  /* Address Type */
+T   :1,  /* Type. (0) Write (1) Read/AtomicOp */
+F   :1;  /* Fault */
+} fields;
+};
+};
+
 enum VTD_FAULT_TYPE
 {
 /* Interrupt remapping transition faults */
diff --git a/xen/drivers/passthrough/vtd/vvtd.c 
b/xen/drivers/passthrough/vtd/vvtd.c
index f8e5499..bea5315 100644
--- a/xen/drivers/passthrough/vtd/vvtd.c
+++ b/xen/drivers/passthrough/vtd/vvtd.c
@@ -19,6 +19,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -30,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "iommu.h"
@@ -49,6 +51,8 @@ struct hvm_hw_vvtd_regs {
 struct vvtd {
 /* VIOMMU_STATUS_XXX_REMAPPING_ENABLED */
 int status;
+/* Fault Recording index */
+int frcd_idx;
 /* Address range of remapping hardware register-set */
 uint64_t base_addr;
 uint64_t length;
@@ -97,6 +101,23 @@ static inline struct vvtd *vcpu_vvtd(struct vcpu *v)
 return domain_vvtd(v->domain);
 }
 
+static inline int vvtd_test_and_set_bit(struct vvtd *vvtd, uint32_t reg,
+int nr)
+{
+

[Xen-devel] [PATCH 20/25] passthrough: move some fields of hvm_gmsi_info to a sub-structure

[Lan Tianyu]

From: Chao Gao 

No functional change. It is a preparation for introducing new fields in
hvm_gmsi_info to manage remapping format msi bound to a physical msi.

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
 xen/arch/x86/hvm/vmsi.c  |  4 ++--
 xen/drivers/passthrough/io.c | 32 
 xen/include/xen/hvm/irq.h|  8 ++--
 3 files changed, 24 insertions(+), 20 deletions(-)

diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
index a36692c..c4ec0ad 100644
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -101,8 +101,8 @@ int vmsi_deliver(
 
 void vmsi_deliver_pirq(struct domain *d, const struct hvm_pirq_dpci *pirq_dpci)
 {
-uint32_t flags = pirq_dpci->gmsi.gflags;
-int vector = pirq_dpci->gmsi.gvec;
+uint32_t flags = pirq_dpci->gmsi.legacy.gflags;
+int vector = pirq_dpci->gmsi.legacy.gvec;
 uint8_t dest = (uint8_t)flags;
 uint8_t dest_mode = !!(flags & VMSI_DM_MASK);
 uint8_t delivery_mode = (flags & VMSI_DELIV_MASK)
diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index e5a43e5..2158a11 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -325,8 +325,8 @@ int pt_irq_create_bind(
 {
 pirq_dpci->flags = HVM_IRQ_DPCI_MAPPED | HVM_IRQ_DPCI_MACH_MSI |
HVM_IRQ_DPCI_GUEST_MSI;
-pirq_dpci->gmsi.gvec = pt_irq_bind->u.msi.gvec;
-pirq_dpci->gmsi.gflags = pt_irq_bind->u.msi.gflags;
+pirq_dpci->gmsi.legacy.gvec = pt_irq_bind->u.msi.gvec;
+pirq_dpci->gmsi.legacy.gflags = pt_irq_bind->u.msi.gflags;
 /*
  * 'pt_irq_create_bind' can be called after 'pt_irq_destroy_bind'.
  * The 'pirq_cleanup_check' which would free the structure is only
@@ -358,8 +358,8 @@ int pt_irq_create_bind(
 }
 if ( unlikely(rc) )
 {
-pirq_dpci->gmsi.gflags = 0;
-pirq_dpci->gmsi.gvec = 0;
+pirq_dpci->gmsi.legacy.gflags = 0;
+pirq_dpci->gmsi.legacy.gvec = 0;
 pirq_dpci->dom = NULL;
 pirq_dpci->flags = 0;
 pirq_cleanup_check(info, d);
@@ -378,20 +378,20 @@ int pt_irq_create_bind(
 }
 
 /* If pirq is already mapped as vmsi, update guest data/addr. */
-if ( pirq_dpci->gmsi.gvec != pt_irq_bind->u.msi.gvec ||
- pirq_dpci->gmsi.gflags != pt_irq_bind->u.msi.gflags )
+if ( pirq_dpci->gmsi.legacy.gvec != pt_irq_bind->u.msi.gvec ||
+ pirq_dpci->gmsi.legacy.gflags != pt_irq_bind->u.msi.gflags )
 {
 /* Directly clear pending EOIs before enabling new MSI info. */
 pirq_guest_eoi(info);
 
-pirq_dpci->gmsi.gvec = pt_irq_bind->u.msi.gvec;
-pirq_dpci->gmsi.gflags = pt_irq_bind->u.msi.gflags;
+pirq_dpci->gmsi.legacy.gvec = pt_irq_bind->u.msi.gvec;
+pirq_dpci->gmsi.legacy.gflags = pt_irq_bind->u.msi.gflags;
 }
 }
 /* Calculate dest_vcpu_id for MSI-type pirq migration. */
-dest = pirq_dpci->gmsi.gflags & VMSI_DEST_ID_MASK;
-dest_mode = !!(pirq_dpci->gmsi.gflags & VMSI_DM_MASK);
-delivery_mode = (pirq_dpci->gmsi.gflags & VMSI_DELIV_MASK) >>
+dest = pirq_dpci->gmsi.legacy.gflags & VMSI_DEST_ID_MASK;
+dest_mode = !!(pirq_dpci->gmsi.legacy.gflags & VMSI_DM_MASK);
+delivery_mode = (pirq_dpci->gmsi.legacy.gflags & VMSI_DELIV_MASK) >>
  GFLAGS_SHIFT_DELIV_MODE;
 
 dest_vcpu_id = hvm_girq_dest_2_vcpu_id(d, dest, dest_mode);
@@ -404,7 +404,7 @@ int pt_irq_create_bind(
 {
 if ( delivery_mode == dest_LowestPrio )
 vcpu = vector_hashing_dest(d, dest, dest_mode,
-   pirq_dpci->gmsi.gvec);
+   pirq_dpci->gmsi.legacy.gvec);
 if ( vcpu )
 pirq_dpci->gmsi.posted = true;
 }
@@ -414,7 +414,7 @@ int pt_irq_create_bind(
 /* Use interrupt posting if it is supported. */
 if ( iommu_intpost )
 pi_update_irte(vcpu ? &vcpu->arch.hvm_vmx.pi_desc : NULL,
-   info, pirq_dpci->gmsi.gvec);
+   info, pirq_dpci->gmsi.legacy.gvec);
 
 break;
 }
@@ -729,10 +729,10 @@ static int _hvm_dpci_msi_eoi(struct domain *d,
 int vector = (long)arg;
 
 if ( (pirq_dpci->flags & HVM_IRQ_DPCI_MACH_MSI) &&
- (pirq_dpci->gmsi.gvec == vector) )
+ (pirq_dpci->gmsi.legacy.gvec == vector) )
 {
-int dest = pirq_dpci->gmsi.gflags & VMSI_DEST_ID_MASK;
-int dest_mode = !!(pirq_dpci->gmsi.gflags & VMSI_DM_MASK);
+int dest = pirq_dpci->gmsi.legacy.gflags & VMSI_DEST_ID_MASK;
+int dest_mode = !!(pirq_dpci->gmsi.legacy.gflags

[Xen-devel] [PATCH 17/25] X86/vvtd: Enable Queued Invalidation through GCMD

[Lan Tianyu]

From: Chao Gao 

Software writes to QIE fields of GCMD to enable or disable queued
invalidations. This patch emulates QIE fields of GCMD.

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
 xen/drivers/passthrough/vtd/iommu.h |  3 ++-
 xen/drivers/passthrough/vtd/vvtd.c  | 22 ++
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.h 
b/xen/drivers/passthrough/vtd/iommu.h
index 70e64cf..82bf6bc 100644
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -190,7 +190,8 @@
 #define DMA_GSTS_FLS(((u64)1) << 29)
 #define DMA_GSTS_AFLS   (((u64)1) << 28)
 #define DMA_GSTS_WBFS   (((u64)1) << 27)
-#define DMA_GSTS_QIES   (((u64)1) <<26)
+#define DMA_GSTS_QIES_BIT   26
+#define DMA_GSTS_QIES   (((u64)1) << DMA_GSTS_QIES_BIT)
 #define DMA_GSTS_IRES   (((u64)1) <<25)
 #define DMA_GSTS_SIRTPS_BIT 24
 #define DMA_GSTS_SIRTPS (((u64)1) << DMA_GSTS_SIRTPS_BIT)
diff --git a/xen/drivers/passthrough/vtd/vvtd.c 
b/xen/drivers/passthrough/vtd/vvtd.c
index c6d7014..0954aa2 100644
--- a/xen/drivers/passthrough/vtd/vvtd.c
+++ b/xen/drivers/passthrough/vtd/vvtd.c
@@ -102,6 +102,11 @@ static inline void __vvtd_set_bit(struct vvtd *vvtd, 
uint32_t reg, int nr)
 return __set_bit(nr, (uint32_t *)&vvtd->regs->data[reg]);
 }
 
+static inline void __vvtd_clear_bit(struct vvtd *vvtd, uint32_t reg, int nr)
+{
+return __clear_bit(nr, (uint32_t *)&vvtd->regs->data[reg]);
+}
+
 static inline void vvtd_set_reg(struct vvtd *vtd, uint32_t reg,
 uint32_t value)
 {
@@ -262,6 +267,21 @@ static int vvtd_record_fault(struct vvtd *vvtd,
 return 0;
 }
 
+static int vvtd_handle_gcmd_qie(struct vvtd *vvtd, uint32_t val)
+{
+VVTD_DEBUG(VVTD_DBG_RW, "%sable Queue Invalidation.",
+   (val & DMA_GCMD_QIE) ? "En" : "Dis");
+
+if ( val & DMA_GCMD_QIE )
+__vvtd_set_bit(vvtd, DMAR_GSTS_REG, DMA_GSTS_QIES_BIT);
+else
+{
+vvtd_set_reg_quad(vvtd, DMAR_IQH_REG, 0ULL);
+__vvtd_clear_bit(vvtd, DMAR_GSTS_REG, DMA_GSTS_QIES_BIT);
+}
+return X86EMUL_OKAY;
+}
+
 static int vvtd_handle_gcmd_sirtp(struct vvtd *vvtd, uint32_t val)
 {
 uint64_t irta;
@@ -296,6 +316,8 @@ static int vvtd_write_gcmd(struct vvtd *vvtd, uint32_t val)
 
 if ( changed & DMA_GCMD_SIRTP )
 vvtd_handle_gcmd_sirtp(vvtd, val);
+if ( changed & DMA_GCMD_QIE )
+vvtd_handle_gcmd_qie(vvtd, val);
 
 return X86EMUL_OKAY;
 }
-- 
1.8.3.1


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

[Xen-devel] [PATCH 13/25] X86/vvtd: Set Interrupt Remapping Table Pointer through GCMD

[Lan Tianyu]

From: Chao Gao 

Software sets this field to set/update the interrupt remapping table pointer
used by hardware. The interrupt remapping table pointer is specified through
the Interrupt Remapping Table Address (IRTA_REG) register.

This patch emulates this operation and adds some new fields in VVTD to track
info (e.g. the table's gfn and max supported entries) of interrupt remapping
table.

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
 xen/drivers/passthrough/vtd/iommu.h |  9 -
 xen/drivers/passthrough/vtd/vvtd.c  | 73 +
 2 files changed, 81 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.h 
b/xen/drivers/passthrough/vtd/iommu.h
index 55f3b6e..102b4f3 100644
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -192,9 +192,16 @@
 #define DMA_GSTS_WBFS   (((u64)1) << 27)
 #define DMA_GSTS_QIES   (((u64)1) <<26)
 #define DMA_GSTS_IRES   (((u64)1) <<25)
-#define DMA_GSTS_SIRTPS (((u64)1) << 24)
+#define DMA_GSTS_SIRTPS_BIT 24
+#define DMA_GSTS_SIRTPS (((u64)1) << DMA_GSTS_SIRTPS_BIT)
 #define DMA_GSTS_CFIS   (((u64)1) <<23)
 
+/* IRTA_REG */
+#define DMA_IRTA_ADDR(val)  (val & ~0xfffULL)
+#define DMA_IRTA_EIME(val)  (!!(val & (1 << 11)))
+#define DMA_IRTA_S(val) (val & 0xf)
+#define DMA_IRTA_SIZE(val)  (1UL << (DMA_IRTA_S(val) + 1))
+
 /* PMEN_REG */
 #define DMA_PMEN_EPM(((u32)1) << 31)
 #define DMA_PMEN_PRS(((u32)1) << 0)
diff --git a/xen/drivers/passthrough/vtd/vvtd.c 
b/xen/drivers/passthrough/vtd/vvtd.c
index 0945970..80c7e96 100644
--- a/xen/drivers/passthrough/vtd/vvtd.c
+++ b/xen/drivers/passthrough/vtd/vvtd.c
@@ -46,6 +46,13 @@ struct vvtd {
 uint64_t length;
 /* Point back to the owner domain */
 struct domain *domain;
+/* Is in Extended Interrupt Mode? */
+bool eim;
+/* Max remapping entries in IRT */
+int irt_max_entry;
+/* Interrupt remapping table base gfn */
+uint64_t irt;
+
 struct hvm_hw_vvtd_regs *regs;
 struct page_info *regs_page;
 };
@@ -82,6 +89,11 @@ static inline struct vvtd *vcpu_vvtd(struct vcpu *v)
 return domain_vvtd(v->domain);
 }
 
+static inline void __vvtd_set_bit(struct vvtd *vvtd, uint32_t reg, int nr)
+{
+return __set_bit(nr, (uint32_t *)&vvtd->regs->data[reg]);
+}
+
 static inline void vvtd_set_reg(struct vvtd *vtd, uint32_t reg,
 uint32_t value)
 {
@@ -108,6 +120,44 @@ static inline uint8_t vvtd_get_reg_byte(struct vvtd *vtd, 
uint32_t reg)
 vvtd_set_reg(vvtd, (reg) + 4, (val) >> 32); \
 } while(0)
 
+static int vvtd_handle_gcmd_sirtp(struct vvtd *vvtd, uint32_t val)
+{
+uint64_t irta;
+
+if ( !(val & DMA_GCMD_SIRTP) )
+return X86EMUL_OKAY;
+
+vvtd_get_reg_quad(vvtd, DMAR_IRTA_REG, irta);
+vvtd->irt = DMA_IRTA_ADDR(irta) >> PAGE_SHIFT;
+vvtd->irt_max_entry = DMA_IRTA_SIZE(irta);
+vvtd->eim = DMA_IRTA_EIME(irta);
+VVTD_DEBUG(VVTD_DBG_RW, "Update IR info (addr=%lx eim=%d size=%d).",
+   vvtd->irt, vvtd->eim, vvtd->irt_max_entry);
+__vvtd_set_bit(vvtd, DMAR_GSTS_REG, DMA_GSTS_SIRTPS_BIT);
+
+return X86EMUL_OKAY;
+}
+
+static int vvtd_write_gcmd(struct vvtd *vvtd, uint32_t val)
+{
+uint32_t orig = vvtd_get_reg(vvtd, DMAR_GSTS_REG);
+uint32_t changed;
+
+orig = orig & 0x96ff;/* reset the one-shot bits */
+changed = orig ^ val;
+
+if ( !changed )
+return X86EMUL_OKAY;
+if ( (changed & (changed - 1)) )
+VVTD_DEBUG(VVTD_DBG_RW, "Guest attempts to update multiple fields "
+ "of GCMD_REG in one write transation.");
+
+if ( changed & DMA_GCMD_SIRTP )
+vvtd_handle_gcmd_sirtp(vvtd, val);
+
+return X86EMUL_OKAY;
+}
+
 static int vvtd_range(struct vcpu *v, unsigned long addr)
 {
 struct vvtd *vvtd = vcpu_vvtd(v);
@@ -165,12 +215,18 @@ static int vvtd_write(struct vcpu *v, unsigned long addr,
 {
 switch ( offset_aligned )
 {
+case DMAR_GCMD_REG:
+ret = vvtd_write_gcmd(vvtd, val);
+break;
+
 case DMAR_IEDATA_REG:
 case DMAR_IEADDR_REG:
 case DMAR_IEUADDR_REG:
 case DMAR_FEDATA_REG:
 case DMAR_FEADDR_REG:
 case DMAR_FEUADDR_REG:
+case DMAR_IRTA_REG:
+case DMAR_IRTA_REG_HI:
 vvtd_set_reg(vvtd, offset_aligned, val);
 ret = X86EMUL_OKAY;
 break;
@@ -179,6 +235,20 @@ static int vvtd_write(struct vcpu *v, unsigned long addr,
 break;
 }
 }
+else /* len == 8 */
+{
+switch ( offset_aligned )
+{
+case DMAR_IRTA_REG:
+vvtd_set_reg_quad(vvtd, DMAR_IRTA_REG, val);
+ret = X86EMUL_OKAY;
+break;
+
+default:
+ret = X86EMUL_UNHANDLEABLE;
+break;
+}
+}
 
 return ret;
 }
@@ -236,6 +306,9 @@ static int vvtd_create(struct domain *d, struct viommu 
*viommu)

[Xen-devel] [PATCH 14/25] X86/vvtd: Process interrupt remapping request

[Lan Tianyu]

From: Chao Gao 

When a remapping interrupt request arrives, remapping hardware computes the
interrupt_index per the algorithm described in VTD spec
"Interrupt Remapping Table", interprets the IRTE and generates a remapped
interrupt request.

This patch introduces viommu_handle_irq_request() to emulate the process how
remapping hardware handles a remapping interrupt request.

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
 xen/drivers/passthrough/vtd/iommu.h |  21 +++
 xen/drivers/passthrough/vtd/vtd.h   |   6 +
 xen/drivers/passthrough/vtd/vvtd.c  | 277 +++-
 3 files changed, 303 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.h 
b/xen/drivers/passthrough/vtd/iommu.h
index 102b4f3..70e64cf 100644
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -244,6 +244,21 @@
 #define dma_frcd_source_id(c) (c & 0x)
 #define dma_frcd_page_addr(d) (d & (((u64)-1) << 12)) /* low 64 bit */
 
+enum VTD_FAULT_TYPE
+{
+/* Interrupt remapping transition faults */
+VTD_FR_IR_REQ_RSVD = 0x20,   /* One or more IR request reserved
+  * fields set */
+VTD_FR_IR_INDEX_OVER = 0x21, /* Index value greater than max */
+VTD_FR_IR_ENTRY_P = 0x22,/* Present (P) not set in IRTE */
+VTD_FR_IR_ROOT_INVAL = 0x23, /* IR Root table invalid */
+VTD_FR_IR_IRTE_RSVD = 0x24,  /* IRTE Rsvd field non-zero with
+  * Present flag set */
+VTD_FR_IR_REQ_COMPAT = 0x25, /* Encountered compatible IR
+  * request while disabled */
+VTD_FR_IR_SID_ERR = 0x26,/* Invalid Source-ID */
+};
+
 /*
  * 0: Present
  * 1-11: Reserved
@@ -384,6 +399,12 @@ struct iremap_entry {
 };
 
 /*
+ * When VT-d doesn't enable Extended Interrupt Mode. Hardware only interprets
+ * only 8-bits ([15:8]) of Destination-ID field in the IRTEs.
+ */
+#define IRTE_xAPIC_DEST_MASK 0xff00
+
+/*
  * Posted-interrupt descriptor address is 64 bits with 64-byte aligned, only
  * the upper 26 bits of lest significiant 32 bits is available.
  */
diff --git a/xen/drivers/passthrough/vtd/vtd.h 
b/xen/drivers/passthrough/vtd/vtd.h
index bb8889f..1032b46 100644
--- a/xen/drivers/passthrough/vtd/vtd.h
+++ b/xen/drivers/passthrough/vtd/vtd.h
@@ -47,6 +47,8 @@ struct IO_APIC_route_remap_entry {
 };
 };
 
+#define IOAPIC_REMAP_ENTRY_INDEX(x) ((x.index_15 << 15) + x.index_0_14)
+
 struct msi_msg_remap_entry {
 union {
 u32 val;
@@ -65,4 +67,8 @@ struct msi_msg_remap_entry {
 u32data;   /* msi message data */
 };
 
+#define MSI_REMAP_ENTRY_INDEX(x) ((x.address_lo.index_15 << 15) + \
+  x.address_lo.index_0_14 + \
+  (x.address_lo.SHV ? (uint16_t)x.data : 0))
+
 #endif // _VTD_H_
diff --git a/xen/drivers/passthrough/vtd/vvtd.c 
b/xen/drivers/passthrough/vtd/vvtd.c
index 80c7e96..e8aeb60 100644
--- a/xen/drivers/passthrough/vtd/vvtd.c
+++ b/xen/drivers/passthrough/vtd/vvtd.c
@@ -23,12 +23,17 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
+#include 
 #include 
+#include 
 #include 
 
 #include "iommu.h"
+#include "vtd.h"
 
 struct hvm_hw_vvtd_regs {
 uint8_t data[1024];
@@ -38,6 +43,9 @@ struct hvm_hw_vvtd_regs {
 #define VIOMMU_STATUS_IRQ_REMAPPING_ENABLED (1 << 0)
 #define VIOMMU_STATUS_DMA_REMAPPING_ENABLED (1 << 1)
 
+#define vvtd_irq_remapping_enabled(vvtd) \
+(vvtd->status & VIOMMU_STATUS_IRQ_REMAPPING_ENABLED)
+
 struct vvtd {
 /* VIOMMU_STATUS_XXX_REMAPPING_ENABLED */
 int status;
@@ -120,6 +128,140 @@ static inline uint8_t vvtd_get_reg_byte(struct vvtd *vtd, 
uint32_t reg)
 vvtd_set_reg(vvtd, (reg) + 4, (val) >> 32); \
 } while(0)
 
+static int map_guest_page(struct domain *d, uint64_t gfn, void **virt)
+{
+struct page_info *p;
+
+p = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);
+if ( !p )
+return -EINVAL;
+
+if ( !get_page_type(p, PGT_writable_page) )
+{
+put_page(p);
+return -EINVAL;
+}
+
+*virt = __map_domain_page_global(p);
+if ( !*virt )
+{
+put_page_and_type(p);
+return -ENOMEM;
+}
+return 0;
+}
+
+static void unmap_guest_page(void *virt)
+{
+struct page_info *page;
+
+if ( !virt )
+return;
+
+virt = (void *)((unsigned long)virt & PAGE_MASK);
+page = mfn_to_page(domain_page_map_to_mfn(virt));
+
+unmap_domain_page_global(virt);
+put_page_and_type(page);
+}
+
+static void vvtd_inj_irq(
+struct vlapic *target,
+uint8_t vector,
+uint8_t trig_mode,
+uint8_t delivery_mode)
+{
+VVTD_DEBUG(VVTD_DBG_INFO, "dest=v%d, delivery_mode=%x vector=%d "
+   "trig_mode=%d.",
+   vlapic_vcpu(target)->vcpu_id, delivery_mode,
+   vector, trig_mode);
+
+ASSERT((delivery_mode == dest_Fixed) ||
+   (delivery_mode == dest_LowestPrio));
+
+ 

[Xen-devel] [PATCH 19/25] x86/vioapic: introduce a function to get vector from pin

[Lan Tianyu]

From: Chao Gao 

When IOAPIC RTE is in remapping format, it doesn't contain the vector of
interrupt. This patch adds vioapic_pin_vector() to get vector from pin
for both remapping format and legacy format and uses this function other
than accessing IOAPIC RTE directly.

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
 xen/arch/x86/hvm/vioapic.c| 21 +
 xen/arch/x86/hvm/vpt.c| 11 ++-
 xen/include/asm-x86/hvm/vioapic.h |  1 +
 3 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c
index 40f529c..f560c0b 100644
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -319,6 +319,27 @@ static inline int pit_channel0_enabled(void)
 return pt_active(¤t->domain->arch.vpit.pt0);
 }
 
+int vioapic_pin_vector(struct hvm_vioapic *vioapic, unsigned int pin)
+{
+struct IO_APIC_route_remap_entry rte = { { vioapic->redirtbl[pin].bits } };
+
+if ( rte.format )
+{
+int err;
+struct irq_remapping_request request;
+struct irq_remapping_info info;
+
+irq_request_ioapic_fill(&request, vioapic->id, rte.val);
+/* Currently, only viommu 0 is supported */
+err = viommu_get_irq_info(vioapic->domain, 0, &request, &info);
+return !err ? info.vector : -1;
+}
+else
+{
+return vioapic->redirtbl[pin].fields.vector;
+}
+}
+
 static void vioapic_deliver(struct hvm_vioapic *vioapic, unsigned int pin)
 {
 uint16_t dest = vioapic->redirtbl[pin].fields.dest_id;
diff --git a/xen/arch/x86/hvm/vpt.c b/xen/arch/x86/hvm/vpt.c
index e3f2039..d69c3c0 100644
--- a/xen/arch/x86/hvm/vpt.c
+++ b/xen/arch/x86/hvm/vpt.c
@@ -80,6 +80,7 @@ static int pt_irq_vector(struct periodic_time *pt, enum 
hvm_intsrc src)
 struct vcpu *v = pt->vcpu;
 struct hvm_vioapic *vioapic;
 unsigned int gsi, isa_irq, pin;
+int vector;
 
 if ( pt->source == PTSRC_lapic )
 return pt->irq;
@@ -101,7 +102,15 @@ static int pt_irq_vector(struct periodic_time *pt, enum 
hvm_intsrc src)
 return -1;
 }
 
-return vioapic->redirtbl[pin].fields.vector;
+vector = vioapic_pin_vector(vioapic, pin);
+if ( vector < 0 )
+{
+gdprintk(XENLOG_ERR, "Can't get interrupt vector from GSI (%u)\n",
+ gsi);
+domain_crash(v->domain);
+return -1;
+}
+return vector;
 }
 
 static int pt_irq_masked(struct periodic_time *pt)
diff --git a/xen/include/asm-x86/hvm/vioapic.h 
b/xen/include/asm-x86/hvm/vioapic.h
index 2ceb60e..bc2725b 100644
--- a/xen/include/asm-x86/hvm/vioapic.h
+++ b/xen/include/asm-x86/hvm/vioapic.h
@@ -64,6 +64,7 @@ struct hvm_vioapic {
 struct hvm_vioapic *gsi_vioapic(const struct domain *d, unsigned int gsi,
 unsigned int *pin);
 
+int vioapic_pin_vector(struct hvm_vioapic *vioapic, unsigned int pin);
 int vioapic_init(struct domain *d);
 void vioapic_deinit(struct domain *d);
 void vioapic_reset(struct domain *d);
-- 
1.8.3.1


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

[Xen-devel] [PATCH 16/25] x86/vioapic: Hook interrupt delivery of vIOAPIC

[Lan Tianyu]

From: Chao Gao 

When irq remapping is enabled, IOAPIC Redirection Entry may be in remapping
format. If that, generate an irq_remapping_request and call the common
VIOMMU abstraction's callback to handle this interrupt request. Device
model is responsible for checking the request's validity.

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
 xen/arch/x86/hvm/vioapic.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c
index abcc473..40f529c 100644
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -39,6 +40,8 @@
 #include 
 #include 
 
+#include "../../../drivers/passthrough/vtd/vtd.h"
+
 /* HACK: Route IRQ0 only to VCPU0 to prevent time jumps. */
 #define IRQ0_SPECIAL_ROUTING 1
 
@@ -327,9 +330,20 @@ static void vioapic_deliver(struct hvm_vioapic *vioapic, 
unsigned int pin)
 struct vlapic *target;
 struct vcpu *v;
 unsigned int irq = vioapic->base_gsi + pin;
+struct IO_APIC_route_remap_entry rte = { { vioapic->redirtbl[pin].bits } };
 
 ASSERT(spin_is_locked(&d->arch.hvm_domain.irq_lock));
 
+if ( rte.format )
+{
+struct irq_remapping_request request;
+
+irq_request_ioapic_fill(&request, vioapic->id, rte.val);
+/* Currently, only viommu 0 is supported */
+viommu_handle_irq_request(d, 0, &request);
+return;
+}
+
 HVM_DBG_LOG(DBG_LEVEL_IOAPIC,
 "dest=%x dest_mode=%x delivery_mode=%x "
 "vector=%x trig_mode=%x",
-- 
1.8.3.1


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

[Xen-devel] [PATCH 22/25] x86/vmsi: Hook delivering remapping format msi to guest

[Lan Tianyu]

From: Chao Gao 

In two situations, hypervisor delivers a msi to a hvm guest. One is
when qemu sends a request to hypervisor through XEN_DMOP_inject_msi.
The other is when a physical interrupt arrives and it has been bound
to a guest msi.

For the former, the msi is routed to common vIOMMU layer if it is in
remapping format. For the latter, if the pt irq is bound to a guest
remapping msi, a new remapping msi is constructed based on the binding
information and routed to common vIOMMU layer.

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
 xen/arch/x86/hvm/irq.c   | 11 ++
 xen/arch/x86/hvm/vmsi.c  | 14 ++--
 xen/drivers/passthrough/io.c | 51 +---
 xen/include/asm-x86/msi.h|  3 +++
 4 files changed, 65 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
index 8625584..abe2f77 100644
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Must be called with hvm_domain->irq_lock hold */
 static void assert_gsi(struct domain *d, unsigned ioapic_gsi)
@@ -298,6 +299,16 @@ int hvm_inject_msi(struct domain *d, uint64_t addr, 
uint32_t data)
 >> MSI_DATA_TRIGGER_SHIFT;
 uint8_t vector = data & MSI_DATA_VECTOR_MASK;
 
+if ( addr & MSI_ADDR_INTEFORMAT_MASK )
+{
+struct irq_remapping_request request;
+
+irq_request_msi_fill(&request, 0, addr, data);
+/* Currently, only viommu 0 is supported */
+viommu_handle_irq_request(d, 0, &request);
+return 0;
+}
+
 if ( !vector )
 {
 int pirq = ((addr >> 32) & 0xff00) | dest;
diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
index c4ec0ad..75ceb19 100644
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -114,9 +114,19 @@ void vmsi_deliver_pirq(struct domain *d, const struct 
hvm_pirq_dpci *pirq_dpci)
 "vector=%x trig_mode=%x\n",
 dest, dest_mode, delivery_mode, vector, trig_mode);
 
-ASSERT(pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MSI);
+ASSERT(pirq_dpci->flags & (HVM_IRQ_DPCI_GUEST_MSI | 
HVM_IRQ_DPCI_GUEST_MSI_IR));
+if ( pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MSI_IR )
+{
+struct irq_remapping_request request;
 
-vmsi_deliver(d, vector, dest, dest_mode, delivery_mode, trig_mode);
+irq_request_msi_fill(&request, pirq_dpci->gmsi.intremap.source_id,
+ pirq_dpci->gmsi.intremap.addr,
+ pirq_dpci->gmsi.intremap.data);
+/* Currently, only viommu 0 is supported */
+viommu_handle_irq_request(d, 0, &request);
+}
+else
+vmsi_deliver(d, vector, dest, dest_mode, delivery_mode, trig_mode);
 }
 
 /* Return value, -1 : multi-dests, non-negative value: dest_vcpu_id */
diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 599f481..39f0a5b 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -139,7 +139,9 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci 
*pirq_dpci)
 
 bool_t pt_irq_need_timer(uint32_t flags)
 {
-return !(flags & (HVM_IRQ_DPCI_GUEST_MSI | HVM_IRQ_DPCI_TRANSLATE));
+return !(flags & (HVM_IRQ_DPCI_GUEST_MSI_IR |
+  HVM_IRQ_DPCI_GUEST_MSI |
+  HVM_IRQ_DPCI_TRANSLATE));
 }
 
 static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
@@ -656,7 +658,8 @@ int pt_irq_destroy_bind(
 pirq = pirq_info(d, machine_gsi);
 pirq_dpci = pirq_dpci(pirq);
 
-if ( pt_irq_bind->irq_type != PT_IRQ_TYPE_MSI )
+if ( (pt_irq_bind->irq_type != PT_IRQ_TYPE_MSI_IR) &&
+ (pt_irq_bind->irq_type != PT_IRQ_TYPE_MSI) )
 {
 unsigned int bus = pt_irq_bind->u.pci.bus;
 unsigned int device = pt_irq_bind->u.pci.device;
@@ -821,17 +824,39 @@ static int _hvm_dpci_msi_eoi(struct domain *d,
 {
 int vector = (long)arg;
 
-if ( (pirq_dpci->flags & HVM_IRQ_DPCI_MACH_MSI) &&
- (pirq_dpci->gmsi.legacy.gvec == vector) )
+if ( pirq_dpci->flags & HVM_IRQ_DPCI_MACH_MSI )
 {
-int dest = pirq_dpci->gmsi.legacy.gflags & VMSI_DEST_ID_MASK;
-int dest_mode = !!(pirq_dpci->gmsi.legacy.gflags & VMSI_DM_MASK);
+if ( (pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MSI) &&
+ (pirq_dpci->gmsi.legacy.gvec == vector) )
+{
+int dest = pirq_dpci->gmsi.legacy.gflags & VMSI_DEST_ID_MASK;
+int dest_mode = !!(pirq_dpci->gmsi.legacy.gflags & VMSI_DM_MASK);
 
-if ( vlapic_match_dest(vcpu_vlapic(current), NULL, 0, dest,
-   dest_mode) )
+if ( vlapic_match_dest(vcpu_vlapic(current), NULL, 0, dest,
+   dest_mode) )
+{
+__msi_pirq_eoi(pirq_dpci);
+return 1;
+}
+}
+else if ( pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MS

[Xen-devel] [PATCH 18/25] X86/vvtd: Enable Interrupt Remapping through GCMD

[Lan Tianyu]

From: Chao Gao 

Software writes this field to enable/disable interrupt reampping. This patch
emulate IRES field of GCMD.

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
 xen/drivers/passthrough/vtd/iommu.h |  3 ++-
 xen/drivers/passthrough/vtd/vvtd.c  | 27 +++
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.h 
b/xen/drivers/passthrough/vtd/iommu.h
index 82bf6bc..e323352 100644
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -192,7 +192,8 @@
 #define DMA_GSTS_WBFS   (((u64)1) << 27)
 #define DMA_GSTS_QIES_BIT   26
 #define DMA_GSTS_QIES   (((u64)1) << DMA_GSTS_QIES_BIT)
-#define DMA_GSTS_IRES   (((u64)1) <<25)
+#define DMA_GSTS_IRES_BIT   25
+#define DMA_GSTS_IRES   (((u64)1) << DMA_GSTS_IRES_BIT)
 #define DMA_GSTS_SIRTPS_BIT 24
 #define DMA_GSTS_SIRTPS (((u64)1) << DMA_GSTS_SIRTPS_BIT)
 #define DMA_GSTS_CFIS   (((u64)1) <<23)
diff --git a/xen/drivers/passthrough/vtd/vvtd.c 
b/xen/drivers/passthrough/vtd/vvtd.c
index 0954aa2..f8e5499 100644
--- a/xen/drivers/passthrough/vtd/vvtd.c
+++ b/xen/drivers/passthrough/vtd/vvtd.c
@@ -282,6 +282,25 @@ static int vvtd_handle_gcmd_qie(struct vvtd *vvtd, 
uint32_t val)
 return X86EMUL_OKAY;
 }
 
+static int vvtd_handle_gcmd_ire(struct vvtd *vvtd, uint32_t val)
+{
+VVTD_DEBUG(VVTD_DBG_RW, "%sable Interrupt Remapping.",
+   (val & DMA_GCMD_IRE) ? "En" : "Dis");
+
+if ( val & DMA_GCMD_IRE )
+{
+vvtd->status |= VIOMMU_STATUS_IRQ_REMAPPING_ENABLED;
+__vvtd_set_bit(vvtd, DMAR_GSTS_REG, DMA_GSTS_IRES_BIT);
+}
+else
+{
+vvtd->status |= ~VIOMMU_STATUS_IRQ_REMAPPING_ENABLED;
+__vvtd_clear_bit(vvtd, DMAR_GSTS_REG, DMA_GSTS_IRES_BIT);
+}
+
+return X86EMUL_OKAY;
+}
+
 static int vvtd_handle_gcmd_sirtp(struct vvtd *vvtd, uint32_t val)
 {
 uint64_t irta;
@@ -289,6 +308,10 @@ static int vvtd_handle_gcmd_sirtp(struct vvtd *vvtd, 
uint32_t val)
 if ( !(val & DMA_GCMD_SIRTP) )
 return X86EMUL_OKAY;
 
+if ( vvtd_irq_remapping_enabled(vvtd) )
+VVTD_DEBUG(VVTD_DBG_RW, "Update Interrupt Remapping Table when "
+   "active." );
+
 vvtd_get_reg_quad(vvtd, DMAR_IRTA_REG, irta);
 vvtd->irt = DMA_IRTA_ADDR(irta) >> PAGE_SHIFT;
 vvtd->irt_max_entry = DMA_IRTA_SIZE(irta);
@@ -318,6 +341,10 @@ static int vvtd_write_gcmd(struct vvtd *vvtd, uint32_t val)
 vvtd_handle_gcmd_sirtp(vvtd, val);
 if ( changed & DMA_GCMD_QIE )
 vvtd_handle_gcmd_qie(vvtd, val);
+if ( changed & DMA_GCMD_IRE )
+vvtd_handle_gcmd_ire(vvtd, val);
+if ( changed & ~(DMA_GCMD_QIE | DMA_GCMD_SIRTP | DMA_GCMD_IRE) )
+gdprintk(XENLOG_INFO, "Only QIE,SIRTP,IRE in GCMD_REG are handled.\n");
 
 return X86EMUL_OKAY;
 }
-- 
1.8.3.1


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

[Xen-devel] [PATCH 12/25] X86/vvtd: Add MMIO handler for VVTD

[Lan Tianyu]

From: Chao Gao 

This patch adds VVTD MMIO handler to deal with MMIO access.

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
 xen/drivers/passthrough/vtd/vvtd.c | 114 +
 1 file changed, 114 insertions(+)

diff --git a/xen/drivers/passthrough/vtd/vvtd.c 
b/xen/drivers/passthrough/vtd/vvtd.c
index a6735ca..0945970 100644
--- a/xen/drivers/passthrough/vtd/vvtd.c
+++ b/xen/drivers/passthrough/vtd/vvtd.c
@@ -50,6 +50,38 @@ struct vvtd {
 struct page_info *regs_page;
 };
 
+#define __DEBUG_VVTD__
+#ifdef __DEBUG_VVTD__
+extern unsigned int vvtd_debug_level;
+#define VVTD_DBG_INFO 1
+#define VVTD_DBG_TRANS(1<<1)
+#define VVTD_DBG_RW   (1<<2)
+#define VVTD_DBG_FAULT(1<<3)
+#define VVTD_DBG_EOI  (1<<4)
+#define VVTD_DEBUG(lvl, _f, _a...) do { \
+if ( vvtd_debug_level & lvl ) \
+printk("VVTD %s:" _f "\n", __func__, ## _a);\
+} while(0)
+#else
+#define VVTD_DEBUG(fmt...) do {} while(0)
+#endif
+
+unsigned int vvtd_debug_level __read_mostly;
+integer_param("vvtd_debug", vvtd_debug_level);
+
+struct vvtd *domain_vvtd(struct domain *d)
+{
+struct viommu_info *info = &d->viommu;
+
+BUILD_BUG_ON(NR_VIOMMU_PER_DOMAIN != 1);
+return (info && info->viommu[0]) ? info->viommu[0]->priv : NULL;
+}
+
+static inline struct vvtd *vcpu_vvtd(struct vcpu *v)
+{
+return domain_vvtd(v->domain);
+}
+
 static inline void vvtd_set_reg(struct vvtd *vtd, uint32_t reg,
 uint32_t value)
 {
@@ -76,6 +108,87 @@ static inline uint8_t vvtd_get_reg_byte(struct vvtd *vtd, 
uint32_t reg)
 vvtd_set_reg(vvtd, (reg) + 4, (val) >> 32); \
 } while(0)
 
+static int vvtd_range(struct vcpu *v, unsigned long addr)
+{
+struct vvtd *vvtd = vcpu_vvtd(v);
+
+if ( vvtd )
+return (addr >= vvtd->base_addr) &&
+   (addr < vvtd->base_addr + PAGE_SIZE);
+return 0;
+}
+
+static int vvtd_read(struct vcpu *v, unsigned long addr,
+ unsigned int len, unsigned long *pval)
+{
+struct vvtd *vvtd = vcpu_vvtd(v);
+unsigned int offset = addr - vvtd->base_addr;
+unsigned int offset_aligned = offset & ~3;
+
+VVTD_DEBUG(VVTD_DBG_RW, "READ INFO: offset %x len %d.", offset, len);
+
+if ( !pval )
+return X86EMUL_UNHANDLEABLE;
+
+if ( (offset & 3) || ((len != 4) && (len != 8)) )
+{
+VVTD_DEBUG(VVTD_DBG_RW, "Alignment or length is not canonical");
+return X86EMUL_UNHANDLEABLE;
+}
+
+if ( len == 4 )
+*pval = vvtd_get_reg(vvtd, offset_aligned);
+else
+vvtd_get_reg_quad(vvtd, offset_aligned, *pval);
+return X86EMUL_OKAY;
+}
+
+static int vvtd_write(struct vcpu *v, unsigned long addr,
+  unsigned int len, unsigned long val)
+{
+struct vvtd *vvtd = vcpu_vvtd(v);
+unsigned int offset = addr - vvtd->base_addr;
+unsigned int offset_aligned = offset & ~0x3;
+int ret;
+
+VVTD_DEBUG(VVTD_DBG_RW, "WRITE INFO: offset %x len %d val %lx.",
+   offset, len, val);
+
+if ( (offset & 3) || ((len != 4) && (len != 8)) )
+{
+VVTD_DEBUG(VVTD_DBG_RW, "Alignment or length is not canonical");
+return X86EMUL_UNHANDLEABLE;
+}
+
+ret = X86EMUL_UNHANDLEABLE;
+if ( len == 4 )
+{
+switch ( offset_aligned )
+{
+case DMAR_IEDATA_REG:
+case DMAR_IEADDR_REG:
+case DMAR_IEUADDR_REG:
+case DMAR_FEDATA_REG:
+case DMAR_FEADDR_REG:
+case DMAR_FEUADDR_REG:
+vvtd_set_reg(vvtd, offset_aligned, val);
+ret = X86EMUL_OKAY;
+break;
+
+default:
+break;
+}
+}
+
+return ret;
+}
+
+static const struct hvm_mmio_ops vvtd_mmio_ops = {
+.check = vvtd_range,
+.read = vvtd_read,
+.write = vvtd_write
+};
+
 static void vvtd_reset(struct vvtd *vvtd, uint64_t capability)
 {
 uint64_t cap, ecap;
@@ -123,6 +236,7 @@ static int vvtd_create(struct domain *d, struct viommu 
*viommu)
 vvtd->length = viommu->length;
 vvtd->domain = d;
 vvtd->status = 0;
+register_mmio_handler(d, &vvtd_mmio_ops);
 return 0;
 
  out2:
-- 
1.8.3.1


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

[Xen-devel] [PATCH 2/25] DOMCTL: Introduce new DOMCTL commands for vIOMMU support

[Lan Tianyu]

This patch is to introduce create, destroy and query capabilities
command for vIOMMU. vIOMMU layer will deal with requests and call
arch vIOMMU ops.

Signed-off-by: Lan Tianyu 
---
 xen/common/domctl.c |  3 +++
 xen/common/viommu.c | 43 +++
 xen/include/public/domctl.h | 40 
 xen/include/xen/viommu.h|  6 ++
 4 files changed, 92 insertions(+)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 951a5dc..a178544 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -1141,6 +1141,9 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
 if ( !ret )
 copyback = 1;
 break;
+case XEN_DOMCTL_viommu_op:
+ret = viommu_domctl(d, &op->u.viommu_op, ©back);
+break;
 
 default:
 ret = arch_do_domctl(op, d, u_domctl);
diff --git a/xen/common/viommu.c b/xen/common/viommu.c
index 19ba529..ffb2118 100644
--- a/xen/common/viommu.c
+++ b/xen/common/viommu.c
@@ -146,6 +146,49 @@ static u64 viommu_query_caps(struct domain *d, u64 type)
 return viommu_type->ops->query_caps(d);
 }
 
+int viommu_domctl(struct domain *d, struct xen_domctl_viommu_op *op,
+  bool *need_copy)
+{
+int rc = -EINVAL, ret;
+
+if ( !viommu_enabled() )
+return rc;
+
+switch ( op->cmd )
+{
+case XEN_DOMCTL_create_viommu:
+ret = viommu_create(d, op->u.create_viommu.viommu_type,
+ op->u.create_viommu.base_address,
+ op->u.create_viommu.length,
+ op->u.create_viommu.capabilities);
+if ( ret >= 0 ) {
+op->u.create_viommu.viommu_id = ret;
+*need_copy = true;
+rc = 0; /* return 0 if success */
+}
+break;
+
+case XEN_DOMCTL_destroy_viommu:
+rc = viommu_destroy(d, op->u.destroy_viommu.viommu_id);
+break;
+
+case XEN_DOMCTL_query_viommu_caps:
+ret = viommu_query_caps(d, op->u.query_caps.viommu_type);
+if ( ret >= 0 )
+{
+op->u.query_caps.caps = ret;
+rc = 0;
+}
+*need_copy = true;
+break;
+
+default:
+break;
+}
+
+return rc;
+}
+
 int __init viommu_setup(void)
 {
 INIT_LIST_HEAD(&type_list);
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index f7cbc0a..7581df3 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1141,6 +1141,44 @@ struct xen_domctl_psr_cat_op {
 typedef struct xen_domctl_psr_cat_op xen_domctl_psr_cat_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cat_op_t);
 
+struct xen_domctl_viommu_op {
+uint32_t cmd;
+#define XEN_DOMCTL_create_viommu  0
+#define XEN_DOMCTL_destroy_viommu 1
+#define XEN_DOMCTL_query_viommu_caps  2
+union {
+struct {
+/* IN - vIOMMU type */
+uint64_t viommu_type;
+/* 
+ * IN - MMIO base address of vIOMMU. vIOMMU device models
+ * are in charge of to check base_address and length.
+ */
+uint64_t base_address;
+/* IN - Length of MMIO region */
+uint64_t length;
+/* IN - Capabilities with which we want to create */
+uint64_t capabilities;
+/* OUT - vIOMMU identity */
+uint32_t viommu_id;
+} create_viommu;
+
+struct {
+/* IN - vIOMMU identity */
+uint32_t viommu_id;
+} destroy_viommu;
+
+struct {
+/* IN - vIOMMU type */
+uint64_t viommu_type;
+/* OUT - vIOMMU Capabilities */
+uint64_t caps;
+} query_caps;
+} u;
+};
+typedef struct xen_domctl_viommu_op xen_domctl_viommu_op;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_viommu_op);
+
 struct xen_domctl {
 uint32_t cmd;
 #define XEN_DOMCTL_createdomain   1
@@ -1218,6 +1256,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_monitor_op77
 #define XEN_DOMCTL_psr_cat_op78
 #define XEN_DOMCTL_soft_reset79
+#define XEN_DOMCTL_viommu_op 80
 #define XEN_DOMCTL_gdbsx_guestmemio1000
 #define XEN_DOMCTL_gdbsx_pausevcpu 1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu   1002
@@ -1280,6 +1319,7 @@ struct xen_domctl {
 struct xen_domctl_psr_cmt_oppsr_cmt_op;
 struct xen_domctl_monitor_opmonitor_op;
 struct xen_domctl_psr_cat_oppsr_cat_op;
+struct xen_domctl_viommu_op viommu_op;
 uint8_t pad[128];
 } u;
 };
diff --git a/xen/include/xen/viommu.h b/xen/include/xen/viommu.h
index 0a93aa4..bce6825 100644
--- a/xen/include/xen/viommu.h
+++ b/xen/include/xen/viommu.h
@@ -49,6 +49,8 @@ extern bool_t opt_viommu;
 static inline bool_t viommu_enabled(void) { return opt_viommu; }
 int vi

[Xen-devel] [PATCH 3/25] VIOMMU: Add irq request callback to deal with irq remapping

[Lan Tianyu]

This patch is to add irq request callback for platform implementation
to deal with irq remapping request.

Signed-off-by: Lan Tianyu 
---
 xen/common/viommu.c  | 15 +
 xen/include/asm-x86/viommu.h | 73 
 xen/include/xen/viommu.h |  9 ++
 3 files changed, 97 insertions(+)
 create mode 100644 xen/include/asm-x86/viommu.h

diff --git a/xen/common/viommu.c b/xen/common/viommu.c
index ffb2118..93a0176 100644
--- a/xen/common/viommu.c
+++ b/xen/common/viommu.c
@@ -196,6 +196,21 @@ int __init viommu_setup(void)
 return 0;
 }
 
+int viommu_handle_irq_request(struct domain *d, u32 viommu_id,
+  struct irq_remapping_request *request)
+{
+struct viommu_info *info = &d->viommu;
+
+if ( viommu_id >= info->nr_viommu
+ || !info->viommu[viommu_id] )
+return -EINVAL;
+
+if ( !info->viommu[viommu_id]->ops->handle_irq_request )
+return -EINVAL;
+
+return info->viommu[viommu_id]->ops->handle_irq_request(d, request);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-x86/viommu.h b/xen/include/asm-x86/viommu.h
new file mode 100644
index 000..51bda72
--- /dev/null
+++ b/xen/include/asm-x86/viommu.h
@@ -0,0 +1,73 @@
+/*
+ * include/asm-x86/viommu.h
+ *
+ * Copyright (c) 2017 Intel Corporation.
+ * Author: Lan Tianyu  
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 .
+ *
+ */
+#ifndef __ARCH_X86_VIOMMU_H__
+#define __ARCH_X86_VIOMMU_H__
+
+#include 
+#include 
+
+/* IRQ request type */
+#define VIOMMU_REQUEST_IRQ_MSI  0
+#define VIOMMU_REQUEST_IRQ_APIC 1
+
+struct irq_remapping_request
+{
+union {
+/* MSI */
+struct {
+u64 addr;
+u32 data;
+} msi;
+/* Redirection Entry in IOAPIC */
+u64 rte;
+} msg;
+u16 source_id;
+u8 type;
+};
+
+static inline void irq_request_ioapic_fill(struct irq_remapping_request *req,
+ uint32_t ioapic_id, uint64_t rte)
+{
+ASSERT(req);
+req->type = VIOMMU_REQUEST_IRQ_APIC;
+req->source_id = ioapic_id;
+req->msg.rte = rte;
+}
+
+static inline void irq_request_msi_fill(struct irq_remapping_request *req,
+  uint32_t source_id, uint64_t addr, uint32_t data)
+{
+ASSERT(req);
+req->type = VIOMMU_REQUEST_IRQ_MSI;
+req->source_id = source_id;
+req->msg.msi.addr = addr;
+req->msg.msi.data = data;
+}
+
+#endif /* __ARCH_X86_VIOMMU_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * End:
+ */
diff --git a/xen/include/xen/viommu.h b/xen/include/xen/viommu.h
index bce6825..83eb69b 100644
--- a/xen/include/xen/viommu.h
+++ b/xen/include/xen/viommu.h
@@ -20,6 +20,8 @@
 #ifndef __XEN_VIOMMU_H__
 #define __XEN_VIOMMU_H__
 
+#include 
+
 #define NR_VIOMMU_PER_DOMAIN 1
 
 struct viommu;
@@ -28,6 +30,8 @@ struct viommu_ops {
 u64 (*query_caps)(struct domain *d);
 int (*create)(struct domain *d, struct viommu *viommu);
 int (*destroy)(struct viommu *viommu);
+int (*handle_irq_request)(struct domain *d,
+  struct irq_remapping_request *request);
 };
 
 struct viommu {
@@ -52,6 +56,8 @@ int viommu_register_type(u64 type, struct viommu_ops * ops);
 int viommu_domctl(struct domain *d, struct xen_domctl_viommu_op *op,
   bool_t *need_copy);
 int viommu_setup(void);
+int viommu_handle_irq_request(struct domain *d, u32 viommu_id,
+  struct irq_remapping_request *request);
 #else
 static inline int viommu_init_domain(struct domain *d) { return 0; }
 static inline int viommu_register_type(u64 type, struct viommu_ops * ops)
@@ -62,6 +68,9 @@ static inline int viommu_domctl(struct domain *d,
 struct xen_domctl_viommu_op *op,
 bool_t *need_copy)
 { return -ENODEV };
+static inline int viommu_handle_irq_request(struct domain *d, u32 viommu_id,
+  struct irq_remapping_request *request)
+{ return 0 };
 #endif
 
 #endif /* __XEN_VIOMMU_H__ */
-- 
1.8.3.1


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

[Xen-devel] [PATCH 6/25] Tools/libxc: Add viommu operations in libxc

[Lan Tianyu]

From: Chao Gao 

This patch is to add XEN_DOMCTL_viommu_op hypercall. This hypercall
comprise three sub-command:
- query capabilities of one specific type vIOMMU emulated by Xen
- create vIOMMU in Xen hypervisor with viommu type, register range,
capability
- destroy vIOMMU specified by viommu_id

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
 tools/libxc/Makefile  |  1 +
 tools/libxc/include/xenctrl.h |  8 +
 tools/libxc/xc_viommu.c   | 81 +++
 3 files changed, 90 insertions(+)
 create mode 100644 tools/libxc/xc_viommu.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 28b1857..b8f4742 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -51,6 +51,7 @@ CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
 CTRL_SRCS-y   += xc_evtchn_compat.c
 CTRL_SRCS-y   += xc_gnttab_compat.c
 CTRL_SRCS-y   += xc_devicemodel_compat.c
+CTRL_SRCS-y += xc_viommu.c
 
 GUEST_SRCS-y :=
 GUEST_SRCS-y += xg_private.c xc_suspend.c
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 1629f41..51ceeb9 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -27,6 +27,7 @@
 #define __XEN_TOOLS__ 1
 #endif
 
+#include 
 #include 
 #include 
 #include 
@@ -2491,6 +2492,13 @@ enum xc_static_cpu_featuremask {
 const uint32_t *xc_get_static_cpu_featuremask(enum xc_static_cpu_featuremask);
 const uint32_t *xc_get_feature_deep_deps(uint32_t feature);
 
+int xc_viommu_query_cap(xc_interface *xch, uint32_t dom,
+uint64_t type, uint64_t *cap);
+int xc_viommu_create(xc_interface *xch, uint32_t dom, uint64_t type,
+ uint64_t base_addr, uint64_t length, uint64_t cap,
+ uint32_t *viommu_id);
+int xc_viommu_destroy(xc_interface *xch, uint32_t dom, uint32_t viommu_id);
+
 #endif
 
 int xc_livepatch_upload(xc_interface *xch,
diff --git a/tools/libxc/xc_viommu.c b/tools/libxc/xc_viommu.c
new file mode 100644
index 000..54ed877
--- /dev/null
+++ b/tools/libxc/xc_viommu.c
@@ -0,0 +1,81 @@
+/*
+ * xc_viommu.c
+ *
+ * viommu related API functions.
+ *
+ * Copyright (C) 2017 Intel Corporation
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License, version 2.1, as published by the Free Software Foundation.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; If not, see .
+ */
+
+#include "xc_private.h"
+
+int xc_viommu_query_cap(xc_interface *xch, uint32_t dom,
+uint64_t type, uint64_t *cap)
+{
+int rc;
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_viommu_op;
+domctl.domain = (domid_t)dom;
+domctl.u.viommu_op.cmd = XEN_DOMCTL_query_viommu_caps;
+domctl.u.viommu_op.u.query_caps.viommu_type = type;
+
+rc = do_domctl(xch, &domctl);
+if ( !rc )
+*cap = domctl.u.viommu_op.u.query_caps.caps;
+return rc;
+}
+
+int xc_viommu_create(xc_interface *xch, uint32_t dom, uint64_t type,
+ uint64_t base_addr, uint64_t length, uint64_t cap,
+ uint32_t *viommu_id)
+{
+int rc;
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_viommu_op;
+domctl.domain = (domid_t)dom;
+domctl.u.viommu_op.cmd = XEN_DOMCTL_create_viommu;
+domctl.u.viommu_op.u.create_viommu.viommu_type = type;
+domctl.u.viommu_op.u.create_viommu.base_address = base_addr;
+domctl.u.viommu_op.u.create_viommu.length = length;
+domctl.u.viommu_op.u.create_viommu.capabilities = cap;
+
+rc = do_domctl(xch, &domctl);
+if ( !rc )
+*viommu_id = domctl.u.viommu_op.u.create_viommu.viommu_id;
+return rc;
+}
+
+int xc_viommu_destroy(xc_interface *xch, uint32_t dom, uint32_t viommu_id)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_viommu_op;
+domctl.domain = (domid_t)dom;
+domctl.u.viommu_op.cmd = XEN_DOMCTL_destroy_viommu;
+domctl.u.viommu_op.u.destroy_viommu.viommu_id = viommu_id;
+
+return do_domctl(xch, &domctl);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.8.3.1


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

[Xen-devel] [PATCH 9/25] Tools/libacpi: Add a user configurable parameter to control vIOMMU attributes

[Lan Tianyu]

From: Chao Gao 

a field, viommu_info, is added to struct libxl_domain_build_info. Several
attributes can be specified by guest configuration file for the DMAR table
building and vIOMMU creation.

In domain creation process, a new logic is added to build ACPI DMAR table in
tool stack according VM configuration and to pass though it to hvmloader via
xenstore ACPI PT channel. If there are ACPI tables needed to pass through, we
joint the tables.

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
 docs/man/xl.cfg.pod.5.in| 34 +-
 tools/libacpi/build.c   |  5 +++
 tools/libacpi/libacpi.h |  1 +
 tools/libxl/libxl_dom.c | 87 +
 tools/libxl/libxl_types.idl | 10 ++
 tools/xl/xl_parse.c | 64 +
 6 files changed, 200 insertions(+), 1 deletion(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 38084c7..874f3f2 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -1540,7 +1540,39 @@ Do not provide a VM generation ID.
 See also "Virtual Machine Generation ID" by Microsoft:
 L
 
-=back 
+=back
+
+=item B
+
+Specifies the viommu which are to be provided to the guest.
+
+B has the form C where:
+
+=over 4
+
+=item B
+
+Possible Bs are:
+
+=over 4
+
+=item B
+
+Currently there is only one valid type:
+
+(X86 only) "vtd" means providing a emulated intel VT-d to the guest.
+
+=item B
+
+Specifies whether the vvtd should support intrrupt remapping
+and default 'true'.
+
+=item B
+
+Specifies whether the vvtd should support x2apic mode
+and default 'true'.
+
+=back
 
 =head3 Guest Virtual Time Controls
 
diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
index d5bedfd..0c3d3db 100644
--- a/tools/libacpi/build.c
+++ b/tools/libacpi/build.c
@@ -561,6 +561,11 @@ static int new_vm_gid(struct acpi_ctxt *ctxt,
 return 1;
 }
 
+uint32_t acpi_get_table_size(struct acpi_header * header)
+{
+return header ? header->length : 0;
+}
+
 int acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
 {
 struct acpi_info *acpi_info;
diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
index 6a4e1cf..0a58d6f 100644
--- a/tools/libacpi/libacpi.h
+++ b/tools/libacpi/libacpi.h
@@ -109,6 +109,7 @@ struct acpi_config {
 #define DMAR_X2APIC_OPT_OUT 0x2
 struct acpi_dmar *construct_dmar(struct acpi_ctxt *ctxt,
  const struct acpi_config *config);
+uint32_t acpi_get_table_size(struct acpi_header * header);
 int acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config);
 
 #endif /* __LIBACPI_H__ */
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 5d914a5..f8d61c2 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -19,11 +19,13 @@
 
 #include "libxl_internal.h"
 #include "libxl_arch.h"
+#include "libacpi/libacpi.h"
 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include "_paths.h"
 
@@ -925,6 +927,43 @@ out:
 return rc;
 }
 
+static unsigned long acpi_v2p(struct acpi_ctxt *ctxt, void *v)
+{
+return (unsigned long)v;
+}
+
+static void *acpi_mem_alloc(struct acpi_ctxt *ctxt,
+uint32_t size, uint32_t align)
+{
+return aligned_alloc(align, size);
+}
+
+static void acpi_mem_free(struct acpi_ctxt *ctxt,
+  void *v, uint32_t size)
+{
+/* ACPI builder currently doesn't free memory so this is just a stub */
+}
+
+static int libxl__acpi_build_dmar(libxl__gc *gc,
+  struct acpi_config *config,
+  void **data_r, int *datalen_r)
+{
+struct acpi_ctxt ctxt;
+void *table;
+
+ctxt.mem_ops.alloc = acpi_mem_alloc;
+ctxt.mem_ops.free = acpi_mem_free;
+ctxt.mem_ops.v2p = acpi_v2p;
+
+table = construct_dmar(&ctxt, config);
+if ( !table )
+return ERROR_FAIL;
+
+*data_r = table;
+*datalen_r = acpi_get_table_size((struct acpi_header *)table);
+return 0;
+}
+
 static int libxl__domain_firmware(libxl__gc *gc,
   libxl_domain_build_info *info,
   struct xc_dom_image *dom)
@@ -1045,6 +1084,54 @@ static int libxl__domain_firmware(libxl__gc *gc,
 }
 }
 
+/* build DMAR table according guest configuration and joint it with other
+ * apci tables specified by acpi_modules */
+if ((info->u.hvm.viommu.type == VIOMMU_TYPE_INTEL_VTD) &&
+!libxl_defbool_is_default(info->u.hvm.viommu.intremap) &&
+info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
+struct acpi_config config;
+
+memset(&config, 0, sizeof(config));
+if (libxl_defbool_val(info->u.hvm.viommu.intremap)) {
+config.table_flags |= ACPI_HAS_DMAR;
+config.dmar_flag = DMAR_INTR_REMAP;
+if (!libxl_defbool_is_default(info-

[Xen-devel] [PATCH 11/25] x86/hvm: Introduce a emulated VTD for HVM

[Lan Tianyu]

From: Chao Gao 

This patch adds create/destroy/query function for the emulated VTD
and adapts it to the common VIOMMU abstraction.

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
 xen/drivers/passthrough/vtd/Makefile |   7 +-
 xen/drivers/passthrough/vtd/iommu.h  |  99 +-
 xen/drivers/passthrough/vtd/vvtd.c   | 159 +++
 xen/include/asm-x86/viommu.h |   3 +
 4 files changed, 242 insertions(+), 26 deletions(-)
 create mode 100644 xen/drivers/passthrough/vtd/vvtd.c

diff --git a/xen/drivers/passthrough/vtd/Makefile 
b/xen/drivers/passthrough/vtd/Makefile
index f302653..163c7fe 100644
--- a/xen/drivers/passthrough/vtd/Makefile
+++ b/xen/drivers/passthrough/vtd/Makefile
@@ -1,8 +1,9 @@
 subdir-$(CONFIG_X86) += x86
 
-obj-y += iommu.o
 obj-y += dmar.o
-obj-y += utils.o
-obj-y += qinval.o
 obj-y += intremap.o
+obj-y += iommu.o
+obj-y += qinval.o
 obj-y += quirks.o
+obj-y += utils.o
+obj-$(CONFIG_VIOMMU) += vvtd.o
diff --git a/xen/drivers/passthrough/vtd/iommu.h 
b/xen/drivers/passthrough/vtd/iommu.h
index 72c1a2e..55f3b6e 100644
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -23,31 +23,54 @@
 #include 
 
 /*
- * Intel IOMMU register specification per version 1.0 public spec.
+ * Intel IOMMU register specification per version 2.4 public spec.
  */
 
-#defineDMAR_VER_REG0x0/* Arch version supported by this IOMMU */
-#defineDMAR_CAP_REG0x8/* Hardware supported capabilities */
-#defineDMAR_ECAP_REG0x10/* Extended capabilities supported */
-#defineDMAR_GCMD_REG0x18/* Global command register */
-#defineDMAR_GSTS_REG0x1c/* Global status register */
-#defineDMAR_RTADDR_REG0x20/* Root entry table */
-#defineDMAR_CCMD_REG0x28/* Context command reg */
-#defineDMAR_FSTS_REG0x34/* Fault Status register */
-#defineDMAR_FECTL_REG0x38/* Fault control register */
-#defineDMAR_FEDATA_REG0x3c/* Fault event interrupt data register */
-#defineDMAR_FEADDR_REG0x40/* Fault event interrupt addr register */
-#defineDMAR_FEUADDR_REG 0x44/* Upper address register */
-#defineDMAR_AFLOG_REG0x58/* Advanced Fault control */
-#defineDMAR_PMEN_REG0x64/* Enable Protected Memory Region */
-#defineDMAR_PLMBASE_REG 0x68/* PMRR Low addr */
-#defineDMAR_PLMLIMIT_REG 0x6c/* PMRR low limit */
-#defineDMAR_PHMBASE_REG 0x70/* pmrr high base addr */
-#defineDMAR_PHMLIMIT_REG 0x78/* pmrr high limit */
-#defineDMAR_IQH_REG0x80/* invalidation queue head */
-#defineDMAR_IQT_REG0x88/* invalidation queue tail */
-#defineDMAR_IQA_REG0x90/* invalidation queue addr */
-#defineDMAR_IRTA_REG   0xB8/* intr remap */
+#define DMAR_VER_REG0x0  /* Arch version supported by this IOMMU */
+#define DMAR_CAP_REG0x8  /* Hardware supported capabilities */
+#define DMAR_ECAP_REG   0x10 /* Extended capabilities supported */
+#define DMAR_GCMD_REG   0x18 /* Global command register */
+#define DMAR_GSTS_REG   0x1c /* Global status register */
+#define DMAR_RTADDR_REG 0x20 /* Root entry table */
+#define DMAR_CCMD_REG   0x28 /* Context command reg */
+#define DMAR_FSTS_REG   0x34 /* Fault Status register */
+#define DMAR_FECTL_REG  0x38 /* Fault control register */
+#define DMAR_FEDATA_REG 0x3c /* Fault event interrupt data register */
+#define DMAR_FEADDR_REG 0x40 /* Fault event interrupt addr register */
+#define DMAR_FEUADDR_REG0x44 /* Upper address register */
+#define DMAR_AFLOG_REG  0x58 /* Advanced Fault control */
+#define DMAR_PMEN_REG   0x64 /* Enable Protected Memory Region */
+#define DMAR_PLMBASE_REG0x68 /* PMRR Low addr */
+#define DMAR_PLMLIMIT_REG   0x6c /* PMRR low limit */
+#define DMAR_PHMBASE_REG0x70 /* pmrr high base addr */
+#define DMAR_PHMLIMIT_REG   0x78 /* pmrr high limit */
+#define DMAR_IQH_REG0x80 /* invalidation queue head */
+#define DMAR_IQT_REG0x88 /* invalidation queue tail */
+#define DMAR_IQT_REG_HI 0x8c
+#define DMAR_IQA_REG0x90 /* invalidation queue addr */
+#define DMAR_IQA_REG_HI 0x94
+#define DMAR_ICS_REG0x9c /* Invalidation complete status */
+#define DMAR_IECTL_REG  0xa0 /* Invalidation event control */
+#define DMAR_IEDATA_REG 0xa4 /* Invalidation event data */
+#define DMAR_IEADDR_REG 0xa8 /* Invalidation event address */
+#define DMAR_IEUADDR_REG0xac /* Invalidation event address */
+#define DMAR_IRTA_REG   0xb8 /* Interrupt remapping table addr */
+#define DMAR_IRTA_REG_HI0xbc
+#define DMAR_PQH_REG0xc0 /* Page request queue head */
+#define DMAR_PQH_REG_HI 0xc4
+#define DMAR_PQT_REG0xc8 /* Page request queue tai

[Xen-devel] [PATCH 4/25] VIOMMU: Add get irq info callback to convert irq remapping request

[Lan Tianyu]

This patch is to add get_irq_info callback for platform implementation
to convert irq remapping request to irq info (E,G vector, dest, dest_mode
and so on).

Signed-off-by: Lan Tianyu 
---
 xen/common/viommu.c  | 16 
 xen/include/asm-x86/viommu.h |  8 
 xen/include/xen/viommu.h |  9 +
 3 files changed, 33 insertions(+)

diff --git a/xen/common/viommu.c b/xen/common/viommu.c
index 93a0176..a66237f 100644
--- a/xen/common/viommu.c
+++ b/xen/common/viommu.c
@@ -211,6 +211,22 @@ int viommu_handle_irq_request(struct domain *d, u32 
viommu_id,
 return info->viommu[viommu_id]->ops->handle_irq_request(d, request);
 }
 
+int viommu_get_irq_info(struct domain *d, u32 viommu_id,
+struct irq_remapping_request *request,
+struct irq_remapping_info *irq_info)
+{
+struct viommu_info *info = &d->viommu;
+
+if ( viommu_id >= info->nr_viommu
+ || !info->viommu[viommu_id] )
+return -EINVAL;
+
+if ( !info->viommu[viommu_id]->ops->get_irq_info )
+return -EINVAL;
+
+return info->viommu[viommu_id]->ops->get_irq_info(d, request, irq_info);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-x86/viommu.h b/xen/include/asm-x86/viommu.h
index 51bda72..1e8d4be 100644
--- a/xen/include/asm-x86/viommu.h
+++ b/xen/include/asm-x86/viommu.h
@@ -27,6 +27,14 @@
 #define VIOMMU_REQUEST_IRQ_MSI  0
 #define VIOMMU_REQUEST_IRQ_APIC 1
 
+struct irq_remapping_info
+{
+u8  vector;
+u32 dest;
+u32 dest_mode:1;
+u32 delivery_mode:3;
+};
+
 struct irq_remapping_request
 {
 union {
diff --git a/xen/include/xen/viommu.h b/xen/include/xen/viommu.h
index 83eb69b..6cfcafd 100644
--- a/xen/include/xen/viommu.h
+++ b/xen/include/xen/viommu.h
@@ -32,6 +32,8 @@ struct viommu_ops {
 int (*destroy)(struct viommu *viommu);
 int (*handle_irq_request)(struct domain *d,
   struct irq_remapping_request *request);
+int (*get_irq_info)(struct domain *d, struct irq_remapping_request 
*request,
+struct irq_remapping_info *info);
 };
 
 struct viommu {
@@ -58,6 +60,9 @@ int viommu_domctl(struct domain *d, struct 
xen_domctl_viommu_op *op,
 int viommu_setup(void);
 int viommu_handle_irq_request(struct domain *d, u32 viommu_id,
   struct irq_remapping_request *request);
+int viommu_get_irq_info(struct domain *d, u32 viommu_id, 
+struct irq_remapping_request *request,
+struct irq_remapping_info *irq_info);
 #else
 static inline int viommu_init_domain(struct domain *d) { return 0; }
 static inline int viommu_register_type(u64 type, struct viommu_ops * ops)
@@ -71,6 +76,10 @@ static inline int viommu_domctl(struct domain *d,
 static inline int viommu_handle_irq_request(struct domain *d, u32 viommu_id,
   struct irq_remapping_request *request)
 { return 0 };
+static inline int viommu_get_irq_info(struct domain *d, u32 viommu_id,
+  struct irq_remapping_request *request,
+  struct irq_remapping_info *irq_info)
+{ return 0 };
 #endif
 
 #endif /* __XEN_VIOMMU_H__ */
-- 
1.8.3.1


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

[Xen-devel] [PATCH 5/25] Xen/doc: Add Xen virtual IOMMU doc

[Lan Tianyu]

This patch is to add Xen virtual IOMMU doc to introduce motivation,
framework, vIOMMU hypercall and xl configuration.

Signed-off-by: Lan Tianyu 
---
 docs/misc/viommu.txt | 129 +++
 1 file changed, 129 insertions(+)
 create mode 100644 docs/misc/viommu.txt

diff --git a/docs/misc/viommu.txt b/docs/misc/viommu.txt
new file mode 100644
index 000..76d4cee
--- /dev/null
+++ b/docs/misc/viommu.txt
@@ -0,0 +1,129 @@
+Xen virtual IOMMU
+
+Motivation
+==
+*) Enable more than 255 vcpu support
+HPC cloud service requires VM provides high performance parallel
+computing and we hope to create a huge VM with >255 vcpu on one machine
+to meet such requirement. Pin each vcpu to separate pcpus.
+
+To support >255 vcpus, X2APIC mode in guest is necessary because legacy
+APIC(XAPIC) just supports 8-bit APIC ID and it only can support 255
+vcpus at most. X2APIC mode supports 32-bit APIC ID and it requires
+interrupt mapping function of vIOMMU.
+
+The reason for this is that there is no modification to existing PCI MSI
+and IOAPIC with the introduction of X2APIC. PCI MSI/IOAPIC can only send
+interrupt message containing 8-bit APIC ID, which cannot address >255
+cpus. Interrupt remapping supports 32-bit APIC ID and so it's necessary
+to enable >255 cpus with x2apic mode.
+
+
+vIOMMU Architecture
+===
+vIOMMU device model is inside Xen hypervisor for following factors
+1) Avoid round trips between Qemu and Xen hypervisor
+2) Ease of integration with the rest of hypervisor
+3) HVMlite/PVH doesn't use Qemu
+
+* Interrupt remapping overview.
+Interrupts from virtual devices and physical devices are delivered
+to vLAPIC from vIOAPIC and vMSI. vIOMMU needs to remap interrupt during
+this procedure.
+
++---+
+|Qemu   |VM |
+|   | ++|
+|   | |  Device driver ||
+|   | ++---+|
+|   |  ^|
+|   ++  | ++---+|
+|   | Virtual device |  | |  IRQ subsystem ||
+|   +---++  | ++---+|
+|   |   |  ^|
+|   |   |  ||
++---+---+
+|hyperviosr |  | VIRQ   |
+|   |+-++   |
+|   ||  vLAPIC  |   |
+|   |VIRQ+-++   |
+|   |  ^|
+|   |  ||
+|   |+-++   |
+|   ||  vIOMMU  |   |
+|   |+-++   |
+|   |  ^|
+|   |  ||
+|   |+-++   |
+|   ||   vIOAPIC/vMSI   |   |
+|   |++++   |
+|   | ^^|
+|   +-+||
+|  ||
++---+
+HW |IRQ
++---+
+|   PCI Device  |
++---+
+
+
+vIOMMU hypercall
+
+Introduce new domctl hypercall "xen_domctl_viommu_op" to create/destroy
+vIOMMU and query vIOMMU capabilities that device model can support.
+
+* vIOMMU hypercall parameter structure
+struct xen_domctl_viommu_op {
+uint32_t cmd;
+#define XEN_DOMCTL_create_viommu  0
+#define XEN_DOMCTL_destroy_viommu 1
+#define XEN_DOMCTL_query_viommu_caps  2
+union {
+struct {
+/* IN - vIOMMU type */
+uint64_t viommu_type;
+/* IN - MMIO base address of vIOMMU. */
+uint64_t base_address;
+/* IN - Length of MMIO region */
+uint64_t length;
+/* IN - Capabilities with which we want to create */
+uint64_t capabilities;
+/* OUT - vIOMMU identity */
+uint32_t viommu_id;
+} create_viommu;
+
+struct {
+/* IN - vIOMMU identity */
+uint32_t viommu_id;
+} destroy_viommu;
+
+struct {
+/* IN - vIOMMU type */
+uint64_t viommu_type;
+/* OUT - vIOMMU Capabilities */
+uint64_t caps;
+} query_caps;
+} u;
+};
+
+- XEN_DOMCTL_query_viommu_caps
+Query capabilities of vIOMMU device model. vIOMMU_type specifies
+which vendor vIOMMU device model(E,G Intel

[Xen-devel] [PATCH 1/25] VIOMMU: Add vIOMMU helper functions to create, destroy and query capabilities

[Lan Tianyu]

This patch is to introduct an abstract layer for arch vIOMMU implementation
to deal with requests from dom0. Arch vIOMMU code needs to provide callback
to perform create, destroy and query capabilities operation.

Signed-off-by: Lan Tianyu 
---
 xen/arch/x86/setup.c|   1 +
 xen/common/Kconfig  |  12 
 xen/common/Makefile |   1 +
 xen/common/domain.c |   3 +
 xen/common/viommu.c | 163 
 xen/include/public/viommu.h |  49 +
 xen/include/xen/sched.h |   2 +
 xen/include/xen/viommu.h|  71 +++
 8 files changed, 302 insertions(+)
 create mode 100644 xen/common/viommu.c
 create mode 100644 xen/include/public/viommu.h
 create mode 100644 xen/include/xen/viommu.h

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index f7b9278..f204d71 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1513,6 +1513,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 early_msi_init();
 
 iommu_setup();/* setup iommu if available */
+viommu_setup();
 
 smp_prepare_cpus(max_cpus);
 
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index dc8e876..8ba4f5a 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -73,6 +73,18 @@ config TMEM
 
  If unsure, say Y.
 
+config VIOMMU
+   def_bool y
+   depends on X86
+   ---help---
+ Virtual IOMMU provides interrupt remapping function for guest and
+ it allows guest to boot up more than 255 vcpus which requires 
interrupt
+ remapping function.
+
+ You also have to enable it on the Xen commandline by using viommu=1
+
+ If unsure, say Y.
+
 config XENOPROF
def_bool y
prompt "Xen Oprofile Support" if EXPERT = "y"
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 26c5a64..852553d 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -56,6 +56,7 @@ obj-y += time.o
 obj-y += timer.o
 obj-y += trace.o
 obj-y += version.o
+obj-$(CONFIG_VIOMMU) += viommu.o
 obj-y += virtual_region.o
 obj-y += vm_event.o
 obj-y += vmap.o
diff --git a/xen/common/domain.c b/xen/common/domain.c
index b22aacc..d1f9b10 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -396,6 +396,9 @@ struct domain *domain_create(domid_t domid, unsigned int 
domcr_flags,
 spin_unlock(&domlist_update_lock);
 }
 
+if ( (err = viommu_init_domain(d)) != 0 )
+goto fail;
+
 return d;
 
  fail:
diff --git a/xen/common/viommu.c b/xen/common/viommu.c
new file mode 100644
index 000..19ba529
--- /dev/null
+++ b/xen/common/viommu.c
@@ -0,0 +1,163 @@
+/*
+ * common/viommu.c
+ * 
+ * Copyright (c) 2017 Intel Corporation
+ * Author: Lan Tianyu  
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 
+
+bool_t __read_mostly opt_viommu = 0;
+boolean_param("viommu", opt_viommu);
+
+spinlock_t type_list_lock;
+static struct list_head type_list;
+
+struct viommu_type {
+u64 type;
+struct viommu_ops *ops;
+struct list_head node;
+};
+
+int viommu_init_domain(struct domain *d)
+{
+d->viommu.nr_viommu = 0;
+return 0;
+}
+
+static struct viommu_type *viommu_get_type(u64 type)
+{
+struct viommu_type *viommu_type = NULL;
+
+spin_lock(&type_list_lock);
+list_for_each_entry( viommu_type, &type_list, node )
+{
+if ( viommu_type->type == type )
+{
+spin_unlock(&type_list_lock);
+return viommu_type;
+}
+}
+spin_unlock(&type_list_lock);
+
+return NULL;
+}
+
+int viommu_register_type(u64 type, struct viommu_ops * ops)
+{
+struct viommu_type *viommu_type = NULL;
+
+if ( !viommu_enabled() )
+return -EINVAL;
+
+if ( viommu_get_type(type) )
+return -EEXIST;
+
+viommu_type = xzalloc(struct viommu_type);
+if ( !viommu_type )
+return -ENOMEM;
+
+viommu_type->type = type;
+viommu_type->ops = ops;
+
+spin_lock(&type_list_lock);
+list_add_tail(&viommu_type->node, &type_list);
+spin_unlock(&type_list_lock);
+
+return 0;
+}
+
+static int viommu_create(struct domain *d, u64 type, u64 base_address,
+  u64 length, u64 caps)
+{
+struct viommu_info *info = &d->viommu;
+struct viommu *viommu;
+struct viommu_type *viommu_type = NULL;
+int rc;
+
+viommu_type = viommu_get_type(type);
+if ( !viommu_type

[Xen-devel] [PATCH 8/25] Tools/libacpi: Add new fields in acpi_config to build DMAR table

[Lan Tianyu]

From: Chao Gao 

The BIOS reports the remapping hardware units in a platform to system software
through the DMA Remapping Reporting (DMAR) ACPI table.

To build DMAR table during domain construction, two fields are added to struct
acpi_config. One is dmar_flag which indicates whether interrupt remapping is
supported and whether enabling X2APIC mode is premitted. The other is the base
address of remapping hardware register-set for a remapping unit. Also, a
function construct_dmar() is added to build DMAR table according the two
fields.

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
 tools/libacpi/build.c   | 53 +
 tools/libacpi/libacpi.h | 11 ++
 2 files changed, 64 insertions(+)

diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
index f9881c9..d5bedfd 100644
--- a/tools/libacpi/build.c
+++ b/tools/libacpi/build.c
@@ -28,6 +28,10 @@
 
 #define ACPI_MAX_SECONDARY_TABLES 16
 
+#define VTD_HOST_ADDRESS_WIDTH 39
+#define I440_PSEUDO_BUS_PLATFORM 0xff
+#define I440_PSEUDO_DEVFN_IOAPIC 0x0
+
 #define align16(sz)(((sz) + 15) & ~15)
 #define fixed_strcpy(d, s) strncpy((d), (s), sizeof(d))
 
@@ -303,6 +307,55 @@ static struct acpi_20_slit *construct_slit(struct 
acpi_ctxt *ctxt,
 return slit;
 }
 
+struct acpi_dmar *construct_dmar(struct acpi_ctxt *ctxt,
+ const struct acpi_config *config)
+{
+struct acpi_dmar *dmar;
+struct acpi_dmar_hardware_unit *drhd;
+struct dmar_device_scope *scope;
+unsigned int size;
+unsigned int ioapic_scope_size = sizeof(*scope) + sizeof(scope->path[0]);
+
+size = sizeof(*dmar) + sizeof(*drhd) + ioapic_scope_size;
+
+dmar = ctxt->mem_ops.alloc(ctxt, size, 16);
+if ( !dmar )
+return NULL;
+
+memset(dmar, 0, size);
+dmar->header.signature = ACPI_2_0_DMAR_SIGNATURE;
+dmar->header.revision = ACPI_2_0_DMAR_REVISION;
+dmar->header.length = size;
+fixed_strcpy(dmar->header.oem_id, ACPI_OEM_ID);
+fixed_strcpy(dmar->header.oem_table_id, ACPI_OEM_TABLE_ID);
+dmar->header.oem_revision = ACPI_OEM_REVISION;
+dmar->header.creator_id   = ACPI_CREATOR_ID;
+dmar->header.creator_revision = ACPI_CREATOR_REVISION;
+dmar->host_address_width = VTD_HOST_ADDRESS_WIDTH - 1;
+dmar->flags = config->dmar_flag & (DMAR_INTR_REMAP|DMAR_X2APIC_OPT_OUT);
+
+drhd = (struct acpi_dmar_hardware_unit *)((void*)dmar + sizeof(*dmar));
+drhd->type = ACPI_DMAR_TYPE_HARDWARE_UNIT;
+drhd->length = sizeof(*drhd) + ioapic_scope_size;
+drhd->flags = ACPI_DMAR_INCLUDE_PCI_ALL;
+drhd->pci_segment = 0;
+drhd->address = config->viommu_base_addr;
+
+scope = &drhd->scope[0];
+scope->type = ACPI_DMAR_DEVICE_SCOPE_IOAPIC;
+scope->length = ioapic_scope_size;
+/*
+ * This field provides the I/O APICID as provided in the I/O APIC structure
+ * in the ACPI MADT (Multiple APIC Descriptor Table).
+ */
+scope->enumeration_id = 1;
+scope->bus = I440_PSEUDO_BUS_PLATFORM;
+scope->path[0] = I440_PSEUDO_DEVFN_IOAPIC;
+
+set_checksum(dmar, offsetof(struct acpi_header, checksum), size);
+return dmar;
+}
+
 static int construct_passthrough_tables(struct acpi_ctxt *ctxt,
 unsigned long *table_ptrs,
 int nr_tables,
diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
index 2ed1ecf..6a4e1cf 100644
--- a/tools/libacpi/libacpi.h
+++ b/tools/libacpi/libacpi.h
@@ -20,6 +20,8 @@
 #ifndef __LIBACPI_H__
 #define __LIBACPI_H__
 
+#include "acpi2_0.h"
+
 #define ACPI_HAS_COM1  (1<<0)
 #define ACPI_HAS_COM2  (1<<1)
 #define ACPI_HAS_LPT1  (1<<2)
@@ -36,6 +38,7 @@
 #define ACPI_HAS_8042  (1<<13)
 #define ACPI_HAS_CMOS_RTC  (1<<14)
 #define ACPI_HAS_SSDT_LAPTOP_SLATE (1<<15)
+#define ACPI_HAS_DMAR  (1<<16)
 
 struct xen_vmemrange;
 struct acpi_numa {
@@ -96,8 +99,16 @@ struct acpi_config {
 uint32_t ioapic_base_address;
 uint16_t pci_isa_irq_mask;
 uint8_t ioapic_id;
+
+/* dmar info */
+uint8_t dmar_flag;
+uint64_t viommu_base_addr;
 };
 
+#define DMAR_INTR_REMAP 0x1
+#define DMAR_X2APIC_OPT_OUT 0x2
+struct acpi_dmar *construct_dmar(struct acpi_ctxt *ctxt,
+ const struct acpi_config *config);
 int acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config);
 
 #endif /* __LIBACPI_H__ */
-- 
1.8.3.1


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