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

flight 118382 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118382/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 118363 Tests which

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

flight 118341 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/118341/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 118287 Tests which did

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

flight 118381 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118381/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 118363 Tests which

[Xen-devel] [xen-unstable-smoke bisection] complete build-arm64-xsm

branch xen-unstable-smoke xenbranch xen-unstable-smoke job build-arm64-xsm testid xen-build Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug

[Xen-devel] [xen-4.7-testing test] 118337: tolerable FAIL - PUSHED

flight 118337 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/118337/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-5 49 xtf/test-hvm64-lbr-tsx-vmentry fail like 118221 test-xtf-amd64-amd64-3 49

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

flight 118376 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118376/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 118363 Tests which

Re: [Xen-devel] [PATCH v10 09/11] x86/ctxt: Issue a speculation barrier between vcpu contexts

> On 25/01/18 16:09, Andrew Cooper wrote: > > On 25/01/18 15:57, Jan Beulich wrote: > > > > > > > > > For the record, the overwhelming majority of calls to > > > __sync_local_execstate() being responsible for the behavior > > > come from invalidate_interrupt(), which suggests to me that > > >

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

flight 118372 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118372/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 118363 Tests which

Re: [Xen-devel] GPU passthrough on ARM

On 01/26/2018 10:13 AM, Oleksandr Tyshchenko wrote: Hi, Martin On Fri, Jan 26, 2018 at 8:05 PM, Oleksandr Tyshchenko wrote: On Fri, Jan 26, 2018 at 3:49 PM, Julien Grall wrote: Hi, I am CCing Oleksandr. He knows better than me this platform.

Re: [Xen-devel] [PATCH RFC] ocaml: Fix compile with ocaml 4.06, use unsafe strings

On Fri, 26 Jan 2018, at 23:16, Christian Lindig wrote: > using the -unsafe-string option (introduced in OCaml 4.02) to keep > strings mutable to avoid code changes is not going to work in the long > run. Okay, NAK my unsafe-string patch. On 26. Jan 2018, at 09:09, M A Young

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

flight 118366 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118366/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 118363 Tests which

[Xen-devel] [xen-4.8-testing test] 118329: regressions - FAIL

flight 118329 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/118329/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-3 49 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 118170

Re: [Xen-devel] [PATCH] xen/arm: Fix platform name for Xilinx ZynqMP

Hi, > I guess you mean: xilinx_zynqmp, ... ? Sorry, I would fix and repost it. Thanks for looking. -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] tools/libxl: Fix assertion failure when trying to build a nested-virt PVH domain

On Fri, Jan 26, 2018 at 07:23:52PM +, Andrew Cooper wrote: > On 26/01/18 19:11, Ian Jackson wrote: > > Andrew Cooper writes ("[PATCH] tools/libxl: Fix assertion failure when > > trying to build a nested-virt PVH domain"): > >> xl: libxl.c:339: libxl_defbool_val: Assertion > >>

[Xen-devel] [PATCH] xen: Fix XSM build after dropping XEN_DOMCTL_getmemlist

c/s 94450e36bfbb removed XEN_DOMCTL_getmemlist entirely, but missed adjusting the XSM side of things. As far as I can tell, 'pagelist' wasn't even offered to dom0 in default policy. Also, drop the stale struct xen_domctl_getmemlist which was missed from the same changeset. Signed-off-by: Andrew

Re: [Xen-devel] [PATCH] tools/libxl: Fix assertion failure when trying to build a nested-virt PVH domain

On 26/01/18 19:11, Ian Jackson wrote: > Andrew Cooper writes ("[PATCH] tools/libxl: Fix assertion failure when trying > to build a nested-virt PVH domain"): >> xl: libxl.c:339: libxl_defbool_val: Assertion >> `!libxl_defbool_is_default(db)' failed. >> >> This happens because

Re: [Xen-devel] [PATCH] tools/libxl: Fix assertion failure when trying to build a nested-virt PVH domain

Andrew Cooper writes ("[PATCH] tools/libxl: Fix assertion failure when trying to build a nested-virt PVH domain"): > xl: libxl.c:339: libxl_defbool_val: Assertion `!libxl_defbool_is_default(db)' > failed. > > This happens because initiate_domain_create() checks for type != HVM, then > pokes at

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

flight 118363 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118363/ 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

