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

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

On 11/15/2010 10:15 AM, Konrad Rzeszutek Wilk wrote:
>>>  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.

Yes, that's the main reason I think it should be in the toolstack.  The
domain doesn't know whether the PCI hole is necessary or not, and its
too early for it to poke around in xenstore to look for passed devices
or anything.  It could conservatively always reserve a 1G hole at 3G,
but that seems too pessimistic and is a waste of sub-4G adress space
which it might otherwise have use for.

If the toolstack can tell it where to make the hole by editing the E820,
then the dom0 and domU cases are very similar.

The question of whether all the pages given by the builder to the domain
should be distributed over the E820 RAM ranges, or should just be
considered ballooned out of the holes (which is what currently happens)
is pretty much orthogonal.

    J


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel