linux-kernel - Re: [PATCH] KVM: lapic: stop advertising DIRECTED

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180211052539.GA31261@xz-mi>
Date:   Sun, 11 Feb 2018 13:25:39 +0800
From:   Peter Xu <peterx@...hat.com>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>
Cc:     kvm@...r.kernel.org, linux-kernel@...r.kernel.org, x86@...nel.org,
        Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>
Subject: Re: [PATCH] KVM: lapic: stop advertising DIRECTED_EOI when in-kernel
 IOAPIC is in use

On Fri, Feb 09, 2018 at 02:01:33PM +0100, Vitaly Kuznetsov wrote:
> Devices which use level-triggered interrupts under Windows 2016 with
> Hyper-V role enabled don't work: Windows disables EOI broadcast in SPIV
> unconditionally. Our in-kernel IOAPIC implementation emulates an old IOAPIC
> version which has no EOI register so EOI never happens.
> 
> The issue was discovered and discussed a while ago:
> https://www.spinics.net/lists/kvm/msg148098.html
> 
> While this is a guest OS bug (it should check that IOAPIC has the required
> capabilities before disabling EOI broadcast) we can workaround it in KVM:
> advertising DIRECTED_EOI with in-kernel IOAPIC makes little sense anyway.
> 
> Signed-off-by: Vitaly Kuznetsov <vkuznets@...hat.com>
> ---
> - Radim's suggestion was to disable DIRECTED_EOI unconditionally but I'm not
>   that radical :-) In theory, we may have multiple IOAPICs in userspace in
>   future and DIRECTED_EOI can be leveraged.

I sort of agree on this, especially considering that we already have
IOAPIC version 0x20 support in QEMU already.

> ---
>  arch/x86/kvm/lapic.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 924ac8ce9d50..5339287fee63 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -321,8 +321,16 @@ void kvm_apic_set_version(struct kvm_vcpu *vcpu)
>  	if (!lapic_in_kernel(vcpu))
>  		return;
>  
> +	/*
> +	 * KVM emulates 82093AA datasheet (with in-kernel IOAPIC implementation)
> +	 * which doesn't have EOI register; Some buggy OSes (e.g. Windows with
> +	 * Hyper-V role) disable EOI broadcast in lapic not checking for IOAPIC
> +	 * version first and level-triggered interrupts never get EOIed in
> +	 * IOAPIC.
> +	 */
>  	feat = kvm_find_cpuid_entry(apic->vcpu, 0x1, 0);
> -	if (feat && (feat->ecx & (1 << (X86_FEATURE_X2APIC & 31))))
> +	if (feat && (feat->ecx & (1 << (X86_FEATURE_X2APIC & 31))) &&
> +	    !ioapic_in_kernel(vcpu->kvm))
>  		v |= APIC_LVR_DIRECTED_EOI;
>  	kvm_lapic_set_reg(apic, APIC_LVR, v);
>  }
> -- 
> 2.14.3
> 

Does this mean that we can avoid the migration problem that Radim
raised in previous discussion?  Basically the OSs should only probe
this version once for each boot, if so I think it should be fine.  But
since you didn't mention that in either commit message and comment, I
would like to ask and confirm.

For the change itself, it looks sane to me.

Thanks,

-- 
Peter Xu