Ingo Molnar wrote: > * Ingo Molnar <[EMAIL PROTECTED]> wrote: > > >> ok. How about the patch below then? This only addresses the OOM >> scenario, not the !memslot case. >> > > the !memslot case is covered by the patch below. Injecting a #GPF is the > easiest one to do here, although we could do a triple fault too - i just > dont see the infrastructure for that in KVM, so i went for the easier > solution ;-) > > I have tested this with an intentionally bad cr3 value in a Linux guest, > and the result is a relatively clean guest abort crash: > > inject_general_protection: rip 0xc012093e > kvm_handle_exit: unexpected, valid vectoring info and exit reason is 0x9 > > at the right RIP: > > c012093e: 0f 22 d8 mov %eax,%cr3 > > instead of a host crash. Note that i chose to put this into the generic > cr3 loading function, so that it covers real-mode too. I think we can > safely ignore a BIOS loading crap into cr3 and after that loading the > right value into it. (if that ever happens we 1) want to know about it > 2) can push the test down into paging_new_cr3()) Agreed? > > Ingo > >
Applied, thanks. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
