On Jan 1, 2016, at 4:36 PM, Paolo Bonzini wrote: > > > 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?
I don't offer a fixed driver because I honestly don't know that the driver is broken. It is also a lot more convenient for the user to just switch on a macro than have to install a custom driver (IMHO). > > 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 didn't know that many users of QEMU do not build from source. I thought it was the other way around. I don't like this solution also. A one size fits all solution is what I was hoping for. > 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. Mark and I are working on an issue with the bus master bit in the command register. It appears to be set to false sometime after Mac OS X starts booting. I only found this out yesterday. Happy New Years to all