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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

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

~Andrew

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