On Mon, Jan 25, 2010 at 3:32 AM, Liu Yu-B13201 <b13...@freescale.com> wrote: > >> -----Original Message----- >> From: Alexander Graf [mailto:ag...@suse.de] >> Sent: Friday, January 22, 2010 7:33 PM >> To: Liu Yu-B13201 >> Cc: hol...@penguinppc.org; kvm-...@vger.kernel.org; >> kvm@vger.kernel.org >> Subject: Re: [PATCH] kvmppc/booke: Set ESR and DEAR when >> inject interrupt to guest >> >> >> On 22.01.2010, at 12:27, Liu Yu-B13201 wrote: >> >> > >> > >> >> -----Original Message----- >> >> From: kvm-ppc-ow...@vger.kernel.org >> >> [mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Alexander Graf >> >> Sent: Friday, January 22, 2010 7:13 PM >> >> To: Liu Yu-B13201 >> >> Cc: hol...@penguinppc.org; kvm-...@vger.kernel.org; >> >> kvm@vger.kernel.org >> >> Subject: Re: [PATCH] kvmppc/booke: Set ESR and DEAR when >> >> inject interrupt to guest >> >> >> >> >> >> On 22.01.2010, at 11:54, Liu Yu wrote: >> >> >> >>> Old method prematurely sets ESR and DEAR. >> >>> Move this part after we decide to inject interrupt, >> >>> and make it more like hardware behave. >> >>> >> >>> Signed-off-by: Liu Yu <yu....@freescale.com> >> >>> --- >> >>> arch/powerpc/kvm/booke.c | 24 ++++++++++++++---------- >> >>> arch/powerpc/kvm/emulate.c | 2 -- >> >>> 2 files changed, 14 insertions(+), 12 deletions(-) >> >>> >> >>> @@ -286,15 +295,12 @@ int kvmppc_handle_exit(struct kvm_run >> >> *run, struct kvm_vcpu *vcpu, >> >>> break; >> >>> >> >>> case BOOKE_INTERRUPT_DATA_STORAGE: >> >>> - vcpu->arch.dear = vcpu->arch.fault_dear; >> >>> - vcpu->arch.esr = vcpu->arch.fault_esr; >> >>> kvmppc_booke_queue_irqprio(vcpu, >> >> BOOKE_IRQPRIO_DATA_STORAGE); >> >> >> >> kvmppc_booke_queue_data_storage(vcpu, vcpu->arch.fault_esr, >> >> vcpu->arch.fault_dear); >> >> >> >>> kvmppc_account_exit(vcpu, DSI_EXITS); >> >>> r = RESUME_GUEST; >> >>> break; >> >>> >> >>> case BOOKE_INTERRUPT_INST_STORAGE: >> >>> - vcpu->arch.esr = vcpu->arch.fault_esr; >> >>> kvmppc_booke_queue_irqprio(vcpu, >> >> BOOKE_IRQPRIO_INST_STORAGE); >> >> >> >> kvmppc_booke_queue_inst_storage(vcpu, vcpu->arch.fault_esr); >> >> >> > >> > Not sure if this is redundant, as we already have fault_esr. >> > Or should we ignore what hareware is and create a new esr to guest? >> >> On Book3S I take the SRR1 we get from the host as >> "inspiration" of what to pass to the guest as SRR1. I think >> we should definitely be able to inject a fault that we didn't >> get in that exact form from the exit path. >> >> I'm also not sure if something could clobber fault_esr if >> another interrupt takes precedence. Say a #MC. > > No as far as I know. > And if yes, the clobber could as well happen before we copy it. > Hollis, what do you think we should do here?
I'm torn, and in some ways it's not that important right now. However, I think it makes sense to add something like "vcpu->queued_esr" as a separate field from vcpu->fault_esr. The use case I'm thinking of is a debugger wanting to invoke guest kernel to provide a translation for an address not currently present in the TLB (i.e. not currently visible to the debugger). -Hollis -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
