Re: [Qemu-devel] Single 64bit memory transaction instead of two 32bit memory transaction
Is there a patch for the new MemoryRegion API? At least for now, I need to be able to issue a single 64, 128 or 256bit transaction to a particular IO device. Is there a way I can do this now as a temp solution? I don't mind coalescing the bytes as they are issued by Qemu but I have no way to know that they're from the same instruction. Any pointers? Thanks, AK _ From: Richard Henderson [mailto:r...@twiddle.net] To: ad...@khaleel.us Cc: qemu-devel@nongnu.org, blauwir...@gmail.com Sent: Fri, 02 Sep 2011 20:53:30 -0500 Subject: Re: [Qemu-devel] Single 64bit memory transaction instead of two 32bit memory transaction On 09/02/2011 12:46 AM, Adnan Khaleel wrote: Is there anyway we can prevent Qemu breaking up 64,128 and 256bit XMM or YMM instructions into smaller chunks and have them issue as a single transaction of the original width? Not yet. The new MemoryRegion API will allow this, but we need to convert all the devices first, then rip out the old API. It's a work in progress... r~
Re: [Qemu-devel] Single 64bit memory transaction instead of two 32bit memory transaction
I had asked this question a year ago and I managed to have a temporary work
around for doing a single 64bit read/write operations but now I'm looking for a
more complete solution.
Is there anyway we can prevent Qemu breaking up 64,128 and 256bit XMM or YMM
instructions into smaller chunks and have them issue as a single transaction of
the original width? This is not an issue for reading/writing to the processor's
memory but for an I/O device attached over PCI. One hack is that I could
accumulate the writes as they're happening but I have no way of knowing if the
writes are from the same instruction.
Thanks
AK
Re: [Qemu-devel] Single 64bit memory transaction instead of two 32bit me
_
From: Blue Swirl
Subject: Re: [Qemu-devel] Single 64bit memory transaction instead of
two 32bit memory transaction.
Date: Tue, 9 Nov 2010 17:57:28 +
Legacy. Patches have been submitted to add 64 bit IO handlers. But there
have been other discussions to change the whole I/O interface.
On Mon, Nov 8, 2010 at 11:27 PM, Adnan Khaleel address@hidden wrote: In
the file exec.c:
The memory Write/Read functions are declared as an array of 4 entries
where the index values of 0,1,2 correspond to 8,16 and 32bit write and
read functions respectively.
CPUWriteMemoryFunc *io_mem_write[IO_MEM_NB_ENTRIES][4];
CPUReadMemoryFunc *io_mem_read[IO_MEM_NB_ENTRIES][4];
Is there any reason why we can't extend this to include 64bit writes and
read by increasing the array size? This is because 64bit reads are
currently handled as two separate 32bit reads for eg: sommu_template.h
static inline DATA_TYPE glue(io_read, SUFFIX)(target_phys_addr_t physaddr,
target_ulong addr,
void *retaddr)
{
:
res = io_mem_read[index][2](io_mem_opaque[index], physaddr);
res |= (uint64_t)io_mem_read[index][2](io_mem_opaque[index], physaddr +
4) 32;
:
return res;
}
I'm sure this is happening in other places as well. Is there a reason for
this or could we arbitrarily increase this (within limits ofcourse)?
Thanks
AK
[Qemu-devel] When will the Q35 chipset be merged into Qemu mainstream
PCI express support has been made available for quite sometime now with patches from Isaku Yamahata for the Q35 chipset for Qemu 0.12 and then for Qemu 0.14. However, Qemu 0.15 has been released but support for the Q35 chipset is still not officially included. At what point will Qemu merge the Q35 chipset code for PCIexpress? AK
[Qemu-devel] Calling a function every N instructions or simulated cpu cycles
I'm using Qemu along with a network simulator and I need to perform a
synchronization every N cycles. What is the best way to do this in Qemu so that
I can call a function periodically say every N instructions or simulated cpu
cycles?
Currently I have a routine in main_loop() in vl.c but it seems like my
synchronization routine is not called consistently. I'm showing the code
snippet below to give you a better idea.
#define NETWORK_SYNC_CPU_CYCLES 10
static void main_loop(void)
{
int r;
#ifdef NETWORK_COSIM
int check_counter = NETWORK_SYNC_CPU_CYCLES; //
#endif
qemu_main_loop_start();
for (;;) {
do {
bool nonblocking = false;
#ifdef NETWORK_COSIM
if (--check_counter == 0)
network_sync();
#endif
:
:
}
Thanks
Adnan
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
[Qemu-devel] Debug Qemu dhcpd
I'm using Isaku Yamahata's q35 chipset model in Qemu0.14 and I'm trying to figure out why the Qemu dhcpd server is not responding back to the nic device in the guest OS when used with user mode 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) The NIC device is an Intel e1000 however, even if I use a pci ne2k, I get the same result. I've enabled debugging in the hw/e1000.c and in comparing the good debug output with the bad debug output, I noticed the point of deviation. The two traces are identical up till that point. Given that the problem is not the e1000 model itself, I doubt these traces are anything but symptomatic of the underlying problem in the Qemu portion that handles network traffic. Any ideas on what I can check next to see where the underlying problem might be? -AK This is a trace of the e1000.c debug messages from boot up for the good case on the left (where networking works) and the bad case on the right (where it doesn't). Good - Debug out Bad - Debug out === e1000: e1000_ioport_map addr=0xc040 size=0x0040 e1000: e1000_ioport_map addr=0xc040 size=0x0040 e1000: RCTL: 0, mac_reg[RCTL] = 0x0 e1000: tx disabled e1000: RCTL: 0, mac_reg[RCTL] = 0x0 e1000: tx disabled e1000: MMIO unknown write addr=0x5800,val=0x e1000: tx disabled e1000: MMIO unknown write addr=0x0030,val=0x8808 e1000: MMIO unknown write addr=0x002c,val=0x0100 e1000: MMIO unknown write addr=0x0028,val=0x00c28001 e1000: MMIO unknown write addr=0x0170,val=0x0680 e1000: MMIO unknown write addr=0x2160,val=0x e1000: MMIO unknown write addr=0x2168,val=0x e1000: MMIO unknown read addr=0x4014 e1000: MMIO unknown read addr=0x4018 e1000: MMIO unknown read addr=0x401c e1000: MMIO unknown read addr=0x4020 : e1000: MMIO unknown read addr=0x40b4 e1000: MMIO unknown read addr=0x40b8 e1000: MMIO unknown read addr=0x40bc e1000: MMIO unknown write addr=0x0458,val=0x e1000: RCTL: 0, mac_reg[RCTL] = 0x4 e1000: tx disabled e1000: MMIO unknown write addr=0x0410,val=0x00602008 e1000: MMIO unknown write addr=0x3820,val=0x0008 e1000: MMIO unknown write addr=0x382c,val=0x0020 e1000: tx disabled e1000: tx disabled e1000: RCTL: 0, mac_reg[RCTL] = 0x48002 e1000: RCTL: 0, mac_reg[RCTL] = 0x48000 e1000: MMIO unknown write addr=0x2820,val=0x e1000: MMIO unknown write addr=0x282c,val=0x0008 e1000: MMIO unknown write addr=0x00c4,val=0x00c3 e1000: MMIO unknown read addr=0x5000 e1000: MMIO unknown write addr=0x5000,val=0x0200 e1000: RCTL: 0, mac_reg[RCTL] = 0x48002 e1000: RCTL: 0, mac_reg[RCTL] = 0x48002 e1000: MMIO unknown write addr=0x00c4,val=0x03d0 e1000: RCTL: 254, mac_reg[RCTL] = 0x48002 = Point at which 1st difference appears e1000: RCTL: 254, mac_reg[RCTL] = 0x48002e1000: RCTL: 254, mac_reg[RCTL] = 0x48002 e1000: tx disabled e1000: RCTL: 254, mac_reg[RCTL] = 0x48002 e1000: MMIO unknown read
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/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] Howto debug boot device not showing up in bios
I meant what is the best way to debug the qemu and seabios interaction, I don't necessarily want to inspect instructions but rather just the function calls and trace the process so I can compare it for another case that isn't working. AK _ From: Mulyadi Santosa [mailto:mulyadi.sant...@gmail.com] To: ad...@khaleel.us Cc: qemu-devel@nongnu.org Sent: Tue, 10 May 2011 01:49:31 -0500 Subject: Re: [Qemu-devel] Howto debug boot device not showing up in bios Hi On Tue, May 10, 2011 at 05:24, Adnan Khaleel ad...@khaleel.us wrote: Can somebody give me some pointers on what the best way to debug the boot process in Qemu and seabios? At first, I guess -s a.k.a qemu gdb stub of Qemu could help you...but uhm, on a second thought, I think it is the qemu itself that you need to run under Qemu... regarding seabios code, i have no idea how to debug that... is it a binary blob only? -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
[Qemu-devel] Howto debug boot device not showing up in bios
Can somebody give me some pointers on what the best way to debug the boot process in Qemu and seabios? Seabios reports that no boot device is present even though I'm passing it the hda commandline argument. What I'm looking for in particular is what Qemu does to map the path to a device and how it passes this on to seabios. Any information on debug switches, general description of the process would be extremely helpful. AK
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
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 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
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
[Qemu-devel] Guest bootup time varies with simulated memory size
In trying out various simulated memory sized in Qemu, there is a noticeable increase in guest bootup times with more memory. My metric of measuring how long linux takes to boot is probably not the most consistent but here is what I've observed. In Qemu 0.12.5 512m ~ 4 mins 2048m ~ 7 mins In the latest version of Qemu 0.14.0-rc0, things have improved 512m ~ 3 mins 30 secs 2048m ~ 4 mins 45 secs As you can see, boot up time increases with more memory. My host system itself has 16G of memory so swapping is not the issue. Its quite likely that the guest linux kernel maybe doing something with this extra memory but I haven't looked into possible causes. I just wanted to see if the developers would know of an explanation as to whats happening as it would seem that adding more memory to the guest should improve performance. I will run some measurements after boot to see if there is any variation in overall simulation speed or if its just restricted to bootup. - AK
[Qemu-devel] Re: PCIe Transaction handling in Qemu
),
.qdev.reset = pcie_msix_reset,
.qdev.vmsd = vmstate_pcie_msix,
.is_express = 1,
.config_read= pcie_msix_read_config,
.config_write = pcie_msix_write_config,
.init = pcie_msix_initfn,
.exit = pcie_msix_exitfn,
.qdev.props = (Property[]) {
DEFINE_PROP_UINT32(vectors, PCIE_MSIX_DEVState, vectors,
PCIE_MSIX_MSI_NR_VECTOR),
DEFINE_PROP_UINT16(aer_log_max, PCIESlot,
port.br.dev.aer_log.log_max,
PCIE_AER_LOG_MAX_DEFAULT),
DEFINE_PROP_END_OF_LIST(),
}
};
Here is a code snippet where I register the mmio handlers:
static CPUWriteMemoryFunc * const pcie_msix_mem_write_fn[] = {
pcie_msix_mem_writeb, pcie_msix_mem_writew, pcie_msix_mem_writel,
pcie_msix_mem_writed
};
static CPUReadMemoryFunc * const pcie_msix_mem_read_fn[] = {
pcie_msix_mem_readb, pcie_msix_mem_readw, pcie_msix_mem_readl,
pcie_msix_mem_readd
};
static void
pcie_msix_mem_map(PCIDevice *dev, int region_num,
pcibus_t addr, pcibus_t size, int type)
{
uint32_t msix_mem_bar = 0;
PCIE_MSIX_DEVState *d = DO_UPCAST(PCIE_MSIX_DEVState, dev, dev);
cpu_register_physical_memory(addr, BAR_Regions[msix_mem_bar][0],
d-mmio_index);
}
Which I register via the following call in the pcie_msix_initfn(PCIDevice
*pci_dev) function
pci_register_bar(d-dev, msix_mem_bar, BAR_Regions[msix_mem_bar][0],
BAR_Regions[msix_mem_bar][1], pcie_msix_mem_map);
So are my following assumption true then for my PCIe device i.e the wrapper?
All config requests WILL be handled by the config handlers and,
All MMIO requests will be handled by the mmio handlers (given that the q35
model does not support MMIO on MMCONFIG)
3.a. What address is passed on the MMIO handlers for config and MMIO
operations? From pci_data_write in pci_host.c, it appears that config
operations send only the offset into the config region. I couldn't determine
what address is passed for MMIO operations.
b. Is it an offset from the BAR for MMIO operations?
c. How do I get the full physical address?
d. What address does a PCIe device expect to see - physical or offset
for?
e. Is there anyway I can find out what the bus and device numbers are
once
inside the config and MMIO handlers? i.e once the execution has reached
the pci_cirrus_write_config() or cirrus_vga_mem_readb(..) from the code
above?
offset in configuration space of each pcie function is passed to
write/read config handler
physical address is passed to mmio handler of memory BAR.
When I examine the address on calls to the PCIe Device Wrapper config handlers,
they start at 0x0 so they clearly are offsets. However, I also see addresses
from 0x0 in the MMIO handlers. Paul's response indicated that they were offsets
so I'm inclined to believe that the address is an offset from the start of the
BAR. So let me ask my question again - when I'm synthesizing the PCIe
transaction to send to the PCIe device model, do I have to give it a full
address i.e. bus,dev,fn for config transactions and full physical address for
MMIO transactions?
--
yamahata
/*
* pcie_template_device.c
*
* Copyright (c) 2010 Adnan Khaleel akhaleel at cray com
*Cray Inc
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, see http://www.gnu.org/licenses/.
*/
/* This is essentially an example for a device that utilises PCIe and MSI-X */
#include hw.h
#include pc.h
#include pci_ids.h
#include msi.h
#include msix.h
#include pcie.h
#include pcie_msix_template.h
#include pcie_pkt.h
extern int pcie_server_fd;
extern struct hostent *pcie_server;
extern uint64 pcie_transId;
extern boolpcie_server_connected;
#define BYTE 1
#define WORD 2*BYTE
#define LWORD 4*BYTE
#define DWORD 8*BYTE
/* Debug code */
#define DEBUG_PCIE_MSIX_TEMPLATE
#ifdef DEBUG_PCIE_MSIX_TEMPLATE
#define SPLIT64(x) (uint32_t)((x 32) 0x), (uint32_t)(x
0x)
#define PRINT_DEBUG(format, ...) printf(format, __VA_ARGS__);
#define PRINT_DEBUG0(format) printf(format);
#else
#define SPLIT64(x)
#define PRINT_DEBUG(format, ...)
#define PRINT_DEBUG0(format)
#endif
#define DEFINE_DEVICE_PROPERTIES(_state, _conf)
#define PCIE_MSIX_VID PCI_VENDOR_ID_CRAY
#define PCIE_MSIX_DID
[Qemu-devel] PCIe Transaction handling in Qemu
Hello,
I have a question regarding how Qemu PCIe devices handle Config Transactions vs
Memory Transactions (assuming the PCI device is setup to act as
PCI_BASE_ADDRESS_SPACE_MEMORY).
I'm using portions of hw/cirrus_vga.c to make my point,
static PCIDeviceInfo cirrus_vga_info = {
.qdev.name= cirrus-vga,
.qdev.desc= Cirrus CLGD 54xx VGA,
.qdev.size= sizeof(PCICirrusVGAState),
.qdev.vmsd= vmstate_pci_cirrus_vga,
.init = pci_cirrus_vga_initfn,
.romfile = VGABIOS_CIRRUS_FILENAME,
.config_write = pci_cirrus_write_config,
};
PCIDeviceInfo allows for custom .config_write ( config_read) handler as shown
above. Any pci config operations operations initiated via legacy I/O operations
will use these config handlers.
The MMIO regions and handlers are mapped as shown below:
static uint32_t cirrus_vga_mem_readb(void *opaque, target_phys_addr_t addr)
{
:
} and so on for the other mmio handlers
static CPUReadMemoryFunc * const cirrus_vga_mem_read[3] = {
cirrus_vga_mem_readb,
cirrus_vga_mem_readw,
cirrus_vga_mem_readl,
};
static CPUWriteMemoryFunc * const cirrus_vga_mem_write[3] = {
cirrus_vga_mem_writeb,
cirrus_vga_mem_writew,
cirrus_vga_mem_writel,
};
static void cirrus_init_common(CirrusVGAState * s, int device_id, int is_pci)
{
:
:
s-vga.vga_io_memory = cpu_register_io_memory(cirrus_vga_mem_read,
cirrus_vga_mem_write, s);
:
}
static void cirrus_pci_mmio_map(PCIDevice *d, int region_num,
pcibus_t addr, pcibus_t size, int type)
{
CirrusVGAState *s = DO_UPCAST(PCICirrusVGAState, dev, d)-cirrus_vga;
cpu_register_physical_memory(addr, CIRRUS_PNPMMIO_SIZE,
s-cirrus_mmio_io_addr);
}
static int pci_cirrus_vga_initfn(PCIDevice *dev)
{
:
:
cirrus_init_common(..)
:
if (device_id == CIRRUS_ID_CLGD5446) {
pci_register_bar((PCIDevice *)d, 1, CIRRUS_PNPMMIO_SIZE,
PCI_BASE_ADDRESS_SPACE_MEMORY, cirrus_pci_mmio_map);
}
return 0;
}
I have some questions about PCIe operations sssuming the device has MMIO
handlers involved (as shown above).
1. Will all PCIe config operations ALWAYS use the installed config handlers? Or
can PCIe config operations use the MMIO handlers?
2. Assuming that both PCI config and MMIO operations can use the MMIO handlers,
is there any way I can identify if a transaction is a config or a memory
transaction?
3.a. What address is passed on the MMIO handlers for config and MMIO
operations? From pci_data_write in pci_host.c, it appears that config
operations send only the offset into the config region. I couldn't determine
what address is passed for MMIO operations.
b. Is it an offset from the BAR for MMIO operations?
c. How do I get the full physical address?
d. What address does a PCIe device expect to see - physical or offset for?
e. Is there anyway I can find out what the bus and device numbers are once
inside the config and MMIO handlers? i.e once the execution has reached the
pci_cirrus_write_config() or cirrus_vga_mem_readb(..) from the code above?
Thanks
Adnan
[Qemu-devel] Single 64bit memory transaction instead of two 32bit memory transaction.
In the file exec.c:
The memory Write/Read functions are declared as an array of 4 entries where the
index values of 0,1,2 correspond to 8,16 and 32bit write and read functions
respectively.
CPUWriteMemoryFunc *io_mem_write[IO_MEM_NB_ENTRIES][4];
CPUReadMemoryFunc *io_mem_read[IO_MEM_NB_ENTRIES][4];
Is there any reason why we can't extend this to include 64bit writes and read
by increasing the array size? This is because 64bit reads are currently handled
as two separate 32bit reads for eg: sommu_template.h
static inline DATA_TYPE glue(io_read, SUFFIX)(target_phys_addr_t physaddr,
target_ulong addr,
void *retaddr)
{
:
res = io_mem_read[index][2](io_mem_opaque[index], physaddr);
res |= (uint64_t)io_mem_read[index][2](io_mem_opaque[index], physaddr + 4)
32;
:
return res;
}
I'm sure this is happening in other places as well. Is there a reason for this
or could we arbitrarily increase this (within limits ofcourse)?
Thanks
AK
[Qemu-devel] Re: [PATCH v5 00/14] pcie port switch emulators
Are all these patches going to be integrated into the current qemu repository?
-AK
_
From: Isaku Yamahata [mailto:yamah...@valinux.co.jp]
To: Michael S. Tsirkin [mailto:m...@redhat.com]
Cc: qemu-devel@nongnu.org, skand...@cisco.com, etmar...@cisco.com,
we...@cisco.com, ad...@khaleel.us
Sent: Tue, 19 Oct 2010 08:55:29 -0500
Subject: Re: [PATCH v5 00/14] pcie port switch emulators
Isaku Yamahata (14):
pci: introduce helper functions to test-and-{clear, set} mask in
configuration space
pci: introduce helper function to handle msi-x and msi.
pci: use pci_word_test_and_clear_mask() in pci_device_reset()
pci/bridge: fix pci_bridge_reset()
msi: implements msi
pcie: add pcie constants to pcie_regs.h
pcie: helper functions for pcie capability and extended capability
I'll apply these.
pcie/aer: helper functions for pcie aer capability
Maybe move this to the end of the series?
pcie port: define struct PCIEPort/PCIESlot and helper functions
ioh3420: pcie root port in X58 ioh
x3130: pcie upstream port
x3130: pcie downstream port
pcie/hotplug: introduce pushing attention button command
I think the above can be applied - just remove the dependency
on aer for now.
Okay. I'll update the patch series and send it tomorrow.
--
yamahata
Re: [Qemu-devel] Template for developing a Qe mu device with PCIe and MSI-X
I've tried everything you mentioned and I still get the same problem. The only
thing that seems to avoid that issue is if I reduce the aperture size from
0x20ull to 0x200ull.
Here is the relevant section of code:
static const unsigned long long BAR_Regions[6][2] =
{
// len , type
{ 0x200ull, PCI_BASE_ADDRESS_SPACE_MEMORY |
PCI_BASE_ADDRESS_MEM_TYPE_64} , //BAR0,
{ 0, 0} , // BAR1
{ 0x200ull, PCI_BASE_ADDRESS_SPACE_IO} , //BAR2,
{ 0, 0} , // BAR3 for MSI-X
{ 0, 0} , // BAR4
{ 0, 0} , // BAR5
};
static int pcie_msix_initfn(PCIDevice *pci_dev)
{
PCIE_MSIX_DEVState *d = DO_UPCAST(PCIE_MSIX_DEVState, dev, pci_dev);
PCIBridge *br = DO_UPCAST(PCIBridge, dev, pci_dev);
PCIEPort *p = DO_UPCAST(PCIEPort, br, br);
int rc, i;
PRINT_DEBUG(%s: PCIE MSIX Device init...\n, __FUNCTION__);
pci_config_set_vendor_id(d-dev.config, PCIE_MSIX_VID);
pci_config_set_device_id(d-dev.config, PCIE_MSIX_DID);
memcpy(d-dev.config, g_cfg_init, sizeof(g_cfg_init[0x20]));
d-mmio_index = cpu_register_io_memory(pcie_msix_mem_read_fn,
pcie_msix_mem_write_fn, d);
int msix_mem_bar = 0; // Since its a 64bit BAR, we take up BAR0 BAR1
int msix_io_bar = 2;
int msix_mmio_bar = 3;
pci_register_bar(d-dev, msix_mem_bar, BAR_Regions[msix_mem_bar][0],
BAR_Regions[msix_mem_bar][1], pcie_msix_mem_map);
pci_register_bar(d-dev, msix_io_bar, BAR_Regions[msix_io_bar][0],
BAR_Regions[msix_io_bar][1], pcie_msix_io_map);
rc = msix_init(d-dev, d-vectors, msix_mmio_bar, 0);
if (!rc) {
PRINT_DEBUG(%s: Registering Bar %i as I/O BAR\n, __FUNCTION__,
msix_mmio_bar);
pci_register_bar(d-dev, msix_mmio_bar, msix_bar_size(d-dev),
PCI_BASE_ADDRESS_SPACE_MEMORY, msix_mmio_map);
PRINT_DEBUG(%s: MSI-X initialized (%d vectors)\n, __FUNCTION__,
d-vectors);
}
else {
PRINT_DEBUG(%s: MSI-X initialization failed!\n, __FUNCTION__);
return rc;
}
// Activate the vectors
for (i = 0; i d-vectors; i++) {
msix_vector_use(d-dev, i);
}
rc = pci_pcie_cap_init(d-dev, PCIE_MSIX_EXP_OFFSET,
PCI_EXP_TYPE_ENDPOINT, p-port);
if (rc 0) {
return rc;
}
pcie_cap_flr_init(d-dev, pcie_msix_flr);
pcie_cap_deverr_init(d-dev);
pcie_cap_ari_init(d-dev);
rc = pcie_aer_init(d-dev, PCIE_MSIX_AER_OFFSET);
if (rc 0) {
return rc;
}
PRINT_DEBUG(%s: Init done\n, __FUNCTION__);
return 0;
}
Another question I have is why doesn't the device show up when I try a cat
/proc/interrupts.
linux-an84:~/AriesKernelModules/gni/aries/ghal # cat /proc/interrupts
CPU0
0:694 IO-APIC-edge timer
1: 6 IO-APIC-edge i8042
4:753 IO-APIC-edge serial
8: 1 IO-APIC-edge rtc0
9: 0 IO-APIC-fasteoi acpi
12: 89 IO-APIC-edge i8042
14: 3522 IO-APIC-edge ata_piix
15:785 IO-APIC-edge ata_piix
16:162 IO-APIC-fasteoi eth0
4344: 0 PCI-MSI-edge aerdrv
4345: 0 PCI-MSI-edge aerdrv
4346: 0 PCI-MSI-edge aerdrv
4347: 0 PCI-MSI-edge aerdrv
4348: 0 PCI-MSI-edge aerdrv
4349: 0 PCI-MSI-edge aerdrv
4350: 0 PCI-MSI-edge aerdrv
4351: 0 PCI-MSI-edge aerdrv
NMI: 0 Non-maskable interrupts
LOC: 107095 Local timer interrupts
RES: 0 Rescheduling interrupts
CAL: 0 function call interrupts
TLB: 0 TLB shootdowns
TRM: 0 Thermal event interrupts
THR: 0 Threshold APIC interrupts
SPU: 0 Spurious interrupts
ERR: 0
Shouldn't there be an entry for the MSI-X device?
Thanks for all your input.
AK
_
Probably what you want is something like
{ 0x20ull, PCI_BASE_ADDRESS_SPACE_MEMORY |
PCI_BASE_ADDRESS_MEM_TYPE_64} , //BAR0
{ 0, 0} , //BAR1
// 64bit BAR occupies 2 BAR entries so that BAR1 can't be used.
{ 0x200ull,PCI_BASE_ADDRESS_SPACE_IO} , //BAR2
{ 0, 0} , //BAR3
// for MSI-X
{ 0, 0} , //BAR4
{ 0, 0}//BAR5
Re: [Qemu-devel] Template for developing a Qe mu device with PCIe and MSI-X
During bootup, I also see the following error message:
pci :40:00.0: BAR 0 bad alignment 20:
0x00-0x1f
Any idea whats causing this?
AK
_
From: Isaku Yamahata [mailto:yamah...@valinux.co.jp]
To: Adnan Khaleel [mailto:ad...@khaleel.us]
Cc: Cam Macdonell [mailto:c...@cs.ualberta.ca], qemu-devel@nongnu.org
Sent: Wed, 01 Sep 2010 21:38:31 -0500
Subject: Re: [Qemu-devel] Template for developing a Qemu device with PCIe and
MSI-X
On Wed, Sep 01, 2010 at 02:07:33PM -0500, Adnan Khaleel wrote:
Yamahata, Cam,
Thank you both very much for pointers about Qemu coding for PCIe and MSI-X.
I'm at a point where I can see my device when I do an lspci -t -v as shown
below.
linux-an84:~ # lspci -t -v
-[:00]-+-00.0 Intel Corporation 82G33/G31/P35/P31 Express DRAM
Controller
+-01.0 Cirrus Logic GD 5446
+-04.0-[:20]--
+-18.0-[:21]--
+-18.1-[:22]--
+-18.2-[:23]--
+-18.3-[:24]--
+-18.4-[:25]--
+-18.5-[:26]--
+-19.0-[:36-bf]--+-00.0-[:37-47]--+-00.0-[:38]--
||+-01.0-[:39]--
||+-02.0-[:3a]--
||+-03.0-[:3b]--
||+-04.0-[:3c]--
||+-05.0-[:3d]--
||+-06.0-[:3e]--
||+-07.0-[:3f]--
||
+-08.0-[:40]00.0
Cray Inc Device 0301 - The device that I've included
However, I'm having a bit of an issue with the MSI-X.
I'm following the code examples in virtio-pci.c and ivshmem.c that Cam
pointed
out to. I've got bar 01 already occupied so I assign the msix_mmio_map to
bar
2. However, when I do that, Qemu fails to boot and fails with the following
assertion fail:
unused outb: port=0x00f1 data=0x00
qemu: fatal: Trying to execute code outside RAM or ROM at 0x0010
Couple of thins I'm unsure about:
1. Am I registering the 64bit bar addresses correctly?
pci_register_bar(d-dev, i, BAR_Regions[i][0], PCI_BASE_ADDRESS_SPACE_IO |
PCI_BASE_ADDRESS_MEM_TYPE_64, pcie_msix_io_map);
No. PCI_BASE_ADDRESS_SPACE_IO | PCI_BASE_ADDRESS_MEM_TYPE_64 is invalid.
PCI doesn't support 64bit io space, but 32bit. And x86 supports 64k
io sparce.
2. In the function int msix_init(PCIDevice *pdev, unsigned short nentries,
unsigned bar_nr, unsigned bar_size);
I'm not sure what bar_nr is, however setting it to 1 (as in code examples
above) or to 2 (bar that I want to register the msix_mmio_map to) both fail
with the same error.
It should be 2. I'm not sure why it failed.
rc = msix_init(d-dev, d-vectors, 2, 0);
:
:
pci_register_bar(d-dev, 2, msix_bar_size(d-dev),
PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_64,
msix_mmio_map);
Here is my init function code in its entirety:
static const unsigned long long BAR_Regions[6][2] =
{
// len , type
{ 0x20ull, PCI_BASE_ADDRESS_SPACE_MEMORY} , //BAR0
{ 0x200ull,PCI_BASE_ADDRESS_SPACE_IO} , //BAR1
{ 0, 0} , //BAR2
{ 0, 0} , //BAR3
{ 0, 0} , //BAR4
{ 0, 0}//BAR5
};
Probably what you want is something like
{ 0x20ull, PCI_BASE_ADDRESS_SPACE_MEMORY |
PCI_BASE_ADDRESS_MEM_TYPE_64} , //BAR0
{ 0, 0} , //BAR1
// 64bit BAR occupies 2 BAR entries so that BAR1 can't be used.
{ 0x200ull,PCI_BASE_ADDRESS_SPACE_IO} , //BAR2
{ 0, 0} , //BAR3
// for MSI-X
{ 0, 0} , //BAR4
{ 0, 0}//BAR5
static int pcie_msix_initfn(PCIDevice *pci_dev)
{
PCIE_MSIX_DEVState *d = DO_UPCAST(PCIE_MSIX_DEVState, dev, pci_dev);
PCIBridge *br = DO_UPCAST(PCIBridge, dev, pci_dev);
PCIEPort *p = DO_UPCAST(PCIEPort, br, br);
int rc, i;
PRINT_DEBUG(%s: PCIE MSIX Device init...\n, __FUNCTION__);
pci_config_set_vendor_id(d-dev.config, PCIE_MSIX_VID);
pci_config_set_device_id(d-dev.config, PCIE_MSIX_DID);
d-dev.config[PCI_REVISION_ID] = PCIE_MSIX_VERSION;
d-dev.config[PCI_SUBSYSTEM_VENDOR_ID] = PCIE_MSIX_VID 0xff;
d-dev.config[PCI_SUBSYSTEM_VENDOR_ID+1] = (PCIE_MSIX_VID 8) 0xff;
d-dev.config[PCI_SUBSYSTEM_ID] = PCIE_MSIX_SS_DID 0xff;
d-dev.config[PCI_SUBSYSTEM_ID+1] = (PCIE_MSIX_SS_DID 8) 0xff;
Use pci_set_word().
d-mmio_index = cpu_register_io_memory(pcie_msix_mem_read_fn,
pcie_msix_mem_write_fn, d);
for(i=0; i PCI_NUM_REGIONS -1; i++) { //-1
Re: [Qemu-devel] Template for developing a Qemu device with PCIe and MSI-X
,
PCI_EXP_TYPE_ENDPOINT, p-port);
if (rc 0) {
return rc;
}
pcie_cap_flr_init(d-dev, pcie_msix_flr);
pcie_cap_deverr_init(d-dev);
pcie_cap_ari_init(d-dev);
rc = pcie_aer_init(d-dev, PCIE_MSIX_AER_OFFSET);
if (rc 0) {
return rc;
}
PRINT_DEBUG(%s: Init done\n, __FUNCTION__);
return 0;
}
Thanks
AK
_
From: Cam Macdonell [mailto:c...@cs.ualberta.ca]
To: ad...@khaleel.us
Cc: Isaku Yamahata [mailto:yamah...@valinux.co.jp], qemu-devel@nongnu.org
Sent: Fri, 27 Aug 2010 10:48:48 -0500
Subject: Re: [Qemu-devel] Template for developing a Qemu device with PCIe and
MSI-X
On Wed, Aug 25, 2010 at 4:39 PM, Adnan Khaleel ad...@khaleel.us wrote:
Hi Isaku,
I've made some progress in coding the device template but its no where near
complete.
I've created some files and am attaching it to this note. Based on what I
could gather from the pcie source files I've made a stab at creating a
simple model. I've also attached a file for a simple pci device that works
under regular Qemu. I would like to duplicate its functionality in your pcie
environment for starters.
Could you please take a look at the files I've created and tell me if I've
understood your pcie model correctly. Any help will be truly appreciated.
Adnan
Hi Adnan,
There is a fairly simple device I've created called ivshmem that is
in the qemu git tree. It is a regular PCI device that exports a
shared memory object via a BAR and supports a few registers and
optional MSI-X interrupts (I had to pick through the virtio code to
get MSI-X working, so looking at ivshmem might save you some effort).
My device is somewhat similar to a graphics card actually which I
recall is your goal. The purpose of ivshmem is to support sharing
memory between multiple guests running on the same host. It follows
the qdev model which you will need to do.
Cam
The five files I've modified from your git repository are as follows
hw/pci_ids.h// Added vendor id defines
hw/pc_q35.c// Device instantiation
hw/pcie_msix_template.h // Device header file
hw/pcie_msix_template.c // Device file
Makefile.objs // Added pcie_msix_template.o to list of
objects being built
Everything should compile without any warnings or errors.
The last file:
sc_link_pci.c
Is the original PCI device that I'm trying to convert into being PCIe and
MSI-X and is included merely for reference to help you understand what I'd
like to achieve in your environment.
From: Isaku Yamahata [mailto:yamah...@valinux.co.jp]
To: Adnan Khaleel [mailto:ad...@khaleel.us]
Cc: qemu-devel@nongnu.org
Sent: Wed, 18 Aug 2010 22:19:04 -0500
Subject: Re: [Qemu-devel] Template for developing a Qemu device with PCIe
and MSI-X
On Wed, Aug 18, 2010 at 02:10:10PM -0500, Adnan Khaleel wrote:
Hello Qemu developers,
I'm interested in developing a device model that plugs into Qemu that is
based
on a PCIe interface and uses MSI-X. My goal is to ultimately attach a GPU
simulator to this PCIe interface and use the entire platfom (Qemu + GPU
simulator) for studying cpu, gpu interactions.
I'm not terribly familiar with the Qemu device model and I'm looking for
some
assistance, perhaps a starting template for pcie and msi-x that would
offer the
basic functionality that I could then build upon.
I have looked at the various devices that already modelled that are
included
with Qemu (v0.12.5 at least) and I've noticed several a few pci devices,
eg;
ne2k and cirrus-pci etc, however only one device truly seems to utilize
both
the technologies that I'm interested in and that is the virtio-pci.c
I'm not sure what virtio-pci does so I'm not sure if that is a suitable
starting point for me.
Any help, suggestions etc would be extremely helpful and much appreciated.
Qemu doesn't support pcie at the moment.
Only partial patches have been merged, still more patches have to
be merged for pcie to fully work. The following repo is available.
git clone http://people.valinux.co.jp/~yamahata/qemu/q35/qemu
git clone http://people.valinux.co.jp/~yamahata/qemu/q35/seabios
git clone http://people.valinux.co.jp/~yamahata/qemu/q35/vgabios
Note: patched seabios and vgabios are needed, you have to pass ACPI DSDT
for q35.
example:
qemu-system-x86_64 -M pc_q35 -acpitable
load_header,data=roms/seabios/src/q35-acpi-dsdt.aml
This repo is for those who want to try/develop pcie support,
not for upstream merge. So they include patches unsuitable for upstream.
The repo includes pcie port switch emulator which utilize pcie and
MSI(not MSI-X).
The difference between PCI device and PCIe device is configuration
space size.
By setting PCIDeviceInfo
Re: [Qemu-devel] Template for developing a Qe mu device with PCIe?and MSI-X
Hi there. I should have sent a lot of these with my note yesterday but I was in
a hurry to get the files to you first.
See my comments below and thanks again.
AK
pcie_msix_write_config() should call pci_default_write_config()
unless you did it so intentionally.I've made this change. Thanks for the
pointer.
You also want to catch up pci api clean up.
pci_{set, get}_{byte, word, long, quad}(),
pci_config_set_vendor() ...Are you referring to the setting up of the config
registers where we pass on the vendor id and device id etc? Would you elaborate
a little more.
Also, I've got a bunch of questions but let me state my assumptions first so
that you have a better idea of what I'm referring to.
- The device template is a pcie endpoint
- I want to be able to setup 64bit bar addresses, with large apertures
- For now, I'd like to be able to do basic MMIO and regular IO reads and
writes.
PCIe questions.
1. What does the topology of the bridge with respect to the root look like? Is
it
Root --- PCIe Bridge
2. If so, where is the slot where I can insert the PCIe device? Is it off the
Bridge or would it be better for it to be off the root?
Root --- PCIe Bridge --- PCIe/MSI-X device
Or
Root --- PCIe Bridge
--- PCIe/MSI-X Device
And hence my confusion about how to do the following:
static void pcie_msix_register(void)
{
pci_bridge_qdev_register(pcie_msix_info); // Is this what I should be
doing?
OR
pci_qdev_register(pcie_msix_info); // Or this
}
3. I wasn't sure how to register the device how to do the initializing. Please
see the following section of code:
void pcie_msix_init(PCIBus *bus)
{
// Is this how we should be doing this?
pci_create_simple(bus, -1, pcie_msix_device);
OR
pci_bridge_create(...);
}
Or if should I use pci_bridge_create(...) in place of the pci_create_simple(...)
Also, this confusion led me to being unsure what the following device struct
should look like
typedef struct PCIE_MSIX_DEVState_St {
PCIDevice dev;
int mmio_index;
} PCIE_MSIX_DEVState;
For the simple device function that I've described above, what is the purpose
of this struct? What other data should be captured?
Which include the initializing of the following static structs. Btw, can you
tell me what VMStateDescrption is used for by Qemu? Also, what should the
fields member contain? I couldn't quite make out.
static const VMStateDescription vmstate_pcie_msix = {
.name = pcie-msix-device,
.version_id = 1,
.minimum_version_id = 1,
.minimum_version_id_old = 1,
.fields = (VMStateField[]) {
VMSTATE_PCIE_DEVICE(dev, PCIE_MSIX_DEVState),
VMSTATE_STRUCT(dev.aer_log, PCIE_MSIX_DEVState, 0,
vmstate_pcie_aer_log, struct pcie_aer_log),
VMSTATE_END_OF_LIST()
}
};
4. What is the qdev.props field used for?
static PCIDeviceInfo pcie_msix_info = {
.qdev.name = PCIE_MSIX_DEVICE,
.qdev.desc = PCIE MSIX device template,
.qdev.size = sizeof(PCIE_MSIX_DEVState),
.qdev.reset = pcie_msix_reset,
.qdev.vmsd = vmstate_pcie_msix,
.is_express = 1,
.config_write = pcie_msix_write_config,
.init = pcie_msix_initfn,
.exit = pcie_msix_exitfn,
.qdev.props = (Property[]) {
DEFINE_PROP_END_OF_LIST(),
}
};
5. Device instantiation
I init the device in pc_q35_bridge_init() in pc_q35.c
pcie_msix_init(root_port_bus);
I know I'm doing this incorrectly since I'm not specifying several things.
Again, is this the correct place to init the device?
MSI/MSIX questions
1. How is an interrupt notification passed on to Qemu? In the regular case I'd
use qemu_set_irq(..) to do so but what is the correct way of doing it in the
MSIX paradigm? For example in the case of a DMA transfer.
Re: [Qemu-devel] Template for developing a Qe mu device with PCIe?and MSI-X
I'm not sure what the problem was but I had checked out the code on a windows machine and then copied it over to a linux box. That was causing problems somehow. I've managed to compile qemu and seabios but vgabios is taking forever to compile. The problem seems to be bcc. I've tried a simple helloworld program and even that seems to be taking forever to compile. Not sure if there is something wrong with my bcc install. AK _ From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] To: Adnan Khaleel [mailto:ad...@khaleel.us] Cc: qemu-devel@nongnu.org Sent: Fri, 20 Aug 2010 00:22:03 -0500 Subject: Re: [Qemu-devel] Template for developing a Qemu device with PCIe?and MSI-X On Thu, Aug 19, 2010 at 01:32:42PM -0500, Adnan Khaleel wrote: Isaku, I'm having some difficulties building the sources, I get the following message *akhal...@yar95 qemu-q35 $ ./configure --help : bad interpreter: No such file or directory And I get a similar error while compiling seabios as well. What shell are you using or am I missing something? I'm compiling from a typical bash shell and using gcc v4.4.0. I'm not sure. configure script isn't modified. Can you compile normal qemu? The first line of the script is #!/bin/sh. I suppose you have /bin/sh. In vgabios, there is a requirement for bcc. Is that borland C compiler? No. Most Linux destro has bcc package. Just you need to install it like yum install bcc or something. Thanks, Thanks Adnan ━ From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] To: Adnan Khaleel [mailto:ad...@khaleel.us] Cc: qemu-devel@nongnu.org Sent: Wed, 18 Aug 2010 22:19:04 -0500 Subject: Re: [Qemu-devel] Template for developing a Qemu device with PCIe and MSI-X On Wed, Aug 18, 2010 at 02:10:10PM -0500, Adnan Khaleel wrote: Hello Qemu developers, I'm interested in developing a device model that plugs into Qemu that is based on a PCIe interface and uses MSI-X. My goal is to ultimately attach a GPU simulator to this PCIe interface and use the entire platfom (Qemu + GPU simulator) for studying cpu, gpu interactions. I'm not terribly familiar with the Qemu device model and I'm looking for some assistance, perhaps a starting template for pcie and msi-x that would offer the basic functionality that I could then build upon. I have looked at the various devices that already modelled that are included with Qemu (v0.12.5 at least) and I've noticed several a few pci devices, eg; ne2k and cirrus-pci etc, however only one device truly seems to utilize both the technologies that I'm interested in and that is the virtio-pci.c I'm not sure what virtio-pci does so I'm not sure if that is a suitable starting point for me. Any help, suggestions etc would be extremely helpful and much appreciated. Qemu doesn't support pcie at the moment. Only partial patches have been merged, still more patches have to be merged for pcie to fully work. The following repo is available. git clone http://people.valinux.co.jp/~yamahata/qemu/q35/qemu git clone http://people.valinux.co.jp/~yamahata/qemu/q35/seabios git clone http://people.valinux.co.jp/~yamahata/qemu/q35/vgabios Note: patched seabios and vgabios are needed, you have to pass ACPI DSDT for q35. example: qemu-system-x86_64 -M pc_q35 -acpitable load_header,data=roms/seabios/src/ q35-acpi-dsdt.aml This repo is for those who want to try/develop pcie support, not for upstream merge. So they include patches unsuitable for upstream. The repo includes pcie port switch emulator which utilize pcie and MSI(not MSI-X). The difference between PCI device and PCIe device is configuration space size. By setting PCIDeviceInfo::is_express = 1, you'll get 4K configuration space. Helper functions for pcie are found in qemu/hw/pcie.c For msi-x, see qemu/hw/msix.c. Thanks, -- yamahata -- yamahata
Re: [Qemu-devel] Template for developing a Qe mu device with PCIe?and MSI-X
After messing around with bcc, as86 and ld86 I finally got the vgabios to compile. Everything works as it should I'm guessing. I've attached the output from lspci from the guest. I'll spend sometime looking at the device models and see how I can implement a model of what I'm interested in. Is the overall architecture of any qemu device still similar to how a typical qemu pci device is or is there anything I should be aware of? Thanks again Isaku. AK _ From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] To: Adnan Khaleel [mailto:ad...@khaleel.us] Cc: qemu-devel@nongnu.org Sent: Fri, 20 Aug 2010 00:22:03 -0500 Subject: Re: [Qemu-devel] Template for developing a Qemu device with PCIe?and MSI-X On Thu, Aug 19, 2010 at 01:32:42PM -0500, Adnan Khaleel wrote: Isaku, I'm having some difficulties building the sources, I get the following message *akhal...@yar95 qemu-q35 $ ./configure --help : bad interpreter: No such file or directory And I get a similar error while compiling seabios as well. What shell are you using or am I missing something? I'm compiling from a typical bash shell and using gcc v4.4.0. I'm not sure. configure script isn't modified. Can you compile normal qemu? The first line of the script is #!/bin/sh. I suppose you have /bin/sh. In vgabios, there is a requirement for bcc. Is that borland C compiler? No. Most Linux destro has bcc package. Just you need to install it like yum install bcc or something. Thanks, Thanks Adnan ━ From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] To: Adnan Khaleel [mailto:ad...@khaleel.us] Cc: qemu-devel@nongnu.org Sent: Wed, 18 Aug 2010 22:19:04 -0500 Subject: Re: [Qemu-devel] Template for developing a Qemu device with PCIe and MSI-X On Wed, Aug 18, 2010 at 02:10:10PM -0500, Adnan Khaleel wrote: Hello Qemu developers, I'm interested in developing a device model that plugs into Qemu that is based on a PCIe interface and uses MSI-X. My goal is to ultimately attach a GPU simulator to this PCIe interface and use the entire platfom (Qemu + GPU simulator) for studying cpu, gpu interactions. I'm not terribly familiar with the Qemu device model and I'm looking for some assistance, perhaps a starting template for pcie and msi-x that would offer the basic functionality that I could then build upon. I have looked at the various devices that already modelled that are included with Qemu (v0.12.5 at least) and I've noticed several a few pci devices, eg; ne2k and cirrus-pci etc, however only one device truly seems to utilize both the technologies that I'm interested in and that is the virtio-pci.c I'm not sure what virtio-pci does so I'm not sure if that is a suitable starting point for me. Any help, suggestions etc would be extremely helpful and much appreciated. Qemu doesn't support pcie at the moment. Only partial patches have been merged, still more patches have to be merged for pcie to fully work. The following repo is available. git clone http://people.valinux.co.jp/~yamahata/qemu/q35/qemu git clone http://people.valinux.co.jp/~yamahata/qemu/q35/seabios git clone http://people.valinux.co.jp/~yamahata/qemu/q35/vgabios Note: patched seabios and vgabios are needed, you have to pass ACPI DSDT for q35. example: qemu-system-x86_64 -M pc_q35 -acpitable load_header,data=roms/seabios/src/ q35-acpi-dsdt.aml This repo is for those who want to try/develop pcie support, not for upstream merge. So they include patches unsuitable for upstream. The repo includes pcie port switch emulator which utilize pcie and MSI(not MSI-X). The difference between PCI device and PCIe device is configuration space size. By setting PCIDeviceInfo::is_express = 1, you'll get 4K configuration space. Helper functions for pcie are found in qemu/hw/pcie.c For msi-x, see qemu/hw/msix.c. Thanks, -- yamahata -- yamahata 00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller 00:01.0 VGA compatible controller: Cirrus Logic GD 5446 00:04.0 PCI bridge: Intel Corporation X58 I/O Hub PCI Express Root Port 0 (rev 02) 00:18.0 PCI bridge: Intel Corporation X58 I/O Hub PCI Express Root Port 0 (rev 02) 00:18.1 PCI bridge: Intel Corporation X58 I/O Hub PCI Express Root Port 0 (rev 02) 00:18.2 PCI bridge: Intel Corporation X58 I/O Hub PCI Express Root Port 0 (rev 02) 00:18.3 PCI bridge: Intel Corporation X58 I/O Hub PCI Express Root Port 0 (rev 02) 00:18.4 PCI bridge: Intel Corporation
Re: [Qemu-devel] Template for developing a Qe mu device with PCIe and MSI-X
Hi Isaku, thank you very much for your very detailed response. I have a few questions, see below. Thanks again, Adnan Qemu doesn't support pcie at the moment. Only partial patches have been merged, still more patches have to be merged for pcie to fully work. The following repo is available. git clone http://people.valinux.co.jp/~yamahata/qemu/q35/qemu git clone http://people.valinux.co.jp/~yamahata/qemu/q35/seabios git clone http://people.valinux.co.jp/~yamahata/qemu/q35/vgabios Note: patched seabios and vgabios are needed, you have to pass ACPI DSDT for q35. example: qemu-system-x86_64 -M pc_q35 -acpitable load_header,data=roms/seabios/src/q35-acpi-dsdt.aml This repo is for those who want to try/develop pcie support, not for upstream merge. So they include patches unsuitable for upstream.I'm looking at Qemu 0.12.3 and there are 2 files, pci_host.c and pcie_host.c. Can you explain what these do? Also, I see virtio_pci.c is the only device that uses msi-x in qemu. Can you explain what device this is trying to emulate? Also, will the support for PCIe be merged with the mail Qemu at some point? The repo includes pcie port switch emulator which utilize pcie and MSI(not MSI-X). I guess I could use this as a template for my qemu device mode correct? The difference between PCI device and PCIe device is configuration space size. By setting PCIDeviceInfo::is_express = 1, you'll get 4K configuration space. Helper functions for pcie are found in qemu/hw/pcie.c For msi-x, see qemu/hw/msix.c. One last question, does the current implementation allow for 64bit BAR addresses? Thanks, -- yamahata
Re: [Qemu-devel] Template for developing a Qe mu device with PCIe and MSI-X
Isaku, I'm having some difficulties building the sources, I get the following message *akhal...@yar95 qemu-q35 $ ./configure --help : bad interpreter: No such file or directory And I get a similar error while compiling seabios as well. What shell are you using or am I missing something? I'm compiling from a typical bash shell and using gcc v4.4.0. In vgabios, there is a requirement for bcc. Is that borland C compiler? Thanks Adnan _ From: Isaku Yamahata [mailto:yamah...@valinux.co.jp] To: Adnan Khaleel [mailto:ad...@khaleel.us] Cc: qemu-devel@nongnu.org Sent: Wed, 18 Aug 2010 22:19:04 -0500 Subject: Re: [Qemu-devel] Template for developing a Qemu device with PCIe and MSI-X On Wed, Aug 18, 2010 at 02:10:10PM -0500, Adnan Khaleel wrote: Hello Qemu developers, I'm interested in developing a device model that plugs into Qemu that is based on a PCIe interface and uses MSI-X. My goal is to ultimately attach a GPU simulator to this PCIe interface and use the entire platfom (Qemu + GPU simulator) for studying cpu, gpu interactions. I'm not terribly familiar with the Qemu device model and I'm looking for some assistance, perhaps a starting template for pcie and msi-x that would offer the basic functionality that I could then build upon. I have looked at the various devices that already modelled that are included with Qemu (v0.12.5 at least) and I've noticed several a few pci devices, eg; ne2k and cirrus-pci etc, however only one device truly seems to utilize both the technologies that I'm interested in and that is the virtio-pci.c I'm not sure what virtio-pci does so I'm not sure if that is a suitable starting point for me. Any help, suggestions etc would be extremely helpful and much appreciated. Qemu doesn't support pcie at the moment. Only partial patches have been merged, still more patches have to be merged for pcie to fully work. The following repo is available. git clone http://people.valinux.co.jp/~yamahata/qemu/q35/qemu git clone http://people.valinux.co.jp/~yamahata/qemu/q35/seabios git clone http://people.valinux.co.jp/~yamahata/qemu/q35/vgabios Note: patched seabios and vgabios are needed, you have to pass ACPI DSDT for q35. example: qemu-system-x86_64 -M pc_q35 -acpitable load_header,data=roms/seabios/src/q35-acpi-dsdt.aml This repo is for those who want to try/develop pcie support, not for upstream merge. So they include patches unsuitable for upstream. The repo includes pcie port switch emulator which utilize pcie and MSI(not MSI-X). The difference between PCI device and PCIe device is configuration space size. By setting PCIDeviceInfo::is_express = 1, you'll get 4K configuration space. Helper functions for pcie are found in qemu/hw/pcie.c For msi-x, see qemu/hw/msix.c. Thanks, -- yamahata
[Qemu-devel] Template for developing a Qemu device with PCIe and MSI-X
Hello Qemu developers, I'm interested in developing a device model that plugs into Qemu that is based on a PCIe interface and uses MSI-X. My goal is to ultimately attach a GPU simulator to this PCIe interface and use the entire platfom (Qemu + GPU simulator) for studying cpu, gpu interactions. I'm not terribly familiar with the Qemu device model and I'm looking for some assistance, perhaps a starting template for pcie and msi-x that would offer the basic functionality that I could then build upon. I have looked at the various devices that already modelled that are included with Qemu (v0.12.5 at least) and I've noticed several a few pci devices, eg; ne2k and cirrus-pci etc, however only one device truly seems to utilize both the technologies that I'm interested in and that is the virtio-pci.c I'm not sure what virtio-pci does so I'm not sure if that is a suitable starting point for me. Any help, suggestions etc would be extremely helpful and much appreciated. Sincerely, AK
Re: [Qemu-devel] Problems changing dvdrom iso during execution
So do you have any idea whats causing the problem? Is there any other way I can mount a dvd in Qemu? Adnan _ From: David S. Ahern [mailto:daah...@cisco.com] To: ad...@khaleel.us Cc: Qemu-devel@nongnu.org Sent: Thu, 20 May 2010 17:45:11 -0500 Subject: Re: [Qemu-devel] Problems changing dvdrom iso during execution On 05/20/2010 03:48 PM, Adnan Khaleel wrote: Thanks for your response. Does it work if the guest uses ide based CD's: rmmod ide-scsi modprobe ide-cd There isn't an ide-scsi but there is a scsi_mod and when I try to remove that it gives ERROR: Module scsi_mod is in use by sr_mod,sg,sd_mod,libata modprobe ide-cd seems to work. Ok, I pulled those from a RHEL3 VM. Looks like SLES11 is using a newer 2.6 kernel. The idea I was poking at was to get the CD in the VM to go through the ide-cd layer and not the ata/scsi route. I had to do that for my RHEL3 guest to get some consistency with the DVD -- similar to the problem you are seeing. David However it doesn't fix the problem. Interestingly, before doing modprobe ide-cd, linux lsmod | grep ide ide_pci_generic 46520 ide_core 115068 2 ide_pci_generic, piix After the modprobe ide-cd, I get ide_cd_mod 339840 cdrom 362002 ide_cd_mod, sr_mod ide_pci_generic 46520 ide_core 115068 3 ide_cd_mod, ide_pci_generic, piix
Re: [Qemu-devel] Problems changing dvdrom iso during execution
Tried that, still the same. My current workaround is to mount all the DVD iso files as separate hard disks and mount those. This worked but its a workaround at best. Not sure what I'd do if ever had to access more then 3 dvd's at a time - which I doubt should happen anytime soon. _ From: David S. Ahern [mailto:daah...@cisco.com] To: ad...@khaleel.us Cc: Qemu-devel@nongnu.org Sent: Fri, 21 May 2010 13:47:00 -0500 Subject: Re: [Qemu-devel] Problems changing dvdrom iso during execution On 05/21/2010 10:10 AM, Adnan Khaleel wrote: So do you have any idea whats causing the problem? Is there any other way I can mount a dvd in Qemu? Adnan have you tried ejecting the cd in the guest before changing the file in the monitor? David
Re: [Qemu-devel] Problems changing dvdrom iso during execution
It works in ubuntu 9.10. When I mount the CDROM the first time it mounts fine. After I change the iso file and mount, it spits out a bunch of messages but it does mount the drive. I think this problem might be specific to sles11. On May 21, 2010, at 5:37 PM, Natalia Portillo clau...@claunia.com wrote: Have you tried any other operating system or kernel revision? I have just changed the iso with change ide1-cd0 command in Windows XP Upgrade (it asks to insert a previous Windows CD and then reinsert the XP one) without any kind of problem, in QEMU 0.12.4. El 21/05/2010, a las 20:42, Adnan Khaleel escribió: Tried that, still the same. My current workaround is to mount all the DVD iso files as separate hard disks and mount those. This worked but its a workaround at best. Not sure what I'd do if ever had to access more then 3 dvd's at a time - which I doubt should happen anytime soon. From: David S. Ahern [mailto:daah...@cisco.com] To: ad...@khaleel.us Cc: Qemu-devel@nongnu.org Sent: Fri, 21 May 2010 13:47:00 -0500 Subject: Re: [Qemu-devel] Problems changing dvdrom iso during execution On 05/21/2010 10:10 AM, Adnan Khaleel wrote: So do you have any idea whats causing the problem? Is there any other way I can mount a dvd in Qemu? Adnan have you tried ejecting the cd in the guest before changing the file in the monitor? David
[Qemu-devel] Problems changing dvdrom iso during execution
I cannot change DVD roms during execution using the monitor. I can only mount a cdrom/dvdrom if I specify the iso file in the command line x86_64-softmmu/qemu-system-x86_64 -hda ../../OSImages/sles11.qcow2 -cdrom ../../ISOz/mydvd.iso -m 2048 In the guest I can mount the iso image as you could normally expect mount /dev/cdrom /mnt mount: block device /dev/sr0 is write-protected, mounting read-only Info block in the monitor yields (qemu) info block ide0-hd0: type=hd removable=0 file../../OSImages/sles11.qcow2 ro=0 drv=dcow2 encrypted=0 ide1-cd0: type=cdrom removable=1 locked=1 file=../../ISOz/mydvd.iso ro=0 drv=raw encrypted=0 floppy0: type=floppy removable=1 locked=0 [not inserted] sd0: type=floppy removable=1 locked=0 [not inserted] When I try to do a eject ide0-cd0, I get a device busy message so I have to do a eject -f ide0-cd0 After which, an info block yields: (qemu) info block ide0-hd0: type=hd removable=0 file../../OSImages/sles11.qcow2 ro=0 drv=dcow2 encrypted=0 ide1-cd0: type=cdrom removable=1 locked=1 [not inserted] floppy0: type=floppy removable=1 locked=0 [not inserted] sd0: type=floppy removable=1 locked=0 [not inserted] I change the iso image with (or so it seems) (qemu) change ide1-cd0 ../../ISOz/mydvd2_rom.iso (qemu) info block ide0-hd0: type=hd removable=0 file../../OSImages/sles11.qcow2 ro=0 drv=dcow2 encrypted=0 ide1-cd0: type=cdrom removable=1 locked=1 file=../../ISOz/mydvd2.iso ro=0 drv=raw encrypted=0 floppy0: type=floppy removable=1 locked=0 [not inserted] sd0: type=floppy removable=1 locked=0 [not inserted] I go back to the guest and when I try to mount: mount /dev/cdrom /mnt mount: /dev/sr0 unknown device I'm running sles11 as guest and I think it may have something to do with sles11 as it works fine with ubuntu9. Any ideas what might be happening? Thanks AK
Re: [Qemu-devel] Problems changing dvdrom iso during execution
Thanks for your response. Does it work if the guest uses ide based CD's: rmmod ide-scsi modprobe ide-cd There isn't an ide-scsi but there is a scsi_mod and when I try to remove that it gives ERROR: Module scsi_mod is in use by sr_mod,sg,sd_mod,libata modprobe ide-cd seems to work. However it doesn't fix the problem. Interestingly, before doing modprobe ide-cd, linux lsmod | grep ide ide_pci_generic 46520 ide_core 115068 2 ide_pci_generic, piix After the modprobe ide-cd, I get ide_cd_mod 339840 cdrom 362002 ide_cd_mod, sr_mod ide_pci_generic 46520 ide_core 115068 3 ide_cd_mod, ide_pci_generic, piix
[Qemu-devel] Question about PCIe and MSI-X status in Qemu
Could one of the developers give a brief status of the current state of support for PCIe and MSI-X interrupts in Qemu. I'm trying to build a System-C device that I'd like to co-simulate with Qemu and have the ability to use the same software stack as well. The kernel modules rely on MSI-X interrupts and the device itself would be a PCIe device. Also, in your opinion, what would be the best device model (NIC etc) that Qemu already has in place that would serve as a good starting template? I know this is a fairly broad question so any pointers would be helpful. Thanks AK
[Qemu-devel] Error installing bootloader in guest
Hi there, I'm using qemu-0.7.1 to install SUSE Linux enterprise v9 and everything proceeds smoothly until the boot loader as to be installed as which point I get the SUSE installer reporting a segmentation fault while installing GRUB. The hard disk image is in raw format I created using qemu-img and is 3G in size. I've attached a screen capture Any ideas what might be causing this? I've tried it using 2 different harddisk images but I get the same problem. Thanks Adnan qemu_error.gif Description: GIF image ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
