Re: [Xen-devel] [PATCH v2 09/17] arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler

On 27/03/18 10:07, Manish Jaggi wrote: > This patch is ported from linux to xen > commit: 2724c11a1df4b22ee966c04809ea0e808f66b04e > (KVM: arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler) > > Add a handler for reading the guest's view of the ICV_HPPIR1_EL1 > register. This is a simple parsing of the

Re: [Xen-devel] [PATCH v2 02/17] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

On 27/03/18 11:35, Manish Jaggi wrote: > > > On 03/27/2018 04:00 PM, Marc Zyngier wrote: >> On 27/03/18 10:07, Manish Jaggi wrote: >>> This patch is ported to xen from linux commit >>> d70c7b31a60f2458f35c226131f2a01a7a98b6cf >>> KVM: arm64: vgic-v3: Add ICV_BPR1_EL1 handler >>> >>> Add a

Re: [Xen-devel] [PATCH v2 02/17] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

On 03/27/2018 04:00 PM, Marc Zyngier wrote: On 27/03/18 10:07, Manish Jaggi wrote: This patch is ported to xen from linux commit d70c7b31a60f2458f35c226131f2a01a7a98b6cf KVM: arm64: vgic-v3: Add ICV_BPR1_EL1 handler Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1

Re: [Xen-devel] [RFC 4/4] HACK libxl_exec: Check QEMU status via QMP instead of xenstore

Anthony PERARD writes ("[RFC 4/4] HACK libxl_exec: Check QEMU status via QMP instead of xenstore"): > This path is more of a prof of concept reather than a patch as this > would break qemu-trad. ... > For libxl, the only way to find out if qemu is ready on migrate/restore, > it is to connect to

Re: [Xen-devel] [PATCH v2 02/17] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

On 27/03/18 10:07, Manish Jaggi wrote: > This patch is ported to xen from linux commit > d70c7b31a60f2458f35c226131f2a01a7a98b6cf > KVM: arm64: vgic-v3: Add ICV_BPR1_EL1 handler > > Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1 > register, which is located in the

Re: [Xen-devel] [RFC 1/4] libxl: Learned to send FD through QMP to QEMU

