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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