Re: [Xen-devel] bug: unable to LZ4 decompress ub1910 installer kernel when launching domU

[Jeremi Piotrowski]

On Tue, Dec 03, 2019 at 09:02:18AM +0100, Jan Beulich wrote:
> On 01.12.2019 18:47, Jeremi Piotrowski wrote:
> > On Thu, Oct 24, 2019 at 10:12:19AM +0200, Jan Beulich wrote:
> >> On 23.10.2019 22:33, Pry Mar wrote:
> >>> Hello xen-devel,
> >>>
> >>> https://paste.debian.net/plain/1109374
> >>>
> >>> shows my traces from a healthy CentOS 8, xen-4.12.1 dom0 when trying
> >>> to launch a pv install of the newly released ub1910. The source is a
> >>> block-attached ISO and the kernel/ramdisk was copied off locally.
> >>
> >> Would you please increase verbosity (xl -vvv create ...) such that we
> >> can see what exactly the decompression code doesn't like about this
> >> kernel image?
> > 
> > I stumbled across the same issue, below is the xl - create output.
> > 
> > Parsing config from ubuntu.cfg
> > libxl: debug: libxl_create.c:1693:do_domain_create: Domain 0:ao 
> > 0x55a598e77190: create: how=(nil) callback=(nil) poller=0x55a598e74040
> > libxl: debug: libxl_device.c:397:libxl__device_disk_set_backend: Disk 
> > vdev=xvda spec.backend=unknown
> > libxl: debug: libxl_device.c:358:disk_try_backend: Disk vdev=xvda, backend 
> > phy unsuitable due to format qcow2
> > libxl: debug: libxl_device.c:431:libxl__device_disk_set_backend: Disk 
> > vdev=xvda, using backend qdisk
> > libxl: debug: libxl_create.c:1018:initiate_domain_create: Domain 11:running 
> > bootloader
> > libxl: debug: libxl_bootloader.c:334:libxl__bootloader_run: Domain 11:no 
> > bootloader configured, using user supplied kernel
> > libxl: debug: libxl_event.c:689:libxl__ev_xswatch_deregister: watch 
> > w=0x55a598e827a8: deregister unregistered
> > domainbuilder: detail: xc_dom_allocate: cmdline="", features=""
> > libxl: debug: libxl_dom.c:799:libxl__build_pv: pv kernel mapped 0 path 
> > /tank/xenscratch/ubuntu/vmlinuz-5.3.0-23-generic
> > domainbuilder: detail: xc_dom_kernel_file: 
> > filename="/tank/xenscratch/ubuntu/vmlinuz-5.3.0-23-generic"
> > domainbuilder: detail: xc_dom_malloc_filemap: 11132 kB
> > domainbuilder: detail: xc_dom_boot_xen_init: ver 4.12, caps xen-3.0-x86_64 
> > xen-3.0-x86_32p 
> > domainbuilder: detail: xc_dom_parse_image: called
> > domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader 
> > ... 
> > domainbuilder: detail: loader probe failed
> > domainbuilder: detail: xc_dom_find_loader: trying HVM-generic loader ... 
> > domainbuilder: detail: loader probe failed
> > domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... 
> > domainbuilder: detail: LZ4 decompression error: decoding failed
> 
> This suggests that the decoding logic didn't like the input. Since as
> per the other mail manual decompression works, this will likely need
> debugging by someone able to repro.
> 
> Jan

