* Re: [PATCH] xen: arm: configure correct dom0_gnttab_start/size
2014-09-11 15:21 [PATCH] xen: arm: configure correct dom0_gnttab_start/size Ian Campbell
@ 2014-09-11 15:37 ` Ian Campbell
2014-09-11 15:54 ` Andrew Cooper
` (3 subsequent siblings)
4 siblings, 0 replies; 15+ messages in thread
From: Ian Campbell @ 2014-09-11 15:37 UTC (permalink / raw)
To: xen-devel; +Cc: julien.grall, tim, stefano.stabellini
On Thu, 2014-09-11 at 16:21 +0100, Ian Campbell wrote:
$subject should end "...for vexpress"
> Vexpress is currently failing to boot for me with:
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at arch/arm/mm/ioremap.c:301 __arm_ioremap_pfn_caller+0x118/0x1a4()
> CPU: 0 PID: 1 Comm: swapper Tainted: G W 3.16.0-arm-native+ #276
> [<c0011e9c>] (unwind_backtrace) from [<c0010758>] (show_stack+0x10/0x14)
> [<c0010758>] (show_stack) from [<c001a3ec>] (warn_slowpath_common+0x5c/0x7c)
> [<c001a3ec>] (warn_slowpath_common) from [<c001a4c8>] (warn_slowpath_null+0x18/0x20)
> [<c001a4c8>] (warn_slowpath_null) from [<c001488c>] (__arm_ioremap_pfn_caller+0x118/0x1a4)
> [<c001488c>] (__arm_ioremap_pfn_caller) from [<c00149a0>] (__arm_ioremap+0x14/0x20)
> [<c00149a0>] (__arm_ioremap) from [<c01d103c>] (gnttab_setup_auto_xlat_frames+0x30/0xdc)
> [<c01d103c>] (gnttab_setup_auto_xlat_frames) from [<c0495324>] (xen_guest_init+0x19c/0x2d4)
> [<c0495324>] (xen_guest_init) from [<c0492c6c>] (do_one_initcall+0xfc/0x1a4)
> [<c0492c6c>] (do_one_initcall) from [<c0492d6c>] (kernel_init_freeable+0x58/0x1b4)
> [<c0492d6c>] (kernel_init_freeable) from [<c039611c>] (kernel_init+0x8/0xe4)
> [<c039611c>] (kernel_init) from [<c000de58>] (ret_from_fork+0x14/0x3c)
> ---[ end trace 3406ff24bd97382f ]---
> xen:grant_table: Failed to ioremap gnttab share frames (addr=0x00000000b0000000)!
>
> which is:
> /*
> * Don't allow RAM to be mapped - this causes problems with ARMv6+
> */
> if (WARN_ON(pfn_valid(pfn)))
> return NULL;
>
> This makes sense since the gnttab defaults to 0xb000000 and my dom0
> is being allocated a 1:1 mapping at 0xa0000000-0xc0000000.
>
> I suspect this broke around the time we stopped forcing dom0 memory to be
> allocated as low as possible which happened to prevent the default dom0_gnttab
> region overlapping RAM.
>
> This patch specifies an explicit dom0_gnttab base which is explicitly unused
> according to the FVP model docs (although it correpsonds to CS5 this isn't
> wired up to anything).
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> This just fixes vexpress, I wonder if a followup patch should either remove the
> default dom0_gnttab (forcing all platforms to specify one explicitly) or make
> the default something less arbitrary than 0xb0000000, e.g. 0x0-0x20000 or
> 0xfffe0000-0x100000000 (very start or very end of RAM). Perhaps with a command
> line option to override for new platform hacking.
>
> Or maybe we should search for an unused hole in the dom0 RAM space?
> ---
> xen/arch/arm/platforms/vexpress.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/xen/arch/arm/platforms/vexpress.c b/xen/arch/arm/platforms/vexpress.c
> index 8e6a4ea..ce66935 100644
> --- a/xen/arch/arm/platforms/vexpress.c
> +++ b/xen/arch/arm/platforms/vexpress.c
> @@ -176,6 +176,8 @@ PLATFORM_START(vexpress, "VERSATILE EXPRESS")
> #endif
> .reset = vexpress_reset,
> .blacklist_dev = vexpress_blacklist_dev,
> + .dom0_gnttab_start = 0x10000000,
> + .dom0_gnttab_size = 0x20000,
> PLATFORM_END
>
> /*
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH] xen: arm: configure correct dom0_gnttab_start/size
2014-09-11 15:21 [PATCH] xen: arm: configure correct dom0_gnttab_start/size Ian Campbell
2014-09-11 15:37 ` Ian Campbell
@ 2014-09-11 15:54 ` Andrew Cooper
2014-09-11 16:05 ` Ian Campbell
2014-09-11 20:11 ` Julien Grall
` (2 subsequent siblings)
4 siblings, 1 reply; 15+ messages in thread
From: Andrew Cooper @ 2014-09-11 15:54 UTC (permalink / raw)
To: Ian Campbell, xen-devel; +Cc: julien.grall, tim, stefano.stabellini
On 11/09/14 16:21, Ian Campbell wrote:
> Vexpress is currently failing to boot for me with:
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at arch/arm/mm/ioremap.c:301 __arm_ioremap_pfn_caller+0x118/0x1a4()
> CPU: 0 PID: 1 Comm: swapper Tainted: G W 3.16.0-arm-native+ #276
> [<c0011e9c>] (unwind_backtrace) from [<c0010758>] (show_stack+0x10/0x14)
> [<c0010758>] (show_stack) from [<c001a3ec>] (warn_slowpath_common+0x5c/0x7c)
> [<c001a3ec>] (warn_slowpath_common) from [<c001a4c8>] (warn_slowpath_null+0x18/0x20)
> [<c001a4c8>] (warn_slowpath_null) from [<c001488c>] (__arm_ioremap_pfn_caller+0x118/0x1a4)
> [<c001488c>] (__arm_ioremap_pfn_caller) from [<c00149a0>] (__arm_ioremap+0x14/0x20)
> [<c00149a0>] (__arm_ioremap) from [<c01d103c>] (gnttab_setup_auto_xlat_frames+0x30/0xdc)
> [<c01d103c>] (gnttab_setup_auto_xlat_frames) from [<c0495324>] (xen_guest_init+0x19c/0x2d4)
> [<c0495324>] (xen_guest_init) from [<c0492c6c>] (do_one_initcall+0xfc/0x1a4)
> [<c0492c6c>] (do_one_initcall) from [<c0492d6c>] (kernel_init_freeable+0x58/0x1b4)
> [<c0492d6c>] (kernel_init_freeable) from [<c039611c>] (kernel_init+0x8/0xe4)
> [<c039611c>] (kernel_init) from [<c000de58>] (ret_from_fork+0x14/0x3c)
> ---[ end trace 3406ff24bd97382f ]---
> xen:grant_table: Failed to ioremap gnttab share frames (addr=0x00000000b0000000)!
>
> which is:
> /*
> * Don't allow RAM to be mapped - this causes problems with ARMv6+
> */
> if (WARN_ON(pfn_valid(pfn)))
> return NULL;
>
> This makes sense since the gnttab defaults to 0xb000000 and my dom0
> is being allocated a 1:1 mapping at 0xa0000000-0xc0000000.
>
> I suspect this broke around the time we stopped forcing dom0 memory to be
> allocated as low as possible which happened to prevent the default dom0_gnttab
> region overlapping RAM.
>
> This patch specifies an explicit dom0_gnttab base which is explicitly unused
> according to the FVP model docs (although it correpsonds to CS5 this isn't
> wired up to anything).
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> This just fixes vexpress, I wonder if a followup patch should either remove the
> default dom0_gnttab (forcing all platforms to specify one explicitly) or make
> the default something less arbitrary than 0xb0000000, e.g. 0x0-0x20000 or
> 0xfffe0000-0x100000000 (very start or very end of RAM). Perhaps with a command
> line option to override for new platform hacking.
>
> Or maybe we should search for an unused hole in the dom0 RAM space?
Why it is hard coded at all? (x86 appears to manage fine.) Without it
being variably-located, there will always be a risk of collisions like this.
~Andrew
> ---
> xen/arch/arm/platforms/vexpress.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/xen/arch/arm/platforms/vexpress.c b/xen/arch/arm/platforms/vexpress.c
> index 8e6a4ea..ce66935 100644
> --- a/xen/arch/arm/platforms/vexpress.c
> +++ b/xen/arch/arm/platforms/vexpress.c
> @@ -176,6 +176,8 @@ PLATFORM_START(vexpress, "VERSATILE EXPRESS")
> #endif
> .reset = vexpress_reset,
> .blacklist_dev = vexpress_blacklist_dev,
> + .dom0_gnttab_start = 0x10000000,
> + .dom0_gnttab_size = 0x20000,
> PLATFORM_END
>
> /*
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH] xen: arm: configure correct dom0_gnttab_start/size
2014-09-11 15:54 ` Andrew Cooper
@ 2014-09-11 16:05 ` Ian Campbell
2014-09-11 16:51 ` David Vrabel
0 siblings, 1 reply; 15+ messages in thread
From: Ian Campbell @ 2014-09-11 16:05 UTC (permalink / raw)
To: Andrew Cooper; +Cc: julien.grall, tim, stefano.stabellini, xen-devel
On Thu, 2014-09-11 at 16:54 +0100, Andrew Cooper wrote:
> Why it is hard coded at all? (x86 appears to manage fine.) Without it
> being variably-located, there will always be a risk of collisions like this.
For x86 PV (and shadow?) you can establish a mapping of the gnttab from
a virtual address directly to the machine address without needing a p2m
entry, via whichever hypercall it is which does that.
For HAP (and shadow?) you need a p2m mapping to get at the grant table,
so somewhere has to be found in the physical address space where it can
go.
In theory a guest kernel could try and find some io space which it isn't
using but to help them out we give them a hint.
For x86 HVM the IOBAR of the platform device as a handy place to put the
hint, for ARM domU we have a defined region in our address map which we
use and communicate via device tree.
But for ARM dom0 the physical address space layout follows the host,
figuring out a free bit of space is a bit tricky so each platform is
currently required (except some don't and there is a broken default) to
say where is a safe place to use (i.e. a person has to read the
datasheet and figure it out).
Ideally we would in the future walk the device tree and try and find a
hole in the address space, but that isn't implemented yet (for x86 PVHVM
Linux or ARM AFAICT, I heard a rumour that the windows PV drivers were
moving away from the platform device IOBAR somehow).
Ian.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] xen: arm: configure correct dom0_gnttab_start/size
2014-09-11 16:05 ` Ian Campbell
@ 2014-09-11 16:51 ` David Vrabel
2014-09-12 9:56 ` Ian Campbell
0 siblings, 1 reply; 15+ messages in thread
From: David Vrabel @ 2014-09-11 16:51 UTC (permalink / raw)
To: Ian Campbell, Andrew Cooper
Cc: xen-devel, julien.grall, tim, stefano.stabellini
On 11/09/14 17:05, Ian Campbell wrote:
> On Thu, 2014-09-11 at 16:54 +0100, Andrew Cooper wrote:
>> Why it is hard coded at all? (x86 appears to manage fine.) Without it
>> being variably-located, there will always be a risk of collisions like this.
>
> For x86 PV (and shadow?) you can establish a mapping of the gnttab from
> a virtual address directly to the machine address without needing a p2m
> entry, via whichever hypercall it is which does that.
>
> For HAP (and shadow?) you need a p2m mapping to get at the grant table,
> so somewhere has to be found in the physical address space where it can
> go.
>
> In theory a guest kernel could try and find some io space which it isn't
> using but to help them out we give them a hint.
>
> For x86 HVM the IOBAR of the platform device as a handy place to put the
> hint, for ARM domU we have a defined region in our address map which we
> use and communicate via device tree.
>
> But for ARM dom0 the physical address space layout follows the host,
> figuring out a free bit of space is a bit tricky so each platform is
> currently required (except some don't and there is a broken default) to
> say where is a safe place to use (i.e. a person has to read the
> datasheet and figure it out).
Linux x86 PVH dom0 and domU uses ballooned pages and they're vmap()'d in
into a contiguous bit of virtual address space.
Perhaps something similar could be considered for ARM in the future?
This would be common code between ARM and x86 PVH.
David
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] xen: arm: configure correct dom0_gnttab_start/size
2014-09-11 16:51 ` David Vrabel
@ 2014-09-12 9:56 ` Ian Campbell
0 siblings, 0 replies; 15+ messages in thread
From: Ian Campbell @ 2014-09-12 9:56 UTC (permalink / raw)
To: David Vrabel
Cc: Andrew Cooper, xen-devel, julien.grall, tim, stefano.stabellini
On Thu, 2014-09-11 at 17:51 +0100, David Vrabel wrote:
> On 11/09/14 17:05, Ian Campbell wrote:
> > On Thu, 2014-09-11 at 16:54 +0100, Andrew Cooper wrote:
> >> Why it is hard coded at all? (x86 appears to manage fine.) Without it
> >> being variably-located, there will always be a risk of collisions like this.
> >
> > For x86 PV (and shadow?) you can establish a mapping of the gnttab from
> > a virtual address directly to the machine address without needing a p2m
> > entry, via whichever hypercall it is which does that.
> >
> > For HAP (and shadow?) you need a p2m mapping to get at the grant table,
> > so somewhere has to be found in the physical address space where it can
> > go.
> >
> > In theory a guest kernel could try and find some io space which it isn't
> > using but to help them out we give them a hint.
> >
> > For x86 HVM the IOBAR of the platform device as a handy place to put the
> > hint, for ARM domU we have a defined region in our address map which we
> > use and communicate via device tree.
> >
> > But for ARM dom0 the physical address space layout follows the host,
> > figuring out a free bit of space is a bit tricky so each platform is
> > currently required (except some don't and there is a broken default) to
> > say where is a safe place to use (i.e. a person has to read the
> > datasheet and figure it out).
>
> Linux x86 PVH dom0 and domU uses ballooned pages and they're vmap()'d in
> into a contiguous bit of virtual address space.
>
> Perhaps something similar could be considered for ARM in the future?
> This would be common code between ARM and x86 PVH.
That would be good, yes.
Unfortunately the provision of this "hint" region is now part of our
ABI, so we can't just stop providing it, similar to how if PVHVM x86
switched to using ballooned pages you couldn't just remove the platform
devices IO BAR (not that it causes too much pain on x86, so you likely
wouldn't bother anyway).
Although there maybe migration paths which we can consider in both
cases.
Ian.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] xen: arm: configure correct dom0_gnttab_start/size
2014-09-11 15:21 [PATCH] xen: arm: configure correct dom0_gnttab_start/size Ian Campbell
2014-09-11 15:37 ` Ian Campbell
2014-09-11 15:54 ` Andrew Cooper
@ 2014-09-11 20:11 ` Julien Grall
2014-09-12 9:54 ` Ian Campbell
2014-11-04 10:17 ` Ian Campbell
2014-11-04 12:46 ` Julien Grall
4 siblings, 1 reply; 15+ messages in thread
From: Julien Grall @ 2014-09-11 20:11 UTC (permalink / raw)
To: Ian Campbell, xen-devel; +Cc: tim, stefano.stabellini
Hi Ian,
On 11/09/14 08:21, Ian Campbell wrote:
> This just fixes vexpress, I wonder if a followup patch should either remove the
> default dom0_gnttab (forcing all platforms to specify one explicitly) or make
> the default something less arbitrary than 0xb0000000, e.g. 0x0-0x20000 or
> 0xfffe0000-0x100000000 (very start or very end of RAM). Perhaps with a command
> line option to override for new platform hacking.
Dropping the default value sounds a good solution.
> Or maybe we should search for an unused hole in the dom0 RAM space?
I'm not sure to understand your suggestion here. Did you mean that as
DOM0 will never use all the host RAM, we could find a space in the RAM
to use for grant table?
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] xen: arm: configure correct dom0_gnttab_start/size
2014-09-11 20:11 ` Julien Grall
@ 2014-09-12 9:54 ` Ian Campbell
2014-09-12 19:20 ` Julien Grall
0 siblings, 1 reply; 15+ messages in thread
From: Ian Campbell @ 2014-09-12 9:54 UTC (permalink / raw)
To: Julien Grall; +Cc: stefano.stabellini, tim, xen-devel
On Thu, 2014-09-11 at 13:11 -0700, Julien Grall wrote:
> Hi Ian,
>
> On 11/09/14 08:21, Ian Campbell wrote:
> > This just fixes vexpress, I wonder if a followup patch should either remove the
> > default dom0_gnttab (forcing all platforms to specify one explicitly) or make
> > the default something less arbitrary than 0xb0000000, e.g. 0x0-0x20000 or
> > 0xfffe0000-0x100000000 (very start or very end of RAM). Perhaps with a command
> > line option to override for new platform hacking.
>
> Dropping the default value sounds a good solution.
>
> > Or maybe we should search for an unused hole in the dom0 RAM space?
>
> I'm not sure to understand your suggestion here. Did you mean that as
> DOM0 will never use all the host RAM, we could find a space in the RAM
> to use for grant table?
Something like that, yes.
In fact it occurred to me last night that that since the gnttab needs to
be populate anyway we could allocate it early in the case of 1:1 dom0
and then use that address as a 1:1 value for the gnttab IPA passed to
dom0.
For non-1:1 dom0 we could safely put it right over the dom0 memory
allocation, which as you observe is never going to be all of host ram
(since Xen must be using something...)
In fact, maybe using Xen's own 2M IPA would work everywhere.
Ian.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] xen: arm: configure correct dom0_gnttab_start/size
2014-09-12 9:54 ` Ian Campbell
@ 2014-09-12 19:20 ` Julien Grall
0 siblings, 0 replies; 15+ messages in thread
From: Julien Grall @ 2014-09-12 19:20 UTC (permalink / raw)
To: Ian Campbell; +Cc: stefano.stabellini, tim, xen-devel
Hi Ian,
On 12/09/14 02:54, Ian Campbell wrote:
> On Thu, 2014-09-11 at 13:11 -0700, Julien Grall wrote:
>> Hi Ian,
>>
>> On 11/09/14 08:21, Ian Campbell wrote:
>>> This just fixes vexpress, I wonder if a followup patch should either remove the
>>> default dom0_gnttab (forcing all platforms to specify one explicitly) or make
>>> the default something less arbitrary than 0xb0000000, e.g. 0x0-0x20000 or
>>> 0xfffe0000-0x100000000 (very start or very end of RAM). Perhaps with a command
>>> line option to override for new platform hacking.
>>
>> Dropping the default value sounds a good solution.
>>
>>> Or maybe we should search for an unused hole in the dom0 RAM space?
>>
>> I'm not sure to understand your suggestion here. Did you mean that as
>> DOM0 will never use all the host RAM, we could find a space in the RAM
>> to use for grant table?
>
> Something like that, yes.
>
> In fact it occurred to me last night that that since the gnttab needs to
> be populate anyway we could allocate it early in the case of 1:1 dom0
> and then use that address as a 1:1 value for the gnttab IPA passed to
> dom0.
>
> For non-1:1 dom0 we could safely put it right over the dom0 memory
> allocation, which as you observe is never going to be all of host ram
> (since Xen must be using something...)
>
> In fact, maybe using Xen's own 2M IPA would work everywhere.
The default size of the grant table can be changed via the command line.
This is something we don't handle actually.
So a "malloc" would be the best solution here.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] xen: arm: configure correct dom0_gnttab_start/size
2014-09-11 15:21 [PATCH] xen: arm: configure correct dom0_gnttab_start/size Ian Campbell
` (2 preceding siblings ...)
2014-09-11 20:11 ` Julien Grall
@ 2014-11-04 10:17 ` Ian Campbell
2014-11-04 10:20 ` Stefano Stabellini
2014-11-04 12:46 ` Julien Grall
4 siblings, 1 reply; 15+ messages in thread
From: Ian Campbell @ 2014-11-04 10:17 UTC (permalink / raw)
To: xen-devel, Konrad Rzeszutek Wilk; +Cc: julien.grall, tim, stefano.stabellini
On Thu, 2014-09-11 at 16:21 +0100, Ian Campbell wrote:
I think we should apply this workaround for 4.5 and do things properly
for 4.6. Any thoughts?
> Vexpress is currently failing to boot for me with:
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at arch/arm/mm/ioremap.c:301 __arm_ioremap_pfn_caller+0x118/0x1a4()
> CPU: 0 PID: 1 Comm: swapper Tainted: G W 3.16.0-arm-native+ #276
> [<c0011e9c>] (unwind_backtrace) from [<c0010758>] (show_stack+0x10/0x14)
> [<c0010758>] (show_stack) from [<c001a3ec>] (warn_slowpath_common+0x5c/0x7c)
> [<c001a3ec>] (warn_slowpath_common) from [<c001a4c8>] (warn_slowpath_null+0x18/0x20)
> [<c001a4c8>] (warn_slowpath_null) from [<c001488c>] (__arm_ioremap_pfn_caller+0x118/0x1a4)
> [<c001488c>] (__arm_ioremap_pfn_caller) from [<c00149a0>] (__arm_ioremap+0x14/0x20)
> [<c00149a0>] (__arm_ioremap) from [<c01d103c>] (gnttab_setup_auto_xlat_frames+0x30/0xdc)
> [<c01d103c>] (gnttab_setup_auto_xlat_frames) from [<c0495324>] (xen_guest_init+0x19c/0x2d4)
> [<c0495324>] (xen_guest_init) from [<c0492c6c>] (do_one_initcall+0xfc/0x1a4)
> [<c0492c6c>] (do_one_initcall) from [<c0492d6c>] (kernel_init_freeable+0x58/0x1b4)
> [<c0492d6c>] (kernel_init_freeable) from [<c039611c>] (kernel_init+0x8/0xe4)
> [<c039611c>] (kernel_init) from [<c000de58>] (ret_from_fork+0x14/0x3c)
> ---[ end trace 3406ff24bd97382f ]---
> xen:grant_table: Failed to ioremap gnttab share frames (addr=0x00000000b0000000)!
>
> which is:
> /*
> * Don't allow RAM to be mapped - this causes problems with ARMv6+
> */
> if (WARN_ON(pfn_valid(pfn)))
> return NULL;
>
> This makes sense since the gnttab defaults to 0xb000000 and my dom0
> is being allocated a 1:1 mapping at 0xa0000000-0xc0000000.
>
> I suspect this broke around the time we stopped forcing dom0 memory to be
> allocated as low as possible which happened to prevent the default dom0_gnttab
> region overlapping RAM.
>
> This patch specifies an explicit dom0_gnttab base which is explicitly unused
> according to the FVP model docs (although it correpsonds to CS5 this isn't
> wired up to anything).
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> This just fixes vexpress, I wonder if a followup patch should either remove the
> default dom0_gnttab (forcing all platforms to specify one explicitly) or make
> the default something less arbitrary than 0xb0000000, e.g. 0x0-0x20000 or
> 0xfffe0000-0x100000000 (very start or very end of RAM). Perhaps with a command
> line option to override for new platform hacking.
>
> Or maybe we should search for an unused hole in the dom0 RAM space?
> ---
> xen/arch/arm/platforms/vexpress.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/xen/arch/arm/platforms/vexpress.c b/xen/arch/arm/platforms/vexpress.c
> index 8e6a4ea..ce66935 100644
> --- a/xen/arch/arm/platforms/vexpress.c
> +++ b/xen/arch/arm/platforms/vexpress.c
> @@ -176,6 +176,8 @@ PLATFORM_START(vexpress, "VERSATILE EXPRESS")
> #endif
> .reset = vexpress_reset,
> .blacklist_dev = vexpress_blacklist_dev,
> + .dom0_gnttab_start = 0x10000000,
> + .dom0_gnttab_size = 0x20000,
> PLATFORM_END
>
> /*
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH] xen: arm: configure correct dom0_gnttab_start/size
2014-11-04 10:17 ` Ian Campbell
@ 2014-11-04 10:20 ` Stefano Stabellini
2014-11-04 12:48 ` Julien Grall
0 siblings, 1 reply; 15+ messages in thread
From: Stefano Stabellini @ 2014-11-04 10:20 UTC (permalink / raw)
To: Ian Campbell; +Cc: julien.grall, tim, stefano.stabellini, xen-devel
On Tue, 4 Nov 2014, Ian Campbell wrote:
> On Thu, 2014-09-11 at 16:21 +0100, Ian Campbell wrote:
>
> I think we should apply this workaround for 4.5 and do things properly
> for 4.6. Any thoughts?
I agree with you
> > Vexpress is currently failing to boot for me with:
> > ------------[ cut here ]------------
> > WARNING: CPU: 0 PID: 1 at arch/arm/mm/ioremap.c:301 __arm_ioremap_pfn_caller+0x118/0x1a4()
> > CPU: 0 PID: 1 Comm: swapper Tainted: G W 3.16.0-arm-native+ #276
> > [<c0011e9c>] (unwind_backtrace) from [<c0010758>] (show_stack+0x10/0x14)
> > [<c0010758>] (show_stack) from [<c001a3ec>] (warn_slowpath_common+0x5c/0x7c)
> > [<c001a3ec>] (warn_slowpath_common) from [<c001a4c8>] (warn_slowpath_null+0x18/0x20)
> > [<c001a4c8>] (warn_slowpath_null) from [<c001488c>] (__arm_ioremap_pfn_caller+0x118/0x1a4)
> > [<c001488c>] (__arm_ioremap_pfn_caller) from [<c00149a0>] (__arm_ioremap+0x14/0x20)
> > [<c00149a0>] (__arm_ioremap) from [<c01d103c>] (gnttab_setup_auto_xlat_frames+0x30/0xdc)
> > [<c01d103c>] (gnttab_setup_auto_xlat_frames) from [<c0495324>] (xen_guest_init+0x19c/0x2d4)
> > [<c0495324>] (xen_guest_init) from [<c0492c6c>] (do_one_initcall+0xfc/0x1a4)
> > [<c0492c6c>] (do_one_initcall) from [<c0492d6c>] (kernel_init_freeable+0x58/0x1b4)
> > [<c0492d6c>] (kernel_init_freeable) from [<c039611c>] (kernel_init+0x8/0xe4)
> > [<c039611c>] (kernel_init) from [<c000de58>] (ret_from_fork+0x14/0x3c)
> > ---[ end trace 3406ff24bd97382f ]---
> > xen:grant_table: Failed to ioremap gnttab share frames (addr=0x00000000b0000000)!
> >
> > which is:
> > /*
> > * Don't allow RAM to be mapped - this causes problems with ARMv6+
> > */
> > if (WARN_ON(pfn_valid(pfn)))
> > return NULL;
> >
> > This makes sense since the gnttab defaults to 0xb000000 and my dom0
> > is being allocated a 1:1 mapping at 0xa0000000-0xc0000000.
> >
> > I suspect this broke around the time we stopped forcing dom0 memory to be
> > allocated as low as possible which happened to prevent the default dom0_gnttab
> > region overlapping RAM.
> >
> > This patch specifies an explicit dom0_gnttab base which is explicitly unused
> > according to the FVP model docs (although it correpsonds to CS5 this isn't
> > wired up to anything).
> >
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> > This just fixes vexpress, I wonder if a followup patch should either remove the
> > default dom0_gnttab (forcing all platforms to specify one explicitly) or make
> > the default something less arbitrary than 0xb0000000, e.g. 0x0-0x20000 or
> > 0xfffe0000-0x100000000 (very start or very end of RAM). Perhaps with a command
> > line option to override for new platform hacking.
> >
> > Or maybe we should search for an unused hole in the dom0 RAM space?
> > ---
> > xen/arch/arm/platforms/vexpress.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/xen/arch/arm/platforms/vexpress.c b/xen/arch/arm/platforms/vexpress.c
> > index 8e6a4ea..ce66935 100644
> > --- a/xen/arch/arm/platforms/vexpress.c
> > +++ b/xen/arch/arm/platforms/vexpress.c
> > @@ -176,6 +176,8 @@ PLATFORM_START(vexpress, "VERSATILE EXPRESS")
> > #endif
> > .reset = vexpress_reset,
> > .blacklist_dev = vexpress_blacklist_dev,
> > + .dom0_gnttab_start = 0x10000000,
> > + .dom0_gnttab_size = 0x20000,
> > PLATFORM_END
> >
> > /*
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] xen: arm: configure correct dom0_gnttab_start/size
2014-11-04 10:20 ` Stefano Stabellini
@ 2014-11-04 12:48 ` Julien Grall
2014-11-04 17:20 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 15+ messages in thread
From: Julien Grall @ 2014-11-04 12:48 UTC (permalink / raw)
To: Stefano Stabellini, Ian Campbell; +Cc: tim, xen-devel
On 11/04/2014 10:20 AM, Stefano Stabellini wrote:
> On Tue, 4 Nov 2014, Ian Campbell wrote:
>> On Thu, 2014-09-11 at 16:21 +0100, Ian Campbell wrote:
>>
>> I think we should apply this workaround for 4.5 and do things properly
>> for 4.6. Any thoughts?
>
> I agree with you
+1
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] xen: arm: configure correct dom0_gnttab_start/size
2014-11-04 12:48 ` Julien Grall
@ 2014-11-04 17:20 ` Konrad Rzeszutek Wilk
2014-11-05 10:59 ` Ian Campbell
0 siblings, 1 reply; 15+ messages in thread
From: Konrad Rzeszutek Wilk @ 2014-11-04 17:20 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, tim, Ian Campbell, Stefano Stabellini
On Tue, Nov 04, 2014 at 12:48:15PM +0000, Julien Grall wrote:
> On 11/04/2014 10:20 AM, Stefano Stabellini wrote:
> > On Tue, 4 Nov 2014, Ian Campbell wrote:
> >> On Thu, 2014-09-11 at 16:21 +0100, Ian Campbell wrote:
> >>
> >> I think we should apply this workaround for 4.5 and do things properly
> >> for 4.6. Any thoughts?
> >
> > I agree with you
>
> +1
/me unrolls the first-bandaid and puts it on Xen and signs it with:
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
> Regards,
>
> --
> Julien Grall
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] xen: arm: configure correct dom0_gnttab_start/size
2014-11-04 17:20 ` Konrad Rzeszutek Wilk
@ 2014-11-05 10:59 ` Ian Campbell
0 siblings, 0 replies; 15+ messages in thread
From: Ian Campbell @ 2014-11-05 10:59 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: tim, Julien Grall, xen-devel, Stefano Stabellini
On Tue, 2014-11-04 at 12:20 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 04, 2014 at 12:48:15PM +0000, Julien Grall wrote:
> > On 11/04/2014 10:20 AM, Stefano Stabellini wrote:
> > > On Tue, 4 Nov 2014, Ian Campbell wrote:
> > >> On Thu, 2014-09-11 at 16:21 +0100, Ian Campbell wrote:
> > >>
> > >> I think we should apply this workaround for 4.5 and do things properly
> > >> for 4.6. Any thoughts?
> > >
> > > I agree with you
> >
> > +1
>
>
> /me unrolls the first-bandaid and puts it on Xen and signs it with:
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thanks, applied!
Ian.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] xen: arm: configure correct dom0_gnttab_start/size
2014-09-11 15:21 [PATCH] xen: arm: configure correct dom0_gnttab_start/size Ian Campbell
` (3 preceding siblings ...)
2014-11-04 10:17 ` Ian Campbell
@ 2014-11-04 12:46 ` Julien Grall
4 siblings, 0 replies; 15+ messages in thread
From: Julien Grall @ 2014-11-04 12:46 UTC (permalink / raw)
To: Ian Campbell, xen-devel; +Cc: tim, stefano.stabellini
On 09/11/2014 04:21 PM, Ian Campbell wrote:
> Vexpress is currently failing to boot for me with:
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at arch/arm/mm/ioremap.c:301 __arm_ioremap_pfn_caller+0x118/0x1a4()
> CPU: 0 PID: 1 Comm: swapper Tainted: G W 3.16.0-arm-native+ #276
> [<c0011e9c>] (unwind_backtrace) from [<c0010758>] (show_stack+0x10/0x14)
> [<c0010758>] (show_stack) from [<c001a3ec>] (warn_slowpath_common+0x5c/0x7c)
> [<c001a3ec>] (warn_slowpath_common) from [<c001a4c8>] (warn_slowpath_null+0x18/0x20)
> [<c001a4c8>] (warn_slowpath_null) from [<c001488c>] (__arm_ioremap_pfn_caller+0x118/0x1a4)
> [<c001488c>] (__arm_ioremap_pfn_caller) from [<c00149a0>] (__arm_ioremap+0x14/0x20)
> [<c00149a0>] (__arm_ioremap) from [<c01d103c>] (gnttab_setup_auto_xlat_frames+0x30/0xdc)
> [<c01d103c>] (gnttab_setup_auto_xlat_frames) from [<c0495324>] (xen_guest_init+0x19c/0x2d4)
> [<c0495324>] (xen_guest_init) from [<c0492c6c>] (do_one_initcall+0xfc/0x1a4)
> [<c0492c6c>] (do_one_initcall) from [<c0492d6c>] (kernel_init_freeable+0x58/0x1b4)
> [<c0492d6c>] (kernel_init_freeable) from [<c039611c>] (kernel_init+0x8/0xe4)
> [<c039611c>] (kernel_init) from [<c000de58>] (ret_from_fork+0x14/0x3c)
> ---[ end trace 3406ff24bd97382f ]---
> xen:grant_table: Failed to ioremap gnttab share frames (addr=0x00000000b0000000)!
>
> which is:
> /*
> * Don't allow RAM to be mapped - this causes problems with ARMv6+
> */
> if (WARN_ON(pfn_valid(pfn)))
> return NULL;
>
> This makes sense since the gnttab defaults to 0xb000000 and my dom0
> is being allocated a 1:1 mapping at 0xa0000000-0xc0000000.
>
> I suspect this broke around the time we stopped forcing dom0 memory to be
> allocated as low as possible which happened to prevent the default dom0_gnttab
> region overlapping RAM.
>
> This patch specifies an explicit dom0_gnttab base which is explicitly unused
> according to the FVP model docs (although it correpsonds to CS5 this isn't
NIT: corresponds
> wired up to anything).
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 15+ messages in thread