From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pekka Enberg Subject: Re: [PATCH 2/2] KVM: Document KVM_SET_TSS_ADDR Date: Thu, 25 Mar 2010 14:00:44 +0200 Message-ID: <4BAB506C.7060609@cs.helsinki.fi> References: <1269513099-21060-1-git-send-email-avi@redhat.com> <1269513099-21060-3-git-send-email-avi@redhat.com> <4BAB3CB5.7050303@cs.helsinki.fi> <4BAB3E67.2040504@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Marcelo Tosatti To: Avi Kivity Return-path: Received: from courier.cs.helsinki.fi ([128.214.9.1]:35257 "EHLO mail.cs.helsinki.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751570Ab0CYMAq (ORCPT ); Thu, 25 Mar 2010 08:00:46 -0400 In-Reply-To: <4BAB3E67.2040504@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity kirjoitti: > On 03/25/2010 12:36 PM, Pekka Enberg wrote: >>> +4.35 KVM_SET_TSS_ADDR >>> + >>> +Capability: KVM_CAP_SET_TSS_ADDR >>> +Architectures: x86 >>> +Type: vm ioctl >>> +Parameters: unsigned long tss_address (in) >>> +Returns: 0 on success, -1 on error >>> + >>> +This ioctl defines the physical address of a three-page region in >>> the guest >>> +physical address space. The region must be within the first 4GB of the >>> +guest physical address space and must not conflict with any memory slot >>> +or any mmio address. The guest may malfunction if it accesses this >>> memory >>> +region. >>> + >>> +This ioctl is required on Intel-based hosts. >> >> I don't quite understand what it's _used for_ from the above >> description. I assume it's about task state segment...? > > It's a quirk in the Intel implementation of hardware virtualization > extensions. You cannot enter guest mode in vmx with the guest cr0.pe > cleared (i.e. real mode), so kvm enters the guest in vm86 mode which is > fairly similar and tries to massage things so it looks to the guest as > if it is running in real mode. Unfortunately, vm86 mode requires a task > state segment in the address space, and there is no way for us to hide > it. kvm doesn't know anything about the guest physical memory map, so > it has to rely on userspace to supply an unused region. > > I don't think such a technical description of an implementation detail > has a place in the API reference; maybe in internal documentation. Sure but it would be nice to have something along the lines of "This is needed on Intel hardware because of a quirk in the virtualization implementation" and maybe point the reader to a more appropriate document (internals document, Intel manuals, ...). Pekka