Re: [PATCH v6 1/3] xen/arm: add support for run_in_exception_handler()

[Julien Grall <julien@xxxxxxx>]

Hi Jan,

On 21/01/2021 10:06, Jan Beulich wrote:
> On 21.01.2021 10:50, Julien Grall wrote:
> > Hi Jan,
> >
> > On 21/01/2021 07:55, Jan Beulich wrote:
> > > On 20.01.2021 19:20, Julien Grall wrote:
> > > > On 16/01/2021 10:33, Juergen Gross wrote:
> > > > > Add support to run a function in an exception handler for Arm. Do it
> > > > > as on x86 via a bug_frame, but pass the function pointer via a
> > > > > register (this needs to be done that way, because inline asm support
> > > > > for 32-bit Arm lacks the needed functionality to reference an
> > > > > arbitrary function via the bugframe).
> > > > I was going to commit the series, but then realized the commit message
> > > > and comment needs some tweaking because technically GCC is supporting
> > > > 'i' (I managed to get it working with -fno-pie).
> > > >
> > > > So how about:
> > > >
> > > > "This is needed to be done that way because GCC complains about invalid
> > > > constraint when using a function pointer with "i" and PIE is enabled
> > > > (default on most of GCC shipped with distro). Clang happily accepts it,
> > > > so it may be a bug in GCC."
> > > May I ask why you think it's a bug in gcc? I'd rather consider it
> > > a bug in clang. Taking the address of a symbol doesn't yield a
> > > constant in PIC or PIE code, aiui.
> > I consider it a bug because we were using it as:
> >
> > .pushsection .bug.frame
> > 2b:
> > .long (%0 - 2b)
> >
> > So I expect the compiler to be able to find the displacement in both
> > cases as we don't need to know the exact address.
> >
> > I think Clang is just clever enough to figure out we want a displacement.
> If they take apart the contents of the asm(), this may be possible,
> yes. (Did you try with -no-integrated-as, btw?).
Clang will be able to build the code with and without -no-integrated-as. 
The dump of the structure will show that the address of the function 
will be stored (I used this small snippet [1]).
[...]

> > Do you have a suggestion of constraint that could resolve the issue?
> No. Don't use -fpie (but I guess that's not an option for other
> reasons).
Yes, we need to have Xen code relocatable for at least UEFI. In the 
future we will need to be able to change at runtime the Xen virtual 
address in order to address memory issues (we can't switch page-tables 
with MMU enabled).
Linux Arm64 supports KASLR, yet, they are building with -fno-pie. I need 
to figure out how they deal with relocating the kernel and see if we can 
re-use it in Xen.
I have revised the comment to not suggest this is a bug and commit the 
series.
Cheers,

[1]

int test(void)
{
        return 0;
}

int main(void)
{
    asm volatile (".pushsection .bug_frames, \"aw\"\n"
              ".quad %0\n"
              ".popsection\n"
              :: "i"(test));

    return 0;
}



--
Julien Grall