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]

Date:   Fri, 30 Sep 2016 15:23:04 +0200
From:   Radim Krčmář <rkrcmar@...hat.com>
To:     Paolo Bonzini <pbonzini@...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

2016-09-29 17:41-0400, Paolo Bonzini:
>> 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.

True, thanks.

> (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).

Yeah, TMR is not used by the hardware ...