Re: [Xen-devel] [RFC 15/19] xen/arm: Reserve region in guest memory for device passthrough

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2014-06-18 at 16:23 +0100, Julien Grall wrote:
> On 06/18/2014 04:12 PM, Stefano Stabellini wrote:
> > On Mon, 16 Jun 2014, Julien Grall wrote:
> >> This region will be split by the toolstack to allocate MMIO range for eac
> >> device.
> >>
> >> For now only reserve a 512MB region, this should be enought to passthrough
> >> multiple device at the same time.
> >>
> >> Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
> >> ---
> >>  xen/include/public/arch-arm.h |    4 ++++
> >>  1 file changed, 4 insertions(+)
> >>
> >> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> >> index ac54cd6..789bffb 100644
> >> --- a/xen/include/public/arch-arm.h
> >> +++ b/xen/include/public/arch-arm.h
> >> @@ -369,6 +369,10 @@ typedef uint64_t xen_callback_t;
> >>  #define GUEST_GICC_BASE   0x03002000ULL
> >>  #define GUEST_GICC_SIZE   0x00000100ULL
> >>  
> >> +/* Space for mapping MMIO from device passthrough: 512MB @ 256MB*/
> >> +#define GUEST_MMIO_BASE   0x10000000ULL
> >> +#define GUEST_MMIO_SIZE   0x20000000ULL
> > 
> > Is it really necessary to specify size here? It looks like an artifical
> > limitation to me: given that is unlikely that we'll ever be able to
> > support non-PCI device hotplug, we only have to handle cold-plug here.
> > So the toolstack has all the information it needs to build the perfect
> > memory layout for the guest at VM creation time.
> 
> We have the same "artificial" limitation for the RAM banks... The
> toolstack doesn't know where the different regions end up without the
> size. As the layout may move in the future, adding the size avoid
> modifying the toolstack every time we change it.

It also provides a documentary clue to people modifying things in this
file to remind them to think about how much space they need to try and
leave for this when adding something else.

Ian.


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