date:20170525

Re: [Xen-devel] [PATCH v4 for-4.9] x86/vpmu: add cpu hot unplug notifier for vpmu

2017-05-25 Thread Kang, Luwei

Hi Julien,
Follow your advice, I change the tag to [PATCH v4 for-4.9] because of we  
hope this patch can be merged in Xen 4.9.

Hi Jan,
If there have anything need to change in this patch?

Thanks,
Luwei Kang

> -Original Message-
> From: Kang, Luwei
> Sent: Tuesday, May 23, 2017 4:46 AM
> To: xen-devel@lists.xen.org
> Cc: jbeul...@suse.com; andrew.coop...@citrix.com; boris.ostrov...@oracle.com; 
> Kang, Luwei 
> Subject: [PATCH v4] x86/vpmu: add cpu hot unplug notifier for vpmu
> 
> Currently, Hot unplug a physical CPU with vpmu enabled may cause system hang 
> due to send a remote call to an offlined pCPU. This
> patch add a cpu hot unplug notifer to save vpmu context before cpu offline.
> 
> Consider one scenario, hot unplug pCPU N with vpmu enabled.
> The vcpu which running on this pCPU will be switch to other online cpu. A 
> remote call will be send to pCPU N to save the vpmu
> context before loading the vpmu context on this pCPU.
> System will hang in function on_select_cpus() because of that pCPU is 
> offlined and can not do any respond.
> 
> The purpose of add a VPMU_CONTEXT_LOADED check in vpmu_arch_destroy() before 
> send a remote call to save vpmu contex is:
> a. when a vpmu context has been loaded in a remote pCPU, make a
>remote call to save the vpmu contex and stop counters is necessary.
> b. VPMU_CONTEXT_LOADED flag will be reset if a pCPU is offlined.
>this check will prevent send a remote call to an offlined pCPU.
> 
> Signed-off-by: Luwei Kang 
> ---
> v4:
>  1.remove cpu_online() check in vpm_load();  2.remove "vpmu_" prefix;  3.fix 
> a coding style;  4.add some commit message about
> VPMU_CONTEXT_LOADED in vpmu_arch_destroy();
> v3:
>  1.add cpu_online() check in vpm_load() and vpmu_arch_destroy();  2.add vpmu_ 
> prefix. rename cpu_callback() to
> vpmu_cpu_callback();
> v2:
>  1.fix some typo and coding style;
>  2.change "swith" to "if" in cpu_callback() because of there just have one 
> case;  3.add VPMU_CONTEX_LOADED check before send
> remote call in vpmu_arch_destroy();
> ---
>  xen/arch/x86/cpu/vpmu.c | 45 +
>  1 file changed, 41 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c index 
> 03401fd..1f7830b 100644
> --- a/xen/arch/x86/cpu/vpmu.c
> +++ b/xen/arch/x86/cpu/vpmu.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -575,15 +576,21 @@ static void vpmu_arch_destroy(struct vcpu *v)
>   * We will test it again in vpmu_clear_last() with interrupts
>   * disabled to make sure we don't clear someone else.
>   */
> -if ( per_cpu(last_vcpu, vpmu->last_pcpu) == v )
> +if ( cpu_online(vpmu->last_pcpu) &&
> + per_cpu(last_vcpu, vpmu->last_pcpu) == v )
>  on_selected_cpus(cpumask_of(vpmu->last_pcpu),
>   vpmu_clear_last, v, 1);
> 
>  if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
>  {
> -/* Unload VPMU first. This will stop counters */
> -on_selected_cpus(cpumask_of(vcpu_vpmu(v)->last_pcpu),
> - vpmu_save_force, v, 1);
> +/*
> + * Unload VPMU first if VPMU_CONTEXT_LOADED being set.
> + * This will stop counters.
> + */
> +if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
> +on_selected_cpus(cpumask_of(vcpu_vpmu(v)->last_pcpu),
> + vpmu_save_force, v, 1);
> +
>   vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
>  }
>  }
> @@ -835,6 +842,33 @@ long do_xenpmu_op(unsigned int op, 
> XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
>  return ret;
>  }
> 
> +static int cpu_callback(
> +struct notifier_block *nfb, unsigned long action, void *hcpu) {
> +unsigned int cpu = (unsigned long)hcpu;
> +struct vcpu *vcpu = per_cpu(last_vcpu, cpu);
> +struct vpmu_struct *vpmu;
> +
> +if ( !vcpu )
> +return NOTIFY_DONE;
> +
> +vpmu = vcpu_vpmu(vcpu);
> +if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
> +return NOTIFY_DONE;
> +
> +if ( action == CPU_DYING )
> +{
> +vpmu_save_force(vcpu);
> +vpmu_reset(vpmu, VPMU_CONTEXT_LOADED);
> +}
> +
> +return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block cpu_nfb = {
> +.notifier_call = cpu_callback
> +};
> +
>  static int __init vpmu_init(void)
>  {
>  int vendor = current_cpu_data.x86_vendor; @@ -872,8 +906,11 @@ static 
> int __init vpmu_init(void)
>  }
> 
>  if ( vpmu_mode != XENPMU_MODE_OFF )
> +{
> +register_cpu_notifier(_nfb);
>  printk(XENLOG_INFO "VPMU: version " __stringify(XENPMU_VER_MAJ) "."
> __stringify(XENPMU_VER_MIN) "\n");
> +}
>  else
>  opt_vpmu_enabled = 0;
> 
> --
> 1.8.3.1


___
Xen-devel mailing list

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

2017-05-25 Thread osstest service owner

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-examine  3 host-install   broken REGR. vs. 109656
 test-amd64-i386-libvirt-pair 12 host-ping-check-xen/dst_host fail REGR. vs. 
109656
 test-arm64-arm64-libvirt  9 debian-install   fail REGR. vs. 109656
 test-amd64-i386-qemut-rhel6hvm-amd  9 redhat-install fail REGR. vs. 109656
 test-amd64-i386-xl-qemuu-ovmf-amd64 14 guest-saverestore.2 fail REGR. vs. 
109656
 test-armhf-armhf-libvirt-xsm  9 debian-install   fail REGR. vs. 109656

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop  fail blocked in 109656
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 109656
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 109656
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 109656
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 109656
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 109656
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 109656
 test-amd64-amd64-xl-qemut-ws16-amd64  9 windows-installfail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64  9 windows-installfail never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-checkfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386  9 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386  9 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemut-ws16-amd64  9 windows-install fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64  9 windows-install fail

Re: [Xen-devel] [Embedded-pv-devel] Migrated from Xenserver to Gentoo/Xen

2017-05-25 Thread Paul Durrant

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Andrii Anisov
> Sent: 25 May 2017 04:28
> To: Keith Hamilton ; xen-devel  de...@lists.xenproject.org>
> Cc: embedded-pv-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [Embedded-pv-devel] Migrated from Xenserver to
> Gentoo/Xen
> 
> Dear Keith,
> 
> 
> On 25.05.17 04:19, Keith Hamilton wrote:
> >
> > Hey guys.  I just migrated the first of 2 servers from XenServer into
> > a Gentoo/Xen environment.  I’m really excited and it’s working great!
> > However I’m not sure if I’m doing the drivers correctly.  On my Server
> > 2016 vm I am having a hard time overwriting the XenServer PV drivers
> > with the Xen ones from the website it just says that the driver is up
> > to date.  I’m just wondering if I should worry that I don’t have the
> > PV drivers installed from the Xen site and the XenServer ones are
> > going to be ok.  I’m not sure what to do. I did a save state and then
> > did a clean install of my 2016 server with no change.  I have gone
> > into device manager and removed the XenServer Bus interface and a
> > couple others in hopes to be able to install the ones from the
> > XenProject site but it just renders the system unbootable.

That's not entirely surprising. Removing Windows drivers is not an easy thing 
to do and not something that Microsoft really support. You're safest just 
leaving XenServer drivers in place as they are largely the same as the Xen 
Project drivers.
What has probably happened is that, by removing the bus driver you have 
prevented the PV storage driver from coming on line, but all the infrastructure 
is still in place to unplug your emulated storage device. Thus you no longer 
have a system disk and you get a 0x7b BSOD.

> >  I guess my
> > question is, is there any simple way to remove the XenServer PV
> > drivers on my 2016 server so that I can install the proprietary Xen PV
> > drivers without having to do a complete format of the system.  I have
> > already uninstalled all the citrix stuff I had installed..
> >
> > == Keith
> >
> >
> I guess xen-devel is more suitable list to ask server side questions.
> 

win-pv-devel is more appropriate :-)

  Paul

> --
> 
> *Andrii Anisov*
> 
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Question about QEMU as ide device emulator

2017-05-25 Thread Bruno Alvisio

Hello all,

Summary

I am using XEN hypervisor to run a HVM with a QEMU backed disk. After I
start the HVM I use QMP "query-block" command to see the devices of the VM.
Initially the command returns the disk that I set as part of the
configuration but after a few seconds  the "query-block" command returns an
empty result.

KVM Version: 4.6.5
Arch: x86-64
QEMU : 2.2.1


I was expecting to see the device information in QEMU such as:

{"execute":"query-block"}

{"return": [{"io-status": "ok", "device": "ide0-hd0", "locked": false,
"removable": false, "inserted": {"iops_rd": 0, "detect_zeroes": "off",
"image": {"virtual-size": 10737418240, "filename": "/home/balvisio/
debian-disk.img", "format": "raw", "actual-size": 4940075008, "dirty-flag":
false}, "iops_wr": 0, "ro": false, "backing_file_depth": 0, "drv": "raw",
"iops": 0, "bps_wr": 0, "encrypted": false, "bps": 0, "bps_rd": 0, "file":
"/home/balvisio/debian-disk.img", "encryption_key_missing": false}, "type":
"unknown"}]}



I wanted to understand how the storage subsystem work for QEMU backed
disks. Any help and pointers in the code would be great.

Eventually I would like to implement a feature in XEN to allow migration of
instances with local disks.

Thanks,

Bruno


DETAILED LOGS

I am using XEN hypervisor to run a HVM with QEMU backed disk. When I start
the HVM I see the following QEMU process started:

root  2199 1  0 18:57 ?00:00:02
/usr/local/lib/xen/bin/qemu-system-i386 -xen-domid 3 -chardev
socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-3,server,nowait
-no-shutdown -mon chardev=libxl-cmd,mode=control -chardev
socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-3,server,nowait
-mon chardev=libxenstat-cmd,mode=control -nodefaults -no-user-config -name
debianL2 -vnc :0,to=99 -display none -serial pty -device
cirrus-vga,vgamem_mb=8 -boot order=d -device
rtl8139,id=nic0,netdev=net0,mac=00:16:3e:1b:d0:7e
-netdev type=tap,id=net0,ifname=vif3.0-emu,script=no,downscript=no -machine
xenfv -m 1016 -drive file=/home/balvisio/debian-dis
k.img,if=ide,index=0,media=disk,format=raw,cache=writeback -drive
if=ide,index=2,readonly=on,media=cdrom,id=ide-5632,file=/hom
e/balvisio/debian-live-8.7.1-amd64-gnome-desktop.iso,format=raw

After launching the VM, I connected to the QMP socket:

# rlwrap -C qmp socat STDIO UNIX:/var/run/xen/qmp-libxl-2

{"QMP": {"version": {"qemu": {"micro": 1, "minor": 2, "major": 2},
"package": ""}, "capabilities": []}}

{"execute":"qmp_capabilities"}

{"return": {}}

I issue the "query-block" command and I get

{"execute":"query-block"}

{"return": []}


Xen Config File Used

kernel="/usr/local/lib/xen/boot/hvmloader"

builder='hvm'

memory=1024

vcpus=1

name="debianL2"

vfb = ['type=vnc']

vif= ['bridge=xenbr0']

boot='b'

disk=['file:/home/balvisio/debian-disk.img,xvda,w']

acpi=1

device_model_version='qemu-xen'

serial='pty'

vnc=1

vnclisten=""
vncpasswd=""
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] xl create failure on arm64 with XEN 4.9rc6

2017-05-25 Thread Feng Kan

On Thu, May 25, 2017 at 12:56 PM, Julien Grall  wrote:
> (CC toolstack maintainers)
>
> On 25/05/2017 19:58, Feng Kan wrote:
>>
>> Hi All:
>
>
> Hello,
>
>> This is not specifically against the XEN 4.9. I am using 4.12rc2
>> kernel on arm64 platform. Started dom0 fine with ACPI enabled, but
>> failed when creating the domU guest. Xen is built natively on the
>> arm64 platform. Using the same kernel and ramdisk as dom0. Any idea as
>> why it is stuck here
>> would be greatly appreciated?
>
>
> The first step would to try a stable release if you can. Also, it would be
> useful if you provide information about the guest (i.e the configuration)
> and your .config for the kernel.
I am using the default xen_defconfig in the arm64 directory. This is
very early on
in building the domain, would the guest configuration matter?
>
> I gave a try on Linux 4.12rc2 and I was not able to reproduce your error.
Thanks, I started with 4.11 and work my way up. I have the same
problem in both cases.

>
>>
>> xc: error: panic: xc_dom_boot.c:178: xc_dom_boot_domU_map: failed to
>> mmap domU pages 0x450c2+0x2f3d [mmap, errno=22 (Invalid ar
>> gument), chunksize 0x1000]: Internal error
>> libxl: error: libxl_dom.c:679:libxl__build_dom: xc_dom_build_image
>> failed: Invalid argument
>> domainbuilder: detail: xc_dom_release: called
>> libxl: error: libxl_create.c:1217:domcreate_rebuild_done: Domain
>> 1:cannot (re-)build domain: -3
>> libxl: debug: libxl_domain.c:1140:devices_destroy_cb: Domain 1:Forked
>> pid 2477 for destroy of domain
>> libxl: debug: libxl_create.c:1646:do_domain_create: Domain 0:ao
>> 0x1ae10cb0: inprogress: poller=0x1ae10d40, flags=i
>> libxl: debug: libxl_event.c:1869:libxl__ao_complete: ao 0x1ae10cb0:
>> complete, rc=-3
>> libxl: debug: libxl_event.c:1838:libxl__ao__destroy: ao 0x1ae10cb0:
>> destroy
>> libxl: debug: libxl_domain.c:871:libxl_domain_destroy: Domain 1:ao
>> 0x1ae10cb0: create: how=(nil) callback=(nil) poller=0x1ae10d
>> 40
>>
>> Seem to failed when mmapping pages for the ramdisk. I did some digging
>> and the failure
>> occurs during the  IOCTL_PRIVCMD_MMAPBATCH_V2 call. It seems the
>> 8192's page had a err code of -22.
>
>
> -22 is -EINVAL. There are quite a few path return -EINVAL, did you try to
> narrow the failure in the kernel?
I dug a bit deeper, in privcmd_ioctl_mmap_batch, a global error was detected for
mmap_batch_fn during the mapping of the second half of  0x2f3d of pages. I am
still trying to track down why it is the 8192th element that cause the
problem. seem
like too much of coincidence its the first element of the second half.

>
>  The system have plenty of memory.
>>
>> Afterward, a null guest is created.
>> As a side note, how do I get rid of it?
>
>
> Normally the domain should be destroyed by the tools if the building failed.
>
> You should be able to destroy it using 'xl domain domid' where domid is the
> domain ID of the domain. If it does not work, then it means dom0 is holding
> reference on some page belonging to that domain.
Make sense, since I can rename it but destroy it still left it as null.
>
> Cheers,
>
> --
> Julien Grall

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

Re: [Xen-devel] [PATCH v2 04/18] xen/pvcalls: xenbus state handling

2017-05-25 Thread Boris Ostrovsky

On 05/19/2017 07:22 PM, Stefano Stabellini wrote:
> Introduce the code to handle xenbus state changes.
>
> Implement the probe function for the pvcalls backend. Write the
> supported versions, max-page-order and function-calls nodes to xenstore,
> as required by the protocol.
>
> Introduce stub functions for disconnecting/connecting to a frontend.
>
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> ---
>  drivers/xen/pvcalls-back.c | 135 
> +
>  1 file changed, 135 insertions(+)
>
> diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
> index 9044cf2..b4da138 100644
> --- a/drivers/xen/pvcalls-back.c
> +++ b/drivers/xen/pvcalls-back.c
> @@ -25,20 +25,155 @@
>  #include 
>  #include 
>  
> +#define PVCALLS_VERSIONS "1"

Shouldn't this be in a header file that will be shared with frontends?

> +#define MAX_RING_ORDER XENBUS_MAX_RING_GRANT_ORDER
> +
>  struct pvcalls_back_global {
>   struct list_head frontends;
>   struct semaphore frontends_lock;
>  } pvcalls_back_global;
>  
> +static int backend_connect(struct xenbus_device *dev)
> +{
> + return 0;
> +}
> +
> +static int backend_disconnect(struct xenbus_device *dev)
> +{
> + return 0;
> +}
> +
>  static int pvcalls_back_probe(struct xenbus_device *dev,
> const struct xenbus_device_id *id)
>  {
> + int err;
> +
> + err = xenbus_printf(XBT_NIL, dev->nodename, "versions", "%s",
> + PVCALLS_VERSIONS);
> + if (err) {
> + pr_warn("%s write out 'version' failed\n", __func__);
> + return -EINVAL;

err?

> + }
> +
> + err = xenbus_printf(XBT_NIL, dev->nodename, "max-page-order", "%u",
> + MAX_RING_ORDER);
> + if (err) {
> + pr_warn("%s write out 'max-page-order' failed\n", __func__);
> + return err;
> + }
> +
> + /* "1" means socket, connect, release, bind, listen, accept and poll*/

This comment is obsolete, or at least should refer to
XENBUS_FUNCTIONS_CALLS (and is missing a space at the end).

> + err = xenbus_printf(XBT_NIL, dev->nodename, "function-calls",
> + XENBUS_FUNCTIONS_CALLS);
> + if (err) {
> + pr_warn("%s write out 'function-calls' failed\n", __func__);
> + return err;
> + }


In case of errors we will end up with all previous entries. I think this
should be done as a transaction which would be aborted in case of an error.

> +
> + err = xenbus_switch_state(dev, XenbusStateInitWait);
> + if (err)
> + return err;


Not sure what to do on an error here (wrt xenstore entries).
xenbus_switch_state() itself uses transactions. Are we allowed to have
nested transactions?

OTOH, xenbus_switch_state() never returns an error, at least now. In
fact, in most cases we ignore return value.


-boris


> +
>   return 0;
>  }
>  
>

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

[Xen-devel] [linux-3.18 test] 109744: regressions - FAIL

2017-05-25 Thread osstest service owner

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm  4 host-ping-check-native   fail REGR. vs. 109657
 test-amd64-i386-libvirt  18 guest-start.2fail REGR. vs. 109657
 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
109657
 test-amd64-amd64-i386-pvgrub 18 guest-start/debian.repeat fail REGR. vs. 109657
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
109657

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumprun-amd64 16 rumprun-demo-xenstorels/xenstorels.repeat 
fail REGR. vs. 109657

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-start/win.repeat fail blocked in 
109657
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 109657
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 109657
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 109657
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64  9 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64  9 windows-installfail 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-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386  9 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386  9 windows-install fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64  9 windows-install fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64  9 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386  9 windows-install fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass

version targeted for testing:
 linux6b65a8f64f4fd256ac0f6b9e97e9939ae18fc6c7
baseline version:
 linux7b9d239f0d9f9bbde2c473b642d484dab4bdca79

Last test of basis   109657  2017-05-21 07:51:45 Z4 days
Testing same since   109744  2017-05-25 14:18:09 Z0 days1 attempts

Re: [Xen-devel] [PATCH v2 03/18] xen/pvcalls: initialize the module and register the xenbus backend

2017-05-25 Thread Boris Ostrovsky

On 05/19/2017 07:22 PM, Stefano Stabellini wrote:
> Keep a list of connected frontends. Use a semaphore to protect list
> accesses.
>
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com

Reviewed-by: Boris Ostrovsky 



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

Re: [Xen-devel] [PATCH v2 02/18] xen/pvcalls: introduce the pvcalls xenbus backend

