[Xen-devel] CFP: Platform Security Summit 2018: OpenXT, Xen Project and OpenEmbedded

[Rich Persaud]

If you are working on commercial, academic or open-source projects which use 
OpenXT, Xen Project or OpenEmbedded to implement platform components with 
well-defined security properties, you are invited to present at Platform 
Security Summit 2018, which will take place on May 23-24 in Fairfax, VA, USA.

Topics of interest include:

 - Virtualization-based isolation of open, proprietary and restricted code
 - Architecture for disaggregation of Xen-based systems
 - Mixed-criticality system design, testing and safety certification
 - Scheduling, hardware partitioning and hypervisor nesting
 - Xen PVH, PCI passthrough, PV-IOMMU, Qemu disaggregation

 - Hardware-rooted security technologies (e.g. TPM, TEE, SGX)
 - Measured launch, DRTM and SRTM deployment models
 - Stateless VMs and unikernels with OpenEmbedded
 - Reproducible, cross-compiled builds with OpenEmbedded
 - Spectre/Meltdown mitigations, performance & security

 - Inter-VM and Multi-Hypervisor Communication
 - Networking technologies for mutually trusting systems
 - Mandatory Access Control (e.g. SE Linux, Xen Security Modules)
 - Fuzzing of Xen, OpenEmbedded and platform firmware
 - GPU and co-processor virtualization 

The 2-day event will have a single track of presentations and discussions.  
There is no cost to attend, but space will be limited.  If you would like to 
present or attend, please respond to this message by Friday, 31st March, 
stating your organization name and topics of interest.

Rich___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-4.8-testing test] 120391: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 120116

Tests which are failing intermittently (not blocking):
 test-xtf-amd64-amd64-2 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 120350 pass 
in 120391
 test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 120350 pass 
in 120391
 test-xtf-amd64-amd64-4   50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 120350

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 120116

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 120116
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 120116
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 120116
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 120116
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 120116
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 120116
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 120116
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 120116
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-memop-seg fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 build-amd64-prev  7 xen-build/dist-test  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 build-i386-prev   7 xen-build/dist-test  fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 

Re: [Xen-devel] [PATCH 5/7] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

[Manish Jaggi]

On 10 March 2018 at 23:23, Manish Jaggi  wrote:
> Hi Sameer,
>
>
>
> On 02/09/2018 08:40 AM, Sameer Goel wrote:
>>
>> This driver follows an approach similar to smmu driver. The intent here
>> is to reuse as much Linux code as possible.
>> - Glue code has been introduced to bridge the API calls.
>> - Called Linux functions from the Xen IOMMU function calls.
>> - Xen modifications are preceded by /*Xen: comment */
>> - xen/linux_compat: Add a Linux compat header
>>For porting files directly from Linux it is useful to have a function
>> mapping
>>definitions from Linux to Xen. This file adds common API functions and
>>other defines that are needed for porting arm SMMU drivers.
>>
>> Signed-off-by: Sameer Goel 
>> ---
>>   xen/arch/arm/p2m.c|   1 +
>>   xen/drivers/Kconfig   |   2 +
>>   xen/drivers/passthrough/arm/Kconfig   |   8 +
>>   xen/drivers/passthrough/arm/Makefile  |   1 +
>>   xen/drivers/passthrough/arm/smmu-v3.c | 892
>> --
>>   xen/include/xen/linux_compat.h|  84 
>>   6 files changed, 959 insertions(+), 29 deletions(-)
>>   create mode 100644 xen/drivers/passthrough/arm/Kconfig
>>   create mode 100644 xen/include/xen/linux_compat.h
>>
>> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
>> index 65e8b9c6ea..fef7605fd6 100644
>> --- a/xen/arch/arm/p2m.c
>> +++ b/xen/arch/arm/p2m.c
>> @@ -1460,6 +1460,7 @@ err:
>>   static void __init setup_virt_paging_one(void *data)
>>   {
>>   unsigned long val = (unsigned long)data;
>> +/* SMMUv3 S2 cfg vtcr reuses the following value */
>>   WRITE_SYSREG32(val, VTCR_EL2);
>>   isb();
>>   }
>> diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
>> index bc3a54f0ea..612655386d 100644
>> --- a/xen/drivers/Kconfig
>> +++ b/xen/drivers/Kconfig
>> @@ -12,4 +12,6 @@ source "drivers/pci/Kconfig"
>> source "drivers/video/Kconfig"
>>   +source "drivers/passthrough/arm/Kconfig"
>> +
>>   endmenu
>> diff --git a/xen/drivers/passthrough/arm/Kconfig
>> b/xen/drivers/passthrough/arm/Kconfig
>> new file mode 100644
>> index 00..cda899f608
>> --- /dev/null
>> +++ b/xen/drivers/passthrough/arm/Kconfig
>> @@ -0,0 +1,8 @@
>> +
>> +config ARM_SMMU_v3
>> +   bool "ARM SMMUv3 Support"
>> +   depends on ARM_64
>> +   help
>> +Support for implementations of the ARM System MMU architecture
>> +version 3.
>> +
>> diff --git a/xen/drivers/passthrough/arm/Makefile
>> b/xen/drivers/passthrough/arm/Makefile
>> index f4cd26e15d..e14732b55c 100644
>> --- a/xen/drivers/passthrough/arm/Makefile
>> +++ b/xen/drivers/passthrough/arm/Makefile
>> @@ -1,2 +1,3 @@
>>   obj-y += iommu.o
>>   obj-y += smmu.o
>> +obj-$(CONFIG_ARM_SMMU_v3) += smmu-v3.o
>> diff --git a/xen/drivers/passthrough/arm/smmu-v3.c
>> b/xen/drivers/passthrough/arm/smmu-v3.c
>> index e67ba6c40f..f43485fe6e 100644
>> --- a/xen/drivers/passthrough/arm/smmu-v3.c
>> +++ b/xen/drivers/passthrough/arm/smmu-v3.c
>> @@ -18,28 +18,414 @@
>>* Author: Will Deacon 
>>*
>>* This driver is powered by bad coffee and bombay mix.
>> + *
>> + *
>> + * Based on Linux drivers/iommu/arm-smmu-v3.c
>> + * => commit 7aa8619a66aea52b145e04cbab4f8d6a4e5f3f3b
>> + *
>> + * Xen modifications:
>> + * Sameer Goel 
>> + * Copyright (C) 2017, The Linux Foundation, All rights reserved.
>> + *
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* Alias to Xen device tree helpers */
>> +#define device_node dt_device_node
>> +#define of_phandle_args dt_phandle_args
>> +#define of_device_id dt_device_match
>> +#define of_match_node dt_match_node
>> +#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np,
>> pname, out))
>> +#define of_property_read_bool dt_property_read_bool
>> +#define of_parse_phandle_with_args dt_parse_phandle_with_args
>> +
>> +/* Xen: Helpers to get device MMIO and IRQs */
>> +struct resource {
>> +   u64 addr;
>> +   u64 size;
>> +   unsigned int type;
>> +};
>> +
>> +#define resource_size(res) ((res)->size)
>> +
>> +#define platform_device device
>> +
>> +#define IORESOURCE_MEM 0
>> +#define IORESOURCE_IRQ 1
>> +
>> +static struct resource *platform_get_resource(struct platform_device
>> *pdev,
>> + unsigned int type,
>> + unsigned int num)
>> +{
>> +   /*
>> +* The resource is only used between 2 calls of
>> platform_get_resource.
>> +* It's quite ugly but it's avoid to add too much code in the
part
>> +* imported from Linux
>> +*/
>> +   static struct resource res;
>> +   struct 

Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support

[Peng Fan]

Hi Stefano,
On Fri, Mar 09, 2018 at 05:09:20PM -0800, Stefano Stabellini wrote:
>On Fri, 9 Mar 2018, Julien Grall wrote:
>> Furthermore, the workaround is not in Linux upstream and I doubt this will be
>> accepted as it is. So I am not convinced that we should modify Xen interface
>> for that.
>> 
>> Anyway, given that your silicon is going to be respined, then you probably
>> want to restrict to run on the same cluster.
>
>Hi Pen,
>
>I think that i.MX8 is a critical platform for the future of embedded
>virtualization and I really want to support it in Xen out of the box.
>
>However, I agree with Julien that if there will be a new version of the
>silicon with this issue properly fixed in hardware, then it might not
>make sense to add workarounds in Xen for this. Unless you think the
>version of the hardware with the errata will be commercialized?

Understand. I just thought some kernel code use machine
compatible string to do some check for passthrough case.

Some early customers might use the 1.0 chip to do their development,
but I think all will switch to use new Silicon in the end.

>
>Do you plan to upstream your workaround in Linux? If not, then it might

No plan. This workaround might not be accepted by Linux community.

>be best for you to carry the workaround for Xen in your Xen tree, the
>same way you'll do for Linux. For workarounds that affect/involve both
>Linux and Xen, we tend to follow the same policy as the Linux kernel,
>unless we have good reasons not to. On the other end, if you intend to
>upstream the Linux workaround, then we can discuss what to do for Xen.
>
>
>Also let me expand on one of Julien's suggestions that actually I think
>is quite good. Assuming that we have the tlb maintenance workaround in
>the hypervisor, it would be safe to start guests only in the big or only
>in the little cluster, right? In other words, you could still use both

I am a bit lost here. Are you refering Julien's suggestion 3?
"3) Trap all TLBs access from the guest and convert them to TLB 
alle1s/vmalls12e1is"

Currently, only use one the of the 2 clusters, I do not meet issue.
No change to xen and domu not aware of linux workaround.

Do you mean it is not safe without tlb maintenance workaround on my current
hardware, even if restricting Guest OS only have one kind of cpu?

A naive question, what case would require tlb broadcast from A53 to A72 in XEN? 
page balloon?

Thanks
Peng.

>clusters but only starting guests in one or the other, not both. This is
>a good compromise because it allows full usage of the hardware, a
>relatively small patch in Xen, and no guest visible changes (such as
>toolstack changes to modify the compatible line). Guest visible and user
>visible changes are particularly troublesome to maintain in the long
>term and this is reason why we are reticent in introducing them. The tlb
>maintenance workaround in the hypervisor is something much easier to
>manage and we could consider taking it in if hardware with the errata
>will become available to customers.
>
>Cheers,
>
>Stefano

-- 

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

Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support

[Peng Fan]

On Fri, Mar 09, 2018 at 02:40:25PM +, Julien Grall wrote:
>Hi,
>
>On 09/03/18 13:30, Peng Fan wrote:
>>Hi Julien,
>>On Fri, Mar 09, 2018 at 10:22:09AM +, Julien Grall wrote:
>>>Hi Peng,
>>>
>>>On 09/03/18 09:05, Peng Fan wrote:
On Thu, Mar 08, 2018 at 03:13:50PM +, Julien Grall wrote:
>On 08/03/18 12:43, Peng Fan wrote:
>There are a major difference between Dom0 and DomU in your setup.
>Dom0 vCPUs are pinned to a specific pCPU, so they can't move around.
>For DomU, each vCPU are pinned to a set of pCPUs, so they can move
>around.
>
>But, did you check the DomU has the workaround enabled? I am asking
>that because it looks like to me the way to detect the workaround is
>based on a device (scu) and not processor. So I am not convinced that
>DomU is actually using your workaround.

Just checked this. Because xen toolstack create device tree
with compatible "compatible = "xen,xenvm-4.10", "xen,xenvm";",
but the linux code use "fsl,imx8qm" to detect soc, then call scu
to get revision of chip.
>>>
>>>But how does the guest call the scu?
>>
>>We are doing GPU and display passthrough, also some other IPs passthrough.
>>we could not totally rely on Dom0 to configure the pinmux, gpio, clk,
>>relying on dom0 to do that would bring much hack code to our kernel, also
>>runtime clk set rate in domu could not be done.
>>
>>So we expose an interface to domu to directly communicate with SCU(system
>>control unit).
>
>Do you always expect a domain to access the SCU? Even with no
>passthrough involved?

only needed when a domain only needs to directly access hardware.

>
>>
>>>

After add an entry in linux side "{ .compatible = "xen,xenvm", .data = 
_soc_data, },"
It seems works. Passed a map/unmap stress test which easily fail without
the tlb workaround.

