linux-kernel - [PATCH 0/5] KVM: rename and extend vcpu->requests API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20170216160449.13094-1-rkrcmar@redhat.com>
Date:   Thu, 16 Feb 2017 17:04:44 +0100
From:   Radim Krčmář <rkrcmar@...hat.com>
To:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Andrew Jones <drjones@...hat.com>,
        Marc Zyngier <marc.zyngier@....com>,
        Christian Borntraeger <borntraeger@...ibm.com>,
        Cornelia Huck <cornelia.huck@...ibm.com>,
        James Hogan <james.hogan@...tec.com>,
        Paul Mackerras <paulus@...abs.org>,
        Christoffer Dall <christoffer.dall@...aro.org>
Subject: [PATCH 0/5] KVM: rename and extend vcpu->requests API

KVM requests are not used with one API, but are a mix of open-coded
setting and kicking, which is what this series aims to normalize.

The main problem is described in comment of patch 1:
There are three main kinds of requests
 1) requests from a VCPU to itself,
 2) requests for a remote VCPU,
 3) and requests for a remote VCPU that also expose some data

and we have just one function for setting requests.

The first type of requests leads to just set_bit.  The other two need to
notify the remote VCPU -- often with kvm_vcpu_kick, but if the VCPU is
known to be halted, it can be just swait_activate().  And the third one
needs a memory barrier before setting the bit and after testing it.

The kvm_make_request function we have now is suboptimal in all of these
three cases -- it starts with a barrier, but then doesn't kick, so we
cannot use it for (1) or (2) due to performance issues and we need to
explicitly kick afterwards in (3).

Putting all these into one function would require runtime overhead as it
is not easy to tell if the request is local or remote, but the need for
a barrier can be decided at compile time.

The result of this series is still a mess as it does not include
kvm_vcpu_kick() into kvm_set_request(), but I hope to get an early
feedback about the idea.

(Series based on current kvm/queue.)

Radim Krčmář (5):
  KVM: change API for requests to match bit operations
  KVM: add KVM request variants without barrier
  KVM: optimize kvm_make_all_cpus_request
  KVM: add __kvm_request_needs_mb
  KVM: add kvm_request_pending

 arch/mips/kvm/emulate.c           |   4 +-
 arch/mips/kvm/trap_emul.c         |   4 +-
 arch/powerpc/kvm/book3s_pr.c      |   4 +-
 arch/powerpc/kvm/book3s_pr_papr.c |   2 +-
 arch/powerpc/kvm/booke.c          |  22 +++---
 arch/powerpc/kvm/powerpc.c        |   8 +--
 arch/s390/kvm/kvm-s390.c          |  26 +++----
 arch/s390/kvm/kvm-s390.h          |   4 +-
 arch/s390/kvm/priv.c              |   4 +-
 arch/x86/kvm/hyperv.c             |  14 ++--
 arch/x86/kvm/i8259.c              |   2 +-
 arch/x86/kvm/lapic.c              |  22 +++---
 arch/x86/kvm/mmu.c                |  14 ++--
 arch/x86/kvm/pmu.c                |   6 +-
 arch/x86/kvm/svm.c                |  12 ++--
 arch/x86/kvm/vmx.c                |  32 ++++-----
 arch/x86/kvm/x86.c                | 144 +++++++++++++++++++-------------------
 include/linux/kvm_host.h          |  96 +++++++++++++++++++++----
 virt/kvm/kvm_main.c               |   9 ++-
 19 files changed, 253 insertions(+), 176 deletions(-)

-- 
2.11.1