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.
