Re: [Qemu-devel] [PATCH] Make rtl8139 network interface card compatible with Mac OS 10.4

[Programmingkid]

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