Peter Zijlstra wrote:
It's a fully virtualized guest. There's no way to get this without
patching the guest kernel.
Yes there is.. virtualized monitor-wait stuff coupled with a
monitor-wait based spinlock implementation.
That only works if the guest uses monitor/mwait. Not all of the guests
are under our control. I don't know whether Windows uses
monitor/mwait. Further, we don't have timed exits on mwait like we do
with pause.
Ugh, you really care about crap like windows?
Yes, it is used by my users. Either we convince them not to use
Windows, or we find a way to support it well.
I've also heard that monitor/mwait are very slow and only usable on idle
loop stuff.
Yeah, current implementations suck, doesn't mean it has to stay that
way.
Well, I'm not speculating on future cpu changes. I'd like to support
current and near-future software and hardware, not how it should have
been done software running on how it should have been done hardware.
Once we go change silicon, you might as well do it right.
None of the major x86 vendors are under my control.
I thought this patch came from AMD, who changed their silicon so 'solve'
one of these virt problems.
They changed the silicon to support existing guests. For both Linux and
Windows, the pause instruction is the only indication the guest is spinning.
/me goes hide again, and pretend all of virt doesn't exist :-) Think
happy thoughts.
You'll end up running permanently in a guest, with no way out.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
