Ingo Molnar wrote: > * Avi Kivity <[EMAIL PROTECTED]> wrote: > > >> Note that the corner cases will never be 100% emulatable. For >> example, you can set cr3 to point at your IDE DMA mmio space or >> something like that. It's quite all right to kill the guest quietly >> at that point, as no real-life guest will do that. >> > > yes. Or to map the lapic to the IDT ;-) (as yours truly has tried it > years ago) > > that's why my suggestion is to just kill the guest. Loading such a cr3 > is a serious bug that might be hard to debug in the guest. I had to > debug at least one such bug in Linux before (years ago, in the lazy TLB > switching code) and it was a royal PITA to track down. Having a > hypervisor that points any cr3 load error out /before/ the effects of > the error propagate further is a bonus, not an incompatibility. The CPU > does not implement this not because the semantics is important, but i > suspect mostly because it doesnt really know the boundaries and type of > RAM. > > >> The kvm goals do not include cycle accurate emulation. [...] >> > > yes. That's why i'm suggesting to kill the VM in such a scenario. A cr3 > value is only valid if it points to real RAM. > >
Yes. The value of the bad ram page is that it avoids a check in many places where a guest page is referenced, and so reduces the number of hard to test error paths. It's hard to make the case for cr3 changes alone, but when you consider demand faulting, it makes more sense. -- 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