Wonder is it ok to specific machine compatible in domu.cfg and let xen stack
use this machine compatible other than "xen,xenvm"? Is this acceptable by 
community?
>>>
>>>A user should be able to boot a guest safely on any machine without
>>>having to hack the configuration file. He should also be able to boot
>>>a guest with both ACPI and DT as this is independent from the real
>>>machine. So for me the way to find the workaround at the moment is
>>>not acceptable for a Xen guest upstream.
>>
>>I have no idea about ACPI (:
>>we are mainly working on embedded case, and mostly we are partitioning
>>our IPs. So our kernel normally only work with the dedicated DTB.
>>I am not asking to replace "xen,xenvm", just would like to add a option
>>that if user specific a machine compatible in cfg or else, xen toolstack
>>could add that in the final device tree.
>
>I know you were suggesting that and my point stands. Xen VM are not
>compatible with IMX8 platform.
>
>And again, a user should not have to tweak his configuration file,
>have to passthrough some device to an untrusted guest in order to
>have a guest booting normally on your platform. That is breaking the
>whole purpose of virtualization.
>
>Furthermore, the workaround is not in Linux upstream and I doubt this
>will be accepted as it is. So I am not convinced that we should
>modify Xen interface for that.
>
>Anyway, given that your silicon is going to be respined, then you
>probably want to restrict to run on the same cluster.

Understand.

Thanks,
Peng.

>
>Cheers,
>
>-- 
>Julien Grall

-- 

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

[Xen-devel] [xen-4.9-testing test] 120385: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   6 xen-buildfail REGR. vs. 12
 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install   fail REGR. vs. 12
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-install  fail REGR. vs. 12
 test-armhf-armhf-xl-vhd   7 xen-boot   fail in 120336 REGR. vs. 12

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-xsm   6 xen-install  fail in 120336 pass in 120385
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 120336 
pass in 120385
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail pass 
in 120336

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 12 guest-startfail in 120336 REGR. vs. 12

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail blocked in 12
 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail in 120336 
like 119954
 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 120336 never pass
 test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 120336 never 
pass
 test-armhf-armhf-xl 13 migrate-support-check fail in 120336 never pass
 test-armhf-armhf-xl 14 saverestore-support-check fail in 120336 never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail in 120336 never 
pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail in 120336 
never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail in 120336 never 
pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail in 120336 
never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail in 120336 never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail in 120336 never 
pass
 test-armhf-armhf-libvirt13 migrate-support-check fail in 120336 never pass
 test-armhf-armhf-libvirt 14 saverestore-support-check fail in 120336 never pass
 test-armhf-armhf-xl-credit2 13 migrate-support-check fail in 120336 never pass
 test-armhf-armhf-xl-credit2 14 saverestore-support-check fail in 120336 never 
pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 120336 never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 120336 never 
pass
 test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 119954
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 12
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 12
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 12
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 12
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 

[Xen-devel] [linux-4.1 bisection] complete build-arm64-pvops

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job build-arm64-pvops
testid kernel-build

Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
  Bug introduced:  26bfa48da661f380e53780e148cbf30e8f2b8c9c
  Bug not present: 8e99fb51d17d12af389b00d44a831de051046b2d
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/120523/


  commit 26bfa48da661f380e53780e148cbf30e8f2b8c9c
  Author: Marc Zyngier 
  Date:   Tue Jan 16 10:23:47 2018 +
  
  arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls
  
  [ Upstream commit acfb3b883f6d6a4b5d27ad7fdded11f6a09ae6dd ]
  
  KVM doesn't follow the SMCCC when it comes to unimplemented calls,
  and inject an UNDEF instead of returning an error. Since firmware
  calls are now used for security mitigation, they are becoming more
  common, and the undef is counter productive.
  
  Instead, let's follow the SMCCC which states that -1 must be returned
  to the caller when getting an unknown function number.
  
  Cc: 
  Signed-off-by: Marc Zyngier 
  Signed-off-by: Christoffer Dall 
  Signed-off-by: Sasha Levin 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-4.1/build-arm64-pvops.kernel-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-4.1/build-arm64-pvops.kernel-build 
--summary-out=tmp/120523.bisection-summary --basis-template=118294 
--blessings=real,real-bisect linux-4.1 build-arm64-pvops kernel-build
Searching for failure / basis pass:
 120380 fail [host=laxton1] / 118294 ok.
Failure / basis pass flights: 120380 / 118294
Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Latest 6f20f6d4c095967c3debdb1d4c224ebf3da85452 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
Basis pass 30ad2851a645bb5f42c72f21ceb166877cf7e695 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#30ad2851a645bb5f42c72f21ceb166877cf7e695-6f20f6d4c095967c3debdb1d4c224ebf3da85452
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
Loaded 1001 nodes in revision graph
Searching for test results:
 118279 pass 30ad2851a645bb5f42c72f21ceb166877cf7e695 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 118294 pass 30ad2851a645bb5f42c72f21ceb166877cf7e695 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120380 fail 6f20f6d4c095967c3debdb1d4c224ebf3da85452 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120338 fail 6f20f6d4c095967c3debdb1d4c224ebf3da85452 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120379 pass 30ad2851a645bb5f42c72f21ceb166877cf7e695 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120495 fail 26bfa48da661f380e53780e148cbf30e8f2b8c9c 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120481 fail 26bfa48da661f380e53780e148cbf30e8f2b8c9c 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120433 fail 6f20f6d4c095967c3debdb1d4c224ebf3da85452 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120437 fail 7207bd5112750712b182253b4cd97528e1ef8fa9 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120467 pass 06faf7c003bf6c43ec1200029c680d8f051dd5f6 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120440 pass 3f30e73b418526585d99309fd02b5b56307cb83d 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120445 fail af7659fb189d0232dabe99010461415c89b65ca8 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120448 pass bac5a7ef66b31585b3e3c512c335561d14c3a861 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120454 pass b04b590eab4a13cbfa0b5e43bc91c496ce997ef9 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120470 pass c2a38c6dde8ef70fc4545f25b461a955e2be8853 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120488 pass 8e99fb51d17d12af389b00d44a831de051046b2d 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120499 pass 8e99fb51d17d12af389b00d44a831de051046b2d 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120506 fail 26bfa48da661f380e53780e148cbf30e8f2b8c9c 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120513 pass 8e99fb51d17d12af389b00d44a831de051046b2d 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120523 fail 26bfa48da661f380e53780e148cbf30e8f2b8c9c 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
Searching for interesting versions
 Result found: flight 118279 (pass), for basis pass
 Result found: flight 120338 (fail), for basis failure
 Repro found: flight 120379 (pass), for basis 

[Xen-devel] [seabios test] 120393: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 115539

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 seabios  5adc8bdea6a77bdb457d9cbca9a49a7d01cc25cd
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z  128 days
Failing since115733  2017-11-10 17:19:59 Z  121 days  145 attempts
Testing same since   120197  2018-03-03 11:37:53 Z8 days5 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Marc-André Lureau 
  Marcel Apfelbaum 
  Michael S. Tsirkin 
  Nikolay Nikolov 
  Paul Menzel 
  Stefan Berger 
  Stephen Douthit 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel 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


Not pushing.

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

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

Re: [Xen-devel] [PATCH 03/11] xen: defer call to xen_restrict until just before os_setup_post

[Stefano Stabellini]

On Fri, 9 Mar 2018, Eduardo Habkost wrote:
> On Fri, Mar 09, 2018 at 12:07:21PM +, Ian Jackson wrote:
> > Ian Jackson writes ("Re: [PATCH 03/11] xen: defer call to xen_restrict 
> > until just before os_setup_post"):
> > > Eduardo Habkost writes ("Re: [PATCH 03/11] xen: defer call to 
> > > xen_restrict until just before os_setup_post"):
> > > > I don't think we should have accelerator-specific code in main(),
> > > > if we already have accelerator classes that can abstract that
> > > > out.  I suggest adding a AccelClass;:setup_post() method that can
> > > > be called here.
> > > 
> > > I think I can do that.
> > 
> > How about this ?
> > 
> > From 61f11221afaa29e10021599420238e03836ba413 Mon Sep 17 00:00:00 2001
> > From: Ian Jackson 
> > Date: Fri, 9 Mar 2018 12:02:50 +
> > Subject: [PATCH v6.2 12/11] AccelClass: Introduce accel_setup_post
> > 
> > This is called just before os_setup_post.  Currently none of the
> > accelerators provide this hook, but the Xen one is going to provide
> > one in a moment.
> > 
> > Signed-off-by: Ian Jackson 
> 
> Looks good to me.
> 
> Reviewed-by: Eduardo Habkost 
> 
> That said, I don't think this should block the inclusion of the
> previous patch in 2.12, if the Xen maintainers were already going
> to merge it.

Ian,

The Xen side is almost entirely reviewed and should be OK, but you need
reviewed-bys on some non-Xen specific patches: #7 #8 #11.

Cheers,

Stefano

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

Re: [Xen-devel] [alsa-devel] [PATCH 0/2] sndif: add explicit back and front synchronization

[Takashi Iwai]

Hi,

sorry for the long latency.

On Wed, 07 Mar 2018 09:49:24 +0100,
Oleksandr Andrushchenko wrote:
> 
> > Suppose that we negotiate from the frontend to the backend like
> >
> > int query_hw_param(int parm, int *min_p, int *max_p);
> >
> > so that you can call like
> > err = query_hw_param(PARM_RATE, _rate, _rate);
> >
> > This assumes that min_rate and max_rate were already filled by the
> > values requested from frontend user-space.  In query_hw_parm, the
> > backend receives this range, checks it, and fills again the actually
> > applicable range that satisfies the given range in return.
> >
> > In that way, user-space will reduce the configuration space
> > repeatedly.  And at the last step, the configurator chooses the
> > optimal values that fit in the given configuration space.
> >
> > As mentioned in the previous post, in your driver at open, you'd need
> > to add the hw constraint for each parameter.  That would be like:
> >
> > err = snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_RATE,
> >   hw_rule_rate, NULL, -1);
> >
> > and hw_rule_rate() would look like:
> >
> > static int hw_rule_rate(struct snd_pcm_hw_params *params,
> > struct snd_pcm_hw_rule *rule)
> > {
> > struct snd_interval *p =
> > hw_param_interval(params, SNDRV_PCM_HW_PARAM_RATE);
> > int min_rate = p->min;
> > int max_rate = p->max;
> > struct snd_interval t;
> > int err;
> >
> > err = query_hw_param(PARM_RATE, _rate, _rate);
> > if (err < 0)
> > return err;
> >
> > t.min = min_rate;
> > t.max = max_rate;
> > t.openmin = t.openmax = 0;
> > t.integer = 1;
> >
> > return snd_interval_refine(p, );
> > }
> >
> > The above is simplified not to allow the open min/max and assume only
> > integer, which should be enough for your cases, I suppose.
> >
> > And the above function can be generalized like
> >
> > static int hw_rule_interval(struct snd_pcm_hw_params *params,
> > struct snd_pcm_hw_rule *rule)
> > {
> > struct snd_interval *p =
> > hw_param_interval(params, rule->var);
> > int min_val = p->min;
> > int max_val = p->max;
> > struct snd_interval t;
> > int err;
> >
> > err = query_hw_param(alsa_parm_to_xen_parm(rule->var),
> > _val, _val);
> > if (err < 0)
> > return err;
> >
> > t.min = min_val;
> > t.max = max_val;
> > t.openmin = t.openmax = 0;
> > t.integer = 1;
> >
> > return snd_interval_refine(p, );
> > }
> >
> > and registering this via
> >
> > err = snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_RATE,
> >   hw_rule_interval, NULL, -1);
> >
> > In the above NULL can be referred in the callback via rule->private,
> > if you need some closure in the function, too.
> Thank you so much for that detailed explanation and code sample!!!
> This is really great to see such a comprehensive response.
> Meanwhile, I did a yet another change to the protocol (please find
> attached) which will be added to those two found in this patch set
> already:
> In order to provide explicit stream parameter negotiation between
>     backend and frontend the following changes are introduced in the
> protocol:
>  - add XENSND_OP_HW_PARAM_SET request to set one of the stream
>    parameters: frame rate, sample rate, number of channels,
>    buffer and period sizes
>  - add XENSND_OP_HW_PARAM_QUERY request to read a reduced
>    configuration space for the parameter given: in the response
>    to this request return min/max interval for the parameter
>    given
>  - add minimum buffer size to XenStore configuration
> 
> With this change:
> 1. Frontend sends XENSND_OP_HW_PARAM_SET to the backend in response
> to user space's snd_pcm_hw_params_set_XXX calls, using XenStore entries
> as initial configuration space (this is what returned on
> snd_pcm_hw_params_any)
> 2. Frontend uses snd_pcm_hw_rule_add to set the rules (for sample rate,
> format, number of channels, buffer and period sizes) as you described
> above: querying is done with XENSND_OP_HW_PARAM_QUERY request
> 3. Finally, frontend issues XENSND_OP_OPEN request with all the negotiated
> configuration values
> 
> Questions:
> 
> 1. For XENSND_OP_HW_PARAM_SET I will need a hook in the frontend driver
> so I can intercept snd_pcm_hw_params_set_XXX calls - is this available
> in ALSA?

This is exactly the purpose of hw constraint rule you'd need to add.
The callback function gets called at each time the corresponding
parameter is changed (or the change is asked) by applications.

The final parameter setup is done in hw_params PCM callback, but each
fine-tuning / adjustment beforehand is done via hw constraints.

> 2. From backend side, if it runs as ALSA client, it is almost 1:1
> mapping for XENSND_OP_HW_PARAM_SET/snd_pcm_hw_params_set_XXX, so I can
> imagine
> how to do that. 

Re: [Xen-devel] [PATCH] xl/libxl: add pvcalls support

[Stefano Stabellini]

reping

On Mon, 5 Mar 2018, Stefano Stabellini wrote:
> ping?
> 
> On Tue, 27 Feb 2018, Stefano Stabellini wrote:
> > Add pvcalls support to libxl and xl. Create the appropriate pvcalls
> > entries in xenstore.
> > 
> > Signed-off-by: Stefano Stabellini 
> > 
> > diff --git a/docs/misc/xenstore-paths.markdown 
> > b/docs/misc/xenstore-paths.markdown
> > index 7be2592..77d1a36 100644
> > --- a/docs/misc/xenstore-paths.markdown
> > +++ b/docs/misc/xenstore-paths.markdown
> > @@ -299,6 +299,11 @@ A virtual scsi device frontend. Described by
> >  A virtual usb device frontend. Described by
> >  [xen/include/public/io/usbif.h][USBIF]
> >  
> > + ~/device/pvcalls/$DEVID/* []
> > +
> > +Paravirtualized POSIX function calls frontend. Described by
> > +[docs/misc/pvcalls.markdown][PVCALLS]
> > +
> >   ~/console/* []
> >  
> >  The primary PV console device. Described in [console.txt](console.txt)
> > @@ -377,6 +382,10 @@ A PV SCSI backend.
> >  
> >  A PV USB backend. Described by
> >  [xen/include/public/io/usbif.h][USBIF]
> > + 
> > + ~/backend/pvcalls/$DOMID/$DEVID/* []
> > +
> > +A PVCalls backend. Described in [docs/misc/pvcalls.markdown][PVCALLS].
> >  
> >   ~/backend/console/$DOMID/$DEVID/* []
> >  
> > diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> > index 917ceb0..035e66e 100644
> > --- a/tools/libxl/Makefile
> > +++ b/tools/libxl/Makefile
> > @@ -140,7 +140,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o 
> > libxl_dm.o libxl_pci.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_9pfs.o libxl_domain.o libxl_vdispl.o \
> > -$(LIBXL_OBJS-y)
> > +libxl_pvcalls.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 eca0ea2..76574d2 100644
> > --- a/tools/libxl/libxl.h
> > +++ b/tools/libxl/libxl.h
> > @@ -2006,6 +2006,16 @@ int libxl_device_p9_destroy(libxl_ctx *ctx, uint32_t 
> > domid,
> >  const libxl_asyncop_how *ao_how)
> >  LIBXL_EXTERNAL_CALLERS_ONLY;
> >  
> > +/* pvcalls */
> > +int libxl_device_pvcalls_remove(libxl_ctx *ctx, uint32_t domid,
> > +libxl_device_pvcalls *pvcalls,
> > +const libxl_asyncop_how *ao_how)
> > +LIBXL_EXTERNAL_CALLERS_ONLY;
> > +int libxl_device_pvcalls_destroy(libxl_ctx *ctx, uint32_t domid,
> > + libxl_device_pvcalls *pvcalls,
> > + const libxl_asyncop_how *ao_how)
> > + LIBXL_EXTERNAL_CALLERS_ONLY;
> > +
> >  /* PCI Passthrough */
> >  int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid,
> >   libxl_device_pci *pcidev,
> > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > index c498135..bbdeee5 100644
> > --- a/tools/libxl/libxl_create.c
> > +++ b/tools/libxl/libxl_create.c
> > @@ -1374,6 +1374,9 @@ static void domcreate_launch_dm(libxl__egc *egc, 
> > libxl__multidev *multidev,
> >  for (i = 0; i < d_config->num_p9s; i++)
> >  libxl__device_add(gc, domid, __p9_devtype, 
> > _config->p9s[i]);
> >  
> > +for (i = 0; i < d_config->num_pvcallss; i++)
> > +libxl__device_add(gc, domid, __pvcalls_devtype, 
> > _config->pvcallss[i]);
> > +
> >  switch (d_config->c_info.type) {
> >  case LIBXL_DOMAIN_TYPE_HVM:
> >  {
> > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> > index 506687f..e9edfac 100644
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_internal.h
> > @@ -3648,6 +3648,7 @@ extern const struct libxl_device_type 
> > libxl__usbdev_devtype;
> >  extern const struct libxl_device_type libxl__pcidev_devtype;
> >  extern const struct libxl_device_type libxl__vdispl_devtype;
> >  extern const struct libxl_device_type libxl__p9_devtype;
> > +extern const struct libxl_device_type libxl__pvcalls_devtype;
> >  
> >  extern const struct libxl_device_type *device_type_tbl[];
> >  
> > diff --git a/tools/libxl/libxl_pvcalls.c b/tools/libxl/libxl_pvcalls.c
> > new file mode 100644
> > index 000..a285343
> > --- /dev/null
> > +++ b/tools/libxl/libxl_pvcalls.c
> > @@ -0,0 +1,37 @@
> > +/*
> > + * Copyright (C) 2018  Aporeto
> > + * Author Stefano Stabellini 
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU Lesser General Public License as published
> > + * by the Free Software Foundation; version 2.1 only. with the special
> > + * exception on linking described in file LICENSE.
> > + *
> > + * This program is distributed in the 

Re: [Xen-devel] preparations for 4.9.2 and 4.7.5

[Stefano Stabellini]

On Wed, 7 Mar 2018, Jan Beulich wrote:
> >>> On 06.03.18 at 20:24,  wrote:
> > On Tue, 6 Mar 2018, Jan Beulich wrote:
> >> these stable releases should go out before the end of the month.
> >> Please point out backport candidates you find missing from the
> >> respective staging branches, but which you consider relevant.
> >> Please note that 4.7.5 is expected to be the last xenproject.org
> >> managed release from its branch.
> > 
> > I am waiting for master to pass Julien's PSCI 1.1 series, then I intend
> > to backport it to all stable trees (commits from
> > f30b93b42b7137654a69676a61620f763c4ad3b3 to
> > cd8b749282475caef095ea2f339a01d1ff9714ae).
> > 
> > Backports to older trees might be difficult.
> > 
> > Given your stable release plan, do you suggest I should start the
> > backports now, even if master has not passed yet, or wait?
> 
> There have been a lot of minor issues lately keeping pushes from
> happening on master, so if the commits above have not been
> pushed just because of such a glitch, I'd be fine with them being
> backported right away. If, however, there's any doubt, then I'd
> prefer if you waited. But in the end on the ARM side you know
> better than me what's best.
 
Master hasn't passed yet, so no backports of the ARM64 Spectre
mitigation for the moment.

In the meantime, I tagged the QEMU trees.

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

Re: [Xen-devel] [PATCH 3/3] docs: Remove redundant qemu-xen-security document

[Stefano Stabellini]

On Fri, 9 Mar 2018, George Dunlap wrote:
> All this information is now covered in SUPPORT.md.
> 
> Most of the emulated hardware is obvious a couple of the items are
> worth pointing out specifically.
> 
> "xen_disk" is listed under "Blkback"
> 
> "...the PCI host bridge and the PIIX3 chipset...": This statement is
> redundant -- the PCI host bridge is a part of the piix3 chipset, which
> is listed as supported.
> 
> xenfb: The "graphics" side of "xenfb" is listed under "PV Framebuffer
> (backend)", and the "input" side of "xenfb" (including both keyboard
> and mouse) is listed under "PV Keyboard (backend)".
> 
> Backing storage image format is listed in the "Blkback" section.
> 
> Signed-off-by: George Dunlap 

One thing: stdvga is still mispelled in SUPPORT.md.
Anything else is fine.



> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Andrew Cooper 
> CC: Jan Beulich 
> CC: Tim Deegan 
> CC: Konrad Wilk 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> CC: Anthony Perard 
> CC: Lars Kurth 
> ---
>  docs/misc/qemu-xen-security | 21 -
>  1 file changed, 21 deletions(-)
>  delete mode 100644 docs/misc/qemu-xen-security
> 
> diff --git a/docs/misc/qemu-xen-security b/docs/misc/qemu-xen-security
> deleted file mode 100644
> index 496f7eee7a..00
> --- a/docs/misc/qemu-xen-security
> +++ /dev/null
> @@ -1,21 +0,0 @@
> -qemu-xen (git://xenbits.xen.org/qemu-xen.git) is only supported for
> -security fixes when used together with the Xen hypervisor and only with
> -a subset of all the possible QEMU emulators. Specifically:
> -
> -- network: e1000, rtl8139, virtio-net
> -- storage: piix3 ide, ahci, xen_disk
> -- backing storage image format: raw, qcow, qcow2, vhd
> -- graphics: cirris-vga, stdvga and xenfb
> -- audio: sb16, es1370, ac97
> -- input: Xen PV keyboard and mouse (part of xenfb), USB and PS/2
> - keyboard and mouse
> -- serial cards: UART 16550A
> -
> -Core components, such as the PCI host bridge and the PIIX3 chipset, are
> -supported. All devices of one the above classes, which are not explicitly
> -mentioned, are not supported. For example the ne2000 network card is not
> -supported. 
> -
> -If you think that a specific emulated device should be supported, please
> -contact the QEMU UPSTREAM maintainer and the Xen Security Team
> -(secur...@xenproject.org).
> -- 
> 2.16.2
> 

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

Re: [Xen-devel] [PATCH 7/7] xen/mm: Clean up share_xen_page_with_guest() API

[Julien Grall]

Hi Andrew,

On 03/09/2018 01:18 PM, Andrew Cooper wrote:

The share_xen_page_with_guest() functions are used by common code, and are
implemented the same by each arch.  Move the declarations into the common mm.h
rather than duplicating them in each arch/mm.h

Turn an int readonly into a boolean enum, to retain ro/rw context at the
callsites, but use shorter labels which avoids a large number of split lines.

Implement share_xen_page_with_privileged_guests() as a static inline wrapper
around share_xen_page_with_guest() to avoid having a call into a separate
translation unit whose only purpose is to shuffle function arguments.

No functional change.

Signed-off-by: Andrew Cooper 


Acked-by: Julien Grall 

Cheers,


---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: George Dunlap 
CC: Tim Deegan 
CC: Wei Liu 
CC: Roger Pau Monné 
---
  xen/arch/arm/domain.c |  3 +--
  xen/arch/arm/mm.c | 13 -
  xen/arch/x86/domain.c |  3 +--
  xen/arch/x86/hvm/dom0_build.c |  2 +-
  xen/arch/x86/hvm/vmx/vmx.c|  2 +-
  xen/arch/x86/mm.c | 20 +++-
  xen/arch/x86/pv/shim.c|  6 ++
  xen/arch/x86/x86_64/mm.c  | 16 ++--
  xen/common/trace.c|  9 +++--
  xen/common/xenoprof.c |  3 +--
  xen/include/asm-arm/grant_table.h |  3 +--
  xen/include/asm-arm/mm.h  |  7 ---
  xen/include/asm-x86/grant_table.h |  6 ++
  xen/include/asm-x86/mm.h  |  8 
  xen/include/xen/mm.h  | 14 ++
  15 files changed, 44 insertions(+), 71 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 4b45fad..23dac5d 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -602,8 +602,7 @@ int arch_domain_create(struct domain *d,
  goto fail;
  
  clear_page(d->shared_info);

-share_xen_page_with_guest(
-virt_to_page(d->shared_info), d, XENSHARE_writable);
+share_xen_page_with_guest(virt_to_page(d->shared_info), d, SHARE_rw);
  
  switch ( config->config.gic_version )

  {
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index a09bea2..baa3b0d 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1187,8 +1187,8 @@ unsigned long domain_get_maximum_gpfn(struct domain *d)
  return gfn_x(d->arch.p2m.max_mapped_gfn);
  }
  
-void share_xen_page_with_guest(struct page_info *page,

-  struct domain *d, int readonly)
+void share_xen_page_with_guest(struct page_info *page, struct domain *d,
+   enum XENSHARE_flags flags)
  {
  if ( page_get_owner(page) == d )
  return;
@@ -1196,7 +1196,8 @@ void share_xen_page_with_guest(struct page_info *page,
  spin_lock(>page_alloc_lock);
  
  /* The incremented type count pins as writable or read-only. */

-page->u.inuse.type_info = (readonly ? PGT_none : PGT_writable_page) | 1;
+page->u.inuse.type_info =
+(flags == SHARE_ro ? PGT_none : PGT_writable_page) | 1;
  
  page_set_owner(page, d);

  smp_wmb(); /* install valid domain ptr before updating refcnt. */
@@ -1214,12 +1215,6 @@ void share_xen_page_with_guest(struct page_info *page,
  spin_unlock(>page_alloc_lock);
  }
  
-void share_xen_page_with_privileged_guests(

-struct page_info *page, int readonly)
-{
-share_xen_page_with_guest(page, dom_xen, readonly);
-}
-
  int xenmem_add_to_physmap_one(
  struct domain *d,
  unsigned int space,
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 12d0766..8006bed 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -528,8 +528,7 @@ int arch_domain_create(struct domain *d,
  goto fail;
  
  clear_page(d->shared_info);

-share_xen_page_with_guest(
-virt_to_page(d->shared_info), d, XENSHARE_writable);
+share_xen_page_with_guest(virt_to_page(d->shared_info), d, SHARE_rw);
  
  if ( (rc = init_domain_irq_mapping(d)) != 0 )

  goto fail;
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index afebaec..1c70416 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -297,7 +297,7 @@ static void __init pvh_steal_low_ram(struct domain *d, 
unsigned long start,
  continue;
  }
  
-share_xen_page_with_guest(pg, d, XENSHARE_writable);

+share_xen_page_with_guest(pg, d, SHARE_rw);
  rc = guest_physmap_add_entry(d, _gfn(mfn), _mfn(mfn), 0, p2m_ram_rw);
  if ( rc )
  printk("Unable to add mfn %#lx to p2m: %d\n", mfn, rc);
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 18d8ce2..ebc6934 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ 

Re: [Xen-devel] [PATCH 6/7] xen/domain: Pass the full domctl_createdomain struct to create_domain()

[Julien Grall]

Hi Andrew,

On 03/09/2018 01:18 PM, Andrew Cooper wrote:

In future patches, the structure will be extended with further information,
and this is far cleaner than adding extra parameters.

One minor tweak is that the setting of guest_type needs to be deferred until
config is known-good to dereference, but this doesn't result in any changed
behaviour as system domains never used to pass XEN_DOMCTL_CDF_hvm_guest.

Also for completeness, move the setting of d->handle into the tail of
domain_create() where it more logically should live.

Signed-off-by: Andrew Cooper 


Acked-by: Julien Grall 

Cheers,


---
CC: George Dunlap 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 
CC: Julien Grall 
---
  xen/arch/arm/domain.c| 16 
  xen/arch/arm/mm.c|  6 +++---
  xen/arch/arm/setup.c |  8 
  xen/arch/x86/domain.c| 12 ++--
  xen/arch/x86/mm.c|  6 +++---
  xen/arch/x86/setup.c | 18 +++---
  xen/common/domain.c  | 31 ---
  xen/common/domctl.c  |  8 +---
  xen/common/schedule.c|  2 +-
  xen/include/xen/domain.h |  4 ++--
  xen/include/xen/sched.h  |  5 ++---
  11 files changed, 61 insertions(+), 55 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 291c282..4b45fad 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -573,8 +573,8 @@ void vcpu_switch_to_aarch64_mode(struct vcpu *v)
  v->arch.hcr_el2 |= HCR_RW;
  }
  
-int arch_domain_create(struct domain *d, unsigned int domcr_flags,

-   struct xen_arch_domainconfig *config)
+int arch_domain_create(struct domain *d,
+   struct xen_domctl_createdomain *config)
  {
  int rc, count = 0;
  
@@ -585,7 +585,7 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags,

  if ( is_idle_domain(d) )
  return 0;
  
-if ( domcr_flags != (XEN_DOMCTL_CDF_hvm_guest | XEN_DOMCTL_CDF_hap) )

+if ( config->flags != (XEN_DOMCTL_CDF_hvm_guest | XEN_DOMCTL_CDF_hap) )
  return -EINVAL;
  
  ASSERT(config != NULL);

@@ -605,18 +605,18 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
  share_xen_page_with_guest(
  virt_to_page(d->shared_info), d, XENSHARE_writable);
  
-switch ( config->gic_version )

+switch ( config->config.gic_version )
  {
  case XEN_DOMCTL_CONFIG_GIC_NATIVE:
  switch ( gic_hw_version () )
  {
  case GIC_V2:
-config->gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
+config->config.gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
  d->arch.vgic.version = GIC_V2;
  break;
  
  case GIC_V3:

-config->gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
+config->config.gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
  d->arch.vgic.version = GIC_V3;
  break;
  
@@ -644,10 +644,10 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags,

  if ( (rc = domain_io_init(d, count + MAX_IO_HANDLER)) != 0 )
  goto fail;
  
-if ( (rc = domain_vgic_init(d, config->nr_spis)) != 0 )

+if ( (rc = domain_vgic_init(d, config->config.nr_spis)) != 0 )
  goto fail;
  
-if ( (rc = domain_vtimer_init(d, config)) != 0 )

+if ( (rc = domain_vtimer_init(d, >config)) != 0 )
  goto fail;
  
  update_domain_wallclock_time(d);

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index ce83f69..a09bea2 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -520,7 +520,7 @@ void __init arch_init_memory(void)
   * Any Xen-heap pages that we will allow to be mapped will have
   * their domain field set to dom_xen.
   */
-dom_xen = domain_create(DOMID_XEN, 0, 0, NULL);
+dom_xen = domain_create(DOMID_XEN, NULL);
  BUG_ON(IS_ERR(dom_xen));
  
  /*

@@ -528,14 +528,14 @@ void __init arch_init_memory(void)
   * This domain owns I/O pages that are within the range of the page_info
   * array. Mappings occur at the priv of the caller.
   */
-dom_io = domain_create(DOMID_IO, 0, 0, NULL);
+dom_io = domain_create(DOMID_IO, NULL);
  BUG_ON(IS_ERR(dom_io));
  
  /*

   * Initialise our COW domain.
   * This domain owns sharable pages.
   */
-dom_cow = domain_create(DOMID_COW, 0, 0, NULL);
+dom_cow = domain_create(DOMID_COW, NULL);
  BUG_ON(IS_ERR(dom_cow));
  }
  
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c

index 4627366..b17797d 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -693,7 +693,7 @@ void __init start_xen(unsigned long boot_phys_offset,
  const char *cmdline;
  

Re: [Xen-devel] [PATCH 1/7] xen/domain: Drop DOMCRF_dummy

[Julien Grall]

Hi Andrew,

On 03/09/2018 01:18 PM, Andrew Cooper wrote:

At the moment, there is a tight coupling between the domid and the use of
DOMCRF_dummy.  Instead of using DOMCRF_dummy, base the one relevent decision


NIT: s/relevent/relevant/


on domid alone.

Signed-off-by: Andrew Cooper 


Acked-by: Julien Grall 

Cheers,


---
CC: George Dunlap 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 
CC: Julien Grall 
---
  xen/arch/arm/mm.c   |  6 +++---
  xen/arch/x86/mm.c   |  6 +++---
  xen/common/domain.c |  3 ++-
  xen/include/xen/sched.h | 11 +++
  4 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 3c328e2..ce83f69 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -520,7 +520,7 @@ void __init arch_init_memory(void)
   * Any Xen-heap pages that we will allow to be mapped will have
   * their domain field set to dom_xen.
   */
-dom_xen = domain_create(DOMID_XEN, DOMCRF_dummy, 0, NULL);
+dom_xen = domain_create(DOMID_XEN, 0, 0, NULL);
  BUG_ON(IS_ERR(dom_xen));
  
  /*

@@ -528,14 +528,14 @@ void __init arch_init_memory(void)
   * This domain owns I/O pages that are within the range of the page_info
   * array. Mappings occur at the priv of the caller.
   */
-dom_io = domain_create(DOMID_IO, DOMCRF_dummy, 0, NULL);
+dom_io = domain_create(DOMID_IO, 0, 0, NULL);
  BUG_ON(IS_ERR(dom_io));
  
  /*

   * Initialise our COW domain.
   * This domain owns sharable pages.
   */
-dom_cow = domain_create(DOMID_COW, DOMCRF_dummy, 0, NULL);
+dom_cow = domain_create(DOMID_COW, 0, 0, NULL);
  BUG_ON(IS_ERR(dom_cow));
  }
  
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c

index 9b55944..c275d4b 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -271,7 +271,7 @@ void __init arch_init_memory(void)
   * Hidden PCI devices will also be associated with this domain
   * (but be [partly] controlled by Dom0 nevertheless).
   */
-dom_xen = domain_create(DOMID_XEN, DOMCRF_dummy, 0, NULL);
+dom_xen = domain_create(DOMID_XEN, 0, 0, NULL);
  BUG_ON(IS_ERR(dom_xen));
  INIT_LIST_HEAD(_xen->arch.pdev_list);
  
@@ -280,14 +280,14 @@ void __init arch_init_memory(void)

   * This domain owns I/O pages that are within the range of the page_info
   * array. Mappings occur at the priv of the caller.
   */
-dom_io = domain_create(DOMID_IO, DOMCRF_dummy, 0, NULL);
+dom_io = domain_create(DOMID_IO, 0, 0, NULL);
  BUG_ON(IS_ERR(dom_io));
  
  /*

   * Initialise our COW domain.
   * This domain owns sharable pages.
   */
-dom_cow = domain_create(DOMID_COW, DOMCRF_dummy, 0, NULL);
+dom_cow = domain_create(DOMID_COW, 0, 0, NULL);
  BUG_ON(IS_ERR(dom_cow));
  
  /*

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 219a3e3..cd39a58 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -312,7 +312,8 @@ struct domain *domain_create(domid_t domid, unsigned int 
domcr_flags,
  rangeset_domain_initialise(d);
  init_status |= INIT_rangeset;
  
-if ( domcr_flags & DOMCRF_dummy )

+/* DOMID_{XEN,IO,etc} (other than IDLE) are sufficiently constructed. */
+if ( is_system_domain(d) && !is_idle_domain(d) )
  return d;
  
  if ( !is_idle_domain(d) )

diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 39f9386..aa5729b 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -491,9 +491,15 @@ extern spinlock_t domlist_update_lock;
  extern rcu_read_lock_t domlist_read_lock;
  
  extern struct vcpu *idle_vcpu[NR_CPUS];

+
  #define is_idle_domain(d) ((d)->domain_id == DOMID_IDLE)
  #define is_idle_vcpu(v)   (is_idle_domain((v)->domain))
  
+static inline bool is_system_domain(const struct domain *d)

+{
+return d->domain_id >= DOMID_FIRST_RESERVED;
+}
+
  #define DOMAIN_DESTROYED (1u << 31) /* assumes atomic_t is >= 32 bits */
  #define put_domain(_d) \
if ( atomic_dec_and_test(&(_d)->refcnt) ) domain_destroy(_d)
@@ -531,7 +537,7 @@ void domain_update_node_affinity(struct domain *d);
  
  /*

   * Create a domain: the configuration is only necessary for real domain
- * (i.e !DOMCRF_dummy, excluded idle domain).
+ * (domid < DOMID_FIRST_RESERVED).
   */
  struct domain *domain_create(domid_t domid, unsigned int domcr_flags,
   uint32_t ssidref,
@@ -546,9 +552,6 @@ struct domain *domain_create(domid_t domid, unsigned int 
domcr_flags,
  by tboot */
  #define _DOMCRF_s3_integrity  2
  #define DOMCRF_s3_integrity   (1U<<_DOMCRF_s3_integrity)
- /* DOMCRF_dummy: Create a dummy domain (not scheduled; not on domain list) */
-#define 

Re: [Xen-devel] [PATCH 2/7] xen/domain: Drop all DOMCRF_* constants

[Julien Grall]

Hi Andre,

On 03/09/2018 01:18 PM, Andrew Cooper wrote:

With DOMCRF_dummy removed, all remaining DOMCRF_* idenitcally match their


NIT: s/idenitcally/identically/


DOMCTL counterparts.  Avoid having a conversion between two different bit
layouts, and use the DOMCTL_CDF_* constants everywhere.

Signed-off-by: Andrew Cooper 


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 3/7] RFC arm/domain: Reject invalid combinations of domain creation flags

[Julien Grall]

Hi Andrew,

On 03/09/2018 01:18 PM, Andrew Cooper wrote:

ARM guests are HVM and have hardware assisted paging.  There are no PV guests
or shadow paging, and all other creation flags are x86 specific.

Signed-off-by: Andrew Cooper 
---
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Ian Jackson 
CC: Wei Liu 

RFC.  This is untested, but I noticed it when putting together the preceeding
patch.  There is a moderate chance that this will cause things to explode
because of how libxl handles ARM guest construction, but something along these
lines is the right thing to do.


Tools and hypervisor are considering ARM guests as PV. So this patch is 
going to break boot. There are an action (XEN-102) to move ARM guests to 
behave more like PVH from the tools POV. I am not sure when I will have 
time to look at it thought.


For the time being, I am wondering if we could override the flags for 
Arm in the toolstack?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 12/16] xen/mm: Switch common/memory.c to use typesafe MFN

[Julien Grall]

Hi,

On 03/09/2018 05:33 PM, Wei Liu wrote:

On Mon, Mar 05, 2018 at 07:41:54AM -0700, Jan Beulich wrote:

On 05.03.18 at 15:18,  wrote:

On 02/03/18 15:34, Jan Beulich wrote:

On 21.02.18 at 15:02,  wrote:

@@ -95,11 +101,18 @@ static unsigned int max_order(const struct domain *d)
   return min(order, MAX_ORDER + 0U);
   }
   
+/* Helper to copy a typesafe MFN to guest */

+#define copy_mfn_to_guest(hnd, off, mfn)\
+({  \
+xen_pfn_t mfn_ = mfn_x(mfn);\
+__copy_to_guest_offset(hnd, off, _, 1); \
+})


Hmm, not really nice, but what do you do.


I am open to better suggestion. I wanted to avoid the conversion all
over the code.


I have no better suggestion, I'm sorry, hence the "but what do
you do."


Also, do you have an opinion on Wei's suggestion:

"What I meant was to make copy_{to,from}_guest* type-safe. I just feel it
a bit strange you only created a wrapper for this file. I wonder why.

Note I'm just asking question. That's not necessarily a good idea to
turn them all in the end."


Well, I didn't really understand what he's after (in the context of
this series) - copy_{to,from}_guest() don't take or return MFNs or
GFNs.



Fundamentally Julien's patch is to wrap around an existing API for this
one file only. Why is this file special? Why not just make that class of
APIs do what he wants?

But that is going to be intrusive and a bit counter-intuitive.


I have quickly looked at it. The major problem I can see is it is not 
possible to generically define for any typesafe. Indeed, TYPE_SAFE(...) 
cannot define new macro and, AFAICT, it is not feasible to define static 
inline for copy_* helpers.


So we would need to introduce macros for each typesafe by hand. I can 
move copy_mfn_to_guest in xen/mm.h if people think it could be useful.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 08/16] xen/mm: Drop the parameter mfn from populate_pt_range

[Julien Grall]

Hi Wei,

On 03/09/2018 05:29 PM, Wei Liu wrote:

On Mon, Mar 05, 2018 at 07:38:36AM -0700, Jan Beulich wrote:

On 05.03.18 at 15:11,  wrote:

On 05/03/18 14:00, Jan Beulich wrote:

On 05.03.18 at 14:43,  wrote:

Anyway, I don't have much knowledge on the x86 to make the modification
that you suggested. So I am going to revert to _mfn(0) for x86.


I'd prefer if you didn't, but well, it'll be one of us to clean it up
then.

I can keep as INVALID_MFN. But then either you or Andrew (or anyone x86
folks) would have to provide the patch to skip incrementing invalid MFN
(if I understood correctly your request).


Sigh - this should go together imo. While wrongly incrementing from
zero was bad, wrongly wrapping from INVALID_MFN makes things
worse.



Try this patch?


I am happy to carry this patch at the beginning of my series if you want.



---8<---
 From 8f0024c690c736d17adde0fa765cbbf6fa2846dc Mon Sep 17 00:00:00 2001
From: Wei Liu 
Date: Fri, 9 Mar 2018 17:20:14 +
Subject: [PATCH] x86/mm: skip incrementing mfn if it is not a valid mfn

The function is called to fill in page table entries in
populate_pt_range. Skip incrementing mfn if it is invalid.

Signed-off-by: Wei Liu 
---
  xen/arch/x86/mm.c | 15 ++-
  1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 9b559448a7..5f5577c7c2 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4731,7 +4731,8 @@ int map_pages_to_xen(
  }
  
  virt+= 1UL << L3_PAGETABLE_SHIFT;

-mfn += 1UL << (L3_PAGETABLE_SHIFT - PAGE_SHIFT);
+if ( !mfn_eq(_mfn(mfn), INVALID_MFN) )
+mfn += 1UL << (L3_PAGETABLE_SHIFT - PAGE_SHIFT);
  nr_mfns -= 1UL << (L3_PAGETABLE_SHIFT - PAGE_SHIFT);
  continue;
  }
@@ -4756,7 +4757,8 @@ int map_pages_to_xen(
  if ( i > nr_mfns )
  i = nr_mfns;
  virt+= i << PAGE_SHIFT;
-mfn += i;
+if ( !mfn_eq(_mfn(mfn), INVALID_MFN) )
+mfn += i;
  nr_mfns -= i;
  continue;
  }
@@ -4824,7 +4826,8 @@ int map_pages_to_xen(
  }
  
  virt+= 1UL << L2_PAGETABLE_SHIFT;

-mfn += 1UL << PAGETABLE_ORDER;
+if ( !mfn_eq(_mfn(mfn), INVALID_MFN) )
+mfn += 1UL << PAGETABLE_ORDER;
  nr_mfns -= 1UL << PAGETABLE_ORDER;
  }
  else
@@ -4853,7 +4856,8 @@ int map_pages_to_xen(
  if ( i > nr_mfns )
  i = nr_mfns;
  virt+= i << L1_PAGETABLE_SHIFT;
-mfn += i;
+if ( !mfn_eq(_mfn(mfn), INVALID_MFN) )
+mfn += i;
  nr_mfns -= i;
  goto check_l3;
  }
@@ -4898,7 +4902,8 @@ int map_pages_to_xen(
  }
  
  virt+= 1UL << L1_PAGETABLE_SHIFT;

-mfn += 1UL;
+if ( !mfn_eq(_mfn(mfn), INVALID_MFN) )
+mfn += 1UL;
  nr_mfns -= 1UL;
  
  if ( (flags == PAGE_HYPERVISOR) &&




Cheers,

--
Julien Grall

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

Re: [Xen-devel] update_runstate_area and Linux KPTI

[Julien Grall]

Hi Juergen,

On 03/02/2018 05:25 PM, Juergen Gross wrote:

On 02/03/18 18:09, Andrew Cooper wrote:

On 02/03/18 17:05, Juergen Gross wrote:

On 02/03/18 17:51, Jan Beulich wrote:

On 02.03.18 at 17:25,  wrote:

On 02/03/18 16:18, Jan Beulich wrote:

On 02.03.18 at 17:04,  wrote:

The proper way to do this is indeed by a nominated (guest) physical
address, at which point Xen can make all/any updates at times of its
choosing, and the guests pagetable/permissions state at an instantaneous
moment don't matter.

If you've got time to do this, then please do.  It will be a definite
improvement.

Just to be avoid unnecessary effort in the wrong direction: I don't
think you can alter the current interface. You'd have to add a new
one, and we could then deprecate (but never abandon) the current
one.

I was only planning to store the guest physical address rather than the
virtual address as we do today. Is that considered as an alteration of
the current interface?

Yes, it is, as an existing PV kernel could deliberately alter the
mappings underlying the linear address it has handed us.

Linux pvops kernel isn't doing this. Mini-OS neither. I guess kernel-xen
would be okay with this, too. And I bet BSD is also fine.

Seriously: any kernel playing such tricks is asking for problems.

We shouldn't support operation modes which make no sense just for the
sake of compatibility, IMO.


I'd love to do this, but we cant.  Older Linux used to have a virtual
buffer spanning a page boundary.  Changing the behaviour under that will
cause older setups to explode.


Adding a special per-domain mapping for that purpose would work.


I am not sure to understand your suggestion here. Would you mind giving 
a bit more details?


If the buffer is spanning a page boundary (it seems to be the case on 
current Linux), you would need to map 2 pages using vmap in Xen 
per-VCPU. Would that be acceptable?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH] xen/arm: Add MVEBU UART driver for Armada 3700 SoC

[Julien Grall]

Hi,

On 03/10/2018 04:44 PM, Amit Singh Tomar wrote:

This patch adds driver for UART controller found on Armada 3700 SoC.


OOI, do you have any plan for adding earlyprintk support for that platform?



There is no reference manuals available for 3700 SoC in public and this
driver is derived by looking at Linux driver.


Please give a link to the Linux driver. This would help me for reviewing 
and also for future reference.


For now, see below for some generic comments regarding the code.



Signed-off-by: Amit Singh Tomar 
---
  xen/drivers/char/Kconfig  |   8 ++
  xen/drivers/char/Makefile |   1 +
  xen/drivers/char/mvebu-uart.c | 315 ++


This is part of xen/drivers/char/* so even if the driver if only for ARM 
hardware, you likely want to CC "THE REST" maintainers as this is under 
drivers/char. scripts/get_maintainers.pl can help you to find relevant 
maintainers to CC on each patch.


Regarding the maintenance after it is merged, I think it should fold 
under "ARM" as for all the other arch specific UART driver (PL011 & co).



  3 files changed, 324 insertions(+)
  create mode 100644 xen/drivers/char/mvebu-uart.c

diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index fb53dd8..690eda6 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -12,6 +12,14 @@ config HAS_CADENCE_UART
  This selects the Xilinx Zynq Cadence UART. If you have a Xilinx Zynq
  based board, say Y.
  
+config HAS_MVEBU

+bool
+default y
+depends on ARM_64
+help
+  This selects the Marvell MVEBU UART. if you have an ARMADA 3700
+  based board, say Y.
+
  config HAS_PL011
bool
default y
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index 0d48b16..b68c330 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_HAS_NS16550) += ns16550.o
  obj-$(CONFIG_HAS_CADENCE_UART) += cadence-uart.o
  obj-$(CONFIG_HAS_PL011) += pl011.o
  obj-$(CONFIG_HAS_EXYNOS4210) += exynos4210-uart.o
+obj-$(CONFIG_HAS_MVEBU) += mvebu-uart.o
  obj-$(CONFIG_HAS_OMAP) += omap-uart.o
  obj-$(CONFIG_HAS_SCIF) += scif-uart.o
  obj-$(CONFIG_HAS_EHCI) += ehci-dbgp.o
diff --git a/xen/drivers/char/mvebu-uart.c b/xen/drivers/char/mvebu-uart.c
new file mode 100644
index 000..fdcc153
--- /dev/null
+++ b/xen/drivers/char/mvebu-uart.c
@@ -0,0 +1,315 @@
+/*
+ * xen/drivers/char/mvebu3700-uart.c
+ *
+ * Driver for Marvell MVEBU UART.
+ *
+ * Amit Singh Tomar


NIT: space before <.


+ * Copyright (c) 2018.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 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 General Public License for more details.
+ */
+
+#include 
+#include 


 include should be first, then .


+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 


xen/serial.h is mentioned twice.


+#include 
+
+#define UART_RX_REG 0x00
+#define RBR_BRK_DET BIT(15)
+#define RBR_FRM_ERR_DET BIT(14)
+#define RBR_PAR_ERR_DET BIT(13)
+#define RBR_OVR_ERR_DET BIT(12)
+
+#define UART_TX_REG 0x04
+
+#define UART_CTRL_REG   0x08
+#define CTRL_SOFT_RST   BIT(31)
+#define CTRL_TXFIFO_RST BIT(15)
+#define CTRL_RXFIFO_RST BIT(14)
+#define CTRL_ST_MIRR_EN BIT(13)
+#define CTRL_LPBK_ENBIT(12)
+#define CTRL_SND_BRK_SEQBIT(11)
+#define CTRL_PAR_EN BIT(10)
+#define CTRL_TWO_STOP   BIT(9)
+#define CTRL_TX_HFL_INT BIT(8)
+#define CTRL_RX_HFL_INT BIT(7)
+#define CTRL_TX_EMP_INT BIT(6)
+#define CTRL_TX_RDY_INT BIT(5)
+#define CTRL_RX_RDY_INT BIT(4)
+#define CTRL_BRK_DET_INTBIT(3)
+#define CTRL_FRM_ERR_INTBIT(2)
+#define CTRL_PAR_ERR_INTBIT(1)
+#define CTRL_OVR_ERR_INTBIT(0)
+#define CTRL_RX_INT (CTRL_BRK_DET_INT | CTRL_FRM_ERR_INT | \
+ CTRL_PAR_ERR_INT | CTRL_OVR_ERR_INT)
+
+#define UART_STATUS_REG 0x0c
+#define STATUS_TXFIFO_EMP   BIT(13)
+#define STATUS_RXFIFO_EMP   BIT(12)
+#define STATUS_TXFIFO_FUL   BIT(11)
+#define STATUS_TXFIFO_HFL   BIT(10)
+#define STATUS_RX_TOGL  BIT(9)
+#define STATUS_RXFIFO_FUL   BIT(8)
+#define STATUS_RXFIFO_HFL   BIT(7)
+#define STATUS_TX_EMP   BIT(6)
+#define STATUS_TX_RDY   BIT(5)
+#define STATUS_RX_RDY   BIT(4)
+#define STATUS_BRK_DET  BIT(3)
+#define STATUS_FRM_ERR  

Re: [Xen-devel] [RFC PATCH] xen/arm64: Add Support for Marvell ARMADA 3700 SoC

[Julien Grall]

Hi Amit,

On 03/10/2018 04:44 PM, Amit Singh Tomar wrote:

This patch-set is an attempt to enable XEN on ESPRESSObin[1] based on
Marvell's ARMADA 3700 SoC


Thank you for adding support to boot Xen on that board!

Would you mind creating a page on Xen wiki to explain how to boot Xen on 
that board? See [1].


Furthermore, we are always looking for user to test Xen RC on supported 
hardware. Would you be willing to step up for that board? If so, can you 
add your name on [2]?


Cheers,

[1] 
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions#Hardware


[2] https://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test/Results

--
Julien Grall

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 120326

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 120326
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 120326
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 120326
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass

version targeted for testing:
 libvirt  b9b9195f15c94ec0e1d26d0def7387b32126f09b
baseline version:
 libvirt  b932ed69f6664f42e211bdde84c8ab04e1f19033

Last test of basis   120326  2018-03-08 01:25:03 Z3 days
Testing same since   120378  2018-03-09 21:20:32 Z1 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Christian Ehrhardt 
  Daniel P. Berrangé 
  Jamie Strandboge 
  John Ferlan 
  Ján Tomko 
  Peter Krempa 

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  fail
 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 

Re: [Xen-devel] [PATCH 1/3] SUPPORT.md: Clarify that the PV keyboard protocol includes mouse support

[Paul Durrant]

> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: 09 March 2018 18:04
> To: xen-devel@lists.xenproject.org
> Cc: George Dunlap ; Ian Jackson
> ; Wei Liu ; Andrew Cooper
> ; Jan Beulich ; Tim
> (Xen.org) ; Konrad Wilk ; Stefano
> Stabellini ; Julien Grall ;
> Anthony Perard ; Paul Durrant
> ; Lars Kurth 
> Subject: [PATCH 1/3] SUPPORT.md: Clarify that the PV keyboard protocol
> includes mouse support
> 
> s/fo/fo; while we're here.
> 
> Signed-off-by: George Dunlap 

Reviewed-by: Paul Durrant 

> ---
> This is a candidate for backport to 4.10.
> 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Andrew Cooper 
> CC: Jan Beulich 
> CC: Tim Deegan 
> CC: Konrad Wilk 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> CC: Anthony Perard 
> CC: Paul Durrant 
> CC: Lars Kurth 
> ---
>  SUPPORT.md | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/SUPPORT.md b/SUPPORT.md
> index a1810b8046..87d07129b4 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -380,7 +380,8 @@ Guest-side driver capable of speaking the Xen PV
> console protocol
> 
>  Status, Linux (xen-kbdfront): Supported
> 
> -Guest-side driver capable of speaking the Xen PV keyboard protocol
> +Guest-side driver capable of speaking the Xen PV keyboard protocol.
> +Note that the "keyboard protocol" includes mouse / pointer support as
> well.
> 
>  ### PV USB (frontend)
> 
> @@ -451,7 +452,8 @@ Host-side implementation of the Xen PV console
> protocol
> 
>  Status, QEMU: Supported
> 
> -Host-side implementation fo the Xen PV keyboard protocol
> +Host-side implementation of the Xen PV keyboard protocol.
> +Note that the "keyboard protocol" includes mouse / pointer support as
> well.
> 
>  ### PV USB (backend)
> 
> --
> 2.16.2


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

[Xen-devel] [qemu-mainline test] 120376: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1   fail REGR. vs. 120095
 test-amd64-amd64-qemuu-nested-amd 14 xen-boot/l1 fail REGR. vs. 120095

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 120095
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 120095
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 120095
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 120095
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 120095
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 120095
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuue4ae62b802cec437f877f2cadc4ef059cc0eca76
baseline version:
 qemuu6697439794f72b3501ee16bb95d16854f9981421

Last test of basis   120095  2018-02-28 13:46:33 Z   10 days
Failing since120146  2018-03-02 10:10:57 Z9 days5 attempts
Testing same since   120376  2018-03-09 18:52:43 Z1 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alex Bennée 
  Alexey Kardashevskiy 
  Alistair Francis 
  Alistair Francis 
  Anton Nefedov 
  BALATON Zoltan 
  Bastian Koppelmann 
  Christian Borntraeger 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvops 6 kernel-build fail REGR. vs. 118294
 build-i386-pvops  6 kernel-build fail REGR. vs. 118294

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-examine   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118294
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118294
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118294
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118294
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 

[Xen-devel] [rumprun test] 120388: regressions - FAIL

[osstest service owner]

flight 120388 rumprun real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120388/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumprun6 rumprun-buildfail REGR. vs. 106754
 build-amd64-rumprun   6 rumprun-buildfail REGR. vs. 106754

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a

version targeted for testing:
 rumprun  94bdf32ac57b84c1b42150d21f0ad79b3b5dd99c
baseline version:
 rumprun  c7f2f016becc1cd0e85da6e1b25a8e7f9fb2aa74

Last test of basis   106754  2017-03-18 04:21:25 Z  358 days
Testing same since   120360  2018-03-09 04:19:20 Z2 days2 attempts


People who touched revisions under test:
  Kent McLeod 
  Kent McLeod 
  Naja Melan 
  Sebastian Wicki 
  Wei Liu 

jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  fail
 build-i386-rumprun   fail
 test-amd64-amd64-rumprun-amd64   blocked 
 test-amd64-i386-rumprun-i386 blocked 



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

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

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

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


Not pushing.


commit 94bdf32ac57b84c1b42150d21f0ad79b3b5dd99c
Merge: 8fe40c8 b3c1033
Author: Kent McLeod 
Date:   Fri Feb 16 09:15:45 2018 +1100

Merge pull request #118 from kent-mcleod/stretch-linking-defaultpie

Fix linking on Debian Stretch (gcc-6)

commit b3c1033b090b65e8e86999ddd063c174502aa3f0
Author: Kent McLeod 
Date:   Wed Feb 14 16:43:16 2018 +1100

Add further -no-pie checks to Rumprun build tools

This builds upon the previous commit to add -no-pie anywhere the
relocatable flag (-Wl,-r) is used to handle compilers that enable -pie
by default (Such as Debian Stretch).

commit 8fe40c84edddfbf472b4a7cce960df749701174c
Merge: c7f2f01 685f4ab
Author: Sebastian Wicki 
Date:   Fri Jan 5 15:04:18 2018 +0100

Merge pull request #112 from najamelan/bugfix/gcc7-fallthrough

Add the -Wimplicit-fallthrough=0 flag to allow compiling with GCC7

commit 685f4ab3b74b6f1e1b40bdd3d2c42efa44bf385d
Author: Naja Melan 
Date:   Thu Jan 4 16:07:46 2018 +

Make the disabling of the fallthrough warning dependent on GCC version

This should prevent older gcc versions from choking on unknown argument.

I have not tested this, just wrote the code directly on github. Use with 
caution.

commit 34056451174e8722b972229fefc1bf9e0b89a7da
Author: Naja Melan 
Date:   Wed Jan 3 18:57:50 2018 +

Add the -Wimplicit-fallthrough=0 flag to allow compiling with GCC7

GCC7 comes with a new warning "implicit-fallthrough" which will prevent 
building the netbsd-src.

For more information: 
https://dzone.com/articles/implicit-fallthrough-in-gcc-7

commit 35d81194b7feb75d20af3ba4fdb45ea76230852f
Author: Wei Liu 
Date:   Wed Jun 7 16:30:00 2017 +0100

Fix linking on Debian Stretch

Provide cc-option. Use that to check if -no-pie is available and
append it when necessary.

Signed-off-by: Wei Liu 

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