linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: ian.campbell@citrix.com (Ian Campbell)
To: linux-arm-kernel@lists.infradead.org
Subject: arm64: iomem_resource doesn't contain all the region used
Date: Fri, 23 Oct 2015 16:45:12 +0100	[thread overview]
Message-ID: <1445615112.2374.226.camel@citrix.com> (raw)
In-Reply-To: <562A4B0F.2020603@citrix.com>

On Fri, 2015-10-23 at 15:58 +0100, Julien Grall wrote:
> Is there any way we could register the IO region used on ARM without
> having to enforce it in all the drivers?

This seems like an uphill battle to me.

Why not do as I suggested IRL yesterday and expose the map of "potential
RAM" addresses to the guest as well as the "actual RAM" addresses in the
regular memory properties.

i.e. explicitly expose the holes where RAM can be hotplugged later.

This is even analogous to a native memory hotplug case, which AIUI
similarly involves the provisioning of specific address space where RAM
might plausibly appear in the future (I don't think physical memory hotplug
involves searching for free PA space and hoping for the best, although
strange things have happened I guess).

With any luck you would be able to steal or define the bindings in terms of
the native hotplug case rather than inventing some Xen specific thing.

In terms of dom0 the "potential" RAM is the host's actual RAM banks.

In terms of domU the "potential" RAM is defined by the domain builder
layout (currently the two banks mentioned in Xen's arch-arm.h).

Ian.

  reply	other threads:[~2015-10-23 15:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-23 14:58 arm64: iomem_resource doesn't contain all the region used Julien Grall
2015-10-23 15:45 ` Ian Campbell [this message]
2015-10-28 17:32   ` Julien Grall
2015-10-29 16:36     ` Daniel Kiper
2015-10-29 17:24       ` Julien Grall
2015-10-30 17:53         ` Daniel Kiper
2015-10-30 18:32           ` Julien Grall
2015-10-30 20:36             ` Daniel Kiper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1445615112.2374.226.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).