[Xen-devel] [qemu-mainline baseline-only test] 38709: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

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. 38685

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

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-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 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
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  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-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail 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-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-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu39c36a0573d9307d68c0c3336b48e6351ffabc06
baseline version:
 qemuu1cf81ea2e2ecfd2ec046e2b409e75e87808ac4d0

Last test of basis38685  2016-01-22 14:52:19 Z5 days
Testing same since38709  2016-01-27 18:19:19 Z0 days1 attempts


People who touched revisions under test:
  Alistair Francis 
  Andrew Jones 
  Aurelien Jarno 
  Cao jin 
  Christian Borntraeger 
  Christoffer Dall 
  Cornelia Huck 
  Daniel P. Berrange 
  Denis V. Lunev 
  Dongxue Zhang 
  Dr. David Alan Gilbert 
  Edgar E. Iglesias 
  Eduardo Habkost 
  Eric Blake 
  Fam Zheng 
  Gerd Hoffmann 
  Greg Kurz 
  Haozhong Zhang 
  Huaitong Han 
  Ian Campbell 
  James Hogan 
  Janosch Frank 
  John Snow 
  Kevin Wolf 
  Laszlo Ersek 
  Leon Alrae 
  Luiz Capitulino 
  Markus Armbruster 
  Miodrag Dinic 
  Paolo Bonzini 
  Peter Crosthwaite 
  Peter Crosthwaite 
  Peter 

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

[Boris Ostrovsky]

On 01/27/2016 02:00 PM, Luis R. Rodriguez wrote:

On Wed, Jan 27, 2016 at 10:48 AM, Luis R. Rodriguez  wrote:

Worth mentioning here also is hpa's clarification on when subarch type
PC (0) should be used: [it should be used if the hardware is]
"enumerable using standard PC mechanisms (PCI, ACPI) and doesn't need
a special boot flow" -- does that fit HVMLite's description so far? If
so then The Xen subarch may need to be redefined as well to be clear
what it means. I don't think we need to be precise but at the very
least cover grounds to enable the definitions to meet its actual use
to not confuse users.

Another thing to consider for HVMlite is that if the 0 subarch (PC) is
used in light of my linker table work and x86's use of it with the
subarch and supported subarch bitmask, is that it would also mean
HVMLite would run all routines currently pegged as needing PC type
(the current KVM and bare metal path) and it would mean not running
anything only pegged with Xen subarch type (but note that today Xen
doesn't even set the subarch type). If there is nothing in common
between PV and HVMlite (no x86 init calls to share), and if HVMLite
*can* call *al* PC init calls, then by all means this is fine,


Yes, that's the idea. HVMlite jumps to startup_32|64 from the stub and 
runs from there with subarch 0.


-boris


and if we just need to distinguish stuff between PC types that's fine,
it may still be possible to further extend hypervisor_type to the x86
init calls I'm adding as another supported_hyper_types to ensure even
though a subarch is being used, that we also check the supported
hypervisor type as well.

  Luis



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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-credit2  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2   fail REGR. vs. 60684
 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate   fail REGR. vs. 60684
 test-amd64-amd64-xl  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 REGR. vs. 60684
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 60684
 test-amd64-i386-rumpuserxen-i386 10 guest-start   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-amd64-libvirt-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  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-i386-xl-xsm   15 guest-localmigrate   fail blocked in 60684
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-i386-xl   15 guest-localmigrate   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-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 60684
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 60684

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  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-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   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-qemuu-nested-intel 13 xen-boot/l1 fail never pass

version targeted for testing:
 linuxeec9b33534ab3ffd0b118a2b7988788ee58496e1
baseline version:
 linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0

Last test of basis60684  2015-08-13 04:21:46 Z  167 days
Failing since 60712  2015-08-15 18:33:48 Z  165 days  115 attempts
Testing same since79067  2016-01-26 04:28:34 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  pass
 build-i386-rumpuserxen   pass
 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 fail
 test-amd64-amd64-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  fail
 test-amd64-amd64-xl-xsm  fail
 test-amd64-i386-xl-xsm   

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

[Paul E. McKenney]

On Wed, Jan 27, 2016 at 10:25:46AM +, Will Deacon wrote:
> On Tue, Jan 26, 2016 at 11:58:20AM -0800, Paul E. McKenney wrote:
> > On Tue, Jan 26, 2016 at 12:16:09PM +, Will Deacon wrote:
> > > On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote:
> > > > On Mon, Jan 25, 2016 at 04:42:43PM +, Will Deacon wrote:
> > > > > On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote:
> > > > > > PPC Overlapping Group-B sets version 4
> > > > > > ""
> > > > > > (* When the Group-B sets from two different barriers involve 
> > > > > > instructions in
> > > > > >the same thread, within that thread one set must contain the 
> > > > > > other.
> > > > > > 
> > > > > > P0  P1  P2
> > > > > > Rx=1Wy=1Wz=2
> > > > > > dep.lwsync  lwsync
> > > > > > Ry=0Wz=1Wx=1
> > > > > > Rz=1
> > > > > > 
> > > > > > assert(!(z=2))
> > > > > > 
> > > > > >Forbidden by ppcmem, allowed by herd.
> > > > > > *)
> > > > > > {
> > > > > > 0:r1=x; 0:r2=y; 0:r3=z;
> > > > > > 1:r1=x; 1:r2=y; 1:r3=z; 1:r4=1;
> > > > > > 2:r1=x; 2:r2=y; 2:r3=z; 2:r4=1; 2:r5=2;
> > > > > > }
> > > > > >  P0 | P1| P2;
> > > > > >  lwz r6,0(r1)   | stw r4,0(r2)  | stw r5,0(r3)  ;
> > > > > >  xor r7,r6,r6   | lwsync| lwsync;
> > > > > >  lwzx r7,r7,r2  | stw r4,0(r3)  | stw r4,0(r1)  ;
> > > > > >  lwz r8,0(r3)   |   |   ;
> > > > > > 
> > > > > > exists
> > > > > > (z=2 /\ 0:r6=1 /\ 0:r7=0 /\ 0:r8=1)
> > > > > 
> > > > > That really hurts. Assuming that the "assert(!(z=2))" is actually 
> > > > > there
> > > > > to constrain the coherence order of z to be {0->1->2}, then I think 
> > > > > that
> > > > > this test is forbidden on arm using dmb instead of lwsync. That said, 
> > > > > I
> > > > > also don't think the Rz=1 in P0 changes anything.
> > > > 
> > > > What about the smp_wmb() variant of dmb that orders only stores?
> > > 
> > > Tricky, but I think it still works out if the coherence order of z is as
> > > I described above. The line of reasoning is weird though -- I ended up
> > > considering the two cases where P0 reads z before and after it reads x
> > > and what that means for the read of y.
> > 
> > By "works out" you mean that ARM prohibits the outcome?
> 
> Yes, that's my understanding.

Very good, we have agreement between the two architectures, then.  ;-)

Thanx, Paul


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

Re: [Xen-devel] [RFC] support more qdisk types

[Jim Fehlig]

On 01/27/2016 11:32 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 25, 2016 at 05:25:02PM -0700, Jim Fehlig wrote:
>> I would like to hear the community's opinion on supporting more qdisk types 
>> in
>> xl/libxl, e.g. nbd, rbd, iSCSI, etc. I prefer supporting additional qdisk 
>> types
>> in libxl over apps like xl or libvirt doing all the setup, producing a block
>> device, and then passing that to libxl. Each libxl app would have to
>> re-implement functionality already provided by qdisk. libxl already supports
>> IDE, AHCI, SCSI, and Xen PV qdisks. My suggestion is to extend that to 
>> initially
>> include nbd, rbd, and iSCSI. Sheepdog, ssh, etc. could be added in the 
>> future.
> ssh?

http://qemu.weilnetz.de/qemu-doc.html#disk_005fimages_005fssh

>> I considered several approaches to supporting additional qdisk types, based
>> primarily on changes to the disk cfg and interface. At one extreme is to 
>> change
>> nothing and use the existing 'target=' to encode all required config for the
>> additional qdisk types. libxl would need to be taught how to turn the blob 
>> into
>> an appropriate qdisk. At the other extreme is extending xl-disk-configuration
> Either way - new backends would require changes in both libxl and libvirt 
> right?

The backend is not new, it's qdisk. I'm suggesting to support more qdisk types.
But yes, it requires changes to libxl, xl, and libvirt.

> The libxl would need to understand the new 'target=' blob to parse it out?

Right, that's one approach. The config info is encoded in 'target=' in a
specified format, and libxl parses it out. Another approach is libxl provides
more settings for specifying these qdisk types.

Regards,
Jim


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck  6 xen-bootfail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 59254
 test-amd64-i386-xl   15 guest-localmigratefail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-i386-xl-xsm   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-i386-rumpuserxen-i386 10 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-credit2  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate   fail REGR. vs. 59254
 test-amd64-i386-pair   22 guest-migrate/dst_host/src_host fail REGR. vs. 59254
 test-amd64-amd64-pair  22 guest-migrate/dst_host/src_host fail REGR. vs. 59254

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt  9 debian-install fail in 79068 pass in 79155
 test-armhf-armhf-xl-rtds 11 guest-start fail pass in 79068

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 59254
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 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-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-libvirt-xsm 15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-libvirt 15 guest-saverestore.2  fail blocked in 59254
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 79068 like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 79068 never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 79068 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 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
 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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   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-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 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 12 migrate-support-checkfail   never pass

version targeted for testing:
 linux92e963f50fc74041b5e9e744c330dca48e04f08d
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  202 days
Failing since 59348  2015-07-10 04:24:05 Z  201 days  135 attempts
Testing same 

[Xen-devel] [PATCH v6 6/8] arm/gic-v3: Refactor gicv3_init into generic and dt specific parts

[Shannon Zhao]

From: Shannon Zhao 

Refactor gic-v3 related functions into dt and generic parts. This will be
helpful when adding acpi support for gic-v3.

Signed-off-by: Shannon Zhao 
---
v6: keep vsize check in gicv3_init_v2
---
 xen/arch/arm/gic-v3.c | 84 +++
 1 file changed, 45 insertions(+), 39 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index a245b56..fa61231 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1138,26 +1138,14 @@ static int __init cmp_rdist(const void *a, const void 
*b)
 return ( l->base < r->base) ? -1 : 0;
 }
 
+static paddr_t __initdata dbase = INVALID_PADDR;
+static paddr_t __initdata vbase = INVALID_PADDR, vsize = 0;
+static paddr_t __initdata cbase = INVALID_PADDR, csize = 0;
+
 /* If the GICv3 supports GICv2, initialize it */
-static void __init gicv3_init_v2(const struct dt_device_node *node,
- paddr_t dbase)
+static void __init gicv3_init_v2(void)
 {
-int res;
-paddr_t cbase, csize;
-paddr_t vbase, vsize;
-
-/*
- * For GICv3 supporting GICv2, GICC and GICV base address will be
- * provided.
- */
-res = dt_device_get_address(node, 1 + gicv3.rdist_count,
-, );
-if ( res )
-return;
-
-res = dt_device_get_address(node, 1 + gicv3.rdist_count + 2,
-, );
-if ( res )
+if ( cbase == INVALID_PADDR || vbase == INVALID_PADDR )
 return;
 
 /*
@@ -1180,20 +1168,11 @@ static void __init gicv3_init_v2(const struct 
dt_device_node *node,
 vgic_v2_setup_hw(dbase, cbase, csize, vbase, 0);
 }
 
-/* Set up the GIC */
-static int __init gicv3_init(void)
+static void __init gicv3_dt_init(void)
 {
 struct rdist_region *rdist_regs;
 int res, i;
-uint32_t reg;
 const struct dt_device_node *node = gicv3_info.node;
-paddr_t dbase;
-
-if ( !cpu_has_gicv3 )
-{
-dprintk(XENLOG_ERR, "GICv3: driver requires system register 
support\n");
-return -ENODEV;
-}
 
 res = dt_device_get_address(node, 0, , NULL);
 if ( res )
@@ -1203,14 +1182,6 @@ static int __init gicv3_init(void)
 panic("GICv3:  Found unaligned distributor address %"PRIpaddr"",
   dbase);
 
-gicv3.map_dbase = ioremap_nocache(dbase, SZ_64K);
-if ( !gicv3.map_dbase )
-panic("GICv3: Failed to ioremap for GIC distributor\n");
-
-reg = readl_relaxed(GICD + GICD_PIDR2) & GIC_PIDR2_ARCH_MASK;
-if ( reg != GIC_PIDR2_ARCH_GICv3 && reg != GIC_PIDR2_ARCH_GICv4 )
- panic("GICv3: no distributor detected\n");
-
 if ( !dt_property_read_u32(node, "#redistributor-regions",
 _count) )
 gicv3.rdist_count = 1;
@@ -1248,6 +1219,41 @@ static int __init gicv3_init(void)
 panic("GICv3: Cannot find the maintenance IRQ");
 gicv3_info.maintenance_irq = res;
 
+/*
+ * For GICv3 supporting GICv2, GICC and GICV base address will be
+ * provided.
+ */
+res = dt_device_get_address(node, 1 + gicv3.rdist_count,
+, );
+if ( res )
+return;
+
+dt_device_get_address(node, 1 + gicv3.rdist_count + 2,
+  , );
+}
+
+/* Set up the GIC */
+static int __init gicv3_init(void)
+{
+int res, i;
+uint32_t reg;
+
+if ( !cpu_has_gicv3 )
+{
+dprintk(XENLOG_ERR, "GICv3: driver requires system register 
support\n");
+return -ENODEV;
+}
+
+gicv3_dt_init();
+
+gicv3.map_dbase = ioremap_nocache(dbase, SZ_64K);
+if ( !gicv3.map_dbase )
+panic("GICv3: Failed to ioremap for GIC distributor\n");
+
+reg = readl_relaxed(GICD + GICD_PIDR2) & GIC_PIDR2_ARCH_MASK;
+if ( reg != GIC_PIDR2_ARCH_GICv3 && reg != GIC_PIDR2_ARCH_GICv4 )
+ panic("GICv3: no distributor detected\n");
+
 for ( i = 0; i < gicv3.rdist_count; i++ )
 {
 /* map dbase & rdist regions */
@@ -1277,7 +1283,7 @@ static int __init gicv3_init(void)
 
 vgic_v3_setup_hw(dbase, gicv3.rdist_count, gicv3.rdist_regions,
  gicv3.rdist_stride);
-gicv3_init_v2(node, dbase);
+gicv3_init_v2();
 
 spin_lock_init();
 
@@ -1317,7 +1323,7 @@ static const struct gic_hw_operations gicv3_ops = {
 .make_hwdom_dt_node  = gicv3_make_hwdom_dt_node,
 };
 
-static int __init gicv3_preinit(struct dt_device_node *node, const void *data)
+static int __init gicv3_dt_preinit(struct dt_device_node *node, const void 
*data)
 {
 gicv3_info.hw_version = GIC_V3;
 gicv3_info.node = node;
@@ -1335,7 +1341,7 @@ static const struct dt_device_match gicv3_dt_match[] 
__initconst =
 
 DT_DEVICE_START(gicv3, "GICv3", DEVICE_GIC)
 .dt_match = gicv3_dt_match,
-.init = gicv3_preinit,
+.init = gicv3_dt_preinit,
 DT_DEVICE_END
 
 /*
-- 
2.0.4



___
Xen-devel mailing 

[Xen-devel] build Xen tool fail

[Hao, Xudong]

Ian, 

A recent changes of tools evtchn cause a build failure with gcc 4.4.7, OS is 
RHEL6.5.

Bad commit:
commit b7f76a699dcfadc0a52ab45b33cc72dbf3a69e7b
Author: Ian Campbell <ian.campb...@citrix.com>
Date:   Mon Jun 1 16:20:09 2015 +0100

tools: Refactor /dev/xen/evtchn wrappers into libxenevtchn.

libxenevtchn will provide a stable API and ABI for accessing the
　evtchn device.


Partial error log:
...
gcc  -DPIC -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 
-Wall -Wstrict-prototypes -Wdeclaration-after-statement 
-Wno-unused-but-set-variable   -O0 -g3 -D__XEN_TOOLS__ -MMD -MF .linux.opic.d 
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls  -Werror 
-Wmissing-prototypes -I./include 
-I/home/www/builds_xen_unstable/xen-src-2e46e3f2-20160127/tools/libs/evtchn/../../../tools/include
 
-I/home/www/builds_xen_unstable/xen-src-2e46e3f2-20160127/tools/libs/evtchn/../../../tools/libs/toollog/include
 
-I/home/www/builds_xen_unstable/xen-src-2e46e3f2-20160127/tools/libs/evtchn/../../../tools/include
  -fPIC -c -o linux.opic linux.c 
mv headers.chk.new headers.chk
In file included from private.h:5,
 from core.c:19:
./include/xenevtchn.h:36: error: redefinition of typedef ‘xentoollog_logger’
/home/www/builds_xen_unstable/xen-src-2e46e3f2-20160127/tools/libs/evtchn/../../../tools/libs/toollog/include/xentoollog.h:44:
 note: previous declaration of ‘xentoollog_logger’ was here
In file included from private.h:5,
 from core.c:19:
./include/xenevtchn.h:36: error: redefinition of typedef ‘xentoollog_logger’
/home/www/builds_xen_unstable/xen-src-2e46e3f2-20160127/tools/libs/evtchn/../../../tools/libs/toollog/include/xentoollog.h:44:
 note: previous declaration of ‘xentoollog_logger’ was here
make[6]: *** [core.opic] Error 1
make[6]: *** Waiting for unfinished jobs
make[6]: *** [core.o] Error 1
In file included from private.h:5,
 from linux.c:29:
./include/xenevtchn.h:36: error: redefinition of typedef ‘xentoollog_logger’
/home/www/builds_xen_unstable/xen-src-2e46e3f2-20160127/tools/libs/evtchn/../../../tools/libs/toollog/include/xentoollog.h:44:
 note: previous declaration of ‘xentoollog_logger’ was here
In file included from private.h:5,
 from linux.c:29:
./include/xenevtchn.h:36: error: redefinition of typedef ‘xentoollog_logger’
/home/www/builds_xen_unstable/xen-src-2e46e3f2-20160127/tools/libs/evtchn/../../../tools/libs/toollog/include/xentoollog.h:44:
 note: previous declaration of ‘xentoollog_logger’ was here
make[6]: *** [linux.o] Error 1
make[6]: *** [linux.opic] Error 1
...

　
Best Regards,
Xudong



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

Re: [Xen-devel] [RFC] support more qdisk types

[Jim Fehlig]

On 01/27/2016 02:09 PM, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 27, 2016 at 02:25:51PM -0600, Doug Goldstein wrote:
>> On 1/27/16 12:32 PM, Konrad Rzeszutek Wilk wrote:
>>> On Mon, Jan 25, 2016 at 05:25:02PM -0700, Jim Fehlig wrote:
 I would like to hear the community's opinion on supporting more qdisk 
 types in
 xl/libxl, e.g. nbd, rbd, iSCSI, etc. I prefer supporting additional qdisk 
 types
 in libxl over apps like xl or libvirt doing all the setup, producing a 
 block
 device, and then passing that to libxl. Each libxl app would have to
 re-implement functionality already provided by qdisk. libxl already 
 supports
 IDE, AHCI, SCSI, and Xen PV qdisks. My suggestion is to extend that to 
 initially
 include nbd, rbd, and iSCSI. Sheepdog, ssh, etc. could be added in the 
 future.
>>> ssh?
 I considered several approaches to supporting additional qdisk types, based
 primarily on changes to the disk cfg and interface. At one extreme is to 
 change
 nothing and use the existing 'target=' to encode all required config for 
 the
 additional qdisk types. libxl would need to be taught how to turn the blob 
 into
 an appropriate qdisk. At the other extreme is extending 
 xl-disk-configuration
>>> Either way - new backends would require changes in both libxl and libvirt 
>>> right?
>>> The libxl would need to understand the new 'target=' blob to parse it out?
>>>
>> libvirt would probably just do what its doing now. Since it can setup
>> the connection and pass the file descriptor into libxl. Honestly I don't
>> see the advantage here because libvirt does a better job from a security
>> standpoint and unless the goal is to have everything and the kitchen
>> sink in libxl/xl. There's already a number of ways to skin the cat (xl,
>> libvirt, xapi, openstack), why another one?
> I believe what Jim is saying that there needs to be some parsing in libxl
> so that it can pass the right information to QEMU.

Correct. The info is also needed when libxl creates the device in xenstore.

Regards,
Jim


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

[Xen-devel] [PATCH v11 2/2] Add a command line parameter for VT-d posted-interrupts

[Feng Wu]

Enable VT-d Posted-Interrupts and add a command line
parameter for it.

CC: Jan Beulich 
Signed-off-by: Feng Wu 
Reviewed-by: Kevin Tian 
Acked-by: Jan Beulich 
---
 docs/misc/xen-command-line.markdown | 9 -
 xen/drivers/passthrough/iommu.c | 3 +++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 467dc8f..ea1d60d 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -868,7 +868,7 @@ debug hypervisor only).
 > Default: `new` unless directed-EOI is supported
 
 ### iommu
-> `= List of [  | force | required | intremap | qinval | snoop | 
sharept | dom0-passthrough | dom0-strict | amd-iommu-perdev-intremap | 
workaround_bios_bug | igfx | verbose | debug ]`
+> `= List of [  | force | required | intremap | intpost | qinval | 
snoop | sharept | dom0-passthrough | dom0-strict | amd-iommu-perdev-intremap | 
workaround_bios_bug | igfx | verbose | debug ]`
 
 > Sub-options:
 
@@ -895,6 +895,13 @@ debug hypervisor only).
 >> Control the use of interrupt remapping (DMA remapping will always be enabled
 >> if IOMMU functionality is enabled).
 
+> `intpost`
+
+> Default: `false`
+
+>> Control the use of interrupt posting, which depends on the availability of
+>> interrupt remapping.
+
 > `qinval` (VT-d)
 
 > Default: `true`
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 0b2abf4..50d74a5 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -32,6 +32,7 @@ static void iommu_dump_p2m_table(unsigned char key);
  *   off|no|false|disable   Disable IOMMU (default)
  *   force|required Don't boot unless IOMMU is enabled
  *   no-intremapDisable interrupt remapping
+ *   no-intpost Disable VT-d Interrupt posting
  *   verboseBe more verbose
  *   debug  Enable debugging messages and checks
  *   workaround_bios_bugWorkaround some bios issue to still enable
@@ -105,6 +106,8 @@ static void __init parse_iommu_param(char *s)
 iommu_qinval = val;
 else if ( !strcmp(s, "intremap") )
 iommu_intremap = val;
+else if ( !strcmp(s, "intpost") )
+iommu_intpost = val;
 else if ( !strcmp(s, "debug") )
 {
 iommu_debug = val;
-- 
2.1.0


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

[Xen-devel] [PATCH v11 0/2] Add VT-d Posted-Interrupts support

[Feng Wu]

VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.

You can find the VT-d Posted-Interrtups Spec. in the following URL:
http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/vt-directed-io-spec.html

Feng Wu (2):
  vmx: VT-d posted-interrupt core logic handling
  Add a command line parameter for VT-d posted-interrupts

 docs/misc/xen-command-line.markdown |   9 +-
 xen/arch/x86/hvm/vmx/vmcs.c |   2 +
 xen/arch/x86/hvm/vmx/vmx.c  | 179 
 xen/common/schedule.c   |   4 +
 xen/drivers/passthrough/iommu.c |   3 +
 xen/drivers/passthrough/vtd/iommu.c |   2 +
 xen/include/asm-arm/domain.h|   2 +
 xen/include/asm-x86/hvm/hvm.h   |   5 +
 xen/include/asm-x86/hvm/vmx/vmcs.h  |  14 +++
 xen/include/asm-x86/hvm/vmx/vmx.h   |   4 +
 10 files changed, 223 insertions(+), 1 deletion(-)

-- 
2.1.0


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

[Xen-devel] [PATCH v11 1/2] vmx: VT-d posted-interrupt core logic handling

[Feng Wu]

This is the core logic handling for VT-d posted-interrupts. Basically it
deals with how and when to update posted-interrupts during the following
scenarios:
- vCPU is preempted
- vCPU is slept
- vCPU is blocked

When vCPU is preempted/slept, we update the posted-interrupts during
scheduling by introducing two new architecutral scheduler hooks:
vmx_pi_switch_from() and vmx_pi_switch_to(). When vCPU is blocked, we
introduce a new architectural hook: arch_vcpu_block() to update
posted-interrupts descriptor.

Besides that, before VM-entry, we will make sure the 'NV' filed is set
to 'posted_intr_vector' and the vCPU is not in any blocking lists, which
is needed when vCPU is running in non-root mode. The reason we do this check
is because we change the posted-interrupts descriptor in vcpu_block(),
however, we don't change it back in vcpu_unblock() or when vcpu_block()
directly returns due to event delivery (in fact, we don't need to do it
in the two places, that is why we do it before VM-Entry).

When we handle the lazy context switch for the following two scenarios:
- Preempted by a tasklet, which uses in an idle context.
- the prev vcpu is in offline and no new available vcpus in run queue.
We don't change the 'SN' bit in posted-interrupt descriptor, this
may incur spurious PI notification events, but since PI notification
event is only sent when 'ON' is clear, and once the PI notificatoin
is sent, ON is set by hardware, hence no more notification events
before 'ON' is clear. Besides that, spurious PI notification events are
going to happen from time to time in Xen hypervisor, such as, when
guests trap to Xen and PI notification event happens, there is
nothing Xen actually needs to do about it, the interrupts will be
delivered to guest atht the next time we do a VMENTRY.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Kevin Tian 
CC: George Dunlap 
CC: Dario Faggioli 
Suggested-by: Yang Zhang 
Suggested-by: Dario Faggioli 
Suggested-by: George Dunlap 
Suggested-by: Jan Beulich 
Signed-off-by: Feng Wu 
---
v11:
- Add ASSERT() in vmx_vcpu_block()
- Add some comments in vmx_pi_switch_from()
- Remove some comments which should have been removed when the
  related code was removed during v9 -> v10
- Rename 'vmx_pi_state_to_normal' to 'vmx_pi_do_resume'
- Coding style
- Make arch_vcpu_block() a macro
- Make 'pi_wakeup_vector' static
- Move hook 'vcpu_block' to 'struct hvm_vcpu'
- Initial hook 'vcpu_block' when assigning the first pci device
  and zap it on removal of the last device
- Save pointer to the block list lock instead of the processor
  id in 'struct arch_vmx_struct'
- Implement the following functions as hooks, so we
  can elimilate lots of checkings and spinlocks in scheduling
  related code path, which is good for performance.
vmx_pi_switch_from
vmx_pi_switch_to
vmx_pi_do_resume

v10:
- Check iommu_intpost first
- Remove pointless checking of has_hvm_container_vcpu(v)
- Rename 'vmx_pi_state_change' to 'vmx_pi_state_to_normal'
- Since vcpu_unblock() doesn't acquire 'pi_blocked_vcpu_lock', we
  don't need use another list to save the vCPUs with 'ON' set, just
  directly call vcpu_unblock(v).

v9:
- Remove arch_vcpu_block_cancel() and arch_vcpu_wake_prepare()
- Add vmx_pi_state_change() and call it before VM Entry

v8:
- Remove the lazy context switch handling for PI state transition
- Change PI state in vcpu_block() and do_poll() when the vCPU
  is going to be blocked

v7:
- Merge [PATCH v6 16/18] vmx: Add some scheduler hooks for VT-d posted 
interrupts
  and "[PATCH v6 14/18] vmx: posted-interrupt handling when vCPU is blocked"
  into this patch, so it is self-contained and more convenient
  for code review.
- Make 'pi_blocked_vcpu' and 'pi_blocked_vcpu_lock' static
- Coding style
- Use per_cpu() instead of this_cpu() in pi_wakeup_interrupt()
- Move ack_APIC_irq() to the beginning of pi_wakeup_interrupt()
- Rename 'pi_ctxt_switch_from' to 'ctxt_switch_prepare'
- Rename 'pi_ctxt_switch_to' to 'ctxt_switch_cancel'
- Use 'has_hvm_container_vcpu' instead of 'is_hvm_vcpu'
- Use 'spin_lock' and 'spin_unlock' when the interrupt has been
  already disabled.
- Rename arch_vcpu_wake_prepare to vmx_vcpu_wake_prepare
- Define vmx_vcpu_wake_prepare in xen/arch/x86/hvm/hvm.c
- Call .pi_ctxt_switch_to() __context_switch() instead of directly
  calling vmx_post_ctx_switch_pi() in vmx_ctxt_switch_to()
- Make .pi_block_cpu unsigned int
- Use list_del() instead of list_del_init()
- Coding style

One remaining item in v7:
Jan has concern about calling vcpu_unblock() in vmx_pre_ctx_switch_pi(),
need Dario or George's input about this.

v6:
- Add two static inline functions for pi context switch
- Fix typos

v5:
- Rename arch_vcpu_wake to 

Re: [Xen-devel] [RFC] support more qdisk types

[Jim Fehlig]

On 01/27/2016 01:25 PM, Doug Goldstein wrote:
> On 1/27/16 12:32 PM, Konrad Rzeszutek Wilk wrote:
>> On Mon, Jan 25, 2016 at 05:25:02PM -0700, Jim Fehlig wrote:
>>> I would like to hear the community's opinion on supporting more qdisk types 
>>> in
>>> xl/libxl, e.g. nbd, rbd, iSCSI, etc. I prefer supporting additional qdisk 
>>> types
>>> in libxl over apps like xl or libvirt doing all the setup, producing a block
>>> device, and then passing that to libxl. Each libxl app would have to
>>> re-implement functionality already provided by qdisk. libxl already supports
>>> IDE, AHCI, SCSI, and Xen PV qdisks. My suggestion is to extend that to 
>>> initially
>>> include nbd, rbd, and iSCSI. Sheepdog, ssh, etc. could be added in the 
>>> future.
>> ssh?
>>> I considered several approaches to supporting additional qdisk types, based
>>> primarily on changes to the disk cfg and interface. At one extreme is to 
>>> change
>>> nothing and use the existing 'target=' to encode all required config for the
>>> additional qdisk types. libxl would need to be taught how to turn the blob 
>>> into
>>> an appropriate qdisk. At the other extreme is extending 
>>> xl-disk-configuration
>> Either way - new backends would require changes in both libxl and libvirt 
>> right?
>> The libxl would need to understand the new 'target=' blob to parse it out?
>>
> libvirt would probably just do what its doing now. Since it can setup
> the connection and pass the file descriptor into libxl.

Hmm, I'm not sure I understand. AFAIK, there is no way to pass libxl a file
descriptor opened from an image file or block device.

>  Honestly I don't
> see the advantage here because libvirt does a better job from a security
> standpoint and unless the goal is to have everything and the kitchen
> sink in libxl/xl. There's already a number of ways to skin the cat (xl,
> libvirt, xapi, openstack), why another one?

I'm simply proposing to extend the types of devices supported by and already
supported backend - qdisk. libxl configures qdisk based on the contents of the
libxl_device_disk struct. This proposal extends the struct with info necessary
to support the additional qdisk types.

Regards,
Jim


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

[Xen-devel] [linux-next test] 79158: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-vhd   9 debian-di-install fail REGR. vs. 78977
 test-armhf-armhf-libvirt  4 host-ping-check-nativefail REGR. vs. 79155
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-saverestore fail REGR. vs. 79155
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail 
REGR. vs. 79155
 test-armhf-armhf-libvirt-raw  9 debian-di-install fail REGR. vs. 79155

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 79155
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 79155
 test-armhf-armhf-xl   8 leak-check/basis(8)  fail blocked in 79155
 test-armhf-armhf-xl-cubietruck 11 guest-startfail blocked in 79155
 test-armhf-armhf-xl-multivcpu  8 leak-check/basis(8) fail blocked in 79155
 test-armhf-armhf-xl-credit2   8 leak-check/basis(8)  fail blocked in 79155
 test-amd64-i386-rumpuserxen-i386 10 guest-startfail like 79155
 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate   fail  like 79155
 test-amd64-amd64-xl  15 guest-localmigrate   fail   like 79155
 test-amd64-amd64-libvirt 15 guest-saverestore.2  fail   like 79155
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail   like 79155
 test-amd64-amd64-xl-xsm  15 guest-localmigrate   fail   like 79155
 test-amd64-amd64-xl-credit2  15 guest-localmigrate   fail   like 79155
 test-amd64-i386-xl   15 guest-localmigrate   fail   like 79155
 test-amd64-amd64-xl-rtds 15 guest-localmigrate   fail   like 79155
 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2  fail   like 79155
 test-amd64-i386-xl-xsm   15 guest-localmigrate   fail   like 79155
 test-amd64-amd64-pair   22 guest-migrate/dst_host/src_host fail like 79155
 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail like 
79155
 test-amd64-i386-pair22 guest-migrate/dst_host/src_host fail like 79155
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 79155
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 79155
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail   like 79155
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 79155
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail like 79155

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  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-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail 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-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   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:
 linux725e269ca7edf4c624732e91e2c1418dd7f7
baseline version:
 linux92e963f50fc74041b5e9e744c330dca48e04f08d

Last test of basis  (not found) 
Failing since 0  1970-01-01 00:00:00 Z 16828 days
Testing same since79158  2016-01-27 09:21:28 Z0 days1 attempts

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

Re: [Xen-devel] Status of "dma, x86, xen: reduce SWIOTLB usage in Xen guests" series

[Sarah Newman]

On 01/25/2016 02:47 AM, David Vrabel wrote:
> On 23/01/16 22:12, Sarah Newman wrote:
>> Greetings,
>>
>> We are having problems related to mptsas and "swiotlb buffer is full" with 
>> the Xen4CentOS kernel (3.18). It looks like the last related work was
>> the series 
>> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00770.html 
>> back at the end of 2014 and I'm wondering if there are any plans
>> to revive the series.

> As a workaround, you can give dom0 more than 4 GiB and then the driver
> will set a 64-bit DMA mask.  I don't think the memory needs to populated
> so something like dom0_mem=2GiB,max:4GiB might work.

4GiB RAM worked, though we may need to shuffle things around to put this into 
effect everywhere. Thanks.


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

[Xen-devel] [PATCH v2] build: specify minimum versions of make and binutils

[Doug Goldstein]

To help people avoid having to figure out what versions of make and
binutils need to be supported document them explicitly. The version of
binutils that had to be supported was mentioned in
http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg00609.html
as 2.17 recently. It was decided that the versions should instead be
GNU binutils 2.16.1 and GNU Make 3.80 in
http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg02134.html

Signed-off-by: Doug Goldstein 
---
 README | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/README b/README
index 1324c7c..f5bd429 100644
--- a/README
+++ b/README
@@ -36,8 +36,8 @@ release. Make sure you have all the following installed, 
either by
 visiting the project webpage or installing a pre-built package
 provided by your OS distributor:
 * GCC v4.1 or later
-* GNU Make
-* GNU Binutils
+* GNU Make v3.80 or later
+* GNU Binutils v2.16.1 or later
 * Development install of zlib (e.g., zlib-dev)
 * Development install of Python v2.3 or later (e.g., python-dev)
 * Development install of curses (e.g., libncurses-dev)
-- 
2.4.10


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

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

[Leonid Yegoshin]

On 01/27/2016 03:26 AM, Maciej W. Rozycki wrote:

On Fri, 15 Jan 2016, Leonid Yegoshin wrote:


So you need to build a different kernel for some types of MIPS systems?
Or do you do boot-time rewriting, like a number of other arches do?

I don't know. I would like to have responses. Ralf asked Maciej about old
systems and that came nowhere. Even rewrite - don't know what to do with that:
no lightweight SYNC or no SYNC at all - yes, it is still possible that SYNC on
some systems can be too heavy or even harmful, nobody tested that.

  I don't recall being asked; mind that I might not get to messages I have
not been cc-ed in a timely manner and I may miss some altogether.  With
the amount of mailing list traffic that passes by me my scanner may fail
to trigger.  Sorry if this causes anybody trouble, but such is life.

  Coincidentally, I have just posted some notes on SYNC in a different
thread, see .
There's a reference to an older message of mine there too.  I hope this
answers your questions.

   Maciej
In http://patchwork.linux-mips.org/patch/10505/the very last mesg 
exchange is:


Maciej,

do you have an R4000 / R4600 / R5000 / R7000 / SiByte system at hand to
test this?
...
  Ralf

Maciej W. Rozycki- June 5, 2015, 9:18 p.m.

On Fri, 5 Jun 2015, Ralf Baechle wrote:


do you have an R4000 / R4600 / R5000 / R7000 / SiByte system at hand to
test this?


 I should be able to check R4400 (that is virtually the same as R4000)
next week or so.  As to SiByte -- not before next month I'm afraid.  I
don't have access to any of the other processors you named.  You may
want to find a better person if you want to accept this change soon.

  Maciej

... and that stops forever...

- Leonid.

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

Re: [Xen-devel] [PATCH 0/3] x86: xsave{c,s} fixes and adjustments

[Jan Beulich]

>>> On 27.01.16 at 08:35,  wrote:
> 1: xstate: don't unintentionally clear compaction bit
> 2: adjust xsave structure attributes
> 3: xstate: fix fault behavior on XRSTORS
> 
> Signed-off-by: Jan Beulich 

Actually - no, let me see whether I can figure out the further
#GP that is apparently occurring despite these patches being
present (and having helped the original issue).

Jan


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

Re: [Xen-devel] Error booting Xen

[Jan Beulich]

>>> On 26.01.16 at 19:02,  wrote:
> Last time, I did absolutely nothing. System was idle
> and it crashed just after the login. Now, I booted the
> system again and this time, there is no reset. But,
> performance of the system is very slow. Browser
> (Mozilla Firefox) freezes a lot. Also, before applying
> patches, when I used to disabe xsave it resulted in
> same kind of performance issues. And the following
> is still present in the log.
> 
> (XEN) traps.c:3290: GPF (): 82d0801c1cea -> 82d080252e5c
> (XEN) d1v1 fault#1: mxcsr=1f80
> (XEN) d1v1 xs=0003 xc=8000
> (XEN) d1v1 r0= r1=
> (XEN) d1v1 r2= r3=
> (XEN) d1v1 r4= r5=
> (XEN) traps.c:3290: GPF (): 82d0801c1cea -> 82d080252e5c
> (XEN) d1v1 fault#2: mxcsr=1f80
> (XEN) d1v1 xs= xc=
> (XEN) d1v1 r0= r1=
> (XEN) d1v1 r2= r3=
> (XEN) d1v1 r4= r5=
> 
> Full log here: http://paste2.org/C8WpyKOg 

This is not _still_ present, but that's another, different instance,
now during guest creation. Please try to be precise in your
wording. Namely, in this case, you again fail to mention what
kind of guest you're now creating that causes this to re-appear.

Jan


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-cubietruck  6 xen-bootfail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 59254
 test-amd64-i386-xl   15 guest-localmigratefail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-i386-xl-xsm   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-i386-rumpuserxen-i386 10 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-credit2  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate   fail REGR. vs. 59254
 test-amd64-i386-pair   22 guest-migrate/dst_host/src_host fail REGR. vs. 59254
 test-amd64-amd64-pair  22 guest-migrate/dst_host/src_host fail REGR. vs. 59254

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale  11 guest-startfail in 78977 pass in 79068
 test-armhf-armhf-xl-rtds 11 guest-startfail in 78977 pass in 79068
 test-armhf-armhf-libvirt  9 debian-install  fail pass in 78977

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 59254
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 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-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-libvirt-xsm 15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-libvirt 15 guest-saverestore.2  fail blocked in 59254
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 guest-saverestore fail in 78977 never pass
 test-armhf-armhf-libvirt 12 migrate-support-check fail in 78977 never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-check fail in 78977 never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-check fail in 78977 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-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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-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-amd64-xl-pvh-amd  11 guest-start  fail   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-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 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 12 migrate-support-checkfail   never pass

version targeted for testing:
 linux

Re: [Xen-devel] [PATCH v3 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI

[Hanjun Guo]

Hi Shannon,

On 2016/1/23 11:19, Shannon Zhao wrote:

From: Shannon Zhao 

When it's a Xen domain0 booting with ACPI, it will supply a /chosen and
a /hypervisor node in DT. So check if it needs to enable ACPI.

Signed-off-by: Shannon Zhao 
---
CC: Hanjun Guo 
---
  arch/arm64/kernel/acpi.c | 12 
  1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index d1ce8e2..4e92be0 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -67,10 +67,13 @@ static int __init dt_scan_depth1_nodes(unsigned long node,
  {
/*
 * Return 1 as soon as we encounter a node at depth 1 that is
-* not the /chosen node.
+* not the /chosen node, or /hypervisor node when running on Xen.


The comment is bit misleading, we need to specify two mode, running on
Xen or not, if not on xen, then /chosen node is enough.


 */
-   if (depth == 1 && (strcmp(uname, "chosen") != 0))
-   return 1;
+   if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
+   if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
+   return 1;
+   }
+
return 0;
  }

@@ -184,7 +187,8 @@ void __init acpi_boot_table_init(void)
/*
 * Enable ACPI instead of device tree unless
 * - ACPI has been disabled explicitly (acpi=off), or
-* - the device tree is not empty (it has more than just a /chosen node)
+* - the device tree is not empty (it has more than just a /chosen node,
+*   and a /hypervisor node when running on Xen)


and here too.

if that is addressed,

Acked-by: Hanjun Guo 

Thanks
Hanjun

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

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

[Linus Torvalds]

On Jan 26, 2016 23:51, "Peter Zijlstra"  wrote:
>
> So for a moment it looked like MIPS wanted to equal or surpass Alpha in
> this respect.

If there is an architecture that I'd expect to try to take the "sucks more"
crown, MIPS would be it. They've already done the "worst cache award"
thing, and are proud members of the "stupid branch delay slot" crowd. MIPS
historically even did the "delayed load slot".

The only mistake they've never done, AFAIK, is to have a rotating register
file.

At the same time, the "load-to-dependent-store" thing you really have to
*work* at doing wrong. It's not enough to just have bad taste and
incompetent architects. You really have to spend real effort to screw up
that badly. It's really hard to do by mistake.

So I suspect that even MIPS can't get it wrong.

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

Re: [Xen-devel] [PATCH v9 02/25] docs/libxl: Introduce COLO_CONTEXT to support migration v2 colo streams

[Konrad Rzeszutek Wilk]

On Wed, Jan 27, 2016 at 03:15:47PM +, Andrew Cooper wrote:
> On 27/01/16 15:11, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jan 27, 2016 at 11:00:24AM +, Andrew Cooper wrote:
> >> On 27/01/16 06:47, Wen Congyang wrote:
> >>> On 01/27/2016 04:40 AM, Konrad Rzeszutek Wilk wrote:
>  On Wed, Dec 30, 2015 at 10:37:32AM +0800, Wen Congyang wrote:
> > It is the negotiation record for COLO.
> > Primary->Secondary:
> > control_id  0x: Secondary VM is out of sync, start a new 
> > checkpoint
> > Secondary->Primary:
> > 0x0001: Secondary VM is suspended
> > 0x0002: Secondary VM is ready
> > 0x0003: Secondary VM is resumed
> >
> > Signed-off-by: Wen Congyang 
> > Signed-off-by: Yang Hongyang 
> > ---
> >  docs/specs/libxl-migration-stream.pandoc | 25 +++--
> >  tools/libxl/libxl_sr_stream_format.h | 11 +++
> >  tools/python/xen/migration/libxl.py  |  9 +
> >  3 files changed, 43 insertions(+), 2 deletions(-)
> >
> > diff --git a/docs/specs/libxl-migration-stream.pandoc 
> > b/docs/specs/libxl-migration-stream.pandoc
> > index 2c97d86..5166d66 100644
> > --- a/docs/specs/libxl-migration-stream.pandoc
> > +++ b/docs/specs/libxl-migration-stream.pandoc
> > @@ -1,6 +1,6 @@
> >  % LibXenLight Domain Image Format
> >  % Andrew Cooper <>
> > -% Revision 1
> > +% Revision 2
> >  
> >  Introduction
> >  
> > @@ -119,7 +119,9 @@ type 0x: END
> >  
> >   0x0004: CHECKPOINT_END
> >  
> > - 0x0005 - 0x7FFF: Reserved for future _mandatory_
> > + 0x0005: CHECKPOINT_STATE
> > +
> > + 0x0006 - 0x7FFF: Reserved for future _mandatory_
>  This is in the 'mandatory' records. Should it be part of optional 
>  records?
> 
>  Would this checkpoint state always present on non-COLO guest migration?
> >>> No. Will be fixed in the next version
> >> It is correct that CHECKPOINT_STATE is a mandatory record.
> >>
> >> Optional records which are free for the receiving end to ignore if they
> >> are not understood.
> > What you are saying is that the receving end has to expect this 
> > (CHECKPOINT_STATE)
> > even there is nothing in them - as the size of them is zero (becuase there 
> > are
> > no  dirty PFNs to send).
> 
> The sole difference between a mandatory record an an option record is
> the receivers behaviour.
> 
> Mandatory records may not be ignored, and constitutes a hard error. 
> Optional records may be ignored, without error, if they are not understood.

You are still not answering my question.

Is it a hard error if the mandatory record is zero length?

> 
> ~Andrew

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

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

[Borislav Petkov]

On Wed, Jan 27, 2016 at 02:50:36PM +, David Vrabel wrote:
> Surely the interesting comparison here is how is (early) microcode
> loading disabled in KVM guests?

It isn't - kvm simply ignores the write to the microcode application
MSRs MSR_AMD64_PATCH_LOADER and MSR_IA32_UCODE_REV, respectively.

> We should use the same mechanism for HVMlite guests.

Good idea.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

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

Re: [Xen-devel] [PATCH v5] x86/p2m: use large pages for MMIO mappings

[Jan Beulich]

>>> On 27.01.16 at 15:51,  wrote:
> On 27/01/16 14:40, Jan Beulich wrote:
>>
>>  int set_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn,
>> -   p2m_access_t access)
>> +   unsigned int order, p2m_access_t access)
>>  {
>> -return set_typed_p2m_entry(d, gfn, mfn, p2m_mmio_direct, access);
>> +if ( order &&
>> + rangeset_overlaps_range(mmio_ro_ranges, mfn_x(mfn),
>> + mfn_x(mfn) + (1UL << order) - 1) &&
>> + !rangeset_contains_range(mmio_ro_ranges, mfn_x(mfn),
>> +  mfn_x(mfn) + (1UL << order) - 1) )
>> +return order;
> Should this not be a hard error?  Even retrying with a lower order is
> going fail.
 Why? The latest when order == 0, rangeset_overlaps_range()
 will return the same as rangeset_contains_range(), and hence
 the condition above will always be false (one of the two reasons
 for checking order first here).
>>> It isn't the order check which is an issue.
>>>
>>> One way or another, if the original (mfn/order) fails the rangeset
>>> checks, the overall call is going to fail, but it will be re-executed
>>> repeatedly with an order decreasing to 0.  Wouldn't it be better just to
>>> short-circuit this back?
>> But this won't necessarily go down to order 0. Short-circuiting
>> would mean taking PAGE_ORDER_2M and PAGE_ORDER_1G into
>> account here, which would imo severely hamper readability.
> 
> Even when this check starts passing, the subsequent
> set_typed_p2m_entry() will fail for writeable mappings, after having
> constructed small pages up to the boundary of the RO region.

I don't see where such failure would come from:
{ept_,}p2m_type_to_flags() silently suppress the mapping
becoming writable. What am I overlooking?

>>> Relatedly, is there actually anything wrong with making a superpage
>>> read-only mapping over some scattered read-only 4K pages?
>> I'm afraid I don't understand: "scattered pages" and "superpage
>> mapping" don't seem to fit together for me.
> 
> If there is a single 4K page in the RO region, and the caller attempts
> to create a RO 2M superpage which includes the 4K region, these checks
> will force the use of 4K mappings even though the 2M mapping would be fine.

Oh, so you want "access" to also be taken into account. Not
sure that's worth it right now - r/o MMIO mappings shouldn't
occur very often (and map_mmio_regions() passes
->default_access anyway).

Jan


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

Re: [Xen-devel] [PATCH v2 3/3] tools: introduce parameter max_wp_ram_ranges.

[Yu, Zhang]

On 1/27/2016 11:12 PM, Jan Beulich wrote:

On 27.01.16 at 15:56,  wrote:

On 1/27/2016 10:32 PM, Jan Beulich wrote:

On 27.01.16 at 15:13,  wrote:

About the truncation issue:
 I do not quite follow. Will this hurt if the value configured does
not exceed 4G? What about a type cast?


A typecast would not alter behavior in any way. And of course
a problem only arises if the value was above 4 billion. You either
need to refuse such values while the attempt is made to set it.
or you need to deal with the full range of possible values. Likely
the former is the better (and I wonder whether the upper
bound shouldn't be forced even lower than 4 billion).


Oh, I see. A check with the upper bound sounds better. Using 4G as the
upper bound is a little conservative, but I do not have any better
criteria right now. :)


But when making that decision keep security in mind: How much
memory would it take to populate 4G rangeset nodes?


Well, for XenGT, one extreme case I can imagine would be half of all
the guest ram is used as the GPU page table, and page frames containing
these page tables are discontinuous (rangeset can combine continuous
ranges). For other virtual devices to leverage the write-protected gfn
rangeset, I believe the same idea applies. :)
Is this logic OK?

Thanks
Yu

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

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

[osstest service owner]

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

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. 78610
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 78610
 test-armhf-armhf-xl-credit2  16 guest-start.2 fail REGR. vs. 78610

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 78610
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 78610
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 78610

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 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-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-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-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-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-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-libvirt-vhd 11 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-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  3b971de7f1cc595ae7ef03fb6f500295a8b82630
baseline version:
 xen  1949868d640427dc91bfb23741d78eb1d86841c8

Last test of basis78610  2016-01-20 10:56:23 Z7 days
Failing since 78703  2016-01-21 17:20:38 Z5 days5 attempts
Testing same since79108  2016-01-26 18:27:25 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  David Scott 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jonathan Creekmore 
  Malcolm Crossley 
  Olaf Hering 
  Roger Pau Monné 
  Tim Deegan 
  Wei Liu 
  Wen Congyang 

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

Re: [Xen-devel] xenbits GitHub mirror?

[George Dunlap]

On 27/01/16 15:45, Ian Campbell wrote:
> On Wed, 2016-01-27 at 15:18 +, Lars Kurth wrote:
>>> Doug says that you can mark a repo as a 'mirror', which will prevent
>>> people from being able to send pull requests to it; so I think my
>>> technical objection has been answered.
>>>
>>> I think the idea is still only half-baked though, as I'm not sure how
>>> having a github mirror will make it so that most mail has a git repo
>>> you can pull from (which would be necessary to reach the ultimate
>>> goal, making it straightforward to apply patches sent to the list).
>>
>>
>> I would be good, if we could identify any workflow issues (e.g. such as
>> the mailing issue raised here). Maybe some of the people who have hands-on
>> experience with Github and mailing lists can make a few suggestions. We
>> then should also consider adding this to the How to submit patches wiki
>> page
> 
> I don't think we want to encourage this for all submissions, nor dive too
> deeply into the workflows (given that Doug says we can disable GH PRs for
> the repo).
> 
> All Doug is trying to address is for the (infrequent) occasions when a
> series is particularly big and complicated to be able to say "please stick
> this in a git tree to ease review, oh and by the way if you need git
> hosting you could fork $this repo on github or $that repo on gitlab".

Right -- I see how this could help contributors contribute in a useful
fashion.

> For most patch series setting up a GH account and pushing the changes to it
> etc is pure overhead (or at least optional), there is no need to encourage
> it for most series, nor even necessarily to encourage people to proactively
> push to a repo, we can always ask if we find the series to hard to review
> as patches.

It did take me a while to find a system that made it not a pain to apply
patch series from xen-devel, and the solution I have now is very
particular to the combination of e-mail tools that I happen to use; I'm
not sure how transferrable they are.

So while I've managed to get things to a point where I don't have much
pain, it's probably something that could use some work as a project in
general.  "Encouraging most people to include public git branches" is
one option to help that; "Having a mail bot that gave you git-am'able
mbox files" is another.

 -George

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

Re: [Xen-devel] [PATCH v9 02/25] docs/libxl: Introduce COLO_CONTEXT to support migration v2 colo streams

[Ian Jackson]

Andrew Cooper writes ("Re: [Xen-devel] [PATCH v9 02/25] docs/libxl: Introduce 
COLO_CONTEXT to support migration v2 colo streams"):
> On 27/01/16 15:28, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jan 27, 2016 at 03:15:47PM +, Andrew Cooper wrote:
> >> Mandatory records may not be ignored, and constitutes a hard
> >> error.  Optional records may be ignored, without error, if they
> >> are not understood.

`Mandatory' is a somewhat misleading term.  (In a past life we called
these different kinds of protocol extension `harmful' and `harmless'.
A `harmless' extension is one that is safe to ignore if the receiver
does not know about the extension.  A `harmful' extension will always
cause a naive receiver to get a parse error.)

> > You are still not answering my question.
> >
> > Is it a hard error if the mandatory record is zero length?
>
> Not if the type specifies that a zero length record is permitted.

This is misleading.  Obviously the behaviour of a naive receiver
cannot depend on the specification document for the type, because that
specification document was written after the type was invented.


Let me provide an exhaustive case analysis:

  Optional or   Value sentReceiver knows   Receiver
   Mandatory  about the type?   behaviour

  Optional or   No record ofYesDepends on type
  Mandatory this type spec and semantics;
  reciever may fail
  if information is
  required.

  Optional or   Empty   YesDepends on type
  Mandatory  record(s)spec and semantics;
  empty record might be
  invalid or semantically
  inappropriate (eg
  inconsistent with
  other info)

  Optional or   NonemptyYesDepends on type
  Mandatory  record(s)spec and semantics

  Optional or   No record ofNo Whatever it does
  Mandatory this type normally, obviously



And these are the only cases where `Optional' or `Mandatory' makes a
difference:

  Optional  Empty   No Record(s) silently
 record(s)discarded by receiver

  Optional  NonemptyNo Record(s) silently
 record(s)discarded by receiver

  Mandatory Empty   No Receiver ABORTS
 record(s)entire operation

  Mandatory NonemptyNo Receiver ABORTS
 record(s)entire operation



There is nothing special about empty records.  Indeed an empty record
can be used as a flag.

Ian.

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

Re: [Xen-devel] libxl refactoring, call for discussion

[Pavlo Suikov]

Hi Ian,

I'll try to make clear domain restart thing first. Currently there are only
device entries in domain config for frontends with backend paths in them,
e.g.:

FrontendDomain.cfg:
vdevice = [ 'backend=BackendDomain,devid=0,device=/dev/device' ]

it is parsed only on frontend domain start, and libxl creates both frontend
and backend xenstore branches from that entry. Problem is, on backend
domain restart libxl does not re-read this config, because it belongs to
the frontend domain which is clearly not restarted, and as a consequence
xenstore backend branches are cleared (on backend shutdown) but not filled
again, because backend domain does not have any entries for this device.

What I propose is to add information needed to fill xenstore backend
branches to backend domains and remove it from frontend domains, so it
would possibly look like this:

FrontendDomain.cfg:
frontend:vdevice = [ 'backend=BackendDomain,devid=0' ]

BackendDomain.cfg:
backend:vdevice = ['frontend=FrontendDomain,devid=0,device=/dev/device']

Now we have all the information needed for both domains to restart
intependently filling their own xenstore branches. On FrontendDomain start
libxl fills only frontend branch for vdevice, and on backendDomain
start libxl fills only backend branch.

This can be easily done in backwards-compatible way: if frontend entry is
filled in the old format, it is used to fill both branches, but if we
explicitly state that it's only frontend or only backend entry, then it is
used to fill only the corresponding branch.

For the main part, that's it: currently the main thing we need is a DomD
restart, and such a change would be enough for that purpose with no need
for dirty hacks.

But from that point we can make one step further: to remove split driver
connection information from user domains. It would possibly look like this:

FrontendDomain.cfg:
frontend:vdevice = [ 'devid=0' ]

BackendDomain.cfg:
backend:vdevice = ['devid=0,devname=Main,device=/dev/device']

SupervisorDomain.cfg:
backend:vdevice = ['devid=0,devname=Fallback,device=/dev/device']

connection:vdevice = ['devid=0, frontend=FrontendDomain, backend=BackendDomain,
devname=Main']
connection:vdevice = ['devid=0, frontend=FrontendDomain,
backend=SupervisorDomain,
devname=Fallback']

Motivation for this example is the following: if we have, e.g., PV GPU
which is used in user domain and we have restrictions on graphics
availability, we can monitor if main device backend hanged and make a
runtime switch to a fallback device (software rendering) till main backend
would be restated. Connections are static, they generally do not change and
do not actually belong to any user domain, so there is no need clearing and
refilling them on every domain restart.

This can be easily done in backwards-compatible way as well: if entries
already have connection information, we stick to the old model; if they
don't, we look for the connection branch to fill missing fields and to
setup fallback paths.

There still is an issue with hoplug devices being non-persistent (xl
vdevice-attach fills both frontend and backend branches, but restart of any
of user domains looses this information). At the moment we fix this rather
dirty with additional 'hotplugged' xenstore branch bot belonging to any
domain so it's not erased on shutdown but is being read on domain start if
exists. In context of reworking libxl, I believe this one can be done as
well, though I still don't have a solution I would like.




Suikov Pavlo
GlobalLogic
P +x.xxx.xxx.  M +38.066.667.1296  S psujkov
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

On Wed, Jan 27, 2016 at 4:26 PM, Ian Campbell 
wrote:

> On Mon, 2016-01-25 at 15:38 +0200, Pavlo Suikov wrote:
> > Hi everyone,
> >
> > I want to bring domain restart question for a discussion. It originates
> > from DomD restart, but the solution I am about to offer can be quite
> > generic.
> >
> > Problem is, domain specification currently holds only frontend info,
> > which is used to generate both frontend and backend entries for a device;
> > that means that backend xenstore data is handled not by a domain that
> > owns backends, but by a domain that has frontends linked to these
> > backends. As a result, reboot of any domain with backends without reboot
> > of the corresponding frontend domains is impossible.
> >
> > This is wrong on many levels, but the main thing is: some domains don't
> > know something they should (do they have any backends) and some know
> > something they should not (there are backends for their frontends in
> > different domains).
> >
> > I propose following change: make domain "require" and "provide"
> > interfaces visible (think CORBA), hold connections between the two in the
> > priveleged domain (where toolstack is, think controller from the MVC
> > idiom). With this change domains (except for Dom0 which is a special
> > case) can be rebooted in 

Re: [Xen-devel] [PATCH] arm: clean up build variables

[Doug Goldstein]

On 1/27/16 9:24 AM, Ian Campbell wrote:
> On Wed, 2016-01-27 at 09:11 -0600, Doug Goldstein wrote:
>> On 1/27/16 9:05 AM, Ian Campbell wrote:
>>> On Wed, 2016-01-27 at 07:44 -0700, Jan Beulich wrote:
>>> On 27.01.16 at 15:30,  wrote:
> On 1/25/16 5:27 AM, Ian Campbell wrote:
>> On Wed, 2016-01-20 at 15:47 -0600, Doug Goldstein wrote:
>>> @@ -52,7 +52,7 @@ ALL_OBJS := $(TARGET_SUBARCH)/head.o
>>> $(ALL_OBJS)
>>>  
>>>  $(TARGET): $(TARGET)-syms $(TARGET).axf
>>> $(OBJCOPY) -O binary -S $< $@
>>> -ifeq (arm64,$(XEN_TARGET_ARCH))
>>> +ifdef CONFIG_ARM_64
>>
>> The old way looks to be the prevailing normal form. I don't
>> especially
>> object to the change but things ought to remain consistent.
>
> Which part? Using arm32/arm64? Or having the if blocks rather than
> var-$(CONFIG_THING) ?
>
> My goal here is consistency and that was to standardize on the form
> of
> var-$(CONFIG_THING) across the board.

 But there's no var-$(CONFIG_THING) in the code above.
>>>
>>> Indeed, I was referring to the change from:
>>>
>>> -ifeq (arm64,$(XEN_TARGET_ARCH))
>>>
>>> to
>>>
>>> +ifdef CONFIG_ARM_64
>>>
>>> While:
>>>
>>> ifeq ($(CONFIG_ARM_64),y)
>>>
>>> is the more prevalent style.
>>>
>>> Ian.
>>>
>>
>> Oh sure. We can do that. Would you like me to send a v2 or are you
>> comfortable squashing that into the patch?
> 
> I may as well just do it, thanks.
> 
> 

I'll change my style going forward to use that form as well.

-- 
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] libxl refactoring, call for discussion

[Ian Campbell]

On Wed, 2016-01-27 at 18:20 +0200, Pavlo Suikov wrote:
> Hi Ian,

Please don't top post and please use plain text emails, not html.

> I'll try to make clear domain restart thing first. Currently there are
> only device entries in domain config for frontends with backend paths in
> them, e.g.:
> 
> FrontendDomain.cfg:
> vdevice = [ 'backend=BackendDomain,devid=0,device=/dev/device' ]
> 
> it is parsed only on frontend domain start, and libxl creates both
> frontend and backend xenstore branches from that entry. Problem is, on
> backend domain restart libxl does not re-read this config,

libxl _never_ reads this config. This is an xl configuration file. xl is
one user of libxl, but not the only one (libvirt is another for example).
It is important to keep the distinction in mind when discussing these APIs.

libxl gets libxl_device_disk structs from xl.

>  because it belongs to the frontend domain which is clearly not
> restarted, and as a consequence xenstore backend branches are cleared (on
> backend shutdown) but not filled again, because backend domain does not
> have any entries for this device.

The information regarding which backends a domain has is present in
xenstore (in /local/domain//backends) and libxl could make use of
that information when restarting a domain, including following the trail to
the frontend configuration.

If needed libxl could also make a note in a backend domain location when
starting a frontend of anything which it might need in order to restart
that backend. Likewise if anything which libxl needs in order to restart a
backend is missing it should just be added.

I think most of the problem here is just that libxl is not making use of
the information which it already has available when rebooting a domain
which has backends attached.

> What I propose is to add information needed to fill xenstore backend
> branches to backend domains and remove it from frontend domains, so it
> would possibly look like this:
> 
> FrontendDomain.cfg:
> frontend:vdevice = [ 'backend=BackendDomain,devid=0' ]
> 
> BackendDomain.cfg:
> backend:vdevice = ['frontend=FrontendDomain,devid=0,device=/dev/device']

Leaving aside that this proposal is xl specific and not addressing the more
important libxl API I don't think that having to predeclare the set of
backends when starting the backend domain is going to be feasible in the
general case (where domains are created dynamically and in an adhoc way by
users without the foresight afforded to embedded situations).

In any case as described above I think you are solving an issue which
doesn't actually exist.

[...]
> Motivation for this example is the following: if we have, e.g., PV GPU
> which is used in user domain and we have restrictions on graphics
> availability, we can monitor if main device backend hanged and make a
> runtime switch to a fallback device (software rendering) till main
> backend would be restated. Connections are static, they generally do not
> change and do not actually belong to any user domain, so there is no need
> clearing and refilling them on every domain restart.

I think you need to think about this in terms of the underlying libxl APIs
(i.e. libxl_device__reconnect() or something) before thinking about
what the xl cfg file format and commands might be like.

> There still is an issue with hoplug devices being non-persistent (xl
> vdevice-attach fills both frontend and backend branches, but restart of
> any of user domains looses this information).

Not since 4.5 (or maybe 4.6), libxl now records such dynamic changes and
they are preserved on reboot (or should be, if not then there is a bug
somewhere).

Ian.

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

Re: [Xen-devel] [PATCH v9 02/25] docs/libxl: Introduce COLO_CONTEXT to support migration v2 colo streams

[Andrew Cooper]

On 27/01/16 15:28, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 27, 2016 at 03:15:47PM +, Andrew Cooper wrote:
>> On 27/01/16 15:11, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Jan 27, 2016 at 11:00:24AM +, Andrew Cooper wrote:
 On 27/01/16 06:47, Wen Congyang wrote:
> On 01/27/2016 04:40 AM, Konrad Rzeszutek Wilk wrote:
>> On Wed, Dec 30, 2015 at 10:37:32AM +0800, Wen Congyang wrote:
>>> It is the negotiation record for COLO.
>>> Primary->Secondary:
>>> control_id  0x: Secondary VM is out of sync, start a new 
>>> checkpoint
>>> Secondary->Primary:
>>> 0x0001: Secondary VM is suspended
>>> 0x0002: Secondary VM is ready
>>> 0x0003: Secondary VM is resumed
>>>
>>> Signed-off-by: Wen Congyang 
>>> Signed-off-by: Yang Hongyang 
>>> ---
>>>  docs/specs/libxl-migration-stream.pandoc | 25 +++--
>>>  tools/libxl/libxl_sr_stream_format.h | 11 +++
>>>  tools/python/xen/migration/libxl.py  |  9 +
>>>  3 files changed, 43 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/docs/specs/libxl-migration-stream.pandoc 
>>> b/docs/specs/libxl-migration-stream.pandoc
>>> index 2c97d86..5166d66 100644
>>> --- a/docs/specs/libxl-migration-stream.pandoc
>>> +++ b/docs/specs/libxl-migration-stream.pandoc
>>> @@ -1,6 +1,6 @@
>>>  % LibXenLight Domain Image Format
>>>  % Andrew Cooper <>
>>> -% Revision 1
>>> +% Revision 2
>>>  
>>>  Introduction
>>>  
>>> @@ -119,7 +119,9 @@ type 0x: END
>>>  
>>>   0x0004: CHECKPOINT_END
>>>  
>>> - 0x0005 - 0x7FFF: Reserved for future _mandatory_
>>> + 0x0005: CHECKPOINT_STATE
>>> +
>>> + 0x0006 - 0x7FFF: Reserved for future _mandatory_
>> This is in the 'mandatory' records. Should it be part of optional 
>> records?
>>
>> Would this checkpoint state always present on non-COLO guest migration?
> No. Will be fixed in the next version
 It is correct that CHECKPOINT_STATE is a mandatory record.

 Optional records which are free for the receiving end to ignore if they
 are not understood.
>>> What you are saying is that the receving end has to expect this 
>>> (CHECKPOINT_STATE)
>>> even there is nothing in them - as the size of them is zero (becuase there 
>>> are
>>> no  dirty PFNs to send).
>> The sole difference between a mandatory record an an option record is
>> the receivers behaviour.
>>
>> Mandatory records may not be ignored, and constitutes a hard error. 
>> Optional records may be ignored, without error, if they are not understood.
> You are still not answering my question.
>
> Is it a hard error if the mandatory record is zero length?

Not if the type specifies that a zero length record is permitted.

~Andrew

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

Re: [Xen-devel] xenbits GitHub mirror?

[Ian Campbell]

On Wed, 2016-01-27 at 15:18 +, Lars Kurth wrote:
> > Doug says that you can mark a repo as a 'mirror', which will prevent
> > people from being able to send pull requests to it; so I think my
> > technical objection has been answered.
> > 
> > I think the idea is still only half-baked though, as I'm not sure how
> > having a github mirror will make it so that most mail has a git repo
> > you can pull from (which would be necessary to reach the ultimate
> > goal, making it straightforward to apply patches sent to the list).
> 
> 
> I would be good, if we could identify any workflow issues (e.g. such as
> the mailing issue raised here). Maybe some of the people who have hands-on
> experience with Github and mailing lists can make a few suggestions. We
> then should also consider adding this to the How to submit patches wiki
> page

I don't think we want to encourage this for all submissions, nor dive too
deeply into the workflows (given that Doug says we can disable GH PRs for
the repo).

All Doug is trying to address is for the (infrequent) occasions when a
series is particularly big and complicated to be able to say "please stick
this in a git tree to ease review, oh and by the way if you need git
hosting you could fork $this repo on github or $that repo on gitlab".

For most patch series setting up a GH account and pushing the changes to it
etc is pure overhead (or at least optional), there is no need to encourage
it for most series, nor even necessarily to encourage people to proactively
push to a repo, we can always ask if we find the series to hard to review
as patches.

Ian.

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

Re: [Xen-devel] [PATCH v2 3/3] tools: introduce parameter max_wp_ram_ranges.

[Jan Beulich]

>>> On 27.01.16 at 16:23,  wrote:

> 
> On 1/27/2016 11:12 PM, Jan Beulich wrote:
> On 27.01.16 at 15:56,  wrote:
>>> On 1/27/2016 10:32 PM, Jan Beulich wrote:
>>> On 27.01.16 at 15:13,  wrote:
> About the truncation issue:
>  I do not quite follow. Will this hurt if the value configured does
> not exceed 4G? What about a type cast?

 A typecast would not alter behavior in any way. And of course
 a problem only arises if the value was above 4 billion. You either
 need to refuse such values while the attempt is made to set it.
 or you need to deal with the full range of possible values. Likely
 the former is the better (and I wonder whether the upper
 bound shouldn't be forced even lower than 4 billion).
>>>
>>> Oh, I see. A check with the upper bound sounds better. Using 4G as the
>>> upper bound is a little conservative, but I do not have any better
>>> criteria right now. :)
>>
>> But when making that decision keep security in mind: How much
>> memory would it take to populate 4G rangeset nodes?
>>
> Well, for XenGT, one extreme case I can imagine would be half of all
> the guest ram is used as the GPU page table, and page frames containing
> these page tables are discontinuous (rangeset can combine continuous
> ranges). For other virtual devices to leverage the write-protected gfn
> rangeset, I believe the same idea applies. :)
> Is this logic OK?

I can follow it, yes, but 4G ranges mean 16Tb of memory put
in page tables, which to be honest doesn't seem reasonable to
me.

Jan


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

Re: [Xen-devel] schedulers and topology exposing questions

[Konrad Rzeszutek Wilk]

On Wed, Jan 27, 2016 at 03:53:38PM +, George Dunlap wrote:
> On 27/01/16 15:27, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jan 27, 2016 at 03:10:01PM +, George Dunlap wrote:
> >> On 27/01/16 14:33, Konrad Rzeszutek Wilk wrote:
> >>> On Xen - the schedule() would go HLT.. and then later be woken up by the
> >>> VIRQ_TIMER. And since the two applications were on seperate CPUs - the
> >>> single packet would just stick in the queue until the VIRQ_TIMER arrived.
> >>
> >> I'm not sure I understand the situation right, but it sounds a bit like
> >> what you're seeing is just a quirk of the fact that Linux doesn't always
> >> send IPIs to wake other processes up (either by design or by accident),
> > 
> > It does and it does not :-)
> > 
> >> but relies on scheduling timers to check for work to do.  Presumably
> > 
> > It .. I am not explaining it well. The Linux kernel scheduler when
> > called for 'schedule' (from the UDP sendmsg) would either pick the next
> > appliction and do a context swap - of if there were none - go to sleep.
> > [Kind of - it also may do an IPI to the other CPU if requested ,but that 
> > requires
> > some hints from underlaying layers]
> > Since there were only two apps on the runqueue - udp sender and udp receiver
> > it would run them back-to back (this is on baremetal)
> 
> I think I understand at a high level from your description what's
> happening (No IPIs -> happens to run if on the same cpu, waits until
> next timer tick if on a different cpu); but what I don't quite get is
> *why* Linux doesn't send an IPI.

Wait no no.

"happens to run if on the same cpu" - only if on baremetal or if
we expose SMT topology to a guest.

Otherwise the applications are not on the same CPU.

The sending IPI part is because there are two CPUs - and the apps on those
two runqeueus are not intertwined from the perspective of the scheduler.
(Unless the udp code has given the scheduler hints).


However if I tasket the applications on the same vCPU (this being without
exposing SMT threads or just the normal situation as today) - the scheduler
will send IPI context switches.

Then I found that if I enable vAPIC and disable event channels for IPIs
and only use the native APIC machinery for (aka vAPIC) we can even do less
VMEXITs, but that is a different story:
http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg00897.html

> 
> It's been quite a while since I looked at the Linux scheduling code, so
> I'm trying to understand it based a lot on the Xen code. In Xen a vcpu
> can be "runnable" (has something to do) and "blocked" (waiting for
> something to do). Whenever a vcpu goes from "blocked" to "runnable", the
> scheduler will call vcpu_wake(), which sends an IPI to the appropriate
> pcpu to get it to run the vcpu.
> 
> What you're describing is a situation where a process is blocked (either
> in 'listen' or 'read'), and another process does something which should
> cause it to become 'runnable' (sends it a UDP message). If anyone
> happens to run the scheduler on its cpu, it will run; but no proactive
> actions are taken to wake it up (i.e., sending an IPI).

Right. And that is a UDP code decision. It called the schedule without
any timeout or hints.
> 
> The idea of not sending an IPI when a process goes from "waiting for
> something to do" to "has something to do" seems strange to me; and if it
> wasn't a mistake, then my only guess why they would choose to do that
> would be to reduce IPI traffic on large systems.
> 
> But whether it's a mistake or on purpose, it's a Linux thing, so...

Yes :-)
> 
> >> they knew that low performance on ping-pong workloads might be a
> >> possibility when they wrote the code that way; I don't see a reason why
> >> we should try to work around that in Xen.
> > 
> > Which is not what I am suggesting.
> 
> I'm glad we agree on this. :-)
> 
> > Our first ideas was that since this is a Linux kernel schduler 
> > characteristic
> > - let us give the guest all the information it needs to do this. That is
> > make it look as baremetal as possible - and that is where the vCPU
> > pinning and the exposing of SMT information came about. That (Elena
> > pls correct me if I am wrong) did indeed show that the guest was doing
> > what we expected.
> > 
> > But naturally that requires pinning and all that - and while it is a useful
> > case for those that have the vCPUs to spare and can do it - that is not
> > a general use-case.
> > 
> > So Elena started looking at the CPU bound and seeing how Xen behaves then
> > and if we can improve the floating situation as she saw some abnormal
> > behavious.
> 
> OK -- if the focus was on the two cases where the Xen credit1 scheduler
> (apparently) co-located two cpu-burning vcpus on sibling threads, then
> yeah, that's behavior we should probably try to get to the bottom of.

Right!

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

Re: [Xen-devel] [PATCH v2 3/3] tools: introduce parameter max_wp_ram_ranges.

[Yu, Zhang]

On 1/27/2016 11:58 PM, Jan Beulich wrote:

On 27.01.16 at 16:23,  wrote:




On 1/27/2016 11:12 PM, Jan Beulich wrote:

On 27.01.16 at 15:56,  wrote:

On 1/27/2016 10:32 PM, Jan Beulich wrote:

On 27.01.16 at 15:13,  wrote:

About the truncation issue:
  I do not quite follow. Will this hurt if the value configured does
not exceed 4G? What about a type cast?


A typecast would not alter behavior in any way. And of course
a problem only arises if the value was above 4 billion. You either
need to refuse such values while the attempt is made to set it.
or you need to deal with the full range of possible values. Likely
the former is the better (and I wonder whether the upper
bound shouldn't be forced even lower than 4 billion).


Oh, I see. A check with the upper bound sounds better. Using 4G as the
upper bound is a little conservative, but I do not have any better
criteria right now. :)


But when making that decision keep security in mind: How much
memory would it take to populate 4G rangeset nodes?


Well, for XenGT, one extreme case I can imagine would be half of all
the guest ram is used as the GPU page table, and page frames containing
these page tables are discontinuous (rangeset can combine continuous
ranges). For other virtual devices to leverage the write-protected gfn
rangeset, I believe the same idea applies. :)
Is this logic OK?


I can follow it, yes, but 4G ranges mean 16Tb of memory put
in page tables, which to be honest doesn't seem reasonable to
me.



Thanks for your reply, Jan.
In most cases max_memkb in configuration file will not be set to such a
big value. So I'd suggest we use a comparison between the one
calculated from max_memkb and 4G, and choose the smaller one as upper
bound. If some time in the future, it becomes common cases for VMs to
use huge rams, we should use uint64 for the rangeset limit other than a 
uint32.


Yu

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

[Xen-devel] Xen Project Infrastructure Maintenance: xenbits (Jan 28), qemu-bitslave & mail & downloads.xenproject.org (Feb 1), lists & etherpad (Feb 4th)

[Lars Kurth]

Hi everyone,

we are rebooting a number of Xen Project services in the next few days to 
upgrade operating systems. This means that a few services may be temporarily 
unavailable. The following websites are affected and will be done during the 
times below. If you notice any issues after the reboot, please reply to this 
mail or check on the #xeninfra IRC channel.

= Jan 28, 7am - 9am UTC : affecting xenbits =
Affected services: Xen Project source code repositories, automatically 
generated xenproject docs, list of security vulnerabilities
If you need to clone or commit to any affected repositories please do so before 
or after

= Feb 1, 7am - 9am UTC : affecting qemu-bitslave and xenproject.org mail 
aliases and downloads.xenproject.org =
Affected services: qemu-bitslave, mail server, DNS and downloads.xenproject.org
Note that mails to e-mails using foo-...@xenproject.org may be delayed during 
the maintenance window. 

= Feb 4, 7am - 9am UTC : affecting xen project mailing lists & ether pad =
Affected services: all f...@lists.xenproject.org mailing lists and ether pads
Note that mails to all mailing lists will be delayed during the maintenance 
window

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

Re: [Xen-devel] [PATCH] arm: clean up build variables

[Ian Campbell]

On Wed, 2016-01-27 at 09:11 -0600, Doug Goldstein wrote:
> On 1/27/16 9:05 AM, Ian Campbell wrote:
> > On Wed, 2016-01-27 at 07:44 -0700, Jan Beulich wrote:
> > > > > > On 27.01.16 at 15:30,  wrote:
> > > > On 1/25/16 5:27 AM, Ian Campbell wrote:
> > > > > On Wed, 2016-01-20 at 15:47 -0600, Doug Goldstein wrote:
> > > > > > @@ -52,7 +52,7 @@ ALL_OBJS := $(TARGET_SUBARCH)/head.o
> > > > > > $(ALL_OBJS)
> > > > > >  
> > > > > >  $(TARGET): $(TARGET)-syms $(TARGET).axf
> > > > > >     $(OBJCOPY) -O binary -S $< $@
> > > > > > -ifeq (arm64,$(XEN_TARGET_ARCH))
> > > > > > +ifdef CONFIG_ARM_64
> > > > > 
> > > > > The old way looks to be the prevailing normal form. I don't
> > > > > especially
> > > > > object to the change but things ought to remain consistent.
> > > > 
> > > > Which part? Using arm32/arm64? Or having the if blocks rather than
> > > > var-$(CONFIG_THING) ?
> > > > 
> > > > My goal here is consistency and that was to standardize on the form
> > > > of
> > > > var-$(CONFIG_THING) across the board.
> > > 
> > > But there's no var-$(CONFIG_THING) in the code above.
> > 
> > Indeed, I was referring to the change from:
> > 
> > -ifeq (arm64,$(XEN_TARGET_ARCH))
> > 
> > to
> > 
> > +ifdef CONFIG_ARM_64
> > 
> > While:
> > 
> > ifeq ($(CONFIG_ARM_64),y)
> > 
> > is the more prevalent style.
> > 
> > Ian.
> > 
> 
> Oh sure. We can do that. Would you like me to send a v2 or are you
> comfortable squashing that into the patch?

I may as well just do it, thanks.



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

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

[Konrad Rzeszutek Wilk]

On Wed, Jan 27, 2016 at 10:17:56AM -0500, Boris Ostrovsky wrote:
> On 01/27/2016 10:09 AM, David Vrabel wrote:
> >On 27/01/16 15:06, Boris Ostrovsky wrote:
> >>On 01/27/2016 09:50 AM, David Vrabel wrote:
> >>>On 27/01/16 14:42, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 26, 2016 at 08:54:56PM -0800, Luis R. Rodriguez wrote:
> >On Jan 26, 2016 6:16 PM, "Luis R. Rodriguez"  wrote:
> >>On Tue, Jan 26, 2016 at 4:04 PM, Luis R. Rodriguez 
> >wrote:
> >>>You go:
> >>>
> >>>hvmlite_start_xen() -->
> >>>  HVM stub
> >>>  startup_64() | (startup_32()
> >>Hrm, does HVMlite work well with load_ucode_bsp(), note the patches to
> >>rebrand pv_enabled() to pv_legacy() or whatever, this PV type will not
> >>be legacy or crap / old, so we'd need a way to catch it if we should
> >>not use that code for this PV type. This begs the question, are you
> >>also sure other callers in startup_32() or startup_64() might be OK as
> >>well where previously guarded with pv_enabled() ?
> >Actually this call can't be used, and if early code used it prior to
> >setup_arch() it'd be a bug as its only properly set until later.
> >Vetting
> >for correctness of all code call is still required though and
> >perhaps we do
> >need something to catch now this PV type on early code such as this
> >one if
> >we don't want it. From what I've gathered before on other bsp ucode we
> >don't want ucode loaded for PV guest types through these mechanisms.
> It may help to not think of PVH/hvmlite as PV. It really is HVM with
> a lot
> of emulated devices removed.
> 
> How does early microcode work on EFI? Does the EFI stub code have an
> early
> microcode loading code ?
> >>>Surely the interesting comparison here is how is (early) microcode
> >>>loading disabled in KVM guests?  We should use the same mechanism for
> >
> >>>HVMlite guests.
> >>
> >>Why would we ever want to have a guest load microcode during boot? I can
> >>see how a (privileged) guest may want to load microcode from a shell
> >>(via microcode driver).
> >I think you missed a word when you read my reply.
> 
> Yes, I missed it ;-)
> 
> Why not continue relying on paravirt_enabled()? We are going to keep this in
> some form for HVMlite.

And this is where Luis comes in. He has posted an patchset which removes the
paravirt_enabled with .. Here is the link https://lkml.org/lkml/2015/12/15/772

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

Re: [Xen-devel] schedulers and topology exposing questions

[Konrad Rzeszutek Wilk]

On Wed, Jan 27, 2016 at 03:10:01PM +, George Dunlap wrote:
> On 27/01/16 14:33, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jan 26, 2016 at 11:21:36AM +, George Dunlap wrote:
> >> On 22/01/16 16:54, Elena Ufimtseva wrote:
> >>> Hello all!
> >>>
> >>> Dario, Gerorge or anyone else,  your help will be appreciated.
> >>>
> >>> Let me put some intro to our findings. I may forget something or put 
> >>> something
> >>> not too explicit, please ask me.
> >>>
> >>> Customer filled a bug where some of the applications were running slow in 
> >>> their HVM DomU setups.
> >>> These running times were compared against baremetal running same kernel 
> >>> version as HVM DomU.
> >>>
> >>> After some investigation by different parties, the test case scenario was 
> >>> found
> >>> where the problem was easily seen. The test app is a udp server/client 
> >>> pair where
> >>> client passes some message n number of times.
> >>> The test case was executed on baremetal and Xen DomU with kernel version 
> >>> 2.6.39.
> >>> Bare metal showed 2x times better result that DomU.
> >>>
> >>> Konrad came up with a workaround that was setting the flag for domain 
> >>> scheduler in linux
> >>> As the guest is not aware of SMT-related topology, it has a flat topology 
> >>> initialized.
> >>> Kernel has domain scheduler flags for scheduling domain CPU set to 4143 
> >>> for 2.6.39.
> >>> Konrad discovered that changing the flag for CPU sched domain to 4655
> >>> works as a workaround and makes Linux think that the topology has SMT 
> >>> threads.
> >>> This workaround makes the test to complete almost in same time as on 
> >>> baremetal (or insignificantly worse).
> >>>
> >>> This workaround is not suitable for kernels of higher versions as we 
> >>> discovered.
> >>>
> >>> The hackish way of making domU linux think that it has SMT threads (along 
> >>> with matching cpuid)
> >>> made us thinks that the problem comes from the fact that cpu topology is 
> >>> not exposed to
> >>> guest and Linux scheduler cannot make intelligent decision on scheduling.
> >>>
> >>> Joao Martins from Oracle developed set of patches that fixed the 
> >>> smt/core/cashe
> >>> topology numbering and provided matching pinning of vcpus and enabling 
> >>> options,
> >>> allows to expose to guest correct topology.
> >>> I guess Joao will be posting it at some point.
> >>>
> >>> With this patches we decided to test the performance impact on different 
> >>> kernel versionand Xen versions.
> >>>
> >>> The test described above was labeled as IO-bound test.
> >>
> >> So just to clarify: The client sends a request (presumably not much more
> >> than a ping) to the server, and waits for the server to respond before
> >> sending another one; and the server does the reverse -- receives a
> >> request, responds, and then waits for the next request.  Is that right?
> > 
> > Yes.
> >>
> >> How much data is transferred?
> > 
> > 1 packet, UDP
> >>
> >> If the amount of data transferred is tiny, then the bottleneck for the
> >> test is probably the IPI time, and I'd call this a "ping-pong"
> >> benchmark[1].  I would only call this "io-bound" if you're actually
> >> copying large amounts of data.
> > 
> > What we found is that on baremetal the scheduler would put both apps
> > on the same CPU and schedule them right after each other. This would
> > have a high IPI as the scheduler would poke itself.
> > On Xen it would put the two applications on seperate CPUs - and there
> > would be hardly any IPI.
> 
> Sorry -- why would the scheduler send itself an IPI if it's on the same
> logical cpu (which seems pretty pointless), but *not* send an IPI to the
> *other* processor when it was actually waking up another task?
> 
> Or do you mean high context switch rate?

Yes, very high.
> 
> > Digging deeper in the code I found out that if you do an UDP sendmsg
> > without any timeouts - it would put it in a queue and just call schedule.
> 
> You mean, it would mark the other process as runnable somehow, but not
> actually send an IPI to wake it up?  Is that a new "feature" designed

Correct - because the other process was not on its vCPU runqueue.

> for large systems, to reduce the IPI traffic or something?

This is just a normal Linux scheduler. The only way it would do an IPI
to the other CPU was if the UDP message had an timeout. The default
timeout is infite so it didn't bother to send an IPI.

> 
> > On baremetal the schedule would result in scheduler picking up the other
> > task, and starting it - which would dequeue immediately.
> > 
> > On Xen - the schedule() would go HLT.. and then later be woken up by the
> > VIRQ_TIMER. And since the two applications were on seperate CPUs - the
> > single packet would just stick in the queue until the VIRQ_TIMER arrived.
> 
> I'm not sure I understand the situation right, but it sounds a bit like
> what you're seeing is just a quirk of the fact that Linux doesn't always
> send IPIs to wake other processes up (either by design or 

Re: [Xen-devel] [PATCH v4 06/21] arm/acpi: Parse FADT table and get PSCI flags

[Stefano Stabellini]

On Sat, 23 Jan 2016, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set, the
> former signals to the OS that the hardware is PSCI compliant. The latter
> selects the appropriate conduit for PSCI calls by toggling between
> Hypervisor Calls (HVC) and Secure Monitor Calls (SMC). FADT table
> contains such information, parse FADT to get the flags for furture
> usage.
> 
> Since STAO table and the GIC version are introduced by ACPI 6.0, we will
> check the version and only parse FADT table with version >= 6.0. If
> firmware provides ACPI tables with ACPI version less than 6.0, OS will
> be messed up with those information, so disable ACPI if we get an FADT
> table with version less than 6.0.
> 
> Signed-off-by: Hanjun Guo 
> Signed-off-by: Naresh Bhat 
> Signed-off-by: Parth Dixit 
> Signed-off-by: Shannon Zhao 
> ---
> V4: drop disable_acpi in acpi_parse_fadt
> ---
>  xen/arch/arm/acpi/boot.c   | 30 ++
>  xen/arch/arm/acpi/lib.c| 12 
>  xen/include/asm-arm/acpi.h |  9 +
>  3 files changed, 51 insertions(+)
> 
> diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
> index 1570f7e..6b33fbe 100644
> --- a/xen/arch/arm/acpi/boot.c
> +++ b/xen/arch/arm/acpi/boot.c
> @@ -27,9 +27,32 @@
>  
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  
>  #include 
>  
> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
> +{
> +struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> +
> +/*
> + * Revision in table header is the FADT Major revision, and there
> + * is a minor revision of FADT which was introduced by ACPI 6.0,
> + * we only deal with ACPI 6.0 or newer revision to get GIC and SMP
> + * boot protocol configuration data, or we will disable ACPI.
> + */
> +if ( table->revision > 6
> + || (table->revision == 6 && fadt->minor_revision >= 0) )
> +return 0;
> +
> +printk("Unsupported FADT revision %d.%d, should be 6.0+, will disable 
> ACPI\n",
> +table->revision, fadt->minor_revision);
> +
> +return -EINVAL;
> +}
> +
>  /*
>   * acpi_boot_table_init() called from setup_arch(), always.
>   *  1. find RSDP and get its address, and then find XSDT
> @@ -54,5 +77,12 @@ int __init acpi_boot_table_init(void)
>  return error;
>  }
>  
> +if ( acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt) )
> +{
> +/* disable ACPI if no FADT is found */
> +disable_acpi();
> +printk("Can't find FADT\n");
> +}
> +
>  return 0;
>  }
> diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
> index f817fe6..a30e4e6 100644
> --- a/xen/arch/arm/acpi/lib.c
> +++ b/xen/arch/arm/acpi/lib.c
> @@ -50,3 +50,15 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
>  
>   return ((char *) base + offset);
>  }
> +
> +/* 1 to indicate PSCI 0.2+ is implemented */
> +bool_t __init acpi_psci_present(void)
> +{
> +return acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT;
> +}
> +
> +/* 1 to indicate HVC is present instead of SMC as the PSCI conduit */
> +bool_t __init acpi_psci_hvc_present(void)
> +{
> +return acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC;
> +}

