linux-kernel - Re: [PATCH RFC 0/2] KVM: nVMX: fix apicv disablement for L1

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] [day] [month] [year] [list]

Message-ID: <71921ae9-56b2-2f1c-410b-f61c37db1a17@redhat.com>
Date:   Fri, 21 Feb 2020 17:50:23 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>,
        Jim Mattson <jmattson@...gle.com>, kvm@...r.kernel.org
Cc:     Sean Christopherson <sean.j.christopherson@...el.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 0/2] KVM: nVMX: fix apicv disablement for L1

On 20/02/20 18:22, Vitaly Kuznetsov wrote:
> 
> RFC: I looked at the code and ran some tests and nothing suspicious popped
> out, however, I'm still not convinced this is a good idea to have apicv
> enabled for L2 when it's disabled for L1... Also, we may prefer to merge
> or re-order these two patches.

I swapped the patches and queued them.  The basic observation is that
APICv is only about virtualizing the APIC, without any interaction with
the hypervisor's APIC apart from the IPI path.  So if L1 turns it on it
wants L1 and L2's APICs to be completely independent, and SynIC is
completely irrelevant.  All that matters is again whether the IPI path
works, and that is what patch 2 fixes.

Paolo