Re: [Xen-devel] [xen-unstable test] 103540: regressions - FAIL
>>> On 18.12.16 at 11:47, wrote: > On 18/12/2016 10:38, Andrew Cooper wrote: >> On 18/12/2016 05:21, osstest service owner wrote: >>> flight 103540 xen-unstable real [real] >>> http://logs.test-lab.xenproject.org/osstest/logs/103540/ >>> >>> Regressions :-( >>> >>> Tests which did not succeed and are blocking, >>> including tests which could not be run: >>> test-amd64-amd64-i386-pvgrub 6 xen-boot fail REGR. vs. > 103466 >>> test-xtf-amd64-amd64-36 xen-boot fail REGR. vs. > 103466 >>> test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-bootfail REGR. vs. > 103466 >>> test-amd64-amd64-xl-qemuu-win7-amd64 6 xen-boot fail REGR. vs. > 103466 >>> test-armhf-armhf-libvirt-raw 4 host-ping-check-native fail REGR. vs. > 103466 >>> test-xtf-amd64-amd64-56 xen-boot fail REGR. vs. > 103466 >>> test-xtf-amd64-amd64-46 xen-boot fail REGR. vs. > 103466 >>> test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-boot fail REGR. vs. > 103466 >>> test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. > vs. 103466 >>> test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. > vs. 103466 >> > http://logs.test-lab.xenproject.org/osstest/logs/103540/test-xtf-amd64-amd64- > 3/serial-merlot0.log >> from 22:48:30.821939 >> >> (XEN) [ Xen-4.9-unstable x86_64 debug=y Not tainted ] >> (XEN) CPU:0 >> (XEN) RIP:e008:[] __bitmap_and+0x24/0x33 >> (XEN) RFLAGS: 00010202 CONTEXT: hypervisor >> (XEN) rax: rbx: 82d08030fd58 rcx: 0001 >> (XEN) rdx: 82d0802edda0 rsi: 83023ffd1ef0 rdi: >> (XEN) rbp: 82d08030fd18 rsp: 82d08030fd18 r8: 0004 >> (XEN) r9: 82d080323a48 r10: r11: >> (XEN) r12: 0028 r13: 83023ffd1ef0 r14: >> (XEN) r15: 82d080343aa0 cr0: 8005003b cr4: 000406e0 >> (XEN) cr3: bdaff000 cr2: >> (XEN) ds: es: fs: gs: ss: cs: e008 >> (XEN) Xen code around (__bitmap_and+0x24/0x33): >> (XEN) 48 8b 0c c2 48 23 0c c6 <48> 89 0c c7 48 83 c0 01 41 39 c0 7f eb >> 5d c3 55 >> (XEN) Xen stack trace from rsp=82d08030fd18: >> (XEN)82d08030fd48 82d0801719cc 83023e203800 83023e384030 >> (XEN)82d08030fd58 82d08030fd88 82d080171bbc >> (XEN) 82d08030fd88 83023e384010 >> (XEN)82d080329b70 0038 82d08030fdc8 82d0802afb8b >> (XEN)c000 ffed 82d08030 >> (XEN) 82d080343aa0 82d08030fdd8 82d0802b00d7 >> (XEN)82d08030fdf8 82d0802ac9cb 82d080343aa0 83023fff5fe0 >> (XEN)82d08030ff08 82d0802c0ff2 0010 >> (XEN)01ff 0001 0001 0001 >> (XEN)0001 0001 0001 0001 >> (XEN) 011f3000 0043efff 00800163 >> (XEN)f001 00043ee0 0002 8308dd80 >> (XEN)8308def0 8308dfb0 >> (XEN)0008 0001006e 0003 02f8 >> (XEN) >> (XEN) 82d080100073 >> (XEN) >> (XEN) >> (XEN) >> (XEN) >> (XEN) Xen call trace: >> (XEN)[] __bitmap_and+0x24/0x33 >> (XEN)[] msi_compose_msg+0x7e/0xf5 >> (XEN)[] __setup_msi_irq+0x2f/0x5c >> (XEN)[] amd_iommu_init+0x460/0x6b7 >> (XEN)[] amd_iov_detect+0x69/0xad >> (XEN)[] iommu_setup+0x61/0x1c1 >> (XEN)[] __start_xen+0x23a8/0x2878 >> (XEN)[] __high_start+0x53/0x55 >> (XEN) >> (XEN) Pagetable walk from : >> (XEN) L4[0x000] = 00023fff3063 >> (XEN) L3[0x000] = 00023fff2063 >> (XEN) L2[0x000] = 00023fff1063 >> (XEN) L1[0x000] = >> (XEN) >> (XEN) >> (XEN) Panic on CPU 0: >> (XEN) FATAL PAGE FAULT >> (XEN) [error_code=0002] >> (XEN) Faulting linear address: >> (XEN) >> (XEN) >> (XEN) Reboot in five seconds... >> >> This will be caused by 7f885a1f49a75c770360b030666a5c1545156e5c or >> 3b6172645880f6324d0394d0d707f5d76b69ae1f > > Yes. 15aa6
Re: [Xen-devel] [PATCH 3/7] xen/Rules.mk: fix build with CFLAGS from environment
>>> On 16.12.16 at 23:56, wrote: > From: "Yann E. MORIN" > > When CFLAGS are passed from the environment, But that's what shouldn't be done. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 103744: trouble: broken/pass
flight 103744 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/103744/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 3 host-install(3) broken REGR. vs. 103742 version targeted for testing: ovmf d2fc7711136a13ea3ea8e00de6d9651507b8ed50 baseline version: ovmf a35dc6499beb0b76c340379a06dff74a8d38095a Last test of basis 103742 2016-12-19 01:16:04 Z0 days Testing same since 103744 2016-12-19 04:23:56 Z0 days1 attempts People who touched revisions under test: Dandan Bi Jiewen Yao Michael Kinney jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 broken test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-step test-amd64-amd64-xl-qemuu-ovmf-amd64 host-install(3) Not pushing. commit d2fc7711136a13ea3ea8e00de6d9651507b8ed50 Author: Jiewen Yao Date: Thu Nov 24 13:36:56 2016 +0800 UefiCpuPkg/PiSmmCpu: Add SMM Comm Buffer Paging Protection. This patch sets the normal OS buffer EfiLoaderCode/Data, EfiBootServicesCode/Data, EfiConventionalMemory, EfiACPIReclaimMemory to be not present after SmmReadyToLock. To access these region in OS runtime phase is not a good solution. Previously, we did similar check in SmmMemLib to help SMI handler do the check. But if SMI handler forgets the check, it can still access these OS region and bring risk. So here we enforce the policy to prevent it happening. Cc: Jeff Fan Cc: Michael D Kinney Cc: Laszlo Ersek Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao Reviewed-by: Jeff Fan commit 09119a00cccaa08b28b7e2449998ba4c7aa4b0f8 Author: Michael Kinney Date: Tue Nov 29 06:36:51 2016 +0800 UefiCpuPkg/SmmCpuFeaturesLibStm: Add STM library instance Add a new instances of the SmmCpuFeaturesLib that is used by platforms to enable the SMI Transfer Monitor(STM) feature. This new instance is in the same directory as the default SmmCpuFeaturesLib instance in order to share source files. The DSC file is updated to build both SmmCpuFeatureLib instances and to build two versions of the PiSmmCpuDxeSmm module using each of the SmmCpuFeatureLib instances. Cc: Jiewen Yao Cc: Jeff Fan Cc: Feng Tian Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney Reviewed-by: Jiewen Yao Reviewed-by: Jeff Fan commit 4c6351db25eaf24335933ce3499258d7b48a57b2 Author: Michael Kinney Date: Thu Nov 17 20:54:19 2016 -0800 UefiCpuPkg/SmmCpuFeaturesLib: Split into two files Split the default implementation of the SmmCpuFeaturesLib into two files to prepare for the addition of the STM specific SmmCpuFeaturesLib implementation. The STM specific implementation installs a different SMI entry handler and initialize the MSEG specific MSR at the end of SmmCpuFeaturesInitializeProcessor(). This patch does not introduce any functional changes to the default implementation of the SmmCpuFeaturesLib. Cc: Jiewen Yao Cc: Jeff Fan Cc: Feng Tian Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney Reviewed-by: Jiewen Yao Reviewed-by: Jeff Fan commit f7c11c534ccd9b8a8299d0870507507b205365e0 Author: Michael Kinney Date: Mon Nov 28 13:52:57 2016 -0800 UefiCpuPkg: Add STM GUIDs, Protocols, and PCDs * Add GUIDed HOB that described MSEG region in SMRAM * Add SM Monitor Init Protocol *
[Xen-devel] [PATCH] x86/SMP: CPU0's scratch mask is needed earlier
When putting together commit 3b61726458 ("x86: introduce and use
scratch CPU mask") I failed to remember that AMD IOMMU setups needs the
scratch mask prior to smp_prepare_cpus() having run. Use a static mask
for the boot CPU instead.
Note that the definition of scratch_cpu0mask could also be put inside a
"NR_CPUS > 2 * BITS_PER_LONG" conditional, but it seems preferable to
me to carry the extra variable in all cases and avoid the #ifdef-ary.
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
I'm not particularly happy about the remaining #ifdef, but I don't see
a way to avoid it.
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -57,6 +57,7 @@ DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t
DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, scratch_cpumask);
+static cpumask_t scratch_cpu0mask;
cpumask_t cpu_online_map __read_mostly;
EXPORT_SYMBOL(cpu_online_map);
@@ -648,7 +649,8 @@ static void cpu_smpboot_free(unsigned in
free_cpumask_var(per_cpu(cpu_sibling_mask, cpu));
free_cpumask_var(per_cpu(cpu_core_mask, cpu));
-free_cpumask_var(per_cpu(scratch_cpumask, cpu));
+if ( per_cpu(scratch_cpumask, cpu) != &scratch_cpu0mask )
+free_cpumask_var(per_cpu(scratch_cpumask, cpu));
if ( per_cpu(stubs.addr, cpu) )
{
@@ -795,8 +797,7 @@ void __init smp_prepare_cpus(unsigned in
panic("No memory for socket CPU siblings map");
if ( !zalloc_cpumask_var(&per_cpu(cpu_sibling_mask, 0)) ||
- !zalloc_cpumask_var(&per_cpu(cpu_core_mask, 0)) ||
- !alloc_cpumask_var(&per_cpu(scratch_cpumask, 0)) )
+ !zalloc_cpumask_var(&per_cpu(cpu_core_mask, 0)) )
panic("No memory for boot CPU sibling/core maps");
set_cpu_sibling_map(0);
@@ -850,8 +851,13 @@ void __init smp_prepare_cpus(unsigned in
void __init smp_prepare_boot_cpu(void)
{
-cpumask_set_cpu(smp_processor_id(), &cpu_online_map);
-cpumask_set_cpu(smp_processor_id(), &cpu_present_map);
+unsigned int cpu = smp_processor_id();
+
+cpumask_set_cpu(cpu, &cpu_online_map);
+cpumask_set_cpu(cpu, &cpu_present_map);
+#if NR_CPUS > 2 * BITS_PER_LONG
+per_cpu(scratch_cpumask, cpu) = &scratch_cpu0mask;
+#endif
}
static void
x86/SMP: CPU0's scratch mask is needed earlier
When putting together commit 3b61726458 ("x86: introduce and use
scratch CPU mask") I failed to remember that AMD IOMMU setups needs the
scratch mask prior to smp_prepare_cpus() having run. Use a static mask
for the boot CPU instead.
Note that the definition of scratch_cpu0mask could also be put inside a
"NR_CPUS > 2 * BITS_PER_LONG" conditional, but it seems preferable to
me to carry the extra variable in all cases and avoid the #ifdef-ary.
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
I'm not particularly happy about the remaining #ifdef, but I don't see
a way to avoid it.
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -57,6 +57,7 @@ DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t
DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, scratch_cpumask);
+static cpumask_t scratch_cpu0mask;
cpumask_t cpu_online_map __read_mostly;
EXPORT_SYMBOL(cpu_online_map);
@@ -648,7 +649,8 @@ static void cpu_smpboot_free(unsigned in
free_cpumask_var(per_cpu(cpu_sibling_mask, cpu));
free_cpumask_var(per_cpu(cpu_core_mask, cpu));
-free_cpumask_var(per_cpu(scratch_cpumask, cpu));
+if ( per_cpu(scratch_cpumask, cpu) != &scratch_cpu0mask )
+free_cpumask_var(per_cpu(scratch_cpumask, cpu));
if ( per_cpu(stubs.addr, cpu) )
{
@@ -795,8 +797,7 @@ void __init smp_prepare_cpus(unsigned in
panic("No memory for socket CPU siblings map");
if ( !zalloc_cpumask_var(&per_cpu(cpu_sibling_mask, 0)) ||
- !zalloc_cpumask_var(&per_cpu(cpu_core_mask, 0)) ||
- !alloc_cpumask_var(&per_cpu(scratch_cpumask, 0)) )
+ !zalloc_cpumask_var(&per_cpu(cpu_core_mask, 0)) )
panic("No memory for boot CPU sibling/core maps");
set_cpu_sibling_map(0);
@@ -850,8 +851,13 @@ void __init smp_prepare_cpus(unsigned in
void __init smp_prepare_boot_cpu(void)
{
-cpumask_set_cpu(smp_processor_id(), &cpu_online_map);
-cpumask_set_cpu(smp_processor_id(), &cpu_present_map);
+unsigned int cpu = smp_processor_id();
+
+cpumask_set_cpu(cpu, &cpu_online_map);
+cpumask_set_cpu(cpu, &cpu_present_map);
+#if NR_CPUS > 2 * BITS_PER_LONG
+per_cpu(scratch_cpumask, cpu) = &scratch_cpu0mask;
+#endif
}
static void
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/emul: Don't opencode CR0_TS in CLTS handling
Also replace implicit 0 checks with X86EMUL_OKAY Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/x86_emulate/x86_emulate.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c index f69dece..f8188ee 100644 --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -4684,8 +4684,8 @@ x86_emulate( case X86EMUL_OPC(0x0f, 0x06): /* clts */ generate_exception_if(!mode_ring0(), EXC_GP, 0); fail_if((ops->read_cr == NULL) || (ops->write_cr == NULL)); -if ( (rc = ops->read_cr(0, &dst.val, ctxt)) || - (rc = ops->write_cr(0, dst.val&~8, ctxt)) ) +if ( (rc = ops->read_cr(0, &dst.val, ctxt)) != X86EMUL_OKAY || + (rc = ops->write_cr(0, dst.val & ~CR0_TS, ctxt)) != X86EMUL_OKAY ) goto done; break; -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen: ARM: Support for mapping ECAM PCIe Config Space Specified In Static ACPI Table
Hi, On 16/12/2016 15:49, Julien Grall wrote: On 14/12/16 08:00, Jiandi An wrote: Xen currently doesn't map ECAM space specified in static ACPI table. Seeking opinion on how this should be handled properly. Each root complex ECAM region takes up 64K 4K pages (256MB). For some platforms there might be multiple root complexes. Is the plan to map all at once?Julien has mentioned support for mapping ECAM may come when support for PCI passthrough is added, is that right? What mechanism will it be? Will Xen or dom0 be the one that parses the staic ACPI tables and map the ECAM space? For performance reason, each ECAM region would need to be mapped at once, so the stage-2 page table could take advantage of superpage (it will mostly be 2MB). Now, I don't think Xen should map the ECAM region in stage-2 before hand. All the regions may not be described in the MCFG and I would like to see a generic solution. Looking at the code (see pci_create_ecam_create in drivers/pci/ecam.c), ioremap is used. I believe the problem is the same for the 2 other threads you sent ( [1] and [2]). So it might be good to look at hooking up a call to XENMEM_add_to_physmap_range in ioremap. Any opinions? I thought a bit more about it and I realized we need to be cautious on how to proceed here. DOM0 will have a mix of real devices and emulated devices (e.g some part of the GIC). For the emulated devices, DOM0 should not call XENMEM_add_to_physmap_range. However, DOM0 is not aware what is emulated or not, so even the current approach (hooking up in platform device) seems fragile. We rely on Xen to say "this region cannot be mapped". Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/SMP: CPU0's scratch mask is needed earlier
On 19/12/16 09:45, Jan Beulich wrote:
> When putting together commit 3b61726458 ("x86: introduce and use
> scratch CPU mask") I failed to remember that AMD IOMMU setups needs the
> scratch mask prior to smp_prepare_cpus() having run. Use a static mask
> for the boot CPU instead.
>
> Note that the definition of scratch_cpu0mask could also be put inside a
> "NR_CPUS > 2 * BITS_PER_LONG" conditional, but it seems preferable to
> me to carry the extra variable in all cases and avoid the #ifdef-ary.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Jan Beulich
> ---
> I'm not particularly happy about the remaining #ifdef, but I don't see
> a way to avoid it.
Nor me.
Reviewed-by: Andrew Cooper
Lets unblock staging while considering if there is a better way of doing
this.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 07/11] docs: move vtpm from misc to man
On Wed, 2016-12-14 at 16:08 -0500, Daniel De Graaf wrote: > On 12/09/2016 11:17 AM, Cédric Bosdonnat wrote: > > vtpm.txt is referenced in xl.cfg man page. Convert it to pod, > > move it to the man folder and update the reference. > > > > Signed-off-by: Cédric Bosdonnat > > Since this manpage only describes Xen's vTPM implementation, and > Xen is not the only vTPM that exists in Linux (there's a Linux > kernel "vtpm_proxy" interface and another ibmvtpm module), I think > it needs be named something like "xen-vtpm". The same applies to > patch 8 (vtpmmgr) as that manpage (and software) is Xen-specific. I just changed the names locally. I'll resubmit after having gathered a few more comments. Thanks for your review. -- Cedric > The POD sources look correct, though I have not compiled & looked > at the resulting manpages. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [tip:x86/urgent] x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels
Commit-ID: 1c52d859cb2d417e7216d3e56bb7fea88444cec9
Gitweb: http://git.kernel.org/tip/1c52d859cb2d417e7216d3e56bb7fea88444cec9
Author: Andy Lutomirski
AuthorDate: Fri, 9 Dec 2016 10:24:05 -0800
Committer: Thomas Gleixner
CommitDate: Mon, 19 Dec 2016 11:54:20 +0100
x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels
We support various non-Intel CPUs that don't have the CPUID
instruction, so the M486 test was wrong. For now, fix it with a big
hammer: handle missing CPUID on all 32-bit CPUs.
Reported-by: One Thousand Gnomes
Signed-off-by: Andy Lutomirski
Cc: Juergen Gross
Cc: Peter Zijlstra
Cc: Brian Gerst
Cc: Matthew Whitehead
Cc: Borislav Petkov
Cc: Henrique de Moraes Holschuh
Cc: Andrew Cooper
Cc: Boris Ostrovsky
Cc: xen-devel
Link:
http://lkml.kernel.org/r/685bd083a7c036f7769510b6846315b17d6ba71f.1481307769.git.l...@kernel.org
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/processor.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 6aa741f..b934871 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -607,7 +607,7 @@ static inline void sync_core(void)
{
int tmp;
-#ifdef CONFIG_M486
+#ifdef CONFIG_X86_32
/*
* Do a CPUID if available, otherwise do a jump. The jump
* can conveniently enough be the jump around CPUID.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [tip:x86/urgent] Revert "x86/boot: Fail the boot if !M486 and CPUID is missing"
Commit-ID: 426d1aff3138cf38da14e912df3c75e312f96e9e
Gitweb: http://git.kernel.org/tip/426d1aff3138cf38da14e912df3c75e312f96e9e
Author: Andy Lutomirski
AuthorDate: Fri, 9 Dec 2016 10:24:06 -0800
Committer: Thomas Gleixner
CommitDate: Mon, 19 Dec 2016 11:54:20 +0100
Revert "x86/boot: Fail the boot if !M486 and CPUID is missing"
This reverts commit ed68d7e9b9cfb64f3045ffbcb108df03c09a0f98.
The patch wasn't quite correct -- there are non-Intel (and hence
non-486) CPUs that we support that don't have CPUID. Since we no
longer require CPUID for sync_core(), just revert the patch.
I think the relevant CPUs are Geode and Elan, but I'm not sure.
In principle, we should try to do better at identifying CPUID-less
CPUs in early boot, but that's more complicated.
Reported-by: One Thousand Gnomes
Signed-off-by: Andy Lutomirski
Cc: Juergen Gross
Cc: Denys Vlasenko
Cc: Peter Zijlstra
Cc: Brian Gerst
Cc: Josh Poimboeuf
Cc: Matthew Whitehead
Cc: Borislav Petkov
Cc: Henrique de Moraes Holschuh
Cc: Andrew Cooper
Cc: Boris Ostrovsky
Cc: xen-devel
Cc: Linus Torvalds
Link:
http://lkml.kernel.org/r/82acde18a108b8e353180dd6febcc2876df33f24.1481307769.git.l...@kernel.org
Signed-off-by: Thomas Gleixner
---
arch/x86/boot/cpu.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/x86/boot/cpu.c b/arch/x86/boot/cpu.c
index 4224ede..26240dd 100644
--- a/arch/x86/boot/cpu.c
+++ b/arch/x86/boot/cpu.c
@@ -87,12 +87,6 @@ int validate_cpu(void)
return -1;
}
- if (CONFIG_X86_MINIMUM_CPU_FAMILY <= 4 && !IS_ENABLED(CONFIG_M486) &&
- !has_eflag(X86_EFLAGS_ID)) {
- printf("This kernel requires a CPU with the CPUID instruction.
Build with CONFIG_M486=y to run on this CPU.\n");
- return -1;
- }
-
if (err_flags) {
puts("This kernel requires the following features "
"not present on the CPU:\n");
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [tip:x86/urgent] x86/asm: Rewrite sync_core() to use IRET-to-self
Commit-ID: c198b121b1a1d7a7171770c634cd49191bac4477
Gitweb: http://git.kernel.org/tip/c198b121b1a1d7a7171770c634cd49191bac4477
Author: Andy Lutomirski
AuthorDate: Fri, 9 Dec 2016 10:24:08 -0800
Committer: Thomas Gleixner
CommitDate: Mon, 19 Dec 2016 11:54:21 +0100
x86/asm: Rewrite sync_core() to use IRET-to-self
Aside from being excessively slow, CPUID is problematic: Linux runs
on a handful of CPUs that don't have CPUID. Use IRET-to-self
instead. IRET-to-self works everywhere, so it makes testing easy.
For reference, On my laptop, IRET-to-self is ~110ns,
CPUID(eax=1, ecx=0) is ~83ns on native and very very slow under KVM,
and MOV-to-CR2 is ~42ns.
While we're at it: sync_core() serves a very specific purpose.
Document it.
Signed-off-by: Andy Lutomirski
Cc: Juergen Gross
Cc: One Thousand Gnomes
Cc: Peter Zijlstra
Cc: Brian Gerst
Cc: Matthew Whitehead
Cc: Borislav Petkov
Cc: Henrique de Moraes Holschuh
Cc: Andrew Cooper
Cc: Boris Ostrovsky
Cc: xen-devel
Link:
http://lkml.kernel.org/r/5c79f0225f68bc8c40335612bf624511abb78941.1481307769.git.l...@kernel.org
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/processor.h | 80 +---
1 file changed, 58 insertions(+), 22 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index b934871..eaf1005 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -602,33 +602,69 @@ static __always_inline void cpu_relax(void)
rep_nop();
}
-/* Stop speculative execution and prefetching of modified code. */
+/*
+ * This function forces the icache and prefetched instruction stream to
+ * catch up with reality in two very specific cases:
+ *
+ * a) Text was modified using one virtual address and is about to be executed
+ * from the same physical page at a different virtual address.
+ *
+ * b) Text was modified on a different CPU, may subsequently be
+ * executed on this CPU, and you want to make sure the new version
+ * gets executed. This generally means you're calling this in a IPI.
+ *
+ * If you're calling this for a different reason, you're probably doing
+ * it wrong.
+ */
static inline void sync_core(void)
{
- int tmp;
-
-#ifdef CONFIG_X86_32
/*
-* Do a CPUID if available, otherwise do a jump. The jump
-* can conveniently enough be the jump around CPUID.
+* There are quite a few ways to do this. IRET-to-self is nice
+* because it works on every CPU, at any CPL (so it's compatible
+* with paravirtualization), and it never exits to a hypervisor.
+* The only down sides are that it's a bit slow (it seems to be
+* a bit more than 2x slower than the fastest options) and that
+* it unmasks NMIs. The "push %cs" is needed because, in
+* paravirtual environments, __KERNEL_CS may not be a valid CS
+* value when we do IRET directly.
+*
+* In case NMI unmasking or performance ever becomes a problem,
+* the next best option appears to be MOV-to-CR2 and an
+* unconditional jump. That sequence also works on all CPUs,
+* but it will fault at CPL3 (i.e. Xen PV and lguest).
+*
+* CPUID is the conventional way, but it's nasty: it doesn't
+* exist on some 486-like CPUs, and it usually exits to a
+* hypervisor.
+*
+* Like all of Linux's memory ordering operations, this is a
+* compiler barrier as well.
*/
- asm volatile("cmpl %2,%1\n\t"
-"jl 1f\n\t"
-"cpuid\n"
-"1:"
-: "=a" (tmp)
-: "rm" (boot_cpu_data.cpuid_level), "ri" (0), "0" (1)
-: "ebx", "ecx", "edx", "memory");
+ register void *__sp asm(_ASM_SP);
+
+#ifdef CONFIG_X86_32
+ asm volatile (
+ "pushfl\n\t"
+ "pushl %%cs\n\t"
+ "pushl $1f\n\t"
+ "iret\n\t"
+ "1:"
+ : "+r" (__sp) : : "memory");
#else
- /*
-* CPUID is a barrier to speculative execution.
-* Prefetched instructions are automatically
-* invalidated when modified.
-*/
- asm volatile("cpuid"
-: "=a" (tmp)
-: "0" (1)
-: "ebx", "ecx", "edx", "memory");
+ unsigned int tmp;
+
+ asm volatile (
+ "mov %%ss, %0\n\t"
+ "pushq %q0\n\t"
+ "pushq %%rsp\n\t"
+ "addq $8, (%%rsp)\n\t"
+ "pushfq\n\t"
+ "mov %%cs, %0\n\t"
+ "pushq %q0\n\t"
+ "pushq $1f\n\t"
+ "iretq\n\t"
+ "1:"
+ : "=&r" (tmp), "+r" (__sp) : : "cc", "memory");
#endif
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists
[Xen-devel] [tip:x86/urgent] x86/microcode/intel: Replace sync_core() with native_cpuid()
Commit-ID: 484d0e5c7943644cc46e7308a8f9d83be598f2b9
Gitweb: http://git.kernel.org/tip/484d0e5c7943644cc46e7308a8f9d83be598f2b9
Author: Andy Lutomirski
AuthorDate: Fri, 9 Dec 2016 10:24:07 -0800
Committer: Thomas Gleixner
CommitDate: Mon, 19 Dec 2016 11:54:21 +0100
x86/microcode/intel: Replace sync_core() with native_cpuid()
The Intel microcode driver is using sync_core() to mean "do CPUID
with EAX=1". I want to rework sync_core(), but first the Intel
microcode driver needs to stop depending on its current behavior.
Reported-by: Henrique de Moraes Holschuh
Signed-off-by: Andy Lutomirski
Acked-by: Borislav Petkov
Cc: Juergen Gross
Cc: One Thousand Gnomes
Cc: Peter Zijlstra
Cc: Brian Gerst
Cc: Matthew Whitehead
Cc: Andrew Cooper
Cc: Boris Ostrovsky
Cc: xen-devel
Link:
http://lkml.kernel.org/r/535a025bb91fed1a019c5412b036337ad239e5bb.1481307769.git.l...@kernel.org
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/microcode/intel.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/intel.c
b/arch/x86/kernel/cpu/microcode/intel.c
index 54d50c3..b624b54 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -368,6 +368,26 @@ next:
return patch;
}
+static void cpuid_1(void)
+{
+ /*
+* According to the Intel SDM, Volume 3, 9.11.7:
+*
+* CPUID returns a value in a model specific register in
+* addition to its usual register return values. The
+* semantics of CPUID cause it to deposit an update ID value
+* in the 64-bit model-specific register at address 08BH
+* (IA32_BIOS_SIGN_ID). If no update is present in the
+* processor, the value in the MSR remains unmodified.
+*
+* Use native_cpuid -- this code runs very early and we don't
+* want to mess with paravirt.
+*/
+ unsigned int eax = 1, ebx, ecx = 0, edx;
+
+ native_cpuid(&eax, &ebx, &ecx, &edx);
+}
+
static int collect_cpu_info_early(struct ucode_cpu_info *uci)
{
unsigned int val[2];
@@ -393,7 +413,7 @@ static int collect_cpu_info_early(struct ucode_cpu_info
*uci)
native_wrmsrl(MSR_IA32_UCODE_REV, 0);
/* As documented in the SDM: Do a CPUID 1 here */
- sync_core();
+ cpuid_1();
/* get the current revision from MSR 0x8B */
native_rdmsr(MSR_IA32_UCODE_REV, val[0], val[1]);
@@ -593,7 +613,7 @@ static int apply_microcode_early(struct ucode_cpu_info
*uci, bool early)
native_wrmsrl(MSR_IA32_UCODE_REV, 0);
/* As documented in the SDM: Do a CPUID 1 here */
- sync_core();
+ cpuid_1();
/* get the current revision from MSR 0x8B */
native_rdmsr(MSR_IA32_UCODE_REV, val[0], val[1]);
@@ -805,7 +825,7 @@ static int apply_microcode_intel(int cpu)
wrmsrl(MSR_IA32_UCODE_REV, 0);
/* As documented in the SDM: Do a CPUID 1 here */
- sync_core();
+ cpuid_1();
/* get the current revision from MSR 0x8B */
rdmsr(MSR_IA32_UCODE_REV, val[0], val[1]);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/emul: Don't opencode CR0_TS in CLTS handling
>>> On 19.12.16 at 11:22, wrote: > Also replace implicit 0 checks with X86EMUL_OKAY > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 103741: regressions - trouble: broken/fail/pass
flight 103741 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/103741/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-36 xen-boot fail REGR. vs. 103466 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. vs. 103466 test-amd64-amd64-i386-pvgrub 6 xen-boot fail in 103659 REGR. vs. 103466 test-amd64-amd64-xl-qemuu-win7-amd64 6 xen-boot fail in 103659 REGR. vs. 103466 test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail in 103659 REGR. vs. 103466 test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-boot fail in 103659 REGR. vs. 103466 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail in 103659 REGR. vs. 103466 Tests which are failing intermittently (not blocking): test-xtf-amd64-amd64-43 host-install(3) broken pass in 103659 test-amd64-amd64-xl-qemut-debianhvm-amd64 3 host-install(3) broken pass in 103659 test-amd64-amd64-xl-rtds 3 host-install(3) broken pass in 103659 test-amd64-amd64-i386-pvgrub 3 host-install(3) broken pass in 103659 test-amd64-amd64-xl-qemuu-win7-amd64 3 host-install(3) broken pass in 103659 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken pass in 103737 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3)broken pass in 103737 test-amd64-amd64-xl 3 host-install(3) broken pass in 103737 test-amd64-amd64-xl-xsm 3 host-install(3) broken pass in 103737 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken pass in 103737 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken pass in 103737 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken pass in 103737 test-xtf-amd64-amd64-46 xen-boot fail in 103540 pass in 103659 test-armhf-armhf-libvirt-raw 4 host-ping-check-native fail in 103540 pass in 103741 test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-boot fail in 103659 pass in 103540 test-amd64-amd64-xl 6 xen-boot fail in 103659 pass in 103540 test-amd64-amd64-xl-xsm 6 xen-boot fail in 103659 pass in 103540 test-xtf-amd64-amd64-56 xen-boot fail in 103659 pass in 103741 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 11 saverestore-support-check fail in 103659 pass in 103741 test-armhf-armhf-xl-vhd 9 debian-di-install fail in 103659 pass in 103741 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail in 103737 pass in 103659 test-amd64-i386-qemuu-rhel6hvm-amd 6 xen-boot fail in 103737 pass in 103659 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail pass in 103659 test-armhf-armhf-libvirt 6 xen-boot fail pass in 103737 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 17 guest-start/win.repeat fail pass in 103737 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 11 guest-start fail in 103540 like 103466 test-amd64-amd64-xl-rtds 6 xen-boot fail in 103659 REGR. vs. 103466 test-armhf-armhf-libvirt 13 saverestore-support-check fail in 103659 like 103466 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 103737 like 103394 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 103394 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 103466 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 103466 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 103466 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 103466 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 103466 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt12 migrate-support-check fail in 103659 never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pas
[Xen-devel] [ovmf test] 103745: trouble: broken/pass
flight 103745 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/103745/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken REGR. vs. 103742 version targeted for testing: ovmf 15dae68589243726f0374e535a77e76444096bad baseline version: ovmf a35dc6499beb0b76c340379a06dff74a8d38095a Last test of basis 103742 2016-12-19 01:16:04 Z0 days Failing since103744 2016-12-19 04:23:56 Z0 days2 attempts Testing same since 103745 2016-12-19 09:14:52 Z0 days1 attempts People who touched revisions under test: Dandan Bi Jiewen Yao Michael Kinney Ruiyu Ni jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 broken 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 broken-step test-amd64-i386-xl-qemuu-ovmf-amd64 host-install(3) Not pushing. commit 15dae68589243726f0374e535a77e76444096bad Author: Ruiyu Ni Date: Mon Dec 19 15:27:38 2016 +0800 ShellBinPkg: New Shell binaries for IA32 and X64 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni commit 254e7cc32ce93c2a8f32c3b73563a145e65cf648 Author: Ruiyu Ni Date: Mon Dec 19 14:52:38 2016 +0800 FatBinPkg: New EnhancedFatDxe binaries for IA32, X64, EBC and IPF Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni commit d2fc7711136a13ea3ea8e00de6d9651507b8ed50 Author: Jiewen Yao Date: Thu Nov 24 13:36:56 2016 +0800 UefiCpuPkg/PiSmmCpu: Add SMM Comm Buffer Paging Protection. This patch sets the normal OS buffer EfiLoaderCode/Data, EfiBootServicesCode/Data, EfiConventionalMemory, EfiACPIReclaimMemory to be not present after SmmReadyToLock. To access these region in OS runtime phase is not a good solution. Previously, we did similar check in SmmMemLib to help SMI handler do the check. But if SMI handler forgets the check, it can still access these OS region and bring risk. So here we enforce the policy to prevent it happening. Cc: Jeff Fan Cc: Michael D Kinney Cc: Laszlo Ersek Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao Reviewed-by: Jeff Fan commit 09119a00cccaa08b28b7e2449998ba4c7aa4b0f8 Author: Michael Kinney Date: Tue Nov 29 06:36:51 2016 +0800 UefiCpuPkg/SmmCpuFeaturesLibStm: Add STM library instance Add a new instances of the SmmCpuFeaturesLib that is used by platforms to enable the SMI Transfer Monitor(STM) feature. This new instance is in the same directory as the default SmmCpuFeaturesLib instance in order to share source files. The DSC file is updated to build both SmmCpuFeatureLib instances and to build two versions of the PiSmmCpuDxeSmm module using each of the SmmCpuFeatureLib instances. Cc: Jiewen Yao Cc: Jeff Fan Cc: Feng Tian Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney Reviewed-by: Jiewen Yao Reviewed-by: Jeff Fan commit 4c6351db25eaf24335933ce3499258d7b48a57b2 Author: Michael Kinney Date: Thu Nov 17 20:54:19 2016 -0800 UefiCpuPkg/SmmCpuFeaturesLib: Split into two files Split the default implementation of the SmmCpuFeaturesLib into two files to prepare for the addition of the STM specific SmmCpuFeaturesLib implementation. The STM specific implementation installs a different SMI entry handler and initialize the MSEG specific MSR at the end of SmmCpuFeaturesInitializeProc
Re: [Xen-devel] [PATCH] Xen: ARM: Zero reserved fields of xatp before making hypervisor call
On 19/12/16 03:56, Jiandi An wrote:
> Ensure all reserved fields of xatp are zero before making hypervisor
> call to XEN in xen_map_device_mmio(). xenmem_add_to_physmap_one() in
> XEN fails the mapping request if extra.res reserved field in xatp is
> not zero for XENMAPSPACE_dev_mmio request.
>
> Signed-off-by: Jiandi An
> ---
> drivers/xen/arm-device.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/xen/arm-device.c b/drivers/xen/arm-device.c
> index 778acf8..208273b 100644
> --- a/drivers/xen/arm-device.c
> +++ b/drivers/xen/arm-device.c
> @@ -87,6 +87,9 @@ static int xen_map_device_mmio(const struct resource
> *resources,
> idxs[j] = XEN_PFN_DOWN(r->start) + j;
> }
>
> + /* Ensure reserved fields are set to zero */
> + memset(&xatp, 0, sizeof(xatp));
> +
> xatp.domid = DOMID_SELF;
> xatp.size = nr;
> xatp.space = XENMAPSPACE_dev_mmio;
Instead of setting xatp to 0 in each iteration I'd prefer a static
initialization of .domid and .space:
struct xen_add_to_physmap_range xatp = {
.domid = DOMID_SELF,
.space = XENMAPSPACE_dev_mmio
};
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 1/1] xen/arm: Map mmio-sram nodes as cached memory
Hi Edgar, On 16/12/2016 18:04, Edgar E. Iglesias wrote: On Fri, Dec 16, 2016 at 04:12:00PM +, Julien Grall wrote: On 15/12/16 11:26, Edgar E. Iglesias wrote: From: "Edgar E. Iglesias" Relax the mapping of mmio-sram nodes that do not set the no-memory-wc property to cached normal memory. Rationale: Allthough on chip memories are relatively fast compared to s/Allthough/Although/ Fixed for v2. off-chip memories, large OCMs are still significantly slower May I ask what does OCMs mean? It means On Chip Memories. I can spell it out in v2. Yes please. I was not able to find the acronym with a quick search Google. [...] I consider it as the most trusted domain and has other way to mess up the platform. So I am fine with this relaxation for the hardware domain (AKA DOM0). However, I have the feeling that we need this kind of relaxation for many devices. For instance prefetchable memory BARs for PCI would have to be cacheable, same for integrated graphic cards. Yes, I agree. I am wondering whether for DOM0 only (*not the other guests), we should relax the default stage-2 attribute mapping to p2m_mmio_direct_c. So we would let DOM0 in charge of the final attribute. This may boost the performance of memory access in DOM0. Any opinions? I think it makes sense. We had a discussiong about it a while back ago: https://lists.xenproject.org/archives/html/xen-devel/2015-05/msg02349.html The concerns that were raised were wether there could be devices that could behave badly and possibly giving dom0 access to trig undefined or unpredictable behavior that could be exploited. I think it would be fine for DOM0. It is already a trusted domain and have other way to take down the platform. If dom0 accesses devices through a cache, access patterns will change. In theory it may trig unexpected behaviour in some device. It's hard to say unless talking about specific chips and implementations. For example, given dom0 access to a DMA capable device may also achieve the same. I.e access patterns from DMA units differ from the ones originating from a CPU using uncached device memory. It could trig similar kind of errors. Another example is having the device mapped with different in 2 places with different cacheability attributes. The data accessed would not be coherent. But I believe that should not lead to a security issue. It would be interesting to see a concrete example of a problematic system. I believe it would depend a lot on how the platform have been designed. I think we have two choices to go forward: 1) Relax the memory attribute on case by case. DOM0 would not be able to exploit potential undefined behavior. However, this means that code is been added for any new device (e.g compatible string). 2) Relax the memory attribute on every case. DOM0 would be able to exploit potential undefined behavior. On the benefit side, every devices can be used at its full performance without any change required in Xen. In the case of ACPI, we rely on DOM0 to provide the correct mapping attribute when asking to do the stage-2 mapping (see XENMAPSPACE_dev_mmio). Note that currently, the MMIO are always mapped with the attribute Device-nGnRE. There is plan to change that in the future. So ACPI is implementing 2). Device Tree is currently implementing 1). But I would like to see the behavior of Xen the same no matter the firmware tables used. So I would lean towards 2). Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest
On Fri, Dec 16, 2016 at 05:03:13PM +, Julien Grall wrote: > (CC rest maintainers for event channel questions) > > On 16/12/16 10:06, Bhupinder Thakur wrote: > >Hi, > > Hi Bhupinder, > > >The idea is for Xen to act as an intermediary as shown below: > > > > ring buffers > > rx/tx fifo > >dom0 <---> Xen HYP (running pl011 emulation) > ><---> domU > >event > > interrupts > > > >Xen will directly manage the in/out console ring buffers (allocated by > >dom0 for dom0-domU console communication) for reading/writing console > >data from/to dom0. On the other side, Xen HYP will emulate pl011 to > >read/write data from/to domU and pass it on to/from dom0 over the > >in/out console ring buffers. There should be no change in dom0 as it > >will still use the same ring buffers. Similarly there should be no > >change in domU which would be running a standard pll011 driver. > > > >Currently, I am working on the interface between dom0 and Xen HYP. I > >want to intercept the console events in Xen HYP which pass between > >dom0 and domU. For now, I just want to capture console data coming > >from dom0 at Xen HYP and loop it back to dom0, to confirm that this > >interface is working. > > > >Since each guest domain will have a unique event channel assigned for > >console communication, Xen HYP can find out the event channel for a > >given domU from the start_info page of that domU, which should have > > The start_info page is x86 specific. If you want to get the console > event channel for ARM, you would have to use > d->arch.hvm_domain.params[HVM_PARAM_CONSOLE_EVTCHN]. > > This parameter will be setup by the toolstack (see alloc_magic_pages > in libxc/xc_dom_arm.c). > > >been allocated by dom0. Whenever, an event is to be dispatched via > >evtchn_send() API in Xen, it can check if the event channel is the > >console event channel for a given domU. If yes and its source domain > >is dom0 and destination domain is domU then it will write the data > >back to the console out ring buffer of the domU and raise a console > >event to dom0. > > > >Once this interface is working, Xen HYP can check the source and > >destination dom ids and decide which way the event came from and > >accordingly process the console data. To allow a mix of PV console > >guests and pl011 guests, Xen might have to maintain a flag per domain, > >which tells whether Xen HYP should intercept and process the data (for > >pl011 UART case) or let it go transparently (for PV conosle case). > > I am not very familiar with the event channel code. I will let the > others comment on this bit. > > Regardless that, how would you decide whether the hypervisor should > intercept the notification? > > I can see 2 different cases: > 1) The guest is starting to use the pl011 then move to the HVC > console (or HVC then pl011) > 2) The guest is using both the PL011 and the HVC console > > Should we consider the second case valid? I would say yes, because a > user could specify both on the command line. If we use the same > ring, the output would be a total garbage. > > So maybe we need to allocate two distinct rings and event channel? This sounds like the only sensible thing to me. I think this is really about adding a new device to the Xen virtual platform, and providing the user the option to choose which one he wants the tool in Dom0 to be presented using stdin/out. Presumably the other console/serial can be redirected to a file or socket or something? Thanks, -Christoffer ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen: ARM: Support for mapping ECAM PCIe Config Space Specified In Static ACPI Table
Hi, >On 16/12/2016 15:49, Julien Grall wrote: >> On 14/12/16 08:00, Jiandi An wrote: >>> Xen currently doesn't map ECAM space specified in static ACPI table. >>> Seeking opinion on how this should be handled properly. >>> Each root complex ECAM region takes up 64K 4K pages (256MB). >>> For some platforms there might be multiple root complexes. >>> Is the plan to map all at once?Julien has mentioned support >>> for mapping ECAM may come when support for PCI passthrough is >>> added, is that right? What mechanism will it be? Will Xen or >>> dom0 be the one that parses the staic ACPI tables and map the ECAM space? >> >> For performance reason, each ECAM region would need to be mapped at >> once, so the stage-2 page table could take advantage of superpage (it >> will mostly be 2MB). >> >> Now, I don't think Xen should map the ECAM region in stage-2 before >> hand. All the regions may not be described in the MCFG and I would like >> to see a generic solution. >> >> Looking at the code (see pci_create_ecam_create in drivers/pci/ecam.c), >> ioremap is used. I believe the problem is the same for the 2 other >> threads you sent ( [1] and [2]). >> >> So it might be good to look at hooking up a call to >> XENMEM_add_to_physmap_range in ioremap. >> >> Any opinions? > >I thought a bit more about it and I realized we need to be cautious on >how to proceed here. > >DOM0 will have a mix of real devices and emulated devices (e.g some part >of the GIC). For the emulated devices, DOM0 should not call >XENMEM_add_to_physmap_range. However, DOM0 is not aware what is emulated >or not, so even the current approach (hooking up in platform device) >seems fragile. We rely on Xen to say "this region cannot be mapped". > Why not add support for parsing ACPI tables in Xen, from linux, as we parse dt. -manish ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 103746: tolerable all pass - PUSHED
flight 103746 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103746/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen 7469686ccc959765542cd10551f9bd7a602f2cbd
baseline version:
xen fa25f10f2af877ed6bfa2ddce3d321ff61268c13
Last test of basis 103511 2016-12-17 00:02:50 Z2 days
Testing same since 103746 2016-12-19 11:02:18 Z0 days1 attempts
People who touched revisions under test:
Jan Beulich
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl 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 :
+ branch=xen-unstable-smoke
+ revision=7469686ccc959765542cd10551f9bd7a602f2cbd
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
7469686ccc959765542cd10551f9bd7a602f2cbd
+ branch=xen-unstable-smoke
+ revision=7469686ccc959765542cd10551f9bd7a602f2cbd
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' x7469686ccc959765542cd10551f9bd7a602f2cbd = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/
Re: [Xen-devel] Xen: ARM: Support for mapping ECAM PCIe Config Space Specified In Static ACPI Table
On 19/12/2016 13:20, Jaggi, Manish wrote: On 16/12/2016 15:49, Julien Grall wrote: On 14/12/16 08:00, Jiandi An wrote: Xen currently doesn't map ECAM space specified in static ACPI table. Seeking opinion on how this should be handled properly. Each root complex ECAM region takes up 64K 4K pages (256MB). For some platforms there might be multiple root complexes. Is the plan to map all at once?Julien has mentioned support for mapping ECAM may come when support for PCI passthrough is added, is that right? What mechanism will it be? Will Xen or dom0 be the one that parses the staic ACPI tables and map the ECAM space? For performance reason, each ECAM region would need to be mapped at once, so the stage-2 page table could take advantage of superpage (it will mostly be 2MB). Now, I don't think Xen should map the ECAM region in stage-2 before hand. All the regions may not be described in the MCFG and I would like to see a generic solution. Looking at the code (see pci_create_ecam_create in drivers/pci/ecam.c), ioremap is used. I believe the problem is the same for the 2 other threads you sent ( [1] and [2]). So it might be good to look at hooking up a call to XENMEM_add_to_physmap_range in ioremap. Any opinions? I thought a bit more about it and I realized we need to be cautious on how to proceed here. DOM0 will have a mix of real devices and emulated devices (e.g some part of the GIC). For the emulated devices, DOM0 should not call XENMEM_add_to_physmap_range. However, DOM0 is not aware what is emulated or not, so even the current approach (hooking up in platform device) seems fragile. We rely on Xen to say "this region cannot be mapped". Why not add support for parsing ACPI tables in Xen, from linux, as we parse dt. Because MMIO can be described in ASL too. I would rather avoid to have a different behavior depending whether the MMIO has been described in static table or ASL. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/head: Refactor 32-bit pgtable setup
On 12/18/2016 03:44 AM, Ingo Molnar wrote: > * Boris Ostrovsky wrote: > >> On 12/08/2016 11:33 PM, Ingo Molnar wrote: >>> * Boris Ostrovsky wrote: >>> The new Xen PVH entry point requires page tables to be setup by the kernel since it is entered with paging disabled. Pull the common code out of head_32.S so that mk_early_pgtbl_32 can be invoked from both the new Xen entry point and the existing startup_32 code. Convert resulting common code to C. Signed-off-by: Boris Ostrovsky --- This is replacement for https://lkml.org/lkml/2016/10/14/434, with assembly code re-written in C as requested by Ingo. arch/x86/include/asm/pgtable_32.h | 32 ++ arch/x86/kernel/head32.c | 62 +++ arch/x86/kernel/head_32.S | 122 +++--- 3 files changed, 101 insertions(+), 115 deletions(-) >>> Whee, I love it! And the code is so much more readable! >>> >>> Did you have any particular robustness problems (difficult to resolve >>> crashes) >>> while developing it, or was it reasonably straightforward to do? >> There was nothing particularly difficult beyond understanding current >> code. That, of course, is not to say that there were no crashes but >> developing this on a guest gives you pretty good insight into why/where >> you crashed. >> >> This was tested on bare-metal (in case you are wondering), but obviously >> more testing is always good. > Ok, cool! > > Would you like to carry this with your other Xen dependencies? If yes: > >Acked-by: Ingo Molnar > > If not then I can pick it up and get it to Linus in v4.10. I don't think my series will get into 4.10 since it is has a dependency on hypervisor code that is still being reviewed. If you could take it via your tree it would be great. Thanks! -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 01/13] x86/pmtimer: Move ACPI registers from PMTState to hvm_domain
>>> On 17.12.16 at 00:18, wrote: > These registers (pm1a specifically) are not all specific to pm timer > and are accessed by non-pmtimer code (for example, sleep/power button > emulation). > > The public name for save state structure is kept as 'pmtimer' to avoid > code churn with the expected changes in migration code. hvm_hw_acpi > name is introduced for internal use but when migration code is updated > hvm_hw_pmtimer will be renamed to hvm_hw_acpi. > > No functional changes are introduced. > > (While this file is being modified, also add emacs mode style rune) > > Signed-off-by: Boris Ostrovsky Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 03/13] domctl: Add XEN_DOMCTL_acpi_access
>>> On 17.12.16 at 00:18, wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1425,6 +1425,15 @@ long arch_do_domctl(
> }
> break;
>
> +case XEN_DOMCTL_acpi_access:
> +if ( !is_hvm_domain(d) )
> +ret = -EINVAL;
I think it would be better to use some other, less frequently used
error code here.
> --- /dev/null
> +++ b/xen/arch/x86/hvm/acpi.c
> @@ -0,0 +1,25 @@
> +/* acpi.c: ACPI access handling
> + *
> + * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
> + */
> +#include
> +#include
> +#include
> +
> +
> +int hvm_acpi_domctl_access(struct domain *d, uint8_t rw,
Wouldn't "rw" better be bool internally?
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -1144,6 +1144,29 @@ struct xen_domctl_psr_cat_op {
> typedef struct xen_domctl_psr_cat_op xen_domctl_psr_cat_op_t;
> DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cat_op_t);
>
> +/* ACPI access structure */
> +typedef struct xen_acpi_access {
> +#define XEN_ACPI_SYSTEM_MEMORY 0
> +#define XEN_ACPI_SYSTEM_IO 1
> +uint8_tspace_id; /* Address space */
> +uint8_twidth; /* Access size (bytes) */
> +uint8_tpad[6];
> +uint64_aligned_t address;/* 64-bit address of register */
> +} xen_acpi_access_t;
> +
> +struct xen_domctl_acpi_access {
> +xen_acpi_access_t access; /* IN: Register being accessed */
> +
> +#define XEN_DOMCTL_ACPI_READ 0
> +#define XEN_DOMCTL_ACPI_WRITE 1
> +uint8_trw; /* IN: Read or write */
> +uint8_tpad[7];
> +
> +XEN_GUEST_HANDLE_64(void) val; /* IN/OUT: data */
> +};
> +typedef struct xen_domctl_acpi_access xen_domctl_acpi_access_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_acpi_access_t);
Do you expect to use xen_acpi_access anywhere else? If not,
the overall amount of padding needed could be reduced by
folding both structures.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [linux-4.1 test] 103740: regressions - trouble: broken/fail/pass
flight 103740 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/103740/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 101737 test-amd64-i386-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 101737 test-amd64-amd64-qemuu-nested-intel 6 xen-boot fail REGR. vs. 101737 test-amd64-i386-pair 9 xen-boot/src_hostfail REGR. vs. 101737 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101737 test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-boot fail REGR. vs. 101737 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101737 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101737 test-amd64-amd64-xl-pvh-intel 6 xen-bootfail REGR. vs. 101737 test-amd64-amd64-xl-multivcpu 6 xen-bootfail REGR. vs. 101737 test-amd64-i386-freebsd10-amd64 6 xen-boot fail REGR. vs. 101737 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101737 build-armhf-pvops 5 kernel-build fail in 102733 REGR. vs. 101737 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-win7-amd64 3 host-install(3) broken in 103011 pass in 103740 test-amd64-i386-xl-qemut-winxpsp3 3 host-install(3) broken in 103011 pass in 103740 test-amd64-amd64-xl-qemuu-win7-amd64 3 host-install(3) broken in 103011 pass in 103740 test-amd64-i386-xl 3 host-install(3) broken in 103011 pass in 103740 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken in 103011 pass in 103740 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken pass in 103736 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken pass in 103736 test-amd64-amd64-xl-qcow2 3 host-install(3) broken pass in 103736 test-amd64-amd64-libvirt-vhd 9 debian-di-install fail in 102733 pass in 102886 test-amd64-amd64-xl-xsm 19 guest-start/debian.repeat fail in 102755 pass in 103089 test-armhf-armhf-libvirt-xsm 14 guest-stop fail in 102755 pass in 103740 test-armhf-armhf-xl-multivcpu 11 guest-start fail in 102829 pass in 103740 test-amd64-i386-xl-xsm6 xen-boot fail in 102886 pass in 103740 test-amd64-amd64-qemuu-nested-amd 9 debian-hvm-install fail in 102886 pass in 103740 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail in 102886 pass in 103740 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail in 103011 pass in 103740 test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail in 103089 pass in 103740 test-armhf-armhf-libvirt-xsm 6 xen-boot fail in 103451 pass in 103740 test-armhf-armhf-libvirt 11 guest-start fail in 103736 pass in 103740 test-armhf-armhf-libvirt-xsm 11 guest-start fail in 103736 pass in 103740 test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail pass in 102733 test-amd64-i386-xl-raw6 xen-boot fail pass in 102733 test-amd64-amd64-libvirt 6 xen-boot fail pass in 102733 test-amd64-amd64-xl-qemut-winxpsp3 6 xen-boot fail pass in 102755 test-amd64-i386-libvirt-xsm 6 xen-boot fail pass in 102755 test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail pass in 102829 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 102886 test-amd64-amd64-libvirt-vhd 6 xen-boot fail pass in 102886 test-amd64-i386-freebsd10-i386 6 xen-boot fail pass in 103011 test-amd64-amd64-xl-xsm 6 xen-boot fail pass in 103089 test-amd64-amd64-libvirt-pair 9 xen-boot/src_host fail pass in 103089 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host fail pass in 103089 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 103089 test-amd64-amd64-xl-rtds 6 xen-boot fail pass in 103089 test-amd64-amd64-pair 9 xen-boot/src_host fail pass in 103165 test-amd64-amd64-pair10 xen-boot/dst_host fail pass in 103165 test-amd64-amd64-libvirt-xsm 6 xen-boot fail pass in 103165 test-amd64-amd64-i386-pvgrub 6 xen-boot fail pass in 103352 test-amd64-i386-libvirt-pair 9 xen-boot/src_host fail pass in 103451 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host fail pass in 103451 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-rumprun-amd64 6 xen-boot fail blocked in 101737 test-armhf-armhf-xl-credit2 11 guest-start fail in 102755 like 101737 test-armhf-armhf-xl-rtds 16 guest-start.2 fail in 102886 blocked in 101737 test-armhf-armhf-libvirt 15 guest-start/debian.repeat fail in 102886 like 101672 test-armhf-arm
Re: [Xen-devel] [licensing] was: [XTF PATCH 04/16] vvmx: add C wrappers of vmxon/vmread/vmptrld
On 18/12/2016 21:20, "Haozhong Zhang" wrote:
>On 12/16/16 19:03 +, Andrew Cooper wrote:
>>On 16/12/16 13:43, Haozhong Zhang wrote:
>>> diff --git a/include/arch/x86/hvm/vmx/vmcs.h
>>>b/include/arch/x86/hvm/vmx/vmcs.h
>>> new file mode 100644
>>> index 000..e1a6ef8
>>> --- /dev/null
>>> +++ b/include/arch/x86/hvm/vmx/vmcs.h
>>> @@ -0,0 +1,179 @@
>>> +#ifndef XTF_X86_HVM_VMX_VMCS_H
>>> +#define XTF_X86_HVM_VMX_VMCS_H
>>> +
>>> +/* VMCS field encodings. */
>>> +#define VMCS_HIGH(x) ((x) | 1)
>>> +enum vmcs_field {
>>> +VIRTUAL_PROCESSOR_ID= 0x,
>>> +POSTED_INTR_NOTIFICATION_VECTOR = 0x0002,
>>> +EPTP_INDEX = 0x0004,
>>> +#define GUEST_SEG_SELECTOR(sel) (GUEST_ES_SELECTOR + (sel) * 2) /* ES
>>>... GS */
>>
>>Unfortunately, there is probably a BSD/GPL licensing issue here.
>>
>>XTF is BSD clause 2 licensed, because a lot of the core microkernel bits
>>are generally useful to other microkernel projects, and I have specific
>>plans to contribute improvements back to the likes of Mini-OS and
>>HVMLoader. I would specifically like to maintain this property.
>>
>>Xen, following its Linux heritage, is strictly GPLv2 (other than the
>>public headers, which are specifically different).
>>
>>
>>Having XTF use the same naming as Xen is convenient for development, and
>>I specifically don't want to get caught up in tricks like renaming
>>constants;
>
>but renaming or taking names from other BSD-licensed projects [1] could
>keep the whole project as purely BSD-licensed.
>
>[1]
>https://github.com/freebsd/freebsd/blob/master/sys/amd64/vmm/intel/vmcs.h
I am not sure what you mean.
>> these names inherit from the architecture manual and calling
>>them anything else would be even worse. If we were to go down this
>>route, being able to keep the header file in sync would be useful, but
>>dual licensing it Xen would be complicated and confusing.
>>
>>BSD and GPL are compatible licenses. One option Ian suggested would be
>>to have a GPL subdirectory in XTF which clearly separates GPL content
>>from BSD content. The resulting tests would become GPL, but the primary
>>distribution method is "git clone && make", so there are no issues
>>there.
This seems to be a workable approach.
Whether the test suite itself (when combined with minios or other non-GPL
baselines) are GPL or another license probably does not matter.
Separating the GPL code out, would be useful if the suite needed to be
combined with a baseline which is non-GPL compatible.
@Andy: you may want to have a chat with Ian and check whether the MPL 2.0
may be a better choice for XTF than BSD in this case. I have not looked
into how copyleft and MPL 2 work together though. Just a thought.
>If I want to use the BSD-licensed files individually in other
>projects, will I need to keep a GPL license with them?
I am assuming you mean whether the file needs a GPL (c) header? The answer
is no.
But the combined work will be GPL: for example let's say a folder A has
BSD files in it and a folder B has GPL files in it and you compile A and B
together to AB.exe, then AB.exe as a whole is licensed under the GPL.
>
>Thanks,
>Haozhong
>
>> I think it is reasonable to take this approach for header file
>>content like this, describing an external ABI, but I'd certainly like to
>>avoid doing anything similar for other content, as it complicates
>>contributing microkernel content back to other projects.
>>
>>CC'ing various people for opinions.
>>
>>~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [distros-debian-sid test] 68243: trouble: blocked/broken/fail/pass
flight 68243 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68243/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 3 host-install(3) broken REGR. vs. 68207 Regressions which are regarded as allowable (not blocking): test-amd64-i386-i386-sid-netboot-pvgrub 9 debian-di-install fail like 68207 test-amd64-i386-amd64-sid-netboot-pygrub 9 debian-di-install fail like 68207 test-amd64-amd64-amd64-sid-netboot-pvgrub 9 debian-di-install fail like 68207 test-amd64-amd64-i386-sid-netboot-pygrub 9 debian-di-install fail like 68207 Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-sid-netboot-pygrub 1 build-check(1)blocked n/a baseline version: flight 68207 jobs: build-amd64 pass build-armhf broken build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-sid-netboot-pvgrubfail test-amd64-i386-i386-sid-netboot-pvgrub fail test-amd64-i386-amd64-sid-netboot-pygrub fail test-armhf-armhf-armhf-sid-netboot-pygrubblocked test-amd64-amd64-i386-sid-netboot-pygrub fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 03/13] domctl: Add XEN_DOMCTL_acpi_access
On 12/19/2016 09:17 AM, Jan Beulich wrote:
On 17.12.16 at 00:18, wrote:
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -1425,6 +1425,15 @@ long arch_do_domctl(
>> }
>> break;
>>
>> +case XEN_DOMCTL_acpi_access:
>> +if ( !is_hvm_domain(d) )
>> +ret = -EINVAL;
> I think it would be better to use some other, less frequently used
> error code here.
ENODEV? (Because there is no ACPI "device" for PV guests)
>
>> --- /dev/null
>> +++ b/xen/arch/x86/hvm/acpi.c
>> @@ -0,0 +1,25 @@
>> +/* acpi.c: ACPI access handling
>> + *
>> + * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
>> + */
>> +#include
>> +#include
>> +#include
>> +
>> +
>> +int hvm_acpi_domctl_access(struct domain *d, uint8_t rw,
> Wouldn't "rw" better be bool internally?
I will drop it altogether since as you pointed out below there is no
reason to keep xen_acpi_access_t as a separate structure. I'll pass
whole xen_domctl_acpi_access_t here.
(And I noticed that XEN_DOMCTL_ACPI_WRITE crept into acpi_common_*()
code in patch 5 so I will want to fix dir/rw there)
-boris
>
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -1144,6 +1144,29 @@ struct xen_domctl_psr_cat_op {
>> typedef struct xen_domctl_psr_cat_op xen_domctl_psr_cat_op_t;
>> DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cat_op_t);
>>
>> +/* ACPI access structure */
>> +typedef struct xen_acpi_access {
>> +#define XEN_ACPI_SYSTEM_MEMORY 0
>> +#define XEN_ACPI_SYSTEM_IO 1
>> +uint8_tspace_id; /* Address space */
>> +uint8_twidth; /* Access size (bytes) */
>> +uint8_tpad[6];
>> +uint64_aligned_t address;/* 64-bit address of register */
>> +} xen_acpi_access_t;
>> +
>> +struct xen_domctl_acpi_access {
>> +xen_acpi_access_t access; /* IN: Register being accessed */
>> +
>> +#define XEN_DOMCTL_ACPI_READ 0
>> +#define XEN_DOMCTL_ACPI_WRITE 1
>> +uint8_trw; /* IN: Read or write */
>> +uint8_tpad[7];
>> +
>> +XEN_GUEST_HANDLE_64(void) val; /* IN/OUT: data */
>> +};
>> +typedef struct xen_domctl_acpi_access xen_domctl_acpi_access_t;
>> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_acpi_access_t);
> Do you expect to use xen_acpi_access anywhere else? If not,
> the overall amount of padding needed could be reduced by
> folding both structures.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 103748: all pass - PUSHED
flight 103748 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103748/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 15dae68589243726f0374e535a77e76444096bad
baseline version:
ovmf a35dc6499beb0b76c340379a06dff74a8d38095a
Last test of basis 103742 2016-12-19 01:16:04 Z0 days
Failing since103744 2016-12-19 04:23:56 Z0 days3 attempts
Testing same since 103745 2016-12-19 09:14:52 Z0 days2 attempts
People who touched revisions under test:
Dandan Bi
Jiewen Yao
Michael Kinney
Ruiyu Ni
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=ovmf
+ revision=15dae68589243726f0374e535a77e76444096bad
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf
15dae68589243726f0374e535a77e76444096bad
+ branch=ovmf
+ revision=15dae68589243726f0374e535a77e76444096bad
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' x15dae68589243726f0374e535a77e76444096bad = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.ke
Re: [Xen-devel] [PATCH v5 03/13] domctl: Add XEN_DOMCTL_acpi_access
>>> On 19.12.16 at 15:48, wrote: > On 12/19/2016 09:17 AM, Jan Beulich wrote: > On 17.12.16 at 00:18, wrote: >>> --- a/xen/arch/x86/domctl.c >>> +++ b/xen/arch/x86/domctl.c >>> @@ -1425,6 +1425,15 @@ long arch_do_domctl( >>> } >>> break; >>> >>> +case XEN_DOMCTL_acpi_access: >>> +if ( !is_hvm_domain(d) ) >>> +ret = -EINVAL; >> I think it would be better to use some other, less frequently used >> error code here. > > ENODEV? (Because there is no ACPI "device" for PV guests) Fine with me. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 4/4] init/FreeBSD: add rc control variables
Those are used in order to decide which scripts are executed at init.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/hotplug/FreeBSD/rc.d/xencommons.in | 5 -
tools/hotplug/FreeBSD/rc.d/xendriverdomain.in | 5 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/tools/hotplug/FreeBSD/rc.d/xencommons.in
b/tools/hotplug/FreeBSD/rc.d/xencommons.in
index 81f69f3..2fcd84a 100644
--- a/tools/hotplug/FreeBSD/rc.d/xencommons.in
+++ b/tools/hotplug/FreeBSD/rc.d/xencommons.in
@@ -11,6 +11,7 @@ LD_LIBRARY_PATH="${libdir}"
export LD_LIBRARY_PATH
name="xencommons"
+rcvar="xencommons_enable"
start_precmd="xen_precmd"
start_cmd="xen_startcmd"
stop_cmd="xen_stop"
@@ -23,6 +24,9 @@ XENCONSOLED_PIDFILE="@XEN_RUN_DIR@/xenconsoled.pid"
#XENCONSOLED_TRACE="@XEN_LOG_DIR@/xenconsole-trace.log"
#XENSTORED_TRACE="@XEN_LOG_DIR@/xen/xenstore-trace.log"
+load_rc_config $name
+: ${xencommons_enable:=no}
+
xen_precmd()
{
mkdir -p @XEN_LIB_STORED@ || exit 1
@@ -116,5 +120,4 @@ xen_status()
fi
}
-load_rc_config $name
run_rc_command "$1"
diff --git a/tools/hotplug/FreeBSD/rc.d/xendriverdomain.in
b/tools/hotplug/FreeBSD/rc.d/xendriverdomain.in
index c71871c..1384fdd 100644
--- a/tools/hotplug/FreeBSD/rc.d/xendriverdomain.in
+++ b/tools/hotplug/FreeBSD/rc.d/xendriverdomain.in
@@ -13,12 +13,16 @@ LD_LIBRARY_PATH="${libdir}"
export LD_LIBRARY_PATH
name="xendriverdomain"
+rcvar="xendriverdomain_enable"
start_cmd="xendriverdomain_startcmd"
stop_cmd="xendriverdomain_stop"
extra_commands=""
XLDEVD_PIDFILE="@XEN_RUN_DIR@/xldevd.pid"
+load_rc_config $name
+: ${xendriverdomain_enable:=no}
+
xendriverdomain_start()
{
printf "Starting xenservices: xl devd."
@@ -38,5 +42,4 @@ xendriverdomain_stop()
wait_for_pids $rc_pids
}
-load_rc_config $name
run_rc_command "$1"
--
2.10.1 (Apple Git-78)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/4] init/FreeBSD: set correct PATH for xl devd
FreeBSD init scripts don't have /usr/local/{bin/sbin} in it's PATH, which
prevents `xl devd` from working properly since hotplug scripts require the set
of xenstore cli tools to be in PATH.
While there also fix the usage of --pidfile, which according to the xl help
doesn't use "=", and add braces around XLDEVD_PIDFILE.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/hotplug/FreeBSD/rc.d/xendriverdomain.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/hotplug/FreeBSD/rc.d/xendriverdomain.in
b/tools/hotplug/FreeBSD/rc.d/xendriverdomain.in
index 8ece7c3..3917de2 100644
--- a/tools/hotplug/FreeBSD/rc.d/xendriverdomain.in
+++ b/tools/hotplug/FreeBSD/rc.d/xendriverdomain.in
@@ -29,7 +29,7 @@ xendriverdomain_startcmd()
{
printf "Starting xenservices: xl devd."
- ${sbindir}/xl devd --pidfile=$XLDEVD_PIDFILE ${XLDEVD_ARGS}
+ PATH="${bindir}:${sbindir}:$PATH" ${sbindir}/xl devd --pidfile
${XLDEVD_PIDFILE} ${XLDEVD_ARGS}
printf "\n"
}
--
2.10.1 (Apple Git-78)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/4] init/FreeBSD: Minor fixes for FreeBSD init scripts
A couple of minor fixes for FreeBSD init scripts that I've discovered while playing with FreeBSD driver domains. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 3/4] init/FreeBSD: fix xencommons so it can only be launched by Dom0
At the moment the execution of xencommons is gated on the presence of the privcmd device, but that's not correct, since privcmd is available to all Xen domains (privileged or unprivileged). Instead of using privcmd use the xenstored device, which will only be available to the domain that's in charge of running xenstored, and thus xencommons. Signed-off-by: Roger Pau Monné --- Cc: Ian Jackson Cc: Wei Liu --- tools/hotplug/FreeBSD/rc.d/xencommons.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/hotplug/FreeBSD/rc.d/xencommons.in b/tools/hotplug/FreeBSD/rc.d/xencommons.in index efa8801..81f69f3 100644 --- a/tools/hotplug/FreeBSD/rc.d/xencommons.in +++ b/tools/hotplug/FreeBSD/rc.d/xencommons.in @@ -16,7 +16,7 @@ start_cmd="xen_startcmd" stop_cmd="xen_stop" status_cmd="xen_status" extra_commands="status" -required_files="/dev/xen/privcmd" +required_files="/dev/xen/xenstored" XENSTORED_PIDFILE="@XEN_RUN_DIR@/xenstored.pid" XENCONSOLED_PIDFILE="@XEN_RUN_DIR@/xenconsoled.pid" -- 2.10.1 (Apple Git-78) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/4] init/FreeBSD: remove xendriverdomain_precmd
...because it's empty. While there also rename xendriverdomain_startcmd to
xendriverdomain_start in order to match the nomenclature of the file.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/hotplug/FreeBSD/rc.d/xendriverdomain.in | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/tools/hotplug/FreeBSD/rc.d/xendriverdomain.in
b/tools/hotplug/FreeBSD/rc.d/xendriverdomain.in
index 3917de2..c71871c 100644
--- a/tools/hotplug/FreeBSD/rc.d/xendriverdomain.in
+++ b/tools/hotplug/FreeBSD/rc.d/xendriverdomain.in
@@ -13,19 +13,13 @@ LD_LIBRARY_PATH="${libdir}"
export LD_LIBRARY_PATH
name="xendriverdomain"
-start_precmd="xendriverdomain_precmd"
start_cmd="xendriverdomain_startcmd"
stop_cmd="xendriverdomain_stop"
extra_commands=""
XLDEVD_PIDFILE="@XEN_RUN_DIR@/xldevd.pid"
-xendriverdomain_precmd()
-{
- :
-}
-
-xendriverdomain_startcmd()
+xendriverdomain_start()
{
printf "Starting xenservices: xl devd."
--
2.10.1 (Apple Git-78)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [linux-3.18 test] 103743: regressions - trouble: blocked/broken/fail/pass
flight 103743 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/103743/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-xsm 3 host-install(3)broken REGR. vs. 101675 test-amd64-i386-libvirt-pair 9 xen-boot/src_hostfail REGR. vs. 101675 test-amd64-i386-libvirt-pair 10 xen-boot/dst_hostfail REGR. vs. 101675 test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-bootfail REGR. vs. 101675 test-amd64-amd64-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-xl-multivcpu 6 xen-bootfail REGR. vs. 101675 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101675 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101675 test-amd64-i386-pair 9 xen-boot/src_hostfail REGR. vs. 101675 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101675 test-amd64-i386-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-amd64-pvgrub 6 xen-bootfail REGR. vs. 101675 test-amd64-amd64-libvirt-pair 9 xen-boot/src_host fail REGR. vs. 101675 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host fail REGR. vs. 101675 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-qemuu-nested-intel 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-libvirt-xsm 6 xen-boot fail REGR. vs. 101675 build-i386-pvops 5 kernel-build fail in 102732 REGR. vs. 101675 build-armhf-libvirt 4 host-build-prep fail in 102875 REGR. vs. 101675 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken in 103738 pass in 103743 test-amd64-i386-xl-qemut-debianhvm-amd64 3 host-install(3) broken pass in 103738 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3)broken pass in 103738 test-amd64-i386-freebsd10-amd64 3 host-install(3) broken pass in 103738 test-amd64-amd64-xl-rtds 3 host-install(3) broken pass in 103738 test-amd64-amd64-xl-qemuu-win7-amd64 3 host-install(3) broken pass in 103738 test-amd64-i386-qemuu-rhel6hvm-amd 15 capture-logs(15) broken pass in 103738 test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail in 103312 pass in 103743 test-armhf-armhf-libvirt 4 host-ping-check-native fail in 103688 pass in 103743 test-amd64-amd64-pair 9 xen-boot/src_host fail pass in 102732 test-amd64-amd64-pair10 xen-boot/dst_host fail pass in 102732 test-amd64-amd64-xl-xsm 6 xen-boot fail pass in 102732 test-amd64-amd64-i386-pvgrub 6 xen-boot fail pass in 102754 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 102823 test-amd64-amd64-libvirt 6 xen-boot fail pass in 102823 test-amd64-amd64-xl-credit2 6 xen-boot fail pass in 102875 test-amd64-i386-xl-raw6 xen-boot fail pass in 102875 test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail pass in 102974 test-amd64-i386-freebsd10-i386 6 xen-boot fail pass in 103169 test-amd64-i386-xl-qemuu-winxpsp3 6 xen-boot fail pass in 103312 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-boot fail pass in 103688 test-amd64-i386-xl6 xen-boot fail pass in 103738 test-armhf-armhf-libvirt-raw 14 guest-start/debian.repeat fail pass in 103738 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-vhd 9 debian-di-install fail in 103169 like 101662 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 103312 like 101662 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail in 103738 like 101675 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail in 103738 like 101675 test-amd64-amd64-xl-rtds 9 debian-install fail in 103738 like 101675 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 101675 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 101675 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 101675 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101675 Tests which did not succeed, but are not blocking: test-amd64-i386-freebsd10-i386 1 build-check(1) blocked in 102732 n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 102732 n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 102732 n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked in 102732 n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked in 102732
Re: [Xen-devel] [licensing] was: [XTF PATCH 04/16] vvmx: add C wrappers of vmxon/vmread/vmptrld
On Fri, Dec 16, 2016 at 07:03:49PM +, Andrew Cooper wrote:
> On 16/12/16 13:43, Haozhong Zhang wrote:
> > diff --git a/include/arch/x86/hvm/vmx/vmcs.h
> > b/include/arch/x86/hvm/vmx/vmcs.h
> > new file mode 100644
> > index 000..e1a6ef8
> > --- /dev/null
> > +++ b/include/arch/x86/hvm/vmx/vmcs.h
> > @@ -0,0 +1,179 @@
> > +#ifndef XTF_X86_HVM_VMX_VMCS_H
> > +#define XTF_X86_HVM_VMX_VMCS_H
> > +
> > +/* VMCS field encodings. */
> > +#define VMCS_HIGH(x) ((x) | 1)
> > +enum vmcs_field {
> > +VIRTUAL_PROCESSOR_ID= 0x,
> > +POSTED_INTR_NOTIFICATION_VECTOR = 0x0002,
> > +EPTP_INDEX = 0x0004,
> > +#define GUEST_SEG_SELECTOR(sel) (GUEST_ES_SELECTOR + (sel) * 2) /* ES ...
> > GS */
>
> Unfortunately, there is probably a BSD/GPL licensing issue here.
>
> XTF is BSD clause 2 licensed, because a lot of the core microkernel bits
> are generally useful to other microkernel projects, and I have specific
> plans to contribute improvements back to the likes of Mini-OS and
> HVMLoader. I would specifically like to maintain this property.
>
> Xen, following its Linux heritage, is strictly GPLv2 (other than the
> public headers, which are specifically different).
IANAL, but it seems quite weird to me that a set of defines or enums (without
any logic behind) can be put under a specific license, which seems to be the
case here. Certainly this is publicly available on the SDM, and it won't be
surprising for someone to code them in the exact same way AFAICT.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [licensing] was: [XTF PATCH 04/16] vvmx: add C wrappers of vmxon/vmread/vmptrld
On 19/12/16 15:20, Roger Pau Monné wrote:
> On Fri, Dec 16, 2016 at 07:03:49PM +, Andrew Cooper wrote:
>> On 16/12/16 13:43, Haozhong Zhang wrote:
>>> diff --git a/include/arch/x86/hvm/vmx/vmcs.h
>>> b/include/arch/x86/hvm/vmx/vmcs.h
>>> new file mode 100644
>>> index 000..e1a6ef8
>>> --- /dev/null
>>> +++ b/include/arch/x86/hvm/vmx/vmcs.h
>>> @@ -0,0 +1,179 @@
>>> +#ifndef XTF_X86_HVM_VMX_VMCS_H
>>> +#define XTF_X86_HVM_VMX_VMCS_H
>>> +
>>> +/* VMCS field encodings. */
>>> +#define VMCS_HIGH(x) ((x) | 1)
>>> +enum vmcs_field {
>>> +VIRTUAL_PROCESSOR_ID= 0x,
>>> +POSTED_INTR_NOTIFICATION_VECTOR = 0x0002,
>>> +EPTP_INDEX = 0x0004,
>>> +#define GUEST_SEG_SELECTOR(sel) (GUEST_ES_SELECTOR + (sel) * 2) /* ES ...
>>> GS */
>> Unfortunately, there is probably a BSD/GPL licensing issue here.
>>
>> XTF is BSD clause 2 licensed, because a lot of the core microkernel bits
>> are generally useful to other microkernel projects, and I have specific
>> plans to contribute improvements back to the likes of Mini-OS and
>> HVMLoader. I would specifically like to maintain this property.
>>
>> Xen, following its Linux heritage, is strictly GPLv2 (other than the
>> public headers, which are specifically different).
> IANAL, but it seems quite weird to me that a set of defines or enums (without
> any logic behind) can be put under a specific license, which seems to be the
> case here. Certainly this is publicly available on the SDM, and it won't be
> surprising for someone to code them in the exact same way AFAICT.
Frankly, I was already on the fence with this, but Ian had a stronger
opinion.
If it were just the names, I wouldn't have raised an issue at all.
After all, it is just a C implementation of an ABI described in the
Intel manual, and there are only a handful of ways to actually do that
and also end up something which compiles.
The extra comments and macros however, are more dubious.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [XTF PATCH 02/16] vvmx: test whether MSR_IA32_FEATURE_CONTROL is set correctly
On 19/12/16 02:20, Haozhong Zhang wrote: > On 12/16/16 16:17 +, Andrew Cooper wrote: >> If so, I don't expect Xen's behaviour to ever change. We'd prefer to do >> all configuration like that at the toolstack/hypervisor level, rather >> than the in-guest firmware (if any). >> > > OK, then TODO is not necessary at all. My concern was that Intel SDM > says MSR_IA32_FEATURE_CONTROL is cleared to zero when a logical > processor is reset that is not consistent to what Xen currently > presents in HVM domains. The firmware line is somewhat blurred in virtualisation. Even with reset, I'd still expect Xen to handle this part of the state, in accordance with the toolstack settings. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 204 - x86: Mishandling of SYSCALL singlestep during emulation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory XSA-204 x86: Mishandling of SYSCALL singlestep during emulation ISSUE DESCRIPTION = The typical behaviour of singlestepping exceptions is determined at the start of the instruction, with a #DB trap being raised at the end of the instruction. SYSCALL (and SYSRET, although we don't implement it) behave differently because the typical behaviour allows userspace to escalate its privilege. (This difference in behaviour seems to be undocumented.) Xen wrongly raised the exception based on the flags at the start of the instruction. IMPACT == Guest userspace which can invoke the instruction emulator can use this flaw to escalate its privilege to that of the guest kernel. VULNERABLE SYSTEMS == All Xen versions are affected. The vulnerability is only exposed to 64-bit x86 HVM guests. On Xen 4.6 and earlier the vulnerability is exposed to all guest user processes, including unprivileged processes, in such guests. On Xen 4.7 and later, the vulnerability is exposed only to guest user processes granted a degree of privilege (such as direct hardware access) by the guest administrator; or, to all user processes when the VM has been explicitly configured with a non-default cpu vendor string (in xm/xl, this would be done with a `cpuid=' domain config option). A 64-bit guest kernel which uses an IST for #DB handling will most likely mitigate the issue, but will have a single unexpected #DB exception frame to deal with. This in practice means that Linux is not vulnerable. The vulnerability is not exposed to 32-bit HVM guests. This is because the emulation bug also matches real hardware behaviour, and a 32-bit guest kernel using SYSCALL will already have to be using a Task Gate for handling #DB to avoid being susceptible to an escalation of privilege. The vulnerability is not exposed to PV guests. ARM systems are not vulnerable. MITIGATION == There is no known mitigation. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa204.patch xen-unstable xsa204-4.8.patch Xen 4.8.x xsa204-4.7.patch Xen 4.7.x, Xen 4.6.x xsa204-4.5.patch Xen 4.5.x, Xen 4.4.x $ sha256sum xsa204* 251c33905f86d386cc07240041108ec0664e5e9dddb2b88685d9b4b8ca7fdc24 xsa204.patch e523b65ba122c8e22d32004d2035facaf06295094fdc8b67c151b6f44799ef0b xsa204-4.5.patch d0359f26e9be783672896200e14d85a3111c29d7da580313b593fca04688fef2 xsa204-4.7.patch fa2a69682868104b6263655abbfc6b326f76deebdac3273b4b65da6673f5d977 xsa204-4.8.patch $ NOTE REGARDING EMBARGO == This issue was discussed publicly on qemu-devel before its impact was realised. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYV/5uAAoJEIP+FMlX6CvZnxgIAMXcpEN0qejTe50dAP/gSzzP edi76o/LNGaQBdFRVLvIasRna2TZSXhBNbHPEcAQLPq6pTfQG/HiqdVtftaaaoaG dvNhuDBdZaa1/fmhCV1P+t9vaipp3U3yK2s0eiSJLXp3nGqkgjSSmZloYY0bevDN DJ0uZ7uWkvyN6Tkl6R/h3h9PsgIKPIQBIyBuT2zYPf/JAjBD27ZYX11F9JvVMmt3 JH/AbvJwUsaqNG3teLg+tioQPwHwkZCdxOhG+v2Y3CeqQ1bvNCb5emLtpXFO9h0w kZNh88gT1mwbxDWbF3Ek/OhHbOHosfxi9kn8ib5Yu0P8xRmvYhQHMeQDa/rt9Y0= =OVcU -END PGP SIGNATURE- xsa204.patch Description: Binary data xsa204-4.5.patch Description: Binary data xsa204-4.7.patch Description: Binary data xsa204-4.8.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [XTF PATCH 03/16] vvmx: test whether MSR_IA32_VMX_BASIC is set correctly
On 19/12/16 02:44, Haozhong Zhang wrote:
>>> +passed = false;
>>> +}
>>> +
>>> +vmcs_size = (vmx_basic & VMX_BASIC_VMCS_SIZE_MASK) >> 32;
>>> +if ( vmcs_size > PAGE_SIZE )
>>> +{
>>> +xtf_failure("Fail: "
>>> +"VMCS size (%"PRIu64") in MSR_IA32_VMX_BASIC is
>>> > %ld\n",
>>> +vmcs_size, PAGE_SIZE);
>>> +passed = false;
>>> +}
>>> +else if ( vmcs_size == 0 )
>>> +{
>>> +xtf_failure("Fail: VMCS size in MSR_IA32_VMX_BASIC cannot
>>> be 0\n");
>>> +passed = false;
>>> +}
>>> +
>>> +/* test is running on hvm64, so this bit should be 0 */
>>> +if ( vmx_basic & VMX_BASIC_32BIT_ADDRESSES )
>>
>> There is nothing in principle wrong with Xen setting this bit. It would
>> be odd certainly, but not erroneous.
>>
>
> The reason I added this test is because Intel SDM Vol 3, Appendix A.1
> Basic VMX Information says "This bit (bit 48) is always 0 for
> processors that support Intel 64 architecture."
Right, and Xen, being 64bit only, can expect to find this bit always clear.
>
> I don't know whether there is SW in real world that depends on the
> consistency between this bit and Intel SDM, but if there is any, it
> might be confused by an odd configuration. So I think it's still worth
> to keep such test.
It is a valid administrator choice to restrict a VM to 32bit-only by
hiding the long mode bit. Under those circumstances, it would be
logical to expect this bit to be set in the virtual environment, despite
not being required at the physical level.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [licensing] was: [XTF PATCH 04/16] vvmx: add C wrappers of vmxon/vmread/vmptrld
Lars Kurth writes ("Re: [licensing] was: [XTF PATCH 04/16] vvmx: add C wrappers
of vmxon/vmread/vmptrld"):
> @Andy: you may want to have a chat with Ian and check whether the MPL 2.0
> may be a better choice for XTF than BSD in this case. I have not looked
> into how copyleft and MPL 2 work together though. Just a thought.
They work badly together. I would avoid the MPL for anything.
BSD2/MIT (ie a permissive licence) is correct for Andy's requirements.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [licensing] was: [XTF PATCH 04/16] vvmx: add C wrappers of vmxon/vmread/vmptrld
On 19/12/16 03:20, Haozhong Zhang wrote:
> On 12/16/16 19:03 +, Andrew Cooper wrote:
>> On 16/12/16 13:43, Haozhong Zhang wrote:
>>> diff --git a/include/arch/x86/hvm/vmx/vmcs.h
>>> b/include/arch/x86/hvm/vmx/vmcs.h
>>> new file mode 100644
>>> index 000..e1a6ef8
>>> --- /dev/null
>>> +++ b/include/arch/x86/hvm/vmx/vmcs.h
>>> @@ -0,0 +1,179 @@
>>> +#ifndef XTF_X86_HVM_VMX_VMCS_H
>>> +#define XTF_X86_HVM_VMX_VMCS_H
>>> +
>>> +/* VMCS field encodings. */
>>> +#define VMCS_HIGH(x) ((x) | 1)
>>> +enum vmcs_field {
>>> +VIRTUAL_PROCESSOR_ID= 0x,
>>> +POSTED_INTR_NOTIFICATION_VECTOR = 0x0002,
>>> +EPTP_INDEX = 0x0004,
>>> +#define GUEST_SEG_SELECTOR(sel) (GUEST_ES_SELECTOR + (sel) * 2) /*
>>> ES ... GS */
>>
>> Unfortunately, there is probably a BSD/GPL licensing issue here.
>>
>> XTF is BSD clause 2 licensed, because a lot of the core microkernel bits
>> are generally useful to other microkernel projects, and I have specific
>> plans to contribute improvements back to the likes of Mini-OS and
>> HVMLoader. I would specifically like to maintain this property.
>>
>> Xen, following its Linux heritage, is strictly GPLv2 (other than the
>> public headers, which are specifically different).
>>
>>
>> Having XTF use the same naming as Xen is convenient for development, and
>> I specifically don't want to get caught up in tricks like renaming
>> constants;
>
> but renaming or taking names from other BSD-licensed projects [1] could
> keep the whole project as purely BSD-licensed.
That would also work.
I also tend to only pull in defines which are actually used, but that is
just personal choice and to keep the size of the commits down.
>
> [1]
> https://github.com/freebsd/freebsd/blob/master/sys/amd64/vmm/intel/vmcs.h
>
>> these names inherit from the architecture manual and calling
>> them anything else would be even worse. If we were to go down this
>> route, being able to keep the header file in sync would be useful, but
>> dual licensing it Xen would be complicated and confusing.
>>
>> BSD and GPL are compatible licenses. One option Ian suggested would be
>> to have a GPL subdirectory in XTF which clearly separates GPL content
>> from BSD content. The resulting tests would become GPL, but the primary
>> distribution method is "git clone && make", so there are no issues
>> there.
>
> If I want to use the BSD-licensed files individually in other
> projects, will I need to keep a GPL license with them?
Only if the GPL file needed to be ported as well. In this case, it is
only the VMX test which uses it, rather than any of the core code.
I don't plan on porting entire files to other projects, but individual
functions certainly. (Having said that, I do plan on moving the entire
vsnprintf() implementation to hvmloader so it can actually format 64bit
integers).
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [XTF PATCH 07/16] vvmx: test vmxon in CPL=3 and out of VMX operation
On 19/12/16 03:35, Haozhong Zhang wrote:
> On 12/16/16 20:33 +, Andrew Cooper wrote:
>> On 16/12/16 13:43, Haozhong Zhang wrote:
>>> diff --git a/tests/vvmx/vmxon.c b/tests/vvmx/vmxon.c
>>> index 31f074c..ca33b3c 100644
>>> --- a/tests/vvmx/vmxon.c
>>> +++ b/tests/vvmx/vmxon.c
>>> @@ -28,11 +28,42 @@ static bool test_vmxon_novmxe(void)
>>>VMXERR_FAULT, EXINFO_SYM(UD, 0), 0);
>>> }
>>>
>>> +static unsigned long vmxon_in_user(void)
>>
>> I'd name this user_vmxon() as it is slightly shorter, but I'm not
>> terribly fussed.
>>
>>> +{
>>> +exinfo_t fault;
>>> +unsigned long ret = vmxon((uint64_t)vmxon_region, &fault);
>>> +
>>> +return (ret << 32) | fault;
>>> +}
>>> +
>>> +/**
>>> + * vmxon in CPL=3 and out of VMX operation
>>> + *
>>> + * Expect: #GP(0)
>>> + */
>>> +static bool test_vmxon_in_user(void)
>>
>> Similarly, test_user_vmxon()
>>
>
> I'll turn to shorter names.
>
>>> +{
>>> +clear_vmcs(vmxon_region, get_vmcs_revid());
>>> +
>>> +unsigned long ret = exec_user(vmxon_in_user);
>>> +uint8_t err = (ret >> 32) & 0xff;
>>> +exinfo_t fault = ret & 0x;
>>> +
>>> +return handle_vmxinsn_err(__func__, err, fault,
>>> + VMXERR_FAULT, EXINFO_SYM(GP, 0), 0);
>>> +}
>>> +
>>> bool test_vmxon(void)
>>> {
>>> if ( !test_vmxon_novmxe() )
>>> return false;
>>
>> Your subject says out of VMX operation, but the implementation is inside
>> VMX operation.
>>
>
> vmxon in test_vmxon_novmxe() fails if test_vmxon_novmxe() return true,
> so here we are still out of VMX operation.
Very good point. Its obvious now you point it out. Sorry for the noise.
~andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xsm: allow relevant permission during migrate and gpu-passthrough.
On 12/14/16 3:09 PM, Daniel De Graaf wrote:
> On 12/12/2016 09:00 AM, Anshul Makkar wrote:
>> During guest migrate allow permission to prevent
>> spurious page faults.
>> Prevents these errors:
>> d73: Non-privileged (73) attempt to map I/O space
>>
>> avc: denied { set_misc_info } for domid=0 target=11
>> scontext=system_u:system_r:dom0_t
>> tcontext=system_u:system_r:domU_t tclass=domain
>>
>> GPU passthrough for hvm guest:
>> avc: denied { send_irq } for domid=0 target=10
>> scontext=system_u:system_r:dom0_t
>> tcontext=system_u:system_r:domU_t tclass=hvm
>>
>> Signed-off-by: Anshul Makkar
>
> Acked-by: Daniel De Graaf
>
Daniel,
Should this be backported to 4.8?
--
Doug Goldstein
signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [XTF PATCH 07/16] vvmx: test vmxon in CPL=3 and out of VMX operation
On 19/12/16 03:35, Haozhong Zhang wrote:
>
>>> +{
>>> +clear_vmcs(vmxon_region, get_vmcs_revid());
>>> +
>>> +unsigned long ret = exec_user(vmxon_in_user);
>>> +uint8_t err = (ret >> 32) & 0xff;
>>> +exinfo_t fault = ret & 0x;
>>> +
>>> +return handle_vmxinsn_err(__func__, err, fault,
>>> + VMXERR_FAULT, EXINFO_SYM(GP, 0), 0);
>>> +}
>>> +
>>> bool test_vmxon(void)
>>> {
>>> if ( !test_vmxon_novmxe() )
>>> return false;
>>
>> Your subject says out of VMX operation, but the implementation is inside
>> VMX operation.
>>
>
> vmxon in test_vmxon_novmxe() fails if test_vmxon_novmxe() return true,
> so here we are still out of VMX operation.
Very good point. Its obvious now you point it out. Sorry for the noise.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [XTF PATCH 14/16] vvmx: test vmxon in VMX root w/ CPL = 3 and w/o current VMCS
On 19/12/16 03:46, Haozhong Zhang wrote: >> However, I am not sure of its purpose. Why cant you reuse the previous >> host state area? >> > > Intel SDM says SW should not access or modify the VXMON rgion of a > logical processor between vmxon and vmxoff. Though I have tested on > real hardware whether reusing VMXON region would cause any trouble, I > still want to exclude that possibility/noise from this test. That is a good reason. Could you please add a comment to this effect? ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [XTF PATCH 00/16] Add test cases for nested vmxon
On 19/12/16 01:44, Haozhong Zhang wrote: > On 12/16/16 14:12 +, Andrew Cooper wrote: >> On 16/12/16 13:43, Haozhong Zhang wrote: >>> This patch series starts to add a test selection "test-hvm64-vvmx" for >>> nested VMX. This first series focuses mostly on nested vmxon. >>> >>> * Patch 01 - 03 test the basic environment (cpuid and MSR). >>> >>> * Patch 04 - 05 add functions to execute VMX instructions and to >>> collect and handle errors. >>> >>> * Patch 06 - 16 construct a bunch of test cases for nested vmxon per >>> its pseudo code in section "VMXON - Enter VMX Operation" of Intel >>> SDM Vol 3. >> >> Thankyou very much for contributing this. >> >> As a general question though, how have you found using XTF? I am eager >> for any feedback, especially if you found problem areas. >> > > Lars Kurth and George Dunlap visited out site recently and mentioned > XTF. When I started to look at and fix nested VMX bugs, I used KVM as > L1 hypervisor. However, KVM is sometimes too heavy and not quite > controllable for the quick verification and test, so I turned to XTF and > found it was exactly what I wanted for this purpose. > > So far I feel XTF is pretty handy for me to construct quick and short > test cases for VMX instructions. This reason is precisely why I developed it to start with. I now find that I do almost all my debugging and development work with it. > > One feature I desire is to configure the dependency among tests. Take > this patch series as an example: some tests in patch 09 - 16 make > sense only when VMX is available. If I can indicate they depend on the > successful result of tests in patch 01 - 03, then I can separate patch > 01 - 03 and patch 09 - 16 into two test selections, and will not need > to introduce additional code in patch 09 - 16 to check the availability > of VMX. Do you mean dependencies between specific test functions? From XTF's point of view, each microkernel constitutes a single test with an overall result, which typically consists of multiple test steps. Within a single microkernel, you are free to make some of the test steps conditional. Particularly when testing bits which differ subtly between Intel and AMD, I find it common to have test steps conditional on cpu_has_*. One thing I tend to do which I notice you haven't is that I tend to have a printk() before major test steps so in the success case, there is a bit of a log of what was tested. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [XTF PATCH 00/16] Add test cases for nested vmxon
On 19/12/16 05:31, Haozhong Zhang wrote: > On 12/16/16 21:26 +, Andrew Cooper wrote: >> On 16/12/16 13:43, Haozhong Zhang wrote: >>> This patch series starts to add a test selection "test-hvm64-vvmx" for >>> nested VMX. This first series focuses mostly on nested vmxon. >>> >>> * Patch 01 - 03 test the basic environment (cpuid and MSR). >>> >>> * Patch 04 - 05 add functions to execute VMX instructions and to >>> collect and handle errors. >>> >>> * Patch 06 - 16 construct a bunch of test cases for nested vmxon per >>> its pseudo code in section "VMXON - Enter VMX Operation" of Intel >>> SDM Vol 3. >>> >> >> Thankyou for this series. I have reviewed it now, and have no major >> problems. It is in quite good shape, other than the licensing concerns >> with patch 4. >> >> One limitation (because I haven't gotten around to implementing it yet) >> is that once a test is accepted, it can't be logically extended, because >> it isn't bisection-safe as far as OSSTest is concerned. >> > > I'm going to add more test cases in the process of fixing nested VMX, > so I think I'd better to put each case in a single test, instead of > all cases in one test-hvm64-vvmx. Ah - this clarifies what you mean by dependences of tests on the other thread. At the moment there is an implicit dependency used by both automated test systems running XTF at the moment, which says that a test-$ENV-$foo shouldn't be run if the test-$ENV-selftest didn't complete successfully. I haven't yet encountered a need for other tests to be co-dependent. Let me consider how this might be made to work. > >> I will prioritise my work to introduce the test-revision plan, which >> will allow the OSSTest bisector to work properly in the case that new >> functionality in a test causes a previously-passing scenario to now >> fail. >> >> Is this a complete set of vmxon scenarios, or are you working on more? >> Some which come to mind are: >> >> * a register operand (to check that Xen decodes properly and rejects the >> instruction) > > I'll add this one, and > > * vmxon w/ nestedhvm=0. You should probably look into using a test variation to explicitly set the test configuration to =0 and =1 See the invlpg and pv-iopl tests for examples of this. > >> * duplicate vmxon in root operation >> >> Another area I had on my nested-virt plan was to allow rather finer >> grain configuration of the vmx options, but that depends on the start of >> the MSR levelling work, which is still blocked behind getting enough >> time to finish the CPUID levelling plans. >> > > I'll keep this possible change in my mind while I'm preparing test > cases which use CPUID/MSR/... to detect the environment instead of > replying on assumptions only satisfied on the current Xen implementation. > >> In particular, I eventually want an ability for fine-grained toolstack >> settings of the available VMX configuration (these being a subset of the >> MSRs in the system), (all subject to auditing by Xen to keep it within >> hardware and supported bounds), at which point it would be plausible to >> spin up a VM, asking for VMX_BASIC_32BIT_ADDRESSES, and checking that >> suitable limits were observed/enforced inside the VM. >> > > I do not quite understand the purpose for the fine-grained VMX > options. Is it to provide users with a chance to workaround bugs in > certain parts of nested virtualization? I have two usecases in mind. First is being able to check that Xen functions correctly when certain VMX features are unavailable. Recently, we have found a number of security issues which only affect older hardware, and older hardware is getting harder and harder to come by. Using fine grained features can simulate older hardware in some cases. Second, and more importantly, that I need to eventually make this all work with live migration, including between non-identical hardware. Therefore, the fine-grained nature would be used to implement feature levelling. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] x86/emul: Bugfixes to SYSCALL emulation
Introduce vendor_is() to allow emulation to have vendor-specific
behaviour. Adjust the SYSCALL behaviour on Intel to raise #UD when
executed outside of 64bit mode.
in_longmode() has different return semantics from rc, so use a separate
integer for the purpose.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/x86_emulate/x86_emulate.c | 54 ++
1 file changed, 49 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c
b/xen/arch/x86/x86_emulate/x86_emulate.c
index 165eebb..419c2da 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1327,6 +1327,45 @@ static bool vcpu_has(
#define host_and_vcpu_must_have(feat) vcpu_must_have(feat)
#endif
+#define X86_VENDOR_INTEL 0
+#define X86_VENDOR_AMD 2
+
+static bool vendor_is(
+struct x86_emulate_ctxt *ctxt,
+const struct x86_emulate_ops *ops,
+int vendor)
+{
+unsigned int eax = 0, ebx = 0, ecx = 0, edx = 0;
+int rc = X86EMUL_OKAY;
+
+fail_if(!ops->cpuid);
+rc = ops->cpuid(&eax, &ebx, &ecx, &edx, ctxt);
+if ( rc == X86EMUL_OKAY )
+{
+switch ( vendor )
+{
+case X86_VENDOR_INTEL:
+return (ebx == 0x756e6547u && /* "GenuineIntel" */
+ecx == 0x6c65746eu &&
+edx == 0x49656e69u);
+
+case X86_VENDOR_AMD:
+return (ebx == 0x68747541u && /* "AuthenticAMD" */
+ecx == 0x444d4163u &&
+edx == 0x69746e65u);
+default:
+rc = ~X86EMUL_OKAY;
+break;
+}
+}
+
+ done:
+return rc == X86EMUL_OKAY;
+}
+
+#define vendor_is_intel() vendor_is(ctxt, ops, X86_VENDOR_INTEL)
+#define vendor_is_amd() vendor_is(ctxt, ops, X86_VENDOR_AMD)
+
static int
in_longmode(
struct x86_emulate_ctxt *ctxt,
@@ -4623,10 +4662,15 @@ x86_emulate(
break;
}
-case X86EMUL_OPC(0x0f, 0x05): /* syscall */ {
+case X86EMUL_OPC(0x0f, 0x05): /* syscall */
+{
uint64_t msr_content;
+#ifdef __x86_64__
+int lm;
+#endif
-generate_exception_if(!in_protmode(ctxt, ops), EXC_UD);
+generate_exception_if(!in_protmode(ctxt, ops) ||
+ (vendor_is_intel() && !mode_64bit()), EXC_UD);
/* Inject #UD if syscall/sysret are disabled. */
fail_if(ops->read_msr == NULL);
@@ -4645,10 +4689,10 @@ x86_emulate(
sreg.attr.bytes = 0xc93; /* G+DB+P+S+Data */
#ifdef __x86_64__
-rc = in_longmode(ctxt, ops);
-if ( rc < 0 )
+lm = in_longmode(ctxt, ops);
+if ( lm < 0 )
goto cannot_emulate;
-if ( rc )
+if ( lm )
{
cs.attr.bytes = 0xa9b; /* L+DB+P+S+Code */
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] x86/hvm: Don't emulate all instructions hitting the #UD intercept
Having the instruction emulator fill in all #UDs when using FEP is unhelpful
when trying to test emulation behaviour against hardware.
Restrict emulation from the #UD intercept to the cross-vendor case, and when a
postive Forced Emulation Prefix has been identified.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/hvm/hvm.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 73d24df..12a6f46 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4002,13 +4002,15 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t
msr_content,
void hvm_ud_intercept(struct cpu_user_regs *regs)
{
+struct vcpu *cur = current;
+bool should_emulate =
+cur->domain->arch.x86_vendor != boot_cpu_data.x86_vendor;
struct hvm_emulate_ctxt ctxt;
hvm_emulate_init_once(&ctxt, regs);
if ( opt_hvm_fep )
{
-struct vcpu *cur = current;
const struct segment_register *cs = &ctxt.seg_reg[x86_seg_cs];
uint32_t walk = (ctxt.seg_reg[x86_seg_ss].attr.fields.dpl == 3)
? PFEC_user_mode : 0;
@@ -4032,9 +4034,17 @@ void hvm_ud_intercept(struct cpu_user_regs *regs)
regs->eip = regs->_eip;
add_taint(TAINT_HVM_FEP);
+
+should_emulate = true;
}
}
+if ( !should_emulate )
+{
+hvm_inject_hw_exception(TRAP_invalid_op, X86_EVENT_NO_EC);
+return;
+}
+
switch ( hvm_emulate_one(&ctxt) )
{
case X86EMUL_UNHANDLEABLE:
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/time: Adjust init-time handling of pit0_ticks
There is no need for the volatile cast in the timer interrupt. pit0_ticks has
external linkage, preventing the compiler from eliding the update. This
reduces the generated assembly from a read, local modify, write to a single
add instruction.
Drop the memory barriers from timer_irq_works(), as they are not needed.
pit0_ticks is only modified by timer_interrupt() running on the same CPU, so
that is required is a volatile reference to prevent the compiler from eliding
the second read.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/io_apic.c | 6 ++
xen/arch/x86/time.c| 2 +-
xen/include/xen/lib.h | 2 ++
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c
index 33e5927..f989978 100644
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -1485,8 +1485,7 @@ static int __init timer_irq_works(void)
{
unsigned long t1, flags;
-t1 = pit0_ticks;
-mb();
+t1 = ACCESS_ONCE(pit0_ticks);
local_save_flags(flags);
local_irq_enable();
@@ -1501,8 +1500,7 @@ static int __init timer_irq_works(void)
* might have cached one ExtINT interrupt. Finally, at
* least one tick may be lost due to delays.
*/
-mb();
-if (pit0_ticks - t1 > 4)
+if ( (ACCESS_ONCE(pit0_ticks) - t1) > 4 )
return 1;
return 0;
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index cb6939e..f160c01 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -197,7 +197,7 @@ static void timer_interrupt(int irq, void *dev_id, struct
cpu_user_regs *regs)
return;
/* Only for start-of-day interruopt tests in io_apic.c. */
-(*(volatile unsigned long *)&pit0_ticks)++;
+pit0_ticks++;
/* Rough hack to allow accurate timers to sort-of-work with no APIC. */
if ( !cpu_has_apic )
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index d1171b7..1976e4b 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -56,6 +56,8 @@
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]) + __must_be_array(x))
+#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
+
#define MASK_EXTR(v, m) (((v) & (m)) / ((m) & -(m)))
#define MASK_INSR(v, m) (((v) * ((m) & -(m))) & (m))
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86: fix asm() constraint in clear_user()
Commit 2fdf5b2554 ("x86: streamline copying to/from user memory")
wrongly used "g" here, when it obviously needs to be a register.
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/usercopy.c
+++ b/xen/arch/x86/usercopy.c
@@ -141,7 +141,7 @@ unsigned clear_user(void __user *to, uns
_ASM_EXTABLE(0b,3b)
_ASM_EXTABLE(1b,2b)
: [cnt] "=&c" (n), [to] "+D" (to)
-: [bytes] "g" (n & (BYTES_PER_LONG - 1)),
+: [bytes] "r" (n & (BYTES_PER_LONG - 1)),
[longs] "0" (n / BYTES_PER_LONG), "a" (0) );
clac();
}
x86: fix asm() constraint in clear_user()
Commit 2fdf5b2554 ("x86: streamline copying to/from user memory")
wrongly used "g" here, when it obviously needs to be a register.
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/usercopy.c
+++ b/xen/arch/x86/usercopy.c
@@ -141,7 +141,7 @@ unsigned clear_user(void __user *to, uns
_ASM_EXTABLE(0b,3b)
_ASM_EXTABLE(1b,2b)
: [cnt] "=&c" (n), [to] "+D" (to)
-: [bytes] "g" (n & (BYTES_PER_LONG - 1)),
+: [bytes] "r" (n & (BYTES_PER_LONG - 1)),
[longs] "0" (n / BYTES_PER_LONG), "a" (0) );
clac();
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/time: Adjust init-time handling of pit0_ticks
>>> On 19.12.16 at 17:38, wrote:
> There is no need for the volatile cast in the timer interrupt. pit0_ticks has
> external linkage, preventing the compiler from eliding the update. This
> reduces the generated assembly from a read, local modify, write to a single
> add instruction.
I don't think external linkage is the reason here, considering the
effects of whole-program-optimization.
> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -1485,8 +1485,7 @@ static int __init timer_irq_works(void)
> {
> unsigned long t1, flags;
>
> -t1 = pit0_ticks;
> -mb();
> +t1 = ACCESS_ONCE(pit0_ticks);
Any reason not to use the available read_atomic() here?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86: fix asm() constraint in clear_user()
On 19/12/16 16:44, Jan Beulich wrote:
> Commit 2fdf5b2554 ("x86: streamline copying to/from user memory")
> wrongly used "g" here, when it obviously needs to be a register.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen/x86: Improve hypercall page writing
Use memcpy() rather than individual writes with explicit casts. The __builtin_memcpy() wrapper does a better job at combining adjacent writes into a larger word size. This results in better generated assembly. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Jun Nakajima CC: Kevin Tian CC: Boris Ostrovsky CC: Suravee Suthikulpanit --- xen/arch/x86/hvm/svm/svm.c | 10 +- xen/arch/x86/hvm/vmx/vmx.c | 10 +- xen/arch/x86/x86_64/compat/traps.c | 15 +-- xen/arch/x86/x86_64/traps.c| 31 ++- 4 files changed, 37 insertions(+), 29 deletions(-) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 811ea4e..962667a 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -888,12 +888,12 @@ static void svm_init_hypercall_page(struct domain *d, void *hypercall_page) continue; p = (char *)(hypercall_page + (i * 32)); -*(u8 *)(p + 0) = 0xb8; /* mov imm32, %eax */ +*(u8 *)(p + 0) = 0xb8; /* mov $, %eax */ *(u32 *)(p + 1) = i; -*(u8 *)(p + 5) = 0x0f; /* vmmcall */ -*(u8 *)(p + 6) = 0x01; -*(u8 *)(p + 7) = 0xd9; -*(u8 *)(p + 8) = 0xc3; /* ret */ +memcpy(p + 5, + "\x0f\x01\xd9" /* vmmcall */ + "\xc3", /* ret */ + 4); } /* Don't support HYPERVISOR_iret at the moment */ diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index d50d49e..c0e62a2 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -1295,12 +1295,12 @@ static void vmx_init_hypercall_page(struct domain *d, void *hypercall_page) continue; p = (char *)(hypercall_page + (i * 32)); -*(u8 *)(p + 0) = 0xb8; /* mov imm32, %eax */ +*(u8 *)(p + 0) = 0xb8; /* mov $, %eax */ *(u32 *)(p + 1) = i; -*(u8 *)(p + 5) = 0x0f; /* vmcall */ -*(u8 *)(p + 6) = 0x01; -*(u8 *)(p + 7) = 0xc1; -*(u8 *)(p + 8) = 0xc3; /* ret */ +memcpy(p + 5, + "\x0f\x01\xc1" /* vmmcall */ + "\xc3", /* ret */ + 4); } /* Don't support HYPERVISOR_iret at the moment */ diff --git a/xen/arch/x86/x86_64/compat/traps.c b/xen/arch/x86/x86_64/compat/traps.c index 95c5cb3..8b03291 100644 --- a/xen/arch/x86/x86_64/compat/traps.c +++ b/xen/arch/x86/x86_64/compat/traps.c @@ -388,8 +388,10 @@ static void hypercall_page_initialise_ring1_kernel(void *hypercall_page) p = (char *)(hypercall_page + (i * 32)); *(u8 *)(p+ 0) = 0xb8;/* mov $,%eax */ *(u32 *)(p+ 1) = i; -*(u16 *)(p+ 5) = (HYPERCALL_VECTOR << 8) | 0xcd; /* int $xx */ -*(u8 *)(p+ 7) = 0xc3;/* ret */ +memcpy(p + 5, + "\xcd\x82" /* int $HYPERCALL_VECTOR */ + "\xc3",/* ret */ + 3); } /* @@ -398,10 +400,11 @@ static void hypercall_page_initialise_ring1_kernel(void *hypercall_page) * calling it. */ p = (char *)(hypercall_page + (__HYPERVISOR_iret * 32)); -*(u8 *)(p+ 0) = 0x50;/* push %eax */ -*(u8 *)(p+ 1) = 0xb8;/* mov $__HYPERVISOR_iret,%eax */ -*(u32 *)(p+ 2) = __HYPERVISOR_iret; -*(u16 *)(p+ 6) = (HYPERCALL_VECTOR << 8) | 0xcd; /* int $xx */ +memcpy(p, + "\x50" /* push %eax */ + "\xb8\x17\x00\x00\x00" /* mov $__HYPERVISOR_iret, %eax */ + "\xcd\x82",/* int $HYPERCALL_VECTOR */ + 8); } /* diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c index fc8cde6..7a586cd 100644 --- a/xen/arch/x86/x86_64/traps.c +++ b/xen/arch/x86/x86_64/traps.c @@ -591,14 +591,18 @@ static void hypercall_page_initialise_ring3_kernel(void *hypercall_page) continue; p = (char *)(hypercall_page + (i * 32)); -*(u8 *)(p+ 0) = 0x51;/* push %rcx */ -*(u16 *)(p+ 1) = 0x5341; /* push %r11 */ -*(u8 *)(p+ 3) = 0xb8;/* mov $,%eax */ +memcpy(p, + "\x51" /* push %rcx */ + "\x41\x53" /* push %r11 */ + "\xb8", /* mov $,%eax */ + 4); *(u32 *)(p+ 4) = i; -*(u16 *)(p+ 8) = 0x050f; /* syscall */ -*(u16 *)(p+10) = 0x5b41; /* pop %r11 */ -*(u8 *)(p+12) = 0x59;/* pop %rcx */ -*(u8 *)(p+13) = 0xc3;/* ret */ +memcpy(p + 8, + "\x0f\x05" /* syscall */ + "\x41\x5b" /* pop %r11 */ + "\x59" /* pop %rcx */ + "\xc3", /* ret */ + 6); } /* @@ -607,12 +611,13 @@ static void hypercall_page_initialise_ring3_kernel(void *hypercall_page) * calling it. */ p = (char *)(hypercall_page + (__HYPERVISOR_iret * 32)); -*(u8 *)(p+ 0) = 0x51;/* push %rcx
Re: [Xen-devel] [PATCH] x86/time: Adjust init-time handling of pit0_ticks
On 19/12/16 16:51, Jan Beulich wrote:
On 19.12.16 at 17:38, wrote:
>> There is no need for the volatile cast in the timer interrupt. pit0_ticks
>> has
>> external linkage, preventing the compiler from eliding the update. This
>> reduces the generated assembly from a read, local modify, write to a single
>> add instruction.
> I don't think external linkage is the reason here, considering the
> effects of whole-program-optimization.
In the case of whole-program-optimisation, the compiler would observe
that one function wrote to the variable, and one function read from it.
I presume that is also sufficient to prevent the eliding?
>
>> --- a/xen/arch/x86/io_apic.c
>> +++ b/xen/arch/x86/io_apic.c
>> @@ -1485,8 +1485,7 @@ static int __init timer_irq_works(void)
>> {
>> unsigned long t1, flags;
>>
>> -t1 = pit0_ticks;
>> -mb();
>> +t1 = ACCESS_ONCE(pit0_ticks);
> Any reason not to use the available read_atomic() here?
ACCESS_ONCE() doesn't force an explicit reg/mem mov instruction,
although in practice it doesn't make any difference in this case.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 204 (CVE-2016-10013) - x86: Mishandling of SYSCALL singlestep during emulation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-10013 / XSA-204 version 2 x86: Mishandling of SYSCALL singlestep during emulation UPDATES IN VERSION 2 CVE assigned. ISSUE DESCRIPTION = The typical behaviour of singlestepping exceptions is determined at the start of the instruction, with a #DB trap being raised at the end of the instruction. SYSCALL (and SYSRET, although we don't implement it) behave differently because the typical behaviour allows userspace to escalate its privilege. (This difference in behaviour seems to be undocumented.) Xen wrongly raised the exception based on the flags at the start of the instruction. IMPACT == Guest userspace which can invoke the instruction emulator can use this flaw to escalate its privilege to that of the guest kernel. VULNERABLE SYSTEMS == All Xen versions are affected. The vulnerability is only exposed to 64-bit x86 HVM guests. On Xen 4.6 and earlier the vulnerability is exposed to all guest user processes, including unprivileged processes, in such guests. On Xen 4.7 and later, the vulnerability is exposed only to guest user processes granted a degree of privilege (such as direct hardware access) by the guest administrator; or, to all user processes when the VM has been explicitly configured with a non-default cpu vendor string (in xm/xl, this would be done with a `cpuid=' domain config option). A 64-bit guest kernel which uses an IST for #DB handling will most likely mitigate the issue, but will have a single unexpected #DB exception frame to deal with. This in practice means that Linux is not vulnerable. The vulnerability is not exposed to 32-bit HVM guests. This is because the emulation bug also matches real hardware behaviour, and a 32-bit guest kernel using SYSCALL will already have to be using a Task Gate for handling #DB to avoid being susceptible to an escalation of privilege. The vulnerability is not exposed to PV guests. ARM systems are not vulnerable. MITIGATION == There is no known mitigation. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa204.patch xen-unstable xsa204-4.8.patch Xen 4.8.x xsa204-4.7.patch Xen 4.7.x, Xen 4.6.x xsa204-4.5.patch Xen 4.5.x, Xen 4.4.x $ sha256sum xsa204* 251c33905f86d386cc07240041108ec0664e5e9dddb2b88685d9b4b8ca7fdc24 xsa204.patch e523b65ba122c8e22d32004d2035facaf06295094fdc8b67c151b6f44799ef0b xsa204-4.5.patch d0359f26e9be783672896200e14d85a3111c29d7da580313b593fca04688fef2 xsa204-4.7.patch fa2a69682868104b6263655abbfc6b326f76deebdac3273b4b65da6673f5d977 xsa204-4.8.patch $ NOTE REGARDING EMBARGO == This issue was discussed publicly on qemu-devel before its impact was realised. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYWBMjAAoJEIP+FMlX6CvZe2wH/i/tAxpXbIc0xhhA5L6nlGJ9 fYZY0C6GuujTFIPmF40dMKIZieB+zKxiBseYHw4dHSzs3hbLbYhcP2Qgr2WJ2uJw 3zuS+OAtOlwzl+KRu6WUZPMf5JTAZp+kWJny3qCymUzXqz4OmUzsqHAORYyAjVi/ RN0lqgnkoTrGV8YS7fEUC5mB6PQGaEerJWFRLmaEmxV0th70oTuSGELjZ7rJdJg/ 92BZ/GVQNspuSgZCJyEhwSfzBgF1MvAKjUZafh9+0/2G5Ab0Z71ikRX/l8RWop9E 7B+KC6zeG6DukPME2sJTuL+b0EmZyfOwewDnbdGbzb2nCfOhwsoHvzrAhF9rYwI= =ypHy -END PGP SIGNATURE- xsa204.patch Description: Binary data xsa204-4.5.patch Description: Binary data xsa204-4.7.patch Description: Binary data xsa204-4.8.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf baseline-only test] 68244: regressions - FAIL
This run is configured for baseline tests only. flight 68244 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68244/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 68241 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail like 68241 version targeted for testing: ovmf 15dae68589243726f0374e535a77e76444096bad baseline version: ovmf a35dc6499beb0b76c340379a06dff74a8d38095a Last test of basis68241 2016-12-19 04:51:26 Z0 days Testing same since68244 2016-12-19 14:48:58 Z0 days1 attempts People who touched revisions under test: Dandan Bi Jiewen Yao Michael Kinney Ruiyu Ni jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 15dae68589243726f0374e535a77e76444096bad Author: Ruiyu Ni Date: Mon Dec 19 15:27:38 2016 +0800 ShellBinPkg: New Shell binaries for IA32 and X64 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni commit 254e7cc32ce93c2a8f32c3b73563a145e65cf648 Author: Ruiyu Ni Date: Mon Dec 19 14:52:38 2016 +0800 FatBinPkg: New EnhancedFatDxe binaries for IA32, X64, EBC and IPF Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni commit d2fc7711136a13ea3ea8e00de6d9651507b8ed50 Author: Jiewen Yao Date: Thu Nov 24 13:36:56 2016 +0800 UefiCpuPkg/PiSmmCpu: Add SMM Comm Buffer Paging Protection. This patch sets the normal OS buffer EfiLoaderCode/Data, EfiBootServicesCode/Data, EfiConventionalMemory, EfiACPIReclaimMemory to be not present after SmmReadyToLock. To access these region in OS runtime phase is not a good solution. Previously, we did similar check in SmmMemLib to help SMI handler do the check. But if SMI handler forgets the check, it can still access these OS region and bring risk. So here we enforce the policy to prevent it happening. Cc: Jeff Fan Cc: Michael D Kinney Cc: Laszlo Ersek Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao Reviewed-by: Jeff Fan commit 09119a00cccaa08b28b7e2449998ba4c7aa4b0f8 Author: Michael Kinney Date: Tue Nov 29 06:36:51 2016 +0800 UefiCpuPkg/SmmCpuFeaturesLibStm: Add STM library instance Add a new instances of the SmmCpuFeaturesLib that is used by platforms to enable the SMI Transfer Monitor(STM) feature. This new instance is in the same directory as the default SmmCpuFeaturesLib instance in order to share source files. The DSC file is updated to build both SmmCpuFeatureLib instances and to build two versions of the PiSmmCpuDxeSmm module using each of the SmmCpuFeatureLib instances. Cc: Jiewen Yao Cc: Jeff Fan Cc: Feng Tian Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney Reviewed-by: Jiewen Yao Reviewed-by: Jeff Fan commit 4c6351db25eaf24335933ce3499258d7b48a57b2 Author: Michael Kinney Date: Thu Nov 17 20:54:19 2016 -0800 UefiCpuPkg/SmmCpuFeaturesLib: Split into two files Split the default implementation of the SmmCpuFeaturesLib into two files to prepare for the addition of the STM specific SmmCpuFeaturesLib implementation. The STM specific implementation installs a different SMI entry handler and initialize the MSEG specific MSR at the end of SmmCpuFeaturesInitializeProcessor(). This patch does not introduce any functional changes to the default implementation of the SmmCpuFeaturesLib. Cc: Jiewen Yao Cc: Jeff Fan
Re: [Xen-devel] [PATCH] xen/arm: fix rank/vgic locks inversion bug
Hi Stefano,
On 17/12/2016 02:13, Stefano Stabellini wrote:
On Fri, 16 Dec 2016, Stefano Stabellini wrote:
On Fri, 16 Dec 2016, Julien Grall wrote:
Hi Stefano,
On 16/12/16 00:08, Stefano Stabellini wrote:
On Thu, 15 Dec 2016, Julien Grall wrote:
On 15/12/2016 01:04, Stefano Stabellini wrote:
The locking order is: first rank lock, then vgic lock. The order is
respected everywhere, except for gic_update_one_lr.
gic_update_one_lr is called with the vgic lock held, but it calls
vgic_get_target_vcpu, which tries to obtain the rank lock. This can
cause deadlocks.
We already have a version of vgic_get_target_vcpu that doesn't take the
rank lock: __vgic_get_target_vcpu. Also the only routine that modify
the target vcpu are vgic_store_itargetsr and vgic_store_irouter. They
call vgic_migrate_irq, which already take the vgic lock.
Solve the lock inversion problem, by not taking the rank lock in
gic_update_one_lr (calling __vgic_get_target_vcpu instead of
vgic_get_target_vcpu).
If I look at the callers of gic_update_one_lr, the function gic_clear_lrs
will
not take the rank lock. So from my understanding nobody will take the rank
here.
However __vgic_get_target_vcpu has an ASSERT to check whether the rank
lock
has been taken. So who is taking lock for gic_update_one_lr now?
I should have removed the ASSERT - nobody is taking the rank lock now on
the gic_update_one_lr code path.
Please either keep this ASSERT or update it. But not dropping it, we need to
prevent anyone calling this function without any lock taken at least in debug
build.
The current callers (see vgic_{disable,enable}_irqs) are calling the function
with rank lock taken.
So we need to keep this behavior at least for them.
We make this safe, by placing modifications to
rank->vcpu within regions protected by the vgic lock.
This look unsafe to me. The vgic lock is per-vcpu, but rank->vcpu could be
written/read by any vCPU. So you will never protect rank->vcpu with this
lock.
Did I miss anything?
The vgic lock is per-vcpu, but it is always the vgic lock of the old (old
in the sense, before the interrupt is migrated) vcpu that is taken.
On one hand any vcpu can read/write to itargetsr. Those operations are
protected by the rank lock. However vgic_migrate_irq and writes to
rank->vcpu are protected also by the vgic lock of the old vcpu (first
the rank lock is taken, then the vgic lock of the old vcpu).
I don't think this is true. Any vCPU read/write to itargetsr will be protected
by the vgic lock of the vCPU in rank->vcpu[offset].
For inflight IRQ, the migration will happen when the guest has EOIed the IRQ.
Until this is happening, the guest may have written multiple time in
ITARGETSR.
For instance, let say the guest is requesting to migrate the IRQ from vCPU A
to vCPU B. The vgic lock A will be taken in vgic_store_itargetsr, if the
interrupt is inflight vgic_migrate_irq will set a flag. Now the guest could
decide to migrate the interrupt to vCPU C before the interrupt has been EOIed.
In this case, vgic lock B will be taken.
So we have a mismatch between the lock taken in gic_update_one_lr and
vgic_migrate_irq.
I think the only safe way to fully protect rank->vcpu is taking the rank lock.
It will never change and be accessible from anywhere.
When I submitted this series, I considered this scenario, and I thought
that the existing GIC_IRQ_GUEST_MIGRATING flag should be enough to
protect it, because when GIC_IRQ_GUEST_MIGRATING is set,
vgic_migrate_irq actually returns immediately, without doing anything.
Either GIC_IRQ_GUEST_MIGRATING is not set, and it's the first irq
migration, or GIC_IRQ_GUEST_MIGRATING is set, and vgic_migrate_irq just
returns.
However, as I was writing this explanation to you in more details, I
realized that it is not actually safe. Concurrent accesses to
rank->vcpu, and concurrent calls to irq_set_affinity, can result in the
physical affinity actually set to the intermediate pcpu rather than the
final. As a matter of fact, one of these races affect the code today,
even without this patch series.
Because irq_set_affinity is not called protected by the same lock (e.g
rank or vgic), right?
[...]
2) We run gic_update_one_lr and vgic_store_itargetsr in parallel safely
and locklessly. There might be a way to do it, but it is not easy I
haven't found it yet.
Correct me if I am wrong. There are no restriction to write into
IROUTER/ITARGETSR while an IRQ is pending. So the irq_set_affinity could
be called once at the beginning of vgic_irq_migrate.
We may receive the interrupt on the wrong physical CPU at the beginning.
But it would be the same when writing into IROUTER/ITARGETSR.
This would remove the need to get the rank lock in gic_update_one_lr.
Did I miss anything?
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/7] Remove hardcoded strict -Werror checking
On Sat, Dec 17, 2016 at 7:51 AM, Konrad Rzeszutek Wilk wrote: > On Fri, Dec 16, 2016 at 02:56:01PM -0800, Alistair Francis wrote: >> Signed-off-by: Alistair Francis > > > Why? Hey Konrad, The problem that I have is that we build Xen releases in buildroot. As things change (GCC version usually) new warnings are generated for issues that previously never caused any problems. Instead of constantly fixing these small warnings it is easier to disable Werror. I understand that for development this isn't what you want. I just thought it was worth at least sending this up. Maybe a way to disable Werror when configuring would be the best solution? Thanks, Alistair > > Thanks! >> --- >> Config.mk | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/Config.mk b/Config.mk >> index 3ec7367..e3cda81 100644 >> --- a/Config.mk >> +++ b/Config.mk >> @@ -34,7 +34,7 @@ CONFIG_$(XEN_OS) := y >> SHELL ?= /bin/sh >> >> # Tools to run on system hosting the build >> -HOSTCFLAGS = -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer >> +HOSTCFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer >> HOSTCFLAGS += -fno-strict-aliasing >> >> DISTDIR ?= $(XEN_ROOT)/dist >> -- >> 2.7.4 >> >> >> ___ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/7] tools: Update sys/poll.h to poll.h
On Sat, Dec 17, 2016 at 7:55 AM, Konrad Rzeszutek Wilk wrote: > On Fri, Dec 16, 2016 at 02:56:04PM -0800, Alistair Francis wrote: >> To avoid this build error with newer build systems: > > And what is newer? GCC 5? 6? In this case it is GCC 5. Thanks, Alistair > > Thanks. >> error: #warning redirecting incorrect #include to >> [-Werror=cpp] >> >> Rename sys/poll.h to poll.h >> >> Signed-off-by: Alistair Francis >> --- >> tools/libxl/libxl_internal.h | 2 +- >> tools/tests/xen-access/xen-access.c| 2 +- >> tools/xenstat/libxenstat/src/xenstat_qmp.c | 2 +- >> tools/xentrace/xentrace.c | 2 +- >> 4 files changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h >> index 5f46578..acf9ac2 100644 >> --- a/tools/libxl/libxl_internal.h >> +++ b/tools/libxl/libxl_internal.h >> @@ -38,7 +38,7 @@ >> #include >> >> #include >> -#include >> +#include >> #include >> #include >> #include >> diff --git a/tools/tests/xen-access/xen-access.c >> b/tools/tests/xen-access/xen-access.c >> index 9d4f957..887bcd9 100644 >> --- a/tools/tests/xen-access/xen-access.c >> +++ b/tools/tests/xen-access/xen-access.c >> @@ -36,7 +36,7 @@ >> #include >> #include >> #include >> -#include >> +#include >> >> #include >> #include >> diff --git a/tools/xenstat/libxenstat/src/xenstat_qmp.c >> b/tools/xenstat/libxenstat/src/xenstat_qmp.c >> index a87c937..3fda487 100644 >> --- a/tools/xenstat/libxenstat/src/xenstat_qmp.c >> +++ b/tools/xenstat/libxenstat/src/xenstat_qmp.c >> @@ -14,7 +14,7 @@ >> #include >> #include >> #include >> -#include >> +#include >> #include >> #include >> #include >> diff --git a/tools/xentrace/xentrace.c b/tools/xentrace/xentrace.c >> index f09fe6c..364a6fd 100644 >> --- a/tools/xentrace/xentrace.c >> +++ b/tools/xentrace/xentrace.c >> @@ -24,7 +24,7 @@ >> #include >> #include >> #include >> -#include >> +#include >> #include >> >> #include >> -- >> 2.7.4 >> >> >> ___ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 5/7] tools/blktap2: Update sys/signal.h to signal.h
On Sat, Dec 17, 2016 at 7:56 AM, Konrad Rzeszutek Wilk wrote: > On Fri, Dec 16, 2016 at 02:56:05PM -0800, Alistair Francis wrote: >> To avoid this build error with newer build systems: >> error: #warning redirecting incorrect #include to >> [-Werror=cpp] > > And what is the 'newer build system' you speak off? Sorry I should have specified more there. It's GCC 5 that I am seeing the problem on. Thanks, Alistair > > Thanks! >> >> Rename sys/signal.h to signal.h >> >> Signed-off-by: Alistair Francis >> --- >> tools/blktap2/drivers/tapdisk-server.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/tools/blktap2/drivers/tapdisk-server.c >> b/tools/blktap2/drivers/tapdisk-server.c >> index eecde3d..71315bb 100644 >> --- a/tools/blktap2/drivers/tapdisk-server.c >> +++ b/tools/blktap2/drivers/tapdisk-server.c >> @@ -30,7 +30,7 @@ >> #include >> #include >> #include >> -#include >> +#include >> >> #include "tapdisk-utils.h" >> #include "tapdisk-server.h" >> -- >> 2.7.4 >> >> >> ___ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 103751: trouble: broken/pass
flight 103751 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/103751/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 3 host-install(3)broken REGR. vs. 103746 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass version targeted for testing: xen b9a8061bc28930b0c922a5d828447c52e4e873c2 baseline version: xen 7469686ccc959765542cd10551f9bd7a602f2cbd Last test of basis 103746 2016-12-19 11:02:18 Z0 days Testing same since 103751 2016-12-19 16:01:58 Z0 days1 attempts People who touched revisions under test: Andrew Cooper jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt broken 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 broken-step test-amd64-amd64-libvirt host-install(3) Not pushing. commit b9a8061bc28930b0c922a5d828447c52e4e873c2 Author: Andrew Cooper Date: Sun Dec 18 15:42:59 2016 + x86/emul: Correct the handling of eflags with SYSCALL A singlestep #DB is determined by the resulting eflags value from the execution of SYSCALL, not the original eflags value. By using the original eflags value, we negate the guest kernels attempt to protect itself from a privilege escalation by masking TF. (re)introduce a singlestep boolean, defaulting to the original eflags state, but have the SYSCALL emulation recalculate it after masking has occurred. This is XSA-204 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (qemu changes not included) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] Xen: ARM: Zero reserved fields of xatp before making hypervisor call
On Mon, 19 Dec 2016, Juergen Gross wrote:
> On 19/12/16 03:56, Jiandi An wrote:
> > Ensure all reserved fields of xatp are zero before making hypervisor
> > call to XEN in xen_map_device_mmio(). xenmem_add_to_physmap_one() in
> > XEN fails the mapping request if extra.res reserved field in xatp is
> > not zero for XENMAPSPACE_dev_mmio request.
> >
> > Signed-off-by: Jiandi An
> > ---
> > drivers/xen/arm-device.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/xen/arm-device.c b/drivers/xen/arm-device.c
> > index 778acf8..208273b 100644
> > --- a/drivers/xen/arm-device.c
> > +++ b/drivers/xen/arm-device.c
> > @@ -87,6 +87,9 @@ static int xen_map_device_mmio(const struct resource
> > *resources,
> > idxs[j] = XEN_PFN_DOWN(r->start) + j;
> > }
> >
> > + /* Ensure reserved fields are set to zero */
> > + memset(&xatp, 0, sizeof(xatp));
> > +
> > xatp.domid = DOMID_SELF;
> > xatp.size = nr;
> > xatp.space = XENMAPSPACE_dev_mmio;
>
> Instead of setting xatp to 0 in each iteration I'd prefer a static
> initialization of .domid and .space:
>
> struct xen_add_to_physmap_range xatp = {
> .domid = DOMID_SELF,
> .space = XENMAPSPACE_dev_mmio
> };
+1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Regression due to "mm/swap.c: flush lru pvecs on compound page arrival"
On Wednesday, December 14, 2016 4:22 PM Michal Hocko, wrote:
> Ohh, I can see it now. This is not an upstream commit. This is a 3.18.37
> backport which was wrong! You need the follow up fix 52c84a95dc6a
> ("4.1.28 Fix bad backport of 8f182270dfec "mm/swap.c: flush lru pvecs on
> compound page arrival""). The primary problem was that __lru_cache_add
> has leaked pages which would explain your OOM.
Ian did it solve the problem for you?
Thanks,
Lukas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/x86: Improve hypercall page writing
On 12/19/2016 11:55 AM, Andrew Cooper wrote: > Use memcpy() rather than individual writes with explicit casts. The > __builtin_memcpy() wrapper does a better job at combining adjacent writes into > a larger word size. > > This results in better generated assembly. No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest
On Mon, 19 Dec 2016, Christoffer Dall wrote: > On Fri, Dec 16, 2016 at 05:03:13PM +, Julien Grall wrote: > > (CC rest maintainers for event channel questions) > > > > On 16/12/16 10:06, Bhupinder Thakur wrote: > > >Hi, > > > > Hi Bhupinder, > > > > >The idea is for Xen to act as an intermediary as shown below: > > > > > > ring buffers > > > rx/tx fifo > > >dom0 <---> Xen HYP (running pl011 emulation) > > ><---> domU > > >event > > > interrupts > > > > > >Xen will directly manage the in/out console ring buffers (allocated by > > >dom0 for dom0-domU console communication) for reading/writing console > > >data from/to dom0. On the other side, Xen HYP will emulate pl011 to > > >read/write data from/to domU and pass it on to/from dom0 over the > > >in/out console ring buffers. There should be no change in dom0 as it > > >will still use the same ring buffers. Similarly there should be no > > >change in domU which would be running a standard pll011 driver. > > > > > >Currently, I am working on the interface between dom0 and Xen HYP. I > > >want to intercept the console events in Xen HYP which pass between > > >dom0 and domU. For now, I just want to capture console data coming > > >from dom0 at Xen HYP and loop it back to dom0, to confirm that this > > >interface is working. > > > > > >Since each guest domain will have a unique event channel assigned for > > >console communication, Xen HYP can find out the event channel for a > > >given domU from the start_info page of that domU, which should have > > > > The start_info page is x86 specific. If you want to get the console > > event channel for ARM, you would have to use > > d->arch.hvm_domain.params[HVM_PARAM_CONSOLE_EVTCHN]. > > > > This parameter will be setup by the toolstack (see alloc_magic_pages > > in libxc/xc_dom_arm.c). > > > > >been allocated by dom0. Whenever, an event is to be dispatched via > > >evtchn_send() API in Xen, it can check if the event channel is the > > >console event channel for a given domU. If yes and its source domain > > >is dom0 and destination domain is domU then it will write the data > > >back to the console out ring buffer of the domU and raise a console > > >event to dom0. > > > > > >Once this interface is working, Xen HYP can check the source and > > >destination dom ids and decide which way the event came from and > > >accordingly process the console data. To allow a mix of PV console > > >guests and pl011 guests, Xen might have to maintain a flag per domain, > > >which tells whether Xen HYP should intercept and process the data (for > > >pl011 UART case) or let it go transparently (for PV conosle case). > > > > I am not very familiar with the event channel code. I will let the > > others comment on this bit. > > > > Regardless that, how would you decide whether the hypervisor should > > intercept the notification? > > > > I can see 2 different cases: > > 1) The guest is starting to use the pl011 then move to the HVC > > console (or HVC then pl011) > > 2) The guest is using both the PL011 and the HVC console > > > > Should we consider the second case valid? I would say yes, because a > > user could specify both on the command line. If we use the same > > ring, the output would be a total garbage. > > > > So maybe we need to allocate two distinct rings and event channel? > > This sounds like the only sensible thing to me. I think this is really > about adding a new device to the Xen virtual platform, and providing the > user the option to choose which one he wants the tool in Dom0 to be > presented using stdin/out. Presumably the other console/serial can be > redirected to a file or socket or something? Let me explain how the PV console protocol and drivers work, because they are a bit unusual. The first PV console is advertised via hvm_params. The guest calls: hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v); hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v); to get the two parameters to setup the ring and evtchn. If they are 0, the guest considers the first console unavailable. Other PV console rings, from the second onward, are advertised via xenstore like any other Xen PV protocols. In those cases, frontend and backend access xenstore to setup ring and event channel. The PV console backends are unusual too. xenconsoled, available on all Xen systems, is one process per host and can handle only one PV console per domain. Specifically, it is only able to deal with the first console. Domains that have multiple PV consoles require QEMU (not as an emulator, but as a PV backends provider). The toolstack writes "type" = "xenconsoled" or "ioemu" to distinguish PV consoles that xenconsoled or QEMU are supposed to handle. Ideally, we shouldn't require QEMU for pl011 PV consoles, but it wouldn't be the end of the world if we did. Additionally, Xen cannot speak xenstore. It can neither read no
[Xen-devel] [xen-unstable-smoke test] 103759: regressions - FAIL
flight 103759 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103759/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 9 debian-hvm-install fail REGR. vs.
103746
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen 157db407533fb55c0ce0c133991e3cb951b76484
baseline version:
xen 7469686ccc959765542cd10551f9bd7a602f2cbd
Last test of basis 103746 2016-12-19 11:02:18 Z0 days
Failing since103751 2016-12-19 16:01:58 Z0 days2 attempts
Testing same since 103759 2016-12-19 19:34:32 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
Jan Beulich
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
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
Not pushing.
commit 157db407533fb55c0ce0c133991e3cb951b76484
Author: Jan Beulich
Date: Mon Dec 19 17:52:42 2016 +0100
x86: fix asm() constraint in clear_user()
Commit 2fdf5b2554 ("x86: streamline copying to/from user memory")
wrongly used "g" here, when it obviously needs to be a register.
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
commit b9a8061bc28930b0c922a5d828447c52e4e873c2
Author: Andrew Cooper
Date: Sun Dec 18 15:42:59 2016 +
x86/emul: Correct the handling of eflags with SYSCALL
A singlestep #DB is determined by the resulting eflags value from the
execution of SYSCALL, not the original eflags value.
By using the original eflags value, we negate the guest kernels attempt to
protect itself from a privilege escalation by masking TF.
(re)introduce a singlestep boolean, defaulting to the original eflags state,
but have the SYSCALL emulation recalculate it after masking has occurred.
This is XSA-204
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
(qemu changes not included)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: fix rank/vgic locks inversion bug
On Mon, 19 Dec 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 17/12/2016 02:13, Stefano Stabellini wrote:
> > On Fri, 16 Dec 2016, Stefano Stabellini wrote:
> > > On Fri, 16 Dec 2016, Julien Grall wrote:
> > > > Hi Stefano,
> > > >
> > > > On 16/12/16 00:08, Stefano Stabellini wrote:
> > > > > On Thu, 15 Dec 2016, Julien Grall wrote:
> > > > > > On 15/12/2016 01:04, Stefano Stabellini wrote:
> > > > > > > The locking order is: first rank lock, then vgic lock. The order
> > > > > > > is
> > > > > > > respected everywhere, except for gic_update_one_lr.
> > > > > > >
> > > > > > > gic_update_one_lr is called with the vgic lock held, but it calls
> > > > > > > vgic_get_target_vcpu, which tries to obtain the rank lock. This
> > > > > > > can
> > > > > > > cause deadlocks.
> > > > > > >
> > > > > > > We already have a version of vgic_get_target_vcpu that doesn't
> > > > > > > take the
> > > > > > > rank lock: __vgic_get_target_vcpu. Also the only routine that
> > > > > > > modify
> > > > > > > the target vcpu are vgic_store_itargetsr and vgic_store_irouter.
> > > > > > > They
> > > > > > > call vgic_migrate_irq, which already take the vgic lock.
> > > > > > >
> > > > > > > Solve the lock inversion problem, by not taking the rank lock in
> > > > > > > gic_update_one_lr (calling __vgic_get_target_vcpu instead of
> > > > > > > vgic_get_target_vcpu).
> > > > > >
> > > > > > If I look at the callers of gic_update_one_lr, the function
> > > > > > gic_clear_lrs
> > > > > > will
> > > > > > not take the rank lock. So from my understanding nobody will take
> > > > > > the rank
> > > > > > here.
> > > > > >
> > > > > > However __vgic_get_target_vcpu has an ASSERT to check whether the
> > > > > > rank
> > > > > > lock
> > > > > > has been taken. So who is taking lock for gic_update_one_lr now?
> > > > >
> > > > > I should have removed the ASSERT - nobody is taking the rank lock now
> > > > > on
> > > > > the gic_update_one_lr code path.
> > > >
> > > > Please either keep this ASSERT or update it. But not dropping it, we
> > > > need to
> > > > prevent anyone calling this function without any lock taken at least in
> > > > debug
> > > > build.
> > > >
> > > > The current callers (see vgic_{disable,enable}_irqs) are calling the
> > > > function
> > > > with rank lock taken.
> > > >
> > > > So we need to keep this behavior at least for them.
> > > >
> > > > > > We make this safe, by placing modifications to
> > > > > > > rank->vcpu within regions protected by the vgic lock.
> > > > > >
> > > > > > This look unsafe to me. The vgic lock is per-vcpu, but rank->vcpu
> > > > > > could be
> > > > > > written/read by any vCPU. So you will never protect rank->vcpu with
> > > > > > this
> > > > > > lock.
> > > > > > Did I miss anything?
> > > > >
> > > > > The vgic lock is per-vcpu, but it is always the vgic lock of the old
> > > > > (old
> > > > > in the sense, before the interrupt is migrated) vcpu that is taken.
> > > > >
> > > > > On one hand any vcpu can read/write to itargetsr. Those operations are
> > > > > protected by the rank lock. However vgic_migrate_irq and writes to
> > > > > rank->vcpu are protected also by the vgic lock of the old vcpu (first
> > > > > the rank lock is taken, then the vgic lock of the old vcpu).
> > > >
> > > > I don't think this is true. Any vCPU read/write to itargetsr will be
> > > > protected
> > > > by the vgic lock of the vCPU in rank->vcpu[offset].
> > > >
> > > > For inflight IRQ, the migration will happen when the guest has EOIed the
> > > > IRQ.
> > > > Until this is happening, the guest may have written multiple time in
> > > > ITARGETSR.
> > > >
> > > > For instance, let say the guest is requesting to migrate the IRQ from
> > > > vCPU A
> > > > to vCPU B. The vgic lock A will be taken in vgic_store_itargetsr, if the
> > > > interrupt is inflight vgic_migrate_irq will set a flag. Now the guest
> > > > could
> > > > decide to migrate the interrupt to vCPU C before the interrupt has been
> > > > EOIed.
> > > > In this case, vgic lock B will be taken.
> > > >
> > > > So we have a mismatch between the lock taken in gic_update_one_lr and
> > > > vgic_migrate_irq.
> > > >
> > > > I think the only safe way to fully protect rank->vcpu is taking the rank
> > > > lock.
> > > > It will never change and be accessible from anywhere.
> > >
> > > When I submitted this series, I considered this scenario, and I thought
> > > that the existing GIC_IRQ_GUEST_MIGRATING flag should be enough to
> > > protect it, because when GIC_IRQ_GUEST_MIGRATING is set,
> > > vgic_migrate_irq actually returns immediately, without doing anything.
> > > Either GIC_IRQ_GUEST_MIGRATING is not set, and it's the first irq
> > > migration, or GIC_IRQ_GUEST_MIGRATING is set, and vgic_migrate_irq just
> > > returns.
> > >
> > > However, as I was writing this explanation to you in more details, I
> > > realized that it is not actually safe. Concurrent accesses to
> > > rank->vcpu, and concurrent calls to irq_set_
Re: [Xen-devel] [PATCH] xen/arm: fix rank/vgic locks inversion bug
Hi Stefano, On 19/12/2016 23:30, Stefano Stabellini wrote: On Mon, 19 Dec 2016, Julien Grall wrote: 2) We run gic_update_one_lr and vgic_store_itargetsr in parallel safely and locklessly. There might be a way to do it, but it is not easy I haven't found it yet. Correct me if I am wrong. There are no restriction to write into IROUTER/ITARGETSR while an IRQ is pending. So the irq_set_affinity could be called once at the beginning of vgic_irq_migrate. We may receive the interrupt on the wrong physical CPU at the beginning. But it would be the same when writing into IROUTER/ITARGETSR. This would remove the need to get the rank lock in gic_update_one_lr. Did I miss anything? I am not sure if we can do that: the virtual interrupt might not be EOI'd yet at that time. The guest EOI is used to deactivate the corresponding physical interrupt. Migrating the physical IRQ at that time, could have unintended consequences? I am not sure what the spec says about this, but even if it is correct on paper, I would prefer not to put it to the test: I bet that not many interrupt controllers have been heavily tested in this scenario. What do you think? I don't think this is an issue. An interrupt could have the priority drop happening on pCPU A and be deactivated on pCPU B if the vCPU A is been migrated when the interrupt is inflight. So if it is fine here, why would not it be when the guest is specifically requesting the routing? Thinking outside the box, another way to solve this problem is to reject any interrupt affinity changes while an interrupt migration is still in progress. In fact, that scenario is very uncommon. As far as I know operating systems deactivate interrupts before migrating them. I would rather avoid to differ from the specification, even it looks sensible for a guest to migrate the interrupt whilst it is not active. Otherwise, I think it is very reasonable to store the vcpu id (or the pcpu id) in struct pending_irq: we already store the lr register number there. The current code can tell in which lr register an interrupt has been written to, but it cannot tell to which cpu the lr register belongs to. It's a paradox. Once we know the vcpu id for any inflight irqs, then we can make sure to take the right vcpu.vgic lock from vgic_migrate_irq. This is a good point. I was concerned about the size of pending_irq (we have to allocate it per-IRQ) but it looks like we have some padding in the structure between priority and inflight. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen: Support for mapping OperationRegion in ACPI ASL
This is actually not an ARM specific question, so changing the subject and CC'ing more people. On Wed, 14 Dec 2016, Konrad Rzeszutek Wilk wrote: > On Tue, Dec 13, 2016 at 07:14:27PM -0600, Jiandi An wrote: > > Hi Guys, > > > > Xen currently does not handle mapping of MMIO regions specified under > > OperationRegion in ACPI ASL. OperationRegion is well defined in ACPI > > specification. I'm seeking for architectural direction on adding support > > for mapping OperationRegion. > > > > Some context here. Mapping of resources specificed under _CRS in ACPI is > > handled by dom0 requesting Xen to map as platform devices are added. > > https://lwn.net/Articles/674666/ provided service xen_map_device_mmio() in > > dom0 to call Xen to map and it's done so by registering > > xen_platform_notifier() platform bus driver. This covers the platform > > devices. > > > > The OperationRegion access in dom0 is in acpica path. The following is a > > stack of the code path where OperationRegion is parsed. > > acpi_ex_system_memory_space_handler() gets the parsed address specified in > > OperationRegion in ACPI and maps it then performs the memory read or write. > > > > > > acpi_ex_system_memory_space_handler+0x378/0x424 > > acpi_ev_address_space_dispatch+0x294/0x310 > > acpi_ex_access_region+0x3c0/0x468 > > acpi_ex_field_datum_io+0x14c/0x380 > > acpi_ex_extract_from_field+0xe8/0x2f4 > > acpi_ex_read_data_from_field+0x330/0x38c > > acpi_ex_resolve_node_to_value+0x310/0x3fc > > acpi_ex_resolve_to_value+0x354/0x3e8 > > acpi_ds_evaluate_name_path+0xa4/0x15c > > acpi_ds_exec_end_op+0xbc/0x6c8 > > acpi_ps_parse_loop+0x7ac/0x840 > > acpi_ps_parse_aml+0x1c4/0x434 > > acpi_ps_execute_method+0x1f0/0x2a0 > > acpi_ns_evaluate+0x2e4/0x424 > > acpi_ut_evaluate_object+0xb0/0x250 > > acpi_ut_execute_STA+0xb0/0x164 > > acpi_ns_init_one_device+0xac/0x250 > > acpi_ns_walk_namespace+0x108/0x254 > > acpi_ns_initialize_devices+0x274/0x35c > > acpi_initialize_objects+0x90/0xf0 > > acpi_init+0xc0/0x30c > > do_one_initcall+0x44/0x138 > > kernel_init_freeable+0x148/0x1ec > > kernel_init+0x18/0x108 > > > > The workaround in testing for handling OperationRegion I did is to call > > xen_map_device_mmio() to map the resource specificied in OperationRegion if > > it's dom0 running under XEN in acpi_ex_system_memory_space_handler(). But > > this is a fairly generic ACPI code path. Looking for achitectural > > suggestion to properly handle OperationRegion for Xen on ARM. > > The ACPI code path obviously calls the underlaying OS code to map it. > Could this path have an wrapper around it (so one could register > different underlaying 'map_device_mmio' function calls)? > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: fix rank/vgic locks inversion bug
On Mon, 19 Dec 2016, Julien Grall wrote: > Hi Stefano, > > On 19/12/2016 23:30, Stefano Stabellini wrote: > > On Mon, 19 Dec 2016, Julien Grall wrote: > > > > > 2) We run gic_update_one_lr and vgic_store_itargetsr in parallel > > > > > safely > > > > > and locklessly. There might be a way to do it, but it is not easy I > > > > > haven't found it yet. > > > > > > Correct me if I am wrong. There are no restriction to write into > > > IROUTER/ITARGETSR while an IRQ is pending. So the irq_set_affinity could > > > be > > > called once at the beginning of vgic_irq_migrate. > > > > > > We may receive the interrupt on the wrong physical CPU at the beginning. > > > But > > > it would be the same when writing into IROUTER/ITARGETSR. > > > > > > This would remove the need to get the rank lock in gic_update_one_lr. > > > > > > Did I miss anything? > > > > I am not sure if we can do that: the virtual interrupt might not be > > EOI'd yet at that time. The guest EOI is used to deactivate the > > corresponding physical interrupt. Migrating the physical IRQ at that > > time, could have unintended consequences? I am not sure what the spec > > says about this, but even if it is correct on paper, I would prefer not > > to put it to the test: I bet that not many interrupt controllers have > > been heavily tested in this scenario. What do you think? > > I don't think this is an issue. An interrupt could have the priority drop > happening on pCPU A and be deactivated on pCPU B if the vCPU A is been > migrated when the interrupt is inflight. So if it is fine here, why would not > it be when the guest is specifically requesting the routing? That is true, but this is not exactly the same. This is changing the physical irq affinity while both physical and virtual irqs are still active. As I wrote, usually operating systems only change affinity after deactivating an irq, so I thought it would be wise in Xen to wait at least for the EOI. If we tried to inject the same virtual interrupt on a different vcpu, while the interrupt is still inflight, we could get in troubles. But we could avoid that by testing for GIC_IRQ_GUEST_MIGRATING in vgic_vcpu_inject_irq. Maybe I am worrying about nothing. > > Otherwise, I think it is very reasonable to store the vcpu id (or the > > pcpu id) in struct pending_irq: we already store the lr register number > > there. The current code can tell in which lr register an interrupt has > > been written to, but it cannot tell to which cpu the lr register belongs > > to. It's a paradox. Once we know the vcpu id for any inflight irqs, then > > we can make sure to take the right vcpu.vgic lock from vgic_migrate_irq. > > This is a good point. I was concerned about the size of pending_irq (we have > to allocate it per-IRQ) but it looks like we have some padding in the > structure between priority and inflight. That's right, that's exactly what I intended to use. This solution comes at no costs, but we would have to remember that it's the vcpu vgic lock that protects reads to rank->vcpu rather than the rank lock. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen: ARM: Support to map mmio region specified in static ACPI tables
This is not exactly ARM specific, so expanding the CC list. On Wed, 14 Dec 2016, Jiandi An wrote: > Hi Guys, > > Xen currently does not handle mapping mmio regions specified in standard > static ACPI tables such as BERT, TPM2, GT block, IORT, HEST, etc. There has > been some initial discussions on using whitelist and leave it up to the > individual drivers in dom0 who need the particular region in particular ACPI > static table to be mapped to add the support of calling back to XEN to > request the mapping. Just want to get the discussion started and gather > consensus on this approach. This means in each driver in dom0 logic is > inserted to check for if running under Xen being dom0, then call hypercall to > XEN to request mapping. Maintainers for individual drivers (BERT driver, TPM > driver, etc) may not like this idea for inserting XEN specific checking and > mapping call in the driver right? Hello Jiandi, I don't think that this is exactly what was suggested. Let me elaborate here. Any devices, even non-discoverable devices, should request MMIO regions mappings via xen_map_device_mmio. We should be able to receive an internal Linux notification for each one of them via the usual BUS_NOTIFY_ADD_DEVICE Linux callback. See drivers/xen/arm-device.c on how to handle them. If we don't receive an internal Linux callback for a particular device, it is likely because of a bug in Linux and we should fix it. For things that are not devices, such as the Boot Error Region described by BERT, it's more blurry. We have two options: 1) we introduce a new internal Linux API that allows us to replace the memory mapping function used for ACPI tables such as BERT 2) we introduce support in Xen to parse and map each of these tables (we can do that because they are all static tables, no AML involved) I think that 1) is simpler and more robust. We only need a way to replace the ioremap implementation when Xen is enabled. It is also pretty much the same suggestion that Konrad gave for the OperationRegion: http://marc.info/?l=xen-devel&m=148172287422178 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen: ARM: Support for mapping ECAM PCIe Config Space Specified In Static ACPI Table
On Mon, 19 Dec 2016, Julien Grall wrote: > Hi, > > On 16/12/2016 15:49, Julien Grall wrote: > > On 14/12/16 08:00, Jiandi An wrote: > > > Xen currently doesn't map ECAM space specified in static ACPI table. > > > Seeking opinion on how this should be handled properly. > > > Each root complex ECAM region takes up 64K 4K pages (256MB). > > > For some platforms there might be multiple root complexes. > > > Is the plan to map all at once?Julien has mentioned support > > > for mapping ECAM may come when support for PCI passthrough is > > > added, is that right? What mechanism will it be? Will Xen or > > > dom0 be the one that parses the staic ACPI tables and map the ECAM space? > > > > For performance reason, each ECAM region would need to be mapped at > > once, so the stage-2 page table could take advantage of superpage (it > > will mostly be 2MB). > > > > Now, I don't think Xen should map the ECAM region in stage-2 before > > hand. All the regions may not be described in the MCFG and I would like > > to see a generic solution. > > > > Looking at the code (see pci_create_ecam_create in drivers/pci/ecam.c), > > ioremap is used. I believe the problem is the same for the 2 other > > threads you sent ( [1] and [2]). > > > > So it might be good to look at hooking up a call to > > XENMEM_add_to_physmap_range in ioremap. > > > > Any opinions? > > I thought a bit more about it and I realized we need to be cautious on how to > proceed here. > > DOM0 will have a mix of real devices and emulated devices (e.g some part of > the GIC). For the emulated devices, DOM0 should not call > XENMEM_add_to_physmap_range. However, DOM0 is not aware what is emulated or > not, so even the current approach (hooking up in platform device) seems > fragile. We rely on Xen to say "this region cannot be mapped". You are right that Dom0 doesn't and shouldn't be able to tell the difference between emulated and real devices. But I don't think that should be a problem because Xen knows exactly if an MMIO region belongs to an emulated device thanks to the 1:1 mapping. When XENMEM_add_to_physmap_range is called, Xen can check whether the region belongs to an emulated device or a real device, mapping memory only if it belongs to a real device. No need to report errors: from Dom0 point of view the operation succeeded either way. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 1/1] xen/arm: Map mmio-sram nodes as cached memory
On Mon, 19 Dec 2016, Julien Grall wrote: > Hi Edgar, > > On 16/12/2016 18:04, Edgar E. Iglesias wrote: > > On Fri, Dec 16, 2016 at 04:12:00PM +, Julien Grall wrote: > > > On 15/12/16 11:26, Edgar E. Iglesias wrote: > > > > From: "Edgar E. Iglesias" > > > > > > > > Relax the mapping of mmio-sram nodes that do not set the > > > > no-memory-wc property to cached normal memory. > > > > > > > > Rationale: > > > > Allthough on chip memories are relatively fast compared to > > > > > > s/Allthough/Although/ > > > > Fixed for v2. > > > > > > > > > off-chip memories, large OCMs are still significantly slower > > > > > > May I ask what does OCMs mean? > > > > It means On Chip Memories. I can spell it out in v2. > > Yes please. I was not able to find the acronym with a quick search Google. > > [...] > > > > I consider it as the most trusted domain and has other way to mess up the > > > platform. So I am fine with this relaxation for the hardware domain (AKA > > > DOM0). > > > > > > However, I have the feeling that we need this kind of relaxation for many > > > devices. For instance prefetchable memory BARs for PCI would have to be > > > cacheable, same for integrated graphic cards. > > > > Yes, I agree. > > > > > > > > I am wondering whether for DOM0 only (*not the other guests), we should > > > relax the default stage-2 attribute mapping to p2m_mmio_direct_c. > > > > > > So we would let DOM0 in charge of the final attribute. This may boost the > > > performance of memory access in DOM0. > > > > > > Any opinions? > > > > I think it makes sense. We had a discussiong about it a while back ago: > > https://lists.xenproject.org/archives/html/xen-devel/2015-05/msg02349.html > > > > The concerns that were raised were wether there could be devices that > > could behave badly and possibly giving dom0 access to trig undefined or > > unpredictable behavior that could be exploited. > > I think it would be fine for DOM0. It is already a trusted domain and have > other way to take down the platform. > > > > > If dom0 accesses devices through a cache, access patterns will change. > > In theory it may trig unexpected behaviour in some device. It's hard > > to say unless talking about specific chips and implementations. > > > > For example, given dom0 access to a DMA capable device may also achieve > > the same. I.e access patterns from DMA units differ from the ones > > originating from a CPU using uncached device memory. It could trig > > similar kind of errors. > > Another example is having the device mapped with different in 2 places with > different cacheability attributes. The data accessed would not be coherent. > But I believe that should not lead to a security issue. > > > > > It would be interesting to see a concrete example of a problematic > > system. > > I believe it would depend a lot on how the platform have been designed. > > I think we have two choices to go forward: > 1) Relax the memory attribute on case by case. DOM0 would not be able > to exploit potential undefined behavior. However, this means that code is been > added for any new device (e.g compatible string). > 2) Relax the memory attribute on every case. DOM0 would be able to > exploit potential undefined behavior. On the benefit side, every devices can > be used at its full performance without any change required in Xen. > > In the case of ACPI, we rely on DOM0 to provide the correct mapping attribute > when asking to do the stage-2 mapping (see XENMAPSPACE_dev_mmio). Note that > currently, the MMIO are always mapped with the attribute Device-nGnRE. There > is plan to change that in the future. So ACPI is implementing 2). > > Device Tree is currently implementing 1). But I would like to see the behavior > of Xen the same no matter the firmware tables used. So I would lean towards > 2). That's fine by me. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 103760: regressions - FAIL
flight 103760 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103760/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 17 guest-start/debianhvm.repeat fail
REGR. vs. 103746
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen 157db407533fb55c0ce0c133991e3cb951b76484
baseline version:
xen 7469686ccc959765542cd10551f9bd7a602f2cbd
Last test of basis 103746 2016-12-19 11:02:18 Z0 days
Failing since103751 2016-12-19 16:01:58 Z0 days3 attempts
Testing same since 103759 2016-12-19 19:34:32 Z0 days2 attempts
People who touched revisions under test:
Andrew Cooper
Jan Beulich
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
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
Not pushing.
commit 157db407533fb55c0ce0c133991e3cb951b76484
Author: Jan Beulich
Date: Mon Dec 19 17:52:42 2016 +0100
x86: fix asm() constraint in clear_user()
Commit 2fdf5b2554 ("x86: streamline copying to/from user memory")
wrongly used "g" here, when it obviously needs to be a register.
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
commit b9a8061bc28930b0c922a5d828447c52e4e873c2
Author: Andrew Cooper
Date: Sun Dec 18 15:42:59 2016 +
x86/emul: Correct the handling of eflags with SYSCALL
A singlestep #DB is determined by the resulting eflags value from the
execution of SYSCALL, not the original eflags value.
By using the original eflags value, we negate the guest kernels attempt to
protect itself from a privilege escalation by masking TF.
(re)introduce a singlestep boolean, defaulting to the original eflags state,
but have the SYSCALL emulation recalculate it after masking has occurred.
This is XSA-204
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
(qemu changes not included)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [RFC] Xen PV Drivers Lifecycle
Hi all, as you know, we have an issue with the speed of review and acceptance of new PV drivers. In a discussion among committers, George wrote an email with a short proposal to clarify the development lifecycle of new PV drivers and the different expectations at each stage of the process. I took that email, polished it and turned it into markdown. Here it is. --- # Xen PV Drivers lifecycle ## Purpose Getting new PV drivers accepted in Xen, upstream code bases, and ABI stable in the quickest and most efficient way possible. ## Design Phase The first step toward acceptance of a new PV protocol is to write a design document and send it to xen-devel. It should cover the xenstore handshake mechanism, the ABI, how the protocol works and anything else which is required to write an implementation of it. The usage of C-like structs to describe language and platform agnostic protocols is discouraged. An attempt should be made for the protocol ABI to be backward compatible and OS agnostic, but, realistically, backward and cross-platform compatibility are not fully expected at this stage. After the high level design of the protocol has been discussed and agreed, the document is committed to xen.git. ## Prototype Stage The contributor sends patches to implement the PV drivers for the new protocol to the relevant open source mailing lists, such as LKML, qemu-devel and xen-devel. The code is expected to work, be good quality and faithfully implement the spec. However, there are no promises about ABI and cross-platform compatibility yet. After careful review by the relevant maintainers, the code is committed to the upstream code bases. The drivers are considered experimental. ## Production Stage The quality of the drivers and the spec is improved. Bugs are fixed. The protocol version is likely bumped. More testing leads to confidence that the spec and the drivers are ready for production usage. Promises about backward compatibility and cross-platform compatibility are clearly spelled out. ## How to move forward from a stage to the next The PV protocols Czar is responsible for determining the transitions between stages. Our governance principles specify "lazy consensus" for most things. It applies to this case too. New PV protocols should move from one stage to the next within a reasonable time frame unless someone has specific technical objections and voices them in a responsive manner. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 103747: regressions - trouble: broken/fail/pass
flight 103747 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/103747/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. vs. 103466 test-amd64-amd64-i386-pvgrub 6 xen-boot fail in 103659 REGR. vs. 103466 test-amd64-amd64-xl-qemuu-win7-amd64 6 xen-boot fail in 103659 REGR. vs. 103466 test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail in 103659 REGR. vs. 103466 test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-boot fail in 103659 REGR. vs. 103466 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail in 103659 REGR. vs. 103466 test-xtf-amd64-amd64-36 xen-boot fail in 103741 REGR. vs. 103466 Tests which are failing intermittently (not blocking): test-xtf-amd64-amd64-43 host-install(3) broken pass in 103659 test-amd64-amd64-xl-qemut-debianhvm-amd64 3 host-install(3) broken pass in 103659 test-amd64-amd64-xl-rtds 3 host-install(3) broken pass in 103659 test-amd64-amd64-xl-qemuu-win7-amd64 3 host-install(3) broken pass in 103659 test-amd64-amd64-i386-pvgrub 3 host-install(3) broken pass in 103659 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken pass in 103737 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3)broken pass in 103737 test-amd64-amd64-xl 3 host-install(3) broken pass in 103737 test-amd64-amd64-xl-xsm 3 host-install(3) broken pass in 103737 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken pass in 103737 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken pass in 103737 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken pass in 103737 test-xtf-amd64-amd64-33 host-install(3) broken pass in 103741 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3)broken pass in 103741 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 3 host-install(3) broken pass in 103741 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken pass in 103741 test-xtf-amd64-amd64-46 xen-boot fail in 103540 pass in 103659 test-armhf-armhf-libvirt-raw 4 host-ping-check-native fail in 103540 pass in 103747 test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-boot fail in 103659 pass in 103540 test-amd64-amd64-xl 6 xen-boot fail in 103659 pass in 103540 test-amd64-amd64-xl-xsm 6 xen-boot fail in 103659 pass in 103540 test-xtf-amd64-amd64-56 xen-boot fail in 103659 pass in 103747 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 11 saverestore-support-check fail in 103659 pass in 103747 test-armhf-armhf-xl-vhd 9 debian-di-install fail in 103659 pass in 103747 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail in 103737 pass in 103659 test-amd64-i386-qemuu-rhel6hvm-amd 6 xen-boot fail in 103737 pass in 103659 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail in 103741 pass in 103659 test-armhf-armhf-libvirt 6 xen-boot fail in 103741 pass in 103747 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 17 guest-start/win.repeat fail in 103741 pass in 103747 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 11 guest-start fail in 103540 like 103466 test-amd64-amd64-xl-rtds 6 xen-boot fail in 103659 REGR. vs. 103466 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 103737 like 103394 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 103394 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 103466 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 103466 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 103466 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 103466 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 103466 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 103466 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail in 103741 never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12
[Xen-devel] [linux-4.1 test] 103749: regressions - trouble: broken/fail/pass
flight 103749 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/103749/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 101737 test-amd64-i386-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 101737 test-amd64-amd64-qemuu-nested-intel 6 xen-boot fail REGR. vs. 101737 test-amd64-i386-pair 9 xen-boot/src_hostfail REGR. vs. 101737 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101737 test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-boot fail REGR. vs. 101737 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101737 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101737 test-amd64-amd64-xl-pvh-intel 6 xen-bootfail REGR. vs. 101737 test-amd64-amd64-xl-multivcpu 6 xen-bootfail REGR. vs. 101737 test-amd64-i386-freebsd10-amd64 6 xen-boot fail REGR. vs. 101737 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101737 build-armhf-pvops 5 kernel-build fail in 102733 REGR. vs. 101737 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-win7-amd64 3 host-install(3) broken in 103011 pass in 103749 test-amd64-i386-xl-qemut-winxpsp3 3 host-install(3) broken in 103011 pass in 103749 test-amd64-amd64-xl-qemuu-win7-amd64 3 host-install(3) broken in 103011 pass in 103749 test-amd64-i386-xl 3 host-install(3) broken in 103011 pass in 103749 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken in 103011 pass in 103749 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken in 103740 pass in 103749 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 103740 pass in 103749 test-amd64-amd64-xl-qcow23 host-install(3) broken in 103740 pass in 103749 test-amd64-i386-xl-qemuu-winxpsp3 3 host-install(3) broken pass in 103740 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3)broken pass in 103740 test-amd64-amd64-libvirt-vhd 9 debian-di-install fail in 102733 pass in 102886 test-amd64-amd64-xl-xsm 19 guest-start/debian.repeat fail in 102755 pass in 103089 test-armhf-armhf-libvirt-xsm 14 guest-stop fail in 102755 pass in 103749 test-amd64-i386-xl-xsm6 xen-boot fail in 102886 pass in 103749 test-amd64-amd64-qemuu-nested-amd 9 debian-hvm-install fail in 102886 pass in 103749 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail in 102886 pass in 103749 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail in 103011 pass in 103749 test-armhf-armhf-libvirt-xsm 11 guest-start fail in 103011 pass in 103749 test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail in 103089 pass in 103740 test-armhf-armhf-libvirt-xsm 6 xen-boot fail in 103451 pass in 103749 test-armhf-armhf-libvirt 11 guest-start fail in 103451 pass in 103749 test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail pass in 102733 test-amd64-i386-xl-raw6 xen-boot fail pass in 102733 test-amd64-amd64-libvirt 6 xen-boot fail pass in 102733 test-amd64-amd64-xl-qemut-winxpsp3 6 xen-boot fail pass in 102755 test-amd64-i386-libvirt-xsm 6 xen-boot fail pass in 102755 test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail pass in 102829 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 102886 test-amd64-amd64-libvirt-vhd 6 xen-boot fail pass in 102886 test-amd64-i386-freebsd10-i386 6 xen-boot fail pass in 103011 test-amd64-amd64-xl-xsm 6 xen-boot fail pass in 103089 test-amd64-amd64-libvirt-pair 9 xen-boot/src_host fail pass in 103089 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host fail pass in 103089 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 103089 test-amd64-amd64-xl-rtds 6 xen-boot fail pass in 103089 test-amd64-amd64-pair 9 xen-boot/src_host fail pass in 103165 test-amd64-amd64-pair10 xen-boot/dst_host fail pass in 103165 test-amd64-amd64-libvirt-xsm 6 xen-boot fail pass in 103165 test-amd64-amd64-i386-pvgrub 6 xen-boot fail pass in 103352 test-amd64-i386-libvirt-pair 9 xen-boot/src_host fail pass in 103451 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host fail pass in 103451 test-armhf-armhf-xl-credit2 6 xen-boot fail pass in 103740 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail pass in 103740 test-armhf-armhf-xl-arndale 5 xen-installfail pass in 103740 test-armhf-armhf-xl-multivcpu 11 guest-start f
Re: [Xen-devel] [XTF PATCH 00/16] Add test cases for nested vmxon
On 12/19/16 16:34 +, Andrew Cooper wrote: On 19/12/16 05:31, Haozhong Zhang wrote: On 12/16/16 21:26 +, Andrew Cooper wrote: On 16/12/16 13:43, Haozhong Zhang wrote: This patch series starts to add a test selection "test-hvm64-vvmx" for nested VMX. This first series focuses mostly on nested vmxon. * Patch 01 - 03 test the basic environment (cpuid and MSR). * Patch 04 - 05 add functions to execute VMX instructions and to collect and handle errors. * Patch 06 - 16 construct a bunch of test cases for nested vmxon per its pseudo code in section "VMXON - Enter VMX Operation" of Intel SDM Vol 3. Thankyou for this series. I have reviewed it now, and have no major problems. It is in quite good shape, other than the licensing concerns with patch 4. One limitation (because I haven't gotten around to implementing it yet) is that once a test is accepted, it can't be logically extended, because it isn't bisection-safe as far as OSSTest is concerned. I'm going to add more test cases in the process of fixing nested VMX, so I think I'd better to put each case in a single test, instead of all cases in one test-hvm64-vvmx. Ah - this clarifies what you mean by dependences of tests on the other thread. At the moment there is an implicit dependency used by both automated test systems running XTF at the moment, which says that a test-$ENV-$foo shouldn't be run if the test-$ENV-selftest didn't complete successfully. I haven't yet encountered a need for other tests to be co-dependent. Let me consider how this might be made to work. OK. Right now let me organize these test cases by instructions, e.g. test-hvm64-vvmxon, test-hvm64-vvmxoff, etc. I will prioritise my work to introduce the test-revision plan, which will allow the OSSTest bisector to work properly in the case that new functionality in a test causes a previously-passing scenario to now fail. Is this a complete set of vmxon scenarios, or are you working on more? Some which come to mind are: * a register operand (to check that Xen decodes properly and rejects the instruction) I'll add this one, and * vmxon w/ nestedhvm=0. You should probably look into using a test variation to explicitly set the test configuration to =0 and =1 See the invlpg and pv-iopl tests for examples of this. Yes, that is what I'm going to follow. * duplicate vmxon in root operation Another area I had on my nested-virt plan was to allow rather finer grain configuration of the vmx options, but that depends on the start of the MSR levelling work, which is still blocked behind getting enough time to finish the CPUID levelling plans. I'll keep this possible change in my mind while I'm preparing test cases which use CPUID/MSR/... to detect the environment instead of replying on assumptions only satisfied on the current Xen implementation. In particular, I eventually want an ability for fine-grained toolstack settings of the available VMX configuration (these being a subset of the MSRs in the system), (all subject to auditing by Xen to keep it within hardware and supported bounds), at which point it would be plausible to spin up a VM, asking for VMX_BASIC_32BIT_ADDRESSES, and checking that suitable limits were observed/enforced inside the VM. I do not quite understand the purpose for the fine-grained VMX options. Is it to provide users with a chance to workaround bugs in certain parts of nested virtualization? I have two usecases in mind. First is being able to check that Xen functions correctly when certain VMX features are unavailable. Recently, we have found a number of security issues which only affect older hardware, and older hardware is getting harder and harder to come by. Using fine grained features can simulate older hardware in some cases. make sense Second, and more importantly, that I need to eventually make this all work with live migration, including between non-identical hardware. Therefore, the fine-grained nature would be used to implement feature levelling. Ah yes, for the live migration! Thanks for the explanation. Thanks, Haozhong ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [XTF PATCH 03/16] vvmx: test whether MSR_IA32_VMX_BASIC is set correctly
On 12/19/16 15:41 +, Andrew Cooper wrote:
On 19/12/16 02:44, Haozhong Zhang wrote:
+passed = false;
+}
+
+vmcs_size = (vmx_basic & VMX_BASIC_VMCS_SIZE_MASK) >> 32;
+if ( vmcs_size > PAGE_SIZE )
+{
+xtf_failure("Fail: "
+"VMCS size (%"PRIu64") in MSR_IA32_VMX_BASIC is
> %ld\n",
+vmcs_size, PAGE_SIZE);
+passed = false;
+}
+else if ( vmcs_size == 0 )
+{
+xtf_failure("Fail: VMCS size in MSR_IA32_VMX_BASIC cannot
be 0\n");
+passed = false;
+}
+
+/* test is running on hvm64, so this bit should be 0 */
+if ( vmx_basic & VMX_BASIC_32BIT_ADDRESSES )
There is nothing in principle wrong with Xen setting this bit. It would
be odd certainly, but not erroneous.
The reason I added this test is because Intel SDM Vol 3, Appendix A.1
Basic VMX Information says "This bit (bit 48) is always 0 for
processors that support Intel 64 architecture."
Right, and Xen, being 64bit only, can expect to find this bit always clear.
I don't know whether there is SW in real world that depends on the
consistency between this bit and Intel SDM, but if there is any, it
might be confused by an odd configuration. So I think it's still worth
to keep such test.
It is a valid administrator choice to restrict a VM to 32bit-only by
hiding the long mode bit. Under those circumstances, it would be
logical to expect this bit to be set in the virtual environment, despite
not being required at the physical level.
If we want to limit the L1 hypervisor to only use 32-bit VMCS/VMXON
address, I think the right way is to limit the L1 vcpu's physical
address width to 32, instead of introducing spec inconsistency, though
it also limits the physical address space that can be used by L1
hypervisor.
Thanks,
Haozhong
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [XTF PATCH 14/16] vvmx: test vmxon in VMX root w/ CPL = 3 and w/o current VMCS
On 12/19/16 16:07 +, Andrew Cooper wrote: On 19/12/16 03:46, Haozhong Zhang wrote: However, I am not sure of its purpose. Why cant you reuse the previous host state area? Intel SDM says SW should not access or modify the VXMON rgion of a logical processor between vmxon and vmxoff. Though I have tested on ^ I missed a 'not' here, hope you didn't misunderstand what I meant here real hardware whether reusing VMXON region would cause any trouble, I still want to exclude that possibility/noise from this test. That is a good reason. Could you please add a comment to this effect? Sure, I'll add a comment around vmxon_region_2nd. Haozhong ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-4.6-testing test] 103753: regressions - trouble: broken/fail/pass
flight 103753 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/103753/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-23 host-install(3)broken REGR. vs. 103407 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken REGR. vs. 103407 test-amd64-amd64-amd64-pvgrub 3 host-install(3) broken REGR. vs. 103407 test-amd64-i386-freebsd10-i386 3 host-install(3) broken REGR. vs. 103407 test-amd64-i386-xl-xsm3 host-install(3)broken REGR. vs. 103407 test-xtf-amd64-amd64-53 host-install(3)broken REGR. vs. 103407 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken REGR. vs. 103407 test-amd64-amd64-libvirt-xsm 3 host-install(3)broken REGR. vs. 103407 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken REGR. vs. 103407 test-amd64-amd64-xl-qemuu-ovmf-amd64 3 host-install(3) broken REGR. vs. 103407 test-amd64-amd64-xl-qcow2 3 host-install(3)broken REGR. vs. 103407 test-armhf-armhf-xl-arndale 3 host-install(3)broken REGR. vs. 103407 test-amd64-i386-pair 7 xen-install/src_host fail REGR. vs. 103407 test-amd64-i386-pair 8 xen-install/dst_host fail REGR. vs. 103407 test-amd64-i386-freebsd10-amd64 10 guest-start fail REGR. vs. 103407 test-amd64-amd64-libvirt 10 debian-fixup fail REGR. vs. 103407 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 103407 test-amd64-amd64-xl-credit2 11 guest-start fail REGR. vs. 103407 test-amd64-i386-qemut-rhel6hvm-amd 9 redhat-install fail REGR. vs. 103407 test-amd64-i386-qemut-rhel6hvm-intel 9 redhat-install fail REGR. vs. 103407 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 103407 test-xtf-amd64-amd64-4 54 xtf/test-pv32pae-livepatch-priv-check fail REGR. vs. 103407 test-amd64-i386-qemuu-rhel6hvm-amd 9 redhat-install fail REGR. vs. 103407 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail REGR. vs. 103407 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 103407 test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail REGR. vs. 103407 test-armhf-armhf-libvirt15 guest-start/debian.repeat fail REGR. vs. 103407 test-armhf-armhf-xl-credit2 9 debian-install fail REGR. vs. 103407 test-amd64-amd64-libvirt-vhd 16 guest-start/debian.repeat fail REGR. vs. 103407 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-rumprun-amd64 16 rumprun-demo-xenstorels/xenstorels.repeat fail REGR. vs. 103407 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail blocked in 103407 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 103407 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 103407 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 103407 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 103407 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 103407 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 103407 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-xtf-amd64-amd64-1 61 xtf/test-pv32pae-xsa-194 fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-xtf-amd64-amd64-3 61 xtf/test-pv32pae-xsa-194 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 save
Re: [Xen-devel] [PATCH 1/7] Remove hardcoded strict -Werror checking
On 12/17/16 9:51 AM, Konrad Rzeszutek Wilk wrote: > On Fri, Dec 16, 2016 at 02:56:01PM -0800, Alistair Francis wrote: >> Signed-off-by: Alistair Francis > > > Why? *adjusts his distro maintainer hat* It's considered really bad form for upstreams to push -Werror in their projects. However I know there's upstream interest to keep it. The compromise would probably be to get my rear in gear and get a wider range of distros testing with Travis CI / GitLab CI. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 103761: tolerable all pass - PUSHED
flight 103761 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103761/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen 157db407533fb55c0ce0c133991e3cb951b76484
baseline version:
xen 7469686ccc959765542cd10551f9bd7a602f2cbd
Last test of basis 103746 2016-12-19 11:02:18 Z0 days
Failing since103751 2016-12-19 16:01:58 Z0 days4 attempts
Testing same since 103759 2016-12-19 19:34:32 Z0 days3 attempts
People who touched revisions under test:
Andrew Cooper
Jan Beulich
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl 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 :
+ branch=xen-unstable-smoke
+ revision=157db407533fb55c0ce0c133991e3cb951b76484
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
157db407533fb55c0ce0c133991e3cb951b76484
+ branch=xen-unstable-smoke
+ revision=157db407533fb55c0ce0c133991e3cb951b76484
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' x157db407533fb55c0ce0c133991e3cb951b76484 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home
Re: [Xen-devel] [PATCH 4/7] tools: Update sys/poll.h to poll.h
On 12/19/16 12:01 PM, Alistair Francis wrote: > On Sat, Dec 17, 2016 at 7:55 AM, Konrad Rzeszutek Wilk > wrote: >> On Fri, Dec 16, 2016 at 02:56:04PM -0800, Alistair Francis wrote: >>> To avoid this build error with newer build systems: >> >> And what is newer? GCC 5? 6? > > In this case it is GCC 5. > No. Its a libc thing. I wonder what libc you're using because glibc 2.24 still has it at sys/pool.h for me. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 5/7] tools/blktap2: Update sys/signal.h to signal.h
On 12/19/16 12:02 PM, Alistair Francis wrote: > On Sat, Dec 17, 2016 at 7:56 AM, Konrad Rzeszutek Wilk > wrote: >> On Fri, Dec 16, 2016 at 02:56:05PM -0800, Alistair Francis wrote: >>> To avoid this build error with newer build systems: >>> error: #warning redirecting incorrect #include to >>> [-Werror=cpp] >> >> And what is the 'newer build system' you speak off? > > Sorry I should have specified more there. > > It's GCC 5 that I am seeing the problem on. Same as the last patch. This is your libc. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xsm: allow relevant permission during migrate and gpu-passthrough.
On 12/19/16 10:02 AM, Doug Goldstein wrote:
> On 12/14/16 3:09 PM, Daniel De Graaf wrote:
>> On 12/12/2016 09:00 AM, Anshul Makkar wrote:
>>> During guest migrate allow permission to prevent
>>> spurious page faults.
>>> Prevents these errors:
>>> d73: Non-privileged (73) attempt to map I/O space
>>>
>>> avc: denied { set_misc_info } for domid=0 target=11
>>> scontext=system_u:system_r:dom0_t
>>> tcontext=system_u:system_r:domU_t tclass=domain
>>>
>>> GPU passthrough for hvm guest:
>>> avc: denied { send_irq } for domid=0 target=10
>>> scontext=system_u:system_r:dom0_t
>>> tcontext=system_u:system_r:domU_t tclass=hvm
>>>
>>> Signed-off-by: Anshul Makkar
>>
>> Acked-by: Daniel De Graaf
>>
>
> Daniel,
>
> Should this be backported to 4.8?
>
FWIW, Daniel's email is bouncing. Anshul, do you want to test/confirm?
--
Doug Goldstein
signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-4.8-testing test] 103752: regressions - trouble: broken/fail/pass
flight 103752 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/103752/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken REGR. vs. 103160 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken REGR. vs. 103160 test-amd64-amd64-xl-qemut-debianhvm-amd64 3 host-install(3) broken REGR. vs. 103160 test-amd64-i386-freebsd10-i386 3 host-install(3) broken REGR. vs. 103160 test-amd64-i386-xl-raw3 host-install(3)broken REGR. vs. 103160 test-amd64-amd64-xl-xsm 3 host-install(3)broken REGR. vs. 103160 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 3 host-install(3) broken REGR. vs. 103160 test-amd64-amd64-xl-qemuu-win7-amd64 3 host-install(3) broken REGR. vs. 103160 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 103160 test-xtf-amd64-amd64-43 host-install(3)broken REGR. vs. 103160 test-amd64-i386-rumprun-i386 3 host-install(3)broken REGR. vs. 103160 test-amd64-i386-libvirt-xsm 3 host-install(3)broken REGR. vs. 103160 test-amd64-i386-migrupgrade 8 xen-install/dst_host fail REGR. vs. 103160 test-amd64-i386-qemuu-rhel6hvm-intel 9 redhat-install fail REGR. vs. 103160 test-amd64-i386-libvirt 9 debian-install fail REGR. vs. 103160 test-amd64-i386-xl-xsm 11 guest-start fail REGR. vs. 103160 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 15 guest-start/debianhvm.repeat fail REGR. vs. 103160 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 3 host-install(3)broken REGR. vs. 103160 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeatfail like 103103 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 103160 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass version targeted for testing: xen b996efb23864f7135db3578a3a2059fe2f3c1a98 baseline version: xen 7967dafe6acce66193a8a81fa88ac4d3eb7b48aa Last test of basis 103160 2016-12-11 20:43:59 Z8 days Testing same since 103752 2016-12-19 16:14:47 Z0 days1 attempts People who touched revisions under test: Andrew Cooper jobs:
Re: [Xen-devel] [PATCH] Xen: ARM: Zero reserved fields of xatp before making hypervisor call
On 12/19/16 12:49, Stefano Stabellini wrote:
> On Mon, 19 Dec 2016, Juergen Gross wrote:
>> On 19/12/16 03:56, Jiandi An wrote:
>>> Ensure all reserved fields of xatp are zero before making hypervisor
>>> call to XEN in xen_map_device_mmio(). xenmem_add_to_physmap_one() in
>>> XEN fails the mapping request if extra.res reserved field in xatp is
>>> not zero for XENMAPSPACE_dev_mmio request.
>>>
>>> Signed-off-by: Jiandi An
>>> ---
>>> drivers/xen/arm-device.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/xen/arm-device.c b/drivers/xen/arm-device.c
>>> index 778acf8..208273b 100644
>>> --- a/drivers/xen/arm-device.c
>>> +++ b/drivers/xen/arm-device.c
>>> @@ -87,6 +87,9 @@ static int xen_map_device_mmio(const struct resource
>>> *resources,
>>> idxs[j] = XEN_PFN_DOWN(r->start) + j;
>>> }
>>>
>>> + /* Ensure reserved fields are set to zero */
>>> + memset(&xatp, 0, sizeof(xatp));
>>> +
>>> xatp.domid = DOMID_SELF;
>>> xatp.size = nr;
>>> xatp.space = XENMAPSPACE_dev_mmio;
>>
>> Instead of setting xatp to 0 in each iteration I'd prefer a static
>> initialization of .domid and .space:
>>
>> struct xen_add_to_physmap_range xatp = {
>> .domid = DOMID_SELF,
>> .space = XENMAPSPACE_dev_mmio
>> };
>
> +1
>
Hi Juergen,
Thanks for you comments. xatp is passed to XEN via the hypervisor call in each
loop.
XEN touches xatp and returns it back. For example XEN returns error of
underlying mapping call in the err[] array in xatp. (The err[] is not checked
after the hypervisor call returns and it's a bug to be addressed in a separate
patch) XEN could theoretically corrupt xatp when it's returned. And the loop
would go on to the next iteration passing in whatever that's in xatp returned
by the previous hypervisor call. Harder to debug in my opinion if xatp get
corrupted by XEN somehow when a bug is introduced in XEN. At first I put the
memset of xatp at the beginning outside of the loop. But I thought it's better
to initialize xatp that's passed in each time a hypervisor call is made so we
know exactly we set going into the hypervisor call.
--
Jiandi An
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
Foundation Collaborative Project.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] vvmx: fix the wrong address width in c/s 08fac63
> From: Zhang, Haozhong > Sent: Monday, December 19, 2016 9:14 AM > > c/s 08fac63 misused v->domain-arch.paging.gfn_bits as the width of > guest physical address and missed adding PAGE_SHIFT to it when > checking vmxon operand. > > Signed-off-by: Haozhong Zhang Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] vvmx: replace vmreturn() by vmsucceed() and vmfail*()
> From: Zhang, Haozhong > Sent: Thursday, December 15, 2016 8:46 PM > > Replace vmreturn() by vmsucceed(), vmfail(), vmfail_valid() and > vmfail_invalid(), which are consistent to the pseudo code on Intel > SDM, and allow to return VM instruction error numbers to L1 > hypervisor. > > Signed-off-by: Haozhong Zhang > Acked-by: Andrew Cooper Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/paging: Rename paging_mark_pfn_dirty() and use pfn_t
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, December 14, 2016 10:26 PM > > paging_mark_gfn_dirty() actually takes a pfn, even by paramter name. Rename > the function and alter the type to pfn_t to match. > > Push pfn_t into the LOGDIRTY_IDX() macros, and clean up a couple of local > variable types in paging_mark_pfn_dirty(). > > Leave an explicit comment in vmx_vcpu_flush_pml_buffer() when we intentally > perform a straight conversion from gfn to pfn. > > Signed-off-by: Andrew Cooper Reviewed-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/x86: Improve hypercall page writing
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Tuesday, December 20, 2016 12:55 AM > > Use memcpy() rather than individual writes with explicit casts. The > __builtin_memcpy() wrapper does a better job at combining adjacent writes into > a larger word size. > > This results in better generated assembly. No functional change. > > Signed-off-by: Andrew Cooper Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-3.18 test] 103750: regressions - trouble: broken/fail/pass
flight 103750 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/103750/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-xsm3 host-install(3) broken in 103743 REGR. vs. 101675 test-amd64-i386-libvirt-pair 9 xen-boot/src_hostfail REGR. vs. 101675 test-amd64-i386-libvirt-pair 10 xen-boot/dst_hostfail REGR. vs. 101675 test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-bootfail REGR. vs. 101675 test-amd64-amd64-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-xl-multivcpu 6 xen-bootfail REGR. vs. 101675 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-qemuu-nested-intel 6 xen-boot fail REGR. vs. 101675 test-amd64-i386-pair 9 xen-boot/src_hostfail REGR. vs. 101675 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101675 test-amd64-i386-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-amd64-pvgrub 6 xen-bootfail REGR. vs. 101675 test-amd64-amd64-libvirt-pair 9 xen-boot/src_host fail REGR. vs. 101675 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host fail REGR. vs. 101675 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-libvirt-xsm 6 xen-boot fail REGR. vs. 101675 build-i386-pvops 5 kernel-build fail in 102732 REGR. vs. 101675 build-armhf-libvirt 4 host-build-prep fail in 102875 REGR. vs. 101675 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail in 103743 REGR. vs. 101675 Tests which are failing intermittently (not blocking): test-amd64-i386-freebsd10-amd64 3 host-install(3) broken in 103743 pass in 103750 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken in 103743 pass in 103750 test-amd64-i386-qemuu-rhel6hvm-amd 15 capture-logs(15) broken in 103743 pass in 103750 test-amd64-i386-xl-qemut-debianhvm-amd64 3 host-install(3) broken pass in 103738 test-amd64-amd64-xl-rtds 3 host-install(3) broken pass in 103738 test-amd64-amd64-xl-qemuu-win7-amd64 3 host-install(3) broken pass in 103738 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken pass in 103743 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken pass in 103743 test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail in 103312 pass in 103750 test-armhf-armhf-libvirt 4 host-ping-check-native fail in 103688 pass in 103750 test-amd64-amd64-libvirt 6 xen-boot fail in 103743 pass in 102823 test-armhf-armhf-libvirt-raw 14 guest-start/debian.repeat fail in 103743 pass in 103750 test-amd64-amd64-pair 9 xen-boot/src_host fail pass in 102732 test-amd64-amd64-pair10 xen-boot/dst_host fail pass in 102732 test-amd64-amd64-xl-xsm 6 xen-boot fail pass in 102732 test-amd64-amd64-i386-pvgrub 6 xen-boot fail pass in 102754 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 102823 test-amd64-amd64-xl-credit2 6 xen-boot fail pass in 102875 test-amd64-i386-xl-raw6 xen-boot fail pass in 102875 test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail pass in 102974 test-amd64-i386-freebsd10-i386 6 xen-boot fail pass in 103169 test-amd64-i386-xl-qemuu-winxpsp3 6 xen-boot fail pass in 103312 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-boot fail pass in 103688 test-amd64-i386-xl6 xen-boot fail pass in 103738 test-armhf-armhf-xl-xsm 11 guest-startfail pass in 103738 test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat fail pass in 103738 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 5 xen-install fail pass in 103743 test-amd64-amd64-libvirt 5 xen-installfail pass in 103743 test-amd64-i386-xl-xsm 11 guest-startfail pass in 103743 test-amd64-i386-qemuu-rhel6hvm-intel 9 redhat-install fail pass in 103743 test-amd64-i386-qemut-rhel6hvm-intel 11 guest-start/redhat.repeat fail pass in 103743 Regressions which are regarded as allowable (not blocking): test-amd64-i386-rumprun-i386 3 host-install(3) broken blocked in 101675 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 103312 like 101662 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail in 103738 like 101675 test-amd64-amd64-xl-rtds 9 debian-install fail in 103738 like 101675 test-armhf-armhf-xl-vhd 9 debian-di-installfail like 101662 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 101675 test-armhf-armhf-libvirt-q
Re: [Xen-devel] [PATCH v3] x86/apicv: fix RTC periodic timer and apicv issue
> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
> Sent: Friday, December 16, 2016 5:40 PM
>
> From 89fffdd6b563b2723e24d17231715bb8c9f24f90 Mon Sep 17 00:00:00 2001
> From: Quan Xu
> Date: Fri, 16 Dec 2016 17:24:01 +0800
> Subject: [PATCH v3] x86/apicv: fix RTC periodic timer and apicv issue
>
> When Xen apicv is enabled, wall clock time is faster on Windows7-32
> guest with high payload (with 2vCPU, captured from xentrace, in
> high payload, the count of IPI interrupt increases rapidly between
> these vCPUs).
>
> If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector 0xd1)
> are both pending (index of bit set in vIRR), unfortunately, the IPI
> intrrupt is high priority than periodic timer interrupt. Xen updates
> IPI interrupt bit set in vIRR to guest interrupt status (RVI) as a high
> priority and apicv (Virtual-Interrupt Delivery) delivers IPI interrupt
> within VMX non-root operation without a VM-Exit. Within VMX non-root
> operation, if periodic timer interrupt index of bit is set in vIRR and
> highest, the apicv delivers periodic timer interrupt within VMX non-root
> operation as well.
>
> But in current code, if Xen doesn't update periodic timer interrupt bit
> set in vIRR to guest interrupt status (RVI) directly, Xen is not aware
> of this case to decrease the count (pending_intr_nr) of pending periodic
> timer interrupt, then Xen will deliver a periodic timer interrupt again.
>
> And that we update periodic timer interrupt in every VM-entry, there is
> a chance that already-injected instance (before EOI-induced exit happens)
> will incur another pending IRR setting if there is a VM-exit happens
> between virtual interrupt injection (vIRR->0, vISR->1) and EOI-induced
> exit (vISR->0), since pt_intr_post hasn't been invoked yet, then the
> guest receives more periodic timer interrupt.
>
> So we set eoi_exit_bitmap for intack.vector when it's higher than
> pending periodic time interrupts. This way we can guarantee there's
> always a chance to post periodic time interrupts when periodic time
> interrupts becomes the highest one.
>
> Signed-off-by: Quan Xu
I suppose you've verified this new version, but still would like get
your explicit confirmation - did you still see time accuracy issue
in your side? Have you tried other guest OS types other than
Win7-32?
> ---
> xen/arch/x86/hvm/vmx/intr.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
> index 639a705..d7a5716 100644
> --- a/xen/arch/x86/hvm/vmx/intr.c
> +++ b/xen/arch/x86/hvm/vmx/intr.c
> @@ -315,9 +315,17 @@ void vmx_intr_assist(void)
> * Set eoi_exit_bitmap for periodic timer interrup to cause
> EOI-induced VM
> * exit, then pending periodic time interrups have the chance to be
> injected
> * for compensation
> +* Set eoi_exit_bitmap for intack.vector when it's higher than pending
> +* periodic time interrupts. This way we can guarantee there's always
> a chance
> +* to post periodic time interrupts when periodic time interrupts
> becomes the
> +* highest one
> */
> -if (pt_vector != -1)
> -vmx_set_eoi_exit_bitmap(v, pt_vector);
> +if ( pt_vector != -1 ) {
> +if ( intack.vector > pt_vector )
> +vmx_set_eoi_exit_bitmap(v, intack.vector);
> +else
> +vmx_set_eoi_exit_bitmap(v, pt_vector);
> +}
Above can be simplified as one line change:
if ( pt_vector != -1 )
vmx_set_eoi_exit_bitmap(v, intack.vector);
>
> /* we need update the RVI field */
> __vmread(GUEST_INTR_STATUS, &status);
> @@ -334,7 +342,8 @@ void vmx_intr_assist(void)
> __vmwrite(EOI_EXIT_BITMAP(i),
> v->arch.hvm_vmx.eoi_exit_bitmap[i]);
> }
>
> -pt_intr_post(v, intack);
> +if ( intack.vector == pt_vector )
> +pt_intr_post(v, intack);
> }
> else
> {
> --
> 1.7.12.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] x86/apicv: fix RTC periodic timer and apicv issue
On December 20, 2016 1:37 PM, Tian, Kevin wrote:
>> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>> Sent: Friday, December 16, 2016 5:40 PM
>>
>> From 89fffdd6b563b2723e24d17231715bb8c9f24f90 Mon Sep 17 00:00:00
>2001
>> From: Quan Xu
>> Date: Fri, 16 Dec 2016 17:24:01 +0800
>> Subject: [PATCH v3] x86/apicv: fix RTC periodic timer and apicv issue
>>
>> When Xen apicv is enabled, wall clock time is faster on Windows7-32
>> guest with high payload (with 2vCPU, captured from xentrace, in high
>> payload, the count of IPI interrupt increases rapidly between these
>> vCPUs).
>>
>> If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector
>> 0xd1) are both pending (index of bit set in vIRR), unfortunately, the
>> IPI intrrupt is high priority than periodic timer interrupt. Xen
>> updates IPI interrupt bit set in vIRR to guest interrupt status (RVI)
>> as a high priority and apicv (Virtual-Interrupt Delivery) delivers IPI
>> interrupt within VMX non-root operation without a VM-Exit. Within VMX
>> non-root operation, if periodic timer interrupt index of bit is set in
>> vIRR and highest, the apicv delivers periodic timer interrupt within
>> VMX non-root operation as well.
>>
>> But in current code, if Xen doesn't update periodic timer interrupt
>> bit set in vIRR to guest interrupt status (RVI) directly, Xen is not
>> aware of this case to decrease the count (pending_intr_nr) of pending
>> periodic timer interrupt, then Xen will deliver a periodic timer interrupt
>again.
>>
>> And that we update periodic timer interrupt in every VM-entry, there
>> is a chance that already-injected instance (before EOI-induced exit
>> happens) will incur another pending IRR setting if there is a VM-exit
>> happens between virtual interrupt injection (vIRR->0, vISR->1) and
>> EOI-induced exit (vISR->0), since pt_intr_post hasn't been invoked
>> yet, then the guest receives more periodic timer interrupt.
>>
>> So we set eoi_exit_bitmap for intack.vector when it's higher than
>> pending periodic time interrupts. This way we can guarantee there's
>> always a chance to post periodic time interrupts when periodic time
>> interrupts becomes the highest one.
>>
>> Signed-off-by: Quan Xu
>
>I suppose you've verified this new version, but still would like get your
>explicit confirmation - did you still see time accuracy issue in your side?
>Have you tried other guest OS types other than Win7-32?
>
I only verified it on win7-32 guest..
I will continue to verify it on other windows guest (I think windows is enough,
right?)
>> ---
>> xen/arch/x86/hvm/vmx/intr.c | 15 ---
>> 1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
>> index 639a705..d7a5716 100644
>> --- a/xen/arch/x86/hvm/vmx/intr.c
>> +++ b/xen/arch/x86/hvm/vmx/intr.c
>> @@ -315,9 +315,17 @@ void vmx_intr_assist(void)
>> * Set eoi_exit_bitmap for periodic timer interrup to cause
>EOI-induced VM
>> * exit, then pending periodic time interrups have the chance
>to be injected
>> * for compensation
>> +* Set eoi_exit_bitmap for intack.vector when it's higher than
>pending
>> +* periodic time interrupts. This way we can guarantee there's
>always a chance
>> +* to post periodic time interrupts when periodic time
>interrupts becomes the
>> +* highest one
>> */
>> -if (pt_vector != -1)
>> -vmx_set_eoi_exit_bitmap(v, pt_vector);
>> +if ( pt_vector != -1 ) {
>> +if ( intack.vector > pt_vector )
>> +vmx_set_eoi_exit_bitmap(v, intack.vector);
>> +else
>> +vmx_set_eoi_exit_bitmap(v, pt_vector);
>> +}
>
>Above can be simplified as one line change:
> if ( pt_vector != -1 )
> vmx_set_eoi_exit_bitmap(v, intack.vector);
>
Agreed.. I found this change doesn't look good, but I had no idea to improve
it.. thanks.
Also sorry for the late v3.
Quan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-4.7-testing test] 103754: regressions - trouble: broken/fail/pass
flight 103754 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/103754/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit2 3 host-install(3)broken REGR. vs. 103419 test-amd64-amd64-pygrub 3 host-install(3)broken REGR. vs. 103419 test-amd64-i386-libvirt 3 host-install(3)broken REGR. vs. 103419 test-amd64-i386-freebsd10-amd64 3 host-install(3) broken REGR. vs. 103419 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken REGR. vs. 103419 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 103419 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 3 host-install(3) broken REGR. vs. 103419 test-amd64-i386-xl-qemuu-winxpsp3 3 host-install(3) broken REGR. vs. 103419 test-xtf-amd64-amd64-23 host-install(3)broken REGR. vs. 103419 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken REGR. vs. 103419 test-armhf-armhf-libvirt-xsm 11 guest-start fail REGR. vs. 103419 test-amd64-i386-qemut-rhel6hvm-intel 9 redhat-install fail REGR. vs. 103419 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 103419 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 103419 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 103419 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 103419 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 103419 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 103419 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 103419 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass version targeted for testing: xen c5feb915d8536f235b74195bf33f4bb0e82734cd baseline version: xen 7a71cea02afe2bf0f04f1cbf91931081dbe9dd76 Last test of basis 103419 2016-12-15 19:54:04 Z4 days Testing same since 103754 2016-12-19 16:15:57 Z0 days1 attempts People who touched revisions under test: Andrew Cooper jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pa
Re: [Xen-devel] Xen: ARM: Support for mapping ECAM PCIe Config Space Specified In Static ACPI Table
On 12/19/16 07:11, Julien Grall wrote: > > > On 19/12/2016 13:20, Jaggi, Manish wrote: >>> On 16/12/2016 15:49, Julien Grall wrote: On 14/12/16 08:00, Jiandi An wrote: > Xen currently doesn't map ECAM space specified in static ACPI table. > Seeking opinion on how this should be handled properly. > Each root complex ECAM region takes up 64K 4K pages (256MB). > For some platforms there might be multiple root complexes. > Is the plan to map all at once?Julien has mentioned support > for mapping ECAM may come when support for PCI passthrough is > added, is that right? What mechanism will it be? Will Xen or > dom0 be the one that parses the staic ACPI tables and map the ECAM space? For performance reason, each ECAM region would need to be mapped at once, so the stage-2 page table could take advantage of superpage (it will mostly be 2MB). Now, I don't think Xen should map the ECAM region in stage-2 before hand. All the regions may not be described in the MCFG and I would like to see a generic solution. Looking at the code (see pci_create_ecam_create in drivers/pci/ecam.c), ioremap is used. I believe the problem is the same for the 2 other threads you sent ( [1] and [2]). So it might be good to look at hooking up a call to XENMEM_add_to_physmap_range in ioremap. Any opinions? >>> >>> I thought a bit more about it and I realized we need to be cautious on >>> how to proceed here. >>> >>> DOM0 will have a mix of real devices and emulated devices (e.g some part >>> of the GIC). For the emulated devices, DOM0 should not call >>> XENMEM_add_to_physmap_range. However, DOM0 is not aware what is emulated >>> or not, so even the current approach (hooking up in platform device) >>> seems fragile. We rely on Xen to say "this region cannot be mapped". >>> >> Why not add support for parsing ACPI tables in Xen, from linux, as we >> parse dt. > > Because MMIO can be described in ASL too. I would rather avoid to have a > different behavior depending whether the MMIO has been described in static > table or ASL. > > Cheers, > I also think hooking up a call to XENMEM_add_to_physmap_range in ioremap is not a good approach as ioremap() is commonly called in so many places. It's not ideal to make a check of am I dom0 running under xen every time ioremap() is called. And Julien also pointed out, not every call to ioremap() needs a stage 2 mapping. -- Jiandi An Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
