Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754530AbcJSFrW (ORCPT ); Wed, 19 Oct 2016 01:47:22 -0400 Received: from mx2.suse.de ([195.135.220.15]:50822 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750737AbcJSFrV (ORCPT ); Wed, 19 Oct 2016 01:47:21 -0400 Subject: Re: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests To: Boris Ostrovsky , Konrad Rzeszutek Wilk References: <1476468318-24422-1-git-send-email-boris.ostrovsky@oracle.com> <1476468318-24422-7-git-send-email-boris.ostrovsky@oracle.com> <20161014191923.GD16777@localhost.localdomain> <20161014195134.GA22782@char.us.oracle.com> <467c1dd5-80a7-4079-ad49-69883fb9f076@oracle.com> Cc: david.vrabel@citrix.com, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, roger.pau@citrix.com From: Juergen Gross Message-ID: <222383a5-29e1-426f-31b7-a4a95f214058@suse.com> Date: Wed, 19 Oct 2016 07:47:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <467c1dd5-80a7-4079-ad49-69883fb9f076@oracle.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1877 Lines: 51 On 18/10/16 18:40, Boris Ostrovsky wrote: > On 10/18/2016 12:08 PM, Juergen Gross wrote: >> On 14/10/16 22:02, Boris Ostrovsky wrote: >>> On 10/14/2016 03:51 PM, Konrad Rzeszutek Wilk wrote: >>>> On Fri, Oct 14, 2016 at 03:43:19PM -0400, Boris Ostrovsky wrote: >>>>> On 10/14/2016 03:19 PM, Konrad Rzeszutek Wilk wrote: >>>>>> On Fri, Oct 14, 2016 at 02:05:16PM -0400, Boris Ostrovsky wrote: >>>>>> >>>>>> Perhaps add in here: >>>>>> >>>>>> PVH is like PV in that there are no PCI devices - which HVM >>>>>> code would piggyback on to find the Xen PCI platform device and >>>>>> use its MMIO space to stash the grants in. >>>>>> >>>>>> For PVH we balloon out memory and stash the grants in there. >>>>>> >>>>>> (Which begs the next question - where and when do we balloon out the >>>>>> normal memory back in?) >>>>> Are you saying that we should get back memory that we gave to grant tables? >>>> Yes. >>>> >>>> In pure HVM that area is MMIO - which hvmloader has balloonned out. >>>> >>>> The hvmloader then balloons that number of pages back at the end of >>>> guest memory (after 4GB). >>> We don't do this for PV though, do we? >> Uuh, kind of. We try to allocate granted pages from the ballooned area. >> See gnttab_alloc_pages(). > > > I meant that we don't give memory back for PV. That's right AFAIK. >> So for PV(H) we don't need to balloon this memory back in as it was >> never shadowed by a grant. > > > Is it *never* or *may or may not be* shadowed? (I assume "shadowed" > means "used for" here.) "shadowed" means a pte is being used for a granted page which was referencing a RAM page before. So the RAM page is unusable as long as the grant is active. A page is shadowed by a grant only if there is no ballooning space available, so ballooning that page out would serve no purpose as we would have no way to balloon it in at another address. Juergen