On Sun, Jun 29, 2014 at 04:01:04PM +0200, Borislav Petkov wrote: > On Sun, Jun 29, 2014 at 04:42:47PM +0300, Gleb Natapov wrote: > > Please do so and let us know. > > Yep, just did. Reverting ae9fedc793 fixes the issue. > > > reinj:1 means that previous injection failed due to another #PF that > > happened during the event injection itself This may happen if GDT or fist > > instruction of a fault handler is not mapped by shadow pages, but here > > it says that the new page fault is at the same address as the previous > > one as if GDT is or #PF handler is mapped there. Strange. Especially > > since #DF is injected successfully, so GDT should be fine. May be wrong > > cpl makes svm crazy? > > Well, I'm not going to even pretend to know kvm to know *when* we're > saving VMCB state but if we're saving the wrong CPL and then doing the > pagetable walk, I can very well imagine if the walker gets confused. One > possible issue could be U/S bit (bit 2) in the PTE bits which allows > access to supervisor pages only when CPL < 3. I.e., CPL has effect on > pagetable walk and a wrong CPL level could break it. > > All a conjecture though... > Looks plausible, still strange that second #PF is at the same address as the first one though. Anyway, not we have the commit to blame. -- 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
