8:48 p.m.
On Thu, Jan 18, 2018 at 11:36 AM, Pankaj Gupta <pagupta(a)redhat.com> wrote:
>
> On Thu, Jan 18, 2018 at 10:54 AM, Pankaj Gupta <pagupta(a)redhat.com> 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)
> >
> > I agree here if we discover regions with virtio-X we don't need to worry
> > about
> > NFIT ACPI. Actually, there are three ways to do it with pros and cons of
> > these
> > approaches:
> >
> > 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.
o.k that means we can configure libnvdimm with virtio as well and use existing pmem
driver. AFAICU it uses nvdimm bus?
Do we need other features which ACPI provides?
No, to keep it simple use nvdimm_pmem_region_create without
registering any DIMM devices. I'd start with the e820 driver as a bus
driver reference (drivers/nvdimm/e820.c) rather than try to unwind the
complexity of the nfit driver.