lkml.org 
[lkml]   [2022]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.

\
 
 \ /
  Last update: 2022-07-21 23:18    [W:0.050 / U:1.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site