Re: [Xen-devel] [PATCH] x86: move declaration of the exception_table to C

On 26/01/18 19:02, Roger Pau Monné wrote: > On Fri, Jan 26, 2018 at 05:46:23PM +, Andrew Cooper wrote: >> On 26/01/18 17:37, Roger Pau Monne wrote: >>> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c >>> index a3e8f0c9b9..be95baafe1 100644 >>> --- a/xen/arch/x86/traps.c >>> +++

[Xen-devel] [PATCH] tools/libxl: Fix assertion failure when trying to build a nested-virt PVH domain

xl: libxl.c:339: libxl_defbool_val: Assertion `!libxl_defbool_is_default(db)' failed. This happens because initiate_domain_create() checks for type != HVM, then pokes at the hvm union. Check for == HVM instead so the union access is correctly guarded. Signed-off-by: Andrew Cooper

Re: [Xen-devel] [PATCH 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c

Hi, On 26.01.18 20:15, Julien Grall wrote: Hi, On 26/01/18 18:09, Volodymyr Babchuk wrote: On 24.01.18 20:34, Julien Grall wrote: -    case PSCI_0_2_FN32(AFFINITY_INFO): -    case PSCI_0_2_FN64(AFFINITY_INFO): +    switch ( fid )   { -    register_t taff = PSCI_ARG(regs, 1); -   

Re: [Xen-devel] [PATCH 2/3] xen/arm: vsmc: Don't implement function ID that doesn't exist

Hi, On 26/01/18 18:12, Volodymyr Babchuk wrote: On 26.01.18 20:07, Julien Grall wrote: On 26/01/18 18:03, Volodymyr Babchuk wrote: diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h index f543dea0bb..303517459f 100644 --- a/xen/include/asm-arm/smccc.h +++

Re: [Xen-devel] [PATCH 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c

Hi, On 26/01/18 18:09, Volodymyr Babchuk wrote: On 24.01.18 20:34, Julien Grall wrote: -    case PSCI_0_2_FN32(AFFINITY_INFO): -    case PSCI_0_2_FN64(AFFINITY_INFO): +    switch ( fid )   { -    register_t taff = PSCI_ARG(regs, 1); -    uint32_t laff = PSCI_ARG32(regs, 2); - - 

Re: [Xen-devel] GPU passthrough on ARM

Hi, Martin On Fri, Jan 26, 2018 at 8:05 PM, Oleksandr Tyshchenko wrote: > On Fri, Jan 26, 2018 at 3:49 PM, Julien Grall wrote: >> Hi, >> >> I am CCing Oleksandr. He knows better than me this platform. > > Hi, Julien. > > OK, thank you, I will try to

Re: [Xen-devel] [PATCH 2/3] xen/arm: vsmc: Don't implement function ID that doesn't exist

On 26.01.18 20:07, Julien Grall wrote: On 26/01/18 18:03, Volodymyr Babchuk wrote: diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h index f543dea0bb..303517459f 100644 --- a/xen/include/asm-arm/smccc.h +++ b/xen/include/asm-arm/smccc.h @@ -82,9 +82,23 @@ static inline

Re: [Xen-devel] [PATCH v2 1/2] x86/acpi: add retrieval function for rsdp address

On Thu, Jan 25, 2018 at 4:36 PM, Juergen Gross wrote: > Add a function to get the address of the RSDP table. Per default use a > __weak annotated function being a nop. The problem with weak functions that we can't have more than one implementation per kernel while we would like

Re: [Xen-devel] GPU passthrough on ARM

On Fri, Jan 26, 2018 at 3:49 PM, Julien Grall wrote: > Hi, > > I am CCing Oleksandr. He knows better than me this platform. Hi, Julien. OK, thank you, I will try to provide some pointers. > > Cheers, > > On 26/01/18 00:29, Martin Kelly wrote: >> >> On 01/25/2018 04:17

Re: [Xen-devel] [PATCH 2/3] xen/arm: vsmc: Don't implement function ID that doesn't exist

On 24.01.18 20:34, Julien Grall wrote: The current implementation of SMCCC relies on the fact only function number (bits [15:0]) is enough to identify what to implement. However, PSCI call are only available in the range 0x8400-0x841F and 0xC400-0xC41F. Furthermore, not all

Re: [Xen-devel] [PATCH] x86: move declaration of the exception_table to C

On 26/01/18 17:37, Roger Pau Monne wrote: > This makes the code cleaner because there's no need to declare the > exception_table in assembly, and also fixes the following error when > using clang's integrated assembler: > > entry.S:834:15: error: unexpected token in '.rept' directive >

[Xen-devel] [PATCH] x86: move declaration of the exception_table to C

This makes the code cleaner because there's no need to declare the exception_table in assembly, and also fixes the following error when using clang's integrated assembler: entry.S:834:15: error: unexpected token in '.rept' directive .rept 32 - ((. - exception_table) / 8) ^

Re: [Xen-devel] [PATCHv3] xen: Add EFI_LOAD_OPTION support

On Fri, Jan 26, 2018 at 5:46 AM, Jan Beulich wrote: On 23.01.18 at 01:21, wrote: >> @@ -88,6 +88,16 @@ typedef struct _EFI_APPLE_PROPERTIES { >> EFI_APPLE_PROPERTIES_GETALL GetAll; >> } EFI_APPLE_PROPERTIES; >> >> +typedef struct

Re: [Xen-devel] [PATCH] xen, x86: turn the selftests ASSERT into a warning

On 26/01/18 17:19, Stefano Stabellini wrote: > On selftests failure, print a very visible warning instead of crashing > over an ASSERT. > > Signed-off-by: Stefano Stabellini > > diff --git a/xen/arch/x86/extable.c b/xen/arch/x86/extable.c > index 72f30d9..9b834a2 100644 >

Re: [Xen-devel] [PATCH] xen,x86: introduce tcg_errata

On Fri, 26 Jan 2018, Andrew Cooper wrote: > On 26/01/18 11:06, Jan Beulich wrote: > On 25.01.18 at 21:04, wrote: > >> On 25/01/18 19:43, Stefano Stabellini wrote: > >>> On Thu, 25 Jan 2018, Andrew Cooper wrote: > On 25/01/18 18:37, Stefano Stabellini wrote: >

Re: [Xen-devel] [PATCH] xen/arm: Fix platform name for Xilinx ZynqMP

Hi, (CC:ing Edgar) On 25/01/18 15:03, Amit Singh Tomar wrote: > This seems to be copy/paste error.This patch simply > replace string xgene_storm with xilink_zymp for xilink > platform. > > Signed-off-by: Amit Singh Tomar > --- > xen/arch/arm/platforms/xilinx-zynqmp.c |

Re: [Xen-devel] [PATCH] x86/boot: Make the "Building Dom0" messages consistent

>>> On 26.01.18 at 17:28, wrote: > On 26/01/18 16:20, Roger Pau Monné wrote: >> On Fri, Jan 26, 2018 at 04:00:03PM +, Andrew Cooper wrote: >>> --- a/xen/arch/x86/pv/dom0_build.c >>> +++ b/xen/arch/x86/pv/dom0_build.c >>> @@ -328,7 +328,7 @@ int __init

Re: [Xen-devel] [PATCH] xen/pvshim: fix GNTTABOP_query_size hypercall forwarding with SMAP

>>> On 26.01.18 at 17:28, wrote: > On Fri, Jan 26, 2018 at 04:22:41PM +, Roger Pau Monné wrote: >> On Fri, Jan 26, 2018 at 03:52:38PM +, Wei Liu wrote: >> > On Fri, Jan 26, 2018 at 03:29:10PM +, Roger Pau Monne wrote: >> > > --- a/xen/arch/x86/pv/shim.c >> > > +++

[Xen-devel] [linux-linus test] 118324: tolerable FAIL - PUSHED

flight 118324 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/118324/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 118250 test-armhf-armhf-libvirt 14

Re: [Xen-devel] Xen Introspection, KPTI, and CR3 bit 63 leads to guest VMENTRY failures during introspection

On 01/26/2018 06:17 PM, Bitweasil . wrote: > The proposed changes would only have an impact if CR3 exiting is > enabled, which implies a pair of world switches and other code execution > in a different region of memory and with different page tables anyway. > > Under normal operation, CR3 exiting

Re: [Xen-devel] [PATCH 1/3] xen/arm: vpsci: Removing dummy MIGRATE and MIGRATE_INFO_UP_CPU

Hi, On 24/01/18 18:34, Julien Grall wrote: The PSCI call MIGRATE and MIGRATE_INFO_UP_CPU are optional and implemented as just returning PSCI_NOT_SUPPORTED (aka UNKNOWN_FUNCTION for SMCCC). The new SMCCC framework is able to deal with unimplemented function and return the proper error code. So

Re: [Xen-devel] [PATCH] x86/boot: Make the "Building Dom0" messages consistent

On 26/01/18 16:20, Roger Pau Monné wrote: > On Fri, Jan 26, 2018 at 04:00:03PM +, Andrew Cooper wrote: >> Switch the PV message to match the wording of the PVH side, use the same >> number of ***'s, explicitly identify PV vs PVH, and set the log level at >> INFO. >> >> Signed-off-by: Andrew

Re: [Xen-devel] [PATCH] xen/pvshim: fix GNTTABOP_query_size hypercall forwarding with SMAP

On Fri, Jan 26, 2018 at 04:22:41PM +, Roger Pau Monné wrote: > On Fri, Jan 26, 2018 at 03:52:38PM +, Wei Liu wrote: > > On Fri, Jan 26, 2018 at 03:29:10PM +, Roger Pau Monne wrote: > > > Disable SMAP in the shim before bouncing the hypercall, or else L0 > > > will fail to get the

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

On 24/01/18 17:55, Mirela Simonovic wrote: Hi Julien, Stefano, Hi Mirela, Thank you very much for the feedback! On 01/11/2018 03:00 PM, Julien Grall wrote: Hi Mirela, Thank you for the sending the design document. The general design looks good to me. I have some comments below, but

Re: [Xen-devel] [PATCH] x86/boot: Make the "Building Dom0" messages consistent

On Fri, Jan 26, 2018 at 04:00:03PM +, Andrew Cooper wrote: > Switch the PV message to match the wording of the PVH side, use the same > number of ***'s, explicitly identify PV vs PVH, and set the log level at INFO. > > Signed-off-by: Andrew Cooper Reviewed-by: Wei

[Xen-devel] [PATCH] x86/boot: Make the "Building Dom0" messages consistent

Switch the PV message to match the wording of the PVH side, use the same number of ***'s, explicitly identify PV vs PVH, and set the log level at INFO. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau

Re: [Xen-devel] [PATCH] xen/pvshim: fix GNTTABOP_query_size hypercall forwarding with SMAP

On Fri, Jan 26, 2018 at 03:29:10PM +, Roger Pau Monne wrote: > Disable SMAP in the shim before bouncing the hypercall, or else L0 > will fail to get the hypercall buffer. > > Signed-off-by: Roger Pau Monné > Reported-by: Fatih Acar > --- > Cc: Jan

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

Hi Edgar, On 25/01/18 14:15, Edgar E. Iglesias wrote: On Wed, Jan 24, 2018 at 07:04:35PM +0100, Mirela Simonovic wrote: Hi Oleksandr, Edgar, Thanks, you're right. On 01/23/2018 12:58 PM, Edgar E. Iglesias wrote: On Tue, Jan 23, 2018 at 01:52:50PM +0200, Oleksandr Tyshchenko wrote: Hi

Re: [Xen-devel] [PATCH] xen/pvshim: fix GNTTABOP_query_size hypercall forwarding with SMAP

On 26/01/18 15:29, Roger Pau Monne wrote: > Disable SMAP in the shim before bouncing the hypercall, or else L0 > will fail to get the hypercall buffer. > > Signed-off-by: Roger Pau Monné > Reported-by: Fatih Acar Reviewed-by: Andrew Cooper

[Xen-devel] [PATCH] xen/pvshim: fix GNTTABOP_query_size hypercall forwarding with SMAP

Disable SMAP in the shim before bouncing the hypercall, or else L0 will fail to get the hypercall buffer. Signed-off-by: Roger Pau Monné Reported-by: Fatih Acar --- Cc: Jan Beulich Cc: Andrew Cooper Cc:

Re: [Xen-devel] [PATCH 2/2] xen: Drop DOMCTL_getmemlist and xc_get_pfn_list()

On Fri, Jan 19, 2018 at 07:19:03PM +, Andrew Cooper wrote: > c/s 4ddf474e2 "tools/xen-mceinj: Pass in GPA when injecting through > MSR_MCI_ADDR" removed the remaining user of hypercall. > > It has been listed as broken, deprecated and wont-fix since XSA-74, so take > this opportunity to

Re: [Xen-devel] [PATCH] xen,x86: introduce tcg_errata

On 26/01/18 11:06, Jan Beulich wrote: On 25.01.18 at 21:04, wrote: >> On 25/01/18 19:43, Stefano Stabellini wrote: >>> On Thu, 25 Jan 2018, Andrew Cooper wrote: On 25/01/18 18:37, Stefano Stabellini wrote: > The TCG emulator in QEMU is not good enough to

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

flight 118359 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118359/ 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

Re: [Xen-devel] [PATCH] x86/hvm: fix domain crash when CR3 has the noflush bit set

On 26/01/18 10:58, Jan Beulich wrote: On 26.01.18 at 11:49, wrote: >> On 01/26/2018 12:27 PM, Jan Beulich wrote: >> On 26.01.18 at 10:39, wrote: --- a/xen/arch/x86/hvm/monitor.c +++ b/xen/arch/x86/hvm/monitor.c @@

Re: [Xen-devel] [PATCH RFC] ocaml: Fix compile with ocaml 4.06, use unsafe strings

> On 26. Jan 2018, at 12:00, Wei Liu wrote: > >> >> Reviewed-by: Christian Lindig >> > > Taking the above into consideration, does this tag still stand? Thanks for the clarification. My tag still stands as the code in the patch is IMHO

[Xen-devel] [PATCH 0/3] Improvements to decode_register()

Andrew Cooper (3): x86/emul: Optimise decode_register() somewhat x86/hvm: Improvements to external users of decode_register() x86/emul: Improvements to internal users of decode_register() xen/arch/x86/hvm/hvm.c | 17 +--- xen/arch/x86/hvm/vmx/vvmx.c| 16 +---

[Xen-devel] [PATCH 3/3] x86/emul: Improvements to internal users of decode_register()

Most users of decode_register() can be replaced with decode_gpr() right away. For the few sites which do care about possibly using the highbyte encoding, rename decode_register() to decode_high_gpr() and make it prototype match decode_gpr(). Signed-off-by: Andrew Cooper

[Xen-devel] [PATCH 1/3] x86/emul: Optimise decode_register() somewhat

The positions of GPRs inside struct cpu_user_regs doesn't follow any particular order, so as compiled, decode_register() becomes a jump table to 16 blocks which calculate the appropriate offset, at a total of 207 bytes. Instead, pre-compute the offsets at build time and use pointer arithmetic to

Re: [Xen-devel] [PATCHv3] xen: Add EFI_LOAD_OPTION support

>>> On 23.01.18 at 01:21, wrote: > @@ -88,6 +88,16 @@ typedef struct _EFI_APPLE_PROPERTIES { > EFI_APPLE_PROPERTIES_GETALL GetAll; > } EFI_APPLE_PROPERTIES; > > +typedef struct _EFI_LOAD_OPTION { > +UINT32 Attributes; > +UINT16 FilePathListLength; > +

Re: [Xen-devel] [PATCH v11 7/11] x86/entry: Avoid using alternatives in NMI/#MC paths

On 26/01/18 12:23, Jan Beulich wrote: On 25.01.18 at 18:21, wrote: >> This patch is deliberately arranged to be easy to revert if/when alternatives >> patching becomes NMI/#MC safe. >> >> For safety, there must be a dispatch serialising instruction in (what is >>

Re: [Xen-devel] [PATCH v11 7/11] x86/entry: Avoid using alternatives in NMI/#MC paths

>>> On 25.01.18 at 18:21, wrote: > This patch is deliberately arranged to be easy to revert if/when alternatives > patching becomes NMI/#MC safe. > > For safety, there must be a dispatch serialising instruction in (what is > logically) DO_SPEC_CTRL_ENTRY so that, in

Re: [Xen-devel] [PATCH v11 6/11] x86/entry: Organise the clobbering of the RSB/RAS on entry to Xen

>>> On 25.01.18 at 17:54, wrote: > ret instructions are speculated directly to values recorded in the Return > Stack Buffer/Return Address Stack, as there is no uncertainty in well-formed > code. Guests can take advantage of this in two ways: > > 1) If they can find

Re: [Xen-devel] [PATCH] xen: fix xsm build

>>> On 26.01.18 at 12:45, wrote: > On Thu, Jan 25, 2018 at 01:14:24PM +, Wei Liu wrote: >> Commit e8d461497d9 renamed gcov_op to coverage_op but forgot to change >> XSM handles. >> >> Signed-off-by: Wei Liu > > Osstest's ARM build is blocked by

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

In case we can detect single-threaded guest processes (by checking whether we can account for all root page table uses locally on the vCPU that's running), there's no point in issuing a sync IPI upon an L4 entry update, as no other vCPU of the guest will have that page table loaded.

Re: [Xen-devel] [PATCH RFC] ocaml: Fix compile with ocaml 4.06, use unsafe strings

On Fri, Jan 26, 2018 at 11:47:34AM +, Christian Lindig wrote: > > > > On 26. Jan 2018, at 11:43, Wei Liu wrote: > > > > On Fri, Jan 26, 2018 at 09:29:20AM +, Christian Lindig wrote: > >> > >> > >>> On 26. Jan 2018, at 09:09, M A Young

Re: [Xen-devel] [PATCH RFC] ocaml: Fix compile with ocaml 4.06, use unsafe strings

> On 26. Jan 2018, at 11:43, Wei Liu wrote: > > On Fri, Jan 26, 2018 at 09:29:20AM +, Christian Lindig wrote: >> >> >>> On 26. Jan 2018, at 09:09, M A Young wrote: >>> >>> On Fri, 26 Jan 2018, John Thomson wrote: >>> Use autoconf to

Re: [Xen-devel] [PATCH RFC] ocaml: Fix compile with ocaml 4.06, use unsafe strings

On 26/01/18 11:43, Wei Liu wrote: > On Fri, Jan 26, 2018 at 09:29:20AM +, Christian Lindig wrote: >> >>> On 26. Jan 2018, at 09:09, M A Young wrote: >>> >>> On Fri, 26 Jan 2018, John Thomson wrote: >>> Use autoconf to test if ocaml version >= 4.02 If so, use

Re: [Xen-devel] [PATCH] xen: fix xsm build

On Thu, Jan 25, 2018 at 01:14:24PM +, Wei Liu wrote: > Commit e8d461497d9 renamed gcov_op to coverage_op but forgot to change > XSM handles. > > Signed-off-by: Wei Liu Osstest's ARM build is blocked by this now. I will wait until 5pm UK time for Daniel to express his

Re: [Xen-devel] [PATCH RFC] ocaml: Fix compile with ocaml 4.06, use unsafe strings

On Fri, Jan 26, 2018 at 09:29:20AM +, Christian Lindig wrote: > > > > On 26. Jan 2018, at 09:09, M A Young wrote: > > > > On Fri, 26 Jan 2018, John Thomson wrote: > > > >> Use autoconf to test if ocaml version >= 4.02 > >> If so, use -unsafe-string for ocamlopt and

Re: [Xen-devel] [PATCH v10 09/11] x86/ctxt: Issue a speculation barrier between vcpu contexts

On Fri, 2018-01-26 at 02:43 -0700, Jan Beulich wrote: > > > > On 26.01.18 at 02:08, wrote: > > And in order to go and investigate this a bit further, Jan, what is > > it > > that you were doing when you saw what you described above? AFAIUI, > > that's booting an HVM guest,

Re: [Xen-devel] [PATCH] xen,x86: introduce tcg_errata

>>> On 25.01.18 at 20:43, wrote: > I haven't investigated yet the QEMU side of the problem. I can dig > deeper there, then, once we understand the full extent of the issue, > we could decide what to do with this patch. However, I performed a few > tests so far and I

Re: [Xen-devel] [PATCH] xen,x86: introduce tcg_errata

>>> On 25.01.18 at 21:04, wrote: > On 25/01/18 19:43, Stefano Stabellini wrote: >> On Thu, 25 Jan 2018, Andrew Cooper wrote: >>> On 25/01/18 18:37, Stefano Stabellini wrote: The TCG emulator in QEMU is not good enough to pass the the tests in stub_selftest.

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

flight 118354 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118354/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 118326 Tests which

[Xen-devel] [libvirt test] 118319: regressions - FAIL

flight 118319 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/118319/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt 6 xen-install fail REGR. vs. 118278 Tests which did not

Re: [Xen-devel] [PATCH] x86/hvm: fix domain crash when CR3 has the noflush bit set

>>> On 26.01.18 at 11:49, wrote: > On 01/26/2018 12:27 PM, Jan Beulich wrote: > On 26.01.18 at 10:39, wrote: >>> --- a/xen/arch/x86/hvm/monitor.c >>> +++ b/xen/arch/x86/hvm/monitor.c >>> @@ -36,6 +36,12 @@ bool hvm_monitor_cr(unsigned int

Re: [Xen-devel] [PATCH] x86/hvm: fix domain crash when CR3 has the noflush bit set

On 01/26/2018 12:27 PM, Jan Beulich wrote: On 26.01.18 at 10:39, wrote: >> --- a/xen/arch/x86/hvm/hvm.c >> +++ b/xen/arch/x86/hvm/hvm.c >> @@ -2324,6 +2324,9 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer) >> } >> } >> >> +if (

Re: [Xen-devel] [PATCH RFC] x86/irq: Fix maybe uninitalised issue in map_domain_pirq()

>>> On 25.01.18 at 20:14, wrote: > When compiling at -O3, GCC 7.2 reports: > > irq.c: In function 'map_domain_pirq': > irq.c:1271:20: error: 'info' may be used uninitialized in this function > [-Werror=maybe-uninitialized] >pirq->arch.irq = irq; >

Re: [Xen-devel] [PATCH] x86/build: Untangle CONFIG_DEBUG and CONFIG_FRAME_POINTER

>>> On 25.01.18 at 19:39, wrote: > Both options are independently choseable in KConfig, but currently a DEBUG > build without FRAME_POINTER is left to the compilers default choice, not the > users choice. > > Signed-off-by: Andrew Cooper

Re: [Xen-devel] [PATCH] x86/hvm: fix domain crash when CR3 has the noflush bit set

>>> On 26.01.18 at 10:39, wrote: > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -2324,6 +2324,9 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer) > } > } > > +if ( hvm_pcid_enabled(v) ) /* Clear the noflush bit. */ > +

Re: [Xen-devel] [PATCH v10 09/11] x86/ctxt: Issue a speculation barrier between vcpu contexts

>>> On 26.01.18 at 02:08, wrote: > On Thu, 2018-01-25 at 19:49 +0100, Dario Faggioli wrote: >> On Thu, 2018-01-25 at 16:09 +, Andrew Cooper wrote: >> > On 25/01/18 15:57, Jan Beulich wrote: >> > > >> > > For the record, the overwhelming majority of calls to >> > >

[Xen-devel] [PATCH] x86/hvm: fix domain crash when CR3 has the noflush bit set

The emulation layers of Xen lack PCID support, and as we only offer PCID to HAP guests, all writes to CR3 are handled by hardware, except when introspection is involved. Consequently, trying to set CR3 when the noflush bit is set in hvm_set_cr3() leads to domain crashes. The workaround is to clear

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

flight 118328 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/118328/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539 Tests which did not

Re: [Xen-devel] [PATCH RFC] ocaml: Fix compile with ocaml 4.06, use unsafe strings

> On 26. Jan 2018, at 09:09, M A Young wrote: > > On Fri, 26 Jan 2018, John Thomson wrote: > >> Use autoconf to test if ocaml version >= 4.02 >> If so, use -unsafe-string for ocamlopt and ocamlc >> >> Bytes & safe-string were introduced in ocaml 4.02 (2015-07-27) >>

Re: [Xen-devel] [PATCH RFC] ocaml: Fix compile with ocaml 4.06, use unsafe strings

On Fri, 26 Jan 2018, John Thomson wrote: > Use autoconf to test if ocaml version >= 4.02 > If so, use -unsafe-string for ocamlopt and ocamlc > > Bytes & safe-string were introduced in ocaml 4.02 (2015-07-27) > > With ocaml 4.06, -safe-string is now default > This separates the types bytes

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

flight 118351 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118351/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 118326 Tests which

[Xen-devel] [PATCH RFC] ocaml: Fix compile with ocaml 4.06, use unsafe strings

Use autoconf to test if ocaml version >= 4.02 If so, use -unsafe-string for ocamlopt and ocamlc Bytes & safe-string were introduced in ocaml 4.02 (2015-07-27) With ocaml 4.06, -safe-string is now default This separates the types bytes (mutable string) and string ocaml 4.06 throws errors in