On 06/12/2011 04:47 PM, Avi Kivity wrote: > On 06/10/2011 07:05 AM, Xiao Guangrong wrote: >> On 06/09/2011 03:39 PM, Avi Kivity wrote: >> >> > First, I think we should consider dropping bypass_guest_pf completely, >> > just so we have less things to think about. >> > >> >> I agree. > > Great, please post a patch.
OK. >> Ah, maybe the cpu can not do it, we need a light way to get spte for i386 >> host... > > Look at the comments in arch/x86/mm/gup.c - it does the same thing. > Yeah, it is a good study case for me. >> the origin way is: >> >> fetch last level spte >> if failed or it is not a mmio spte: >> call page fault >> do mmio >> >> and it has little heavy sine we need to walk guest page table, >> and build spte under mmu-lock. > > For shadow, yes, this is a good optimization. But with nested paging it slow > things down. We already have the gpa, so all we need to do is follow the > mmio path. There's no need to walk the spte hierarchy. > Yes, it is, i just want to detect BUG for KVM, it helps us to know if "ept misconfig" is the real MMIO or the BUG. I noticed some "ept misconfig" BUGs is reported before, so i think doing this is necessary, and i think it is not too bad, since walking spte hierarchy is lockless, it really fast. >> Maybe i missed your meaning, could you please tell me the advantage? :-( > > I wanted to also service RAM faults without the lock, if the only thing > missing was the spte (and the rest of the hierarchy was fine). But it can't > be made to work without an overhaul of all of the locking. > Great, i have the same thought, anyway, it is a good start :-) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