I'm able to repro, and I isolated the code from xc_dom_bzimageloader.c,
xc_dom_decompress_lz4.c and /xen/common/lz4/decompress.c such that I can
test more easily (I'm using code from 4.12.1). I'm testing with
vmlinuz-5.3.0-23-generic installed in ubuntu-19.10.

What I see is that the code fails at the first frame at decompress.c:282
(if (unlikely((unsigned long)cpy < (unsigned long)op))).
because cpy == (op - 1).
decompress.c:265 (cpy = op + length - (STEPSIZE-4);) gets executed twice and
prints:

length=4
length=3

STEPSIZE is 8 (x86_64). So this has to fail. The STEPSIZE gave me the
idea to rebuild the code as 32-bit and decompression works correctly.

Any suggestions how to proceed?

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

[Xen-devel] [xen-4.13-testing test] 144509: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  ea6a2c4b776569d0da1521961520f61e9d86acce
baseline version:
 xen  8ba357fc326c9e6f2f7d39c461955c110fea9a8a

Last test of basis   144500  2019-12-03 00:06:07 Z1 days
Testing same since   144509  2019-12-03 14:08:04 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Roger Pau Monne 
  Roger Pau Monné 
  Wei Liu 

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

[Xen-devel] [PATCH v2] x86/AMD: unbreak CPU hotplug on AMD systems without RstrFpErrPtrs

[Igor Druzhinin]

If the feature is not present Xen will try to force X86_BUG_FPU_PTRS
feature at CPU identification time. This is especially noticeable in
PV-shim that usually hotplugs its vCPUs. We either need to restrict this
action for boot CPU only or allow secondary CPUs to modify
forced CPU capabilities at runtime. Choose the former since modifying
forced capabilities out of boot path leaves the system in potentially
inconsistent state.

Signed-off-by: Igor Druzhinin 
---
Changes in v2:
- pick the former approach instead of the latter
---
 xen/arch/x86/cpu/amd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index fec2830..8b5f0f2 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -583,7 +583,7 @@ static void init_amd(struct cpuinfo_x86 *c)
 * Older AMD CPUs don't save/load FOP/FIP/FDP unless an FPU exception
 * is pending.  Xen works around this at (F)XRSTOR time.
 */
-   if (!cpu_has(c, X86_FEATURE_RSTR_FP_ERR_PTRS))
+   if (c == _cpu_data && !cpu_has(c, X86_FEATURE_RSTR_FP_ERR_PTRS))
setup_force_cpu_cap(X86_BUG_FPU_PTRS);
 
/*
-- 
2.7.4


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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10   fail  like 144495
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 144495
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 144495
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 144495
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 144495
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 144495
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 144495
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass

version targeted for testing:
 qemuu24d68f3737be432df15694f7c7a2d26d7d7d1189
baseline version:
 qemuu39032981fa851d25fb27527f25f046fed800e585

Last test of basis   144495  2019-12-02 17:36:27 Z1 days
Testing same since   144507  2019-12-03 11:06:29 Z0 days1 attempts


People who touched revisions under test:
  Cameron Esfahani 
  Paolo Bonzini 
  Peter Maydell 

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

[Xen-devel] [PATCH] x86/svm: Fix handling of EFLAGS.RF on task switch

[Andrew Cooper]

VT-x updates RF before vmexit, so eflags written into the outgoing TSS happens
to be correct.  SVM does not update RF before vmexit, and instead provides it
via a bit in exitinfo2.

In practice, needing RF set in the outgoing state occurs when a task gate is
used to handle faults.

Extend hvm_task_switch() with an extra_eflags parameter which gets fed into
the outgoing TSS, and fill it in suitably from the SVM vmexit information.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Jun Nakajima 
CC: Kevin Tian 
CC: Juergen Gross 

Kevin: There is no help in the SDM about this.  RF is not mentioned in the
list of state either modified or unmodified by hardware on a task switch
vmexit.  This conclusion has been drawn from looking at the actual VMExit
state given an XTF test poking every corner of TASK_SWITCH VMExits.

Juergen: I know its getting stupidly late in the day, but this, like the
previous fixes, want backporting.  OTOH, the likelihood of not fixing it
causing harm to VMs is minimal, unlike the earlier task switch fixes.
---
 xen/arch/x86/hvm/hvm.c| 4 ++--
 xen/arch/x86/hvm/svm/svm.c| 3 ++-
 xen/arch/x86/hvm/vmx/vmx.c| 3 ++-
 xen/include/asm-x86/hvm/hvm.h | 2 +-
 4 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 7f556171bd..47573f71b8 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2913,7 +2913,7 @@ void hvm_prepare_vm86_tss(struct vcpu *v, uint32_t base, 
uint32_t limit)
 
 void hvm_task_switch(
 uint16_t tss_sel, enum hvm_task_switch_reason taskswitch_reason,
-int32_t errcode, unsigned int insn_len)
+int32_t errcode, unsigned int insn_len, unsigned int extra_eflags)
 {
 struct vcpu *v = current;
 struct cpu_user_regs *regs = guest_cpu_user_regs();
@@ -2988,7 +2988,7 @@ void hvm_task_switch(
 eflags &= ~X86_EFLAGS_NT;
 
 tss.eip= regs->eip + insn_len;
-tss.eflags = eflags;
+tss.eflags = eflags | extra_eflags;
 tss.eax= regs->eax;
 tss.ecx= regs->ecx;
 tss.edx= regs->edx;
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 0fb1908c18..6ae43999ff 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2812,7 +2812,8 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
 if ( (vmcb->exitinfo2 >> 44) & 1 )
 errcode = (uint32_t)vmcb->exitinfo2;
 
-hvm_task_switch(vmcb->exitinfo1, reason, errcode, insn_len);
+hvm_task_switch(vmcb->exitinfo1, reason, errcode, insn_len,
+(vmcb->exitinfo2 & (1ul << 48)) ? X86_EFLAGS_RF : 0);
 break;
 }
 
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 7450cbe40d..bafc3b30c5 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3963,7 +3963,8 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
 else
  ecode = -1;
 
-hvm_task_switch(exit_qualification, reasons[source], ecode, inst_len);
+hvm_task_switch(exit_qualification, reasons[source], ecode, inst_len,
+0 /* EFLAGS.RF already updated. */);
 break;
 }
 case EXIT_REASON_CPUID:
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 17fb7efa6e..1d7b66f927 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -296,7 +296,7 @@ void hvm_set_rdtsc_exiting(struct domain *d, bool_t enable);
 enum hvm_task_switch_reason { TSW_jmp, TSW_iret, TSW_call_or_int };
 void hvm_task_switch(
 uint16_t tss_sel, enum hvm_task_switch_reason taskswitch_reason,
-int32_t errcode, unsigned int insn_len);
+int32_t errcode, unsigned int insn_len, unsigned int extra_eflags);
 
 enum hvm_access_type {
 hvm_access_insn_fetch,
-- 
2.11.0


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

[Xen-devel] [xen-unstable test] 144503: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  42c8cdc039d6dc7d6aea8008bb24622eaf4b7bc8
baseline version:
 xen  f19af2f1138e89bdf05e8cfcab26a190e3771c4b

Last test of basis   144497  2019-12-02 18:37:15 Z1 days
Testing same since   144503  2019-12-03 08:58:06 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Yi Sun 

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

[Xen-devel] [xen-4.11-testing test] 144505: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  239d37e514c93e29d50d71f734b1dc453b2236a6
baseline version:
 xen  f137d4c8df08b202a34e5e092f1ab14a97c7144e

Last test of basis   144376  2019-11-29 09:36:36 Z4 days
Testing same since   144496  2019-12-02 18:37:16 Z1 days2 attempts


People who touched revisions under test:
  Amit Singh Tomar 
  Julien Grall 

jobs:
 build-amd64-xsm 

Re: [Xen-devel] [PATCH] x86/debug: Plumb pending_dbg through the monitor and devicemodel interfaces

[Tamas K Lengyel]

> diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
> index 959083d8c4..76676ff4c0 100644
> --- a/xen/include/public/vm_event.h
> +++ b/xen/include/public/vm_event.h
> @@ -281,6 +281,7 @@ struct vm_event_debug {
>  uint32_t insn_length;
>  uint8_t type;/* HVMOP_TRAP_* */
>  uint8_t _pad[3];
> +uint64_t pending_dbg;

This is just a nitpick but I would prefer if we had the _pad field as
the last element in the struct and keep all 64-bit members up in the
front.

Thanks,
Tamas

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

Re: [Xen-devel] [PATCH] x86/debug: Plumb pending_dbg through the monitor and devicemodel interfaces

[Tamas K Lengyel]

On Tue, Dec 3, 2019 at 1:23 PM Andrew Cooper  wrote:
>
> On 03/12/2019 18:16, Tamas K Lengyel wrote:
> > On Tue, Dec 3, 2019 at 1:09 PM Andrew Cooper  
> > wrote:
> >> On 03/12/2019 18:05, Tamas K Lengyel wrote:
>  diff --git a/xen/include/public/vm_event.h 
>  b/xen/include/public/vm_event.h
>  index 959083d8c4..76676ff4c0 100644
>  --- a/xen/include/public/vm_event.h
>  +++ b/xen/include/public/vm_event.h
>  @@ -281,6 +281,7 @@ struct vm_event_debug {
>   uint32_t insn_length;
>   uint8_t type;/* HVMOP_TRAP_* */
>   uint8_t _pad[3];
>  +uint64_t pending_dbg;
> >>> This is just a nitpick but I would prefer if we had the _pad field as
> >>> the last element in the struct and keep all 64-bit members up in the
> >>> front.
> >> Well the reason I did it like this is that this version will continue to
> >> function with older introspection code.  The extra field is within a
> >> union and no other data moves.
> >>
> >> By repositioning to the start, it will almost certainly break older
> >> introspection code even though it compiled correctly.
> >>
> >> Your choice.
> > We are already bumping the interface version for the next release so
> > old introspection code by design will stop working. We make no ABI
> > stability guarantees between interface versions so this is a
> > non-issue.
>
> Ok fine.  Updated locally, but I won't send a new version of the patch
> just for this delta.
>
> diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
> index 76676ff4c0..8c24a58964 100644
> --- a/xen/include/public/vm_event.h
> +++ b/xen/include/public/vm_event.h
> @@ -278,10 +278,10 @@ struct vm_event_singlestep {
>
>  struct vm_event_debug {
>  uint64_t gfn;
> +uint64_t pending_dbg;
>  uint32_t insn_length;
>  uint8_t type;/* HVMOP_TRAP_* */
>  uint8_t _pad[3];
> -uint64_t pending_dbg;
>  };
>
>  struct vm_event_mov_to_msr {
>
>
> However, this does raise the question of why insn_length is uint32_t.
> It has a value which is at most 15.
>

We could shorten it (feel free to do that as part of this patch or
another if you are inclined to do so). Overall I don't think it would
make much of a difference since we aren't saving any space on the ring
page with that because its used in a union with larger structs.

Tamas

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

Re: [Xen-devel] [PATCH] xen/blkback: Avoid unmapping unmapped grant pages

[Jens Axboe]

On 11/26/19 8:36 AM, SeongJae Park wrote:

From: SeongJae Park 

For each I/O request, blkback first maps the foreign pages for the
request to its local pages.  If an allocation of a local page for the
mapping fails, it should unmap every mapping already made for the
request.

However, blkback's handling mechanism for the allocation failure does
not mark the remaining foreign pages as unmapped.  Therefore, the unmap
function merely tries to unmap every valid grant page for the request,
including the pages not mapped due to the allocation failure.  On a
system that fails the allocation frequently, this problem leads to
following kernel crash.

   [  372.012538] BUG: unable to handle kernel NULL pointer dereference at 
0001
   [  372.012546] IP: [] gnttab_unmap_refs.part.7+0x1c/0x40
   [  372.012557] PGD 16f3e9067 PUD 16426e067 PMD 0
   [  372.012562] Oops: 0002 [#1] SMP
   [  372.012566] Modules linked in: act_police sch_ingress cls_u32
   ...
   [  372.012746] Call Trace:
   [  372.012752]  [] gnttab_unmap_refs+0x34/0x40
   [  372.012759]  [] xen_blkbk_unmap+0x83/0x150 [xen_blkback]
   ...
   [  372.012802]  [] dispatch_rw_block_io+0x970/0x980 
[xen_blkback]
   ...
   Decompressing Linux... Parsing ELF... done.
   Booting the kernel.
   [0.00] Initializing cgroup subsys cpuset

This commit fixes this problem by marking the grant pages of the given
request that didn't mapped due to the allocation failure as invalid.

Fixes: c6cc142dac52 ("xen-blkback: use balloon pages for all mappings")


Queued up with Roger's reviewed-by.

--
Jens Axboe


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

Re: [Xen-devel] [PATCH] x86/debug: Plumb pending_dbg through the monitor and devicemodel interfaces

[Tamas K Lengyel]

On Tue, Dec 3, 2019 at 1:09 PM Andrew Cooper  wrote:
>
> On 03/12/2019 18:05, Tamas K Lengyel wrote:
> >> diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
> >> index 959083d8c4..76676ff4c0 100644
> >> --- a/xen/include/public/vm_event.h
> >> +++ b/xen/include/public/vm_event.h
> >> @@ -281,6 +281,7 @@ struct vm_event_debug {
> >>  uint32_t insn_length;
> >>  uint8_t type;/* HVMOP_TRAP_* */
> >>  uint8_t _pad[3];
> >> +uint64_t pending_dbg;
> > This is just a nitpick but I would prefer if we had the _pad field as
> > the last element in the struct and keep all 64-bit members up in the
> > front.
>
> Well the reason I did it like this is that this version will continue to
> function with older introspection code.  The extra field is within a
> union and no other data moves.
>
> By repositioning to the start, it will almost certainly break older
> introspection code even though it compiled correctly.
>
> Your choice.

We are already bumping the interface version for the next release so
old introspection code by design will stop working. We make no ABI
stability guarantees between interface versions so this is a
non-issue.

>
> ~Andrew
>
> P.S. What is the point of tail-padding a struct inside a union?

To always make sure all structures used by the interface are 64-bit
aligned without having to keep in mind which one is used in a union
and which one isn't or having to remember their relative position in
the overall structure. So it just reduces the cognitive load.

Tamas

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

Re: [Xen-devel] [PATCH] x86/debug: Plumb pending_dbg through the monitor and devicemodel interfaces

[Tamas K Lengyel]

On Tue, Dec 3, 2019 at 1:31 PM Andrew Cooper  wrote:
>
> On 03/12/2019 18:24, Tamas K Lengyel wrote:
> > On Tue, Dec 3, 2019 at 1:22 PM Tamas K Lengyel  wrote:
> >> On Tue, Dec 3, 2019 at 1:18 PM Andrew Cooper  
> >> wrote:
> >>> On 03/12/2019 18:09, Tamas K Lengyel wrote:
>  On Tue, Dec 3, 2019 at 1:05 PM Tamas K Lengyel  
>  wrote:
> >> diff --git a/xen/include/public/vm_event.h 
> >> b/xen/include/public/vm_event.h
> >> index 959083d8c4..76676ff4c0 100644
> >> --- a/xen/include/public/vm_event.h
> >> +++ b/xen/include/public/vm_event.h
> >> @@ -281,6 +281,7 @@ struct vm_event_debug {
> >>  uint32_t insn_length;
> >>  uint8_t type;/* HVMOP_TRAP_* */
> >>  uint8_t _pad[3];
> >> +uint64_t pending_dbg;
> > This is just a nitpick but I would prefer if we had the _pad field as
> > the last element in the struct and keep all 64-bit members up in the
> > front.
>  Also, since pending_dbg uses unsigned int in Xen, do we need uint64_t
>  for it here? Seems to me a uint32_t would suffice.
> >>> Its %dr6 (but not quite, due to complexity with exception priorities,
> >>> interrupt shadows, and backwards compatibility of the RTM bit with
> >>> inverted polarity).  All other registers have 64 bit fields in the
> >>> interface.
> >>>
> >>> The only interesting bits in it fall within the first 32 which is why it
> >>> is handled in a shorter way within Xen.  Like %cr0, I don't expect
> >>> anything interesting to appear in the upper 32 bits.
> >>>
> >> Perhaps it would be better to call it dr6 in the interface then to
> >> make it more clear that this is a register value?
> >>
> > Which then begs the question, why not just use dr6 that's already
> > present in the vm_event_regs_x86 struct?
>
> Because it (specifically) isn't exactly %dr6.  The ABI it follows is
> strictly like the VT-x's pending_dbg VMCS field.
>
> All bits have positive polarity, and are specific to the debug exception
> in question.
>
> %dr6 accumulates some debug bits or-wise (and until the guest #DB
> handler decides to clear them), some debug bits overwrite-wise, and some
> bits with inverted polarity.
>
> Providing %dr6 alone, either before or after merging pending_dbg, is
> insufficient to disambiguate the debug exception.
>
> pending_dbg is strictly "the new exception(s) to add into the %dr6 mix".
>

OK, thanks for the explanation. SGTM.

Tamas

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

Re: [Xen-devel] [PATCH] x86/debug: Plumb pending_dbg through the monitor and devicemodel interfaces

[Tamas K Lengyel]

On Tue, Dec 3, 2019 at 1:18 PM Andrew Cooper  wrote:
>
> On 03/12/2019 18:09, Tamas K Lengyel wrote:
> > On Tue, Dec 3, 2019 at 1:05 PM Tamas K Lengyel  wrote:
> >>> diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
> >>> index 959083d8c4..76676ff4c0 100644
> >>> --- a/xen/include/public/vm_event.h
> >>> +++ b/xen/include/public/vm_event.h
> >>> @@ -281,6 +281,7 @@ struct vm_event_debug {
> >>>  uint32_t insn_length;
> >>>  uint8_t type;/* HVMOP_TRAP_* */
> >>>  uint8_t _pad[3];
> >>> +uint64_t pending_dbg;
> >> This is just a nitpick but I would prefer if we had the _pad field as
> >> the last element in the struct and keep all 64-bit members up in the
> >> front.
> > Also, since pending_dbg uses unsigned int in Xen, do we need uint64_t
> > for it here? Seems to me a uint32_t would suffice.
>
> Its %dr6 (but not quite, due to complexity with exception priorities,
> interrupt shadows, and backwards compatibility of the RTM bit with
> inverted polarity).  All other registers have 64 bit fields in the
> interface.
>
> The only interesting bits in it fall within the first 32 which is why it
> is handled in a shorter way within Xen.  Like %cr0, I don't expect
> anything interesting to appear in the upper 32 bits.
>

Perhaps it would be better to call it dr6 in the interface then to
make it more clear that this is a register value?

Tamas

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

Re: [Xen-devel] [PATCH] x86/debug: Plumb pending_dbg through the monitor and devicemodel interfaces

[Tamas K Lengyel]

On Tue, Dec 3, 2019 at 1:23 PM Andrew Cooper  wrote:
>
> On 03/12/2019 18:16, Tamas K Lengyel wrote:
> > On Tue, Dec 3, 2019 at 1:09 PM Andrew Cooper  
> > wrote:
> >> On 03/12/2019 18:05, Tamas K Lengyel wrote:
>  diff --git a/xen/include/public/vm_event.h 
>  b/xen/include/public/vm_event.h
>  index 959083d8c4..76676ff4c0 100644
>  --- a/xen/include/public/vm_event.h
>  +++ b/xen/include/public/vm_event.h
>  @@ -281,6 +281,7 @@ struct vm_event_debug {
>   uint32_t insn_length;
>   uint8_t type;/* HVMOP_TRAP_* */
>   uint8_t _pad[3];
>  +uint64_t pending_dbg;
> >>> This is just a nitpick but I would prefer if we had the _pad field as
> >>> the last element in the struct and keep all 64-bit members up in the
> >>> front.
> >> Well the reason I did it like this is that this version will continue to
> >> function with older introspection code.  The extra field is within a
> >> union and no other data moves.
> >>
> >> By repositioning to the start, it will almost certainly break older
> >> introspection code even though it compiled correctly.
> >>
> >> Your choice.
> > We are already bumping the interface version for the next release so
> > old introspection code by design will stop working. We make no ABI
> > stability guarantees between interface versions so this is a
> > non-issue.
>
> Ok fine.  Updated locally, but I won't send a new version of the patch
> just for this delta.
>
> diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
> index 76676ff4c0..8c24a58964 100644
> --- a/xen/include/public/vm_event.h
> +++ b/xen/include/public/vm_event.h
> @@ -278,10 +278,10 @@ struct vm_event_singlestep {
>
>  struct vm_event_debug {
>  uint64_t gfn;
> +uint64_t pending_dbg;
>  uint32_t insn_length;
>  uint8_t type;/* HVMOP_TRAP_* */
>  uint8_t _pad[3];
> -uint64_t pending_dbg;
>  };

With the above adjustment:

Acked-by: Tamas K Lengyel 

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

Re: [Xen-devel] [PATCH] x86/debug: Plumb pending_dbg through the monitor and devicemodel interfaces

[Andrew Cooper]

On 03/12/2019 18:24, Tamas K Lengyel wrote:
> On Tue, Dec 3, 2019 at 1:22 PM Tamas K Lengyel  wrote:
>> On Tue, Dec 3, 2019 at 1:18 PM Andrew Cooper  
>> wrote:
>>> On 03/12/2019 18:09, Tamas K Lengyel wrote:
 On Tue, Dec 3, 2019 at 1:05 PM Tamas K Lengyel  wrote:
>> diff --git a/xen/include/public/vm_event.h 
>> b/xen/include/public/vm_event.h
>> index 959083d8c4..76676ff4c0 100644
>> --- a/xen/include/public/vm_event.h
>> +++ b/xen/include/public/vm_event.h
>> @@ -281,6 +281,7 @@ struct vm_event_debug {
>>  uint32_t insn_length;
>>  uint8_t type;/* HVMOP_TRAP_* */
>>  uint8_t _pad[3];
>> +uint64_t pending_dbg;
> This is just a nitpick but I would prefer if we had the _pad field as
> the last element in the struct and keep all 64-bit members up in the
> front.
 Also, since pending_dbg uses unsigned int in Xen, do we need uint64_t
 for it here? Seems to me a uint32_t would suffice.
>>> Its %dr6 (but not quite, due to complexity with exception priorities,
>>> interrupt shadows, and backwards compatibility of the RTM bit with
>>> inverted polarity).  All other registers have 64 bit fields in the
>>> interface.
>>>
>>> The only interesting bits in it fall within the first 32 which is why it
>>> is handled in a shorter way within Xen.  Like %cr0, I don't expect
>>> anything interesting to appear in the upper 32 bits.
>>>
>> Perhaps it would be better to call it dr6 in the interface then to
>> make it more clear that this is a register value?
>>
> Which then begs the question, why not just use dr6 that's already
> present in the vm_event_regs_x86 struct?

Because it (specifically) isn't exactly %dr6.  The ABI it follows is
strictly like the VT-x's pending_dbg VMCS field.

All bits have positive polarity, and are specific to the debug exception
in question.

%dr6 accumulates some debug bits or-wise (and until the guest #DB
handler decides to clear them), some debug bits overwrite-wise, and some
bits with inverted polarity.

Providing %dr6 alone, either before or after merging pending_dbg, is
insufficient to disambiguate the debug exception.

pending_dbg is strictly "the new exception(s) to add into the %dr6 mix".

~Andrew

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

Re: [Xen-devel] [PATCH] x86/debug: Plumb pending_dbg through the monitor and devicemodel interfaces

[Tamas K Lengyel]

On Tue, Dec 3, 2019 at 1:22 PM Tamas K Lengyel  wrote:
>
> On Tue, Dec 3, 2019 at 1:18 PM Andrew Cooper  
> wrote:
> >
> > On 03/12/2019 18:09, Tamas K Lengyel wrote:
> > > On Tue, Dec 3, 2019 at 1:05 PM Tamas K Lengyel  
> > > wrote:
> > >>> diff --git a/xen/include/public/vm_event.h 
> > >>> b/xen/include/public/vm_event.h
> > >>> index 959083d8c4..76676ff4c0 100644
> > >>> --- a/xen/include/public/vm_event.h
> > >>> +++ b/xen/include/public/vm_event.h
> > >>> @@ -281,6 +281,7 @@ struct vm_event_debug {
> > >>>  uint32_t insn_length;
> > >>>  uint8_t type;/* HVMOP_TRAP_* */
> > >>>  uint8_t _pad[3];
> > >>> +uint64_t pending_dbg;
> > >> This is just a nitpick but I would prefer if we had the _pad field as
> > >> the last element in the struct and keep all 64-bit members up in the
> > >> front.
> > > Also, since pending_dbg uses unsigned int in Xen, do we need uint64_t
> > > for it here? Seems to me a uint32_t would suffice.
> >
> > Its %dr6 (but not quite, due to complexity with exception priorities,
> > interrupt shadows, and backwards compatibility of the RTM bit with
> > inverted polarity).  All other registers have 64 bit fields in the
> > interface.
> >
> > The only interesting bits in it fall within the first 32 which is why it
> > is handled in a shorter way within Xen.  Like %cr0, I don't expect
> > anything interesting to appear in the upper 32 bits.
> >
>
> Perhaps it would be better to call it dr6 in the interface then to
> make it more clear that this is a register value?
>

Which then begs the question, why not just use dr6 that's already
present in the vm_event_regs_x86 struct?

Tamas

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

Re: [Xen-devel] [PATCH] x86/debug: Plumb pending_dbg through the monitor and devicemodel interfaces

[Andrew Cooper]

On 03/12/2019 18:16, Tamas K Lengyel wrote:
> On Tue, Dec 3, 2019 at 1:09 PM Andrew Cooper  
> wrote:
>> On 03/12/2019 18:05, Tamas K Lengyel wrote:
 diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
 index 959083d8c4..76676ff4c0 100644
 --- a/xen/include/public/vm_event.h
 +++ b/xen/include/public/vm_event.h
 @@ -281,6 +281,7 @@ struct vm_event_debug {
  uint32_t insn_length;
  uint8_t type;/* HVMOP_TRAP_* */
  uint8_t _pad[3];
 +uint64_t pending_dbg;
>>> This is just a nitpick but I would prefer if we had the _pad field as
>>> the last element in the struct and keep all 64-bit members up in the
>>> front.
>> Well the reason I did it like this is that this version will continue to
>> function with older introspection code.  The extra field is within a
>> union and no other data moves.
>>
>> By repositioning to the start, it will almost certainly break older
>> introspection code even though it compiled correctly.
>>
>> Your choice.
> We are already bumping the interface version for the next release so
> old introspection code by design will stop working. We make no ABI
> stability guarantees between interface versions so this is a
> non-issue.

Ok fine.  Updated locally, but I won't send a new version of the patch
just for this delta.

diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
index 76676ff4c0..8c24a58964 100644
--- a/xen/include/public/vm_event.h
+++ b/xen/include/public/vm_event.h
@@ -278,10 +278,10 @@ struct vm_event_singlestep {
 
 struct vm_event_debug {
 uint64_t gfn;
+    uint64_t pending_dbg;
 uint32_t insn_length;
 uint8_t type;    /* HVMOP_TRAP_* */
 uint8_t _pad[3];
-    uint64_t pending_dbg;
 };
 
 struct vm_event_mov_to_msr {


However, this does raise the question of why insn_length is uint32_t. 
It has a value which is at most 15.

~Andrew

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

Re: [Xen-devel] [PATCH] x86/debug: Plumb pending_dbg through the monitor and devicemodel interfaces

[Tamas K Lengyel]

On Tue, Dec 3, 2019 at 1:05 PM Tamas K Lengyel  wrote:
>
> > diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
> > index 959083d8c4..76676ff4c0 100644
> > --- a/xen/include/public/vm_event.h
> > +++ b/xen/include/public/vm_event.h
> > @@ -281,6 +281,7 @@ struct vm_event_debug {
> >  uint32_t insn_length;
> >  uint8_t type;/* HVMOP_TRAP_* */
> >  uint8_t _pad[3];
> > +uint64_t pending_dbg;
>
> This is just a nitpick but I would prefer if we had the _pad field as
> the last element in the struct and keep all 64-bit members up in the
> front.

Also, since pending_dbg uses unsigned int in Xen, do we need uint64_t
for it here? Seems to me a uint32_t would suffice.

Tamas

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

Re: [Xen-devel] [PATCH] x86/debug: Plumb pending_dbg through the monitor and devicemodel interfaces

[Andrew Cooper]

On 03/12/2019 18:09, Tamas K Lengyel wrote:
> On Tue, Dec 3, 2019 at 1:05 PM Tamas K Lengyel  wrote:
>>> diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
>>> index 959083d8c4..76676ff4c0 100644
>>> --- a/xen/include/public/vm_event.h
>>> +++ b/xen/include/public/vm_event.h
>>> @@ -281,6 +281,7 @@ struct vm_event_debug {
>>>  uint32_t insn_length;
>>>  uint8_t type;/* HVMOP_TRAP_* */
>>>  uint8_t _pad[3];
>>> +uint64_t pending_dbg;
>> This is just a nitpick but I would prefer if we had the _pad field as
>> the last element in the struct and keep all 64-bit members up in the
>> front.
> Also, since pending_dbg uses unsigned int in Xen, do we need uint64_t
> for it here? Seems to me a uint32_t would suffice.

Its %dr6 (but not quite, due to complexity with exception priorities,
interrupt shadows, and backwards compatibility of the RTM bit with
inverted polarity).  All other registers have 64 bit fields in the
interface.

The only interesting bits in it fall within the first 32 which is why it
is handled in a shorter way within Xen.  Like %cr0, I don't expect
anything interesting to appear in the upper 32 bits.

~Andrew

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

Re: [Xen-devel] [PATCH v2 01/22] golang/xenlight: generate enum types from IDL

[George Dunlap]

> On Nov 15, 2019, at 7:44 PM, Nick Rosbrook  wrote:
> 
> From: Nick Rosbrook 
> 
> Introduce gengotypes.py to generate Go code the from IDL. As a first step,
> implement 'enum' type generation.
> 
> As a result of the newly-generated code, remove the existing, and now
> conflicting definitions in xenlight.go. In the case of the Error type,
> rename the slice 'errors' to 'libxlErrors' so that it does not conflict
> with the standard library package 'errors.' And, negate the values used
> in 'libxlErrors' since the generated error values are negative.
> 
> Signed-off-by: Nick Rosbrook 
> ---
> Changes in v2:
> - Introduce Makefile targets for code generation
> - Re-generate Go code (includes new libxl_passtrhough enum). 
> - Use *.gen.go naming convention for generated Go files.
> 
> tools/golang/xenlight/Makefile  |  18 +-
> tools/golang/xenlight/gengotypes.py | 109 
> tools/golang/xenlight/types.gen.go  | 388 
> tools/golang/xenlight/xenlight.go   | 140 ++
> 4 files changed, 535 insertions(+), 120 deletions(-)
> create mode 100644 tools/golang/xenlight/gengotypes.py
> create mode 100644 tools/golang/xenlight/types.gen.go
> 
> diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile
> index 0987305224..681f32c234 100644
> --- a/tools/golang/xenlight/Makefile
> +++ b/tools/golang/xenlight/Makefile
> @@ -7,20 +7,21 @@ GOCODE_DIR ?= $(prefix)/share/gocode/
> GOXL_PKG_DIR = /src/$(XEN_GOCODE_URL)/xenlight/
> GOXL_INSTALL_DIR = $(GOCODE_DIR)$(GOXL_PKG_DIR)
> 
> -# PKGSOURCES: Files which comprise the distributed source package
> -PKGSOURCES = xenlight.go
> -
> GO ?= go
> 
> .PHONY: all
> all: build
> 
> .PHONY: package
> -package: $(XEN_GOPATH)$(GOXL_PKG_DIR)$(PKGSOURCES)
> +package: $(XEN_GOPATH)$(GOXL_PKG_DIR)
> 
> -$(XEN_GOPATH)/src/$(XEN_GOCODE_URL)/xenlight/$(PKGSOURCES): $(PKGSOURCES)
> +$(XEN_GOPATH)/src/$(XEN_GOCODE_URL)/xenlight/: %.gen.go
>   $(INSTALL_DIR) $(XEN_GOPATH)$(GOXL_PKG_DIR)
> - $(INSTALL_DATA) $(PKGSOURCES) $(XEN_GOPATH)$(GOXL_PKG_DIR)
> + $(INSTALL_DATA) xenlight.go $(XEN_GOPATH)$(GOXL_PKG_DIR)
> + $(INSTALL_DATA) types.gen.go $(XEN_GOPATH)$(GOXL_PKG_DIR)
> +
> +%.gen.go: gengotypes.py $(XEN_ROOT)/tools/libxl/libxl_types.idl 
> $(XEN_ROOT)/tools/libxl/idl.py
> + XEN_ROOT=$(XEN_ROOT) $(PYTHON) gengotypes.py ../../libxl/libxl_types.idl

This seems to always run gengotypes.py and always do the ‘install’ here, 
regardless of whether anything has changed or not.  I think that’s probably 
fine for now, but it might be nice at some point to make it more 
dependency-driven.

That said:

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

Re: [Xen-devel] [PATCH] x86/debug: Plumb pending_dbg through the monitor and devicemodel interfaces

[Andrew Cooper]

On 03/12/2019 18:05, Tamas K Lengyel wrote:
>> diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
>> index 959083d8c4..76676ff4c0 100644
>> --- a/xen/include/public/vm_event.h
>> +++ b/xen/include/public/vm_event.h
>> @@ -281,6 +281,7 @@ struct vm_event_debug {
>>  uint32_t insn_length;
>>  uint8_t type;/* HVMOP_TRAP_* */
>>  uint8_t _pad[3];
>> +uint64_t pending_dbg;
> This is just a nitpick but I would prefer if we had the _pad field as
> the last element in the struct and keep all 64-bit members up in the
> front.

Well the reason I did it like this is that this version will continue to
function with older introspection code.  The extra field is within a
union and no other data moves.

By repositioning to the start, it will almost certainly break older
introspection code even though it compiled correctly.

Your choice.

~Andrew

P.S. What is the point of tail-padding a struct inside a union?

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

Re: [Xen-devel] [PATCH v2] xen/arm: remove physical timer offset

[Julien Grall]

Hi,

On 26/11/2019 21:13, Jeff Kubascik wrote:

The physical timer traps apply an offset so that time starts at 0 for
the guest. However, this offset is not currently applied to the physical
counter. Per the ARMv8 Reference Manual (ARM DDI 0487E.a), section
D11.2.4 Timers, the "Offset" between the counter and timer should be
zero for a physical timer. This removes the offset to make the timer and
counter consistent.

Furthermore, section D11.2.4 specifies that the values in the TimerValue
view of the timers are signed in standard two's complement form. When
writing to the TimerValue register, it should be signed extended as
described by the equation

   CompareValue = (Counter[63:0] + SignExtend(TimerValue))[63:0]


I am a bit confused, is it a new bug introduced by the change or 
previously existing? If the latter, then I think this should be modified 
in a separate patch.




Signed-off-by: Jeff Kubascik 
---
Changes in v2:
- Update commit message to specify reference manual version and section
- Change physical timer cval to hold hardware value


I think this change should be explained in the commit message.


- Make sure to sign extend TimerValue on writes. This was done by first
   casting the r pointer to (int32_t *), dereferencing it, then casting
   to uint64_t. Please let me know if there is a more correct way to do
   this
---
  xen/arch/arm/vtimer.c| 21 +
  xen/include/asm-arm/domain.h |  3 ---
  2 files changed, 9 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index e6aebdac9e..eb12a08acf 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -62,7 +62,6 @@ static void virt_timer_expired(void *data)
  
  int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config)

  {
-d->arch.phys_timer_base.offset = NOW();
  d->arch.virt_timer_base.offset = READ_SYSREG64(CNTPCT_EL0);
  d->time_offset_seconds = ticks_to_ns(d->arch.virt_timer_base.offset - 
boot_count);
  do_div(d->time_offset_seconds, 10);


I think you need to update the initialization of cval to avoid storing 
ns. But CTNP_CVAL_EL0 is reset to a unknown value at reboot, so we 
should not need to set a value at all as the guest would have to set it.



@@ -185,7 +184,7 @@ static bool vtimer_cntp_ctl(struct cpu_user_regs *regs, 
uint32_t *r, bool read)
  if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
  {
  set_timer(>arch.phys_timer.timer,
-  v->arch.phys_timer.cval + 
v->domain->arch.phys_timer_base.offset);
+  ticks_to_ns(v->arch.phys_timer.cval - boot_count));


cval may be smaller than boot_count. In that case, we will set the timer 
to expire a very long time. This is not the expected behavior from the 
guest.


Instead, we should either use 0 to create the timer or call 
phys_timer_expired directly.



  }
  else
  stop_timer(>arch.phys_timer.timer);
@@ -197,26 +196,25 @@ static bool vtimer_cntp_tval(struct cpu_user_regs *regs, 
uint32_t *r,
   bool read)
  {
  struct vcpu *v = current;
-s_time_t now;
+uint64_t cntpct;
  
  if ( !ACCESS_ALLOWED(regs, EL0PTEN) )

  return false;
  
-now = NOW() - v->domain->arch.phys_timer_base.offset;

+cntpct = get_cycles();
  
  if ( read )

  {
-*r = (uint32_t)(ns_to_ticks(v->arch.phys_timer.cval - now) & 
0xull);
+*r = (uint32_t)((v->arch.phys_timer.cval - cntpct) & 0xull);
  }
  else
  {
-v->arch.phys_timer.cval = now + ticks_to_ns(*r);
+v->arch.phys_timer.cval = cntpct + (uint64_t)(*((int32_t *)r));


I would prefer (uint64_t)(int32_t)*r.


  if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
  {
  v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
  set_timer(>arch.phys_timer.timer,
-  v->arch.phys_timer.cval +
-  v->domain->arch.phys_timer_base.offset);
+  ticks_to_ns(v->arch.phys_timer.cval - boot_count));
  }
  }
  return true;
@@ -232,17 +230,16 @@ static bool vtimer_cntp_cval(struct cpu_user_regs *regs, 
uint64_t *r,
  
  if ( read )

  {
-*r = ns_to_ticks(v->arch.phys_timer.cval);
+*r = v->arch.phys_timer.cval;
  }
  else
  {
-v->arch.phys_timer.cval = ticks_to_ns(*r);
+v->arch.phys_timer.cval = *r;
  if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
  {
  v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
  set_timer(>arch.phys_timer.timer,
-  v->arch.phys_timer.cval +
-  v->domain->arch.phys_timer_base.offset);
+  ticks_to_ns(v->arch.phys_timer.cval - boot_count));
  }
  }
  return true;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  d7c3e6c9e9dabbba0b8dc0ddb0fc38811ae0915f
baseline version:
 xen  b4637ed6cd5375f04ac51d6b900a9ccad6c6c03a

Last test of basis   144508  2019-12-03 12:00:45 Z0 days
Testing same since   144511  2019-12-03 15:00:38 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Roger Pau Monne 
  Roger Pau Monné 
  Wei Liu 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   b4637ed6cd..d7c3e6c9e9  d7c3e6c9e9dabbba0b8dc0ddb0fc38811ae0915f -> smoke

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

Re: [Xen-devel] Xen 4.14 and future work

[Andrew Cooper]

On 03/12/2019 09:03, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel  On Behalf Of
>> Andrew Cooper
>> Sent: 02 December 2019 19:52
>> To: Xen-devel List 
>> Subject: [Xen-devel] Xen 4.14 and future work
>>
>> Hello,
>>
>> Now that 4.13 is on its way out of the door, it is time to look to
>> ongoing work.
>>
>> We have a large backlog of speculation-related work.  For one, we still
>> don't virtualise MSR_ARCH_CAPS for guests, or use eIBRS ourselves in
>> Xen.  Therefore, while Xen does function on Cascade Lake, support is
>> distinctly suboptimal.
>>
>> Similarly, AMD systems frequently fill /var/log with:
>>
>> (XEN) emul-priv-op.c:1113:d0v13 Domain attempted WRMSR c0011020 from
>> 0x00064040 to 0x000640400400
>>
>> which is an interaction Linux's prctl() to disable memory disambiguation
>> on a per-process basis, Xen's write/discard behaviour for MSRs, and the
>> long-overdue series to properly virtualise SSBD support on AMD
>> hardware.  AMD Rome hardware, like Cascade Lake, has certain hardware
>> speculative mitigation features which need virtualising for guests to
>> make use of.
>>
> I assume this would addressed by the proposed cpuid/msr policy work?

Yes.  The next task there is to plumb the CPUID policy through the libxc
migrate stream, coping with its absence from older sources.  This
(purposefully) breaks the dual purpose of the CPUID code in libxc for
both domain start and domain restore, and allows us to rewrite the
domain start logic without impacting migrating-in VMs.

Then, and only then, is it safe to add MSR_ARCH_CAPS into the guest
policies and start setting it up.

> I think it is quite vital for Xen that we are able to migrate guests across 
> pools of heterogeneous h/w and therefore I'd like to see this done in 4.14 if 
> possible.

Why do you think it was top of my list :)

>
>> Similarly, there is plenty more work to do with core-aware scheduling,
>> and from my side of things, sane guest topology.  This will eventually
>> unblock one of the factors on the hard 128 vcpu limit for HVM guests.
>>
>>
>> Another big area is the stability of toolstack hypercalls.  This is a
>> crippling pain point for distros and upgradeability of systems, and
>> there is frankly no justifiable reason for the way we currently do
>> things  The real reason is inertia from back in the days when Xen.git
>> (bitkeeper as it was back then) contained a fork of every relevant
>> pieces of software, but this a long-since obsolete model, but still
>> causing us pain.  I will follow up with a proposal in due course, but as
>> a oneliner, it will build on the dm_op() API model.
> This is also fairly vital for the work on live update of Xen (as discussed at 
> the last dev summit). Any instability in the tools ABI will compromise 
> hypervisor update and fixing such issues on an ad-hoc basis as they arise is 
> not really a desirable prospect.
>
>> Likely included within this is making the domain/vcpu destroy paths
>> idempotent so we can fix a load of NULL pointer dereferences in Xen
>> caused by XEN_DOMCTL_max_vcpus not being part of XEN_DOMCTL_createdomain.
>>
>> Other work in this area involves adding X86_EMUL_{VIRIDIAN,NESTED_VIRT}
>> to replace their existing problematic enablement interfaces.
>>
> I think this should include deprecation of HVMOP_get/set_param as far as is 
> possible (i.e. tools use)...
>
>> A start needs to be made on a total rethink of the HVM ABI.  This has
>> come up repeatedly at previous dev summits, and is in desperate need of
>> having some work started on it.
>>
> ...and completely in any new ABI.

Both already in the plan(s).

> I wonder to what extent we can provide a guest-side compat layer here, 
> otherwise it would be hard to get traction I think.

Step 1 of the design (deliberately) won't be concerned with guest
compatibility.  The single most important aspect is to come up with a
clean design which is not crippled by retaining compatibility for PV
guests, and without x86-isms leaking into other architectures.

Once a sensible design exists, we can go about figuring out how best to
enact it.  Most areas will be able to fit compatibility into existing
HVM guests, but some are going to have a very hard time.

> There was an interesting talk at KVM Forum (https://sched.co/Tmuy) on dealing 
> with emulation inside guest context by essentially re-injecting the VMEXITs 
> back into the guest for pseudo-SMM code (loaded as part of the firmware blob) 
> to deal with. I could imagine potentially using such a mechanism to have a 
> 'legacy' hypercall translated to the new ABI, which would allow older guests 
> to be supported unmodified (albeit with a performance penalty). Such a 
> mechanism may also be useful as an alternative way of dealing with some of 
> the emulation dealt with directly in Xen at the moment, to reduce the 
> hypervisor attack surface e.g. stdvga caching, hpet, rtc... perhaps.

I don't think this is relevant to the ABI 

Re: [Xen-devel] [PATCH v5 7/8] x86: be more verbose when running on a hypervisor

[Wei Liu]

On Tue, Dec 03, 2019 at 05:09:43PM +, Wei Liu wrote:
> On Tue, Dec 03, 2019 at 05:58:28PM +0100, Jan Beulich wrote:
> > On 03.12.2019 17:37, Wei Liu wrote:
> > > On Tue, Dec 03, 2019 at 03:54:35PM +0100, Jan Beulich wrote:
> > >> On 30.11.2019 12:57, Wei Liu wrote:
> > >>> Also replace reference to xen_guest.
> > >>>
> > >>> Signed-off-by: Wei Liu 
> > >>
> > >> Acked-by: Jan Beulich 
> > > 
> > > Thanks.
> > > 
> > >>
> > >> However, ...
> > >>
> > >>> --- a/xen/arch/x86/setup.c
> > >>> +++ b/xen/arch/x86/setup.c
> > >>> @@ -700,6 +700,7 @@ void __init noreturn __start_xen(unsigned long 
> > >>> mbi_p)
> > >>>  .max_grant_frames = -1,
> > >>>  .max_maptrack_frames = -1,
> > >>>  };
> > >>> +const char *hypervisor_name;
> > >>>  
> > >>>  /* Critical region without IDT or TSS.  Any fault is deadly! */
> > >>>  
> > >>> @@ -763,7 +764,7 @@ void __init noreturn __start_xen(unsigned long 
> > >>> mbi_p)
> > >>>   * allocing any xenheap structures wanted in lower memory. */
> > >>>  kexec_early_calculations();
> > >>>  
> > >>> -hypervisor_probe();
> > >>> +hypervisor_name = hypervisor_probe();
> > >>
> > >> ... you no longer calling this function multiple time, why does
> > >> patch 4 still put in a respective guard?
> > > 
> > > Remnant from previous iterations.
> > > 
> > > I can submit a follow-up patch to drop that -- do really want to
> > > invalidate all the reviews and acks I got so far.
> > 
> > According to my records patch 4 had no acks except mine, which you
> > could keep with this change (in fact I was thinking of making it
> > dependent upon the dropping of this leftover). Subsequent patches
> > may only need re-basing, which doesn't imply dropping of any acks.
> 
> OK. In that case, I will drop it locally. If that causes any substantial
> changes, I will post another version; otherwise I will just keep all the
> tags and push this series soon-ish.
> 
> How does that sound to you?

And it turns out it is indeed trivial. Dropping that hunk in patch 4
only requires a minor fixup to patch 6.

Wei.

> 
> Wei.
> 
> > 
> > Jan

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

[Xen-devel] [PATCH] x86/debug: Plumb pending_dbg through the monitor and devicemodel interfaces

[Andrew Cooper]

Like %cr2 for pagefaults, %dr6 contains ancillary information for debug
exceptions, and needs similar handling.

For xendevicemodel_inject_event(), no ABI change is needed (although an API
one would be ideal).  Switch from 'cr2' to 'extra' in variable names which
don't constitute an API change, and update the documentation to match.

For the monitor interface, vm_event_debug needs extending with a pending_dbg
field.  Extend hvm_monitor_debug() and for now, always pass in 0 - this will
be fixed eventually, when other hypervisor bugfixes are complete.

While modifying hvm_monitor_debug(), take the opportunity to correct trap type
and instruction length from unsigned long to unsigned int, as they are both
tiny values.

Finally, adjust xen-access.c to the new expectations.  Introspection tools
intercepting debug exceptions should mirror the new pending_dbg field into
xendevicemodel_inject_event() for %dr6 to be processed correctly for the
guest.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Razvan Cojocaru 
CC: Tamas K Lengyel 
CC: Alexandru Isaila 
CC: Petre Pircalabu 
CC: Ian Jackson 

I'm expecting to commit this alongside "x86/svm: Correct vm_event API for
descriptor accesses" which covers the bump of the VM_EVENT interface version.
---
 tools/libs/devicemodel/core.c   | 4 ++--
 tools/libs/devicemodel/include/xendevicemodel.h | 4 ++--
 tools/tests/xen-access/xen-access.c | 7 ---
 xen/arch/x86/hvm/monitor.c  | 4 +++-
 xen/arch/x86/hvm/svm/svm.c  | 4 ++--
 xen/arch/x86/hvm/vmx/vmx.c  | 6 +++---
 xen/include/asm-x86/hvm/monitor.h   | 3 ++-
 xen/include/public/hvm/dm_op.h  | 2 +-
 xen/include/public/vm_event.h   | 1 +
 9 files changed, 20 insertions(+), 15 deletions(-)

diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c
index f76e3d305e..db501d9e80 100644
--- a/tools/libs/devicemodel/core.c
+++ b/tools/libs/devicemodel/core.c
@@ -536,7 +536,7 @@ int xendevicemodel_set_mem_type(
 
 int xendevicemodel_inject_event(
 xendevicemodel_handle *dmod, domid_t domid, int vcpu, uint8_t vector,
-uint8_t type, uint32_t error_code, uint8_t insn_len, uint64_t cr2)
+uint8_t type, uint32_t error_code, uint8_t insn_len, uint64_t extra)
 {
 struct xen_dm_op op;
 struct xen_dm_op_inject_event *data;
@@ -551,7 +551,7 @@ int xendevicemodel_inject_event(
 data->type = type;
 data->error_code = error_code;
 data->insn_len = insn_len;
-data->cr2 = cr2;
+data->cr2 = extra;
 
 return xendevicemodel_op(dmod, domid, 1, , sizeof(op));
 }
diff --git a/tools/libs/devicemodel/include/xendevicemodel.h 
b/tools/libs/devicemodel/include/xendevicemodel.h
index 08cb0d4374..e877f5c8a6 100644
--- a/tools/libs/devicemodel/include/xendevicemodel.h
+++ b/tools/libs/devicemodel/include/xendevicemodel.h
@@ -309,12 +309,12 @@ int xendevicemodel_set_mem_type(
  * @parm type the event type (see the definition of enum x86_event_type)
  * @parm error_code the error code or ~0 to skip
  * @parm insn_len the instruction length
- * @parm cr2 the value of CR2 for page faults
+ * @parm extra type-specific extra data (%cr2 for #PF, pending_dbg for #DB)
  * @return 0 on success, -1 on failure.
  */
 int xendevicemodel_inject_event(
 xendevicemodel_handle *dmod, domid_t domid, int vcpu, uint8_t vector,
-uint8_t type, uint32_t error_code, uint8_t insn_len, uint64_t cr2);
+uint8_t type, uint32_t error_code, uint8_t insn_len, uint64_t extra);
 
 /**
  * Shuts the domain down.
diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index 6aaee16d67..044a3a3c57 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -826,18 +826,19 @@ int main(int argc, char *argv[])
 
 break;
 case VM_EVENT_REASON_DEBUG_EXCEPTION:
-printf("Debug exception: rip=%016"PRIx64", vcpu %d. Type: %u. 
Length: %u\n",
+printf("Debug exception: rip=%016"PRIx64", vcpu %d. Type: %u. 
Length: %u. Pending dbg %08"PRIx64"\n",
req.data.regs.x86.rip,
req.vcpu_id,
req.u.debug_exception.type,
-   req.u.debug_exception.insn_length);
+   req.u.debug_exception.insn_length,
+   req.u.debug_exception.pending_dbg);
 
 /* Reinject */
 rc = xc_hvm_inject_trap(xch, domain_id, req.vcpu_id,
 X86_TRAP_DEBUG,
 req.u.debug_exception.type, -1,
 req.u.debug_exception.insn_length,
-req.data.regs.x86.cr2);
+req.u.debug_exception.pending_dbg);
 if (rc < 0)
  

Re: [Xen-devel] [PATCH v5 7/8] x86: be more verbose when running on a hypervisor

[Wei Liu]

On Tue, Dec 03, 2019 at 05:58:28PM +0100, Jan Beulich wrote:
> On 03.12.2019 17:37, Wei Liu wrote:
> > On Tue, Dec 03, 2019 at 03:54:35PM +0100, Jan Beulich wrote:
> >> On 30.11.2019 12:57, Wei Liu wrote:
> >>> Also replace reference to xen_guest.
> >>>
> >>> Signed-off-by: Wei Liu 
> >>
> >> Acked-by: Jan Beulich 
> > 
> > Thanks.
> > 
> >>
> >> However, ...
> >>
> >>> --- a/xen/arch/x86/setup.c
> >>> +++ b/xen/arch/x86/setup.c
> >>> @@ -700,6 +700,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> >>>  .max_grant_frames = -1,
> >>>  .max_maptrack_frames = -1,
> >>>  };
> >>> +const char *hypervisor_name;
> >>>  
> >>>  /* Critical region without IDT or TSS.  Any fault is deadly! */
> >>>  
> >>> @@ -763,7 +764,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> >>>   * allocing any xenheap structures wanted in lower memory. */
> >>>  kexec_early_calculations();
> >>>  
> >>> -hypervisor_probe();
> >>> +hypervisor_name = hypervisor_probe();
> >>
> >> ... you no longer calling this function multiple time, why does
> >> patch 4 still put in a respective guard?
> > 
> > Remnant from previous iterations.
> > 
> > I can submit a follow-up patch to drop that -- do really want to
> > invalidate all the reviews and acks I got so far.
> 
> According to my records patch 4 had no acks except mine, which you
> could keep with this change (in fact I was thinking of making it
> dependent upon the dropping of this leftover). Subsequent patches
> may only need re-basing, which doesn't imply dropping of any acks.

OK. In that case, I will drop it locally. If that causes any substantial
changes, I will post another version; otherwise I will just keep all the
tags and push this series soon-ish.

How does that sound to you?

Wei.

> 
> Jan

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

Re: [Xen-devel] [PATCH v5 7/8] x86: be more verbose when running on a hypervisor

[Jan Beulich]

On 03.12.2019 17:37, Wei Liu wrote:
> On Tue, Dec 03, 2019 at 03:54:35PM +0100, Jan Beulich wrote:
>> On 30.11.2019 12:57, Wei Liu wrote:
>>> Also replace reference to xen_guest.
>>>
>>> Signed-off-by: Wei Liu 
>>
>> Acked-by: Jan Beulich 
> 
> Thanks.
> 
>>
>> However, ...
>>
>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>> @@ -700,6 +700,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>>  .max_grant_frames = -1,
>>>  .max_maptrack_frames = -1,
>>>  };
>>> +const char *hypervisor_name;
>>>  
>>>  /* Critical region without IDT or TSS.  Any fault is deadly! */
>>>  
>>> @@ -763,7 +764,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>>   * allocing any xenheap structures wanted in lower memory. */
>>>  kexec_early_calculations();
>>>  
>>> -hypervisor_probe();
>>> +hypervisor_name = hypervisor_probe();
>>
>> ... you no longer calling this function multiple time, why does
>> patch 4 still put in a respective guard?
> 
> Remnant from previous iterations.
> 
> I can submit a follow-up patch to drop that -- do really want to
> invalidate all the reviews and acks I got so far.

According to my records patch 4 had no acks except mine, which you
could keep with this change (in fact I was thinking of making it
dependent upon the dropping of this leftover). Subsequent patches
may only need re-basing, which doesn't imply dropping of any acks.

Jan

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

Re: [Xen-devel] [PATCH v5 8/8] x86: introduce CONFIG_HYPERV and detection code

[Wei Liu]

On Sat, Nov 30, 2019 at 11:57:37AM +, Wei Liu wrote:
[...]
> + */
> +#include 
> +
> +#include 
> +
> +static const struct hypervisor_ops hyperv_ops = {

Since xg_ops has lost its xg_ prefix, I also take the liberty to drop
the hyperv_ prefix here to make things more consistent.

Wei.

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

Re: [Xen-devel] [PATCH] xen/arm: Basic support for sunxi/sun50i h6 platform.

[Julien Grall]

On 03/12/2019 14:38, Andre Przywara wrote:

On Tue, 3 Dec 2019 11:39:58 +
Julien Grall  wrote:

Hi,


(+Andre)

Hi,

@Andre, IIRC you originally added the support for sunxi in Xen. Could
you have a look at this patch?


Looks alright, and indeed the H6 needs it. Even though Allwinner totally 
re-arranged the memory map, they missed the opportunity to put each device at 
least in their own 4K page.

Reviewed-by: Andre Przywara 


Thank you for the review!



If you can wait till this evening, I can even test it.


I can wait until tomorrow before comitting the patch.



It's actually a shame that we need this enumeration, when all we are after is an answer to the question: Does a device used by Xen share a 4K page with a device handed off to Dom0? It sounds 
like a nice rainy afternoon exercise to scan the DT to find those 
devices automatically and mask them (on the A64 for instance UART4 is on 
a different page).


I agree and I think we discussed about it before :). I would welcome 
such improvement in Xen, this would actually allow us to drop sunxi.c 
completely.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 7/8] x86: be more verbose when running on a hypervisor

[Wei Liu]

On Tue, Dec 03, 2019 at 03:54:35PM +0100, Jan Beulich wrote:
> On 30.11.2019 12:57, Wei Liu wrote:
> > Also replace reference to xen_guest.
> > 
> > Signed-off-by: Wei Liu 
> 
> Acked-by: Jan Beulich 

Thanks.

> 
> However, ...
> 
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -700,6 +700,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> >  .max_grant_frames = -1,
> >  .max_maptrack_frames = -1,
> >  };
> > +const char *hypervisor_name;
> >  
> >  /* Critical region without IDT or TSS.  Any fault is deadly! */
> >  
> > @@ -763,7 +764,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> >   * allocing any xenheap structures wanted in lower memory. */
> >  kexec_early_calculations();
> >  
> > -hypervisor_probe();
> > +hypervisor_name = hypervisor_probe();
> 
> ... you no longer calling this function multiple time, why does
> patch 4 still put in a respective guard?

Remnant from previous iterations.

I can submit a follow-up patch to drop that -- do really want to
invalidate all the reviews and acks I got so far.

Wei.

> 
> Jan

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

Re: [Xen-devel] [PATCH v5 6/8] x86: switch xen guest implementation to use hypervisor framework

[Wei Liu]

On Tue, Dec 03, 2019 at 03:52:47PM +0100, Jan Beulich wrote:
> On 30.11.2019 12:57, Wei Liu wrote:
> > Signed-off-by: Wei Liu 
> 
> Acked-by: Jan Beulich 
> again with one more remark:
> 
> > @@ -326,6 +310,31 @@ void hypervisor_resume(void)
> >  pv_console_init();
> >  }
> >  
> > +static const struct hypervisor_ops xg_ops = {
> 
> Along with other static variable not having an xg_ prefix,
> this one could lose its one, too. But I'm not going to make
> this a requirement.

I will drop the xg_ prefix locally per your comment here.

Wei.

> 
> Jan

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

Re: [Xen-devel] [PATCH v5 4/8] x86: introduce hypervisor framework

[Wei Liu]

On Tue, Dec 03, 2019 at 03:49:33PM +0100, Jan Beulich wrote:
> On 30.11.2019 12:57, Wei Liu wrote:
> > We will soon implement Hyper-V support for Xen. Add a framework for
> > that.
> > 
> > This requires moving some of the hypervisor_* functions from xen.h to
> > hypervisor.h.
> > 
> > Signed-off-by: Wei Liu 
> 
> Acked-by: Jan Beulich 
[...]
> > +#include 
> > +
> > +static const struct hypervisor_ops __read_mostly *ops;
> 
> The __read_mostly is misplaced - it's an attribute of the variable,
> not its type, and hence belongs after the * . It just so happens
> that the compiler is (still) relatively relaxed in what it accepts,
> but I think at least the gcc manual has a warning towards future
> more strict behavior.

Fixed.

Wei.

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

Re: [Xen-devel] [PATCH v2 4/4] x86/apic: allow enabling x2APIC mode regardless of interrupt remapping

[Jan Beulich]

On 29.11.2019 12:28, Roger Pau Monne wrote:
> --- a/xen/arch/x86/apic.c
> +++ b/xen/arch/x86/apic.c
> @@ -492,7 +492,8 @@ static void __enable_x2apic(void)
>  
>  static void resume_x2apic(void)
>  {
> -iommu_enable_x2apic();
> +if ( iommu_supports_x2apic() )
> +iommu_enable_x2apic();

The hooks called by this function are __init, and at least the AMD
one also isn't (I think) prepared to be called more than once.

Jan

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

Re: [Xen-devel] [PATCH v2 3/4] x86/smp: check APIC ID on AP bringup

[Jan Beulich]

On 29.11.2019 12:28, Roger Pau Monne wrote:
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -1317,6 +1317,13 @@ int __cpu_up(unsigned int cpu)
>  if ( (apicid = x86_cpu_to_apicid[cpu]) == BAD_APICID )
>  return -ENODEV;
>  
> +if ( (!x2apic_enabled || !iommu_intremap) && (apicid >> 8) )
> +{
> +printk("Processor with APIC ID %u cannot be onlined in xAPIC mode "
> +   "or without interrupt remapping\n", apicid);

Please log the APIC ID in hex, to match how it gets logged e.g.
by the ACPI table parsing code. I'd also prefer if the message
could be shortened a little: I don't think the "or" is needed,
"Processor" could become "CPU", and slight re-wording could
save even a little more: "Cannot online CPU with APIC ID %#x in
xAPIC mode w/o interrupt remapping".

Then again this isn't fully correct: We could bring such a
CPU online in x2APIC mode but without interrupt remapping.
There would be a restriction on which CPUs physical interrupts
could be delivered to. So perhaps "Unsupported: APIC ID %#x in
xAPIC mode w/o interrupt remapping" or some such?

Jan

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

Re: [Xen-devel] [PATCH v1] xen-pciback: optionally allow interrupt enable flag writes

[Roger Pau Monné]

On Tue, Dec 03, 2019 at 06:41:56AM +0100, Marek Marczykowski-Górecki wrote:
> QEMU running in a stubdom needs to be able to set INTX_DISABLE, and the
> MSI(-X) enable flags in the PCI config space. This adds an attribute
> 'allow_interrupt_control' which when set for a PCI device allows writes
> to this flag(s). The toolstack will need to set this for stubdoms.
> When enabled, guest (stubdomain) will be allowed to set relevant enable
> flags, but only one at a time - i.e. it refuses to enable more than one
> of INTx, MSI, MSI-X at a time.
> 
> This functionality is needed only for config space access done by device
> model (stubdomain) serving a HVM with the actual PCI device. It is not
> necessary and unsafe to enable direct access to those bits for PV domain
> with the device attached. For PV domains, there are separate protocol
> messages (XEN_PCI_OP_{enable,disable}_{msi,msix}) for this purpose.
> Those ops in addition to setting enable bits, also configure MSI(-X) in
> dom0 kernel - which is undesirable for PCI passthrough to HVM guests.
> 
> This should not introduce any new security issues since a malicious
> guest (or stubdom) can already generate MSIs through other ways, see
> [1] page 8. Additionally, when qemu runs in dom0, it already have direct
> access to those bits.
> 
> This is the second iteration of this feature. First was proposed as a
> direct Xen interface through a new hypercall, but ultimately it was
> rejected by the maintainer, because of mixing pciback and hypercalls for
> PCI config space access isn't a good design. Full discussion at [2].
> 
> [1]: 
> https://invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf
> [2]: https://xen.markmail.org/thread/smpgpws4umdzizze
> 
> [part of the commit message and sysfs handling]
> Signed-off-by: Simon Gaiser 
> [the rest]
> Signed-off-by: Marek Marczykowski-Górecki 
> ---
> I'm not very happy about code duplication regarding MSI/MSI-X/INTx
> exclusivity test, but I don't have better ideas how to structure it. Any
> suggestions?

Can't you create a helper that returns the currently enabled interrupt
mode?

I expect returning an enum (ie: NONE, INTX, MSI, MSIX) should be fine
since no two of those should be enabled at the same time.

> ---
>  .../xen/xen-pciback/conf_space_capability.c   | 113 ++
>  drivers/xen/xen-pciback/conf_space_header.c   |  30 +
>  drivers/xen/xen-pciback/pci_stub.c|  66 ++
>  drivers/xen/xen-pciback/pciback.h |   1 +
>  4 files changed, 210 insertions(+)
> 
> diff --git a/drivers/xen/xen-pciback/conf_space_capability.c 
> b/drivers/xen/xen-pciback/conf_space_capability.c
> index e5694133ebe5..c5a7c58ff3e3 100644
> --- a/drivers/xen/xen-pciback/conf_space_capability.c
> +++ b/drivers/xen/xen-pciback/conf_space_capability.c
> @@ -189,6 +189,109 @@ static const struct config_field caplist_pm[] = {
>   {}
>  };
>  
> +static struct msi_msix_field_config {
> + u16 enable_bit;  /* bit for enabling MSI/MSI-X */
> + int other_cap;  /* the other capability for exclusiveness check */

Nit: just one space between the declaration and the comment IMO.

Also capability ID is not a signed value, hence unsigned int would
feel more natural.

> +} msi_field_config = {
> + .enable_bit = PCI_MSI_FLAGS_ENABLE,
> + .other_cap = PCI_CAP_ID_MSIX,
> +}, msix_field_config = {
> + .enable_bit = PCI_MSIX_FLAGS_ENABLE,
> + .other_cap = PCI_CAP_ID_MSI,
> +};

I think it would be more helpful to store the current capability ID
rather the one you need to check against. Then if you had a helper
that returns the currently enabled interrupt mode you would have to
check that either it's NONE or matches the capability requested to be
enabled.

> +
> +static void *msi_field_init(struct pci_dev *dev, int offset)
> +{
> + return _field_config;
> +}
> +
> +static void *msix_field_init(struct pci_dev *dev, int offset)
> +{
> + return _field_config;
> +}
> +
> +static int msi_msix_flags_write(struct pci_dev *dev, int offset, u16 
> new_value,
> +  void *data)
> +{
> + int err;
> + u16 old_value;
> + struct msi_msix_field_config *field_config = data;
> + struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(dev);

const for both the above.

> + int other_cap_offset;

unsigned int

> + u16 other_cap_enable_bit;
> + u16 other_cap_value;
> +
> + if (xen_pcibk_permissive || dev_data->permissive)
> + goto write;
> +
> + err = pci_read_config_word(dev, offset, _value);
> + if (err)
> + return err;
> +
> + if (new_value == old_value)
> + return 0;
> +
> + if (!dev_data->allow_interrupt_control ||
> + (new_value ^ old_value) & ~field_config->enable_bit)
> + return PCIBIOS_SET_FAILED;
> +
> + if (new_value & field_config->enable_bit) {
> + /* don't allow enabling together with INTx */
> + err = 

Re: [Xen-devel] [PATCH v2 2/4] x86/apic: force phys mode if interrupt remapping is disabled

[Jan Beulich]

On 29.11.2019 12:38, Roger Pau Monné  wrote:
> On Fri, Nov 29, 2019 at 12:28:49PM +0100, Roger Pau Monne wrote:
>> Cluster mode can only be used with interrupt remapping support, since
>> the top 16bits of the APIC ID are filled with the cluster ID, and
>> hence on systems where the physical ID is still smaller than 255 the
>> cluster ID is not. Force x2APIC to use physical mode if there's no
>> interrupt remapping support.
>>
>> Note that this requires a further patch in order to enable x2APIC
>> without interrupt remapping support.
>>
>> Signed-off-by: Roger Pau Monné 
> 
> This is missing a command line doc update and the logic below ignores
> a user-set x2apic_phys value.

So what would the behavior be in your opinion when the user
has requested cluster mode? I can't see you do much other
than panic()-ing, perhaps it's better to override the request
(as you already do)?

Jan

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

Re: [Xen-devel] [PATCH v2 1/4] x86/ioapic: only use dest32 with x2apic and interrupt remapping enabled

[Jan Beulich]

On 29.11.2019 12:28, Roger Pau Monne wrote:
> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -562,7 +562,7 @@ set_ioapic_affinity_irq(struct irq_desc *desc, const 
> cpumask_t *mask)
>  
>  dest = set_desc_affinity(desc, mask);
>  if (dest != BAD_APICID) {
> -if ( !x2apic_enabled )
> +if ( !iommu_intremap )

To match description as well as the other changes done, doesn't
this need to be "!x2apic_enabled || !iommu_intremap"?

jan

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  b4637ed6cd5375f04ac51d6b900a9ccad6c6c03a
baseline version:
 xen  42c8cdc039d6dc7d6aea8008bb24622eaf4b7bc8

Last test of basis   144494  2019-12-02 17:01:22 Z0 days
Testing same since   144508  2019-12-03 12:00:45 Z0 days1 attempts


People who touched revisions under test:
  Ian Campbell 
  Jeff Kubascik 
  Julien Grall 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   42c8cdc039..b4637ed6cd  b4637ed6cd5375f04ac51d6b900a9ccad6c6c03a -> smoke

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

Re: [Xen-devel] [PATCH v5 7/8] x86: be more verbose when running on a hypervisor

[Jan Beulich]

On 30.11.2019 12:57, Wei Liu wrote:
> Also replace reference to xen_guest.
> 
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 

However, ...

> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -700,6 +700,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  .max_grant_frames = -1,
>  .max_maptrack_frames = -1,
>  };
> +const char *hypervisor_name;
>  
>  /* Critical region without IDT or TSS.  Any fault is deadly! */
>  
> @@ -763,7 +764,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>   * allocing any xenheap structures wanted in lower memory. */
>  kexec_early_calculations();
>  
> -hypervisor_probe();
> +hypervisor_name = hypervisor_probe();

... you no longer calling this function multiple time, why does
patch 4 still put in a respective guard?

Jan

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

Re: [Xen-devel] [PATCH v5 6/8] x86: switch xen guest implementation to use hypervisor framework

[Jan Beulich]

On 30.11.2019 12:57, Wei Liu wrote:
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 
again with one more remark:

> @@ -326,6 +310,31 @@ void hypervisor_resume(void)
>  pv_console_init();
>  }
>  
> +static const struct hypervisor_ops xg_ops = {

Along with other static variable not having an xg_ prefix,
this one could lose its one, too. But I'm not going to make
this a requirement.

Jan

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

Re: [Xen-devel] [PATCH v5 4/8] x86: introduce hypervisor framework

[Jan Beulich]

On 30.11.2019 12:57, Wei Liu wrote:
> We will soon implement Hyper-V support for Xen. Add a framework for
> that.
> 
> This requires moving some of the hypervisor_* functions from xen.h to
> hypervisor.h.
> 
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 
with one more adjustment (sorry for noticing only now):

> --- /dev/null
> +++ b/xen/arch/x86/guest/hypervisor.c
> @@ -0,0 +1,45 @@
> +/**
> + * arch/x86/guest/hypervisor.c
> + *
> + * Support for detecting and running under a hypervisor.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; If not, see .
> + *
> + * Copyright (c) 2019 Microsoft.
> + */
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +static const struct hypervisor_ops __read_mostly *ops;

The __read_mostly is misplaced - it's an attribute of the variable,
not its type, and hence belongs after the * . It just so happens
that the compiler is (still) relatively relaxed in what it accepts,
but I think at least the gcc manual has a warning towards future
more strict behavior.

Jan

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

Re: [Xen-devel] [PATCH for-4.13] x86/AMD: unbreak CPU hotplug on AMD systems without RstrFpErrPtrs

[Jan Beulich]

On 03.12.2019 15:41, Igor Druzhinin wrote:
> On 03/12/2019 14:28, Jan Beulich wrote:
>> On 03.12.2019 15:21, Igor Druzhinin wrote:
>>> On 03/12/2019 10:08, Jan Beulich wrote:
 On 29.11.2019 21:01, Igor Druzhinin wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -54,7 +54,7 @@ static unsigned int forced_caps[NCAPINTS];
>  
>  DEFINE_PER_CPU(bool, full_gdt_loaded);
>  
> -void __init setup_clear_cpu_cap(unsigned int cap)
> +void setup_clear_cpu_cap(unsigned int cap)
>  {
>   const uint32_t *dfs;
>   unsigned int i;
> @@ -83,7 +83,7 @@ void __init setup_clear_cpu_cap(unsigned int cap)
>   }
>  }
>  
> -void __init setup_force_cpu_cap(unsigned int cap)
> +void setup_force_cpu_cap(unsigned int cap)
>  {
>   if (__test_and_set_bit(cap, forced_caps))
>   return;

 The two functions are deliberately __init, as any call to them
 post-init is not going to take system-wide effect. These functions
 should really be __init_presmp, if we had something like this. No
 use of them on an AP boot path is going to affect the BSP, and
 hence will leave the system in an inconsistent state.
>>>
>>> On second thought, looking at how many places actually call 
>>> setup_{force,clear}_cpu_cap() on AP init path it still makes sense
>>> to keep the v1 approach as otherwise we will have to manually workaround
>>> every single place where it happens.
>>
>> While not all of the other uses of the functions happen from __init
>> functions, all of them are unreachable on APs afaict - I've just
>> gone through all instances.
> 
> I see 2 places where it looks suspicious:
> psr_cpu_init(), mwait_idle_cpu_init()

if ( !psr_alloc_feat_enabled() || !boot_cpu_has(X86_FEATURE_PQE) )
goto assoc_init;

if ( boot_cpu_data.cpuid_level < PSR_CPUID_LEVEL_CAT )
{
setup_clear_cpu_cap(X86_FEATURE_PQE);
goto assoc_init;
}

The boot_cpu_has(X86_FEATURE_PQE) will prevent the 2nd if() from
being reached by an AP, if the BSP force-cleared the feature.

if (state > 2 && !boot_cpu_has(X86_FEATURE_NONSTOP_TSC) &&
!pm_idle_save)
setup_clear_cpu_cap(X86_FEATURE_TSC_RELIABLE);

The !pm_idle_save check is the guard here.

Jan

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

Re: [Xen-devel] [PATCH for-4.13] x86/AMD: unbreak CPU hotplug on AMD systems without RstrFpErrPtrs

[Igor Druzhinin]

On 03/12/2019 14:28, Jan Beulich wrote:
> On 03.12.2019 15:21, Igor Druzhinin wrote:
>> On 03/12/2019 10:08, Jan Beulich wrote:
>>> On 29.11.2019 21:01, Igor Druzhinin wrote:
 --- a/xen/arch/x86/cpu/common.c
 +++ b/xen/arch/x86/cpu/common.c
 @@ -54,7 +54,7 @@ static unsigned int forced_caps[NCAPINTS];
  
  DEFINE_PER_CPU(bool, full_gdt_loaded);
  
 -void __init setup_clear_cpu_cap(unsigned int cap)
 +void setup_clear_cpu_cap(unsigned int cap)
  {
const uint32_t *dfs;
unsigned int i;
 @@ -83,7 +83,7 @@ void __init setup_clear_cpu_cap(unsigned int cap)
}
  }
  
 -void __init setup_force_cpu_cap(unsigned int cap)
 +void setup_force_cpu_cap(unsigned int cap)
  {
if (__test_and_set_bit(cap, forced_caps))
return;
>>>
>>> The two functions are deliberately __init, as any call to them
>>> post-init is not going to take system-wide effect. These functions
>>> should really be __init_presmp, if we had something like this. No
>>> use of them on an AP boot path is going to affect the BSP, and
>>> hence will leave the system in an inconsistent state.
>>
>> On second thought, looking at how many places actually call 
>> setup_{force,clear}_cpu_cap() on AP init path it still makes sense
>> to keep the v1 approach as otherwise we will have to manually workaround
>> every single place where it happens.
> 
> While not all of the other uses of the functions happen from __init
> functions, all of them are unreachable on APs afaict - I've just
> gone through all instances.

I see 2 places where it looks suspicious:
psr_cpu_init(), mwait_idle_cpu_init()

Igor

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

Re: [Xen-devel] [PATCH] xen/arm: Basic support for sunxi/sun50i h6 platform.

[Andre Przywara]

On Tue, 3 Dec 2019 11:39:58 +
Julien Grall  wrote:

Hi,

> (+Andre)
> 
> Hi,
> 
> @Andre, IIRC you originally added the support for sunxi in Xen. Could 
> you have a look at this patch?

Looks alright, and indeed the H6 needs it. Even though Allwinner totally 
re-arranged the memory map, they missed the opportunity to put each device at 
least in their own 4K page.

Reviewed-by: Andre Przywara 


If you can wait till this evening, I can even test it.

It's actually a shame that we need this enumeration, when all we are after is 
an answer to the question: Does a device used by Xen share a 4K page with a 
device handed off to Dom0? It sounds like a nice rainy afternoon exercise to 
scan the DT to find those devices automatically and mask them (on the A64 for 
instance UART4 is on a different page).

Cheers,
Andre

> On 02/12/2019 08:49, Yangtao Li wrote:
> > adding compatible strings for h6 SoCs, Specifically orangepi3.
> > 
> > Signed-off-by: Yangtao Li   
> > --- >   xen/arch/arm/platforms/sunxi.c | 1 +  
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/xen/arch/arm/platforms/sunxi.c b/xen/arch/arm/platforms/sunxi.c
> > index 55705b15b2..e8e4d88bef 100644
> > --- a/xen/arch/arm/platforms/sunxi.c
> > +++ b/xen/arch/arm/platforms/sunxi.c
> > @@ -119,6 +119,7 @@ static const char * const sunxi_v8_dt_compat[] 
> > __initconst =
> >   {
> >   "allwinner,sun50i-a64",
> >   "allwinner,sun50i-h5",
> > +"allwinner,sun50i-h6",
> >   NULL
> >   };
> >   
> >   
> 


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

Re: [Xen-devel] [PATCH] xen/blkback: Avoid unmapping unmapped grant pages

[sjpark]

On 27.11.19 10:13, Roger Pau Monné wrote:
> On Tue, Nov 26, 2019 at 04:36:05PM +0100, SeongJae Park wrote:
>> From: SeongJae Park 
>>
>> For each I/O request, blkback first maps the foreign pages for the
>> request to its local pages.  If an allocation of a local page for the
>> mapping fails, it should unmap every mapping already made for the
>> request.
>>
>> However, blkback's handling mechanism for the allocation failure does
>> not mark the remaining foreign pages as unmapped.  Therefore, the unmap
>> function merely tries to unmap every valid grant page for the request,
>> including the pages not mapped due to the allocation failure.  On a
>> system that fails the allocation frequently, this problem leads to
>> following kernel crash.
>>
>>   [  372.012538] BUG: unable to handle kernel NULL pointer dereference at 
>> 0001
>>   [  372.012546] IP: [] gnttab_unmap_refs.part.7+0x1c/0x40
>>   [  372.012557] PGD 16f3e9067 PUD 16426e067 PMD 0
>>   [  372.012562] Oops: 0002 [#1] SMP
>>   [  372.012566] Modules linked in: act_police sch_ingress cls_u32
>>   ...
>>   [  372.012746] Call Trace:
>>   [  372.012752]  [] gnttab_unmap_refs+0x34/0x40
>>   [  372.012759]  [] xen_blkbk_unmap+0x83/0x150 
>> [xen_blkback]
>>   ...
>>   [  372.012802]  [] dispatch_rw_block_io+0x970/0x980 
>> [xen_blkback]
>>   ...
>>   Decompressing Linux... Parsing ELF... done.
>>   Booting the kernel.
>>   [0.00] Initializing cgroup subsys cpuset
>>
>> This commit fixes this problem by marking the grant pages of the given
>> request that didn't mapped due to the allocation failure as invalid.
>>
>> Fixes: c6cc142dac52 ("xen-blkback: use balloon pages for all mappings")
>>
>> Signed-off-by: SeongJae Park 
>> Reviewed-by: David Woodhouse 
>> Reviewed-by: Maximilian Heyne 
>> Reviewed-by: Paul Durrant 
> Reviewed-by: Roger Pau Monné 
>
> Thanks, Roger.


May I ask some more comments?



Thanks,

SeongJae Park



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

Re: [Xen-devel] [PATCH for-4.13] x86/AMD: unbreak CPU hotplug on AMD systems without RstrFpErrPtrs

[Jan Beulich]

On 03.12.2019 15:21, Igor Druzhinin wrote:
> On 03/12/2019 10:08, Jan Beulich wrote:
>> On 29.11.2019 21:01, Igor Druzhinin wrote:
>>> --- a/xen/arch/x86/cpu/common.c
>>> +++ b/xen/arch/x86/cpu/common.c
>>> @@ -54,7 +54,7 @@ static unsigned int forced_caps[NCAPINTS];
>>>  
>>>  DEFINE_PER_CPU(bool, full_gdt_loaded);
>>>  
>>> -void __init setup_clear_cpu_cap(unsigned int cap)
>>> +void setup_clear_cpu_cap(unsigned int cap)
>>>  {
>>> const uint32_t *dfs;
>>> unsigned int i;
>>> @@ -83,7 +83,7 @@ void __init setup_clear_cpu_cap(unsigned int cap)
>>> }
>>>  }
>>>  
>>> -void __init setup_force_cpu_cap(unsigned int cap)
>>> +void setup_force_cpu_cap(unsigned int cap)
>>>  {
>>> if (__test_and_set_bit(cap, forced_caps))
>>> return;
>>
>> The two functions are deliberately __init, as any call to them
>> post-init is not going to take system-wide effect. These functions
>> should really be __init_presmp, if we had something like this. No
>> use of them on an AP boot path is going to affect the BSP, and
>> hence will leave the system in an inconsistent state.
> 
> On second thought, looking at how many places actually call 
> setup_{force,clear}_cpu_cap() on AP init path it still makes sense
> to keep the v1 approach as otherwise we will have to manually workaround
> every single place where it happens.

While not all of the other uses of the functions happen from __init
functions, all of them are unreachable on APs afaict - I've just
gone through all instances.

Jan

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

Re: [Xen-devel] [RFC XEN PATCH v3 08/11] xen: arm: vgic: don't fail if IRQ is already connected

[Julien Grall]

Hi,

On 15/11/2019 20:10, Stewart Hildebrand wrote:

There are some IRQs that happen to have multiple "interrupts = < ... >;"
properties with the same IRQ in the device tree. For example:

interrupts = <0 123 4>,
  <0 123 4>,
  <0 123 4>,
  <0 123 4>,
  <0 123 4>;

In this case it seems that we are invoking vgic_connect_hw_irq multiple
times for the same IRQ.

Rework the checks to allow booting in this scenario.

I have not seen any cases where the pre-existing p->desc is any different from
the new desc, so BUG() out if they're different for now.

Signed-off-by: Stewart Hildebrand 

---
v3: new patch

I tested on Xilinx Zynq UltraScale+ with the old vGIC. I have not fully
tested with CONFIG_NEW_VGIC. This hack only became necessary after
introducing the PPI series, and I'm not entirely sure what the reason
is for that.

I'm also unsure if BUG()ing out is the right thing to do in case of
desc != p->desc, or what conditions would even trigger this? Is this
function exposed to guests?


This can happen with PPIs as the desc is per-CPU. If you migrate the 
vCPU to another pCPU, you will likely hit the BUG() below if the guest 
disabled the interrupt.


But I don't think we should call vgic_connect_hw_irq() multiples time on 
the same IRQ. The upper layer should take care of such issue (such as 
setup_guest_irq()).


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH for-4.13] x86/AMD: unbreak CPU hotplug on AMD systems without RstrFpErrPtrs

[Igor Druzhinin]

On 03/12/2019 10:08, Jan Beulich wrote:
> On 29.11.2019 21:01, Igor Druzhinin wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -54,7 +54,7 @@ static unsigned int forced_caps[NCAPINTS];
>>  
>>  DEFINE_PER_CPU(bool, full_gdt_loaded);
>>  
>> -void __init setup_clear_cpu_cap(unsigned int cap)
>> +void setup_clear_cpu_cap(unsigned int cap)
>>  {
>>  const uint32_t *dfs;
>>  unsigned int i;
>> @@ -83,7 +83,7 @@ void __init setup_clear_cpu_cap(unsigned int cap)
>>  }
>>  }
>>  
>> -void __init setup_force_cpu_cap(unsigned int cap)
>> +void setup_force_cpu_cap(unsigned int cap)
>>  {
>>  if (__test_and_set_bit(cap, forced_caps))
>>  return;
> 
> The two functions are deliberately __init, as any call to them
> post-init is not going to take system-wide effect. These functions
> should really be __init_presmp, if we had something like this. No
> use of them on an AP boot path is going to affect the BSP, and
> hence will leave the system in an inconsistent state.

On second thought, looking at how many places actually call 
setup_{force,clear}_cpu_cap() on AP init path it still makes sense
to keep the v1 approach as otherwise we will have to manually workaround
every single place where it happens.

Igor

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

Re: [Xen-devel] [PATCH for-4.13] x86/AMD: unbreak CPU hotplug on AMD systems without RstrFpErrPtrs

[Jan Beulich]

On 03.12.2019 15:11, Andrew Cooper wrote:
> On 03/12/2019 10:08, Jan Beulich wrote:
>> On 29.11.2019 21:01, Igor Druzhinin wrote:
>>> --- a/xen/arch/x86/cpu/common.c
>>> +++ b/xen/arch/x86/cpu/common.c
>>> @@ -54,7 +54,7 @@ static unsigned int forced_caps[NCAPINTS];
>>>  
>>>  DEFINE_PER_CPU(bool, full_gdt_loaded);
>>>  
>>> -void __init setup_clear_cpu_cap(unsigned int cap)
>>> +void setup_clear_cpu_cap(unsigned int cap)
>>>  {
>>> const uint32_t *dfs;
>>> unsigned int i;
>>> @@ -83,7 +83,7 @@ void __init setup_clear_cpu_cap(unsigned int cap)
>>> }
>>>  }
>>>  
>>> -void __init setup_force_cpu_cap(unsigned int cap)
>>> +void setup_force_cpu_cap(unsigned int cap)
>>>  {
>>> if (__test_and_set_bit(cap, forced_caps))
>>> return;
>> The two functions are deliberately __init, as any call to them
>> post-init is not going to take system-wide effect.
> 
> Current example demonstrates the contrary.  Setting X86_BUG_FPU_PTRS at
> any point through the runtime of Xen will cause the safe action to start
> happening.

This is because of an implementation detail _and_ specific to this
one flag. In general what I've said applies; making these functions
non-_init will give the false impression that their use it going to
have an effect in general. I.e. doing as you suggest would lay the
groundwork for future bugs. As an aside, recall my objection to use
the x86_capabilities[] machinery for this erratum? You wanting
__init dropped here is a result of that (as I would call it) abuse.

> Dropping this call on the non-boot CPUs leads to an insecure
> configuration which we're perfectly capable of working around, and
> therefore isn't an acceptable solution.

A prereq to retaining the calls on APs would be to make non-BSP use
of the functions generally safe. Otherwise, if you want to support
such asymmetric configurations, cpu_bug_fpu_ptrs wants to be
switched to a bool variable.

Jan

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

Re: [Xen-devel] [PATCH for-4.13] x86/AMD: unbreak CPU hotplug on AMD systems without RstrFpErrPtrs

[Andrew Cooper]

On 03/12/2019 10:08, Jan Beulich wrote:
> On 29.11.2019 21:01, Igor Druzhinin wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -54,7 +54,7 @@ static unsigned int forced_caps[NCAPINTS];
>>  
>>  DEFINE_PER_CPU(bool, full_gdt_loaded);
>>  
>> -void __init setup_clear_cpu_cap(unsigned int cap)
>> +void setup_clear_cpu_cap(unsigned int cap)
>>  {
>>  const uint32_t *dfs;
>>  unsigned int i;
>> @@ -83,7 +83,7 @@ void __init setup_clear_cpu_cap(unsigned int cap)
>>  }
>>  }
>>  
>> -void __init setup_force_cpu_cap(unsigned int cap)
>> +void setup_force_cpu_cap(unsigned int cap)
>>  {
>>  if (__test_and_set_bit(cap, forced_caps))
>>  return;
> The two functions are deliberately __init, as any call to them
> post-init is not going to take system-wide effect.

Current example demonstrates the contrary.  Setting X86_BUG_FPU_PTRS at
any point through the runtime of Xen will cause the safe action to start
happening.

Dropping this call on the non-boot CPUs leads to an insecure
configuration which we're perfectly capable of working around, and
therefore isn't an acceptable solution.

~Andrew

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

Re: [Xen-devel] [PATCH for-4.13] x86/AMD: unbreak CPU hotplug on AMD systems without RstrFpErrPtrs

[Igor Druzhinin]

On 03/12/2019 10:08, Jan Beulich wrote:
> On 29.11.2019 21:01, Igor Druzhinin wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -54,7 +54,7 @@ static unsigned int forced_caps[NCAPINTS];
>>  
>>  DEFINE_PER_CPU(bool, full_gdt_loaded);
>>  
>> -void __init setup_clear_cpu_cap(unsigned int cap)
>> +void setup_clear_cpu_cap(unsigned int cap)
>>  {
>>  const uint32_t *dfs;
>>  unsigned int i;
>> @@ -83,7 +83,7 @@ void __init setup_clear_cpu_cap(unsigned int cap)
>>  }
>>  }
>>  
>> -void __init setup_force_cpu_cap(unsigned int cap)
>> +void setup_force_cpu_cap(unsigned int cap)
>>  {
>>  if (__test_and_set_bit(cap, forced_caps))
>>  return;
> 
> The two functions are deliberately __init, as any call to them
> post-init is not going to take system-wide effect. These functions
> should really be __init_presmp, if we had something like this. No
> use of them on an AP boot path is going to affect the BSP, and
> hence will leave the system in an inconsistent state.
> 

I agree with you and have a version where I just gate the corresponding 
calls with (c == _cpu_data). Removing __init was the approach
suggested by Andrew following the concern of potentially asymmetric
microcode in a system which I don't think would work anyway due to
the reasons you mentioned.

I will send the original approach as v2.

Igor

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

Re: [Xen-devel] [PATCH 0/2] automation: improve tests

[Jürgen Groß]

On 03.12.19 11:33, Roger Pau Monne wrote:

Hello,

Small series to improve the automated tests, first patch enables Xen
console timestamps and the second one increases the test timeout to 30s
since the clang PVH tests already takes ~10s without taking into account
the time to initialize QEMU.

Thanks, Roger.

Roger Pau Monne (2):
   automation: add timestamps to Xen tests
   automation: increase tests maximum time from 10s to 30s

  automation/scripts/qemu-smoke-x86-64.sh | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)



For the series:

Release-acked-by: Juergen Gross 


Juergen

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  0a65cba423781f2cbf123354b7f670c4f441b385
baseline version:
 libvirt  ff1af696c1979d6d8fac4c4cc77e9430fd5c93fd

Last test of basis   144408  2019-11-30 04:18:46 Z3 days
Testing same since   144501  2019-12-03 04:20:06 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrangé 
  Daniel Veillard 
  Jim Fehlig 
  Peter Krempa 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/libvirt.git
   ff1af696c1..0a65cba423  0a65cba423781f2cbf123354b7f670c4f441b385 -> 
xen-tested-master

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

[Xen-devel] Xen 4.11.3 released

[Jan Beulich]

All,

I am pleased to announce the release of Xen 4.11.3. This is available
immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.11
(tag RELEASE-4.11.3) or from the XenProject download page
https://xenproject.org/downloads/xen-project-archives/xen-project-4-11-series/xen-project-4-11-3/
(where a list of changes can also be found).

We recommend all users of the 4.11 stable series to update to this
latest point release.

Regards, Jan

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

[Xen-devel] [xen-4.13-testing test] 144500: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  8ba357fc326c9e6f2f7d39c461955c110fea9a8a
baseline version:
 xen  7a0e35f82325cc0d25315eeca34e45c05abd28cd

Last test of basis   144402  2019-11-30 00:06:57 Z3 days
Testing same since   144493  2019-12-02 15:36:14 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Yi Sun 

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

Re: [Xen-devel] Community Call: Call for Agenda Items and call details for Thursday Dec 5, 16:00 - 17:00 UTC

[Lars Kurth]

Correction: the meeting is this Thursday, the 5th
Apologies for the typo
Lars


On 02/12/2019, 20:05, "Lars Kurth"  wrote:

Dear community members,
 
please send me agenda items for this Friday’s community call (sorry for the 
late notice, I was on PTO last week). A draft agenda is at 
https://cryptpad.fr/pad/#/2/pad/edit/PCtBphoXkCTiXABJ8cdL0KuZ/ 
Please add agenda items to the document or reply to this e-mail

@Juergen: I added a slot re the 4.13 release
@Doug: I saw some activity recently about the CI Loop stuff - maybe worth 
discussing, if you have time
@Ian: you mentioned that you wanted to find a way to get sysadmin help from 
someone in the community to help maintain test infra - I wanted to run this 
past this group first to see whether any names come to mind. The required 
skillset is likely to be different to that of a developer 

UPDATE: Paul Durrant will be release manager for 4.14 - congratulations

Last month’s minutes are at 
https://cryptpad.fr/pad/#/2/pad/view/7l3a4mhZTU4xs0GE415OXiAj0ScKl39xdQ9wm0cwASs/
 
 
Best Regards
Lars

## Meeting time (please double check the times)
16:00 - 17:00 UTC
08:00 - 09:00 PST (San Francisco) - sorry for the early time slot. If this 
is a problem, let's discuss at the call
10:00 - 11:00 CST (Austin, Costa Rica)
11:00 - 12:00 EST (New York)
16:00 - 17:00 FMT (London)
17:00 - 18:00 CET (Berlin)
00:00 - 01:00+1 CST (Beijing)

Further International meeting times: 
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019=12=5=16=0=0=224=24=179=136=37=33

## Dial in details
Web: https://www.gotomeet.me/larskurth

You can also dial in using your phone
Access Code: 906-886-965

China (Toll Free): 4008 811084
Germany: +49 692 5736 7317
Poland (Toll Free): 00 800 1124759
United Kingdom: +44 330 221 0088
United States: +1 (571) 317-3129

More phone numbers
Australia: +61 2 9087 3604
Austria: +43 7 2081 5427
Argentina (Toll Free): 0 800 444 3375
Bahrain (Toll Free): 800 81 111
Belarus (Toll Free): 8 820 0011 0400
Belgium: +32 28 93 7018
Brazil (Toll Free): 0 800 047 4906
Bulgaria (Toll Free): 00800 120 4417
Canada: +1 (647) 497-9391
Chile (Toll Free): 800 395 150
Colombia (Toll Free): 01 800 518 4483
Czech Republic (Toll Free): 800 500448
Denmark: +45 32 72 03 82
Finland: +358 923 17 0568
France: +33 170 950 594
Greece (Toll Free): 00 800 4414 3838
Hong Kong (Toll Free): 30713169
Hungary (Toll Free): (06) 80 986 255
Iceland (Toll Free): 800 7204
India (Toll Free): 18002669272
Indonesia (Toll Free): 007 803 020 5375
Ireland: +353 15 360 728
Israel (Toll Free): 1 809 454 830
Italy: +39 0 247 92 13 01
Japan (Toll Free): 0 120 663 800
Korea, Republic of (Toll Free): 00798 14 207 4914
Luxembourg (Toll Free): 800 85158
Malaysia (Toll Free): 1 800 81 6854
Mexico (Toll Free): 01 800 522 1133
Netherlands: +31 207 941 377
New Zealand: +64 9 280 6302
Norway: +47 21 93 37 51
Panama (Toll Free): 00 800 226 7928
Peru (Toll Free): 0 800 77023
Philippines (Toll Free): 1 800 1110 1661
Portugal (Toll Free): 800 819 575
Romania (Toll Free): 0 800 410 029
Russian Federation (Toll Free): 8 800 100 6203
Saudi Arabia (Toll Free): 800 844 3633
Singapore (Toll Free): 18007231323
South Africa (Toll Free): 0 800 555 447
Spain: +34 932 75 2004
Sweden: +46 853 527 827
Switzerland: +41 225 4599 78
Taiwan (Toll Free): 0 800 666 854
Thailand (Toll Free): 001 800 011 023
Turkey (Toll Free): 00 800 4488 23683
Ukraine (Toll Free): 0 800 50 1733
United Arab Emirates (Toll Free): 800 044 40439
Uruguay (Toll Free): 0004 019 1018
Viet Nam (Toll Free): 122 80 481

First GoToMeeting? Let's do a quick system check:
https://link.gotomeeting.com/system-check




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

Re: [Xen-devel] [PATCH] xen/arm: Basic support for sunxi/sun50i h6 platform.

[Julien Grall]

(+Andre)

Hi,

@Andre, IIRC you originally added the support for sunxi in Xen. Could 
you have a look at this patch?


Cheers,

On 02/12/2019 08:49, Yangtao Li wrote:

adding compatible strings for h6 SoCs, Specifically orangepi3.

Signed-off-by: Yangtao Li 
--- >   xen/arch/arm/platforms/sunxi.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/xen/arch/arm/platforms/sunxi.c b/xen/arch/arm/platforms/sunxi.c
index 55705b15b2..e8e4d88bef 100644
--- a/xen/arch/arm/platforms/sunxi.c
+++ b/xen/arch/arm/platforms/sunxi.c
@@ -119,6 +119,7 @@ static const char * const sunxi_v8_dt_compat[] __initconst =
  {
  "allwinner,sun50i-a64",
  "allwinner,sun50i-h5",
+"allwinner,sun50i-h6",
  NULL
  };
  



--
Julien Grall

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

Re: [Xen-devel] Community Call: Call for Agenda Items and call details for Dec 4, 16:00 - 17:00 UTC

[Jan Beulich]

On 03.12.2019 03:05, Lars Kurth wrote:
> Dear community members,
>  
> please send me agenda items for this Friday’s community call (sorry
> for the late notice, I was on PTO last week). A draft agenda is at
> https://cryptpad.fr/pad/#/2/pad/edit/PCtBphoXkCTiXABJ8cdL0KuZ/ 

I'm confused: The title says Dec 4, which is Wednesday. The text
above says Friday. Iirc we used to run this on Thursdays.

Jan

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

Re: [Xen-devel] [PATCH 1/2] automation: add timestamps to Xen tests

[Wei Liu]

On Tue, 3 Dec 2019 at 10:35, Roger Pau Monne  wrote:
>
> Enable Xen timestamps in the automated Xen tests, this is helpful in
> order to figure out if Xen is stuck or just slow in the automated
> tests.
>
> Signed-off-by: Roger Pau Monné 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 2/2] automation: increase tests maximum time from 10s to 30s

[Wei Liu]

On Tue, 3 Dec 2019 at 10:34, Roger Pau Monne  wrote:
>
> 10s is too low for the clang tests, this is the output from a clang
> test:
>
> (XEN) [6.512748] ***
> (XEN) [6.513323] SELFTEST FAILURE: CORRECT BEHAVIOR CANNOT BE GUARANTEED
> (XEN) [6.513891] ***
> (XEN) [6.514469] 3... 2... 1...
> (XEN) [9.520011] *** Serial input to DOM0 (type 'CTRL-a' three times to 
> switch input)
> (XEN) [9.544319] Freed 488kB init memory
> --- Xen Test Framework ---
> Environment: HVM 32bit (PAE 3 levels)
> Hello World
> Test result: SUCCESS
> (XEN) [9.610977] Hardware Dom0 halted: halting machine
>
> As can be seen from the output above booting Xen and the XTF test
> takes ~10s, without accounting for the time it takes for QEMU to
> initialize.
>
> Increase the timeout to 30s to be on the safe side.
>
> Signed-off-by: Roger Pau Monné 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH for-4.13] x86: re-order clang no integrated assembler tests

[Jan Beulich]

On 03.12.2019 12:04, Roger Pau Monné wrote:
> On Tue, Dec 03, 2019 at 11:03:31AM +0100, Jan Beulich wrote:
>> Furthermore I think this moving around of logic (which imo
>> would better remain at the bottom of the file, well out of
>> sight) is only the second best solution to the issue. The
>> reason I didn't notice the breakage was because I had noticed
>> what made me create the patch in question only while putting
>> together a change moving out the majority of the as-option-add
>> invocations, primarily with the goal of not having the
>> compiler invoked over and over just to calculate CFLAGS. I
>> didn't post this change yet simply because I wanted to give it
>> some more (local) testing.
> 
> Looks like an improvement, but how do you plan to achieve the same?
> 
> Are there some compiler/assembler hints available at build time about
> which features are supported?

No, I'm changing the mechanism altogether. The various HAVE_AS_*
will be put in a generated header file instead. Its generation
(obviously) happens with CFLAGS already in final shape.

>> Another reason to keep this at the bottom of the file is that
>> other CFLAGS additions wouldn't have happened yet at the
>> place the checks live now.
> 
> Right, but it's unlikely that CFLAGS can influence whether the
> internal assembler is capable of building Xen or not, while it's IMO
> more likely that using the internal or an external assembler can lead
> to a different set of CFLAGS (as CFLAGS also include options that
> affect the assembler).

For simple checks against insns being known I agree. But already
something like

# Set up the assembler include path properly for older toolchains.
CFLAGS += -Wa,-I$(BASEDIR)/include

could make a difference, if a more complex check involved
including some other file.

Jan

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

Re: [Xen-devel] [PATCH for-4.13] x86: re-order clang no integrated assembler tests

[Roger Pau Monné]

On Tue, Dec 03, 2019 at 11:03:31AM +0100, Jan Beulich wrote:
> On 02.12.2019 12:29, Roger Pau Monne wrote:
> > The tests to check whether the integrated assembler is capable of
> > building Xen should be performed before testing any assembler
> > features, or else the feature specific tests would be stale if the
> > integrated assembler is disabled afterwards.
> > 
> > Fixes: ef286f67787a ('x86: move and fix clang .skip check')
> 
> Perhaps this change has made the situation worse (and I'm sorry
> for the breakage), but the issue was definitely there before.
> The change above merely added one check to two already present
> ones in the same place.

I agree this was already broken, that change just made things worse
and caused tests to start failing, so I've used the fixes tag in order
to notice this change did restore things to the previous state.

> > --- a/xen/arch/x86/Rules.mk
> > +++ b/xen/arch/x86/Rules.mk
> > @@ -12,6 +12,30 @@ CFLAGS += '-D__OBJECT_LABEL__=$(subst /,$$,$(subst 
> > -,_,$(subst $(BASEDIR)/,,$(CU
> >  # Prevent floating-point variables from creeping into Xen.
> >  CFLAGS += -msoft-float
> >  
> > +ifeq ($(clang),y)
> > +# Note: Any test which adds -no-integrated-as will cause subsequent tests 
> > to
> > +# succeed, and not trigger further additions.
> > +#
> > +# The tests to select whether the integrated assembler is usable need to 
> > happen
> > +# before testing any assembler features, or else the result of the tests 
> > would
> > +# be stale if the integrated assembler is not used.
> > +
> > +# Older clang's built-in assembler doesn't understand .skip with labels:
> > +# https://bugs.llvm.org/show_bug.cgi?id=27369
> > +$(call as-option-add,CFLAGS,CC,".L0: .L1: .skip (.L1 - .L0)",,\
> > + -no-integrated-as)
> > +
> > +# Check whether clang asm()-s support .include.
> > +$(call as-option-add,CFLAGS,CC,".include \"asm/indirect_thunk_asm.h\"",,\
> > + -no-integrated-as)
> > +
> > +# Check whether clang keeps .macro-s between asm()-s:
> > +# https://bugs.llvm.org/show_bug.cgi?id=36110
> > +$(call as-option-add,CFLAGS,CC,\
> > + ".macro FOO;.endm"$$(close); asm volatile 
> > $$(open)".macro FOO;.endm",\
> > + -no-integrated-as)
> > +endif
> > +
> >  $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
> >  $(call cc-option-add,CFLAGS,CC,-Wnested-externs)
> >  $(call as-option-add,CFLAGS,CC,"vmcall",-DHAVE_AS_VMX)
> > @@ -70,22 +94,3 @@ endif
> >  # Set up the assembler include path properly for older toolchains.
> >  CFLAGS += -Wa,-I$(BASEDIR)/include
> >  
> > -ifeq ($(clang),y)
> > -# Note: Any test which adds -no-integrated-as will cause subsequent tests 
> > to
> > -# succeed, and not trigger further additions.
> > -
> > -# Older clang's built-in assembler doesn't understand .skip with labels:
> > -# https://bugs.llvm.org/show_bug.cgi?id=27369
> > -$(call as-option-add,CFLAGS,CC,".L0: .L1: .skip (.L1 - .L0)",,\
> > - -no-integrated-as)
> > -
> > -# Check whether clang asm()-s support .include.
> > -$(call as-option-add,CFLAGS,CC,".include \"asm/indirect_thunk_asm.h\"",,\
> > - -no-integrated-as)
> > -
> > -# Check whether clang keeps .macro-s between asm()-s:
> > -# https://bugs.llvm.org/show_bug.cgi?id=36110
> > -$(call as-option-add,CFLAGS,CC,\
> > - ".macro FOO;.endm"$$(close); asm volatile 
> > $$(open)".macro FOO;.endm",\
> > - -no-integrated-as)
> > -endif
> 
> Furthermore I think this moving around of logic (which imo
> would better remain at the bottom of the file, well out of
> sight) is only the second best solution to the issue. The
> reason I didn't notice the breakage was because I had noticed
> what made me create the patch in question only while putting
> together a change moving out the majority of the as-option-add
> invocations, primarily with the goal of not having the
> compiler invoked over and over just to calculate CFLAGS. I
> didn't post this change yet simply because I wanted to give it
> some more (local) testing.

Looks like an improvement, but how do you plan to achieve the same?

Are there some compiler/assembler hints available at build time about
which features are supported?

> Another reason to keep this at the bottom of the file is that
> other CFLAGS additions wouldn't have happened yet at the
> place the checks live now.

Right, but it's unlikely that CFLAGS can influence whether the
internal assembler is capable of building Xen or not, while it's IMO
more likely that using the internal or an external assembler can lead
to a different set of CFLAGS (as CFLAGS also include options that
affect the assembler).

> Since there's one as-option-add
> invocation remaining even after my change (the one
> establishing HAVE_AS_QUOTED_SYM, not fitting the model used
> because of the further option additions), I guess the right
> course of action is going to be to move the block back down
> 

Re: [Xen-devel] [PATCH v1] xen-pciback: optionally allow interrupt enable flag writes

[Jan Beulich]

On 03.12.2019 06:41, Marek Marczykowski-Górecki  wrote:
> @@ -117,6 +118,35 @@ static int command_write(struct pci_dev *dev, int 
> offset, u16 value, void *data)
>   pci_clear_mwi(dev);
>   }
>  
> + if (dev_data && dev_data->allow_interrupt_control) {
> + if (!(cmd->val & PCI_COMMAND_INTX_DISABLE) &&
> + (value & PCI_COMMAND_INTX_DISABLE)) {
> + pci_intx(dev, 0);
> + } else if ((cmd->val & PCI_COMMAND_INTX_DISABLE) &&
> + !(value & PCI_COMMAND_INTX_DISABLE)) {
> + /* Do not allow enabling INTx together with MSI or 
> MSI-X. */
> + /* Do not trust dev->msi(x)_enabled here, as enabling 
> could be done
> +  * bypassing the pci_*msi* functions, by the qemu.
> +  */
> + err = pci_read_config_word(dev,
> +dev->msi_cap + PCI_MSI_FLAGS,
> +_value);
> + if (!err && (cap_value & PCI_MSI_FLAGS_ENABLE))
> + err = -EBUSY;
> + if (!err)
> + err = pci_read_config_word(dev,
> +dev->msix_cap + 
> PCI_MSIX_FLAGS,
> +_value);

What about a device without MSI and/or MSI-X? Wouldn't you read
from (close to) config space offset 0 in this case, interpreting
some unrelated bit(s) as the MSI / MSI-X enable one(s)?

Just as an initial implementation related remark. I'm still to
think about the idea as a whole, albeit I find the argument
pretty convincing at the first glance of devices being able to
raise MSI anyway even when disabled as per the config space
setting. (Of course, as with any config space settings, devices
providing backdoor access would open similar avenues.)

Jan

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

Re: [Xen-devel] [PATCH 0/2] automation: improve tests

[Andrew Cooper]

On 03/12/2019 10:33, Roger Pau Monne wrote:
> Hello,
>
> Small series to improve the automated tests, first patch enables Xen
> console timestamps and the second one increases the test timeout to 30s
> since the clang PVH tests already takes ~10s without taking into account
> the time to initialize QEMU.
>
> Thanks, Roger.
>
> Roger Pau Monne (2):
>   automation: add timestamps to Xen tests
>   automation: increase tests maximum time from 10s to 30s

Acked-by: Andrew Cooper 

CC Juergen for a view towards 4.13

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

[Xen-devel] [PATCH 1/2] automation: add timestamps to Xen tests

[Roger Pau Monne]

Enable Xen timestamps in the automated Xen tests, this is helpful in
order to figure out if Xen is stuck or just slow in the automated
tests.

Signed-off-by: Roger Pau Monné 
---
 automation/scripts/qemu-smoke-x86-64.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/automation/scripts/qemu-smoke-x86-64.sh 
b/automation/scripts/qemu-smoke-x86-64.sh
index 5fa3a63dbd..f38eacfd9f 100755
--- a/automation/scripts/qemu-smoke-x86-64.sh
+++ b/automation/scripts/qemu-smoke-x86-64.sh
@@ -24,7 +24,8 @@ set +e
 timeout -k 1 10 \
 qemu-system-x86_64 -nographic -kernel binaries/xen \
 -initrd xtf/tests/example/$k \
--append "loglvl=all com1=115200,,8n1 console=com1 noreboot $extra" \
+-append "loglvl=all com1=115200,,8n1 console=com1 noreboot \
+ console_timestamps=boot $extra" \
 -m 512 -monitor none -serial file:smoke.serial
 set -e
 grep -q 'Test result: SUCCESS' smoke.serial || exit 1
-- 
2.24.0


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

[Xen-devel] [PATCH 0/2] automation: improve tests

[Roger Pau Monne]

Hello,

Small series to improve the automated tests, first patch enables Xen
console timestamps and the second one increases the test timeout to 30s
since the clang PVH tests already takes ~10s without taking into account
the time to initialize QEMU.

Thanks, Roger.

Roger Pau Monne (2):
  automation: add timestamps to Xen tests
  automation: increase tests maximum time from 10s to 30s

 automation/scripts/qemu-smoke-x86-64.sh | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

-- 
2.24.0


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

[Xen-devel] [PATCH 2/2] automation: increase tests maximum time from 10s to 30s

[Roger Pau Monne]

10s is too low for the clang tests, this is the output from a clang
test:

(XEN) [6.512748] ***
(XEN) [6.513323] SELFTEST FAILURE: CORRECT BEHAVIOR CANNOT BE GUARANTEED
(XEN) [6.513891] ***
(XEN) [6.514469] 3... 2... 1...
(XEN) [9.520011] *** Serial input to DOM0 (type 'CTRL-a' three times to 
switch input)
(XEN) [9.544319] Freed 488kB init memory
--- Xen Test Framework ---
Environment: HVM 32bit (PAE 3 levels)
Hello World
Test result: SUCCESS
(XEN) [9.610977] Hardware Dom0 halted: halting machine

As can be seen from the output above booting Xen and the XTF test
takes ~10s, without accounting for the time it takes for QEMU to
initialize.

Increase the timeout to 30s to be on the safe side.

Signed-off-by: Roger Pau Monné 
---
 automation/scripts/qemu-smoke-x86-64.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/automation/scripts/qemu-smoke-x86-64.sh 
b/automation/scripts/qemu-smoke-x86-64.sh
index f38eacfd9f..09152e3e9c 100755
--- a/automation/scripts/qemu-smoke-x86-64.sh
+++ b/automation/scripts/qemu-smoke-x86-64.sh
@@ -21,7 +21,7 @@ esac
 
 rm -f smoke.serial
 set +e
-timeout -k 1 10 \
+timeout -k 1 30 \
 qemu-system-x86_64 -nographic -kernel binaries/xen \
 -initrd xtf/tests/example/$k \
 -append "loglvl=all com1=115200,,8n1 console=com1 noreboot \
-- 
2.24.0


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

[Xen-devel] [xen-4.11-testing test] 144496: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-prev  6 xen-buildfail REGR. vs. 144376
 test-armhf-armhf-libvirt-raw 16 guest-start.2fail REGR. vs. 144376

Tests which did not succeed, but are not blocking:
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass

version targeted for testing:
 xen  239d37e514c93e29d50d71f734b1dc453b2236a6
baseline version:
 xen  

Re: [Xen-devel] [PATCH for-4.13] x86/AMD: unbreak CPU hotplug on AMD systems without RstrFpErrPtrs

[Jan Beulich]

On 29.11.2019 21:01, Igor Druzhinin wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -54,7 +54,7 @@ static unsigned int forced_caps[NCAPINTS];
>  
>  DEFINE_PER_CPU(bool, full_gdt_loaded);
>  
> -void __init setup_clear_cpu_cap(unsigned int cap)
> +void setup_clear_cpu_cap(unsigned int cap)
>  {
>   const uint32_t *dfs;
>   unsigned int i;
> @@ -83,7 +83,7 @@ void __init setup_clear_cpu_cap(unsigned int cap)
>   }
>  }
>  
> -void __init setup_force_cpu_cap(unsigned int cap)
> +void setup_force_cpu_cap(unsigned int cap)
>  {
>   if (__test_and_set_bit(cap, forced_caps))
>   return;

The two functions are deliberately __init, as any call to them
post-init is not going to take system-wide effect. These functions
should really be __init_presmp, if we had something like this. No
use of them on an AP boot path is going to affect the BSP, and
hence will leave the system in an inconsistent state.

Jan

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

Re: [Xen-devel] [PATCH for-4.13] x86: re-order clang no integrated assembler tests

[Jan Beulich]

On 02.12.2019 12:29, Roger Pau Monne wrote:
> The tests to check whether the integrated assembler is capable of
> building Xen should be performed before testing any assembler
> features, or else the feature specific tests would be stale if the
> integrated assembler is disabled afterwards.
> 
> Fixes: ef286f67787a ('x86: move and fix clang .skip check')

Perhaps this change has made the situation worse (and I'm sorry
for the breakage), but the issue was definitely there before.
The change above merely added one check to two already present
ones in the same place.

> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -12,6 +12,30 @@ CFLAGS += '-D__OBJECT_LABEL__=$(subst /,$$,$(subst 
> -,_,$(subst $(BASEDIR)/,,$(CU
>  # Prevent floating-point variables from creeping into Xen.
>  CFLAGS += -msoft-float
>  
> +ifeq ($(clang),y)
> +# Note: Any test which adds -no-integrated-as will cause subsequent tests to
> +# succeed, and not trigger further additions.
> +#
> +# The tests to select whether the integrated assembler is usable need to 
> happen
> +# before testing any assembler features, or else the result of the tests 
> would
> +# be stale if the integrated assembler is not used.
> +
> +# Older clang's built-in assembler doesn't understand .skip with labels:
> +# https://bugs.llvm.org/show_bug.cgi?id=27369
> +$(call as-option-add,CFLAGS,CC,".L0: .L1: .skip (.L1 - .L0)",,\
> + -no-integrated-as)
> +
> +# Check whether clang asm()-s support .include.
> +$(call as-option-add,CFLAGS,CC,".include \"asm/indirect_thunk_asm.h\"",,\
> + -no-integrated-as)
> +
> +# Check whether clang keeps .macro-s between asm()-s:
> +# https://bugs.llvm.org/show_bug.cgi?id=36110
> +$(call as-option-add,CFLAGS,CC,\
> + ".macro FOO;.endm"$$(close); asm volatile 
> $$(open)".macro FOO;.endm",\
> + -no-integrated-as)
> +endif
> +
>  $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
>  $(call cc-option-add,CFLAGS,CC,-Wnested-externs)
>  $(call as-option-add,CFLAGS,CC,"vmcall",-DHAVE_AS_VMX)
> @@ -70,22 +94,3 @@ endif
>  # Set up the assembler include path properly for older toolchains.
>  CFLAGS += -Wa,-I$(BASEDIR)/include
>  
> -ifeq ($(clang),y)
> -# Note: Any test which adds -no-integrated-as will cause subsequent tests to
> -# succeed, and not trigger further additions.
> -
> -# Older clang's built-in assembler doesn't understand .skip with labels:
> -# https://bugs.llvm.org/show_bug.cgi?id=27369
> -$(call as-option-add,CFLAGS,CC,".L0: .L1: .skip (.L1 - .L0)",,\
> - -no-integrated-as)
> -
> -# Check whether clang asm()-s support .include.
> -$(call as-option-add,CFLAGS,CC,".include \"asm/indirect_thunk_asm.h\"",,\
> - -no-integrated-as)
> -
> -# Check whether clang keeps .macro-s between asm()-s:
> -# https://bugs.llvm.org/show_bug.cgi?id=36110
> -$(call as-option-add,CFLAGS,CC,\
> - ".macro FOO;.endm"$$(close); asm volatile 
> $$(open)".macro FOO;.endm",\
> - -no-integrated-as)
> -endif

Furthermore I think this moving around of logic (which imo
would better remain at the bottom of the file, well out of
sight) is only the second best solution to the issue. The
reason I didn't notice the breakage was because I had noticed
what made me create the patch in question only while putting
together a change moving out the majority of the as-option-add
invocations, primarily with the goal of not having the
compiler invoked over and over just to calculate CFLAGS. I
didn't post this change yet simply because I wanted to give it
some more (local) testing.

Another reason to keep this at the bottom of the file is that
other CFLAGS additions wouldn't have happened yet at the
place the checks live now. Since there's one as-option-add
invocation remaining even after my change (the one
establishing HAVE_AS_QUOTED_SYM, not fitting the model used
because of the further option additions), I guess the right
course of action is going to be to move the block back down
again after my change (hopefully) went in, moving the one
remaining as-option-add past it at the same time.

Jan

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

Re: [Xen-devel] [PATCH v3 1/2] xen/xenbus: reference count registered modules

[Jan Beulich]

On 02.12.2019 12:41, Paul Durrant wrote:
> To prevent a PV driver module being removed whilst attached to its other
> end, and hence xenbus calling into potentially invalid text, take a
> reference on the module before calling the probe() method (dropping it if
> unsuccessful) and drop the reference after returning from the remove()
> method.
> 
> Suggested-by: Jan Beulich 
> Signed-off-by: Paul Durrant 

Reviewed-by: Jan Beulich 
with ...

> --- a/drivers/xen/xenbus/xenbus_probe.c
> +++ b/drivers/xen/xenbus/xenbus_probe.c
> @@ -232,9 +232,16 @@ int xenbus_dev_probe(struct device *_dev)
>   return err;
>   }
>  
> + if (!try_module_get(drv->driver.owner)) {
> + dev_warn(>dev, "failed to acquire module reference on 
> '%s'.\n",
> +  drv->driver.name);

... perhaps the full stop dropped here and ...

> + err = -ESRCH;
> + goto fail;
> +}

... (definitely) indentation here changed to use a tab.

Jan

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

Re: [Xen-devel] [PATCH livepatch-build-tools] create-diff-object: Include string sections later

[Sergey Dyasli]

On 03/12/2019 07:57, Pawel Wieczorkiewicz wrote:
> ... when all symbols have their status and include flags processed.
> 
> Processing special sections may include additional symbols. String
> sections (.rodata*) are included iff they are referenced by at least
> one symbol. Thus, in order to decide if string section should be
> included or not, all symbols must be evaluated first.
> 
> Signed-off-by: Pawel Wieczorkiewicz 
> Reported-by: Sergey Dyasli 

Tested-by: Sergey Dyasli 

This fixes creation/loading of my test LP.

--
Thanks,
Sergey

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

Re: [Xen-devel] [PATCH v2] x86 / iommu: set up a scratch page in the quarantine domain

[Jan Beulich]

On 28.11.2019 12:32, Jürgen Groß wrote:
> On 28.11.19 12:17, Jan Beulich wrote:
>> On 27.11.2019 18:11, Paul Durrant wrote:
>>> This patch introduces a new iommu_op to facilitate a per-implementation
>>> quarantine set up, and then further code for x86 implementations
>>> (amd and vtd) to set up a read-only scratch page to serve as the source
>>> for DMA reads whilst a device is assigned to dom_io. DMA writes will
>>> continue to fault as before.
>>>
>>> The reason for doing this is that some hardware may continue to re-try
>>> DMA (despite FLR) in the event of an error, or even BME being cleared, and
>>> will fail to deal with DMA read faults gracefully. Having a scratch page
>>> mapped will allow pending DMA reads to complete and thus such buggy
>>> hardware will eventually be quiesced.
>>>
>>> NOTE: These modifications are restricted to x86 implementations only as
>>>the buggy h/w I am aware of is only used with Xen in an x86
>>>environment. ARM may require similar code but, since I am not
>>>aware of the need, this patch does not modify any ARM implementation.
>>>
>>> Signed-off-by: Paul Durrant 
>>
>> Reviewed-by: Jan Beulich 
>>
>>> There is still the open question of whether use of a scratch page ought
>>> to be gated on something, either are run-time or compile-time.
>>
>> I have no clear opinion either way here. The workaround seems low
>> overhead enough that there may not be a need to have an admin (or
>> build time) control for this.
>>
>> As to 4.13: The quarantining as a whole is pretty fresh. While it
>> has been backported to security maintained trees, I'd still consider
>> it a new feature in 4.13, and hence this workaround at least eligible
>> for consideration.
> 
> I agree.
> 
> Release-acked-by: Juergen Gross 

I notice this has been committed meanwhile. I had specifically not
done so due to the still missing VT-d ack, seeing that this wasn't
an entirely "trivial" change.

Jan

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

Re: [Xen-devel] [PATCH for-4.13] clang: do not enable live-patching support

[George Dunlap]

> On Dec 2, 2019, at 5:01 PM, Konrad Rzeszutek Wilk  
> wrote:
> 
> On Mon, Dec 02, 2019 at 03:55:04PM +, Andrew Cooper wrote:
>> On 02/12/2019 15:53, Konrad Rzeszutek Wilk wrote:
> I plan to release ack the patch in case the missing maintainer's acks
> are not coming in too late.
 I think Andy's objection was that there has been zero testing of
 livepatching on gcc.  Maybe we can find someone to do a smoke-test.
>>> As in integrate livepatch-build tools in osstest smoke-tests?
>>> Because the livepatch test cases are in osstest, unless something went awry?
>> 
>> The sum total of livepatch testing in OSSTest is using the hand-coded
>> ELF objects from the tests/ directory.
>> 
>> This is perhaps ok for the basic mechanism, but its not representative
>> of actually building real livepatches using livepatch build tools.
> 
> True. But it tests the _hypervisor_ livepatch code.
> 
> I am thinking that this discussion about "oh, but livepatch-build tools don't 
> work b/c"
> is well  sucks but should never block an release as the core
> livepatch functionality is OK.

I think a parallel is if Xen doesn’t build with a particular version of the 
compiler, or can’t build on a particular distro for some reason.  We should 
certainly *try* to make things work with other projects, but if the issue is 
clearly with the other project, we shouldn’t have to block to wait for that 
other project to get things sorted out.

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

Re: [Xen-devel] Xen 4.14 and future work

[Durrant, Paul]

> -Original Message-
> From: Xen-devel  On Behalf Of
> Andrew Cooper
> Sent: 02 December 2019 19:52
> To: Xen-devel List 
> Subject: [Xen-devel] Xen 4.14 and future work
> 
> Hello,
> 
> Now that 4.13 is on its way out of the door, it is time to look to
> ongoing work.
> 
> We have a large backlog of speculation-related work.  For one, we still
> don't virtualise MSR_ARCH_CAPS for guests, or use eIBRS ourselves in
> Xen.  Therefore, while Xen does function on Cascade Lake, support is
> distinctly suboptimal.
> 
> Similarly, AMD systems frequently fill /var/log with:
> 
> (XEN) emul-priv-op.c:1113:d0v13 Domain attempted WRMSR c0011020 from
> 0x00064040 to 0x000640400400
> 
> which is an interaction Linux's prctl() to disable memory disambiguation
> on a per-process basis, Xen's write/discard behaviour for MSRs, and the
> long-overdue series to properly virtualise SSBD support on AMD
> hardware.  AMD Rome hardware, like Cascade Lake, has certain hardware
> speculative mitigation features which need virtualising for guests to
> make use of.
> 

I assume this would addressed by the proposed cpuid/msr policy work? I think it 
is quite vital for Xen that we are able to migrate guests across pools of 
heterogeneous h/w and therefore I'd like to see this done in 4.14 if possible.

> 
> Similarly, there is plenty more work to do with core-aware scheduling,
> and from my side of things, sane guest topology.  This will eventually
> unblock one of the factors on the hard 128 vcpu limit for HVM guests.
> 
> 
> Another big area is the stability of toolstack hypercalls.  This is a
> crippling pain point for distros and upgradeability of systems, and
> there is frankly no justifiable reason for the way we currently do
> things  The real reason is inertia from back in the days when Xen.git
> (bitkeeper as it was back then) contained a fork of every relevant
> pieces of software, but this a long-since obsolete model, but still
> causing us pain.  I will follow up with a proposal in due course, but as
> a oneliner, it will build on the dm_op() API model.

This is also fairly vital for the work on live update of Xen (as discussed at 
the last dev summit). Any instability in the tools ABI will compromise 
hypervisor update and fixing such issues on an ad-hoc basis as they arise is 
not really a desirable prospect.

> 
> Likely included within this is making the domain/vcpu destroy paths
> idempotent so we can fix a load of NULL pointer dereferences in Xen
> caused by XEN_DOMCTL_max_vcpus not being part of XEN_DOMCTL_createdomain.
> 
> Other work in this area involves adding X86_EMUL_{VIRIDIAN,NESTED_VIRT}
> to replace their existing problematic enablement interfaces.
> 

I think this should include deprecation of HVMOP_get/set_param as far as is 
possible (i.e. tools use)...

> 
> A start needs to be made on a total rethink of the HVM ABI.  This has
> come up repeatedly at previous dev summits, and is in desperate need of
> having some work started on it.
> 

...and completely in any new ABI.

I wonder to what extent we can provide a guest-side compat layer here, 
otherwise it would be hard to get traction I think.
There was an interesting talk at KVM Forum (https://sched.co/Tmuy) on dealing 
with emulation inside guest context by essentially re-injecting the VMEXITs 
back into the guest for pseudo-SMM code (loaded as part of the firmware blob) 
to deal with. I could imagine potentially using such a mechanism to have a 
'legacy' hypercall translated to the new ABI, which would allow older guests to 
be supported unmodified (albeit with a performance penalty). Such a mechanism 
may also be useful as an alternative way of dealing with some of the emulation 
dealt with directly in Xen at the moment, to reduce the hypervisor attack 
surface e.g. stdvga caching, hpet, rtc... perhaps.

Cheers,

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

[Xen-devel] [xen-unstable test] 144497: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10   fail  like 144484
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 144484
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 144484
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 144484
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 144484
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 144484
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 144484
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 144484
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 144484
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 144484
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 144484
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass

version targeted for testing:
 xen  f19af2f1138e89bdf05e8cfcab26a190e3771c4b
baseline version:
 xen  0022387cefc6ced6d2062ffaee7285405aa4d444

Last test of basis   144484  2019-12-02 07:49:13 Z1 days
Testing same since   144497  2019-12-02 18:37:15 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Roger Pau Monne 
  Roger Pau Monné 

jobs:
 build-amd64-xsm  pass
 

Re: [Xen-devel] [PATCH V3 2/2] x86/mm: Make use of the default access param from xc_altp2m_create_view

[Jan Beulich]

On 02.12.2019 13:39, Alexandru Stefan ISAILA wrote:
> On 29.11.2019 13:41, Jan Beulich wrote:
>> On 21.11.2019 16:02, Alexandru Stefan ISAILA wrote:
>>> Changes since V2:
>>> - Drop static from xenmem_access_to_p2m_access() and declare it
>>> in mem_access.h
>>> - Use xenmem_access_to_p2m_access() in p2m_init_next_altp2m()
>>> - Pull out the p2m specifics from p2m_init_altp2m_ept().
>>
>> I guess this last point would better have been a prereq patch,
>> but anyway.
> 
> Should I have a prereq patch for this in the next version?

Well, I'm not the maintainer of this code, but if I was, I would
much prefer you doing so.

Jan

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

Re: [Xen-devel] [PATCH V3 1/2] x86/altp2m: Add hypercall to set a range of sve bits

[Jan Beulich]

On 02.12.2019 15:40, Alexandru Stefan ISAILA wrote:
> On 29.11.2019 13:31, Jan Beulich wrote:
>> On 21.11.2019 16:02, Alexandru Stefan ISAILA wrote:
>>> @@ -4711,6 +4712,18 @@ static int do_altp2m_op(
>>>   }
>>>   break;
>>>   
>>> +case HVMOP_altp2m_set_suppress_ve_multi:
>>> +if ( a.u.suppress_ve_multi.pad1 || !a.u.suppress_ve_multi.pad2 )
>>> +rc = -EINVAL;
>>> +else
>>> +{
>>> +rc = p2m_set_suppress_ve_multi(d, _ve_multi);
>>> +
>>> +if ( __copy_to_guest(arg, , 1) )
>>> +rc = -EFAULT;
>>
>> Do you really want to replace a possible prior error here?
> 
> I thought about this and the only error that can be replaced here is 
> EINVAL. A error on __copy_to_guest has a grater importance if this fails.

I'm afraid I don't understand the reference to EINVAL.

As to "greater importance" - I'm not sure I follow. Please take a
look at e.g. do_event_channel_op(), but there are numerous other
examples throughout the tree. The pattern there is a common on,
and what you do here doesn't match that.

>>> --- a/xen/arch/x86/mm/p2m.c
>>> +++ b/xen/arch/x86/mm/p2m.c
>>> @@ -3059,6 +3059,66 @@ out:
>>>   return rc;
>>>   }
>>>   
>>> +/*
>>> + * Set/clear the #VE suppress bit for multiple pages.  Only available on 
>>> VMX.
>>> + */
>>> +int p2m_set_suppress_ve_multi(struct domain *d,
>>> +  struct xen_hvm_altp2m_suppress_ve_multi *sve)
>>> +{
>>> +struct p2m_domain *host_p2m = p2m_get_hostp2m(d);
>>> +struct p2m_domain *ap2m = NULL;
>>> +struct p2m_domain *p2m;
>>> +uint64_t start = sve->opaque ?: sve->first_gfn;
>>> +int rc = 0;
>>> +
>>> +if ( sve->view > 0 )
>>> +{
>>> +if ( sve->view >= MAX_ALTP2M ||
>>> + d->arch.altp2m_eptp[sve->view] == mfn_x(INVALID_MFN) )
>>> +return -EINVAL;
>>> +
>>> +p2m = ap2m = d->arch.altp2m_p2m[sve->view];
>>
>> These want array_index_nospec() or alike used (and the pre-existing
>> similar uses taken care of in a separate patch).
> 
> Sure, this can change to p2m = ap2m = 
> d->arch.altp2m_p2m[array_index_nospec(sve->view, MAX_ALTP2M).
> 
> But what preexisting uses are you talking about? All the places where 
> d->arch.altp2m_p2m[idx] is used? If so, there will be a handful of 
> changes in that new patch.

Indeed, all the places where a caller (i.e. potentially guest)
provided value gets used as array index.

>>
>>> +}
>>> +else
>>> +p2m = host_p2m;
>>
>> Each time I see yet another instance of this pattern appear, I
>> wonder why this is. Use (or not) of initializers should be
>> consistent at least within individual functions. I.e. either
>> you initialize both ap2m and p2m in their declaration, or you
>> do so for neither of them.
> 
> The only reason I can see for this pattern is that p2m will be assigned 
> a value but ap2m can never get a value. But I agree with you and I will 
> have them both initialized with NULL.

Why NULL? This isn't what I had in mind. Quite clearly you would
initialize p2m from host_p2m, eliminating the need for the "else"
altogether.

>>> +while ( sve->last_gfn >= start )
>>
>> There are no checks on ->last_gfn, ->first_gfn, or ->opaque.
>> At the very least a bogus ->opaque should result in an error.
>> I wonder though why you don't simply update ->first_gfn,
>> omitting the need for ->opaque. All this would need is a
>> comment in the public header clarifying that callers should
>> expect the values to change.
> 
> I was following the pattern from range_share() after Tamas requested the 
> opaque field. I agree that it would be simpler to have ->first_gfn 
> update and I can change to that in the next version.
> 
>> Furthermore I think it would be helpful to bail on entirely
>> out of range ->first_gfn. This being a 64-bit field, only
>> 40 of the bits are actually usable from an architecture pov
>> (in reality it may be even less). Otherwise you potentially
>> invoke p2m_ept_set_entry() perhaps trillions of times just
>> for it to return -EINVAL from its first if().
> 
> Do you mean to check ->first_gfn(that will be updated in the next 
> version) against domain_get_maximum_gpfn() and bail after that range?

This may be one possibility (depending on what the inteneded
behavior for GFNs above this value is). Another would be to
simply judge from the guest's CPUID setting for the number of
physical address bits.

Jan

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

Re: [Xen-devel] bug: unable to LZ4 decompress ub1910 installer kernel when launching domU

[Jan Beulich]

On 01.12.2019 18:47, Jeremi Piotrowski wrote:
> On Thu, Oct 24, 2019 at 10:12:19AM +0200, Jan Beulich wrote:
>> On 23.10.2019 22:33, Pry Mar wrote:
>>> Hello xen-devel,
>>>
>>> https://paste.debian.net/plain/1109374
>>>
>>> shows my traces from a healthy CentOS 8, xen-4.12.1 dom0 when trying
>>> to launch a pv install of the newly released ub1910. The source is a
>>> block-attached ISO and the kernel/ramdisk was copied off locally.
>>
>> Would you please increase verbosity (xl -vvv create ...) such that we
>> can see what exactly the decompression code doesn't like about this
>> kernel image?
> 
> I stumbled across the same issue, below is the xl - create output.
> 
> Parsing config from ubuntu.cfg
> libxl: debug: libxl_create.c:1693:do_domain_create: Domain 0:ao 
> 0x55a598e77190: create: how=(nil) callback=(nil) poller=0x55a598e74040
> libxl: debug: libxl_device.c:397:libxl__device_disk_set_backend: Disk 
> vdev=xvda spec.backend=unknown
> libxl: debug: libxl_device.c:358:disk_try_backend: Disk vdev=xvda, backend 
> phy unsuitable due to format qcow2
> libxl: debug: libxl_device.c:431:libxl__device_disk_set_backend: Disk 
> vdev=xvda, using backend qdisk
> libxl: debug: libxl_create.c:1018:initiate_domain_create: Domain 11:running 
> bootloader
> libxl: debug: libxl_bootloader.c:334:libxl__bootloader_run: Domain 11:no 
> bootloader configured, using user supplied kernel
> libxl: debug: libxl_event.c:689:libxl__ev_xswatch_deregister: watch 
> w=0x55a598e827a8: deregister unregistered
> domainbuilder: detail: xc_dom_allocate: cmdline="", features=""
> libxl: debug: libxl_dom.c:799:libxl__build_pv: pv kernel mapped 0 path 
> /tank/xenscratch/ubuntu/vmlinuz-5.3.0-23-generic
> domainbuilder: detail: xc_dom_kernel_file: 
> filename="/tank/xenscratch/ubuntu/vmlinuz-5.3.0-23-generic"
> domainbuilder: detail: xc_dom_malloc_filemap: 11132 kB
> domainbuilder: detail: xc_dom_boot_xen_init: ver 4.12, caps xen-3.0-x86_64 
> xen-3.0-x86_32p 
> domainbuilder: detail: xc_dom_parse_image: called
> domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... 
> domainbuilder: detail: loader probe failed
> domainbuilder: detail: xc_dom_find_loader: trying HVM-generic loader ... 
> domainbuilder: detail: loader probe failed
> domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... 
> domainbuilder: detail: LZ4 decompression error: decoding failed

This suggests that the decoding logic didn't like the input. Since as
per the other mail manual decompression works, this will likely need
debugging by someone able to repro.

Jan

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