Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

[Haozhong Zhang <haozhong.zhang@xxxxxxxxx>]

Hi Jan and Konrad,

On 03/04/16 15:30, Haozhong Zhang wrote:
> Suddenly realize it's unnecessary to let QEMU get SPA ranges of NVDIMM
> or files on NVDIMM. We can move that work to toolstack and pass SPA
> ranges got by toolstack to qemu. In this way, no privileged operations
> (mmap/mlock/...) are needed in QEMU and non-root QEMU should be able to
> work even with vNVDIMM hotplug in future.
> 

As I'm going to let toolstack to get NVDIMM SPA ranges. This can be
done via dom0 kernel interface and xen hypercalls, and can be
implemented in different ways. I'm wondering which of the following
ones is preferred by xen.

1. Given
    * a file descriptor of either a NVDIMM device or a file on NVDIMM, and
    * domain id and guest MFN where vNVDIMM is going to be.
   xen toolstack (1) gets it SPA ranges via dom0 kernel interface
   (e.g. sysfs and ioctl FIEMAP), and (2) calls a hypercall to map
   above SPA ranges to the given guest MFN of the given domain.

2. Or, given the same inputs, we may combine above two steps into a new
   dom0 system call that (1) gets the SPA ranges, (2) calls xen
   hypercall to map SPA ranges, and, one step further, (3) returns SPA
   ranges to userspace (because QEMU needs these addresses to build ACPI).

The first way does not need to modify dom0 linux kernel, while the
second requires a new system call. I'm not sure whether xen toolstack
as a userspace program is considered to be safe to pass the host physical
address to hypervisor. If not, maybe the second one is better?

Thanks,
Haozhong

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel