Messages in this thread | | | Date | Thu, 21 Jul 2022 21:16:10 +0000 | From | Sean Christopherson <> | Subject | Re: [RFC V2 PATCH 2/8] selftests: kvm: Add a basic selftest to test private memory |
| |
On Thu, Jul 21, 2022, Vishal Annapurve wrote: > On Wed, Jul 20, 2022 at 4:03 PM Sean Christopherson <seanjc@google.com> 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.
| |