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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 59254
 test-amd64-amd64-xl-credit2  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-i386-xl-xsm   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-i386-xl   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate   fail REGR. vs. 59254
 test-amd64-amd64-pair23 guest-stop/src_host   fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-pair   22 guest-migrate/dst_host/src_host fail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck  6 xen-bootfail REGR. vs. 59254
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 17 guest-localmigrate/x10fail REGR. vs. 59254
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline 
untested
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline 
untested
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-amd64-amd64-libvirt 15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2  fail blocked in 59254
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 linux6b5f04b6cf8ebab9a65d9c0026c650bb2538fd0f
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  255 days
Failing since 59348  2015-07-10 04:24:05 Z  254 days  182 attempts
Testing same since86626  2016-03-19 04:26:49 Z1 days1 attempts


4570 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm   

[Xen-devel] [qemu-mainline baseline-only test] 44256: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl  19 guest-start/debian.repeatfail   like 44251
 test-amd64-amd64-xl-xsm  19 guest-start/debian.repeatfail   like 44251
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 44251
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail like 44251

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuud1f8764099022bc1173f2413331b26d4ff609a0c
baseline version:
 qemuua6cdb77f816961f929d7934643febd2852230135

Last test of basis44251  2016-03-16 13:50:52 Z1 days
Testing same since44256  2016-03-18 07:19:53 Z0 days1 attempts


People who touched revisions under test:
  Alex Williamson 
  Alexey Kardashevskiy 
  Andrew Baumann 
  Andrew Jeffery 
  Benjamin Herrenschmidt 
  Christian Borntraeger 
  Daniel P. Berrange 
  David Gibson 
  Edgar E. Iglesias 
  Greg Kurz 
  Grégory ESTRADE 
  Jean-Christophe Dubois 
  Jens Wiklander 
  Markus Armbruster 
  Michael Roth 
  Michael S. Tsirkin 
  Paolo Bonzini 
  Pavel Dovgalyuk 
  Peter Maydell 
  Rita Sinha 
  Sascha Silbe 
  Sergey Sorokin 
  Thomas Huth 
  Wei Huang 

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

Re: [Xen-devel] [PATCH 1/2] IOMMU/MMU: Adjust top level functions for VT-d Device-TLB flush error.

[Xu, Quan]

On March 17, 2016 8:30pm,  wrote:
> On Thu, Mar 17, 2016 at 6:54 AM, Quan Xu  wrote:
> > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index
> > c997b53..526548e 100644
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -2467,7 +2467,7 @@ static int __get_page_type(struct page_info *page,
> unsigned long type,
> > int preemptible)  {
> >  unsigned long nx, x, y = page->u.inuse.type_info;
> > -int rc = 0;
> > +int rc = 0, ret = 0;
> >
> >  ASSERT(!(type & ~(PGT_type_mask | PGT_pae_xen_l2)));
> >
> > @@ -2578,11 +2578,11 @@ static int __get_page_type(struct page_info
> *page, unsigned long type,
> >  if ( d && is_pv_domain(d) && unlikely(need_iommu(d)) )
> >  {
> >  if ( (x & PGT_type_mask) == PGT_writable_page )
> > -iommu_unmap_page(d, mfn_to_gmfn(d,
> page_to_mfn(page)));
> > +ret = iommu_unmap_page(d, mfn_to_gmfn(d,
> page_to_mfn(page)));
> >  else if ( type == PGT_writable_page )
> > -iommu_map_page(d, mfn_to_gmfn(d,
> page_to_mfn(page)),
> > -   page_to_mfn(page),
> > -
> IOMMUF_readable|IOMMUF_writable);
> > +ret = iommu_map_page(d, mfn_to_gmfn(d,
> page_to_mfn(page)),
> > + page_to_mfn(page),
> > +
> IOMMUF_readable|IOMMUF_writable);
> >  }
> >  }
> >
> > @@ -2599,6 +2599,9 @@ static int __get_page_type(struct page_info *page,
> unsigned long type,
> >  if ( (x & PGT_partial) && !(nx & PGT_partial) )
> >  put_page(page);
> >
> > +if ( !rc )
> > +rc = ret;
> > +
> 
> What's this about?  If the iommu_[un]map_page() operation times out,
> we still go through with calling alloc_page_type(); and if
> alloc_page_type() fails we return its failure value, but if it
> succeeds, we return the error from iommu_[un]map_page()?
> 
Yes.
To be honest, to me, it is tricky too. 
I found it is not right to return directly if the iommu_[un]map_page() 
operation times out.

 """if ( d && is_pv_domain(d) && unlikely(need_iommu(d)) )"""
Does IOMMU support pv domain? If not, we'd better remove the " if(...){...}"

Quan


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

[Xen-devel] [libvirt test] 86369: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  26f3d9c26ccc8e380ef9e1e9a8df51aa7c2387d2
baseline version:
 libvirt  95ca4fe2f272d1c751acd278cc1617fe2aa1b94b

Last test of basis86026  2016-03-12 04:21:44 Z4 days
Failing since 86280  2016-03-15 04:24:21 Z1 days2 attempts
Testing same since86369  2016-03-16 04:23:38 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Cole Robinson 
  Dmitry Andreev 
  Jim Fehlig 
  John Ferlan 
  Maxim Nestratov 
  Michal Privoznik 

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



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

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

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

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


Pushing revision :

+ branch=libvirt
+ revision=26f3d9c26ccc8e380ef9e1e9a8df51aa7c2387d2
+ . ./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
++ 

Re: [Xen-devel] [PATCH 2/8] libxl: Remove redundant setting of phyical-device

[Ian Jackson]

George Dunlap writes ("[PATCH 2/8] libxl: Remove redundant setting of 
phyical-device"):
> Regardless of whether we're running a custom hotplug script or using
> normal phy: or file:, the "block" script will be run, which will set
> all the necessary xenstore nodes.
> 
> In fact, writing this value here prevents the block script from
> accomplishing its only purpose: to detect duplicate physical block
> devices used in different virtual devices.  The first thing the block
> script does is check to see if this node is written; and if it is, it
> silently exits.
> 
> Remove this, and let the block script perform its duplicate checking
> function.
> 
> Signed-off-by: George Dunlap 
> ---
> NOTE: It's likely that the duplicate checking for physical devices has
> never been run under libxl (at least since this bug was introduced);
> this may shake out some issues.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH v4 03/34] xsm/xen_version: Add XSM for the xen_version hypercall

[Konrad Rzeszutek Wilk]

On Fri, Mar 18, 2016 at 05:55:55AM -0600, Jan Beulich wrote:
> >>> On 15.03.16 at 18:56,  wrote:
> > @@ -223,12 +224,15 @@ void __init do_initcalls(void)
> >  /*
> >   * Simple hypercalls.
> >   */
> > -
> >  DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> 
> Please retain the blank line, as it relates to more than just this
> one function.

Done! (stray change).
> 
> >  {
> > +bool_t deny = !!xsm_xen_version(XSM_OTHER, cmd);
> > +
> >  switch ( cmd )
> >  {
> >  case XENVER_version:
> > +if ( deny )
> > +return 0;
> >  return (xen_major_version() << 16) | xen_minor_version();
> 
> To be honest, I'm now rather uncertain about this one: If a guest
> can't figure out the hypervisor version, how would it be able to
> adjust its behavior accordingly (e.g. use deprecated hypercalls as
> needed)? IOW, other than for most/all other stuff here (the
> get-features and platform-parameters sub-ops may be considered
> similar to this one, see also below), I don't think allowing the
> "permitted" default to be overridden makes sense here.

I don't want to crash old guests or lead them astray. Removed the 'deny' here.
Also removed the XSM checks for this sub-op (and the others below)
as they are ignored.
> 
> > @@ -274,6 +279,9 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) 
> > arg)
> >  .virt_start = HYPERVISOR_VIRT_START
> >  };
> >  
> > +if ( deny )
> > +params.virt_start = 0;
> 
> Guests may (validly imo) assume to get a valid address here. If you
> mean to not expose the non-constant address in the compat mode
> case, I could accept that. But you would then need to set the ABI
> mandated __HYPERVISOR_COMPAT_VIRT_START (and retain the
> constant value in the non-compat case). Our old 32-bit PV guests
> would crash extremely early on boot if they got back zero here
> (that's for 2.6.30 and later, and I think both you and Citrix had
> derived some of their kernels from our 2.6.32 based one).

OK. Let me also relax this one and always return a value.
> 
> > @@ -302,6 +310,8 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) 
> > arg)
> >  switch ( fi.submap_idx )
> >  {
> >  case 0:
> > +if ( deny )
> > +break;
> 
> I think if to be put here at all, this should go ahead of the switch(),

I am OK not acking on the XSM check. It really throws a wrench in Linux
(upstream Linux hangs when initializing the XenBus frontend driver).

> so that guests wouldn't be able to guess from the valid index values
> which features may be available. And of course you should clear
> fi.submap if you deny access, instead of leaving in it what has been
> there before.
> 
> >  case XENVER_guest_handle:
> > -if ( copy_to_guest(arg, current->domain->handle,
> > -   ARRAY_SIZE(current->domain->handle)) )
> > +{
> > +xen_domain_handle_t hdl;
> > +ssize_t len;
> > +
> > +if ( deny )
> > +{
> > +len = sizeof(hdl);
> > +memset(, 0, len);
> > +} else
> > +len = ARRAY_SIZE(current->domain->handle);
> > +
> > +if ( copy_to_guest(arg, deny ? hdl : current->domain->handle, len 
> > ) )
> >  return -EFAULT;
> >  return 0;
> 
> What is this "len" handling here about? Aren't both the same type
> and hence size? Perhaps, if you feel unsure about that, simply add
> a respective BUILD_BUG_ON()?

Yes they are. Used a BUILD_BUG_ON just in case somebody mucks
around.
> 
> > --- a/xen/include/xen/version.h
> > +++ b/xen/include/xen/version.h
> > @@ -12,5 +12,5 @@ unsigned int xen_minor_version(void);
> >  const char *xen_extra_version(void);
> >  const char *xen_changeset(void);
> >  const char *xen_banner(void);
> > -
> > +const char *xen_deny(void);
> >  #endif /* __XEN_VERSION_H__ */
> 
> Please retain the blank line.

Yes. 
> 
> Jan
> 

Inline is what the patch now looks like:

From 0d5d62a9f15b8306e0c62fb00af193a733af435c Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Fri, 11 Mar 2016 21:40:43 -0500
Subject: [PATCH] xsm/xen_version: Add XSM for most of xen_version hypercall

Most of XENVER_* have now an XSM check for their sub-ops.

The subop for XENVER_commandline is now a priviliged operation.
To not break guests we still return an string - but it is
just '\0'.

The XENVER_[version|parameters|get_features] - will always
return an value to the guest.

The rest: XENVER_[extraversion|capabilities|page_size|
guest_handle|changeset| compile_info] behave as before -
allowed by default for all guests if using the XSM default
policy or with the dummy one. And if the system admin
wants to curtail access to some of them - they can do
that now with a non-default XSM policy.

Also we add a local variable block.

Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Daniel De Graaf 

Re: [Xen-devel] [PATCH v11 19/27] COLO: introduce new API to prepare/start/do/get_error/stop replication

[Changlong Xie]

On 03/05/2016 01:29 AM, Ian Jackson wrote:

Changlong Xie writes ("[PATCH v11 19/27] COLO: introduce new API to 
prepare/start/do/get_error/stop replication"):

From: Wen Congyang 

We will use qemu block replication, and qemu provides some qmp commands
to prepare replication, start replication, get replication error, and
stop replication. Introduce new API to execute these qmp commands.


Also, my comments about needing to see the status of the corresponding
Qemu upstream patches, apply here too.


Yes, the lastest version is V16.

http://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg02623.html

Thanks
-Xie



Thanks,
Ian.


.





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

Re: [Xen-devel] [PATCH 1/3] libxl: make libxl__need_xenpv_qemu() operate on domain config

[Juergen Gross]

On 17/03/16 17:53, George Dunlap wrote:
> On Thu, Mar 10, 2016 at 3:00 PM, Juergen Gross  wrote:
>> libxl__need_xenpv_qemu() is called with configuration data for console,
>> vfbs, disks and channels today in order to evaluate the need for
>> starting a device model for a pv domain.
>>
>> The console data is local to the caller and setup in a way to never
>> require a device model. All other data is taken from the domain config
>> structure.
>>
>> In order to support other device backends via qemu change the interface
>> of libxl__need_xenpv_qemu() to take the domain config structure as
>> input instead of the single device arrays.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>>  tools/libxl/libxl_create.c   |  9 +--
>>  tools/libxl/libxl_dm.c   | 59 
>> 
>>  tools/libxl/libxl_internal.h |  5 +---
>>  3 files changed, 18 insertions(+), 55 deletions(-)
>>
>> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
>> index 61b5c01..0e2b0a0 100644
>> --- a/tools/libxl/libxl_create.c
>> +++ b/tools/libxl/libxl_create.c
>> @@ -1304,7 +1304,6 @@ static void domcreate_launch_dm(libxl__egc *egc, 
>> libxl__multidev *multidev,
>>  }
>>  case LIBXL_DOMAIN_TYPE_PV:
>>  {
>> -int need_qemu = 0;
>>  libxl__device_console console;
>>  libxl__device device;
>>
>> @@ -1314,17 +1313,11 @@ static void domcreate_launch_dm(libxl__egc *egc, 
>> libxl__multidev *multidev,
>>  }
>>
>>  init_console_info(gc, , 0);
>> -
>> -need_qemu = libxl__need_xenpv_qemu(gc, 1, ,
>> -d_config->num_vfbs, d_config->vfbs,
>> -d_config->num_disks, _config->disks[0],
>> -d_config->num_channels, _config->channels[0]);
>> -
>>  console.backend_domid = state->console_domid;
>>  libxl__device_console_add(gc, domid, , state, );
>>  libxl__device_console_dispose();
>>
>> -if (need_qemu) {
>> +if (libxl__need_xenpv_qemu(gc, d_config)) {
>>  dcs->dmss.dm.guest_domid = domid;
>>  libxl__spawn_local_dm(egc, >dmss.dm);
>>  return;
>> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
>> index 4aca38e..4b840f4 100644
>> --- a/tools/libxl/libxl_dm.c
>> +++ b/tools/libxl/libxl_dm.c
>> @@ -2107,61 +2107,34 @@ int libxl__destroy_device_model(libxl__gc *gc, 
>> uint32_t domid)
>>  GCSPRINTF("/local/domain/%d/image/device-model-pid", 
>> domid));
>>  }
>>
>> -int libxl__need_xenpv_qemu(libxl__gc *gc,
>> -int nr_consoles, libxl__device_console *consoles,
>> -int nr_vfbs, libxl_device_vfb *vfbs,
>> -int nr_disks, libxl_device_disk *disks,
>> -int nr_channels, libxl_device_channel *channels)
>> +int libxl__need_xenpv_qemu(libxl__gc *gc, libxl_domain_config *d_config)
>>  {
>> -int i, ret = 0;
>> +int i, ret;
>>  uint32_t domid;
>>
>> -/*
>> - * qemu is required in order to support 2 or more consoles. So switch 
>> all
>> - * backends to qemu if this is the case
>> - */
>> -if (nr_consoles > 1) {
>> -for (i = 0; i < nr_consoles; i++)
>> -consoles[i].consback = LIBXL__CONSOLE_BACKEND_IOEMU;
>> +ret = libxl__get_domid(gc, );
>> +if (ret) goto out;
> 
> Doesn't this mean that if libxl__get_domid() fails,
> libxl__need_xenpv_qemu() will effectively return "true"?
> 
> I realize this is a bug in the existing code but there's no need to be
> bug-for-bug compatible here. :-)
> 
> Maybe add an 'rc' variable, and make this:
> 
> rc = libxl__get_domid();
> if(rc) goto out;

Okay, will do (next week).

> 
> Other than that, looks good to me.

Thanks,

Juergen


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

Re: [Xen-devel] [PATCH 2/2] tools: detect appropriate debug optimization level

[Doug Goldstein]

On 3/8/16 10:50 AM, Wei Liu wrote:
> On Tue, Mar 08, 2016 at 10:34:42AM -0600, Doug Goldstein wrote:
>> On 3/8/16 9:38 AM, Wei Liu wrote:
>>> On Mon, Mar 07, 2016 at 08:23:40PM -0600, Doug Goldstein wrote:
 The build should not use -O0 as that results in miscompilations. There
>>>
>>> This needs some (concrete) references. Is that a known issue in gcc? If
>>> so can you reference the bug number?
>>
>> So its not really a bug in GCC but just the complete lack of
>> optimizations in play. inlines aren't inlined. dead code elimination
>> isn't run so things are much bigger. structures aren't padded the same way.
>>
> 
> Urgh...
> 
>> This came about from reading reports on the -devel and -user's ML that
>> were solved by building Xen with debug=n. I was also striving to reduce
>> the duplication of CFLAGS that are passed on the command line of builds.
>>
> 
> I agree this is a good idea.
> 
>>>
 have been a few instances on the ML where users were told to switch
 from -O0 to -O1 or -O2 or to set debug=n and their issue went away. The
 preferred route should be to use -Og if its available, otherwise use
 -O1 which is the default. This change undoes the change from -O1 to -O0
>>>
>>> gcc manual says -O0 is the default.
>>
>> I wasn't clear about where the 'the default' came from. That's the
>> default in the Xen tree (see: config/StdGNU.mk for example but every
>> platform has -O1 set).
>>
> 
> OK. I thought you're talking about something in the manual.
> 
>>>
>>> Not that I disagree with this patch in general, but the commit message
>>> seems a bit misleading.
>>
>> I can rewrite it. I'd also be willing to change the patch to prefer -Og
>> if its available and use -O0 if its not.
>>
> 
> No need to do it now because ...
> 
>>>
 in 1166ecf781b1016eaa61f8d5ba4fb1fde9d599b6.

>>>
>>> And I have no idea why -O1 confuses the debugger so I've CC'ed Euan for
>>> more input.
>>
>> -O1 can optimize things out when you look at them with gdb but -Og is
>> suppose to do the right thing.
>>
> 
> .. I don't know much about gcc so I would like to wait for Ian to give
> some input.
> 
> Wei.
> 
>>>
 Signed-off-by: Doug Goldstein 
 ---
 CC: Ian Jackson 
 CC: Stefano Stabellini 
 CC: Wei Liu 
 ---
  tools/Rules.mk | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/tools/Rules.mk b/tools/Rules.mk
 index 9ef0b47..ae6b01f 100644
 --- a/tools/Rules.mk
 +++ b/tools/Rules.mk
 @@ -137,7 +137,8 @@ SHLIB_libxenvchan  = $(SHDEPS_libxenvchan) 
 -Wl,-rpath-link=$(XEN_LIBVCHAN)
  
  ifeq ($(debug),y)
  # Disable optimizations and enable debugging information for macros
 -CFLAGS += -O0 -g3
 +$(call cc-option-add,CFLAGS,CC,-Og)
 +CFLAGS += -g3
  # But allow an override to -O0 in case Python enforces 
 -D_FORTIFY_SOURCE=.
  PY_CFLAGS += $(PY_NOOPT_CFLAGS)
  endif
 -- 
 2.4.10

>>
>>
>> -- 
>> Doug Goldstein
>>
> 
> 
> 

ping?


-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen/x86: Remap text/data/bss with appropriate permissions

[Jan Beulich]

>>> On 17.03.16 at 13:43,  wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -529,9 +529,33 @@ static void noinline init_done(void)
>  }
>  else
>  {
> +/* Mark .text as RX (avoiding the first 2M superpage). */
> +map_pages_to_xen(XEN_VIRT_START + MB(2),
> + PFN_DOWN(__pa(XEN_VIRT_START + MB(2))),
> + PFN_DOWN(__2M_text_end -
> +  (const char *)(XEN_VIRT_START + MB(2))),
> + PAGE_HYPERVISOR_RX);
> +
> +/* Mark .rodata as RO. */
> +map_pages_to_xen((unsigned long)&__2M_rodata_start,
> + PFN_DOWN(__pa(__2M_rodata_start)),
> + PFN_DOWN(__2M_rodata_end - __2M_rodata_start),
> + PAGE_HYPERVISOR_RO);
> +
> +/* Free and reuse .init. */
>  destroy_xen_mappings((unsigned long)&__init_begin,
>   (unsigned long)&__init_end);
>  init_xenheap_pages(__pa(__init_begin), __pa(__init_end));
> +
> +/* Mark .data and .bss as RW. */
> +map_pages_to_xen((unsigned long)&__2M_rwdata_start,
> + PFN_DOWN(__pa(__2M_rwdata_start)),
> + PFN_DOWN(__2M_rwdata_end - __2M_rwdata_start),
> + PAGE_HYPERVISOR_RW);
> +
> +/* Drop the remaining mappings in the shattered superpage. */
> +destroy_xen_mappings((unsigned long)&__2M_rwdata_end,
> + ROUNDUP((unsigned long)&__2M_rwdata_end, 
> MB(2)));
>  }

I think this would be more appropriate to add to some __init
function (which the discarding of .init.* naturally can't live in).

Also - do we really want to make this code dependent on
map_pages_to_xen() not intermediately zapping the mappings
being changed?

Jan


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

[Xen-devel] [PATCH v2 2/6] x86/mm/pat: Add pat_disable() interface

[Toshi Kani]

In preparation to fix a regression caused by 'commit 9cd25aac1f44
("x86/mm/pat: Emulate PAT when it is disabled")', PAT needs to
provide an interface that disables the OS to initialize PAT MSR.

PAT MSR initialization must be done on all CPUs with the specific
sequence of operations defined in Intel SDM.  This requires MTRR
to be enabled since pat_init() is called as part of MTRR init
from mtrr_rendezvous_handler().

Change pat_disable() as the interface to disable the OS to initialize
PAT MSR, and set PAT table with pat_keep_handoff_state().  This
interface can be called when PAT initialization may not be performed.

This also assures that pat_disable() called from pat_bsp_init()
to set PAT table properly when CPU does not support PAT.

Signed-off-by: Toshi Kani 
Cc: Borislav Petkov 
Cc: Luis R. Rodriguez 
Cc: Juergen Gross 
Cc: Robert Elliott 
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: Thomas Gleixner 
---
 arch/x86/include/asm/pat.h |1 +
 arch/x86/mm/pat.c  |   21 ++---
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/pat.h b/arch/x86/include/asm/pat.h
index ca6c228..016142b 100644
--- a/arch/x86/include/asm/pat.h
+++ b/arch/x86/include/asm/pat.h
@@ -5,6 +5,7 @@
 #include 
 
 bool pat_enabled(void);
+void pat_disable(const char *reason);
 extern void pat_init(void);
 void pat_init_cache_modes(u64);
 
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index e0a34b0..48d1619 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -40,11 +40,26 @@
 static bool boot_cpu_done;
 
 static int __read_mostly __pat_enabled = IS_ENABLED(CONFIG_X86_PAT);
+static void pat_keep_handoff_state(void);
 
-static inline void pat_disable(const char *reason)
+/**
+ * pat_disable() - Disable the OS to initialize PAT MSR
+ *
+ * This function disables the OS to initialize PAT MSR, and calls
+ * pat_keep_handoff_state() to set PAT table to the handoff state.
+ */
+void pat_disable(const char *reason)
 {
+   if (boot_cpu_done) {
+   pr_err("x86/PAT: PAT cannot be disabled after initialization "
+  "(attempting: %s)\n", reason);
+   return;
+   }
+
__pat_enabled = 0;
pr_info("x86/PAT: %s\n", reason);
+
+   pat_keep_handoff_state();
 }
 
 static int __init nopat(char *str)
@@ -202,7 +217,7 @@ static void pat_bsp_init(u64 pat)
 {
u64 tmp_pat;
 
-   if (!cpu_has_pat) {
+   if (!boot_cpu_has(X86_FEATURE_PAT)) {
pat_disable("PAT not supported by CPU.");
return;
}
@@ -220,7 +235,7 @@ static void pat_bsp_init(u64 pat)
 
 static void pat_ap_init(u64 pat)
 {
-   if (!cpu_has_pat) {
+   if (!boot_cpu_has(X86_FEATURE_PAT)) {
/*
 * If this happens we are on a secondary CPU, but switched to
 * PAT on the boot CPU. We have no way to undo PAT.

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

Re: [Xen-devel] [PATCH v6] x86/hvm/viridian: Enable APIC assist enlightenment

[Wei Liu]

On Fri, Mar 18, 2016 at 10:32:30AM +, Paul Durrant wrote:
> This patch adds code to enable the APIC assist enlightenment which,
> under certain conditions, means that the guest can avoid an EOI of
> the local APIC and thereby avoid a VMEXIT.
> 
> Use of the enlightenment by the hypervisor is under control of the
> toolstack, and is added to the default set.
> 
> Signed-off-by: Paul Durrant 
> Cc: Ian Jackson 
> Cc: Stefano Stabellini 
> Cc: Wei Liu 
> Cc: Keir Fraser 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
> 
> v6:
>  - Addressed various comments from Jan
> 
> v4:
>  - Re-worded xl.cfg text and added missing LIBXL_HAVE_ definition
> 
> v3:
>  - Re-instated read-modify-write for forwards compatibility
>  - Fix a coding style issue
> 
> v2:
>  - Removed some code duplication and unnecessary read-modify-write
>operations on the APIC assist word.
>  - Stated in the xl.cfg text that the enlightenment has no effect if
>posted interrupts are in use.
>  - Added the enlightenment to the default set.
> ---
>  docs/man/xl.cfg.pod.5  | 12 +++-
>  tools/libxl/libxl.h|  6 
>  tools/libxl/libxl_dom.c|  4 +++
>  tools/libxl/libxl_types.idl|  1 +

Acked-by: Wei Liu 


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

[Xen-devel] [PATCH 2/2] hotplug: Prevent alloc/free of irq descriptors during cpu up/down (again)

[Boris Ostrovsky]

Now that Xen no longer allocates irqs in _cpu_up() we can restore
commit a89941816726 ("hotplug: Prevent alloc/free of irq descriptors
during cpu up/down")

Signed-off-by: Boris Ostrovsky 
---
 arch/x86/kernel/smpboot.c |   11 ---
 kernel/cpu.c  |8 
 2 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 643dbdc..cabe21e 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1083,17 +1083,8 @@ int native_cpu_up(unsigned int cpu, struct task_struct 
*tidle)
 
common_cpu_up(cpu, tidle);
 
-   /*
-* We have to walk the irq descriptors to setup the vector
-* space for the cpu which comes online.  Prevent irq
-* alloc/free across the bringup.
-*/
-   irq_lock_sparse();
-
err = do_boot_cpu(apicid, cpu, tidle);
-
if (err) {
-   irq_unlock_sparse();
pr_err("do_boot_cpu failed(%d) to wakeup CPU#%u\n", err, cpu);
return -EIO;
}
@@ -,8 +1102,6 @@ int native_cpu_up(unsigned int cpu, struct task_struct 
*tidle)
touch_nmi_watchdog();
}
 
-   irq_unlock_sparse();
-
return 0;
 }
 
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 6ea42e8..2ff63b3 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -342,8 +342,16 @@ static int bringup_cpu(unsigned int cpu)
struct task_struct *idle = idle_thread_get(cpu);
int ret;
 
+   /*
+* Some architectures have to walk the irq descriptors to
+* setup the vector space for the cpu which comes online.
+* Prevent irq alloc/free across the bringup.
+*/
+   irq_lock_sparse();
+
/* Arch-specific enabling code. */
ret = __cpu_up(cpu, idle);
+   irq_unlock_sparse();
if (ret) {
cpu_notify(CPU_UP_CANCELED, cpu);
return ret;
-- 
1.7.1


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

Re: [Xen-devel] [PATCH v3 07/28] xen/x86: Annotate special features

[Jan Beulich]

>>> On 15.03.16 at 16:35,  wrote:
> Some bits in a featureset are not simple a indication of new functionality,
> and require special handling.
> 
> APIC, OSXSAVE and OSPKE are fast-forwards of other pieces of state;
> IA32_APIC_BASE.EN, CR4.OSXSAVE and CR4.OSPKE.  Xen will take care of filling
> these appropriately at runtime.
> 
> FDP_EXCP_ONLY and NO_FPU_SEL are bits indicating reduced functionality in 
> the
> x87 pipeline.  The effects of these cannot be hidden from the guest, so the
> host values will always be provided.
> 
> HTT and CMP_LEGACY indicate how to interpret other cpuid leaves.  In most
> cases, the toolstack value will be used (with the expectation that these 
> flags
> will match the other provided topology information).  However with cpuid
> masking, the host values are presented as masking cannot influence what the
> guest sees in the dependent leaves.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 


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

[Xen-devel] [PATCH v6 06/17] Xen: ARM: Add support for mapping platform device mmio

[Shannon Zhao]

From: Shannon Zhao 

Add a bus_notifier for platform bus device in order to map the device
mmio regions when DOM0 booting with ACPI.

Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
---
 drivers/xen/Makefile |   1 +
 drivers/xen/arm-device.c | 141 +++
 2 files changed, 142 insertions(+)
 create mode 100644 drivers/xen/arm-device.c

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 9b7a35c..415f286 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -9,6 +9,7 @@ CFLAGS_features.o   := $(nostackp)
 
 CFLAGS_efi.o   += -fshort-wchar
 
+dom0-$(CONFIG_ARM64) += arm-device.o
 dom0-$(CONFIG_PCI) += pci.o
 dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
 dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
diff --git a/drivers/xen/arm-device.c b/drivers/xen/arm-device.c
new file mode 100644
index 000..76e26e5
--- /dev/null
+++ b/drivers/xen/arm-device.c
@@ -0,0 +1,141 @@
+/*
+ * Copyright (c) 2015, Linaro Limited, Shannon Zhao
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+
+static int xen_unmap_device_mmio(struct resource *resource, unsigned int count)
+{
+   unsigned int i, j, nr;
+   int rc = 0;
+   struct resource *r;
+   struct xen_remove_from_physmap xrp;
+
+   for (i = 0; i < count; i++) {
+   r = [i];
+   nr = DIV_ROUND_UP(resource_size(r), XEN_PAGE_SIZE);
+   if ((resource_type(r) != IORESOURCE_MEM) || (nr == 0))
+   continue;
+
+   for (j = 0; j < nr; j++) {
+   xrp.domid = DOMID_SELF;
+   xrp.gpfn = XEN_PFN_DOWN(r->start) + j;
+   rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap,
+ );
+   if (rc)
+   return rc;
+   }
+   }
+
+   return rc;
+}
+
+static int xen_map_device_mmio(struct resource *resource, unsigned int count)
+{
+   unsigned int i, j, nr;
+   int rc = 0;
+   struct resource *r;
+   xen_pfn_t *gpfns;
+   xen_ulong_t *idxs;
+   int *errs;
+   struct xen_add_to_physmap_range xatp;
+
+   for (i = 0; i < count; i++) {
+   r = [i];
+   nr = DIV_ROUND_UP(resource_size(r), XEN_PAGE_SIZE);
+   if ((resource_type(r) != IORESOURCE_MEM) || (nr == 0))
+   continue;
+
+   gpfns = kzalloc(sizeof(xen_pfn_t) * nr, GFP_KERNEL);
+   idxs = kzalloc(sizeof(xen_ulong_t) * nr, GFP_KERNEL);
+   errs = kzalloc(sizeof(int) * nr, GFP_KERNEL);
+   if (!gpfns || !idxs || !errs) {
+   kfree(gpfns);
+   kfree(idxs);
+   kfree(errs);
+   return -ENOMEM;
+   }
+
+   for (j = 0; j < nr; j++) {
+   gpfns[j] = XEN_PFN_DOWN(r->start) + j;
+   idxs[j] = XEN_PFN_DOWN(r->start) + j;
+   }
+
+   xatp.domid = DOMID_SELF;
+   xatp.size = nr;
+   xatp.space = XENMAPSPACE_dev_mmio;
+
+   set_xen_guest_handle(xatp.gpfns, gpfns);
+   set_xen_guest_handle(xatp.idxs, idxs);
+   set_xen_guest_handle(xatp.errs, errs);
+
+   rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, );
+   kfree(gpfns);
+   kfree(idxs);
+   kfree(errs);
+   if (rc)
+   return rc;
+   }
+
+   return rc;
+}
+
+static int xen_platform_notifier(struct notifier_block *nb,
+unsigned long action, void *data)
+{
+   struct platform_device *pdev = to_platform_device(data);
+   int r = 0;
+
+   if (pdev->num_resources == 0 || pdev->resource == NULL)
+   return NOTIFY_OK;
+
+   switch (action) {
+   case BUS_NOTIFY_ADD_DEVICE:
+   r = xen_map_device_mmio(pdev->resource, pdev->num_resources);
+   break;
+   case BUS_NOTIFY_DEL_DEVICE:
+   r = xen_unmap_device_mmio(pdev->resource, pdev->num_resources);
+   break;
+   

[Xen-devel] [PATCH 2/2] xen/x86: Introduce a new VMASSIST for architectural behaviour of iopl

[Andrew Cooper]

The existing vIOPL interface is hard to use, and need not be.

Introduce a VMASSIST with which a guest can opt-in to having vIOPL behaviour
consistenly with native hardware.

Specifically:
 - virtual iopl updated from do_iret() hypercalls.
 - virtual iopl reported in bounce frames.
 - guest kernels assumed to be level 0 for the purpose of iopl checks.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/domain.c  | 10 +++---
 xen/arch/x86/physdev.c |  2 +-
 xen/arch/x86/traps.c   |  8 ++--
 xen/arch/x86/x86_64/asm-offsets.c  |  3 +++
 xen/arch/x86/x86_64/compat/entry.S |  7 ++-
 xen/arch/x86/x86_64/compat/traps.c |  4 
 xen/arch/x86/x86_64/entry.S|  7 ++-
 xen/arch/x86/x86_64/traps.c|  3 +++
 xen/include/asm-x86/config.h   |  1 +
 xen/include/asm-x86/domain.h   |  3 ++-
 xen/include/public/xen.h   |  8 
 11 files changed, 47 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a6d721b..36b9aaa 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1001,7 +1001,7 @@ int arch_set_info_guest(
 init_int80_direct_trap(v);
 
 /* IOPL privileges are virtualised. */
-v->arch.pv_vcpu.iopl = (v->arch.user_regs.eflags >> 12) & 3;
+v->arch.pv_vcpu.iopl = v->arch.user_regs.eflags & X86_EFLAGS_IOPL;
 v->arch.user_regs.eflags &= ~X86_EFLAGS_IOPL;
 
 /* Ensure real hardware interrupts are enabled. */
@@ -1742,8 +1742,10 @@ static void load_segments(struct vcpu *n)
 cs_and_mask = (unsigned short)regs->cs |
 ((unsigned int)vcpu_info(n, evtchn_upcall_mask) << 16);
 /* Fold upcall mask into RFLAGS.IF. */
-eflags  = regs->_eflags & ~X86_EFLAGS_IF;
+eflags  = regs->_eflags & ~(X86_EFLAGS_IF|X86_EFLAGS_IOPL);
 eflags |= !vcpu_info(n, evtchn_upcall_mask) << 9;
+if ( VM_ASSIST(n->domain, architectural_iopl) )
+eflags |= n->arch.pv_vcpu.iopl;
 
 if ( !ring_1(regs) )
 {
@@ -1788,8 +1790,10 @@ static void load_segments(struct vcpu *n)
 ((unsigned long)vcpu_info(n, evtchn_upcall_mask) << 32);
 
 /* Fold upcall mask into RFLAGS.IF. */
-rflags  = regs->rflags & ~X86_EFLAGS_IF;
+rflags  = regs->rflags & ~(X86_EFLAGS_IF|X86_EFLAGS_IOPL);
 rflags |= !vcpu_info(n, evtchn_upcall_mask) << 9;
+if ( VM_ASSIST(n->domain, architectural_iopl) )
+rflags |= n->arch.pv_vcpu.iopl;
 
 if ( put_user(regs->ss,rsp- 1) |
  put_user(regs->rsp,   rsp- 2) |
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 1cb9b58..5a49796 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -529,7 +529,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) 
arg)
 if ( set_iopl.iopl > 3 )
 break;
 ret = 0;
-curr->arch.pv_vcpu.iopl = set_iopl.iopl;
+curr->arch.pv_vcpu.iopl = MASK_INSR(set_iopl.iopl, X86_EFLAGS_IOPL);
 break;
 }
 
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 564a107..9754a2f 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1806,7 +1806,9 @@ static int guest_io_okay(
 #define TOGGLE_MODE() if ( user_mode ) toggle_guest_mode(v)
 
 if ( !vm86_mode(regs) &&
- (v->arch.pv_vcpu.iopl >= (guest_kernel_mode(v, regs) ? 1 : 3)) )
+ (MASK_EXTR(v->arch.pv_vcpu.iopl, X86_EFLAGS_IOPL) >=
+  (guest_kernel_mode(v, regs) ?
+   (VM_ASSIST(v->domain, architectural_iopl) ? 0 : 1) : 3)) )
 return 1;
 
 if ( v->arch.pv_vcpu.iobmp_limit > (port + bytes) )
@@ -2367,7 +2369,9 @@ static int emulate_privileged_op(struct cpu_user_regs 
*regs)
 
 case 0xfa: /* CLI */
 case 0xfb: /* STI */
-if ( v->arch.pv_vcpu.iopl < (guest_kernel_mode(v, regs) ? 1 : 3) )
+if ( MASK_EXTR(v->arch.pv_vcpu.iopl, X86_EFLAGS_IOPL) <
+ (guest_kernel_mode(v, regs) ?
+  (VM_ASSIST(v->domain, architectural_iopl) ? 0 : 1) : 3) )
 goto fail;
 /*
  * This is just too dangerous to allow, in my opinion. Consider if the
diff --git a/xen/arch/x86/x86_64/asm-offsets.c 
b/xen/arch/x86/x86_64/asm-offsets.c
index 447c650..fa37ee0 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -86,6 +86,7 @@ void __dummy__(void)
 OFFSET(VCPU_trap_ctxt, struct vcpu, arch.pv_vcpu.trap_ctxt);
 OFFSET(VCPU_kernel_sp, struct vcpu, arch.pv_vcpu.kernel_sp);
 OFFSET(VCPU_kernel_ss, struct vcpu, arch.pv_vcpu.kernel_ss);
+OFFSET(VCPU_iopl, struct vcpu, arch.pv_vcpu.iopl);
 OFFSET(VCPU_guest_context_flags, struct vcpu, arch.vgc_flags);
 OFFSET(VCPU_nmi_pending, struct vcpu, nmi_pending);
 OFFSET(VCPU_mce_pending, struct vcpu, mce_pending);
@@ -166,4 +167,6 @@ void 

Re: [Xen-devel] [PATCH v11 23/27] COLO proxy: preresume, postresume and checkpoint

[Changlong Xie]

On 03/05/2016 02:01 AM, Ian Jackson wrote:

Changlong Xie writes ("[PATCH v11 23/27] COLO proxy: preresume, postresume and 
checkpoint"):

From: Wen Congyang 

preresume, postresume and checkpoint


I think maybe this needs to be combined with the previous patch ?



Surely

Thanks
-Xie


I don't think I quite understand the structure of the patch series at
this point.

Ian.


.





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

[Xen-devel] [PATCH v3 4/4] x86: use 32-bit loads for 32-bit PV guest state reload

[Jan Beulich]

This is slightly more efficient than loading 64-bit quantities.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

--- a/xen/include/asm-x86/asm_defns.h
+++ b/xen/include/asm-x86/asm_defns.h
@@ -313,6 +313,13 @@ static always_inline void stac(void)
 987:
 .endm
 
+#define LOAD_ONE_REG(reg, compat) \
+.if !(compat); \
+movq  UREGS_r##reg(%rsp),%r##reg; \
+.else; \
+movl  UREGS_r##reg(%rsp),%e##reg; \
+.endif
+
 /*
  * Reload registers not preserved by C code from frame.
  *
@@ -326,16 +333,14 @@ static always_inline void stac(void)
 movq  UREGS_r10(%rsp),%r10
 movq  UREGS_r9(%rsp),%r9
 movq  UREGS_r8(%rsp),%r8
-.if \ax
-movq  UREGS_rax(%rsp),%rax
 .endif
-.elseif \ax
-movl  UREGS_rax(%rsp),%eax
+.if \ax
+LOAD_ONE_REG(ax, \compat)
 .endif
-movq  UREGS_rcx(%rsp),%rcx
-movq  UREGS_rdx(%rsp),%rdx
-movq  UREGS_rsi(%rsp),%rsi
-movq  UREGS_rdi(%rsp),%rdi
+LOAD_ONE_REG(cx, \compat)
+LOAD_ONE_REG(dx, \compat)
+LOAD_ONE_REG(si, \compat)
+LOAD_ONE_REG(di, \compat)
 .endm
 
 /*
@@ -372,8 +377,9 @@ static always_inline void stac(void)
 .subsection 0
 #endif
 .endif
-987:movq  UREGS_rbp(%rsp),%rbp
-movq  UREGS_rbx(%rsp),%rbx
+987:
+LOAD_ONE_REG(bp, \compat)
+LOAD_ONE_REG(bx, \compat)
 subq  $-(UREGS_error_code-UREGS_r15+\adj), %rsp
 .endm
 



x86: use 32-bit loads for 32-bit PV guest state reload

This is slightly more efficient than loading 64-bit quantities.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

--- a/xen/include/asm-x86/asm_defns.h
+++ b/xen/include/asm-x86/asm_defns.h
@@ -313,6 +313,13 @@ static always_inline void stac(void)
 987:
 .endm
 
+#define LOAD_ONE_REG(reg, compat) \
+.if !(compat); \
+movq  UREGS_r##reg(%rsp),%r##reg; \
+.else; \
+movl  UREGS_r##reg(%rsp),%e##reg; \
+.endif
+
 /*
  * Reload registers not preserved by C code from frame.
  *
@@ -326,16 +333,14 @@ static always_inline void stac(void)
 movq  UREGS_r10(%rsp),%r10
 movq  UREGS_r9(%rsp),%r9
 movq  UREGS_r8(%rsp),%r8
-.if \ax
-movq  UREGS_rax(%rsp),%rax
 .endif
-.elseif \ax
-movl  UREGS_rax(%rsp),%eax
+.if \ax
+LOAD_ONE_REG(ax, \compat)
 .endif
-movq  UREGS_rcx(%rsp),%rcx
-movq  UREGS_rdx(%rsp),%rdx
-movq  UREGS_rsi(%rsp),%rsi
-movq  UREGS_rdi(%rsp),%rdi
+LOAD_ONE_REG(cx, \compat)
+LOAD_ONE_REG(dx, \compat)
+LOAD_ONE_REG(si, \compat)
+LOAD_ONE_REG(di, \compat)
 .endm
 
 /*
@@ -372,8 +377,9 @@ static always_inline void stac(void)
 .subsection 0
 #endif
 .endif
-987:movq  UREGS_rbp(%rsp),%rbp
-movq  UREGS_rbx(%rsp),%rbx
+987:
+LOAD_ONE_REG(bp, \compat)
+LOAD_ONE_REG(bx, \compat)
 subq  $-(UREGS_error_code-UREGS_r15+\adj), %rsp
 .endm
 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] List of projects for 4.7

[Wei Liu]

Hi all

Today is that last posting day for new features. And we are two weeks
away from the anticipated freeze date.

I've gone through the outstanding patch series on the list and ask for
input from various core community members. I've enumerated a list
here, which covers several areas of this release and can be used as a
guideline.

Important and close patch, new features:
1. xSplice
2. CPUID levelling
3. ARM ACPI
4. COLO HA
5. RTDS per-vcpu parameter setting
6. Event driven RTDS

Important bug fixes:
1. Intel VT-d flush issue
2. SMEP / SMAP fix
3. QEMU hotplug script fix

Note, it is possible for bug fixes to go in after freeze.

Nice to have, not very complicated patch sets:
1. IOREQ server P2M type
2. QEMU-based PVUSB backend
3. Oxenstored improvement
4. Load bios via toolstack

I think it would be good to use the remaining time to focus on things
that are close, important or both.

Thanks
Wei.

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

Re: [Xen-devel] List of projects for 4.7

[Chong Li]

On Fri, Mar 18, 2016 at 7:07 AM, Wei Liu  wrote:
> Hi all
>
> Today is that last posting day for new features. And we are two weeks
> away from the anticipated freeze date.
>
> I've gone through the outstanding patch series on the list and ask for
> input from various core community members. I've enumerated a list
> here, which covers several areas of this release and can be used as a
> guideline.
>
> Important and close patch, new features:
> 1. xSplice
> 2. CPUID levelling
> 3. ARM ACPI
> 4. COLO HA
> 5. RTDS per-vcpu parameter setting

The current status:
1) patch for xen: The "mentioning a bug fixed" issue
2) patch for libxc: Acked-by: Wei Liu; Reviewed-by: Dario Faggioli
3) patch for libxl: Acked-by: Wei Liu
4) patch for xl: More examples need to be added to man page

Chong


-- 
Chong Li
Department of Computer Science and Engineering
Washington University in St.louis

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

Re: [Xen-devel] [PATCH 7/8] docs: Document block-script protocol

[Jim Fehlig]

On 03/16/2016 10:09 AM, George Dunlap wrote:
> Signed-off-by: George Dunlap 
> ---
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Roger Pau Monne 
> ---
>  docs/misc/block-scripts.txt | 100 
> 
>  1 file changed, 100 insertions(+)
>
> diff --git a/docs/misc/block-scripts.txt b/docs/misc/block-scripts.txt
> new file mode 100644
> index 000..ef19207
> --- /dev/null
> +++ b/docs/misc/block-scripts.txt
> @@ -0,0 +1,100 @@
> +Block scripts
> +=
> +
> +Block scripts are called at the moment anytime blkback is directly
> +involved in providing access to a backend.  There are three general
> +cases this happens:
> +
> +1. When a user passes a block device in the 'target' field of the disk
> +specification
> +
> +2. When a user passes a file in the 'target' field of the disk
> +specification
> +
> +3. When a user specifies a custom script.
> +
> +Setup
> +-
> +
> +It is highly recommended that custom scripts as much as possible
> +include and use the common Xen functionality.  If the script is run
> +from the normal block script location (/etc/xen/scripts by default),
> +then this can be done by adding the following to the top of the
> +script:
> +
> +dir=$(dirname "$0")
> +. "$dir/block-common.sh"
> +
> +
> +Inputs
> +--
> +
> +In all cases, the scripts are called with either "add" or "remove" as
> +the command.  For custom scripts, the command will be the first
> +argument of the script (i.e. $1).
> +
> +The environment variable XENBUS_PATH will be set to the
> +path for the block device to be created.
> +
> +When the script is run, the following nodes shall already have been
> +written into xenstore:
> +
> + $XENBUS/paramsThe contents of the 'target' section of the disk 
> specification verbatim.
> + $XENBUS/mode  'r' (for readonly) or 'w' (for read-write)
> +
> +Output
> +---
> +
> +Block scripts are responsible for making sure that if a file is
> +provided to a VM read/write, that it is not provided to any other VM.
> +
> +FreeBSD block hotplug scripts must write
> +"$XENBUS_PATH/physical-device-path" with the path to the physical
> +device or file.  Linux and NetBSD block hotplug scripts *should* also
> +write this node.
> +
> +For the time being, Linux and NetBSD block hotplug scripts must write
> +"$XENBUS_PATH/physical-device" with the device's major and minor
> +numbers, written in hex, and separated by a colon.
> +
> +Scripts which include block-common.sh can simply call write_dev "$dev"
> +with a path to the device, and write_dev will do the right thing, now
> +and going forward.  (See the discussion below.)
> +
> +Rationale and future work
> +-
> +
> +Historically, the block scripts wrote a node called "physical-device",
> +which contains the major and minor numbers, written in hex, and
> +separated by a colon (e.g., "1a:2").  This is required by the Linux
> +blkback driver.
> +
> +FreeBSD blkback, on the other hand, does not have the concept of
> +major/minor numbers, and can give direct access to a file without
> +going through loopback; so its driver will consume
> +physical-device-path.
> +
> +On Linux, the device model (qemu) needs access to a file it can
> +interpret to provide emulated disks before paravirtualized drivers are
> +marked as up.  The easiest way to accomplish this is to allow qemu to
> +consume physical-device-path (rather than, say, having dom0 act as
> +both a frontend and a backend).
> +
> +Going forward, the plan is at some point to have all block scripts
> +simply write "physical-device-path", and then have libxl write the
> +other nodes.  The reason we haven't done this yet is that the main
> +block script wants to check to make sure the *major/minor* number
> +hasn't been re-used, rather than just checking that the *specific
> +device node* isn't re-used.  To do this it currently uses
> +physical-device; and to do this *safely* it needs physical-device to
> +be written with the lock held.
> +
> +The simplest solution for sorting this out would be to have the block
> +script use physical-device if it's present, but if not, to directly
> +stat physical-device-path.  But there's not time before the 4.7
> +release to make sure all that works.
> +
> +Another possibility would be to do away with the block scripts
> +altogether when not actually running any scripts,

Just to clarify, do you mean drop support for all block scripts?

>  and do the duplicate
> +checking inside of libxl.  The rationale for doing this in block
> +scripts rather than in libxl isn't clear at thes point.

Block scripts like block-iscsi and block-drbd also "cook" $XENBUS/params into
$XENBUS_PATH/physical-device{,-path} right?

Regards,
Jim

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

Re: [Xen-devel] [PATCH 15/16] xen: sched: scratch space for cpumasks on Credit2

[Andrew Cooper]

On 18/03/16 19:06, Dario Faggioli wrote:
> like what's there already in both Credit1 and RTDS. In
> fact, when playing with affinity, a lot of cpumask
> manipulation is necessary, inside of various functions.
>
> To avoid having a lot of cpumask_var_t on the stack,
> this patch introduces a global scratch area.
>
> Signed-off-by: Dario Faggioli 
> ---
> Cc: George Dunlap 
> ---

I would suggest instead going with

static DEFINE_PER_CPU(cpumask_t, csched2_cpumask_scratch);

Functions which want to use it can use

cpumask_t *scratch = _cpu(csched2_cpumask_scratch);


This avoids all this opencoded allocation/refcounting, the chance that
starting a scheduler would fail for memory reasons, and one extra
cpumask in the per-cpu data area won't break the bank.

~Andrew

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

Re: [Xen-devel] [SeaBIOS] Xen PV block device support in Seabios

[Gerd Hoffmann]

  Hi,

> > Ian, thanks for your reply! It looks like the problem is how and when to
> > clear PV resources in seabios before handing over to guest. But I wonder
> > why virtio works in seabios. Does seabios using virtio need to clear
> > things like vrings? Or seabios doesn't clear the things and guest just
> > covers the configuration with new values?
> 
> I think virtio covered this use case from day 1 by having the reset,

That is correct.  First thing the kernel driver does as part of the
initialization sequence is a reset, to put the device into a known
state, no matter where seabios left it off.

Oh, and of course seabios does the same.  So even in case the virtio
device is in some weird state due to kernel crashing and rebooting
seabios will be able to boot from it without any problems.

cheers,
  Gerd


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

[Xen-devel] [PATCH 0/8] tools: Allow HVM domains emulated access to disks provided by hotplug scripts

[George Dunlap]

In order for HVM domains to provide emulated access to disks provided
by hotplug scripts, qemu needs access to a "cooked" version of the
disk.  In the case of hotplug scripts, this "cooked" version is
available in the form of a block device passed to blkback.  Make this
"cooked" version available to qemu.

This series also starts to work towards a rationalized interface to
the block hotplug scripts, on which hotplug scripts for FreeBSD can be
added.


George Dunlap (7):
  tools/hotplug: Add a "dummy" hotplug script for testing
  libxl: Remove redundant setting of phyical-device
  tools/hotplug: Write physical-device-path in addition to
physical-device
  libxl: Move check for local access to a funciton
  libxl: Share logic for finding path between qemuu and pygrub
  libxl: Allow local access for block devices with hotplug scripts
  docs: Document block-script protocol

Ian Jackson (1):
  DO NOT APPLY libxl: Change hotplug script interface to use
physical-device-path

 docs/misc/block-scripts.txt |  84 
 tools/hotplug/Linux/Makefile|   1 +
 tools/hotplug/Linux/block-common.sh |  16 ++---
 tools/hotplug/Linux/block-dummy | 107 ++
 tools/libxl/libxl.c | 126 +---
 tools/libxl/libxl_dm.c  |  65 ---
 tools/libxl/libxl_internal.h|  11 +++-
 tools/libxl/libxl_linux.c   |  70 +++-
 8 files changed, 407 insertions(+), 73 deletions(-)
 create mode 100644 docs/misc/block-scripts.txt
 create mode 100644 tools/hotplug/Linux/block-dummy

--
CC: Ian Jackson 
CC: Wei Liu 
CC: Roger Pau Monne 


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

[Xen-devel] [linux-3.18 test] 86513: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail   like 85493
 build-i386-rumpuserxen6 xen-buildfail   like 85493
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 85493
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 85493

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

version targeted for testing:
 linuxd439e869d612dd7a338ac75a4afc3646a5e67370
baseline version:
 linux0f67c5beb42a8328e9e661dcfcc4d328b6138264

Last test of basis85493  2016-03-05 20:25:50 Z   12 days
Testing same since86513  2016-03-17 21:21:40 Z0 days1 attempts


People who touched revisions under test:
  Akshay Bhat 
  Al Viro 
  Alex Deucher 
  Alex Williamson 
  Alexandra Yates 
  Andrea Arcangeli 
  Andrew Morton 
  Andrey Skvortsov 
  Andy Lutomirski 
  Arik Nemtsov 
  Arik Nemtsov 
  Arnaldo Carvalho de Melo 
  Arnd Bergmann 
  Barry Grussling 
  Benjamin Coddington 
  Bjørn Mork 
  Catalin Marinas 
  Christian Borntraeger 
  Christian König 
  Christoffer Dall 
  Christoph Hellwig 
  Daniele Palmas 
  Dave Airlie 
  David Henningsson 
  David S. Miller 
  David Vrabel 
  David Woodhouse 

Re: [Xen-devel] [PATCH v5 2/2] x86/hvm/viridian: Enable APIC assist enlightenment

[Jan Beulich]

>>> On 18.03.16 at 11:06,  wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 17 March 2016 16:43
>> >>> On 17.03.16 at 13:13,  wrote:
>> > @@ -1170,10 +1183,27 @@ int vlapic_has_pending_irq(struct vcpu *v)
>> >   !nestedhvm_vcpu_in_guestmode(v) )
>> >  return irr;
>> >
>> > +/*
>> > + * If APIC assist was used then there may have been no EOI so
>> > + * we need to clear the requisite bit from the ISR here, before
>> > + * comparing with the IRR.
>> > + */
>> > +if ( viridian_complete_apic_assist(v, ) &&
>> > + vector != -1 )
>> 
>> Afaict "vector" is uninitialized here when initialize_apic_assist()
>> didn't run for that vCPU yet (which includes the case where no
>> Viridian emulation is active at all).
>> 
> 
> Yes, vector will be uninitialized in that case but viridian 
> _complete_apic_assist() will return 0 (because the va will be zero) and so 
> the second clause of the if will not be evaluated.

Ah, true. But raises the question why viridian_complete_apic_assist()
doesn't return the vector then rather then using indirection.

>> > +/*
>> > + * This vector is edge triggered and there are no lower priority
>> > + * vectors pending, so we can use APIC assist to avoid exiting
>> > + * for EOI.
>> > + */
>> > +viridian_start_apic_assist(v, vector);
>> >
>> > +done:
>> 
>> Labels indented by at least one space please.
> 
> OK, sorry, emacs keeps moving them back.

That's very unfriendly of it.

Jan


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

Re: [Xen-devel] [PATCH] x86/hvm/viridian: fix the TLB flush hypercall

[Andrew Cooper]

On 16/03/16 13:00, Paul Durrant wrote:
> Commit b38d426a "flush remote tlbs by hypercall" add support to allow
> Windows to request flush of remote TLB via hypercall rather than IPI.
> Unfortunately it seems that this code was broken in a couple of ways:
>
> 1) The allocation of the per-vcpu flush mask is gated on whether the
>domain has viridian features enabled but the call to allocate is
>made before the toolstack has enabled those features. This results
>in a NULL pointer dereference.
>
> 2) One of the flush hypercall variants is a rep op, but the code
>does not update the output data with the reps completed. Hence the
>guest will spin repeatedly making the hypercall because it believes
>it has uncompleted reps.
>
> This patch fixes both of these issues and also adds a check to make
> sure the current vCPU is not included in the flush mask (since there's
> clearly no need for the CPU to IPI itself).

Thinking more about this, the asid flush does serve properly for TLB
flushing.  Why do we then subsequently use flush_tlb_mask(), as opposed
to a less heavyweight alternative like smp_send_event_check_mask() ?

~Andrew

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

[Xen-devel] (no subject)

[Safa Hamza]

i'm trying to run xen on omap5 and installing some guests ..  it seems it
works and a xen boot dom0 as shown the screen shot
but with this arago project i can't download any package ..all commands
such as apt-get ,update ... are not found
i tried to have another file system but its not working ..
can you help me .. with which file system can i work
thanks
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 02/14] libxc: Prepare a start info structure for hvmloader

[Boris Ostrovsky]

On 03/15/2016 08:18 PM, Konrad Rzeszutek Wilk wrote:

On Mon, Mar 14, 2016 at 05:55:37PM +, Anthony PERARD wrote:





@@ -624,8 +628,6 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
  
  if ( !dom->device_model )

  {
-size_t start_info_size = sizeof(struct hvm_start_info);
-
  if ( dom->cmdline )
  {
  dom->cmdline_size = ROUNDUP(strlen(dom->cmdline) + 1, 8);
@@ -635,17 +637,26 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
  /* Limited to one module. */
  if ( dom->ramdisk_blob )
  start_info_size += sizeof(struct hvm_modlist_entry);
-
-rc = xc_dom_alloc_segment(dom, >start_info_seg,
-  "HVMlite start info", 0, start_info_size);
-if ( rc != 0 )
-{
-DOMPRINTF("Unable to reserve memory for the start info");
-goto out;
-}
  }
  else
  {
+start_info_size +=
+sizeof(struct hvm_modlist_entry) * HVMLOADER_MODULE_MAX_COUNT;
+/* Add extra space to write modules name */
+start_info_size +=
+HVMLOADER_MODULE_NAME_SIZE * HVMLOADER_MODULE_MAX_COUNT;

What about \0 ? Ah, the strncpy we use adds \0 byte. But it would be nice
to mention that somewhere. Perhaps mention:

The HVMLOADER_MODULE_NAME_SIZE accounts for NUL byte?


+}
+
+rc = xc_dom_alloc_segment(dom, >start_info_seg,
+  "HVMlite start info", 0, start_info_size);
+if ( rc != 0 )
+{
+DOMPRINTF("Unable to reserve memory for the start info");
+goto out;
+}
+
+if ( dom->device_model )
+{



Can you fold this into the 'else' clause above and move 
xc_dom_alloc_segment() down?




+
  static int bootlate_hvm(struct xc_dom_image *dom)
  {
  uint32_t domid = dom->guest_domid;
  xc_interface *xch = dom->xch;
+struct hvm_start_info *start_info;
+size_t start_info_size;
+void *start_page;
+struct hvm_modlist_entry *modlist;
  
-if ( !dom->device_model )

-{
-struct hvm_start_info *start_info;
-size_t start_info_size;
-void *start_page;
-
-start_info_size = sizeof(*start_info) + dom->cmdline_size;
-if ( dom->ramdisk_blob )
-start_info_size += sizeof(struct hvm_modlist_entry);
+start_info_size = sizeof(*start_info) + dom->cmdline_size;
+if ( dom->ramdisk_blob )
+start_info_size += sizeof(struct hvm_modlist_entry);
  
-if ( start_info_size >

- dom->start_info_seg.pages << XC_DOM_PAGE_SHIFT(dom) )
-{
-DOMPRINTF("Trying to map beyond start_info_seg");
-return -1;
-}
+if ( start_info_size >
+ dom->start_info_seg.pages << XC_DOM_PAGE_SHIFT(dom) )
+{
+DOMPRINTF("Trying to map beyond start_info_seg");
+return -1;
+}
  
-start_page = xc_map_foreign_range(xch, domid, start_info_size,

-  PROT_READ | PROT_WRITE,
-  dom->start_info_seg.pfn);
-if ( start_page == NULL )
-{
-DOMPRINTF("Unable to map HVM start info page");
-return -1;
-}
+start_page = xc_map_foreign_range(xch, domid, start_info_size,
+  PROT_READ | PROT_WRITE,
+  dom->start_info_seg.pfn);
+if ( start_page == NULL )
+{
+DOMPRINTF("Unable to map HVM start info page");
+return -1;
+}
  
-start_info = start_page;

+start_info = start_page;
+modlist = start_page + sizeof(*start_info) + dom->cmdline_size;


I think we can drop start_page and use start_info only. They are the 
same, aren't they?


-boris



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

[Xen-devel] [PATCH v6 15/17] ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services

[Shannon Zhao]

From: Shannon Zhao 

When running on Xen hypervisor, runtime services are supported through
hypercall. Add a Xen specific function to initialize runtime services.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 arch/arm/include/asm/xen/xen-ops.h   |  6 ++
 arch/arm/xen/Makefile|  1 +
 arch/arm/xen/efi.c   | 40 
 arch/arm64/include/asm/xen/xen-ops.h |  6 ++
 arch/arm64/xen/Makefile  |  1 +
 drivers/xen/Kconfig  |  2 +-
 6 files changed, 55 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/include/asm/xen/xen-ops.h
 create mode 100644 arch/arm/xen/efi.c
 create mode 100644 arch/arm64/include/asm/xen/xen-ops.h

diff --git a/arch/arm/include/asm/xen/xen-ops.h 
b/arch/arm/include/asm/xen/xen-ops.h
new file mode 100644
index 000..ec154e7
--- /dev/null
+++ b/arch/arm/include/asm/xen/xen-ops.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_XEN_OPS_H
+#define _ASM_XEN_OPS_H
+
+void xen_efi_runtime_setup(void);
+
+#endif /* _ASM_XEN_OPS_H */
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index 1296952..2279521 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1,2 @@
 obj-y  := enlighten.o hypercall.o grant-table.o p2m.o mm.o
+obj-$(CONFIG_XEN_EFI) += efi.o
diff --git a/arch/arm/xen/efi.c b/arch/arm/xen/efi.c
new file mode 100644
index 000..16db419
--- /dev/null
+++ b/arch/arm/xen/efi.c
@@ -0,0 +1,40 @@
+/*
+ * Copyright (c) 2015, Linaro Limited, Shannon Zhao
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+
+/* Set XEN EFI runtime services function pointers. Other fields of struct efi,
+ * e.g. efi.systab, will be set like normal EFI.
+ */
+void __init xen_efi_runtime_setup(void)
+{
+   efi.get_time = xen_efi_get_time;
+   efi.set_time = xen_efi_set_time;
+   efi.get_wakeup_time  = xen_efi_get_wakeup_time;
+   efi.set_wakeup_time  = xen_efi_set_wakeup_time;
+   efi.get_variable = xen_efi_get_variable;
+   efi.get_next_variable= xen_efi_get_next_variable;
+   efi.set_variable = xen_efi_set_variable;
+   efi.query_variable_info  = xen_efi_query_variable_info;
+   efi.update_capsule   = xen_efi_update_capsule;
+   efi.query_capsule_caps   = xen_efi_query_capsule_caps;
+   efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count;
+   efi.reset_system = NULL; /* Functionality provided by Xen. 
*/
+}
+EXPORT_SYMBOL_GPL(xen_efi_runtime_setup);
diff --git a/arch/arm64/include/asm/xen/xen-ops.h 
b/arch/arm64/include/asm/xen/xen-ops.h
new file mode 100644
index 000..ec154e7
--- /dev/null
+++ b/arch/arm64/include/asm/xen/xen-ops.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_XEN_OPS_H
+#define _ASM_XEN_OPS_H
+
+void xen_efi_runtime_setup(void);
+
+#endif /* _ASM_XEN_OPS_H */
diff --git a/arch/arm64/xen/Makefile b/arch/arm64/xen/Makefile
index 74a8d87..8ff8aa9 100644
--- a/arch/arm64/xen/Makefile
+++ b/arch/arm64/xen/Makefile
@@ -1,2 +1,3 @@
 xen-arm-y  += $(addprefix ../../arm/xen/, enlighten.o grant-table.o p2m.o 
mm.o)
 obj-y  := xen-arm.o hypercall.o
+obj-$(CONFIG_XEN_EFI) += $(addprefix ../../arm/xen/, efi.o)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 979a831..f15bb3b 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -275,7 +275,7 @@ config XEN_HAVE_PVMMU
 
 config XEN_EFI
def_bool y
-   depends on X86_64 && EFI
+   depends on (ARM || ARM64 || X86_64) && EFI
 
 config XEN_AUTO_XLATE
def_bool y
-- 
2.0.4



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

[Xen-devel] [PATCH 05/16] xen: sched: move pCPU initialization in an helper

[Dario Faggioli]

That will turn out useful in following patches, where such
code will need to be called more than just once. Create an
helper now, and move the code there, to avoid mixing code
motion and functional changes later.

In Credit2, some style cleanup is also done.

No functional change intended.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
---
 xen/common/sched_credit.c  |   22 +-
 xen/common/sched_credit2.c |   26 --
 2 files changed, 29 insertions(+), 19 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index d4a0f5e..4488d7c 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -542,16 +542,11 @@ csched_alloc_pdata(const struct scheduler *ops, int cpu)
 }
 
 static void
-csched_init_pdata(const struct scheduler *ops, void *pdata, int cpu)
+init_pdata(struct csched_private *prv, struct csched_pcpu *spc, int cpu)
 {
-struct csched_private *prv = CSCHED_PRIV(ops);
-struct csched_pcpu * const spc = pdata;
-unsigned long flags;
-
-/* cpu data needs to be allocated, but STILL uninitialized */
-ASSERT(spc && spc->runq.next == spc->runq.prev && spc->runq.next == NULL);
-
-spin_lock_irqsave(>lock, flags);
+ASSERT(spin_is_locked(>lock));
+/* cpu data needs to be allocated, but STILL uninitialized. */
+ASSERT(spc && spc->runq.next == NULL && spc->runq.prev == NULL);
 
 /* Initialize/update system-wide config */
 prv->credit += prv->credits_per_tslice;
@@ -575,7 +570,16 @@ csched_init_pdata(const struct scheduler *ops, void 
*pdata, int cpu)
 /* Start off idling... */
 BUG_ON(!is_idle_vcpu(curr_on_cpu(cpu)));
 cpumask_set_cpu(cpu, prv->idlers);
+}
 
+static void
+csched_init_pdata(const struct scheduler *ops, void *pdata, int cpu)
+{
+unsigned long flags;
+struct csched_private *prv = CSCHED_PRIV(ops);
+
+spin_lock_irqsave(>lock, flags);
+init_pdata(prv, pdata, cpu);
 spin_unlock_irqrestore(>lock, flags);
 }
 
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index b1642a8..919ca13 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1969,16 +1969,13 @@ static void deactivate_runqueue(struct csched2_private 
*prv, int rqi)
 }
 
 static void
-csched2_init_pdata(const struct scheduler *ops, void *pdata, int cpu)
+init_pdata(struct csched2_private *prv, unsigned int cpu)
 {
 unsigned rqi;
-unsigned long flags;
-struct csched2_private *prv = CSCHED2_PRIV(ops);
 struct csched2_runqueue_data *rqd;
 spinlock_t *old_lock;
 
-spin_lock_irqsave(>lock, flags);
-
+ASSERT(spin_is_locked(>lock));
 ASSERT(!cpumask_test_cpu(cpu, >initialized));
 
 /* Figure out which runqueue to put it in */
@@ -1998,7 +1995,7 @@ csched2_init_pdata(const struct scheduler *ops, void 
*pdata, int cpu)
 BUG();
 }
 
-rqd=prv->rqd + rqi;
+rqd = prv->rqd + rqi;
 
 printk("Adding cpu %d to runqueue %d\n", cpu, rqi);
 if ( ! cpumask_test_cpu(rqi, >active_queues) )
@@ -2008,13 +2005,13 @@ csched2_init_pdata(const struct scheduler *ops, void 
*pdata, int cpu)
 }
 
 /* IRQs already disabled */
-old_lock=pcpu_schedule_lock(cpu);
+old_lock = pcpu_schedule_lock(cpu);
 
 /* Move spinlock to new runq lock.  */
 per_cpu(schedule_data, cpu).schedule_lock = >lock;
 
 /* Set the runqueue map */
-prv->runq_map[cpu]=rqi;
+prv->runq_map[cpu] = rqi;
 
 cpumask_set_cpu(cpu, >idle);
 cpumask_set_cpu(cpu, >active);
@@ -2024,12 +2021,21 @@ csched2_init_pdata(const struct scheduler *ops, void 
*pdata, int cpu)
 
 cpumask_set_cpu(cpu, >initialized);
 
-spin_unlock_irqrestore(>lock, flags);
-
 return;
 }
 
 static void
+csched2_init_pdata(const struct scheduler *ops, void *pdata, int cpu)
+{
+struct csched2_private *prv = CSCHED2_PRIV(ops);
+unsigned long flags;
+
+spin_lock_irqsave(>lock, flags);
+init_pdata(prv, cpu);
+spin_unlock_irqrestore(>lock, flags);
+}
+
+static void
 csched2_free_pdata(const struct scheduler *ops, void *pcpu, int cpu)
 {
 unsigned long flags;


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

Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for 
Xen"):
> So that again leaves unaddressed the question of what you
> imply to do when a guest elects to use such a page as page
> table. I'm afraid any attempt of yours to invent something that
> is not struct page_info will not be suitable for all possible needs.

It is not clear to me whether this is a realistic thing for a guest to
want to do.  Haozhong, maybe you want to consider this aspect.

If you can come up with an argument why it is OK to simply not permit
this, then maybe the recordkeeping requirements can be relaxed ?

Ian.

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

Re: [Xen-devel] [PATCH] xen/x86: Remap text/data/bss with appropriate permissions

[Andrew Cooper]

On 17/03/16 15:32, Jan Beulich wrote:
 On 17.03.16 at 15:44,  wrote:
>> On 17/03/16 14:31, Jan Beulich wrote:
>>> Also - do we really want to make this code dependent on
>>> map_pages_to_xen() not intermediately zapping the mappings
>>> being changed?
>> Do you mean "immediately"?
> No.
>
>> As far as I can tell, it is guaranteed to be safe, even when remapping
>> the code section.  Updates to the live pagetables are using atomic
>> writes, and I didn't spot a point which would end up with a transient
>> non-present mapping.
> But we may, at some point and for whatever reason, come to make
> the function zap the mapping (i.e. clear the present bit), flush, and
> only the re-establish the new mapping.

This change is temporary until I can fix the legacy boot issue and
reintroduce the proper 2M functionality.

If someone in the future wants to change the behaviour of
map_pages_to_xen() then we can reconsider.  However, I think it is
unlikely that this will actually happen at all, and if it ever does, I
hope to have already fixed the 2M alignment and deleted this change.

This change is a big security improvement, and absolutely should be
taken, especially as the current implementation of map_pages_to_xen() is
safe.

~Andrew

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

[Xen-devel] [GRUB2 PATCH v5 3/4 - FOR COMMIT] multiboot2: Do not pass memory maps to image if EFI boot services are enabled

[Daniel Kiper]

If image requested EFI boot services then skip multiboot2 memory maps.
Main reason for not providing maps is because they will likely be
invalid. We do a few allocations after filling them, e.g. for relocator
needs. Usually we do not care as we would have finished boot services.
If we keep boot services then it is easier/safer to not provide maps.
However, if image needs memory maps and they are not provided by bootloader
then it should get itself just before ExitBootServices() call.

Signed-off-by: Daniel Kiper 
Reviewed-by: Konrad Rzeszutek Wilk 
---
v5 - suggestions/fixes:
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).

v3 - suggestions/fixes:
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk and Vladimir 'phcoder' Serbinenko).
---
 grub-core/loader/multiboot_mbi2.c |   71 ++---
 1 file changed, 35 insertions(+), 36 deletions(-)

diff --git a/grub-core/loader/multiboot_mbi2.c 
b/grub-core/loader/multiboot_mbi2.c
index 6c04402..ad1553b 100644
--- a/grub-core/loader/multiboot_mbi2.c
+++ b/grub-core/loader/multiboot_mbi2.c
@@ -390,7 +390,7 @@ static grub_size_t
 grub_multiboot_get_mbi_size (void)
 {
 #ifdef GRUB_MACHINE_EFI
-  if (!efi_mmap_size)
+  if (!keep_bs && !efi_mmap_size)
 find_efi_mmap_size ();
 #endif
   return 2 * sizeof (grub_uint32_t) + sizeof (struct multiboot_tag)
@@ -755,12 +755,13 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
   }
   }
 
-  {
-struct multiboot_tag_mmap *tag = (struct multiboot_tag_mmap *) ptrorig;
-grub_fill_multiboot_mmap (tag);
-ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
-  / sizeof (grub_properly_aligned_t);
-  }
+  if (!keep_bs)
+{
+  struct multiboot_tag_mmap *tag = (struct multiboot_tag_mmap *) ptrorig;
+  grub_fill_multiboot_mmap (tag);
+  ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+   / sizeof (grub_properly_aligned_t);
+}
 
   {
 struct multiboot_tag_elf_sections *tag
@@ -776,18 +777,19 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
   / sizeof (grub_properly_aligned_t);
   }
 
-  {
-struct multiboot_tag_basic_meminfo *tag
-  = (struct multiboot_tag_basic_meminfo *) ptrorig;
-tag->type = MULTIBOOT_TAG_TYPE_BASIC_MEMINFO;
-tag->size = sizeof (struct multiboot_tag_basic_meminfo); 
+  if (!keep_bs)
+{
+  struct multiboot_tag_basic_meminfo *tag
+   = (struct multiboot_tag_basic_meminfo *) ptrorig;
+  tag->type = MULTIBOOT_TAG_TYPE_BASIC_MEMINFO;
+  tag->size = sizeof (struct multiboot_tag_basic_meminfo);
 
-/* Convert from bytes to kilobytes.  */
-tag->mem_lower = grub_mmap_get_lower () / 1024;
-tag->mem_upper = grub_mmap_get_upper () / 1024;
-ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
-   / sizeof (grub_properly_aligned_t);
-  }
+  /* Convert from bytes to kilobytes.  */
+  tag->mem_lower = grub_mmap_get_lower () / 1024;
+  tag->mem_upper = grub_mmap_get_upper () / 1024;
+  ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+   / sizeof (grub_properly_aligned_t);
+}
 
   {
 struct grub_net_network_level_interface *net;
@@ -886,27 +888,24 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
 grub_efi_uintn_t efi_desc_size;
 grub_efi_uint32_t efi_desc_version;
 
-tag->type = MULTIBOOT_TAG_TYPE_EFI_MMAP;
-tag->size = sizeof (*tag) + efi_mmap_size;
-
 if (!keep_bs)
-  err = grub_efi_finish_boot_services (_mmap_size, tag->efi_mmap, NULL,
-  _desc_size, _desc_version);
-else
   {
-   if (grub_efi_get_memory_map (_mmap_size, (void *) tag->efi_mmap,
-NULL,
-_desc_size, _desc_version) <= 0)
- err = grub_error (GRUB_ERR_IO, "couldn't retrieve memory map");
+   tag->type = MULTIBOOT_TAG_TYPE_EFI_MMAP;
+   tag->size = sizeof (*tag) + efi_mmap_size;
+
+   err = grub_efi_finish_boot_services (_mmap_size, tag->efi_mmap, 
NULL,
+_desc_size, _desc_version);
+
+   if (err)
+ return err;
+
+   tag->descr_size = efi_desc_size;
+   tag->descr_vers = efi_desc_version;
+   tag->size = sizeof (*tag) + efi_mmap_size;
+
+   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+ / sizeof (grub_properly_aligned_t);
   }
-if (err)
-  return err;
-tag->descr_size = efi_desc_size;
-tag->descr_vers = efi_desc_version;
-tag->size = sizeof (*tag) + efi_mmap_size;
-
-ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
-  / sizeof (grub_properly_aligned_t);
   }
 
   if (keep_bs)
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH v7 for Xen 4.7 2/4] libxc: enable per-VCPU parameter settings for RTDS scheduler

[Wei Liu]

On Wed, Mar 16, 2016 at 11:47:49AM -0500, Chong Li wrote:
> Add xc_sched_rtds_vcpu_get/set functions to interact with
> Xen to get/set a domain's per-VCPU parameters.
> 
> Signed-off-by: Chong Li 
> Signed-off-by: Meng Xu 
> Signed-off-by: Sisu Xi 

Acked-by: Wei Liu 

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

[Xen-devel] [OSSTEST PATCH 4/6] mg-debian-installer-update: Print a TftpDiVersion_$suite setting too

[Ian Jackson]

The human running this script might want to update a suite-specific
value, or the global value.  Print an example of the suite-specific
value too.

No functional change other than to example config output.

Signed-off-by: Ian Jackson 
---
 mg-debian-installer-update |1 +
 1 file changed, 1 insertion(+)

diff --git a/mg-debian-installer-update b/mg-debian-installer-update
index c969f1e..0d4f772 100755
--- a/mg-debian-installer-update
+++ b/mg-debian-installer-update
@@ -178,4 +178,5 @@ if [ x$tftpdiversion = xcurrent ]; then
 fi
 
 echo "TftpDiVersion $date"
+echo "TftpDiVersion_$suite $date"
 echo >&2 "downloaded $dstroot/$dst"
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH v4 08/34] vmap: Make the while loop less fishy.

