From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Date: Wed, 30 Jan 2008 21:18:32 +0000 Subject: Re: [kvm-ppc-devel] [PATCH] [1/4] Add per guest pvr Message-Id: <1201727912.10632.14.camel@basalt> 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="us-ascii" Content-Transfer-Encoding: 7bit To: kvm-ppc@vger.kernel.org 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. 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). > 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 virtual > machine). If needed we might change this so that vcpu_create uses the last set > vm pvr as pvr for a new cpu e.g create generic followed by coprocesser > sequentially - comments? 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()). > Additionally this may later be extended to select the real pvr that e.g. > will be presented to what a guest sees on a read to that spr. here the patch > as it is atm folowed by the tlb patch that uses the function to select the > right tlb layout. Why aren't you using real PVR numbers already? 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. -- Hollis Blanchard IBM Linux Technology Center ------------------------------------------------------------------------- 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