Re: [PATCH 1/2] KVM: x86: Add emulation support for #GP triggered by VM instructions

Sean Christopherson writes: ... >> -if ((emulation_type & EMULTYPE_VMWARE_GP) && >> -!is_vmware_backdoor_opcode(ctxt)) { >> -kvm_queue_exception_e(vcpu, GP_VECTOR, 0); >> -return 1; >> +if (emulation_type & EMULTYPE_PARAVIRT_GP) { >> +vminstr =

Re: [PATCH 1/2] KVM: x86: Add emulation support for #GP triggered by VM instructions

Andy Lutomirski writes: ... > #endif diff --git a/arch/x86/kvm/mmu/mmu.c > b/arch/x86/kvm/mmu/mmu.c index 6d16481aa29d..c5c4aaf01a1a 100644 > --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ > -50,6 +50,7 @@ #include #include #include > +#include #include >

Re: [PATCH] KVM: nVMX: fixes for preemption timer migration

ate->hdr.vmx.preemption_timer_deadline; >> - } >> + } else >> + vmx->nested.has_preemption_timer_deadline = false; > > Doesn't the coding standard require braces around the else clause? > I think so... for if/else where at least one of them is multiline. > Reviewed-by: Jim Mattson Looks good to me, Reviewed-by: Bandan Das

Re: Linux 5.3-rc7

Linus Torvalds writes: > On Sat, Sep 7, 2019 at 12:17 PM Linus Torvalds > wrote: >> >> I'm really not clear on why it's a good idea to clear the LDR bits on >> shutdown, and commit 558682b52919 ("x86/apic: Include the LDR when >> clearing out APIC registers") just looks pointless. And now it

Re: linux-next: Fixes tag needs some work in the tip tree

Stephen Rothwell writes: > Hi all, > > In commit > > bae3a8d3308e ("x86/apic: Do not initialize LDR and DFR for bigsmp") > > Fixes tag > > Fixes: db7b9e9f26b8 ("[PATCH] Clustered APIC setup for >8 CPU systems") > > has these problem(s): > > - Target SHA1 does not exist > I tried to dig

Re: [tip:x86/urgent 3/3] arch/x86/kernel/apic/apic.c:1182:6: warning: the address of 'x2apic_enabled' will always evaluate as 'true'

Thomas Gleixner writes: > On Tue, 27 Aug 2019, Bandan Das wrote: >> kbuild test robot writes: >> >> > tree: >> > https://kernel.googlesource.com/pub/scm/linux/kernel/git/tip/tip.git >> > x86/urgent >> > head: c

Re: [tip:x86/urgent 3/3] arch/x86/kernel/apic/apic.c:1182:6: warning: the address of 'x2apic_enabled' will always evaluate as 'true'

kbuild test robot writes: > tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/tip/tip.git > x86/urgent > head: cfa16294b1c5b320c0a0e1cac37c784b92366c87 > commit: cfa16294b1c5b320c0a0e1cac37c784b92366c87 [3/3] x86/apic: Include the > LDR when clearing out APIC registers >

[tip: x86/urgent] x86/apic: Do not initialize LDR and DFR for bigsmp

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: bae3a8d3308ee69a7dbdf145911b18dfda8ade0d Gitweb: https://git.kernel.org/tip/bae3a8d3308ee69a7dbdf145911b18dfda8ade0d Author:Bandan Das AuthorDate:Mon, 26 Aug 2019 06:15:12 -04:00 Committer

[tip: x86/urgent] x86/apic: Include the LDR when clearing out APIC registers

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: 558682b5291937a70748d36fd9ba757fb25b99ae Gitweb: https://git.kernel.org/tip/558682b5291937a70748d36fd9ba757fb25b99ae Author:Bandan Das AuthorDate:Mon, 26 Aug 2019 06:15:13 -04:00 Committer

[tip: x86/urgent] x86/apic: Do not initialize LDR and DFR for bigsmp

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: 9cfe98a6dbfb2a72ae29831e57b406eab7668da8 Gitweb: https://git.kernel.org/tip/9cfe98a6dbfb2a72ae29831e57b406eab7668da8 Author:Bandan Das AuthorDate:Mon, 26 Aug 2019 06:15:12 -04:00 Committer

[tip: x86/urgent] x86/apic: Include the LDR when clearing out APIC registers

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: cfa16294b1c5b320c0a0e1cac37c784b92366c87 Gitweb: https://git.kernel.org/tip/cfa16294b1c5b320c0a0e1cac37c784b92366c87 Author:Bandan Das AuthorDate:Mon, 26 Aug 2019 06:15:13 -04:00 Committer

