[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52117b6e-cbdc-8583-494b-5e8e5d6d4265@redhat.com>
Date: Fri, 6 Jul 2018 11:36:59 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Pavel Tatashin <pasha.tatashin@...cle.com>,
steven.sistare@...cle.com, daniel.m.jordan@...cle.com,
linux@...linux.org.uk, schwidefsky@...ibm.com,
heiko.carstens@...ibm.com, john.stultz@...aro.org,
sboyd@...eaurora.org, x86@...nel.org, linux-kernel@...r.kernel.org,
mingo@...hat.com, hpa@...or.com, douly.fnst@...fujitsu.com,
peterz@...radead.org, prarit@...hat.com, feng.tang@...el.com,
pmladek@...e.com, gnomes@...rguk.ukuu.org.uk,
linux-s390@...r.kernel.org
Subject: Re: [PATCH v12 04/11] kvm/x86: remove kvm memblock dependency
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.
Paolo
Powered by blists - more mailing lists