From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pankaj Gupta Subject: Re: KVM "fake DAX" flushing interface - discussion Date: Sat, 13 Jan 2018 01:23:05 -0500 (EST) Message-ID: <326660076.6160176.1515824585284.JavaMail.zimbra@redhat.com> References: <1455443283.33337333.1500618150787.JavaMail.zimbra@redhat.com> <1511288389.1080.14.camel@redhat.com> <654f8935-258e-22ef-fae4-3e14e91e8fae@redhat.com> <336152896.34452750.1511527207457.JavaMail.zimbra@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Kevin Wolf , Rik van Riel , Jan Kara , Xiao Guangrong , kvm-devel , Stefan Hajnoczi , Ross Zwisler , Qemu Developers , Christoph Hellwig , Stefan Hajnoczi , "linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org" , Paolo Bonzini , Nitesh Narayan Lal To: Dan Williams Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" List-Id: kvm.vger.kernel.org Hello Dan, > Not a flag, but a new "Address Range Type GUID". See section "5.2.25.2 > System Physical Address (SPA) Range Structure" in the ACPI 6.2A > specification. Since it is a GUID we could define a Linux specific > type for this case, but spec changes would allow non-Linux hypervisors > to advertise a standard interface to guests. > I have added new SPA with a GUUID for this memory type and I could add this new memory type in System memory map. I need help with the namespace handling for this new type As mentioned in [1] discussion: - Create a new namespace for this new memory type - Teach libnvdimm how to handle this new namespace I have some queries on this: 1] How namespace handling of this new memory type would be? 2] There are existing namespace types: ND_DEVICE_NAMESPACE_IO, ND_DEVICE_NAMESPACE_PMEM, ND_DEVICE_NAMESPACE_BLK How libnvdimm will handle this new name-space type in conjuction with existing memory type, region & namespaces? 3] For sending guest to host flush commands we still have to think about some async way? [1] https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg08404.html Thanks, Pankaj