Re: [Xen-devel] [DOC RFC] Heterogeneous Multi Processing Support in Xen

[Juergen Gross]

On 15/12/16 19:41, Dario Faggioli wrote:
> On Thu, 2016-12-08 at 11:38 +0100, Juergen Gross wrote:
>> So you really solved the following problem in credit2?
>>
>> You have three domains with 2 vcpus each and different weights. Run
>> them
>> on 3 physical cpus with following pinning:
>>
>> dom1: pcpu 1 and 2
>> dom2: pcpu 2 and 3
>> dom3: pcpu 1 and 3
>>
>> How do you decide which vcpu to run on which pcpu for how long?
>>
> Ok, back to this (sorry, a bit later than how I'd hoped). So, I tried
> to think a bit at the described scenario, but could not figure out what
> you are hinting at.
> 
> There are missing pieces of information, such as what the vcpus do, and
> what exactly are the weights (besides than being different).
> 
> Therefore, I decided to put together a quick eperiment. I've created
> the domains, sat up all their vcpus to run cpu-hog tasks, picked up a
> configuration of my choice for the weights, and run them under both
> Credit1 and Credit2.
> 
> It's a very simple tests, but it will hopefully be helpful in
> understanding the situation better.
> 
> Here's the result.
> 
> On Credit1, equal weigths, unpinned (i.e., plenty of pCPUs available):
>  NAME  CPU(%) [1]
>  vm1   199.9
>  vm2   199.9
>  vm3   199.9
> 
> Pinning as you suggest (i.e., to 3 pCPUs):
>  NAME  CPU(%) [2]
>  vm1   149.0
>  vm266.2
>  vm384.8
> 
> Changing the weights:
>  Name  ID Weight  Cap [3]
>  vm1   82560
>  vm2   95120
>  vm3   6   10240
>  NAME  CPU(%)
>  vm1   100.0
>  vm2   100.0
>  vm3   100.0
> 
> So, here in Credit1, things are ok when there's no pinning in place [1]. As 
> soon as we pin, _even_without_ touching the weights [2], things become 
> *crazy*. In fact, there's absolutely no reason why CPU% numbers would look 
> like how they look in [2].
> 
> This does not surprise me much, though. Credit1's load balancer basically 
> moves vcpus around in a pseudo random fashion, and having to enforce pinning 
> constraints make things even more unpredictable.
> 
> Then it comes the amusing part. At this point, I wonder if I haven't done 
> something wrong in setting up the experiments... Because things really looks 
> too funny. :-O
> In fact, for some reasons, changing the weights as shown [3] cause CPU% 
> numbers to fluctuate a bit (not visible above) and then to stabilize at 100%. 
> That may look like an improvement, but certainly does not reflect the chosen 
> set of weights.
> 
> So, I'd say you were right. Or, actually, things are even worse than what you 
> said: in Credit1, it's not only that pinning and weights does not play well 
> together, it's that even pinning alone works pretty bad.

I'd say: With credit1 pinning should be rather explicit in one of the
following ways:

- a vcpu should be pinned to only 1 pcpu, or
- a group of vcpus should be pinned to a group of pcpus no other
  vcpu is allowed to run on (cpupools seem to be the better choice
  in this case)

> Now, on Credit2, equal weigths, unpinned (i.e., plenty of pCPUs
> available):
>  NAME  CPU(%) [4]
>  vm1   199.9
>  vm2   199.9
>  vm3   199.9
> 
> Pinning as you suggest (i.e., to 3 pCPUs):
>  NAME  CPU(%) [5]
>  vm1   100.0
>  vm2   100.1
>  vm3   100.0
> 
> Changing the weights:
>  Name  ID Weight [6]
>  vm1   2256
>  vm2   3512
>  vm3   6   1024
>  NAME  CPU(%)
>  vm144.1
>  vm287.2
>  vm3   168.7
> 
> Which looks nearly *perfect* to me. :-)

_Really_ impressive!

> In fact, with no constraints [4], each VM gets the 200% share it's
> asking for.
> 
> When only 3 pCPUs can be used, by means of pinning [5], each VM gets
> its fair share of 100%.
> 
> When setting up weights in such a way that vm2 should get 2x CPU time
> than vm1 and vm3 should get 2x CPU time than vm2 [6], things looks,
> well, exactly like that! :-P
> 
> So, since I did not fully understand the problem, I'm not sure whether
> this really answers your question, but it look to me like it actually
> could! :-D
> 
> For sure, it puts Credit2 in rather a good light :-P.

Absolutely!


Juergen

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

Re: [Xen-devel] arm64: Approach for DT based NUMA and issues

[Vijay Kilari]

On Tue, Nov 29, 2016 at 12:29 AM, Julien Grall  wrote:
>
>
> On 26/11/16 06:59, Vijay Kilari wrote:
>>
>> Hi,
>
>
> Hi Vijay,
>
> This mail is mixing two distinct problems:
> 1) Making Xen NUMA-aware
> 2) Make DOM0 NUMA-aware
>
> As mentioned in another part of this thread, those problems should be one by
> one rather than together.
>
> I will focus on problem 1) while answering this e-mail.
>
>
>>Below basic write up on DT based NUMA feature support for arm64
>> platform.
>> I have attempted to get NUMA support, However I face below issues. I would
>> like
>> to discuss these issues. Please let me know your comments on this. Yet to
>> look
>> at ACPI support.
>>
>> DT based NUMA support for arm64 platform
>> 
>> For Xen boot on NUMA arm64 platform, Xen needs to parse
>> CPU and Memory nodes for DT based booting mechanism. Here I would
>> like to discuss about DT based booting mechanism and the issues
>> related to it.
>>
>> 1) Parsing CPU and Memory nodes:
>> ---
>>
>> The numa information associated for CPU and Memory are passed in DT
>> using numa-node-id u32-interger value. More information about NUMA binding
>> is available in linux kernel @ Documentation/devicetree/bindings/numa.txt
>>
>> Similar to Linux kernel, cpu and memory nodes of DT are parsed
>> and numa-node-id information is populated in cpu_parsed and memory_parsed
>> node_t mask.
>>
>> When booting in UEFI mode, UEFI passes memory information to Dom0
>> using EFI memory descriptor table and deletes the memory nodes
>> from the host DT. However to fetch the memory numa node id, memory DT
>> node should not be deleted by EFI stub.
>>
>> ISSUE: When memory node is _NOT_ deleted by EFI stub from host DT,
>> Xen identifies the memory node [xen/arch/arm/bootfdt.c, early_scan_node()
>> ]
>> which adds memory ranges to bootinfo.mem structure there by adding
>> duplicate
>> entry and eventually initialization fails.
>>
>> Possible Solution: While adding new memory region to bootinfo.mem, check
>> for
>> duplicate entries and back off if entry is already available from UEFI mem
>> info
>> table.
>
>
> I think we should have a different approach. I actually like the approach
> suggested by Andre in [1]), which is if the UEFI memory mapped exists (i.e
> bootinfo.mem is already filled), then DT is only used to get NUMA node
> information.
>
>>
>> 2) Parsing CPU nodes:
>> -
>> The CPU nodes are parsed to extract numa-node-id info for each cpu and
>> cpu_nodemask is populated.
>>
>> The MPIDR register value is read for each CPU and cpu_to_node[] is
>> populated.
>
>
> To emphase here, cpu_to_node will be indexed using Xen CPUID and not MPIDR.
> They can be different and Xen does not have a clue of the MPIDR except in
> very few places.
>
>>
>> 3) Parsing Memory nodes:
>> --
>> For all the DT memory nodes in the flattend DT, start address, size
>> and numa-node-id value is extracted and stored in "node_memblk_range[]"
>> which is of type struct node.
>>
>> Each bootinfo.mem entry from UEFI is verified against node_memblk_range[]
>> and
>> NODE_DATA is populated with start PFN, end PFN and nodeid.
>>
>> Populating memnodemap:
>>
>> The memnodemap[] is allocated from heap and using the NODE_DATA structure,
>> the memnodemap[] is populated with nodeid for each page index.
>>
>> This memnodemap info is used to fetch memory node id for a given page
>> by calling phys_to_nid() by memory allocator.
>>
>> ISSUE: phys_to_nid() is called by memory allocator before memnodemap[]
>> is initialized.
>>
>> Since memnodemap[] is allocated from heap, and hence boot allocator should
>> be initialized. The boot_allocator() needs phys_to_nid() which is not
>> available untill memnodemap[] is initialized. So there is deadlock
>> situation
>> during initialization. To overcome this phsy_to_nid() should rely on
>> node_memblk_range[] to get nodeid untill memnodemap[] is initialized.
>
>
> Looking at the code, boot_allocator() does not need phys_to_nid until the
> end. So it would be perfectly fine to use alloc_boot_pages to allocate
> memnodemap.
>
>>
>> 4) Generating memory nodes for DOM0
>> -
>> Linux kernel device drivers that uses devm_zalloc(), tries to allocate
>> memory
>> from local memory node. So Dom0 needs to have memory allocated on all the
>> available nodes of the system.
>>
>> Ex: SMMU driver of device on node 1 tries to allocate memory
>> on node 1.
>>
>> ISSUE:
>>  - Dom0's memory should be split across all the available memory nodes
>>of the system and memory nodes should be generated accordingly.
>>  - Memory DT node generated by Xen for Dom0 should populate numa-node-id
>>information.
>
>
> If you drop numa-node-id property from every node, DOM0 will not try to use
> NUMA. Is there any specific 

[Xen-devel] [xen-4.4-testing baseline-only test] 68226: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-320 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 68083
 test-xtf-amd64-amd64-3 31 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 68083
 test-xtf-amd64-amd64-520 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 68083
 test-xtf-amd64-amd64-342 xtf/test-hvm64-invlpg~shadow fail REGR. vs. 68083
 test-xtf-amd64-amd64-5 31 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 68083
 test-xtf-amd64-amd64-542 xtf/test-hvm64-invlpg~shadow fail REGR. vs. 68083
 test-xtf-amd64-amd64-220 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 68083
 test-xtf-amd64-amd64-2 31 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 68083
 test-xtf-amd64-amd64-242 xtf/test-hvm64-invlpg~shadow fail REGR. vs. 68083
 test-xtf-amd64-amd64-4   52 leak-check/check  fail REGR. vs. 68083
 test-xtf-amd64-amd64-3   52 leak-check/check  fail REGR. vs. 68083
 test-xtf-amd64-amd64-5   52 leak-check/check  fail REGR. vs. 68083
 test-xtf-amd64-amd64-2   52 leak-check/check  fail REGR. vs. 68083
 test-xtf-amd64-amd64-1   52 leak-check/check  fail REGR. vs. 68083
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 20 leak-check/check fail REGR. vs. 
68083

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl  19 guest-start/debian.repeatfail   like 68083
 test-amd64-amd64-xl-credit2  19 guest-start/debian.repeatfail   like 68083
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 68083
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 68083
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 68083
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail like 
68083

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
 test-xtf-amd64-amd64-4   10 xtf-fep  fail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-3   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-5   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-2   10 xtf-fep  fail   never pass
 test-armhf-armhf-libvirt 11 guest-start  fail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-xtf-amd64-amd64-4   51 xtf/test-hvm64-xsa-195   fail   never pass
 build-i386-rumprun6 xen-buildfail   never pass
 test-xtf-amd64-amd64-1   10 xtf-fep  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-xtf-amd64-amd64-3   51 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-5   51 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-2   51 xtf/test-hvm64-xsa-195   fail   never pass
 build-amd64-rumprun   6 xen-buildfail   never pass
 test-xtf-amd64-amd64-1   51 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 xen  149c34a6ea0c6821620554059e85cb89acf0ff8f
baseline version:
 xen  6639a202f285ace4adf57453ade066bd4b4298e0

Last test of basis68083  2016-11-23 06:51:33 Z   23 days
Testing same since68226  2016-12-15 15:17:11 Z0 days1 

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

[Juergen Gross]

On 15/12/16 18:36, Borislav Petkov wrote:
> On Thu, Dec 15, 2016 at 12:27:49PM -0500, Boris Ostrovsky wrote:
>> It will probably fix it but I don't think we want this: it's a
>> build-time solution. Most kernels have XEN on even though they are
>> booted bare-metal.
> 
> Lemme tell you want I want: a way to detect I'm running on xen. Does
> CPUID(4) work really early, at load_ucode_bsp() time?
> 
> IOW, can I use some of the functionality hypervisor_cpuid_base() uses to
> detect xen and stop loading any further?

What you really need is to avoid being called on a Xen pv guest. And
this is easy by using xen_domain().

Not trying to load ucode in _any_ guest is an optimization only.

The attached patch works for me in dom0, bare metal and Xen HVM guest.


Juergen
>From 0b56d1f86679c5dc435ab6d96eb2f68b666271bb Mon Sep 17 00:00:00 2001
From: Juergen Gross 
Date: Fri, 16 Dec 2016 07:18:34 +0100
Subject: [PATCH] x86/microcode: don't try to load microcode when running as a
 xen pv guest

As a Xen pv guest some mechanisms to do microcode loading or
verification might not work. As the hypervisor is responsible for
loading the microcode just skip microcode loading in case of running
under Xen.

Signed-off-by: Juergen Gross 
---
 arch/x86/kernel/cpu/microcode/core.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
index 6996413..8dfc8bd 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -32,6 +32,8 @@
 #include 
 #include 
 
+#include 
+
 #include 
 #include 
 #include 
@@ -91,6 +93,9 @@ static bool __init check_loader_disabled_bsp(void)
 	if (cmdline_find_option_bool(cmdline, option))
 		*res = true;
 
+	if (xen_domain())
+		*res = true;
+
 	return *res;
 }
 
