>
>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
|
Home