linux-kernel - Re: [RFC PATCH 0/3] kvm: x86: speedups for APICv

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: <1865155490.553427.1475185306049.JavaMail.zimbra@redhat.com>
Date:   Thu, 29 Sep 2016 17:41:46 -0400 (EDT)
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Radim Krčmář <rkrcmar@...hat.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        yang zhang wz <yang.zhang.wz@...il.com>,
        feng wu <feng.wu@...el.com>, mst@...hat.com
Subject: Re: [RFC PATCH 0/3] kvm: x86: speedups for APICv


> Another possible optimization: when delivering an IPI, don't write the
> vector to PIR, but directly to VIRR.  If the guest is not in VMX
> non-root mode, then vm entry will take care of the injection; in the
> other case, we'll send POSTED_INTR_VECTOR.
> It seems that we don't even have to set PI.ON -- SDM doesn't say it is
> necessary to evaluate pending virtual interrupts after receiving the
> notification interrupt.  If we have to set PI.ON, we can just skip the
> PIR->VIRR sync as long as the VM doesn't have an assigned device,
> because we know that PIR is empty.

Nope, you cannot write to the APIC page while the VM is running.
(We're already reading the manual in such a way as to "allow" us to
write TMR while the VM is running, but that should not be extended.
For example the SDM doesn't say that the processor accesses VIRR with
atomic instructions, in fact it probably doesn't).

> And a more far-fetched one: if we know that PI.ON is set before vm
> entry, we could just send POSTED_INTR_VECTOR self-IPI after masking
> interrupts and let APICv copy PIR to IRR and deliver interrupts.
> There are two possible drawbacks: Is the self-IPI overhead too big?
> Would APICv IRR evaluation at vm entry take precedence, so we'd have big
> interrupt priority inversion window?

I don't think there is a risk of inverting interrupt priority, because
that race is always present.  But the overhead is probably too much, the
cost of the one xchg in __apic_update_irr is probably half of the whole
IRR update if the PI descriptor cacheline bounces.

Paolo