Re: [RFC][PATCH] objtool,x86_64,paravirt: Add pv_ops[] support

[peterz]

On Mon, Aug 03, 2020 at 03:18:57PM +0000, Michael Kelley wrote:
> From: peterz@xxxxxxxxxxxxx Sent: Monday, August 3, 2020 7:33 AM

> > It requires call sites are the normal indirect call, and not mangled
> > retpoison (slow_down_io() had those), it also requires pv_ops[]
> > assignments are single instructions and not laundered through some
> > pointless intermediate helper (hyperv).

^^^

> > diff --git a/drivers/clocksource/hyperv_timer.c b/drivers/clocksource/hyperv_timer.c
> > index 09aa44cb8a91..bed769a84637 100644
> > --- a/drivers/clocksource/hyperv_timer.c
> > +++ b/drivers/clocksource/hyperv_timer.c
> > @@ -418,6 +418,13 @@ static struct clocksource hyperv_cs_msr = {
> >  	.flags	= CLOCK_SOURCE_IS_CONTINUOUS,
> >  };
> > 
> > +static __always_inline void hv_setup_sched_clock(void *sched_clock)
> > +{
> > +#ifdef CONFIG_PARAVIRT
> > +	pv_ops.time.sched_clock = sched_clock;
> > +#endif
> > +}
> > +
> 
> Moving this function to hyperv_timer.c is problematic because we
> want hyperv_timer.c to be architecture independent.  We're in the
> process of supporting Linux guests running on Hyper-V on ARM64, and
> there's a different implementation of hv_setup_sched_clock() on ARM64.

Then stick it in a header or something. The important part is that the
compiler generates:

4b737:       48 c7 05 00 00 00 00    movq   $0x0,0x0(%rip)        # 4b742 <hv_init_clocksource+0x4d>
4b73e:       00 00 00 00
		4b73a: R_X86_64_PC32    pv_ops
		4b73e: R_X86_64_32S     .text+0x827880

Where:

96378: 0000000000827880    32 FUNC    LOCAL  DEFAULT    4 read_hv_sched_clock_msr

Otherwise objtool cannot find the assignment and you get to keep the
pieces.