On Fri, May 22, 2026 at 04:50:07PM -0700, Yosry Ahmed wrote: > > > Sean, is this the preferred way to expose offsets to asm files (or asm > > > code blocks) -- as opposed to say using .equ [*]? > > > > For actual .S assembly, yes. For inline asm, maybe? If it looks prettier, > > go > > for it. > > > > > If yes, I can rework my nVMX GPR fixes to use the same approach for > > > register offsets. I wonder if the non-TDX part of this patch (i.e. > > > Makefile stuff) can be split, then patch 6 and the Makefile stuff can > > > land independently and allow development on top. > > > > > > I can also split them out and include them in the next version of my > > > series, then whichever series lands first will land the offsets > > > support. > > > > > > WDYT? > > > > Hmm, I'd say keep your series as-is for now. The OFFSET() infrastructure > > really > > shines for proper assembly. For what you're doing, AFAICT it's only > > marginally > > better. So I don't think it's worth juggling dependencies to use it right > > away, > > we can always convert if/when the TDX series lands the fancy stuff. > > Ack. We can do the switch later like you say.
I take this back. My series builds with the internal toolchain, but not when I just use make with LLVM. Probably different compiler versions or build options, but the fact the .equ thing doesn't always work means I can't use it. I would paste the error here, but the compiler literally spits out incomprehensible garbage. Lisa, if you will send a new version of this series for other reasons, do you mind splitting out the non-TDX parts of this patch? Ideally we'd have 1-2 patches that introduce the OFFSET() infrastructure without any TDX parts, which should make it easier to pick up separately or include with other series. If a new version won't be needed anyway, I will just wait for this to land before refreshing my series on top.
