On Thu, Jan 18, 2018 at 9:48 AM, David Hildenbrand <david(a)redhat.com> wrote:
>> I'd like to emphasize again, that I would prefer a
>> 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
Hmm, yes, it seems if ACPI is just going to be used as a trigger for
"go find the virtio-X interface for this range" we could have started
from a virtio device in the first place.