* [PATCH] KVM: nVMX: VMX instructions: fix segment checks when L1 is in long mode.
@ 2016-06-18 9:01 Quentin Casasnovas
2016-06-23 16:03 ` Paolo Bonzini
0 siblings, 1 reply; 6+ messages in thread
From: Quentin Casasnovas @ 2016-06-18 9:01 UTC (permalink / raw)
To: Paolo Bonzini, x86, kvm, lkml
Cc: Quentin Casasnovas, Eugene Korenevsky,
Radim Krčmář,
Thomas Gleixner, Ingo Molnar, H . Peter Anvin, linux-stable
I couldn't get Xen to boot a L2 HVM when it was nested under KVM - it was
getting a GP(0) on a rather unspecial vmread from Xen:
(XEN) ----[ Xen-4.7.0-rc x86_64 debug=n Not tainted ]----
(XEN) CPU: 1
(XEN) RIP: e008:[<ffff82d0801e629e>] vmx_get_segment_register+0x14e/0x450
(XEN) RFLAGS: 0000000000010202 CONTEXT: hypervisor (d1v0)
(XEN) rax: ffff82d0801e6288 rbx: ffff83003ffbfb7c rcx: fffffffffffab928
(XEN) rdx: 0000000000000000 rsi: 0000000000000000 rdi: ffff83000bdd0000
(XEN) rbp: ffff83000bdd0000 rsp: ffff83003ffbfab0 r8: ffff830038813910
(XEN) r9: ffff83003faf3958 r10: 0000000a3b9f7640 r11: ffff83003f82d418
(XEN) r12: 0000000000000000 r13: ffff83003ffbffff r14: 0000000000004802
(XEN) r15: 0000000000000008 cr0: 0000000080050033 cr4: 00000000001526e0
(XEN) cr3: 000000003fc79000 cr2: 0000000000000000
(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008
(XEN) Xen code around <ffff82d0801e629e> (vmx_get_segment_register+0x14e/0x450):
(XEN) 00 00 41 be 02 48 00 00 <44> 0f 78 74 24 08 0f 86 38 56 00 00 b8 08 68 00
(XEN) Xen stack trace from rsp=ffff83003ffbfab0:
...
(XEN) Xen call trace:
(XEN) [<ffff82d0801e629e>] vmx_get_segment_register+0x14e/0x450
(XEN) [<ffff82d0801f3695>] get_page_from_gfn_p2m+0x165/0x300
(XEN) [<ffff82d0801bfe32>] hvmemul_get_seg_reg+0x52/0x60
(XEN) [<ffff82d0801bfe93>] hvm_emulate_prepare+0x53/0x70
(XEN) [<ffff82d0801ccacb>] handle_mmio+0x2b/0xd0
(XEN) [<ffff82d0801be591>] emulate.c#_hvm_emulate_one+0x111/0x2c0
(XEN) [<ffff82d0801cd6a4>] handle_hvm_io_completion+0x274/0x2a0
(XEN) [<ffff82d0801f334a>] __get_gfn_type_access+0xfa/0x270
(XEN) [<ffff82d08012f3bb>] timer.c#add_entry+0x4b/0xb0
(XEN) [<ffff82d08012f80c>] timer.c#remove_entry+0x7c/0x90
(XEN) [<ffff82d0801c8433>] hvm_do_resume+0x23/0x140
(XEN) [<ffff82d0801e4fe7>] vmx_do_resume+0xa7/0x140
(XEN) [<ffff82d080164aeb>] context_switch+0x13b/0xe40
(XEN) [<ffff82d080128e6e>] schedule.c#schedule+0x22e/0x570
(XEN) [<ffff82d08012c0cc>] softirq.c#__do_softirq+0x5c/0x90
(XEN) [<ffff82d0801602c5>] domain.c#idle_loop+0x25/0x50
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 1:
(XEN) GENERAL PROTECTION FAULT
(XEN) [error_code=0000]
(XEN) ****************************************
Tracing my host KVM showed it was the one injecting the GP(0) when
emulating the VMREAD and checking the destination segment permissions in
get_vmx_mem_address():
3) | vmx_handle_exit() {
3) | handle_vmread() {
3) | nested_vmx_check_permission() {
3) | vmx_get_segment() {
3) 0.074 us | vmx_read_guest_seg_base();
3) 0.065 us | vmx_read_guest_seg_selector();
3) 0.066 us | vmx_read_guest_seg_ar();
3) 1.636 us | }
3) 0.058 us | vmx_get_rflags();
3) 0.062 us | vmx_read_guest_seg_ar();
3) 3.469 us | }
3) | vmx_get_cs_db_l_bits() {
3) 0.058 us | vmx_read_guest_seg_ar();
3) 0.662 us | }
3) | get_vmx_mem_address() {
3) 0.068 us | vmx_cache_reg();
3) | vmx_get_segment() {
3) 0.074 us | vmx_read_guest_seg_base();
3) 0.068 us | vmx_read_guest_seg_selector();
3) 0.071 us | vmx_read_guest_seg_ar();
3) 1.756 us | }
3) | kvm_queue_exception_e() {
3) 0.066 us | kvm_multiple_exception();
3) 0.684 us | }
3) 4.085 us | }
3) 9.833 us | }
3) + 10.366 us | }
Cross-checking the KVM/VMX VMREAD emulation code with the Intel Software
Developper Manual Volume 3C - "VMREAD - Read Field from Virtual-Machine
Control Structure", I found that we're enforcing that the destination
operand is NOT located in a read-only data segment or any code segment when
the L1 is in long mode - BUT that check should only happen when it is in
protected mode.
Shuffling the code a bit to make our emulation follow the specification
allows me to boot a Xen dom0 in a nested KVM and start HVM L2 guests
without problems.
This fix is needed from 4.2 onward or if
f9eb4af67c9d ("KVM: nVMX: VMX instructions: add checks for #GP/#SS exceptions")
has been back-ported.
Fixes: f9eb4af67c9d ("KVM: nVMX: VMX instructions: add checks for #GP/#SS exceptions")
Signed-off-by: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Cc: Eugene Korenevsky <ekorenevsky@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: linux-stable <stable@vger.kernel.org>
---
arch/x86/kvm/vmx.c | 22 ++++++++++------------
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 133679d..bdd2dce 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -6657,7 +6657,12 @@ static int get_vmx_mem_address(struct kvm_vcpu *vcpu,
/* Checks for #GP/#SS exceptions. */
exn = false;
- if (is_protmode(vcpu)) {
+ if (is_long_mode(vcpu)) {
+ /* Long mode: #GP(0)/#SS(0) if the memory address is in a
+ * non-canonical form. This is an only check for long mode.
+ */
+ exn = is_noncanonical_address(*ret);
+ } else if (is_protmode(vcpu)) {
/* Protected mode: apply checks for segment validity in the
* following order:
* - segment type check (#GP(0) may be thrown)
@@ -6674,17 +6679,10 @@ static int get_vmx_mem_address(struct kvm_vcpu *vcpu,
* execute-only code segment
*/
exn = ((s.type & 0xa) == 8);
- }
- if (exn) {
- kvm_queue_exception_e(vcpu, GP_VECTOR, 0);
- return 1;
- }
- if (is_long_mode(vcpu)) {
- /* Long mode: #GP(0)/#SS(0) if the memory address is in a
- * non-canonical form. This is an only check for long mode.
- */
- exn = is_noncanonical_address(*ret);
- } else if (is_protmode(vcpu)) {
+ if (exn) {
+ kvm_queue_exception_e(vcpu, GP_VECTOR, 0);
+ return 1;
+ }
/* Protected mode: #GP(0)/#SS(0) if the segment is unusable.
*/
exn = (s.unusable != 0);
--
2.8.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] KVM: nVMX: VMX instructions: fix segment checks when L1 is in long mode.
2016-06-18 9:01 [PATCH] KVM: nVMX: VMX instructions: fix segment checks when L1 is in long mode Quentin Casasnovas
@ 2016-06-23 16:03 ` Paolo Bonzini
2016-06-24 13:04 ` Quentin Casasnovas
0 siblings, 1 reply; 6+ messages in thread
From: Paolo Bonzini @ 2016-06-23 16:03 UTC (permalink / raw)
To: Quentin Casasnovas, x86, kvm, lkml
Cc: Eugene Korenevsky, Radim Krčmář,
Thomas Gleixner, Ingo Molnar, H . Peter Anvin, linux-stable
On 18/06/2016 11:01, Quentin Casasnovas wrote:
> Cross-checking the KVM/VMX VMREAD emulation code with the Intel Software
> Developper Manual Volume 3C - "VMREAD - Read Field from Virtual-Machine
> Control Structure", I found that we're enforcing that the destination
> operand is NOT located in a read-only data segment or any code segment when
> the L1 is in long mode - BUT that check should only happen when it is in
> protected mode.
>
> Shuffling the code a bit to make our emulation follow the specification
> allows me to boot a Xen dom0 in a nested KVM and start HVM L2 guests
> without problems.
That's great, and I'm applying the patch, but it's also pretty weird. :)
Do you have a pointer to Xen source code that does a VMREAD into a
read-only data segment or a code segment?
Thanks,
Paolo
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] KVM: nVMX: VMX instructions: fix segment checks when L1 is in long mode.
2016-06-23 16:03 ` Paolo Bonzini
@ 2016-06-24 13:04 ` Quentin Casasnovas
2016-06-24 13:10 ` Paolo Bonzini
0 siblings, 1 reply; 6+ messages in thread
From: Quentin Casasnovas @ 2016-06-24 13:04 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Quentin Casasnovas, x86, kvm, lkml, Eugene Korenevsky,
Radim Krčmář,
Thomas Gleixner, Ingo Molnar, H . Peter Anvin, linux-stable
On Thu, Jun 23, 2016 at 06:03:01PM +0200, Paolo Bonzini wrote:
>
>
> On 18/06/2016 11:01, Quentin Casasnovas wrote:
> > Cross-checking the KVM/VMX VMREAD emulation code with the Intel Software
> > Developper Manual Volume 3C - "VMREAD - Read Field from Virtual-Machine
> > Control Structure", I found that we're enforcing that the destination
> > operand is NOT located in a read-only data segment or any code segment when
> > the L1 is in long mode - BUT that check should only happen when it is in
> > protected mode.
> >
> > Shuffling the code a bit to make our emulation follow the specification
> > allows me to boot a Xen dom0 in a nested KVM and start HVM L2 guests
> > without problems.
>
> That's great, and I'm applying the patch, but it's also pretty weird. :)
> Do you have a pointer to Xen source code that does a VMREAD into a
> read-only data segment or a code segment?
It is indeed pretty weird. Looking at the Xen stack trace, it looks like
the vmread is writing to an on-stack buffer, and surely it must be writable
so I wonder if Xen might not be using an executable stack for some reason?
That would be a bit scary so I'm surely missing something.
Is there an easy way to know from my KVM host the different segment
permission setup by the guest?
Quentin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] KVM: nVMX: VMX instructions: fix segment checks when L1 is in long mode.
2016-06-24 13:04 ` Quentin Casasnovas
@ 2016-06-24 13:10 ` Paolo Bonzini
2016-06-29 17:25 ` Quentin Casasnovas
0 siblings, 1 reply; 6+ messages in thread
From: Paolo Bonzini @ 2016-06-24 13:10 UTC (permalink / raw)
To: Quentin Casasnovas
Cc: x86, kvm, lkml, Eugene Korenevsky, Radim Krčmář,
Thomas Gleixner, Ingo Molnar, H . Peter Anvin, linux-stable
On 24/06/2016 15:04, Quentin Casasnovas wrote:
> On Thu, Jun 23, 2016 at 06:03:01PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 18/06/2016 11:01, Quentin Casasnovas wrote:
>>> Cross-checking the KVM/VMX VMREAD emulation code with the Intel Software
>>> Developper Manual Volume 3C - "VMREAD - Read Field from Virtual-Machine
>>> Control Structure", I found that we're enforcing that the destination
>>> operand is NOT located in a read-only data segment or any code segment when
>>> the L1 is in long mode - BUT that check should only happen when it is in
>>> protected mode.
>>>
>>> Shuffling the code a bit to make our emulation follow the specification
>>> allows me to boot a Xen dom0 in a nested KVM and start HVM L2 guests
>>> without problems.
>>
>> That's great, and I'm applying the patch, but it's also pretty weird. :)
>> Do you have a pointer to Xen source code that does a VMREAD into a
>> read-only data segment or a code segment?
>
> It is indeed pretty weird. Looking at the Xen stack trace, it looks like
> the vmread is writing to an on-stack buffer, and surely it must be writable
> so I wonder if Xen might not be using an executable stack for some reason?
> That would be a bit scary so I'm surely missing something.
>
> Is there an easy way to know from my KVM host the different segment
> permission setup by the guest?
Remove your patch, call dump_vmcs() where the #GP is injected, and
you'll find the VMCS (including segment permissions, but not the
instruction info field---you probably should add it) in dmesg.
Thanks,
Paolo
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] KVM: nVMX: VMX instructions: fix segment checks when L1 is in long mode.
2016-06-24 13:10 ` Paolo Bonzini
@ 2016-06-29 17:25 ` Quentin Casasnovas
2016-06-29 20:48 ` Paolo Bonzini
0 siblings, 1 reply; 6+ messages in thread
From: Quentin Casasnovas @ 2016-06-29 17:25 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Quentin Casasnovas, x86, kvm, lkml, Eugene Korenevsky,
Radim Krčmář,
Thomas Gleixner, Ingo Molnar, H . Peter Anvin, linux-stable
[-- Attachment #1: Type: text/plain, Size: 2443 bytes --]
On Fri, Jun 24, 2016 at 03:10:03PM +0200, Paolo Bonzini wrote:
> On 24/06/2016 15:04, Quentin Casasnovas wrote:
> > On Thu, Jun 23, 2016 at 06:03:01PM +0200, Paolo Bonzini wrote:
> >>
> >>
> >> On 18/06/2016 11:01, Quentin Casasnovas wrote:
> >>> Cross-checking the KVM/VMX VMREAD emulation code with the Intel Software
> >>> Developper Manual Volume 3C - "VMREAD - Read Field from Virtual-Machine
> >>> Control Structure", I found that we're enforcing that the destination
> >>> operand is NOT located in a read-only data segment or any code segment when
> >>> the L1 is in long mode - BUT that check should only happen when it is in
> >>> protected mode.
> >>>
> >>> Shuffling the code a bit to make our emulation follow the specification
> >>> allows me to boot a Xen dom0 in a nested KVM and start HVM L2 guests
> >>> without problems.
> >>
> >> That's great, and I'm applying the patch, but it's also pretty weird. :)
> >> Do you have a pointer to Xen source code that does a VMREAD into a
> >> read-only data segment or a code segment?
> >
> > It is indeed pretty weird. Looking at the Xen stack trace, it looks like
> > the vmread is writing to an on-stack buffer, and surely it must be writable
> > so I wonder if Xen might not be using an executable stack for some reason?
> > That would be a bit scary so I'm surely missing something.
> >
> > Is there an easy way to know from my KVM host the different segment
> > permission setup by the guest?
>
> Remove your patch, call dump_vmcs() where the #GP is injected, and
> you'll find the VMCS (including segment permissions, but not the
> instruction info field---you probably should add it) in dmesg.
>
Thanks for the heads up :)
I've had a bit more time to spend on this this morning and attached is the
VMCS dump. I've look at the vmcs_instruction_info and it appears the
segment referenced is SS (which is in sync with the backtrace where the
instruction causing the vmexit is "vmread %rbp, %rbp), and it has awkward
attributes:
SS: sel=0x0000, attr=0x1c000, limit=0xffffffff, base=0x0000000000000000
The lower 16 bits are all zero so KVM VMX emulation was injecting the GP(0)
because we were about to write to a read-only segment. At least the stack
isn't executable from what I can tell!
Attached is the full VMCS dump where I've added a printk() to show the
'type' (all zeroes) and vmcs_instruction_info in case my above analysis is
complete non-sense.
Quentin
[-- Attachment #2: vmcs_dump_xen_vmread.txt --]
[-- Type: text/plain, Size: 2900 bytes --]
[ 9853.506447] kvm: wr: read-only segment type==0, info=e2614920
[ 9853.506464] *** Guest State ***
[ 9853.506466] CR0: actual=0x0000000080050033, shadow=0x0000000080050033, gh_mask=fffffffffffffff7
[ 9853.506467] CR4: actual=0x00000000001526e0, shadow=0x00000000001526e0, gh_mask=fffffffffffff871
[ 9853.506467] CR3 = 0x000000007aa37000
[ 9853.506468] RSP = 0xffff83007b73fab0 RIP = 0xffff82d0801e629e
[ 9853.506469] RFLAGS=0x00000202 DR7 = 0x0000000000000400
[ 9853.506470] Sysenter RSP=ffff83007b73ffc0 CS:RIP=e008:ffff82d08022c480
[ 9853.506471] CS: sel=0xe008, attr=0x0a09b, limit=0xffffffff, base=0x0000000000000000
[ 9853.506472] DS: sel=0x0000, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000
[ 9853.506473] SS: sel=0x0000, attr=0x1c000, limit=0xffffffff, base=0x0000000000000000
[ 9853.506474] ES: sel=0x0000, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000
[ 9853.506475] FS: sel=0x0000, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000
[ 9853.506476] GS: sel=0x0000, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000
[ 9853.506477] GDTR: limit=0x0000efff, base=0xffff83007b4d7000
[ 9853.506478] LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, base=0x0000000000000000
[ 9853.506479] IDTR: limit=0x00000fff, base=0xffff83007b4e3000
[ 9853.506480] TR: sel=0xe040, attr=0x0008b, limit=0x00000067, base=0xffff83007b4e6c80
[ 9853.506481] EFER = 0x0000000000000d00 PAT = 0x0000050100070406
[ 9853.506481] DebugCtl = 0x0000000000000000 DebugExceptions = 0x0000000000000000
[ 9853.506482] Interruptibility = 00000000 ActivityState = 00000000
[ 9853.506483] *** Host State ***
[ 9853.506484] RIP = 0xffffffffa00f6daf RSP = 0xffff880131aafd00
[ 9853.506485] CS=0010 SS=0018 DS=0000 ES=0000 FS=0000 GS=0000 TR=0040
[ 9853.506486] FSBase=00007fbf6bfff700 GSBase=ffff88021e240000 TRBase=ffff88021e253b40
[ 9853.506486] GDTBase=ffff88021e249000 IDTBase=ffffffffff57b000
[ 9853.506487] CR0=0000000080050033 CR3=0000000004b21000 CR4=00000000001426e0
[ 9853.506488] Sysenter RSP=0000000000000000 CS:RIP=0010:ffffffff81a02740
[ 9853.506489] EFER = 0x0000000000000d01 PAT = 0x0407010600070106
[ 9853.506490] *** Control State ***
[ 9853.506491] PinBased=0000003f CPUBased=b6a06dfa SecondaryExec=000000eb
[ 9853.506491] EntryControls=0000d3ff ExitControls=002fefff
[ 9853.506492] ExceptionBitmap=00060042 PFECmask=00000000 PFECmatch=00000000
[ 9853.506493] VMEntry: intr_info=000000fc errcode=00000000 ilen=00000000
[ 9853.506494] VMExit: intr_info=00000000 errcode=00000000 ilen=00000006
[ 9853.506495] reason=00000017 qualification=0000000000000008
[ 9853.506495] IDTVectoring: info=00000000 errcode=00000000
[ 9853.506496] TSC Offset = 0xffffe8cdfc3ca592
[ 9853.506497] TPR Threshold = 0x00
[ 9853.506497] EPT pointer = 0x000000000467f01e
[ 9853.506498] Virtual processor ID = 0x0007
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] KVM: nVMX: VMX instructions: fix segment checks when L1 is in long mode.
2016-06-29 17:25 ` Quentin Casasnovas
@ 2016-06-29 20:48 ` Paolo Bonzini
0 siblings, 0 replies; 6+ messages in thread
From: Paolo Bonzini @ 2016-06-29 20:48 UTC (permalink / raw)
To: Quentin Casasnovas
Cc: x86, kvm, lkml, Eugene Korenevsky, Radim Krčmář,
Thomas Gleixner, Ingo Molnar, H . Peter Anvin, linux-stable
On 29/06/2016 19:25, Quentin Casasnovas wrote:
> On Fri, Jun 24, 2016 at 03:10:03PM +0200, Paolo Bonzini wrote:
>> On 24/06/2016 15:04, Quentin Casasnovas wrote:
>>> On Thu, Jun 23, 2016 at 06:03:01PM +0200, Paolo Bonzini wrote:
>>>>
>>>>
>>>> On 18/06/2016 11:01, Quentin Casasnovas wrote:
>>>>> Cross-checking the KVM/VMX VMREAD emulation code with the Intel Software
>>>>> Developper Manual Volume 3C - "VMREAD - Read Field from Virtual-Machine
>>>>> Control Structure", I found that we're enforcing that the destination
>>>>> operand is NOT located in a read-only data segment or any code segment when
>>>>> the L1 is in long mode - BUT that check should only happen when it is in
>>>>> protected mode.
>>>>>
>>>>> Shuffling the code a bit to make our emulation follow the specification
>>>>> allows me to boot a Xen dom0 in a nested KVM and start HVM L2 guests
>>>>> without problems.
>>>>
>>>> That's great, and I'm applying the patch, but it's also pretty weird. :)
>>>> Do you have a pointer to Xen source code that does a VMREAD into a
>>>> read-only data segment or a code segment?
>>>
>>> It is indeed pretty weird. Looking at the Xen stack trace, it looks like
>>> the vmread is writing to an on-stack buffer, and surely it must be writable
>>> so I wonder if Xen might not be using an executable stack for some reason?
>>> That would be a bit scary so I'm surely missing something.
>>>
>>> Is there an easy way to know from my KVM host the different segment
>>> permission setup by the guest?
>>
>> Remove your patch, call dump_vmcs() where the #GP is injected, and
>> you'll find the VMCS (including segment permissions, but not the
>> instruction info field---you probably should add it) in dmesg.
>
> Thanks for the heads up :)
>
> I've had a bit more time to spend on this this morning and attached is the
> VMCS dump. I've look at the vmcs_instruction_info and it appears the
> segment referenced is SS (which is in sync with the backtrace where the
> instruction causing the vmexit is "vmread %rbp, %rbp), and it has awkward
> attributes:
>
> SS: sel=0x0000, attr=0x1c000, limit=0xffffffff, base=0x0000000000000000
>
> The lower 16 bits are all zero so KVM VMX emulation was injecting the GP(0)
> because we were about to write to a read-only segment. At least the stack
> isn't executable from what I can tell!
Yes, that was my reading of the VMCS dump too. The weird attributes
come from the (non)handling of selectors in 64-bit mode.
Paolo
> Attached is the full VMCS dump where I've added a printk() to show the
> 'type' (all zeroes) and vmcs_instruction_info in case my above analysis is
> complete non-sense.
>
> Quentin
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-06-29 20:48 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-18 9:01 [PATCH] KVM: nVMX: VMX instructions: fix segment checks when L1 is in long mode Quentin Casasnovas
2016-06-23 16:03 ` Paolo Bonzini
2016-06-24 13:04 ` Quentin Casasnovas
2016-06-24 13:10 ` Paolo Bonzini
2016-06-29 17:25 ` Quentin Casasnovas
2016-06-29 20:48 ` Paolo Bonzini
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).