qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Question about vNVDIMM file format


From: Zhang, Haozhong
Subject: Re: [Qemu-devel] Question about vNVDIMM file format
Date: Wed, 18 May 2016 16:11:01 +0800
User-agent: Mutt/1.5.24 (2015-08-30)

Hi Richard,

On 05/18/16 15:04, Xiao Guangrong wrote:
[..]
> >There are a few possible problems / questions I have:
> >
> >(a) How necessary is the ACPI dependency?  We disable ACPI because it
> >is quite slow, adding something like 150-200ms to the boot process
> >(every millisecond counts for us!).  Because I previously never needed
> >ACPI, I never really looked into why this is, and it could be
> >something quite simple, so I'm going to look at this issue next.  I
> >understand that NVDIMMs are not regular (eg) PCI devices, so ordinary
> >device probing isn't going to work, and that probably answers the
> >question why you need to use ACPI.
> 
> Yes, ACPI is necessary to export NVDIMM devices. The good news is that
> Intel is working on ‘lite QEMU’ which only has basic/simplest ACPI
> support. Haozhong, who has been CCed, is working on it.
>

The way we were used for non-ACPI VM is really a dirty hack: we
modified qemu and seabios to create a type-12 e820 entry for each pmem
region, so that the guest linux could use the legacy pmem driver.

According to ACPI 6 spec, type-7 e820 entries should be used
here. However, the pmem driver in linux still requires ACPI for pmem
present via type-7 e820 entries. (That is why we turned to type-12
and why I call it a hack.)

We are now considering to add ACPI back in our project (for some other
requirements than NVDIMM) and consequently will use the standard
NVDIMM ACPI in QEMU, so above hack will be obsoleted in future. No
optimization has been applied to NVDIMM ACPI so far.

If the customized linux kernel is allowed, you could attempt to remove
most ACPI supports and only leave NFIT (and maybe others that cannot
be removed), which may save some boot time.

[..]
> 
> >(d) If, in future, you add the namespace metadata, what tools will be
> >available on the host to create a packed filesystem + metadata?
> >Assuming that we won't be able to export just a filesystem as I am
> >doing now.
> 
> Yes, this kind of tool is useful, we has this plan however it is low priority
> in our TODO. :(
>

I'm not clear the exact requirement here. Maybe you could have a look
at ndctl (https://github.com/pmem/ndctl) which supports some sorts of
operations on namespace.

Thanks,
Haozhong



reply via email to

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