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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 66879

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  9 debian-installfail REGR. vs. 66879
 test-amd64-i386-rumpuserxen-i386 10 guest-startfail like 66879
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 66879
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66879
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   like 66879

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

version targeted for testing:
 xen  f7347a282420a5edc74afb31e7c42c2765f24de5
baseline version:
 xen  bf925a9f1254391749f569c1b8fc606036340488

Last test of basis66879  2015-12-21 21:25:56 Z   22 days
Failing since 67053  2015-12-23 06:54:21 Z   20 days7 attempts
Testing same since77827  2016-01-11 12:11:48 Z1 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Bob Moore 
  Boris Ostrovsky 
  Daniel De Graaf 
  Doug Goldstein 
  Feng Wu 
  Graeme Gregory 
  Hanjun Guo 
  Haozhong Zhang 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Joshua Otto 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Len Brown 
  Lin Ming 
  Lv Zheng 
  Paul Durrant 
  Rafael J. Wysocki 
  Samuel Thibault 
  Shannon Zhao 
  Stefano Stabellini 
  Tomasz Nowicki 
  Wei Liu 

jobs:
 build-amd64-xsm  pass 

[Xen-devel] [seabios test] 77918: tolerable FAIL - PUSHED

[osstest service owner]

flight 77918 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77918/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 77427

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 seabios  44250252eeaefd5e81bae2f73639bd323682217b
baseline version:
 seabios  3c577a7644c6c91be70ffd59c121b5d19d381e5f

Last test of basis77427  2016-01-07 20:46:45 Z5 days
Testing same since77918  2016-01-12 18:44:21 Z0 days1 attempts


People who touched revisions under test:
  Stefan Berger 

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-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-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass
 test-amd64-i386-xl-qemuu-winxpsp3pass



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=seabios
+ revision=44250252eeaefd5e81bae2f73639bd323682217b
+ . ./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 seabios 
44250252eeaefd5e81bae2f73639bd323682217b
+ branch=seabios
+ revision=44250252eeaefd5e81bae2f73639bd323682217b
+ . ./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=seabios
+ xenbranch=xen-unstable
+ '[' xseabios = xlinux ']'
+ linuxbranch=
+ '[' x = x 

Re: [Xen-devel] [Qemu-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()

[Hao, Xudong]

> -Original Message-
> From: qemu-devel-bounces+xudong.hao=intel@nongnu.org [mailto:qemu-
> devel-bounces+xudong.hao=intel@nongnu.org] On Behalf Of Gerd
> Hoffmann
> Sent: Tuesday, January 12, 2016 6:25 PM
> To: Hao, Xudong 
> Cc: Lars Kurth ; xen-de...@lists.xensource.com; Stefano
> Stabellini ; Lars Kurth
> ; Michael S. Tsirkin ; qemu-
> de...@nongnu.org; Cao jin ; Stefano Stabellini
> 
> Subject: Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX:
> convert to realize()
> 
> On Di, 2016-01-12 at 09:50 +, Hao, Xudong wrote:
> > With latest qemu 7b8a354d4716, RHEL7.2 (with default kernel) VM still can't
> boot up with IGD.
> 
> There is another bug, using pci_default_write_config() doesn't fly as this 
> checks
> writes against wmask and the registers in question are not whitelisted ...
> 
> I've just rebased my igd patch series which (among other stuff) fixes that 
> bug:
>   https://www.kraxel.org/cgit/qemu/log/?h=work/igd
>   git://git.kraxel.org/qemu work/igd
> 
> Can you give it a spin?

The issue persist on this branch of tree (commit 1a0d06ce6), the VM kernel log 
attached in another mail while answered the following question.

> 
> Also: what does "can't boot up" mean exactly?  Guest doesn't boot at all?  
> Guest
> boots, but igd/console/Xorg doesn't work?  In case of the
> latter:  Any chance to login via network and get a kernel log?
> 
> thanks,
>   Gerd
> 

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

[Xen-devel] [qemu-upstream-4.4-testing baseline-only test] 38625: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 38625 qemu-upstream-4.4-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38625/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-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-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 qemuu2264b0c66075cc34c252a1386f019f8be6240890
baseline version:
 qemuu5fe74249f5ab528fe84a26fa60438a6de4c787f0

Last test of basis38139  2015-10-08 18:19:02 Z   96 days
Testing same since38625  2016-01-12 16:28:40 Z0 days1 attempts


People who touched revisions under test:
  Stefano Stabellini 

jobs:
 build-amd64-xend pass
 build-i386-xend  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  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-amd64-qemuu-nested-intel  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-amd64-amd64-pv  pass
 test-amd64-i386-pv   pass
 test-amd64-amd64-amd64-pvgrubpass
 test-amd64-amd64-i386-pvgrub pass
 test-amd64-amd64-pygrub  pass
 test-amd64-amd64-xl-qcow2pass
 test-amd64-i386-xl-raw   pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-libvirt-vhd pass
 test-amd64-amd64-xl-qemuu-winxpsp3   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 2264b0c66075cc34c252a1386f019f8be6240890
Author: Stefano Stabellini 
Date:   Fri Dec 18 15:45:14 2015 +

xenfb: avoid reading twice the same fields from the shared page

Reading twice the same field could give the guest an attack of
opportunity. In the case of event->type, gcc could compile the switch
statement into a jump table, effectively ending up reading 

Re: [Xen-devel] [PATCH] x86/hvm: Allow the guest to permit the use of userspace hypercalls

[Juergen Gross]

On 12/01/16 18:23, Stefano Stabellini wrote:
> On Tue, 12 Jan 2016, Juergen Gross wrote:
>> On 12/01/16 18:05, Stefano Stabellini wrote:
>>> On Tue, 12 Jan 2016, Jan Beulich wrote:
>>> On 12.01.16 at 13:07,  wrote:
> On Mon, 11 Jan 2016, David Vrabel wrote:
>> On 11/01/16 17:17, Andrew Cooper wrote:
>>> So from one point of view, sufficient justification for this change is
>>> "because the Linux way isn't the only valid way to do this".
>>
>> "Because we can" isn't a good justification for adding something new.
>> Particularly something that is trivially easy to (accidentally) misuse
>> and open a big security hole between userspace and kernel.
>>
>> The vague idea for a userspace netfront that's floating around
>> internally is also not a good reason for pushing this feature at this 
>> time.
>
> I agree with David, but I might have another good use case for this.
>
> Consider the following scenario: we have a Xen HVM guest, with Xen
> installed inside of it (nested virtualization). I'll refer to Xen
> running on the host as L0 Xen and Xen running inside the VM as L1 Xen.
> Similarly we have two dom0 running, the one with access to the physical
> hardware, L0 Dom0, and the one running inside the VM, L1 Dom0.
>
> Let's suppose that we want to lay the groundwork for L1 Dom0 to use PV
> frontend drivers, netfront and blkfront to speed up execution. In order
> to do that, the first thing it needs to do is making an hypercall to L0
> Xen. That's because netfront and blkfront needs to communicate with
> netback and blkback in L0 Dom0: event channels and grant tables are the
> ones provided by L0 Xen.

 That's again a layering violation (bypassing the L1 hypervisor).
>>>
>>> True, but in this scenario it might be necessary for performance
>>> reasons: otherwise every hypercall would need to bounce off L1 Xen,
>>> possibly cancelling the benefits of running netfront and blkfront in the
>>> first place. I don't have numbers though.
>>
>> How is this supposed to work? How can dom0 make hypercalls to L1 _or_ L0
>> hypervisor? How can it select the hypervisor it is talking to?
> 
>>From L0 Xen point of view, the guest is just a normal PV on HVM guest,
> it doesn't matter what's inside, so L1 Dom0 is going to make hypercalls
> to L0 Xen like any other PV on HVM guests: mapping the hypercall page by
> writing to the right MSR, retrieved via cpuid, then calling into the

But how to specify that cpuid/MSR should target the L0 hypervisor
instead of L1? And even if this would be working, just by mapping
the correct page the instructions doing the transition to the
hypervisor would still result in entering the L1 hypervisor, as
those instructions must be handled by L1 first in order to make
nested virtualization work.


Juergen

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

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

[Tian, Kevin]

> From: Xu, Quan
> Sent: Thursday, January 07, 2016 9:47 PM
> 
> > On January 07, 2016 9:28 PM,  wrote:
> > >>> On 07.01.16 at 02:39,  wrote:
> > > On January 06, 2016 7:26 PM,  wrote:
> > >> > I didn't think about the full logic thoroughly now. But it would
> > >> > always be good to not hide device now until a point where all
> > >> > related states have been cleaned up in error handling path chained up.
> > >> >
> > >
> > > Jan, could you help me to double check it? thanks.
> >
> > I'm not sure I understand what you want or need, the more that I didn't even
> > get around to look at the patches yet.
> >
> 
> Jan,
> Patch 2/3 and Patch 3/3 are based on v3 (Actually they are v3's patch 1/2 and 
> patch 2/2).
> We have discussed how to hide a device with pci_hide_device() when Device-TLB 
> flush is
> error.
> 
> Now there are 2 concerns:
>   1. Hide the PCI device may break the code path. (then the pdev->domain 
> is
> dom_xen)
>   2. Is the blew logic right?
>--If Device-TLB flush is timeout, we'll hide the target ATS device 
> and crash the
> domain owning this ATS device.
>  If impacted domain is hardware domain, just throw out a warning, 
> instead of
> crash the hardware domain.
> The hided Device will be disallowed to be further assigned to any 
> domain.
> 
> Kevin, correct me if I am wrong.
> 
> 

for 2, yes it's the policy we agreed in previous discussion.

for 1, after more thinking I think the concern is real. pci_hide_device
is used once in early boot-up phase. At that time, it's simple to just
have right owner configured. However in the path of normal device
assign/deassign, there are tons of more state associated which may
be related to the owner. Though we may do some special handling
in related code paths to have dom_xen specially handled, it's way
tricky and not easy to maintain.

I think the cleaner solution, similar to your earlier version, is to
set a flag and then continue existing calling chains with all required
error handling completed. Only at that place we can safely invoke
pci_hide_device. If outmost callers are scattered, we may do a 
lazy hide until next time when it's assigned to another guest while
the new flag is recognized.

Jan, your comments?

Thanks
Kevin

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

Re: [Xen-devel] [PATCH 1/2] libxl: fix _SC_GETPW_R_SIZE_MAX usage

[Doug Goldstein]

On 1/12/16 7:14 AM, Roger Pau Monne wrote:
> According to the FreeBSD sysconf man page [0] if the variable is associated
> with functionality that is not supported, -1 is returned and errno is not
> modified. Modify libxl__dm_runas_helper so it's able to correctly
> deal with this situation by setting the initial buffer value to 2048.
> 
> [0] https://www.freebsd.org/cgi/man.cgi?query=sysconf
> 
> Signed-off-by: Roger Pau Monné 
> ---
>  tools/libxl/libxl_dm.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 0aaefd9..ec8fb51 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -728,7 +728,14 @@ static int libxl__dm_runas_helper(libxl__gc *gc, const 
> char *username)
>  long buf_size;
>  int ret;
>  
> +errno = 0;
>  buf_size = sysconf(_SC_GETPW_R_SIZE_MAX);
> +if (buf_size < 0 && errno == 0) {
> +buf_size = 2048;
> +LOG(DEBUG,
> +"sysconf(_SC_GETPW_R_SIZE_MAX) is not supported, using a buffer size of %ld",
> +buf_size);
> +}
>  if (buf_size < 0) {
>  LOGE(ERROR, "sysconf(_SC_GETPW_R_SIZE_MAX) returned error %ld",
>  buf_size);
> 

So on Linux the behavior is somewhat similar [1]. But I took a peek at
the libvirt code for doing the similar thing and I notice that they just
default if the value is returned as less than 0 [2]. Reading both man
pages it seems like that would be the better bet instead of failing how
the current code is. Your fix probably makes it fail less but it could
still error out senselessly. Just a suggestion for an improvement overall.

[1] http://man7.org/linux/man-pages/man3/sysconf.3.html#RETURN_VALUE
[2]
http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/util/virutil.c;h=bb9604a0c1ffb9c99e454e84878a8c376f773046;hb=HEAD#l935

-- 
Doug Goldstein



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

[Xen-devel] [PATCH v2] x86/xsave: simplify xcomp_bv initialization

[Jan Beulich]

This simplifies a number of pointless conditionals: Bits 0 and 1 of
xcomp_bv don't matter anyway, and as long as none of bits 2..62 are
set, setting bit 63 is pointless too unless XSAVES is in use.

Signed-off-by: Jan Beulich 
---
v2: Retain setting of bit 63 on XSAVES-capable systems.

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -922,9 +922,8 @@ int arch_set_info_guest(
 if ( v->arch.xsave_area )
 {
 v->arch.xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
-if ( cpu_has_xsaves || cpu_has_xsavec )
-v->arch.xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP_SSE |
- 
XSTATE_COMPACTION_ENABLED;
+v->arch.xsave_area->xsave_hdr.xcomp_bv =
+cpu_has_xsaves ? XSTATE_COMPACTION_ENABLED : 0;
 }
 }
 else if ( v->arch.xsave_area )
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2094,9 +2094,8 @@ static int hvm_load_cpu_ctxt(struct doma
 
 memcpy(v->arch.xsave_area, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
 xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
-if ( cpu_has_xsaves || cpu_has_xsavec )
-xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP_SSE |
- XSTATE_COMPACTION_ENABLED;
+xsave_area->xsave_hdr.xcomp_bv =
+cpu_has_xsaves ? XSTATE_COMPACTION_ENABLED : 0;
 }
 else
 memcpy(v->arch.fpu_ctxt, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
@@ -5455,9 +5454,8 @@ void hvm_vcpu_reset_state(struct vcpu *v
 if ( v->arch.xsave_area )
 {
 v->arch.xsave_area->xsave_hdr.xstate_bv = XSTATE_FP;
-if ( cpu_has_xsaves || cpu_has_xsavec )
-v->arch.xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP |
- XSTATE_COMPACTION_ENABLED;
+v->arch.xsave_area->xsave_hdr.xcomp_bv =
+cpu_has_xsaves ? XSTATE_COMPACTION_ENABLED : 0;
 }
 
 v->arch.vgc_flags = VGCF_online;
--- a/xen/arch/x86/i387.c
+++ b/xen/arch/x86/i387.c
@@ -272,7 +272,7 @@ int vcpu_init_fpu(struct vcpu *v)
 if ( v->arch.xsave_area )
 {
 v->arch.fpu_ctxt = >arch.xsave_area->fpu_sse;
-if ( cpu_has_xsaves || cpu_has_xsavec )
+if ( cpu_has_xsaves )
 v->arch.xsave_area->xsave_hdr.xcomp_bv = XSTATE_COMPACTION_ENABLED;
 }
 else



x86/xsave: simplify xcomp_bv initialization

This simplifies a number of pointless conditionals: Bits 0 and 1 of
xcomp_bv don't matter anyway, and as long as none of bits 2..62 are
set, setting bit 63 is pointless too unless XSAVES is in use.

Signed-off-by: Jan Beulich 
---
v2: Retain setting of bit 63 on XSAVES-capable systems.

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -922,9 +922,8 @@ int arch_set_info_guest(
 if ( v->arch.xsave_area )
 {
 v->arch.xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
-if ( cpu_has_xsaves || cpu_has_xsavec )
-v->arch.xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP_SSE |
- 
XSTATE_COMPACTION_ENABLED;
+v->arch.xsave_area->xsave_hdr.xcomp_bv =
+cpu_has_xsaves ? XSTATE_COMPACTION_ENABLED : 0;
 }
 }
 else if ( v->arch.xsave_area )
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2094,9 +2094,8 @@ static int hvm_load_cpu_ctxt(struct doma
 
 memcpy(v->arch.xsave_area, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
 xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
-if ( cpu_has_xsaves || cpu_has_xsavec )
-xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP_SSE |
- XSTATE_COMPACTION_ENABLED;
+xsave_area->xsave_hdr.xcomp_bv =
+cpu_has_xsaves ? XSTATE_COMPACTION_ENABLED : 0;
 }
 else
 memcpy(v->arch.fpu_ctxt, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
@@ -5455,9 +5454,8 @@ void hvm_vcpu_reset_state(struct vcpu *v
 if ( v->arch.xsave_area )
 {
 v->arch.xsave_area->xsave_hdr.xstate_bv = XSTATE_FP;
-if ( cpu_has_xsaves || cpu_has_xsavec )
-v->arch.xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP |
- XSTATE_COMPACTION_ENABLED;
+v->arch.xsave_area->xsave_hdr.xcomp_bv =
+cpu_has_xsaves ? XSTATE_COMPACTION_ENABLED : 0;
 }
 
 v->arch.vgc_flags = VGCF_online;
--- a/xen/arch/x86/i387.c
+++ b/xen/arch/x86/i387.c
@@ -272,7 +272,7 @@ int vcpu_init_fpu(struct vcpu *v)
 if ( v->arch.xsave_area )
 {
 v->arch.fpu_ctxt = >arch.xsave_area->fpu_sse;
-if ( cpu_has_xsaves || cpu_has_xsavec )
+if ( cpu_has_xsaves )
 v->arch.xsave_area->xsave_hdr.xcomp_bv = XSTATE_COMPACTION_ENABLED;
 }
 else
___
Xen-devel mailing list

[Xen-devel] [PATCH] tools: fix python install with "xentoollog"

[Konrad Rzeszutek Wilk]

commit 5d3dc8671521ea4a4f753e77d3e7fb3a3a6f5f80
"tools: Refactor "xentoollog" into its own library"
with older python versions (2.6.4) will fail to
the build if attempted to be done twice (which
happens due to pygrub dependencies).

make -C python DESTDIR=/tmp
make -C python DESTDIR=/tmp

The second one will fail with:
error: -Wl, -rpath-link=../../tools/libs/toollog: No such file or directory

even thought the directory is there (with the libs).

Andrew pointed out that the linker additions should be in
the "extra_link_args" rather than "depends".

And true enough - with that modification it builds.

CC: Ian Campbell 
CC: Ian Jackson 
CC: Wei Liu 
CC: Boris Ostrovsky 
Suggested-by: Andrew Cooper 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 tools/python/setup.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/python/setup.py b/tools/python/setup.py
index 9771cc4..604b314 100644
--- a/tools/python/setup.py
+++ b/tools/python/setup.py
@@ -17,7 +17,8 @@ xc = Extension("xc",
include_dirs   = [ PATH_XEN, PATH_LIBXENTOOLLOG + 
"/include", PATH_LIBXC + "/include", "xen/lowlevel/xc" ],
library_dirs   = [ PATH_LIBXC ],
libraries  = [ "xenctrl", "xenguest" ],
-   depends= [ PATH_LIBXC + "/libxenctrl.so", 
PATH_LIBXC + "/libxenguest.so",  "-Wl,-rpath-link="+PATH_LIBXENTOOLLOG ],
+   depends= [ PATH_LIBXC + "/libxenctrl.so", 
PATH_LIBXC + "/libxenguest.so" ],
+   extra_link_args= [ "-Wl,-rpath-link="+PATH_LIBXENTOOLLOG ],
sources= [ "xen/lowlevel/xc/xc.c" ])
 
 xs = Extension("xs",
-- 
2.5.0


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

Re: [Xen-devel] [PATCH v2 1/2] build: introduce CONFIG_NR_CPUS in Kconfig

[Jan Beulich]

>>> On 11.01.16 at 23:02,  wrote:
> --- /dev/null
> +++ b/xen/arch/Kconfig
> @@ -0,0 +1,8 @@
> +
> +config NR_CPUS
> + int "Maximum number of physical CPUs"
> + range 1 65536

Why did you change this to 64k, when we settled on 4k-1 being
correct? I don't mind fixing this up upon commit, but I'd like it to
be confirmed that this was unintentional.

Jan


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

Re: [Xen-devel] [PATCH v2] x86/hvm: Allow the guest to permit the use of userspace hypercalls

[Jan Beulich]

>>> On 11.01.16 at 17:51,  wrote:
> Currently, hypercalls issued from HVM userspace will unconditionally fail 
> with
> -EPERM.
> 
> This is inflexible, and a guest may wish to allow userspace to make
> hypercalls.
> 
> Introduce HVMOP_set_hypercall_dpl which allows the guest to alter the
> permissions check for hypercalls.  It behaves exactly like the dpl field for
> GDT/LDT/IDT entries.
> 
> As the dpl is initialised to 0, hypercalls are restricted to cpl0 code until
> the OS explicitly chooses an alternative.
> 
> Signed-off-by: Andrew Cooper 
> --
> CC: Jan Beulich 
> CC: Ian Campbell 
> CC: Stefano Stabellini 
> 
> v2:
>  * Fix rcu lock and dpl check.

That's a bold statement considering ...

> @@ -6839,6 +6840,31 @@ long do_hvm_op(unsigned long op, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
>  rc = do_altp2m_op(arg);
>  break;
>  
> +case HVMOP_set_hypercall_dpl:
> +{
> +xen_hvm_hypercall_dpl_t a;
> +struct domain *d;
> +
> +if ( copy_from_guest(, arg, 1 ) )
> +return -EFAULT;
> +
> +d = rcu_lock_domain_by_any_id(a.domid);
> +if ( d == NULL )
> +return -ESRCH;
> +
> +if ( current->domain != d )
> +return -EPERM;
> +
> +if ( !is_hvm_domain(d) )
> +return -EINVAL;
> +
> +if ( a.dpl > 3 )
> +return -EDOM;
> +
> +d->arch.hvm_domain.hypercall_dpl = a.dpl;
> +break;
> +}

... there's no unlock anywhere here.

Jan


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

Re: [Xen-devel] [Qemu-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()

[Michael S. Tsirkin]

OK - it's possible that this patch
commit 349a3b1cc9023f67f8fa336cb3c4a8f21a4aaaf3
Author: Cao jin 
Date:   Sat Jan 2 16:02:20 2016 +0800

igd-passthrough: fix use of host_pci_config_read

is required for older guests.
This patch just went it - could you test latest master please?

On Tue, Jan 12, 2016 at 08:41:13AM +, Hao, Xudong wrote:
> Yes, Linux VM update to a 3.18 kernel.
> The RHEL7.2 default kernel (should be 3.10) VM don't boot up with IGD 
> pass-through, and Windows can't boot up either.
> 
> Thanks,
> -Xudong
> 
> 
> > -Original Message-
> > From: Gerd Hoffmann [mailto:kra...@redhat.com]
> > Sent: Monday, January 11, 2016 6:32 PM
> > To: Hao, Xudong 
> > Cc: Stefano Stabellini ; Lars Kurth
> > ; xen-de...@lists.xensource.com; Michael S. Tsirkin
> > ; Lars Kurth ; qemu-
> > de...@nongnu.org; Cao jin ; Stefano Stabellini
> > 
> > Subject: Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX:
> > convert to realize()
> > 
> >   Hi,
> > 
> > > I can boot up Linux VM with IGD pass-through with latest qemu (without
> > > any additional patch), guest run 3D "nexuiz" and get 180fps.
> > 
> > That is a pretty recent linux guest I assume?
> > Tried older kernels too, possibly even the old userspace xorg driver?
> > Do windows guest work as well?
> > 
> > cheers,
> >   Gerd
> 

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

Re: [Xen-devel] Nested virtualization off VMware vSphere 6.0 with EL6 guests crashes on Xen 4.6

[Jan Beulich]

>>> On 12.01.16 at 04:38,  wrote:
> (XEN) Assertion 'vapic_pg && !p2m_is_paging(p2mt)' failed at vvmx.c:698
> (XEN) [ Xen-4.6.0  x86_64  debug=y  Tainted:C ]
> (XEN) CPU:39
> (XEN) RIP:e008:[] virtual_vmentry+0x487/0xac9
> (XEN) RFLAGS: 00010246   CONTEXT: hypervisor (d1v3)
> (XEN) rax:    rbx: 83007786c000   rcx: 
> (XEN) rdx: 0e00   rsi: 000f   rdi: 83407f81e010
> (XEN) rbp: 834008a47ea8   rsp: 834008a47e38   r8: 
> (XEN) r9:     r10:    r11: 
> (XEN) r12:    r13: 82c000341000   r14: 834008a47f18
> (XEN) r15: 83407f7c4000   cr0: 80050033   cr4: 001526e0
> (XEN) cr3: 00407fb22000   cr2: 
> (XEN) ds:    es:    fs:    gs:    ss:    cs: e008
> (XEN) Xen stack trace from rsp=834008a47e38:
> (XEN)834008a47e68 82d0801d2cde 834008a47e68 0d00
> (XEN)  834008a47e88 0004801cc30e
> (XEN)83007786c000 83007786c000 834008a4 
> (XEN)834008a47f18  834008a47f08 82d0801edf94
> (XEN)834008a47ef8  834008f62000 834008a47f18
> (XEN)00ae8c99eb8d 83007786c000  
> (XEN)   82d0801ee2ab
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN)078bfbff   beefbeef
> (XEN)fc4b3440 00bfbeef 00040046 fc607f00
> (XEN)beef beef beef beef
> (XEN)beef 0027 83007786c000 006f88716300
> (XEN)
> (XEN) Xen call trace:
> (XEN)[] virtual_vmentry+0x487/0xac9
> (XEN)[] nvmx_switch_guest+0x8ff/0x915
> (XEN)[] vmx_asm_vmexit_handler+0x4b/0xc0
> (XEN)
> (XEN)
> (XEN) 
> (XEN) Panic on CPU 39:
> (XEN) Assertion 'vapic_pg && !p2m_is_paging(p2mt)' failed at vvmx.c:698
> (XEN) 
> (XEN)
> 
> ..and then to my surprise the hypervisor stopped hitting this.

Since we can (I hope) pretty much exclude a paging type, the
ASSERT() must have triggered because of vapic_pg being NULL.
That might be verifiable without extra printk()s, just by checking
the disassembly (assuming the value sits in a register). In which
case vapic_gpfn would be of interest too.

What looks odd to me is the connection between
CPU_BASED_TPR_SHADOW being set and the use of a (valid)
virtual APIC page: Wouldn't this rather need to depend on
SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES, just like in
nvmx_update_apic_access_address()?

Anyway, the writing of the respective VMCS field to zero in the
alternative worries me a little: Aren't we risking MFN zero to be
wrongly accessed due to this?

Furthermore, nvmx_update_apic_access_address() having a
similar ASSERT() seems entirely wrong: The APIC access
page doesn't really need to match up with any actual page
belonging to the guest - a guest could choose to point this
into no-where (note that we've been at least considering this
option recently for our own purposes, in the context of
http://lists.xenproject.org/archives/html/xen-devel/2015-12/msg02191.html).

> Instead I started getting an even more bizzare crash:
> 
> 
> (d1) enter handle_19:
> (d1)   NULL
> (d1) Booting from Hard Disk...
> (d1) Booting from :7c00
> (XEN) stdvga.c:151:d1v0 leaving stdvga mode
> (XEN) stdvga.c:147:d1v0 entering stdvga and caching modes
> (XEN) stdvga.c:520:d1v0 leaving caching mode
> (XEN) [ Xen-4.6.0  x86_64  debug=y  Tainted:C ]
> (XEN) CPU:3
> (XEN) RIP:e008:[] vmx_cpu_up+0xacc/0xba5
> (XEN) RFLAGS: 00010242   CONTEXT: hypervisor (d1v1)
> (XEN) rax:    rbx: 830077877000   rcx: 834077e54000
> (XEN) rdx: 834007dc8000   rsi: 2000   rdi: 830077877000
> (XEN) rbp: 834007dcfc48   rsp: 834007dcfc38   r8:  0404
> (XEN) r9:  000ff000   r10:    r11: fc423f1e
> (XEN) r12: 2000   r13:    r14: 
> (XEN) r15:    cr0: 80050033   cr4: 001526e0
> (XEN) cr3: 004000763000   cr2: 
> (XEN) ds:    es:    fs:    gs:    ss:    cs: e008
> (XEN) Xen stack trace from rsp=834007dcfc38:
> (XEN)834007dcfc98  834007dcfc68 82d0801e2533
> (XEN)830077877000 2000 834007dcfc78 82d0801ea933
> 

Re: [Xen-devel] [Qemu-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()

[Hao, Xudong]

With latest qemu 7b8a354d4716, RHEL7.2 (with default kernel) VM still can't 
boot up with IGD.

Thanks,
-Xudong


> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Tuesday, January 12, 2016 4:48 PM
> To: Hao, Xudong 
> Cc: Gerd Hoffmann ; Stefano Stabellini
> ; Lars Kurth ; xen-
> de...@lists.xensource.com; Lars Kurth ; qemu-
> de...@nongnu.org; Cao jin ; Stefano Stabellini
> 
> Subject: Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX:
> convert to realize()
> 
> OK - it's possible that this patch
>   commit 349a3b1cc9023f67f8fa336cb3c4a8f21a4aaaf3
>   Author: Cao jin 
>   Date:   Sat Jan 2 16:02:20 2016 +0800
> 
>   igd-passthrough: fix use of host_pci_config_read
> 
> is required for older guests.
> This patch just went it - could you test latest master please?
> 
> On Tue, Jan 12, 2016 at 08:41:13AM +, Hao, Xudong wrote:
> > Yes, Linux VM update to a 3.18 kernel.
> > The RHEL7.2 default kernel (should be 3.10) VM don't boot up with IGD pass-
> through, and Windows can't boot up either.
> >
> > Thanks,
> > -Xudong
> >
> >
> > > -Original Message-
> > > From: Gerd Hoffmann [mailto:kra...@redhat.com]
> > > Sent: Monday, January 11, 2016 6:32 PM
> > > To: Hao, Xudong 
> > > Cc: Stefano Stabellini ; Lars
> > > Kurth ; xen-de...@lists.xensource.com;
> > > Michael S. Tsirkin ; Lars Kurth
> > > ; qemu- de...@nongnu.org; Cao jin
> > > ; Stefano Stabellini
> > > 
> > > Subject: Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX:
> > > convert to realize()
> > >
> > >   Hi,
> > >
> > > > I can boot up Linux VM with IGD pass-through with latest qemu
> > > > (without any additional patch), guest run 3D "nexuiz" and get 180fps.
> > >
> > > That is a pretty recent linux guest I assume?
> > > Tried older kernels too, possibly even the old userspace xorg driver?
> > > Do windows guest work as well?
> > >
> > > cheers,
> > >   Gerd
> >

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

[Xen-devel] [PATCH v7 2/2] public/io/netif.h: document control ring and toeplitz hashing

[Paul Durrant]

This patch documents a new shared ring between frontend and backend that
can be used to pass bulk out-of-band data, such as that required to
implement toeplitz hashing in the backend such that it is configurable by
the frontend (which is needed to support NDIS RSS for Windows guests).

The patch then goes on to document the messages passed over the control
ring that can be used to configure toeplitz hashing and a new extra info
fragment that can be used to pass hash values between frontend and
backend for both transmit and receive packets.

Signed-off-by: Paul Durrant 
Cc: Ian Campbell 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
---
v7:
 - s/feature-control-ring/feature-ctrl-ring/g for consistency

v5:
 - Clarify the control API for toeplitz hashing in many places.
 - Add messages for getting and setting mapping table order to allow
   for a table that is larger than can be mapped by a single grant
   reference.
 - Fold in the definition of the new extra info type for passing
   hash values and make it toeplitz specific.

v4:
 - Fix netif_ctrl_response_t definition to match specification.

v3:
 - Fix commit comment.

v2:
 - Use a balanced fix-sized message ring for the control ring
   (bulk data now passed by grant reference).
---
 xen/include/public/io/netif.h | 380 +-
 1 file changed, 379 insertions(+), 1 deletion(-)

diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h
index 0a3272f..fe0a87f 100644
--- a/xen/include/public/io/netif.h
+++ b/xen/include/public/io/netif.h
@@ -151,6 +151,361 @@
  */
 
 /*
+ * Control ring
+ * 
+ *
+ * Some features, such as toeplitz hashing (detailed below), require a
+ * significant amount of out-of-band data to be passed from frontend to
+ * backend. Use of xenstore is not suitable for large quantities of data
+ * because of quota limitations and so a dedicated 'control ring' is used.
+ * The ability of the backend to use a control ring is advertised by
+ * setting:
+ *
+ * /local/domain/X/backend///feature-ctrl-ring = "1"
+ *
+ * The frontend provides a control ring to the backend by setting:
+ *
+ * /local/domain//device/vif//ctrl-ring-ref = 
+ * /local/domain//device/vif//event-channel-ctrl = 
+ *
+ * where  is the grant reference of the shared page used to
+ * implement the control ring and  is an event channel to be used
+ * as a mailbox interrupt. These keys must be set before the frontend
+ * moves into the connected state.
+ *
+ * The control ring uses a fixed request/response message size and is
+ * balanced (i.e. one request to one response), so operationally it is much
+ * the same as a transmit or receive ring.
+ * Note that there is no requirement that responses are issued in the same
+ * order as requests.
+ */
+
+/*
+ * Toeplitz hash types
+ * ===
+ *
+ * For the purposes of the definitions below, 'Packet[]' is an array of
+ * octets containing an IP packet without options, 'Array[X..Y]' means a
+ * sub-array of 'Array' containing bytes X thru Y inclusive, and '+' is
+ * used to indicate concatenation of arrays.
+ */
+
+/*
+ * A hash calculated over an IP version 4 header as follows:
+ *
+ * Buffer[0..8] = Packet[12..15] (source address) +
+ *Packet[16..19] (destination address)
+ *
+ * Result = ToeplitzHash(Buffer, 8)
+ */
+#define _NETIF_CTRL_TOEPLITZ_HASH_IPV4 0
+#define NETIF_CTRL_TOEPLITZ_HASH_IPV4  (1 << 
_NETIF_CTRL_TOEPLITZ_HASH_IPV4)
+
+/*
+ * A hash calculated over an IP version 4 header and TCP header as
+ * follows:
+ *
+ * Buffer[0..12] = Packet[12..15] (source address) +
+ * Packet[16..19] (destination address) +
+ * Packet[20..21] (source port) +
+ * Packet[22..23] (destination port)
+ *
+ * Result = ToeplitzHash(Buffer, 12)
+ */
+#define _NETIF_CTRL_TOEPLITZ_HASH_IPV4_TCP 1
+#define NETIF_CTRL_TOEPLITZ_HASH_IPV4_TCP  (1 << 
_NETIF_CTRL_TOEPLITZ_HASH_IPV4_TCP)
+
+/*
+ * A hash calculated over an IP version 6 header as follows:
+ *
+ * Buffer[0..32] = Packet[8..23]  (source address ) +
+ * Packet[24..39] (destination address)
+ *
+ * Result = ToeplitzHash(Buffer, 32)
+ */
+#define _NETIF_CTRL_TOEPLITZ_HASH_IPV6 2
+#define NETIF_CTRL_TOEPLITZ_HASH_IPV6  (1 << 
_NETIF_CTRL_TOEPLITZ_HASH_IPV4)
+
+/*
+ * A hash calculated over an IP version 6 header and TCP header as
+ * follows:
+ *
+ * Buffer[0..36] = Packet[8..23]  (source address) +
+ * Packet[24..39] (destination address) +
+ * Packet[40..41] (source port) +
+ * Packet[42..43] (destination port)
+ *
+ * Result = ToeplitzHash(Buffer, 36)
+ */
+#define _NETIF_CTRL_TOEPLITZ_HASH_IPV6_TCP 3
+#define NETIF_CTRL_TOEPLITZ_HASH_IPV6_TCP  (1 << 
_NETIF_CTRL_TOEPLITZ_HASH_IPV4_TCP)
+
+/*
+ * Control requests 

[Xen-devel] [PATCH v7 1/2] public/io/netif.h: clarifications to wire formats

[Paul Durrant]

My previous patch 03809ae7 "document transmit and receive wire formats
separately" improved documentation of the receive and transmit wire
formats but further clarifications were requested.

This patch adds those clarifications.

Signed-off-by: Paul Durrant 
Cc: Ian Campbell 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
---

v6:
 - v4 of the original patch was committed so this is an
   incremental version of the patch in v5.

v5:
 - Add extra clarifications.
---
 xen/include/public/io/netif.h | 28 
 1 file changed, 24 insertions(+), 4 deletions(-)

diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h
index 1790ea0..0a3272f 100644
--- a/xen/include/public/io/netif.h
+++ b/xen/include/public/io/netif.h
@@ -154,19 +154,29 @@
  * Guest transmit
  * ==
  *
- * This is the 'wire' format for packets:
+ * This is the 'wire' format for transmit (frontend -> backend) packets:
+ *
  *  Fragment 1: netif_tx_request_t  - flags = NETTXF_*
  *size = total packet size
  * [Extra 1: netif_extra_info_t]- (only if fragment 1 flags include
  * NETTXF_extra_info)
+ *  ...
  * [Extra N: netif_extra_info_t]- (only if extra N-1 flags include
  * XEN_NETIF_EXTRA_MORE)
  *  ...
  *  Fragment N: netif_tx_request_t  - (only if fragment N-1 flags include
- * NETTXF_more_data)
+ * NETTXF_more_data - flags on preceding
+ * extras are not relevent here)
  *flags = 0
  *size = fragment size
  *
+ * NOTE:
+ *
+ * This format slightly is different from that used for receive
+ * (backend -> frontend) packets. Specifically, in a multi-fragment
+ * packet the actual size of fragment 1 can only be determined by
+ * subtracting the sizes of fragments 2..N from the total packet size.
+ *
  * Ring slot size is 12 octets, however not all request/response
  * structs use the full size.
  *
@@ -202,19 +212,29 @@
  * Guest receive
  * =
  *
- * This is the 'wire' format for packets:
+ * This is the 'wire' format for receive (backend -> frontend) packets:
+ *
  *  Fragment 1: netif_rx_request_t  - flags = NETRXF_*
  *size = fragment size
  * [Extra 1: netif_extra_info_t]- (only if fragment 1 flags include
  * NETRXF_extra_info)
+ *  ...
  * [Extra N: netif_extra_info_t]- (only if extra N-1 flags include
  * XEN_NETIF_EXTRA_MORE)
  *  ...
  *  Fragment N: netif_rx_request_t  - (only if fragment N-1 flags include
- * NETRXF_more_data)
+ * NETRXF_more_data - flags on preceding
+ * extras are not relevent here)
  *flags = 0
  *size = fragment size
  *
+ * NOTE:
+ *
+ * This format slightly is different from that used for transmit
+ * (frontend -> backend) packets. Specifically, in a multi-fragment
+ * packet the size of the packet can only be determined by summing the
+ * sizes of fragments 1..N.
+ *
  * Ring slot size is 8 octets.
  *
  * rx request (netif_rx_request_t)
-- 
2.1.4


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

[Xen-devel] [ovmf test] 77825: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 65543
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 65543

version targeted for testing:
 ovmf 819a2394f17f6e4e97893481e4acb95401e7b380
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z   34 days
Failing since 65593  2015-12-08 23:44:51 Z   34 days   20 attempts
Testing same since77825  2016-01-11 11:52:35 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Yao, Jiewen" 
  Andrew Fish 
  Ard Biesheuvel 
  Cecil Sheng 
  Chao Zhang 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  Eric Dong 
  Eric Dong 
  Eugene Cohen 
  Feng Tian 
  Fu Siyuan 
  Hao Wu 
  Hess Chen 
  Heyi Guo 
  Jaben Carsey 
  Jeff Fan 
  Jiaxin Wu 
  Jim Dailey 
  Jordan Justen 
  Larry Hauch 
  Laszlo Ersek 
  Leekha Shaveta 
  Liming Gao 
  Mark Rutland 
  Michael Kinney 
  Michael Thomas 
  Paulo Alcantara 
  Qin Long 
  Qiu Shumin 
  Ruiyu Ni 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Star Zeng 
  Tapan Shah 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zhang Lubo 

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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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

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

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

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


Not pushing.

(No revision log; it would be 4855 lines long.)

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

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

[Michael S. Tsirkin]

On Mon, Jan 11, 2016 at 05:14:14PM -0800, Leonid Yegoshin wrote:
> On 01/10/2016 06:18 AM, Michael S. Tsirkin wrote:
> >On mips dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends,
> >smp_read_barrier_depends, smp_store_release and smp_load_acquire  match
> >the asm-generic variants exactly. Drop the local definitions and pull in
> >asm-generic/barrier.h instead.
> >
> This statement doesn't fit MIPS barriers variations. Moreover, there is a
> reason to extend that even more specific, at least for smp_store_release and
> smp_load_acquire, look into
> 
> http://patchwork.linux-mips.org/patch/10506/
> 
> - Leonid.

Fine, but it matches what current code is doing.  Since that
MIPS_LIGHTWEIGHT_SYNC patch didn't go into linux-next yet, do
you see a problem reworking it on top of this patchset?

-- 
MST

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

Re: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()

[Hao, Xudong]

> -Original Message-
> From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com]
> Sent: Monday, January 11, 2016 6:46 PM
> To: Hao, Xudong 
> Cc: Stefano Stabellini ; Lars Kurth
> ; Lars Kurth ; Cao jin
> ; xen-de...@lists.xensource.com; Stefano Stabellini
> ; qemu-de...@nongnu.org; Michael S. Tsirkin
> 
> Subject: RE: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to 
> realize()
> 
> On Mon, 11 Jan 2016, Hao, Xudong wrote:
> > Stefano,
> >
> > Patch http://marc.info/?l=qemu-devel=145137863501079 don't works for
> qemu at all, some conflict when git apply.
> > Patch http://marc.info/?l=qemu-devel=145137863501079 is based on
> patch http://marc.info/?l=qemu-devel=145172165010604, right?
> >
> > I can boot up Linux VM with IGD pass-through with latest qemu (without any
> additional patch), guest run 3D "nexuiz" and get 180fps.
> 
> Very interesting, thanks for testing.
> 
The Linux VM's kernel is 3.18.

> 
> > Will try the two patch together later.
> 
> That would be useful
> 
With the two patch, Linux VM (with 3.18) boot up successfully. RHEL7.2(default 
kernel 3.10) and Windows8.1 VM boot up fail with IGD pass-through.
The result is same w/o these two patches.
 
> 
> > > -Original Message-
> > > From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com]
> > > Sent: Friday, January 8, 2016 7:57 PM
> > > To: Hao, Xudong 
> > > Cc: Stefano Stabellini ; Lars
> > > Kurth ; Lars Kurth
> > > ; Cao jin ;
> > > xen-de...@lists.xensource.com; Stefano Stabellini
> > > ; qemu-de...@nongnu.org; Michael S.
> > > Tsirkin 
> > > Subject: RE: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert
> > > to realize()
> > >
> > > Since you are at it, could you please let me know how well igd
> > > passthrough works without this bugfix:
> > >
> > > http://marc.info/?l=qemu-devel=145172165010604
> > >
> > > which is about to land in QEMU.  I guess it doesn't work at all?
> > >
> > > I am asking because I would like to know the level of support we
> > > need to provide to igd passthrough with the latest QEMU release (2.5).
> > >
> > >
> > > On Thu, 7 Jan 2016, Hao, Xudong wrote:
> > > > Sure. I'll test it soon.
> > > >
> > > > Thanks,
> > > > -Xudong
> > > >
> > > > > -Original Message-
> > > > > From: Stefano Stabellini
> > > > > [mailto:stefano.stabell...@eu.citrix.com]
> > > > > Sent: Wednesday, January 6, 2016 8:18 PM
> > > > > To: Lars Kurth 
> > > > > Cc: Stefano Stabellini ; Hao,
> > > > > Xudong ; Lars Kurth
> > > > > ; Cao jin ;
> > > > > xen-de...@lists.xensource.com; Stefano Stabellini
> > > > > ; qemu-de...@nongnu.org; Michael
> > > > > S. Tsirkin 
> > > > > Subject: Re: [Xen-devel] [PATCH v4] igd-passthrough-i440FX:
> > > > > convert to realize()
> > > > >
> > > > > Hello Xudong,
> > > > >
> > > > > please test this patch:
> > > > >
> > > > > http://marc.info/?l=qemu-devel=145137863501079
> > > > >
> > > > > with an intel graphic card assigned to a Xen guest. If
> > > > > everything still works as expected, please reply with your Tested-by.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Stefano
> > > > >
> > > > > On Wed, 6 Jan 2016, Lars Kurth wrote:
> > > > > > Hi folks,
> > > > > > let me introduce you to Xudong from Intel, who is willing to help 
> > > > > > out.
> > > > > > Best Regards
> > > > > > Lars
> > > > > >
> > > > > > > On 4 Jan 2016, at 15:41, Stefano Stabellini
> > > > > > > 
> > > > > wrote:
> > > > > > >
> > > > > > > On Mon, 4 Jan 2016, Lars Kurth wrote:
> > > > > > >> On 04/01/2016 14:47, "Stefano Stabellini"
> > > > > > >>  wrote:
> > > > > > >>
> > > > > > >>> Unfortunately I don't have a setup to test this either.
> > > > > > >>> Maybe Lars can find out who should be involved on the Intel side
> on this.
> > > > > > >>
> > > > > > >> I can certainly help to this and get back to you. What
> > > > > > >> exactly are we asking Intel to do?
> > > > > > >> It is not clear to me from this email thread
> > > > > > >
> > > > > > > Tiejun Chen, the author of the Intel graphic card
> > > > > > > passthrough patches for QEMU, seems to have left the
> > > > > > > company. It would be nice if somebody else tested this patch
> > > > > > > with an intel graphic card assigned to a guest VM.
> > > > > > >
> > > > > > > ___
> > > > > > > Xen-devel mailing list
> > > > > > > Xen-devel@lists.xen.org
> > > > > > > 

Re: [Xen-devel] [PATCH v2 2/2] build: convert NR_CPUS to Kconfig

[Jan Beulich]

>>> On 11.01.16 at 23:02,  wrote:
> --- a/xen/include/xen/config.h
> +++ b/xen/include/xen/config.h
> @@ -92,4 +92,7 @@
>  #define FLASK_AVC_STATS 1
>  #endif
>  
> +/* allow existing code to work with Kconfig variable */
> +#define NR_CPUS CONFIG_NR_CPUS

Perhaps here or in a follow-up patch derive CONFIG_SMP (used in a
few places in ARM code) from NR_CPUS > 1?

Jan


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

Re: [Xen-devel] [Qemu-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()

[Hao, Xudong]

Yes, Linux VM update to a 3.18 kernel.
The RHEL7.2 default kernel (should be 3.10) VM don't boot up with IGD 
pass-through, and Windows can't boot up either.

Thanks,
-Xudong


> -Original Message-
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Monday, January 11, 2016 6:32 PM
> To: Hao, Xudong 
> Cc: Stefano Stabellini ; Lars Kurth
> ; xen-de...@lists.xensource.com; Michael S. Tsirkin
> ; Lars Kurth ; qemu-
> de...@nongnu.org; Cao jin ; Stefano Stabellini
> 
> Subject: Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX:
> convert to realize()
> 
>   Hi,
> 
> > I can boot up Linux VM with IGD pass-through with latest qemu (without
> > any additional patch), guest run 3D "nexuiz" and get 180fps.
> 
> That is a pretty recent linux guest I assume?
> Tried older kernels too, possibly even the old userspace xorg driver?
> Do windows guest work as well?
> 
> cheers,
>   Gerd

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

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

[Peter Zijlstra]

On Mon, Jan 11, 2016 at 05:14:14PM -0800, Leonid Yegoshin wrote:

> This statement doesn't fit MIPS barriers variations. Moreover, there is a
> reason to extend that even more specific, at least for smp_store_release and
> smp_load_acquire, look into
> 
> http://patchwork.linux-mips.org/patch/10506/

Dude, that's one horrible patch.

1) you do not make such things selectable; either the hardware needs
them or it doesn't. If it does you _must_ use them, however unlikely.

2) the changelog _completely_ fails to explain the sync 0x11 and sync
0x12 semantics nor does it provide a publicly accessible link to
documentation that does.

3) it really should have explained what you did with
smp_llsc_mb/smp_mb__before_llsc() in _detail_.

And I agree that ideally it should be split into parts.

Seriously, this is _NOT_ OK.

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

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

[Peter Zijlstra]

On Tue, Jan 12, 2016 at 10:43:36AM +0200, Michael S. Tsirkin wrote:
> On Mon, Jan 11, 2016 at 05:14:14PM -0800, Leonid Yegoshin wrote:
> > On 01/10/2016 06:18 AM, Michael S. Tsirkin wrote:
> > >On mips dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends,
> > >smp_read_barrier_depends, smp_store_release and smp_load_acquire  match
> > >the asm-generic variants exactly. Drop the local definitions and pull in
> > >asm-generic/barrier.h instead.
> > >
> > This statement doesn't fit MIPS barriers variations. Moreover, there is a
> > reason to extend that even more specific, at least for smp_store_release and
> > smp_load_acquire, look into
> > 
> > http://patchwork.linux-mips.org/patch/10506/
> > 
> > - Leonid.
> 
> Fine, but it matches what current code is doing.  Since that
> MIPS_LIGHTWEIGHT_SYNC patch didn't go into linux-next yet, do
> you see a problem reworking it on top of this patchset?

That patch is a complete doorstop atm. It needs a lot more work before
it can go anywhere. Don't worry about it.

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

Re: [Xen-devel] [PATCH v6 2/2] public/io/netif.h: document control ring and toeplitz hashing

[Paul Durrant]

> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 11 January 2016 16:05
> To: xen-de...@lists.xenproject.org
> Cc: Paul Durrant; Ian Campbell; Ian Jackson; Jan Beulich; Keir (Xen.org); Tim
> (Xen.org)
> Subject: [PATCH v6 2/2] public/io/netif.h: document control ring and toeplitz
> hashing
> 
> This patch documents a new shared ring between frontend and backend that
> can be used to pass bulk out-of-band data, such as that required to
> implement toeplitz hashing in the backend such that it is configurable by
> the frontend (which is needed to support NDIS RSS for Windows guests).
> 
> The patch then goes on to document the messages passed over the control
> ring that can be used to configure toeplitz hashing and a new extra info
> fragment that can be used to pass hash values between frontend and
> backend for both transmit and receive packets.
> 
> Signed-off-by: Paul Durrant 
> Cc: Ian Campbell 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Keir Fraser 
> Cc: Tim Deegan 
> ---
> v5:
>  - Clarify the control API for toeplitz hashing in many places.
>  - Add messages for getting and setting mapping table order to allow
>for a table that is larger than can be mapped by a single grant
>reference.
>  - Fold in the definition of the new extra info type for passing
>hash values and make it toeplitz specific.
> 
> v4:
>  - Fix netif_ctrl_response_t definition to match specification.
> 
> v3:
>  - Fix commit comment.
> 
> v2:
>  - Use a balanced fix-sized message ring for the control ring
>(bulk data now passed by grant reference).
> ---
>  xen/include/public/io/netif.h | 380
> +-
>  1 file changed, 379 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h
> index 0a3272f..e437d6d 100644
> --- a/xen/include/public/io/netif.h
> +++ b/xen/include/public/io/netif.h
> @@ -151,6 +151,361 @@
>   */
> 
>  /*
> + * Control ring
> + * 
> + *
> + * Some features, such as toeplitz hashing (detailed below), require a
> + * significant amount of out-of-band data to be passed from frontend to
> + * backend. Use of xenstore is not suitable for large quantities of data
> + * because of quota limitations and so a dedicated 'control ring' is used.
> + * The ability of the backend to use a control ring is advertised by
> + * setting:
> + *
> + * /local/domain/X/backend///feature-control-ring = "1"

I noticed this isn't consistent with the abbreviation of 'control' to 'ctrl' 
below so I'll change it.

  Paul

> + *
> + * The frontend provides a control ring to the backend by setting:
> + *
> + * /local/domain//device/vif//ctrl-ring-ref = 
> + * /local/domain//device/vif//event-channel-ctrl = 
> + *
> + * where  is the grant reference of the shared page used to
> + * implement the control ring and  is an event channel to be used
> + * as a mailbox interrupt. These keys must be set before the frontend
> + * moves into the connected state.

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

[Xen-devel] [PATCH v7 0/2] public/io/netif.h: support for toeplitz hashing

[Paul Durrant]

This series documents changes needed to support toeplitz hashing in a
backend, configurable by the frontend.

Patch #1 adds further clarifications to the receive and transmit wire
formats.

Patch #2 documents a new 'control ring' for passing bulk data between
frontend and backend. This is needed for passing the hash mapping table
and hash key. It also documents messages to allow a frontend to configure
toeplitz hashing and a new extra info segment that can be used for passing
hash values along with packets on both the transmit and receive side.

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

Re: [Xen-devel] [ovmf test] 77825: regressions - FAIL

[Wei Liu]

On Tue, Jan 12, 2016 at 08:36:42AM +, osstest service owner wrote:
> flight 77825 ovmf real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/77825/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
> REGR. vs. 65543
>  test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
> REGR. vs. 65543
> 

The guest is constantly rebooting. But there isn't much clue in serial
log. I will wait a bit for the bisector to come back with this.

Wei.

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

Re: [Xen-devel] [PATCH v3 00/41] arch: barrier cleanup + barriers for virt

[Peter Zijlstra]

On Sun, Jan 10, 2016 at 04:16:22PM +0200, Michael S. Tsirkin wrote:
> I parked this in vhost tree for now, though the inclusion of patch 1 from tip
> creates a merge conflict - but one that is trivial to resolve.
> 
> So I intend to just merge it all through my tree, including the
> duplicate patch, and assume conflict will be resolved.
> 
> I would really appreciate some feedback on arch bits (especially the x86 
> bits),
> and acks for merging this through the vhost tree.

Thanks for doing this, looks good to me.

Acked-by: Peter Zijlstra (Intel) 

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

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

[Peter Zijlstra]

On Tue, Jan 12, 2016 at 11:25:55AM +0100, Peter Zijlstra wrote:
> On Tue, Jan 12, 2016 at 10:27:11AM +0100, Peter Zijlstra wrote:
> > 2) the changelog _completely_ fails to explain the sync 0x11 and sync
> > 0x12 semantics nor does it provide a publicly accessible link to
> > documentation that does.
> 
> Ralf pointed me at: https://imgtec.com/mips/architectures/mips64/
> 
> > 3) it really should have explained what you did with
> > smp_llsc_mb/smp_mb__before_llsc() in _detail_.
> 
> And reading the MIPS64 v6.04 instruction set manual, I think 0x11/0x12
> are _NOT_ transitive and therefore cannot be used to implement the
> smp_mb__{before,after} stuff.
> 
> That is, in MIPS speak, those SYNC types are Ordering Barriers, not
> Completion Barriers. They need not be globally performed.

Which if true; and I know Will has some questions here; would also mean
that you 'cannot' use the ACQUIRE/RELEASE barriers for your locks as was
recently suggested by David Daney.

That is, currently all architectures -- with exception of PPC -- have
RCsc locks, but using these non-transitive things will get you RCpc
locks.

So yes, MIPS can go RCpc for its locks and share the burden of pain with
PPC, but that needs to be a very concious decision.

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

Re: [Xen-devel] 2014 and 2015 contribution stats (including Reviewed-by and other tags)

[Lars Kurth]

Hi all,
I attached a cleaned-up version for 2015. Thanks to those which provided input
Lars

On Mon, Jan 11, 2016 at 11:53 AM, Lars Kurth  wrote:
> Hi folks,
>
> please find attached 2014 and 2015 contribution stats, including some of the 
> tags. To compare like with like, the 2015 figures do contain repos which were 
> taken out of xen.git. They also include osstest, as I used to track these in 
> the past.
>
> The company figures in the 2015 file may have some inaccuracies as, I have 
> not tidied the user to company mapping yet. If you see your name or e-mail 
> address in there, it would be great if you could let me know which employer 
> to map you to by sending a private email.
>
> Key observations
> * The number of patch-sets contributed have gone up significantly (from 2118 
> to 2954)
> * The number of developers has gone up from 110 to 116
> * The number of employers could possibly have gone down, but there is always 
> some uncertainty as I don't always know who works for whom and if I don't 
> know people are mapped int the "(Individual)" company bucket
> * The number of "reviews, including ACKs" has increased from 2392 to 3257. If 
> you look at just the ACK's, a lot more people are reviewing. Also the 
> distribution has changed significantly. What is notable is that the Citrix 
> proportion of reviews has shot up significantly. Note that reviewed-by and 
> ACK tags do not accurately reflect actual effort in a review: just an 
> end-state.
> * The number of test related tags has gone up marginally
>
> Best Regards
> Lars
>
open output file /home/adminuser/Code-Clean/output/hypervisor/2015-dev.csv

WARNING: duplicate email/empl for mee...@yomimono.org
WARNING: duplicate email/empl for emun...@mgebm.net
WARNING: duplicate email/empl for car...@cardoe.com
Processed 2954 csets from 116 developers
33 employers found
A total of 170336 lines added, 103200 removed (delta 67136)

Developers with the most changesets
Ian Jackson507 (17.2%)
Ian Campbell   401 (13.6%)
Jan Beulich326 (11.0%)
Andrew Cooper  244 (8.3%)
Wei Liu207 (7.0%)
Julien Grall   188 (6.4%)
Stefano Stabellini 130 (4.4%)
Roger Pau Monné71 (2.4%)
Dario Faggioli  71 (2.4%)
Boris Ostrovsky 66 (2.2%)
Paul Durrant50 (1.7%)
Konrad Rzeszutek Wilk   47 (1.6%)
Doug Goldstein  42 (1.4%)
Olaf Hering 39 (1.3%)
David Vrabel34 (1.2%)
Juergen Gross   33 (1.1%)
Chao Peng   30 (1.0%)
Tamas K Lengyel 27 (0.9%)
Tiejun Chen 25 (0.8%)
George Dunlap   24 (0.8%)
Yang Hongyang   23 (0.8%)
Ross Lagerwall  20 (0.7%)
Quan Xu 19 (0.6%)
Feng Wu 16 (0.5%)
Robert Ho   14 (0.5%)
Tim Deegan  14 (0.5%)
Vitaly Kuznetsov14 (0.5%)
Kai Huang   13 (0.4%)
Daniel Kiper13 (0.4%)
Razvan Cojocaru 10 (0.3%)
Ed White10 (0.3%)
Chen Baozi  10 (0.3%)
Don Slutz9 (0.3%)
Daniel De Graaf  8 (0.3%)
Anthony PERARD   8 (0.3%)
Vijaya Kumar K   8 (0.3%)
Edgar E. Iglesias8 (0.3%)
Thomas Leonard   7 (0.2%)
Haozhong Zhang   6 (0.2%)
Harmandeep Kaur  6 (0.2%)
longtao.pang 5 (0.2%)
Shuai Ruan   5 (0.2%)
Jonathan Creekmore   5 (0.2%)
Len Brown5 (0.2%)
Oleksandr Tyshchenko 5 (0.2%)
Chris Brand  5 (0.2%)
Liang Li 5 (0.2%)
Frediano Ziglio  5 (0.2%)
Sander Eikelenboom   4 (0.1%)
Martin Lucina4 (0.1%)
Huaitong Han 4 (0.1%)
He Chen  4 (0.1%)
Fabio Fantoni4 (0.1%)
Wei Wang 4 (0.1%)
Ravi Sahita  4 (0.1%)
Yu Zhang 3 (0.1%)
Wen Congyang 3 (0.1%)
Jennifer Herbert 3 (0.1%)
Charles Arnold   3 (0.1%)
Pramod Devendra  3 (0.1%)
Malcolm Crossley 2 (0.1%)
Jim Fehlig   2 (0.1%)
Bob Liu  2 (0.1%)
Riku Voipio  2 (0.1%)
Aravind Gopalakrishnan   2 (0.1%)
Mike Latimer 2 (0.1%)
Elena Ufimtseva  2 (0.1%)
Ting-Wei Lan 2 (0.1%)
Ben Catterall2 (0.1%)
Euan Harris  2 (0.1%)
Koushik Chakravarty  2 (0.1%)
Giuseppe Mazzotta2 (0.1%)
Robert VanVossen 2 (0.1%)
Eugene Korenevsky2 (0.1%)
Emil Condrea 2 (0.1%)
Uma Sharma   2 (0.1%)
Mihai Donțu 2 (0.1%)
Alex Xu  1 (0.0%)
Kevin Tian   1 (0.0%)
David Scott

Re: [Xen-devel] [PATCH] x86/hvm: Allow the guest to permit the use of userspace hypercalls

[Stefano Stabellini]

On Mon, 11 Jan 2016, David Vrabel wrote:
> On 11/01/16 17:17, Andrew Cooper wrote:
> > So from one point of view, sufficient justification for this change is
> > "because the Linux way isn't the only valid way to do this".
> 
> "Because we can" isn't a good justification for adding something new.
> Particularly something that is trivially easy to (accidentally) misuse
> and open a big security hole between userspace and kernel.
> 
> The vague idea for a userspace netfront that's floating around
> internally is also not a good reason for pushing this feature at this time.

I agree with David, but I might have another good use case for this.

Consider the following scenario: we have a Xen HVM guest, with Xen
installed inside of it (nested virtualization). I'll refer to Xen
running on the host as L0 Xen and Xen running inside the VM as L1 Xen.
Similarly we have two dom0 running, the one with access to the physical
hardware, L0 Dom0, and the one running inside the VM, L1 Dom0.

Let's suppose that we want to lay the groundwork for L1 Dom0 to use PV
frontend drivers, netfront and blkfront to speed up execution. In order
to do that, the first thing it needs to do is making an hypercall to L0
Xen. That's because netfront and blkfront needs to communicate with
netback and blkback in L0 Dom0: event channels and grant tables are the
ones provided by L0 Xen.

However L0 Xen refuses hypercalls from ring 3, and L1 Dom0 is running in
ring 3 so unfortunately it cannot actually do it.

With this hypercall in place, it is conceivable for L1 Dom0 to instruct
L1 Xen to make a HVMOP_set_hypercall_dpl call and allow L1 Dom0 to setup
netfront and blkfront with L0 Xen.

Fun, isn't it.

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

Re: [Xen-devel] [PATCH v3 13/41] x86: reuse asm-generic/barrier.h

[Thomas Gleixner]

On Sun, 10 Jan 2016, Michael S. Tsirkin wrote:

> As on most architectures, on x86 read_barrier_depends and
> smp_read_barrier_depends are empty.  Drop the local definitions and pull
> the generic ones from asm-generic/barrier.h instead: they are identical.
> 
> This is in preparation to refactoring this code area.
> 
> Signed-off-by: Michael S. Tsirkin 
> Acked-by: Arnd Bergmann 

Reviewed-by: Thomas Gleixner 

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

Re: [Xen-devel] [PATCH v3 27/41] x86: define __smp_xxx

[Thomas Gleixner]

On Sun, 10 Jan 2016, Michael S. Tsirkin wrote:

> This defines __smp_xxx barriers for x86,
> for use by virtualization.
> 
> smp_xxx barriers are removed as they are
> defined correctly by asm-generic/barriers.h
> 
> Signed-off-by: Michael S. Tsirkin 
> Acked-by: Arnd Bergmann 

Reviewed-by: Thomas Gleixner 

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

Re: [Xen-devel] [PATCH RFC OSSTEST v1 05/12] make-*flight: Abolish $defsuite and $guestdefsuite

[Ian Jackson]

Ian Campbell writes ("[PATCH RFC OSSTEST v1 05/12] make-*flight: Abolish 
$defsuite and $guestdefsuite"):
> Instead have mfi-common set $suite or $guestsuite if it is unset. When
> doing so move the use of local to this point, using local at the top
> of the function would shadow any attempt to set a global value, while
> restricting it only to when setting the default means it doesn't leak.
> NB "local" scopes the variable to the containing function, not the
> scope of the block where it is written (i.e. the if body in this
> case).

I'm not really sure this approach is right.

If we were to decide that some of the tests resulting from
test_matrix_iterate ought to have different suite values, we would
have to (re)introduce a layer of indirection.

Perhaps it would be better to retain defsuite and defguestsuite;
move the copy from those to suite and guestsuite closer to use site;
and unconditionally set the runvar ?

Ian.

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

Re: [Xen-devel] [PATCH RFC OSSTEST v1 06/12] ts-host-install: Support DiVersion coming from runvars

[Ian Jackson]

Ian Campbell writes ("[PATCH RFC OSSTEST v1 06/12] ts-host-install: Support 
DiVersion coming from runvars"):
> To do so initialise $ho->{DiVersion} in select host and use it in
> ts-host-install.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] Nested virtualization off VMware vSphere 6.0 with EL6 guests crashes on Xen 4.6

[Alvin Starr]

Insure that memory and maxmem are set to the same value.



On 01/11/2016 10:38 PM, Konrad Rzeszutek Wilk wrote:

Hey,

The machine is an X5-2 which is a Haswell based E5-2699 v3.

We are trying to launch to use the nested virtualization. The
guest is a simple VMware vSphere 6.0 with 32GB, 8 CPUs.

The guest than that is launched within VMware is a 2 VCPU 2GB Linux
(OEL6 to be exact). During its bootup Xen crashes with this assert.

Oddly enough if this is repeated on a workstation Ivy Bridge CPU (i5-3570)
it works fine.

Disabling APICv (apicv=0) on the Xen command line did not help.

I added some debug code to see if the vapic_pg is bad and what
the p2mt type is [read below]


Serial console started.  To stop, type ESC (
(XEN) Assertion 'vapic_pg && !p2m_is_paging(p2mt)' failed at vvmx.c:698
(XEN) [ Xen-4.6.0  x86_64  debug=y  Tainted:C ]
(XEN) CPU:39
(XEN) RIP:e008:[] virtual_vmentry+0x487/0xac9
(XEN) RFLAGS: 00010246   CONTEXT: hypervisor (d1v3)
(XEN) rax:    rbx: 83007786c000   rcx: 
(XEN) rdx: 0e00   rsi: 000f   rdi: 83407f81e010
(XEN) rbp: 834008a47ea8   rsp: 834008a47e38   r8: 
(XEN) r9:     r10:    r11: 
(XEN) r12:    r13: 82c000341000   r14: 834008a47f18
(XEN) r15: 83407f7c4000   cr0: 80050033   cr4: 001526e0
(XEN) cr3: 00407fb22000   cr2: 
(XEN) ds:    es:    fs:    gs:    ss:    cs: e008
(XEN) Xen stack trace from rsp=834008a47e38:
(XEN)834008a47e68 82d0801d2cde 834008a47e68 0d00
(XEN)  834008a47e88 0004801cc30e
(XEN)83007786c000 83007786c000 834008a4 
(XEN)834008a47f18  834008a47f08 82d0801edf94
(XEN)834008a47ef8  834008f62000 834008a47f18
(XEN)00ae8c99eb8d 83007786c000  
(XEN)   82d0801ee2ab
(XEN)   
(XEN)   
(XEN)   
(XEN)078bfbff   beefbeef
(XEN)fc4b3440 00bfbeef 00040046 fc607f00
(XEN)beef beef beef beef
(XEN)beef 0027 83007786c000 006f88716300
(XEN)
(XEN) Xen call trace:
(XEN)[] virtual_vmentry+0x487/0xac9
(XEN)[] nvmx_switch_guest+0x8ff/0x915
(XEN)[] vmx_asm_vmexit_handler+0x4b/0xc0
(XEN)
(XEN)
(XEN) 
(XEN) Panic on CPU 39:
(XEN) Assertion 'vapic_pg && !p2m_is_paging(p2mt)' failed at vvmx.c:698
(XEN) 
(XEN)

..and then to my surprise the hypervisor stopped hitting this. Instead
I started getting an even more bizzare crash:


(d1) enter handle_19:
(d1)   NULL
(d1) Booting from Hard Disk...
(d1) Booting from :7c00
(XEN) stdvga.c:151:d1v0 leaving stdvga mode
(XEN) stdvga.c:147:d1v0 entering stdvga and caching modes
(XEN) stdvga.c:520:d1v0 leaving caching mode
(XEN) [ Xen-4.6.0  x86_64  debug=y  Tainted:C ]
(XEN) CPU:3
(XEN) RIP:e008:[] vmx_cpu_up+0xacc/0xba5
(XEN) RFLAGS: 00010242   CONTEXT: hypervisor (d1v1)
(XEN) rax:    rbx: 830077877000   rcx: 834077e54000
(XEN) rdx: 834007dc8000   rsi: 2000   rdi: 830077877000
(XEN) rbp: 834007dcfc48   rsp: 834007dcfc38   r8:  0404
(XEN) r9:  000ff000   r10:    r11: fc423f1e
(XEN) r12: 2000   r13:    r14: 
(XEN) r15:    cr0: 80050033   cr4: 001526e0
(XEN) cr3: 004000763000   cr2: 
(XEN) ds:    es:    fs:    gs:    ss:    cs: e008
(XEN) Xen stack trace from rsp=834007dcfc38:
(XEN)834007dcfc98  834007dcfc68 82d0801e2533
(XEN)830077877000 2000 834007dcfc78 82d0801ea933
(XEN)834007dcfca8 82d0801eaae4  830077877000
(XEN) 834007dcff18 834007dcfd08 82d0801eb983
(XEN)8341 00013692c000 8340 fc607f28
(XEN)0008 8346 834007dcff18 830077877000
(XEN)0015  834007dcff08 82d0801e8c8d
(XEN)834007763000 8300778c2000 8340007c3000 834007dcfd50
(XEN)82d0801e120b 834007dcfd50 830077877000 834007dcfdf0
(XEN)  

Re: [Xen-devel] [libvirt] [PATCH V2 1/3] xenconfig: support vif bandwidth in sexpr parser and formatter

[John Ferlan]

On 01/04/2016 08:08 PM, Jim Fehlig wrote:
> The xen sexpr config format has long supported specifying vif rate
> limiting, e.g.
> 
>   (device
> (vif
>   (mac '00:16:3e:1b:b1:47')
>   (rate '10240KB/s')
>   ...
> )
>   )
> 
> Add support for mapping rate to and from  in the xenconfig
> sexpr parser and formatter. rate is mapped to the required 'average'
> attribute of the  element, e.g.
> 
>   
> ...
> 
>   
> 
>   
> 
> Also add unit tests to check the conversion logic.
> 
> This patch benefits both the old xen driver and the libxl driver.
> Both drivers gain support for vif bandwidth when converting to/from
> domXML and xen-sxpr. In addition, the old xen driver will now be
> able to handle vif 'rate' setting when communicating with xend.
> 
> Signed-off-by: Jim Fehlig 
> ---
> 
> I used a bit of code from libxlu_vif.c to implement xenParseSxprVifRate()
> instead of using the libxlutil lib directly, since rate limiting applies
> to the old xen driver (no libxl) as well.
> 
>  src/libvirt_xenconfig.syms  |  1 +
>  src/xenconfig/xen_sxpr.c| 74 
> +
>  src/xenconfig/xen_sxpr.h|  2 +
>  tests/sexpr2xmldata/sexpr2xml-vif-rate.sexpr| 11 
>  tests/sexpr2xmldata/sexpr2xml-vif-rate.xml  | 51 +
>  tests/sexpr2xmltest.c   |  2 +
>  tests/xml2sexprdata/xml2sexpr-fv-net-rate.sexpr | 10 
>  tests/xml2sexprdata/xml2sexpr-fv-net-rate.xml   | 34 
>  tests/xml2sexprtest.c   |  1 +
>  9 files changed, 186 insertions(+)
> 

Coverity found an 'issue'...

> diff --git a/src/libvirt_xenconfig.syms b/src/libvirt_xenconfig.syms
> index 6541685..b69f2ab 100644
> --- a/src/libvirt_xenconfig.syms
> +++ b/src/libvirt_xenconfig.syms
> @@ -15,6 +15,7 @@ xenParseSxpr;
>  xenParseSxprChar;
>  xenParseSxprSound;
>  xenParseSxprString;
> +xenParseSxprVifRate;
>  
>  # xenconfig/xen_xm.h
>  xenFormatXM;
> diff --git a/src/xenconfig/xen_sxpr.c b/src/xenconfig/xen_sxpr.c
> index d99bac0..9ae50b0 100644
> --- a/src/xenconfig/xen_sxpr.c
> +++ b/src/xenconfig/xen_sxpr.c
> @@ -26,6 +26,8 @@
>  
>  #include 
>  
> +#include 
> +
>  #include "internal.h"
>  #include "virerror.h"
>  #include "virconf.h"
> @@ -315,6 +317,56 @@ xenParseSxprChar(const char *value,
>  }
>  
>  
> +static const char *vif_bytes_per_sec_re = "^[0-9]+[GMK]?[Bb]/s$";
> +
> +int
> +xenParseSxprVifRate(const char *rate, unsigned long long *kbytes_per_sec)
> +{
> +char *trate = NULL;
> +char *p;
> +regex_t rec;
> +char *suffix;
> +unsigned long long tmp;
> +int ret = -1;
> +
> +if (VIR_STRDUP(trate, rate) < 0)
> +return -1;
> +
> +p = strchr(trate, '@');
> +if (p != NULL)
> +*p = 0;
> +
> +regcomp(, vif_bytes_per_sec_re, REG_EXTENDED|REG_NOSUB);

5) Event check_return:  Calling "regcomp" without checking return value
(as is done elsewhere 14 out of 15 times).

IOW: What if regcomp fails...

John
> +if (regexec(, trate, 0, NULL, 0)) {
> +virReportError(VIR_ERR_INTERNAL_ERROR,
> +   _("Invalid rate '%s' specified"), rate);
> +goto cleanup;
> +}
> +
> +if (virStrToLong_ull(rate, , 10, )) {
> +virReportError(VIR_ERR_INTERNAL_ERROR,
> +   _("Failed to parse rate '%s'"), rate);
> +goto cleanup;
> +}
> +
> +if (*suffix == 'G')
> +   tmp *= 1024 * 1024;
> +else if (*suffix == 'M')
> +   tmp *= 1024;
> +
> +if (*suffix == 'b' || *(suffix + 1) == 'b')
> +   tmp /= 8;
> +
> +*kbytes_per_sec = tmp;
> +ret = 0;
> +
> + cleanup:
> +regfree();
> +VIR_FREE(trate);
> +return ret;
> +}
> +
> +

<...>

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

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

[osstest service owner]

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

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  20c8f1a8a5fd61cb6f0ba6f3c3b3d567b1765116
baseline version:
 xen  f7347a282420a5edc74afb31e7c42c2765f24de5

Last test of basis77538  2016-01-08 19:08:39 Z3 days
Testing same since77890  2016-01-12 11:03:17 Z0 days1 attempts


People who touched revisions under test:
  Brendan Gregg 
  Daniel De Graaf 
  Doug Goldstein 
  Haozhong Zhang 
  Juergen Gross 
  Kevin Tian 
  Wei Liu  for tools bits

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=20c8f1a8a5fd61cb6f0ba6f3c3b3d567b1765116
+ . ./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 
20c8f1a8a5fd61cb6f0ba6f3c3b3d567b1765116
+ branch=xen-unstable-smoke
+ revision=20c8f1a8a5fd61cb6f0ba6f3c3b3d567b1765116
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-unstable
+ '[' x20c8f1a8a5fd61cb6f0ba6f3c3b3d567b1765116 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig 

Re: [Xen-devel] [PATCH V12 1/5] libxl: export some functions for pvusb use

[Ian Jackson]

Chunyan Liu writes ("[PATCH V12 1/5] libxl: export some functions for pvusb 
use"):
> Signed-off-by: Chunyan Liu 
> Signed-off-by: Simon Cao 
> Reviewed-by: Wei Liu 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH V12 2/5] libxl_utils: add internal function to read sysfs file contents

[Ian Jackson]

Chunyan Liu writes ("[PATCH V12 2/5] libxl_utils: add internal function to read 
sysfs file contents"):
> Add a new function libxl_read_sysfs_file_contents to handle sysfs file
> specially. It would be used in later pvusb work.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH V12 3/5] libxl: add pvusb API

[Ian Jackson]

Chunyan Liu writes ("[PATCH V12 3/5] libxl: add pvusb API"):
> Add pvusb APIs, including:
>  - attach/detach (create/destroy) virtual usb controller.
>  - attach/detach usb device
>  - list usb controller and usb devices
>  - some other helper functions
> 
> Signed-off-by: Chunyan Liu 
> Signed-off-by: Simon Cao 
> Signed-off-by: George Dunlap 
> Reviewed-by: George Dunlap 

Thanks.  I have re-reviewed this and found a few issues, I'm afraid,
mostly in the error handling.

> +/* find first unused controller:port and give that to usb device */
> +static int
> +libxl__device_usbdev_set_default_usbctrl(libxl__gc *gc, uint32_t domid,
> + libxl_device_usbdev *usbdev)
> +{
...
> +path = GCSPRINTF("%s/backend/vusb/%d/%d/port/%d",
> + libxl__xs_get_dompath(gc, 
> LIBXL_TOOLSTACK_DOMID),
> + domid, usbctrls[i].devid, j + 1);
> +tmp = libxl__xs_read(gc, XBT_NULL, path);

I think this probably ought to be libxl__xs_read_checked ?  (With
corresponding change to handling of return value.)

> +/* get original driver path of usb interface, stored in @drvpath */
> +static int usbintf_get_drvpath(libxl__gc *gc, const char *intf, char 
> **drvpath)
> +{
> +char *spath, *dp = NULL;
> +struct stat st;
> +int rc;
> +
> +spath = GCSPRINTF(SYSFS_USB_DEV "/%s/driver", intf);
> +
> +rc = lstat(spath, );
> +if (rc == 0) {
> +/* Find the canonical path to the driver. */
> +dp = libxl__zalloc(gc, PATH_MAX);
> +dp = realpath(spath, dp);

This call to realpath seems to lack error checking/handling.

> +static int sysfs_write_intf(libxl__gc *gc, const char *intf, const char 
> *path)
> +{

What is `intf' here ?  Maybe `interface' ?  But there is nothing usb
specific about this function.  Looking for similar code elsewhere this
function seems very similar to libxl_pci.c:sysfs_write_bdf, but I
won't ask you to try to refactor these two functions together.

> +rc = write(fd, intf, strlen(intf));

rc ought not be used for a syscall return value.  (CODING_STYLE)

> +close(fd);

This is a pretty ad-hoc error handling approach.  Can you please use
the CODYING_STYLE-recommended pattern ?

> +static int bind_usbintf(libxl__gc *gc, const char *intf, const char *drvpath)
> +{
> +char *path;
> +struct stat st;
> +
> +path = GCSPRINTF("%s/%s", drvpath, intf);
> +/* if already bound, return */
> +if (!lstat(path, ))
> +return 0;

If lstat fails, you need to check the error return to see why.

> +/* Encode usb interface so that it could be written to xenstore as a key.
> + *
> + * Since xenstore key cannot include '.' or ':', we'll change '.' to '_',
> + * change ':' to '@'. For example, 3-1:2.1 will be encoded to 3-1@2_1.
> + * This will be used to save original driver of USB device to xenstore.
> + */
> +static char *usb_interface_xenstore_encode(libxl__gc *gc, const char *busid)
> +{
> +char *str = libxl__strdup(gc, busid);
> +int i, len = strlen(str);
> +
> +for (i = 0; i < len; i++) {
> +if (str[i] == '.')
> +str[i] = '_';
> +if (str[i] == ':')
> +str[i] = '@';

I know I'm late with this comment and it's trivial and my
comaintainers may disagree, but I would find this

  +if (str[i] == '.') str[i] = '_';
  +if (str[i] == ':') str[i] = '@';

clearer because the layout reflects the regular structure of the code.
But please don't change this until another maintainer has commented
and said whether they agree with me.  Certainly this is observation of
mine does not block this patch.

> +static int usbback_dev_unassign(libxl__gc *gc, const char *busid)
> +{
> +char **intfs = NULL;
> +char *usbdev_encode = NULL;
> +char *path = NULL;
> +int i, num = 0;
> +int rc;
> +
> +if (usbdev_get_all_interfaces(gc, busid, , ) < 0)
> +return ERROR_FAIL;

usbdev_get_all_interfaces returns a libxl error code, which you should
preserved.  So assign the result to rc, and `if (rc) goto out;'.  Same
goes for unbind_usbintf (and maybe other calls elsewhere in this
file).

> +path = GCSPRINTF(USBBACK_INFO_PATH "/%s/%s/driver_path",
> + usbdev_encode, usbintf_encode);
> +rc = libxl__xs_read_checked(gc, XBT_NULL, path, );
> +if (rc) continue;

This anomalous error handling deserves a comment I think.  (See also
below.)

> +if (drvpath && bind_usbintf(gc, intf, drvpath))
> +LOGE(WARN, "Couldn't rebind %s to %s", intf, drvpath);
> +}
> +
> +/* finally, remove xenstore driver path */
> +path = GCSPRINTF(USBBACK_INFO_PATH "/%s", usbdev_encode);
> +libxl__xs_rm_checked(gc, XBT_NULL, path);

If you are deliberately throwing away errors (which I think maybe you
are), please say so in a comment.

Ought this 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  9 debian-install   fail   like 77743

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

version targeted for testing:
 qemuu7b8a354d4716ab2c201fad04c22b8d4a16a1b8c6
baseline version:
 qemuu6bb9ead762bf749af11ea225fc2a74db1b93c105

Last test of basis77743  2016-01-10 15:27:52 Z2 days
Testing same since77846  2016-01-11 16:53:58 Z1 days1 attempts


People who touched revisions under test:
  Alexey Kardashevskiy 
  Alexis Dambricourt 
  Andrew Jones 
  Ashok Kumar 
  Cao jin 
  Chen Gang 
  Chen Gang 
  Cornelia Huck 
  David Gibson 
  Dr. David Alan Gilbert 
  Eric Blake 
  Haozhong Zhang 
  Harmandeep Kaur 
  Igor Mammedov 
  Jason Wang 
  Jean-Christophe Dubois 
  Johan Ouwerkerk 
  John Paul Adrian Glaubitz 
  Laszlo Ersek 
  Laurent Vivier 
  Li Zhijian 
  Marc-André Lureau 
  Miao Yan 
  Miao Yan 
  Michael S. Tsirkin 
  Michael Tokarev 
  P J P 
  Paolo Bonzini 
  Peter Maydell 
  Prasad J Pandit 
  Riku Voipio 
  Roman Kagan 
  Shmulik Ladkani 
  Sukadev Bhattiprolu 
  Tetsuya Mukawa 
  Thomas Huth 
  Zhu Lingshan 

jobs:

Re: [Xen-devel] [PATCH V12 5/5] domcreate: support pvusb in configuration file [and 1 more messages]

[Ian Jackson]

Chunyan Liu writes ("[PATCH V12 4/5] xl: add pvusb commands"):
> Add pvusb commands: usbctrl-attach, usbctrl-detach, usb-list,
> usbdev-attach and usbdev-detach.

The way you have documented usbctrl-attach and the config file syntax
in this patch and the next one means that each usb config setting
appears twice in the documentation.

Can you please follow the example of disk devices ?  (Except that you
probably don't want to refer to a separate file, but to a separate
part of the manpage.)

This will be easier if you swap the order of these two patches,
because otherwise one patch has to refer to docs which are introduced
in a later patch.

> +if (!libxl_device_usbctrl_getinfo(ctx, domid,
> +[i], )) {
> +printf("%-6d %-6s %-3d %-5d %-7d %-5d %-30s\n",
> +usbctrlinfo.devid,
> +libxl_usbctrl_type_to_string(usbctrlinfo.type),
> +usbctrlinfo.backend_id, usbctrlinfo.state,
> +usbctrlinfo.version, usbctrlinfo.ports,
> +usbctrlinfo.backend);

I think the backend xenstore path should not normally be printed out
by xl.  That some of the other xl subcommands do that for some devices
is a mistake, I'm afraid.

Chunyan Liu writes ("[PATCH V12 5/5] domcreate: support pvusb in configuration 
file"):
> Add code to support pvusb in domain config file. One could specify
> usbctrl and usb in domain's configuration file and create domain,
> then usb controllers will be created and usb device would be attached
> to guest automatically.
...
> +if (!xlu_cfg_get_list(config, "usbctrl", , 0, 0)) {
> +d_config->num_usbctrls = 0;
> +d_config->usbctrls = NULL;
> +while ((buf = xlu_cfg_get_listitem(usbctrls, d_config->num_usbctrls))
> +   != NULL) {

I have to say that I am very uncomfortable with the level of code
duplication here, but the existing code is very bad for this so I
don't feel I can ask you to refactor it.

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH v6 1/2] xen/hvm: introduce a flags field in the CPU save record

[Roger Pau Monné]

El 12/01/16 a les 17.31, Jan Beulich ha escrit:
 On 12.01.16 at 17:12,  wrote:
>> @@ -2087,19 +2100,21 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
>> hvm_domain_context_t *h)
>>  seg.attr.bytes = ctxt.ldtr_arbytes;
>>  hvm_set_segment_register(v, x86_seg_ldtr, );
>>  
>> -/* In case xsave-absent save file is restored on a xsave-capable host */
>> -if ( cpu_has_xsave && !xsave_enabled(v) )
>> +v->fpu_initialised = !!(ctxt.flags & XEN_X86_FPU_INITIALISED);
>> +if ( v->fpu_initialised )
>>  {
>> -struct xsave_struct *xsave_area = v->arch.xsave_area;
>> +memcpy(v->arch.fpu_ctxt, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
>> +/* In case xsave-absent save file is restored on a xsave-capable 
>> host */
>> +if ( cpu_has_xsave && !xsave_enabled(v) )
>> +{
>> +struct xsave_struct *xsave_area = v->arch.xsave_area;
>>  
>> -memcpy(v->arch.xsave_area, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
>> -xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
>> -if ( cpu_has_xsaves || cpu_has_xsavec )
>> -xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP_SSE |
>> - XSTATE_COMPACTION_ENABLED;
>> +xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
>> +if ( cpu_has_xsaves || cpu_has_xsavec )
>> +xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP_SSE |
>> + XSTATE_COMPACTION_ENABLED;
>> +}
>>  }
>> -else
>> -memcpy(v->arch.fpu_ctxt, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
>>  
> 
> I would have expected this to simply be re-indentation, yet
> you changed from if/else to just if with the else code done
> ahead of it. If this really is intended, the commit message should
> explain it.

Right, sorry. AFAICT v->arch.fpu_ctxt points to the xsave_area (as set
by vcpu_init_fpu), so I though it was simpler to just do one memcpy for
both cases, since v->arch.fpu_ctxt always points to the right area for
either cases (and I was already modifying the code in question).

I can see that this might be seen as an unrelated change, so if you want
I can split it into a separate patch, or add the following to the commit
message:

"While modifying the FPU restore part of hvm_load_cpu_ctxt remove the
memcpy branching, since v->arch.fpu_ctxt will always point to the right
area for hosts with XSAVE or without it."

Thanks, Roger.


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

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

[Peter Zijlstra]

On Tue, Jan 12, 2016 at 12:45:14PM -0800, Leonid Yegoshin wrote:
> (I try to answer on multiple mails in one)
> 
> First of all, it seems like some generic notes should be given here:
> 
> 1. Generic MIPS "SYNC" (aka "SYNC 0") instruction is a very heavy in some
> CPUs. On that CPUs it basically kills pipelines in each CPU, can do a
> special memory/IO bus transaction (similar to "fence") and hold a system
> until all R/W is completed. It is like Big Kernel Lock but worse. So, the
> move to SMP_* kind of barriers is needed to improve performance, especially
> on newest CPUs with long pipelines.

The MIPS SYNC isn't any worse than the PPC SYNC, x86 MFENCE or arm DSB
SY, yes they're heavy, so what.

> 2. MIPS Arch document may be misleading because words "ordering" and
> "completion" means different from Linux, the SYNC instruction description is
> written for HW engineers. I wrote that in a separate patch of the same
> patchset - http://patchwork.linux-mips.org/patch/10505/ "MIPS: R6: Use
> lightweight SYNC instruction in smp_* memory barriers":

Did you actually say anything here?

> >This instructions were specifically designed to work for smp_*() sort of
> >memory barriers in MIPS R2/R3/R5 and R6.
> >
> >Unfortunately, it's description is very cryptic and is done in HW engineering
> >style which prevents use of it by SW.
> 
> 3. I bother MIPS Arch team long time until I completely understood that MIPS
> SYNC_WMB, SYNC_MB, SYNC_RMB, SYNC_RELEASE and SYNC_ACQUIRE do an exactly
> that is required in Documentation/memory-barriers.txt

Ha! and you think that document covers all the really fun details?

In particular we're very much all 'confused' about the various notions
of transitivity and what barriers imply how much of it.

> In Peter Zijlstra mail:
> 
> >1) you do not make such things selectable; either the hardware needs
> >them or it doesn't. If it does you_must_  use them, however unlikely.

> It is selectable only for MIPS R2 but not MIPS R6. The reason is - most of
> MIPS R2 CPUs have short pipeline and that SYNC is just waste of CPU
> resource, especially taking into account that "lightweight syncs" are
> converted to a heavy "SYNC 0" in many of that CPUs. However the latest
> MIPS/Imagination CPU have a pipeline long enough to hit a problem - absence
> of SYNC at LL/SC inside atomics, barriers etc.

What ?! Are you saying that because R2 has short pipelines its unlikely
to hit the reordering issues and we can omit barriers?

> >And reading the MIPS64 v6.04 instruction set manual, I think 0x11/0x12
> >are_NOT_  transitive and therefore cannot be used to implement the
> >smp_mb__{before,after} stuff.
> >
> >That is, in MIPS speak, those SYNC types are Ordering Barriers, not
> >Completion Barriers.
> 
> Please see above, point 2.

That did not in fact enlighten things. Are they transitive/multi-copy
atomic or not?

(and here Will will go into great detail on the differences between the
two and make our collective brains explode :-)

> >That is, currently all architectures -- with exception of PPC -- have
> >RCsc locks, but using these non-transitive things will get you RCpc
> >locks.
> >
> >So yes, MIPS can go RCpc for its locks and share the burden of pain with
> >PPC, but that needs to be a very concious decision.
> 
> I don't understand that - I tried hard but I can't find any word like
> "RCsc", "RCpc" in Documents/ directory. Web search goes nowhere, of course.

From: lkml.kernel.org/r/20150828153921.gf19...@twins.programming.kicks-ass.net

Yes, the difference between RCpc and RCsc is in the meaning of RELEASE +
ACQUIRE. With RCsc that implies a full memory barrier, with RCpc it does
not.

Currently PowerPC is the only arch that (can, and) does RCpc and gives a
weaker RELEASE + ACQUIRE. Only the CPU who did the ACQUIRE is guaranteed
to see the stores of the CPU which did the RELEASE in order.

As it stands, RCU is the only _known_ codebase where this matters, but
we did in fact write code for a fair number of years 'assuming' RELEASE
+ ACQUIRE was a full barrier, so who knows what else is out there.


RCsc - release consistency sequential consistency
RCpc - release consistency processor consistency

https://en.wikipedia.org/wiki/Processor_consistency


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

[Xen-devel] [qemu-upstream-4.3-testing test] 77853: regressions - FAIL

[osstest service owner]

flight 77853 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77853/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 62112
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 62112

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu6e184363e64a0610c35ca231bfc73cea56eb02f3
baseline version:
 qemuub188780861662e8cf1847ec562799b32bb44f05e

Last test of basis62112  2015-09-18 04:07:28 Z  116 days
Testing same since66538  2015-12-18 16:12:07 Z   25 days   15 attempts


People who touched revisions under test:
  Stefano Stabellini 

jobs:
 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  pass
 test-amd64-i386-xl   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-pv  pass
 test-amd64-i386-pv   pass
 test-amd64-amd64-amd64-pvgrubpass
 test-amd64-amd64-i386-pvgrub pass
 test-amd64-amd64-pygrub  pass
 test-amd64-amd64-xl-qcow2pass
 test-amd64-i386-xl-raw   pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-libvirt-vhd pass
 test-amd64-amd64-xl-qemuu-winxpsp3   fail



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

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

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

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


Not pushing.


commit 6e184363e64a0610c35ca231bfc73cea56eb02f3
Author: Stefano Stabellini 
Date:   Fri Dec 18 15:45:14 2015 +

xenfb: avoid reading twice the same fields from the shared page

Reading twice the same field could give the guest an attack of
opportunity. In the case of event->type, gcc could compile the switch
statement into a jump table, effectively ending up reading the type
field multiple times.

This is part of 

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

[Wei Liu]

Drop xen-users@, CC xen-devel@ and blk maintainers, change title.

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

> ___
> Xen-users mailing list
> xen-us...@lists.xen.org
> http://lists.xen.org/xen-users


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

Re: [Xen-devel] [PATCH 2/2] vm_event: Add altp2m info to HVM events as well

[Tamas K Lengyel]

On Jan 12, 2016 3:21 AM, "Jan Beulich"  wrote:
>
> >>> On 06.01.16 at 12:50,  wrote:
> > On Wed, Jan 6, 2016 at 12:48 PM, Andrew Cooper <
andrew.coop...@citrix.com>
> > wrote:
> >
> >> On 06/01/16 11:42, Tamas K Lengyel wrote:
> >>
> >>
> >>
> >> On Wed, Jan 6, 2016 at 12:32 PM, Jan Beulich  wrote:
> >>
> >>> >>> On 23.12.15 at 15:53, < ta...@tklengyel.com>
> >>> wrote:
> >>> > @@ -83,6 +84,12 @@ static int hvm_event_traps(uint8_t sync,
> >>> vm_event_request_t *req)
> >>> >  vm_event_vcpu_pause(curr);
> >>> >  }
> >>> >
> >>> > +if ( altp2m_active(currd) )
> >>> > +{
> >>> > +req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
> >>> > +req->altp2m_idx = vcpu_altp2m(curr).p2midx;
> >>> > +}
> >>>
> >>> So far this info was provided just for MEM_ACCESS events. Now
> >>> you provide it for a few more ones, but wouldn't this then better
> >>> be supplied for all of them, namely also the other two MEM ones?
> >>>
> >>
> >> AFAIK altp2m is currently incompatible with sharing. I'm not 100% sure
but
> >> I think it's also incompatible with paging.
> >>
> >>
> >> I don't think they are strictly incompatible; I don't see a technical
> >> reason preventing some development work to make them function together.
> >>
> >> Whether this happens or not is a very different matter.
> >
> > Sure, the two systems can be made to work in tandem, this work just
hasn't
> > been done yet. I would very much like to get that to work in the future.
>
> Which re-raises the question: Shouldn't the information then be
> made available uniformly for all events?
>

IMHO there is no point doing so while the systems don't work together.

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

Re: [Xen-devel] [PATCH v2 1/2] build: introduce CONFIG_NR_CPUS in Kconfig

[Doug Goldstein]

On 1/12/16 2:37 AM, Jan Beulich wrote:
 On 11.01.16 at 23:02,  wrote:
>> --- /dev/null
>> +++ b/xen/arch/Kconfig
>> @@ -0,0 +1,8 @@
>> +
>> +config NR_CPUS
>> +int "Maximum number of physical CPUs"
>> +range 1 65536
> 
> Why did you change this to 64k, when we settled on 4k-1 being
> correct? I don't mind fixing this up upon commit, but I'd like it to
> be confirmed that this was unintentional.
> 
> Jan
> 

It was definitely unintentional. I must have edited the patch to make it
4095 the first time before I sent it.

-- 
Doug Goldstein



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

[Xen-devel] [PATCH 2/2] libxl: fix UUID usage on FreeBSD

[Roger Pau Monne]

libxl makes the assumtion that libxl_uuid == uuid_t, and that uuid_t can be
freely used as a byte array. This is not true on FreeBSD (and NetBSD
too, not sure about other BSD UUID implementations), where the internals of
uuid don't match what libxl expects as a byte array because of endianness
issues.

Fix this by converting the libxl_uuid type to a struct with an internal
uuid_t field and a byte-array. Also introduce a new function that should be
used in order to load a byte array into a uuid_t struct.

Signed-off-by: Roger Pau Monné 
---
 tools/libxl/libxl.c  |  2 +-
 tools/libxl/libxl.h  |  9 +
 tools/libxl/libxl_uuid.c | 22 +++---
 tools/libxl/libxl_uuid.h |  3 ++-
 4 files changed, 31 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 9207621..ae08b2f 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -616,7 +616,7 @@ static void xcinfo2xlinfo(libxl_ctx *ctx,
 {
 size_t size;
 
-memcpy(&(xlinfo->uuid), xcinfo->handle, sizeof(xen_domain_handle_t));
+libxl_uuid_from_bytearray(>uuid, xcinfo->handle);
 xlinfo->domid = xcinfo->domain;
 xlinfo->ssidref = xcinfo->ssidref;
 if (libxl_flask_sid_to_context(ctx, xlinfo->ssidref,
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 05606a7..876fca8 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -867,6 +867,15 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, 
libxl_mac *src);
  */
 #define LIBXL_HAVE_DEVICE_MODEL_VERSION_NONE 1
 
+/*
+ * LIBXL_HAVE_UUID_FROM_BYTEARRAY
+ *
+ * In the case that LIBXL_HAVE_UUID_FROM_BYTEARRAY is set libxl
+ * provides a function (libxl_uuid_from_bytearray) to convert an
+ * octet stream into a UUID.
+ */
+#define LIBXL_HAVE_UUID_FROM_BYTEARRAY 1
+
 typedef char **libxl_string_list;
 void libxl_string_list_dispose(libxl_string_list *sl);
 int libxl_string_list_length(const libxl_string_list *sl);
diff --git a/tools/libxl/libxl_uuid.c b/tools/libxl/libxl_uuid.c
index 7d4a032..f566f50 100644
--- a/tools/libxl/libxl_uuid.c
+++ b/tools/libxl/libxl_uuid.c
@@ -33,6 +33,12 @@ int libxl_uuid_from_string(libxl_uuid *uuid, const char *in)
  return uuid_parse(in, uuid->uuid);
 }
 
+int libxl_uuid_from_bytearray(libxl_uuid *uuid, const uint8_t *raw)
+{
+memcpy(uuid, raw, sizeof(*uuid));
+return 0;
+}
+
 void libxl_uuid_copy(libxl_ctx *ctx_opt, libxl_uuid *dst,
  const libxl_uuid *src)
 {
@@ -72,9 +78,9 @@ void libxl_uuid_generate(libxl_uuid *uuid)
 {
 uint32_t status;
 
-BUILD_BUG_ON(sizeof(libxl_uuid) != sizeof(uuid_t));
 uuid_create(>uuid, );
 assert(status == uuid_s_ok);
+uuid_enc_be(uuid->uuid_raw, >uuid);
 }
 
 #ifdef __FreeBSD__
@@ -85,6 +91,8 @@ int libxl_uuid_from_string(libxl_uuid *uuid, const char *in)
 uuid_from_string(in, >uuid, );
 if (status != uuid_s_ok)
 return -1;
+uuid_enc_be(uuid->uuid_raw, >uuid);
+
 return 0;
 }
 #else
@@ -101,15 +109,23 @@ int libxl_uuid_from_string(libxl_uuid *uuid, const char 
*in)
 #undef LIBXL__UUID_PTRS
 #endif
 
+int libxl_uuid_from_bytearray(libxl_uuid *uuid, const uint8_t *raw)
+{
+uuid_dec_le(raw, >uuid);
+uuid_enc_be(uuid->uuid_raw, >uuid);
+
+return 0;
+}
+
 void libxl_uuid_copy(libxl_ctx *ctx_opt, libxl_uuid *dst,
  const libxl_uuid *src)
 {
-memcpy(>uuid, >uuid, sizeof(dst->uuid));
+memcpy(dst, src, sizeof(*dst));
 }
 
 void libxl_uuid_clear(libxl_uuid *uuid)
 {
-memset(>uuid, 0, sizeof(uuid->uuid));
+memset(uuid, 0, sizeof(*uuid));
 }
 
 #ifdef __FreeBSD__
diff --git a/tools/libxl/libxl_uuid.h b/tools/libxl/libxl_uuid.h
index c5041c7..d84e3d1 100644
--- a/tools/libxl/libxl_uuid.h
+++ b/tools/libxl/libxl_uuid.h
@@ -42,7 +42,7 @@ typedef struct {
 #include 
 #include 
 
-typedef union {
+typedef struct {
 uuid_t uuid;
 uint8_t uuid_raw[16];
 } libxl_uuid;
@@ -73,6 +73,7 @@ void libxl_uuid_clear(libxl_uuid *uuid);
 int libxl_uuid_compare(const libxl_uuid *uuid1, const libxl_uuid *uuid2);
 const uint8_t *libxl_uuid_bytearray_const(const libxl_uuid *uuid);
 uint8_t *libxl_uuid_bytearray(libxl_uuid *uuid);
+int libxl_uuid_from_bytearray(libxl_uuid *uuid, const uint8_t *raw);
 
 #endif /* __LIBXL_UUID_H__ */
 
-- 
1.9.5 (Apple Git-50.3)


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

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

[Peter Zijlstra]

On Tue, Jan 12, 2016 at 10:27:11AM +0100, Peter Zijlstra wrote:
> 2) the changelog _completely_ fails to explain the sync 0x11 and sync
> 0x12 semantics nor does it provide a publicly accessible link to
> documentation that does.

Ralf pointed me at: https://imgtec.com/mips/architectures/mips64/

> 3) it really should have explained what you did with
> smp_llsc_mb/smp_mb__before_llsc() in _detail_.

And reading the MIPS64 v6.04 instruction set manual, I think 0x11/0x12
are _NOT_ transitive and therefore cannot be used to implement the
smp_mb__{before,after} stuff.

That is, in MIPS speak, those SYNC types are Ordering Barriers, not
Completion Barriers. They need not be globally performed.

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

Re: [Xen-devel] [PATCH] x86/hvm: Allow the guest to permit the use of userspace hypercalls

[George Dunlap]

On Tue, Jan 12, 2016 at 10:57 AM, Andrew Cooper
 wrote:
> Writing a PV guest from scratch has been very enlightening to
> demonstrate how much of a trainwreck the ABI is.  Almost nothing is
> documented.  Some bits which are documented are misleading.  Several
> areas needlessly deviate from x86 architectural behaviour.  Almost any
> deviation from the way Linux does things ends up in situations which
> don't function.

Something I think HPA has been complaining about for nearly a decade
now I think...

 -George

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

[Xen-devel] [PATCH 1/2] libxl: fix _SC_GETPW_R_SIZE_MAX usage

[Roger Pau Monne]

According to the FreeBSD sysconf man page [0] if the variable is associated
with functionality that is not supported, -1 is returned and errno is not
modified. Modify libxl__dm_runas_helper so it's able to correctly
deal with this situation by setting the initial buffer value to 2048.

[0] https://www.freebsd.org/cgi/man.cgi?query=sysconf

Signed-off-by: Roger Pau Monné 
---
 tools/libxl/libxl_dm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 0aaefd9..ec8fb51 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -728,7 +728,14 @@ static int libxl__dm_runas_helper(libxl__gc *gc, const 
char *username)
 long buf_size;
 int ret;
 
+errno = 0;
 buf_size = sysconf(_SC_GETPW_R_SIZE_MAX);
+if (buf_size < 0 && errno == 0) {
+buf_size = 2048;
+LOG(DEBUG,
+"sysconf(_SC_GETPW_R_SIZE_MAX) is not supported, using a buffer size of %ld",
+buf_size);
+}
 if (buf_size < 0) {
 LOGE(ERROR, "sysconf(_SC_GETPW_R_SIZE_MAX) returned error %ld",
 buf_size);
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [PATCH 0/2] libxl: FreeBSD fixes

[Roger Pau Monne]

Hello,

This series contains a couple of small fixes for FreeBSD. The first one is 
regarding the newly introduced libxl__dm_runas_helper function and it's 
usage of sysconf, while the second one fixes a long-stading bug that impacts 
UUID usage on FreeBSD (and NetBSD AFAICT).

Thanks, Roger.


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

Re: [Xen-devel] [Qemu-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()

[Gerd Hoffmann]

On Di, 2016-01-12 at 09:50 +, Hao, Xudong wrote:
> With latest qemu 7b8a354d4716, RHEL7.2 (with default kernel) VM still can't 
> boot up with IGD.

There is another bug, using pci_default_write_config() doesn't fly as
this checks writes against wmask and the registers in question are not
whitelisted ...

I've just rebased my igd patch series which (among other stuff) fixes
that bug:
  https://www.kraxel.org/cgit/qemu/log/?h=work/igd
  git://git.kraxel.org/qemu work/igd

Can you give it a spin?

Also: what does "can't boot up" mean exactly?  Guest doesn't boot at
all?  Guest boots, but igd/console/Xorg doesn't work?  In case of the
latter:  Any chance to login via network and get a kernel log?

thanks,
  Gerd


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

Re: [Xen-devel] [PATCH] x86/hvm: Allow the guest to permit the use of userspace hypercalls

[Andrew Cooper]

On 12/01/16 07:33, Jan Beulich wrote:
 On 11.01.16 at 18:17,  wrote:
>> On 11/01/16 14:44, Jan Beulich wrote:
>> On 11.01.16 at 14:59,  wrote:
 Currently, hypercalls issued from HVM userspace will unconditionally fail
 with -EPERM.

 This is inflexible, and a guest may wish to allow userspace to make
 hypercalls.
>>> I thought previous discussion had made clear that routing these
>>> through ioctls or alike is the right approach, and hence the patch
>>> isn't needed. The more that an all-or-nothing approach seems
>>> pretty bold.
>> All other issues fixed in v2, but to answer this one specifically.
>>
>> In it inappropriate for Xen to presume that all guests want Linux-like
>> handing of situations like this.  It is simply not true.
>>
>> As part of getting my test framework ready to publish, I attempted to
>> port my XSA-106 unit tests to PV guests.  I have shelved that work as I
>> don't have sufficient time to fix PV trap handing in Xen at this present
>> time, but do plan to fix them in due course.
>>
>> The bugs I have identified so far are:
>> * "INT n" handling assumes the instruction was 2 bytes long
>> * In some circumstances, Xen crashes the domain rather than injecting
>> #NP[sel]
>> * In most circumstances, Xen delivers #GP[sel] where #NP[sel] would be
>> correct
> All of these could be considered part of the awareness
> requirements towards guests.

The first causes corruption of process state in circumstances which
wouldn't under native, including userspace state.

You could make that argument for the final two.  I reckon it is an
unreasonable requirement.

>
>> * Not possible to have non-dpl3 descriptors for #BP and #OF
> Actually the issue is broader I think (I've stumbled across this
> limitation before, namely in the context of the #AC issue having
> been the subject of a recent XSA) - you can't associate a DPL
> with any exception vector.

Ah - I had not patched Xen up sufficiently for the unit test to notice
this (the domain crashes rather than #NP exceptions were prohibitive).

>
>> * Not possible to mark an existing descriptor as not-present
> "Not easily possible" I suppose you mean, since one can by re-
> writing the entire table.

Can't be done atomically.  Even if interrupts are disabled, there is a
window where NMIs and MCEs would be lost.


Writing a PV guest from scratch has been very enlightening to
demonstrate how much of a trainwreck the ABI is.  Almost nothing is
documented.  Some bits which are documented are misleading.  Several
areas needlessly deviate from x86 architectural behaviour.  Almost any
deviation from the way Linux does things ends up in situations which
don't function.

~Andrew

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 66879

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 66879
 test-armhf-armhf-xl-rtds  9 debian-installfail REGR. vs. 66879
 test-amd64-i386-rumpuserxen-i386 10 guest-startfail like 66879
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 66879
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66879
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   like 66879

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

version targeted for testing:
 xen  f7347a282420a5edc74afb31e7c42c2765f24de5
baseline version:
 xen  bf925a9f1254391749f569c1b8fc606036340488

Last test of basis66879  2015-12-21 21:25:56 Z   21 days
Failing since 67053  2015-12-23 06:54:21 Z   20 days6 attempts
Testing same since77827  2016-01-11 12:11:48 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Bob Moore 
  Boris Ostrovsky 
  Daniel De Graaf 
  Doug Goldstein 
  Feng Wu 
  Graeme Gregory 
  Hanjun Guo 
  Haozhong Zhang 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Joshua Otto 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Len Brown 
  Lin Ming 
  Lv Zheng 
  Paul Durrant 
  Rafael J. Wysocki 
  Samuel Thibault 
  Shannon Zhao 
  Stefano Stabellini 
  Tomasz Nowicki 

Re: [Xen-devel] [PATCH RFC OSSTEST v1 04/12] mfi-common: always add host suite to hostos_runvars

[Ian Jackson]

Ian Campbell writes ("[PATCH RFC OSSTEST v1 04/12] mfi-common: always add host 
suite to hostos_runvars"):
> This avoids situations where production-config* has changed
> DebianSuite but the bisector is still picking up baselines etc from
> before the change and reusing their runvars (without suite) with an
> inconsistent config.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH] x86/PV: fix unintended dependency of m2p-strict mode on migration-v2

[Andrew Cooper]

On 12/01/16 10:08, Jan Beulich wrote:
> This went unnoticed until a backport of this to an older Xen got used,
> causing migration of guests enabling this VM assist to fail, because
> page table pinning there preceeds vCPU context loading, and hence L4
> tables get initialized for the wrong mode. Fix this by post-processing
> L4 tables when setting the intended VM assist flags for the guest.
>
> Note that this leaves in place a dependency on vCPU 0 getting its guest
> context restored first, but afaict the logic here is not the only thing
> depending on that.
>
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1067,8 +1067,48 @@ int arch_set_info_guest(
>  goto out;
>  
>  if ( v->vcpu_id == 0 )
> +{
>  d->vm_assist = c(vm_assist);
>  
> +/*
> + * In the restore case we need to deal with L4 pages which got
> + * initialized with m2p_strict still clear (and which hence lack the
> + * correct initial RO_MPT_VIRT_{START,END} L4 entry).
> + */
> +if ( d != current->domain && VM_ASSIST(d, m2p_strict) &&
> + is_pv_domain(d) && !is_pv_32bit_domain(d) &&
> + atomic_read(>arch.pv_domain.nr_l4_pages) )
> +{
> +bool_t done = 0;
> +
> +spin_lock_recursive(>page_alloc_lock);
> +
> +for ( i = 0; ; )
> +{
> +struct page_info *page = 
> page_list_remove_head(>page_list);
> +
> +if ( page_lock(page) )
> +{
> +if ( (page->u.inuse.type_info & PGT_type_mask) ==
> + PGT_l4_page_table )
> +done = !fill_ro_mpt(page_to_mfn(page));
> +
> +page_unlock(page);
> +}
> +
> +page_list_add_tail(page, >page_list);
> +
> +if ( done || (!(++i & 0xff) && hypercall_preempt_check()) )
> +break;
> +}
> +
> +spin_unlock_recursive(>page_alloc_lock);
> +
> +if ( !done )
> +return -ERESTART;

This is a long loop.  It is preemptible, but will incur a time delay
proportional to the size of the domain during the VM downtime. 

Could you defer the loop until after %cr3 has set been set up, and only
enter the loop if the kernel l4 table is missing the RO mappings?  That
way, domains migrated with migration v2 will skip the loop entirely.

> +}
> +}
> +
>  rc = put_old_guest_table(current);
>  if ( rc )
>  return rc;
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -1463,13 +1463,20 @@ void init_guest_l4_table(l4_pgentry_t l4
>  l4tab[l4_table_offset(RO_MPT_VIRT_START)] = l4e_empty();
>  }
>  
> -void fill_ro_mpt(unsigned long mfn)
> +bool_t fill_ro_mpt(unsigned long mfn)
>  {
>  l4_pgentry_t *l4tab = map_domain_page(_mfn(mfn));
> +bool_t ret = 0;
>  
> -l4tab[l4_table_offset(RO_MPT_VIRT_START)] =
> -idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)];
> +if ( !l4e_get_intpte(l4tab[l4_table_offset(RO_MPT_VIRT_START)]) )
> +{
> +l4tab[l4_table_offset(RO_MPT_VIRT_START)] =
> +idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)];
> +ret = 1;

This is a behavioural change.  Previously, the old value was clobbered.

It appears that you are now using this return value to indicate when the
entire pagelist has been walked, but it it relies on the slots being
zero, which is a fragile assumption.

~Andrew

> +}
>  unmap_domain_page(l4tab);
> +
> +return ret;
>  }
>  
>  void zap_ro_mpt(unsigned long mfn)
> @@ -1527,10 +1534,15 @@ static int alloc_l4_table(struct page_in
>  adjust_guest_l4e(pl4e[i], d);
>  }
>  
> -init_guest_l4_table(pl4e, d, !VM_ASSIST(d, m2p_strict));
> +if ( rc >= 0 )
> +{
> +init_guest_l4_table(pl4e, d, !VM_ASSIST(d, m2p_strict));
> +atomic_inc(>arch.pv_domain.nr_l4_pages);
> +rc = 0;
> +}
>  unmap_domain_page(pl4e);
>  
> -return rc > 0 ? 0 : rc;
> +return rc;
>  }
>  
>  static void free_l1_table(struct page_info *page)
> @@ -1648,7 +1660,13 @@ static int free_l4_table(struct page_inf
>  
>  unmap_domain_page(pl4e);
>  
> -return rc > 0 ? 0 : rc;
> +if ( rc >= 0 )
> +{
> +atomic_dec(>arch.pv_domain.nr_l4_pages);
> +rc = 0;
> +}
> +
> +return rc;
>  }
>  
>  int page_lock(struct page_info *page)
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -248,6 +248,8 @@ struct pv_domain
>  {
>  l1_pgentry_t **gdt_ldt_l1tab;
>  
> +atomic_t nr_l4_pages;
> +
>  /* map_domain_page() mapping cache. */
>  struct mapcache_domain mapcache;
>  };
> --- a/xen/include/asm-x86/mm.h
> +++ b/xen/include/asm-x86/mm.h
> @@ -322,7 +322,7 @@ int free_page_type(struct page_info *pag
>  
>  void init_guest_l4_table(l4_pgentry_t[], const struct domain 

Re: [Xen-devel] blk_update_request: I/O error on NFS

[Roger Pau Monné]

Hello,

El 12/01/16 a les 13.05, Wei Liu ha escrit:
> Drop xen-users@, CC xen-devel@ and blk maintainers, change title.
> 
> On Mon, Jan 11, 2016 at 03:08:24PM +0100, Kojedzinszky Richárd wrote:
>> Dear all,
>>
>> We are facing a regular lockup with our xen setup. We have an nfs share
>> mounted on the xen dom0, where the vm images are served, and those files are
>> given to xen domUs.
>>
>> I was just preparing an experiment, where I created a 100G file on the host:
>> # truncate -s 100G /srv/nfs/domU/disk2
>> And after added this disk to the instance's configuration.

Have you tried creating the file with dd instead of truncate? (so it's
not sparse)

>> On the host this is the mountpoint:
>> # mount|grep srv/xen
>> 10.1.1.1:/mnt/main/vps on /srv/xen type nfs 
>> (rw,relatime,vers=3,rsize=16384,wsize=16384,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.1.1.1,mountvers=3,mountport=4045,mountproto=udp,local_lock=none,addr=10.1.1.1)
>>
>> After starting the instance I partitioned the disk with gdisk, and created
>> an xfs fs on it. While the fs has been created well, strange messages
>> appeared on the console:

AFAICT this is the guest console. Is there any corresponding error on
the host console?

>> [   23.787504] blk_update_request: I/O error, dev xvdc, sector 2048
>> [   23.788904] blk_update_request: I/O error, dev xvdc, sector 8390655
>> [   23.789611] blk_update_request: I/O error, dev xvdc, sector 16779262
>> [   23.790359] blk_update_request: I/O error, dev xvdc, sector 25167869
>> [   23.791148] blk_update_request: I/O error, dev xvdc, sector 33556476
>> [   23.791498] blk_update_request: I/O error, dev xvdc, sector 41945083
>> [   23.791498] blk_update_request: I/O error, dev xvdc, sector 50333690
>> [   23.791498] blk_update_request: I/O error, dev xvdc, sector 58722297
>> [   23.791498] blk_update_request: I/O error, dev xvdc, sector 67110904
>> [   23.791498] blk_update_request: I/O error, dev xvdc, sector 75499511
>>
>> I dont think that this is normal. If I chose a local block device (probably
>> lvm) for the domU, this does not appear.

IIRC Xen 4.4 still uses Qemu (Qdisk) for raw disks, do you have any kind
of errors/warnings in /var/log/xen/qemu-dm-.log?

Roger.


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

Re: [Xen-devel] [PATCH 2/2] vm_event: Add altp2m info to HVM events as well

[Jan Beulich]

>>> On 06.01.16 at 12:50,  wrote:
> On Wed, Jan 6, 2016 at 12:48 PM, Andrew Cooper 
> wrote:
> 
>> On 06/01/16 11:42, Tamas K Lengyel wrote:
>>
>>
>>
>> On Wed, Jan 6, 2016 at 12:32 PM, Jan Beulich  wrote:
>>
>>> >>> On 23.12.15 at 15:53, < ta...@tklengyel.com>
>>> wrote:
>>> > @@ -83,6 +84,12 @@ static int hvm_event_traps(uint8_t sync,
>>> vm_event_request_t *req)
>>> >  vm_event_vcpu_pause(curr);
>>> >  }
>>> >
>>> > +if ( altp2m_active(currd) )
>>> > +{
>>> > +req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
>>> > +req->altp2m_idx = vcpu_altp2m(curr).p2midx;
>>> > +}
>>>
>>> So far this info was provided just for MEM_ACCESS events. Now
>>> you provide it for a few more ones, but wouldn't this then better
>>> be supplied for all of them, namely also the other two MEM ones?
>>>
>>
>> AFAIK altp2m is currently incompatible with sharing. I'm not 100% sure but
>> I think it's also incompatible with paging.
>>
>>
>> I don't think they are strictly incompatible; I don't see a technical
>> reason preventing some development work to make them function together.
>>
>> Whether this happens or not is a very different matter.
> 
> Sure, the two systems can be made to work in tandem, this work just hasn't
> been done yet. I would very much like to get that to work in the future.

Which re-raises the question: Shouldn't the information then be
made available uniformly for all events?

Jan


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

Re: [Xen-devel] [PATCH v2] x86/hvm: Allow the guest to permit the use of userspace hypercalls

[George Dunlap]

On Mon, Jan 11, 2016 at 5:58 PM, Andrew Cooper
 wrote:
> On 11/01/16 17:11, Konrad Rzeszutek Wilk wrote:
>> On Mon, Jan 11, 2016 at 04:51:19PM +, Andrew Cooper wrote:
>>> Currently, hypercalls issued from HVM userspace will unconditionally fail 
>>> with
>>> -EPERM.
>>>
>>> This is inflexible, and a guest may wish to allow userspace to make
>>> hypercalls.
>>>
>>> Introduce HVMOP_set_hypercall_dpl which allows the guest to alter the
>>> permissions check for hypercalls.  It behaves exactly like the dpl field for
>>> GDT/LDT/IDT entries.
>>
>> Could you explain a bit of the use-case?
>
> My specific usecase,
> http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen-test-framework.git;a=shortlog;h=refs/heads/wip-traps-v0.1
>
> It isn't quite ready for formal release yet.
>
>> As in why the ioctl via the kernel is no good?
>
> Who says Linux is running?
>
> Hopefully answered in
> http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg01155.html

Not really.  Obviously if you're running custom test code rather than
Linux, then you aren't going to make an ioctl system call on a file
descriptor; but what people are actually suggesting is just that you
make *some* sort of system call from ring 3 which will then make the
hypercall from ring 0.  That's not "the Linux way" of doing things,
it's the *operating system* way of doing things.

>From the previous discussion, ISTR that what you want to be able to
log messages to the Xen console from your test code when running in
ring 3.  It should be fairly easy to set up a custom system call in
your test system that will then make the appropriate hypercall from
ring 0 and return, with minimal interaction with other parts of the
system.  (I think there were some other suggestions there as well.)

Is there a reason that's not possible?

 -George

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1fail REGR. vs. 38609

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl  19 guest-start/debian.repeatfail   like 38609
 test-amd64-amd64-xl-xsm  19 guest-start/debian.repeatfail   like 38609
 test-amd64-amd64-pygrub  18 guest-start/debian.repeatfail   like 38609
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install  fail like 38609

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

version targeted for testing:
 qemuu6bb9ead762bf749af11ea225fc2a74db1b93c105
baseline version:
 qemuua7e00e2536941a6e570b45b7ab4afec4505ff67e

Last test of basis38609  2016-01-09 11:22:39 Z2 days
Testing same since38621  2016-01-11 16:55:22 Z0 days1 attempts


People who touched revisions under test:
  Bandan Das 
  Bo Tu 
  Fam Zheng 
  Gerd Hoffmann 
  Hervé Poussineau 
  Laurent Vivier 
  Mark Cave-Ayland 
  Markus Armbruster 
  Max Reitz 
  OGAWA Hirofumi 
  Paolo Bonzini 
  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  

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

[Will Deacon]

On Tue, Jan 12, 2016 at 11:40:12AM +0100, Peter Zijlstra wrote:
> On Tue, Jan 12, 2016 at 11:25:55AM +0100, Peter Zijlstra wrote:
> > On Tue, Jan 12, 2016 at 10:27:11AM +0100, Peter Zijlstra wrote:
> > > 2) the changelog _completely_ fails to explain the sync 0x11 and sync
> > > 0x12 semantics nor does it provide a publicly accessible link to
> > > documentation that does.
> > 
> > Ralf pointed me at: https://imgtec.com/mips/architectures/mips64/
> > 
> > > 3) it really should have explained what you did with
> > > smp_llsc_mb/smp_mb__before_llsc() in _detail_.
> > 
> > And reading the MIPS64 v6.04 instruction set manual, I think 0x11/0x12
> > are _NOT_ transitive and therefore cannot be used to implement the
> > smp_mb__{before,after} stuff.
> > 
> > That is, in MIPS speak, those SYNC types are Ordering Barriers, not
> > Completion Barriers. They need not be globally performed.
> 
> Which if true; and I know Will has some questions here; would also mean
> that you 'cannot' use the ACQUIRE/RELEASE barriers for your locks as was
> recently suggested by David Daney.

The issue I have with the SYNC description in the text above is that it
describes the single CPU (program order) and the dual-CPU (confusingly
named global order) cases, but then doesn't generalise any further. That
means we can't sensibly reason about transitivity properties when a third
agent is involved. For example, the WRC+sync+addr test:


P0:
Wx = 1

P1:
Rx == 1
SYNC
Wy = 1

P2:
Ry == 1

Rx = 0


I can't find anything to forbid that, given the text. The main problem
is having the SYNC on P1 affect the write by P0.

> That is, currently all architectures -- with exception of PPC -- have
> RCsc locks, but using these non-transitive things will get you RCpc
> locks.
> 
> So yes, MIPS can go RCpc for its locks and share the burden of pain with
> PPC, but that needs to be a very concious decision.

I think it's much worse than RCpc, given my interpretation of the wording.

Will

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

Re: [Xen-devel] [PATCH v2] x86/hvm: Allow the guest to permit the use of userspace hypercalls

[Stefano Stabellini]

On Mon, 11 Jan 2016, Andrew Cooper wrote:
> Currently, hypercalls issued from HVM userspace will unconditionally fail with
> -EPERM.
> 
> This is inflexible, and a guest may wish to allow userspace to make
> hypercalls.
> 
> Introduce HVMOP_set_hypercall_dpl which allows the guest to alter the
> permissions check for hypercalls.  It behaves exactly like the dpl field for
> GDT/LDT/IDT entries.
> 
> As the dpl is initialised to 0, hypercalls are restricted to cpl0 code until
> the OS explicitly chooses an alternative.
> 
> Signed-off-by: Andrew Cooper 
> --
> CC: Jan Beulich 
> CC: Ian Campbell 
> CC: Stefano Stabellini 
> 
> v2:
>  * Fix rcu lock and dpl check.
>  * Use uint8_t for hypercall_dpl and reposition for better packing.
> 
> The test framework (soon to be published officially) how has both positive and
> negative tests to confirm the correct behaviour of this hypercall.
> 
> Arm folks: Is something like this sufficiently generic to be useful on Arm,
> perhaps with more generic naming?

Hypercalls on ARM are made issuing an HVC instruction which is
"UNDEFINED in Secure state, and in User mode in Non-secure state".

In other words, it cannot work.


> PV guest support for userspace hypercalls is substantially more involved, and
> will take longer to complete.
> ---
>  xen/arch/x86/hvm/hvm.c   | 28 +++-
>  xen/include/asm-x86/hvm/domain.h |  2 ++
>  xen/include/public/hvm/hvm_op.h  |  8 
>  3 files changed, 37 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 21470ec..5f3be6b 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -5228,7 +5228,8 @@ int hvm_do_hypercall(struct cpu_user_regs *regs)
>  case 4:
>  case 2:
>  hvm_get_segment_register(curr, x86_seg_ss, );
> -if ( unlikely(sreg.attr.fields.dpl) )
> +if ( unlikely(sreg.attr.fields.dpl >
> +  currd->arch.hvm_domain.hypercall_dpl) )
>  {
>  default:
>  regs->eax = -EPERM;
> @@ -6839,6 +6840,31 @@ long do_hvm_op(unsigned long op, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
>  rc = do_altp2m_op(arg);
>  break;
>  
> +case HVMOP_set_hypercall_dpl:
> +{
> +xen_hvm_hypercall_dpl_t a;
> +struct domain *d;
> +
> +if ( copy_from_guest(, arg, 1 ) )
> +return -EFAULT;
> +
> +d = rcu_lock_domain_by_any_id(a.domid);
> +if ( d == NULL )
> +return -ESRCH;
> +
> +if ( current->domain != d )
> +return -EPERM;
> +
> +if ( !is_hvm_domain(d) )
> +return -EINVAL;
> +
> +if ( a.dpl > 3 )
> +return -EDOM;
> +
> +d->arch.hvm_domain.hypercall_dpl = a.dpl;
> +break;
> +}
> +
>  default:
>  {
>  gdprintk(XENLOG_DEBUG, "Bad HVM op %ld.\n", op);
> diff --git a/xen/include/asm-x86/hvm/domain.h 
> b/xen/include/asm-x86/hvm/domain.h
> index a8cc2ad..ac426ce 100644
> --- a/xen/include/asm-x86/hvm/domain.h
> +++ b/xen/include/asm-x86/hvm/domain.h
> @@ -123,6 +123,8 @@ struct hvm_domain {
>  spinlock_t uc_lock;
>  bool_t is_in_uc_mode;
>  
> +uint8_thypercall_dpl;
> +
>  /* Pass-through */
>  struct hvm_iommu   hvm_iommu;
>  
> diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
> index 1606185..f8247db 100644
> --- a/xen/include/public/hvm/hvm_op.h
> +++ b/xen/include/public/hvm/hvm_op.h
> @@ -489,6 +489,14 @@ struct xen_hvm_altp2m_op {
>  typedef struct xen_hvm_altp2m_op xen_hvm_altp2m_op_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_op_t);
>  
> +#define HVMOP_set_hypercall_dpl 26
> +struct xen_hvm_hypercall_dpl {
> +domid_t domid;
> +uint16_t dpl;  /* IN[1:0] cpl required to make hypercalls. */
> +};
> +typedef struct xen_hvm_hypercall_dpl xen_hvm_hypercall_dpl_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_hvm_hypercall_dpl_t);
> +
>  #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */
>  
>  /*
> -- 
> 2.1.4
> 

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

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

[Leonid Yegoshin]

(I try to answer on multiple mails in one)

First of all, it seems like some generic notes should be given here:

1. Generic MIPS "SYNC" (aka "SYNC 0") instruction is a very heavy in 
some CPUs. On that CPUs it basically kills pipelines in each CPU, can do 
a special memory/IO bus transaction (similar to "fence") and hold a 
system until all R/W is completed. It is like Big Kernel Lock but worse. 
So, the move to SMP_* kind of barriers is needed to improve performance, 
especially on newest CPUs with long pipelines.


2. MIPS Arch document may be misleading because words "ordering" and 
"completion" means different from Linux, the SYNC instruction 
description is written for HW engineers. I wrote that in a separate 
patch of the same patchset - 
http://patchwork.linux-mips.org/patch/10505/ "MIPS: R6: Use lightweight 
SYNC instruction in smp_* memory barriers":



This instructions were specifically designed to work for smp_*() sort of
memory barriers in MIPS R2/R3/R5 and R6.

Unfortunately, it's description is very cryptic and is done in HW engineering
style which prevents use of it by SW.


3. I bother MIPS Arch team long time until I completely understood that 
MIPS SYNC_WMB, SYNC_MB, SYNC_RMB, SYNC_RELEASE and SYNC_ACQUIRE do an 
exactly that is required in Documentation/memory-barriers.txt



In Peter Zijlstra mail:


1) you do not make such things selectable; either the hardware needs
them or it doesn't. If it does you_must_  use them, however unlikely.
It is selectable only for MIPS R2 but not MIPS R6. The reason is - most 
of MIPS R2 CPUs have short pipeline and that SYNC is just waste of CPU 
resource, especially taking into account that "lightweight syncs" are 
converted to a heavy "SYNC 0" in many of that CPUs. However the latest 
MIPS/Imagination CPU have a pipeline long enough to hit a problem - 
absence of SYNC at LL/SC inside atomics, barriers etc.



And reading the MIPS64 v6.04 instruction set manual, I think 0x11/0x12
are_NOT_  transitive and therefore cannot be used to implement the
smp_mb__{before,after} stuff.

That is, in MIPS speak, those SYNC types are Ordering Barriers, not
Completion Barriers.


Please see above, point 2.


That is, currently all architectures -- with exception of PPC -- have
RCsc locks, but using these non-transitive things will get you RCpc
locks.

So yes, MIPS can go RCpc for its locks and share the burden of pain with
PPC, but that needs to be a very concious decision.


I don't understand that - I tried hard but I can't find any word like 
"RCsc", "RCpc" in Documents/ directory. Web search goes nowhere, of course.



In Will Deacon mail:


The issue I have with the SYNC description in the text above is that it
describes the single CPU (program order) and the dual-CPU (confusingly
named global order) cases, but then doesn't generalise any further. That
means we can't sensibly reason about transitivity properties when a third
agent is involved. For example, the WRC+sync+addr test:


P0:
Wx = 1

P1:
Rx == 1
SYNC
Wy = 1

P2:
Ry == 1

Rx = 0


I can't find anything to forbid that, given the text. The main problem
is having the SYNC on P1 affect the write by P0.


As I understand that test, the visibility of P0: W[x] = 1 is identical 
to P1 and P2 here. If P1 got X before SYNC and write to Y after SYNC 
then instruction source register dependency tracking in P2 prevents a 
speculative load of X before P2 obtains Y from the same place as P0/P1 
and calculate address of X. If some load of X in P2 happens before 
address dependency calculation it's result is discarded.


Yes, you can't find that in MIPS SYNC instruction description, it is 
more likely in CM (Coherence Manager) area. I just pointed our arch team 
member responsible for documents and he will think how to explain that.


- Leonid.




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

Re: [Xen-devel] [PATCH RFC OSSTEST v1 07/12] ts-debian-di-install: Allow Di Version to come from runvars

[Ian Jackson]

Ian Campbell writes ("[PATCH RFC OSSTEST v1 07/12] ts-debian-di-install: Allow 
Di Version to come from runvars"):
> and following the lead of the suite arrange for a version selected
> from the defaults to be written back to the runvars.
...
> -  debian_guest_suite
> +  debian_guest_suite debian_guest_diversion

Can we please call this function, ..._di_version ?  Otherwise it sounds
very much like something is being diverted.

> +sub debian_guest_diversion ($) {
> +my ($gho) = @_;
> +
> +$gho->{DiVersion} //= guest_var($gho,'diversion',undef);
> +
> +if (!$gho->{DiVersion}) {
> + $gho->{DiVersion} = $c{TftpDiVersion};
> + store_runvar("$gho->{Guest}_diversion", $gho->{DiVersion});

I'm not sure what we should do about the runvar.  `diversion' is a bad
name but there is a risk with `..._di_version' getting confused with
all the `..._revision' fields.

OTOH

osstestdb=> select distinct name from runvars where name like '%version';
 name
 --
  device_model_version
  (1 row)

osstestdb=>

So maybe guest_di_version would be the right answer.

Aside from the questions about this name, this patch LGTM.

Ian.

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

Re: [Xen-devel] [PATCH RFC OSSTEST v1 08/12] make-flight: Set diversion runvar on d-i based test jobs.

[Ian Jackson]

Ian Campbell writes ("[PATCH RFC OSSTEST v1 08/12] make-flight: Set diversion 
runvar on d-i based test jobs."):
> Note that make-distros-flight does not want this, since it uses d-i
> fetched from the web not the version in our config.

Acked-by: Ian Jackson 

Subject to anticipated change to the runvar name.

Ian.

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

Re: [Xen-devel] [PATCH v2 2/2] build: convert NR_CPUS to Kconfig

[Doug Goldstein]

On 1/12/16 2:41 AM, Jan Beulich wrote:
 On 11.01.16 at 23:02,  wrote:
>> --- a/xen/include/xen/config.h
>> +++ b/xen/include/xen/config.h
>> @@ -92,4 +92,7 @@
>>  #define FLASK_AVC_STATS 1
>>  #endif
>>  
>> +/* allow existing code to work with Kconfig variable */
>> +#define NR_CPUS CONFIG_NR_CPUS
> 
> Perhaps here or in a follow-up patch derive CONFIG_SMP (used in a
> few places in ARM code) from NR_CPUS > 1?
> 
> Jan
> 

I agree with you. That's actually in a follow on. I've got most of the
CONFIG_ fields in a branch locally and as each patch gets reviewed I'm
submitting more.

-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH RFC OSSTEST v1 11/12] mfi-common: usual_debianhvm_image: derive version from $guestsuite

[Ian Jackson]

Ian Campbell writes ("[PATCH RFC OSSTEST v1 11/12] mfi-common: 
usual_debianhvm_image: derive version from $guestsuite"):
> This more likely matches the callers intention.
> 
> Move the setting into production-config* alongside the Suite and
> TftpDiVersion settings. Continue to support $DEBIAN_IMAGE_VERSION as an
> override. The value for Wheezy is from what was replaced
> in 610ea1628363 "Switch to Debian 8.0 (jessie) as OS for test hosts".

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH RFC OSSTEST v1 12/12] make-flight: Use older Debian for host and guest OS with older Xen

[Ian Jackson]

Ian Campbell writes ("[PATCH RFC OSSTEST v1 12/12] make-flight: Use older 
Debian for host and guest OS with older Xen"):
> Sometimes when updating osstest to use a newer version of Debian as a
> baseline we find that the new compiler or other tools pickup latent
> errors in older code bases for which the fixes are invasive or
> otherwise inappropriate for a stable branch.
> 
> This is the case with Debian Jessie and Xen 4.3 and earlier, so
> restrict those branches to keep using Wheezy.

Acked-by: Ian Jackson 

Subject to anticipated change to the runvar name.

Ian.

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

Re: [Xen-devel] [GIT PULL] xen: features and fixes for 4.5-rc0

[David Vrabel]

On 11/01/16 23:01, Stephen Rothwell wrote:
> Hi David,
> 
> On Mon, 11 Jan 2016 11:32:01 + David Vrabel  wrote:
>>
>> Please git pull the following tag:
>>
>>  git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
>> for-linus-4.5-rc0-tag
>>
>> xen: features and fixes for 4.5-rc0
>>
>> - - Stolen ticks and PV wallclock support for arm/arm64.
>> - - Add grant copy ioctl to gntdev device.
> 
> So the version I have of this in linux-next has not been updated since
> Dec 2 and is based on v4.4-rc1.  The version above is based on
> v4.4-rc6 and has extra commits ... Did someone forget to update the
> xen-tip/linux-next branch?

Yes.

Ideally I'd like the linux-next branch in ../xen/tip.git to be symbolic
reference to the current for-linus-x.y branch so I do not have to
remember to push to two different branches.  I can't see a way to do
this though.

David

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

Re: [Xen-devel] [PATCH RFC OSSTEST v1 09/12] mfi-common: Set diversion for build & test host install

[Ian Jackson]

Ian Campbell writes ("[PATCH RFC OSSTEST v1 09/12] mfi-common: Set diversion 
for build & test host install"):
> This means that bisections will use the same version, even if
> production-config changed in the mean time.

Acked-by: Ian Jackson 

Subject to anticipated change to the runvar name.

Ian.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 10 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck  6 xen-bootfail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254

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

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

version targeted for testing:
 linuxafd2ff9b7e1b367172f18ba7f693dfb62bdcb2dc
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  187 days
Failing since 59348  2015-07-10 04:24:05 Z  186 days  120 attempts
Testing same since77830  2016-01-11 13:05:12 Z1 days1 attempts


3445 people touched revisions under test,
not listing them all

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

Re: [Xen-devel] [PATCH] x86/PV: fix unintended dependency of m2p-strict mode on migration-v2

[Jan Beulich]

>>> On 12.01.16 at 12:55,  wrote:
> On 12/01/16 10:08, Jan Beulich wrote:
>> This went unnoticed until a backport of this to an older Xen got used,
>> causing migration of guests enabling this VM assist to fail, because
>> page table pinning there preceeds vCPU context loading, and hence L4
>> tables get initialized for the wrong mode. Fix this by post-processing
>> L4 tables when setting the intended VM assist flags for the guest.
>>
>> Note that this leaves in place a dependency on vCPU 0 getting its guest
>> context restored first, but afaict the logic here is not the only thing
>> depending on that.
>>
>> Signed-off-by: Jan Beulich 
>>
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -1067,8 +1067,48 @@ int arch_set_info_guest(
>>  goto out;
>>  
>>  if ( v->vcpu_id == 0 )
>> +{
>>  d->vm_assist = c(vm_assist);
>>  
>> +/*
>> + * In the restore case we need to deal with L4 pages which got
>> + * initialized with m2p_strict still clear (and which hence lack the
>> + * correct initial RO_MPT_VIRT_{START,END} L4 entry).
>> + */
>> +if ( d != current->domain && VM_ASSIST(d, m2p_strict) &&
>> + is_pv_domain(d) && !is_pv_32bit_domain(d) &&
>> + atomic_read(>arch.pv_domain.nr_l4_pages) )
>> +{
>> +bool_t done = 0;
>> +
>> +spin_lock_recursive(>page_alloc_lock);
>> +
>> +for ( i = 0; ; )
>> +{
>> +struct page_info *page = 
>> page_list_remove_head(>page_list);
>> +
>> +if ( page_lock(page) )
>> +{
>> +if ( (page->u.inuse.type_info & PGT_type_mask) ==
>> + PGT_l4_page_table )
>> +done = !fill_ro_mpt(page_to_mfn(page));
>> +
>> +page_unlock(page);
>> +}
>> +
>> +page_list_add_tail(page, >page_list);
>> +
>> +if ( done || (!(++i & 0xff) && hypercall_preempt_check()) )
>> +break;
>> +}
>> +
>> +spin_unlock_recursive(>page_alloc_lock);
>> +
>> +if ( !done )
>> +return -ERESTART;
> 
> This is a long loop.  It is preemptible, but will incur a time delay
> proportional to the size of the domain during the VM downtime. 
> 
> Could you defer the loop until after %cr3 has set been set up, and only
> enter the loop if the kernel l4 table is missing the RO mappings?  That
> way, domains migrated with migration v2 will skip the loop entirely.

Well, first of all this would be the result only as long as you or
someone else don't re-think and possibly move pinning ahead of
context load again.

Deferring until after CR3 got set up is - afaict - not an option, as
it would defeat the purpose of m2p-strict mode as much as doing
the fixup e.g. in the #PF handler. This mode enabled needs to
strictly mean "L4s start with the slot filled, and user-mode uses
clear it", as documented.

There's a much simpler way we could avoid the loop being
entered: Check the previous setting of the flag. However, I
intentionally did not go that route in this initial version as I
didn't want to add more special casing than needed, plus to
make sure the new code isn't effectively dead.

>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -1463,13 +1463,20 @@ void init_guest_l4_table(l4_pgentry_t l4
>>  l4tab[l4_table_offset(RO_MPT_VIRT_START)] = l4e_empty();
>>  }
>>  
>> -void fill_ro_mpt(unsigned long mfn)
>> +bool_t fill_ro_mpt(unsigned long mfn)
>>  {
>>  l4_pgentry_t *l4tab = map_domain_page(_mfn(mfn));
>> +bool_t ret = 0;
>>  
>> -l4tab[l4_table_offset(RO_MPT_VIRT_START)] =
>> -idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)];
>> +if ( !l4e_get_intpte(l4tab[l4_table_offset(RO_MPT_VIRT_START)]) )
>> +{
>> +l4tab[l4_table_offset(RO_MPT_VIRT_START)] =
>> +idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)];
>> +ret = 1;
> 
> This is a behavioural change.  Previously, the old value was clobbered.
> 
> It appears that you are now using this return value to indicate when the
> entire pagelist has been walked, but it it relies on the slots being
> zero, which is a fragile assumption.

There are only two values possible in this slot - zero or the one
referring to the _shared across domains_ sub-tree for the r/o
MPT. I.e. the change of behavior is only an apparent one, and
I don't see this being fragile either.

Jan

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

Re: [Xen-devel] Unexpected error:

[George Dunlap]

On 07/01/16 10:21, Wei Liu wrote:
> CC George (who does the packaging for CentOS)
> 
> BTW this problem is better directed to appropriate mailing list of
> CentOS (centos-virt? I can't remember the exact name).

It would be centos-virt, but as it looks like an upstream bug, if Janis
had reported this there, I probably would have asked him to re-report it
here (or on xen-users).

> On Thu, Jan 07, 2016 at 10:53:00AM +0200, Jānis Andersons | Failiem.lv wrote:
>> xen_major  : 4
>> xen_minor  : 4
>> xen_extra  : .3-3.el6
>> CentOS release 6.7 (Final)
>>
>> After:
>> xm usb-hc-create demo_win2012_r2 2 4

I'm actually a bit surprised this worked, as I didn't think the CentOS
Virt SIG kernel had PVUSB support.  Which kernel are you using?

Chunyan / Juergen, what modules should he look for to see if he has
pvusb backend support?

>> xm usb-list demo_win2012_r2
>> WARNING: xend/xm is deprecated.
>> Idx BE  state usb-ver  BE-path
>> 0   0   1 USB2.0  /local/domain/0/backend/vusb/2/0
>> port 1:
>> port 2:
>> port 3:
>> port 4:
>> xm usb-list-assignable-devices
>> WARNING: xend/xm is deprecated.
>> 1-1  : ID 090c:1000 SMI Corporation USB DISK
>> 1-10 : ID 14dd:0002 Peppercon AG Multidevice
>>
>>
>> xm usb-attach demo_win2012_r2 0 1 1-1
>>
>> WARNING: xend/xm is deprecated.
>> Unexpected error: 
>>
>> Please report to xen-devel@lists.xen.org
>> Traceback (most recent call last):
>>   File "/usr/sbin/xm", line 20, in 
>> main.main(sys.argv)
>>   File "/usr/lib64/python2.6/site-packages/xen/xm/main.py", line 3946, in
>> main
>> _, rc = _run_cmd(cmd, cmd_name, args)
>>   File "/usr/lib64/python2.6/site-packages/xen/xm/main.py", line 3970, in
>> _run_cmd
>> return True, cmd(args)
>>   File "/usr/lib64/python2.6/site-packages/xen/xm/main.py", line 3011, in
>> xm_usb_attach
>> if vusb_util.bus_is_assigned(bus):
>>   File "/usr/lib64/python2.6/site-packages/xen/util/vusb_util.py", line 275,
>> in bus_is_assigned
>> raise UsbDeviceParseError("Can't get assignment status: (%s)." % bus)
>> xen.util.vusb_util.UsbDeviceParseError: vusb: Error parsing USB device info:
>> Can't get assignment status: (1-1).


This could possibly be a side-effect of having no PVUSB backend; it
could also be a straight-up bug in xend.

If it's an issue with having no PVUSB backend, you could try to build a
kernel with support; the SLES kernel is probably your best bet, as I
*think* they officially support it.

If you have PVUSB available, then it's probably a bug in xend.
Unfortunately xend has been poorly maintained for some time. Xen 4.4 is
already out of support, and xend was removed from the tree shortly after
the Xen 4.5 development window opened (hence the warnings).  So in this
case it would most likely be classified as WONTFIX.

PVUSB support for xl is 99% certain to be available for Xen 4.7.

 -George



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

Re: [Xen-devel] [PATCH RFC OSSTEST v1 10/12] Qualify TftpDiVersion with the suite.

[Ian Jackson]

Ian Campbell writes ("[PATCH RFC OSSTEST v1 10/12] Qualify TftpDiVersion with 
the suite."):
> This allows the version to differ e.g. between Wheezy and Jessie.
> 
> Update production-config* to set TftpDiVersion_jessie instead of just
> TftpDiVersion, also add TftpDiVersion_wheezy using the version
> replaced in commit f610ea162836 "Switch to Debian 8.0 (jessie) as OS
> for test hosts".
> 
> In mfi-common we need to check for TftpDiVersion_$suite (_$guestsuite)
> and TftpDiVersion manually since getconfig In that context will not
> see any DebianSuite override in the environment.
> 
> This ensures that when a non-default suite is configured a
> corresponding useful version of DI is selected.

Acked-by: Ian Jackson 

provided the identifier `diversion' is changed (see my previous
mails).

Ian.

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

Re: [Xen-devel] [PATCH 0/2] libxl: FreeBSD fixes

[Roger Pau Monné]

El 12/01/16 a les 14.14, Roger Pau Monne ha escrit:
> Hello,
> 
> This series contains a couple of small fixes for FreeBSD. The first one is 
> regarding the newly introduced libxl__dm_runas_helper function and it's 
> usage of sysconf, while the second one fixes a long-stading bug that impacts 
> UUID usage on FreeBSD (and NetBSD AFAICT).
> 
> Thanks, Roger.

Hm, it seems like I haven't Cced any of the maintainers, doing it here
to reduce spam, sorry for the trouble.

Roger.


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

Re: [Xen-devel] [PATCH] x86/hvm: Allow the guest to permit the use of userspace hypercalls

[Jan Beulich]

>>> On 12.01.16 at 13:07,  wrote:
> On Mon, 11 Jan 2016, David Vrabel wrote:
>> On 11/01/16 17:17, Andrew Cooper wrote:
>> > So from one point of view, sufficient justification for this change is
>> > "because the Linux way isn't the only valid way to do this".
>> 
>> "Because we can" isn't a good justification for adding something new.
>> Particularly something that is trivially easy to (accidentally) misuse
>> and open a big security hole between userspace and kernel.
>> 
>> The vague idea for a userspace netfront that's floating around
>> internally is also not a good reason for pushing this feature at this time.
> 
> I agree with David, but I might have another good use case for this.
> 
> Consider the following scenario: we have a Xen HVM guest, with Xen
> installed inside of it (nested virtualization). I'll refer to Xen
> running on the host as L0 Xen and Xen running inside the VM as L1 Xen.
> Similarly we have two dom0 running, the one with access to the physical
> hardware, L0 Dom0, and the one running inside the VM, L1 Dom0.
> 
> Let's suppose that we want to lay the groundwork for L1 Dom0 to use PV
> frontend drivers, netfront and blkfront to speed up execution. In order
> to do that, the first thing it needs to do is making an hypercall to L0
> Xen. That's because netfront and blkfront needs to communicate with
> netback and blkback in L0 Dom0: event channels and grant tables are the
> ones provided by L0 Xen.

That's again a layering violation (bypassing the L1 hypervisor).

Jan


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

[Xen-devel] Backport of SeaBIOS changeset 3b8c53

[Roger Pau Monné]

Hello,

I would like to request the backport of the following SeaBIOS commit to
the master branch of the SeaBIOS repository used by Xen unstable (this
is AFAICT the only one that requires this build fix).

commit 3b8c5378dfe24ca8dfeabbcc435c7eb9e2d8d769
Author: Roger Pau Monne 
Date:   Mon Dec 28 13:50:41 2015 +0100

build: fix typo in buildversion.py

Fixes the following build error:

  Building ld scripts
Traceback (most recent call last):
  File "./scripts/buildversion.py", line 134, in 
main()
  File "./scripts/buildversion.py", line 114, in main
cleanbuild, toolstr = tool_versions(options.tools)
  File "./scripts/buildversion.py", line 90, in tool_versions
vers[isbinutils] = "mixed"
NameError: global name 'vers' is not defined
Makefile:160: recipe for target 'out/romlayout16.lds' failed

Signed-off-by: Roger Pau Monné 

Without this build fix it's not possible to build SeaBIOS on systems
with mixed toolstacks.

Thanks, Roger.

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

Re: [Xen-devel] [OSSTEST PATCH 3/7] Database locking: Tcl: Use db-execute

[Ian Jackson]

Ian Campbell writes ("Re: [OSSTEST PATCH 3/7] Database locking: Tcl: Use 
db-execute"):
> On Thu, 2016-01-07 at 19:38 +, Ian Jackson wrote:
> > Replace open-coded uses of pg_execute dbh STMT with
> > jobdb::db-execute-array STMT.
> 
> ITYM jobdb::db-execute?

Yes, fixed, thanks.

Ian.

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

Re: [Xen-devel] [PATCH 4.4 1/2] libxl: Rerun bison and flex

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH 4.4 1/2] libxl: Rerun bison and flex"):
> On Mon, 2016-01-04 at 14:50 +, Ian Jackson wrote:
> > We are going to want to cherry pick a change to the bison input, which
> > will involve rerunning bison.
> > 
> > So firstly, update the bison and flex output to that from current
> > Debian wheezy (i386; 1:2.5.dfsg-2.1 and 2.5.35-10.1 respectively).
> > 
> > There should be no functional change since there is no change to the
> > source file, but we will inherit bugfixes and behavioural changes from
> > the new version of bison.  So this is more a matter of hope than
> > knowledge.
> 
> This one isn't a cherry pick, but rather a manual rerun of the tools with a
> cargo-culted commit message from another such occasion, right?

Yes.

Ian.

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

Re: [Xen-devel] Unexpected error:

[Juergen Gross]

On 12/01/16 16:19, George Dunlap wrote:
> On 07/01/16 10:21, Wei Liu wrote:
>> CC George (who does the packaging for CentOS)
>>
>> BTW this problem is better directed to appropriate mailing list of
>> CentOS (centos-virt? I can't remember the exact name).
> 
> It would be centos-virt, but as it looks like an upstream bug, if Janis
> had reported this there, I probably would have asked him to re-report it
> here (or on xen-users).
> 
>> On Thu, Jan 07, 2016 at 10:53:00AM +0200, Jānis Andersons | Failiem.lv wrote:
>>> xen_major  : 4
>>> xen_minor  : 4
>>> xen_extra  : .3-3.el6
>>> CentOS release 6.7 (Final)
>>>
>>> After:
>>> xm usb-hc-create demo_win2012_r2 2 4
> 
> I'm actually a bit surprised this worked, as I didn't think the CentOS
> Virt SIG kernel had PVUSB support.  Which kernel are you using?
> 
> Chunyan / Juergen, what modules should he look for to see if he has
> pvusb backend support?

The classic kernel-xen flavor has "usbback", so do openSUSE and SLE
official releases.


Juergen

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

[Xen-devel] [PATCH] x86/HVM: prune error labels in do_hvm_op()

[Jan Beulich]

I've got repeatedly annoyed by the bad naming: Make them slightly
better recognizable (and less likely to get mixed up), except in cases
where they can be eliminated altogether.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -6523,29 +6523,29 @@ long do_hvm_op(unsigned long op, XEN_GUE
 
 rc = -EINVAL;
 if ( !is_hvm_domain(d) )
-goto param_fail2;
+goto tdv_fail;
 
 if ( a.nr > GB(1) >> PAGE_SHIFT )
-goto param_fail2;
+goto tdv_fail;
 
 rc = xsm_hvm_control(XSM_DM_PRIV, d, op);
 if ( rc )
-goto param_fail2;
+goto tdv_fail;
 
 rc = -ESRCH;
 if ( d->is_dying )
-goto param_fail2;
+goto tdv_fail;
 
 rc = -EINVAL;
 if ( d->vcpu == NULL || d->vcpu[0] == NULL )
-goto param_fail2;
+goto tdv_fail;
 
 if ( shadow_mode_enabled(d) )
 rc = shadow_track_dirty_vram(d, a.first_pfn, a.nr, a.dirty_bitmap);
 else
 rc = hap_track_dirty_vram(d, a.first_pfn, a.nr, a.dirty_bitmap);
 
-param_fail2:
+tdv_fail:
 rcu_unlock_domain(d);
 break;
 }
@@ -6564,21 +6564,21 @@ long do_hvm_op(unsigned long op, XEN_GUE
 
 rc = -EINVAL;
 if ( !is_hvm_domain(d) )
-goto param_fail3;
+goto modmem_fail;
 
 rc = xsm_hvm_control(XSM_DM_PRIV, d, op);
 if ( rc )
-goto param_fail3;
+goto modmem_fail;
 
 rc = -EINVAL;
 if ( a.nr < start_iter ||
  ((a.first_pfn + a.nr - 1) < a.first_pfn) ||
  ((a.first_pfn + a.nr - 1) > domain_get_maximum_gpfn(d)) )
-goto param_fail3;
+goto modmem_fail;
 
 rc = 0;
 if ( !paging_mode_log_dirty(d) )
-goto param_fail3;
+goto modmem_fail;
 
 while ( a.nr > start_iter )
 {
@@ -6604,7 +6604,7 @@ long do_hvm_op(unsigned long op, XEN_GUE
 }
 }
 
-param_fail3:
+modmem_fail:
 rcu_unlock_domain(d);
 break;
 }
@@ -6623,11 +6623,9 @@ long do_hvm_op(unsigned long op, XEN_GUE
 return -ESRCH;
 
 rc = xsm_hvm_param(XSM_TARGET, d, op);
-if ( rc )
-goto param_fail_getmemtype;
-
-rc = -EINVAL;
-if ( is_hvm_domain(d) )
+if ( unlikely(rc) )
+/* nothing */;
+else if ( likely(is_hvm_domain(d)) )
 {
 /* Use get_gfn query as we are interested in the current 
  * type, not in allocating or unsharing. That'll happen 
@@ -6647,10 +6645,12 @@ long do_hvm_op(unsigned long op, XEN_GUE
 a.mem_type =  HVMMEM_ram_rw;
 else
 a.mem_type =  HVMMEM_mmio_dm;
-rc = __copy_to_guest(arg, , 1) ? -EFAULT : 0;
+if ( __copy_to_guest(arg, , 1) )
+rc = -EFAULT;
 }
+else
+rc = -EINVAL;
 
-param_fail_getmemtype:
 rcu_unlock_domain(d);
 break;
 }
@@ -6677,20 +6677,20 @@ long do_hvm_op(unsigned long op, XEN_GUE
 
 rc = -EINVAL;
 if ( !is_hvm_domain(d) )
-goto param_fail4;
+goto setmemtype_fail;
 
 rc = xsm_hvm_control(XSM_DM_PRIV, d, op);
 if ( rc )
-goto param_fail4;
+goto setmemtype_fail;
 
 rc = -EINVAL;
 if ( a.nr < start_iter ||
  ((a.first_pfn + a.nr - 1) < a.first_pfn) ||
  ((a.first_pfn + a.nr - 1) > domain_get_maximum_gpfn(d)) )
-goto param_fail4;
+goto setmemtype_fail;
 
 if ( a.hvmmem_type >= ARRAY_SIZE(memtype) )
-goto param_fail4;
+goto setmemtype_fail;
 
 while ( a.nr > start_iter )
 {
@@ -6703,39 +6703,39 @@ long do_hvm_op(unsigned long op, XEN_GUE
 put_gfn(d, pfn);
 p2m_mem_paging_populate(d, pfn);
 rc = -EAGAIN;
-goto param_fail4;
+goto setmemtype_fail;
 }
 if ( p2m_is_shared(t) )
 {
 put_gfn(d, pfn);
 rc = -EAGAIN;
-goto param_fail4;
+goto setmemtype_fail;
 }
 if ( !p2m_is_ram(t) &&
  (!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm) &&
  (t != p2m_mmio_write_dm || a.hvmmem_type != HVMMEM_ram_rw) )
 {
 put_gfn(d, pfn);
-goto param_fail4;
+goto setmemtype_fail;
 }
 
 rc = p2m_change_type_one(d, pfn, t, memtype[a.hvmmem_type]);
 put_gfn(d, pfn);
 if ( rc )
-goto param_fail4;
+goto setmemtype_fail;
 
 /* Check for continuation if it's not the last interation */
   

[Xen-devel] [qemu-upstream-4.4-testing test] 77834: tolerable FAIL - PUSHED

[osstest service owner]

flight 77834 qemu-upstream-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77834/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 62580
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 62702

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu2264b0c66075cc34c252a1386f019f8be6240890
baseline version:
 qemuu5fe74249f5ab528fe84a26fa60438a6de4c787f0

Last test of basis62702  2015-10-06 15:32:13 Z   98 days
Testing same since66539  2015-12-18 16:12:10 Z   24 days   13 attempts


People who touched revisions under test:
  Stefano Stabellini 

jobs:
 build-amd64-xend pass
 build-i386-xend  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  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-amd64-qemuu-nested-intel  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-amd64-amd64-pv  pass
 test-amd64-i386-pv   pass
 test-amd64-amd64-amd64-pvgrubpass
 test-amd64-amd64-i386-pvgrub pass
 test-amd64-amd64-pygrub  pass
 test-amd64-amd64-xl-qcow2pass
 test-amd64-i386-xl-raw   pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-libvirt-vhd pass
 test-amd64-amd64-xl-qemuu-winxpsp3   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=qemu-upstream-4.4-testing
+ revision=2264b0c66075cc34c252a1386f019f8be6240890
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;

Re: [Xen-devel] [OSSTEST PATCH 5/7] Database locking: Tcl: for errorCode, use pg_exec, not pg_execute

[Ian Jackson]

Ian Campbell writes ("Re: [OSSTEST PATCH 5/7] Database locking: Tcl: for 
errorCode, use pg_exec, not pg_execute"):
> On Thu, 2016-01-07 at 19:38 +, Ian Jackson wrote:
> > A wrinkle is that as a result it is no longer possible to use
> > db-execute on a SELECT statement nor db-execute-array on a non-SELECT
> > statement.  This is because the 1. the `ok' status that we have to

(fixed the typos, thanks)

> > of the statement handle (-cmdTuples vs -numTuples).  But all uses in
> > the codebase are now fine for this distinction.
> 
> Does this imply that db-execute-array could be renamed db-execute-select,
> or even just db-select?

Yes, indeed.  Do you think I should ?

Ian.

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

Re: [Xen-devel] [PATCH] tools: make flask utils build unconditional

[Wei Liu]

On Mon, Jan 11, 2016 at 11:10:35AM -0600, Doug Goldstein wrote:
> On 1/11/16 9:19 AM, Wei Liu wrote:
> > On Fri, Jan 08, 2016 at 12:49:07PM -0600, Doug Goldstein wrote:
> > [...]
> >> Ok so I'm at a loss what steps I need to take. I've submitted patches to
> >> put the config in /boot so that this check can be made but there's a
> >> disagreement if that's even necessary or not.
> >>
> > 
> > That's a bit unfortunate. :-(
> > 
> > But if I'm not mistaken that's orthogonal to this problem, right? That's
> > one more step down the road regarding grub integration.
> > 
> >> Do I need to supply a patch to make --disable-xsmpolicy the default so
> >> that this change doesn't generate the policy by default? The point of
> >> this patch is to compile the necessarily bits always which will help
> >> shake out bugs earlier. If we don't want the policy file to be installed
> >> then we should use the proper setting for that and not the fact that the
> >> utility isn't being compiled.
> >>
> > 
> > I think one solution would be to modify flask/Makefile to guard policy
> > compilation against (FLASK_ENABLE && FLASK_POLICY).
> > 
> > What do you think? Admittedly I haven't followed closely all the KConfig
> > work so I might be talking nonsense.
> > 
> > Ian and Ian?
> > 
> > Wei.
> 
> Wei (and Ian and Ian and Daniel),
> 
> There's already a guard against compiling the policy in the tools/
> directory's configure script called --{enable,disable}-xsmpolicy What I
> could do is disable it by default because it is currently enabled by
> default.
> 
> I honestly think that would be an improvement because we would compile
> all the source code (causing us to shake bugs out earlier) but only
> generate the policy when the user explicitly requests it. Right now the
> policy is made whenever the utilities are compiled.
> 
> Let me know if that sounds appealing to you.
> 

Fine by me.

I don't really have a strong opinion at this point. My original concern
that the installed xenpolicy file interferes with grub was based on the
assumption that we only had version numbers as indicator to match
hypervisor binary and xenpolicy file. But now since I think there is
better way to generate grub entry I don't think my objection based on
the (bad) assumption to this patch is relevant anymore.

Wei.

> Thanks.
> -- 
> Doug Goldstein
> 



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

[Xen-devel] [ovmf test] 77886: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 65543
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 65543

version targeted for testing:
 ovmf ef422fc53c4bc978767fcee35b284f61c02ea6d5
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z   35 days
Failing since 65593  2015-12-08 23:44:51 Z   34 days   21 attempts
Testing same since77886  2016-01-12 09:02:22 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Yao, Jiewen" 
  Andrew Fish 
  Ard Biesheuvel 
  Cecil Sheng 
  Chao Zhang 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  Eric Dong 
  Eric Dong 
  Eugene Cohen 
  Feng Tian 
  Fu Siyuan 
  Hao Wu 
  Hess Chen 
  Heyi Guo 
  Jaben Carsey 
  Jeff Fan 
  Jiaxin Wu 
  Jim Dailey 
  Jordan Justen 
  Larry Hauch 
  Laszlo Ersek 
  Leekha Shaveta 
  Liming Gao 
  Mark Rutland 
  Michael Kinney 
  Michael Thomas 
  Paulo Alcantara 
  Qin Long 
  Qiu Shumin 
  Ruiyu Ni 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Star Zeng 
  Tapan Shah 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zhang Lubo 

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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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

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

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

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


Not pushing.

(No revision log; it would be 4925 lines long.)

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   like 77684

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

version targeted for testing:
 libvirt  545e5571f9bafc61c65b563ca69907f8cc935f72
baseline version:
 libvirt  03569fda63d6dd8cb5cd63c34eb23faf5193da74

Last test of basis77684  2016-01-10 01:57:02 Z2 days
Failing since 77788  2016-01-11 03:22:23 Z1 days2 attempts
Testing same since77871  2016-01-12 01:15:10 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Cole Robinson 
  Jasper Lievisse Adriaanse 
  John Ferlan 
  Laine Stump 
  Martin Kletzander 
  Michal Privoznik 
  Roman Bogorodskiy 

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 fail



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=545e5571f9bafc61c65b563ca69907f8cc935f72
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local 

[Xen-devel] [linux-3.16 baseline-only test] 38623: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-multivcpu  6 xen-boot fail REGR. vs. 38589
 test-amd64-amd64-xl-qemuu-win7-amd64  6 xen-boot  fail REGR. vs. 38589

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rumpuserxen-i386 10 guest-startfail like 38589
 test-amd64-amd64-xl-credit2  17 guest-localmigrate/x10   fail   like 38589
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   like 38589
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 38589

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

version targeted for testing:
 linuxc5305f04d7b78f16586a5fbce2690c57a855f5cf
baseline version:
 linux70a95b3e395fa9f5a5cf531c56ae7e5b6ed37e32

Last test of basis38589  2016-01-04 10:01:47 Z8 days
Testing same since38623  2016-01-12 07:36:39 Z0 days1 attempts


People who touched revisions under test:
  Aaro Koskinen 
  Al Viro 
  Aleksander Morgado 
  Alex Deucher 
  Andrew Cooper 
  Andrew Honig 
  Andrew Lunn 
  Andrew Morton 
  Andy Honig 
  Antonio Quartulli 
  Antonio Quartulli 
  Arnd Bergmann 
  Bart Van Assche 
  Ben Hutchings 
  Ben McCauley 
  Benjamin Coddington 
  Bjørn Mork 
  Boris Ostrovsky 
  Bruce Ford 
  Catalin Marinas 
  Charles Keepax 
  Chris Mason 
  Chris Wilson 
  Christoffer Dall 
  Christoph Biedl 
  Clemens Ladisch 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 60684
 build-amd64   5 xen-build fail REGR. vs. 60684

Tests which did not succeed, but are not blocking:
 build-amd64-rumpuserxen   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3  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

version targeted for testing:
 linux682515645995af4112ba0bd52a4ec62279d68973
baseline version:
 linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0

Last test of basis60684  2015-08-13 04:21:46 Z  152 days
Failing since 60712  2015-08-15 18:33:48 Z  150 days  100 attempts
Testing same since77867  2016-01-12 00:06:19 Z0 days1 attempts

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

[Xen-devel] [qemu-upstream-4.5-testing test] 77858: tolerable FAIL - PUSHED

[osstest service owner]

flight 77858 qemu-upstream-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77858/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail in 77752 pass in 
77858
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail in 77752 pass 
in 77858
 test-armhf-armhf-xl-rtds  9 debian-install fail in 77752 pass in 77858
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail pass 
in 77752

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 9 debian-hvm-install fail in 77752 
baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 77752 
like 62321
 test-amd64-amd64-xl-rtds  6 xen-boot  fail in 77752 like 62414
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail in 77752 like 62414
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10  fail like 62321
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 62414

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

version targeted for testing:
 qemuu32bba3499008c847e08858f310d65806e0bade36
baseline version:
 qemuue5a1bb22cfb307db909dbd3404c48e5bbeb9e66d

Last test of basis62414  2015-09-26 20:34:49 Z  108 days
Testing same since66534  2015-12-18 15:48:15 Z   25 days   12 attempts


People who touched revisions under test:
  Stefano Stabellini 

jobs:
 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-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 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 pass
 test-amd64-i386-xl-qemuu-win7-amd64  

Re: [Xen-devel] [PATCH v3 01/41] lcoking/barriers, arch: Use smp barriers in smp_store_release()

[Michael S. Tsirkin]

On Tue, Jan 12, 2016 at 08:28:44AM -0800, Paul E. McKenney wrote:
> On Sun, Jan 10, 2016 at 04:16:32PM +0200, Michael S. Tsirkin wrote:
> > From: Davidlohr Bueso 
> > 
> > With commit b92b8b35a2e ("locking/arch: Rename set_mb() to smp_store_mb()")
> > it was made clear that the context of this call (and thus set_mb)
> > is strictly for CPU ordering, as opposed to IO. As such all archs
> > should use the smp variant of mb(), respecting the semantics and
> > saving a mandatory barrier on UP.
> > 
> > Signed-off-by: Davidlohr Bueso 
> > Signed-off-by: Peter Zijlstra (Intel) 
> > Cc: 
> > Cc: Andrew Morton 
> > Cc: Benjamin Herrenschmidt 
> > Cc: Heiko Carstens 
> > Cc: Linus Torvalds 
> > Cc: Paul E. McKenney 
> > Cc: Peter Zijlstra 
> > Cc: Thomas Gleixner 
> > Cc: Tony Luck 
> > Cc: d...@stgolabs.net
> > Link: 
> > http://lkml.kernel.org/r/1445975631-17047-3-git-send-email-d...@stgolabs.net
> > Signed-off-by: Ingo Molnar 
> 
> Aside from a need for s/lcoking/locking/ in the subject line:
> 
> Reviewed-by: Paul E. McKenney 

Thanks!
Though Ingo already put this in tip tree like this,
and I need a copy in my tree to avoid breaking bisect,
so I will probably keep it exactly the same to avoid confusion.

> > ---
> >  arch/ia64/include/asm/barrier.h| 2 +-
> >  arch/powerpc/include/asm/barrier.h | 2 +-
> >  arch/s390/include/asm/barrier.h| 2 +-
> >  include/asm-generic/barrier.h  | 2 +-
> >  4 files changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/arch/ia64/include/asm/barrier.h 
> > b/arch/ia64/include/asm/barrier.h
> > index df896a1..209c4b8 100644
> > --- a/arch/ia64/include/asm/barrier.h
> > +++ b/arch/ia64/include/asm/barrier.h
> > @@ -77,7 +77,7 @@ do {  
> > \
> > ___p1;  \
> >  })
> > 
> > -#define smp_store_mb(var, value)   do { WRITE_ONCE(var, value); mb(); } 
> > while (0)
> > +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); } 
> > while (0)
> > 
> >  /*
> >   * The group barrier in front of the rsm & ssm are necessary to ensure
> > diff --git a/arch/powerpc/include/asm/barrier.h 
> > b/arch/powerpc/include/asm/barrier.h
> > index 0eca6ef..a7af5fb 100644
> > --- a/arch/powerpc/include/asm/barrier.h
> > +++ b/arch/powerpc/include/asm/barrier.h
> > @@ -34,7 +34,7 @@
> >  #define rmb()  __asm__ __volatile__ ("sync" : : : "memory")
> >  #define wmb()  __asm__ __volatile__ ("sync" : : : "memory")
> > 
> > -#define smp_store_mb(var, value)   do { WRITE_ONCE(var, value); mb(); } 
> > while (0)
> > +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); } 
> > while (0)
> > 
> >  #ifdef __SUBARCH_HAS_LWSYNC
> >  #define SMPWMB  LWSYNC
> > diff --git a/arch/s390/include/asm/barrier.h 
> > b/arch/s390/include/asm/barrier.h
> > index d68e11e..7ffd0b1 100644
> > --- a/arch/s390/include/asm/barrier.h
> > +++ b/arch/s390/include/asm/barrier.h
> > @@ -36,7 +36,7 @@
> >  #define smp_mb__before_atomic()smp_mb()
> >  #define smp_mb__after_atomic() smp_mb()
> > 
> > -#define smp_store_mb(var, value)   do { WRITE_ONCE(var, value); 
> > mb(); } while (0)
> > +#define smp_store_mb(var, value)   do { WRITE_ONCE(var, value); smp_mb(); 
> > } while (0)
> > 
> >  #define smp_store_release(p, v)
> > \
> >  do {   
> > \
> > diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h
> > index b42afad..0f45f93 100644
> > --- a/include/asm-generic/barrier.h
> > +++ b/include/asm-generic/barrier.h
> > @@ -93,7 +93,7 @@
> >  #endif /* CONFIG_SMP */
> > 
> >  #ifndef smp_store_mb
> > -#define smp_store_mb(var, value)  do { WRITE_ONCE(var, value); mb(); } 
> > while (0)
> > +#define smp_store_mb(var, value)  do { WRITE_ONCE(var, value); smp_mb(); } 
> > while (0)
> >  #endif
> > 
> >  #ifndef smp_mb__before_atomic
> > -- 
> > MST
> > 

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

[Xen-devel] [qemu-upstream-4.2-testing test] 77910: regressions - FAIL

[osstest service owner]

flight 77910 qemu-upstream-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77910/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3865 xen-build fail REGR. vs. 62044
 build-amd64   5 xen-build fail REGR. vs. 62044

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 build-check(1)  blocked n/a

version targeted for testing:
 qemuu5081fc1c773d2a83ec7a867f030323b8b6956cd1
baseline version:
 qemuuc17e602ae64fb24405ebd256679ba9a6f5819086

Last test of basis62044  2015-09-15 15:06:42 Z  119 days
Testing same since66542  2015-12-18 16:37:10 Z   25 days   18 attempts


People who touched revisions under test:
  Stefano Stabellini 

jobs:
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 blocked 
 test-amd64-i386-xend-qemuu-winxpsp3  blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3   blocked 
 test-i386-i386-xl-qemuu-winxpsp3 blocked 



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

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

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

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


Not pushing.


commit 5081fc1c773d2a83ec7a867f030323b8b6956cd1
Author: Stefano Stabellini 
Date:   Fri Dec 18 15:45:14 2015 +

xenfb: avoid reading twice the same fields from the shared page

Reading twice the same field could give the guest an attack of
opportunity. In the case of event->type, gcc could compile the switch
statement into a jump table, effectively ending up reading the type
field multiple times.

This is part of XSA-155.

Signed-off-by: Stefano Stabellini 

commit 74fab2ef4c0ba42af477e9e445c9883cc45cf9e6
Author: Stefano Stabellini 
Date:   Fri Dec 18 15:44:58 2015 +

xen/blkif: Avoid double access to src->nr_segments

src is stored in shared memory and src->nr_segments is dereferenced
twice at the end of the function.  If a compiler decides to compile this
into two separate memory accesses then the size limitation could be
bypassed.

Fix it by removing the double 

[Xen-devel] [distros-debian-snapshot test] 38624: regressions - FAIL

[Platform Team regression test user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-i386-weekly-netinst-pygrub 9 debian-di-install fail REGR. vs. 
38592
 test-amd64-i386-amd64-weekly-netinst-pygrub 9 debian-di-install fail REGR. vs. 
38592

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-armhf-daily-netboot-pygrub 9 debian-di-install fail like 38592
 test-amd64-amd64-i386-daily-netboot-pygrub 9 debian-di-install fail like 38592
 test-amd64-i386-amd64-daily-netboot-pygrub 9 debian-di-install fail like 38592
 test-amd64-i386-i386-daily-netboot-pvgrub  9 debian-di-install fail like 38592
 test-amd64-amd64-amd64-daily-netboot-pvgrub 9 debian-di-install fail like 38592
 test-amd64-amd64-i386-weekly-netinst-pygrub 9 debian-di-install fail like 38592
 test-amd64-amd64-amd64-weekly-netinst-pygrub 9 debian-di-install fail like 
38592

baseline version:
 flight   38592

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubfail
 test-amd64-i386-amd64-daily-netboot-pygrub   fail
 test-armhf-armhf-armhf-daily-netboot-pygrub  fail
 test-amd64-amd64-i386-daily-netboot-pygrub   fail
 test-amd64-amd64-amd64-current-netinst-pygrubpass
 test-amd64-i386-amd64-current-netinst-pygrub pass
 test-amd64-amd64-i386-current-netinst-pygrub pass
 test-amd64-i386-i386-current-netinst-pygrub  pass
 test-amd64-amd64-amd64-weekly-netinst-pygrub fail
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  fail
 test-amd64-i386-i386-weekly-netinst-pygrub   fail



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

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

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


Push not applicable.


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

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

[Leonid Yegoshin]

On 01/12/2016 01:40 PM, Peter Zijlstra wrote:



It is selectable only for MIPS R2 but not MIPS R6. The reason is - most of
MIPS R2 CPUs have short pipeline and that SYNC is just waste of CPU
resource, especially taking into account that "lightweight syncs" are
converted to a heavy "SYNC 0" in many of that CPUs. However the latest
MIPS/Imagination CPU have a pipeline long enough to hit a problem - absence
of SYNC at LL/SC inside atomics, barriers etc.

What ?! Are you saying that because R2 has short pipelines its unlikely
to hit the reordering issues and we can omit barriers?


It was my guess to explain - why barriers was not included originally. 
You can check with Ralf, he knows more about that time MIPS Linux code.


I bother with this more than 2 years and I just try to solve that issue 
- in recent CPUs the load after LL/SC synchronization instruction loop 
can get ahead of SC for sure, it was tested.





And reading the MIPS64 v6.04 instruction set manual, I think 0x11/0x12
are_NOT_  transitive and therefore cannot be used to implement the
smp_mb__{before,after} stuff.

That is, in MIPS speak, those SYNC types are Ordering Barriers, not
Completion Barriers.

Please see above, point 2.

That did not in fact enlighten things. Are they transitive/multi-copy
atomic or not?


Peter Zijlstra recently wrote: "In particular we're very much all 
'confused' about the various notions of transitivity". I am actually 
confused too and need some examples here.




(and here Will will go into great detail on the differences between the
two and make our collective brains explode :-)


That is, currently all architectures -- with exception of PPC -- have
RCsc locks, but using these non-transitive things will get you RCpc
locks.

So yes, MIPS can go RCpc for its locks and share the burden of pain with
PPC, but that needs to be a very concious decision.

I don't understand that - I tried hard but I can't find any word like
"RCsc", "RCpc" in Documents/ directory. Web search goes nowhere, of course.

From: lkml.kernel.org/r/20150828153921.gf19...@twins.programming.kicks-ass.net

Yes, the difference between RCpc and RCsc is in the meaning of RELEASE +
ACQUIRE. With RCsc that implies a full memory barrier, with RCpc it does
not.


MIPS Arch starting from R2 requires that. If some CPU can't, it should 
execute a full "SYNC 0" instead, which is a full memory barrier.




Currently PowerPC is the only arch that (can, and) does RCpc and gives a
weaker RELEASE + ACQUIRE. Only the CPU who did the ACQUIRE is guaranteed
to see the stores of the CPU which did the RELEASE in order.


Yes, it was a goal for SYNC_ACQUIRE and SYNC_RELEASE.

Caveats:

- "Full memory barrier" on MIPS means - full barrier for any device 
in coherent domain. In MIPS Tech/Imagination Tech MIPS-based CPU it is 
"for any device connected to CM or IOCU + directly connected memory".


- It is not applied to instruction fetch. However, I-Cache flushes 
and SYNCI are consistent with that. There is also hazard barrier 
instructions to clear CPU pipeline to some extent - to help with this 
limitation.


I don't think that these caveats prevent a correct Acquire/Release semantic.

- Leonid.



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

Re: [Xen-devel] [Qemu-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()

[Hao, Xudong]

"can't boot up" means guest doesn't boot at all, guest will stop to booting 
after adding vga device, detail log in attachment.

Thanks,
-Xudong


> -Original Message-
> From: qemu-devel-bounces+xudong.hao=intel@nongnu.org [mailto:qemu-
> devel-bounces+xudong.hao=intel@nongnu.org] On Behalf Of Gerd
> Hoffmann
> Sent: Tuesday, January 12, 2016 6:25 PM
> To: Hao, Xudong 
> Cc: Lars Kurth ; xen-de...@lists.xensource.com; Stefano
> Stabellini ; Lars Kurth
> ; Michael S. Tsirkin ; qemu-
> de...@nongnu.org; Cao jin ; Stefano Stabellini
> 
> Subject: Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX:
> convert to realize()
> 
> On Di, 2016-01-12 at 09:50 +, Hao, Xudong wrote:
> > With latest qemu 7b8a354d4716, RHEL7.2 (with default kernel) VM still can't
> boot up with IGD.
> 
> There is another bug, using pci_default_write_config() doesn't fly as this 
> checks
> writes against wmask and the registers in question are not whitelisted ...
> 
> I've just rebased my igd patch series which (among other stuff) fixes that 
> bug:
>   https://www.kraxel.org/cgit/qemu/log/?h=work/igd
>   git://git.kraxel.org/qemu work/igd
> 
> Can you give it a spin?
> 
> Also: what does "can't boot up" mean exactly?  Guest doesn't boot at all?  
> Guest
> boots, but igd/console/Xorg doesn't work?  In case of the
> latter:  Any chance to login via network and get a kernel log?
> 
> thanks,
>   Gerd
> 



rhel7-default-kernel-boot.log
Description: rhel7-default-kernel-boot.log
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v4 1/2] memory-hotplug: add automatic onlining policy for the newly added memory

[Vitaly Kuznetsov]

Currently, all newly added memory blocks remain in 'offline' state unless
someone onlines them, some linux distributions carry special udev rules
like:

SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline", ATTR{state}="online"

to make this happen automatically. This is not a great solution for virtual
machines where memory hotplug is being used to address high memory pressure
situations as such onlining is slow and a userspace process doing this
(udev) has a chance of being killed by the OOM killer as it will probably
require to allocate some memory.

Introduce default policy for the newly added memory blocks in
/sys/devices/system/memory/auto_online_blocks file with two possible
values: "offline" which preserves the current behavior and "online" which
causes all newly added memory blocks to go online as soon as they're added.
The default is "offline".

Signed-off-by: Vitaly Kuznetsov 
---
 Documentation/memory-hotplug.txt | 19 +++
 drivers/base/memory.c| 40 
 drivers/xen/balloon.c|  2 +-
 include/linux/memory.h   |  3 ++-
 include/linux/memory_hotplug.h   |  4 +++-
 mm/memory_hotplug.c  | 18 +++---
 6 files changed, 72 insertions(+), 14 deletions(-)

diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt
index ce2cfcf..ceaf40c 100644
--- a/Documentation/memory-hotplug.txt
+++ b/Documentation/memory-hotplug.txt
@@ -254,12 +254,23 @@ If the memory block is online, you'll read "online".
 If the memory block is offline, you'll read "offline".
 
 
-5.2. How to online memory
+5.2. Memory onlining
 
-Even if the memory is hot-added, it is not at ready-to-use state.
-For using newly added memory, you have to "online" the memory block.
+When the memory is hot-added, the kernel decides whether or not to "online"
+it according to the policy which can be read from "auto_online_blocks" file:
 
-For onlining, you have to write "online" to the memory block's state file as:
+% cat /sys/devices/system/memory/auto_online_blocks
+
+The default is "offline" which means the newly added memory is not in a
+ready-to-use state and you have to "online" the newly added memory blocks
+manually. Automatic onlining can be requested by writing "online" to
+"auto_online_blocks" file:
+
+% echo online > /sys/devices/system/memory/auto_online_blocks
+
+If the automatic onlining wasn't requested or some memory block was offlined
+it is possible to change the individual block's state by writing to the "state"
+file:
 
 % echo online > /sys/devices/system/memory/memoryXXX/state
 
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 25425d3..7008edc 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -439,6 +439,37 @@ print_block_size(struct device *dev, struct 
device_attribute *attr,
 static DEVICE_ATTR(block_size_bytes, 0444, print_block_size, NULL);
 
 /*
+ * Memory auto online policy.
+ */
+
+static ssize_t
+show_auto_online_blocks(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   if (memhp_auto_online)
+   return sprintf(buf, "online\n");
+   else
+   return sprintf(buf, "offline\n");
+}
+
+static ssize_t
+store_auto_online_blocks(struct device *dev, struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   if (sysfs_streq(buf, "online"))
+   memhp_auto_online = true;
+   else if (sysfs_streq(buf, "offline"))
+   memhp_auto_online = false;
+   else
+   return -EINVAL;
+
+   return count;
+}
+
+static DEVICE_ATTR(auto_online_blocks, 0644, show_auto_online_blocks,
+  store_auto_online_blocks);
+
+/*
  * Some architectures will have custom drivers to do this, and
  * will not need to do it from userspace.  The fake hot-add code
  * as well as ppc64 will do all of their discovery in userspace
@@ -654,10 +685,10 @@ static int add_memory_block(int base_section_nr)
 
 
 /*
- * need an interface for the VM to add new memory regions,
- * but without onlining it.
+ * add new memory regions keeping their state.
  */
-int register_new_memory(int nid, struct mem_section *section)
+int register_new_memory(int nid, struct mem_section *section,
+   unsigned long state)
 {
int ret = 0;
struct memory_block *mem;
@@ -669,7 +700,7 @@ int register_new_memory(int nid, struct mem_section 
*section)
mem->section_count++;
put_device(>dev);
} else {
-   ret = init_memory_block(, section, MEM_OFFLINE);
+   ret = init_memory_block(, section, state);
if (ret)
goto out;
}
@@ -737,6 +768,7 @@ static struct attribute *memory_root_attrs[] = {
 #endif
 
_attr_block_size_bytes.attr,
+   _attr_auto_online_blocks.attr,
NULL
 };
 

[Xen-devel] [PATCH v4 0/2] memory-hotplug: add automatic onlining policy for the newly added memory

[Vitaly Kuznetsov]

Changes since v3:
- Add support for the policy to Xen balloon driver [Daniel Kiper, David Vrabel]
- I found an issue with PATCH v3: when memory auto onlining was requested we
  do nothing to memblocks states so in sysfs they stay 'offline' (while in
  reality they're online). Modify register_new_memory() (and its only caller,
  __add_section()) to create memblocks in the proper state.

Original description:

Currently, all newly added memory blocks remain in 'offline' state unless
someone onlines them, some linux distributions carry special udev rules
like:

SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline", ATTR{state}="online"

to make this happen automatically. This is not a great solution for virtual
machines where memory hotplug is being used to address high memory pressure
situations as such onlining is slow and a userspace process doing this
(udev) has a chance of being killed by the OOM killer as it will probably
require to allocate some memory.

Introduce default policy for the newly added memory blocks in
/sys/devices/system/memory/auto_online_blocks file with two possible
values: "offline" which preserves the current behavior and "online" which
causes all newly added memory blocks to go online as soon as they're added.
The default is "offline".

Vitaly Kuznetsov (2):
  memory-hotplug: add automatic onlining policy for the newly added
memory
  xen_balloon: support memory auto onlining policy

 Documentation/memory-hotplug.txt | 19 +++
 drivers/base/memory.c| 40 
 drivers/xen/Kconfig  | 20 +---
 drivers/xen/balloon.c| 30 +++---
 include/linux/memory.h   |  3 ++-
 include/linux/memory_hotplug.h   |  4 +++-
 mm/memory_hotplug.c  | 18 +++---
 7 files changed, 103 insertions(+), 31 deletions(-)

-- 
2.5.0


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

[Xen-devel] [PATCH v4 2/2] xen_balloon: support memory auto onlining policy

[Vitaly Kuznetsov]

Add support for the newly added kernel memory auto onlining policy to Xen
ballon driver.

Suggested-by: Daniel Kiper 
Signed-off-by: Vitaly Kuznetsov 
---
 drivers/xen/Kconfig   | 20 +---
 drivers/xen/balloon.c | 30 +++---
 2 files changed, 32 insertions(+), 18 deletions(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 73708ac..098ab49 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -37,23 +37,29 @@ config XEN_BALLOON_MEMORY_HOTPLUG
 
  Memory could be hotplugged in following steps:
 
-   1) dom0: xl mem-max  
+   1) domU: ensure that memory auto online policy is in effect by
+  checking /sys/devices/system/memory/auto_online_blocks file
+  (should be 'online').
+
+   2) dom0: xl mem-max  
   where  is >= requested memory size,
 
-   2) dom0: xl mem-set  
+   3) dom0: xl mem-set  
   where  is requested memory size; alternatively memory
   could be added by writing proper value to
   /sys/devices/system/xen_memory/xen_memory0/target or
   /sys/devices/system/xen_memory/xen_memory0/target_kb on dumU,
 
-   3) domU: for i in /sys/devices/system/memory/memory*/state; do \
-  [ "`cat "$i"`" = offline ] && echo online > "$i"; done
+ Alternatively, if memory auto onlining was not requested at step 1
+ the newly added memory can be manually onlined in domU by doing the
+ following:
 
- Memory could be onlined automatically on domU by adding following 
line to udev rules:
+   for i in /sys/devices/system/memory/memory*/state; do \
+ [ "`cat "$i"`" = offline ] && echo online > "$i"; done
 
- SUBSYSTEM=="memory", ACTION=="add", RUN+="/bin/sh -c '[ -f 
/sys$devpath/state ] && echo online > /sys$devpath/state'"
+ or by adding the following line to udev rules:
 
- In that case step 3 should be omitted.
+ SUBSYSTEM=="memory", ACTION=="add", RUN+="/bin/sh -c '[ -f 
/sys$devpath/state ] && echo online > /sys$devpath/state'"
 
 config XEN_BALLOON_MEMORY_HOTPLUG_LIMIT
int "Hotplugged memory limit (in GiB) for a PV guest"
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 890c3b5..68f0aa2 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -284,7 +284,7 @@ static void release_memory_resource(struct resource 
*resource)
kfree(resource);
 }
 
-static enum bp_state reserve_additional_memory(void)
+static enum bp_state reserve_additional_memory(bool online)
 {
long credit;
struct resource *resource;
@@ -338,7 +338,18 @@ static enum bp_state reserve_additional_memory(void)
}
 #endif
 
-   rc = add_memory_resource(nid, resource, false);
+   /*
+* add_memory_resource() will call online_pages() which in its turn
+* will call xen_online_page() callback causing deadlock if we don't
+* release balloon_mutex here. It is safe because there can only be
+* one balloon_process() running at a time and balloon_mutex is
+* internal to Xen driver, generic memory hotplug code doesn't mess
+* with it.
+*/
+   mutex_unlock(_mutex);
+   rc = add_memory_resource(nid, resource, online);
+   mutex_lock(_mutex);
+
if (rc) {
pr_warn("Cannot add additional memory (%i)\n", rc);
goto err;
@@ -562,14 +573,11 @@ static void balloon_process(struct work_struct *work)
 
credit = current_credit();
 
-   if (credit > 0) {
-   if (balloon_is_inflated())
-   state = increase_reservation(credit);
-   else
-   state = reserve_additional_memory();
-   }
-
-   if (credit < 0)
+   if (credit > 0 && balloon_is_inflated())
+   state = increase_reservation(credit);
+   else if (credit > 0)
+   state = reserve_additional_memory(memhp_auto_online);
+   else if (credit < 0)
state = decrease_reservation(-credit, GFP_BALLOON);
 
state = update_schedule(state);
@@ -599,7 +607,7 @@ static int add_ballooned_pages(int nr_pages)
enum bp_state st;
 
if (xen_hotplug_unpopulated) {
-   st = reserve_additional_memory();
+   st = reserve_additional_memory(false);
if (st != BP_ECANCELED) {
mutex_unlock(_mutex);
wait_event(balloon_wq,
-- 
2.5.0


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

Re: [Xen-devel] [PATCH v3 2/3] XENVER_build_id: Provide ld-embedded build-ids (v8)

[Jan Beulich]

>>> On 12.01.16 at 17:43,  wrote:
> On Tue, Jan 12, 2016 at 09:25:27AM -0700, Jan Beulich wrote:
>> >>> On 08.01.16 at 03:25,  wrote:
>> > The mechanism to get this is via the XENVER hypercall and
>> > we add a new sub-command to retrieve the binary build-id
>> > called XENVER_build_id. The sub-hypercall parameter
>> > allows an arbitrary size (the buffer and len is provided
>> > to the hypervisor). A NULL parameter will probe the hypervisor
>> > for the length of the build-id.
>> > 
>> > One can also retrieve the value of the build-id by doing
>> > 'readelf -h xen-syms'.
>> 
>> Does this or something similar also work on xen.gz and xen.efi?
> 
> Sadly no.
>> I ask because xen-syms isn't present on the boot partition, and
>> may not be present anywhere on an otherwise functioning
>> system.
> 
> Right. Some later patches (xsplice related) hook the build-id printing
> to a keyboard handler. Would that work ?

Key handlers are strictly a debugging facility.

> Or are you suggesting that perhaps the kernel should at boot time
> print the build-id (like it does the changset)?

Perhaps, albeit to me that's a bit orthogonal to being able to find out
the build ID for a given binary.

>> > +if ( rc )
>> > +return rc;
>> > +
>> > +if ( guest_handle_is_null(arg) )
>> > +return sz;
>> > +
>> > +if ( sz > build_id.len )
>> > +return -ENOBUFS;
>> 
>> And how will the caller know how much is needed?
> 
> Duh. I shall update the build_id.len with the appropiate value.

Ah, actually I now see you have Andrew's beloved NULL handle
check up a few lines - that may suffice. Albeit I'm not generally in
favor of this model; I prefer a first attempt to succeed if possible,
and a second one only to be needed if the caller estimated size in
fact didn't suffice (and then no 3rd one being necessary in order
to obtain the needed size).

>> > +if ( copy_to_guest_offset(arg, offsetof(xen_build_id_t, buf), p, 
>> > sz) )
>> > +return -EFAULT;
>> > +
>> > +return sz;
>> > +}
>> 
>> Or how much got copied?
> 
> That one is easy - we do return 'sz' which tells us how much got copied.

Ah, right. Perhaps I shouldn't be reviewing patches a few minutes
before heading home...

Jan


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