So far so good.


> diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
> index 6a037c9..1ce88f8 100644
> --- a/xen/include/asm-arm/acpi.h
> +++ b/xen/include/asm-arm/acpi.h
> @@ -31,6 +31,15 @@
>  #define ACPI_MAP_MEM_ATTR  PAGE_HYPERVISOR
>  
>  extern bool_t acpi_disabled;
> +
> +#ifdef CONFIG_ACPI
> +bool_t __init acpi_psci_present(void);
> +bool_t __init acpi_psci_hvc_present(void);
> +#else
> +static inline bool_t acpi_psci_present(void) { return false; }
> +static inline bool_t acpi_psci_hvc_present(void) {return false; }
> +#endif /* CONFIG_ACPI */
> +
>  /* Basic configuration for ACPI */
>  static inline void disable_acpi(void)
>  {

I would prefer if we only defined each function once, outside the ifdef
(no static inline needed). Then we could

#ifdef CONFIG_ACPI
extern bool_t acpi_disabled;
#else
#define acpi_disabled (1)
#endif

Which would solve the problem for !CONFIG_ACPI cases. But you need to be
careful to move bool_t acpi_disabled, enable_acpi and disable_acpi
inside an ifdef.

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

Re: [Xen-devel] schedulers and topology exposing questions

[Elena Ufimtseva]

On Wed, Jan 27, 2016 at 10:27:01AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 27, 2016 at 03:10:01PM +, George Dunlap wrote:
> > On 27/01/16 14:33, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Jan 26, 2016 at 11:21:36AM +, George Dunlap wrote:
> > >> On 22/01/16 16:54, Elena Ufimtseva wrote:
> > >>> Hello all!
> > >>>
> > >>> Dario, Gerorge or anyone else,  your help will be appreciated.
> > >>>
> > >>> Let me put some intro to our findings. I may forget something or put 
> > >>> something
> > >>> not too explicit, please ask me.
> > >>>
> > >>> Customer filled a bug where some of the applications were running slow 
> > >>> in their HVM DomU setups.
> > >>> These running times were compared against baremetal running same kernel 
> > >>> version as HVM DomU.
> > >>>
> > >>> After some investigation by different parties, the test case scenario 
> > >>> was found
> > >>> where the problem was easily seen. The test app is a udp server/client 
> > >>> pair where
> > >>> client passes some message n number of times.
> > >>> The test case was executed on baremetal and Xen DomU with kernel 
> > >>> version 2.6.39.
> > >>> Bare metal showed 2x times better result that DomU.
> > >>>
> > >>> Konrad came up with a workaround that was setting the flag for domain 
> > >>> scheduler in linux
> > >>> As the guest is not aware of SMT-related topology, it has a flat 
> > >>> topology initialized.
> > >>> Kernel has domain scheduler flags for scheduling domain CPU set to 4143 
> > >>> for 2.6.39.
> > >>> Konrad discovered that changing the flag for CPU sched domain to 4655
> > >>> works as a workaround and makes Linux think that the topology has SMT 
> > >>> threads.
> > >>> This workaround makes the test to complete almost in same time as on 
> > >>> baremetal (or insignificantly worse).
> > >>>
> > >>> This workaround is not suitable for kernels of higher versions as we 
> > >>> discovered.
> > >>>
> > >>> The hackish way of making domU linux think that it has SMT threads 
> > >>> (along with matching cpuid)
> > >>> made us thinks that the problem comes from the fact that cpu topology 
> > >>> is not exposed to
> > >>> guest and Linux scheduler cannot make intelligent decision on 
> > >>> scheduling.
> > >>>
> > >>> Joao Martins from Oracle developed set of patches that fixed the 
> > >>> smt/core/cashe
> > >>> topology numbering and provided matching pinning of vcpus and enabling 
> > >>> options,
> > >>> allows to expose to guest correct topology.
> > >>> I guess Joao will be posting it at some point.
> > >>>
> > >>> With this patches we decided to test the performance impact on 
> > >>> different kernel versionand Xen versions.
> > >>>
> > >>> The test described above was labeled as IO-bound test.
> > >>
> > >> So just to clarify: The client sends a request (presumably not much more
> > >> than a ping) to the server, and waits for the server to respond before
> > >> sending another one; and the server does the reverse -- receives a
> > >> request, responds, and then waits for the next request.  Is that right?
> > > 
> > > Yes.
> > >>
> > >> How much data is transferred?
> > > 
> > > 1 packet, UDP
> > >>
> > >> If the amount of data transferred is tiny, then the bottleneck for the
> > >> test is probably the IPI time, and I'd call this a "ping-pong"
> > >> benchmark[1].  I would only call this "io-bound" if you're actually
> > >> copying large amounts of data.
> > > 
> > > What we found is that on baremetal the scheduler would put both apps
> > > on the same CPU and schedule them right after each other. This would
> > > have a high IPI as the scheduler would poke itself.
> > > On Xen it would put the two applications on seperate CPUs - and there
> > > would be hardly any IPI.
> > 
> > Sorry -- why would the scheduler send itself an IPI if it's on the same
> > logical cpu (which seems pretty pointless), but *not* send an IPI to the
> > *other* processor when it was actually waking up another task?
> > 
> > Or do you mean high context switch rate?
> 
> Yes, very high.
> > 
> > > Digging deeper in the code I found out that if you do an UDP sendmsg
> > > without any timeouts - it would put it in a queue and just call schedule.
> > 
> > You mean, it would mark the other process as runnable somehow, but not
> > actually send an IPI to wake it up?  Is that a new "feature" designed
> 
> Correct - because the other process was not on its vCPU runqueue.
> 
> > for large systems, to reduce the IPI traffic or something?
> 
> This is just a normal Linux scheduler. The only way it would do an IPI
> to the other CPU was if the UDP message had an timeout. The default
> timeout is infite so it didn't bother to send an IPI.
> 
> > 
> > > On baremetal the schedule would result in scheduler picking up the other
> > > task, and starting it - which would dequeue immediately.
> > > 
> > > On Xen - the schedule() would go HLT.. and then later be woken up by the
> > > VIRQ_TIMER. And since the two applications were on seperate CPUs 

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

[Boris Ostrovsky]

On 01/27/2016 10:29 AM, Konrad Rzeszutek Wilk wrote:

On Wed, Jan 27, 2016 at 10:17:56AM -0500, Boris Ostrovsky wrote:

On 01/27/2016 10:09 AM, David Vrabel wrote:

On 27/01/16 15:06, Boris Ostrovsky wrote:

On 01/27/2016 09:50 AM, David Vrabel wrote:

On 27/01/16 14:42, Konrad Rzeszutek Wilk wrote:

On Tue, Jan 26, 2016 at 08:54:56PM -0800, Luis R. Rodriguez wrote:

On Jan 26, 2016 6:16 PM, "Luis R. Rodriguez"  wrote:

On Tue, Jan 26, 2016 at 4:04 PM, Luis R. Rodriguez 

wrote:

You go:

hvmlite_start_xen() -->
  HVM stub
  startup_64() | (startup_32()

Hrm, does HVMlite work well with load_ucode_bsp(), note the patches to
rebrand pv_enabled() to pv_legacy() or whatever, this PV type will not
be legacy or crap / old, so we'd need a way to catch it if we should
not use that code for this PV type. This begs the question, are you
also sure other callers in startup_32() or startup_64() might be OK as
well where previously guarded with pv_enabled() ?

Actually this call can't be used, and if early code used it prior to
setup_arch() it'd be a bug as its only properly set until later.
Vetting
for correctness of all code call is still required though and
perhaps we do
need something to catch now this PV type on early code such as this
one if
we don't want it. From what I've gathered before on other bsp ucode we
don't want ucode loaded for PV guest types through these mechanisms.

It may help to not think of PVH/hvmlite as PV. It really is HVM with
a lot
of emulated devices removed.

How does early microcode work on EFI? Does the EFI stub code have an
early
microcode loading code ?

Surely the interesting comparison here is how is (early) microcode
loading disabled in KVM guests?  We should use the same mechanism for



HVMlite guests.

Why would we ever want to have a guest load microcode during boot? I can
see how a (privileged) guest may want to load microcode from a shell
(via microcode driver).

I think you missed a word when you read my reply.

Yes, I missed it ;-)

Why not continue relying on paravirt_enabled()? We are going to keep this in
some form for HVMlite.

And this is where Luis comes in. He has posted an patchset which removes the
paravirt_enabled with .. Here is the link https://lkml.org/lkml/2015/12/15/772


Yes, I saw that and this will be renamed as paravirt_legacy() (which I 
am not sure is really what it should be called.)


Another option is to have early microcode code query CPUID to see 
whether we are running on a hypervisor (this in fact is what we 
originally thought of doing before realizing that we have 
paravirt_enabled()).


But then how is HVMlite different from a regular HVM guest trying to 
load microcode?


(BTW, to answer David's question about what KVM is doing --- it is 
ignoring writes to microcode MSRs, see kvm_set_msr_common().)


-boris



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

Re: [Xen-devel] [PATCH v4 07/21] arm/acpi: Print GIC information when MADT is parsed

[Stefano Stabellini]

On Sat, 23 Jan 2016, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> When MADT is parsed, print GIC information to make the boot log look
> pretty.
> 
> Signed-off-by: Hanjun Guo 
> Signed-off-by: Tomasz Nowicki 
> Signed-off-by: Shannon Zhao 

Reviewed-by: Stefano Stabellini 


> V4: use PRIx64 instead of %llx
> ---
>  xen/drivers/acpi/tables.c | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/xen/drivers/acpi/tables.c b/xen/drivers/acpi/tables.c
> index 4e590de..84a290f 100644
> --- a/xen/drivers/acpi/tables.c
> +++ b/xen/drivers/acpi/tables.c
> @@ -189,6 +189,28 @@ void __init acpi_table_print_madt_entry(struct 
> acpi_subtable_header *header)
>   }
>   break;
>  
> + case ACPI_MADT_TYPE_GENERIC_INTERRUPT:
> + {
> + struct acpi_madt_generic_interrupt *p =
> + (struct acpi_madt_generic_interrupt *)header;
> + printk(KERN_INFO PREFIX
> +"GICC (acpi_id[0x%04x] address[0x%"PRIx64"] 
> MPIDR[0x%"PRIx64"] %s)\n",
> +p->uid, p->base_address, p->arm_mpidr,
> +(p->flags & ACPI_MADT_ENABLED) ? "enabled" : 
> "disabled");
> +
> + }
> + break;
> +
> + case ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR:
> + {
> + struct acpi_madt_generic_distributor *p =
> + (struct acpi_madt_generic_distributor *)header;
> + printk(KERN_INFO PREFIX
> +"GIC Distributor (gic_id[0x%04x] 
> address[0x%"PRIx64"] gsi_base[%d])\n",
> +p->gic_id, p->base_address, p->global_irq_base);
> + }
> + break;
> +
>   default:
>   printk(KERN_WARNING PREFIX
>  "Found unsupported MADT entry (type = %#x)\n",
> -- 
> 2.0.4
> 
> 

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

Re: [Xen-devel] schedulers and topology exposing questions

[George Dunlap]

On 27/01/16 15:27, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 27, 2016 at 03:10:01PM +, George Dunlap wrote:
>> On 27/01/16 14:33, Konrad Rzeszutek Wilk wrote:
>>> On Xen - the schedule() would go HLT.. and then later be woken up by the
>>> VIRQ_TIMER. And since the two applications were on seperate CPUs - the
>>> single packet would just stick in the queue until the VIRQ_TIMER arrived.
>>
>> I'm not sure I understand the situation right, but it sounds a bit like
>> what you're seeing is just a quirk of the fact that Linux doesn't always
>> send IPIs to wake other processes up (either by design or by accident),
> 
> It does and it does not :-)
> 
>> but relies on scheduling timers to check for work to do.  Presumably
> 
> It .. I am not explaining it well. The Linux kernel scheduler when
> called for 'schedule' (from the UDP sendmsg) would either pick the next
> appliction and do a context swap - of if there were none - go to sleep.
> [Kind of - it also may do an IPI to the other CPU if requested ,but that 
> requires
> some hints from underlaying layers]
> Since there were only two apps on the runqueue - udp sender and udp receiver
> it would run them back-to back (this is on baremetal)

