On Wed, Feb 28, 2018 at 05:36:59PM +0800, Haozhong Zhang wrote: > On 02/27/18 17:22 +0000, Anthony PERARD wrote: > > On Thu, Dec 07, 2017 at 06:18:02PM +0800, Haozhong Zhang wrote: > > > This is the QEMU part patches that works with the associated Xen > > > patches to enable vNVDIMM support for Xen HVM domains. Xen relies on > > > QEMU to build guest NFIT and NVDIMM namespace devices, and allocate > > > guest address space for vNVDIMM devices. > > > > I've got other question, and maybe possible improvements. > > > > When QEMU build the ACPI tables, it also initialize some MemoryRegion, > > which use more guest memory. Do you know if those regions are used with > > your patch series on Xen? > > Yes, that's why dm_acpi_size is introduced. > > > Otherwise, we could try to avoid their > > creation with this: > > In xenfv_machine_options() > > m->rom_file_has_mr = false; > > (setting this in xen_hvm_init() would probably be better, but I havn't > > try) > > If my memory is correct, simply setting rom_file_has_mr to false does > not work (though I cannot remind the exact reason). I'll have a look > as the code to refresh my memory.
I've played a bit with this idea, but without a proper NVDIMM available for the guest, so I don't know if it's going to work properly without the mr. To make it work, I had to disable some code in acpi_build_update() that make use of the MemoryRegions, as well as an assert in acpi_setup(). After those small hacks, I could boot the guest, and I've check that the expected ACPI tables where there, and they looked correct to my eyes. And least `ndctl list` works and showed the nvdimm (that I have configured on QEMU's cmdline). But I may not have been far enough with my tests, and maybe something later relies on the MRs, especially the _DSM method that I don't know if it was working properly. Anyway, that why I proposed the idea, and if we can avoid more uncertainty about how much guest memory QEMU is going to use, that would be good. Thanks, -- Anthony PERARD
