From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57395) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIepq-0002DV-Pc for qemu-devel@nongnu.org; Wed, 26 Feb 2014 08:47:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIepk-0005tb-Pu for qemu-devel@nongnu.org; Wed, 26 Feb 2014 08:47:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:16690) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIepk-0005tH-Gz for qemu-devel@nongnu.org; Wed, 26 Feb 2014 08:47:36 -0500 Message-ID: <530DF070.7020803@redhat.com> Date: Wed, 26 Feb 2014 14:47:28 +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> <20140226144333.5ed8e07e@nial.usersys.redhat.com> In-Reply-To: <20140226144333.5ed8e07e@nial.usersys.redhat.com> 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: Igor Mammedov Cc: Hu Tao , Marcelo Tosatti , lersek@redhat.com, qemu-devel@nongnu.org, Wanlong Gao Il 26/02/2014 14:43, Igor Mammedov ha scritto: > On Wed, 26 Feb 2014 13:45:38 +0100 > Paolo Bonzini wrote: > >> Il 26/02/2014 13:31, Igor Mammedov ha scritto: >>>>> The problem is that some backends might not be handled the same way. >>>>> For example, not all backends might produce a single void*/size_t pair >>>>> for the entire region. Think of a "composite" backend that produces a >>>>> large memory region from two smaller ones. >>> 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. > Isn't issue here in how backend is mapped into GPA? Well that is not > backend's job. > > Once one starts to put layout (alignment, noncontinuously mapped > memory regions inside of container, ...), mapping HPA->GPA gets complicated. > > It would be better to use simple building blocks and model as: > 2 separate backends (ram + hugetlbfs) and 2 corresponding DIMM devices. Right, I had forgotten that you can have cold-plugged DIMM devices. That's a nice solution, also because it simplifies passing the GPA configuration down to the guest. How would that translate to sharing HostMemoryBackend code for memory policies? Which of Hu Tao's proposals do you like best? Paolo