Eduardo Habkost wrote:
Can't we just set a flag when we are about to enable vmx, so we run vmxoff
only when know it's enabled? There will be a tiny window between setting
this flag and and actually running vmxon where things could go wrong,
but this doesn't look that bad.
It makes more sense to have a vmxon api in the core; you call it, the
kernel enables it and sets a flag; then either you or the core can
disable it.
Having to handle #UD would make things more messy, in my opinion.
It's not too bad, either relying on exception handlers or hacking our own.
BTW, is this problem vmx-specific? Do we need to do something similar
for svm?
svm needs it as well, since it shares some memory with the cpu. It's
less critical though, will likely work even without it.
If we trust the exception handlers, there's no problem. Otherwise we
need to replace the current #UD handler with an iret (perhaps switching
temporarily to another IDT).
I think we can't fully trust anything if we are on the crash dump path,
so the less code we depend on, the better.
So we can point #UD temporarily at an 'addq $3, (%rsp); iret' for the
vmxoff instruction. Or implement the 'enable virt extensions' API.
The patches I've sent to the kvm mailing list added a notifier interface
specific for kexec_crash, using raw_notifier_*().
IMO, if a notifier registration interface was acceptable, the raw
notifiers would be good enough for that. But Eric seems to think that
adding a notifier registration interface for the crash handler path
wouldn't be a good idea, and I am starting to agree with him.
I wouldn't mind notifiers (with a nice comment explaining that you must
know what you're doing, though that's the case with most kernel APIs).
I'm fine with either approach.
The general kexec path also wants this fixed.
When I've tested it, kexec called the kvm reboot notifier, so
everything worked fine.
Oh, okay.
--
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
