[Qemu-devel] Re: [kvm-devel] [ kvm-Bugs-1802223 ] nics have same hw address (rtl8139)

[Avi Kivity <avi@qumranet.com>]

Daniel P. Berrange wrote:
> On Wed, Sep 26, 2007 at 06:02:21PM +0200, Laurent Vivier wrote:
>   
>> Daniel P. Berrange wrote:
>>     
>>> On Wed, Sep 26, 2007 at 05:47:20PM +0200, Laurent Vivier wrote:
>>>       
>>>> Hi,
>>>>
>>>> I think there is a bug in qemu RTL8139.
>>>>
>>>> RTL8139 uses:
>>>>
>>>> cpu_register_physical_memory(addr + 0, 0x100, s->rtl8139_mmio_io_addr);
>>>>
>>>> But in the comment of cpu_register_physical_memory() we have:
>>>>
>>>> "'size' must be a multiple of the target page size."
>>>>
>>>> And I think 0x100 is not a multiple of target page size.... :-P
>>>>         
>>> Latest upstream QEMU has fixed its memory handling so that MMIO regions
>>> do not need to be a multiple of page size. Changing RTL8139 to use a
>>> block of size 0x1000 is a reasonable short term hack around the problem,
>>> but syncing with latest QEMU is the real solution, since there are other
>>> places in the code which will have similar issues.
>>>
>>>       
>> So this explains why rtl8139.c from QEMU CVS always uses 0x100.
>>
>> Thank you for the comment.
>>
>> Avi, you know what you have to do ;-)
>>     
>
> I did start on back porting the QEMU  subpage handling fixes to KVM for
> Fedora 7, but in the end went for the simpler  s/0x100/0x1000/ quick hack.
> I'm attaching the patch which I started against kvm-24 in case it is useful,
> though note that the only testing I did with it was to see if a F7 guest 
> booted and saw distinct MAC addrs. It should apply with minor fuzz/offsets
> to at least kvm-35.
>   

Everything points to a qemu merge being sorely needed.  Does anyone have
any experience with recent versions?


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.