From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiao Guangrong Subject: Re: [Qemu-devel] [PATCH v2 02/18] i386/acpi-build: allow SSDT to operate on 64 bit Date: Wed, 2 Sep 2015 18:43:41 +0800 Message-ID: <55E6D2DD.1020009@linux.intel.com> References: <1439563931-12352-1-git-send-email-guangrong.xiao@linux.intel.com> <1439563931-12352-3-git-send-email-guangrong.xiao@linux.intel.com> <20150902120602.74c57da0@nial.brq.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: 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, rth@twiddle.net To: Igor Mammedov Return-path: Received: from mga02.intel.com ([134.134.136.20]:29225 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752778AbbIBKtd (ORCPT ); Wed, 2 Sep 2015 06:49:33 -0400 In-Reply-To: <20150902120602.74c57da0@nial.brq.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 09/02/2015 06:06 PM, Igor Mammedov wrote: > On Fri, 14 Aug 2015 22:51:55 +0800 > Xiao Guangrong wrote: > >> Only 512M is left for MMIO below 4G and that are used by PCI, BIOS etc. >> Other components also reserve regions from their internal usage, e.g, >> [0xFED00000, 0xFED00000 + 0x400) is reserved for HPET >> >> Switch SSDT to 64 bit to use the huge free room above 4G. In the later >> patches, we will dynamical allocate free space within this region which >> is used by NVDIMM _DSM method >> >> Signed-off-by: Xiao Guangrong >> --- >> hw/i386/acpi-build.c | 4 ++-- >> hw/i386/acpi-dsdt.dsl | 2 +- >> 2 files changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c >> index 46eddb8..8ead1c1 100644 >> --- a/hw/i386/acpi-build.c >> +++ b/hw/i386/acpi-build.c >> @@ -1348,7 +1348,7 @@ build_ssdt(GArray *table_data, GArray *linker, >> g_array_append_vals(table_data, ssdt->buf->data, ssdt->buf->len); >> build_header(linker, table_data, >> (void *)(table_data->data + table_data->len - ssdt->buf->len), >> - "SSDT", ssdt->buf->len, 1); >> + "SSDT", ssdt->buf->len, 2); > That might break Windows XP, since it supports only 1.0b ACPI with some > 2.0 extensions. > there is 2 way to work around it: > - add an additional Rev2 ssdt table if NVDIMMs are present > and describe them there I like this way, it's more straightforward to me. BTW, IIUC the DSDT still need to be changed to Rev2 to recognise SSDT with Rev2, does it hurt Windows XP?