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

On 05/02/18 17:53, Dario Faggioli wrote: > On Mon, 2018-02-05 at 13:01 +, George Dunlap wrote: >> And in any case, making those improvements >> on credit2 will be easier than on credit. >> > And, if possible, I agree with George on this even more! > > One thing I think we should consider, thou

[Xen-devel] [xen-unstable test] 118594: regressions - FAIL

flight 118594 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/118594/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 118582 test-amd64-amd64-x

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On Mon, 5 Feb 2018 21:18:42 + Igor Druzhinin wrote: >We're noticing a reproducible system boot hang on certain >post-Skylake platforms where the BIOS is configured in >legacy boot mode with x2APIC disabled. The system stalls >immediately after writing the first SMP initialization >sequence in

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

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Monday, February 5, 2018 7:17 PM > > 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 > occasi

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

On 05/02/2018 19:23, Konrad Rzeszutek Wilk wrote: > On Mon, Feb 05, 2018 at 07:10:33PM +, Andrew Cooper wrote: >> -apply_alternatives(__alt_instructions, __alt_instructions_end); >> +/* Send ourselves an NMI to trigger the callback. */ >> +self_nmi(); >> + >> +/* >> + * Send

[Xen-devel] [linux-next test] 118588: regressions - trouble: blocked/broken/fail/pass

flight 118588 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/118588/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 broken test-amd64-i386-qemut-rhel6hvm-inte

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

flight 118590 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/118590/ 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 suc

[Xen-devel] [PATCH 2/2] pvcalls-front: wait for other operations to return when release passive sockets

Passive sockets can have ongoing operations on them, specifically, we have two wait_event_interruptable calls in pvcalls_front_accept. Add two wake_up calls in pvcalls_front_release, then wait for the potential waiters to return and release the sock_mapping refcount. Signed-off-by: Stefano Stabel

[Xen-devel] [PATCH 0/2] pvcalls-front improvements

Hi all, this small series introduces a per socket refcount to increase the efficiency on socket release operations, and makes releasing passive sockets safe. Cheers, Stefano Stefano Stabellini (2): pvcalls-front: introduce a per sock_mapping refcount pvcalls-front: wait for other o

[Xen-devel] [PATCH 1/2] pvcalls-front: introduce a per sock_mapping refcount

Introduce a per sock_mapping refcount, in addition to the existing global refcount. Thanks to the sock_mapping refcount, we can safely wait for it to be 1 in pvcalls_front_release before freeing an active socket, instead of waiting for the global refcount to be 1. Signed-off-by: Stefano Stabellini

[Xen-devel] [qemu-mainline test] 118589: regressions - trouble: broken/fail/pass

flight 118589 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/118589/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-xsm broken test-amd64-i386-libvirt-xsm 4 host-ins

Re: [Xen-devel] [GSOC] Xen on ARM: create multiple guests from device tree

> Hello Denis, > Hello Stefano, > it is great to see interest in Xen on ARM and this project! > > Unfortunately RPi3 can't run Xen as far as I know due to their non-ARM > interrupt controller without virtualization support. Otherwise it would > have been a good dev board. The BeagleBoard doesn't ha

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

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

[Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

We're noticing a reproducible system boot hang on certain post-Skylake platforms where the BIOS is configured in legacy boot mode with x2APIC disabled. The system stalls immediately after writing the first SMP initialization sequence into APIC ICR. The cause of the problem is watchdog NMI handler

Re: [Xen-devel] [Xen-users] Network and SATA Instability on Xen 4.6/4.8

Hi, we've been experiencing the same errors on very similar hardware. Just as Kevin described: all SATA goes down and NICs start to flap in Dom0, the only way to fix is to reboot. Unlike Kevin, i was unable to observe any patterns in system activity which may trigger these, it seems completely

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

flight 118586 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/118586/ 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 test-amd64-amd64-xl

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

On Mon, Feb 05, 2018 at 07:10:33PM +, Andrew Cooper 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 loo

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

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

On 02/05/2018 01:01 PM, Stefano Stabellini wrote: > On Sun, 4 Feb 2018, Boris Ostrovsky wrote: >> On 02/02/2018 08:34 PM, Stefano Stabellini wrote: >>> When the client sends a regular blocking accept request, the backend is >>> expected to return only when the accept is completed, simulating a >>>

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

On 05/02/18 16:20, Jan Beulich wrote: 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 paths, in

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

On Sun, 4 Feb 2018, Boris Ostrovsky wrote: > On 02/02/2018 08:34 PM, Stefano Stabellini wrote: > > 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. > > > > Speci

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

On Mon, Feb 05, 2018 at 11:16:55AM +, Andrew Cooper 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 lo

Re: [Xen-devel] [PATCH] xen/livepatch: Drop stray tabs and fix indentation

On Mon, Feb 05, 2018 at 11:04:01AM +, Andrew Cooper wrote: > Signed-off-by: Andrew Cooper > --- > CC: Konrad Rzeszutek Wilk Reviewed-by: Konrad Rzeszutek Wilk > CC: Ross Lagerwall > --- > xen/common/livepatch.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git

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

On Mon, Feb 05, 2018 at 10:24:58AM +, Andrew Cooper 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 loo

Re: [Xen-devel] [GSOC] Xen on ARM: create multiple guests from device tree

CC'ing Edgar who is co-mentoring this project On Sun, 4 Feb 2018, Denis Obrezkov wrote: > Hello all, > > I would like to participate in GSoC 2018 with the project Xen on ARM > related project. I have some previous experience with GSoC: > https://summerofcode.withgoogle.com/archive/2017/projects/4

Re: [Xen-devel] [PATCH 4/4] x86: avoid double CR3 reload when switching to guest user mode

On 31/01/18 10:12, Jan Beulich wrote: > >>> --- a/xen/arch/x86/pv/domain.c >>> +++ b/xen/arch/x86/pv/domain.c >>> @@ -220,10 +220,20 @@ int pv_domain_initialise(struct domain * >>> return rc; >>> } >>> >>> -static void _toggle_guest_pt(struct vcpu *v) >>> +static void _toggle_guest_pt(struc

Re: [Xen-devel] [PATCH 2/4] x86: eliminate most XPTI entry/exit code when it's not in use

On 30/01/18 13:51, Jan Beulich wrote: > >>> --- a/xen/arch/x86/x86_64/compat/entry.S >>> +++ b/xen/arch/x86/x86_64/compat/entry.S >>> @@ -189,7 +189,7 @@ ENTRY(compat_post_handle_exception) >>> >>> /* See lstar_enter for entry register state. */ >>> ENTRY(cstar_enter) >>> -/* sti could

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: >> --- a/xen/include/asm-x86/system.h >> +++ b/xen/include/asm-x86/system.h >> @@ -110,6 +110,38

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

>>> On 05.02.18 at 17:47, wrote: > On Mon, Feb 05, 2018 at 02:09:15AM -0700, Jan Beulich wrote: >> If the latter check was moved to the caller, the whole function >> would perhaps be better placed in nestedsvm.c? > > I thought about putting it in nestedsvm.c but I thought having it as a > static

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 ( cpu_has_cx16 ) > +{ > +__uint128_t *o

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 systems,

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 ASM_AC(STAC) >>> #define A

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 ) +{ +__uint128_t *old = p_old, cur; + +if (

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

On Mon, Feb 05, 2018 at 02:09:15AM -0700, Jan Beulich wrote: > If the latter check was moved to the caller, the whole function > would perhaps be better placed in nestedsvm.c? I thought about putting it in nestedsvm.c but I thought having it as a static function would be better. I could move it t

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 > It

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 Beulich > CC: Jun Nakajima > C

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. The three uses in wait.c may

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 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 unnecessary binary differences. Furthermore, dia

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 Xen-devel@lists.xenproj

[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 Pr

[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/arch/arm/domain.c | 1 +

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 paths, in which case bad things >>> will happen. >>> >

[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 separate

[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 that

[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 ne

[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 said

[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 Acked-by: Stefano St

[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 Reviewed-by: Stefano Stab

[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 Acked-by: Julien Grall --- xen/arch/arm/irq.c

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. >>> >>> Furthermore, diagnostic information around calls is inconsist

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 >>> --- >>> v3: New. >>> >>> --- a/xen/arch/x86/hvm/emulate.

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, >>> struct x86_emulate_ctxt *ct

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 ) goto done;

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; >> >> - op.cmd = cmd; >> -

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/arch/x86/hvm/svm/vmcb.c | 1

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 >> occasionally unhelpful. (e.g.

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(&op.u, arg, len); >

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 can be eliminated by runnin

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(&op.u, arg, len); You'll want an array_nospec() or whatever its called these days.

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(&op.u, arg, sizeof(op.u)); > - rc = _hypercall1(

[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 v3 21/25] x86emul: add read-modify-write hook

>>> On 05.02.18 at 15:21, wrote: > 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 >>>

[Xen-devel] Save the date: Xen Project Developer Summit, Nanjing, China, June 20-22 (Wednesday - Friday)

Dear Community members, we finalized the Xen Project Developer Summit proposal with the event hotel. Apologies this has taken so long. The event will be held at the Crowne Plaza Nanjing Jiangning

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 by default for >>> non-DEBUG

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 > Reviewed-by: Dario Faggioli Regards, Dario -- <> (Raistlin Majere) --

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 more that its prompt says "

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 combine both, and don't uni

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 > --- > SUPPORT.md | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/SUPPORT.md b/SUPPORT.md > index 42ffa9f..a181

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. PHYSDEVOP_xxx are also consecutive b

[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 save

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 "(EXPERIMENTAL)". Well I l

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 in NMI context, at > which

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 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 extra hoops, simplifying the analysis of problems in test >

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 logs from the field which might

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, &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 >>> +++ b/xen/arch/x86/mm/shadow/m

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 Acked-by: Jan Beulich

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 Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listin

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;\ > } while (0) > > -sta

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 b/xen/a

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). At

[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 workar

[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 unimplemented

[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 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 u

[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 becom

[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 +++ xe

[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. So

[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 copy_hyp_vec

[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 +++ b/xen/include/asm-a

[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 pr

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 +++ b/docs/misc/xen-command-line.markdown @@ -916,6 +916,19 @@ Controls EPT related fe

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 emulation code. >>> >>> The bl

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 which case the instruction is i

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 X86EMUL_OPC_VEX_66(0x0f3a, 0x48): /* v

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 what justification? > > Swit

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 >>> --- >>> CC: Jan Beulich >>> --- >>> xen/arch/x86/pv/Makefile

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 related features. >>> >>> Specify which console gdbstub

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; >> > + case EVTCHNOP_bind_virq

  1   2   >