[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20100309062803.GI16909@redhat.com>
Date: Tue, 9 Mar 2010 08:28:03 +0200
From: Gleb Natapov <gleb@...hat.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Avi Kivity <avi@...hat.com>,
john cooper <john.cooper@...rd-harmonic.com>,
Takuya Yoshikawa <yoshikawa.takuya@....ntt.co.jp>,
linux-kernel@...r.kernel.org, mingo@...e.hu, mtosatti@...hat.com,
zamsden@...hat.com
Subject: Re: use of setjmp/longjmp in x86 emulator.
On Mon, Mar 08, 2010 at 03:11:49PM -0800, Eric W. Biederman wrote:
> Avi Kivity <avi@...hat.com> writes:
>
> > On 03/02/2010 09:28 AM, Gleb Natapov wrote:
> >> On Mon, Mar 01, 2010 at 02:13:32PM -0500, john cooper wrote:
> >>
> >>> Gleb Natapov wrote:
> >>>
> >>>
> >>>> Think about what happens if in the middle of
> >>>> instruction emulation some data from device emulated in userspace is
> >>>> needed. Emulator should be able to tell KVM that exit to userspace is
> >>>> needed and restart instruction emulation when data is available.
> >>>>
> >>> setjmp/longjmp are useful constructs in general but
> >>> IME are better suited for infrequent exceptions vs.
> >>> routine usage.
> >>>
> >> Exception condition during instruction emulation _is_
> >> infrequent.
> >
> > Well, with mmio you'd expect it to happen every read access.
>
> Of course if you are hitting that kind of case very often
> you don't want to do the emulation in the kernel but
> in userspace so you don't have to take the context switch
> overhead and everything else.
>
The devices that do mmio most often are already in the kernel
to avoid exit to usesrapce on each access. And mmio may be the
most frequent cause of emulation, but not the only one.
> I know running emulations in userspace was for dosemu
> the difference between a 16 color ega emulation on X
> that was unusable to one that was good enough to play video
> games like wolfenstein and doom.
>
> Eric
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists