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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-boot fail REGR. vs. 59254
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-freebsd10-i386  6 xen-bootfail REGR. vs. 59254
 test-amd64-i386-rumpuserxen-i386  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-freebsd10-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-win7-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-xsm6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-win7-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-amd64-xl   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-qemut-rhel6hvm-amd  6 xen-bootfail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 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-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 59254
 test-amd64-i386-pair 10 xen-boot/dst_host fail REGR. vs. 59254
 test-amd64-i386-pair  9 xen-boot/src_host fail REGR. vs. 59254
 test-amd64-i386-qemuu-rhel6hvm-amd  6 xen-bootfail REGR. vs. 59254
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot   fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-xsm   6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-libvirt   6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-raw6 xen-bootfail baseline untested
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail baseline 
untested
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host   fail baseline untested
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host   fail baseline untested
 test-amd64-amd64-libvirt-vhd  9 debian-di-install   fail baseline untested
 test-amd64-amd64-i386-pvgrub  6 xen-bootfail baseline untested
 test-armhf-armhf-libvirt-raw  6 xen-bootfail baseline untested
 test-armhf-armhf-libvirt-qcow2  6 xen-boot  fail 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-amd64-qemuu-nested-amd  6 xen-boot  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-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 linux

Re: [Xen-devel] [PATCH v13 7/8] Add IOREQ_TYPE_VMWARE_PORT

[Paul Durrant]

> -Original Message-
> From: Don Slutz [mailto:don.sl...@gmail.com]
> Sent: 04 December 2015 00:23
> To: Paul Durrant; xen-devel@lists.xen.org
> Cc: Jun Nakajima; Wei Liu; Kevin Tian; Keir (Xen.org); Ian Campbell; George
> Dunlap; Andrew Cooper; Stefano Stabellini; Eddie Dong; Don Slutz; Tim
> (Xen.org); Aravind Gopalakrishnan; Jan Beulich; Suravee Suthikulpanit; Boris
> Ostrovsky; Ian Jackson
> Subject: Re: [Xen-devel] [PATCH v13 7/8] Add IOREQ_TYPE_VMWARE_PORT
> 
> On 12/01/15 06:28, Paul Durrant wrote:
> >> -Original Message-
> >> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
> >> boun...@lists.xen.org] On Behalf Of Don Slutz
> >> Sent: 28 November 2015 21:45
> >> To: xen-devel@lists.xen.org
> >> Cc: Jun Nakajima; Wei Liu; Kevin Tian; Keir (Xen.org); Ian Campbell;
> George
> >> Dunlap; Andrew Cooper; Stefano Stabellini; Eddie Dong; Don Slutz; Don
> Slutz;
> >> Tim (Xen.org); Aravind Gopalakrishnan; Jan Beulich; Suravee
> Suthikulpanit;
> >> Boris Ostrovsky; Ian Jackson
> >> Subject: [Xen-devel] [PATCH v13 7/8] Add IOREQ_TYPE_VMWARE_PORT
> >>
> >> From: Don Slutz 
> >>
> ...
> >>
> >>  /* Verify the emulation request has been correctly re-issued */
> >> -if ( (p.type != is_mmio ? IOREQ_TYPE_COPY : IOREQ_TYPE_PIO) ||
> >> +if ( (p.type != (is_mmio ? IOREQ_TYPE_COPY : is_vmware ?
> >> IOREQ_TYPE_VMWARE_PORT : IOREQ_TYPE_PIO)) ||
> >
> > is_vmware already incorporated !is_mmio so there's a redundant
> > check in that expression. The extra test also makes it look
> > pretty ugly... probably better re-factored into an if
> > statement.
> >
> 
> Ok, Will add a variable, that is set via an if statement.  Thinking about:
> 
>   case STATE_IORESP_READY:
> +{
> +uint8_t calc_type = p.type;
> +
> +if ( is_vmware )
> +calc_type = IOREQ_TYPE_VMWARE_PORT;
> +
>  vio->io_req.state = STATE_IOREQ_NONE;
>  p = vio->io_req;
> 
>  /* Verify the emulation request has been correctly re-issued */
> -if ( (p.type != is_mmio ? IOREQ_TYPE_COPY : IOREQ_TYPE_PIO) ||
> +if ( (p.type != calc_type) ||
> 
> 
> 
> 
> >>   (p.addr != addr) ||
> >>   (p.size != size) ||
> >>   (p.count != reps) ||
> ...
> >> +
> >> +p.type = IOREQ_TYPE_VMWARE_PORT;
> >> +vio->io_req.type = IOREQ_TYPE_VMWARE_PORT;
> >
> > This could be done in a single statement.
> >
> 
> Ok.
> 
>  p.type = vio->io_req.type = IOREQ_TYPE_VMWARE_PORT;
> 
> or
> 
>  vio->io_req.type = p.type = IOREQ_TYPE_VMWARE_PORT;
> 
> is clearer to you?

I think that the former is probably better.

> 
> >> +s = hvm_select_ioreq_server(curr->domain, &p);
> ...
> >>
> >>  if ( rc )
> >> -hvm_unmap_ioreq_page(s, 0);
> >> +{
> >> +hvm_unmap_ioreq_page(s, IOREQ_PAGE_TYPE_IOREQ);
> >> +return rc;
> >> +}
> >> +
> >> +rc = hvm_map_ioreq_page(s, IOREQ_PAGE_TYPE_VMPORT,
> >> vmport_ioreq_pfn);
> >
> > Is every ioreq server going to have one of these? It doesn't look
> > like it, so should you not have validity check on the pfn?
> >
> 
> 
> Currently the default is that all ioreq servers get the mapping:
> 

That's probably a bit wasteful. It should probably be selectable in the create 
HVM op. I don't know whether you'd even need it there in the default server 
since I guess the QEMU end of things post-dates the use of the HVM op (rather 
than the old param).

> +/* VMware port */
> +if ( i == HVMOP_IO_RANGE_VMWARE_PORT &&
> +s->domain->arch.hvm_domain.is_vmware_port_enabled )
> +rc = rangeset_add_range(s->range[i], 1, 1);
> 
> 
> 
> but you are right that a check on is_vmware_port_enabled should be
> added.  Will do.

Cool. Thanks,

  Paul

> 
>-Don Slutz
> 
> >   Paul
> >

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

Re: [Xen-devel] [PATCH OSSTEST] standalone: Log things we are running via with_logging

[Ian Campbell]

On Thu, 2015-12-03 at 16:41 +, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST] standalone: Log things we are
> running via with_logging"):
> > Turning on set -x is too verbose, so just echo the command ourselves.
> 
> It's not clear to me from the context whether $@ might contain things
> which would require quoting.

It's stuff which is able to be run on the next line with:
"$@" 2>&1 | tee "$log"
But I'm not sure that answers your question.

Are you worried about things being incorrectly expanded in the evaluation
of the echo, or just about being able to cut and paste a command directly
from this output into a shell? (or something else).

FWIW $@ is unlikely any $vars at this point or to contain spaces, quotes or
other special characters, although it's not totally impossible (it would
require job names, or idents, or ts-script arguments etc with such in
them).

>   set -x would quote them.
> 
> You can perhaps do something like this
>    bash -xc ': standalone-runs "$@"' x "$@" >&2
> ?  (Sadly -n suppresses output from -x too.)

Sadly it also spews the contents of my .bashrc too. Weirdly (?) adding --
norc _and_ --noprofile to the mix doesn't change that, which seems rather
contrary to the manpage.

Invoking as sh instead produces unquoted results:

$ sh -xc ': standalone-runs "$@"' x "foo" "bar bar"
+ : standalone-runs foo bar bar

(this must be difference between bash and POSIX?)

This seems to work:

$ bash -c 'set -x ; : standalone-runs: "$@"' x "foo" "bar bar"
+ : standalone-runs: foo 'bar bar'

And this: (set -x ; : "$@") also looks to DTRT:

$ foo() { (set -x ; : "$@") }
$ foo "foo" "bar bar"
+ : foo 'bar bar'

coreutils' printf(1) also has %q, but it's a bit ugly to use and is
backslashy rather than quoting :
$ printf "%q " "foo bar" "baz" ; echo
foo\ bar baz 

This is a tricky thing to search for (you mostly just get stuff about
regular variable quoting).

Closest thing I found to a solution was:
http://stackoverflow.com/questions/12985178/bash-quoted-array-expansion


Ian.

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

Re: [Xen-devel] [libvirt test] 65324: regressions - FAIL

[Joao Martins]

On 12/04/2015 01:18 AM, osstest service owner wrote:
> flight 65324 libvirt real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/65324/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. 
> vs. 63340
>  test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. 
> vs. 63340
A fix is in the works: it is failing because it failed to create the net
interface that has name that is the same as an existent domain on destination in
this case domid 1. And that happens because domain conf now includes the ifnames
but that aren't being cleaned up beforehand on migration Begin phase.

Joao

>  test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 
> 63340
> 
> Tests which did not succeed, but are not blocking:
>  test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never 
> pass
>  test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never 
> pass
>  test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never 
> pass
>  test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never 
> pass
>  test-armhf-armhf-libvirt 14 guest-saverestorefail   never 
> pass
>  test-armhf-armhf-libvirt 12 migrate-support-checkfail   never 
> pass
>  test-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-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  d2e5538b16e325d9095f3ccb0dac88bbd9fc98f0
> baseline version:
>  libvirt  3c7590e0a435d833895fc7b5be489e53e223ad95
> 
> Last test of basis63340  2015-10-28 04:19:47 Z   36 days
> Failing since 63352  2015-10-29 04:20:29 Z   35 days   31 attempts
> Testing same since65324  2015-12-03 04:21:16 Z0 days1 attempts
> 
> 
> People who touched revisions under test:
>   Andrea Bolognani 
>   Chen Hanxiao 
>   Christian Loehle 
>   Cole Robinson 
>   Daniel P. Berrange 
>   Daniel Veillard 
>   Dmitry Andreev 
>   Erik Skultety 
>   Guido Günther 
>   Ian Campbell 
>   Jim Fehlig 
>   Jiri Denemark 
>   Joao Martins 
>   John Ferlan 
>   Ján Tomko 
>   Laine Stump 
>   Luyao Huang 
>   Marc-André Lureau 
>   Martin Kletzander 
>   Maxim Perevedentsev 
>   Michal Privoznik 
>   Michel Normand 
>   Mikhail Feoktistov 
>   Nikolay Shirokovskiy 
>   Pavel Hrdina 
>   Peter Krempa 
>   Richard Weinberger 
>   Roman Bogorodskiy 
>   Stefan Berger 
>   Stefan Berger 
>   Wang Yufei 
>   Wei Jiangang 
> 
> 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-pairfail
>  test-amd64-i386-libvirt-pair fail
>  test-armhf-armhf-libvirt-qcow2   fail
>  test-armhf-armhf-libvirt-raw fail
>  test-amd64-amd64-libvirt-vhd fail
> 
> 
> 

Re: [Xen-devel] [PATCH LIBVIRT v1 1/2] libxl: Correct value for xendConfigVersion to xen{Parse, Format}ConfigCommon

[Daniel P. Berrange]

On Thu, Dec 03, 2015 at 11:13:06PM -0700, Jim Fehlig wrote:
> On 11/26/2015 09:59 AM, Ian Campbell wrote:
> > libxlConnectDomainXMLFromNative calls both xenParseXM and xenParseXL
> > with cfg->verInfo->xen_version_major, however AFAICT they both (either
> > inherently, or through there use of xenParseConfigCommon expect a
> > value from xenConfigVersionEnum (which does not correspond to
> > xen_version_major).
> 
> I recall being a little apprehensive about using xen_version_major when 
> writing
> the code, and apparently that was justified. But now that we are revisiting
> this, I wonder if we care about these old xend config versions at all. Is 
> anyone
> even running Xen 3.0.x, or 3.1.x, particularly with a newish libvirt? IMO we
> could drop all of this xend config nonsense and go with the code associated 
> with
> the last xend config version, i.e. XEND_CONFIG_VERSION_3_1_0.
> 
> And while mentioning dropping support for these old xend config versions, do I
> dare mention dropping the xend driver altogether? :-) It will certainly need 
> to
> be done some day. Question is whether that's a bit premature now.

We just decided to drop QEMU driver code supporting for RHEL-5 vintage
distros, requiring RHEL-6 as minimum. So I think it is entirely reasonable
to drop Xen driver code supporting similar vintage XenD.  That would
certainly simplify or even eliminate the current crazy xend_config_version
code we have

I think we need to continue suppoorting XenD driver for a while, but at
least you can simplify the code shared with libxl.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [Xen-devel] [PATCH XEN v6 25/32] tools/libs/gnttab: Extensive updates to API documentation.

[Ian Campbell]

On Thu, 2015-12-03 at 13:08 -0500, Daniel De Graaf wrote:
> On 03/12/15 06:22, Ian Campbell wrote:
> > In particular around error handling, behaviour on fork and the unmap
> > notification mechanism.
> > 
> > Behaviour of xengnttab_map_*grant_refs and xengntshr_share_pages on
> > partial failure has been confirmed/inferred (by inspection) on Linux
> > and Mini-os (the only two known implementations. Likewise the
> > behaviour of the notification mechanism has been confirmed/inferred
> > (by inspection) of the Linux implementation (currently the only
> > implementation) and libvchan (primary known user).
> > 
> > These updates are not folded into "tools: Refactor
> > /dev/xen/gnt{dev,shr} wrappers into libxengnttab." to try and reduce
> > the amount of non-movement changes in that patch.
> > 
> > While I'm not convinced by javadoc/doxygen cause the existing comments
> > which appear to use that syntax to have the appropriate /** marker.
> > 
> > Also fix a typo in a code comment.
> > 
> > Signed-off-by: Ian Campbell 
> > Cc: Daniel De Graaf 
> > ---
> > Daniel, you input on the description of the unmap notification stuff
> > would be much appreciated.
> 
> The description looks complete and correct to me.  The statement that
> the interfaces operate on a single page only might be misleading - the
> interface will work on multi-page mappings, but only allows one notify
> on the mapping.  I'm not sure this distinction is important for most
> users of the interface, since the notify is almost always used on a
> one-page mapping.

I think I concluded that it was a single page because the library
interfaces which allow a mapping to have a notify attached only take/return
a single gref:

void *xengnttab_map_grant_ref_notify(xengnttab_handle *xgt,
 uint32_t domid,
 uint32_t ref,
 int prot,
 uint32_t notify_offset,
 evtchn_port_t notify_port);
void *xengntshr_share_page_notify(xengntshr_handle *xgs, uint32_t domid,
  uint32_t *ref, int writable,
  uint32_t notify_offset,
  evtchn_port_t notify_port);

The offset in the underlying ioctl in the Linux implementation is a
uint64_t, so you are right that in principal it could support a larger
offset.

I think I am inclined to therefore leave things as they are, the
alternative would be to expand those two functions now to support multi-
gref mappings.

I think given the current set of use cases I would prefer to add multipage
variants in the future should the need arise.

I suppose the argument for making the change right no would be the
prediction of a userspace multipage ring implementation.

> Reviewed-by: Daniel De Graaf 

Thanks.

> 
> > @@ -71,6 +154,10 @@ void *xengnttab_map_grant_ref(xengnttab_handle
> > *xgt,
> >    * contiguous local address range. Mappings should be unmapped with
> >    * xengnttab_munmap.  Logs errors.
> >    *
> > + * On failure sets errno and returns NULL.
> > + *
> > + * If notify_offset or notify_port a requested and cannot be set up an
> > + * error will be returned and no mapping will be made.
> 
> Typo: "a requested" => "are requested"

Yes, thanks.


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

Re: [Xen-devel] Xen hypercall calling convention

[Andrew Cooper]

On 04/12/15 03:21, Carl Patenaude Poulin wrote:
> Hi folks,
>
> On page 12 of "The Definitive Guide to the Xen Hypervisor", it is
> mentioned that "Xen, like Linux, uses the MS-DOS calling convention,
> rather than the UNIX convention used by FreeBSD."
>
> I keep digging online and I can't find any information about an
> "MS-DOS calling convention".

Second google link,

www.agner.org/optimize/calling_conventions.pdf

except that you want to be looking for Windows 16bit as its alternative
name.


> We've already reverse engineered which registers are used in what
> order from the Mini-OS source code, but I'm wondering if there's a
> specification of this calling convention floating anywhere.

The in-tree public header files are the authoritative source of
information, so

http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/arch-x86/xen-x86_32.h;hb=HEAD

and

http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/arch-x86/xen-x86_64.h;hb=HEAD

respectively.

~Andrew

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

Re: [Xen-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

[Gerd Hoffmann]

  Hi,

> btw some questions here:
> 
> for non-gl and gl rendering in Qemu, are they based on dma-buf already?

> once we can export guest framebuffer in dma-buf, is there additional work
> required or just straightforward to integrate with SPICE?

Right now we are busy integrating dma-buf support into spice, which will
be used for the gl rendering path, for virtio-gpu.

For intel-vgpu the wireup inside qemu will be slightly different:  We'll
get a dma-buf handle from the igd driver, whereas virtio-gpu renders
into a texture, then exports that texture as dma-buf.

But in both cases we'll go pass the dma-buf with the guest framebuffer
(and meta-data such as fourcc and size) to spice-server, which in turn
will pass on the dma-buf to spice-client for (local) display.  So we
have a common code path in spice for both virtio-gpu and intel-vgpu,
based on dma-bufs.  spice-server even doesn't need to know what kind of
graphics device the guest has, it'll go just process the dma-bufs.

longer-term we also plan to support video-encoding for a remote display.
Again based on dma-bufs, by sending them to the gpu video encoder.


The non-gl rendering path needs to be figured out.

With virtio-gpu we'll go simply turn off 3d support, so the guest will
fallback to do software rendering, we'll get a classic DisplaySurface
and the vnc server can work with that.

That isn't going to fly with intel-vgpu though, so we need something
else.  Import dma-buf, then glReadPixels into a DisplaySurface would
work.  But as mentioned before I'd prefer a code path which doesn't
require opengl support in qemu, and one option for that would be the
special vfio region.  I've written up a quick draft meanwhile:


diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 751b69f..91b928d 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -596,6 +596,28 @@ struct vfio_iommu_spapr_tce_remove {
 };
 #define VFIO_IOMMU_SPAPR_TCE_REMOVE_IO(VFIO_TYPE, VFIO_BASE + 20)
 
+/*  Additional API for vGPU  */
+
+/*
+ * framebuffer meta data
+ * subregion located at the end of the framebuffer region
+ */
+struct vfio_framebuffer {
+   __u32 argsz;
+
+   /* out */
+   __u32 format;/* drm fourcc */
+   __u32 offset;/* relative to region start */
+   __u32 width; /* in pixels */
+   __u32 height;/* in pixels */
+   __u32 stride;/* in bytes  */
+
+   /* in+out */
+#define VFIO_FB_STATE_REQUEST_UPDATE   1  /* userspace requests update
*/
+#define VFIO_FB_STATE_UPDATE_COMPLETE  2  /* kernel signals completion
*/
+   __u32 state; /* VFIO_FB_STATE_ */
+};
+
 /* * */
 
 #endif /* _UAPIVFIO_H */

cheers,
  Gerd


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

Re: [Xen-devel] [xen-4.6-testing test] 65327: regressions - FAIL

[Wei Liu]

On Fri, Dec 04, 2015 at 05:15:28AM +, osstest service owner wrote:
> flight 65327 xen-4.6-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/65327/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 
> guest-localmigrate/x10 fail in 65210 REGR. vs. 63449

This has been blocked on merlot* for quite a while.

And xen-unstable (with the supposedly fixes to mini-os and oxenstored in
place) is not doing any better on merlot*, just that the test cast
itself won't block pushing.

http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/ALL

Looking into this further, OSStest is using cxenstored, which supposedly
doesn't have the bug that stalled the ring.

Maybe this is a host specific bug. Maybe cxenstored also has a latent
bug. I'm not sure. I don't know what to make of this.

Wei.

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

Re: [Xen-devel] [libvirt test] 65324: regressions - FAIL

[Ian Campbell]

Jim,

FYI, something in 3c7590e0a435..d2e5538b16e3 seems to have broken migrate.
The bisector is working on it at:
http://logs.test-lab.xenproject.org/osstest/results/bisect/libvirt/test-amd64-amd64-libvirt-pair.guest-migrate--src_host--dst_host.html

The build-armhf issue is fixed.

Stefano, Anthony: The debian-di-install failure has "error: Unknown driver
'vhd'" in the qemu-log. It turns out this has previously been bisected and
blamed on:

  commit 3fb401edbd8e9741c611bfddf6a2032ca91f55ed
  Merge: a44c280 816609b
  Author: Stefano Stabellini 
  Date:   Mon Nov 23 16:55:36 2015 +

  Merge remote-tracking branch 'qemu-xen/staging' into qemu-xen-4.7

See which went to xen-devel 
+ osstest-output but for some reason is in
neither the xen-devel nor osstest-output archives and attempting to open
the mail in evolution hangs the MUA!

Looks like the first failure was:
http://logs.test-lab.xenproject.org/osstest/logs/65096/test-amd64-amd64-libvirt-vhd/info.html

Ian.

On Fri, 2015-12-04 at 01:18 +, osstest service owner wrote:
> flight 65324 libvirt real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/65324/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. 
> vs. 63340
>  test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. 
> vs. 63340
>  test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 
> 63340
> 
> Tests which did not succeed, but are not blocking:
>  test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never 
> pass
>  test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never 
> pass
>  test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never 
> pass
>  test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never 
> pass
>  test-armhf-armhf-libvirt 14 guest-saverestorefail   never 
> pass
>  test-armhf-armhf-libvirt 12 migrate-support-checkfail   never 
> pass
>  test-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-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  d2e5538b16e325d9095f3ccb0dac88bbd9fc98f0
> baseline version:
>  libvirt  3c7590e0a435d833895fc7b5be489e53e223ad95
> 
> Last test of basis63340  2015-10-28 04:19:47 Z   36 days
> Failing since 63352  2015-10-29 04:20:29 Z   35 days   31 attempts
> Testing same since65324  2015-12-03 04:21:16 Z0 days1 attempts
> 
> 
> People who touched revisions under test:
>   Andrea Bolognani 
>   Chen Hanxiao 
>   Christian Loehle 
>   Cole Robinson 
>   Daniel P. Berrange 
>   Daniel Veillard 
>   Dmitry Andreev 
>   Erik Skultety 
>   Guido Günther 
>   Ian Campbell 
>   Jim Fehlig 
>   Jiri Denemark 
>   Joao Martins 
>   John Ferlan 
>   Ján Tomko 
>   Laine Stump 
>   Luyao Huang 
>   Marc-André Lureau 
>   Martin Kletzander 
>   Maxim Perevedentsev 
>   Michal Privoznik 
>   Michel Normand 
>   Mikhail Feoktistov 
>   Nikolay Shirokovskiy 
>   Pavel Hrdina 
>   Peter Krempa 
>   Richard Weinberger 
>   Roman Bogorodskiy 
>   Stefan Berger 
>   Stefan Berger 
>   Wang Yufei 
>   Wei Jiangang 
> 
> 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

[Xen-devel] [distros-debian-jessie test] 38428: tolerable FAIL

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-amd64-jessie-netboot-pygrub 9 debian-di-install fail blocked 
in 38362
 test-amd64-i386-i386-jessie-netboot-pvgrub 10 guest-start fail blocked in 38362
 test-amd64-amd64-amd64-jessie-netboot-pvgrub 10 guest-start fail blocked in 
38362

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

baseline version:
 flight   38362

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



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

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

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


Push not applicable.


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

Re: [Xen-devel] [libvirt test] 65324: regressions - FAIL

[Ian Campbell]

On Fri, 2015-12-04 at 09:54 +, Joao Martins wrote:
> 
> On 12/04/2015 01:18 AM, osstest service owner wrote:
> > flight 65324 libvirt real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/65324/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail
> > REGR. vs. 63340
> >  test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail
> > REGR. vs. 63340
> A fix is in the works: it is failing because it failed to create the net
> interface that has name that is the same as an existent domain on destination 
> in
> this case domid 1. And that happens because domain conf now includes the 
> ifnames
> but that aren't being cleaned up beforehand on migration Begin phase.

Super, thanks. (CCing Jim because I did so when I replied with a heads up
just now before seeing this mail).


> 
> Joao
> 
> >  test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR.
> > vs. 63340
> > 
> > Tests which did not succeed, but are not blocking:
> >  test-armhf-armhf-libvirt-raw  9 debian-di-
> > installfail   never pass
> >  test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail
> > never pass
> >  test-armhf-armhf-libvirt-xsm 12 migrate-support-
> > checkfail   never pass
> >  test-armhf-armhf-libvirt-xsm 14 guest-
> > saverestorefail   never pass
> >  test-armhf-armhf-libvirt 14 guest-
> > saverestorefail   never pass
> >  test-armhf-armhf-libvirt 12 migrate-support-
> > checkfail   never pass
> >  test-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-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  d2e5538b16e325d9095f3ccb0dac88bbd9fc98f0
> > baseline version:
> >  libvirt  3c7590e0a435d833895fc7b5be489e53e223ad95
> > 
> > Last test of basis63340  2015-10-28 04:19:47 Z   36 days
> > Failing since 63352  2015-10-29 04:20:29 Z   35 days   31
> > attempts
> > Testing same since65324  2015-12-03 04:21:16 Z0 days1
> > attempts
> > 
> > 
> > People who touched revisions under test:
> >   Andrea Bolognani 
> >   Chen Hanxiao 
> >   Christian Loehle 
> >   Cole Robinson 
> >   Daniel P. Berrange 
> >   Daniel Veillard 
> >   Dmitry Andreev 
> >   Erik Skultety 
> >   Guido Günther 
> >   Ian Campbell 
> >   Jim Fehlig 
> >   Jiri Denemark 
> >   Joao Martins 
> >   John Ferlan 
> >   Ján Tomko 
> >   Laine Stump 
> >   Luyao Huang 
> >   Marc-André Lureau 
> >   Martin Kletzander 
> >   Maxim Perevedentsev 
> >   Michal Privoznik 
> >   Michel Normand 
> >   Mikhail Feoktistov 
> >   Nikolay Shirokovskiy 
> >   Pavel Hrdina 
> >   Peter Krempa 
> >   Richard Weinberger 
> >   Roman Bogorodskiy 
> >   Stefan Berger 
> >   Stefan Berger 
> >   Wang Yufei 
> >   Wei Jiangang 
> > 
> > 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-lib

Re: [Xen-devel] [PATCH v2] x86: Fixup IRQs when CPUs go down during shutdown

[Andrew Cooper]

On 02/12/15 15:30, Jan Beulich wrote:
 On 02.12.15 at 16:09,  wrote:
>> On 12/02/2015 02:02 PM, Jan Beulich wrote:
>> On 02.12.15 at 14:46,  wrote:
 --- a/xen/arch/x86/smp.c
 +++ b/xen/arch/x86/smp.c
 @@ -286,6 +286,7 @@ void __stop_this_cpu(void)

   static void stop_this_cpu(void *dummy)
   {
 +fixup_eoi();
   __stop_this_cpu();
>>> Is this really needed during shutdown?
>> Possibly not, but I think it's cleaner to do the same as what is used 
>> for CPU down.
> I'm not convinced. Andrew?

Suppose there is an oustanding line interrupt on the pending eoi stack. 
Without this fixup_eoi(), it could stay permanently attached to a cpu
which isn't processing anything further.

With the current use of smp_send_stop(), all cpus will end up in a state
where they can only be recovered with an #INIT, so I suppose it doesn't
actually matter.

Therefore, not performing redundant work is probably the best course of
action.

~Andrew

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

Re: [Xen-devel] [PATCHv3 1/2] x86/ept: invalidate guest physical mappings on VMENTER

[George Dunlap]

On 03/12/15 16:42, David Vrabel wrote:
> If a guest allocates a page and the tlbflush_timestamp on the page
> indicates that a TLB flush of the previous owner is required, only the
> linear and combined mappings are invalidated.  The guest-physical
> mappings are not invalidated.
> 
> This is currently safe because the EPT code ensures that the
> guest-physical and combined mappings are invalidated /before/ the page
> is freed.  However, this prevents us from deferring the EPT invalidate
> until after the page is freed (e.g., to defer the invalidate until the
> p2m locks are released).
> 
> The TLB flush that may be done after allocating page already causes
> the original guest to VMEXIT, thus on VMENTER we can do an INVEPT if
> one is still pending.
> 
> ept_sync_domain() now marks all PCPUs as needing to be invalidated,
> including PCPUs that the domain has not run on.  We still only IPI
> those PCPUs that are active so this does not result in any more[1]
> INVEPT calls.
> 
> We do not attempt to track when PCPUs may have cached translations
> because the only safe way to clear this per-CPU state if immediately
> after an invalidate the PCPU is not active (i.e., the PCPU is not in
> d->domain_dirty_cpumask).  Since we only invalidate on VMENTER or by
> IPIing active PCPUs this can never happen.
> 
> [1] There is one unnecessary INVEPT when the domain runs on a PCPU for
> the very first time.  But this is: a) only 1 additional invalidate
> per PCPU for the lifetime of the domain; and b) we can avoid it
> with a subsequent change.
> 
> Signed-off-by: David Vrabel 

This looks like a definite improvement.

One thing you missed is that in ept_p2m_init(), it calls
__ept_sync_domain() on all cpus; but because the "invalidate" mask is
clear at that point, nothing will actually happen.

Part of this I think comes as a result from inverting what the mask
means.  Before this patch, "not synced" is the default, and therefore
you need to invalidate unless someone has set the bit saying you don't
have to.  After this, "don't invalidate" is the default and you do
nothing unless someone has set a bit saying you do have to.

I'd think prefer it if you left the mask as "synced_mask"; then you can
actually take that on_each_cpu() out of the ept_p2m_init entirely.
(Probably wants a comment pointing that out.)

 -George

> ---
>  xen/arch/x86/hvm/vmx/vmx.c | 22 ++
>  xen/arch/x86/mm/p2m-ept.c  | 20 
>  xen/include/asm-x86/hvm/vmx/vmcs.h |  3 +--
>  3 files changed, 19 insertions(+), 26 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 9ad6d82..2f3a9f1 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -738,24 +738,12 @@ static void vmx_ctxt_switch_from(struct vcpu *v)
>  
>  static void vmx_ctxt_switch_to(struct vcpu *v)
>  {
> -struct domain *d = v->domain;
>  unsigned long old_cr4 = read_cr4(), new_cr4 = mmu_cr4_features;
> -struct ept_data *ept_data = &p2m_get_hostp2m(d)->ept;
>  
>  /* HOST_CR4 in VMCS is always mmu_cr4_features. Sync CR4 now. */
>  if ( old_cr4 != new_cr4 )
>  write_cr4(new_cr4);
>  
> -if ( paging_mode_hap(d) )
> -{
> -unsigned int cpu = smp_processor_id();
> -/* Test-and-test-and-set this CPU in the EPT-is-synced mask. */
> -if ( !cpumask_test_cpu(cpu, ept_get_synced_mask(ept_data)) &&
> - !cpumask_test_and_set_cpu(cpu,
> -   ept_get_synced_mask(ept_data)) )
> -__invept(INVEPT_SINGLE_CONTEXT, ept_get_eptp(ept_data), 0);
> -}
> -
>  vmx_restore_guest_msrs(v);
>  vmx_restore_dr(v);
>  }
> @@ -3497,6 +3485,16 @@ void vmx_vmenter_helper(const struct cpu_user_regs 
> *regs)
>  if ( unlikely(need_flush) )
>  vpid_sync_all();
>  
> +if ( paging_mode_hap(curr->domain) )
> +{
> +struct ept_data *ept = &p2m_get_hostp2m(curr->domain)->ept;
> +unsigned int cpu = smp_processor_id();
> +
> +if ( cpumask_test_cpu(cpu, ept->invalidate)
> + && cpumask_test_and_clear_cpu(cpu, ept->invalidate) )
> +__invept(INVEPT_SINGLE_CONTEXT, ept_get_eptp(ept), 0);
> +}
> +
>   out:
>  HVMTRACE_ND(VMENTRY, 0, 1/*cycles*/, 0, 0, 0, 0, 0, 0, 0);
>  
> diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
> index eef0372..014e2b2 100644
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -1090,8 +1090,10 @@ static void ept_memory_type_changed(struct p2m_domain 
> *p2m)
>  static void __ept_sync_domain(void *info)
>  {
>  struct ept_data *ept = &((struct p2m_domain *)info)->ept;
> +unsigned int cpu = smp_processor_id();
>  
> -__invept(INVEPT_SINGLE_CONTEXT, ept_get_eptp(ept), 0);
> +if ( cpumask_test_and_clear_cpu(cpu, ept->invalidate) )
> +__invept(INVEPT_SINGLE_CONTEXT, ept_get_eptp(ept), 0);
>  }
>  
>  void ept_sync_domain(struc

Re: [Xen-devel] [xen-4.6-testing test] 65327: regressions - FAIL

[Jan Beulich]

>>> On 04.12.15 at 11:20,  wrote:
> On Fri, Dec 04, 2015 at 05:15:28AM +, osstest service owner wrote:
>> flight 65327 xen-4.6-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/65327/ 
>> 
>> Regressions :-(
>> 
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 
>> guest-localmigrate/x10 fail 
> in 65210 REGR. vs. 63449
> 
> This has been blocked on merlot* for quite a while.
> 
> And xen-unstable (with the supposedly fixes to mini-os and oxenstored in
> place) is not doing any better on merlot*, just that the test cast
> itself won't block pushing.

And indeed I had suggested a force push a number of flights ago,
but Ian had hoped it would eventually end up running on another
host, thus allowing a push to happen. I don't know how sticky the
stickiness of failed tests is, but I'm not getting the impression that
such a host change is going to happen reliably within a couple of
days at most.

Jan


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

Re: [Xen-devel] Seeking input for 2016 Advisory Board budget (needed by Friday)

[Lars Kurth]

Dario,

thank you for the feedback. 

Does anyone else have any? One item that was raised when I chatted to a few 
people was to see whether we can include something like 
https://fuzzing-project.org/ or http://lcamtuf.coredump.cx/afl/ into the Xen 
Project Test Lab. This may not be quite as easy as it seems, but Ian Jackson 
has some ideas. 

This would probably have two angles: a) an infrastructure angle, b) a tooling 
side with maybe a custom hypervisor build. It is not yet clear at this stage 
how much effort it would be to do this, but I see a number of possibilities to 
fund it
a) Just use normal Xen Project Budget (I don't think this would be something 
which is feasible if more development work is required)
b) See whether we can get some additional funds from initiatives such as CII 
(Core Infrastructure Initiative)
c) See whether this is something where a group of vendors in the community 
would be willing to step up and collaborate and help with manpower
d) See whether this is something where a group of vendors in the community 
would be willing to provide extra funds
e) A combination of all of the above

