On Wed, 2009-07-08 at 10:28 +0800, Liu Yu-B13201 wrote: > > > -----Original Message----- > > From: kvm-ppc-ow...@vger.kernel.org > > [mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Alexander Graf > > Sent: Wednesday, July 08, 2009 7:23 AM > > To: Hollis Blanchard > > Cc: Avi Kivity; kvm-ppc@vger.kernel.org; a...@arndb.de; > > kw...@redhat.com > > Subject: Re: [PATCH 01/23] Pass PVR in sregs > > > > > > On 08.07.2009, at 00:50, Hollis Blanchard wrote: > > > > > > The PVR register is basically the equivalent of cpuid. It might make > > > more sense to exit to qemu to handle those accesses. Today, > > PVR reads > > > are emulated in-kernel. > > > > I actually use it in 970.c to find out which guest MMU to choose from. > > So even if we were to do it in userspace, we'd still need the > > information what CPU to create in the guest on the kernel > > side. Which > > in turn means we don't win anything from leaving the PVR > > emulation to > > userspace. > > > > > Hmm, I don't remember where arch->vcpu.pvr is being set at > > all for 440 > > > and e500... > > > > It used to be in some creation code - either general kvm or > > vcpu. But > > some recent patch removed vcpu->arch.pvr and made emulate.c do an > > mfspr(SPRN_PVR). > > > > Yes. Since the demand to emulate PVR for 440 and e500 is still vague. > Directly return the real value can simplify the code, and latter patches > can easily change it. > The same thing goes for PIR.
By the way, I don't like that PVR patch you sent to Avi (and he committed). It's my own fault for not reading more closely, but in the future could you send me patches that touch code which isn't e500-specific? -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
