> -----Original Message----- > From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc- > ow...@vger.kernel.org] On Behalf Of Bhushan Bharat-R65777 > Sent: Wednesday, May 16, 2012 12:58 PM > To: Alexander Graf > Cc: Wood Scott-B07421; Yoder Stuart-B08248; kvm-ppc@vger.kernel.org > Subject: Not emulated registers on BOOKE_HV (GS-mode) > > Hi Alex, > > There is below comment in arch/powerpc/kvm/booke_emulate.c > > /* > * NOTE: some of these registers are not emulated on BOOKE_HV (GS-mode). > * Their backing store is in real registers, and these functions > * will return the wrong result if called for them in another context > * (such as debugging). > */ > > "some of these registers are not emulated on BOOKE_HV (GS-mode)" > 1) Is not that mtspr()/mfspr() for "not emulated" registers should > follow EMULATE_FAIL path? So should be ifdef out for BOOKE_HV? Otherwise > the emulation code execute. > 2) Or These are not emulated because the GS mode have direct access to > these registers, Right? So no trap? > For BOOKE_HV mtspr/mfspr would get mapped to hardware maintained guest shadow copies. For example guest access to dear would get mapped to gdear and wouldn't trap > > "and these functions will return the wrong result if called for them in > another context (such as debugging)." > 1) So do you mean that guest is not supposed to access these registers > in normal scenario but the debugger (some command on gdb in guest) can > access these register? then does it make sense to treat mtspr() as nop > and mfspr returns 0/undefined? > Actually, in a normal scenario (For BOOKE_HV) guest (MSR[GS] = 1) would be able to directly access these registers without hypervisor intervention. However I am not sure under what condition would the guest access generate a trap, all guest accesses would be with MSR[GS]=1.
-Varun -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