Assuming we could get funds/resources, then there are two ways of doing this in 
principle: 1) resources from community members, 2) hire a contractor on behalf 
of the project, 3) provide a grant to someone who has the right skills and can 
drive this forward or 4) a combination of all.

For now, I just wanted to get a sense of whether you think this is valuable and 
if so, I can add a place-holder to the budget and get this raised at one of the 
next Advisory Board meetings. I can also add this to my community plan.

I can also check with the Linux Foundation on what they have learned during CII 
and what is maybe realistic based on their experience.

Best Regards
Lars
 
> On 3 Dec 2015, at 09:58, Dario Faggioli  wrote:
> 
> On Wed, 2015-12-02 at 10:44 +, Lars Kurth wrote:
>> Hi everyone,
>> I am putting together the Advisory Board budget for 2016. Besides
>> items that are operational and spending on a new HW for the Test Lab,
>> are there any items which I should add that help the developer
>> community.
>> 
> I think all are good ideas and nice and useful things.
> 
> If we have to pick one, priority, IMO, should be given to automatic
> code and style checking. It is something we need quite badly, and it's
> hard to do (or, at least, time consuming) because of the various
> existing style in our codebase.
> 
>> * Easier hosting of personal git repos on a git hosting service
>> 
> 0
> 
>> * Development of code standards checking tools
>> 
> +2
> 
>> * Other tools (e.g. fixing up maintainers.pkl and similar)
>> 
> +1
> 
> Regards,
> Dario
> -- 
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> 


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

Re: [Xen-devel] [PATCHv3 2/2] x86/ept: defer the invalidation until the p2m lock is released

[George Dunlap]

On 03/12/15 16:42, David Vrabel wrote:
> From: David Vrabel 
> 
> Holding the p2m lock while calling ept_sync_domain() is very expensive
> since it does a on_selected_cpus() call.  IPIs on many socket machines
> can be very slows and on_selected_cpus() is serialized.
> 
> Defer the invalidate until the p2m lock is released.  Since the processor
> may cache partial translations, we also need to make sure any page table
> pages to be freed are not freed until the invalidate is complete.  Such
> pages are temporarily stored in a list.
> 
> Signed-off-by: David Vrabel 

Looks good.

One thing is that now (actually since the previous patch) the flush in
__ept_sync_domain() itself is actually entirely redundant, as the check
will happen on the vmentry path again anyway.  But I think you do want
to wait until at least all vcpus have been interrupted, and
on_selected_cpus() looks like the simplest way to do that.  (Otherwise
you could just call smp_send_event_check_mask() and get rid of
__ept_sync_domain() entirely.)

Jan / Andy, any thoughts?

 -George

> ---
> v2:
> - use per-p2m list for deferred pages.
> - update synced_mask while holding write lock.
> ---
>  xen/arch/x86/mm/mm-locks.h | 23 ++
>  xen/arch/x86/mm/p2m-ept.c  | 48 
> +-
>  xen/arch/x86/mm/p2m.c  | 18 +
>  xen/include/asm-x86/p2m.h  |  7 +++
>  4 files changed, 79 insertions(+), 17 deletions(-)
> 
> diff --git a/xen/arch/x86/mm/mm-locks.h b/xen/arch/x86/mm/mm-locks.h
> index 76c7217..b5eb560 100644
> --- a/xen/arch/x86/mm/mm-locks.h
> +++ b/xen/arch/x86/mm/mm-locks.h
> @@ -263,14 +263,21 @@ declare_mm_lock(altp2mlist)
>   */
>  
>  declare_mm_rwlock(altp2m);
> -#define p2m_lock(p) \
> -{   \
> -if ( p2m_is_altp2m(p) ) \
> -mm_write_lock(altp2m, &(p)->lock);  \
> -else\
> -mm_write_lock(p2m, &(p)->lock); \
> -}
> -#define p2m_unlock(p) mm_write_unlock(&(p)->lock);
> +#define p2m_lock(p) \
> +do {\
> +if ( p2m_is_altp2m(p) ) \
> +mm_write_lock(altp2m, &(p)->lock);  \
> +else\
> +mm_write_lock(p2m, &(p)->lock); \
> +(p)->defer_flush++; \
> +} while (0)
> +#define p2m_unlock(p)   \
> +do {\
> +if ( --(p)->defer_flush == 0 && (p)->need_flush )   \
> +(p)->flush_and_unlock(p);   \
> +else\
> +mm_write_unlock(&(p)->lock);\
> +} while (0)
>  #define gfn_lock(p,g,o)   p2m_lock(p)
>  #define gfn_unlock(p,g,o) p2m_unlock(p)
>  #define p2m_read_lock(p)  mm_read_lock(p2m, &(p)->lock)
> diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
> index 014e2b2..bec27d7 100644
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -263,7 +263,7 @@ static void ept_free_entry(struct p2m_domain *p2m, 
> ept_entry_t *ept_entry, int l
>  unmap_domain_page(epte);
>  }
>  
> -p2m_free_ptp(p2m, mfn_to_page(ept_entry->mfn));
> +p2m_free_ptp_defer(p2m, mfn_to_page(ept_entry->mfn));
>  }
>  
>  static bool_t ept_split_super_page(struct p2m_domain *p2m,
> @@ -1096,24 +1096,53 @@ static void __ept_sync_domain(void *info)
>  __invept(INVEPT_SINGLE_CONTEXT, ept_get_eptp(ept), 0);
>  }
>  
> -void ept_sync_domain(struct p2m_domain *p2m)
> +static void ept_sync_domain_prepare(struct p2m_domain *p2m)
>  {
>  struct domain *d = p2m->domain;
>  struct ept_data *ept = &p2m->ept;
> -/* Only if using EPT and this domain has some VCPUs to dirty. */
> -if ( !paging_mode_hap(d) || !d->vcpu || !d->vcpu[0] )
> -return;
> -
> -ASSERT(local_irq_is_enabled());
>  
>  if ( nestedhvm_enabled(d) && !p2m_is_nestedp2m(p2m) )
>  p2m_flush_nestedp2m(d);
>  
>  /* May need to invalidate on all PCPUs. */
>  cpumask_setall(ept->invalidate);
> +}
> +
> +static void ept_sync_domain_mask(struct p2m_domain *p2m, const cpumask_t 
> *mask)
> +{
> +on_selected_cpus(mask, __ept_sync_domain, p2m, 1);
> +}
> +
> +void ept_sync_domain(struct p2m_domain *p2m)
> +{
> +struct domain *d = p2m->domain;
> +
> +/* Only if using EPT and this domain has some VCPUs to dirty. */
> +if ( !paging_mode_hap(d) || !d->vcpu || !d->vcpu[0] )
> +return;
> +
> +ept_sync_domain_prepare(p2m);
> +
> +if ( p2m->defer_flush )
> +{
> +p2m->need_flush = 1;
> +return;
> +}
> +p2m->need_flush = 0;
> +
> +ept_sync_domain_mask(p2m, d->domain_d

[Xen-devel] [ovmf baseline-only test] 38427: trouble: broken/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3) broken REGR. vs. 38425

version targeted for testing:
 ovmf e04671e81a7fe842f640a926171048e5524b46e0
baseline version:
 ovmf dcb2e4bb61931e2dee1739bb76aba315002f0a82

Last test of basis38425  2015-12-03 18:24:52 Z0 days
Testing same since38427  2015-12-04 06:56:15 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Jeff Fan 
  Jordan Justen 
  Wang Yu 

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



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

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

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

broken-step test-amd64-amd64-xl-qemuu-ovmf-amd64 host-install(3)

Push not applicable.


commit e04671e81a7fe842f640a926171048e5524b46e0
Author: Ard Biesheuvel 
Date:   Thu Dec 3 08:51:36 2015 +

ArmVirtPkg: use explicit KERNEL_BLOB_TYPE cast

The ARM RVCT compiler does not allow implicit casts between enumerated
types and integer types. In this particular case, the STUB_FILE::Position
member is overloaded as a KERNEL_BLOB_TYPE identifier, so it does not
hurt to make that cast explicit.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19108 
6f19259b-4bc3-4df7-8a09-765794883524

commit 2e728930aa6aaeff230bb60f36c8e39632399bcc
Author: Ard Biesheuvel 
Date:   Thu Dec 3 08:51:27 2015 +

SecurityPkg: put missing empty lines at the end of some header files

Some compilers (like RVCT) reject input files that do not end in a
newline. So add missing newlines to some SecurityPkg header files.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Chao Zhang 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19107 
6f19259b-4bc3-4df7-8a09-765794883524

commit ce3ecf13645cadf80aedbc02f7b9934598263854
Author: Ard Biesheuvel 
Date:   Thu Dec 3 08:51:17 2015 +

MdeModulePkg: remove unreachable code

Some compilers (like RVCT) are finicky about unreachable code,
so remove it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19106 
6f19259b-4bc3-4df7-8a09-765794883524

commit 2c239d62fd37a8311bf3511ffbeca9d6057e114b
Author: Ard Biesheuvel 
Date:   Thu Dec 3 08:51:06 2015 +

IntelFrameworkModulePkg: remove unreachable code

Some compilers (like RVCT) are finicky about unreachable code,
so remove it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19105 
6f19259b-4bc3-4df7-8a09-765794883524

commit 103733f8e63b009b4f311e2df6bf32d5463082c7
Author: Jordan Justen 
Date:   Thu Dec 3 08:18:00 2015 +

BaseTools PatchCheck.py: Support binary diff

This allows a patch with binary data that is generated with --binary
to be parsed by the PatchCheck.py script.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen 
Reviewed-by: Liming Gao 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19104 
6f19259b-4bc3-4df7-8a09-765794883524

commit 5d9cd24ede010b95b4e7ca891de1c9c10a0faa2e
Author: Wang Yu 
Date:   Thu Dec 3 03:19:01 2015 +

BaseTools: Add VS2015 tool chain in tools_def.template

Contributed-under: TianoCore Co

Re: [Xen-devel] [xen-4.6-testing test] 65327: regressions - FAIL

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] [xen-4.6-testing test] 65327: regressions 
- FAIL"):
> And indeed I had suggested a force push a number of flights ago,
> but Ian had hoped it would eventually end up running on another
> host, thus allowing a push to happen.

I'm not sure which Ian this is and I can't find a record in email of
anyone having said that.  But, that seems like a rather forlorn hope.

It seems that this is a host-specific failure, which is reliably
reproducible.  I did a search in the database[1] to see if this test
ever passed on merlot, and it didn't.

> I don't know how sticky the stickiness of failed tests is, but I'm
> not getting the impression that such a host change is going to
> happen reliably within a couple of days at most.

The system tries to be as sticky as possible to avoid regressions
slipping through.

IMO the right justification for a push is that this test has never
passed on merlot.  The push gate only regards it as a regression
because it once happened to run on a different machine for some
reason, which looks like a baseline pass that it thinks ought to be
reproduced.

We can force push this in 4.6 and I will do so (based on 65327) after
sending this mail.

This will recur on other branches occasionally.  In general in
situations like this we have four options:
 1. Fix the underlying bug
 2. Force push each relevant tree each time this comes up
 3. Add this particular test to the allowable failures list
 4. Arrange to not run this test on merlot*

In this case: fixing the bug seems difficult (thanks to Wei for
investigating).  Selecting different hosts would be applicable if we
knew what the problem was (eg BIOS bug, CPU incompatibility, or
whatever), but doesn't seem relevant here.  Force pushing affected
trees will get annoying eventually.

I suggest we continue doing force pushes and mark the test as
non-blocking if it gets too annoying.

In the meantime I think we should continue to investigate the bug.  I
think it is likely that it is a race which we happen to lose on
merlot*.

Ian.

[1]

select * from steps join flights using (flight) join jobs using (flight,job) 
where job='test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm' and testid = 
'guest-localmigrate/x10' and blessing='real' and (select val from runvars r 
where r.flight=flights.flight and r.job=jobs.job and name='host') like 
'merlot%' order by flight desc;
 => 64 rows, all showing failure, on a variety of branches

select * from steps join flights using (flight) join jobs using (flight,job) 
where job='test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm' and testid = 
'guest-localmigrate/x10' and blessing='real' and (select val from runvars r 
where r.flight=flights.flight and r.job=jobs.job and name='host') like 
'merlot%' and steps.status='pass' order by flight desc;
 => 0 rows

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

Re: [Xen-devel] [xen-4.6-testing test] 65327: regressions - FAIL [and 1 more messages]

[Ian Jackson]

osstest service owner writes ("[xen-4.6-testing test] 65327: regressions - 
FAIL"):
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 
> guest-localmigrate/x10 fail in 65210 REGR. vs. 63449
> 
...
> version targeted for testing:
>  xen  78833c04250416f1870c458309d3ac0e5cf915fd

Force pushed as discussed.

Ian.

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

[Xen-devel] [PATCH v2] ignore writes to GICD_ICACTIVER ... GICD_ICACTIVERN

[Stefano Stabellini]

Injecting a fault to the guest just because it is writing to one of the
GICD_ICACTIVER registers, which are part of the GICv2 and GICv3 specs,
is harsh. Additionally it causes recent linux kernels to fail to boot on
Xen.

Ignore writes to GICD_ICACTIVER ... GICD_ICACTIVERN instead, to solve
the boot issue and for backportability. However implementing the
registers properly might a better long term solution.

Signed-off-by: Stefano Stabellini 

---

Changes in v2:
- rebase on staging

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 2c73133..3079901 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -494,11 +494,10 @@ static int vgic_v2_distr_mmio_write(struct vcpu *v, 
mmio_info_t *info,
 return 0;
 
 case VRANGE32(GICD_ICACTIVER, GICD_ICACTIVERN):
-if ( dabt.size != DABT_WORD ) goto bad_width;
-printk(XENLOG_G_ERR
+gdprintk(XENLOG_DEBUG,
"%pv: vGICD: unhandled word write %#"PRIregister" to 
ICACTIVER%d\n",
v, r, gicd_reg - GICD_ICACTIVER);
-return 0;
+goto write_ignore_32;
 
 case VRANGE32(GICD_IPRIORITYR, GICD_IPRIORITYRN):
 {
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 985e866..6011e9e 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -621,11 +621,10 @@ static int __vgic_v3_distr_common_mmio_write(const char 
*name, struct vcpu *v,
 return 0;
 
 case VRANGE32(GICD_ICACTIVER, GICD_ICACTIVERN):
-if ( dabt.size != DABT_WORD ) goto bad_width;
-printk(XENLOG_G_ERR
+gdprintk(XENLOG_DEBUG,
"%pv: %s: unhandled word write %#"PRIregister" to 
ICACTIVER%d\n",
v, name, r, reg - GICD_ICACTIVER);
-return 0;
+goto write_ignore_32;
 
 case VRANGE32(GICD_IPRIORITYR, GICD_IPRIORITYRN):
 {

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

Re: [Xen-devel] [PATCH v2] ignore writes to GICD_ICACTIVER ... GICD_ICACTIVERN

[Julien Grall]

Hi Stefano:

Can you please add xen/arm in the commit title?

On 04/12/2015 12:36, Stefano Stabellini wrote:

Injecting a fault to the guest just because it is writing to one of the
GICD_ICACTIVER registers, which are part of the GICv2 and GICv3 specs,
is harsh. Additionally it causes recent linux kernels to fail to boot on
Xen.

Ignore writes to GICD_ICACTIVER ... GICD_ICACTIVERN instead, to solve
the boot issue and for backportability. However implementing the
registers properly might a better long term solution.

Signed-off-by: Stefano Stabellini 

---

Changes in v2:
- rebase on staging

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 2c73133..3079901 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -494,11 +494,10 @@ static int vgic_v2_distr_mmio_write(struct vcpu *v, 
mmio_info_t *info,
  return 0;

  case VRANGE32(GICD_ICACTIVER, GICD_ICACTIVERN):
-if ( dabt.size != DABT_WORD ) goto bad_width;
-printk(XENLOG_G_ERR
+gdprintk(XENLOG_DEBUG,


Why did you  move to gdprintk? The vCPU is already printed using %pv in 
the string.



 "%pv: vGICD: unhandled word write %#"PRIregister" to 
ICACTIVER%d\n",
 v, r, gicd_reg - GICD_ICACTIVER);
-return 0;
+goto write_ignore_32;

  case VRANGE32(GICD_IPRIORITYR, GICD_IPRIORITYRN):
  {
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 985e866..6011e9e 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -621,11 +621,10 @@ static int __vgic_v3_distr_common_mmio_write(const char 
*name, struct vcpu *v,
  return 0;

  case VRANGE32(GICD_ICACTIVER, GICD_ICACTIVERN):
-if ( dabt.size != DABT_WORD ) goto bad_width;
-printk(XENLOG_G_ERR
+gdprintk(XENLOG_DEBUG,


Ditto


 "%pv: %s: unhandled word write %#"PRIregister" to 
ICACTIVER%d\n",
 v, name, r, reg - GICD_ICACTIVER);
-return 0;
+goto write_ignore_32;

  case VRANGE32(GICD_IPRIORITYR, GICD_IPRIORITYRN):
  {



Regards,

--
Julien Grall

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl   3 host-install(3) broken REGR. vs. 65114
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. vs. 
65114

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail blocked in 65114
 test-amd64-i386-rumpuserxen-i386 10 guest-startfail like 65114
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 65114
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail like 65114
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 65114
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 65114
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   like 65114

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-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-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-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
 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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  68dc5813545c408b57221a2cb81b7e00dc9dc630
baseline version:
 xen  713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1

Last test of basis65114  2015-11-25 19:42:37 Z8 days
Failing since 65141  2015-11-26 20:45:33 Z7 days   10 attempts
Testing same since65338  2015-12-03 18:48:10 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  Daniel De Graaf 
  David Scott 
  David Vrabel 
  Doug Goldstein 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jonathan Creekmore 
  Juergen Gross 
  Kai Huang 
  Kevin Tian 
  Len Brown 
  Paul Durrant 
  Robert Hu 
  Roger Pau Monné 
  Wei Liu 
  Xudong Hao 
  Yang Zhang 

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

Re: [Xen-devel] [PATCHv3 1/2] x86/ept: invalidate guest physical mappings on VMENTER

[David Vrabel]

On 04/12/15 11:00, George Dunlap wrote:
> On 03/12/15 16:42, David Vrabel wrote:
>> If a guest allocates a page and the tlbflush_timestamp on the page
>> indicates that a TLB flush of the previous owner is required, only the
>> linear and combined mappings are invalidated.  The guest-physical
>> mappings are not invalidated.
>>
>> This is currently safe because the EPT code ensures that the
>> guest-physical and combined mappings are invalidated /before/ the page
>> is freed.  However, this prevents us from deferring the EPT invalidate
>> until after the page is freed (e.g., to defer the invalidate until the
>> p2m locks are released).
>>
>> The TLB flush that may be done after allocating page already causes
>> the original guest to VMEXIT, thus on VMENTER we can do an INVEPT if
>> one is still pending.
>>
>> ept_sync_domain() now marks all PCPUs as needing to be invalidated,
>> including PCPUs that the domain has not run on.  We still only IPI
>> those PCPUs that are active so this does not result in any more[1]
>> INVEPT calls.
>>
>> We do not attempt to track when PCPUs may have cached translations
>> because the only safe way to clear this per-CPU state if immediately
>> after an invalidate the PCPU is not active (i.e., the PCPU is not in
>> d->domain_dirty_cpumask).  Since we only invalidate on VMENTER or by
>> IPIing active PCPUs this can never happen.
>>
>> [1] There is one unnecessary INVEPT when the domain runs on a PCPU for
>> the very first time.  But this is: a) only 1 additional invalidate
>> per PCPU for the lifetime of the domain; and b) we can avoid it
>> with a subsequent change.
>>
>> Signed-off-by: David Vrabel 
> 
> This looks like a definite improvement.
> 
> One thing you missed is that in ept_p2m_init(), it calls
> __ept_sync_domain() on all cpus; but because the "invalidate" mask is
> clear at that point, nothing will actually happen.

Good point.  I'd missed this because I'd planned to replace this initial
invalidate by initializing ept->invalidate to all ones (as I alluded to
in the [1] footnote).

> Part of this I think comes as a result from inverting what the mask
> means.  Before this patch, "not synced" is the default, and therefore
> you need to invalidate unless someone has set the bit saying you don't
> have to.  After this, "don't invalidate" is the default and you do
> nothing unless someone has set a bit saying you do have to.
> 
> I'd think prefer it if you left the mask as "synced_mask"; then you can
> actually take that on_each_cpu() out of the ept_p2m_init entirely.
> (Probably wants a comment pointing that out.)

I changed its name because it's old use as synced_mask (i.e., the set of
CPUs needing to be notified of required invalidation) did not match its
name.  I rather not keep the name and invert its use.

David

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

[Xen-devel] [OSSTEST PATCH] production-config-cambridge: Use new squid proxy

[Ian Jackson]

Specify both HttpProxy and DebianMirrorProxy.  In my tests this seems
to improve some of the apparently-intercepting-proxy-related failures,
and it will certainly improve logging.

I set DebianMirrorProxy too so that queries to security.d.o go through
the proxy.  Ideally we would have a apt cache that could be used as an
http proxy rather than as an origin server; when that happens we can
set DebianMirrorProxy to point to it and do away with DebianMirrorHost
(as we do in Massachusetts).

Signed-off-by: Ian Jackson 
---
 production-config-cambridge |3 +++
 1 file changed, 3 insertions(+)

diff --git a/production-config-cambridge b/production-config-cambridge
index f801303..012a056 100644
--- a/production-config-cambridge
+++ b/production-config-cambridge
@@ -82,6 +82,9 @@ XenUseUser osstest
 #DebianMirrorHost debian.uk.xensource.com
 DebianMirrorHost 10.80.16.196
 
+HttpProxy http://osstest.xs.citrite.net:3128/
+DebianMirrorProxy http://osstest.xs.citrite.net:3128/
+
 HostProp_NtpServer ntp.uk.xensource.com
 HostProp_DhcpWatchMethod leases dhcp3 dns1.uk.xensource.com:5556
 
-- 
1.7.10.4


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

[Xen-devel] [PATCH v3] x86: Fixup IRQs when CPUs go down during shutdown

[Ross Lagerwall]

Commit fc0c3fa2ad5c ("x86/IO-APIC: fix setup of Xen internally used IRQs
(take 2)") introduced a regression on some hardware where Xen would hang
during shutdown, repeating the following message:
APIC error on CPU0: 08(08), Receive accept error

This appears to be because an interrupt (in this case from the serial
console) destined for a CPU other than the boot CPU is left unhandled so
an APIC error on CPU 0 is generated instead.

To fix this, before taking down the non-boot CPUs, call fixup_irqs()
with a CPU mask of only the boot CPU to reset the IRQ affinities
correctly.

Signed-off-by: Ross Lagerwall 
---
v3:
* Don't call fixup_eoi() in shutdown path
* Use cpumask_of
* Update comments
* Reduce code churn

 xen/arch/x86/irq.c| 28 ++--
 xen/arch/x86/smp.c|  4 
 xen/arch/x86/smpboot.c|  3 ++-
 xen/include/asm-x86/irq.h |  5 +++--
 4 files changed, 27 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 5f515a0..1228568 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -2328,14 +2328,12 @@ static int __init setup_dump_irqs(void)
 }
 __initcall(setup_dump_irqs);
 
-/* A cpu has been removed from cpu_online_mask.  Re-set irq affinities. */
-void fixup_irqs(void)
+/* Reset irq affinities to match the given CPU mask. */
+void fixup_irqs(const cpumask_t *mask, bool_t verbose)
 {
-unsigned int irq, sp;
+unsigned int irq;
 static int warned;
 struct irq_desc *desc;
-irq_guest_action_t *action;
-struct pending_eoi *peoi;
 
 for ( irq = 0; irq < nr_irqs; irq++ )
 {
@@ -2355,21 +2353,20 @@ void fixup_irqs(void)
 vector = irq_to_vector(irq);
 if ( vector >= FIRST_HIPRIORITY_VECTOR &&
  vector <= LAST_HIPRIORITY_VECTOR )
-cpumask_and(desc->arch.cpu_mask, desc->arch.cpu_mask,
-&cpu_online_map);
+cpumask_and(desc->arch.cpu_mask, desc->arch.cpu_mask, mask);
 
 cpumask_copy(&affinity, desc->affinity);
-if ( !desc->action || cpumask_subset(&affinity, &cpu_online_map) )
+if ( !desc->action || cpumask_subset(&affinity, mask) )
 {
 spin_unlock(&desc->lock);
 continue;
 }
 
-cpumask_and(&affinity, &affinity, &cpu_online_map);
+cpumask_and(&affinity, &affinity, mask);
 if ( cpumask_empty(&affinity) )
 {
 break_affinity = 1;
-cpumask_copy(&affinity, &cpu_online_map);
+cpumask_copy(&affinity, mask);
 }
 
 if ( desc->handler->disable )
@@ -2385,6 +2382,9 @@ void fixup_irqs(void)
 
 spin_unlock(&desc->lock);
 
+if ( !verbose )
+continue;
+
 if ( break_affinity && set_affinity )
 printk("Broke affinity for irq %i\n", irq);
 else if ( !set_affinity )
@@ -2395,6 +2395,14 @@ void fixup_irqs(void)
 local_irq_enable();
 mdelay(1);
 local_irq_disable();
+}
+
+void fixup_eoi(void)
+{
+unsigned int irq, sp;
+struct irq_desc *desc;
+irq_guest_action_t *action;
+struct pending_eoi *peoi;
 
 /* Clean up cpu_eoi_map of every interrupt to exclude this CPU. */
 for ( irq = 0; irq < nr_irqs; irq++ )
diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
index 50ff6c2..988b9c2 100644
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -299,6 +299,10 @@ void smp_send_stop(void)
 {
 int timeout = 10;
 
+local_irq_disable();
+fixup_irqs(cpumask_of(smp_processor_id()), 0);
+local_irq_enable();
+
 smp_call_function(stop_this_cpu, NULL, 0);
 
 /* Wait 10ms for all other CPUs to go offline. */
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 5d48bac..1eb16cb 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -922,7 +922,8 @@ void __cpu_disable(void)
 
 /* It's now safe to remove this processor from the online map */
 cpumask_clear_cpu(cpu, &cpu_online_map);
-fixup_irqs();
+fixup_irqs(&cpu_online_map, 1);
+fixup_eoi();
 
 if ( cpu_disable_scheduler(cpu) )
 BUG();
diff --git a/xen/include/asm-x86/irq.h b/xen/include/asm-x86/irq.h
index fcf37a3..7efdd37 100644
--- a/xen/include/asm-x86/irq.h
+++ b/xen/include/asm-x86/irq.h
@@ -148,8 +148,9 @@ int map_domain_emuirq_pirq(struct domain *d, int pirq, int 
irq);
 int unmap_domain_pirq_emuirq(struct domain *d, int pirq);
 bool_t hvm_domain_use_pirq(const struct domain *, const struct pirq *);
 
-/* A cpu has been removed from cpu_online_mask.  Re-set irq affinities. */
-void fixup_irqs(void);
+/* Reset irq affinities to match the given CPU mask. */
+void fixup_irqs(const cpumask_t *mask, bool_t verbose);
+void fixup_eoi(void);
 
 int  init_irq_data(void);
 
-- 
2.4.3


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

Re: [Xen-devel] [PATCHv1] x86: rtc_cmos platform device requires legacy irqs

[David Vrabel]

On 03/12/15 10:43, David Vrabel wrote:
> Adding the rtc platform device when there are no legacy irqs (no
> legacy PIC) causes a conflict with other devices that end up using the
> same irq number.

An alternative is to remove the rtc_cmos platform device in Xen PV
guests.

Any preference on how this regression should be fixed?

David

8<--
x86: Xen PV guests don't have the rtc_cmos platform device

Adding the rtc platform device in a Xen PV guests causes an IRQ
conflict because these guests do not have a legacy PIC.

In a single VCPU Xen PV guest we should have:

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

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

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

So don't add the rtc_cmos device in Xen PV guests.

Reported-by: Sander Eikelenboom 
Signed-off-by: David Vrabel 
Tested-by: Sander Eikelenboom 
---
 arch/x86/kernel/rtc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
index cd96852..7b190b8 100644
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -200,6 +200,9 @@ static __init int add_rtc_cmos(void)
}
 #endif
 
+   if (xen_pv_domain())
+   return -ENODEV;
+
platform_device_register(&rtc_device);
dev_info(&rtc_device.dev,
 "registered platform RTC device (no PNP device found)\n");
-- 
2.1.4


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

Re: [Xen-devel] [OSSTEST PATCH] production-config-cambridge: Use new squid proxy

[Ian Campbell]

On Fri, 2015-12-04 at 13:57 +, Ian Jackson wrote:
> Specify both HttpProxy and DebianMirrorProxy.  In my tests this seems
> to improve some of the apparently-intercepting-proxy-related failures,
> and it will certainly improve logging.
> 
> I set DebianMirrorProxy too so that queries to security.d.o go through
> the proxy.  Ideally we would have a apt cache that could be used as an
> http proxy rather than as an origin server; when that happens we can
> set DebianMirrorProxy to point to it and do away with DebianMirrorHost
> (as we do in Massachusetts).
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 

Do you want to go pretest in Cambridge then merge back to colo or do you
want to push it to the colo and let it flow through in time?


> ---
>  production-config-cambridge |3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/production-config-cambridge b/production-config-cambridge
> index f801303..012a056 100644
> --- a/production-config-cambridge
> +++ b/production-config-cambridge
> @@ -82,6 +82,9 @@ XenUseUser osstest
>  #DebianMirrorHost debian.uk.xensource.com
>  DebianMirrorHost 10.80.16.196
>  
> +HttpProxy http://osstest.xs.citrite.net:3128/
> +DebianMirrorProxy http://osstest.xs.citrite.net:3128/
> +
>  HostProp_NtpServer ntp.uk.xensource.com
>  HostProp_DhcpWatchMethod leases dhcp3 dns1.uk.xensource.com:5556
>  

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

[Xen-devel] [PATCH v3] x86/VPMU: Support only versions 2 through 4 of architectural performance monitoring

[Boris Ostrovsky]

We need to have at least version 2 since it's the first version to
support various control and status registers (such as
MSR_CORE_PERF_GLOBAL_CTRL) that VPMU relies on always having.

We don't fully emulate version 4 but since it's back compatible with
earlier versions we can fall back to v3. At this point there is no
compatibility statement for v5 so anything above 4 is not supported.

For guests querying PMU version via CPUID leaf 0xa clip it at v3.

With explicit testing for PMU version we can now remove CPUID model
check.

Signed-off-by: Boris Ostrovsky 
---
v3: 
* Clip PMU version to 3 in CPUID op (as opposed to only checking for version
  4 in previous posting)
* Convert 'if' statemnt to 'switch' in core2_vpmu_init()
* Update commit message

 xen/arch/x86/cpu/vpmu_intel.c | 80 ---
 1 file changed, 30 insertions(+), 50 deletions(-)

diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c
index d5ea7fe..c27f095 100644
--- a/xen/arch/x86/cpu/vpmu_intel.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -733,11 +733,11 @@ static void core2_vpmu_do_cpuid(unsigned int input,
 unsigned int *eax, unsigned int *ebx,
 unsigned int *ecx, unsigned int *edx)
 {
-if (input == 0x1)
+switch ( input )
 {
-struct vpmu_struct *vpmu = vcpu_vpmu(current);
+case 0x1:
 
-if ( vpmu_is_set(vpmu, VPMU_CPU_HAS_DS) )
+if ( vpmu_is_set(vcpu_vpmu(current), VPMU_CPU_HAS_DS) )
 {
 /* Switch on the 'Debug Store' feature in CPUID.EAX[1]:EDX[21] */
 *edx |= cpufeat_mask(X86_FEATURE_DS);
@@ -746,6 +746,13 @@ static void core2_vpmu_do_cpuid(unsigned int input,
 if ( cpu_has(¤t_cpu_data, X86_FEATURE_DSCPL) )
 *ecx |= cpufeat_mask(X86_FEATURE_DSCPL);
 }
+break;
+
+case 0xa:
+/* Report at most version 3 since that's all we currently emulate */
+if ( MASK_EXTR(*eax, PMU_VERSION_MASK) > 3 )
+*eax = (*eax & ~PMU_VERSION_MASK) | MASK_INSR(3, PMU_VERSION_MASK);
+break;
 }
 }
 
@@ -955,59 +962,32 @@ int vmx_vpmu_initialise(struct vcpu *v)
 int __init core2_vpmu_init(void)
 {
 u64 caps;
+unsigned int version = 0;
 
-if ( current_cpu_data.x86 != 6 )
+if ( current_cpu_data.cpuid_level >= 0xa )
+version = MASK_EXTR(cpuid_eax(0xa), PMU_VERSION_MASK);
+
+switch ( version )
 {
-printk(XENLOG_WARNING "VPMU: only family 6 is supported\n");
+case 4:
+printk(XENLOG_INFO "VPMU: PMU version 4 is not fully supported. "
+   "Emulating version 3\n");
+/* FALLTHROUGH */
+
+case 2:
+case 3:
+break;
+
+default:
+printk(XENLOG_WARNING "VPMU: PMU version %u is not supported\n",
+   version);
 return -EINVAL;
 }
 
-switch ( current_cpu_data.x86_model )
+if ( current_cpu_data.x86 != 6 )
 {
-/* Core2: */
-case 0x0f: /* original 65 nm celeron/pentium/core2/xeon, 
"Merom"/"Conroe" */
-case 0x16: /* single-core 65 nm celeron/core2solo "Merom-L"/"Conroe-L" 
*/
-case 0x17: /* 45 nm celeron/core2/xeon "Penryn"/"Wolfdale" */
-case 0x1d: /* six-core 45 nm xeon "Dunnington" */
-
-case 0x2a: /* SandyBridge */
-case 0x2d: /* SandyBridge, "Romley-EP" */
-
-/* Nehalem: */
-case 0x1a: /* 45 nm nehalem, "Bloomfield" */
-case 0x1e: /* 45 nm nehalem, "Lynnfield", "Clarksfield", "Jasper 
Forest" */
-case 0x2e: /* 45 nm nehalem-ex, "Beckton" */
-
-/* Westmere: */
-case 0x25: /* 32 nm nehalem, "Clarkdale", "Arrandale" */
-case 0x2c: /* 32 nm nehalem, "Gulftown", "Westmere-EP" */
-case 0x2f: /* 32 nm Westmere-EX */
-
-case 0x3a: /* IvyBridge */
-case 0x3e: /* IvyBridge EP */
-
-/* Haswell: */
-case 0x3c:
-case 0x3f:
-case 0x45:
-case 0x46:
-
-/* Broadwell */
-case 0x3d:
-case 0x4f:
-case 0x56:
-
-/* future: */
-case 0x4e:
-
-/* next gen Xeon Phi */
-case 0x57:
-break;
-
-default:
-printk(XENLOG_WARNING "VPMU: Unsupported CPU model %#x\n",
-   current_cpu_data.x86_model);
-return -EINVAL;
+printk(XENLOG_WARNING "VPMU: only family 6 is supported\n");
+return -EINVAL;
 }
 
 arch_pmc_cnt = core2_get_arch_pmc_count();
-- 
1.8.1.4


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

Re: [Xen-devel] [PATCH LIBVIRT v1 1/2] libxl: Correct value for xendConfigVersion to xen{Parse, Format}ConfigCommon

[Ian Campbell]

On Fri, 2015-12-04 at 10:01 +, Daniel P. Berrange wrote:
> On Thu, Dec 03, 2015 at 11:13:06PM -0700, Jim Fehlig wrote:
> > On 11/26/2015 09:59 AM, Ian Campbell wrote:
> > > libxlConnectDomainXMLFromNative calls both xenParseXM and xenParseXL
> > > with cfg->verInfo->xen_version_major, however AFAICT they both
> > > (either
> > > inherently, or through there use of xenParseConfigCommon expect a
> > > value from xenConfigVersionEnum (which does not correspond to
> > > xen_version_major).
> > 
> > I recall being a little apprehensive about using xen_version_major when
> > writing
> > the code, and apparently that was justified. But now that we are
> > revisiting
> > this, I wonder if we care about these old xend config versions at all.
> > Is anyone
> > even running Xen 3.0.x, or 3.1.x, particularly with a newish libvirt?
> > IMO we
> > could drop all of this xend config nonsense and go with the code
> > associated with
> > the last xend config version, i.e. XEND_CONFIG_VERSION_3_1_0.
> > 
> > And while mentioning dropping support for these old xend config
> > versions, do I
> > dare mention dropping the xend driver altogether? :-) It will certainly
> > need to
> > be done some day. Question is whether that's a bit premature now.
> 
> We just decided to drop QEMU driver code supporting for RHEL-5 vintage
> distros, requiring RHEL-6 as minimum. So I think it is entirely reasonable
> to drop Xen driver code supporting similar vintage XenD.  That would
> certainly simplify or even eliminate the current crazy xend_config_version
> code we have

RHEL 6.0 looks[0] to have been release on 2010-11-09, which was in the
middle of Xen 4.0 and 4.1[1]. 4.0 seems like a decent enough cut off point
(and is what is in Debian oldstable AKA Wheezy, FWIW) plus it is after the
currently latest XEND_CONFIG_VERSION, so all that code could be removed.

Shall I respin this series with that as a precursor?

Ian.

[0] https://access.redhat.com/articles/3078
[1] http://wiki.xen.org/wiki/Xen_Release_Features

> I think we need to continue suppoorting XenD driver for a while, but at
> least you can simplify the code shared with libxl.
> 
> Regards,
> Daniel

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

Re: [Xen-devel] [PATCH LIBVIRT v1 1/2] libxl: Correct value for xendConfigVersion to xen{Parse, Format}ConfigCommon

[Daniel P. Berrange]

On Fri, Dec 04, 2015 at 02:19:33PM +, Ian Campbell wrote:
> On Fri, 2015-12-04 at 10:01 +, Daniel P. Berrange wrote:
> > On Thu, Dec 03, 2015 at 11:13:06PM -0700, Jim Fehlig wrote:
> > > On 11/26/2015 09:59 AM, Ian Campbell wrote:
> > > > libxlConnectDomainXMLFromNative calls both xenParseXM and xenParseXL
> > > > with cfg->verInfo->xen_version_major, however AFAICT they both
> > > > (either
> > > > inherently, or through there use of xenParseConfigCommon expect a
> > > > value from xenConfigVersionEnum (which does not correspond to
> > > > xen_version_major).
> > > 
> > > I recall being a little apprehensive about using xen_version_major when
> > > writing
> > > the code, and apparently that was justified. But now that we are
> > > revisiting
> > > this, I wonder if we care about these old xend config versions at all.
> > > Is anyone
> > > even running Xen 3.0.x, or 3.1.x, particularly with a newish libvirt?
> > > IMO we
> > > could drop all of this xend config nonsense and go with the code
> > > associated with
> > > the last xend config version, i.e. XEND_CONFIG_VERSION_3_1_0.
> > > 
> > > And while mentioning dropping support for these old xend config
> > > versions, do I
> > > dare mention dropping the xend driver altogether? :-) It will certainly
> > > need to
> > > be done some day. Question is whether that's a bit premature now.
> > 
> > We just decided to drop QEMU driver code supporting for RHEL-5 vintage
> > distros, requiring RHEL-6 as minimum. So I think it is entirely reasonable
> > to drop Xen driver code supporting similar vintage XenD.  That would
> > certainly simplify or even eliminate the current crazy xend_config_version
> > code we have
> 
> RHEL 6.0 looks[0] to have been release on 2010-11-09, which was in the
> middle of Xen 4.0 and 4.1[1]. 4.0 seems like a decent enough cut off point
> (and is what is in Debian oldstable AKA Wheezy, FWIW) plus it is after the
> currently latest XEND_CONFIG_VERSION, so all that code could be removed.
> 
> Shall I respin this series with that as a precursor?

Yeah, that sounds reasonable. Would let us drop all Xen 3.x support
essentially.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

[Xen-devel] [PATCH] xen_disk: treat "vhd" as "vpc"

[Stefano Stabellini]

The Xen toolstack uses "vhd" to specify a disk in VHD format, however
the name of the driver in QEMU is "vpc". Replace "vhd" with "vpc", so
that QEMU can find the right driver to use for it.

Signed-off-by: Stefano Stabellini 

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 267d8a8..37e14d1 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -811,6 +811,9 @@ static int blk_init(struct XenDevice *xendev)
 if (!strcmp("aio", blkdev->fileproto)) {
 blkdev->fileproto = "raw";
 }
+if (!strcmp("vhd", blkdev->fileproto)) {
+blkdev->fileproto = "vpc";
+}
 if (blkdev->mode == NULL) {
 blkdev->mode = xenstore_read_be_str(&blkdev->xendev, "mode");
 }

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

Re: [Xen-devel] [PATCH v3] x86: Fixup IRQs when CPUs go down during shutdown

[Jan Beulich]

>>> On 04.12.15 at 15:01,  wrote:
> Commit fc0c3fa2ad5c ("x86/IO-APIC: fix setup of Xen internally used IRQs
> (take 2)") introduced a regression on some hardware where Xen would hang
> during shutdown, repeating the following message:
> APIC error on CPU0: 08(08), Receive accept error
> 
> This appears to be because an interrupt (in this case from the serial
> console) destined for a CPU other than the boot CPU is left unhandled so
> an APIC error on CPU 0 is generated instead.
> 
> To fix this, before taking down the non-boot CPUs, call fixup_irqs()
> with a CPU mask of only the boot CPU to reset the IRQ affinities
> correctly.
> 
> Signed-off-by: Ross Lagerwall 

Reviewed-by: Jan Beulich 

Albeit along the lines of ...

> * Reduce code churn

... I really would have wanted the split of the functions to be
undone too (renaming the bool_t function parameter suitably).

Jan


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

Re: [Xen-devel] [libvirt test] 65324: regressions - FAIL

[Stefano Stabellini]

On Fri, 4 Dec 2015, Ian Campbell wrote:
> Stefano, Anthony: The debian-di-install failure has "error: Unknown driver
> 'vhd'" in the qemu-log. It turns out this has previously been bisected and
> blamed on:
>
>   commit 3fb401edbd8e9741c611bfddf6a2032ca91f55ed
>   Merge: a44c280 816609b
>   Author: Stefano Stabellini 
>   Date:   Mon Nov 23 16:55:36 2015 +
>
>   Merge remote-tracking branch 'qemu-xen/staging' into qemu-xen-4.7

This patch should fix the QEMU vhd issue:

http://marc.info/?i=alpine.DEB.2.02.1512041435110.24652%40kaball.uk.xensource.com___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3] x86/VPMU: Support only versions 2 through 4 of architectural performance monitoring

[Jan Beulich]

>>> On 04.12.15 at 15:07,  wrote:
> We need to have at least version 2 since it's the first version to
> support various control and status registers (such as
> MSR_CORE_PERF_GLOBAL_CTRL) that VPMU relies on always having.
> 
> We don't fully emulate version 4 but since it's back compatible with
> earlier versions we can fall back to v3. At this point there is no
> compatibility statement for v5 so anything above 4 is not supported.
> 
> For guests querying PMU version via CPUID leaf 0xa clip it at v3.
> 
> With explicit testing for PMU version we can now remove CPUID model
> check.
> 
> Signed-off-by: Boris Ostrovsky 

Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v3] x86: Fixup IRQs when CPUs go down during shutdown

[Andrew Cooper]

On 04/12/15 14:01, Ross Lagerwall wrote:
> Commit fc0c3fa2ad5c ("x86/IO-APIC: fix setup of Xen internally used IRQs
> (take 2)") introduced a regression on some hardware where Xen would hang
> during shutdown, repeating the following message:
> APIC error on CPU0: 08(08), Receive accept error
>
> This appears to be because an interrupt (in this case from the serial
> console) destined for a CPU other than the boot CPU is left unhandled so
> an APIC error on CPU 0 is generated instead.
>
> To fix this, before taking down the non-boot CPUs, call fixup_irqs()
> with a CPU mask of only the boot CPU to reset the IRQ affinities
> correctly.
>
> Signed-off-by: Ross Lagerwall 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [OSSTEST PATCH] production-config-cambridge: Use new squid proxy

[Ian Jackson]

Ian Campbell writes ("Re: [OSSTEST PATCH] production-config-cambridge: Use new 
squid proxy"):
> Do you want to go pretest in Cambridge then merge back to colo or do you
> want to push it to the colo and let it flow through in time?

I don't care all that much.

Ian.

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

Re: [Xen-devel] [libvirt test] 65324: regressions - FAIL

[Ian Campbell]

On Fri, 2015-12-04 at 14:43 +, Stefano Stabellini wrote:
> On Fri, 4 Dec 2015, Ian Campbell wrote:
> > Stefano, Anthony: The debian-di-install failure has "error: Unknown
> > driver
> > 'vhd'" in the qemu-log. It turns out this has previously been bisected
> > and
> > blamed on:
> > 
> >   commit 3fb401edbd8e9741c611bfddf6a2032ca91f55ed
> >   Merge: a44c280 816609b
> >   Author: Stefano Stabellini 
> >   Date:   Mon Nov 23 16:55:36 2015 +
> > 
> >   Merge remote-tracking branch 'qemu-xen/staging' into qemu-xen-4.7
> 
> This patch should fix the QEMU vhd issue:
> 
> http://marc.info/?i=alpine.DEB.2.02.1512041435110.24652%40kaball.uk.xenso
> urce.com

OOI what causes it?


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

Re: [Xen-devel] [libvirt test] 65324: regressions - FAIL

[Ian Jackson]

Ian Campbell writes ("Re: [libvirt test] 65324: regressions - FAIL"):
> See which went to 
> xen-devel + osstest-output but for some reason is in

That message had a complete git log of all the changes being merged,
so was massive.  Now there is a length limit.

Ian.

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

Re: [Xen-devel] [PATCH OSSTEST] standalone: Log things we are running via with_logging

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH OSSTEST] standalone: Log things we are running 
via with_logging"):
> On Thu, 2015-12-03 at 16:41 +, Ian Jackson wrote:
> > It's not clear to me from the context whether $@ might contain things
> > which would require quoting.
...
> Are you worried about things being incorrectly expanded in the evaluation
> of the echo, or just about being able to cut and paste a command directly
> from this output into a shell? (or something else).

The latter, but also ambiguity in the debug output which might confuse
a human reader.

> FWIW $@ is unlikely any $vars at this point or to contain spaces, quotes or
> other special characters, although it's not totally impossible (it would
> require job names, or idents, or ts-script arguments etc with such in
> them).

I would prefer to do this properly if it's in a generic logging
subfunction.

> > You can perhaps do something like this
> >    bash -xc ': standalone-runs "$@"' x "$@" >&2
> > ?  (Sadly -n suppresses output from -x too.)
> 
> Sadly it also spews the contents of my .bashrc too. Weirdly (?) adding --
> norc _and_ --noprofile to the mix doesn't change that, which seems rather
> contrary to the manpage.

Urgh.

> This seems to work:
> 
> $ bash -c 'set -x ; : standalone-runs: "$@"' x "foo" "bar bar"
> + : standalone-runs: foo 'bar bar'
> 
> And this: (set -x ; : "$@") also looks to DTRT:
> 
> $ foo() { (set -x ; : "$@") }
> $ foo "foo" "bar bar"
> + : foo 'bar bar'

Either of these would suit me.  The latter seems tidier.

> coreutils' printf(1) also has %q, but it's a bit ugly to use and is
> backslashy rather than quoting :
> $ printf "%q " "foo bar" "baz" ; echo
> foo\ bar baz 

The output from -x is nicer, indeed.

Ian.

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

Re: [Xen-devel] [PATCH OSSTEST] cr-try-bisect-adhoc: Set OSSTEST_PRIORITY=-30

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST] cr-try-bisect-adhoc: Set 
OSSTEST_PRIORITY=-30"):
> This makes adhoc bisects slightly more important than smoke tests, on
> the basis that a smoke test can choose another host while an adhoc
> bisect cannot.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [libvirt test] 65324: regressions - FAIL

[Stefano Stabellini]

On Fri, 4 Dec 2015, Ian Campbell wrote:
> On Fri, 2015-12-04 at 14:43 +, Stefano Stabellini wrote:
> > On Fri, 4 Dec 2015, Ian Campbell wrote:
> > > Stefano, Anthony: The debian-di-install failure has "error: Unknown
> > > driver
> > > 'vhd'" in the qemu-log. It turns out this has previously been bisected
> > > and
> > > blamed on:
> > >
> > >   commit 3fb401edbd8e9741c611bfddf6a2032ca91f55ed
> > >   Merge: a44c280 816609b
> > >   Author: Stefano Stabellini 
> > >   Date:   Mon Nov 23 16:55:36 2015 +
> > >
> > >   Merge remote-tracking branch 'qemu-xen/staging' into qemu-xen-4.7
> >
> > This patch should fix the QEMU vhd issue:
> >
> > http://marc.info/?i=alpine.DEB.2.02.1512041435110.24652%40kaball.uk.xenso
> > urce.com
>
> OOI what causes it?

libxl passes "vhd" when actually "vpc" is the correct string to match
the right driver in QEMU. Secondly QEMU has become more stringent in how
format recognition is done and given that the user is passing a driver
name ("vhd", which is wrong), it is not going to try to guess the right
driver for the image anymore.

In other words, it used to work by "accident".___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv1] x86: rtc_cmos platform device requires legacy irqs

[David Vrabel]

On 04/12/15 14:06, David Vrabel wrote:
> On 03/12/15 10:43, David Vrabel wrote:
>> Adding the rtc platform device when there are no legacy irqs (no
>> legacy PIC) causes a conflict with other devices that end up using the
>> same irq number.
> 
> An alternative is to remove the rtc_cmos platform device in Xen PV
> guests.
> 
> Any preference on how this regression should be fixed?
> 
> David
> 
> 8<--
> x86: Xen PV guests don't have the rtc_cmos platform device
> 
[...]
> --- a/arch/x86/kernel/rtc.c
> +++ b/arch/x86/kernel/rtc.c
> @@ -200,6 +200,9 @@ static __init int add_rtc_cmos(void)
>   }
>  #endif
>  
> + if (xen_pv_domain())
> + return -ENODEV;
> +

Note there's a missing include that breaks !XEN builds.

David

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

Re: [Xen-devel] [libvirt test] 65324: regressions - FAIL

[Ian Campbell]

On Fri, 2015-12-04 at 15:14 +, Stefano Stabellini wrote:
> On Fri, 4 Dec 2015, Ian Campbell wrote:
> > On Fri, 2015-12-04 at 14:43 +, Stefano Stabellini wrote:
> > > On Fri, 4 Dec 2015, Ian Campbell wrote:
> > > > Stefano, Anthony: The debian-di-install failure has "error: Unknown
> > > > driver
> > > > 'vhd'" in the qemu-log. It turns out this has previously been
> > > > bisected
> > > > and
> > > > blamed on:
> > > > 
> > > >   commit 3fb401edbd8e9741c611bfddf6a2032ca91f55ed
> > > >   Merge: a44c280 816609b
> > > >   Author: Stefano Stabellini 
> > > >   Date:   Mon Nov 23 16:55:36 2015 +
> > > > 
> > > >   Merge remote-tracking branch 'qemu-xen/staging' into qemu-
> > > > xen-4.7
> > > 
> > > This patch should fix the QEMU vhd issue:
> > > 
> > > http://marc.info/?i=alpine.DEB.2.02.1512041435110.24652%40kaball.uk.x
> > > enso
> > > urce.com
> > 
> > OOI what causes it?
> 
> libxl passes "vhd" when actually "vpc" is the correct string to match
> the right driver in QEMU. Secondly QEMU has become more stringent in how
> format recognition is done and given that the user is passing a driver
> name ("vhd", which is wrong), it is not going to try to guess the right
> driver for the image anymore.
> 
> In other words, it used to work by "accident".

Thanks for the explanation.

Ian.

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

Re: [Xen-devel] [PATCH QEMU-XEN v6 5/8] xen: Switch uses of xc_map_foreign_{pages, bulk} to use libxenforeignmemory API.

[Stefano Stabellini]

On Thu, 3 Dec 2015, Ian Campbell wrote:
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 2cadd4f..8fbaf07 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -41,6 +41,7 @@ static inline void *xc_map_foreign_bulk(int xc_handle, 
> uint32_t dom, int prot,
>  typedef int XenXC;
>  typedef int xenevtchn_handle;
>  typedef int xengnttab_handle;
> +typedef int xenforeignmemory_handle;
>  
>  #  define XC_INTERFACE_FMT "%i"
>  #  define XC_HANDLER_INITIAL_VALUE-1
> @@ -104,6 +105,19 @@ static inline XenXC xen_xc_interface_open(void *logger, 
> void *dombuild_logger,
>  return xc_interface_open();
>  }
>  
> +#define xenforeignmemory_open(l, f) &xen_xc
> +static inline void *xenforeignmemory_map(XenXC *h, uint32_t dom,
> + int prot, size_t pages,
> + const xen_pfn_t arr[/*pages*/],
> + int err[/*pages*/])
> +{
> +if (err)
> +return xc_map_foreign_bulk(*h, dom, prot, arr, err, pages);
> +else
> +return xc_map_foreign_pages(*h, dom, prot, arr, pages);
> +}
> +#define xenforeignmemory_unmap(h, p, s) munmap(p, s * XC_PAGE_SIZE)
> +
>  static inline int xc_fd(int xen_xc)
>  {
>  return xen_xc;
> @@ -149,6 +163,7 @@ static inline void xs_close(struct xs_handle *xsh)
>  #else
>  
>  typedef xc_interface *XenXC;
> +typedef xc_interface *xenforeignmemory_handle;
>  typedef xc_evtchn xenevtchn_handle;
>  typedef xc_gnttab xengnttab_handle;
>  
> @@ -178,6 +193,20 @@ static inline XenXC xen_xc_interface_open(void *logger, 
> void *dombuild_logger,
>  return xc_interface_open(logger, dombuild_logger, open_flags);
>  }
>  
> +#define xenforeignmemory_open(l, f) &xen_xc
> +static inline void *xenforeignmemory_map(XenXC *h, uint32_t dom,
> + int prot, size_t pages,
> + const xen_pfn_t arr[/*pages*/],
> + int err[/*pages*/])
> +{
> +if (err)
> +return xc_map_foreign_bulk(*h, dom, prot, arr, err, pages);
> +else
> +return xc_map_foreign_pages(*h, dom, prot, arr, pages);
> +}
> +
> +#define xenforeignmemory_unmap(h, p, s) munmap(p, s * XC_PAGE_SIZE)
> +
>  /* FIXME There is now way to have the xen fd */
>  static inline int xc_fd(xc_interface *xen_xc)
>  {

The two definitions are the same. Please introduce just one, at the
bottom under the ifdef CONFIG_XEN_CTRL_INTERFACE_VERSION < 470 case.

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

[Xen-devel] [PATCH v2 8/8] treewide: Remove newlines inside DEFINE_PER_CPU() macros

[Michal Marek]

Otherwise make tags can't parse them:

ctags: Warning: arch/ia64/kernel/smp.c:60: null expansion of name pattern "\1"
ctags: Warning: drivers/xen/events/events_2l.c:41: null expansion of name 
pattern "\1"
ctags: Warning: drivers/acpi/processor_idle.c:64: null expansion of name 
pattern "\1"
ctags: Warning: kernel/locking/lockdep.c:153: null expansion of name pattern 
"\1"
ctags: Warning: kernel/workqueue.c:305: null expansion of name pattern "\1"
ctags: Warning: kernel/rcu/rcutorture.c:133: null expansion of name pattern "\1"
ctags: Warning: kernel/rcu/rcutorture.c:135: null expansion of name pattern "\1"
ctags: Warning: net/rds/page.c:45: null expansion of name pattern "\1"
ctags: Warning: net/ipv4/syncookies.c:53: null expansion of name pattern "\1"
ctags: Warning: net/ipv6/syncookies.c:44: null expansion of name pattern "\1"

Cc: linux-i...@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
Cc: linux-a...@vger.kernel.org
Cc: rds-de...@oss.oracle.com
Cc: net...@vger.kernel.org
Signed-off-by: Michal Marek 
---
v2: No change

 arch/ia64/kernel/smp.c | 3 +--
 drivers/acpi/processor_idle.c  | 3 +--
 drivers/xen/events/events_2l.c | 3 +--
 kernel/locking/lockdep.c   | 3 +--
 kernel/rcu/rcutorture.c| 6 ++
 kernel/workqueue.c | 3 +--
 net/ipv4/syncookies.c  | 3 +--
 net/ipv6/syncookies.c  | 3 +--
 net/rds/page.c | 3 +--
 9 files changed, 10 insertions(+), 20 deletions(-)

diff --git a/arch/ia64/kernel/smp.c b/arch/ia64/kernel/smp.c
index 7f706d4f84f7..1dcfe29d8a42 100644
--- a/arch/ia64/kernel/smp.c
+++ b/arch/ia64/kernel/smp.c
@@ -57,8 +57,7 @@ static struct local_tlb_flush_counts {
unsigned int count;
 } __attribute__((__aligned__(32))) local_tlb_flush_counts[NR_CPUS];
 
-static DEFINE_PER_CPU_SHARED_ALIGNED(unsigned short [NR_CPUS],
-shadow_flush_counts);
+static DEFINE_PER_CPU_SHARED_ALIGNED(unsigned short [NR_CPUS], 
shadow_flush_counts);
 
 #define IPI_CALL_FUNC  0
 #define IPI_CPU_STOP   1
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 175c86bee3a9..16ca18547370 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -61,8 +61,7 @@ module_param(latency_factor, uint, 0644);
 
 static DEFINE_PER_CPU(struct cpuidle_device *, acpi_cpuidle_device);
 
-static DEFINE_PER_CPU(struct acpi_processor_cx * [CPUIDLE_STATE_MAX],
-   acpi_cstate);
+static DEFINE_PER_CPU(struct acpi_processor_cx * [CPUIDLE_STATE_MAX], 
acpi_cstate);
 
 static int disabled_by_idle_boot_param(void)
 {
diff --git a/drivers/xen/events/events_2l.c b/drivers/xen/events/events_2l.c
index 7dd46312c180..7ffed4c62434 100644
--- a/drivers/xen/events/events_2l.c
+++ b/drivers/xen/events/events_2l.c
@@ -38,8 +38,7 @@
 /* Find the first set bit in a evtchn mask */
 #define EVTCHN_FIRST_BIT(w) find_first_bit(BM(&(w)), BITS_PER_EVTCHN_WORD)
 
-static DEFINE_PER_CPU(xen_ulong_t [EVTCHN_2L_NR_CHANNELS/BITS_PER_EVTCHN_WORD],
- cpu_evtchn_mask);
+static DEFINE_PER_CPU(xen_ulong_t 
[EVTCHN_2L_NR_CHANNELS/BITS_PER_EVTCHN_WORD], cpu_evtchn_mask);
 
 static unsigned evtchn_2l_max_channels(void)
 {
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 60ace56618f6..96e5300fdf4b 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -150,8 +150,7 @@ static inline struct lock_class *hlock_class(struct 
held_lock *hlock)
 }
 
 #ifdef CONFIG_LOCK_STAT
-static DEFINE_PER_CPU(struct lock_class_stats[MAX_LOCKDEP_KEYS],
- cpu_lock_stats);
+static DEFINE_PER_CPU(struct lock_class_stats[MAX_LOCKDEP_KEYS], 
cpu_lock_stats);
 
 static inline u64 lockstat_clock(void)
 {
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index adbb194e2b5d..3504c6e5b641 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -130,10 +130,8 @@ static struct rcu_torture __rcu *rcu_torture_current;
 static unsigned long rcu_torture_current_version;
 static struct rcu_torture rcu_tortures[10 * RCU_TORTURE_PIPE_LEN];
 static DEFINE_SPINLOCK(rcu_torture_lock);
-static DEFINE_PER_CPU(long [RCU_TORTURE_PIPE_LEN + 1],
- rcu_torture_count) = { 0 };
-static DEFINE_PER_CPU(long [RCU_TORTURE_PIPE_LEN + 1],
- rcu_torture_batch) = { 0 };
+static DEFINE_PER_CPU(long [RCU_TORTURE_PIPE_LEN + 1], rcu_torture_count) = { 
0 };
+static DEFINE_PER_CPU(long [RCU_TORTURE_PIPE_LEN + 1], rcu_torture_batch) = { 
0 };
 static atomic_t rcu_torture_wcount[RCU_TORTURE_PIPE_LEN + 1];
 static atomic_t n_rcu_torture_alloc;
 static atomic_t n_rcu_torture_alloc_fail;
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index c579dbab2e36..4111c5b9ba0c 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -302,8 +302,7 @@ static bool workqueue_freezing; /* PL: have wqs 
started freezing? */
 static cpumask_var_t wq_unbound_cpumas

Re: [Xen-devel] [PATCH QEMU-XEN v6 4/8] xen: Switch uses of xc_map_foreign_range into xc_map_foreign_pages

[Stefano Stabellini]

On Thu, 3 Dec 2015, Ian Campbell wrote:
> In Xen 4.7 we are refactoring parts libxenctrl into a number of
> separate libraries which will provide backward and forward API and ABI
> compatiblity.
> 
> One such library will be libxenforeignmemory which provides access to
> privileged foreign mappings and which will provide an interface
> equivalent to xc_map_foreign_{pages,bulk}.
> 
> In preparation for this switch all uses of xc_map_foreign_range to
> xc_map_foreign_pages. This is trivial because size was always
> XC_PAGE_SIZE so the necessary adjustments are trivial:
> 
>   * Pass &mfn (an array of length 1) instead of mfn. The function
> takes a pointer to const, so there is no possibily of mfn changing
> due to this change.
>   * Pass nr_pages=1 instead of size=XC_PAGE_SIZE
> 
> There is one wrinkle in xen_console.c:con_initialise() where
> con->ring_ref is an int but can in some code paths (when !xendev->dev)
> be treated as an mfn. I think this is an existing latent truncation
> hazard on platforms where xen_pfn_t is 64-bit and int is 32-bit (e.g.
> amd64, both arm* variants). I'm unsure under what circumstances
> xendev->dev can be NULL or if anything elsewhere ensures the value
> fits into an int. For now I just use a temporary xen_pfn_t to in
> effect upcast the pointer from int* to xen_pfn_t*.
> 
> Signed-off-by: Ian Campbell 

Reviewed-by: Stefano Stabellini 


> v6: Switch to xc_map_foreign_pages rather than _bulk. Switching to
> _bulk without checking the value of err[0] risked missing errors.
> The new xenforeignmemory_map coming later in this series will
> DTRT with err==NULL.
> 
> Dropped Stefano's Reviewed-by due to this change.
> 
> v4: Ran checkpatch, fixed all errors
> Mention the const-ness of the mfn array in the commit log
> ---
>  hw/char/xen_console.c |  8 
>  hw/display/xenfb.c|  5 ++---
>  xen-hvm.c | 14 +++---
>  3 files changed, 13 insertions(+), 14 deletions(-)
> 
> diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
> index 8c06c19..56f1b1a 100644
> --- a/hw/char/xen_console.c
> +++ b/hw/char/xen_console.c
> @@ -228,10 +228,10 @@ static int con_initialise(struct XenDevice *xendev)
>   con->buffer.max_capacity = limit;
>  
>  if (!xendev->dev) {
> -con->sring = xc_map_foreign_range(xen_xc, con->xendev.dom,
> -  XC_PAGE_SIZE,
> -  PROT_READ|PROT_WRITE,
> -  con->ring_ref);
> +xen_pfn_t mfn = con->ring_ref;
> +con->sring = xc_map_foreign_pages(xen_xc, con->xendev.dom,
> + PROT_READ|PROT_WRITE,
> + &mfn, 1);
>  } else {
>  con->sring = xengnttab_map_grant_ref(xendev->gnttabdev, 
> con->xendev.dom,
>   con->ring_ref,
> diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> index 5e324ef..c96d974 100644
> --- a/hw/display/xenfb.c
> +++ b/hw/display/xenfb.c
> @@ -104,9 +104,8 @@ static int common_bind(struct common *c)
>  if (xenstore_read_fe_int(&c->xendev, "event-channel", 
> &c->xendev.remote_port) == -1)
>   return -1;
>  
> -c->page = xc_map_foreign_range(xen_xc, c->xendev.dom,
> -XC_PAGE_SIZE,
> -PROT_READ | PROT_WRITE, mfn);
> +c->page = xc_map_foreign_pages(xen_xc, c->xendev.dom,
> +   PROT_READ | PROT_WRITE, &mfn, 1);
>  if (c->page == NULL)
>   return -1;
>  
> diff --git a/xen-hvm.c b/xen-hvm.c
> index 6680782..2f4e109 100644
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -1240,8 +1240,9 @@ int xen_hvm_init(PCMachineState *pcms,
>  DPRINTF("buffered io page at pfn %lx\n", bufioreq_pfn);
>  DPRINTF("buffered io evtchn is %x\n", bufioreq_evtchn);
>  
> -state->shared_page = xc_map_foreign_range(xen_xc, xen_domid, 
> XC_PAGE_SIZE,
> -  PROT_READ|PROT_WRITE, 
> ioreq_pfn);
> +state->shared_page = xc_map_foreign_pages(xen_xc, xen_domid,
> +  PROT_READ|PROT_WRITE,
> +  &ioreq_pfn, 1);
>  if (state->shared_page == NULL) {
>  hw_error("map shared IO page returned error %d handle=" 
> XC_INTERFACE_FMT,
>   errno, xen_xc);
> @@ -1251,8 +1252,8 @@ int xen_hvm_init(PCMachineState *pcms,
>  if (!rc) {
>  DPRINTF("shared vmport page at pfn %lx\n", ioreq_pfn);
>  state->shared_vmport_page =
> -xc_map_foreign_range(xen_xc, xen_domid, XC_PAGE_SIZE,
> - PROT_READ|PROT_WRITE, ioreq_pfn);
> +xc_map_foreign_pages(xen_xc, xen_domid, PROT_READ|PROT_WRITE,
> + &ioreq_pfn, 1);
>  if (state->shared_vmport_page == NULL) {
>  hw_error("map sha

[Xen-devel] [PATCH OSSTEST v2] standalone: Log things we are running via with_logging

[Ian Campbell]

Turning on set -x generally in this script is too verbose, so run the
command in a subshell which sets -x.

Signed-off-by: Ian Campbell 
---
v2: Use set -x in a sub shell
---
 standalone | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/standalone b/standalone
index c804b74..499cb6c 100755
--- a/standalone
+++ b/standalone
@@ -195,7 +195,7 @@ with_logging() {
 if command -v savelog >/dev/null ; then
 savelog -c 300 -n "$log" >/dev/null
 fi
-"$@" 2>&1 | tee "$log"
+( set -x ; "$@" ) 2>&1 | tee "$log"
 rc=${PIPESTATUS[0]}
 if [ $rc -ne 0 ] ; then
echo "FAILED rc=${rc}" >&2
-- 
2.6.1


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

Re: [Xen-devel] [PATCHv1] x86: rtc_cmos platform device requires legacy irqs

[Boris Ostrovsky]

On 12/04/2015 10:24 AM, David Vrabel wrote:

On 04/12/15 14:06, David Vrabel wrote:

On 03/12/15 10:43, David Vrabel wrote:

Adding the rtc platform device when there are no legacy irqs (no
legacy PIC) causes a conflict with other devices that end up using the
same irq number.

An alternative is to remove the rtc_cmos platform device in Xen PV
guests.

Any preference on how this regression should be fixed?

David

8<--
x86: Xen PV guests don't have the rtc_cmos platform device


[...]

--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -200,6 +200,9 @@ static __init int add_rtc_cmos(void)
}
  #endif
  
+	if (xen_pv_domain())

+   return -ENODEV;
+

Note there's a missing include that breaks !XEN builds.


We could also use paravirt_enable() here which will probably cover 
HVMlite case as well. (Until we start turning on and off various HVMlite 
features).


Don't know how it will affect lguest (which so far is the only other 
paravirt-enabled guest).


-boris

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

Re: [Xen-devel] [PATCH QEMU-XEN v6 6/8] xen: Use stable library interfaces when they are available.

[Stefano Stabellini]

On Thu, 3 Dec 2015, Ian Campbell wrote:
> In Xen 4.7 we are refactoring parts libxenctrl into a number of
> separate libraries which will provide backward and forward API and ABI
> compatiblity.
> 
> Specifically libxenevtchn, libxengnttab and libxenforeignmemory.
> 
> Previous patches have already laid the groundwork for using these by
> switching the existing compatibility shims to reflect the intefaces to
> these libraries.
> 
> So all which remains is to update configure to detect the libraries
> and enable their use. Although they are notionally independent we take
> an all or nothing approach to the three libraries since they were
> added at the same time.
> 
> The only non-obvious bit is that we now open a proper xenforeignmemory
> handle for xen_fmem instead of reusing the xen_xc handle.
> 
> Build tested with 4.0 .. 4.6 (inclusive) and the patches targetting
> 4.7 which adds these libraries.
> 
> Signed-off-by: Ian Campbell 

Reviewed-by: Stefano Stabellini 


> v6: Two minor formatting things.
> Rebase onto "xen: fix usage of xc_domain_create in domain
> builder", required adjusting the configure script changes.
> 
> The rebase wasn't entirely trivial (semantically), so dropped
> Stefano's reviwed by.
> 
> v5: Remove ifdef check when undeffing the compat stuff.
> s/now way/no way/
> 
> v4: xenforeignmemory_open is now a compat wrapper, so no ifdef.
> 
> Simplify configury by asserting that interface version 470 will
> always have the libraries (lack of them makes it 460).
> 
> Ran checkpatch and fixed everything except:
> 
> ERROR: need consistent spacing around '*' (ctx:WxV)
> +typedef xc_interface *XenXC;
> 
> Which I think is a false +ve.
> 
> Simpler configure stuff
> ---
>  configure   | 42 +-
>  include/hw/xen/xen_common.h | 35 +--
>  2 files changed, 74 insertions(+), 3 deletions(-)
> 
> diff --git a/configure b/configure
> index 979bc55..cb72115 100755
> --- a/configure
> +++ b/configure
> @@ -1923,6 +1923,7 @@ fi
>  
>  if test "$xen" != "no" ; then
>xen_libs="-lxenstore -lxenctrl -lxenguest"
> +  xen_stable_libs="-lxenforeignmemory -lxengnttab -lxenevtchn"
>  
># First we test whether Xen headers and libraries are available.
># If no, we are done and there is no Xen support.
> @@ -1945,16 +1946,52 @@ EOF
># Xen unstable
>elif
>cat > $TMPC < +/*
> + * If we have stable libs the we don't want the libxc compat
> + * layers, regardless of what CFLAGS we may have been given.
> + */
> +#undef XC_WANT_COMPAT_EVTCHN_API
> +#undef XC_WANT_COMPAT_GNTTAB_API
> +#undef XC_WANT_COMPAT_MAP_FOREIGN_API
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
>  #include 
> +#include 
> +#if !defined(HVM_MAX_VCPUS)
> +# error HVM_MAX_VCPUS not defined
> +#endif
>  int main(void) {
>xc_interface *xc = NULL;
> +  xenforeignmemory_handle *xfmem;
> +  xenevtchn_handle *xe;
> +  xengnttab_handle *xg;
>xen_domain_handle_t handle;
> +
> +  xs_daemon_open();
> +
> +  xc = xc_interface_open(0, 0, 0);
> +  xc_hvm_set_mem_type(0, 0, HVMMEM_ram_ro, 0, 0);
> +  xc_domain_add_to_physmap(0, 0, XENMAPSPACE_gmfn, 0, 0);
> +  xc_hvm_inject_msi(xc, 0, 0xf000, 0x);
> +  xc_hvm_create_ioreq_server(xc, 0, HVM_IOREQSRV_BUFIOREQ_ATOMIC, NULL);
>xc_domain_create(xc, 0, handle, 0, NULL, NULL);
> +
> +  xfmem = xenforeignmemory_open(0, 0);
> +  xenforeignmemory_map(xfmem, 0, 0, 0, 0, 0);
> +
> +  xe = xenevtchn_open(0, 0);
> +  xenevtchn_fd(xe);
> +
> +  xg = xengnttab_open(0, 0);
> +  xengnttab_map_grant_ref(xg, 0, 0, 0);
> +
>return 0;
>  }
>  EOF
> -  compile_prog "" "$xen_libs"
> +  compile_prog "" "$xen_libs $xen_stable_libs"
>  then
>  xen_ctrl_version=470
>  xen=yes
> @@ -2138,6 +2175,9 @@ EOF
>fi
>  
>if test "$xen" = yes; then
> +if test $xen_ctrl_version -ge 470  ; then
> +  libs_softmmu="$xen_stable_libs $libs_softmmu"
> +fi
>  libs_softmmu="$xen_libs $libs_softmmu"
>fi
>  fi
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 8fbaf07..884fbd1 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -6,6 +6,15 @@
>  #include 
>  #include 
>  
> +/*
> + * If we have new enough libxenctrl then we do not want/need these compat
> + * interfaces, despite what the user supplied cflags might say. They
> + * must be undefined before including xenctrl.h
> + */
> +#undef XC_WANT_COMPAT_EVTCHN_API
> +#undef XC_WANT_COMPAT_GNTTAB_API
> +#undef XC_WANT_COMPAT_MAP_FOREIGN_API
> +
>  #include 
>  #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 420
>  #  include 
> @@ -159,8 +168,8 @@ static inline void xs_close(struct xs_handle *xsh)
>  }
>  
>  
> -/* Xen 4.1 */
> -#else
> +/* Xen 4.1 thru 4.6 */
> +#elif CONFIG_XEN_CTRL_INTERFACE_VERSION < 470
>  
>  typedef xc_interface *XenXC;
>  typedef xc_interface *xenforeignmemory_handle;
> @@ -207,6 +216,28 @@ stati

Re: [Xen-devel] [PATCHv1] x86: rtc_cmos platform device requires legacy irqs

[Vitaly Kuznetsov]

Boris Ostrovsky  writes:

> On 12/04/2015 10:24 AM, David Vrabel wrote:
>> On 04/12/15 14:06, David Vrabel wrote:
>>> On 03/12/15 10:43, David Vrabel wrote:
 Adding the rtc platform device when there are no legacy irqs (no
 legacy PIC) causes a conflict with other devices that end up using the
 same irq number.
>>> An alternative is to remove the rtc_cmos platform device in Xen PV
>>> guests.
>>>
>>> Any preference on how this regression should be fixed?
>>>
>>> David
>>>
>>> 8<--
>>> x86: Xen PV guests don't have the rtc_cmos platform device
>>>
>> [...]
>>> --- a/arch/x86/kernel/rtc.c
>>> +++ b/arch/x86/kernel/rtc.c
>>> @@ -200,6 +200,9 @@ static __init int add_rtc_cmos(void)
>>> }
>>>   #endif
>>>   + if (xen_pv_domain())
>>> +   return -ENODEV;
>>> +
>> Note there's a missing include that breaks !XEN builds.
>
> We could also use paravirt_enable() here which will probably cover
> HVMlite case as well. (Until we start turning on and off various
> HVMlite features).

Would it make sense to create a new abstraction, e.g. 'rtc_available' in
struct hypervisor_x86?

-- 
  Vitaly

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail baseline 
untested
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 64579

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-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-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-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 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-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   never pass

version targeted for testing:
 qemuu4c65fed8bdf96780735dbdb92a8bd0d6b6526cc3
baseline version:
 qemuu9be060f5278dc0d732ebfcf2bf0a293f88b833eb

Last test of basis64579  2015-11-17 15:37:49 Z   17 days
Failing since 64797  2015-11-19 03:03:30 Z   15 days   15 attempts
Testing same since65346  2015-12-04 01:01:26 Z0 days1 attempts


People who touched revisions under test:
  "Dr. David Alan Gilbert" 
  "Eugene (jno) Dvurechenski" 
  Alberto Garcia 
  Alistair Francis 
  Andreas Färber 
  Andrew Baumann 
  Anthony PERARD 
  Aurelien Jarno 
  Bandan Das 
  Christian Borntraeger 
  Cornelia Huck 
  Daniel P. Berrange 
  David Gibson 
  Denis V. Lunev 
  Don Slutz 
  Dr. David Alan Gilbert 
  Eduardo Habkost 
  Eric Blake 
  Eugene (jno) Dvurechenski 
  Fam Zheng 
  François Baldassari 
  Gerd Hoffmann 
  Greg Kurz 
  Hervé Poussineau 
  Ildar Isaev 
  James Hogan 
  Jason J. Herne 
  Jason Wang 
  Jeff Cody 
  John Arbuckle 
  John Clarke 
  John Snow 
  Juan Quintela 
  Kevin Wolf 
  Leon Alrae 
  Madhavan Srinivasan 
  Marc-André Lureau 
  Marcel Apfelbaum 
  Markus Armbruster 
  Max Reitz 
  Michael Roth 
  Michael S. Tsirkin 
  Paolo Bonzini 
  Pavel Fedin 
  Peter Lieven 
  Peter Maydell 
  Prasad J Pandit 
  Programmingkid 
  Rabin Vincent 
  Ricard Wanderlof 
  Ricard Wanderlöf 
  Richard Henderson 
  Rik van Riel 
  Roger Pau Monne 
  Roger Pau Monné 
  Sergey Fedorov 
  Shmulik Ladkani 
  Stefan Hajnoczi 
  Stefan Weil 
  Stefano Dong (董兴水) 
  Stefano Stabellini 
  Thomas Huth 
  Victor Kaplansky 
  Vladimir Sementsov-Ogievskiy 
  Wen Congyang 
  Yi Min Zhao 
  Yuanhan Liu 
  Yuri Pudgorodskiy 

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

Re: [Xen-devel] [PATCH] xen_pt: fix failure of attaching & detaching a PCI device to VM repeatedly

[Stefano Stabellini]

On Thu, 3 Dec 2015, Jianzhong,Chang wrote:
> From: jianzhong,Chang 
> 
> Add pci = [ '$VF_BDF', '$VF_BDF', '$VF_BDF'] in

This is a bit confusing: it is not actually correct to assign the same
device, even an SR_IOV VF, multiple times, so these must be all
different. More like:

pci = [ '$VF_BDF1', '$VF_BDF2', '$VF_BDF3']


> hvm guest configuration file. After the guest boot up,
> detach the VFs in sequence by "xl pci-detach $DOMID $VF_BDF",
> reattach the VFs by "xl pci-attach $VF_BDF" in sequence.

So do you mean:

xl pci-detach $DOMID $VF_BDF1
xl pci-detach $DOMID $VF_BDF2
xl pci-detach $DOMID $VF_BDF3
xl pci-attach $DOMID $VF_BDF1
xl pci-attach $DOMID $VF_BDF2
xl pci-attach $DOMID $VF_BDF3

?


> An error message will be reported like this:
> "libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received
> an error message from QMP server: Duplicate ID 'pci-pt-07_10.1' for device"
> 
> When xen_pt_region_add/del() is called, MemoryRegion
> may not belong to the XenPCIPassthroughState.
> xen_pt_region_update() checks it but memory_region_ref/unref() does not.
> This case causes obj->ref issue and affects the release of related objects.
> So, the detection operation is moved from
> xen_pt_region_update to xen_pt_region_add/del.
> 
> Signed-off-by: Jianzhong,Chang 
> ---
>  hw/xen/xen_pt.c |   23 ---
>  1 files changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
> index aa96288..95b4970 100644
> --- a/hw/xen/xen_pt.c
> +++ b/hw/xen/xen_pt.c
> @@ -523,6 +523,14 @@ static int xen_pt_bar_from_region(XenPCIPassthroughState 
> *s, MemoryRegion *mr)
>  }
>  return -1;
>  }
> +static bool xen_pt_region_in_state(XenPCIPassthroughState *s, MemoryRegion 
> *mr)
> +{
> +int bar = xen_pt_bar_from_region(s, mr);
> +if (-1 == bar && (!s->msix || &s->msix->mmio != mr)) {
> +return false;
> +}
> +return true;
> +}
>  
>  /*
>   * This function checks if an io_region overlaps an io_region from another
> @@ -587,9 +595,6 @@ static void xen_pt_region_update(XenPCIPassthroughState 
> *s,
>  };
>  
>  bar = xen_pt_bar_from_region(s, mr);
> -if (bar == -1 && (!s->msix || &s->msix->mmio != mr)) {
> -return;
> -}
>  
>  if (s->msix && &s->msix->mmio == mr) {
>  if (adding) {
> @@ -642,6 +647,9 @@ static void xen_pt_region_add(MemoryListener *l, 
> MemoryRegionSection *sec)
>  XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
>   memory_listener);
>  
> +if (!xen_pt_region_in_state(s, sec->mr)) {
> +return;
> +}
>  memory_region_ref(sec->mr);
>  xen_pt_region_update(s, sec, true);
>  }
> @@ -651,6 +659,9 @@ static void xen_pt_region_del(MemoryListener *l, 
> MemoryRegionSection *sec)
>  XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
>   memory_listener);
>  
> +if (!xen_pt_region_in_state(s, sec->mr)) {
> +return;
> +}
>  xen_pt_region_update(s, sec, false);
>  memory_region_unref(sec->mr);
>  }
> @@ -660,6 +671,9 @@ static void xen_pt_io_region_add(MemoryListener *l, 
> MemoryRegionSection *sec)
>  XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
>   io_listener);
>  
> +if (!xen_pt_region_in_state(s, sec->mr)) {
> +return;
> +}
>  memory_region_ref(sec->mr);
>  xen_pt_region_update(s, sec, true);
>  }
> @@ -669,6 +683,9 @@ static void xen_pt_io_region_del(MemoryListener *l, 
> MemoryRegionSection *sec)
>  XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
>   io_listener);
>  
> +if (!xen_pt_region_in_state(s, sec->mr)) {
> +return;
> +}
>  xen_pt_region_update(s, sec, false);
>  memory_region_unref(sec->mr);
>  }

Wouldn't it make more sense to move the
memory_region_ref/memory_region_unref calls inside xen_pt_region_update?

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

[Xen-devel] Unexpected crashes/reboots of domU on debian with xen 4.6 kernel 4.1.13

[Maarten Coenaerts]

Hi,

I'm having a problem with an Xen 4.6.0 install on debian jessie 8.2 with 
kernel 4.1.13.

Different domU's has been unexpectedly rebooted several times.
DomU's runs debian squeeze and wheezy with 4.1.13 kernel.
Then yesterday a domU (debian squeeze) crashed with following trace in 
xl dmesg:


(XEN) domain_crash_sync called from entry.S: fault at 82d08022a01e 
create_bounce_frame+0x66/0x13a

(XEN) Domain 12 (vcpu#7) crashed on cpu#6:
(XEN) [ Xen-4.6.0  x86_64  debug=n  Not tainted ]
(XEN) CPU:6
(XEN) RIP:e033:[]
(XEN) RFLAGS: 00010206   EM: 0   CONTEXT: pv guest (d12v7)
(XEN) rax: 00ca   rbx: 006e   rcx: 81041530
(XEN) rdx: 0001   rsi: 0081   rdi: 7fc1749baa28
(XEN) rbp: 7fc1734f36b0   rsp: 7fc17fe2ddf5   r8: 7fc1749baa28
(XEN) r9:  0646   r10: 7fc1734f3670   r11: 0206
(XEN) r12: 01f4   r13: 7fc1749baa00   r14: 7fc1749baa28
(XEN) r15: 7fc1749baa50   cr0: 80050033   cr4: 001526e0
(XEN) cr3: 6676   cr2: 7fc17fe2dded
(XEN) ds:    es:    fs:    gs:    ss: e02b   cs: e033
(XEN) Guest stack trace from rsp=7fc17fe2ddf5:
(XEN)841f0fc35e5a 495541544100 ec8348f58949fc89 
c748f631e7894810
(XEN)48d060c0 0003e8bf0824448b 007d8b49e7f74800 
243c2b4808758b49
(XEN)c681480a79c62948 48cfff483b9aca00 243c89483678ff85 
148b410824748948
(XEN)e289491474d28524 00cab8e7894cf631 75003f83050f 
4110c48348c0310b
(XEN)92f88348c35c415d eb006eb88f75 90909090909090ea 
314d525241909090
(XEN)640080f681d2 890048253423 a98000ca81c2 
d0392b754000
(XEN)097517b10ff00674 8b050f00cab8 148b64da75c08507 
00ca8102d025
(XEN)7517b10ff080 66c35a415ac6 841f0f2e 
20d4213d8300
(XEN)894951417574 81b941d2 3423640080f6 
09ce81004825
(XEN)4000a901 ca81c2893c75 0ff00d74c2398000 
00c1c74817b1
(XEN)00cab80b7500 c085078bc189050f 02d025148b641775 
8000ca81
(XEN)5941037517b10ff0 f983057492f983c3 ebd8f7c889b075ea 
9aca00087a8148ed
(XEN)4100d4830f3b 5655415441514150 49fc894920ec8348 
481024448948d589
(XEN)00c0c748f631e789 448b48d06000 4803e8bf0824 
8b49007d8b49e7f7
(XEN)2948243c2b480875 ca00c681480a79c6 ff8548cfff483b9a 
8948008c880f
(XEN)480824748948243c ca81d0891024548b 00a98000 
f00f74c239537540
(XEN)c1c7482414b10f41 89492675 80f6812024748be2 
482534236400
(XEN)cab8e7894c00 c18948050f00 2975c08524048b41 
02d025148b64
(XEN)41f08000ca81 834813752414b10f 59415c415d4128c4 
0016b8c35841
(XEN)ff30850f92f983c3 eb006eb8 90909090909090dd 
25348b645f909090


Today I had another reboot of the domU (debian squeeze) and now I have a 
kernel panic in  the console log.


[79376.951876] general protection fault: febc [#1] SMP
[79376.951885] Modules linked in: rpcsec_gss_krb5 xt_tcpudp xt_limit 
xt_state xt_multiport iptable_filter iptable_nat nf_conntrack_ipv4 
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle ip_tables 
x_tables x86_pkg_temp_thermal thermal_sys coretemp evdev snd_pcm 
snd_timer crct10dif_pclmul crc32_pclmul snd soundcore pcspkr r8168(O) 
crc32c_intel

[79376.951910] CPU: 4 PID: 898 Comm: ntpd Tainted: G   O 4.1.13 #1
[79376.951914] task: 8802e88dee80 ti: 8802eebf8000 task.ti: 
8802eebf8000
[79376.951919] RIP: e030:[] [] 
setup_sigcontext+0xde/0x13f

[79376.951927] RSP: e02b:8802eebfbe30  EFLAGS: 00010246
[79376.951930] RAX: 0246 RBX: 7ffddc51a878 RCX: 

[79376.951933] RDX: 8802eebfbf58 RSI: 7ffddc51aa40 RDI: 
7ffddc51a8a8
[79376.951937] RBP: 8802e88df4b0 R08:  R09: 
88000389df00
[79376.951940] R10: 88000389df00 R11: 0005 R12: 

[79376.951943] R13: 000e R14: 7ffddc51aa40 R15: 
8802eebfbf58
[79376.951949] FS:  7f064a398700() GS:8802f0d0() 
knlGS:8802f0d0

[79376.951953] CS:  e033 DS:  ES:  CR0: 80050033
[79376.951957] CR2: ff600400 CR3: 0002ec1aa000 CR4: 
00042660

[79376.951960] Stack:
[79376.951962]  81047572 0003950ffebe  

[79376.951967]  0340  0042c640 
0400
[79376.951973]  7f0649009230  000e 
0001fffe

[79376.951979] Call Trace:
[79376.951982]  [] ? do_signal+0x332/0x53e
[79376.951987]  [] ? xen_clocksource_read+0x12/0x14
[79376.951990]  [] ? do_notify_resume+0xd/0x48
[79376.951995]  [] ? int_signal+0x12/0x17
[79376.951998] Code: 00 48 8b 80 d8 05 00 00 48 89 87 98 00 00 00 48 8b 
82 80 00 00 00 48 89 87 80 00 00 00 48 8b 82 90 00 00 00 48 89 87 88 00 
00 00 <48> cb 82 88 00 00 00 66 89 87 90 00 00 00 66 c7 87 92 00 00 00

[79376.952027] RIP  [] setup_s

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. 
vs. 63340
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 
63340
 test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 63340

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

version targeted for testing:
 libvirt  dc692438f34b81583673a44f209b9af2abffadfc
baseline version:
 libvirt  3c7590e0a435d833895fc7b5be489e53e223ad95

Last test of basis63340  2015-10-28 04:19:47 Z   37 days
Failing since 63352  2015-10-29 04:20:29 Z   36 days   32 attempts
Testing same since65353  2015-12-04 04:20:01 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Boris Fiuczynski 
  Chen Hanxiao 
  Christian Loehle 
  Cole Robinson 
  Daniel P. Berrange 
  Daniel Veillard 
  Dmitry Andreev 
  Erik Skultety 
  Guido Günther 
  Ian Campbell 
  Jim Fehlig 
  Jiri Denemark 
  Joao Martins 
  John Ferlan 
  Ján Tomko 
  Laine Stump 
  Luyao Huang 
  Marc-André Lureau 
  Martin Kletzander 
  Maxim Perevedentsev 
  Michal Privoznik 
  Michel Normand 
  Mikhail Feoktistov 
  Nikolay Shirokovskiy 
  Pavel Hrdina 
  Peter Krempa 
  Richard Weinberger 
  Roman Bogorodskiy 
  Stefan Berger 
  Stefan Berger 
  Wang Yufei 
  Wei Jiangang 

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-pairfail
 test-amd64-i386-libvirt-pair fail
 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


Not pushing.

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

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

Re: [Xen-devel] [PATCHv1] x86: rtc_cmos platform device requires legacy irqs

[Boris Ostrovsky]

On 12/04/2015 10:52 AM, Vitaly Kuznetsov wrote:

Boris Ostrovsky  writes:


On 12/04/2015 10:24 AM, David Vrabel wrote:

On 04/12/15 14:06, David Vrabel wrote:

On 03/12/15 10:43, David Vrabel wrote:

Adding the rtc platform device when there are no legacy irqs (no
legacy PIC) causes a conflict with other devices that end up using the
same irq number.

An alternative is to remove the rtc_cmos platform device in Xen PV
guests.

Any preference on how this regression should be fixed?

David

8<--
x86: Xen PV guests don't have the rtc_cmos platform device


[...]

--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -200,6 +200,9 @@ static __init int add_rtc_cmos(void)
}
   #endif
   +if (xen_pv_domain())
+   return -ENODEV;
+

Note there's a missing include that breaks !XEN builds.

We could also use paravirt_enable() here which will probably cover
HVMlite case as well. (Until we start turning on and off various
HVMlite features).

Would it make sense to create a new abstraction, e.g. 'rtc_available' in
struct hypervisor_x86?


We could do this but since this fine-grained feature enabling is still 
way off it may be worth waiting until we actually get to this.


Besides, it would probably be something like if (paravirt_enabled() && 
!rtc_available) so for now having just the first term should suffice.


-boris

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

[Xen-devel] [PATCH] x86: refine nr_sockets calculation

[Jan Beulich]

The previous variant didn't work for non-contiguous socket numbers.

Reported-by: Ed Swierk 
Signed-off-by: Jan Beulich 
Tested-by: Ed Swierk 

--- a/xen/arch/x86/mpparse.c
+++ b/xen/arch/x86/mpparse.c
@@ -89,19 +89,14 @@ void __init set_nr_cpu_ids(unsigned int
 
 void __init set_nr_sockets(void)
 {
-/*
- * Count the actual cpus in the socket 0 and use it to calculate nr_sockets
- * so that the latter will be always >= the actual socket number in the
- * system even when APIC IDs from MP table are too sparse.
- */
-unsigned int cpus = bitmap_weight(phys_cpu_present_map.mask,
-  boot_cpu_data.x86_max_cores *
-  boot_cpu_data.x86_num_siblings);
-
-if ( cpus == 0 )
-cpus = 1;
-
-nr_sockets = DIV_ROUND_UP(num_processors + disabled_cpus, cpus);
+   nr_sockets = last_physid(phys_cpu_present_map)
+/ boot_cpu_data.x86_max_cores
+/ boot_cpu_data.x86_num_siblings + 1;
+   if (disabled_cpus)
+   nr_sockets += (disabled_cpus - 1)
+ / boot_cpu_data.x86_max_cores
+ / boot_cpu_data.x86_num_siblings + 1;
+   printk(XENLOG_DEBUG "nr_sockets: %u\n", nr_sockets);
 }
 
 /*
--- a/xen/include/asm-x86/mpspec.h
+++ b/xen/include/asm-x86/mpspec.h
@@ -43,6 +43,19 @@ typedef struct physid_mask physid_mask_t
 #define physid_isset(physid, map)  test_bit(physid, (map).mask)
 #define physid_test_and_set(physid, map)   test_and_set_bit(physid, 
(map).mask)
 
+#define first_physid(map)  find_first_bit((map).mask, \
+  MAX_APICS)
+#define next_physid(id, map)   find_next_bit((map).mask, \
+ MAX_APICS, (id) + 
1)
+#define last_physid(map) ({ \
+   const unsigned long *mask = (map).mask; \
+   unsigned int id, last = MAX_APICS; \
+   for (id = find_first_bit(mask, MAX_APICS); id < MAX_APICS; \
+id = find_next_bit(mask, MAX_APICS, (id) + 1)) \
+   last = id; \
+   last; \
+})
+
 #define physids_and(dst, src1, src2)   bitmap_and((dst).mask, 
(src1).mask, (src2).mask, MAX_APICS)
 #define physids_or(dst, src1, src2)bitmap_or((dst).mask, 
(src1).mask, (src2).mask, MAX_APICS)
 #define physids_clear(map) bitmap_zero((map).mask, 
MAX_APICS)



x86: refine nr_sockets calculation

The previous variant didn't work for non-contiguous socket numbers.

Reported-by: Ed Swierk 
Signed-off-by: Jan Beulich 
Tested-by: Ed Swierk 

--- a/xen/arch/x86/mpparse.c
+++ b/xen/arch/x86/mpparse.c
@@ -89,19 +89,14 @@ void __init set_nr_cpu_ids(unsigned int
 
 void __init set_nr_sockets(void)
 {
-/*
- * Count the actual cpus in the socket 0 and use it to calculate nr_sockets
- * so that the latter will be always >= the actual socket number in the
- * system even when APIC IDs from MP table are too sparse.
- */
-unsigned int cpus = bitmap_weight(phys_cpu_present_map.mask,
-  boot_cpu_data.x86_max_cores *
-  boot_cpu_data.x86_num_siblings);
-
-if ( cpus == 0 )
-cpus = 1;
-
-nr_sockets = DIV_ROUND_UP(num_processors + disabled_cpus, cpus);
+   nr_sockets = last_physid(phys_cpu_present_map)
+/ boot_cpu_data.x86_max_cores
+/ boot_cpu_data.x86_num_siblings + 1;
+   if (disabled_cpus)
+   nr_sockets += (disabled_cpus - 1)
+ / boot_cpu_data.x86_max_cores
+ / boot_cpu_data.x86_num_siblings + 1;
+   printk(XENLOG_DEBUG "nr_sockets: %u\n", nr_sockets);
 }
 
 /*
--- a/xen/include/asm-x86/mpspec.h
+++ b/xen/include/asm-x86/mpspec.h
@@ -43,6 +43,19 @@ typedef struct physid_mask physid_mask_t
 #define physid_isset(physid, map)  test_bit(physid, (map).mask)
 #define physid_test_and_set(physid, map)   test_and_set_bit(physid, 
(map).mask)
 
+#define first_physid(map)  find_first_bit((map).mask, \
+  MAX_APICS)
+#define next_physid(id, map)   find_next_bit((map).mask, \
+ MAX_APICS, (id) + 
1)
+#define last_physid(map) ({ \
+   const unsigned long *mask = (map).mask; \
+   unsigned int id, last = MAX_APICS; \
+   for (id = find_first_bit(mask, MAX_APICS); id < MAX_APICS; \
+id = find_next_bit(mask, MAX_APICS, (id) + 1)) \
+   last = id; \
+   last; \
+})
+
 #define physids_and(dst, src1, src2)   bitmap_and((dst).mask, 
(src1).mask, (src2).mask, MAX_APICS)
 #define physids_or(dst, src1, src2)bitmap_or((dst).mask, 
(src1).mask, (src2).mask, MAX_APICS)
 #define p

[Xen-devel] [PATCH] x86: re-enable NX if disabled

[Jan Beulich]

I noticed Linux 4.4 doing this universally now, and I think it's a good
idea to override such anti-security BIOS settings (we certainly have no
compatibility problem due to NX being enabled).

Secondary changes:
- no need to check supported extended CPUID level for leaves 8000
  and 8001 (required on x86-64)
- no need to update c->cpuid_level in early_init_intel() (done anyway
  in generic_identify())
- alignment of trampoline data items

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -32,9 +32,13 @@ GLOBAL(trampoline_realmode_entry)
 lmsw%ax   # CR0.PE = 1 (enter protected mode)
 ljmpl   $BOOT_CS32,$bootsym_rel(trampoline_protmode_entry,6)
 
+.balign 8
+.word   0
 idt_48: .word   0, 0, 0 # base = limit = 0
+.word   0
 gdt_48: .word   6*8-1
 .long   bootsym_rel(trampoline_gdt,4)
+
 trampoline_gdt:
 /* 0x: unused */
 .quad   0x
@@ -56,6 +60,9 @@ trampoline_gdt:
 .long   trampoline_gdt + BOOT_PSEUDORM_DS + 2 - .
 .popsection
 
+GLOBAL(trampoline_misc_enable_off)
+.quad   0
+
 GLOBAL(cpuid_ext_features)
 .long   0
 
@@ -84,6 +91,21 @@ trampoline_protmode_entry:
 add bootsym_rel(trampoline_xen_phys_start,4,%eax)
 mov %eax,%cr3
 
+/* Adjust IA32_MISC_ENABLE if needed. */
+mov bootsym_rel(trampoline_misc_enable_off,4,%esi)
+mov bootsym_rel(trampoline_misc_enable_off+4,4,%edi)
+mov %esi,%eax
+or  %edi,%eax
+jz  1f
+mov $MSR_IA32_MISC_ENABLE,%ecx
+rdmsr
+not %esi
+not %edi
+and %esi,%eax
+and %edi,%edx
+wrmsr
+1:
+
 /* Set up EFER (Extended Feature Enable Register). */
 mov bootsym_rel(cpuid_ext_features,4,%edi)
 movl$MSR_EFER,%ecx
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -256,15 +256,15 @@ static void __cpuinit generic_identify(s
 
/* AMD-defined flags: level 0x8001 */
c->extended_cpuid_level = cpuid_eax(0x8000);
-   if ( (c->extended_cpuid_level & 0x) == 0x8000 ) {
-   if ( c->extended_cpuid_level >= 0x8001 )
-   cpuid(0x8001, &tmp, &tmp,
- 
&c->x86_capability[cpufeat_word(X86_FEATURE_LAHF_LM)],
- 
&c->x86_capability[cpufeat_word(X86_FEATURE_SYSCALL)]);
+   cpuid(0x8001, &tmp, &tmp,
+ &c->x86_capability[cpufeat_word(X86_FEATURE_LAHF_LM)],
+ &c->x86_capability[cpufeat_word(X86_FEATURE_SYSCALL)]);
+   if (c == &boot_cpu_data)
+   bootsym(cpuid_ext_features) =
+   c->x86_capability[cpufeat_word(X86_FEATURE_NX)];
 
-   if ( c->extended_cpuid_level >= 0x8004 )
-   get_model_name(c); /* Default name */
-   }
+   if (c->extended_cpuid_level >= 0x8004)
+   get_model_name(c); /* Default name */
 
/* Intel-defined flags: level 0x0007 */
if ( c->cpuid_level >= 0x0007 )
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -162,19 +162,29 @@ static void __devinit early_init_intel(s
if (c->x86 == 15 && c->x86_cache_alignment == 64)
c->x86_cache_alignment = 128;
 
-   /* Unmask CPUID levels if masked: */
+   /* Unmask CPUID levels and NX if masked: */
if (c->x86 > 6 || (c->x86 == 6 && c->x86_model >= 0xd)) {
-   u64 misc_enable;
+   u64 misc_enable, disable;
 
rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable);
 
-   if (misc_enable & MSR_IA32_MISC_ENABLE_LIMIT_CPUID) {
-   misc_enable &= ~MSR_IA32_MISC_ENABLE_LIMIT_CPUID;
-   wrmsrl(MSR_IA32_MISC_ENABLE, misc_enable);
-   c->cpuid_level = cpuid_eax(0);
-   if (opt_cpu_info || c == &boot_cpu_data)
-   printk(KERN_INFO "revised cpuid level: %d\n",
-  c->cpuid_level);
+   disable = misc_enable & (MSR_IA32_MISC_ENABLE_LIMIT_CPUID |
+MSR_IA32_MISC_ENABLE_XD_DISABLE);
+   if (disable) {
+   wrmsrl(MSR_IA32_MISC_ENABLE, misc_enable & ~disable);
+   bootsym(trampoline_misc_enable_off) |= disable;
+   }
+
+   if (disable & MSR_IA32_MISC_ENABLE_LIMIT_CPUID)
+   printk(KERN_INFO "revised cpuid level: %d\n",
+  cpuid_eax(0));
+   if (disable & MSR_IA32_MISC_ENABLE_XD_DISABLE) {
+   u64 efer;
+
+   rdmsrl(MSR_EFER, efer);
+   wrmsrl(MSR_EFER, efer | EFER_NX);
+   printk(KERN_INFO
+   

Re: [Xen-devel] Unexpected crashes/reboots of domU on debian with xen 4.6 kernel 4.1.13

[Jan Beulich]

>>> On 04.12.15 at 16:55,  wrote:
> I'm having a problem with an Xen 4.6.0 install on debian jessie 8.2 with 
> kernel 4.1.13.
> Different domU's has been unexpectedly rebooted several times.
> DomU's runs debian squeeze and wheezy with 4.1.13 kernel.

This ...

> [235243.886902] RIP: e030:[] [] 
> 0xfeff81041470

... in particular suggests a faulty CPU (a bit flip in the instruction
pointer, which I happen to have seen before in a customer report
we've got).

Jan


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

Re: [Xen-devel] [PATCH v2] libxl: add p2p migration

[Jim Fehlig]

On 12/03/2015 12:18 PM, Joao Martins wrote:
>
> On 12/02/2015 11:27 PM, Jim Fehlig wrote:
>> On 11/10/2015 08:32 AM, Joao Martins wrote:
>>> Introduce support for VIR_MIGRATE_PEER2PEER in libxl driver
>>> for supporting migration in Openstack. Most of the changes
>>> occur at the source and no modifications at the receiver.
>>>
>>> In P2P mode there is only the Perform phase so we must handle
>>> the connection with the destination and actually perform the
>>> migration. libxlDomainPerformP2P implements the connection to
>>> the destination and let libxlDoMigrateP2P implements the actual
>>> migration logic with virConnectPtr. In this function we do
>>> the migration steps in the destination similar to
>>> virDomainMigrateVersion3Full. We appropriately save the last
>>> error reported in each of the phases to provide proper
>>> reporting. We don't yet support VIR_MIGRATE_TUNNELED and
>>> we always use V3 with extensible params, making the
>>> implementation simpler.
>>>
>>> It is worth noting that the receiver didn't have any changes,
>>> and because it's still the v3 sequence thus it is possible to
>>> migrate from a P2P to non-P2P host.
>>>
>>> Signed-off-by: Joao Martins 
>>> ---
>>> Changes since v1:
>>>  - Move Begin step to libxlDoMigrateP2P to have all 4 steps
>>>  together.
>>>  - Remove if before VIR_FREE(dom_xml)
>>> ---
>>>  src/libxl/libxl_driver.c|  13 ++-
>>>  src/libxl/libxl_migration.c | 220 
>>> 
>>>  src/libxl/libxl_migration.h |  11 +++
>>>  3 files changed, 241 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
>>> index fcdcbdb..da98265 100644
>>> --- a/src/libxl/libxl_driver.c
>>> +++ b/src/libxl/libxl_driver.c
>>> @@ -4713,6 +4713,7 @@ libxlConnectSupportsFeature(virConnectPtr conn, int 
>>> feature)
>>>  switch (feature) {
>>>  case VIR_DRV_FEATURE_TYPED_PARAM_STRING:
>>>  case VIR_DRV_FEATURE_MIGRATION_PARAMS:
>>> +case VIR_DRV_FEATURE_MIGRATION_P2P:
>>>  return 1;
>>>  default:
>>>  return 0;
>>> @@ -5039,9 +5040,15 @@ libxlDomainMigratePerform3Params(virDomainPtr dom,
>>>  if (virDomainMigratePerform3ParamsEnsureACL(dom->conn, vm->def) < 0)
>>>  goto cleanup;
>>>  
>>> -if (libxlDomainMigrationPerform(driver, vm, dom_xml, dconnuri,
>>> -uri, dname, flags) < 0)
>>> -goto cleanup;
>>> +if (flags & VIR_MIGRATE_PEER2PEER) {
>>> +if (libxlDomainMigrationPerformP2P(driver, vm, dom->conn, dom_xml,
>>> +   dconnuri, uri, dname, flags) < 
>>> 0)
>>> +goto cleanup;
>>> +} else {
>>> +if (libxlDomainMigrationPerform(driver, vm, dom_xml, dconnuri,
>>> +uri, dname, flags) < 0)
>>> +goto cleanup;
>>> +}
>>>  
>>>  ret = 0;
>>>  
>>> diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c
>>> index 0d23e5f..a1c7b55 100644
>>> --- a/src/libxl/libxl_migration.c
>>> +++ b/src/libxl/libxl_migration.c
>>> @@ -42,6 +42,7 @@
>>>  #include "libxl_conf.h"
>>>  #include "libxl_migration.h"
>>>  #include "locking/domain_lock.h"
>>> +#include "virtypedparam.h"
>>>  
>>>  #define VIR_FROM_THIS VIR_FROM_LIBXL
>>>  
>>> @@ -456,6 +457,225 @@ libxlDomainMigrationPrepare(virConnectPtr dconn,
>>>  return ret;
>>>  }
>>>  
>>> +/* This function is a simplification of virDomainMigrateVersion3Full
>>> + * excluding tunnel support and restricting it to migration v3
>>> + * with params since it was the first to be introduced in libxl.
>>> + */
>>> +static int
>>> +libxlDoMigrateP2P(libxlDriverPrivatePtr driver,
>>> +  virDomainObjPtr vm,
>>> +  virConnectPtr sconn,
>>> +  const char *xmlin,
>>> +  virConnectPtr dconn,
>>> +  const char *dconnuri ATTRIBUTE_UNUSED,
>>> +  const char *dname,
>>> +  const char *uri,
>>> +  unsigned int flags)
>>> +{
>>> +virDomainPtr ddomain = NULL;
>>> +virTypedParameterPtr params = NULL;
>>> +int nparams = 0;
>>> +int maxparams = 0;
>>> +char *uri_out = NULL;
>>> +char *dom_xml = NULL;
>>> +unsigned long destflags;
>>> +bool cancelled = true;
>>> +virErrorPtr orig_err = NULL;
>>> +int ret = -1;
>>> +
>>> +dom_xml = libxlDomainMigrationBegin(sconn, vm, xmlin);
>>> +if (!dom_xml)
>>> +goto cleanup;
>>> +
>>> +if (virTypedParamsAddString(¶ms, &nparams, &maxparams,
>>> +VIR_MIGRATE_PARAM_DEST_XML, dom_xml) < 0)
>>> +goto cleanup;
>>> +
>>> +if (dname &&
>>> +virTypedParamsAddString(¶ms, &nparams, &maxparams,
>>> +VIR_MIGRATE_PARAM_DEST_NAME, dname) < 0)
>>> +goto cleanup;
>>> +
>>> +if (uri &&
>>> +virTypedParamsAddString(¶ms, &nparams, &maxparams,
>>> + 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  5 kernel-build  fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail REGR. vs. 60684
 test-amd64-i386-rumpuserxen-i386 10 guest-start  fail in 65323 REGR. vs. 60684

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-i386-pvgrub  9 debian-di-install  fail in 65271 pass in 65352
 test-amd64-i386-xl6 xen-boot   fail in 65323 pass in 65271
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-bootfail in 65323 pass in 65271
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail in 65323 pass in 
65271
 test-amd64-i386-qemuu-rhel6hvm-amd  6 xen-boot fail in 65323 pass in 65291
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail in 65323 pass in 65352
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 65323 pass in 65352
 test-amd64-amd64-libvirt-xsm  6 xen-bootfail pass in 65271
 test-amd64-amd64-xl-qemut-debianhvm-amd64  6 xen-boot   fail pass in 65271
 test-amd64-amd64-xl-multivcpu  6 xen-boot   fail pass in 65323
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 
65323

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 60684

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemut-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-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  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-vcpus1  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail in 65271 never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-check fail in 65323 never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 65323 never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 65323 never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail in 65323 never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 65323 never pass
 test-amd64-i386-libvirt  12 migrate-support-check fail in 65323 never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass

version targeted for testing:
 linux 

Re: [Xen-devel] [PATCH] x86: refine nr_sockets calculation

[Andrew Cooper]

On 04/12/15 16:29, Jan Beulich wrote:
> The previous variant didn't work for non-contiguous socket numbers.
>
> Reported-by: Ed Swierk 
> Signed-off-by: Jan Beulich 
> Tested-by: Ed Swierk 

Reviewed-by: Andrew Cooper 

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

[Xen-devel] [PATCH] libxl: free ifname on migration begin phase

[Joao Martins]

Commit d2e5538b1 changes virDomainDef to create ifnames
that are autogenerated by libxl, and also clearing them up
on domain cleanup. One place that was missing was also
on migration, when domain xml is sent to dst libvirtd and
would contain ifnames from the source libvirtd. This
would lead to erronous behaviour (as seen in osstest CI)
such as failing to migrate when a vif with the a name
that existed on the destination host (belonging to another domain).

This patch adds an helper libxlDomainFreeIfaceNames for
freeing autogenerated ifnames on both migration begin phase
and domain cleanup.

Signed-off-by: Joao Martins 
---
 src/libxl/libxl_domain.c| 32 ++--
 src/libxl/libxl_domain.h|  3 +++
 src/libxl/libxl_migration.c |  2 ++
 3 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index ef92974..487589d 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -728,16 +728,7 @@ libxlDomainCleanup(libxlDriverPrivatePtr driver,
 }
 }
 
-if ((vm->def->nnets)) {
-size_t i;
-
-for (i = 0; i < vm->def->nnets; i++) {
-virDomainNetDefPtr net = vm->def->nets[i];
-
-if (STRPREFIX(net->ifname, "vif"))
-VIR_FREE(net->ifname);
-}
-}
+libxlDomainFreeIfaceNames(vm->def);
 
 if (virAsprintf(&file, "%s/%s.xml", cfg->stateDir, vm->def->name) > 0) {
 if (unlink(file) < 0 && errno != ENOENT && errno != ENOTDIR)
@@ -923,6 +914,27 @@ libxlDomainCreateIfaceNames(virDomainDefPtr def, 
libxl_domain_config *d_config)
 }
 }
 
+/*
+ * Removes autogenerated interface names for the network devices in
+ * parameter def. User-provided interface names are skipped.
+ */
+void
+libxlDomainFreeIfaceNames(virDomainDefPtr def)
+{
+size_t i;
+
+for (i = 0; i < def->nnets; i++) {
+virDomainNetDefPtr net = def->nets[i];
+
+if (!net->ifname)
+continue;
+
+if (STRPREFIX(net->ifname, "vif"))
+VIR_FREE(net->ifname);
+}
+}
+
+
 
 /*
  * Start a domain through libxenlight.
diff --git a/src/libxl/libxl_domain.h b/src/libxl/libxl_domain.h
index 44b3e0b..70c139c 100644
--- a/src/libxl/libxl_domain.h
+++ b/src/libxl/libxl_domain.h
@@ -135,6 +135,9 @@ int
 libxlDomainSetVcpuAffinities(libxlDriverPrivatePtr driver,
  virDomainObjPtr vm);
 
+void
+libxlDomainFreeIfaceNames(virDomainDefPtr def);
+
 int
 libxlDomainStart(libxlDriverPrivatePtr driver,
  virDomainObjPtr vm,
diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c
index 0d23e5f..1ee19ae 100644
--- a/src/libxl/libxl_migration.c
+++ b/src/libxl/libxl_migration.c
@@ -249,6 +249,8 @@ libxlDomainMigrationBegin(virConnectPtr conn,
 def = tmpdef;
 } else {
 def = vm->def;
+
+libxlDomainFreeIfaceNames(def);
 }
 
 if (!libxlDomainMigrationIsAllowed(def))
-- 
2.1.4


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

[Xen-devel] Save the Date: Xen Project Hackathon 2016 (Location: Cambridge UK, Dates 18-19 April 2016)

[Lars Kurth]

Hi everyone,
I am pleased to inform you that ARM will host the 2016 Hackathon at their site 
in Cambridge, UK. The Hackathon will take place April 18 & 19. I will put 
together more information (wiki, blog posts, ...) in the new year!
Best Regards
Lars
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86: re-enable NX if disabled

[Andrew Cooper]

On 04/12/15 16:31, Jan Beulich wrote:
> I noticed Linux 4.4 doing this universally now, and I think it's a good
> idea to override such anti-security BIOS settings (we certainly have no
> compatibility problem due to NX being enabled).

I had a plan to do the same, so definitely +1.

>
> Secondary changes:
> - no need to check supported extended CPUID level for leaves 8000
>   and 8001 (required on x86-64)
> - no need to update c->cpuid_level in early_init_intel() (done anyway
>   in generic_identify())
> - alignment of trampoline data items
>
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/boot/trampoline.S
> +++ b/xen/arch/x86/boot/trampoline.S
> @@ -32,9 +32,13 @@ GLOBAL(trampoline_realmode_entry)
>  lmsw%ax   # CR0.PE = 1 (enter protected mode)
>  ljmpl   $BOOT_CS32,$bootsym_rel(trampoline_protmode_entry,6)
>  
> +.balign 8
> +.word   0
>  idt_48: .word   0, 0, 0 # base = limit = 0
> +.word   0
>  gdt_48: .word   6*8-1
>  .long   bootsym_rel(trampoline_gdt,4)
> +
>  trampoline_gdt:
>  /* 0x: unused */
>  .quad   0x
> @@ -56,6 +60,9 @@ trampoline_gdt:
>  .long   trampoline_gdt + BOOT_PSEUDORM_DS + 2 - .
>  .popsection
>  
> +GLOBAL(trampoline_misc_enable_off)
> +.quad   0
> +

For clarity, I would name this trampoline_misc_enable_mask and invert
its representation to make the asm easier.

>  GLOBAL(cpuid_ext_features)
>  .long   0
>  
> @@ -84,6 +91,21 @@ trampoline_protmode_entry:
>  add bootsym_rel(trampoline_xen_phys_start,4,%eax)
>  mov %eax,%cr3
>  
> +/* Adjust IA32_MISC_ENABLE if needed. */

Possibly worth stating that this is to allow us to enable NX before
attempting to use pagetables with NX set.

> +mov bootsym_rel(trampoline_misc_enable_off,4,%esi)
> +mov bootsym_rel(trampoline_misc_enable_off+4,4,%edi)
> +mov %esi,%eax
> +or  %edi,%eax
> +jz  1f
> +mov $MSR_IA32_MISC_ENABLE,%ecx
> +rdmsr
> +not %esi
> +not %edi
> +and %esi,%eax
> +and %edi,%edx
> +wrmsr
> +1:
> +
>  /* Set up EFER (Extended Feature Enable Register). */
>  mov bootsym_rel(cpuid_ext_features,4,%edi)
>  movl$MSR_EFER,%ecx
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -256,15 +256,15 @@ static void __cpuinit generic_identify(s
>  
>   /* AMD-defined flags: level 0x8001 */
>   c->extended_cpuid_level = cpuid_eax(0x8000);
> - if ( (c->extended_cpuid_level & 0x) == 0x8000 ) {
> - if ( c->extended_cpuid_level >= 0x8001 )
> - cpuid(0x8001, &tmp, &tmp,
> -   
> &c->x86_capability[cpufeat_word(X86_FEATURE_LAHF_LM)],
> -   
> &c->x86_capability[cpufeat_word(X86_FEATURE_SYSCALL)]);
> + cpuid(0x8001, &tmp, &tmp,
> +   &c->x86_capability[cpufeat_word(X86_FEATURE_LAHF_LM)],
> +   &c->x86_capability[cpufeat_word(X86_FEATURE_SYSCALL)]);
> + if (c == &boot_cpu_data)
> + bootsym(cpuid_ext_features) =
> + c->x86_capability[cpufeat_word(X86_FEATURE_NX)];
>  
> - if ( c->extended_cpuid_level >= 0x8004 )
> - get_model_name(c); /* Default name */
> - }
> + if (c->extended_cpuid_level >= 0x8004)
> + get_model_name(c); /* Default name */
>  
>   /* Intel-defined flags: level 0x0007 */
>   if ( c->cpuid_level >= 0x0007 )
> --- a/xen/arch/x86/cpu/intel.c
> +++ b/xen/arch/x86/cpu/intel.c
> @@ -162,19 +162,29 @@ static void __devinit early_init_intel(s
>   if (c->x86 == 15 && c->x86_cache_alignment == 64)
>   c->x86_cache_alignment = 128;
>  
> - /* Unmask CPUID levels if masked: */
> + /* Unmask CPUID levels and NX if masked: */
>   if (c->x86 > 6 || (c->x86 == 6 && c->x86_model >= 0xd)) {
> - u64 misc_enable;
> + u64 misc_enable, disable;
>  
>   rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable);
>  
> - if (misc_enable & MSR_IA32_MISC_ENABLE_LIMIT_CPUID) {
> - misc_enable &= ~MSR_IA32_MISC_ENABLE_LIMIT_CPUID;
> - wrmsrl(MSR_IA32_MISC_ENABLE, misc_enable);
> - c->cpuid_level = cpuid_eax(0);
> - if (opt_cpu_info || c == &boot_cpu_data)
> - printk(KERN_INFO "revised cpuid level: %d\n",
> -c->cpuid_level);
> + disable = misc_enable & (MSR_IA32_MISC_ENABLE_LIMIT_CPUID |
> +  MSR_IA32_MISC_ENABLE_XD_DISABLE);
> + if (disable) {
> + wrmsrl(MSR_IA32_MISC_ENABLE, misc_enable & ~disable);
> + bootsym(trampoline_misc_enable_off) |= 

Re: [Xen-devel] [PATCH] libxl: free ifname on migration begin phase

[Joao Martins]

On 12/04/2015 05:28 PM, Joao Martins wrote:
> Commit d2e5538b1 changes virDomainDef to create ifnames
> that are autogenerated by libxl, and also clearing them up
> on domain cleanup. One place that was missing was also
> on migration, when domain xml is sent to dst libvirtd and
> would contain ifnames from the source libvirtd. This
> would lead to erronous behaviour (as seen in osstest CI)
> such as failing to migrate when a vif with the a name
> that existed on the destination host (belonging to another domain).
> 
> This patch adds an helper libxlDomainFreeIfaceNames for
> freeing autogenerated ifnames on both migration begin phase
> and domain cleanup.
> 
Apologies, this might not be the correct way. While migration happens we can't
get the interface stats, plus if the migration fails we would leave the domain
without ifname. So perhaps should be done on Prepare phase and the destination
would be responsible for clearing them up since XML is not active and might
actually disappear if migration fails. It would also be better for P2P support.
I will resubmit (and retest). Please ignore this patch.

Joao

> Signed-off-by: Joao Martins 
> ---
>  src/libxl/libxl_domain.c| 32 ++--
>  src/libxl/libxl_domain.h|  3 +++
>  src/libxl/libxl_migration.c |  2 ++
>  3 files changed, 27 insertions(+), 10 deletions(-)
> 
> diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> index ef92974..487589d 100644
> --- a/src/libxl/libxl_domain.c
> +++ b/src/libxl/libxl_domain.c
> @@ -728,16 +728,7 @@ libxlDomainCleanup(libxlDriverPrivatePtr driver,
>  }
>  }
>  
> -if ((vm->def->nnets)) {
> -size_t i;
> -
> -for (i = 0; i < vm->def->nnets; i++) {
> -virDomainNetDefPtr net = vm->def->nets[i];
> -
> -if (STRPREFIX(net->ifname, "vif"))
> -VIR_FREE(net->ifname);
> -}
> -}
> +libxlDomainFreeIfaceNames(vm->def);
>  
>  if (virAsprintf(&file, "%s/%s.xml", cfg->stateDir, vm->def->name) > 0) {
>  if (unlink(file) < 0 && errno != ENOENT && errno != ENOTDIR)
> @@ -923,6 +914,27 @@ libxlDomainCreateIfaceNames(virDomainDefPtr def, 
> libxl_domain_config *d_config)
>  }
>  }
>  
> +/*
> + * Removes autogenerated interface names for the network devices in
> + * parameter def. User-provided interface names are skipped.
> + */
> +void
> +libxlDomainFreeIfaceNames(virDomainDefPtr def)
> +{
> +size_t i;
> +
> +for (i = 0; i < def->nnets; i++) {
> +virDomainNetDefPtr net = def->nets[i];
> +
> +if (!net->ifname)
> +continue;
> +
> +if (STRPREFIX(net->ifname, "vif"))
> +VIR_FREE(net->ifname);
> +}
> +}
> +
> +
>  
>  /*
>   * Start a domain through libxenlight.
> diff --git a/src/libxl/libxl_domain.h b/src/libxl/libxl_domain.h
> index 44b3e0b..70c139c 100644
> --- a/src/libxl/libxl_domain.h
> +++ b/src/libxl/libxl_domain.h
> @@ -135,6 +135,9 @@ int
>  libxlDomainSetVcpuAffinities(libxlDriverPrivatePtr driver,
>   virDomainObjPtr vm);
>  
> +void
> +libxlDomainFreeIfaceNames(virDomainDefPtr def);
> +
>  int
>  libxlDomainStart(libxlDriverPrivatePtr driver,
>   virDomainObjPtr vm,
> diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c
> index 0d23e5f..1ee19ae 100644
> --- a/src/libxl/libxl_migration.c
> +++ b/src/libxl/libxl_migration.c
> @@ -249,6 +249,8 @@ libxlDomainMigrationBegin(virConnectPtr conn,
>  def = tmpdef;
>  } else {
>  def = vm->def;
> +
> +libxlDomainFreeIfaceNames(def);
>  }
>  
>  if (!libxlDomainMigrationIsAllowed(def))
> 

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

[Xen-devel] [OSSTEST PATCH 05/11] mg-debug-fail: Catch attempts to read from a tty

[Ian Jackson]

When stdin is a tty, do not try to dump it.

Signed-off-by: Ian Jackson 
---
 mg-debug-fail |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/mg-debug-fail b/mg-debug-fail
index 64fa235..ffe9f50 100755
--- a/mg-debug-fail
+++ b/mg-debug-fail
@@ -3,10 +3,10 @@
 # This script can be provided anywhere an executable or command name is
 # wanted.  It prints its arguments, and its stdin, to its stderr, and
 # then exits nonzero.
-#
-# When using this it may be useful to provide /dev/null 2>&1; then
+   exec &2
-- 
1.7.10.4


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

[Xen-devel] [OSSTEST PATCH 08/11] Osstest.pm: Break out and export globalconfigfiles

[Ian Jackson]

No functional change; no callers as yet.

Signed-off-by: Ian Jackson 
---
 Osstest.pm |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/Osstest.pm b/Osstest.pm
index 95e4d46..20b8f62 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -30,7 +30,7 @@ BEGIN {
 @ISA = qw(Exporter);
 @EXPORT  = qw(
   readglobalconfig %c $mjobdb $mhostdb
-  augmentconfigdefaults
+  augmentconfigdefaults globalconfigfiles
   csreadconfig
   getmethod
   postfork
@@ -124,6 +124,10 @@ sub getmethod {
 return $r;
 }
 
+sub globalconfigfiles () {
+   $ENV{'OSSTEST_CONFIG'} || "$ENV{'HOME'}/.xen-osstest/config";
+}
+
 sub readglobalconfig () {
 our $readglobalconfig_done;
 return if $readglobalconfig_done;
@@ -135,7 +139,7 @@ sub readglobalconfig () {
 $c{AuthorizedKeysFiles} = '';
 $c{AuthorizedKeysAppend} = '';
 
-my $cfgfiles = $ENV{'OSSTEST_CONFIG'} || 
"$ENV{'HOME'}/.xen-osstest/config";
+my $cfgfiles = globalconfigfiles();
 
 my $readcfg;
 $readcfg = sub ($$) {
-- 
1.7.10.4


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

[Xen-devel] [OSSTEST PATCH 00/11] Test database handling

[Ian Jackson]

I'm intending to be able to do database schema updates.  But I don't
want to play around with such code on a live database.  So I need a
test database.

Thus, a yak: arrangements to make a test database.

I have tested this and it now does the right things in, apparently,
the right order, and seems to leave things in a good state even when
it collapses halfway or is ^C'd.


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

[Xen-devel] [OSSTEST PATCH 02/11] cri-getconfig: Break out exec_resetting_sigint.

[Ian Jackson]

Move this oddity (and the associated comment) from
standalone-generate-dump-flight-runvars to cri-getconfig.  We are
going to want it elsewhere.

We put this in cri-getconfig because that is the one library of
generic shell functions which everything includes.  Perhaps this file
is misnamed.

No overall functional change.

Signed-off-by: Ian Jackson 
---
 cri-getconfig   |   30 ++
 standalone-generate-dump-flight-runvars |   28 +---
 2 files changed, 31 insertions(+), 27 deletions(-)

diff --git a/cri-getconfig b/cri-getconfig
index 0589bf0..ee1cc40 100644
--- a/cri-getconfig
+++ b/cri-getconfig
@@ -39,3 +39,33 @@ getrepos() {
fi
echo $repos
 }
+
+# Good grief, handling background proceesses from shell is a pain.
+#
+# For stupid historical reasons, background processes start with
+# SIGINT (and QUIT) ignored (SuSv3 2.11).  bash does not currently
+# offer a way to ask it not to do this; nor is there a reliable way to
+# put the SIGINT handling back to normal.
+#
+# "trap - INT" can be used to put the handling back in recent versions
+# of bash (eg Debian jessie), but earlier versions are buggy, so
+# we use perl.
+#
+# However, there is still a race: if the signal arrives just after the
+# fork, after the shell has (in the child) set it to to IGN, but
+# before Perl has put it back, the child might still escape.
+# There is no reasonable way to deal with this race.  So the result
+# may still be slightly racy in the case that s-g-d-f-r is ^C'd right
+# after starting.
+#
+# Hopefully in the future we can fix this with something like
+# "shopt -s no_async_sig_ignore".  See
+# https://lists.gnu.org/archive/html/bug-bash/2015-10/msg00077.html
+#
+exec_resetting_sigint () {
+   exec perl -e '
+   $SIG{$_}=DFL foreach qw(INT QUIT HUP);
+   kill 1, $$ unless getppid=='$$';
+   exec @ARGV or die $!;
+   ' "$@"
+}
diff --git a/standalone-generate-dump-flight-runvars 
b/standalone-generate-dump-flight-runvars
index e91026a..3b20c62 100755
--- a/standalone-generate-dump-flight-runvars
+++ b/standalone-generate-dump-flight-runvars
@@ -58,35 +58,9 @@ perbranch () {
 flight=check_${branch//[-._]/_}
 }
 
-# Good grief, handling background proceesses from shell is a pain.
-#
-# For stupid historical reasons, background processes start with
-# SIGINT (and QUIT) ignored (SuSv3 2.11).  bash does not currently
-# offer a way to ask it not to do this; nor is there a reliable way to
-# put the SIGINT handling back to normal.
-#
-# "trap - INT" can be used to put the handling back in recent versions
-# of bash (eg Debian jessie), but earlier versions are buggy, so
-# we use perl.
-#
-# However, there is still a race: if the signal arrives just after the
-# fork, after the shell has (in the child) set it to to IGN, but
-# before Perl has put it back, the child might still escape.
-# There is no reasonable way to deal with this race.  So the result
-# may still be slightly racy in the case that s-g-d-f-r is ^C'd right
-# after starting.
-#
-# Hopefully in the future we can fix this with something like
-# "shopt -s no_async_sig_ignore".  See
-# https://lists.gnu.org/archive/html/bug-bash/2015-10/msg00077.html
-
 for branch in $@; do
 perbranch
-perl -e '
-$SIG{$_}=DFL foreach qw(INT QUIT HUP);
-   kill 1, $$ unless getppid=='$$';
-   exec @ARGV or die $!;
-' \
+exec_resetting_sigint \
 ./standalone make-flight -f $flight $branch >$log 2>&1 &
 procs+=" $branch=$!"
 done
-- 
1.7.10.4


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

[Xen-devel] [OSSTEST PATCH 10/11] mg-schema-test-database: Move setting of test_cfg_setting to dbname

[Ian Jackson]

This will makes it available to a wider subset of the script, which is
going to be important in a moment.

No functional change.

Signed-off-by: Ian Jackson 
---
 mg-schema-test-database |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/mg-schema-test-database b/mg-schema-test-database
index 64acdcf..fec7f20 100755
--- a/mg-schema-test-database
+++ b/mg-schema-test-database
@@ -56,6 +56,12 @@ dbname () {
dbname="${maindbname}_test$suffix"
t="tmp/testdb$suffix"
tcfg=local-config.test-database$suffix
+
+   test_cfg_setting="$(perl -we '
+   use Osstest;
+   print globalconfigfiles() or die $!;
+   '):$tcfg"
+
 }
 
 psql_query_internal () {
@@ -260,12 +266,6 @@ QueueDaemonPort ${ctrlports#*,}
 END
mv -f $tcfg.tmp $tcfg
 
-   # this makes `withtest' work
-   test_cfg_setting="$(perl -we '
-   use Osstest;
-   print globalconfigfiles() or die $!;
-   '):$tcfg"
-
# Extract the schema for reference
$(get_pgdump_cmd) -s -O -x >$t.schema
 
-- 
1.7.10.4


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

[Xen-devel] [OSSTEST PATCH 06/11] cri-getconfig: Provide get_psql_cmd and get_pgdump_cmd

[Ian Jackson]

This is for (non-standalone-mode) shell scripts which want to access
the postgresql database.

get_psql_command provides `-v ON_ERROR_STOP' because it is not the
default (!) and no sane caller would not want it.

No callers as yet.

Signed-off-by: Ian Jackson 
---
 cri-getconfig |   31 +++
 1 file changed, 31 insertions(+)

diff --git a/cri-getconfig b/cri-getconfig
index ee1cc40..48528b5 100644
--- a/cri-getconfig
+++ b/cri-getconfig
@@ -40,6 +40,37 @@ getrepos() {
echo $repos
 }
 
+get_psql_cmd () {
+   perl -we '
+   use Osstest;
+   use Osstest::Executive;
+   use DBI;
+   csreadconfig();
+   print "psql",
+" -d ", $dbh_tests->{pg_db},
+" -h ", $dbh_tests->{pg_host},
+" -p ", $dbh_tests->{pg_port},
+" -U ", $dbh_tests->{pg_user},
+" -v ON_ERROR_STOP=1\n"
+or die $!;
+'
+}
+
+get_pgdump_cmd () {
+   perl -we '
+   use Osstest;
+   use Osstest::Executive;
+   use DBI;
+   csreadconfig();
+   print "pg_dump",
+" -h ", $dbh_tests->{pg_host},
+" -p ", $dbh_tests->{pg_port},
+" -U ", $dbh_tests->{pg_user},
+" ",$dbh_tests->{pg_db}, "\n"
+or die $!;
+'
+}
+
 # Good grief, handling background proceesses from shell is a pain.
 #
 # For stupid historical reasons, background processes start with
-- 
1.7.10.4


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

[Xen-devel] [OSSTEST PATCH 04/11] mg-debug-fail: New utility script for debugging

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
 mg-debug-fail |   13 +
 1 file changed, 13 insertions(+)
 create mode 100755 mg-debug-fail

diff --git a/mg-debug-fail b/mg-debug-fail
new file mode 100755
index 000..64fa235
--- /dev/null
+++ b/mg-debug-fail
@@ -0,0 +1,13 @@
+#!/bin/sh
+#
+# This script can be provided anywhere an executable or command name is
+# wanted.  It prints its arguments, and its stdin, to its stderr, and
+# then exits nonzero.
+#
+# When using this it may be useful to provide &2
+exit 127
-- 
1.7.10.4


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

[Xen-devel] [OSSTEST PATCH 01/11] tcl daemons: log host and port number we bind to, at startup

[Ian Jackson]

If the socket setup fails, this makes it easier to see what the
program was trying to do.

Signed-off-by: Ian Jackson 
---
 tcl/daemonlib.tcl |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tcl/daemonlib.tcl b/tcl/daemonlib.tcl
index 972b5e2..b76ff12 100644
--- a/tcl/daemonlib.tcl
+++ b/tcl/daemonlib.tcl
@@ -210,7 +210,7 @@ proc main-daemon {which setup} {
 fconfigure stdout -buffering line
 fconfigure stderr -buffering none
 
-log "starting"
+log "starting $host:$port"
 
 uplevel 1 $setup
 
-- 
1.7.10.4


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

[Xen-devel] [OSSTEST PATCH 03/11] Configuration: No longer set password=<~/.xen-osstest/db-password>

[Ian Jackson]

Instead, expect the user to provide ~/.pgpass.

This is a good idea because we don't really want to be handling
passwords ourselves if we can help it.  And, we are shortly going to
want to do some exciting mangling of the database access
configuration, which would be complicated by the presence of this
password expansion.

This may break for some users of existing Executive (non-standalone)
setups which are using production-config-cambridge or the default
built-in configuration.

Signed-off-by: Ian Jackson 
---
 Osstest.pm  |3 +--
 production-config-cambridge |2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/Osstest.pm b/Osstest.pm
index ec50d60..95e4d46 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -191,8 +191,7 @@ sub readglobalconfig () {
 
 # dynamic default config settings
 $c{ExecutiveDbnamePat} ||= "dbname=;user=;".
-   "host=.db.$c{DnsDomain};".
-   "password=<~/.xen-osstest/db-password>"
+   "host=.db.$c{DnsDomain}"
if defined $c{DnsDomain};
 # 1. <\w+> is replaced with variables:
 # database name
diff --git a/production-config-cambridge b/production-config-cambridge
index f801303..412766c 100644
--- a/production-config-cambridge
+++ b/production-config-cambridge
@@ -23,7 +23,7 @@ HostDB_Executive_NoConfigDB 1
 
 OwnerDaemonHost owner.daemon.osstest.xs.citrite.net
 QueueDaemonHost queue.daemon.osstest.xs.citrite.net
-ExecutiveDbnamePat 
dbname=;user=;host=osstestdb.xs.citrite.net;password=<~/.xen-osstest/db-password>
+ExecutiveDbnamePat dbname=;user=;host=osstestdb.xs.citrite.net
 
 HostnameSortSwapWords 1
 
-- 
1.7.10.4


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

[Xen-devel] [OSSTEST PATCH 09/11] mg-schema-test-database: New script

[Ian Jackson]

This allows a user in non-standalone mode to make a whole new test
database, which is largely a clone of the original database.

The new db refers to the same resources (hosts), and more-or-less
safely borrows some of those hosts.

Currently we don't do anything about the queue and owner daemons.
This means that queue-daemon-based resource allocation is broken when
clients are pointed at the test db.  But non-queue-based allocation
(eg, ./mg-allocate without -U) works, and the test db can be used for
db-related experiments and even support individual ts-* scripts (other
than ts-hosts-allocate of course).

Signed-off-by: Ian Jackson 
---
 mg-schema-test-database |  458 +++
 1 file changed, 458 insertions(+)
 create mode 100755 mg-schema-test-database

diff --git a/mg-schema-test-database b/mg-schema-test-database
new file mode 100755
index 000..64acdcf
--- /dev/null
+++ b/mg-schema-test-database
@@ -0,0 +1,458 @@
+#!/bin/bash
+#
+# usages:
+#
+#
+#  ./mg-schema-test-database create [_SUFFIX] [TASK...] \
+#  [-fMINFLIGHT | -f-NUMFLIGHTS]
+#
+# does `drop' and then creates
+#   - the databaseosstestdb_test_SUFFIX
+#   - a file  local-config.test-database_SUFFIX
+#
+# default for SUFFIX is your local username
+#
+# Resources owned in the main db by a task in the list of specified
+# TASKs become idle in the test copy.  Others become allocated to
+# a specially-created `owned by someone in real db' task.
+#
+#
+#  ./mg-schema-test-database drop [_SUFFIX]
+#
+# deletes your test database and removes the local-config file
+#
+#
+
+set -e -o posix ${OSSTEST_DEBUG:+-x}
+
+. ./cri-getconfig
+. ./mgi-common
+
+if [ $# -lt 1 ]; then fail "need operation"; fi
+
+cmd="$1"; shift
+
+localconfig=local-config.test-database
+
+maindbname=$(perl -we '
+   use Osstest;
+   use Osstest::Executive;
+   use DBI;
+   csreadconfig();
+   print $dbh_tests->{pg_db},"\n"
+or die $!;
+')
+
+parse_only_suffix () {
+   for arg in "$@"; do
+   case "$arg" in
+   _*) suffix="$arg" ;;
+   *)  fail 'bad usage' ;;
+   esac
+   done
+}
+
+dbname () {
+   dbname="${maindbname}_test$suffix"
+   t="tmp/testdb$suffix"
+   tcfg=local-config.test-database$suffix
+}
+
+psql_query_internal () {
+   $(get_psql_cmd) -At -R' ' -f- "$@"
+}
+
+psql_query () {
+if [ x$OSSTEST_DEBUG != x ]; then
+   tee /dev/stderr | psql_query_internal "$@"
+   else
+   psql_query_internal "$@"
+   fi
+}
+
+psql_do_cmd () {
+   echo "$(get_psql_cmd) ${OSSTEST_DEBUG:+-e -a}" 
+}
+
+psql_do () {
+   $(psql_do_cmd) -q -f- "$@"
+}
+
+moretasks () {
+   local ifnone="$1"; shift
+   local where="$1"; shift
+   local r
+   r=$(
+   psql_query "$@" <&2 "warning: $m"
+   ;;
+   *)
+   fail-bad-moretasks-ifnone-"$ifnone"
+   ;;
+   esac
+   fi
+
+   tasks+=" $r"
+}
+
+withtest () {
+   OSSTEST_CONFIG="$test_cfg_setting" "$@"
+}
+
+each_copy_table () {
+   local tab=$1; shift
+   local cond=$1; shift
+
+   p=$t.tabledata.$tab
+   rm -f $p
+
+   cat <>$t.export
+   \\COPY (SELECT * FROM $tab WHERE $cond) TO $p $copyhow
+END
+   cat <>$t.import
+   \\COPY $tab FROM $p $copyhow
+END
+}
+
+make_xdbref_task () {
+   local refkey=$1; shift
+   local comment=$1; shift
+   local refinfo=$1; shift
+   echo "
+   INSERT INTO tasks
+   (type, refkey, username, comment, live, refinfo)
+ VALUES ('xdbref','$refkey','$username@$nodename',
+ '$comment','t','$refinfo');
+   "
+}
+
+taskid () {
+   local type=$1; shift
+   local refkey=$1; shift
+   local xcond=$1
+   echo "(SELECT taskid FROM tasks WHERE
+   type='$type' AND refkey='$refkey' $xcond)"
+}
+borrowtaskid () {
+   local bt=$1
+   taskid xdbref $dbname "
+   AND live AND refinfo IS NOT NULL AND refinfo='$bt'
+   "
+}
+
+username=`whoami`
+nodename=`uname -n`
+suffix=_$username
+invocation_now=`date +%s`
+
+case "$cmd" in
+
+#== CREATE ==
+
+create)
+   #-- argument parsing --
+
+   tasks=''
+   minflight=-1000
+   for arg in "$@"; do
+   case "$arg" in
+   *@*)
+   moretasks warning   \
+   "WHERE type = 'static'
+  AND refkey LIKE :'pattern'"  \
+   -v pattern="${arg//\*/%}"   \
+   ;;
+   *" "*" "*)
+   local rhs="${arg#* }"
+   moretasks error \
+   "WHERE taskid = :'taskid'
+ 

[Xen-devel] [OSSTEST PATCH 07/11] cri-getconfig: Provide debugging for get_psql_cmd

[Ian Jackson]

This allows us to execute only the first  SQL
invocations.  The first non-executed one is dumped, instead, by having
get_psql_command print a rune involving ./mg-debug-fail (which the
caller will then execute).

The locking makes things work roughly-correctly if get_psql_cmd is run
in multiple processes at once: it is not defined exactly which
invocations get which counter values, but they will all work properly
and get exactly one counter value each.

If set -x is in force, turn it off for get_psql_cmd: our perl rune is
uninteresting to see repeated ad infinitum in debugging output.

Signed-off-by: Ian Jackson 
---
 cri-getconfig |   16 
 1 file changed, 16 insertions(+)

diff --git a/cri-getconfig b/cri-getconfig
index 48528b5..a357d86 100644
--- a/cri-getconfig
+++ b/cri-getconfig
@@ -41,6 +41,22 @@ getrepos() {
 }
 
 get_psql_cmd () {
+   # To use this:
+   #  on each test run, rm -f t.psql-counter
+   #  and set OSSTEST_PSQL_ONLY_DO to an integer
+   if [ "x$OSSTEST_PSQL_ONLY_DO" != x ]; then
+   local f=t.psql-counter
+   psql_counter=$( with-lock-ex -w $f.lock bash -ec '
+   psql_counter=$(cat '$f' || echo 0)
+   echo $(( $psql_counter + 1 )) >'$f'.tmp
+   mv -f '$f'.tmp '$f'
+   echo $psql_counter' )
+   if ! [ $psql_counter -lt $OSSTEST_PSQL_ONLY_DO ]; then
+   printf './mg-debug-fail '
+   fi
+   fi
+
+   set +x
perl -we '
use Osstest;
use Osstest::Executive;
-- 
1.7.10.4


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

[Xen-devel] [OSSTEST PATCH 11/11] mg-schema-test-database: Sort out daemons; provide `daemons' subcommand

[Ian Jackson]

We arrange for the test configuration to look for the daemons on a
different host and port, and we provide a convenient way to run such a
pair of daemons.

Signed-off-by: Ian Jackson 
---
 mg-schema-test-database |   57 ++-
 1 file changed, 56 insertions(+), 1 deletion(-)

diff --git a/mg-schema-test-database b/mg-schema-test-database
index fec7f20..73d92f3 100755
--- a/mg-schema-test-database
+++ b/mg-schema-test-database
@@ -4,7 +4,8 @@
 #
 #
 #  ./mg-schema-test-database create [_SUFFIX] [TASK...] \
-#  [-fMINFLIGHT | -f-NUMFLIGHTS]
+#  [-fMINFLIGHT | -f-NUMFLIGHTS] \
+#  [-hCTRL_DAEMONS_HOST] [-fOWNER_D_PORT[,QUEUE_D_PORT]]
 #
 # does `drop' and then creates
 #   - the databaseosstestdb_test_SUFFIX
@@ -16,12 +17,24 @@
 # TASKs become idle in the test copy.  Others become allocated to
 # a specially-created `owned by someone in real db' task.
 #
+# Default for CTRL_DAEMONS_HOST is localhost; if no port is supplied,
+# we use the corresponding production port + 2; if only one port is
+# supplied we use that and the next port number.
+#
 #
 #  ./mg-schema-test-database drop [_SUFFIX]
 #
 # deletes your test database and removes the local-config file
 #
 #
+#  ./mg-schema-test-database daemons [_SUFFIX]
+#
+# synchronously runs owner and queue daemons for your test database
+#
+# NB that you can't drop a test database with these daemons running,
+# because Postgres will refuse to drop a database that anyone is
+# connected to.
+
 
 set -e -o posix ${OSSTEST_DEBUG:+-x}
 
@@ -114,6 +127,9 @@ END
 }
 
 withtest () {
+   if ! [ -e "$tcfg" ]; then
+   fail "test $dbname not set up ($tcfg does not exist)"
+   fi
OSSTEST_CONFIG="$test_cfg_setting" "$@"
 }
 
@@ -194,6 +210,10 @@ create)
;;
-f*)minflight="${arg#-f}"
;;
+   -h*)ctrlhost="${arg#-h}"
+   ;;
+   -p*)ctrlports="${arg#-p}"
+   ;;
*)  fail "bad arg to create"
;;
esac
@@ -224,6 +244,18 @@ END
;;
esac
 
+   if [ "x$ctrlhost" = x ]; then
+   ctrlhost=localhost
+   fi
+   case "$ctrlports" in
+   *,*);;
+   ?*) ctrlports+=,$(( $ctrlports + 1 )) ;;
+   '')
+ ctrlports=$(( $(getconfig OwnerDaemonPort) + 2)),$((
+   $(getconfig QueueDaemonPort) + 2))
+   ;;
+   esac
+
#-- preparation and data-gathering --
 
bad=$(  psql_query <$tcfg.tmp -we '
@@ -450,6 +484,27 @@ END
 
;;
 
+#== DAEMONS ==
+
+daemons)
+   parse_only_suffix "$@"
+
+   dbname
+
+   printf "Running daemons for %s\n" "$dbname"
+
+   withtest \
+   exec_resetting_sigint ./ms-ownerdaemon &
+
+   sleep 1
+
+   withtest \
+   exec_resetting_sigint ./ms-queuedaemon &
+
+   wait
+
+   ;;
+
 #== EPILOGUE ==
 
 *)
-- 
1.7.10.4


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

[Xen-devel] [PATCH v2] libxl: free ifname on libxlDomainMigrationPrepareDef

[Joao Martins]

Commit d2e5538b1 changes virDomainDef to include ifnames
that autogenerated by libxl, and that are also cleared
on domain cleanup. One place that's missing is on
migration, when domain xml is sent to dst libvirtd and
would contain ifnames from the source libvirtd. This
would lead to erronous behaviour (as seen in osstest CI)
such as failing to migrate when a vif with the same name
existed (belonging to another domain) on destination.

This patch adds a helper libxlDomainFreeIfaceNames for
clearing ifnames on both migration prepare phase and domain
cleanup. It is done on prepare phase so that we don't affect
source domain (specially in cases when the migration fails),
while still allowing interface stats to be consulted during
the migration.

Signed-off-by: Joao Martins 
---
Changes since v1:
 - Commit message is changed
 - Clear ifnames on prepare phase as opposed to begin phase.
---
 src/libxl/libxl_domain.c| 32 ++--
 src/libxl/libxl_domain.h|  3 +++
 src/libxl/libxl_migration.c |  2 ++
 3 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index ef92974..487589d 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -728,16 +728,7 @@ libxlDomainCleanup(libxlDriverPrivatePtr driver,
 }
 }
 
-if ((vm->def->nnets)) {
-size_t i;
-
-for (i = 0; i < vm->def->nnets; i++) {
-virDomainNetDefPtr net = vm->def->nets[i];
-
-if (STRPREFIX(net->ifname, "vif"))
-VIR_FREE(net->ifname);
-}
-}
+libxlDomainFreeIfaceNames(vm->def);
 
 if (virAsprintf(&file, "%s/%s.xml", cfg->stateDir, vm->def->name) > 0) {
 if (unlink(file) < 0 && errno != ENOENT && errno != ENOTDIR)
@@ -923,6 +914,27 @@ libxlDomainCreateIfaceNames(virDomainDefPtr def, 
libxl_domain_config *d_config)
 }
 }
 
+/*
+ * Removes autogenerated interface names for the network devices in
+ * parameter def. User-provided interface names are skipped.
+ */
+void
+libxlDomainFreeIfaceNames(virDomainDefPtr def)
+{
+size_t i;
+
+for (i = 0; i < def->nnets; i++) {
+virDomainNetDefPtr net = def->nets[i];
+
+if (!net->ifname)
+continue;
+
+if (STRPREFIX(net->ifname, "vif"))
+VIR_FREE(net->ifname);
+}
+}
+
+
 
 /*
  * Start a domain through libxenlight.
diff --git a/src/libxl/libxl_domain.h b/src/libxl/libxl_domain.h
index 44b3e0b..70c139c 100644
--- a/src/libxl/libxl_domain.h
+++ b/src/libxl/libxl_domain.h
@@ -135,6 +135,9 @@ int
 libxlDomainSetVcpuAffinities(libxlDriverPrivatePtr driver,
  virDomainObjPtr vm);
 
+void
+libxlDomainFreeIfaceNames(virDomainDefPtr def);
+
 int
 libxlDomainStart(libxlDriverPrivatePtr driver,
  virDomainObjPtr vm,
diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c
index 0d23e5f..1ca31ab 100644
--- a/src/libxl/libxl_migration.c
+++ b/src/libxl/libxl_migration.c
@@ -288,6 +288,8 @@ libxlDomainMigrationPrepareDef(libxlDriverPrivatePtr driver,
 VIR_DOMAIN_DEF_PARSE_INACTIVE)))
 goto cleanup;
 
+libxlDomainFreeIfaceNames(def);
+
 if (dname) {
 name = def->name;
 if (VIR_STRDUP(def->name, dname) < 0) {
-- 
2.1.4


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

[Xen-devel] [qemu-mainline baseline-only test] 38431: trouble: blocked/broken/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   4 capture-logs !broken [st=!broken!]
 build-amd64-xsm   4 capture-logs !broken [st=!broken!]
 build-i386-xsm4 capture-logs !broken [st=!broken!]
 build-amd64-pvops 4 capture-logs !broken [st=!broken!]
 build-i386-pvops  4 capture-logs !broken [st=!broken!]
 build-i3864 capture-logs !broken [st=!broken!]
 test-armhf-armhf-xl-xsm   3 host-install(3) broken REGR. vs. 38307
 test-armhf-armhf-xl-credit2   3 host-install(3) broken REGR. vs. 38307
 test-armhf-armhf-xl   3 host-install(3) broken REGR. vs. 38307
 build-amd64   3 host-install(3) broken REGR. vs. 38307
 test-armhf-armhf-xl-vhd   3 host-install(3) broken REGR. vs. 38307
 test-armhf-armhf-xl-midway3 host-install(3) broken REGR. vs. 38307
 test-armhf-armhf-xl-multivcpu  3 host-install(3)broken REGR. vs. 38307
 build-amd64-xsm   3 host-install(3) broken REGR. vs. 38307
 build-i386-xsm3 host-install(3) broken REGR. vs. 38307
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 38307
 build-i386-pvops  3 host-install(3) broken REGR. vs. 38307
 build-i3863 host-install(3) broken REGR. vs. 38307

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm  3 host-install(3) broken REGR. vs. 38307
 test-armhf-armhf-libvirt-raw  3 host-install(3) broken REGR. vs. 38307
 test-armhf-armhf-libvirt-qcow2  3 host-install(3)   broken REGR. vs. 38307
 test-armhf-armhf-libvirt  3 host-install(3) broken REGR. vs. 38307
 test-armhf-armhf-xl-rtds  3 host-install(3) broken REGR. vs. 38307
 test-armhf-armhf-libvirt  4 capture-logs(4)broken blocked in 38307
 test-armhf-armhf-xl   4 capture-logs(4)broken blocked in 38307
 test-armhf-armhf-xl-vhd   4 capture-logs(4)broken blocked in 38307
 test-armhf-armhf-xl-midway4 capture-logs(4)broken blocked in 38307

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   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-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   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-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-pair  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-chec

[Xen-devel] [xen-4.6-testing test] 65355: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail REGR. vs. 63449

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start.2  fail in 65227 pass in 65283
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail in 65283 pass in 65210
 test-amd64-i386-rumpuserxen-i386 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 65299 pass in 65355
 test-armhf-armhf-xl-rtds 11 guest-startfail in 65299 pass in 65355
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail in 65299 pass in 65355
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail pass in 65227
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail pass in 65299

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail in 65227 like 63379
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 63449

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

version targeted for testing:
 xen  78833c04250416f1870c458309d3ac0e5cf915fd
baseline version:
 xen  40d7a7454835c2f7c639c78f6c09e7b6f0e4a4e2

Last test of basis63449  2015-11-01 10:09:20 Z   33 days
Failing since 64055  2015-11-10 11:39:11 Z   24 days   23 attempts
Testing same since64935  2015-11-20 02:51:37 Z   14 days   17 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Kevin Tian 

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

[Xen-devel] Taking on a Xen development project

[jtotto]

Hi,

We're a team of three fourth-year undergraduate software engineering
students at the University of Waterloo in Canada.  We're in the process
of planning for our capstone design project, and are interested in
contributing to Xen.  Ideally, we'd like to take on a hypervisor/kernel
hacking project with roughly the same scope as a Google Summer of Code
project (like the hypervisor or domain support projects described at
[0]), following a similar timeline (roughly May to August 2016).  We're
all broadly interested in systems programming in C, and have each had
relevant academic and internship experiences.

Each of projects [1-3] currently on the Wiki look interesting, though
we'd be completely open to others as well.  In particular, we'd be open
to picking up Ben Catterall's work on HVM x86 deprivileged mode [4].  Do
any of these projects seem like a good fit in terms of usefulness to the
community and our timeline?  If so, we'd love to communicate more with
any maintainers with projects in mind!  We were also hoping to
familiarize ourselves with the project by addressing some Coverity
issues, if any are open at the moment.

Thanks!

Harley Armstrong, Chester Lin, Joshua Otto

[0] http://wiki.xenproject.org/wiki/GSoC_2015
[1]  

[2]  

[3]  

[4]  







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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 6e3e562c9d3f3737b718b5be9c9a64e98784890b
baseline version:
 ovmf e04671e81a7fe842f640a926171048e5524b46e0

Last test of basis65336  2015-12-03 18:07:59 Z1 days
Testing same since65359  2015-12-04 06:44:53 Z0 days1 attempts


People who touched revisions under test:
  Eugene Cohen 
  Jiaxin Wu 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=6e3e562c9d3f3737b718b5be9c9a64e98784890b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
6e3e562c9d3f3737b718b5be9c9a64e98784890b
+ branch=ovmf
+ revision=6e3e562c9d3f3737b718b5be9c9a64e98784890b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' x6e3e562c9d3f3737b718b5be9c9a64e98784890b = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 
'git://cache:9

Re: [Xen-devel] Skylake: VT-d and other error messages

[Eric Shelton]

On Wed, Dec 2, 2015 at 10:41 AM, Jan Beulich  wrote:

> >>> On 02.12.15 at 16:37,  wrote:
> > On Dec 2, 2015, at 10:28 AM, Jan Beulich  wrote:
> >
> > On 02.12.15 at 16:04,  wrote:
> >>> I have attached the output from 'xl dmesg' with iommu=debug
> >>> apic_verbosity=debug loglvl=all
> >>
> >> As of 4.6.0 it actually takes a debug hypervisor to get those
> >> messages logged (which arguably is wrong, and which quite
> >> certainly is wrong for messages accompanying error returns).
> >
> > So when I rebuild the hypervisor, it sounds like I should be doing a
> debug
> > build?
>
> Yes please.
>
>
With my current setup, it was easier for me to go back to 4.4.3.
Apparently the IOAPIC is at :f0.1f.0.  Output from 'xl dmesg'' is
attached.

Eric
.3-7)) debug=n Fri Dec  4 18:12:56 UTC 2015
(XEN) Latest ChangeSet: 
(XEN) Bootloader: GRUB 2.00
(XEN) Command line: placeholder console=none dom0_mem=min:1024M 
dom0_mem=max:4096M iommu=debug loglvl=all apic_verbosity=debug
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)   - 0009c800 (usable)
(XEN)  0009c800 - 000a (reserved)
(XEN)  000e - 0010 (reserved)
(XEN)  0010 - 70ec5000 (usable)
(XEN)  70ec5000 - 70ec6000 (ACPI NVS)
(XEN)  70ec6000 - 70ef (reserved)
(XEN)  70ef - 70f43000 (usable)
(XEN)  70f43000 - 71648000 (reserved)
(XEN)  71648000 - 76b9d000 (usable)
(XEN)  76b9d000 - 777b (reserved)
(XEN)  777b - 77f9a000 (ACPI NVS)
(XEN)  77f9a000 - 77fff000 (ACPI data)
(XEN)  77fff000 - 7800 (usable)
(XEN)  7800 - 7810 (reserved)
(XEN)  e000 - f000 (reserved)
(XEN)  fe00 - fe011000 (reserved)
(XEN)  fec0 - fec01000 (reserved)
(XEN)  fee0 - fee01000 (reserved)
(XEN)  ff00 - 0001 (reserved)
(XEN)  0001 - 00087600 (usable)
(XEN) ACPI: RSDP 000F05B0, 0024 (r2 ALASKA)
(XEN) ACPI: XSDT 77A1F098, 00B4 (r1 ALASKA   A M I   1072009 AMI 10013)
(XEN) ACPI: FACP 77A41B30, 010C (r5 ALASKA   A M I   1072009 AMI 10013)
(XEN) ACPI: DSDT 77A1F1E8, 22943 (r2 ALASKA   A M I   1072009 INTL 20120913)
(XEN) ACPI: FACS 77F99F80, 0040
(XEN) ACPI: APIC 77A41C40, 0084 (r3 ALASKA   A M I   1072009 AMI 10013)
(XEN) ACPI: FPDT 77A41CC8, 0044 (r1 ALASKA   A M I   1072009 AMI 10013)
(XEN) ACPI: FIDT 77A41D10, 009C (r1 ALASKA   A M I   1072009 AMI 10013)
(XEN) ACPI: MCFG 77A41DB0, 003C (r1 ALASKAA M I  1072009 MSFT   97)
(XEN) ACPI: HPET 77A41DF0, 0038 (r1 ALASKAA M I  1072009 AMI.5000B)
(XEN) ACPI: SSDT 77A41E28, 036D (r1 SataRe SataTabl 1000 INTL 20120913)
(XEN) ACPI: LPIT 77A42198, 0094 (r1 INTEL   SKL0 MSFT   5F)
(XEN) ACPI: SSDT 77A42230, 002B (r2 INTEL  UsbCTabl 1000 INTL 20120913)
(XEN) ACPI: DBGP 77A42260, 0034 (r1 INTEL  0 MSFT   5F)
(XEN) ACPI: DBG2 77A42298, 0054 (r0 INTEL  0 MSFT   5F)
(XEN) ACPI: SSDT 77A422F0, 0618 (r2  INTEL xh_rvp080 INTL 20120913)
(XEN) ACPI: AAFT 77A42908, 051A (r1 ALASKA OEMAAFT   1072009 MSFT   97)
(XEN) ACPI: SSDT 77A42E28, 5212 (r2 SaSsdt  SaSsdt  3000 INTL 20120913)
(XEN) ACPI: UEFI 77A48040, 0042 (r10 0)
(XEN) ACPI: SSDT 77A48088, 0E58 (r2 CpuRef  CpuSsdt 3000 INTL 20120913)
(XEN) ACPI: DMAR 77A48EE0, 00A8 (r1 INTEL  SKL 1 INTL1)
(XEN) ACPI: ASF! 77A48F88, 00A5 (r32 INTEL   HCG1 TFSMF4240)
(XEN) System RAM: 32452MB (33230888kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at -00087600
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000fc670
(XEN) DMI 2.8 present.
(XEN) APIC boot state is 'xapic'
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x1808
(XEN) ACPI: v5 SLEEP INFO: control[1:1804], status[1:1800]
(XEN) ACPI: Invalid sleep control/status register data: 0:0x8:0x3 0:0x8:0x3
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1804,0], pm1x_evt[1800,0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT - 77f99f80/, 
using 32
(XEN) ACPI: wakeup_vec[77f99f8c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee0
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
(XEN) Processor #6 7:14 APIC version 21
(XEN) ACPI: L

[Xen-devel] [xen-4.6-testing baseline-only test] 38429: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 38429 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38429/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  3 host-install(3) broken REGR. vs. 38242
 test-amd64-amd64-rumpuserxen-amd64  3 host-install(3)   broken REGR. vs. 38242
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3)  broken REGR. vs. 38242
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 
38242
 test-amd64-i386-xl-xsm3 host-install(3) broken REGR. vs. 38242
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 38242
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 38242
 test-amd64-i386-xl-qemut-win7-amd64  3 host-install(3)  broken REGR. vs. 38242
 test-amd64-i386-xl-qemuu-ovmf-amd64 19 guest-start/debianhvm.repeat fail REGR. 
vs. 38242
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 17 guest-stopfail REGR. vs. 38242
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 19 guest-start/win.repeat fail REGR. 
vs. 38242
 build-i386-prev   5 xen-build fail REGR. vs. 38242
 test-amd64-i386-xl-qemut-winxpsp3 12 guest-stop   fail REGR. vs. 38242
 test-amd64-i386-xl-qemut-winxpsp3 11 saverestore-support-check fail REGR. vs. 
38242
 test-amd64-i386-xl-qemut-winxpsp3 10 migrate-support-check fail REGR. vs. 38242

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-xsm  3 host-install(3) broken REGR. vs. 38242
 test-amd64-amd64-libvirt  3 host-install(3) broken REGR. vs. 38242
 test-amd64-amd64-libvirt-vhd  3 host-install(3) broken REGR. vs. 38242
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken 
REGR. vs. 38242
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken 
REGR. vs. 38242
 test-amd64-i386-libvirt-xsm   3 host-install(3) broken REGR. vs. 38242
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 4 capture-logs(4) broken 
blocked in 38242
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 38242
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install  fail like 38242

Tests which did not succeed, but are not blocking:
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-i386-rumpuserxen-i386  4 capture-logs(4)  broken never pass
 test-amd64-amd64-libvirt-xsm  4 capture-logs(4)  broken never pass
 test-amd64-amd64-rumpuserxen-amd64  4 capture-logs(4)broken never pass
 test-amd64-amd64-libvirt  4 capture-logs(4)  broken never pass
 test-amd64-amd64-libvirt-vhd  4 capture-logs(4)  broken never pass
 test-amd64-i386-libvirt-xsm   4 capture-logs(4)  broken never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 4 capture-logs(4) broken 
never pass
 test-amd64-i386-xl-qemuu-win7-amd64  4 capture-logs(4)   broken never pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64  4 capture-logs(4)  broken never pass
 test-amd64-i386-xl-xsm4 capture-logs(4)  broken never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  4 capture-logs(4)  broken never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  4 capture-logs(4)broken never pass
 test-amd64-i386-xl-qemut-win7-amd64  4 capture-logs(4)   broken never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64 20 capture-logs(20)  broken never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 18 capture-logs(18) broken never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 20 capture-logs(20) broken never pass
 test-amd64-i386-xl-qemut-winxpsp3 13 capture-logs(13)broken never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-check

Re: [Xen-devel] [PATCH v13 7/8] Add IOREQ_TYPE_VMWARE_PORT

[Don Slutz]

On 12/04/15 03:59, Paul Durrant wrote:
>> -Original Message-
>> From: Don Slutz [mailto:don.sl...@gmail.com]
>> Sent: 04 December 2015 00:23
>> To: Paul Durrant; xen-devel@lists.xen.org
>> Cc: Jun Nakajima; Wei Liu; Kevin Tian; Keir (Xen.org); Ian Campbell; George
>> Dunlap; Andrew Cooper; Stefano Stabellini; Eddie Dong; Don Slutz; Tim
>> (Xen.org); Aravind Gopalakrishnan; Jan Beulich; Suravee Suthikulpanit; Boris
>> Ostrovsky; Ian Jackson
>> Subject: Re: [Xen-devel] [PATCH v13 7/8] Add IOREQ_TYPE_VMWARE_PORT
>>
>> On 12/01/15 06:28, Paul Durrant wrote:
 -Original Message-
 From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
 boun...@lists.xen.org] On Behalf Of Don Slutz
 Sent: 28 November 2015 21:45
 To: xen-devel@lists.xen.org
 Cc: Jun Nakajima; Wei Liu; Kevin Tian; Keir (Xen.org); Ian Campbell;
>> George
 Dunlap; Andrew Cooper; Stefano Stabellini; Eddie Dong; Don Slutz; Don
>> Slutz;
 Tim (Xen.org); Aravind Gopalakrishnan; Jan Beulich; Suravee
>> Suthikulpanit;
 Boris Ostrovsky; Ian Jackson
 Subject: [Xen-devel] [PATCH v13 7/8] Add IOREQ_TYPE_VMWARE_PORT

 From: Don Slutz 

>> ...

  /* Verify the emulation request has been correctly re-issued */
 -if ( (p.type != is_mmio ? IOREQ_TYPE_COPY : IOREQ_TYPE_PIO) ||
 +if ( (p.type != (is_mmio ? IOREQ_TYPE_COPY : is_vmware ?
 IOREQ_TYPE_VMWARE_PORT : IOREQ_TYPE_PIO)) ||
>>>
>>> is_vmware already incorporated !is_mmio so there's a redundant
>>> check in that expression. The extra test also makes it look
>>> pretty ugly... probably better re-factored into an if
>>> statement.
>>>
>>
>> Ok, Will add a variable, that is set via an if statement.  Thinking about:
>>
>>   case STATE_IORESP_READY:
>> +{
>> +uint8_t calc_type = p.type;
>> +
>> +if ( is_vmware )
>> +calc_type = IOREQ_TYPE_VMWARE_PORT;
>> +
>>  vio->io_req.state = STATE_IOREQ_NONE;
>>  p = vio->io_req;
>>
>>  /* Verify the emulation request has been correctly re-issued */
>> -if ( (p.type != is_mmio ? IOREQ_TYPE_COPY : IOREQ_TYPE_PIO) ||
>> +if ( (p.type != calc_type) ||
>>
>>
>>
>>
   (p.addr != addr) ||
   (p.size != size) ||
   (p.count != reps) ||
>> ...
 +
 +p.type = IOREQ_TYPE_VMWARE_PORT;
 +vio->io_req.type = IOREQ_TYPE_VMWARE_PORT;
>>>
>>> This could be done in a single statement.
>>>
>>
>> Ok.
>>
>>  p.type = vio->io_req.type = IOREQ_TYPE_VMWARE_PORT;
>>
>> or
>>
>>  vio->io_req.type = p.type = IOREQ_TYPE_VMWARE_PORT;
>>
>> is clearer to you?
> 
> I think that the former is probably better.
> 

Will use this.

>>
 +s = hvm_select_ioreq_server(curr->domain, &p);
>> ...

  if ( rc )
 -hvm_unmap_ioreq_page(s, 0);
 +{
 +hvm_unmap_ioreq_page(s, IOREQ_PAGE_TYPE_IOREQ);
 +return rc;
 +}
 +
 +rc = hvm_map_ioreq_page(s, IOREQ_PAGE_TYPE_VMPORT,
 vmport_ioreq_pfn);
>>>
>>> Is every ioreq server going to have one of these? It doesn't look
>>> like it, so should you not have validity check on the pfn?
>>>
>>
>>
>> Currently the default is that all ioreq servers get the mapping:
>>
> 
> That's probably a bit wasteful. It should probably be
> selectable in the create HVM op.

Since the most common case is QEMU and it can use it since upstream
version 2.2.0, the waste is real small.  If a non-QEMU ioreq server does
not want it, it add 0 overhead.  The only case I know of (which is PVH
related to PVH) is if QEMU is not running and you add a non-QEMU ioreq
server that does not use it, you get 1 page + page table entries.

While the following exists:

#define HVM_IOREQSRV_BUFIOREQ_OFF0
#define HVM_IOREQSRV_BUFIOREQ_LEGACY 1
/*
 * Use this when read_pointer gets updated atomically and
 * the pointer pair gets read atomically:
 */
#define HVM_IOREQSRV_BUFIOREQ_ATOMIC 2
uint8_t handle_bufioreq; /* IN - should server handle buffered ioreqs */

I see no tests that use these.  Also adding vmport enable/disable to
handle_bufioreq is much more of a hack then I expect to pass a code
review.

Does not look simple to add a new additional argument, but that could
just be my lack of understanding in the area.

> I don't know whether you'd
> even need it there in the default server since I guess the QEMU
> end of things post-dates the use of the HVM op (rather than the
> old param).
> 

Not sure how to parse "post-dates".  Here is some tables about this that
I know about:


xen Supportshandle_bufioreq
 create_ioreq_server
4.5 yes 0 or !0
4.6 yes 0 or !0
4.7 yes 0 or !0

Upstream vmport is_default atomic
 QEMU support

2.2.xyesyesn/a
2.3.xyesno no
2.4.xyesno no
2.5.xyes 

[Xen-devel] fyi, Xen's EFI workarounds (/mapbs & efi=no-rs) on SuperMicro hardware; fixes solve 1/2 problems & SM responds that can't/won't fix their firmware

[PGNet Dev]

I run Xen 4.6 Dom0 on an Opensuse Leap 42.1 server.

Hardware is a SuperMicro X10SAT motherboard 
(http://www.supermicro.com/products/motherboard/Xeon/C220/X10SAT.cfm), 
with AMI v3 BIOS + "UEFI support"


Two issues exist with the SuperMicro EFI

(1) firmware EFI mis-mapping causing Xen PANIC on restart
(2) EFI variables not persistent across reboot

SuperMicro's development/support has been made aware of both issues; 
Their response is that they won't/can't fix the problem.


I do NOT know if the problems exist with other SM boards' EFI 
implementations.


Xen's EFI workarounds work to fix (1), not (2) (admittedly, not a 
xen-specific issue ... just crops up when GRUB2-ing your way to Xen boot)


In #xen, it was suggested that I document the issue to the xen-devel ML, 
just for the record.  Hence, detail follows:


Xen Dom0 version

xen-4.6.0_04-398.3.x86_64

on Opensuse server

lsb_release -rd
Description:openSUSE Leap 42.1 (x86_64)
Release:42.1
uname -rm
4.3.0-21.g0e6e680-default x86_64

The board/bios info

dmidecode
# dmidecode 2.12
# SMBIOS entry point at 0x000f04c0
SMBIOS 2.7 present.
81 structures occupying 3317 bytes.
Table at 0x000EC200.
...
System Information
Manufacturer: Supermicro
Product Name: X10SAT
...
BIOS Information
Vendor: American Megatrends Inc.
Version: 3.0
Release Date: 05/26/2015
Address: 0xF
Runtime Size: 64 kB
ROM Size: 16384 kB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 
13h)
3.5"/720 kB floppy services are supported (int 
13h)
3.5"/2.88 MB floppy services are supported (int 
13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 4.6

BIOS is updated with latest available version,

X10SAT5.526

and EFI reports

Shell> ver
EFI Specification Revision : 2.31
EFI Vendor : American Megatrends
EFI Revision   : 4.655

Not clear whether they're using tianocore UEFI code.



Demonstration of (2), non-persistence of EFI boot vars:

@ OS shell, make changes to the MoBo's EFI NVRAM.  E.g.,

efibootmgr -c -d /dev/sdg -p 2 -l 
\\EFI\\opensuse\\xen-4.6.0_02-397.efi -L OpenSuse-Xen

efibootmgr -c -d /dev/sdg -p 2 -l \\EFI\\XEN\\xen.efi -L Custom-Xen

efibootmgr
BootOrder: 0001,
Boot* OpenSuse-Xen
Boot0001* Custom-Xen

efibootmgr -o 0,1

efibootmgr
BootOrder: ,0001
Boot* OpenSuse-Xen
Boot0001* Custom-Xen

after reboot, re-checking the EFI variables presented from the motherboard,

efibootmgr -v
(empty)

the vars are NOT persistent, and have been removed.



Documentation of (1), EFI mapping, Xen PANIC & workarounds

(A) boot & shutdown, Xen PANIC, no EFI 'fixes'

Xen 4.6.0_04-398 (c/s ) EFI loader
Using configuration file 'xen-4.6.0_04-398.cfg'
vmlinuz-4.3.0-21.g0e6e680-default: 0x8c08c000-0x8c65ee60
initrd-4.3.0-21.g0e6e680-default: 0x8b12-0x8c08bf9c
0x:0x00:0x19.0x0: ROM: 0x1 bytes at 0x92892018
0x:0x04:0x00.0x0: ROM: 0x8000 bytes at 0x92889018
0x:0x10:0x00.0x0: ROM: 0x10800 bytes at 0x92871018
 __  ___  ______ ___  _  _ _ ___   ___
 \ \/ /___ _ __   | || |  / /_  / _ \   / _ \| || |   |___ // _ \ ( _ )
  \  // _ \ '_ \  | || |_| '_ \| | | | | | | | || |_ __ |_ \ (_) |/ _ \
  /  \  __/ | | | |__   _| (_) | |_| | | |_| |__   _|__|__) \__, 

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 6e3e562c9d3f3737b718b5be9c9a64e98784890b
baseline version:
 ovmf e04671e81a7fe842f640a926171048e5524b46e0

Last test of basis38427  2015-12-04 06:56:15 Z0 days
Testing same since38447  2015-12-04 21:32:45 Z0 days1 attempts


People who touched revisions under test:
  Eugene Cohen 
  Jiaxin Wu 

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



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

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

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


Push not applicable.


commit 6e3e562c9d3f3737b718b5be9c9a64e98784890b
Author: Jiaxin Wu 
Date:   Fri Dec 4 01:10:17 2015 +

ShellPkg: Fix wrong return status for Ifconfig.c

The Ifconfig command handler tries to return an EFI_STATUS when
the return type should be SHELL_STATUS.

Cc: Cohen Eugene 
Cc: Carsey Jaben 
Cc: Ye Ting 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
Reviewed-by: Jaben Carsey 
Reviewed-by: Ye Ting 
Reviewed-by: Ard Biesheuvel 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19110 
6f19259b-4bc3-4df7-8a09-765794883524

commit efda17751344965c7f51cbd0660ed6a59e2de855
Author: Eugene Cohen 
Date:   Thu Dec 3 20:28:02 2015 +

ArmPkg: update RVCT assembly functions to use new RVCT_ASM_EXPORT macro

This has the effect of splitting assembly functions into their own sections
so the linker can remove unused ones to save space.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eugene Cohen 
Reviewed-by: Ard Biesheuvel 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19109 
6f19259b-4bc3-4df7-8a09-765794883524

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-boot fail REGR. vs. 59254
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-freebsd10-i386  6 xen-bootfail REGR. vs. 59254
 test-amd64-i386-rumpuserxen-i386  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-freebsd10-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-win7-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-xsm6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-win7-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-amd64-xl   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-qemut-rhel6hvm-amd  6 xen-bootfail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
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-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 59254
 test-amd64-i386-pair 10 xen-boot/dst_host fail REGR. vs. 59254
 test-amd64-i386-pair  9 xen-boot/src_host fail REGR. vs. 59254
 test-amd64-i386-qemuu-rhel6hvm-amd  6 xen-bootfail REGR. vs. 59254
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 
fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot   fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-xsm   6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-libvirt   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-raw6 xen-bootfail baseline untested
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail baseline 
untested
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host   fail baseline untested
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host   fail baseline untested
 test-amd64-amd64-i386-pvgrub  6 xen-bootfail baseline untested
 test-amd64-amd64-libvirt-vhd  9 debian-di-install   fail baseline untested
 test-armhf-armhf-libvirt-raw  6 xen-bootfail baseline untested
 test-armhf-armhf-libvirt-qcow2  6 xen-boot  fail 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-amd64-qemuu-nested-amd  6 xen-boot  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-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 linux071f5d105a0ae93aeb02197c4ee3557e8cc57a21
baseline version:
 linux45820c294fe1b1

Re: [Xen-devel] fyi, Xen's EFI workarounds (/mapbs & efi=no-rs) on SuperMicro hardware; fixes solve 1/2 problems & SM responds that can't/won't fix their firmware

[Zir Blazer]

> Hardware is a SuperMicro X10SAT motherboard
> (http://www.supermicro.com/products/motherboard/Xeon/C220/X10SAT.cfm),
> with AMI v3 BIOS + "UEFI support"
>
> Two issues exist with the SuperMicro EFI
>
> (1) firmware EFI mis-mapping causing Xen PANIC on restart
> (2) EFI variables not persistent across reboot
>
> SuperMicro's development/support has been made aware of both issues;
> Their response is that they won't/can't fix the problem.



I'm a X10SAT owner, I'm using BIOS R2.0 (Don't recall the ZIP name with the 
release date, but I have it stored somewhere). There were also a R2.2 version 
before R3.0 came out (Which should include Broadwell support, since I asked 
Supermicro support about that back when R2.2 was the latest and they said that 
it didn't had it).

The efibootmgr issue you mentioned makes me remember that I found a ugly, 
freeze inducing bug in the BIOS itself. UEFI specification says that the 
Firmware must allow the user to edit NVRAM Boot entries from the Firmware 
itself (Or something along those lines), which the X10SAT, at least on paper, 
appears to do. If you go to the Boot menu, you can use "Add New Boot Option", 
which is supposedly the way you can do what efibootmgr does from inside Linux 
(Writing to Firmware NVRAM), but from the Motherboard Firmware itself. 
Everytime I recall having tried to manually add an option there so I can boot 
doing UEFI -> Xen -> Dom0 instead of UEFI -> Boot Loader/Manager  -> Xen -> 
Dom0 (Or just base Linux, without Xen), after properly setting up the option 
and Xen/Linux Kernel parameters, trying to switch to another menu freezes the 
BIOS. On rebooting, there was nothing at all.
I didn't tested that again before sending you this mail, nor reported the bug 
to Supermicro, but I recall it was that way - you may want to try it, chances 
are that you can reproduce the freeze in R3.0, as your mail seems to point that 
all is related to the same volatile NVRAM issue.

Also, while I don't recall any Xen panic, since I started to sucessfully use 
UEFI Boot (Back when Linux Kernel 3.17 was released, as that was the very first 
Kernel that I got UEFI Boot working with. 3.17 introduced official Xen Dom0 
support, some people got it working before that on other platforms, but I had 
to wait specifically for that Kernel), what I noticed is that using the reboot 
command may freeze at the very last step ("Restarting the system..." I think it 
was). It doesn't always happens, seems to do so more often if I use reboot soon 
after booting, don't recall it freezing when issuing reboot if left on for long 
periods (Days).
I'm using Arch Linux, Xen 4.5, and Kernel 4.0.1, but I recall the reboot issue 
being much older, chances are that I first encounter it with Xen 4.3 and Kernel 
3.17, and very possibily is Firmware related. I don't recall that it ever 
freezed when NOT using Xen, which is basically when launching standalone Arch 
Linux.

You can workaround your UEFI Boot issue if you use a Boot Manager like 
Gummiboot (Which has been deprecated, no idea what currently replaces it). If I 
recall correctly, even with a broken NVRAM, UEFI specification says that by 
default the Firmware should attempt to load \EFI\BOOT\BOOTX64.EFI from the ESP 
(EFI System Partition) of the selected unit if no specific EFI file is 
selected. A Boot Manager that works by replacing BOOTX64.EFI with its own 
(Gummiboot does), and creates a menu with entries that you can store in the 
ESP, which should be in a non-volatile HD/SSD, should allow you to fully 
workaround that issue. That's the same workaround that allow you to have a OVMF 
(UEFI) based VM in Xen with persistent settings, since Xen has no way currently 
to save OVMF NVRAM settings (Basically, X10SAT issue, VM side).
On a sidenote, I don't know why everyone wants to use GRUB to chainload the Xen 
EFI image. You can use a less bloated Boot Loader/Manager and achieve the same 
results, no idea what makes GRUB better than telling the Firmware to boot the 
Xen EFI image directly (And its one less step).


All in all, I'm extremely satisfied with my X10SAT, even would recommend and 
buy it again. Supermicro support was at least more helpful than the other 
consumer oriented vendors I know (Mainly ASUS, I dislike them), and their 
Firmware also seems a bit more polished - I can guarantee you, its more UEFI 
compliant that it looks since I didn't faced common issues when UEFI Booting 
that I hear other users had in other platforms.
I myself spend months researching on a Motherboard that got a working VT-d 
implementation since a truckload of Motherboards brands and models had broken 
implementations which no maker cared to fix, yet the X10SAT delivered 
flawlessly. Sadly, no Motherboard vendor that I know of has a perfect Firmware, 
what one got properly working, is totally broken on another one, as you can see 
that there are also those flaws in X10SAT, too. I don't know if there is a 
better Server Motherboard for LGA 1150 Has

[Xen-devel] [linux-next test] 65364: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail REGR. vs. 65329

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rumpuserxen-i386 10 guest-start  fail blocked in 65329
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stopfail blocked in 65329
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail blocked in 65329
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 65329
 test-armhf-armhf-xl-xsm   6 xen-boot fail   like 65329
 test-armhf-armhf-xl-vhd   6 xen-boot fail   like 65329
 test-armhf-armhf-xl-arndale   6 xen-boot fail   like 65329
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  like 65329
 test-armhf-armhf-xl-credit2   6 xen-boot fail   like 65329
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail   like 65329
 test-armhf-armhf-libvirt-raw  6 xen-boot fail   like 65329
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 65329
 test-armhf-armhf-xl-rtds  6 xen-boot fail   like 65329
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail like 65329
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   like 65329
 test-armhf-armhf-xl   6 xen-boot fail   like 65329
 test-armhf-armhf-libvirt  6 xen-boot fail   like 65329
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail like 65329

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

version targeted for testing:
 linuxdcccebc04ddba852aad354270986d508e8f011c0
baseline version:
 linux25364a9e54fb8296837061bf684b76d20eec01fb

Last test of basis  (not found) 
Failing since 0  1970-01-01 00:00:00 Z 16774 days
Testing same since65364  2015-12-04 09:28:18 Z0 days1 attempts

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-xsmfail
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm pass

Re: [Xen-devel] [PATCH 0/2] VT-d flush issue

[Xu, Quan]

On 04.12.2015 at 2:55pm,  wrote:
> >>> "Tian, Kevin"  12/04/15 2:49 AM >>>
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Thursday, December 03, 2015 9:16 PM
> >> >>> On 03.12.15 at 09:09,  wrote:
> >> > If impacted domain is Dom0 or hardware domain, just throw out a
> warning.
> >> > It's an open here whether we want to kill
> >> > Dom0 or hardware domain (or directly panic hypervisor).
> >> > Comments are welcomed.
> >>
> >> I think that's a reasonable default, provided by that "Dom0 or
> >> hardware domain" you really just mean the same domain known with two
> >> different names (i.e. Dom0 should not be special when it is not the
> >> hardware domain).
> >
> >Are you suggest just checking hardware_domain should be enough in the
> code?
> 
> Yes, absolutely.


Agreed.

-Quan

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