I think I understand at a high level from your description what's
happening (No IPIs -> happens to run if on the same cpu, waits until
next timer tick if on a different cpu); but what I don't quite get is
*why* Linux doesn't send an IPI.

It's been quite a while since I looked at the Linux scheduling code, so
I'm trying to understand it based a lot on the Xen code. In Xen a vcpu
can be "runnable" (has something to do) and "blocked" (waiting for
something to do). Whenever a vcpu goes from "blocked" to "runnable", the
scheduler will call vcpu_wake(), which sends an IPI to the appropriate
pcpu to get it to run the vcpu.

What you're describing is a situation where a process is blocked (either
in 'listen' or 'read'), and another process does something which should
cause it to become 'runnable' (sends it a UDP message). If anyone
happens to run the scheduler on its cpu, it will run; but no proactive
actions are taken to wake it up (i.e., sending an IPI).

The idea of not sending an IPI when a process goes from "waiting for
something to do" to "has something to do" seems strange to me; and if it
wasn't a mistake, then my only guess why they would choose to do that
would be to reduce IPI traffic on large systems.

But whether it's a mistake or on purpose, it's a Linux thing, so...

>> they knew that low performance on ping-pong workloads might be a
>> possibility when they wrote the code that way; I don't see a reason why
>> we should try to work around that in Xen.
> 
> Which is not what I am suggesting.

I'm glad we agree on this. :-)

> Our first ideas was that since this is a Linux kernel schduler characteristic
> - let us give the guest all the information it needs to do this. That is
> make it look as baremetal as possible - and that is where the vCPU
> pinning and the exposing of SMT information came about. That (Elena
> pls correct me if I am wrong) did indeed show that the guest was doing
> what we expected.
> 
> But naturally that requires pinning and all that - and while it is a useful
> case for those that have the vCPUs to spare and can do it - that is not
> a general use-case.
> 
> So Elena started looking at the CPU bound and seeing how Xen behaves then
> and if we can improve the floating situation as she saw some abnormal
> behavious.

OK -- if the focus was on the two cases where the Xen credit1 scheduler
(apparently) co-located two cpu-burning vcpus on sibling threads, then
yeah, that's behavior we should probably try to get to the bottom of.

 -George


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

Re: [Xen-devel] xenbits GitHub mirror?

[Ian Campbell]

On Wed, 2016-01-27 at 16:01 +, George Dunlap wrote:
> On 27/01/16 15:45, Ian Campbell wrote:
> > For most patch series setting up a GH account and pushing the changes to it
> > etc is pure overhead (or at least optional), there is no need to encourage
> > it for most series, nor even necessarily to encourage people to proactively
> > push to a repo, we can always ask if we find the series to hard to review
> > as patches.
> 
> It did take me a while to find a system that made it not a pain to apply
> patch series from xen-devel, and the solution I have now is very
> particular to the combination of e-mail tools that I happen to use; I'm
> not sure how transferrable they are.

I use the script below, which apart from needing a way to see the message
id of mails is independent of any mail tools. For git send-email generated
series I use it as:

~/get-msgid -g '2 5' '<
1447415999-22003-1-git-send-email-o...@aepfle.de>' | git am

(where 2 and 5 come come from the message id of the first and last patch
mails and it will apply the whole range, note that git send-email often has
patch #1 with msgid=2 due to the cover letter)

> So while I've managed to get things to a point where I don't have much
> pain, it's probably something that could use some work as a project in
> general.  "Encouraging most people to include public git branches" is
> one option to help that; "Having a mail bot that gave you git-am'able
> mbox files" is another.

Sure, but none of that is a blocker for what Doug is actually asking for
feedback on here, which really doesn't need to go off into the weeds
regarding some other future workflow which it may or may not enable, in
order to make a decision.

Ian.

#!/bin/bash

help()
{
echo "help!" 1>&2
}

GIT=
while getopts g: OPT ; do
case $OPT in
g)  GIT="$OPTARG" ;;
h)  help ; exit 1 ;;
\?) exit 1 ;;
esac
done
shift $(expr $OPTIND - 1)

fetch_messages()
{
for i in $@ ; do
echo "Fetching Message ID $i" 1>&2
if [ -n "$X" ] ; then
ssh celaeno cat /srv/mldrop/xen-devel/"\"$i\""
else
#wget -O - -q http://bugs.xenproject.org/xen/mid/"$i"/raw
i=${i/\+/%2B}
curl --silent http://bugs.xenproject.org/xen/mid/"$i"/raw
fi
done
}

if [ -z "$GIT" ] ; then
fetch_messages $@
else
#<1349427871-31195-4-git-send-email-anthony.per...@citrix.com>
for i in $@ ; do
PATTERN=$(echo "$i" | sed -e 
's/^\(<[0-9]*-[0-9]*-\)[0-9]*\(-.*>\)/\1@@NR@@\2/g')
echo "GIT pattern $PATTERN" 1>&2
for n in $(seq $GIT) ; do
MSG=$(echo "$PATTERN" | sed -e "s/@@NR@@/$n/")
fetch_messages $MSG
done
done
fi

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail in 
79090 pass in 79162
 test-armhf-armhf-xl-arndale   6 xen-boot   fail in 79090 pass in 79162
 test-armhf-armhf-xl-cubietruck 11 guest-start  fail in 79090 pass in 79162
 test-armhf-armhf-xl-credit2  11 guest-startfail in 79090 pass in 79162
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
in 79090 pass in 79162
 test-armhf-armhf-xl-xsm  11 guest-start fail pass in 79008
 test-armhf-armhf-xl  15 guest-start/debian.repeat   fail pass in 79090
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-boot  fail pass in 79090

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rumpuserxen-i386 10 guest-start   fail in 79090 like 66399
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail in 79090 like 66399
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66399
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   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-xsm  13 saverestore-support-check fail in 79008 never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-check fail in 79008 never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-check fail in 79008 never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-check fail in 79008 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-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 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-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-libvirt-vhd 11 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-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
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-libvirt-raw  9 debian-di-installfail   never pass

version targeted for testing:
 linux99c5a856dcee7658ec7e250aa477a9afaab8cfc6
baseline version:
 linux

Re: [Xen-devel] blk_update_request: I/O error on NFS (was: [Xen-users] xen domU disk on nfs shared file)

[Konrad Rzeszutek Wilk]

On Tue, Jan 12, 2016 at 12:05:48PM +, Wei Liu wrote:
> Drop xen-users@, CC xen-devel@ and blk maintainers, change title.
> 

What is the MTU you are using?

How do you mount the disk?

> On Mon, Jan 11, 2016 at 03:08:24PM +0100, Kojedzinszky Richárd wrote:
> > Dear all,
> > 
> > We are facing a regular lockup with our xen setup. We have an nfs share
> > mounted on the xen dom0, where the vm images are served, and those files are
> > given to xen domUs.
> > 
> > I was just preparing an experiment, where I created a 100G file on the host:
> > # truncate -s 100G /srv/nfs/domU/disk2
> > And after added this disk to the instance's configuration.
> > 
> > On the host this is the mountpoint:
> > # mount|grep srv/xen
> > 10.1.1.1:/mnt/main/vps on /srv/xen type nfs 
> > (rw,relatime,vers=3,rsize=16384,wsize=16384,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.1.1.1,mountvers=3,mountport=4045,mountproto=udp,local_lock=none,addr=10.1.1.1)
> > 
> > After starting the instance I partitioned the disk with gdisk, and created
> > an xfs fs on it. While the fs has been created well, strange messages
> > appeared on the console:
> > 
> > [   23.787504] blk_update_request: I/O error, dev xvdc, sector 2048
> > [   23.788904] blk_update_request: I/O error, dev xvdc, sector 8390655
> > [   23.789611] blk_update_request: I/O error, dev xvdc, sector 16779262
> > [   23.790359] blk_update_request: I/O error, dev xvdc, sector 25167869
> > [   23.791148] blk_update_request: I/O error, dev xvdc, sector 33556476
> > [   23.791498] blk_update_request: I/O error, dev xvdc, sector 41945083
> > [   23.791498] blk_update_request: I/O error, dev xvdc, sector 50333690
> > [   23.791498] blk_update_request: I/O error, dev xvdc, sector 58722297
> > [   23.791498] blk_update_request: I/O error, dev xvdc, sector 67110904
> > [   23.791498] blk_update_request: I/O error, dev xvdc, sector 75499511
> > 
> > I dont think that this is normal. If I chose a local block device (probably
> > lvm) for the domU, this does not appear.
> > 
> > The host is running xen-4.4 with 3.16.0-4-amd64 kernel (debian jessie
> > stock), the domU is running 4.3.0-0.bpo.1-amd64 (jessie backport, 4.4.4).
> > 
> > I suspect those messages should not be there.
> > 
> > Regards,
> > 
> > Kojedzinszky Richárd
> > Euronet Magyarorszag Informatika Zrt.
> 
> > ___
> > Xen-users mailing list
> > xen-us...@lists.xen.org
> > http://lists.xen.org/xen-users
> 

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

[Xen-devel] [PATCH] xenstore: add stddef.h to xenstore_lib.h

[Ian Campbell]

xs_perm_to_string takes a size_t which isn't defined by anything
pulled in directly by this header.

Given the other headers xenstore_lib.h pulls in this looks to be an
oversight rather than a deliberate policy.

Signed-off-by: Ian Campbell 
---
 tools/xenstore/include/xenstore_lib.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/xenstore/include/xenstore_lib.h 
b/tools/xenstore/include/xenstore_lib.h
index 5a10c6c..462b7b9 100644
--- a/tools/xenstore/include/xenstore_lib.h
+++ b/tools/xenstore/include/xenstore_lib.h
@@ -19,6 +19,7 @@
 #ifndef XENSTORE_LIB_H
 #define XENSTORE_LIB_H
 
+#include 
 #include 
 #include 
 #include 
-- 
2.1.4


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 78683

Tests which did not succeed, but are not blocking:
 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-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-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 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-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-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-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 11 guest-start  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-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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-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-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 qemuu39c36a0573d9307d68c0c3336b48e6351ffabc06
baseline version:
 qemuu1cf81ea2e2ecfd2ec046e2b409e75e87808ac4d0

Last test of basis78683  2016-01-21 12:32:58 Z6 days
Failing since 78788  2016-01-22 04:47:28 Z5 days5 attempts
Testing same since79130  2016-01-26 23:47:52 Z0 days1 attempts


People who touched revisions under test:
  Alistair Francis 
  Andrew Jones 
  Aurelien Jarno 
  Cao jin 
  Christian Borntraeger 
  Christoffer Dall 
  Cornelia Huck 
  Daniel P. Berrange 
  Denis V. Lunev 
  Dongxue Zhang 
  Dr. David Alan Gilbert 
  Edgar E. Iglesias 
  Eduardo Habkost 
  Eric Blake 
  Fam Zheng 
  Gerd Hoffmann 
  Greg Kurz 
  Haozhong Zhang 
  Huaitong Han 
  Ian Campbell 
  James Hogan 
  Janosch Frank 
  John Snow 
  Kevin Wolf 
  Laszlo Ersek 
  Leon Alrae 
  Luiz Capitulino 
  Markus Armbruster 
  Miodrag Dinic 
  Paolo Bonzini 
  Peter Crosthwaite 
  Peter Crosthwaite 
  Peter Crosthwaite 
  Peter Maydell 
  Shmulik Ladkani 

[Xen-devel] [PATCH 4.3 004/157] x86/paravirt: Prevent rtc_cmos platform device init on PV guests

[Greg Kroah-Hartman]

4.3-stable review patch.  If anyone has any objections, please let me know.

--

From: David Vrabel 

commit d8c98a1d1488747625ad6044d423406e17e99b7a upstream.

Adding the rtc platform device in non-privileged Xen PV guests causes
an IRQ conflict because these guests do not have legacy PIC and may
allocate irqs in the legacy range.

In a single VCPU Xen PV guest we should have:

/proc/interrupts:
   CPU0
  0:   4934  xen-percpu-virq  timer0
  1:  0  xen-percpu-ipi   spinlock0
  2:  0  xen-percpu-ipi   resched0
  3:  0  xen-percpu-ipi   callfunc0
  4:  0  xen-percpu-virq  debug0
  5:  0  xen-percpu-ipi   callfuncsingle0
  6:  0  xen-percpu-ipi   irqwork0
  7:321   xen-dyn-event xenbus
  8: 90   xen-dyn-event hvc_console
  ...

But hvc_console cannot get its interrupt because it is already in use
by rtc0 and the console does not work.

  genirq: Flags mismatch irq 8.  (hvc_console) vs.  (rtc0)

We can avoid this problem by realizing that unprivileged PV guests (both
Xen and lguests) are not supposed to have rtc_cmos device and so
adding it is not necessary.

Privileged guests (i.e. Xen's dom0) do use it but they should not have
irq conflicts since they allocate irqs above legacy range (above
gsi_top, in fact).

Instead of explicitly testing whether the guest is privileged we can
extend pv_info structure to include information about guest's RTC
support.

Reported-and-tested-by: Sander Eikelenboom 
Signed-off-by: David Vrabel 
Signed-off-by: Boris Ostrovsky 
Cc: vkuzn...@redhat.com
Cc: xen-de...@lists.xenproject.org
Cc: konrad.w...@oracle.com
Link: 
http://lkml.kernel.org/r/1449842873-2613-1-git-send-email-boris.ostrov...@oracle.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/paravirt.h   |6 ++
 arch/x86/include/asm/paravirt_types.h |5 +
 arch/x86/include/asm/processor.h  |1 +
 arch/x86/kernel/rtc.c |3 +++
 arch/x86/lguest/boot.c|1 +
 arch/x86/xen/enlighten.c  |4 +++-
 6 files changed, 19 insertions(+), 1 deletion(-)

--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -19,6 +19,12 @@ static inline int paravirt_enabled(void)
return pv_info.paravirt_enabled;
 }
 
+static inline int paravirt_has_feature(unsigned int feature)
+{
+   WARN_ON_ONCE(!pv_info.paravirt_enabled);
+   return (pv_info.features & feature);
+}
+
 static inline void load_sp0(struct tss_struct *tss,
 struct thread_struct *thread)
 {
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -70,9 +70,14 @@ struct pv_info {
 #endif
 
int paravirt_enabled;
+   unsigned int features;/* valid only if paravirt_enabled is set */
const char *name;
 };
 
+#define paravirt_has(x) paravirt_has_feature(PV_SUPPORTED_##x)
+/* Supported features */
+#define PV_SUPPORTED_RTC(1<<0)
+
 struct pv_init_ops {
/*
 * Patch may replace one of the defined code sequences with
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -472,6 +472,7 @@ static inline unsigned long current_top_
 #else
 #define __cpuidnative_cpuid
 #define paravirt_enabled() 0
+#define paravirt_has(x)0
 
 static inline void load_sp0(struct tss_struct *tss,
struct thread_struct *thread)
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -200,6 +200,9 @@ static __init int add_rtc_cmos(void)
}
 #endif
 
+   if (paravirt_enabled() && !paravirt_has(RTC))
+   return -ENODEV;
+
platform_device_register(_device);
dev_info(_device.dev,
 "registered platform RTC device (no PNP device found)\n");
--- a/arch/x86/lguest/boot.c
+++ b/arch/x86/lguest/boot.c
@@ -1414,6 +1414,7 @@ __init void lguest_init(void)
pv_info.kernel_rpl = 1;
/* Everyone except Xen runs with this set. */
pv_info.shared_kernel_pmd = 1;
+   pv_info.features = 0;
 
/*
 * We set up all the lguest overrides for sensitive operations.  These
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1191,7 +1191,7 @@ static const struct pv_info xen_info __i
 #ifdef CONFIG_X86_64
.extra_user_64bit_cs = FLAT_USER_CS64,
 #endif
-
+   .features = 0,
.name = "Xen",
 };
 
@@ -1534,6 +1534,8 @@ asmlinkage __visible void __init xen_sta
 
/* Install Xen paravirt ops */
pv_info = xen_info;
+   if (xen_initial_domain())
+   pv_info.features |= PV_SUPPORTED_RTC;
pv_init_ops = xen_init_ops;
pv_apic_ops = xen_apic_ops;
  

Re: [Xen-devel] [PATCH RESEND] fix MSI injection on Xen

[Konrad Rzeszutek Wilk]

On Wed, Jan 13, 2016 at 02:59:09PM +, Stefano Stabellini wrote:
> On Xen MSIs can be remapped into pirqs, which are a type of event
> channels. It's mostly for the benefit of PCI passthrough devices, to
> avoid the overhead of interacting with the emulated lapic.
> 
> However remapping interrupts and MSIs is also supported for emulated
> devices, such as the e1000 and virtio-net.
> 
> When an interrupt or an MSI is remapped into a pirq, masking and
> unmasking is done by masking and unmasking the event channel. The
> masking bit on the PCI config space or MSI-X table should be ignored,
> but it isn't at the moment.
> 
> As a consequence emulated devices which use MSI or MSI-X, such as
> virtio-net, don't work properly (the guest doesn't receive any
> notifications). The mechanism was working properly when xen_apic was

By xen_apic I presume the Linux Xen APIC code?

> introduced, but I haven't narrowed down which commit in particular is
> causing the regression.

It sounds like the issue was due to the Xen APIC code? Or am I misreading it?

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

[Xen-devel] [PATCH 1/2] x86/vmx: Don't clobber exception_bitmap when entering/leaving emulated real mode

[Andrew Cooper]

Most updates to the exception bitmaps set or clear an individual bits.

However, entering or exiting emulated real mode unilaterally clobbers it,
leaving the exit code to recalculate what it should have been.  This is error
prone, and indeed currently fails to recalculate the TRAP_no_device intercept
appropriately.

Instead of overwriting exception_bitmap when entering emulated real mode, move
the override into vmx_update_exception_bitmap() and leave exception_bitmap
unmodified.

This means that recalculation is unnecessary, and that the use of
vmx_fpu_leave() and vmx_update_debug_state() while in emulated real mode
doesn't result in TRAP_no_device and TRAP_int3 being un-intercepted.

This is only a functional change on hardware lacking unrestricted guest
support.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Jun Nakajima 
CC: Kevin Tian 
---
 xen/arch/x86/hvm/vmx/vmx.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 04dde83..4f9951f 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -389,10 +389,13 @@ void vmx_update_secondary_exec_control(struct vcpu *v)
 
 void vmx_update_exception_bitmap(struct vcpu *v)
 {
+u32 bitmap = unlikely(v->arch.hvm_vmx.vmx_realmode)
+? 0xu : v->arch.hvm_vmx.exception_bitmap;
+
 if ( nestedhvm_vcpu_in_guestmode(v) )
-nvmx_update_exception_bitmap(v, v->arch.hvm_vmx.exception_bitmap);
+nvmx_update_exception_bitmap(v, bitmap);
 else
-__vmwrite(EXCEPTION_BITMAP, v->arch.hvm_vmx.exception_bitmap);
+__vmwrite(EXCEPTION_BITMAP, bitmap);
 }
 
 static int vmx_guest_x86_mode(struct vcpu *v)
@@ -1306,8 +1309,6 @@ static void vmx_update_guest_cr(struct vcpu *v, unsigned 
int cr)
 {
 for ( s = x86_seg_cs ; s <= x86_seg_tr ; s++ )
 vmx_set_segment_register(v, s, [s]);
-v->arch.hvm_vmx.exception_bitmap = 0x;
-vmx_update_exception_bitmap(v);
 }
 else 
 {
@@ -1315,13 +1316,9 @@ static void vmx_update_guest_cr(struct vcpu *v, unsigned 
int cr)
 if ( !(v->arch.hvm_vmx.vm86_segment_mask & (1<arch.hvm_vmx.vm86_saved_seg[s]);
-v->arch.hvm_vmx.exception_bitmap = HVM_TRAP_MASK
-  | (paging_mode_hap(v->domain) ?
- 0 : (1U << TRAP_page_fault))
-  | (1U << TRAP_no_device);
-vmx_update_exception_bitmap(v);
-vmx_update_debug_state(v);
 }
+
+vmx_update_exception_bitmap(v);
 }
 
 v->arch.hvm_vcpu.hw_cr[0] =
-- 
2.1.4


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

[Xen-devel] qemu-upstream compile failure in intel_iommu.c:vtd_context_device_invalidate

[Olaf Hering]

Compiling qemu-xen at 2ce1d30 ("xenfb.c: avoid expensive loops when prod
<= out_cons") leads to this error with -O1:

xen.git/tools/qemu-xen-dir/hw/i386/intel_iommu.c: In function 
‘vtd_context_device_invalidate’:
xen.git/tools/qemu-xen-dir/hw/i386/intel_iommu.c:911:46: error: ‘mask’ may be 
used uninitialized in this function [-Werror=maybe-uninitialized]
 if (vtd_as && ((devfn_it & mask) == (devfn & mask))) {
  ^
It works with -O2. From the code flow its clear that mask is always
initialized. Looks like gcc 5.2.1 does no proper diagnostic at -O1.
What should be done with such issues, are they fixed in the code?

Olaf

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 3 host-install(3) broken REGR. vs. 
38682
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 38682
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 38682
 test-armhf-armhf-xl-vhd   9 debian-di-install fail REGR. vs. 38682

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-credit2  19 guest-start/debian.repeatfail   like 38682
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 38682

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-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-amd64-amd64-xl-pvh-amd  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-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  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-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 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-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-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 xen  2e46e3f2539d026594ec1618e7df2c2bc8785b42
baseline version:
 xen  1949868d640427dc91bfb23741d78eb1d86841c8

Last test of basis38682  2016-01-21 17:27:15 Z6 days
Testing same since38708  2016-01-27 10:21:09 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  David Scott 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jonathan Creekmore 
  Malcolm Crossley 
  Roger Pau Monné 
  Tim Deegan 
  Wei Liu 
  Wen Congyang 

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

Re: [Xen-devel] [PATCH v13 1/8] tools: Add vga=vmware

[Konrad Rzeszutek Wilk]

On Sat, Nov 28, 2015 at 04:44:58PM -0500, Don Slutz wrote:
> From: Don Slutz 
> 
> This allows use of QEMU's VMware emulated video card
> 
> NOTE: vga=vmware is not supported by device_model_version=qemu-xen-traditional
> 
> Signed-off-by: Don Slutz 
> CC: Don Slutz 
> Acked-by: Ian Campbell 

Reviewed-by: Konrad Rzeszutek Wilk 
> ---
> v13:
>   Added Acked-by: Ian Campbell
> 
> v12:
>   Dropped LIBXL_HAVE_LIBXL_VGA_INTERFACE_TYPE_VMWARE
>   This means that the later patch that defines LIBXL_HAVE_VMWARE
>   is now also required.
> 
> v11:
>   Dropped support for Qemu-trad.
>   Also changed later patchs to not need this one.
> 
> v10: New at v10.
> 
>   Was part of "tools: Add vmware_hwver support"
> 
> 
>  docs/man/xl.cfg.pod.5   | 4 +++-
>  tools/libxl/libxl_dm.c  | 9 +
>  tools/libxl/libxl_types.idl | 1 +
>  tools/libxl/xl_cmdimpl.c| 2 ++
>  4 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index 3b695bd..9a5744d 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -1547,7 +1547,7 @@ This option is deprecated, use vga="stdvga" instead.
>  
>  =item 

[Xen-devel] [PATCH 2/2] x86/hvm: Don't intercept #UD exceptions in general

[Andrew Cooper]

c/s 0f1cb96e "x86 hvm: Allow cross-vendor migration" caused HVM domains to
unconditionally intercept #UD exceptions.  While cross-vendor migration is
cool as a demo, it is extremely niche.

Intercepting #UD allows userspace code in a multi-vcpu guest to execute
arbitrary instructions in the x86 emulator by having one thread execute a ud2a
instruction, and having a second thread rewrite the instruction before the
emulator performs an instruction fetch.

XSAs 105, 106 and 110 are all examples where guest userspace can use bugs in
the x86 emulator to compromise security of the domain, either by privilege
escalation or causing a crash.

c/s 2d67a7a4 "x86: synchronize PCI config space access decoding"
introduced (amongst other things) a per-domain vendor, based on the guests
cpuid policy.

Use the per-guest vendor to enable #UD interception only when a domain is
configured for a vendor different to the current hardware.  (#UD interception
is also enabled if hvm_fep is specified on the Xen command line.  This is a
debug-only option whose entire purpose is for testing the x86 emulator.)

As a result, the overwhelming majority of usecases now have #UD interception
disabled, removing an attack surface for malicious guest userspace.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Jun Nakajima 
CC: Kevin Tian 
CC: Boris Ostrovsky 
CC: Suravee Suthikulpanit 
CC: Aravind Gopalakrishnan 
---
 xen/arch/x86/domctl.c | 18 ++
 xen/arch/x86/hvm/hvm.c|  6 ++
 xen/arch/x86/hvm/svm/svm.c| 13 +
 xen/arch/x86/hvm/svm/vmcb.c   |  1 +
 xen/arch/x86/hvm/vmx/vmcs.c   |  1 +
 xen/arch/x86/hvm/vmx/vmx.c| 15 +++
 xen/include/asm-x86/hvm/hvm.h | 15 ++-
 7 files changed, 64 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 1d71216..1084e82 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -65,8 +65,20 @@ static void update_domain_cpuid_info(struct domain *d,
 .ecx = ctl->ecx
 }
 };
+int old_vendor = d->arch.x86_vendor;
 
 d->arch.x86_vendor = get_cpu_vendor(vendor_id.str, gcv_guest);
+
+if ( is_hvm_domain(d) && (d->arch.x86_vendor != old_vendor) )
+{
+struct vcpu *v;
+
+domain_pause(d);
+for_each_vcpu( d, v )
+hvm_update_guest_vendor(v);
+domain_unpause(d);
+}
+
 break;
 }
 
@@ -707,6 +719,12 @@ long arch_do_domctl(
 xen_domctl_cpuid_t *ctl = >u.cpuid;
 cpuid_input_t *cpuid, *unused = NULL;
 
+if ( d == currd ) /* no domain_pause() */
+{
+ret = -EINVAL;
+break;
+}
+
 for ( i = 0; i < MAX_CPUID_INPUT; i++ )
 {
 cpuid = >arch.cpuids[i];
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 674feea..7a15d49 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -93,12 +93,10 @@ unsigned long __section(".bss.page_aligned")
 static bool_t __initdata opt_hap_enabled = 1;
 boolean_param("hap", opt_hap_enabled);
 
-#ifndef NDEBUG
+#ifndef opt_hvm_fep
 /* Permit use of the Forced Emulation Prefix in HVM guests */
-static bool_t opt_hvm_fep;
+bool_t opt_hvm_fep;
 boolean_param("hvm_fep", opt_hvm_fep);
-#else
-#define opt_hvm_fep 0
 #endif
 
 /* Xen command-line option to enable altp2m */
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 953e0b5..44a1250 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -597,6 +597,18 @@ static void svm_update_guest_efer(struct vcpu *v)
 vmcb_set_efer(vmcb, new_efer);
 }
 
+static void svm_update_guest_vendor(struct vcpu *v)
+{
+struct arch_svm_struct *arch_svm = >arch.hvm_svm;
+struct vmcb_struct *vmcb = arch_svm->vmcb;
+
+if ( opt_hvm_fep ||
+ (v->domain->arch.x86_vendor != boot_cpu_data.x86_vendor) )
+vmcb->_exception_intercepts |= (1U << TRAP_invalid_op);
+else
+vmcb->_exception_intercepts &= ~(1U << TRAP_invalid_op);
+}
+
 static void svm_sync_vmcb(struct vcpu *v)
 {
 struct arch_svm_struct *arch_svm = >arch.hvm_svm;
@@ -2245,6 +2257,7 @@ static struct hvm_function_table __initdata 
svm_function_table = {
 .get_shadow_gs_base   = svm_get_shadow_gs_base,
 .update_guest_cr  = svm_update_guest_cr,
 .update_guest_efer= svm_update_guest_efer,
+.update_guest_vendor  = svm_update_guest_vendor,
 .set_guest_pat= svm_set_guest_pat,
 .get_guest_pat= svm_get_guest_pat,
 .set_tsc_offset   = svm_set_tsc_offset,
diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index 9ea014f..be2dc32 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ 

Re: [Xen-devel] [RFC] support more qdisk types

[Konrad Rzeszutek Wilk]

On Mon, Jan 25, 2016 at 05:25:02PM -0700, Jim Fehlig wrote:
> I would like to hear the community's opinion on supporting more qdisk types in
> xl/libxl, e.g. nbd, rbd, iSCSI, etc. I prefer supporting additional qdisk 
> types
> in libxl over apps like xl or libvirt doing all the setup, producing a block
> device, and then passing that to libxl. Each libxl app would have to
> re-implement functionality already provided by qdisk. libxl already supports
> IDE, AHCI, SCSI, and Xen PV qdisks. My suggestion is to extend that to 
> initially
> include nbd, rbd, and iSCSI. Sheepdog, ssh, etc. could be added in the future.

ssh?
> 
> I considered several approaches to supporting additional qdisk types, based
> primarily on changes to the disk cfg and interface. At one extreme is to 
> change
> nothing and use the existing 'target=' to encode all required config for the
> additional qdisk types. libxl would need to be taught how to turn the blob 
> into
> an appropriate qdisk. At the other extreme is extending xl-disk-configuration

Either way - new backends would require changes in both libxl and libvirt right?
The libxl would need to understand the new 'target=' blob to parse it out?



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

Re: [Xen-devel] [PATCH 2/2] x86/hvm: Don't intercept #UD exceptions in general

[Boris Ostrovsky]

On 01/27/2016 01:59 PM, Andrew Cooper wrote:

On 27/01/16 18:49, Boris Ostrovsky wrote:

On 01/27/2016 01:11 PM, Andrew Cooper wrote:

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 1d71216..1084e82 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -65,8 +65,20 @@ static void update_domain_cpuid_info(struct domain
*d,
   .ecx = ctl->ecx
   }
   };
+int old_vendor = d->arch.x86_vendor;
 d->arch.x86_vendor = get_cpu_vendor(vendor_id.str,
gcv_guest);
+
+if ( is_hvm_domain(d) && (d->arch.x86_vendor != old_vendor) )
+{
+struct vcpu *v;
+
+domain_pause(d);
+for_each_vcpu( d, v )
+hvm_update_guest_vendor(v);
+domain_unpause(d);
+}
+
   break;
   }

Not specific to this patch, but shouldn't we pause/unpause domain for
the whole routine?

Not specifically, although that might be better lonterm.

In practice, this hypercall is only made as part of domain construction,
and never at domain runtime.


Is it safe to unpause a domain here if it is not running?

-boris

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

Re: [Xen-devel] [BUG] pci-passthrough generates "xen:events: Failed to obtain physical IRQ" for some devices

[Konrad Rzeszutek Wilk]

On Sat, Jan 23, 2016 at 05:12:04PM +0100, Tommi Airikka wrote:
> Xen developers,
> 
> After an upgrade of my Debian Jessie dom0 and domUs, my passthroughed
> NIC stopped working.
> This bug was probably introduced in Debian Jessie sometime
> between 2015-12-30 and 2016-01-08 as 2015-12-30 as 2015-12-30 was the
> last time I upgraded without any problems according to my dpkg.log.

This upgrade looks to only have upgraded the hypervisor?

As in I see:

domU "bug" "uname -a":
Linux bug 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2 (2016-01-02)
x86_64 GNU/Linux

domU "working" "uname -a":
Linux working 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2
(2016-01-02) x86_64 GNU/Linux

So same version? What was the earlier version of the hypervisor?

The Xen version you have says:
> (XEN) I/O virtualisation disabled

Which is not very healthy for PCI passthrough. Albeit you can do
it with PV without IOMMU. Did the previous version of Xen have the same
message?

Looking at the code (in Linux) I see:
 516 /* NB. We are happy to share unless we are probing. */
 517 bind_pirq.flags = info->u.pirq.flags & PIRQ_SHAREABLE ?
 518 BIND_PIRQ__WILL_SHARE : 0;
 519 rc = HYPERVISOR_event_channel_op(EVTCHNOP_bind_pirq, _pirq);
 520 if (rc != 0) {
 521 pr_warn("Failed to obtain physical IRQ %d\n", irq);
 522 return 0;
 523 }

It would be nice if I we had included the return code :-(

Anyhow for PV guests in the hypervisor there is a check:
 414 if ( !is_hvm_domain(d) && !pirq_access_permitted(d, pirq) )
 415 return -EPERM;
 416 

And I wonder if the XEN_DOMCTL_irq_permission aka, xc_domain_irq_permission
had been called. I remember that at some point we missed it for Xend..

Could you enable Xend debugging (if you are using that):

export XEND_DEBUG=1
/etc/init.d/xend start

And try starting the guest. Then grep in /var/log/xen/xend.log for
"pci: enabling irq "

You should see 18, 17 and 21.

Also if you do 'xl debug-keys i && xl dmesg'

You should see that the IRQ 17, 18, 21 are assigned to the domain.
?

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

Re: [Xen-devel] Developers for virgl 3d windows guest support

[Konrad Rzeszutek Wilk]

On Tue, Jan 26, 2016 at 05:48:34PM +0100, Fabio Fantoni wrote:
> I take a fast look to virgl 3d project even if I not tested it for now. It
> seems interesting for adding 2d and 3d hw acceleration support to virtual
> machines with a large hw (gpu) choice.
> I take a look also to intel gvt-g but it has a very limited cpu support
> choice.
> I saw that windows guest support with direct3d drivers in virgl is planned
> but I nothing was done for now.
> I'm approaching a new project (based on xen) and I'm in planning phase now.
> My goal would be to have virgl 3d windows guest support (drivers with opengl
> and direct3d) and support of remote rendering with spice (we are already
> using with qxl for now)

Did you look at the VirtIO drivers and their roadmap?


> Are there any developers expert about these things that can advice me if
> developing windows drivers (WDDM kernel driver + GL and D3D userspace
> pieces) and any other needed pieces of code in virglrender, mesa, and /or
> qemu is a good choice?

I have no clue about Windows. But when I started working on Linux it took
me good three months to get comfortable. I would presume the same thing
is for Windows. Albeit you would need also to have understanding of
OpenGL.

> If yes, what we would like to know is approx time/effort to have the above
> support upstream. Approximately how many persons and how many time would
> require to complete the tasks? (my project is going to be financed so we
> eventually have resource to schedule working time in the community)

Um, .. Are you saying you need the person/month values so that you can
get the money? Or that you have the money and just need to figure out
if it can be done with the amount you have?

> 
> Thanks for any reply and sorry for my bad english.
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

[Luis R. Rodriguez]

Bleh moving forward please use mcg...@kernel.org, that will be sent to
my employer and my personal address. More below.

On Wed, Jan 27, 2016 at 8:15 AM, Boris Ostrovsky
 wrote:
> On 01/27/2016 10:29 AM, Konrad Rzeszutek Wilk wrote:
>> On Wed, Jan 27, 2016 at 10:17:56AM -0500, Boris Ostrovsky wrote:
>>> On 01/27/2016 10:09 AM, David Vrabel wrote:
 On 27/01/16 15:06, Boris Ostrovsky wrote:
>>> Why not continue relying on paravirt_enabled()? We are going to keep this
>>> in
>>> some form for HVMlite.
>>
>> And this is where Luis comes in. He has posted an patchset which removes
>> the
>> paravirt_enabled with .. Here is the link
>> https://lkml.org/lkml/2015/12/15/772
>
>
> Yes, I saw that and this will be renamed as paravirt_legacy() (which I am
> not sure is really what it should be called.)

Given Konrad's pointers about some folks pushing for BIOS to have a
"legacy free option" where all legacy crap (PS/2, PnP, serial port,
parallel port) are all disabled [0], I'm inclined to respin the rename
patch to use x86_legacy_free(). This can later then be extended
provided such BIOS check becomes available.

[0] http://lkml.kernel.org/r/20160120193241.ga4...@char.us.oracle.com

But -- as I also pointed out to hpa recently, there is an issue with
using things like cpu_has_hypervisor() (or in this case
paravirt_enabled()) for early code, given that it relies on
init_hypervisor_platform() having been called first which is called on
setup_arch() [1]. So paravirt_enabled() really can only be used prior
to setup_arch() correctly (specifically after,
init_hypervisor_platform()), and anything else would be a bug. I
learned the hard way while doing some linker table work and trying to
find a good use / solution to the dead code concerns I've been aiming
to address due to Xen's separate entry point and the nature of pvops
[2] [3]. hpa's response to this issue was that we cannot and should
not abuse the boot_params hardware_subarch for this purpose (in this
case I was suggesting perhaps KVM could use it if it in the future
needed it for a kvm check earlier than setup_arch()), but he noted
that:

  "If you have a genuine need for a "hypervisor type" then that is a
separate thing and should be
   treated separately from subarch.  However, you need to consider
that some hypervisors can
  emulate other hypervisors and you may have more than one hypervisor
API available."

This goes along with my suggestion here earlier where I mentioned that
subarch is already used nicely to pivot off some specific subarch
entry after startup_32(), if we want to avoid yet-another-entry for
HVMlite (the PVH rebrand done cleanly) and still use startup_32() for
it we could perhaps follow similar strategy as with subarch but
instead add a hypervisor type and use that for a stub call the
hypervisor type if needed early on in startup_32(). This could perhaps
in turn also be used as a generic hypervisor type / and more robust /
easier / not-so-convoluted check. For instance of what I think is a
convoluted check refer to snd_intel8x0_inside_vm() in
sound/pci/intel8x0.c with its use of kvm_para_available(), #ifdefery
over boot_cpu_has(X86_FEATURE_HYPERVISOR) (which is just
cpu_has_hypervisor()). If we had a hypervisor type easily accessible
it could both be used by early init code and perhaps driver code to
replace these convoluted checks.

If this seems a bit sensible the next question to ask if -- how we'd
*set* the hypervisor type, do we extend the x86 boot protocol and
enable a hypervisor type on the zero page? That would clearly only
make sense if:

1) Its reasonable to x86 maintainers (perhaps pending this
discussion's outcome? If its preemptively known to not reasonable an
alternative suggestion would be appreciated)
2) Xen is willing to actually set this (and perhaps a new
hypervisor_type_data for the private data structure), but not much
more would be needed, and incorporate this as part of the DmLite
protocol, or whatever its called as an option for some OSes
3) The kernel could get access to this value from the zero page really
early on, immediately following startup_32()

Worth mentioning here also is hpa's clarification on when subarch type
PC (0) should be used: [it should be used if the hardware is]
"enumerable using standard PC mechanisms (PCI, ACPI) and doesn't need
a special boot flow" -- does that fit HVMLite's description so far? If
so then The Xen subarch may need to be redefined as well to be clear
what it means. I don't think we need to be precise but at the very
least cover grounds to enable the definitions to meet its actual use
to not confuse users.

[1] 
http://lkml.kernel.org/r/CAB=ne6woksp8+kgnjetigwyktcmjg6ihercocq-jskxi4p2...@mail.gmail.com
[2] 
http://www.do-not-panic.com/2015/12/avoiding-dead-code-pvops-not-silver-bullet.html
[3] http://www.do-not-panic.com/2015/12/xen-and-x86-linux-zero-page.html
[4] http://lkml.kernel.org/r/56a17b01.9040...@zytor.com

> Another option is to have early 

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

[Luis R. Rodriguez]

On Wed, Jan 27, 2016 at 10:48 AM, Luis R. Rodriguez  wrote:
>
> Worth mentioning here also is hpa's clarification on when subarch type
> PC (0) should be used: [it should be used if the hardware is]
> "enumerable using standard PC mechanisms (PCI, ACPI) and doesn't need
> a special boot flow" -- does that fit HVMLite's description so far? If
> so then The Xen subarch may need to be redefined as well to be clear
> what it means. I don't think we need to be precise but at the very
> least cover grounds to enable the definitions to meet its actual use
> to not confuse users.

Another thing to consider for HVMlite is that if the 0 subarch (PC) is
used in light of my linker table work and x86's use of it with the
subarch and supported subarch bitmask, is that it would also mean
HVMLite would run all routines currently pegged as needing PC type
(the current KVM and bare metal path) and it would mean not running
anything only pegged with Xen subarch type (but note that today Xen
doesn't even set the subarch type). If there is nothing in common
between PV and HVMlite (no x86 init calls to share), and if HVMLite
*can* call *al* PC init calls, then by all means this is fine,
and if we just need to distinguish stuff between PC types that's fine,
it may still be possible to further extend hypervisor_type to the x86
init calls I'm adding as another supported_hyper_types to ensure even
though a subarch is being used, that we also check the supported
hypervisor type as well.

 Luis

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

Re: [Xen-devel] [PATCH 2/2] x86/hvm: Don't intercept #UD exceptions in general

[Andrew Cooper]

On 27/01/16 19:14, Boris Ostrovsky wrote:
> On 01/27/2016 01:59 PM, Andrew Cooper wrote:
>> On 27/01/16 18:49, Boris Ostrovsky wrote:
>>> On 01/27/2016 01:11 PM, Andrew Cooper wrote:
 diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
 index 1d71216..1084e82 100644
 --- a/xen/arch/x86/domctl.c
 +++ b/xen/arch/x86/domctl.c
 @@ -65,8 +65,20 @@ static void update_domain_cpuid_info(struct domain
 *d,
.ecx = ctl->ecx
}
};
 +int old_vendor = d->arch.x86_vendor;
  d->arch.x86_vendor = get_cpu_vendor(vendor_id.str,
 gcv_guest);
 +
 +if ( is_hvm_domain(d) && (d->arch.x86_vendor != old_vendor) )
 +{
 +struct vcpu *v;
 +
 +domain_pause(d);
 +for_each_vcpu( d, v )
 +hvm_update_guest_vendor(v);
 +domain_unpause(d);
 +}
 +
break;
}
>>> Not specific to this patch, but shouldn't we pause/unpause domain for
>>> the whole routine?
>> Not specifically, although that might be better lonterm.
>>
>> In practice, this hypercall is only made as part of domain construction,
>> and never at domain runtime.
>
> Is it safe to unpause a domain here if it is not running?

Yes - all pausing/unpausing is reference counted, including the initial
systemcontroller pause reference taken (on behalf of the toolstack
domain) during the createdomain hypercall.

~Andrew

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

Re: [Xen-devel] [PATCH 2/2] x86/hvm: Don't intercept #UD exceptions in general

[Boris Ostrovsky]

On 01/27/2016 01:11 PM, Andrew Cooper wrote:

c/s 0f1cb96e "x86 hvm: Allow cross-vendor migration" caused HVM domains to
unconditionally intercept #UD exceptions.  While cross-vendor migration is
cool as a demo, it is extremely niche.

Intercepting #UD allows userspace code in a multi-vcpu guest to execute
arbitrary instructions in the x86 emulator by having one thread execute a ud2a
instruction, and having a second thread rewrite the instruction before the
emulator performs an instruction fetch.

XSAs 105, 106 and 110 are all examples where guest userspace can use bugs in
the x86 emulator to compromise security of the domain, either by privilege
escalation or causing a crash.

c/s 2d67a7a4 "x86: synchronize PCI config space access decoding"
introduced (amongst other things) a per-domain vendor, based on the guests
cpuid policy.

Use the per-guest vendor to enable #UD interception only when a domain is
configured for a vendor different to the current hardware.  (#UD interception
is also enabled if hvm_fep is specified on the Xen command line.  This is a
debug-only option whose entire purpose is for testing the x86 emulator.)

As a result, the overwhelming majority of usecases now have #UD interception
disabled, removing an attack surface for malicious guest userspace.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Jun Nakajima 
CC: Kevin Tian 
CC: Boris Ostrovsky 
CC: Suravee Suthikulpanit 
CC: Aravind Gopalakrishnan 
---
  xen/arch/x86/domctl.c | 18 ++
  xen/arch/x86/hvm/hvm.c|  6 ++
  xen/arch/x86/hvm/svm/svm.c| 13 +
  xen/arch/x86/hvm/svm/vmcb.c   |  1 +
  xen/arch/x86/hvm/vmx/vmcs.c   |  1 +
  xen/arch/x86/hvm/vmx/vmx.c| 15 +++
  xen/include/asm-x86/hvm/hvm.h | 15 ++-
  7 files changed, 64 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 1d71216..1084e82 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -65,8 +65,20 @@ static void update_domain_cpuid_info(struct domain *d,
  .ecx = ctl->ecx
  }
  };
+int old_vendor = d->arch.x86_vendor;
  
  d->arch.x86_vendor = get_cpu_vendor(vendor_id.str, gcv_guest);

+
+if ( is_hvm_domain(d) && (d->arch.x86_vendor != old_vendor) )
+{
+struct vcpu *v;
+
+domain_pause(d);
+for_each_vcpu( d, v )
+hvm_update_guest_vendor(v);
+domain_unpause(d);
+}
+
  break;
  }


Not specific to this patch, but shouldn't we pause/unpause domain for 
the whole routine?



  
@@ -707,6 +719,12 @@ long arch_do_domctl(

  xen_domctl_cpuid_t *ctl = >u.cpuid;
  cpuid_input_t *cpuid, *unused = NULL;
  
+if ( d == currd ) /* no domain_pause() */

+{
+ret = -EINVAL;
+break;
+}
+
  for ( i = 0; i < MAX_CPUID_INPUT; i++ )
  {
  cpuid = >arch.cpuids[i];


...

  
  /* Xen command-line option to enable altp2m */

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 953e0b5..44a1250 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -597,6 +597,18 @@ static void svm_update_guest_efer(struct vcpu *v)
  vmcb_set_efer(vmcb, new_efer);
  }
  
+static void svm_update_guest_vendor(struct vcpu *v)

+{
+struct arch_svm_struct *arch_svm = >arch.hvm_svm;
+struct vmcb_struct *vmcb = arch_svm->vmcb;
+
+if ( opt_hvm_fep ||
+ (v->domain->arch.x86_vendor != boot_cpu_data.x86_vendor) )
+vmcb->_exception_intercepts |= (1U << TRAP_invalid_op);
+else
+vmcb->_exception_intercepts &= ~(1U << TRAP_invalid_op);
+}


I think you need to clear clean bits here (at least bit 0).

-boris

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

[Xen-devel] [PATCH v2 2/2] x86/hvm: Don't intercept #UD exceptions in general

[Andrew Cooper]

c/s 0f1cb96e "x86 hvm: Allow cross-vendor migration" caused HVM domains to
unconditionally intercept #UD exceptions.  While cross-vendor migration is
cool as a demo, it is extremely niche.

Intercepting #UD allows userspace code in a multi-vcpu guest to execute
arbitrary instructions in the x86 emulator by having one thread execute a ud2a
instruction, and having a second thread rewrite the instruction before the
emulator performs an instruction fetch.

XSAs 105, 106 and 110 are all examples where guest userspace can use bugs in
the x86 emulator to compromise security of the domain, either by privilege
escalation or causing a crash.

c/s 2d67a7a4 "x86: synchronize PCI config space access decoding"
introduced (amongst other things) a per-domain vendor, based on the guests
cpuid policy.

Use the per-guest vendor to enable #UD interception only when a domain is
configured for a vendor different to the current hardware.  (#UD interception
is also enabled if hvm_fep is specified on the Xen command line.  This is a
debug-only option whose entire purpose is for testing the x86 emulator.)

As a result, the overwhelming majority of usecases now have #UD interception
disabled, removing an attack surface for malicious guest userspace.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Jun Nakajima 
CC: Kevin Tian 
CC: Boris Ostrovsky 
CC: Suravee Suthikulpanit 
CC: Aravind Gopalakrishnan 

v2:
 * Pause the domain while updating cpuid information.  In practice, the
   set_cpuid hypercall is only made during domain construction.
 * Use vmcb_{get,set}_exception_intercepts() to provide appropriate
   manipulation of the clean bits.
---
 xen/arch/x86/domctl.c | 19 +++
 xen/arch/x86/hvm/hvm.c|  6 ++
 xen/arch/x86/hvm/svm/svm.c| 16 
 xen/arch/x86/hvm/svm/vmcb.c   |  1 +
 xen/arch/x86/hvm/vmx/vmcs.c   |  1 +
 xen/arch/x86/hvm/vmx/vmx.c| 15 +++
 xen/include/asm-x86/hvm/hvm.h | 15 ++-
 7 files changed, 68 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 1d71216..316e13a 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -65,8 +65,18 @@ static void update_domain_cpuid_info(struct domain *d,
 .ecx = ctl->ecx
 }
 };
+int old_vendor = d->arch.x86_vendor;
 
 d->arch.x86_vendor = get_cpu_vendor(vendor_id.str, gcv_guest);
+
+if ( is_hvm_domain(d) && (d->arch.x86_vendor != old_vendor) )
+{
+struct vcpu *v;
+
+for_each_vcpu( d, v )
+hvm_update_guest_vendor(v);
+}
+
 break;
 }
 
@@ -707,6 +717,12 @@ long arch_do_domctl(
 xen_domctl_cpuid_t *ctl = >u.cpuid;
 cpuid_input_t *cpuid, *unused = NULL;
 
+if ( d == currd ) /* no domain_pause() */
+{
+ret = -EINVAL;
+break;
+}
+
 for ( i = 0; i < MAX_CPUID_INPUT; i++ )
 {
 cpuid = >arch.cpuids[i];
@@ -724,6 +740,8 @@ long arch_do_domctl(
 break;
 }
 
+domain_pause(d);
+
 if ( i < MAX_CPUID_INPUT )
 *cpuid = *ctl;
 else if ( unused )
@@ -734,6 +752,7 @@ long arch_do_domctl(
 if ( !ret )
 update_domain_cpuid_info(d, ctl);
 
+domain_unpause(d);
 break;
 }
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 674feea..7a15d49 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -93,12 +93,10 @@ unsigned long __section(".bss.page_aligned")
 static bool_t __initdata opt_hap_enabled = 1;
 boolean_param("hap", opt_hap_enabled);
 
-#ifndef NDEBUG
+#ifndef opt_hvm_fep
 /* Permit use of the Forced Emulation Prefix in HVM guests */
-static bool_t opt_hvm_fep;
+bool_t opt_hvm_fep;
 boolean_param("hvm_fep", opt_hvm_fep);
-#else
-#define opt_hvm_fep 0
 #endif
 
 /* Xen command-line option to enable altp2m */
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 953e0b5..e62dfa1 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -597,6 +597,21 @@ static void svm_update_guest_efer(struct vcpu *v)
 vmcb_set_efer(vmcb, new_efer);
 }
 
+static void svm_update_guest_vendor(struct vcpu *v)
+{
+struct arch_svm_struct *arch_svm = >arch.hvm_svm;
+struct vmcb_struct *vmcb = arch_svm->vmcb;
+u32 bitmap = vmcb_get_exception_intercepts(vmcb);
+
+if ( opt_hvm_fep ||
+ (v->domain->arch.x86_vendor != boot_cpu_data.x86_vendor) )
+bitmap |= (1U << TRAP_invalid_op);
+else
+bitmap &= ~(1U << TRAP_invalid_op);
+
+vmcb_set_exception_intercepts(vmcb, bitmap);
+}
+
 static void svm_sync_vmcb(struct vcpu *v)
 {
 struct arch_svm_struct *arch_svm = >arch.hvm_svm;
@@ 

Re: [Xen-devel] [PATCH 2/2] x86/hvm: Don't intercept #UD exceptions in general

[Andrew Cooper]

On 27/01/16 18:49, Boris Ostrovsky wrote:
> On 01/27/2016 01:11 PM, Andrew Cooper wrote:
>> c/s 0f1cb96e "x86 hvm: Allow cross-vendor migration" caused HVM
>> domains to
>> unconditionally intercept #UD exceptions.  While cross-vendor
>> migration is
>> cool as a demo, it is extremely niche.
>>
>> Intercepting #UD allows userspace code in a multi-vcpu guest to execute
>> arbitrary instructions in the x86 emulator by having one thread
>> execute a ud2a
>> instruction, and having a second thread rewrite the instruction
>> before the
>> emulator performs an instruction fetch.
>>
>> XSAs 105, 106 and 110 are all examples where guest userspace can use
>> bugs in
>> the x86 emulator to compromise security of the domain, either by
>> privilege
>> escalation or causing a crash.
>>
>> c/s 2d67a7a4 "x86: synchronize PCI config space access decoding"
>> introduced (amongst other things) a per-domain vendor, based on the
>> guests
>> cpuid policy.
>>
>> Use the per-guest vendor to enable #UD interception only when a
>> domain is
>> configured for a vendor different to the current hardware.  (#UD
>> interception
>> is also enabled if hvm_fep is specified on the Xen command line. 
>> This is a
>> debug-only option whose entire purpose is for testing the x86 emulator.)
>>
>> As a result, the overwhelming majority of usecases now have #UD
>> interception
>> disabled, removing an attack surface for malicious guest userspace.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Jan Beulich 
>> CC: Jun Nakajima 
>> CC: Kevin Tian 
>> CC: Boris Ostrovsky 
>> CC: Suravee Suthikulpanit 
>> CC: Aravind Gopalakrishnan 
>> ---
>>   xen/arch/x86/domctl.c | 18 ++
>>   xen/arch/x86/hvm/hvm.c|  6 ++
>>   xen/arch/x86/hvm/svm/svm.c| 13 +
>>   xen/arch/x86/hvm/svm/vmcb.c   |  1 +
>>   xen/arch/x86/hvm/vmx/vmcs.c   |  1 +
>>   xen/arch/x86/hvm/vmx/vmx.c| 15 +++
>>   xen/include/asm-x86/hvm/hvm.h | 15 ++-
>>   7 files changed, 64 insertions(+), 5 deletions(-)
>>
>> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
>> index 1d71216..1084e82 100644
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -65,8 +65,20 @@ static void update_domain_cpuid_info(struct domain
>> *d,
>>   .ecx = ctl->ecx
>>   }
>>   };
>> +int old_vendor = d->arch.x86_vendor;
>> d->arch.x86_vendor = get_cpu_vendor(vendor_id.str,
>> gcv_guest);
>> +
>> +if ( is_hvm_domain(d) && (d->arch.x86_vendor != old_vendor) )
>> +{
>> +struct vcpu *v;
>> +
>> +domain_pause(d);
>> +for_each_vcpu( d, v )
>> +hvm_update_guest_vendor(v);
>> +domain_unpause(d);
>> +}
>> +
>>   break;
>>   }
>
> Not specific to this patch, but shouldn't we pause/unpause domain for
> the whole routine?

Not specifically, although that might be better lonterm.

In practice, this hypercall is only made as part of domain construction,
and never at domain runtime.

>
>
>>   @@ -707,6 +719,12 @@ long arch_do_domctl(
>>   xen_domctl_cpuid_t *ctl = >u.cpuid;
>>   cpuid_input_t *cpuid, *unused = NULL;
>>   +if ( d == currd ) /* no domain_pause() */
>> +{
>> +ret = -EINVAL;
>> +break;
>> +}
>> +
>>   for ( i = 0; i < MAX_CPUID_INPUT; i++ )
>>   {
>>   cpuid = >arch.cpuids[i];
>
> ...
>
>> /* Xen command-line option to enable altp2m */
>> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
>> index 953e0b5..44a1250 100644
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -597,6 +597,18 @@ static void svm_update_guest_efer(struct vcpu *v)
>>   vmcb_set_efer(vmcb, new_efer);
>>   }
>>   +static void svm_update_guest_vendor(struct vcpu *v)
>> +{
>> +struct arch_svm_struct *arch_svm = >arch.hvm_svm;
>> +struct vmcb_struct *vmcb = arch_svm->vmcb;
>> +
>> +if ( opt_hvm_fep ||
>> + (v->domain->arch.x86_vendor != boot_cpu_data.x86_vendor) )
>> +vmcb->_exception_intercepts |= (1U << TRAP_invalid_op);
>> +else
>> +vmcb->_exception_intercepts &= ~(1U << TRAP_invalid_op);
>> +}
>
> I think you need to clear clean bits here (at least bit 0).

Hmm - looks like I copied some other code in need of fixing.  I will see
what I can do.

~Andrew

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

Re: [Xen-devel] [PATCH v2 2/2] x86/hvm: Don't intercept #UD exceptions in general

[Boris Ostrovsky]

On 01/27/2016 02:13 PM, Andrew Cooper wrote:

c/s 0f1cb96e "x86 hvm: Allow cross-vendor migration" caused HVM domains to
unconditionally intercept #UD exceptions.  While cross-vendor migration is
cool as a demo, it is extremely niche.

Intercepting #UD allows userspace code in a multi-vcpu guest to execute
arbitrary instructions in the x86 emulator by having one thread execute a ud2a
instruction, and having a second thread rewrite the instruction before the
emulator performs an instruction fetch.

XSAs 105, 106 and 110 are all examples where guest userspace can use bugs in
the x86 emulator to compromise security of the domain, either by privilege
escalation or causing a crash.

c/s 2d67a7a4 "x86: synchronize PCI config space access decoding"
introduced (amongst other things) a per-domain vendor, based on the guests
cpuid policy.

Use the per-guest vendor to enable #UD interception only when a domain is
configured for a vendor different to the current hardware.  (#UD interception
is also enabled if hvm_fep is specified on the Xen command line.  This is a
debug-only option whose entire purpose is for testing the x86 emulator.)

As a result, the overwhelming majority of usecases now have #UD interception
disabled, removing an attack surface for malicious guest userspace.

Signed-off-by: Andrew Cooper 



Reviewed-by: Boris Ostrovsky 


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

Re: [Xen-devel] [PATCH] x86 vm_event: reset monitor in vm_event_cleanup_domain()

[Andrew Cooper]

On 27/01/2016 19:42, Razvan Cojocaru wrote:
> It is currently possible to leave a monitor flag enabled even
> after vm_event_cleanup_domain() has been called, potentially
> leading to a crash in hvm_msr_write_intercept() and hvm_set_crX()
> (when v->arch.vm_event has become NULL, but the corresponding
> corresponding v->domain->arch.monitor flag is non-zero).
> This patch zeroes out arch.monitor in vm_event_cleanup_domain().
>
> Signed-off-by: Razvan Cojocaru 

Reviewed-by: Andrew Cooper 

> ---
>  xen/arch/x86/vm_event.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
> index 9677ecc..08d678a 100644
> --- a/xen/arch/x86/vm_event.c
> +++ b/xen/arch/x86/vm_event.c
> @@ -56,6 +56,7 @@ void vm_event_cleanup_domain(struct domain *d)
>  }
>  
>  d->arch.mem_access_emulate_each_rep = 0;
> +memset(>arch.monitor, 0, sizeof(d->arch.monitor));
>  }
>  
>  void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)


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

Re: [Xen-devel] [RFC] support more qdisk types

[Doug Goldstein]

On 1/27/16 12:32 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 25, 2016 at 05:25:02PM -0700, Jim Fehlig wrote:
>> I would like to hear the community's opinion on supporting more qdisk types 
>> in
>> xl/libxl, e.g. nbd, rbd, iSCSI, etc. I prefer supporting additional qdisk 
>> types
>> in libxl over apps like xl or libvirt doing all the setup, producing a block
>> device, and then passing that to libxl. Each libxl app would have to
>> re-implement functionality already provided by qdisk. libxl already supports
>> IDE, AHCI, SCSI, and Xen PV qdisks. My suggestion is to extend that to 
>> initially
>> include nbd, rbd, and iSCSI. Sheepdog, ssh, etc. could be added in the 
>> future.
> 
> ssh?
>>
>> I considered several approaches to supporting additional qdisk types, based
>> primarily on changes to the disk cfg and interface. At one extreme is to 
>> change
>> nothing and use the existing 'target=' to encode all required config for the
>> additional qdisk types. libxl would need to be taught how to turn the blob 
>> into
>> an appropriate qdisk. At the other extreme is extending xl-disk-configuration
> 
> Either way - new backends would require changes in both libxl and libvirt 
> right?
> The libxl would need to understand the new 'target=' blob to parse it out?
> 

libvirt would probably just do what its doing now. Since it can setup
the connection and pass the file descriptor into libxl. Honestly I don't
see the advantage here because libvirt does a better job from a security
standpoint and unless the goal is to have everything and the kitchen
sink in libxl/xl. There's already a number of ways to skin the cat (xl,
libvirt, xapi, openstack), why another one?

-- 
Doug Goldstein



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

[Xen-devel] [PATCH] x86 vm_event: reset monitor in vm_event_cleanup_domain()

[Razvan Cojocaru]

It is currently possible to leave a monitor flag enabled even
after vm_event_cleanup_domain() has been called, potentially
leading to a crash in hvm_msr_write_intercept() and hvm_set_crX()
(when v->arch.vm_event has become NULL, but the corresponding
corresponding v->domain->arch.monitor flag is non-zero).
This patch zeroes out arch.monitor in vm_event_cleanup_domain().

Signed-off-by: Razvan Cojocaru 
---
 xen/arch/x86/vm_event.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index 9677ecc..08d678a 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -56,6 +56,7 @@ void vm_event_cleanup_domain(struct domain *d)
 }
 
 d->arch.mem_access_emulate_each_rep = 0;
+memset(>arch.monitor, 0, sizeof(d->arch.monitor));
 }
 
 void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)
-- 
2.7.0


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

Re: [Xen-devel] [PATCH] x86 vm_event: reset monitor in vm_event_cleanup_domain()

[Tamas K Lengyel]

On Wed, Jan 27, 2016 at 12:42 PM, Razvan Cojocaru  wrote:

> It is currently possible to leave a monitor flag enabled even
> after vm_event_cleanup_domain() has been called, potentially
> leading to a crash in hvm_msr_write_intercept() and hvm_set_crX()
> (when v->arch.vm_event has become NULL, but the corresponding
> corresponding v->domain->arch.monitor flag is non-zero).
> This patch zeroes out arch.monitor in vm_event_cleanup_domain().
>
> Signed-off-by: Razvan Cojocaru 
>

Acked-by: Tamas K Lengyel 


> ---
>  xen/arch/x86/vm_event.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
> index 9677ecc..08d678a 100644
> --- a/xen/arch/x86/vm_event.c
> +++ b/xen/arch/x86/vm_event.c
> @@ -56,6 +56,7 @@ void vm_event_cleanup_domain(struct domain *d)
>  }
>
>  d->arch.mem_access_emulate_each_rep = 0;
> +memset(>arch.monitor, 0, sizeof(d->arch.monitor));
>  }
>
>  void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)
> --
> 2.7.0
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 2/2] x86/hvm: Don't intercept #UD exceptions in general

[Konrad Rzeszutek Wilk]

On Wed, Jan 27, 2016 at 07:57:00PM +, Andrew Cooper wrote:
> On 27/01/2016 19:52, Konrad Rzeszutek Wilk wrote:
> >> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> >> index 674feea..7a15d49 100644
> >> --- a/xen/arch/x86/hvm/hvm.c
> >> +++ b/xen/arch/x86/hvm/hvm.c
> >> @@ -93,12 +93,10 @@ unsigned long __section(".bss.page_aligned")
> >>  static bool_t __initdata opt_hap_enabled = 1;
> >>  boolean_param("hap", opt_hap_enabled);
> >>  
> >> -#ifndef NDEBUG
> >> +#ifndef opt_hvm_fep
> >>  /* Permit use of the Forced Emulation Prefix in HVM guests */
> >> -static bool_t opt_hvm_fep;
> >> +bool_t opt_hvm_fep;
> >>  boolean_param("hvm_fep", opt_hvm_fep);
> > Since you remove the debug option you should probably also update the 
> > documentation which says: ">Recognized in debug builds of the hypervisor 
> > only."
> 
> This doesn't change the "debug-only"-ness of the option.
> 
> Observe in the first hunk to hvm.h that opt_hvm_fep is defined to 0 in a
> non-debug build, which causes this hunk to be omitted.

I missed that. Sorry for the noise.
> 
> This actually matches the original introduction of opt_hvm_fep, before
> it was reduced in scope to only hvm.c.  I now need it available again in
> other translation units.
> 
> ~Andrew

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

Re: [Xen-devel] [PATCH v2 2/2] x86/hvm: Don't intercept #UD exceptions in general

[Konrad Rzeszutek Wilk]

> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 674feea..7a15d49 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -93,12 +93,10 @@ unsigned long __section(".bss.page_aligned")
>  static bool_t __initdata opt_hap_enabled = 1;
>  boolean_param("hap", opt_hap_enabled);
>  
> -#ifndef NDEBUG
> +#ifndef opt_hvm_fep
>  /* Permit use of the Forced Emulation Prefix in HVM guests */
> -static bool_t opt_hvm_fep;
> +bool_t opt_hvm_fep;
>  boolean_param("hvm_fep", opt_hvm_fep);

Since you remove the debug option you should probably also update the 
documentation which says: ">Recognized in debug builds of the hypervisor only."


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

Re: [Xen-devel] [PATCH v2 2/2] x86/hvm: Don't intercept #UD exceptions in general

[Andrew Cooper]

On 27/01/2016 19:52, Konrad Rzeszutek Wilk wrote:
>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> index 674feea..7a15d49 100644
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -93,12 +93,10 @@ unsigned long __section(".bss.page_aligned")
>>  static bool_t __initdata opt_hap_enabled = 1;
>>  boolean_param("hap", opt_hap_enabled);
>>  
>> -#ifndef NDEBUG
>> +#ifndef opt_hvm_fep
>>  /* Permit use of the Forced Emulation Prefix in HVM guests */
>> -static bool_t opt_hvm_fep;
>> +bool_t opt_hvm_fep;
>>  boolean_param("hvm_fep", opt_hvm_fep);
> Since you remove the debug option you should probably also update the 
> documentation which says: ">Recognized in debug builds of the hypervisor 
> only."

This doesn't change the "debug-only"-ness of the option.

Observe in the first hunk to hvm.h that opt_hvm_fep is defined to 0 in a
non-debug build, which causes this hunk to be omitted.

This actually matches the original introduction of opt_hvm_fep, before
it was reduced in scope to only hvm.c.  I now need it available again in
other translation units.

~Andrew

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

[Xen-devel] [PATCH 2/2] altp2m: Implement p2m_get_mem_access for altp2m views

[Tamas K Lengyel]

