Re: [Xen-devel] [PATCH] xen/arm: Register re-mapped Xen area as a temporary virtual region

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Tue, Mar 14, 2017 at 01:32:31PM +0000, Julien Grall wrote:
> Hi Konrad,
> 
> On 14/03/17 13:20, Konrad Rzeszutek Wilk wrote:
> > On Tue, Mar 14, 2017 at 05:27:17PM +0800, Wei Chen wrote:
> > > While we're doing apply_alternatives, we will generate new instructions
> > > if required. The new instructions need to update the Xen text section,
> > > but Xen text section is read-only. So we re-map Xen to a new virtual
> > > address to enable write access.
> > > 
> > > The targets of the new generated instructions are located in this
> > > re-mapped Xen area. But we haven't register this area as a virtual
> > > region, so the checking code determines the targets are not in the
> > > Xen text section, the new instructions could not be generated.
> > 
> > Could you expand on that please? Where is the checking code that determines
> > this? Are we talking about the traps handling and them scanning this
> > new region?
> > 
> > But you are saying 'new instructions'.. Hm, please enlighten!
> 
> He is talking about the check in branch_insn_requires_update. There is some

<lightbulb lights up>

> sanity checking about the branch offset. Because Xen text section is marked
> as read-only and we configure the hardware to not allow a region to be
> writable and executable at the same time, we need to re-map Xen in a
> temporary area. This means that the pc given in parameter of
> branch_insn_requires_update will point to a value in the re-mapped area. So
> the check is_active_kernel_text will always return false.

Yup.
> 
> Registering the virtual region temporarily will solve the problem.
> 
> Wei, it would be worth to explain that you hit the BUG(); in branch_insn_*
> and show an example in the commit message.

<nods>
> 
> Cheers,
> 
> -- 
> Julien Grall

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