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: David Hildenbrand
Subject: Re: [Qemu-devel] KVM "fake DAX" flushing interface - discussion
Date: Thu, 18 Jan 2018 18:48:38 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

>> 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)

-- 

Thanks,

David / dhildenb



reply via email to

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