On 09.01.2012, at 23:39, Scott Wood wrote: > On 01/09/2012 04:17 PM, Alexander Graf wrote: >> >> On 09.01.2012, at 22:48, Scott Wood wrote: >> >>> On 01/09/2012 11:48 AM, Alexander Graf wrote: >>>> >>>> Do you think it's possible to combine this with the book3s_pr code, so we >>>> don't duplicate too much here? >>> >>> book3s_pr is a bit different in that it can trap when the guest sets >>> MSR[FP]. >> >> Ah, there's no doorbell? So you always have to swap fpu registers? You still >> have to enable it manually when preempting in, right? IIRC ppc32 does lazy >> fpu activation. > > Right. > > Preempting in is handled by calling kvmppc_load_guest_fp() (which should > be renamed to be booke-specific, since the semantics are tied to > booke.c) from kvmppc_core_vcpu_load() in e500mc.c.
Ah, and that one's called on sched_in. All is well then :). > >>>> I'm having a hard time to grasp when shared->msr, shadow_msr and regs->msr >>>> is used in your code :). >>> >>> shadow_msr is the real MSR. >>> >>> shared->msr is the guest's view of MSR. > > Correction -- this applies to PR-mode (e500v2). > > In GS-mode, shadow_msr is not used. The guest sees the real MSR (hw > silently prevents it from modifying certain bits), which gets saved on > exit into shared->msr. Hrm. Can we maybe #ifdef out shadow_msr on HV then? I'm really getting confused with having 3 potential msr variables in the vcpu struct. Alex _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
