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
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 gues
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, t
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.)
> — In
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 b/arch/x86/kvm/vmx.c
> index 9
PROCESSOR_ID, vmx->nested.vpid02);
> + if (vmcs12->virtual_processor_id !=
> vmx->nested.last_vpid) {
> + vmx->nested.last_vpid =
> vmcs12->virtual_processor_id;
> + vmx_flush_tlb(vcpu);
> + }
&g
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 b/arch/x86/kvm/vmx.c
> index
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.
>>
>> Sig
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
>>>> vpi
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?
>
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 and
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 "Virtual
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, a
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. Changi
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
>>> ++
STRUCTION:
> return nested_cpu_has(vmcs12, CPU_BASED_MWAIT_EXITING);
> + case EXIT_REASON_MONITOR_TRAP_FLAG:
> + return nested_cpu_has(vmcs12, CPU_BASED_MONITOR_TRAP_FLAG);
> case EXIT_REASON_MONITOR_INSTRUCTION:
> return nested_cpu_has(vmc
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 wrote:
>>> On 08/07/15 17:06, Peter Maydell wrote:
I'd prefer it
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 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
>>> consequence of QEM
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
>>>>
>>>> ARAT sign
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
>>
>> ARAT signals that the APIC timer does not stop in power saving states.
>> As our APICs are emulated, it's fine to expose this fea
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: [] kvm_irq_map_gsi+0x7c
From: Jan Kiszka
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 that introduced the featu
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
>>>
>
From: Jan Kiszka
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 that introduced the featu
From: Jan Kiszka
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 that introduced the featu
From: Jan Kiszka
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 that introduced the featu
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
From: Jan Kiszka
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
---
arch/x86/kvm/cpuid.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/x86
From: Jan Kiszka
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 that introduced the featu
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
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 requ
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?
>>>>
>>>&g
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
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
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 ma
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
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
"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 pro
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
---
x86/vmx_tests.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff
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
---
Affects kernels since 3.19.
arch/x86/kvm/vmx.c | 5 ++---
1 file changed
Am 2015-04-30 um 00:21 schrieb Bandan Das:
> Jan Kiszka 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.
>>
>>&g
Am 2015-04-29 um 20:54 schrieb Bandan Das:
> Jan Kiszka 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 i
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 remai
Am 2015-04-29 um 14:55 schrieb Bandan Das:
> Jan Kiszka 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 b
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 lat
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 it
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 ab
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 V
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 w
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.
>>
>&
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ář wrot
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ář
>>>>
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ář
>>>
>>> Uncached accesses were roughly 20x slower.
>&g
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 t
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
---
Changes in v2:
- add mark_dirty as found missing by Radim
arch/x86/kvm/svm.c | 10 ++
1 file
On 2015-04-20 19:16, Radim Krčmář wrote:
> 2015-04-20 18:14+0200, Radim Krčmář:
>> Tested-by: Radim Krčmář
>
> 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
> #define
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
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, tes
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 20
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 the
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,
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
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. Jail
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
---
RFC because it is only compile-tested.
arch/x86/kvm/svm.c | 9 +
1 file changed, 9 insertions
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
r
On 2015-04-08 19:40, Nadav Amit wrote:
> Jan Kiszka wrote:
>
>> On 2015-04-08 18:59, Nadav Amit wrote:
>>> Jan Kiszka wrote:
>>>
>>>> On 2015-04-08 18:40, Nadav Amit wrote:
>>>>> Hi,
>>>>>
>>>>> I would appr
On 2015-04-08 18:59, Nadav Amit wrote:
> Jan Kiszka 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 Inte
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:
>
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,
>&g
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).
>
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 logi
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 instruct
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 or
From: Jan Kiszka
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
---
Changes in v3
On 2015-03-23 18:01, Bandan Das wrote:
> Jan Kiszka 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_
From: Jan Kiszka
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
---
Changes in v2
From: Jan Kiszka
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
---
arch/x86/include
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
> * In
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.htm
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 HLT=0
KVM tends to patch and emulated vmmcall on Intel. But that must not
happen for L2.
Signed-off-by: Jan Kiszka
---
If the recently posted fixed for KVM are applied, this test passes.
x86/vmx_tests.c | 40
1 file changed, 40 insertions(+)
diff --git a
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
---
Noticed while wondering where the vmmcall of a misconfigured L2
issue by consolidating both into the same handler.
Signed-off-by: Jan Kiszka
---
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
--- a/arch/x86/kvm/emulate.c
Code compiles to the same binary, but now with one warning less.
Signed-off-by: Jan Kiszka
---
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/emulator.c
@@ -838,7
On 2015-02-24 17:30, Radim Krčmář wrote:
> 2015-02-23 19:05+0100, Kashyap Chamarthy:
>> Tested with the _correct_ Kernel[1] (that has Radim's patch) now --
>> applied it on both L0 and L1.
>>
>> Result: Same as before -- Booting L2 causes L1 to reboot. However, the
>> stack trace from `dmes
On 2015-02-17 19:00, Bandan Das wrote:
> Kashyap Chamarthy 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
>> BOOT_IM
9197
>9198 if ((exit_reason == EXIT_REASON_EXTERNAL_INTERRUPT)
>9199 && nested_exit_intr_ack_set(vcpu)) {
>9200 int irq = kvm_cpu_get_interrupt(vcpu);
>9201 WARN_ON(irq < 0);
>9202 vmcs12->vm_
On 2015-02-16 10:34, Alexander Spyridakis wrote:
> On Mon, Feb 16, 2015 at 2:43 PM, Jan Kiszka 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
>
On 2015-02-16 10:20, Anup Patel wrote:
> On Mon, Feb 16, 2015 at 2:43 PM, Jan Kiszka 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
>> e
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 black
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
>>>> wrote:
>>>>&g
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 vi
-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
>> wrote:
>>> On 2015-02-15 15:59, Marc Zyngier wrote:
>>>> On Sun, Feb 15
On 2015-02-15 16:30, Marc Zyngier wrote:
> On Sun, Feb 15 2015 at 3:07:50 pm GMT, Jan Kiszka wrote:
>> On 2015-02-15 15:59, Marc Zyngier wrote:
>>> On Sun, Feb 15 2015 at 2:40:40 pm GMT, Jan Kiszka
>>> wrote:
>>>> On 2015-02-15 14:37, Marc Zyngier wrot
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
>>> wrote:
>>>> On 2015-02-15 15:59, Marc Zyngier
On 2015-02-15 16:30, Marc Zyngier wrote:
> On Sun, Feb 15 2015 at 3:07:50 pm GMT, Jan Kiszka wrote:
>> On 2015-02-15 15:59, Marc Zyngier wrote:
>>> On Sun, Feb 15 2015 at 2:40:40 pm GMT, Jan Kiszka
>>> wrote:
>>>> On 2015-02-15 14:37, Marc Zyngier wrot
On 2015-02-15 15:59, Marc Zyngier wrote:
> On Sun, Feb 15 2015 at 2:40:40 pm GMT, Jan Kiszka wrote:
>> On 2015-02-15 14:37, Marc Zyngier wrote:
>>> On Sun, Feb 15 2015 at 8:53:30 am GMT, Jan Kiszka
>>> wrote:
>>>> I'm now throwing trace_print
On 2015-02-15 14:37, Marc Zyngier wrote:
> On Sun, Feb 15 2015 at 8:53:30 am GMT, Jan Kiszka 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.
>
On 2015-02-13 07:53, Alex Bennée wrote:
>
> Alex Bennée writes:
>
>> Christoffer Dall writes:
>
>>> On Sun, Feb 08, 2015 at 08:48:09AM +0100, Jan Kiszka wrote:
>
>>>> BTW, KVM tracing support on ARM seems like it requires some care. E.g.:
>>&g
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 d
1 - 100 of 4875 matches
Mail list logo
