From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: List of unaccessible x86 states Date: Tue, 20 Oct 2009 15:29:38 +0200 Message-ID: <4ADDBB42.6000103@siemens.com> References: <4ADDB49B.3010101@siemens.com> <5D3F39A4-0532-4027-8D71-87FE9BCA1C27@suse.de> <4ADDB8ED.3070600@siemens.com> <20091020132736.GL29477@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Graf , kvm-devel , Avi Kivity , Marcelo Tosatti To: Gleb Natapov Return-path: Received: from thoth.sbs.de ([192.35.17.2]:17393 "EHLO thoth.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752043AbZJTN3s (ORCPT ); Tue, 20 Oct 2009 09:29:48 -0400 In-Reply-To: <20091020132736.GL29477@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux