On 16/07/14 11:01, Jiuyue Ma via gem5-dev wrote:
On July 15, 2014, 1:26 p.m., Andreas Sandberg wrote:
Could you split this into two (or potentially three) different patches?
The PCI/ISA bus ID fixes look fine and should definitely go upstream ASAP. As
far as I'm concerned that particular part of the patch can be submitted
separately right away as it is a small bug fixes that is limited to a few lines.
I'm not so sure about the bridge ranges though. The PCI specification seems to
allow devices to be mapped to pretty much any region of the memory space, so we
can probably not do what you're doing currently to determine the range.
Unfortunately, I can't think of a good solution off the top of my head. I'll
discuss it with some colleagues and get back to you.
Split into three patches may be better:
1) PCI/ISA bus ID fixes
2) add/connect ethernet device
3) bridge range fixes
I will do this split latter tomorrow.
Thank you! That's a good split.
About the bridge range, I have tried to modify recvRangeChange() interface of
Bridge: change bridge's slave port range when its master side changed.
I think this should be a better solution than current one. But I failed to deal
with the address conflict of mem_ctrls and iobridge/iocache in membus. T_T
I've discussed this with a couple of colleagues and it is not obvious
how to sort out the bridge issue. I think the bridge used to
automatically discover which device ranges were connected and magically
just work (in most cases), but this could get pretty hairy in the
general case depending on bus topology.
I checked how Linux handles address assignments (see e820.c somewhere in
arch/x86/) and it simply looks for a big hole (don't remember the
minimum size) in the memory map below 4GB. In practice, this finds the
hole that starts at around 3GB on most PCs. We could exploit this
behaviour to force IO devices to be mapped in a specific range (gem5
seems to assume 0xC0000000-0xFFFFFFFF for devices). That would require
the following changes:
* Statically bridge 0xC0000000-0xFFFF0000 to the IO bus. (The upper
64kB are reserved for m5ops.)
* Make sure that no E820 entry covers the IO range. (There isn't a
separate device entry type.)
* If RAM is less than 3GB reserve anything between the end of ram and
3GB. (I.e., everything below 3GB is covered by the E820 map and is
either ram or reserved.)
I think the above would be the simplest solution for now since it
doesn't involve mucking around with the bridge and it should "just work".
//Andreas
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in
England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