2017-05-25 Thread Boris Ostrovsky

On 05/19/2017 07:22 PM, Stefano Stabellini wrote:
> Introduce a xenbus backend for the pvcalls protocol, as defined by
> https://xenbits.xen.org/docs/unstable/misc/pvcalls.html.
>
> This patch only adds the stubs, the code will be added by the following
> patches.
>
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com

Reviewed-by: Boris Ostrovsky 



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

Re: [Xen-devel] [PATCH v2 01/18] xen: introduce the pvcalls interface header

2017-05-25 Thread Boris Ostrovsky

On 05/19/2017 07:22 PM, Stefano Stabellini wrote:
> Introduce the C header file which defines the PV Calls interface. It is
> imported from xen/include/public/io/pvcalls.h.
>
> Signed-off-by: Stefano Stabellini 
> CC: konrad.w...@oracle.com
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> ---
>  include/xen/interface/io/pvcalls.h | 120 
> +
>  1 file changed, 120 insertions(+)
>  create mode 100644 include/xen/interface/io/pvcalls.h
>
> diff --git a/include/xen/interface/io/pvcalls.h 
> b/include/xen/interface/io/pvcalls.h
> new file mode 100644
> index 000..0d41959
> --- /dev/null
> +++ b/include/xen/interface/io/pvcalls.h
> @@ -0,0 +1,120 @@
> +#ifndef __XEN_PUBLIC_IO_XEN_PVCALLS_H__
> +#define __XEN_PUBLIC_IO_XEN_PVCALLS_H__
> +
> +#include 
> +#include "xen/interface/io/ring.h"
> +
> +/* "1" means socket, connect, release, bind, listen, accept and poll */
> +#define XENBUS_FUNCTIONS_CALLS "1"
> +
> +/*
> + * See docs/misc/pvcalls.markdown in xen.git for the full specification:
> + * https://xenbits.xen.org/docs/unstable/misc/pvcalls.html
> + */
> +struct pvcalls_data_intf {
> +RING_IDX in_cons, in_prod, in_error;
> +
> +uint8_t pad1[52];
> +
> +RING_IDX out_cons, out_prod, out_error;
> +
> +uint8_t pad2[52];
> +
> +RING_IDX ring_order;
> +grant_ref_t ref[];

I think you should also include .

In fact, ring.h probably needs to do it too.

-boris


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

Re: [Xen-devel] [PATCH v9 12/28] ARM: vGIC: advertise LPI support

2017-05-25 Thread Stefano Stabellini

On Thu, 25 May 2017, Julien Grall wrote:
> Hi Stefano,
> 
> On 25/05/2017 19:49, Stefano Stabellini wrote:
> > On Thu, 25 May 2017, Andre Przywara wrote:
> > > Hi,
> > > 
> > > On 23/05/17 18:47, Stefano Stabellini wrote:
> > > > On Tue, 23 May 2017, Julien Grall wrote:
> > > > > Hi Stefano,
> > > > > 
> > > > > On 22/05/17 23:19, Stefano Stabellini wrote:
> > > > > > On Tue, 16 May 2017, Julien Grall wrote:
> > > > > > > > @@ -436,8 +473,26 @@ static int
> > > > > > > > __vgic_v3_rdistr_rd_mmio_write(struct
> > > > > > > > vcpu
> > > > > > > > *v, mmio_info_t *info,
> > > > > > > >  switch ( gicr_reg )
> > > > > > > >  {
> > > > > > > >  case VREG32(GICR_CTLR):
> > > > > > > > -/* LPI's not implemented */
> > > > > > > > -goto write_ignore_32;
> > > > > > > > +{
> > > > > > > > +unsigned long flags;
> > > > > > > > +
> > > > > > > > +if ( !v->domain->arch.vgic.has_its )
> > > > > > > > +goto write_ignore_32;
> > > > > > > > +if ( dabt.size != DABT_WORD ) goto bad_width;
> > > > > > > > +
> > > > > > > > +vgic_lock(v);   /* protects
> > > > > > > > rdists_enabled */
> > > > > > > 
> > > > > > > Getting back to the locking. I don't see any place where we get
> > > > > > > the domain
> > > > > > > vgic lock before vCPU vgic lock. So this raises the question why
> > > > > > > this
> > > > > > > ordering
> > > > > > > and not moving this lock into vgic_vcpu_enable_lpis.
> > > > > > > 
> > > > > > > At least this require documentation in the code and explanation in
> > > > > > > the
> > > > > > > commit
> > > > > > > message.
> > > > > > 
> > > > > > It doesn't look like we need to take the v->arch.vgic.lock here.
> > > > > > What is
> > > > > > it protecting?
> > > > > 
> > > > > The name of the function is a bit confusion. It does not take the vCPU
> > > > > vgic
> > > > > lock but the domain vgic lock.
> > > > > 
> > > > > I believe the vcpu is passed to avoid have v->domain in most of the
> > > > > callers.
> > > > > But we should probably rename the function.
> > > > > 
> > > > > In this case it protects vgic_vcpu_enable_lpis because you can
> > > > > configure the
> > > > > number of LPIs per re-distributor but this is a domain wide value. I
> > > > > know the
> > > > > spec is confusing on this.
> > > > 
> > > > The quoting here is very unhelpful. In Andre's patch:
> > > > 
> > > > @@ -436,8 +473,26 @@ static int __vgic_v3_rdistr_rd_mmio_write(struct
> > > > vcpu *v, mmio_info_t *info,
> > > >  switch ( gicr_reg )
> > > >  {
> > > >  case VREG32(GICR_CTLR):
> > > > -/* LPI's not implemented */
> > > > -goto write_ignore_32;
> > > > +{
> > > > +unsigned long flags;
> > > > +
> > > > +if ( !v->domain->arch.vgic.has_its )
> > > > +goto write_ignore_32;
> > > > +if ( dabt.size != DABT_WORD ) goto bad_width;
> > > > +
> > > > +vgic_lock(v);   /* protects rdists_enabled */
> > > > +spin_lock_irqsave(>arch.vgic.lock, flags);
> > > > +
> > > > +/* LPIs can only be enabled once, but never disabled again. */
> > > > +if ( (r & GICR_CTLR_ENABLE_LPIS) &&
> > > > + !(v->arch.vgic.flags & VGIC_V3_LPIS_ENABLED) )
> > > > +vgic_vcpu_enable_lpis(v);
> > > > +
> > > > +spin_unlock_irqrestore(>arch.vgic.lock, flags);
> > > > +vgic_unlock(v);
> > > > +
> > > > +return 1;
> > > > +}
> > > > 
> > > > My question is: do we need to take both vgic_lock and v->arch.vgic.lock?
> > > 
> > > The domain lock (taken by vgic_lock()) protects rdists_enabled. This
> > > variable stores whether at least one redistributor has LPIs enabled. In
> > > this case the property table gets into use and since the table is shared
> > > across all redistributors, we must not change it anymore, even on
> > > another redistributor which has its LPIs still disabled.
> > > So while this looks like this is a per-redistributor (=per-VCPU)
> > > property, it is actually per domain, hence this lock.
> > > The VGIC VCPU lock is then used to naturally protect the enable bit
> > > against multiple VCPUs accessing this register simultaneously - the
> > > redists are MMIO mapped, but not banked, so this is possible.
> > > 
> > > Does that make sense?
> > 
> > If the VGIC VCPU lock is only used to protect VGIC_V3_LPIS_ENABLED,
> > couldn't we just read/write the bit atomically? It's just a bit after
> > all, it doesn't need a lock.
> 
> The vGIC vCPU lock is also here to serialize access to the re-distributor
> state when necessary.
> 
> For instance you don't want to allow write in PENDBASER after LPIs have been
> enabled.
> 
> If you don't take the lock here, you would have a small race where PENDBASER
> might be written whilst the LPIs are getting enabled.
> 
> The code in PENDBASER today does not strictly require the locking, but I think
> we should keep the lock around. Moving to the atomic will not

[Xen-devel] [linux-4.9 test] 109738: regressions - trouble: broken/fail/pass

2017-05-25 Thread osstest service owner

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2   6 xen-boot fail REGR. vs. 107358

Tests which are failing intermittently (not blocking):
 test-arm64-arm64-libvirt-qcow2  3 host-install(3)broken pass in 109717
 test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
109717 pass in 109738
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
109717
 test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail pass in 
109717

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 107358
 test-amd64-amd64-xl-rtds  9 debian-install   fail REGR. vs. 107358
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail in 109717 REGR. vs. 
107358

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-start/win.repeat fail blocked in 
107358
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-start/win.repeat fail in 109717 
never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-check fail in 109717 never 
pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-check fail in 109717 
never pass
 test-armhf-armhf-libvirt-raw  6 xen-boot fail  like 107358
 test-armhf-armhf-xl-xsm   6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt  6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail  like 107358
 test-armhf-armhf-xl-rtds  6 xen-boot fail  like 107358
 test-armhf-armhf-xl   6 xen-boot fail  like 107358
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail like 107358
 test-armhf-armhf-xl-vhd   6 xen-boot fail  like 107358
 test-amd64-amd64-xl-qemuu-ws16-amd64  9 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64  9 windows-installfail never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-examine  6 reboot   fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386  9 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386  9 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386  9 windows-install fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64  9 windows-install fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64  9 windows-install fail never pass

version targeted for testing:
 linuxf5eea276d8de10a32e68721707ae8f2fdfaa0960
baseline version:
 linux37feaf8095d352014555b82adb4a04609ca17d3f

Last test of basis   107358  2017-04-10

Re: [Xen-devel] [PATCH v9 19/28] ARM: vITS: handle MAPD command

2017-05-25 Thread Stefano Stabellini

On Thu, 25 May 2017, Julien Grall wrote:
> On 25/05/2017 19:55, Stefano Stabellini wrote:
> > On Wed, 24 May 2017, Andre Przywara wrote:
> > > Hi,
> > > 
> > > On 24/05/17 10:56, Julien Grall wrote:
> > > > Hi Andre,
> > > > 
> > > > On 05/24/2017 10:10 AM, Andre Przywara wrote:
> > > > > On 17/05/17 19:07, Julien Grall wrote:
> > > > > > >  /*
> > > > > > >   * Lookup the address of the Interrupt Translation Table
> > > > > > > associated
> > > > > > > with
> > > > > > >   * that device ID.
> > > > > > > @@ -414,6 +429,133 @@ out_unlock:
> > > > > > >  return ret;
> > > > > > >  }
> > > > > > > 
> > > > > > > +/* Must be called with the ITS lock held. */
> > > > > > > +static int its_discard_event(struct virt_its *its,
> > > > > > > + uint32_t vdevid, uint32_t vevid)
> > > > > > > +{
> > > > > > > +struct pending_irq *p;
> > > > > > > +unsigned long flags;
> > > > > > > +struct vcpu *vcpu;
> > > > > > > +uint32_t vlpi;
> > > > > > > +
> > > > > > > +ASSERT(spin_is_locked(>its_lock));
> > > > > > > +
> > > > > > > +if ( !read_itte_locked(its, vdevid, vevid, , ) )
> > > > > > > +return -ENOENT;
> > > > > > > +
> > > > > > > +if ( vlpi == INVALID_LPI )
> > > > > > > +return -ENOENT;
> > > > > > > +
> > > > > > > +/* Lock this VCPU's VGIC to make sure nobody is using the
> > > > > > > pending_irq. */
> > > > > > > +spin_lock_irqsave(>arch.vgic.lock, flags);
> > > > > > 
> > > > > > There is an interesting issue happening with this code. You don't
> > > > > > check
> > > > > > the content of the memory provided by the guest. So a malicious
> > > > > > guest
> > > > > > could craft the memory in order to setup mapping with known vlpi and
> > > > > > a
> > > > > > different vCPU.
> > > > > > 
> > > > > > This would lead to use the wrong lock here and corrupt the list.
> > > > > 
> > > > > What about this:
> > > > > Right now (mostly due to the requirements of the INVALL
> > > > > implementation)
> > > > > we store the VCPU ID in our struct pending_irq, populated upon MAPTI.
> > > > > So
> > > > > originally this was just for caching (INVALL being the only user of
> > > > > this), but I was wondering if we should move the actual instance of
> > > > > this
> > > > > information to pending_irq instead of relying on the collection ID
> > > > > from
> > > > > the ITS table. So we would never need to look up and trust the ITS
> > > > > tables for this information anymore. Later with the VGIC rework we
> > > > > will
> > > > > need this field anyway (even for SPIs).
> > > > > 
> > > > > I think this should solve this threat, where a guest can manipulate
> > > > > Xen
> > > > > by crafting the tables. Tinkering with the other information stored in
> > > > > the tables should not harm Xen, the guest would just shoot itself into
> > > > > the foot.
> > > > > 
> > > > > Does that make sense?
> > > > 
> > > > I think so. If I understand correctly, with that solution we would not
> > > > need to protect the memory provided by the guest?
> > > 
> > > Well, it gets better (though also a bit scary):
> > > Currently we use the guest's ITS tables to translate a DeviceID/EventID
> > > pair to a vLPI/vCPU pair. Now there is this new
> > > gicv3_its_get_event_pending_irq() function, which also takes an ITS and
> > > an DeviceID/EventID pair and gives us a struct pending_irq.
> > > And here we have both the vLPI number and the VCPU number in there
> > > already, so actually we don't need read_itte() anymore. And if we don't
> > > read, we don't need write. And if we don't write, we don't need to
> > > access guest memory. So this seems to ripple through and allows us to
> > > possibly dump the guest memory tables altogether.
> > 
> > Sounds like a good idea to me for DeviceID/EventID to vLPI/vCPU
> > translations.
> > 
> > 
> > > Now we still use the collection table in guest memory, but I was
> > > wondering if we could store the collection ID in the vcpu struct and use
> > > some hashing scheme to do the reverse lookup. But that might be
> > > something for some future cleanup / optimization series.
> > 
> > Leaving the security angle aside for a moment, I would prefer to keep
> > the guest memory accesses rather than adding another hashing scheme to
> > Xen for collection IDs.
> 
> The spec only require you to implement max cpus + 1 collections. I don't think
> an hashing scheme would be necessary here. It is a simple array (1 byte per
> entry in today).
> 
> > 
> > Going back to security: it looks like it should be possible to check for
> > the validity of collection IDs without too much troubles?
> > too?
> 
> If we store everthing in the pending_irq the use of the collection would
> limited to a few commands (e.g MOVI, MAPTI...). We don't much care if the
> guest modify the collection table as long as we check the vCPU is valid.

That's what I thought. In that case we might as well keep the info in
guest memory.

Re: [Xen-devel] [PATCH v9 19/28] ARM: vITS: handle MAPD command

2017-05-25 Thread Julien Grall




On 25/05/2017 19:55, Stefano Stabellini wrote:

On Wed, 24 May 2017, Andre Przywara wrote:

Hi,

On 24/05/17 10:56, Julien Grall wrote:

Hi Andre,

On 05/24/2017 10:10 AM, Andre Przywara wrote:

On 17/05/17 19:07, Julien Grall wrote:

 /*
  * Lookup the address of the Interrupt Translation Table associated
with
  * that device ID.
@@ -414,6 +429,133 @@ out_unlock:
 return ret;
 }

+/* Must be called with the ITS lock held. */
+static int its_discard_event(struct virt_its *its,
+ uint32_t vdevid, uint32_t vevid)
+{
+struct pending_irq *p;
+unsigned long flags;
+struct vcpu *vcpu;
+uint32_t vlpi;
+
+ASSERT(spin_is_locked(>its_lock));
+
+if ( !read_itte_locked(its, vdevid, vevid, , ) )
+return -ENOENT;
+
+if ( vlpi == INVALID_LPI )
+return -ENOENT;
+
+/* Lock this VCPU's VGIC to make sure nobody is using the
pending_irq. */
+spin_lock_irqsave(>arch.vgic.lock, flags);


There is an interesting issue happening with this code. You don't check
the content of the memory provided by the guest. So a malicious guest
could craft the memory in order to setup mapping with known vlpi and a
different vCPU.

This would lead to use the wrong lock here and corrupt the list.


What about this:
Right now (mostly due to the requirements of the INVALL implementation)
we store the VCPU ID in our struct pending_irq, populated upon MAPTI. So
originally this was just for caching (INVALL being the only user of
this), but I was wondering if we should move the actual instance of this
information to pending_irq instead of relying on the collection ID from
the ITS table. So we would never need to look up and trust the ITS
tables for this information anymore. Later with the VGIC rework we will
need this field anyway (even for SPIs).

I think this should solve this threat, where a guest can manipulate Xen
by crafting the tables. Tinkering with the other information stored in
the tables should not harm Xen, the guest would just shoot itself into
the foot.

Does that make sense?


I think so. If I understand correctly, with that solution we would not
need to protect the memory provided by the guest?


Well, it gets better (though also a bit scary):
Currently we use the guest's ITS tables to translate a DeviceID/EventID
pair to a vLPI/vCPU pair. Now there is this new
gicv3_its_get_event_pending_irq() function, which also takes an ITS and
an DeviceID/EventID pair and gives us a struct pending_irq.
And here we have both the vLPI number and the VCPU number in there
already, so actually we don't need read_itte() anymore. And if we don't
read, we don't need write. And if we don't write, we don't need to
access guest memory. So this seems to ripple through and allows us to
possibly dump the guest memory tables altogether.


Sounds like a good idea to me for DeviceID/EventID to vLPI/vCPU
translations.



Now we still use the collection table in guest memory, but I was
wondering if we could store the collection ID in the vcpu struct and use
some hashing scheme to do the reverse lookup. But that might be
something for some future cleanup / optimization series.


Leaving the security angle aside for a moment, I would prefer to keep
the guest memory accesses rather than adding another hashing scheme to
Xen for collection IDs.


The spec only require you to implement max cpus + 1 collections. I don't 
think an hashing scheme would be necessary here. It is a simple array (1 
byte per entry in today).




Going back to security: it looks like it should be possible to check for
the validity of collection IDs without too much troubles?
too?


If we store everthing in the pending_irq the use of the collection would 
limited to a few commands (e.g MOVI, MAPTI...). We don't much care if 
the guest modify the collection table as long as we check the vCPU is valid.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v9 12/28] ARM: vGIC: advertise LPI support

2017-05-25 Thread Julien Grall


Hi Stefano,

On 25/05/2017 19:49, Stefano Stabellini wrote:

On Thu, 25 May 2017, Andre Przywara wrote:

Hi,

On 23/05/17 18:47, Stefano Stabellini wrote:

On Tue, 23 May 2017, Julien Grall wrote:

Hi Stefano,

On 22/05/17 23:19, Stefano Stabellini wrote:

On Tue, 16 May 2017, Julien Grall wrote:

@@ -436,8 +473,26 @@ static int __vgic_v3_rdistr_rd_mmio_write(struct
vcpu
*v, mmio_info_t *info,
 switch ( gicr_reg )
 {
 case VREG32(GICR_CTLR):
-/* LPI's not implemented */
-goto write_ignore_32;
+{
+unsigned long flags;
+
+if ( !v->domain->arch.vgic.has_its )
+goto write_ignore_32;
+if ( dabt.size != DABT_WORD ) goto bad_width;
+
+vgic_lock(v);   /* protects rdists_enabled */


Getting back to the locking. I don't see any place where we get the domain
vgic lock before vCPU vgic lock. So this raises the question why this
ordering
and not moving this lock into vgic_vcpu_enable_lpis.

At least this require documentation in the code and explanation in the
commit
message.


It doesn't look like we need to take the v->arch.vgic.lock here. What is
it protecting?


The name of the function is a bit confusion. It does not take the vCPU vgic
lock but the domain vgic lock.

I believe the vcpu is passed to avoid have v->domain in most of the callers.
But we should probably rename the function.

In this case it protects vgic_vcpu_enable_lpis because you can configure the
number of LPIs per re-distributor but this is a domain wide value. I know the
spec is confusing on this.


The quoting here is very unhelpful. In Andre's patch:

@@ -436,8 +473,26 @@ static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, 
mmio_info_t *info,
 switch ( gicr_reg )
 {
 case VREG32(GICR_CTLR):
-/* LPI's not implemented */
-goto write_ignore_32;
+{
+unsigned long flags;
+
+if ( !v->domain->arch.vgic.has_its )
+goto write_ignore_32;
+if ( dabt.size != DABT_WORD ) goto bad_width;
+
+vgic_lock(v);   /* protects rdists_enabled */
+spin_lock_irqsave(>arch.vgic.lock, flags);
+
+/* LPIs can only be enabled once, but never disabled again. */
+if ( (r & GICR_CTLR_ENABLE_LPIS) &&
+ !(v->arch.vgic.flags & VGIC_V3_LPIS_ENABLED) )
+vgic_vcpu_enable_lpis(v);
+
+spin_unlock_irqrestore(>arch.vgic.lock, flags);
+vgic_unlock(v);
+
+return 1;
+}

My question is: do we need to take both vgic_lock and v->arch.vgic.lock?


The domain lock (taken by vgic_lock()) protects rdists_enabled. This
variable stores whether at least one redistributor has LPIs enabled. In
this case the property table gets into use and since the table is shared
across all redistributors, we must not change it anymore, even on
another redistributor which has its LPIs still disabled.
So while this looks like this is a per-redistributor (=per-VCPU)
property, it is actually per domain, hence this lock.
The VGIC VCPU lock is then used to naturally protect the enable bit
against multiple VCPUs accessing this register simultaneously - the
redists are MMIO mapped, but not banked, so this is possible.

Does that make sense?


If the VGIC VCPU lock is only used to protect VGIC_V3_LPIS_ENABLED,
couldn't we just read/write the bit atomically? It's just a bit after
all, it doesn't need a lock.


The vGIC vCPU lock is also here to serialize access to the 
re-distributor state when necessary.


For instance you don't want to allow write in PENDBASER after LPIs have 
been enabled.


If you don't take the lock here, you would have a small race where 
PENDBASER might be written whilst the LPIs are getting enabled.


The code in PENDBASER today does not strictly require the locking, but I 
think we should keep the lock around. Moving to the atomic will not 
really benefit here as write to those registers will be very unlikely so 
we don't need very good performance.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] xl create failure on arm64 with XEN 4.9rc6

2017-05-25 Thread Julien Grall


(CC toolstack maintainers)

On 25/05/2017 19:58, Feng Kan wrote:

Hi All:


Hello,


This is not specifically against the XEN 4.9. I am using 4.12rc2
kernel on arm64 platform. Started dom0 fine with ACPI enabled, but
failed when creating the domU guest. Xen is built natively on the
arm64 platform. Using the same kernel and ramdisk as dom0. Any idea as
why it is stuck here
would be greatly appreciated?


The first step would to try a stable release if you can. Also, it would 
be useful if you provide information about the guest (i.e the 
configuration) and your .config for the kernel.


I gave a try on Linux 4.12rc2 and I was not able to reproduce your error.



xc: error: panic: xc_dom_boot.c:178: xc_dom_boot_domU_map: failed to
mmap domU pages 0x450c2+0x2f3d [mmap, errno=22 (Invalid ar
gument), chunksize 0x1000]: Internal error
libxl: error: libxl_dom.c:679:libxl__build_dom: xc_dom_build_image
failed: Invalid argument
domainbuilder: detail: xc_dom_release: called
libxl: error: libxl_create.c:1217:domcreate_rebuild_done: Domain
1:cannot (re-)build domain: -3
libxl: debug: libxl_domain.c:1140:devices_destroy_cb: Domain 1:Forked
pid 2477 for destroy of domain
libxl: debug: libxl_create.c:1646:do_domain_create: Domain 0:ao
0x1ae10cb0: inprogress: poller=0x1ae10d40, flags=i
libxl: debug: libxl_event.c:1869:libxl__ao_complete: ao 0x1ae10cb0:
complete, rc=-3
libxl: debug: libxl_event.c:1838:libxl__ao__destroy: ao 0x1ae10cb0: destroy
libxl: debug: libxl_domain.c:871:libxl_domain_destroy: Domain 1:ao
0x1ae10cb0: create: how=(nil) callback=(nil) poller=0x1ae10d
40

Seem to failed when mmapping pages for the ramdisk. I did some digging
and the failure
occurs during the  IOCTL_PRIVCMD_MMAPBATCH_V2 call. It seems the
8192's page had a err code of -22.


-22 is -EINVAL. There are quite a few path return -EINVAL, did you try 
to narrow the failure in the kernel?


 The system have plenty of memory.

Afterward, a null guest is created.
As a side note, how do I get rid of it?


Normally the domain should be destroyed by the tools if the building failed.

You should be able to destroy it using 'xl domain domid' where domid is 
the domain ID of the domain. If it does not work, then it means dom0 is 
holding reference on some page belonging to that domain.


Cheers,

--
Julien Grall

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

[Xen-devel] xl create failure on arm64 with XEN 4.9rc6

2017-05-25 Thread Feng Kan

Hi All:

This is not specifically against the XEN 4.9. I am using 4.12rc2
kernel on arm64 platform. Started dom0 fine with ACPI enabled, but
failed when creating the domU guest. Xen is built natively on the
arm64 platform. Using the same kernel and ramdisk as dom0. Any idea as
why it is stuck here
would be greatly appreciated?

xc: error: panic: xc_dom_boot.c:178: xc_dom_boot_domU_map: failed to
mmap domU pages 0x450c2+0x2f3d [mmap, errno=22 (Invalid ar
gument), chunksize 0x1000]: Internal error
libxl: error: libxl_dom.c:679:libxl__build_dom: xc_dom_build_image
failed: Invalid argument
domainbuilder: detail: xc_dom_release: called
libxl: error: libxl_create.c:1217:domcreate_rebuild_done: Domain
1:cannot (re-)build domain: -3
libxl: debug: libxl_domain.c:1140:devices_destroy_cb: Domain 1:Forked
pid 2477 for destroy of domain
libxl: debug: libxl_create.c:1646:do_domain_create: Domain 0:ao
0x1ae10cb0: inprogress: poller=0x1ae10d40, flags=i
libxl: debug: libxl_event.c:1869:libxl__ao_complete: ao 0x1ae10cb0:
complete, rc=-3
libxl: debug: libxl_event.c:1838:libxl__ao__destroy: ao 0x1ae10cb0: destroy
libxl: debug: libxl_domain.c:871:libxl_domain_destroy: Domain 1:ao
0x1ae10cb0: create: how=(nil) callback=(nil) poller=0x1ae10d
40

Seem to failed when mmapping pages for the ramdisk. I did some digging
and the failure
occurs during the  IOCTL_PRIVCMD_MMAPBATCH_V2 call. It seems the
8192's page had a err code of -22. The system have plenty of memory.
Afterward, a null guest is created.
As a side note, how do I get rid of it?


[root@localhost xen-guest]# xl list
NameID   Mem VCPUs  State   Time(s)
Domain-0 0 6553632 r-  16.3
(null)   1 0 0 --p--d   0.0

[root@localhost xen-guest]# xl info
host   : localhost.localdomain
release: 4.12.0-rc2
version: #1 SMP Thu May 25 13:17:35 EDT 2017
machine: aarch64
nr_cpus: 32
max_cpu_id : 31
nr_nodes   : 1
cores_per_socket   : 1
threads_per_core   : 1
cpu_mhz: 50
hw_caps:
:::::::
virt_caps  :
total_memory   : 130700
free_memory: 61637
sharing_freed_memory   : 0
sharing_used_memory: 0
outstanding_claims : 0
free_cpus  : 0
xen_major  : 4
xen_minor  : 9
xen_extra  : -rc
xen_version: 4.9-rc
xen_caps   : xen-3.0-aarch64 xen-3.0-armv7l
xen_scheduler  : credit
xen_pagesize   : 4096
platform_params: virt_start=0x20
xen_changeset  : Tue May 23 19:21:04 2017 -0400 git:4108ded-dirty
xen_commandline: xen.efi dom0_mem=64G loglvl=all
guest_loglvl=all conswitch=x acpi=force
cc_compiler: gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
cc_compile_by  : root
cc_compile_domain  :
cc_compile_date: Thu May 25 14:38:25 EDT 2017
build_id   : 22732b38d4e0ea99d541519eb49a7d50115717da
xend_config_format : 4

Thanks in advance.

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

Re: [Xen-devel] [PATCH v9 19/28] ARM: vITS: handle MAPD command

2017-05-25 Thread Stefano Stabellini

On Wed, 24 May 2017, Andre Przywara wrote:
> Hi,
> 
> On 24/05/17 10:56, Julien Grall wrote:
> > Hi Andre,
> > 
> > On 05/24/2017 10:10 AM, Andre Przywara wrote:
> >> On 17/05/17 19:07, Julien Grall wrote:
>   /*
>    * Lookup the address of the Interrupt Translation Table associated
>  with
>    * that device ID.
>  @@ -414,6 +429,133 @@ out_unlock:
>   return ret;
>   }
> 
>  +/* Must be called with the ITS lock held. */
>  +static int its_discard_event(struct virt_its *its,
>  + uint32_t vdevid, uint32_t vevid)
>  +{
>  +struct pending_irq *p;
>  +unsigned long flags;
>  +struct vcpu *vcpu;
>  +uint32_t vlpi;
>  +
>  +ASSERT(spin_is_locked(>its_lock));
>  +
>  +if ( !read_itte_locked(its, vdevid, vevid, , ) )
>  +return -ENOENT;
>  +
>  +if ( vlpi == INVALID_LPI )
>  +return -ENOENT;
>  +
>  +/* Lock this VCPU's VGIC to make sure nobody is using the
>  pending_irq. */
>  +spin_lock_irqsave(>arch.vgic.lock, flags);
> >>>
> >>> There is an interesting issue happening with this code. You don't check
> >>> the content of the memory provided by the guest. So a malicious guest
> >>> could craft the memory in order to setup mapping with known vlpi and a
> >>> different vCPU.
> >>>
> >>> This would lead to use the wrong lock here and corrupt the list.
> >>
> >> What about this:
> >> Right now (mostly due to the requirements of the INVALL implementation)
> >> we store the VCPU ID in our struct pending_irq, populated upon MAPTI. So
> >> originally this was just for caching (INVALL being the only user of
> >> this), but I was wondering if we should move the actual instance of this
> >> information to pending_irq instead of relying on the collection ID from
> >> the ITS table. So we would never need to look up and trust the ITS
> >> tables for this information anymore. Later with the VGIC rework we will
> >> need this field anyway (even for SPIs).
> >>
> >> I think this should solve this threat, where a guest can manipulate Xen
> >> by crafting the tables. Tinkering with the other information stored in
> >> the tables should not harm Xen, the guest would just shoot itself into
> >> the foot.
> >>
> >> Does that make sense?
> > 
> > I think so. If I understand correctly, with that solution we would not
> > need to protect the memory provided by the guest?
> 
> Well, it gets better (though also a bit scary):
> Currently we use the guest's ITS tables to translate a DeviceID/EventID
> pair to a vLPI/vCPU pair. Now there is this new
> gicv3_its_get_event_pending_irq() function, which also takes an ITS and
> an DeviceID/EventID pair and gives us a struct pending_irq.
> And here we have both the vLPI number and the VCPU number in there
> already, so actually we don't need read_itte() anymore. And if we don't
> read, we don't need write. And if we don't write, we don't need to
> access guest memory. So this seems to ripple through and allows us to
> possibly dump the guest memory tables altogether.

Sounds like a good idea to me for DeviceID/EventID to vLPI/vCPU
translations.


> Now we still use the collection table in guest memory, but I was
> wondering if we could store the collection ID in the vcpu struct and use
> some hashing scheme to do the reverse lookup. But that might be
> something for some future cleanup / optimization series.

Leaving the security angle aside for a moment, I would prefer to keep
the guest memory accesses rather than adding another hashing scheme to
Xen for collection IDs.

Going back to security: it looks like it should be possible to check for
the validity of collection IDs without too much troubles?
too?

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

Re: [Xen-devel] [PATCH v9 12/28] ARM: vGIC: advertise LPI support

2017-05-25 Thread Stefano Stabellini

On Thu, 25 May 2017, Andre Przywara wrote:
> Hi,
> 
> On 23/05/17 18:47, Stefano Stabellini wrote:
> > On Tue, 23 May 2017, Julien Grall wrote:
> >> Hi Stefano,
> >>
> >> On 22/05/17 23:19, Stefano Stabellini wrote:
> >>> On Tue, 16 May 2017, Julien Grall wrote:
> > @@ -436,8 +473,26 @@ static int __vgic_v3_rdistr_rd_mmio_write(struct
> > vcpu
> > *v, mmio_info_t *info,
> >  switch ( gicr_reg )
> >  {
> >  case VREG32(GICR_CTLR):
> > -/* LPI's not implemented */
> > -goto write_ignore_32;
> > +{
> > +unsigned long flags;
> > +
> > +if ( !v->domain->arch.vgic.has_its )
> > +goto write_ignore_32;
> > +if ( dabt.size != DABT_WORD ) goto bad_width;
> > +
> > +vgic_lock(v);   /* protects rdists_enabled */
> 
>  Getting back to the locking. I don't see any place where we get the 
>  domain
>  vgic lock before vCPU vgic lock. So this raises the question why this
>  ordering
>  and not moving this lock into vgic_vcpu_enable_lpis.
> 
>  At least this require documentation in the code and explanation in the
>  commit
>  message.
> >>>
> >>> It doesn't look like we need to take the v->arch.vgic.lock here. What is
> >>> it protecting?
> >>
> >> The name of the function is a bit confusion. It does not take the vCPU vgic
> >> lock but the domain vgic lock.
> >>
> >> I believe the vcpu is passed to avoid have v->domain in most of the 
> >> callers.
> >> But we should probably rename the function.
> >>
> >> In this case it protects vgic_vcpu_enable_lpis because you can configure 
> >> the
> >> number of LPIs per re-distributor but this is a domain wide value. I know 
> >> the
> >> spec is confusing on this.
> > 
> > The quoting here is very unhelpful. In Andre's patch:
> > 
> > @@ -436,8 +473,26 @@ static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu 
> > *v, mmio_info_t *info,
> >  switch ( gicr_reg )
> >  {
> >  case VREG32(GICR_CTLR):
> > -/* LPI's not implemented */
> > -goto write_ignore_32;
> > +{
> > +unsigned long flags;
> > +
> > +if ( !v->domain->arch.vgic.has_its )
> > +goto write_ignore_32;
> > +if ( dabt.size != DABT_WORD ) goto bad_width;
> > +
> > +vgic_lock(v);   /* protects rdists_enabled */
> > +spin_lock_irqsave(>arch.vgic.lock, flags);
> > +
> > +/* LPIs can only be enabled once, but never disabled again. */
> > +if ( (r & GICR_CTLR_ENABLE_LPIS) &&
> > + !(v->arch.vgic.flags & VGIC_V3_LPIS_ENABLED) )
> > +vgic_vcpu_enable_lpis(v);
> > +
> > +spin_unlock_irqrestore(>arch.vgic.lock, flags);
> > +vgic_unlock(v);
> > +
> > +return 1;
> > +}
> > 
> > My question is: do we need to take both vgic_lock and v->arch.vgic.lock?
> 
> The domain lock (taken by vgic_lock()) protects rdists_enabled. This
> variable stores whether at least one redistributor has LPIs enabled. In
> this case the property table gets into use and since the table is shared
> across all redistributors, we must not change it anymore, even on
> another redistributor which has its LPIs still disabled.
> So while this looks like this is a per-redistributor (=per-VCPU)
> property, it is actually per domain, hence this lock.
> The VGIC VCPU lock is then used to naturally protect the enable bit
> against multiple VCPUs accessing this register simultaneously - the
> redists are MMIO mapped, but not banked, so this is possible.
> 
> Does that make sense?

If the VGIC VCPU lock is only used to protect VGIC_V3_LPIS_ENABLED,
couldn't we just read/write the bit atomically? It's just a bit after
all, it doesn't need a lock.

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

Re: [Xen-devel] [TESTDAY] Test report

2017-05-25 Thread Stefano Stabellini

On Thu, 25 May 2017, Julien Grall wrote:
> Hi Andrii,
> 
> On 23/05/17 18:03, Andrii Anisov wrote:
> > * Hardware:
> > Salvator-X board with Renesas R-Car H3 SoC (ARM64)
> > 
> > * Software:
> > XEN 4.9-rc6
> > System based on Renesas Yocto 2.19.0 BSP [1]
> > Linux kernel 4.9
> > 
> > * Guest operating systems:
> > The same system as dom0.
> > 
> > * Functionality tested:
> > xl create/restart/shutdown
> > Guest domain reboot from its console
> > PV NET (nfsroot in domU) , PV Block (copy from xvda to nfsroot in DomU)
> > 
> > * Comments:
> > 
> > On DomU startup messages like following appeared:
> > 
> > root@salvator-x-domx:~# (XEN) printk: 9 messages suppressed.
> > (XEN) d1v0: vGICD: unhandled word write 0x to ICACTIVER0
> > (XEN) d1v1: vGICD: unhandled word write 0x to ICACTIVER0
> > (XEN) d1v2: vGICD: unhandled word write 0x to ICACTIVER0
> > (XEN) d1v3: vGICD: unhandled word write 0x to ICACTIVER0
> 
> The vGIC emulation does not emulate I*ACTIVER* registers so far. But Linux
> only accesses them at boot to ensure the firmware didn't leave interrupt in
> active state. They are harmless for now.
> 
> > [   65.333062] xen-blkback: backend/vbd/1/51713: using 4 queues,
> > protocol 1 (arm-abi) persistent grants
> > [   65.357846] xen-blkback: backend/vbd/1/51714: using 4 queues,
> > protocol 1 (arm-abi) persistent grants
> > [   65.514054] vif vif-1-0 vif1.0: Guest Rx ready
> > [   65.518485] IPv6: ADDRCONF(NETDEV_CHANGE): vif1.0: link becomes
> > ready
> > [   65.525021] xenbr0: port 2(vif1.0) entered blocking state
> > [   65.530359] xenbr0: port 2(vif1.0) entered forwarding state
> > [   65.815976] xen_add_phys_to_mach_entry: cannot add
> > pfn=0x00063772 -> mfn=0x0072abb0: pfn=0x00063772
> > -> mfn=0x00727aad already exists
> > [   65.834442] xen_add_phys_to_mach_entry: cannot add
> > pfn=0x0006374e -> mfn=0x0072abb0: pfn=0x0006374e
> > -> mfn=0x00727aad already exists
> > [   66.025979] xen_add_phys_to_mach_entry: cannot add
> > pfn=0x0006379c -> mfn=0x0072abb3: pfn=0x0006379c
> > -> mfn=0x0072abb1 already exists
> > [   66.273534] xen_add_phys_to_mach_entry: cannot add
> > pfn=0x00063731 -> mfn=0x00727c3d: pfn=0x00063731
> > -> mfn=0x00727c3e already exists
> > [   66.328245] xen_add_phys_to_mach_entry: cannot add
> > pfn=0x000637ee -> mfn=0x00727c3f: pfn=0x000637ee
> > -> mfn=0x00727c3d already exists
> 
> I was expecting Stefano to answer here as he knows better than me this part of
> the code.
> 
> Linux is storing the conversion between pfn (guest frame number) to the mfn
> (machine frame number) in an RB-tree. This will be used by the swiotlb code to
> know if a buffer is contiguous in the physical RAM.
> 
> In your case, the log says that there was already a mapping pfn <-> mfn in the
> tree. It looks to me the previous mapping has not been removed correctly.
> 
> Are you able to reproduce this reliably? If so, can you try to figure out who
> added the first mapping pfn <-> mfn?

Sorry, I skimmed over the email and missed those warnings.

Julien, you are correct. The mappings are added by
set_foreign_p2m_mapping, which is called on gnttab_map_refs, and should
be removed by clear_foreign_p2m_mapping, called by gnttab_unmap_refs.

Maybe the mapping function is called twice or the unmapping function is
not called when it should?

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

Re: [Xen-devel] [PATCH 08/12 v3] xen/arm: vpl011: Modify xenconsole to support multiple consoles

2017-05-25 Thread Stefano Stabellini

On Thu, 25 May 2017, Bhupinder Thakur wrote:
> Hi,
> 
> On 17 May 2017 at 05:11, Stefano Stabellini  wrote:
> > On Wed, 10 May 2017, Bhupinder Thakur wrote:
> >> Xenconsole supports only PV console currently. This patch adds support
> >> for supporting multiple consoles.
> >>
> >> This patch modifies different data structures and APIs used
> >> in xenconsole to support multiple consoles.
> >>
> >> Change summary:
> >>
> >> 1. Split the domain structure into a console structure and the
> >>domain structure, where each console structure represents one
> >>console.
> >>
> >> 2. Modify different APIs such as buffer_append() etc. to take
> >>console structure as input and perform per console specific
> >>operations.
> >>
> >> 3. Define a generic console_create_ring(), which sets up the
> >>ring buffer and event channel for each console.
> >>
> >> 3. Modify domain_create_ring() to use console_create_ring().
> >>
> >> 4. Modifications in handle_ring_read() to read ring buffer data
> >>from multiple consoles.
> >>
> >> 5. Add log file support for multiple consoles.
> >>
> >> Signed-off-by: Bhupinder Thakur 
> >
> > There is something wrong with this patch: I cannot apply it.
> >
> > Also, it is still way to big for me to review. I cannot track all the
> > changes and figure out if they are correct.
> >
> > One option is to introduce struct console in one patch, with only one
> > struct console per domain. Then the second patch could introduce
> > multiple struct console with the helpers such as console_iter_void_arg1.
> >
> > Finally the third patch could add vuart support.
> >
> I have divided the changes into 4 patches:
> 
> patch#1: This patch introduces the console structure and modifies the
> code to use the new console structure.
> 
> patch#2: This patch modifies the functions to take console structure
> as input instead of domain structure. Also it renames the console
> specific functions to start with "console_" prefix instead of
> "domain_" prefix. For example - domain_create_tty() is renamed to
> console_create_tty().
> 
> patch#3: This patch adds the support for multiple consoles and
> introduces the iterator functions to operate on multiple consoles.
> 
> patch#4: Finally this patch adds support for a new vuart console.

Thank you, it looks better on paper


> >> -static int create_domain_log(struct domain *dom)
> >> +static int create_console_log(struct console *con)
> >>  {
> >>   char logfile[PATH_MAX];
> >>   char *namepath, *data, *s;
> >>   int fd;
> >>   unsigned int len;
> >> + struct domain *dom = con->d;
> >>
> >>   namepath = xs_get_domain_path(xs, dom->domid);
> >>   s = realloc(namepath, strlen(namepath) + 6);
> >> @@ -314,7 +443,9 @@ static int create_domain_log(struct domain *dom)
> >>   return -1;
> >>   }
> >>
> >> - snprintf(logfile, PATH_MAX-1, "%s/guest-%s.log", log_dir, data);
> >> + snprintf(logfile, PATH_MAX-1, "%s%s/guest-%s.log",
> >> +  log_dir, con->xspath, data);
> >
> > This changes the log directory, right? Are the new directories created
> > correctly by the install scripts?
> I will correct this. There should be no change in the path for PV
> console log. I think by default guest logging is disabled. How can I
> enable the logging to test it? I believe some option needs to be
> passed while spawning xenconsoled?

Yes, it looks like it's the -l option, see:

case 'l':
if (!strcmp(optarg, "all")) {
  log_hv = 1;
  log_guest = 1;
} else if (!strcmp(optarg, "hv")) {
  log_hv = 1;
} else if (!strcmp(optarg, "guest")) {
  log_guest = 1;
}

in main.c

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

Re: [Xen-devel] [PATCH v9 12/28] ARM: vGIC: advertise LPI support

2017-05-25 Thread Andre Przywara

Hi,

On 23/05/17 18:47, Stefano Stabellini wrote:
> On Tue, 23 May 2017, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 22/05/17 23:19, Stefano Stabellini wrote:
>>> On Tue, 16 May 2017, Julien Grall wrote:
> @@ -436,8 +473,26 @@ static int __vgic_v3_rdistr_rd_mmio_write(struct
> vcpu
> *v, mmio_info_t *info,
>  switch ( gicr_reg )
>  {
>  case VREG32(GICR_CTLR):
> -/* LPI's not implemented */
> -goto write_ignore_32;
> +{
> +unsigned long flags;
> +
> +if ( !v->domain->arch.vgic.has_its )
> +goto write_ignore_32;
> +if ( dabt.size != DABT_WORD ) goto bad_width;
> +
> +vgic_lock(v);   /* protects rdists_enabled */

 Getting back to the locking. I don't see any place where we get the domain
 vgic lock before vCPU vgic lock. So this raises the question why this
 ordering
 and not moving this lock into vgic_vcpu_enable_lpis.

 At least this require documentation in the code and explanation in the
 commit
 message.
>>>
>>> It doesn't look like we need to take the v->arch.vgic.lock here. What is
>>> it protecting?
>>
>> The name of the function is a bit confusion. It does not take the vCPU vgic
>> lock but the domain vgic lock.
>>
>> I believe the vcpu is passed to avoid have v->domain in most of the callers.
>> But we should probably rename the function.
>>
>> In this case it protects vgic_vcpu_enable_lpis because you can configure the
>> number of LPIs per re-distributor but this is a domain wide value. I know the
>> spec is confusing on this.
> 
> The quoting here is very unhelpful. In Andre's patch:
> 
> @@ -436,8 +473,26 @@ static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu 
> *v, mmio_info_t *info,
>  switch ( gicr_reg )
>  {
>  case VREG32(GICR_CTLR):
> -/* LPI's not implemented */
> -goto write_ignore_32;
> +{
> +unsigned long flags;
> +
> +if ( !v->domain->arch.vgic.has_its )
> +goto write_ignore_32;
> +if ( dabt.size != DABT_WORD ) goto bad_width;
> +
> +vgic_lock(v);   /* protects rdists_enabled */
> +spin_lock_irqsave(>arch.vgic.lock, flags);
> +
> +/* LPIs can only be enabled once, but never disabled again. */
> +if ( (r & GICR_CTLR_ENABLE_LPIS) &&
> + !(v->arch.vgic.flags & VGIC_V3_LPIS_ENABLED) )
> +vgic_vcpu_enable_lpis(v);
> +
> +spin_unlock_irqrestore(>arch.vgic.lock, flags);
> +vgic_unlock(v);
> +
> +return 1;
> +}
> 
> My question is: do we need to take both vgic_lock and v->arch.vgic.lock?

The domain lock (taken by vgic_lock()) protects rdists_enabled. This
variable stores whether at least one redistributor has LPIs enabled. In
this case the property table gets into use and since the table is shared
across all redistributors, we must not change it anymore, even on
another redistributor which has its LPIs still disabled.
So while this looks like this is a per-redistributor (=per-VCPU)
property, it is actually per domain, hence this lock.
The VGIC VCPU lock is then used to naturally protect the enable bit
against multiple VCPUs accessing this register simultaneously - the
redists are MMIO mapped, but not banked, so this is possible.

Does that make sense?

Cheers,
Andre

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

Re: [Xen-devel] Commit moratorium for branching Xen 4.9

2017-05-25 Thread Boris Ostrovsky

On 05/25/2017 01:46 PM, Julien Grall wrote:
> Hi Boris,
>
> On 25/05/17 18:08, Boris Ostrovsky wrote:
>> On 05/25/2017 11:54 AM, Julien Grall wrote:
>>> Hi,
>>>
>>> The patches fixing the 2 outstanding regressions have been merged.
>>
>> Is this:
>>
>> https://lists.xenproject.org/archives/html/xen-devel/2017-05/msg02340.html
>>
>>
>> being deferred to the next RC (if we are having one)?
>
> I missed that issue sorry. So far, this patch lacks of
> Acked-by/Reviewed-by but as a Tested-by.
>
> I am aware the patch that introduced the regression (efa9596e9d
> "x86/mm: fix incorrect unmapping of 2MB and 1GB pages") was attempting
> to prevent breaking down an EPT structure irreversibly when removing
> 2MB and 1GB pages. AFAIU, this commit will improve performance, but a
> boot regression was introduced on AMD platforms.


The regression only affects AMD guests that have maxmem > memory.

Since we have a fix in flight my suggestion would be to release-note
this issue but not revert the offending patch.

-boris

>
> As the first regression was not introduced by Xen 4.9 and we lack
> review bandwidth, I would suggest to revert the commit efa9596e9d
> until we get the patch [1] reviewed.
>
> If we managed to review it before the release, then we can consider to
> include both of them. But, at the moment, I would not consider the
> regression fixed by the commit efa9596e9d as a blocker for the release.
>
> Cheers,
>
> [1]
> https://lists.xenproject.org/archives/html/xen-devel/2017-05/msg02340.html
>


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

[Xen-devel] [xen-unstable-smoke test] 109745: tolerable trouble: broken/pass - PUSHED

2017-05-25 Thread osstest service owner

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  876800d5f9de8b15355172794cb82f505dd26e18
baseline version:
 xen  d9eb706356ad4dbd04aad563ec4d2bcd3d7d6c03

Last test of basis   109740  2017-05-25 09:17:45 Z0 days
Testing same since   109745  2017-05-25 16:02:31 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Jackson 
  M A Young 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] Commit moratorium for branching Xen 4.9

2017-05-25 Thread Julien Grall


Hi Boris,

On 25/05/17 18:08, Boris Ostrovsky wrote:

On 05/25/2017 11:54 AM, Julien Grall wrote:

Hi,

The patches fixing the 2 outstanding regressions have been merged.


Is this:

https://lists.xenproject.org/archives/html/xen-devel/2017-05/msg02340.html

being deferred to the next RC (if we are having one)?


I missed that issue sorry. So far, this patch lacks of 
Acked-by/Reviewed-by but as a Tested-by.


I am aware the patch that introduced the regression (efa9596e9d "x86/mm: 
fix incorrect unmapping of 2MB and 1GB pages") was attempting to prevent 
breaking down an EPT structure irreversibly when removing 2MB and 1GB 
pages. AFAIU, this commit will improve performance, but a boot 
regression was introduced on AMD platforms.


As the first regression was not introduced by Xen 4.9 and we lack review 
bandwidth, I would suggest to revert the commit efa9596e9d until we get 
the patch [1] reviewed.


If we managed to review it before the release, then we can consider to 
include both of them. But, at the moment, I would not consider the 
regression fixed by the commit efa9596e9d as a blocker for the release.


Cheers,

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2017-05/msg02340.html


--
Julien Grall

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

[Xen-devel] [libvirt test] 109736: tolerable all pass - PUSHED

2017-05-25 Thread osstest service owner

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 109709
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 109709
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 109709
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-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-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  a495e3f9eabcfcea3d80c5c04effa371e751541c
baseline version:
 libvirt  6de895f64c412b530b2d81eb19f3a4053a7c76fb

Last test of basis   109709  2017-05-24 04:20:57 Z1 days
Testing same since   109736  2017-05-25 04:20:08 Z0 days1 attempts


People who touched revisions under test:
  Chen Hanxiao 
  John Ferlan 
  Konstantin Neumoin 
  Michal Privoznik 
  Pavel Hrdina 
  Peter Krempa 
  Yi Wang 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-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-arm64-arm64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



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

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

Explanation of these reports, and of osstest in general, is at

Re: [Xen-devel] Commit moratorium for branching Xen 4.9

2017-05-25 Thread Boris Ostrovsky

On 05/25/2017 11:54 AM, Julien Grall wrote:
> Hi,
>
> The patches fixing the 2 outstanding regressions have been merged.

Is this:

https://lists.xenproject.org/archives/html/xen-devel/2017-05/msg02340.html

being deferred to the next RC (if we are having one)?

-boris

>
> I would like to make another attempt to branch with the RC (4.9 RC7).
> I don't want to branch when master != staging, so please avoid
> committing new patches to staging now to let master catch up with
> staging. Another announcement will be made when the moratorium is lifted.
>
> Cheers,
>


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

Re: [Xen-devel] [PATCH v9 05/28] ARM: GICv3: forward pending LPIs to guests

2017-05-25 Thread Andre Przywara

Hi,

On 22/05/17 23:03, Stefano Stabellini wrote:
> On Thu, 11 May 2017, Andre Przywara wrote:
>> Upon receiving an LPI on the host, we need to find the right VCPU and
>> virtual IRQ number to get this IRQ injected.
>> Iterate our two-level LPI table to find this information quickly when
>> the host takes an LPI. Call the existing injection function to let the
>> GIC emulation deal with this interrupt.
>> Also we enhance struct pending_irq to cache the pending bit and the
>> priority information for LPIs.
> 
> I can see that you added "uint8_t lpi_priority" to pending_irq. Where
> are we caching the pending bit?

Ah, that statement is a leftover from v5, where I introduced
GIC_IRQ_GUEST_LPI_PENDING. However we don't need an explicit pending
state at the moment (the VGIC rework will probably change this), so we
get away without that bit. Will drop those words.

> Also, I don't think the priority changes need to be part of this patch;
> without out I would give my reviewed-by.

OK, will split it.

Cheers,
Andre.

> 
>> Reading the information from there is
>> faster than accessing the property table from guest memory. Also it
>> use some padding area, so does not require more memory.
>> This introduces a do_LPI() as a hardware gic_ops and a function to
>> retrieve the (cached) priority value of an LPI and a vgic_ops.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/gic-v2.c|  7 
>>  xen/arch/arm/gic-v3-lpi.c| 71 
>> 
>>  xen/arch/arm/gic-v3.c|  1 +
>>  xen/arch/arm/gic.c   |  8 -
>>  xen/arch/arm/vgic-v2.c   |  7 
>>  xen/arch/arm/vgic-v3.c   | 18 ++
>>  xen/arch/arm/vgic.c  |  7 +++-
>>  xen/include/asm-arm/domain.h |  3 +-
>>  xen/include/asm-arm/gic.h|  2 ++
>>  xen/include/asm-arm/gic_v3_its.h |  8 +
>>  xen/include/asm-arm/vgic.h   |  2 ++
>>  11 files changed, 131 insertions(+), 3 deletions(-)
>>

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

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

2017-05-25 Thread osstest service owner

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-examine  4 xen-install  fail REGR. vs. 109690
 test-amd64-amd64-qemuu-nested-amd 10 nested-setupfail REGR. vs. 109707
 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
109707

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 109690
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 109690
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 109690
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 109690
 test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail like 109707
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 109707
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 109707
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 109707
 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-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64  9 windows-installfail never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  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-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64  9 windows-installfail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemuu-win10-i386  9 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386  9 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64  9 windows-install fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64  9 windows-install fail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail

[Xen-devel] [PATCH v2 6/7] osstest: add a FreeBSD build to flights

2017-05-25 Thread Roger Pau Monne

This requires changes in several places in order to accommodate the
FreeBSD build, which although it's a build job, it doesn't have the
same set of dependencies as the current builds.

First, a new build recipe is added to sg-run-job, and accordingly
sg-run-job is also made aware about the differences between a Linux
and a FreeBSD build job.  A Linux build job requires ts-host-allocate
+ ts-host-install-twice + ts-xen-build-prep, while a FreeBSD build job
requires ts-host-allocate + ts-freebsd-host-install.

All the current build jobs are kept to use the Linux build recipe,
while the newly added build-freebsd is using the new FreeBSD recipe.

cri-getconfig is also modified to introduce two new helpers, used to
fetch a runvar and a stashed file from a specific job. This is needed
by the FreeBSD build job creator in order to fetch information from a
previous buildjob (so the output from a previous buildjob can be used
as input to a new buildjob).

Finally, the logic to create a FreeBSD build job is added to
mfi-common. This includes creating a FreeBSD build job, and also
testing the output of that build job (by creating another build job
that depends on the output of the first).

Note that the FreeBSD build job needs some input in order to setup a
FreeBSD host, and that can be fetched from different places:

1. Env variable FREEBSD_BUILDJOB: use the output from a previous
build--freebsd.

2. Env variables FREEBSD_IMAGE, FREEBSD_SETS, FREEBSD_VERSION: set
before calling into make-flight, provide the installer image, the sets
to install and the version being installed.

3. Config file FreeBSDImage, FreeBSDSets and FreeBSDVersion: same as
2. except that they are set on the config file.

Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - Replace freebsd_buildjob with freebsdbuildjob.
 - Replace FREEBSD_SETS/IMAGE with a single FREEBSD_DIST that points
   to a folder that should contain both things.
 - Document the FreeBSDDist and FreeBSDVersion config file options in
   the README file.
---
 README| 11 ++
 ap-common |  4 
 cri-getconfig | 37 ++
 mfi-common| 65 +++
 sg-run-job| 39 ---
 5 files changed, 144 insertions(+), 12 deletions(-)

diff --git a/README b/README
index b45058da..51243974 100644
--- a/README
+++ b/README
@@ -423,6 +423,17 @@ HostGroupFlags_
 DebianPreseed
Text to add to the debian-installer preseed file.  Optional.
 
+FreeBSDDist
+   Path to the folder that contains the FreeBSD install image and
+   the FreeBSD compressed install sets, together with the MANIFEST
+   file that holds the checksums. This is required in order to run
+   a FreeBSD host install if no previous FreeBSD buildjob is
+   available (ie: for example when running in standalone mode).
+
+FreeBSDVersion
+   Numeric value holding the major FreeBSD version of the media
+   provided in FreeBSDDist (ie: 12).
+
 
 
 Config settings relevant only to standalone mode
diff --git a/ap-common b/ap-common
index cbb815ce..d4fa7aef 100644
--- a/ap-common
+++ b/ap-common
@@ -37,6 +37,10 @@
 : ${PUSH_TREE_XTF:=$XENBITS:/home/xen/git/xtf.git}
 : ${BASE_TREE_XTF:=git://xenbits.xen.org/xtf.git}
 
+: ${TREE_FREEBSD:=git://github.com/freebsd/freebsd.git}
+: ${PUSH_TREE_FREEBSD:=$XENBITS:/home/xen/git/freebsd.git}
+: ${BASE_TREE_FREEBSD:=git://xenbits.xen.org/freebsd.git}
+
 : ${TREE_LIBVIRT:=git://libvirt.org/libvirt.git}
 : ${PUSH_TREE_LIBVIRT:=$XENBITS:/home/xen/git/libvirt.git}
 : ${BASE_TREE_LIBVIRT:=git://xenbits.xen.org/libvirt.git}
diff --git a/cri-getconfig b/cri-getconfig
index b2c91ac7..b7f7ae0c 100644
--- a/cri-getconfig
+++ b/cri-getconfig
@@ -25,6 +25,43 @@ getconfig () {
 '
 }
 
+# Get the path to a stashed file from another job.
+#
+# $1: current flight
+# $2: current job
+# $3: name of the stashed file
+# $4: flight (optional) and job where to fetch the stashed file from
+# (in $flight.$job format or $job).
+getstashed() {
+   perl -e '
+   use Osstest;
+   use Osstest::TestSupport;
+   csreadconfig();
+   $flight = "'$1'";
+   $job = "'$2'";
+   print get_stashed("'$3'", "'$4'") or die $!;
+   '
+}
+
+# Get a runvar from another job.
+#
+# $1: current flight
+# $2: current job
+# $3: name of the runvar
+# $4: flight (optional) and job where to fetch the runvar from
+# (in $flight.$job format or $job).
+
+getrunvar() {
+   perl -e '
+   use Osstest;
+   use Osstest::TestSupport;
+   csreadconfig();
+   $flight = "'$1'";
+   $job = "'$2'";
+   print get_runvar("'$3'", "'$4'") or die $!;
+   '
+}
+
 getconfig_TftpDiVersion_suite () {
perl -e '
use Osstest;
diff --git a/mfi-common b/mfi-common
index ec31e2ef..5b7d1887

[Xen-devel] [PATCH v2 2/7] osstest: move known_hosts generation to TestSupport

2017-05-25 Thread Roger Pau Monne

This is equivalent to the already existing authorized_keys function,
and generates the contents of the known_hosts file that should be
installed on targets.

Signed-off-by: Roger Pau Monné 
Acked-by: Ian Jackson 
---
 Osstest/Debian.pm  | 36 +---
 Osstest/TestSupport.pm | 41 -
 2 files changed, 41 insertions(+), 36 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 8ba48bfa..87539822 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -709,41 +709,7 @@ sub preseed_ssh ($$) {
 my ($ho,$sfx) = @_;
 
 my $authkeys_url= create_webfile($ho, "authkeys$sfx", authorized_keys());
-
-my $hostkeyfile= "$c{OverlayLocal}/etc/ssh/ssh_host_rsa_key.pub";
-my $hostkey= get_filecontents($hostkeyfile);
-chomp($hostkey); $hostkey.="\n";
-my $knownhosts= '';
-
-my $hostsq= $dbh_tests->prepare(<execute($flight);
-while (my ($node) = $hostsq->fetchrow_array()) {
-my $defaultfqdn = $node;
-$defaultfqdn .= ".$c{TestHostDomain}" unless $defaultfqdn =~ m/\./;
-
-my %props;
-$mhostdb->get_properties($node, \%props);
-
-my $longname= $props{Fqdn} // $defaultfqdn;
-my (@hostent)= gethostbyname($longname);
-if (!@hostent) {
-logm("skipping host key for nonexistent host $longname");
-next;
-}
-my $specs= join ',', $longname, $node, map {
-join '.', unpack 'W4', $_;
-} @hostent[4..$#hostent];
-logm("adding host key for $specs");
-$knownhosts.= "$specs ".$hostkey;
-}
-$hostsq->finish();
-
-$knownhosts.= "localhost,127.0.0.1 ".$hostkey;
-my $knownhosts_url= create_webfile($ho, "known_hosts$sfx", $knownhosts);
+my $knownhosts_url= create_webfile($ho, "known_hosts$sfx", known_hosts());
 
 preseed_hook_command($ho, 'late_command', $sfx, <prepare(<execute($flight);
+while (my ($node) = $hostsq->fetchrow_array()) {
+my $defaultfqdn = $node;
+$defaultfqdn .= ".$c{TestHostDomain}" unless $defaultfqdn =~ m/\./;
+
+my %props;
+$mhostdb->get_properties($node, \%props);
+
+my $longname= $props{Fqdn} // $defaultfqdn;
+my (@hostent)= gethostbyname($longname);
+if (!@hostent) {
+logm("skipping host key for nonexistent host $longname");
+next;
+}
+my $specs= join ',', $longname, $node, map {
+join '.', unpack 'W4', $_;
+} @hostent[4..$#hostent];
+logm("adding host key for $specs");
+$knownhosts.= "$specs ".$hostkey;
+}
+$hostsq->finish();
+
+$knownhosts.= "localhost,127.0.0.1 ".$hostkey;
+
+return $knownhosts;
+}
+
 sub cfg_tftp_di_version ($) {
 my ($suite) = @_;
 $suite //= 'x def suite'; # will not find $c{...}
-- 
2.11.0 (Apple Git-81)


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

[Xen-devel] [PATCH v2 4/7] osstest: add a FreeBSD host install recipe

2017-05-25 Thread Roger Pau Monne

The installation is performed using the bsdinstall tool, which is part
of the FreeBSD base system. The installer image is setup with the
osstest ssh keys and sshd enabled by default, which allows the test
harness to just ssh into the box, create the install config file and
launch the scripted install.

Currently the installation is done with ZFS only, in stripe mode, and
a single disk.

In order to support the FreeBSD installer a new method is added, that
allows setting the pxe boot of a host using a memdisk.

The install script either picks the binary images from the output of a
previous FreeBSD buildjob (yet to be introduced), or from the folder
pointed by freebsd_distpath. This folder should contain the installer
image (install.img) and the compressed install sets (kernel.txz,
base.txz) together with the MANIFEST file that contains the checksums.

Note that the FreeBSD installer image uses "memdisk" from pxelinux, so
the tftp root needs to provide a copy of memdisk.

Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - Use pkg bootstrap instead of pkg update.
 - Use freebsdbuildjob instead of freebsd_buildjob.
 - add "append raw" to the memdisk command line.
 - Use with-lock-ex instead of flock.
 - Use system_checked and an array to hold the locked command to
   execute.
 - Use an array to store the list of possible disk devices.
 - Use target_putfilecontents_root_stash in order to upload the
   install script to the target.
 - Remove the usage of TftpFreeBSDBase.
 - Use target_tftp_prefix in order to get the prefix for the tftp
   target image path.
 - Add a missing linewrap.
 - Replace the split used to get the runvar paths with a regexp.
 - Place the install sets at /root/osstest_sets instead of
   /tmp/osstest_sets.
 - Pick the sets/installer image from the freebsdbuildjob
   path_freebsdist or from the runvar variable freebsd_distpath.
 - Add a comment about which FreeBSD specific inputs the script
   consumes.
---
 Osstest/TestSupport.pm  |  22 +++-
 ts-freebsd-host-install | 263 
 2 files changed, 284 insertions(+), 1 deletion(-)
 create mode 100755 ts-freebsd-host-install

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 8b41a4bc..ba1d6cc9 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -118,7 +118,7 @@ BEGIN {
   await_webspace_fetch_byleaf create_webfile
   file_link_contents get_timeout
   setup_netboot_di setup_netboot_local host_netboot_file
- subst_netboot_template
+  subst_netboot_template setup_netboot_memdisk
 
   ether_prefix
 
@@ -2559,6 +2559,26 @@ default local
 END
 }
 
+sub setup_netboot_memdisk ($$) {
+my ($ho, $img) = @_;
+setup_netboot_bootcfg($ho, <.
+
+# The FreeBSD installer script consumes either one of the following
+# runvars:
+#
+# freebsd_distpath: points to a folder accessible by the controller that
+# should contain the installer image and the compressed install sets,
+# together with the MANIFEST file.
+#
+# freebsdbuildjob: points to a previous FreeBSD build job, that has
+# produced an installer image and compressed sets. The only runvar used
+# form the job pointed to by freebsdbuildjob is the path_freebsddist

[Xen-devel] [PATCH v2 3/7] osstest: introduce helper to get per-host tftp prefix

2017-05-25 Thread Roger Pau Monne

This is used in order to get the per-host tftp prefix, used to store
the host initrd file.

Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - New in this version.
---
 Osstest/TestSupport.pm | 8 +++-
 ts-host-install| 2 +-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 8c7078c5..8b41a4bc 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -67,7 +67,7 @@ BEGIN {
   target_run_apt
   target_install_packages target_install_packages_norec
   target_jobdir target_extract_jobdistpath_subdir
-  target_extract_jobdistpath
+  target_extract_jobdistpath target_tftp_prefix
   lv_create lv_dev_mapper
 
   poll_loop tcpconnect await_tcp
@@ -2278,6 +2278,12 @@ sub target_extract_jobdistpath ($) {
 target_cmd_root($ho, "cd / && tar -hzxf $distcopy", 300);
 }
 
+sub target_tftp_prefix ($) {
+my ($ho) = @_;
+
+return "$ho->{Tftp}{TmpDir}/" . hostnamepath($ho);
+}
+
 sub guest_find_domid ($$) {
 my ($ho,$gho) = @_;
 return if defined $gho->{Domid};
diff --git a/ts-host-install b/ts-host-install
index 299eae48..9f9c84fd 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -253,7 +253,7 @@ END
 push @initrds, "$initrd_overlay.cpio.gz";
 
 logm("using initrds: @initrds");
-my $initrd= "$ho->{Tftp}{TmpDir}".hostnamepath($ho)."--initrd.gz";
+my $initrd= target_tftp_prefix($ho) . "--initrd.gz";
 system_checked("cat -- @initrds >$ho->{Tftp}{Path}$initrd");
 
 push @dicmdline, "domain=$c{TestHostDomain}";
-- 
2.11.0 (Apple Git-81)


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

[Xen-devel] [PATCH v2 7/7] osstest: introduce make-freebsd-flight

2017-05-25 Thread Roger Pau Monne

At the moment this flight only contains a build-amd64-freebsd and
build-amd64-freebsd-again jobs, because that's all osstest can do with
FreeBSD now.

This allows testing FreeBSD specific functionality without generating
a fully-fledged flight, that also includes the Linux jobs.

Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - Replace freebsd_buildjob with freebsdbuildjob.
---
 make-freebsd-flight | 62 +
 1 file changed, 62 insertions(+)
 create mode 100755 make-freebsd-flight

diff --git a/make-freebsd-flight b/make-freebsd-flight
new file mode 100755
index ..10e8f863
--- /dev/null
+++ b/make-freebsd-flight
@@ -0,0 +1,62 @@
+#!/bin/bash
+
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2017 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see .
+
+
+set -e -o posix
+
+branch=$1
+xenbranch=$2
+blessing=$3
+buildflight=$4
+
+flight=`./cs-flight-create $blessing $branch`
+
+. ./cri-common
+. ./ap-common
+. ./mfi-common
+
+arch=amd64
+
+job_create_build_filter_callback () {
+:
+}
+
+job_create_build build-$arch-freebsd build-freebsd   \
+arch=$arch   \
+$RUNVARS $BUILD_RUNVARS $BUILD_FREEBSD_RUNVARS $arch_runvars \
+tree_freebsd=$TREE_FREEBSD   \
+revision_freebsd=$REVISION_FREEBSD
+version=`set_freebsd_build_job_flags $arch`
+
+# Pass new hostflags, now the buildhost must not be shared, since we are
+# testing the newly built image
+job_create_build build-$arch-freebsd-again build-freebsd \
+arch=$arch   \
+$RUNVARS $BUILD_RUNVARS $BUILD_FREEBSD_RUNVARS $arch_runvars \
+host_hostflags=arch-$arch,freebsd-$version,purpose-build \
+tree_freebsd=$TREE_FREEBSD   \
+revision_freebsd=$REVISION_FREEBSD   \
+freebsdbuildjob=build-$arch-freebsd
+
+echo $flight
+
+# Local variables:
+# mode: sh
+# sh-basic-offset: 2
+# indent-tabs-mode: nil
+# End:
-- 
2.11.0 (Apple Git-81)


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

[Xen-devel] [PATCH v2 1/7] osstest: make built_stash_file store a path_ runvar for each file

2017-05-25 Thread Roger Pau Monne

And introduce built_stash_debugfile in order the keep the previous
behavior of built_stash_file.

Signed-off-by: Roger Pau Monné 
Acked-by: Ian Jackson 
---
 Osstest/TestSupport.pm | 14 --
 ts-kernel-build|  4 ++--
 ts-xen-build   |  8 
 3 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index c23ac135..5f13eb0b 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -83,7 +83,7 @@ BEGIN {
   get_stashed open_unique_stashfile compress_stashed
   dir_identify_vcs
   build_url_vcs build_clone
-  built_stash built_stash_file
+  built_stash built_stash_file built_stash_debugfile
   built_compress_stashed
   hg_dir_revision git_dir_revision vcs_dir_revision
   store_revision store_vcs_revision
@@ -1445,7 +1445,7 @@ END
 store_runvar("path_$item", $stashleaf);
 }
 
-sub built_stash_file (;$) {
+sub built_stash_debugfile (;$) {
 my ($ho, $builddir, $item, $fname, $optional) = @_;
 my $build= "build";
 my $stashleaf= "$build/$item";
@@ -1458,6 +1458,16 @@ sub built_stash_file (;$) {
"$stash/$stashleaf");
 }
 
+sub built_stash_file (;$) {
+my ($ho, $builddir, $item, $fname, $optional) = @_;
+my $build= "build";
+my $stashleaf= "$build/$item";
+
+built_stash_debugfile($ho, $builddir, $item, $fname, $optional);
+store_runvar("path_$item", $stashleaf);
+}
+
+
 sub built_compress_stashed($) {
 my ($path) = @_;
 compress_stashed("build/$path");
diff --git a/ts-kernel-build b/ts-kernel-build
index 94e67a47..5b87f5a7 100755
--- a/ts-kernel-build
+++ b/ts-kernel-build
@@ -438,9 +438,9 @@ if ($r{tree_linuxfirmware}) {
 fwinstall();
 }
 built_stash($ho, $builddir, 'dist', 'kerndist');
-built_stash_file($ho, $builddir, 'vmlinux', 'linux/vmlinux');
+built_stash_debugfile($ho, $builddir, 'vmlinux', 'linux/vmlinux');
 built_compress_stashed('vmlinux');
-built_stash_file($ho, $builddir, 'config', 'linux/.config');
+built_stash_debugfile($ho, $builddir, 'config', 'linux/.config');
 
 sub enable_xen_config () {
 return <<'END';
diff --git a/ts-xen-build b/ts-xen-build
index 31acb9dd..0152ea05 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -209,10 +209,10 @@ sub stash () {
 "xen/dist/${part}install",
 "${part}dist");
 }
-built_stash_file($ho, $builddir, "xen-syms", "xen/xen/xen-syms", 1);
-built_stash_file($ho, $builddir, "xen-config", "xen/.config", 1);
-built_stash_file($ho, $builddir, "xen-hv-config", "xen/xen/.config", 1);
-built_stash_file($ho, $builddir, "seabios-config",
+built_stash_debugfile($ho, $builddir, "xen-syms", "xen/xen/xen-syms", 1);
+built_stash_debugfile($ho, $builddir, "xen-config", "xen/.config", 1);
+built_stash_debugfile($ho, $builddir, "xen-hv-config", "xen/xen/.config", 
1);
+built_stash_debugfile($ho, $builddir, "seabios-config",
 "xen/tools/firmware/seabios-dir-remote/.config", 1);
 built_compress_stashed("xen-syms");
 }
-- 
2.11.0 (Apple Git-81)


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

[Xen-devel] [PATCH v2 5/7] osstest: introduce a FreeBSD build script

2017-05-25 Thread Roger Pau Monne

In order to generate the FreeBSD installer image and the install
media.

The install sets are the vanilla ones generated by the 'ftp' release
target.  The installer image is handcrafted based on the filesystem
created by the 'bootonly' target, which is then populated with the ssh
host keys, and setup in order to use the serial console. The other
difference from upstream FreeBSD installer images is that the one
built by osstest uses a ramdisk instead of relying on the installer
media to be somehow attached, either on a CD or USB drive. This is
required in order to boot the image from pxelinux (where no CD or USB
is actually attached to the host, and everything is fetched from
tftp).

Due to the nature of the FreeBSD build, the outputs are different from
what osstest expects from a buildjob, more specifically
path_freebsddist points to a folder that contains the several outputs
form this buildjob.

Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - Remove the ts-build-check FreeBSD hack.
 - Use pkg-static instead of pkg.
 - Introduce buildcmd_stamped_logged_root and target_cmd_build_root.
 - Use target_cmd_build_root and buildcmd_stamped_logged_root in the
   ts-freebsd-build script.
 - Fix the script snippets to use <&1`;
diff --git a/ts-freebsd-build b/ts-freebsd-build
new file mode 100755
index ..df902e30
--- /dev/null
+++ b/ts-freebsd-build
@@ -0,0 +1,244 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2017 Citrix Inc.
+# 
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later

[Xen-devel] [PATCH v2 0/7] osstest: initial FreeBSD support

2017-05-25 Thread Roger Pau Monne

Hello,

This series introduces initial FreeBSD host support to osstest. The
current series allow installing a bare-metal host with FreeBSD and
building FreeBSD on it in order to generate new install media that can
be fed into the installer script.

This is still very limited, since no Xen testing is done on those
hosts, however it sets the base to add a Xen build test for FreeBSD.

Note that it should be quite easy to add more steps to the build
script so that FreeBSD VM images are also generated, that could be
used by osstest.

I've tried to add a detailed commit log at each relevant patch, so not
much more to add here in the cover letter.

The series can also be found on my git repo:

git://xenbits.xen.org/people/royger/osstest.git freebsd_v2

Thanks, Roger.


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

Re: [Xen-devel] [PATCH v9 03/28] ARM: GIC: Add checks for NULL pointer pending_irq's

2017-05-25 Thread Andre Przywara

Hi,

On 22/05/17 18:15, Julien Grall wrote:
> 
> 
> On 22/05/17 17:49, Andre Przywara wrote:
>> Hi,
> 
> Hi Andre,
> 
>> On 12/05/17 15:19, Julien Grall wrote:
>>> Hi Andre,
>>>
>>> On 11/05/17 18:53, Andre Przywara wrote:
 For LPIs the struct pending_irq's are dynamically allocated and the
 pointers will be stored in a radix tree. Since an LPI can be "unmapped"
 at any time, teach the VGIC how to deal with irq_to_pending() returning
 a NULL pointer.
 We just do nothing in this case or clean up the LR if the virtual LPI
 number was still in an LR.

 Those are all call sites for irq_to_pending(), as per:
 "git grep irq_to_pending", and their evaluations:
 (PROTECTED means: added NULL check and bailing out)

 xen/arch/arm/gic.c:
 gic_route_irq_to_guest(): only called for SPIs, added ASSERT()
 gic_remove_irq_from_guest(): only called for SPIs, added ASSERT()
 gic_remove_from_queues(): PROTECTED, called within VCPU VGIC lock
 gic_raise_inflight_irq(): PROTECTED, called under VCPU VGIC lock
 gic_raise_guest_irq(): PROTECTED, called under VCPU VGIC lock
 gic_update_one_lr(): PROTECTED, called under VCPU VGIC lock
>>>
>>> Even they are protected, an ASSERT would be useful.
>>
>> I am not sure I get what you mean here.
>> With PROTECTED I meant that the code checks for a irq_to_pending()
>> returning NULL and reacts accordingly.
>> ASSERTs are only for making sure that those functions are never called
>> for LPIs(), but the other functions can be called with an LPI, and they
>> can now cope with a NULL pending_irq.
>>
>> So what do I miss here?
> 
> I mean adding an ASSERT(spin_is_locked(vgic->vcpu)) in those functions
> if it is not done yet.

Well, that's what I meant with PROTECTED: all of them have that ASSERT
already.
So I consider this done then.

Cheers,
Andre.

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

Re: [Xen-devel] [PATCH for-4.9 2/2] Makefile: Regularise subdir targets and their dependencies

2017-05-25 Thread Roger Pau Monné

On Thu, May 25, 2017 at 04:45:48PM +0100, Ian Jackson wrote:
> Thanks to everyone for testing and review and acks.  I have just
> pushed those two commits to staging.
> 
> Roger Pau Monné writes ("Re: [Xen-devel] [PATCH for-4.9 2/2] Makefile: 
> Regularise subdir targets and their dependencies"):
> > Maybe it would be good to add a note like:
> > 
> > "All the Makefiles invoked with -C from the toplevel should have the
> > following targets: all, build, install, clean, distclean"
> 
> Yes, indeed.  How about the extra patch below ?
> There are some special cases, so I think `generally' is right.
> 
> I'll wait a bit for opinions, but given that this is a comment-only
> patch I guess Julien's exception for docs applies, so I will probably
> commit it tomorrow unless someone objects.
> 
> Ian.
> 
> From 352f4a1f9797d1eee94121565fb4e3d8fc698371 Mon Sep 17 00:00:00 2001
> From: Ian Jackson 
> Date: Thu, 25 May 2017 16:42:12 +0100
> Subject: [PATCH] Makefile: Mention usual targets of subdir Makefiles
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> Suggested-by: Roger Pau Monné 
> Signed-off-by: Ian Jackson 

Acked-by: Roger Pau Monné 

Thanks, Roger.

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

Re: [Xen-devel] Xen 4.9 RC4 test result

2017-05-25 Thread Julien Grall

On 25/05/17 09:01, Hao, Xudong wrote:

-Original Message-
From: Julien Grall [mailto:julien.gr...@arm.com]
Sent: Thursday, May 25, 2017 3:40 PM
To: Hao, Xudong ; xen-devel@lists.xen.org
Cc: n...@arm.com; Lars Kurth ; George Dunlap
; Kang, Luwei 
Subject: Re: Xen 4.9 RC4 test result

Hello Xudong,

On 23/05/2017 03:56, Hao, Xudong wrote:

We performed Xen 4.9 RC4 testing on Intel Xeon Skylake, Broadwell,
Haswell server platforms, verified many functional features on Xen 4.9.
We'd like to share the result out.

Thank you for the testing.

Most of features passed to testing on Xen 4.9 RC4, RAS and nested has
some bugs.

RAS:

1.  xen-mceinj tool testing cause dom0 crash
https://www.mail-archive.com/xen-devel@lists.xen.org/msg108671.html

2.  CPU online/offline fail, Luwei is fixing it:
https://www.mail-archive.com/xen-devel@lists.xen.org/msg108660.html

I would recommend to tag the patch with for-4.9 + CC me if this is a regression
and you would like the patch to be included in the next release.

It's a regression from Xen 4.8 to Xen 4.9. Yes, I'd like the patch be merged in 
next release.
The patch author Luwei already sent out v4, is it fine to reply the patch with 
"[PATCH v4 for-4.9]" ?

I would also mention it in the e-mail explaining why you want it for Xen 
4.9.

Cheers,

--
Julien Grall

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

[Xen-devel] Commit moratorium for branching Xen 4.9

2017-05-25 Thread Julien Grall


Hi,

The patches fixing the 2 outstanding regressions have been merged.

I would like to make another attempt to branch with the RC (4.9 RC7). I 
don't want to branch when master != staging, so please avoid committing 
new patches to staging now to let master catch up with staging. Another 
announcement will be made when the moratorium is lifted.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH for-4.9 2/2] Makefile: Regularise subdir targets and their dependencies

2017-05-25 Thread Julien Grall




On 25/05/17 16:45, Ian Jackson wrote:

Thanks to everyone for testing and review and acks.  I have just
pushed those two commits to staging.

Roger Pau Monné writes ("Re: [Xen-devel] [PATCH for-4.9 2/2] Makefile: Regularise 
subdir targets and their dependencies"):

Maybe it would be good to add a note like:

"All the Makefiles invoked with -C from the toplevel should have the
following targets: all, build, install, clean, distclean"


Yes, indeed.  How about the extra patch below ?
There are some special cases, so I think `generally' is right.

I'll wait a bit for opinions, but given that this is a comment-only
patch I guess Julien's exception for docs applies, so I will probably
commit it tomorrow unless someone objects.


That's right. However, I'd like to try branching tomorrow so we need 
staging != master.


Could you hold the patch until we branch? (I will send an e-mail for a 
commit moratorium).


Cheers,


--
Julien Grall

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

Re: [Xen-devel] [PATCH for-4.9 2/2] Makefile: Regularise subdir targets and their dependencies

2017-05-25 Thread Ian Jackson

Thanks to everyone for testing and review and acks.  I have just
pushed those two commits to staging.

Roger Pau Monné writes ("Re: [Xen-devel] [PATCH for-4.9 2/2] Makefile: 
Regularise subdir targets and their dependencies"):
> Maybe it would be good to add a note like:
> 
> "All the Makefiles invoked with -C from the toplevel should have the
> following targets: all, build, install, clean, distclean"

Yes, indeed.  How about the extra patch below ?
There are some special cases, so I think `generally' is right.

I'll wait a bit for opinions, but given that this is a comment-only
patch I guess Julien's exception for docs applies, so I will probably
commit it tomorrow unless someone objects.

Ian.

From 352f4a1f9797d1eee94121565fb4e3d8fc698371 Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Thu, 25 May 2017 16:42:12 +0100
Subject: [PATCH] Makefile: Mention usual targets of subdir Makefiles
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Suggested-by: Roger Pau Monné 
Signed-off-by: Ian Jackson 
CC: Wei Liu 
CC: M A Young 
CC: Andrew Cooper 
---
 Makefile | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Makefile b/Makefile
index 51905eb..2ff33df 100644
--- a/Makefile
+++ b/Makefile
@@ -90,6 +90,11 @@ test:
 #
 # Also, we have a number of targets COMPONENT which run
 # dist-COMPONENT, for convenience.
+#
+# The Makefiles invoked with -C from the toplevel should
+# generally have the following targets:
+#   all  build  install  clean  distclean
+
 
 .PHONY: dist
 dist: DESTDIR=$(DISTDIR)/install
-- 
2.1.4


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

[Xen-devel] Schedule is live for the Xen Project’s Annual Conference - Discounted Registration closes by end of May

2017-05-25 Thread Lars Kurth

Dear Community members,
 
Community, embedded, automotive, performance, hardware, and security are a few 
topics that will be covered during the upcoming Xen Project Developer and 
Design Summit 
(http://events.linuxfoundation.org/events/xen-developer-and-design-summit) 
happening July 11-13 in Budapest, Hungary. 

You can find the full schedule here: 
http://events.linuxfoundation.org/events/xen-developer-and-design-summit/program/schedule
 
The conference is combines the formats of the Xen Project Developer Summits 
with the Xen Project Hackathons, with talks in the morning and Design Sessions 
in the afternoon.

Here’s a sampling of some of the talks at the Summit:
* Dedicated Secure Domain as an Approach for Certification of Automotive Sector 
Solutions from Iurii Mykhalskyi of GlobalLogic
* Uniprof: Transparent Unikernel Performance Profiling and Debugging from 
Florian Schmidt of NEC
* Hypervisor-Based Security: Bringing Virtualized Exceptions Into the Game from 
Mihai Dontu of Bitdefender
* Bring up PCI Passthrough on ARM from Julien Grall of ARM
* Shared Coprocessor Framework on ARM - Oleksandr Andrushchenko, EPAM Systems
* Secure Containers with Xen and CoreOS rkt - Stefano Stabellini, Aporeto
* To Grant or Not to Grant? - João Martins, Oracle
 
Currently, we have an early bird special ($250), which will end at the end of 
May (see 
http://events.linuxfoundation.org/events/xen-developer-and-design-summit/attend/register).
 Note that the overall ticket price is higher compared to the past, as the 
event is 3 days long and based on your feedback from last year, we included 
lunch.

Also note that you can still submit design sessions: see 
http://events.linuxfoundation.org/events/xen-developer-and-design-summit/program/cfp-design-session
 
Best Regards
Lars
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.9 2/2] Makefile: Regularise subdir targets and their dependencies

2017-05-25 Thread Roger Pau Monné

On Wed, May 24, 2017 at 05:14:30PM +0100, Ian Jackson wrote:
> Recent changes to this Makefile have broken some build targets, and
> some parallel builds.
> 
> Looking at it, I think I have identified the undocumented design
> intent in the top-level Makefile.  So in this patch I document it, and
> also make it true.
> 
> In detail:
> 
>  * Add a comment with the new design intent
>  * Get rid of the ad-hoc rules for recursing into tools/include,
>and replace them with a pattern rule
>  * Add an appropriate dependency on TARGET-tools-public-headers from
>TARGET-tools and TARGET-stubdom (but not dist-*).
>  * Get rid of all the separate invocations of $(MAKE) -C tools/include
>which are now obsolete
>  * Un-deprecate the simple `tools' etc. targets (aliases for `dist-tools')
>which we seem not to be making any effort to get rid of
> 
> I have verified with the following shell script that after my change,
> the tree producese the same results for various build targets as
> 3fafdc28eb98 (before the Makefile-hacking started).
> 
> My tests failed as expected for make -C tools, both before and after.
> 
> Separately, there is a bug in the Makefiles that `make distclean-tools'
> fails.  I have not investigated that bug in detail.
> 
> #!/bin/bash
> 
> set -e
> set -o pipefail
> 
> listings=../listings
> 
> rm -rf $listings
> mkdir $listings
> 
> chks () {
>  reskey="C$subdir $*"
>  reskey="${reskey// /_}"
>  reskey="${reskey//\//:}"
>  lk=$listings/$reskey
>  for suffix in '' -xen -tools -stubdom -docs; do
>  case "$subdir:$suffix" in
>  .:*) ;;
>  *:) ;;
>  *) continue;;
>  esac
>  git clean -qxdff
>  rm -rf $output
>  printf '%s' "running -C$subdir suffix=$suffix "
>  case "$subdir $suffix" in
>  *xen*) ;;
>  *) printf 'configure '; ./configure >$lk.cfg 2>&1 ;;
>  esac
>  fail=''
>  for targ in $*; do
>  realtarg=$targ$suffix
>  printf '%s ' "$realtarg"
>  if ! make -C $subdir -j10 $realtarg >${lk}_${realtarg}.log 
> 2>&1
>  then
> fail=$realtarg
> break
>  fi
>  done
>  if [ "$fail" ]; then
>echo fail!
>echo "$fail failed" >$lk.list
>  else
>echo ok.
>(test ! -e "$output" || find $output) |sort >$lk.list
>  fi
> done
> }
> 
> subdirs='. xen docs tools'
> 
> output=$PWD/dist
> for subdir in $subdirs; do
> chks build clean distclean
> done
> 
> output=$PWD/dist
> subdir=.
> chks dist
> 
> export DESTDIR=$PWD/destdir
> output=$PWD/destdir
> for subdir in $subdirs; do
> chks install
> done
> 
> And the output:
> 
> (64)iwj@mariner:~/work/xen.git$ ~/junk/chks
> running -C. suffix= configure build clean distclean ok.
> running -C. suffix=-xen build-xen clean-xen distclean-xen ok.
> running -C. suffix=-tools configure build-tools clean-tools 
> distclean-tools fail!
> running -C. suffix=-stubdom configure build-stubdom clean-stubdom 
> distclean-stubdom ok.
> running -C. suffix=-docs configure build-docs clean-docs distclean-docs 
> ok.
> running -Cxen suffix= build clean distclean ok.
> running -Cdocs suffix= configure build clean distclean ok.
> running -Ctools suffix= configure build fail!
> running -C. suffix= configure dist ok.
> running -C. suffix=-xen dist-xen ok.
> running -C. suffix=-tools configure dist-tools ok.
> running -C. suffix=-stubdom configure dist-stubdom ok.
> running -C. suffix=-docs configure dist-docs ok.
> running -C. suffix= configure install ok.
> running -C. suffix=-xen install-xen ok.
> running -C. suffix=-tools configure install-tools ok.
> running -C. suffix=-stubdom configure install-stubdom ok.
> running -C. suffix=-docs configure install-docs ok.
> running -Cxen suffix= install ok.
> running -Cdocs suffix= configure install ok.
> running -Ctools suffix= configure install fail!
> (64)iwj@mariner:~/work/xen.git$
> 
> CC: Julien Grall 
> CC: M A Young 
> CC: Andrew Cooper 
> CC: Wei Liu 
> Signed-off-by: Ian Jackson 

Acked-by: Roger Pau Monné 

Just a minor nit/question.

> ---
>  Makefile | 39 +++
>  1 file changed, 23 insertions(+), 16 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index fc30b3c..51905eb 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -38,18 +38,13 @@ mini-os-dir-force-update: mini-os-dir
>  export XEN_TARGET_ARCH
>  export DESTDIR

Maybe it would be

Re: [Xen-devel] [PATCH for-4.9 1/2] tools/include/Makefile: Support `build' target

2017-05-25 Thread Roger Pau Monné

On Wed, May 24, 2017 at 05:14:29PM +0100, Ian Jackson wrote:
> This is the only one of the Makefiles invoked with -C from the
> toplevel which lacks this target.
> 
> CC: Julien Grall 
> CC: M A Young 
> CC: Andrew Cooper 
> CC: Wei Liu 
> Signed-off-by: Ian Jackson 

Acked-by: Roger Pau Monné 

Roger.

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

Re: [Xen-devel] Xen 4.9 rc6 [and 1 more messages]

2017-05-25 Thread Andrew Cooper

On 25/05/17 13:55, Julien Grall wrote:
> Hi Ian,
>
> On 25/05/17 13:42, Ian Jackson wrote:
>> Thanks for the test reports and the release-ack.  Ideally I would like
>> a review but I may not get one.  Julien, or Michael, do you feel
>> qualified to review this ?
>
> My knowledge of the build system is very limited. So I don't think my
> review here will be useful sorry.
>
>>
>> Looking at the REST MAINTAINERS:
>>
>> I know Andrew, Jan and Konrad are extremely busy right now so I don't
>> want to ask them to stare at these Makefiles, and Wei is away.
>>
>> Stefano, do you think you could look ?
>>
>> If I can't get a review, I do think I should get some kind of ack to
>> commit it.  An ack from a REST maintainer suffices I think.

If it helps, the arguments look persuasive and the changes appear to
match the arguments.

Acked-by: Andrew Cooper 

~Andrew

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

Re: [Xen-devel] Xen 4.9 rc6 [and 1 more messages]

2017-05-25 Thread Julien Grall


Hi Ian,

On 25/05/17 13:42, Ian Jackson wrote:

Thanks for the test reports and the release-ack.  Ideally I would like
a review but I may not get one.  Julien, or Michael, do you feel
qualified to review this ?


My knowledge of the build system is very limited. So I don't think my 
review here will be useful sorry.




Looking at the REST MAINTAINERS:

I know Andrew, Jan and Konrad are extremely busy right now so I don't
want to ask them to stare at these Makefiles, and Wei is away.

Stefano, do you think you could look ?

If I can't get a review, I do think I should get some kind of ack to
commit it.  An ack from a REST maintainer suffices I think.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] Xen 4.9 rc6 [and 1 more messages]

2017-05-25 Thread Ian Jackson

Thanks for the test reports and the release-ack.  Ideally I would like
a review but I may not get one.  Julien, or Michael, do you feel
qualified to review this ?

Looking at the REST MAINTAINERS:

I know Andrew, Jan and Konrad are extremely busy right now so I don't
want to ask them to stare at these Makefiles, and Wei is away.

Stefano, do you think you could look ?

If I can't get a review, I do think I should get some kind of ack to
commit it.  An ack from a REST maintainer suffices I think.

Thanks,
Ian.

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

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

2017-05-25 Thread osstest service owner

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop  fail blocked in 109656
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 109656
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 109656
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 109656
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 109656
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 109656
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 109656
 test-amd64-amd64-xl-qemut-ws16-amd64  9 windows-installfail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64  9 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemut-win10-i386  9 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386  9 windows-install fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64  9 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemut-ws16-amd64  9 windows-install fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail

[Xen-devel] [PATCH v2 1/3] libxl: add PV display device driver interface

2017-05-25 Thread Oleksandr Grytsov

From: Oleksandr Grytsov 

Signed-off-by: Oleksandr Grytsov 
---
 tools/libxl/Makefile |   2 +-
 tools/libxl/libxl.h  |  21 ++
 tools/libxl/libxl_create.c   |   3 +
 tools/libxl/libxl_device.c   | 178 -
 tools/libxl/libxl_internal.h |  24 +++
 tools/libxl/libxl_types.idl  |  40 +++-
 tools/libxl/libxl_types_internal.idl |   1 +
 tools/libxl/libxl_usb.c  |   2 +
 tools/libxl/libxl_utils.h|   4 +
 tools/libxl/libxl_vdispl.c   | 372 +++
 10 files changed, 643 insertions(+), 4 deletions(-)
 create mode 100644 tools/libxl/libxl_vdispl.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 566b706..3a932e1 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -138,7 +138,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o 
libxl_pci.o \
libxl_dom_suspend.o libxl_dom_save.o libxl_usb.o \
libxl_vtpm.o libxl_nic.o libxl_disk.o libxl_console.o \
libxl_cpupool.o libxl_mem.o libxl_sched.o libxl_tmem.o \
-   libxl_domain.o \
+   libxl_domain.o libxl_vdispl.o \
 $(LIBXL_OBJS-y)
 LIBXL_OBJS += libxl_genid.o
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 72ec39d..4eff121 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1833,6 +1833,27 @@ libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx 
*ctx, uint32_t domid, int *n
 int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
libxl_device_vtpm *vtpm, libxl_vtpminfo 
*vtpminfo);
 
+/* Virtual displays */
+int libxl_device_vdispl_add(libxl_ctx *ctx, uint32_t domid,
+libxl_device_vdispl *displ,
+const libxl_asyncop_how *ao_how)
+LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_device_vdispl_remove(libxl_ctx *ctx, uint32_t domid,
+   libxl_device_vdispl *vdispl,
+   const libxl_asyncop_how *ao_how)
+   LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_device_vdispl_destroy(libxl_ctx *ctx, uint32_t domid,
+libxl_device_vdispl *vdispl,
+const libxl_asyncop_how *ao_how)
+LIBXL_EXTERNAL_CALLERS_ONLY;
+
+libxl_device_vdispl *libxl_device_vdispl_list(libxl_ctx *ctx, uint32_t domid,
+  int *num);
+void libxl_device_vdispl_list_free(libxl_device_vdispl* list, int num);
+int libxl_device_vdispl_getinfo(libxl_ctx *ctx, uint32_t domid,
+libxl_device_vdispl *vdispl,
+libxl_vdisplinfo *vdisplinfo);
+
 /* Keyboard */
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb,
  const libxl_asyncop_how *ao_how)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 25389e1..b36383f 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1422,6 +1422,8 @@ out:
 
 #define libxl_device_dtdev_list NULL
 #define libxl_device_dtdev_compare NULL
+#define libxl__device_from_dtdev NULL
+#define libxl__device_dtdev_setdefault NULL
 static DEFINE_DEVICE_TYPE_STRUCT(dtdev);
 
 const struct libxl_device_type *device_type_tbl[] = {
@@ -1432,6 +1434,7 @@ const struct libxl_device_type *device_type_tbl[] = {
 __usbdev_devtype,
 __pcidev_devtype,
 __dtdev_devtype,
+__vdispl_devtype,
 NULL
 };
 
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 5e96676..2954800 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -18,7 +18,7 @@
 
 #include "libxl_internal.h"
 
-static char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device)
+char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device)
 {
 char *dom_path = libxl__xs_get_dompath(gc, device->domid);
 
@@ -1776,6 +1776,182 @@ out:
 return AO_CREATE_FAIL(rc);
 }
 
+static int device_add_domain_config(libxl__gc *gc, uint32_t domid,
+const struct libxl_device_type *dt,
+void *type)
+{
+int rc;
+libxl_domain_config d_config;
+libxl__domain_userdata_lock *lock = NULL;
+int *num_dev;
+int i;
+void *item = NULL;
+
+libxl_domain_config_init(_config);
+
+lock = libxl__lock_domain_userdata(gc, domid);
+if (!lock) {
+rc = ERROR_LOCK_FAIL; goto out;
+}
+
+rc = libxl__get_domain_configuration(gc, domid, _config);
+if (rc) goto out;
+
+num_dev = libxl__device_type_get_num(dt, _config);
+
+/* Check for existing device */

[Xen-devel] [PATCH v2 2/3] xl: add PV display device commands

2017-05-25 Thread Oleksandr Grytsov

From: Oleksandr Grytsov 

Signed-off-by: Oleksandr Grytsov 
---
 tools/xl/Makefile  |   1 +
 tools/xl/xl.h  |   3 +
 tools/xl/xl_cmdtable.c |  19 ++
 tools/xl/xl_parse.c|  77 ++-
 tools/xl/xl_parse.h|   2 +-
 tools/xl/xl_vdispl.c   | 166 +
 6 files changed, 266 insertions(+), 2 deletions(-)
 create mode 100644 tools/xl/xl_vdispl.c

diff --git a/tools/xl/Makefile b/tools/xl/Makefile
index e16f877..5c784b5 100644
--- a/tools/xl/Makefile
+++ b/tools/xl/Makefile
@@ -21,6 +21,7 @@ XL_OBJS += xl_vtpm.o xl_block.o xl_nic.o xl_usb.o
 XL_OBJS += xl_sched.o xl_pci.o xl_vcpu.o xl_cdrom.o xl_mem.o
 XL_OBJS += xl_psr.o xl_info.o xl_console.o xl_misc.o
 XL_OBJS += xl_vmcontrol.o xl_saverestore.o xl_migrate.o
+XL_OBJS += xl_vdispl.o
 
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxentoollog)
 $(XL_OBJS): CFLAGS += $(CFLAGS_XL)
diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index aa95b77..d361241 100644
--- a/tools/xl/xl.h
+++ b/tools/xl/xl.h
@@ -166,6 +166,9 @@ int main_blockdetach(int argc, char **argv);
 int main_vtpmattach(int argc, char **argv);
 int main_vtpmlist(int argc, char **argv);
 int main_vtpmdetach(int argc, char **argv);
+int main_vdisplattach(int argc, char **argv);
+int main_vdispllist(int argc, char **argv);
+int main_vdispldetach(int argc, char **argv);
 int main_usbctrl_attach(int argc, char **argv);
 int main_usbctrl_detach(int argc, char **argv);
 int main_usbdev_attach(int argc, char **argv);
diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index 7d97811..9f92663 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -372,6 +372,25 @@ struct cmd_spec cmd_table[] = {
   "Destroy a domain's virtual TPM device",
   " ",
 },
+{ "vdispl-attach",
+  _vdisplattach, 1, 1,
+  "Create a new virtual display device",
+  " [devId=] [backend=] [beAlloc=] 
[connectors='']",
+  "BackAlloc - set to 1 to allow backend allocated display buffers\n"
+  "Connectors - list of connector's description in ID:WxH format,\n"
+  " where: ID - unique connector ID, W - connector 
width,\n"
+  " H - connector height: 
connectors='id0:800x600;id1:1024x768'\n"
+},
+{ "vdispl-list",
+  _vdispllist, 0, 0,
+  "List virtual display devices for a domain",
+  "",
+},
+{ "vdispl-detach",
+  _vdispldetach, 0, 1,
+  "Destroy a domain's virtual display device",
+  " ",
+},
 { "uptime",
   _uptime, 0, 0,
   "Print uptime for all/some domains",
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index b72f990..6ed040a 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -803,6 +803,53 @@ int parse_usbdev_config(libxl_device_usbdev *usbdev, char 
*token)
 return 0;
 }
 
+int parse_vdispl_config(libxl_device_vdispl *vdispl, char *token)
+{
+char *oparg;
+libxl_string_list connectors = NULL;
+int i;
+int rc;
+
+if (MATCH_OPTION("backend", token, oparg)) {
+vdispl->backend_domname = strdup(oparg);
+} else if (MATCH_OPTION("devId", token, oparg)) {
+vdispl->devid = atoi(oparg);
+} else if (MATCH_OPTION("beAlloc", token, oparg)) {
+vdispl->be_alloc = strtoul(oparg, NULL, 0);
+} else if (MATCH_OPTION("connectors", token, oparg)) {
+split_string_into_string_list(oparg, ";", );
+
+vdispl->num_connectors = libxl_string_list_length();
+vdispl->connectors = calloc(vdispl->num_connectors,
+sizeof(*vdispl->connectors));
+
+for(i = 0; i < vdispl->num_connectors; i++)
+{
+char *resolution;
+
+rc = split_string_into_pair(connectors[i], ":",
+>connectors[i].id,
+);
+
+rc= sscanf(resolution, "%ux%u", >connectors[i].width,
+   >connectors[i].height);
+if (rc != 2) {
+fprintf(stderr, "Can't parse connector resolution\n");
+goto out;
+}
+}
+} else {
+fprintf(stderr, "Unknown string \"%s\" in vdispl spec\n", token);
+rc = 1; goto out;
+}
+
+rc = 0;
+
+out:
+libxl_string_list_dispose();
+return rc;
+}
+
 void parse_config_data(const char *config_source,
const char *config_data,
int config_len,
@@ -812,7 +859,7 @@ void parse_config_data(const char *config_source,
 long l, vcpus = 0;
 XLU_Config *config;
 XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms,
-   *usbctrls, *usbdevs;
+   *usbctrls, *usbdevs, *vdispls;
 XLU_ConfigList *channels, *ioports, *irqs, *iomem, *viridian, *dtdevs;
 int num_ioports, num_irqs, num_iomem, num_cpus, num_viridian;
 int

[Xen-devel] [PATCH v2 0/3] libxl: add PV display device driver interface

2017-05-25 Thread Oleksandr Grytsov

From: Oleksandr Grytsov 

These patches add PV display device to libxl and xl.

Changes since v1:
 * add connector id;
 * set connector resolution and id to Xen store;

Oleksandr Grytsov (3):
  libxl: add PV display device driver interface
  xl: add PV display device commands
  docs: add virtual display driver information

 docs/man/xl.cfg.pod.5.in |  54 +
 docs/man/xl.pod.1.in |  42 
 tools/libxl/Makefile |   2 +-
 tools/libxl/libxl.h  |  21 ++
 tools/libxl/libxl_create.c   |   3 +
 tools/libxl/libxl_device.c   | 178 -
 tools/libxl/libxl_internal.h |  24 +++
 tools/libxl/libxl_types.idl  |  40 +++-
 tools/libxl/libxl_types_internal.idl |   1 +
 tools/libxl/libxl_usb.c  |   2 +
 tools/libxl/libxl_utils.h|   4 +
 tools/libxl/libxl_vdispl.c   | 372 +++
 tools/xl/Makefile|   1 +
 tools/xl/xl.h|   3 +
 tools/xl/xl_cmdtable.c   |  19 ++
 tools/xl/xl_parse.c  |  77 +++-
 tools/xl/xl_parse.h  |   2 +-
 tools/xl/xl_vdispl.c | 166 
 18 files changed, 1005 insertions(+), 6 deletions(-)
 create mode 100644 tools/libxl/libxl_vdispl.c
 create mode 100644 tools/xl/xl_vdispl.c

-- 
2.7.4


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

[Xen-devel] [PATCH v2 3/3] docs: add virtual display driver information

2017-05-25 Thread Oleksandr Grytsov

Signed-off-by: Oleksandr Grytsov 
---
 docs/man/xl.cfg.pod.5.in | 54 
 docs/man/xl.pod.1.in | 42 +
 2 files changed, 96 insertions(+)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 52802d5..8c5a593 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -1064,6 +1064,60 @@ FIFO-based event channel ABI support up to 131,071 event 
channels.
 Other guests are limited to 4095 (64-bit x86 and ARM) or 1023 (32-bit
 x86).
 
+=item

Re: [Xen-devel] [PATCH for-4.9 2/2] Makefile: Regularise subdir targets and their dependencies

2017-05-25 Thread Julien Grall




On 24/05/17 18:14, Andrew Cooper wrote:

On 24/05/17 17:14, Ian Jackson wrote:

CC: Julien Grall 
CC: M A Young 
CC: Andrew Cooper 
CC: Wei Liu 
Signed-off-by: Ian Jackson 


This resolves all the XenServer build issues I encountered.

Tested-by: Andrew Cooper 


Release-acked-by: Julien Grall 





--
Julien Grall

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

[Xen-devel] [PATCH] x86/vmx: Fix vmentry failure because of invalid LER on Broadwell

2017-05-25 Thread Ross Lagerwall

Occasionally, the top three bits of MSR_IA32_LASTINTTOIP
(MSR_LER_TO_LIP) may be incorrect, as though the MSR is using the
LBR_FORMAT_EIP_FLAGS_TSX format. The MSR should contain an offset into
the current code segment according to the Intel documentation. It is not
clear why this happens. It may be due to erratum BDF14, or some other
errata.  The result is a vmentry failure.

Workaround the issue by sign-extending into bits 61:63 for this MSR on
Broadwell CPUs.
---
 xen/arch/x86/hvm/vmx/vmx.c | 29 +
 xen/include/asm-x86/hvm/vmx/vmcs.h |  1 +
 2 files changed, 30 insertions(+)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index c8ef18a..7d729af 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2434,6 +2434,7 @@ static void pi_notification_interrupt(struct 
cpu_user_regs *regs)
 }
 
 static void __init lbr_tsx_fixup_check(void);
+static void __init ler_bdw_fixup_check(void);
 
 const struct hvm_function_table * __init start_vmx(void)
 {
@@ -2499,6 +2500,7 @@ const struct hvm_function_table * __init start_vmx(void)
 setup_vmcs_dump();
 
 lbr_tsx_fixup_check();
+ler_bdw_fixup_check();
 
 return _function_table;
 }
@@ -2790,8 +2792,10 @@ enum
 };
 
 #define LBR_FROM_SIGNEXT_2MSB  ((1ULL << 59) | (1ULL << 60))
+#define LER_TO_SIGNEXT_3MSB  (LBR_FROM_SIGNEXT_2MSB | (1ULL << 58))
 
 static bool __read_mostly lbr_tsx_fixup_needed;
+static bool __read_mostly ler_bdw_fixup_needed;
 static uint32_t __read_mostly lbr_from_start;
 static uint32_t __read_mostly lbr_from_end;
 static uint32_t __read_mostly lbr_lastint_from;
@@ -2828,6 +2832,13 @@ static void __init lbr_tsx_fixup_check(void)
 }
 }
 
+static void __init ler_bdw_fixup_check(void)
+{
+/* Broadwell E5-2600 v4 processors need to work around erratum BDF14. */
+if ( boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 79 )
+ler_bdw_fixup_needed = true;
+}
+
 static int is_last_branch_msr(u32 ecx)
 {
 const struct lbr_info *lbr = last_branch_msr_get();
@@ -3089,6 +3100,8 @@ static int vmx_msr_write_intercept(unsigned int msr, 
uint64_t msr_content)
 vmx_disable_intercept_for_msr(v, lbr->base + i, 
MSR_TYPE_R | MSR_TYPE_W);
 v->arch.hvm_vmx.lbr_tsx_fixup_enabled =
 lbr_tsx_fixup_needed;
+v->arch.hvm_vmx.ler_bdw_fixup_enabled =
+ler_bdw_fixup_needed;
 }
 }
 
@@ -4174,6 +4187,20 @@ static void lbr_tsx_fixup(void)
 msr->data |= ((LBR_FROM_SIGNEXT_2MSB & msr->data) << 2);
 }
 
+static void ler_bdw_fixup(void)
+{
+struct vmx_msr_entry *msr;
+
+/*
+ * Occasionally, the top three bits of MSR_IA32_LASTINTTOIP may be
+ * incorrect (possibly due to BDF14), as though the MSR is using the
+ * LBR_FORMAT_EIP_FLAGS_TSX format. This is incorrect and causes a vmentry
+ * failure -- the MSR should contain an offset into the current code
+ * segment. Fix it up by sign-extending into bits 61:63. */
+if ( (msr = vmx_find_msr(MSR_IA32_LASTINTTOIP, VMX_GUEST_MSR)) != NULL )
+msr->data |= ((LER_TO_SIGNEXT_3MSB & msr->data) << 3);
+}
+
 void vmx_vmenter_helper(const struct cpu_user_regs *regs)
 {
 struct vcpu *curr = current;
@@ -4232,6 +4259,8 @@ void vmx_vmenter_helper(const struct cpu_user_regs *regs)
  out:
 if ( unlikely(curr->arch.hvm_vmx.lbr_tsx_fixup_enabled) )
 lbr_tsx_fixup();
+if ( unlikely(curr->arch.hvm_vmx.ler_bdw_fixup_enabled) )
+ler_bdw_fixup();
 
 HVMTRACE_ND(VMENTRY, 0, 1/*cycles*/, 0, 0, 0, 0, 0, 0, 0);
 
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h 
b/xen/include/asm-x86/hvm/vmx/vmcs.h
index 9507bd2..aedef82 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -137,6 +137,7 @@ struct arch_vmx_struct {
 uint8_t  vmx_emulate;
 
 bool lbr_tsx_fixup_enabled;
+bool ler_bdw_fixup_enabled;
 
 /* Bitmask of segments that we can't safely use in virtual 8086 mode */
 uint16_t vm86_segment_mask;
-- 
2.9.4


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

[Xen-devel] [OSSTEST PATCH 2/2] ts-hosts-allocate-Executive: Make build failures not be host-sticky

2017-05-25 Thread Ian Jackson

Builds (jobs whose recipe contains `build') are not supposed to
contain host-specific tests.  We already don't care about varying
which host they run on, to hunt for host-specific bugs.

We should also not make build failures sticky to the host they last
failed on.

Fix this by defaulting $prevfail_bonus to 0 in that case, before the
week-long later default is applied.  This means that a build job
runvar would override the built-in default whether that's 7 days or 0.

Reported-by: Roger Pau Monné 
Signed-off-by: Ian Jackson 
---
 ts-hosts-allocate-Executive | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
index 7494291..975a8b9 100755
--- a/ts-hosts-allocate-Executive
+++ b/ts-hosts-allocate-Executive
@@ -624,6 +624,7 @@ sub hid_recurse ($$) {
 if ($jobinfo->{recipe} =~ m/build/) {
 $variation_age= 0;
$duration_for_cost= $duration + $duration_rightaway_adjust;
+   $prevfail_bonus //= 0;
 }
 
 my $log_variation_age = log(1+$variation_age/86400);
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 1/2] ts-hosts-allocate-Executive: Move $prevfail_bonus initial setting

2017-05-25 Thread Ian Jackson

No functional change.  This is going to make the next patch easy.

Reported-by: Roger Pau Monné 
Signed-off-by: Ian Jackson 
---
 ts-hosts-allocate-Executive | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
index 9955cba..7494291 100755
--- a/ts-hosts-allocate-Executive
+++ b/ts-hosts-allocate-Executive
@@ -618,6 +618,8 @@ sub hid_recurse ($$) {
 
 $duration_rightaway_adjust=0 if $start_time;
 
+my $prevfail_bonus = $r{hostalloc_bonus_previousfail}
+
 my $duration_for_cost = 0;
 if ($jobinfo->{recipe} =~ m/build/) {
 $variation_age= 0;
@@ -630,7 +632,7 @@ sub hid_recurse ($$) {
 $variation_bonus=$max_variation_bonus
if $variation_bonus>$max_variation_bonus;
 
-my $prevfail_bonus = $r{hostalloc_bonus_previousfail} // 7.0*86400;
+$prevfail_bonus //= 7.0*86400;
 my $prevfail_equiv_bonus = $prevfail_bonus * (6.5 / 7.0);
 
 my $share_reuse_bonus = $r{hostalloc_bonus_sharereuse} // 1;
-- 
2.1.4


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

[Xen-devel] [xen-unstable-smoke test] 109740: tolerable trouble: broken/pass - PUSHED

2017-05-25 Thread osstest service owner

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  d9eb706356ad4dbd04aad563ec4d2bcd3d7d6c03
baseline version:
 xen  7cc806d7f1d91dd4c4656f11226f043c749eb0ed

Last test of basis   109725  2017-05-24 17:02:34 Z0 days
Testing same since   109740  2017-05-25 09:17:45 Z0 days1 attempts


People who touched revisions under test:
  Anshul Makkar 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH 08/12 v3] xen/arm: vpl011: Modify xenconsole to support multiple consoles

2017-05-25 Thread Bhupinder Thakur

Hi,

On 17 May 2017 at 05:11, Stefano Stabellini  wrote:
> On Wed, 10 May 2017, Bhupinder Thakur wrote:
>> Xenconsole supports only PV console currently. This patch adds support
>> for supporting multiple consoles.
>>
>> This patch modifies different data structures and APIs used
>> in xenconsole to support multiple consoles.
>>
>> Change summary:
>>
>> 1. Split the domain structure into a console structure and the
>>domain structure, where each console structure represents one
>>console.
>>
>> 2. Modify different APIs such as buffer_append() etc. to take
>>console structure as input and perform per console specific
>>operations.
>>
>> 3. Define a generic console_create_ring(), which sets up the
>>ring buffer and event channel for each console.
>>
>> 3. Modify domain_create_ring() to use console_create_ring().
>>
>> 4. Modifications in handle_ring_read() to read ring buffer data
>>from multiple consoles.
>>
>> 5. Add log file support for multiple consoles.
>>
>> Signed-off-by: Bhupinder Thakur 
>
> There is something wrong with this patch: I cannot apply it.
>
> Also, it is still way to big for me to review. I cannot track all the
> changes and figure out if they are correct.
>
> One option is to introduce struct console in one patch, with only one
> struct console per domain. Then the second patch could introduce
> multiple struct console with the helpers such as console_iter_void_arg1.
>
> Finally the third patch could add vuart support.
>
I have divided the changes into 4 patches:

patch#1: This patch introduces the console structure and modifies the
code to use the new console structure.

patch#2: This patch modifies the functions to take console structure
as input instead of domain structure. Also it renames the console
specific functions to start with "console_" prefix instead of
"domain_" prefix. For example - domain_create_tty() is renamed to
console_create_tty().

patch#3: This patch adds the support for multiple consoles and
introduces the iterator functions to operate on multiple consoles.

patch#4: Finally this patch adds support for a new vuart console.

>> -static int create_domain_log(struct domain *dom)
>> +static int create_console_log(struct console *con)
>>  {
>>   char logfile[PATH_MAX];
>>   char *namepath, *data, *s;
>>   int fd;
>>   unsigned int len;
>> + struct domain *dom = con->d;
>>
>>   namepath = xs_get_domain_path(xs, dom->domid);
>>   s = realloc(namepath, strlen(namepath) + 6);
>> @@ -314,7 +443,9 @@ static int create_domain_log(struct domain *dom)
>>   return -1;
>>   }
>>
>> - snprintf(logfile, PATH_MAX-1, "%s/guest-%s.log", log_dir, data);
>> + snprintf(logfile, PATH_MAX-1, "%s%s/guest-%s.log",
>> +  log_dir, con->xspath, data);
>
> This changes the log directory, right? Are the new directories created
> correctly by the install scripts?
I will correct this. There should be no change in the path for PV
console log. I think by default guest logging is disabled. How can I
enable the logging to test it? I believe some option needs to be
passed while spawning xenconsoled?

Regards,
Bhupinder

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

Re: [Xen-devel] [TESTDAY] Test report

2017-05-25 Thread Julien Grall


Hi Andrii,

On 23/05/17 18:03, Andrii Anisov wrote:

* Hardware:
Salvator-X board with Renesas R-Car H3 SoC (ARM64)

* Software:
XEN 4.9-rc6
System based on Renesas Yocto 2.19.0 BSP [1]
Linux kernel 4.9

* Guest operating systems:
The same system as dom0.

* Functionality tested:
xl create/restart/shutdown
Guest domain reboot from its console
PV NET (nfsroot in domU) , PV Block (copy from xvda to nfsroot in DomU)

* Comments:

On DomU startup messages like following appeared:

root@salvator-x-domx:~# (XEN) printk: 9 messages suppressed.
(XEN) d1v0: vGICD: unhandled word write 0x to ICACTIVER0
(XEN) d1v1: vGICD: unhandled word write 0x to ICACTIVER0
(XEN) d1v2: vGICD: unhandled word write 0x to ICACTIVER0
(XEN) d1v3: vGICD: unhandled word write 0x to ICACTIVER0


The vGIC emulation does not emulate I*ACTIVER* registers so far. But 
Linux only accesses them at boot to ensure the firmware didn't leave 
interrupt in active state. They are harmless for now.



[   65.333062] xen-blkback: backend/vbd/1/51713: using 4 queues,
protocol 1 (arm-abi) persistent grants
[   65.357846] xen-blkback: backend/vbd/1/51714: using 4 queues,
protocol 1 (arm-abi) persistent grants
[   65.514054] vif vif-1-0 vif1.0: Guest Rx ready
[   65.518485] IPv6: ADDRCONF(NETDEV_CHANGE): vif1.0: link becomes
ready
[   65.525021] xenbr0: port 2(vif1.0) entered blocking state
[   65.530359] xenbr0: port 2(vif1.0) entered forwarding state
[   65.815976] xen_add_phys_to_mach_entry: cannot add
pfn=0x00063772 -> mfn=0x0072abb0: pfn=0x00063772
-> mfn=0x00727aad already exists
[   65.834442] xen_add_phys_to_mach_entry: cannot add
pfn=0x0006374e -> mfn=0x0072abb0: pfn=0x0006374e
-> mfn=0x00727aad already exists
[   66.025979] xen_add_phys_to_mach_entry: cannot add
pfn=0x0006379c -> mfn=0x0072abb3: pfn=0x0006379c
-> mfn=0x0072abb1 already exists
[   66.273534] xen_add_phys_to_mach_entry: cannot add
pfn=0x00063731 -> mfn=0x00727c3d: pfn=0x00063731
-> mfn=0x00727c3e already exists
[   66.328245] xen_add_phys_to_mach_entry: cannot add
pfn=0x000637ee -> mfn=0x00727c3f: pfn=0x000637ee
-> mfn=0x00727c3d already exists


I was expecting Stefano to answer here as he knows better than me this 
part of the code.


Linux is storing the conversion between pfn (guest frame number) to the 
mfn (machine frame number) in an RB-tree. This will be used by the 
swiotlb code to know if a buffer is contiguous in the physical RAM.


In your case, the log says that there was already a mapping pfn <-> mfn 
in the tree. It looks to me the previous mapping has not been removed 
correctly.


Are you able to reproduce this reliably? If so, can you try to figure 
out who added the first mapping pfn <-> mfn?


Cheers,

--
Julien Grall

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

[Xen-devel] Interrupt issues with hvm_emulate_one_vm_event()

2017-05-25 Thread Razvan Cojocaru

Hello,

I've noticed that, with pages marked NX and vm_event emulation, we can
end up emulating an ud2, for which hvm_emulate_one() returns
X86EMUL_EXCEPTION in hvm_emulate_one_vm_event().

This, in turn, causes a hvm_inject_event() call in the context of
hvm_do_resume(), which can, if there's already a pending event there,
cause a 101 BSOD (timer-related, if I understand correctly) or loss of
input (mouse frozen, keyboard unresponsive).

After much trial and error, I've been able to confirm this by leaving a
guest on for almost a full day with this change:

 case X86EMUL_EXCEPTION:
-hvm_inject_event();
+if ( !hvm_event_pending(current) )
+hvm_inject_event();

and checking that there's been no BSOD or loss of input.

However, just losing the event here, while fine to prove that this is
indeed the problem, is not OK. But I'm not sure what an elegant / robust
way of fixing this is.

Suggestions are (as always) greatly appreciated.


Thanks,
Razvan

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

[Xen-devel] [ovmf baseline-only test] 71430: tolerable FAIL

2017-05-25 Thread Platform Team regression test user

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-amd64-libvirt   5 libvirt-buildfail   like 71428
 build-i386-libvirt5 libvirt-buildfail   like 71428

version targeted for testing:
 ovmf 687bde9cac2ce1a45d916bc26caa370d15d58fce
baseline version:
 ovmf 0fff7d6740419417b65361529612a49a6a2b96b2

Last test of basis71428  2017-05-25 04:49:24 Z0 days
Testing same since71430  2017-05-25 07:16:43 Z0 days1 attempts


People who touched revisions under test:
  Yonghong Zhu 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-i386-libvirt   fail
 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 687bde9cac2ce1a45d916bc26caa370d15d58fce
Author: Yonghong Zhu 
Date:   Wed May 24 16:16:07 2017 +0800

BaseTools: Correct if condition expression for DatumType == 'VOID*'

Correct the if condition expression for DatumType == 'VOID*'. Current
this condition is not work since the DatumType is changed before we do
the value judgement.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
Reviewed-by: Liming Gao 

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

[Xen-devel] [distros-debian-wheezy test] 71429: tolerable trouble: broken/pass

2017-05-25 Thread Platform Team regression test user

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass

baseline version:
 flight   71341

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass
 test-amd64-i386-i386-wheezy-netboot-pvgrub   pass
 test-amd64-i386-amd64-wheezy-netboot-pygrub  pass
 test-amd64-amd64-i386-wheezy-netboot-pygrub  pass



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

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

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


Push not applicable.


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

Re: [Xen-devel] [Embedded-pv-devel] Migrated from Xenserver to Gentoo/Xen

2017-05-25 Thread Andrii Anisov


Dear Keith,


On 25.05.17 04:19, Keith Hamilton wrote:


Hey guys.  I just migrated the first of 2 servers from XenServer into 
a Gentoo/Xen environment.  I’m really excited and it’s working great!  
However I’m not sure if I’m doing the drivers correctly.  On my Server 
2016 vm I am having a hard time overwriting the XenServer PV drivers 
with the Xen ones from the website it just says that the driver is up 
to date.  I’m just wondering if I should worry that I don’t have the 
PV drivers installed from the Xen site and the XenServer ones are 
going to be ok.  I’m not sure what to do. I did a save state and then 
did a clean install of my 2016 server with no change.  I have gone 
into device manager and removed the XenServer Bus interface and a 
couple others in hopes to be able to install the ones from the 
XenProject site but it just renders the system unbootable.  I guess my 
question is, is there any simple way to remove the XenServer PV 
drivers on my 2016 server so that I can install the proprietary Xen PV 
drivers without having to do a complete format of the system.  I have 
already uninstalled all the citrix stuff I had installed..


== Keith



I guess xen-devel is more suitable list to ask server side questions.

--

*Andrii Anisov*



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

Re: [Xen-devel] Xen 4.9 RC4 test result

2017-05-25 Thread Hao, Xudong

Hi, Julien


> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: Thursday, May 25, 2017 3:40 PM
> To: Hao, Xudong ; xen-devel@lists.xen.org
> Cc: n...@arm.com; Lars Kurth ; George Dunlap
> ; Kang, Luwei 
> Subject: Re: Xen 4.9 RC4 test result
> 
> Hello Xudong,
> 
> On 23/05/2017 03:56, Hao, Xudong wrote:
> > We performed Xen 4.9 RC4 testing on Intel Xeon Skylake, Broadwell,
> > Haswell server platforms, verified many functional features on Xen 4.9.
> > We'd like to share the result out.
> 
> Thank you for the testing.
> 
> >
> >
> >
> > Most of features passed to testing on Xen 4.9 RC4, RAS and nested has
> > some bugs.
> >
> >
> >
> > RAS:
> >
> > 1.  xen-mceinj tool testing cause dom0 crash
> > https://www.mail-archive.com/xen-devel@lists.xen.org/msg108671.html
> >
> > 2.  CPU online/offline fail, Luwei is fixing it:
> > https://www.mail-archive.com/xen-devel@lists.xen.org/msg108660.html
> 
> I would recommend to tag the patch with for-4.9 + CC me if this is a 
> regression
> and you would like the patch to be included in the next release.
> 

It's a regression from Xen 4.8 to Xen 4.9. Yes, I'd like the patch be merged in 
next release.
The patch author Luwei already sent out v4, is it fine to reply the patch with 
"[PATCH v4 for-4.9]" ?

> >
> >
> >
> > Nested:
> >
> > Nested is worse although we know it's an experimental feature. Only
> > Xen on Xen works, others hybrid such as KVM on Xen, hyperV on Xen,
> > VMware on Xen all fail.
> >
> > The status is same as Xen 4.8 rc2.
> > https://wiki.xenproject.org/wiki/Nested_Virtualization_in_Xen
> 
> Would it be possible to update the wiki with Xen 4.9 rc4?
> 

We will, mostly maybe for next release or the 4.9 final release version if we 
have update data.


Thanks,
-Xudong

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

Re: [Xen-devel] Xen 4.9 RC4 test result

2017-05-25 Thread Julien Grall


Hello Xudong,

On 23/05/2017 03:56, Hao, Xudong wrote:

We performed Xen 4.9 RC4 testing on Intel Xeon Skylake, Broadwell,
Haswell server platforms, verified many functional features on Xen 4.9.
We’d like to share the result out.


Thank you for the testing.





Most of features passed to testing on Xen 4.9 RC4, RAS and nested has
some bugs.



RAS:

1.  xen-mceinj tool testing cause dom0 crash
https://www.mail-archive.com/xen-devel@lists.xen.org/msg108671.html

2.  CPU online/offline fail, Luwei is fixing it:
https://www.mail-archive.com/xen-devel@lists.xen.org/msg108660.html


I would recommend to tag the patch with for-4.9 + CC me if this is a 
regression and you would like the patch to be included in the next release.






Nested:

Nested is worse although we know it’s an experimental feature. Only Xen
on Xen works, others hybrid such as KVM on Xen, hyperV on Xen, VMware on
Xen all fail.

The status is same as Xen 4.8 rc2.
https://wiki.xenproject.org/wiki/Nested_Virtualization_in_Xen


Would it be possible to update the wiki with Xen 4.9 rc4?

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [[PATCH -v2]] XenBus: Don't wait for the producer to fill the ring if

2017-05-25 Thread Julien Grall




On 24/05/2017 15:16, Andrew Cooper wrote:

On 23/05/17 16:14, Jan Beulich wrote:

On 23.05.17 at 16:12,  wrote:

The condition: if there is a space in the ring then wait for the producer
to fill the ring also evaluates to true even if the ring if full. It
leads to a deadlock where producer is waiting for consumer
to consume the items and consumer is waiting for producer to fill the ring.

Fix for the issue: check if the ring is full and then break from
the loop to consume the items from the ring.
eg. case: prod = 1272, cons = 248.

Signed-off-by: Anshul Makkar 

Reviewed-by: Jan Beulich 

Julien,

do you want to consider this for 4.9?


I'd agree with including this in 4.9


Release-acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH for-4.9] docs: replace xm with xl in xen-tscmode [and 1 more messages]

2017-05-25 Thread Julien Grall


Hi Ian,

On 24/05/2017 12:07, Ian Jackson wrote:

Olaf Hering writes ("[PATCH] docs: replace xm with xl in xen-tscmode"):

Signed-off-by: Olaf Hering 


Olaf Hering writes ("[PATCH] docs: correct paragraph indention in xen-tscmode"):

Signed-off-by: Olaf Hering 


Both:

Acked-by: Ian Jackson 

I think these good for 4.9 and are covered by Julien's exception for
docs.  So Wei or I will commit them soon.


Yes that's correct.

Cheers,

--
Julien Grall

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

[Xen-devel] [ovmf baseline-only test] 71428: tolerable FAIL

2017-05-25 Thread Platform Team regression test user

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-amd64-libvirt   5 libvirt-buildfail   like 71426
 build-i386-libvirt5 libvirt-buildfail   like 71426

version targeted for testing:
 ovmf 0fff7d6740419417b65361529612a49a6a2b96b2
baseline version:
 ovmf a0284a9a5820e470bae2557a7e25c426e62c8a4e

Last test of basis71426  2017-05-24 20:19:12 Z0 days
Testing same since71428  2017-05-25 04:49:24 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Leif Lindholm 
  Michael D Kinney 
  Michael Kinney 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-i386-libvirt   fail
 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 0fff7d6740419417b65361529612a49a6a2b96b2
Author: Michael Kinney 
Date:   Tue May 23 12:22:37 2017 -0700

MdeModulePkg/DebugSupportDxe: Fix XCODE5 build failure

https://bugzilla.tianocore.org/show_bug.cgi?id=572

Update X64 AsmFuncs.S to resolve a build failure using the
XCODE5 tool chain.  This change updates AsmFuncs.S to match
AsmFuncs.asm and AsmFuncs.nasm.

The error generated in XCODE5 build is:

error: invalid instruction mnemonic 'movzxw'
movzxw 8(%rax), %rax
^~

The correct instruction is

movzwq 8(%rax), %rax

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Andrew Fish 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael D Kinney 
Reviewed-by: Andrew Fish 
Reviewed-by: Star Zeng 

commit c8206f22fd2fb6e72c291304d38d8d1ddee732ce
Author: Michael Kinney 
Date:   Tue May 23 12:03:39 2017 -0700

MdeModulePkg/RegularExpressionDxe: Fix XCODE5 build failure

https://bugzilla.tianocore.org/show_bug.cgi?id=572

The ErrorMessage local variable in OnigurumaMatch() should
be type OnigUChar instead of type CHAR8.  This resolves
a build failure with the XCODE5 tool chain.

Cc: Andrew Fish 
Cc: Star Zeng 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael D Kinney 
Reviewed-by: Andrew Fish 
Reviewed-by: Star Zeng 

commit 00b00cc57bfe0fca54c904d4dd44a263e243c88b
Author: Ard Biesheuvel 
Date:   Fri May 19 11:47:40 2017 +0100

BaseTools/Scripts: discard .gnu.hash section in GCC builds

Some builds of GCC/binutils will default to using the GNU flavor of
the symbol hash table, and will emit it into a section called .gnu.hash
rather than .hash. We have no use for its contents, and GenFw ignores
it anyway, so it shouldn't really matter what we do with it.

However, due to a workaround for AARCH64 we have in GenFw to deal with
older GCCs that corrupt section-based relocations when merging sections
during the final link, we need the ELF and PE/COFF views of the binary
to be identical. Since we don't place the .gnu.hash section explicitly,
it may end up at the beginning of the ELF binary, causing other sections
to be shifted in the ELF view but not in the PE/COFF view.

So let's add .gnu.hash to the GCC linker script. We don't care about its
contents so add it to the /DISCARD/ section.

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

2017-05-25 Thread osstest service owner

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 687bde9cac2ce1a45d916bc26caa370d15d58fce
baseline version:
 ovmf 0fff7d6740419417b65361529612a49a6a2b96b2

Last test of basis   109731  2017-05-25 02:17:19 Z0 days
Testing same since   109737  2017-05-25 05:15:36 Z0 days1 attempts


People who touched revisions under test:
  Yonghong Zhu 

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=687bde9cac2ce1a45d916bc26caa370d15d58fce
+ . ./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 
687bde9cac2ce1a45d916bc26caa370d15d58fce
+ branch=ovmf
+ revision=687bde9cac2ce1a45d916bc26caa370d15d58fce
+ . ./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.8-testing
+ '[' x687bde9cac2ce1a45d916bc26caa370d15d58fce = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ :

[Xen-devel] [linux-4.9 test] 109717: regressions - FAIL

2017-05-25 Thread osstest service owner

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2   6 xen-boot fail REGR. vs. 107358

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 109703 
pass in 109717
 test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail in 109703 
pass in 109717
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 109703 
pass in 109717
 test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail pass 
in 109703

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 107358
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail REGR. vs. 107358
 test-amd64-amd64-xl-rtds  9 debian-install   fail REGR. vs. 107358

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-start/win.repeat fail blocked in 
107358
 test-amd64-amd64-xl-qemut-ws16-amd64 8 leak-check/basis(8) fail in 109703 
baseline untested
 test-armhf-armhf-libvirt-raw  6 xen-boot fail  like 107358
 test-armhf-armhf-xl-xsm   6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt  6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail  like 107358
 test-armhf-armhf-xl-rtds  6 xen-boot fail  like 107358
 test-armhf-armhf-xl   6 xen-boot fail  like 107358
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail like 107358
 test-armhf-armhf-xl-vhd   6 xen-boot fail  like 107358
 test-amd64-amd64-xl-qemuu-ws16-amd64  9 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-examine  6 reboot   fail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64  9 windows-installfail never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-start/win.repeat  fail never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemut-win10-i386  9 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386  9 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386  9 windows-install fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64  9 windows-install fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64  9 windows-install fail never pass

version targeted for testing:
 linuxf5eea276d8de10a32e68721707ae8f2fdfaa0960
baseline version:
 linux

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

2017-05-25 Thread osstest service owner

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot fail REGR. vs. 109697
 test-amd64-i386-libvirt-xsm   6 xen-boot fail REGR. vs. 109697
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail REGR. vs. 109697
 test-amd64-amd64-xl-credit2   6 xen-boot fail REGR. vs. 109697
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
109697
 test-amd64-i386-pair  9 xen-boot/src_hostfail REGR. vs. 109697
 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 109697
 test-amd64-i386-xl-qemuu-win10-i386  6 xen-boot  fail REGR. vs. 109697
 test-amd64-i386-xl-qemuu-ws16-amd64  6 xen-boot  fail REGR. vs. 109697
 test-amd64-amd64-xl-qemuu-ws16-amd64  6 xen-boot fail REGR. vs. 109697
 test-amd64-i386-rumprun-i386  6 xen-boot fail REGR. vs. 109697
 test-amd64-i386-xl6 xen-boot fail REGR. vs. 109697
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot fail REGR. vs. 109697
 test-amd64-amd64-qemuu-nested-intel  6 xen-boot  fail REGR. vs. 109697
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. 
vs. 109697
 test-amd64-amd64-libvirt-vhd  6 xen-boot fail REGR. vs. 109697
 test-amd64-amd64-i386-pvgrub  6 xen-boot fail REGR. vs. 109697
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 109697
 test-amd64-i386-xl-qemut-win10-i386  6 xen-boot  fail REGR. vs. 109697
 test-amd64-amd64-xl-qemut-ws16-amd64  6 xen-boot fail REGR. vs. 109697
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot fail REGR. vs. 109697
 test-amd64-i386-libvirt   6 xen-boot fail REGR. vs. 109697
 test-amd64-amd64-xl-qemut-debianhvm-amd64  6 xen-bootfail REGR. vs. 109697
 test-amd64-amd64-amd64-pvgrub  6 xen-bootfail REGR. vs. 109697
 test-amd64-i386-freebsd10-amd64  6 xen-boot  fail REGR. vs. 109697
 test-amd64-amd64-libvirt-xsm  6 xen-boot fail REGR. vs. 109697
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 109697
 test-amd64-amd64-xl-pvh-amd   6 xen-boot fail REGR. vs. 109697
 test-amd64-i386-libvirt-pair  9 xen-boot/src_hostfail REGR. vs. 109697
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_hostfail REGR. vs. 109697
 test-amd64-amd64-libvirt  6 xen-boot fail REGR. vs. 109697
 test-amd64-i386-qemut-rhel6hvm-amd  6 xen-boot   fail REGR. vs. 109697
 test-amd64-amd64-xl-multivcpu  6 xen-bootfail REGR. vs. 109697
 test-amd64-i386-xl-qemut-ws16-amd64  6 xen-boot  fail REGR. vs. 109697
 test-amd64-amd64-xl-pvh-intel  6 xen-bootfail REGR. vs. 109697
 test-amd64-i386-xl-raw6 xen-boot fail REGR. vs. 109697
 test-amd64-i386-xl-xsm6 xen-boot fail REGR. vs. 109697
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 109697
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
109697
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-bootfail REGR. vs. 109697
 test-amd64-amd64-rumprun-amd64  6 xen-boot   fail REGR. vs. 109697
 test-amd64-amd64-xl   6 xen-boot fail REGR. vs. 109697
 test-amd64-amd64-pygrub   6 xen-boot fail REGR. vs. 109697
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 109697
 test-amd64-amd64-xl-qcow2 6 xen-boot fail REGR. vs. 109697
 test-amd64-i386-qemuu-rhel6hvm-amd  6 xen-boot   fail REGR. vs. 109697
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot fail REGR. vs. 109697
 test-amd64-amd64-xl-qemuu-win10-i386  6 xen-boot fail REGR. vs. 109697
 test-amd64-i386-freebsd10-i386  6 xen-boot   fail REGR. vs. 109697
 test-amd64-i386-examine   6 reboot   fail REGR. vs. 109697
 test-amd64-amd64-xl-qemut-win7-amd64  6 xen-boot fail REGR. vs. 109697
 test-amd64-i386-xl-qemut-win7-amd64  6 xen-boot  fail REGR. vs. 109697
 test-amd64-amd64-xl-qemut-win10-i386  6 xen-boot fail REGR. vs. 109697
 test-amd64-amd64-examine  6 reboot   fail REGR. vs. 109697
 test-amd64-amd64-qemuu-nested-amd  6 xen-bootfail REGR. vs. 109697
 test-amd64-amd64-xl-qemuu-win7-amd64  6 xen-boot fail REGR. vs. 109697
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
109697
 test-amd64-amd64-pair 9 xen-boot/src_hostfail REGR. vs. 109697
 test-amd64-amd64-pair10 xen-boot/dst_hostfail REGR. vs. 109697
 test-amd64-i386-xl-qemuu-win7-amd64  6 xen-boot

73 matches

Mail list logo