On Sun, Oct 31, 2010 at 12:01:29PM -0700, Alexander Graf wrote: > > 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. > > A guest has thousands ways to kill qemu from ring 0. Actually, after fixing the bug, open firmware kills qemu in other place. This time it looks like it maps two pci bars into the same physical address for a short time (one of then framebuffer) and this kills qemu-kvm dirty logging (qemu works). -- Gleb. -- 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
