On Thu, Jul 21, 2022, Vishal Annapurve wrote: > On Wed, Jul 20, 2022 at 4:03 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > ... > > > + * which doesn't handle global offset table updates. Calling standard libc > > > + * functions would normally result in referring to the global offset table. > > > + * Adding O1 here seems to prohibit compiler from replacing the memory > > > + * operations with standard libc functions such as memset. > > > + */ > > > > Eww. We should either fix kvm_vm_elf_load() or override the problematic libc > > variants. Playing games with per-function attributes is not maintainable. > > > > I will try to spend more time on how kvm_vm_elf_load can be modified > to handle GOT fixups in different scenarios including > statically/dynamically linked sefltest binaries as I currently recall > limited information here. > > But modifying kvm_vm_elf_load to fixup GOT entries will be > insufficient as guest VM code (possibly whole selftest binary) will > need to be compiled with flags that allow memset/memcpy > implementations to work with specific guest VM configurations e.g. AVX > extension. Same concern is outlined in > https://elixir.bootlin.com/linux/latest/source/tools/testing/selftests/kvm/lib/x86_64/svm.c#L64. > > Would it be ok to maintain selftest binary compilation flags based on > guest VM configurations? No, we should instead define/implement versions of memset/memcpy that are guaranteed to be guest-friendly, either explicitly by selftests are implicitly by compiler builtins, e.g. see arch/x86/boot/string.h.
