Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci express support

[Jan Kiszka]

On 2011-05-17 15:57, Isaku Yamahata wrote:
> On Tue, May 17, 2011 at 09:15:39AM +0200, Jan Kiszka wrote:
>> On 2011-05-16 23:55, Adnan Khaleel wrote:
>>> I finally got this work after I realised that the AHCI driver was not being 
>>> loaded in my disk image and that ACHI was not being enabled in the Seabios 
>>> .config file.
>>> This is really good work Yamahata, thanks.
>>>
>>>
>>> As far as I can tell, everything works like the stock Qemu 0.14 except 
>>> networking. The guest OS sees the network device and initialises it but I 
>>> think the Qemu DHCP server/firewall never gets back, since the network 
>>> device doesn't even get a 10.0.2.15 ip address during bootup and the guest 
>>> dhcp client never gets an ip address, 
>>>
>>>
>>> eth0   device: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 
>>> 03)
>>> eth0   Starting DHCP4 client. . . . . . . .
>>> eth0   DHCP4 continues in background 
>>> eth0   device: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 
>>> 03)
>>> eth0   DHCP4 client (dhcpcd) is running
>>> eth0   . . . but is still waiting for data
>>> eth0   interface could not be set up until now
>>>
>>>
>>> So doing an ifconfig later on just shows
>>>
>>>
>>> eth0   Link encap:Ethernet  HWaddr 52:54:00:12:34:56
>>>          UP BROADCAST MULTICAST  MTU:1500  Metric:1
>>>          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>>          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>>>          collisions:0 txqueuelen:1000
>>>          RX bytes:0 (0.0 b)   TX bytes:0 (0.0 b)
>>>
>>>
>>>
>>> lo      Link encap:Local loopback  
>>>          inet addr:127.0.0.1  Mask:255.0.0.0
>>>          inet6 addr: ::1/128 Scope:Host
>>>          UP LOOPBACK RUNING  MTU:16436  Metric:1
>>>          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>>          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>>>          collisions:0 txqueuelen:1000
>>>          RX bytes:0 (0.0 b)   TX bytes:0 (0.0 b)
>>>
>>>
>>> I'm going to start a separate thread to see what the possible cause might 
>>> be and what might be the best way to debug this. Do you have any idea if 
>>> this q35 chipset going to be committed to Qemu upstream?
>>
>> I've recently hacked a bit on q35, rebased it over current master, found
>> and fixed a few bugs to allow booting of WinXP and Win7, and
>> particularly added kvm support to improve testability significantly. You
>> can find my current work at
>>
>> git://git.kiszka.org/qemu.git q35-test
>> git://git.kiszka.org/seabios.git q35-test
>>
>> There are some issues remaining, e.g. usb appeared broken to me. Now I
>> just tested your scenario (e1000+usernet) with a Win7 guest, and I do
>> not get an IP either. There is no traffic on the vlan (I attached a dump
>> device to verify). Looking closer, it seems PCI bar mapping is failing,
>> at least partially, see 'info pci'. I hope it's not yet another ACPI
>> issue. Fixing the polarity bug already forced me to dig way too deep
>> into this horrible domain.
> 
> Wow, very great. So is kvm working with q35?

Mostly. The key was to avoid that seabios does smm initialization as
that mode is not support by kvm. I also merged the q35 into qemu-kvm to
enable in-kernel irqchip support. That finally revealed the polarity
issues (only with win7 guests). I also posted a qemu ioapic patch to
make it polarity aware as well [1][2].

I also succeeded with passing through a PCIe host device. Nicely, the
full set capabilities showed up on the guest side this way. But GPU
pass-through did not improve this way (it rather regressed, yet unclear
why).

> 
> I had a quick look at your patches.
> With seabios patch of 94710189f5323034e00b510fe5a0865a7b576a9f,
> you ignored MCFG area.
> 
> (start = Q35_HOST_BRIDGE_PCIEXBAR_ADDR, size = 256MB) is used
> for MCFG (!= pci region), so it can't be used for PCI region.
> That's why 256M is added to s.
> And Q35_HOST_BRIDGE_PCIEXBAR_ADDR in dev-q35.h also needs to be adjusted.

Confused. Where was the PCI region located without my hack?

BTW, the PCI bar mapping failures of VGA or e1000 are independent of
that seabios commit. You should see them with your tree as well.

> 
> After pushing out pci id clean up and once they are accepted,
> I'll publish rebased/cleaned up one.

Note that I dropped "simply i440fx initialization". It was a premature
cleanup that caused regressions. The good news: I'm working on PAM/SMRAM
fixes that will include such a cleanup after removing the need for the
init function. The bad news: Those patches will force you to rebase
again (to break out the new PAM/SMRAM code).

Jan

[1] http://thread.gmane.org/gmane.comp.emulators.qemu/102459
[2] http://thread.gmane.org/gmane.comp.emulators.qemu/102460

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux