RE: [Xen-ia64-devel] eepro100 HVM NIC

["Zhang, Xing Z" <xing.z.zhang@xxxxxxxxx>]

>
>On Mon, 2007-10-08 at 10:33 +0800, Zhang, Xing Z wrote:
>> Hi Alex:
>>      I also work on this task. Base on the primary emulator in
>QEMU, I
>> refine it to fix where I think it doesn't
>> follow intel's eepr100 spec. Current status are:
>> 1. it works for linux guest both in XEN/IPF and QEMU. But seems
>> speed is slow.
>> 2. From microsoft's WDK I get a rough eepro100 driver of win2k3.
>> With this driver, the emulator can work in win2k3/X86 in QEMU.
>> 3. The windows device manager can recognize the card both in
>QEMU and
>> XEN/IPF. But it reports there is a resource conflict that
>> makes card can't work.
>>
>> All my works base on a native i82557b card.
>>
>> Now I try to use windbg to investigate into it. I am enabling
>windbg
>> for IPF guest now, hope it helpful. Attachment is my version
>of
>> eepro100.
>
>Hi Wing,
>
>   What is your eepro100 code based on?  It looks like perhaps
>a very
>early revision of what's currently in QEMU CVS.  I haven't
>tested
>performance at all with my port, but it does work with Linux
>guests.  A
>slow virtual NIC that works under Windows/IPF is better than
>not having
>a virtual NIC at all.  Perhaps you're resource issue is the same
>thing
>I'm seeing with Windows moving the BARs on the card to and invalid
>address.  If I turn on debug in the driver, I see this:
>
>The BARs get mapped by some level of firmware/qemu:
>EE100   pci_mmio_map            region 0, addr=0xc4000000,
>size=0x00001000, type=8
>EE100   pci_map                 region 1, addr=0x0000c200,
>size=0x00000040, type=1
>EE100   pci_mmio_map            region 2, addr=0xc4020000,
>size=0x00020000, type=0
>
>When Win2k3 boots, I see this:
>EE100   pci_mmio_map            region 0, addr=0xf4fdf000,
>size=0x00001000, type=8
>EE100   pci_map                 region 1, addr=0x0000c200,
>size=0x00000040, type=1
>EE100   pci_mmio_map            region 2, addr=0xf4fe0000,
>size=0x00020000, type=0
>
>Xen prints out some bad mfn messages with these addresses, which
>is
>presumably the driver trying to access the card and not finding
>the data
>it expects.  A Linux HVM guest doesn't remap the BARs, and the
>0xc4000000 addresses are what I see both from the EFI pci command
>and
>from lspci in Linux.  There don't appear to be any resource
>conflicts
>between the virtual PCI devices that would cause the OS driver
>to
>attempt to remap them.
>
>   I don't know much about debugging Windows, but perhaps if
>you can let
>me know what your code is based on I can extract the spec updates
>you've
>made into my driver and we can work together on it.  Thanks,
>
>       Alex
Hi Alex:
        I don't follow QEMU's upstream to do this driver. When I 
begin this task, I found there is no eepro100 driver in QEMU0.9.2,
so I get a very old version that Tristan sent one year ago. 
Unfortunately, it cannot work in my linux guest. Then I base on
it and intel's sepc to re-write. There is no more 
changes except packet transmit function and eeprom control function. And 
somewhere just likes injecting interrupt under some conditions. 
        
        At my side, I don't find windows do any BARs remapping. Below
are what I got from debug output for win2k3:
EE100   pci_mmio_map                region 0, addr=0xc4000000, size=0x00001000, 
type=8
EE100   pci_ioport_map              region 1, addr=0x0000c200, size=0x00000040, 
type=1
EE100   pci_mmio_map                region 2, addr=0xc4020000, size=0x00020000, 
type=0

It's same with my linux guest.

Actually, I can get windows accessing eeprom from debug codes.
But it's strange that windows masks interrupt of card after reading two eeprom 
register(register 1 and register 14). So I think windows has finished register 
IO/MMIO range. By the way, I also use open GFW.

I will go on looking into it.

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel