[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.
- Re: [Qemu-devel] KVM "fake DAX" flushing interface - discussion, (continued)
- Re: [Qemu-devel] KVM "fake DAX" flushing interface - discussion, David Hildenbrand, 2018/01/18
- Re: [Qemu-devel] KVM "fake DAX" flushing interface - discussion, Dan Williams, 2018/01/18
- Re: [Qemu-devel] KVM "fake DAX" flushing interface - discussion, David Hildenbrand, 2018/01/18
- Re: [Qemu-devel] KVM "fake DAX" flushing interface - discussion, Dan Williams, 2018/01/18
- Re: [Qemu-devel] KVM "fake DAX" flushing interface - discussion, Pankaj Gupta, 2018/01/18
- Re: [Qemu-devel] KVM "fake DAX" flushing interface - discussion, Dan Williams, 2018/01/18
- Re: [Qemu-devel] KVM "fake DAX" flushing interface - discussion, Pankaj Gupta, 2018/01/18
- Re: [Qemu-devel] KVM "fake DAX" flushing interface - discussion, Dan Williams, 2018/01/18
- Re: [Qemu-devel] KVM "fake DAX" flushing interface - discussion, David Hildenbrand, 2018/01/18
- Re: [Qemu-devel] KVM "fake DAX" flushing interface - discussion,
Dan Williams <=