From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38288) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZexQw-0000AZ-Ng for qemu-devel@nongnu.org; Wed, 23 Sep 2015 23:42:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZexQr-00064E-KT for qemu-devel@nongnu.org; Wed, 23 Sep 2015 23:42:58 -0400 Received: from e23smtp07.au.ibm.com ([202.81.31.140]:54266) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZexQr-00061h-2g for qemu-devel@nongnu.org; Wed, 23 Sep 2015 23:42:53 -0400 Received: from /spool/local by e23smtp07.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 24 Sep 2015 13:42:49 +1000 Date: Thu, 24 Sep 2015 09:11:52 +0530 From: Bharata B Rao Message-ID: <20150924034152.GE16381@in.ibm.com> References: <1442893189-5680-1-git-send-email-bharata@linux.vnet.ibm.com> <1442893189-5680-2-git-send-email-bharata@linux.vnet.ibm.com> <20150923032853.GU20331@voom.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150923032853.GU20331@voom.fritz.box> Subject: Re: [Qemu-devel] [RFC PATCH v0 1/2] spapr: Allocate HTAB from machine init Reply-To: bharata@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: nfont@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com On Wed, Sep 23, 2015 at 01:28:53PM +1000, David Gibson wrote: > On Tue, Sep 22, 2015 at 09:09:48AM +0530, Bharata B Rao wrote: > > Allocate HTAB from ppc_spapr_init() so that we can abort the guest > > if requested HTAB size is't allocated by the host. However retain the > > htab reset call in spapr_reset_htab() so that HTAB gets reset (and > > not allocated) during machine reset. > > I was briefly worried about this, because I recall there as a reason > htab allocation got moved to the reset handler in the first place. > Looking at the git history, however, I've convinced myself this is > basically ok (because you preserve the call during reset to wipe clean > the htab). > > > Signed-off-by: Bharata B Rao > > --- > > hw/ppc/spapr.c | 13 ++++++++++++- > > 1 file changed, 12 insertions(+), 1 deletion(-) > > > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c > > index 7f4f196..4692122 100644 > > --- a/hw/ppc/spapr.c > > +++ b/hw/ppc/spapr.c > > @@ -979,7 +979,7 @@ static void emulate_spapr_hypercall(PowerPCCPU *cpu) > > #define CLEAN_HPTE(_hpte) ((*(uint64_t *)(_hpte)) &= tswap64(~HPTE64_V_HPTE_DIRTY)) > > #define DIRTY_HPTE(_hpte) ((*(uint64_t *)(_hpte)) |= tswap64(HPTE64_V_HPTE_DIRTY)) > > > > -static void spapr_reset_htab(sPAPRMachineState *spapr) > > +static void spapr_alloc_htab(sPAPRMachineState *spapr) > > { > > long shift; > > int index; > > @@ -1012,6 +1012,16 @@ static void spapr_reset_htab(sPAPRMachineState *spapr) > > DIRTY_HPTE(HPTE(spapr->htab, index)); > > } > > } > > +} > > + > > +static void spapr_reset_htab(sPAPRMachineState *spapr) > > +{ > > + /* > > + * We have already allocated the hash page table, this call will > > + * not again allocate but only result in clearing of hash page > > + * table entries. > > + */ > > + kvmppc_reset_htab(spapr->htab_shift); > > It's unlikely the kernel will give us less htab than we already have, > but we really should at least check for that. Probably not much we > can do except abort() but at least we can give a useful error message. With the change I am doing here, this is no longer an allocation path. Host kernel will just clear the HTAB and return the same htab_shift that we passed here. So do you think it still makes sense to check return value ? Regards, Bharata.