Re: [PATCH v11 2/2] Drivers: hv: Introduce mshv_vtl driver

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Nov 12, 2025 at 04:12:08AM +0000, Michael Kelley wrote:

> > @@ -96,3 +97,10 @@ SYM_FUNC_START(__mshv_vtl_return_call)
> >  	pop %rbp
> >  	RET
> >  SYM_FUNC_END(__mshv_vtl_return_call)
> > +
> > +	.section	.discard.addressable,"aw"
> > +	.align 8
> > +	.type 	__UNIQUE_ID_addressable___SCK____mshv_vtl_return_hypercall_662.0, @object
> > +	.size 	__UNIQUE_ID_addressable___SCK____mshv_vtl_return_hypercall_662.0, 8
> > +__UNIQUE_ID_addressable___SCK____mshv_vtl_return_hypercall_662.0:
> > +	.quad	__SCK____mshv_vtl_return_hypercall
> 
> This is pretty yucky itself. 

Definitely doesn't win any prizes, for sure. 

> Why is it better than calling out to a C function?

It keeps all the code in one place is a strong argument.

> Is it because in spite of the annotations, there's no guarantee the C
> compiler won't generate some code that messes up a register value? Or is
> there some other reason?

There is that too, a frame pointer build would be in its right to add a
stack frame (although they typically won't in this case). And the C ABI
doesn't provide the guarantees your need, so calling out into C is very
much you get to keep the pieces.

> Does the magic "_662.0" have any significance?  Or is it just some
> uniqueness salt on the symbol name?

Like Paolo already said, that's just the crazy generated by our
__ADRESSABLE() macro, this name is mostly irrelevant, all we really need
is a reference to that __SCK____mshv_vtl_return_hypercall symbol so it
ends up in the symbol table. (And the final link will then complain if
the symbol doesn't end up being resolved)

Keeping the name somewhat in line with __ADDRESSABLE() has the advantage
that you can clearly see where it comes from, but yeah, we can strip of
the number if you like.