Re: [Qemu-devel] [PATCH] Capture traffic to a pcap file

[Balazs Attila-Mihaly (Cd-MaN)]

>> This patch allows to capture the traffic flowing through a particular
 vlan in a tcpdump compatible pcap file.
>>
>> The patch is identical to the one created some time back, however it
 was updated to apply to HEAD.
>>
>> Usage: -net nic,pcap=capture_file.pcap
>>   

> I like the idea but I think it would be more useful as a monitor
 command 
> similar to how the audio capture command works already.


Good idea. I will create a patch to update that feature too (but the command 
line should be left in IMHO, because there are use-cases where you would want 
to start such a capture in an automated way - ie. a honeypot)




  ___
Support the World Aids Awareness campaign this month with Yahoo! For Good 
http://uk.promotions.yahoo.com/forgood/

[Qemu-devel] QEMU problem ...

[dara burke]

Hi,

I've got a problem with Qemu, it won't seem to work on my ubuntu
system. It can't seem to find the framebuffer device ...

[EMAIL PROTECTED]:~/qemu_dir$ qemu -localtime -cdrom /dev/cdrom -m 384 -boot d 
c.img
Warning: No DNS servers found

   -- DirectFB v0.9.25 -
 (c) 2000-2002  convergence integrated media GmbH
 (c) 2002-2004  convergence GmbH
---

(*) DirectFB/Core: Single Application Core. (2007-08-07 19:21)
(*) Direct/Memcpy: Using linux kernel memcpy()
(!) Direct/Util: opening '/dev/fb0' and '/dev/fb/0' failed
--> No such file or directory
(!) DirectFB/FBDev: Error opening framebuffer device!
(!) DirectFB/FBDev: Use 'fbdev' option or set FRAMEBUFFER environment variable.
(!) DirectFB/Core: Could not initialize 'system' core!
--> Initialization error!
Could not initialize SDL - exiting

Does anyone have any ideas ?

Thanks,

Dara

[Qemu-devel] EFI BIOS on QEMU

[Kuniyasu Suzaki]

Hello,

We tried EFI BIOS on QEMU.
  http://bellard.org/qemu/efi-bios.tar.bz2

It' fine but the network is not effective. The "devices" command of EFI
does not find a NIC.
# Linux can not set up also network.

Please tell me how to solve this problem. I will re-compile EFI BIOS if 
necessary.

We want to try EFI toolkit on QEMU because EFI toolkit has many
commands for network. They were effective on EFI on IntelMac.
  https://efi-toolkit.tianocore.org/

--
suzaki

Re: [Qemu-devel] and now bus error for i386 guest

[Shaddy Baddah]

Hi,

Blue Swirl wrote:

On 12/5/07, Shaddy Baddah <[EMAIL PROTECTED]> wrote:

0x1e958 :   ld  [ %l6 + 0x8c ], %l1
0x1e95c :   call  0xa90b4 
0x1e960 :   mov  %l1, %o0


Maybe you missed the effect of the delay slot. The first argument is
prepared in %l1 and moved to %o0 in the delay slot of the call
instruction.
You'll have to forgive me... although I know about the delay slot, I 
only slightly dabble in assembly, so I am not so confident at reading 
it. Reading this to mean that perhaps the assignment would be effected 
after execution of a further instruction, I've redone the debugging, and 
include it below:


$ gdb --args ./i386-softmmu/qemu -cdrom 
../../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 


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)
(gdb) break vl.c:7362
Breakpoint 1 at 0x1e958: file /home/shaddy/qemu-cvs/qemu/vl.c, line 7362.
(gdb) display /i $pc
(gdb) run
Starting program: /home/shaddy/qemu-cvs/qemu-optbuild/i386-softmmu/qemu 
-cdrom ../../KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -L ../qemu/pc-bios

[Thread debugging using libthread_db enabled]
[New Thread 0xf7f27550 (LWP 15523)]
[Switching to Thread 0xf7f27550 (LWP 15523)]

Breakpoint 1, main (argc=1430528, argv=0x15d400) at 
/home/shaddy/qemu-cvs/qemu/vl.c:7362