Extend the existing get_mem_access memop to allow querying permissions in
altp2m views as well.

Signed-off-by: Tamas K Lengyel 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: Razvan Cojocaru 
Cc: Stefano Stabellini 
Cc: George Dunlap 
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 tools/libxc/include/xenctrl.h   |  3 ++-
 tools/libxc/xc_mem_access.c |  8 +---
 tools/tests/xen-access/xen-access.c |  5 -
 xen/arch/arm/p2m.c  |  4 ++--
 xen/arch/x86/mm/p2m.c   | 23 +++
 xen/common/mem_access.c |  2 +-
 xen/include/xen/p2m-common.h|  3 ++-
 7 files changed, 35 insertions(+), 13 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index b4e57d8..09d9f62 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2065,7 +2065,8 @@ int xc_set_mem_access(xc_interface *xch, domid_t 
domain_id,
  * Gets the mem access for the given page (returned in access on success)
  */
 int xc_get_mem_access(xc_interface *xch, domid_t domain_id,
-  uint64_t pfn, xenmem_access_t *access);
+  uint64_t pfn, uint16_t altp2m_idx,
+  xenmem_access_t *access);
 
 /*
  * Instructions causing a mem_access violation can be emulated by Xen
diff --git a/tools/libxc/xc_mem_access.c b/tools/libxc/xc_mem_access.c
index d6fb409..a44865d 100644
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -46,14 +46,16 @@ int xc_set_mem_access(xc_interface *xch,
 int xc_get_mem_access(xc_interface *xch,
   domid_t domain_id,
   uint64_t pfn,
+  uint16_t altp2m_idx,
   xenmem_access_t *access)
 {
 int rc;
 xen_mem_access_op_t mao =
 {
-.op= XENMEM_access_op_get_access,
-.domid = domain_id,
-.pfn   = pfn
+.op = XENMEM_access_op_get_access,
+.domid  = domain_id,
+.pfn= pfn,
+.altp2m_idx = altp2m_idx
 };
 
 rc = do_memory_op(xch, XENMEM_access_op, , sizeof(mao));
diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index 2300e9a..d9dda62 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -571,7 +571,10 @@ int main(int argc, char *argv[])
 
 switch (req.reason) {
 case VM_EVENT_REASON_MEM_ACCESS:
-rc = xc_get_mem_access(xch, domain_id, req.u.mem_access.gfn, 
);
+rc = xc_get_mem_access(xch, domain_id, req.u.mem_access.gfn,
+   ((req.flags & 
VM_EVENT_FLAG_ALTERNATE_P2M) ? req.altp2m_idx : 0),
+   
+   );
 if (rc < 0)
 {
 ERROR("Error %d getting mem_access event\n", rc);
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 8e9b4be..932c6e2 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1666,7 +1666,7 @@ bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, 
const struct npfec npfec)
 if ( !p2m->mem_access_enabled )
 return true;
 
-rc = p2m_get_mem_access(v->domain, _gfn(paddr_to_pfn(gpa)), );
+rc = p2m_get_mem_access(v->domain, _gfn(paddr_to_pfn(gpa)), 0, );
 if ( rc )
 return true;
 
@@ -1847,7 +1847,7 @@ long p2m_set_mem_access(struct domain *d, gfn_t gfn, 
uint32_t nr,
 return 0;
 }
 
-int p2m_get_mem_access(struct domain *d, gfn_t gfn,
+int p2m_get_mem_access(struct domain *d, gfn_t gfn, unsigned long altp2m_idx,
xenmem_access_t *access)
 {
 int ret;
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 95bf7ce..18068e8 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1572,7 +1572,9 @@ void p2m_mem_access_emulate_check(struct vcpu *v,
 bool_t violation = 1;
 const struct vm_event_mem_access *data = >u.mem_access;
 
-if ( p2m_get_mem_access(v->domain, _gfn(data->gfn), ) == 0 )
+if ( p2m_get_mem_access(v->domain, _gfn(data->gfn),
+altp2m_active(v->domain) ? 
vcpu_altp2m(v).p2midx : 0,
+) == 0 )
 {
 switch ( access )
 {
@@ -1918,9 +1920,10 @@ long p2m_set_mem_access(struct domain *d, gfn_t gfn, 
uint32_t nr,
  * Get access type for a gfn.
  * If gfn == INVALID_GFN, gets the default access type.
  */
