From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Ehrhardt Date: Thu, 31 Jan 2008 08:37:25 +0000 Subject: Re: [kvm-ppc-devel] [PATCH] [1/4] Add per guest pvr Message-Id: <47A188C5.1020106@linux.vnet.ibm.com> List-Id: References: <1201696318462-git-send-email-ehrhardt@linux.vnet.ibm.com> In-Reply-To: <1201696318462-git-send-email-ehrhardt@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: kvm-ppc@vger.kernel.org Hollis Blanchard wrote: > On Wed, 2008-01-30 at 13:31 +0100, ehrhardt@linux.vnet.ibm.com wrote: >> This adds get/set pvr to differ wanted guest cpu on runtiome. >> The intention to bring it up so early at the vm ioctl is that our kernel= code >> can not know if which guest type we want to create on vcpu_create. Vcpu_= create >> itself do not transport any structure and and is called before our hooks= in >> the machine initialization. >=20 > The analogue for x86 is cpuid, and that's handled as a vcpu ioctl. Of > course, they don't go all the way with it, because their guests are > somewhat tied to the host hardware (hardware manages e.g. guest register > state). >=20 >> We want to have our implementation ready to run different guest types at= the >> same time, therefore we can't set this globally at the /dev/kvm ioctl. >> Currently this sets the pvr per machine while in the architecture itself= it >> is a per processor attribute (this binds us to one processor type per vi= rtual >> machine). If needed we might change this so that vcpu_create uses the la= st set >> vm pvr as pvr for a new cpu e.g create generic followed by coprocesser >> sequentially - comments? >=20 > Yes, I really don't like it. :) I think this should be a per-vcpu ioctl, > and then we must make sure we've allocated enough vcpu memory for any > guest architecture type (see vcpu_size as passed to kvm_init()). ok, fine for me. It was you who suggested that we need it on create, but al= locating enough for all possible cases is ok for me. I'll change the pvr stuff. =20 >> Additionally this may later be extended to select the real pvr that e.g.= =20 >> will be presented to what a guest sees on a read to that spr. here the p= atch >> as it is atm folowed by the tlb patch that uses the function to select t= he >> right tlb layout. >=20 > Why aren't you using real PVR numbers already? To be honest I did not want to decide which of the numerous 440 types I sho= uld set and I didn't need to use that pvr&mask match atm. =20 > Anyways, this probably isn't worth spending too much time on now. The > immediate need is for the TLB accessors, and I think we can base those > on the PVR without a full multi-arch guest solution. I'll let it be virtual pvr's - we can change them later without issues anyw= ay. --=20 Gr=FCsse / regards,=20 Christian Ehrhardt IBM Linux Technology Center, Open Virtualization ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-ppc-devel mailing list kvm-ppc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel