On 30/12/2015 01:35, Programmingkid wrote: > After a lot of stepping thru code using gdb, I found out that a > MemoryRegions's enabled member variable was set to false, causing a zero > value being returned every time. When I set the value to true, that is > when the magic started happening. For the first time, data between the > driver and the emulated nic matched. It didn't take me too long to > figure out where to put the code needed to make communications possible. > > I would build the Mac OS X driver inside of QEMU using Mac OS 10.4 > as a guest. I used XCode to build the driver. To run the driver I used > these commands: > > "sudo su" once to go into root. > cp -R <path to xcode build directory>/AppleRTL8139.kext /tmp > kextload /tmp/AppleRTL8139.kext > Then review all the debug text I would see in the Console application. > kextunload /tmp/AppleRTL8139.kext - unload the driver so I could test more > changes without rebooting. > > I would sometimes go into the Network Pane inside of the System > Preferences to see if the nic was working. After a lot of hard work, > I was able to watch a YouTube video inside of QEMU with this patch > applied.
Since you have the source, why don't you fix the driver instead? These changes to QEMU, unfortunately, are not correct. Reordering the BARs breaks Linux in all likelihood, and the bus master enable bit is there to avoid undesired memory corruptions on e.g. reset. (This does not cover the fact that #ifdefs are not the way to handle backwards-compatibility; 99% of the QEMU users do not build from source). I guess you _could_ add a property to ignore the bus master enable bit on a per-device basis (or per-class using -global). But still, fixing the driver seems much, much simpler. Both reordering the BARs, and setting the bus master bit in the command register after initialization is complete, should be easy to do. Paolo
