On Fri, May 22, 2026, Yosry Ahmed wrote:
> > +static void __attribute__((used)) common(void)
> > +{
> > + OFFSET(TD_BOOT_PARAMETERS_CR0, td_boot_parameters, cr0);
> > + OFFSET(TD_BOOT_PARAMETERS_CR3, td_boot_parameters, cr3);
> > + OFFSET(TD_BOOT_PARAMETERS_CR4, td_boot_parameters, cr4);
> > + OFFSET(TD_BOOT_PARAMETERS_GDT, td_boot_parameters, gdtr);
> > + OFFSET(TD_BOOT_PARAMETERS_IDT, td_boot_parameters, idtr);
> > + OFFSET(TD_BOOT_PARAMETERS_PER_VCPU, td_boot_parameters, per_vcpu);
> > + OFFSET(TD_PER_VCPU_PARAMETERS_ESP_GVA, td_per_vcpu_parameters,
> > esp_gva);
> > + OFFSET(TD_PER_VCPU_PARAMETERS_GUEST_CODE, td_per_vcpu_parameters,
> > + guest_code);
> > + DEFINE(SIZEOF_TD_PER_VCPU_PARAMETERS,
> > + sizeof(struct td_per_vcpu_parameters));
> > +}
>
> This is neat.
>
> 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.
