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

[Isaku Yamahata]

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?

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.

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