All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pekka Enberg <penberg@cs.helsinki.fi>
To: Avi Kivity <avi@redhat.com>
Cc: kvm@vger.kernel.org, Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [PATCH 2/2] KVM: Document KVM_SET_TSS_ADDR
Date: Thu, 25 Mar 2010 14:00:44 +0200	[thread overview]
Message-ID: <4BAB506C.7060609@cs.helsinki.fi> (raw)
In-Reply-To: <4BAB3E67.2040504@redhat.com>

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

  reply	other threads:[~2010-03-25 12:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-25 10:31 [PATCH 0/2] Document KVM_SET_USER_MEMORY_REGION and KVM_SET_TSS_ADDR Avi Kivity
2010-03-25 10:31 ` [PATCH 1/2] KVM: Document KVM_SET_USER_MEMORY_REGION Avi Kivity
2010-03-25 10:34   ` Pekka Enberg
2010-03-25 11:10   ` Alexander Graf
2010-03-25 11:49     ` Avi Kivity
2010-03-25 11:54       ` Alexander Graf
2010-03-25 11:58         ` Avi Kivity
2010-03-25 10:31 ` [PATCH 2/2] KVM: Document KVM_SET_TSS_ADDR Avi Kivity
2010-03-25 10:36   ` Pekka Enberg
2010-03-25 10:43     ` Avi Kivity
2010-03-25 12:00       ` Pekka Enberg [this message]
2010-03-25 12:02         ` Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BAB506C.7060609@cs.helsinki.fi \
    --to=penberg@cs.helsinki.fi \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.