lkml.org 
[lkml]   [2018]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v12 04/11] kvm/x86: remove kvm memblock dependency
    On Fri, 6 Jul 2018, Paolo Bonzini wrote:
    > On 06/07/2018 11:24, Thomas Gleixner wrote:
    > >> The reason for this is to avoid wasting a lot of BSS memory when KVM is
    > >> not in use. Thomas is going to send his take on this!
    > > Got it working with per cpu variables, but there is a different subtle
    > > issue with that.
    > >
    > > The pvclock data is mapped into the VDSO as well, i.e. as a full page.
    > >
    > > Right now with the linear array, which is forced to be page sized at least
    > > this only maps pvclock data or zeroed data (after the last CPU) into the
    > > VDSO.
    > >
    > > With PER CPU variables this would map arbitraty other per cpu data which
    > > happens to be in the same page into the VDSO. Not really what we want.
    > >
    > > That means to utilize PER CPU data this requires to allocate page sized
    > > pvclock data space for each CPU to prevent leaking arbitrary stuff.
    > >
    > > As this data is allocated on demand, i.e. only if kvmclock is used, this
    > > might be tolerable, but I'm not so sure.
    >
    > One possibility is to introduce another layer of indirection: in
    > addition to the percpu pvclock data, add a percpu pointer to the pvclock
    > data and initialize it to point to a page-aligned variable in BSS. CPU0
    > (used by vDSO) doesn't touch the pointer and keeps using the BSS
    > variable, APs instead redirect the pointer to the percpu data.

    Yeah, thought about that, but the extra indirection is ugly. Instead of
    using per cpu data, I just can allocate the memory _after_ the allocators
    are up and running and use a single page sized static __initdata for the
    early boot.

    Thanks,

    tglx

    \
     
     \ /
      Last update: 2018-07-06 11:46    [W:2.569 / U:0.076 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site