[Ian Jackson]

Konrad Rzeszutek Wilk writes ("[PATCH v4 08/34] vmap: Make the while loop less 
fishy."):
>   error:
> -while ( i-- )
> -free_domheap_page(mfn_to_page(mfn_x(mfn[i])));
> +while ( i )
> +free_domheap_page(mfn_to_page(mfn_x(mfn[--i])));

I quite strongly dislike this.  It is good practice to keep the loop
control code together where this is reasonably convenient.

I wouldn't quibble on such a stylistic matter (particularly outside my
bailiwick) but (a) I would like to reinforce Jan's position and
(b) it seems worth writing an email as there will be many occurrences.

Ian.

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

Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

[Jan Beulich]

>>> On 17.03.16 at 09:58,  wrote:
> On 03/16/16 09:23, Jan Beulich wrote:
>> >>> On 16.03.16 at 15:55,  wrote:
>> > On 03/16/16 08:23, Jan Beulich wrote:
>> >> >>> On 16.03.16 at 14:55,  wrote:
>> >> > On 03/16/16 07:16, Jan Beulich wrote:
>> >> >> And
>> >> >> talking of fragmentation - how do you mean to track guest
>> >> >> permissions for an unbounded number of address ranges?
>> >> >>
>> >> > 
>> >> > In this case range structs in iomem_caps for NVDIMMs may consume a lot
>> >> > of memory, so I think they are another candidate that should be put in
>> >> > the reserved area on NVDIMM. If we only allow to grant access
>> >> > permissions to NVDIMM page by page (rather than byte), the number of
>> >> > range structs for each NVDIMM in the worst case is still decidable.
>> >> 
>> >> Of course the permission granularity is going to by pages, not
>> >> bytes (or else we couldn't allow the pages to be mapped into
>> >> guest address space). And the limit on the per-domain range
>> >> sets isn't going to be allowed to be bumped significantly, at
>> >> least not for any of the existing ones (or else you'd have to
>> >> prove such bumping can't be abused).
>> > 
>> > What is that limit? the total number of range structs in per-domain
>> > range sets? I must miss something when looking through 'case
>> > XEN_DOMCTL_iomem_permission' of do_domctl() and didn't find that
>> > limit, unless it means alloc_range() will fail when there are lots of
>> > range structs.
>> 
>> Oh, I'm sorry, that was a different set of range sets I was
>> thinking about. But note that excessive creation of ranges
>> through XEN_DOMCTL_iomem_permission is not a security issue
>> just because of XSA-77, i.e. we'd still not knowingly allow a
>> severe increase here.
>>
> 
> I didn't notice that multiple domains can all have access permission
> to an iomem range, i.e. there can be multiple range structs for a
> single iomem range. If range structs for NVDIMM are put on NVDIMM,
> then there would be still a huge amount of them on NVDIMM in the worst
> case (maximum number of domains * number of NVDIMM pages).
> 
> A workaround is to only allow a range of NVDIMM pages be accessed by a
> single domain. Whenever we add the access permission of NVDIMM pages
> to a domain, we also remove the permission from its current
> grantee. In this way, we only need to put 'number of NVDIMM pages'
> range structs on NVDIMM in the worst case.

But will this work? There's a reason multiple domains are permitted
access: The domain running qemu for the guest, for example,
needs to be able to access guest memory.

No matter how much you and others are opposed to this, I can't
help myself thinking that PMEM regions should be treated like RAM
(and hence be under full control of Xen), whereas PBLK regions
could indeed be treated like MMIO (and hence partly be under the
control of Dom0).

Jan


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

[Xen-devel] [PATCH] tools/xenstore-watch: Add new timeout parameter

[Razvan Cojocaru]

This patch allows xenstore-watch to exit even if no changes to its
XenStore key have occured in a specified interval (in seconds), via
a new -T parameter.

Signed-off-by: Razvan Cojocaru 
---
 tools/xenstore/xenstore_client.c | 64 ++--
 1 file changed, 48 insertions(+), 16 deletions(-)

diff --git a/tools/xenstore/xenstore_client.c b/tools/xenstore/xenstore_client.c
index 3d14d37..2873b71 100644
--- a/tools/xenstore/xenstore_client.c
+++ b/tools/xenstore/xenstore_client.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -99,7 +100,7 @@ usage(enum mode mode, int incl_mode, const char *progname)
errx(1, "Usage: %s %s[-h] [-u] [-r] [-s] key ", 
progname, mstr);
 case MODE_watch:
mstr = incl_mode ? "watch " : "";
-   errx(1, "Usage: %s %s[-h] [-n NR] key", progname, mstr);
+   errx(1, "Usage: %s %s[-h] [-n NR] [-T TIMEOUT] key", progname, mstr);
 }
 }
 
@@ -273,27 +274,49 @@ do_chmod(char *path, struct xs_permissions *perms, int 
nperms, int upto,
 }
 
 static void
-do_watch(struct xs_handle *xsh, int max_events)
+do_watch(struct xs_handle *xsh, int max_events, int timeout)
 {
-int count = 0;
+int rc, ms_timeout = timeout * 1000;
 char **vec = NULL;
+struct pollfd fd;
 
-for ( count = 0; max_events == -1 || count < max_events; count++ ) {
-   unsigned int num;
+fd.fd = xs_fileno(xsh);
+fd.events = POLLIN | POLLERR;
 
-   vec = xs_read_watch(xsh, );
-   if (vec == NULL)
-   continue;
+do {
+rc = poll(, 1, 100);
 
-   printf("%s\n", vec[XS_WATCH_PATH]);
-   fflush(stdout);
-   free(vec);
-}
+if (rc == 0 || (rc < 0 && errno == EINTR)) {
+ms_timeout -= 100;
+continue;
+}
+
+if (rc < 0) {
+err(1, "poll() failed: %s", strerror(errno));
+return;
+}
+
+if (fd.revents & POLLIN) {
+unsigned int num;
+
+--max_events;
+vec = xs_read_watch(xsh, );
+
+if (vec == NULL)
+continue;
+
+printf("%s\n", vec[XS_WATCH_PATH]);
+fflush(stdout);
+free(vec);
+}
+
+} while ((ms_timeout > 0 || timeout == -1) && max_events > 0);
 }
 
 static int
 perform(enum mode mode, int optind, int argc, char **argv, struct xs_handle 
*xsh,
-xs_transaction_t xth, int prefix, int tidy, int upto, int recurse, int 
nr_watches)
+xs_transaction_t xth, int prefix, int tidy, int upto, int recurse, int 
nr_watches,
+int timeout)
 {
 switch (mode) {
 case MODE_ls:
@@ -461,7 +484,7 @@ perform(enum mode mode, int optind, int argc, char **argv, 
struct xs_handle *xsh
 if (!xs_watch(xsh, w, w))
 errx(1, "Unable to add watch on %s\n", w);
 }
-do_watch(xsh, nr_watches);
+do_watch(xsh, nr_watches, timeout);
 }
 }
 }
@@ -505,6 +528,7 @@ main(int argc, char **argv)
 int upto = 0;
 int recurse = 0;
 int nr_watches = -1;
+int timeout = -1;
 int transaction;
 struct winsize ws;
 enum mode mode;
@@ -539,10 +563,11 @@ main(int argc, char **argv)
{"upto",0, 0, 'u'}, /* MODE_chmod */
{"recurse", 0, 0, 'r'}, /* MODE_chmod */
{"number",  1, 0, 'n'}, /* MODE_watch */
+   {"timeout", 1, 0, 'T'}, /* MODE_watch */
{0, 0, 0, 0}
};
 
-   c = getopt_long(argc - switch_argv, argv + switch_argv, "hfspturn:",
+   c = getopt_long(argc - switch_argv, argv + switch_argv, "hfspturn:T:",
long_options, );
if (c == -1)
break;
@@ -593,6 +618,12 @@ main(int argc, char **argv)
else
usage(mode, switch_argv, argv[0]);
break;
+   case 'T':
+   if ( mode == MODE_watch )
+   timeout = atoi(optarg);
+   else
+   usage(mode, switch_argv, argv[0]);
+   break;
}
 }
 
@@ -646,7 +677,8 @@ again:
errx(1, "couldn't start transaction");
 }
 
-ret = perform(mode, optind, argc - switch_argv, argv + switch_argv, xsh, 
xth, prefix, tidy, upto, recurse, nr_watches);
+ret = perform(mode, optind, argc - switch_argv, argv + switch_argv, xsh, 
xth, prefix, tidy, upto, recurse,
+  nr_watches, timeout);
 
 if (transaction && !xs_transaction_end(xsh, xth, ret)) {
if (ret == 0 && errno == EAGAIN) {
-- 
1.9.1


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

Re: [Xen-devel] [PATCH v4 01/34] compat/x86: Remove unncessary #define.

[Konrad Rzeszutek Wilk]

On Wed, Mar 16, 2016 at 05:08:30AM -0600, Jan Beulich wrote:
> >>> On 15.03.16 at 18:56,  wrote:
> > It is not used.
> 
> Consistently please - either keep them all (just to cover the case
> that they might get used) or remove them all: xen_compile_info,
> xen_changeset_info, etc are all unused too. Otoh
> xennmi_callback is used, but xennmi_callback_t isn't. Which to me
> suggests that we should leave this alone.

Oddly enough taking an cleaver to it was OK.

From 7e3ed6faed6e083f27ad6be947ac528c3eaba9a1 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Wed, 2 Mar 2016 12:50:32 -0500
Subject: [PATCH v4 02/35] compat/x86: Remove unncessary #defines.

They are not used.

Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Andrew Cooper 

---
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 

v2: Remove a lot more of them.
---
---
 xen/common/compat/kernel.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/xen/common/compat/kernel.c b/xen/common/compat/kernel.c
index df93fdd..dc898ae 100644
--- a/xen/common/compat/kernel.c
+++ b/xen/common/compat/kernel.c
@@ -18,30 +18,22 @@ asm(".file \"" __FILE__ "\"");
 
 extern xen_commandline_t saved_cmdline;
 
-#define xen_extraversion compat_extraversion
 #define xen_extraversion_t compat_extraversion_t
 
-#define xen_compile_info compat_compile_info
 #define xen_compile_info_t compat_compile_info_t
 
 CHECK_TYPE(capabilities_info);
 
-#define xen_platform_parameters compat_platform_parameters
 #define xen_platform_parameters_t compat_platform_parameters_t
 #undef HYPERVISOR_VIRT_START
 #define HYPERVISOR_VIRT_START HYPERVISOR_COMPAT_VIRT_START(current->domain)
 
-#define xen_changeset_info compat_changeset_info
 #define xen_changeset_info_t compat_changeset_info_t
 
-#define xen_feature_info compat_feature_info
 #define xen_feature_info_t compat_feature_info_t
 
 CHECK_TYPE(domain_handle);
 
-#define xennmi_callback compat_nmi_callback
-#define xennmi_callback_t compat_nmi_callback_t
-
 #ifdef COMPAT_VM_ASSIST_VALID
 #undef VM_ASSIST_VALID
 #define VM_ASSIST_VALID COMPAT_VM_ASSIST_VALID
-- 
2.5.0


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

[Xen-devel] [PATCH 1/2] xen/x86: Don't hold TRAPBOUNCE_flags in %cl during create_bounce_frame

[Andrew Cooper]

TRAPBOUNCE_flags are always available via a displacement from %rdx.  This
allows all of %rcx to be used as a scratch register.

No functional change.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
---
 xen/arch/x86/x86_64/compat/entry.S | 5 ++---
 xen/arch/x86/x86_64/entry.S| 5 ++---
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/x86_64/compat/entry.S 
b/xen/arch/x86/x86_64/compat/entry.S
index 927439d..36a8eae 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -263,11 +263,10 @@ compat_create_bounce_frame:
 movl  UREGS_rsp+8(%rsp),%esi
 .Lft4:  mov   UREGS_ss+8(%rsp),%fs
 2:
-movb  TRAPBOUNCE_flags(%rdx),%cl
 subl  $3*4,%esi
 movq  VCPU_vcpu_info(%rbx),%rax
 pushq COMPAT_VCPUINFO_upcall_mask(%rax)
-testb $TBF_INTERRUPT,%cl
+testb $TBF_INTERRUPT,TRAPBOUNCE_flags(%rdx)
 setnz %ch   # TBF_INTERRUPT -> set upcall mask
 orb   %ch,COMPAT_VCPUINFO_upcall_mask(%rax)
 popq  %rax
@@ -284,7 +283,7 @@ compat_create_bounce_frame:
 .Lft6:  movl  %eax,%fs:2*4(%rsi)# EFLAGS
 movl  UREGS_rip+8(%rsp),%eax
 .Lft7:  movl  %eax,%fs:(%rsi)   # EIP
-testb $TBF_EXCEPTION_ERRCODE,%cl
+testb $TBF_EXCEPTION_ERRCODE,TRAPBOUNCE_flags(%rdx)
 jz1f
 subl  $4,%esi
 movl  TRAPBOUNCE_error_code(%rdx),%eax
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index dd7f114..221de01 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -343,7 +343,6 @@ UNLIKELY_START(g, create_bounce_frame_bad_sp)
 lea   UNLIKELY_DISPATCH_LABEL(create_bounce_frame_bad_sp)(%rip), %rdi
 jmp   asm_domain_crash_synchronous  /* Does not return */
 __UNLIKELY_END(create_bounce_frame_bad_sp)
-movb  TRAPBOUNCE_flags(%rdx),%cl
 subq  $40,%rsi
 movq  UREGS_ss+8(%rsp),%rax
 ASM_STAC
@@ -352,7 +351,7 @@ __UNLIKELY_END(create_bounce_frame_bad_sp)
 .Lft3:  movq  %rax,24(%rsi) # RSP
 movq  VCPU_vcpu_info(%rbx),%rax
 pushq VCPUINFO_upcall_mask(%rax)
-testb $TBF_INTERRUPT,%cl
+testb $TBF_INTERRUPT,TRAPBOUNCE_flags(%rdx)
 setnz %ch   # TBF_INTERRUPT -> set upcall mask
 orb   %ch,VCPUINFO_upcall_mask(%rax)
 popq  %rax
@@ -369,7 +368,7 @@ __UNLIKELY_END(create_bounce_frame_bad_sp)
 .Lft5:  movq  %rax,16(%rsi) # RFLAGS
 movq  UREGS_rip+8(%rsp),%rax
 .Lft6:  movq  %rax,(%rsi)   # RIP
-testb $TBF_EXCEPTION_ERRCODE,%cl
+testb $TBF_EXCEPTION_ERRCODE,TRAPBOUNCE_flags(%rdx)
 jz1f
 subq  $8,%rsi
 movl  TRAPBOUNCE_error_code(%rdx),%eax
-- 
2.1.4


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

[Xen-devel] [PATCH v6 05/22] arm/acpi: Prepare MADT table for Dom0

[Shannon Zhao]

From: Shannon Zhao 

Copy main MADT table contents and distributor subtable from physical
ACPI MADT table. Make other subtables through the callback of
gic_hw_ops.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/domain_build.c | 50 +
 1 file changed, 50 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d9b7213..ed257e0 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1357,6 +1357,52 @@ static int prepare_dtb(struct domain *d, struct 
kernel_info *kinfo)
 }
 
 #ifdef CONFIG_ACPI
+static int acpi_create_madt(struct domain *d, struct membank tbl_add[])
+{
+struct acpi_table_header *table = NULL;
+struct acpi_table_madt *madt = NULL;
+struct acpi_subtable_header *header;
+struct acpi_madt_generic_distributor *gicd;
+u32 table_size = sizeof(struct acpi_table_madt);
+u32 offset = acpi_get_table_offset(tbl_add, TBL_MADT);
+acpi_status status;
+u8 *base_ptr, checksum;
+
+status = acpi_get_table(ACPI_SIG_MADT, 0, );
+
+if ( ACPI_FAILURE(status) )
+{
+const char *msg = acpi_format_exception(status);
+
+printk("Failed to get MADT table, %s\n", msg);
+return -EINVAL;
+}
+
+base_ptr = d->arch.efi_acpi_table + offset;
+ACPI_MEMCPY(base_ptr, table, table_size);
+
+/* Add Generic Distributor */
+header = acpi_table_get_entry_madt(ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR, 0);
+if ( !header )
+panic("Can't get GICD entry");
+gicd = container_of(header, struct acpi_madt_generic_distributor, header);
+ACPI_MEMCPY(base_ptr + table_size, gicd,
+sizeof(struct acpi_madt_generic_distributor));
+table_size += sizeof(struct acpi_madt_generic_distributor);
+
+/* Add other subtables*/
+table_size += gic_make_hwdom_madt(d, offset + table_size);
+
+madt = (struct acpi_table_madt *)base_ptr;
+madt->header.length = table_size;
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, madt), table_size);
+madt->header.checksum -= checksum;
+
+tbl_add[TBL_MADT].start = d->arch.efi_acpi_gpa + offset;
+tbl_add[TBL_MADT].size = table_size;
+
+return 0;
+}
 
 static int acpi_create_fadt(struct domain *d, struct membank tbl_add[])
 {
@@ -1462,6 +1508,10 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 if ( rc != 0 )
 return rc;
 
+rc = acpi_create_madt(d, tbl_add);
+if ( rc != 0 )
+return rc;
+
 return 0;
 }
 #else
-- 
2.0.4



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

Re: [Xen-devel] [PATCH v6 19/22] hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ

[Shannon Zhao]

On 2016/3/17 19:29, Jan Beulich wrote:
 On 17.03.16 at 12:04,  wrote:
>> On 2016/3/17 18:42, Jan Beulich wrote:
>> On 17.03.16 at 10:41,  wrote:
> --- a/xen/include/public/hvm/params.h
> +++ b/xen/include/public/hvm/params.h
> @@ -49,11 +49,24 @@
>   * Domain = val[47:32], Bus = val[31:16] DevFn = val[15:8], IntX = 
>> val[1:0]
>   */
>  
> +#ifndef CONFIG_ARM
>>> This is a public header, so you can't rely on CONFIG_* values.
>>> You should check compiler defined CPU architecture manifest
>>> constants instead (and there are numerous examples throughout
>>> public/).
>> Oh, right, thanks. Will replace it with
>> #if !defined(__arm__) && !defined (__aarch64__)
> 
> Well, not exactly. You should use only positive checks here,
> i.e. the x86 one wants to be framed by a respective x86
> conditional, and the ARM one wants to be framed by the
> inverse of the above.
> 
Like below:

diff --git a/xen/include/public/hvm/params.h
b/xen/include/public/hvm/params.h
index 73d4718..d03c103 100644
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -49,11 +49,24 @@
  * Domain = val[47:32], Bus = val[31:16] DevFn = val[15:8], IntX = val[1:0]
  */

+#if defined(__i386__) || defined(__x86_64__)
 #define HVM_PARAM_CALLBACK_TYPE_VECTOR   2
 /*
  * val[7:0] is a vector number.  Check for XENFEAT_hvm_callback_vector
to know
  * if this delivery method is available.
  */
+#elif defined(__arm__) || defined (__aarch64__)
+#define HVM_PARAM_CALLBACK_TYPE_PPI  2
+/*
+ * val[55:16] needs to be zero.
+ * val[15:8] is interrupt flag of the PPI used by event-channel:
+ *  bit 8: the PPI is edge(1) or level(0) triggered
+ *  bit 9: the PPI is active low(1) or high(0)
+ * val[7:0] is a PPI number used by event-channel.
+ * This is only used by ARM/ARM64 and masking/eoi the interrupt
associated to
+ * the notification is handled by the interrupt controller.
+ */
+#endif

 /*
  * These are not used by Xen. They are here for convenience of HVM-guest

-- 
Shannon


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-qcow2  3 host-install(3)   broken REGR. vs. 86376
 test-armhf-armhf-xl-credit2  11 guest-start   fail REGR. vs. 86376

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 86376
 build-amd64-rumpuserxen   6 xen-buildfail   like 86376
 build-i386-rumpuserxen6 xen-buildfail   like 86376
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 86376
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 86376
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 86376
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 86376

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

version targeted for testing:
 xen  6ea2dc59a78ebf24ecdf20193144dada90b0512b
baseline version:
 xen  efc904263f483026672a5cdf3ccf9be8c4fdaa31

Last test of basis86376  2016-03-16 07:21:55 Z1 days
Testing same since86434  2016-03-16 22:43:52 Z0 days1 attempts


People who touched revisions under test:
  Doug Goldstein 
  Jan Beulich 
  Konrad Rzeszutek Wilk 
  Razvan Cojocaru 
  Wei Liu 

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

Re: [Xen-devel] [PATCH 2/2] xen/x86: Introduce a new VMASSIST for architectural behaviour of iopl

[Andrew Cooper]

On 17/03/16 10:25, Jan Beulich wrote:
 On 16.03.16 at 21:05,  wrote:
>> @@ -1742,8 +1742,10 @@ static void load_segments(struct vcpu *n)
>>  cs_and_mask = (unsigned short)regs->cs |
>>  ((unsigned int)vcpu_info(n, evtchn_upcall_mask) << 16);
>>  /* Fold upcall mask into RFLAGS.IF. */
>> -eflags  = regs->_eflags & ~X86_EFLAGS_IF;
>> +eflags  = regs->_eflags & ~(X86_EFLAGS_IF|X86_EFLAGS_IOPL);
> This and ...
>
>> @@ -1788,8 +1790,10 @@ static void load_segments(struct vcpu *n)
>>  ((unsigned long)vcpu_info(n, evtchn_upcall_mask) << 32);
>>  
>>  /* Fold upcall mask into RFLAGS.IF. */
>> -rflags  = regs->rflags & ~X86_EFLAGS_IF;
>> +rflags  = regs->rflags & ~(X86_EFLAGS_IF|X86_EFLAGS_IOPL);
> ... this is not really necessary (but also not wrong) - the actual
> EFLAGS.IOPL is always zero (and assumed to be so by code
> further down from the respective adjustments you make). For
> consistency's sake it might be better to either drop the changes
> here, or also adjust the two places masking regs->eflags.

I will adjust the others.  I would prefer not to rely on the assumption
that it is actually 0.

>
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -1806,7 +1806,9 @@ static int guest_io_okay(
>>  #define TOGGLE_MODE() if ( user_mode ) toggle_guest_mode(v)
>>  
>>  if ( !vm86_mode(regs) &&
>> - (v->arch.pv_vcpu.iopl >= (guest_kernel_mode(v, regs) ? 1 : 3)) )
>> + (MASK_EXTR(v->arch.pv_vcpu.iopl, X86_EFLAGS_IOPL) >=
>> +  (guest_kernel_mode(v, regs) ?
>> +   (VM_ASSIST(v->domain, architectural_iopl) ? 0 : 1) : 3)) )
>>  return 1;
>>  
>>  if ( v->arch.pv_vcpu.iobmp_limit > (port + bytes) )
>> @@ -2367,7 +2369,9 @@ static int emulate_privileged_op(struct cpu_user_regs 
>> *regs)
>>  
>>  case 0xfa: /* CLI */
>>  case 0xfb: /* STI */
>> -if ( v->arch.pv_vcpu.iopl < (guest_kernel_mode(v, regs) ? 1 : 3) )
>> +if ( MASK_EXTR(v->arch.pv_vcpu.iopl, X86_EFLAGS_IOPL) <
>> + (guest_kernel_mode(v, regs) ?
>> +  (VM_ASSIST(v->domain, architectural_iopl) ? 0 : 1) : 3) )
>>  goto fail;
> The similarity of the two together with the growing complexity
> suggests to make this a macro or inline function. Additionally
> resulting binary code would likely be better if you compared
> v->arch.pv_vcpu.iopl with MASK_INSR(,
> X86_EFLAGS_IOPL), even if that means having three
> MASK_INSR() (albeit those perhaps again would be hidden in
> a macro, e.g.
>
> #define IOPL(n) MASK_INSR(n, X86_EFLAGS_IOPL)

I will see what I can do.

>
> ).
>
>> --- a/xen/arch/x86/x86_64/compat/entry.S
>> +++ b/xen/arch/x86/x86_64/compat/entry.S
>> @@ -277,9 +277,14 @@ compat_create_bounce_frame:
>>  testb %al,%al   # Bits 0-7: saved_upcall_mask
>>  setz  %ch   # %ch == !saved_upcall_mask
>>  movl  UREGS_eflags+8(%rsp),%eax
>> -andl  $~X86_EFLAGS_IF,%eax
>> +andl  $~(X86_EFLAGS_IF|X86_EFLAGS_IOPL),%eax
> See earlier comment.

I hope I have suitably answered why this is staying.

>
>>  addb  %ch,%ch   # Bit 9 (EFLAGS.IF)
>>  orb   %ch,%ah   # Fold EFLAGS.IF into %eax
>> +movq  VCPU_domain(%rbx),%rcx# if ( VM_ASSIST(v->domain, 
>> architectural_iopl) )
> If you used another register, this could be pulled up quite a bit,
> to hide the latency of the load before the loaded value gets used.

Can do, but given all pipeline stalls which currently exist in this
code, I doubt it will make any observable difference.

>
>> +testb $1 << VMASST_TYPE_architectural_iopl,DOMAIN_vm_assist(%rcx)
>> +jz.Lft6
>> +movzwl VCPU_iopl(%rbx),%ecx # Bits 13:12 (EFLAGS.IOPL)
> Why not just MOVL?

Ah yes - this is leftover from the first iteration.

~Andrew

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

Re: [Xen-devel] [PATCH v6 22/22] xen/arm64: Add ACPI support

[Shannon Zhao]

On 2016/3/17 19:31, Jan Beulich wrote:
 On 17.03.16 at 12:03,  wrote:
>> > On 2016/3/17 18:52, Jan Beulich wrote:
>> > On 17.03.16 at 10:41,  wrote:
> >>> > --- a/xen/include/asm-arm/config.h
> >>> > +++ b/xen/include/asm-arm/config.h
> >>> > @@ -31,6 +31,10 @@
> >>> >  
> >>> >  #define CONFIG_ARM_L1_CACHE_SHIFT 7 /* XXX */
> >>> >  
> >>> > +#ifdef CONFIG_ACPI
> >>> > +#define CONFIG_ACPI_BOOT 1
> >>> > +#endif
>>> >> Do we think that ACPI without ACPI_BOOT is useful for anything?
>>> >> If not, I think we should just get rid of the latter in common code
>>> >> (x86 could be cleaned up separately), and hence ARM wouldn't
>>> >> have a need for this ugliness. If however we do, then this should
>>> >> be switched to Kconfig (at once on x86 then).
>> > I think we could replace CONFIG_ACPI_BOOT with CONFIG_ACPI. Maybe we
>> > could clean up them on top this of patch.
> Cleaning up the sole common code use should be done as a prereq,
> or even inside this patch. Doing such cleanup on top is a bad idea:
> We should aim at not introducing any further CONFIG_* #define-s
> in headers, now that we have the Kconfig machinery in place.
Ok, so it's fine to you that replace CONFIG_ACPI_BOOT with CONFIG_ACPI
in common and x86 codes, right? If so, I'll add a patch to that before
thia patch.

Thanks,
-- 
Shannon


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

Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

[Konrad Rzeszutek Wilk]

> Then there is another problem (which also exists in the current
> design): does Xen need to emulate NVDIMM _DSM for dom0? Take the _DSM
> that access label storage area (for namespace) for example:

No. And it really can't as each vendors _DSM is different - and there
is no ACPI AML interpreter inside Xen hypervisor.
> 
> The way Linux reserving space on pmem mode NVDIMM is to leave the
> reserved space at the beginning of pmem mode NVDIMM and create a pmem
> namespace which starts from the end of the reserved space. Because the
> reservation information is written in the namespace in the NVDIMM
> label storage area, every OS that follows the namespace spec would not
> mistakenly write files in the reserved area. I prefer to the same way
> if Xen is going to do the reservation. We definitely don't want dom0
> to break the label storage area, so Xen seemingly needs to emulate the
> corresponding _DSM functions for dom0? If so, which part, the
> hypervisor or the toolstack, should do the emulation?

But we do not want Xen to do the reservation. The control guest (Dom0)
is the one that will mount the NVDIMM, and extract the system ranges
from the files on the NVDIMM - and glue them to a guest. 

It is also the job of Dom0 to do the actually partition the NVDIMM
as fit. Actually let me step back. It is the job of the guest who
has the full NVDIMM in it. At bootup it is Dom0 - but you can very
well 'unplug' the NVDIMM from Dom0 and assign it wholesale to a guest.

Granted at that point the _DSM operations have to go through QEMU
which ends up calling the dom0 ioctls on PMEM to do the operation
(like getting the SMART data).
> 
> Haozhong

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  a6f2cdb633bf519244a16674031b8034b581ba7f
baseline version:
 xen  6ea2dc59a78ebf24ecdf20193144dada90b0512b

Last test of basis86408  2016-03-16 16:03:38 Z0 days
Testing same since86477  2016-03-17 13:03:28 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Paul Durrant 
  Shanker Donthineni 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=a6f2cdb633bf519244a16674031b8034b581ba7f
+ . ./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 
a6f2cdb633bf519244a16674031b8034b581ba7f
+ branch=xen-unstable-smoke
+ revision=a6f2cdb633bf519244a16674031b8034b581ba7f
+ . ./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-unstable-coverity
+ '[' xa6f2cdb633bf519244a16674031b8034b581ba7f = 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/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;

Re: [Xen-devel] [PATCH v4 06/34] x86/arm: Add BUGFRAME_NR define and BUILD checks.

[Konrad Rzeszutek Wilk]

On Fri, Mar 18, 2016 at 06:40:31AM -0600, Jan Beulich wrote:
> >>> On 15.03.16 at 18:56,  wrote:
> > --- a/xen/include/asm-arm/bug.h
> > +++ b/xen/include/asm-arm/bug.h
> > @@ -31,6 +31,7 @@ struct bug_frame {
> >  #define BUGFRAME_warn   0
> >  #define BUGFRAME_bug1
> >  #define BUGFRAME_assert 2
> > +#define BUGFRAME_NR 3
> >  
> >  /* Many versions of GCC doesn't support the asm %c parameter which would
> >   * be preferable to this unpleasantness. We use mergeable string
> > @@ -39,6 +40,7 @@ struct bug_frame {
> >   */
> >  #define BUG_FRAME(type, line, file, has_msg, msg) do { 
> >  \
> >  BUILD_BUG_ON((line) >> 16);
> >  \
> > +BUILD_BUG_ON(type >= BUGFRAME_NR); 
> >  \
> 
> The x86 variant has type properly parenthesized - why not here?
> 
> > --- a/xen/include/asm-x86/bug.h
> > +++ b/xen/include/asm-x86/bug.h
> > @@ -9,7 +9,7 @@
> >  #define BUGFRAME_warn   1
> >  #define BUGFRAME_bug2
> >  #define BUGFRAME_assert 3
> > -
> > +#define BUGFRAME_NR 4
> >  #ifndef __ASSEMBLY__
> 
> Please retain the blank line.
> 
> > @@ -51,6 +51,7 @@ struct bug_frame {
> >  
> >  #define BUG_FRAME(type, line, ptr, second_frame, msg) do { 
> >   \
> >  BUILD_BUG_ON((line) >> (BUG_LINE_LO_WIDTH + BUG_LINE_HI_WIDTH));   
> >   \
> > +BUILD_BUG_ON((type) >= (BUGFRAME_NR)); 
> >   \
> 
> The ARM variant has BUGFRAME_NR properly un-parenthesized -
> why here?

I know I copied and pasted it and I must have done something uncanny.

Anyhow this is what the change looks like now (I've retained the Reviewed
and Ack as I think this change is mostly cosmetical in nature?)

From 123ad665b283f8c59688bd86be0bbe79ce5723bb Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Thu, 10 Mar 2016 16:45:31 -0500
Subject: [PATCH] x86/arm: Add BUGFRAME_NR define and BUILD checks.

So that we have a nice mechansim to figure out the upper
bounds of bug.frames and also catch compiler errors in case
one tries to use a higher frame number.

Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Andrew Cooper 
Acked-by: Julien Grall 

---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v3: First time included.
v4: Add BUG_FRAME check also in the assembler version of the macro.
v5: Add Acks, make BUILD_BUG_ON checks look correct. Position the
BUGFRAME_NR properly.
---
---
 xen/include/asm-arm/bug.h | 3 +++
 xen/include/asm-x86/bug.h | 7 +++
 2 files changed, 10 insertions(+)

diff --git a/xen/include/asm-arm/bug.h b/xen/include/asm-arm/bug.h
index ab9e811..68353e1 100644
--- a/xen/include/asm-arm/bug.h
+++ b/xen/include/asm-arm/bug.h
@@ -32,6 +32,8 @@ struct bug_frame {
 #define BUGFRAME_bug1
 #define BUGFRAME_assert 2
 
+#define BUGFRAME_NR 3
+
 /* Many versions of GCC doesn't support the asm %c parameter which would
  * be preferable to this unpleasantness. We use mergeable string
  * sections to avoid multiple copies of the string appearing in the
@@ -39,6 +41,7 @@ struct bug_frame {
  */
 #define BUG_FRAME(type, line, file, has_msg, msg) do {  \
 BUILD_BUG_ON((line) >> 16); \
+BUILD_BUG_ON((type) >= BUGFRAME_NR);\
 asm ("1:"BUG_INSTR"\n"  \
  ".pushsection .rodata.str, \"aMS\", %progbits, 1\n"\
  "2:\t.asciz " __stringify(file) "\n"   \
diff --git a/xen/include/asm-x86/bug.h b/xen/include/asm-x86/bug.h
index e868e85..7825565 100644
--- a/xen/include/asm-x86/bug.h
+++ b/xen/include/asm-x86/bug.h
@@ -10,6 +10,7 @@
 #define BUGFRAME_bug2
 #define BUGFRAME_assert 3
 
+#define BUGFRAME_NR 4
 #ifndef __ASSEMBLY__
 
 struct bug_frame {
@@ -51,6 +52,7 @@ struct bug_frame {
 
 #define BUG_FRAME(type, line, ptr, second_frame, msg) do {   \
 BUILD_BUG_ON((line) >> (BUG_LINE_LO_WIDTH + BUG_LINE_HI_WIDTH)); \
+BUILD_BUG_ON((type) >= BUGFRAME_NR); \
 asm volatile ( _ASM_BUGFRAME_TEXT(second_frame)  \
:: _ASM_BUGFRAME_INFO(type, line, ptr, msg) );\
 } while (0)
@@ -83,6 +85,11 @@ extern const struct bug_frame __start_bug_frames[],
  * in .rodata
  */
 .macro BUG_FRAME type, line, file_str, second_frame, msg
+
+.if \type >= BUGFRAME_NR
+.error "Invalid BUGFRAME index"
+.endif
+
 .L\@ud: ud2a
 
 .pushsection .rodata.str1, "aMS", @progbits, 1
-- 
2.5.0


___

Re: [Xen-devel] [PATCH v3 1/2] x86/hvm/viridian: keep APIC assist page mapped...

[Paul Durrant]

> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 16 March 2016 17:44
> To: xen-de...@lists.xenproject.org
> Cc: Paul Durrant; Keir (Xen.org); Jan Beulich; Andrew Cooper
> Subject: [PATCH v3 1/2] x86/hvm/viridian: keep APIC assist page mapped...
> 
> ... for the lifetime of the domain.
> 
> If Xen is to make use of the APIC assist enlightenment then a persistent
> mapping needs to be kept, rather than the temporary one which is currently
> used only to initialize the page content.
> 
> This patch also adds a comment block at the top of the source with
> information on the latest version of the spec. from Microsoft and the
> current URL where it may be found.
> 
> Signed-off-by: Paul Durrant 
> Cc: Keir Fraser 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
> 
> v2:
>  - Re-instated warning if the initialization of an APIC assist page fails.
>  - Added up-to-date information about the viridian specification to the
>comment block at the top of the source.
> ---
>  xen/arch/x86/hvm/hvm.c |  2 +
>  xen/arch/x86/hvm/viridian.c| 76 ---
> ---
>  xen/include/asm-x86/hvm/viridian.h |  8 +++-
>  3 files changed, 65 insertions(+), 21 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 4ea51d7..f446ee4 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2606,6 +2606,8 @@ int hvm_vcpu_initialise(struct vcpu *v)
> 
>  void hvm_vcpu_destroy(struct vcpu *v)
>  {
> +viridian_vcpu_deinit(v);
> +
>  hvm_all_ioreq_servers_remove_vcpu(v->domain, v);
> 
>  if ( hvm_altp2m_supported() )
> diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
> index 1ee22aa..e990163 100644
> --- a/xen/arch/x86/hvm/viridian.c
> +++ b/xen/arch/x86/hvm/viridian.c
> @@ -1,7 +1,12 @@
> 
> /**
> 
>   * viridian.c
>   *
> - * An implementation of the Viridian hypercall interface.
> + * An implementation of some Viridian enlightenments. See Microsoft's
> + * Hypervisor Top Level Functional Specification (v4.0b) at:
> + *
> + * https://msdn.microsoft.com/en-
> us/virtualization/hyperv_on_windows/develop/tlfs
> + *
> + * for more information.
>   */
> 
>  #include 
> @@ -163,7 +168,7 @@ static void dump_apic_assist(const struct vcpu *v)
>  {
>  const union viridian_apic_assist *aa;
> 
> -aa = >arch.hvm_vcpu.viridian.apic_assist;
> +aa = >arch.hvm_vcpu.viridian.apic_assist.msr;
> 
>  printk(XENLOG_G_INFO "%pv: VIRIDIAN APIC_ASSIST: enabled: %x pfn:
> %lx\n",
> v, aa->fields.enabled, (unsigned long)aa->fields.pfn);
> @@ -217,9 +222,9 @@ static void enable_hypercall_page(struct domain *d)
>  static void initialize_apic_assist(struct vcpu *v)
>  {
>  struct domain *d = v->domain;
> -unsigned long gmfn = v->arch.hvm_vcpu.viridian.apic_assist.fields.pfn;
> +unsigned long gmfn = v-
> >arch.hvm_vcpu.viridian.apic_assist.msr.fields.pfn;
>  struct page_info *page = get_page_from_gfn(d, gmfn, NULL,
> P2M_ALLOC);
> -uint8_t *p;
> +void *va;
> 
>  /*
>   * We don't yet make use of the APIC assist page but by setting
> @@ -227,25 +232,49 @@ static void initialize_apic_assist(struct vcpu *v)
>   * bound to support the MSR. We therefore do just enough to keep
> windows
>   * happy.
>   *
> - * See http://msdn.microsoft.com/en-
> us/library/ff538657%28VS.85%29.aspx for
> - * details of how Windows uses the page.
> + * See section 13.3.4.1 of the specification for details of this
> + * enlightenment.
>   */
> 
> -if ( !page || !get_page_type(page, PGT_writable_page) )
> +if ( !page )
> +goto fail;
> +
> +if ( !get_page_type(page, PGT_writable_page) )
>  {
> -if ( page )
> -put_page(page);
> -gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn,
> - page ? page_to_mfn(page) : INVALID_MFN);
> -return;
> +put_page(page);
> +goto fail;
>  }
> 
> -p = __map_domain_page(page);
> +va = __map_domain_page_global(page);
> +if ( !va )
> +{
> +put_page_and_type(page);
> +goto fail;
> +}
> 
> -*(u32 *)p = 0;
> +*(uint32_t *)va = 0;
> 
> -unmap_domain_page(p);
> +v->arch.hvm_vcpu.viridian.apic_assist.page = page;
> +v->arch.hvm_vcpu.viridian.apic_assist.va = va;
> +return;
> +
> + fail:
> +gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn,
> + page ? page_to_mfn(page) : INVALID_MFN);
> +}
> +
> +static void teardown_apic_assist(struct vcpu *v)
> +{
> +struct page_info *page = v->arch.hvm_vcpu.viridian.apic_assist.page;
> +void *va = v->arch.hvm_vcpu.viridian.apic_assist.va;
> 
> +if ( !va )
> +return;
> +
> +v->arch.hvm_vcpu.viridian.apic_assist.va = 

Re: [Xen-devel] [PATCH v7 for Xen 4.7 3/4] libxl: enable per-VCPU parameter settings for RTDS scheduler

[Dario Faggioli]

On Wed, 2016-03-16 at 11:47 -0500, Chong Li wrote:
> Add libxl_vcpu_sched_params_get/set and sched_rtds_vcpu_get/set
> functions to support per-VCPU settings.
> 
And a couple more things that I forgot.

I'd shorten the subject line, as already suggested for libxc.

> +/* Get the RTDS scheduling parameters of vcpu(s) */
> +static int sched_rtds_vcpu_get(libxl__gc *gc, uint32_t domid,
> +   libxl_vcpu_sched_params *scinfo)
> +{
I think this should be called

static int sched_rtds_vcpu_params_get(libxl__gc *gc, uint32_t domid,
      libxl_vcpu_sched_params *scinfo)

for homogeneity with the _set counterpart here below:

> @@ -5873,6 +6048,74 @@ int libxl_domain_sched_params_set(libxl_ctx
> *ctx, uint32_t domid,
>  return ret;
>  }
>  
> +int libxl_vcpu_sched_params_set(libxl_ctx *ctx, uint32_t domid,
> +const libxl_vcpu_sched_params
> *scinfo)
> +{
So, this function takes a libxl_vcpu_sched_params*, which is basically
an array of vcpus' parameters, one element per vcpu (and it can be
sparse).

Are there any restrictions on how such array should be constructed, for
calling this function? Are they any special meaning of particular
configurations of the array?

I think at least the latter is true, in fact:
 - this calls sched_rtds_vcpus_params_set();
 - in there, if the array is empty, we fail;
 - if the array has one or more elements, we deal with the vcpus 
   (and just them) specified in the elements of the array itself.

Then there is libxl_vcpu_sched_params_set_all(). That one:
 - calls sched_rtds_vcpus_params_set_all();
 - in there, if the array has more than just one element, we fail.

And then the get side, with libxl_vcpu_sched_params_get(). That one:
 - calls sched_rtds_vcpu_get();
 - in there, if the array is empty, we create one, and return info for 
   all the vcpus;
 - if the array has one or more elements, we deal with them (and just 
   them).

I think this should be documented some (unless it's already there and I
missed it).

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



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

[Xen-devel] [linux-mingo-tip-master test] 86624: regressions - FAIL

[osstest service owner]

flight 86624 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/86624/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 60684
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-xl  17 guest-localmigrate/x10fail REGR. vs. 60684
 test-amd64-amd64-xl-multivcpu 17 guest-localmigrate/x10   fail REGR. vs. 60684
 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2   fail REGR. vs. 60684
 test-amd64-amd64-xl-credit2  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-pair  22 guest-migrate/dst_host/src_host fail REGR. vs. 60684
 test-amd64-amd64-libvirt  15 guest-saverestore.2 fail in 86535 REGR. vs. 60684

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl  14 guest-saverestore  fail in 86535 pass in 86624
 test-amd64-amd64-xl-multivcpu 14 guest-saverestore fail in 86535 pass in 86624
 test-amd64-amd64-xl-rtds 15 guest-localmigrate fail in 86535 pass in 86624
 test-amd64-amd64-pair 21 guest-migrate/src_host/dst_host fail in 86535 pass in 
86624
 test-amd64-amd64-libvirt 14 guest-saverestore   fail pass in 86535
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail pass in 
86535

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 17 guest-localmigrate/x10fail REGR. vs. 60684
 test-amd64-amd64-qemuu-nested-intel 9 debian-hvm-install fail baseline untested
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-i386-xl-xsm   15 guest-localmigrate   fail blocked in 60684
 test-amd64-i386-xl   15 guest-localmigrate   fail blocked in 60684
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked 
in 60684
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked 
in 60684
 test-amd64-i386-pair  22 guest-migrate/dst_host/src_host fail blocked in 60684
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 60684
 test-amd64-i386-libvirt-xsm  14 guest-saverestore fail in 86535 like 60684
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 60684
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 60684
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 60684

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1fail in 86535 never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 linux7eebe2a731a0f4f48d57cfb2cfcae76f788f2164
baseline version:
 linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0

Last test of basis60684  2015-08-13 04:21:46 Z  219 days
Failing since 60712  2015-08-15 18:33:48 Z  217 days  162 attempts
Testing same since86535  2016-03-18 04:29:32 Z1 days2 attempts

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
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  fail
 test-amd64-i386-xl  

[Xen-devel] [xen-unstable baseline-only test] 44249: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 44249 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44249/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 build-i386-rumpuserxen6 xen-buildfail   like 44245
 test-amd64-amd64-xl-xsm  19 guest-start/debian.repeatfail   like 44245
 build-amd64-rumpuserxen   6 xen-buildfail   like 44245
 test-amd64-amd64-xl-credit2  19 guest-start/debian.repeatfail   like 44245
 test-amd64-amd64-xl  19 guest-start/debian.repeatfail   like 44245
 test-amd64-amd64-i386-pvgrub 10 guest-start  fail   like 44245
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 44245
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 44245

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

version targeted for testing:
 xen  c2b9b97775e9de061dd72b22fb96293daaa77f98
baseline version:
 xen  e46a729b18af85b4dd040578643f7fa430b22a48

Last test of basis44245  2016-03-12 17:19:39 Z3 days
Testing same since44249  2016-03-16 07:19:34 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  Jan Beulich 
  Kevin Tian 
  Quan Xu 
  Wei Liu 

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

[Xen-devel] [PATCH 0/5] x86/time: PVCLOCK_TSC_STABLE_BIT support

[Joao Martins]

Hey,

This series is a repost with the comments that I got so far and
hopefully could be considered for Xen 4.7.

PVCLOCK_TSC_STABLE_BIT is the flag telling the guest that the
vcpu_time_info (pvti) are monotonic as seen by any CPU, a feature
which is currently not supported. As it is (i.e. bindly setting the
flag), we can observe that this property isn't there: a process using
vdso clock_gettime/gettimeofday will observe a significant amount of
warps (i.e. time going backwards) and it's due to 1) time calibration
skew in xen rendezvous algorithm 2) clocksource not in sync with TSC.
These warps are seen more frequently on PV guests (potentially because
vcpu time infos are only updated when guest is in kernel mode, and
perhaps lack of tsc_offset?), and in rare ocasions on HVM guests. It
is worth noting that with guests VCPUs pinned, only PV guests see
these warps. But on HVM guests specifically: such warps only occur
when one of guest VCPUs is pinned to CPU0. This series aims to propose
a solution to that and it's divided as following:

(R) * Patch 1: Adds the missing flag field to vcpu_time_info.
(U) * Patch 2: Adds a new clocksource based on TSC
(U) * Patch 3, 4: Adjustments for patch 5
* Patch 5: Implements the PVCLOCK_TSC_STABLE_BIT

[R := Reviewed-by ;; U := Updated]

PVCLOCK_TSC_STABLE_BIT is set only when using clocksource=tsc,
and so it remains optional unless specified by the admin.

The test was running time-warp-test, that constantly calls
clock_gettime/gettimeofday on every CPU. It measures a delta with the
previous returned value and mark a warp if it's negative. I measured
it during periods of 1h and 6h and check how many warps and their
values (alongside the amount of time skew). Measurements/Changelog are
included in individual patches.

Note that most of the testing has been done with Linux 4.4 in which
these warps/skew could be easily observed as vdso would use each vCPU
pvti. Though Linux >= 4.5 changes this behaviour and use only the
vCPU0 pvti though still requiring PVCLOCK_TSC_STABLE_BIT flag
support.

Any comments appreciated,

Thanks!
Joao

Joao Martins (5):
  public/xen.h: add flags field to vcpu_time_info
  x86/time: implement tsc as clocksource
  x86/time: streamline platform time init on plt_init()
  x86/time: refactor read_platform_stime()
  x86/time: implement PVCLOCK_TSC_STABLE_BIT

 xen/arch/x86/time.c  | 132 ---
 xen/include/public/xen.h |   6 ++-
 2 files changed, 119 insertions(+), 19 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH v3 0/3] Allow tmem to be disabled via Kconfig

[Doug Goldstein]

Allows expert users to disable tmem  via Kconfig. Incorporates feedback
from Jan and Konrad. Patch 2 & 3 from v1 were merged and patch 4 was
dropped.

Doug Goldstein (3):
  tmem: add tmem_disable() function
  tmem: drop direct usage of opt_tmem
  tmem: allow tmem to be disabled with Kconfig

 xen/arch/x86/setup.c   |  6 +++---
 xen/arch/x86/x86_64/compat/entry.S |  4 
 xen/arch/x86/x86_64/entry.S|  4 
 xen/common/Kconfig | 10 ++
 xen/common/Makefile|  8 +---
 xen/common/memory.c|  2 +-
 xen/common/page_alloc.c|  8 
 xen/common/tmem.c  |  3 +++
 xen/include/xen/hypercall.h|  4 
 xen/include/xen/tmem.h | 26 ++
 xen/include/xen/tmem_xen.h | 16 
 11 files changed, 80 insertions(+), 11 deletions(-)

-- 
2.4.10


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

[Xen-devel] [distros-debian-jessie test] 44257: tolerable trouble: broken/pass

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-armhf-jessie-netboot-pygrub 3 host-install(3) broken blocked 
in 44240
 test-amd64-amd64-i386-jessie-netboot-pygrub 3 host-install(3) broken blocked 
in 44240
 test-amd64-amd64-amd64-jessie-netboot-pvgrub 3 host-install(3) broken blocked 
in 44240
 test-amd64-i386-amd64-jessie-netboot-pygrub 3 host-install(3) broken blocked 
in 44240
 test-amd64-i386-i386-jessie-netboot-pvgrub 3 host-install(3) broken blocked in 
44240

baseline version:
 flight   44240

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub broken  
 test-amd64-i386-i386-jessie-netboot-pvgrub   broken  
 test-amd64-i386-amd64-jessie-netboot-pygrub  broken  
 test-armhf-armhf-armhf-jessie-netboot-pygrub broken  
 test-amd64-amd64-i386-jessie-netboot-pygrub  broken  



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

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

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


Push not applicable.


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

[Xen-devel] [PATCH v7 for Xen 4.7 1/4] xen: enable per-VCPU parameter settings for RTDS scheduler

[Chong Li]

Add XEN_DOMCTL_SCHEDOP_getvcpuinfo and _putvcpuinfo hypercalls
to independently get and set the scheduling parameters of each
vCPU of a domain

Signed-off-by: Chong Li 
Signed-off-by: Meng Xu 
Signed-off-by: Sisu Xi 

---
Changes on PATCH v6:
1) Add explain for nr_vcpus in struct xen_domctl_scheduler_op, because it is 
used
in both IN and OUT ways.
2) Remove the check and warning for vcpu settings with low budget or budget. 
Making this
feature "per-domain" or "per-operation" is one of the future work.
3) In the *cntl() functions in sched_credit.c and sched_credit2.c, change the 
"if-else"
structure to "switch" structure.
4) In rt_dom_cntl(), use copy_to_guest* instead of __copy_to_guest*, because 
the latter one
requires lock protection.

Changes on PATCH v5:
1) When processing XEN_DOMCTL_SCHEDOP_get/putvcpuinfo, we do
preemption check in a similar way to XEN_SYSCTL_pcitopoinfo

Changes on PATCH v4:
1) Add uint32_t vcpu_index to struct xen_domctl_scheduler_op.
When processing XEN_DOMCTL_SCHEDOP_get/putvcpuinfo, we call
hypercall_preemption_check in case the current hypercall lasts
too long. If we decide to preempt the current hypercall, we record
the index of the most-recent finished vcpu into the vcpu_index of
struct xen_domctl_scheduler_op. So when we resume the hypercall after
preemption, we start processing from the posion specified by vcpu_index,
and don't need to repeat the work that has already been done in the
hypercall before the preemption.
(This design is based on the do_grant_table_op() in grant_table.c)

2) Coding style changes

Changes on PATCH v3:
1) Remove struct xen_domctl_schedparam_t.

2) Change struct xen_domctl_scheduler_op.

3) Check if period/budget is within a validated range

Changes on PATCH v2:
1) Change struct xen_domctl_scheduler_op, for transferring per-vcpu parameters
between libxc and hypervisor.

2) Handler of XEN_DOMCTL_SCHEDOP_getinfo now just returns the default budget and
period values of RTDS scheduler.

3) Handler of XEN_DOMCTL_SCHEDOP_getvcpuinfo now can return a random subset of
the parameters of the VCPUs of a specific domain

CC: 
CC: 
CC: 
CC: 
CC: 
CC: 
---
 xen/common/sched_credit.c   |  17 ---
 xen/common/sched_credit2.c  |  16 ---
 xen/common/sched_rt.c   | 114 ++--
 xen/common/schedule.c   |  15 --
 xen/include/public/domctl.h |  63 +++-
 5 files changed, 183 insertions(+), 42 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 0dce790..82b0d14 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -1054,15 +1054,16 @@ csched_dom_cntl(
  * lock. Runq lock not needed anywhere in here. */
 spin_lock_irqsave(>lock, flags);
 
-if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
+switch ( op->cmd )
 {
+case XEN_DOMCTL_SCHEDOP_putvcpuinfo:
+case XEN_DOMCTL_SCHEDOP_getvcpuinfo:
+return -EINVAL;
+case XEN_DOMCTL_SCHEDOP_getinfo:
 op->u.credit.weight = sdom->weight;
 op->u.credit.cap = sdom->cap;
-}
-else
-{
-ASSERT(op->cmd == XEN_DOMCTL_SCHEDOP_putinfo);
-
+break;
+case XEN_DOMCTL_SCHEDOP_putinfo:
 if ( op->u.credit.weight != 0 )
 {
 if ( !list_empty(>active_sdom_elem) )
@@ -1075,7 +1076,9 @@ csched_dom_cntl(
 
 if ( op->u.credit.cap != (uint16_t)~0U )
 sdom->cap = op->u.credit.cap;
-
+break;
+default:
+return -EINVAL;
 }
 
 spin_unlock_irqrestore(>lock, flags);
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 3c49ffa..46d54bc 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1421,14 +1421,15 @@ csched2_dom_cntl(
  * runq lock to update csvcs. */
 spin_lock_irqsave(>lock, flags);
 
-if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
+switch ( op->cmd )
 {
+case XEN_DOMCTL_SCHEDOP_putvcpuinfo:
+case XEN_DOMCTL_SCHEDOP_getvcpuinfo:
+return -EINVAL;
+case XEN_DOMCTL_SCHEDOP_getinfo:
 op->u.credit2.weight = sdom->weight;
-}
-else
-{
-ASSERT(op->cmd == XEN_DOMCTL_SCHEDOP_putinfo);
-
+break;
+case XEN_DOMCTL_SCHEDOP_putinfo:
 if ( op->u.credit2.weight != 0 )
 {
 struct vcpu *v;
@@ -1457,6 +1458,9 @@ csched2_dom_cntl(
 vcpu_schedule_unlock(lock, svc->vcpu);
 }
 }
+break;
+default:
+return -EINVAL;
 }
 
 spin_unlock_irqrestore(>lock, flags);
diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 3f1d047..359c2db 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -86,6 +86,22 @@
 #define RTDS_DEFAULT_PERIOD (MICROSECS(1))
 #define 

Re: [Xen-devel] [PATCH v4 12/34] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op

[Konrad Rzeszutek Wilk]

On Wed, Mar 16, 2016 at 12:12:00PM +, Julien Grall wrote:
> Hi Konrad,
> 
> On 15/03/2016 17:56, Konrad Rzeszutek Wilk wrote:
> >diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> >index 8fbc46d..dbe9ccc 100644
> >--- a/xen/common/Kconfig
> >+++ b/xen/common/Kconfig
> >@@ -168,4 +168,15 @@ config SCHED_DEFAULT
> >
> >  endmenu
> >
> >+# Enable/Disable xsplice support
> >+config XSPLICE
> >+bool "xSplice live patching support"
> >+default y
> 
> I think it would be better to disable xSplice on ARM until we effectively
> support it.

If you would like. I made it dependent on x86.
> 
> It will avoid people asking on the mailing why xSplice doesn't work for ARM
> platform.
> 
> Regards,
> 
> -- 
> Julien Grall

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

Re: [Xen-devel] [PATCH 5/8] libxl: Share logic for finding path between qemuu and pygrub

[George Dunlap]

On Thu, Mar 17, 2016 at 6:22 PM, Ian Jackson  wrote:
> George Dunlap writes ("[PATCH 5/8] libxl: Share logic for finding path 
> between qemuu and pygrub"):
>> From: George Dunlap 
>
> Thanks.  There are a few format inconsistencies (long lines, spaces)
> which I won't enumerate.
>
>> * In the case of a block script, or a non-dom0 backend, qemuu will now
>> print a warning and skip the disk, rather than adding bogus
>> parameters that will cause qemuu to error out.
>
> I think the consequences here ought to be better spelled out.  AFAICT
> the implication is that, in this case, the disk will be available to
> the guest as a PV disk (because libxl will select a backend other than
> qdisk) but not via the emulated IDE ?
>
> IWBNI the resulting functional restriction were documented, but I
> won't insist on that given that you're improving matters.
>
>> @@ -3023,6 +3024,16 @@ static char * 
>> libxl__device_disk_find_local_path(libxl__gc *gc,
>>  goto out;
>>  }
>>
>> +/*
>> + * If we're being called for a qemu path, we can pass the target
>> + * string directly as well
>> + */
>> +if (qdisk_direct && disk->backend == LIBXL_DISK_BACKEND_QDISK ) {
>> +path = libxl__strdup(gc, disk->pdev_path);
>> +LOG(DEBUG, "Directly accessing local QDISK target %s", path);
>> +goto out;
>
> Is this really true ?  What if the format is qcow2 ?  I think that
> might result in feeding pygrub the qcow2 file rather than the virtual
> block image it contains.

That's what the "qdisk_direct" argument is for -- it tells
libxl__device_disk_find_local_path, "I can interpret QDISK backends".
Pygrub will call this function with "qdisk_direct" set to "false",
since it can't interpret QDISK backends; this will result in it doing
a local attach instead.

> Overall I think this patch is otherwise probably good but it it's a
> bit hard to see the wood for the trees.  If you felt like factoring
> out some of the refactoring and variable renaming, from the functional
> change, that would be very nice.

Yes, there are a lot of things going on, aren't there.  I think I
remember trying to make it simpler when I first wrote it last year,
but not finding any really sensible in-between points; but I'll give
it another look.

 -George

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

[Xen-devel] [PATCH 1/2] IOMMU/MMU: Adjust top level functions for VT-d Device-TLB flush error.

[Quan Xu]

Current code would be panic(), when VT-d Device-TLB flush timed out.
the panic() is going to be eliminated, so we must check all kinds of
error and all the way up the call trees.

Signed-off-by: Quan Xu 

CC: Jan Beulich 
CC: Liu Jinsong 
CC: Keir Fraser 
CC: Andrew Cooper 
CC: Jun Nakajima 
CC: Kevin Tian 
CC: George Dunlap 
CC: Feng Wu 
CC: Dario Faggioli 
---
 xen/arch/x86/acpi/power.c | 14 +-
 xen/arch/x86/mm.c | 13 -
 xen/arch/x86/mm/p2m-ept.c | 10 +-
 xen/arch/x86/mm/p2m-pt.c  | 12 ++--
 xen/common/grant_table.c  |  5 +++--
 xen/common/memory.c   |  5 +++--
 xen/drivers/passthrough/iommu.c   | 16 +++-
 xen/drivers/passthrough/vtd/x86/vtd.c |  7 +--
 xen/drivers/passthrough/x86/iommu.c   |  6 +-
 xen/include/xen/iommu.h   |  6 +++---
 10 files changed, 70 insertions(+), 24 deletions(-)

diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index 2885e31..50edf3f 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -45,6 +45,8 @@ void do_suspend_lowlevel(void);
 
 static int device_power_down(void)
 {
+int err;
+
 console_suspend();
 
 time_suspend();
@@ -53,11 +55,21 @@ static int device_power_down(void)
 
 ioapic_suspend();
 
-iommu_suspend();
+err = iommu_suspend();
+if ( err )
+goto iommu_suspend_error;
 
 lapic_suspend();
 
 return 0;
+
+iommu_suspend_error:
+ioapic_resume();
+i8259A_resume();
+time_resume();
+console_resume();
+
+return err;
 }
 
 static void device_power_up(void)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index c997b53..526548e 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2467,7 +2467,7 @@ static int __get_page_type(struct page_info *page, 
unsigned long type,
int preemptible)
 {
 unsigned long nx, x, y = page->u.inuse.type_info;
-int rc = 0;
+int rc = 0, ret = 0;
 
 ASSERT(!(type & ~(PGT_type_mask | PGT_pae_xen_l2)));
 
@@ -2578,11 +2578,11 @@ static int __get_page_type(struct page_info *page, 
unsigned long type,
 if ( d && is_pv_domain(d) && unlikely(need_iommu(d)) )
 {
 if ( (x & PGT_type_mask) == PGT_writable_page )
-iommu_unmap_page(d, mfn_to_gmfn(d, page_to_mfn(page)));
+ret = iommu_unmap_page(d, mfn_to_gmfn(d, page_to_mfn(page)));
 else if ( type == PGT_writable_page )
-iommu_map_page(d, mfn_to_gmfn(d, page_to_mfn(page)),
-   page_to_mfn(page),
-   IOMMUF_readable|IOMMUF_writable);
+ret = iommu_map_page(d, mfn_to_gmfn(d, page_to_mfn(page)),
+ page_to_mfn(page),
+ IOMMUF_readable|IOMMUF_writable);
 }
 }
 
@@ -2599,6 +2599,9 @@ static int __get_page_type(struct page_info *page, 
unsigned long type,
 if ( (x & PGT_partial) && !(nx & PGT_partial) )
 put_page(page);
 
+if ( !rc )
+rc = ret;
+
 return rc;
 }
 
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 3cb6868..f9bcce7 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -830,7 +830,15 @@ out:
 {
 if ( iommu_flags )
 for ( i = 0; i < (1 << order); i++ )
-iommu_map_page(d, gfn + i, mfn_x(mfn) + i, iommu_flags);
+{
+rc = iommu_map_page(d, gfn + i, mfn_x(mfn) + i, 
iommu_flags);
+if ( rc )
+{
+while ( i-- > 0 )
+iommu_unmap_page(d, gfn + i);
+break;
+}
+}
 else
 for ( i = 0; i < (1 << order); i++ )
 iommu_unmap_page(d, gfn + i);
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 3d80612..c33b753 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -680,8 +680,16 @@ p2m_pt_set_entry(struct p2m_domain *p2m, unsigned long 
gfn, mfn_t mfn,
 }
 else if ( iommu_pte_flags )
 for ( i = 0; i < (1UL << page_order); i++ )
-iommu_map_page(p2m->domain, gfn + i, mfn_x(mfn) + i,
-   iommu_pte_flags);
+{
+rc = iommu_map_page(p2m->domain, gfn + i, mfn_x(mfn) + i,
+iommu_pte_flags);
+if ( rc )
+{
+while ( i-- > 0 )
+iommu_unmap_page(p2m->domain, gfn + i);

Re: [Xen-devel] [PATCH v2] x86/hvm/viridian: fix the TLB flush hypercall

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 17 March 2016 08:12
> To: Paul Durrant
> Cc: Andrew Cooper; xen-de...@lists.xenproject.org; Keir (Xen.org)
> Subject: RE: [PATCH v2] x86/hvm/viridian: fix the TLB flush hypercall
> 
> >>> On 16.03.16 at 18:35,  wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 16 March 2016 15:36
> >> >>> On 16.03.16 at 15:21,  wrote:
> >> > @@ -656,7 +647,9 @@ int viridian_hypercall(struct cpu_user_regs
> *regs)
> >> >   * so we may unnecessarily IPI some CPUs.
> >> >   */
> >> >  if ( !cpumask_empty(pcpu_mask) )
> >> > -flush_tlb_mask(pcpu_mask);
> >> > +smp_send_event_check_mask(pcpu_mask);
> >> > +
> >> > +output.rep_complete = input.rep_count;
> >>
> >> Questions on this one remain: Why only for this hypercall? And
> >> what does "repeat count" mean in this context?
> >>
> >
> > It's only for this hypercall because it's the only 'rep' hypercall we
> > implement. For non-rep hypercalls the spec states that the rep count and
> > starting index in the input params must be zero. It does not state what the
> > value of reps complete should be on output for non-rep hypercalls but I
> think
> > it's safe to assume that zero is correct.
> > For rep hypercalls the spec says that on output "the reps complete field is
> > the total number of reps complete and not relative to the rep start index.
> > For example, if the caller specified a rep start index of 5, and a rep count
> > of 10, the reps complete field would indicate 10 upon successful
> completion".
> >
> > Section 12.4.3 of the spec defines the HvFlushVirtualAddressList hypercall
> > as a rep hypercall and each rep refers to flush of a single guest VA range.
> > Because we invalidate all VA ranges in one go clearly we complete all reps
> > straight away :-)
> 
> Ah, there's an address list associated with it. So if the flush
> request was just for a single page, isn't a flush-all then pretty
> heavy handed?
> 

Yes, it is overkill, but it's probably still less expensive than waking up a 
de-scheduled vCPU to flush a single page and possibly still less expensive than 
an IPI to do the same.

  Paul

> Jan


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

Re: [Xen-devel] [PATCH 2/2] x86/mtrr: Refactor PAT initialization code

[Toshi Kani]

On Thu, 2016-03-17 at 17:06 -0700, Luis R. Rodriguez wrote:
> On Mar 17, 2016 2:04 PM, "Toshi Kani"  wrote:
> > 
> > On Wed, 2016-03-16 at 00:29 +0100, Luis R. Rodriguez wrote:
> > > On Tue, Mar 15, 2016 at 05:48:44PM -0600, Toshi Kani wrote:
> > > > On Tue, 2016-03-15 at 01:15 +0100, Luis R. Rodriguez wrote:
> > > > > On Fri, Mar 11, 2016 at 06:16:36PM -0700, Toshi Kani wrote:
> > > > > > 
> >  :
> > > > MTRR code does not have to be dead for the virtual machines with no
> > > > MTRR support.  The code just needs to handle the disabled case
> > > > properly.  I consider this is part of 1) that the kernel keeps the
> > > > MTRR state as disabled.
> > > 
> > > For Xen it was possible to use PAT without any of the MTRR code
> > > running, I don't see why its needed then and why other virtual
> > > machines that only need PAT need it.
> > 
> > Virtual BIOS does not need MTRRs since it does not manage the platform.
> 
> Unless if in dom0 and if some of this purposely wants to be punted
> there to leverage existing kernel code. On the Xen thread I'm asking
> about the implications of that and how/if Xen should be doing. We can
> follow up on this there as its Xen specific.

I do not see any issue for Xen, but sure, we can discuss about Xen in a
separate thread.


 :
> > > On x86 Linux code we now have ioremap_uc() that can't use MTRR behind
> > > the scenes, why would something like this on the BIOS not be
> > > possible? That ultimately uses set_pte_at(). What limitations are
> > > there on the BIOS that prevent us from just using strong UC for PAT
> > > on the BIOS?
> > 
> > Because it requires to run in virtual mode with page tables.
> 
> Ah... interesting... is UC really needed, what is the default? If the
> default is used would there be an issue ? Can such work be deferred to
> a later time ? It seems like a high burden to require on large piece
> of legacy architecture to just blow a fan.

The default cache attribute (i.e. ranges not covered by MTRRs) is specified
by the MTRR default type MSR.

 :
> > > > > > 
> > > MTRR has a bunch of junk that is outside of the scope of the generic
> > > procedure which I'd hope we can skip.
> > 
> > We can skip the part that modifies MTRR setup. I think that is the part
> > you think is a junk.
> 
> Sure, but the more we can avoid any of that code the better. For
> example consider the cleanup patch to increase the chunk size, do we
> even need the cleanup anymore ?

No, I do not think we need it now.  I think this cleanup was needed to
allocate more free slots to MTRRs.  We do not need to care about the number
of free slots as long as the kernel does not insert any new entry to MTRRs.

Thanks,
-Toshi

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

Re: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node

[Paul Durrant]

> -Original Message-
> From: Bob Liu [mailto:bob@oracle.com]
> Sent: 16 March 2016 13:59
> To: Ian Jackson
> Cc: xen-devel@lists.xen.org; Paul Durrant; konrad.w...@oracle.com;
> jgr...@suse.com; Roger Pau Monne; annie...@oracle.com
> Subject: Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
> 
> 
> On 03/16/2016 08:36 PM, Ian Jackson wrote:
> > Bob Liu writes ("[RFC PATCH] blkif.h: document scsi/0x12/0x83 node"):
> >> Sometimes, we need to query VPD page=0x83 data from underlying
> >> storage so that vendor supplied software can run inside the VM and
> >> believe it's talking to the vendor's own storage.  But different
> >> vendors may have different special features, so it's not suitable to
> >> export through "feature-".
> >>
> >> One solution is query the whole VPD page through Xenstore node, which
> has
> >> already been used by windows pv driver.
> >>
> http://xenbits.xen.org/gitweb/?p=pvdrivers/win/xenvbd.git;a=blob;f=src/x
> envbd/pdoinquiry.c
> >
> > Thanks for your contribution.
> >
> > Thanks also to Konrad for decoding the numbers, which really helps me
> > understand what is going on here and helped me find the relevant
> > references.
> >
> > (For background: I have just double-checked the SCSI spec and: INQUIRY
> > lets you query either the standard page, or one of a number of `vital
> > product data' pages, each identified by an 8-bit page number.  The VPD
> > pages are mostly full of vendor-specific data in vendor-specific
> > format.)
> >
> > I have some qualms about the approach you have adopted.  It is
> > difficult to see how this feature could be used safely without
> > knowledge specific to the storage vendor.
> >
> > But I think it is probably OK to define a specification along these
> > lines provided that it is very clear that if you aren't the storage
> > vendor and you use this and something breaks, you get to keep all the
> > pieces.
> >
> >> + * scsi/0x12/0x83
> >> + *Values: string
> >> + *A base64 formatted string providing VPD pages read out from
> backend
> >> + *device.
> >
> > I think this probably isn't the prettiest name for this node or
> > necessarily the best format but given that this protocol is already
> > deployed, and this syntax will do, I don't want to quibble.
> >
> > I would like the base64 encoding to specified much more explicitly.
> > Just `base64 formatted' is too vague.
> >
> >
> >> + *The backend driver or the toolstack should write this node with 
> >> VPD
> >> + *informations when attaching devices.
> >
> > I think this is the wrong semantics.  I certainly don't want to
> > encourage backends to use this feature.
> >
> > Rather, I would prefer something like this:
> >
> >  * scsi/0x12/0x
> >
> >This optional node contains SCSI INQUIRY VPD information.
> > is the hexadecimal representation of the VPD page code.
> >
> >A frontend which represents a Xen VBD to its containing operating
> >system as a (virtual) SCSI target may return the specified data in
> >response to INQUIRY commands from its containing OS.
> >
> >A frontend which supports this feature must return the backend-
> >specified data for every INQUIRY command with the EVPD bit set.
> >For EVPD=1 INQUIRY commands where the corresponding xenstore node
> >does not exist, the frontend must report (to its containing OS) an
> >appropriate failure condition.
> >
> >A frontend which does not support this feature (ie, which does not
> >use these xenstore nodes), and which presents as a SCSI target to
> >its containing OS, should support and provide whatever VPD
> >information it considers appropriate, and should disregard these
> >xenstore nodes.
> >
> >A frontend need not - and often will not - present to its
> >containing OS as a device addressable with SCSI CDBs.  Such a
> >frontend has no use for SCSI INQUIRY VPD information.
> >
> >A backend should set this information with caution.  Pages
> >containing device-vendor-specific information should not be
> >specified without the appropriate device-vendor-specific knowledge.
> >
> 
> That's much more clear, thank you very much!
> 
> >
> > Also I have two other observations:
> >
> > Firstly, AFAICT you have not provided any way to set the standard
> > INQUIRY response.  Is it not necessary in your application to provide
> 
> If backends are not encouraged to use this node, then we must have the
> toolstack write this node with the right VPD information.
> Paul mentioned there should be corresponding code in the xapi project, but I
> haven't found out where.
> 
> 
> > synthetic vendorid and productid, at the very least ?
> >
> > Secondly, I think your hope that
> >
> >> blkfront in Linux ... can use the same mechanism.
> >
> > is I think misguided.  blkfront does not present the disk (to the rest
> > of the Linux storage system) as a SCSI device.  Rather, Linux allows
> > blkfront to present as a block 

Re: [Xen-devel] List of projects for 4.7

[Wei Liu]

Trim CC list

On Fri, Mar 18, 2016 at 05:18:11PM +0100, Fabio Fantoni wrote:
> Il 18/03/2016 13:07, Wei Liu ha scritto:
> >Hi all
> >
> >Today is that last posting day for new features. And we are two weeks
> >away from the anticipated freeze date.
> >
> >I've gone through the outstanding patch series on the list and ask for
> >input from various core community members. I've enumerated a list
> >here, which covers several areas of this release and can be used as a
> >guideline.
> >
> >Important and close patch, new features:
> >1. xSplice
> >2. CPUID levelling
> >3. ARM ACPI
> >4. COLO HA
> >5. RTDS per-vcpu parameter setting
> >6. Event driven RTDS
> 
> Hi, what about "Domain snapshot API"? From a fast search I not found recent
> news about it.
> 

There has not been any activity during this cycle. Chunyan mostly worked
on PVUSB passthrough (which was merged this morning).

Wei.

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

[Xen-devel] [PATCH 0/2] Check VT-d Device-TLB flush error

[Quan Xu]

this patch set is a prereq patch set for Patch:'VT-d Device-TLB flush issue'.
Current code would be panic(), when VT-d Device-TLB flush timed out. the panic()
is going to be eliminated, so we must check all kinds of error and all the way 
up
the call trees.

Quan Xu (2):
  IOMMU/MMU: Adjust top level functions for VT-d Device-TLB flush error.
  IOMMU/MMU: Adjust low level functions for VT-d Device-TLB flush error.


This patch set was patch#1/patch#2 of 'VT-d Device-TLB flush issue' v6 patch 
sets.
--Changes in this version:
   * Rebase against efc904263f483026672a5cdf3ccf9be8c4fdaa31.
   * Make a reasonable attempt at splitting things, adjusting top level 
functions first and then
 working the way down to leaf ones.
   * Remove some pointless initializers (Compiler helps me check them).
   * Log error and don't return error value for hardware_domain init and 
crashed system shutdown.
   * when to populate iommu page table for domu, try to tear down the iommu 
page table for iommu
 iotlb flush error.
   * when the flush_iotlb_qi() return value is positive, All we need are:
 -call iommu_flush_write_buffer() only when rc > 0
 -return zero from this function when rc is positive (or 'rc = 0' after 
call iommu_flush_write_buffer()).
   * Fix v4 "VT-d Device-TLB flush issue" unaddressed issue:
 http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg01555.html

 xen/arch/x86/acpi/power.c |  14 ++-
 xen/arch/x86/mm.c |  13 +--
 xen/arch/x86/mm/p2m-ept.c |  12 ++-
 xen/arch/x86/mm/p2m-pt.c  |  12 ++-
 xen/common/grant_table.c  |   5 +-
 xen/common/memory.c   |   5 +-
 xen/drivers/passthrough/amd/iommu_init.c  |  12 ++-
 xen/drivers/passthrough/amd/pci_amd_iommu.c   |   2 +-
 xen/drivers/passthrough/arm/smmu.c|  10 ++-
 xen/drivers/passthrough/iommu.c   |  25 --
 xen/drivers/passthrough/vtd/extern.h  |   2 +-
 xen/drivers/passthrough/vtd/iommu.c   | 120 ++
 xen/drivers/passthrough/vtd/quirks.c  |  26 +++---
 xen/drivers/passthrough/vtd/x86/vtd.c |   7 +-
 xen/drivers/passthrough/x86/iommu.c   |   6 +-
 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h |   2 +-
 xen/include/asm-x86/iommu.h   |   2 +-
 xen/include/xen/iommu.h   |  12 +--
 18 files changed, 199 insertions(+), 88 deletions(-)

-- 
1.9.1


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

Re: [Xen-devel] [PATCH v2 0/5] xen: avoid module usage in non-modular code

[Paul Gortmaker]

[[PATCH v2 0/5] xen: avoid module usage in non-modular code] On 21/02/2016 (Sun 
19:06) Paul Gortmaker wrote:

> This series of commits is a part of a larger project to ensure
> people don't reference modular support functions in non-modular
> code.  Overall there was roughly 5k lines of dead code in the
> kernel due to this.  So far we've fixed several areas, like tty,
> x86, net, ... and we continue to work on other areas.

Just wondering if this is still pending for this merge window; Stefano
had reviewed the two commits he wanted changed vs. v1 and this v2 was
sent approximately a month ago w/o any further change requests.

Thanks,
Paul.
--

> 
> There are several reasons to not use module support for code that
> can never be built as a module, but the big ones are:
> 
>  (1) it is easy to accidentally write unused module_exit and remove code
>  (2) it can be misleading when reading the source, thinking it can be
>   modular when the Makefile and/or Kconfig prohibit it
>  (3) it requires the include of the module.h header file which in turn
>  includes nearly everything else.
>  (4) it gets copied/replicated into other code and spreads like weeds.
> 
> For the xen subsystem, there are just five commits:
> 
> First, we get rid of "include " instances that are
> completely unnecessary.
> 
> Then #2 and #3 and #5 are basically trivial remapping to the
> appropriate non-modular counterparts, meaning that there is no
> runtime change here either.
> 
> The fourth hypervisor commit is similar, but also has removal of
> some dead code associated with the module_exit function that will
> never be called.  So the runtime should be the same, but the object
> file will be different (reduced in size).
> 
> Patches created on linux-next and build tested for x86-64 and ARM64
> allmodconfig.
> 
> ---
> 
> [v2: manually inline one-liners in #4; update probe vs init fcn names
>  in #5 ; both suggestions by Stefano ; add Reviewed tags to #1, #2, #3.
>  Redid build testing on x86-64 and ARM64 to test for typos etc.  ]
> 
> Cc: Boris Ostrovsky 
> Cc: David Vrabel 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Russell King 
> Cc: Stefano Stabellini 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: xen-de...@lists.xenproject.org
> 
> Paul Gortmaker (5):
>   xen: audit usages of module.h ; remove unnecessary instances
>   drivers/xen: make [xen-]ballon explicitly non-modular
>   drivers/xen: make xenbus_dev_[front/back]end explicitly non-modular
>   drivers/xen: make sys-hypervisor.c explicitly non-modular
>   drivers/xen: make platform-pci.c explicitly non-modular
> 
>  arch/arm/include/asm/xen/hypercall.h |  2 ++
>  drivers/xen/balloon.c|  4 
>  drivers/xen/events/events_2l.c   |  1 -
>  drivers/xen/events/events_base.c |  2 +-
>  drivers/xen/events/events_fifo.c |  1 -
>  drivers/xen/features.c   |  2 +-
>  drivers/xen/grant-table.c|  1 -
>  drivers/xen/platform-pci.c   | 16 ++--
>  drivers/xen/sys-hypervisor.c | 31 ---
>  drivers/xen/xen-balloon.c| 14 +++---
>  drivers/xen/xen-pciback/conf_space.c |  2 +-
>  drivers/xen/xen-pciback/pciback_ops.c|  2 +-
>  drivers/xen/xen-pciback/xenbus.c |  2 +-
>  drivers/xen/xen-selfballoon.c|  1 -
>  drivers/xen/xenbus/xenbus_dev_backend.c  | 13 ++---
>  drivers/xen/xenbus/xenbus_dev_frontend.c | 13 ++---
>  drivers/xen/xenbus/xenbus_xs.c   |  1 -
>  drivers/xen/xenfs/xensyms.c  |  1 -
>  18 files changed, 24 insertions(+), 85 deletions(-)
> 
> -- 
> 2.6.1
> Paul Gortmaker (5):
>   xen: audit usages of module.h ; remove unnecessary instances
>   drivers/xen: make [xen-]ballon explicitly non-modular
>   drivers/xen: make xenbus_dev_[front/back]end explicitly non-modular
>   drivers/xen: make sys-hypervisor.c explicitly non-modular
>   drivers/xen: make platform-pci.c explicitly non-modular
> 
>  arch/arm/include/asm/xen/hypercall.h |  2 ++
>  drivers/xen/balloon.c|  4 ---
>  drivers/xen/events/events_2l.c   |  1 -
>  drivers/xen/events/events_base.c |  2 +-
>  drivers/xen/events/events_fifo.c |  1 -
>  drivers/xen/features.c   |  2 +-
>  drivers/xen/grant-table.c|  1 -
>  drivers/xen/platform-pci.c   | 22 +---
>  drivers/xen/sys-hypervisor.c | 59 
> +---
>  drivers/xen/xen-balloon.c| 14 ++--
>  drivers/xen/xen-pciback/conf_space.c |  2 +-
>  drivers/xen/xen-pciback/pciback_ops.c|  2 +-
>  drivers/xen/xen-pciback/xenbus.c |  2 +-
>  drivers/xen/xen-selfballoon.c|  1 -
>  drivers/xen/xenbus/xenbus_dev_backend.c  | 13 ++-
>  

Re: [Xen-devel] Patching error while setting up COLO

[Yu-An(Victor) Chen]

Hi,

I have a question about the network setup with COLO.

so in the colo page(
http://wiki.xenproject.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping)

it shows a network topology graph:

master:
br0: 192.168.0.33
eth1: 192.168.1.33
eth2: 192.168.2.33

slave:
br0: 192.168.0.88
br1: no ip address
eth1: 192.168.1.88
eth2: 192.168.2.88


Just from the master and slave configuration the page provided. I cannot
see how the two servers are going to communicate with each other if the
bridge's ip is different from both eth1 and eth2. can anybody provide a
hint how this works? Thank you!

Victor


On Tue, Mar 15, 2016 at 11:06 PM, Yu-An(Victor) Chen 
wrote:

> Hi Changlong,
>
> Thanks for the reply, the script works now. Now I have a question about
> the network setup: according to the website
>  you
> sent me, colo network interfaces between two servers should be set up like
> the following? is there any other detail regarding networking I might be
> missing? Thank you!
>
> master:
> br0: 192.168.0.33
> eth1: 192.168.1.33
> eth2: 192.168.2.33
>
> slave:
> br0: 192.168.0.88
> br1: no ip address
> eth1: 192.168.1.88
> eth2: 192.168.2.88
>
>
> Victor
>
> On Mon, Mar 14, 2016 at 1:36 AM, Changlong Xie 
> wrote:
>
>> On 03/09/2016 06:57 AM, Yu-An(Victor) Chen wrote:
>>
>>> Sorry for the duplicated email Congyang, I forgot to replied all:
>>>
>>> Hi Congyang,
>>>
>>> Thank you for the hint, after building xen, your script works for
>>> qemu-xen!
>>>
>>> so now I am trying to set up the secondary node with the script provided
>>> by
>>> Changlong in his first reply:
>>>
>>> ---
>>> rm -f /var/log/xen/*
>>> rm -f /var/lib/xen/userdata-d.*
>>> service xencommons start
>>> modprobe xt_SECCOLO
>>>
>>>
>>>
>>> *active_disk=/mnt/ramfs/active_disk.imghidden_disk=/mnt/ramfs/hidden_disk.imglocal_img=/root/xie/suse-64hvm.img*
>>> tmp_disk_size=`./qemu-colo/qemu-img info $local_img |grep 'virtual size'
>>> |awk  '{print $3}'`
>>> rm -rf /mnt/ramfs/*
>>> umount /mnt/ramfs/
>>> rm -rf /mnt/ramfs/
>>> mkdir /mnt/ramfs
>>> function create_image()
>>> {
>>>  /root/xie/xen/tools/qemu-xen-dir/qemu-img create -f qcow2 $1
>>> $tmp_disk_size
>>> }
>>> function prepare_temp_images()
>>> {
>>>  grep -q "^none /mnt/ramfs ramfs" /proc/mounts
>>>  if [[ $? -ne 0 ]]; then
>>>  mount -t ramfs none /mnt/ramfs/ -o size=2G
>>>  fi
>>>
>>>  if [[ ! -e $active_disk ]]; then
>>>  create_image $active_disk
>>>  fi
>>>
>>>  if [[ ! -e $hidden_disk ]]; then
>>>  create_image $hidden_disk
>>>  fi
>>> }
>>>
>>> ---
>>>
>>> I have question about for the codes below:
>>>
>>>
>>>
>>>
>>> *active_disk=/mnt/ramfs/active_disk.imghidden_disk=/mnt/ramfs/hidden_disk.imglocal_img=/root/xie/suse-64hvm.img*
>>>
>>> Do I have to create my own image and put the img in that location? if so
>>> what kind of img specifically?
>>>
>>
>> The scripts will create "/mnt/ramfs/active_disk.img" and
>> "/mnt/ramfs/hidden_disk.img" automaticly. You need create Domain U image by
>> yourself
>>
>> Thanks
>> -Xie
>>
>>
>>> because when I look into /mnt/ramfs, it is an empty directory.
>>>
>>> Thank you!
>>>
>>> On Sun, Mar 6, 2016 at 5:12 PM, Wen Congyang 
>>> wrote:
>>>
>>> On 03/05/2016 09:51 AM, Yu-An(Victor) Chen wrote:

> Hi Congyang,
>
> Thanks for your reply,
>
> even with your script, and I modify the "path_to_xen_source" to point
>
 where my xen directory is. I still got this error.

>
> ERROR: User requested feature xen
> configure was not able to find it.
> Install xen devel
>
> What do you think what I am missing? Thank you!
>

 Do you build xen before?

 Thanks
 Wen Congyang


> Victor
>
>
>
> On Thu, Mar 3, 2016 at 6:15 PM, Wen Congyang 
 > wrote:

>
>  On 03/04/2016 10:01 AM, Yu-An(Victor) Chen wrote:
>  > Hi,
>  >
>  > So I git clone
>

 https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_wencongyang_qemu-2Dxen.git=CwICaQ=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI=IitX1U91-NhsQt0q4MJOLQ=4j1T2HKL4uKodf62b4Tz1XtOvX81uAqCqfOcD90CRAY=s0fo5ej8_vZ1PmOkDCuyIroS5Zi_KpDSHI8jqodSmrg=

>  >
>  > but i only see branch "con-xen-v2" instead of " colo-xen-v2" so
> I
>
 assume I use just use con-xen-v2.

>  >
>  > But then the following step:
>  >
>  > in both ~/qemu-colo and ~/qemu-xen
>  >
>  > ./configure --enable-xen --target-list=x86_64-softmmu
>
 

Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

[Jan Beulich]

>>> On 17.03.16 at 13:44,  wrote:
> On 03/17/16 05:04, Jan Beulich wrote:
>> >>> On 17.03.16 at 09:58,  wrote:
>> > On 03/16/16 09:23, Jan Beulich wrote:
>> >> >>> On 16.03.16 at 15:55,  wrote:
>> >> > On 03/16/16 08:23, Jan Beulich wrote:
>> >> >> >>> On 16.03.16 at 14:55,  wrote:
>> >> >> > On 03/16/16 07:16, Jan Beulich wrote:
>> >> >> >> And
>> >> >> >> talking of fragmentation - how do you mean to track guest
>> >> >> >> permissions for an unbounded number of address ranges?
>> >> >> >>
>> >> >> > 
>> >> >> > In this case range structs in iomem_caps for NVDIMMs may consume a 
>> >> >> > lot
>> >> >> > of memory, so I think they are another candidate that should be put 
>> >> >> > in
>> >> >> > the reserved area on NVDIMM. If we only allow to grant access
>> >> >> > permissions to NVDIMM page by page (rather than byte), the number of
>> >> >> > range structs for each NVDIMM in the worst case is still decidable.
>> >> >> 
>> >> >> Of course the permission granularity is going to by pages, not
>> >> >> bytes (or else we couldn't allow the pages to be mapped into
>> >> >> guest address space). And the limit on the per-domain range
>> >> >> sets isn't going to be allowed to be bumped significantly, at
>> >> >> least not for any of the existing ones (or else you'd have to
>> >> >> prove such bumping can't be abused).
>> >> > 
>> >> > What is that limit? the total number of range structs in per-domain
>> >> > range sets? I must miss something when looking through 'case
>> >> > XEN_DOMCTL_iomem_permission' of do_domctl() and didn't find that
>> >> > limit, unless it means alloc_range() will fail when there are lots of
>> >> > range structs.
>> >> 
>> >> Oh, I'm sorry, that was a different set of range sets I was
>> >> thinking about. But note that excessive creation of ranges
>> >> through XEN_DOMCTL_iomem_permission is not a security issue
>> >> just because of XSA-77, i.e. we'd still not knowingly allow a
>> >> severe increase here.
>> >>
>> > 
>> > I didn't notice that multiple domains can all have access permission
>> > to an iomem range, i.e. there can be multiple range structs for a
>> > single iomem range. If range structs for NVDIMM are put on NVDIMM,
>> > then there would be still a huge amount of them on NVDIMM in the worst
>> > case (maximum number of domains * number of NVDIMM pages).
>> > 
>> > A workaround is to only allow a range of NVDIMM pages be accessed by a
>> > single domain. Whenever we add the access permission of NVDIMM pages
>> > to a domain, we also remove the permission from its current
>> > grantee. In this way, we only need to put 'number of NVDIMM pages'
>> > range structs on NVDIMM in the worst case.
>> 
>> But will this work? There's a reason multiple domains are permitted
>> access: The domain running qemu for the guest, for example,
>> needs to be able to access guest memory.
>>
> 
> QEMU now only maintains ACPI tables and emulates _DSM for vNVDIMM
> which both do not need to access NVDIMM pages mapped to guest.

For one - this was only an example. And then - iirc qemu keeps
mappings of certain guest RAM ranges. If I'm remembering this
right, then why would it be excluded that it also may need
mappings of guest NVDIMM?

>> No matter how much you and others are opposed to this, I can't
>> help myself thinking that PMEM regions should be treated like RAM
>> (and hence be under full control of Xen), whereas PBLK regions
>> could indeed be treated like MMIO (and hence partly be under the
>> control of Dom0).
>>
> 
> Hmm, making Xen has full control could at least make reserving space
> on NVDIMM easier. I guess full control does not include manipulating
> file systems on NVDIMM which can be still left to dom0?
> 
> Then there is another problem (which also exists in the current
> design): does Xen need to emulate NVDIMM _DSM for dom0? Take the _DSM
> that access label storage area (for namespace) for example:
> 
> The way Linux reserving space on pmem mode NVDIMM is to leave the
> reserved space at the beginning of pmem mode NVDIMM and create a pmem
> namespace which starts from the end of the reserved space. Because the
> reservation information is written in the namespace in the NVDIMM
> label storage area, every OS that follows the namespace spec would not
> mistakenly write files in the reserved area. I prefer to the same way
> if Xen is going to do the reservation. We definitely don't want dom0
> to break the label storage area, so Xen seemingly needs to emulate the
> corresponding _DSM functions for dom0? If so, which part, the
> hypervisor or the toolstack, should do the emulation?

I don't think I can answer all but the very last point: Of course this
can't be done in the tool stack, since afaict the Dom0 kernel will
want to evaluate _DSM before the tool stack even runs.

Jan

___
Xen-devel mailing list

[Xen-devel] [linux-4.1 test] 86441: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 66399
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 66399
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeat fail REGR. vs. 66399
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail REGR. vs. 66399

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-xsm  11 guest-startfail in 85641 pass in 86441
 test-armhf-armhf-xl-credit2   6 xen-boot   fail in 85641 pass in 86441
 test-armhf-armhf-xl   15 guest-start/debian.repeat fail in 85641 pass in 86441
 test-armhf-armhf-xl-multivcpu 16 guest-start.2 fail in 86270 pass in 85972
 test-armhf-armhf-xl-credit2  11 guest-startfail in 86270 pass in 86441
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail pass in 85641
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat  fail pass in 86270
 test-armhf-armhf-xl-rtds 11 guest-start fail pass in 86392

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 85641 like 66399
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66399
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 66399
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 66399
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 66399
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   like 66399

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 85641 never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 85641 never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass

version targeted for testing:
 linuxb9a9cfdbf7254f4a231cc8ddf685cc29d3a9c6e5
baseline version:
 linux07cc49f66973f49a391c91bf4b158fa0f2562ca8

Last test of basis66399  2015-12-15 18:20:39 Z   93 days
Failing since 78925  2016-01-24 13:50:39 Z   53 days   57 attempts
Testing same since85582  2016-03-06 13:53:34 Z   11 days   15 attempts


431 people touched revisions under test,
not listing them all

jobs:
 

[Xen-devel] [PATCH 4/5] x86/time: refactor read_platform_stime()

[Joao Martins]

To fetch the last read from the clocksource which was used to
calculate system_time. In the case of clocksource=tsc we will
use it to set tsc_timestamp.

Signed-off-by: Joao Martins 
---
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/time.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 5af8902..89c35d0 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -508,6 +508,7 @@ static s_time_t stime_platform_stamp; /* System time at 
below platform time */
 static u64 platform_timer_stamp;  /* Platform time at above system time */
 static u64 plt_stamp64;  /* 64-bit platform counter stamp   */
 static u64 plt_stamp;/* hardware-width platform counter stamp   */
+static u64 plt_stamp_counter;/* last read since read_counter */
 static struct timer plt_overflow_timer;
 
 static s_time_t __read_platform_stime(u64 platform_time)
@@ -566,7 +567,7 @@ static void plt_overflow(void *unused)
 set_timer(_overflow_timer, NOW() + plt_overflow_period);
 }
 
-static s_time_t read_platform_stime(void)
+static s_time_t read_platform_stime(u64 *stamp)
 {
 u64 count;
 s_time_t stime;
@@ -574,8 +575,11 @@ static s_time_t read_platform_stime(void)
 ASSERT(!local_irq_is_enabled());
 
 spin_lock(_timer_lock);
-count = plt_stamp64 + ((plt_src.read_counter() - plt_stamp) & plt_mask);
+plt_stamp_counter = plt_src.read_counter();
+count = plt_stamp64 + ((plt_stamp_counter - plt_stamp) & plt_mask);
 stime = __read_platform_stime(count);
+if (stamp)
+*stamp = plt_stamp_counter;
 spin_unlock(_timer_lock);
 
 return stime;
@@ -693,7 +697,7 @@ void cstate_restore_tsc(void)
 if ( boot_cpu_has(X86_FEATURE_NONSTOP_TSC) )
 return;
 
-write_tsc(stime2tsc(read_platform_stime()));
+write_tsc(stime2tsc(read_platform_stime(NULL)));
 }
 
 /***
@@ -1012,7 +1016,7 @@ int cpu_frequency_change(u64 freq)
 
 local_irq_disable();
 /* Platform time /first/, as we may be delayed by platform_timer_lock. */
-t->stime_master_stamp = read_platform_stime();
+t->stime_master_stamp = read_platform_stime(NULL);
 /* TSC-extrapolated time may be bogus after frequency change. */
 /*t->stime_local_stamp = get_s_time();*/
 t->stime_local_stamp = t->stime_master_stamp;
@@ -1330,7 +1334,7 @@ static void time_calibration_tsc_rendezvous(void *_r)
 
 if ( r->master_stime == 0 )
 {
-r->master_stime = read_platform_stime();
+r->master_stime = read_platform_stime(NULL);
 r->master_tsc_stamp = rdtsc();
 }
 atomic_inc(>semaphore);
@@ -1422,7 +1426,7 @@ void init_percpu_time(void)
 
 local_irq_save(flags);
 t->local_tsc_stamp = rdtsc();
-now = read_platform_stime();
+now = read_platform_stime(NULL);
 local_irq_restore(flags);
 
 t->stime_master_stamp = now;
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v7 for Xen 4.7 1/4] xen: enable per-VCPU parameter settings for RTDS scheduler

[Jan Beulich]

>>> On 17.03.16 at 21:42,  wrote:
> On Thu, Mar 17, 2016 at 5:03 AM, Dario Faggioli
>  wrote:
>> On Wed, 2016-03-16 at 11:47 -0500, Chong Li wrote:
> 
>>
>>> --- a/xen/common/sched_rt.c
>>> +++ b/xen/common/sched_rt.c
>>> @@ -1129,24 +1145,22 @@ rt_dom_cntl(
>>>  struct vcpu *v;
>>>  unsigned long flags;
>>>  int rc = 0;
>>> +xen_domctl_schedparam_vcpu_t local_sched;
>>> +s_time_t period, budget;
>>> +uint32_t index = 0;
>>>
>>>  switch ( op->cmd )
>>>  {
>>>  case XEN_DOMCTL_SCHEDOP_getinfo:
>>> -if ( d->max_vcpus > 0 )
>>> -{
>>> -spin_lock_irqsave(>lock, flags);
>>> -svc = rt_vcpu(d->vcpu[0]);
>>> -op->u.rtds.period = svc->period / MICROSECS(1);
>>> -op->u.rtds.budget = svc->budget / MICROSECS(1);
>>> -spin_unlock_irqrestore(>lock, flags);
>>> -}
>>> -else
>>> -{
>>> -/* If we don't have vcpus yet, let's just return the
>>> defaults. */
>>> -op->u.rtds.period = RTDS_DEFAULT_PERIOD;
>>> -op->u.rtds.budget = RTDS_DEFAULT_BUDGET;
>>> -}
>>> +/* Return the default parameters.
>>> + * A previous bug fixed here:
>>> + * The default PERIOD or BUDGET should be divided by
>>> MICROSECS(1),
>>> + * before returned to upper caller.
>>> + */
>> Comment style (missing opening '/*').
>>
>> Also, putting this kind of things in comments is not at all ideal. If
>> doing this in this patch, you should mention it in the changelog. Or
>> you do it in a separate patch (that you put before this one in the
>> series).
>>
>> I'd say that, in this specific case, is not a big deal which one of the
>> two approaches you take (mentioning or separate patch), but the having
>> a separate one is indeed almost always preferable (e.g., the fix can be
>> backported).
> 
> If I choose mentioning, do I move the comment to the changelog? Or do I keep
> it here and say it again in the changelog?

Just consider what would happen if everyone mentioned in
comments the bugs they fixed. I think the answer to you question
is obvious then...

Jan


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

[Xen-devel] [xen-unstable test] 86376: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail   like 86315
 build-i386-rumpuserxen6 xen-buildfail   like 86315
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 86315
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 86315
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 86315
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 86315
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 86315

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

version targeted for testing:
 xen  efc904263f483026672a5cdf3ccf9be8c4fdaa31
baseline version:
 xen  c2b9b97775e9de061dd72b22fb96293daaa77f98

Last test of basis86315  2016-03-15 13:05:53 Z1 days
Testing same since86376  2016-03-16 07:21:55 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  David Vrabel 
  Edgar E. Iglesias 
  Jan Beulich 
  Kevin Tian 
  Konrad Rzeszutek Wilk 
  Malcolm Crossley 
  Ross Lagerwall 
  Stefano Stabellini 

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

Re: [Xen-devel] [PATCH v3 21/28] xen+tools: Export maximum host and guest cpu featuresets via SYSCTL

[Wei Liu]

On Tue, Mar 15, 2016 at 03:35:17PM +, Andrew Cooper wrote:
> And provide stubs for toolstack use.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Tim Deegan 
> CC: Wei Liu 
> CC: David Scott 
> CC: Rob Hoes 
> 
> v3:
>  * Provide libxc implementation for XEN_SYSCTL_get_cpu_levelling_caps as well.
> v2:
>  * Rebased to use libxencall
>  * Improve hypercall documentation
> ---
>  tools/libxc/include/xenctrl.h   |  4 +++
>  tools/libxc/xc_cpuid_x86.c  | 41 +

Acked-by: Wei Liu 

>  tools/ocaml/libs/xc/xenctrl.ml  |  3 +++
>  tools/ocaml/libs/xc/xenctrl.mli |  4 +++
>  tools/ocaml/libs/xc/xenctrl_stubs.c | 35 +

The ocaml wrappers also look sensible. But admittedly my ocaml skill is
limited so I will defer those to Dave or Rob.

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

[Xen-devel] rcu_sched self-detected stall on CPU on kernel 4.4.5 in PV DomU

[Steven Haigh]

Hi all,

I've noticed the following problem that ends up with a non-repsonsive PV
DomU using kernel 4.4.5 under heavy disk IO:

INFO: rcu_sched self-detected stall on CPU
0-...: (6759098 ticks this GP) idle=cb3/141/0
softirq=3244615/3244615 fqs=4
 (t=6762321 jiffies g=2275626 c=2275625 q=54)
rcu_sched kthread starved for 6762309 jiffies! g2275626 c2275625 f0x0 s3
->state=0x0
Task dump for CPU 0:
updatedbR  running task0  6027   6021 0x0088
 818d0c00 88007fc03c58 810a625f 
 818d0c00 88007fc03c70 810a8699 0001
 88007fc03ca0 810d0e5a 88007fc170c0 818d0c00
Call Trace:
   [] sched_show_task+0xaf/0x110
 [] dump_cpu_task+0x39/0x40
 [] rcu_dump_cpu_stacks+0x8a/0xc0
 [] rcu_check_callbacks+0x424/0x7a0
 [] ? account_system_time+0x81/0x110
 [] ? account_process_tick+0x61/0x160
 [] ? tick_sched_do_timer+0x30/0x30
 [] update_process_times+0x39/0x60
 [] tick_sched_handle.isra.15+0x36/0x50
 [] tick_sched_timer+0x3d/0x70
 [] __hrtimer_run_queues+0xf2/0x250
 [] hrtimer_interrupt+0xa8/0x190
 [] xen_timer_interrupt+0x2e/0x140
 [] handle_irq_event_percpu+0x55/0x1e0
 [] handle_percpu_irq+0x3a/0x50
 [] generic_handle_irq+0x22/0x30
 [] __evtchn_fifo_handle_events+0x15f/0x180
 [] evtchn_fifo_handle_events+0x10/0x20
 [] __xen_evtchn_do_upcall+0x43/0x80
 [] xen_evtchn_do_upcall+0x30/0x50
 [] xen_hvm_callback_vector+0x82/0x90
   [] ? queued_spin_lock_slowpath+0x10/0x170
 [] _raw_spin_lock+0x20/0x30
 [] find_inode_fast+0x61/0xa0
 [] iget_locked+0x6e/0x170
 [] ext4_iget+0x33/0xae0
 [] ? out_of_line_wait_on_bit+0x72/0x80
 [] ext4_iget_normal+0x30/0x40
 [] ext4_lookup+0xd5/0x140
 [] lookup_real+0x1d/0x50
 [] __lookup_hash+0x33/0x40
 [] walk_component+0x177/0x280
 [] path_lookupat+0x60/0x110
 [] filename_lookup+0x9c/0x150
 [] ? kfree+0x10d/0x290
 [] ? call_filldir+0x9c/0x130
 [] ? getname_flags+0x4f/0x1f0
 [] user_path_at_empty+0x36/0x40
 [] vfs_fstatat+0x53/0xa0
 [] ? __fput+0x169/0x1d0
 [] SYSC_newlstat+0x22/0x40
 [] ? __audit_syscall_exit+0x1f0/0x270
 [] ? syscall_slow_exit_work+0x3f/0xc0
 [] ? __audit_syscall_entry+0xaf/0x100
 [] SyS_newlstat+0xe/0x10
 [] entry_SYSCALL_64_fastpath+0x12/0x71

This ends up with the system not responding at 100% CPU usage.

Has anyone else seen this using kernel 4.4.5 in a DomU?

-- 
Steven Haigh

Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v7 1/2] VT-d: Reduce spin timeout to 1ms, which can be boot-time changed

[Xu, Quan]

On March 17, 2016 4:14pm,  wrote:
> >>> On 17.03.16 at 09:11,  wrote:
> > On March 17, 2016 3:45pm, Tian, Kevin  wrote:
> >> > From: Xu, Quan
> >> > Sent: Thursday, March 17, 2016 3:13 PM diff --git
> >> > a/xen/drivers/passthrough/vtd/qinval.c
> >> > b/xen/drivers/passthrough/vtd/qinval.c
> >> > index b81b0bd..37a15fb 100644
> >> > --- a/xen/drivers/passthrough/vtd/qinval.c
> >> > +++ b/xen/drivers/passthrough/vtd/qinval.c
> >> > @@ -28,6 +28,11 @@
> >> >  #include "vtd.h"
> >> >  #include "extern.h"
> >> >
> >> > +static unsigned int __read_mostly vtd_qi_timeout = 1;
> >> > +integer_param("vtd_qi_timeout", vtd_qi_timeout);
> >> > +
> >> > +#define IOMMU_QI_TIMEOUT (vtd_qi_timeout * MILLISECS(1))
> >> > +
> >> >  static void print_qi_regs(struct iommu *iommu)  {
> >> >  u64 val;
> >> > @@ -130,10 +135,14 @@ static void queue_invalidate_iotlb(struct
> >> > iommu
> >> *iommu,
> >> >  spin_unlock_irqrestore(>register_lock, flags);  }
> >> >
> >> > +/*
> >> > + * NB. We must check all kinds of error and all the way up the
> >> > + * call trees.
> >> > + */
> >>
> >> This comment is meaningless put in the code. It just reflects what
> >> you need
> > do
> >> to push the whole patch series, but it's obvious a straightforward
> > requirement.
> >>
> > Kevin,
> > This is for Jan requirement:
> >
> > http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg02388.h
> > tml
> > Jan said:
> > """ Without a __must_check annotation on the function I cannot see how
> > I should reasonably convince myself that all call sites now handle
> > such an error in one way or another."""
> >
> > Now I think I misunderstood what Jan said. It may be:
> >
> > + static int __must_check queue_invalidate_wait(struct iommu *iommu,
> > + u8
> > iflag, u8 sw, u8 fn)
> >
> > I found that there is a '__must_check' in xen code.
> 
> Indeed that's what I meant.
> 
Sorry:(.. I will fix it next v8.
Quan

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

[Xen-devel] [PATCH v6 17/17] Xen: EFI: Parse DT parameters for Xen specific UEFI

[Shannon Zhao]

From: Shannon Zhao 

Add a new function to parse DT parameters for Xen specific UEFI just
like the way for normal UEFI. Then it could reuse the existing codes.

If Xen supports EFI, initialize runtime services.

Signed-off-by: Shannon Zhao 
Reviewed-by: Matt Fleming 
Reviewed-by: Stefano Stabellini 
---
CC: Matt Fleming 
---
 arch/arm/xen/enlighten.c   |  6 +
 drivers/firmware/efi/arm-runtime.c | 17 +-
 drivers/firmware/efi/efi.c | 45 --
 3 files changed, 56 insertions(+), 12 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index c43617f..9d52342b 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -261,6 +261,12 @@ static int __init fdt_find_hyper_node(unsigned long node, 
const char *uname,
!strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
hyper_node.version = s + strlen(hyper_node.prefix);
 
+   if (IS_ENABLED(CONFIG_XEN_EFI)) {
+   /* Check if Xen supports EFI */
+   if (of_get_flat_dt_subnode_by_name(node, "uefi") > 0)
+   set_bit(EFI_PARAVIRT, );
+   }
+
return 0;
 }
 
diff --git a/drivers/firmware/efi/arm-runtime.c 
b/drivers/firmware/efi/arm-runtime.c
index 6ae21e4..ac609b9 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 extern u64 efi_system_table;
 
@@ -107,13 +108,19 @@ static int __init arm_enable_runtime_services(void)
}
set_bit(EFI_SYSTEM_TABLES, );
 
-   if (!efi_virtmap_init()) {
-   pr_err("No UEFI virtual mapping was installed -- runtime 
services will not be available\n");
-   return -ENOMEM;
+   if (IS_ENABLED(CONFIG_XEN_EFI) && efi_enabled(EFI_PARAVIRT)) {
+   /* Set up runtime services function pointers for Xen Dom0 */
+   xen_efi_runtime_setup();
+   } else {
+   if (!efi_virtmap_init()) {
+   pr_err("No UEFI virtual mapping was installed -- 
runtime services will not be available\n");
+   return -ENOMEM;
+   }
+
+   /* Set up runtime services function pointers */
+   efi_native_runtime_setup();
}
 
-   /* Set up runtime services function pointers */
-   efi_native_runtime_setup();
set_bit(EFI_RUNTIME_SERVICES, );
 
efi.runtime_version = efi.systab->hdr.revision;
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 2cd37da..1328cb7 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -500,12 +500,14 @@ device_initcall(efi_load_efivars);
FIELD_SIZEOF(struct efi_fdt_params, field) \
}
 
-static __initdata struct {
+struct params {
const char name[32];
const char propname[32];
int offset;
int size;
-} dt_params[] = {
+};
+
+static struct params fdt_params[] __initdata = {
UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
@@ -513,24 +515,45 @@ static __initdata struct {
UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
 };
 
+static struct params xen_fdt_params[] __initdata = {
+   UEFI_PARAM("System Table", "xen,uefi-system-table", system_table),
+   UEFI_PARAM("MemMap Address", "xen,uefi-mmap-start", mmap),
+   UEFI_PARAM("MemMap Size", "xen,uefi-mmap-size", mmap_size),
+   UEFI_PARAM("MemMap Desc. Size", "xen,uefi-mmap-desc-size", desc_size),
+   UEFI_PARAM("MemMap Desc. Version", "xen,uefi-mmap-desc-ver", desc_ver)
+};
+
 struct param_info {
int found;
void *params;
+   struct params *dt_params;
+   int size;
 };
 
 static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
   int depth, void *data)
 {
struct param_info *info = data;
+   struct params *dt_params = info->dt_params;
const void *prop;
void *dest;
u64 val;
-   int i, len;
+   int i, len, offset;
 
-   if (depth != 1 || strcmp(uname, "chosen") != 0)
-   return 0;
+   if (efi_enabled(EFI_PARAVIRT)) {
+   if (depth != 1 || strcmp(uname, "hypervisor") != 0)
+   return 0;
 
-   for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
+   offset = of_get_flat_dt_subnode_by_name(node, "uefi");
+   if (offset < 0)
+   return 0;
+   node = offset;
+   } else {
+   if (depth != 1 || strcmp(uname, "chosen") != 0)
+   return 

Re: [Xen-devel] [PATCH 4/8] libxl: Move check for local access to a funciton

[Ian Jackson]

George Dunlap writes ("[PATCH 4/8] libxl: Move check for local access to a 
funciton"):
> +static char * libxl__device_disk_find_local_path(libxl__gc *gc, 
> + const libxl_device_disk 
> *disk) {
...
> +if (disk->format == LIBXL_DISK_FORMAT_RAW
> +&& disk->script == NULL
> +&& disk->pdev_path) {

libxl__device_disk_local_initiate_attach asserts pdev_path.  Do you
foresee it maybe being NULL and if so how ?

> -rc = libxl__device_disk_setdefault(gc, disk);
> -if (rc) goto out;
> +if(dls->diskpath)
 ^
Missing space.

> +LOG(DEBUG, "Strange, dls->diskpath already set: %s", dls->diskpath);
>  
> -/* If this is in a driver domain, or it's not a raw format, or it 
> involves
> - * running a script, we have to do a local attach. */
> -if (disk->backend_domname != NULL
> -|| disk->format != LIBXL_DISK_FORMAT_RAW
> -|| disk->script != NULL) {
> +LOG(DEBUG, "Trying to find local path");
> +
> +if ((dls->diskpath = libxl__device_disk_find_local_path(gc, in_disk))) {

We normally seem to avoid this kind of   if ((x = ...))  construction
in libxl.

But apart from that and my previous stylistic comments, this patch
looks OK.  I didn't see any other unexpected functional change.

ian.

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

Re: [Xen-devel] [PATCH v3 2/5] arm/config: Declare ELFSIZE_[32|64] respectively.

[Konrad Rzeszutek Wilk]

On Thu, Mar 17, 2016 at 11:04:29AM +, Julien Grall wrote:
> Hi Konrad,
> 
> On 17/03/16 01:16, Konrad Rzeszutek Wilk wrote:
> >And here is the patch. The change for uintXX_t type worked out - same
> >size and offset as on 64-bit. Thought I am tempted to add some
> >more BUILD_BUG checks.
> >
> > From 7007f1a3fa3a77a725f529420c7aea0e8ebdc9fa Mon Sep 17 00:00:00 2001
> >From: Konrad Rzeszutek Wilk 
> >Date: Wed, 16 Mar 2016 16:08:25 -0400
> >Subject: [PATCH v4 01/35] arm/config: Declare ELFSIZE_[32|64]
> >
> >The commit bcfaea685d38c08e5eb90797512ab80f0bc69d0c
> >"arm/config: Declare ELFSIZE_64" was not correct.
> >
> >For 32-bit ARM, ELFCLASS32 (i.e. 32-bit data types) will always
> >be used so we need to set ELFSIZE to 32.
> >
> >Reported-by: Julien Grall 
> >Signed-off-by: Konrad Rzeszutek Wilk 
> 
> Acked-by: Julien Grall 

Thank you. Patch applied.

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

Re: [Xen-devel] [PATCH] xen/events: Mask a moving irq

[Boris Ostrovsky]

On 03/17/2016 01:29 PM, David Vrabel wrote:

On 17/03/16 16:53, Boris Ostrovsky wrote:

On 03/17/2016 12:03 PM, David Vrabel wrote:

On 17/03/16 12:45, Boris Ostrovsky wrote:

Moving an unmasked irq may result in irq handler being invoked on both
source and target CPUs.

With 2-level this can happen as follows:

On source CPU:
  evtchn_2l_handle_events() ->
  generic_handle_irq() ->
  handle_edge_irq() ->
 eoi_pirq():
 irq_move_irq(data);

 /* WE ARE HERE */

 if (VALID_EVTCHN(evtchn))
 clear_evtchn(evtchn);

If at this moment target processor is handling an unrelated event in
evtchn_2l_handle_events()'s loop it may pick up our event since target's
cpu_evtchn_mask claims that this event belongs to it *and* the event is
unmasked and still pending. At the same time, source CPU will continue
executing its own handle_edge_irq().

With FIFO interrupt the scenario is similar: irq_move_irq() may result
in a EVTCHNOP_unmask hypercall which, in turn, may make the event
pending on the target CPU.

We can avoid this situation by moving and clearing the event while
keeping event masked.

Can you do:

 if (unlikely(irqd_is_setaffinity_pending(data))) {
 masked = test_and_set_mask()

 clear_evtchn()
 irq_move_masked_irq()

I did think about this but then I wasn't sure whether this might open
some other window for things to sneak in. It shouldn't but these things
are rather subtle so I'd rather leave the order of how operations are
done unchanged.

This is the order your patch has though.  I'm confused.


Ugh, sorry --- I misread what you wrote, I thought you wanted to clear 
before masking. Which wouldn't make any sense.


So yes, what you are suggesting is better.

-borsi

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

Re: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node

[Bob Liu]

On 03/16/2016 10:07 PM, Paul Durrant wrote:
>> -Original Message-
>> From: Bob Liu [mailto:bob@oracle.com]
..snip..
>>>
>>
>> But we'd like to get the VPD information(of underlying storage device) also 
>> in
>> Linux blkfront, even blkfront is not a SCSI device.
>>
>> That's because our underlying storage device has some vendor-specific
>> features which can be recognized through informations in VPD pages.
>> And Our applications in guest want to aware of these vendor-specific
>> features.
> 
> I think the missing piece of the puzzle is how the applications get this 
> information. 
> In Windows, since everything is a SCSI LUN (or has to emulate one) 
> applications just send down 'scsi pass-through' IOCTLs and get the raw 
> INQUIRY data back. 
> In Linux there would need to be some alternative scheme that presumably 
> blkfront would have to support.
> 

They plan to send a REQ_TYPE_BLOCK_PC request down to blkfront, and hoping 
blkfront can handle this request and return the VPD informations.
I'll confirm weather they can read the xenstore node directly.

-- 
Regards,
-Bob

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

Re: [Xen-devel] [Patch V4 0/3] xen, usb: support pvUSB frontend driver

[Oleksandr Tyshchenko]

Hi Juergen, All.

I would like to apply PVUSB drivers for using in our platform while PVUSB
stuff doesn't reach upstream.

Unfortunately, I couldn't find more recent version of "kernel based"
backend driver in mailing list.
I have found it in v0 only.

[Xen-devel] [PATCH 0/4] xen, usb: support pvUSB drivers


Can I use this frontend driver (v4) together with kernel based backend
driver (v0)?
Are they fully compatible with each other?

Thank you.

On Mon, Jul 20, 2015 at 8:13 AM, Juergen Gross  wrote:

> Ping?
>
>
> On 06/23/2015 08:53 AM, Juergen Gross wrote:
>
>> This series adds XEN guest pvUSB support. With pvUSB it is possible to
>> use physical USB devices from a XEN domain.
>>
>> The support consists of a frontend in form of a virtual hcd driver in
>> the unprivileged domU passing I/O-requests to the backend in a driver
>> domain (usually Dom0). The backend is not part of this patch series,
>> as it will be supported via qemu.
>>
>> The code is taken (and adapted) from the original pvUSB implementation
>> done for Linux 2.6 in 2008 by Fujitsu.
>>
>> Normal operation of USB devices by adding and removing them dynamically
>> to/from a domain has been tested using various USB devices (USB 1.1,
>> 2.0 and 3.0). The pvUSB backend for these tests was a SUSE SLES Dom0
>> with a kernel based backend driver.
>>
>> Changes in V4:
>> - remove sysfs file from frontend, as it violated the "one value per file"
>>rule and didn't serve any real purpose.
>>
>> Changes in V3:
>> - move frontend to drivers/usb/host and rename it to xen-hcd.
>> - changed name prefixes in patch 1 to "xenusb" as requested by Greg
>> - use __u types rather than uint_t as requested by Greg
>>
>> Changes in V2:
>> - removed backend, as it can be implemented in user land
>> - added some access macros and definitions to the pvUSB interface
>>description to make it independant from linux kernel USB internals
>> - adapted frontend to newer kernel version and use new pvUSB
>>interface macros
>> - set port status in one chunk as suggested by Oliver Neukum
>>
>>
>> Juergen Gross (3):
>>usb: Add Xen pvUSB protocol description
>>usb: Introduce Xen pvUSB frontend (xen hcd)
>>xen: add Xen pvUSB maintainer
>>
>>   MAINTAINERS  |8 +
>>   drivers/usb/host/Kconfig |   11 +
>>   drivers/usb/host/Makefile|1 +
>>   drivers/usb/host/xen-hcd.c   | 1594
>> ++
>>   include/xen/interface/io/usbif.h |  252 ++
>>   5 files changed, 1866 insertions(+)
>>   create mode 100644 drivers/usb/host/xen-hcd.c
>>   create mode 100644 include/xen/interface/io/usbif.h
>>
>>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>



-- 

Oleksandr Tyshchenko | Embedded Dev
GlobalLogic
www.globallogic.com

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

[Xen-devel] [PATCH v4 0/2] x86/hvm/viridian: APIC assist

[Paul Durrant]

This patch series enables use of the 'APIC assist' enlightenment in Xen.

See section 13.3.4.1 of the Microsoft Hypervisor Top Level Function
Specification v4.0b at:

https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/develop/tlfs

for more information.

Patch #1 modifies the viridian code to keep the guest APIC assist pages
mapped for the lifetime of the domain (and incorporates a straightforward
data-structure change).

Patch #2 adds a new viridian code and a configuration option to the
toolstack that, when enabled, allows the local APIC emulation to make use
the APIC assist pages.


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

[Xen-devel] [PATCH 2/6] xenalyze: Support for ARM platform

[Benjamin Sanda]

From: bensanda 

Modified to provide building of the xenalyze binary for ARM platforms. This was 
done in conjunction with patches to xentrace allowing its use on ARM. The 
xenalyze binary is now built as part of the SBIN list.

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

diff --git a/tools/xentrace/Makefile b/tools/xentrace/Makefile
index 0157be2..180add4 100644
--- a/tools/xentrace/Makefile
+++ b/tools/xentrace/Makefile
@@ -9,9 +9,8 @@ LDLIBS += $(LDLIBS_libxenevtchn)
 LDLIBS += $(LDLIBS_libxenctrl)
 LDLIBS += $(ARGP_LDFLAGS)
 
-BIN-$(CONFIG_X86) = xenalyze
 BIN  = $(BIN-y)
-SBIN = xentrace xentrace_setsize
+SBIN = xenalyze xentrace xentrace_setsize 
 LIBBIN   = xenctx
 SCRIPTS  = xentrace_format
 
-- 
2.7.2


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 86536

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  2dabe2e03e2ebd7ef28f2c61a019330a172b43a7
baseline version:
 libvirt  9a0c7f5f834185db9017c34aabc03ad99cf37bed

Last test of basis86536  2016-03-18 04:25:19 Z1 days
Testing same since86625  2016-03-19 04:23:22 Z0 days1 attempts


People who touched revisions under test:
  Cole Robinson 
  Jim Fehlig 
  John Ferlan 
  Martin Kletzander 
  Michal Privoznik 

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



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

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

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

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


Not pushing.


commit 2dabe2e03e2ebd7ef28f2c61a019330a172b43a7
Author: Cole Robinson 
Date:   Wed Jan 6 15:44:30 2016 -0500

domain: Remove controller/net address whitelists

Judging by how the whitelist has skewed quite far from the original
error message, I think it's better to just drop these.

If someone wants to revive this check I suggest implementing it on
a per-HV driver basis with PostParse callbacks.

commit d77ffb6876e87a5c6f4c74c49cf0d89ade4f8326
Author: Martin Kletzander 
Date:   Tue Mar 15 12:22:03 2016 +0100

nodedev: Expose PCI header type

If we expose this information, which is one byte in every PCI config
file, we let all mgmt apps know whether the 

Re: [Xen-devel] [PATCH v4 01/34] compat/x86: Remove unncessary #define.

[Jan Beulich]

>>> On 17.03.16 at 01:44,  wrote:
> On Wed, Mar 16, 2016 at 05:08:30AM -0600, Jan Beulich wrote:
>> >>> On 15.03.16 at 18:56,  wrote:
>> > It is not used.
>> 
>> Consistently please - either keep them all (just to cover the case
>> that they might get used) or remove them all: xen_compile_info,
>> xen_changeset_info, etc are all unused too. Otoh
>> xennmi_callback is used, but xennmi_callback_t isn't. Which to me
>> suggests that we should leave this alone.
> 
> Oddly enough taking an cleaver to it was OK.
> 
> From 7e3ed6faed6e083f27ad6be947ac528c3eaba9a1 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk 
> Date: Wed, 2 Mar 2016 12:50:32 -0500
> Subject: [PATCH v4 02/35] compat/x86: Remove unncessary #defines.
> 
> They are not used.

This now goes too far.

> Signed-off-by: Konrad Rzeszutek Wilk 
> Reviewed-by: Andrew Cooper 

Hence this can't stay.

> ---
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Keir Fraser 
> Cc: Tim Deegan 
> 
> v2: Remove a lot more of them.

(Side note: Not only this time round I notice versioning mixup in
your patches: The subject says v4 here, yet the update to it
above says v2. In the previous round of the xSplice series - v3 -
I seem to recall there were patches showing a "history" up to
something like v9. I think in cases of such heavy mixing it should
be the patch with the oldest history that determines the version
of the entire series.)

> --- a/xen/common/compat/kernel.c
> +++ b/xen/common/compat/kernel.c
> @@ -18,30 +18,22 @@ asm(".file \"" __FILE__ "\"");
>  
>  extern xen_commandline_t saved_cmdline;
>  
> -#define xen_extraversion compat_extraversion
>  #define xen_extraversion_t compat_extraversion_t
>  
> -#define xen_compile_info compat_compile_info
>  #define xen_compile_info_t compat_compile_info_t
>  
>  CHECK_TYPE(capabilities_info);
>  
> -#define xen_platform_parameters compat_platform_parameters
>  #define xen_platform_parameters_t compat_platform_parameters_t
>  #undef HYPERVISOR_VIRT_START
>  #define HYPERVISOR_VIRT_START HYPERVISOR_COMPAT_VIRT_START(current->domain)
>  
> -#define xen_changeset_info compat_changeset_info
>  #define xen_changeset_info_t compat_changeset_info_t
>  
> -#define xen_feature_info compat_feature_info
>  #define xen_feature_info_t compat_feature_info_t
>  
>  CHECK_TYPE(domain_handle);
>  
> -#define xennmi_callback compat_nmi_callback
> -#define xennmi_callback_t compat_nmi_callback_t

The former definitely is being used; not getting a compilation
error here is not a sign of things being right. That's another
reason why - as I had suggested already - we'd probably
better leave things as they are: Introduction of uses of the
now removed identifiers might otherwise break compat code
without anyone noticing right away.

Jan


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

Re: [Xen-devel] [PATCH v11 12/27] tools/libx{l, c}: introduce wait_checkpoint callback

[Changlong Xie]

On 03/05/2016 01:03 AM, Ian Jackson wrote:

Changlong Xie writes ("[PATCH v11 12/27] tools/libx{l,c}: introduce wait_checkpoint 
callback"):

From: Wen Congyang 

Under COLO, we are doing checkpoint on demand, if this
callback returns 1, we will take another checkpoint.
0 indicates unexpected error.


This doesn't seem to have a corresponding implementation.  I think the
implementation ought to be in the same patch.



Surely, will merge it in the implement patch in next version

Thanks
-Xie


If 0 is always an `unexpected error', perhaps the return value should
be an error code or something ?  I'm not sure.

Ian.


.





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

[Xen-devel] Xen Security Advisory 171 (CVE-2016-3157) - I/O port access privilege escalation in x86-64 Linux

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Xen Security Advisory CVE-2016-3157 / XSA-171
  version 4

 I/O port access privilege escalation in x86-64 Linux

UPDATES IN VERSION 4


Clarify Vulnerable Systems section.

Public release.

ISSUE DESCRIPTION
=

IRET and POPF do not modify EFLAGS.IOPL when executed by code at a
privilege level other than zero.  Since PV Xen guests run at privilege
level 3 (for 64-bit ones; 32-bit ones run at privilege level 1), to
compensate for this the context switching of EFLAGS.IOPL requires the
guest to make use of a dedicated hypercall (PHYSDEVOP_set_iopl).  The
invocation of this hypercall, while present in the 32-bit context
switch path, is missing from its 64-bit counterpart.

IMPACT
==

User mode processes not supposed to be able to access I/O ports may
be granted such permission, potentially resulting in one or more of
in-guest privilege escalation, guest crashes (Denial of Service), or
in-guest information leaks.

VULNERABLE SYSTEMS
==

All upstream x86-64 Linux versions operating as PV Xen guests are
vulnerable.

ARM systems are not vulnerable.  x86 HVM guests are not vulnerable.
32-bit Linux guests are not vulnerable.

x86-64 Linux versions derived from linux-2.6.18-xen.hg (XenoLinux) are
not vulnerable.

We believe that non-Linux guests are not vulnerable, as we are not
aware of any with an analogous bug.

MITIGATION
==

Running only HVM or 32-bit PV guests will avoid this issue.

CREDITS
===

This issue was discovered by Andy Lutomirski.

RESOLUTION
==

Applying the attached patch resolves this issue for the indicated Linux
versions.

xsa171.patch   Linux 4.5-rc7, Linux 4.4.x

$ sha256sum xsa171*
5d47ead1212c735b444ac8f82e7f311cda3473fe3847e576c3772ce020265dfd  xsa171.patch
$


DEPLOYMENT DURING EMBARGO
=

The patch is a change to the domU, ie, to the guest, not to hosts.


Where the guest kernel is provided by the host administrator
- 

Deployment of the patch by the host administrator is NOT permitted
(except where all the affected systems and VMs are administered and
used only by organisations which are members of the Xen Project
Security Issues Predisclosure List).  Specifically, deployment on
public cloud systems is NOT permitted.

This is because a the cloud guest administrator is almost certainly in
a position to see the changes that are made by to the kernel even if
the kernel is provided by the host administrator.

Deployment is permitted only AFTER the embargo ends.


Where the guest kernel is provided by the guest administrator
- -

Deployment of the patch (or another which is substantially similar) by
the guest administrator is permitted during the embargo ONLY if
 (i) the host administrator organisation is also a member of the Xen
 Project Security Issues Predisclosure List.
 (ii) all the guest's users are also members of predisclosure list.
 (guest users includes administrators of Linux containers running
 within the guest).

Restriction (i) is because the host administrator can see changes that
made to the kernel by a guest administrator.  Restriction (ii) is
because it is difficult to fully conceal the Linux kernel from
unprivileged guest user processes.

If the host is not operated by a member of the predisclosure list, or
the guest has users outside the predisclousre list, deployment is
permitted only AFTER the embargo ends.


In any case
- ---

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

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, or whose situation is not clearly covered
above, please contact the Xen Project Security Team.


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

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

iQEcBAEBAgAGBQJW6a4ZAAoJEIP+FMlX6CvZEs4H/12hKU3NzqfHZb/wOW9PeT4Z
yhGQ2mkVE6FATW15b+/+Lr4N2nIUHa40BtWjPyEOQR4UXJrZr3R5HL/wINRO7c6M
5XNjDyHqmfhOAsHWsrTB0a3CP2wWNNQ6LiBN5AuiUwoqiJiZPLhKCeEi99F+rFFK
IINyOgd4XSeGRkb96GfZcPbizbO3wqiREfBIAjECYchBARv7JVGr3my6R3YBYdTn
VtBratEPdkEmAEn0LtdiQlnjPib5O3paiaIDk41IPbPu1WPiozt3RJSqJUSwu+al
A3qe9cBGz0NyghdYkXQjvaPP+1Q3BjyJC4hgGLo+yqyODPdaFAJZ0mjR/e0uajs=
=F9Nz
-END PGP SIGNATURE-


xsa171.patch
Description: Binary data
___
Xen-devel 

[Xen-devel] [PATCH v3 5/4] x86: reduce code size of struct cpu_info member accesses

[Jan Beulich]

Instead of addressing these fields via the base of the stack (which
uniformly requires 4-byte displacements), address them from the end
(which for everything other than guest_cpu_user_regs requires just
1-byte ones). This yields a code size reduction somewhere between 8k
and 12k in my builds.

Signed-off-by: Jan Beulich 
---
Note that just like patch 4 of the series this also isn't directly
related to the SMEP/SMAP issue, but is again just a result of things
realized while doing that work, and again depends on the earlier
patches to apply cleanly.

--- a/xen/arch/x86/hvm/svm/entry.S
+++ b/xen/arch/x86/hvm/svm/entry.S
@@ -31,7 +31,7 @@
 #define CLGI   .byte 0x0F,0x01,0xDD
 
 ENTRY(svm_asm_do_resume)
-GET_CURRENT(%rbx)
+GET_CURRENT(bx)
 .Lsvm_do_resume:
 call svm_intr_assist
 mov  %rsp,%rdi
@@ -97,7 +97,7 @@ UNLIKELY_END(svm_trace)
 
 VMRUN
 
-GET_CURRENT(%rax)
+GET_CURRENT(ax)
 push %rdi
 push %rsi
 push %rdx
--- a/xen/arch/x86/hvm/vmx/entry.S
+++ b/xen/arch/x86/hvm/vmx/entry.S
@@ -40,7 +40,7 @@ ENTRY(vmx_asm_vmexit_handler)
 push %r10
 push %r11
 push %rbx
-GET_CURRENT(%rbx)
+GET_CURRENT(bx)
 push %rbp
 push %r12
 push %r13
@@ -113,7 +113,7 @@ UNLIKELY_END(realmode)
 BUG  /* vmx_vmentry_failure() shouldn't return. */
 
 ENTRY(vmx_asm_do_vmentry)
-GET_CURRENT(%rbx)
+GET_CURRENT(bx)
 jmp  .Lvmx_do_vmentry
 
 .Lvmx_goto_emulator:
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -26,7 +26,7 @@ UNLIKELY_START(ne, msi_check)
 UNLIKELY_END(msi_check)
 
 movl  UREGS_rax(%rsp),%eax
-GET_CURRENT(%rbx)
+GET_CURRENT(bx)
 
 cmpl  $NR_hypercalls,%eax
 jae   compat_bad_hypercall
@@ -202,7 +202,7 @@ ENTRY(compat_restore_all_guest)
 /* This mustn't modify registers other than %rax. */
 ENTRY(cr4_pv32_restore)
 push  %rdx
-GET_CPUINFO_FIELD(cr4, %rdx)
+GET_CPUINFO_FIELD(cr4, dx)
 mov   (%rdx), %rax
 test  $X86_CR4_SMEP|X86_CR4_SMAP,%eax
 jnz   0f
@@ -245,7 +245,7 @@ ENTRY(cstar_enter)
 pushq %rcx
 pushq $0
 SAVE_VOLATILE TRAP_syscall
-GET_CURRENT(%rbx)
+GET_CURRENT(bx)
 movq  VCPU_domain(%rbx),%rcx
 cmpb  $0,DOMAIN_is_32bit_pv(%rcx)
 jeswitch_to_kernel
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -97,7 +97,7 @@ ENTRY(lstar_enter)
 pushq %rcx
 pushq $0
 SAVE_VOLATILE TRAP_syscall
-GET_CURRENT(%rbx)
+GET_CURRENT(bx)
 testb $TF_kernel_mode,VCPU_thread_flags(%rbx)
 jzswitch_to_kernel
 
@@ -246,7 +246,7 @@ GLOBAL(sysenter_eflags_saved)
 pushq $0 /* null rip */
 pushq $0
 SAVE_VOLATILE TRAP_syscall
-GET_CURRENT(%rbx)
+GET_CURRENT(bx)
 cmpb  $0,VCPU_sysenter_disables_events(%rbx)
 movq  VCPU_sysenter_addr(%rbx),%rax
 setne %cl
@@ -288,7 +288,7 @@ UNLIKELY_START(ne, msi_check)
 call  check_for_unexpected_msi
 UNLIKELY_END(msi_check)
 
-GET_CURRENT(%rbx)
+GET_CURRENT(bx)
 
 /* Check that the callback is non-null. */
 leaq  VCPU_int80_bounce(%rbx),%rdx
@@ -420,10 +420,10 @@ domain_crash_page_fault:
 call  show_page_walk
 ENTRY(dom_crash_sync_extable)
 # Get out of the guest-save area of the stack.
-GET_STACK_BASE(%rax)
+GET_STACK_END(ax)
 leaq  STACK_CPUINFO_FIELD(guest_cpu_user_regs)(%rax),%rsp
 # create_bounce_frame() temporarily clobbers CS.RPL. Fix up.
-__GET_CURRENT(%rax)
+__GET_CURRENT(ax)
 movq  VCPU_domain(%rax),%rax
 testb $1,DOMAIN_is_32bit_pv(%rax)
 setz  %al
@@ -441,7 +441,7 @@ ENTRY(common_interrupt)
 
 /* No special register assumptions. */
 ENTRY(ret_from_intr)
-GET_CURRENT(%rbx)
+GET_CURRENT(bx)
 testb $3,UREGS_cs(%rsp)
 jzrestore_all_xen
 movq  VCPU_domain(%rbx),%rax
@@ -455,7 +455,7 @@ ENTRY(page_fault)
 GLOBAL(handle_exception)
 SAVE_ALL CLAC
 handle_exception_saved:
-GET_CURRENT(%rbx)
+GET_CURRENT(bx)
 testb $X86_EFLAGS_IF>>8,UREGS_eflags+1(%rsp)
 jzexception_with_ints_disabled
 
@@ -649,7 +649,7 @@ handle_ist_exception:
 testb $3,UREGS_cs(%rsp)
 jz1f
 /* Interrupted guest context. Copy the context to stack bottom. */
-GET_CPUINFO_FIELD(guest_cpu_user_regs,%rdi)
+GET_CPUINFO_FIELD(guest_cpu_user_regs,di)
 movq  %rsp,%rsi
 movl  $UREGS_kernel_sizeof/8,%ecx
 movq  %rdi,%rsp
@@ -664,7 +664,7 @@ handle_ist_exception:
 /* We want to get straight to the IRET on the NMI exit path. */
 testb $3,UREGS_cs(%rsp)
 jzrestore_all_xen
-GET_CURRENT(%rbx)
+GET_CURRENT(bx)
 

[Xen-devel] [PATCH v3 2/2] x86/hvm/viridian: Enable APIC assist enlightenment

[Paul Durrant]

This patch adds code to enable the APIC assist enlightenment which,
under certain conditions, means that the guest can avoid an EOI of
the local APIC and thereby avoid a VMEXIT.

Use of the enlightenment by the hypervisor is under control of the
toolstack, and is added to the default set.

Signed-off-by: Paul Durrant 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Wei Liu 
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---

v3:
 - Re-instated read-modify-write for forwards compatibility
 - Fix a coding style issue

v2:
 - Removed some code duplication and unnecessary read-modify-write
   operations on the APIC assist word.
 - Stated in the xl.cfg text that the enlightenment has no effect if
   posted interrupts are in use.
 - Added the enlightenment to the default set.
---
 docs/man/xl.cfg.pod.5  | 13 -
 tools/libxl/libxl_dom.c|  4 +++
 tools/libxl/libxl_types.idl|  1 +
 xen/arch/x86/hvm/viridian.c| 59 ++
 xen/arch/x86/hvm/vlapic.c  | 58 +
 xen/include/asm-x86/hvm/viridian.h |  5 
 xen/include/public/hvm/params.h|  7 -
 7 files changed, 134 insertions(+), 13 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 56b1117..1ba026b 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -1484,10 +1484,21 @@ This set incorporates use of hypercalls for remote TLB 
flushing.
 This enlightenment may improve performance of Windows guests running
 on hosts with higher levels of (physical) CPU contention.
 
+=item B
+
+This set incorporates use of the APIC assist page to avoid EOI of
+the local APIC.
+This enlightenment may improve performance of Windows guests,
+particularly those running PV drivers that make use of per-vcpu
+event channel upcall vectors.
+Note that this enlightenment will have no effect if the guest is
+using APICv posted interrupts.
+
 =item B
 
 This is a special value that enables the default set of groups, which
-is currently the B, B and B groups.
+is currently the B, B, B and B
+groups.
 
 =item B
 
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index b825b98..09d3bca 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -211,6 +211,7 @@ static int hvm_set_viridian_features(libxl__gc *gc, 
uint32_t domid,
 libxl_bitmap_set(, LIBXL_VIRIDIAN_ENLIGHTENMENT_BASE);
 libxl_bitmap_set(, LIBXL_VIRIDIAN_ENLIGHTENMENT_FREQ);
 libxl_bitmap_set(, 
LIBXL_VIRIDIAN_ENLIGHTENMENT_TIME_REF_COUNT);
+libxl_bitmap_set(, 
LIBXL_VIRIDIAN_ENLIGHTENMENT_APIC_ASSIST);
 }
 
 libxl_for_each_set_bit(v, info->u.hvm.viridian_enable) {
@@ -253,6 +254,9 @@ static int hvm_set_viridian_features(libxl__gc *gc, 
uint32_t domid,
 if (libxl_bitmap_test(, 
LIBXL_VIRIDIAN_ENLIGHTENMENT_HCALL_REMOTE_TLB_FLUSH))
 mask |= HVMPV_hcall_remote_tlb_flush;
 
+if (libxl_bitmap_test(, 
LIBXL_VIRIDIAN_ENLIGHTENMENT_APIC_ASSIST))
+mask |= HVMPV_apic_assist;
+
 if (mask != 0 &&
 xc_hvm_param_set(CTX->xch,
  domid,
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 632c009..e3be957 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -221,6 +221,7 @@ libxl_viridian_enlightenment = 
Enumeration("viridian_enlightenment", [
 (2, "time_ref_count"),
 (3, "reference_tsc"),
 (4, "hcall_remote_tlb_flush"),
+(5, "apic_assist"),
 ])
 
 libxl_hdtype = Enumeration("hdtype", [
diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
index e990163..664f233 100644
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -227,11 +227,6 @@ static void initialize_apic_assist(struct vcpu *v)
 void *va;
 
 /*
- * We don't yet make use of the APIC assist page but by setting
- * the CPUID3A_MSR_APIC_ACCESS bit in CPUID leaf 4003 we are duty
- * bound to support the MSR. We therefore do just enough to keep windows
- * happy.
- *
  * See section 13.3.4.1 of the specification for details of this
  * enlightenment.
  */
@@ -256,6 +251,7 @@ static void initialize_apic_assist(struct vcpu *v)
 
 v->arch.hvm_vcpu.viridian.apic_assist.page = page;
 v->arch.hvm_vcpu.viridian.apic_assist.va = va;
+v->arch.hvm_vcpu.viridian.apic_assist.vector = -1;
 return;
 
  fail:
@@ -263,6 +259,59 @@ static void initialize_apic_assist(struct vcpu *v)
  page ? page_to_mfn(page) : INVALID_MFN);
 }
 
+static uint32_t *get_apic_assist_word(struct vcpu *v)
+{
+if ( !(viridian_feature_mask(v->domain) & HVMPV_apic_assist) )
+return NULL;
+
+return v->arch.hvm_vcpu.viridian.apic_assist.va;
+}
+
+void viridian_start_apic_assist(struct vcpu *v, int 

Re: [Xen-devel] [PATCH v6] x86/hvm/viridian: Enable APIC assist enlightenment

[Jan Beulich]

>>> On 18.03.16 at 11:32,  wrote:
> This patch adds code to enable the APIC assist enlightenment which,
> under certain conditions, means that the guest can avoid an EOI of
> the local APIC and thereby avoid a VMEXIT.
> 
> Use of the enlightenment by the hypervisor is under control of the
> toolstack, and is added to the default set.
> 
> Signed-off-by: Paul Durrant 

Acked-by: Jan Beulich 


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

[Xen-devel] [PATCH 01/16] xen: sched: fix locking when allocating an RTDS pCPU

[Dario Faggioli]

as doing that include changing the scheduler lock
mapping for the pCPU itself, and the correct way
of doing that is:
 - take the lock that the pCPU is using right now
   (which may be the lock of another scheduler);
 - change the mapping of the lock to the RTDS one;
 - release the lock (the one that has actually been
   taken!)

Signed-off-by: Dario Faggioli 
---
Cc: Meng Xu 
Cc: George Dunlap 
Cc: Tianyang Chen 
---
 xen/common/sched_rt.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index c896a6f..d98bfb6 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -653,11 +653,16 @@ static void *
 rt_alloc_pdata(const struct scheduler *ops, int cpu)
 {
 struct rt_private *prv = rt_priv(ops);
+spinlock_t *old_lock;
 unsigned long flags;
 
-spin_lock_irqsave(>lock, flags);
+/* Move the scheduler lock to our global runqueue lock.  */
+old_lock = pcpu_schedule_lock_irqsave(cpu, );
+
 per_cpu(schedule_data, cpu).schedule_lock = >lock;
-spin_unlock_irqrestore(>lock, flags);
+
+/* _Not_ pcpu_schedule_unlock(): per_cpu().schedule_lock changed! */
+spin_unlock_irqrestore(old_lock, flags);
 
 if ( !alloc_cpumask_var(&_cpumask_scratch[cpu]) )
 return NULL;


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

Re: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node

[Ian Jackson]

David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document 
scsi/0x12/0x83 node"):
> On 16/03/16 13:59, Bob Liu wrote:
> > But we'd like to get the VPD information(of underlying storage device) also 
> > in Linux blkfront, even blkfront is not a SCSI device.
> 
> Why does blkback/blkfront need to involved here?  This is just some
> xenstore keys that can be written by the toolstack and directly read by
> the relevant application in the guest.

I'm getting rather a different picture here than at first.  Previously
I thought you had some 3rd-party application, not under your control,
which expected to see this VPD data.

But now I think that you're saying the application is under your own
control.  I don't understand why synthetic VPD data is the best way to
give your application the information it needs.

What is the application doing with this VPD data ?  I mean,
which specific application functions, and how do they depend on the
VPD data ?

Ian.

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

Re: [Xen-devel] [PATCH v5 16/17] FDT: Add a helper to get the subnode by given name

[Rob Herring]

On Fri, Mar 4, 2016 at 12:37 AM, Shannon Zhao  wrote:
> From: Shannon Zhao 
>
> Sometimes it needs to check if there is a subnode of given node in FDT
> by given name. Introduce this helper to get the subnode if it exists.
>
> CC: Rob Herring 
> Signed-off-by: Shannon Zhao 

Acked-by: Rob Herring 

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

[Xen-devel] [xen-unstable test] 86491: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail   like 86376
 build-i386-rumpuserxen6 xen-buildfail   like 86376
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 86376
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 86376
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 86376
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 86376
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 86376

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

version targeted for testing:
 xen  a6f2cdb633bf519244a16674031b8034b581ba7f
baseline version:
 xen  efc904263f483026672a5cdf3ccf9be8c4fdaa31

Last test of basis86376  2016-03-16 07:21:55 Z2 days
Failing since 86434  2016-03-16 22:43:52 Z1 days2 attempts
Testing same since86491  2016-03-17 15:24:59 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Doug Goldstein 
  Jan Beulich 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Paul Durrant 
  Razvan Cojocaru 
  Shanker Donthineni 
  Wei Liu 

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

[Xen-devel] [PATCH 4/7] oxenstored: keep track of each transaction's operations

[Jonathan Davies]

A list of (request, response) pairs from the operations performed within the
transaction will be useful to support transaction replay.

Since this consumes memory, the number of requests per transaction must not be
left unbounded. Hence a new quota for this is introduced. This quota, configured
via the configuration key 'quota-maxrequests', limits the size of transactions
initiated by domUs.

After the maximum number of requests has been exhausted, any further requests
will result in EQUOTA errors. The client may then choose to end the transaction;
a successful commit will result in the retention of only the prior requests.

Signed-off-by: Jonathan Davies 
Reviewed-by: Andrew Cooper 
Reviewed-by: Jon Ludlam 
Reviewed-by: Euan Harris 
---
 tools/ocaml/xenstored/define.ml   |1 +
 tools/ocaml/xenstored/oxenstored.conf |1 +
 tools/ocaml/xenstored/process.ml  |   13 +++--
 tools/ocaml/xenstored/transaction.ml  |   21 +++--
 tools/ocaml/xenstored/xenstored.ml|1 +
 5 files changed, 29 insertions(+), 8 deletions(-)

diff --git a/tools/ocaml/xenstored/define.ml b/tools/ocaml/xenstored/define.ml
index 89a6aac..d60861c 100644
--- a/tools/ocaml/xenstored/define.ml
+++ b/tools/ocaml/xenstored/define.ml
@@ -27,6 +27,7 @@ let default_config_dir = "/etc/xen"
 
 let maxwatch = ref (50)
 let maxtransaction = ref (20)
+let maxrequests = ref (-1)   (* maximum requests per transaction *)
 
 let domid_self = 0x7FF0
 
diff --git a/tools/ocaml/xenstored/oxenstored.conf 
b/tools/ocaml/xenstored/oxenstored.conf
index dd20eda..ac60f49 100644
--- a/tools/ocaml/xenstored/oxenstored.conf
+++ b/tools/ocaml/xenstored/oxenstored.conf
@@ -18,6 +18,7 @@ quota-maxentity = 1000
 quota-maxsize = 2048
 quota-maxwatch = 100
 quota-transaction = 10
+quota-maxrequests = 1024
 
 # Activate filed base backend
 persistent = false
diff --git a/tools/ocaml/xenstored/process.ml b/tools/ocaml/xenstored/process.ml
index c92bec7..758ade1 100644
--- a/tools/ocaml/xenstored/process.ml
+++ b/tools/ocaml/xenstored/process.ml
@@ -155,7 +155,7 @@ let do_transaction_end con t domains cons data =
if not success then
raise Transaction_again;
if commit then
-   process_watch (List.rev (Transaction.get_ops t)) cons
+   process_watch (List.rev (Transaction.get_paths t)) cons
 
 let do_introduce con t domains cons data =
if not (Connection.is_dom0 con)
@@ -303,7 +303,7 @@ let reply_ack fct con t doms cons data =
fct con t doms cons data;
Packet.Ack (fun () ->
if Transaction.get_id t = Transaction.none then
-   process_watch (Transaction.get_ops t) cons
+   process_watch (Transaction.get_paths t) cons
)
 
 let reply_data fct con t doms cons data =
@@ -384,6 +384,15 @@ let process_packet ~store ~cons ~doms ~con ~req =
in
let response = input_handle_error ~cons ~doms ~fct ~con ~t ~req 
in
 
+   let response = try
+   if tid <> Transaction.none then
+   (* Remember the request and response for this 
operation in case we need to replay the transaction *)
+   Transaction.add_operation 
~perm:(Connection.get_perm con) t req response;
+   response
+   with Quota.Limit_reached ->
+   Packet.Error "EQUOTA"
+   in
+
(* Put the response on the wire *)
send_response ty con t rid response
with exn ->
diff --git a/tools/ocaml/xenstored/transaction.ml 
b/tools/ocaml/xenstored/transaction.ml
index 77de4e8..6b37fc2 100644
--- a/tools/ocaml/xenstored/transaction.ml
+++ b/tools/ocaml/xenstored/transaction.ml
@@ -75,7 +75,8 @@ type t = {
ty: ty;
store: Store.t;
quota: Quota.t;
-   mutable ops: (Xenbus.Xb.Op.operation * Store.Path.t) list;
+   mutable paths: (Xenbus.Xb.Op.operation * Store.Path.t) list;
+   mutable operations: (Packet.request * Packet.response) list;
mutable read_lowpath: Store.Path.t option;
mutable write_lowpath: Store.Path.t option;
 }
@@ -86,16 +87,24 @@ let make id store =
ty = ty;
store = if id = none then store else Store.copy store;
quota = Quota.copy store.Store.quota;
-   ops = [];
+   paths = [];
+   operations = [];
read_lowpath = None;
write_lowpath = None;
}
 
 let get_id t = match t.ty with No -> none | Full (id, _, _) -> id
 let get_store t = t.store
-let get_ops t = t.ops
-
-let add_wop t ty path = t.ops <- (ty, path) :: t.ops
+let get_paths t = t.paths
+
+let add_wop t ty path = t.paths <- (ty, path) :: t.paths
+let add_operation ~perm t request response =
+ 

Re: [Xen-devel] [PATCH v3 06/28] xen/x86: Mask out unknown features from Xen's capabilities

[Konrad Rzeszutek Wilk]

On Tue, Mar 15, 2016 at 03:35:02PM +, Andrew Cooper wrote:
> If Xen doesn't know about a feature, it is unsafe for use and should be
> deliberately hidden from Xen's capabilities.
> 
> This doesn't make a practical difference yet, but will make a difference
> later when the guest featuresets are seeded from the host featureset.
> 
> Signed-off-by: Andrew Cooper 
> Acked-by: Jan Beulich 
> ---
> v2:
>  * Reduced substantially from v1, by using the autogenerated information.
> ---
>  xen/arch/x86/Makefile|  1 +
>  xen/arch/x86/cpu/common.c|  3 +++
>  xen/arch/x86/cpuid.c | 20 
>  xen/include/asm-x86/cpufeature.h |  4 +---
>  xen/include/asm-x86/cpuid.h  | 25 +
>  xen/tools/gen-cpuid.py   | 24 
>  6 files changed, 74 insertions(+), 3 deletions(-)
>  create mode 100644 xen/arch/x86/cpuid.c
>  create mode 100644 xen/include/asm-x86/cpuid.h
> 
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index 1bcb08b..729065b 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -12,6 +12,7 @@ obj-y += bitops.o
>  obj-bin-y += bzimage.init.o
>  obj-bin-y += clear_page.o
>  obj-bin-y += copy_page.o
> +obj-y += cpuid.o
>  obj-y += compat.o x86_64/compat.o
>  obj-$(CONFIG_KEXEC) += crash.o
>  obj-y += debug.o
> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
> index 1a278b1..cd168c8 100644
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -341,6 +341,9 @@ void identify_cpu(struct cpuinfo_x86 *c)
>* The vendor-specific functions might have changed features.  Now
>* we do "generic changes."
>*/
> + for (i = 0; i < FSCAPINTS; ++i) {
> + c->x86_capability[i] &= known_features[i];
> + }

You probably don't need those { }

>  
>   for (i = 0 ; i < NCAPINTS ; ++i)
>   c->x86_capability[i] &= ~cleared_caps[i];

Otherwise Reviewed-by: Konrad Rzeszutek Wilk 

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

Re: [Xen-devel] [PATCH v7 for Xen 4.7 3/4] libxl: enable per-VCPU parameter settings for RTDS scheduler

[Dario Faggioli]

On Thu, 2016-03-17 at 14:50 -0500, Chong Li wrote:
> On Wed, Mar 16, 2016 at 11:05 PM, Dario Faggioli
>  wrote:
> > 
> > On Wed, 2016-03-16 at 11:47 -0500, Chong Li wrote:
> > > 
> > > +/* Set the RTDS scheduling parameters of all vcpus of a domain
> > > */
> > > +static int sched_rtds_vcpus_params_set_all(libxl__gc *gc,
> > > uint32_t
> > > domid,
> > > +   const libxl_vcpu_sched_params
> > > *scinfo)
> > > 
> > Indentation?
> If I follow the indentation rule, the second line would be longer
> than
> 80 characters.
> The function name is just too long.
> 
static
int sched_rtds_vcpus_params_set_all(libxl__gc *gc, uint32_t domid,
const libxl_vcpu_sched_params *scinfo)

or 

static int
sched_rtds_vcpus_params_set_all(libxl__gc *gc, uint32_t domid,
const libxl_vcpu_sched_params *scinfo)

or shorten the name.

From quickly looking at libxl, neither of the first two proposed
solutions seems to happen much, so I recommend shortening the name a
bit. It's an internal function, so we can do that pretty freely.

> > > LIBXL_DOMAIN_SCHED_PARAM_BUDGET_DEFAULT) {
> > > -if (scinfo->budget < 1) {
> > > -LOG(ERROR, "VCPU budget is not set or out of range,
> > > "
> > > -   "valid values are larger than 1");
> > > +if (scinfo->period !=
> > > LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT &&
> > > +scinfo->budget !=
> > > LIBXL_DOMAIN_SCHED_PARAM_BUDGET_DEFAULT)
> > > +if (sched_rtds_validate_params(gc, scinfo->period,
> > > scinfo-
> > > > 
> > > > budget))
> > >  return ERROR_INVAL;
> > > 
> > I'm not sure I understand. What's happening in this function?
> > 
> > As it stands after this patch, it looks to me that:
> >  - we read the default scheduling parameter from Xen,
> >    via xc_sched_rtds_domain_get()
> >  - we (possibly, if both are non-default) validate a new period and
> >    budget couple of values
> >  - we don't use such values for anything, and set back what we got
> >    from Xen, via xc_sched_rtds_domain_set()
> > 
> > Either I'm missing something very basic, or this is not what Wei
> > said
> > when reviewing v6:
> > 
> > "Then at callsites you set those values with two direct assignment:
> > 
> >    if (validate(period_value, budget_value) != 0) {
> >    error;
> >    }
> >    period = period_value;
> >    budget = budget_value;"
> > 
> > Is it?
> The current RTDS (xen 4.6) is:
> 
> 1) Read the (per-domain) scheduling params from Xen, and store them
> to sdom
> 2) If period equals LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT (which is
> -1), use sdom.period;
> else sdom.period = new period (if new period is valid);
> If budget equals LIBXL_DOMAIN_SCHED_PARAM_BUDGET_DEFAULT (which
> is
> -1), use sdom.budget;
> else sdom.budget = new budget;
> 3) xc_sched_rtds_domain_set (sdom);
> 
Sort of, let me restate it more generally:

 1) get currently set period and budget;
 2) if scinfo->period is not PERIOD_DEFAULT and is valid, update
    the period;
 3) if scinfo->budget is not BUDGET_DEFAULT and is valid, update
    the budget

However that happens in terms of where the values of budget and period
are stashed, what call to xc_sched_rtds_domain_{get,set}() are made,
etc.

So, basically, when you say "if period equals PERIOD_DEFAULT", you mean
scinfo->period, i.e., the period being set is just the default libxl
value for it, which in turns means (most likely) one want to only alter
the budget.

> In our patch, my plan is:
> 1) Read the default params from Xen, and store them to sdom
> 2) If period equals LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT (which is
> -1), use sdom.period;
> else sdom.period = new period (if new period is valid);
> If budget equals LIBXL_DOMAIN_SCHED_PARAM_BUDGET_DEFAULT (which
> is
> -1), use sdom.budget;
> else sdom.budget = new budget;
> 3) xc_sched_rtds_domain_set (sdom);
> 
> Even though I made some mistakes in this post (forgot the two "else"s
> in my plan), is this plan ok?
> 
Your plan should be to leve things exactly as they are, from a
functional/logical perspective.

The difference between "(per-domain) scheduling params from Xen" of
right now, and "the default params from Xen" of after the patch, is of
no concern here, as it's all done by Xen.

So, really, this should be _all_ about taking the chance of refactoring
the code such as the validating function does not have weird side
effects, not about changing the logic, which looks fine to me.

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



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

Re: [Xen-devel] [PATCH v7 for Xen 4.7 1/4] xen: enable per-VCPU parameter settings for RTDS scheduler

[Dario Faggioli]

On Fri, 2016-03-18 at 01:39 -0600, Jan Beulich wrote:
> > 
> > > > On 17.03.16 at 21:42,  wrote:
> > On Thu, Mar 17, 2016 at 5:03 AM, Dario Faggioli
> >  wrote:
> > > 
> > > I'd say that, in this specific case, is not a big deal which one
> > > of the
> > > two approaches you take (mentioning or separate patch), but the
> > > having
> > > a separate one is indeed almost always preferable (e.g., the fix
> > > can be
> > > backported).
> > If I choose mentioning, do I move the comment to the changelog? Or
> > do I keep
> > it here and say it again in the changelog?
> Just consider what would happen if everyone mentioned in
> comments the bugs they fixed. I think the answer to you question
> is obvious then...
>
Exactly! :-)

And, please (Chong), let me restate this: "having a separate one is
indeed almost always preferable (e.g., the fix can be backported)"

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



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

[Xen-devel] [linux-mingo-tip-master test] 86447: regressions - FAIL

[osstest service owner]

flight 86447 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/86447/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 60684
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 60684
 test-amd64-amd64-libvirt 15 guest-saverestore.2   fail REGR. vs. 60684
 test-amd64-amd64-xl  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-xl-multivcpu 17 guest-localmigrate/x10   fail REGR. vs. 60684
 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2   fail REGR. vs. 60684
 test-amd64-amd64-xl-credit2  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-pair  22 guest-migrate/dst_host/src_host fail REGR. vs. 60684

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 60684
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-i386-xl-xsm   15 guest-localmigrate   fail blocked in 60684
 test-amd64-i386-xl   15 guest-localmigrate   fail blocked in 60684
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked 
in 60684
 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked 
in 60684
 test-amd64-i386-pair  22 guest-migrate/dst_host/src_host fail blocked in 60684
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 60684
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 60684
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 60684
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 60684

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 linuxe4cc2693368e9112d0e23b2c7596a3deddfd8c88
baseline version:
 linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0

Last test of basis60684  2015-08-13 04:21:46 Z  217 days
Failing since 60712  2015-08-15 18:33:48 Z  215 days  160 attempts
Testing same since86447  2016-03-17 04:26:18 Z0 days1 attempts

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
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  fail
 test-amd64-i386-xl   fail
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  

Re: [Xen-devel] [PATCH v9]xen: sched: convert RTDS from time to event driven model

[Dario Faggioli]

On Wed, 2016-03-16 at 11:43 -0400, Chen, Tianyang wrote:
> 
> On 03/16/2016 10:25 AM, Dario Faggioli wrote:
> > 
> > This is too detailed for a changelog. If you want this information
> > to
> > live somewhere (it already lives in the list archives, actually),
> > make
> > a cover letter (this is just one patch, so it's not required, but
> > nothing forbids that). Or put it in a wiki page. Or write a blog
> > post.
> > Or (which would be kind of nice) all of them! :-)
> > 
> I was thinking about this as well. The wiki will look a bit outdated
> for 
> RTDS if this patch goes through. Meng: Do you think we should put
> extra 
> information in the wiki? Someone's gotta update it sooner or later.
> 
No need to ask. More information / more updated information on the wiki
is just __always__ a good thing.

So, feel free to go ahead and make it so. If no one of you has write
access, there is a procedure in the wiki itself to request for that (or
just create an user and tell it to me, I think I should be able to
enable that for you).

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



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