From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: KVM "fake DAX" flushing interface - discussion References: <1455443283.33337333.1500618150787.JavaMail.zimbra@redhat.com> <86754966-281f-c3ed-938c-f009440de563@gmail.com> <1511288389.1080.14.camel@redhat.com> <654f8935-258e-22ef-fae4-3e14e91e8fae@redhat.com> <336152896.34452750.1511527207457.JavaMail.zimbra@redhat.com> From: David Hildenbrand Message-ID: <72839100-7fdf-693c-e9c2-348a5add8a56@redhat.com> Date: Thu, 18 Jan 2018 18:48:38 +0100 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Dan Williams Cc: Kevin Wolf , Pankaj Gupta , Rik van Riel , Jan Kara , Xiao Guangrong , kvm-devel , Stefan Hajnoczi , Ross Zwisler , Qemu Developers , Christoph Hellwig , Stefan Hajnoczi , "linux-nvdimm@lists.01.org" , Paolo Bonzini , Nitesh Narayan Lal List-ID: >> I'd like to emphasize again, that I would prefer a virtio-pmem only >> solution. >> >> There are architectures out there (e.g. s390x) that don't support >> NVDIMMs - there is no HW interface to expose any such stuff. >> >> However, with virtio-pmem, we could make it work also on architectures >> not having ACPI and friends. > > ACPI and virtio-only can share the same pmem driver. There are two > parts to this, region discovery and setting up the pmem driver. For > discovery you can either have an NFIT-bus defined range, or a new > virtio-pmem-bus define it. As far as the pmem driver itself it's > agnostic to how the range is discovered. > And in addition to discovery + setup, we need the flush via virtio. > In other words, pmem consumes 'regions' from libnvdimm and the a bus > provider like nfit, e820, or a new virtio-mechansim produce 'regions'. > That sounds good to me. I would like to see how the ACPI discovery variant connects to a virtio ring. The natural way for me would be: A virtio-X device supplies a memory region ("discovery") and also the interface for flushes for this device. So one virtio-X corresponds to one pmem device. No ACPI to be involved (also not on architectures that have ACPI) -- Thanks, David / dhildenb _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Hildenbrand Subject: Re: KVM "fake DAX" flushing interface - discussion Date: Thu, 18 Jan 2018 18:48:38 +0100 Message-ID: <72839100-7fdf-693c-e9c2-348a5add8a56@redhat.com> References: <1455443283.33337333.1500618150787.JavaMail.zimbra@redhat.com> <86754966-281f-c3ed-938c-f009440de563@gmail.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=utf-8 Content-Transfer-Encoding: 8bit Cc: Pankaj Gupta , Paolo Bonzini , Rik van Riel , Xiao Guangrong , Christoph Hellwig , Jan Kara , Stefan Hajnoczi , Stefan Hajnoczi , kvm-devel , Qemu Developers , "linux-nvdimm@lists.01.org" , ross zwisler , Kevin Wolf , Nitesh Narayan Lal , Haozhong Zhang , Ross Zwisler To: Dan Williams Return-path: Received: from mx1.redhat.com ([209.132.183.28]:27726 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753228AbeARRsw (ORCPT ); Thu, 18 Jan 2018 12:48:52 -0500 In-Reply-To: Content-Language: en-US Sender: kvm-owner@vger.kernel.org List-ID: >> I'd like to emphasize again, that I would prefer a virtio-pmem only >> solution. >> >> There are architectures out there (e.g. s390x) that don't support >> NVDIMMs - there is no HW interface to expose any such stuff. >> >> However, with virtio-pmem, we could make it work also on architectures >> not having ACPI and friends. > > ACPI and virtio-only can share the same pmem driver. There are two > parts to this, region discovery and setting up the pmem driver. For > discovery you can either have an NFIT-bus defined range, or a new > virtio-pmem-bus define it. As far as the pmem driver itself it's > agnostic to how the range is discovered. > And in addition to discovery + setup, we need the flush via virtio. > In other words, pmem consumes 'regions' from libnvdimm and the a bus > provider like nfit, e820, or a new virtio-mechansim produce 'regions'. > That sounds good to me. I would like to see how the ACPI discovery variant connects to a virtio ring. The natural way for me would be: A virtio-X device supplies a memory region ("discovery") and also the interface for flushes for this device. So one virtio-X corresponds to one pmem device. No ACPI to be involved (also not on architectures that have ACPI) -- Thanks, David / dhildenb From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52128) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecEJ8-00046K-RU for qemu-devel@nongnu.org; Thu, 18 Jan 2018 12:48:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ecEJ3-0003up-NB for qemu-devel@nongnu.org; Thu, 18 Jan 2018 12:48:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39238) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ecEJ3-0003tQ-HQ for qemu-devel@nongnu.org; Thu, 18 Jan 2018 12:48:53 -0500 References: <1455443283.33337333.1500618150787.JavaMail.zimbra@redhat.com> <86754966-281f-c3ed-938c-f009440de563@gmail.com> <1511288389.1080.14.camel@redhat.com> <654f8935-258e-22ef-fae4-3e14e91e8fae@redhat.com> <336152896.34452750.1511527207457.JavaMail.zimbra@redhat.com> From: David Hildenbrand Message-ID: <72839100-7fdf-693c-e9c2-348a5add8a56@redhat.com> Date: Thu, 18 Jan 2018 18:48:38 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] KVM "fake DAX" flushing interface - discussion List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dan Williams Cc: Pankaj Gupta , Paolo Bonzini , Rik van Riel , Xiao Guangrong , Christoph Hellwig , Jan Kara , Stefan Hajnoczi , Stefan Hajnoczi , kvm-devel , Qemu Developers , "linux-nvdimm@lists.01.org" , ross zwisler , Kevin Wolf , Nitesh Narayan Lal , Haozhong Zhang , Ross Zwisler >> I'd like to emphasize again, that I would prefer a virtio-pmem only >> solution. >> >> There are architectures out there (e.g. s390x) that don't support >> NVDIMMs - there is no HW interface to expose any such stuff. >> >> However, with virtio-pmem, we could make it work also on architectures >> not having ACPI and friends. >=20 > ACPI and virtio-only can share the same pmem driver. There are two > parts to this, region discovery and setting up the pmem driver. For > discovery you can either have an NFIT-bus defined range, or a new > virtio-pmem-bus define it. As far as the pmem driver itself it's > agnostic to how the range is discovered. >=20 And in addition to discovery + setup, we need the flush via virtio. > In other words, pmem consumes 'regions' from libnvdimm and the a bus > provider like nfit, e820, or a new virtio-mechansim produce 'regions'. >=20 That sounds good to me. I would like to see how the ACPI discovery variant connects to a virtio ring. The natural way for me would be: A virtio-X device supplies a memory region ("discovery") and also the interface for flushes for this device. So one virtio-X corresponds to one pmem device. No ACPI to be involved (also not on architectures that have ACPI) --=20 Thanks, David / dhildenb