7362env = next_cpu;
1: x/i $pc
0x1e958 :   ld  [ %l6 + 0x8c ], %l1
(gdb) print /x env
$1 = 0x322e3100
(gdb) print /x next_cpu
$2 = 0x1cd13e8
(gdb) stepi
7366ret = cpu_exec(env);
1: x/i $pc
0x1e95c :   call  0xa90b4 
0x1e960 :   mov  %l1, %o0
(gdb)
0x0001e960  7366ret = cpu_exec(env);
1: x/i $pc
0x1e960 :   mov  %l1, %o0
(gdb) print /x next_cpu
$3 = 0x1cd13e8
(gdb) print /x env
$4 = 0x322e3100
(gdb) print /x &env
Address requested for identifier "env" which is in register $g6
(gdb) print $g6
$5 = 841888000
(gdb) print /x $g6
$6 = 0x322e3100
(gdb) stepi
cpu_x86_exec (env1=0x117000) at /home/shaddy/qemu-cvs/qemu/cpu-exec.c:244
244 {
1: x/i $pc
0xa90b4 : add  %sp, -232, %sp
(gdb) print /x $g6
$7 = 0x322e3100
(gdb) stepi
0x000a90b8 in cpu_x86_exec (env1=0x117000) at 
/home/shaddy/qemu-cvs/qemu/cpu-exec.c:244

244 {
1: x/i $pc
0xa90b8 :   st  %i7, [ %sp + 0x60 ]
(gdb) print /x $g6
$8 = 0x322e3100
(gdb) stepi
0x000a90bc  244 {
1: x/i $pc
0xa90bc :   sub  %sp, -232, %i7
(gdb) print /x $g6
$9 = 0x322e3100
(gdb)

I still read that as failing to assign the value. Given my limited 
knowledge, how is gdb so adamantly stating that env1=0x117000 when the 
value of env1 (i.e. env in the calling function) is only known after the 
delay slot instruction is completed? That's more a rhetorical 
question... I've got to do a bit of research to be able to know these 
things myself.



0x240a4 :sethi  %hi(0x258800), %g4
0x240a8 :or  %g4, 0x4c, %g4  ! 0x25884c
0x240ac :ld  [ %g4 ], %g4
0x240b0 :st  %g4, [ %fp + -20 ]
0x240b4 :ld  [ %fp + -20 ], %o0
0x240b8 :call  0x14fa64 
0x240bc :nop


This looks like equivalent code, only dumber version using an
intermediate store and not using the delay slot.
Sure. However, what do you read of gdb determining that the value for 
env in the parameters to the cpu_exec call being different to its value 
in the calling function?


Regards,
Shaddy

[Qemu-devel] [PATCH 2/2] Use extboot to support -kernel

[Anthony Liguori]

This patch uses the extboot option ROM to support -kernel.  Instead of 
hijacking the first boot sector of the first IDE drive, we use extboot 
to read the boot sector from an in-memory block device.  This eliminates 
the need to have an IDE device (or any device) configured when using 
-kernel.


This depends on the extboot series I posted today.

Regards,

Anthony Liguori
Index: qemu/hw/pc.c
===
--- qemu.orig/hw/pc.c	2007-12-05 15:53:35.0 -0600
+++ qemu/hw/pc.c	2007-12-05 15:59:32.0 -0600
@@ -383,20 +383,26 @@
 static void generate_bootsect(uint32_t gpr[8], uint16_t segs[6], uint16_t ip)
 {
 uint8_t bootsect[512], *p;
-int i;
-int hda;
+BlockDriverState *bs;
+int i, cyls, heads, secs;
 
-hda = drive_get_index(IF_IDE, 0, 0);
-if (hda == -1) {
-	fprintf(stderr, "A disk image must be given for 'hda' when booting "
-		"a Linux kernel\n");
+/* Create a device with at least one cylinder */
+bs = bdrv_new("mem");
+if (bdrv_mem_open(bs, 63 * 512) == -1) {
+	fprintf(stderr, "Error initializing memory block device\n");
 	exit(1);
 }
 
-memset(bootsect, 0, sizeof(bootsect));
-
 /* Copy the MSDOS partition table if possible */
-bdrv_read(drives_table[hda].bdrv, 0, bootsect, 1);
+bdrv_read(bs, 0, bootsect, 1);
+
+/* Setup extboot to boot from the memory block device */
+bdrv_guess_geometry(bs, &cyls, &heads, &secs);
+bdrv_set_geometry_hint(bs, cyls, heads, secs);
+extboot_init(bs, 1);
+
+/* Prevent double initialization */
+extboot_drive = -1;
 
 /* Make sure we have a partition signature */
 bootsect[510] = 0x55;
@@ -433,7 +439,7 @@
 *p++ = segs[1];		/* CS */
 *p++ = segs[1] >> 8;
 
-bdrv_set_boot_sector(drives_table[hda].bdrv, bootsect, sizeof(bootsect));
+bdrv_write(bs, 0, bootsect, 1);
 }
 
 static int load_kernel(const char *filename, uint8_t *addr,
@@ -834,7 +840,7 @@
 for (i = 0; i < nb_option_roms; i++)
 	opt_rom_offset += load_option_rom(option_rom[i], opt_rom_offset);
 
-if (extboot_drive != -1) {
+if (extboot_drive != -1 || linux_boot) {
 	snprintf(buf, sizeof(buf), "%s/%s", bios_dir, EXTBOOT_FILENAME);
 	opt_rom_offset += load_option_rom(buf, opt_rom_offset);
 }

[Qemu-devel] [PATCH 1/2] Add an in-memory block device

[Anthony Liguori]

This is a generic in-memory block device.  It is needed by the next patch.

Regards,

Anthony Liguori
Index: qemu/Makefile
===
--- qemu.orig/Makefile	2007-12-05 15:39:09.0 -0600
+++ qemu/Makefile	2007-12-05 15:39:39.0 -0600
@@ -40,7 +40,7 @@
 BLOCK_OBJS=cutils.o
 BLOCK_OBJS+=block-cow.o block-qcow.o aes.o block-vmdk.o block-cloop.o
 BLOCK_OBJS+=block-dmg.o block-bochs.o block-vpc.o block-vvfat.o
-BLOCK_OBJS+=block-qcow2.o block-parallels.o
+BLOCK_OBJS+=block-qcow2.o block-parallels.o block-mem.o
 
 ##
 # libqemu_common.a: Target indepedent part of system emulation. The
Index: qemu/block-mem.c
===
--- /dev/null	1970-01-01 00:00:00.0 +
+++ qemu/block-mem.c	2007-12-05 15:54:02.0 -0600
@@ -0,0 +1,99 @@
+/*
+ * In-memory block driver
+ *
+ * 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 "qemu-common.h"
+#include "block_int.h"
+
+typedef struct BDRVMemState {
+void *mem;
+size_t size;
+} BDRVMemState;
+
+static int mem_probe(const uint8_t *buf, int buf_size, const char *filename)
+{
+return 0;
+}
+
+static int mem_open(BlockDriverState *bs, const char *filename, int flags)
+{
+return -1;
+}
+
+int bdrv_mem_open(BlockDriverState *bs, size_t size)
+{
+BDRVMemState *s;
+
+bs->read_only = 0;
+bs->is_temporary = 0;
+bs->encrypted = 0;
+pstrcpy(bs->filename, sizeof(bs->filename), "");
+bs->drv = &bdrv_mem;
+bs->total_sectors = ((size + 511) & ~511) / 512;
+
+bs->opaque = qemu_mallocz(bdrv_mem.instance_size);
+if (bs->opaque == NULL)
+	return -1;
+
+s = bs->opaque;
+s->mem = qemu_mallocz(size);
+if (s->mem == NULL)
+	return -1;
+s->size = size;
+
+return 0;
+}
+
+static int mem_read(BlockDriverState *bs, int64_t sector_num,
+		uint8_t *buf, int nb_sectors)
+{
+BDRVMemState *s = bs->opaque;
+size_t size;
+
+sector_num = MIN(sector_num, bs->total_sectors - 1);
+size = MIN(s->size - (sector_num * 512), nb_sectors * 512);
+
+memcpy(buf, s->mem + (sector_num * 512), size);
+
+return 0;
+}
+
+static int mem_write(BlockDriverState *bs, int64_t sector_num,
+		 const uint8_t *buf, int nb_sectors)
+{
+BDRVMemState *s = bs->opaque;
+size_t size;
+
+sector_num = MIN(sector_num, bs->total_sectors - 1);
+size = MIN(s->size - (sector_num * 512), nb_sectors * 512);
+
+memcpy(s->mem + (sector_num * 512), buf, size);
+
+return 0;
+}
+
+static void mem_close(BlockDriverState *bs)
+{
+BDRVMemState *s = bs->opaque;
+
+qemu_free(s->mem);
+}
+
+BlockDriver bdrv_mem = {
+"mem",
+sizeof(BDRVMemState),
+mem_probe,
+mem_open,
+mem_read,
+mem_write,
+mem_close,
+};
Index: qemu/block.h
===
--- qemu.orig/block.h	2007-12-05 15:38:48.0 -0600
+++ qemu/block.h	2007-12-05 15:47:36.0 -0600
@@ -16,6 +16,7 @@
 extern BlockDriver bdrv_vvfat;
 extern BlockDriver bdrv_qcow2;
 extern BlockDriver bdrv_parallels;
+extern BlockDriver bdrv_mem;
 
 typedef struct BlockDriverInfo {
 /* in bytes, 0 if irrelevant */
@@ -155,4 +156,6 @@
   const char *base_path,
   const char *filename);
 
+int bdrv_mem_open(BlockDriverState *bs, size_t size);
+
 #endif

Re: [Qemu-devel] and now bus error for i386 guest

[Blue Swirl]

On 12/5/07, Shaddy Baddah <[EMAIL PROTECTED]> wrote:
> 0x1e958 :   ld  [ %l6 + 0x8c ], %l1
> 0x1e95c :   call  0xa90b4 
> 0x1e960 :   mov  %l1, %o0

Maybe you missed the effect of the delay slot. The first argument is
prepared in %l1 and moved to %o0 in the delay slot of the call
instruction.

> 0x240a4 :sethi  %hi(0x258800), %g4
> 0x240a8 :or  %g4, 0x4c, %g4  ! 0x25884c
> 0x240ac :ld  [ %g4 ], %g4
> 0x240b0 :st  %g4, [ %fp + -20 ]
> 0x240b4 :ld  [ %fp + -20 ], %o0
> 0x240b8 :call  0x14fa64 
> 0x240bc :nop

This looks like equivalent code, only dumber version using an
intermediate store and not using the delay slot.

Re: [Qemu-devel] Online image backup

[Ricardo Almeida]

Hi,

Discalmer: I'm just a user of QEmu :) 

> Fabrice, that's just part of the problem.  A full automated remote
> backup service for qemu VMs should work like this:
>
>   1. send a "savevm state" command to qemu;
>   2. wait for savevm completion;

2.1 Switch to snapshot mode

>   3. perform an *online* copy (cp, rsync, whatever) of the .qcow2 image,
> while it's still running in qemu;

3.1 Pause VM
3.2 Apply snapshot changes to local and remote copy (remote must be
running something that can apply the update)
3.3 Back to normal mode

>   4. ...repeat for all running VMs.
>

[...]

> The weak spot of this configuration is the third step of backup: if you
> perform an online copy (and that's your only real choice, since you
> don't want to powerdown the VMs every night just to backup them), you
> are copying a file while it's always modifying, and chances are high
> that the copy will be corrupted (i.e. different from any state the
> original went through), since you can't perform the copy with a single read.

See the above added steps :)
Is this a bad idea?

Regards and keep up the good work :),
Ricardo Almeida

Re: [Qemu-devel] Re: [PATCH 2/3] virtio network device

[Anthony Liguori]

Paul Brook wrote:

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.
  

Yes, and unfortunately, cpu_physical_memory_{read,write} are copy
interfaces.  We really don't want that for high speed I/O.



I really don't like doing direct access to guest ram without implementing a 
proper API for zero-copy/scatter-gather access. There was a list thread about 
this not so long ago.
  


I agree that we need a proper API for sg ram access.  I'm going to look 
into that real soon since it's necessary to optimize the network/disk 
transports.


virtio makes things a bit trickier though.  There's a shared ring queue 
between the host and guest.  The ring queue is lock-less and depends on 
the ability to atomically increment ring queue indices to be SMP safe.  
Using a copy-API wouldn't be a problem for QEMU since the host and guest 
are always running in lock-step.  A copy API is actually needed to deal 
with differing host/guest alignment and endianness.


Once you introduce KVM though, this is no longer true since KVM supports 
true SMP.  The solution may be to implement some sort of 
atomic_increment function and then have that use a if (kvm) guard to do 
a direct access verses a copy.


Regards,

Anthony Liguori


Paul
  

[Qemu-devel] [PATCH] add rdpmc intercept for SVM

[Bernhard Kauer]

The attached patch adds an SVM intercept for rdpmc to qemu,
thus allowing a VMM to virtualize them. Please note that 
performance counters are currently unimplemented in qemu.


Bernhard Kauer
Index: target-i386/helper.c
--- target-i386/helper.c	18 Nov 2007 01:44:38 -	1.95
+++ target-i386/helper.c	5 Dec 2007 19:31:31 -
@@ -2743,6 +2816,19 @@
 EDX = (uint32_t)(val >> 32);
 }
 
+void helper_rdpmc()
+{
+  if ((env->cr[4] & CR4_PCE_MASK) && ((env->hflags & HF_CPL_MASK) != 0)) {
+raise_exception(EXCP0D_GPF);
+  }
+  
+  if (!svm_check_intercept_param(SVM_EXIT_RDPMC, 0))
+{
+  // currently unimplemented
+  raise_exception_err(EXCP06_ILLOP, 0);
+}
+}
+
 #if defined(CONFIG_USER_ONLY)
 void helper_wrmsr(void)
 {
Index: target-i386/op.c
--- target-i386/op.c	23 Sep 2007 15:28:04 -	1.51
+++ target-i386/op.c	5 Dec 2007 19:31:32 -
@@ -953,6 +953,11 @@
 helper_rdtsc();
 }
 
+void OPPROTO op_rdpmc(void)
+{
+helper_rdpmc();
+}
+
 void OPPROTO op_cpuid(void)
 {
 helper_cpuid();
Index: target-i386/translate.c
--- target-i386/translate.c	8 Nov 2007 14:25:03 -	1.74
+++ target-i386/translate.c	5 Dec 2007 19:31:38 -
@@ -5653,5 +5653,9 @@
 gen_op_rdtsc();
 break;
+case 0x133: /* rdpmc */
+gen_jmp_im(pc_start - s->cs_base);
+gen_op_rdpmc();
+break;
 case 0x134: /* sysenter */
 if (CODE64(s))
 goto illegal_op;

Re: [Qemu-devel] Re: [PATCH 2/3] virtio network device

[Paul Brook]

> > 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.
>
> Yes, and unfortunately, cpu_physical_memory_{read,write} are copy
> interfaces.  We really don't want that for high speed I/O.

I really don't like doing direct access to guest ram without implementing a 
proper API for zero-copy/scatter-gather access. There was a list thread about 
this not so long ago.

Paul

[Qemu-devel] Re: [PATCH 2/3] virtio network device

[Anthony Liguori]

Dor Laor wrote:

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.
  


Yes, and unfortunately, cpu_physical_memory_{read,write} are copy 
interfaces.  We really don't want that for high speed I/O.


The only down-sides of not using cpu_physical_memory_{read,write} is 
that writes aren't dispatched to MMIO functions and dirty updating isn't 
handled automatically.  I do need to go through an audit the dirty 
updating.  It may be possible to do a 1-time check of MMIO memory and 
then have a fast and slow path.  I'm not sure how much it matter honestly.


Regards,

Anthony Liguori




+   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] [PATCH 2/2] Option ROM for booting from SCSI/PV disks

[Anthony Liguori]

Hi,

The attached patch is an option ROM that allows x86 guests to boot from 
any block device supported by QEMU (and the guest kernel).  It works by 
hijacking the BIOS int13 function and then uses a very simply protocol 
to communicate all block requests to QEMU.


This patch also adds a "boot=on|off" parameter to the -drive option.  
When this option is specified, the extboot option ROM is automatically 
loaded and this device will be exposes by int13 as '0x80'.  What '-boot 
c' really means is boot from the first disk driver or BIOS drive '0x80' 
so the -boot option is complimentary to this new boot flag.


I have successfully booted Linux, Win2k, and WinXP from SCSI with this 
patch.  Windows takes a bit of prep work to be able to boot from SCSI.   
For win2k, you just need to make sure you have the right driver 
installed.  WinXP, however, seems to require that it be installed on 
SCSI to boot from SCSI.  If anyone knows how to modify WinXP after the 
fact, please let me know.


I can also use this new flag to boot a Linux guest from my previously 
posted virtio blk driver.


This patch is against my previous virtio patches but does not strictly 
depend on them.  When applying this patch, you'll have to build extboot 
in extboot/ and then copy extboot/extboot.bin to pc-bios/extboot.bin.


Regards,

Anthony Liguori
Index: qemu/extboot/Makefile
===
--- /dev/null	1970-01-01 00:00:00.0 +
+++ qemu/extboot/Makefile	2007-12-05 09:43:11.0 -0600
@@ -0,0 +1,21 @@
+OBJCOPY=objcopy
+
+CFLAGS=-Wall -Wstrict-prototypes -Werror -fomit-frame-pointer -fno-builtin \
+   -fno-stack-protector
+
+all: extboot.bin
+
+%.o: %.S
+	$(CC) $(CFLAGS) -o $@ -c $<
+
+extboot.img: extboot.o
+	$(LD) --oformat binary -Ttext 0 -o $@ $<
+
+extboot.bin: extboot.img signrom
+	./signrom extboot.img extboot.bin
+
+signrom: signrom.c
+	$(CC) -o $@ -g -Wall $^
+
+clean:
+	$(RM) *.o *.img *.bin signrom *~
Index: qemu/extboot/extboot.S
===
--- /dev/null	1970-01-01 00:00:00.0 +
+++ qemu/extboot/extboot.S	2007-12-05 09:43:11.0 -0600
@@ -0,0 +1,742 @@
+/*
+ * Extended Boot Option ROM
+ *
+ * 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, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Copyright IBM Corporation, 2007
+ *   Authors: Anthony Liguori <[EMAIL PROTECTED]>
+ */
+
+.code16
+.text
+	.global _start
+_start:
+	.short 0xaa55
+	.byte (_end - _start) / 512
+	push %ax
+	push %bx
+	push %cx
+	push %dx
+	push %ds
+
+	/* setup ds so we can access the IVT */
+	xor %ax, %ax
+	mov %ax, %ds
+
+	/* save old int 19 at int 2b */
+	mov $(0x19 * 4), %bx
+	mov 0(%bx), %ax
+	mov 2(%bx), %cx
+
+	mov $(0x2b * 4), %bx
+	mov %ax, 0(%bx)
+	mov %cx, 2(%bx)
+
+	/* install out int 19 handler */
+	mov $(0x19 * 4), %bx
+	mov $int19_handler, %ax
+	mov %ax, 0(%bx)
+	mov %cs, 2(%bx)
+
+	pop %ds	
+	pop %dx
+	pop %cx
+	pop %bx
+	pop %ax
+	lret
+
+int19_handler:
+	push %ax
+	push %bx
+	push %cx
+	push %dx
+	push %ds
+
+	movw $0x404, %dx
+	inb %dx, %al
+	cmp $1, %al
+	je 1f
+	cmp $2, %al
+	je 2f
+	jmp 3f
+
+1: /* hook int13: intb(0x404) == 1 */
+	/* setup ds to access IVT */
+	xor %ax, %ax
+	mov %ax, %ds
+
+	/* save old int 13 to int 2c */
+	mov $(0x13 * 4), %bx
+	mov 0(%bx), %ax
+	mov 2(%bx), %cx
+
+	mov $(0x2c * 4), %bx
+	mov %ax, 0(%bx)
+	mov %cx, 2(%bx)
+
+	/* install our int 13 handler */
+	mov $(0x13 * 4), %bx
+	mov $int13_handler, %ax
+
+	mov %ax, 0(%bx)
+	mov %cs, 2(%bx)
+	jmp 3f
+	
+2: /* linux boot: intb(0x404) == 2 */
+	cli
+	cld
+	mov $0x9000, %ax
+	mov %ax, %ds
+	mov %ax, %es
+	mov %ax, %fs
+	mov %ax, %gs
+	mov %ax, %ss
+	mov $0x8ffe, %sp
+	ljmp $0x9000 + 0x20, $0
+
+3: /* fall through: inb(0x404) == 0 */
+	pop %ds
+	pop %dx
+	pop %cx
+	pop %bx
+	pop %ax
+	int $0x2b
+
+#define FLAGS_CF	0x01
+	
+.macro clc
+	push %ax
+	pushf
+	pop %ax
+	and $(~FLAGS_CF), %ax
+	push %ax
+	popf
+	pop %ax
+.endm
+
+.macro stc
+	push %ax
+	pushf
+	pop %ax
+	or $(FLAGS_CF), %ax
+	push %ax
+	popf
+	pop %ax
+.endm
+
+/* we clobber %bx */
+.macro alloca size
+	push %ds
+	push %bp
+	mov %sp, %bp  /* remember the current stack position */
+	
+	mov %ss, %bx
+	mov %bx, %ds
+	
+	sub \size, %sp
+	and $(~0x0F), %sp
+	mov %sp, %bx
+	
+	push %bp
+	mov 0(%bp), %bp
+.endm
+
+/* we clobber %bp */
+.macro allo

[Qemu-devel] [PATCH 1/2] Refactor CHS guessing to be usable outside of IDE

[Anthony Liguori]

The next patch I post will require this patch.  It refactors the CHS 
guessing so it can be used by devices other than IDE.


Regards,

Anthony Liguori
Index: qemu/block.c
===
--- qemu.orig/block.c	2007-12-04 16:18:46.0 -0600
+++ qemu/block.c	2007-12-04 16:19:08.0 -0600
@@ -738,6 +738,122 @@
 memset(bs->boot_sector_data + size, 0, 512 - size);
 }
 
+struct partition {
+	uint8_t boot_ind;		/* 0x80 - active */
+	uint8_t head;		/* starting head */
+	uint8_t sector;		/* starting sector */
+	uint8_t cyl;		/* starting cylinder */
+	uint8_t sys_ind;		/* What partition type */
+	uint8_t end_head;		/* end head */
+	uint8_t end_sector;	/* end sector */
+	uint8_t end_cyl;		/* end cylinder */
+	uint32_t start_sect;	/* starting sector counting from 0 */
+	uint32_t nr_sects;		/* nr of sectors in partition */
+} __attribute__((packed));
+
+/* try to guess the disk logical geometry from the MSDOS partition table. Return 0 if OK, -1 if could not guess */
+static int guess_disk_lchs(BlockDriverState *bs,
+   int *pcylinders, int *pheads, int *psectors)
+{
+uint8_t buf[512];
+int ret, i, heads, sectors, cylinders;
+struct partition *p;
+uint32_t nr_sects;
+int64_t nb_sectors;
+
+bdrv_get_geometry(bs, &nb_sectors);
+
+ret = bdrv_read(bs, 0, buf, 1);
+if (ret < 0)
+return -1;
+/* test msdos magic */
+if (buf[510] != 0x55 || buf[511] != 0xaa)
+return -1;
+for(i = 0; i < 4; i++) {
+p = ((struct partition *)(buf + 0x1be)) + i;
+nr_sects = le32_to_cpu(p->nr_sects);
+if (nr_sects && p->end_head) {
+/* We make the assumption that the partition terminates on
+   a cylinder boundary */
+heads = p->end_head + 1;
+sectors = p->end_sector & 63;
+if (sectors == 0)
+continue;
+cylinders = nb_sectors / (heads * sectors);
+if (cylinders < 1 || cylinders > 16383)
+continue;
+*pheads = heads;
+*psectors = sectors;
+*pcylinders = cylinders;
+#if 0
+printf("guessed geometry: LCHS=%d %d %d\n",
+   cylinders, heads, sectors);
+#endif
+return 0;
+}
+}
+return -1;
+}
+
+void bdrv_guess_geometry(BlockDriverState *bs, int *pcyls, int *pheads, int *psecs)
+{
+int translation, lba_detected = 0;
+int cylinders, heads, secs;
+int64_t nb_sectors;
+
+/* if a geometry hint is available, use it */
+bdrv_get_geometry(bs, &nb_sectors);
+bdrv_get_geometry_hint(bs, &cylinders, &heads, &secs);
+translation = bdrv_get_translation_hint(bs);
+if (cylinders != 0) {
+	*pcyls = cylinders;
+	*pheads = heads;
+	*psecs = secs;
+} else {
+	if (guess_disk_lchs(bs, &cylinders, &heads, &secs) == 0) {
+	if (heads > 16) {
+		/* if heads > 16, it means that a BIOS LBA
+		   translation was active, so the default
+		   hardware geometry is OK */
+		lba_detected = 1;
+		goto default_geometry;
+	} else {
+		*pcyls = cylinders;
+		*pheads = heads;
+		*psecs = secs;
+		/* disable any translation to be in sync with
+		   the logical geometry */
+		if (translation == BIOS_ATA_TRANSLATION_AUTO) {
+		bdrv_set_translation_hint(bs,
+	  BIOS_ATA_TRANSLATION_NONE);
+		}
+	}
+	} else {
+	default_geometry:
+	/* if no geometry, use a standard physical disk geometry */
+	cylinders = nb_sectors / (16 * 63);
+
+	if (cylinders > 16383)
+	cylinders = 16383;
+	else if (cylinders < 2)
+	cylinders = 2;
+	*pcyls = cylinders;
+	*pheads = 16;
+	*psecs = 63;
+	if ((lba_detected == 1) && (translation == BIOS_ATA_TRANSLATION_AUTO)) {
+		if ((*pcyls * *pheads) <= 131072) {
+		bdrv_set_translation_hint(bs,
+	  BIOS_ATA_TRANSLATION_LARGE);
+		} else {
+		bdrv_set_translation_hint(bs,
+	  BIOS_ATA_TRANSLATION_LBA);
+		}
+	}
+	}
+	bdrv_set_geometry_hint(bs, *pcyls, *pheads, *psecs);
+}
+}
+
 void bdrv_set_geometry_hint(BlockDriverState *bs,
 int cyls, int heads, int secs)
 {
Index: qemu/block.h
===
--- qemu.orig/block.h	2007-12-04 16:18:46.0 -0600
+++ qemu/block.h	2007-12-04 16:19:08.0 -0600
@@ -73,6 +73,7 @@
 int bdrv_truncate(BlockDriverState *bs, int64_t offset);
 int64_t bdrv_getlength(BlockDriverState *bs);
 void bdrv_get_geometry(BlockDriverState *bs, int64_t *nb_sectors_ptr);
+void bdrv_guess_geometry(BlockDriverState *bs, int *pcyls, int *pheads, int *psecs);
 int bdrv_commit(BlockDriverState *bs);
 void bdrv_set_boot_sector(BlockDriverState *bs, const uint8_t *data, int size);
 /* async block I/O */
Index: qemu/hw/ide.c
===
--- qemu.orig/hw/ide.c	2007-12-04 16:18:46.0 -0600
+++ qemu/hw/ide.c	2007-12

Re: [Qemu-devel] gcc

[Rick Vernam]

On Tuesday 04 December 2007 06:35:53 pm Carlo Marcelo Arenas Belon wrote:
> On Mon, Dec 03, 2007 at 08:20:28PM -0600, Rick Vernam wrote:
> > any comments on the current status of moving beyond dependency on GCC
> > 3.3.6?
>
> you meant dependency on GCC < 4 right?
yeah..thanks.

> I use gcc 3.4.6 and there shouldn't be any reasons AFAIK that wouldn't work.
yeah, I keep 3.4.6 around, too.

>
> Carlo

[Qemu-devel] Re: [PATCH 0/3] virtio support for QEMU

[Rusty Russell]

On Wednesday 05 December 2007 11:10:46 Anthony Liguori wrote:
> Dor Laor wrote:
> > Can you set up an uptodate git repository for the kernel part, other
> 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.

I'm actually on vacation this week and next week, so my queue won't be updated 
for a while.  I'll put them all in once I'm back on deck...

Rusty.

[Qemu-devel] Re: [PATCH 0/3] virtio support for QEMU

[Anthony Liguori]

Avi Kivity wrote:

Rusty Russell wrote:

On Wednesday 05 December 2007 11:10:46 Anthony Liguori wrote:
 

Dor Laor wrote:
   

Can you set up an uptodate git repository for the kernel part, other
  

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.



I'm actually on vacation this week and next week, so my queue won't 
be updated for a while.  I'll put them all in once I'm back on deck...


  


I can host it in a branch on kvm.git, if I knew what patches to 
include.  Anthony, can you post pointers?


http://hg.codemonkey.ws/linux-virtio

That's the required patches from rusty's queue plus my patches based off 
the kvm git tree as of 83f9425dc148dbe0d373b7e07f221a9e91cb


Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH] Capture traffic to a pcap file

[Paul Brook]

On Wednesday 05 December 2007, Balazs Attila-Mihaly (Cd-MaN) wrote:
> This patch allows to capture the traffic flowing through a particular vlan
> in a tcpdump compatible pcap file.
>
> The patch is identical to the one created some time back, however it was
> updated to apply to HEAD.
>
> Usage: -net nic,pcap=capture_file.pcap

This should be a separate -net option, not part of -net nic.

Paul

Re: [Qemu-devel] [PATCH 2/2 v2] Direct IDE I/O

[Anthony Liguori]

Gerd Hoffmann wrote:

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 ...
  


Yeah, it is definitely something that should be turned into a shared 
library.  I don't think I'll attempt that at first but I do agree it's 
the right direction to move toward.


Regards,

Anthony Liguori


cheers,
  Gerd




  

[Qemu-devel] [PATCH] sh4: add interrupt support to sh_timer.c

[Magnus Damm]

Hi everyone,

This patch adds interrupt support to the sh specific timer code.
Tested with a 2.6.24-rc guest kernel.

 hw/sh.h   |7 ++-
 hw/sh7750.c   |   12 +---
 hw/sh_timer.c |   32 ++--
 3 files changed, 33 insertions(+), 18 deletions(-)

/ magnus


qemu-cvs-20071128-sh-timer.patch
Description: Binary data

Re: [Qemu-devel] [PATCH] Capture traffic to a pcap file

[Anthony Liguori]

Balazs Attila-Mihaly (Cd-MaN) wrote:

This patch allows to capture the traffic flowing through a particular vlan in a 
tcpdump compatible pcap file.

The patch is identical to the one created some time back, however it was 
updated to apply to HEAD.

Usage: -net nic,pcap=capture_file.pcap
  


I like the idea but I think it would be more useful as a monitor command 
similar to how the audio capture command works already.


Regards,

Anthony Liguori




  __
Sent from Yahoo! - the World's favourite mail http://uk.mail.yahoo.com
  

[Qemu-devel] Re: [PATCH] r2d: Add R2D-PLUS FPGA support.

[Magnus Damm]

On Dec 3, 2007 6:30 PM, Paul Mundt <[EMAIL PROTECTED]> wrote:
> This adds trivial support for the R2D-PLUS FPGA, mostly just for the
> versioning information that the kernel uses for IRL mappings, in addition
> to handling the heartbeat and poweroff writes.
>
> Signed-off-by: Paul Mundt <[EMAIL PROTECTED]>
Acked-by: Magnus Damm <[EMAIL PROTECTED]>

Looking good, thanks. Please apply.

/ magnus

Re: [Qemu-devel] and now bus error for i386 guest

[Shaddy Baddah]

Hi,

Blue Swirl wrote:

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

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.
As I will detail later, this problem looks to me to be at least 
partially caused by a bug in the compiler optimizer.



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?
I meant full system emulator mode. I was able to successfully compile 
inside the guest Sparc(32) Debian Lenny system. However, I couldn't 
really run qemu successfully inside the guest system. I was getting a 
hang, and I traced that down to a call to glibc's timer_create function, 
in the dynticks_start_timer function:


 printf("timer_create1\n");
   if (timer_create(CLOCK_REALTIME, &ev, &host_timer)) {
 printf("timer_create\n");
   perror("timer_create");

   /* disable dynticks */
   fprintf(stderr, "Dynamic Ticks disabled\n");

   return -1;
   }
 printf("timer_create2\n");

the bt shows three threads, and two of which are stuck in some type of 
pthread suspend functions, and on stuck in a poll function. I don't know 
much about the clocks, so I just randomly tried to select clocks via 
-clock option. I tried -clock unix, and got a similar bus error. But all 
this precludes what I am about to write with regards to my discoveries 
on the compiler optimizer.


Back on the real Sun Ultra box, I did a bit of debug. I found the 
following bit of failed code, as described in a capture of my gdb session:


$ gdb --args ./i386-softmmu/qemu -cdrom 
../../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 


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) break vl.c:7362
Breakpoint 1 at 0x1e958: file /home/shaddy/qemu-cvs/qemu/vl.c, line 7362.
(gdb) display /i $pc
(gdb) run
Starting program: /home/shaddy/qemu-cvs/qemu-build/i386-softmmu/qemu 
-cdrom ../../KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -L ../qemu/pc-bios

[Thread debugging using libthread_db enabled]
[New Thread 0xf7f77550 (LWP 13579)]
[Switching to Thread 0xf7f77550 (LWP 13579)]

Breakpoint 1, main (argc=1430528, argv=0x15d400) at 
/home/shaddy/qemu-cv

[Qemu-devel] Re: [PATCH] target-sh4: Support CPU versioning.

[Magnus Damm]

On Dec 3, 2007 5:40 PM, Paul Mundt <[EMAIL PROTECTED]> wrote:
> Trivial patch adding CPU listing and the ability to do per-subtype
> CVR/PVR/PRR values. The existing semantics aren't changed, as only
> the SH7751R values are stubbed in for the moment, but the kernel is at
> least able to get the cache probing correct.
>
> This also makes it trivial to abstract subtype specific registers like
> MMU_PTEA and to set up feature bits in line with the kernel probing for
> things like conditionalizing FPU/DSP context.
>
> Signed-off-by: Paul Mundt <[EMAIL PROTECTED]>

Thank you for implementing this. Good idea. There is however a small
glitch introduced with this patch - both the r2d and the shix board
can pass "any" as cpu string when calling cpu_init(). This results in
a "Unable to find CPU definition" error unless the cpu type is
specified on the command line using the -cpu option. Maybe a better
solution would be to pass "SH7751R" from r2d and "SH7750" from shix by
default?

/ magnus

Re: [Qemu-devel] Online image backup

[Lorenzo Mancini]

Matteo Bertini wrote:

Hello everyone,

is there any support for an online image backup? Or some direction to
have it?

Imagine I have an emulated server. How can I make an online backup of
the server state?

If I'm right in the actual design this is very hard.

Or there are some image internals update rules that permit a consistent
copy possible?


It should not be difficult provided the VM is using the QEMU qcow2 image
format (doing a backup can be seen as a kind of snapshot).


Fabrice, that's just part of the problem.  A full automated remote 
backup service for qemu VMs should work like this:


 1. send a "savevm state" command to qemu;
 2. wait for savevm completion;
 3. perform an *online* copy (cp, rsync, whatever) of the .qcow2 image, 
while it's still running in qemu;

 4. ...repeat for all running VMs.

Now suppose you lose the host machine and must revert to backup.  A 
recovery scenario would be:


 1. copy the .qcow2 image on the new host machine;
 2. start qemu with the "-loadvm state" commandline switch.


The weak spot of this configuration is the third step of backup: if you 
perform an online copy (and that's your only real choice, since you 
don't want to powerdown the VMs every night just to backup them), you 
are copying a file while it's always modifying, and chances are high 
that the copy will be corrupted (i.e. different from any state the 
original went through), since you can't perform the copy with a single read.


However, if the .qcow2 file format is designed in such a way that even 
while copying it online, the resulting copy will certainly be corrupted 
but at least the states inside of it will be loadvm-able, that saves the 
day.



If that's not the case, one could fallback to perform the online copy 
between a couple of "stop" and "cont" commands, so you're sure that the 
underlying .qcow2 image is frozen while you're reading it (...is it?), 
but again that's suboptimal since you force the VMs to be down for some 
time.



Thanks in advance!

--
Lorenzo Mancini

[Qemu-devel] [PATCH] Capture traffic to a pcap file

[Balazs Attila-Mihaly (Cd-MaN)]

This patch allows to capture the traffic flowing through a particular vlan in a 
tcpdump compatible pcap file.

The patch is identical to the one created some time back, however it was 
updated to apply to HEAD.

Usage: -net nic,pcap=capture_file.pcap




  __
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	5 Dec 2007 13:38:04 -
@@ -3588,6 +3588,8 @@
 return NULL;
 vlan->id = id;
 vlan->next = NULL;
+vlan->pcap_fh = -1;
+vlan->last_packet_time = 0;
 pvlan = &first_vlan;
 while (*pvlan != NULL)
 pvlan = &(*pvlan)->next;
@@ -3635,6 +3637,22 @@
 {
 VLANState *vlan = vc1->vlan;
 VLANClientState *vc;
+
+if (vlan->pcap_fh >= 0) {
+vlan->packet_header.timestamp_sec = time(NULL);
+if (vlan->packet_header.timestamp_sec == vlan->last_packet_time) {
+if (vlan->packet_header.timestamp_usec < 100)
+	++vlan->packet_header.timestamp_usec;
+} else {
+	vlan->packet_header.timestamp_usec = 0;
+	vlan->last_packet_time = vlan->packet_header.timestamp_sec;
+}
+
+vlan->packet_header.orig_len = size;
+vlan->packet_header.saved_len = (size > MAX_CAPTURED_PACKET_SIZE) ? MAX_CAPTURED_PACKET_SIZE : size;
+write(vlan->pcap_fh, &vlan->packet_header, sizeof(PCAPPacketHeader));
+write(vlan->pcap_fh, buf, vlan->packet_header.saved_len);
+}
 
 #if 0
 printf("vlan %d send:\n", vlan->id);
@@ -4642,6 +4660,7 @@
 char buf[1024];
 int vlan_id, ret;
 VLANState *vlan;
+PCAPHeader initial_header;
 
 p = str;
 q = device;
@@ -4662,6 +4681,22 @@
 fprintf(stderr, "Could not create vlan %d\n", vlan_id);
 return -1;
 }
+if (get_param_value(buf, sizeof(buf), "pcap", p)) {
+	vlan->pcap_fh = open(buf, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY, 0644);
+	if (vlan->pcap_fh < 0) {
+		fprintf(stderr, "Failed to open capture file \"%s\": %d\n", buf, errno);
+		return -1;
+	}
+	
+	initial_header.magic_number  = 0xa1b2c3d4;
+	initial_header.version_major = 2;
+	initial_header.version_minor = 4;
+	initial_header.thiszone  = 0;
+	initial_header.sigfigs   = 0;
+	initial_header.snaplen   = MAX_CAPTURED_PACKET_SIZE;
+	initial_header.network   = 1; /* Ethernet */
+	write(vlan->pcap_fh, &initial_header, sizeof(initial_header));
+}
 if (!strcmp(device, "nic")) {
 NICInfo *nd;
 uint8_t *macaddr;
@@ -7481,8 +7516,10 @@
"-name stringset the name of the guest\n"
"\n"
"Network options:\n"
-   "-net nic[,vlan=n][,macaddr=addr][,model=type]\n"
+   "-net nic[,vlan=n][,macaddr=addr][,model=type][,pcap=filename]\n"
"create a new Network Interface Card and connect it to VLAN 'n'\n"
+   "optionally save the traffic which flows through VLAN 'n' to\n"
+   "'filename' in pcap (tcpdump) format\n"
 #ifdef CONFIG_SLIRP
"-net user[,vlan=n][,hostname=host]\n"
"connect the user mode network stack to VLAN 'n' and send\n"
@@ -8931,5 +8968,11 @@
 }
 }
 #endif
+
+/* close capture files associated with any vlan */
+for(vlan = first_vlan; vlan != NULL; vlan = vlan->next)
+if (vlan->pcap_fh >= 0)
+close(vlan->pcap_fh);
+
 return 0;
 }
