On Mon, 2 Jul 2012 14:56:49 +0200, Antonios Motakis <a.motakis at virtualopensystems.com> wrote: > Hello again, > > So I tried to get this latest patch to work (it currently crashes the > host). Unfortunately with some debugging, it seems keeping the FPU in guest > state until vcpu_put is not that simple! Between a guest exit, and a > vcpu_put following it, the host can and will try to check on FPEXC_EN. Really? In kernel mode? Yech :( As you can tell, I thought this wouldn't happen. > If the VFP has entered a "guest state", we currently then disable the > CP10/11 trap. A SMP Linux host might very well find FPEXC_EN enabled and > assume it needs to save the hosts state... but the state is will access is > the guests! So at the very least we need to keep CP10/11 disabled. OK, so it saves the guest state to ti->vfp_state: we'd need to get it from there instead of from the CPU. But I can't think of a good way to detect when this has happened. Can you? > An ugly workaround maybe could be to emulate reads to FPEXC_EN, with zero. > This way the host kernel would just move on, until we reach vcpu_put and > switch back to the host state. I'm looking at it, however I'm not 100% sure > yet it won't cause other complications, and we would then depend on kernel > behavior that could change without warning in the future... Too ugly. Just restore host state for now before we local_irq_enable(): if (vcpu->arch.host_vfp_saved) __kvm_restore_host_vfp(vcpu); We can try for tricky and efficient later? Cheers, Rusty.
