Re: [Xen-devel] [PATCH v10] VT-d: use correct BDF for VF to search VT-d unit

[Tian, Kevin]

> From: Gao, Chao
> Sent: Monday, August 28, 2017 10:42 AM
> 
> When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function'
> are under the scope of the same VT-d unit as the 'Physical Function'.
> A 'Physical Function' can be a 'Traditional Function' or an ARI
> 'Extended Function'. And furthermore, 'Extended Functions' on an
> endpoint are under the scope of the same VT-d unit as the 'Traditional
> Functions' on the endpoint. To search VT-d unit for a VF, if its PF
> isn't an extended function, the BDF of PF should be used. Otherwise
> the BDF of a traditional function in the same device with the PF
> should be used.
> 
> Current code uses PCI_SLOT() to recognize an ARI 'Extended Funcion'.
> But it is conceptually wrong w/o checking whether PF is an extended
> function and would lead to match VFs of a RC integrated PF to a wrong
> VT-d unit.
> 
> This patch overrides VF 'is_extfn' field and uses this field to
> indicate whether the PF of this VF is an extended function. The field
> helps to use correct BDF to search VT-d unit.
> 
> Reported-by: Crawford, Eric R 
> Signed-off-by: Chao Gao 

Reviewed-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH RESEND v9] VT-d: use correct BDF for VF to search VT-d unit

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, August 25, 2017 11:20 PM
> 
> 
> >  Currently, VF won't implement SRIOV feature, seeing
> > SRIOV specv1.1 chapter 3.7 PCI Express Extended Capabilities. Even VF
> > will implement SRIOV later, I think as long as a function is SRIOV
> > capable, we can initialize vf_rlen[] here.
> 
> How could a VF itself implement SR-IOV?
> 

PCI SRIOV doesn't support such capability, i.e. no nested hardware
i/o virtualization

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

Re: [Xen-devel] [PATCH v8 00/13] Unify the interrupt delivery mode and do its setup in advance

[Dou Liyang]

Hi,

Follow Juergen's advice, +CC xen-devel and linux-acpi

In case a single patch of a series isn't stand alone it would be nice
to receive at least the cover letter of the series in order to know
what its all about.

Thanks,
dou.

At 08/28/2017 11:20 AM, Dou Liyang wrote:

Changes V7 --> V8:

  - Change the order of [12/13] patch and [11/13]patch suggested by Rafael J. 
Wysocki.
  - Fix some comments.
  - Do more tests in Thinkpad x121e   -- Thanks for Borislav Petkov's help.

[Background]

MP specification defines three different interrupt delivery modes as follows:

 1. PIC Mode
 2. Virtual Wire Mode
 3. Symmetric I/O Mode

They will be setup in the different periods of booting time:
 1. *PIC Mode*, the default interrupt delivery modes, will be set first.
 2. *Virtual Wire Mode* will be setup during ISA IRQ initialization( step 1
in the figure.1).
 3. *Symmetric I/O Mode*'s setup is related to the system
3.1 In SMP-capable system, setup during prepares CPUs(step 2)
3.2 In UP system, setup during initializes itself(step 3).


 start_kernel
+---+
|
+--> ...
|
|setup_arch
+--> +---+
|
|init_IRQ
+-> +--+-+
|  |init_ISA_irqs
|  +--> +-++
| | ++
+---> +-->  | 1.init_bsp_APIC|
| ...   ++
+--->
| rest_init
+--->---+-+
|   |   kernel_init
|   +> +-+
|  |   kernel_init_freeable
|  +->  +-+
|   | smp_prepare_cpus
|   +---> ++-+
|   |  |   +---+
|   |  +-> |2.  apic_bsp_setup |
|   |  +---+
|   |
v   | smp_init
+---> +---++
  |+---+
  +--> |3.  apic_bsp_setup |
   +---+
figure.1 The flow chart of the kernel startup process

[Problem]

1. Cause kernel in an unmatched mode at the beginning of booting time.
2. Cause the dump-capture kernel hangs with 'notsc' option inherited
   from 1st kernel option.
3. Cause the code hard to read and maintain.

As Ingo's and Eric's discusses[1,2], it need to be refactor.

[Solution]

1. Construct a selector to unify these switches

   ++
   |disable_apic++
   ++   true |
  |false |
  |  |
 +v--+   |
 |!boot_cpu_has(X86_FEATURE_APIC)+---+
 +---+  true |
  |false |
  |  |
  +---v-+v
  |!smp_found_config|PIC MODE
  +---+-+
   |false |true
   |  |
   v  +---v-+
SYMMETRIC IO MODE | !acpi_lapic |
  +--+--+
 |
 v
   VIRTUAL WIRE MODE

2. Unifying these setup steps of SMP-capable and UP system

   start_kernel
---+
|
|
|
|x86_late_time_init
+>---++
||
||  ++
|+> | 4. init_interrupt_mode |
|   ++
v


3. Execute the function as soon as possible.

[Test]

1. In a theoretical code analysis, the patchset can wrap the original
logic.

1) The original logic of the interrupt delivery mode setup：

-Step O_1) Keep in PIC mode or virtual wire mode:

  Check (smp_found_config || !boot_cpu_has(X86_FEATURE_APIC))
true:  PIC mode
false: virtual wire mode

-Step O_2) Try to switch to symmetric IO mode:
  O_2_1) In up system:

-Check disable_apic
  ture: O_S_1 (original situation 1)
-Check whether there is a separate or integrated chip
  don't has: O_S_2
-Check !smp_found_config
  ture: O_S_3
-Others:
  O_S_4

  O_2_2) In smp-capable system:

-Check !smp_found_config && !acpi_lapic
  true: goto O_2_1
-Check if it is LAPIC
  don't has: O_S_5
-Check !max_cpus
  true: O_S_6
-read_apic_id() != boot_cpu_physical_apicid
  true: O_S_7
-Others:
O_S_8

2) After that patchset, the new logic:

-Step N_1) Skip step O_1 and try to switch to the final interrupt mode
   -Check disable_apic
 ture: N_S_1 (New situation 1)
   -Check whether there is a separate or integrated chip
 ture: N_S_2
   -Check if (!smp_found_config)
 ture: N_S_3
   -Check !setup_max_cpus
 ture: N_S_4
   -Check read_apic_id() != boot_cpu_physical_apicid
 ture: N_S_5
   -Others:
   N_S_6

O_S_1 is covered in N_S_1
O_S_2 is covered in N_S_2

[Xen-devel] linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got conflicts in:

  arch/x86/xen/xen-asm.S
  arch/x86/xen/xen-asm_64.S

between commit:

  edcb5cf84f05 ("x86/paravirt/xen: Remove xen_patch()")

from the tip tree and commits:

  ad5b8c4ba323("xen: get rid of paravirt op adjust_exception_frame")
  bd830917233b ("paravirt,xen: remove xen_patch()")

from the xen-tip tree.

I fixed it up (edcb5cf84f05 and bd830917233b ate more or less the same
patch, so I just used the latter version files) and can carry the fix
as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

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

Re: [Xen-devel] [PATCH v8 10/13] x86/xen: Bypass intr mode setup in enlighten_pv system

[Dou Liyang]

Hi Juergen,

At 08/28/2017 12:32 PM, Juergen Gross wrote:

On 28/08/17 06:25, Juergen Gross wrote:

On 28/08/17 05:20, Dou Liyang wrote:

XEN PV overrides smp_prepare_cpus(). xen_pv_smp_prepare_cpus()
initializes interrupts in the XEN PV specific way and does not invoke
native_smp_prepare_cpus(). As a consequence, x86_init.intr_mode_init() is
not invoked either.

The invocation of x86_init.intr_mode_init() will be moved from
native_smp_prepare_cpus() in a follow up patch to solve .


Can you be a little bit more precise here, please? :-)


That move would cause the invocation of x86_init.intr_mode_init() for XEN
PV platforms. To prevent that, override the default x86_init.
intr_mode_init() callback with a noop().

[Rewrited by Thomas Gleixner ]

Signed-off-by: Dou Liyang 
Cc: xen-de...@lists.xenproject.org
Cc: boris.ostrov...@oracle.com


On which tree does this apply? Would be nice to get a hint against which
source this can be reviewed.


Aah, just found the rest of the series. In case a single patch of a
series isn't stand alone it would be nice to receive at least the cover
letter of the series in order to know what its all about.


Sorry to confuse you, It's my fault.

Thank you for your reply. I understood. will CC the cover letter to
linux-xen and linux-acpi.

Thanks,
dou.



Juergen







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

Re: [Xen-devel] [PATCH v8 10/13] x86/xen: Bypass intr mode setup in enlighten_pv system

[Juergen Gross]

On 28/08/17 06:25, Juergen Gross wrote:
> On 28/08/17 05:20, Dou Liyang wrote:
>> XEN PV overrides smp_prepare_cpus(). xen_pv_smp_prepare_cpus()
>> initializes interrupts in the XEN PV specific way and does not invoke
>> native_smp_prepare_cpus(). As a consequence, x86_init.intr_mode_init() is
>> not invoked either.
>>
>> The invocation of x86_init.intr_mode_init() will be moved from
>> native_smp_prepare_cpus() in a follow up patch to solve > REASON/PROBLEM>.
> 
> Can you be a little bit more precise here, please? :-)
> 
>> That move would cause the invocation of x86_init.intr_mode_init() for XEN
>> PV platforms. To prevent that, override the default x86_init.
>> intr_mode_init() callback with a noop().
>>
>> [Rewrited by Thomas Gleixner ]
>>
>> Signed-off-by: Dou Liyang 
>> Cc: xen-de...@lists.xenproject.org
>> Cc: boris.ostrov...@oracle.com
> 
> On which tree does this apply? Would be nice to get a hint against which
> source this can be reviewed.

Aah, just found the rest of the series. In case a single patch of a
series isn't stand alone it would be nice to receive at least the cover
letter of the series in order to know what its all about.


Juergen

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

Re: [Xen-devel] [PATCH v8 10/13] x86/xen: Bypass intr mode setup in enlighten_pv system

[Juergen Gross]

On 28/08/17 05:20, Dou Liyang wrote:
> XEN PV overrides smp_prepare_cpus(). xen_pv_smp_prepare_cpus()
> initializes interrupts in the XEN PV specific way and does not invoke
> native_smp_prepare_cpus(). As a consequence, x86_init.intr_mode_init() is
> not invoked either.
> 
> The invocation of x86_init.intr_mode_init() will be moved from
> native_smp_prepare_cpus() in a follow up patch to solve  REASON/PROBLEM>.

Can you be a little bit more precise here, please? :-)

> That move would cause the invocation of x86_init.intr_mode_init() for XEN
> PV platforms. To prevent that, override the default x86_init.
> intr_mode_init() callback with a noop().
> 
> [Rewrited by Thomas Gleixner ]
> 
> Signed-off-by: Dou Liyang 
> Cc: xen-de...@lists.xenproject.org
> Cc: boris.ostrov...@oracle.com

On which tree does this apply? Would be nice to get a hint against which
source this can be reviewed.


Juergen

> ---
>  arch/x86/xen/enlighten_pv.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index 811e4dd..07147dd 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -1250,6 +1250,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
>   x86_platform.get_nmi_reason = xen_get_nmi_reason;
>  
>   x86_init.resources.memory_setup = xen_memory_setup;
> + x86_init.irqs.intr_mode_init= x86_init_noop;
>   x86_init.oem.arch_setup = xen_arch_setup;
>   x86_init.oem.banner = xen_banner;
>  
> 


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

[Xen-devel] [PATCH v10] VT-d: use correct BDF for VF to search VT-d unit

[Chao Gao]

When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function'
are under the scope of the same VT-d unit as the 'Physical Function'.
A 'Physical Function' can be a 'Traditional Function' or an ARI
'Extended Function'. And furthermore, 'Extended Functions' on an
endpoint are under the scope of the same VT-d unit as the 'Traditional
Functions' on the endpoint. To search VT-d unit for a VF, if its PF
isn't an extended function, the BDF of PF should be used. Otherwise
the BDF of a traditional function in the same device with the PF
should be used.

Current code uses PCI_SLOT() to recognize an ARI 'Extended Funcion'.
But it is conceptually wrong w/o checking whether PF is an extended
function and would lead to match VFs of a RC integrated PF to a wrong
VT-d unit.

This patch overrides VF 'is_extfn' field and uses this field to
indicate whether the PF of this VF is an extended function. The field
helps to use correct BDF to search VT-d unit.

Reported-by: Crawford, Eric R 
Signed-off-by: Chao Gao 
---
v10:
 - move setting vf's is_extfn closer to the place where we set other fields.
 - reverse the conditional expression in acpi_find_matched_drhd_unit()

v9:
 - check 'is_virtfn' first in pci_add_device() to avoid potential error if
 linux side sets VF's 'is_extfn'
 - comments changes to make it clear that we use VF's 'is_extfn' intentionally
 otherwise the patch seems like a workaround.

v8:
 - use "conceptually wrong", instead of "a corner case" in commit message
 - check 'is_virtfn' first in acpi_find_matched_drhd_unit()

v7:
 - Drop Eric's tested-by
 - Change commit message to be clearer
 - Re-use VF's is_extfn field
 - access PF's is_extfn field in locked area

---
 xen/drivers/passthrough/pci.c  | 19 +++
 xen/drivers/passthrough/vtd/dmar.c | 12 ++--
 xen/include/xen/pci.h  |  4 
 3 files changed, 25 insertions(+), 10 deletions(-)

diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 27bdb71..187a9e7 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -599,21 +599,24 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
 unsigned int slot = PCI_SLOT(devfn), func = PCI_FUNC(devfn);
 const char *pdev_type;
 int ret;
+bool pf_is_extfn = false;
 
-if (!info)
+if ( !info )
 pdev_type = "device";
-else if (info->is_extfn)
-pdev_type = "extended function";
-else if (info->is_virtfn)
+else if ( info->is_virtfn )
 {
 pcidevs_lock();
 pdev = pci_get_pdev(seg, info->physfn.bus, info->physfn.devfn);
+if ( pdev )
+pf_is_extfn = pdev->info.is_extfn;
 pcidevs_unlock();
 if ( !pdev )
 pci_add_device(seg, info->physfn.bus, info->physfn.devfn,
NULL, node);
 pdev_type = "virtual function";
 }
+else if ( info->is_extfn )
+pdev_type = "extended function";
 else
 {
 info = NULL;
@@ -637,7 +640,15 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
 pdev->node = node;
 
 if ( info )
+{
 pdev->info = *info;
+/*
+ * VF's 'is_extfn' field is used to indicate whether its PF is an
+ * extended function.
+ */
+if ( pdev->info.is_virtfn )
+pdev->info.is_extfn = pf_is_extfn;
+}
 else if ( !pdev->vf_rlen[0] )
 {
 unsigned int pos = pci_find_ext_capability(seg, bus, devfn,
diff --git a/xen/drivers/passthrough/vtd/dmar.c 
b/xen/drivers/passthrough/vtd/dmar.c
index 82040dd..9676471 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -211,15 +211,15 @@ struct acpi_drhd_unit *acpi_find_matched_drhd_unit(const 
struct pci_dev *pdev)
 if ( pdev == NULL )
 return NULL;
 
-if ( pdev->info.is_extfn )
+if ( pdev->info.is_virtfn )
 {
-bus = pdev->bus;
-devfn = 0;
+bus = pdev->info.physfn.bus;
+devfn = (!pdev->info.is_extfn) ? pdev->info.physfn.devfn : 0;
 }
-else if ( pdev->info.is_virtfn )
+else if ( pdev->info.is_extfn )
 {
-bus = pdev->info.physfn.bus;
-devfn = PCI_SLOT(pdev->info.physfn.devfn) ? 0 : 
pdev->info.physfn.devfn;
+bus = pdev->bus;
+devfn = 0;
 }
 else
 {
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 59b6e8a..da1bd22 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -39,6 +39,10 @@
 #define PCI_SBDF3(s,b,df) s) & 0x) << 16) | PCI_BDF2(b, df))
 
 struct pci_dev_info {
+/*
+ * VF's 'is_extfn' field is used to indicate whether its PF is an extended
+ * function.
+ */
 bool_t is_extfn;
 bool_t is_virtfn;
 struct {
-- 
1.8.3.1


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

[Xen-devel] [PATCH v8 10/13] x86/xen: Bypass intr mode setup in enlighten_pv system

[Dou Liyang]

XEN PV overrides smp_prepare_cpus(). xen_pv_smp_prepare_cpus()
initializes interrupts in the XEN PV specific way and does not invoke
native_smp_prepare_cpus(). As a consequence, x86_init.intr_mode_init() is
not invoked either.

The invocation of x86_init.intr_mode_init() will be moved from
native_smp_prepare_cpus() in a follow up patch to solve .

That move would cause the invocation of x86_init.intr_mode_init() for XEN
PV platforms. To prevent that, override the default x86_init.
intr_mode_init() callback with a noop().

[Rewrited by Thomas Gleixner ]

Signed-off-by: Dou Liyang 
Cc: xen-de...@lists.xenproject.org
Cc: boris.ostrov...@oracle.com
---
 arch/x86/xen/enlighten_pv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 811e4dd..07147dd 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1250,6 +1250,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
x86_platform.get_nmi_reason = xen_get_nmi_reason;
 
x86_init.resources.memory_setup = xen_memory_setup;
+   x86_init.irqs.intr_mode_init= x86_init_noop;
x86_init.oem.arch_setup = xen_arch_setup;
x86_init.oem.banner = xen_banner;
 
-- 
2.5.5




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

[Xen-devel] [linux-linus test] 112895: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 112891

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 112891

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
 build-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-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112891
 build-arm64-pvops 3 capture-logsbroken like 112891
 build-arm64-xsm   2 hosts-allocate  broken like 112891
 build-arm64-xsm   3 capture-logsbroken like 112891
 build-arm64   2 hosts-allocate  broken like 112891
 build-arm64   3 capture-logsbroken like 112891
 test-armhf-armhf-xl-rtds   16 guest-start/debian.repeat fail blocked in 112891
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail blocked in 
112891
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112891
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 112891
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 112891
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112891
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112891
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112891
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-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-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-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail 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-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-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
 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 13 guest-saverestore   fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail 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-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-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-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux0cc3b0ec23ce4c69e1e890ed2b8d2fa932b14aad
baseline version:
 linux

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

[H. Peter Anvin]

On 08/21/17 07:31, Peter Zijlstra wrote:
> On Tue, Aug 15, 2017 at 07:20:38AM -0700, Thomas Garnier wrote:
>> On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar  wrote:
> 
>>> Have you considered a kernel with -mcmodel=small (or medium) instead of 
>>> -fpie
>>> -mcmodel=large? We can pick a random 2GB window in the (non-kernel) 
>>> canonical
>>> x86-64 address space to randomize the location of kernel text. The location 
>>> of
>>> modules can be further randomized within that 2GB window.
>>
>> -model=small/medium assume you are on the low 32-bit. It generates
>> instructions where the virtual addresses have the high 32-bit to be
>> zero.
> 
> That's a compiler fail, right? Because the SDM states that for "CALL
> rel32" the 32bit displacement is sign extended on x86_64.
> 

No.  It is about whether you can do something like:

movl $variable, %eax/* rax =  */

or

addl %ecx,variable(,%rsi,4) /* variable[rsi] += ecx */

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

[Xen-devel] [linux-3.18 test] 112894: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

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

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-multivcpu  6 xen-install fail in 112889 pass in 112886
 test-armhf-armhf-xl-arndale   7 xen-boot fail in 112889 pass in 112886
 test-amd64-amd64-xl-rtds  7 xen-boot   fail pass in 112889

Regressions which are regarded as allowable (not blocking):
 build-arm64   2 hosts-allocate broken REGR. vs. 112102
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 112102
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 112102

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   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-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   3 capture-logs  broken blocked in 112102
 build-arm64-xsm   3 capture-logs  broken blocked in 112102
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail blocked in 112102
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 112886 blocked in 
112102
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail in 112886 never 
pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail in 112886 
never pass
 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 112886 never pass
 test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 112886 never 
pass
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 112889 
blocked in 112102
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail in 112889 like 
112102
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 112889 
like 112102
 test-armhf-armhf-libvirt 14 saverestore-support-check fail in 112889 like 
112102
 test-amd64-amd64-xl-rtds 10 debian-install  fail in 112889 like 112102
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 112889 like 
112102
 test-armhf-armhf-xl-xsm 13 migrate-support-check fail in 112889 never pass
 test-armhf-armhf-xl-xsm 14 saverestore-support-check fail in 112889 never pass
 test-armhf-armhf-xl 13 migrate-support-check fail in 112889 never pass
 test-armhf-armhf-xl 14 saverestore-support-check fail in 112889 never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail in 112889 never pass
 test-armhf-armhf-xl-credit2 13 migrate-support-check fail in 112889 never pass
 test-armhf-armhf-xl-credit2 14 saverestore-support-check fail in 112889 never 
pass
 test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 112889 never pass
 test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 112889 never pass
 test-armhf-armhf-libvirt13 migrate-support-check fail in 112889 never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 112889 never pass
 test-armhf-armhf-xl-rtds13 migrate-support-check fail in 112889 never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 112889 never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail in 112889 never 
pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail in 112889 
never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112085
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112102
 test-amd64-amd64-xl-qemut-win7-amd64 16 

Re: [Xen-devel] [kernel-hardening] Re: x86: PIE support and option to extend KASLR randomization

[Boris Lukashev]

On Fri, Aug 25, 2017 at 11:38 AM, Christopher Lameter  wrote:
>
>
> On Thu, 17 Aug 2017, Boris Lukashev wrote:
>
>> Is the expectation then to have security functions also decrease size
>> and operational latency? Seems a bit unrealistic if so.
>> 1-2% performance hit on systems which have become at least several
>> hundred % faster over recent years is not a significant performance
>> regression compared to the baseline before.
>
> Where do you get these fantastic numbers? Where can I buy a system like
> that? Commonly we see regressions with single threaded integer
> performance on most newer processor generations.
>
> These hundreds of percent improvement can only come from floating point
> performance using specialized instructions. There are only a very limited
> number of applications that can make use of it.
>

An example of these fantastic numbers can be seen in
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Pentium+4+3.00GHz which
shows a 9 year old P4 compared to today's desktop chips. Point taken
on the specific types of maths being performed though. I personally
can't make an educated guess at how much of the "modern" functionality
compilers could leverage to optimize these code paths.
I am by no means a chip or compiler architect, but have built a fair
number of systems and service oriented architectures; and in the
business-end of planning and design, a deficit of security function
doesn't just slow down execution by several percent - it can halt the
project or scuttle it altogether as stakeholders do not wish to put
their posteriors on the line.
The intent of my original email was to point out that the balance
between performance and security isn't as clear-cut as "all bugs are
created equal and hackbench outputs tell the whole story," since
aspects of performance and security are often evaluated by separate
parties in different segments of the decision making process.
Providing as many avenues as possible to enhance security posture with
clearly labeled performance penalties may be the difference between
adoption/execution and another cycle of "wait and see." While
decisions around future development agility based on changes in these
optional configurations are definitely a major point to consider, the
decision between a performance penalty and an exposed attack surface
is likely a useful option to leave for the people building the final
systems.

-Boris

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 
112809
 test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install  fail REGR. vs. 112809
 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install   fail REGR. vs. 112809
 test-amd64-i386-xl-qemut-win7-amd64 10 windows-install   fail REGR. vs. 112809

Tests which are failing intermittently (not blocking):
 test-xtf-amd64-amd64-17 xen-boot fail in 112888 pass in 112893
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 112888 
pass in 112893
 test-armhf-armhf-libvirt  6 xen-installfail pass in 112888
 test-armhf-armhf-libvirt-raw  7 xen-boot   fail pass in 112888
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 14 guest-localmigrate fail pass 
in 112888

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
 build-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-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate  broken like 112809
 build-arm64-pvops 2 hosts-allocate  broken like 112809
 build-arm64-xsm   2 hosts-allocate  broken like 112809
 build-arm64-xsm   3 capture-logsbroken like 112809
 build-arm64   3 capture-logsbroken like 112809
 build-arm64-pvops 3 capture-logsbroken like 112809
 test-armhf-armhf-libvirt 14 saverestore-support-check fail in 112888 like 
112809
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 112888 like 
112809
 test-armhf-armhf-libvirt13 migrate-support-check fail in 112888 never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 112888 never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112809
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112809
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112809
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112809
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-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-amd64-amd64-libvirt 13 migrate-support-checkfail   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-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-ws16-amd64 13 guest-saverestore   fail 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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  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-xl-multivcpu 14 saverestore-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-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 

[Xen-devel] [linux-linus test] 112891: tolerable trouble: blocked/broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 112887 
pass in 112891
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 112887 
pass in 112891
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail pass in 112887

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 12 guest-start  fail REGR. vs. 112876

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
 build-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-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112876
 build-arm64-pvops 3 capture-logsbroken like 112876
 build-arm64-xsm   2 hosts-allocate  broken like 112876
 build-arm64-xsm   3 capture-logsbroken like 112876
 build-arm64   2 hosts-allocate  broken like 112876
 build-arm64   3 capture-logsbroken like 112876
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 112864
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112864
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112864
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112876
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112876
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112876
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-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-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-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-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
 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 13 guest-saverestore   fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail 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-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-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-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linuxbab9752480c54b5f483a0f52e53cbdef55a83219
baseline version:
 linux90a6cd503982bfd33ce8c70eb49bd2dd33bc6325

Last test of basis   112876  2017-08-25 19:51:14 Z1 days
Failing since112884  

[Xen-devel] [linux-3.18 test] 112889: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvops 3 capture-logs   broken REGR. vs. 112102

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-multivcpu  6 xen-install   fail pass in 112886
 test-armhf-armhf-xl-arndale   7 xen-boot   fail pass in 112886

Regressions which are regarded as allowable (not blocking):
 build-arm64   2 hosts-allocate broken REGR. vs. 112102
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 112102
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 112102

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
 build-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-xsm   1 build-check(1)   blocked  n/a
 build-arm64   3 capture-logs  broken blocked in 112102
 build-arm64-xsm   3 capture-logs  broken blocked in 112102
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail blocked in 
112102
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 112886 blocked in 
112102
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail in 112886 blocked in 
112102
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail in 112886 never 
pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail in 112886 
never pass
 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 112886 never pass
 test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 112886 never 
pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112102
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 112102
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112102
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112102
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112102
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112102
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112102
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-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-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-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail 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-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail 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-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-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-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail 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
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 

[Xen-devel] [libvirt test] 112890: tolerable trouble: blocked/broken/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   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
 build-arm64-xsm   2 hosts-allocate  broken like 112866
 build-arm64   2 hosts-allocate  broken like 112866
 build-arm64-pvops 2 hosts-allocate  broken like 112866
 build-arm64-xsm   3 capture-logsbroken like 112866
 build-arm64   3 capture-logsbroken like 112866
 build-arm64-pvops 3 capture-logsbroken like 112866
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112866
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112866
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112866
 test-amd64-i386-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-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-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 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  b7e779c1a51793ee63a52889440361d8ba019781
baseline version:
 libvirt  941ec9b6a7ab0ea463ce7dcd2daad858b58cd9ae

Last test of basis   112866  2017-08-25 04:20:19 Z2 days
Failing since112882  2017-08-26 04:21:57 Z1 days2 attempts
Testing same since   112890  2017-08-27 04:20:12 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Scott Garfinkle 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 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 blocked 
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt blocked 
 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   blocked 
 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, 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
112809
 test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install  fail REGR. vs. 112809
 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install   fail REGR. vs. 112809
 test-amd64-i386-xl-qemut-win7-amd64 10 windows-install   fail REGR. vs. 112809

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-raw 10 debian-di-install fail in 112885 pass in 112888
 test-xtf-amd64-amd64-17 xen-boot   fail pass in 112885

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
 build-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-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate  broken like 112809
 build-arm64-pvops 2 hosts-allocate  broken like 112809
 build-arm64-xsm   2 hosts-allocate  broken like 112809
 build-arm64-xsm   3 capture-logsbroken like 112809
 build-arm64   3 capture-logsbroken like 112809
 build-arm64-pvops 3 capture-logsbroken like 112809
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112809
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112809
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112809
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112809
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112809
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112809
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-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-amd64-amd64-libvirt 13 migrate-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-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail 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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  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 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 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-libvirt-raw 12 migrate-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-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen   

[Xen-devel] [xen-unstable-coverity test] 112892: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  803c5a2a42e7c72a4c848e0f0106a941b758a91f
baseline version:
 xen  4a0485c3d343e1c582fa824e4896b9b613a14efe

Last test of basis   112842  2017-08-23 10:49:51 Z3 days
Testing same since   112892  2017-08-27 09:19:45 Z0 days1 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Andrew Cooper 
  Anthony PERARD 
  Boris Ostrovsky 
  Christopher Clark 
  Daniel De Graaf 
  Dario Faggioli 
  David Woodhouse 
  George Dunlap 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Paul Durrant 
  Roger Pau Monné 
  Tamas K Lengyel 
  Tim Deegan 
  Wei Liu 

jobs:
 coverity-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=xen-unstable-coverity
+ revision=803c5a2a42e7c72a4c848e0f0106a941b758a91f
+ . ./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-coverity 803c5a2a42e7c72a4c848e0f0106a941b758a91f
+ branch=xen-unstable-coverity
+ revision=803c5a2a42e7c72a4c848e0f0106a941b758a91f
+ . ./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-coverity
+ qemuubranch=qemu-upstream-unstable-coverity
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-coverity
+ prevxenbranch=xen-4.9-testing
+ '[' x803c5a2a42e7c72a4c848e0f0106a941b758a91f = 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
++ : 

[Xen-devel] [PATCH v2 4/6] xsm: flask: change the dummy xsm policy and flask hook for map_gmfn_foregin

[Zhongze Liu]

The original dummy xsm_map_gmfn_foregin checks if source domain has the proper
privileges over the target domain. Under this policy, it's not allowed if a Dom0
wants to map pages from one DomU to another, which restricts some useful yet not
dangerous use cases of the API, such as sharing pages among DomU's by calling
XENMEM_add_to_physmap from Dom0.

For the dummy xsm_map_gmfn_foregin, change to policy to: IFF the current domain
has the proper privileges on (d) and (t), grant the access.

For the flask side: 1) Introduce a new av permission MMU__SHARE_MEM to denote if
two domains can share memory through map_gmfn_foregin. 2) Change to hook to
grant the access IFF the current domain has proper MMU privileges on (d) and 
(t),
and MMU__SHARE_MEM is allowed between (d) and (t). 3) Modify the default xen.te
to allow MMU__SHARE_MEM for normal domains that allow grant mapping/event
channels.

References to the xsm check have also been updated to pass the current
domain as a new parameter.

This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).

[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

Signed-off-by: Zhongze Liu 

Cc: Daniel De Graaf 
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: xen-devel@lists.xen.org
---
v2:
  * Preserve the error code in both the dummy xsm callback and the flask hook.
  * Also check if (d) and (t) can share memory in the flask hook.
---
 tools/flask/policy/modules/xen.if   |  2 ++
 xen/arch/arm/mm.c   |  2 +-
 xen/arch/x86/mm/p2m.c   |  2 +-
 xen/include/xsm/dummy.h |  8 ++--
 xen/include/xsm/xsm.h   |  7 ---
 xen/xsm/flask/hooks.c   | 10 --
 xen/xsm/flask/policy/access_vectors |  4 
 7 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/tools/flask/policy/modules/xen.if 
b/tools/flask/policy/modules/xen.if
index ed0df4f010..edb7dc8b50 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -127,6 +127,8 @@ define(`domain_comms', `
domain_event_comms($1, $2)
allow $1 $2:grant { map_read map_write copy unmap };
allow $2 $1:grant { map_read map_write copy unmap };
+   allow $1 $2:mmu share_mem;
+   allow $2 $1:mmu share_mem;
 ')
 
 # domain_self_comms(domain)
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index a810a056d7..9ec78d8c03 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1284,7 +1284,7 @@ int xenmem_add_to_physmap_one(
 return -EINVAL;
 }
 
-rc = xsm_map_gmfn_foreign(XSM_TARGET, d, od);
+rc = xsm_map_gmfn_foreign(XSM_TARGET, current->domain, d, od);
 if ( rc )
 {
 rcu_unlock_domain(od);
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index e8a57d118c..a547fd00c0 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2545,7 +2545,7 @@ int p2m_add_foreign(struct domain *tdom, unsigned long 
fgfn,
 if ( tdom == fdom )
 goto out;
 
-rc = xsm_map_gmfn_foreign(XSM_TARGET, tdom, fdom);
+rc = xsm_map_gmfn_foreign(XSM_TARGET, current->domain, tdom, fdom);
 if ( rc )
 goto out;
 
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 62fcea6f04..1a42d85d27 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -525,10 +525,14 @@ static XSM_INLINE int 
xsm_remove_from_physmap(XSM_DEFAULT_ARG struct domain *d1,
 return xsm_default_action(action, d1, d2);
 }
 
-static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain *d, 
struct domain *t)
+static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain *cd,
+   struct domain *d, struct domain *t)
 {
+int rc;
 XSM_ASSERT_ACTION(XSM_TARGET);
-return xsm_default_action(action, d, t);
+rc = xsm_default_action(action, cd, d);
+if (rc) return rc;
+return xsm_default_action(action, cd, t);
 }
 
 static XSM_INLINE int xsm_hvm_param(XSM_DEFAULT_ARG struct domain *d, unsigned 
long op)
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 60c0fd6a62..a20654a803 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -85,7 +85,7 @@ struct xsm_operations {
 int (*memory_pin_page) (struct domain *d1, struct domain *d2, struct 
page_info *page);
 int (*add_to_physmap) (struct domain *d1, struct domain *d2);
 int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
-int (*map_gmfn_foreign) (struct domain *d, struct domain *t);
+int (*map_gmfn_foreign) (struct domain *cd, struct domain *d, struct 
domain *t);
 int 

[Xen-devel] [PATCH v2 2/6] libxl: introduce a new structure to represent static shared memory regions

[Zhongze Liu]

Add a new structure to the IDL familiy to represent static shared memory regions
as proposed in the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).

Also fix some code style issues (indentation, trailling whitespaces).

[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

Signed-off-by: Zhongze Liu 
Reviewed-by: Stefano Stabellini 

Cc: Wei Liu 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: xen-devel@lists.xen.org
---
v2: mention in the commit msg that several style corrections have been done
---
 tools/libxl/libxl.h |  4 
 tools/libxl/libxl_types.idl | 34 +++---
 2 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 229e289750..3ee788642f 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -2237,6 +2237,10 @@ int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int 
nonblock);
 int libxl_qemu_monitor_command(libxl_ctx *ctx, uint32_t domid,
const char *command_line, char **output);
 
+/* Constants for libxl_static_shm */
+#define LIBXL_SSHM_RANGE_UNKNOWN UINT64_MAX
+#define LIBXL_SSHM_ID_MAXLEN128
+
 #include 
 
 #endif /* LIBXL_H */
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 6e80d36256..5ba8a878dc 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -472,7 +472,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
 ("blkdev_start",string),
 
 ("vnuma_nodes", Array(libxl_vnode_info, "num_vnuma_nodes")),
-
+
 ("device_model_version", libxl_device_model_version),
 ("device_model_stubdomain", libxl_defbool),
 # if you set device_model you must set device_model_version too
@@ -543,10 +543,10 @@ libxl_domain_build_info = Struct("domain_build_info",[
("keymap",   string),
("sdl",  libxl_sdl_info),
("spice",libxl_spice_info),
-   
+
("gfx_passthru", libxl_defbool),
("gfx_passthru_kind", 
libxl_gfx_passthru_kind),
-   
+
("serial",   string),
("boot", string),
("usb",  libxl_defbool),
@@ -779,6 +779,33 @@ libxl_device_channel = Struct("device_channel", [
])),
 ])
 
+libxl_sshm_cachepolicy = Enumeration("sshm_cachepolicy", [
+(-1, "UNKNOWN"),
+(0,  "ARM_NORMAL"),  # ARM policies should be < 32
+(32,  "X86_NORMAL"), # X86 policies should be >= 32
+], init_val = "LIBXL_SSHM_CHCHE_POLICY_UNKNOWN")
+
+libxl_sshm_prot = Enumeration("sshm_prot", [
+(-1, "UNKNOWN"),
+(3,  "RW"),
+], init_val = "LIBXL_SSHM_PROT_UNKNOWN")
+
+libxl_sshm_role = Enumeration("sshm_role", [
+(-1, "UNKNOWN"),
+(0,  "MASTER"),
+(1,  "SLAVE"),
+], init_val = "LIBXL_SSHM_ROLE_UNKNOWN")
+
+libxl_static_shm = Struct("static_shm", [
+("id", string),
+("offset", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
+("begin", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
+("end", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
+("prot", libxl_sshm_prot, {'init_val': 'LIBXL_SSHM_PROT_UNKNOWN'}),
+("cache_policy", libxl_sshm_cachepolicy, {'init_val': 
'LIBXL_SSHM_CACHEPOLICY_UNKNOWN'}),
+("role", libxl_sshm_role, {'init_val': 'LIBXL_SSHM_ROLE_UNKNOWN'}),
+])
+
 libxl_domain_config = Struct("domain_config", [
 ("c_info", libxl_domain_create_info),
 ("b_info", libxl_domain_build_info),
@@ -797,6 +824,7 @@ libxl_domain_config = Struct("domain_config", [
 ("channels", Array(libxl_device_channel, "num_channels")),
 ("usbctrls", Array(libxl_device_usbctrl, "num_usbctrls")),
 ("usbdevs", Array(libxl_device_usbdev, "num_usbdevs")),
+("sshms", Array(libxl_static_shm, "num_sshms")),
 
 ("on_poweroff", libxl_action_on_shutdown),
 ("on_reboot", libxl_action_on_shutdown),
-- 
2.14.0


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

[Xen-devel] [PATCH v2 1/6] libxc: add xc_domain_remove_from_physmap to wrap XENMEM_remove_from_physmap

[Zhongze Liu]

This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file". See:

  https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

Then plan is to use XENMEM_add_to_physmap_batch to map the shared pages from
one domU to another and use XENMEM_remove_from_physmap to cancel the sharing.
A wrapper to XENMEM_add_to_physmap_batch was added in the following commit:

  commit 20e725e9364cff4a29945f66986ecd88cca8743d

Now add the wrapper to XENMEM_remove_from_physmap.

Signed-off-by: Zhongze Liu 
Reviewed-by: Stefano Stabellini 
Acked-by: Wei Liu 

Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: xen-devel@lists.xen.org
---
 tools/libxc/include/xenctrl.h |  4 
 tools/libxc/xc_domain.c   | 11 +++
 2 files changed, 15 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index c7710b8f36..0ff15a9255 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1381,6 +1381,10 @@ int xc_domain_add_to_physmap_batch(xc_interface *xch,
xen_pfn_t *gfpns,
int *errs);
 
+int xc_domain_remove_from_physmap(xc_interface *xch,
+  domid_t domid,
+  xen_pfn_t gpfn);
+
 int xc_domain_populate_physmap(xc_interface *xch,
uint32_t domid,
unsigned long nr_extents,
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 3bab4e8bab..e6b32792c0 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1077,6 +1077,17 @@ out:
 return rc;
 }
 
+int xc_domain_remove_from_physmap(xc_interface *xch,
+  domid_t domid,
+  xen_pfn_t gpfn)
+{
+struct xen_remove_from_physmap xrfp = {
+.domid = domid,
+.gpfn = gpfn,
+};
+return do_memory_op(xch, XENMEM_remove_from_physmap, , sizeof(xrfp));
+}
+
 int xc_domain_claim_pages(xc_interface *xch,
uint32_t domid,
unsigned long nr_pages)
-- 
2.14.0


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

[Xen-devel] [PATCH v2 0/6] Allow setting up shared memory areas between VMs from xl config files

[Zhongze Liu]

This series implements the new xl config entry proposed in [1]. Users can use
the new config entry to statically setup shared memory areas among VMs that
don't have grant table support so that they could communicate with each other
through the static shared memory areas.

[1] Proposla to allow setting up shared memory areas between VMs from xl config 
file:
  https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

v2:
  * fixed several code style issues.
  * introduce MMU__SHARE_MEM in flask av permissions, and add a check to this.
permission in the flask hook for xsm_map_gmfn_foreign.
  * support rolling back during creation on partial failure.
  * refcounting the sshm path instead of using "alive" and "zombie" to label the
master and counting the slaves.

Cheers,

Zhongze Liu (6):
  libxc: add xc_domain_remove_from_physmap to wrap
XENMEM_remove_from_physmap
  libxl: introduce a new structure to represent static shared memory
regions
  libxl:xl: add parsing code to parse "libxl_static_sshm" from xl config
files
  xsm: flask: change the dummy xsm policy and flask hook for
map_gmfn_foregin
  libxl: support mapping static shared memory areas during domain
creation
  libxl: support unmapping static shared memory areas during domain
destruction

 tools/flask/policy/modules/xen.if   |   2 +
 tools/libxc/include/xenctrl.h   |   4 +
 tools/libxc/xc_domain.c |  11 +
 tools/libxl/Makefile|   4 +-
 tools/libxl/libxl.h |   4 +
 tools/libxl/libxl_arch.h|   6 +
 tools/libxl/libxl_arm.c |  15 ++
 tools/libxl/libxl_create.c  |  27 ++
 tools/libxl/libxl_domain.c  |   5 +
 tools/libxl/libxl_internal.h|  15 ++
 tools/libxl/libxl_sshm.c| 480 
 tools/libxl/libxl_types.idl |  34 ++-
 tools/libxl/libxl_x86.c |  18 ++
 tools/libxl/libxlu_sshm.c   | 210 
 tools/libxl/libxlutil.h |   6 +
 tools/xl/xl_parse.c |  24 +-
 xen/arch/arm/mm.c   |   2 +-
 xen/arch/x86/mm/p2m.c   |   2 +-
 xen/include/xsm/dummy.h |   8 +-
 xen/include/xsm/xsm.h   |   7 +-
 xen/xsm/flask/hooks.c   |  10 +-
 xen/xsm/flask/policy/access_vectors |   4 +
 22 files changed, 883 insertions(+), 15 deletions(-)
 create mode 100644 tools/libxl/libxl_sshm.c
 create mode 100644 tools/libxl/libxlu_sshm.c

-- 
2.14.0


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

[Xen-devel] [PATCH v2 6/6] libxl: support unmapping static shared memory areas during domain destruction

[Zhongze Liu]

Add libxl__sshm_del to unmap static shared memory areas mapped by
libxl__sshm_add during domain creation. The unmapping process is:

* For a master: decrease the refcount of the sshm region, if the refcount
  reaches 0, cleanup the whole sshm path.
* For a slave: unmap the shared pages, and cleanup related xs entries.
  decrease the refcount of the sshm region, if the refcount reaches 0,
  cleanup the whole sshm path.

This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).

[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

Signed-off-by: Zhongze Liu 

Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: xen-devel@lists.xen.org
---
v2:
  * use the predefined XC_PAGE_SIZE instead of hardcoding 12
  * refcounting the node
---
 tools/libxl/libxl_domain.c   |   5 +++
 tools/libxl/libxl_internal.h |   2 +
 tools/libxl/libxl_sshm.c | 105 +++
 3 files changed, 112 insertions(+)

diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
index 08eccd082b..73ac856fb4 100644
--- a/tools/libxl/libxl_domain.c
+++ b/tools/libxl/libxl_domain.c
@@ -1028,6 +1028,11 @@ void libxl__destroy_domid(libxl__egc *egc, 
libxl__destroy_domid_state *dis)
 goto out;
 }
 
+rc = libxl__sshm_del(gc, domid);
+if (rc) {
+LOGD(ERROR, domid, "Deleting static shm failed.");
+}
+
 if (libxl__device_pci_destroy_all(gc, domid) < 0)
 LOGD(ERROR, domid, "Pci shutdown failed");
 rc = xc_domain_pause(ctx->xch, domid);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7ab2d40c49..731823dc1e 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4360,6 +4360,8 @@ static inline bool libxl__acpi_defbool_val(const 
libxl_domain_build_info *b_info
 _hidden int libxl__sshm_add(libxl__gc *gc, uint32_t domid,
 libxl_static_shm *sshm, int len);
 
+_hidden int libxl__sshm_del(libxl__gc *gc, uint32_t domid);
+
 _hidden int libxl__sshm_check_overlap(libxl__gc *gc, uint32_t domid,
   libxl_static_shm *sshms, int len);
 _hidden int libxl__sshm_setdefault(libxl__gc *gc, uint32_t domid,
diff --git a/tools/libxl/libxl_sshm.c b/tools/libxl/libxl_sshm.c
index a4091a3056..edfde0a905 100644
--- a/tools/libxl/libxl_sshm.c
+++ b/tools/libxl/libxl_sshm.c
@@ -86,6 +86,111 @@ int libxl__sshm_check_overlap(libxl__gc *gc, uint32_t domid,
 return 0;
 }
 
+/* Decrease the refcount of an sshm. When refcount reaches 0,
+ * clean up the whole sshm path */
+static void libxl__sshm_decref(libxl__gc *gc, xs_transaction_t xt,
+   const char *sshm_path)
+{
+int count;
+const char *count_path, *count_string;
+
+count_path = GCSPRINTF("%s/users", sshm_path);
+if (libxl__xs_read_checked(gc, xt, count_path, _string))
+return;
+count = atoi(count_string);
+
+if (--count == 0) {
+libxl__xs_path_cleanup(gc, xt, sshm_path);
+return;
+}
+
+count_string = GCSPRINTF("%d", count);
+libxl__xs_write_checked(gc, xt, count_path, count_string);
+
+return;
+}
+
+static void libxl__sshm_do_unmap(libxl__gc *gc, uint32_t domid, const char *id,
+ uint64_t begin, uint64_t end)
+{
+begin >>= XC_PAGE_SHIFT;
+end >>= XC_PAGE_SHIFT;
+for (; begin < end; ++begin) {
+if (xc_domain_remove_from_physmap(CTX->xch, domid, begin)) {
+SSHM_ERROR(domid, id,
+   "unable to unmap shared page at 0x%"PRIx64".",
+   begin);
+}
+}
+}
+
+static void libxl__sshm_del_slave(libxl__gc *gc, xs_transaction_t xt,
+  uint32_t domid, const char *id, bool isretry)
+{
+const char *slave_path, *begin_str, *end_str;
+uint64_t begin, end;
+
+slave_path = GCSPRINTF("%s/slaves/%"PRIu32, SSHM_PATH(id), domid);
+
+begin_str = libxl__xs_read(gc, xt, GCSPRINTF("%s/begin", slave_path));
+end_str = libxl__xs_read(gc, xt, GCSPRINTF("%s/end", slave_path));
+begin = strtoull(begin_str, NULL, 16);
+end = strtoull(end_str, NULL, 16);
+
+/* Avoid calling do_unmap many times in case of xs transaction retry */
+if (!isretry)
+libxl__sshm_do_unmap(gc, domid, id, begin, end);
+
+libxl__xs_path_cleanup(gc, xt, slave_path);
+}
+
+/* Delete static_shm entries in the xensotre. */
+int libxl__sshm_del(libxl__gc *gc,  uint32_t domid)
+{
+int rc, i;
+bool isretry;
+xs_transaction_t xt = XBT_NULL;
+const char *dom_path, *dom_sshm_path, *role;
+char **sshm_ents;
+unsigned int sshm_num;
+
+dom_path = libxl__xs_get_dompath(gc, domid);
+dom_sshm_path = GCSPRINTF("%s/static_shm", dom_path);
+
+isretry = false;
+for (;;) {

[Xen-devel] [PATCH v2 3/6] libxl:xl: add parsing code to parse "libxl_static_sshm" from xl config files

[Zhongze Liu]

Add the parsing utils for the newly introduced libxl_static_sshm struct
to the libxl/libxlu_* family. And add realated parsing code in xl to
parse the struct from xl config files. This is for the proposal "Allow
setting up shared memory areas between VMs from xl config file" (see [1]).

[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

Signed-off-by: Zhongze Liu 

Cc: Andrew Cooper 
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 
Cc: xen-devel@lists.xen.org
---
v2:
  * fix all the 'Yoda conditions'
  * use the predefined XC_PAGE_MASK instead of defining a new one
---
 tools/libxl/Makefile  |   2 +-
 tools/libxl/libxlu_sshm.c | 210 ++
 tools/libxl/libxlutil.h   |   6 ++
 tools/xl/xl_parse.c   |  24 +-
 4 files changed, 240 insertions(+), 2 deletions(-)
 create mode 100644 tools/libxl/libxlu_sshm.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 082af8f716..3b63fb2cad 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -175,7 +175,7 @@ AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h 
_paths.h \
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
 AUTOSRCS += _libxl_save_msgs_callout.c _libxl_save_msgs_helper.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
-   libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o
+   libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o libxlu_sshm.o
 $(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 
 $(TEST_PROG_OBJS) _libxl.api-for-check: CFLAGS += $(CFLAGS_libxentoollog)
diff --git a/tools/libxl/libxlu_sshm.c b/tools/libxl/libxlu_sshm.c
new file mode 100644
index 00..5276ff9395
--- /dev/null
+++ b/tools/libxl/libxlu_sshm.c
@@ -0,0 +1,210 @@
+#include "libxl_osdeps.h" /* must come before any other headers */
+#include "libxlu_internal.h"
+#include "xenctrl.h"
+
+#include 
+
+#define PARAM_RE(EXPR) "^\\s*" EXPR "\\s*(,|$)"
+#define WORD_RE "([_a-zA-Z0-9]+)"
+#define EQU_RE PARAM_RE(WORD_RE "\\s*=\\s*" WORD_RE)
+
+#define RET_INVAL(msg, curr_str)  do {  \
+xlu__sshm_err(cfg, msg, curr_str);  \
+rc = EINVAL;\
+goto out;   \
+} while(0)
+
+/* set a member in libxl_static_shm and report an error if it's respecified,
+ * @curr_str indicates the head of the remaining string. */
+#define SET_VAL(var, name, type, value, curr_str)  do { \
+if ((var) != LIBXL_SSHM_##type##_UNKNOWN && (var) != value) {   \
+RET_INVAL("\"" name "\" respecified", curr_str);\
+}   \
+(var) = value;  \
+} while(0)
+
+
+static void xlu__sshm_err(XLU_Config *cfg, const char *msg,
+  const char *curr_str) {
+fprintf(cfg->report,
+"%s: config parsing error in shared_memory: %s at '%s'\n",
+cfg->config_source, msg, curr_str);
+}
+
+static int parse_prot(XLU_Config *cfg, char *str, libxl_sshm_prot *prot)
+{
+int rc;
+libxl_sshm_prot new_prot;
+
+if (!strcmp(str, "rw")) {
+new_prot = LIBXL_SSHM_PROT_RW;
+} else {
+RET_INVAL("invalid permission flags", str);
+}
+
+SET_VAL(*prot, "permission flags", PROT, new_prot, str);
+
+rc = 0;
+
+ out:
+return rc;
+}
+
+static int parse_cachepolicy(XLU_Config *cfg, char *str,
+ libxl_sshm_cachepolicy *policy)
+{
+int rc;
+libxl_sshm_cachepolicy new_policy;
+
+if (!strcmp(str, "ARM_normal")) {
+new_policy = LIBXL_SSHM_CACHEPOLICY_ARM_NORMAL;
+} else if (!strcmp(str, "x86_normal")) {
+new_policy = LIBXL_SSHM_CACHEPOLICY_X86_NORMAL;
+} else {
+RET_INVAL("invalid cache policy", str);
+}
+
+SET_VAL(*policy, "cache policy", CACHEPOLICY, new_policy, str);
+rc = 0;
+
+ out:
+return rc;
+}
+
+/* handle key = value pairs */
+static int handle_equ(XLU_Config *cfg, char *key, char *val,
+  libxl_static_shm *sshm)
+{
+int rc;
+
+if (!strcmp(key, "id")) {
+if (strlen(val) > LIBXL_SSHM_ID_MAXLEN) { RET_INVAL("id too long", 
val); }
+if (sshm->id && !strcmp(sshm->id, val)) {
+RET_INVAL("id respecified", val);
+}
+
+sshm->id = strdup(val);
+if (!sshm->id) {
+fprintf(stderr, "sshm parser out of memory\n");
+rc = ENOMEM;
+goto out;
+}
+} else if (!strcmp(key, "role")) {
+libxl_sshm_role new_role;
+
+   

[Xen-devel] [PATCH v2 5/6] libxl: support mapping static shared memory areas during domain creation

[Zhongze Liu]

Add libxl__sshm_add to map shared pages from one DomU to another, The mapping
process involves the follwing steps:

  * Set defaults and check for further errors in the static_shm configs:
overlapping areas, invalid ranges, duplicated master domain,
no master domain etc.
  * Write infomation of static shared memory areas into the appropriate
xenstore paths.
  * Use xc_domain_add_to_physmap_batch to do the page sharing.
  * Set the refcount of the shared region accordingly

Temporarily mark this as unsupported on x86 because calling p2m_add_foregin on
two domU's is currently not allowd on x86 (see the comments in
x86/mm/p2m.c:p2m_add_foregin for more details).

This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).

[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

Signed-off-by: Zhongze Liu 

Cc: Andrew Cooper 
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 
Cc: xen-devel@lists.xen.org
---
v2:
  * coding style corrections
  * replace libxl__xs_get_sshmpath() with a macro
  * use the predefined XC_PAGE_SIZE instead of hardcoding 12
  * avoid calling xc_domain_add_to_physmap many time during xs retry
  * unmapping mapped pages on partial failure
  * refcounting the node
---
 tools/libxl/Makefile |   2 +-
 tools/libxl/libxl_arch.h |   6 +
 tools/libxl/libxl_arm.c  |  15 ++
 tools/libxl/libxl_create.c   |  27 
 tools/libxl/libxl_internal.h |  13 ++
 tools/libxl/libxl_sshm.c | 375 +++
 tools/libxl/libxl_x86.c  |  18 +++
 7 files changed, 455 insertions(+), 1 deletion(-)
 create mode 100644 tools/libxl/libxl_sshm.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 3b63fb2cad..fd624b28f3 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_9pfs.o libxl_domain.o \
+   libxl_9pfs.o libxl_domain.o libxl_sshm.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_arch.h b/tools/libxl/libxl_arch.h
index 5e1fc6060e..1d681d8863 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -71,6 +71,12 @@ int libxl__arch_extra_memory(libxl__gc *gc,
  const libxl_domain_build_info *info,
  uint64_t *out);
 
+_hidden
+bool libxl__arch_domain_support_sshm(const libxl_domain_build_info *b_info);
+
+_hidden
+int libxl__arch_domain_sshm_cachepolicy_setdefault(libxl_static_shm *sshm);
+
 #if defined(__i386__) || defined(__x86_64__)
 
 #define LAPIC_BASE_ADDRESS  0xfee0
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index d842d888eb..0975109c0c 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -1065,6 +1065,21 @@ void libxl__arch_domain_build_info_acpi_setdefault(
 libxl_defbool_setdefault(_info->acpi, false);
 }
 
+bool libxl__arch_domain_support_sshm(const libxl_domain_build_info *b_info)
+{
+return true;
+}
+
+int libxl__arch_domain_sshm_cachepolicy_setdefault(libxl_static_shm *sshm)
+{
+if (sshm->cache_policy == LIBXL_SSHM_CACHEPOLICY_UNKNOWN)
+sshm->cache_policy = LIBXL_SSHM_CACHEPOLICY_ARM_NORMAL;
+if (sshm->cache_policy >= LIBXL_SSHM_CACHEPOLICY_X86_NORMAL)
+return ERROR_INVAL;
+
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 1158303e1a..f0193c84ba 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -501,6 +501,14 @@ int libxl__domain_build(libxl__gc *gc,
 ret = ERROR_INVAL;
 goto out;
 }
+
+/* the p2m has been setup, we could map the static shared memory now. */
+ret = libxl__sshm_add(gc, domid, d_config->sshms, d_config->num_sshms);
+if (ret != 0) {
+LOG(ERROR, "failed to map static shared memory");
+goto out;
+}
+
 ret = libxl__build_post(gc, domid, info, state, vments, localents);
 out:
 return ret;
@@ -918,6 +926,25 @@ static void initiate_domain_create(libxl__egc *egc,
 goto error_out;
 }
 
+if (d_config->num_sshms != 0 &&
+!libxl__arch_domain_support_sshm(_config->b_info)) {
+LOGD(ERROR, domid, 

[Xen-devel] [linux-linus test] 112887: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
112876
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 
112876

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 12 guest-start  fail REGR. vs. 112876

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
 build-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-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112876
 build-arm64-pvops 3 capture-logsbroken like 112876
 build-arm64-xsm   2 hosts-allocate  broken like 112876
 build-arm64-xsm   3 capture-logsbroken like 112876
 build-arm64   2 hosts-allocate  broken like 112876
 build-arm64   3 capture-logsbroken like 112876
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112864
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112864
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112876
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112876
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112876
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-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-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-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-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
 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 13 guest-saverestore   fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail 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-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-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-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linuxbab9752480c54b5f483a0f52e53cbdef55a83219
baseline version:
 linux90a6cd503982bfd33ce8c70eb49bd2dd33bc6325

Last test of basis   112876  2017-08-25 19:51:14 Z1 days
Failing since112884  2017-08-26 14:33:01 Z0 days2 attempts
Testing same since   112887  2017-08-26 23:25:02 Z0 days1 attempts

[Xen-devel] [RFC v5]Proposal to Allow Setting up Shared Memory Areas between VMs from xl Config File

[Zhongze Liu]

Hi,

I'm updating this document to reflect some changes in the code based on the
discussions on #xen-devel and on the mailing list.

The biggest change is to ref-counting the sshm xenstore entry to avoid removing
the node too early while the memory pages are still in use, in section 2.2.

The rest are minor changes such as typos and ambiguous expressions.


1. Motivation and Description

Virtual machines use grant table hypercalls to setup a share page for
inter-VMs communications. These hypercalls are used by all PV
protocols today. However, very simple guests, such as baremetal
applications, might not have the infrastructure to handle the grant table.
This project is about setting up several shared memory areas for inter-VMs
communications directly from the VM config file.
So that the guest kernel doesn't have to have grant table support (in the
embedded space, this is not unusual) to be able to communicate with
other guests.


2. Implementation Plan:


==
2.1 Introduce a new VM config option in xl:
==

2.1.1 Design Goals
~~~

The shared areas should be shareable among several (>=2) VMs, so every shared
physical memory area is assigned to a set of VMs. Therefore, a “token” or
“identifier” should be used here to uniquely identify a backing memory area.
A string no longer than 128 bytes is used here to serve the purpose.

The backing area would be taken from one domain, which we will mark
as the "master domain", and this domain should be created prior to any
other "slave domain"s. Again, we have to use some kind of tag to tell who
is the "master domain".

And the ability to specify the permissions and cacheability (and shareability
for ARM guest's) of the pages to be shared should also be given to the user.

2.2.2 Syntax and Behavior
~
The following example illustrates the syntax of the proposed config entry
(suppose that we're on x86):

In xl config file of vm1:
  static_shm = [ 'id=ID1, begin=0x10, end=0x20, role=master,\
  cache_policy=x86_normal, prot=rw',\
 'id=ID2, begin=0x30, end=0x40, role=master' ]

In xl config file of vm2:
  static_shm = [ 'id=ID1, offset = 0, begin=0x50, end=0x60, \
  role=slave, prot=rw' ]

In xl config file of vm3:
  static_shm = [ 'id=ID2, offset = 0x1, begin=0x69, \
  end=0x80, role=slave' ]

where:
  @id  The identifier of the backing memory area.
   Can be any string that matches the regexp "[_a-zA-Z0-9]+"
   and no longer than 128 characters

  @offset  Can only appear when @role = slave. The sharing will
   start from the beginning of backing memory area plus
   this offset. If not set, it defaults to zero.
   Can be decimals or hexadecimals of the form "0x2",
   and should be the multiple of the hypervisor page
   granularity (currently 4K on both ARM and x86).

  @begin/end   The boundaries of the shared memory area. The format
   requirements are the same with @offset. This should also
   be the multiple of the hypervisor page granularity (currently
   4K on both ARM and x86).

  @roleCan only be 'master' or 'slave', it defaults to 'slave'.

  @protWhen @role = master, this means the largest set of
   stage-2 permission flags that can be granted to the
   slave domains.
   When @role = slave, this means the stage-2 permission
   flags of the shared memory area.
   Currently only 'rw' is supported. If not set. it
   defaults to 'rw'.

  @cache_policyCan only appear when @role = master.
   The stage-2 cacheability/shareability attributes of the
   shared memory area. Currently, only two policies are
   supported:
 * ARM_normal: Only applicable to ARM guests. This
   would mean Inner and Outer Write-Back
   Cacheable, and Inner Shareable.
 * x86_normal: Only applicable to x86 HVM guests. This
   would mean Write-Back Cacheable.
   If not set, it defaults to the *_normal policy for the
   current platform.

Note:
  The sizes of the areas specified by @begin and @end in the slave
  domain's config file should be smaller than or equal to the corresponding
  sizes specified in its master's