On Thu, Mar 23, 2023, Sean Christopherson wrote: > On Wed, Mar 01, 2023, Aaron Lewis wrote: > > Add a local version of vsprintf() for the guest to use. > > > > The file printf.c was lifted from arch/x86/boot/printf.c. > > Is there by any shance a version of > > +/* > > + * Oh, it's a waste of space, but oh-so-yummy for debugging. This > > + * version of printf() does not include 64-bit support. "Live with > > But selftests are 64-bit only, at least on x86. > I think that's a legacy comment. AFAICT this code supports 64-bit values. I'll remove the comment to avoid confusion. > > +static char *number(char *str, long num, int base, int size, int precision, > > + int type) > > Do we actually need a custom number()? I.e. can we sub in a libc equivalent? > That would reduce the craziness of this file by more than a few degrees. > Yeah, I think we need it. One of the biggest problems I'm trying to avoid here is the use of LIBC in a guest. Using it always seems to end poorly because guests generally don't set up AVX-512 or a TLS segmet, nor should they have to. Calling into LIBC seems to require both of them too often, so it seems like it's better to just avoid it. Also, in working on v2 I upgraded vsprintf() to vsnprintf() which required custom changes to number().
