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

[Gordan Bobic <gordan@xxxxxxxxxx>]

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

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