From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49180) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIeK0-00089A-7c for qemu-devel@nongnu.org; Wed, 26 Feb 2014 08:14:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIeJu-0002gJ-9E for qemu-devel@nongnu.org; Wed, 26 Feb 2014 08:14:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58108) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIeJt-0002gC-Vh for qemu-devel@nongnu.org; Wed, 26 Feb 2014 08:14:42 -0500 Message-ID: <530DE8B3.7070704@redhat.com> Date: Wed, 26 Feb 2014 14:14:27 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <53047351.80300@redhat.com> <20140219103657.4daed264@nial.usersys.redhat.com> <20140226055706.GA5090@G08FNSTD100614.fnst.cn.fujitsu.com> <20140226101056.1a9ec3b3@nial.usersys.redhat.com> <530DC2FA.9080401@redhat.com> <20140226133119.3ccca5a3@nial.usersys.redhat.com> <530DE1F2.6060701@redhat.com> <20140226125814.GA10055@amt.cnet> In-Reply-To: <20140226125814.GA10055@amt.cnet> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v18 13/14] memory backend: fill memory backend ram fields List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: Igor Mammedov , lersek@redhat.com, qemu-devel@nongnu.org, Wanlong Gao , Hu Tao Il 26/02/2014 13:58, Marcelo Tosatti ha scritto: >>> I'd prefer to keep backends simple, with 1:1 mapping to memory regions. >> >> I agree. However not all backends may have a mapping to a RAM >> memory region. A composite backend could create a container memory >> region whose children are other HostMemoryBackend objects. >> >>> Is there a need in composite one or something similar? >> >> I've heard of users that want a node backed partially by hugetlbfs >> and partially by regular RAM. Not sure why. > > To overcommit the non hugetlbfs backed guest RAM (think guest pagecache on that non > hugetlbfs backed memory, swappable and KSM-able). > > The problem is, you have to in someway guarantee the guest allocates > 1GB pages out of the hugetlb backed GPA ranges. Some thoughts > (honestly, dislike all of them): > > 1) Boot guest with hugepages, allocate hugepages in guest, > later on hotplug 4K backed ranges. HV-unaware reboot might fail, > though. > > 2) Communicate hugepage GPAs to guest. > > 3) Create holes in non hugepage backed GPA range. I guess (2) is the only one I "like", and I like it just because it officially becomes Not Our Problem. Paolo