-int p2m_get_mem_access(struct domain *d, gfn_t gfn, xenmem_access_t *access)
+int p2m_get_mem_access(struct domain *d, gfn_t 

[Xen-devel] [PATCH 1/2] altp2m: Merge p2m_set_altp2m_mem_access and p2m_set_mem_access

[Tamas K Lengyel]

The altp2m subsystem in its current form uses its own HVMOP hypercall to set
mem_access permissions, duplicating some of the code already present for
setting regular mem_access permissions. In this patch we consolidate the two,
deprecate the HVMOP hypercall and update the corresponding tools.

Signed-off-by: Tamas K Lengyel 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: Razvan Cojocaru 
Cc: Stefano Stabellini 
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
---
 tools/libxc/include/xenctrl.h   |   5 +-
 tools/libxc/xc_altp2m.c |  25 --
 tools/libxc/xc_mem_access.c |  14 +--
 tools/tests/xen-access/xen-access.c |  53 ---
 xen/arch/arm/p2m.c  |   9 +-
 xen/arch/x86/hvm/hvm.c  |   9 --
 xen/arch/x86/mm/p2m.c   | 169 
 xen/common/mem_access.c |   2 +-
 xen/include/asm-x86/p2m.h   |   4 -
 xen/include/public/hvm/hvm_op.h |  15 +---
 xen/include/public/memory.h |   3 +
 xen/include/xen/p2m-common.h|   3 +-
 12 files changed, 115 insertions(+), 196 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index e632b1e..b4e57d8 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2027,9 +2027,6 @@ int xc_altp2m_destroy_view(xc_interface *handle, domid_t 
domid,
 /* Switch all vCPUs of the domain to the specified altp2m view */
 int xc_altp2m_switch_to_view(xc_interface *handle, domid_t domid,
  uint16_t view_id);
-int xc_altp2m_set_mem_access(xc_interface *handle, domid_t domid,
- uint16_t view_id, xen_pfn_t gfn,
- xenmem_access_t access);
 int xc_altp2m_change_gfn(xc_interface *handle, domid_t domid,
  uint16_t view_id, xen_pfn_t old_gfn,
  xen_pfn_t new_gfn);
@@ -2062,7 +2059,7 @@ int xc_mem_paging_load(xc_interface *xch, domid_t 
domain_id,
  */
 int xc_set_mem_access(xc_interface *xch, domid_t domain_id,
   xenmem_access_t access, uint64_t first_pfn,
-  uint32_t nr);
+  uint32_t nr, uint16_t altp2m_idx);
 
 /*
  * Gets the mem access for the given page (returned in access on success)
diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
index 0639632..4f44a7b 100644
--- a/tools/libxc/xc_altp2m.c
+++ b/tools/libxc/xc_altp2m.c
@@ -163,31 +163,6 @@ int xc_altp2m_switch_to_view(xc_interface *handle, domid_t 
domid,
 return rc;
 }
 
-int xc_altp2m_set_mem_access(xc_interface *handle, domid_t domid,
- uint16_t view_id, xen_pfn_t gfn,
- xenmem_access_t access)
-{
-int rc;
-DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
-
-arg = xc_hypercall_buffer_alloc(handle, arg, sizeof(*arg));
-if ( arg == NULL )
-return -1;
-
-arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
-arg->cmd = HVMOP_altp2m_set_mem_access;
-arg->domain = domid;
-arg->u.set_mem_access.view = view_id;
-arg->u.set_mem_access.hvmmem_access = access;
-arg->u.set_mem_access.gfn = gfn;
-
-rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
- HYPERCALL_BUFFER_AS_ARG(arg));
-
-xc_hypercall_buffer_free(handle, arg);
-return rc;
-}
-
 int xc_altp2m_change_gfn(xc_interface *handle, domid_t domid,
  uint16_t view_id, xen_pfn_t old_gfn,
  xen_pfn_t new_gfn)
diff --git a/tools/libxc/xc_mem_access.c b/tools/libxc/xc_mem_access.c
index 3634c39..d6fb409 100644
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -27,15 +27,17 @@ int xc_set_mem_access(xc_interface *xch,
   domid_t domain_id,
   xenmem_access_t access,
   uint64_t first_pfn,
-  uint32_t nr)
+  uint32_t nr,
+  uint16_t altp2m_idx)
 {
 xen_mem_access_op_t mao =
 {
-.op = XENMEM_access_op_set_access,
-.domid  = domain_id,
-.access = access,
-.pfn= first_pfn,
-.nr = nr
+.op = XENMEM_access_op_set_access,
+.domid  = domain_id,
+.access = access,
+.pfn= first_pfn,
+.nr = nr,
+.altp2m_idx = altp2m_idx
 };
 
 return do_memory_op(xch, XENMEM_access_op, , sizeof(mao));
diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index 7993947..2300e9a 100644
--- 

Re: [Xen-devel] [RFC] support more qdisk types

[Konrad Rzeszutek Wilk]

On Wed, Jan 27, 2016 at 02:25:51PM -0600, Doug Goldstein wrote:
> On 1/27/16 12:32 PM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jan 25, 2016 at 05:25:02PM -0700, Jim Fehlig wrote:
> >> I would like to hear the community's opinion on supporting more qdisk 
> >> types in
> >> xl/libxl, e.g. nbd, rbd, iSCSI, etc. I prefer supporting additional qdisk 
> >> types
> >> in libxl over apps like xl or libvirt doing all the setup, producing a 
> >> block
> >> device, and then passing that to libxl. Each libxl app would have to
> >> re-implement functionality already provided by qdisk. libxl already 
> >> supports
> >> IDE, AHCI, SCSI, and Xen PV qdisks. My suggestion is to extend that to 
> >> initially
> >> include nbd, rbd, and iSCSI. Sheepdog, ssh, etc. could be added in the 
> >> future.
> > 
> > ssh?
> >>
> >> I considered several approaches to supporting additional qdisk types, based
> >> primarily on changes to the disk cfg and interface. At one extreme is to 
> >> change
> >> nothing and use the existing 'target=' to encode all required config for 
> >> the
> >> additional qdisk types. libxl would need to be taught how to turn the blob 
> >> into
> >> an appropriate qdisk. At the other extreme is extending 
> >> xl-disk-configuration
> > 
> > Either way - new backends would require changes in both libxl and libvirt 
> > right?
> > The libxl would need to understand the new 'target=' blob to parse it out?
> > 
> 
> libvirt would probably just do what its doing now. Since it can setup
> the connection and pass the file descriptor into libxl. Honestly I don't
> see the advantage here because libvirt does a better job from a security
> standpoint and unless the goal is to have everything and the kitchen
> sink in libxl/xl. There's already a number of ways to skin the cat (xl,
> libvirt, xapi, openstack), why another one?

I believe what Jim is saying that there needs to be some parsing in libxl
so that it can pass the right information to QEMU. But that is an assumption
and it may be that we do not need it as you suggest?

> 
> -- 
> Doug Goldstein
> 



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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  370608b4c76f7290cbebc4e4a05fca4eb0e9ffe8
baseline version:
 libvirt  356e28b35ed9a49399a1cdbeb34194c80e3579a4

Last test of basis79069  2016-01-26 04:27:26 Z1 days
Testing same since79146  2016-01-27 04:20:46 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  Laine Stump 
  Leno Hou 
  Luyao Huang 
  Michal Privoznik 
  Pavel Hrdina 

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=370608b4c76f7290cbebc4e4a05fca4eb0e9ffe8
+ . ./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 ']'
++ 

Re: [Xen-devel] [PATCH v9 02/25] docs/libxl: Introduce COLO_CONTEXT to support migration v2 colo streams

[Andrew Cooper]

On 27/01/16 06:47, Wen Congyang wrote:
> On 01/27/2016 04:40 AM, Konrad Rzeszutek Wilk wrote:
>> On Wed, Dec 30, 2015 at 10:37:32AM +0800, Wen Congyang wrote:
>>> It is the negotiation record for COLO.
>>> Primary->Secondary:
>>> control_id  0x: Secondary VM is out of sync, start a new 
>>> checkpoint
>>> Secondary->Primary:
>>> 0x0001: Secondary VM is suspended
>>> 0x0002: Secondary VM is ready
>>> 0x0003: Secondary VM is resumed
>>>
>>> Signed-off-by: Wen Congyang 
>>> Signed-off-by: Yang Hongyang 
>>> ---
>>>  docs/specs/libxl-migration-stream.pandoc | 25 +++--
>>>  tools/libxl/libxl_sr_stream_format.h | 11 +++
>>>  tools/python/xen/migration/libxl.py  |  9 +
>>>  3 files changed, 43 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/docs/specs/libxl-migration-stream.pandoc 
>>> b/docs/specs/libxl-migration-stream.pandoc
>>> index 2c97d86..5166d66 100644
>>> --- a/docs/specs/libxl-migration-stream.pandoc
>>> +++ b/docs/specs/libxl-migration-stream.pandoc
>>> @@ -1,6 +1,6 @@
>>>  % LibXenLight Domain Image Format
>>>  % Andrew Cooper <>
>>> -% Revision 1
>>> +% Revision 2
>>>  
>>>  Introduction
>>>  
>>> @@ -119,7 +119,9 @@ type 0x: END
>>>  
>>>   0x0004: CHECKPOINT_END
>>>  
>>> - 0x0005 - 0x7FFF: Reserved for future _mandatory_
>>> + 0x0005: CHECKPOINT_STATE
>>> +
>>> + 0x0006 - 0x7FFF: Reserved for future _mandatory_
>> This is in the 'mandatory' records. Should it be part of optional records?
>>
>> Would this checkpoint state always present on non-COLO guest migration?
> No. Will be fixed in the next version

It is correct that CHECKPOINT_STATE is a mandatory record.

Optional records which are free for the receiving end to ignore if they
are not understood.

~Andrew

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

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

[Maciej W. Rozycki]

On Fri, 15 Jan 2016, Leonid Yegoshin wrote:

> > So you need to build a different kernel for some types of MIPS systems?
> > Or do you do boot-time rewriting, like a number of other arches do?
> 
> I don't know. I would like to have responses. Ralf asked Maciej about old
> systems and that came nowhere. Even rewrite - don't know what to do with that:
> no lightweight SYNC or no SYNC at all - yes, it is still possible that SYNC on
> some systems can be too heavy or even harmful, nobody tested that.

 I don't recall being asked; mind that I might not get to messages I have 
not been cc-ed in a timely manner and I may miss some altogether.  With 
the amount of mailing list traffic that passes by me my scanner may fail 
to trigger.  Sorry if this causes anybody trouble, but such is life.

 Coincidentally, I have just posted some notes on SYNC in a different 
thread, see .  
There's a reference to an older message of mine there too.  I hope this 
answers your questions.

  Maciej

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

Re: [Xen-devel] xenbits GitHub mirror?

[George Dunlap]

On Wed, Jan 27, 2016 at 10:55 AM, Andrew Cooper
 wrote:
> On 27/01/16 09:45, Ian Campbell wrote:
>> On Tue, 2016-01-26 at 11:26 -0600, Doug Goldstein wrote:
>>> On 1/26/16 10:55 AM, Ian Campbell wrote:
 On Sat, 2015-12-19 at 14:51 -0600, Doug Goldstein wrote:
> All,
>
> Now I'll start off by saying that "no" is a perfectly acceptable answer
> to this suggestion. Basically I remember at the Xen Developer Summit a
> few people mentioned it being nice if people provided a git tree where
> their branches were available for testing. I was just thinking it might
> be easier for third parties to do that if there was an official Xen
> Project mirror of the main repos on xenbits on GitHub and people could
> fork that repo and make their branch available. Just a thought.
 If forking the repo significantly easier than just creating an empty one of
 your own and pushing to it? Is the parent repo "important" in some way in
 the GH world? (Given that, as George says, we are unlikely to accept
 contributions via GH pull requests etc).

 Ian.

>>> Its not easier or different. I just remembered from the Xen Developer
>>> Summit that a few people complained that a lot of the patch series
>>> posted to the ML really should be available as a repo because they were
>>> quite large and hard to review. I see this comment come up over and over
>>> on the ML myself as well so I was just trying to lower the barriers to
>>> people doing that. I know the reason people don't isn't technical so
>>> this isn't really a technical solution but I figured this is more a
>>> social thing. GitHub has the ability to mark a repo as a mirror and not
>>> allow pull requests or issues, which is what I would recommend. I'm just
>>> looking at improving the community aspect. I could create an
>>> organization called "xen-mirror" and get it setup and turn it over to
>>> the Xen Project.
>>>
>>> Again, I'm fine with an answer of "no" here. Just trying to pitch out
>>> ideas to solve what some see as an irritation.
>> I don't think you need anybodies permission to do this if you think it will
>> be valuable.
>
> If there is going to be an official github mirror, then it should be
> part of github.com/xen-project rather than hosted by a random developer.

Just to be clear, I think Ian was suggesting that Doug could make an
unofficial mirror (as the mirage guys have done).

> FWIW, I am +1 for setting up infrastructure like this, but lets do it
> properly.
>
> Lars: Thoughts?

Doug says that you can mark a repo as a 'mirror', which will prevent
people from being able to send pull requests to it; so I think my
technical objection has been answered.

I think the idea is still only half-baked though, as I'm not sure how
having a github mirror will make it so that most mail has a git repo
you can pull from (which would be necessary to reach the ultimate
goal, making it straightforward to apply patches sent to the list).

 -George

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

Re: [Xen-devel] [linux-4.1 test] 79008: regressions - FAIL

[Ian Campbell]

On Wed, 2016-01-27 at 11:18 +, Ian Campbell wrote:
> On Tue, 2016-01-26 at 13:11 +, osstest service owner wrote:
> > flight 79008 linux-4.1 real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/79008/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail REGR. vs. 
> > 66399
> >  test-armhf-armhf-xl-xsm  15 guest-start/debian.repeat fail REGR. vs. 
> > 66399
> 
> These were both:
> 
> 2016-01-26 01:20:33 Z executing ssh ... root@172.16.147.101 echo guest 
> debian.guest.osstest: ok 
> Warning: Permanently added '172.16.147.101' (ECDSA) to the list of known 
> hosts.
> key_verify failed for server_host_key

While poking through the test histories I also spotted:
http://logs.test-lab.xenproject.org/osstest/logs/78799/test-armhf-armhf-xl-cubietruck/info.html
http://logs.test-lab.xenproject.org/osstest/logs/78997/test-armhf-armhf-xl-cubietruck/info.html

Which are:
2016-01-26 01:03:34 Z executing ssh ... root@172.16.144.48 ps -wwef 
Corrupted MAC on input.
Disconnecting: Packet corrupt
(this is dom0 rather than the "server_host_key" thing which was guest)

But it seems like it could be a different symptom of the same underlying
cause. Data-mining the logs a bit I find:

78033  test-armhf-armhf-xl-cubietruck  16.ts-logs-capture.log  host   
cubietruck-braque
78799  test-armhf-armhf-libvirt-raw8.ts-leak-check.log host~  
cubietruck-braque
78799  test-armhf-armhf-libvirt-raw9.ts-logs-capture.log   host~  
cubietruck-braque
78799  test-armhf-armhf-libvirt-xsm8.ts-leak-check.log host~  
cubietruck-braque
78799  test-armhf-armhf-libvirt-xsm9.ts-logs-capture.log   host~  
cubietruck-braque
78799  test-armhf-armhf-xl 8.ts-leak-check.log host~  
cubietruck-picasso
78799  test-armhf-armhf-xl 9.ts-logs-capture.log   host~  
cubietruck-picasso
78799  test-armhf-armhf-xl-credit2 8.ts-leak-check.log host~  
cubietruck-picasso
78799  test-armhf-armhf-xl-credit2 9.ts-logs-capture.log   host~  
cubietruck-picasso
78799  test-armhf-armhf-xl-cubietruck  8.ts-leak-check.log host~  
cubietruck-braque
78799  test-armhf-armhf-xl-cubietruck  9.ts-logs-capture.log   host~  
cubietruck-braque
78799  test-armhf-armhf-xl-multivcpu   8.ts-leak-check.log host~  
cubietruck-gleizes
78799  test-armhf-armhf-xl-multivcpu   9.ts-logs-capture.log   host~  
cubietruck-gleizes
78799  test-armhf-armhf-xl-vhd 10.ts-logs-capture.log  host~  
cubietruck-metzinger
78799  test-armhf-armhf-xl-xsm 8.ts-leak-check.log host~  
cubietruck-metzinger
78799  test-armhf-armhf-xl-xsm 9.ts-logs-capture.log   host~  
cubietruck-metzinger
78925  test-armhf-armhf-libvirt-raw10.ts-logs-capture.log  host~  
cubietruck-picasso
78925  test-armhf-armhf-xl-credit2 12.ts-logs-capture.log  host~  
cubietruck-metzinger
78925  test-armhf-armhf-xl-cubietruck  16.ts-logs-capture.log  host~  
cubietruck-gleizes
78925  test-armhf-armhf-xl-multivcpu   19.ts-logs-capture.log  host~  
cubietruck-metzinger
78925  test-armhf-armhf-xl-xsm 16.ts-logs-capture.log  host~  
cubietruck-gleizes
78997  test-armhf-armhf-libvirt-raw10.ts-logs-capture.log  host~  
cubietruck-braque
78997  test-armhf-armhf-libvirt-xsm8.ts-leak-check.log host~  
cubietruck-braque
78997  test-armhf-armhf-libvirt-xsm9.ts-logs-capture.log   host~  
cubietruck-braque
78997  test-armhf-armhf-xl 8.ts-leak-check.log host~  
cubietruck-gleizes
78997  test-armhf-armhf-xl 9.ts-logs-capture.log   host~  
cubietruck-gleizes
78997  test-armhf-armhf-xl-credit2 8.ts-leak-check.log host~  
cubietruck-picasso
78997  test-armhf-armhf-xl-credit2 9.ts-logs-capture.log   host~  
cubietruck-picasso
78997  test-armhf-armhf-xl-cubietruck  8.ts-leak-check.log host~  
cubietruck-braque
78997  test-armhf-armhf-xl-cubietruck  9.ts-logs-capture.log   host~  
cubietruck-braque
78997  test-armhf-armhf-xl-multivcpu   8.ts-leak-check.log host~  
cubietruck-metzinger
78997  test-armhf-armhf-xl-multivcpu   9.ts-logs-capture.log   host~  
cubietruck-metzinger
78997  test-armhf-armhf-xl-vhd 10.ts-logs-capture.log  host~  
cubietruck-metzinger
78997  test-armhf-armhf-xl-xsm 8.ts-leak-check.log host~  
cubietruck-gleizes
78997  test-armhf-armhf-xl-xsm 9.ts-logs-capture.log   host~  
cubietruck-gleizes
79008  test-armhf-armhf-libvirt-raw10.ts-logs-capture.log  host~  
cubietruck-picasso
79008  test-armhf-armhf-xl-credit2 16.ts-logs-capture.log  host~  
cubietruck-metzinger
79008  test-armhf-armhf-xl-cubietruck  12.ts-logs-capture.log  host~  
cubietruck-gleizes
79008  test-armhf-armhf-xl-multivcpu   19.ts-logs-capture.log  host~  
cubietruck-picasso
79008  test-armhf-armhf-xl-xsm 16.ts-logs-capture.log  host~  
cubietruck-gleizes
79088  

Re: [Xen-devel] [PATCH v5 6/8] arm/gic-v3: Refactor gicv3_init into generic and dt specific parts

[Stefano Stabellini]

On Sat, 23 Jan 2016, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> Refactor gic-v3 related functions into dt and generic parts. This will be
> helpful when adding acpi support for gic-v3.
> 
> Signed-off-by: Shannon Zhao 
> ---
> v5: none
> v4: Use INVALID_PADDR and move ioremap to common init function
> ---
>  xen/arch/arm/gic-v3.c | 114 
> +++---
>  1 file changed, 61 insertions(+), 53 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index a245b56..65a4de6 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1138,41 +1138,14 @@ static int __init cmp_rdist(const void *a, const void 
> *b)
>  return ( l->base < r->base) ? -1 : 0;
>  }
>  
> +static paddr_t __initdata dbase = INVALID_PADDR, vbase = INVALID_PADDR;
> +static paddr_t __initdata cbase = INVALID_PADDR, csize = INVALID_PADDR;
> +
>  /* If the GICv3 supports GICv2, initialize it */
> -static void __init gicv3_init_v2(const struct dt_device_node *node,
> - paddr_t dbase)
> +static void __init gicv3_init_v2(void)
>  {
> -int res;
> -paddr_t cbase, csize;
> -paddr_t vbase, vsize;
> -
> -/*
> - * For GICv3 supporting GICv2, GICC and GICV base address will be
> - * provided.
> - */
> -res = dt_device_get_address(node, 1 + gicv3.rdist_count,
> -, );
> -if ( res )
> -return;
> -
> -res = dt_device_get_address(node, 1 + gicv3.rdist_count + 2,
> -, );
> -if ( res )
> -return;
> -
> -/*
> - * We emulate a vGICv2 using a GIC CPU interface of GUEST_GICC_SIZE.
> - * So only support GICv2 on GICv3 when the virtual CPU interface is
> - * at least GUEST_GICC_SIZE.
> - */
> -if ( vsize < GUEST_GICC_SIZE )
> -{
> -printk(XENLOG_WARNING
> -   "GICv3: WARNING: Not enabling support for GICv2 compat 
> mode.\n"
> -   "Size of GICV (%#"PRIpaddr") must at least be %#llx.\n",
> -   vsize, GUEST_GICC_SIZE);

The vsize < GUEST_GICC_SIZE check needs to remain here because ... 


> +if ( cbase == INVALID_PADDR || vbase == INVALID_PADDR )
>  return;
> -}
>  
>  printk("GICv3 compatible with GICv2 cbase %#"PRIpaddr" vbase 
> %#"PRIpaddr"\n",
> cbase, vbase);
> @@ -1180,20 +1153,12 @@ static void __init gicv3_init_v2(const struct 
> dt_device_node *node,
>  vgic_v2_setup_hw(dbase, cbase, csize, vbase, 0);
>  }
>  
> -/* Set up the GIC */
> -static int __init gicv3_init(void)
> +static void __init gicv3_dt_init(void)
>  {
>  struct rdist_region *rdist_regs;
>  int res, i;
> -uint32_t reg;
>  const struct dt_device_node *node = gicv3_info.node;
> -paddr_t dbase;
> -
> -if ( !cpu_has_gicv3 )
> -{
> -dprintk(XENLOG_ERR, "GICv3: driver requires system register 
> support\n");
> -return -ENODEV;
> -}
> +paddr_t vsize;
>  
>  res = dt_device_get_address(node, 0, , NULL);
>  if ( res )
> @@ -1203,14 +1168,6 @@ static int __init gicv3_init(void)
>  panic("GICv3:  Found unaligned distributor address %"PRIpaddr"",
>dbase);
>  
> -gicv3.map_dbase = ioremap_nocache(dbase, SZ_64K);
> -if ( !gicv3.map_dbase )
> -panic("GICv3: Failed to ioremap for GIC distributor\n");
> -
> -reg = readl_relaxed(GICD + GICD_PIDR2) & GIC_PIDR2_ARCH_MASK;
> -if ( reg != GIC_PIDR2_ARCH_GICv3 && reg != GIC_PIDR2_ARCH_GICv4 )
> - panic("GICv3: no distributor detected\n");
> -
>  if ( !dt_property_read_u32(node, "#redistributor-regions",
>  _count) )
>  gicv3.rdist_count = 1;
> @@ -1248,6 +1205,57 @@ static int __init gicv3_init(void)
>  panic("GICv3: Cannot find the maintenance IRQ");
>  gicv3_info.maintenance_irq = res;
>  
> +/*
> + * For GICv3 supporting GICv2, GICC and GICV base address will be
> + * provided.
> + */
> +res = dt_device_get_address(node, 1 + gicv3.rdist_count,
> +, );
> +if ( res )
> +return;
> +
> +res = dt_device_get_address(node, 1 + gicv3.rdist_count + 2,
> +, );
> +if ( res )
> +return;
> +
> +/*
> + * We emulate a vGICv2 using a GIC CPU interface of GUEST_GICC_SIZE.
> + * So only support GICv2 on GICv3 when the virtual CPU interface is
> + * at least GUEST_GICC_SIZE.
> + */
> +if ( vsize < GUEST_GICC_SIZE )
> +{
> +printk(XENLOG_WARNING
> +   "GICv3: WARNING: Not enabling support for GICv2 compat 
> mode.\n"
> +   "Size of GICV (%#"PRIpaddr") must at least be %#llx.\n",
> +   vsize, GUEST_GICC_SIZE);
> +return;

... here it is completely ineffectual.


> +}
> +}
> +
> +/* Set up the GIC */
> +static int __init gicv3_init(void)
> +{
> +

Re: [Xen-devel] A New Year, A New Way to Build for XenServer

[Ian Campbell]

On Wed, 2016-01-27 at 11:01 +, Jason Long wrote:
> Hello.
> I look at below article :
> 
> http://xenserver.org/blog/entry/a-new-year-a-new-way-to-build-for-xenserver.html
> 
> What does it mean?

xenserver != xenproject (xenserver is a downstream project of xenproject).

If this discussion belongs anywhere (which isn't clear) then it is on the
xenserver lists/forums etc.

Ian.

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

Re: [Xen-devel] [PATCH v4 3/3] VT-d: Fix vt-d Device-TLB flush timeout issue.

[Xu, Quan]

> On January 27, 2016 at 6:48am,  wrote:
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: Tuesday, January 26, 2016 11:53 PM


> > Once again: Before getting started, please assess which route is going
> > to be the better one. Remember that we had already discussed and put
> > aside some form of deferring the hiding of devices, so if you come
> > back with a patch doing that again, you'll have to be able to explain
> > why the alternative(s) are worse.
> >
> 
> Quan, could you list pros/cons of those alternatives based on discussion so 
> far?
> Then we can decide which way should be done before you go to actual coding.
> Earlier suggestion on hiding device immediately is under the assumption that 
> all
> locks have been held. If this part becomes too complex, and you can explain
> clearly that deferring the hiding action doesn't lead to any race condition, 
> then
> people can see why you are proposing defer again.


The following are pros/cons of those alternatives. It is also why I propose 
defer again.

-- --
1. Hiding the devices immediately
Pros:
 * it makes whatever changes are ASAP after the Device-TLB flush error.
 
Cons:
 * It may break the code path.
 * It may lead to any race condition.
 * Hiding the devices immediately is under the assumption that all locks 
have been held.
  Different locking state is possible for different call trees. This part 
becomes too complex.
 
2. deferring the hiding of devices
Pros:
*It doesn't lead to any race condition.
*It makes existing calling chains with all required error handling 
completed.
 
Cons:
* It needs to maintain a flag.
-- --

-
How to defer the hiding of devices:
When Device-TLB flush is error, it is to set a new flag and then continue 
existing calling chains with all required error handling completed. Only at 
safe place we can safely invoke pci_hide_device() variant to hide devices. We 
do a lazy hide until next time when it's assigned to another guest while the 
new flag is recognized.

Furthermore explanation:
A new flag:
 In my previous email, I introduced a "pci_dev->info.is_unassignable" 
flag. When Device-TLB flush is error, I think it is not a good idea to modify 
the pci_dev,
 As it is uncertain whether pcidevs_lock is acquired.
 I'd better introduce a new iommu bitmap array to register the device 
with BDF. It may be quite similar to 'iommu->domid_bitmap'

Safe place: 
 I think the beginning of reassign_device_ownership() is a safe place 
to hide the device which is registered with the new flag.
 reassign_device_ownership() is under lock.

pci_hide_device() variant:
 Remove the pcidevs_lock, as the pcidevs_lock has been acquired at call 
tree of reassign_device_ownership().


Thanks!!!
-Quan

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail in 78925 
REGR. vs. 66399
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 79008 REGR. 
vs. 66399
 test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail in 79008 REGR. vs. 
66399
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop   running

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken in 78925 
pass in 79090
 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken in 78925 pass in 
79090
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 
fail in 78925 pass in 79008
 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail in 78925 
pass in 79090
 test-armhf-armhf-xl-cubietruck 11 guest-start   fail pass in 78925
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail pass 
in 79008
 test-armhf-armhf-xl-credit2  11 guest-start fail pass in 79008
 test-armhf-armhf-xl-arndale   6 xen-bootfail pass in 79008
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
pass in 79008
 test-armhf-armhf-xl-xsm  11 guest-start fail pass in 79008

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail in 78925 never 
pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail in 78925 
never pass
 test-armhf-armhf-xl-credit2 13 saverestore-support-check fail in 79008 never 
pass
 test-armhf-armhf-xl-credit2  12 migrate-support-check fail in 79008 never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-check fail in 79008 never pass
 test-armhf-armhf-xl-arndale 13 saverestore-support-check fail in 79008 never 
pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-check fail in 79008 never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-check fail in 79008 never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail in 79008 never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-check fail in 79008 never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-check fail in 79008 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-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 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-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-i386-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-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-libvirt-vhd 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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
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-libvirt-raw  9 debian-di-installfail   never pass

version targeted for testing:
 linux99c5a856dcee7658ec7e250aa477a9afaab8cfc6
baseline version:
 linux

Re: [Xen-devel] [PATCH v4 3/3] VT-d: Fix vt-d Device-TLB flush timeout issue.

[Jan Beulich]

>>> On 27.01.16 at 12:09,  wrote:
>>  On January 27, 2016 at 6:48am,  wrote:
>> > From: Jan Beulich [mailto:jbeul...@suse.com]
>> > Sent: Tuesday, January 26, 2016 11:53 PM
> 
> 
>> > Once again: Before getting started, please assess which route is going
>> > to be the better one. Remember that we had already discussed and put
>> > aside some form of deferring the hiding of devices, so if you come
>> > back with a patch doing that again, you'll have to be able to explain
>> > why the alternative(s) are worse.
>> >
>> 
>> Quan, could you list pros/cons of those alternatives based on discussion so 
>> far?
>> Then we can decide which way should be done before you go to actual coding.
>> Earlier suggestion on hiding device immediately is under the assumption that 
>> all
>> locks have been held. If this part becomes too complex, and you can explain
>> clearly that deferring the hiding action doesn't lead to any race condition, 
>> then
>> people can see why you are proposing defer again.
> 
> 
> The following are pros/cons of those alternatives. It is also why I propose 
> defer again.
> 
> -- --
> 1. Hiding the devices immediately
> Pros:
>  * it makes whatever changes are ASAP after the Device-TLB flush error.
>  
> Cons:
>  * It may break the code path.
>  * It may lead to any race condition.
>  * Hiding the devices immediately is under the assumption that all locks 
> have been held.
>   Different locking state is possible for different call trees. This part 
> becomes too complex.

So you just repeat what you've already said before. "This part
becomes too complex" you say without any kind of proof, yet
that's what we need to understand whether the alternative of
doing the locking correctly really is this bad (and I continue to
not see why it would).

Jan


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

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

[Maciej W. Rozycki]

On Wed, 27 Jan 2016, Ralf Baechle wrote:

> > So you need to build a different kernel for some types of MIPS systems?
> 
> Yes.  We can't really do without.  Classic MIPS code is not relocatable
> without the complexity of PIC code as used by ELF DSOs - and their
> performanc penalty.  Plus we have a number of architecture revisions
> ovr the decades, big and little endian, 32 and 64 bit as the major
> stumbling stones.  There however are groups of similar systems that
> can share kernel binaries.

 Matt (cc-ed) has recently posted patches to add support for a relocatable 
kernel, implemented without the usual overhead of PIC code.  It works by 
retaining relocations in a fully-linked binary and then simply replaying 
the work the static linker does when assigning addresses, as the image 
loaded is copied to its intended destination at an early bootstrap stage.  
See: 

 
for details.

 I think this framework can be reused by carefully choosing instructions 
used in early bootstrap code, up to the relocation stage, so that it is 
runnable anywhere (not the same as PIC!) like early ld.so initialisation 
and then loading the whole attached image starting from an address where 
RAM does exist on target hardware.

 Endianness is a different matter, obviously we can't build a single image 
for both, although for distributions' sake an approach similar to one used 
with bi-endian firmware (for hardware which has an easy way to switch the 
endianness, e.g. a physical jumper or a configuration bit stored in flash 
memory; not to be confused with the reverse user endianness mode) might be 
feasible, by glueing two kernel images together and then selecting the 
right one early in bootstrap, perhaps again reusing Matt's framework.  
I'm not sure if this is worth the effort though, I suspect the usage level 
of this feature would be minimal.

 All in all I think making a generic MIPS kernel just might be feasible, 
but with the diversity of options available the effort required would be 
enormous.  NetBSD for example I believe supports building a kernel that 
correctly runs on both R3000 (MIPS I, 32-bit) and R4000 (MIPS III, 64-bit) 
DEC hardware (as did DEC Ultrix, the vendor OS for these systems).  These 
processors are different enough from each other that you cannot use the 
same code for cache, memory and exception management in an OS kernel -- 
backward compatibility is only provided for user software.  That proves 
the concept, however in a very limited way only, not even covering SMP, 
and their R4000 kernel does not support 64-bit userland I believe.  They 
still have completely separate ports for other MIPS hardware, such as for 
Broadcom SiByte SB-1 (MIPS64r1) processors.

  Maciej

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

[Xen-devel] [distros-debian-squeeze test] 38707: all pass

[Platform Team regression test user]

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

Perfect :-)
All tests in this flight passed
baseline version:
 flight   38672

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-squeeze-netboot-pygrubpass
 test-amd64-i386-amd64-squeeze-netboot-pygrub pass
 test-amd64-amd64-i386-squeeze-netboot-pygrub pass
 test-amd64-i386-i386-squeeze-netboot-pygrub  pass



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

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

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


Push not applicable.


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

[Xen-devel] [PATCH V2] arm: p2m.c bug-fix: hypervisor hang on __p2m_get_mem_access

[Corneliu ZUZU]

When __p2m_get_mem_access gets called, the p2m lock is already taken
by either get_page_from_gva or p2m_get_mem_access.

Possible code paths:
1)  -> get_page_from_gva
-> p2m_mem_access_check_and_get_page
-> __p2m_get_mem_access
2)  -> p2m_get_mem_access
-> __p2m_get_mem_access

In both cases if __p2m_get_mem_access subsequently gets to
call p2m_lookup (happens if !radix_tree_lookup(...)), a hypervisor
hang will occur, since p2m_lookup also spin-locks on the p2m lock.

This bug-fix simply replaces the p2m_lookup call from __p2m_get_mem_access
with a call to __p2m_lookup.

Following Ian's suggestion, we also add an ASSERT to ensure that
the p2m lock is taken upon __p2m_get_mem_access entry.

Signed-off-by: Corneliu ZUZU 
---
 xen/arch/arm/p2m.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 2190908..e8e6db4 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -468,6 +468,8 @@ static int __p2m_get_mem_access(struct domain *d, gfn_t gfn,
 #undef ACCESS
 };
 
+ASSERT(spin_is_locked(>lock));
+
 /* If no setting was ever set, just return rwx. */
 if ( !p2m->mem_access_enabled )
 {
@@ -490,7 +492,7 @@ static int __p2m_get_mem_access(struct domain *d, gfn_t gfn,
  * No setting was found in the Radix tree. Check if the
  * entry exists in the page-tables.
  */
-paddr_t maddr = p2m_lookup(d, gfn_x(gfn) << PAGE_SHIFT, NULL);
+paddr_t maddr = __p2m_lookup(d, gfn_x(gfn) << PAGE_SHIFT, NULL);
 if ( INVALID_PADDR == maddr )
 return -ESRCH;
 
-- 
2.5.0


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

Re: [Xen-devel] xenbits GitHub mirror?

[Ian Campbell]

On Tue, 2016-01-26 at 11:26 -0600, Doug Goldstein wrote:
> On 1/26/16 10:55 AM, Ian Campbell wrote:
> > On Sat, 2015-12-19 at 14:51 -0600, Doug Goldstein wrote:
> > > All,
> > > 
> > > Now I'll start off by saying that "no" is a perfectly acceptable answer
> > > to this suggestion. Basically I remember at the Xen Developer Summit a
> > > few people mentioned it being nice if people provided a git tree where
> > > their branches were available for testing. I was just thinking it might
> > > be easier for third parties to do that if there was an official Xen
> > > Project mirror of the main repos on xenbits on GitHub and people could
> > > fork that repo and make their branch available. Just a thought.
> > 
> > If forking the repo significantly easier than just creating an empty one of
> > your own and pushing to it? Is the parent repo "important" in some way in
> > the GH world? (Given that, as George says, we are unlikely to accept
> > contributions via GH pull requests etc).
> > 
> > Ian.
> > 
> 
> Its not easier or different. I just remembered from the Xen Developer
> Summit that a few people complained that a lot of the patch series
> posted to the ML really should be available as a repo because they were
> quite large and hard to review. I see this comment come up over and over
> on the ML myself as well so I was just trying to lower the barriers to
> people doing that. I know the reason people don't isn't technical so
> this isn't really a technical solution but I figured this is more a
> social thing. GitHub has the ability to mark a repo as a mirror and not
> allow pull requests or issues, which is what I would recommend. I'm just
> looking at improving the community aspect. I could create an
> organization called "xen-mirror" and get it setup and turn it over to
> the Xen Project.
> 
> Again, I'm fine with an answer of "no" here. Just trying to pitch out
> ideas to solve what some see as an irritation.

I don't think you need anybodies permission to do this if you think it will
be valuable.

Ian.

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

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

[Will Deacon]

On Tue, Jan 26, 2016 at 11:58:20AM -0800, Paul E. McKenney wrote:
> On Tue, Jan 26, 2016 at 12:16:09PM +, Will Deacon wrote:
> > On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote:
> > > On Mon, Jan 25, 2016 at 04:42:43PM +, Will Deacon wrote:
> > > > On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote:
> > > > > PPC Overlapping Group-B sets version 4
> > > > > ""
> > > > > (* When the Group-B sets from two different barriers involve 
> > > > > instructions in
> > > > >the same thread, within that thread one set must contain the other.
> > > > > 
> > > > >   P0  P1  P2
> > > > >   Rx=1Wy=1Wz=2
> > > > >   dep.lwsync  lwsync
> > > > >   Ry=0Wz=1Wx=1
> > > > >   Rz=1
> > > > > 
> > > > >   assert(!(z=2))
> > > > > 
> > > > >Forbidden by ppcmem, allowed by herd.
> > > > > *)
> > > > > {
> > > > > 0:r1=x; 0:r2=y; 0:r3=z;
> > > > > 1:r1=x; 1:r2=y; 1:r3=z; 1:r4=1;
> > > > > 2:r1=x; 2:r2=y; 2:r3=z; 2:r4=1; 2:r5=2;
> > > > > }
> > > > >  P0   | P1| P2;
> > > > >  lwz r6,0(r1) | stw r4,0(r2)  | stw r5,0(r3)  ;
> > > > >  xor r7,r6,r6 | lwsync| lwsync;
> > > > >  lwzx r7,r7,r2| stw r4,0(r3)  | stw r4,0(r1)  ;
> > > > >  lwz r8,0(r3) |   |   ;
> > > > > 
> > > > > exists
> > > > > (z=2 /\ 0:r6=1 /\ 0:r7=0 /\ 0:r8=1)
> > > > 
> > > > That really hurts. Assuming that the "assert(!(z=2))" is actually there
> > > > to constrain the coherence order of z to be {0->1->2}, then I think that
> > > > this test is forbidden on arm using dmb instead of lwsync. That said, I
> > > > also don't think the Rz=1 in P0 changes anything.
> > > 
> > > What about the smp_wmb() variant of dmb that orders only stores?
> > 
> > Tricky, but I think it still works out if the coherence order of z is as
> > I described above. The line of reasoning is weird though -- I ended up
> > considering the two cases where P0 reads z before and after it reads x
> > and what that means for the read of y.
> 
> By "works out" you mean that ARM prohibits the outcome?

Yes, that's my understanding.

Will

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

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

[Ralf Baechle]

On Thu, Jan 14, 2016 at 04:47:53PM -0800, Paul E. McKenney wrote:

> So you need to build a different kernel for some types of MIPS systems?

Yes.  We can't really do without.  Classic MIPS code is not relocatable
without the complexity of PIC code as used by ELF DSOs - and their
performanc penalty.  Plus we have a number of architecture revisions
ovr the decades, big and little endian, 32 and 64 bit as the major
stumbling stones.  There however are groups of similar systems that
can share kernel binaries.

> Or do you do boot-time rewriting, like a number of other arches do?

We don't rewrite the code (as in the .text of the vmlinux binary) but we
do runtime code generation for a few highly performance sensitive area
of the kernel code such as copy_page() or TLB exception handlers.  This
allows more flexibility than just inserting templates into the kernel
code.  Downside - it means we have some of the complexity of as and ld
in the kernel.

  Ralf

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

Re: [Xen-devel] xenbits GitHub mirror?

[Andrew Cooper]

On 27/01/16 09:45, Ian Campbell wrote:
> On Tue, 2016-01-26 at 11:26 -0600, Doug Goldstein wrote:
>> On 1/26/16 10:55 AM, Ian Campbell wrote:
>>> On Sat, 2015-12-19 at 14:51 -0600, Doug Goldstein wrote:
 All,

 Now I'll start off by saying that "no" is a perfectly acceptable answer
 to this suggestion. Basically I remember at the Xen Developer Summit a
 few people mentioned it being nice if people provided a git tree where
 their branches were available for testing. I was just thinking it might
 be easier for third parties to do that if there was an official Xen
 Project mirror of the main repos on xenbits on GitHub and people could
 fork that repo and make their branch available. Just a thought.
>>> If forking the repo significantly easier than just creating an empty one of
>>> your own and pushing to it? Is the parent repo "important" in some way in
>>> the GH world? (Given that, as George says, we are unlikely to accept
>>> contributions via GH pull requests etc).
>>>
>>> Ian.
>>>
>> Its not easier or different. I just remembered from the Xen Developer
>> Summit that a few people complained that a lot of the patch series
>> posted to the ML really should be available as a repo because they were
>> quite large and hard to review. I see this comment come up over and over
>> on the ML myself as well so I was just trying to lower the barriers to
>> people doing that. I know the reason people don't isn't technical so
>> this isn't really a technical solution but I figured this is more a
>> social thing. GitHub has the ability to mark a repo as a mirror and not
>> allow pull requests or issues, which is what I would recommend. I'm just
>> looking at improving the community aspect. I could create an
>> organization called "xen-mirror" and get it setup and turn it over to
>> the Xen Project.
>>
>> Again, I'm fine with an answer of "no" here. Just trying to pitch out
>> ideas to solve what some see as an irritation.
> I don't think you need anybodies permission to do this if you think it will
> be valuable.

If there is going to be an official github mirror, then it should be
part of github.com/xen-project rather than hosted by a random developer.

FWIW, I am +1 for setting up infrastructure like this, but lets do it
properly.

Lars: Thoughts?

~Andrew

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

Re: [Xen-devel] [PATCH v9 03/25] libxc/migration: Specification update for DIRTY_PFN_LIST records

[Andrew Cooper]

On 27/01/16 10:00, Ian Campbell wrote:
> On Wed, 2016-01-27 at 15:12 +0800, Wen Congyang wrote:
>> On 01/27/2016 04:44 AM, Konrad Rzeszutek Wilk wrote:
 + 0x000F: DIRTY_PFN_LIST
 +
>>> Perhaps make it part of the optional and prefix it with CHECKPOINT?
>> IIUC, optional record can be ignored, but this record cannot be ignored.
>>
>> To Andrew Cooper:
>> Should I mark this record as optional record?
> My understanding was that this indicated things for which support was
> mandatory (whereas unknown optional ones may be ignored), not that they
> must be present in every stream.
>
> IOW placing this in the mandatory flags is correct, since the restorer
> cannot simply ignore a checkpoint flag.

Both correct on all points.  This should be a mandatory record.

~Andrew

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

Re: [Xen-devel] [linux-4.1 test] 79008: regressions - FAIL

[Ian Campbell]

On Tue, 2016-01-26 at 13:11 +, osstest service owner wrote:
> flight 79008 linux-4.1 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/79008/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail REGR. vs. 
> 66399
>  test-armhf-armhf-xl-xsm  15 guest-start/debian.repeat fail REGR. vs. 
> 66399

These were both:

2016-01-26 01:20:33 Z executing ssh ... root@172.16.147.101 echo guest 
debian.guest.osstest: ok 
Warning: Permanently added '172.16.147.101' (ECDSA) to the list of known hosts.
key_verify failed for server_host_key

Searching for that message online shows a variety of results for the last
15 years or so, although it's not clear that any of them are actually the
same, many of them also involve a "hash mismatch" message, which is not
present here.

As far as our own tests go:

$ echo ~osstest/pub/logs/*/*/[0-9]*.log | xargs grep -l "key_verify failed for 
server_host_key"
/home/osstest/pub/logs/78033/test-armhf-armhf-xl-cubietruck/15.ts-repeat-test.log

/home/osstest/pub/logs/78925/test-armhf-armhf-xl-credit2/11.ts-guest-start.log
/home/osstest/pub/logs/78925/test-armhf-armhf-xl-cubietruck/15.ts-repeat-test.log
/home/osstest/pub/logs/78925/test-armhf-armhf-xl-xsm/15.ts-repeat-test.log

/home/osstest/pub/logs/79008/test-armhf-armhf-xl-credit2/15.ts-repeat-test.log
/home/osstest/pub/logs/79008/test-armhf-armhf-xl-cubietruck/11.ts-guest-start.log
/home/osstest/pub/logs/79008/test-armhf-armhf-xl-xsm/15.ts-repeat-test.log

/home/osstest/pub/logs/79088/test-armhf-armhf-xl-credit2/15.ts-repeat-test.log

/home/osstest/pub/logs/79090/test-armhf-armhf-xl-credit2/11.ts-guest-start.log
/home/osstest/pub/logs/79090/test-armhf-armhf-xl-cubietruck/11.ts-guest-start.log
/home/osstest/pub/logs/79090/test-armhf-armhf-xl-xsm/11.ts-guest-start.log

/home/osstest/pub/logs/79120/test-armhf-armhf-xl-xsm/15.ts-repeat-test.log

From flights (machines in same order as tests above):

[linux-linus bisection] 78033: tested test-armhf-armhf-xl-cubietruck
cubietruck-braque
[linux-4.1 test] 78925: regressions - trouble: broken/fail/pass
cubietruck-metzinger
cubietruck-gleizes
cubietruck-gleizes
[linux-4.1 test] 79008: regressions - FAIL
cubietruck-metzinger
[linux-4.1 bisection] 79088: testing test-armhf-armhf-xl-credit2
cubietruck-metzinger
79090 is still in progress (nearly complete) but is on linux-4.1
cubietruck-metzinger
cubietruck-gleizes
cubietruck-gleizes
[linux-4.1 bisection] 79120: testing test-armhf-armhf-xl-xsm
cubietruck-gleizes

Neither of the bisects look likely to make any progress:
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-4.1/test-armhf-armhf-xl-xsm.guest-start--debian.repeat.html
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-4.1/test-armhf-armhf-xl-credit2.guest-start--debian.repeat.html

We only have logs back as far as 20 Jan, so it's possible there isn't
enough data here to decide anything, but the span does include some logs
from linux-3.18 which seems to not be showing this. OTOH linux-linus has
only hit it once, maybe this was fixed already upstream.

I suspect linux-4.1 has a cubietruck specific hardware issue (perhaps in
the network driver). I'm not sure how best to approach it though,
especially given that it doesn't seem to be reproducible by the bisector.

Ian.

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

[Xen-devel] [linux-3.18 baseline-only test] 38706: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 38706 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38706/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-credit2  19 guest-start/debian.repeat fail REGR. vs. 38588

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 13 rumpuserxen-demo-xenstorels/xenstorels 
fail REGR. vs. 38588
 test-amd64-i386-rumpuserxen-i386 10 guest-startfail like 38588

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-xl-pvh-intel 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-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-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-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-xl-pvh-amd  11 guest-start  fail   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-amd64-amd64-libvirt-xsm 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-i386-libvirt  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-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-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-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-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install  fail never pass

version targeted for testing:
 linux707e840c5e24bb2df1ea4e753964275e257ec816
baseline version:
 linux60917545df1ffc7f918550512dc4a14758f74784

Last test of basis38588  2016-01-04 09:58:54 Z   23 days
Testing same since38706  2016-01-26 21:30:25 Z0 days1 attempts


People who touched revisions under test:
  Alan Stern 
  Alexey Khoroshilov 
  Andrew Morton 
  Arnd Bergmann 
  Ben Hutchings 
  Benjamin Coddington 
  Cong Wang 
  Daeho Jeong 
  Daniele Palmas 
  David Howells 
  David J. Wilder 
  David S. Miller 
  Dmitry Vyukov 
  Don Zickus 
  Emmanuel Grumbach 
  Eric Dumazet 
  Felipe Balbi 
  Filipe Manana 
  Greg Kroah-Hartman 
  Hannes Frederic Sowa 
  Hans Yang 
  Hobin Woo 
  Ilya Dryomov 
  J. Bruce Fields 
  James Morris 

Re: [Xen-devel] [PATCH] arm: p2m.c bug-fix: hypervisor hang on __p2m_get_mem_access

[Ian Campbell]

(we went offlist by mistake without noticing, resending my last reply which
I think has sufficient context/quoting to make sense)

On Wed, 2016-01-27 at 11:51 +0200, CORNELIU ZUZU wrote:
> On 1/26/2016 6:14 PM, Ian Campbell wrote:
> > On Tue, 2016-01-26 at 13:46 +0200, Corneliu ZUZU wrote:
> > > When __p2m_get_mem_access gets called, the p2m lock is already taken
> > > by either get_page_from_gva or p2m_get_mem_access.
> > > 
> > > Possible code paths:
> > > 1)-> get_page_from_gva
> > >   -> p2m_mem_access_check_and_get_page
> > >   -> __p2m_get_mem_access
> > > 2)-> p2m_get_mem_access
> > >   -> __p2m_get_mem_access
> > What about:
> > -> p2m_mem_access_check
> > -> p2m_get_mem_access
> > I can't see the lock being taken in that paths.
> 
> Yes, that's code path #2 I've previously mentioned, the lock is first 
> taken in p2m_get_mem_access (i.e. the line 'spin_lock(>lock)'),
> before __p2m_get_mem_access is called.

Oh yes, not sure how I got myself confused there.

> I'm looking @ the master branch of git://xenbits.xenproject.org/xen.git 
> (although we've hit this bug on the 4.6 stable repo).
> 
> > 
> > As well as fixing that I think it would be wise to add an assert that
> > the
> > lock is held before the call to p2m_lookup which you are changing into
> > the
> > unlocked variant.
> 
> Good idea, didn't know one could do that.
> Concretely, I suppose this would be done by
> 
> ASSERT(spin_is_locked(>lock));
> 
> ?

Right.

> 
> One question though. It seems that everytime __p2m_get_mem_access is 
> called, the lock is taken *before the call*, not within the
> function itself.

Right. It's a common (but by no mean universal) convention within Xen that
a __foo function is a version of foo which expects the relevant lock(s) to
already be held.

> Since __p2m_get_mem_access also accesses other fields of the p2m pointer 
> (e.g. 'p2m->mem_access_enabled'),
> including performing a radix tree lookup before calling p2m_lookup, 
> doesn't this mean that
> the p2m lock is also needed for these accesses (especially for the radix 
> tree lookup)? And if so,
> shouldn't I position the assertion line @ the *beginning* of 
> __p2m_get_mem_access, e.g. just before 'if ( !p2m->mem_access_enabled )'?

Yes, since p2m_get_mem_access requires the lock to be taken on entry it
makes sense to put the assert as near the top of the function as possible. 

This is true whether the initial bit of the function does anything which
requires the lock.

Ian.

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