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