(George, CC'ing you wrt your depriv doc patch - see below.) Anthony PERARD writes ("[RFC 1/4] libxl: Learned to send FD through QMP to QEMU"): > Adding the ability to send a file descriptor from libxl to QEMU via the > QMP interface. This will be use with the "add-fd" QMP command. The code

Re: [Xen-devel] [PATCH v2 01/17] arm: Placeholder for handling Group0/1 traps

On 27/03/18 11:10, Manish Jaggi wrote: > > > On 03/27/2018 03:31 PM, Marc Zyngier wrote: >> On 27/03/18 10:07, Manish Jaggi wrote: >>> The errata will require to emulate the GIC virtual CPU interface in Xen. >>> Because the hypervisor will update its internal state of the vGIC, we want >>> to

Re: [Xen-devel] [PATCH] docs/qemu-deprivilege: Revise and update with status and future plans

On 03/26/2018 05:43 PM, Ian Jackson wrote: > Thanks for this update! > > George Dunlap writes ("[PATCH] docs/qemu-deprivilege: Revise and update with > status and future plans"): > ... >> +# Technical details >> + >> +## Restrictions done > > This makes this doc into a mixture of a design doc

Re: [Xen-devel] [PATCH] docs/qemu-deprivilege: Revise and update with status and future plans

On 03/26/2018 05:43 PM, Ian Jackson wrote: >> +### Network >> >> +If QEMU runs in its own network namespace, it can't open the tap >> +device itself because the interface won't be visible outside of its >> +own namespace. So instead, have the toolstack open the device and pass >> +it as an fd on

Re: [Xen-devel] [PATCH v2 07/17] arm64: vgic-v3: Add ICV_EOIR1_EL1 handler

On 27/03/18 10:07, Manish Jaggi wrote: > This patch is ported to xen from linux commit > b6f49035b4bf6e2709f2a5fed3107f5438c1fd02 > KVM: arm64: vgic-v3: Add ICV_EOIR1_EL1 handler > > Add a handler for writing the guest's view of the ICC_EOIR1_EL1 > register. This involves dropping the priority of

Re: [Xen-devel] [PATCH v2 01/17] arm: Placeholder for handling Group0/1 traps

On 03/27/2018 03:31 PM, Marc Zyngier wrote: On 27/03/18 10:07, Manish Jaggi wrote: The errata will require to emulate the GIC virtual CPU interface in Xen. Because the hypervisor will update its internal state of the vGIC, we want to avoid messing up with it. So the errata is handled

Re: [Xen-devel] [PATCH v3] drm/xen-front: Add support for Xen PV display frontend

On 03/27/2018 12:50 PM, Daniel Vetter wrote: On Tue, Mar 27, 2018 at 11:34 AM, Oleksandr Andrushchenko wrote: Hi, Daniel! On 03/26/2018 03:46 PM, Oleksandr Andrushchenko wrote: On 03/26/2018 11:18 AM, Daniel Vetter wrote: On Fri, Mar 23, 2018 at 05:54:49PM +0200,

[Xen-devel] [rumprun test] 121295: regressions - FAIL

flight 121295 rumprun real [real] http://logs.test-lab.xenproject.org/osstest/logs/121295/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumprun 6 rumprun-buildfail REGR. vs. 106754 build-i386-rumprun

Re: [Xen-devel] [PATCH v2 01/17] arm: Placeholder for handling Group0/1 traps

On 27/03/18 10:07, Manish Jaggi wrote: > The errata will require to emulate the GIC virtual CPU interface in Xen. > Because the hypervisor will update its internal state of the vGIC, we want > to avoid messing up with it. So the errata is handled separately from the > rest of the hypervisor. > >

Re: [Xen-devel] [PATCH v3] drm/xen-front: Add support for Xen PV display frontend

On Tue, Mar 27, 2018 at 11:34 AM, Oleksandr Andrushchenko wrote: > Hi, Daniel! > > > On 03/26/2018 03:46 PM, Oleksandr Andrushchenko wrote: >> >> On 03/26/2018 11:18 AM, Daniel Vetter wrote: >>> >>> On Fri, Mar 23, 2018 at 05:54:49PM +0200, Oleksandr Andrushchenko wrote: >

Re: [Xen-devel] [PATCH v2] xen-pvdevice: Introduce a simplistic xen-pvdevice save state

On Tue, Mar 13, 2018 at 11:14:54PM +, Igor Druzhinin wrote: > This should help to avoid problems with accessing the device after > migration/resume without PV drivers by migrating its PCI configuration > space state. Without an explicitly defined state record it resets > every time a VM

Re: [Xen-devel] [PATCH v3] drm/xen-front: Add support for Xen PV display frontend

Hi, Daniel! On 03/26/2018 03:46 PM, Oleksandr Andrushchenko wrote: On 03/26/2018 11:18 AM, Daniel Vetter wrote: On Fri, Mar 23, 2018 at 05:54:49PM +0200, Oleksandr Andrushchenko wrote: My apologies, but I found a few more things that look strange and should be cleaned up. Sorry for this

[Xen-devel] [PATCH v5] new config option vtsc_tolerance_khz to avoid TSC emulation

Add an option to control when vTSC emulation will be activated for a domU with tsc_mode=default. Without such option each TSC access from domU will be emulated, which causes a significant perfomance drop for workloads that make use of rdtsc. One option to avoid the TSC option is to run domUs with

[Xen-devel] [PATCH v2 17/17] arm64: if trapping a read-from-write-only GICv3 access inject undef exception in guest

This patch is ported to xen from linux commit: e7f1d1eef482150a64a6e6ad8faf40f8f97eed67 KVM: arm64: Log an error if trapping a read-from-write-only GICv3 access A read-from-write-only GICv3 access should UNDEF at EL1. But since we're in complete paranoia-land with broken CPUs, let's assume the

[Xen-devel] [PATCH v2 14/17] arm64: Add config for Cavium Thunder erratum 30115

Some Cavium Thunder CPUs suffer a problem where a Xen guest may inadvertently cause the host kernel to quit receiving interrupts. This patch adds CONFIG_CAVIUM_ERRATUM_30115. Subsequent patches will provide workaround. This patch is ported to xen from linux kernel commit:

[Xen-devel] [PATCH v2 08/17] arm64: vgic-v3: Add ICV_AP1Rn_EL1 handler

This patch is a xen port of linux commit f9e7449c780f688bf61a13dfa8c344afeb4ad6e0 KVM: arm64: vgic-v3: Add ICV_AP1Rn_EL1 handler Add a handler for reading/writing the guest's view of the ICV_AP1Rn_EL1 registers. We just map them to the corresponding ICH_AP1Rn_EL2 registers. This patch calls

[Xen-devel] [PATCH v2 09/17] arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler

This patch is ported from linux to xen commit: 2724c11a1df4b22ee966c04809ea0e808f66b04e (KVM: arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler) Add a handler for reading the guest's view of the ICV_HPPIR1_EL1 register. This is a simple parsing of the available LRs, extracting the highest available

[Xen-devel] [PATCH v2 16/17] arm64: if trapping a write-to-read-only GICv3 access inject Undef exception in guest

This patch is a port to xen from linux commit: 7b1dba1f7325629427c0e5bdf014159b229d16c8 KVM: arm64: Log an error if trapping a write-to-read-only GICv3 access A write-to-read-only GICv3 access should UNDEF at EL1. But since we're in complete paranoia-land with broken CPUs, let's assume the worse

[Xen-devel] [PATCH v2 12/17] arm64: vgic-v3: Add misc Group-0 handlers

This patch is ported to xen from linux commit: eab0b2dc4f6f34147e3d10da49ab8032e15dbea0 (KVM: arm64: vgic-v3: Add misc Group-0 handlers) A number of Group-0 registers can be handled by the same accessors as that of Group-1, so let's add the required system register encodings and catch them in the

[Xen-devel] [PATCH v2 13/17] arm64: cputype: Add MIDR values for Cavium ThunderX1 CPU family

Add MIDR values for Cavium ThunderX1 SoC family: ThunderX1, 81XX, 83XX. This patch copies the below defines as is from linux kernel code. arch/arm64/include/asm/cputype.h Signed-off-by: Manish Jaggi --- xen/include/asm-arm/processor.h | 9 + 1 file changed, 9

[Xen-devel] [PATCH v2 15/17] arm: Hook workaround handler from traps.c based on Cavium workaround_30115

Function vgic_v3_handle_cpuif_access is called from do_trap_guest_sync if ARM64_WORKAROUND_CAVIUM_30115 capability is found. A flag skip_hyp_tail is introduced in struct cpu_info. This flag is used to skip leave_hypervisor_tail when enter_hypervisor_head is not invoked. enter_hypervisor_head

[Xen-devel] [PATCH v2 10/17] arm64: vgic-v3: Add ICV_BPR0_EL1 handler

This patch is ported to xen from linux commit: 423de85a98c2b50715a0784a74f6124fbc0b1548 (KVM: arm64: vgic-v3: Add ICV_BPR0_EL1 handler) Add a handler for reading/writing the guest's view of the ICC_BPR0_EL1 register, which is located in the ICH_VMCR_EL2.BPR0 field. Signed-off-by: Manish Jaggi

[Xen-devel] [PATCH v2 11/17] arm64: vgic-v3: Add ICV_IGRPEN0_EL1 handler

This patch is ported to xen from linux commit: fbc48a0011deb3d51cb657ca9c0f9083f41c0665 (KVM: arm64: vgic-v3: Add ICV_IGNREN0_EL1 handler) Add a handler for reading/writing the guest's view of the ICC_IGRPEN0_EL1 register, which is located in the ICH_VMCR_EL2.VENG0 field. Signed-off-by: Manish

[Xen-devel] [PATCH v2 03/17] arm64: vgic-v3: Add ICV_IGRPEN1_EL1 handler

This patch is ported to xen from linux commit: f8b630bc542e0368886ae193d3519c832b270359 KVM: arm64: vgic-v3: Add ICV_IGRPEN1_EL1 handler Add a handler for reading/writing the guest's view of ICC_IGRPEN1_EL1 register, which is located in the ICH_VMCR_EL2.VENG1 field. Signed-off-by: Manish Jaggi

[Xen-devel] [PATCH v2 04/17] arm64: Add accessors for the ICH_APxRn_EL2 registers

This patch is ported to xen from linux commit 63000dd8006dc987db31ba670edc23142ea91e01 KVM: arm/arm64: vgic-v3: Add accessors for the ICH_APxRn_EL2 registers As we're about to access the Active Priority registers a lot more, let's define accessors that take the register number as a parameter.

[Xen-devel] [PATCH v2 01/17] arm: Placeholder for handling Group0/1 traps

The errata will require to emulate the GIC virtual CPU interface in Xen. Because the hypervisor will update its internal state of the vGIC, we want to avoid messing up with it. So the errata is handled separately from the rest of the hypervisor. New file vgic-v3-sr.c is added which will hold

[Xen-devel] [PATCH v2 07/17] arm64: vgic-v3: Add ICV_EOIR1_EL1 handler

This patch is ported to xen from linux commit b6f49035b4bf6e2709f2a5fed3107f5438c1fd02 KVM: arm64: vgic-v3: Add ICV_EOIR1_EL1 handler Add a handler for writing the guest's view of the ICC_EOIR1_EL1 register. This involves dropping the priority of the interrupt, and deactivating it if required

[Xen-devel] [PATCH v2 00/17] arm64: Mediate access to GICv3 sysregs at EL2

This patchset is based on Marc's patchset below. arm64: KVM: Mediate access to GICv3 sysregs at EL2 [1]. As these patches are ported to xen specifically for cavium errata 30115 few changes are made: - Xen coding style is used - group1_enable / group0_enable command line options not used.

[Xen-devel] [PATCH v2 02/17] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

This patch is ported to xen from linux commit d70c7b31a60f2458f35c226131f2a01a7a98b6cf KVM: arm64: vgic-v3: Add ICV_BPR1_EL1 handler Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1 register, which is located in the ICH_VMCR_EL2.BPR1 field. Signed-off-by: Manish Jaggi

[Xen-devel] [PATCH v2 06/17] arm64: Add ICV_IAR1_EL1 handler

This patch is ported to xen from linux commit 132a324ab62fe4fb8d6dcc2ab4eddb0e93b69afe. KVM: arm64: vgic-v3: Add ICV_IAR1_EL1 handler Add a handler for reading the guest's view of the ICC_IAR1_EL1 register. This involves finding the highest priority Group-1 interrupt, checking against both PMR

[Xen-devel] [PATCH v2 05/17] Expose ich_read/write_lr in vgic-v3-sr.c

gicv3_ich_read/write_lr functions are duplicated in vgic-v3-sr.c This is done to make the file independent of the xen vgic code for handling the errata. Both the functions in the patch are static, so this patch needs subsequent patches to compile without error (unused function) Signed-off-by:

[Xen-devel] [PATCH v4 2/7] x86/xpti: don't flush TLB twice when switching to 64-bit pv context

When switching to a 64-bit pv context the TLB is flushed twice today: the first time when switching to the new address space in write_ptbase(), the second time when switching to guest mode in restore_to_guest. Avoid the first TLB flush in that case. Signed-off-by: Juergen Gross

[Xen-devel] [PATCH v4 0/7] xen/x86: various XPTI speedups

This patch series aims at reducing the overhead of the XPTI Meltdown mitigation. It is based on Jan's XPTI speedup series. Patch 1 had been posted before, the main changes in this patch are due to addressing Jan's comments on my first version. The main objective of that patch is to avoid copying

[Xen-devel] [PATCH v4 5/7] xen/x86: disable global pages for domains with XPTI active

Instead of flushing the TLB from global pages when switching address spaces with XPTI being active just disable global pages via %cr4 completely when a domain subject to XPTI is active. This avoids the need for extra TLB flushes as loading %cr3 will remove all TLB entries. In order to avoid

[Xen-devel] [PATCH v4 3/7] xen/x86: support per-domain flag for xpti

Instead of switching XPTI globally on or off add a per-domain flag for that purpose. This allows to modify the xpti boot parameter to support running dom0 without Meltdown mitigations. Using "xpti=nodom0" as boot parameter will achieve that. Move the xpti boot parameter handling to

[Xen-devel] [PATCH v4 6/7] xen/x86: use flag byte for decision whether xen_cr3 is valid

Today cpu_info->xen_cr3 is either 0 to indicate %cr3 doesn't need to be switched on entry to Xen, or negative for keeping the value while indicating not to restore %cr3, or positive in case %cr3 is to be restored. Switch to use a flag byte instead of a negative xen_cr3 value in order to allow

[Xen-devel] [PATCH v4 1/7] x86/xpti: avoid copying L4 page table contents when possible

For mitigation of Meltdown the current L4 page table is copied to the cpu local root page table each time a 64 bit pv guest is entered. Copying can be avoided in cases where the guest L4 page table hasn't been modified while running the hypervisor, e.g. when handling interrupts or any hypercall

[Xen-devel] [PATCH v4 4/7] xen/x86: use invpcid for flushing the TLB

If possible use the INVPCID instruction for flushing the TLB instead of toggling cr4.pge for that purpose. While at it remove the dependency on cr4.pge being required for mtrr loading, as this will be required later anyway. Add a command line option "invpcid" for controlling the use of INVPCID

[Xen-devel] [PATCH v4 7/7] xen/x86: use PCID feature

Avoid flushing the complete TLB when switching %cr3 for mitigation of Meltdown by using the PCID feature if available. We are using 4 PCID values for a 64 bit pv domain subject to XPTI and 2 values for the non-XPTI case: - guest active and in kernel mode - guest active and in user mode -

Re: [Xen-devel] [PATCH v3 5/7] xen/x86: disable global pages for domains with XPTI active

>>> On 27.03.18 at 10:44, wrote: > On 27/03/18 10:33, Jan Beulich wrote: > On 27.03.18 at 09:37, wrote: >>> On 27/03/18 09:23, Jan Beulich wrote: >>> On 27.03.18 at 09:14, wrote: > I just realized that using read_cr4() | X86_CR4_PGE

Re: [Xen-devel] [PATCH v2] x86/boot: Disable IBRS in intr/nmi exit path at bootup stage

>>> On 27.03.18 at 06:52, wrote: > After reset, IBRS is disabled by processor, but a coming intr/nmi leave IBRS > enabled after their exit. It's not necessory for bootup code to run in low > performance with IBRS enabled. > > On ORACLE X6-2(500GB/88 cpus, dom0 11GB/20

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Tue, Mar 27, 2018 at 05:42:11AM +1000, Alexey G wrote: > On Mon, 26 Mar 2018 10:24:38 +0100 > Roger Pau Monné wrote: > > >On Sat, Mar 24, 2018 at 08:32:44AM +1000, Alexey G wrote: > [...] > >> In fact, the emulated chipset (NB+SB combo without supplemental > >> devices)

[Xen-devel] [xen-4.6-testing test] 121278: regressions - FAIL

flight 121278 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/121278/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 119227 Tests

Re: [Xen-devel] [PATCH v3 5/7] xen/x86: disable global pages for domains with XPTI active

On 27/03/18 10:33, Jan Beulich wrote: On 27.03.18 at 09:37, wrote: >> On 27/03/18 09:23, Jan Beulich wrote: >> On 27.03.18 at 09:14, wrote: On 22/03/18 17:30, Jan Beulich wrote: On 21.03.18 at 13:51, wrote: >> Instead

Re: [Xen-devel] [PATCH v3 5/7] xen/x86: disable global pages for domains with XPTI active

>>> On 27.03.18 at 09:37, wrote: > On 27/03/18 09:23, Jan Beulich wrote: > On 27.03.18 at 09:14, wrote: >>> On 22/03/18 17:30, Jan Beulich wrote: >>> On 21.03.18 at 13:51, wrote: > Instead of flushing the TLB from global pages when

Re: [Xen-devel] [PATCH v2 for-4.11 2/2] vpci: make sure handlers can deal with size == 0

>>> On 26.03.18 at 18:32, wrote: > The code is not prepared to handle such case, so just return early. In > the debug case add an assert. > > Reported-by: Coverity > Coverity ID: 1430809 > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich

Re: [Xen-devel] [PATCH v3 5/7] xen/x86: disable global pages for domains with XPTI active

On 27/03/18 09:23, Jan Beulich wrote: On 27.03.18 at 09:14, wrote: >> On 22/03/18 17:30, Jan Beulich wrote: >> On 21.03.18 at 13:51, wrote: Instead of flushing the TLB from global pages when switching address spaces with XPTI being active just

Re: [Xen-devel] [PATCH v3 5/7] xen/x86: disable global pages for domains with XPTI active

>>> On 27.03.18 at 09:14, wrote: > On 22/03/18 17:30, Jan Beulich wrote: > On 21.03.18 at 13:51, wrote: >>> Instead of flushing the TLB from global pages when switching address >>> spaces with XPTI being active just disable global pages via %cr4 >>>

Re: [Xen-devel] [PATCH v3 5/7] xen/x86: disable global pages for domains with XPTI active

On 22/03/18 17:30, Jan Beulich wrote: On 21.03.18 at 13:51, wrote: >> Instead of flushing the TLB from global pages when switching address >> spaces with XPTI being active just disable global pages via %cr4 >> completely when a domain subject to XPTI is active. This avoids

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

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

<    1   2