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
[KVM Development]
[KVM ARM]
[KVM ia64]
[Linux USB Devel]
[Linux Video]
[Linux Audio Users]
[Photo]
[Video Projectors]
[PDAs]
[Free Online Dating]
[Linux Kernel]
[Linux SCSI]
[XFree86]
[Big List of Linux Books]