From: Robert Reif <reif@earthlink.net>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [5849] Change MMIO callbacks to use offsets, not absolute addresses.
Date: Mon, 23 Feb 2009 20:05:33 -0500 [thread overview]
Message-ID: <49A347DD.3030906@earthlink.net> (raw)
In-Reply-To: <200902240030.29683.paul@codesourcery.com>
Paul Brook wrote:
>> Sparc devices are passed in their physical addresses. They are
>> currently hard wired
>> because there is no proper bus/slot layer and only on-broad devices are
>> implemented
>> anyway. However each system may have the same hardware located at
>> different locations
>> so this may not be typical QEMU behavior. Real hardware deals with real
>> addresses.
>>
>
> Oh real hardware address decoding is typically implemented as chip selects in
> the host bridge, routing tables in the switch fabric, and/or having
> individual devices do address decoding and claiming transactions on a shared
> bus. Modelling full per-device address decoding simply isn't feasible, we
> have to use additional knowledge (e.g. PCI BARs or fixed address fanges) to
> perform that decoding at a higher level.
>
>
The layers above the device emulation must be responsible for generating the
the physical address appropriately. This is looking at the problem from
a sparc
perspective.
Sparc hardware is very fault happy and will generate a fault if you look
at it funny.
This isn't an issue when running a fully debugged OS but limits QEMU's
usefulness
as a OS development platform.
The open boot self tests do strange and unimplemented things and I would
like to see more of that work in the future. The same applies to more
than the
currently supported OSs. I would rather have the hardware emulation work
properly and run any OS than the current approach of trying a specific
OS and hardware configuration and fixing what breaks. All I want is QEMU
to be a better product.
How do you propose having the hardware drivers generate meaningful and
timely
faults when an improper access is performed so it behaves like real low
level
software expects the hardware to behave? A device could generate a
fault and pass the
offset up to a higher layer that has knowledge of the real physical
address but that
currently doesn't exist.
next prev parent reply other threads:[~2009-02-24 1:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-01 18:59 [Qemu-devel] [5849] Change MMIO callbacks to use offsets, not absolute addresses Paul Brook
2009-02-23 12:18 ` Robert Reif
2009-02-23 12:36 ` Paul Brook
2009-02-23 12:42 ` Robert Reif
2009-02-23 13:16 ` Paul Brook
2009-02-23 16:43 ` Robert Reif
2009-02-23 17:04 ` Paul Brook
2009-02-24 0:08 ` Robert Reif
2009-02-24 0:30 ` Paul Brook
2009-02-24 1:05 ` Robert Reif [this message]
2009-02-24 1:12 ` Paul Brook
2009-02-24 1:27 ` Robert Reif
2009-02-24 1:50 ` Paul Brook
2009-02-24 21:04 ` Blue Swirl
2009-02-24 22:28 ` Paul Brook
2009-02-25 19:54 ` Blue Swirl
2009-02-26 15:19 ` Paul Brook
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=49A347DD.3030906@earthlink.net \
--to=reif@earthlink.net \
--cc=paul@codesourcery.com \
--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).