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

Re: [Xen-devel] [PATCH v2 13/20] livepatch: Initial ARM64 support.



On Wed, Sep 07, 2016 at 11:43:27AM +0100, Julien Grall wrote:
> 
> 
> On 07/09/2016 04:33, Konrad Rzeszutek Wilk wrote:
> > > ...snip..
> > > > > +        case R_AARCH64_ABS32:
> > > > > +            ovf = reloc_data(RELOC_OP_ABS, dest, val, 32);
> > > > > +            break;
> > > > 
> > > > I have noticed that not all the relocations are implemented (e.g
> > > > R_AARCH64_ABS16, R_AARCH64_MOVW_*...). I don't think there is anything
> > > > preventing the compiler to use them. So is there any particular reasons 
> > > > to
> > > > not include them?
> > > 
> > > I followed the same principle Ross did on x86 - only implement the ones 
> > > that
> > > the compiler has generated. And that is what I initially had in the v1, 
> > > but expanded
> > > it per request.
> > > 
> > > I can include more, but at what point should I stop?
> 
> Good question. My question was more, would it ever be possible to be
> generated by the same compiler when applying a patch?

If the hypervisor did not have them, then the payload will most likely not have
them either.

And vice-versa - if hypervisor does have them, then the payload will most likely
have them.

Either way I think we are debating academics as I already added all that code 
in :-)
> 
> > 
> > 
> >  xen/arch/arm/arm64/livepatch.c       |  140 +++++++
> >  xen/include/xen/elfstructs.h         |   23 ++
> > 
> > lines later and I added them all in.
> > 
> 
> -- 
> Julien Grall

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

 


Rackspace

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