[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v3 02/22] include/xen/slr-table.h: Secure Launch Resource Table definitions
On Wed, Jul 02, 2025 at 04:36:27PM +0200, Jan Beulich wrote: > On 30.05.2025 15:17, Sergii Dmytruk wrote: > > The file provides constants, structures and several helper functions for > > parsing SLRT. > > > > The data described by the structures is passed to Xen by a bootloader > > which initiated DRTM. > > > > Signed-off-by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx> > > Signed-off-by: Ross Philipson <ross.philipson@xxxxxxxxxx> > > Signed-off-by: Sergii Dmytruk <sergii.dmytruk@xxxxxxxxx> > > --- > > xen/include/xen/slr-table.h | 276 ++++++++++++++++++++++++++++++++++++ > > 1 file changed, 276 insertions(+) > > create mode 100644 xen/include/xen/slr-table.h > > Btw, please don't forget to Cc maintainers of code you're changing / adding. What do you mean? I'm running add_maintainers.pl on the patches. > > +/* > > + * Prototype of a function pointed to by slr_entry_dl_info::dl_handler. > > + */ > > +typedef void (*dl_handler_func)(struct slr_bl_context *bl_context); > > I keep wondering why this ... > > > +/* > > + * DRTM Dynamic Launch Configuration > > + */ > > +struct slr_entry_dl_info > > +{ > > + struct slr_entry_hdr hdr; > > + uint64_t dce_size; > > + uint64_t dce_base; > > + uint64_t dlme_size; > > + uint64_t dlme_base; > > + uint64_t dlme_entry; > > + struct slr_bl_context bl_context; > > + uint64_t dl_handler; > > ... 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. > > +} __packed; > > I similarly keep wondering why there are all these packed attributes here, > when > (afaics) all of the structures are defined in a way that any padding is > explicit > anyway. As before: it won't hurt, it's future-proof, just in case and to let reader of the code know the structure must have no padding. If you want them gone, I can do that, but I think it will make the code harder to maintain. > > +static inline const struct slr_entry_hdr * > > +slr_next_entry(const struct slr_table *table, const struct slr_entry_hdr > > *curr) > > +{ > > + const struct slr_entry_hdr *next = (void *)curr + curr->size; > > + > > + if ( (void *)next + sizeof(*next) > slr_end_of_entries(table) ) > > + return NULL; > > + if ( next->tag == SLR_ENTRY_END ) > > + return NULL; > > + if ( (void *)next + next->size > slr_end_of_entries(table) ) > > + return NULL; > > + > > + return next; > > +} > > + > > +static inline const struct slr_entry_hdr * > > +slr_next_entry_by_tag(const struct slr_table *table, > > + const struct slr_entry_hdr *entry, > > + uint16_t tag) > > +{ > > + if ( !entry ) /* Start from the beginning */ > > + entry = (void *)table + sizeof(*table); > > + > > + for ( ; ; ) > > + { > > + if ( entry->tag == tag ) > > + return entry; > > + > > + entry = slr_next_entry(table, entry); > > + if ( !entry ) > > + return NULL; > > + } > > + > > + return NULL; > > +} > > For both of the functions, again: Please don't cast away const-ness. > > Jan You had commented on v2 after v3 was already sent. Regards
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |