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. > 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 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. 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? Best regards, Antonios
