From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54618) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwLld-0004qh-CP for qemu-devel@nongnu.org; Tue, 10 Nov 2015 22:08:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwLla-0001xk-5Z for qemu-devel@nongnu.org; Tue, 10 Nov 2015 22:08:13 -0500 Received: from mga03.intel.com ([134.134.136.65]:62826) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwLlZ-0001xb-RO for qemu-devel@nongnu.org; Tue, 10 Nov 2015 22:08:10 -0500 References: <1446455617-129562-1-git-send-email-guangrong.xiao@linux.intel.com> <1446455617-129562-26-git-send-email-guangrong.xiao@linux.intel.com> <20151105105816.4945e0c4@nial.brq.redhat.com> <563B2C43.2030407@linux.intel.com> <20151105140326.18b21c32@nial.brq.redhat.com> <563B5AB3.6040605@linux.intel.com> <20151105154906.659779b5@nial.brq.redhat.com> <563C656F.3030808@linux.intel.com> <20151109121331.55eeba9e@nial.brq.redhat.com> From: Xiao Guangrong Message-ID: <5642AF9A.6090803@linux.intel.com> Date: Wed, 11 Nov 2015 11:01:46 +0800 MIME-Version: 1.0 In-Reply-To: <20151109121331.55eeba9e@nial.brq.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Ask for ACK (was Re: [PATCH v7 25/35] nvdimm acpi: init the resource used by NVDIMM ACPI) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: vsementsov@virtuozzo.com, ehabkost@redhat.com, kvm@vger.kernel.org, mst@redhat.com, gleb@kernel.org, mtosatti@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, pbonzini@redhat.com, dan.j.williams@intel.com, rth@twiddle.net On 11/09/2015 07:13 PM, Igor Mammedov wrote: > On Fri, 6 Nov 2015 16:31:43 +0800 > Xiao Guangrong wrote: > >> >> >> On 11/05/2015 10:49 PM, Igor Mammedov wrote: >>> On Thu, 5 Nov 2015 21:33:39 +0800 >>> Xiao Guangrong wrote: >>> >>>> >>>> >>>> On 11/05/2015 09:03 PM, Igor Mammedov wrote: >>>>> On Thu, 5 Nov 2015 18:15:31 +0800 >>>>> Xiao Guangrong wrote: >>>>> >>>>>> >>>>>> >>>>>> On 11/05/2015 05:58 PM, Igor Mammedov wrote: >>>>>>> On Mon, 2 Nov 2015 17:13:27 +0800 >>>>>>> Xiao Guangrong wrote: >>>>>>> >>>>>>>> A page staring from 0xFF00000 and IO port 0x0a18 - 0xa1b in guest are >>>>>>> ^^ missing one 0??? >>>>>>> >>>>>>>> reserved for NVDIMM ACPI emulation, refer to docs/specs/acpi_nvdimm.txt >>>>>>>> for detailed design >>>>>>>> >>>>>>>> A parameter, 'nvdimm-support', is introduced for PIIX4_PM and ICH9-LPC >>>>>>>> that controls if nvdimm support is enabled, it is true on default and >>>>>>>> it is false on 2.4 and its earlier version to keep compatibility >>>>>>>> >>>>>>>> Signed-off-by: Xiao Guangrong >>>>>>> [...] >>>>>>> >>>>>>>> @@ -33,6 +33,15 @@ >>>>>>>> */ >>>>>>>> #define MIN_NAMESPACE_LABEL_SIZE (128UL << 10) >>>>>>>> >>>>>>>> +/* >>>>>>>> + * A page staring from 0xFF00000 and IO port 0x0a18 - 0xa1b in guest are >>>>>>> ^^^ missing 0 or value in define below has an extra 0 >>>>>>> >>>>>>>> + * reserved for NVDIMM ACPI emulation, refer to docs/specs/acpi_nvdimm.txt >>>>>>>> + * for detailed design. >>>>>>>> + */ >>>>>>>> +#define NVDIMM_ACPI_MEM_BASE 0xFF000000ULL >>>>>>> it still maps RAM at arbitrary place, >>>>>>> that's the reason why VMGenID patches hasn't been merged for >>>>>>> more than several months. >>>>>>> I'm not against of using (more exactly I'm for it) direct mapping >>>>>>> but we should reach consensus when and how to use it first. >>>>>>> >>>>>>> I'd wouldn't use addresses below 4G as it may be used firmware or >>>>>>> legacy hardware and I won't bet that 0xFF000000ULL won't conflict >>>>>>> with anything. >>>>>>> An alternative place to allocate reserve from could be high memory. >>>>>>> For pc we have "reserved-memory-end" which currently makes sure >>>>>>> that hotpluggable memory range isn't used by firmware. >>>>>>> >>>>>>> How about making API that allows to map additional memory >>>>>>> ranges before reserved-memory-end and pushes it up as mappings are >>>>>>> added. > [...] > >> >> Really a good study case to me, i tried your patch and moved the 64 bit >> staffs to the private method, it worked. :) >> >> Igor, is this the API you want? > > Lets get ack from Michael on the idea of RAM mapping before > "reserved-memory-end" first. > If he rejects it then there isn't any other way except of switching > to MMIO instead. Michael, what's your idea? BTW, this is the reason why we prefer to reserve memory space just in case if you missed the thread: http://marc.info/?l=qemu-devel&m=144530844718146&w=2