[Xen-devel] [xen-4.9-testing test] 118524: tolerable FAIL - PUSHED

flight 118524 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/118524/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 118487 pass in 118524

[Xen-devel] [linux-4.9 test] 118520: tolerable FAIL - PUSHED

flight 118520 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/118520/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail in 118483 pass in 118520

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

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

[Xen-devel] [PATCH] pvcalls-back: do not return error on inet_accept EAGAIN

When the client sends a regular blocking accept request, the backend is expected to return only when the accept is completed, simulating a blocking behavior, or return an error. Specifically, on EAGAIN from inet_accept, the backend shouldn't return "EAGAIN" to the client. Instead, it should

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

flight 118547 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118547/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt

Re: [Xen-devel] [PATCH] xen: hypercall: fix out-of-bounds memcpy

On 02/02/2018 10:32 AM, Arnd Bergmann wrote: > The legacy hypercall handlers were originally added with > a comment explaining that "copying the argument structures in > HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op() into the local > variable is sufficiently safe" and only made sure to

Re: [Xen-devel] [PATCH v3 0/4] xen/arm: Inject an exception to the guest rather than crashing it

On 02/02/2018 22:48, Stefano Stabellini wrote: Committed, thanks I know you acked/reviewed all the patches, but it would have been nice to wait/give more feedback regarding Andre's valid point on patch #4. Cheers, On Fri, 2 Feb 2018, Julien Grall wrote: Hi all, This small series

Re: [Xen-devel] [PATCH v3 0/4] xen/arm: Inject an exception to the guest rather than crashing it

Committed, thanks On Fri, 2 Feb 2018, Julien Grall wrote: > Hi all, > > This small series replaces all call to domain_crash_synchronous by injecting > an exception to the guest. > > This will result to a nicer trace from the guest (no need to manually walk > the stack) and give a chance to the

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

flight 118544 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118544/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt

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

flight 118532 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/118532/ 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 v4 0/7] xen/arm32: Branch predictor hardening (XSA-254 variant 2)

Committed, thanks On Fri, 2 Feb 2018, Julien Grall wrote: > Hi all, > > This series provides a skeleton for mitigating branch predictor hardening for > arm32 on exception entry. > > It also implements mitigation for Cortex-A12, A15 and A17. SoC vendors with > affected CPUs are strongly

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

flight 118542 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118542/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt

Re: [Xen-devel] [PATCH v2] x86/xen: init %gs very early to avoid page faults with stack protector

On Fri, Feb 2, 2018 at 12:56 AM, Juergen Gross wrote: > On 02/02/18 01:36, Chris Patterson wrote: >> Works great, tested it and it fixes booting Linux v4.15 kernel for me :) > > Can I add your "Tested-by:" to the patch when committing it? > > Sure thing, have a great day.

[Xen-devel] [PATCH v2] xenbus: track caller request id

Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent xenstore accesses") optimized xenbus concurrent accesses but in doing so broke UABI of /dev/xen/xenbus. Through /dev/xen/xenbus applications are in charge of xenbus message exchange with the correct header and body. Now,

[Xen-devel] [PATCH 4.14 124/156] x86/xen: Support early interrupts in xen pv guests

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Juergen Gross [ Upstream commit 42b3a4cb5609de757f5445fcad18945ba9239a07 ] Add early interrupt handlers activated by idt_setup_early_handler() to the handlers supported by

Re: [Xen-devel] [PATCH v3 12/25] x86emul: abstract out XCRn accesses

>>> On 02.02.18 at 14:29, wrote: > On 07/12/17 14:07, Jan Beulich wrote: >> --- a/tools/tests/x86_emulator/x86-emulate.c >> +++ b/tools/tests/x86_emulator/x86-emulate.c >> @@ -120,6 +120,19 @@ int emul_test_read_cr( >> return X86EMUL_UNHANDLEABLE; >> } >> >>

[Xen-devel] [PATCH] x86/pv: Rename pv/ro-page-fault.c to pv/emul-ro-page-fault.c

