On 31.10.2010, at 11:56, Gleb Natapov wrote: > On Sun, Oct 31, 2010 at 11:26:09AM -0700, Alexander Graf wrote: >> >> On 31.10.2010, at 11:22, Gleb Natapov wrote: >> >>> On Sun, Oct 31, 2010 at 11:00:08AM -0700, Alexander Graf wrote: >>>> >>>> On 31.10.2010, at 07:36, Gleb Natapov wrote: >>>> >>>>> Call into emulator when INVD instruction is executed by a guest. >>>> >>>> Why? This is a poor patch description. >>> Why what? Why we need to handle INVD exit instead of stopping with >>> unhandled exit error? >> >> Ah, so we get the exit already, but don't handle it? That's an important piece of information that belongs in the patch description. Another thing I as a reader would also like to know is where this got triggered, so which guests would break without the patch. >> > I'll add it to the patch description. The guest that triggered it was > open firmware, but I do not think this info belongs to patch description > too. Quite the contrary, I would be very interested in that information in the patch description. The patch description is what people afterwards use to cherry-pick patches. So this is crucial. > >> I'm also wondering why nobody has seen it before. Is this a regression? Is this exit a side-effect of another feature bit of VMX, so only newer CPUs are affected? >> > I guess nobody seen it because not many guests use the instruction. > Actually this instruction is useful only for firmware use. This is not a > regression. This, too, should go in the patch description :). At least the part that usually only firmware uses it. The part where it has been around since the beginning might be interesting as well from a security point of view. After all, the guest can kill its full kvm context without going through qemu interfaces. Thanks! Alex -- 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
