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:27:36 +0200
Message-ID: <20091020132736.GL29477@redhat.com>
References: <4ADDB49B.3010101@siemens.com>
 <5D3F39A4-0532-4027-8D71-87FE9BCA1C27@suse.de>
 <4ADDB8ED.3070600@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]:11153 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751846AbZJTN1h (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 20 Oct 2009 09:27:37 -0400
Content-Disposition: inline
In-Reply-To: <4ADDB8ED.3070600@siemens.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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 :)

--
			Gleb.