Index: net.h
===
RCS file: /sources/qemu/qemu/net.h,v
retrieving revision 1.1
diff -u -r1.1 net.h
--- net.h	17 Nov 2007 17:14:38 -	1.1
+++ net.h	5 Dec 2007 13:38:04 -
@@ -1,6 +1,27 @@
 #ifndef QEMU_NET_H
 #define QEMU_NET_H
 
+/* PCAP support */
+/* source: http://wiki.wireshark.org/Development/LibpcapFileFormat */
+typedef struct {
+uint32_t magic_number;
+uint16_t version_major;
+uint16_t version_minor;
+int32_t thiszone;
+uint32_t sigfigs;
+uint32_t snaplen;
+uint32_t network;
+} PCAPHeader;
+
+typedef struct {
+	uint32_t timestamp_sec;
+	uint32_t timestamp_usec;
+	uint32_t saved_len;
+	uint32_t orig_len;
+} PCAPPacketHeader;
+
+#define MAX_CAPTURED_PACKET_SIZE 0x
+
 /* VLANs support */
 
 typedef struct VLANClientState VLANClientState;
@@ -21,6 +42,10 @@
 VLANClientState *first_client;
 struct VLANState *next;
 unsigned int nb_guest_devs, nb_host_devs;
+/* Filehandle for the capture file */
+int pcap_fh;
+time_t last_packet_time;
+PCAPPacketHeader packet_header;
 };
 
 VLANState *qemu_find_vlan(int id);

[Qemu-devel] Re: [PATCH 0/3] virtio support for QEMU

[Avi Kivity]

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.




Can you post this to kvm-devel as well next time?  I'm sure there is 
considerable interest in this work among kvm developers.


--
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: [PATCH 0/3] virtio support for QEMU

[Avi Kivity]

Rusty Russell wrote:

On Wednesday 05 December 2007 11:10:46 Anthony Liguori wrote:
  

Dor Laor wrote:


Can you set up an uptodate git repository for the kernel part, other
  

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.



I'm actually on vacation this week and next week, so my queue won't be updated 
for a while.  I'll put them all in once I'm back on deck...


  


I can host it in a branch on kvm.git, if I knew what patches to 
include.  Anthony, can you post pointers?


--
error compiling committee.c: too many arguments to function

[Qemu-devel] [PATCH] mark host pages as reserved

[Magnus Damm]

Hi all,

This patch teaches the user space emulator about host pages. It marks
present host page mappings with PAGE_RESERVED so mmap_find_vma()
properly can detect that pages at mmap_next_start should be skipped
over instead of being overwritten using mmap(). Without this patch I
experience crashes with the arm or sh4 user space emulator together
with sbox2. This combination sometimes result in that host libraries
are mapped into the qemu process space starting from 0x4xxx
instead of 0xb7xx. This together with the initial value of
mmap_next_start results in a segfault when the elf loader overwrites
the mapped host libraries with the target binary.

Comments anyone?

/ magnus


qemu-cvs-20071205b-reserve-host-pages.patch
Description: Binary data