[Qemu-devel] [PATCH 00/26] q35 chipset support for native pci express support
This patch series adds basic q35 chipset support for native pci express support. Some bios related patches are still needed. For those who want to try it, the following repo is avaiable. (vgabios doesn't need patches, so use the upstream one) git clone http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu git clone http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/seabios Example: qemu-system-x86_64 ... -M pc_q35 -acpitable 'load_header,data=roms/seabios/src/q35-acpi-dsdt.aml The motivation is to support newer hardware features because piix chipset is very old. Especially I have PCI express in mind and this is the basic infrastructure for PCI express hot plug and PCI express native direct attach. I can boot Linux with PCIe MMCONFIG with APIC mode pci interrupt routing. I haven't tested other OSes. The patch series consist as following - Firstly, some PCI patches which introduce helper functions and so on. - Then, PC initialization related patches which simplifies pc board initialization, pc_init1(). - Thirdly, factoring out the logics which are common to the existing piix and q35. ie. smram, pam and acpi logic. - At last introduce q35 chipset emulator which is able to handle pci express natively. Thanks, Change from v7: - heavily reorganized and improved. - factoring out code duplication. - improved irq routing fully. Changes from split out piix specific part from pc emulator. V6 - rebased to 731c54f86988d3f28268f184fabfe9b2a32fb5d3 - PCIe MMCONFIG - pci bridge related fixes - chipset emulator works. - IOAPIC patches Changes from v5: - rebased 0.11.0-rc0 - changed qemu_system_powerdown_register() to call qemu_system_shutdown_request() if qemu_system_shutdown() is called before registering. Changes from v4: - fix version number. - rebased anthony's staging tree whose latest change set is 62969268f876c547ee64da6d60e0f363e0f1df75 Changes from v3: - move qemu_system_powerdown() in vl.c and more generic following the comment by Marcelo Tosatti acpi.c: make qemu_system_powerdown() piix independent. - define cmos_set_s3_resume_init() and cmos_set_s3_resume() in pc.c even if TARGET_I386 isn't defined following th ecommit by Paolo Bonzini pc.c: remove a global variable, RTCState *rtc_state. - minor compilation fixes Changes from v2: - clean up pc_pci_device_init() not to use unnecessary braces. Changes from v1: - make patches full bisectable - typo s/allocte/allocate/ - some minor fixes - dropped a merged patch Isaku Yamahata (26): pci: replace the magic, 256, for the maximum of slot pci: add opaque argument to pci_map_irq_fn pci: introduce pci_swizzle_map_irq_fn() for standardized interrupt pin swizzle pci: add accessor function to get irq levels piix_pci: eliminate PIIX3State::pci_irq_levels pci_bridge: add helper function to convert PCIBridge into PCIDevice pci/p2pbr: generic pci p2p bridge apb_pci: simplify apb_pci.c by using pci_p2pbr dec_pci: simplify dec_pci.c by using pci_p2pbr ide/ahci/ich: use qdev.reset ahci: add ide device initialization helper usb/uhci: generalize initialization usb/uhci: add ich9 usb uhci id's device ide: consolidate drive_get(IF_IDE) smbus_eeprom: consolidate smbus eeprom creation pc, pc_piix: split out allocating isa irqs pc, pc_piix: split out pc nic initialization ioapic: move ioapic_init() from pc_piix.c to pc.c pc/piix_pci: factor out smram/pam logic pc, i440fx: simply i440fx initialization acpi, acpi_piix: factor out PM_TMR logic acpi, acpi_piix: factor out PM1a EVT logic acpi, acpi_piix: factor out PM1_CNT logic acpi, acpi_piix: factor out GPE logic pci_ids: add intel 82801BA pci-to-pci bridge id and PCI_CLASS_SERIAL_SMBUS pc q35 based chipset emulator Makefile.objs |2 +- Makefile.target|3 +- hw/acpi.c | 197 hw/acpi.h | 68 hw/acpi_ich9.c | 314 +++ hw/acpi_ich9.h | 53 hw/acpi_piix4.c| 220 -- hw/apb_pci.c | 67 ++--- hw/bonito.c|2 +- hw/dec_pci.c | 51 +--- hw/grackle_pci.c |2 +- hw/gt64xxx.c |2 +- hw/ide.h |6 + hw/ide/ahci.c | 15 + hw/ide/core.c | 14 + hw/ide/ich.c |9 +- hw/mips_fulong2e.c | 18 +- hw/mips_malta.c| 22 +-- hw/mips_r4k.c | 10 +- hw/pam.c | 128 hw/pam.h | 96 ++ hw/pc.c| 47 +++- hw/pc.h|7 +- hw/pc_piix.c | 64 + hw/pc_q35.c| 359 + hw/pci.c | 27 ++- hw/pci.h |6 +- hw/pci_bridge.c|6 + hw/pci_bridge.h|1 + hw/pci_ids.h | 17 + hw/pci_internals.h |2 +- hw/pci_p2pbr.c | 151 + hw/pci_p2pbr.h | 61 hw/piix_pci.c | 117 +++- hw/ppc4xx_pci.c|2 +- hw/ppc_newworld.c | 11 +- hw/ppc_oldworld.c | 11 +- hw/ppc_prep.c | 10 +- h
Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci express support
On Tue, Apr 19, 2011 at 04:28:01PM +0800, Hu Tao wrote: > On Wed, Mar 16, 2011 at 06:29:11PM +0900, Isaku Yamahata wrote: > > This patch series adds basic q35 chipset support for native pci express > > support. Some bios related patches are still needed. > > For those who want to try it, the following repo is avaiable. > > (vgabios doesn't need patches, so use the upstream one) > > > > git clone http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu > > git clone http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/seabios > > Hi, > > When I visit the links, the pages say 'You dont have permission'. Could > you make these git-repos avaiable again? Thanks in advance. The link is not for human-reading. Just issue the git command. -- yamahata
Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci express support
On Tue, Apr 19, 2011 at 05:51:27PM +0900, Isaku Yamahata wrote: > On Tue, Apr 19, 2011 at 04:28:01PM +0800, Hu Tao wrote: > > On Wed, Mar 16, 2011 at 06:29:11PM +0900, Isaku Yamahata wrote: > > > This patch series adds basic q35 chipset support for native pci express > > > support. Some bios related patches are still needed. > > > For those who want to try it, the following repo is avaiable. > > > (vgabios doesn't need patches, so use the upstream one) > > > > > > git clone http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu > > > git clone http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/seabios > > > > Hi, > > > > When I visit the links, the pages say 'You dont have permission'. Could > > you make these git-repos avaiable again? Thanks in advance. > > The link is not for human-reading. Just issue the git command. Done. Thanks:) > -- > yamahata
Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci express support
On Wed, Mar 16, 2011 at 06:29:11PM +0900, Isaku Yamahata wrote: > This patch series adds basic q35 chipset support for native pci express > support. Some bios related patches are still needed. > For those who want to try it, the following repo is avaiable. > (vgabios doesn't need patches, so use the upstream one) > > git clone http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu > git clone http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/seabios Hi, When I visit the links, the pages say 'You dont have permission'. Could you make these git-repos avaiable again? Thanks in advance.
Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci express support
I forgot to changet its HEAD. Now it's fixed. So please change the branch manually or clone the repo again. On Tue, Apr 19, 2011 at 04:58:32PM +0800, Hu Tao wrote: > On Tue, Apr 19, 2011 at 05:51:27PM +0900, Isaku Yamahata wrote: > > On Tue, Apr 19, 2011 at 04:28:01PM +0800, Hu Tao wrote: > > > On Wed, Mar 16, 2011 at 06:29:11PM +0900, Isaku Yamahata wrote: > > > > This patch series adds basic q35 chipset support for native pci express > > > > support. Some bios related patches are still needed. > > > > For those who want to try it, the following repo is avaiable. > > > > (vgabios doesn't need patches, so use the upstream one) > > > > > > > > git clone http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu > > > > git clone > > > > http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/seabios > > > > > > Hi, > > > > > > When I visit the links, the pages say 'You dont have permission'. Could > > > you make these git-repos avaiable again? Thanks in advance. > > > > The link is not for human-reading. Just issue the git command. > > Done. Thanks:) > > > -- > > yamahata > -- yamahata
Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci express support
Something is still wrong, I get the following errors now: : error: cannot unpack fffd440d2ca664a03ee83eabc00107eaf74d7af4 from /users/akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack error: Unable to find ad620c29c2da573e3a5f13f5b1eb2694fee64cfb under http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu/ Cannot obtain needed none ad620c29c2da573e3a5f13f5b1eb2694fee64cfb while processing commit . rm: cannot remove directory `/users/akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/clone-tmp': Directory not empty Adnan _ From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] To: Hu Tao [mailto:hu...@cn.fujitsu.com], Adnan Khaleel [mailto:ad...@khaleel.us] Cc: qemu-devel@nongnu.org Sent: Wed, 20 Apr 2011 17:46:44 -0500 Subject: Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci express support I forgot to changet its HEAD. Now it's fixed. So please change the branch manually or clone the repo again. On Tue, Apr 19, 2011 at 04:58:32PM +0800, Hu Tao wrote: > On Tue, Apr 19, 2011 at 05:51:27PM +0900, Isaku Yamahata wrote: > > On Tue, Apr 19, 2011 at 04:28:01PM +0800, Hu Tao wrote: > > > On Wed, Mar 16, 2011 at 06:29:11PM +0900, Isaku Yamahata wrote: > > > > This patch series adds basic q35 chipset support for native pci express > > > > support. Some bios related patches are still needed. > > > > For those who want to try it, the following repo is avaiable. > > > > (vgabios doesn't need patches, so use the upstream one) > > > > > > > > git clone http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu > > > > git clone http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/seabios > > > > > > Hi, > > > > > > When I visit the links, the pages say 'You dont have permission'. Could > > > you make these git-repos avaiable again? Thanks in advance. > > > > The link is not for human-reading. Just issue the git command. > > Done. Thanks:) > > > -- > > yamahata > -- yamahata
Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci?express support
Okay. Can you please try git clone again? On Wed, Apr 20, 2011 at 06:41:56PM -0500, Adnan Khaleel wrote: > Something is still wrong, > > I get the following errors now: > > : > error: cannot unpack fffd440d2ca664a03ee83eabc00107eaf74d7af4 from /users/ > akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/ > pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack > error: Unable to find ad620c29c2da573e3a5f13f5b1eb2694fee64cfb under http:// > people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu/ > Cannot obtain needed none ad620c29c2da573e3a5f13f5b1eb2694fee64cfb > while processing commit . > rm: cannot remove directory > `/users/akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/ > qemu/.git/clone-tmp': Directory not empty > > Adnan > > > ━ > From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] > To: Hu Tao [mailto:hu...@cn.fujitsu.com], Adnan Khaleel > [mailto:ad...@khaleel.us] > Cc: qemu-devel@nongnu.org > Sent: Wed, 20 Apr 2011 17:46:44 -0500 > Subject: Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci > express support > > I forgot to changet its HEAD. Now it's fixed. > So please change the branch manually or clone the repo again. > > On Tue, Apr 19, 2011 at 04:58:32PM +0800, Hu Tao wrote: > > On Tue, Apr 19, 2011 at 05:51:27PM +0900, Isaku Yamahata wrote: > > > On Tue, Apr 19, 2011 at 04:28:01PM +0800, Hu Tao wrote: > > > > On Wed, Mar 16, 2011 at 06:29:11PM +0900, Isaku Yamahata wrote: > > > > > This patch series adds basic q35 chipset support for native pci > express > > > > > support. Some bios related patches are still needed. > > > > > For those who want to try it, the following repo is avaiable. > > > > > (vgabios doesn't need patches, so use the upstream one) > > > > > > > > > > git clone http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/ > qemu > > > > > git clone http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/ > seabios > > > > > > > > Hi, > > > > > > > > When I visit the links, the pages say 'You dont have permission'. > Could > > > > you make these git-repos avaiable again? Thanks in advance. > > > > > > The link is not for human-reading. Just issue the git command. > > > > Done. Thanks:) > > > > > -- > > > yamahata > > > > -- > yamahata > -- yamahata
Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci?express support
Hi Yamahata I'm wondering if there're any PCI-e device emulated by QEmu? And I think the hogplug patches are in this repo, right? Thanks, Gui Isaku Yamahata wrote: > Okay. Can you please try git clone again? > > On Wed, Apr 20, 2011 at 06:41:56PM -0500, Adnan Khaleel wrote: >> Something is still wrong, >> >> I get the following errors now: >> >> : >> error: cannot unpack fffd440d2ca664a03ee83eabc00107eaf74d7af4 from /users/ >> akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/ >> pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack >> error: Unable to find ad620c29c2da573e3a5f13f5b1eb2694fee64cfb under http:// >> people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu/ >> Cannot obtain needed none ad620c29c2da573e3a5f13f5b1eb2694fee64cfb >> while processing commit . >> rm: cannot remove directory >> `/users/akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/ >> qemu/.git/clone-tmp': Directory not empty >> >> Adnan >> >> >> ━ >> From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] >> To: Hu Tao [mailto:hu...@cn.fujitsu.com], Adnan Khaleel >> [mailto:ad...@khaleel.us] >> Cc: qemu-devel@nongnu.org >> Sent: Wed, 20 Apr 2011 17:46:44 -0500 >> Subject: Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native >> pci >> express support >> >> I forgot to changet its HEAD. Now it's fixed. >> So please change the branch manually or clone the repo again. >> >> On Tue, Apr 19, 2011 at 04:58:32PM +0800, Hu Tao wrote: >> > On Tue, Apr 19, 2011 at 05:51:27PM +0900, Isaku Yamahata wrote: >> > > On Tue, Apr 19, 2011 at 04:28:01PM +0800, Hu Tao wrote: >> > > > On Wed, Mar 16, 2011 at 06:29:11PM +0900, Isaku Yamahata wrote: >> > > > > This patch series adds basic q35 chipset support for native pci >> express >> > > > > support. Some bios related patches are still needed. >> > > > > For those who want to try it, the following repo is avaiable. >> > > > > (vgabios doesn't need patches, so use the upstream one) >> > > > > >> > > > > git clone >> http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/ >> qemu >> > > > > git clone >> http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/ >> seabios >> > > > >> > > > Hi, >> > > > >> > > > When I visit the links, the pages say 'You dont have permission'. >> Could >> > > > you make these git-repos avaiable again? Thanks in advance. >> > > >> > > The link is not for human-reading. Just issue the git command. >> > >> > Done. Thanks:) >> > >> > > -- >> > > yamahata >> > >> >> -- >> yamahata >> >
Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci?express support
I still get the same error: akhaleel@depot5 qemu_0.14_q35 $ git clone http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu Getting alternates list for http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu/ Getting pack list for http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu/ Getting index for pack c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557 Getting pack c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557 which contains ad620c29c2da573e3a5f13f5b1eb2694fee64cfb error: cannot unpack 000198da6f46c240e46c562caf57b14268d27597 from /users/akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack : : error: cannot unpack fffd440d2ca664a03ee83eabc00107eaf74d7af4 from /users/akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack error: Unable to find ad620c29c2da573e3a5f13f5b1eb2694fee64cfb under http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu/ Cannot obtain needed none ad620c29c2da573e3a5f13f5b1eb2694fee64cfb while processing commit . rm: cannot remove directory `/users/akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/clone-tmp': Directory not empty _ From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] To: Adnan Khaleel [mailto:ad...@khaleel.us] Cc: Hu Tao [mailto:hu...@cn.fujitsu.com], qemu-devel@nongnu.org Sent: Wed, 20 Apr 2011 21:07:46 -0500 Subject: Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci?express support Okay. Can you please try git clone again? On Wed, Apr 20, 2011 at 06:41:56PM -0500, Adnan Khaleel wrote: > Something is still wrong, > > I get the following errors now: > > : > error: cannot unpack fffd440d2ca664a03ee83eabc00107eaf74d7af4 from /users/ > akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/ > pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack > error: Unable to find ad620c29c2da573e3a5f13f5b1eb2694fee64cfb under http:// > people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu/ > Cannot obtain needed none ad620c29c2da573e3a5f13f5b1eb2694fee64cfb > while processing commit . > rm: cannot remove directory `/users/akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/ > qemu/.git/clone-tmp': Directory not empty > > Adnan > > > ━ > From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] > To: Hu Tao [mailto:hu...@cn.fujitsu.com], Adnan Khaleel > [mailto:ad...@khaleel.us] > Cc: qemu-devel@nongnu.org > Sent: Wed, 20 Apr 2011 17:46:44 -0500 > Subject: Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci > express support > > I forgot to changet its HEAD. Now it's fixed. > So please change the branch manually or clone the repo again. > > On Tue, Apr 19, 2011 at 04:58:32PM +0800, Hu Tao wrote: > > On Tue, Apr 19, 2011 at 05:51:27PM +0900, Isaku Yamahata wrote: > > > On Tue, Apr 19, 2011 at 04:28:01PM +0800, Hu Tao wrote: > > > > On Wed, Mar 16, 2011 at 06:29:11PM +0900, Isaku Yamahata wrote: > > > > > This patch series adds basic q35 chipset support for native pci > express > > > > > support. Some bios related patches are still needed. > > > > > For those who want to try it, the following repo is avaiable. > > > > > (vgabios doesn't need patches, so use the upstream one) > > > > > > > > > > git clone http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/ > qemu > > > > > git clone http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/ > seabios > > > > > > > > Hi, > > > > > > > > When I visit the links, the pages say 'You dont have permission'. > Could > > > > you make these git-repos avaiable again? Thanks in advance. > > > > > > The link is not for human-reading. Just issue the git command. > > > > Done. Thanks:) > > > > > -- > > > yamahata > > > > -- > yamahata > -- yamahata
Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native?pci?express support
git clone works for me. Hmmm git installation issue? My git is $ git --version git version 1.7.1.1 thanks, On Thu, Apr 21, 2011 at 11:12:37AM -0500, Adnan Khaleel wrote: > I still get the same error: > > akhaleel@depot5 qemu_0.14_q35 $ git clone > http://people.valinux.co.jp/~yamahata > /qemu/q35/20110316/qemu > Getting alternates list for http://people.valinux.co.jp/~yamahata/qemu/q35/ > 20110316/qemu/ > Getting pack list for http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/ > qemu/ > Getting index for pack c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557 > Getting pack c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557 > which contains ad620c29c2da573e3a5f13f5b1eb2694fee64cfb > error: cannot unpack 000198da6f46c240e46c562caf57b14268d27597 from /users/ > akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/ > pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack > : > : > error: cannot unpack fffd440d2ca664a03ee83eabc00107eaf74d7af4 from /users/ > akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/ > pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack > error: Unable to find ad620c29c2da573e3a5f13f5b1eb2694fee64cfb under http:// > people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu/ > Cannot obtain needed none ad620c29c2da573e3a5f13f5b1eb2694fee64cfb > while processing commit . > rm: cannot remove directory > `/users/akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/ > qemu/.git/clone-tmp': Directory not empty > > > ━ > From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] > To: Adnan Khaleel [mailto:ad...@khaleel.us] > Cc: Hu Tao [mailto:hu...@cn.fujitsu.com], qemu-devel@nongnu.org > Sent: Wed, 20 Apr 2011 21:07:46 -0500 > Subject: Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native > pci? > express support > > Okay. Can you please try git clone again? > > On Wed, Apr 20, 2011 at 06:41:56PM -0500, Adnan Khaleel wrote: > > Something is still wrong, > > > > I get the following errors now: > > > > : > > error: cannot unpack fffd440d2ca664a03ee83eabc00107eaf74d7af4 from > /users > / > > akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/ > > pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack > > error: Unable to find ad620c29c2da573e3a5f13f5b1eb2694fee64cfb under > http:// > > people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu/ > > Cannot obtain needed none ad620c29c2da573e3a5f13f5b1eb2694fee64cfb > > while processing commit . > > rm: cannot remove directory `/users/akhaleel/akhaleel/MergeSpace/ > qemu_0.14_q35/ > > qemu/.git/clone-tmp': Directory not empty > > > > Adnan > > > > > > ? > > From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] > > To: Hu Tao [mailto:hu...@cn.fujitsu.com], Adnan Khaleel > > [mailto:ad...@khaleel.us] > > Cc: qemu-devel@nongnu.org > > Sent: Wed, 20 Apr 2011 17:46:44 -0500 > > Subject: Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native > pci > > express support > > > > I forgot to changet its HEAD. Now it's fixed. > > So please change the branch manually or clone the repo again. > > > > On Tue, Apr 19, 2011 at 04:58:32PM +0800, Hu Tao wrote: > > > On Tue, Apr 19, 2011 at 05:51:27PM +0900, Isaku Yamahata wrote: > > > > On Tue, Apr 19, 2011 at 04:28:01PM +0800, Hu Tao wrote: > > > > > On Wed, Mar 16, 2011 at 06:29:11PM +0900, Isaku Yamahata wrote: > > > > > > This patch series adds basic q35 chipset support for native pci > > express > > > > > > support. Some bios related patches are still needed. > > > > > > For those who want to try it, the following repo is avaiable. > > > > > > (vgabios doesn't need patches, so use the upstream one) > > > > > > > > > > > > git clone > http://people.valinux.co.jp/~yamahata/qemu/q35/20110316 > / > > qemu > > > > > > git clone > http://people.valinux.co.jp/~yamahata/qemu/q35/20110316 > / > > seabios > > > > > > > > > > Hi, > > > > > > > > > > When I visit the links, the pages say 'You dont have permission'. > > Could > > > > > you make these git-repos avaiable again? Thanks in advance. > > > > > > > > The link is not for human-reading. Just issue the git command. > > > > > > Done. Thanks:) > > > > > > > -- > > > > yamahata > > > > > > > -- > > yamahata > > > > -- > yamahata > -- yamahata
Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native?pci?express support
Yes, it was a git version conflict. Thanks. Adnan _ From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] To: Adnan Khaleel [mailto:ad...@khaleel.us] Cc: Hu Tao [mailto:hu...@cn.fujitsu.com], qemu-devel@nongnu.org Sent: Thu, 21 Apr 2011 11:38:36 -0500 Subject: Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native?pci?express support git clone works for me. Hmmm git installation issue? My git is $ git --version git version 1.7.1.1 thanks, On Thu, Apr 21, 2011 at 11:12:37AM -0500, Adnan Khaleel wrote: > I still get the same error: > > akhaleel@depot5 qemu_0.14_q35 $ git clone http://people.valinux.co.jp/~yamahata > /qemu/q35/20110316/qemu > Getting alternates list for http://people.valinux.co.jp/~yamahata/qemu/q35/ > 20110316/qemu/ > Getting pack list for http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/ > qemu/ > Getting index for pack c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557 > Getting pack c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557 > which contains ad620c29c2da573e3a5f13f5b1eb2694fee64cfb > error: cannot unpack 000198da6f46c240e46c562caf57b14268d27597 from /users/ > akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/ > pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack > : > : > error: cannot unpack fffd440d2ca664a03ee83eabc00107eaf74d7af4 from /users/ > akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/ > pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack > error: Unable to find ad620c29c2da573e3a5f13f5b1eb2694fee64cfb under http:// > people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu/ > Cannot obtain needed none ad620c29c2da573e3a5f13f5b1eb2694fee64cfb > while processing commit . > rm: cannot remove directory `/users/akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/ > qemu/.git/clone-tmp': Directory not empty > > > ━ > From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] > To: Adnan Khaleel [mailto:ad...@khaleel.us] > Cc: Hu Tao [mailto:hu...@cn.fujitsu.com], qemu-devel@nongnu.org > Sent: Wed, 20 Apr 2011 21:07:46 -0500 > Subject: Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci? > express support > > Okay. Can you please try git clone again? > > On Wed, Apr 20, 2011 at 06:41:56PM -0500, Adnan Khaleel wrote: > > Something is still wrong, > > > > I get the following errors now: > > > > : > > error: cannot unpack fffd440d2ca664a03ee83eabc00107eaf74d7af4 from /users > / > > akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/ > > pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack > > error: Unable to find ad620c29c2da573e3a5f13f5b1eb2694fee64cfb under > http:// > > people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu/ > > Cannot obtain needed none ad620c29c2da573e3a5f13f5b1eb2694fee64cfb > > while processing commit . > > rm: cannot remove directory `/users/akhaleel/akhaleel/MergeSpace/ > qemu_0.14_q35/ > > qemu/.git/clone-tmp': Directory not empty > > > > Adnan > > > > > > ? > > From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] > > To: Hu Tao [mailto:hu...@cn.fujitsu.com], Adnan Khaleel > > [mailto:ad...@khaleel.us] > > Cc: qemu-devel@nongnu.org > > Sent: Wed, 20 Apr 2011 17:46:44 -0500 > > Subject: Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native > pci > > express support > > > > I forgot to changet its HEAD. Now it's fixed. > > So please change the branch manually or clone the repo again. > > > > On Tue, Apr 19, 2011 at 04:58:32PM +0800, Hu Tao wrote: > > > On Tue, Apr 19, 2011 at 05:51:27PM +0900, Isaku Yamahata wrote: > > > > On Tue, Apr 19, 2011 at 04:28:01PM +0800, Hu Tao wrote: > > > > > On Wed, Mar 16, 2011 at 06:29:11PM +0900, Isaku Yamahata wrote: > > > > > > This patch series adds basic q35 chipset support for native pci > > express > > > > > > support. Some bios related patches are still needed. > > > > > > For those who want to try it, the following repo is avaiable. > > > > > > (vgabios doesn't need patches, so use the upstream one) > > > > > > > > > > > > git clone
Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci?express support
I found one problem in the bios config that was preventing the BIOS from seeing the MBR. The AHCI support was not enabled. To fix this change seabios/.config CONFIG_AHCI=y The system now loads the boot loader and does some device initialization. However, the boot gets stuck when the OS partition cannot be seen and I get a message saying "Waiting for device /dev/disk/by-uuid/ to appear: Could not find /dev/disk/by-uuid/" Any ideas whats happening here? AK _ From: Adnan Khaleel [mailto:ad...@khaleel.us] To: ad...@khaleel.us Cc: Hu Tao [mailto:hu...@cn.fujitsu.com] Sent: Tue, 10 May 2011 11:43:33 -0500 Subject: Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci?express support Hi Hu, Have you managed to get this working? Adnan _ From: Adnan Khaleel [mailto:ad...@khaleel.us] To: Isaku Yamahata [mailto:yamah...@valinux.co.jp] Cc: Hu Tao [mailto:hu...@cn.fujitsu.com], qemu-devel@nongnu.org Sent: Thu, 21 Apr 2011 11:12:37 -0500 Subject: Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci?express support I still get the same error: akhaleel@depot5 qemu_0.14_q35 $ git clone http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu Getting alternates list for http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu/ Getting pack list for http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu/ Getting index for pack c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557 Getting pack c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557 which contains ad620c29c2da573e3a5f13f5b1eb2694fee64cfb error: cannot unpack 000198da6f46c240e46c562caf57b14268d27597 from /users/akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack : : error: cannot unpack fffd440d2ca664a03ee83eabc00107eaf74d7af4 from /users/akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack error: Unable to find ad620c29c2da573e3a5f13f5b1eb2694fee64cfb under http://people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu/ Cannot obtain needed none ad620c29c2da573e3a5f13f5b1eb2694fee64cfb while processing commit . rm: cannot remove directory `/users/akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/clone-tmp': Directory not empty _ From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] To: Adnan Khaleel [mailto:ad...@khaleel.us] Cc: Hu Tao [mailto:hu...@cn.fujitsu.com], qemu-devel@nongnu.org Sent: Wed, 20 Apr 2011 21:07:46 -0500 Subject: Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci?express support Okay. Can you please try git clone again? On Wed, Apr 20, 2011 at 06:41:56PM -0500, Adnan Khaleel wrote: > Something is still wrong, > > I get the following errors now: > > : > error: cannot unpack fffd440d2ca664a03ee83eabc00107eaf74d7af4 from /users/ > akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/qemu/.git/objects/pack/ > pack-c0c6d1b7fc8ae79abf99bfb6a402b50e2ec98557.pack > error: Unable to find ad620c29c2da573e3a5f13f5b1eb2694fee64cfb under http:// > people.valinux.co.jp/~yamahata/qemu/q35/20110316/qemu/ > Cannot obtain needed none ad620c29c2da573e3a5f13f5b1eb2694fee64cfb > while processing commit . > rm: cannot remove directory `/users/akhaleel/akhaleel/MergeSpace/qemu_0.14_q35/ > qemu/.git/clone-tmp': Directory not empty > > Adnan > > > ━ > From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] > To: Hu Tao [mailto:hu...@cn.fujitsu.com], Adnan Khaleel > [mailto:ad...@khaleel.us] > Cc: qemu-devel@nongnu.org > Sent: Wed, 20 Apr 2011 17:46:44 -0500 > Subject: Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci > express support > > I forgot to changet its HEAD. Now it's fixed. > So please change the branch manually or clone the repo again. > > On Tue, Apr 19, 2011 at 04:58:32PM +0800, Hu Tao wrote: > > On Tue, Apr 19, 2011 at 05:51:27PM +0900, Isaku Yamahata wrote: > > > On Tue, Apr 19, 2011 at 04:28:01PM +0800, Hu Tao wrote: > > > > On Wed, Mar 16, 2011 at 06:29:11PM +0900, Isaku Yamahata wrote: > > > > > This patch series adds basic q35 chipset support for native pci > express > > > > > support. Some bios related patches are still needed. > > > > > For those who want to try it, the following repo is avaiable. > > > > > (vgabios doesn't need patches, so use the upstream one) > > > > > > > > > > git clone http://people.valinux.co.jp/~yamahata/q
Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci express support
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? Thanks AK
Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci express support
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. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci express support
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
Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci express support
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
Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci express support
On Tue, May 17, 2011 at 04:21:11PM +0200, Jan Kiszka wrote: > 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). Interesting. > > 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? I mean the following patch on top of your tree. At the moment, I only compiled it. diff --git a/src/dev-q35.c b/src/dev-q35.c index c0aa057..eee50c4 100644 --- a/src/dev-q35.c +++ b/src/dev-q35.c @@ -36,13 +36,15 @@ void mch_mem_addr_init(u16 bdf, void *arg) /* * BUILD_MAX_HIGHMEM == 0xc000 - * [0xc000 , 0xf000 ) for MCFG - * 4GB - 1GB, 4GB - 256MB + * [0xc000 , 0xd000 ) for MCFG + * 3GB ,3GB + 256MB + * [0xd000 , 0xf000 ) for pci memory region + * 3GB + 256MB, 4GB - 256MB * [0xf000 , 0xfec0 ) for DMI interface(subtractive decode) * 4GB - 256MB, 4GB - 20MB */ -s = BUILD_MAX_HIGHMEM; -e = s + 128 * 1024 * 1024 - 1 + 512 * 1024 * 1024; +s = Q35_HOST_BRIDGE_PCIEXBAR_ADDR + Q35_HOST_BRIDGE_PCIEXBAR_SIZE; +e = s + 512 * 1024 * 1024 - 1; pci_region_init(addr->pci_bios_mem_region, s, e); /* pci_bios_mem_addr + */ diff --git a/src/dev-q35.h b/src/dev-q35.h index f5cae62..0d83dba 100644 --- a/src/dev-q35.h +++ b/src/dev-q35.h @@ -8,7 +8,7 @@ #define Q35_HOST_BRIDGE_SMRAM 0x9d #define Q35_HOST_BRIDGE_PCIEXBAR0x60 #define Q35_HOST_BRIDGE_PCIEXBAR_SIZE (256 * 1024 * 1024) -#define Q35_HOST_BRIDGE_PCIEXBAR_ADDR 0xe000 +#define Q35_HOST_BRIDGE_PCIEXBAR_ADDR BUILD_MAX_HIGHMEM #define Q35_HOST_BRIDGE_PCIEXBAREN ((u64)1) #define Q35_HOST_PCIE_PCI_SEGMENT 0 #define Q35_HOST_PCIE_START_BUS_NUMBER 0 > 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. Hmm, I'll look into it. > > 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). Please keep CCed on me. -- yamahata
Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci express support
On 2011-05-17 09:15, 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.
FWIW, patch below fixes UHCI here. I suspect more bugs in this area as
accessing the chip_config registers appears to rely on the host being
little endian (direct memcpy).
In contrast, the PCI mapping issue turned out to be a read herring. The
unmapped regions were actually ROM BARs which are usually unmapped. And
the network issues were related to an outdated DSDT. Somehow rebuilding
Seabios did not always properly regenerate them, so my polarity fixes
were not inluded. Haven't looked into details, but deleting out/ and
src/*.hex resolved that.
I'll have to put this topic aside for now as it looks like we don't
depend on it for PCIe pass-through. Still, it's a cool thing, and I
would be happy to find it upstream soon!
Jan
--8<---
From: Jan Kiszka
Subject: [PATCH] q35: Fix irr initialization for slots 25..31
This was totally off: The CC registers are 16 bit (stored as little
endian), their offsets run in reverse order, and D26IR as well as D25IR
have 4 bytes offset to their successors.
Signed-off-by: Jan Kiszka
---
hw/q35.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/hw/q35.c b/hw/q35.c
index a06ea7d..0ab8532 100644
--- a/hw/q35.c
+++ b/hw/q35.c
@@ -424,14 +424,18 @@ static void ich9_cc_update_ir(uint8_t irr[PCI_NUM_PINS],
uint32_t ir)
static void ich9_cc_update(ICH9_LPCState *lpc)
{
int slot;
-int reg_offset;
+int reg;
int intx;
/* D{25 - 31}IR, but D30IR is read only to 0. */
-for (slot = 25, reg_offset = 0; slot < 32; slot++, reg_offset++) {
+for (slot = 31, reg = ICH9_CC_D31IR; slot >= 25; slot--, reg += 2) {
if (slot != 30) {
ich9_cc_update_ir(lpc->irr[slot],
- lpc->chip_config[ICH9_CC_D31IR + reg_offset]);
+ lpc->chip_config[reg] |
+ (uint32_t)lpc->chip_config[reg + 1] << 8);
+}
+if (slot <= 27) {
+reg += 2;
}
}
--
1.7.1
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci express support
On Wed, May 25, 2011 at 09:15:55AM +0200, Jan Kiszka wrote:
> FWIW, patch below fixes UHCI here. I suspect more bugs in this area as
> accessing the chip_config registers appears to rely on the host being
> little endian (direct memcpy).
>
> In contrast, the PCI mapping issue turned out to be a read herring. The
> unmapped regions were actually ROM BARs which are usually unmapped. And
> the network issues were related to an outdated DSDT. Somehow rebuilding
> Seabios did not always properly regenerate them, so my polarity fixes
> were not inluded. Haven't looked into details, but deleting out/ and
> src/*.hex resolved that.
Good catch. I queued it in my repo.
>
> I'll have to put this topic aside for now as it looks like we don't
> depend on it for PCIe pass-through. Still, it's a cool thing, and I
> would be happy to find it upstream soon!
>
> Jan
>
> --8<---
>
> From: Jan Kiszka
> Subject: [PATCH] q35: Fix irr initialization for slots 25..31
>
> This was totally off: The CC registers are 16 bit (stored as little
> endian), their offsets run in reverse order, and D26IR as well as D25IR
> have 4 bytes offset to their successors.
>
> Signed-off-by: Jan Kiszka
> ---
> hw/q35.c | 10 +++---
> 1 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/hw/q35.c b/hw/q35.c
> index a06ea7d..0ab8532 100644
> --- a/hw/q35.c
> +++ b/hw/q35.c
> @@ -424,14 +424,18 @@ static void ich9_cc_update_ir(uint8_t
> irr[PCI_NUM_PINS], uint32_t ir)
> static void ich9_cc_update(ICH9_LPCState *lpc)
> {
> int slot;
> -int reg_offset;
> +int reg;
> int intx;
>
> /* D{25 - 31}IR, but D30IR is read only to 0. */
> -for (slot = 25, reg_offset = 0; slot < 32; slot++, reg_offset++) {
> +for (slot = 31, reg = ICH9_CC_D31IR; slot >= 25; slot--, reg += 2) {
> if (slot != 30) {
> ich9_cc_update_ir(lpc->irr[slot],
> - lpc->chip_config[ICH9_CC_D31IR + reg_offset]);
> + lpc->chip_config[reg] |
> + (uint32_t)lpc->chip_config[reg + 1] << 8);
> +}
> +if (slot <= 27) {
> +reg += 2;
> }
> }
>
> --
> 1.7.1
>
--
yamahata
