Re: [Qemu-devel] qemu vl.c hw/omap.c
Le mardi 04 décembre 2007 à 01:20 +, Paul Brook a écrit : On Tuesday 04 December 2007, andrzej zaborowski wrote: On 04/12/2007, Paul Brook [EMAIL PROTECTED] wrote: Log message: Always create an SD bdrv, so that PXA and OMAP boards can boot with no card inserted again. Eventually SD, CDROM and floppy should all be registered conditionally depending on machine. This seems the wrong way to solve this problem. The SD emulation should be able to cope with no device being present. The bdrv's represent the concept of drive rather than media, and also in the case the bdrv must be present whenever there is a SD slot, not an SD card (so that monitor command change and eject can be used). I agree that not all machines have an SD slot, as not all machines have a cd-rom drive or floppy drive. Right, but I think you're going in the wrong direction. Most scsi interfaces do support hotplug of devices. For USB mass storage the whole controller is hotplug. Pre-allocating all possible devices simply doesn't scale. Hi Paul, I think Andrzez is doing it correctly. He only adds an entry in drives_table[] without creating any bdrv (because he doesn't provide file). Then in omap.c, he creates the device, not the media. And as Palm Tunsgten is the only machine calling omap310_mpu_init(), the device is only created for it. And then he will be able to introduce card (file) in the SD reader. Laurent -- - [EMAIL PROTECTED] -- Any sufficiently advanced technology is indistinguishable from magic. - Arthur C. Clarke signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Qemu-devel] [PATCH 2/2 v2] Direct IDE I/O
Anthony Liguori wrote: I have a patch that uses linux-aio for the virtio-blk driver I'll be posting tomorrow and I'm extremely happy with the results. In recent kernels, you can use an eventfd interface along with linux-aio so that polling is unnecessary. Which kernel version is recent? cheers, Gerd
Re: [Qemu-devel] [PATCH 2/2 v2] Direct IDE I/O
Le mardi 04 décembre 2007 à 13:49 +0100, Gerd Hoffmann a écrit : Anthony Liguori wrote: I have a patch that uses linux-aio for the virtio-blk driver I'll be posting tomorrow and I'm extremely happy with the results. In recent kernels, you can use an eventfd interface along with linux-aio so that polling is unnecessary. Which kernel version is recent? I think it is 2.6.22 and after Laurent -- - [EMAIL PROTECTED] -- Any sufficiently advanced technology is indistinguishable from magic. - Arthur C. Clarke signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Qemu-devel] [PATCH 2/2 v2] Direct IDE I/O
Anthony Liguori wrote: IMHO it would be a much better idea to kill the aio interface altogether and instead make the block drivers reentrant. Then you can use (multiple) posix threads to run the I/O async if you want. Threads are a poor substitute for a proper AIO interface. linux-aio gives you everything you could possibly want in an interface since it allows you to submit multiple vectored operations in a single syscall, use an fd to signal request completion, complete multiple requests in a single syscall, and inject barriers via fdsync. I still think implementing async i/o at block driver level is the wrong thing to do. You'll end up reinventing the wheel over and over again and add complexity to the block drivers which simply doesn't belong there (or not supporting async I/O for most file formats). Just look at the insane file size of the block driver for the simplest possible disk format: block-raw.c. It will become even worse when adding a linux-specific aio variant. In contrast: Making the disk drivers reentrant should be easy for most of them. For the raw driver it should be just using pread/pwrite syscalls instead of lseek + read/write (also saves a syscall along the way, yea!). Others probably need an additional lock for metadata updates. With that in place you can easily implement async I/O via threads one layer above, and only once, in block.c. IMHO the only alternative to that scheme would be to turn the block drivers in some kind of remapping drivers for the various file formats which don't actually perform the I/O. Then you can handle the actual I/O in a generic way using whatever API is available, be it posix-aio, linux-aio or slow-sync-io. cheers, Gerd
Re: [Qemu-devel] and now bus error for i386 guest
HI,
Blue Swirl wrote:
On 11/14/07, Shaddy Baddah [EMAIL PROTECTED] wrote:
Hi again,
After further culling the target list, I was able to install qemu on my
sun4u host.
However, running it, I get a bus error. See below for details:
$ /opt/qemu-cvs/bin/qemu -m 128 -cdrom
~/KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -vnc :1
Bus error
For some reason, Sparc Linux host is not working. I think Sparc Solaris is OK.
Yes, I do recall that I was able to get this working on Sparc Solaris.
Anyway, when I get more time, I will have a better stab at debugging
this. I got a start on this today, and here is a bit of cut and paste
that may or may not be insightful. The address for env1 looks questionable:
[EMAIL PROTECTED]:~/qemu-cvs/qemu-build$ gdb --args ./i386-softmmu/qemu
-hda ../../KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -L ../qemu/pc-bios
GNU gdb 6.6.90.20070912-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as sparc-linux-gnu...
Using host libthread_db library /lib/libthread_db.so.1.
(gdb) run
Starting program: /home/shaddy/qemu-cvs/qemu-build/i386-softmmu/qemu
-hda ../../KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -L ../qemu/pc-bios
[Thread debugging using libthread_db enabled]
[New Thread 0xf7f7b550 (LWP 9363)]
Program received signal SIGBUS, Bus error.
[Switching to Thread 0xf7f7b550 (LWP 9363)]
cpu_x86_exec (env1=0x2) at /home/shaddy/qemu-cvs/qemu/cpu-exec.c:307
307 if (env-exception_index = 0) {
(gdb) info threads
* 1 Thread 0xf7f7b550 (LWP 9363) cpu_x86_exec (env1=0x2)
at /home/shaddy/qemu-cvs/qemu/cpu-exec.c:307
(gdb)
HTH,
Shaddy
PS: couldn't this also be debugged from within qemu VM running Debian
Sparc, for those that don't have access to a real machine? I got a start
on this today as well (because I don't always have access to the Sun
Ultra box). Seems stable, and I was able to get a start on a compile,
that is currently still going.
Re: [Qemu-devel] [PATCH 2/2 v2] Direct IDE I/O
Gerd Hoffmann wrote: Anthony Liguori wrote: IMHO it would be a much better idea to kill the aio interface altogether and instead make the block drivers reentrant. Then you can use (multiple) posix threads to run the I/O async if you want. Threads are a poor substitute for a proper AIO interface. linux-aio gives you everything you could possibly want in an interface since it allows you to submit multiple vectored operations in a single syscall, use an fd to signal request completion, complete multiple requests in a single syscall, and inject barriers via fdsync. I still think implementing async i/o at block driver level is the wrong thing to do. You'll end up reinventing the wheel over and over again and add complexity to the block drivers which simply doesn't belong there (or not supporting async I/O for most file formats). Just look at the insane file size of the block driver for the simplest possible disk format: block-raw.c. It will become even worse when adding a linux-specific aio variant. In contrast: Making the disk drivers reentrant should be easy for most of them. For the raw driver it should be just using pread/pwrite syscalls instead of lseek + read/write (also saves a syscall along the way, yea!). Others probably need an additional lock for metadata updates. With that in place you can easily implement async I/O via threads one layer above, and only once, in block.c. I really want to use readv/writev though. With virtio, we get a scatter/gather list for each IO request. Once I post the virtio-blk driver, I'll follow up a little later with some refactoring of the block device layers. I think it can be made much simpler while still remaining asynchronous. IMHO the only alternative to that scheme would be to turn the block drivers in some kind of remapping drivers for the various file formats which don't actually perform the I/O. Then you can handle the actual I/O in a generic way using whatever API is available, be it posix-aio, linux-aio or slow-sync-io. That's part of my plan. Regards, Anthony Liguori cheers, Gerd
Re: [Qemu-devel] [PATCH] sparc32 machine specific maximums
On 12/4/07, Robert Reif [EMAIL PROTECTED] wrote: Blue Swirl wrote: On 12/3/07, Robert Reif [EMAIL PROTECTED] wrote: This patch sets the maximum number of CPUs and memory to what is supported by the actual hardware. While it's not historically accurate to emulate a Sparcstation 5 with 16 CPUs and 2 gigabytes of memory, it doesn't break anything to have this capability. We don't throttle the power of the CPU, speed of the network, serial or disk devices either, so they may be unrealistically fast. The timers are not accurate at all compared to CPU execution speed. Currently the memory on SS-5 machine is limited by the location of IOMMU and that the memory lies in one linear bank starting from zero. With more advanced banking and 4G patches, the entire physical address space could be filled with RAM. I would be surprised if an SMP kernel actually worked on a multi CPU SS5. Prepare for a surprise: Loading initial ramdisk PROMLIB: obio_ranges 1 Booting Linux... PROMLIB: Sun Boot Prom Version 3 Revision 2 Linux version 2.2.20pre2 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP Wed May 30 10:44:52 PDT 2001 ARCH: SUN4M TYPE: SPARCstation 5 Ethernet address: 52:54:0:12:34:56 Boot time fixup v1.6. 4/Mar/98 Jakub Jelinek ([EMAIL PROTECTED]). Patching kernel for srmmu[Fujitsu TurboSparc]/iommu [0]: v[f000,fd00](d00) p[] [1]: v[ed00,eff2c000](2f2c000) p[0d00] Found CPU 0 node=ffd56998,mid=0 Found CPU 1 node=ffd56d4c,mid=1 Found CPU 2 node=ffd57100,mid=2 Found CPU 3 node=ffd574b4,mid=3 Found 4 CPU prom device tree node(s). Power off control detected. Calibrating delay loop... 235.92 BogoMIPS Memory: 254792k available (1508k kernel code, 3372k data, 148k init) [ed00,fd00] Dentry hash table entries: 32768 (order 6, 256k) Buffer cache hash table entries: 262144 (order 8, 1024k) Page cache hash table entries: 65536 (order 6, 256k) VFS: Diskquotas version dquot_6.4.0 initialized POSIX conformance testing by UNIFIX Entering SMP Mode... Starting CPU 1 at f01c9dc4 Calibrating delay loop... 84.17 BogoMIPS Starting CPU 2 at f01c9dd0 Calibrating delay loop... 77.00 BogoMIPS Starting CPU 3 at f01c9ddc Calibrating delay loop... 78.84 BogoMIPS Total of 4 Processors activated (475.95 BogoMIPS). IOMMU: impl 0 vers 4 page table at efe8 of size 524288 bytes sbus0: Clock 21.1250 MHz dma0: Revision 2 dma1: Revision 0 Linux NET4.0 for Linux 2.2 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0 for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP TCP: Hash tables configured (ehash 262144 bhash 65536) Linux IP multicast router 0.06 plus PIM-SM Initializing RT netlink socket Starting kswapd v 1.5 Sparc Zilog8530 serial driver version 1.41.2.8 tty00 at 0xffe97004 (irq = 44) is a Zilog8530 tty01 at 0xffe97000 (irq = 44) is a Zilog8530 tty02 at 0xffe98004 (irq = 44) is a Zilog8530 tty03 at 0xffe98000 (irq = 44) is a Zilog8530 Sun TYPE 4 keyboard detected without keyclick Console: ttyS0 (Zilog8530) pty: 512 Unix98 ptys configured Sun Mouse-Systems mouse driver version 1.00 RAM disk driver initialized: 16 RAM disks of 5120K size Floppy drive(s): fd0 is 1.44M FDC 0 is a S82078B md driver 0.36.6 MAX_MD_DEV=4, MAX_REAL=8 linear personality registered raid0 personality registered raid1 personality registered raid5 personality registered esp0: IRQ 36 SCSI ID 7 Clk 40MHz CCF=8 TOut 167 NCR53C90(esp100) ESP: Total of 1 ESP hosts found, 1 actually in use. scsi0 : Sparc ESP100 (NCR53C90) scsi : 1 host. Vendor: QEMU Model: QEMU HARDDISK Rev: 0.9. Type: Direct-Access ANSI SCSI revision: 03 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 Vendor: QEMU Model: QEMU CD-ROM Rev: 0.9. Type: CD-ROM ANSI SCSI revision: 03 Detected scsi CD-ROM sr0 at scsi0, channel 0, id 2, lun 0 scsi : detected 2 SCSI generics 1 SCSI cdrom 1 SCSI disk total. sr0: scsi3-mmc drive: 16x/50x cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.11 SCSI device sda: hdwr sector= 512 bytes. Sectors= 2097152 [1024 MB] [1.0 GB] Partition check: sda: sda1 sda2 sda3 RAMDISK: Compressed image found at block 0 EXT2-fs warning: checktime reached, running e2fsck is recommended VFS: Mounted root (ext2 filesystem). serial console detected. Disabling virtual terminals. init started: BusyBox v0.51 (2001.05.24-01:20+) multi-call binary none on /proc type proc (rw) chown[26]: Unimplemented SPARC system call 31 chown[38]: Unimplemented SPARC system call 31 Currently OSs like solaris and bsd that actually use more than a minimal amount of hardware don't work in QEMU. That's because QEMUs system emulation is both incomplete and inaccurate. If you want to make Please give concrete examples where the emulation is incomplete so we can fix the problems. There are some well known areas where Qemu is by design not
Re: [Qemu-devel] [PATCH 2/2 v2] Direct IDE I/O
Anthony Liguori wrote: Gerd Hoffmann wrote: Hi, I really want to use readv/writev though. With virtio, we get a scatter/gather list for each IO request. Yep, I've also missed pwritev (or whatever that syscall would be named). Once I post the virtio-blk driver, I'll follow up a little later with some refactoring of the block device layers. I think it can be made much simpler while still remaining asynchronous. IMHO the only alternative to that scheme would be to turn the block drivers in some kind of remapping drivers for the various file formats which don't actually perform the I/O. Then you can handle the actual I/O in a generic way using whatever API is available, be it posix-aio, linux-aio or slow-sync-io. That's part of my plan. Oh, cool. Can you also turn them into a sane shared library while being at it? The current approach to compile it once for qemu and once for qemu-img with -DQEMU_TOOL isn't that great. But if you factor out the actual I/O the block-raw.c code should have no need to mess with qemu internals any more and become much cleaner and simpler ... cheers, Gerd
Re: [Qemu-devel] [PATCH] sparc32 machine specific maximums
On 12/4/07, Thiemo Seufer [EMAIL PROTECTED] wrote: Blue Swirl wrote: On 12/3/07, Robert Reif [EMAIL PROTECTED] wrote: This patch sets the maximum number of CPUs and memory to what is supported by the actual hardware. While it's not historically accurate to emulate a Sparcstation 5 with 16 CPUs and 2 gigabytes of memory, it doesn't break anything to have this capability. Are you sure? OS kernels, let alone Model-specific firmware images, may well have intimate knowledge about the specific machine layout. The boot prom (OpenBoot Prom/Open Firmware) must know, but the OS need not know so much. For example, the OS calls OF to start a new CPU. On OpenBIOS, this is handled by sending an interrupt to the halted CPU. I don't know how the real ROM works, there are no docs for these things. I'd be happy to change this to match the real hardware if someone tells me how. Likewise for memory, OS just reads a few tables giving the available and unavailable physical and virtual memory addresses. Implementing a different machine than the one announced sounds like bad idea to me, especially when modelling an additional hypothetical machine variant in QEMU is so cheap to implement. I can't see how adding more CPUs or memory can break anything. It works well, because of the indirection provided by the boot prom (OpenBIOS in our case). Maybe the real ROM can't understand the extra CPUs or memory, but who cares? Just reduce CPUs and memory if you want to use real ROM.
Re: [Qemu-devel] [PATCH] sparc32 machine specific maximums
Am 04.12.2007 um 00:53 schrieb Thiemo Seufer: Blue Swirl wrote: On 12/3/07, Robert Reif [EMAIL PROTECTED] wrote: This patch sets the maximum number of CPUs and memory to what is supported by the actual hardware. While it's not historically accurate to emulate a Sparcstation 5 with 16 CPUs and 2 gigabytes of memory, it doesn't break anything to have this capability. Are you sure? OS kernels, let alone Model-specific firmware images, may well have intimate knowledge about the specific machine layout. Implementing a different machine than the one announced sounds like bad idea to me, especially when modelling an additional hypothetical machine variant in QEMU is so cheap to implement. Unfortunately such fprintf messages to stderr are only visible on the console and not in graphical frontends. If you decide to place more of those abort messages, could you please consider using macros so they can be easily overridden with message boxes or some other notification mechanism? Andreas
Re: [Qemu-devel] [PATCH] sparc32 machine specific maximums
If you want to make a 16 CPU, 64 Gb machine, define a QEMU specific machine. There are no real 32 bit sparc systems like that. I believe the Cray CS6400 was a 64-way sparc32 machine with 16Gb ram. Admittedly it's a sun4d variant, not sun4m. I've no idea how much difference (if any) that makes to OS. Paul
Re: [Qemu-devel] [PATCH] sparc32 machine specific maximums
On 12/4/07, Paul Brook [EMAIL PROTECTED] wrote: If you want to make a 16 CPU, 64 Gb machine, define a QEMU specific machine. There are no real 32 bit sparc systems like that. I believe the Cray CS6400 was a 64-way sparc32 machine with 16Gb ram. Admittedly it's a sun4d variant, not sun4m. I've no idea how much difference (if any) that makes to OS. Sun4d is not that different from Sun4m. Interrupt handling is different. There are several IOUNITs in place of the single IOMMU, but they use the same page tables. The rest of the devices are the same old stuff. One (Linux) kernel can be used for all of Sun4c, Sun4m, and Sun4d. I think Linux doesn't support more than 4G of memory even on Sun4d. I have a preliminary patch to implement SS-1000 and SS-2000. If I find docs for Cray CS6400, I'd be interested to implement that as well.
Re: [Qemu-devel] and now bus error for i386 guest
On 12/4/07, Shaddy Baddah [EMAIL PROTECTED] wrote:
HI,
Blue Swirl wrote:
On 11/14/07, Shaddy Baddah [EMAIL PROTECTED] wrote:
Hi again,
After further culling the target list, I was able to install qemu on my
sun4u host.
However, running it, I get a bus error. See below for details:
$ /opt/qemu-cvs/bin/qemu -m 128 -cdrom
~/KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -vnc :1
Bus error
For some reason, Sparc Linux host is not working. I think Sparc Solaris is
OK.
Yes, I do recall that I was able to get this working on Sparc Solaris.
Anyway, when I get more time, I will have a better stab at debugging
this. I got a start on this today, and here is a bit of cut and paste
that may or may not be insightful. The address for env1 looks questionable:
[EMAIL PROTECTED]:~/qemu-cvs/qemu-build$ gdb --args ./i386-softmmu/qemu
-hda ../../KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -L ../qemu/pc-bios
GNU gdb 6.6.90.20070912-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as sparc-linux-gnu...
Using host libthread_db library /lib/libthread_db.so.1.
(gdb) run
Starting program: /home/shaddy/qemu-cvs/qemu-build/i386-softmmu/qemu
-hda ../../KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -L ../qemu/pc-bios
[Thread debugging using libthread_db enabled]
[New Thread 0xf7f7b550 (LWP 9363)]
Program received signal SIGBUS, Bus error.
[Switching to Thread 0xf7f7b550 (LWP 9363)]
cpu_x86_exec (env1=0x2) at /home/shaddy/qemu-cvs/qemu/cpu-exec.c:307
307 if (env-exception_index = 0) {
(gdb) info threads
* 1 Thread 0xf7f7b550 (LWP 9363) cpu_x86_exec (env1=0x2)
at /home/shaddy/qemu-cvs/qemu/cpu-exec.c:307
(gdb)
My guess is that Linux glibc overwrites global registers at some
point, like in signal handling or setjmp. The generated code looks OK
and it shouldn't be different from what Solaris version would
generate. I've been thinking of different register design (using
locals or outs) but then the op helpers would need to use different
mechanism to access T0/T1/T2. Compiling Qemu against uClibc could also
show something.
PS: couldn't this also be debugged from within qemu VM running Debian
Sparc, for those that don't have access to a real machine? I got a start
on this today as well (because I don't always have access to the Sun
Ultra box). Seems stable, and I was able to get a start on a compile,
that is currently still going.
Nice idea! Do you mean full system emulator or user mode?
[Qemu-devel] qemu/hw slavio_serial.c sun4m.c sun4m.h
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/12/04 20:58:31 Modified files: hw : slavio_serial.c sun4m.c sun4m.h Log message: No keyboard mode (Robert Reif) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/slavio_serial.c?cvsroot=qemur1=1.28r2=1.29 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemur1=1.66r2=1.67 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.h?cvsroot=qemur1=1.2r2=1.3
[Qemu-devel] Re: gcc
Rick Vernam [EMAIL PROTECTED] writes: any comments on the current status of moving beyond dependency on GCC 3.3.6? Sorry for a vague ignorant question, but would the gcc-4 issues be affected in any way if the ops were inside a big function (use labels to find them) vs the current use of separate functions? -- http://www.iki.fi/~ananaza/
[Qemu-devel] [PATCH 0/3] virtio support for QEMU
This patch series adds support for paravirtual device drivers that use virtio. virtio is a frame work in Linux for abstracting the details of virtual IO so that a single device driver (like networking) can be used with multiple hypervisors using a small shim layer. Currently, Linux supports a virtio network and a virtio block device and a shim layer for lguest. I have a PCI shim layer for virtio that is suitable for use in QEMU. This is currently in Rusty Russell's virtio tree awaiting the Linux merge window to open again. Regards, Anthony Liguori
[Qemu-devel] [PATCH 1/3] virtio infrastructure
Subject: [PATCH 1/3] virtio infrastructure
Cc: Rusty Russell [EMAIL PROTECTED]
Cc: Avi Kivity [EMAIL PROTECTED]
Cc: Dor Laor [EMAIL PROTECTED]
This patch implements the basic infrastructure for virtio devices. These
devices are exposed to the guest as real PCI devices. The PCI vendor/device
IDs have been donated by Qumranet and the subsystem IDs are used to distinguish
the virtio device itself.
Virtio provides an abstraction for performing guest=host and host=guest
communications. It also provides a standard ring queue interface and discovery
mechanism. Finally, virtio provides a simple mechanism for passing
configuration between host and guest.
In this virtio implementation, we provide these things via normal PCI
operations. The Linux kernel support for this virtio device is pending in
Rusty's virtio patch queue[1]. They should be submitted once the merge window
opens again.
Some future TODOs are to use endian/alignment safe routines when accessing the
virtqueue so that mixed mode host/guests are supported.
[1] http://ozlabs.org/~rusty/kernel/hg
Index: qemu/Makefile.target
===
--- qemu.orig/Makefile.target 2007-12-04 10:00:43.0 -0600
+++ qemu/Makefile.target 2007-12-04 14:15:20.0 -0600
@@ -435,6 +435,9 @@
VL_OBJS += pcnet.o
VL_OBJS += rtl8139.o
+# virtio devices
+VL_OBJS += virtio.o
+
ifeq ($(TARGET_BASE_ARCH), i386)
# Hardware support
VL_OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o
Index: qemu/hw/virtio.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ qemu/hw/virtio.c 2007-12-04 14:17:15.0 -0600
@@ -0,0 +1,422 @@
+/*
+ * Virtio Support
+ *
+ * Copyright IBM, Corp. 2007
+ *
+ * Authors:
+ * Anthony Liguori [EMAIL PROTECTED]
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include inttypes.h
+#include err.h
+
+#include virtio.h
+#include sysemu.h
+
+/* from Linux's linux/virtio_pci.h */
+
+/* A 32-bit r/o bitmask of the features supported by the host */
+#define VIRTIO_PCI_HOST_FEATURES 0
+
+/* A 32-bit r/w bitmask of features activated by the guest */
+#define VIRTIO_PCI_GUEST_FEATURES 4
+
+/* A 32-bit r/w PFN for the currently selected queue */
+#define VIRTIO_PCI_QUEUE_PFN 8
+
+/* A 16-bit r/o queue size for the currently selected queue */
+#define VIRTIO_PCI_QUEUE_NUM 12
+
+/* A 16-bit r/w queue selector */
+#define VIRTIO_PCI_QUEUE_SEL 14
+
+/* A 16-bit r/w queue notifier */
+#define VIRTIO_PCI_QUEUE_NOTIFY 16
+
+/* An 8-bit device status register. */
+#define VIRTIO_PCI_STATUS 18
+
+/* An 8-bit r/o interrupt status register. Reading the value will return the
+ * current contents of the ISR and will also clear it. This is effectively
+ * a read-and-acknowledge. */
+#define VIRTIO_PCI_ISR 19
+
+#define VIRTIO_PCI_CONFIG 20
+
+/* QEMU doesn't strictly need write barriers since everything runs in
+ * lock-step. We'll leave the calls to wmb() in though to make it obvious for
+ * KVM or if kqemu gets SMP support.
+ */
+#define wmb() do { } while (0)
+
+/* virt queue functions */
+
+static void virtqueue_init(VirtQueue *vq, void *p)
+{
+vq-vring.desc = p;
+vq-vring.avail = p + vq-vring.num * sizeof(VRingDesc);
+vq-vring.used = (void *)TARGET_PAGE_ALIGN((unsigned long)vq-vring.avail-ring[vq-vring.num]);
+}
+
+static unsigned virtqueue_next_desc(VirtQueue *vq, unsigned int i)
+{
+unsigned int next;
+
+/* If this descriptor says it doesn't chain, we're done. */
+if (!(vq-vring.desc[i].flags VRING_DESC_F_NEXT))
+ return vq-vring.num;
+
+/* Check they're not leading us off end of descriptors. */
+next = vq-vring.desc[i].next;
+/* Make sure compiler knows to grab that: we don't want it changing! */
+wmb();
+
+if (next = vq-vring.num)
+ errx(1, Desc next is %u, next);
+
+return next;
+}
+
+void virtqueue_push(VirtQueue *vq, const VirtQueueElement *elem,
+ unsigned int len)
+{
+VRingUsedElem *used;
+
+/* Get a pointer to the next entry in the used ring. */
+used = vq-vring.used-ring[vq-vring.used-idx % vq-vring.num];
+used-id = elem-index;
+used-len = len;
+/* Make sure buffer is written before we update index. */
+wmb();
+vq-vring.used-idx++;
+}
+
+int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
+{
+unsigned int i, head;
+unsigned int position;
+
+/* Check it isn't doing very strange things with descriptor numbers. */
+if ((uint16_t)(vq-vring.avail-idx - vq-last_avail_idx) vq-vring.num)
+ errx(1, Guest moved used index from %u to %u,
+ vq-last_avail_idx, vq-vring.avail-idx);
+
+/* If there's nothing new since last we looked, return invalid. */
+if (vq-vring.avail-idx == vq-last_avail_idx)
+ return 0;
+
+/* Grab the next descriptor number they're advertising, and increment
+ * the index we've
[Qemu-devel] [PATCH 3/3] virtio block device
Subject: [PATCH 3/3] virtio block device
Cc: Rusty Russell [EMAIL PROTECTED]
Cc: Avi Kivity [EMAIL PROTECTED]
Cc: Dor Laor [EMAIL PROTECTED]
This patch implements the backend support for the virtio block device. It's
designed to support in-order queueing of a virtually unlimited size so it will
be able to perform better than SCSI. Besides performance, the virtio block
interface passes through guest SCSI commands so it can be used to expose any
type of block device (although only normal disks are supported in this patch).
Index: qemu/Makefile.target
===
--- qemu.orig/Makefile.target 2007-12-04 14:17:37.0 -0600
+++ qemu/Makefile.target 2007-12-04 14:18:57.0 -0600
@@ -436,7 +436,7 @@
VL_OBJS += rtl8139.o
# virtio devices
-VL_OBJS += virtio.o virtio-net.o
+VL_OBJS += virtio.o virtio-net.o virtio-blk.o
ifeq ($(TARGET_BASE_ARCH), i386)
# Hardware support
Index: qemu/hw/virtio-blk.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ qemu/hw/virtio-blk.c 2007-12-04 14:22:36.0 -0600
@@ -0,0 +1,163 @@
+/*
+ * Virtio Block Device
+ *
+ * Copyright IBM, Corp. 2007
+ *
+ * Authors:
+ * Anthony Liguori [EMAIL PROTECTED]
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include virtio.h
+#include block.h
+#include pc.h
+
+/* from Linux's linux/virtio_blk.h */
+
+/* The ID for virtio_block */
+#define VIRTIO_ID_BLOCK 2
+
+/* Feature bits */
+#define VIRTIO_BLK_F_BARRIER 0 /* Does host support barriers? */
+#define VIRTIO_BLK_F_SIZE_MAX 1 /* Indicates maximum segment size */
+#define VIRTIO_BLK_F_SEG_MAX 2 /* Indicates maximum # of segments */
+
+struct virtio_blk_config
+{
+uint64_t capacity;
+uint32_t size_max;
+uint32_t seg_max;
+};
+
+/* These two define direction. */
+#define VIRTIO_BLK_T_IN 0
+#define VIRTIO_BLK_T_OUT 1
+
+/* This bit says it's a scsi command, not an actual read or write. */
+#define VIRTIO_BLK_T_SCSI_CMD 2
+
+/* Barrier before this op. */
+#define VIRTIO_BLK_T_BARRIER 0x8000
+
+/* This is the first element of the read scatter-gather list. */
+struct virtio_blk_outhdr
+{
+/* VIRTIO_BLK_T* */
+uint32_t type;
+/* io priority. */
+uint32_t ioprio;
+/* Sector (ie. 512 byte offset) */
+uint64_t sector;
+/* Where to put reply. */
+uint64_t id;
+};
+
+#define VIRTIO_BLK_S_OK 0
+#define VIRTIO_BLK_S_IOERR 1
+#define VIRTIO_BLK_S_UNSUPP 2
+
+/* This is the first element of the write scatter-gather list */
+struct virtio_blk_inhdr
+{
+unsigned char status;
+};
+
+typedef struct VirtIOBlock
+{
+VirtIODevice vdev;
+BlockDriverState *bs;
+} VirtIOBlock;
+
+static VirtIOBlock *to_virtio_blk(VirtIODevice *vdev)
+{
+return (VirtIOBlock *)vdev;
+}
+
+static void virtio_blk_handle_output(VirtIODevice *vdev, VirtQueue *vq)
+{
+VirtIOBlock *s = to_virtio_blk(vdev);
+VirtQueueElement elem;
+unsigned int count;
+
+while ((count = virtqueue_pop(vq, elem)) != 0) {
+ struct virtio_blk_inhdr *in;
+ struct virtio_blk_outhdr *out;
+ unsigned int wlen;
+ off_t off;
+ int i;
+
+ out = (void *)elem.out_sg[0].iov_base;
+ in = (void *)elem.in_sg[elem.in_num - 1].iov_base;
+ off = out-sector;
+
+ if (out-type VIRTIO_BLK_T_SCSI_CMD) {
+ wlen = sizeof(*in);
+ in-status = VIRTIO_BLK_S_UNSUPP;
+ } else if (out-type VIRTIO_BLK_T_OUT) {
+ wlen = sizeof(*in);
+
+ for (i = 1; i elem.out_num; i++) {
+ bdrv_write(s-bs, off,
+ elem.out_sg[i].iov_base,
+ elem.out_sg[i].iov_len / 512);
+ off += elem.out_sg[i].iov_len / 512;
+ }
+
+ in-status = VIRTIO_BLK_S_OK;
+ } else {
+ wlen = sizeof(*in);
+
+ for (i = 0; i elem.in_num - 1; i++) {
+ bdrv_read(s-bs, off,
+ elem.in_sg[i].iov_base,
+ elem.in_sg[i].iov_len / 512);
+ off += elem.in_sg[i].iov_len / 512;
+ wlen += elem.in_sg[i].iov_len;
+ }
+
+ in-status = VIRTIO_BLK_S_OK;
+ }
+
+ virtqueue_push(vq, elem, wlen);
+ virtio_notify(vdev, vq);
+}
+}
+
+static void virtio_blk_update_config(VirtIODevice *vdev, uint8_t *config)
+{
+VirtIOBlock *s = to_virtio_blk(vdev);
+struct virtio_blk_config blkcfg;
+int64_t capacity;
+
+bdrv_get_geometry(s-bs, capacity);
+blkcfg.capacity = capacity;
+blkcfg.seg_max = 128 - 2;
+memcpy(config, blkcfg, sizeof(blkcfg));
+}
+
+static uint32_t virtio_blk_get_features(VirtIODevice *vdev)
+{
+return (1 VIRTIO_BLK_F_SEG_MAX);
+}
+
+void *virtio_blk_init(PCIBus *bus, uint16_t vendor, uint16_t device,
+ BlockDriverState *bs)
+{
+VirtIOBlock *s;
+
+s = (VirtIOBlock *)virtio_init_pci(bus, virtio-blk, 6900, 0x1001,
+ 0, VIRTIO_ID_BLOCK,
+ 0x01, 0x80, 0x00,
+ 16, sizeof(VirtIOBlock));
+
+s-vdev.update_config = virtio_blk_update_config;
+s-vdev.get_features = virtio_blk_get_features;
+
Re: [Qemu-devel] Re: gcc
On 04/12/2007, Antti P Miettinen [EMAIL PROTECTED] wrote: Rick Vernam [EMAIL PROTECTED] writes: any comments on the current status of moving beyond dependency on GCC 3.3.6? Sorry for a vague ignorant question, but would the gcc-4 issues be affected in any way if the ops were inside a big function (use labels to find them) vs the current use of separate functions? They might likely be affected but it would be an equally fragile and compiler-dependent solution and I think not worth putting the time it would take to adapt dyngen to this. Regards
Re: [Qemu-devel] [PATCH 2/3] virtio network device
Anthony Liguori wrote: Subject: [PATCH 2/3] virtio network device Cc: Rusty Russell [EMAIL PROTECTED] Cc: Avi Kivity [EMAIL PROTECTED] Cc: Dor Laor [EMAIL PROTECTED] This patch implements the backend support for the virtio network device. The device is optimized for virtualized environments by limiting the number of guest=host transitions per-packet. In the best case, the number of transitions per-packet is 1. With some further optimizations, I have been able to obtain 1.5gbit/sec host=guest with this driver (compared to the 90mbit/sec from the rtl8139 card). This requires additional patches not present in this series. Let me qualify that these numbers are with KVM. I haven't done performance testing using CPU emulation. Regards, Anthony Liguori
Re: [Qemu-devel] Re: gcc
Hi, On Tue, 4 Dec 2007, Antti P Miettinen wrote: Rick Vernam [EMAIL PROTECTED] writes: any comments on the current status of moving beyond dependency on GCC 3.3.6? Sorry for a vague ignorant question, but would the gcc-4 issues be affected in any way if the ops were inside a big function (use labels to find them) vs the current use of separate functions? It might be a bit outdated, but the basic ideas still hold valid in http://libvncserver.sourceforge.net/qemu/qemu-porting.html. So no, you cannot have the ops inside a big function. Hth, Dscho
Re: [Qemu-devel] Re: gcc
Hi, On Tue, 4 Dec 2007, Johannes Schindelin wrote: On Tue, 4 Dec 2007, Antti P Miettinen wrote: Rick Vernam [EMAIL PROTECTED] writes: any comments on the current status of moving beyond dependency on GCC 3.3.6? Sorry for a vague ignorant question, but would the gcc-4 issues be affected in any way if the ops were inside a big function (use labels to find them) vs the current use of separate functions? It might be a bit outdated, but the basic ideas still hold valid in http://libvncserver.sourceforge.net/qemu/qemu-porting.html. So no, you cannot have the ops inside a big function. I realise that I was not quite clear enough... gcc4 has this annoying behaviour that it occasionally puts in return statements in the middle of the function. There seems to be no option to prevent that. And this behaviour is not helped by having one function rather than many. Hth, Dscho
[Qemu-devel] [PATCH] Support alternative formats for MAC addresses
The attached patch modifies the parser function for the mac addresses (ie. -net
nic,macaddr=XX) in the following ways:
- the accepted separators now include -, because on Windows it is common to
write a MAC addresses separated by dashes (ie. 54-32-00-12-34-56)
- it supports specifying the lower part of the MAC address (ie. the last three
bytes) as an integer number (so that you can say -net nic,macaddr=0x1234, which
would result in the mac address of 54-32-00-00-12-34). This simplifies the
situations where you want to connect together multiple Qemu virtual machines
and you want an easy way to ensure that they network cards don't have colliding
MAC addresses (simpler than having to retype the whole address)
Any comments are welcome.
__
Sent from Yahoo! - the World's favourite mail http://uk.mail.yahoo.com
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.376
diff -u -r1.376 vl.c
--- vl.c 4 Dec 2007 00:10:34 - 1.376
+++ vl.c 4 Dec 2007 22:58:58 -
@@ -3452,18 +3452,32 @@
static int parse_macaddr(uint8_t *macaddr, const char *p)
{
int i;
-for(i = 0; i 6; i++) {
-macaddr[i] = strtol(p, (char **)p, 16);
-if (i == 5) {
-if (*p != '\0')
-return -1;
-} else {
-if (*p != ':')
-return -1;
-p++;
-}
+char *last_char;
+long int offset;
+
+errno = 0;
+offset = strtol(p, last_char, 0);
+if ((0 == errno) ('\0' == *last_char) (offset = 0) (offset = 0xFF)) {
+ macaddr[3] = (offset 0xFF) 16;
+ macaddr[4] = (offset 0xFF00) 8;
+ macaddr[5] = offset 0xFF;
+ return 0;
+} else {
+ for(i = 0; i 6; i++) {
+ macaddr[i] = strtol(p, (char **)p, 16);
+ if (i == 5) {
+ if (*p != '\0')
+ return -1;
+ } else {
+ if (*p != ':' *p != '-')
+ return -1;
+ p++;
+ }
+ }
+ return 0;
}
-return 0;
+
+return -1;
}
static int get_str_sep(char *buf, int buf_size, const char **pp, int sep)
Re: [Qemu-devel] [PATCH] sparc32 machine specific maximums
Blue Swirl wrote: On 12/4/07, Robert Reif [EMAIL PROTECTED] wrote: I would be surprised if an SMP kernel actually worked on a multi CPU SS5. Prepare for a surprise: That's interesting because the fact that it works shows how inaccurate the emulation is. Now could you please really surprise me by booting Solaris 2.5 using a real sun openprom image ;-)
[Qemu-devel] Re: [PATCH 0/3] virtio support for QEMU
Anthony Liguori wrote: This patch series adds support for paravirtual device drivers that use virtio. virtio is a frame work in Linux for abstracting the details of virtual IO so that a single device driver (like networking) can be used with multiple hypervisors using a small shim layer. Currently, Linux supports a virtio network and a virtio block device and a shim layer for lguest. I have a PCI shim layer for virtio that is suitable for use in QEMU. This is currently in Rusty Russell's virtio tree awaiting the Linux merge window to open again. Regards, Anthony Liguori Hi Anthony, Rusty, Can you set up an uptodate git repository for the kernel part, other community members will also benefit. I got an oops for vring_kick immediately on the first pkt while testing this patchset. Going to debug it tomorrow, hopefully it's not because of patching. Thanks, Dor.
[Qemu-devel] Re: [PATCH 1/3] virtio infrastructure
Anthony Liguori wrote:
Subject: [PATCH 1/3] virtio infrastructure
Cc: Rusty Russell [EMAIL PROTECTED]
Cc: Avi Kivity [EMAIL PROTECTED]
Cc: Dor Laor [EMAIL PROTECTED]
This patch implements the basic infrastructure for virtio devices. These
devices are exposed to the guest as real PCI devices. The PCI vendor/device
IDs have been donated by Qumranet and the subsystem IDs are used to distinguish
the virtio device itself.
Virtio provides an abstraction for performing guest=host and host=guest
communications. It also provides a standard ring queue interface and discovery
mechanism. Finally, virtio provides a simple mechanism for passing
configuration between host and guest.
In this virtio implementation, we provide these things via normal PCI
operations. The Linux kernel support for this virtio device is pending in
Rusty's virtio patch queue[1]. They should be submitted once the merge window
opens again.
Some future TODOs are to use endian/alignment safe routines when accessing the
virtqueue so that mixed mode host/guests are supported.
[1] http://ozlabs.org/~rusty/kernel/hg
Index: qemu/Makefile.target
===
--- qemu.orig/Makefile.target 2007-12-04 10:00:43.0 -0600
+++ qemu/Makefile.target2007-12-04 14:15:20.0 -0600
@@ -435,6 +435,9 @@
VL_OBJS += pcnet.o
VL_OBJS += rtl8139.o
+# virtio devices
+VL_OBJS += virtio.o
+
ifeq ($(TARGET_BASE_ARCH), i386)
# Hardware support
VL_OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o
Index: qemu/hw/virtio.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ qemu/hw/virtio.c2007-12-04 14:17:15.0 -0600
@@ -0,0 +1,422 @@
[snip]
+#define VIRTIO_PCI_CONFIG 20
+
[snip]
+static void virtio_map(PCIDevice *pci_dev, int region_num,
+ uint32_t addr, uint32_t size, int type)
+{
+VirtIODevice *vdev = to_virtio_device(pci_dev);
+int i;
+
+vdev-addr = addr;
+for (i = 0; i 3; i++) {
+ register_ioport_write(addr, 20, 1 i, virtio_ioport_write, vdev);
+ register_ioport_read(addr, 20, 1 i, virtio_ioport_read, vdev);
Can you use VIRTIO_PCI_CONFIG instead of 20?
+}
+
+if (vdev-config_len) {
+ register_ioport_write(addr + 20, vdev-config_len, 1,
+ virtio_config_writeb, vdev);
+ register_ioport_write(addr + 20, vdev-config_len, 2,
+ virtio_config_writew, vdev);
+ register_ioport_write(addr + 20, vdev-config_len, 4,
+ virtio_config_writel, vdev);
+ register_ioport_read(addr + 20, vdev-config_len, 1,
+virtio_config_readb, vdev);
+ register_ioport_read(addr + 20, vdev-config_len, 2,
+virtio_config_readw, vdev);
+ register_ioport_read(addr + 20, vdev-config_len, 4,
+virtio_config_readl, vdev);
+
+ vdev-update_config(vdev, vdev-config);
+}
+}
+
+
I liked the push/pop functions, this encapsulation improves code
readability, cheers.
Dor.
+void virtqueue_push(VirtQueue *vq, const VirtQueueElement *elem,
+ unsigned int len);
+
+int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem);
+
+void virtio_notify(VirtIODevice *vdev, VirtQueue *vq);
+
+#endif
[Qemu-devel] Re: [PATCH 2/3] virtio network device
Anthony Liguori wrote:
Index: qemu/hw/virtio-net.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ qemu/hw/virtio-net.c2007-12-04 14:17:37.0 -0600
+
+static void virtio_net_receive(void *opaque, const uint8_t *buf, int size)
+{
+VirtIONet *n = opaque;
+VirtQueueElement elem;
+struct virtio_net_hdr *hdr;
+int offset, i;
+
+/* FIXME: the drivers really need to set their status better */
+if (n-rx_vq-vring.avail == NULL) {
+ n-can_receive = 0;
+ return;
+}
+
+if (virtqueue_pop(n-rx_vq, elem) == 0) {
+ /* wait until the guest adds some rx bufs */
+ n-can_receive = 0;
+ return;
+}
+
+hdr = (void *)elem.in_sg[0].iov_base;
+hdr-flags = 0;
+hdr-gso_type = VIRTIO_NET_HDR_GSO_NONE;
+
+/* copy in packet. ugh */
+offset = 0;
+i = 1;
+while (offset size i elem.in_num) {
+ int len = MIN(elem.in_sg[i].iov_len, size - offset);
+ memcpy(elem.in_sg[i].iov_base, buf + offset, len);
Actually according to qemu's standard, one should use cpu_physical_memory_write/
cpu_physical_memory_read functions.
This is true also for reading the ring values.
+ offset += len;
+ i++;
+}
+
+/* signal other side */
+virtqueue_push(n-rx_vq, elem, sizeof(*hdr) + offset);
+virtio_notify(n-vdev, n-rx_vq);
+}
+
+/* TX */
+static void virtio_net_handle_tx(VirtIODevice *vdev, VirtQueue *vq)
+{
+VirtIONet *n = to_virtio_net(vdev);
+VirtQueueElement elem;
+
+while (virtqueue_pop(vq, elem)) {
+ int i;
+ size_t len = 0;
+
+ /* ignore the header for now */
+ for (i = 1; i elem.out_num; i++) {
+ qemu_send_packet(n-vc, elem.out_sg[i].iov_base,
+elem.out_sg[i].iov_len);
+ len += elem.out_sg[i].iov_len;
+ }
+
+ virtqueue_push(vq, elem, sizeof(struct virtio_net_hdr) + len);
+ virtio_notify(n-vdev, vq);
+}
The virtio_notify should be left out of the while loop to minimize
irq injection.
+}
+
+void *virtio_net_init(PCIBus *bus, NICInfo *nd, int devfn)
+{
+VirtIONet *n;
+
+n = (VirtIONet *)virtio_init_pci(bus, virtio-net, 6900, 0x1000,
+0, VIRTIO_ID_NET,
+0x02, 0x00, 0x00,
+6, sizeof(VirtIONet));
+
+n-vdev.update_config = virtio_net_update_config;
+n-vdev.get_features = virtio_net_get_features;
+n-rx_vq = virtio_add_queue(n-vdev, 512, virtio_net_handle_rx);
+n-tx_vq = virtio_add_queue(n-vdev, 128, virtio_net_handle_tx);
+n-can_receive = 0;
+memcpy(n-mac, nd-macaddr, 6);
+n-vc = qemu_new_vlan_client(nd-vlan, virtio_net_receive,
+virtio_net_can_receive, n);
+
+return n-vdev;
+}
Index: qemu/hw/pc.h
===
--- qemu.orig/hw/pc.h 2007-12-04 14:15:20.0 -0600
+++ qemu/hw/pc.h2007-12-04 14:43:57.0 -0600
@@ -142,4 +142,9 @@
void isa_ne2000_init(int base, qemu_irq irq, NICInfo *nd);
+/* virtio-net.c */
+
+void *virtio_net_init(PCIBus *bus, NICInfo *nd, int devfn);
+
+
#endif
[Qemu-devel] Re: [PATCH 3/3] virtio block device
Anthony Liguori wrote:
Subject: [PATCH 3/3] virtio block device
+
+static void virtio_blk_handle_output(VirtIODevice *vdev, VirtQueue *vq)
+{
+VirtIOBlock *s = to_virtio_blk(vdev);
+VirtQueueElement elem;
+unsigned int count;
+
+while ((count = virtqueue_pop(vq, elem)) != 0) {
+ struct virtio_blk_inhdr *in;
+ struct virtio_blk_outhdr *out;
+ unsigned int wlen;
+ off_t off;
+ int i;
+
+ out = (void *)elem.out_sg[0].iov_base;
+ in = (void *)elem.in_sg[elem.in_num - 1].iov_base;
+ off = out-sector;
+
+ if (out-type VIRTIO_BLK_T_SCSI_CMD) {
+ wlen = sizeof(*in);
+ in-status = VIRTIO_BLK_S_UNSUPP;
+ } else if (out-type VIRTIO_BLK_T_OUT) {
+ wlen = sizeof(*in);
+
+ for (i = 1; i elem.out_num; i++) {
+ bdrv_write(s-bs, off,
+ elem.out_sg[i].iov_base,
+ elem.out_sg[i].iov_len / 512);
+ off += elem.out_sg[i].iov_len / 512;
+ }
+
+ in-status = VIRTIO_BLK_S_OK;
+ } else {
+ wlen = sizeof(*in);
+
+ for (i = 0; i elem.in_num - 1; i++) {
+ bdrv_read(s-bs, off,
+ elem.in_sg[i].iov_base,
+ elem.in_sg[i].iov_len / 512);
+ off += elem.in_sg[i].iov_len / 512;
+ wlen += elem.in_sg[i].iov_len;
+ }
+
+ in-status = VIRTIO_BLK_S_OK;
+ }
+
+ virtqueue_push(vq, elem, wlen);
+ virtio_notify(vdev, vq);
+}
The notify here should also be outside the while loop.
===
--- qemu.orig/sysemu.h 2007-12-04 13:51:49.0 -0600
+++ qemu/sysemu.h 2007-12-04 14:18:57.0 -0600
@@ -117,7 +117,7 @@
#endif
typedef enum {
-IF_IDE, IF_SCSI, IF_FLOPPY, IF_PFLASH, IF_MTD, IF_SD
+IF_IDE, IF_SCSI, IF_FLOPPY, IF_PFLASH, IF_MTD, IF_SD, IF_VIRTIO
} BlockInterfaceType;
typedef struct DriveInfo {
Index: qemu/hw/pc.c
===
--- qemu.orig/hw/pc.c 2007-12-04 13:51:49.0 -0600
+++ qemu/hw/pc.c2007-12-04 14:18:57.0 -0600
@@ -1008,6 +1008,18 @@
}
}
}
+
+/* Add virtio block devices */
+if (pci_enabled) {
+ int index;
+ int unit_id = 0;
+
+ while ((index = drive_get_index(IF_VIRTIO, 0, unit_id)) != -1) {
+ virtio_blk_init(pci_bus, 0x5002, 0x2258,
The pci vendor id should be identical to the network (0x6900)
regards,
Dor.
[Qemu-devel] Re: [PATCH 0/3] virtio support for QEMU
Dor Laor wrote: Anthony Liguori wrote: This patch series adds support for paravirtual device drivers that use virtio. virtio is a frame work in Linux for abstracting the details of virtual IO so that a single device driver (like networking) can be used with multiple hypervisors using a small shim layer. Currently, Linux supports a virtio network and a virtio block device and a shim layer for lguest. I have a PCI shim layer for virtio that is suitable for use in QEMU. This is currently in Rusty Russell's virtio tree awaiting the Linux merge window to open again. Regards, Anthony Liguori Hi Anthony, Rusty, Can you set up an uptodate git repository for the kernel part, other community members will also benefit. I got an oops for vring_kick immediately on the first pkt while testing this patchset. Going to debug it tomorrow, hopefully it's not because of patching. Yeah, patches are required that aren't yet in Rusty's queue. I'll update the list once we've gotten his queue straightened out. The oops is most certainly from the use of unsigned int in vring_init instead of unsigned long. I have a patch on [EMAIL PROTECTED] for that but I don't think Rusty's pulled it in yet. Regards, Anthony Liguori Thanks, Dor.
[Qemu-devel] Re: [PATCH 3/3] virtio block device
Dor Laor wrote:
Anthony Liguori wrote:
Subject: [PATCH 3/3] virtio block device
+
+static void virtio_blk_handle_output(VirtIODevice *vdev, VirtQueue *vq)
+{
+VirtIOBlock *s = to_virtio_blk(vdev);
+VirtQueueElement elem;
+unsigned int count;
+
+while ((count = virtqueue_pop(vq, elem)) != 0) {
+ struct virtio_blk_inhdr *in;
+ struct virtio_blk_outhdr *out;
+ unsigned int wlen;
+ off_t off;
+ int i;
+
+ out = (void *)elem.out_sg[0].iov_base;
+ in = (void *)elem.in_sg[elem.in_num - 1].iov_base;
+ off = out-sector;
+
+ if (out-type VIRTIO_BLK_T_SCSI_CMD) {
+ wlen = sizeof(*in);
+ in-status = VIRTIO_BLK_S_UNSUPP;
+ } else if (out-type VIRTIO_BLK_T_OUT) {
+ wlen = sizeof(*in);
+
+ for (i = 1; i elem.out_num; i++) {
+ bdrv_write(s-bs, off,
+ elem.out_sg[i].iov_base,
+ elem.out_sg[i].iov_len / 512);
+ off += elem.out_sg[i].iov_len / 512;
+ }
+
+ in-status = VIRTIO_BLK_S_OK;
+ } else {
+ wlen = sizeof(*in);
+
+ for (i = 0; i elem.in_num - 1; i++) {
+ bdrv_read(s-bs, off,
+ elem.in_sg[i].iov_base,
+ elem.in_sg[i].iov_len / 512);
+ off += elem.in_sg[i].iov_len / 512;
+ wlen += elem.in_sg[i].iov_len;
+ }
+
+ in-status = VIRTIO_BLK_S_OK;
+ }
+
+ virtqueue_push(vq, elem, wlen);
+ virtio_notify(vdev, vq);
+}
The notify here should also be outside the while loop.
Yeah, that's in the optimization patch.
===
--- qemu.orig/sysemu.h 2007-12-04 13:51:49.0 -0600
+++ qemu/sysemu.h 2007-12-04 14:18:57.0 -0600
@@ -117,7 +117,7 @@
#endif
typedef enum {
-IF_IDE, IF_SCSI, IF_FLOPPY, IF_PFLASH, IF_MTD, IF_SD
+IF_IDE, IF_SCSI, IF_FLOPPY, IF_PFLASH, IF_MTD, IF_SD, IF_VIRTIO
} BlockInterfaceType;
typedef struct DriveInfo {
Index: qemu/hw/pc.c
===
--- qemu.orig/hw/pc.c 2007-12-04 13:51:49.0 -0600
+++ qemu/hw/pc.c2007-12-04 14:18:57.0 -0600
@@ -1008,6 +1008,18 @@
}
}
}
+
+/* Add virtio block devices */
+if (pci_enabled) {
+ int index;
+ int unit_id = 0;
+
+ while ((index = drive_get_index(IF_VIRTIO, 0, unit_id)) != -1) {
+ virtio_blk_init(pci_bus, 0x5002, 0x2258,
The pci vendor id should be identical to the network (0x6900)
Indeed! That's for catching that.
Regards,
Anthony Liguori
regards,
Dor.
[Qemu-devel] qemu/hw irq.h omap.c omap.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/12/05 03:23:39 Modified files: hw : irq.h omap.c omap.h Log message: Rework OMAP1 interrupt handling to allow multiple interrupt banks, by Lauro Ramos Venancio. Add irq pulse shortcut, by Lauro Ramos Venancio. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/irq.h?cvsroot=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap.c?cvsroot=qemur1=1.28r2=1.29 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap.h?cvsroot=qemur1=1.19r2=1.20
Re: [Qemu-devel] and now bus error for i386 guest
HI,
Blue Swirl wrote:
On 11/14/07, Shaddy Baddah [EMAIL PROTECTED] wrote:
Hi again,
After further culling the target list, I was able to install qemu on my
sun4u host.
However, running it, I get a bus error. See below for details:
$ /opt/qemu-cvs/bin/qemu -m 128 -cdrom
~/KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -vnc :1
Bus error
For some reason, Sparc Linux host is not working. I think Sparc Solaris is OK.
Yes, I do recall that I was able to get this working on Sparc Solaris.
Anyway, when I get more time, I will have a better stab at debugging
this. I got a start on this today, and here is a bit of cut and paste
that may or may not be insightful. The address for env1 looks questionable:
[EMAIL PROTECTED]:~/qemu-cvs/qemu-build$ gdb --args ./i386-softmmu/qemu
-hda ../../KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -L ../qemu/pc-bios
GNU gdb 6.6.90.20070912-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as sparc-linux-gnu...
Using host libthread_db library /lib/libthread_db.so.1.
(gdb) run
Starting program: /home/shaddy/qemu-cvs/qemu-build/i386-softmmu/qemu
-hda ../../KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -L ../qemu/pc-bios
[Thread debugging using libthread_db enabled]
[New Thread 0xf7f7b550 (LWP 9363)]
Program received signal SIGBUS, Bus error.
[Switching to Thread 0xf7f7b550 (LWP 9363)]
cpu_x86_exec (env1=0x2) at /home/shaddy/qemu-cvs/qemu/cpu-exec.c:307
307 if (env-exception_index = 0) {
(gdb) info threads
* 1 Thread 0xf7f7b550 (LWP 9363) cpu_x86_exec (env1=0x2)
at /home/shaddy/qemu-cvs/qemu/cpu-exec.c:307
(gdb)
HTH,
Shaddy
PS: couldn't this also be debugged from within qemu VM running Debian
Sparc, for those that don't have access to a real machine? I got a start
on this today as well (because I don't always have access to the Sun
Ultra box). Seems stable, and I was able to get a start on a compile,
that is currently still going.
