[Xen-devel] [PATCH] x86/emul: Adjustments to exception error code handling

The mkec() end result in c/s bac133d43 wasn't really what I intended, and unfortunately hides programmer errors if passing an error code with an exception which doesn't take one. Rework mkec() completely to simply insert X86_EVENT_NO_EC if no error code parameter was provided. It still is the

Re: [Xen-devel] [PATCH v1 0/5] libxl: add PV sound device

On Tue, Jan 9, 2018 at 1:30 PM, Oleksandr Grytsov wrote: > On Mon, Nov 20, 2017 at 3:44 PM, Oleksandr Grytsov > wrote: > >> On Tue, Nov 14, 2017 at 2:38 PM, Oleksandr Grytsov >> wrote: >> >>> On Wed, Nov 1, 2017 at 5:04 PM, Oleksandr

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

From: Boris Ostrovsky > Sent: 02 February 2018 23:34 ... > > switch (cmd) { > > + case EVTCHNOP_bind_interdomain: > > + len = sizeof(struct evtchn_bind_interdomain); > > + break; > > + case EVTCHNOP_bind_virq: > > + len = sizeof(struct evtchn_bind_virq); > > +

[Xen-devel] [PATCH] x86/emul: Fix the emulation of invlpga

The instruction requires EFER.SVME set to be usable in the first place. Furthermore, the emulation doesn't handle ASIDs, so avoid giving the impression that they work. Permit ASID 0 which is reserved for non-root mode (in which case the instruction is identical to invlpg), but raise #UD for any

Re: [Xen-devel] [PATCH] libxl: add libxl__is_driver_domain function

On Tue, Jan 9, 2018 at 1:34 PM, Oleksandr Grytsov wrote: > On Thu, Dec 14, 2017 at 4:14 PM, Oleksandr Grytsov > wrote: > >> From: Oleksandr Grytsov >> >> We have following arm-based setup: >> >> - Dom0 with xen and xen tools; >> -

[Xen-devel] [PATCH 3/3] xen: Disable ARINC653 scheduler by default for non-DEBUG builds

The ARINC653 scheduler is targeted at a very specific niche; typical users cannot benefit from using it. Disable it by default for non-DEBUG builds. (Enable it for DEBUG builds so that we catch any build breakages sooner rather than later.) Signed-off-by: George Dunlap

Re: [Xen-devel] [PATCH 1/3] Make credit2 the default scheduler

On 05/02/18 11:36, George Dunlap wrote: > Credit2 was declared "supported" in 4.8, and as of 4.10 had two other > critical features implemented (soft affinity / NUMA and caps). > > Signed-off-by: George Dunlap On what justification? Switching the default involves

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

On 02/02/18 08:51, Jan Beulich wrote: 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.

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

On Vi, 2018-02-02 at 08:42 -0700, Tamas K Lengyel wrote: > 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-devel] [PATCH] xen/livepatch: Drop stray tabs and fix indentation

Signed-off-by: Andrew Cooper --- CC: Konrad Rzeszutek Wilk CC: Ross Lagerwall --- xen/common/livepatch.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/common/livepatch.c

Re: [Xen-devel] [PATCH v1 0/6] libxl: create standalone vkb device

On Tue, Jan 9, 2018 at 1:31 PM, Oleksandr Grytsov wrote: > > > On Mon, Nov 20, 2017 at 3:44 PM, Oleksandr Grytsov > wrote: > >> On Tue, Nov 14, 2017 at 2:39 PM, Oleksandr Grytsov >> wrote: >> >>> On Wed, Nov 1, 2017 at 5:05 PM, Oleksandr

[Xen-devel] [PATCH 1/3] Make credit2 the default scheduler

Credit2 was declared "supported" in 4.8, and as of 4.10 had two other critical features implemented (soft affinity / NUMA and caps). Signed-off-by: George Dunlap --- CC: Ian Jackson CC: Wei Liu CC: Andrew Cooper

[Xen-devel] [PATCH 2/3] xen: Fix credit1 Kconfig entry

...so that it shows up in the menu and can be disabled. Signed-off-by: George Dunlap --- CC: Ian Jackson CC: Wei Liu CC: Andrew Cooper CC: Jan Beulich CC: Tim Deegan

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