[PATCH v2 2/2] x86/apic: include the LDR when clearing out apic registers

-by: Bandan Das --- arch/x86/kernel/apic/apic.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c index aa5495d0f478..e75f3782b915 100644 --- a/arch/x86/kernel/apic/apic.c +++ b/arch/x86/kernel/apic/apic.c @@ -1179,6 +1179,10 @@ void

[PATCH v2 1/2] x86/apic: Do not initialize LDR and DFR for bigsmp

in the guest during kdump initialization. Note that this change isn't intended to workaround the kvm lapic bug; bigsmp should correctly stay away from initializing LDR. Suggested-by: Thomas Gleixner Signed-off-by: Bandan Das --- arch/x86/kernel/apic/bigsmp_32.c | 24 ++-- 1

[PATCH v2 0/2] x86/apic: reset LDR in clear_local_APIC

been enabled, a simple guest only change can be to just clear out the LDR. Bandan Das (2): x86/apic: Do not initialize LDR and DFR for bigsmp x86/apic: include the LDR when clearing out apic registers arch/x86/kernel/apic/apic.c | 4 arch/x86/kernel/apic/bigsmp_32.c | 24

Re: [PATCH] x86/apic: reset LDR in clear_local_APIC

Thomas Gleixner writes: > Bandan, > > On Wed, 21 Aug 2019, Bandan Das wrote: >> Thomas Gleixner writes: >> So, in KVM: if we make sure that the logical destination map isn't filled up >> if the virtual >> apic is not enabled by software, it real

Re: [PATCH] x86/apic: reset LDR in clear_local_APIC

Thomas Gleixner writes: > Bandan, > > On Mon, 19 Aug 2019, Bandan Das wrote: >> Thomas Gleixner writes: >> > On Wed, 14 Aug 2019, Bandan Das wrote: >> >> On a 32 bit RHEL6 guest with greater than 8 cpus, the >> >> kdump kernel hangs when calibr

Re: [PATCH] x86/apic: reset LDR in clear_local_APIC

Hi Thomas, Thomas Gleixner writes: > Bandan, > > On Wed, 14 Aug 2019, Bandan Das wrote: >> On a 32 bit RHEL6 guest with greater than 8 cpus, the >> kdump kernel hangs when calibrating apic. This happens >> because when apic initializes bigsmp, it also initializes LDR

[PATCH] x86/apic: reset LDR in clear_local_APIC

the guest while building the logical destination map even for inactive vcpus. While KVM apic can be fixed to ignore apics that haven't been enabled, a simple guest only change can be to just clear out the LDR. Signed-off-by: Bandan Das --- arch/x86/kernel/apic/apic.c | 4 1 file changed, 4

[PATCH v2] perf/x86: descriptive failure messages for PMU init

There's a default warning message that gets printed, however, there are various failure conditions: - a msr read can fail - a msr write can fail - a msr has an unexpected value - all msrs have unexpected values (disable PMU) Lastly, use %llx to silence checkpatch Signed-off-by: Bandan Das

Re: [PATCH] perf/x86: descriptive failure messages for PMU init

Hi Peter, Peter Zijlstra writes: > On Fri, Apr 12, 2019 at 03:09:17PM -0400, Bandan Das wrote: >> >> There's a default warning message that gets printed, however, >> there are various failure conditions: >> - a msr read can fail >> - a msr write can fail &g

[PATCH] perf/x86: descriptive failure messages for PMU init

ssage in virtualized environment") completely removed printing the msr in question but these messages could be helpful for debugging vPMUs as well. Add them back and change them to pr_debugs, this keeps the behavior the same for baremetal. Lastly, use %llx to silence checkpatch Signed-off-by:

Re: [PATCH] KVM: vmx: speed up MSR bitmap merge

