* [PATCH 0/2] KVM: x86: avoid simultaneous queueing of both IRQ and SMI @ 2016-06-01 12:34 Paolo Bonzini 2016-06-01 12:35 ` [PATCH 1/2] " Paolo Bonzini 2016-06-01 12:35 ` [PATCH 2/2] KVM: x86: rename process_smi to enter_smm, process_smi_request to process_smi Paolo Bonzini 0 siblings, 2 replies; 8+ messages in thread From: Paolo Bonzini @ 2016-06-01 12:34 UTC (permalink / raw) To: linux-kernel, kvm This was reported as a vmentry failure while running Windows with SMM enabled. It's not that rare if your processor lacks APICv---it happens about 20-30% of the time while installing Windows 10. I now understand the interrupt injection code (especially complete_interrupts) better, and I also understand why the shortcut I took in SMI handling was a bad idea. In the end the code is somewhat simpler with the patch applied than before. The bug report is at https://github.com/tianocore/edk2/issues/91, but it also fixes other Windows failures that Laszlo had reported to me privately. Paolo Paolo Bonzini (2): KVM: x86: avoid simultaneous queueing of both IRQ and SMI KVM: x86: rename process_smi to enter_smm, process_smi_request to process_smi arch/x86/kvm/x86.c | 75 ++++++++++++++++++++++++++++++++---------------------- 1 file changed, 44 insertions(+), 31 deletions(-) -- 1.8.3.1 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 1/2] KVM: x86: avoid simultaneous queueing of both IRQ and SMI 2016-06-01 12:34 [PATCH 0/2] KVM: x86: avoid simultaneous queueing of both IRQ and SMI Paolo Bonzini @ 2016-06-01 12:35 ` Paolo Bonzini 2016-06-01 16:40 ` Radim Krčmář 2016-06-01 12:35 ` [PATCH 2/2] KVM: x86: rename process_smi to enter_smm, process_smi_request to process_smi Paolo Bonzini 1 sibling, 1 reply; 8+ messages in thread From: Paolo Bonzini @ 2016-06-01 12:35 UTC (permalink / raw) To: linux-kernel, kvm; +Cc: stable If the processor exits to KVM while delivering an interrupt, the hypervisor then requeues the interrupt for the next vmentry. Trying to enter SMM in this same window causes to enter non-root mode in emulated SMM (i.e. with IF=0) and with a request to inject an IRQ (i.e. with a valid VM-entry interrupt info field). This is invalid guest state (SDM 26.3.1.4 "Check on Guest RIP and RFLAGS") and the processor fails vmentry. The fix is to defer the injection from KVM_REQ_SMI to KVM_REQ_EVENT, like we already do for e.g. NMIs. This patch doesn't change the name of the process_smi function so that it can be applied to stable releases. The next patch will modify the names so that process_nmi and process_smi process respectively KVM_REQ_NMI and KVM_REQ_SMI. This is especially common with Windows, probably due to the self-IPI trick that it uses to deliver deferred procedure calls (DPCs). Reported-by: Laszlo Ersek <lersek@redhat.com> Fixes: 64d6067057d9658acb8675afcfba549abdb7fc16 Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> --- arch/x86/kvm/x86.c | 44 ++++++++++++++++++++++++++++---------------- 1 file changed, 28 insertions(+), 16 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index c805cf494154..271585574a9f 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -91,6 +91,7 @@ static u64 __read_mostly efer_reserved_bits = ~((u64)EFER_SCE); static void update_cr8_intercept(struct kvm_vcpu *vcpu); static void process_nmi(struct kvm_vcpu *vcpu); +static void process_smi(struct kvm_vcpu *vcpu); static void __kvm_set_rflags(struct kvm_vcpu *vcpu, unsigned long rflags); struct kvm_x86_ops *kvm_x86_ops __read_mostly; @@ -5292,13 +5293,8 @@ static void kvm_smm_changed(struct kvm_vcpu *vcpu) /* This is a good place to trace that we are exiting SMM. */ trace_kvm_enter_smm(vcpu->vcpu_id, vcpu->arch.smbase, false); - if (unlikely(vcpu->arch.smi_pending)) { - kvm_make_request(KVM_REQ_SMI, vcpu); - vcpu->arch.smi_pending = 0; - } else { - /* Process a latched INIT, if any. */ - kvm_make_request(KVM_REQ_EVENT, vcpu); - } + /* Process a latched INIT or SMI, if any. */ + kvm_make_request(KVM_REQ_EVENT, vcpu); } kvm_mmu_reset_context(vcpu); @@ -6098,7 +6094,10 @@ static int inject_pending_event(struct kvm_vcpu *vcpu, bool req_int_win) } /* try to inject new event if pending */ - if (vcpu->arch.nmi_pending && kvm_x86_ops->nmi_allowed(vcpu)) { + if (vcpu->arch.smi_pending && !is_smm(vcpu)) { + --vcpu->arch.smi_pending; + process_smi(vcpu); + } else if (vcpu->arch.nmi_pending && kvm_x86_ops->nmi_allowed(vcpu)) { --vcpu->arch.nmi_pending; vcpu->arch.nmi_injected = true; kvm_x86_ops->set_nmi(vcpu); @@ -6308,11 +6307,6 @@ static void process_smi(struct kvm_vcpu *vcpu) char buf[512]; u32 cr0; - if (is_smm(vcpu)) { - vcpu->arch.smi_pending = true; - return; - } - trace_kvm_enter_smm(vcpu->vcpu_id, vcpu->arch.smbase, true); vcpu->arch.hflags |= HF_SMM_MASK; memset(buf, 0, 512); @@ -6375,6 +6369,12 @@ static void process_smi(struct kvm_vcpu *vcpu) kvm_mmu_reset_context(vcpu); } +static void process_smi_request(struct kvm_vcpu *vcpu) +{ + vcpu->arch.smi_pending = true; + kvm_make_request(KVM_REQ_EVENT, vcpu); +} + void kvm_make_scan_ioapic_request(struct kvm *kvm) { kvm_make_all_cpus_request(kvm, KVM_REQ_SCAN_IOAPIC); @@ -6496,7 +6496,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) if (kvm_check_request(KVM_REQ_STEAL_UPDATE, vcpu)) record_steal_time(vcpu); if (kvm_check_request(KVM_REQ_SMI, vcpu)) - process_smi(vcpu); + process_smi_request(vcpu); if (kvm_check_request(KVM_REQ_NMI, vcpu)) process_nmi(vcpu); if (kvm_check_request(KVM_REQ_PMU, vcpu)) @@ -6569,8 +6569,18 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) if (inject_pending_event(vcpu, req_int_win) != 0) req_immediate_exit = true; - /* enable NMI/IRQ window open exits if needed */ else { + /* Enable NMI/IRQ window open exits if needed. + * + * SMIs have two cases: 1) they can be nested, and + * then there is nothing to do here because RSM will + * cause a vmexit anyway; 2) or the SMI can be pending + * because inject_pending_event has completed the + * injection of an IRQ or NMI from the previous vmexit, + * and then we request an immediate exit to inject the SMI. + */ + if (vcpu->arch.smi_pending && !is_smm(vcpu)) + req_immediate_exit = true; if (vcpu->arch.nmi_pending) kvm_x86_ops->enable_nmi_window(vcpu); if (kvm_cpu_has_injectable_intr(vcpu) || req_int_win) @@ -6621,8 +6631,10 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) kvm_load_guest_xcr0(vcpu); - if (req_immediate_exit) + if (req_immediate_exit) { + kvm_make_request(KVM_REQ_EVENT, vcpu); smp_send_reschedule(vcpu->cpu); + } trace_kvm_entry(vcpu->vcpu_id); wait_lapic_expire(vcpu); -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] KVM: x86: avoid simultaneous queueing of both IRQ and SMI 2016-06-01 12:35 ` [PATCH 1/2] " Paolo Bonzini @ 2016-06-01 16:40 ` Radim Krčmář 2016-06-01 18:06 ` Paolo Bonzini 0 siblings, 1 reply; 8+ messages in thread From: Radim Krčmář @ 2016-06-01 16:40 UTC (permalink / raw) To: Paolo Bonzini; +Cc: linux-kernel, kvm, stable 2016-06-01 14:35+0200, Paolo Bonzini: > If the processor exits to KVM while delivering an interrupt, > the hypervisor then requeues the interrupt for the next vmentry. > Trying to enter SMM in this same window causes to enter non-root > mode in emulated SMM (i.e. with IF=0) and with a request to > inject an IRQ (i.e. with a valid VM-entry interrupt info field). > This is invalid guest state (SDM 26.3.1.4 "Check on Guest RIP > and RFLAGS") and the processor fails vmentry. > > The fix is to defer the injection from KVM_REQ_SMI to KVM_REQ_EVENT, > like we already do for e.g. NMIs. This patch doesn't change the > name of the process_smi function so that it can be applied to > stable releases. The next patch will modify the names so that > process_nmi and process_smi process respectively KVM_REQ_NMI and > KVM_REQ_SMI. > > This is especially common with Windows, probably due to the > self-IPI trick that it uses to deliver deferred procedure > calls (DPCs). > > Reported-by: Laszlo Ersek <lersek@redhat.com> > Fixes: 64d6067057d9658acb8675afcfba549abdb7fc16 > Cc: stable@vger.kernel.org > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > --- > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > @@ -6098,7 +6094,10 @@ static int inject_pending_event(struct kvm_vcpu *vcpu, bool req_int_win) > } > > /* try to inject new event if pending */ > - if (vcpu->arch.nmi_pending && kvm_x86_ops->nmi_allowed(vcpu)) { > + if (vcpu->arch.smi_pending && !is_smm(vcpu)) { Clearing smi_pending in kvm_vcpu_reset() would be safer now that SMI can be injected without a request or RSM. > + --vcpu->arch.smi_pending; (I'd use 'vcpu->arch.smi_pending = false', to make it clearer that we don't want multiple pending SMIs, unlike NMIs. smi_pending is bool, so the generated code should be identical.) > + process_smi(vcpu); > + } else if (vcpu->arch.nmi_pending && kvm_x86_ops->nmi_allowed(vcpu)) { > --vcpu->arch.nmi_pending; > @@ -6621,8 +6631,10 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) > > kvm_load_guest_xcr0(vcpu); > > - if (req_immediate_exit) > + if (req_immediate_exit) { > + kvm_make_request(KVM_REQ_EVENT, vcpu); > smp_send_reschedule(vcpu->cpu); (Is this a fix for non-smi cases too?) Thanks. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] KVM: x86: avoid simultaneous queueing of both IRQ and SMI 2016-06-01 16:40 ` Radim Krčmář @ 2016-06-01 18:06 ` Paolo Bonzini 2016-06-05 3:28 ` Wanpeng Li 0 siblings, 1 reply; 8+ messages in thread From: Paolo Bonzini @ 2016-06-01 18:06 UTC (permalink / raw) To: Radim Krčmář; +Cc: linux-kernel, kvm, stable On 01/06/2016 18:40, Radim Krčmář wrote: > 2016-06-01 14:35+0200, Paolo Bonzini: >> If the processor exits to KVM while delivering an interrupt, >> the hypervisor then requeues the interrupt for the next vmentry. >> Trying to enter SMM in this same window causes to enter non-root >> mode in emulated SMM (i.e. with IF=0) and with a request to >> inject an IRQ (i.e. with a valid VM-entry interrupt info field). >> This is invalid guest state (SDM 26.3.1.4 "Check on Guest RIP >> and RFLAGS") and the processor fails vmentry. >> >> The fix is to defer the injection from KVM_REQ_SMI to KVM_REQ_EVENT, >> like we already do for e.g. NMIs. This patch doesn't change the >> name of the process_smi function so that it can be applied to >> stable releases. The next patch will modify the names so that >> process_nmi and process_smi process respectively KVM_REQ_NMI and >> KVM_REQ_SMI. >> >> This is especially common with Windows, probably due to the >> self-IPI trick that it uses to deliver deferred procedure >> calls (DPCs). >> >> Reported-by: Laszlo Ersek <lersek@redhat.com> >> Fixes: 64d6067057d9658acb8675afcfba549abdb7fc16 >> Cc: stable@vger.kernel.org >> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> >> --- >> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >> @@ -6098,7 +6094,10 @@ static int inject_pending_event(struct kvm_vcpu *vcpu, bool req_int_win) >> } >> >> /* try to inject new event if pending */ >> - if (vcpu->arch.nmi_pending && kvm_x86_ops->nmi_allowed(vcpu)) { >> + if (vcpu->arch.smi_pending && !is_smm(vcpu)) { > > Clearing smi_pending in kvm_vcpu_reset() would be safer now that SMI can > be injected without a request or RSM. Indeed. >> + --vcpu->arch.smi_pending; > > (I'd use 'vcpu->arch.smi_pending = false', to make it clearer that we > don't want multiple pending SMIs, unlike NMIs. smi_pending is bool, > so the generated code should be identical.) Right. Making the code superficially similar for SMI and NMI was nice; however, as discussed a while ago we could probably make nmi_pending a bool too. >> + process_smi(vcpu); >> + } else if (vcpu->arch.nmi_pending && kvm_x86_ops->nmi_allowed(vcpu)) { >> --vcpu->arch.nmi_pending; > > >> @@ -6621,8 +6631,10 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) >> >> kvm_load_guest_xcr0(vcpu); >> >> - if (req_immediate_exit) >> + if (req_immediate_exit) { >> + kvm_make_request(KVM_REQ_EVENT, vcpu); >> smp_send_reschedule(vcpu->cpu); > > (Is this a fix for non-smi cases too?) No, I don't think so, the existing req_immediate_exit case is only after a VMLAUNCH/VMRESUME vmexit, in which case we already have a if (vmx->nested.nested_run_pending) kvm_make_request(KVM_REQ_EVENT, vcpu); in vmx_vcpu_run. Thanks for the fast review, I'll try to post v2 as soon as possible. Paolo ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] KVM: x86: avoid simultaneous queueing of both IRQ and SMI 2016-06-01 18:06 ` Paolo Bonzini @ 2016-06-05 3:28 ` Wanpeng Li 2016-06-06 8:10 ` Paolo Bonzini 0 siblings, 1 reply; 8+ messages in thread From: Wanpeng Li @ 2016-06-05 3:28 UTC (permalink / raw) To: Paolo Bonzini Cc: Radim Krčmář, linux-kernel, kvm, stable, J. Kiszka 2016-06-02 2:06 GMT+08:00 Paolo Bonzini <pbonzini@redhat.com>: > > > On 01/06/2016 18:40, Radim Krčmář wrote: >> 2016-06-01 14:35+0200, Paolo Bonzini: >>> If the processor exits to KVM while delivering an interrupt, >>> the hypervisor then requeues the interrupt for the next vmentry. >>> Trying to enter SMM in this same window causes to enter non-root >>> mode in emulated SMM (i.e. with IF=0) and with a request to >>> inject an IRQ (i.e. with a valid VM-entry interrupt info field). >>> This is invalid guest state (SDM 26.3.1.4 "Check on Guest RIP >>> and RFLAGS") and the processor fails vmentry. >>> >>> The fix is to defer the injection from KVM_REQ_SMI to KVM_REQ_EVENT, >>> like we already do for e.g. NMIs. This patch doesn't change the >>> name of the process_smi function so that it can be applied to >>> stable releases. The next patch will modify the names so that >>> process_nmi and process_smi process respectively KVM_REQ_NMI and >>> KVM_REQ_SMI. >>> >>> This is especially common with Windows, probably due to the >>> self-IPI trick that it uses to deliver deferred procedure >>> calls (DPCs). >>> >>> Reported-by: Laszlo Ersek <lersek@redhat.com> >>> Fixes: 64d6067057d9658acb8675afcfba549abdb7fc16 >>> Cc: stable@vger.kernel.org >>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> >>> --- >>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >>> @@ -6098,7 +6094,10 @@ static int inject_pending_event(struct kvm_vcpu *vcpu, bool req_int_win) >>> } >>> >>> /* try to inject new event if pending */ >>> - if (vcpu->arch.nmi_pending && kvm_x86_ops->nmi_allowed(vcpu)) { >>> + if (vcpu->arch.smi_pending && !is_smm(vcpu)) { >> >> Clearing smi_pending in kvm_vcpu_reset() would be safer now that SMI can >> be injected without a request or RSM. > > Indeed. > >>> + --vcpu->arch.smi_pending; >> >> (I'd use 'vcpu->arch.smi_pending = false', to make it clearer that we >> don't want multiple pending SMIs, unlike NMIs. smi_pending is bool, >> so the generated code should be identical.) > > Right. Making the code superficially similar for SMI and NMI was nice; > however, as discussed a while ago we could probably make nmi_pending a > bool too. > >>> + process_smi(vcpu); >>> + } else if (vcpu->arch.nmi_pending && kvm_x86_ops->nmi_allowed(vcpu)) { >>> --vcpu->arch.nmi_pending; >> >> >>> @@ -6621,8 +6631,10 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) >>> >>> kvm_load_guest_xcr0(vcpu); >>> >>> - if (req_immediate_exit) >>> + if (req_immediate_exit) { >>> + kvm_make_request(KVM_REQ_EVENT, vcpu); >>> smp_send_reschedule(vcpu->cpu); >> >> (Is this a fix for non-smi cases too?) > > No, I don't think so, the existing req_immediate_exit case is only after > a VMLAUNCH/VMRESUME vmexit, in which case we already have a > > if (vmx->nested.nested_run_pending) > kvm_make_request(KVM_REQ_EVENT, vcpu); > > in vmx_vcpu_run. Do you think this can be removed since it blindly request a KVM_REQ_EVENT even if there is no still-pending event to L1 which blocked by nested_run_pending, however, req_immediate_exit can indicate there is a pending event blocked by nested_run_pending and the request KVM_REQUEST_EVENT added in your patch can guarantee inject this pending event in the next nested vmexit. Regards, Wanpeng Li ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] KVM: x86: avoid simultaneous queueing of both IRQ and SMI 2016-06-05 3:28 ` Wanpeng Li @ 2016-06-06 8:10 ` Paolo Bonzini 2016-06-06 8:25 ` Wanpeng Li 0 siblings, 1 reply; 8+ messages in thread From: Paolo Bonzini @ 2016-06-06 8:10 UTC (permalink / raw) To: Wanpeng Li Cc: Radim Krčmář, linux-kernel, kvm, stable, J. Kiszka On 05/06/2016 05:28, Wanpeng Li wrote: >> > No, I don't think so, the existing req_immediate_exit case is only after >> > a VMLAUNCH/VMRESUME vmexit, in which case we already have a >> > >> > if (vmx->nested.nested_run_pending) >> > kvm_make_request(KVM_REQ_EVENT, vcpu); >> > >> > in vmx_vcpu_run. > Do you think this can be removed since it blindly request a > KVM_REQ_EVENT even if there is no still-pending event to L1 which > blocked by nested_run_pending, however, req_immediate_exit can > indicate there is a pending event blocked by nested_run_pending and > the request KVM_REQUEST_EVENT added in your patch can guarantee inject > this pending event in the next nested vmexit. Yes, I think so. Thanks, Paolo ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] KVM: x86: avoid simultaneous queueing of both IRQ and SMI 2016-06-06 8:10 ` Paolo Bonzini @ 2016-06-06 8:25 ` Wanpeng Li 0 siblings, 0 replies; 8+ messages in thread From: Wanpeng Li @ 2016-06-06 8:25 UTC (permalink / raw) To: Paolo Bonzini Cc: Radim Krčmář, linux-kernel, kvm, stable, J. Kiszka 2016-06-06 16:10 GMT+08:00 Paolo Bonzini <pbonzini@redhat.com>: > > > On 05/06/2016 05:28, Wanpeng Li wrote: >>> > No, I don't think so, the existing req_immediate_exit case is only after >>> > a VMLAUNCH/VMRESUME vmexit, in which case we already have a >>> > >>> > if (vmx->nested.nested_run_pending) >>> > kvm_make_request(KVM_REQ_EVENT, vcpu); >>> > >>> > in vmx_vcpu_run. >> Do you think this can be removed since it blindly request a >> KVM_REQ_EVENT even if there is no still-pending event to L1 which >> blocked by nested_run_pending, however, req_immediate_exit can >> indicate there is a pending event blocked by nested_run_pending and >> the request KVM_REQUEST_EVENT added in your patch can guarantee inject >> this pending event in the next nested vmexit. > > Yes, I think so. Yeah, maybe somebody who is interested in can clean it up and confirm there is no regression. :) Regards, Wanpeng Li ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 2/2] KVM: x86: rename process_smi to enter_smm, process_smi_request to process_smi 2016-06-01 12:34 [PATCH 0/2] KVM: x86: avoid simultaneous queueing of both IRQ and SMI Paolo Bonzini 2016-06-01 12:35 ` [PATCH 1/2] " Paolo Bonzini @ 2016-06-01 12:35 ` Paolo Bonzini 1 sibling, 0 replies; 8+ messages in thread From: Paolo Bonzini @ 2016-06-01 12:35 UTC (permalink / raw) To: linux-kernel, kvm Make the functions more similar between KVM_REQ_NMI and KVM_REQ_SMI. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> --- arch/x86/kvm/x86.c | 41 +++++++++++++++++++++-------------------- 1 file changed, 21 insertions(+), 20 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 271585574a9f..199a87c20a98 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -91,7 +91,7 @@ static u64 __read_mostly efer_reserved_bits = ~((u64)EFER_SCE); static void update_cr8_intercept(struct kvm_vcpu *vcpu); static void process_nmi(struct kvm_vcpu *vcpu); -static void process_smi(struct kvm_vcpu *vcpu); +static void enter_smm(struct kvm_vcpu *vcpu); static void __kvm_set_rflags(struct kvm_vcpu *vcpu, unsigned long rflags); struct kvm_x86_ops *kvm_x86_ops __read_mostly; @@ -6096,7 +6096,7 @@ static int inject_pending_event(struct kvm_vcpu *vcpu, bool req_int_win) /* try to inject new event if pending */ if (vcpu->arch.smi_pending && !is_smm(vcpu)) { --vcpu->arch.smi_pending; - process_smi(vcpu); + enter_smm(vcpu); } else if (vcpu->arch.smi_pending && kvm_x86_ops->nmi_allowed(vcpu)) { --vcpu->arch.nmi_pending; vcpu->arch.nmi_injected = true; @@ -6120,6 +6120,7 @@ static int inject_pending_event(struct kvm_vcpu *vcpu, bool req_int_win) kvm_x86_ops->set_irq(vcpu); } } + return 0; } @@ -6143,7 +6144,7 @@ static void process_nmi(struct kvm_vcpu *vcpu) #define put_smstate(type, buf, offset, val) \ *(type *)((buf) + (offset) - 0x7e00) = val -static u32 process_smi_get_segment_flags(struct kvm_segment *seg) +static u32 enter_smm_get_segment_flags(struct kvm_segment *seg) { u32 flags = 0; flags |= seg->g << 23; @@ -6157,7 +6158,7 @@ static u32 process_smi_get_segment_flags(struct kvm_segment *seg) return flags; } -static void process_smi_save_seg_32(struct kvm_vcpu *vcpu, char *buf, int n) +static void enter_smm_save_seg_32(struct kvm_vcpu *vcpu, char *buf, int n) { struct kvm_segment seg; int offset; @@ -6172,11 +6173,11 @@ static void process_smi_save_seg_32(struct kvm_vcpu *vcpu, char *buf, int n) put_smstate(u32, buf, offset + 8, seg.base); put_smstate(u32, buf, offset + 4, seg.limit); - put_smstate(u32, buf, offset, process_smi_get_segment_flags(&seg)); + put_smstate(u32, buf, offset, enter_smm_get_segment_flags(&seg)); } #ifdef CONFIG_X86_64 -static void process_smi_save_seg_64(struct kvm_vcpu *vcpu, char *buf, int n) +static void enter_smm_save_seg_64(struct kvm_vcpu *vcpu, char *buf, int n) { struct kvm_segment seg; int offset; @@ -6185,7 +6186,7 @@ static void process_smi_save_seg_64(struct kvm_vcpu *vcpu, char *buf, int n) kvm_get_segment(vcpu, &seg, n); offset = 0x7e00 + n * 16; - flags = process_smi_get_segment_flags(&seg) >> 8; + flags = enter_smm_get_segment_flags(&seg) >> 8; put_smstate(u16, buf, offset, seg.selector); put_smstate(u16, buf, offset + 2, flags); put_smstate(u32, buf, offset + 4, seg.limit); @@ -6193,7 +6194,7 @@ static void process_smi_save_seg_64(struct kvm_vcpu *vcpu, char *buf, int n) } #endif -static void process_smi_save_state_32(struct kvm_vcpu *vcpu, char *buf) +static void enter_smm_save_state_32(struct kvm_vcpu *vcpu, char *buf) { struct desc_ptr dt; struct kvm_segment seg; @@ -6217,13 +6218,13 @@ static void process_smi_save_state_32(struct kvm_vcpu *vcpu, char *buf) put_smstate(u32, buf, 0x7fc4, seg.selector); put_smstate(u32, buf, 0x7f64, seg.base); put_smstate(u32, buf, 0x7f60, seg.limit); - put_smstate(u32, buf, 0x7f5c, process_smi_get_segment_flags(&seg)); + put_smstate(u32, buf, 0x7f5c, enter_smm_get_segment_flags(&seg)); kvm_get_segment(vcpu, &seg, VCPU_SREG_LDTR); put_smstate(u32, buf, 0x7fc0, seg.selector); put_smstate(u32, buf, 0x7f80, seg.base); put_smstate(u32, buf, 0x7f7c, seg.limit); - put_smstate(u32, buf, 0x7f78, process_smi_get_segment_flags(&seg)); + put_smstate(u32, buf, 0x7f78, enter_smm_get_segment_flags(&seg)); kvm_x86_ops->get_gdt(vcpu, &dt); put_smstate(u32, buf, 0x7f74, dt.address); @@ -6234,7 +6235,7 @@ static void process_smi_save_state_32(struct kvm_vcpu *vcpu, char *buf) put_smstate(u32, buf, 0x7f54, dt.size); for (i = 0; i < 6; i++) - process_smi_save_seg_32(vcpu, buf, i); + enter_smm_save_seg_32(vcpu, buf, i); put_smstate(u32, buf, 0x7f14, kvm_read_cr4(vcpu)); @@ -6243,7 +6244,7 @@ static void process_smi_save_state_32(struct kvm_vcpu *vcpu, char *buf) put_smstate(u32, buf, 0x7ef8, vcpu->arch.smbase); } -static void process_smi_save_state_64(struct kvm_vcpu *vcpu, char *buf) +static void enter_smm_save_state_64(struct kvm_vcpu *vcpu, char *buf) { #ifdef CONFIG_X86_64 struct desc_ptr dt; @@ -6275,7 +6276,7 @@ static void process_smi_save_state_64(struct kvm_vcpu *vcpu, char *buf) kvm_get_segment(vcpu, &seg, VCPU_SREG_TR); put_smstate(u16, buf, 0x7e90, seg.selector); - put_smstate(u16, buf, 0x7e92, process_smi_get_segment_flags(&seg) >> 8); + put_smstate(u16, buf, 0x7e92, enter_smm_get_segment_flags(&seg) >> 8); put_smstate(u32, buf, 0x7e94, seg.limit); put_smstate(u64, buf, 0x7e98, seg.base); @@ -6285,7 +6286,7 @@ static void process_smi_save_state_64(struct kvm_vcpu *vcpu, char *buf) kvm_get_segment(vcpu, &seg, VCPU_SREG_LDTR); put_smstate(u16, buf, 0x7e70, seg.selector); - put_smstate(u16, buf, 0x7e72, process_smi_get_segment_flags(&seg) >> 8); + put_smstate(u16, buf, 0x7e72, enter_smm_get_segment_flags(&seg) >> 8); put_smstate(u32, buf, 0x7e74, seg.limit); put_smstate(u64, buf, 0x7e78, seg.base); @@ -6294,13 +6295,13 @@ static void process_smi_save_state_64(struct kvm_vcpu *vcpu, char *buf) put_smstate(u64, buf, 0x7e68, dt.address); for (i = 0; i < 6; i++) - process_smi_save_seg_64(vcpu, buf, i); + enter_smm_save_seg_64(vcpu, buf, i); #else WARN_ON_ONCE(1); #endif } -static void process_smi(struct kvm_vcpu *vcpu) +static void enter_smm(struct kvm_vcpu *vcpu) { struct kvm_segment cs, ds; struct desc_ptr dt; @@ -6311,9 +6312,9 @@ static void process_smi(struct kvm_vcpu *vcpu) vcpu->arch.hflags |= HF_SMM_MASK; memset(buf, 0, 512); if (guest_cpuid_has_longmode(vcpu)) - process_smi_save_state_64(vcpu, buf); + enter_smm_save_state_64(vcpu, buf); else - process_smi_save_state_32(vcpu, buf); + enter_smm_save_state_32(vcpu, buf); kvm_vcpu_write_guest(vcpu, vcpu->arch.smbase + 0xfe00, buf, sizeof(buf)); @@ -6369,7 +6370,7 @@ static void process_smi(struct kvm_vcpu *vcpu) kvm_mmu_reset_context(vcpu); } -static void process_smi_request(struct kvm_vcpu *vcpu) +static void process_smi(struct kvm_vcpu *vcpu) { vcpu->arch.smi_pending = true; kvm_make_request(KVM_REQ_EVENT, vcpu); @@ -6496,7 +6497,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) if (kvm_check_request(KVM_REQ_STEAL_UPDATE, vcpu)) record_steal_time(vcpu); if (kvm_check_request(KVM_REQ_SMI, vcpu)) - process_smi_request(vcpu); + process_smi(vcpu); if (kvm_check_request(KVM_REQ_NMI, vcpu)) process_nmi(vcpu); if (kvm_check_request(KVM_REQ_PMU, vcpu)) -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-06-06 8:26 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-06-01 12:34 [PATCH 0/2] KVM: x86: avoid simultaneous queueing of both IRQ and SMI Paolo Bonzini 2016-06-01 12:35 ` [PATCH 1/2] " Paolo Bonzini 2016-06-01 16:40 ` Radim Krčmář 2016-06-01 18:06 ` Paolo Bonzini 2016-06-05 3:28 ` Wanpeng Li 2016-06-06 8:10 ` Paolo Bonzini 2016-06-06 8:25 ` Wanpeng Li 2016-06-01 12:35 ` [PATCH 2/2] KVM: x86: rename process_smi to enter_smm, process_smi_request to process_smi 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).