[Qemu-devel] qemu/target-ppc cpu.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/12/10 08:13:10 Modified files: target-ppc : cpu.h Log message: Cleanup: remove useless TARGET_GPR_BITS definition. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemur1=1.109r2=1.110
[Qemu-devel] qemu/linux-user socket.h syscall_defs.h ppc/sys...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/12/10 08:24:59 Modified files: linux-user : socket.h syscall_defs.h linux-user/ppc : syscall.h target_signal.h Log message: Various linux-user structures and definitions fixes for PowerPC targets. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/socket.h?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall_defs.h?cvsroot=qemur1=1.47r2=1.48 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/ppc/syscall.h?cvsroot=qemur1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/ppc/target_signal.h?cvsroot=qemur1=1.3r2=1.4
[Qemu-devel] [PATCH][PPC] mtfsf: fix FPSCR_VX and FPSCR_FEX computation
Hi all,
The patch below fix the computation of FPSCR_VX and FPSCR_FEX when
using the mtfsf instruction. As stated in the PowerPC manual the mtfsf
instruction can't alter those bit, and thus it should always be
computed.
Bye,
Aurelien
Index: target-ppc/op_helper.c
===
RCS file: /sources/qemu/qemu/target-ppc/op_helper.c,v
retrieving revision 1.73
diff -u -d -p -r1.73 op_helper.c
--- target-ppc/op_helper.c 24 Nov 2007 02:03:55 - 1.73
+++ target-ppc/op_helper.c 10 Dec 2007 09:10:30 -
@@ -888,12 +888,16 @@ void do_store_fpscr (uint32_t mask)
/* Update VX and FEX */
if (fpscr_ix != 0)
env-fpscr |= 1 FPSCR_VX;
+else
+env-fpscr = ~(1 FPSCR_VX);
if ((fpscr_ex fpscr_eex) != 0) {
env-fpscr |= 1 FPSCR_FEX;
env-exception_index = POWERPC_EXCP_PROGRAM;
/* XXX: we should compute it properly */
env-error_code = POWERPC_EXCP_FP;
}
+else
+env-fpscr = ~(1 FPSCR_FEX);
fpscr_set_rounding_mode();
}
#undef WORD0
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
[Qemu-devel] [PATCH][DOC]Update documention with '-drive' usage.
Hi,
The attached patch update qemu-doc.texi with the definition of '-drive'.
Laurent
--
- [EMAIL PROTECTED] --
Any sufficiently advanced technology is
indistinguishable from magic. - Arthur C. Clarke
---
qemu-doc.texi | 70 ++
1 file changed, 70 insertions(+)
Index: qemu/qemu-doc.texi
===
--- qemu.orig/qemu-doc.texi 2007-12-10 10:27:32.0 +0100
+++ qemu/qemu-doc.texi 2007-12-10 10:35:21.0 +0100
@@ -227,6 +227,76 @@ Use @var{file} as CD-ROM image (you cann
@option{-cdrom} at the same time). You can use the host CD-ROM by
using @file{/dev/cdrom} as filename (@pxref{host_drives}).
[EMAIL PROTECTED] -drive @var{option}[,@var{option}[,@var{option}[,...]]]
+
+Define a new drive. Valid options are:
+
[EMAIL PROTECTED] @code
[EMAIL PROTECTED] [EMAIL PROTECTED]
+This option defines which disk image (@pxref{disk_images}) to use with
+this drive.
[EMAIL PROTECTED] [EMAIL PROTECTED]
+This option defines on which type on interface the drive is connected.
+Available types are: ide, scsi, sd, mtd, floppy, pflash.
[EMAIL PROTECTED] [EMAIL PROTECTED],[EMAIL PROTECTED]
+These options define where is connected the drive by defining the bus number and
+the unit id.
[EMAIL PROTECTED] [EMAIL PROTECTED]
+This option defines where is connected the drive by using an index in the list
+of available connectors of a given interface type.
[EMAIL PROTECTED] [EMAIL PROTECTED]
+This option defines the type of the media: disk or cdrom.
[EMAIL PROTECTED] [EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED]
+These options have the same definition as they have in @option{-hdachs}.
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] is on or off and allows to enable snapshot for given drive (see @option{-snapshot}).
[EMAIL PROTECTED] table
+
+Instead of @option{-cdrom} you can use:
[EMAIL PROTECTED]
+qemu -drive file=file,index=2,media=cdrom
[EMAIL PROTECTED] example
+
+Instead of @option{-hda}, @option{-hdb}, @option{-hdc}, @option{-hdd}, you can
+use:
[EMAIL PROTECTED]
+qemu -drive file=file,index=0,media=disk
+qemu -drive file=file,index=1,media=disk
+qemu -drive file=file,index=2,media=disk
+qemu -drive file=file,index=3,media=disk
[EMAIL PROTECTED] example
+
+You can connect a CDROM to the slave of ide0:
[EMAIL PROTECTED]
+qemu -drive file=file,if=ide,index=1,media=cdrom
[EMAIL PROTECTED] example
+
+If you don't specify the file= argument, you define an empty drive:
[EMAIL PROTECTED]
+qemu -drive if=ide,index=1,media=cdrom
[EMAIL PROTECTED] example
+
+You can connect a SCSI disk with unit ID 6 on the bus #0:
[EMAIL PROTECTED]
+qemu -drive file=file,if=scsi,bus=0,unit=6
[EMAIL PROTECTED] example
+
+Instead of @option{-fda}, @option{-fdb}, you can use:
[EMAIL PROTECTED]
+qemu -drive file=file,index=0,if=floppy
+qemu -drive file=file,index=1,if=floppy
[EMAIL PROTECTED] example
+
+By default, @var{interface} is ide and @var{index} is automatically
+incremented:
[EMAIL PROTECTED]
+qemu -drive file=a -drive file=b
[EMAIL PROTECTED] example
+is interpreted like:
[EMAIL PROTECTED]
+qemu -hda a -hdb b
[EMAIL PROTECTED] example
+
@item -boot [a|c|d|n]
Boot on floppy (a), hard disk (c), CD-ROM (d), or Etherboot (n). Hard disk boot
is the default.
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: [Qemu-devel] Online image backup
Ricardo Almeida wrote: 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 How do you switch to snapshot mode *while* the VM is running, i.e. without stopping and restarting qemu? The only way I know to enter that mode is using the -snapshot switch at invocation time and I don't think it can be done online. 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 If executing step 2.1 is actually possible, you can skip step 3.1 and 3.2 because the remote copy is already consistent with the state the VM went throught at the time of execution of step 2.1 . If it was possible, it would be just fine for automated daily backups. -- Lorenzo Mancini
[Qemu-devel] [PATCH] Capture network traffic to a tcpdump file - updated
Here goes v0.2 for my patch :-)
Changes
- now the option is a separate command line switch:
-net capture,vlan=2,file=test.pcap
- it is also available from the monitor
- added some more constants / defines to avoid repeating portions of the code
__
Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.377
diff -u -r1.377 vl.c
--- vl.c 6 Dec 2007 22:11:20 - 1.377
+++ vl.c 10 Dec 2007 10:28:35 -
@@ -237,6 +237,17 @@
static CPUState *next_cpu;
static int event_pending;
+/* File header which needs to be written at the start of each PCAP file*/
+static const PCAPHeader pcap_file_header = {
+0xa1b2c3d4,
+2,
+4,
+0,
+0,
+MAX_CAPTURED_PACKET_SIZE,
+1 /* Ethernet */
+};
+
#define TFR(expr) do { if ((expr) != -1) break; } while (errno == EINTR)
/***/
@@ -3588,6 +3599,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 +3648,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);
@@ -4641,7 +4670,8 @@
char device[64];
char buf[1024];
int vlan_id, ret;
-VLANState *vlan;
+VLANState *vlan;
+const char *capture_file_name;
p = str;
q = device;
@@ -4761,6 +4791,27 @@
}
vlan-nb_host_devs++;
} else
+if (!strcmp(device, capture)) {
+if (vlan-pcap_fh = 0) {
+ fprintf(stderr, vlan %d has already a capture file defined!
+ Can't have multiple capture files for the same vlan\n, vlan-id);
+ return -1;
+}
+
+capture_file_name = DEFAULT_CAPTURE_FILENAME;
+if (get_param_value(buf, sizeof(buf), file, p))
+capture_file_name = buf;
+
+vlan-pcap_fh = open(capture_file_name, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY, 0644);
+ if (vlan-pcap_fh 0) {
+ fprintf(stderr, Failed to open capture file \%s\: %d\n, capture_file_name, errno);
+ return -1;
+ }
+
+ write(vlan-pcap_fh, pcap_file_header, sizeof(pcap_file_header));
+
+ ret = 0;
+} else
{
fprintf(stderr, Unknown network device: %s\n, device);
return -1;
@@ -4784,6 +4835,59 @@
}
}
+void do_net_capture (const char *path,
+int has_vlan, int vlan_id)
+{
+VLANState *vlan;
+
+vlan_id = (has_vlan) ? vlan_id : 0;
+vlan = qemu_find_vlan(vlan_id);
+if (!vlan) {
+term_printf(Failed to find vlan %d\n, vlan_id);
+return;
+}
+
+if (vlan-pcap_fh = 0) {
+ term_printf(Vlan %d is already capturing!\n, vlan_id);
+ return;
+}
+
+vlan-pcap_fh = open(path, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY, 0644);
+ if (vlan-pcap_fh 0) {
+ term_printf(Failed to open capture file \%s\: %d\n, path, errno);
+ return;
+ }
+
+ vlan-last_packet_time = 0;
+ write(vlan-pcap_fh, pcap_file_header, sizeof(pcap_file_header));
+}
+
+void do_stop_net_capture(int has_vlan, int vlan_id)
+{
+VLANState *vlan;
+
+if (has_vlan) {
+vlan = qemu_find_vlan(vlan_id);
+if (!vlan) {
+term_printf(Failed to find vlan %d\n, vlan_id);
+return;
+}
+
+if (vlan-pcap_fh 0) {
+term_printf(Vlan %d is not capturing!\n, vlan_id);
+return;
+}
+
+close(vlan-pcap_fh);
+vlan-pcap_fh = -1;
+vlan-last_packet_time = 0;
+} else {
+for(vlan = first_vlan; vlan != NULL; vlan = vlan-next)
+if (vlan-pcap_fh = 0)
+close(vlan-pcap_fh);
+}
+}
+
#define HD_ALIAS file=\%s\,index=%d,media=disk
#ifdef TARGET_PPC
#define CDROM_ALIAS index=1,media=cdrom
@@ -7511,6 +7615,10 @@
connect the vlan 'n' to another
[Qemu-devel] high resolution timer question
Writing data to a serial port on the sparc emulation happens immediately. I would like to throttle the write speed to match the actual baud rate. What's the best way to do this in qemu? Will QEMUTimer work for a 1 millisecond timer?
RE: [Qemu-devel] high resolution timer question
The usb host controller emulations in qemu (usb-uhci usb-ohci) use QEMUTimer for 1 millisecond timer. This precise interval is required for generating usb 1.1 frames. I currently implement usb 2.0 host controller emulation for qemu (usb-ehci). It uses QEMUTimer for generating usb 2.0 microframes of 125 microsecond. This resolution worked precisely only after compiling the host kernel with high resolution timers and dynamic ticks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Reif Sent: Monday, December 10, 2007 3:00 PM To: qemu-devel@nongnu.org Subject: [Qemu-devel] high resolution timer question Writing data to a serial port on the sparc emulation happens immediately. I would like to throttle the write speed to match the actual baud rate. What's the best way to do this in qemu? Will QEMUTimer work for a 1 millisecond timer?
Re: [Qemu-devel] PATCH: ide.c: send irq for WIN_DIAGNOSE
Index: hw/ide.c === RCS file: /sources/qemu/qemu/hw/ide.c,v retrieving revision 1.72 diff -u -r1.72 ide.c --- hw/ide.c18 Nov 2007 01:44:37 - 1.72 +++ hw/ide.c30 Nov 2007 14:02:33 - @@ -2042,6 +2053,7 @@ ide_set_signature(s); s-status = 0x00; /* NOTE: READY is _not_ set */ s-error = 0x01; +ide_set_irq(s); break; case WIN_SRST: if (!s-is_cdrom) is there a way to reproduce that timeout on the guest OS you are using? I confirm this fixes the timeout issue. Tristan.
Re: [Qemu-devel] [PATCH] Capture network traffic to a tcpdump file - updated
Balazs Attila-Mihaly (Cd-MaN) wrote: Here goes v0.2 for my patch :-) Changes - now the option is a separate command line switch: -net capture,vlan=2,file=test.pcap Is it really necessary/useful to specify this on the command line since it can be controlled from the monitor? Regards, Anthony Liguori - it is also available from the monitor - added some more constants / defines to avoid repeating portions of the code __ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com
Re: [Qemu-devel] [PATCH] Capture network traffic to a tcpdump file - updated
Hi, On Mon, 10 Dec 2007, Anthony Liguori wrote: Balazs Attila-Mihaly (Cd-MaN) wrote: Here goes v0.2 for my patch :-) Changes - now the option is a separate command line switch: -net capture,vlan=2,file=test.pcap Is it really necessary/useful to specify this on the command line since it can be controlled from the monitor? As was said in another mail, if you want to guarantee that _every_ packet is logged, the command line is the most convenient. Besides, if you get your monitor support, why do you care about command line support? Ciao, Dscho
Re: [Qemu-devel] [PATCH] Capture network traffic to a tcpdump file - updated
On Monday 10 December 2007, Anthony Liguori wrote: Balazs Attila-Mihaly (Cd-MaN) wrote: Here goes v0.2 for my patch :-) Changes - now the option is a separate command line switch: -net capture,vlan=2,file=test.pcap Is it really necessary/useful to specify this on the command line since it can be controlled from the monitor? By that argument you could remove half the rest of the commandline options (e.g. the USB options). I think it would be good to expose the whole -net functionality via the monitor, rather than have a special hack for -net monitor. Obviously some functionality would only be usable via the commandline (e.g. non-hotplug NICs). Paul
Re: [Qemu-devel] [PATCH] Capture network traffic to a tcpdump file - updated
The use case I need it for is for honeypot-like systems. Ie. the system starts from a snapshot and accesses links / runs executables while observing the behaviour. For this use case it is the best if it is setable from the command line. ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/
Re: [Qemu-devel] [PATCH] Capture network traffic to a tcpdump file - updated
Johannes Schindelin wrote: Hi, On Mon, 10 Dec 2007, Anthony Liguori wrote: Balazs Attila-Mihaly (Cd-MaN) wrote: Here goes v0.2 for my patch :-) Changes - now the option is a separate command line switch: -net capture,vlan=2,file=test.pcap Is it really necessary/useful to specify this on the command line since it can be controlled from the monitor? As was said in another mail, if you want to guarantee that _every_ packet is logged, the command line is the most convenient. Besides, if you get your monitor support, why do you care about command line support? It's just an issue of usability. If you don't have to expose something two ways, then it's better not to. Regards, Anthony Liguori Ciao, Dscho
Re: [Qemu-devel] [PATCH] Capture network traffic to a tcpdump file - updated
Hi, On Mon, 10 Dec 2007, Anthony Liguori wrote: Johannes Schindelin wrote: On Mon, 10 Dec 2007, Anthony Liguori wrote: Balazs Attila-Mihaly (Cd-MaN) wrote: Here goes v0.2 for my patch :-) Changes - now the option is a separate command line switch: -net capture,vlan=2,file=test.pcap Is it really necessary/useful to specify this on the command line since it can be controlled from the monitor? As was said in another mail, if you want to guarantee that _every_ packet is logged, the command line is the most convenient. Besides, if you get your monitor support, why do you care about command line support? It's just an issue of usability. If you don't have to expose something two ways, then it's better not to. Okay, since you so nicely ask for it: I _want_ the command line option. I do not like having to type the same thing into the monitor every time I start QEmu. But I expressly do _not_ ask to scrap the monitor interface, even if I have no use for it. However, I have no problem maintaining my own fork. Much like I will do with VNC again, since I recently had to use QEmu via VNC and the artefacts are just horrible. Ciao, Dscho
[Qemu-devel] BSP information
I would like to recieve some kind of documents, tutorials, or other related info about BSP on QEMU. I would like to emulate VxWorks on QEMU. Thanks your attention. This message was sent using IMP, the Internet Messaging Program.
Re: [Qemu-devel] Online image backup
2.1 Switch to snapshot mode How do you switch to snapshot mode *while* the VM is running, i.e. without stopping and restarting qemu? The only way I know to enter that mode is using the -snapshot switch at invocation time and I don't think it can be done online. As I said, I'm just a user ;) I don't see a reason why this can't be implemented... This is the devel list, so if a good idea comes up someone can implement it ;) If executing step 2.1 is actually possible, you can skip step 3.1 and 3.2 because the remote copy is already consistent with the state the VM went throught at the time of execution of step 2.1 . If it was possible, it would be just fine for automated daily backups. Yes, you're right. I wanted to update a little more but it doesn't really make much sense...
Re: [Qemu-devel] high resolution timer question
On 12/10/07, Robert Reif [EMAIL PROTECTED] wrote: Writing data to a serial port on the sparc emulation happens immediately. I would like to throttle the write speed to match the actual baud rate. What's the best way to do this in qemu? Will QEMUTimer work for a 1 millisecond timer? Do you mean that you want the serial port to match the host speed so that for example, at 9600 baud, target would only receive 9600 bits per second? Or do you mean that the emulated CPU should see bits arriving at the same rate that the real CPU would see compared to CPU execution speed? On the positive side, this would fix a bug with serial interrupts arriving too fast which can trigger Linux panics. But this would also complicate the design because currently the devices do not need to emulate any internal buffers. I think the throttling should be done at CharDriver level so that all targets and also other devices, like parallel ports (SUNW,bpp anyone?) can benefit. It should be turned off when talking to real hardware on the host.
Re: [Qemu-devel] [PATCH] Capture network traffic to a tcpdump file - updated
Hi Johannes, Johannes Schindelin wrote: Hi, However, I have no problem maintaining my own fork. Much like I will do with VNC again, since I recently had to use QEmu via VNC and the artefacts are just horrible. I just sent a patch to the mailing list that should fix those artifacts. Let me know if it doesn't and I'll track down whatever the issue is. Regards, Anthony Liguori Ciao, Dscho
[Qemu-devel] [PATCH][VNC] Fix fragments due to incomplete dirty tracking in CGA mode
Dirty tracking is done in the VNC server by splitting the framebuffer into 16-pixel blocks and then updating a bitmap when a dpy-update() occurs. If dpy-update() is called with an x st (x % 16) != 0, then the very last block dirtied by the update could potentially not be tracked. This is really only visible when in CGA mode or when using the VMware VGA driver since they are the only ones that generate updates where x != 0. The attached patch addresses this. Reproducing the fragments isn't 100% reliable but I was able to find a somewhat reliable way to reproduce (holding in backspace when editting a grub entry) and confirmed that this patch fixes the problem. Regards, Anthony Liguori Index: qemu/vnc.c === --- qemu.orig/vnc.c 2007-12-10 11:39:04.0 -0600 +++ qemu/vnc.c 2007-12-10 11:42:57.0 -0600 @@ -258,6 +258,13 @@ h += y; +/* round x down to ensure the loop only spans one 16-pixel block per, + iteration. otherwise, if (x % 16) != 0, the last iteration may span + two 16-pixel blocks but we only mark the first as dirty +*/ +w += (x % 16); +x -= (x % 16); + for (; y h; y++) for (i = 0; i w; i += 16) vnc_set_bit(vs-dirty_row[y], (x + i) / 16);
Re: [Qemu-devel] high resolution timer question
Blue Swirl wrote: On 12/10/07, Robert Reif [EMAIL PROTECTED] wrote: Writing data to a serial port on the sparc emulation happens immediately. I would like to throttle the write speed to match the actual baud rate. What's the best way to do this in qemu? Will QEMUTimer work for a 1 millisecond timer? Do you mean that you want the serial port to match the host speed so that for example, at 9600 baud, target would only receive 9600 bits per second? Or do you mean that the emulated CPU should see bits arriving at the same rate that the real CPU would see compared to CPU execution speed? On the positive side, this would fix a bug with serial interrupts arriving too fast which can trigger Linux panics. But this would also complicate the design because currently the devices do not need to emulate any internal buffers. I think the throttling should be done at CharDriver level so that all targets and also other devices, like parallel ports (SUNW,bpp anyone?) But the timing is entirely a concept of the hardware devices. It seems like it would be easier to just add a growable buffer, and then setup a timer in each device that reads from the buffer. Regards, Anthony Liguori can benefit. It should be turned off when talking to real hardware on the host.
[Qemu-devel] [PATCH] ioemu/qemu vga: save and restore vram buffer
The existing stdvga driver from xen-unstable tools/ioemu/hw/vga* does
not save the emulated VGA memory contents. The symptoms include video
malfunction after restore, including black screen (which can often be
fixed by asking the guest to redraw) but also missing font setup etc.
The attached patch fixes this by saving the entire VGA memory buffer,
just like the Xen ioemu Cirrus emulator does.
I have reinterpreted the `is_vbe' byte, which is related to
CONFIG_BOCHS_VBE, as a general flags word. This enables my code to
allow old images to be restored (albeit with loss of VGA memory), by
using another bit in that word to indicate whether the VGA memory dump
is present.
I'm sending this patch to both xen-devel and qemu-devel, as
examination of a recent qemu cvs checkout shows the same bug to be
present there. I don't know if the patch below (which is against
recent xen-unstable) will apply cleanly to qemu, but the code
generally looks very similar.
Signed-off-by: Ian Jackson [EMAIL PROTECTED]
Ian.
diff -r 38a45b7c6cb5 tools/ioemu/hw/vga.c
--- a/tools/ioemu/hw/vga.c Mon Dec 10 11:37:13 2007 +
+++ b/tools/ioemu/hw/vga.c Mon Dec 10 17:55:22 2007 +
@@ -1742,6 +1742,8 @@ static void vga_save(QEMUFile *f, void *
static void vga_save(QEMUFile *f, void *opaque)
{
VGAState *s = opaque;
+unsigned save_format_flags;
+uint32_t vram_size;
#ifdef CONFIG_BOCHS_VBE
int i;
#endif
@@ -1772,8 +1774,9 @@ static void vga_save(QEMUFile *f, void *
qemu_put_buffer(f, s-palette, 768);
qemu_put_be32s(f, s-bank_offset);
+save_format_flags = VGA_SAVE_FORMAT_FLAG_VRAM_DATA;
#ifdef CONFIG_BOCHS_VBE
-qemu_put_byte(f, 1);
+qemu_put_byte(f, save_format_flags | VGA_SAVE_FORMAT_FLAG_BOCHS_VBE);
qemu_put_be16s(f, s-vbe_index);
for(i = 0; i VBE_DISPI_INDEX_NB; i++)
qemu_put_be16s(f, s-vbe_regs[i]);
@@ -1781,17 +1784,19 @@ static void vga_save(QEMUFile *f, void *
qemu_put_be32s(f, s-vbe_line_offset);
qemu_put_be32s(f, s-vbe_bank_mask);
#else
-qemu_put_byte(f, 0);
-#endif
+qemu_put_byte(f, save_format_flags);
+#endif
+vram_size = s-vram_size;
+qemu_put_be32s(f, vram_size);
+qemu_put_buffer(f, s-vram_ptr, s-vram_size);
}
static int vga_load(QEMUFile *f, void *opaque, int version_id)
{
VGAState *s = opaque;
-int is_vbe, ret;
-#ifdef CONFIG_BOCHS_VBE
-int i;
-#endif
+int ret;
+unsigned int save_format_flags;
+uint32_t vram_size;
if (version_id 2)
return -EINVAL;
@@ -1825,9 +1830,9 @@ static int vga_load(QEMUFile *f, void *o
qemu_get_buffer(f, s-palette, 768);
qemu_get_be32s(f, s-bank_offset);
-is_vbe = qemu_get_byte(f);
+save_format_flags = qemu_get_byte(f);
#ifdef CONFIG_BOCHS_VBE
-if (!is_vbe)
+if (!(save_format_flags VGA_SAVE_FORMAT_FLAG_BOCHS_VBE))
return -EINVAL;
qemu_get_be16s(f, s-vbe_index);
for(i = 0; i VBE_DISPI_INDEX_NB; i++)
@@ -1836,9 +1841,16 @@ static int vga_load(QEMUFile *f, void *o
qemu_get_be32s(f, s-vbe_line_offset);
qemu_get_be32s(f, s-vbe_bank_mask);
#else
-if (is_vbe)
+if (save_format_flags VGA_SAVE_FORMAT_FLAG_BOCHS_VBE)
return -EINVAL;
#endif
+if (save_format_flags VGA_SAVE_FORMAT_FLAG_VRAM_DATA) {
+ /* people who restore old images may be lucky ... */
+ qemu_get_be32s(f, vram_size);
+ if (vram_size != s-vram_size)
+ return -EINVAL;
+ qemu_get_buffer(f, s-vram_ptr, s-vram_size);
+}
/* force refresh */
s-graphic_mode = -1;
diff -r 38a45b7c6cb5 tools/ioemu/hw/vga_int.h
--- a/tools/ioemu/hw/vga_int.h Mon Dec 10 11:37:13 2007 +
+++ b/tools/ioemu/hw/vga_int.h Mon Dec 10 17:37:05 2007 +
@@ -157,6 +157,9 @@ static inline int c6_to_8(int v)
return (v 2) | (b 1) | b;
}
+#define VGA_SAVE_FORMAT_FLAG_BOCHS_VBE 0x01
+#define VGA_SAVE_FORMAT_FLAG_VRAM_DATA 0x02
+
void vga_common_init(VGAState *s, DisplayState *ds, uint8_t *vga_ram_base,
unsigned long vga_ram_offset, int vga_ram_size);
uint32_t vga_mem_readb(void *opaque, target_phys_addr_t addr);
Re: [Qemu-devel] [PATCH] ioemu/qemu vga: save and restore vram buffer
On 10/12/2007, Ian Jackson [EMAIL PROTECTED] wrote: The existing stdvga driver from xen-unstable tools/ioemu/hw/vga* does not save the emulated VGA memory contents. The symptoms include video malfunction after restore, including black screen (which can often be fixed by asking the guest to redraw) but also missing font setup etc. The attached patch fixes this by saving the entire VGA memory buffer, just like the Xen ioemu Cirrus emulator does. Sounds reasonable. I have reinterpreted the `is_vbe' byte, which is related to CONFIG_BOCHS_VBE, as a general flags word. This enables my code to allow old images to be restored (albeit with loss of VGA memory), by using another bit in that word to indicate whether the VGA memory dump is present. You can use the version_id parameter for that. Increase the value passed to register_savevm and load the vram only if version_id = 2. Regards
Re: [Qemu-devel] [PATCH] Capture network traffic to a tcpdump file - updated
Hi, On Mon, 10 Dec 2007, Anthony Liguori wrote: Johannes Schindelin wrote: However, I have no problem maintaining my own fork. Much like I will do with VNC again, since I recently had to use QEmu via VNC and the artefacts are just horrible. I just sent a patch to the mailing list that should fix those artifacts. Let me know if it doesn't and I'll track down whatever the issue is. Unfortunately I am way overloaded with work right now, and cannot test. However, from your description it does not seem likely that it fixes the problem: AFAICT Kubuntu's installer does not us CGA or VMWare's VGA driver. I might be wrong, but I do not even have the time to test that. Sorry, Dscho
[Qemu-devel] qemu/target-sparc op_helper.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/12/10 19:58:20 Modified files: target-sparc : op_helper.c Log message: Add ASIs (Robert Reif) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op_helper.c?cvsroot=qemur1=1.60r2=1.61
[Qemu-devel] qemu vl.c hw/boards.h hw/sun4m.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/12/10 20:00:11 Modified files: . : vl.c hw : boards.h sun4m.c Log message: Add SPARCstation 20 machine type (Robert Reif) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.377r2=1.378 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/boards.h?cvsroot=qemur1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemur1=1.68r2=1.69
[Qemu-devel] qemu/hw slavio_serial.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/12/10 20:05:09 Modified files: hw : slavio_serial.c Log message: Name the magic constants, wrap long lines CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/slavio_serial.c?cvsroot=qemur1=1.29r2=1.30
Re: [Qemu-devel] [PATCH] sparc32 add a few more ASI
On 12/9/07, Robert Reif [EMAIL PROTECTED] wrote: diff -p -u -r1.60 op_helper.c --- target-sparc/op_helper.c28 Nov 2007 18:08:28 - 1.60 +++ target-sparc/op_helper.c9 Dec 2007 20:33:02 - @@ -411,6 +411,9 @@ void helper_ld_asi(int asi, int size, in break; } break; +case 0x39: /* data cache diagnostic register */ +ret = 0; +break; case 0x21 ... 0x2d: /* MMU passthrough, unassigned */ default: do_unassigned_access(T0, 0, 0, 1); @@ -703,9 +706,13 @@ void helper_st_asi(int asi, int size) } } return; -case 0x31: /* Ross RT620 I-cache flush */ +case 0x30: /* store buffer tags */ +case 0x31: /* store buffer data or Ross RT620 I-cache flush */ +case 0x32: /* store buffer control */ case 0x36: /* I-cache flash clear */ case 0x37: /* D-cache flash clear */ +case 0x38: /* breakpoint diagnostics */ +case 0x4c: /* breakpoint action */ break; case 9: /* Supervisor code access, XXX */ case 0x21 ... 0x2d: /* MMU passthrough, unassigned */ Thanks, applied. Hardware breakpoint support could be useful, though GDB works without it.
Re: [Qemu-devel] [PATCH] sparc32 add SPARCstation 20 machine type
On 12/10/07, Robert Reif [EMAIL PROTECTED] wrote: +qemu_register_machine(ss20_machine); Thanks, applied. I also added support to OpenBIOS, but although the change is very minimal and SS-10 continues to work, SS-20 doesn't. Puzzling.
Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API
On 12/10/07, Yuval Kashtan [EMAIL PROTECTED] wrote: Hello All, Attached is a proposed patch which adds DBus support to QEMU. DBus is a standard message bus for linux (http://www.freedesktop.org/wiki/Software/dbus ) The idea behind this is to allow for external programs such as controlling GUI or HyperVisors to communicate and control QEMU, in a standard manner. Although it is possible to connect to the monitor, an API is more standard, theres no need to parse texts and error messages, no internationalization problems and in general is a much better idea. Implementation: This is done by creating a DBus server from QEMU which raise signals and act upon methods. Methods mainly implement same logic as the current command line options and monitor does. How to use: To enable DBus support you'll have to add --enable-dbus when you execure configure script. Then when you execute QEMU, you'll have to add -dbus-service service_name where service_name follows the DBus naming convention ( xxx.xxx.xxx) To support QEMU configuration through DBus, you'll also have to add -dbus_configuration which will cause QEMU to wait until ConfigDone is called through the DBus interface. this allows external programs time to call DBus methods starting with Config_ which changes configuration (just as the CLI does) thus enabling invocation of QEMU without parameters (beside the DBus ones). With that, we have implemented a nice python script that reads VM's configuration from INI file. To compile this you will also have to compile the attached freedesktop.org dsrv library (it is also attach for those who can't handle GIT) from: git://people.freedesktop.org/~shaharf/dsrv Features: Currently support was added to all important CLI configuration and some online monitor functions (such as connecting and disconnecting usb devices). configuration methods begins with Config_ prefix and monitor ones with Monitor_. For a complete list you can just execute qemu and connect with dbus-viewer to see what is supported. All the dbus handling routines can be found in dbus-monitor.c. I have two different implementations of this: 1) A single threaded version. which comply to the qemu standard of not opening additional threads. 2) A multi threaded version which open an additional, single, thread which handles all the DBus load. I actually believe this version is better as it allows QEMU to continue execution of guest operations even when there are DBus methods/signals to handle, whereas in the first option, DBus is integrated into QEMU mainloop. Also this makes it possible to monitor even during long operations (like monitoring the progress of savevm) Please comment both on the idea of management API and the proposed implementation. Attached are: RFC-QEMU-Dbus.patch - patch file including all necessary changes to qemu. was made against QEMU HEAD as of 23/9 morning. RFC-QEMU-Dbus-Interface.xml - the xml description of the DBus interface that I suggest. dsrv.tar.gz.txt - the dbus server library. I have no idea if this is useful. I would have tried the patch, but it does not apply to current CVS. Other comments: When configure is invoked with --enable-dbus, it should check for DBUS libraries and abort if not found. The coding style in monitor-dbus.c is different from what is commonly used in Qemu. Some long lines could be shortened. Enabling of DEBUG_ACPI and other ACPI changes are probably not directly needed so they should be in separate patches. Only commands are included, how about reading values and statistics?
Re: [Qemu-devel] [PATCH] Capture network traffic to a tcpdump file - updated
Johannes Schindelin wrote: Hi, On Mon, 10 Dec 2007, Anthony Liguori wrote: Johannes Schindelin wrote: However, I have no problem maintaining my own fork. Much like I will do with VNC again, since I recently had to use QEmu via VNC and the artefacts are just horrible. I just sent a patch to the mailing list that should fix those artifacts. Let me know if it doesn't and I'll track down whatever the issue is. Unfortunately I am way overloaded with work right now, and cannot test. However, from your description it does not seem likely that it fixes the problem: AFAICT Kubuntu's installer does not us CGA or VMWare's VGA driver. I might be wrong, but I do not even have the time to test that. Were you using the alternate installer or the desktop installer? Kubuntu uses ubiquity which is the same as what Ubuntu uses. We've got Ubuntu in the kvm-test harness and I've done dozens of installs with it without any problems. kvm-test uses VNC and would be very sensitive to artifacts. What client were you using? Regards, Anthony Liguori Sorry, Dscho
Re: [Qemu-devel] high resolution timer question
I think the throttling should be done at CharDriver level so that all targets and also other devices, like parallel ports (SUNW,bpp anyone?) But the timing is entirely a concept of the hardware devices. It seems like it would be easier to just add a growable buffer, and then setup a timer in each device that reads from the buffer. I don't see why timing is device specific. The mechanisms for setting the speed are device specific, but the throttling should not be. You may need to augment the char driver API to support outgoing throttling. I'd also like to request that this feature be disabled by default. As I've mentined several times before qemu is not cycle accurate, so any attempt to do accurate timing is completely arbitrary. In practice I'd expect any throttling is probably going to have to be fairly coarse grained because the emulated cpu speed is extremely variable/irregular, and you're limited by host timer resolution. Paul
Re: [Qemu-devel] [PATCH] Capture network traffic to a tcpdump file - updated
Anthony Liguori wrote: Balazs Attila-Mihaly (Cd-MaN) wrote: Here goes v0.2 for my patch :-) Changes - now the option is a separate command line switch: -net capture,vlan=2,file=test.pcap Is it really necessary/useful to specify this on the command line since it can be controlled from the monitor? FWIW, I prefer to have symmetry between monitor and command line options (to help those use cases the programmer didn't think of). Thiemo
[Qemu-devel] Re: [PATCH] mark host pages as reserved
Hi everyone, On Dec 5, 2007 5:45 PM, Magnus Damm [EMAIL PROTECTED] wrote: 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? Any reason for not applying this patch? This fixes user space emulation for all targets. Thanks, / magnus
Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API
Some answers: - If there is interest I can re-create the patch so it will work against the current head. I thought to receive some comments about it first.. - thanks for the styling and configuration remarks, I will certainly fix these. But before I invest more time in it, I would like to hear what ppl think in general of management API? How do you like DBus as the infrastructure for that? and what do you think of the proposed implementation? - Currently only commands are implemented (with very few getters), but of course this can be further extended to include values reading and statistics. - This is very useful when you want to manage and control QEMU, for instance developing a GUI to attach and detach usb devices or controlling more than one instance of QEMU from a single management point, receiving parameters externally and more. On Dec 10, 2007 10:51 PM, Blue Swirl [EMAIL PROTECTED] wrote: On 12/10/07, Yuval Kashtan [EMAIL PROTECTED] wrote: Hello All, Attached is a proposed patch which adds DBus support to QEMU. DBus is a standard message bus for linux ( http://www.freedesktop.org/wiki/Software/dbus ) The idea behind this is to allow for external programs such as controlling GUI or HyperVisors to communicate and control QEMU, in a standard manner. Although it is possible to connect to the monitor, an API is more standard, theres no need to parse texts and error messages, no internationalization problems and in general is a much better idea. Implementation: This is done by creating a DBus server from QEMU which raise signals and act upon methods. Methods mainly implement same logic as the current command line options and monitor does. How to use: To enable DBus support you'll have to add --enable-dbus when you execure configure script. Then when you execute QEMU, you'll have to add -dbus-service service_name where service_name follows the DBus naming convention ( xxx.xxx.xxx) To support QEMU configuration through DBus, you'll also have to add -dbus_configuration which will cause QEMU to wait until ConfigDone is called through the DBus interface. this allows external programs time to call DBus methods starting with Config_ which changes configuration (just as the CLI does) thus enabling invocation of QEMU without parameters (beside the DBus ones). With that, we have implemented a nice python script that reads VM's configuration from INI file. To compile this you will also have to compile the attached freedesktop.org dsrv library (it is also attach for those who can't handle GIT) from: git://people.freedesktop.org/~shaharf/dsrv Features: Currently support was added to all important CLI configuration and some online monitor functions (such as connecting and disconnecting usb devices). configuration methods begins with Config_ prefix and monitor ones with Monitor_. For a complete list you can just execute qemu and connect with dbus-viewer to see what is supported. All the dbus handling routines can be found in dbus-monitor.c. I have two different implementations of this: 1) A single threaded version. which comply to the qemu standard of not opening additional threads. 2) A multi threaded version which open an additional, single, thread which handles all the DBus load. I actually believe this version is better as it allows QEMU to continue execution of guest operations even when there are DBus methods/signals to handle, whereas in the first option, DBus is integrated into QEMU mainloop. Also this makes it possible to monitor even during long operations (like monitoring the progress of savevm) Please comment both on the idea of management API and the proposed implementation. Attached are: RFC-QEMU-Dbus.patch - patch file including all necessary changes to qemu. was made against QEMU HEAD as of 23/9 morning. RFC-QEMU-Dbus-Interface.xml - the xml description of the DBus interface that I suggest. dsrv.tar.gz.txt - the dbus server library. I have no idea if this is useful. I would have tried the patch, but it does not apply to current CVS. Other comments: When configure is invoked with --enable-dbus, it should check for DBUS libraries and abort if not found. The coding style in monitor-dbus.c is different from what is commonly used in Qemu. Some long lines could be shortened. Enabling of DEBUG_ACPI and other ACPI changes are probably not directly needed so they should be in separate patches. Only commands are included, how about reading values and statistics? -- Sincerly, Yuval Kashtan
