linux-kernel - Re: [PATCH 4/4] KVM: x86: allow hotplug of VCPU with APIC ID over 0xff

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: <20161205160228.GA8660@potion>
Date:   Mon, 5 Dec 2016 17:02:29 +0100
From:   Radim Krčmář <rkrcmar@...hat.com>
To:     David Hildenbrand <david@...hat.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        Paolo Bonzini <pbonzini@...hat.com>,
        Igor Mammedov <imammedo@...hat.com>
Subject: Re: [PATCH 4/4] KVM: x86: allow hotplug of VCPU with APIC ID over
 0xff

2016-12-05 15:37+0100, David Hildenbrand:
> Am 02.12.2016 um 20:44 schrieb Radim Krčmář:
>> LAPIC after reset is in xAPIC mode, which poses a problem for hotplug of
>> VCPUs with high APIC ID, because reset VCPU is waiting for INIT/SIPI,
>> but there is no way to uniquely address it using xAPIC.
>> 
>> From many possible options, we chose the one that also works on real
>> hardware: accepting interrupts addressed to LAPIC's x2APIC ID even in
>> xAPIC mode.
>> 
>> KVM intentionally differs from real hardware, because real hardware
>> (Knights Landing) does just "x2apic_id & 0xff" to decide whether to
>> accept the interrupt in xAPIC mode and it can deliver one interrupt to
>> more than one physical destination, e.g. 0x123 to 0x123 and 0x23.
>> 
>> Add a capability to let userspace know that we do something now.
> 
> Should we allow user space to turn it on/off for compatibility handling? Or
> do we just not care?

There should be no guest that relies on the previous behavior, so I'd
forgo the toggle, because it would be extra conditions in the code.
I'd add it as a flag to KVM_CAP_X2APIC_API if you have reasons to let
userspace choose.

>                      (or how will this capability be used later on?)

New userspace should check this capability and disable hotplug of VCPUs
with id over 255 if KVM doesn't support it.