[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2/3] xen/arm: Use p2m_restore_state in construct_dom0



On 03/21/2014 04:50 PM, Ian Campbell wrote:
> On Wed, 2014-03-19 at 15:43 +0000, Julien Grall wrote:
>> The address translation functions used while building dom0 rely on certain 
>> EL1
>> state being configured. In particular they are subject to the behaviour of
>> SCTLR_EL1.M (stage 1 MMU enabled).
>>
>> The Xen (and Linux) boot protocol require that the kernel be entered with the
>> MMU disabled but they don't say anything explicitly about exception levels
>> other than the one which is active when entering the kernels. Arguably the
>> protocol could be said to apply to all exception levels but in any case we
>> should cope with this and setup the EL1 state as necessary.
>>
>> Fu Wei discovered this when booting Xen from grub.efi over UEFI, it's not
>> clear whether grub or UEFI is responsible for leaving stage 1 MMU enabled.
>>
>> Use directly the newly created function p2m_restore_state to retrieve a
>> correct EL1 state to translate an address.
>>
>> Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
>> Reported-by: Fu Wei <fu.wei@xxxxxxxxxx>
> 
> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> 
> I think this will leave some initial dom0 vcpu state in the idle vcpu
> (my patch had the same issue), but I think that is tolerable. It might
> just be worth clearing HCR_VM and perhaps VTTBR (more worried about the
> VMID than the base address) when scheduling an idle vcpu.

I think it's already the case when idle VPCU are scheduled. We don't
change the VTTBR so it keeps the one used by the previous running VCPU.

-- 
Julien Grall

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.