date:20161007

Re: [Xen-devel] [Resend PATCH 2/2] Xen/timer: Process softirq during dumping timer info

2016-10-07 Thread Lan Tianyu

On 2016年10月06日 20:56, Jan Beulich wrote:
 On 30.09.16 at 04:19,  wrote:
>> --- a/xen/common/timer.c
>> +++ b/xen/common/timer.c
>> @@ -530,6 +530,7 @@ static void dump_timerq(unsigned char key)
>>  {
>>  ts = _cpu(timers, i);
>>  
>> +process_pending_softirqs();
>>  printk("CPU%02d:\n", i);
>>  spin_lock_irqsave(>lock, flags);
>>  for ( j = 1; j <= GET_HEAP_SIZE(ts->heap); j++ )
> 
> Hmm - is that enough when there are many timers on one CPU? But
> well, adding something inside the lock region would of course make
> things quite a bit harder, so I guess this has to be enough for now.
> 

Yes, it's hard to add process_pending_softirqs() under lock just like
you said. I search init_timer() and there are 28 callers. Printing 28
lines of timer info is supposed to last a brief of time.

-- 
Best regards
Tianyu Lan

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

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

2016-10-07 Thread osstest service owner

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 9381ad8701275b802c6f6c9d5629a084afa93ddc
baseline version:
 ovmf f6c8e67db9233562fd3ddc6bf7d23f0bb5fb115b

Last test of basis   101329  2016-10-07 22:44:33 Z0 days
Testing same since   101331  2016-10-08 01:47:07 Z0 days1 attempts


People who touched revisions under test:
  Eric Dong 
  Jiewen Yao 
  Thomas Huth 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=9381ad8701275b802c6f6c9d5629a084afa93ddc
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
9381ad8701275b802c6f6c9d5629a084afa93ddc
+ branch=ovmf
+ revision=9381ad8701275b802c6f6c9d5629a084afa93ddc
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x9381ad8701275b802c6f6c9d5629a084afa93ddc = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ :

[Xen-devel] [xen-unstable baseline-only test] 67845: tolerable FAIL

2016-10-07 Thread Platform Team regression test user

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67835
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67835
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 67835

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

version targeted for testing:
 xen  84c1e7d8017c773c41d6e8b79384f37a67be1479
baseline version:
 xen  9f5eff08a6a6f58645fb48382c843973674042c9

Last test of basis67835  2016-10-06 23:18:32 Z1 days
Testing same since67845  2016-10-07 20:53:08 Z0 days1 attempts


People who touched revisions under test:
  Lan Tianyu 
  Razvan Cojocaru 

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

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

2016-10-07 Thread Platform Team regression test user

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf f9c3b1b5343f53705f1ab72c55c1db440b01f36f
baseline version:
 ovmf e8a70885d8f34533b6dd69878fe95a249e9af086

Last test of basis67814  2016-10-06 09:46:01 Z1 days
Testing same since67846  2016-10-07 22:50:43 Z0 days1 attempts


People who touched revisions under test:
  Giri P Mudusuru 
  Vladimir Olovyannikov 

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



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

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

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


Push not applicable.


commit f9c3b1b5343f53705f1ab72c55c1db440b01f36f
Author: Vladimir Olovyannikov 
Date:   Thu Oct 6 15:02:26 2016 -0700

ShellPkg: Fix erroneous Status returned by ShellOpenFileByName()

In ShellOpenFileByName() the file is opened using
gEfiShellProtocol->OpenFileByName().
It is supposed that if this call returns an EFI_ERROR, the function
should return that error immediately. However, this return was missing,
and if UnicodeCollationProtocol has not been located by this time, the
Status gets overwritten with LocateProtocol() call result, which
eventually erroneously returns EFI_SUCCESS to the Shell.c, and this
leads to attempt to execute a non-existent startup script, which fails,
and which in turn leads to Shell being unloaded with "Invalid parameter"
error. This patch fixes the bug.

Cc: Tapan Shah 
Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Vladimir Olovyannikov 
Reviewed-by: Tapan Shah 
Reviewed-by: Jaben Carsey 

commit 98e059ba16549f436e3d9e04112e9b1659da3eed
Author: Giri P Mudusuru 
Date:   Fri Sep 30 10:35:18 2016 -0700

IntelSiliconPkg: Updated IgdOpregion.h based on latest spec

Updated IgdOpregion.h to align with latest specification
https://01.org/sites/default/files/documentation/skl_opregion_rev0p5.pdf

1) Updated Mailbox structures to align with latest spec
2) Added Mailbox 5 structure
3) Added defines for Signature and Mailbox support

Reviewed-by: Jiewen Yao 
Reviewed-by: Maurice Ma 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Giri P Mudusuru 

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

Re: [Xen-devel] [PATCH net-next] MAINTAINERS: add myself as a maintainer of xen-netback

2016-10-07 Thread David Miller

From: Paul Durrant 
Date: Fri, 7 Oct 2016 11:33:37 +0100

> Signed-off-by: Paul Durrant 

Applied.

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

Re: [Xen-devel] [Resend PATCH 1/2] Xen/Keyhandler: Make keyhandler always run in tasklet

2016-10-07 Thread Lan Tianyu

On 2016年10月06日 20:52, Jan Beulich wrote:
 On 30.09.16 at 04:19,  wrote:
>> @@ -87,10 +89,10 @@ void handle_keypress(unsigned char key, struct 
>> cpu_user_regs *regs)
>>  if ( key >= ARRAY_SIZE(key_table) || !(h = _table[key])->fn )
>>  return;
>>  
>> -if ( !in_irq() || h->irq_callback )
>> +if ( h->irq_callback )
> 
> Please make subject/description reflect this: You don't _always_
> force the use of the tasklet.

Ok. I also find register_irq_keyhandler() isn't called anywhere in
current code and that means none uses irq_callback. Can we remove it?

> 
> And then I don't think we want the debugkey sysctl get processed
> asynchronously - the sysctl should complete only when the key has
> been fully handled, in order to not interfere with a subsequent one
> (namely the one retrieving the log buffer).

We may introduce a new parameter for handle_keypress() to specify
whether it should schedule a tasklet to run keyhandler or not. For
sysctl case, it should be the later one.

-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] [Resend PATCH 1/2] Xen/Keyhandler: Make keyhandler always run in tasklet

2016-10-07 Thread Lan Tianyu

Hi Konrad:
Thanks for your review.

On 2016年10月01日 02:07, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 30, 2016 at 10:19:05AM +0800, Lan Tianyu wrote:
>> Keyhandler may run for a long time in a timer handler on the large machine
> 
> I am bit lost.
> 
> You say 'timer handler' which will imply that there is some form
> of 'init_timer' and 'set_timer' that would call the handle_keypress
> function?
> But I am not seeing it?
> 
> Or are you saying that when 'dump_timerq' is invoked?
> If so please say that.


When serial port driver works in the poll mode, it will set a regular
timer to deal with all input key and keyhandler(e,g dump_timerq()) will
run in the timer handler.

> 
>> with a lot of physical cpus(E,G keyhandler for dumping timer info) when 
>> serial
> 
> s/E,G/e.g.g/
> 
>> port driver works in the poll mode. When timer interrupt arrives, timer 
>> subsystem
> 
> s/poll mode/poll mode (via the exception mechanism)/
> 
>> runs all timer handlers before programming next timer interrupt. So if timer 
>> handler
>> runs longer than time for watchdog timeout, the timer handler of watchdog 
>> will be
> 
> Ah, so this is if a guest has set a timer and we are executing it. Or we have
> many of them to go through.

I meant the serial port timer handler here which calls keyhandler
will run long time, no APIC timer interrupt will arrive to trigger timer
softirq and feed watchdog during this procedure. Because there is no
chance to program timer interrupt before completing all timer handlers
in this case.

>
>> blocked to feed watchdog and xen hypervisor panics. This patch is to fix the 
>> issue
>> via always scheduling a tasklet to run keyhandler to avoid timer handler 
>> running
>> too long.
> 
> You say "timer handler" again. But the timer handlers are executed via
> timer_softirq_action (which is a softirq, aka triggered by IPI).

In this case, APIC timer interrupt handler apic_timer_interrupt()
triggers timer softirq and runs all expired timer handlers in timer softirq.

> 
> And the tasklet will mean that that it gets to be executed _after_ the
> do_softirq is done (as softirq.h puts the low numbered ones first, such
> as the TIMER_SOFTIRQ)?
> 
> So what I think you are saying is that you do not want the 
> 'timer_softirq_action'
> to be preempted by the 'dump_timerq' (or any other ones) which will
> trip the watchdog timeout. 

I want to make sure serial port timer handler doesn't run long time and
not affect feed dog operation.

> 
> If that is the case please put something to that affect in the
> commit description.
> 
> That begs one question that should be probably answered in the commit
> description:
> 
> Why can't the dump_timerq or any other keyhandler poke the watchdog
> (expose nmi_timer_fn and call that?)

Do you mean to feed nmi watchdog in the keyhandler directly?

> 
>>
>> Signed-off-by: Lan Tianyu 
> 
> Otherwise the mechanical parts of the patch look good.
> 
>> ---
>>  xen/common/keyhandler.c |8 +---
>>  1 files changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
>> index 16de6e8..fce52d2 100644
>> --- a/xen/common/keyhandler.c
>> +++ b/xen/common/keyhandler.c
>> @@ -75,7 +75,9 @@ static struct keyhandler {
>>  
>>  static void keypress_action(unsigned long unused)
>>  {
>> -handle_keypress(keypress_key, NULL);
>> +console_start_log_everything();
>> +key_table[keypress_key].fn(keypress_key);
>> +console_end_log_everything();
>>  }
>>  
>>  static DECLARE_TASKLET(keypress_tasklet, keypress_action, 0);
>> @@ -87,10 +89,10 @@ void handle_keypress(unsigned char key, struct 
>> cpu_user_regs *regs)
>>  if ( key >= ARRAY_SIZE(key_table) || !(h = _table[key])->fn )
>>  return;
>>  
>> -if ( !in_irq() || h->irq_callback )
>> +if ( h->irq_callback )
>>  {
>>  console_start_log_everything();
>> -h->irq_callback ? h->irq_fn(key, regs) : h->fn(key);
>> +h->irq_fn(key, regs);
>>  console_end_log_everything();
>>  }
>>  else
>> -- 
>> 1.7.1
>>


-- 
Best regards
Tianyu Lan

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

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

2016-10-07 Thread osstest service owner

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 101317
 test-amd64-amd64-xl-rtds  9 debian-install  fail blocked in 101317
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101317
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101317

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-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   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-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-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-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  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-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-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass

version targeted for testing:
 qemuu48f592118ab42f83a1a7561c4bfd2b72a100f241
baseline version:
 qemuue902754e3d0890945ddcc1b33748ed73762ddb8d

Last test of basis   101317  2016-10-06 19:45:44 Z1 days
Testing same since   101325  2016-10-07 15:16:42 Z0 days2 attempts


People who touched revisions under test:
  Ed Maste 
  Peter Maydell 

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-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm

Re: [Xen-devel] [PATCH V4] xen/arm: domain_build: allocate lowmem for dom0 as much as possible

2016-10-07 Thread Peng Fan

Hi Stefano, Julien

Any comments on this v4 patch?

Thanks,
Peng
On Fri, Sep 23, 2016 at 10:55:34AM +0800, Peng Fan wrote:
>On AArch64 SoCs, some IPs may only have the capability to access
>32 bits address space. The physical memory assigned for Dom0 maybe
>not in 4GB address space, then the IPs will not work properly.
>So need to allocate memory under 4GB for Dom0.
>
>There is no restriction that how much lowmem needs to be allocated for
>Dom0 ,so allocate lowmem as much as possible for Dom0.
>
>This patch does not affect 32-bit domain, because Variable "lowmem" is
>set to true at the beginning. If failed to allocate bank0 under 4GB,
>need to panic for 32-bit domain, because 32-bit domain requires bank0
>be allocated under 4GB.
>
>For 64-bit domain, set "lowmem" to false, and continue allocating
>memory from above 4GB.
>
>Signed-off-by: Peng Fan 
>Cc: Stefano Stabellini 
>Cc: Julien Grall 
>---
>
>This patch is to resolve the issue mentioned in
>https://lists.xen.org/archives/html/xen-devel/2016-09/msg00235.html
>
> Tested results:
> (XEN) Allocating 1:1 mappings totalling 2048MB for dom0:
> (XEN) BANK[0] 0x008800-0x00f800 (1792MB)
> (XEN) BANK[1] 0x09e000-0x09f000 (256MB)
> 1792M allocated in 4GB address space.
>
>V4:
> Address comments in V3: 
> https://lists.xen.org/archives/html/xen-devel/2016-09/msg02499.html
> Drop uneccessary check when failed to allocate memory under 4GB
> Refine comments according to Julien's suggestion in V3.
> Keep "bits <= (lowmem ? 32 : PADDR_BITS)", but not changed to "bits <= 32"
>
>V3:
> Add more commit log
> Add more comments
> Add back panic if failed to allocate bank0 under 4GB for 32-bit domain.
>
>V2:
> Remove the bootargs dom0_lowmem introduced in V1.
> Following 
> "https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01459.html;
> to allocate as much as possible lowmem.
>
> xen/arch/arm/domain_build.c | 33 ++---
> 1 file changed, 22 insertions(+), 11 deletions(-)
>
>diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>index 35ab08d..6b5ac8d 100644
>--- a/xen/arch/arm/domain_build.c
>+++ b/xen/arch/arm/domain_build.c
>@@ -195,9 +195,9 @@ fail:
>  *bank. Partly this is just easier for us to deal with, but also
>  *the ramdisk and DTB must be placed within a certain proximity of
>  *the kernel within RAM.
>- * 3. For 32-bit dom0 we want to place as much of the RAM as we
>- *reasonably can below 4GB, so that it can be used by non-LPAE
>- *enabled kernels.
>+ * 3. For dom0 we want to place as much of the RAM as we reasonably can
>+ *below 4GB, so that it can be used by non-LPAE enabled kernels (32-bit)
>+ *or when a device assigned to dom0 can only do 32-bit DMA access.
>  * 4. For 32-bit dom0 the kernel must be located below 4GB.
>  * 5. We want to have a few largers banks rather than many smaller ones.
>  *
>@@ -230,7 +230,8 @@ fail:
>  * we give up.
>  *
>  * For 32-bit domain we require that the initial allocation for the
>- * first bank is under 4G. Then for the subsequent allocations we
>+ * first bank is under 4G. For 64-bit domain, the first bank is preferred
>+ * to be allocated under 4G. Then for the subsequent allocations we
>  * initially allocate memory only from below 4GB. Once that runs out
>  * (as described above) we allow higher allocations and continue until
>  * that runs out (or we have allocated sufficient dom0 memory).
>@@ -244,7 +245,7 @@ static void allocate_memory(struct domain *d, struct 
>kernel_info *kinfo)
> unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
> int i;
> 
>-bool_t lowmem = is_32bit_domain(d);
>+bool_t lowmem = true;
> unsigned int bits;
> 
> /*
>@@ -269,20 +270,30 @@ static void allocate_memory(struct domain *d, struct 
>kernel_info *kinfo)
> {
> pg = alloc_domheap_pages(d, order, MEMF_bits(bits));
> if ( pg != NULL )
>+{
>+if ( !insert_11_bank(d, kinfo, pg, order) )
>+BUG(); /* Cannot fail for first bank */
>+
> goto got_bank0;
>+}
> }
> order--;
> }
> 
>-panic("Unable to allocate first memory bank");
>-
>- got_bank0:
>+/* Failed to allocate bank0 under 4GB */
>+if ( is_32bit_domain(d) )
>+panic("Unable to allocate first memory bank.");
> 
>-if ( !insert_11_bank(d, kinfo, pg, order) )
>-BUG(); /* Cannot fail for first bank */
>+/* Try to allocate memory from above 4GB */
>+printk(XENLOG_INFO "No bank has been allocated below 4GB.\n");
>+lowmem = false;
> 
>-/* Now allocate more memory and fill in additional banks */
>+ got_bank0:
> 
>+/*
>+ * If we failed to allocate bank0 under 4GB, continue allocating
>+ * memory from above 4GB and fill in banks.
>+ */
> order = get_11_allocation_size(kinfo->unassigned_mem);
>

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

2016-10-07 Thread osstest service owner

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf f6c8e67db9233562fd3ddc6bf7d23f0bb5fb115b
baseline version:
 ovmf f9c3b1b5343f53705f1ab72c55c1db440b01f36f

Last test of basis   101327  2016-10-07 17:48:18 Z0 days
Testing same since   101329  2016-10-07 22:44:33 Z0 days1 attempts


People who touched revisions under test:
  Michael Kinney 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=f6c8e67db9233562fd3ddc6bf7d23f0bb5fb115b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
f6c8e67db9233562fd3ddc6bf7d23f0bb5fb115b
+ branch=ovmf
+ revision=f6c8e67db9233562fd3ddc6bf7d23f0bb5fb115b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xf6c8e67db9233562fd3ddc6bf7d23f0bb5fb115b = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ :

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

2016-10-07 Thread osstest service owner

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf f9c3b1b5343f53705f1ab72c55c1db440b01f36f
baseline version:
 ovmf e8a70885d8f34533b6dd69878fe95a249e9af086

Last test of basis   101303  2016-10-06 04:53:09 Z1 days
Testing same since   101327  2016-10-07 17:48:18 Z0 days1 attempts


People who touched revisions under test:
  Giri P Mudusuru 
  Vladimir Olovyannikov 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=f9c3b1b5343f53705f1ab72c55c1db440b01f36f
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
f9c3b1b5343f53705f1ab72c55c1db440b01f36f
+ branch=ovmf
+ revision=f9c3b1b5343f53705f1ab72c55c1db440b01f36f
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xf9c3b1b5343f53705f1ab72c55c1db440b01f36f = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ :

[Xen-devel] [qemu-mainline test] 101325: trouble: blocked/broken/fail/pass

2016-10-07 Thread osstest service owner

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

Failures and problems with tests :-(

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

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-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-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 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-xsm 12 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu48f592118ab42f83a1a7561c4bfd2b72a100f241
baseline version:
 qemuue902754e3d0890945ddcc1b33748ed73762ddb8d

Last test of basis   101317  2016-10-06 19:45:44 Z1 days
Testing same since   101325  2016-10-07 15:16:42 Z0 days1 attempts


People who touched revisions under test:
  Ed Maste 
  Peter Maydell 

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-pvopsbroken  
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  blocked 
 test-amd64-i386-xl   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-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-xl-xsm  pass
 test-armhf-armhf-xl-xsm  blocked 
 test-amd64-i386-xl-xsm   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64

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

2016-10-07 Thread osstest service owner

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 101320
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101320
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101320
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101320
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101320
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101320

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

version targeted for testing:
 xen  84c1e7d8017c773c41d6e8b79384f37a67be1479
baseline version:
 xen  9f5eff08a6a6f58645fb48382c843973674042c9

Last test of basis   101320  2016-10-07 01:58:11 Z0 days
Testing same since   101324  2016-10-07 12:44:47 Z0 days1 attempts


People who touched revisions under test:
  Lan Tianyu 
  Razvan Cojocaru 

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

Re: [Xen-devel] IRC Meeting Logs Mon October 3, 2016

2016-10-07 Thread Jesus M. Gonzalez-Barahona

No problem with file extensions. Text is text ;-) Thanks!

[Well, maybe utf-8 encoding would be nice, but our conversations being
English, old good ASCII would be perfect as well]

Jesus.

On Fri, 2016-10-07 at 13:30 -0400, tevin.k.mall...@gmail.com wrote:
> Sorry about that Jesus. Is there a file type you prefer to have the
> logs in? I have it attached to this email in .txt . If you like for
> me to change it let me know.
>  
> Sent from Mail for Windows 10
>  
> From: Jesus M. Gonzalez-Barahona
> Sent: Friday, October 7, 2016 11:59 AM
> To: tevin.k.mall...@gmail.com; Lars Kurth
> Cc: Xen-Devel@Lists. Xenproject. Org
> Subject: Re: IRC Meeting Logs Mon October 3, 2016
>  
> On Fri, 2016-10-07 at 11:24 -0400, tevin.k.mall...@gmail.com wrote:
> > Hello Jesus and Lars, as requested here are the logs from today's
> IRC
> > meeting. It was really helpful to have your input Jesus, since you
> > have a lot of experience. I'm confident things will run smoothly as
> I
> > continue my micro-task. I really appreciate your guidance, and the
> > time you spent with me today.
> >  
> > -Tevin Mallory
>  
> Thanks, Tevin!
>  
> Usually, a text version is more useful. Please find one for our
> session
> below. If your IM program doesn't allow for saving sessions, usually
> you can just copy & paste from it to get this text version.
>  
> Saludos,
>  
>     Jesus.
>  
> ---
> (04:33:18 PM) tmallory: Hello Everyone, I am Tevin Mallory. How are
> you
> all doing today?
> (04:34:13 PM) jgbarah: Hi Tevin!
> (04:34:50 PM) jgbarah: tmallory: How do you do? Is the hurricane
> being
> a problem?
> (04:35:41 PM) jgbarah: tmallory: Are you there?
> (04:36:02 PM) tmallory: I am doing well so far, the hurrican hasn't
> hit
> my area yet.
> (04:37:09 PM) jgbarah: ok. I hope it doesn't become a big problem for
> you...
> (04:37:24 PM) jgbarah: Anyway, could you have a look a the microtask
> description?
> (04:37:55 PM) tmallory: Thank you. I hope so as well. I have the
> microtask description in fornt me.
> (04:38:51 PM) tmallory: I started on it yesterday and have been
> installing the requirements for perceval
> (04:39:14 PM) jgbarah: ok. I have to leave in 10 min, but will be
> back
> in 30, so let's start, and if needed and you can, we can follow up
> later
> (04:39:25 PM) jgbarah: Good. Any trouuble with Perceval?
> (04:39:45 PM) tmallory: Okay
> (04:40:25 PM) tmallory: I haven't started using Perceval yet, but i
> shouldn't have any trouble with it.
> (04:41:33 PM) tmallory: I just started learning python a little while
> ago, so i spent a great amount of time getting a good grasp
> (04:42:07 PM) jgbarah: OK. The other stuff that could block you is
> installing ElasticSearch and maybe Kibana. I would start with
> ElasticSearch, which is all you'll need for onow
> (04:42:37 PM) tmallory: Ok i'll work on installing that next
> (04:42:37 PM) jgbarah: ok, let me know if you need some help for
> Python. I can point you to courses and material if you happen to need
> those
> (04:43:03 PM) jgbarah: For elasticSearch, you'll mainly need a
> working
> Java vm on your computer, not much more than that.
> (04:43:51 PM) tmallory: Okay I'am taking note of that
> (04:44:22 PM) jgbarah: Can I help you in some way now, or you're on
> your way?
> (04:45:17 PM) tmallory: I am pretty much on my way.
> (04:45:33 PM) tmallory: no major problems
> (04:45:49 PM) jgbarah: Perfect. Then, maybe we can just schedule a
> meeting for next week
> (04:45:59 PM) jgbarah: Meanwhile you can ping me here, or via email
> (04:46:13 PM) tmallory: Ok. perfect
> (04:46:57 PM) jgbarah: For the meeting here, we can consider
> tentatively next Friday, but 45 min. later
> (04:47:03 PM) jgbarah: Is that ok with you?
> (04:47:18 PM) tmallory: yes it is great
> (04:47:20 PM) jgbarah: I guess that would be 17:15 CEST, 11:15am EST
> (04:47:26 PM) jgbarah: Good!
> (04:47:51 PM) jgbarah: There is a slight chance that I cannot make
> that
> time, in that case I will suggest meeting a bit later
> (04:47:57 PM) jgbarah: Anthing else from your side?
> (04:48:32 PM) tmallory: No I am all green lights on my side, if
> anything comes up I'll let you know
> (04:49:22 PM) tmallory: Thank you for your time.
> (04:49:38 PM) jgbarah: Perfect! It was great meeting you. See you
> next
> week! If you don't mind, please send Lars and me the log for his
> meeting via email
> (04:50:32 PM) tmallory: No problem, I'll send it right away.
> (04:50:52 PM) tmallory: It was great meeting with you as well.
> (04:51:01 PM) jgbarah: Thanks! See you. Bye for now!
>  
> --
> Bitergia: http://bitergia.com
> /me at Twitter: https://twitter.com/jgbarah
>  
>  
-- 
Bitergia: http://bitergia.com
/me at Twitter: https://twitter.com/jgbarah


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

Re: [Xen-devel] [PATCH v1 1/1] xen/arm: Disable the Cortex-a53-edac

2016-10-07 Thread Wei Liu

On Fri, Oct 07, 2016 at 10:34:15AM -0700, Stefano Stabellini wrote:
> On Fri, 7 Oct 2016, Alistair Francis wrote:
> > On Thu, Oct 6, 2016 at 9:36 AM, Edgar E. Iglesias
> >  wrote:
> > > From: "Edgar E. Iglesias" 
> > >
> > > Disable the Cortex-a53-edac. Xen currently does not yet
> > > handle reads/writes to the implementation defined CPUMERRSR
> > > register.
> > >
> > > Signed-off-by: Edgar E. Iglesias 
> > 
> > This solution looks fine to me and everything boots on ZynqMP as
> > expected with this patch.
> > 
> > Acked-by: Alistair Francis 
> 
> Reviewed-by: Stefano Stabellini 
> 
> Wei, can we have this in 4.8? See the 0/1 email for an explanation of
> why this change is needed. The patch just adds the troublesome
> cortex-a15-pmu to the "skip_matches" array to remove it from dom0's
> device tree.
> 

Sure.

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

Re: [Xen-devel] [PATCH] fix EFI part of "symbols: Generate an xen-sym.map"

2016-10-07 Thread Stefano Stabellini

On Wed, 21 Sep 2016, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 21, 2016 at 10:04:21AM -0600, Jan Beulich wrote:
> > >>> On 21.09.16 at 17:59,  wrote:
> > > The fix can be done two ways:
> > >  a) See if xen.efi.map exists and then copy it
> > >  b) Or link xen.efi.map to xen-syms.map (similar to how xen.efi is linked
> > > against xen).
> > > 
> > > The patch chooses the latter.
> > 
> > Well, if the ARM maintainers like that ... I don't really see a point in
> > installing the same file twice without its second incarnation having a
> > specific purpose.
> 
> I also have the a) part ready, which is simple:
> 
> 
> diff --git a/xen/Makefile b/xen/Makefile
> index e989a20..678f188 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -67,7 +67,9 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
>   if [ -r $(TARGET).efi -a -n '$(EFI_DIR)' ]; then \
>   [ -d $(D)$(EFI_DIR) ] || $(INSTALL_DIR) $(D)$(EFI_DIR); \
>   $(INSTALL_DATA) $(TARGET).efi 
> $(D)$(EFI_DIR)/$(T)-$(XEN_FULLVERSION).efi; \
> - $(INSTALL_DATA) $(TARGET).efi.map 
> $(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map; \
> +if [ -e $(TARGET).efi.map ]; then \
> + $(INSTALL_DATA) $(TARGET).efi.map 
> $(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map; \
> +fi; \
>   ln -sf $(T)-$(XEN_FULLVERSION).efi 
> $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).$(XEN_SUBVERSION).efi; \
>   ln -sf $(T)-$(XEN_FULLVERSION).efi 
> $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).efi; \
>   ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T).efi; \
> 
> Either fix works.

This is fine.

Reviewed-by: Stefano Stabellini 

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

Re: [Xen-devel] [PATCH v1 1/1] xen/arm: Disable the Cortex-a53-edac

2016-10-07 Thread Stefano Stabellini

On Fri, 7 Oct 2016, Alistair Francis wrote:
> On Thu, Oct 6, 2016 at 9:36 AM, Edgar E. Iglesias
>  wrote:
> > From: "Edgar E. Iglesias" 
> >
> > Disable the Cortex-a53-edac. Xen currently does not yet
> > handle reads/writes to the implementation defined CPUMERRSR
> > register.
> >
> > Signed-off-by: Edgar E. Iglesias 
> 
> This solution looks fine to me and everything boots on ZynqMP as
> expected with this patch.
> 
> Acked-by: Alistair Francis 

Reviewed-by: Stefano Stabellini 

Wei, can we have this in 4.8? See the 0/1 email for an explanation of
why this change is needed. The patch just adds the troublesome
cortex-a15-pmu to the "skip_matches" array to remove it from dom0's
device tree.


> > ---
> >  xen/arch/arm/domain_build.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index ce97359..e8a400c 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -1188,6 +1188,7 @@ static int handle_node(struct domain *d, struct 
> > kernel_info *kinfo,
> >  DT_MATCH_COMPATIBLE("arm,psci-1.0"),
> >  DT_MATCH_COMPATIBLE("arm,cortex-a7-pmu"),
> >  DT_MATCH_COMPATIBLE("arm,cortex-a15-pmu"),
> > +DT_MATCH_COMPATIBLE("arm,cortex-a53-edac"),
> >  DT_MATCH_COMPATIBLE("arm,armv8-pmuv3"),
> >  DT_MATCH_PATH("/cpus"),
> >  DT_MATCH_TYPE("memory"),
> > --
> > 2.5.0
> >
> >
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > https://lists.xen.org/xen-devel
> 

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

Re: [Xen-devel] IRC Meeting Logs Mon October 3, 2016

2016-10-07 Thread tevin.k.mallory

Sorry about that Jesus. Is there a file type you prefer to have the logs in? I 
have it attached to this email in .txt . If you like for me to change it let me 
know. 

Sent from Mail for Windows 10

From: Jesus M. Gonzalez-Barahona
Sent: Friday, October 7, 2016 11:59 AM
To: tevin.k.mall...@gmail.com; Lars Kurth
Cc: Xen-Devel@Lists. Xenproject. Org
Subject: Re: IRC Meeting Logs Mon October 3, 2016

On Fri, 2016-10-07 at 11:24 -0400, tevin.k.mall...@gmail.com wrote:
> Hello Jesus and Lars, as requested here are the logs from today's IRC
> meeting. It was really helpful to have your input Jesus, since you
> have a lot of experience. I'm confident things will run smoothly as I
> continue my micro-task. I really appreciate your guidance, and the
> time you spent with me today.
>  
> -Tevin Mallory

Thanks, Tevin!

Usually, a text version is more useful. Please find one for our session
below. If your IM program doesn't allow for saving sessions, usually
you can just copy & paste from it to get this text version.

Saludos,

Jesus.

---
(04:33:18 PM) tmallory: Hello Everyone, I am Tevin Mallory. How are you
all doing today?
(04:34:13 PM) jgbarah: Hi Tevin!
(04:34:50 PM) jgbarah: tmallory: How do you do? Is the hurricane being
a problem?
(04:35:41 PM) jgbarah: tmallory: Are you there?
(04:36:02 PM) tmallory: I am doing well so far, the hurrican hasn't hit
my area yet.
(04:37:09 PM) jgbarah: ok. I hope it doesn't become a big problem for
you...
(04:37:24 PM) jgbarah: Anyway, could you have a look a the microtask
description?
(04:37:55 PM) tmallory: Thank you. I hope so as well. I have the
microtask description in fornt me.
(04:38:51 PM) tmallory: I started on it yesterday and have been
installing the requirements for perceval
(04:39:14 PM) jgbarah: ok. I have to leave in 10 min, but will be back
in 30, so let's start, and if needed and you can, we can follow up
later
(04:39:25 PM) jgbarah: Good. Any trouuble with Perceval?
(04:39:45 PM) tmallory: Okay
(04:40:25 PM) tmallory: I haven't started using Perceval yet, but i
shouldn't have any trouble with it.
(04:41:33 PM) tmallory: I just started learning python a little while
ago, so i spent a great amount of time getting a good grasp
(04:42:07 PM) jgbarah: OK. The other stuff that could block you is
installing ElasticSearch and maybe Kibana. I would start with
ElasticSearch, which is all you'll need for onow
(04:42:37 PM) tmallory: Ok i'll work on installing that next
(04:42:37 PM) jgbarah: ok, let me know if you need some help for
Python. I can point you to courses and material if you happen to need
those
(04:43:03 PM) jgbarah: For elasticSearch, you'll mainly need a working
Java vm on your computer, not much more than that.
(04:43:51 PM) tmallory: Okay I'am taking note of that
(04:44:22 PM) jgbarah: Can I help you in some way now, or you're on
your way?
(04:45:17 PM) tmallory: I am pretty much on my way.
(04:45:33 PM) tmallory: no major problems
(04:45:49 PM) jgbarah: Perfect. Then, maybe we can just schedule a
meeting for next week
(04:45:59 PM) jgbarah: Meanwhile you can ping me here, or via email
(04:46:13 PM) tmallory: Ok. perfect
(04:46:57 PM) jgbarah: For the meeting here, we can consider
tentatively next Friday, but 45 min. later
(04:47:03 PM) jgbarah: Is that ok with you?
(04:47:18 PM) tmallory: yes it is great
(04:47:20 PM) jgbarah: I guess that would be 17:15 CEST, 11:15am EST
(04:47:26 PM) jgbarah: Good!
(04:47:51 PM) jgbarah: There is a slight chance that I cannot make that
time, in that case I will suggest meeting a bit later
(04:47:57 PM) jgbarah: Anthing else from your side?
(04:48:32 PM) tmallory: No I am all green lights on my side, if
anything comes up I'll let you know
(04:49:22 PM) tmallory: Thank you for your time.
(04:49:38 PM) jgbarah: Perfect! It was great meeting you. See you next
week! If you don't mind, please send Lars and me the log for his
meeting via email
(04:50:32 PM) tmallory: No problem, I'll send it right away.
(04:50:52 PM) tmallory: It was great meeting with you as well.
(04:51:01 PM) jgbarah: Thanks! See you. Bye for now!
 
-- 
Bitergia: http://bitergia.com
/me at Twitter: https://twitter.com/jgbarah



Session Start: Mon Oct 03 17:36:20 2016
Session Ident: #metrics-grimoire
03[17:36] * Now talking in #metrics-grimoire
02[17:40] * gayathri___ (uid69915@gateway/web/irccloud.com/x-zbftnjrevqetnmfh) 
Quit (Quit: Connection closed for inactivity)
03[19:48] * _acs_ (~a...@114.red-79-153-216.dynamicip.rima-tde.net) has joined 
#metrics-grimoire
02[20:00] * _acs_ (~a...@114.red-79-153-216.dynamicip.rima-tde.net) Quit 
(Quit: Leaving.)
02[20:11] * jgbarah (~j...@149.red-79-151-31.dynamicip.rima-tde.net) Quit 
(Ping timeout: 248 seconds)
02[21:56] * Disconnected
Session Close: Mon Oct 03 21:56:33 2016

Session Start: Mon Oct 03 21:56:33 2016
Session Ident: #metrics-grimoire
02[21:56] * Attempting to rejoin channel #metrics-grimoire
03[21:56] * Rejoined

[Xen-devel] [OSSTEST PATCH 12/16] rumprun: Disable unwanted builds

2016-10-07 Thread Ian Jackson

Signed-off-by: Ian Jackson 
---
 make-flight | 8 
 1 file changed, 8 insertions(+)

diff --git a/make-flight b/make-flight
index 17c3ce1..1c53737 100755
--- a/make-flight
+++ b/make-flight
@@ -83,6 +83,14 @@ job_create_build_filter_callback () {
 *) return 1 ;;
   esac
 ;;
+rumprun)
+  case "$job" in
+build-*-pvops) ;;
+build-*-rumprun)   ;;
+build-*-*) return 1 ;;
+*) ;;
+  esac
+;;
   esac
   return 0
 }
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 09/16] rump kernels: Provide networking test

2016-10-07 Thread Ian Jackson

Introduce our own version of `nc -e echo', to replace the removed rump
kernel WOPR test (which we were using to check that networking
worked).

This test program works when compiled on Linux too.

Signed-off-by: Ian Jackson 
---
 make-flight   |  4 ++--
 sg-run-job|  6 +
 ts-rumprun-demo-build | 66 +++
 3 files changed, 74 insertions(+), 2 deletions(-)
 create mode 100755 ts-rumprun-demo-build

diff --git a/make-flight b/make-flight
index 9b47999..17c3ce1 100755
--- a/make-flight
+++ b/make-flight
@@ -219,8 +219,8 @@ do_rumpkernel_tests () {
   test-rumprun xl \
 $xenarch $dom0arch   \
 guests_rumprunbuildjob=build-$rumparch-rumprun   \
- rump_builtimage=rumprun:/usr/local/lib/xen/rump-kernel/rump-kernel \
-rump_cmdline=3   \
+nettest_builtimage=rumpimages:nettest \
+nettest_cmdline=4096 \
 xenstorels_builtimage=rumpimages:xenstorels  \
 xenstorels_cmdline='ls -fp device'   \
 all_hostflags=$most_hostflags
diff --git a/sg-run-job b/sg-run-job
index e4e4e75..967c486 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -460,6 +460,10 @@ proc test-guest-nomigr {g} {
 
 proc need-hosts/test-rumprun {} { return host }
 proc run-job/test-rumprun {} {
+set g nettest
+run-ts . =   ts-rumprun-demo-setup + host $g
+run-ts . =   ts-guest-start+ host $g
+run-ts . =   ts-guest-destroy  + host $g
 set g xenstorels
 run-ts . =   ts-rumprun-demo-setup  + host + $g
 run-ts . =   ts-rumprun-demo-xenstorels + host + $g
@@ -495,8 +499,10 @@ proc run-job/build-libvirt {} {
 
 proc run-job/build-rumprun {} {
 run-ts . = ts-rumprun-build
+run-ts . = ts-rumprun-demo-build + host + nettest rump-test-net
 run-ts . = ts-xen-build + host --no-kconfig tools
 run-ts . = ts-rumprun-bake + host \
+nettest :nettest:/rump-test-net \
 xenstorels ::/usr/local/bin/xenstore-ls
 }
 
diff --git a/ts-rumprun-demo-build b/ts-rumprun-demo-build
new file mode 100755
index 000..c653d5b
--- /dev/null
+++ b/ts-rumprun-demo-build
@@ -0,0 +1,66 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2013 Citrix Inc.
+# 
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+# 
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see .
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use File::Path;
+use POSIX;
+use Osstest::TestSupport;
+use Osstest::BuildSupport;
+
+tsreadconfig();
+selectbuildhost(\@ARGV);
+
+our $dokconfig = 1;
+
+while (@ARGV && $ARGV[0] =~ m/^-/) {
+$_ = shift @ARGV;
+last if m/^--$/;
+die "$_ ?";
+}
+# remaining arguments are passed as targets to "make"
+
+die unless @ARGV==2;
+my ($demo,$bn) = @ARGV;
+
+builddirsprops();
+
+my $demodir;
+
+sub build () {
+prepbuilddirs($demo);
+
+$demodir = "$builddir/$demo";
+
+target_putfile($ho, 30, "$bn.c", "$demodir/$bn.c");
+
+my $make_prefix =  $r{cmdprefix_make}  // '';
+
+target_cmd_build($ho, 300, $demodir, <

[Xen-devel] [OSSTEST PATCH 10/16] TestSupport: guest_unprepare_disk: Make a no-op for guests with no Lvdev

2016-10-07 Thread Ian Jackson

This includes some rump kernel tests.

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

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index bc3ad13..a63ff26 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1601,6 +1601,7 @@ END
 
 sub guest_unprepare_disk ($) {
 my ($gho) = @_;
+return unless defined $gho->{Lvdev};
 return if $gho->{Diskfmt} eq "none";
 target_cmd_root($gho->{Host}, <{Lvdev} || :
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 15/16] make-flight: Honour $bfi (build flight) for rump tests

2016-10-07 Thread Ian Jackson

A quick search suggests there are other a similar bugs...

Signed-off-by: Ian Jackson 
---
 make-flight | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/make-flight b/make-flight
index 1c53737..c236f49 100755
--- a/make-flight
+++ b/make-flight
@@ -226,7 +226,7 @@ do_rumpkernel_tests () {
   job_create_test test-$xenarch$kern-$dom0arch-rumprun-$rumparch \
   test-rumprun xl \
 $xenarch $dom0arch   \
-guests_rumprunbuildjob=build-$rumparch-rumprun   \
+guests_rumprunbuildjob=${bfi}build-$rumparch-rumprun   \
 nettest_builtimage=rumpimages:nettest \
 nettest_cmdline=4096 \
 xenstorels_builtimage=rumpimages:xenstorels  \
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 16/16] rump kernels: Build with RUMP_DEV_XEN_DEBUG and filter out debug messages

2016-10-07 Thread Ian Jackson

Signed-off-by: Ian Jackson 
---
 ts-rumprun-build   | 5 -
 ts-rumprun-demo-xenstorels | 2 ++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/ts-rumprun-build b/ts-rumprun-build
index 1913f29..f408359 100755
--- a/ts-rumprun-build
+++ b/ts-rumprun-build
@@ -44,7 +44,10 @@ sub massage() {
 }
 
 sub build() {
-target_cmd_build($ho, 7200, $rux, <

[Xen-devel] [OSSTEST PATCH 14/16] rump kernels: Install binutils on test box

2016-10-07 Thread Ian Jackson

The `rumprun' tool needs `readelf' which is in binutils.

This introduces a new test step, which is idempotent.

Signed-off-by: Ian Jackson 
---
 sg-run-job   |  1 +
 ts-rumprun-test-prep | 36 
 2 files changed, 37 insertions(+)
 create mode 100755 ts-rumprun-test-prep

diff --git a/sg-run-job b/sg-run-job
index 61cb369..57080e7 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -460,6 +460,7 @@ proc test-guest-nomigr {g} {
 
 proc need-hosts/test-rumprun {} { return host }
 proc run-job/test-rumprun {} {
+run-ts . =   ts-rumprun-test-prep   + host
 set g nettest
 run-ts . =   ts-rumprun-demo-setup  + host $g
 run-ts . =   ts-guest-start + host $g
diff --git a/ts-rumprun-test-prep b/ts-rumprun-test-prep
new file mode 100755
index 000..60be5f4
--- /dev/null
+++ b/ts-rumprun-test-prep
@@ -0,0 +1,36 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2013 Citrix Inc.
+# 
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+# 
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see .
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use POSIX;
+use Osstest::TestSupport;
+use Osstest::Debian;
+
+tsreadconfig();
+
+our ($whhost) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+
+sub packages () {
+target_install_packages($ho,
+   qw(binutils));
+}
+
+packages();
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 13/16] rump kernels: Adjust indentation in run-job/test-rumprun

2016-10-07 Thread Ian Jackson

Whitespace change only.

Signed-off-by: Ian Jackson 
---
 sg-run-job | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/sg-run-job b/sg-run-job
index 967c486..61cb369 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -461,16 +461,16 @@ proc test-guest-nomigr {g} {
 proc need-hosts/test-rumprun {} { return host }
 proc run-job/test-rumprun {} {
 set g nettest
-run-ts . =   ts-rumprun-demo-setup + host $g
-run-ts . =   ts-guest-start+ host $g
-run-ts . =   ts-guest-destroy  + host $g
+run-ts . =   ts-rumprun-demo-setup  + host $g
+run-ts . =   ts-guest-start + host $g
+run-ts . =   ts-guest-destroy   + host $g
 set g xenstorels
 run-ts . =   ts-rumprun-demo-setup  + host + $g
 run-ts . =   ts-rumprun-demo-xenstorels + host + $g
-run-ts . =   ts-guest-destroy-hard  + host + $g
+run-ts . =   ts-guest-destroy-hard  + host + $g
 repeat-ts 150 =.repeat \
  ts-rumprun-demo-xenstorels + host + $g   + \; \
- ts-guest-destroy-hardhost   $g   +
+ ts-guest-destroy-hardhost   $g   +
 }
 
 if {[file exists sg-run-job-adhoc]} {
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 11/16] rumprun: xenstorels: Better new regexps for finding output

2016-10-07 Thread Ian Jackson

There is no need to match the _exit.  We can match the main return as
before, provided we tolerate the way it now says
   main() of "program" returned 0

This is an update to ea13503bc853 "rumprun: xenstorels: New regexps
for finding output" (which was insufficient to get the xenstorels test
to pass).

Signed-off-by: Ian Jackson 
---
 ts-rumprun-demo-xenstorels | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/ts-rumprun-demo-xenstorels b/ts-rumprun-demo-xenstorels
index 3d29c46..b5f3b28 100755
--- a/ts-rumprun-demo-xenstorels
+++ b/ts-rumprun-demo-xenstorels
@@ -80,8 +80,7 @@ sub their_xenstorels () {
while ($output{theirs} =~ m{\n=== calling ".*" main\(\) ===\n\n}) {
$output{theirs} = $'; #';
}
-   $output{theirs} =~ m{\n=== main\(\) returned (\d+) ===\n} or
-   $output{theirs} =~ m{\n=== ERROR: _exit\((\d+)\) called ===\n} or die;
+   $output{theirs} =~ m{\n=== main\(\) .* returned (\d+) ===\n} or die;
$output{theirs} = $`;
die "EXIT STATUS $1 ?" if $1 ne '0';
$output{theirs} =~ s{^STUB \`\`\w+'' called\n}{}mg;
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 08/16] rump kernels: Provide proper DHCP instructions to rumprun

2016-10-07 Thread Ian Jackson

Otherwise we just get an unconfigured network interface.  (Requesting
DHCP used to be implicit.)

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

diff --git a/Osstest/RumpRun.pm b/Osstest/RumpRun.pm
index 0582bd2..f46d520 100644
--- a/Osstest/RumpRun.pm
+++ b/Osstest/RumpRun.pm
@@ -57,7 +57,8 @@ sub rumprun_guest_create ($) {
 
 my $cmd = "$rumprun xen";
 $cmd .= " -N $gn";
-$cmd .= " -IIFTAG,IFBASENAME,mac=$gho->{Ether}";
+$cmd .= " -I xenif0,xenif,mac=$gho->{Ether}";
+$cmd .= " -W xenif0,inet,dhcp";
 $cmd .= " $imagepath";
 $cmd .= " $cmdline";
 
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 07/16] rump kernels: ts-rumprun-bake: Do not tolerate errors

2016-10-07 Thread Ian Jackson

If we skip due to missing the input pieces, make the warning noiser.

If we think we have all the input pieces, bomb out if they don't seem
to contain the right bits, or if rumpbake fails.

Signed-off-by: Ian Jackson 
---
 ts-rumprun-bake | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/ts-rumprun-bake b/ts-rumprun-bake
index d79d6f8..31ce259 100755
--- a/ts-rumprun-bake
+++ b/ts-rumprun-bake
@@ -61,15 +61,14 @@ sub bakeimage ($$) {
($ho, "rumpbake-n-$name", $execpart, $buildjob || $job);
 };
 if ($@) {
-   warn "skipping: $@";
+   logm "*** WARNING: skipping $name: $@";
return;
 }
 my $execfile = $execdist.$execpath;
 
 target_cmd_build($ho, 1000, $imagesdir, <=2;
 my $name = shift @ARGV;
 my $rumpexec = shift @ARGV;
-eval {
-   bakeimage($name,$rumpexec);
-};
+
+bakeimage($name,$rumpexec);
 }
 
 stash();
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 06/16] rump kernels: Specify toolstack for rumprun demo to be rumprun

2016-10-07 Thread Ian Jackson

This causes ts-guest-start to use rumprun, rather than xl.

Signed-off-by: Ian Jackson 
---
 ts-rumprun-demo-setup | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ts-rumprun-demo-setup b/ts-rumprun-demo-setup
index 212d758..b99c6f8 100755
--- a/ts-rumprun-demo-setup
+++ b/ts-rumprun-demo-setup
@@ -47,6 +47,7 @@ sub prep () {
 my $imagepath = $rkdist.'/'.$builtimage_subpath;
 
 store_runvar("${gn}_imagepath", $imagepath);
+store_runvar("${gn}_toolstack", 'rumprun');
 }
 
 prep();
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 04/16] Support guest-specific "toolstack" for guest creation

2016-10-07 Thread Ian Jackson

Some guests need creation in a special way.  For example, rump kernels
are ideally started with rumprun.  Honour a guest var which specifies
a toolstack name.

Osstest::TestSupport::toolstack now takes an optional $gho so it can
do this lookup when appropriate.

After creation the guest is necessarily managed with the toolstack for
the host, so we honour this (ie we pass the $gho) only for create.

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

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index b18a19e..bc3ad13 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1583,7 +1583,7 @@ sub guest_create ($) {
 my ($gho) = @_;
 my $ho = $gho->{Host};
 guest_prepare_disk($gho);
-toolstack($ho)->create($gho);
+toolstack($ho,$gho)->create($gho);
 }
 
 sub guest_prepare_disk ($) {
@@ -2257,13 +2257,16 @@ sub guest_vncsnapshot_stash () {
 target_getfile_root($ho,100, "$rfile", "$stash/$leaf");
 }
 
-sub toolstack ($) {
-my ($ho) = @_;
-return $ho->{_Toolstack} if $ho->{_Toolstack};
+sub toolstack ($;$) {
+my ($ho,$gho) = @_;
+
+my $cache = $gho || $ho;
+return $cache->{_Toolstack} if $cache->{_Toolstack};
 
 my $tsname= $r{toolstack} || 'xend';
-$ho->{_Toolstack}= get_host_method_object($ho, 'Toolstack', $tsname);
-return $ho->{_Toolstack};
+$tsname= guest_var($gho, 'toolstack', $tsname) if $gho;
+$cache->{_Toolstack} = get_host_method_object($ho, 'Toolstack', $tsname);
+return $cache->{_Toolstack};
 }
 
 sub authorized_keys () {
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 02/16] rump-test-net: setsockopt V6ONLY off

2016-10-07 Thread Ian Jackson

NetBSD (unlike Linux) has the V6ONLY socket option turned on by
default.  So to work in the rump kernel environment when tested with
IPv4 we need to adjust this setting.

Signed-off-by: Ian Jackson 
---
 rump-test-net.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/rump-test-net.c b/rump-test-net.c
index 96dbb1c..486a261 100644
--- a/rump-test-net.c
+++ b/rump-test-net.c
@@ -21,6 +21,10 @@ int main(int argc, const char *const *argv) {
 master = socket(AF_INET6,SOCK_STREAM,0);
 if (master<0) { perror("socket"); exit(-1); }
 
+int no = 0;
+r = setsockopt(master, IPPROTO_IPV6, IPV6_V6ONLY, (void*), sizeof(no));
+if (r<0) { perror("IPV6_V6ONLY"); exit(-1); }
+
 int port = atoi(argv[1]);
 
 memset(,0,sizeof(sin6));
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 00/16] Fix rump kernel tests

2016-10-07 Thread Ian Jackson

With these 16 patches, we complete osstest's adaptation to the modern
rumprun-based way of setting up and running rump kernel programs.

We replace the old networking test (based on the WOPR example, now
removed from rump upstream) with our own test program.  The net test
should start working right away.

The xenstore-ls test has been broken by bitrot in the rumprun tree.
It requires a corresponding rumprun patch series, which I am about to
feed as a pull request to rumprun upstream.

The longstanding low-probability scheduler lockup bug remains
outstanding.

Ian.

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

[Xen-devel] [OSSTEST PATCH 01/16] rump-test-net: New test program

2016-10-07 Thread Ian Jackson

The rump kernel WOPR test is no more, so we reimplement it.  This test
program simply listens on a TCP socket and says hi when you connect to
it.  It's a portable program.  So far, this has been tested on Linux,
but not in the rump environment.

Signed-off-by: Ian Jackson 
---
 rump-test-net.c | 65 +
 1 file changed, 65 insertions(+)
 create mode 100644 rump-test-net.c

diff --git a/rump-test-net.c b/rump-test-net.c
new file mode 100644
index 000..96dbb1c
--- /dev/null
+++ b/rump-test-net.c
@@ -0,0 +1,65 @@
+/*
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int master;
+
+int main(int argc, const char *const *argv) {
+struct sockaddr_in6 sin6;
+int r;
+
+assert(argc==2);
+
+master = socket(AF_INET6,SOCK_STREAM,0);
+if (master<0) { perror("socket"); exit(-1); }
+
+int port = atoi(argv[1]);
+
+memset(,0,sizeof(sin6));
+sin6.sin6_family = AF_INET6;
+sin6.sin6_port = htons(port);
+sin6.sin6_addr = in6addr_any;
+
+r = bind(master,(struct sockaddr*),sizeof(sin6));
+if (r) { perror("bind"); exit(-1); }
+
+r = listen(master,5);
+if (r) { perror("listen"); exit(-1); }
+
+fprintf(stderr,"listening on %d\n",port);
+
+int slave = -1;
+for (;;) {
+   static const char message[] = "hello\r\n";
+   static const int messagel = sizeof(message)-1;
+
+   if (slave > 0) close(slave);
+
+   slave = accept(master,0,0);
+   if (slave < 0) { perror("accept"); continue; }
+
+   r = fcntl(slave, F_GETFL);
+   if (r < 0) { perror("F_GETFL"); continue; }
+   r = fcntl(slave, F_SETFL, r | O_NONBLOCK);
+   if (r < 0) { perror("F_SETFL"); continue; }
+
+   r = write(slave, message, messagel);
+   if (r < 0) { perror("write"); continue; }
+   else if (r != messagel) {
+   fprintf(stderr,"write: %d (!= %d",r,messagel);
+   continue;
+   }
+
+   r = close(slave);
+   slave = -1;
+   if (r < 0) { perror("close"); continue; }
+}
+}
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 05/16] rump kernels: Provide rumprun toolstack

2016-10-07 Thread Ian Jackson

This is suitable as a guest-specific toolstack: it defers to xl for
everything other than guest creation.

Signed-off-by: Ian Jackson 
---
 Osstest/Toolstack/rumprun.pm | 33 +
 1 file changed, 33 insertions(+)
 create mode 100644 Osstest/Toolstack/rumprun.pm

diff --git a/Osstest/Toolstack/rumprun.pm b/Osstest/Toolstack/rumprun.pm
new file mode 100644
index 000..74742c4
--- /dev/null
+++ b/Osstest/Toolstack/rumprun.pm
@@ -0,0 +1,33 @@
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2014 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see .
+
+
+package Osstest::Toolstack::rumprun;
+
+use strict;
+use warnings;
+
+use Osstest::RumpRun;
+
+# Defer to xl driver for most things
+use parent qw(Osstest::Toolstack::xl);
+
+sub create ($$) {
+my ($self,$gho) = @_;
+rumprun_guest_create($gho);
+}
+
+1;
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 03/16] BuildSupport: builddirsprops: Clean up each builddir

2016-10-07 Thread Ian Jackson

This makes prepbuilddirs work if it is run a second time for the same
builddirs, which is useful for ad-hoc testing.

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

diff --git a/Osstest/BuildSupport.pm b/Osstest/BuildSupport.pm
index d005ca9..7e114cf 100644
--- a/Osstest/BuildSupport.pm
+++ b/Osstest/BuildSupport.pm
@@ -91,7 +91,8 @@ sub builddirsprops {
 sub prepbuilddirs {
 my (@xbuilddirs) = @_;
 my $cmd = "mkdir -p $builddir && rm -rf $builddir/*-stamp $builddir/dist";
-$cmd .= " && mkdir $builddir/$_" foreach @xbuilddirs;
+$cmd .= " && rm -rf $builddir/$_ && mkdir $builddir/$_"
+   foreach @xbuilddirs;
 target_cmd($ho,$cmd,600);
 }
 
-- 
2.1.4


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

Re: [Xen-devel] Question about VPID during MOV-TO-CR3

2016-10-07 Thread Jan Beulich

>>> On 07.10.16 at 17:41,  wrote:
> There are a ton of calls to flush_area_local, and a good chunk of them
> with the idle vCPU being the active one when it is called. As for
> write_cr3, there are also a lot of calls there. When I added some
> debug output to observe just how many dom0 would take almost an hour
> to boot and the serial line would just be spammed with that printk. So
> even if there no HVM paths leading there, others paths definitely do
> that affect HVM guests by making all of them take on a new tag next
> time they are scheduled.

Well, that's all fine, but - considering what Tim explained in great
detail - not really relevant. We just can't blindly eliminate those
safety flushes. What we can eliminate are just flushes where we
know they're not safety ones, i.e. such initiated by guest CR
updates (or alike), and I'm afraid there aren't that many.

For the safety flushes the best we may be able to do would appear
to be to limit their scope: If we knew which domains can possibly
have active mappings, we could avoid flushing unrelated ASIDs. But
even then we'd have to flush full address spaces, as we don't know
at which _virtual_ address(es) such mappings may have lived (and
there are no mechanisms to flush based on guest or host physical
address).

Jan

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

Re: [Xen-devel] IRC Meeting Logs Mon October 3, 2016

2016-10-07 Thread Jesus M. Gonzalez-Barahona

On Fri, 2016-10-07 at 11:24 -0400, tevin.k.mall...@gmail.com wrote:
> Hello Jesus and Lars, as requested here are the logs from today's IRC
> meeting. It was really helpful to have your input Jesus, since you
> have a lot of experience. I'm confident things will run smoothly as I
> continue my micro-task. I really appreciate your guidance, and the
> time you spent with me today.
>  
> -Tevin Mallory

Thanks, Tevin!

Usually, a text version is more useful. Please find one for our session
below. If your IM program doesn't allow for saving sessions, usually
you can just copy & paste from it to get this text version.

Saludos,

Jesus.

---
(04:33:18 PM) tmallory: Hello Everyone, I am Tevin Mallory. How are you
all doing today?
(04:34:13 PM) jgbarah: Hi Tevin!
(04:34:50 PM) jgbarah: tmallory: How do you do? Is the hurricane being
a problem?
(04:35:41 PM) jgbarah: tmallory: Are you there?
(04:36:02 PM) tmallory: I am doing well so far, the hurrican hasn't hit
my area yet.
(04:37:09 PM) jgbarah: ok. I hope it doesn't become a big problem for
you...
(04:37:24 PM) jgbarah: Anyway, could you have a look a the microtask
description?
(04:37:55 PM) tmallory: Thank you. I hope so as well. I have the
microtask description in fornt me.
(04:38:51 PM) tmallory: I started on it yesterday and have been
installing the requirements for perceval
(04:39:14 PM) jgbarah: ok. I have to leave in 10 min, but will be back
in 30, so let's start, and if needed and you can, we can follow up
later
(04:39:25 PM) jgbarah: Good. Any trouuble with Perceval?
(04:39:45 PM) tmallory: Okay
(04:40:25 PM) tmallory: I haven't started using Perceval yet, but i
shouldn't have any trouble with it.
(04:41:33 PM) tmallory: I just started learning python a little while
ago, so i spent a great amount of time getting a good grasp
(04:42:07 PM) jgbarah: OK. The other stuff that could block you is
installing ElasticSearch and maybe Kibana. I would start with
ElasticSearch, which is all you'll need for onow
(04:42:37 PM) tmallory: Ok i'll work on installing that next
(04:42:37 PM) jgbarah: ok, let me know if you need some help for
Python. I can point you to courses and material if you happen to need
those
(04:43:03 PM) jgbarah: For elasticSearch, you'll mainly need a working
Java vm on your computer, not much more than that.
(04:43:51 PM) tmallory: Okay I'am taking note of that
(04:44:22 PM) jgbarah: Can I help you in some way now, or you're on
your way?
(04:45:17 PM) tmallory: I am pretty much on my way.
(04:45:33 PM) tmallory: no major problems
(04:45:49 PM) jgbarah: Perfect. Then, maybe we can just schedule a
meeting for next week
(04:45:59 PM) jgbarah: Meanwhile you can ping me here, or via email
(04:46:13 PM) tmallory: Ok. perfect
(04:46:57 PM) jgbarah: For the meeting here, we can consider
tentatively next Friday, but 45 min. later
(04:47:03 PM) jgbarah: Is that ok with you?
(04:47:18 PM) tmallory: yes it is great
(04:47:20 PM) jgbarah: I guess that would be 17:15 CEST, 11:15am EST
(04:47:26 PM) jgbarah: Good!
(04:47:51 PM) jgbarah: There is a slight chance that I cannot make that
time, in that case I will suggest meeting a bit later
(04:47:57 PM) jgbarah: Anthing else from your side?
(04:48:32 PM) tmallory: No I am all green lights on my side, if
anything comes up I'll let you know
(04:49:22 PM) tmallory: Thank you for your time.
(04:49:38 PM) jgbarah: Perfect! It was great meeting you. See you next
week! If you don't mind, please send Lars and me the log for his
meeting via email
(04:50:32 PM) tmallory: No problem, I'll send it right away.
(04:50:52 PM) tmallory: It was great meeting with you as well.
(04:51:01 PM) jgbarah: Thanks! See you. Bye for now!
 
-- 
Bitergia: http://bitergia.com
/me at Twitter: https://twitter.com/jgbarah


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

Re: [Xen-devel] [PATCH v1 1/1] xen/arm: Disable the Cortex-a53-edac

2016-10-07 Thread Alistair Francis

On Thu, Oct 6, 2016 at 9:36 AM, Edgar E. Iglesias
 wrote:
> From: "Edgar E. Iglesias" 
>
> Disable the Cortex-a53-edac. Xen currently does not yet
> handle reads/writes to the implementation defined CPUMERRSR
> register.
>
> Signed-off-by: Edgar E. Iglesias 

This solution looks fine to me and everything boots on ZynqMP as
expected with this patch.

Acked-by: Alistair Francis 

Thanks,

Alistair


> ---
>  xen/arch/arm/domain_build.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index ce97359..e8a400c 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1188,6 +1188,7 @@ static int handle_node(struct domain *d, struct 
> kernel_info *kinfo,
>  DT_MATCH_COMPATIBLE("arm,psci-1.0"),
>  DT_MATCH_COMPATIBLE("arm,cortex-a7-pmu"),
>  DT_MATCH_COMPATIBLE("arm,cortex-a15-pmu"),
> +DT_MATCH_COMPATIBLE("arm,cortex-a53-edac"),
>  DT_MATCH_COMPATIBLE("arm,armv8-pmuv3"),
>  DT_MATCH_PATH("/cpus"),
>  DT_MATCH_TYPE("memory"),
> --
> 2.5.0
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] Question about VPID during MOV-TO-CR3

2016-10-07 Thread Tamas K Lengyel

On Fri, Oct 7, 2016 at 9:32 AM, Jan Beulich  wrote:
 On 04.10.16 at 17:06,  wrote:
>> At 08:29 -0600 on 04 Oct (1475569774), Jan Beulich wrote:
>>> >>> On 04.10.16 at 16:12,  wrote:
>>> > yes, I understand that is the case when you do need to flush a guest.
>>> > And yes, there seem to be paths that require to bump the tag of a
>>> > specific guest for certain events (mov-to-cr4 with paging mode changes
>>> > for example). What I'm poking at it here is that we invalidate the
>>> > guest TLBs for _all_ guests very frequently. I can't find an
>>> > explanation for why _that_ is required. AFAIK having the TLB tag
>>> > guarantees that no other guest or Xen will have a chance to bump into
>>> > stale entries given no guests or Xen share a TLB tag with each other.
>>> > So the only time I see that we would have to flush all guest TLBs is
>>> > when the tag overflows and we start from 1 again. What am I missing
>>> > here?
>>>
>>> Oh, I see - this indeed looks to be quite a bit more flushing than is
>>> desirable. So the question, as you did put it already, is why it got
>>> done that way in the first place. At the very least it would look like
>>> more control would need to be given to the callers of both
>>> write_cr3() and flush_area_local(). Tim?
>>
>> IIRC:
>>  - Remote TLB flushes are used for safety, e.g. to be sure that no
>>guest has a mapping of a page before its type or owner changes.
>>The callers rely on _all_ mappings of the page being gone after
>>the remote flush.  The simplest way to do that is to flush all tags.
>
> Ah, of course. And that means that no matter that Tamas observed
> no breakage with some of the flushing removed, it can't be dropped
> altogether.
>
>>  - We believed that on the then-current hardware, and with the
>>scheduling timeslice we had, there wasn't an awful lot of
>>benefit to keeping the tags of descheduled VMs around.
>>  - Although it might sometimes be safe to leave some tags unflushed,
>>it wasn't clear exactly when that would be.  E.g. I don't think
>>that whether the tag is 'current' is a very useful test -- either
>>the tag might contain dangerous mappings or it might not.
>>
>> Since there are cases where we already mask TLB flushes by domain
>> (usign the dirty-cpumask) I can see that we might pass that domain ID
>> to the remote CPU and drop only that domain's tags.
>>
>> And for HAP guests it may be possible to distinguish between "guest"
>> flushes (e.g. emulating guest CR3 writes) and "hypervisor" flushes
>> (e.g. after grant/p2m ops), and target "guest" flushes at particular
>> VCPUs.
>
> Right. Question is whether there are any such operations
> occurring frequently enough that optimizing this would make
> sense. I don't see HVM code paths leading to write_cr3(), and
> I don't think there are a whole lot leading to flush_area_local().
> Did you gain any insight in this regard, Tamas?

There are a ton of calls to flush_area_local, and a good chunk of them
with the idle vCPU being the active one when it is called. As for
write_cr3, there are also a lot of calls there. When I added some
debug output to observe just how many dom0 would take almost an hour
to boot and the serial line would just be spammed with that printk. So
even if there no HVM paths leading there, others paths definitely do
that affect HVM guests by making all of them take on a new tag next
time they are scheduled.

Tamas

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

Re: [Xen-devel] per-domain logging

2016-10-07 Thread Ian Jackson

Wei Liu writes ("Re: [Xen-devel] per-domain logging"):
> Instead of trying to change all the format strings I think it would be
> better to have a new set of LOG macros that takes domid.
> 
> Something like:
>   LOGEVD(ERROR, errno, domid, "");
> 
> I would also like to have the log format written down in some document
> or header file.

That would seem like a good idea to me.

> But let's step back a bit: have we agreed on the approach forward? This
> thread doesn't seem to have a clear conclusion yet.  Obviously I don't
> want you to waste your writing code that's going to be threw away.
> 
> If you're happy with demuxing in libvirt, I won't object to it. Looks
> like there is relatively less code churn involved than other solutions,
> say, libxl keeping track of a set of per-domain xtl loggers.

The libvirt solution is not particularly general.

Ian.

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

Re: [Xen-devel] Question about VPID during MOV-TO-CR3

2016-10-07 Thread Jan Beulich

>>> On 04.10.16 at 17:06,  wrote:
> At 08:29 -0600 on 04 Oct (1475569774), Jan Beulich wrote:
>> >>> On 04.10.16 at 16:12,  wrote:
>> > yes, I understand that is the case when you do need to flush a guest.
>> > And yes, there seem to be paths that require to bump the tag of a
>> > specific guest for certain events (mov-to-cr4 with paging mode changes
>> > for example). What I'm poking at it here is that we invalidate the
>> > guest TLBs for _all_ guests very frequently. I can't find an
>> > explanation for why _that_ is required. AFAIK having the TLB tag
>> > guarantees that no other guest or Xen will have a chance to bump into
>> > stale entries given no guests or Xen share a TLB tag with each other.
>> > So the only time I see that we would have to flush all guest TLBs is
>> > when the tag overflows and we start from 1 again. What am I missing
>> > here?
>> 
>> Oh, I see - this indeed looks to be quite a bit more flushing than is
>> desirable. So the question, as you did put it already, is why it got
>> done that way in the first place. At the very least it would look like
>> more control would need to be given to the callers of both
>> write_cr3() and flush_area_local(). Tim?
> 
> IIRC:
>  - Remote TLB flushes are used for safety, e.g. to be sure that no
>guest has a mapping of a page before its type or owner changes.
>The callers rely on _all_ mappings of the page being gone after
>the remote flush.  The simplest way to do that is to flush all tags.

Ah, of course. And that means that no matter that Tamas observed
no breakage with some of the flushing removed, it can't be dropped
altogether.

>  - We believed that on the then-current hardware, and with the
>scheduling timeslice we had, there wasn't an awful lot of
>benefit to keeping the tags of descheduled VMs around.
>  - Although it might sometimes be safe to leave some tags unflushed,
>it wasn't clear exactly when that would be.  E.g. I don't think
>that whether the tag is 'current' is a very useful test -- either
>the tag might contain dangerous mappings or it might not.
> 
> Since there are cases where we already mask TLB flushes by domain
> (usign the dirty-cpumask) I can see that we might pass that domain ID
> to the remote CPU and drop only that domain's tags.
> 
> And for HAP guests it may be possible to distinguish between "guest"
> flushes (e.g. emulating guest CR3 writes) and "hypervisor" flushes
> (e.g. after grant/p2m ops), and target "guest" flushes at particular
> VCPUs.

Right. Question is whether there are any such operations
occurring frequently enough that optimizing this would make
sense. I don't see HVM code paths leading to write_cr3(), and
I don't think there are a whole lot leading to flush_area_local().
Did you gain any insight in this regard, Tamas?

The thing that would really help us would be some INVLPG
equivalent allowing a size/mask to be provided along with the
address (as that other path in flush_area_local() doesn't have
all these problems). Otoh, Tim - if INVLPG was sufficient for order
zero, how come ASID based full invalidation is required on the
other path? Wouldn't this need to be accompanied by a suitable
INVVPID/INVLPGA?

Jan

> Both of those will want careful unpicking from existing safety
> mechanisms that assume that a flush is a flush.  E.g. the
> tlbflush_timestamp used on page allocation skips a shootdown if _any_
> TLB flush has happened on the remote PCPU since the page was freed.
> Partial flushes can't count towards that.  And there might be other
> gotchas that I can't think of right now.
> 
> Cheers,
> 
> Tim.




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

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

2016-10-07 Thread Platform Team regression test user

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 67834

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 67834
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67834

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

version targeted for testing:
 qemuue902754e3d0890945ddcc1b33748ed73762ddb8d
baseline version:
 qemuua65b6f27ce65e2e4f771f69d549ffa455a4d543a

Last test of basis67834  2016-10-06 19:45:23 Z0 days
Testing same since67836  2016-10-07 04:48:01 Z0 days1 attempts


People who touched revisions under test:
  Avinesh Kumar 
  David Gibson 
  Felipe Franciosi 
  Greg Kurz 
  Laurent Vivier 
  Nikunj A Dadhania 
  Peter Maydell 
  Rajalakshmi Srinivasaraghavan 
  Ravi Bangoria 
  Thomas Huth 

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

Re: [Xen-devel] per-domain logging

2016-10-07 Thread Wei Liu

On Tue, Oct 04, 2016 at 11:14:52AM +0200, Cedric Bosdonnat wrote:
> Hi Ian and Wei,
> 
> On Mon, 2016-09-19 at 16:23 +0100, Ian Jackson wrote:
> > Cedric Bosdonnat writes ("Re: [Xen-devel] per-domain logging"):
> > > On Thu, 2016-09-15 at 16:11 +0100, Wei Liu wrote:
> > > > IIRC there is already logfile abstraction inside libvirt -- can you just
> > > > pass in a libvirt logfile fd and try to demux there?
> > > 
> > > 
> > > The abstraction we have is something similar to the XenToolLogger,
> > > not something abstracting the log files. Even if we had that, how
> > > could we demux since there is no domain name in the libxl messages.
> 
> I came up with a commit on the libvirt side writing a custom xtl_logger
> that demuxes the log messages. Here it is for the curious ones:
> 
> https://github.com/cbosdo/libvirt/commit/5e28dd67c52a49b11635167469a8b60dcb4e287c
> 
> This way, libvirt would put all log messages containing ': Domain %u:' in a
> separate log file and all non-matching messages would go to the default
> libxl-driver.log file.
> 
> > Right.
> > 
> > It's not trivial to change the xtl API because there is no
> > negotiation, just a vops structure.  I can think of a way to do it,
> > but do we want to make all xtl logger users (that is, all generators
> > of log messages) pass a domid ?
> > 
> > Do we want to extend this to other information ?  (Not sure _what_
> > other information.)
> > 
> > Alternatively, we could have libxl (and perhaps libxc) put the domid
> > in a standard format in the message, so it could be extracted ?
> > 
> > However we do it, we would have to add a domid to every LOG call in
> > libxl.
> 
> Attached is a partial attempt at this that I wrote to test my libvirt code.
> How does that sound to you? Should I continue like this? Obviously I surely
> missed a few log messages that could get a domid, but it seems that even libxl
> has log messages that can't have a domid.
> 

Instead of trying to change all the format strings I think it would be
better to have a new set of LOG macros that takes domid.

Something like:
  LOGEVD(ERROR, errno, domid, "");

I would also like to have the log format written down in some document
or header file.

But let's step back a bit: have we agreed on the approach forward? This
thread doesn't seem to have a clear conclusion yet.  Obviously I don't
want you to waste your writing code that's going to be threw away.

If you're happy with demuxing in libvirt, I won't object to it. Looks
like there is relatively less code churn involved than other solutions,
say, libxl keeping track of a set of per-domain xtl loggers.

Wei.

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

[Xen-devel] [distros-debian-jessie test] 67837: tolerable all pass

2016-10-07 Thread Platform Team regression test user

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-jessie-netboot-pygrub 11 migrate-support-check fail 
never pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub 12 saverestore-support-check fail 
never pass

baseline version:
 flight   67751

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



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH] x86: defer not-present segment checks

2016-10-07 Thread Jan Beulich

>>> On 07.10.16 at 15:01,  wrote:
> Also note how e.g. emulate_gate_op() looks at the P bit of the gate
> only after having done other relevant checks. Having looked at this
> again just now I realize, though, that the P bit clear on the code
> segment descriptor wrongly raises #GP. As this gets fixed by the
> rework patch using the generic insn decoder, I won't bother submitting
> a separate fix for this though; I'll just add a note to that patch's
> commit message.

Actually I was wrong here - it's the check of the descriptor of an
already loaded segment register that does this, so there's nothing
wrong with raising #GP when it ends up being no longer present
at that point (as there's no architectural exception in this case,
using #GP uniformly is likely better than trying to be creative).

Jan

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

Re: [Xen-devel] [PATCH] x86: defer not-present segment checks

2016-10-07 Thread Jan Beulich

>>> On 07.10.16 at 14:28,  wrote:
> On 06/10/16 13:24, Jan Beulich wrote:
>> Following on from commits 5602e74c60 ("x86emul: correct loading of
>> %ss") and bdb860d01c ("x86/HVM: correct segment register loading during
>> task switch") the point of the non-.present checks needs to be refined:
>> #NP (and its #SS companion), other than suggested by the various
>> instruction pages in Intel's SDM, gets checked for only after all type
>> and permission checks. The only checks getting done even later are the
>> 64-bit specific ones for system descriptors (which we don't support
>> yet).
> 
> Is this from observation on native hardware?

Yes. I also found that old paper manuals are more helpful in this
respect than the SDM is nowadays.

> The AMD manual does describe:
> 
> Present (P) Bit. Bit 15 of the upper doubleword. The segment-present bit
> indicates that the segment referenced by the descriptor is loaded in
> memory. If a reference is made to a descriptor entry when P = 0, a
> segment-not-present exception (#NP) occurs.
> 
> which doesn't imply that the present bit is a validity bit for the other
> contents of the segment.
> 
> Intel is similar, with:
> 
> Indicates whether the segment is present in memory (set) or not present
> (clear). If this flag is clear, the processor generates a
> segment-not-present exception (#NP) when a segment selector that points
> to the segment descriptor is loaded into a segment register.
> 
> Furthermore, Figure 3-9 shows what a segment descriptor looks like with
> the present flag is clear.  This quite clearly states that the type, S,
> DPL and P fields all have meanings, but that all other fields are
> explicitly available for software use.
> 
> Therefore, it seems legitimate to consider type/dpl/S before P, but we
> must take extra special care not to look at any other fields until P is
> found to be set.

Exactly.

Also note how e.g. emulate_gate_op() looks at the P bit of the gate
only after having done other relevant checks. Having looked at this
again just now I realize, though, that the P bit clear on the code
segment descriptor wrongly raises #GP. As this gets fixed by the
rework patch using the generic insn decoder, I won't bother submitting
a separate fix for this though; I'll just add a note to that patch's
commit message.

Jan


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

Re: [Xen-devel] [PATCH] x86: defer not-present segment checks

2016-10-07 Thread Andrew Cooper

On 06/10/16 13:24, Jan Beulich wrote:
> Following on from commits 5602e74c60 ("x86emul: correct loading of
> %ss") and bdb860d01c ("x86/HVM: correct segment register loading during
> task switch") the point of the non-.present checks needs to be refined:
> #NP (and its #SS companion), other than suggested by the various
> instruction pages in Intel's SDM, gets checked for only after all type
> and permission checks. The only checks getting done even later are the
> 64-bit specific ones for system descriptors (which we don't support
> yet).

Is this from observation on native hardware?

The AMD manual does describe:

Present (P) Bit. Bit 15 of the upper doubleword. The segment-present bit
indicates that the segment referenced by the descriptor is loaded in
memory. If a reference is made to a descriptor entry when P = 0, a
segment-not-present exception (#NP) occurs.

which doesn't imply that the present bit is a validity bit for the other
contents of the segment.

Intel is similar, with:

Indicates whether the segment is present in memory (set) or not present
(clear). If this flag is clear, the processor generates a
segment-not-present exception (#NP) when a segment selector that points
to the segment descriptor is loaded into a segment register.

Furthermore, Figure 3-9 shows what a segment descriptor looks like with
the present flag is clear.  This quite clearly states that the type, S,
DPL and P fields all have meanings, but that all other fields are
explicitly available for software use.

Therefore, it seems legitimate to consider type/dpl/S before P, but we
must take extra special care not to look at any other fields until P is
found to be set.

~Andrew

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

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

2016-10-07 Thread osstest service owner

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 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

version targeted for testing:
 xen  84c1e7d8017c773c41d6e8b79384f37a67be1479
baseline version:
 xen  9f5eff08a6a6f58645fb48382c843973674042c9

Last test of basis   101282  2016-10-05 13:03:25 Z1 days
Testing same since   101323  2016-10-07 10:01:01 Z0 days1 attempts


People who touched revisions under test:
  Lan Tianyu 
  Razvan Cojocaru 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=84c1e7d8017c773c41d6e8b79384f37a67be1479
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
84c1e7d8017c773c41d6e8b79384f37a67be1479
+ branch=xen-unstable-smoke
+ revision=84c1e7d8017c773c41d6e8b79384f37a67be1479
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x84c1e7d8017c773c41d6e8b79384f37a67be1479 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ :

Re: [Xen-devel] [PATCH] docs: Belatedly update for move of qmp-commands.txt.

2016-10-07 Thread Markus Armbruster

Markus Armbruster  writes:

> Missed in commit d076a2a and commit bd6092e.
>
> Signed-off-by: Markus Armbruster 

Applied to my qapi-next branch, with a cosmetic change to the commit
message.

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

Re: [Xen-devel] [RFC PATCH 4/8] gcov: add new interface and 3.4 and 4.7 format support

2016-10-07 Thread Wei Liu

On Fri, Oct 07, 2016 at 05:52:50AM -0600, Jan Beulich wrote:
> >>> On 07.10.16 at 13:43,  wrote:
> > On Fri, Oct 07, 2016 at 12:10:25PM +0100, Wei Liu wrote:
> >> On Fri, Oct 07, 2016 at 05:06:42AM -0600, Jan Beulich wrote:
> >> > >>> On 06.10.16 at 16:37,  wrote:
> >> > > A new sysctl interface for passing gcov data back to userspace. The new
> >> > > interface uses a customised record file format. The new sysctl reuses
> >> > > original sysctl number but renames the op to gcov_op.
> >> > > 
> >> > > Both gcc 3.4 and 4.7 format are supported. The code is rewritten so 
> >> > > that
> >> > > a new format can be easily added in the future.  Version specific code
> >> > > is grouped into different files. The format one needs to use can be
> >> > > picked via Kconfig. The default format is 4.7 format.
> >> > > 
> >> > > Userspace programs to handle extracted data will come in a later patch.
> >> > > 
> >> > > Signed-off-by: Wei Liu 
> >> > 
> >> > Looks reasonable, but wants some cosmetics done: Constification
> >> > seems to b possible in a number of places, labels should be
> >> > indented by at least one blank, and pointless initializers would be
> >> > nice to see eliminated. Also, unless at least the removal patch is
> >> > still meant to go in for 4.8, you'll need to bump
> >> > XEN_SYSCTL_INTERFACE_VERSION in the patch here.
> >> > 
> >> 
> >> Regarding cosmetic issues, I will try to fix as many as possible.
> >> 
> >> The removal patch won't go in 4.8 because though the implementation has
> >> a lot of limitations it might still be useful to some people. I will
> >> bump XEN_SYSCTL_INTERFACE_VERSION here in this patch.
> >> 
> > 
> > I go through most (if not all) initialisers, actually they are necessary:
> > 
> > 1. those accumulative counters need to be initialised to 0.
> 
> In e.g.
> 
> +uint32_t total_size = 0;
> +struct gcov_info *info = NULL;
> +
> +/* Magic number XCOV */
> +total_size += sizeof(uint32_t);
> 
> I can't see why the sizeof(uint32_t) can't be the initializer right away,
> or the initializer be dropped and = used in place of += .
> 

Sure, I can change this and check if there are other similar instances.

Wei.

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

Re: [Xen-devel] [RFC PATCH 4/8] gcov: add new interface and 3.4 and 4.7 format support

2016-10-07 Thread Jan Beulich

>>> On 07.10.16 at 13:43,  wrote:
> On Fri, Oct 07, 2016 at 12:10:25PM +0100, Wei Liu wrote:
>> On Fri, Oct 07, 2016 at 05:06:42AM -0600, Jan Beulich wrote:
>> > >>> On 06.10.16 at 16:37,  wrote:
>> > > A new sysctl interface for passing gcov data back to userspace. The new
>> > > interface uses a customised record file format. The new sysctl reuses
>> > > original sysctl number but renames the op to gcov_op.
>> > > 
>> > > Both gcc 3.4 and 4.7 format are supported. The code is rewritten so that
>> > > a new format can be easily added in the future.  Version specific code
>> > > is grouped into different files. The format one needs to use can be
>> > > picked via Kconfig. The default format is 4.7 format.
>> > > 
>> > > Userspace programs to handle extracted data will come in a later patch.
>> > > 
>> > > Signed-off-by: Wei Liu 
>> > 
>> > Looks reasonable, but wants some cosmetics done: Constification
>> > seems to b possible in a number of places, labels should be
>> > indented by at least one blank, and pointless initializers would be
>> > nice to see eliminated. Also, unless at least the removal patch is
>> > still meant to go in for 4.8, you'll need to bump
>> > XEN_SYSCTL_INTERFACE_VERSION in the patch here.
>> > 
>> 
>> Regarding cosmetic issues, I will try to fix as many as possible.
>> 
>> The removal patch won't go in 4.8 because though the implementation has
>> a lot of limitations it might still be useful to some people. I will
>> bump XEN_SYSCTL_INTERFACE_VERSION here in this patch.
>> 
> 
> I go through most (if not all) initialisers, actually they are necessary:
> 
> 1. those accumulative counters need to be initialised to 0.

In e.g.

+uint32_t total_size = 0;
+struct gcov_info *info = NULL;
+
+/* Magic number XCOV */
+total_size += sizeof(uint32_t);

I can't see why the sizeof(uint32_t) can't be the initializer right away,
or the initializer be dropped and = used in place of += .

> 2. gcov_info_next expects NULL for first invocation.

Oh, I've indeed overlooked this requirement.

Jan


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

Re: [Xen-devel] [RFC PATCH 4/8] gcov: add new interface and 3.4 and 4.7 format support

2016-10-07 Thread Wei Liu

On Fri, Oct 07, 2016 at 12:10:25PM +0100, Wei Liu wrote:
> On Fri, Oct 07, 2016 at 05:06:42AM -0600, Jan Beulich wrote:
> > >>> On 06.10.16 at 16:37,  wrote:
> > > A new sysctl interface for passing gcov data back to userspace. The new
> > > interface uses a customised record file format. The new sysctl reuses
> > > original sysctl number but renames the op to gcov_op.
> > > 
> > > Both gcc 3.4 and 4.7 format are supported. The code is rewritten so that
> > > a new format can be easily added in the future.  Version specific code
> > > is grouped into different files. The format one needs to use can be
> > > picked via Kconfig. The default format is 4.7 format.
> > > 
> > > Userspace programs to handle extracted data will come in a later patch.
> > > 
> > > Signed-off-by: Wei Liu 
> > 
> > Looks reasonable, but wants some cosmetics done: Constification
> > seems to b possible in a number of places, labels should be
> > indented by at least one blank, and pointless initializers would be
> > nice to see eliminated. Also, unless at least the removal patch is
> > still meant to go in for 4.8, you'll need to bump
> > XEN_SYSCTL_INTERFACE_VERSION in the patch here.
> > 
> 
> Regarding cosmetic issues, I will try to fix as many as possible.
> 
> The removal patch won't go in 4.8 because though the implementation has
> a lot of limitations it might still be useful to some people. I will
> bump XEN_SYSCTL_INTERFACE_VERSION here in this patch.
> 

I go through most (if not all) initialisers, actually they are necessary:

1. those accumulative counters need to be initialised to 0.
2. gcov_info_next expects NULL for first invocation.

Wei.

> Wei.
> 
> > Jan
> > 

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

[Xen-devel] [xen-unstable test] 101320: tolerable FAIL

2016-10-07 Thread osstest service owner

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen  9f5eff08a6a6f58645fb48382c843973674042c9
baseline version:
 xen  9f5eff08a6a6f58645fb48382c843973674042c9

Last test of basis   101320  2016-10-07 01:58:11 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17081 days0 attempts

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

Re: [Xen-devel] [RFC PATCH 4/8] gcov: add new interface and 3.4 and 4.7 format support

2016-10-07 Thread Wei Liu

On Fri, Oct 07, 2016 at 05:06:42AM -0600, Jan Beulich wrote:
> >>> On 06.10.16 at 16:37,  wrote:
> > A new sysctl interface for passing gcov data back to userspace. The new
> > interface uses a customised record file format. The new sysctl reuses
> > original sysctl number but renames the op to gcov_op.
> > 
> > Both gcc 3.4 and 4.7 format are supported. The code is rewritten so that
> > a new format can be easily added in the future.  Version specific code
> > is grouped into different files. The format one needs to use can be
> > picked via Kconfig. The default format is 4.7 format.
> > 
> > Userspace programs to handle extracted data will come in a later patch.
> > 
> > Signed-off-by: Wei Liu 
> 
> Looks reasonable, but wants some cosmetics done: Constification
> seems to b possible in a number of places, labels should be
> indented by at least one blank, and pointless initializers would be
> nice to see eliminated. Also, unless at least the removal patch is
> still meant to go in for 4.8, you'll need to bump
> XEN_SYSCTL_INTERFACE_VERSION in the patch here.
> 

Regarding cosmetic issues, I will try to fix as many as possible.

The removal patch won't go in 4.8 because though the implementation has
a lot of limitations it might still be useful to some people. I will
bump XEN_SYSCTL_INTERFACE_VERSION here in this patch.

Wei.

> Jan
> 

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

Re: [Xen-devel] [RFC PATCH 8/8] gcov: provide the capability to select gcov format automatically

2016-10-07 Thread Wei Liu

On Fri, Oct 07, 2016 at 03:55:47AM -0600, Jan Beulich wrote:
> >>> On 06.10.16 at 16:37,  wrote:
> > +config GCOV_FORMAT_AUTODETECT
> > +   bool "Autodetect"
> > +   ---help---
> > +   Automatically select gcov format based on GCC version.
> 
> Tab indentation again please, and I think help text usually gets
> indented by another one or two spaces from the "help" or "---help---"
> keyword's.
> 

I will fix the issues you point out in this patch and previous ones.

Thanks for reviewing.

Wei.

> Jan
> 

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

Re: [Xen-devel] [RFC PATCH 4/8] gcov: add new interface and 3.4 and 4.7 format support

2016-10-07 Thread Jan Beulich

>>> On 06.10.16 at 16:37,  wrote:
> A new sysctl interface for passing gcov data back to userspace. The new
> interface uses a customised record file format. The new sysctl reuses
> original sysctl number but renames the op to gcov_op.
> 
> Both gcc 3.4 and 4.7 format are supported. The code is rewritten so that
> a new format can be easily added in the future.  Version specific code
> is grouped into different files. The format one needs to use can be
> picked via Kconfig. The default format is 4.7 format.
> 
> Userspace programs to handle extracted data will come in a later patch.
> 
> Signed-off-by: Wei Liu 

Looks reasonable, but wants some cosmetics done: Constification
seems to b possible in a number of places, labels should be
indented by at least one blank, and pointless initializers would be
nice to see eliminated. Also, unless at least the removal patch is
still meant to go in for 4.8, you'll need to bump
XEN_SYSCTL_INTERFACE_VERSION in the patch here.

Jan

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

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

2016-10-07 Thread Platform Team regression test user

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken 
REGR. vs. 67792
 test-armhf-armhf-xl-credit2  16 guest-start.2 fail REGR. vs. 67792

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67792
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67792
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 67792

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

version targeted for testing:
 xen  9f5eff08a6a6f58645fb48382c843973674042c9
baseline version:
 xen  40277cded320efa32b86c0c9f01e33145eab5ee4

Last test of basis67792  2016-10-04 02:47:26 Z3 days
Testing same since67835  2016-10-06 23:18:32 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  casionwoo 
  Ian Jackson 
  Jan Beulich 
  JEUNGWOO, YOO 
  Wei Liu 

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

Re: [Xen-devel] [PATCH net-next] MAINTAINERS: add myself as a maintainer of xen-netback

2016-10-07 Thread Wei Liu

On Fri, Oct 07, 2016 at 11:33:37AM +0100, Paul Durrant wrote:
> Signed-off-by: Paul Durrant 
> Cc: Wei Liu 

Acked-by: Wei Liu 

Thanks for stepping up!

> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 464437d..4491841 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -13061,6 +13061,7 @@ F:arch/arm64/include/asm/xen/
>  
>  XEN NETWORK BACKEND DRIVER
>  M:   Wei Liu 
> +M:   Paul Durrant 
>  L:   xen-de...@lists.xenproject.org (moderated for non-subscribers)
>  L:   net...@vger.kernel.org
>  S:   Supported
> -- 
> 2.1.4
> 

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

[Xen-devel] [PATCH net-next] MAINTAINERS: add myself as a maintainer of xen-netback

2016-10-07 Thread Paul Durrant

Signed-off-by: Paul Durrant 
Cc: Wei Liu 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 464437d..4491841 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13061,6 +13061,7 @@ F:  arch/arm64/include/asm/xen/
 
 XEN NETWORK BACKEND DRIVER
 M: Wei Liu 
+M: Paul Durrant 
 L: xen-de...@lists.xenproject.org (moderated for non-subscribers)
 L: net...@vger.kernel.org
 S: Supported
-- 
2.1.4


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

Re: [Xen-devel] [RFC PATCH 5/8] gcov: userspace tools to extract and split gcov data

2016-10-07 Thread Wei Liu

On Fri, Oct 07, 2016 at 11:47:13AM +0100, Andrew Cooper wrote:
> On 06/10/16 15:37, Wei Liu wrote:
> > Provide two tools: a small C program to extract data from hypervisor and
> > a python script to split data into multiple files.
> >
> > The file xencov.c is salvaged and modified from the original xencov.c.
> >
> > Signed-off-by: Wei Liu 
> > ---
> > Cc: Ian Jackson 
> > ---
> >  tools/misc/Makefile |   6 ++
> >  tools/misc/xencov.c | 148 
> > 
> >  tools/misc/xencov_split | 100 
> >  3 files changed, 254 insertions(+)
> >  create mode 100644 tools/misc/xencov.c
> >  create mode 100755 tools/misc/xencov_split
> >
> > diff --git a/tools/misc/Makefile b/tools/misc/Makefile
> > index 5ba6672..c029401 100644
> > --- a/tools/misc/Makefile
> > +++ b/tools/misc/Makefile
> > @@ -13,6 +13,7 @@ CFLAGS += $(CFLAGS_libxenstore)
> >  INSTALL_BIN-$(CONFIG_X86)  += xen-cpuid
> >  INSTALL_BIN-$(CONFIG_X86)  += xen-detect
> >  INSTALL_BIN+= xencons
> > +INSTALL-BIN+= xencov_split
> 
> You have typo'd INSTALL_BIN here, causing xencov_split not to be
> installed.  (Luckily, RPM catches this, but I have spent a while staring
> in disbelief, trying to work out what was wrong.)
> 

I stared at the two lines for 30s and finally figured out that went
wrong.

Sorry about this! I will fix that in v2.

Wei.

> ~Andrew

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

Re: [Xen-devel] [RFC PATCH 5/8] gcov: userspace tools to extract and split gcov data

2016-10-07 Thread Andrew Cooper

On 06/10/16 15:37, Wei Liu wrote:
> Provide two tools: a small C program to extract data from hypervisor and
> a python script to split data into multiple files.
>
> The file xencov.c is salvaged and modified from the original xencov.c.
>
> Signed-off-by: Wei Liu 
> ---
> Cc: Ian Jackson 
> ---
>  tools/misc/Makefile |   6 ++
>  tools/misc/xencov.c | 148 
> 
>  tools/misc/xencov_split | 100 
>  3 files changed, 254 insertions(+)
>  create mode 100644 tools/misc/xencov.c
>  create mode 100755 tools/misc/xencov_split
>
> diff --git a/tools/misc/Makefile b/tools/misc/Makefile
> index 5ba6672..c029401 100644
> --- a/tools/misc/Makefile
> +++ b/tools/misc/Makefile
> @@ -13,6 +13,7 @@ CFLAGS += $(CFLAGS_libxenstore)
>  INSTALL_BIN-$(CONFIG_X86)  += xen-cpuid
>  INSTALL_BIN-$(CONFIG_X86)  += xen-detect
>  INSTALL_BIN+= xencons
> +INSTALL-BIN+= xencov_split

You have typo'd INSTALL_BIN here, causing xencov_split not to be
installed.  (Luckily, RPM catches this, but I have spent a while staring
in disbelief, trying to work out what was wrong.)

~Andrew

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

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

2016-10-07 Thread osstest service owner

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  1eeeb1e89bf979d5726f283fe126c1163ad1f840
baseline version:
 libvirt  c7d3cf2e3ba73e6e3eee36bd1d6ca2eed1fedc55

Last test of basis   101301  2016-10-06 04:22:57 Z1 days
Testing same since   101321  2016-10-07 04:23:24 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Erik Skultety 
  JÃ¡n Tomko 
  Martin Kletzander 
  Peter Krempa 

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=1eeeb1e89bf979d5726f283fe126c1163ad1f840
+ . ./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] New Outreachy Applicant

2016-10-07 Thread George Dunlap

On Thu, Oct 6, 2016 at 4:16 PM, George Dunlap  wrote:
> Let me take a look at a simple example you could use to "wire-in"
> something to the build system.

Probably the simplest example of how to "wire in" a directory is tools/xentrace.

For the moment, I would just hardcode it in tools/Makefile (as
xentrace is); we can work on getting an option to `configure` later.

It should be pretty straightforward to take tools/xentrace/Makefile
and modify it to do what you need.

The primary difference is that due to the way Go operates, the main
thing you want to install is the go files themselves, rather than a
compiled binary.

Anyway -- why don't you find me on #xendevel when you get a chance and
we can walk through what the Makefile should do. :-)

 -George

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

Re: [Xen-devel] [RFC PATCH 6/8] Config.mk: expand cc-ver a bit

2016-10-07 Thread Wei Liu

On Fri, Oct 07, 2016 at 03:52:53AM -0600, Jan Beulich wrote:
> >>> On 06.10.16 at 16:37,  wrote:
> > --- a/Config.mk
> > +++ b/Config.mk
> > @@ -112,17 +112,17 @@ endef
> >  
> >  cc-options-add = $(foreach o,$(3),$(call cc-option-add,$(1),$(2),$(o)))
> >  
> > -# cc-ver: Check compiler is at least specified version. Return boolean 
> > 'y'/'n'.
> > -# Usage: ifeq ($(call cc-ver,$(CC),0x030400),y)
> > +# cc-ver: Check compiler against the version requirement. Return boolean 
> > 'y'/'n'.
> > +# Usage: ifeq ($(call cc-ver,$(CC),-ge,0x030400),y)
> >  cc-ver = $(shell if [ $$((`$(1) -dumpversion | awk -F. \
> > -   '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -ge $$(($(2))) 
> > ]; \
> > +   '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) $(2) $$(($(3))) 
> > ]; \
> > then echo y; else echo n; fi ;)
> >  
> >  # cc-ver-check: Check compiler is at least specified version, else fail.
> >  # Usage: $(call cc-ver-check,CC,0x030400,"Require at least gcc-3.4")
> >  cc-ver-check = $(eval $(call cc-ver-check-closure,$(1),$(2),$(3)))
> >  define cc-ver-check-closure
> > -ifeq ($$(call cc-ver,$$($(1)),$(2)),n)
> > +ifeq ($$(call cc-ver,$$($(1)),-ge,$(2)),n)
> 
> Could you keep the dash in the macro, making such invocations look
> a little more "normal"?
> 

