This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

>>> 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).


Xen-devel mailing list