Re: [RFC Patch] Support for making an E820 PCI hole in toolstack (xl + xm)

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

> >  1). Did not work for me - I am not sure why but I had the hardest time do
> >      hypervisor_populate_physmap - it would just hang the guest.
> 
> For a PV guest you don't need to do any alloc/free/move memory hypercalls.
> You rewrite your own p2m to relocate mfns where you want them in pfn space.
> Then some hypercalls just to update the m2p array to match.

Ok, I can play with that see what fun/havoc I can create.
> 
> >  2). It is much simple to parse the E820 in the Linux kernel than actually
> >      creating new E820 entries in the kernel (hypercall), making a bunch of
> >      hypervisor calls that unmap, then remap the space, filling out the P2M
> >      with INVALID_MFN, and doing all of that before the "real" Linux kernel
> >      actually starts (all would have to be done in xen_start_kernel).
> >      I have a sinking feeling tha the upstream community would not like it
> >      this that much.
> 
> Well it is all quite Xen specific, so I'm surprised.

Oh, there was another reason that I so obvious that I completly forgot. DomU
has no idea where the host PCI hole starts. In most cases it is at 3GB (or even
further up - 3.5GB), but a quick look for 'Allocating PCI resources starting at' 
at Google shows that there are some that start at 1.2G.