On 09.01.2012, at 23:54, Scott Wood wrote: > On 01/09/2012 04:47 PM, Alexander Graf wrote: >> >> 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: >>>>>> 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. > > An ifdef would take us further down the road of not being able to > support both in the same kernel image (not sure whether that's a > long-term goal -- probably won't happen any time soon with e500v2+e500mc > even disregarding KVM, but maybe it'll be relevant on some other chips), > and in general increase the mess in the struct definition. How about a > comment? Well, I'd like to make sure we don't accidentally access the wrong field. But yes, a comment should be ok. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
