"Dr. David Alan Gilbert" writes:
> * Paolo Bonzini (pbonz...@redhat.com) wrote:
>>
>>
>> On 10/03/2015 19:21, Bandan Das wrote:
>> > Paolo Bonzini writes:
>> >
>> >> On 10/03/2015 17:57, Dr. David Alan Gilbert wrote:
>> >
Paolo Bonzini writes:
> On 10/03/2015 17:57, Dr. David Alan Gilbert wrote:
>> I'm seeing something similar; it's very intermittent and generally
>> happening right at boot of the guest; I'm running this on qemu
>> head+my postcopy world (but it's happening right at boot before postcopy
>> gets
Andrey Korolyov writes:
> On Fri, Mar 6, 2015 at 1:14 AM, Andrey Korolyov wrote:
>> Hello,
>>
>> recently I`ve got a couple of shiny new Intel 2620v2s for future
>> replacement of the E5-2620v1, but I experienced relatively many events
>> with emulation errors, all traces looks simular to the on
Alex Williamson writes:
> On Wed, 2015-03-04 at 15:49 -0500, Bandan Das wrote:
>> Hi Alex,
>>
>> Alex Williamson writes:
>> ...
>> > + if (fields < 2) {
>> > + pr_warn("vfio-pci: invalid id st
Hi Alex,
Alex Williamson writes:
...
> + if (fields < 2) {
> + pr_warn("vfio-pci: invalid id string \"%s\"\n", id);
> + continue;
> + }
> +
> + pr_info("vfio-pci: add %04X:%04X sub=%04X:%04X cls=%08X/%08X\n",
> +
Hi Wincy,
Wincy Van writes:
> In commit 3af18d9c5fe9 ("KVM: nVMX: Prepare for using hardware MSR bitmap"),
> we are setting MSR_BITMAP in prepare_vmcs02 if we should use hardware. This
> is not enough since the field will be modified by following vmx_set_efer.
>
> Fix this by setting vmx_msr_bit
Wincy Van writes:
> On Wed, Mar 4, 2015 at 1:39 AM, Bandan Das wrote:
>> Wincy Van writes:
>>
>>> In commit 3af18d9c5fe9 ("KVM: nVMX: Prepare for using hardware MSR bitmap"),
>>> we are setting MSR_BITMAP in prepare_vmcs02 if we should use hardware.
Christian Borntraeger writes:
> halt_poll_ns is used only locally. Make it static.
>
> Signed-off-by: Christian Borntraeger
> ---
> virt/kvm/kvm_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 34310a8..58bc2a9 100
Wincy Van writes:
> In commit 3af18d9c5fe9 ("KVM: nVMX: Prepare for using hardware MSR bitmap"),
> we are setting MSR_BITMAP in prepare_vmcs02 if we should use hardware. This
> is not enough since the field will be modified by following vmx_set_efer.
>
> Fix this by setting vmx_msr_bitmap_nested
Radim Krčmář writes:
> 2015-03-01 21:29-0500, Bandan Das:
>> Joel Schopp writes:
>>
>> > From: David Kaplan
>> > No need to re-decode WBINVD since we know what it is from the intercept.
>> >
>> > Signed-off-by: David Kaplan
>> > [ex
Joel Schopp writes:
> From: David Kaplan
> No need to re-decode WBINVD since we know what it is from the intercept.
>
> Signed-off-by: David Kaplan
> [extracted from larger unlrelated patch, forward ported, tested]
> Signed-off-by: Joel Schopp
> ---
> arch/x86/kvm/svm.c | 10 +-
> 1
Thomas Huth writes:
> kvm_kvfree() provides exactly the same functionality as the
> new common kvfree() function - so let's simply replace the
> kvm function with the common function.
I assumed there would be a wrapper kvzalloc as well, seems not :)
> Signed-off-by: Thomas Huth
> ---
> arch/x
Jan Kiszka writes:
> 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
>>>
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_IMAGE=/vmlinuz-3.20.0-0.rc0.git5.1.fc23.x86_64
> ro
Eugene Korenevsky writes:
>> Hi, Eugene, is it okay to split my part up?
>
> I think the patch is atomic. No ideas how this patch could be split
> without breaking its integrity.
> You are a co-author of the patch since your ideas make significant part of it.
I was suggesting adding the interfac
Eugene Korenevsky writes:
> Several hypervisors use MSR loading/storing to run guests.
> This patch implements emulation of this feature and allows these
> hypervisors to work in L1.
>
> The following is emulated:
> - Loading MSRs on VM-entries
> - Saving MSRs on VM-exits
> - Loading MSRs on VM-e
[Ccing a few others who might be interested]
Hi Eugene,
Did you look at the other patch that was posted for this functionality
by Wincy Van ?
https://lkml.org/lkml/2014/11/21/749
Eugene Korenevsky writes:
> BitVisor hypervisor fails to start a nested guest due to lack of MSR
> load/store supp
If L0 has disabled EPT, don't advertise unrestricted
mode at all since it depends on EPT to run real mode code.
Signed-off-by: Bandan Das
---
arch/x86/kvm/vmx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 3e
Andy Lutomirski writes:
> I don't know what's going on here, but a nested VMX boot using -cpu
> host on SNB on L0 and L1 fails with the OOPS below. I kind of suspect
> that there's both a KVM bug and an APIC driver bug here.
What kernel version is this ? What are you running for L1 and L2 ?
>
Jan Kiszka writes:
> In order to access the shadow VMCS, we need to load it. At this point,
> vmx->loaded_vmcs->vmcs and the actually loaded one start to differ. If
> we now get preempted by Linux, vmx_vcpu_put and, on return, the
> vmx_vcpu_load will work against the wrong vmcs. That can cause
>
Andy Lutomirski writes:
> virtio-rng is both too complicated and insufficient for initial rng
> seeding. It's far too complicated to use for KASLR or any other
> early boot random number needs. It also provides /dev/random-style
> bits, which means that making guest boot wait for virtio-rng is
Paolo Bonzini writes:
> test_vmptrld was actually invoking vmclear. make_vmcs_current is
> the wrapper for vmptrld, not vmcs_clear!
Oops, this was my fault, sorry!!
> Signed-off-by: Paolo Bonzini
> ---
> x86/vmx.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a
Wanpeng Li writes:
...
>
> As Jan metioned in http://www.spinics.net/lists/kvm/msg105238.html, "In any
> case,
> unconditionally setting KVM_REQ_EVENT seems strange and should be changed."
> Your
> trick still keep the unconditionally setting KVM_REQ_EVENT which is the root
> cause
> of the
check
for injectable interrupt returns true
Signed-off-by: Bandan Das
---
arch/x86/kvm/x86.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 73537ec..56327a6 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5907,6 +59
Paolo Bonzini writes:
> Il 07/07/2014 19:31, Bandan Das ha scritto:
>>> >
>>> > Which patch? Yours or Bandan's?
>> Why don't we hold off on Wanpeng's patch and instead apply the one I proposed
>> to call check_nested_events() w
Paolo Bonzini writes:
> Il 07/07/2014 10:46, Wanpeng Li ha scritto:
>> Hi Paolo,
>>
>> Is it ok for you to apply this patch and then more effort should be taken
>> to figure out the other bug which don't have any relationship with the race
>> that this patch fixed?
>
> Which patch? Yours or Band
Wanpeng Li writes:
> On Thu, Jul 03, 2014 at 01:15:26AM -0400, Bandan Das wrote:
>>Jan Kiszka writes:
>>
>>> On 2014-07-02 08:54, Wanpeng Li wrote:
>>>> This patch fix bug https://bugzilla.kernel.org/show_bug.cgi?id=72381
>>>>
>>&g
Wanpeng Li writes:
> On Thu, Jul 03, 2014 at 01:15:26AM -0400, Bandan Das wrote:
>>Jan Kiszka writes:
>>
>>> On 2014-07-02 08:54, Wanpeng Li wrote:
>>>> This patch fix bug https://bugzilla.kernel.org/show_bug.cgi?id=72381
>>>>
>>&g
Wanpeng Li writes:
> Hi Bandan,
> On Wed, Jul 02, 2014 at 12:27:59PM -0400, Bandan Das wrote:
>>Wanpeng Li writes:
>>
>>> This patch fix bug https://bugzilla.kernel.org/show_bug.cgi?id=72381
>>I can also reproduce this easily with Linux as L1 by "slowi
Jan Kiszka writes:
> On 2014-07-02 08:54, Wanpeng Li wrote:
>> This patch fix bug https://bugzilla.kernel.org/show_bug.cgi?id=72381
>>
>> If we didn't inject a still-pending event to L1 since nested_run_pending,
>> KVM_REQ_EVENT should be requested after the vmexit in order to inject the
>> ev
Wanpeng Li writes:
> This patch fix bug https://bugzilla.kernel.org/show_bug.cgi?id=72381
I can also reproduce this easily with Linux as L1 by "slowing it down"
eg. running with ept = 0
I suggest changing the subject to -
KVM: nVMX: Fix race that incorrectly injects L1's irq to L2
> If we didn
Paolo Bonzini writes:
> Il 30/06/2014 03:03, Nadav Amit ha scritto:
sipi_vector = apic->sipi_vector;
-pr_debug("vcpu %d received sipi with vector # %x\n",
+apic_debug("vcpu %d received sipi with vector # %x\n",
>>>
>>> Why don't we just use pr_debug a
Paolo Bonzini writes:
> Il 30/06/2014 19:39, Bandan Das ha scritto:
>> Paolo Bonzini writes:
>>
>>> Il 30/06/2014 03:03, Nadav Amit ha scritto:
>>>>>>
>>>>>> sipi_vector = apic->sipi_vector;
>
Nadav Amit writes:
> In two cases lapic.c does not use the apic_debug macro correctly. This patch
> fixes them.
>
> Signed-off-by: Nadav Amit
> ---
> arch/x86/kvm/lapic.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> i
"Gabriel L. Somlo" writes:
> On Wed, Jun 18, 2014 at 10:59:14AM -0700, Eric Northup wrote:
>> On Wed, Jun 18, 2014 at 7:19 AM, Nadav Amit wrote:
>> > mwait and monitor are currently handled as nop. Considering this behavior,
>> > they
>> > should still be handled correctly, i.e., check executio
Paolo Bonzini writes:
> Il 18/06/2014 18:43, Bandan Das ha scritto:
>>> > mwait and monitor are currently handled as nop. Considering this
>>> > behavior, they
>>> > should still be handled correctly, i.e., check execution conditions and
>>> >
Nadav Amit writes:
> mwait and monitor are currently handled as nop. Considering this behavior,
> they
> should still be handled correctly, i.e., check execution conditions and
> generate
> exceptions when required. mwait and monitor may also be executed in real-mode
Is this necessary ? They a
Paolo Bonzini writes:
> Il 16/06/2014 19:38, Bandan Das ha scritto:
>> Nadav Amit writes:
>>
>>> The emulator does not emulate the xadd instruction correctly if the two
>>> operands are the same. In this (unlikely) situation the result should be
>>&
Nadav Amit writes:
> The emulator does not emulate the xadd instruction correctly if the two
> operands are the same. In this (unlikely) situation the result should be the
> sum of X and X (2X) when it is currently X. The solution is to first perform
> writeback to the source, before writing to
Jan Kiszka writes:
> From: Jan Kiszka
>
> Consistently make sure we are not affected by any compiler reordering
> when evaluating the current stage.
Should we prevent accidental calls to the variable directly by moving
get/set to vmx.c or a separate file in lib/x86 altogether ?
> Signed-off-
Jan Kiszka writes:
...
> /* cpu-based controls */
> rdmsr(MSR_IA32_VMX_PROCBASED_CTLS,
> nested_vmx_procbased_ctls_low, nested_vmx_procbased_ctls_high);
> @@ -2409,11 +2422,17 @@ static int vmx_get_vmx_msr(struct kvm_vcpu *vcpu, u32
> msr_index, u64 *pdata)
>
Jan Kiszka writes:
> SDM says bits 1, 4-6, 8, 13-16, and 26 have to be set.
>
> Signed-off-by: Jan Kiszka
> ---
> arch/x86/include/asm/vmx.h | 3 +++
> arch/x86/kvm/vmx.c | 5 +++--
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/vmx.h b/arch/x86
Jan Kiszka writes:
> We already implemented them but failed to advertise them. Currently they
> all return the identical values to the capability MSRs they are
> augmenting. So there is no change in exposed features yet.
>
> Drop related comments at this chance that are partially incorrect and
>
Alex Williamson writes:
> On Thu, 2014-06-12 at 16:12 -0400, Bandan Das wrote:
>> Alex Williamson writes:
>>
>> > If the PCI core set cfg_size isn't large enough for extended
>> > capabilities, then they're not there. Extended config space may b
Alex Williamson writes:
> If the PCI core set cfg_size isn't large enough for extended
> capabilities, then they're not there. Extended config space may be
> inaccessible due to a PCI bridge, in which case cfg_size may be cut
> short.
Just curious, is this part of the spec or just a convention
Nadav Amit writes:
> The current realmode tests always report success when done, regardless to
> whether any of the tests failed. Although the log includes the individual
> test
> results, this behavior complicates the life of the tester.
Please include kvm-unit-tests in the subject line for e
This makes sure that the flags register doesn't get accidentally
overwritten due to compiler optimizations or other means
Signed-off-by: Bandan Das
---
lib/x86/processor.h | 7 ---
x86/vmx.c | 31 ++-
x86/vmx.h | 10 --
3
Check if the vmcs pointer is not aligned to page size,
and if bits beyond physical address width are set. Also,
vmclear and vmptrld should fail if the vmxon region is
supplied instead of the vmcs
Signed-off-by: Bandan Das
---
x86/vmx.c | 52
Verify that vmon fails with unaligned vmxon region or
any bits set beyong the physical address width. Also verify
failure with an invalid revision identifier.
Signed-off-by: Bandan Das
---
x86/vmx.c | 40 +---
1 file changed, 37 insertions(+), 3 deletions
writing of flags register inside asm blocks
Bandan Das (3):
VMX: move write_rflags inside asm blocks for vmx instructions
VMX: Add more checks to test_vmxon
VMX: Updated test_vmclear and test_vmptrld
lib/x86/processor.h | 7 ---
x86/vmx.c | 121
Jidong Xiao writes:
..
>>
> Hi, Bandan,
>
> Thanks for the advice. I think Paolo has incorporated this patch into
> his patch sets, and he sent the revised version in a separate email
> earlier today with the subject "[PULL 11/11] kvm: Fix eax for cpuid
> leaf 0x4000".
Oops! Sorry, must have
A couple more updates to test_vmxon, test_vmptrld
and test_vmclear based on kvm commits -
3573e22cfecaac83f82ef4f6847d90e466fc8e10
KVM: nVMX: additional checks on vmxon region
96ec146330d18a938b4773be8d6dd1f93399507c
KVM: nVMX: fail on invalid vmclear/vmptrld pointer
Bandan Das (2):
VMX: Add
Check if the vmcs pointer is not aligned to page size,
and if bits beyond physical address width are set. Also,
vmclear and vmptrld should fail if the vmxon region is
supplied instead of the vmcs
Signed-off-by: Bandan Das
---
x86/vmx.c | 63
Verify that vmon fails with unaligned vmxon region or
any bits set beyong the physical address width. Also verify
failure with an invalid revision identifier.
Signed-off-by: Bandan Das
---
x86/vmx.c | 46 +++---
1 file changed, 43 insertions(+), 3
Jidong Xiao writes:
> On Wed, Jun 4, 2014 at 3:09 AM, Paolo Bonzini wrote:
>> Il 04/06/2014 03:10, Jidong Xiao ha scritto:
>>
>>> diff --git a/qemu-2.0.0/target-i386/kvm.c.orig
>>> b/qemu-2.0.0/target-i386/kvm.c
>>> index 4389959..b8b282d 100644
>>> --- a/qemu-2.0.0/target-i386/kvm.c.orig
>>> ++
It's incorrect to assume the context in which invept
is called. Check what is supported and fallback if
single context invalidation isn't supported
Signed-off-by: Bandan Das
---
x86/vmx.c | 20
x86/vmx.h | 1 +
x86/vmx_tests.c | 14 +++--
If the hypervisor has the interrupt acknowledgement bit set,
vector information is already present in intr_info during a vmexit.
The hypervisor then uses it to call the appropriate handler.
Signed-off-by: Bandan Das
---
lib/x86/isr.c | 32
lib/x86/isr.h | 2
Adds a simple test for interrupt acknowledgement and change
invept behavior to check for supported invalidation contexts
Bandan Das (2):
VMX: check for supported contexts before calling invept
VMX: Add test for interrupt acknowledgement
lib/x86/isr.c | 32
Paolo Bonzini writes:
> Il 06/05/2014 08:19, Bandan Das ha scritto:
>> Reference: https://bugzilla.kernel.org/show_bug.cgi?id=54521
>>
>> The vmxon region is unused by nvmx, but adding these checks
>> are probably harmless and may detect buggy L1 hypervisors in
>&g
Alex Williamson writes:
> The latest Nvidia driver (337.88) specifically checks for KVM as the
> hypervisor and reports Code 43 for the driver in a Windows guest when
> found. Removing or changing the KVM signature is sufficient for the
> driver to load and work. This patch adds an option to ea
Michael Tokarev writes:
> 02.06.2014 17:30, Alex Williamson wrote:
>> On Mon, 2014-06-02 at 14:32 +0400, Michael Tokarev wrote:
>>> 01.06.2014 20:25, Alex Williamson wrote:
The latest Nvidia driver (337.88) specifically checks for KVM as the
hypervisor and reports Code 43 for the driver
Nadav Amit writes:
> 32-bit operations are zero extended in 64-bit mode. Currently, the code does
> not handle them correctly and keeps the high bits. In 16-bit mode, the high
> 32-bits are kept intact.
>
> In addition, although it is not well-documented, when address override prefix
It would be
Nadav Amit writes:
> Relative jumps and calls do the masking according to the operand size, and not
> according to the address size as the KVM emulator does today. In 64-bit mode,
> the resulting RIP is always 64-bit. Otherwise it is masked according to the
> instruction operand-size. Note that
Paolo Bonzini writes:
> Il 06/05/2014 02:40, Bandan Das ha scritto:
>> On every instruction fetch, kvm_read_guest_virt_helper
>> does the gva to gpa translation followed by searching for the
>> memslot. Store the gva hva mapping so that if there's a match
>> we ca
Paolo Bonzini writes:
> We do not need a memory copying loop anymore in insn_fetch; we
> can use a byte-aligned pointer to access instruction fields directly
Nice approach!
> from the fetch_cache. This eliminates 40-80 cycles (corresponding to
> a 5-7% improvement in performance) from each ins
Paolo Bonzini writes:
> do_insn_fetch_bytes will only be called once in a given insn_fetch and
> insn_fetch_arr, because in fact it will only be called at most twice
> for any instruction and the first call is explicit in x86_decode_insn.
> This observation lets us hoist the call out of the memor
Ok! Now that you posted your changes, I am getting to understand this
a little :)
Paolo Bonzini writes:
> Hoist the common case up from do_insn_fetch_byte to do_insn_fetch,
> and prime the fetch_cache in x86_decode_insn. This helps both the
> compiler and the branch predictor.
>
> Signed-off-b
Our common function for vmptr checks (in 2/4) needs to fetch
the memory address
Signed-off-by: Bandan Das
---
arch/x86/kvm/vmx.c | 106 ++---
1 file changed, 53 insertions(+), 53 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
The spec mandates that if the vmptrld or vmclear
address is equal to the vmxon region pointer, the
instruction should fail with error "VMPTRLD with
VMXON pointer" or "VMCLEAR with VMXON pointer"
Signed-off-by: Bandan Das
---
arch/x86/kvm/vmx.c | 12
1 file ch
()
- Fix a leak with kunmap()
- Remove unnecessary braces around comparisions
- Move all checks into a common function, this will be later
used by handle_vmptrld and handle_vmclear in 4/4
4/4
- New patch - use common function to perform checks on
vmptr
Bandan Das (4):
KVM: nVMX
Some checks are common to all, and moreover,
according to the spec, the check for whether any bits
beyond the physical address width are set are also
applicable to all of them
Signed-off-by: Bandan Das
---
arch/x86/kvm/vmx.c | 83 --
1 file
Currently, the vmxon region isn't used in the nested case.
However, according to the spec, the vmxon instruction performs
additional sanity checks on this region and the associated
pointer. Modify emulated vmxon to better adhere to the spec
requirements
Signed-off-by: Bandan Das
---
arc
uction (9.0%)
Bandan Das (3):
KVM: x86: pass ctxt to fetch helper function
KVM: x86: use memory_prepare in fetch helper function
KVM: x86: cache userspace address for faster fetches
arch/x86/include/asm/kvm_emulate.h | 7 +-
arch/x86/kvm/x86.c
On every instruction fetch, kvm_read_guest_virt_helper
does the gva to gpa translation followed by searching for the
memslot. Store the gva hva mapping so that if there's a match
we can directly call __copy_from_user()
Suggested-by: Paolo Bonzini
Signed-off-by: Bandan Das
---
arch/x86/in
Insn fetch fastpath function. Not that
arch.walk_mmu->gva_to_gpa can't be used but let's
piggyback on top of interface meant for our purpose
Signed-off-by: Bandan Das
---
arch/x86/kvm/x86.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --g
In the following patches, our adress caching struct that's
embedded within struct x86_emulate_ctxt will need to be
accessed
Signed-off-by: Bandan Das
---
arch/x86/kvm/x86.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/
Hu Yaohui writes:
> On Fri, May 2, 2014 at 11:52 AM, Paolo Bonzini wrote:
>> Il 02/05/2014 17:17, Hu Yaohui ha scritto:
>>
>>> Hi Paolo,
>>> I have tried L0 with linux kernel 3.14.2 and L1 with linux kernel 3.14.2
>>> L1 QEMU qemu-1.7.0
>>> L2 QEMU qemu-1.7.0.
>>
>>
>> Do you mean L0 and L1?
> Y
Jan Kiszka writes:
> On 2014-04-28 07:00, Bandan Das wrote:
>> Currently, the vmxon region isn't used in the nested case.
>> However, according to the spec, the vmxon instruction performs
>> additional sanity checks on this region and the associated
>> pointer.
Jan Kiszka writes:
> On 2014-04-28 07:00, Bandan Das wrote:
>> Reference: https://bugzilla.kernel.org/show_bug.cgi?id=54521
>>
>> The vmxon region is unused by nvmx, but adding these checks
>> are probably harmless and may detect buggy L1 hypervisors in
>>
Currently, the vmxon region isn't used in the nested case.
However, according to the spec, the vmxon instruction performs
additional sanity checks on this region and the associated
pointer. Modify emulated vmxon to better adhere to the spec
requirements
Signed-off-by: Bandan Das
---
arc
handle_vmon will call this function to get the vmxon region
pointer in the next patch
Signed-off-by: Bandan Das
---
arch/x86/kvm/vmx.c | 106 ++---
1 file changed, 53 insertions(+), 53 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=54521
The vmxon region is unused by nvmx, but adding these checks
are probably harmless and may detect buggy L1 hypervisors in
the future!
Bandan Das (3):
KVM: nVMX: rearrange get_vmx_mem_address
KVM: nVMX: additional checks on vmxon
The spec mandates that if the vmptrld or vmclear
address is equal to the vmxon region pointer, the
instruction should fail with error "VMPTRLD with
VMXON pointer" or "VMCLEAR with VMXON pointer"
Signed-off-by: Bandan Das
---
arch/x86/kvm/vmx.c | 12
1 file ch
Paolo Bonzini writes:
> Il 22/04/2014 12:25, Bandan Das ha scritto:
>>>> >> + if (j < i)
>>>> >> + shadow_read_write_fields[j] =
>>>> >> + shadow_read_write_fields[
Paolo Bonzini writes:
> Il 21/04/2014 15:20, Bandan Das ha scritto:
>> +for (i = j = 0; i < max_shadow_read_write_fields; i++) {
>> +
>
> Extra empty line. Not a big deal, but...
>
>> +switch (shadow_read_write_fields[i]) {
&
example, commit
36be0b9deb23161 introduced GUEST_BNDCFGS, which is not supported
by all processors. Filter out host unsupported fields before
letting guests use shadow vmcs
Signed-off-by: Bandan Das
---
v2:
- Just compress the original lists instead of creating new ones
- Change commit message
Paolo Bonzini writes:
> Il 19/04/2014 19:34, Bandan Das ha scritto:
>>
>> We track shadow vmcs fields through two static lists,
>> one for read only fields and another for r/w. However, with
>> addition of new vmcs fields, not all fields may be suppo
, commit
36be0b9deb23161 introduced GUEST_BNDCFGS, which is not supported
for all processors. Create new lists based out of intersection of
static lists and host support and use them for tracking
shadow fields instead
Signed-off-by: Bandan Das
---
arch/x86/kvm/vmx.c | 98
Some Type 1 hypervisors such as XEN won't enable VMX without it present
Signed-off-by: Bandan Das
---
arch/x86/kvm/vmx.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 5c0b74d..7bed3e3 100644
--- a/arch/x86/kvm/vmx.c
ommit description to 2/3 and change comment for nested_exit_intr_ack_set
Jan, I will send a separate unit-test patch
Bandan Das (3):
KVM: nVMX: Don't advertise single context invalidation for invept
KVM: nVMX: Ack and write vector info to intr_info if L1 asks us to
KVM: nVMX: Adverti
be true.
Signed-off-by: Bandan Das
---
arch/x86/kvm/vmx.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 1f68c58..ce8f6c4 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2353,12 +2353,11 @@ static
This feature emulates the "Acknowledge interrupt on exit" behavior.
We can safely emulate it for L1 to run L2 even if L0 itself has it
disabled (to run L1).
Signed-off-by: Bandan Das
---
arch/x86/kvm/irq.c | 1 +
arch/x86/kvm/vmx.c | 18 ++
2 files changed, 19
Remove the if conditional - that will help us avoid
an "else initialize to 0" Also, rearrange operators
for slightly better code.
Signed-off-by: Bandan Das
---
arch/x86/kvm/emulate.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/emulat
unctions
- 6/6 - new patch, remove memopp and move rip_relative to a local variable in
decode_modrm
Bandan Das (6):
KVM: emulate: move init_decode_cache to emulate.c
KVM: emulate: Remove ctxt->intercept and ctxt->check_perm checks
KVM: emulate: cleanup decode_modrm
KVM: emu
Core emulator functions all belong in emulator.c,
x86 should have no knowledge of emulator internals
Signed-off-by: Bandan Das
---
arch/x86/include/asm/kvm_emulate.h | 1 +
arch/x86/kvm/emulate.c | 13 +
arch/x86/kvm/x86.c | 13 -
3 files
A lot of initializations are unnecessary as they get set to
appropriate values before actually being used. Optimize
placement of fields in x86_emulate_ctxt
Signed-off-by: Bandan Das
---
arch/x86/include/asm/kvm_emulate.h | 20 +++-
arch/x86/kvm/emulate.c | 7
The same information can be gleaned from ctxt->d and avoids having
to zero/NULL initialize intercept and check_perm
Signed-off-by: Bandan Das
---
arch/x86/kvm/emulate.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulat
Move typecast on "out of range value" of mem.ea to
decode_modrm. rip_relative is only set in decode_modrm,
change it to a local var
Signed-off-by: Bandan Das
---
arch/x86/include/asm/kvm_emulate.h | 8 +---
arch/x86/kvm/emulate.c | 20 +---
2 files c
x86_decode_insn already sets a default for seg_override,
so remove it from the zeroed area. Also replace set/get functions
with direct access to the field.
Signed-off-by: Bandan Das
---
arch/x86/include/asm/kvm_emulate.h | 3 +--
arch/x86/kvm/emulate.c | 41
Paolo Bonzini writes:
> Il 10/04/2014 20:03, Bandan Das ha scritto:
>> /* Fields above regs are cleared together. */
>
> This comment is not accurate anymore after patch 4. Since you're
> fixing it, please add another comment saying where the cleared fields
> star
101 - 200 of 256 matches
Mail list logo
