Google
  Web www.spinics.net

Re: [RFC PATCH 15/16] KVM: PPC: booke: standard PPC floating point support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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]

  Powered by Linux