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: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.


To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[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