David Hildenbrand writes: ... >> vmx->nested.cached_vmcs12 = kmalloc(VMCS12_SIZE, GFP_KERNEL); >> @@ -10325,36 +10321,43 @@ static inline bool >> nested_vmx_merge_msr_bitmap(struct kvm_vcpu *vcpu, >> /* This shortcut is ok because we support only x2APIC MSRs so far.

Re: [PATCH] KVM: vmx: speed up MSR bitmap merge

David Hildenbrand writes: ... >> vmx->nested.cached_vmcs12 = kmalloc(VMCS12_SIZE, GFP_KERNEL); >> @@ -10325,36 +10321,43 @@ static inline bool >> nested_vmx_merge_msr_bitmap(struct kvm_vcpu *vcpu, >> /* This shortcut is ok because we support only x2APIC MSRs so far. */ >> if

Re: [PATCH] x86/pci: Add a break condition when enabling BAR

Am 07.12.2017 um 09:00 schrieb Bandan Das: >> On an old flaky system with AMD Opteron 6320, boot hangs >> with the following trace since commit fa564ad9: >> >> [ 28.181012] Hardware name: HP ProLiant DL385p Gen8, BIOS A28 09/03/2014 >> [ 28.184022] R

Re: [PATCH] x86/pci: Add a break condition when enabling BAR

Christian König writes: > Hi Bandas, > > thanks for the patch, but this is a known issue with a fix already on > the way into the next -rc. Oh great! Thank you, have a pointer to the patch so that I can test ? > Regards, > Christian. > > Am 07.12.2017 um 09:00 schrieb

[PATCH] x86/pci: Add a break condition when enabling BAR

egions, there will be no way to break out of the loop when enabling 64bit BAR. Add checks and exit the loop in these cases without attempting to enable BAR. Signed-off-by: Bandan Das <b...@redhat.com> --- arch/x86/pci/fixup.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/

[PATCH] x86/pci: Add a break condition when enabling BAR

egions, there will be no way to break out of the loop when enabling 64bit BAR. Add checks and exit the loop in these cases without attempting to enable BAR. Signed-off-by: Bandan Das --- arch/x86/pci/fixup.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/x86/pci/fixup.c

Re: [PATCH v7 0/3] Expose VMFUNC to the nested hypervisor

David Hildenbrand <da...@redhat.com> writes: ... >> v1: >> https://lkml.org/lkml/2017/6/29/958 >> >> Bandan Das (3): >> KVM: vmx: Enable VMFUNCs >> KVM: nVMX: Enable VMFUNC for the L1 hypervisor >> KVM: nVMX: Emulate EPTP switching for the

Re: [PATCH v7 0/3] Expose VMFUNC to the nested hypervisor

David Hildenbrand writes: ... >> v1: >> https://lkml.org/lkml/2017/6/29/958 >> >> Bandan Das (3): >> KVM: vmx: Enable VMFUNCs >> KVM: nVMX: Enable VMFUNC for the L1 hypervisor >> KVM: nVMX: Emulate EPTP switching for the L1 hypervisor >> &

[PATCH v7 1/3] KVM: vmx: Enable VMFUNCs

Enable VMFUNC in the secondary execution controls. This simplifies the changes necessary to expose it to nested hypervisors. VMFUNCs still cause #UD when invoked. Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> Signed-off-by: Bandan Das <b...@redhat.com> --- arch/x86/include/as

[PATCH v7 1/3] KVM: vmx: Enable VMFUNCs

Enable VMFUNC in the secondary execution controls. This simplifies the changes necessary to expose it to nested hypervisors. VMFUNCs still cause #UD when invoked. Signed-off-by: Paolo Bonzini Signed-off-by: Bandan Das --- arch/x86/include/asm/vmx.h | 3 +++ arch/x86/kvm/vmx.c | 22

[PATCH v7 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

When L2 uses vmfunc, L0 utilizes the associated vmexit to emulate a switching of the ept pointer by reloading the guest MMU. Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> Signed-off-by: Bandan Das <b...@redhat.com> --- arch/x86/include/asm/vmx.h | 6 +++ arch/x86/kvm/vmx.c

[PATCH v7 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

When L2 uses vmfunc, L0 utilizes the associated vmexit to emulate a switching of the ept pointer by reloading the guest MMU. Signed-off-by: Paolo Bonzini Signed-off-by: Bandan Das --- arch/x86/include/asm/vmx.h | 6 +++ arch/x86/kvm/vmx.c | 124

[PATCH v7 2/3] KVM: nVMX: Enable VMFUNC for the L1 hypervisor

Expose VMFUNC in MSRs and VMCS fields. No actual VMFUNCs are enabled. Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> Signed-off-by: Bandan Das <b...@redhat.com> --- arch/x86/kvm/vmx.c | 53 +++-- 1 file changed, 51 insertions(+),

Re: [PATCH 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Paolo Bonzini writes: > On 03/08/2017 13:39, David Hildenbrand wrote: >>> + /* AD, if set, should be supported */ >>> + if ((address & VMX_EPT_AD_ENABLE_BIT)) { >>> + if (!enable_ept_ad_bits) >>> + return false; >> In theory (I guess) we would

[PATCH v7 2/3] KVM: nVMX: Enable VMFUNC for the L1 hypervisor

Expose VMFUNC in MSRs and VMCS fields. No actual VMFUNCs are enabled. Signed-off-by: Paolo Bonzini Signed-off-by: Bandan Das --- arch/x86/kvm/vmx.c | 53 +++-- 1 file changed, 51 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/vmx.c b

Re: [PATCH 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Paolo Bonzini writes: > On 03/08/2017 13:39, David Hildenbrand wrote: >>> + /* AD, if set, should be supported */ >>> + if ((address & VMX_EPT_AD_ENABLE_BIT)) { >>> + if (!enable_ept_ad_bits) >>> + return false; >> In theory (I guess) we would have to check here

[PATCH v7 0/3] Expose VMFUNC to the nested hypervisor

oad. These patches expose eptp switching/vmfunc to the nested hypervisor. vmfunc is enabled in the secondary controls for the host and is exposed to the nested hypervisor. However, if the nested hypervisor decides to use eptp switching, L0 emulates it. v1: https://lkml.org/lkml/2017/6/29/958 Ban

[PATCH v7 0/3] Expose VMFUNC to the nested hypervisor

oad. These patches expose eptp switching/vmfunc to the nested hypervisor. vmfunc is enabled in the secondary controls for the host and is exposed to the nested hypervisor. However, if the nested hypervisor decides to use eptp switching, L0 emulates it. v1: https://lkml.org/lkml/2017/6/29/958 Ban

[PATCH v6 1/3] KVM: vmx: Enable VMFUNCs

Enable VMFUNC in the secondary execution controls. This simplifies the changes necessary to expose it to nested hypervisors. VMFUNCs still cause #UD when invoked. Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> Signed-off-by: Bandan Das <b...@redhat.com> --- arch/x86/include/as

[PATCH v6 1/3] KVM: vmx: Enable VMFUNCs

Enable VMFUNC in the secondary execution controls. This simplifies the changes necessary to expose it to nested hypervisors. VMFUNCs still cause #UD when invoked. Signed-off-by: Paolo Bonzini Signed-off-by: Bandan Das --- arch/x86/include/asm/vmx.h | 3 +++ arch/x86/kvm/vmx.c | 22

[PATCH 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

When L2 uses vmfunc, L0 utilizes the associated vmexit to emulate a switching of the ept pointer by reloading the guest MMU. Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> Signed-off-by: Bandan Das <b...@redhat.com> --- arch/x86/include/asm/vmx.h | 6 +++ arch/x86/kvm/vmx.c

[PATCH v6 2/3] KVM: nVMX: Enable VMFUNC for the L1 hypervisor

Expose VMFUNC in MSRs and VMCS fields. No actual VMFUNCs are enabled. Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> Signed-off-by: Bandan Das <b...@redhat.com> --- arch/x86/kvm/vmx.c | 53 +++-- 1 file changed, 51 insertions(+),

[PATCH 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

When L2 uses vmfunc, L0 utilizes the associated vmexit to emulate a switching of the ept pointer by reloading the guest MMU. Signed-off-by: Paolo Bonzini Signed-off-by: Bandan Das --- arch/x86/include/asm/vmx.h | 6 +++ arch/x86/kvm/vmx.c | 130

[PATCH v6 2/3] KVM: nVMX: Enable VMFUNC for the L1 hypervisor

Expose VMFUNC in MSRs and VMCS fields. No actual VMFUNCs are enabled. Signed-off-by: Paolo Bonzini Signed-off-by: Bandan Das --- arch/x86/kvm/vmx.c | 53 +++-- 1 file changed, 51 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/vmx.c b

[PATCH v6 0/3] Expose VMFUNC to the nested hypervisor

led in the secondary controls for the host and is exposed to the nested hypervisor. However, if the nested hypervisor decides to use eptp switching, L0 emulates it. v1: https://lkml.org/lkml/2017/6/29/958 Bandan Das (3): KVM: vmx: Enable VMFUNCs KVM: nVMX: Enable VMFUNC for the L1 hypervisor KVM: n

[PATCH v6 0/3] Expose VMFUNC to the nested hypervisor

led in the secondary controls for the host and is exposed to the nested hypervisor. However, if the nested hypervisor decides to use eptp switching, L0 emulates it. v1: https://lkml.org/lkml/2017/6/29/958 Bandan Das (3): KVM: vmx: Enable VMFUNCs KVM: nVMX: Enable VMFUNC for the L1 hypervisor KVM: n

Re: [PATCH v5 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář <rkrc...@redhat.com> writes: > 2017-07-28 15:52-0400, Bandan Das: >> When L2 uses vmfunc, L0 utilizes the associated vmexit to >> emulate a switching of the ept pointer by reloading the >> guest MMU. >> >> Signed-off-by: Paolo Bonzini <pbo

Re: [PATCH v5 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář writes: > 2017-07-28 15:52-0400, Bandan Das: >> When L2 uses vmfunc, L0 utilizes the associated vmexit to >> emulate a switching of the ept pointer by reloading the >> guest MMU. >> >> Signed-off-by: Paolo Bonzini >> Signed-off-by: Bandan D

Re: [PATCH v5 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Hi David, David Hildenbrand writes: >> +static inline bool nested_cpu_has_eptp_switching(struct vmcs12 *vmcs12) >> +{ >> +return nested_cpu_has_vmfunc(vmcs12) && >> +(vmcs12->vm_function_control & >> + VMX_VMFUNC_EPTP_SWITCHING); >> +} >> + >>

Re: [PATCH v5 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Hi David, David Hildenbrand writes: >> +static inline bool nested_cpu_has_eptp_switching(struct vmcs12 *vmcs12) >> +{ >> +return nested_cpu_has_vmfunc(vmcs12) && >> +(vmcs12->vm_function_control & >> + VMX_VMFUNC_EPTP_SWITCHING); >> +} >> + >> static inline bool

Re: [RFC PATCH v2 00/38] Nested Virtualization on KVM/ARM

Jintack Lim writes: ... >> >> I'll share my experiment setup shortly. > > I summarized my experiment setup here. > > https://github.com/columbia/nesting-pub/wiki/Nested-virtualization-on-ARM-setup Thanks Jintack! I was able to test L2 boot up with these instructions.

Re: [RFC PATCH v2 00/38] Nested Virtualization on KVM/ARM

Jintack Lim writes: ... >> >> I'll share my experiment setup shortly. > > I summarized my experiment setup here. > > https://github.com/columbia/nesting-pub/wiki/Nested-virtualization-on-ARM-setup Thanks Jintack! I was able to test L2 boot up with these instructions. Next, I will try to run

[PATCH v5 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

When L2 uses vmfunc, L0 utilizes the associated vmexit to emulate a switching of the ept pointer by reloading the guest MMU. Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> Signed-off-by: Bandan Das <b...@redhat.com> --- arch/x86/include/asm/vmx.h | 6 +++ arch/x86/kvm/vmx.c

[PATCH v5 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

When L2 uses vmfunc, L0 utilizes the associated vmexit to emulate a switching of the ept pointer by reloading the guest MMU. Signed-off-by: Paolo Bonzini Signed-off-by: Bandan Das --- arch/x86/include/asm/vmx.h | 6 +++ arch/x86/kvm/vmx.c | 124

[PATCH v5 2/3] KVM: nVMX: Enable VMFUNC for the L1 hypervisor

Expose VMFUNC in MSRs and VMCS fields. No actual VMFUNCs are enabled. Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> Signed-off-by: Bandan Das <b...@redhat.com> --- arch/x86/kvm/vmx.c | 53 +++-- 1 file changed, 51 insertions(+),

[PATCH v5 2/3] KVM: nVMX: Enable VMFUNC for the L1 hypervisor

Expose VMFUNC in MSRs and VMCS fields. No actual VMFUNCs are enabled. Signed-off-by: Paolo Bonzini Signed-off-by: Bandan Das --- arch/x86/kvm/vmx.c | 53 +++-- 1 file changed, 51 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/vmx.c b

[PATCH v5 0/3] Expose VMFUNC to the nested hypervisor

controls for the host and is exposed to the nested hypervisor. However, if the nested hypervisor decides to use eptp switching, L0 emulates it. v1: https://lkml.org/lkml/2017/6/29/958 Bandan Das (3): KVM: vmx: Enable VMFUNCs KVM: nVMX: Enable VMFUNC for the L1 hypervisor KVM: nVMX: Emulate

[PATCH v5 0/3] Expose VMFUNC to the nested hypervisor

controls for the host and is exposed to the nested hypervisor. However, if the nested hypervisor decides to use eptp switching, L0 emulates it. v1: https://lkml.org/lkml/2017/6/29/958 Bandan Das (3): KVM: vmx: Enable VMFUNCs KVM: nVMX: Enable VMFUNC for the L1 hypervisor KVM: nVMX: Emulate

[PATCH v5 1/3] KVM: vmx: Enable VMFUNCs

Enable VMFUNC in the secondary execution controls. This simplifies the changes necessary to expose it to nested hypervisors. VMFUNCs still cause #UD when invoked. Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> Signed-off-by: Bandan Das <b...@redhat.com> --- arch/x86/include/as

[PATCH v5 1/3] KVM: vmx: Enable VMFUNCs

Enable VMFUNC in the secondary execution controls. This simplifies the changes necessary to expose it to nested hypervisors. VMFUNCs still cause #UD when invoked. Signed-off-by: Paolo Bonzini Signed-off-by: Bandan Das --- arch/x86/include/asm/vmx.h | 3 +++ arch/x86/kvm/vmx.c | 22

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář <rkrc...@redhat.com> writes: > 2017-07-17 13:58-0400, Bandan Das: >> Radim Krčmář <rkrc...@redhat.com> writes: >> ... >>>> > and no other mentions of a VM exit, so I think that the VM exit happens >>>> > only under these co

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář writes: > 2017-07-17 13:58-0400, Bandan Das: >> Radim Krčmář writes: >> ... >>>> > and no other mentions of a VM exit, so I think that the VM exit happens >>>> > only under these conditions: >>>> > >>

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář writes: ... >> > and no other mentions of a VM exit, so I think that the VM exit happens >> > only under these conditions: >> > >> > — The EPT memory type (bits 2:0) must be a value supported by the >> > processor as indicated in the IA32_VMX_EPT_VPID_CAP

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář writes: ... >> > and no other mentions of a VM exit, so I think that the VM exit happens >> > only under these conditions: >> > >> > — The EPT memory type (bits 2:0) must be a value supported by the >> > processor as indicated in the IA32_VMX_EPT_VPID_CAP MSR (see >> >

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

David Hildenbrand writes: + /* + * If the (L2) guest does a vmfunc to the currently + * active ept pointer, we don't have to do anything else + */ + if (vmcs12->ept_pointer != address) { + if (address >> cpuid_maxphyaddr(vcpu) ||

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

David Hildenbrand writes: + /* + * If the (L2) guest does a vmfunc to the currently + * active ept pointer, we don't have to do anything else + */ + if (vmcs12->ept_pointer != address) { + if (address >> cpuid_maxphyaddr(vcpu) || +

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář writes: ... >> Why do you think it's a bug ? > > SDM defines a different behavior and hardware doesn't do that either. > There are only two reasons for a VMFUNC VM exit from EPTP switching: > > 1) ECX > 0 > 2) EPTP would cause VM entry to fail if in

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář writes: ... >> Why do you think it's a bug ? > > SDM defines a different behavior and hardware doesn't do that either. > There are only two reasons for a VMFUNC VM exit from EPTP switching: > > 1) ECX > 0 > 2) EPTP would cause VM entry to fail if in VMCS.EPT_POINTER > > KVM can

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář writes: ... >> > Thanks, we're not here to judge the guest, but to provide a bare-metal >> > experience. :) >> >> There are certain cases where do. For example, when L2 instruction emulation >> fails we decide to kill L2 instead of injecting the error to L1 and

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář writes: ... >> > Thanks, we're not here to judge the guest, but to provide a bare-metal >> > experience. :) >> >> There are certain cases where do. For example, when L2 instruction emulation >> fails we decide to kill L2 instead of injecting the error to L1 and let it >> handle >>

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář <rkrc...@redhat.com> writes: > 2017-07-11 16:34-0400, Bandan Das: >> Radim Krčmář <rkrc...@redhat.com> writes: >> >> > 2017-07-11 15:50-0400, Bandan Das: >> >> Radim Krčmář <rkrc...@redhat.com> writes: >> >> > 20

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář writes: > 2017-07-11 16:34-0400, Bandan Das: >> Radim Krčmář writes: >> >> > 2017-07-11 15:50-0400, Bandan Das: >> >> Radim Krčmář writes: >> >> > 2017-07-11 14:24-0400, Bandan Das: >> >> >> Bandan Das w

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář <rkrc...@redhat.com> writes: > 2017-07-11 15:38-0400, Bandan Das: >> Radim Krčmář <rkrc...@redhat.com> writes: >> >> > 2017-07-11 14:35-0400, Bandan Das: >> >> Jim Mattson <jmatt...@google.com> writes: >> >> ...

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář writes: > 2017-07-11 15:38-0400, Bandan Das: >> Radim Krčmář writes: >> >> > 2017-07-11 14:35-0400, Bandan Das: >> >> Jim Mattson writes: >> >> ... >> >> >>> I can find the definition for an vmexit i

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář <rkrc...@redhat.com> writes: > 2017-07-11 15:50-0400, Bandan Das: >> Radim Krčmář <rkrc...@redhat.com> writes: >> > 2017-07-11 14:24-0400, Bandan Das: >> >> Bandan Das <b...@redhat.com> writes: >> >> > If there's a t

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář writes: > 2017-07-11 15:50-0400, Bandan Das: >> Radim Krčmář writes: >> > 2017-07-11 14:24-0400, Bandan Das: >> >> Bandan Das writes: >> >> > If there's a triple fault, I think it's a good idea to inject it >> >> > bac

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář <rkrc...@redhat.com> writes: > 2017-07-11 14:24-0400, Bandan Das: >> Bandan Das <b...@redhat.com> writes: >> > If there's a triple fault, I think it's a good idea to inject it >> > back. Basically, there's no need to take care of damage cont

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář writes: > 2017-07-11 14:24-0400, Bandan Das: >> Bandan Das writes: >> > If there's a triple fault, I think it's a good idea to inject it >> > back. Basically, there's no need to take care of damage control >>

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář <rkrc...@redhat.com> writes: > 2017-07-11 14:35-0400, Bandan Das: >> Jim Mattson <jmatt...@google.com> writes: >> ... >> >>> I can find the definition for an vmexit in case of index >= >> >>> VMFUNC_EPTP_ENTRIES, but not

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář writes: > 2017-07-11 14:35-0400, Bandan Das: >> Jim Mattson writes: >> ... >> >>> I can find the definition for an vmexit in case of index >= >> >>> VMFUNC_EPTP_ENTRIES, but not for !vmcs12->eptp_list_address in the SDM. >&g

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář <rkrc...@redhat.com> writes: > 2017-07-11 14:05-0400, Bandan Das: >> Radim Krčmář <rkrc...@redhat.com> writes: >> >> > [David did a great review, so I'll just point out things I noticed.] >> > >> > 2017-07-11 09:51+0200, David Hi

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář writes: > 2017-07-11 14:05-0400, Bandan Das: >> Radim Krčmář writes: >> >> > [David did a great review, so I'll just point out things I noticed.] >> > >> > 2017-07-11 09:51+0200, David Hildenbrand: >> >> On 10.07.2017 22

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Jim Mattson writes: ... >>> I can find the definition for an vmexit in case of index >= >>> VMFUNC_EPTP_ENTRIES, but not for !vmcs12->eptp_list_address in the SDM. >>> >>> Can you give me a hint? >> >> I don't think there is. Since, we are basically emulating eptp switching

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Jim Mattson writes: ... >>> I can find the definition for an vmexit in case of index >= >>> VMFUNC_EPTP_ENTRIES, but not for !vmcs12->eptp_list_address in the SDM. >>> >>> Can you give me a hint? >> >> I don't think there is. Since, we are basically emulating eptp switching >> for L2, this is a

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Bandan Das <b...@redhat.com> writes: >>> + /* >>> +* If the (L2) guest does a vmfunc to the currently >>> +* active ept pointer, we don't have to do anything else >>> +*/ >>> + if (vmcs12->ept_pointer != address)

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Bandan Das writes: >>> + /* >>> +* If the (L2) guest does a vmfunc to the currently >>> +* active ept pointer, we don't have to do anything else >>> +*/ >>> + if (vmcs12->ept_pointer != address) { >

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář <rkrc...@redhat.com> writes: > [David did a great review, so I'll just point out things I noticed.] > > 2017-07-11 09:51+0200, David Hildenbrand: >> On 10.07.2017 22:49, Bandan Das wrote: >> > When L2 uses vmfunc, L0 utilizes the associated vmex

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář writes: > [David did a great review, so I'll just point out things I noticed.] > > 2017-07-11 09:51+0200, David Hildenbrand: >> On 10.07.2017 22:49, Bandan Das wrote: >> > When L2 uses vmfunc, L0 utilizes the associated vmexit to >> > emula

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

David Hildenbrand <da...@redhat.com> writes: > On 10.07.2017 22:49, Bandan Das wrote: >> When L2 uses vmfunc, L0 utilizes the associated vmexit to >> emulate a switching of the ept pointer by reloading the >> guest MMU. >> >> Signed-off-by: Paolo Bonz

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

David Hildenbrand writes: > On 10.07.2017 22:49, Bandan Das wrote: >> When L2 uses vmfunc, L0 utilizes the associated vmexit to >> emulate a switching of the ept pointer by reloading the >> guest MMU. >> >> Signed-off-by: Paolo Bonzini >> Signed-off-by:

[PATCH v4 1/3] KVM: vmx: Enable VMFUNCs

Enable VMFUNC in the secondary execution controls. This simplifies the changes necessary to expose it to nested hypervisors. VMFUNCs still cause #UD when invoked. Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> Signed-off-by: Bandan Das <b...@redhat.com> --- arch/x86/include/as

[PATCH v4 1/3] KVM: vmx: Enable VMFUNCs

Enable VMFUNC in the secondary execution controls. This simplifies the changes necessary to expose it to nested hypervisors. VMFUNCs still cause #UD when invoked. Signed-off-by: Paolo Bonzini Signed-off-by: Bandan Das --- arch/x86/include/asm/vmx.h | 3 +++ arch/x86/kvm/vmx.c | 22

[PATCH v4 0/3] Expose VMFUNC to the nested hypervisor

it. v1: https://lkml.org/lkml/2017/6/29/958 Bandan Das (3): KVM: vmx: Enable VMFUNCs KVM: nVMX: Enable VMFUNC for the L1 hypervisor KVM: nVMX: Emulate EPTP switching for the L1 hypervisor arch/x86/include/asm/vmx.h | 9 arch/x86/kvm/vmx.c | 125

[PATCH v4 0/3] Expose VMFUNC to the nested hypervisor

it. v1: https://lkml.org/lkml/2017/6/29/958 Bandan Das (3): KVM: vmx: Enable VMFUNCs KVM: nVMX: Enable VMFUNC for the L1 hypervisor KVM: nVMX: Emulate EPTP switching for the L1 hypervisor arch/x86/include/asm/vmx.h | 9 arch/x86/kvm/vmx.c | 125

[PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

When L2 uses vmfunc, L0 utilizes the associated vmexit to emulate a switching of the ept pointer by reloading the guest MMU. Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> Signed-off-by: Bandan Das <b...@redhat.com> --- arch/x86/include/asm/vmx.h | 6 + arch/x86/kvm/vmx.c

[PATCH v4 2/3] KVM: nVMX: Enable VMFUNC for the L1 hypervisor

Expose VMFUNC in MSRs and VMCS fields. No actual VMFUNCs are enabled. Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> Signed-off-by: Bandan Das <b...@redhat.com> Reviewed-by: David Hildenbrand <da...@redhat.com> --- arch/

[PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

When L2 uses vmfunc, L0 utilizes the associated vmexit to emulate a switching of the ept pointer by reloading the guest MMU. Signed-off-by: Paolo Bonzini Signed-off-by: Bandan Das --- arch/x86/include/asm/vmx.h | 6 + arch/x86/kvm/vmx.c | 58

[PATCH v4 2/3] KVM: nVMX: Enable VMFUNC for the L1 hypervisor

Expose VMFUNC in MSRs and VMCS fields. No actual VMFUNCs are enabled. Signed-off-by: Paolo Bonzini Signed-off-by: Bandan Das Reviewed-by: David Hildenbrand --- arch/x86/kvm/vmx.c | 53 +++-- 1 file changed, 51 insertions(+), 2 deletions(-) diff

Re: [PATCH v3 2/3] KVM: nVMX: Enable VMFUNC for the L1 hypervisor

David Hildenbrand writes: >> -kvm_queue_exception(vcpu, UD_VECTOR); >> +struct vcpu_vmx *vmx = to_vmx(vcpu); >> +struct vmcs12 *vmcs12; >> +u32 function = vcpu->arch.regs[VCPU_REGS_RAX]; >> + >> +/* >> + * VMFUNC is only supported for nested guests, but

  1   2   3   4   5   6   >