Re: upstream merge status for 2.6.35, .36?

[Jeremy Fitzhardinge <jeremy@goop.org>]

On 06/07/2010 10:12 AM, Josip Rodin wrote:
> On Mon, Jun 07, 2010 at 10:57:43AM -0400, Konrad Rzeszutek Wilk wrote:
>   
>>> so the end-result should be bulletproof (as much as it can be :).
>>>       
>> There are some outstanding issues that we know of. I hadn't yet gotten
>> my head around them, but here is a list of Xen PCI frontend bugs:
>>
>> 1). Pass in 4GB or more to DomU. All the memory that the guest sees are
>> RAM and there are no "holes" for the PCI devices, akin to what you have
>> on a normal machine (the hole is 256MB and it shifts 256MB of RAM above
>> the 4GB - we don't do that yet in DomU). Workaround: use less memory, or
>> some magic Linux kernel parameter (memhole?) to create a hole.
>>     
> Does this just mean you can't have PCI frontend in those domUs?
> IOW it may be a regression compared to Xen .18, but not compared to what's
> in mainline at the moment?
>   

We actually have the same problem in dom0, but the fix is to simply
punch a hole in the memory map to make space for the pci devices where
the host e820 maps make holes.  The memory in the hole is freed back to
Xen, so it isn't wasted, but it means that if you want to start a domain
with 4G of usable memory, you need to give it something like 5G.

For domU we don't have direct access to the host e820 map to determine
where the holes are.  I think we could just punch out the 3-4G range and
everything would be happy.  But you'd have the same problem that there
would be a big step in the amount of usable memory you could give a domain.

Probably the best fix is to relocate the memory higher up the address
space rather than free it, so that its still usable by the domain.

Anyway, this isn't a huge thing to fix.  It just requires a bit of
thought about how its all going to fit together.

    J