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
| ||
|
Date: Thu, 28 May 2020 13:04:55 +0200 From: Paolo Bonzini <pbonzini@...hat.com> To: Vitaly Kuznetsov <vkuznets@...hat.com>, kvm@...r.kernel.org, x86@...nel.org Cc: Andy Lutomirski <luto@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>, "H. Peter Anvin" <hpa@...or.com>, Wanpeng Li <wanpengli@...cent.com>, Sean Christopherson <sean.j.christopherson@...el.com>, Jim Mattson <jmattson@...gle.com>, Vivek Goyal <vgoyal@...hat.com>, Gavin Shan <gshan@...hat.com>, Peter Zijlstra <peterz@...radead.org>, linux-kernel@...r.kernel.org Subject: Re: [PATCH v2 00/10] KVM: x86: Interrupt-based mechanism for async_pf 'page present' notifications On 25/05/20 16:41, Vitaly Kuznetsov wrote: > Concerns were expressed around (ab)using #PF for KVM's async_pf mechanism, > it seems that re-using #PF exception for a PV mechanism wasn't a great > idea after all. The Grand Plan is to switch to using e.g. #VE for 'page > not present' events and normal APIC interrupts for 'page ready' events. > This series does the later. > > Changes since v1: > - struct kvm_vcpu_pv_apf_data's fields renamed to 'flags' and 'token', > comments added [Vivek Goyal] > - 'type1/2' names for APF events dropped from everywhere [Vivek Goyal] > - kvm_arch_can_inject_async_page_present() renamed to > kvm_arch_can_dequeue_async_page_present [Vivek Goyal] > - 'KVM: x86: deprecate KVM_ASYNC_PF_SEND_ALWAYS' patch added. > > v1: https://lore.kernel.org/kvm/20200511164752.2158645-1-vkuznets@redhat.com/ > QEMU patches for testing: https://github.com/vittyvk/qemu.git (async_pf2_v2 branch) I'll do another round of review and queue patches 1-7; 8-9 will be queued later and separately due to the conflicts with the interrupt entry rework, but it's my job and you don't need to do anything else. Thanks, Paolo
Powered by blists - more mailing lists