From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33942) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDNoo-0007dV-Db for qemu-devel@nongnu.org; Sun, 27 Dec 2015 21:45:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aDNoj-0006Ao-F6 for qemu-devel@nongnu.org; Sun, 27 Dec 2015 21:45:54 -0500 Received: from mga04.intel.com ([192.55.52.120]:31841) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDNoj-00069S-9X for qemu-devel@nongnu.org; Sun, 27 Dec 2015 21:45:49 -0500 References: <1449040860-19040-1-git-send-email-guangrong.xiao@linux.intel.com> From: Xiao Guangrong Message-ID: <5680A0C8.6040505@linux.intel.com> Date: Mon, 28 Dec 2015 10:39:04 +0800 MIME-Version: 1.0 In-Reply-To: <1449040860-19040-1-git-send-email-guangrong.xiao@linux.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] How to reserve guest physical region for ACPI List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: pbonzini@redhat.com, imammedo@redhat.com, mst@redhat.com Cc: ehabkost@redhat.com, kvm@vger.kernel.org, gleb@kernel.org, mtosatti@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, dan.j.williams@intel.com, rth@twiddle.net Hi Michael, Paolo, Now it is the time to return to the challenge that how to reserve guest physical region internally used by ACPI. Igor suggested that: | 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 (https://lists.nongnu.org/archive/html/qemu-devel/2015-11/msg00926.html) he also innovated a way to use 64-bit address in DSDT/SSDT.rev = 1: | when writing ASL one shall make sure that only XP supported | features are in global scope, which is evaluated when tables | are loaded and features of rev2 and higher are inside methods. | That way XP doesn't crash as far as it doesn't evaluate unsupported | opcode and one can guard those opcodes checking _REV object if neccesary. (https://lists.nongnu.org/archive/html/qemu-devel/2015-11/msg01010.html) Michael, Paolo, what do you think about these ideas? Thanks!