Re: [Qemu-devel] KVM "fake DAX" flushing interface - discussion

[Dan Williams]

On Thu, Jan 18, 2018 at 9:48 AM, David Hildenbrand <address@hidden> wrote:
>>> 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)

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.