Re: [Xen-devel] [PATCH v2] x86/compat: fix compilation errors with clang 6

[Jan Beulich]

>>> On 23.01.18 at 15:36,  wrote:
> The following errors are generated when compiling Xen with clang 6:
> 
> In file included from x86_64/asm-offsets.c:9:
> In file included from /root/src/xen/xen/include/xen/sched.h:8:
> In file included from /root/src/xen/xen/include/xen/shared.h:6:
> In file included from /root/src/xen/xen/include/compat/arch-x86/../xen.h:9:
> /root/src/xen/xen/include/compat/arch-x86/xen.h:10:10: error: the current 
> #pragma pack aligment
>   value is modified in the included file [-Werror,-Wpragma-pack]
> #include "xen-x86_32.h"
>  ^
> /root/src/xen/xen/include/compat/arch-x86/xen-x86_32.h:40:9: note: previous 
> '#pragma pack'
>   directive that modifies alignment is here
> #pragma pack()
> ^
> In file included from x86_64/asm-offsets.c:9:
> In file included from /root/src/xen/xen/include/xen/sched.h:8:
> In file included from /root/src/xen/xen/include/xen/shared.h:6:
> /root/src/xen/xen/include/compat/arch-x86/../xen.h:9:10: error: the current 
> #pragma pack aligment
>   value is modified in the included file [-Werror,-Wpragma-pack]
> #include "arch-x86/xen.h"
>  ^
> /root/src/xen/xen/include/compat/arch-x86/xen.h:71:9: note: previous 
> '#pragma pack' directive that
>   modifies alignment is here
> #pragma pack()
> ^
> 2 errors generated.
> 
> Fix this by using pragma push/pop in order to store the current pragma
> value in the compiler stack and later restoring it when using clang.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Jan Beulich 


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

Re: [Xen-devel] [Xen EFI] Impossible to limit the dom0 memory

[Jan Beulich]

>>> On 23.01.18 at 18:43,  wrote:
>>  Yet you'll need to provide the kernel messages
> 
> I attached a console log "xen-console-log.txt".
> 
> Here, Xen crash even without the "dom0_mem=1G,max:1G" option :

Xen doesn't crash at all. It's the Dom0 kernel which panics, but
the log doesn't tell me why it does (other than _something_
having tried to exit the init process). This doesn't look Xen related
at all with the provided information.

Jan


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

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

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 linux1995266727fa8143897e89b55f5d3c79aa828420
baseline version:
 linuxd517bb79f4994a87cfc2ddd4cc76bd1a627d4bed

Last test of basis   118250  2018-01-21 06:48:31 Z3 days
Failing since118263  2018-01-21 23:17:15 Z2 days4 attempts
Testing same since   118283  2018-01-23 13:28:30 Z0 days1 attempts


People who touched revisions under test:
  Andi Kleen 
  Ben Hutchings 
  Dave Young 
  David Woodhouse 
  J. Bruce Fields 
  Keith Busch 
  Kirill A. Shutemov 
  Linus Torvalds

Re: [Xen-devel] Xen fails to boot inside QEMU on x86, no VMX:

[Jan Beulich]

>>> On 24.01.18 at 01:47,  wrote:
> On Tue, 23 Jan 2018, Jan Beulich wrote:
>> >>> On 23.01.18 at 01:41,  wrote:
>> > On 23/01/2018 00:38, Stefano Stabellini wrote:
>> >> On Tue, 23 Jan 2018, Andrew Cooper wrote:
>> >>> On 22/01/2018 23:48, Stefano Stabellini wrote:
>>  Hi all,
>> 
>>  Running Xen inside QEMU x86 without KVM acceleartion and without VMX
>>  emulation leads to the failure appended below.
>> 
>>  This trivial workaround "fixes" the problem:
>> 
>>  diff --git a/xen/arch/x86/extable.c b/xen/arch/x86/extable.c
>>  index 72f30d9..a67d6c1 100644
>>  --- a/xen/arch/x86/extable.c
>>  +++ b/xen/arch/x86/extable.c
>>  @@ -168,7 +168,6 @@ static int __init stub_selftest(void)
>>  _ASM_EXTABLE(.Lret%=, .Lfix%=)
>>  : [exn] "+m" (res)
>>  : [stb] "r" (addr), "a" (tests[i].rax));
>>  -ASSERT(res == tests[i].res.raw);
>>   }
>>   
>>   return 0;
>> 
>> 
>>  Any suggestions?
>> >>> Which i failed?  This will probably be an emulation bug in Qemu.
>> >> i=2 is the culprit
>> > 
>> > Qemu doesn't emulate %rsp-based memory accesses properly.  It should
>> > raise #SS[0], and is presumably raising #GP[0] instead.
>> 
>> Right, the value on %rax supports that suspicion. Dropping the
>> ASSERT() is no option, of course. If we were able to reliably
>> detect that we're running under qemu, we could cater for this
>> special case, but I can't seem to be able to think of other options
>> besides adding a command line option allowing to bypass the self
>> test.
> 
> I am going to give a look at the QEMU side of things. However, even if I
> fix the bug in QEMU, it won't solve the problem for all the QEMU
> instances already out there, shipped by distros, etc.
> 
> So, I think that regardless of the QEMU fix, we also need to add a
> workaround in Xen. We can detect QEMU from the cpuid string, which is
> going to be TCGTCGTCGTCG.
> 
> What do you think of something like below?

Well, not really nice, but what do you do. In a cleaned up form
this may well be acceptable.

Jan

> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
> index 6cf3628..471e394 100644
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -280,6 +280,21 @@ static void __init early_cpu_detect(void)
>   initialize_cpu_data(0);
>  }
>  
> +bool tcg_workaround = false;
> +static inline void hypervisor_cpuid_base(struct cpuinfo_x86 *c)
> +{
> + uint32_t base, eax, signature[3];
> + char *sig = "TCGTCGTCGTCG";
> +
> + if ( c->phys_proc_id )
> + return;
> +
> + base = 0x4000;
> + cpuid(base, &eax, &signature[0], &signature[1], &signature[2]);
> + if ( !memcmp(sig, signature, 12) )
> + tcg_workaround = true;
> +}
> +
>  static void generic_identify(struct cpuinfo_x86 *c)
>  {
>   u32 eax, ebx, ecx, edx, tmp;
> @@ -343,6 +358,8 @@ static void generic_identify(struct cpuinfo_x86 *c)
>   
> &c->x86_capability[cpufeat_word(X86_FEATURE_FSGSBASE)],
>   &c->x86_capability[cpufeat_word(X86_FEATURE_PKU)],
>   
> &c->x86_capability[cpufeat_word(X86_FEATURE_AVX512_4VNNIW)]);
> +
> + hypervisor_cpuid_base(c);
>  }
>  
>  /*
> diff --git a/xen/arch/x86/extable.c b/xen/arch/x86/extable.c
> index 6fffe05..6c8ca3d 100644
> --- a/xen/arch/x86/extable.c
> +++ b/xen/arch/x86/extable.c
> @@ -146,6 +146,9 @@ static int __init stub_selftest(void)
>  unsigned long addr = this_cpu(stubs.addr) + STUB_BUF_SIZE / 2;
>  unsigned int i;
>  
> +if ( tcg_workaround )
> +return 0;
> +
>  printk("Running stub recovery selftests...\n");
>  
>  for ( i = 0; i < ARRAY_SIZE(tests); ++i )
> diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
> index 41a8d8c..dfc4537 100644
> --- a/xen/include/asm-x86/processor.h
> +++ b/xen/include/asm-x86/processor.h
> @@ -556,6 +556,7 @@ int early_microcode_update_cpu(bool start_update);
>  int early_microcode_init(void);
>  int microcode_init_intel(void);
>  int microcode_init_amd(void);
> +extern bool tcg_workaround;
>  
>  enum get_cpu_vendor {
>  gcv_host,



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

Re: [Xen-devel] [PATCH RFC v2 00/12] xen/x86: use per-vcpu stacks for 64 bit pv domains

[Jan Beulich]

>>> On 23.01.18 at 18:33,  wrote:
> Well at very least there should be something in the boot scrool that
> says, "Enabling Xen Pagetable protection (XPTI) for PV guests" or
> something.  (That goes for the current round of XPTI as well really.)

And indeed I have this on my list of follow-up things, but didn't get
to it yet.

Jan


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

[Xen-devel] [PATCH AUTOSEL for 4.14 098/100] x86/xen: Support early interrupts in xen pv guests

[Sasha Levin]

From: Juergen Gross 

[ Upstream commit 42b3a4cb5609de757f5445fcad18945ba9239a07 ]

Add early interrupt handlers activated by idt_setup_early_handler() to
the handlers supported by Xen pv guests. This will allow for early
WARN() calls not crashing the guest.

Suggested-by: Andy Lutomirski 
Signed-off-by: Juergen Gross 
Signed-off-by: Thomas Gleixner 
Cc: xen-devel@lists.xenproject.org
Cc: boris.ostrov...@oracle.com
Link: https://lkml.kernel.org/r/20171124084221.30172-1-jgr...@suse.com
Signed-off-by: Sasha Levin 
---
 arch/x86/include/asm/segment.h | 12 
 arch/x86/mm/extable.c  |  4 +++-
 arch/x86/xen/enlighten_pv.c| 37 -
 arch/x86/xen/xen-asm_64.S  | 14 ++
 4 files changed, 53 insertions(+), 14 deletions(-)

diff --git a/arch/x86/include/asm/segment.h b/arch/x86/include/asm/segment.h
index b20f9d623f9c..8f09012b92e7 100644
--- a/arch/x86/include/asm/segment.h
+++ b/arch/x86/include/asm/segment.h
@@ -236,11 +236,23 @@
  */
 #define EARLY_IDT_HANDLER_SIZE 9
 
+/*
+ * xen_early_idt_handler_array is for Xen pv guests: for each entry in
+ * early_idt_handler_array it contains a prequel in the form of
+ * pop %rcx; pop %r11; jmp early_idt_handler_array[i]; summing up to
+ * max 8 bytes.
+ */
+#define XEN_EARLY_IDT_HANDLER_SIZE 8
+
 #ifndef __ASSEMBLY__
 
 extern const char 
early_idt_handler_array[NUM_EXCEPTION_VECTORS][EARLY_IDT_HANDLER_SIZE];
 extern void early_ignore_irq(void);
 
+#if defined(CONFIG_X86_64) && defined(CONFIG_XEN_PV)
+extern const char 
xen_early_idt_handler_array[NUM_EXCEPTION_VECTORS][XEN_EARLY_IDT_HANDLER_SIZE];
+#endif
+
 /*
  * Load a segment. Fall back on loading the zero segment if something goes
  * wrong.  This variant assumes that loading zero fully clears the segment.
diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c
index 30bc4812ceb8..9fe656c42aa5 100644
--- a/arch/x86/mm/extable.c
+++ b/arch/x86/mm/extable.c
@@ -1,6 +1,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -212,8 +213,9 @@ void __init early_fixup_exception(struct pt_regs *regs, int 
trapnr)
 * Old CPUs leave the high bits of CS on the stack
 * undefined.  I'm not sure which CPUs do this, but at least
 * the 486 DX works this way.
+* Xen pv domains are not using the default __KERNEL_CS.
 */
-   if (regs->cs != __KERNEL_CS)
+   if (!xen_pv_domain() && regs->cs != __KERNEL_CS)
goto fail;
 
/*
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index ae3a071e1d0f..899a22a02e95 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -622,7 +622,7 @@ static struct trap_array_entry trap_array[] = {
{ simd_coprocessor_error,  xen_simd_coprocessor_error,  false },
 };
 
-static bool get_trap_addr(void **addr, unsigned int ist)
+static bool __ref get_trap_addr(void **addr, unsigned int ist)
 {
unsigned int nr;
bool ist_okay = false;
@@ -644,6 +644,14 @@ static bool get_trap_addr(void **addr, unsigned int ist)
}
}
 
+   if (nr == ARRAY_SIZE(trap_array) &&
+   *addr >= (void *)early_idt_handler_array[0] &&
+   *addr < (void *)early_idt_handler_array[NUM_EXCEPTION_VECTORS]) {
+   nr = (*addr - (void *)early_idt_handler_array[0]) /
+EARLY_IDT_HANDLER_SIZE;
+   *addr = (void *)xen_early_idt_handler_array[nr];
+   }
+
if (WARN_ON(ist != 0 && !ist_okay))
return false;
 
@@ -1261,6 +1269,21 @@ asmlinkage __visible void __init xen_start_kernel(void)
xen_setup_gdt(0);
 
xen_init_irq_ops();
+
+   /* Let's presume PV guests always boot on vCPU with id 0. */
+   per_cpu(xen_vcpu_id, 0) = 0;
+
+   /*
+* Setup xen_vcpu early because idt_setup_early_handler needs it for
+* local_irq_disable(), irqs_disabled().
+*
+* Don't do the full vcpu_info placement stuff until we have
+* the cpu_possible_mask and a non-dummy shared_info.
+*/
+   xen_vcpu_info_reset(0);
+
+   idt_setup_early_handler();
+
xen_init_capabilities();
 
 #ifdef CONFIG_X86_LOCAL_APIC
@@ -1294,18 +1317,6 @@ asmlinkage __visible void __init xen_start_kernel(void)
 */
acpi_numa = -1;
 #endif
-   /* Let's presume PV guests always boot on vCPU with id 0. */
-   per_cpu(xen_vcpu_id, 0) = 0;
-
-   /*
-* Setup xen_vcpu early because start_kernel needs it for
-* local_irq_disable(), irqs_disabled().
-*
-* Don't do the full vcpu_info placement stuff until we have
-* the cpu_possible_mask and a non-dummy shared_info.
-*/
-   xen_vcpu_info_reset(0);
-
WARN_ON(xen_cpuhp_setup(xen_cpu_up_prepare_pv, xen_cpu_dead_pv));
 
local_irq_disable();
diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S
index 8a10c9a9e2b5..417b339e5c8e 10064

[Xen-devel] pvscsi is not supported by xl command

[Dongli Zhang]

Hi Juergen,

Would you please let me know if pvscsi is still supported by the most recent
xen, as 'vscsi' is not supported in domU config file and scsi-attach/scsi-detach
are not supported by xl command.

Are scsi-attach/scsi-detach still on the roadmap and will be added to xl in the
future, or this is deprecated?

I assume the following link is deprecated as 'vscsi' is not supported by xl
command in config file:

https://wiki.xenproject.org/wiki/Paravirtualized_SCSI

Thank you very much!

Dongli Zhang


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. 
vs. 118174
 test-amd64-amd64-xl-qemuu-ws16-amd64 15 guest-saverestore.2 fail REGR. vs. 
118174

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

version targeted for testing:
 xen  a5e7ce9560b408dbdc2f7fb8a58f6209601cc054
baseline version:
 xen  e871e80c38547d9faefc6604532ba3e985e65873

Last test of basis   118174  2018-01-17 17:13:00 Z6 days
Failing since118230  2018-01-19 14:22:44 Z4 days6 attempts
Testing same since   118281  2018-01-23 09:01:16 Z0 days1 attempts


People who touc

Re: [Xen-devel] [PATCH v2] libxl: put RSDP for PVH guest near 4GB

[Boris Ostrovsky]

On 01/18/2018 05:33 AM, Wei Liu wrote:
> On Thu, Jan 18, 2018 at 11:31:32AM +0100, Juergen Gross wrote:
>> Wei,
>>
>> On 01/12/17 15:14, Juergen Gross wrote:
>>> Instead of locating the RSDP table below 1MB put it just below 4GB
>>> like the rest of the ACPI tables in case of PVH guests. This will
>>> avoid punching more holes than necessary into the memory map.
>>>
>>> Signed-off-by: Juergen Gross 
>>> Acked-by: Wei Liu 
>> Mind applying this one?
> Don't worry, it is in my queue.
>
> Will come to this and other patches I accumulated soon.
>
> Wei.

This requires kernel changes, doesn't it?

https://lists.xenproject.org/archives/html/xen-devel/2017-12/msg00714.html

And this series apparently never made it to the tree.

PVH guests are broken now on staging.

-boris



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

Re: [Xen-devel] [PATCH v2 3/3] drop "domain_" prefix from struct domain's dirty CPU mask

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, January 23, 2018 6:17 PM
> 
> It being a field of struct domain is sufficient to recognize its
> purpose.
> 
> Signed-off-by: Jan Beulich 
> Reviewed-by: Wei Liu 
> Reviewed-by: George Dunlap 
> Reviewed-by: Andrew Cooper 
> ---
> v2: White space changes (consolidate split line statements into single
> line ones). Re-base.

Reviewed-by: Kevin Tian 

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

Re: [Xen-devel] Xen fails to boot inside QEMU on x86, no VMX:

[Stefano Stabellini]

On Tue, 23 Jan 2018, Jan Beulich wrote:
> >>> On 23.01.18 at 01:41,  wrote:
> > On 23/01/2018 00:38, Stefano Stabellini wrote:
> >> On Tue, 23 Jan 2018, Andrew Cooper wrote:
> >>> On 22/01/2018 23:48, Stefano Stabellini wrote:
>  Hi all,
> 
>  Running Xen inside QEMU x86 without KVM acceleartion and without VMX
>  emulation leads to the failure appended below.
> 
>  This trivial workaround "fixes" the problem:
> 
>  diff --git a/xen/arch/x86/extable.c b/xen/arch/x86/extable.c
>  index 72f30d9..a67d6c1 100644
>  --- a/xen/arch/x86/extable.c
>  +++ b/xen/arch/x86/extable.c
>  @@ -168,7 +168,6 @@ static int __init stub_selftest(void)
>  _ASM_EXTABLE(.Lret%=, .Lfix%=)
>  : [exn] "+m" (res)
>  : [stb] "r" (addr), "a" (tests[i].rax));
>  -ASSERT(res == tests[i].res.raw);
>   }
>   
>   return 0;
> 
> 
>  Any suggestions?
> >>> Which i failed?  This will probably be an emulation bug in Qemu.
> >> i=2 is the culprit
> > 
> > Qemu doesn't emulate %rsp-based memory accesses properly.  It should
> > raise #SS[0], and is presumably raising #GP[0] instead.
> 
> Right, the value on %rax supports that suspicion. Dropping the
> ASSERT() is no option, of course. If we were able to reliably
> detect that we're running under qemu, we could cater for this
> special case, but I can't seem to be able to think of other options
> besides adding a command line option allowing to bypass the self
> test.

I am going to give a look at the QEMU side of things. However, even if I
fix the bug in QEMU, it won't solve the problem for all the QEMU
instances already out there, shipped by distros, etc.

So, I think that regardless of the QEMU fix, we also need to add a
workaround in Xen. We can detect QEMU from the cpuid string, which is
going to be TCGTCGTCGTCG.

What do you think of something like below?


diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 6cf3628..471e394 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -280,6 +280,21 @@ static void __init early_cpu_detect(void)
initialize_cpu_data(0);
 }
 
+bool tcg_workaround = false;
+static inline void hypervisor_cpuid_base(struct cpuinfo_x86 *c)
+{
+   uint32_t base, eax, signature[3];
+   char *sig = "TCGTCGTCGTCG";
+
+   if ( c->phys_proc_id )
+   return;
+
+   base = 0x4000;
+   cpuid(base, &eax, &signature[0], &signature[1], &signature[2]);
+   if ( !memcmp(sig, signature, 12) )
+   tcg_workaround = true;
+}
+
 static void generic_identify(struct cpuinfo_x86 *c)
 {
u32 eax, ebx, ecx, edx, tmp;
@@ -343,6 +358,8 @@ static void generic_identify(struct cpuinfo_x86 *c)

&c->x86_capability[cpufeat_word(X86_FEATURE_FSGSBASE)],
&c->x86_capability[cpufeat_word(X86_FEATURE_PKU)],

&c->x86_capability[cpufeat_word(X86_FEATURE_AVX512_4VNNIW)]);
+
+   hypervisor_cpuid_base(c);
 }
 
 /*
diff --git a/xen/arch/x86/extable.c b/xen/arch/x86/extable.c
index 6fffe05..6c8ca3d 100644
--- a/xen/arch/x86/extable.c
+++ b/xen/arch/x86/extable.c
@@ -146,6 +146,9 @@ static int __init stub_selftest(void)
 unsigned long addr = this_cpu(stubs.addr) + STUB_BUF_SIZE / 2;
 unsigned int i;
 
+if ( tcg_workaround )
+return 0;
+
 printk("Running stub recovery selftests...\n");
 
 for ( i = 0; i < ARRAY_SIZE(tests); ++i )
diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
index 41a8d8c..dfc4537 100644
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -556,6 +556,7 @@ int early_microcode_update_cpu(bool start_update);
 int early_microcode_init(void);
 int microcode_init_intel(void);
 int microcode_init_amd(void);
+extern bool tcg_workaround;
 
 enum get_cpu_vendor {
 gcv_host,

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-debianhvm-amd64 15 guest-saverestore.2 fail REGR. vs. 
117197

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 117197
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 117197
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 117197
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 117197
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 117197
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 117197
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 117197
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-examine  8 reboot   fail   never pass
 test-arm64-arm64-xl-credit2   7 xen-boot fail   never pass
 test-arm64-arm64-xl-xsm   7 xen-boot fail   never pass
 test-arm64-arm64-xl   7 xen-boot fail   never pass
 test-arm64-arm64-libvirt-xsm  7 xen-boot fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux30ad2851a645bb5f42c72f21ceb166877cf7e695
baseline version:
 linux0199619b21f7320482e8a2db14cf8bc974a7766a

Last test of basis   117197  2017-12-15 20:20:02 Z   39 days
Testing same since   118279  2018-01-23 07:54:41 Z0 days1 attempts


328 people touched revisions under test,
not listing them all

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

[Xen-devel] [xen-unstable-smoke test] 118290: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  1c8627d2a102274f8afeb9dc548100a60077fc8d
baseline version:
 xen  4786f9f8f7dff445a3b078b24508fd9d2f211f48

Last test of basis   118282  2018-01-23 10:01:22 Z0 days
Testing same since   118290  2018-01-23 19:01:30 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Wei Liu 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   4786f9f8f7..1c8627d2a1  1c8627d2a102274f8afeb9dc548100a60077fc8d -> smoke

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

Re: [Xen-devel] [PATCH v9 06/11] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point

[Andrew Cooper]

On 23/01/18 02:19, Boris Ostrovsky wrote:
>
>
> On 01/22/2018 07:17 PM, Andrew Cooper wrote:
>> On 22/01/2018 22:27, Boris Ostrovsky wrote:
>>> On 01/19/2018 08:36 AM, Andrew Cooper wrote:
 On 19/01/18 11:43, Jan Beulich wrote:

>> @@ -99,6 +106,10 @@ UNLIKELY_END(realmode)
>>   .Lvmx_vmentry_fail:
>>   sti
>>   SAVE_ALL
>> +
>> +    SPEC_CTRL_ENTRY_FROM_PV /* Req: %rsp=regs/cpuinfo Clob:
>> acd */
> I think the use of the PV variant here requires a comment.
 Oh.  It used to have one...  I'll try to find it.
>>> I, in fact, meant to ask about this for a long time and always forgot.
>>> Perhaps your comment will say more than just why a PV variant is used
>>> here but in case it won't --- why do we have *any* mitigation here? We
>>> are never returning to the guest, do we?
>>
>> We never return to *this* guest, but we are still open to abuse from a
>> separate hyperthread, so still need to set SPEC_CTRL.IBRS if we are
>> using IBRS for safety.  (If we are using lfence+jmp or repoline then we
>> don't need this change, but its not a hotpath so doesn't warrant yet
>> another variant of SPEC_CTRL_ENTRY_FROM_*.)
>
>
> We wrote IBRS during VMEXIT. I thought this serves as barrier for all
> preceding predictions (both threads) from lower protection mode.

There is no guarantee that a sequence which sets IBRS, then clears it,
serves to flush older predictions.

In practice, some implementations of IBRS are a flush internally, and
some are a disable internally.  This is why the semantics require you to
rewrite it the value 1 on entry to a higher mode (even if it was
previously set), and keep it set for the duration of protection you want.

> Is the concern here that SPEC_CTRL_EXIT_TO_GUEST (before VMENTER) may
> set IBRS to 0 and *that* will open hypervisor to other thread's mischief?

Correct.

~Andrew

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

Re: [Xen-devel] [PATCH 0/4] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot

[Ard Biesheuvel]

On 12 January 2018 at 11:24, Daniel Kiper  wrote:
> Hi Ard,
>
> On Thu, Jan 11, 2018 at 12:51:07PM +, Ard Biesheuvel wrote:
>> On 9 January 2018 at 14:22, Daniel Kiper  wrote:
>> > Hi,
>> >
>> > Initialize UEFI secure boot state during dom0 boot. Otherwise the kernel
>> > may not even know that it runs on secure boot enabled platform.
>>
>> Hi Daniel,
>>
>> I must say, I am not too thrilled with the approach you have chosen
>> here. #including .c files in other .c files, and using #defines to
>> override C functions or other stub functionality is rather fragile. In
>
> TBH I do not like it too. Sadly I have not find a better solution for
> that. I wish to avoid code duplication as much as possible because
> otherwise it will fall out of sync sooner or later (usually sooner).
> Similar thing happened in different part of Xen EFI code a few months ago.
>
>> particular, it means we have to start caring about not breaking
>> Xen/x86 code when making modifications to the EFI stub, and that code
>> is already difficult enough to maintain, given that it is shared
>> between ARM, arm64 and x86, and runs either from the decompressor or
>> the kernel proper (arm64) but in the context of the UEFI firmware.
>
> I understand that.
>
>> None of the stub code currently runs in ordinary kernel context.
>
> Yep.
>
>> So please, could you try to find another way to do this?
>
> I am happy to improve the situation, however, I am afraid that it is
> difficult here. Stub and kernel proper are separate entities and simple
> linking does not work. So, It seems to me that only play with includes
> will allow us to not duplicate the code. However, if you have a better
> idea I am happy to implement it.
>

Actually, there is another reason why it does not make sense to reuse that code.

This code

/*
* See if a user has put the shim into insecure mode. If so, and if the
* variable doesn't have the runtime attribute set, we might as well
* honor that.
*/
size = sizeof(moksbstate);
status = get_efi_var(L"MokSBState", &shim_guid,
 &attr, &size, &moksbstate);

/* If it fails, we don't care why. Default to secure */
if (status != EFI_SUCCESS)
goto secure_boot_enabled;
if (!(attr & EFI_VARIABLE_RUNTIME_ACCESS) && moksbstate == 1)
return efi_secureboot_mode_disabled;

will always fail after exiting boot services, so it makes no sense to
call it from xen_efi_init().

So I suggest you just clone the function and only keep the pieces that
make sense for Xen.

-- 
Ard.

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

[Xen-devel] [examine test] 118286: tolerable ALL FAIL

[osstest service owner]

flight 118286 examine real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118286/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 examine-laxton1   2 hosts-allocatebroken blocked in 116480
 examine-pinot02 hosts-allocate  broken like 116480
 examine-chardonnay1   2 hosts-allocate  broken like 116480
 examine-cubietruck-picasso2 hosts-allocate  broken like 116480
 examine-rimava0   2 hosts-allocate  broken like 116480
 examine-elbling0  2 hosts-allocate  broken like 116480
 examine-italia0   2 hosts-allocate  broken like 116480
 examine-elbling1  2 hosts-allocate  broken like 116480
 examine-arndale-bluewater 2 hosts-allocate  broken like 116480
 examine-arndale-westfield 2 hosts-allocate  broken like 116480
 examine-pinot12 hosts-allocate  broken like 116480
 examine-huxelrebe02 hosts-allocate  broken like 116480
 examine-arndale-metrocentre   2 hosts-allocate  broken like 116480
 examine-baroque1  2 hosts-allocate  broken like 116480
 examine-cubietruck-braque 2 hosts-allocate  broken like 116480
 examine-italia1   2 hosts-allocate  broken like 116480
 examine-fiano02 hosts-allocate  broken like 116480
 examine-godello0  2 hosts-allocate  broken like 116480
 examine-baroque0  2 hosts-allocate  broken like 116480
 examine-godello1  2 hosts-allocate  broken like 116480
 examine-arndale-lakeside  2 hosts-allocate  broken like 116480
 examine-cubietruck-gleizes2 hosts-allocate  broken like 116480
 examine-huxelrebe12 hosts-allocate  broken like 116480
 examine-chardonnay0   2 hosts-allocate  broken like 116480
 examine-fiano12 hosts-allocate  broken like 116480
 examine-cubietruck-metzinger  2 hosts-allocate  broken like 116480

baseline version:
 flight   116480

jobs:
 examine-baroque0 fail
 examine-baroque1 fail
 examine-arndale-bluewaterfail
 examine-cubietruck-braquefail
 examine-chardonnay0  fail
 examine-chardonnay1  fail
 examine-elbling0 fail
 examine-elbling1 fail
 examine-fiano0   fail
 examine-fiano1   fail
 examine-cubietruck-gleizes   fail
 examine-godello0 fail
 examine-godello1 fail
 examine-huxelrebe0   fail
 examine-huxelrebe1   fail
 examine-italia0  fail
 examine-italia1  fail
 examine-arndale-lakeside fail
 examine-laxton1  fail
 examine-arndale-metrocentre  fail
 examine-cubietruck-metzinger fail
 examine-cubietruck-picasso   fail
 examine-pinot0   fail
 examine-pinot1   fail
 examine-rimava0  fail
 examine-arndale-westfieldfail



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


Push not applicable.


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

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

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 seabios  14d91c353e19b7085fdbb7b2dcc43f3355665670
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z   80 days
Failing since115733  2017-11-10 17:19:59 Z   74 days   88 attempts
Testing same since   118140  2018-01-17 05:09:48 Z6 days9 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Marcel Apfelbaum 
  Michael S. Tsirkin 
  Paul Menzel 
  Stefan Berger 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass



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

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

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

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


Not pushing.


commit 14d91c353e19b7085fdbb7b2dcc43f3355665670
Author: Marcel Apfelbaum 
Date:   Thu Jan 11 22:15:12 2018 +0200

pci: fix 'io hints' capability for RedHat PCI bridges

Commit ec6cb17f (pci: enable RedHat PCI bridges to reserve additional
 resources on PCI init)
added a new vendor specific PCI capability for RedHat PCI bridges
allowing them to reserve additional buses and/or IO/MEM space.

When adding the IO hints PCI capability to the pcie-root-port
without specifying a value for bus reservation, the subordinate bus
computation is wrong and the guest kernel gets messed up.

Fix it by returning to prev code if the value for bus
reservation is not set.

Removed also a wrong debug print "PCI: invalid QEMU resource reserve
cap offset" which appears if the 'IO hints' capability is not present.

Acked-by: Michael S. Tsirkin 
Signed-off-by: Marcel Apfelbaum 

commit 844b86464a5cbfffb62b87808632018ca250d867
Author: Paul Menzel 
Date:   Mon Oct 2 08:13:13 2017 +020

Re: [Xen-devel] I only see one CPU core on Xen when booted via grub

[Daniel Kiper]

On Tue, Jan 23, 2018 at 01:03:04PM +0100, msd+xen-de...@msd.im wrote:
> >I need at least GRUB2 version, Xen version
>
> ```
> # apt-cache policy grub2-common
> grub2-common:
>   Installé : 2.02~beta3-5
>   Candidat : 2.02~beta3-5
>  Table de version :
>  *** 2.02~beta3-5 500
> 500 http://debian.mirrors.ovh.net/debian stretch/main amd64
> Packages
> 100 /var/lib/dpkg/status

[...]

This version of GRUB2 will not work with Xen on UEFI platforms.
Please take the latest one from the upstream GRUB2 git tree.

I hope that helps.

Daniel

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

Re: [Xen-devel] [PATCH v4 6/6] x86/domctl: Remove XEN_DOMCTL_pin_mem_cacheattr

[Wei Liu]

On Tue, Jan 23, 2018 at 10:16:45AM -0700, Jan Beulich wrote:
> >>> Wei Liu  01/23/18 4:44 PM >>>
> On Tue, Jan 23, 2018 at 03:22:46PM +, Ross Lagerwall wrote:
> >> --- a/xen/include/public/domctl.h
> >> +++ b/xen/include/public/domctl.h
> >> @@ -38,7 +38,7 @@
> >>  #include "hvm/save.h"
> >>  #include "memory.h"
> >>  
> >> -#define XEN_DOMCTL_INTERFACE_VERSION 0x000f
> >> +#define XEN_DOMCTL_INTERFACE_VERSION 0x0010
> >>  
> >
> >We bumped this to 0f in this development window so there is no need to
> >do it again.
> 
> As pointed out elsewhere (at least on two other threads meanwhile) whether
> to bump _again_ depends on the backporting plans of the domctl changes
> in the shim series. If 4.10 is to obtain those eventually, it should be _just_
> that one change which goes under interface version 0xf.

OK. This makes sense.  My Rb still stands.

Wei.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  9d34af1a6b671a4df1c73eea46072bddf6b26b5f
baseline version:
 libvirt  71d56a397925a1bd55d3aee30afdbdcd1a14f9a8

Last test of basis   118237  2018-01-19 19:48:17 Z3 days
Failing since118265  2018-01-22 04:20:33 Z1 days2 attempts
Testing same since   118278  2018-01-23 04:20:08 Z0 days1 attempts


People who touched revisions under test:
  Chen Hanxiao 
  Jiri Denemark 
  Laine Stump 
  Michal Koutný 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



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

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

Explanation of these reports, and of osstest in general, is at
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 

Re: [Xen-devel] [Xen EFI] Impossible to limit the dom0 memory

[msd+xen-de...@msd.im]

Yet you'll need to provide the kernel messages


I attached a console log "xen-console-log.txt".

Here, Xen crash even without the "dom0_mem=1G,max:1G" option :

```
# cat /boot/efi/EFI/xen/xen.cfg
[global]
default=xen

[xen]
options=loglvl=all com1=115200,8n1 console=com1,vga
kernel=vmlinuz root=/dev/md2 ro rootdelay=10 noquiet nosplash 
earlyprintk=xen console=com1

