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

On Wed, Jan 31, 2018 at 4:43 PM, Andy Shevchenko wrote: > On Mon, Jan 29, 2018 at 5:02 AM, Rafael J. Wysocki wrote: >> On Sun, Jan 28, 2018 at 4:04 PM, Andy Shevchenko >> wrote: >>> On Fri, Jan 26, 2018 at 8:21 PM, Juergen

Re: [Xen-devel] [bug]xen 4.10 + dom0 4.15 couldn't boot up

On 01/02/18 07:20, Zhang, Xiong Y wrote: > This is the message with debug=y > Xen 4.11-unstable > (XEN) Xen version 4.11-unstable (test@) (gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) > 5.4.0 20160609) debug=y Tue Jan 30 02:38:14 CST 2018 > (XEN) Latest ChangeSet: Wed Jan 24 12:01:55 2018 +

Re: [Xen-devel] [PATCH V2] tests/xen-access: disable CR4 write events on application exit

On 01/29/2018 11:48 PM, Razvan Cojocaru wrote: > On exit, xen-access did not unsubscribe from CR4 write vm_events, > potentially leaving the guest stuck. > > Signed-off-by: Razvan Cojocaru > > --- > Changes since V1: > - Made all the ignored parameters of

Re: [Xen-devel] kernel-ml-4.15.0-1.el7.elrepo.x86_64 doesn't boot as Xen PV domU

On 01/02/18 01:17, Michael Young wrote: > On Wed, 31 Jan 2018, Michael Young wrote: > >> (XEN) Guest stack trace from rsp=82203e20: >> (XEN)    >> 81036a89 >> (XEN)    0001e030 00010092 82203e68 >>

[Xen-devel] [PATCH v3] libxc: don't fail domain creation when unpacking initrd fails

At least Linux kernels have been able to work with gzip-ed initrd for quite some time; initrd compressed with other methods aren't even being attempted to unpack. Furthermore the unzip-ing routine used here isn't capable of dealing with various forms of concatenated files, each of which was

Re: [Xen-devel] Problem with IOMEM and domain reboot

Ian, Wei, could you please take a look at the below? Thank you, Oleksandr On 12/20/2017 06:27 PM, Oleksandr Andrushchenko wrote: Hi, all! While trying to reboot a domain which has iomem configured (we are passing through some devices), I found an issue, that after domain reboot those

Re: [Xen-devel] [bug]xen 4.10 + dom0 4.15 couldn't boot up

This is the message with debug=y Xen 4.11-unstable (XEN) Xen version 4.11-unstable (test@) (gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609) debug=y Tue Jan 30 02:38:14 CST 2018 (XEN) Latest ChangeSet: Wed Jan 24 12:01:55 2018 + git:1252e28 (XEN) Bootloader: GRUB 2.02~beta2-36ubuntu3.8

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

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

[Xen-devel] [xen-4.8-testing test] 118465: tolerable FAIL - PUSHED

flight 118465 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/118465/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-xtf-amd64-amd64-5 49 xtf/test-hvm64-lbr-tsx-vmentry fail in 118446 pass in 118465

Re: [Xen-devel] Xen 4.11 Development Update

On 18-01-31 02:57:32, Jan Beulich wrote: > >>> On 31.01.18 at 07:57, wrote: > > === x86 === > > > > * Enable Memory Bandwidth Allocation in Xen (v10) > > - XEN-48 > > - Yi Sun > > I think this has all gone in, the tools parts a little less than two weeks > ago. > Yes,

Re: [Xen-devel] [PATCH 1/3] xen/arm: io: Distinguish unhandled IO from aborted one

On Wed, 31 Jan 2018, Julien Grall wrote: > Hi Stefano, > > On 30/01/18 19:09, Stefano Stabellini wrote: > > On Tue, 30 Jan 2018, Julien Grall wrote: > > > > > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c > > > > > index c8534d6cff..843adf4959 100644 > > > > > ---

[Xen-devel] [seabios test] 118475: regressions - trouble: broken/fail/pass

flight 118475 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/118475/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-amd broken test-amd64-amd64-xl-qemuu-ws16-amd64 17

Re: [Xen-devel] kernel-ml-4.15.0-1.el7.elrepo.x86_64 doesn't boot as Xen PV domU

On Wed, 31 Jan 2018, Michael Young wrote: (XEN) Guest stack trace from rsp=82203e20: (XEN) 81036a89 (XEN)0001e030 00010092 82203e68 e02b (XEN)

