linux-kernel - RE: [PATCH v2] KVM: x86: Prevent exposing TSC deadline timer feature in the absence of in-kernel APIC

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: <DE8DF0795D48FD4CA783C40EC8292335C418@SHSMSX101.ccr.corp.intel.com>
Date:	Mon, 26 Dec 2011 14:23:39 +0000
From:	"Liu, Jinsong" <jinsong.liu@...el.com>
To:	Avi Kivity <avi@...hat.com>
CC:	Jan Kiszka <jan.kiszka@...mens.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Alexey Zaytsev <alexey.zaytsev@...il.com>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Garrett D'Amore <garrett@...enta.com>,
	kvm <kvm@...r.kernel.org>, "Li, Susie" <susie.li@...el.com>
Subject: RE: [PATCH v2] KVM: x86: Prevent exposing TSC deadline timer
 feature in the absence of in-kernel APIC

Avi Kivity wrote:
> On 12/26/2011 10:11 AM, Liu, Jinsong wrote:
>>> 
>>> It breaks live migration: if you start a guest on a TSC-deadline
>>> capable host kernel, and migrate it to a TSC-deadline incapable host
>>> kernel, you end up with a broken guest.
>>> 
>>> More broadly, kvm never exposes features transparently to the guest,
>>> it always passes them to userspace first, so userspace controls the
>>> ABI exposed to the guest.  This prevents the following scenario:
>> 
>> Do you mean, by the method qemu control cpuid exposing, it can avoid
>> live migration broken issue by 
>> 1. user probe the lowest ability host of whole pool where vm may
>> live migrate; 
>> 2. only if the lowest ablility host support the feature can user
>> enable the feature when boot a vm; 
>> 3. if the lowest ability host didn't support the feature (say tsc
>> deadline timer as example), user disable the feature when boot a vm;
>> In this way, live migration wouldn't be broken. Right? 
> 
> Right.

Thanks Avi, for your detailed explanation, fix a long misunderstanding I had for live migration.

Best Regards,
Jinsong

> 
>> or, do you mean qemu-kvm solve live migration broken issue by some
>> other method? 
> 
> The method you outlined, or any other method, such as partitioning the
> cluster according to hardware capabilities.
> 
>> 
>>> 
>>> - a guest is started on some hardware, which doesn't support some
>>> cpuid feature (say AVX for example)
>>> - the guest or one of its applications are broken wrt AVX, but
>>> because the feature is not exposed, it works correctly
>>> - the host hardware is upgraded to one which supports AVX
>>> - the guest is now broken
>> 
>> You mean, live migrate from 'old' (which doesn't support the
>> feature) platform to 'new' platform would broken? 
> 
> Live migration, or even just a guest restart on updated hardware.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/