|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC 5/9] xen: arm: Defer setting of VTCR_EL2 until after CPUs are up
On Wed, 2014-07-30 at 18:11 +0100, Julien Grall wrote:
> > +{
> > + unsigned long val = (unsigned long)data;
>
> VTCR_EL2 is a 32 bit register. I would use uint32_t for the variable type.
The problem with that is:
p2m.c: In function âsetup_virt_paging_oneâ:
p2m.c:1117:20: error: cast from pointer to integer of different size
[-Werror=pointer-to-int-cast]
uint32_t val = (uint32_t)data;
p2m.c: In function âsetup_virt_pagingâ:
p2m.c:1139:27: error: cast to pointer from integer of different size
[-Werror=int-to-pointer-cast]
setup_virt_paging_one((void *)val);
The fix for that is to sprinkle additional casts to (uintptr_t) before
all the (uint32_t) and (void*) casts, which IMHO is worse than passing
an unsigned long to WRITE_SYSREG32, which is mostly harmless I think.
> > @@ -838,6 +836,8 @@ void __init start_xen(unsigned long boot_phys_offset,
> >
> > do_initcalls();
> >
> > + setup_virt_paging();
> > +
>
> Assuming there is no CPU hotplug, which IIRC is not yet support, this is
> only depends on the SMP bring up. Can we move this before do_initcalls?
> So if we need to initialize some code that is relying on VTCR_EL2, it
> will be possible.
This seems to work. I'm not really sure what we would do about CPU
hotplug yet, especially of CPUs which would require a different choice
of VTCR_EL2 value. Cross that bridge when we get to it I think.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |