From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aravinda Prasad Date: Sat, 23 Jan 2016 12:40:48 +0000 Subject: Re: [PATCH v3 1/2] KVM: PPC: New capability to control MCE behaviour Message-Id: <56A37200.3030402@linux.vnet.ibm.com> List-Id: References: <20160113070759.20248.86252.stgit@aravindap> <20160123102013.GA11916@fergus.ozlabs.ibm.com> In-Reply-To: <20160123102013.GA11916@fergus.ozlabs.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Paul Mackerras Cc: gleb@kernel.org, agraf@suse.de, kvm-ppc@vger.kernel.org, linuxppc-dev@ozlabs.org, pbonzini@redhat.com, mahesh@linux.vnet.ibm.com, david@gibson.dropbear.id.au, kvm@vger.kernel.org, mpe@ellerman.id.au On Saturday 23 January 2016 03:50 PM, Paul Mackerras wrote: > On Wed, Jan 13, 2016 at 12:37:59PM +0530, Aravinda Prasad wrote: >> This patch introduces a new KVM capability to control >> how KVM behaves on machine check exception (MCE). >> Without this capability, KVM redirects machine check >> exceptions to guest's 0x200 vector if the address in >> error belongs to the guest. With this capability KVM >> causes a guest exit with NMI exit reason. >> >> This is required to avoid problems if a new kernel/KVM >> is used with an old QEMU for guests that don't issue >> "ibm,nmi-register". As old QEMU does not understand the >> NMI exit type, it treats it as a fatal error. However, >> the guest could have handled the machine check error >> if the exception was delivered to guest's 0x200 interrupt >> vector instead of NMI exit in case of old QEMU. > > [snip] > >> @@ -1132,6 +1135,10 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu, >> break; >> } >> #endif /* CONFIG_KVM_XICS */ >> + case KVM_CAP_PPC_FWNMI: >> + r = 0; >> + vcpu->kvm->arch.fwnmi_enabled = true; >> + break; > > Might we ever want to set this flag back to false after setting it to > true? If so perhaps we should do vcpu->kvm->arch.fwnmi_enabled > !!cap->args[0]. However, I admit I can't actually think of a > situation where we would need to reset it. :) Even I am not able to think of any situation where resetting is required. Regards, Aravinda > > Paul. > -- Regards, Aravinda