Hey Gabe, I believe the developers at AMD have already implemented a lot of similar things to get their GPU model working. The relevant Jira issue is https://gem5.atlassian.net/browse/GEM5-470 (I think). There may be other relevant issues on this Epic: https://gem5.atlassian.net/browse/GEM5-195.
I just want to make sure we rope in everyone who has been doing development in this space! Cheers, Jason On Thu, Oct 1, 2020 at 9:33 PM Gabe Black via gem5-dev <gem5-dev@gem5.org> wrote: > Hi folks. We locally just rebased and picked up a change where the ARM PCI > controller's configuration was fixed so that it had the appropriate > starting address for memory mappings. Now that that's correct, it means > that instead of setting memory BARs to 0x40000000 (for example) to get them > in the correct place, they need to be set to 0, and the "hardware" will > take care of adding in a 0x40000000 offset. > > That's more correct, but it means that now the BAR needs to be set to 0, > and the gem5 PCI BAR handling code is a little bit simplistic and wrong in > that it treats 0 and 0xffffffff as magical values and has special behavior > when the BARs are set to them. Specifically, it treats a 0 as off, and > doesn't update the ranges the device responds to on its parent bus. This > isn't a problem on x86 where the memory addresses are usually not 0 since > there's actual RAM there, and there's generally no offset applied either. > > To fix this, I have a big rework in progress which will change how BARs > are set up for PCI devices across the board. Note that this will not affect > any of the work Andreas did a while ago setting up a host device, the > DeviceInterface type, etc., which is all fine. There are two major parts to > the change I'm making, in python and C++. > > First, rather than having several arrays of scalar parameters which > together control the BARs, a raw BAR value as it would be in the config, a > flag setting it s a "legacyIO", and a size, (and a legacy IO offset!) each > BAR is represented by a python object whose type reflects it's job. There > is one for IO, one for memory, one for the upper 32 bits of a 64 bit BAR, > and one for legacy IO. They each have appropriate properties like a fixed > address or a size as appropriate, and are assigned to a device as a > VectorParam. > > Then on the C++ side, rather than try to track things from the raw BAR > values, config writes are filtered through the BAR objects which know what > bits to mask, what the corresponding address range should be based on their > type, etc. I also took this opportunity to clear away a number of clumsy > bookkeeping mechanisms and bugs/misunderstandings of how BARs work, many of > them my own from a long time ago. Also, the handling of disabling memory or > IO BARs through the config "command" byte is now handled centrally, rather > than being implemented one off in the IDE controller. > > Both of these things seem to now be working, so that's great. The reason > I'm writing an email rather than sending a code review (yet) is that I'm > also running into a problem with the python config. > > The gist of it is that the PCI device creates the VectorParam of BARs. The > IDE controller then sets the BARs using a python list of BAR objects as a > default, and that works. Then in the X86 SouthBridge object (x86 is a > little easier for me to test atm), I've tried to overwrite some of those > BARs individually to give them new defaults which make sense on x86. That > fails because the new values are not parented correctly. If I try setting > the whole VectorParam with a new list, then it works fine. I think the > problem is that foo.bar[0] = doesn't actually set foo.bar, it extracts bar > from foo and then sets element 0 in the bar it extracted. The bookkeeping > for this is wrong somehow. > > Anyway, I wanted to send out an email to let people know there's a bug > here on both counts, in case they ran into any problems. The default ARM > setup should be mostly ok since the only PCI device seems to be the IDE > controller, and that uses legacy style fixed IO BARs which seem to work > fine. I also wanted to let people know I'm fighting with the bug in the > config system. I'm going to try to figure that one out, but it's pretty > twisty in there and I'm struggling to understand how all that plumbing > works. If anybody has any great insights, I'd be happy to hear them! > > Gabe > _______________________________________________ > gem5-dev mailing list -- gem5-dev@gem5.org > To unsubscribe send an email to gem5-dev-le...@gem5.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
