From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiao Guangrong Subject: Re: How to reserve guest physical region for ACPI Date: Fri, 8 Jan 2016 12:21:09 +0800 Message-ID: <568F3935.5020307@linux.intel.com> References: <1449040860-19040-1-git-send-email-guangrong.xiao@linux.intel.com> <5680A0C8.6040505@linux.intel.com> <20151228141917-mutt-send-email-mst@redhat.com> <20151230165554.4d15e5a4@nial.brq.redhat.com> <20151230213740-mutt-send-email-mst@redhat.com> <20160105173025.4aa4e69f@nial.brq.redhat.com> <20160105183211-mutt-send-email-mst@redhat.com> <568BF861.8040907@linux.intel.com> <20160107102157.5fba01cf@nial.brq.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Michael S. Tsirkin" , pbonzini@redhat.com, gleb@kernel.org, mtosatti@redhat.com, stefanha@redhat.com, rth@twiddle.net, ehabkost@redhat.com, dan.j.williams@intel.com, kvm@vger.kernel.org, qemu-devel@nongnu.org, Laszlo Ersek To: Igor Mammedov Return-path: Received: from mga09.intel.com ([134.134.136.24]:54868 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753612AbcAHEaQ (ORCPT ); Thu, 7 Jan 2016 23:30:16 -0500 In-Reply-To: <20160107102157.5fba01cf@nial.brq.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 01/07/2016 05:21 PM, Igor Mammedov wrote: > On Wed, 6 Jan 2016 01:07:45 +0800 > Xiao Guangrong wrote: > >> On 01/06/2016 12:43 AM, Michael S. Tsirkin wrote: >> >>>>> Yes - if address is static, you need to put it outside >>>>> the table. Can come right before or right after this. >>>>> >>>>>> Also if OperationRegion() is used, then one has to patch >>>>>> DefOpRegion directly as RegionOffset must be Integer, >>>>>> using variable names is not permitted there. >>>>> >>>>> I am not sure the comment was understood correctly. >>>>> The comment says really "we can't use DataTableRegion >>>>> so here is an alternative". >>>> so how are you going to access data at which patched >>>> NameString point to? >>>> for that you'd need a normal patched OperationRegion >>>> as well since DataTableRegion isn't usable. >>> >>> For VMGENID you would patch the method that >>> returns the address - you do not need an op region >>> as you never access it. >>> >>> I don't know about NVDIMM. Maybe OperationRegion can >>> use the patched NameString? Will need some thought. >> >> The ACPI spec says that the offsetTerm in OperationRegion >> is evaluated as Int, so the named object is allowed to be >> used in OperationRegion, that is exact what my patchset >> is doing (http://marc.info/?l=kvm&m=145193395624537&w=2): > that's not my reading of spec: > " > DefOpRegion := OpRegionOp NameString RegionSpace RegionOffset RegionLen > RegionOffset := TermArg => Integer > TermArg := Type2Opcode | DataObject | ArgObj | LocalObj > " > > Named object is not allowed per spec, but you've used ArgObj which is > allowed, even Windows ok with such dynamic OperationRegion. Sorry, Named object i was talking about is something like this: Name("SOTH", int(0x10000)) I am checking acpi spec, and this is a formal NamedObj definition in that spec, my fault. > >> >> + dsm_mem = aml_arg(3); >> + aml_append(method, aml_store(aml_call0(NVDIMM_GET_DSM_MEM), dsm_mem)); >> >> + aml_append(method, aml_operation_region("NRAM", AML_SYSTEM_MEMORY, >> + dsm_mem, TARGET_PAGE_SIZE)); >> >> We hide the int64 object which is patched by BIOS in the method, >> NVDIMM_GET_DSM_MEM, to make windows XP happy. > considering that NRAM is allocated in low mem it's even fine to move > OperationRegion into object scope to get rid of IASL warnings > about declariong Named object inside method, but the you'd need to > patch it directly as the only choice for RegionOffset would be DataObject > Yes, it is. So it is depends on the question in my reply of another thread: http://marc.info/?l=kvm&m=145222487605390&w=2 Can we assume that BIOS allocated address is always 32 bits? If yes, we also need not make ssdt as v2. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54589) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHOgv-0002HH-8V for qemu-devel@nongnu.org; Thu, 07 Jan 2016 23:30:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHOgq-0000Z6-OT for qemu-devel@nongnu.org; Thu, 07 Jan 2016 23:30:21 -0500 Received: from mga14.intel.com ([192.55.52.115]:60015) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHOgq-0000YZ-JE for qemu-devel@nongnu.org; Thu, 07 Jan 2016 23:30:16 -0500 References: <1449040860-19040-1-git-send-email-guangrong.xiao@linux.intel.com> <5680A0C8.6040505@linux.intel.com> <20151228141917-mutt-send-email-mst@redhat.com> <20151230165554.4d15e5a4@nial.brq.redhat.com> <20151230213740-mutt-send-email-mst@redhat.com> <20160105173025.4aa4e69f@nial.brq.redhat.com> <20160105183211-mutt-send-email-mst@redhat.com> <568BF861.8040907@linux.intel.com> <20160107102157.5fba01cf@nial.brq.redhat.com> From: Xiao Guangrong Message-ID: <568F3935.5020307@linux.intel.com> Date: Fri, 8 Jan 2016 12:21:09 +0800 MIME-Version: 1.0 In-Reply-To: <20160107102157.5fba01cf@nial.brq.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] How to reserve guest physical region for ACPI List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: ehabkost@redhat.com, kvm@vger.kernel.org, "Michael S. Tsirkin" , gleb@kernel.org, mtosatti@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, pbonzini@redhat.com, dan.j.williams@intel.com, Laszlo Ersek , rth@twiddle.net On 01/07/2016 05:21 PM, Igor Mammedov wrote: > On Wed, 6 Jan 2016 01:07:45 +0800 > Xiao Guangrong wrote: > >> On 01/06/2016 12:43 AM, Michael S. Tsirkin wrote: >> >>>>> Yes - if address is static, you need to put it outside >>>>> the table. Can come right before or right after this. >>>>> >>>>>> Also if OperationRegion() is used, then one has to patch >>>>>> DefOpRegion directly as RegionOffset must be Integer, >>>>>> using variable names is not permitted there. >>>>> >>>>> I am not sure the comment was understood correctly. >>>>> The comment says really "we can't use DataTableRegion >>>>> so here is an alternative". >>>> so how are you going to access data at which patched >>>> NameString point to? >>>> for that you'd need a normal patched OperationRegion >>>> as well since DataTableRegion isn't usable. >>> >>> For VMGENID you would patch the method that >>> returns the address - you do not need an op region >>> as you never access it. >>> >>> I don't know about NVDIMM. Maybe OperationRegion can >>> use the patched NameString? Will need some thought. >> >> The ACPI spec says that the offsetTerm in OperationRegion >> is evaluated as Int, so the named object is allowed to be >> used in OperationRegion, that is exact what my patchset >> is doing (http://marc.info/?l=kvm&m=145193395624537&w=2): > that's not my reading of spec: > " > DefOpRegion := OpRegionOp NameString RegionSpace RegionOffset RegionLen > RegionOffset := TermArg => Integer > TermArg := Type2Opcode | DataObject | ArgObj | LocalObj > " > > Named object is not allowed per spec, but you've used ArgObj which is > allowed, even Windows ok with such dynamic OperationRegion. Sorry, Named object i was talking about is something like this: Name("SOTH", int(0x10000)) I am checking acpi spec, and this is a formal NamedObj definition in that spec, my fault. > >> >> + dsm_mem = aml_arg(3); >> + aml_append(method, aml_store(aml_call0(NVDIMM_GET_DSM_MEM), dsm_mem)); >> >> + aml_append(method, aml_operation_region("NRAM", AML_SYSTEM_MEMORY, >> + dsm_mem, TARGET_PAGE_SIZE)); >> >> We hide the int64 object which is patched by BIOS in the method, >> NVDIMM_GET_DSM_MEM, to make windows XP happy. > considering that NRAM is allocated in low mem it's even fine to move > OperationRegion into object scope to get rid of IASL warnings > about declariong Named object inside method, but the you'd need to > patch it directly as the only choice for RegionOffset would be DataObject > Yes, it is. So it is depends on the question in my reply of another thread: http://marc.info/?l=kvm&m=145222487605390&w=2 Can we assume that BIOS allocated address is always 32 bits? If yes, we also need not make ssdt as v2.