On Sun, Feb 11, 2018 at 3:56 AM, Wanpeng Li wrote:
> Writes 0 to cr3 can't be detected during vmentry checks by hardware.
I never suggested otherwise. I was just trying to explain why you
can't assume that the host CR3 field in the VMCS matches the host CR3
at the time of VMLAUNCH.
KVM is set u
2018-02-08 23:29 GMT+08:00 Jim Mattson :
> Consider the following scenario:
>
> L1 has never successfully executed VMLAUNCH. It has written 0 to
> vmcs12's host CR3 field using VMWRITE, but the current host CR3 value
Writes 0 to cr3 can't be detected during vmentry checks by hardware.
> is actual
On 08/02/2018 16:54, Jim Mattson wrote:
> On Thu, Feb 8, 2018 at 7:29 AM, Jim Mattson wrote:
>> Similarly, the correct L1 CR4 value should be in vmcs01's CR4
>> read shadow field.
> Sorry; that's wrong. L1's CR4 value has to be reconstructed from the
> vmcs01 guest CR4 field and CR4 shadow field u
On Thu, Feb 8, 2018 at 7:29 AM, Jim Mattson wrote:
> Similarly, the correct L1 CR4 value should be in vmcs01's CR4
> read shadow field.
Sorry; that's wrong. L1's CR4 value has to be reconstructed from the
vmcs01 guest CR4 field and CR4 shadow field using the cr4 guest/host
mask. But there is no w
Consider the following scenario:
L1 has never successfully executed VMLAUNCH. It has written 0 to
vmcs12's host CR3 field using VMWRITE, but the current host CR3 value
is actually 3e7000. It has written some illegal control field that the
L0 KVM doesn't check itself, but defers to the hardware che
2018-02-08 0:57 GMT+08:00 Jim Mattson :
> vmcs12->host_cr[34] does not contain the up-to-date values when L1 is
> running. L1 can vmwrite any values there. We know at this point that
It will incur a vmexit to emulate L1 vmwrites vmcs12->host_cr[34] even
if vmcs shadow is enabled since host_cr[34]
vmcs12->host_cr[34] does not contain the up-to-date values when L1 is
running. L1 can vmwrite any values there. We know at this point that
they are legal (because we checked them), but that's about it. If the
VMLAUNCH/VMRESUME of vmcs12 fails for "invalid control field," there
is no VM-exit from L2
2018-02-07 0:58 GMT+08:00 Jim Mattson :
> On Mon, Feb 5, 2018 at 4:57 PM, Wanpeng Li wrote:
>
>> This is effective one, what I restore in this patch is
>> achitectural/guest visible.
>
> This patch doesn't "restore" the guest visible CR4 to its value at the
> time of VMLAUNCH/VMRESUME. It loads a
On Mon, Feb 5, 2018 at 4:57 PM, Wanpeng Li wrote:
> This is effective one, what I restore in this patch is
> achitectural/guest visible.
This patch doesn't "restore" the guest visible CR4 to its value at the
time of VMLAUNCH/VMRESUME. It loads a new CR4 value from the vmcs12.
That behavior is in
2018-02-06 2:24 GMT+08:00 Jim Mattson :
> [Resending as plain text]
>
> On Mon, Feb 5, 2018 at 10:21 AM Jim Mattson wrote:
>
>> This is incorrect. In the event of an early VM-entry failure (e.g. a
>> VM-entry failure for "VM entry with invalid control field(s)"), no host
>> state should be loaded
[Resending as plain text]
On Mon, Feb 5, 2018 at 10:21 AM Jim Mattson wrote:
> This is incorrect. In the event of an early VM-entry failure (e.g. a
> VM-entry failure for "VM entry with invalid control field(s)"), no host
> state should be loaded from the VMCS12. Of course, no guest state should
From: Wanpeng Li
In L0, Haswell client host:
nested_vmx_exit_reflected failed vm entry 7
WARNING: CPU: 6 PID: 6797 at kvm/arch/x86/kvm//vmx.c:6206
handle_desc+0x2d/0x40 [kvm_intel]
CPU: 6 PID: 6797 Comm: qemu-system-x86 Tainted: GW OE4.15.0+ #4
RIP: 0010:handle_desc+0x2d/0x40 [
12 matches
Mail list logo