Re: [PATCH 0/3] Infinite loops in microcode while running guests

On 2015-11-11 14:12, Austin S Hemmelgarn wrote: > On 2015-11-11 08:07, Paolo Bonzini wrote: >> >> >> On 11/11/2015 13:47, Austin S Hemmelgarn wrote: >>> I just finished running a couple of tests in a KVM instance running >>> nested on a Xen HVM instance, and found no issues, so for the set as

Re: [PATCH 0/3] Infinite loops in microcode while running guests

On 2015-11-10 13:22, Paolo Bonzini wrote: > Yes, these can happen. The issue is that benign exceptions are > delivered serially, but two of them (#DB and #AC) can also happen > during exception delivery itself. The subsequent infinite stream > of exceptions causes the processor to never exit

Re: [PATCH v4 0/6] virtio core DMA API conversion

On 2015-11-10 03:18, Andy Lutomirski wrote: > On Mon, Nov 9, 2015 at 6:04 PM, Benjamin Herrenschmidt >> I thus go back to my original statement, it's a LOT easier to handle if >> the device itself is self describing, indicating whether it is set to >> bypass a host iommu or not. For L1->L2, well,

Re: [PATCH v4 1/2] KVM: nVMX: enhance allocate/free_vpid to handle shadow vpid

On 2015-09-16 09:19, Wanpeng Li wrote: > Enhance allocate/free_vid to handle shadow vpid. > > Signed-off-by: Wanpeng Li > --- > arch/x86/kvm/vmx.c | 23 +++ > 1 file changed, 11 insertions(+), 12 deletions(-) > > diff --git a/arch/x86/kvm/vmx.c

Re: [PATCH v3 2/2] KVM: nVMX: nested VPID emulation

ite16(VIRTUAL_PROCESSOR_ID, vmx->nested.vpid02); > + if (vmcs12->virtual_processor_id != > vmx->nested.last_vpid) { > + vmx->nested.last_vpid = > vmcs12->virtual_processor_id; > + vmx_flush_

Re: [PATCH v3 1/2] KVM: nVMX: enhance allocate/free_vpid to handle shadow vpid

On 2015-09-16 05:51, Wanpeng Li wrote: > Enhance allocate/free_vid to handle shadow vpid. > > Signed-off-by: Wanpeng Li > --- > arch/x86/kvm/vmx.c | 24 +++- > 1 file changed, 11 insertions(+), 13 deletions(-) > > diff --git a/arch/x86/kvm/vmx.c

Re: [PATCH] KVM: vmx: fix VPID is 0000H in non-root operation

On 2015-09-16 13:31, Wanpeng Li wrote: > Reference SDM 28.1: > > The current VPID is H in the following situations: > — Outside VMX operation. (This includes operation in system-management > mode under the default treatment of SMIs and SMM with VMX operation; > see Section 34.14.) > —

Re: [PATCH] KVM: nVMX: nested VPID emulation

On 2015-09-16 04:36, Wanpeng Li wrote: > On 9/16/15 1:32 AM, Jan Kiszka wrote: >> On 2015-09-15 12:14, Wanpeng Li wrote: >>> On 9/14/15 10:54 PM, Jan Kiszka wrote: >>>> Last but not least: the guest can now easily exhaust the host's pool of >>>> vpid

Re: [Qemu-devel] [PATCH 1/2] target-i386: disable LINT0 after reset

On 2015-09-15 23:19, Alex Williamson wrote: > On Mon, 2015-04-13 at 02:32 +0300, Nadav Amit wrote: >> Due to old Seabios bug, QEMU reenable LINT0 after reset. This bug is long >> gone >> and therefore this hack is no longer needed. Since it violates the >> specifications, it is removed. >> >>

Re: [PATCH] KVM: nVMX: nested VPID emulation

On 2015-09-15 12:14, Wanpeng Li wrote: > On 9/14/15 10:54 PM, Jan Kiszka wrote: >> Last but not least: the guest can now easily exhaust the host's pool of >> vpid by simply spawning plenty of VCPUs for L2, no? Is this acceptable >> or should there be some limit? > >

Re: [PATCH] KVM: nVMX: nested VPID emulation

On 2015-09-14 14:52, Wanpeng Li wrote: > VPID is used to tag address space and avoid a TLB flush. Currently L0 use > the same VPID to run L1 and all its guests. KVM flushes VPID when switching > between L1 and L2. > > This patch advertises VPID to the L1 hypervisor, then address space of L1

Re: [PATCH 00/13] arm64: Virtualization Host Extension support

On 2015-08-26 11:12, Antonios Motakis wrote: Hello Marc, On 08-Jul-15 18:19, Marc Zyngier wrote: ARMv8.1 comes with the Virtualization Host Extension (VHE for short), which enables simpler support of Type-2 hypervisors. This extension allows the kernel to directly run at EL2, and

Re: [PATCH 00/13] arm64: Virtualization Host Extension support

On 2015-08-26 11:28, Antonios Motakis wrote: On 26-Aug-15 11:21, Jan Kiszka wrote: On 2015-08-26 11:12, Antonios Motakis wrote: Hello Marc, On 08-Jul-15 18:19, Marc Zyngier wrote: ARMv8.1 comes with the Virtualization Host Extension (VHE for short), which enables simpler support of Type

Re: [PATCH v7 1/4] KVM: x86: Split the APIC from the rest of IRQCHIP.

On 2015-07-30 23:19, Steve Rutherford wrote: On Thu, Jul 30, 2015 at 11:38:20AM +0200, Paolo Bonzini wrote: On 30/07/2015 10:37, Steve Rutherford wrote: This looks a bit non-sensical, but is overprepared for the introduction IOAPIC hotplug, which two patches down the line. Changing it is

Re: [PATCH v5 3/4] KVM: x86: Add EOI exit bitmap inference

On 2015-07-29 22:27, Steve Rutherford wrote: On Wed, Jul 29, 2015 at 02:38:09PM +0200, Paolo Bonzini wrote: On 28/07/2015 01:17, Steve Rutherford wrote: diff --git a/arch/x86/kvm/ioapic.h b/arch/x86/kvm/ioapic.h index d8cc54b..f6ce112 100644 --- a/arch/x86/kvm/ioapic.h +++

Re: [RFC PATCH] KVM: arm/arm64: Don't let userspace update CNTVOFF once guest is running

On 2015-07-09 12:22, Christoffer Dall wrote: Hi Peter and Marc, [cc'ing Paolo for his input on x86 timekeeping] On Wed, Jul 08, 2015 at 08:13:59PM +0100, Peter Maydell wrote: On 8 July 2015 at 17:37, Marc Zyngier marc.zyng...@arm.com wrote: On 08/07/15 17:06, Peter Maydell wrote: I'd

Re: [PATCH] kvm/x86: add support for MONITOR_TRAP_FLAG

add my Reviewed-by: Jan Kiszka jan.kis...@siemens.com Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info

Re: [RFC PATCH] KVM: arm/arm64: Don't let userspace update CNTVOFF once guest is running

On 2015-06-25 11:25, Claudio Fontana wrote: On 25.06.2015 11:10, Peter Maydell wrote: On 25 June 2015 at 09:59, Claudio Fontana claudio.font...@huawei.com wrote: Once the VM is created, I think QEMU should not request kvm to change the virtual offset of the VM anymore: maybe an unexpected

Re: [PATCH v5] i386: Introduce ARAT CPU feature

On 2015-06-23 04:50, Wanpeng Li wrote: On 6/22/15 1:38 AM, Jan Kiszka wrote: On 2015-06-18 22:21, Eduardo Habkost wrote: On Sun, Jun 07, 2015 at 11:15:08AM +0200, Jan Kiszka wrote: From: Jan Kiszka jan.kis...@siemens.com ARAT signals that the APIC timer does not stop in power saving

Re: [PATCH v5] i386: Introduce ARAT CPU feature

On 2015-06-18 22:21, Eduardo Habkost wrote: On Sun, Jun 07, 2015 at 11:15:08AM +0200, Jan Kiszka wrote: From: Jan Kiszka jan.kis...@siemens.com ARAT signals that the APIC timer does not stop in power saving states. As our APICs are emulated, it's fine to expose this feature to guests

vfio-pci + no-kvm-irqchip = oops

Hi Alex, just tried vfio-pci with user-space irqchip (qemu-system-x86_64 -device vfio-pci,host=... -enable-kvm -no-kvm-irqchip). This ends up in the following oops: [ 61.908453] BUG: unable to handle kernel NULL pointer dereference at 0128 [ 61.908462] IP: [a0146d87]

[PATCH v5] i386: Introduce ARAT CPU feature

From: Jan Kiszka jan.kis...@siemens.com ARAT signals that the APIC timer does not stop in power saving states. As our APICs are emulated, it's fine to expose this feature to guests, at least when asking for KVM host features or with CPU types that include the flag. The exact model number

[PATCH v3] i386: Introduce ARAT CPU feature

From: Jan Kiszka jan.kis...@siemens.com ARAT signals that the APIC timer does not stop in power saving states. As our APICs are emulated, it's fine to expose this feature to guests, at least when asking for KVM host features or with CPU types that include the flag. The exact model number

[PATCH v2] i386: Introduce ARAT CPU feature

From: Jan Kiszka jan.kis...@siemens.com ARAT signals that the APIC timer does not stop in power saving states. As our APICs are emulated, it's fine to expose this feature to guests, at least when asking for KVM host features or with CPU types that include the flag. The exact model number

Re: [PATCH] KVM: x86: Allow ARAT CPU feature

On 2015-05-26 03:37, Yong Wang wrote: On Mon, May 25, 2015 at 03:24:05PM +0200, Paolo Bonzini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 24/05/2015 17:22, Jan Kiszka wrote: From: Jan Kiszka jan.kis...@siemens.com There is no reason to deny this feature to guests. We

[PATCH v3] i386: Introduce ARAT CPU feature

From: Jan Kiszka jan.kis...@siemens.com ARAT signals that the APIC timer does not stop in power saving states. As our APICs are emulated, it's fine to expose this feature to guests, at least when asking for KVM host features or with CPU types that include the flag. The exact model number

Re: [PATCH v2] KVM: SVM: Sync g_pat with guest-written PAT value

On 2015-04-21 14:21, Radim Krčmář wrote: 2015-04-21 13:09+0200, Paolo Bonzini: On 20/04/2015 19:25, Jan Kiszka wrote: When hardware supports the g_pat VMCB field, we can use it for emulating the PAT configuration that the guest configures by writing to the corresponding MSR. Signed-off

[PATCH] i386: Introduce ARAT CPU feature

From: Jan Kiszka jan.kis...@siemens.com ARAT signals that the APIC timer does not stop in power saving states. As our APICs are emulated, it's fine to expose this feature to guests, at least when asking for KVM host features or with CPU types that include the flag. The exact model number

[PATCH] KVM: x86: Allow ARAT CPU feature

From: Jan Kiszka jan.kis...@siemens.com There is no reason to deny this feature to guests. We are emulating the APIC timer, thus are exposing it without stops in power-saving states. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- arch/x86/kvm/cpuid.c | 7 ++- 1 file changed, 6

Re: Announcing qboot, a minimal x86 firmware for QEMU

On 2015-05-21 15:51, Paolo Bonzini wrote: Some of you may have heard about the Clear Containers initiative from Intel, which couple KVM with various kernel tricks to create extremely lightweight virtual machines. The experimental Clear Containers setup requires only 18-20 MB to launch a

Re: [RFC PATCH 4/4] KVM: x86: Add support for local interrupt requests from userspace

On 2015-05-14 00:41, Steve Rutherford wrote: On Wed, May 13, 2015 at 08:12:59AM +0200, Jan Kiszka wrote: On 2015-05-13 03:47, Steve Rutherford wrote: In order to enable userspace PIC support, the userspace PIC needs to be able to inject local interrupt requests. This adds the ioctl

Re: [RFC PATCH 3/4] KVM: x86: Add EOI exit bitmap inference

On 2015-05-13 11:24, Paolo Bonzini wrote: On 13/05/2015 10:10, Jan Kiszka wrote: There can even be multiple IOAPICs (thanks to your patches overcoming the single in-kernel instance). With multiple IOAPICs you have more than 24 GSIs per IOAPIC. That means I don't think that the number

Re: [RFC PATCH 3/4] KVM: x86: Add EOI exit bitmap inference

On 2015-05-13 15:04, Paolo Bonzini wrote: On 13/05/2015 12:25, Jan Kiszka wrote: But perhaps when enabling KVM_SPLIT_IRQCHIP we can use args[0] to pass the number of IOAPIC routes that will cause EOI exits? And you need to ensure that their routes can be found in the table directly

Re: [RFC PATCH 3/4] KVM: x86: Add EOI exit bitmap inference

On 2015-05-13 03:47, Steve Rutherford wrote: In order to support a userspace IOAPIC interacting with an in kernel APIC, the EOI exit bitmaps need to be configurable. If the IOAPIC is in userspace (i.e. the irqchip has been split), the EOI exit bitmaps will be set whenever the GSI Routes are

Re: [PATCH] KVM: x86: fix initial PAT value

On 2015-05-13 07:02, Wanpeng Li wrote: Hi Radim, On Mon, Apr 27, 2015 at 03:11:25PM +0200, Radim Krčmář wrote: PAT should be 0007_0406_0007_0406h on RESET and not modified on INIT. Could you point out where this value is described in SDM? :) 11.12.4 (revision from September 2014) Jan --

Re: [RFC PATCH 4/4] KVM: x86: Add support for local interrupt requests from userspace

On 2015-05-13 03:47, Steve Rutherford wrote: In order to enable userspace PIC support, the userspace PIC needs to be able to inject local interrupt requests. This adds the ioctl KVM_REQUEST_LOCAL_INTERRUPT and kvm exit KVM_EXIT_GET_EXTINT. The vm ioctl KVM_REQUEST_LOCAL_INTERRUPT makes a

Re: [RFC PATCH 3/4] KVM: x86: Add EOI exit bitmap inference

On 2015-05-13 10:04, Paolo Bonzini wrote: On 13/05/2015 08:12, Jan Kiszka wrote: +void kvm_scan_ioapic_routes(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap) +{ + struct kvm *kvm = vcpu-kvm; + struct kvm_kernel_irq_routing_entry *entry; + struct kvm_irq_routing_table *table; + u32

[ANNOUNCE] Jailhouse 0.5 released

Release often, release early -- we did quite well on the latter but there is room for improvements regarding the former. So let's do it: After its first release 0.1, we are happy to announce the new version 0.5 of the Linux-based partitioning hypervisor Jailhouse. The project made noteworthy

[PATCH] KVM: nVMX: Fix host crash when loading MSRs with userspace irqchip

vcpu-arch.apic is NULL when a userspace irqchip is active. But instead of letting the test incorrectly depend on in-kernel irqchip mode, open-code it to catch also userspace x2APICs. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- Affects kernels since 3.19. arch/x86/kvm/vmx.c | 5

[PATCH kvm-unit-tests] x86: vmx: Remove bogus GUEST_RIP update from interrupt test

When we get an EXTINT exit, the guest RIP already points to the instruction after the one that sent it into HLT state. Moving the RIP based on stale insn_len caused spurious L2 crashes. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- x86/vmx_tests.c | 4 +--- 1 file changed, 1 insertion

Re: [PATCH] KVM: nVMX: Don't return error on nested bitmap memory allocation failure

Am 2015-04-28 um 21:55 schrieb Bandan Das: If get_free_page() fails for nested bitmap area, it's evident that we are gonna get screwed anyway but returning failure because we failed allocating memory for a nested structure seems like an unnecessary big hammer. Also, save the call for later;

Re: [PATCH] KVM: nVMX: Don't return error on nested bitmap memory allocation failure

Am 2015-04-29 um 14:55 schrieb Bandan Das: Jan Kiszka jan.kis...@siemens.com writes: Am 2015-04-28 um 21:55 schrieb Bandan Das: If get_free_page() fails for nested bitmap area, it's evident that we are gonna get screwed anyway but returning failure because we failed allocating memory

Re: APIC_ID in apic_reg_write()

Am 2015-04-29 um 20:54 schrieb Bandan Das: Jan Kiszka jan.kis...@siemens.com writes: Am 2015-04-29 um 18:47 schrieb Bandan Das: Why do we allow writes to APIC_ID ? On all _newer_ processors, it's read only. The spec doesn't explicitly mention it though, or atleast I couldn't find it. Does

Re: APIC_ID in apic_reg_write()

Am 2015-04-29 um 18:47 schrieb Bandan Das: Why do we allow writes to APIC_ID ? On all _newer_ processors, it's read only. The spec doesn't explicitly mention it though, or atleast I couldn't find it. Does userspace have a reason to modify it ? The APIC ID is read-only for x2APIC. It remains

Re: APIC_ID in apic_reg_write()

Am 2015-04-30 um 00:21 schrieb Bandan Das: Jan Kiszka jan.kis...@siemens.com writes: ... And I can verify on a SandyBridge and Haswell system that it's RO there too. So the APIC just ignores the writes, it doesn't through #GP at least. In fact, that was one of the reasons I had submitted

Re: Guest handling of IA32_DEBUGCTL MSR

Am 2015-04-28 um 13:43 schrieb Paolo Bonzini: On 28/04/2015 13:42, Nadav Amit wrote: It seems strange that the guest is allowed to set IA32_DEBUGCTL MSR for the nested VM and get this value to the physical IA32_DEBUGCTL (see prepare_vmcs02), while it cannot set IA32_DEBUGCTL for itself

Re: [v6] kvm/fpu: Enable fully eager restore kvm FPU

On 2015-04-23 12:40, Paolo Bonzini wrote: On 23/04/2015 23:13, Liang Li wrote: Romove lazy FPU logic and use eager FPU entirely. Eager FPU does not have performance regression, and it can simplify the code. When compiling kernel on westmere, the performance of eager FPU is about 0.4%

Re: x-tier code injection for VMI

On 2015-04-21 15:52, Jonas Jelten wrote: Hai *! We [0] are developing x-tier [1], a VMI system that injects code into a kvm guest from the hypervisor. Currently we're using kernel modules to be executed in the context of the VM. The execution is carefully separated from the target VM so

Re: [PATCH v2] KVM: SVM: Sync g_pat with guest-written PAT value

On 2015-04-21 13:09, Paolo Bonzini wrote: On 20/04/2015 19:25, Jan Kiszka wrote: When hardware supports the g_pat VMCB field, we can use it for emulating the PAT configuration that the guest configures by writing to the corresponding MSR. Signed-off-by: Jan Kiszka jan.kis...@siemens.com

Re: [PATCH v2] KVM: SVM: Sync g_pat with guest-written PAT value

On 2015-04-21 13:32, Paolo Bonzini wrote: Basically it's an optimization. The guest can set the UC memory type on PCI BARs that are actually backed by RAM in QEMU, and then accesses to these BARs will be unnecessarily slow. It would be particularly bad if, for example, access to ivshmem were

[PATCH v2] KVM: SVM: Sync g_pat with guest-written PAT value

When hardware supports the g_pat VMCB field, we can use it for emulating the PAT configuration that the guest configures by writing to the corresponding MSR. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- Changes in v2: - add mark_dirty as found missing by Radim arch/x86/kvm/svm.c | 10

Re: [RFC][PATCH] KVM: SVM: Sync g_pat with guest-written PAT value

On 2015-04-20 19:37, Jan Kiszka wrote: On 2015-04-20 19:33, Radim Krčmář wrote: 2015-04-20 19:21+0200, Jan Kiszka: On 2015-04-20 19:16, Radim Krčmář wrote: 2015-04-20 18:14+0200, Radim Krčmář: Tested-by: Radim Krčmář rkrc...@redhat.com Uncached accesses were roughly 20x slower. In case

Re: [RFC][PATCH] KVM: SVM: Sync g_pat with guest-written PAT value

On 2015-04-20 19:33, Radim Krčmář wrote: 2015-04-20 19:21+0200, Jan Kiszka: On 2015-04-20 19:16, Radim Krčmář wrote: 2015-04-20 18:14+0200, Radim Krčmář: Tested-by: Radim Krčmář rkrc...@redhat.com Uncached accesses were roughly 20x slower. In case anyone wanted to reproduce, I used

Re: x2apic issues with Solaris and Xen guests

On 2015-04-20 19:07, Stefan Hajnoczi wrote: I wonder whether the following two x2apic issues are related: Solaris 10 U11 network doesn't work https://bugzilla.redhat.com/show_bug.cgi?id=1040500 kvm - fails to setup timer interrupt via io-apic (Thanks to Michael Tokarev for posting this

Re: [RFC][PATCH] KVM: SVM: Sync g_pat with guest-written PAT value

On 2015-04-20 19:16, Radim Krčmář wrote: 2015-04-20 18:14+0200, Radim Krčmář: Tested-by: Radim Krčmář rkrc...@redhat.com Uncached accesses were roughly 20x slower. In case anyone wanted to reproduce, I used this as a kvm-unit-test: --- #include processor.h #define NR_TOP_LOOPS 24

Re: [RFC][PATCH] KVM: SVM: Sync g_pat with guest-written PAT value

On 2015-04-20 20:33, Radim Krčmář wrote: 2015-04-20 19:45+0200, Jan Kiszka: On 2015-04-20 19:37, Jan Kiszka wrote: On 2015-04-20 19:33, Radim Krčmář wrote: 2015-04-20 19:21+0200, Jan Kiszka: On 2015-04-20 19:16, Radim Krčmář wrote: 2015-04-20 18:14+0200, Radim Krčmář: Tested-by: Radim

Re: KVM: How does is PAT emulation supposed to work?

On 2015-04-17 18:43, Radim Krčmář wrote: 2015-04-13 07:16+0200, Jan Kiszka: PS: If someone has a good idea for a simple test case on machines without IOMMU (like my current boxes), thus without a chance to use device pass-through to stress guest PAT settings, I would be all ears. Not a good

Re: [PATCH] vt-x: Preserve host CR4.MCE value while in guest mode.

On 2015-04-16 18:41, Benjamin Serebrin wrote: The host's decision to enable machine check exceptions should remain in force during non-root mode. KVM was writing 0 to cr4 on VCPU reset and passed a slightly-modified 0 to the vmcs.guest_cr4 value. Tested: Built. On earlier version, tested

Re: SVM: vmload/vmsave-free VM exits?

On 2015-04-14 08:39, Valentine Sinitsyn wrote: Hi all, On 13.04.2015 22:41, Avi Kivity wrote: On 04/13/2015 08:35 PM, Jan Kiszka wrote: On 2015-04-13 19:29, Avi Kivity wrote: On 04/13/2015 10:01 AM, Jan Kiszka wrote: On 2015-04-07 07:43, Jan Kiszka wrote: On 2015-04-05 19:12, Valentine

Re: SVM: vmload/vmsave-free VM exits?

On 2015-04-13 20:07, Avi Kivity wrote: On 04/13/2015 08:57 PM, Jan Kiszka wrote: On 2015-04-13 19:48, Avi Kivity wrote: I think that Xen does (or did) something along the lines of disabling IST usage (by playing with the descriptors in the IDT) and then re-enabling them when exiting

Re: SVM: vmload/vmsave-free VM exits?

On 2015-04-13 19:48, Avi Kivity wrote: On 04/13/2015 08:41 PM, Avi Kivity wrote: On 04/13/2015 08:35 PM, Jan Kiszka wrote: On 2015-04-13 19:29, Avi Kivity wrote: On 04/13/2015 10:01 AM, Jan Kiszka wrote: On 2015-04-07 07:43, Jan Kiszka wrote: On 2015-04-05 19:12, Valentine Sinitsyn wrote

Re: SVM: vmload/vmsave-free VM exits?

On 2015-04-13 19:29, Avi Kivity wrote: On 04/13/2015 10:01 AM, Jan Kiszka wrote: On 2015-04-07 07:43, Jan Kiszka wrote: On 2015-04-05 19:12, Valentine Sinitsyn wrote: Hi Jan, On 05.04.2015 13:31, Jan Kiszka wrote: studying the VM exit logic of Jailhouse, I was wondering when AMD's vmload

[RFC][PATCH] KVM: SVM: Sync g_pat with guest-written PAT value

When hardware supports the g_pat VMCB field, we can use it for emulating the PAT configuration that the guest configures by writing to the corresponding MSR. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- RFC because it is only compile-tested. arch/x86/kvm/svm.c | 9 + 1 file

Re: SVM: vmload/vmsave-free VM exits?

On 2015-04-07 07:43, Jan Kiszka wrote: On 2015-04-05 19:12, Valentine Sinitsyn wrote: Hi Jan, On 05.04.2015 13:31, Jan Kiszka wrote: studying the VM exit logic of Jailhouse, I was wondering when AMD's vmload/vmsave can be avoided. Jailhouse as well as KVM currently use these instructions

KVM: How does is PAT emulation supposed to work?

Hi all, while digging into the PAT topic for Jailhouse, I also wondered how KVM deals with it. And I'm still not getting it complete - or there is a bug: KVM intercepts all guest writes to the PAT MSR and instead keeps the guest value in vcpu-arch.pat. But, besides returning that value back on

Re: x86: Question regarding the reset value of LINT0

On 2015-04-08 18:59, Nadav Amit wrote: Jan Kiszka jan.kis...@siemens.com wrote: On 2015-04-08 18:40, Nadav Amit wrote: Hi, I would appreciate if someone explains the reason for enabling LINT0 during APIC reset. This does not correspond with Intel SDM Figure 10-8: “Local Vector Table

Re: x86: Question regarding the reset value of LINT0

On 2015-04-08 18:40, Nadav Amit wrote: Hi, I would appreciate if someone explains the reason for enabling LINT0 during APIC reset. This does not correspond with Intel SDM Figure 10-8: “Local Vector Table” that says all LVT registers are reset to 0x1. In kvm_lapic_reset, I see:

Re: x86: Question regarding the reset value of LINT0

On 2015-04-08 19:40, Nadav Amit wrote: Jan Kiszka jan.kis...@siemens.com wrote: On 2015-04-08 18:59, Nadav Amit wrote: Jan Kiszka jan.kis...@siemens.com wrote: On 2015-04-08 18:40, Nadav Amit wrote: Hi, I would appreciate if someone explains the reason for enabling LINT0 during APIC

Re: SVM: vmload/vmsave-free VM exits?

On 2015-04-07 08:10, Valentine Sinitsyn wrote: Hi Jan, On 07.04.2015 10:43, Jan Kiszka wrote: On 2015-04-05 19:12, Valentine Sinitsyn wrote: Hi Jan, On 05.04.2015 13:31, Jan Kiszka wrote: studying the VM exit logic of Jailhouse, I was wondering when AMD's vmload/vmsave can be avoided

Re: SVM: vmload/vmsave-free VM exits?

On 2015-04-07 08:19, Valentine Sinitsyn wrote: On 07.04.2015 11:13, Jan Kiszka wrote: It is, at least 160 cycles with hot caches on an AMD A6-5200 APU, more towards 600 if they are colder (added some usleep to each loop in the test). Great, thanks. Could you post absolute numbers, i.e how

Re: SVM: vmload/vmsave-free VM exits?

On 2015-04-07 08:29, Valentine Sinitsyn wrote: On 07.04.2015 11:23, Jan Kiszka wrote: On 2015-04-07 08:19, Valentine Sinitsyn wrote: On 07.04.2015 11:13, Jan Kiszka wrote: It is, at least 160 cycles with hot caches on an AMD A6-5200 APU, more towards 600 if they are colder (added some usleep

Re: SVM: vmload/vmsave-free VM exits?

On 2015-04-05 19:12, Valentine Sinitsyn wrote: Hi Jan, On 05.04.2015 13:31, Jan Kiszka wrote: studying the VM exit logic of Jailhouse, I was wondering when AMD's vmload/vmsave can be avoided. Jailhouse as well as KVM currently use these instructions unconditionally. However, I think both

SVM: vmload/vmsave-free VM exits?

Hi, studying the VM exit logic of Jailhouse, I was wondering when AMD's vmload/vmsave can be avoided. Jailhouse as well as KVM currently use these instructions unconditionally. However, I think both only need GS.base, i.e. the per-cpu base address, to be saved and restored if no user space exit

[PATCH] KVM: nVMX: Add support for rdtscp

From: Jan Kiszka jan.kis...@siemens.com If the guest CPU is supposed to support rdtscp and the host has rdtscp enabled in the secondary execution controls, we can also expose this feature to L1. Just extend nested_vmx_exit_handled to properly route EXIT_REASON_RDTSCP. Signed-off-by: Jan Kiszka

[PATCH v2] KVM: nVMX: Add support for rdtscp

From: Jan Kiszka jan.kis...@siemens.com If the guest CPU is supposed to support rdtscp and the host has rdtscp enabled in the secondary execution controls, we can also expose this feature to L1. Just extend nested_vmx_exit_handled to properly route EXIT_REASON_RDTSCP. Signed-off-by: Jan Kiszka

Re: [PATCH v2] KVM: nVMX: Add support for rdtscp

On 2015-03-23 18:01, Bandan Das wrote: Jan Kiszka jan.kis...@web.de writes: ... --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -2467,6 +2467,7 @@ static void nested_vmx_setup_ctls_msrs(struct vcpu_vmx *vmx) vmx-nested.nested_vmx_secondary_ctls_low = 0; vmx

[PATCH v3] KVM: nVMX: Add support for rdtscp

From: Jan Kiszka jan.kis...@siemens.com If the guest CPU is supposed to support rdtscp and the host has rdtscp enabled in the secondary execution controls, we can also expose this feature to L1. Just extend nested_vmx_exit_handled to properly route EXIT_REASON_RDTSCP. Signed-off-by: Jan Kiszka

Re: [PATCH v3 0/2] kvm: x86: Implement handling of RH=1 for MSI delivery in KVM

On 2015-03-17 02:30, James Sullivan wrote: Changes Since v1: * Reworked patches into two commits: 1) [Patch v2 1/2] Extended struct kvm_lapic_irq with bool msi_redir_hint * Initialize msi_redir_hint = true in kvm_set_msi_irq when RH=1 *

KVM emulation failure with recent kernel and QEMU Seabios

Hi, apparently since the latest QEMU updates I'm getting this once in a while: KVM internal error. Suberror: 1 emulation failure EAX= EBX= ECX= EDX=000fd2bc ESI= EDI= EBP= ESP= EIP=000fd2c5 EFL=00010007 [-PC] CPL=0 II=0 A20=1 SMM=0

Re: KVM emulation failure with recent kernel and QEMU Seabios

Am 2015-03-12 um 09:11 schrieb Gerd Hoffmann: On Do, 2015-03-12 at 09:09 +0100, Jan Kiszka wrote: Hi, apparently since the latest QEMU updates I'm getting this once in a while: http://www.seabios.org/pipermail/seabios/2015-March/008897.html OK... So we are waiting on a stable release

[PATCH kvm-unit-test] x86/emulator: Fix inline assembler warning

Code compiles to the same binary, but now with one warning less. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- x86/emulator.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x86/emulator.c b/x86/emulator.c index 0964e6a..e5c1c6b 100644 --- a/x86/emulator.c +++ b/x86

[PATCH] KVM: x86: Fix re-execution of patched vmmcall

the issue by consolidating both into the same handler. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- arch/x86/kvm/emulate.c | 17 +++-- 1 file changed, 3 insertions(+), 14 deletions(-) diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c index 106c015..c941abe 100644

[PATCH kvm-unit-test] x86: vmx: Check #UD triggering of vmmcall

KVM tends to patch and emulated vmmcall on Intel. But that must not happen for L2. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- If the recently posted fixed for KVM are applied, this test passes. x86/vmx_tests.c | 40 1 file changed, 40

[PATCH] KVM: nVMX: Do not emulate #UD while in guest mode

While in L2, leave all #UD to L2 and do not try to emulate it. If L1 is interested in doing this, it reports its interest via the exception bitmap, and we never get into handle_exception of L0 anyway. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- Noticed while wondering where the vmmcall

Re: [nVMX] With 3.20.0-0.rc0.git5.1 on L0, booting L2 guest results in L1 *rebooting*

On 2015-02-17 19:00, Bandan Das wrote: Kashyap Chamarthy kcham...@redhat.com writes: .. Does enable_apicv make a difference? Actually, I did perform a test (on Paolo's suggestion on IRC) with enable_apicv=0 on physical host, and it didn't make any difference: $ cat /proc/cmdline

Re: [nVMX] With 3.20.0-0.rc0.git5.1 on L0, booting L2 guest results in L1 *rebooting*

-nested.nested_run_pending)' \ -- ./arch/x86/kvm/vmx.c commit 5f3d5799974b89100268ba813cec8db7bd0693fb Author: Jan Kiszka jan.kis...@siemens.com Date: Sun Apr 14 12:12:46 2013 +0200 KVM: nVMX: Rework event injection and recovery The basic idea is to always transfer

Re: arm: warning at virt/kvm/arm/vgic.c:1468

On 2015-02-16 09:57, Marc Zyngier wrote: On 15/02/15 19:03, Jan Kiszka wrote: On 2015-02-15 19:01, Jan Kiszka wrote: On 2015-02-15 16:30, Marc Zyngier wrote: On Sun, Feb 15 2015 at 3:07:50 pm GMT, Jan Kiszka jan.kis...@web.de wrote: On 2015-02-15 15:59, Marc Zyngier wrote: On Sun, Feb 15

vexpress: Framebuffer broken with KVM enabled

Hi, next issue related to KVM/QEMU on the TK1: The guest image I'm running gives proper framebuffer output when in emulation mode. Once KVM is enabled, the screen is - at best - only initially updated. Sometimes I see the famous tux images and a bit of the console texts, but usually it stays

Re: vexpress: Framebuffer broken with KVM enabled

On 2015-02-16 10:20, Anup Patel wrote: On Mon, Feb 16, 2015 at 2:43 PM, Jan Kiszka jan.kis...@web.de wrote: Hi, next issue related to KVM/QEMU on the TK1: The guest image I'm running gives proper framebuffer output when in emulation mode. Once KVM is enabled, the screen is - at best - only

Re: vexpress: Framebuffer broken with KVM enabled

On 2015-02-16 10:34, Alexander Spyridakis wrote: On Mon, Feb 16, 2015 at 2:43 PM, Jan Kiszka jan.kis...@web.de wrote: Hi, next issue related to KVM/QEMU on the TK1: The guest image I'm running gives proper framebuffer output when in emulation mode. Once KVM is enabled, the screen

Re: arm: warning at virt/kvm/arm/vgic.c:1468

On 2015-02-13 07:53, Alex Bennée wrote: Alex Bennée alex.ben...@linaro.org writes: Christoffer Dall christoffer.d...@linaro.org writes: snip On Sun, Feb 08, 2015 at 08:48:09AM +0100, Jan Kiszka wrote: snip BTW, KVM tracing support on ARM seems like it requires some care. E.g.: kvm_exit

Re: arm: warning at virt/kvm/arm/vgic.c:1468

On 2015-02-15 14:37, Marc Zyngier wrote: On Sun, Feb 15 2015 at 8:53:30 am GMT, Jan Kiszka jan.kis...@web.de wrote: I'm now throwing trace_printk at my broken KVM. Already found out that I get ARM_EXCEPTION_IRQ every few 10 µs. Not seeing any irq_* traces, though. Weird. This very much

Re: arm: warning at virt/kvm/arm/vgic.c:1468

On 2015-02-15 15:59, Marc Zyngier wrote: On Sun, Feb 15 2015 at 2:40:40 pm GMT, Jan Kiszka jan.kis...@web.de wrote: On 2015-02-15 14:37, Marc Zyngier wrote: On Sun, Feb 15 2015 at 8:53:30 am GMT, Jan Kiszka jan.kis...@web.de wrote: I'm now throwing trace_printk at my broken KVM. Already

Re: arm: warning at virt/kvm/arm/vgic.c:1468

On 2015-02-15 16:30, Marc Zyngier wrote: On Sun, Feb 15 2015 at 3:07:50 pm GMT, Jan Kiszka jan.kis...@web.de wrote: On 2015-02-15 15:59, Marc Zyngier wrote: On Sun, Feb 15 2015 at 2:40:40 pm GMT, Jan Kiszka jan.kis...@web.de wrote: On 2015-02-15 14:37, Marc Zyngier wrote: On Sun, Feb 15

Re: arm: warning at virt/kvm/arm/vgic.c:1468

On 2015-02-15 16:59, Christoffer Dall wrote: On Sun, Feb 15, 2015 at 04:35:14PM +0100, Jan Kiszka wrote: On 2015-02-15 16:30, Marc Zyngier wrote: On Sun, Feb 15 2015 at 3:07:50 pm GMT, Jan Kiszka jan.kis...@web.de wrote: On 2015-02-15 15:59, Marc Zyngier wrote: On Sun, Feb 15 2015 at 2:40

Re: arm: warning at virt/kvm/arm/vgic.c:1468

On 2015-02-15 16:30, Marc Zyngier wrote: On Sun, Feb 15 2015 at 3:07:50 pm GMT, Jan Kiszka jan.kis...@web.de wrote: On 2015-02-15 15:59, Marc Zyngier wrote: On Sun, Feb 15 2015 at 2:40:40 pm GMT, Jan Kiszka jan.kis...@web.de wrote: On 2015-02-15 14:37, Marc Zyngier wrote: On Sun, Feb 15

Re: arm: warning at virt/kvm/arm/vgic.c:1468

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2015-02-15 19:01, Jan Kiszka wrote: On 2015-02-15 16:30, Marc Zyngier wrote: On Sun, Feb 15 2015 at 3:07:50 pm GMT, Jan Kiszka jan.kis...@web.de wrote: On 2015-02-15 15:59, Marc Zyngier wrote: On Sun, Feb 15 2015 at 2:40:40 pm GMT, Jan

vexpress: Horribly slow MMC emulation on ARM host

Hi, this basically concludes my problems of getting KVM running on the Jetson TK1 board with QEMU: all fine now, provided I switch from qemu-system-arm -machine vexpress-a15 -sd disk.img ... to qemu-system-arm -machine vexpress-a15 \ -drive file=disk.img,if=none,id=disk \ -device

Re: arm: warning at virt/kvm/arm/vgic.c:1468

Hi Christoffer, On 2015-02-13 05:46, Christoffer Dall wrote: Hi Jan, On Sun, Feb 08, 2015 at 08:48:09AM +0100, Jan Kiszka wrote: Hi, after fixing the VM_BUG_ON, my QEMU guest on the Jetson TK1 generally refuses to boot. Once in a while it does, but quickly gets stuck again. In one case I

Re: nSVM: Booting L2 results in L1 hang and a skip_emulated_instruction

On 2015-02-11 19:12, Kashyap Chamarthy wrote: Hi, This was tested with kernel-3.19.0-1.fc22) and QEMU (qemu-2.2.0-5.fc22) on L0 L1. Description --- Inside L1, boot a nested KVM guest (L2) . Instead of a full blown guest, let's use `qemu-sanity-check` with KVM: $

  1   2   3   4   5   6   7   8   9   10   >