From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: List of unaccessible x86 states Date: Mon, 26 Oct 2009 11:21:12 +0200 Message-ID: <4AE56A08.5090306@redhat.com> References: <4ADDB49B.3010101@siemens.com> <4AE2055A.3050001@web.de> <9D81B6EA-7161-4682-8685-79928C0AC2B3@suse.de> <4AE41F2F.2050700@redhat.com> <20091026091731.GF5326@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Graf , Jan Kiszka , kvm-devel list , Marcelo Tosatti , Gleb Natapov To: Joerg Roedel Return-path: Received: from mx1.redhat.com ([209.132.183.28]:27144 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755330AbZJZJVM (ORCPT ); Mon, 26 Oct 2009 05:21:12 -0400 In-Reply-To: <20091026091731.GF5326@amd.com> Sender: kvm-owner@vger.kernel.org List-ID: On 10/26/2009 11:17 AM, Joerg Roedel wrote: > On Sun, Oct 25, 2009 at 11:49:35AM +0200, Avi Kivity wrote: > >> On 10/24/2009 12:35 PM, Alexander Graf wrote: >> >>> Hm, thinking about this again, it might be useful to have an >>> "currently in nested VM" flag here. That way userspace can decide >>> if it needs to get out of the nested state (for migration) or if >>> it just doesn't care. >>> >> Getting out of nested state involves modifying state (both memory >> and registers). Nor can we in the general case force it. The guest >> can set up a situation where it is impossible to #vmexit. >> > There is actually more than that. If the guest runs in guest mode itself > we also need to report the host state to be able to do an #vmexit after > migration. > In nested SVM the host state is not saved in the guest memory to prevent > the guest from modifying it and break out of its virtualization jail. > Which host state? As far as I can tell, it can all be regenerated. -- error compiling committee.c: too many arguments to function