[9fans] Fwd: [Lguest] mercurial repo

[9fans] Fwd: [Lguest] mercurial repo

[ron minnich]

So I get the following argument from a linux guy about why allowing
the plan 9 system call interrupt is bad. 0x40 never struck me as
particularly dangerous.

Anybody got a comment here?

ron

---------- Forwarded message ----------
From: Zachary Amsden <zach@vmware.com>
Date: Jul 26, 2007 2:08 PM
Subject: Re: [Lguest] mercurial repo
To: ron minnich <rminnich@gmail.com>
Cc: lguest@ozlabs.org


ron minnich wrote:
> Next question. I do have a working patch to allow experts to set the
> system call #. Really, though, it makes more sense to set this in
> sysfs or via a per-guest ioctl or some such, right? What's the fix
> here? Plan 9 port is done, but I do need this change among others.
>

Allowing one to set the system call # is a bad idea.  You can't allow it
to overlap with any host IRQ or architectural fault handler.  Because
Linux uses IPIs in high numbers, and 0-0x1f are architectural faults,
the only truly safe system call vector that you can dispatch is 0x80.

If you have an IO-APIC, pretty much everything else overlaps with a host
IRQ, with the exception of a couple stray vectors in 0xfX range.

Unless, of course, you want to push for an API where clients can reserve
IDT vectors.  This doesn't work today because there is no way to reverse
map from IDT vector to IRQ for IO-APIC vectors, which you need to do so
you  can disable or re-wire all IRQs for that vector in hardware.  You
also need to stop MSI sources from getting to you.

Spurious systems calls (and/or hypercalls) caused by interrupt sources
are rather bad.  We used to steal vector 0xfe, the APIC error vector,
for making hypercalls.  Which worked great until we ran on a machine
with a badly wired APIC.  Similar problems occur if you pass through
gates on top of IRQs.

Zach