Quoting Steve Reinhardt <ste...@gmail.com>:
On Sat, Sep 25, 2010 at 5:03 AM, Gabriel Michael Black
<gbl...@eecs.umich.edu> wrote:
[...]
1 & 2 sound good to me.
3. For selectively trapped instructions, StaticInst properties might now
vary based on runtime information which doesn't really work.
I can see how this is a theoretical issue but I'm not convinced it
will matter in practice. Basically either you're always faking
something, just possibly in different ways, or you're faking it or not
depending on the mode (syscalls in SE vs FS). And as long as you're
faking it anyway, I don't think you need to worry about imprecision in
the instruction itself.
You're -not- faking it anyway, though. If the same code works in SE
and FS modes, you're faking in one situation and not in the other with
the same code and the same StaticInsts. The instruction needs to
decide if its non-speculative, serialize before/after, artificially
dependent on register so and so, and the right answer wouldn't be
fixed ahead of time if SE and FS were just artifacts of the
configuration and convention and not enforced with #ifdefs.
That said, while worrying about this is probably healthy planning, we
(I) might not want to get too far ahead of our(my)self and worry about
the fine details of merging FS and SE modes yet. That will come, I
think, but there are benefits from just consolidating the mechanisms
providing "magic instruction" type behavior.
4. As I understand it we have system objects in SE and FS mode, and process
objects in SE mode but nothing to correspond to them in FS. We may want to
introduce an OS object to be the backing object there.
Are you proposing this for the case where we do "hypercall emulation"
to have M5 fake the existence of a hypervisor, like it fakes an OS in
SE mode now? It makes sense in that context, but I don't see how it's
necessary otherwise. I would say that there's no need to push on this
unless we really have a desire to support "HE mode". I like the
elegance of this generalized model that makes HE mode possible, but
I'm not convinced there's much practical need for it... I think
implementing the virtualization extensions of a real ISA so we can run
something like KVM under M5 would be more useful.
No. I think HE mode is a fairly interesting idea (paravirtualize
tricky devices?), but I'm talking about something that understands the
ABI and knows where to pull arguments from when dispatching a pseudo
inst for instance. 64 bit Linux and 32 bit Linux and Windows (maybe 32
bit vs. 64 bit) will all most naturally (and maybe compulsively) do
that differently, but they don't and can't with the current set up.
We've made the implicit assumption that we'll always be dealing with
one static ABI per ISA. We might also want instructions that recognize
that you've requested a BIOS service, for instance, and fake that
through a backing BIOS object. I don't know exactly how PAL mode calls
are handled in FS for Alpha (I think we have a ROM?) but if those are
faked this would be a similar sort of thing. Basically I want to have
one or more objects associated with whatever the workload is, or maybe
really whatever code might run since the BIOS isn't really a workload,
and have them register to handle families of hypercalls.
On top of that, the code that sets up an OS kernel is mechanically
pretty similar to the thing that loads a process in SE mode. The both
take an image and blast it into memory, set up supporting memory
structures (initial stack, BIOS tables, etc.) and both configure the
hardware to start running whatever they loaded. This seems ripe for
generalization.
Gabe
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
