From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58955) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYU2v-0004fs-1L for qemu-devel@nongnu.org; Sun, 06 Sep 2015 03:07:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZYU2r-0003bG-Q7 for qemu-devel@nongnu.org; Sun, 06 Sep 2015 03:07:24 -0400 Received: from mga03.intel.com ([134.134.136.65]:53560) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYU2r-0003bC-Ku for qemu-devel@nongnu.org; Sun, 06 Sep 2015 03:07:21 -0400 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> <55E6D2DD.1020009@linux.intel.com> <20150902134204.2273d58c@nial.brq.redhat.com> From: Xiao Guangrong Message-ID: <55EBE4BB.4090104@linux.intel.com> Date: Sun, 6 Sep 2015 15:01:15 +0800 MIME-Version: 1.0 In-Reply-To: <20150902134204.2273d58c@nial.brq.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 02/18] i386/acpi-build: allow SSDT to operate on 64 bit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov 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 On 09/02/2015 07:42 PM, Igor Mammedov wrote: > On Wed, 2 Sep 2015 18:43:41 +0800 > Xiao Guangrong wrote: > >> >> >> 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? > Probably it will, but why DSDT should be v2 for one of SSDT to be v2, > they are separate tables. When i made the first version of this patch, i only changed SSDT to v2 in build_ssdt() but it failed, it worked only if both SSDT and DSDT were changed to v2. :( I will confirm it again and figure it out. > > Also you might find following interesting wrt Windows compatibility > http://www.acpi.info/presentations/S01USMOBS169_OS%20new.ppt That's great help to me, thanks for your sharing, Igor!