Re: [PATCH v3 02/22] include/xen/slr-table.h: Secure Launch Resource Table definitions

[Sergii Dmytruk <sergii.dmytruk@xxxxxxxxx>]

On Mon, Jul 14, 2025 at 09:33:09AM +0200, Jan Beulich wrote:
> On 13.07.2025 19:29, Sergii Dmytruk wrote:
> > On Tue, Jul 08, 2025 at 08:52:36AM +0200, Jan Beulich wrote:
> >> On 07.07.2025 19:31, Sergii Dmytruk wrote:
> >>> On Mon, Jul 07, 2025 at 10:29:46AM +0200, Jan Beulich wrote:
> >>>>>> ... then isn't used right here, instead requiring a cast somewhere 
> >>>>>> (presumably,
> >>>>>> as code using this isn't visible in this patch).
> >>>>>
> >>>>> As was mentioned earlier: because size of a pointer between Xen and a
> >>>>> bootloader doesn't necessarily match.  What you're proposing can break
> >>>>> under certain conditions.
> >>>>
> >>>> But the header isn't shared with a bootloader's code base. It's private 
> >>>> to
> >>>> Xen.
> >>>
> >>> Yes, but sources of Xen be compiled with different size of a pointer
> >>> which messes up the interpretation of the data.  I tried using
> >>> BUILD_BUG_ON() to enforce the pointer is 64-bit and early code stopped
> >>> compiling.  The structures must not vary like that.
> >>
> >> Hmm. Does early code actually need to have this struct exposed to it?
> >
> > It doesn't use this particular structure, but it uses some other ones in
> > the header (also SLRT entries, but of different types).  Making a
> > separate header just to get rid of a cast doesn't seem to be worth it.
>
> Which I also didn't suggest. Didn't I see an EARLY_<something> #define-d
> somewhere? Couldn't you key exposure of the structure to that not being
> defined?
>
> Jan

That's possible, but it seems rather adhoc to conditionally provide a
declaration which would also make normal and early sources differ a bit
more.  __EARLY_SLAUNCH__ was added out of necessity, I wouldn't use it
for anything new unless there is no better option.

Regards