From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33483) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SR24m-0000YC-5H for qemu-devel@nongnu.org; Sun, 06 May 2012 10:04:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SR24j-0005tb-Rw for qemu-devel@nongnu.org; Sun, 06 May 2012 10:04:39 -0400 Received: from router-304.cs.umd.edu ([128.8.127.145]:4489 helo=sausage.cs.umd.edu) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SR24j-0005s2-NC for qemu-devel@nongnu.org; Sun, 06 May 2012 10:04:37 -0400 Received: from newman.cs.umd.edu (newman.cs.umd.edu [172.24.0.4]) by sausage.cs.umd.edu (Postfix) with ESMTPS id 963AD6C03AC for ; Sun, 6 May 2012 10:04:33 -0400 (EDT) Received: from webmail.cs.umd.edu (localhost [127.0.0.1]) by newman.cs.umd.edu (8.13.1/8.14.1) with ESMTP id q46E4IIf021101 for ; Sun, 6 May 2012 10:04:18 -0400 Message-ID: <031acc46fa564d29a335172989d62603.squirrel@webmail.cs.umd.edu> In-Reply-To: References: Date: Sun, 6 May 2012 10:04:18 -0400 From: jims@cs.umd.edu MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] DMA Pointer for SSD Simulation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org A quick follow up: I realized that I didn't understand how to use scatter/gather lists and that is why I was getting garbage output. I read some old mailing list messages from when this was first implemented and added the following code to ide_dma_cb: fprintf(stderr, "\nsg SG list (size =3D %ld, nsg=3D%d)\n", s->sg.size, s->sg.nsg); int i; for (i=3D0; isg.nsg; i++) { fprintf(stderr, "%d (base =3D %ld, len =3D %ld)\n", i, s->sg.sg[i].base, s->sg.sg[i].len); } I'm now getting reasonable output for the most cases when s->nsector =3D=3D= 0 (which is when we actually send the call back to PTLSim). Here is a typical output: io_buffer_size =3D 13312 SG list (size =3D 13312, nsg=3D4) 0 (base =3D 231381680, len =3D 4096) 1 (base =3D 547137536, len =3D 4096) 2 (base =3D 547141632, len =3D 4096) 3 (base =3D 547145728, len =3D 1024) I'm still seeing some things that don't look valid though. Here is one that targets address 0 (not sure if this is allowed or not): sg SG list (size =3D 1024, nsg=3D1) 0 (base =3D 0, len =3D 1024) And here is one that looks almost correct except for one garbage entry: SG list (size =3D 69632, nsg=3D17) 0 (base =3D 139836550876824, len =3D 139836550876824) 1 (base =3D 547180544, len =3D 4096) 2 (base =3D 547184640, len =3D 4096) 3 (base =3D 547188736, len =3D 4096) 4 (base =3D 547192832, len =3D 4096) 5 (base =3D 547196928, len =3D 4096) 6 (base =3D 547201024, len =3D 4096) 7 (base =3D 547205120, len =3D 4096) 8 (base =3D 547209216, len =3D 4096) 9 (base =3D 547213312, len =3D 4096) 10 (base =3D 547217408, len =3D 4096) 11 (base =3D 547221504, len =3D 4096) 12 (base =3D 547225600, len =3D 4096) 13 (base =3D 547229696, len =3D 4096) 14 (base =3D 547233792, len =3D 4096) 15 (base =3D 547237888, len =3D 4096) 16 (base =3D 547241984, len =3D 4096) As you can see, it appears the 0th entry should have len=3D4096 (because that would result in a sum of 69632). But both the address and length are wrong. Any ideas as to why? Thanks, Jim Stevens University of Maryland, College Park > I am working on an SSD simulation to plug into the MARSSx86 simulation > environment (http://marss86.org/~marss86/index.php/Home). MARSSx86 uses > QEMU as an emulation for an x86_64 system and PTLSim for timing the > pipeline. My lab has further extended this system to use our DRAMSim2 > simulator to simulate the main memory > (https://wiki.umd.edu/DRAMSim2/index.php?title=3DMain_Page). > > I have integrated our SSD simulator into marss. The SSD simulator model= s > the host interface and the SSD internals. This works by delaying the IR= Q > for the IDE (in qemu/hw/ide/core.c:ide_dma_cb()) based on the operation= of > the SSD model. I now want to capture the timing of the DMA for the SSD = as > it would happen in a real system. To do this, I'd like to send read > transactions to DRAMSim2 before a write operation to the SSD and write > transactions to DRAMSim2 after a read operation to the SSD. The reason = I'm > emailing is that I've made a few assumptions about how the IDE code in > QEMU works and I'd like to confirm that I'm doing things correctly. > > One problem I'm having is that I cannot figure out what the actual poin= ter > is for the DMA operation in the guest physical memory. I have printed o= ut > the s->sg.sg->base and s->sg.sg->len in ide_dma_cb(), but it seems to = be > garbage a lot of the time. I'm getting base=3D0 or base as something ve= ry > large and out of my memory bounds (e.g. 139880767148024). Sometimes it > does seem to be a valid location in memory though. Why is this sometime= s > seemingly invalid? Or am I using the wrong variable to the DMA pointer > into the guest physical memory? > > Also, the s->sg.sg->len is often not matching the io_buffer_size. I'm n= ot > 100% sure if it should, but since I'm using io_buffer_size to determine > the number of transactions to send to DRAMSim2 per IRQ (with > io_buffer_size / 64) and the number of sectors to write to the disk per > IRQ, I'd like to know if I'm doing things correctly or not. > > Lastly, I'm using the sector_num (multiplied by 512 to get a byte addre= ss) > in ide_dma_cb() as the base address to the SSD. Is this correct? > > If you'd like to review the code, it is available on Github > (https://github.com/jimstevens2001/marss.dramsim/tree/ssdsim). The disk > access/DMA information is extracted from qemu/hw/ide/core.c and the > interaction with our SSD model is implemented in ptlsim/sim/ptlsim.cpp. > > > Thanks, > > Jim Stevens > University of Maryland, College Park >