From: Jason Gress <jasong@ccgr.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Impractical ideas?
Date: Thu, 6 May 2004 20:34:39 -0500 [thread overview]
Message-ID: <200405062034.39658.jasong@ccgr.org> (raw)
In-Reply-To: <1083881490.3560.1143.camel@aragorn>
On Thursday 06 May 2004 05:11 pm, John R. Hogerhuis wrote:
> Of course, there is already something in real life that can get you most
> of this if you can afford to rent one: a logic analyzer with built-in
> disassembler.
>
> To buy one is *a lot* unless you get an old one like I have which is
> only useful mainly for instrumenting older systems.
>
> I guess we're getting really sci-fi now, but maybe you should just make
> it pass-through everything to underlying OS, and the front end would be
> a virtual logic analyzer.
>
> Of course thinking about the cool timing diagrams a logic analyzer gives
> you, I think I'm realizing what the real problem is here: timing.
> Virtual drivers incorporate knowledge of timing of the real devices in
> their operation. Without that buffer between you and the bare metal, I
> think the live guest driver just ain't gonna work. Counterarguments?
>
I hate to feed the fire ;), but it would seem that drivers couldn't use too
much timing information as they can never expect a certain time for anything.
Example: If I had a 50MHz FSB, won't most PCI cards still work even though
most systems run at 66MHz? (Think old Pentiums) Also I would think that in
the case of, say a PCI Gigabit ethernet or HDD controller hogging the
bandwidth on a PCI bus that a video card (or whatever) would still work
properly even though the delays may go up on a 'real' system in those cases.
So, in conclusion, I would think that timing may not be all 'that'
important. ;)
> -- John.
>
Jason
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
next prev parent reply other threads:[~2004-05-07 1:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-06 16:08 [Qemu-devel] Impractical ideas? Robert Wittams
2004-05-06 18:06 ` John R. Hogerhuis
2004-05-06 21:52 ` J. Mayer
2004-05-06 22:11 ` John R. Hogerhuis
2004-05-07 1:34 ` Jason Gress [this message]
2004-05-07 1:38 ` John R. Hogerhuis
2004-05-07 9:44 ` David Woodhouse
2004-05-07 17:13 ` Irvin Probst
2004-05-07 17:51 ` Chad Page
2004-05-07 19:21 ` David Woodhouse
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=200405062034.39658.jasong@ccgr.org \
--to=jasong@ccgr.org \
--cc=qemu-devel@nongnu.org \
/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.