From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface Date: Fri, 2 Jul 2010 20:41:40 +0200 Message-ID: References: <1277980982-12433-1-git-send-email-agraf@suse.de> <1277980982-12433-28-git-send-email-agraf@suse.de> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8BIT Cc: kvm-ppc@vger.kernel.org, linuxppc-dev , KVM list To: Segher Boessenkool Return-path: Received: from cantor.suse.de ([195.135.220.2]:42406 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757298Ab0GBSlm convert rfc822-to-8bit (ORCPT ); Fri, 2 Jul 2010 14:41:42 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 02.07.2010, at 18:27, Segher Boessenkool wrote: >> +To find out if we're running on KVM or not, we overlay the PVR register. Usually >> +the PVR register contains an id that identifies your CPU type. If, however, you >> +pass KVM_PVR_PARA in the register that you want the PVR result in, the register >> +still contains KVM_PVR_PARA after the mfpvr call. >> + >> + LOAD_REG_IMM(r5, KVM_PVR_PARA) >> + mfpvr r5 >> + [r5 still contains KVM_PVR_PARA] > > I love this part :-) :) > >> + __u64 scratch3; >> + __u64 critical; /* Guest may not get interrupts if == r1 */ >> + __u64 sprg0; >> + __u64 sprg1; >> + __u64 sprg2; >> + __u64 sprg3; >> + __u64 srr0; >> + __u64 srr1; >> + __u64 dar; >> + __u64 msr; >> + __u32 dsisr; >> + __u32 int_pending; /* Tells the guest if we have an interrupt */ >> +}; >> + >> +Additions to the page must only occur at the end. Struct fields are always 32 >> +bit aligned. > > The u64s are 64-bit aligned, should they always be? That's obvious, isn't it? And the ABI only specifies u64s to be 32 bit aligned, no? At least that's what ld and std specify. > >> +The "ld" and "std" instructions are transormed to "lwz" and "stw" instructions >> +respectively on 32 bit systems with an added offset of 4 to accomodate for big >> +endianness. > > Will this add never overflow? Is there anything that checks for it? It basically means that to access dar, we either do ld rX, DAR(0) or lwz rX, DAR+4(0) > >> +mtmsrd rX, 0 b >> +mtmsr b > > mtmsr rX Nod. Alex From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.suse.de (cantor.suse.de [195.135.220.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx1.suse.de", Issuer "CAcert Class 3 Root" (verified OK)) by ozlabs.org (Postfix) with ESMTPS id 7BC22B70A7 for ; Sat, 3 Jul 2010 04:41:46 +1000 (EST) Subject: Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Alexander Graf In-Reply-To: Date: Fri, 2 Jul 2010 20:41:40 +0200 Message-Id: References: <1277980982-12433-1-git-send-email-agraf@suse.de> <1277980982-12433-28-git-send-email-agraf@suse.de> To: Segher Boessenkool Cc: linuxppc-dev , KVM list , kvm-ppc@vger.kernel.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 02.07.2010, at 18:27, Segher Boessenkool wrote: >> +To find out if we're running on KVM or not, we overlay the PVR = register. Usually >> +the PVR register contains an id that identifies your CPU type. If, = however, you >> +pass KVM_PVR_PARA in the register that you want the PVR result in, = the register >> +still contains KVM_PVR_PARA after the mfpvr call. >> + >> + LOAD_REG_IMM(r5, KVM_PVR_PARA) >> + mfpvr r5 >> + [r5 still contains KVM_PVR_PARA] >=20 > I love this part :-) :) >=20 >> + __u64 scratch3; >> + __u64 critical; /* Guest may not get interrupts if =3D=3D = r1 */ >> + __u64 sprg0; >> + __u64 sprg1; >> + __u64 sprg2; >> + __u64 sprg3; >> + __u64 srr0; >> + __u64 srr1; >> + __u64 dar; >> + __u64 msr; >> + __u32 dsisr; >> + __u32 int_pending; /* Tells the guest if we have an = interrupt */ >> +}; >> + >> +Additions to the page must only occur at the end. Struct fields are = always 32 >> +bit aligned. >=20 > The u64s are 64-bit aligned, should they always be? That's obvious, isn't it? And the ABI only specifies u64s to be 32 bit = aligned, no? At least that's what ld and std specify. >=20 >> +The "ld" and "std" instructions are transormed to "lwz" and "stw" = instructions >> +respectively on 32 bit systems with an added offset of 4 to = accomodate for big >> +endianness. >=20 > Will this add never overflow? Is there anything that checks for it? It basically means that to access dar, we either do ld rX, DAR(0) or lwz rX, DAR+4(0) >=20 >> +mtmsrd rX, 0 b >> +mtmsr b >=20 > mtmsr rX Nod. Alex From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Date: Fri, 02 Jul 2010 18:41:40 +0000 Subject: Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface Message-Id: List-Id: References: <1277980982-12433-1-git-send-email-agraf@suse.de> <1277980982-12433-28-git-send-email-agraf@suse.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Segher Boessenkool Cc: kvm-ppc@vger.kernel.org, linuxppc-dev , KVM list On 02.07.2010, at 18:27, Segher Boessenkool wrote: >> +To find out if we're running on KVM or not, we overlay the PVR register. Usually >> +the PVR register contains an id that identifies your CPU type. If, however, you >> +pass KVM_PVR_PARA in the register that you want the PVR result in, the register >> +still contains KVM_PVR_PARA after the mfpvr call. >> + >> + LOAD_REG_IMM(r5, KVM_PVR_PARA) >> + mfpvr r5 >> + [r5 still contains KVM_PVR_PARA] > > I love this part :-) :) > >> + __u64 scratch3; >> + __u64 critical; /* Guest may not get interrupts if = r1 */ >> + __u64 sprg0; >> + __u64 sprg1; >> + __u64 sprg2; >> + __u64 sprg3; >> + __u64 srr0; >> + __u64 srr1; >> + __u64 dar; >> + __u64 msr; >> + __u32 dsisr; >> + __u32 int_pending; /* Tells the guest if we have an interrupt */ >> +}; >> + >> +Additions to the page must only occur at the end. Struct fields are always 32 >> +bit aligned. > > The u64s are 64-bit aligned, should they always be? That's obvious, isn't it? And the ABI only specifies u64s to be 32 bit aligned, no? At least that's what ld and std specify. > >> +The "ld" and "std" instructions are transormed to "lwz" and "stw" instructions >> +respectively on 32 bit systems with an added offset of 4 to accomodate for big >> +endianness. > > Will this add never overflow? Is there anything that checks for it? It basically means that to access dar, we either do ld rX, DAR(0) or lwz rX, DAR+4(0) > >> +mtmsrd rX, 0 b >> +mtmsr b > > mtmsr rX Nod. Alex