Re: [Xen-devel] [PATCH] xen/arm: Implement domain_get_maximum_gpfn

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2014-07-02 at 11:58 +0100, Andrew Cooper wrote:
> On 02/07/14 11:52, Ian Campbell wrote:
> > On Wed, 2014-07-02 at 12:51 +0200, Roger Pau Monnà wrote:
> >> On 02/07/14 12:31, Jan Beulich wrote:
> >>>>>> On 02.07.14 at 12:19, <roger.pau@xxxxxxxxxx> wrote:
> >>>> For PVH guests there's still no MMIO hole (or any other kind of hole) at
> >>>> all, the hole(s) is only there for Dom0.
> >>> So where would passed through devices get their MMIO BARs located?
> >>> (I realize pass-through isn't supported yet for PVH, but I didn't expect
> >>> such fundamental things to be missing.)
> >> We could always add a MMIO region to a PVH guest in backwards compatible
> >> way, the only requirement is to make sure the e820 provided to the guest
> >> has this hole set up, but I see no reason to add it before having this
> >> functionality, or to add it unconditionally to guests even if no devices
> >> are passed through.
> >>
> >> Also, shouldn't PVH guests use pcifront/pciback, which means it won't
> >> have any BARs mapped directly?
> > They need to map them somewhere in their physical address to be able to
> > use them... (Unlike a PV guest which I think maps them in the virtual
> > address space "by magic" avoiding the need for a p2m entry).
> >
> > Ian.
> 
> With respect to the original problem of accidentally punching a hole in
> the guest
> 
> Why cant libxc clean up after itself?  From my understanding, it is a
> simple increase reservation to fill the hole it 'borrowed' during setup.

I think the issue is that in the functions in question it doesn't know
if there was RAM there to start with (since it's based on guest RAM
allocation and layout etc), so it doesn't know if it needs refill the
hole or not.

Not insurmountable though I suspect.

> 
> This avoids MMIO ranges in pure PVH guests (arm included).
> 
> ~Andrew



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