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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).