[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 Fri, 2014-03-28 at 13:26 +0000, Julien Grall wrote:
> 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.

I expect you are correct.

I don't think we currently rely anywhere on a domain's VMID not being
present in a VTTBR if none of its VCPUs are scheduled or some other case
like that. I'm not sure how likely that scenario is. It's the sort of
thing which might come up if someone was trying to do clever TLB or
cache flush elision. Lets not worry about it now...

Ian.



_______________________________________________
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®.