From mboxrd@z Thu Jan  1 00:00:00 1970
From: Gleb Natapov <gleb@redhat.com>
Subject: Re: List of unaccessible x86 states
Date: Tue, 20 Oct 2009 15:32:00 +0200
Message-ID: <20091020133200.GM29477@redhat.com>
References: <4ADDB49B.3010101@siemens.com>
 <5D3F39A4-0532-4027-8D71-87FE9BCA1C27@suse.de>
 <4ADDB8ED.3070600@siemens.com>
 <20091020132736.GL29477@redhat.com>
 <4ADDBB42.6000103@siemens.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Alexander Graf <agraf@suse.de>, kvm-devel <kvm@vger.kernel.org>,
	Avi Kivity <avi@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:23684 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1750976AbZJTNcB (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 20 Oct 2009 09:32:01 -0400
Content-Disposition: inline
In-Reply-To: <4ADDBB42.6000103@siemens.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Tue, Oct 20, 2009 at 03:29:38PM +0200, Jan Kiszka wrote:
> Gleb Natapov wrote:
> > On Tue, Oct 20, 2009 at 03:19:41PM +0200, Jan Kiszka wrote:
> >> Alexander Graf wrote:
> >>> On 20.10.2009, at 15:01, Jan Kiszka wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> as the list of yet user-unaccessible x86 states is a bit volatile ATM,
> >>>> this is an attempt to collect the precise requirements for additional
> >>>> state fields. Once everyone feels the list is complete, we can decide
> >>>> how to partition it into one ore more substates for the new
> >>>> KVM_GET/SET_VCPU_STATE interface.
> >>>>
> >>>> What I read so far (or tried to patch already):
> >>>>
> >>>> - nmi_masked
> >>>> - nmi_pending
> >>>> - nmi_injected
> >>>> - kvm_queued_exception (whole struct content)
> >>>> - KVM_REQ_TRIPLE_FAULT (from vcpu.requests)
> >>>>
> >>>> Unclear points (for me) from the last discussion:
> >>>>
> >>>> - sipi_vector
> >>>> - MCE (covered via kvm_queued_exception, or does it require more?)
> >>>>
> >>>> Please extend or correct the list as required.
> >>> hflags. Qemu supports GIF, kvm supports GIF, but no side knows how to  
> >>> sync it.
> >> OK. Whole hflags or just the GIF bit?
> >>
> >> If we allow access to all bits, can user space cause any problems
> >> (beyond screwing up its guests) by passing weird patterns?
> >>
> > HF_NMI_MASK should be migrated too. Destination should enable IRET intercept if
> > HF_NMI_MASK is set. Or we can assume that migration in the middle of NMI
> > will never happen :)
> 
> HF_NMI_MASK is redundant to the vendor-agnostic nmi_masked and would
> therefore likely be masked out.
> 
Correct. We can restore HF_NMI_MASK from nmi_masked.

--
			Gleb.