[Xen-devel] [PATCH v4 2/3] bitmap: import bitmap_{set/clear} from Linux 5.5

2020-02-04 Thread Roger Pau Monne
Import the functions and it's dependencies. Based on Linux 5.5, commit id d5226fa6dbae0569ee43ecfc08bdcd6770fc4755. Signed-off-by: Roger Pau Monné --- xen/common/bitmap.c | 41 xen/include/asm-x86/bitops.h | 2 ++ xen/include/xen/bitmap.h | 38 +

[Xen-devel] [PATCH v4 3/3] nvmx: always trap accesses to x2APIC MSRs

2020-02-04 Thread Roger Pau Monne
Nested VMX doesn't expose support for SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE, SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY or SECONDARY_EXEC_APIC_REGISTER_VIRT, and hence the x2APIC MSRs should always be trapped in the nested guest MSR bitmap, or else a nested guest could access the hardware x2APIC MSRs giv

[Xen-devel] [PATCH v4 1/3] nvmx: implement support for MSR bitmaps

2020-02-04 Thread Roger Pau Monne
Current implementation of nested VMX has a half baked handling of MSR bitmaps for the L1 VMM: it maps the L1 VMM provided MSR bitmap, but doesn't actually load it into the nested vmcs, and thus the nested guest vmcs ends up using the same MSR bitmap as the L1 VMM. This is wrong as there's no assur

Re: [Xen-devel] [PATCH 1/2] x86/shim: suspend and resume platform time correctly

2020-02-04 Thread Igor Druzhinin
On 04/02/2020 17:17, Roger Pau Monné wrote: > On Tue, Feb 04, 2020 at 03:40:24PM +, Igor Druzhinin wrote: >> Similarly to S3, platform time needs to be saved on guest suspend >> and restored on resume respectively. This should account for expected >> jumps in PV clock counter value after resume

[Xen-devel] [ovmf test] 146723: regressions - FAIL

2020-02-04 Thread osstest service owner
flight 146723 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/146723/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 145767 Tests which did not succee

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

2020-02-04 Thread osstest service owner
flight 146729 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/146729/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-buildfail REGR. vs. 144861 build-arm64-xsm

Re: [Xen-devel] [PATCH v2] xen/arm: Handle unimplemented VGICv3 dist registers as RAZ/WI

2020-02-04 Thread Jeff Kubascik
Hey Julien, On 2/1/2020 6:45 AM, Julien Grall wrote: > Hi, > > On 31/01/2020 20:10, Jeff Kubascik wrote: >> Per the ARM Generic Interrupt Controller Architecture Specification (ARM >> IHI 0069E), reserved registers should generally be treated as RAZ/WI. >> To simplify the VGICv3 design and improv

Re: [Xen-devel] [PATCH v3 8/8] RFC: Sketch constructors, DomainCreateNew

2020-02-04 Thread Nick Rosbrook
> But the problem I'm worried about is this: > > Scenario B > 1. Make an empty, uninitialized structure, without calling NewType() > 2. Fill in some fields > 3. Marshal it into json > 4. Marshal it out of json (with the same version) > > In the case above, step 3 encodes all the known fields with *

[Xen-devel] [PATCH v3] xen/arm: Handle unimplemented VGICv3 dist registers as RAZ/WI

2020-02-04 Thread Jeff Kubascik
Per the ARM Generic Interrupt Controller Architecture Specification (ARM IHI 0069E), reserved registers should generally be treated as RAZ/WI. To simplify the VGICv3 design and improve guest compatibility, treat the default case for GICD and GICR registers as read_as_zero/write_ignore. Signed-off-

[Xen-devel] [PATCH] libxc/restore: Fix REC_TYPE_X86_PV_VCPU_XSAVE data auditing (take 2)

2020-02-04 Thread Andrew Cooper
It turns out that a bug (since forever) in Xen causes XSAVE records to have non-architectural behaviour on xsave-capable hardware, when a PV guest has not touched the state. In such a case, the data record returned from Xen is 2*uint64_t, both claiming the (illegitimate) state of %xcr0 and %xcr0_a

Re: [Xen-devel] [PATCH 2/2] x86/time: report correct frequency of Xen PV clocksource

2020-02-04 Thread Igor Druzhinin
On 04/02/2020 17:28, Roger Pau Monné wrote: > On Tue, Feb 04, 2020 at 03:40:25PM +, Igor Druzhinin wrote: >> The value of the counter represents the number of nanoseconds >> since host boot. That means the correct frequency is always 1GHz. >> >> This inconsistency caused time to go slower in PV

Re: [Xen-devel] [PATCH 1/2] x86/shim: suspend and resume platform time correctly

2020-02-04 Thread Igor Druzhinin
On 04/02/2020 17:43, Igor Druzhinin wrote: > On 04/02/2020 17:17, Roger Pau Monné wrote: >> On Tue, Feb 04, 2020 at 03:40:24PM +, Igor Druzhinin wrote: >>> Similarly to S3, platform time needs to be saved on guest suspend >>> and restored on resume respectively. This should account for expected

[Xen-devel] [PATCH v2 1/2] x86/shim: suspend and resume platform time correctly

2020-02-04 Thread Igor Druzhinin
Similarly to S3, platform time needs to be saved on guest suspend and restored on resume respectively. This should account for expected jumps in PV clock counter value after resume. time_suspend/resume() are safe to use in PVH setting as is since any existing operations with PIT/HPET that they do w

[Xen-devel] [PATCH v2 2/2] x86/time: report correct frequency of Xen PV clocksource

2020-02-04 Thread Igor Druzhinin
The value of the counter represents the number of nanoseconds since host boot. That means the correct frequency is always 1GHz. This inconsistency caused time to go slower in PV shim on most platforms. Signed-off-by: Igor Druzhinin --- xen/arch/x86/time.c | 5 ++--- 1 file changed, 2 insertions

[Xen-devel] [PATCH v2 0/2] PV shim timekeeping fixes

2020-02-04 Thread Igor Druzhinin
Igor Druzhinin (2): x86/shim: suspend and resume platform time correctly x86/time: report correct frequency of Xen PV clocksource xen/arch/x86/pv/shim.c | 7 ++- xen/arch/x86/time.c| 17 +++-- 2 files changed, 17 insertions(+), 7 deletions(-) -- 2.7.4

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

2020-02-04 Thread osstest service owner
flight 146726 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/146726/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 146563

[Xen-devel] [linux-5.4 test] 146728: regressions - FAIL

2020-02-04 Thread osstest service owner
flight 146728 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/146728/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121 test-amd64-i386-xl

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

2020-02-04 Thread osstest service owner
flight 146731 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/146731/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-buildfail REGR. vs. 144861 build-arm64-xsm

[Xen-devel] [ovmf test] 146730: regressions - FAIL

2020-02-04 Thread osstest service owner
flight 146730 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/146730/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767 test-amd64-amd64-xl-qemuu

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

2020-02-04 Thread osstest service owner
flight 146734 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/146734/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-buildfail REGR. vs. 144861 build-arm64-xsm

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

2020-02-04 Thread osstest service owner
flight 146736 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/146736/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-buildfail REGR. vs. 144861 build-arm64-xsm

Re: [Xen-devel] PV DRM doesn't work without auto_translated_physmap feature in Dom0

2020-02-04 Thread Oleksandr Andrushchenko
On 2/4/20 10:28 AM, Santucco wrote: > Hello, > displ_be was compiled without zero-copy support early. > I have tried with the recompiled dom0 kernel, a result is the same. > Logs and configs (+displ_be’s CMakeCache.txt ) are attached. Ok, yet another test to localize the problem. Could you please r

Re: [Xen-devel] Kdump doesn't work when running with xen on newer hardware

2020-02-04 Thread Dietmar Hahn
Am Dienstag, 4. Februar 2020, 15:12:28 CET schrieb Igor Druzhinin: > On 04/02/2020 14:07, Dietmar Hahn wrote: > > Am Freitag, 31. Januar 2020, 22:59:19 CET schrieb Igor Druzhinin: > >> On 30/01/2020 13:03, Dietmar Hahn wrote: > >>> Hi, > >>> > >>> we use SLES12 with kernel-default-4.12.14-95.45.1.x

<    1   2