Re: [Xen-devel] resume of HVM guest without PV drivers

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 07.08.09 12:13 >>>
>So what does improving ticket lock behaviour have to do with save/restore?
>I'm a bit confused now.

I need a hypercall to do the yield that I want to do when realizing that the
lock owner is blocked. In order to find out whether the lock owner is (not)
running, I need the runstate area (or else I'd need a second hypercall,
which I dislike for the case the lock owner *is* running, and hence can
expect that the local vCPU will be able to get the lock soon). The runstate
area, however, needs to be re-registered after resume, and since I'm not
not told that I'm being resumed, I need a way to figure this out from
just memory state.

Besides that, doing hypercalls here also requires that I'll be able to re-
setup the hypercall (or the hypercall page) in case I got migrated
between VMX and SVM. While this could certainly be done in a fixup
handler invoked from #UD (a little tricky for the hypercall page case), I
find it preferable to synchronously fix things up beforehand.

>I'll certainly consider the patch. I'd also consider a CPUID flag to
>indicate its presence.

I thought about a feature flag briefly, but I'm not certain it's worth it.
Given the current state of things, the feature being absent will just
result in all vCPU-s always being considered running, and hence the
intended optimization just not taking any effect (but specifically also
not having any adverse effect on the guest afaict).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel