linux-kernel - RE: [PATCH v11 2/2] Drivers: hv: Introduce mshv

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <SN6PR02MB4157F3F565621B32AC29EC92D4CCA@SN6PR02MB4157.namprd02.prod.outlook.com>
Date: Wed, 12 Nov 2025 09:44:20 +0000
From: Michael Kelley <mhklinux@...look.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: Naman Jain <namjain@...ux.microsoft.com>, Paolo Bonzini
	<pbonzini@...hat.com>, Sean Christopherson <seanjc@...gle.com>, "K . Y .
 Srinivasan" <kys@...rosoft.com>, Haiyang Zhang <haiyangz@...rosoft.com>, Wei
 Liu <wei.liu@...nel.org>, Dexuan Cui <decui@...rosoft.com>, Thomas Gleixner
	<tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov
	<bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, "H . Peter Anvin"
	<hpa@...or.com>, "linux-hyperv@...r.kernel.org"
	<linux-hyperv@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "x86@...nel.org" <x86@...nel.org>, Mukesh
 Rathor <mrathor@...ux.microsoft.com>, Stanislav Kinsburskii
	<skinsburskii@...ux.microsoft.com>, Nuno Das Neves
	<nunodasneves@...ux.microsoft.com>, Christoph Hellwig <hch@...radead.org>,
	Saurabh Sengar <ssengar@...ux.microsoft.com>, ALOK TIWARI
	<alok.a.tiwari@...cle.com>
Subject: RE: [PATCH v11 2/2] Drivers: hv: Introduce mshv_vtl driver

From: Peter Zijlstra <peterz@...radead.org> Sent: Wednesday, November 12, 2025 1:37 AM
> 
> 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.

Thanks. If that symbol is referenced only by these few lines, I'd
go with something even shorter and simpler. Perhaps:

.section		.discard.addressable,"aw"
.align 8
.type	vtl_return_sym, @object
.size	vtl_return_sym, 8
vtl_return_sym:
.quad	__SCK____mshv_vtl_return_hypercall

Regardless of the choice of symbol name, add a comment about
mimicking __ADDRESSABLE(). That feels less messy to me, but
it's Naman's call.

Michael