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
next prev 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