qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).