From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1L8MmY-00040W-Db
	for qemu-devel@nongnu.org; Thu, 04 Dec 2008 17:34:50 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1L8MmW-0003yJ-Ez
	for qemu-devel@nongnu.org; Thu, 04 Dec 2008 17:34:49 -0500
Received: from [199.232.76.173] (port=57543 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1L8MmW-0003y7-9J
	for qemu-devel@nongnu.org; Thu, 04 Dec 2008 17:34:48 -0500
Received: from qw-out-1920.google.com ([74.125.92.150]:52428)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1L8MmV-00019v-Um
	for qemu-devel@nongnu.org; Thu, 04 Dec 2008 17:34:48 -0500
Received: by qw-out-1920.google.com with SMTP id 5so1338646qwc.4
	for <qemu-devel@nongnu.org>; Thu, 04 Dec 2008 14:34:47 -0800 (PST)
Message-ID: <49385B02.9010206@codemonkey.ws>
Date: Thu, 04 Dec 2008 16:34:42 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [5874] Add virtio-balloon support
References: <E1L8Ksl-0007wr-3q@cvs.savannah.gnu.org>
	<1228426490.19459.44.camel@localhost.localdomain>
In-Reply-To: <1228426490.19459.44.camel@localhost.localdomain>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Hollis Blanchard <hollisb@us.ibm.com>
Cc: Rusty Russell <rusty@ozlabs.au.ibm.com>, qemu-devel@nongnu.org, kvm-devel <kvm@vger.kernel.org>

Hollis Blanchard wrote:
> On Thu, 2008-12-04 at 20:33 +0000, Anthony Liguori wrote:
>   
>> +static void balloon_page(void *addr, int deflate)
>> +{
>> +#if defined(__linux__)
>> +    if (!kvm_enabled() || kvm_has_sync_mmu())
>> +        madvise(addr, TARGET_PAGE_SIZE,
>> +                deflate ? MADV_WILLNEED : MADV_DONTNEED);
>> +#endif
>> +}
>>     
>
> Hmm, I just noticed this... we need to use VIRTIO_BALLOON_PFN_SHIFT like
> Rusty did on the kernel side.
>
> However, in general I'm not sure how this is supposed to work. Isn't it
> true that madvise() is a no-op if 0 < length < getpagesize()? If so, how
> should the guest know the chunk size needed on the host?
>   

We need to pass multiple of TARGET_PAGE_SIZE to madvise() but we can 
certainly adjust that depending on VIRTIO_BALLOON_PFN_SHIFT.  But 
basically, if the two aren't equal, we shouldn't even try madvise().

> What happens when a guest tries to balloon 4K pages when it's backed on
> the host by hugetlbfs? We can't even use getpagesize() there.
>   

Nothing.  For ballooning to work in this circumstance, the guest would 
have to balloon 2MB pages which isn't something that's reasonable for it 
to do.

> Maybe the virtio balloon interface needs to advertise a unit size from
> the host, and use that size instead of alloc_page() in the guest?
>   

That's a possibility.  May make sense to give it the ability to balloon 
memory up to unit size because I don't think it'll be able to meet the 
reservation for large pages only.

Regards,

Anthony Liguori