On Tue, Feb 25, 2020 at 04:16:43PM +0000, Peter Maydell wrote: > On Tue, 25 Feb 2020 at 16:10, Wayne Li <waynli329@xxxxxxxxx> wrote: > > So what could be causing this problem? I’m guessing it has something > > to do with the translation lookaside buffers (TLBs)? But the > > translation between virtual and physical memory clearly works when KVM > > isn’t enabled. So what could cause this to stop working when KVM is > > enabled? > > When you're not using KVM, virtual-to-physical lookups are > done using QEMU's emulation code that emulates the MMU. > When you are using KVM, virtual-to-physical lookups > are done entirely using the host CPU (except for corner > cases like when we come out of the kernel and the user > does things with the gdb debug stub). So all the page > tables and other guest setup of the MMU had better match > what the host CPU expects. (I don't know how big the > differences between e5500 and e6500 MMU are or whether > the PPC architecture/KVM supports emulating the one on > the other: some PPC expert will probably be able to tell you.) Well, sort of. Including things like KVM-PR, things get complicated. But in any case, the resposibility for translation lies somewhere between the cpu itself and the KVM code - qemu is not involved. Depending on exactly what the host's MMU looks like and what it has in the way of virtualization features, that might make it impossible to run a guest expecting a substantially different cpu model from the host's. Unfortunately, I'm not really at all familiar with the Freescale parts, and even less with the KVM implementation for them. It doesn't surprise me that there are substantial bugs there, but I wouldn't realy now where to begin to fix them. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