To match all our other emulation handling. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/pv/Makefile | 2 +- xen/arch/x86/pv/{ro-page-fault.c => emul-ro-page-fault.c} | 2

[Xen-devel] [PATCH] x86/emul: Misc non-functional improvements

* Drop trailing whitespace * Use ARRAY_SIZE() rather than opencoding it Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/x86_emulate/x86_emulate.c | 13 ++--- xen/arch/x86/x86_emulate/x86_emulate.h | 12 ++-- 2

Re: [Xen-devel] [PATCH v3 24/25] x86/shadow: fully move unmap-dest into common code

On 07/12/17 14:18, Jan Beulich wrote: > @@ -1778,6 +1781,42 @@ void *sh_emulate_map_dest(struct vcpu *v > return map; > } > > +/**/ > +/* Optimization: If we see two emulated writes of zeros to the same > + *

Re: [Xen-devel] [PATCH v3 23/25] x86/HVM: make use of new read-modify-write emulator hook

On 07/12/17 14:17, Jan Beulich wrote: > ..., at least as far as currently possible, i.e. when a mapping can be > obtained. > > Signed-off-by: Jan Beulich > --- > v3: New. > > --- a/xen/arch/x86/hvm/emulate.c > +++ b/xen/arch/x86/hvm/emulate.c > @@ -1187,6 +1187,61 @@ static int

Re: [Xen-devel] [PATCH v3 22/25] x86/HVM: do actual CMPXCHG in hvmemul_cmpxchg()

On 07/12/17 14:16, Jan Beulich wrote: > ..., at least as far as currently possible, i.e. when a mapping can be > obtained. > > Signed-off-by: Jan Beulich > --- > v3: New. > > --- a/xen/arch/x86/hvm/emulate.c > +++ b/xen/arch/x86/hvm/emulate.c > @@ -1296,8 +1296,83 @@ static int

Re: [Xen-devel] [PATCH] xen: hypercall: fix out-of-bounds memcpy

On Fri, Feb 02, 2018 at 05:11:02PM +0100, Arnd Bergmann wrote: > On Fri, Feb 2, 2018 at 4:53 PM, Dan Carpenter > wrote: > > On Fri, Feb 02, 2018 at 04:32:31PM +0100, Arnd Bergmann wrote: > >> switch (cmd) { > >> + case EVTCHNOP_bind_interdomain: > >> +

Re: [Xen-devel] [PATCH v3 13/25] x86emul: adjust_bnd() should check XCR0

On 02/02/18 16:19, Jan Beulich wrote: On 02.02.18 at 14:30, wrote: >> On 07/12/17 14:08, Jan Beulich wrote: >>> Experimentally MPX instructions have been confirmed to behave as NOPs >>> unless both related XCR0 bits are set to 1. By implication branches >>> then

Re: [Xen-devel] [PATCH v1 2/4] hvm/svm: Enable Breakpoint events

On Vi, 2018-02-02 at 15:58 +, Andrew Cooper wrote: > On 02/02/18 09:37, Alexandru Isaila wrote: > > > > This commit enables the breakpoint events for svm. > > > > Signed-off-by: Alexandru Isaila > > --- > > xen/arch/x86/hvm/svm/svm.c| 52 > >

Re: [Xen-devel] [PATCH v3 16/25] x86emul: support SWAPGS

>>> On 02.02.18 at 14:41, wrote: > On 07/12/17 14:11, Jan Beulich wrote: >> Signed-off-by: Jan Beulich >> --- >> v3: New. >> >> --- a/xen/arch/x86/x86_emulate/x86_emulate.c >> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c >> @@ -5047,6 +5047,24 @@

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

flight 118539 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118539/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-i386 16 guest-localmigrate/x10 fail REGR. vs. 118537

Re: [Xen-devel] [PATCH v3 21/25] x86emul: add read-modify-write hook

On 07/12/17 14:16, Jan Beulich wrote: > In order to correctly emulate read-modify-write insns, especially > LOCKed ones, we should not issue reads and writes separately. Use a > new hook to combine both, and don't uniformly read the memory > destination anymore. Instead, DstMem opcodes without Mov

Re: [Xen-devel] [PATCH v3 13/25] x86emul: adjust_bnd() should check XCR0

>>> On 02.02.18 at 14:30, wrote: > On 07/12/17 14:08, Jan Beulich wrote: >> Experimentally MPX instructions have been confirmed to behave as NOPs >> unless both related XCR0 bits are set to 1. By implication branches >> then also don't clear BNDn. >> >> Signed-off-by:

Re: [Xen-devel] [PATCH v3 10/25] x86emul: support 3DNow! insns

On 02/02/18 15:22, Jan Beulich wrote: On 02.02.18 at 14:02, wrote: >> On 07/12/17 14:05, Jan Beulich wrote: >>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c >>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c >>> @@ -355,6 +355,36 @@ static const struct { >>>

Re: [Xen-devel] [PATCH] xen: hypercall: fix out-of-bounds memcpy

On Fri, Feb 2, 2018 at 4:53 PM, Dan Carpenter wrote: > On Fri, Feb 02, 2018 at 04:32:31PM +0100, Arnd Bergmann wrote: >> --- a/drivers/xen/fallback.c >> +++ b/drivers/xen/fallback.c >> @@ -7,75 +7,87 @@ >> >> int xen_event_channel_op_compat(int cmd, void *arg) >> { >>

Re: [Xen-devel] [PATCH v3 08/25] x86emul: add tables for XOP 08 and 09 extension spaces

On 02/02/18 15:15, Jan Beulich wrote: On 02.02.18 at 12:43, wrote: >> On 07/12/17 14:04, Jan Beulich wrote: >>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c >>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c >>> @@ -458,6 +458,20 @@ static const opcode_desc_t

Re: [Xen-devel] [PATCH v1 2/4] hvm/svm: Enable Breakpoint events

On 02/02/18 09:37, Alexandru Isaila wrote: > This commit enables the breakpoint events for svm. > > Signed-off-by: Alexandru Isaila > --- > xen/arch/x86/hvm/svm/svm.c| 52 > --- > xen/include/asm-x86/monitor.h | 3 ++- > 2

Re: [Xen-devel] [PATCH] xen: hypercall: fix out-of-bounds memcpy

On Fri, Feb 02, 2018 at 04:32:31PM +0100, Arnd Bergmann wrote: > The legacy hypercall handlers were originally added with > a comment explaining that "copying the argument structures in > HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op() into the local > variable is sufficiently safe" and

Re: [Xen-devel] [PATCH v1 2/4] hvm/svm: Enable Breakpoint events

On Fri, Feb 2, 2018 at 2:37 AM, Alexandru Isaila wrote: > This commit enables the breakpoint events for svm. > > Signed-off-by: Alexandru Isaila > --- > xen/arch/x86/hvm/svm/svm.c| 52 > --- >

Re: [Xen-devel] [PATCH RFC v2 11/12] x86: modify interrupt handlers to support stack switching

On 31/01/18 11:36, Jan Beulich wrote: On 30.01.18 at 18:19, wrote: >> On 30/01/18 17:07, Jan Beulich wrote: >> On 22.01.18 at 13:32, wrote: --- a/xen/arch/x86/x86_64/asm-offsets.c +++ b/xen/arch/x86/x86_64/asm-offsets.c @@ -137,6 +137,10

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

Hi On 02.02.18 16:31, Julien Grall wrote: Hi, On 02/02/18 14:23, Volodymyr Babchuk wrote: On 02.02.18 13:41, Julien Grall wrote: At the moment PSCI function dispatching is done in vsmc.c and the function implementation in vpsci.c. Some bits of the implementation is even done in vsmc.c (see

Re: [Xen-devel] [PATCH v1 1/4] asm-x86/monitor: Enable svm monitor events

On Fri, Feb 2, 2018 at 2:37 AM, Alexandru Isaila wrote: > This commit separates the svm caps from the vmx caps. > > Signed-off-by: Alexandru Isaila > --- > xen/include/asm-x86/monitor.h | 33 - > 1 file changed,

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

On Fri, Feb 2, 2018 at 1:14 AM, Razvan Cojocaru wrote: > 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

[Xen-devel] [PATCH] xen: hypercall: fix out-of-bounds memcpy

The legacy hypercall handlers were originally added with a comment explaining that "copying the argument structures in HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op() into the local variable is sufficiently safe" and only made sure to not write past the end of the argument structure, the

Re: [Xen-devel] [PATCH v3 10/25] x86emul: support 3DNow! insns

>>> On 02.02.18 at 14:02, wrote: > On 07/12/17 14:05, Jan Beulich wrote: >> --- a/xen/arch/x86/x86_emulate/x86_emulate.c >> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c >> @@ -355,6 +355,36 @@ static const struct { >> [0xff] = { ModRM } >> }; >> >> +static const

Re: [Xen-devel] [PATCH v3 09/25] x86emul: support XOP insns

>>> On 02.02.18 at 13:03, wrote: > On 07/12/17 14:04, Jan Beulich wrote: >> @@ -8027,6 +8060,13 @@ x86_emulate( >> generate_exception_if(vex.w, EXC_UD); >> goto simd_0f_imm8_avx; >> >> +case X86EMUL_OPC_VEX_66(0x0f3a, 0x48): /* vpermil2ps >>

Re: [Xen-devel] [PATCH v3 08/25] x86emul: add tables for XOP 08 and 09 extension spaces

>>> On 02.02.18 at 12:43, wrote: > On 07/12/17 14:04, Jan Beulich wrote: >> --- a/xen/arch/x86/x86_emulate/x86_emulate.c >> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c >> @@ -458,6 +458,20 @@ static const opcode_desc_t xop_table[] = >> DstReg|SrcImm|ModRM, >> };

Re: [Xen-devel] [PATCH v3 1/4] xen/arm: traps: Merge try_handle_mmio() and handle_mmio()

Hi, On 02/02/18 14:47, Julien Grall wrote: > > > On 02/02/18 14:34, Andre Przywara wrote: >> Hi, > > Hi, > >> On 02/02/18 10:14, Julien Grall wrote: >>> At the moment, try_handle_mmio() will do check on the HSR and bail out >>> if one check fail. This means that another method will be tried

Re: [Xen-devel] [PATCH v3 4/4] xen/arm: Don't crash the domain on invalid HVC immediate

On 02/02/18 14:37, Andre Przywara wrote: Hi, Hi, On 02/02/18 10:14, Julien Grall wrote: domain_crash_synchronous() should only be used when something went wrong in Xen. It is better to inject to the guest as it will be in a better position to provide helpful information (stack trace...).

Re: [Xen-devel] [PATCH v3 20/25] x86emul: correctly handle CMPXCHG* comparison failures

On 07/12/17 14:15, Jan Beulich wrote: > If the ->cmpxchg() hook finds a mismatch, we should deal with this the > same way as when the "manual" comparison reports a mismatch. > > This involves reverting bfce0e62c3 ("x86/emul: Drop > X86EMUL_CMPXCHG_FAILED"), albeit with X86EMUL_CMPXCHG_FAILED now >

Re: [Xen-devel] [PATCH v3 2/4] xen/arm: io: Distinguish unhandled IO from aborted one

On 02/02/18 14:34, Andre Przywara wrote: Hi, Hi, On 02/02/18 10:14, Julien Grall wrote: Currently, Xen is considering that an IO could either be handled or unhandled. When unhandled, the stage-2 abort function will try another way to resolve the abort. However, the MMIO emulation may

Re: [Xen-devel] [PATCH v3 1/4] xen/arm: traps: Merge try_handle_mmio() and handle_mmio()

On 02/02/18 14:34, Andre Przywara wrote: Hi, Hi, On 02/02/18 10:14, Julien Grall wrote: At the moment, try_handle_mmio() will do check on the HSR and bail out if one check fail. This means that another method will be tried to handle the fault even for bad access on emulated region. While

Re: [Xen-devel] [PATCH v3 4/4] xen/arm: Don't crash the domain on invalid HVC immediate

Hi, On 02/02/18 10:14, Julien Grall wrote: > domain_crash_synchronous() should only be used when something went wrong > in Xen. It is better to inject to the guest as it will be in a better > position to provide helpful information (stack trace...). > > Signed-off-by: Julien Grall

Re: [Xen-devel] [PATCH v3 3/4] xen/arm: Don't crash domain on bad MMIO emulation

Hi, On 02/02/18 10:14, Julien Grall wrote: > Now the MMIO emulation is able to distinguish unhandled IO from aborted > one, there are no need to crash the domain when the region is access > with a bad width. > > Instead let Xen inject a data abort to the guest and decide what to do. Very nice!

Re: [Xen-devel] [PATCH v3 2/4] xen/arm: io: Distinguish unhandled IO from aborted one

Hi, On 02/02/18 10:14, Julien Grall wrote: > Currently, Xen is considering that an IO could either be handled or > unhandled. When unhandled, the stage-2 abort function will try another > way to resolve the abort. > > However, the MMIO emulation may return unhandled when the address > belongs to

Re: [Xen-devel] [PATCH v3 1/4] xen/arm: traps: Merge try_handle_mmio() and handle_mmio()

Hi, On 02/02/18 10:14, Julien Grall wrote: > At the moment, try_handle_mmio() will do check on the HSR and bail out > if one check fail. This means that another method will be tried to > handle the fault even for bad access on emulated region. While this > should not be an issue, this is not

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

Hi, On 02/02/18 14:23, Volodymyr Babchuk wrote: On 02.02.18 13:41, Julien Grall wrote: At the moment PSCI function dispatching is done in vsmc.c and the function implementation in vpsci.c. Some bits of the implementation is even done in vsmc.c (see PSCI_SYSTEM_RESET). This means that it is

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

On 02.02.18 13:41, Julien Grall wrote: At the moment PSCI function dispatching is done in vsmc.c and the function implementation in vpsci.c. Some bits of the implementation is even done in vsmc.c (see PSCI_SYSTEM_RESET). This means that it is difficult to follow the implementation and also

[Xen-devel] [PATCH v4 3/7] xen/arm32: entry: Add missing trap_reset entry

At the moment, the reset vector is defined as .word 0 (e.g andeq r0, r0, r0). This is rather unintuitive and will result to execute the trap undefined. Instead introduce trap helpers for reset and will generate an error message in the unlikely case that reset will be called. This is part of

[Xen-devel] [PATCH v4 0/7] xen/arm32: Branch predictor hardening (XSA-254 variant 2)

Hi all, This series provides a skeleton for mitigating branch predictor hardening for arm32 on exception entry. It also implements mitigation for Cortex-A12, A15 and A17. SoC vendors with affected CPUs are strongly encouraged to update. For more information about the impact of this issue and

[Xen-devel] [PATCH v4 6/7] xen/arm32: Invalidate icache on guest exist for Cortex-A15

In order to avoid aliasing attacks against the branch predictor on Cortex A-15, let's invalidate the BTB on guest exit, which can only be done by invalidating the icache (with ACTLR[0] being set). We use the same hack as for A12/A17 to perform the vector decoding. This is based on Linux patch

[Xen-devel] [PATCH v4 2/7] xen/arm32: Add missing MIDR values for Cortex-A17 and A12

Cortex-A17 and A12 MIDR will be used in a follow-up patch for hardening the branch predictor. This is part of XSA-254. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini --- Changes in v2: - Add Stefano's reviewed-by ---

[Xen-devel] [PATCH v4 5/7] xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12

In order to avoid aliasing attackes agains the branch predictor, let's invalidate the BTB on guest exist. This is made complicated by the fact that we cannot take a branch invalidating the BTB. This is based on the fourth version posted by Marc Zyngier on Linux-arm mailing list (see [1]). This

[Xen-devel] [PATCH v4 4/7] xen/arm32: Add skeleton to harden branch predictor aliasing attacks

Aliasing attacked against CPU branch predictors can allow an attacker to redirect speculative control flow on some CPUs and potentially divulge information from one context to another. This patch adds initiatial skeleton code behind a new Kconfig option to enable implementation-specific

[Xen-devel] [PATCH v4 7/7] xen/arm32: entry: Document the purpose of r11 in the traps handler

It took me a bit of time to understand why __DEFINE_TRAP_ENTRY is storing the original stack pointer in r11. It is working in pair with return_traps_entry where sp will be restored from r11. This is fine because per the AAPCS r11 must be preserved by the subroutine. So in return_from_trap, r11

Re: [Xen-devel] Compatible string for psci node: v1.0?

Hi Julien, Thanks, it looks like the issue was with the way I verified this - cat on /sys/firmware/devicetree/base/psci/compatible from dom0's console returns only the first compatible string set by Xen no matter what. I have verified by debugging that linux finds the right compatible string in

Re: [Xen-devel] [PATCH v3 19/25] x86emul: tell cmpxchg hook whether LOCK is in effect

On 07/12/17 14:14, Jan Beulich wrote: > This is necessary for the hook to correctly perform the operation. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH v3 18/25] x86emul: add missing suffixes in test harness

On 07/12/17 14:12, Jan Beulich wrote: > I'm in the process of putting together a gas change issuing at least > warnings when the intended size of a memory operation can't be deduced > from another (register) operand. Add missing suffixes to silence such > future diagnostics. > > Signed-off-by: Jan

Re: [Xen-devel] [PATCH v3 17/25] x86emul: emulate {MONITOR, MWAIT}{, X} as no-op

On 07/12/17 14:11, Jan Beulich wrote: > As mentioned in Linux commit 87c00572ba ("kvm: x86: emulate monitor and > mwait instructions as nop"), older OS X versions (for example) may make > use of the insns without checking CPUID flags (presumably implying > availability from family/model). -1 to

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

On 02.02.18 13:41, 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 v2 1/3] xen/arm: vpsci: Removing dummy MIGRATE and MIGRATE_INFO_UP_CPU

Hi Julien, On 02.02.18 13:41, 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

Re: [Xen-devel] [PATCH v3 16/25] x86emul: support SWAPGS

On 07/12/17 14:11, Jan Beulich wrote: > Signed-off-by: Jan Beulich > --- > v3: New. > > --- a/xen/arch/x86/x86_emulate/x86_emulate.c > +++ b/xen/arch/x86/x86_emulate/x86_emulate.c > @@ -5047,6 +5047,24 @@ x86_emulate( > goto done; > break; > > +

Re: [Xen-devel] [PATCH v3 14/25] x86emul: make all FPU emulation use the stub

On 07/12/17 14:09, Jan Beulich wrote: > While this means quite some reduction of (source) code, the main > purpose is to no longer have exceptions raised from other than stubs. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper for the

Re: [Xen-devel] [PATCH v3 13/25] x86emul: adjust_bnd() should check XCR0

On 07/12/17 14:08, Jan Beulich wrote: > Experimentally MPX instructions have been confirmed to behave as NOPs > unless both related XCR0 bits are set to 1. By implication branches > then also don't clear BNDn. > > Signed-off-by: Jan Beulich > > ---

Re: [Xen-devel] [PATCH v3 12/25] x86emul: abstract out XCRn accesses

On 07/12/17 14:07, Jan Beulich wrote: > --- a/tools/tests/x86_emulator/x86-emulate.c > +++ b/tools/tests/x86_emulator/x86-emulate.c > @@ -120,6 +120,19 @@ int emul_test_read_cr( > return X86EMUL_UNHANDLEABLE; > } > > +int emul_test_read_xcr( > +unsigned int reg, > +uint64_t *val, >

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

flight 118537 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118537/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt

Re: [Xen-devel] [PATCH v3 11/25] x86emul: place test blobs in executable section

On 07/12/17 14:06, Jan Beulich wrote: > This allows the section contents to be disassembled without going > through any extra hoops, simplifying the analysis of problems in test > and/or emulation code. > > The blobs being emitted as (r/o) data means we need to accept an > assembler warning here

Re: [Xen-devel] [PATCH v3 10/25] x86emul: support 3DNow! insns

On 07/12/17 14:05, Jan Beulich wrote: > --- a/xen/arch/x86/x86_emulate/x86_emulate.c > +++ b/xen/arch/x86/x86_emulate/x86_emulate.c > @@ -355,6 +355,36 @@ static const struct { > [0xff] = { ModRM } > }; > > +static const uint16_t _3dnow_table[16] = { Comment explaining how these mappings

Re: [Xen-devel] [PATCH v3 09/25] x86emul: support XOP insns

On 07/12/17 14:04, Jan Beulich wrote: > @@ -8027,6 +8060,13 @@ x86_emulate( > generate_exception_if(vex.w, EXC_UD); > goto simd_0f_imm8_avx; > > +case X86EMUL_OPC_VEX_66(0x0f3a, 0x48): /* vpermil2ps > $imm,{x,y}mm/mem,{x,y}mm,{x,y}mm,{x,y}mm */ > +

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