flight 118580 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/118580/ 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 v3 0/4] xen/arm: Inject an exception to the guest rather than crashing it

Hi, On 02/02/18 23:10, Julien Grall wrote: > > > 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. I think that's fine. I didn't

Re: [Xen-devel] [PATCH v4 2/7] xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing

Hi Jan, (Sorry for the late reply.) 2018-02-02 16:32 GMT+08:00 Jan Beulich : On 01.02.18 at 19:11, wrote: >> 2018-02-01 18:23 GMT+08:00 Jan Beulich : >> On 30.01.18 at 18:50, wrote: ---

[Xen-devel] [PATCH] x86/boot: Make alternative patching NMI-safe

During patching, there is a very slim risk that an NMI or MCE interrupt in the middle of altering the code in the NMI/MCE paths, in which case bad things will happen. The NMI risk can be eliminated by running the patching loop in NMI context, at which point the CPU will defer further NMIs until

[Xen-devel] [PATCH] xen: Improvements to domain_crash_sync()

The use of __LINE__ in a printk() is problematic for livepatching, as it causes unnecessary binary differences. Furthermore, diagnostic information around calls is inconsistent and occasionally unhelpful. (e.g. diagnosing logs from the field which might be release builds, or likely without exact

[Xen-devel] [PATCH] vmx/altp2m: Use domain_crash_sync() when failing to find the current EPTP

When failing to locate the guests EPTP in the altp2m EPTP list, use domain_crash_sync() rather than domain_crash(). The latter returns and will hit the subsequent BUG(). Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Jun Nakajima

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

flight 118591 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118591/ 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 25/25] x86/shadow: fold sh_x86_emulate_{write, cmpxchg}() into their only callers

Hi, At 01:42 -0700 on 05 Feb (1517794959), Jan Beulich wrote: > >>> On 02.02.18 at 17:52, wrote: > > On 07/12/17 14:19, Jan Beulich wrote: > >> +case 1: prev = cmpxchg((uint8_t *)ptr, old, new); break; > >> +case 2: prev = cmpxchg((uint16_t *)ptr, old, new);

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

On 05/02/18 08:57, Jan Beulich wrote: On 02.02.18 at 17:58, wrote: >> To match all our other emulation handling. >> >> No functional change. >> >> Signed-off-by: Andrew Cooper >> --- >> CC: Jan Beulich >> --- >>

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

On Mon, Feb 5, 2018 at 1:11 PM, David Laight wrote: > From: Boris Ostrovsky >> Sent: 02 February 2018 23:34 > ... >> > switch (cmd) { >> > + case EVTCHNOP_bind_interdomain: >> > + len = sizeof(struct evtchn_bind_interdomain); >> > + break; >> > +

Re: [Xen-devel] [PATCH 1/3] Make credit2 the default scheduler

On 02/05/2018 11:45 AM, Andrew Cooper wrote: > On 05/02/18 11:36, George Dunlap wrote: >> Credit2 was declared "supported" in 4.8, and as of 4.10 had two other >> critical features implemented (soft affinity / NUMA and caps). >> >> Signed-off-by: George Dunlap > > On

Re: [Xen-devel] [PATCH 3/3] xen: Disable ARINC653 scheduler by default for non-DEBUG builds

>>> On 05.02.18 at 12:36, wrote: > The ARINC653 scheduler is targeted at a very specific niche; typical > users cannot benefit from using it. Disable it by default for > non-DEBUG builds. The more that its prompt says "(EXPERIMENTAL)". > Signed-off-by: George Dunlap

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

>>> On 05.02.18 at 14:11, wrote: > On 02/02/18 15:27, Jan Beulich wrote: > On 02.02.18 at 14:03, wrote: >>> On 07/12/17 14:06, Jan Beulich wrote: This allows the section contents to be disassembled without going through any

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

>>> On 05.02.18 at 13:22, wrote: > On 05/02/18 08:57, Jan Beulich wrote: > On 02.02.18 at 17:58, wrote: >>> To match all our other emulation handling. >>> >>> No functional change. >>> >>> Signed-off-by: Andrew Cooper

Re: [Xen-devel] [PATCH] x86/emul: Fix the emulation of invlpga

>>> On 05.02.18 at 11:38, wrote: > The instruction requires EFER.SVME set to be usable in the first place. > > Furthermore, the emulation doesn't handle ASIDs, so avoid giving the > impression that they work. Permit ASID 0 which is reserved for non-root > mode (in

[Xen-devel] [PATCH 0/7] xen/arm: PSCI 1.1 and SMCCC-1.1 support and XSA-254 variant 2 update

Hi all, Arm has recently published a SMC Calling Convention (SMCCC) specification update [1] that provides an optimised calling convention and optional, discoverable support for mitigating CVE-2017-5715 (XSA-254 variant 2). ARM Trusted Firmware (ATF) has already gained such an implementation[2].

[Xen-devel] [PATCH 3/7] xen/arm: vpsci: Add support for PSCI 1.1

At the moment, Xen provides virtual PSCI interface compliant with 0.1 and 0.2. Since them, the specification has been updated and the latest version is 1.1 (see ARM DEN 0022D). From an implementation point of view, only PSCI_FEATURES is mandatory. The rest is optional and can be left

[Xen-devel] [PATCH 1/7] xen/arm: vpsci: Remove parameter 'ver' from do_common_cpu

Currently, the behavior of do_common_cpu will slightly change depending on the PSCI version passed in parameter. Looking at the code, more the specific 0.2 behavior could move out of the function or adapted for 0.1: - x0/r0 can be updated on PSCI 0.1 because general purpose registers are

Re: [Xen-devel] [PATCH 9/9] xen/arm: Help to know the hardening provided for a CPU

Hmmm sorry, I was not meant to be sent with this series. I will resend it separately with a proper commit message. On 05/02/18 13:20, Julien Grall wrote: --- xen/arch/arm/cpuerrata.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/cpuerrata.c

Re: [Xen-devel] [PATCH 8/9] xen/arm: Park CPUs with a MIDR different from the boot CPU.

Hmmm sorry, I was not meant to be sent with this series. It is also a duplicate of the same patch sent last week. On 05/02/18 13:20, Julien Grall wrote: Xen does not properly support big.LITTLE platform. All vCPUs of a guest will always have the MIDR of the boot CPU (see arch_domain_create).

Re: [Xen-devel] [PATCH] x86/emul: Adjustments to exception error code handling

>>> On 05.02.18 at 11:59, wrote: > --- a/xen/arch/x86/x86_emulate/x86_emulate.c > +++ b/xen/arch/x86/x86_emulate/x86_emulate.c > @@ -877,14 +877,12 @@ do { > \ > if ( rc ) goto done;

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

On 05/02/18 08:07, Jan Beulich wrote: > >>> + >>> +memcpy(p_old, , bytes); >> This is redundant with ... >> >>> + >>> +return rc; >>> } >>> >>> static const struct x86_emulate_ops hvm_shadow_emulator_ops = { >>> --- a/xen/arch/x86/mm/shadow/multi.c >>> +++

Re: [Xen-devel] [PATCH] x86/boot: Make alternative patching NMI-safe

>>> On 05.02.18 at 11:24, wrote: > During patching, there is a very slim risk that an NMI or MCE interrupt in the > middle of altering the code in the NMI/MCE paths, in which case bad things > will happen. > > The NMI risk can be eliminated by running the patching loop

[Xen-devel] [xen-unstable test] 118582: tolerable FAIL

flight 118582 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/118582/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118551 test-armhf-armhf-libvirt-xsm 14

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

On 05/02/18 08:22, Jan Beulich wrote: On 02.02.18 at 17:13, wrote: >> 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

Re: [Xen-devel] [PATCH 3/3] xen: Disable ARINC653 scheduler by default for non-DEBUG builds

On Mon, 2018-02-05 at 06:36 -0700, Jan Beulich wrote: > > > > On 05.02.18 at 12:36, wrote: > > > > The ARINC653 scheduler is targeted at a very specific niche; > > typical > > users cannot benefit from using it. Disable it by default for > > non-DEBUG builds. > > The

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

>>> On 05.02.18 at 12:55, wrote: > On 02/02/18 08:51, Jan Beulich wrote: > 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

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

On 02/02/18 15:17, Jan Beulich wrote: 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

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

On 02/02/18 15:27, Jan Beulich wrote: On 02.02.18 at 14:03, wrote: >> 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

[Xen-devel] [PATCH 6/7] xen/arm: Adapt smccc.h to be able to use it in assembly code

Signed-off-by: Julien Grall --- xen/include/asm-arm/smccc.h | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h index b790fac17c..d24ccb51d8 100644 --- a/xen/include/asm-arm/smccc.h

[Xen-devel] [PATCH 4/7] xen/arm: vsmc: Implement SMCCC 1.1

The new SMC Calling Convention (v1.1) allows for a reduced overhead when calling into the firmware, and provides a new feature discovery mechanism. See ARM DEN 00070A. Signed-off-by: Julien Grall --- xen/arch/arm/vpsci.c| 1 + xen/arch/arm/vsmc.c | 23

[Xen-devel] [PATCH 8/9] xen/arm: Park CPUs with a MIDR different from the boot CPU.

Xen does not properly support big.LITTLE platform. All vCPUs of a guest will always have the MIDR of the boot CPU (see arch_domain_create). At best the guest may see unreliable performance (vCPU switching between big and LITTLE), at worst the guest will become unreliable or insecure. This is

[Xen-devel] [PATCH 2/7] xen/arm: psci: Rework the PSCI definitions

Some PSCI functions are only available in the 32-bit version. After recent changes, Xen always needs to know whether the call was made using 32-bit id or 64-bit id. So we don't emulate reserved one. With the current naming scheme, it is not easy to know which call supports 32-bit and 64-bit id.

[Xen-devel] [PATCH 7/7] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_1

The function SMCCC_ARCH_WORKAROUND_1 will be called by the guest for hardening the branch predictor. So we want the handling to be as fast as possible. As the mitigation is applied on every guest exit, we can check for the call before saving all the context and return very early. For now, only

[Xen-devel] [PATCH 9/9] xen/arm: Help to know the hardening provided for a CPU

--- xen/arch/arm/cpuerrata.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c index 9c7458ef06..6704648b26 100644 --- a/xen/arch/arm/cpuerrata.c +++ b/xen/arch/arm/cpuerrata.c @@ -79,7 +79,8 @@ static bool

Re: [Xen-devel] [PATCH 2/3] xen: Fix credit1 Kconfig entry

>>> On 05.02.18 at 12:36, wrote: > ...so that it shows up in the menu and can be disabled. > > Signed-off-by: George Dunlap Acked-by: Jan Beulich ___ Xen-devel mailing list

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

From: Arnd Bergmann > Sent: 05 February 2018 12:37 > > Are the EVTCHNOP_xxx values dense? > > In which case an array is almost certainly better than the switch statement. > > They are, yes. PHYSDEVOP_xxx are also consecutive by start at '4'. > Dan made the same comment earlier, and I replied

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

On Mon, Feb 5, 2018 at 2:58 PM, David Laight wrote: > From: Arnd Bergmann >> Sent: 05 February 2018 12:37 > >> > Are the EVTCHNOP_xxx values dense? >> > In which case an array is almost certainly better than the switch >> > statement. >> >> They are, yes.

Re: [Xen-devel] [PATCH 1/2] SUPPORT.md: increment version number

On Wed, Jan 31, 2018 at 1:03 PM, Ian Jackson wrote: > CC: Andrew Cooper > Reported-by: Andrew Cooper > Signed-off-by: Ian Jackson Acked-by: George Dunlap >

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

On 02/05/2018 12:56 PM, Jan Beulich wrote: On 05.02.18 at 12:55, wrote: >> On 02/02/18 08:51, Jan Beulich wrote: >> On 01.02.18 at 15:38, wrote: --- a/docs/misc/xen-command-line.markdown +++

[Xen-devel] [PATCH 5/7] xen/arm: vsmc: Implement SMCCC_ARCH_WORKAROUND_1 BP hardening support

SMCCC 1.1 offers firmware-based CPU workarounds. In particular, SMCCC_ARCH_WORKAROUND_1 provides BP hardening for variant 2 of XSA-254 (CVE-2017-5715). If the hypervisor has some mitigation for this issue, report that we deal with it using SMCCC_ARCH_WORKAROUND_1, as we apply the hypervisor

Re: [Xen-devel] [PATCH] xen: Improvements to domain_crash_sync()

>>> On 05.02.18 at 12:16, wrote: > The use of __LINE__ in a printk() is problematic for livepatching, as it > causes unnecessary binary differences. > > Furthermore, diagnostic information around calls is inconsistent and > occasionally unhelpful. (e.g. diagnosing

Re: [Xen-devel] [PATCH 3/3] xen: Disable ARINC653 scheduler by default for non-DEBUG builds

On 02/05/2018 01:36 PM, Jan Beulich wrote: On 05.02.18 at 12:36, wrote: >> The ARINC653 scheduler is targeted at a very specific niche; typical >> users cannot benefit from using it. Disable it by default for >> non-DEBUG builds. > > The more that its prompt says

Re: [Xen-devel] [PATCH 3/3] xen: Disable ARINC653 scheduler by default for non-DEBUG builds

On 02/05/2018 02:42 PM, Dario Faggioli wrote: > On Mon, 2018-02-05 at 06:36 -0700, Jan Beulich wrote: > On 05.02.18 at 12:36, wrote: >>> >>> The ARINC653 scheduler is targeted at a very specific niche; >>> typical >>> users cannot benefit from using it. Disable it

Re: [Xen-devel] [PATCH 2/3] xen: Fix credit1 Kconfig entry

On Mon, 2018-02-05 at 06:35 -0700, Jan Beulich wrote: > > > > On 05.02.18 at 12:36, wrote: > > > > ...so that it shows up in the menu and can be disabled. > > > > Signed-off-by: George Dunlap > > Acked-by: Jan Beulich >

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

From: Andrew Cooper > Sent: 05 February 2018 15:14 > > On 05/02/18 15:03, Arnd Bergmann wrote: > > Snipping deleted code to make things clearer: > > > + if (cmd > ARRAY_SIZE(physdevop_len)) > > + return -ENOSYS; > > > > + len = physdevop_len[cmd]; > > + memcpy(, arg, len); > >

Re: [Xen-devel] [PATCH] xen: Improvements to domain_crash_sync()

On 05/02/18 13:44, Jan Beulich wrote: On 05.02.18 at 12:16, wrote: >> The use of __LINE__ in a printk() is problematic for livepatching, as it >> causes unnecessary binary differences. >> >> Furthermore, diagnostic information around calls is inconsistent and >>

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

>>> On 05.02.18 at 16:03, wrote: > int xen_event_channel_op_compat(int cmd, void *arg) > { > - struct evtchn_op op; > + struct evtchn_op op = { .cmd = cmd, }; > + size_t len; > int rc; > > - op.cmd = cmd; > - memcpy(, arg, sizeof(op.u)); > - rc =

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

On 05/02/18 15:03, Arnd Bergmann wrote: Snipping deleted code to make things clearer: > + if (cmd > ARRAY_SIZE(physdevop_len)) > + return -ENOSYS; > > + len = physdevop_len[cmd]; > + memcpy(, arg, len); You'll want an array_nospec() or whatever its called these days. 

Re: [Xen-devel] [PATCH] x86/boot: Make alternative patching NMI-safe

On 05/02/18 14:09, Jan Beulich wrote: On 05.02.18 at 11:24, wrote: >> During patching, there is a very slim risk that an NMI or MCE interrupt in >> the >> middle of altering the code in the NMI/MCE paths, in which case bad things >> will happen. >> >> The NMI risk

Re: [Xen-devel] [PATCH 2/3] x86/svm: add EFER SVME support for VGIF/VLOAD

On 31/01/18 20:35, Brian Woods wrote: > Only enable virtual VMLOAD/SAVE and VGIF if the guest EFER.SVME is set. > > Reported-by: Andrew Cooper > Signed-off-by: Brian Woods > --- > xen/arch/x86/hvm/svm/svm.c | 69 >

[Xen-devel] [PATCH] [v2] 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] [v2] xen: hypercall: fix out-of-bounds memcpy

On Mon, Feb 5, 2018 at 4:14 PM, Jan Beulich wrote: On 05.02.18 at 16:03, wrote: >> int xen_event_channel_op_compat(int cmd, void *arg) >> { >> - struct evtchn_op op; >> + struct evtchn_op op = { .cmd = cmd, }; >> + size_t len; >> int rc;

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

On 05/02/18 08:32, Jan Beulich wrote: On 02.02.18 at 17:36, wrote: >> On 07/12/17 14:16, Jan Beulich wrote: >>> --- a/xen/arch/x86/hvm/emulate.c >>> +++ b/xen/arch/x86/hvm/emulate.c >>> @@ -1296,8 +1296,83 @@ static int hvmemul_cmpxchg( >>> bool lock, >>>

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

On 05/02/18 08:34, Jan Beulich wrote: On 02.02.18 at 17:37, wrote: >> 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 >>> --- >>>

[Xen-devel] [PATCH v4 2/8] ARM: VGIC: split gic.c to observe hardware/virtual GIC separation

Currently gic.c holds code to handle hardware IRQs as well as code to bridge VGIC requests to the GIC virtualization hardware. Despite being named gic.c, this file reaches into the VGIC and uses data structures describing virtual IRQs. To improve abstraction, move the VGIC functions into a

[Xen-devel] [PATCH v4 3/8] ARM: VGIC: split up gic_dump_info() to cover virtual part separately

Currently gic_dump_info() not only dumps the hardware state of the GIC, but also the VGIC internal virtual IRQ lists. Split the latter off and move it into gic-vgic.c to observe the abstraction. Signed-off-by: Andre Przywara Reviewed-by: Stefano Stabellini

[Xen-devel] [PATCH v4 1/8] ARM: VGIC: drop unneeded gic_restore_pending_irqs()

In gic_restore_pending_irqs() we push our pending virtual IRQs into the list registers. This function is called once from gic_inject(), just before we return to the guest, but also in gic_restore_state(), when we context-switch a VCPU. Having a closer look it turns out that the later call is not

Re: [Xen-devel] [PATCH] x86/boot: Make alternative patching NMI-safe

>>> On 05.02.18 at 16:16, wrote: > On 05/02/18 14:09, Jan Beulich wrote: > On 05.02.18 at 11:24, wrote: >>> During patching, there is a very slim risk that an NMI or MCE interrupt in >>> the >>> middle of altering the code in the NMI/MCE

[Xen-devel] [PATCH v4 4/8] ARM: VGIC: rework events_need_delivery()

In event.h we very deeply dive into the VGIC to learn if an event for a guest is pending. Rework that function to abstract the VGIC specific part out. Also reorder the queries there, as we only actually need to check for the event channel if there are no other pending IRQs. Signed-off-by: Andre

Re: [Xen-devel] [PATCH] x86/emul: Adjustments to exception error code handling

>>> On 05.02.18 at 17:00, wrote: > On 05/02/18 13:32, Jan Beulich wrote: > On 05.02.18 at 11:59, wrote: >>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c >>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c >>> @@ -877,14 +877,12 @@ do {

Re: [Xen-devel] [PATCH] xen: Improvements to domain_crash_sync()

>>> On 05.02.18 at 17:24, wrote: > Actually, on further consideration, its probably best to drop > domain_crash_sync() entirely, and opencode the softirq loop in the few > cases of almost-removed code. That would completely prevent people from > introducing new uses.

Re: [Xen-devel] [PATCH] vmx/altp2m: Use domain_crash_sync() when failing to find the current EPTP

On 05/02/18 11:21, Andrew Cooper wrote: > When failing to locate the guests EPTP in the altp2m EPTP list, use > domain_crash_sync() rather than domain_crash(). The latter returns and will > hit the subsequent BUG(). > > Signed-off-by: Andrew Cooper > --- > CC: Jan

Re: [Xen-devel] [PATCH 2/3] x86/svm: add EFER SVME support for VGIF/VLOAD

On Mon, Feb 05, 2018 at 03:37:06PM +, Andrew Cooper wrote: > Indenting is off, but that can be fixed on commit. Oopsy, sorry about that. > As some extra cleanup, what about folding this diff in?  It avoids > repeatedly hitting the cleanbits, and is clearer to follow IMO. > > ~Andrew >

Re: [Xen-devel] [PATCH] x86/emul: Adjustments to exception error code handling

On 05/02/18 13:32, Jan Beulich wrote: On 05.02.18 at 11:59, wrote: >> --- a/xen/arch/x86/x86_emulate/x86_emulate.c >> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c >> @@ -877,14 +877,12 @@ do { >> \ >> if ( rc

[Xen-devel] [PATCH v4 5/8] ARM: VGIC: factor out vgic_connect_hw_irq()

At the moment we happily access VGIC internal data structures like the rank and struct pending_irq in gic.c, which should be VGIC agnostic. Factor out a new function vgic_connect_hw_irq(), which allows a virtual IRQ to be connected to a hardware IRQ (using the hw bit in the LR). This removes

[Xen-devel] [PATCH v4 0/8] ARM: VGIC/GIC separation cleanups

Hi, an updated version, focussing on the complaints Julien raised about the locking on assigned hardware IRQs. Patch 5/8 has been changed to address his concerns. I dropped the tag on this patch, also on 2/8 since I moved the per-CPU variable declaration into gic.h, as requested. Not sure if

[Xen-devel] [PATCH v4 7/8] ARM: VGIC: rework gicv[23]_update_lr to not use pending_irq

The functions to actually populate a list register were accessing the VGIC internal pending_irq struct, although they should be abstracting from that. Break the needed information down to remove the reference to pending_irq from gic-v[23].c. Signed-off-by: Andre Przywara

[Xen-devel] [PATCH v4 8/8] ARM: make nr_irqs a constant

On ARM the maximum number of IRQs is a constant, but we share it being a variable to match x86. Since we are not supposed to alter it, let's mark it as "const" to avoid accidental change. Suggested-by: Julien Grall Signed-off-by: Andre Przywara

Re: [Xen-devel] [PATCH] xen: Improvements to domain_crash_sync()

>>> On 05.02.18 at 16:34, wrote: > On 05/02/18 13:44, Jan Beulich wrote: > On 05.02.18 at 12:16, wrote: >>> The use of __LINE__ in a printk() is problematic for livepatching, as it >>> causes unnecessary binary differences. >>> >>>

[Xen-devel] [PATCH v4 6/8] ARM: VGIC: factor out vgic_get_hw_irq_desc()

At the moment we happily access the VGIC internal struct pending_irq (which describes a virtual IRQ) in irq.c. Factor out the actually needed functionality to learn the associated hardware IRQ and move that into gic-vgic.c to improve abstraction. Signed-off-by: Andre Przywara

Re: [Xen-devel] [PATCH] xen: Improvements to domain_crash_sync()

On 05/02/18 16:17, Jan Beulich wrote: On 05.02.18 at 16:34, wrote: >> On 05/02/18 13:44, Jan Beulich wrote: >> On 05.02.18 at 12:16, wrote: The use of __LINE__ in a printk() is problematic for livepatching, as it causes

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

On Mon, 5 Feb 2018, Arnd Bergmann wrote: > + if (cmd > ARRAY_SIZE(evtchnop_len)) > + return -ENOSYS; > + len = evtchnop_len[cmd]; What if cmd == ARRAY_SIZE(evtchnop_len) ? Nicolas ___ Xen-devel mailing list

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

>>> On 05.02.18 at 17:09, wrote: > On 05/02/18 08:32, Jan Beulich wrote: > On 02.02.18 at 17:36, wrote: >>> On 07/12/17 14:16, Jan Beulich wrote: +case 16: +if ( cpu_has_cx16 ) +{ +

Re: [Xen-devel] [PATCH 1/4] x86: remove CR reads from exit-to-guest path

On 30/01/18 11:10, Jan Beulich wrote: On 30.01.18 at 12:01, wrote: >> On 23/01/18 10:36, Jan Beulich wrote: >>> --- a/xen/include/asm-x86/asm_defns.h >>> +++ b/xen/include/asm-x86/asm_defns.h >>> @@ -206,13 +206,12 @@ void ret_from_intr(void); >>> #define ASM_STAC

Re: [Xen-devel] [PATCH 1/3] Make credit2 the default scheduler

On Mon, 2018-02-05 at 13:01 +, George Dunlap wrote: > On 02/05/2018 11:45 AM, Andrew Cooper wrote: > > > Here is a summary of data from an intern e-mail Dario sent about 6 > months ago: > > * DVDbench: On underloaded systems, credit2 outperformed credit1 by > about 4%. On overloaded

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

On 05/02/18 16:49, Jan Beulich wrote: On 05.02.18 at 17:09, wrote: >> On 05/02/18 08:32, Jan Beulich wrote: >> On 02.02.18 at 17:36, wrote: On 07/12/17 14:16, Jan Beulich wrote: > +case 16: > +if (

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

>>> On 05.02.18 at 17:57, wrote: > On 05/02/18 16:49, Jan Beulich wrote: > On 05.02.18 at 17:09, wrote: >>> On 05/02/18 08:32, Jan Beulich wrote: >>> On 02.02.18 at 17:36, wrote: >> ---

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

>>> On 02.02.18 at 15:49, wrote: > On 07/12/17 14:15, Jan Beulich wrote: >> --- a/xen/arch/x86/mm/shadow/common.c >> +++ b/xen/arch/x86/mm/shadow/common.c >> @@ -302,8 +302,12 @@ hvm_emulate_cmpxchg(enum x86_segment seg >> memcpy(, p_old, bytes); >> memcpy(,

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

>>> On 02.02.18 at 17:13, wrote: > 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

[Xen-devel] [PATCH 1/2] sndif: introduce protocol version

From: Oleksandr Andrushchenko Protocol version was referenced in the protocol description, but missed its definition. Fix this by adding a constant for current protocol version. Signed-off-by: Oleksandr Andrushchenko ---

[Xen-devel] [PATCH 0/2] sndif: add explicit back and front synchronization

From: Oleksandr Andrushchenko Hi, all! Foreword This change is aimed to add support for explicit back and front synchronization during playback and capture in response to comments raised during upstream attempt of the para-virtualized sound frontend

[Xen-devel] [PATCH 2/2] sndif: add explicit back and front synchronization

From: Oleksandr Andrushchenko In order to provide explicit synchronization between backend and frontend the following changes are introduced in the protocol: - add new ring buffer for sending asynchronous events from backend to frontend to report number of

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

>>> On 02.02.18 at 17:36, wrote: > On 07/12/17 14:16, Jan Beulich wrote: >> --- a/xen/arch/x86/hvm/emulate.c >> +++ b/xen/arch/x86/hvm/emulate.c >> @@ -1296,8 +1296,83 @@ static int hvmemul_cmpxchg( >> bool lock, >> struct x86_emulate_ctxt *ctxt) >> { >> -

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

>>> On 02.02.18 at 17:37, wrote: > 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

Re: [Xen-devel] [PATCH v3 25/25] x86/shadow: fold sh_x86_emulate_{write, cmpxchg}() into their only callers

>>> On 02.02.18 at 17:52, wrote: > On 07/12/17 14:19, Jan Beulich wrote: >> @@ -298,14 +332,43 @@ hvm_emulate_cmpxchg(enum x86_segment seg >> if ( rc ) >> return rc; >> >> +/* Unaligned writes are only acceptable on HVM */ >> +if ( (addr & (bytes

Re: [Xen-devel] [PATCH v8 02/17] x86: Support indirect thunks from assembly code

>>> On 04.02.18 at 11:57, wrote: > On Fri, 2018-01-12 at 18:00 +, Andrew Cooper wrote: >> +#ifdef CONFIG_INDIRECT_THUNK >> +/* callq __x86_indirect_thunk_rcx */ >> +ctxt->io_emul_stub[10] = 0xe8; >> +*(int32_t *)>io_emul_stub[11] = >> +(unsigned

  1   2   >