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
