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

Message-ID: <4EF85BF3.9010903@redhat.com>
Date:	Mon, 26 Dec 2011 13:35:15 +0200
From:	Avi Kivity <avi@...hat.com>
To:	"Liu, Jinsong" <jinsong.liu@...el.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

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.

> 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.

-- 
error compiling committee.c: too many arguments to function

--
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/