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

[Gordan Bobic <gordan@xxxxxxxxxx>]

On 07/29/2013 12:17 AM, 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.
That is indeed where I was pondering going with this, yes - apply the 
same restriction in the HVM case that exists in the PV case.
Regarding the e820_host=1 case, which of the following is true:

1) The dom0 BAR areas are simply reserved/holes and the domU still maps 
it's own BARs elsewhere in the memory space?
2) domU is free to map BARs into any of the host E820 map holes of 
appropriate size?
3) vBAR=pBAR

4) Other?

Thanks.

Gordan

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