From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40366) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuKli-0007ZO-Gz for qemu-devel@nongnu.org; Thu, 05 Nov 2015 08:40:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZuKld-00017c-Db for qemu-devel@nongnu.org; Thu, 05 Nov 2015 08:39:58 -0500 Received: from mga01.intel.com ([192.55.52.88]:49190) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuKld-00017W-21 for qemu-devel@nongnu.org; Thu, 05 Nov 2015 08:39:53 -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> From: Xiao Guangrong Message-ID: <563B5AB3.6040605@linux.intel.com> Date: Thu, 5 Nov 2015 21:33:39 +0800 MIME-Version: 1.0 In-Reply-To: <20151105140326.18b21c32@nial.brq.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [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/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. >> >> That what i did in the v1/v2 versions, however, as you noticed, using 64-bit >> address in ACPI in QEMU is not a easy work - we can not simply make >> SSDT.rev = 2 to apply 64 bit address, the reason i have documented in >> v3's changelog: >> >> 3) we figure out a unused memory hole below 4G that is 0xFF00000 ~ >> 0xFFF00000, this range is large enough for NVDIMM ACPI as build 64-bit >> ACPI SSDT/DSDT table will break windows XP. >> BTW, only make SSDT.rev = 2 can not work since the width is only depended >> on DSDT.rev based on 19.6.28 DefinitionBlock (Declare Definition Block) >> in ACPI spec: >> | Note: For compatibility with ACPI versions before ACPI 2.0, the bit >> | width of Integer objects is dependent on the ComplianceRevision of the DSDT. >> | If the ComplianceRevision is less than 2, all integers are restricted to 32 >> | bits. Otherwise, full 64-bit integers are used. The version of the DSDT sets >> | the global integer width for all integers, including integers in SSDTs. >> 4) use the lowest ACPI spec version to document AML terms. >> >> The only way introducing 64 bit address is adding XSDT support that what >> Michael did before, however, it seems it need great efforts to do it as >> it will break OVMF. It's a long term workload. :( > to enable 64-bit integers in AML it's sufficient to change DSDT revision to 2, > I already have a patch that switches DSDT/SSDT to rev2. > Tests show it doesn't break WindowsXP (which is rev1) and uses 64-bit integers > on linux & later Windows versions. Great, i remembered i did the similar test (directly change DSDT to rev2) and it caused winXP blue screen. Could you please tell me where i can find your patch? > >> >> The luck thing is, the ACPI part is not ABI, we can move it to the high >> memory if QEMU supports XSDT is ready in future development. > But mapped control region is ABI and we can't change it if we find out later > that it breaks something. But the ACPI code is completely built by QEMU, which is transparent to guest and guest should not depend on it, no?