From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Cross vendor migration ideas Date: Mon, 17 Nov 2008 13:59:21 +0200 Message-ID: <49215C99.8080800@redhat.com> References: <982D8D05B6407A49AD506E6C3AC8E7D6BEF936912A@caralain.haven.nynaeve.net> <7CCF7468C07AFF4B991DD1528058EC2F042C7283@SSVLEXMB1.amd.com> <878wrl16q5.fsf@basil.nowhere.org> <1FF5F416-082C-4FA2-8392-8552BFBEDA00@suse.de> <491F08F1.40501@firstfloor.org> <49203DFE.1070101@redhat.com> <20081117110934.GH6703@one.firstfloor.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Graf , "Serebrin, Benjamin (Calendar)" , Skywing , Anthony Liguori , kvm@vger.kernel.org, Amit Shah , "Wahlig, Elsie" , "Nakajima, Jun" To: Andi Kleen Return-path: Received: from mx2.redhat.com ([66.187.237.31]:53930 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752779AbYKQL7y (ORCPT ); Mon, 17 Nov 2008 06:59:54 -0500 In-Reply-To: <20081117110934.GH6703@one.firstfloor.org> Sender: kvm-owner@vger.kernel.org List-ID: Andi Kleen wrote: >> But at least for Linux, if we notify the >> guest telling it to retune (which can include the vsyscall path) we can >> avoid the cost entirely. >> > > Hmm, we discussed something like this some time ago anyways (add > a way to rescan CPUID features) because there are microcode updates > around that change some (relatively obscure) CPUID features. > > But doing it fully general would be likely quite intrusive. You > would need to rewrite the CPU initialization code and some other > code in a callback like matter like the PCI code does for hotplug. > > The primary consumer would be compat mode syscall/sysenter. Page copy would be a secondary consumer. All the rest are likely in the noise. Hmm, maybe also the raid5+ algorithms. -- error compiling committee.c: too many arguments to function