All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Pratt <Ian.Pratt@cl.cam.ac.uk>
To: Andi Kleen <ak@suse.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Ian Pratt <Ian.Pratt@cl.cam.ac.uk>,
	Rik van Riel <riel@redhat.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	akpm@osdl.org, Steven.Hand@cl.cam.ac.uk,
	Christian.Limpach@cl.cam.ac.uk, Keir.Fraser@cl.cam.ac.uk,
	Ian.Pratt@cl.cam.ac.uk
Subject: Re: arch/xen is a bad idea
Date: Thu, 16 Dec 2004 20:37:11 +0000	[thread overview]
Message-ID: <E1Cf2N5-0005pD-00@mta1.cl.cam.ac.uk> (raw)
In-Reply-To: Your message of "Thu, 16 Dec 2004 15:28:24 +0100." <20041216142824.GC29761@wotan.suse.de>

> > There are so many problems in snooping and decoding instructions it
> > isn't funny. Aside from the mmap pci buffer half way through instruction
> 
> Hmm? From what I remember reading the code of the Xen hypervisor
> they are already emulating a lot of instructions (e.g. take a look
> at xen/arch/x86/x86_32/seg_fixup.c) Emulating some more doesn't 
> seem like a big issue to me.

There's actually no emulation in Xen at all. seg_fixup is the
closest we come, which is a tiny decoder that is able to work out
the effective address of an instruction. It's only through grim
necessity we need this in order to be able to make NPTL thread
local storage accesses work (-ve segment offsets). We'd much
prefer that glibc was slightly tweaked such that we didn't have
to do this (it would be a lot faster too).

Anyhow, I really don't think emulation is the issue. The handful
of cases that you pointed out that could relatively easily be
emulated constitute a tiny fraction of the arch xen patch.  Even
so, you have to be a bit careful from a performance point of
view: loading debug registers can occur quite frequently, and its
much quicker to be able to load them as a batch rather than
taking individual faults. 


Ian

  reply	other threads:[~2004-12-16 20:37 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <41BF1983.mailP9C1B91GB@suse.de.suse.lists.linux.kernel>
2004-12-14 18:59 ` arch/xen is a bad idea Andi Kleen
2004-12-14 19:35   ` Antonio Vargas
2004-12-14 22:40   ` Ian Pratt
2004-12-15  4:49     ` Andi Kleen
2004-12-16  0:09       ` Alan Cox
2004-12-16  4:01         ` Andi Kleen
2004-12-16 12:54           ` Alan Cox
2004-12-16 14:09             ` Andi Kleen
2004-12-16 13:19               ` Alan Cox
2004-12-16 14:28                 ` Andi Kleen
2004-12-16 20:37                   ` Ian Pratt [this message]
2004-12-16 18:26               ` Andrew Morton
2004-12-16 18:57                 ` Alan Cox
2004-12-16 21:00                 ` Ian Pratt
2004-12-16 21:03                   ` Andrew Morton
2004-12-16 21:36                     ` Ian Pratt
2004-12-16 21:39                       ` Rik van Riel
2004-12-17  6:04                       ` Andi Kleen
2004-12-17  8:26                         ` Ian Pratt
2004-12-16 22:04                   ` Philip R Auld
2004-12-16 23:08                     ` Rik van Riel
2004-12-17  2:07                       ` Philip R Auld
2004-12-17  6:03                   ` Andi Kleen
2004-12-15 11:49     ` Pavel Machek
2004-12-16  1:14       ` Ian Pratt
2004-12-16  1:26         ` Pavel Machek
2004-12-16 14:21         ` Andi Kleen
2004-12-16 22:45       ` Bill Davidsen
2004-12-16 23:09         ` Rik van Riel
2004-12-20 15:08         ` arch/xen clue? Dorn Hetzel
2004-12-20 15:15           ` Ian Pratt
2004-12-20 15:23           ` Anton Altaparmakov
2004-12-20 15:34           ` Måns Rullgård
2004-12-15 11:51     ` arch/xen is a bad idea Pavel Machek
2004-12-17 16:05   ` William Lee Irwin III
2004-12-18 17:57     ` Ian Pratt
2005-02-25 11:43   ` Andrew Morton
2005-02-25 11:55     ` kernel 2.6.8-24.11-smp errors Marcel Smeets
2005-02-25 12:07 arch/xen is a bad idea Ian Pratt
2005-02-25 15:01 ` Andi Kleen
2005-02-25 22:37 ` Andrew Morton
2005-02-26 20:41 Ian Pratt

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=E1Cf2N5-0005pD-00@mta1.cl.cam.ac.uk \
    --to=ian.pratt@cl.cam.ac.uk \
    --cc=Christian.Limpach@cl.cam.ac.uk \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=Steven.Hand@cl.cam.ac.uk \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@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.