[Xen-devel] [xtf test] 118484: all pass - PUSHED

flight 118484 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/118484/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf 9eeb26f3faeb25925c0cfde9ec18571fdbfbe4fa baseline version: xtf

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

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

Re: [Xen-devel] kernel-ml-4.15.0-1.el7.elrepo.x86_64 doesn't boot as Xen PV domU

On Wed, 31 Jan 2018, Adi Pircalabu wrote: (XEN) d8v0: unhandled page fault (ec=) (XEN) Pagetable walk from 0028: (XEN) L4[0x000] = (XEN) domain_crash_sync called from entry.S: fault at 82d08022a472 create_bounce_frame+0x12b/0x13a (XEN)

[Xen-devel] [linux-linus bisection] complete test-amd64-amd64-xl-pvhv2-amd

branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-xl-pvhv2-amd testid guest-start Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu

[Xen-devel] [PATCH 1/3] x86/svm: update VGIF support

There are places where the GIF value is checked. A guest with VGIF enabled can change the GIF value without the host being involved, therefore it needs to check the GIF value in the VMCB rather the one in the nestedsvm struct. Signed-off-by: Brian Woods ---

[Xen-devel] [PATCH 3/3] x86/svm: correct EFER.SVME intercept checks

Corrects some EFER.SVME checks in intercepts. See AMD APM vol2 section 15.4 for more details. VMMCALL isn't checked due to guests needing it to boot. Reported-by: Andrew Cooper Signed-off-by: Brian Woods --- xen/arch/x86/hvm/svm/nestedsvm.c |

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

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

[Xen-devel] [PATCH 0/3] Various SVM Cleanups

This is a small series of SVM cleanup patches. The first patch is correcting a couple of checks relating to VGIF. The other two are ensuring that nested SVM functionality is emulated/setup more correctly. Brian Woods (3): x86/svm: update VGIF support x86/svm: add EFER SVME support for

Re: [Xen-devel] [PATCH v3 04/25] x86emul: support FMA4 insns

On 07/12/17 14:01, Jan Beulich wrote: > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

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

flight 118456 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/118456/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeat fail REGR. vs. 118441 Tests which

Re: [Xen-devel] [PATCH v3 03/25] x86emul: support F16C insns

On 07/12/17 14:00, Jan Beulich wrote: > Note that this avoids emulating the behavior of VCVTPS2PH found on at > least some Intel CPUs, which update MXCSR even when the memory write > faults. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper

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

On Wed, Jan 31, 2018 at 11:44 AM, Tamas K Lengyel wrote: > " > > On Tue, Jan 30, 2018 at 2:16 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

Re: [Xen-devel] [PATCH 2/2] update the minimal ocaml version to 4.02

> On 30. Jan 2018, at 22:56, Michael Young wrote: > > The ocaml safe-strings patch uses code introduced in ocaml 4.02 > so update the minimal version. > Signed-off-by: Michael Young > --- > stubdom/configure| 4 ++-- > stubdom/configure.ac |

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

On Wed, 31 Jan 2018, Julien Grall wrote: > From: Julien Grall > > 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

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

On Wed, 31 Jan 2018, Julien Grall wrote: > From: Julien Grall > > 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

[Xen-devel] [PATCH RFC] firmware/shim: fix Xen tree setup

There are multiple issues here, and I'm happy to split the patch up if that's what it takes: - "set -e" on a separate Makefile line is meaningless. Glue together all the lines that this is supposed to cover. - I have no idea what *.d1 is supposed to refer to - we only have .*.d and .*.d2 files

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

From: Julien Grall 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 first version posrted by Marc

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

From: Julien Grall 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

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

From: Julien Grall 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

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

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

On Wed, 31 Jan 2018, Julien Grall wrote: > Hi Stefano, > > On 25/01/18 19:35, Stefano Stabellini wrote: > > > This means that bne will branch only when bit 2 is set. So the only way to > > > end > > > here is because the first 3-bit are equal to 0x00X. This corresponds to > > > IRQ/FIQ vector. >

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

On Wed, 31 Jan 2018, Julien Grall wrote: > On 26/01/18 16:21, Julien Grall wrote: > > > "Therefore hypervisor code running with guest vectors table should be > > > minimized and always have interrupts and async aborts masked to reduce > > > the risk to use them." > > > > > > Do you think that it

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

On 31/01/18 15:54, Andre Przywara wrote: Hi, Yeah! Locking discussions! Have fun below ;-) On 30/01/18 13:19, Julien Grall wrote: Hi Andre, On 24/01/18 18:10, Andre Przywara wrote: At the moment we happily access VGIC internal data structures like the rank and struct pending_irq in gic.c,

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

Hi, On 31/01/18 16:16, Julien Grall wrote: > Hi, > > On 24/01/18 18:10, Andre Przywara wrote: >> 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

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

Hi, On 24/01/18 18:10, Andre Przywara wrote: 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.

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

On Mon, Jan 29, 2018 at 5:02 AM, Rafael J. Wysocki wrote: > On Sun, Jan 28, 2018 at 4:04 PM, Andy Shevchenko > wrote: >> On Fri, Jan 26, 2018 at 8:21 PM, Juergen Gross wrote: >>> On 26/01/18 19:08, Andy Shevchenko wrote: On

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

On Mon, Jan 29, 2018 at 5:01 AM, Rafael J. Wysocki wrote: > On Fri, Jan 26, 2018 at 7:08 PM, Andy Shevchenko > wrote: >> I have stumbled on the similar stuff and realize that. >> >> Perhaps, one of the solution is to have an additional struct under

[Xen-devel] [PATCH] x86/shim: don't use 32-bit compare on boolean variable

Current upstream gas silently assumes 32-bit operand size for most operations where the size can't be inferred from an involved register (my own one doesn't anymore, which is how I've noticed this). It is pure luck that the 3 bytes following pvh_boot are currently padding ones. Signed-off-by: Jan

Re: [Xen-devel] [PATCH 0.5/5] arm/alternatives: Drop the !HAS_ALTERNATIVE infrastructure

Hi, On 30/01/18 11:31, Andrew Cooper wrote: On 30/01/18 11:29, Julien Grall wrote: Hi Andrew, Thank you for doing the clean-up. On 30/01/18 11:16, Andrew Cooper wrote: ARM now unconditionally selects HAS_ALTERNATIVE, which has caused the !HAS_ALTERNATIVE code in

Re: [Xen-devel] Access I2C bus from guest/DomU on ARM board

Hello Saumya, On 18.01.18 09:50, Saumya Rajesh wrote: Actually I am planning to set up Android as guest in Xen. I see. In order to enable sound in the Android guest, I need to passthrough the audio codec device which communicates through the I2C bus. For BE/FE scheme, I think sharing the

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

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] Unregistering XEN PV vdispl [ 3236.485745] [drm:xen_drv_remove [drm_xen_front]] *ERROR* Backend state is InitWait while removing

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

On 31.01.18 16:54, Julien Grall wrote: On 31/01/18 11:32, Volodymyr Babchuk wrote: I thought about vpsci.h, but basically you will have only 2 functions in it and the number of PSCI calls. That's it. Is  this really a problem? It is quite natural to find declarations for something.c in

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

On 31/01/18 14:29, Volodymyr Babchuk wrote: Hi, Hi Volodymyr, On 31.01.18 13:36, Julien Grall wrote: Hi, On 31/01/18 11:32, Volodymyr Babchuk wrote: I thought about vpsci.h, but basically you will have only 2 functions in it and the number of PSCI calls. That's it. Is  this really a

Re: [Xen-devel] [PATCH 4.10] SUPPORT.md: Fix version and Initial-Release

>>> On 31.01.18 at 14:10, wrote: > On 31/01/18 13:06, Ian Jackson wrote: >> Security-Support-Until should be `TBD'. We need to answer these >> questions properly, but let's not block fixing the obvious bugs here >> for that policy discussion. >> >> CC: Andrew Cooper

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

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

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

Hi, On 31.01.18 13:36, Julien Grall wrote: Hi, On 31/01/18 11:32, Volodymyr Babchuk wrote: I thought about vpsci.h, but basically you will have only 2 functions in it and the number of PSCI calls. That's it. Is  this really a problem? It is quite natural to find declarations for

[Xen-devel] [xen-4.9-testing test] 118452: regressions - FAIL

flight 118452 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/118452/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 broken in 118314

Re: [Xen-devel] [PATCH 4.10] SUPPORT.md: Fix version and Initial-Release

On 31/01/18 13:06, Ian Jackson wrote: > Security-Support-Until should be `TBD'. We need to answer these > questions properly, but let's not block fixing the obvious bugs here > for that policy discussion. > > CC: Andrew Cooper > CC: Lars Kurth >

Re: [Xen-devel] [PATCH 2/2] release-checklist.txt: Say to increment SUPPORT.md version number

On 31/01/18 13:03, Ian Jackson wrote: > CC: Andrew Cooper > Reported-by: Andrew Cooper > Signed-off-by: Ian Jackson > --- > docs/process/release-checklist.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git

[Xen-devel] [PATCH 4.10] SUPPORT.md: Fix version and Initial-Release

Security-Support-Until should be `TBD'. We need to answer these questions properly, but let's not block fixing the obvious bugs here for that policy discussion. CC: Andrew Cooper CC: Lars Kurth Reported-by: Andrew Cooper

[Xen-devel] [PATCH 2/2] release-checklist.txt: Say to increment SUPPORT.md version number

CC: Andrew Cooper Reported-by: Andrew Cooper Signed-off-by: Ian Jackson --- docs/process/release-checklist.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/process/release-checklist.txt

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

CC: Andrew Cooper Reported-by: Andrew Cooper Signed-off-by: Ian Jackson --- SUPPORT.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SUPPORT.md b/SUPPORT.md index 42ffa9f..a1810b8 100644 ---

[Xen-devel] [PATCH v2] x86/emul: Split exception handling out of invoke_stub()

For a release build, bloat-o-meter reports: add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-5111 (-5111) function old new delta x86_emulate 126458 121347 -5111 or in other words, a 4% redunction in code size from this

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

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

Re: [Xen-devel] [PATCH 1/3] xen/arm: io: Distinguish unhandled IO from aborted one

Hi Stefano, On 30/01/18 19:09, Stefano Stabellini wrote: On Tue, 30 Jan 2018, Julien Grall wrote: diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index c8534d6cff..843adf4959 100644 --- a/xen/arch/arm/traps.c +++ b/xen/arch/arm/traps.c @@ -1864,10 +1864,10 @@ static inline bool

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

Hi Stefano, On 30/01/18 19:21, Stefano Stabellini wrote: On Tue, 30 Jan 2018, Julien Grall wrote: Hi, On 30/01/18 18:29, Andrew Cooper wrote: On 30/01/18 17:00, Julien Grall wrote: On 30/01/18 16:38, Andrew Cooper wrote: On 30/01/18 16:14, Julien Grall wrote: Hi all, This small series

Re: [Xen-devel] ThunderX support in Xen

Hi Stefano, On 31/01/18 00:01, Stefano Stabellini wrote: > I am testing Xen support in ThunderX, but I am having some issues > booting Dom0 using Xen staging and the Ubuntu Xenial kernel (it has > CONFIG_XEN enabled). The trace is appened to this email. I am using the > device tree converted from

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

Hi, On 31/01/18 11:32, Volodymyr Babchuk wrote: I thought about vpsci.h, but basically you will have only 2 functions in it and the number of PSCI calls. That's it. Is  this really a problem? It is quite natural to find declarations for something.c in something.h. By moving declaration into

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

Hi Julien, On 31.01.18 00:06, Julien Grall wrote: On 30 January 2018 at 19:35, Volodymyr Babchuk wrote: On 30.01.18 20:44, Julien Grall wrote: On 30/01/18 18:28, Volodymyr Babchuk wrote: Hi Julien, On 30.01.18 20:01, Julien Grall wrote: On 26/01/18

Re: [Xen-devel] [PATCH v2 1/4] x86/emul: Introduce a test covering legacy byte ops

On 31/01/18 11:06, Jan Beulich wrote: On 30.01.18 at 16:56, wrote: >> Signed-off-by: Andrew Cooper > Reviewed-by: Jan Beulich > with one cosmetic remark: > >> --- a/tools/tests/x86_emulator/test_x86_emulator.c >> +++

Re: [Xen-devel] Xen 4.11 Development Update

On Wed, Jan 31, 2018 at 07:57:51AM +0100, Juergen Gross wrote: > * Comet: Run PV in PVH container (v2) > - Wei Liu > This is committed some time ago. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

[Xen-devel] [OSSTEST PATCH] sg-report-host-history: Multiply size of reported history by 10

Right now, http://logs.test-lab.xenproject.org/osstest/results/host/laxton1.html contains ~200 jobs as expected, but that covers only 4 days. We obviously would like more like a month. The effect ought to be some more db work, but not worse concurrency. CC: Julien Grall

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

>>> On 30.01.18 at 16:56, wrote: > --- a/xen/arch/x86/x86_emulate/x86_emulate.c > +++ b/xen/arch/x86/x86_emulate/x86_emulate.c > @@ -1957,9 +1957,8 @@ const uint8_t cpu_user_regs_gpr_offsets[] = { > #endif > }; > > -void * > -decode_register( > -uint8_t

Re: [Xen-devel] [PATCH v2 2/4] x86/emul: Optimise decode_register() somewhat

>>> On 30.01.18 at 16:56, wrote: > --- a/xen/arch/x86/x86_emulate/x86_emulate.c > +++ b/xen/arch/x86/x86_emulate/x86_emulate.c > @@ -1935,36 +1935,67 @@ load_seg( > return rc; > } > > +/* Map GPRs by ModRM encoding to their offset within struct cpu_user_regs. */

Re: [Xen-devel] [PATCH v2 1/4] x86/emul: Introduce a test covering legacy byte ops

>>> On 30.01.18 at 16:56, wrote: > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich with one cosmetic remark: > --- a/tools/tests/x86_emulator/test_x86_emulator.c > +++ b/tools/tests/x86_emulator/test_x86_emulator.c

Re: [Xen-devel] [PATCH 4/5] x86/alternative: Implement NMI/#MC-safe patching

>>> On 30.01.18 at 20:26, wrote: > On 30/01/18 08:39, Jan Beulich wrote: > On 29.01.18 at 16:38, wrote: >>> +/* >>> + * We are the CPU performing the patching, and might have ended up >>> here by >>> + * hitting a breakpoint.

Re: [Xen-devel] [PATCH] xen/cmdline: Fix parse_boolean() for unadorned values

>>> On 31.01.18 at 11:36, wrote: > A command line such as "cpuid=no-ibrsb,no-stibp" tickles a bug in > parse_boolean() because the separating comma fails the NUL case. > > Instead, check for slen == nlen which accounts for the boundary (if any) > passed via the 'e'

Re: [Xen-devel] [PATCH RFC v2 12/12] x86: activate per-vcpu stacks in case of xpti

>>> On 30.01.18 at 18:33, wrote: > On 30/01/18 17:33, Jan Beulich wrote: > On 22.01.18 at 13:32, wrote: >>> --- a/xen/arch/x86/domain.c >>> +++ b/xen/arch/x86/domain.c >>> @@ -1585,9 +1585,28 @@ static inline bool need_full_gdt(const struct domain >>> *d)

[Xen-devel] [PATCH] xen/cmdline: Fix parse_boolean() for unadorned values

A command line such as "cpuid=no-ibrsb,no-stibp" tickles a bug in parse_boolean() because the separating comma fails the NUL case. Instead, check for slen == nlen which accounts for the boundary (if any) passed via the 'e' parameter. Signed-off-by: Andrew Cooper ---

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

>>> 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 @@ void __dummy__(void) >>>

Re: [Xen-devel] [PATCH 4/5] x86/alternative: Implement NMI/#MC-safe patching

On 31/01/18 06:07, Juergen Gross wrote: > On 30/01/18 20:26, Andrew Cooper wrote: >> However, there is literally nothing we can do to prevent #MC from >> arriving.  We can stop servicing #MC by disabling CR4.MCE, but then the >> processor will shut down. > Hmm, there is a way to avoid #MC on other

Re: [Xen-devel] [PATCH RFC v2 07/12] x86: allow per-domain mappings without NX bit or with specific mfn

>>> On 22.01.18 at 13:32, wrote: > For support of per-vcpu stacks we need per-vcpu trampolines. To be > able to put those into the per-domain mappings the upper levels > page tables must not have NX set for per-domain mappings. > > In order to be able to reset the NX bit for a

[Xen-devel] [xen-unstable-coverity test] 118472: all pass - PUSHED

flight 118472 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/118472/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 16a31ca735165e63d67e86f60996f2b6a31cc0ee baseline version: xen

Re: [Xen-devel] Xen 4.11 Development Update

>>> On 31.01.18 at 07:57, wrote: > === x86 === > > * Enable Memory Bandwidth Allocation in Xen (v10) > - XEN-48 > - Yi Sun I think this has all gone in, the tools parts a little less than two weeks ago. Jan ___ Xen-devel

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

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

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

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

Re: [Xen-devel] Xen 4.11 Development Update

On 01/31/2018 06:57 AM, Juergen Gross wrote: This email only tracks big items for xen.git tree. Please reply for items you would like to see in 4.11 so that people have an idea what is going on and prioritise accordingly. snip> * Mitigations for SP2/CVE-2017-5715/Branch Target Injection (v7)