qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dan Williams
Subject: Re: [Qemu-devel] KVM "fake DAX" flushing interface - discussion
Date: Thu, 18 Jan 2018 12:11:47 -0800

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

I think that's reasonable. Once we have the virtio based discovery I
think the incremental changes to libnvdimm core and the pmem driver
are small.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]