On 03/29/16 03:11, Jan Beulich wrote: > >>> On 29.03.16 at 10:47, <haozhong.zh...@intel.com> wrote: > > On 03/17/16 22:21, Haozhong Zhang wrote: > >> On 03/17/16 14:00, Ian Jackson wrote: > >> > Haozhong Zhang writes ("Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM > >> > support for Xen"): > >> > > QEMU keeps mappings of guest memory because (1) that mapping is > >> > > created by itself, and/or (2) certain device emulation needs to access > >> > > the guest memory. But for vNVDIMM, I'm going to move the creation of > >> > > its mappings out of qemu to toolstack and vNVDIMM in QEMU does not > >> > > access vNVDIMM pages mapped to guest, so it's not necessary to let > >> > > qemu keeps vNVDIMM mappings. > >> > > >> > I'm confused by this. > >> > > >> > Suppose a guest uses an emulated device (or backend) provided by qemu, > >> > to do DMA to an vNVDIMM. Then qemu will need to map the real NVDIMM > >> > pages into its own address space, so that it can write to the memory > >> > (ie, do the virtual DMA). > >> > > >> > That virtual DMA might well involve a direct mapping in the kernel > >> > underlying qemu: ie, qemu might use O_DIRECT to have its kernel write > >> > directly to the NVDIMM, and with luck the actual device backing the > >> > virtual device will be able to DMA to the NVDIMM. > >> > > >> > All of this seems to me to mean that qemu needs to be able to map > >> > its guest's parts of NVDIMMs > >> > > >> > There are probably other example: memory inspection systems used by > >> > virus scanners etc.; debuggers used to inspect a guest from outside; > >> > etc. > >> > > >> > I haven't even got started on save/restore... > >> > > >> > >> Oops, so many cases I missed. Thanks Ian for pointing out all these! > >> Now I need to reconsider how to manage guest permissions for NVDIMM pages. > >> > > > > I still cannot find a neat approach to manage guest permissions for > > nvdimm pages. A possible one is to use a per-domain bitmap to track > > permissions: each bit corresponding to an nvdimm page. The bitmap can > > save lots of spaces and even be stored in the normal ram, but > > operating it for a large nvdimm range, especially for a contiguous > > one, is slower than rangeset. > > I don't follow: What would a single bit in that bitmap mean? Any > guest may access the page? That surely wouldn't be what we > need. >
For a host having a N pages of nvdimm, each domain will have a N bits bitmap. If the m'th bit of a domain's bitmap is set, then that domain has the permission to access the m'th host nvdimm page. > > BTW, if I take the other way to map nvdimm pages to guest > > (http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg01972.html) > > | 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 treat nvdimm as normal ram, then xen will not need to use rangeset > > or above bitmap to track guest permissions for nvdimm? But looking at > > how qemu currently populates guest memory via XENMEM_populate_physmap > > , and other hypercalls like XENMEM_[in|de]crease_reservation, it looks > > like that mapping a _dedicated_ piece of host ram to guest is not > > allowed out of the hypervisor (and not allowed even in dom0 kernel)? > > Is it for security concerns, e.g. avoiding a malfunctioned dom0 leaking > > guest memory? > > Well, it's simply because RAM is a resource managed through > allocation/freeing, instead of via reserving chunks for special > purposes. > So that means xen can always ensure the ram assigned to a guest is what the guest is permitted to access, so no data structures like iomem_caps is needed for ram. If I have to introduce a hypercall that maps the dedicated host ram/nvdimm to guest, then the explicit permission management is still needed, regardless of who (dom0 kernel, qemu or toolstack) will use it. Right? Haozhong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel