Re: [Xen-devel] Bug: Limitation of <=2GB RAM in domU persists with 4.3.0

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

Gordan Bobic <gordan@xxxxxxxxxx> wrote:
>On 07/28/2013 11:26 AM, Konrad Rzeszutek Wilk wrote:
>> Andrew Bobulsky <rulerof@xxxxxxxxx> wrote:
>>> On Thu, Jul 25, 2013 at 8:21 PM, Ian Campbell
><ian.campbell@xxxxxxxxxx>
>>> wrote:
>>>> On Thu, 2013-07-25 at 23:23 +0100, Gordan Bobic wrote:
>>>>> Now, if I am understanding the basic nature of the problem
>>> correctly,
>>>>> this _could_ be worked around by ensuring that vBAR = pBAR since
>in
>>> that
>>>>> case there is no room for the mis-mapped memory overwrites to
>occur.
>>> Is
>>>>> that correct?
>>>>
>>>> AIUI (which is not very well...) it's not so much vBAR=pBAR but
>>> making
>>>> the guest e820 (memory map) have the same MMIO holes as the host so
>>> that
>>>> there can't be any clash between v- or p-BAR and RAM in the guest.
>>>>
>>>>> I guess I could test this easily enough by applying the vBAR =
>pBAR
>>> hack.
>>>>
>>>> Does the e820_host=1 option help? That might be PV only though, I
>>> can't
>>>> remember...
>>>
>>> Alas, yes.  The man pages list it under "PV Guest Specific Options":
>>> http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html
>>>
>>> You got my hopes up! ;)
>>>
>>> Carry on!  I'll be sitting here metaphorically munching popcorn with
>>> anticipation :P
>>
>> We could implement that for HVM guests too. But I am not sure about
>> the consequences of this for migration (say you unplug the device
>> beforehand and then migrate to another host which has a different
>> E820). That part requires a bit of pondering.
>
>Just out of interest, what happens in case where the PV guests get 
>migrated with e820_host=1 set?
>
>Gordan

We disallow (I think?)  as there is no way we can guarantee the E820 map.  I 
guess your point is that since we disallow this on PV with this parameter there 
is not much difference in allowing HVM guest with this. 

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