public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Zachary Amsden <zach@vmware.com>
To: Zwane Mwaikambo <zwane@arm.linux.org.uk>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: VMI Interface Proposal Documentation for I386, Part 5
Date: Tue, 14 Mar 2006 09:01:19 -0800	[thread overview]
Message-ID: <4416F6DF.3050407@vmware.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0603140040230.11606@montezuma.fsmlabs.com>

Zwane Mwaikambo wrote:
> I believe it certainly is worth seperating and would help in the iret, in 
> that you could enable interrupts without recursing again.
>   

The iret instruction is by far the trickiest and most sinister 
instruction in the i386 architecture to virtualize.  It is used for so 
many different things - setting VIF and VIP flags, returning to kernel 
mode from an interrupt or exception, returning to user mode from a 
system call, returning to v8086 mode.  And it uses the stack differently 
for some of these.  And it is inherently non-virtualizable, because it 
is sensitive to IOPL without trapping.  And it performs many actions 
atomically - setting CPU flags, segment registers and EIP,  popping 
values off the stack.  And it is often used from one code location for 
many of these possible effects simultaneously.  And it alters code flow, 
so after it executes, there is no going back.  Unfortunately, it is 
usually not possible to entirely separate the implications of interrupt 
delivery from the iret instruction.

Iret really does need specially treatment.  You can't virtualize it in 
one instruction without hardware assistance.  But you can emulate it 
successfully if you can perform a simple test on your fault / IRQ 
delivery path.  See patch 8, Vmi syscall assembly for some more 
details.  The same race condition is inherent to all stack based event 
delivery mechanisms.

Zach

  parent reply	other threads:[~2006-03-14 17:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-13 19:56 VMI Interface Proposal Documentation for I386, Part 5 Zachary Amsden
2006-03-14  7:59 ` Zwane Mwaikambo
2006-03-14  8:25   ` Zachary Amsden
2006-03-14  8:47     ` Zwane Mwaikambo
2006-03-14 16:45       ` Zachary Amsden
2006-03-14 17:01       ` Zachary Amsden [this message]
2006-03-15 23:41     ` Pavel Machek
2006-03-16  1:33       ` Zachary Amsden

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=4416F6DF.3050407@vmware.com \
    --to=zach@vmware.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zwane@arm.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox