[Android-virt] [RFC PATCH] ARM: KVM: Handle VFP/NEON state switching

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

 




On 22.05.2012, at 07:03, Rusty Russell <rusty.russell at linaro.org> wrote:

> On Tue, 22 May 2012 05:27:28 +0200, Alexander Graf <agraf at suse.de> wrote:
>> On 22.05.2012, at 05:00, Rusty Russell <rusty.russell at linaro.org> wrote:
>>> Note that in some cases, we could skip saving and restoring the host FPU
>>> state.  But that seems like a premature optimization,
>> 
>> Yup, getting things work first and fast later is usually the better
>> approach :).
> 
> Actually, I prefer getting it to work and putting a FIXME.  Then someone
> else can do all the tricky work ;)
> 
>> How does the ARM code work here? Are you guys doing it x86 style and exit vcpu_run for every intercept or are you going the ppc way to keep inside vcpu_run until we want to return to user space?
>> 
>> The former benefits a lot from not saving/restoring the host fpu state. The latter not so much :).
> 
> The latter.  So this is how it looks at the moment, assuming the guest
> always hits the FPU, we do a hyp trap and two fpu switches for each
> guest entry.
> 
> Now, we could do some heuristics about FPU-intense guests, and try to
> avoid the hyp trap by always switching the FPU.  We won't know the costs
> involved until we benchmark on real silicon.

Can't you just keep the FPU in guest context until you hit vcpu_put? Check out the ppc code for 'ext' handling - it's fairly simple.

> 
>>> and makes us
>>> depend on the specific Linux kernel saving behavior.
>> 
>> ... which should be a reasonable thing to do given that kvm is part of
>> the Linux kernel ;).
> 
> Except the it allows changes in arch/arm/vfp/ to break code in
> arch/arm/kvm/.

Yeah, but that will always be the case, no? Changes in oprofile could also hit you when you suddenly get intercepts you don't know yet.

> 
> And we won't spot it for ages, because it's subtle and only breaks in
> odd corner cases.  This seems to be the history of floating point.

Well - corner cases are bad of course :)

> 
> Worse, we can't call kernel code to frob the FPU, since we want to stay
> in hyp mode to do the switch.

:(

What's the reason we can't run all of Linux in HV mode like we do on ppc again? ;)


Alex




[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux