Re: [Xen-devel] Feature Request : dummy paddings for mapping memory holes in privcmd

[Andres Lagar-Cavilla <andreslc@xxxxxxxxxxxxxx>]

On Aug 9, 2013, at 6:18 PM, Guanglin Xu <mzguanglin@xxxxxxxxx> wrote:

> Hi All,
> 
> As a developer of high efficient VMI (Virtual Machine Introspection)
> applications, I appreciate hypervisor to map the whole guest memory
> for us.
> 
> While Xen has been providing mmap_foreign_range() API by libxc and
> privcmd for a long time, it denies to map if the requested page range
> includes memory holes, such as page 160 - 191 legacy video buffer, VGA
> reserved memory, PCI hole, MMIO hole, etc. (see
> http://techfiles.de/dmelanchthon/files/memory_hole.pdf ).
> 
> Maybe you would ask, "what the hell do you want dummy memory holes?!"
> It is because VMI applications are almost about memory searching where
> both the probing of derived separate memory regions and processing on
> them can slow it down a lot.

Sounds like a non-sequitur… "memory searching?".

First of all, you application can easily deal with memory holes with some 
internal remapping data structure or bitmap.

Second, if you don't want to do that, in order to persistently map the whole 
memory in a contiguous range with non-holes, you should look at mremap. It 
*should* work with privcmd mappings, but your mileage may vary.

Third, by keeping a persistent map to all pages, you effectively disable memory 
paging, sharing, and ballooning, so keep that in mind.

Andres

> 
> In fact, we have recently added such feature for KVM hypervisor.

In KVM the "RAM" is a flat ram block upon which memory holes ROMs and BIOSes 
are overlaid, coming from separate ram blocks. So maybe you're looking at zeros 
when you should be looking at something else. Hard to tell.

Andres
> However, we are not familiar with Xen. So we hope Xen community can
> help.
> 
> Thanks,
> 
> Guanglin


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