From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42935) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abUYt-0002M8-Gl for qemu-devel@nongnu.org; Thu, 03 Mar 2016 09:49:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1abUYm-0005M1-Q8 for qemu-devel@nongnu.org; Thu, 03 Mar 2016 09:49:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44027) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abUYm-0005Lo-GN for qemu-devel@nongnu.org; Thu, 03 Mar 2016 09:49:00 -0500 Date: Thu, 3 Mar 2016 16:48:55 +0200 From: "Michael S. Tsirkin" Message-ID: <20160303164730-mutt-send-email-mst@redhat.com> References: <1456919441-101204-1-git-send-email-guangrong.xiao@linux.intel.com> <1456919441-101204-6-git-send-email-guangrong.xiao@linux.intel.com> <20160303152819-mutt-send-email-mst@redhat.com> <56D844AB.5060805@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56D844AB.5060805@linux.intel.com> Subject: Re: [Qemu-devel] [PATCH v5 5/5] nvdimm acpi: add _CRS List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Xiao Guangrong Cc: ehabkost@redhat.com, kvm@vger.kernel.org, gleb@kernel.org, mtosatti@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, imammedo@redhat.com, pbonzini@redhat.com, dan.j.williams@intel.com, rth@twiddle.net On Thu, Mar 03, 2016 at 10:05:31PM +0800, Xiao Guangrong wrote: > > > On 03/03/2016 09:29 PM, Michael S. Tsirkin wrote: > >On Wed, Mar 02, 2016 at 07:50:41PM +0800, Xiao Guangrong wrote: > >>As Igor suggested that we can report the BIOS patched operation region > >>so that OSPM could see that particular range is in use and be able to > >>notice conflicts if it happens some day > >> > >>Signed-off-by: Xiao Guangrong > > > >This is reserved RAM, exposing it in _CRS makes no sense to me. > > As more and more memory will be reserved by BIOS/QEMU, report the > information to OSPM and let it check the potential error is bad, > no? :) guest has enough info to detect conflicts if it wishes to. IIUC _CRS is not intended for RAM, it's for MMIO resources, if it works for RAM that's an accident. -- MST