@@ -143,6 +148,9 @@ void __init load_ucode_bsp(void)
 
 static bool check_loader_disabled_ap(void)
 {
+	if (xen_domain())
+		return true;
+
 #ifdef CONFIG_X86_32
 	return *((bool *)__pa_nodebug(_ucode_ldr));
 #else
-- 
2.10.2

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

Re: [Xen-devel] [PATCH v2] x86/emul: Simplfy L{ES, DS, SS, FS, GS} handling

[Jan Beulich]

>>> On 15.12.16 at 18:10,  wrote:
> %ss, %fs and %gs can be calculated by directly masking the opcode.  %es and
> %ds cant, but the calculation isn't hard.
> 
> Use seg rather than dst.val for storing the calculated segment, which is
> appropriately typed.  Drop the sel local variable entirely and use dst.val
> instead.  The mode_64bit() check can be repositioned and simplified to drop
> the ext check.  Replace opencoding of X86EMUL_OKAY.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 


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

[Xen-devel] [XEN VMID RESEND v5 2/2] xen/arm: Add support for 16 bit VMIDs

[Bhupinder Thakur]

VMID space is increased to 16-bits from 8-bits in ARMv8 8.1 revision.
This allows more than 256 VMs to be supported by Xen.

This change adds support for 16-bit VMIDs in Xen based on whether the
architecture supports it.

Signed-off-by: Bhupinder Thakur 
---
 xen/arch/arm/p2m.c  | 52 ++---
 xen/include/asm-arm/p2m.h   |  2 +-
 xen/include/asm-arm/processor.h | 18 +-
 3 files changed, 62 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 6930f8c..09ceb37 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -14,15 +15,25 @@
 #include 
 #include 
 
+#define MAX_VMID_8_BIT  (1UL << 8)
+#define MAX_VMID_16_BIT (1UL << 16)
+
+#define INVALID_VMID 0 /* VMID 0 is reserved */
+
 #ifdef CONFIG_ARM_64
 static unsigned int __read_mostly p2m_root_order;
 static unsigned int __read_mostly p2m_root_level;
 #define P2M_ROOT_ORDERp2m_root_order
 #define P2M_ROOT_LEVEL p2m_root_level
+static unsigned int __read_mostly max_vmid = MAX_VMID_8_BIT;
+/* VMID is by default 8 bit width on AArch64 */
+#define MAX_VMID   max_vmid
 #else
 /* First level P2M is alway 2 consecutive pages */
 #define P2M_ROOT_LEVEL 1
 #define P2M_ROOT_ORDER1
+/* VMID is always 8 bit width on AArch32 */
+#define MAX_VMIDMAX_VMID_8_BIT
 #endif
 
 #define P2M_ROOT_PAGES(1<root = page;
 
-p2m->vttbr = page_to_maddr(p2m->root) | ((uint64_t)p2m->vmid & 0xff) << 48;
+p2m->vttbr = page_to_maddr(p2m->root) | ((uint64_t)p2m->vmid << 48);
 
 /*
  * Make sure that all TLBs corresponding to the new VMID are flushed
@@ -1228,19 +1239,27 @@ static int p2m_alloc_table(struct domain *d)
 return 0;
 }
 
-#define MAX_VMID 256
-#define INVALID_VMID 0 /* VMID 0 is reserved */
 
 static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
 
 /*
- * VTTBR_EL2 VMID field is 8 bits. Using a bitmap here limits us to
- * 256 concurrent domains.
+ * VTTBR_EL2 VMID field is 8 or 16 bits. AArch64 may support 16-bit VMID.
+ * Using a bitmap here limits us to 256 or 65536 (for AArch64) concurrent
+ * domains. The bitmap space will be allocated dynamically based on
+ * whether 8 or 16 bit VMIDs are supported.
  */
-static DECLARE_BITMAP(vmid_mask, MAX_VMID);
+static unsigned long *vmid_mask;
 
 static void p2m_vmid_allocator_init(void)
 {
+/*
+ * allocate space for vmid_mask based on MAX_VMID
+ */
+vmid_mask = xzalloc_array(unsigned long, BITS_TO_LONGS(MAX_VMID));
+
+if ( !vmid_mask )
+panic("Could not allocate VMID bitmap space");
+
 set_bit(INVALID_VMID, vmid_mask);
 }
 
@@ -1630,20 +1649,36 @@ void __init setup_virt_paging(void)
 
 unsigned int cpu;
 unsigned int pa_range = 0x10; /* Larger than any possible value */
+bool vmid_8_bit = false;
 
 for_each_online_cpu ( cpu )
 {
 const struct cpuinfo_arm *info = _data[cpu];
 if ( info->mm64.pa_range < pa_range )
 pa_range = info->mm64.pa_range;
+
+/* Set a flag if the current cpu does not support 16 bit VMIDs. */
+if ( info->mm64.vmid_bits != MM64_VMID_16_BITS_SUPPORT )
+vmid_8_bit = true;
 }
 
+/*
+ * If the flag is not set then it means all CPUs support 16-bit
+ * VMIDs.
+ */
+if ( !vmid_8_bit )
+max_vmid = MAX_VMID_16_BIT;
+
 /* pa_range is 4 bits, but the defined encodings are only 3 bits */
 if ( pa_range >= ARRAY_SIZE(pa_range_info) || 
!pa_range_info[pa_range].pabits )
 panic("Unknown encoding of ID_AA64MMFR0_EL1.PARange %x\n", pa_range);
 
 val |= VTCR_PS(pa_range);
 val |= VTCR_TG0_4K;
+
+/* Set the VS bit only if 16 bit VMID is supported. */
+if ( MAX_VMID == MAX_VMID_16_BIT )
+val |= VTCR_VS;
 val |= VTCR_SL0(pa_range_info[pa_range].sl0);
 val |= VTCR_T0SZ(pa_range_info[pa_range].t0sz);
 
@@ -1651,9 +1686,10 @@ void __init setup_virt_paging(void)
 p2m_root_level = 2 - pa_range_info[pa_range].sl0;
 p2m_ipa_bits = 64 - pa_range_info[pa_range].t0sz;
 
-printk("P2M: %d-bit IPA with %d-bit PA\n",
+printk("P2M: %d-bit IPA with %d-bit PA and %d-bit VMID\n",
p2m_ipa_bits,
-   pa_range_info[pa_range].pabits);
+   pa_range_info[pa_range].pabits,
+   ( MAX_VMID == MAX_VMID_16_BIT ) ? 16 : 8);
 #endif
 printk("P2M: %d levels with order-%d root, VTCR 0x%lx\n",
4 - P2M_ROOT_LEVEL, P2M_ROOT_ORDER, val);
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 0987be2..9de55fc 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -30,7 +30,7 @@ struct p2m_domain {
 struct page_info *root;
 
 /* Current VMID in use */
-uint8_t vmid;
+uint16_t vmid;
 
 /* Current Translation 

[Xen-devel] [XEN VMID RESEND v5 1/2] xen/arm: Move p2m_vmid_allocator_init() inside setup_virt_paging()

[Bhupinder Thakur]

Since VMIDs are related to 2nd stage address translation, it makes more sense
to move the call to p2m_vmid_allocator_init(), which initializes the vmid
allocation bitmap, inside setup_virt_paging(), where 2nd stage address 
translation
is set up.

Signed-off-by: Bhupinder Thakur 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/p2m.c| 5 -
 xen/arch/arm/setup.c  | 2 --
 xen/include/asm-arm/p2m.h | 3 ---
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index cc5634b..2327509 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1241,7 +1241,7 @@ static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
  */
 static DECLARE_BITMAP(vmid_mask, MAX_VMID);
 
-void p2m_vmid_allocator_init(void)
+static void p2m_vmid_allocator_init(void)
 {
 set_bit(INVALID_VMID, vmid_mask);
 }
@@ -1659,6 +1659,9 @@ void __init setup_virt_paging(void)
 #endif
 printk("P2M: %d levels with order-%d root, VTCR 0x%lx\n",
4 - P2M_ROOT_LEVEL, P2M_ROOT_ORDER, val);
+
+p2m_vmid_allocator_init();
+
 /* It is not allowed to concatenate a level zero root */
 BUG_ON( P2M_ROOT_LEVEL == 0 && P2M_ROOT_ORDER > 0 );
 setup_virt_paging_one((void *)val);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 38eb888..ac49515 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -789,8 +789,6 @@ void __init start_xen(unsigned long boot_phys_offset,
 
 gic_init();
 
-p2m_vmid_allocator_init();
-
 softirq_init();
 
 tasklet_subsys_init();
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index fdb6b47..0987be2 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -152,9 +152,6 @@ void p2m_altp2m_check(struct vcpu *v, uint16_t idx)
 /* Not supported on ARM. */
 }
 
-/* Initialise vmid allocator */
-void p2m_vmid_allocator_init(void);
-
 /* Second stage paging setup, to be called on all CPUs */
 void setup_virt_paging(void);
 
-- 
2.7.4


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl   6 xen-boot fail REGR. vs. 101737
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-boot   fail REGR. vs. 101737
 test-amd64-i386-xl-qemut-win7-amd64  6 xen-boot  fail REGR. vs. 101737
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101737
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 101737
 test-amd64-i386-pair  9 xen-boot/src_hostfail REGR. vs. 101737
 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101737
 test-amd64-amd64-qemuu-nested-intel  6 xen-boot  fail REGR. vs. 101737
 test-amd64-amd64-xl-pvh-intel  6 xen-bootfail REGR. vs. 101737
 test-amd64-amd64-xl-multivcpu  6 xen-bootfail REGR. vs. 101737
 test-amd64-i386-freebsd10-amd64  6 xen-boot  fail REGR. vs. 101737
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
101737
 build-armhf-pvops 5 kernel-build   fail in 102733 REGR. vs. 101737

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 103011 pass in 
103352
 test-amd64-amd64-xl-qemut-win7-amd64 3 host-install(3) broken in 103011 pass 
in 103352
 test-amd64-i386-xl   3 host-install(3) broken in 103011 pass in 103352
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken in 103011 
pass in 103352
 test-amd64-amd64-xl-qemuu-win7-amd64 3 host-install(3) broken in 103011 pass 
in 103352
 test-amd64-i386-xl-qemut-winxpsp3 3 host-install(3) broken in 103011 pass in 
103352
 test-amd64-amd64-libvirt-vhd 9 debian-di-install fail in 102733 pass in 102886
 test-amd64-amd64-xl-xsm 19 guest-start/debian.repeat fail in 102755 pass in 
103089
 test-armhf-armhf-libvirt-xsm 14 guest-stop   fail in 102755 pass in 103352
 test-armhf-armhf-xl-multivcpu 11 guest-start fail in 102829 pass in 103352
 test-amd64-i386-xl-xsm6 xen-boot fail in 102886 pass in 103352
 test-amd64-amd64-qemuu-nested-amd 9 debian-hvm-install fail in 102886 pass in 
103352
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail in 102886 pass 
in 103352
 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail in 103011 
pass in 103352
 test-armhf-armhf-libvirt-xsm 11 guest-start  fail in 103011 pass in 103352
 test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail in 103089 pass 
in 103352
 test-armhf-armhf-libvirt 11 guest-start  fail in 103165 pass in 103352
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot   fail pass in 102733
 test-amd64-i386-xl-raw6 xen-boot   fail pass in 102733
 test-amd64-amd64-libvirt  6 xen-boot   fail pass in 102733
 test-amd64-i386-libvirt-xsm   6 xen-boot   fail pass in 102755
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-boot fail pass in 102755
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot   fail pass in 102829
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 
102886
 test-amd64-amd64-libvirt-vhd  6 xen-boot   fail pass in 102886
 test-amd64-i386-freebsd10-i386  6 xen-boot fail pass in 103011
 test-amd64-amd64-xl-xsm   6 xen-boot   fail pass in 103089
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail pass in 103089
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_host fail pass in 103089
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host fail pass in 103089
 test-amd64-amd64-xl-rtds  6 xen-boot   fail pass in 103089
 test-amd64-amd64-pair 9 xen-boot/src_host  fail pass in 103165
 test-amd64-amd64-pair10 xen-boot/dst_host  fail pass in 103165
 test-amd64-amd64-libvirt-xsm  6 xen-boot   fail pass in 103165

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 102755 like 
101715
 test-armhf-armhf-xl-credit2  11 guest-start fail in 102829 like 101737
 test-armhf-armhf-xl-xsm  11 guest-start fail in 102829 like 101737
 test-armhf-armhf-xl-rtds 16 guest-start.2 fail in 102886 blocked in 101737
 test-amd64-i386-rumprun-i386 16 rumprun-demo-xenstorels/xenstorels.repeat fail 
in 102886 blocked in 101737
 test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat fail in 102886 like 
101737
 test-armhf-armhf-xl  11 guest-start fail in 103089 like 101672
 test-armhf-armhf-libvirt 15 guest-start/debian.repeatfail  like 101672
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeatfail  like 101687
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeat

[Xen-devel] [linux-4.1 bisection] complete test-amd64-amd64-qemuu-nested-intel

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-qemuu-nested-intel
testid xen-boot

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
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.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:  9a9a2373142ac2c6fd9df9d038eb929b919e30d7
  Bug not present: 1b15bd7396897e2f8018f863dd18006092a4deb0
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/103444/


  commit 9a9a2373142ac2c6fd9df9d038eb929b919e30d7
  Author: Kashyap Desai 
  Date:   Fri Oct 21 06:33:32 2016 -0700
  
  scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) 
devices
  
  [ Upstream commit 1e793f6fc0db920400574211c48f9157a37e3945 ]
  
  Commit 02b01e010afe ("megaraid_sas: return sync cache call with
  success") modified the driver to successfully complete SYNCHRONIZE_CACHE
  commands without passing them to the controller. Disk drive caches are
  only explicitly managed by controller firmware when operating in RAID
  mode. So this commit effectively disabled writeback cache flushing for
  any drives used in JBOD mode, leading to data integrity failures.
  
  [mkp: clarified patch description]
  
  Fixes: 02b01e010afeeb49328d35650d70721d2ca3fd59
  CC: sta...@vger.kernel.org
  Signed-off-by: Kashyap Desai 
  Signed-off-by: Sumit Saxena 
  Reviewed-by: Tomas Henzl 
  Reviewed-by: Hannes Reinecke 
  Reviewed-by: Ewan D. Milne 
  Signed-off-by: Martin K. Petersen 
  Signed-off-by: Sasha Levin 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-4.1/test-amd64-amd64-qemuu-nested-intel.xen-boot.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/test-amd64-amd64-qemuu-nested-intel.xen-boot
 --summary-out=tmp/103444.bisection-summary --basis-template=101737 
--blessings=real,real-bisect linux-4.1 test-amd64-amd64-qemuu-nested-intel 
xen-boot
Searching for failure / basis pass:
 103352 fail [host=elbling0] / 101737 [host=godello0] 101715 [host=nobling0] 
101687 [host=godello1] 101672 [host=chardonnay0] 101659 [host=italia1] 101649 
[host=huxelrebe1] 101401 ok.
Failure / basis pass flights: 103352 / 101401
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
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
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 8576fa45c10e665bb72931a31461c7310f3c5494 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
89c4cbe8d234049b0145e4dc5e5d19d626250b57 
4220231eb22235e757d269722b9f6a594fbcb70f 
8e4b2676685f50bc26f03b5f62d8b7aea8e69dbf
Basis pass 91473db3a3257eacead8f4d84cf4bc96c447193f 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
570117996772b762e9654e58e708943a4db68b4f 
71b8b46111219a2f83f4f9ae06ac5409744ea86e
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#91473db3a3257eacead8f4d84cf4bc96c447193f-8576fa45c10e665bb72931a31461c7310f3c5494
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#c4e0d84d3c92923fdbc7fa922638d54e5e834753-89c4cbe8d234049b0145e4dc5e5d19d626250b57
 
git://xenbits.xen.org/qemu-xen.git#570117996772b762e9654e58e708943a4db68b4f-4220231eb22235e757d269722b9f6a594fbcb70f
 
git://xenbits.xen.org/xen.git#71b8b46111219a2f83f4f9ae06ac5409744ea86e-8e4b2676685f50bc26f03b5f62d8b7aea8e69dbf
Loaded 7002 nodes in revision graph
Searching for test results:
 101401 pass 91473db3a3257eacead8f4d84cf4bc96c447193f 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
570117996772b762e9654e58e708943a4db68b4f 
71b8b46111219a2f83f4f9ae06ac5409744ea86e
 101649 [host=huxelrebe1]
 101672 [host=chardonnay0]
 101659 [host=italia1]
 101687 [host=godello1]
 101715 [host=nobling0]
 101737 [host=godello0]
 102733 fail 8576fa45c10e665bb72931a31461c7310f3c5494 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 

[Xen-devel] [xen-unstable-smoke test] 103439: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   5 libvirt-buildfail REGR. vs. 103284

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

version targeted for testing:
 xen  eaddbb122e918d0ee61b9572398833661ea93670
baseline version:
 xen  fc9229c4bb35c5474fbc67f78e628dcbcc90afc5

Last test of basis   103284  2016-12-13 19:03:56 Z2 days
Failing since103292  2016-12-13 22:19:08 Z2 days   20 attempts
Testing same since   103417  2016-12-15 18:01:58 Z0 days4 attempts


People who touched revisions under test:
  Andrew Cooper 
  Cédric Bosdonnat 
  Haozhong Zhang 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Konrad Rzeszutek Wilk 
  Razvan Cojocaru 
  Ross Lagerwall 
  Stefano Stabellini 
  Suravee Suthikulpanit 
  Tamas K Lengyel 
  Tim Deegan 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  fail
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt 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.

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

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf aaa61995af9e0b65c37bdad6796867760fa1d5fe
baseline version:
 ovmf dc756baeda55490202f3150a8821b5164e906451

Last test of basis68221  2016-12-14 16:19:37 Z1 days
Testing same since68227  2016-12-15 16:17:30 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 
  Liming Gao 

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



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

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

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


Push not applicable.


commit aaa61995af9e0b65c37bdad6796867760fa1d5fe
Author: Dandan Bi 
Date:   Mon Dec 12 10:26:54 2016 +0800

MdeModulePkg/CapsuleApp: Fix GUID/protocol format issues

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Jiewen Yao 

commit ea7dcfed68d59d6c462dcefd943aa065204dfda5
Author: Dandan Bi 
Date:   Thu Nov 24 15:33:28 2016 +0800

MdeModulePkg: Add missing info string for PCDs

Some Pcds are added to the dec file, but miss to add the
prompt& info to the uni file, now add them.

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Jiewen Yao 

commit 11ee1bc93dfb590ae0c9bd0f0400b8591ad21525
Author: Dandan Bi 
Date:   Tue Nov 22 15:38:10 2016 +0800

MdeModulePkg: Make the comments align with the function

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Jiewen Yao 

commit 499ed484e8ea081ed051fa411161bf43569a75d7
Author: Dandan Bi 
Date:   Tue Dec 13 16:08:01 2016 +0800

UefiCpuPkg/Capsule: Fix coding style issues

Cc: Jiewen Yao 
Cc: Jeff Fan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Jiewen Yao 

commit 764b294f111d3a14b0278bc26707e382536428b9
Author: Dandan Bi 
Date:   Tue Dec 13 10:54:25 2016 +0800

UefiCpuPkg/MicrocodeUpdateDxe: Fix coding style issues in INF file

1. Add MicrocodeUpdate.h to the [Sources] section.
2. Fix the incorrect Guid/Protocol format issues.

Cc: Jiewen Yao 
Cc: Jeff Fan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Jiewen Yao 

commit 664e3a0b9f1d97f0dc3e51bbb8d6ad17d2acd4c7
Author: Dandan Bi 
Date:   Tue Dec 13 10:49:08 2016 +0800

UefiCpuPkg: Add info string to UNI file for PcdCpuSmmStaticPageTable

Cc: Jiewen Yao 
Cc: Jeff Fan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Jiewen Yao 

commit 367284e7735478b0c4ad37d8f6bf17d3c4a473d0
Author: Dandan Bi 
Date:   Tue Dec 13 10:46:28 2016 +0800

UefiCpuPkg: Make the comments align with the functions

Cc: Jeff Fan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Jeff Fan 

commit 

[Xen-devel] RFC: p2m type change draft

[George Dunlap]

Yu Zhang,

As we discussed, attached is the draft of the change to the 
p2m_change_entry_type changes I was working on.

Currently, Xen keeps track of what certain types “should” be, via a list of 
logdirty ranges as well as mmio ranges. 

This patch series attempts to do the opposite: to make “p2m_change_entry_type” 
simply change all entries of type ot to type nt.

It has a couple of issues at the moment.  It’s not yet complete — the actual 
number of entries still to be recalculated isn’t counted.

At the moment both migration and vram logdirty are used by the same type, and 
disambiguated by the “global_logdirty” bit.  To move to the new model, we’d 
have to have two different types.

And some more listed in the patches.

As I said, I’m not sure this is the right way forward or not — but I think it’s 
worth looking at.

Peace,

 -George



0001-xen-ept-Rename-ept_invalidate_emt-to-ept_misconfigur.patch
Description: 0001-xen-ept-Rename-ept_invalidate_emt-to-ept_misconfigur.patch


0002-xen-p2m-Make-p2m_change_entry_type-generic.patch
Description: 0002-xen-p2m-Make-p2m_change_entry_type-generic.patch
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 8/8] libelf: safety: Document safety principles in header file

[George Dunlap]

> On Dec 16, 2016, at 12:43 AM, Jan Beulich  wrote:
> 
 On 09.12.16 at 16:44,  wrote:
>> + *  - Any loop needs to be accompanied by calls to elf_iter_ok (or
>> + *elf_iter_ok_counted).
>> + *
>> + *Rationale: the image must not be able to cause libelf to do
>> + *unbounded work (ie, get stuck in a loop).
> 
> As expressed before, I'm not convinced library code should be
> concerned about caller restrictions.

People designing toolstacks that call this function are likely to be thinking 
about domains and things, not, “What happens if I get a rogue elf image that 
causes this function to run forever?”  I think if we can prevent libelf-source 
DoS bugs in all toolstacks that rely on libxl, then it makes sense to do so.

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

Re: [Xen-devel] [PATCH RFC] tools/xenlight: Create xenlight Makefile

[George Dunlap]

On Fri, Dec 16, 2016 at 7:20 AM, Ronald Rojas  wrote:
> Create a basic Makefile to build and install libxenlight Golang
> bindings.  Also add a template.

What's this template again?

>
> ---
>
> Eventually this patch will contain the actual bindings package; for
> now it just includes a stub package.
>
> To Do:
> - Have configure detect golang bindings properly
>
> CC: xen-devel 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: George Dunlap 
> CC: George Dunlap 
> ---
>  tools/Makefile| 16 
>  tools/golang/Makefile | 33 +
>  tools/golang/xenlight/xenlight.go |  7 +++
>  3 files changed, 56 insertions(+)
>  create mode 100644 tools/golang/Makefile
>  create mode 100644 tools/golang/xenlight/xenlight.go
>
> diff --git a/tools/Makefile b/tools/Makefile
> index 71515b4..f2198e0 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -11,6 +11,8 @@ SUBDIRS-y += misc
>  SUBDIRS-y += examples
>  SUBDIRS-y += hotplug
>  SUBDIRS-y += xentrace
> +SUBDIRS-y += golang
> +#FIXME: Have golang controlled by a configure variable
>  SUBDIRS-$(CONFIG_XCUTILS) += xcutils
>  SUBDIRS-$(CONFIG_X86) += firmware
>  SUBDIRS-y += console
> @@ -311,6 +313,20 @@ subdir-install-debugger/gdbsx: .phony
>  subdir-all-debugger/gdbsx: .phony
> $(MAKE) -C debugger/gdbsx all
>
> +subdir-all-golang/xenlight: .phony
> +   $(MAKE) -C golang all
> +
> +subdir-clean-golang/xenlight: .phony
> +   $(MAKE) -C golang clean
> +
> +subdir-install-golang/xenlight: .phony
> +   $(MAKE) -C golang install
> +
> +subdir-build-golang/xenlight: .phony
> +   $(MAKE) -C golang build
> +
> +subdir-distclean-golang/xenlight: .phony
> +   $(MAKE) -C golang distclean
>
>  subdir-clean-debugger/kdd subdir-distclean-debugger/kdd: .phony
> $(MAKE) -C debugger/kdd clean
> diff --git a/tools/golang/Makefile b/tools/golang/Makefile
> new file mode 100644
> index 000..eead226
> --- /dev/null
> +++ b/tools/golang/Makefile
> @@ -0,0 +1,33 @@
> +XEN_ROOT=$(CURDIR)/../..
> +include $(XEN_ROOT)/tools/Rules.mk
> +
> +BINARY = xenlight.a
> +GO ?= go
> +
> +.PHONY: all
> +all: build
> +
> +.PHONY: build
> +build: xenlight/xenlight.a

I think eventually we'll want to have a makefile in tools/golang which
calls the makefiles in tools/golang/xenlight and other directories;
but since we have only one at the moment, I think this is probably
fine.

> +.PHONY: install
> +install: build
> +   if [ ! -f $(BINARY) ]; then \
> +   mkdir $(GOPATH)/src/xenlight; \
> +   $(INSTALL_PROG) xenlight/xenlight.go 
> $(GOPATH)/src/xenlight/xenlight.go; \
> +   echo "this"; \
> +   fi

A couple of things.

First, as we discussed on IRC, the if[] clause is not necessary --
make will automatically stop if one of the prerequisites isn't
available.

Secondly -- this is a bit confusing, but the "install" section of the
parts of the tree that actually build things don't install files
directly onto the host filesystem.  Instead, they install into
$(DESTDIR) (which is xen.git/dist/install), and then the final step of
"make install" will copy everything from dist/install into the host
filesystem.

Also, you shouldn't do a plain mkdir, but should use $(INSTALL_DIR).
And since the file you're installing is not going to be executed, you
should use $(INSTALL_DATA).  (I didn't realize that distinction
existed until I looked at tools/libxl/Makefile).

So this should look more like:

install: build
  $(INSTALL_DIR) $(DESTDIR)$(GOLANG_SRC)
  $(INSTALL_DATA) xenlight/xenlight.go $(DESTDIR)$(GOLANG_SRC)

And we want the package name to be "xenproject.org/xenlight", so that
we can put up a repo at git://xenproject.org/xenlight and have people
download it automatically.  So GOLANG_SRC should be set by default to
$(GOPATH)/src/xenproject.org/xenlight

With that done I think we might be ready to add some golang code. :-)

 -George

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

Re: [Xen-devel] [PATCH RFC] tools/xenlight: Create xenlight Makefile

[George Dunlap]

> On Dec 16, 2016, at 11:20 AM, Doug Goldstein  wrote:
> 
> On 12/15/16 5:20 PM, Ronald Rojas wrote:
>> Create a basic Makefile to build and install libxenlight Golang
>> bindings.  Also add a template.
>> 
>> ---
>> 
>> Eventually this patch will contain the actual bindings package; for
>> now it just includes a stub package.
>> 
> 
> So I'm curious why the interest to include Golang bindings in the tree.
> Most people are going to expect a Go package to behave like any other go
> package and be able to grab it with "go get". But by including this in
> the tree I believe that method will not work.

My plan was to name the package such that we could have an 
automatically-mirrored git repo in the expected place; i.e.,

git://xenproject.org/xenlight

The “fetch the tree automatically based on the package name” distribution 
mechanism might be a decent fit for web-based technologies, but I think it’s a 
terrible fit for mature software projects like Xen; and I expect that there 
will be a shift in the next few years as people (re-)discover this.  I want to 
make it work, but I think that should be secondary to actually installing the 
library as a part of installing a Xen package / “make install”.

 -George

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

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

[Henrique de Moraes Holschuh]

On Fri, 16 Dec 2016, Borislav Petkov wrote:
> What for? We don't want to run the microcode loader on xen at all.

Or under KVM, or any other hypervisor, really.

-- 
  Henrique Holschuh

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

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

[Boris Ostrovsky]

On 12/15/2016 06:04 PM, Borislav Petkov wrote:

On Thu, Dec 15, 2016 at 05:56:44PM -0500, Boris Ostrovsky wrote:

With CONFIG_PARAVIRT (which I suspect you don't have on) cpuid() is a
call via a pointer, you can see it, for example, if you disassemble
load_ucode_amd_bsp(). And we don't have paging on yet when we call
load_ucode_amd_bsp (at least in 32-bit mode).


That's a good catch, you can send me that one as a proper patch with a
commit message and so on...


OK, I'll send something tomorrow.




Since this happens during AP bringup PV cpuid is available and can be
checked to see whether we are a guest.


What exactly do I need to check there? CPUID(4), leaf which, reg which?
How do I identify a xen hypervisor properly?


You can use xen_cpuid_base(), for example. It will prevent microcode 
loading for all types of Xen guests (PV, HVM and, in the near future, 
PVH). Which I think is fine. This will require adding a #define for 
xen_cpu_base() for !CONFIG_XEN.


Alternatively, if we think that no guest should ever load microcode, we 
could check for 'x86_hyper != 0'. This will be cleaner but I can't speak 
for KVM/VMware/Hyper-V.


Neither of these solutions will work for load_ucode_bsp() because 
xen_cpuid_base() calls cpuid() (and so we are back to the above bug) and 
x86_hyper is not set yet. This is OK for Xen as PV guests never call 
load_ucode_bsp and HVM/PVH guests should be able to handle MSR accesses.





But I think it may be worthwhile trying to understand why we are
dying, it hasn't happened until now.


What for? We don't want to run the microcode loader on xen at all.


True. But I don't think it's clear that the problem we are seeing is 
Xen-specific.


-boris

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

Re: [Xen-devel] [PATCH RFC] tools/xenlight: Create xenlight Makefile

[Doug Goldstein]

On 12/15/16 5:20 PM, Ronald Rojas wrote:
> Create a basic Makefile to build and install libxenlight Golang
> bindings.  Also add a template.
> 
> ---
> 
> Eventually this patch will contain the actual bindings package; for
> now it just includes a stub package.
> 

So I'm curious why the interest to include Golang bindings in the tree.
Most people are going to expect a Go package to behave like any other go
package and be able to grab it with "go get". But by including this in
the tree I believe that method will not work.

I say this because when I finally get around to making Rust bindings for
Xen, I have no plan to include them in the tree but instead publish them
at crates.io so that they work like every other Rust package.

-- 
Doug Goldstein



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

[Xen-devel] [xen-unstable-smoke test] 103429: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   5 libvirt-buildfail REGR. vs. 103284

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

version targeted for testing:
 xen  eaddbb122e918d0ee61b9572398833661ea93670
baseline version:
 xen  fc9229c4bb35c5474fbc67f78e628dcbcc90afc5

Last test of basis   103284  2016-12-13 19:03:56 Z2 days
Failing since103292  2016-12-13 22:19:08 Z2 days   19 attempts
Testing same since   103417  2016-12-15 18:01:58 Z0 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  Cédric Bosdonnat 
  Haozhong Zhang 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Konrad Rzeszutek Wilk 
  Razvan Cojocaru 
  Ross Lagerwall 
  Stefano Stabellini 
  Suravee Suthikulpanit 
  Tamas K Lengyel 
  Tim Deegan 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  fail
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt 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.

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

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

[Xen-devel] [xen-4.4-testing test] 103365: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-3   20 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 102521
 test-xtf-amd64-amd64-3 31 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 102521
 test-xtf-amd64-amd64-3   42 xtf/test-hvm64-invlpg~shadow fail REGR. vs. 102521
 test-xtf-amd64-amd64-5   52 leak-check/check fail REGR. vs. 102521
 test-xtf-amd64-amd64-4   52 leak-check/check fail REGR. vs. 102521
 test-xtf-amd64-amd64-3   52 leak-check/check fail REGR. vs. 102521
 test-xtf-amd64-amd64-2   52 leak-check/check fail REGR. vs. 102521
 test-xtf-amd64-amd64-1   52 leak-check/check fail REGR. vs. 102521
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
102521
 test-amd64-i386-xend-qemut-winxpsp3  9 windows-install   fail REGR. vs. 102521

Tests which are failing intermittently (not blocking):
 test-amd64-i386-freebsd10-amd64 16 guest-localmigrate/x10 fail in 103311 pass 
in 103365
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 103311 
pass in 103365
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail pass 
in 103311
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail pass in 103311

Regressions which are regarded as allowable (not blocking):
 test-xtf-amd64-amd64-4   16 xtf/test-pv32pae-selftestfail  like 102521
 test-xtf-amd64-amd64-2   16 xtf/test-pv32pae-selftestfail  like 102521
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 102521
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 102521
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 102521

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
 test-xtf-amd64-amd64-4   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-1   10 xtf-fep  fail   never pass
 build-amd64-rumprun   7 xen-buildfail   never pass
 test-xtf-amd64-amd64-1   16 xtf/test-pv32pae-selftestfail   never pass
 test-xtf-amd64-amd64-4   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4 29 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 build-i386-rumprun7 xen-buildfail   never pass
 test-xtf-amd64-amd64-5   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-4 35 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-1 29 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   39 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-xtf-amd64-amd64-1 35 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-3   10 xtf-fep  fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-xtf-amd64-amd64-1   39 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-2   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 29 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2 35 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   39 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5   51 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-4   51 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-3   51 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-2   51 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd   9 

Re: [Xen-devel] [RFC PATCH 21/24] ARM: vITS: handle INVALL command

[Dario Faggioli]

On Wed, 2016-12-14 at 03:39 +0100, George Dunlap wrote:
> > On Dec 10, 2016, at 4:18 AM, Stefano Stabellini  > .org> wrote:
> > > > The issue with spreading interrupts migrations over time is
> > > > that it makes
> > > > interrupt latency less deterministic. It is OK, in the uncommon
> > > > case of
> > > > vCPU migration with interrupts, to take a hit for a short time.
> > > > This
> > > > "hit" can be measured. It can be known. If your workload cannot
> > > > tolerate
> > > > it, vCPUs can be pinned. It should be a rare event anyway. On
> > > > the other
> > > > hand, by spreading interrupts migrations, we make it harder to
> > > > predict
> > > > latency. Aside from determinism, another problem with this
> > > > approach is
> > > > that it ensures that every interrupt assigned to a vCPU will
> > > > first hit
> > > > the wrong pCPU, then it will be moved. It guarantees the worst-
> > > > case
> > > > scenario for interrupt latency for the vCPU that has been
> > > > moved. If we
> > > > migrated all interrupts as soon as possible, we would minimize
> > > > the
> > > > amount of interrupts delivered to the wrong pCPU. Most
> > > > interrupts would
> > > > be delivered to the new pCPU right away, reducing interrupt
> > > > latency.
> 
> Another approach which one might take:
> 3. Eagerly migrate a subset of the interrupts and lazily migrate the
> others.  For instance, we could eagerly migrate all the interrupts
> which have fired since the last vcpu migration.  In a system where
> migrations happen frequently, this should only be a handful; in a
> system that migrates infrequently, this will be more, but it won’t
> matter, because it will happen less often.
> 
Yes, if doable (e.g., I don't know how easy and practical is to know
and keep track of fired interrupts) this looks a good solution to me
too.

> So at the moment, the scheduler already tries to avoid migrating
> things *a little bit* if it can (see migrate_resist).  It’s not clear
> to me at the moment whether this is enough or not.  
>
Well, true, but migration resistance, in Credit2, is just a fixed value
which:
 1. is set at boot time;
 2. is always the same for all vcpus;
 3. is always the same, no matter what a vcpu is doing.

And even if we make it tunable and changeable at runtime (which I
intend to do), it's still something pretty "static" because of 2 and 3.

And even if we make it tunable per-vcpu (which is doable), it would be
rather hard to decide to what value to set it, for each vcpu. And, of
course, 3 would still apply (i.e., it would change according to the
vcpu workload or characteristics).

So, it's guessing. More or less fine grained, but always guessing.

On the other hand, using something proportional to nr. of routed
interrupt as the migration resistance threshold would overcome all 1, 2
and 3. It would give us a migrate_resist value which is adaptive, and
is determined according to actual workload of properties of a specific
vcpu.
Feeding routed interrupt info to the load balancer comes from similar
reasoning (and we actually may want to do both).

FTR, Credit1 has a similar mechanism, i.e., it *even wilded guesses*
whether a vcpu could still have some of its data in cache, and tries
not to migrate it if it's likely (see __csched_vcpu_is_cache_hot()).
We can improve that too, although it is a lot more complex and less
predictable, as usual with Credit1.

> Or to put it a different way — how long should the scheduler try to
> wait before moving one of these vcpus?  
>
Yep, it's similar to the "anticipation" problem in I/O schedulers
(where "excessive seeks" ~= "too frequent migrations").

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

> At the moment I haven’t seen a good way of calculating this.
> 
Exactly, and basing the calculation on the number of routed interrupt
--and, if possible, other metrics too-- could be that "good way" we're
looking for.

It would need experimenting, of course, but I like the idea.

> #3 to me has the feeling of being somewhat more satisfying, but also
> potentially fairly complicated.  Since the scheduler already does
> migration resistance somewhat, #1 would be a simpler to implement in
> the sort run.  If it turns out that #1 has other drawbacks, we can
> implement #3 as and when needed.
> 
> Thoughts?
> 
Yes, we can do things incrementally, which is always good. I like your
#1 proposal because it has the really positive side effect of bringing
us in the camp of adaptive migration resistance, which is something
pretty advanced and pretty cool, if we manage to do it right. :-)

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH v2] xen: sched: removal of redundant check in Credit

[Dario Faggioli]

On Thu, 2016-12-15 at 23:39 +0530, Praveen Kumar wrote:
> The patch gets rid of a redundant check in csched_vcpu_acct. In fact,
> the function is only called from csched_tick, which already checks
> that current is not the idle vcpu. The patch also adds an ASSERT to
> the same effect, in order to make assumption ( i.e., no calling this
> on idle vcpus) even more clear and as a guard for future mis-use.
> 
> Signed-off-by: Praveen Kumar 
> 
This is all good and can have my:

Acked-by: Dario Faggioli 

_HOWEVER_ when I tried to apply the patch directly from this email I
get this:

(Stripping trailing CRs from patch; use --binary to disable.)
checking file xen/common/sched_credit.c
patch:  malformed patch at line 6: unsigned int cpu)

Which I think means that the patch has been corrupted, most likely by
the email program.

This is a common issue, and although it is possible to paste patches in
an email client and teach it not to mangle them, I would say:
 1) it's a very boring thing to do, it does not scale, it's not
    practical when sending patch series and it's not reliable;
 2) I've only done a couple of times at the beginning of my OS 
    contribution history, and would not be able to help on how to make 
    that happen.

For this reason, I encourage you to look at and learn alternative ways 
of submitting patches, like git-send-email. Personally, I use StGit for
development, and it has its own sending patches machinery too.

I think you should send a v3, by using one of these methods (or, in
general, not in a mangled state). When doing that (and if you don't
change anything), you can stick my 'Acked-by:' tag right below your own
'Signed-off-by:'

Thanks and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen/arm: fix rank/vgic locks inversion bug

[Stefano Stabellini]

On Thu, 15 Dec 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 15/12/2016 01:04, Stefano Stabellini wrote:
> > The locking order is: first rank lock, then vgic lock. The order is
> > respected everywhere, except for gic_update_one_lr.
> > 
> > gic_update_one_lr is called with the vgic lock held, but it calls
> > vgic_get_target_vcpu, which tries to obtain the rank lock. This can
> > cause deadlocks.
> > 
> > We already have a version of vgic_get_target_vcpu that doesn't take the
> > rank lock: __vgic_get_target_vcpu. Also the only routine that modify
> > the target vcpu are vgic_store_itargetsr and vgic_store_irouter. They
> > call vgic_migrate_irq, which already take the vgic lock.
> > 
> > Solve the lock inversion problem, by not taking the rank lock in
> > gic_update_one_lr (calling __vgic_get_target_vcpu instead of
> > vgic_get_target_vcpu).
> 
> If I look at the callers of gic_update_one_lr, the function gic_clear_lrs will
> not take the rank lock. So from my understanding nobody will take the rank
> here.
>
> However __vgic_get_target_vcpu has an ASSERT to check whether the rank lock
> has been taken. So who is taking lock for gic_update_one_lr now?

I should have removed the ASSERT - nobody is taking the rank lock now on
the gic_update_one_lr code path.


>  We make this safe, by placing modifications to
> > rank->vcpu within regions protected by the vgic lock.
> 
> This look unsafe to me. The vgic lock is per-vcpu, but rank->vcpu could be
> written/read by any vCPU. So you will never protect rank->vcpu with this lock.
> Did I miss anything?

The vgic lock is per-vcpu, but it is always the vgic lock of the old (old
in the sense, before the interrupt is migrated) vcpu that is taken.

On one hand any vcpu can read/write to itargetsr. Those operations are
protected by the rank lock. However vgic_migrate_irq and writes to
rank->vcpu are protected also by the vgic lock of the old vcpu (first
the rank lock is taken, then the vgic lock of the old vcpu).

gic_update_one_lr doesn't take the rank lock, but it takes the vgic lock
of the old vcpu. We know that it is the old vcpu because it is the one
with the interrupt in question in an LR register. gic_update_one_lr
accesses to rank->vcpu are safe because they are protected by the same
vgic lock.

Does it make sense?



> > 
> > Signed-off-by: Stefano Stabellini 
> > 
> > ---
> > There are supposed to be 2 Coverity IDs associated with this, but the
> > system the currently down.
> 
> I think the 2 Coverity IDs are 1381855 and 1381853.
 


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

[Xen-devel] [xen-unstable-smoke test] 103422: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   5 libvirt-buildfail REGR. vs. 103284

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

version targeted for testing:
 xen  eaddbb122e918d0ee61b9572398833661ea93670
baseline version:
 xen  fc9229c4bb35c5474fbc67f78e628dcbcc90afc5

Last test of basis   103284  2016-12-13 19:03:56 Z2 days
Failing since103292  2016-12-13 22:19:08 Z2 days   18 attempts
Testing same since   103417  2016-12-15 18:01:58 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Cédric Bosdonnat 
  Haozhong Zhang 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Konrad Rzeszutek Wilk 
  Razvan Cojocaru 
  Ross Lagerwall 
  Stefano Stabellini 
  Suravee Suthikulpanit 
  Tamas K Lengyel 
  Tim Deegan 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  fail
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt 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.

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

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

[Xen-devel] [PATCH RFC] tools/xenlight: Create xenlight Makefile

[Ronald Rojas]

Create a basic Makefile to build and install libxenlight Golang
bindings.  Also add a template.

---

Eventually this patch will contain the actual bindings package; for
now it just includes a stub package.

To Do:
- Have configure detect golang bindings properly

CC: xen-devel 
CC: Ian Jackson 
CC: Wei Liu 
CC: George Dunlap 
CC: George Dunlap 
---
 tools/Makefile| 16 
 tools/golang/Makefile | 33 +
 tools/golang/xenlight/xenlight.go |  7 +++
 3 files changed, 56 insertions(+)
 create mode 100644 tools/golang/Makefile
 create mode 100644 tools/golang/xenlight/xenlight.go

diff --git a/tools/Makefile b/tools/Makefile
index 71515b4..f2198e0 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -11,6 +11,8 @@ SUBDIRS-y += misc
 SUBDIRS-y += examples
 SUBDIRS-y += hotplug
 SUBDIRS-y += xentrace
+SUBDIRS-y += golang
+#FIXME: Have golang controlled by a configure variable
 SUBDIRS-$(CONFIG_XCUTILS) += xcutils
 SUBDIRS-$(CONFIG_X86) += firmware
 SUBDIRS-y += console
@@ -311,6 +313,20 @@ subdir-install-debugger/gdbsx: .phony
 subdir-all-debugger/gdbsx: .phony
$(MAKE) -C debugger/gdbsx all
 
+subdir-all-golang/xenlight: .phony
+   $(MAKE) -C golang all
+
+subdir-clean-golang/xenlight: .phony
+   $(MAKE) -C golang clean
+
+subdir-install-golang/xenlight: .phony
+   $(MAKE) -C golang install
+
+subdir-build-golang/xenlight: .phony
+   $(MAKE) -C golang build
+
+subdir-distclean-golang/xenlight: .phony
+   $(MAKE) -C golang distclean
 
 subdir-clean-debugger/kdd subdir-distclean-debugger/kdd: .phony
$(MAKE) -C debugger/kdd clean
diff --git a/tools/golang/Makefile b/tools/golang/Makefile
new file mode 100644
index 000..eead226
--- /dev/null
+++ b/tools/golang/Makefile
@@ -0,0 +1,33 @@
+XEN_ROOT=$(CURDIR)/../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+BINARY = xenlight.a
+GO ?= go
+
+.PHONY: all
+all: build
+
+.PHONY: build
+build: xenlight/xenlight.a
+
+.PHONY: install
+install: build
+   if [ ! -f $(BINARY) ]; then \
+   mkdir $(GOPATH)/src/xenlight; \
+   $(INSTALL_PROG) xenlight/xenlight.go 
$(GOPATH)/src/xenlight/xenlight.go; \
+   echo "this"; \
+   fi  
+
+.PHONY: clean
+clean:
+   $(RM) $(BINARY)
+
+.PHONY: distclean
+distclean: clean
+
+
+xenlight/xenlight.a: xenlight/xenlight.go
+   $(GO) build -o $@ $<
+
+
+-include $(DEPS)
diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
new file mode 100644
index 000..9136676
--- /dev/null
+++ b/tools/golang/xenlight/xenlight.go
@@ -0,0 +1,7 @@
+package xenlight
+
+import "fmt"
+
+func main() {
+   fmt.Println("go")
+}
-- 
2.7.4


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

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

[Borislav Petkov]

On Thu, Dec 15, 2016 at 05:56:44PM -0500, Boris Ostrovsky wrote:
> With CONFIG_PARAVIRT (which I suspect you don't have on) cpuid() is a
> call via a pointer, you can see it, for example, if you disassemble
> load_ucode_amd_bsp(). And we don't have paging on yet when we call
> load_ucode_amd_bsp (at least in 32-bit mode).

That's a good catch, you can send me that one as a proper patch with a
commit message and so on...

> Since this happens during AP bringup PV cpuid is available and can be
> checked to see whether we are a guest.

What exactly do I need to check there? CPUID(4), leaf which, reg which?
How do I identify a xen hypervisor properly?

> But I think it may be worthwhile trying to understand why we are
> dying, it hasn't happened until now.

What for? We don't want to run the microcode loader on xen at all.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

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

Re: [Xen-devel] [PATCH] xen/arm: fix rank/vgic locks inversion bug

[Julien Grall]

Hi Stefano,

On 15/12/2016 01:04, Stefano Stabellini wrote:

The locking order is: first rank lock, then vgic lock. The order is
respected everywhere, except for gic_update_one_lr.

gic_update_one_lr is called with the vgic lock held, but it calls
vgic_get_target_vcpu, which tries to obtain the rank lock. This can
cause deadlocks.

We already have a version of vgic_get_target_vcpu that doesn't take the
rank lock: __vgic_get_target_vcpu. Also the only routine that modify
the target vcpu are vgic_store_itargetsr and vgic_store_irouter. They
call vgic_migrate_irq, which already take the vgic lock.

Solve the lock inversion problem, by not taking the rank lock in
gic_update_one_lr (calling __vgic_get_target_vcpu instead of
vgic_get_target_vcpu).


If I look at the callers of gic_update_one_lr, the function 
gic_clear_lrs will not take the rank lock. So from my understanding 
nobody will take the rank here.


However __vgic_get_target_vcpu has an ASSERT to check whether the rank 
lock has been taken. So who is taking lock for gic_update_one_lr now?


 We make this safe, by placing modifications to

rank->vcpu within regions protected by the vgic lock.


This look unsafe to me. The vgic lock is per-vcpu, but rank->vcpu could 
be written/read by any vCPU. So you will never protect rank->vcpu with 
this lock. Did I miss anything?




Signed-off-by: Stefano Stabellini 

---
There are supposed to be 2 Coverity IDs associated with this, but the
system the currently down.


I think the 2 Coverity IDs are 1381855 and 1381853.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

[Boris Ostrovsky]

On 12/15/2016 03:03 PM, Borislav Petkov wrote:
> On Thu, Dec 15, 2016 at 02:36:46PM -0500, Boris Ostrovsky wrote:
>> We are calling find_proper_container(..., _id) and determine result
>> based on eq_id not being zero. If find_proper_container() doesn't find
>> anything it will not modify eq_id and so you get back whatever you
>> passed in.
> The correct fix for that is to not return struct container at all from
> those functions but simply an eq_id or even an int error value or so.
> Passing back a struct is simply silly. I'll prep a proper patch for
> that.
>
>> The fact that  I am having problems with HVM may or may not have
>> anything to do with microcode. I don't know yet but it's separate from
>> save_microcode_in_initrd_amd() patch. I am pretty sure about that
>> because unlike PV it is failing in early boot code.

For AMD you also need something like:

--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -297,6 +297,7 @@ void __init load_ucode_amd_bsp(unsigned int family)
struct cpio_data cp;
const char *path;
bool use_pa;
+   u32 eax = 1, ebx, ecx = 0, edx;
 
if (IS_ENABLED(CONFIG_X86_32)) {
uci = (struct ucode_cpu_info
*)__pa_nodebug(ucode_cpu_info);
@@ -315,7 +316,8 @@ void __init load_ucode_amd_bsp(unsigned int family)
return;
 
/* Get BSP's CPUID.EAX(1), needed in load_microcode_amd() */
-   uci->cpu_sig.sig = cpuid_eax(1);
+   native_cpuid(, , , );
+   uci->cpu_sig.sig = eax;
 
apply_microcode_early_amd(cp.data, cp.size, true);
 }


With CONFIG_PARAVIRT (which I suspect you don't have on) cpuid() is a
call via a pointer, you can see it, for example, if you disassemble
load_ucode_amd_bsp(). And we don't have paging on yet when we call
load_ucode_amd_bsp (at least in 32-bit mode).


> I still need a fix for Jürgen's use case where he lands in the
> microcode loader. And that he shouldn't do in the first place when
> running in a xen guest.
>

Since this happens during AP bringup PV cpuid is available and can be
checked to see whether we are a guest.

But I think it may be worthwhile trying to understand why we are dying,
it hasn't happened until now.

-boris


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

Re: [Xen-devel] [XEN VMID PATCH v5 2/2] xen/arm: Add support for 16 bit VMIDs

[Julien Grall]

On 15/12/2016 17:35, Bhupinder Thakur wrote:

Hi Julien,


Hi Bhupinder,


Thanks for the clarification. One more confirmation: When the reviewer
asks you to add the reviewed-by tag to one of the patch in the series
then also the whole series should be resent with just the reviewed-by
tag added to that single patch.


No need, the committer will usually take care of adding the Reviewed-by 
tag while committing the series.


A rule of thumb is anything other than tag (reviewed-by, acked-by,...) 
will require to resend the series. If the patches contains few minor 
errors (e.g typoes), the committer will usually do it for you.


Cheers,

--
Julien Grall

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

[Xen-devel] [xen-unstable-smoke test] 103417: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   5 libvirt-buildfail REGR. vs. 103284

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

version targeted for testing:
 xen  eaddbb122e918d0ee61b9572398833661ea93670
baseline version:
 xen  fc9229c4bb35c5474fbc67f78e628dcbcc90afc5

Last test of basis   103284  2016-12-13 19:03:56 Z2 days
Failing since103292  2016-12-13 22:19:08 Z1 days   17 attempts
Testing same since   103417  2016-12-15 18:01:58 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Cédric Bosdonnat 
  Haozhong Zhang 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Konrad Rzeszutek Wilk 
  Razvan Cojocaru 
  Ross Lagerwall 
  Stefano Stabellini 
  Suravee Suthikulpanit 
  Tamas K Lengyel 
  Tim Deegan 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  fail
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt 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.

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

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

[Xen-devel] [xen-unstable baseline-only test] 68224: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68224 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68224/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-win7-amd64  9 windows-install   fail REGR. vs. 68157

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 68157
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 68157
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 68157
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 68157

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
 build-i386-rumprun6 xen-buildfail   never pass
 build-amd64-rumprun   6 xen-buildfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 xen  fc9229c4bb35c5474fbc67f78e628dcbcc90afc5
baseline version:
 xen  8e4b2676685f50bc26f03b5f62d8b7aea8e69dbf

Last test of basis68157  2016-12-04 15:45:06 Z   11 days
Testing same since68224  2016-12-15 08:47:47 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Andrii Anisov 
  Artem Mygaiev 
  Cedric Bosdonnat 
  Cédric Bosdonnat 
  Daniel De Graaf 
  Daniel Kiper 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Jun Sun 
  Kevin Tian 
  Luwei Kang 
  Oleksandr Tyshchenko 
  Oleksandr Tyshchenko 
  Paul Durrant 
  Peng Fan 
  

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

[Borislav Petkov]

On Thu, Dec 15, 2016 at 02:36:46PM -0500, Boris Ostrovsky wrote:
> We are calling find_proper_container(..., _id) and determine result
> based on eq_id not being zero. If find_proper_container() doesn't find
> anything it will not modify eq_id and so you get back whatever you
> passed in.

The correct fix for that is to not return struct container at all from
those functions but simply an eq_id or even an int error value or so.
Passing back a struct is simply silly. I'll prep a proper patch for
that.

> The fact that  I am having problems with HVM may or may not have
> anything to do with microcode. I don't know yet but it's separate from
> save_microcode_in_initrd_amd() patch. I am pretty sure about that
> because unlike PV it is failing in early boot code.

I still need a fix for Jürgen's use case where he lands in the
microcode loader. And that he shouldn't do in the first place when
running in a xen guest.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

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

[Xen-devel] [xen-4.7-testing test] 103351: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 103163
 test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail in 103270 REGR. vs. 
103163

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail pass in 103270

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 103163
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 103163
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 103163
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 103163
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 103163
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 103163

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

version targeted for testing:
 xen  7a71cea02afe2bf0f04f1cbf91931081dbe9dd76
baseline version:
 xen  4be57d3e41f22387c1bc6b4d4332f857eeea84b8

Last test of basis   103163  2016-12-11 20:46:19 Z3 days
Testing same since   103270  2016-12-13 14:17:36 Z2 days2 attempts


People who touched revisions under test:
  Jan Beulich 
  Juergen Gross 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvops

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

[Boris Ostrovsky]

On 12/15/2016 02:23 PM, Borislav Petkov wrote:
> On Thu, Dec 15, 2016 at 02:08:50PM -0500, Boris Ostrovsky wrote:
>> This fixes my PV boot problem. I am still failing to boot HVM, will
>> need to look at this some more.
> No, no more stabbing in the dark and no more brown paper bags.

This fixes a bug that has nothing to do with Xen.

We are calling find_proper_container(..., _id) and determine result
based on eq_id not being zero. If find_proper_container() doesn't find
anything it will not modify eq_id and so you get back whatever you
passed in.

What the patch that I sent does is no different from how
apply_microcode_early_amd() makes the call to find_proper_container.

The fact that  I am having problems with HVM may or may not have
anything to do with microcode. I don't know yet but it's separate from
save_microcode_in_initrd_amd() patch. I am pretty sure about that
because unlike PV it is failing in early boot code.

-boris

>
> Please check whether CPUID(4) works that early in any xen guest and
> let's add that check to a function which does something like:
>
> bool loader_disabled(void)
> {
>   if (running_on_a_xen_guest)
>   return true;
>
> if (check_loader_disabled_bsp())
> return true;
>
> if (!have_cpuid_p())
> return true;
>
>   return false;
>
> }
>
> and call that at the entry points and be done with it.
>
> Or if there's some other clean method to detect I'm running on a xen
> guest.
>
> Thanks.
>



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

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

[Borislav Petkov]

On Thu, Dec 15, 2016 at 02:08:50PM -0500, Boris Ostrovsky wrote:
> This fixes my PV boot problem. I am still failing to boot HVM, will
> need to look at this some more.

No, no more stabbing in the dark and no more brown paper bags.

Please check whether CPUID(4) works that early in any xen guest and
let's add that check to a function which does something like:

bool loader_disabled(void)
{
if (running_on_a_xen_guest)
return true;

if (check_loader_disabled_bsp())
return true;

if (!have_cpuid_p())
return true;

return false;

}

and call that at the entry points and be done with it.

Or if there's some other clean method to detect I'm running on a xen
guest.

Thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

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

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

[Boris Ostrovsky]

On 12/15/2016 12:36 PM, Borislav Petkov wrote:
> On Thu, Dec 15, 2016 at 12:27:49PM -0500, Boris Ostrovsky wrote:
>> It will probably fix it but I don't think we want this: it's a
>> build-time solution. Most kernels have XEN on even though they are
>> booted bare-metal.
> Lemme tell you want I want: a way to detect I'm running on xen. Does
> CPUID(4) work really early, at load_ucode_bsp() time?
>
> IOW, can I use some of the functionality hypervisor_cpuid_base() uses to
> detect xen and stop loading any further?

I think we need at least

diff --git a/arch/x86/kernel/cpu/microcode/amd.c
b/arch/x86/kernel/cpu/microcode/amd.c
index 6f353bd..383b635 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -427,7 +427,7 @@ int __init save_microcode_in_initrd_amd(unsigned int
fam)
 {
enum ucode_state ret;
int retval = 0;
-   u16 eq_id;
+   u16 eq_id = 0;
 
if (!cont.data) {
if (IS_ENABLED(CONFIG_X86_32) && (cont.size != -1)) {



This fixes my PV boot problem. I am still failing to boot HVM, will need
to look at this some more.

-boris



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

Re: [Xen-devel] [DOC RFC] Heterogeneous Multi Processing Support in Xen

[Dario Faggioli]

On Thu, 2016-12-08 at 11:38 +0100, Juergen Gross wrote:
> So you really solved the following problem in credit2?
> 
> You have three domains with 2 vcpus each and different weights. Run
> them
> on 3 physical cpus with following pinning:
> 
> dom1: pcpu 1 and 2
> dom2: pcpu 2 and 3
> dom3: pcpu 1 and 3
> 
> How do you decide which vcpu to run on which pcpu for how long?
> 
Ok, back to this (sorry, a bit later than how I'd hoped). So, I tried
to think a bit at the described scenario, but could not figure out what
you are hinting at.

There are missing pieces of information, such as what the vcpus do, and
what exactly are the weights (besides than being different).

Therefore, I decided to put together a quick eperiment. I've created
the domains, sat up all their vcpus to run cpu-hog tasks, picked up a
configuration of my choice for the weights, and run them under both
Credit1 and Credit2.

It's a very simple tests, but it will hopefully be helpful in
understanding the situation better.

Here's the result.

On Credit1, equal weigths, unpinned (i.e., plenty of pCPUs available):
 NAME  CPU(%) [1]
 vm1   199.9
 vm2   199.9
 vm3   199.9

Pinning as you suggest (i.e., to 3 pCPUs):
 NAME  CPU(%) [2]
 vm1   149.0
 vm2    66.2
 vm3    84.8

Changing the weights:
 Name  ID Weight  Cap [3]
 vm1   82560
 vm2   95120
 vm3   6   10240
 NAME  CPU(%)
 vm1   100.0
 vm2   100.0
 vm3   100.0

So, here in Credit1, things are ok when there's no pinning in place [1]. As 
soon as we pin, _even_without_ touching the weights [2], things become *crazy*. 
In fact, there's absolutely no reason why CPU% numbers would look like how they 
look in [2].

This does not surprise me much, though. Credit1's load balancer basically moves 
vcpus around in a pseudo random fashion, and having to enforce pinning 
constraints make things even more unpredictable.

Then it comes the amusing part. At this point, I wonder if I haven't done 
something wrong in setting up the experiments... Because things really looks 
too funny. :-O
In fact, for some reasons, changing the weights as shown [3] cause CPU% numbers 
to fluctuate a bit (not visible above) and then to stabilize at 100%. That may 
look like an improvement, but certainly does not reflect the chosen set of 
weights.

So, I'd say you were right. Or, actually, things are even worse than what you 
said: in Credit1, it's not only that pinning and weights does not play well 
together, it's that even pinning alone works pretty bad.


Now, on Credit2, equal weigths, unpinned (i.e., plenty of pCPUs
available):
 NAME  CPU(%) [4]
 vm1   199.9
 vm2   199.9
 vm3   199.9

Pinning as you suggest (i.e., to 3 pCPUs):
 NAME  CPU(%) [5]
 vm1   100.0
 vm2   100.1
 vm3   100.0

Changing the weights:
 Name  ID Weight [6]
 vm1   2256
 vm2   3512
 vm3   6   1024
 NAME  CPU(%)
 vm144.1
 vm287.2
 vm3   168.7

Which looks nearly *perfect* to me. :-)

In fact, with no constraints [4], each VM gets the 200% share it's
asking for.

When only 3 pCPUs can be used, by means of pinning [5], each VM gets
its fair share of 100%.

When setting up weights in such a way that vm2 should get 2x CPU time
than vm1 and vm3 should get 2x CPU time than vm2 [6], things looks,
well, exactly like that! :-P

So, since I did not fully understand the problem, I'm not sure whether
this really answers your question, but it look to me like it actually
could! :-D

For sure, it puts Credit2 in rather a good light :-P.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2] xen: sched: removal of redundant check in Credit

[Praveen Kumar]

The patch gets rid of a redundant check in csched_vcpu_acct. In fact,
the function is only called from csched_tick, which already checks
that current is not the idle vcpu. The patch also adds an ASSERT to
the same effect, in order to make assumption ( i.e., no calling this
on idle vcpus) even more clear and as a guard for future mis-use.

Signed-off-by: Praveen Kumar 

---
Changed since v1:
   * Changelog updated as per the comment.

v2:

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index fc3a321..dfe8545 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -941,6 +941,7 @@ csched_vcpu_acct(struct csched_private *prv,
unsigned int cpu)

 ASSERT( current->processor == cpu );
 ASSERT( svc->sdom != NULL );
+ASSERT( !is_idle_vcpu(svc->vcpu) );

 /*
  * If this VCPU's priority was boosted when it last awoke, reset
it.
@@ -957,8 +958,7 @@ csched_vcpu_acct(struct csched_private *prv,
unsigned int cpu)
 /*
  * Update credits
  */
-if ( !is_idle_vcpu(svc->vcpu) )
-burn_credits(svc, NOW());
+burn_credits(svc, NOW());

 /*
  * Put this VCPU and domain back on the active list if it was

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

Re: [Xen-devel] [PATCH v4 0/4] CPUID-less CPU/sync_core fixes and improvements

[Andy Lutomirski]

On Fri, Dec 9, 2016 at 10:24 AM, Andy Lutomirski  wrote:
> *** PATCHES 1 and 2 MAY BE 4.9 MATERIAL ***
>
> Alan Cox pointed out that the 486 isn't the only supported CPU that
> doesn't have CPUID.  Let's clean up the mess and make everything
> faster while we're at it.
>

Ping?  Any chance of getting these in for 4.10?

--Andy

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

[Xen-devel] [xen-unstable-smoke test] 103412: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   5 libvirt-buildfail REGR. vs. 103284

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

version targeted for testing:
 xen  6e616a3cef4d782253787904bf3d641112eafa14
baseline version:
 xen  fc9229c4bb35c5474fbc67f78e628dcbcc90afc5

Last test of basis   103284  2016-12-13 19:03:56 Z1 days
Failing since103292  2016-12-13 22:19:08 Z1 days   16 attempts
Testing same since   103401  2016-12-15 11:15:56 Z0 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  Cédric Bosdonnat 
  Haozhong Zhang 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Konrad Rzeszutek Wilk 
  Razvan Cojocaru 
  Ross Lagerwall 
  Stefano Stabellini 
  Suravee Suthikulpanit 
  Tamas K Lengyel 
  Tim Deegan 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  fail
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt 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.

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

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

Re: [Xen-devel] [XEN VMID PATCH v5 2/2] xen/arm: Add support for 16 bit VMIDs

[Bhupinder Thakur]

Hi Julien,

Thanks for the clarification. One more confirmation: When the reviewer
asks you to add the reviewed-by tag to one of the patch in the series
then also the whole series should be resent with just the reviewed-by
tag added to that single patch.

Regards,
Bhupinder


On 15 December 2016 at 22:53, Julien Grall  wrote:
>
>
> On 15/12/2016 17:14, Bhupinder Thakur wrote:
>>
>> Hi Julien,
>
>
> Hi Bhupinder,
>
>>
>> I did not send the 1st patch in the series as there is no change in
>> the first patch since the last one I sent. I understood from your last
>> mail that I need not send the patch again if there is no change.
>
>
> You misunderstood what I said:
>
> "No need to resend this series if there are no other comments."
>
> This series is composed of 2 patches. So if you modified one patch in the
> series you have to resend all the patches.
>
> There are an exceptions when a committer has applied a part of the series.
> In this case, you only have to resend those that haven't been committed.
>
> In the case of this series, the first patch was not committed. So you have
> to send the 2 patches.
>
>>
>> Should I send it again after updating the version as 5? Should I add
>> the reviewed-by tag in the first patch in the series?
>
>
> The reviewed-by tag has to be carried across all the version unless the
> patch has been heavily modified or the reviewer explicitly asked to
> withdraw.
>
> My comment on the previous version was only advice for the future on the
> netiquette :).
>
> I would prefer if you resend the series as the committer may not notice that
> there was a first patch.
>
> You don't need to bump the version (i.e v5 -> v6), instead add "RESEND" in
> the tag:
>
> [XEN VMID RESEND v5...]
>
> If you have any doubt how to proceed, feel free to ask it :).
>
> Cheers,
>
> --
> Julien Grall

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

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

[Borislav Petkov]

On Thu, Dec 15, 2016 at 12:27:49PM -0500, Boris Ostrovsky wrote:
> It will probably fix it but I don't think we want this: it's a
> build-time solution. Most kernels have XEN on even though they are
> booted bare-metal.

Lemme tell you want I want: a way to detect I'm running on xen. Does
CPUID(4) work really early, at load_ucode_bsp() time?

IOW, can I use some of the functionality hypervisor_cpuid_base() uses to
detect xen and stop loading any further?

> I meant, for example:
> 
> proc_fam = find_cpu_family_by_equiv_cpu(proc_id);
> if (!proc_fam) {
> pr_err("No patch family for equiv ID: 0x%04x\n", proc_id);
> return crnt_size;
> }
> 
> -boris
> 
> > It returns
> > crnt_size which can be a positive number so that we can advance to the
> > next patch in the blob.
^^^

Read what I wrote here.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

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

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

[Boris Ostrovsky]

On 12/15/2016 12:17 PM, Borislav Petkov wrote:
> On Thu, Dec 15, 2016 at 12:00:22PM -0500, Boris Ostrovsky wrote:
>> There is an error on AMD as well. We end up being called at
>> load_microcode_amd() with size=0 and crash soon after.
> Does that fix it?
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index dd47e60aabf5..e238119b5dff 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1202,6 +1202,7 @@ config X86_REBOOTFIXUPS
>  config MICROCODE
>   bool "CPU microcode loading support"
>   default y
> + depends on !XEN
>   depends on CPU_SUP_AMD || CPU_SUP_INTEL
>   select FW_LOADER
>   ---help---


It will probably fix it but I don't think we want this: it's a
build-time solution. Most kernels have XEN on even though they are
booted bare-metal.

>
>> (As a side note, I think verify_and_add_patch() should return error
>> codes and not crnt_size, which may be a positive number. Which it was in
>> my case.)
> It does return negative values when there's some failure. 

I meant, for example:

proc_fam = find_cpu_family_by_equiv_cpu(proc_id);
if (!proc_fam) {
pr_err("No patch family for equiv ID: 0x%04x\n", proc_id);
return crnt_size;
}

-boris

> It returns
> crnt_size which can be a positive number so that we can advance to the
> next patch in the blob.
>


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

Re: [Xen-devel] [XEN VMID PATCH v5 2/2] xen/arm: Add support for 16 bit VMIDs

[Julien Grall]

On 15/12/2016 17:14, Bhupinder Thakur wrote:

Hi Julien,


Hi Bhupinder,



I did not send the 1st patch in the series as there is no change in
the first patch since the last one I sent. I understood from your last
mail that I need not send the patch again if there is no change.


You misunderstood what I said:

"No need to resend this series if there are no other comments."

This series is composed of 2 patches. So if you modified one patch in 
the series you have to resend all the patches.


There are an exceptions when a committer has applied a part of the 
series. In this case, you only have to resend those that haven't been 
committed.


In the case of this series, the first patch was not committed. So you 
have to send the 2 patches.




Should I send it again after updating the version as 5? Should I add
the reviewed-by tag in the first patch in the series?


The reviewed-by tag has to be carried across all the version unless the 
patch has been heavily modified or the reviewer explicitly asked to 
withdraw.


My comment on the previous version was only advice for the future on the 
netiquette :).


I would prefer if you resend the series as the committer may not notice 
that there was a first patch.


You don't need to bump the version (i.e v5 -> v6), instead add "RESEND" 
in the tag:


[XEN VMID RESEND v5...]

If you have any doubt how to proceed, feel free to ask it :).

Cheers,

--
Julien Grall

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

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

[Borislav Petkov]

On Thu, Dec 15, 2016 at 12:00:22PM -0500, Boris Ostrovsky wrote:
> There is an error on AMD as well. We end up being called at
> load_microcode_amd() with size=0 and crash soon after.

Does that fix it?

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index dd47e60aabf5..e238119b5dff 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1202,6 +1202,7 @@ config X86_REBOOTFIXUPS
 config MICROCODE
bool "CPU microcode loading support"
default y
+   depends on !XEN
depends on CPU_SUP_AMD || CPU_SUP_INTEL
select FW_LOADER
---help---

> (As a side note, I think verify_and_add_patch() should return error
> codes and not crnt_size, which may be a positive number. Which it was in
> my case.)

It does return negative values when there's some failure. It returns
crnt_size which can be a positive number so that we can advance to the
next patch in the blob.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

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

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

[Borislav Petkov]

On Thu, Dec 15, 2016 at 04:59:49PM +, Andrew Cooper wrote:
> Xen has the same logic as Linux does to look for an uncompressed
> microcode blob in the initrd and apply it early in boot.
> 
> If dom0 goes looking, it should see the same microcode version as it has
> in its initrd.

So it sounds to me like I wanna do this:

---
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index dd47e60aabf5..e238119b5dff 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1202,6 +1202,7 @@ config X86_REBOOTFIXUPS
 config MICROCODE
bool "CPU microcode loading support"
default y
+   depends on !XEN
depends on CPU_SUP_AMD || CPU_SUP_INTEL
select FW_LOADER
---help---
--

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

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

Re: [Xen-devel] [XEN VMID PATCH v5 2/2] xen/arm: Add support for 16 bit VMIDs

[Bhupinder Thakur]

Hi Julien,

I did not send the 1st patch in the series as there is no change in
the first patch since the last one I sent. I understood from your last
mail that I need not send the patch again if there is no change.

Should I send it again after updating the version as 5? Should I add
the reviewed-by tag in the first patch in the series?

Regards,
Bhupinder

On 15 December 2016 at 22:32, Julien Grall  wrote:
> Hi,
>
> The patch indicates "2/2" but I can't find the first patch. Is it a mistake?
>
> Cheers,
>
>
> On 15/12/2016 16:55, Bhupinder Thakur wrote:
>>
>> VMID space is increased to 16-bits from 8-bits in ARMv8 8.1 revision.
>> This allows more than 256 VMs to be supported by Xen.
>>
>> This change adds support for 16-bit VMIDs in Xen based on whether the
>> architecture supports it.
>>
>> Signed-off-by: Bhupinder Thakur 
>> ---
>>  xen/arch/arm/p2m.c  | 52
>> ++---
>>  xen/include/asm-arm/p2m.h   |  2 +-
>>  xen/include/asm-arm/processor.h | 18 +-
>>  3 files changed, 62 insertions(+), 10 deletions(-)
>>
>> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
>> index 6930f8c..61b9e49 100644
>> --- a/xen/arch/arm/p2m.c
>> +++ b/xen/arch/arm/p2m.c
>> @@ -7,6 +7,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -14,15 +15,25 @@
>>  #include 
>>  #include 
>>
>> +#define MAX_VMID_8_BIT  (1UL << 8)
>> +#define MAX_VMID_16_BIT (1UL << 16)
>> +
>> +#define INVALID_VMID 0 /* VMID 0 is reserved */
>> +
>>  #ifdef CONFIG_ARM_64
>>  static unsigned int __read_mostly p2m_root_order;
>>  static unsigned int __read_mostly p2m_root_level;
>>  #define P2M_ROOT_ORDERp2m_root_order
>>  #define P2M_ROOT_LEVEL p2m_root_level
>> +static unsigned int __read_mostly max_vmid = MAX_VMID_8_BIT;
>> +/* VMID is by default 8 bit width on AArch64 */
>> +#define MAX_VMID   max_vmid
>>  #else
>>  /* First level P2M is alway 2 consecutive pages */
>>  #define P2M_ROOT_LEVEL 1
>>  #define P2M_ROOT_ORDER1
>> +/* VMID is always 8 bit width on AArch32 */
>> +#define MAX_VMIDMAX_VMID_8_BIT
>>  #endif
>>
>>  #define P2M_ROOT_PAGES(1<> @@ -1217,7 +1228,7 @@ static int p2m_alloc_table(struct domain *d)
>>
>>  p2m->root = page;
>>
>> -p2m->vttbr = page_to_maddr(p2m->root) | ((uint64_t)p2m->vmid & 0xff)
>> << 48;
>> +p2m->vttbr = page_to_maddr(p2m->root) | ((uint64_t)p2m->vmid << 48);
>>
>>  /*
>>   * Make sure that all TLBs corresponding to the new VMID are flushed
>> @@ -1228,19 +1239,27 @@ static int p2m_alloc_table(struct domain *d)
>>  return 0;
>>  }
>>
>> -#define MAX_VMID 256
>> -#define INVALID_VMID 0 /* VMID 0 is reserved */
>>
>>  static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
>>
>>  /*
>> - * VTTBR_EL2 VMID field is 8 bits. Using a bitmap here limits us to
>> - * 256 concurrent domains.
>> + * VTTBR_EL2 VMID field is 8 or 16 bits. AArch64 may support 16-bit VMID.
>> + * Using a bitmap here limits us to 256 or 65536 (for AArch64) concurrent
>> + * domains. The bitmap space will be allocated dynamically based on
>> + * whether 8 or 16 bit VMIDs are supported.
>>   */
>> -static DECLARE_BITMAP(vmid_mask, MAX_VMID);
>> +static unsigned long *vmid_mask;
>>
>>  static void p2m_vmid_allocator_init(void)
>>  {
>> +/*
>> + * allocate space for vmid_mask based on MAX_VMID
>> + */
>> +vmid_mask = xzalloc_array(unsigned long, BITS_TO_LONGS(MAX_VMID));
>> +
>> +if ( !vmid_mask )
>> +panic("Could not allocate VMID bitmap space");
>> +
>>  set_bit(INVALID_VMID, vmid_mask);
>>  }
>>
>> @@ -1630,20 +1649,36 @@ void __init setup_virt_paging(void)
>>
>>  unsigned int cpu;
>>  unsigned int pa_range = 0x10; /* Larger than any possible value */
>> +bool vmid_8_bit = false;
>>
>>  for_each_online_cpu ( cpu )
>>  {
>>  const struct cpuinfo_arm *info = _data[cpu];
>>  if ( info->mm64.pa_range < pa_range )
>>  pa_range = info->mm64.pa_range;
>> +
>> +/* Set a flag if the current cpu does not support 16 bit VMIDs.
>> */
>> +if ( info->mm64.vmid_bits != MM64_VMID_16_BITS_SUPPORT )
>> +vmid_8_bit = true;
>>  }
>>
>> +/*
>> + * If the flag is not set then it means all CPUs support 16-bit
>> + * VMIDs.
>> + */
>> +if ( !vmid_8_bit )
>> +max_vmid = MAX_VMID_16_BIT;
>> +
>>  /* pa_range is 4 bits, but the defined encodings are only 3 bits */
>>  if ( pa_range >= ARRAY_SIZE(pa_range_info) ||
>> !pa_range_info[pa_range].pabits )
>>  panic("Unknown encoding of ID_AA64MMFR0_EL1.PARange %x\n",
>> pa_range);
>>
>>  val |= VTCR_PS(pa_range);
>>  val |= VTCR_TG0_4K;
>> +
>> +/* Set the VS bit only if 16 bit VMID is supported. */
>> +if ( MAX_VMID == MAX_VMID_16_BIT )
>> +val |= VTCR_VS;
>>  val |= VTCR_SL0(pa_range_info[pa_range].sl0);
>>  

[Xen-devel] [PATCH v2] x86/emul: Simplfy L{ES, DS, SS, FS, GS} handling

[Andrew Cooper]

%ss, %fs and %gs can be calculated by directly masking the opcode.  %es and
%ds cant, but the calculation isn't hard.

Use seg rather than dst.val for storing the calculated segment, which is
appropriately typed.  Drop the sel local variable entirely and use dst.val
instead.  The mode_64bit() check can be repositioned and simplified to drop
the ext check.  Replace opencoding of X86EMUL_OKAY.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 

v2:
 * Drop the sel local variable entirely.
 * Move the lss/fs/gs cases back to their original location.
---
 xen/arch/x86/x86_emulate/x86_emulate.c | 32 +++-
 1 file changed, 11 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
b/xen/arch/x86/x86_emulate/x86_emulate.c
index dfdcd6c..4753d0a 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -3397,24 +3397,20 @@ x86_emulate(
 _regs.eip = dst.val;
 break;
 
-case 0xc4: /* les */ {
-unsigned long sel;
-dst.val = x86_seg_es;
-les: /* dst.val identifies the segment */
-generate_exception_if(mode_64bit() && !ext, EXC_UD);
+case 0xc4: /* les */
+case 0xc5: /* lds */
+generate_exception_if(mode_64bit(), EXC_UD);
+seg = (b & 1) * 3; /* es = 0, ds = 3 */
+les:
 generate_exception_if(src.type != OP_MEM, EXC_UD);
 if ( (rc = read_ulong(src.mem.seg, src.mem.off + src.bytes,
-  , 2, ctxt, ops)) != 0 )
+  , 2, ctxt, ops)) != X86EMUL_OKAY )
 goto done;
-if ( (rc = load_seg(dst.val, sel, 0, NULL, ctxt, ops)) != 0 )
+ASSERT(is_x86_user_segment(seg));
+if ( (rc = load_seg(seg, dst.val, 0, NULL, ctxt, ops)) != X86EMUL_OKAY 
)
 goto done;
 dst.val = src.val;
 break;
-}
-
-case 0xc5: /* lds */
-dst.val = x86_seg_ds;
-goto les;
 
 case 0xc8: /* enter imm16,imm8 */ {
 uint8_t depth = imm2 & 31;
@@ -5233,21 +5229,15 @@ x86_emulate(
 break;
 
 case X86EMUL_OPC(0x0f, 0xb2): /* lss */
-dst.val = x86_seg_ss;
+case X86EMUL_OPC(0x0f, 0xb4): /* lfs */
+case X86EMUL_OPC(0x0f, 0xb5): /* lgs */
+seg = b & 7;
 goto les;
 
 case X86EMUL_OPC(0x0f, 0xb3): btr: /* btr */
 emulate_2op_SrcV_nobyte("btr", src, dst, _regs.eflags);
 break;
 
-case X86EMUL_OPC(0x0f, 0xb4): /* lfs */
-dst.val = x86_seg_fs;
-goto les;
-
-case X86EMUL_OPC(0x0f, 0xb5): /* lgs */
-dst.val = x86_seg_gs;
-goto les;
-
 case X86EMUL_OPC(0x0f, 0xb6): /* movzx rm8,r{16,32,64} */
 /* Recompute DstReg as we may have decoded AH/BH/CH/DH. */
 dst.reg   = decode_register(modrm_reg, &_regs, 0);
-- 
2.1.4


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

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

[Juergen Gross]

On 15/12/16 17:46, Borislav Petkov wrote:
> On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote:
>> with today's kernel the system isn't coming up when booted as Xen dom0:
> 
> Remind me again pls, is dom0 even supposed to load microcode? Isn't the
> hypervisor supposed to apply microcode?
> 
>> Looking into the state of cpu 1 I find the following backtrace (created
>> manually by looking up addresses from a stack dump retrieved from the
>> hypervisor):
>>
>> find_cpio_data()
>> find_microcode_in_initrd()
>> __load_ucode_intel()
>> load_ucode_intel_ap()
>> cpu_init()
>> cpu_bringup()
>> cpu_bringup_and_idle()
>>
>> It seems as if load_ucode_intel_ap() is looping. You introduced a
>> possibly endless loop in it with commit fe055896.
> 
> Are you sure you mean:
> 
>   fe055896c040 ("x86/microcode: Merge the early microcode loader")
> 
> because that commit is a year old.

OMG. Sorry, somehow I managed to read the date of that patch wrong.

> So from looking at the *current* code:
> 
>   if (apply_microcode_early(, true)) {
> 
> fails probably because MSR_IA32_UCODE_REV doesn't get read properly due
> to virtualized MSRs, bla, yadda yadda...

I'll check.

BTW: Adding a retry count doesn't help. Just tried.

> But before we debug this further, I'd like to make sure I'm debugging
> the proper thing and not some situation again where xen wasn't even
> supposed to run the microcode loader but it does it anyway...

I guess this might be the case.


Juergen


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

Re: [Xen-devel] [XEN VMID PATCH v5 2/2] xen/arm: Add support for 16 bit VMIDs

[Julien Grall]

Hi,

The patch indicates "2/2" but I can't find the first patch. Is it a mistake?

Cheers,

On 15/12/2016 16:55, Bhupinder Thakur wrote:

VMID space is increased to 16-bits from 8-bits in ARMv8 8.1 revision.
This allows more than 256 VMs to be supported by Xen.

This change adds support for 16-bit VMIDs in Xen based on whether the
architecture supports it.

Signed-off-by: Bhupinder Thakur 
---
 xen/arch/arm/p2m.c  | 52 ++---
 xen/include/asm-arm/p2m.h   |  2 +-
 xen/include/asm-arm/processor.h | 18 +-
 3 files changed, 62 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 6930f8c..61b9e49 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -14,15 +15,25 @@
 #include 
 #include 

+#define MAX_VMID_8_BIT  (1UL << 8)
+#define MAX_VMID_16_BIT (1UL << 16)
+
+#define INVALID_VMID 0 /* VMID 0 is reserved */
+
 #ifdef CONFIG_ARM_64
 static unsigned int __read_mostly p2m_root_order;
 static unsigned int __read_mostly p2m_root_level;
 #define P2M_ROOT_ORDERp2m_root_order
 #define P2M_ROOT_LEVEL p2m_root_level
+static unsigned int __read_mostly max_vmid = MAX_VMID_8_BIT;
+/* VMID is by default 8 bit width on AArch64 */
+#define MAX_VMID   max_vmid
 #else
 /* First level P2M is alway 2 consecutive pages */
 #define P2M_ROOT_LEVEL 1
 #define P2M_ROOT_ORDER1
+/* VMID is always 8 bit width on AArch32 */
+#define MAX_VMIDMAX_VMID_8_BIT
 #endif

 #define P2M_ROOT_PAGES(1<root = page;

-p2m->vttbr = page_to_maddr(p2m->root) | ((uint64_t)p2m->vmid & 0xff) << 48;
+p2m->vttbr = page_to_maddr(p2m->root) | ((uint64_t)p2m->vmid << 48);

 /*
  * Make sure that all TLBs corresponding to the new VMID are flushed
@@ -1228,19 +1239,27 @@ static int p2m_alloc_table(struct domain *d)
 return 0;
 }

-#define MAX_VMID 256
-#define INVALID_VMID 0 /* VMID 0 is reserved */

 static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;

 /*
- * VTTBR_EL2 VMID field is 8 bits. Using a bitmap here limits us to
- * 256 concurrent domains.
+ * VTTBR_EL2 VMID field is 8 or 16 bits. AArch64 may support 16-bit VMID.
+ * Using a bitmap here limits us to 256 or 65536 (for AArch64) concurrent
+ * domains. The bitmap space will be allocated dynamically based on
+ * whether 8 or 16 bit VMIDs are supported.
  */
-static DECLARE_BITMAP(vmid_mask, MAX_VMID);
+static unsigned long *vmid_mask;

 static void p2m_vmid_allocator_init(void)
 {
+/*
+ * allocate space for vmid_mask based on MAX_VMID
+ */
+vmid_mask = xzalloc_array(unsigned long, BITS_TO_LONGS(MAX_VMID));
+
+if ( !vmid_mask )
+panic("Could not allocate VMID bitmap space");
+
 set_bit(INVALID_VMID, vmid_mask);
 }

@@ -1630,20 +1649,36 @@ void __init setup_virt_paging(void)

 unsigned int cpu;
 unsigned int pa_range = 0x10; /* Larger than any possible value */
+bool vmid_8_bit = false;

 for_each_online_cpu ( cpu )
 {
 const struct cpuinfo_arm *info = _data[cpu];
 if ( info->mm64.pa_range < pa_range )
 pa_range = info->mm64.pa_range;
+
+/* Set a flag if the current cpu does not support 16 bit VMIDs. */
+if ( info->mm64.vmid_bits != MM64_VMID_16_BITS_SUPPORT )
+vmid_8_bit = true;
 }

+/*
+ * If the flag is not set then it means all CPUs support 16-bit
+ * VMIDs.
+ */
+if ( !vmid_8_bit )
+max_vmid = MAX_VMID_16_BIT;
+
 /* pa_range is 4 bits, but the defined encodings are only 3 bits */
 if ( pa_range >= ARRAY_SIZE(pa_range_info) || 
!pa_range_info[pa_range].pabits )
 panic("Unknown encoding of ID_AA64MMFR0_EL1.PARange %x\n", pa_range);

 val |= VTCR_PS(pa_range);
 val |= VTCR_TG0_4K;
+
+/* Set the VS bit only if 16 bit VMID is supported. */
+if ( MAX_VMID == MAX_VMID_16_BIT )
+val |= VTCR_VS;
 val |= VTCR_SL0(pa_range_info[pa_range].sl0);
 val |= VTCR_T0SZ(pa_range_info[pa_range].t0sz);

@@ -1651,9 +1686,10 @@ void __init setup_virt_paging(void)
 p2m_root_level = 2 - pa_range_info[pa_range].sl0;
 p2m_ipa_bits = 64 - pa_range_info[pa_range].t0sz;

-printk("P2M: %d-bit IPA with %d-bit PA\n",
+printk("P2M: %d-bit IPA with %d-bit PA and %d-bit VMID\n",
p2m_ipa_bits,
-   pa_range_info[pa_range].pabits);
+   pa_range_info[pa_range].pabits,
+   ( MAX_VMID == MAX_VMID_16_BIT )?16:8);
 #endif
 printk("P2M: %d levels with order-%d root, VTCR 0x%lx\n",
4 - P2M_ROOT_LEVEL, P2M_ROOT_ORDER, val);
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 0987be2..9de55fc 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -30,7 +30,7 @@ struct p2m_domain {
 struct 

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

[Andrew Cooper]

On 15/12/16 16:53, Jan Beulich wrote:
 On 15.12.16 at 17:46,  wrote:
>> On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote:
>>> with today's kernel the system isn't coming up when booted as Xen dom0:
>> Remind me again pls, is dom0 even supposed to load microcode? Isn't the
>> hypervisor supposed to apply microcode?
> Yes, it's the hypervisor. Dom0 can at best hand the blob to it via
> hypercall, but iirc upstream Linux doesn't make use of that.

Xen has the same logic as Linux does to look for an uncompressed
microcode blob in the initrd and apply it early in boot.

If dom0 goes looking, it should see the same microcode version as it has
in its initrd.

~Andrew

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

[Xen-devel] [XEN VMID PATCH v5 2/2] xen/arm: Add support for 16 bit VMIDs

[Bhupinder Thakur]

VMID space is increased to 16-bits from 8-bits in ARMv8 8.1 revision.
This allows more than 256 VMs to be supported by Xen.

This change adds support for 16-bit VMIDs in Xen based on whether the
architecture supports it.

Signed-off-by: Bhupinder Thakur 
---
 xen/arch/arm/p2m.c  | 52 ++---
 xen/include/asm-arm/p2m.h   |  2 +-
 xen/include/asm-arm/processor.h | 18 +-
 3 files changed, 62 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 6930f8c..61b9e49 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -14,15 +15,25 @@
 #include 
 #include 
 
+#define MAX_VMID_8_BIT  (1UL << 8)
+#define MAX_VMID_16_BIT (1UL << 16)
+
+#define INVALID_VMID 0 /* VMID 0 is reserved */
+
 #ifdef CONFIG_ARM_64
 static unsigned int __read_mostly p2m_root_order;
 static unsigned int __read_mostly p2m_root_level;
 #define P2M_ROOT_ORDERp2m_root_order
 #define P2M_ROOT_LEVEL p2m_root_level
+static unsigned int __read_mostly max_vmid = MAX_VMID_8_BIT;
+/* VMID is by default 8 bit width on AArch64 */
+#define MAX_VMID   max_vmid
 #else
 /* First level P2M is alway 2 consecutive pages */
 #define P2M_ROOT_LEVEL 1
 #define P2M_ROOT_ORDER1
+/* VMID is always 8 bit width on AArch32 */
+#define MAX_VMIDMAX_VMID_8_BIT
 #endif
 
 #define P2M_ROOT_PAGES(1<root = page;
 
-p2m->vttbr = page_to_maddr(p2m->root) | ((uint64_t)p2m->vmid & 0xff) << 48;
+p2m->vttbr = page_to_maddr(p2m->root) | ((uint64_t)p2m->vmid << 48);
 
 /*
  * Make sure that all TLBs corresponding to the new VMID are flushed
@@ -1228,19 +1239,27 @@ static int p2m_alloc_table(struct domain *d)
 return 0;
 }
 
-#define MAX_VMID 256
-#define INVALID_VMID 0 /* VMID 0 is reserved */
 
 static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
 
 /*
- * VTTBR_EL2 VMID field is 8 bits. Using a bitmap here limits us to
- * 256 concurrent domains.
+ * VTTBR_EL2 VMID field is 8 or 16 bits. AArch64 may support 16-bit VMID.
+ * Using a bitmap here limits us to 256 or 65536 (for AArch64) concurrent
+ * domains. The bitmap space will be allocated dynamically based on
+ * whether 8 or 16 bit VMIDs are supported.
  */
-static DECLARE_BITMAP(vmid_mask, MAX_VMID);
+static unsigned long *vmid_mask;
 
 static void p2m_vmid_allocator_init(void)
 {
+/*
+ * allocate space for vmid_mask based on MAX_VMID
+ */
+vmid_mask = xzalloc_array(unsigned long, BITS_TO_LONGS(MAX_VMID));
+
+if ( !vmid_mask )
+panic("Could not allocate VMID bitmap space");
+
 set_bit(INVALID_VMID, vmid_mask);
 }
 
@@ -1630,20 +1649,36 @@ void __init setup_virt_paging(void)
 
 unsigned int cpu;
 unsigned int pa_range = 0x10; /* Larger than any possible value */
+bool vmid_8_bit = false;
 
 for_each_online_cpu ( cpu )
 {
 const struct cpuinfo_arm *info = _data[cpu];
 if ( info->mm64.pa_range < pa_range )
 pa_range = info->mm64.pa_range;
+
+/* Set a flag if the current cpu does not support 16 bit VMIDs. */
+if ( info->mm64.vmid_bits != MM64_VMID_16_BITS_SUPPORT )
+vmid_8_bit = true;
 }
 
+/*
+ * If the flag is not set then it means all CPUs support 16-bit
+ * VMIDs.
+ */
+if ( !vmid_8_bit )
+max_vmid = MAX_VMID_16_BIT;
+
 /* pa_range is 4 bits, but the defined encodings are only 3 bits */
 if ( pa_range >= ARRAY_SIZE(pa_range_info) || 
!pa_range_info[pa_range].pabits )
 panic("Unknown encoding of ID_AA64MMFR0_EL1.PARange %x\n", pa_range);
 
 val |= VTCR_PS(pa_range);
 val |= VTCR_TG0_4K;
+
+/* Set the VS bit only if 16 bit VMID is supported. */
+if ( MAX_VMID == MAX_VMID_16_BIT )
+val |= VTCR_VS;
 val |= VTCR_SL0(pa_range_info[pa_range].sl0);
 val |= VTCR_T0SZ(pa_range_info[pa_range].t0sz);
 
@@ -1651,9 +1686,10 @@ void __init setup_virt_paging(void)
 p2m_root_level = 2 - pa_range_info[pa_range].sl0;
 p2m_ipa_bits = 64 - pa_range_info[pa_range].t0sz;
 
-printk("P2M: %d-bit IPA with %d-bit PA\n",
+printk("P2M: %d-bit IPA with %d-bit PA and %d-bit VMID\n",
p2m_ipa_bits,
-   pa_range_info[pa_range].pabits);
+   pa_range_info[pa_range].pabits,
+   ( MAX_VMID == MAX_VMID_16_BIT )?16:8);
 #endif
 printk("P2M: %d levels with order-%d root, VTCR 0x%lx\n",
4 - P2M_ROOT_LEVEL, P2M_ROOT_ORDER, val);
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 0987be2..9de55fc 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -30,7 +30,7 @@ struct p2m_domain {
 struct page_info *root;
 
 /* Current VMID in use */
-uint8_t vmid;
+uint16_t vmid;
 
 /* Current Translation 

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

[Boris Ostrovsky]

On 12/15/2016 11:46 AM, Borislav Petkov wrote:
> On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote:
>> with today's kernel the system isn't coming up when booted as Xen dom0:
> Remind me again pls, is dom0 even supposed to load microcode? Isn't the
> hypervisor supposed to apply microcode?
>
>> Looking into the state of cpu 1 I find the following backtrace (created
>> manually by looking up addresses from a stack dump retrieved from the
>> hypervisor):
>>
>> find_cpio_data()
>> find_microcode_in_initrd()
>> __load_ucode_intel()
>> load_ucode_intel_ap()
>> cpu_init()
>> cpu_bringup()
>> cpu_bringup_and_idle()
>>
>> It seems as if load_ucode_intel_ap() is looping. You introduced a
>> possibly endless loop in it with commit fe055896.
> Are you sure you mean:
>
>   fe055896c040 ("x86/microcode: Merge the early microcode loader")
>
> because that commit is a year old.
>
> So from looking at the *current* code:
>
>   if (apply_microcode_early(, true)) {
>
> fails probably because MSR_IA32_UCODE_REV doesn't get read properly due
> to virtualized MSRs, bla, yadda yadda...
>
> But before we debug this further, I'd like to make sure I'm debugging
> the proper thing and not some situation again where xen wasn't even
> supposed to run the microcode loader but it does it anyway...
>

There is an error on AMD as well. We end up being called at
load_microcode_amd() with size=0 and crash soon after.

(As a side note, I think verify_and_add_patch() should return error
codes and not crnt_size, which may be a positive number. Which it was in
my case.)

-boris


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

Re: [Xen-devel] Intel board support for xen

[George John]

ok thank you very much


On Tuesday, December 13, 2016, Konrad Rzeszutek Wilk 
wrote:

> On Tue, Dec 13, 2016 at 10:58:53AM +0530, George John wrote:
> > no, I meant some embedded platform like say for example minnowboard. Any
> > other boards like minnowboard?
>
> Based n
> https://ark.intel.com/products/78477/Intel-Atom-
> Processor-E3826-1M-Cache-1_46-GHz
>
> It has 64-bit support so you are all good.
> >
> > thanks and regards,
> > George
> >
> > On Mon, Dec 12, 2016 at 8:11 PM, Konrad Rzeszutek Wilk <
> > konrad.w...@oracle.com > wrote:
> >
> > > On Mon, Dec 12, 2016 at 12:56:32PM +0530, George John wrote:
> > > > hi,
> > > >
> > > > Thanks for the reply. I want to bring up xen on an intel embedded
> > > >  development platform. I am going to buy one. Can you suggest a intel
> > > > development platform for embedded applications on which xen could
> work?
> > >
> > > Um, your laptop? You desktop?
> > > >
> > > > Thanks and regards,
> > > > George
> > > >
> > > >
> > > > On Friday, December 9, 2016, Konrad Rzeszutek Wilk <
> > > konrad.w...@oracle.com >
> > > > wrote:
> > > >
> > > > > On Fri, Dec 09, 2016 at 06:40:07PM +0530, George John wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > I am a newbie in xen. I wish to know which all intel platforms
> > > support
> > > > > xen
> > > > > > hypervisor?.
> > > > >
> > > > > All the ones that can do 64-bit mode.
> > > > >
> > >
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

[Jan Beulich]

>>> On 15.12.16 at 17:46,  wrote:
> On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote:
>> with today's kernel the system isn't coming up when booted as Xen dom0:
> 
> Remind me again pls, is dom0 even supposed to load microcode? Isn't the
> hypervisor supposed to apply microcode?

Yes, it's the hypervisor. Dom0 can at best hand the blob to it via
hypercall, but iirc upstream Linux doesn't make use of that.

Jan


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

Re: [Xen-devel] FATAL TRAP on __do_update_va_mapping when booting Xen 4.8

[Jan Beulich]

>>> On 15.12.16 at 17:33,  wrote:
> We're getting a FATAL TRAP when booting Xen 4.8 on 2 different servers (Xeon
> L5640 and Xeon L5520). The same xen binary boots fine on a third server with a
> Xeon E5-2650 v2 CPU, and the 3 servers boot fine when Xen is built with -01
> instead of -02 (gcc 4.9.2-10 from Debian jessie).
> 
> I've attached the boot log, and I've uploaded the xen and xen.syms binary 
> here:
> 
>  http://legout.info/~vincent/xen 
> 
> Would anyone have any idea? I'll be happy to provide more information if 
> needed.

This

(XEN) Xen code around  
(mm.c#__do_update_va_mapping+0x3c/0x630):
(XEN)  00 00 00 00 00 00 00 00  ff 0f 84 54 02 00 00 48 89 34 24 48 8d 74 24

pretty clearly shows that Xen's .text has been corrupted. To
determine how/when that has happened I guess you're in the
best position to find out. In particular you forgot to mention
whether you have any local modifications on top of (I assume)
4.8-staging.

Jan


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

Re: [Xen-devel] [PATCH 2/2] cpufreq: Remove cpu hotplug callbacks only if they were initialized

[Thomas Gleixner]

On Thu, 15 Dec 2016, Boris Ostrovsky wrote:

> Since cpu hotplug callbacks are requested for CPUHP_AP_ONLINE_DYN state,
> successful callback initialization will result in cpuhp_setup_state()
> returning a positive value. Therefore acpi_cpufreq_online being zero
> indicates that callbacks have not been installed.
> 
> This means that acpi_cpufreq_boost_exit() should only remove them if
> acpi_cpufreq_online is positive. Trying to call
> cpuhp_remove_state_nocalls(0) will cause a BUG().
> 
> Signed-off-by: Boris Ostrovsky 

Reviewed-by: Thomas Gleixner 

> ---
>  drivers/cpufreq/acpi-cpufreq.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
> index 3a98702..3a2ca0f 100644
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -930,7 +930,7 @@ static void __init acpi_cpufreq_boost_init(void)
>  
>  static void acpi_cpufreq_boost_exit(void)
>  {
> - if (acpi_cpufreq_online >= 0)
> + if (acpi_cpufreq_online > 0)
>   cpuhp_remove_state_nocalls(acpi_cpufreq_online);
>  }
>  
> -- 
> 1.7.1
> 
> 

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

Re: [Xen-devel] FATAL TRAP on __do_update_va_mapping when booting Xen 4.8

[Andrew Cooper]

On 15/12/16 16:33, Vincent Legout wrote:
> Hello,
>
> We're getting a FATAL TRAP when booting Xen 4.8 on 2 different servers (Xeon
> L5640 and Xeon L5520). The same xen binary boots fine on a third server with a
> Xeon E5-2650 v2 CPU, and the 3 servers boot fine when Xen is built with -01
> instead of -02 (gcc 4.9.2-10 from Debian jessie).
>
> I've attached the boot log, and I've uploaded the xen and xen.syms binary 
> here:
>
>  http://legout.info/~vincent/xen
>
> Would anyone have any idea? I'll be happy to provide more information if 
> needed.

I discussed this issue with Roger on IRC earlier.

The backtrace reminded me of a compiler bug we identified, but that was
with GCC 6, so probably isn't applicable here.

How patched is Xen? Is it stock debian?

Can you provide the full build log including all compiler arguments, and
xen-syms for both the -O1 and -O2 case.  If it is a compiler bug, I will
need to compare the two disassembles.

~Andrew

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

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

[Borislav Petkov]

On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote:
> with today's kernel the system isn't coming up when booted as Xen dom0:

Remind me again pls, is dom0 even supposed to load microcode? Isn't the
hypervisor supposed to apply microcode?

> Looking into the state of cpu 1 I find the following backtrace (created
> manually by looking up addresses from a stack dump retrieved from the
> hypervisor):
> 
> find_cpio_data()
> find_microcode_in_initrd()
> __load_ucode_intel()
> load_ucode_intel_ap()
> cpu_init()
> cpu_bringup()
> cpu_bringup_and_idle()
> 
> It seems as if load_ucode_intel_ap() is looping. You introduced a
> possibly endless loop in it with commit fe055896.

Are you sure you mean:

  fe055896c040 ("x86/microcode: Merge the early microcode loader")

because that commit is a year old.

So from looking at the *current* code:

if (apply_microcode_early(, true)) {

fails probably because MSR_IA32_UCODE_REV doesn't get read properly due
to virtualized MSRs, bla, yadda yadda...

But before we debug this further, I'd like to make sure I'm debugging
the proper thing and not some situation again where xen wasn't even
supposed to run the microcode loader but it does it anyway...

Thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

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

Re: [Xen-devel] [PATCH 8/8] libelf: safety: Document safety principles in header file

[Jan Beulich]

>>> On 09.12.16 at 16:44,  wrote:
> +/*
> + * DESIGN PRINCIPLES FOR THE SAFETY OF LIBELF
> + *
> + * libelf is a complex piece of code on a security boundary: when
> + * built as part of the tools, it parses guest kernels and loads them
> + * into guest memory.  Bugs in libelf can become privilege escalation
> + * or denial of service bugs in the toolstack.
> + *
> + * We try to reduce the risk of such bugs by writing the actual format
> + * parsing in a mostly-safe subset of C.  To avoid nonlocal exits or
> + * the need for explicit error-checking code, we make all references
> + * into the input image, or into guest memory, via an inherently safe
> + * wrapper system.
> + *
> + * This means that it is safe to simply honour the instructions from
> + * the image, even if they are nonsense.  If the image implies wild
> + * pointer accesses, these will be harmlessly defused; a note will be
> + * made that things are broken; and processing can safely continue
> + * despite some of the operations having not been done.  Eventually
> + * the error will be reported.
> + *
> + *
> + * To preserve these safety properties, there are some rules that
> + * programmers editing libelf need to follow:
> + *
> + *  - Any loop needs to be accompanied by calls to elf_iter_ok (or
> + *elf_iter_ok_counted).
> + *
> + *Rationale: the image must not be able to cause libelf to do
> + *unbounded work (ie, get stuck in a loop).

As expressed before, I'm not convinced library code should be
concerned about caller restrictions.

> + *  - The input image and output area must be accessed only via the
> + *safe pointer access system.  Real pointers into the input or
> + *output may not be even *calculated*.
> + *
> + *Rationale: calculating wild pointers is undefined behaviour;
> + *if the compiler sees that you might be calculating wild
> + *pointers, it may remove important checks!
> + *
> + *  - Stack local buffer variables containing information derived from
> + *the image (including structs, or byte buffers) must be
> + *completely zeroed, using elf_memset_unchecked (and an
> + *accompanying elf_iter_ok_counted) on entry to the function (or
> + *somewhere very obviously near there).
> + *
> + *Rationale: This avoids uninitialised stack data being used
> + *as input to any of the loader.

What distinguishes a "buffer variable" from a plain variable? I.e.
where is the boundary here as to which ones need zeroing? Also,
I don't think zeroing is needed when a variable gets fully written
over (like in a structure assignment). Do you perhaps want to
limit the above to "directly derived from the image"?

> + *  - All integer variables should be unsigned.
> + *
> + *Rationale: this avoids signed integer overflow (which has
> + *undefined behaviour in C, and if spotted by the compiler can
> + *cause it to generate bad code).

There are certainly cases where one explicitly needs negative
values, and hence signed integer types. Therefore I don't think
we can outright exclude this. Perhaps limit by "... variables with
non-negative value range ..."?

> + *  - Arithmetic operations other than + - * should be avoided; in
> + *particular, division (/ or %) by non-constant values should be
> + *avoided.  If it cannot be avoided, the divisor must be checked
> + *for zero.
> + *
> + *Rationale: We must avoid division-by-zero (or other overflow
> + *traps).
> + *
> + *  - If it is desirable to breach these rules, there should be a
> + *comment explaining why this is OK.
> + *
> + * Even so, this is a fairly high-risk environment, so:
> + *
> + *  - Do not add code which is not necessary for libelf to function
> + *with correct input, or to avoid being vulnerable to incorrect
> + *input.  Do not add additional functionally-unnecessary checks
> + *for diagnosing problems with the image, or validating sanity of
> + *the input ELF.
> + *
> + *Rationale: Redundant checks have almost zero benefit because
> + *1. we do not expect ELF-generating tools to generate invalid
> + *ELFs so these checks' failure paths will very likely never
> + *be executed anywhere, and 2. anyone debugging such a
> + *hypothetical bad ELF will have a variety of tools available
> + *which will do a much better job of analysing it.

While I can understand your reasoning, I continue to think that
libelf in a ELF loader, and hence should check certain things. The
best example I currently know of are e_[ps]hentsize, which the
code uses without checking the lower valid bound.

Overall I'm certainly not meaning to veto any of this, but I think it
would be better for some other REST maintainer (agreeing with
your way of thinking) to ack this.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xen.org

[Xen-devel] FATAL TRAP on __do_update_va_mapping when booting Xen 4.8

[Vincent Legout]

Hello,

We're getting a FATAL TRAP when booting Xen 4.8 on 2 different servers (Xeon
L5640 and Xeon L5520). The same xen binary boots fine on a third server with a
Xeon E5-2650 v2 CPU, and the 3 servers boot fine when Xen is built with -01
instead of -02 (gcc 4.9.2-10 from Debian jessie).

I've attached the boot log, and I've uploaded the xen and xen.syms binary here:

 http://legout.info/~vincent/xen

Would anyone have any idea? I'll be happy to provide more information if needed.

Thanks,
Vincent
(XEN) Xen version 4.8.1-pre (Debian ) (@) (gcc (Debian 4.9.2-10) 4.9.2) debug=n 
 Thu Dec 15 15:29:25 UTC 2016
(XEN) Bootloader: COM32 Multiboot loader v0.2
(XEN) Command line: console=com2 loglvl=all guest_loglvl=all iommu=off 
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)   - 000a (usable)
(XEN)  0010 - 7f379000 (usable)
(XEN)  7f379000 - 7f38f000 (reserved)
(XEN)  7f38f000 - 7f3ce000 (ACPI data)
(XEN)  7f3ce000 - 8000 (reserved)
(XEN)  e000 - f000 (reserved)
(XEN)  fe00 - 0001 (reserved)
(XEN)  0001 - 000c8000 (usable)
(XEN) ACPI: RSDP 000F11A0, 0024 (r2 DELL  )
(XEN) ACPI: XSDT 000F12A4, 009C (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: FACP 7F3B3F9C, 00F4 (r3 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: DSDT 7F38F000, 3D72 (r1 DELL   PE_SC3  1 INTL 20050624)
(XEN) ACPI: FACS 7F3B6000, 0040
(XEN) ACPI: APIC 7F3B3478, 015E (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: SPCR 7F3B35D8, 0050 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: HPET 7F3B362C, 0038 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: DMAR 7F3B3668, 01B0 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: MCFG 7F3B38C4, 003C (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: WD__ 7F3B3904, 0134 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: SLIC 7F3B3A3C, 0176 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: ERST 7F392EF4, 0270 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: HEST 7F393164, 03A8 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: BERT 7F392D74, 0030 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: EINJ 7F392DA4, 0150 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: SRAT 7F3B3BC0, 0370 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: TCPA 7F3B3F34, 0064 (r2 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: SSDT 7F3B7000, 41E4 (r1  INTEL PPM RCM  8001 INTL 20061109)
(XEN) System RAM: 49139MB (50318436kB)
(XEN) SRAT: PXM 1 -> APIC 10 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 00 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 12 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 02 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 14 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 04 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 16 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 06 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 11 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 01 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 13 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 03 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 15 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 05 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 17 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 07 -> Node 1
(XEN) SRAT: Node 1 PXM 2 0-8000
(XEN) SRAT: Node 1 PXM 2 1-68000
(XEN) SRAT: Node 0 PXM 1 68000-c8000
(XEN) NUMA: Using 19 for the hash shift.
(XEN) Domain heap initialised DMA width 32 bits
(XEN) CPU Vendor: Intel, Family 6 (0x6), Model 26 (0x1a), Stepping 5 (raw 
000106a5)
(XEN) found SMP MP-table at 000fe710
(XEN) DMI 2.6 present.
(XEN) Using APIC driver bigsmp
(XEN) ACPI: PM-Timer IO Port: 0x808 (32 bits)
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:804,1:0], pm1x_evt[1:800,1:0]
(XEN) ACPI: wakeup_vec[7f3b600c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee0
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x10] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x00] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x12] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x02] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x04] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x16] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x06] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x11] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x01] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x13] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x03] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x15] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x05] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x17] enabled)
(XEN) ACPI: LAPIC 

Re: [Xen-devel] [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]

[Kevin Grittner]

On Thu, Dec 15, 2016 at 9:53 AM, Ian Jackson  wrote:

> I don't think "set max_pred_locks_per_transaction generously" is a
> practical thing to write in the documentation, because the application
> programmer, or admin, has no sensible way to calculate what a
> sufficiently generous value is.

ok

> You seem to be implying that code relying on the summarised data might
> make over-optimistic decisions.  That seems dangerous to me, but (with
> my very dim view of database innards) I can't immediately see how to
> demonstrate that it must in any case be excluded.

No, with any of these conditions, the information on which a
decision to generate a serialization failure is summarized into
something less granular, and in all cases we turn any "in doubt"
situations into serialization failures; that is, you can get false
positives (a serialization failure exception where complete
information could have avoided it) but not false negatives (a
serialization anomaly appearing in the database or query results
from a transaction which commits).  Based on that alone, I think it
is fair to say that it does not weaken guarantees about
serialization failures for read-only transactions not being
possible on commit unless the initial exception is suppressed in a
subtransaction nor that anomalous results are not possible in a
read-only transaction.  The granularity promotion of predicate
locks could not affect the guarantees about never seeing a
serialization failure on the first statement that reads data in a
read-only transaction, but I would need to take a very close look
at how the SLRU summarization of committed transactions might
affect that one -- we lose some of the detail about the relative
order of the commits and snapshot acquisitions, and that might be
enough to allow a false positive on that first statement.  That
would require more study than I can give it this month.

I do remember that Dan ran some saturation workloads to stress this
feature for days and weeks at a time pushing things to the point of
using the SLRU summarization, and I remember thinking it odd that
certain tests generated zero errors on the read-only transactions,
which I'm pretty sure were single-statement transactions.  It was
only during this week's discussion that I had the epiphany about
that only being possible if the read-only transaction had multiple
statements; but the fact that such long saturation runs with SLRU
summarization showed no errors on read-only transactions supports
the idea that such summarization doesn't compromise that guarantee.
Unfortunately, it falls short of proof.  :-(

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

Re: [Xen-devel] [PATCH v2 7/8] dm_op: convert HVMOP_inject_trap and HVMOP_inject_msi

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
> Beulich
> Sent: 15 December 2016 16:23
> To: Paul Durrant 
> Cc: Andrew Cooper ; Daniel De Graaf
> ; Wei Liu ; Ian Jackson
> ; xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH v2 7/8] dm_op: convert
> HVMOP_inject_trap and HVMOP_inject_msi
> 
> >>> On 06.12.16 at 14:46,  wrote:
> > +struct xen_dm_op_inject_trap {
> > +/* IN - index of vCPU */
> > +uint32_t vcpuid;
> > +/* IN - interrupt vector */
> > +uint8_t vector;
> > +/* IN - trap type (DMOP_TRAP_* ) */
> > +uint8_t type;
> > +/* NB. This enumeration precisely matches hvm.h:X86_EVENTTYPE_* */
> > +# define DMOP_TRAP_ext_int0 /* external interrupt */
> > +# define DMOP_TRAP_nmi2 /* nmi */
> > +# define DMOP_TRAP_hw_exc 3 /* hardware exception */
> > +# define DMOP_TRAP_sw_int 4 /* software interrupt (CD nn) */
> > +# define DMOP_TRAP_pri_sw_exc 5 /* ICEBP (F1) */
> > +# define DMOP_TRAP_sw_exc 6 /* INT3 (CC), INTO (CE) */
> 
> XEN_ prefixes missing. (Did I overlook any in earlier patches? Please
> double check.)
> 

I should have noticed anyway... I'll fix them up.

> > +/* IN - enstruction length */
> > +uint8_t insn_len;
> > +uint8_t pad;
> > +/* IN - error code (or ~0 to skip) */
> > +uint32_t error_code;
> > +/* IN - CR2 for page faults */
> > +uint64_aligned_t cr2;
> 
> Another 32-bit padding field is needed ahead of this one.

So, it is... I obviously can't count.

> 
> With both taken care of, hypervisor parts
> Reviewed-by: Jan Beulich 
> 

Thanks,

  Paul

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

Re: [Xen-devel] [PATCH v2 5/8] dm_op: convert HVMOP_modified_memory

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
> Beulich
> Sent: 15 December 2016 16:06
> To: Paul Durrant 
> Cc: Andrew Cooper ; Daniel De Graaf
> ; Wei Liu ; Ian Jackson
> ; xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH v2 5/8] dm_op: convert
> HVMOP_modified_memory
> 
> >>> On 06.12.16 at 14:46,  wrote:
> > @@ -142,18 +143,77 @@ static int set_isa_irq_level(struct domain *d,
> uint8_t isa_irq,
> >  return 0;
> >  }
> >
> > +static int modified_memory(struct domain *d, xen_pfn_t *first_pfn,
> > +   unsigned int *nr)
> > +{
> > +xen_pfn_t last_pfn = *first_pfn + *nr - 1;
> > +unsigned int iter;
> > +int rc;
> > +
> > +if ( (*first_pfn > last_pfn) ||
> > + (last_pfn > domain_get_maximum_gpfn(d)) )
> > +return -EINVAL;
> > +
> > +if ( !paging_mode_log_dirty(d) )
> > +return 0;
> > +
> > +iter = 0;
> > +rc = 0;
> > +while ( iter < *nr )
> > +{
> > +unsigned long pfn = *first_pfn + iter;
> > +struct page_info *page;
> > +
> > +page = get_page_from_gfn(d, pfn, NULL, P2M_UNSHARE);
> > +if ( page )
> > +{
> > +paging_mark_dirty(d, page_to_mfn(page));
> 
> I guess this will need re-basing over Andrew's about to be committed
> (I think) parameter type change of this function. And you probably
> want to latch the MFN into a local variable instead of doing the
> translation (which is not as cheap as we'd like it to be) twice.
> 

Sure. I probably won't get time to post v3 until the new year so hopefully 
Andrew's changes will be there by then :-)

> >  long do_dm_op(domid_t domid,
> >unsigned int nr_bufs,
> >XEN_GUEST_HANDLE_PARAM(xen_dm_op_buf_t) bufs)
> >  {
> >  struct domain *d;
> >  struct xen_dm_op op;
> > +bool restart;
> >  long rc;
> >
> >  rc = rcu_lock_remote_domain_by_id(domid, );
> >  if ( rc )
> >  return rc;
> >
> > +restart = false;
> 
> Please make this the initializer of the variable.
> 

Ok.

> > --- a/xen/include/public/hvm/dm_op.h
> > +++ b/xen/include/public/hvm/dm_op.h
> > @@ -233,6 +233,24 @@ struct xen_dm_op_set_pci_link_route {
> >  uint16_t pad;
> >  };
> >
> > +/*
> > + * XEN_DMOP_modified_memory: Notify that a set of pages were
> modified by
> > + *   an emulator.
> > + *
> > + * NOTE: In the event of a continuation (return code -ERESTART), the
> > + *   @first_pfn is set to the value of the pfn of the remaining
> > + *   set of pages and @nr reduced to the size of the remaining set.
> > + */
> 
> There's no point in mentioning -ERESTART here, as that's never be
> seen by the caller.
> 

Ok.

  Paul

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

Re: [Xen-devel] [PATCH v2 3/8] dm_op: convert HVMOP_track_dirty_vram

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 15 December 2016 15:45
> To: Paul Durrant 
> Cc: Andrew Cooper ; Wei Liu
> ; George Dunlap ; Ian
> Jackson ; xen-de...@lists.xenproject.org; Daniel
> De Graaf ; Tim (Xen.org) 
> Subject: Re: [PATCH v2 3/8] dm_op: convert HVMOP_track_dirty_vram
> 
> >>> On 06.12.16 at 14:46,  wrote:
> > @@ -68,6 +70,35 @@ static int
> copy_buf_to_guest(XEN_GUEST_HANDLE_PARAM(xen_dm_op_buf_t)
> bufs,
> >  return copy_to_guest(buf.h, src, size) ? -EFAULT : 0;
> >  }
> >
> > +static int track_dirty_vram(struct domain *d,
> > +unsigned int nr_bufs,
> > +XEN_GUEST_HANDLE_PARAM(xen_dm_op_buf_t) bufs,
> > +xen_pfn_t first_pfn, unsigned int nr)
> > +{
> > +struct xen_dm_op_buf buf;
> > +int rc;
> > +
> > +if ( nr > (GB(1) >> PAGE_SHIFT) )
> > +return -EINVAL;
> > +
> > +if ( d->is_dying )
> > +return -ESRCH;
> > +
> > +if ( !d->vcpu || !d->vcpu[0] )
> 
> It may not have been this patch, but I think we had settled on the left
> side here wanting to be !d->max_vcpus for consistency with other
> (modern) code.

Oh sorry, I must have missed that.

> 
> > --- a/xen/arch/x86/mm/hap/hap.c
> > +++ b/xen/arch/x86/mm/hap/hap.c
> > @@ -68,7 +68,7 @@
> >  int hap_track_dirty_vram(struct domain *d,
> >   unsigned long begin_pfn,
> >   unsigned long nr,
> > - XEN_GUEST_HANDLE_64(uint8) guest_dirty_bitmap)
> > + XEN_GUEST_HANDLE_PARAM(void) guest_dirty_bitmap)
> >  {
> >  long rc = 0;
> >  struct sh_dirty_vram *dirty_vram;
> > --- a/xen/arch/x86/mm/shadow/common.c
> > +++ b/xen/arch/x86/mm/shadow/common.c
> > @@ -3677,7 +3677,7 @@ static void sh_clean_dirty_bitmap(struct domain
> *d)
> >  int shadow_track_dirty_vram(struct domain *d,
> >  unsigned long begin_pfn,
> >  unsigned long nr,
> > -XEN_GUEST_HANDLE_64(uint8) guest_dirty_bitmap)
> > +XEN_GUEST_HANDLE_PARAM(void) 
> > guest_dirty_bitmap)
> >  {
> >  int rc = 0;
> >  unsigned long end_pfn = begin_pfn + nr;
> > --- a/xen/include/asm-x86/hap.h
> > +++ b/xen/include/asm-x86/hap.h
> > @@ -43,7 +43,7 @@ void  hap_vcpu_init(struct vcpu *v);
> >  int   hap_track_dirty_vram(struct domain *d,
> > unsigned long begin_pfn,
> > unsigned long nr,
> > -   XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
> > +   XEN_GUEST_HANDLE_PARAM(void) dirty_bitmap);
> >
> >  extern const struct paging_mode *hap_paging_get_mode(struct vcpu *);
> >  int hap_set_allocation(struct domain *d, unsigned int pages, bool
> *preempted);
> > --- a/xen/include/asm-x86/shadow.h
> > +++ b/xen/include/asm-x86/shadow.h
> > @@ -63,7 +63,7 @@ int shadow_enable(struct domain *d, u32 mode);
> >  int shadow_track_dirty_vram(struct domain *d,
> >  unsigned long first_pfn,
> >  unsigned long nr,
> > -XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
> > +XEN_GUEST_HANDLE_PARAM(void) dirty_bitmap);
> 
> I think all of these will go away with the type change required in the
> earlier patch.
> 

Yes, they probably will.

> With all of this taken care of, hypervisor parts
> Reviewed-by: Jan Beulich 
> 

Thanks,

  Paul

> Jan


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

Re: [Xen-devel] [PATCH v2 7/8] dm_op: convert HVMOP_inject_trap and HVMOP_inject_msi

[Jan Beulich]

>>> On 06.12.16 at 14:46,  wrote:
> +struct xen_dm_op_inject_trap {
> +/* IN - index of vCPU */
> +uint32_t vcpuid;
> +/* IN - interrupt vector */
> +uint8_t vector;
> +/* IN - trap type (DMOP_TRAP_* ) */
> +uint8_t type;
> +/* NB. This enumeration precisely matches hvm.h:X86_EVENTTYPE_* */
> +# define DMOP_TRAP_ext_int0 /* external interrupt */
> +# define DMOP_TRAP_nmi2 /* nmi */
> +# define DMOP_TRAP_hw_exc 3 /* hardware exception */
> +# define DMOP_TRAP_sw_int 4 /* software interrupt (CD nn) */
> +# define DMOP_TRAP_pri_sw_exc 5 /* ICEBP (F1) */
> +# define DMOP_TRAP_sw_exc 6 /* INT3 (CC), INTO (CE) */

XEN_ prefixes missing. (Did I overlook any in earlier patches? Please
double check.)

> +/* IN - enstruction length */
> +uint8_t insn_len;
> +uint8_t pad;
> +/* IN - error code (or ~0 to skip) */
> +uint32_t error_code;
> +/* IN - CR2 for page faults */
> +uint64_aligned_t cr2;

Another 32-bit padding field is needed ahead of this one.

With both taken care of, hypervisor parts
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] SMBIOS UUID

[Andrew Cooper]

On 12/12/16 19:05, Dejan Markic wrote:
> Hello all,
>
> sorry, as this might be a stupid question for some of you, but I
> wonder why here:
>
> https://github.com/mirage/xen/blob/master/tools/firmware/hvmloader/smbios.c#L438
>
>
> You allow almost everything to be overwritten in SMBIOS type 1 table
> except the UUID.

Probably only because whomever implemented the code didn't need to do that.

> Would there be any problems if UUID was also picked up from xenstore
> with, for instance, HVM_XS_SYSTEM_UUID?

The UUID is currently picked up from the domain's UUID stored in Xen, so
is currently under toolstack control.

I don't see a particular problem with being able to specify it via
xenstore.  What is your usecase here?

~Andrew

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

Re: [Xen-devel] [PATCH v2 1/2] arm/mem_access: adjust check_and_get_page to not rely on current

[Julien Grall]

Hi George,

On 15/12/16 04:54, George Dunlap wrote:

On Wed, Dec 14, 2016 at 8:05 PM, Julien Grall  wrote:

Note that ARM does not provide any hardware instruction to translate
an IPA (guest physical address) to a PA. So we have a walker there.

We also a walk for debugging guest page table (though only when it is
using LPAE). I guess it could be re-used in the case where it is not
possible to do it in hardware. Although, it would be rewritten to make
it safe.



This sounds like the kind of thing which would be generally useful,
although I'd like to understand the problem better before making
suggestions.



memaccess will restrict permission of certain memory regions in stage-2 page
table. For the purpose of the example, lets say read-access as been
restricted.

One of these memory regions may contain the stage-1 page table. Do you agree
that the guest will not able to read stage-1 page table due the restriction?


But only if the memory is read-protected, right?  If a guest PT
(stage-1) has read permission but not write permission, the hardware
walker should still work, shouldn't it?


Good question, ARMv8.1 is adding support of hardware management for the 
access flag and dirty state (see chapter B4 in DDI0557A.b). So if the 
hardware has to update the page table entry it would need write permission.


I have looked at the pseudo code for the address translation in both 
ARMv8.0 and ARMv8.1.


ARMv8.0 does not need to update the table entry in hardware, looking at 
the AArch64.CheckS2Permission pseudo-code (see J1-5290 in ARM DDI 
0486A.k_iss10775), the hardware walk will check whether stage-2 as read 
permission during Stage 1 page table walk (s2fs1walk variable is to true).


For ARMv8.1, after spending a couple of hours reading the pseudo-code 
(see E.1.2.5 in DDI0557A.b) my understanding is the hardware walker may 
need to update the entry (see AArch64.CheckAndUpdateDescriptor). This is 
depending on who has triggered the walker (e.g address translation 
instruction, instruction fetch, memory access...). In the case of 
address translation instruction (AccType_AT) no hardware update will be 
done.


So to answer your question, the address translation instruction only 
need read access. So the issue mentioned would only happen when the 
memory is read-protected.


Reading the pseudo-code reminded me a potential upcoming error with 
memaccess. I mentioned it a couple of months ago (see [1] and the KVM 
counterpart [2]) on the ML. Stage-2 permission fault during stage-1 
walk, the syndrome field WnR (Write not Read) will report whether the 
abort was caused by a write instruction or read instruction. And not 
whether the hardware walker was reading or writing the page table entry. 
This is pretty obvious with the new pseudo-code for 
AArch64.CheckPermission in the spec (see J1-5290 in ARM DDI 
0486A.k_iss10775).


I think that a guest having stage-1 page table protected in stage-2 
could be stuck forever faulting and retrying a write instruction because 
memaccess would receive the wrong fault (i.e write fault instead of read).


Cheers,

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2016-10/msg00228.html
[2] 
https://lists.cs.columbia.edu/pipermail/kvmarm/2016-September/021925.html


--
Julien Grall

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

[Xen-devel] Can't boot as Xen dom0 due to commit fe055896

[Juergen Gross]

Boris,

with today's kernel the system isn't coming up when booted as Xen dom0:

[   33.575326] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s!
[swapper/0:1]
[   33.589795] Modules linked in:
[   33.596015] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-pv+ #687
[   33.608844] Hardware name: Dell Inc. Latitude E6440/0159N7, BIOS A07
06/26/2014
[   33.623590] task: 8801fa574dc0 task.stack: c90001e68000
[   33.635535] RIP: e030:xen_hypercall_sched_op+0xa/0x20
[   33.645756] RSP: e02b:c90001e6bdc8 EFLAGS: 0246
[   33.656331] RAX:  RBX: 0001 RCX:
810013aa
[   33.670718] RDX:  RSI:  RDI:

[   33.685102] RBP:  R08:  R09:
0001
[   33.699487] R10: 0001b448 R11: 0246 R12:
b8b8
[   33.713872] R13: 0001 R14: 001ff889 R15:
001193a2
[   33.728260] FS:  () GS:8801ff80()
knlGS:
[   33.744562] CS:  e033 DS:  ES:  CR0: 80050033
[   33.756158] CR2: c900010f6000 CR3: 01807000 CR4:
00042660
[   33.770545] Call Trace:
[   33.775567]  ? xen_cpu_up+0x1da/0x500
[   33.783020]  ? put_online_cpus+0x70/0x70
[   33.790992]  ? bringup_cpu+0x1e/0x80
[   33.798269]  ? cpuhp_invoke_callback+0x7b/0x3e0
[   33.807459]  ? ring_buffer_record_is_on+0x10/0x10
[   33.816989]  ? cpuhp_up_callbacks+0x2b/0xa0
[   33.825482]  ? _cpu_up+0x6d/0xc0
[   33.832068]  ? rest_init+0x70/0x70
[   33.838998]  ? do_cpu_up+0x77/0xa0
[   33.845931]  ? smp_init+0xd7/0xdc
[   33.852688]  ? kernel_init_freeable+0xe3/0x1fd
[   33.861705]  ? rest_init+0x70/0x70
[   33.868635]  ? rest_init+0x70/0x70
[   33.875568]  ? kernel_init+0x5/0x100
[   33.882848]  ? ret_from_fork+0x25/0x30
[   33.890473] Code: cc 51 41 53 b8 1c 00 00 00 0f 05 41 5b 59 c3 cc cc
cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 1d 00 00 00
0f 05 <41> 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc

Looking into the state of cpu 1 I find the following backtrace (created
manually by looking up addresses from a stack dump retrieved from the
hypervisor):

find_cpio_data()
find_microcode_in_initrd()
__load_ucode_intel()
load_ucode_intel_ap()
cpu_init()
cpu_bringup()
cpu_bringup_and_idle()

It seems as if load_ucode_intel_ap() is looping. You introduced a
possibly endless loop in it with commit fe055896.

I'm not sure whether it is best to add a maximum loop counter or to
correct the situation in another way.


Juergen

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

Re: [Xen-devel] [PATCH v2 6/8] dm_op: convert HVMOP_set_mem_type

[Jan Beulich]

>>> On 06.12.16 at 14:46,  wrote:
> --- a/xen/arch/x86/hvm/dm.c
> +++ b/xen/arch/x86/hvm/dm.c
> @@ -199,6 +199,87 @@ static int modified_memory(struct domain *d, xen_pfn_t 
> *first_pfn,
>  return rc;
>  }
>  
> +static bool allow_p2m_type_change(p2m_type_t old, p2m_type_t new)
> +{
> +return ( p2m_is_ram(old) ||
> + (p2m_is_hole(old) && new == p2m_mmio_dm) ||
> + (old == p2m_ioreq_server && new == p2m_ram_rw) );

Pointless outermost parentheses; at the very least the blanks
immediately inside them need to go away.

> +static int set_mem_type(struct domain *d, hvmmem_type_t mem_type,
> +xen_pfn_t *first_pfn, unsigned int *nr)
> +{
> +xen_pfn_t last_pfn = *first_pfn + *nr - 1;
> +unsigned int iter;
> +int rc;
> +
> +/* Interface types to internal p2m types */
> +static const p2m_type_t memtype[] = {
> +[HVMMEM_ram_rw]  = p2m_ram_rw,
> +[HVMMEM_ram_ro]  = p2m_ram_ro,
> +[HVMMEM_mmio_dm] = p2m_mmio_dm,
> +[HVMMEM_unused] = p2m_invalid,
> +[HVMMEM_ioreq_server] = p2m_ioreq_server
> +};
> +
> +if ( (*first_pfn > last_pfn) ||
> + (last_pfn > domain_get_maximum_gpfn(d)) )
> +return -EINVAL;
> +
> +if ( mem_type >= ARRAY_SIZE(memtype) ||
> + unlikely(mem_type == HVMMEM_unused) )
> +return -EINVAL;
> +
> +iter = 0;
> +rc = 0;
> +while ( iter < *nr )
> +{
> +unsigned long pfn = *first_pfn + iter;
> +p2m_type_t t;
> +
> +get_gfn_unshare(d, pfn, );
> +if ( p2m_is_paging(t) )
> +{
> +put_gfn(d, pfn);
> +p2m_mem_paging_populate(d, pfn);
> +return -EAGAIN;
> +}
> +
> +if ( p2m_is_shared(t) )
> +rc = -EAGAIN;
> +else if ( !allow_p2m_type_change(t, memtype[mem_type]) )
> +rc = -EINVAL;
> +else
> +rc = p2m_change_type_one(d, pfn, t, memtype[mem_type]);
> +
> +put_gfn(d, pfn);
> +
> +if ( rc )
> +break;
> +
> +iter++;
> +
> +/*
> + * Check for continuation every 256th iteration and if the
> + * iteration is not the last.
> + */
> +if ( (iter < *nr) && ((iter & 0xff) == 0) &&
> + hypercall_preempt_check() )
> +{
> +rc = -ERESTART;
> +break;
> +}
> +}
> +
> +if ( rc == -ERESTART )
> +{
> +*first_pfn += iter;
> +*nr -= iter;
> +}

I may have overlooked this in the previous patch - the body of this
if() could easily move into the one setting rc to -ERESTART,
eliminating the extra conditional.

Jan


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

Re: [Xen-devel] [PATCH v2 5/8] dm_op: convert HVMOP_modified_memory

[Jan Beulich]

>>> On 06.12.16 at 14:46,  wrote:
> @@ -142,18 +143,77 @@ static int set_isa_irq_level(struct domain *d, uint8_t 
> isa_irq,
>  return 0;
>  }
>  
> +static int modified_memory(struct domain *d, xen_pfn_t *first_pfn,
> +   unsigned int *nr)
> +{
> +xen_pfn_t last_pfn = *first_pfn + *nr - 1;
> +unsigned int iter;
> +int rc;
> +
> +if ( (*first_pfn > last_pfn) ||
> + (last_pfn > domain_get_maximum_gpfn(d)) )
> +return -EINVAL;
> +
> +if ( !paging_mode_log_dirty(d) )
> +return 0;
> +
> +iter = 0;
> +rc = 0;
> +while ( iter < *nr )
> +{
> +unsigned long pfn = *first_pfn + iter;
> +struct page_info *page;
> +
> +page = get_page_from_gfn(d, pfn, NULL, P2M_UNSHARE);
> +if ( page )
> +{
> +paging_mark_dirty(d, page_to_mfn(page));

I guess this will need re-basing over Andrew's about to be committed
(I think) parameter type change of this function. And you probably
want to latch the MFN into a local variable instead of doing the
translation (which is not as cheap as we'd like it to be) twice.

>  long do_dm_op(domid_t domid,
>unsigned int nr_bufs,
>XEN_GUEST_HANDLE_PARAM(xen_dm_op_buf_t) bufs)
>  {
>  struct domain *d;
>  struct xen_dm_op op;
> +bool restart;
>  long rc;
>  
>  rc = rcu_lock_remote_domain_by_id(domid, );
>  if ( rc )
>  return rc;
>  
> +restart = false;

Please make this the initializer of the variable.

> --- a/xen/include/public/hvm/dm_op.h
> +++ b/xen/include/public/hvm/dm_op.h
> @@ -233,6 +233,24 @@ struct xen_dm_op_set_pci_link_route {
>  uint16_t pad;
>  };
>  
> +/*
> + * XEN_DMOP_modified_memory: Notify that a set of pages were modified by
> + *   an emulator.
> + *
> + * NOTE: In the event of a continuation (return code -ERESTART), the
> + *   @first_pfn is set to the value of the pfn of the remaining
> + *   set of pages and @nr reduced to the size of the remaining set.
> + */

There's no point in mentioning -ERESTART here, as that's never be
seen by the caller.

Jan


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

Re: [Xen-devel] [PATCH v2] VT-d: correct dma_msi_set_affinity()

[Andrew Cooper]

On 15/12/16 15:53, Jan Beulich wrote:
> Commit 83cd2038fe ("VT-d: use msi_compose_msg()) together with
> 15aa6c6748 ("amd iommu: use base platform MSI implementation"),
> introducing the use of a per-CPU scratch CPU mask, went too far:
> dma_msi_set_affinity() may, at least in theory, be called in
> interrupt context, and hence the use of that scratch variable is not
> correct.
>
> Since the function overwrites the destination information anyway,
> allow msi_compose_msg() to be called with a NULL CPU mask, avoiding
> the use of that scratch variable.
>
> Signed-off-by: Jan Beulich 
> Reviewed-by: Kevin Tian 

Reviewed-by: Andrew Cooper 


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

Re: [Xen-devel] [PATCH v2 1/8] public / x86: Introduce __HYPERCALL_dm_op...

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 15 December 2016 15:23
> To: Paul Durrant 
> Cc: Andrew Cooper ; Ian Jackson
> ; Jennifer Herbert ;
> Wei Liu ; xen-de...@lists.xenproject.org; Daniel De
> Graaf 
> Subject: Re: [PATCH v2 1/8] public / x86: Introduce __HYPERCALL_dm_op...
> 
> >>> On 06.12.16 at 14:46,  wrote:
> > ...as a set of hypercalls to be used by a device model.
> >
> > As stated in the new docs/designs/dm_op.markdown:
> >
> > "The aim of DMOP is to prevent a compromised device model from
> > compromising domains other then the one it is associated with. (And is
> > therefore likely already compromised)."
> >
> > See that file for further information.
> >
> > This patch simply adds the boilerplate for the hypercall.
> >
> > Signed-off-by: Paul Durrant 
> > Suggested-by: Ian Jackson 
> > Suggested-by: Jennifer Herbert 
> 
> Hypervisor parts
> Reviewed-by: Jan Beulich 
> albeit with one more question/adjustment request:
> 
> > +struct xen_dm_op_buf {
> > +XEN_GUEST_HANDLE(void) h;
> > +uint64_aligned_t size;
> 
> Does size need to be 64 bits wide? I thing 32 should suffice, even if
> that won't shrink structure size (because the handle really wants to
> be XEN_GUEST_HANDLE_64() for a tool stack-only interface which
> we don't want to have a compat wrapper for).

Sure. I don't think it does need to be that wide in reality.

  Paul

> 
> Jan


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf aaa61995af9e0b65c37bdad6796867760fa1d5fe
baseline version:
 ovmf dc756baeda55490202f3150a8821b5164e906451

Last test of basis   103293  2016-12-13 22:50:12 Z1 days
Testing same since   103347  2016-12-14 16:28:50 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 
  Liming Gao 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]

[Ian Jackson]

Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry 
on constraint violation [and 2 more messages] [and 1 more messages]"):
> On Thu, Dec 15, 2016 at 6:09 AM, Ian Jackson  
> wrote:
> > [...]  Are there other reasons,
> > besides previously suppressed serialisation failures, why commit of a
> > transaction that did only reads[1] might fail ?
> 
> I'm pretty confident that if you're not using prepared transactions
> the answer is "no".  [...] I fear that [for now], if "pre-crash"
> prepared transactions are still open, some of the deductions above
> may not hold.

I think it is reasonable to write in the documentation "if you use
prepared transactions, even read only serialisable transctions might
throw a serialisation failure during commit, and they might do so
after returning data which is not consistent with any global
serialisation".

Prepared transactions are a special purpose feature intended for use
by external transaction management software which I hope could cope
with a requirement to not trust data from a read only transaction
until it had been committed.  (Also, frankly, the promise that a
prepared transaction is can be committed successfully with "very high
probability" is not sufficiently precise to be of use when building
robust software at the next layer up.)

> One other situation in which I'm not entirely sure, and it would
> take me some time to review code to be sure, is if
> max_pred_locks_per_transaction is not set high enough to
> accommodate tracking all serializable transactions in allocated RAM
> (recognizing that they must often be tracked after commit, until
> overlapping serializable transactions commit), we have a mechanism
> to summarize some of the committed transactions and spill them to
> disk (using an internal SLRU module).  The summarized data might
> not be able to determine all of the above as precisely as the
> "normal" data tracked in RAM.  To avoid this, be generous when
> setting max_pred_locks_per_transaction; not only will it avoid this
> summarization, but it will reduce the amount of summarization of
> multiple page locks in the predicate locking system to relation
> locks.  Coarser locks increase the "false positive" rate of
> serialization failures, reducing performance.

I don't think "set max_pred_locks_per_transaction generously" is a
practical thing to write in the documentation, because the application
programmer, or admin, has no sensible way to calculate what a
sufficiently generous value is.

You seem to be implying that code relying on the summarised data might
make over-optimistic decisions.  That seems dangerous to me, but (with
my very dim view of database innards) I can't immediately see how to
demonstrate that it must in any case be excluded.

But, I think this can only be a problem (that is, it can only cause a
return of un-serialisable results within such a transaction) if, after
such a spill, COMMIT would recalculate the proper answers, in full,
and thus be able to belatedly report the serialisation failure.  Is
that the case ?

> > If so presumably it always throws a serialisation failure at that
> > point.  I think that is then sufficient.  There is no need to tell the
> > application programmer they have to commit even transactions which
> > only read.
> 
> Well, if they don't explicitly start a transaction there is no need
> to explicitly commit it, period.  [...]

Err, yes, I meant multi-statement transactions.  (Or alternatively by
"have to commit" I meant to include the implicit commit of an implicit
transaction.)

> If you can put together a patch to improve the documentation, that
> is always welcome!

Thanks.  I hope I will be able to do that.  Right now I am still
trying to figure out what guarantees the application programmer can be
offered.

Regards,
Ian.

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

[Xen-devel] [PATCH v2] VT-d: correct dma_msi_set_affinity()

[Jan Beulich]

Commit 83cd2038fe ("VT-d: use msi_compose_msg()) together with
15aa6c6748 ("amd iommu: use base platform MSI implementation"),
introducing the use of a per-CPU scratch CPU mask, went too far:
dma_msi_set_affinity() may, at least in theory, be called in
interrupt context, and hence the use of that scratch variable is not
correct.

Since the function overwrites the destination information anyway,
allow msi_compose_msg() to be called with a NULL CPU mask, avoiding
the use of that scratch variable.

Signed-off-by: Jan Beulich 
Reviewed-by: Kevin Tian 
---
v2: Mention first commit's hash. Fill msg.dest32 in
dma_msi_set_affinity() even if that's not strictly needed as the
field (including its copy in iommu->msi.msg.dest32) is unused right
now.

--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -160,39 +160,37 @@ static bool_t msix_memory_decoded(const
  */
 void msi_compose_msg(unsigned vector, const cpumask_t *cpu_mask, struct 
msi_msg *msg)
 {
-unsigned dest;
-
 memset(msg, 0, sizeof(*msg));
-if ( !cpumask_intersects(cpu_mask, _online_map) )
+
+if ( vector < FIRST_DYNAMIC_VECTOR )
 return;
 
-if ( vector )
+if ( cpu_mask )
 {
 cpumask_t *mask = this_cpu(scratch_mask);
 
-cpumask_and(mask, cpu_mask, _online_map);
-dest = cpu_mask_to_apicid(mask);
+if ( !cpumask_intersects(cpu_mask, _online_map) )
+return;
 
-msg->address_hi = MSI_ADDR_BASE_HI;
-msg->address_lo =
-MSI_ADDR_BASE_LO |
-((INT_DEST_MODE == 0) ?
- MSI_ADDR_DESTMODE_PHYS:
- MSI_ADDR_DESTMODE_LOGIC) |
-((INT_DELIVERY_MODE != dest_LowestPrio) ?
- MSI_ADDR_REDIRECTION_CPU:
- MSI_ADDR_REDIRECTION_LOWPRI) |
-MSI_ADDR_DEST_ID(dest);
-msg->dest32 = dest;
-
-msg->data =
-MSI_DATA_TRIGGER_EDGE |
-MSI_DATA_LEVEL_ASSERT |
-((INT_DELIVERY_MODE != dest_LowestPrio) ?
- MSI_DATA_DELIVERY_FIXED:
- MSI_DATA_DELIVERY_LOWPRI) |
-MSI_DATA_VECTOR(vector);
+cpumask_and(mask, cpu_mask, _online_map);
+msg->dest32 = cpu_mask_to_apicid(mask);
 }
+
+msg->address_hi = MSI_ADDR_BASE_HI;
+msg->address_lo = MSI_ADDR_BASE_LO |
+  (INT_DEST_MODE ? MSI_ADDR_DESTMODE_LOGIC
+ : MSI_ADDR_DESTMODE_PHYS) |
+  ((INT_DELIVERY_MODE != dest_LowestPrio)
+   ? MSI_ADDR_REDIRECTION_CPU
+   : MSI_ADDR_REDIRECTION_LOWPRI) |
+  MSI_ADDR_DEST_ID(msg->dest32);
+
+msg->data = MSI_DATA_TRIGGER_EDGE |
+MSI_DATA_LEVEL_ASSERT |
+((INT_DELIVERY_MODE != dest_LowestPrio)
+ ? MSI_DATA_DELIVERY_FIXED
+ : MSI_DATA_DELIVERY_LOWPRI) |
+MSI_DATA_VECTOR(vector);
 }
 
 static bool_t read_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1085,11 +1085,11 @@ static void dma_msi_set_affinity(struct
 return;
 }
 
-msi_compose_msg(desc->arch.vector, desc->arch.cpu_mask, );
-/* Are these overrides really needed? */
+msi_compose_msg(desc->arch.vector, NULL, );
+msg.dest32 = dest;
 if (x2apic_enabled)
 msg.address_hi = dest & 0xFF00;
-msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK;
+ASSERT(!(msg.address_lo & MSI_ADDR_DEST_ID_MASK));
 msg.address_lo |= MSI_ADDR_DEST_ID(dest);
 iommu->msi.msg = msg;
 



VT-d: correct dma_msi_set_affinity()

Commit 83cd2038fe ("VT-d: use msi_compose_msg()) together with
15aa6c6748 ("amd iommu: use base platform MSI implementation"),
introducing the use of a per-CPU scratch CPU mask, went too far:
dma_msi_set_affinity() may, at least in theory, be called in
interrupt context, and hence the use of that scratch variable is not
correct.

Since the function overwrites the destination information anyway,
allow msi_compose_msg() to be called with a NULL CPU mask, avoiding
the use of that scratch variable.

Signed-off-by: Jan Beulich 
Reviewed-by: Kevin Tian 
---
v2: Mention first commit's hash. Fill msg.dest32 in
dma_msi_set_affinity() even if that's not strictly needed as the
field (including its copy in iommu->msi.msg.dest32) is unused right
now.

--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -160,39 +160,37 @@ static bool_t msix_memory_decoded(const
  */
 void msi_compose_msg(unsigned vector, const cpumask_t *cpu_mask, struct 
msi_msg *msg)
 {
-unsigned dest;
-
 memset(msg, 0, sizeof(*msg));
-if ( !cpumask_intersects(cpu_mask, _online_map) )
+
+if ( vector < FIRST_DYNAMIC_VECTOR )
 return;
 
-if ( vector )
+if ( cpu_mask )
 {
 cpumask_t *mask = this_cpu(scratch_mask);
 
-

Re: [Xen-devel] [PATCH] x86: streamline copying to/from user memory

[Andrew Cooper]

On 06/12/16 11:25, Jan Beulich wrote:
> Their size parameters being "unsigned", there's neither a point for
> them returning "unsigned long", nor for any of their (assembly)
> arithmetic to involved 64-bit operations on other than addresses.
>
> Take the opportunity and fold __do_clear_user() into its single user
> (using qword stores instead of dword ones), name all asm() operands,
> and reduce the amount of (redundant) operands.
>
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v2 4/8] dm_op: convert HVMOP_set_pci_intx_level, HVMOP_set_isa_irq_level, and...

[Jan Beulich]

>>> On 06.12.16 at 14:46,  wrote:
> --- a/xen/include/public/hvm/dm_op.h
> +++ b/xen/include/public/hvm/dm_op.h
> @@ -191,6 +191,49 @@ struct xen_dm_op_track_dirty_vram {
>  uint64_aligned_t first_pfn;
>  };
>  
> +/*
> + * XEN_DMOP_set_pci_intx_level: Set the logical level of one of a domain's
> + *  PCI INTx pins.
> + */
> +#define XEN_DMOP_set_pci_intx_level 8
> +
> +struct xen_dm_op_set_pci_intx_level {
> +/* IN - PCI INTx identification (domain:bus:device:intx) */
> +uint16_t domain;
> +uint8_t bus, device, intx;
> +/* IN - Level: 0 -> deasserted, 1 -> asserted */
> +uint8_t  level;
> +uint16_t pad;
> +};

You don't need any padding here afaict.

> +/*
> + * XEN_DMOP_set_isa_irq_level: Set the logical level of a one of a domain's
> + * ISA IRQ lines.
> + */
> +#define XEN_DMOP_set_isa_irq_level 9
> +
> +struct xen_dm_op_set_isa_irq_level {
> +/* IN - ISA IRQ (0-15) */
> +uint8_t  isa_irq;
> +/* IN - Level: 0 -> deasserted, 1 -> asserted */
> +uint8_t  level;
> +uint16_t pad;
> +};

Same here.

> +/*
> + * XEN_DMOP_set_pci_link_route: Map a PCI INTx line to an IRQ line.
> + */
> +#define XEN_DMOP_set_pci_link_route 10
> +
> +struct xen_dm_op_set_pci_link_route {
> +/* PCI INTx line (0-3) */
> +uint8_t  link;
> +/* ISA IRQ (1-15) or 0 -> disable link */
> +uint8_t  isa_irq;
> +uint16_t pad;
> +};

And here.

> +
> +
>  struct xen_dm_op {

No double blank lines please.

With all of these taken care of, hypervisor parts
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH v2 3/8] dm_op: convert HVMOP_track_dirty_vram

[Jan Beulich]

>>> On 06.12.16 at 14:46,  wrote:
> @@ -68,6 +70,35 @@ static int 
> copy_buf_to_guest(XEN_GUEST_HANDLE_PARAM(xen_dm_op_buf_t) bufs,
>  return copy_to_guest(buf.h, src, size) ? -EFAULT : 0;
>  }
>  
> +static int track_dirty_vram(struct domain *d,
> +unsigned int nr_bufs,
> +XEN_GUEST_HANDLE_PARAM(xen_dm_op_buf_t) bufs,
> +xen_pfn_t first_pfn, unsigned int nr)
> +{
> +struct xen_dm_op_buf buf;
> +int rc;
> +
> +if ( nr > (GB(1) >> PAGE_SHIFT) )
> +return -EINVAL;
> +
> +if ( d->is_dying )
> +return -ESRCH;
> +
> +if ( !d->vcpu || !d->vcpu[0] )

It may not have been this patch, but I think we had settled on the left
side here wanting to be !d->max_vcpus for consistency with other
(modern) code.

> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -68,7 +68,7 @@
>  int hap_track_dirty_vram(struct domain *d,
>   unsigned long begin_pfn,
>   unsigned long nr,
> - XEN_GUEST_HANDLE_64(uint8) guest_dirty_bitmap)
> + XEN_GUEST_HANDLE_PARAM(void) guest_dirty_bitmap)
>  {
>  long rc = 0;
>  struct sh_dirty_vram *dirty_vram;
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -3677,7 +3677,7 @@ static void sh_clean_dirty_bitmap(struct domain *d)
>  int shadow_track_dirty_vram(struct domain *d,
>  unsigned long begin_pfn,
>  unsigned long nr,
> -XEN_GUEST_HANDLE_64(uint8) guest_dirty_bitmap)
> +XEN_GUEST_HANDLE_PARAM(void) guest_dirty_bitmap)
>  {
>  int rc = 0;
>  unsigned long end_pfn = begin_pfn + nr;
> --- a/xen/include/asm-x86/hap.h
> +++ b/xen/include/asm-x86/hap.h
> @@ -43,7 +43,7 @@ void  hap_vcpu_init(struct vcpu *v);
>  int   hap_track_dirty_vram(struct domain *d,
> unsigned long begin_pfn,
> unsigned long nr,
> -   XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
> +   XEN_GUEST_HANDLE_PARAM(void) dirty_bitmap);
>  
>  extern const struct paging_mode *hap_paging_get_mode(struct vcpu *);
>  int hap_set_allocation(struct domain *d, unsigned int pages, bool 
> *preempted);
> --- a/xen/include/asm-x86/shadow.h
> +++ b/xen/include/asm-x86/shadow.h
> @@ -63,7 +63,7 @@ int shadow_enable(struct domain *d, u32 mode);
>  int shadow_track_dirty_vram(struct domain *d,
>  unsigned long first_pfn,
>  unsigned long nr,
> -XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
> +XEN_GUEST_HANDLE_PARAM(void) dirty_bitmap);

I think all of these will go away with the type change required in the
earlier patch.

With all of this taken care of, hypervisor parts
Reviewed-by: Jan Beulich 

Jan


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

[Xen-devel] [xen-unstable-smoke test] 103406: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   5 libvirt-buildfail REGR. vs. 103284

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

version targeted for testing:
 xen  6e616a3cef4d782253787904bf3d641112eafa14
baseline version:
 xen  fc9229c4bb35c5474fbc67f78e628dcbcc90afc5

Last test of basis   103284  2016-12-13 19:03:56 Z1 days
Failing since103292  2016-12-13 22:19:08 Z1 days   15 attempts
Testing same since   103401  2016-12-15 11:15:56 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Cédric Bosdonnat 
  Haozhong Zhang 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Konrad Rzeszutek Wilk 
  Razvan Cojocaru 
  Ross Lagerwall 
  Stefano Stabellini 
  Suravee Suthikulpanit 
  Tamas K Lengyel 
  Tim Deegan 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  fail
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt 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.

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

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

Re: [Xen-devel] Ping: Re: [PATCH 2/3] VT-d: correct dma_msi_set_affinity()

[Andrew Cooper]

On 15/12/16 14:16, Jan Beulich wrote:
 On 15.12.16 at 13:52,  wrote:
>> On 15/12/16 09:54, Jan Beulich wrote:
>> On 09.12.16 at 09:47,  wrote:
>>> On 08.12.16 at 18:33,  wrote:
> On 08/12/16 16:01, Jan Beulich wrote:
>> That commit ("VT-d: use msi_compose_msg()) together with 15aa6c6748
> Which commit?
 Oops - initially I had intended the title to include the hash: 83cd2038fe.
 I've adjusted the text.

>> ("amd iommu: use base platform MSI implementation") introducing the use
>> of a per-CPU scratch CPU mask went too far: dma_msi_set_affinity() may,
>> at least in theory, be called in interrupt context, and hence the use
>> of that scratch variable is not correct.
>>
>> Since the function overwrites the destination information anyway,
>> allow msi_compose_msg() to be called with a NULL CPU mask, avoiding the
>> use of that scratch variable.
> Which function overwrites what?  I can't see dma_msi_set_affinity()
> doing anything to clobber msg.dest32, so I don't understand why this
> change is correct.
 msg.dest32 simply isn't being used. msg is local to that function, so
 all that matters is which fields the function consumes. Is uses only
 address and data, and updates address to properly specify the
 intended destination. To guard against stale data (in
 iommu->msi.msg), it may be reasonable to nevertheless set dest32
 before storing msg into that field.
>>> Any further thoughts here? Do I need to resend with that one line
>>> added?
>> msg is tiny.  I'd suggest just initialising to 0 at the start of the
>> function.
> Why? msi_compose_msg() does exactly that as its very first action.

Perhaps it would be easier to post a v2 of just this patch.  I can't
work out which one line you are referring to.

~Andrew

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

Re: [Xen-devel] [PATCH 3/3] x86: introduce and use scratch CPU mask

[Andrew Cooper]

On 15/12/16 14:59, Jan Beulich wrote:
 On 15.12.16 at 15:15,  wrote:
>> On 09/12/16 08:59, Jan Beulich wrote:
>> On 08.12.16 at 18:51,  wrote:
 On 08/12/16 16:02, Jan Beulich wrote:
> variable. With an IRQ happening at the deepest point of the stack, and
> with send_guest_pirq() being called from there (leading to vcpu_kick()
> -> ... -> csched_vcpu_wake() -> __runq_tickle() ->
> cpumask_raise_softirq(), the last two of which also have CPU mask
> variables on their stacks), this has been observed to cause a stack
 "stacks), has been".
>>> Hmm, that looks strange to me: Wouldn't the dropping of "this"
>>> also requite the "With" at the start of the sentence to be dropped
>>> (and isn't the sentence okay with both left in place)?
>> The use of "this" requires a substantial backtrack through the text to
>> evaluate what it refers to, which as you point, I didn't manage to do
>> successfully. 
>>
>> As is evident, I had a very hard time trying to parse the sentence.
>>
>> It would be clearer to read if you took out both the "With" and "this".
> I've re-ordered it some more:
>
> __get_page_type(), so far using an on-stack CPU mask variable, is
> involved in recursion when e.g. pinning page tables. This means there
> may be up to five instances of the function active at a time, implying
> five instances of the (up to 512 bytes large) CPU mask variable. An IRQ
> happening at the deepest point of the stack has been observed to cause
> a stack overflow with a 4095-pCPU build, when the IRQ handling results
> in send_guest_pirq() being called (leading to vcpu_kick() -> ... ->
> csched_vcpu_wake() -> __runq_tickle() -> cpumask_raise_softirq(), the
> last two of which also have CPU mask variables on their stacks).
>
> Does this suit you better?

Much clearer, thanks.

~Andrew

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

Re: [Xen-devel] [PATCH v2 2/8] dm_op: convert HVMOP_*ioreq_server*

[Jan Beulich]

>>> On 06.12.16 at 14:46,  wrote:
>  switch ( op.op )
>  {
> +case XEN_DMOP_create_ioreq_server:
> +{
> +struct domain *curr_d = current->domain;
> +struct xen_dm_op_create_ioreq_server *data =
> +_ioreq_server;
> +
> +rc = -EINVAL;
> +if ( data->pad )

You only check the first of three bytes. With that taken care of,
hypervisor parts
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH v2 1/8] public / x86: Introduce __HYPERCALL_dm_op...

[Jan Beulich]

>>> On 06.12.16 at 14:46,  wrote:
> ...as a set of hypercalls to be used by a device model.
> 
> As stated in the new docs/designs/dm_op.markdown:
> 
> "The aim of DMOP is to prevent a compromised device model from
> compromising domains other then the one it is associated with. (And is
> therefore likely already compromised)."
> 
> See that file for further information.
> 
> This patch simply adds the boilerplate for the hypercall.
> 
> Signed-off-by: Paul Durrant 
> Suggested-by: Ian Jackson 
> Suggested-by: Jennifer Herbert 

Hypervisor parts
Reviewed-by: Jan Beulich 
albeit with one more question/adjustment request:

> +struct xen_dm_op_buf {
> +XEN_GUEST_HANDLE(void) h;
> +uint64_aligned_t size;

Does size need to be 64 bits wide? I thing 32 should suffice, even if
that won't shrink structure size (because the handle really wants to
be XEN_GUEST_HANDLE_64() for a tool stack-only interface which
we don't want to have a compat wrapper for).

Jan


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

[Xen-devel] [xtf test] 103339: all pass - PUSHED

[osstest service owner]

flight 103339 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103339/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  5f54a923b496210af833b902afcc56b1982818a4
baseline version:
 xtf  1f021c88130b4d2d818ba4f269b3929339c00a88

Last test of basis   102740  2016-11-30 19:45:46 Z   14 days
Testing same since   103339  2016-12-14 13:48:15 Z1 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   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=xtf
+ revision=5f54a923b496210af833b902afcc56b1982818a4
+ . ./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 xtf 
5f54a923b496210af833b902afcc56b1982818a4
+ branch=xtf
+ revision=5f54a923b496210af833b902afcc56b1982818a4
+ . ./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=xtf
+ xenbranch=xen-unstable
+ '[' xxtf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' x5f54a923b496210af833b902afcc56b1982818a4 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : 

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

[Ian Jackson]

Ian Jackson writes ("Re: [xen-4.5-testing test] 103161: regressions - FAIL"):
> Andrew Cooper writes ("Re: [xen-4.5-testing test] 103161: regressions - 
> FAIL"):
> > These leak check failures are because the XSA-195 PoC is somehow causing
> > qemu to segfault.  I cant explain why, because qemu should be involved
> > at all, and it is especially suspicious that it is only older branches
> > where this happens.
> 
> As we discussed yesterday, while this may be a real bug, I think it is
> not really a _regression_ in the sense that the osstest baseline
> version has the same bug.
> 
> I therefore propose to do a force push of 4.4 too.

I have now done this.  I force pushed this version:

osstest service owner writes ("[xen-4.4-testing test] 103240: regressions - 
FAIL"):
> flight 103240 xen-4.4-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/103240/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-xtf-amd64-amd64-3 20 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 102521
>  test-xtf-amd64-amd64-3 42 xtf/test-hvm64-invlpg~shadow fail REGR. vs. 102521
>  test-xtf-amd64-amd64-3 31 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 
> 102521

These are expected.

>  test-xtf-amd64-amd64-4   52 leak-check/check fail REGR. vs. 102521
>  test-xtf-amd64-amd64-5   52 leak-check/check fail REGR. vs. 102521
>  test-xtf-amd64-amd64-1   52 leak-check/check fail REGR. vs. 102521
>  test-xtf-amd64-amd64-3   52 leak-check/check fail REGR. vs. 102521
>  test-xtf-amd64-amd64-2   52 leak-check/check fail REGR. vs. 102521

This is the known qemu crash, see above.

>  test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail REGR. vs. 
> 102521

This test seems to be slightly unreliable.  It would be nice to know
why but in any case it's not a regression on the Xen 4.4 branch.

> version targeted for testing:
>  xen  149c34a6ea0c6821620554059e85cb89acf0ff8f

So pushed this.

Later flights have more failures in, which is why I picked this one.

Ian.

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

Re: [Xen-devel] Ping: [PATCH v2 RESEND] x86/time: correctly honor late clearing of TSC related feature flags

[Jan Beulich]

>>> On 15.12.16 at 12:04,  wrote:
> On 15/12/16 09:49, Jan Beulich wrote:
> On 06.12.16 at 11:51,  wrote:
>>> As such clearing of flags may have an impact on the selected rendezvous
>>> function, handle such in a central place.
>>>
>>> But don't allow such feature flags to be cleared during CPU hotplug:
>>> Platform and local system times may have diverged significantly by
>>> then, potentially causing noticably (even if only temporary) strange
>>> behavior. As we're anyway expecting only sufficiently similar CPUs to
>>> appear during hotplug, this shouldn't be introducing new limitations.
>>>
>>> Reported-by: Joao Martins 
>>> Signed-off-by: Jan Beulich 
>>> Tested-by: Dario Faggioli 
>>> Tested-by: Joao Martins 
>>> ---
>>> The resend is mainly to get the discussion going again on what the
>>> alternatives are, if this patch is not acceptable.
>> Even if you don't agree with the patch, can we at least revive
>> the discussion of what alternatives there are?
> 
> Sorry - it slipped through the cracks.  I have no issue with the
> principle of the patch.
> 
> The only problem I have, which we didn't sort out last time, is the
> initialisation of rendezvous_fn
> 
> It is still my opinion that under no circumstance is it ok for
> clear_tsc_cap() to modify time_calibration_rendezvous_fn from
> time_calibration_tsc_rendezvous to time_calibration_std_rendezvous,
> which can in principle happen because rendezvous_fn doesn't get
> initialised from the current time_calibration_rendezvous_fn.

I understand that this is your primary reservation against the patch,
yet at the same time this is also the purpose of the patch. If we're
not allowed to change the rendezvous function to what it is supposed
to be given the final set of CPU features we determined, then the
whole patch is pointless. At the time we first set the pointer, we
simply don't know yet what we'll find once we brought up APs. If we
knew, we'd set it differently. Since pre- and post-AP bringup
knowledge will always have the potential to differ, we need to adjust
the function pointer in one direction anyway: Either we set it to std
early, and switch to tsc later, or we allow setting it to tsc early,
reverting to std if need be.

Jan


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

[Xen-devel] [PATCH 1/2] cpu/hotplug: Clarify description of __cpuhp_setup_state() return value

[Boris Ostrovsky]

When ivoked with CPUHP_AP_ONLINE_DYN state __cpuhp_setup_state()
is expected to return positive value which is the hotplug state that
the routine assigns.

Signed-off-by: Boris Ostrovsky 
---

 kernel/cpu.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/kernel/cpu.c b/kernel/cpu.c
index 217fd2e..5339aca 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -1586,7 +1586,11 @@ int __cpuhp_state_add_instance(enum cpuhp_state state, 
struct hlist_node *node,
  * @startup:   startup callback function
  * @teardown:  teardown callback function
  *
- * Returns 0 if successful, otherwise a proper error code
+ * Returns:
+ *   On success:
+ *  Positive state number if @state is CPUHP_AP_ONLINE_DYN
+ *  0 for all other states
+ *   On failure: proper (negative) error code
  */
 int __cpuhp_setup_state(enum cpuhp_state state,
const char *name, bool invoke,
-- 
1.7.1


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

[Xen-devel] [PATCH 2/2] cpufreq: Remove cpu hotplug callbacks only if they were initialized

[Boris Ostrovsky]

Since cpu hotplug callbacks are requested for CPUHP_AP_ONLINE_DYN state,
successful callback initialization will result in cpuhp_setup_state()
returning a positive value. Therefore acpi_cpufreq_online being zero
indicates that callbacks have not been installed.

This means that acpi_cpufreq_boost_exit() should only remove them if
acpi_cpufreq_online is positive. Trying to call
cpuhp_remove_state_nocalls(0) will cause a BUG().

Signed-off-by: Boris Ostrovsky 
---
 drivers/cpufreq/acpi-cpufreq.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 3a98702..3a2ca0f 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -930,7 +930,7 @@ static void __init acpi_cpufreq_boost_init(void)
 
 static void acpi_cpufreq_boost_exit(void)
 {
-   if (acpi_cpufreq_online >= 0)
+   if (acpi_cpufreq_online > 0)
cpuhp_remove_state_nocalls(acpi_cpufreq_online);
 }
 
-- 
1.7.1


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

Re: [Xen-devel] Ping: Re: [PATCH 2/2] x86: drop cpu_has_sse{,2}

[Jan Beulich]

>>> On 15.12.16 at 13:03,  wrote:
> On 15/12/16 09:57, Jan Beulich wrote:
> On 09.12.16 at 16:27,  wrote:
>> On 09.12.16 at 16:19,  wrote:
>>> On 09.12.16 at 15:56,  wrote:
> It is a layering violation to remove the host_has_* part of the check
> from the emulator.
 This is from a very, very abstract perspective. The fact that
 host_and_vcpu_*() and vcpu_*() are the same in the harness
 should allow for them to be used interchangeably when only the
 harness is affected.
>>> I should add that in a subsequent patch adding emulation of
>>> LDDQU (an SSE3 insn) this is going to be done by slightly
>>> extending the existing MOVDQ{U,A} etc block, i.e. using an
>>> SSE2 insn. If I was to follow your directions, I'd have to add
>>> separate host_has(sse2) and vcpu_has(sse3) checks. That's
>>> just going to become insane. I have just the vcpu check in
>>> there, and I really hope you won't force me to uglify that.
>> And one more which did stall. Meanwhile I've submitted patches
>> falling into the above category, which should help making a
>> judgment here.
> 
> I am sorry, but I remain unconvinced by these arguments.
> 
> The rule governing the use host_and_vcpu_*() is a) correct, and b) very
> clear when it comes to using instructions from certain classes as part
> of emulation.
> 
> In particular, a 32bit build of the emulator should not crash even if
> there is junk in the cpuid policy.

And it doesn't. Once again - the comment you refer to is relevant
for the hypervisor only (which its placement tries to make obvious).
For the harness, the host and vcpu checks are equivalent.

Did you look at some of those newer patches, to estimate how odd it
would be to add separate vcpu_must_have() and host_must_have()
checks? Given the (growing) size of the part of the code base, I think
we should always strive for as concise code as possible - no
unnecessary clutter or anything. Much of my recent code folding was
motivated by that, and I appreciate your recent recognition of further
opportunities in that area.

> This means either, we drop support for 32bit builds of the emulator, or
> retain the proper host_and_vcpu_*() checks.
> 
> 
> An alternative which comes to mind and hasn't been discussed yet, would
> be to formally require a 64bit cpu as a minimum requirement, even for
> 32bit builds.  In fact, I think we should have rather more written
> documentation anyway (possibly at the head of x86_emulate.c), including
> the instruction groups and behaviours we expect to be implemented, and
> which we expect to currently be missing.
> 
> If we had a formal statement of requiring a 64bit-capable CPU for
> running the emulator, I'd be happy to relax the checks based on the
> assumptions we are permitted to make.

Well, if I really can't convince you, I wouldn't see any issue with
documenting such a requirement (albeit it's not really clear where
that would best go, as putting it at the top of some of the files'
would imo make it likely to be overlooked by anyone not specifically
searching for any such statement).

Jan


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

Re: [Xen-devel] [PATCH 3/3] x86: introduce and use scratch CPU mask

[Jan Beulich]

>>> On 15.12.16 at 15:15,  wrote:
> On 09/12/16 08:59, Jan Beulich wrote:
> On 08.12.16 at 18:51,  wrote:
>>> On 08/12/16 16:02, Jan Beulich wrote:
 variable. With an IRQ happening at the deepest point of the stack, and
 with send_guest_pirq() being called from there (leading to vcpu_kick()
 -> ... -> csched_vcpu_wake() -> __runq_tickle() ->
 cpumask_raise_softirq(), the last two of which also have CPU mask
 variables on their stacks), this has been observed to cause a stack
>>> "stacks), has been".
>> Hmm, that looks strange to me: Wouldn't the dropping of "this"
>> also requite the "With" at the start of the sentence to be dropped
>> (and isn't the sentence okay with both left in place)?
> 
> The use of "this" requires a substantial backtrack through the text to
> evaluate what it refers to, which as you point, I didn't manage to do
> successfully. 
> 
> As is evident, I had a very hard time trying to parse the sentence.
> 
> It would be clearer to read if you took out both the "With" and "this".

I've re-ordered it some more:

__get_page_type(), so far using an on-stack CPU mask variable, is
involved in recursion when e.g. pinning page tables. This means there
may be up to five instances of the function active at a time, implying
five instances of the (up to 512 bytes large) CPU mask variable. An IRQ
happening at the deepest point of the stack has been observed to cause
a stack overflow with a 4095-pCPU build, when the IRQ handling results
in send_guest_pirq() being called (leading to vcpu_kick() -> ... ->
csched_vcpu_wake() -> __runq_tickle() -> cpumask_raise_softirq(), the
last two of which also have CPU mask variables on their stacks).

Does this suit you better?

Jan


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

[Xen-devel] [PATCH 0/2] __cpuhp_setup_state() returns positive value for dynamic state

[Boris Ostrovsky]

The first patch corrects description of __cpuhp_setup_state()'s possible
return values and the second fixes a bug (which causes Xen guests to crash).

As a follow-up question for the first patch --- should we allow calling
__cpuhp_setup_state() with state in [CPUHP_AP_ONLINE_DYN + 1 .. 
CPUHP_AP_ONLINE_DYN_END]
range?

Boris Ostrovsky (2):
  cpu/hotplug: Clarify description of __cpuhp_setup_state() return
value
  cpufreq: Remove cpu hotplug callbacks only if they were initialized

 drivers/cpufreq/acpi-cpufreq.c |2 +-
 kernel/cpu.c   |6 +-
 2 files changed, 6 insertions(+), 2 deletions(-)


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

Re: [Xen-devel] Ping: Re: [PATCH 2/3] VT-d: correct dma_msi_set_affinity()

[Jan Beulich]

>>> On 15.12.16 at 13:52,  wrote:
> On 15/12/16 09:54, Jan Beulich wrote:
> On 09.12.16 at 09:47,  wrote:
>> On 08.12.16 at 18:33,  wrote:
 On 08/12/16 16:01, Jan Beulich wrote:
> That commit ("VT-d: use msi_compose_msg()) together with 15aa6c6748
 Which commit?
>>> Oops - initially I had intended the title to include the hash: 83cd2038fe.
>>> I've adjusted the text.
>>>
> ("amd iommu: use base platform MSI implementation") introducing the use
> of a per-CPU scratch CPU mask went too far: dma_msi_set_affinity() may,
> at least in theory, be called in interrupt context, and hence the use
> of that scratch variable is not correct.
>
> Since the function overwrites the destination information anyway,
> allow msi_compose_msg() to be called with a NULL CPU mask, avoiding the
> use of that scratch variable.
 Which function overwrites what?  I can't see dma_msi_set_affinity()
 doing anything to clobber msg.dest32, so I don't understand why this
 change is correct.
>>> msg.dest32 simply isn't being used. msg is local to that function, so
>>> all that matters is which fields the function consumes. Is uses only
>>> address and data, and updates address to properly specify the
>>> intended destination. To guard against stale data (in
>>> iommu->msi.msg), it may be reasonable to nevertheless set dest32
>>> before storing msg into that field.
>> Any further thoughts here? Do I need to resend with that one line
>> added?
> 
> msg is tiny.  I'd suggest just initialising to 0 at the start of the
> function.

Why? msi_compose_msg() does exactly that as its very first action.

Jan


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

Re: [Xen-devel] [PATCH 3/3] x86: introduce and use scratch CPU mask

[Andrew Cooper]

On 09/12/16 08:59, Jan Beulich wrote:
 On 08.12.16 at 18:51,  wrote:
>> On 08/12/16 16:02, Jan Beulich wrote:
>>> variable. With an IRQ happening at the deepest point of the stack, and
>>> with send_guest_pirq() being called from there (leading to vcpu_kick()
>>> -> ... -> csched_vcpu_wake() -> __runq_tickle() ->
>>> cpumask_raise_softirq(), the last two of which also have CPU mask
>>> variables on their stacks), this has been observed to cause a stack
>> "stacks), has been".
> Hmm, that looks strange to me: Wouldn't the dropping of "this"
> also requite the "With" at the start of the sentence to be dropped
> (and isn't the sentence okay with both left in place)?

The use of "this" requires a substantial backtrack through the text to
evaluate what it refers to, which as you point, I didn't manage to do
successfully. 

As is evident, I had a very hard time trying to parse the sentence.

It would be clearer to read if you took out both the "With" and "this".

>
>>> @@ -2509,20 +2510,21 @@ static int __get_page_type(struct page_i
>>>   * may be unnecessary (e.g., page was GDT/LDT) but those 
>>>   * circumstances should be very rare.
>>>   */
>>> -cpumask_t mask;
>>> +cpumask_t *mask = this_cpu(scratch_cpumask);
>> This indirection looks suspicious.  Why do you have a per_cpu pointer to
>> a cpumask, with a dynamically allocated mask?
>>
>> It would be smaller and more efficient overall to have a fully cpumask
>> allocated in the per-cpu area, and use it via
> Well, as you can see from the smpboot.c context of the
> modifications done, that's how other masks are being dealt with
> too. The reasoning is that it is quite wasteful to pre-allocate 512
> bytes for a CPU mask when on the running system perhaps only
> the low few bytes will be used.
>
> Overall I'm getting the impression from your comments that you
> simply didn't recognize the use of cpumask_t vs cpumask_var_t
> in the various places.

Ok - on the basis that this is the same as the prevailing uses,

Acked-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH] x86/boot: fix build with certain older gcc versions

[Andrew Cooper]

On 15/12/16 14:04, Jan Beulich wrote:
> Despite all attempts so far (ending in commit fecf584294 ["Config.mk:
> fix comment for debug option"] adjusting the respective comment),
> Config.mk's debug= setting still affects the hypervisor build: CFLAGS
> gets -g added there.
>
> xen/arch/x86/boot/build32.mk includes that file, and hence inherits the
> setting too. Some gcc versions take -g to create an .eh_frame section
> despite -fno-asynchronous-unwind-tables (which instead one would expect
> to produce .debug_frame).
>
> In turn, commit 93c0c0287a ("x86/boot: create *.lnk files with linker
> script") was - in my understanding - supposed to make sure .text is
> first, but apparently it did also not really achieve that effect: Both
> reloc.lnk and reloc.bin in the case here ended up with .eh_frame first,
> which obviously rendered the whole final binary unusable.
>
> Explicitly suppress generation of any kind of debug info when building
> reloc.o.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

[Xen-devel] [PATCH] x86/boot: fix build with certain older gcc versions

[Jan Beulich]

Despite all attempts so far (ending in commit fecf584294 ["Config.mk:
fix comment for debug option"] adjusting the respective comment),
Config.mk's debug= setting still affects the hypervisor build: CFLAGS
gets -g added there.

xen/arch/x86/boot/build32.mk includes that file, and hence inherits the
setting too. Some gcc versions take -g to create an .eh_frame section
despite -fno-asynchronous-unwind-tables (which instead one would expect
to produce .debug_frame).

In turn, commit 93c0c0287a ("x86/boot: create *.lnk files with linker
script") was - in my understanding - supposed to make sure .text is
first, but apparently it did also not really achieve that effect: Both
reloc.lnk and reloc.bin in the case here ended up with .eh_frame first,
which obviously rendered the whole final binary unusable.

Explicitly suppress generation of any kind of debug info when building
reloc.o.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/boot/build32.mk
+++ b/xen/arch/x86/boot/build32.mk
@@ -4,7 +4,7 @@ include $(XEN_ROOT)/Config.mk
 
 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
 
-CFLAGS += -Werror -fno-asynchronous-unwind-tables -fno-builtin -msoft-float
+CFLAGS += -Werror -fno-asynchronous-unwind-tables -fno-builtin -g0 -msoft-float
 CFLAGS := $(filter-out -flto,$(CFLAGS)) 
 
 # NB. awk invocation is a portable alternative to 'head -n -1'



x86/boot: fix build with certain older gcc versions

Despite all attempts so far (ending in commit fecf584294 ["Config.mk:
fix comment for debug option"] adjusting the respective comment),
Config.mk's debug= setting still affects the hypervisor build: CFLAGS
gets -g added there.

xen/arch/x86/boot/build32.mk includes that file, and hence inherits the
setting too. Some gcc versions take -g to create an .eh_frame section
despite -fno-asynchronous-unwind-tables (which instead one would expect
to produce .debug_frame).

In turn, commit 93c0c0287a ("x86/boot: create *.lnk files with linker
script") was - in my understanding - supposed to make sure .text is
first, but apparently it did also not really achieve that effect: Both
reloc.lnk and reloc.bin in the case here ended up with .eh_frame first,
which obviously rendered the whole final binary unusable.

Explicitly suppress generation of any kind of debug info when building
reloc.o.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/boot/build32.mk
+++ b/xen/arch/x86/boot/build32.mk
@@ -4,7 +4,7 @@ include $(XEN_ROOT)/Config.mk
 
 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
 
-CFLAGS += -Werror -fno-asynchronous-unwind-tables -fno-builtin -msoft-float
+CFLAGS += -Werror -fno-asynchronous-unwind-tables -fno-builtin -g0 -msoft-float
 CFLAGS := $(filter-out -flto,$(CFLAGS)) 
 
 # NB. awk invocation is a portable alternative to 'head -n -1'
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-xsm   11 guest-start  fail REGR. vs. 103209
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 103209

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 103209
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 103209
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 103209
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 103209
 test-armhf-armhf-xl-rtds 11 guest-start  fail  like 103209
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 103209
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 103209
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 103209
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 103209

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-2   61 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-1   61 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-xtf-amd64-amd64-3   61 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-xtf-amd64-amd64-5   61 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-4   61 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass

version targeted for testing:
 xen  ac699ed4c45a4ea4f93d366b9185d62795ffdf48
baseline version:
 xen  57e3ac3a0bceb33093bed584194c7cf163648441

Last test of basis   103209  2016-12-12 16:08:49 Z2 days
Testing same since   103323  2016-12-14 08:48:32 Z1 days1 attempts


People who touched revisions under test:
  Jan Beulich 

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

Re: [Xen-devel] [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]

[Kevin Grittner]

On Thu, Dec 15, 2016 at 6:09 AM, Ian Jackson  wrote:

> However, in that example, as you seem to allude to, there is still a
> complete serialisation of all the transactions, even the failed T3:
> T1,T2,T3.  The database has detected the problem before returning data
> in T3 that would contradict the serialisation order.

In that case, yes.  Thinking about it, I suspect that a read-only
transaction will never actually return results that need to be
ignored.  Let me take a quick run at an argument to support that.
I'm working from the previous conclusion about read-only
transactions: that the read-only transaction will only be the one
to experience serialization failure if the other two transactions
involved in the "dangerous structure" have already committed
without developing a serialization failure, and the failure will be
detected during a read of the data by the read-only transaction --
never during commit.  Catching the initial exception and trying to
suppress it can cause it to resurface on the commit, but it would
have been initially detected and a serialization error thrown on
the read, but even if it is re-thrown on the commit, the initial
exception would have prevented the data which contradicted
already-committed state from being returned.

I also realized some other properties of read-only transactions
that might interest you (and that I should probably document).
Since the only way for a read-only transaction to be the on
experiencing a serialization failure is if Tout commits before the
read-only transaction (which is always Tin) acquires its snapshot,
Tpivot is still running when Tin acquires its snapshot, Tpivot
commits before a serialization failure involving Tin is detected,
and *then* Tin reads a data set affected by the writes of Tpivot.
Since a snapshot is only acquired when a statement is run which
requires a snapshot, that means that a query run in an implicit
transaction (i.e., there is no START or BEGIN statement to
explicitly start it; the SELECT or other data-accessing statement
automatically starts the transaction so it has a valid context in
which to run) that does not write data can never return bad results
nor receive a serialization failure.  Nor can those things happen
on the *first* or *only* non-writing statement in an explicit
transaction.

> The thing that was puzzling me, after having slept on it, and before I
> read your mail, was how it could happen that the serialisation failure
> (of a transaction that did only reads) would only be detected at
> commit.  The point about attempts to suppress the serialisation
> failure is part of the answer to that.  Are there other reasons,
> besides previously suppressed serialisation failures, why commit of a
> transaction that did only reads[1] might fail ?

I'm pretty confident that if you're not using prepared transactions
the answer is "no".  Our initial implementation of serializable
prepared transactions was found to have a bug after crash and when
dealing with the persisted data found during recovery.  The safest
way to fix that on stable branches was, until those prepared
transactions which were found during recovery were committed or
rolled back, to be *very* eager to throw serialization failures for
any new transactions which developed a rw-dependency with them.
This can be improved, but I fear that until and unless that
happens, if "pre-crash" prepared transactions are still open, some
of the deductions above may not hold.  If you don't use prepared
transactions, or promptly clean up any that were pending when a
server crashes, that should not be a problem, but it's probably
worth mentioning.

One other situation in which I'm not entirely sure, and it would
take me some time to review code to be sure, is if
max_pred_locks_per_transaction is not set high enough to
accommodate tracking all serializable transactions in allocated RAM
(recognizing that they must often be tracked after commit, until
overlapping serializable transactions commit), we have a mechanism
to summarize some of the committed transactions and spill them to
disk (using an internal SLRU module).  The summarized data might
not be able to determine all of the above as precisely as the
"normal" data tracked in RAM.  To avoid this, be generous when
setting max_pred_locks_per_transaction; not only will it avoid this
summarization, but it will reduce the amount of summarization of
multiple page locks in the predicate locking system to relation
locks.  Coarser locks increase the "false positive" rate of
serialization failures, reducing performance.

> [1] I mean to include transactions which don't update even if they're
> not explicitly declared `read only', so that the application retained
> (until it said to commit) the option to try to make changes.

There is an attempt to recognize, at commit time, *implicit*
read-only transactions -- those that, in spite of not being
*declared* as READ ONLY never wrote any data.  Although these 

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

[Julien Grall]

On 14/12/16 21:18, Edgar E. Iglesias wrote:

On Wed, Dec 14, 2016 at 03:59:00PM +0100, Dario Faggioli wrote:

On Tue, 2016-12-13 at 19:00 +, Julien Grall wrote:

Hi all,

Stefano suggested to move the call at 5pm and I haven't seen any
disagreement.

So the call will be tomorrow (Wednesday 14th December at 5pm).



Hi all,


Hi Edgar,



Thanks for the call today. I'm sending a link to EEMI the
power management framework that Xilinx co-developed with Aggios.
I don't have a link to the ARM specs for SCMI. I found some slides
though. Perhaps Julien has specs?


Thank you for the link, I will add them in the meeting minutes.

Regarding SCMI, the spec is not yet public but can be downloaded under 
NDA (see the link at the end of the slides you sent).


Cheers,

--
Julien Grall


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

[Xen-devel] [xen-unstable-smoke test] 103401: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   5 libvirt-buildfail REGR. vs. 103284

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

version targeted for testing:
 xen  6e616a3cef4d782253787904bf3d641112eafa14
baseline version:
 xen  fc9229c4bb35c5474fbc67f78e628dcbcc90afc5

Last test of basis   103284  2016-12-13 19:03:56 Z1 days
Failing since103292  2016-12-13 22:19:08 Z1 days   14 attempts
Testing same since   103401  2016-12-15 11:15:56 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Cédric Bosdonnat 
  Haozhong Zhang 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Konrad Rzeszutek Wilk 
  Razvan Cojocaru 
  Ross Lagerwall 
  Stefano Stabellini 
  Suravee Suthikulpanit 
  Tamas K Lengyel 
  Tim Deegan 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  fail
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt 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.

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

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