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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Sun, 2013-07-28 at 19:17 -0400, Konrad Rzeszutek Wilk wrote:
> 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. 

Yes, I don't think it is unreasonable to disallow migration when
hardware specific workarounds have been applied (which is really what
e820_host is, for either PV or HVM).

Ian.


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