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

[David Hildenbrand]

>> 1] Existing pmem driver & virtio for region discovery:
>>   -----------------------------------------------------
>>   Use existing pmem driver which is tightly coupled with concepts of 
>> namespaces, labels etc
>>   from ACPI region discovery and re-implement these concepts with virtio so 
>> that existing
>>   pmem driver can understand it. In addition to this, task of pmem driver to 
>> send flush command
>>   using virtio.
> 
> It's not tightly coupled. The whole point of libnvdimm is to be
> agnostic to ACPI, e820 or any other range discovery. The only work to
> do beyond identifying the address range is teaching libnvdimm to pass
> along a flush control interface to the pmem driver.
> 
>>
>> 2] Existing pmem driver & ACPI NFIT for region discovery:
>>   ----------------------------------------------------------------
>> - If we use NFIT ACPI, we need to teach existing ACPI driver to add this new 
>> memory
>>   type and teach existing pmem driver to handle this new memory type. Still 
>> we need
>>   an asynchronous(virtio) way to send flush commands. We need virtio 
>> device/driver
>>   or arbitrary key/value like pair just to send commands from guest to host 
>> using virtio.
>>
>> 3] New Virtio pmem driver & paravirt device:
>>  ----------------------------------------
>>   Third way is new virtio pmem driver with less work to support existing 
>> features of different protocols,
>>   and with asynchronous way of sending flush commands.
>>
>>   But this needs to duplicate some of the work which existing pmem driver 
>> does but as discussed
>>   previously we can separate common code from existing pmem driver and reuse 
>> it.
>>
>> Among these approaches I also prefer 3].
> 
> I disagree, the reason we went down this ACPI path was to limit the
> needless duplication of most of the pmem driver.
> 

I have way to little insight to make qualified statements to different
approaches here. :)

All I am interesting in is making this as independent of architecture
specific technologies (e.g. ACPI) as possible. We will want this e.g.
for s390x too. Rather sooner than later. So trying to couple this
(somehow) to ACPI just for the sake of less code to copy will not pay of
in the long run.

Better have a clean virtio interface / design right from the start.

So I hope my words will be heard :)

-- 

Thanks,

David / dhildenb