qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] mac99: Change memory layout to better match


From: Mark Cave-Ayland
Subject: Re: [Qemu-devel] [PATCH v2] mac99: Change memory layout to better match PowerMac3, 1
Date: Mon, 23 Jun 2014 22:33:29 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]