NP. Changed in my tree.

Wei.

> Jan
> 

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

Re: [Xen-devel] [RFC PATCH 8/8] gcov: provide the capability to select gcov format automatically

2016-10-07 Thread Jan Beulich

>>> On 06.10.16 at 16:37,  wrote:
> +config GCOV_FORMAT_AUTODETECT
> +   bool "Autodetect"
> +   ---help---
> +   Automatically select gcov format based on GCC version.

Tab indentation again please, and I think help text usually gets
indented by another one or two spaces from the "help" or "---help---"
keyword's.

Jan

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

Re: [Xen-devel] [RFC PATCH 6/8] Config.mk: expand cc-ver a bit

2016-10-07 Thread Jan Beulich

>>> On 06.10.16 at 16:37,  wrote:
> --- a/Config.mk
> +++ b/Config.mk
> @@ -112,17 +112,17 @@ endef
>  
>  cc-options-add = $(foreach o,$(3),$(call cc-option-add,$(1),$(2),$(o)))
>  
> -# cc-ver: Check compiler is at least specified version. Return boolean 
> 'y'/'n'.
> -# Usage: ifeq ($(call cc-ver,$(CC),0x030400),y)
> +# cc-ver: Check compiler against the version requirement. Return boolean 
> 'y'/'n'.
> +# Usage: ifeq ($(call cc-ver,$(CC),-ge,0x030400),y)
>  cc-ver = $(shell if [ $$((`$(1) -dumpversion | awk -F. \
> -   '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -ge $$(($(2))) ]; \
> +   '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) $(2) $$(($(3))) ]; 
> \
> then echo y; else echo n; fi ;)
>  
>  # cc-ver-check: Check compiler is at least specified version, else fail.
>  # Usage: $(call cc-ver-check,CC,0x030400,"Require at least gcc-3.4")
>  cc-ver-check = $(eval $(call cc-ver-check-closure,$(1),$(2),$(3)))
>  define cc-ver-check-closure
> -ifeq ($$(call cc-ver,$$($(1)),$(2)),n)
> +ifeq ($$(call cc-ver,$$($(1)),-ge,$(2)),n)

Could you keep the dash in the macro, making such invocations look
a little more "normal"?

Jan


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

Re: [Xen-devel] [RFC PATCH 1/8] Kconfig: add BROKEN config

2016-10-07 Thread Jan Beulich

>>> On 06.10.16 at 16:37,  wrote:
> --- a/xen/Kconfig
> +++ b/xen/Kconfig
> @@ -12,6 +12,9 @@ config ARCH
>   string
>   option env="ARCH"
>  
> +config BROKEN
> +   bool

Please use tab indentation, like all the other options here do.

Jan


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

Re: [Xen-devel] [PATCH v2 20/30] xen/x86: add the basic infrastructure to import QEMU passthrough code

2016-10-07 Thread Jan Beulich

>>> On 06.10.16 at 17:08,  wrote:
> On Mon, Oct 03, 2016 at 10:54:54AM +0100, Paul Durrant wrote:

To both of you: Please limit the quoting in your replies.

Thanks, Jan


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

[Xen-devel] FW: [PATCH v2 net] xen-netback: make sure that hashes are not send to unaware frontends

2016-10-07 Thread Paul Durrant

Sorry, I fat-fingered the address in the get send-email...
--- Begin Message ---
In the case when a frontend only negotiates a single queue with xen-
netback it is possible for a skbuff with a s/w hash to result in a
hash extra_info segment being sent to the frontend even when no hash
algorithm has been configured. (The ndo_select_queue() entry point makes
sure the hash is not set if no algorithm is configured, but this entry
point is not called when there is only a single queue). This can result
in a frontend that is unable to handle extra_info segments being given
such a segment, causing it to crash.

This patch fixes the problem by clearing the hash in ndo_start_xmit()
instead, which is clearly guaranteed to be called irrespective of the
number of queues.

Signed-off-by: Paul Durrant 
Cc: Wei Liu 
---

v2:
 - Simplified and re-based onto re-factored net branch
---
 drivers/net/xen-netback/interface.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index 4af532a..74dc2bf 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -149,17 +149,8 @@ static u16 xenvif_select_queue(struct net_device *dev, 
struct sk_buff *skb,
struct xenvif *vif = netdev_priv(dev);
unsigned int size = vif->hash.size;
 
-   if (vif->hash.alg == XEN_NETIF_CTRL_HASH_ALGORITHM_NONE) {
-   u16 index = fallback(dev, skb) % dev->real_num_tx_queues;
-
-   /* Make sure there is no hash information in the socket
-* buffer otherwise it would be incorrectly forwarded
-* to the frontend.
-*/
-   skb_clear_hash(skb);
-
-   return index;
-   }
+   if (vif->hash.alg == XEN_NETIF_CTRL_HASH_ALGORITHM_NONE)
+   return fallback(dev, skb) % dev->real_num_tx_queues;
 
xenvif_set_skb_hash(vif, skb);
 
@@ -208,6 +199,13 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct 
net_device *dev)
cb = XENVIF_RX_CB(skb);
cb->expires = jiffies + vif->drain_timeout;
 
+   /* If there is no hash algorithm configured then make sure there
+* is no hash information in the socket buffer otherwise it
+* would be incorrectly forwarded to the frontend.
+*/
+   if (vif->hash.alg == XEN_NETIF_CTRL_HASH_ALGORITHM_NONE)
+   skb_clear_hash(skb);
+
xenvif_rx_queue_tail(queue, skb);
xenvif_kick_thread(queue);
 
-- 
2.1.4

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

Re: [Xen-devel] [PATCH net] xen-netback: make sure that hashes are not send to unaware frontends

2016-10-07 Thread Paul Durrant

> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: 07 October 2016 06:38
> To: Paul Durrant 
> Cc: net...@vger.kernel.org; xen-de...@lists.xenproject.org; Wei Liu
> 
> Subject: Re: [PATCH net] xen-netback: make sure that hashes are not send
> to unaware frontends
> 
> From: Paul Durrant 
> Date: Thu, 6 Oct 2016 15:47:10 +0100
> 
> > In the case when a frontend only negotiates a single queue with xen-
> > netback it is possible for a skbuff with a s/w hash to result in a
> > hash extra_info segment being sent to the frontend even when no hash
> > algorithm has been configured. (The ndo_select_queue() entry point
> > makes sure the hash is not set if no algorithm is configured, but this
> > entry point is not called when there is only a single queue). This can
> > result in a frontend that isunable to handle extra_info segments being
> > given such a segment, causing it to crash.
> >
> > This patch fixes the problem by gating whether the extra_info is sent
> > not only on the presence of a s/w hash, but also on whether the hash
> > algorithm has been configured.
> >
> > Signed-off-by: Paul Durrant 
> > Cc: Wei Liu 
> 
> This doesn't apply cleanly to the current 'net' tree, please respin.
> 

Sure. V2 coming.

  Paul

> Thanks.

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

70 matches

Mail list logo