On Wed, 16 May 2012 20:45:41 +0200, Antonios Motakis <a.motakis at virtualopensystems.com> wrote: > Hello Rusty, > > Thanks for your feedback! > > On 05/09/2012 09:29 AM, Rusty Russell wrote: > > > > Hi Antonios, > > > > Nice work! > > > > AFAICT, this is going to be fairly inefficient. Not just because we're > > saving and restoring even when the FP registers are not being used, but > > also because the (host) kernel does very naive lazy FPU restore, so > > we'll be doing an undefined trap in the host every time we run this code > > after a context switch. > I'm not sure I understand why there will be a trap, will there be one > even if the host itself won't use the FPU? Anyway my idea is to leave > the state of the FPU exactly as I received it, and not to optimize for > the host's behavior. Theoretically the host's code could change in the > future, so I try to stay decoupled from that and not introduce a > potential source of bugs. You're right; if the host doesn't use the FPU, we won't trap. But if you're running 2 guests on the same CPU, it'll be trapping every switch. > > I'm thinking we should use HCPTR to do lazy FPU enable. It might be > > best to have an arg to __kvm_vcpu_run() which activates your code; that > > way we can always set it to 'true' now, and false later as we get smarter. > > > > Cheers, > > Rusty. > > Yes, lazy switching is planned eventually. In you suggestion you mean to > do a traditional lazy switch every time the FPU is used in the guest, or > to set the flag as true the first time a FP instruction is used, and > from that point on always switch the registers? The problem with having > an outside variable to trigger the lazy switching the FP registers is > that each time you will have to do it you will have multiple context > switches. I was suggesting we set it once, actually: disable the trap and restore the FPU on re-entry, but... > I was considering a more careful approach adding a new path in > the interrupt vector in hyp mode, calling the switching code and > returning to the guest, while avoiding going all the way to the host to > do the switch. Right, that would be more efficient. We should probably just do that. > If I get your suggestion for "lazy enabling" right, it could be a > compromise for a simpler solution for now, but in practice booting a > Linux guest would always end up enabling the flag before we even get to > userspace! Maybe we could reset the flag at an interval? I happened to discuss this yesterday with some PPC guys who have played with smart lazy switching, and they had trouble showing any real improvement. The cost of the trap is pretty small, and you'll at worst have to do it once per context switch, which is expensive anyway. Cheers, Rusty.
