From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
To: BALATON Zoltan <balaton@eik.bme.hu>, Alexander Graf <agraf@suse.de>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org, afaerber@suse.de
Subject: Re: [Qemu-devel] [PATCH v2] mac99: Change memory layout to better match PowerMac3, 1
Date: Mon, 23 Jun 2014 22:33:29 +0100 [thread overview]
Message-ID: <53A89D29.1070001@ilande.co.uk> (raw)
In-Reply-To: <alpine.LMD.2.02.1406232119330.2806@jedlik.phy.bme.hu>
On 23/06/14 20:25, BALATON Zoltan wrote:
>>> It's how OpenBIOS assigns MMIO addresses to pci devices. It does it
>>> by going through them in order and map them starting from the base
>>> address (with some allingment). I guess you could look at
>>> drivers/pci.c I think it's in there somewhere.
>>
>> I think it'd make more sense to just bolt the PCI devices to their
>> respective devfns that they also have on real hardware. Depending on
>> ordering magic that happens to give us different BAR maps by firmware
>> doesn't really give me a lot of confidence.
>
> I don't understand what you mean. I don't want to rewrite PCI handling
> code in OpenBIOS as that would have a higher chance of breaking
> something else (OpenBIOS is used by other archs as well). Also it would
> require more knowledge about the emulated hardware in OpenBIOS while it
> aims to be a generic implementation and wants to reduce special cases
> already in it. So I don't see a cleaner and easy way to do this. If I'm
> missing something please tell me. On the other hand you've said before
> that the mac99 machine is mostly a hack to be enough that some OS-es can
> run with it. Why reordering some devices to get the right BAR maps not
> fit in this hack?
Since the MMIO address is calculated by rounding up to the next start
address based on region size (where size tends to be more static
compared to start address) then I'd be okay with this as a short term hack.
Longer term I suspect we'll need to teach OpenBIOS about assigning fixed
addresses to certain PCI devices based upon architecture, and it's
starting to look like I may need to do this for the next part of my work
on improving SPARC64 support.
ATB,
Mark.
next prev parent reply other threads:[~2014-06-23 21:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-02 23:12 [Qemu-devel] [PATCH v2] mac99: Change memory layout to better match PowerMac3, 1 BALATON Zoltan
2014-06-09 20:26 ` [Qemu-devel] [Qemu-ppc] " BALATON Zoltan
2014-06-16 23:37 ` BALATON Zoltan
2014-06-17 8:46 ` [Qemu-devel] " Alexander Graf
2014-06-17 9:36 ` BALATON Zoltan
2014-06-17 9:39 ` Alexander Graf
2014-06-17 10:24 ` BALATON Zoltan
2014-06-22 9:14 ` [Qemu-devel] [Qemu-ppc] " BALATON Zoltan
2014-06-23 16:27 ` [Qemu-devel] " Alexander Graf
2014-06-23 19:25 ` BALATON Zoltan
2014-06-23 21:33 ` Mark Cave-Ayland [this message]
2014-06-23 22:32 ` BALATON Zoltan
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=53A89D29.1070001@ilande.co.uk \
--to=mark.cave-ayland@ilande.co.uk \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=balaton@eik.bme.hu \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@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.