On Thu, Feb 1, 2018 at 4:45 PM, Andy Shevchenko wrote: > On Thu, Feb 1, 2018 at 9:57 AM, Rafael J. Wysocki wrote: >> On Wed, Jan 31, 2018 at 4:43 PM, Andy Shevchenko >> wrote: >>> On Mon, Jan 29, 2018 at 5:02 AM, Rafael J.

Re: [Xen-devel] [PATCH v3 08/25] x86emul: add tables for XOP 08 and 09 extension spaces

On 07/12/17 14:04, Jan Beulich wrote: > Convert the few existing opcodes so far supported. > > Also adjust two vex_* case labels to better be ext_* (the values are > identical). > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/x86_emulate/x86_emulate.c > +++

[Xen-devel] [PATCH v2 0/3] xen/arm: SMCCC fixes and PSCI clean-up

Hi all, This small patch series contains SMCCC fixes (see #2) and PSCI clean-up. Cheers, Julien Grall (3): xen/arm: vpsci: Removing dummy MIGRATE and MIGRATE_INFO_UP_CPU xen/arm: vsmc: Don't implement function ID that doesn't exist xen/arm: vpsci: Move PSCI function dispatching from

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

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 remove the implementations for both function.

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

At the moment PSCI function dispatching is done in vsmc.c and the function implementation in vpsci.c. Some bits of the implementation is even done in vsmc.c (see PSCI_SYSTEM_RESET). This means that it is difficult to follow the implementation and also requires to export functions for each PSCI

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

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 SMC32 functions have equivalent in the SMC64.

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

flight 118501 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/118501/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail REGR. vs. 118324

[Xen-devel] [PATCH v3 4/4] xen/arm: Don't crash the domain on invalid HVC immediate

domain_crash_synchronous() should only be used when something went wrong in Xen. It is better to inject to the guest as it will be in a better position to provide helpful information (stack trace...). Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini

[Xen-devel] [PATCH v3 2/4] xen/arm: io: Distinguish unhandled IO from aborted one

Currently, Xen is considering that an IO could either be handled or unhandled. When unhandled, the stage-2 abort function will try another way to resolve the abort. However, the MMIO emulation may return unhandled when the address belongs to an emulated range but was not correct. In that case,

[Xen-devel] [PATCH v3 0/4] xen/arm: Inject an exception to the guest rather than crashing it

Hi all, This small series replaces all call to domain_crash_synchronous by injecting an exception to the guest. This will result to a nicer trace from the guest (no need to manually walk the stack) and give a chance to the guest to give a bit more information on what it was doing. Cheers,

[Xen-devel] [PATCH v3 1/4] xen/arm: traps: Merge try_handle_mmio() and handle_mmio()

At the moment, try_handle_mmio() will do check on the HSR and bail out if one check fail. This means that another method will be tried to handle the fault even for bad access on emulated region. While this should not be an issue, this is not future proof. Move the checks of try_handle_mmio() in

[Xen-devel] [PATCH v3 3/4] xen/arm: Don't crash domain on bad MMIO emulation

Now the MMIO emulation is able to distinguish unhandled IO from aborted one, there are no need to crash the domain when the region is access with a bad width. Instead let Xen inject a data abort to the guest and decide what to do. Signed-off-by: Julien Grall Reviewed-by:

Re: [Xen-devel] [PATCHv2] xen-netfront: remove warning when unloading module

On 02/02/2018 10:54 AM, Eduardo Otubo wrote: On Wed, Jan 31, 2018 at 05:00:23PM +0200, Oleksandr Andrushchenko wrote: Hi, Eduardo! I am working on a frontend driver (PV DRM) and also seeing some strange things on driver unloading: xt# rmmod -f drm_xen_front.ko [ 3236.462497] [drm]

Re: [Xen-devel] [PATCH v3 07/25] x86emul: support AVX2 gather insns

>>> On 01.02.18 at 21:53, wrote: > On 07/12/17 14:03, Jan Beulich wrote: >> @@ -2805,13 +2808,17 @@ x86_decode( >> ea.type = OP_MEM; >> if ( modrm_rm == 4 ) >> { >> -sib = insn_fetch_type(uint8_t); >> -

[Xen-devel] [PATCH v1 4/4] hvm/svm: Enable CR events

This commit enables controlregister events for svm. Signed-off-by: Alexandru Isaila --- xen/arch/x86/hvm/svm/svm.c| 11 +++ xen/include/asm-x86/monitor.h | 3 ++- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/svm/svm.c

[Xen-devel] [PATCH v1 1/4] asm-x86/monitor: Enable svm monitor events

This commit separates the svm caps from the vmx caps. Signed-off-by: Alexandru Isaila --- xen/include/asm-x86/monitor.h | 33 - 1 file changed, 20 insertions(+), 13 deletions(-) diff --git a/xen/include/asm-x86/monitor.h

[Xen-devel] [PATCH v1 3/4] hvm/svm: Enable MSR events

This commit enables MSR events for svm. Signed-off-by: Alexandru Isaila --- xen/arch/x86/hvm/svm/svm.c| 9 + xen/include/asm-x86/monitor.h | 3 ++- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/svm/svm.c

[Xen-devel] [PATCH v1 0/4] hvm/svm: Enable vm events for SVM

Hi all, This series provides a skeleton for enabling vm_events on SVM. For the first step, the MSR, CR, Breakpoint and GuestRequest have been tested and added to the capabilities list. Cheers, Alexandru Isaila ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH v2] x86/xen: init %gs very early to avoid page faults with stack protector

On 02/02/18 01:36, Chris Patterson wrote: > Works great, tested it and it fixes booting Linux v4.15 kernel for me :) Can I add your "Tested-by:" to the patch when committing it? Juergen > > Cheers! > > On Thu, Feb 1, 2018 at 3:17 PM, Boris Ostrovsky > wrote: >>

Re: [Xen-devel] [PATCH v3 06/25] x86emul: support most remaining AVX2 insns

>>> On 01.02.18 at 20:45, wrote: > On 07/12/17 14:03, Jan Beulich wrote: >> @@ -2973,7 +2985,7 @@ x86_decode( >> } >> break; >> >> -case simd_scalar_fp: >> +case simd_scalar_fp: /* case simd_scalar_dq: */ > > I don't see this case label

Re: [Xen-devel] [PATCH] common/gnttab: Introduce command line feature controls

>>> On 01.02.18 at 15:38, wrote: > --- a/docs/misc/xen-command-line.markdown > +++ b/docs/misc/xen-command-line.markdown > @@ -916,6 +916,19 @@ Controls EPT related features. > > Specify which console gdbstub should use. See **console**. > > +### gnttab > +> `=

[Xen-devel] [PATCH V3] 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