James, what does it mean to be “led to believe” that something is inlined?
You can read the headers. You know exactly what is inlined.
Beside that, we’ve already published the document that allows Xen, KVM and
whomever else to switch on spinlock enlightenments and other such things
when running Windows on top of a hypervisor. My impression was that Xen had
already picked up support for this, though I haven’t read the code.
(The original guy who led the Hyper-V project liked to make a distinction
between changes to a kernel for running in a VM, which he called
“enlightenments” and replacing entire device drivers with ones that are only
for running in a VM, which he called “synthetic I/O.” They’re both called
“paravirtualization” by the open source crowd.)
You expose a set of features through CPUID, in the way that Hyper-V does,
and then Windows will change the way its spinlock code works, making a
hypercall if the lock can’t be acquired in a few tries. This allows the
hypervisor a strong hint that running a different virtual processor would be
a really good idea.
There are lots of other enlightenments that are turned on through CPUID
features, too. Windows 6 implemented a few of them, including the
spinlocks. Windows 7 implemented more. Windows 8 will presumably take that
even further.
Here’s the doc:
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=18673
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group
This post implies no warranties and confers no rights.
“James Harper” wrote in message news:xxxxx@ntdev…
Under Xen it is possible to assign more virtual CPU’s to a VM than there
are physical CPU’s in the system - eg on my old dual core AMD box I can
assign 8 virtual CPU’s to a VM. Obviously performance is awful but it is
useful as it stretches out the window for potential race conditions
which is great for testing.
Apart from the obvious resource problem of assigning one physical cpu to
multiple virtual cpu’s, under periods of high lock contention things can
really get bogged down - if vCPU 1 holds a spinlock and (worst case)
vCPU’s 2-8 are spinning, and the scheduler is doing simple round robin
scheduling, vCPU’s 2-8 are each going to still be scheduled their slice
of the physical CPU but are doing nothing but spinning, and vCPU 1 can’t
progress and release the lock until it is next scheduled. That’s
obviously an absolute worst case and such high lock contention probably
needs a rethink but it illustrates the problem.
If the spinlock code was in a fixed point in memory (eg inside
KeAcquireSpinLock) then it may be possible for the xen scheduler to
detect that a vCPU is currently executing a ‘spin’ and maybe service
another vCPU instead, but I’m led to believe that spinlock code is
inlined under AMD64 so this would not be possible. Is there another way
that Xen could detect that a CPU is waiting on a spinlock?
Thanks
James