linux-kernel - Re: [PATCH 07/14] KVM: Don't block+unblock when halt-polling is successful

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <877df3btgb.wl-maz@kernel.org>
Date:   Sun, 26 Sep 2021 10:02:28 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Sean Christopherson <seanjc@...gle.com>,
        Huacai Chen <chenhuacai@...nel.org>,
        Aleksandar Markovic <aleksandar.qemu.devel@...il.com>,
        Paul Mackerras <paulus@...abs.org>,
        Christian Borntraeger <borntraeger@...ibm.com>,
        Janosch Frank <frankja@...ux.ibm.com>,
        James Morse <james.morse@....com>,
        Alexandru Elisei <alexandru.elisei@....com>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        David Hildenbrand <david@...hat.com>,
        Cornelia Huck <cohuck@...hat.com>,
        Claudio Imbrenda <imbrenda@...ux.ibm.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>,
        linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.cs.columbia.edu,
        linux-mips@...r.kernel.org, kvm@...r.kernel.org,
        kvm-ppc@...r.kernel.org, linux-kernel@...r.kernel.org,
        David Matlack <dmatlack@...gle.com>,
        Jing Zhang <jingzhangos@...gle.com>
Subject: Re: [PATCH 07/14] KVM: Don't block+unblock when halt-polling is successful

On Sun, 26 Sep 2021 07:27:28 +0100,
Paolo Bonzini <pbonzini@...hat.com> wrote:
> 
> On 25/09/21 11:50, Marc Zyngier wrote:
> >> there is no need for arm64 to put/load
> >> the vGIC as KVM hasn't relinquished control of the vCPU in any way.
> > 
> > This doesn't mean that there is no requirement for any state
> > change. The put/load on GICv4 is crucial for performance, and the VMCR
> > resync is a correctness requirement.
> 
> I wouldn't even say it's crucial for performance: halt polling cannot
> work and is a waste of time without (the current implementation of)
> put/load.

Not quite. A non-V{LPI,SGI} could still be used as the a wake-up from
WFI (which is the only reason we end-up on this path). Only LPIs (and
SGIs on GICv4.1) can be directly injected, meaning that SPIs and PPIs
still follow the standard SW injection model.

However, there is still the ICH_VMCR_EL2 requirement (to get the
up-to-date priority mask and group enable bits) for SW-injected
interrupt wake-up to work correctly, and I really don't want to save
that one eagerly on each shallow exit.

> However, is activating the doorbell necessary?  If possible, polling
> the VGIC directly for pending VLPIs without touching the ITS (for
> example by emulating IAR reads) may make sense.  IIUC that must be
> done at EL2 though, so maybe it would even make sense to move all of
> halt polling to EL2 for the nVHE case.  It all depends on benchmark
> results, of course.

No, there is no architectural way to observe the VLPI state. EL2
cannot impersonate the guest an read ICV_IAR1_EL1 (because it
conveniently has the same encoding as ICC_IAR1_EL1), and if it could,
it would be *destructive* (not what you want). The equivalent of the
LR that is used to hold the highest priority VLPI presented to the
virtual CPU interface is not visible to SW at all.

There are exactly two ways for the hypervisor to get a hint about the
VLPI state (and that's only a hint, as everything can be spurious):

- Make the vPE non resident and use GICR_VPENDBASER.PendingLast bit to
  find out whether there are pending VLPIs

- Make the vPE non resident and get a doorbell interrupt

See the common pattern?

There is no polling mechanism, and the only way to flush the VLPI
state to memory is to destroy the GIC view of the vPE, which is a bit
counter-productive. It also only work on GICv4.1, and not GICv4 (which
is why we don't support live migration on GICv4).

> Sorry for the many stupid questions I'm asking lately, but I'm trying
> to pay more attention to ARM and understand the VGIC and EL1/EL2 split
> better.

Feel free to ask any question. The more people understand how the
architecture works, the better.

	M.

-- 
Without deviation from the norm, progress is not possible.