ramdisk=initrd.img
```

Do you need something else helpful ?

Regards,


Guillaume
[0.00]   node   0: [mem 0x1000-0x00057fff]
[0.00]   node   0: [mem 0x00059000-0x0009dfff]
[0.00]   node   0: [mem 0x0009f000-0x0009]
[0.00]   node   0: [mem 0x0010-0x881c5fff]
[0.00]   node   0: [mem 0x88211000-0x88282fff]
[0.00]   node   0: [mem 0x89fff000-0x89ff]
[0.00]   node   0: [mem 0x0001-0x000861ff]
[0.00] Initmem setup node 0 [mem 0x1000-0x000861ff]
[0.00] p2m virtual area at c900, size is 4000
[0.00] Remapped 491049 page(s)
[0.00] ACPI: PM-Timer IO Port: 0x1808
[0.00] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[0.00] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
[0.00] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
[0.00] ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
[0.00] ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
[0.00] ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1])
[0.00] ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1])
[0.00] ACPI: LAPIC_NMI (acpi_id[0x08] high edge lint[0x1])
[0.00] IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-119
[0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[0.00] Using ACPI (MADT) for SMP configuration information
[0.00] ACPI: HPET id: 0x8086a201 base: 0xfed0
[0.00] smpboot: Allowing 8 CPUs, 0 hotplug CPUs
[0.00] PM: Registered nosave memory: [mem 0x-0x0fff]
[0.00] PM: Registered nosave memory: [mem 0x00058000-0x00058fff]
[0.00] PM: Registered nosave memory: [mem 0x0009e000-0x0009efff]
[0.00] PM: Registered nosave memory: [mem 0x000a-0x000f]
[0.00] PM: Registered nosave memory: [mem 0x881c6000-0x881c6fff]
[0.00] PM: Registered nosave memory: [mem 0x881c7000-0x88210fff]
[0.00] PM: Registered nosave memory: [mem 0x88283000-0x89ec1fff]
[0.00] PM: Registered nosave memory: [mem 0x89ec2000-0x89f99fff]
[0.00] PM: Registered nosave memory: [mem 0x89f9a000-0x89ffefff]
[0.00] PM: Registered nosave memory: [mem 0x8a00-0x8bff]
[0.00] PM: Registered nosave memory: [mem 0x8c00-0x8fff]
[0.00] PM: Registered nosave memory: [mem 0x9000-0x95ff]
[0.00] PM: Registered nosave memory: [mem 0x9600-0x97ff]
[0.00] PM: Registered nosave memory: [mem 0x9800-0x9dff]
[0.00] PM: Registered nosave memory: [mem 0x9e00-0xe00f9fff]
[0.00] PM: Registered nosave memory: [mem 0xe00fa000-0xe00fafff]
[0.00] PM: Registered nosave memory: [mem 0xe00fb000-0xe00fcfff]
[0.00] PM: Registered nosave memory: [mem 0xe00fd000-0xe00fdfff]
[0.00] PM: Registered nosave memory: [mem 0xe00fe000-0xfdff]
[0.00] PM: Registered nosave memory: [mem 0xfe00-0xfe010fff]
[0.00] PM: Registered nosave memory: [mem 0xfe011000-0xfebf]
[0.00] PM: Registered nosave memory: [mem 0xfec0-0xfec00fff]
[0.00] PM: Registered nosave memory: [mem 0xfec01000-0xfed8]
[0.00] PM: Registered nosave memory: [mem 0xfed9-0xfed90fff]
[0.00] PM: Registered nosave memory: [mem 0xfed91000-0xfedf]
[0.00] PM: Registered nosave memory: [mem 0xfee0-0xfeef]
[0.00] PM: Registered nosave memory: [mem 0xfef0-0x]
[0.00] e820: [mem 0x9e00-0xe00f9fff] available for PCI devices
[0.00] Booting paravirtualized kernel on Xserve-AD)
[0.00] clocksource: refined-jiffies: mask: 0x max_cycles: 
0x, max_idle_ns: 7645519600211568 ns
[0.00] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:8 
nr_node_ids:1
[0.00] percpu: Embedded 35 pages/cpu @88083ec0 s105304 r8192 
d29864 u262144
[0.00] PV qspinlock hash table entries: 256 (order: 0, 4096 bytes)
[0.00] Built 1 zonelists in Node order, mobility grouping on.  Total 
pages: 8169272
[0.00] Policy zone: Normal
[0.00] Kernel command line: root=/dev/md2 ro rootdelay=10 noquiet 
nosplash earlyprintk=xen console=com1
[0.00] PID hash table entries: 4096 (order: 3, 32768 bytes)
[0.00] software IO TLB [mem 0x83ac0-0x83ec0] (64MB) mapped at

Re: [Xen-devel] [PATCH v4] kexec-tools: Perform run-time linking of libxenctrl.so

[Eric DeVolder]

Daniel,
I've implemented your feedback and posted the following:

[PATCH v1] kexec-tools: Tweak run-time handling of libxenctrl.so

Regards,
eric

On 01/18/2018 05:55 AM, Daniel Kiper wrote:

On Wed, Jan 17, 2018 at 10:39:01AM -0600, Eric DeVolder wrote:

When kexec is utilized in a Xen environment, it has an explicit
run-time dependency on libxenctrl.so. This dependency occurs
during the configure stage and when building kexec-tools.


[...]

As I saw Simon applied the patch. Great! Sadly I have just
realized that I have missed two things. Please look below.


The patch creates a wrapper function around xc_interface_open()
and xc_interface_close() to perform the dlopen() and dlclose().


You say about dlclose() here...

diff --git a/kexec/kexec-xen.h b/kexec/kexec-xen.h
new file mode 100644
index 000..ffb8743
--- /dev/null
+++ b/kexec/kexec-xen.h

[...]


+/* The handle from dlopen(), needed by dlsym(), dlclose() */
+extern void *xc_dlhandle;


...and here but it is never called. Is it by design or by mistake?
If by design please add a comment saying why into relevant place,
e.g. __xc_interface_close()? If by mistake please fix it.

[...]


+/* The handle from dlopen(), needed by dlsym(), dlclose() */
+extern void *xc_dlhandle;


I am still not happy with xc_dlhandle being extern. IMO it should be static.
I have missed that during last review. Sorry about that. I have a feeling
that you can easily fix it.

Define __xc_dlsym() in kexec/kexec-xen.c just before __xc_interface_open() like 
below:

void *__xc_dlsym(const char *symbol)
{
   return dlsym(xc_dlhandle, symbol);
}


+/* Wrappers around xc_interface_open/close() to insert dlopen/dlclose() */
+xc_interface *__xc_interface_open(xentoollog_logger *logger,
+ xentoollog_logger *dombuild_logger,
+ unsigned open_flags);
+int __xc_interface_close(xc_interface *xch);
+
+/* GCC expression statements for evaluating dlsym() */
+#define __xc_call(dtype, name, args...) \
+( \
+   { dtype value; \
+   typedef dtype (*func_t)(xc_interface *, ...); \
+   func_t func = dlsym(xc_dlhandle, #name); \


And then replace dlsym(xc_dlhandle, #name) with __xc_dlsym(#name)...


+   value = func(args); \
+   value; } \
+)
+#define __xc_data(dtype, name) \
+( \
+   { dtype *value = (dtype *)dlsym(xc_dlhandle, #name); value; } \


...and here. Additionally, you can use __xc_dlsym() instead of dlsym()
in other places in your patch. Latter is not a must...

Daniel



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

Re: [Xen-devel] [PATCH] x86: slightly reduce Meltdown band-aid overhead

[George Dunlap]

On 01/18/2018 03:39 PM, Jan Beulich wrote:
> I'm not sure why I didn't do this right away: By avoiding to make any
> of the cloned directmap PTEs global, there's no need to fiddle with
> CR4.PGE on any of the entry paths. Only the exit paths need to flush
> global mappings.
> 
> The reduced flushing, however, implies that we now need to have
> interrupts off on all entry paths until after the page table switch, so
> that flush IPIs can't arrive with the restricted page tables still
> active, but only a non-global flush happening with the CR3 loads. Along
> those lines the "sync" IPI after L4 entry updates now needs to become a
> real (and global) flush IPI, so that inside Xen we'll also pick up such
> changes.
> 
> Take the opportunity and also do a GET_CURRENT() -> __GET_CURRENT()
> transition the original patch missed.
> 
> Signed-off-by: Jan Beulich 

FWIW, for me this patch reduces the overhead from 38% to 28%.  Below are
times from a "time make -j 4 xen"

* xpti=off: 63s
* [xpti default]: 87s (+38%)
* + this patch: 81s (+28%)

 -George

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

Re: [Xen-devel] [PATCH RFC v2 00/12] xen/x86: use per-vcpu stacks for 64 bit pv domains

[George Dunlap]

On 01/23/2018 04:56 PM, Juergen Gross wrote:
> On 23/01/18 17:45, George Dunlap wrote:
>> On 01/22/2018 06:39 PM, Andrew Cooper wrote:
>>> Juergen: you're now adding a LTR into the context switch path which
>>> tends to be very slow.  I.e. As currently presented, this series
>>> necessarily has a higher runtime overhead than Jan's XPTI.
>>
>> So here are a repeat of the "hypervisor compile" tests I did, comparing
>> the different XPTI-like series so far.
>>
>> # Experimental setup:
>> Host:
>>  - Intel(R) Xeon(R) CPU E5630  @ 2.53GHz
>>  - 4 pcpus
>>  - Memory: 4GiB
>> Guest:
>>  - 4vcpus, 512MiB, blkback to raw file
>>  - CentOS 6 userspace
>>  - Linux 4.14 kernel with PV / PVH / PVHVM / KVM guest support (along
>> with expected drivers) built-in
>> Test:
>>  - cd xen-4.10.0
>>  - make -C xen clean
>>  - time make -j 4 xen
>>
> 
> ...
> 
>> * Staging + Juergen's v2 series
>> real1m3.018s
>> user2m52.217s
>> sys 0m40.357s
>>
>> Result: 63s (0% overhead)
>>
>> Unfortunately, I can't really verify that Juergen's patches are having
>> any effect; there's no printk indicating whether it's enabling the
>> mitigation or not.  I have verified that the changeset reported in `xl
>> dmesg` corresponds to the branch I have with the patches applied.
>>
>> So it's *possible* something has gotten mixed up, and the mitigation
>> isn't being applied; but if it *is* applied, the performance is
>> significantly better than the "band-aid" XPTI.
> 
> As there is no real mitigation in place, but only the needed rework of
> the interrupt handling and context switching, anything not next to
> xpti=off would have been disappointing for me. :-)
> 
> I'll add some statistics in the next patches so it can be verified the
> patches are really doing something.

Well at very least there should be something in the boot scrool that
says, "Enabling Xen Pagetable protection (XPTI) for PV guests" or
something.  (That goes for the current round of XPTI as well really.)

 -George

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

Re: [Xen-devel] [PATCH v4 6/6] x86/domctl: Remove XEN_DOMCTL_pin_mem_cacheattr

[Jan Beulich]

>>> Wei Liu  01/23/18 4:44 PM >>>
On Tue, Jan 23, 2018 at 03:22:46PM +, Ross Lagerwall wrote:
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -38,7 +38,7 @@
>>  #include "hvm/save.h"
>>  #include "memory.h"
>>  
>> -#define XEN_DOMCTL_INTERFACE_VERSION 0x000f
>> +#define XEN_DOMCTL_INTERFACE_VERSION 0x0010
>>  
>
>We bumped this to 0f in this development window so there is no need to
>do it again.

As pointed out elsewhere (at least on two other threads meanwhile) whether
to bump _again_ depends on the backporting plans of the domctl changes
in the shim series. If 4.10 is to obtain those eventually, it should be _just_
that one change which goes under interface version 0xf.

Jan


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

Re: [Xen-devel] [PATCH RFC v2 00/12] xen/x86: use per-vcpu stacks for 64 bit pv domains

[Juergen Gross]

On 23/01/18 17:45, George Dunlap wrote:
> On 01/22/2018 06:39 PM, Andrew Cooper wrote:
>> Juergen: you're now adding a LTR into the context switch path which
>> tends to be very slow.  I.e. As currently presented, this series
>> necessarily has a higher runtime overhead than Jan's XPTI.
> 
> So here are a repeat of the "hypervisor compile" tests I did, comparing
> the different XPTI-like series so far.
> 
> # Experimental setup:
> Host:
>  - Intel(R) Xeon(R) CPU E5630  @ 2.53GHz
>  - 4 pcpus
>  - Memory: 4GiB
> Guest:
>  - 4vcpus, 512MiB, blkback to raw file
>  - CentOS 6 userspace
>  - Linux 4.14 kernel with PV / PVH / PVHVM / KVM guest support (along
> with expected drivers) built-in
> Test:
>  - cd xen-4.10.0
>  - make -C xen clean
>  - time make -j 4 xen
> 

...

> * Staging + Juergen's v2 series
> real1m3.018s
> user2m52.217s
> sys 0m40.357s
> 
> Result: 63s (0% overhead)
> 
> Unfortunately, I can't really verify that Juergen's patches are having
> any effect; there's no printk indicating whether it's enabling the
> mitigation or not.  I have verified that the changeset reported in `xl
> dmesg` corresponds to the branch I have with the patches applied.
> 
> So it's *possible* something has gotten mixed up, and the mitigation
> isn't being applied; but if it *is* applied, the performance is
> significantly better than the "band-aid" XPTI.

As there is no real mitigation in place, but only the needed rework of
the interrupt handling and context switching, anything not next to
xpti=off would have been disappointing for me. :-)

I'll add some statistics in the next patches so it can be verified the
patches are really doing something.

Thanks for doing the tests,


Juergen

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

Re: [Xen-devel] [RFC v4 3/8] xen/linux_compat: Add a Linux compat header

[Roger Pau Monné]

On Mon, Dec 18, 2017 at 08:16:58PM -0700, Sameer Goel wrote:
> For porting files directly from Linux it is useful to have a function mapping
> definitions from Linux to Xen. This file adds common API functions and
> other defines that are needed for porting arm SMMU drivers.

It would be good that you add things to linux_compat.h in the same
patch that you import the code, or else reviewing whether this is
needed or not is impossible.

> Signed-off-by: Sameer Goel 
> ---
>  xen/include/xen/linux_compat.h | 81 
> ++
>  1 file changed, 81 insertions(+)
>  create mode 100644 xen/include/xen/linux_compat.h
> 
> diff --git a/xen/include/xen/linux_compat.h b/xen/include/xen/linux_compat.h
> new file mode 100644
> index 00..174d0390e5
> --- /dev/null
> +++ b/xen/include/xen/linux_compat.h
> @@ -0,0 +1,81 @@
> +/**
> + * include/xen/linux_compat.h
> + *
> + * Compatibility defines for porting code from Linux to Xen
> + *
> + * Copyright (c) 2017 Linaro Limited
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; If not, see .
> + */
> +
> +#ifndef __XEN_LINUX_COMPAT_H__
> +#define __XEN_LINUX_COMPAT_H__
> +
> +#include 
> +
> +typedef paddr_t phys_addr_t;
> +typedef paddr_t dma_addr_t;
> +
> +typedef unsigned int gfp_t;
> +#define GFP_KERNEL 0
> +#define __GFP_ZERO 0
> +
> +/* Alias to Xen device tree helpers */
> +#define device_node dt_device_node
> +#define of_phandle_args dt_phandle_args
> +#define of_device_id dt_device_match
> +#define of_match_node dt_match_node
> +#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, 
> pname, out))
> +#define of_property_read_bool dt_property_read_bool
> +#define of_parse_phandle_with_args dt_parse_phandle_with_args

The above looks pretty much ARM specific. I wonder whether it would
make sense to also introduce an asm/linux_compat.h to place such
things.

> +/* Helpers for IRQ functions */
> +#define free_irq release_irq
> +
> +enum irqreturn {
> +IRQ_NONE= (0 << 0),
> +IRQ_HANDLED = (1 << 0),
> +IRQ_WAKE_THREAD = (2 << 0),

You don't need to set the explicit values, just using:

enum irqreturn {
IRQ_NONE,
IRQ_HANDLED,
IRQ_WAKE_THREAD,
};

Will achieve exactly the same.

> +};
> +
> +typedef enum irqreturn irqreturn_t;
> +
> +/* Device logger functions */
> +#define dev_print(dev, lvl, fmt, ...)   \
> + printk(lvl fmt, ## __VA_ARGS__)

You don't need to pass dev here (it's not used AFAICT).

> +
> +#define dev_dbg(dev, fmt, ...) dev_print(dev, XENLOG_DEBUG, fmt, ## 
> __VA_ARGS__)
> +#define dev_notice(dev, fmt, ...) dev_print(dev, XENLOG_INFO, fmt, ## 
> __VA_ARGS__)
> +#define dev_warn(dev, fmt, ...) dev_print(dev, XENLOG_WARNING, fmt, ## 
> __VA_ARGS__)
> +#define dev_err(dev, fmt, ...) dev_print(dev, XENLOG_ERR, fmt, ## 
> __VA_ARGS__)
> +#define dev_info(dev, fmt, ...) dev_print(dev, XENLOG_INFO, fmt, ## 
> __VA_ARGS__)

Neither here. In which case you can get rid of dev_print and simply
use printk the in the above macros. Also you should make sure they are
no longer than 80 cols.

> +
> +#define dev_err_ratelimited(dev, fmt, ...)  \
> + dev_print(dev, XENLOG_ERR, fmt, ## __VA_ARGS__)
> +
> +#define dev_name(dev) dt_node_full_name(dev_to_dt(dev))
> +
> +/* Alias to Xen allocation helpers */
> +#define kfree xfree
> +#define kmalloc(size, flags)_xmalloc(size, sizeof(void *))
> +#define kzalloc(size, flags)_xzalloc(size, sizeof(void *))
> +#define devm_kzalloc(dev, size, flags)  _xzalloc(size, sizeof(void *))
> +#define kmalloc_array(size, n, flags)   _xmalloc_array(size, sizeof(void *), 
> n)

Why use the '_' versions of malloc/zalloc? Do you really intend to
force the alignment?

> +
> +/* Alias to Xen time functions */
> +#define ktime_t s_time_t
> +#define ktime_add_us(t,i)   (NOW() + MICROSECS(i))
> +#define ktime_compare(t,i)  (NOW() > (i))

Er, the above is wrong, ktime_add_us adds 'i' to 't', not to NOW.

Roger.

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

Re: [Xen-devel] [PATCH RFC v2 00/12] xen/x86: use per-vcpu stacks for 64 bit pv domains

[George Dunlap]

On 01/22/2018 06:39 PM, Andrew Cooper wrote:
> On 22/01/18 16:51, Jan Beulich wrote:
> On 22.01.18 at 16:00,  wrote:
>>> On 22/01/18 15:48, Jan Beulich wrote:
>>> On 22.01.18 at 15:38,  wrote:
> On 22/01/18 15:22, Jan Beulich wrote:
> On 22.01.18 at 15:18,  wrote:
>>> On 22/01/18 13:50, Jan Beulich wrote:
>>> On 22.01.18 at 13:32,  wrote:
> As a preparation for doing page table isolation in the Xen hypervisor
> in order to mitigate "Meltdown" use dedicated stacks, GDT and TSS for
> 64 bit PV domains mapped to the per-domain virtual area.
>
> The per-vcpu stacks are used for early interrupt handling only. After
> saving the domain's registers stacks are switched back to the normal
> per physical cpu ones in order to be able to address on-stack data
> from other cpus e.g. while handling IPIs.
>
> Adding %cr3 switching between saving of the registers and switching
> the stacks will enable the possibility to run guest code without any
> per physical cpu mapping, i.e. avoiding the threat of a guest being
> able to access other domains data.
>
> Without any further measures it will still be possible for e.g. a
> guest's user program to read stack data of another vcpu of the same
> domain, but this can be easily avoided by a little PV-ABI modification
> introducing per-cpu user address spaces.
>
> This series is meant as a replacement for Andrew's patch series:
> "x86: Prerequisite work for a Xen KAISER solution".
 Considering in particular the two reverts, what I'm missing here
 is a clear description of the meaningful additional protection this
 approach provides over the band-aid. For context see also
 https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg01735.html
  
>>> My approach supports mapping only the following data while the guest is
>>> running (apart form the guest's own data, of course):
>>>
>>> - the per-vcpu entry stacks of the domain which will contain only the
>>>   guest's registers saved when an interrupt occurs
>>> - the per-vcpu GDTs and TSSs of the domain
>>> - the IDT
>>> - the interrupt handler code (arch/x86/x86_64/[compat/]entry.S
>>>
>>> All other hypervisor data and code can be completely hidden from the
>>> guests.
>> I understand that. What I'm not clear about is: Which parts of
>> the additionally hidden data are actually necessary (or at least
>> very desirable) to hide?
> Necessary:
> - other guests' memory (e.g. physical memory 1:1 mapping)
> - data from other guests e.g.in stack pages, debug buffers, I/O buffers,
>   code emulator buffers
> - other guests' register values e.g. in vcpu structure
 All of this is already being made invisible by the band-aid (with the
 exception of leftovers on the hypervisor stacks across context
 switches, which we've already said could be taken care of by
 memset()ing that area). I'm asking about the _additional_ benefits
 of your approach.
>>> I'm quite sure the performance will be much better as it doesn't require
>>> per physical cpu L4 page tables, but just a shadow L4 table for each
>>> guest L4 table, similar to the Linux kernel KPTI approach.
>> But isn't that model having the same synchronization issues upon
>> guest L4 updates which Andrew was fighting with?
> 
> (Condensing a lot of threads down into one)
> 
> All the methods have L4 synchronisation update issues, until we have a
> PV ABI which guarantees that L4's don't get reused.  Any improvements to
> the shadowing/synchronisation algorithm will benefit all approaches.
> 
> Juergen: you're now adding a LTR into the context switch path which
> tends to be very slow.  I.e. As currently presented, this series
> necessarily has a higher runtime overhead than Jan's XPTI.

So here are a repeat of the "hypervisor compile" tests I did, comparing
the different XPTI-like series so far.

# Experimental setup:
Host:
 - Intel(R) Xeon(R) CPU E5630  @ 2.53GHz
 - 4 pcpus
 - Memory: 4GiB
Guest:
 - 4vcpus, 512MiB, blkback to raw file
 - CentOS 6 userspace
 - Linux 4.14 kernel with PV / PVH / PVHVM / KVM guest support (along
with expected drivers) built-in
Test:
 - cd xen-4.10.0
 - make -C xen clean
 - time make -j 4 xen

# Results
- In all cases, running a "default" build with CONFIG_DEBUG=n

* Staging, xpti=off
real1m2.995s
user2m52.527s
sys 0m40.276s

Result: 63s

* Staging [xpti default]
real1m27.190s
user3m3.900s
sys 1m42.686s

Result: 87s (38% overhead)

Note also that the "system time" here is about 2.5x of "xpti=off"; so
total wasted cpu time is significantly higher.

* Staging + "x86: slightly reduce Meltdown band-aid overhead"
real1m21.661s
user3m3.809s
sys 1m25.344s

Result: 81s (28% overhead)

NB that the "syste

Re: [Xen-devel] [RFC v4 3/8] xen/linux_compat: Add a Linux compat header

[Wei Liu]

On Mon, Dec 18, 2017 at 08:16:58PM -0700, Sameer Goel wrote:
> For porting files directly from Linux it is useful to have a function mapping
> definitions from Linux to Xen. This file adds common API functions and
> other defines that are needed for porting arm SMMU drivers.
> 
> Signed-off-by: Sameer Goel 
> ---
>  xen/include/xen/linux_compat.h | 81 
> ++
>  1 file changed, 81 insertions(+)
>  create mode 100644 xen/include/xen/linux_compat.h
> 
> diff --git a/xen/include/xen/linux_compat.h b/xen/include/xen/linux_compat.h
> new file mode 100644
> index 00..174d0390e5
> --- /dev/null
> +++ b/xen/include/xen/linux_compat.h
> @@ -0,0 +1,81 @@
> +/**
> + * include/xen/linux_compat.h
> + *
> + * Compatibility defines for porting code from Linux to Xen
> + *
> + * Copyright (c) 2017 Linaro Limited
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; If not, see .
> + */
> +
> +#ifndef __XEN_LINUX_COMPAT_H__
> +#define __XEN_LINUX_COMPAT_H__
> +
> +#include 
> +
> +typedef paddr_t phys_addr_t;
> +typedef paddr_t dma_addr_t;
> +
> +typedef unsigned int gfp_t;
> +#define GFP_KERNEL 0
> +#define __GFP_ZERO 0

You might want to think carefully about this one.

I haven't checked if Xen supports such flag, but it is probably a bad
idea to fool the driver that it gets a zeroed allocation.

> +
> +/* Alias to Xen device tree helpers */
> +#define device_node dt_device_node
> +#define of_phandle_args dt_phandle_args
> +#define of_device_id dt_device_match
> +#define of_match_node dt_match_node
> +#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, 
> pname, out))
> +#define of_property_read_bool dt_property_read_bool
> +#define of_parse_phandle_with_args dt_parse_phandle_with_args
> +
> +/* Helpers for IRQ functions */
> +#define free_irq release_irq
> +
> +enum irqreturn {
> +IRQ_NONE= (0 << 0),
> +IRQ_HANDLED = (1 << 0),
> +IRQ_WAKE_THREAD = (2 << 0),

Use 1U 2U please.

> +};
> +
> +typedef enum irqreturn irqreturn_t;
> +
> +/* Device logger functions */
> +#define dev_print(dev, lvl, fmt, ...)   \
> + printk(lvl fmt, ## __VA_ARGS__)
> +
> +#define dev_dbg(dev, fmt, ...) dev_print(dev, XENLOG_DEBUG, fmt, ## 
> __VA_ARGS__)
> +#define dev_notice(dev, fmt, ...) dev_print(dev, XENLOG_INFO, fmt, ## 
> __VA_ARGS__)
> +#define dev_warn(dev, fmt, ...) dev_print(dev, XENLOG_WARNING, fmt, ## 
> __VA_ARGS__)
> +#define dev_err(dev, fmt, ...) dev_print(dev, XENLOG_ERR, fmt, ## 
> __VA_ARGS__)
> +#define dev_info(dev, fmt, ...) dev_print(dev, XENLOG_INFO, fmt, ## 
> __VA_ARGS__)
> +
> +#define dev_err_ratelimited(dev, fmt, ...)  \
> + dev_print(dev, XENLOG_ERR, fmt, ## __VA_ARGS__)
> +

These are going to clash with the ones in
drivers/passthrough/arm/smmu.c.

Wei.

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

Re: [Xen-devel] [RFC v4 1/8] Port WARN_ON_ONCE() from Linux

[Wei Liu]

On Mon, Dec 18, 2017 at 08:16:56PM -0700, Sameer Goel wrote:
> Port WARN_ON_ONCE macro from Linux.
> 
> Signed-off-by: Sameer Goel 
> ---
>  xen/include/xen/lib.h | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
> index ed00ae1379..83206c0848 100644
> --- a/xen/include/xen/lib.h
> +++ b/xen/include/xen/lib.h
> @@ -11,6 +11,17 @@
>  #define BUG_ON(p)  do { if (unlikely(p)) BUG();  } while (0)
>  #define WARN_ON(p) do { if (unlikely(p)) WARN(); } while (0)
>  
> +#define WARN_ON_ONCE(p)  ({  \
> +static bool __section(".data.unlikely") __warned; \

You introduced a new section without corresponding changes to
{arm,x86}/xen.lds.S

> +int __ret_warn_once = !!(p);\
> +\
> +if (unlikely(__ret_warn_once && !__warned)) {   \
> +__warned = true;\
> +WARN_ON(1); \

This isn't really a direct port from Linux. At this point I wonder why
you didn't use WARN() directly?

Wei.

> +}   \
> +unlikely(__ret_warn_once);  \
> +})
> +
>  #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6)
>  /* Force a compilation error if condition is true */
>  #define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!(" #cond ")"); })
> -- 
> 2.14.1
> 

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

Re: [Xen-devel] [PATCH] x86/shutdown: Use ACPI reboot method for Dell PowerEdge R740

[Ross Lagerwall]

On 01/22/2018 12:29 PM, Jan Beulich wrote:

On 19.01.18 at 17:57,  wrote:

--- a/xen/arch/x86/shutdown.c
+++ b/xen/arch/x86/shutdown.c
@@ -511,6 +511,15 @@ static struct dmi_system_id __initdata reboot_dmi_table[] 
= {
  DMI_MATCH(DMI_PRODUCT_NAME, "Latitude E6520"),
  },
  },
+{/* Handle problems with rebooting on Dell PowerEdge R740. */
+.callback = override_reboot,
+.driver_data = (void *)(long)BOOT_ACPI,
+.ident = "Dell PowerEdge R740",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+DMI_MATCH(DMI_PRODUCT_NAME, "PowerEdge R740"),
+},
+},


Judging from the description you don't really want or need to
override the reboot method if not running under EFI, or if there
was an override on the command line already. override_reboot(),
however, overrides everything and under all circumstances. I
therefore think you may want to introduce a new callback
function.


Agreed, it should only apply when running under EFI. Note that the 
command-line takes priority over override_reboot() -- see the note at 
the start of reboot_init().




As an aside - how come the page at address zero is actually
mapped at the time of the reboot attempt?



No idea...

--
Ross Lagerwall

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

Re: [Xen-devel] [PATCH v5] x86: relocate pvh_info

[Wei Liu]

On Tue, Jan 23, 2018 at 03:18:22PM +, Andrew Cooper wrote:
> On 23/01/18 15:13, Wei Liu wrote:
> > @@ -226,14 +259,27 @@ static multiboot_info_t *mbi2_reloc(u32 mbi_in)
> >  return mbi_out;
> >  }
> >  
> > -multiboot_info_t __stdcall *reloc(u32 mb_magic, u32 mbi_in, u32 trampoline)
> > +void __stdcall *reloc(u32 magic, u32 in, u32 trampoline)
> 
> As an final observation, void * __stdcall reloc() so the __stdcall isn't
> in the middle of the return type (Can be fixed on commit).

Sure.

> 
> Otherwise, Reviewed-by: Andrew Cooper 

Thanks.

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

Re: [Xen-devel] [PATCH v4 1/6] xen/mm: Make xenmem_add_to_physmap global

[Wei Liu]

On Tue, Jan 23, 2018 at 03:22:41PM +, Ross Lagerwall wrote:
> Make it global in preparation to be called by a new dmop.
> 
> Signed-off-by: Ross Lagerwall 
> Reviewed-by: Paul Durrant 
> Acked-by: Jan Beulich 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v4 6/6] x86/domctl: Remove XEN_DOMCTL_pin_mem_cacheattr

[Wei Liu]

On Tue, Jan 23, 2018 at 03:47:52PM +, Ross Lagerwall wrote:
> On 01/23/2018 03:44 PM, Wei Liu wrote:
> > On Tue, Jan 23, 2018 at 03:22:46PM +, Ross Lagerwall wrote:
> > > Remove the implementation of XEN_DOMCTL_pin_mem_cacheattr since it has
> > > been replaced by a dmop. Change xc_domain_pin_memory_cacheattr() so
> > > that it is only defined when XC_WANT_COMPAT_DEVICEMODEL_API is set and
> > > have it call the new dmop.  Leave the definitions of
> > > XEN_DOMCTL_MEM_CACHEATTR_* since they are still used by QEMU.
> > > 
> snip>> diff --git a/xen/include/public/domctl.h
> b/xen/include/public/domctl.h
> > > index a8921dd..30674d6 100644
> > > --- a/xen/include/public/domctl.h
> > > +++ b/xen/include/public/domctl.h
> > > @@ -38,7 +38,7 @@
> > >   #include "hvm/save.h"
> > >   #include "memory.h"
> > > -#define XEN_DOMCTL_INTERFACE_VERSION 0x000f
> > > +#define XEN_DOMCTL_INTERFACE_VERSION 0x0010
> > 
> > We bumped this to 0f in this development window so there is no need to
> > do it again.
> 
> OK.
> 
> > 
> > >   /*
> > >* NB. xen_domctl.domain is an IN/OUT parameter for this operation.
> > > @@ -598,10 +598,6 @@ struct xen_domctl_ioport_mapping {
> > >   #define XEN_DOMCTL_MEM_CACHEATTR_WB  6
> > >   #define XEN_DOMCTL_MEM_CACHEATTR_UCM 7
> > >   #define XEN_DOMCTL_DELETE_MEM_CACHEATTR (~(uint32_t)0)
> > 
> > Any reason to not remove these #define's?
> > 
> 
> They're still used by QEMU at the moment. Removing them now would break the
> build. They can be removed once QEMU(s) have been switch to use the new
> XEN_DMOP_* #defines.
> 

OK.

With the version bump removed:

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v4 6/6] x86/domctl: Remove XEN_DOMCTL_pin_mem_cacheattr

[Ross Lagerwall]

On 01/23/2018 03:44 PM, Wei Liu wrote:

On Tue, Jan 23, 2018 at 03:22:46PM +, Ross Lagerwall wrote:

Remove the implementation of XEN_DOMCTL_pin_mem_cacheattr since it has
been replaced by a dmop. Change xc_domain_pin_memory_cacheattr() so
that it is only defined when XC_WANT_COMPAT_DEVICEMODEL_API is set and
have it call the new dmop.  Leave the definitions of
XEN_DOMCTL_MEM_CACHEATTR_* since they are still used by QEMU.

snip>> diff --git a/xen/include/public/domctl.h 
b/xen/include/public/domctl.h

index a8921dd..30674d6 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -38,7 +38,7 @@
  #include "hvm/save.h"
  #include "memory.h"
  
-#define XEN_DOMCTL_INTERFACE_VERSION 0x000f

+#define XEN_DOMCTL_INTERFACE_VERSION 0x0010
  


We bumped this to 0f in this development window so there is no need to
do it again.


OK.




  /*
   * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
@@ -598,10 +598,6 @@ struct xen_domctl_ioport_mapping {
  #define XEN_DOMCTL_MEM_CACHEATTR_WB  6
  #define XEN_DOMCTL_MEM_CACHEATTR_UCM 7
  #define XEN_DOMCTL_DELETE_MEM_CACHEATTR (~(uint32_t)0)


Any reason to not remove these #define's?



They're still used by QEMU at the moment. Removing them now would break 
the build. They can be removed once QEMU(s) have been switch to use the 
new XEN_DMOP_* #defines.


--
Ross Lagerwall

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 qemuuee264eb32c14f076c964fc34ee66f6f95cce2080
baseline version:
 qemuuf7c6b96c3e639e871bb929038a1b82ded7f39437

Last test of basis   118270  2018-01-22 11:44:53 Z1 days
Testing same since   118277  2018-01-23 03:34:29 Z0 days1 attempts


People who touched revisions under test:
  BALATON Zoltan 
  Cédric Le Goater 
  David Gibson 
  Greg Kurz 
  Laszlo Ersek 
  Marc-André Lureau 
  Paolo Bonzini 
  pbonz...@redhat.com 
  Peter Maydell 
  Suraj Jitindar Singh 
  Thomas Huth 

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

Re: [Xen-devel] [PATCH v4 6/6] x86/domctl: Remove XEN_DOMCTL_pin_mem_cacheattr

[Wei Liu]

On Tue, Jan 23, 2018 at 03:22:46PM +, Ross Lagerwall wrote:
> Remove the implementation of XEN_DOMCTL_pin_mem_cacheattr since it has
> been replaced by a dmop. Change xc_domain_pin_memory_cacheattr() so
> that it is only defined when XC_WANT_COMPAT_DEVICEMODEL_API is set and
> have it call the new dmop.  Leave the definitions of
> XEN_DOMCTL_MEM_CACHEATTR_* since they are still used by QEMU.
> 
> Signed-off-by: Ross Lagerwall 
> Reviewed-by: Paul Durrant 
> Acked-by: Daniel De Graaf 
> ---
> 
> Changed in v4:
> * Bump interface version.
> * Clarified comment.
> 
> New in v3.
> 
>  tools/flask/policy/modules/xen.if   |  4 ++--
>  tools/libs/devicemodel/include/xendevicemodel.h |  2 +-
>  tools/libxc/include/xenctrl.h   |  6 --
>  tools/libxc/include/xenctrl_compat.h|  3 +++
>  tools/libxc/xc_devicemodel_compat.c |  8 
>  tools/libxc/xc_domain.c | 15 ---

These changes LGTM.

>  {
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index a8921dd..30674d6 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -38,7 +38,7 @@
>  #include "hvm/save.h"
>  #include "memory.h"
>  
> -#define XEN_DOMCTL_INTERFACE_VERSION 0x000f
> +#define XEN_DOMCTL_INTERFACE_VERSION 0x0010
>  

We bumped this to 0f in this development window so there is no need to
do it again.

>  /*
>   * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
> @@ -598,10 +598,6 @@ struct xen_domctl_ioport_mapping {
>  #define XEN_DOMCTL_MEM_CACHEATTR_WB  6
>  #define XEN_DOMCTL_MEM_CACHEATTR_UCM 7
>  #define XEN_DOMCTL_DELETE_MEM_CACHEATTR (~(uint32_t)0)

Any reason to not remove these #define's?

Wei.

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

Re: [Xen-devel] [RFC v4 8/8] drivers/passthrough/arm: Refactor code for arm smmu drivers

[Julien Grall]

Hi Sameer,

On 19/12/17 03:17, Sameer Goel wrote:

Pull common defines for SMMU drivers in a local header.


I was expected to see this patch before SMMUv3 is added. But I am ok 
with that too.


However, if you want to do some renaming this should be done separately. 
So it will be easier to know this patch is only consolidation.


But why do you need to do renaming at first in the SMMUv3? The code is new.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC v4 7/8] xen/smmu: Add a new config define for legacy SMMU

[Julien Grall]

Hi Sameer,

On 19/12/17 03:17, Sameer Goel wrote:

Add a new config item to control compilation for legacy arm SMMU.

Signed-off-by: Sameer Goel 
---
  xen/drivers/passthrough/arm/Kconfig  | 6 ++
  xen/drivers/passthrough/arm/Makefile | 2 +-
  2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/arm/Kconfig 
b/xen/drivers/passthrough/arm/Kconfig
index cda899f608..597f58f10b 100644
--- a/xen/drivers/passthrough/arm/Kconfig
+++ b/xen/drivers/passthrough/arm/Kconfig
@@ -6,3 +6,9 @@ config ARM_SMMU_v3
 Support for implementations of the ARM System MMU architecture
 version 3.
  
+config ARM_SMMU

+   bool "ARM Legacy SMMU Support"
+   depends on (ARM_64 || ARM)


ARM_64 will select ARM. So ARM is enough here.

Cheers,


+   help
+Support for implementations of the ARM System MMU architecture
+version 1 and 2.
diff --git a/xen/drivers/passthrough/arm/Makefile 
b/xen/drivers/passthrough/arm/Makefile
index e14732b55c..5b3eb1545e 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,3 +1,3 @@
  obj-y += iommu.o
-obj-y += smmu.o
+obj-$(CONFIG_ARM_SMMU) += smmu.o
  obj-$(CONFIG_ARM_SMMU_v3) += smmu-v3.o



--
Julien Grall

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

[Xen-devel] [PATCH v4 2/6] x86/hvm: Provide XEN_DMOP_relocate_memory

[Ross Lagerwall]

Provide XEN_DMOP_relocate_memory, a limited version of
XENMEM_add_to_physmap to allow a deprivileged QEMU to move VRAM when a
guest programs its BAR. It is equivalent to XENMEM_add_to_physmap with
space == XENMAPSPACE_gmfn_range.

Signed-off-by: Ross Lagerwall 
Reviewed-by: Paul Durrant 
---

Changed in v4:
* Renamed add_to_physmap to relocate_memory.
* Instead of checking for overflow, handle using continuation.

Changed in v3:
* Renamed idx -> src_gfn and gpfn -> dst_gfn.
* Increase the width of size and add an overflow check.
* Rework some of the descriptions.
* Dropped Paul's reviewed-by due to the above changes.

Changed in v2:
* Make it operate on a range.

 xen/arch/x86/hvm/dm.c  | 32 
 xen/include/public/hvm/dm_op.h | 18 ++
 xen/include/xlat.lst   |  1 +
 3 files changed, 51 insertions(+)

diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index a787f43..a5773e3 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -640,6 +640,37 @@ static int dm_op(const struct dmop_args *op_args)
 break;
 }
 
+case XEN_DMOP_relocate_memory:
+{
+struct xen_dm_op_relocate_memory *data = &op.u.relocate_memory;
+struct xen_add_to_physmap xatp = {
+.domid = op_args->domid,
+.size = data->size,
+.space = XENMAPSPACE_gmfn_range,
+.idx = data->src_gfn,
+.gpfn = data->dst_gfn,
+};
+
+if ( data->pad )
+{
+rc = -EINVAL;
+break;
+}
+
+rc = xenmem_add_to_physmap(d, &xatp, 0);
+if ( rc == 0 && data->size != xatp.size )
+rc = xatp.size;
+if ( rc > 0 )
+{
+data->size -= rc;
+data->src_gfn += rc;
+data->dst_gfn += rc;
+const_op = false;
+rc = -ERESTART;
+}
+break;
+}
+
 default:
 rc = -EOPNOTSUPP;
 break;
@@ -669,6 +700,7 @@ CHECK_dm_op_set_mem_type;
 CHECK_dm_op_inject_event;
 CHECK_dm_op_inject_msi;
 CHECK_dm_op_remote_shutdown;
+CHECK_dm_op_relocate_memory;
 
 int compat_dm_op(domid_t domid,
  unsigned int nr_bufs,
diff --git a/xen/include/public/hvm/dm_op.h b/xen/include/public/hvm/dm_op.h
index e173085..35d1346 100644
--- a/xen/include/public/hvm/dm_op.h
+++ b/xen/include/public/hvm/dm_op.h
@@ -368,6 +368,23 @@ struct xen_dm_op_remote_shutdown {
/* (Other reason values are not blocked) */
 };
 
+/*
+ * XEN_DMOP_relocate_memory : Relocate GFNs for the specified guest.
+ *Identical to XENMEM_add_to_physmap with
+ *space == XENMAPSPACE_gmfn_range.
+ */
+#define XEN_DMOP_relocate_memory 17
+
+struct xen_dm_op_relocate_memory {
+/* Number of GFNs to process. */
+uint32_t size;
+uint32_t pad;
+/* Starting GFN to relocate. */
+uint64_aligned_t src_gfn;
+/* Starting GFN where GFNs should be relocated. */
+uint64_aligned_t dst_gfn;
+};
+
 struct xen_dm_op {
 uint32_t op;
 uint32_t pad;
@@ -389,6 +406,7 @@ struct xen_dm_op {
 struct xen_dm_op_map_mem_type_to_ioreq_server
 map_mem_type_to_ioreq_server;
 struct xen_dm_op_remote_shutdown remote_shutdown;
+struct xen_dm_op_relocate_memory relocate_memory;
 } u;
 };
 
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 4346cbe..b3d00b7 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -57,6 +57,7 @@
 ?  grant_entry_v2  grant_table.h
 ?  gnttab_swap_grant_ref   grant_table.h
 !  dm_op_buf   hvm/dm_op.h
+?  dm_op_relocate_memory   hvm/dm_op.h
 ?  dm_op_create_ioreq_server   hvm/dm_op.h
 ?  dm_op_destroy_ioreq_server  hvm/dm_op.h
 ?  dm_op_get_ioreq_server_info hvm/dm_op.h
-- 
2.9.5


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

[Xen-devel] [PATCH v4 6/6] x86/domctl: Remove XEN_DOMCTL_pin_mem_cacheattr

[Ross Lagerwall]

Remove the implementation of XEN_DOMCTL_pin_mem_cacheattr since it has
been replaced by a dmop. Change xc_domain_pin_memory_cacheattr() so
that it is only defined when XC_WANT_COMPAT_DEVICEMODEL_API is set and
have it call the new dmop.  Leave the definitions of
XEN_DOMCTL_MEM_CACHEATTR_* since they are still used by QEMU.

Signed-off-by: Ross Lagerwall 
Reviewed-by: Paul Durrant 
Acked-by: Daniel De Graaf 
---

Changed in v4:
* Bump interface version.
* Clarified comment.

New in v3.

 tools/flask/policy/modules/xen.if   |  4 ++--
 tools/libs/devicemodel/include/xendevicemodel.h |  2 +-
 tools/libxc/include/xenctrl.h   |  6 --
 tools/libxc/include/xenctrl_compat.h|  3 +++
 tools/libxc/xc_devicemodel_compat.c |  8 
 tools/libxc/xc_domain.c | 15 ---
 xen/arch/x86/domctl.c   |  8 
 xen/include/public/domctl.h |  9 ++---
 xen/include/public/hvm/dm_op.h  | 10 +-
 xen/xsm/flask/hooks.c   |  3 ---
 xen/xsm/flask/policy/access_vectors |  2 --
 11 files changed, 25 insertions(+), 45 deletions(-)

diff --git a/tools/flask/policy/modules/xen.if 
b/tools/flask/policy/modules/xen.if
index cb48a6c..459880b 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -57,7 +57,7 @@ define(`create_domain_common', `
allow $1 $2:shadow enable;
allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage 
mmuext_op updatemp };
allow $1 $2:grant setup;
-   allow $1 $2:hvm { cacheattr getparam hvmctl sethvmc
+   allow $1 $2:hvm { getparam hvmctl sethvmc
setparam nested altp2mhvm altp2mhvm_op dm };
 ')
 
@@ -151,7 +151,7 @@ define(`device_model', `
 
allow $1 $2_target:domain { getdomaininfo shutdown };
allow $1 $2_target:mmu { map_read map_write adjust physmap target_hack 
};
-   allow $1 $2_target:hvm { getparam setparam hvmctl cacheattr dm };
+   allow $1 $2_target:hvm { getparam setparam hvmctl dm };
 ')
 
 # make_device_model(priv, dm_dom, hvm_dom)
diff --git a/tools/libs/devicemodel/include/xendevicemodel.h 
b/tools/libs/devicemodel/include/xendevicemodel.h
index 9b89f32..7629c35 100644
--- a/tools/libs/devicemodel/include/xendevicemodel.h
+++ b/tools/libs/devicemodel/include/xendevicemodel.h
@@ -346,7 +346,7 @@ int xendevicemodel_relocate_memory(
  * @parm domid the domain id to be serviced
  * @parm start Start gfn
  * @parm end End gfn
- * @parm type XEN_DOMCTL_MEM_CACHEATTR_*
+ * @parm type XEN_DMOP_MEM_CACHEATTR_*
  * @return 0 on success, -1 on failure.
  */
 int xendevicemodel_pin_memory_cacheattr(
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index ecb0312..6a4347e 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1473,12 +1473,6 @@ int xc_domain_iomem_permission(xc_interface *xch,
unsigned long nr_mfns,
uint8_t allow_access);
 
-int xc_domain_pin_memory_cacheattr(xc_interface *xch,
-   uint32_t domid,
-   uint64_t start,
-   uint64_t end,
-   uint32_t type);
-
 unsigned long xc_make_page_below_4G(xc_interface *xch, uint32_t domid,
 unsigned long mfn);
 
diff --git a/tools/libxc/include/xenctrl_compat.h 
b/tools/libxc/include/xenctrl_compat.h
index a655e47..464f645 100644
--- a/tools/libxc/include/xenctrl_compat.h
+++ b/tools/libxc/include/xenctrl_compat.h
@@ -164,6 +164,9 @@ int xc_hvm_set_mem_type(
 int xc_hvm_inject_trap(
 xc_interface *xch, uint32_t domid, int vcpu, uint8_t vector,
 uint8_t type, uint32_t error_code, uint8_t insn_len, uint64_t cr2);
+int xc_domain_pin_memory_cacheattr(
+xc_interface *xch, uint32_t domid, uint64_t start, uint64_t end,
+uint32_t type);
 
 #endif /* XC_WANT_COMPAT_DEVICEMODEL_API */
 
diff --git a/tools/libxc/xc_devicemodel_compat.c 
b/tools/libxc/xc_devicemodel_compat.c
index dbd1785..a46011c 100644
--- a/tools/libxc/xc_devicemodel_compat.c
+++ b/tools/libxc/xc_devicemodel_compat.c
@@ -128,6 +128,14 @@ int xc_hvm_inject_trap(
type, error_code, insn_len, cr2);
 }
 
+int xc_domain_pin_memory_cacheattr(
+xc_interface *xch, uint32_t domid, uint64_t start, uint64_t end,
+uint32_t type)
+{
+return xendevicemodel_pin_memory_cacheattr(xch->dmod, domid, start, end,
+   type);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 8169284..da0aa2f 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -720,21 +720,6 @@ int xc_domain_setmaxmem(xc_interface *xch,
 return do_domctl(xch, &domctl)

[Xen-devel] [PATCH v4 4/6] tools: libxendevicemodel: Provide xendevicemodel_relocate_memory

[Ross Lagerwall]

Signed-off-by: Ross Lagerwall 
Acked-by: Ian Jackson 
Reviewed-by: Paul Durrant 
---

Changed in v4:
* Rename add_to_physmap to relocate_memory to match hypervisor
  interface.

Changed in v3:
* Match width of size with updated hypervisor interface.
* Match description with the one for the hypervisor interface.

Changed in v2:
* Make it operate on a range.

 tools/libs/devicemodel/Makefile |  2 +-
 tools/libs/devicemodel/core.c   | 20 
 tools/libs/devicemodel/include/xendevicemodel.h | 14 ++
 tools/libs/devicemodel/libxendevicemodel.map|  5 +
 4 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/tools/libs/devicemodel/Makefile b/tools/libs/devicemodel/Makefile
index 342371a..5b2df7a 100644
--- a/tools/libs/devicemodel/Makefile
+++ b/tools/libs/devicemodel/Makefile
@@ -2,7 +2,7 @@ XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 MAJOR= 1
-MINOR= 1
+MINOR= 2
 SHLIB_LDFLAGS += -Wl,--version-script=libxendevicemodel.map
 
 CFLAGS   += -Werror -Wmissing-prototypes
diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c
index 355b7de..4ae15e1 100644
--- a/tools/libs/devicemodel/core.c
+++ b/tools/libs/devicemodel/core.c
@@ -564,6 +564,26 @@ int xendevicemodel_shutdown(
 return xendevicemodel_op(dmod, domid, 1, &op, sizeof(op));
 }
 
+int xendevicemodel_relocate_memory(
+xendevicemodel_handle *dmod, domid_t domid, uint32_t size, uint64_t 
src_gfn,
+uint64_t dst_gfn)
+{
+struct xen_dm_op op;
+struct xen_dm_op_relocate_memory *data;
+
+memset(&op, 0, sizeof(op));
+
+op.op = XEN_DMOP_relocate_memory;
+data = &op.u.relocate_memory;
+
+data->size = size;
+data->pad = 0;
+data->src_gfn = src_gfn;
+data->dst_gfn = dst_gfn;
+
+return xendevicemodel_op(dmod, domid, 1, &op, sizeof(op));
+}
+
 int xendevicemodel_restrict(xendevicemodel_handle *dmod, domid_t domid)
 {
 return osdep_xendevicemodel_restrict(dmod, domid);
diff --git a/tools/libs/devicemodel/include/xendevicemodel.h 
b/tools/libs/devicemodel/include/xendevicemodel.h
index dda0bc7..e5e047e 100644
--- a/tools/libs/devicemodel/include/xendevicemodel.h
+++ b/tools/libs/devicemodel/include/xendevicemodel.h
@@ -325,6 +325,20 @@ int xendevicemodel_inject_event(
 int xendevicemodel_shutdown(
 xendevicemodel_handle *dmod, domid_t domid, unsigned int reason);
 
+/*
+ * Relocate GFNs for the specified domain.
+ *
+ * @parm dmod a handle to an open devicemodel interface.
+ * @parm domid the domain id to be serviced
+ * @parm size Number of GFNs to process
+ * @parm src_gfn Starting GFN to relocate
+ * @parm dst_gfn Starting GFN where GFNs should be relocated
+ * @return 0 on success, -1 on failure.
+ */
+int xendevicemodel_relocate_memory(
+xendevicemodel_handle *dmod, domid_t domid, uint32_t size, uint64_t 
src_gfn,
+uint64_t dst_gfn);
+
 /**
  * This function restricts the use of this handle to the specified
  * domain.
diff --git a/tools/libs/devicemodel/libxendevicemodel.map 
b/tools/libs/devicemodel/libxendevicemodel.map
index cefd32b..4c967b3 100644
--- a/tools/libs/devicemodel/libxendevicemodel.map
+++ b/tools/libs/devicemodel/libxendevicemodel.map
@@ -27,3 +27,8 @@ VERS_1.1 {
global:
xendevicemodel_shutdown;
 } VERS_1.0;
+
+VERS_1.2 {
+   global:
+   xendevicemodel_relocate_memory;
+} VERS_1.1;
-- 
2.9.5


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

[Xen-devel] [PATCH v4 0/6] Add dmops to allow use of VGA with restricted QEMU

[Ross Lagerwall]

The recently added support for restricting QEMU prevents use of the VGA
console. This series addresses that by adding a couple of new dmops.
A corresponding patch for QEMU is needed to make use of the new dmops.

Changes in v4:
* Rename add_to_physmap -> relocate_memory.
* Use continutation instead of erroring in relocate_memory.
* Bump domctl interface version.

Changes in v3:
* Address Jan's comments - primarily adding a new patch to remove the
  existing pin_mem_cacheattr domctl.

Changes in v2:
* Address Paul's comments - mainly making add_to_physmap operate on a
  range.

Ross Lagerwall (6):
  xen/mm: Make xenmem_add_to_physmap global
  x86/hvm: Provide XEN_DMOP_relocate_memory
  x86/hvm: Provide XEN_DMOP_pin_memory_cacheattr
  tools: libxendevicemodel: Provide xendevicemodel_relocate_memory
  tools: libxendevicemodel: Provide xendevicemodel_pin_memory_cacheattr
  x86/domctl: Remove XEN_DOMCTL_pin_mem_cacheattr

 tools/flask/policy/modules/xen.if   |  4 +-
 tools/libs/devicemodel/Makefile |  2 +-
 tools/libs/devicemodel/core.c   | 39 +++
 tools/libs/devicemodel/include/xendevicemodel.h | 28 ++
 tools/libs/devicemodel/libxendevicemodel.map|  6 +++
 tools/libxc/include/xenctrl.h   |  6 ---
 tools/libxc/include/xenctrl_compat.h|  3 ++
 tools/libxc/xc_devicemodel_compat.c |  8 
 tools/libxc/xc_domain.c | 15 
 xen/arch/x86/domctl.c   |  8 
 xen/arch/x86/hvm/dm.c   | 50 +
 xen/common/memory.c |  5 +--
 xen/include/public/domctl.h |  9 +
 xen/include/public/hvm/dm_op.h  | 40 
 xen/include/xen/mm.h|  3 ++
 xen/include/xlat.lst|  2 +
 xen/xsm/flask/hooks.c   |  3 --
 xen/xsm/flask/policy/access_vectors |  2 -
 18 files changed, 186 insertions(+), 47 deletions(-)

-- 
2.9.5


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

[Xen-devel] [PATCH v4 5/6] tools: libxendevicemodel: Provide xendevicemodel_pin_memory_cacheattr

[Ross Lagerwall]

Signed-off-by: Ross Lagerwall 
Acked-by: Ian Jackson 
Reviewed-by: Paul Durrant 
---
 tools/libs/devicemodel/core.c   | 19 +++
 tools/libs/devicemodel/include/xendevicemodel.h | 14 ++
 tools/libs/devicemodel/libxendevicemodel.map|  1 +
 3 files changed, 34 insertions(+)

diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c
index 4ae15e1..23924e9 100644
--- a/tools/libs/devicemodel/core.c
+++ b/tools/libs/devicemodel/core.c
@@ -584,6 +584,25 @@ int xendevicemodel_relocate_memory(
 return xendevicemodel_op(dmod, domid, 1, &op, sizeof(op));
 }
 
+int xendevicemodel_pin_memory_cacheattr(
+xendevicemodel_handle *dmod, domid_t domid, uint64_t start, uint64_t end,
+uint32_t type)
+{
+struct xen_dm_op op;
+struct xen_dm_op_pin_memory_cacheattr *data;
+
+memset(&op, 0, sizeof(op));
+
+op.op = XEN_DMOP_pin_memory_cacheattr;
+data = &op.u.pin_memory_cacheattr;
+
+data->start = start;
+data->end = end;
+data->type = type;
+
+return xendevicemodel_op(dmod, domid, 1, &op, sizeof(op));
+}
+
 int xendevicemodel_restrict(xendevicemodel_handle *dmod, domid_t domid)
 {
 return osdep_xendevicemodel_restrict(dmod, domid);
diff --git a/tools/libs/devicemodel/include/xendevicemodel.h 
b/tools/libs/devicemodel/include/xendevicemodel.h
index e5e047e..9b89f32 100644
--- a/tools/libs/devicemodel/include/xendevicemodel.h
+++ b/tools/libs/devicemodel/include/xendevicemodel.h
@@ -340,6 +340,20 @@ int xendevicemodel_relocate_memory(
 uint64_t dst_gfn);
 
 /**
+ * Pins caching type of RAM space.
+ *
+ * @parm dmod a handle to an open devicemodel interface.
+ * @parm domid the domain id to be serviced
+ * @parm start Start gfn
+ * @parm end End gfn
+ * @parm type XEN_DOMCTL_MEM_CACHEATTR_*
+ * @return 0 on success, -1 on failure.
+ */
+int xendevicemodel_pin_memory_cacheattr(
+xendevicemodel_handle *dmod, domid_t domid, uint64_t start, uint64_t end,
+uint32_t type);
+
+/**
  * This function restricts the use of this handle to the specified
  * domain.
  *
diff --git a/tools/libs/devicemodel/libxendevicemodel.map 
b/tools/libs/devicemodel/libxendevicemodel.map
index 4c967b3..04797b2 100644
--- a/tools/libs/devicemodel/libxendevicemodel.map
+++ b/tools/libs/devicemodel/libxendevicemodel.map
@@ -31,4 +31,5 @@ VERS_1.1 {
 VERS_1.2 {
global:
xendevicemodel_relocate_memory;
+   xendevicemodel_pin_memory_cacheattr;
 } VERS_1.1;
-- 
2.9.5


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

[Xen-devel] [PATCH v4 3/6] x86/hvm: Provide XEN_DMOP_pin_memory_cacheattr

[Ross Lagerwall]

Provide XEN_DMOP_pin_memory_cacheattr to allow a deprivileged QEMU to
pin the caching type of RAM after moving the VRAM. It is equivalent to
XEN_DOMCTL_pin_memory_cacheattr.

Signed-off-by: Ross Lagerwall 
Reviewed-by: Paul Durrant 
Reviewed-by: Jan Beulich 
---

Changed in v2:
* Check pad is 0.

 xen/arch/x86/hvm/dm.c  | 18 ++
 xen/include/public/hvm/dm_op.h | 14 ++
 xen/include/xlat.lst   |  1 +
 3 files changed, 33 insertions(+)

diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index a5773e3..8083ded 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -20,6 +20,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 
@@ -671,6 +672,22 @@ static int dm_op(const struct dmop_args *op_args)
 break;
 }
 
+case XEN_DMOP_pin_memory_cacheattr:
+{
+const struct xen_dm_op_pin_memory_cacheattr *data =
+&op.u.pin_memory_cacheattr;
+
+if ( data->pad )
+{
+rc = -EINVAL;
+break;
+}
+
+rc = hvm_set_mem_pinned_cacheattr(d, data->start, data->end,
+  data->type);
+break;
+}
+
 default:
 rc = -EOPNOTSUPP;
 break;
@@ -701,6 +718,7 @@ CHECK_dm_op_inject_event;
 CHECK_dm_op_inject_msi;
 CHECK_dm_op_remote_shutdown;
 CHECK_dm_op_relocate_memory;
+CHECK_dm_op_pin_memory_cacheattr;
 
 int compat_dm_op(domid_t domid,
  unsigned int nr_bufs,
diff --git a/xen/include/public/hvm/dm_op.h b/xen/include/public/hvm/dm_op.h
index 35d1346..5c10ec3 100644
--- a/xen/include/public/hvm/dm_op.h
+++ b/xen/include/public/hvm/dm_op.h
@@ -385,6 +385,19 @@ struct xen_dm_op_relocate_memory {
 uint64_aligned_t dst_gfn;
 };
 
+/*
+ * XEN_DMOP_pin_memory_cacheattr : Pin caching type of RAM space.
+ * Identical to XEN_DOMCTL_pin_mem_cacheattr.
+ */
+#define XEN_DMOP_pin_memory_cacheattr 18
+
+struct xen_dm_op_pin_memory_cacheattr {
+uint64_aligned_t start; /* Start gfn. */
+uint64_aligned_t end;   /* End gfn. */
+uint32_t type;  /* XEN_DOMCTL_MEM_CACHEATTR_* */
+uint32_t pad;
+};
+
 struct xen_dm_op {
 uint32_t op;
 uint32_t pad;
@@ -407,6 +420,7 @@ struct xen_dm_op {
 map_mem_type_to_ioreq_server;
 struct xen_dm_op_remote_shutdown remote_shutdown;
 struct xen_dm_op_relocate_memory relocate_memory;
+struct xen_dm_op_pin_memory_cacheattr pin_memory_cacheattr;
 } u;
 };
 
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index b3d00b7..3690b97 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -65,6 +65,7 @@
 ?  dm_op_inject_msihvm/dm_op.h
 ?  dm_op_ioreq_server_rangehvm/dm_op.h
 ?  dm_op_modified_memory   hvm/dm_op.h
+?  dm_op_pin_memory_cacheattr  hvm/dm_op.h
 ?  dm_op_remote_shutdown   hvm/dm_op.h
 ?  dm_op_set_ioreq_server_statehvm/dm_op.h
 ?  dm_op_set_isa_irq_level hvm/dm_op.h
-- 
2.9.5


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

[Xen-devel] [PATCH v4 1/6] xen/mm: Make xenmem_add_to_physmap global

[Ross Lagerwall]

Make it global in preparation to be called by a new dmop.

Signed-off-by: Ross Lagerwall 
Reviewed-by: Paul Durrant 
Acked-by: Jan Beulich 
---
 xen/common/memory.c  | 5 ++---
 xen/include/xen/mm.h | 3 +++
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/xen/common/memory.c b/xen/common/memory.c
index c2797ba..09549ab 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -770,9 +770,8 @@ static long 
memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg)
 return rc;
 }
 
-static int xenmem_add_to_physmap(struct domain *d,
- struct xen_add_to_physmap *xatp,
- unsigned int start)
+int xenmem_add_to_physmap(struct domain *d, struct xen_add_to_physmap *xatp,
+  unsigned int start)
 {
 unsigned int done = 0;
 long rc = 0;
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index e813c07..0e0e511 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -579,6 +579,9 @@ int xenmem_add_to_physmap_one(struct domain *d, unsigned 
int space,
   union xen_add_to_physmap_batch_extra extra,
   unsigned long idx, gfn_t gfn);
 
+int xenmem_add_to_physmap(struct domain *d, struct xen_add_to_physmap *xatp,
+  unsigned int start);
+
 /* Return 0 on success, or negative on error. */
 int __must_check guest_remove_page(struct domain *d, unsigned long gmfn);
 int __must_check steal_page(struct domain *d, struct page_info *page,
-- 
2.9.5


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

Re: [Xen-devel] [PATCH v5] x86: relocate pvh_info

[Andrew Cooper]

On 23/01/18 15:13, Wei Liu wrote:
> @@ -226,14 +259,27 @@ static multiboot_info_t *mbi2_reloc(u32 mbi_in)
>  return mbi_out;
>  }
>  
> -multiboot_info_t __stdcall *reloc(u32 mb_magic, u32 mbi_in, u32 trampoline)
> +void __stdcall *reloc(u32 magic, u32 in, u32 trampoline)

As an final observation, void * __stdcall reloc() so the __stdcall isn't
in the middle of the return type (Can be fixed on commit).

Otherwise, Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v2] libxc: don't fail domain creation when unpacking initrd fails

[Wei Liu]

On Mon, Dec 04, 2017 at 05:46:41AM -0700, Jan Beulich wrote:
> At least Linux kernels have been able to work with gzip-ed initrd for
> quite some time; initrd compressed with other methods aren't even being
> attempted to unpack. Furthermore the unzip-ing routine used here isn't
> capable of dealing with various forms of concatenated files, each of
> which was gzip-ed separately (it is this particular case which has been
> the source of observed VM creation failures).
> 
> Hence, if unpacking fails, simply hand the the compressed blob to the
> guest as is.
> 
> Signed-off-by: Jan Beulich 

The code looks OK to me. It requires rebase though.

Wei.

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

Re: [Xen-devel] [RFC v4 6/8] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

[Julien Grall]

Hi Sameer,

On 19/12/17 03:17, Sameer Goel wrote:

This driver follows an approach similar to smmu driver. The intent here
is to reuse as much Linux code as possible.
- Glue code has been introduced to bridge the API calls.
- Called Linux functions from the Xen IOMMU function calls.
- Xen modifications are preceded by /*Xen: comment */

Signed-off-by: Sameer Goel 
---
  xen/arch/arm/p2m.c|   1 +
  xen/drivers/Kconfig   |   2 +
  xen/drivers/passthrough/arm/Kconfig   |   8 +
  xen/drivers/passthrough/arm/Makefile  |   1 +
  xen/drivers/passthrough/arm/smmu-v3.c | 880 --
  5 files changed, 861 insertions(+), 31 deletions(-)
  create mode 100644 xen/drivers/passthrough/arm/Kconfig

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 22165ae376..6aa24cae48 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1460,6 +1460,7 @@ err:
  static void __init setup_virt_paging_one(void *data)
  {
  unsigned long val = (unsigned long)data;
+/* SMMUv3 S2 cfg vtcr reuses the following value */
  WRITE_SYSREG32(val, VTCR_EL2);
  isb();
  }
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index bc3a54f0ea..612655386d 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -12,4 +12,6 @@ source "drivers/pci/Kconfig"
  
  source "drivers/video/Kconfig"
  
+source "drivers/passthrough/arm/Kconfig"

+
  endmenu
diff --git a/xen/drivers/passthrough/arm/Kconfig 
b/xen/drivers/passthrough/arm/Kconfig
new file mode 100644
index 00..cda899f608
--- /dev/null
+++ b/xen/drivers/passthrough/arm/Kconfig
@@ -0,0 +1,8 @@
+
+config ARM_SMMU_v3
+   bool "ARM SMMUv3 Support"
+   depends on ARM_64
+   help
+Support for implementations of the ARM System MMU architecture
+version 3.
+
diff --git a/xen/drivers/passthrough/arm/Makefile 
b/xen/drivers/passthrough/arm/Makefile
index f4cd26e15d..e14732b55c 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,2 +1,3 @@
  obj-y += iommu.o
  obj-y += smmu.o
+obj-$(CONFIG_ARM_SMMU_v3) += smmu-v3.o
diff --git a/xen/drivers/passthrough/arm/smmu-v3.c 
b/xen/drivers/passthrough/arm/smmu-v3.c
index e67ba6c40f..3488184ad4 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -18,28 +18,402 @@
   * Author: Will Deacon 
   *
   * This driver is powered by bad coffee and bombay mix.
+ *
+ *
+ * Based on Linux drivers/iommu/arm-smmu-v3.c
+ * => commit 7aa8619a66aea52b145e04cbab4f8d6a4e5f3f3b
+ *
+ * Xen modifications:
+ * Sameer Goel 
+ * Copyright (C) 2017, The Linux Foundation, All rights reserved.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+


No need for 2 newlines. Can you drop one?


+/* Xen: Helpers to get device MMIO and IRQs */
+struct resource {
+   u64 addr;
+   u64 size;
+   unsigned int type;
+};
+
+#define resource_size(res) ((res)->size)
+
+#define platform_device device
+
+#define IORESOURCE_MEM 0
+#define IORESOURCE_IRQ 1
+
+static struct resource *platform_get_resource(struct platform_device *pdev,
+ unsigned int type,
+ unsigned int num)
+{
+   /*
+* The resource is only used between 2 calls of platform_get_resource.
+* It's quite ugly but it's avoid to add too much code in the part
+* imported from Linux
+*/
+   static struct resource res;
+   struct acpi_iort_node *iort_node;
+   struct acpi_iort_smmu_v3 *node_smmu_data;
+   int ret = 0;
+
+   res.type = type;
+
+   switch (type) {
+   case IORESOURCE_MEM:
+   if (pdev->type == DEV_ACPI) {
+   ret = 1;
+   iort_node = pdev->acpi_node;
+   node_smmu_data =
+   (struct acpi_iort_smmu_v3 
*)iort_node->node_data;
+
+   if (node_smmu_data != NULL) {
+   res.addr = node_smmu_data->base_address;
+   res.size = SZ_128K;
+   ret = 0;
+   }
+   } else {
+   ret = dt_device_get_address(dev_to_dt(pdev), num,
+   &res.addr, &res.size);
+   }
+
+   return ((ret) ? NULL : &res);
+
+   case IORESOURCE_IRQ:
+   /* ACPI case not implemented as there is no use case for it */
+   ret = platform_get_irq(dev_to_dt(pdev), num);
+
+   if (ret < 0)
+   return NULL;
+
+   res.addr = ret;
+   res.size = 1;
+
+   return &res;
+
+   default:
+   return NULL;
+   }
+

[Xen-devel] [PATCH v5] x86: relocate pvh_info

[Wei Liu]

Modify early boot code to relocate pvh info as well, so that we can be
sure __va in __start_xen works.

Signed-off-by: Wei Liu 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Roger Pau Monné 

v5: Include kconfig.h. Use IS_ENABLED. Adjust code.
---
 xen/arch/x86/boot/Makefile |  3 ++-
 xen/arch/x86/boot/defs.h   |  3 +++
 xen/arch/x86/boot/head.S   | 25 ++-
 xen/arch/x86/boot/reloc.c  | 60 --
 4 files changed, 72 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index c6246c85d2..e10388282f 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -5,7 +5,8 @@ DEFS_H_DEPS = defs.h $(BASEDIR)/include/xen/stdbool.h
 CMDLINE_DEPS = $(DEFS_H_DEPS) video.h
 
 RELOC_DEPS = $(DEFS_H_DEPS) $(BASEDIR)/include/xen/multiboot.h \
-$(BASEDIR)/include/xen/multiboot2.h
+$(BASEDIR)/include/xen/multiboot2.h \
+$(BASEDIR)/include/public/arch-x86/hvm/start_info.h
 
 head.o: cmdline.S reloc.S
 
diff --git a/xen/arch/x86/boot/defs.h b/xen/arch/x86/boot/defs.h
index 6abdc15446..05921a64a3 100644
--- a/xen/arch/x86/boot/defs.h
+++ b/xen/arch/x86/boot/defs.h
@@ -51,6 +51,9 @@ typedef unsigned short u16;
 typedef unsigned int u32;
 typedef unsigned long long u64;
 typedef unsigned int size_t;
+typedef u8 uint8_t;
+typedef u32 uint32_t;
+typedef u64 uint64_t;
 
 #define U16_MAX((u16)(~0U))
 #define UINT_MAX   (~0U)
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 0f652cea11..3cb66fc06b 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -414,6 +414,7 @@ __pvh_start:
 
 /* Set trampoline_phys to use mfn 1 to avoid having a mapping at VA 0 
*/
 movw$0x1000, sym_esi(trampoline_phys)
+mov (%ebx), %eax /* mov $XEN_HVM_START_MAGIC_VALUE, %eax */
 jmp trampoline_setup
 
 #endif /* CONFIG_PVH_GUEST */
@@ -578,18 +579,20 @@ trampoline_setup:
 /* Get bottom-most low-memory stack address. */
 add $TRAMPOLINE_SPACE,%ecx
 
-#ifdef CONFIG_PVH_GUEST
-cmpb$0, sym_fs(pvh_boot)
-jne 1f
-#endif
-
-/* Save the Multiboot info struct (after relocation) for later use. */
+/* Save Multiboot / PVH info struct (after relocation) for later use. 
*/
 push%ecx/* Bottom-most low-memory stack address. */
-push%ebx/* Multiboot information address. */
-push%eax/* Multiboot magic. */
+push%ebx/* Multiboot / PVH information address. */
+push%eax/* Magic number. */
 callreloc
-mov %eax,sym_fs(multiboot_ptr)
+#ifdef CONFIG_PVH_GUEST
+cmp $0, sym_fs(pvh_boot)
+je  1f
+mov %eax, sym_fs(pvh_start_info_pa)
+jmp 2f
+#endif
 1:
+mov %eax, sym_fs(multiboot_ptr)
+2:
 
 /*
  * Now trampoline_phys points to the following structure (lowest 
address
@@ -598,12 +601,12 @@ trampoline_setup:
  * ++
  * | TRAMPOLINE_STACK_SPACE |
  * ++
- * |mbi data|
+ * | Data (MBI / PVH)   |
  * +- - - - - - - - - - - - +
  * |TRAMPOLINE_SPACE|
  * ++
  *
- * mbi data grows downwards from the highest address of 
TRAMPOLINE_SPACE
+ * Data grows downwards from the highest address of TRAMPOLINE_SPACE
  * region to the end of the trampoline. The rest of TRAMPOLINE_SPACE is
  * reserved for trampoline code and data.
  */
diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index b992678b5e..8a66390383 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -14,8 +14,8 @@
 
 /*
  * This entry point is entered from xen/arch/x86/boot/head.S with:
- *   - 0x4(%esp) = MULTIBOOT_MAGIC,
- *   - 0x8(%esp) = MULTIBOOT_INFORMATION_ADDRESS,
+ *   - 0x4(%esp) = MAGIC,
+ *   - 0x8(%esp) = INFORMATION_ADDRESS,
  *   - 0xc(%esp) = TOPMOST_LOW_MEMORY_STACK_ADDRESS.
  */
 asm (
@@ -29,6 +29,9 @@ asm (
 #include "../../../include/xen/multiboot.h"
 #include "../../../include/xen/multiboot2.h"
 
+#include "../../../include/xen/kconfig.h"
+#include 
+
 #define get_mb2_data(tag, type, member)   (((multiboot2_tag_##type##_t 
*)(tag))->member)
 #define get_mb2_string(tag, type, member) ((u32)get_mb2_data(tag, type, 
member))
 
@@ -71,6 +74,36 @@ static u32 copy_string(u32 src)
 return copy_mem(src, p - src + 1);
 }
 
+static struct hvm_start_info *pvh_info_reloc(u32 in)
+{
+struct hvm_start_info *out;
+
+out = _p(copy_mem(in, sizeof(*out)));
+
+if ( out->cmdline_paddr )
+out->cmdline_paddr = copy_string(out->cmdline_paddr);
+
+if ( out->nr_modules )
+{
+unsigned int i;
+struct hvm_m

[Xen-devel] [PATCH v8 10/11] vpci: add a priority parameter to the vPCI register initializer

[Roger Pau Monne]

This is needed for MSI-X, since MSI-X will need to be initialized
before parsing the BARs, so that the header BAR handlers are aware of
the MSI-X related holes and make sure they are not mapped in order for
the trap handlers to work properly.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Jan Beulich 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v4:
 - Add a middle priority and add the PCI header to it.

Changes since v3:
 - Add a numerial suffix to the section used to store the pointer to
   each initializer function, and sort them at link time.
---
 xen/arch/arm/xen.lds.S| 4 ++--
 xen/arch/x86/xen.lds.S| 4 ++--
 xen/drivers/vpci/header.c | 2 +-
 xen/drivers/vpci/msi.c| 2 +-
 xen/include/xen/vpci.h| 8 ++--
 5 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 98b82680c6..f2e213b3c2 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -69,7 +69,7 @@ SECTIONS
 #if defined(CONFIG_HAS_PCI) && defined(CONFIG_LATE_HWDOM)
. = ALIGN(POINTER_ALIGN);
__start_vpci_array = .;
-   *(.data.vpci)
+   *(SORT(.data.vpci.*))
__end_vpci_array = .;
 #endif
   } :text
@@ -184,7 +184,7 @@ SECTIONS
 #if defined(CONFIG_HAS_PCI) && !defined(CONFIG_LATE_HWDOM)
. = ALIGN(POINTER_ALIGN);
__start_vpci_array = .;
-   *(.data.vpci)
+   *(SORT(.data.vpci.*))
__end_vpci_array = .;
 #endif
   } :text
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 96e53f68a8..19a912245a 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -132,7 +132,7 @@ SECTIONS
 #if defined(CONFIG_HAS_PCI) && defined(CONFIG_LATE_HWDOM)
. = ALIGN(POINTER_ALIGN);
__start_vpci_array = .;
-   *(.data.vpci)
+   *(SORT(.data.vpci.*))
__end_vpci_array = .;
 #endif
   } :text
@@ -230,7 +230,7 @@ SECTIONS
 #if defined(CONFIG_HAS_PCI) && !defined(CONFIG_LATE_HWDOM)
. = ALIGN(POINTER_ALIGN);
__start_vpci_array = .;
-   *(.data.vpci)
+   *(SORT(.data.vpci.*))
__end_vpci_array = .;
 #endif
   } :text
diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index 994cfbb8f7..98ed53a126 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -508,7 +508,7 @@ static int init_bars(struct pci_dev *pdev)
 
 return 0;
 }
-REGISTER_VPCI_INIT(init_bars);
+REGISTER_VPCI_INIT(init_bars, VPCI_PRIORITY_MIDDLE);
 
 /*
  * Local variables:
diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
index 9da687a5d7..f8f08cb515 100644
--- a/xen/drivers/vpci/msi.c
+++ b/xen/drivers/vpci/msi.c
@@ -265,7 +265,7 @@ static int init_msi(struct pci_dev *pdev)
 
 return ret;
 }
-REGISTER_VPCI_INIT(init_msi);
+REGISTER_VPCI_INIT(init_msi, VPCI_PRIORITY_LOW);
 
 void vpci_dump_msi(void)
 {
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index 5afd54b2e8..6e810801d6 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -15,9 +15,13 @@ typedef void vpci_write_t(const struct pci_dev *pdev, 
unsigned int reg,
 
 typedef int vpci_register_init_t(struct pci_dev *dev);
 
-#define REGISTER_VPCI_INIT(x)   \
+#define VPCI_PRIORITY_HIGH  "1"
+#define VPCI_PRIORITY_MIDDLE"5"
+#define VPCI_PRIORITY_LOW   "9"
+
+#define REGISTER_VPCI_INIT(x, p)\
   static vpci_register_init_t *const x##_entry  \
-   __used_section(".data.vpci") = x
+   __used_section(".data.vpci." p) = x
 
 /* Add vPCI handlers to device. */
 int __must_check vpci_add_handlers(struct pci_dev *dev);
-- 
2.15.1


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

[Xen-devel] [PATCH v8 07/11] vpci/bars: add handlers to map the BARs

[Roger Pau Monne]

Introduce a set of handlers that trap accesses to the PCI BARs and the
command register, in order to snoop BAR sizing and BAR relocation.

The command handler is used to detect changes to bit 2 (response to
memory space accesses), and maps/unmaps the BARs of the device into
the guest p2m. A rangeset is used in order to figure out which memory
to map/unmap. This makes it easier to keep track of the possible
overlaps with other BARs, and will also simplify MSI-X support, where
certain regions of a BAR might be used for the MSI-X table or PBA.

The BAR register handlers are used to detect attempts by the guest to
size or relocate the BARs.

Note that the long running BAR mapping and unmapping operations are
deferred to be performed by hvm_io_pending, so that they can be safely
preempted.

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
Changes since v7:
 - Order includes.
 - Add newline between switch cases.
 - Fix typo in comment (hopping).
 - Wrap ternary conditional in parentheses.
 - Remove CONFIG_HAS_PCI gueard from sched.h vpci_vcpu usage.
 - Add comment regarding vpci_vcpu usage.
 - Move rom_enabled from BAR struct to header.
 - Do not protect vpci_vcpu with __XEN__ guards.

Changes since v6:
 - s/vpci_check_pending/vpci_process_pending/.
 - Improve error handling in vpci_process_pending.
 - Add a comment that explains how vpci_check_bar_overlap works.
 - Add error messages to vpci_modify_bars and vpci_modify_rom.
 - Introduce vpci_hw_read16/32, in order to passthrough reads to
   the underlying hw.
 - Print BAR number on error in vpci_bar_write.
 - Place the CONFIG_HAS_PCI guards inside the vpci.h header and
   provide an empty vpci_vcpu structure for the !CONFIG_HAS_PCI case.
 - Define CONFIG_HAS_PCI in the test harness emul.h header before
   including vpci.h
 - Add ARM TODOs and an ARM-specific bodge to vpci_map_range due to
   the lack of preemption in {un}map_mmio_regions.
 - Make vpci_maybe_defer_map void.
 - Set rom_enabled in vpci_init_bars.
 - Defer enabling/disabling the memory decoding (or the ROM enable
   bit) until the memory has been mapped/unmapped.
 - Remove vpci_ prefix from static functions.
 - Use the same code in order to map the general BARs and the ROM
   BARs.
 - Remove the seg/bus local variables and use pdev->{seg,bus} instead.
 - Convert the bools in the BAR related structs into bool bitfields.
 - Add the must_check attribute to vpci_process_pending.
 - Open code check_bar_overlap inside modify_bars, which was it's only
   user.

Changes since v5:
 - Switch to the new handler type.
 - Use pci_sbdf_t to size the BARs.
 - Use a single return for vpci_modify_bar.
 - Do not return an error code from vpci_modify_bars, just log the
   failure.
 - Remove the 'sizing' parameter. Instead just let the guest write
   directly to the BAR, and read the value back. This simplifies the
   BAR register handlers, specially the read one.
 - Ignore ROM BAR writes with memory decoding enabled and ROM enabled.
 - Do not propagate failures to setup the ROM BAR in vpci_init_bars.
 - Add preemption support to the BAR mapping/unmapping operations.

Changes since v4:
 - Expand commit message to mention the reason behind the usage of
   rangesets.
 - Fix comment related to the inclusiveness of rangesets.
 - Fix off-by-one error in the calculation of the end of memory
   regions.
 - Store the state of the BAR (mapped/unmapped) in the vpci_bar
   enabled field, previously was only used by ROMs.
 - Fix double negation of return code.
 - Modify vpci_cmd_write so it has a single call to pci_conf_write16.
 - Print a warning when trying to write to the BAR with memory
   decoding enabled (and ignore the write).
 - Remove header_type local variable, it's used only once.
 - Move the read of the command register.
 - Restore previous command register value in the exit paths.
 - Only set address to INVALID_PADDR if the initial BAR value matches
~0 & PCI_BASE_ADDRESS_MEM_MASK.
 - Don't disable the enabled bit in the expansion ROM register, memory
   decoding is already disabled and takes precedence.
 - Don't use INVALID_PADDR, just set the initial BAR address to the
   value found in the hardware.
 - Introduce rom_enabled to store the status of the
   PCI_ROM_ADDRESS_ENABLE bit.
 - Reorder fields of the structure to prevent holes.

Changes since v3:
 - Propagate previous changes: drop xen_ prefix and use u8/u16/u32
   instead of the previous half_word/word/double_word.
 - Constify some of the paramerters.
 - s/VPCI_BAR_MEM/VPCI_BAR_MEM32/.
 - Simplify the number of fields stored for each BAR, a single address
   field is stored and contains the address of the BAR both on Xen and
   in the guest.
 - Allow the guest to move the BARs around in the physical memory map.
 - Add support for expansion ROM BARs.
 - Do not cache the value of the command register.
 - Remove a lab

[Xen-devel] [PATCH v8 09/11] vpci/msi: add MSI handlers

[Roger Pau Monne]

Add handlers for the MSI control, address, data and mask fields in
order to detect accesses to them and setup the interrupts as requested
by the guest.

Note that the pending register is not trapped, and the guest can
freely read/write to it.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Paul Durrant 
---
Changes since v7:
 - Don't store pci segment/bus on local variables.
 - Add an error label to init_msi.
 - Don't trap accesses to the PBA.
 - Fix msi_pending_bits_reg macro so it matches coding style.
 - Move the position of vectors in the vpci_msi struct.
 - Add a comment to clarify the expected state of vectors after
   pt_irq_create_bind and use XEN_DOMCTL_VMSI_X86_UNMASKED.

Changes since v6:
 - Use domain_spin_lock_irq_desc instead of open coding it.
 - Reduce the size of printed debug messages.
 - Constify domain in vpci_dump_msi.
 - Lock domlist_read_lock before iterating over the list of domains.
 - Make max_vectors and vectors uint8_t.
 - Drop the vpci_ prefix from the static functions in msi.c.
 - Turn the booleans in vpci_msi into bitfields.
 - Apply the mask bits to all vectors when enabling msi.
 - Remove the pos field.
 - Remove the usage of __msi_set_{enable/disable}.
 - Update the bindings when the message or data fields are updated.
 - Make vpci_msi_arch_disable return void, it wasn't returning any
   error.
 - Prevent the guest from writing to the pending bits field, it's read
   only as defined in the spec.
 - Add the must_check attribute to vpci_msi_arch_enable.

Changes since v5:
 - Update to new lock usage.
 - Change handlers to match the new type.
 - s/msi_flags/msi_gflags/, remove the local variables and use the new
   DOMCTL_VMSI_* defines.
 - Change the MSI arch function to take a vpci_msi instead of a
   vpci_arch_msi as parameter.
 - Fix the calculation of the guest vector for MSI injection to take
   into account the number of bits that can be modified.
 - Use INVALID_PIRQ everywhere.
 - Simplify exit path of vpci_msi_disable.
 - Remove the conditional when setting address64 and masking fields.
 - Add a process_pending_softirqs to the MSI dump loop.
 - Place the prototypes for the MSI arch-specific functions in
   xen/vpci.h.
 - Add parentheses around the INVALID_PIRQ definition.

Changes since v4:
 - Fix commit message.
 - Change the ASSERTs in vpci_msi_arch_mask into ifs.
 - Introduce INVALID_PIRQ.
 - Destroy the partially created bindings in case of failure in
   vpci_msi_arch_enable.
 - Just take the pcidevs lock once in vpci_msi_arch_disable.
 - Print an error message in case of failure of pt_irq_destroy_bind.
 - Make vpci_msi_arch_init return void.
 - Constify the arch parameter of vpci_msi_arch_print.
 - Use fixed instead of cpu for msi redirection.
 - Separate the header includes in vpci/msi.c between xen and asm.
 - Store the number of configured vectors even if MSI is not enabled
   and always return it in vpci_msi_control_read.
 - Fix/add comments in vpci_msi_control_write to clarify intended
   behavior.
 - Simplify usage of masks in vpci_msi_address_{upper_}write.
 - Add comment to vpci_msi_mask_{read/write}.
 - Don't use MASK_EXTR in vpci_msi_mask_write.
 - s/msi_offset/pos/ in vpci_init_msi.
 - Move control variable setup closer to it's usage.
 - Use d%d in vpci_dump_msi.
 - Fix printing of bitfield mask in vpci_dump_msi.
 - Fix definition of MSI_ADDR_REDIRECTION_MASK.
 - Shuffle the layout of vpci_msi to minimize gaps.
 - Remove the error label in vpci_init_msi.

Changes since v3:
 - Propagate changes from previous versions: drop xen_ prefix, drop
   return value from handlers, use the new vpci_val fields.
 - Use MASK_EXTR.
 - Remove the usage of GENMASK.
 - Add GFLAGS_SHIFT_DEST_ID and use it in msi_flags.
 - Add "arch" to the MSI arch specific functions.
 - Move the dumping of vPCI MSI information to dump_msi (key 'M').
 - Remove the guest_vectors field.
 - Allow the guest to change the number of active vectors without
   having to disable and enable MSI.
 - Check the number of active vectors when parsing the disable
   mask.
 - Remove the debug messages from vpci_init_msi.
 - Move the arch-specific part of the dump handler to x86/hvm/vmsi.c.
 - Use trylock in the dump handler to get the vpci lock.

Changes since v2:
 - Add an arch-specific abstraction layer. Note that this is only implemented
   for x86 currently.
 - Add a wrapper to detect MSI enabling for vPCI.

NB: I've only been able to test this with devices using a single MSI interrupt
and no mask register. I will try to find hardware that supports the mask
register and more than one vector, but I cannot make any promises.

If there are doubts about the untested parts we could always force Xen to
report no per-vector masking support and only 1 available vector, but I would
rather avoid doing it.
---
 xen/arch/x86/hvm/vmsi.c  | 142 +++
 xen/arch/x86/msi.c   |   3 +
 xen/drivers/vpci/Makefile|   2 +-
 xen/drivers/vp

[Xen-devel] [PATCH v8 02/11] x86/mmcfg: add handlers for the PVH Dom0 MMCFG areas

[Roger Pau Monne]

Introduce a set of handlers for the accesses to the MMCFG areas. Those
areas are setup based on the contents of the hardware MMCFG tables,
and the list of handled MMCFG areas is stored inside of the hvm_domain
struct.

The read/writes are forwarded to the generic vpci handlers once the
address is decoded in order to obtain the device and register the
guest is trying to access.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Paul Durrant 
Reviewed-by: Jan Beulich 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Paul Durrant 
---
Changes since v7:
 - Add check for end_bus >= start_bus to register_vpci_mmcfg_handler.
 - Protect destroy_vpci_mmcfg with the mmcfg_lock.

Changes since v6:
 - Move allocation of mmcfg outside of the locked region.
 - Do proper overlap checks when adding mmcfg regions.
 - Return _RETRY if the mcfg region cannot be found in the read/write
   handlers. This means the mcfg area has been removed between the
   accept and the read/write calls.

Changes since v5:
 - Switch to use pci_sbdf_t.
 - Switch to the new per vpci locks.
 - Move the mmcfg related external definitions to asm-x86/pci.h.

Changes since v4:
 - Change the attribute of pvh_setup_mmcfg to __hwdom_init.
 - Try to add as many MMCFG regions as possible, even if one fails to
   add.
 - Change some fields of the hvm_mmcfg struct: turn size into a
   unsigned int, segment into uint16_t and bus into uint8_t.
 - Convert some address parameters from unsigned long to paddr_t for
   consistency.
 - Make vpci_mmcfg_decode_addr return the decoded register in the
   return of the function.
 - Introduce a new macro to convert a MMCFG address into a BDF, and
   use it in vpci_mmcfg_decode_addr to clarify the logic.
 - In vpci_mmcfg_{read/write} unify the logic for 8B accesses and
   smaller ones.
 - Add the __hwdom_init attribute to register_vpci_mmcfg_handler.
 - Test that reg + size doesn't cross a device boundary.

Changes since v3:
 - Propagate changes from previous patches: drop xen_ prefix for vpci
   functions, pass slot and func instead of devfn and fix the error
   paths of the MMCFG handlers.
 - s/ecam/mmcfg/.
 - Move the destroy code to a separate function, so the hvm_mmcfg
   struct can be private to hvm/io.c.
 - Constify the return of vpci_mmcfg_find.
 - Use d instead of v->domain in vpci_mmcfg_accept.
 - Allow 8byte accesses to the mmcfg.

Changes since v1:
 - Added locking.
---
 xen/arch/x86/hvm/dom0_build.c|  21 +
 xen/arch/x86/hvm/hvm.c   |   4 +
 xen/arch/x86/hvm/io.c| 184 ++-
 xen/arch/x86/x86_64/mmconfig.h   |   4 -
 xen/include/asm-x86/hvm/domain.h |   4 +
 xen/include/asm-x86/hvm/io.h |   7 ++
 xen/include/asm-x86/pci.h|   6 ++
 7 files changed, 225 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 7d177a1d7d..e511809766 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -1056,6 +1057,24 @@ static int __init pvh_setup_acpi(struct domain *d, 
paddr_t start_info)
 return 0;
 }
 
+static void __hwdom_init pvh_setup_mmcfg(struct domain *d)
+{
+unsigned int i;
+int rc;
+
+for ( i = 0; i < pci_mmcfg_config_num; i++ )
+{
+rc = register_vpci_mmcfg_handler(d, pci_mmcfg_config[i].address,
+ pci_mmcfg_config[i].start_bus_number,
+ pci_mmcfg_config[i].end_bus_number,
+ pci_mmcfg_config[i].pci_segment);
+if ( rc )
+printk("Unable to setup MMCFG handler at %#lx for segment %u\n",
+   pci_mmcfg_config[i].address,
+   pci_mmcfg_config[i].pci_segment);
+}
+}
+
 int __init dom0_construct_pvh(struct domain *d, const module_t *image,
   unsigned long image_headroom,
   module_t *initrd,
@@ -1097,6 +1116,8 @@ int __init dom0_construct_pvh(struct domain *d, const 
module_t *image,
 return rc;
 }
 
+pvh_setup_mmcfg(d);
+
 panic("Building a PVHv2 Dom0 is not yet supported.");
 return 0;
 }
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 41b49038ac..42369d34cb 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -585,8 +585,10 @@ int hvm_domain_initialise(struct domain *d, unsigned long 
domcr_flags,
 spin_lock_init(&d->arch.hvm_domain.irq_lock);
 spin_lock_init(&d->arch.hvm_domain.uc_lock);
 spin_lock_init(&d->arch.hvm_domain.write_map.lock);
+rwlock_init(&d->arch.hvm_domain.mmcfg_lock);
 INIT_LIST_HEAD(&d->arch.hvm_domain.write_map.list);
 INIT_LIST_HEAD(&d->arch.hvm_domain.g2m_ioport_list);
+INIT_LIST_HEAD(&d->arch.hvm_domain.mmcfg_regions);
 
 rc = create_perdomain_mapping(d, PERDOMAIN_VIRT_START, 0, NULL, NULL);
 if ( rc )
@@ -732,6 +734,8 @@ 

[Xen-devel] [PATCH v8 01/11] vpci: introduce basic handlers to trap accesses to the PCI config space

[Roger Pau Monne]

This functionality is going to reside in vpci.c (and the corresponding
vpci.h header), and should be arch-agnostic. The handlers introduced
in this patch setup the basic functionality required in order to trap
accesses to the PCI config space, and allow decoding the address and
finding the corresponding handler that should handle the access
(although no handlers are implemented).

Note that the traps to the PCI IO ports registers (0xcf8/0xcfc) are
setup inside of a x86 HVM file, since that's not shared with other
arches.

A new XEN_X86_EMU_VPCI x86 domain flag is added in order to signal Xen
whether a domain should use the newly introduced vPCI handlers, this
is only enabled for PVH Dom0 at the moment.

A very simple user-space test is also provided, so that the basic
functionality of the vPCI traps can be asserted. This has been proven
quite helpful during development, since the logic to handle partial
accesses or accesses that expand across multiple registers is not
trivial.

The handlers for the registers are added to a linked list that's keep
sorted at all times. Both the read and write handlers support accesses
that expand across multiple emulated registers and contain gaps not
emulated.

Signed-off-by: Roger Pau Monné 
Acked-by: Wei Liu 
Reviewed-by: Jan Beulich 
[IO parts]
Reviewed-by: Paul Durrant 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Paul Durrant 
---
Changes since v7:
 - Constify d in vpci_portio_read.
 - ASSERT the correctness of the address in the read/write handlers.
 - Add newlines between non-fallthrough case statements.

Changes since v6:
 - Align the vpci handlers in the linker script.
 - Switch add/remove register functions to take a vpci parameter
   instead of a pci_dev.
 - Expand comment of merge_result.
 - Return X86EMUL_UNHANDLEABLE if accessing cfc and cf8 is disabled.

Changes since v5:
 - Use a spinlock per pci device.
 - Use the recently introduced pci_sbdf_t type.
 - Fix test harness to use the right handler type and the newly
   introduced lock.
 - Move the position of the vpci sections in the linker scripts.
 - Constify domain and pci_dev in vpci_{read/write}.
 - Fix typos in comments.
 - Use _XEN_VPCI_H_ as header guard.

Changes since v4:
* User-space test harness:
 - Do not redirect the output of the test.
 - Add main.c and emul.h as dependencies of the Makefile target.
 - Use the same rule to modify the vpci and list headers.
 - Remove underscores from local macro variables.
 - Add _check suffix to the test harness multiread function.
 - Change the value written by every different size in the multiwrite
   test.
 - Use { } to initialize the r16 and r20 arrays (instead of { 0 }).
 - Perform some of the read checks with the local variable directly.
 - Expand some comments.
 - Implement a dummy rwlock.
* Hypervisor code:
 - Guard the linker script changes with CONFIG_HAS_PCI.
 - Rename vpci_access_check to vpci_access_allowed and make it return
   bool.
 - Make hvm_pci_decode_addr return the register as return value.
 - Use ~3 instead of 0xfffc to remove the register offset when
   checking accesses to IO ports.
 - s/head/prev in vpci_add_register.
 - Add parentheses around & in vpci_add_register.
 - Fix register removal.
 - Change the BUGs in vpci_{read/write}_hw helpers to
   ASSERT_UNREACHABLE.
 - Make merge_result static and change the computation of the mask to
   avoid using a uint64_t.
 - Modify vpci_read to only read from hardware the not-emulated gaps.
 - Remove the vpci_val union and use a uint32_t instead.
 - Change handler read type to return a uint32_t instead of modifying
   a variable passed by reference.
 - Constify the data opaque parameter of read handlers.
 - Change the size parameter of the vpci_{read/write} functions to
   unsigned int.
 - Place the array of initialization handlers in init.rodata or
   .rodata depending on whether late-hwdom is enabled.
 - Remove the pci_devs lock, assume the Dom0 is well behaved and won't
   remove the device while trying to access it.
 - Change the recursive spinlock into a rw lock for performance
   reasons.

Changes since v3:
* User-space test harness:
 - Fix spaces in container_of macro.
 - Implement a dummy locking functions.
 - Remove 'current' macro make current a pointer to the statically
   allocated vpcu.
 - Remove unneeded parentheses in the pci_conf_readX macros.
 - Fix the name of the write test macro.
 - Remove the dummy EXPORT_SYMBOL macro (this was needed by the RB
   code only).
 - Import the max macro.
 - Test all possible read/write size combinations with all possible
   emulated register sizes.
 - Introduce a test for register removal.
* Hypervisor code:
 - Use a sorted list in order to store the config space handlers.
 - Remove some unneeded 'else' branches.
 - Make the IO port handlers always return X86EMUL_OKAY, and set the
   data to all 1's in case of read failure (write are simply ignored).
 - In hvm_select_ioreq_server reuse local variables when calling
   X

[Xen-devel] [PATCH v8 04/11] pci: split code to size BARs from pci_add_device

[Roger Pau Monne]

So that it can be called from outside in order to get the size of regular PCI
BARs. This will be required in order to map the BARs from PCI devices into PVH
Dom0 p2m.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
---
Changes since v7:
 - Do not return error from pci_size_mem_bar in order to keep previous
   behavior.

Changes since v6:
 - Remove the vf and addr local variables.
 - Change the way flags are declared.
 - Move the last bool parameter to the flags field.

Changes since v5:
 - Introduce a flags field for pci_size_mem_bar.
 - Use pci_sbdf_t.

Changes since v4:
 - Restore printing whether the BAR is from a vf.
 - Make the psize pointer parameter not optional.
 - s/u64/uint64_t.
 - Remove some unneeded parentheses.
 - Assert the return value is never 0.
 - Use the newly introduced pci_sbdf_t type.

Changes since v3:
 - Rename function to size BARs to pci_size_mem_bar.
 - Change the parameters passed to the function. Pass the position and
   whether the BAR is the last one, instead of the (base, max_bars,
   *index) tuple.
 - Make the function return the number of BARs consumed (1 for 32b, 2
   for 64b BARs).
 - Change the dprintk back to printk.
 - Do not log another error message in pci_add_device in case
   pci_size_mem_bar fails.
---
 xen/drivers/passthrough/pci.c | 97 ---
 xen/include/xen/pci.h |  5 +++
 2 files changed, 68 insertions(+), 34 deletions(-)

diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 519993d536..fb36b20834 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -603,6 +603,56 @@ static int iommu_add_device(struct pci_dev *pdev);
 static int iommu_enable_device(struct pci_dev *pdev);
 static int iommu_remove_device(struct pci_dev *pdev);
 
+unsigned int pci_size_mem_bar(pci_sbdf_t sbdf, unsigned int pos,
+  uint64_t *paddr, uint64_t *psize,
+  unsigned int flags)
+{
+uint32_t hi = 0, bar = pci_conf_read32(sbdf.seg, sbdf.bus, sbdf.dev,
+   sbdf.func, pos);
+uint64_t size;
+
+ASSERT((bar & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_MEMORY);
+pci_conf_write32(sbdf.seg, sbdf.bus, sbdf.dev, sbdf.func, pos, ~0);
+if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
+ PCI_BASE_ADDRESS_MEM_TYPE_64 )
+{
+if ( flags & PCI_BAR_LAST )
+{
+printk(XENLOG_WARNING
+   "%sdevice %04x:%02x:%02x.%u with 64-bit %sBAR in last 
slot\n",
+   (flags & PCI_BAR_VF) ? "SR-IOV " : "", sbdf.seg, sbdf.bus,
+   sbdf.dev, sbdf.func, (flags & PCI_BAR_VF) ? "vf " : "");
+*psize = 0;
+return 1;
+}
+hi = pci_conf_read32(sbdf.seg, sbdf.bus, sbdf.dev, sbdf.func, pos + 4);
+pci_conf_write32(sbdf.seg, sbdf.bus, sbdf.dev, sbdf.func, pos + 4, ~0);
+}
+size = pci_conf_read32(sbdf.seg, sbdf.bus, sbdf.dev, sbdf.func, pos) &
+   PCI_BASE_ADDRESS_MEM_MASK;
+if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
+ PCI_BASE_ADDRESS_MEM_TYPE_64 )
+{
+size |= (uint64_t)pci_conf_read32(sbdf.seg, sbdf.bus, sbdf.dev,
+  sbdf.func, pos + 4) << 32;
+pci_conf_write32(sbdf.seg, sbdf.bus, sbdf.dev, sbdf.func, pos + 4, hi);
+}
+else if ( size )
+size |= (uint64_t)~0 << 32;
+pci_conf_write32(sbdf.seg, sbdf.bus, sbdf.dev, sbdf.func, pos, bar);
+size = -size;
+
+if ( paddr )
+*paddr = (bar & PCI_BASE_ADDRESS_MEM_MASK) | ((uint64_t)hi << 32);
+*psize = size;
+
+if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
+ PCI_BASE_ADDRESS_MEM_TYPE_64 )
+return 2;
+
+return 1;
+}
+
 int pci_add_device(u16 seg, u8 bus, u8 devfn,
const struct pci_dev_info *info, nodeid_t node)
 {
@@ -674,11 +724,16 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
 unsigned int i;
 
 BUILD_BUG_ON(ARRAY_SIZE(pdev->vf_rlen) != PCI_SRIOV_NUM_BARS);
-for ( i = 0; i < PCI_SRIOV_NUM_BARS; ++i )
+for ( i = 0; i < PCI_SRIOV_NUM_BARS; )
 {
 unsigned int idx = pos + PCI_SRIOV_BAR + i * 4;
 u32 bar = pci_conf_read32(seg, bus, slot, func, idx);
-u32 hi = 0;
+pci_sbdf_t sbdf = {
+.seg = seg,
+.bus = bus,
+.dev = slot,
+.func = func,
+};
 
 if ( (bar & PCI_BASE_ADDRESS_SPACE) ==
  PCI_BASE_ADDRESS_SPACE_IO )
@@ -689,38 +744,12 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
seg, bus, slot, func, i);
 continue;
 }
-pci_conf_write32(seg, bus, slot, func, idx, ~0);
-if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
-

[Xen-devel] [PATCH v8 11/11] vpci/msix: add MSI-X handlers

[Roger Pau Monne]

Add handlers for accesses to the MSI-X message control field on the
PCI configuration space, and traps for accesses to the memory region
that contains the MSI-X table and PBA. This traps detect attempts from
the guest to configure MSI-X interrupts and properly sets them up.

Note that accesses to the Table Offset, Table BIR, PBA Offset and PBA
BIR are not trapped by Xen at the moment.

Finally, turn the panic in the Dom0 PVH builder into a warning.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v7:
 - Switch vpci.h macros to inline functions.
 - Change vpci_msix_arch_print_entry into vpci_msix_arch_print and
   make it print all the entries.
 - Add a log message if rangeset_remove_range fails to remove the BAR
   MSI-related range.
 - Introduce a new update_entry to disable and enable a MSIX entry in
   order to either update or set it up. This removes open coding it in
   two different places.
 - Unify access checks in access_allowed.
 - Add newlines between switch cases.
 - Expand max_entries to 12 bits.

Changes since v6:
 - Reduce the output of the debug keys.
 - Fix comments and code to match in vpci_msix_control_write.
 - Optimize size of the MSIX structure.
 - Convert 'tables[]' to a uint32_t in order to reduce the size of
   vpci_msix. Introduce some macros to make it easier to get the MSIX
   tables related data.
 - Limit size of the bool fields to 1 bit.
 - Remove the 'nr' field of vpci_msix_entry. The position can be
   calculated from the base of the entries array.
 - Drop the 'vpci_' prefix from the functions in msix.c, they are all
   static.
 - Remove the val local variable in control_read.
 - Initialize new_masked and new_enabled at declaration.
 - Recalculate the msix control value before writing it.
 - Remove the seg and bus local variables and use pdev->seg and
   pdev->bus instead.
 - Initialize msix at declaration in msix_{write/read}.
 - Add the must_check attribute to
   vpci_msix_arch_{enable/disable}_entry.

Changes since v5:
 - Update lock usage.
 - Unbind/unmap PIRQs when MSIX is disabled.
 - Share the arch-specific MSIX code with the MSI functions.
 - Do not reference the MSIX memory areas from the PCI BARs fields,
   instead fetch the BIR and offset each time needed.
 - Add the '_entry' suffix to the MSIX arch functions.
 - Prefix the vMSIX macros with 'V'.
 - s/gdprintk/gprintk/ in msix.c
 - Make vpci_msix_access_check return bool, and change it's name to
   vpci_msix_access_allowed.
 - Join the first two ifs in vpci_msix_{read/write} into a single one.
 - Allow Dom0 to write to the PBA area.
 - Add a note that reads from the PBA area will need to be translated
   if the PBA it's not identity mapped.

Changes since v4:
 - Remove parentheses around offsetof.
 - Add "being" to MSI-X enabling comment.
 - Use INVALID_PIRQ.
 - Add a simple sanity check to vpci_msix_arch_enable in order to
   detect wrong MSI-X entries more quickly.
 - Constify vpci_msix_arch_print entry argument.
 - s/cpu/fixed/ in vpci_msix_arch_print.
 - Dump the MSI-X info together with the MSI info.
 - Fix vpci_msix_control_write to take into account changes to the
   address and data fields when switching the function mask bit.
 - Only disable/enable the entries if the address or data fields have
   been updated.
 - Usew the BAR enable field to check if a BAR is mapped or not
   (instead of reading the command register for each device).
 - Fix error path in vpci_msix_read to set the return data to ~0.
 - Simplify mask usage in vpci_msix_write.
 - Cast data to uint64_t when shifting it 32 bits.
 - Fix writes to the table entry control register to take into account
   if the mask-all bit is set.
 - Add some comments to clarify the intended behavior of the code.
 - Align the PBA size to 64-bits.
 - Remove the error label in vpci_init_msix.
 - Try to compact the layout of the vpci_msix structure.
 - Remove the local table_bar and pba_bar variables from
   vpci_init_msix, they are used only once.

Changes since v3:
 - Propagate changes from previous versions: remove xen_ prefix, use
   the new fields in vpci_val and remove the return value from
   handlers.
 - Remove the usage of GENMASK.
 - Mave the arch-specific parts of the dump routine to the
   x86/hvm/vmsi.c dump handler.
 - Chain the MSI-X dump handler to the 'M' debug key.
 - Fix the header BAR mappings so that the MSI-X regions inside of
   BARs are unmapped from the domain p2m in order for the handlers to
   work properly.
 - Unconditionally trap and forward accesses to the PBA MSI-X area.
 - Simplify the conditionals in vpci_msix_control_write.
 - Fix vpci_msix_accept to use a bool type.
 - Allow all supported accesses as described in the spec to the MSI-X
   table.
 - Truncate the returned address when the access is a 32b read.
 - Always return X86EMUL_OKAY from the handlers, returning ~0 in the
   read case if the access is not supported, or ignoring writes.
 - Do not check that max_entries is != 0 in the ini

[Xen-devel] [PATCH v8 08/11] x86/pt: mask MSI vectors on unbind

[Roger Pau Monne]

When a MSI device with per-vector masking capabilities is detected or
added to Xen all the vectors are masked when initializing it. This
implies that the first time the interrupt is bound to a domain it's
masked.

This however only applies to the first time the interrupt is bound
because neither the unbind nor the pirq unmap will mask the vector
again. In order to fix this re-mask the interrupt when unbinding it
from a guest. This makes sure that pairs of bind/unbind will always
get the same masking state.

Note that no issues have been reported regarding this behavior because
QEMU always uses the newly introduced XEN_PT_GFLAGSSHIFT_UNMASKED when
binding interrupts, so it's always unmasked.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
---
Changes since v7:
 - New in this version.
---
 xen/drivers/passthrough/io.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 8f16e6c0a5..bab3aa349a 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -645,7 +645,22 @@ int pt_irq_destroy_bind(
 }
 break;
 case PT_IRQ_TYPE_MSI:
+{
+unsigned long flags;
+struct irq_desc *desc = domain_spin_lock_irq_desc(d, machine_gsi,
+  &flags);
+
+if ( !desc )
+return -EINVAL;
+/*
+ * Leave the MSI masked, so that the state when calling
+ * pt_irq_create_bind is consistent across bind/unbinds.
+ */
+guest_mask_msi_irq(desc, true);
+spin_unlock_irqrestore(&desc->lock, flags);
 break;
+}
+
 default:
 return -EOPNOTSUPP;
 }
-- 
2.15.1


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

[Xen-devel] [PATCH v8 03/11] x86/physdev: enable PHYSDEVOP_pci_mmcfg_reserved for PVH Dom0

[Roger Pau Monne]

So that MMCFG regions not present in the MCFG ACPI table can be added
at run time by the hardware domain.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Jan Beulich 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v7:
 - Add newline in hvm_physdev_op for non-fallthrough case.

Changes since v6:
 - Do not return EEXIST if the same exact region is already tracked by
   Xen.

Changes since v5:
 - Check for has_vpci before calling register_vpci_mmcfg_handler
   instead of checking for is_hvm_domain.

Changes since v4:
 - Change the hardware_domain check in hvm_physdev_op to a vpci check.
 - Only register the MMCFG area, but don't scan it.

Changes since v3:
 - New in this version.
---
 xen/arch/x86/hvm/hypercall.c |  5 +
 xen/arch/x86/hvm/io.c| 16 +++-
 xen/arch/x86/physdev.c   | 11 +++
 3 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index 5742dd1797..85eacd7d33 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -89,6 +89,11 @@ static long hvm_physdev_op(int cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 if ( !has_pirq(curr->domain) )
 return -ENOSYS;
 break;
+
+case PHYSDEVOP_pci_mmcfg_reserved:
+if ( !has_vpci(curr->domain) )
+return -ENOSYS;
+break;
 }
 
 if ( !curr->hcall_compat )
diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index 04425c064b..556810c126 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -507,10 +507,9 @@ static const struct hvm_mmio_ops vpci_mmcfg_ops = {
 .write = vpci_mmcfg_write,
 };
 
-int __hwdom_init register_vpci_mmcfg_handler(struct domain *d, paddr_t addr,
- unsigned int start_bus,
- unsigned int end_bus,
- unsigned int seg)
+int register_vpci_mmcfg_handler(struct domain *d, paddr_t addr,
+unsigned int start_bus, unsigned int end_bus,
+unsigned int seg)
 {
 struct hvm_mmcfg *mmcfg, *new = xmalloc(struct hvm_mmcfg);
 
@@ -535,9 +534,16 @@ int __hwdom_init register_vpci_mmcfg_handler(struct domain 
*d, paddr_t addr,
 if ( new->addr < mmcfg->addr + mmcfg->size &&
  mmcfg->addr < new->addr + new->size )
 {
+int ret = -EEXIST;
+
+if ( new->addr == mmcfg->addr &&
+ new->start_bus == mmcfg->start_bus &&
+ new->segment == mmcfg->segment &&
+ new->size == mmcfg->size )
+ret = 0;
 write_unlock(&d->arch.hvm_domain.mmcfg_lock);
 xfree(new);
-return -EEXIST;
+return ret;
 }
 
 if ( list_empty(&d->arch.hvm_domain.mmcfg_regions) )
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 380d36f6b9..984491c3dc 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -557,6 +557,17 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) 
arg)
 
 ret = pci_mmcfg_reserved(info.address, info.segment,
  info.start_bus, info.end_bus, info.flags);
+if ( !ret && has_vpci(currd) )
+{
+/*
+ * For HVM (PVH) domains try to add the newly found MMCFG to the
+ * domain.
+ */
+ret = register_vpci_mmcfg_handler(currd, info.address,
+  info.start_bus, info.end_bus,
+  info.segment);
+}
+
 break;
 }
 
-- 
2.15.1


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

[Xen-devel] [PATCH v8 06/11] xen: introduce rangeset_consume_ranges

[Roger Pau Monne]

This function allows to iterate over a rangeset while removing the
processed regions.

This will be used in order to split processing of large memory areas
when mapping them into the guest p2m.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Wei Liu 
---
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
Changes since v6:
 - Expand commit message.
 - Add a comment to describe the expected function behavior.
 - Fix indentation.

Changes since v5:
 - New in this version.
---
 xen/common/rangeset.c  | 28 
 xen/include/xen/rangeset.h | 10 ++
 2 files changed, 38 insertions(+)

diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index ade34f6a50..bb68ce62e4 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -350,6 +350,34 @@ int rangeset_claim_range(struct rangeset *r, unsigned long 
size,
 return 0;
 }
 
+int rangeset_consume_ranges(struct rangeset *r,
+int (*cb)(unsigned long s, unsigned long e, void *,
+  unsigned long *c),
+void *ctxt)
+{
+int rc = 0;
+
+write_lock(&r->lock);
+while ( !rangeset_is_empty(r) )
+{
+unsigned long consumed = 0;
+struct range *x = first_range(r);
+
+rc = cb(x->s, x->e, ctxt, &consumed);
+
+ASSERT(consumed <= x->e - x->s + 1);
+x->s += consumed;
+if ( x->s > x->e )
+destroy_range(r, x);
+
+if ( rc )
+break;
+}
+write_unlock(&r->lock);
+
+return rc;
+}
+
 int rangeset_add_singleton(
 struct rangeset *r, unsigned long s)
 {
diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/rangeset.h
index 1f83b1f44b..583b72bb0c 100644
--- a/xen/include/xen/rangeset.h
+++ b/xen/include/xen/rangeset.h
@@ -70,6 +70,16 @@ int rangeset_report_ranges(
 struct rangeset *r, unsigned long s, unsigned long e,
 int (*cb)(unsigned long s, unsigned long e, void *), void *ctxt);
 
+/*
+ * Note that the consume function can return an error value apart from
+ * -ERESTART, and that no cleanup is performed (ie: the user should call
+ * rangeset_destroy if needed).
+ */
+int rangeset_consume_ranges(struct rangeset *r,
+int (*cb)(unsigned long s, unsigned long e,
+  void *, unsigned long *c),
+void *ctxt);
+
 /* Add/remove/query a single number. */
 int __must_check rangeset_add_singleton(
 struct rangeset *r, unsigned long s);
-- 
2.15.1


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

[Xen-devel] [PATCH v8 00/11] vpci: PCI config space emulation

[Roger Pau Monne]

Hello,

The following series contain an implementation of handlers for the PCI
configuration space inside of Xen. This allows Xen to detect accesses
to the PCI configuration space and react accordingly.

Why is this needed? IMHO, there are two main points of doing all this
emulation inside of Xen, the first one is to prevent adding a bunch of
duplicated Xen PV specific code to each OS we want to support in PVH
mode. This just promotes Xen code duplication amongst OSes, which
leads to a higher maintainership burden.

The second reason would be that this code (or it's functionality to be
more precise) already exists in QEMU (and pciback to a degree), and
it's code that we already support and maintain. By moving it into the
hypervisor itself every guest type can make use of it, and should be
shared between them all. I know that the code in this series is not
yet suitable for DomU HVM guests in it's current state, but it should
be in due time.

As usual, each patch contains a changeset summary between versions,
I'm not going to copy the list of changes here.

Patch 1 is a pre-patch to allow internal PIO handlers return RETRY.
Patch 2 modifies a function to decode a PCI IO port access into
pci_sbdf_t and register (which is shared with the ioreq code). Patch 3
implements the generic handlers for accesses to the PCI configuration
space together with a minimal user-space test harness that I've used
during development. Currently a per-device linked list is used in order
to store the list of handlers, and they are sorted based on their offset
inside of the configuration space. Patch 2 also adds the x86 port IO
traps and wires them into the newly introduced vPCI dispatchers. Patch 4
and 5 adds handlers for the MMCFG areas (as found on the MMCFG ACPI
table). Patches 6, 7 and 8 are mostly code moment/refactoring in order
to implement support for BAR mapping in patch 9. Finally patches 10 and
12 add support for trapping accesses to the MSI and MSI-X capabilities
respectively, so that interrupts are properly setup on behalf of Dom0.

The branch containing the patches can be found at:

git://xenbits.xen.org/people/royger/xen.git vpci_v8

Note that this is only safe to use for the hardware domain (that's
trusted), any non-trusted domain will need a lot more of traps before
it can freely access the PCI configuration space.

Thanks, Roger.

Roger Pau Monne (11):
  vpci: introduce basic handlers to trap accesses to the PCI config
space
  x86/mmcfg: add handlers for the PVH Dom0 MMCFG areas
  x86/physdev: enable PHYSDEVOP_pci_mmcfg_reserved for PVH Dom0
  pci: split code to size BARs from pci_add_device
  pci: add support to size ROM BARs to pci_size_mem_bar
  xen: introduce rangeset_consume_ranges
  vpci/bars: add handlers to map the BARs
  x86/pt: mask MSI vectors on unbind
  vpci/msi: add MSI handlers
  vpci: add a priority parameter to the vPCI register initializer
  vpci/msix: add MSI-X handlers

 .gitignore|   3 +
 tools/libxl/libxl_x86.c   |   2 +-
 tools/tests/Makefile  |   1 +
 tools/tests/vpci/Makefile |  37 +++
 tools/tests/vpci/emul.h   | 134 ++
 tools/tests/vpci/main.c   | 309 ++
 xen/arch/arm/xen.lds.S|  14 +
 xen/arch/x86/domain.c |  19 +-
 xen/arch/x86/hvm/dom0_build.c |  23 +-
 xen/arch/x86/hvm/hvm.c|   7 +
 xen/arch/x86/hvm/hypercall.c  |   5 +
 xen/arch/x86/hvm/io.c | 293 +
 xen/arch/x86/hvm/ioreq.c  |   4 +
 xen/arch/x86/hvm/vmsi.c   | 228 
 xen/arch/x86/msi.c|   3 +
 xen/arch/x86/physdev.c|  11 +
 xen/arch/x86/setup.c  |   3 +-
 xen/arch/x86/x86_64/mmconfig.h|   4 -
 xen/arch/x86/xen.lds.S|  14 +
 xen/common/rangeset.c |  28 ++
 xen/drivers/Makefile  |   2 +-
 xen/drivers/passthrough/io.c  |  15 ++
 xen/drivers/passthrough/pci.c | 107 +---
 xen/drivers/vpci/Makefile |   1 +
 xen/drivers/vpci/header.c | 539 ++
 xen/drivers/vpci/msi.c| 338 
 xen/drivers/vpci/msix.c   | 464 
 xen/drivers/vpci/vpci.c   | 473 +
 xen/include/asm-x86/domain.h  |   1 +
 xen/include/asm-x86/hvm/domain.h  |   7 +
 xen/include/asm-x86/hvm/io.h  |  20 ++
 xen/include/asm-x86/msi.h |   3 +
 xen/include/asm-x86/pci.h |   6 +
 xen/include/public/arch-x86/xen.h |   5 +-
 xen/include/xen/irq.h |   1 +
 xen/include/xen/pci.h |   9 +
 xen/include/xen/pci_regs.h|   8 +
 xen/include/xen/rangeset.h|  10 +
 xen/include/xen/sched.h   |   4 +
 xen/include/xen/vpci.h| 219 
 40 files changed, 3325 insertions(+), 49 deletions(-)
 create mode 100644 tools/tests/vpci/Makefile
 create mode 100644

[Xen-devel] [PATCH v8 05/11] pci: add support to size ROM BARs to pci_size_mem_bar

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné 
Reviewed-by: Jan Beulich 
---
Cc: Jan Beulich 
---
Changes since v6:
 - Remove the rom local variable.

Changes since v5:
 - Use the flags field.
 - Introduce a mask local variable.
 - Simplify return.

Changes since v4:
 - New in this version.
---
 xen/drivers/passthrough/pci.c | 28 ++--
 xen/include/xen/pci.h |  1 +
 2 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index fb36b20834..bf26027f4c 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -610,11 +610,16 @@ unsigned int pci_size_mem_bar(pci_sbdf_t sbdf, unsigned 
int pos,
 uint32_t hi = 0, bar = pci_conf_read32(sbdf.seg, sbdf.bus, sbdf.dev,
sbdf.func, pos);
 uint64_t size;
-
-ASSERT((bar & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_MEMORY);
+bool is64bits = !(flags & PCI_BAR_ROM) &&
+(bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) == PCI_BASE_ADDRESS_MEM_TYPE_64;
+uint32_t mask = (flags & PCI_BAR_ROM) ? (uint32_t)PCI_ROM_ADDRESS_MASK
+  : 
(uint32_t)PCI_BASE_ADDRESS_MEM_MASK;
+
+ASSERT(!((flags & PCI_BAR_VF) && (flags & PCI_BAR_ROM)));
+ASSERT((flags & PCI_BAR_ROM) ||
+   (bar & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_MEMORY);
 pci_conf_write32(sbdf.seg, sbdf.bus, sbdf.dev, sbdf.func, pos, ~0);
-if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
- PCI_BASE_ADDRESS_MEM_TYPE_64 )
+if ( is64bits )
 {
 if ( flags & PCI_BAR_LAST )
 {
@@ -628,10 +633,9 @@ unsigned int pci_size_mem_bar(pci_sbdf_t sbdf, unsigned 
int pos,
 hi = pci_conf_read32(sbdf.seg, sbdf.bus, sbdf.dev, sbdf.func, pos + 4);
 pci_conf_write32(sbdf.seg, sbdf.bus, sbdf.dev, sbdf.func, pos + 4, ~0);
 }
-size = pci_conf_read32(sbdf.seg, sbdf.bus, sbdf.dev, sbdf.func, pos) &
-   PCI_BASE_ADDRESS_MEM_MASK;
-if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
- PCI_BASE_ADDRESS_MEM_TYPE_64 )
+size = pci_conf_read32(sbdf.seg, sbdf.bus, sbdf.dev, sbdf.func,
+   pos) & mask;
+if ( is64bits )
 {
 size |= (uint64_t)pci_conf_read32(sbdf.seg, sbdf.bus, sbdf.dev,
   sbdf.func, pos + 4) << 32;
@@ -643,14 +647,10 @@ unsigned int pci_size_mem_bar(pci_sbdf_t sbdf, unsigned 
int pos,
 size = -size;
 
 if ( paddr )
-*paddr = (bar & PCI_BASE_ADDRESS_MEM_MASK) | ((uint64_t)hi << 32);
+*paddr = (bar & mask) | ((uint64_t)hi << 32);
 *psize = size;
 
-if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
- PCI_BASE_ADDRESS_MEM_TYPE_64 )
-return 2;
-
-return 1;
+return is64bits ? 2 : 1;
 }
 
 int pci_add_device(u16 seg, u8 bus, u8 devfn,
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 2f171a8dcc..4cfa774615 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -191,6 +191,7 @@ const char *parse_pci_seg(const char *, unsigned int *seg, 
unsigned int *bus,
 
 #define PCI_BAR_VF  (1u << 0)
 #define PCI_BAR_LAST(1u << 1)
+#define PCI_BAR_ROM (1u << 2)
 unsigned int pci_size_mem_bar(pci_sbdf_t sbdf, unsigned int pos,
   uint64_t *paddr, uint64_t *psize,
   unsigned int flags);
-- 
2.15.1


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

Re: [Xen-devel] PVH backports to 4.9 and 4.8

[Simon Gaiser]

George Dunlap:
> On 01/23/2018 04:06 AM, Simon Gaiser wrote:
>> George Dunlap:
>>> Part of our solution to XSA-254 SP3 (aka "Meltdown") is to backport
>>> the PVH mode from 4.10 to 4.9 and 4.8.  This will first allow people
>>> able to run PVH kernels to switch their PV guests directly to PVH
>>> guests; and second, eventually enable the backport of patches which
>>> will enable transparent changing of PV guests into PVH guests.
>>>
>>> All of the hypervisor support seems to have existed already in 4.8, so
>>> the only backports involve toolstack patches.
>>>
>>> I've put up two trees for a first-cut backport of the PVH
>>> functionality, to 4.9 and 4.8 here:
>>>
>>> git://xenbits.xen.org/people/gdunlap/xen.git
>>>
>>> Branches out/pvh-backport/4.8/v1 and out/pvh-backport/4.9/v1
>>>
>>> Below are the patches backported from 4.10 to 4.9 (23 patches total):
>> [...]
>>
>> So future 4.8 releases will include the backports, right? Asking because
>> the AFAICS the 4.8.3-pre-shim-comet branch include them but staging-4.8
>> does not.
> 
> Some of us have had informal conversations about backporting PVH and
> Comet host/toolstack patches to 4.8, and a number of us think it's a
> good idea, but we haven't had an official discussion with all the
> stakeholders yet.  We'll come back to it once more of the fires have
> been put out.
> 
> Feel free to remind us in a month or so if you still haven't seen any
> patches in the stable-4.8 branch. :-)

Ok, thank you for the quick reply. In Qubes we are using PVH with 4.8
using the old device_model_version=none config option. And changing this
would be much easier before release (So the change should be in our rc
now). Anyway if it's not decided yet, we will have to guess what ends up
in future 4.8.z releases.



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

[Xen-devel] [PATCH v2] x86/compat: fix compilation errors with clang 6

[Roger Pau Monne]

The following errors are generated when compiling Xen with clang 6:

In file included from x86_64/asm-offsets.c:9:
In file included from /root/src/xen/xen/include/xen/sched.h:8:
In file included from /root/src/xen/xen/include/xen/shared.h:6:
In file included from /root/src/xen/xen/include/compat/arch-x86/../xen.h:9:
/root/src/xen/xen/include/compat/arch-x86/xen.h:10:10: error: the current 
#pragma pack aligment
  value is modified in the included file [-Werror,-Wpragma-pack]
#include "xen-x86_32.h"
 ^
/root/src/xen/xen/include/compat/arch-x86/xen-x86_32.h:40:9: note: previous 
'#pragma pack'
  directive that modifies alignment is here
#pragma pack()
^
In file included from x86_64/asm-offsets.c:9:
In file included from /root/src/xen/xen/include/xen/sched.h:8:
In file included from /root/src/xen/xen/include/xen/shared.h:6:
/root/src/xen/xen/include/compat/arch-x86/../xen.h:9:10: error: the current 
#pragma pack aligment
  value is modified in the included file [-Werror,-Wpragma-pack]
#include "arch-x86/xen.h"
 ^
/root/src/xen/xen/include/compat/arch-x86/xen.h:71:9: note: previous '#pragma 
pack' directive that
  modifies alignment is here
#pragma pack()
^
2 errors generated.

Fix this by using pragma push/pop in order to store the current pragma
value in the compiler stack and later restoring it when using clang.

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
Changes since v1:
 - Only use push/pop with clang.
---
 xen/include/Makefile | 5 +
 1 file changed, 5 insertions(+)

diff --git a/xen/include/Makefile b/xen/include/Makefile
index 1299b1962f..19066a33a0 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -35,8 +35,13 @@ cppflags-y:= -include public/xen-compat.h 
-DXEN_GENERATING_COMPA
 cppflags-$(CONFIG_X86)+= -m32
 
 # 8-byte types are 4-byte aligned on x86_32 ...
+ifeq ($(clang),y)
+prefix-$(CONFIG_X86)  := \#pragma pack(push, 4)
+suffix-$(CONFIG_X86)  := \#pragma pack(pop)
+else
 prefix-$(CONFIG_X86)  := \#pragma pack(4)
 suffix-$(CONFIG_X86)  := \#pragma pack()
+endif
 
 endif
 
-- 
2.15.1


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

Re: [Xen-devel] [PATCH v2 3/3] drop "domain_" prefix from struct domain's dirty CPU mask

[Boris Ostrovsky]

On 01/23/2018 05:16 AM, Jan Beulich wrote:
> It being a field of struct domain is sufficient to recognize its
> purpose.
>
> Signed-off-by: Jan Beulich 
> Reviewed-by: Wei Liu 
> Reviewed-by: George Dunlap 
> Reviewed-by: Andrew Cooper 
> ---
> v2: White space changes (consolidate split line statements into single
> line ones). Re-base.


Reviewed-by: Boris Ostrovsky 

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

Re: [Xen-devel] [PATCH] x86/compat: fix compilation errors with clang 6

[Jan Beulich]

>>> On 23.01.18 at 14:54,  wrote:
> On Tue, Jan 23, 2018 at 06:34:44AM -0700, Jan Beulich wrote:
>> >>> On 23.01.18 at 13:38,  wrote:
>> > Fix this by using pragma push/pop in order to store the current pragma
>> > value in the compiler stack and later restoring it.
>> 
>> For Linux this is fine all the way back to gcc 4.1 afaict, but what
>> about other OSes using gcc? In 4.1, only config/linux.h and a few
>> special config/i386/*.h define the necessary macro
>> (HANDLE_PRAGMA_PACK_PUSH_POP).
> 
> OK, then I have the following version:
> 
> diff --git a/xen/include/Makefile b/xen/include/Makefile
> index 1299b1962f..19066a33a0 100644
> --- a/xen/include/Makefile
> +++ b/xen/include/Makefile
> @@ -35,8 +35,13 @@ cppflags-y:= -include public/xen-compat.h 
> -DXEN_GENERATING_COMPA
>  cppflags-$(CONFIG_X86)+= -m32
>  
>  # 8-byte types are 4-byte aligned on x86_32 ...
> +ifeq ($(clang),y)
> +prefix-$(CONFIG_X86)  := \#pragma pack(push, 4)
> +suffix-$(CONFIG_X86)  := \#pragma pack(pop)
> +else
>  prefix-$(CONFIG_X86)  := \#pragma pack(4)
>  suffix-$(CONFIG_X86)  := \#pragma pack()
> +endif
>  
>  endif
>  
> 
> Since ATM that's a clang only issue I guess we can leave it like that.
> I'm not aware of anyway to know whether the compiler supports pragma
> pack with psuh/pop.
> 
> Let me know if that's fine and I will send out a formal v2.

Yes, that's fine indeed. Checking whether the construct is
supported would involve a test compile, which I think we should
bother doing only when we can't avoid this anymore.

Jan


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

Re: [Xen-devel] [PATCH] x86/compat: fix compilation errors with clang 6

[Roger Pau Monné]

On Tue, Jan 23, 2018 at 06:34:44AM -0700, Jan Beulich wrote:
> >>> On 23.01.18 at 13:38,  wrote:
> > Fix this by using pragma push/pop in order to store the current pragma
> > value in the compiler stack and later restoring it.
> 
> For Linux this is fine all the way back to gcc 4.1 afaict, but what
> about other OSes using gcc? In 4.1, only config/linux.h and a few
> special config/i386/*.h define the necessary macro
> (HANDLE_PRAGMA_PACK_PUSH_POP).

OK, then I have the following version:

diff --git a/xen/include/Makefile b/xen/include/Makefile
index 1299b1962f..19066a33a0 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -35,8 +35,13 @@ cppflags-y:= -include public/xen-compat.h 
-DXEN_GENERATING_COMPA
 cppflags-$(CONFIG_X86)+= -m32
 
 # 8-byte types are 4-byte aligned on x86_32 ...
+ifeq ($(clang),y)
+prefix-$(CONFIG_X86)  := \#pragma pack(push, 4)
+suffix-$(CONFIG_X86)  := \#pragma pack(pop)
+else
 prefix-$(CONFIG_X86)  := \#pragma pack(4)
 suffix-$(CONFIG_X86)  := \#pragma pack()
+endif
 
 endif
 

Since ATM that's a clang only issue I guess we can leave it like that.
I'm not aware of anyway to know whether the compiler supports pragma
pack with psuh/pop.

Let me know if that's fine and I will send out a formal v2.

Roger.

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

[Xen-devel] [PATCH] x86: avoid insn patching on fully async entry paths

[Jan Beulich]

As long as our patching logic isn't safe against concurrently occurring
NMI or #MC we should avoid patching those paths. For sanity's sake also
avoid this on the #DF entry path.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -698,7 +698,7 @@ ENTRY(alignment_check)
 ENTRY(double_fault)
 movl  $TRAP_double_fault,4(%rsp)
 /* Set AC to reduce chance of further SMAP faults */
-SAVE_ALL STAC
+SAVE_ALL STAC_SAFE
 
 GET_STACK_END(bx)
 mov   STACK_CPUINFO_FIELD(xen_cr3)(%rbx), %rbx
@@ -727,7 +727,7 @@ ENTRY(nmi)
 pushq $0
 movl  $TRAP_nmi,4(%rsp)
 handle_ist_exception:
-SAVE_ALL CLAC
+SAVE_ALL CLAC_SAFE
 
 GET_STACK_END(14)
 mov   STACK_CPUINFO_FIELD(xen_cr3)(%r14), %rcx
--- a/xen/include/asm-x86/asm_defns.h
+++ b/xen/include/asm-x86/asm_defns.h
@@ -203,8 +203,22 @@ void ret_from_intr(void);
 altinstruction_entry 661b, 662b, X86_FEATURE_XEN_SMAP, 3, 3;   \
 .popsection
 
-#define ASM_STAC ASM_AC(STAC)
-#define ASM_CLAC ASM_AC(CLAC)
+.macro ASM_STAC
+ASM_AC(STAC)
+.endm
+.macro ASM_CLAC
+ASM_AC(CLAC)
+.endm
+.macro ASM_STAC_SAFE
+pushf
+orl   $X86_EFLAGS_AC, (%rsp)
+popf
+.endm
+.macro ASM_CLAC_SAFE
+pushf
+andl  $~X86_EFLAGS_AC, (%rsp)
+popf
+.endm
 
 .macro write_cr3 val:req, tmp1:req, tmp2:req
 mov   %cr4, %\tmp1
@@ -241,16 +255,8 @@ static always_inline void stac(void)
 
 #ifdef __ASSEMBLY__
 .macro SAVE_ALL op, compat=0
-.ifeqs "\op", "CLAC"
-ASM_CLAC
-.else
-.ifeqs "\op", "STAC"
-ASM_STAC
-.else
 .ifnb \op
-.err
-.endif
-.endif
+ASM_\op
 .endif
 addq  $-(UREGS_error_code-UREGS_r15), %rsp
 cld




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

Re: [Xen-devel] [Xen EFI] Impossible to limit the dom0 memory

[Jan Beulich]

>>> On 23.01.18 at 12:18,  wrote:
> As explained on the Xen_EFI wiki page, I have added a line "options=" 
> into my file "/boot/efi/EFI/xen/xen.cfg" :
> 
> ```
> # cat /boot/efi/EFI/xen/xen.cfg :
> [global]
> default=xen
> 
> [xen]
> options=dom0_mem=1G,max:1G
> kernel=vmlinuz root=/dev/md2 ro rootdelay=10 noquiet nosplash
> ramdisk=initrd.img
> ```
> 
> With the line `options=dom0_mem=1G,max:1G` the server reboot infinitely.
> Without the line `options=dom0_mem=1G,max:1G`, the server boot 
> correctly, but obviously, the dom0 memory is in ballooning mode.
> 
> I have attached a screen shot of the boot lines with the last lines I 
> can see before the reboot. Unfortunately, I have nothing in kern.log.

Of course there's nothing in a log on disk - the crash occurs way to
early. Yet you'll need to provide the kernel messages, either via
serial console (and "earlyprintk=xen") or some other means, in
order for anyone to be able to tell/guess where the problem might
be.

Jan


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

Re: [Xen-devel] [PATCH] x86/compat: fix compilation errors with clang 6

[Jan Beulich]

>>> On 23.01.18 at 13:38,  wrote:
> Fix this by using pragma push/pop in order to store the current pragma
> value in the compiler stack and later restoring it.

For Linux this is fine all the way back to gcc 4.1 afaict, but what
about other OSes using gcc? In 4.1, only config/linux.h and a few
special config/i386/*.h define the necessary macro
(HANDLE_PRAGMA_PACK_PUSH_POP).

Jan


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

Re: [Xen-devel] [PATCH RFC v2 00/12] xen/x86: use per-vcpu stacks for 64 bit pv domains

[Juergen Gross]

On 23/01/18 12:45, Andrew Cooper wrote:
> On 23/01/18 10:10, Juergen Gross wrote:
>> On 23/01/18 10:31, Jan Beulich wrote:
>> On 23.01.18 at 10:24,  wrote:
 On 23/01/18 09:53, Jan Beulich wrote:
 On 23.01.18 at 07:34,  wrote:
>> On 22/01/18 19:39, Andrew Cooper wrote:
>>> One of my concerns is that this patch series moves further away from the
>>> secondary goal of my KAISER series, which was to have the IDT and GDT
>>> mapped at the same linear addresses on every CPU so a) SIDT/SGDT don't
>>> leak which CPU you're currently scheduled on into PV guests and b) the
>>> context switch code can drop a load of its slow instructions like LGDT
>>> and the VMWRITEs to update the VMCS.
>> The GDT address of a PV vcpu is depending on vcpu_id only. I don't
>> see why the IDT can't be mapped to the same address on each cpu with
>> my approach.
> You're not introducing a per-CPU range in the page tables afaics
> (again from overview and titles only), yet with the IDT needing
> to be per-CPU you'd also need a per-CPU range to map it to if
> you want to avoid the LIDT as well as exposing what CPU you're
> on (same goes for the GDT and the respective avoidance of LGDT
> afaict).
 After a quick look I don't see why a Meltdown mitigation can't use
 the same IDT for all cpus: the only reason I could find for having
 per-cpu IDTs seems to be in SVM code, so it seems to be AMD specific.
 And AMD won't need XPTI at all.
>>> Isn't your RFC series allowing XPTI to be enabled even on AMD?
>> Yes, you are right. This might either want to be revisited or the
>> address space to be activated for SVM domains could map an IDT with
>> IST related traps removed.
> 
> I've experimented quite a lot in this area.  Ideally, we'd vmload/save
> in the SVM critical region (like all other hypervisors) at which point
> we don't need any adjustments to the IDT (as IST references are safe to
> use), and we'd catch stack overflows in the #DF handler rather than
> immediately triple faulting.
> 
> Using LIDT to switch between alternative IDTs, or INVLPG to swap the
> mapping under a fixed linear address are both much slower than the
> current implementation.
> 
>>
 The GDT of pv domains is already in the per-domain region even without
 my patches, so I don't have to change anything regarding usage of LGDT.
>>> Andrew's point was that eliminating the LGDT is a secondary goal.
>> With per-cpu mappings this is surely an obvious optimization. In the
>> end the overall performance should be taken as base for a decision.
>> His main point was avoiding exposing data like the physical cpu number
>> and this doesn't apply here, as the GDT is per vcpu in my case.
> 
> The GDT leaks vcpu_id into guest userspace, which is similarly problematic.

Mind explaining this? Why is leaking the vcpu_id problematic?

> The secondary goals of my KAISER series stand irrespective of the
> Meltdown issues:
> * The stack and mutable critical structures really should be numa-local
> to the CPU using it.
> * The GDT should sit fully fat over zeros.  At the moment in HVM
> context, there are 14 frames of arbitrary directmap living within the
> GDT limit.
> * The IDT/GDT should exist at the same linear address on every pcpu to
> avoid leaking information  (This property is what allows the removal of
> the lgdt from the context switch path).
> * The critical datastructures should be mapped read only to make
> exploitation hardware for an attacker with a write-primative.
> * With the stack at the same linear address on each CPU, we don't need
> the syscall stubs, and the TSS is identical on all cpus.
> 
> In some copious free time, it would be nice to fix these issues.

As long as you can't solve the primary performance problem of your
approach for existing pv guests I don't see why above tuning attempts
would make any sense.

I know for sure there are users out there not capable to switch to HVM
or PVH guests because they need more than 64 vcpus per guest. So before
tackling above problems you really have to solve the large HVM guest
problem. And making it impossible for those users to continue using
PV guests by hitting performance so bad won't be an accepted "solution".


Juergen

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

Re: [Xen-devel] [PATCH v4 3/4] x86emul: Support vaes insns

[Jan Beulich]

>>> On 23.01.18 at 13:56,  wrote:
> I did below TEMP patch, please help me check whther this patch meet your 
> requirements, many thanks!

Looks reasonable at the first glance, provided you add a proper
fall-through annotation to the new fall-through.

Jan


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

Re: [Xen-devel] [PATCH RFC v2 00/12] xen/x86: use per-vcpu stacks for 64 bit pv domains

[Dario Faggioli]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey, Hi!

On Mon, 2018-01-22 at 18:39 +, Andrew Cooper wrote:
> > > > On 22.01.18 at 15:38,  wrote:
> > > I'm quite sure the performance will be much better as it doesn't
> > > require
> > > per physical cpu L4 page tables, but just a shadow L4 table for
> > > each
> > > guest L4 table, similar to the Linux kernel KPTI approach.
> > 
> Juergen: you're now adding a LTR into the context switch path which
> tends to be very slow.  I.e. As currently presented, this series
> necessarily has a higher runtime overhead than Jan's XPTI.
> 
So, as Juergen mentioned, I'm trying to do some performance evaluation
of these solutions.

This is just the first set of numbers, so consider it preliminary. In
particular, I'm sure there is a better set of benchmarks than the ones
I've used for now (in order to have something quickly)... I am looking
more into this.

Anyway, what I'm seeing for now is that Juergen's branch performs
pretty much as current staging, if booted with xpti=false (i.e., with
Jan's band-aid compiled but disabled).

OTOH, staging with xpti=true does show some performance impact. I
appreciate that this is still unfair a comparison (as Juergen's series
lacks the "real XPTI" bits), but the goal here was to figure out
whether the current status of the series is already introducing
regressions or not (and, as far as this first set of benches says, it's
not).

Anyway, here's the numbers. The benchmarks are run in a 16 vCPUs Debian
PV guest, on a 16 pCPUs (Intel Xeon-s) Debian host.

Raw numbers:
https://openbenchmarking.org/result/1801238-AL-1801232AL05

Normalized against "Staging xpti=false"
https://openbenchmarking.org/result/1801238-AL-1801232AL05&obr_nor=y&obr_hgv=4.11+Staging+xpti%3Dfalse

You'll have to forgive me about the labels (I'll pick better titles
next time). They're meaning is as follows:
- - "4.11 Staging xpti=false" this is current staging, booted with
  xpti=false (so, with Jan's band-aid applied, but disabled);
- - "staging-xpti-on" this is current staging, booted with xpti=true
  (so, with Jan's band-aid applied, but enabled);
- - "4.11 Juergen xpti" this is Juergen's GitHub branch, booted with
xpti=true.

I'll post more as soon as I will have it.
Dario
- -- 
<> (Raistlin Majere)
- -
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEES5ssOj3Vhr0WPnOLFkJ4iaW4c+4FAlpnN5sACgkQFkJ4iaW4
c+7p3RAAskP/vGfZMermn3iXh5tULiumjWb8olYN/X5bXEcR5HQCuWiK3p647LkA
p9Am1vgTxGSz7GpQJt45f1No0zS/oMcfEDvnV7aJ76sjSQqK/fIwVGec9qIJbgFB
TzvF4rGqiPnbXykq79ps6RFK3bN6PasV/4Yr1cqr0EJRtiYVe/F12UMER32AyOnd
XSCnHMI5yu4Zy6te0CsfxH96TlDoIGsvSKv86xMpc1m87l19yBFfRLUrVZL1Dmfc
zZwaR91IZdlR7N2xKCBgGbbnqRx4HmfNTN49Ih2ND/YISEyQdgNxZdOSxfRKpD2m
yMOzf7huJmUBiwQ+M/tJmC/bn8hVG1ZCwPbuMF5OItXWPnfA/SHBG++NM17LVGTa
tdQC12Gl2DNvQEOns6z9tfnRF/FqnQAnK7KJ1LACAWGmQSIBGCrO+sQlmy/uwRdX
wWpuH4qE7WDBhXtMbN/4b31ab7US4N/ZJcgz/uKgMr8/OUhjYUFSjUwR39gGeruN
b78s019rtEVOUEKNYngzb8FPJP89qnfcDj7sivMmgzq0FIB5VTXXhA4Idvgk6WPb
/RCfyO1SYgWOY0zKAV85lGCcuU7X8SVdTmAjlM7yNVh/WtfHCcah5GZQYBnse3tw
i61CmZpl2eVzzbfeSnA6lU7g9y8jOKkhmPaQ+8dxgV+mMv0Z/Lo=
=/v47
-END PGP SIGNATURE-


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

Re: [Xen-devel] [PATCH v2] libxc: don't fail domain creation when unpacking initrd fails

[Jan Beulich]

>>> On 23.01.18 at 11:55,  wrote:
> On Mon, Dec 04, 2017 at 05:46:41AM -0700, Jan Beulich wrote:
>> At least Linux kernels have been able to work with gzip-ed initrd for
>> quite some time; initrd compressed with other methods aren't even being
>> attempted to unpack. Furthermore the unzip-ing routine used here isn't
>> capable of dealing with various forms of concatenated files, each of
>> which was gzip-ed separately (it is this particular case which has been
>> the source of observed VM creation failures).
>> 
>> Hence, if unpacking fails, simply hand the the compressed blob to the
>> guest as is.
> 
> Sadly this will have to be rebased on top of staging,
> xc_dom_build_ramdisk was renamed to xc_dom_build_module.

That shouldn't be difficult to do, but makes little sense until I know
I don't need to make other changes. Note for how long the patch
has been pending.

>> @@ -1020,11 +1015,18 @@ static int xc_dom_build_ramdisk(struct x
>>  if ( unziplen )
>>  {
>>  if ( xc_dom_do_gunzip(dom->xch, dom->ramdisk_blob, 
>> dom->ramdisk_size,
>> -  ramdiskmap, ramdisklen) == -1 )
>> +  ramdiskmap, unziplen) != -1 )
>> +return 0;
>> +if ( dom->ramdisk_size > ramdisklen )
> 
> AFAICT this would mean that the non-gzipped ramdisk would be bigger
> than the gzipped one?

Yes (an at least theoretical possibility).

> The code LGTM.

Thanks, Jan


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

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

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 linuxa0ec1ded22e6a6bc41981fae22406835b006a66e
baseline version:
 linuxd517bb79f4994a87cfc2ddd4cc76bd1a627d4bed

Last test of basis   118250  2018-01-21 06:48:31 Z2 days
Failing since118263  2018-01-21 23:17:15 Z1 days3 attempts
Testing same since   118276  2018-01-23 01:58:02 Z0 days1 attempts


People who touched revisions under test:
  Andi Kleen 
  Dave Young 
  David Woodhouse 
  Keith Busch 
  Kirill A. Shutemov 
  Linus Torvalds 
  Martin Brandenburg 
  Masami Hiramatsu 
  Michal Hocko 
  Thomas Gleixner 
  Tom Lendacky 
  zhenwei.pi 

jobs:
 build-a

Re: [Xen-devel] [PATCH v4] x86: relocate pvh_info

[Jan Beulich]

>>> On 23.01.18 at 12:44,  wrote:
> On Tue, Jan 23, 2018 at 02:14:51AM -0700, Jan Beulich wrote:
>> >>> On 22.01.18 at 19:31,  wrote:
>> > On Mon, Jan 22, 2018 at 06:19:43PM +, Andrew Cooper wrote:
>> >> On 22/01/18 18:17, Wei Liu wrote:
>> >> > So you want reloc.o to contain pvh_info_reloc unconditionally?
>> >> >
>> >> > Fundamentally I don't think I care enough about all the bikeshedding so
>> >> > if Jan and you agree on this I will just make the change.
>> >> 
>> >> It wont.  The function will be dropped due to DCE, but we'll spot build
>> >> breakages far more easily.  (The important bit is that the function call
>> >> is guarded by the IS_ENABLED())
>> > 
>> > reloc.o will still have that function in non-PVH build on my machine.
>> > And that's with the following diff applied.
>> 
>> Well, DCE doesn't make any promises towards what it is able to
>> eliminate, which is why generally I prefer to help the compiler in
>> cases like the one here.
> 
> If I read this correctly, this means you prefer the ifdef CONFIG_PVH_GUEST
> version?

Well, in an ideal world I'd prefer what Andrew did suggest. If the
compiler turns out to be incapable of removing dead code
properly, I'd be slightly in favor of the #ifdef approach, but with
Andrew apparently strongly feeling the other way around, I
wouldn't mind that variant (the more that it's all .init.* contents).

Jan


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

Re: [Xen-devel] [PATCH v4 3/4] x86emul: Support vaes insns

[Yang Zhong]

On Thu, Jan 18, 2018 at 07:13:21AM -0700, Jan Beulich wrote:
> >>> On 03.01.18 at 09:26,  wrote:
> > The previous aes insns only support legacy and AVX128.
> > Icelake added AVX256 support.
> 
> Same remark here as for the pclmulqdq patch.
> 
> > Signed-off-by: Yang Zhong 
> > ---
> 
> Please provide a brief list of changes at this spot in each patch.
> 
> > @@ -7336,17 +7337,23 @@ x86_emulate(
> >  case X86EMUL_OPC_66(0x0f38, 0xdb): /* aesimc xmm/m128,xmm */
> >  case X86EMUL_OPC_VEX_66(0x0f38, 0xdb): /* vaesimc xmm/m128,xmm */
> >  case X86EMUL_OPC_66(0x0f38, 0xdc): /* aesenc xmm/m128,xmm,xmm */
> > -case X86EMUL_OPC_VEX_66(0x0f38, 0xdc): /* vaesenc xmm/m128,xmm,xmm */
> > +case X86EMUL_OPC_VEX_66(0x0f38, 0xdc): /* vaesenc 
> > {x,y}mm/mem,{x,y}mm,{x,y}mm */
> >  case X86EMUL_OPC_66(0x0f38, 0xdd): /* aesenclast xmm/m128,xmm,xmm 
> > */
> > -case X86EMUL_OPC_VEX_66(0x0f38, 0xdd): /* vaesenclast xmm/m128,xmm,xmm 
> > */
> > +case X86EMUL_OPC_VEX_66(0x0f38, 0xdd): /* vaesenclast 
> > {x,y}mm/mem,{x,y}mm,{x,y}mm */
> >  case X86EMUL_OPC_66(0x0f38, 0xde): /* aesdec xmm/m128,xmm,xmm */
> > -case X86EMUL_OPC_VEX_66(0x0f38, 0xde): /* vaesdec xmm/m128,xmm,xmm */
> > +case X86EMUL_OPC_VEX_66(0x0f38, 0xde): /* vaesdec 
> > {x,y}mm/mem,{x,y}mm,{x,y}mm */
> >  case X86EMUL_OPC_66(0x0f38, 0xdf): /* aesdeclast xmm/m128,xmm,xmm 
> > */
> > -case X86EMUL_OPC_VEX_66(0x0f38, 0xdf): /* vaesdeclast xmm/m128,xmm,xmm 
> > */
> > +case X86EMUL_OPC_VEX_66(0x0f38, 0xdf): /* vaesdeclast 
> > {x,y}mm/mem,{x,y}mm,{x,y}mm */
> > +if ( vex.l )
> > +{
> > +host_and_vcpu_must_have(vaes);
> > +goto simd_0f_ymm;
> > +}
> >  host_and_vcpu_must_have(aesni);
> >  if ( vex.opcx == vex_none )
> >  goto simd_0f38_common;
> > -/* fall through */
> > +goto simd_0f_avx;
> > +
> >  case X86EMUL_OPC_VEX_66(0x0f38, 0x41): /* vphminposuw xmm/m128,xmm,xmm 
> > */
> 
> Hmm, you've reacted to my v3 comments, but you didn't really address
> them: VAESIMC still is mishandled with the code above. Note that I didn't
> say "remove the fall-through", but instead "move out the block no longer
> wanting this fall-through".
> 
> Jan

Hello Jan,

I did below TEMP patch, please help me check whther this patch meet your 
requirements, many thanks!

I moved vaesimc insn before host_and_vcpu_must_have(aesni), this method
can make sure there is not any change for vaesimc. by the way, the fall
through still be kept for avx128.


+#define vcpu_has_vaes()vcpu_has( 7, ECX,  9, ctxt, ops)
 #define vcpu_has_vpclmulqdq()  vcpu_has( 7, ECX, 10, ctxt, ops)
 #define vcpu_has_rdpid()   vcpu_has( 7, ECX, 22, ctxt, ops)
 #define vcpu_has_clzero()  vcpu_has(0x8008, EBX,  0, ctxt, ops)
@@ -7334,15 +7335,20 @@ x86_emulate(
 goto simd_0f38_common;

 case X86EMUL_OPC_66(0x0f38, 0xdb): /* aesimc xmm/m128,xmm */
-case X86EMUL_OPC_VEX_66(0x0f38, 0xdb): /* vaesimc xmm/m128,xmm */
 case X86EMUL_OPC_66(0x0f38, 0xdc): /* aesenc xmm/m128,xmm,xmm */
-case X86EMUL_OPC_VEX_66(0x0f38, 0xdc): /* vaesenc xmm/m128,xmm,xmm */
+case X86EMUL_OPC_VEX_66(0x0f38, 0xdc): /* vaesenc 
{x,y}mm/mem,{x,y}mm,{x,y}mm */
 case X86EMUL_OPC_66(0x0f38, 0xdd): /* aesenclast xmm/m128,xmm,xmm */
-case X86EMUL_OPC_VEX_66(0x0f38, 0xdd): /* vaesenclast xmm/m128,xmm,xmm */
+case X86EMUL_OPC_VEX_66(0x0f38, 0xdd): /* vaesenclast 
{x,y}mm/mem,{x,y}mm,{x,y}mm */
 case X86EMUL_OPC_66(0x0f38, 0xde): /* aesdec xmm/m128,xmm,xmm */
-case X86EMUL_OPC_VEX_66(0x0f38, 0xde): /* vaesdec xmm/m128,xmm,xmm */
+case X86EMUL_OPC_VEX_66(0x0f38, 0xde): /* vaesdec 
{x,y}mm/mem,{x,y}mm,{x,y}mm */
 case X86EMUL_OPC_66(0x0f38, 0xdf): /* aesdeclast xmm/m128,xmm,xmm */
-case X86EMUL_OPC_VEX_66(0x0f38, 0xdf): /* vaesdeclast xmm/m128,xmm,xmm */
+case X86EMUL_OPC_VEX_66(0x0f38, 0xdf): /* vaesdeclast 
{x,y}mm/mem,{x,y}mm,{x,y}mm */
+if ( vex.l )
+{
+host_and_vcpu_must_have(vaes);
+goto simd_0f_ymm;
+}
+case X86EMUL_OPC_VEX_66(0x0f38, 0xdb): /* vaesimc xmm/m128,xmm */
 host_and_vcpu_must_have(aesni);
 if ( vex.opcx == vex_none )
 goto simd_0f38_common;


Regards,

Yang



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

[Xen-devel] [PATCH] x86/compat: fix compilation errors with clang 6

[Roger Pau Monne]

The following errors are generated when compiling Xen with clang 6:

In file included from x86_64/asm-offsets.c:9:
In file included from /root/src/xen/xen/include/xen/sched.h:8:
In file included from /root/src/xen/xen/include/xen/shared.h:6:
In file included from /root/src/xen/xen/include/compat/arch-x86/../xen.h:9:
/root/src/xen/xen/include/compat/arch-x86/xen.h:10:10: error: the current 
#pragma pack aligment
  value is modified in the included file [-Werror,-Wpragma-pack]
#include "xen-x86_32.h"
 ^
/root/src/xen/xen/include/compat/arch-x86/xen-x86_32.h:40:9: note: previous 
'#pragma pack'
  directive that modifies alignment is here
#pragma pack()
^
In file included from x86_64/asm-offsets.c:9:
In file included from /root/src/xen/xen/include/xen/sched.h:8:
In file included from /root/src/xen/xen/include/xen/shared.h:6:
/root/src/xen/xen/include/compat/arch-x86/../xen.h:9:10: error: the current 
#pragma pack aligment
  value is modified in the included file [-Werror,-Wpragma-pack]
#include "arch-x86/xen.h"
 ^
/root/src/xen/xen/include/compat/arch-x86/xen.h:71:9: note: previous '#pragma 
pack' directive that
  modifies alignment is here
#pragma pack()
^
2 errors generated.

Fix this by using pragma push/pop in order to store the current pragma
value in the compiler stack and later restoring it.

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/include/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/include/Makefile b/xen/include/Makefile
index 1299b1962f..bdf8dd4372 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -35,8 +35,8 @@ cppflags-y:= -include public/xen-compat.h 
-DXEN_GENERATING_COMPA
 cppflags-$(CONFIG_X86)+= -m32
 
 # 8-byte types are 4-byte aligned on x86_32 ...
-prefix-$(CONFIG_X86)  := \#pragma pack(4)
-suffix-$(CONFIG_X86)  := \#pragma pack()
+prefix-$(CONFIG_X86)  := \#pragma pack(push, 4)
+suffix-$(CONFIG_X86)  := \#pragma pack(pop)
 
 endif
 
-- 
2.15.1


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

Re: [Xen-devel] [RFC v4 2/8] xen/bitops: Rename LOG_2 to ilog2

[Julien Grall]

Hi Roger,

On 23/01/18 12:10, Roger Pau Monné wrote:

On Tue, Jan 23, 2018 at 11:44:30AM +, Julien Grall wrote:

Hi Roger,

On 23/01/18 11:39, Roger Pau Monné wrote:

On Mon, Dec 18, 2017 at 08:16:57PM -0700, Sameer Goel wrote:

diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
index e2019b02a3..a103e49089 100644
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -223,7 +223,7 @@ static inline __u32 ror32(__u32 word, unsigned int shift)
   #define __L4(_x)  (((_x) & 0x000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
   #define __L8(_x)  (((_x) & 0x00f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
   #define __L16(_x) (((_x) & 0xff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
-#define LOG_2(_x) (((_x) & 0x) ? (16 + __L16((_x)>>16)) : __L16(_x))
+#define ilog2(_x) (((_x) & 0x) ? (16 + __L16((_x)>>16)) : __L16(_x))


Er, why not add a:

#define ilog2 LOG_2

On the code that you have to import?


There is exactly on caller of LOG_2. So what is the benefits to provide 2
names? More that I would expect ilog2 to be used in any code coming from
Linux.


I don't think we should be renaming macros just because we want to
import verbatim code from Linux or anywhere else, I would rather add a
linuxkpi.h or similar in order to do the translation, but that's just
my opinion.


I would have agreed if there was 10-30 callsite in Xen code. For 1 
callsite it sounds like a bit overkill to request to have 2 different 
name. You can see this as renaming very similar to series that rename field.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC v4 2/8] xen/bitops: Rename LOG_2 to ilog2

[Roger Pau Monné]

On Tue, Jan 23, 2018 at 11:44:30AM +, Julien Grall wrote:
> Hi Roger,
> 
> On 23/01/18 11:39, Roger Pau Monné wrote:
> > On Mon, Dec 18, 2017 at 08:16:57PM -0700, Sameer Goel wrote:
> > > diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
> > > index e2019b02a3..a103e49089 100644
> > > --- a/xen/include/xen/bitops.h
> > > +++ b/xen/include/xen/bitops.h
> > > @@ -223,7 +223,7 @@ static inline __u32 ror32(__u32 word, unsigned int 
> > > shift)
> > >   #define __L4(_x)  (((_x) & 0x000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( 
> > > _x))
> > >   #define __L8(_x)  (((_x) & 0x00f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( 
> > > _x))
> > >   #define __L16(_x) (((_x) & 0xff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( 
> > > _x))
> > > -#define LOG_2(_x) (((_x) & 0x) ? (16 + __L16((_x)>>16)) : 
> > > __L16(_x))
> > > +#define ilog2(_x) (((_x) & 0x) ? (16 + __L16((_x)>>16)) : 
> > > __L16(_x))
> > 
> > Er, why not add a:
> > 
> > #define ilog2 LOG_2
> > 
> > On the code that you have to import?
> 
> There is exactly on caller of LOG_2. So what is the benefits to provide 2
> names? More that I would expect ilog2 to be used in any code coming from
> Linux.

I don't think we should be renaming macros just because we want to
import verbatim code from Linux or anywhere else, I would rather add a
linuxkpi.h or similar in order to do the translation, but that's just
my opinion.

Roger.

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

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

[Edgar E. Iglesias]

On Tue, Jan 23, 2018 at 01:52:50PM +0200, Oleksandr Tyshchenko wrote:
> Hi Mirela,
> 
> Just some remarks regarding the scope of work:
> 
> +In addition, the following have to be implemented:
> +* Suspend/resume vCPU (triggered by vSYSTEM_SUSPEND call)
> +* Suspend/resume Xen (triggered by vSYSTEM_SUSPEND called by Dom0), 
> including:
> +   * Disable wathdog on suspend, enable it on resume
> +   * Pause domains on suspend, unpause them on resume
> +   * Disable non-boot pCPUs on suspend, enable them on resume
> +   * Save/restore of GIC configuration
> +   * Suspend/resume timer
> +   * Save/restore of EL2 context
> +   * Implement resume entry point in Xen, including MMU configuration
> 
> I think that saving/restoring IOMMU registers/context should be
> implemented as well.

Yes, good point.
Mirela, I think that in the ZU+ case the IOMMU actually gets powered down
with the FPD.


> In other words, each involved platform device driver in Xen on ARM
> (IOMMU-XX, UART-XX, etc) should have suspend/resume callbacks
> implemented.

Yes agreed.

Best regards,
Edgar


> 
> -- 
> Regards,
> 
> Oleksandr Tyshchenko

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

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

[Oleksandr Tyshchenko]

Hi Mirela,

Just some remarks regarding the scope of work:

+In addition, the following have to be implemented:
+* Suspend/resume vCPU (triggered by vSYSTEM_SUSPEND call)
+* Suspend/resume Xen (triggered by vSYSTEM_SUSPEND called by Dom0), including:
+   * Disable wathdog on suspend, enable it on resume
+   * Pause domains on suspend, unpause them on resume
+   * Disable non-boot pCPUs on suspend, enable them on resume
+   * Save/restore of GIC configuration
+   * Suspend/resume timer
+   * Save/restore of EL2 context
+   * Implement resume entry point in Xen, including MMU configuration

I think that saving/restoring IOMMU registers/context should be
implemented as well.
In other words, each involved platform device driver in Xen on ARM
(IOMMU-XX, UART-XX, etc) should have suspend/resume callbacks
implemented.

-- 
Regards,

Oleksandr Tyshchenko

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

Re: [Xen-devel] [PATCH RFC v2 00/12] xen/x86: use per-vcpu stacks for 64 bit pv domains

[Andrew Cooper]

On 23/01/18 10:10, Juergen Gross wrote:
> On 23/01/18 10:31, Jan Beulich wrote:
> On 23.01.18 at 10:24,  wrote:
>>> On 23/01/18 09:53, Jan Beulich wrote:
>>> On 23.01.18 at 07:34,  wrote:
> On 22/01/18 19:39, Andrew Cooper wrote:
>> One of my concerns is that this patch series moves further away from the
>> secondary goal of my KAISER series, which was to have the IDT and GDT
>> mapped at the same linear addresses on every CPU so a) SIDT/SGDT don't
>> leak which CPU you're currently scheduled on into PV guests and b) the
>> context switch code can drop a load of its slow instructions like LGDT
>> and the VMWRITEs to update the VMCS.
> The GDT address of a PV vcpu is depending on vcpu_id only. I don't
> see why the IDT can't be mapped to the same address on each cpu with
> my approach.
 You're not introducing a per-CPU range in the page tables afaics
 (again from overview and titles only), yet with the IDT needing
 to be per-CPU you'd also need a per-CPU range to map it to if
 you want to avoid the LIDT as well as exposing what CPU you're
 on (same goes for the GDT and the respective avoidance of LGDT
 afaict).
>>> After a quick look I don't see why a Meltdown mitigation can't use
>>> the same IDT for all cpus: the only reason I could find for having
>>> per-cpu IDTs seems to be in SVM code, so it seems to be AMD specific.
>>> And AMD won't need XPTI at all.
>> Isn't your RFC series allowing XPTI to be enabled even on AMD?
> Yes, you are right. This might either want to be revisited or the
> address space to be activated for SVM domains could map an IDT with
> IST related traps removed.

I've experimented quite a lot in this area.  Ideally, we'd vmload/save
in the SVM critical region (like all other hypervisors) at which point
we don't need any adjustments to the IDT (as IST references are safe to
use), and we'd catch stack overflows in the #DF handler rather than
immediately triple faulting.

Using LIDT to switch between alternative IDTs, or INVLPG to swap the
mapping under a fixed linear address are both much slower than the
current implementation.

>
>>> The GDT of pv domains is already in the per-domain region even without
>>> my patches, so I don't have to change anything regarding usage of LGDT.
>> Andrew's point was that eliminating the LGDT is a secondary goal.
> With per-cpu mappings this is surely an obvious optimization. In the
> end the overall performance should be taken as base for a decision.
> His main point was avoiding exposing data like the physical cpu number
> and this doesn't apply here, as the GDT is per vcpu in my case.

The GDT leaks vcpu_id into guest userspace, which is similarly problematic.

The secondary goals of my KAISER series stand irrespective of the
Meltdown issues:
* The stack and mutable critical structures really should be numa-local
to the CPU using it.
* The GDT should sit fully fat over zeros.  At the moment in HVM
context, there are 14 frames of arbitrary directmap living within the
GDT limit.
* The IDT/GDT should exist at the same linear address on every pcpu to
avoid leaking information  (This property is what allows the removal of
the lgdt from the context switch path).
* The critical datastructures should be mapped read only to make
exploitation hardware for an attacker with a write-primative.
* With the stack at the same linear address on each CPU, we don't need
the syscall stubs, and the TSS is identical on all cpus.

In some copious free time, it would be nice to fix these issues.

~Andrew

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

Re: [Xen-devel] [RFC v4 2/8] xen/bitops: Rename LOG_2 to ilog2

[Julien Grall]

Hi Roger,

On 23/01/18 11:39, Roger Pau Monné wrote:

On Mon, Dec 18, 2017 at 08:16:57PM -0700, Sameer Goel wrote:

diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
index e2019b02a3..a103e49089 100644
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -223,7 +223,7 @@ static inline __u32 ror32(__u32 word, unsigned int shift)
  #define __L4(_x)  (((_x) & 0x000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
  #define __L8(_x)  (((_x) & 0x00f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
  #define __L16(_x) (((_x) & 0xff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
-#define LOG_2(_x) (((_x) & 0x) ? (16 + __L16((_x)>>16)) : __L16(_x))
+#define ilog2(_x) (((_x) & 0x) ? (16 + __L16((_x)>>16)) : __L16(_x))


Er, why not add a:

#define ilog2 LOG_2

On the code that you have to import?


There is exactly on caller of LOG_2. So what is the benefits to provide 
2 names? More that I would expect ilog2 to be used in any code coming 
from Linux.


Cheers,



Roger.

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



--
Julien Grall

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

Re: [Xen-devel] [PATCH v4] x86: relocate pvh_info

[Wei Liu]

On Tue, Jan 23, 2018 at 02:14:51AM -0700, Jan Beulich wrote:
> >>> On 22.01.18 at 19:31,  wrote:
> > On Mon, Jan 22, 2018 at 06:19:43PM +, Andrew Cooper wrote:
> >> On 22/01/18 18:17, Wei Liu wrote:
> >> > So you want reloc.o to contain pvh_info_reloc unconditionally?
> >> >
> >> > Fundamentally I don't think I care enough about all the bikeshedding so
> >> > if Jan and you agree on this I will just make the change.
> >> 
> >> It wont.  The function will be dropped due to DCE, but we'll spot build
> >> breakages far more easily.  (The important bit is that the function call
> >> is guarded by the IS_ENABLED())
> > 
> > reloc.o will still have that function in non-PVH build on my machine.
> > And that's with the following diff applied.
> 
> Well, DCE doesn't make any promises towards what it is able to
> eliminate, which is why generally I prefer to help the compiler in
> cases like the one here.
> 

If I read this correctly, this means you prefer the ifdef CONFIG_PVH_GUEST
version?

Wei.

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

Re: [Xen-devel] [RFC v4 4/8] passthrough/arm: Modify SMMU driver to use generic device definition

[Julien Grall]

Hi Sameer,

On 19/12/17 03:16, Sameer Goel wrote:

Modify the SMMU code to use generic device instead of dt_device_node for
functions that can be used for ACPI based systems too.

Signed-off-by: Sameer Goel 


Acked-by: Julien Grall 

Cheers,


---
  xen/drivers/passthrough/arm/smmu.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 45acb89380..ad956d5b8d 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -76,7 +76,7 @@ struct resource
  
  #define resource_size(res) (res)->size;
  
-#define platform_device dt_device_node

+#define platform_device device
  
  #define IORESOURCE_MEM 0

  #define IORESOURCE_IRQ 1
@@ -97,12 +97,12 @@ static struct resource *platform_get_resource(struct 
platform_device *pdev,
  
  	switch (type) {

case IORESOURCE_MEM:
-   ret = dt_device_get_address(pdev, num, &res.addr, &res.size);
+   ret = dt_device_get_address(dev_to_dt(pdev), num, &res.addr, 
&res.size);
  
  		return ((ret) ? NULL : &res);
  
  	case IORESOURCE_IRQ:

-   ret = platform_get_irq(pdev, num);
+   ret = platform_get_irq(dev_to_dt(pdev), num);
if (ret < 0)
return NULL;
  
@@ -2286,7 +2286,7 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)

const struct of_device_id *of_id;
struct resource *res;
struct arm_smmu_device *smmu;
-   struct device *dev = &pdev->dev;
+   struct device *dev = pdev;
struct rb_node *node;
struct of_phandle_args masterspec;
int num_irqs, i, err;
@@ -2339,7 +2339,7 @@ static int arm_smmu_device_dt_probe(struct 
platform_device *pdev)
}
  
  	for (i = 0; i < num_irqs; ++i) {

-   int irq = platform_get_irq(pdev, i);
+   int irq = platform_get_irq(dev_to_dt(pdev), i);
  
  		if (irq < 0) {

dev_err(dev, "failed to get irq index %d\n", i);
@@ -2820,7 +2820,7 @@ static __init int arm_smmu_dt_init(struct dt_device_node 
*dev,
 */
dt_device_set_used_by(dev, DOMID_XEN);
  
-	rc = arm_smmu_device_dt_probe(dev);

+   rc = arm_smmu_device_dt_probe(dt_to_dev(dev));
if (rc)
return rc;
  



--
Julien Grall

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

Re: [Xen-devel] [RFC v4 2/8] xen/bitops: Rename LOG_2 to ilog2

[Roger Pau Monné]

On Mon, Dec 18, 2017 at 08:16:57PM -0700, Sameer Goel wrote:
> diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
> index e2019b02a3..a103e49089 100644
> --- a/xen/include/xen/bitops.h
> +++ b/xen/include/xen/bitops.h
> @@ -223,7 +223,7 @@ static inline __u32 ror32(__u32 word, unsigned int shift)
>  #define __L4(_x)  (((_x) & 0x000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
>  #define __L8(_x)  (((_x) & 0x00f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
>  #define __L16(_x) (((_x) & 0xff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
> -#define LOG_2(_x) (((_x) & 0x) ? (16 + __L16((_x)>>16)) : __L16(_x))
> +#define ilog2(_x) (((_x) & 0x) ? (16 + __L16((_x)>>16)) : __L16(_x))

Er, why not add a:

#define ilog2 LOG_2

On the code that you have to import?

Roger.

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

Re: [Xen-devel] [RFC v4 2/8] xen/bitops: Rename LOG_2 to ilog2

[Julien Grall]

Hi Sameer,

On 19/12/17 03:16, Sameer Goel wrote:

Changing the name of the macro from LOG_2 to ilog2.This makes the function name
similar to its Linux counterpart. Since, this is not used in mutiple places, so 
the code churn is minimal.


s/mutiple/multiple/


This change helps in porting unchanged code from Linux.


Can you wrap the commit message correctly?

Cheers,



Signed-off-by: Sameer Goel 
---
  xen/arch/x86/x86_64/asm-offsets.c | 2 +-
  xen/include/xen/bitops.h  | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/x86_64/asm-offsets.c 
b/xen/arch/x86/x86_64/asm-offsets.c
index e136af6b99..4bccbc9bdf 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -157,7 +157,7 @@ void __dummy__(void)
  BLANK();
  #endif
  
-DEFINE(IRQSTAT_shift, LOG_2(sizeof(irq_cpustat_t)));

+DEFINE(IRQSTAT_shift, ilog2(sizeof(irq_cpustat_t)));
  OFFSET(IRQSTAT_softirq_pending, irq_cpustat_t, __softirq_pending);
  BLANK();
  
diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h

index e2019b02a3..a103e49089 100644
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -223,7 +223,7 @@ static inline __u32 ror32(__u32 word, unsigned int shift)
  #define __L4(_x)  (((_x) & 0x000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
  #define __L8(_x)  (((_x) & 0x00f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
  #define __L16(_x) (((_x) & 0xff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
-#define LOG_2(_x) (((_x) & 0x) ? (16 + __L16((_x)>>16)) : __L16(_x))
+#define ilog2(_x) (((_x) & 0x) ? (16 + __L16((_x)>>16)) : __L16(_x))
  
  /**

   * for_each_set_bit - iterate over every set bit in a memory region



--
Julien Grall

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

Re: [Xen-devel] [RFC v4 1/8] Port WARN_ON_ONCE() from Linux

[Julien Grall]

Hi Sameer,

On 19/12/17 03:16, Sameer Goel wrote:

Port WARN_ON_ONCE macro from Linux.

Signed-off-by: Sameer Goel 
---
  xen/include/xen/lib.h | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index ed00ae1379..83206c0848 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -11,6 +11,17 @@
  #define BUG_ON(p)  do { if (unlikely(p)) BUG();  } while (0)
  #define WARN_ON(p) do { if (unlikely(p)) WARN(); } while (0)
  
+#define WARN_ON_ONCE(p)	({  \

+static bool __section(".data.unlikely") __warned; \
+int __ret_warn_once = !!(p);\
+\
+if (unlikely(__ret_warn_once && !__warned)) {   \


I realise BUG_ON/WARN_ON above is not using Xen coding style. However, 
can you make this code follow Xen coding style?


FWIW with the coding style change:

Acked-by: Julien Grall 

This will also require an ack from "THE REST" maintainers as this is 
common code.


Cheers,


+__warned = true;\
+WARN_ON(1); \
+}   \
+unlikely(__ret_warn_once);  \
+})
+
  #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6)
  /* Force a compilation error if condition is true */
  #define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!(" #cond ")"); })



--
Julien Grall

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

Re: [Xen-devel] I only see one CPU core on Xen when booted via grub

[Daniel Kiper]

On Tue, Jan 23, 2018 at 03:09:19AM -0700, Jan Beulich wrote:
> >>> On 23.01.18 at 10:39,  wrote:
> >>  ... your report is very likely duplicating earlier ones where the
> >> ACPI root point cannot be found without it being properly
> >> propagated through by grub from EFI to Xen. Iirc the only
> >> way around that is to chainload xen.efi, if the grub used
> >> doesn't support the extensions needed to boot Xen via the
> >> multiboot2 protocol (support for which was added during the
> >> 4.9 development cycle).
> >
> > Thanks. So if I want to boot Xen through grub, I need Xen >= 4.9 and
> > which version of grub ?
>
> I'm afraid this isn't necessarily tied to a version number.
> Daniel?

Could you send me more info? I need at least GRUB2 version, Xen version,
GRUB2 command lines used to boot Xen, Xen and dom0 kernel boot logs.

Daniel

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

[Xen-devel] [xen-unstable-smoke test] 118282: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  4786f9f8f7dff445a3b078b24508fd9d2f211f48
baseline version:
 xen  a5e7ce9560b408dbdc2f7fb8a58f6209601cc054

Last test of basis   118274  2018-01-22 19:01:16 Z0 days
Testing same since   118282  2018-01-23 10:01:22 Z0 days1 attempts


People who touched revisions under test:
  Daniel Kiper 
  Jan Beulich 
  Juergen Gross 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   a5e7ce9560..4786f9f8f7  4786f9f8f7dff445a3b078b24508fd9d2f211f48 -> smoke

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

Re: [Xen-devel] [PATCH RFC v2 00/12] xen/x86: use per-vcpu stacks for 64 bit pv domains

[Andrew Cooper]

On 23/01/18 08:36, Jan Beulich wrote:
 On 22.01.18 at 20:02,  wrote:
>> On 22/01/18 18:48, George Dunlap wrote:
>>> On 01/22/2018 06:39 PM, Andrew Cooper wrote:
 Jan: As to the things not covered by the current XPTI, hiding most of
 the .text section is important to prevent fingerprinting or ROP
 scanning.  This is a defence-in-depth argument, but a guest being easily
 able to identify whether certain XSAs are fixed or not is quite bad. 
>>> I'm afraid we have a fairly different opinion of what is "quite bad".
>> I suggest you try talking to some real users then.
>>
>>> Suppose we handed users a knob and said, "If you flip this switch,
>>> attackers won't be able to tell if you've fixed XSAs or not without
>>> trying them; but it will slow down your guests 20%."  How many do you
>>> think would flip it, and how many would reckon that an attacker could
>>> probably find out that information anyway?
>> Nonsense.  The performance hit is already taken.  The argument is "do
>> you want an attacker able to trivially evaluate security weaknesses in
>> your hypervisor", a process which usually has to be done by guesswork
>> and knowing the exact binary under attack.  Having .text fully readable
>> lowers the barrier to entry substantially.
> I neither agree with George's reply being nonsense, nor do I think
> this is an appropriate tone. _Some_ performance hit is already
> taken. Further hiding of information my incur further loss of
> performance, or are you telling me you can guarantee this never
> ever to happen? Additionally, the amount of "guesswork" may
> heavily depend on the nature of a specific issue. I can imagine
> cases where such guesswork may even turn out easier than using
> some side channel approach like those recent ones.
>
> As indicated earlier, I'm not fundamentally opposed to hiding
> more things, but I'm also not convinced we should hide more stuff
> regardless of the price to pay.

Here is an example which comes with zero extra overhead.

Shuffle the virtual layout to put .text adjacent to MMCFG, and steal
some space (1G?) from the top of MMCFG for .entry.text and the per-cpu
stubs.  With some linker adjustments, relative jumps/references will
even work properly.

Anyone serious about security is not going to be happy with XPTI in its
current form, because being able to arbitrarily read .text is far too
valuable for an attacker.  Anyone serious about performance will turn
the whole lot off.

In some theoretical world with three options, only a fool would choose
the middle option, because a 10% hit is not going to be chosen lightly
in the first place, but there is no point taking the hit with the
reduced security.

~Andrew

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

[Xen-devel] [Xen EFI] Impossible to limit the dom0 memory

[msd+xen-de...@msd.im]

Hi,

I have configured Xen to boot directly from EFI (with `efibootmgr`).

As explained on the Xen_EFI wiki page, I have added a line "options=" 
into my file "/boot/efi/EFI/xen/xen.cfg" :


```
# cat /boot/efi/EFI/xen/xen.cfg :
[global]
default=xen

[xen]
options=dom0_mem=1G,max:1G
kernel=vmlinuz root=/dev/md2 ro rootdelay=10 noquiet nosplash
ramdisk=initrd.img
```

With the line `options=dom0_mem=1G,max:1G` the server reboot infinitely.
Without the line `options=dom0_mem=1G,max:1G`, the server boot 
correctly, but obviously, the dom0 memory is in ballooning mode.


I have attached a screen shot of the boot lines with the last lines I 
can see before the reboot. Unfortunately, I have nothing in kern.log.


1. Do you know what happens ?
2. Do you need some logs ?

Regards,


Guillaume

Links :
- 
https://wiki.xen.org/wiki/Xen_Project_Best_Practices#Xen_dom0_dedicated_memory_and_preventing_dom0_memory_ballooning

- https://xenbits.xen.org/docs/4.8-testing/misc/xen-command-line.html
- https://wiki.xen.org/wiki/Xen_EFI

```
# cat /proc/cpuinfo
model name  : Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz
microcode   : 0x5e
flags   : fpu de tsc msr pae mce cx8 apic sep mca cmov pat 
clflush acpi mmx fxsr sse sse2 ht syscall nx lm constant_tsc 
arch_perfmon rep_good nopl nonstop_tsc eagerfpu pni pclmulqdq monitor 
est ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand 
hypervisor lahf_lm abm 3dnowprefetch epb fsgsbase bmi1 hle avx2 bmi2 
erms rtm rdseed adx clflushopt xsaveopt xsavec xgetbv1 dtherm ida arat 
pln pts hwp hwp_notify hwp_act_window hwp_epp


# xl info
release: 4.9.0-5-amd64
version: #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04)
xen_version: 4.8.3-pre

# cat /etc/debian_version
9.3
```
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 for-next 3/9] gcov: rename sysctl and functions

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] [PATCH v2 for-next 3/9] gcov: rename 
sysctl and functions"):
> On 09.11.17 at 12:13,  wrote:
> > Change gcov to cov (for internal interfaces) or coverage (for the
> > public ones).
...
> Btw., I still have this (and subsequent patches in the series) on my
> list of things wanting to be committed, but this needs a tools
> maintainer's ack before it can go in.

Thanks for the implied ping.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH RFC v2 00/12] xen/x86: use per-vcpu stacks for 64 bit pv domains

[George Dunlap]

On 01/22/2018 07:02 PM, Andrew Cooper wrote:
> On 22/01/18 18:48, George Dunlap wrote:
>> On 01/22/2018 06:39 PM, Andrew Cooper wrote:
>>> On 22/01/18 16:51, Jan Beulich wrote:
>>> On 22.01.18 at 16:00,  wrote:
> On 22/01/18 15:48, Jan Beulich wrote:
> On 22.01.18 at 15:38,  wrote:
>>> On 22/01/18 15:22, Jan Beulich wrote:
>>> On 22.01.18 at 15:18,  wrote:
> On 22/01/18 13:50, Jan Beulich wrote:
> On 22.01.18 at 13:32,  wrote:
>>> As a preparation for doing page table isolation in the Xen 
>>> hypervisor
>>> in order to mitigate "Meltdown" use dedicated stacks, GDT and TSS 
>>> for
>>> 64 bit PV domains mapped to the per-domain virtual area.
>>>
>>> The per-vcpu stacks are used for early interrupt handling only. 
>>> After
>>> saving the domain's registers stacks are switched back to the normal
>>> per physical cpu ones in order to be able to address on-stack data
>>> from other cpus e.g. while handling IPIs.
>>>
>>> Adding %cr3 switching between saving of the registers and switching
>>> the stacks will enable the possibility to run guest code without any
>>> per physical cpu mapping, i.e. avoiding the threat of a guest being
>>> able to access other domains data.
>>>
>>> Without any further measures it will still be possible for e.g. a
>>> guest's user program to read stack data of another vcpu of the same
>>> domain, but this can be easily avoided by a little PV-ABI 
>>> modification
>>> introducing per-cpu user address spaces.
>>>
>>> This series is meant as a replacement for Andrew's patch series:
>>> "x86: Prerequisite work for a Xen KAISER solution".
>> Considering in particular the two reverts, what I'm missing here
>> is a clear description of the meaningful additional protection this
>> approach provides over the band-aid. For context see also
>> https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg01735.html
>>  
> My approach supports mapping only the following data while the guest 
> is
> running (apart form the guest's own data, of course):
>
> - the per-vcpu entry stacks of the domain which will contain only the
>   guest's registers saved when an interrupt occurs
> - the per-vcpu GDTs and TSSs of the domain
> - the IDT
> - the interrupt handler code (arch/x86/x86_64/[compat/]entry.S
>
> All other hypervisor data and code can be completely hidden from the
> guests.
 I understand that. What I'm not clear about is: Which parts of
 the additionally hidden data are actually necessary (or at least
 very desirable) to hide?
>>> Necessary:
>>> - other guests' memory (e.g. physical memory 1:1 mapping)
>>> - data from other guests e.g.in stack pages, debug buffers, I/O buffers,
>>>   code emulator buffers
>>> - other guests' register values e.g. in vcpu structure
>> All of this is already being made invisible by the band-aid (with the
>> exception of leftovers on the hypervisor stacks across context
>> switches, which we've already said could be taken care of by
>> memset()ing that area). I'm asking about the _additional_ benefits
>> of your approach.
> I'm quite sure the performance will be much better as it doesn't require
> per physical cpu L4 page tables, but just a shadow L4 table for each
> guest L4 table, similar to the Linux kernel KPTI approach.
 But isn't that model having the same synchronization issues upon
 guest L4 updates which Andrew was fighting with?
>>> (Condensing a lot of threads down into one)
>>>
>>> All the methods have L4 synchronisation update issues, until we have a
>>> PV ABI which guarantees that L4's don't get reused.  Any improvements to
>>> the shadowing/synchronisation algorithm will benefit all approaches.
>>>
>>> Juergen: you're now adding a LTR into the context switch path which
>>> tends to be very slow.  I.e. As currently presented, this series
>>> necessarily has a higher runtime overhead than Jan's XPTI.
>>>
>>> One of my concerns is that this patch series moves further away from the
>>> secondary goal of my KAISER series, which was to have the IDT and GDT
>>> mapped at the same linear addresses on every CPU so a) SIDT/SGDT don't
>>> leak which CPU you're currently scheduled on into PV guests and b) the
>>> context switch code can drop a load of its slow instructions like LGDT
>>> and the VMWRITEs to update the VMCS.
>>>
>>> Jan: As to the things not covered by the current XPTI, hiding most of
>>> the .text section is important to prevent fingerprinting or ROP
>>> scanning.  This is a defence-in-depth argument, but a guest being easily
>>> able to identify whether certain XSAs are fixed or no

Re: [Xen-devel] [PATCH v2 1/3] replace vCPU's dirty CPU mask by numeric ID

[Julien Grall]

Hi Jan,

On 23/01/18 10:12, Jan Beulich wrote:

At most one bit can be set in the masks, so especially on larger systems
it's quite a bit of unnecessary memory and processing overhead to track
the information as a mask. Store the numeric ID of the respective CPU
instead, or VCPU_CPU_CLEAN if no dirty state exists.

Signed-off-by: Jan Beulich 


Reviewed-by: Julien Grall 

Cheers,


---
ARM adjustments compile tested only.
---
v2: Introduce VCPU_CPU_CLEAN and vcpu_cpu_dirty(). Re-word comments.
 Re-base.

--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -330,7 +330,7 @@ void context_switch(struct vcpu *prev, s
  {
  ASSERT(local_irq_is_enabled());
  ASSERT(prev != next);
-ASSERT(cpumask_empty(next->vcpu_dirty_cpumask));
+ASSERT(!vcpu_cpu_dirty(next));
  
  if ( prev != next )

  update_runstate_area(prev);
@@ -471,7 +471,7 @@ void startup_cpu_idle_loop(void)
  ASSERT(is_idle_vcpu(v));
  /* TODO
 cpumask_set_cpu(v->processor, v->domain->domain_dirty_cpumask);
-   cpumask_set_cpu(v->processor, v->vcpu_dirty_cpumask);
+   v->dirty_cpu = v->processor;
  */
  
  reset_stack_and_jump(idle_loop);

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -146,7 +146,7 @@ void startup_cpu_idle_loop(void)
  
  ASSERT(is_idle_vcpu(v));

  cpumask_set_cpu(v->processor, v->domain->domain_dirty_cpumask);
-cpumask_set_cpu(v->processor, v->vcpu_dirty_cpumask);
+v->dirty_cpu = v->processor;
  
  reset_stack_and_jump(idle_loop);

  }
@@ -1602,7 +1602,7 @@ static void __context_switch(void)
  struct desc_ptr   gdt_desc;
  
  ASSERT(p != n);

-ASSERT(cpumask_empty(n->vcpu_dirty_cpumask));
+ASSERT(!vcpu_cpu_dirty(n));
  
  if ( !is_idle_domain(pd) )

  {
@@ -1618,7 +1618,7 @@ static void __context_switch(void)
   */
  if ( pd != nd )
  cpumask_set_cpu(cpu, nd->domain_dirty_cpumask);
-cpumask_set_cpu(cpu, n->vcpu_dirty_cpumask);
+n->dirty_cpu = cpu;
  
  if ( !is_idle_domain(nd) )

  {
@@ -1674,7 +1674,7 @@ static void __context_switch(void)
  
  if ( pd != nd )

  cpumask_clear_cpu(cpu, pd->domain_dirty_cpumask);
-cpumask_clear_cpu(cpu, p->vcpu_dirty_cpumask);
+p->dirty_cpu = VCPU_CPU_CLEAN;
  
  per_cpu(curr_vcpu, cpu) = n;

  }
@@ -1684,20 +1684,16 @@ void context_switch(struct vcpu *prev, s
  {
  unsigned int cpu = smp_processor_id();
  const struct domain *prevd = prev->domain, *nextd = next->domain;
-cpumask_t dirty_mask;
+unsigned int dirty_cpu = next->dirty_cpu;
  
  ASSERT(local_irq_is_enabled());
  
  get_cpu_info()->xen_cr3 = 0;
  
-cpumask_copy(&dirty_mask, next->vcpu_dirty_cpumask);

-/* Allow at most one CPU at a time to be dirty. */
-ASSERT(cpumask_weight(&dirty_mask) <= 1);
-if ( unlikely(!cpumask_test_cpu(cpu, &dirty_mask) &&
-  !cpumask_empty(&dirty_mask)) )
+if ( unlikely(dirty_cpu != cpu) && dirty_cpu != VCPU_CPU_CLEAN )
  {
-/* Other cpus call __sync_local_execstate from flush ipi handler. */
-flush_mask(&dirty_mask, FLUSH_TLB | FLUSH_VCPU_STATE);
+/* Remote CPU calls __sync_local_execstate() from flush IPI handler. */
+flush_mask(cpumask_of(dirty_cpu), FLUSH_TLB | FLUSH_VCPU_STATE);
  }
  
  if ( prev != next )

@@ -1802,11 +1798,14 @@ void sync_local_execstate(void)
  
  void sync_vcpu_execstate(struct vcpu *v)

  {
-if ( cpumask_test_cpu(smp_processor_id(), v->vcpu_dirty_cpumask) )
+if ( v->dirty_cpu == smp_processor_id() )
  sync_local_execstate();
  
-/* Other cpus call __sync_local_execstate from flush ipi handler. */

-flush_mask(v->vcpu_dirty_cpumask, FLUSH_TLB | FLUSH_VCPU_STATE);
+if ( vcpu_cpu_dirty(v) )
+{
+/* Remote CPU calls __sync_local_execstate() from flush IPI handler. */
+flush_mask(cpumask_of(v->dirty_cpu), FLUSH_TLB | FLUSH_VCPU_STATE);
+}
  }
  
  static int relinquish_memory(

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1212,7 +1212,7 @@ void put_page_from_l1e(l1_pgentry_t l1e,
  for_each_vcpu ( pg_owner, v )
  {
  if ( pv_destroy_ldt(v) )
-flush_tlb_mask(v->vcpu_dirty_cpumask);
+flush_tlb_mask(cpumask_of(v->dirty_cpu));
  }
  }
  put_page(page);
@@ -2937,8 +2937,8 @@ static inline int vcpumask_to_pcpumask(
  vcpu_id += vcpu_bias;
  if ( (vcpu_id >= d->max_vcpus) )
  return 0;
-if ( ((v = d->vcpu[vcpu_id]) != NULL) )
-cpumask_or(pmask, pmask, v->vcpu_dirty_cpumask);
+if ( ((v = d->vcpu[vcpu_id]) != NULL) && vcpu_cpu_dirty(v) )
+__cpumask_set_cpu(v->dirty_cpu, pmask);
  }
  }
  }
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -135,6 +135,7 @@ struct vcpu *alloc_vcpu(
  
  v->domain = d;

  v->vcpu_id = vcpu_id;
+v->d

Re: [Xen-devel] [PATCH v2 3/3] drop "domain_" prefix from struct domain's dirty CPU mask

[Julien Grall]

Hi Jan,

On 23/01/18 10:16, Jan Beulich wrote:

It being a field of struct domain is sufficient to recognize its
purpose.

Signed-off-by: Jan Beulich 
Reviewed-by: Wei Liu 
Reviewed-by: George Dunlap 
Reviewed-by: Andrew Cooper 

Acked-by: Julien Grall 

Cheers,


---
v2: White space changes (consolidate split line statements into single
 line ones). Re-base.

--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -470,7 +470,7 @@ void startup_cpu_idle_loop(void)
  
  ASSERT(is_idle_vcpu(v));

  /* TODO
-   cpumask_set_cpu(v->processor, v->domain->domain_dirty_cpumask);
+   cpumask_set_cpu(v->processor, v->domain->dirty_cpumask);
 v->dirty_cpu = v->processor;
  */
  
--- a/xen/arch/x86/domain.c

+++ b/xen/arch/x86/domain.c
@@ -145,7 +145,7 @@ void startup_cpu_idle_loop(void)
  struct vcpu *v = current;
  
  ASSERT(is_idle_vcpu(v));

-cpumask_set_cpu(v->processor, v->domain->domain_dirty_cpumask);
+cpumask_set_cpu(v->processor, v->domain->dirty_cpumask);
  v->dirty_cpu = v->processor;
  
  reset_stack_and_jump(idle_loop);

@@ -1617,7 +1617,7 @@ static void __context_switch(void)
   * which is synchronised on that function.
   */
  if ( pd != nd )
-cpumask_set_cpu(cpu, nd->domain_dirty_cpumask);
+cpumask_set_cpu(cpu, nd->dirty_cpumask);
  n->dirty_cpu = cpu;
  
  if ( !is_idle_domain(nd) )

@@ -1673,7 +1673,7 @@ static void __context_switch(void)
  }
  
  if ( pd != nd )

-cpumask_clear_cpu(cpu, pd->domain_dirty_cpumask);
+cpumask_clear_cpu(cpu, pd->dirty_cpumask);
  p->dirty_cpu = VCPU_CPU_CLEAN;
  
  per_cpu(curr_vcpu, cpu) = n;

@@ -1922,7 +1922,7 @@ int domain_relinquish_resources(struct d
  int ret;
  struct vcpu *v;
  
-BUG_ON(!cpumask_empty(d->domain_dirty_cpumask));

+BUG_ON(!cpumask_empty(d->dirty_cpumask));
  
  switch ( d->arch.relmem )

  {
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4045,7 +4045,7 @@ static int hvmop_flush_tlb_all(void)
  paging_update_cr3(v);
  
  /* Flush all dirty TLBs. */

-flush_tlb_mask(d->domain_dirty_cpumask);
+flush_tlb_mask(d->dirty_cpumask);
  
  /* Done. */

  for_each_vcpu ( d, v )
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2322,7 +2322,7 @@ static int svm_is_erratum_383(struct cpu
  wrmsrl(MSR_IA32_MCG_STATUS, msr_content & ~(1ULL << 2));
  
  /* flush TLB */

-flush_tlb_mask(v->domain->domain_dirty_cpumask);
+flush_tlb_mask(v->domain->dirty_cpumask);
  
  return 1;

  }
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2546,7 +2546,7 @@ static int _get_page_type(struct page_in
  cpumask_t *mask = this_cpu(scratch_cpumask);
  
  BUG_ON(in_irq());

-cpumask_copy(mask, d->domain_dirty_cpumask);
+cpumask_copy(mask, d->dirty_cpumask);
  
  /* Don't flush if the timestamp is old enough */

  tlbflush_filter(mask, page->tlbflush_timestamp);
@@ -3277,7 +3277,7 @@ long do_mmuext_op(
  
  case MMUEXT_TLB_FLUSH_ALL:

  if ( likely(currd == pg_owner) )
-flush_tlb_mask(currd->domain_dirty_cpumask);
+flush_tlb_mask(currd->dirty_cpumask);
  else
  rc = -EPERM;
  break;
@@ -3286,8 +3286,7 @@ long do_mmuext_op(
  if ( unlikely(currd != pg_owner) )
  rc = -EPERM;
  else if ( __addr_ok(op.arg1.linear_addr) )
-flush_tlb_one_mask(currd->domain_dirty_cpumask,
-   op.arg1.linear_addr);
+flush_tlb_one_mask(currd->dirty_cpumask, op.arg1.linear_addr);
  break;
  
  case MMUEXT_FLUSH_CACHE:

@@ -3772,7 +3771,7 @@ long do_mmu_update(
  unsigned int cpu = smp_processor_id();
  cpumask_t *mask = per_cpu(scratch_cpumask, cpu);
  
-cpumask_andnot(mask, pt_owner->domain_dirty_cpumask, cpumask_of(cpu));

+cpumask_andnot(mask, pt_owner->dirty_cpumask, cpumask_of(cpu));
  if ( !cpumask_empty(mask) )
  flush_area_mask(mask, ZERO_BLOCK_PTR, FLUSH_VA_VALID);
  }
@@ -3955,7 +3954,7 @@ static int __do_update_va_mapping(
  flush_tlb_local();
  break;
  case UVMF_ALL:
-mask = d->domain_dirty_cpumask;
+mask = d->dirty_cpumask;
  break;
  default:
  mask = this_cpu(scratch_cpumask);
@@ -3975,7 +3974,7 @@ static int __do_update_va_mapping(
  paging_invlpg(v, va);
  break;
  case UVMF_ALL:
-mask = d->domain_dirty_cpumask;
+mask = d->dirty_cpumask;
  break;
  default:
  mask = this_cpu(scratch_cpumask);
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -124,7 +124,7 @@ int hap_track_dirty_vram(struct domain *

Re: [Xen-devel] [PATCH v2] libxc: don't fail domain creation when unpacking initrd fails

[Roger Pau Monné]

On Mon, Dec 04, 2017 at 05:46:41AM -0700, Jan Beulich wrote:
> At least Linux kernels have been able to work with gzip-ed initrd for
> quite some time; initrd compressed with other methods aren't even being
> attempted to unpack. Furthermore the unzip-ing routine used here isn't
> capable of dealing with various forms of concatenated files, each of
> which was gzip-ed separately (it is this particular case which has been
> the source of observed VM creation failures).
> 
> Hence, if unpacking fails, simply hand the the compressed blob to the
> guest as is.

Sadly this will have to be rebased on top of staging,
xc_dom_build_ramdisk was renamed to xc_dom_build_module.

> Signed-off-by: Jan Beulich 
> ---
> v2: Almost full re-work, hopefully better meeting Ian's taste.
> 
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -291,7 +291,6 @@ int xc_dom_mem_init(struct xc_dom_image
>  int xc_dom_kernel_check_size(struct xc_dom_image *dom, size_t sz);
>  int xc_dom_kernel_max_size(struct xc_dom_image *dom, size_t sz);
>  
> -int xc_dom_ramdisk_check_size(struct xc_dom_image *dom, size_t sz);
>  int xc_dom_ramdisk_max_size(struct xc_dom_image *dom, size_t sz);
>  
>  int xc_dom_devicetree_max_size(struct xc_dom_image *dom, size_t sz);
> --- a/tools/libxc/xc_dom_core.c
> +++ b/tools/libxc/xc_dom_core.c
> @@ -314,22 +314,6 @@ int xc_dom_kernel_check_size(struct xc_d
>  return 0;
>  }
>  
> -int xc_dom_ramdisk_check_size(struct xc_dom_image *dom, size_t sz)
> -{
> -/* No limit */
> -if ( !dom->max_ramdisk_size )
> -return 0;
> -
> -if ( sz > dom->max_ramdisk_size )
> -{
> -xc_dom_panic(dom->xch, XC_INVALID_KERNEL,
> - "ramdisk image too large");
> -return 1;
> -}
> -
> -return 0;
> -}
> -
>  /*  
> */
>  /* read files, copy memory blocks, with transparent gunzip  
> */
>  
> @@ -996,16 +980,27 @@ static int xc_dom_build_ramdisk(struct x
>  void *ramdiskmap;
>  
>  if ( !dom->ramdisk_seg.vstart )
> -{
>  unziplen = xc_dom_check_gzip(dom->xch,
>   dom->ramdisk_blob, dom->ramdisk_size);
> -if ( xc_dom_ramdisk_check_size(dom, unziplen) != 0 )
> -unziplen = 0;
> -}
>  else
>  unziplen = 0;
>  
> -ramdisklen = unziplen ? unziplen : dom->ramdisk_size;
> +ramdisklen = max(unziplen, dom->ramdisk_size);
> +if ( dom->max_ramdisk_size )
> +{
> +if ( unziplen && ramdisklen > dom->max_ramdisk_size )
> +{
> +ramdisklen = min(unziplen, dom->ramdisk_size);
> +if ( unziplen > ramdisklen)
 ^ missing space

> +unziplen = 0;
> +}
> +if ( ramdisklen > dom->max_ramdisk_size )
> +{
> +xc_dom_panic(dom->xch, XC_INVALID_KERNEL,
> + "ramdisk image too large");
> +goto err;
> +}
> +}
>  
>  if ( xc_dom_alloc_segment(dom, &dom->ramdisk_seg, "ramdisk",
>dom->ramdisk_seg.vstart, ramdisklen) != 0 )
> @@ -1020,11 +1015,18 @@ static int xc_dom_build_ramdisk(struct x
>  if ( unziplen )
>  {
>  if ( xc_dom_do_gunzip(dom->xch, dom->ramdisk_blob, dom->ramdisk_size,
> -  ramdiskmap, ramdisklen) == -1 )
> +  ramdiskmap, unziplen) != -1 )
> +return 0;
> +if ( dom->ramdisk_size > ramdisklen )

AFAICT this would mean that the non-gzipped ramdisk would be bigger
than the gzipped one?

The code LGTM.

Thanks, Roger.

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

Re: [Xen-devel] PVH backports to 4.9 and 4.8

[George Dunlap]

On 01/23/2018 04:06 AM, Simon Gaiser wrote:
> George Dunlap:
>> Part of our solution to XSA-254 SP3 (aka "Meltdown") is to backport
>> the PVH mode from 4.10 to 4.9 and 4.8.  This will first allow people
>> able to run PVH kernels to switch their PV guests directly to PVH
>> guests; and second, eventually enable the backport of patches which
>> will enable transparent changing of PV guests into PVH guests.
>>
>> All of the hypervisor support seems to have existed already in 4.8, so
>> the only backports involve toolstack patches.
>>
>> I've put up two trees for a first-cut backport of the PVH
>> functionality, to 4.9 and 4.8 here:
>>
>> git://xenbits.xen.org/people/gdunlap/xen.git
>>
>> Branches out/pvh-backport/4.8/v1 and out/pvh-backport/4.9/v1
>>
>> Below are the patches backported from 4.10 to 4.9 (23 patches total):
> [...]
> 
> So future 4.8 releases will include the backports, right? Asking because
> the AFAICS the 4.8.3-pre-shim-comet branch include them but staging-4.8
> does not.

Some of us have had informal conversations about backporting PVH and
Comet host/toolstack patches to 4.8, and a number of us think it's a
good idea, but we haven't had an official discussion with all the
stakeholders yet.  We'll come back to it once more of the fires have
been put out.

Feel free to remind us in a month or so if you still haven't seen any
patches in the stable-4.8 branch. :-)

 -George

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

Re: [Xen-devel] [PATCH v7 for-next 12/12] vpci/msix: add MSI-X handlers

[Roger Pau Monné]

On Wed, Dec 20, 2017 at 09:13:34AM -0700, Jan Beulich wrote:
> >>> On 18.10.17 at 13:40,  wrote:
> > +if ( new_enabled && !new_masked && (!msix->enabled || msix->masked) )
> > +{
> > +for ( i = 0; i < msix->max_entries; i++ )
> > +{
> > +if ( msix->entries[i].masked || !msix->entries[i].updated )
> > +continue;
> > +
> > +rc = vpci_msix_arch_disable_entry(&msix->entries[i], pdev);
> > +/* Ignore ENOENT, it means the entry wasn't setup. */
> > +if ( rc && rc != -ENOENT )
> > +{
> > +gprintk(XENLOG_WARNING,
> > +"%04x:%02x:%02x.%u: unable to disable entry %u: 
> > %d\n",
> > +pdev->seg, pdev->bus, slot, func, i, rc);
> 
> In a log from e.g. a customer, how am I to tell this message from ...

I've replaced this message with:

"%04x:%02x:%02x.%u: unable to disable entry %u for update: %d\n"

> > +return;
> > +}
> > +
> > +rc = vpci_msix_arch_enable_entry(&msix->entries[i], pdev,
> > + VMSIX_TABLE_BASE(pdev->vpci,
> > +  
> > VPCI_MSIX_TABLE));
> > +if ( rc )
> > +{
> > +gprintk(XENLOG_WARNING,
> > +"%04x:%02x:%02x.%u: unable to enable entry %u: 
> > %d\n",
> > +pdev->seg, pdev->bus, slot, func, i, rc);
> > +/* Entry is likely not properly configured, skip it. */
> > +continue;
> > +}
> > +
> > +/*
> > + * At this point the PIRQ is still masked. Unmask it, or else 
> > the
> > + * guest won't receive interrupts. This is due to the
> > + * disable/enable sequence performed above.
> > + */
> > +vpci_msix_arch_mask_entry(&msix->entries[i], pdev, false);
> > +
> > +msix->entries[i].updated = false;
> > +}
> > +}
> > +else if ( !new_enabled && msix->enabled )
> > +{
> > +/* Guest has disabled MSIX, disable all entries. */
> > +for ( i = 0; i < msix->max_entries; i++ )
> > +{
> > +/*
> > + * NB: vpci_msix_arch_disable can be called for entries that 
> > are
> > + * not setup, it will return -ENOENT in that case.
> > + */
> > +rc = vpci_msix_arch_disable_entry(&msix->entries[i], pdev);
> > +switch ( rc )
> > +{
> > +case 0:
> > +/*
> > + * Mark the entry successfully disabled as updated, so 
> > that on
> > + * the next enable the entry is properly setup. This is 
> > done
> > + * so that the following flow works correctly:
> > + *
> > + * mask entry -> disable MSIX -> enable MSIX -> unmask 
> > entry
> > + *
> > + * Without setting 'updated', the 'unmask entry' step will 
> > fail
> > + * because the entry has not been updated, so it would not 
> > be
> > + * mapped/bound at all.
> > + */
> > +msix->entries[i].updated = true;
> > +break;
> > +case -ENOENT:
> > +/* Ignore non-present entry. */
> > +break;
> > +default:
> > +gprintk(XENLOG_WARNING,
> > +"%04x:%02x:%02x.%u: unable to disable entry %u: 
> > %d\n",
> > +pdev->seg, pdev->bus, slot, func, i, rc);
> 
> ... this one?

So that it doesn't crash with this one.

Thanks, Roger.

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