[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen: fix reboot with a PVH Dom0
>>> On 04.06.14 at 18:47, <roger.pau@xxxxxxxxxx> wrote: > The commit that introduced the clts and the FPU clearing (53a82f) > notes that this is needed to workaround some broken BIOSes, but > there's no mention about which specific BIOSes have this issue, so I'm > uncertain if the following fix is appropiate, or if those broken > BIOSes were only found on i386 hardware which Xen does no longer > support. We should be conservative here and hence don't leave the FPU in a bad state. Which includes not leaving CR0.TS set, i.e. the fix you suggest isn't the right one. Instead, how about simply making __stop_this_cpu() call sync_local_execstate() before that FPU handling (perhaps before anything) it does? Of course, a comment should explain why this is needed, to avoid people wondering later and suggesting its removal. Otoh, it does call hvm_cpu_down(), so VMX code should be able to know that it has no business doing anything anymore. I.e. as Andrew already suggested, subsequent operations (__vmwrite() for example) are bogus too considering that __vmxoff() already happened. So perhaps the better thing would be to add an unlikely(!this_cpu(vmxon)) check to vmx_ctxt_switch_from(). And the same ought to be done to SVM, which shouldn't do any SVM stuff after having cleared EFER.SVME (the whole change here really is kind of PVH independent anyway, as the same problem might surface if you shut down without first shutting down all your guests). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |