[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.