[Qemu-devel] [PATCH] Fix drive names in windows
Hi,
Attached patch fixes drive names for windows. Using $ in formatting strings
seems to be Unix specific.
Regards,
Edu
--- vl.c 17 Dec 2007 04:42:28 - 1.388
+++ vl.c 21 Dec 2007 00:08:50 -
@@ -5091,8 +5091,13 @@
if (type == IF_IDE || type == IF_SCSI)
mediastr = (media == MEDIA_CDROM) ? -cd : -hd;
-snprintf(buf, sizeof(buf), max_devs ? %1$s%4$i%2$s%3$i : %s%s%i,
- devname, mediastr, unit_id, bus_id);
+if (max_devs) {
+snprintf(buf, sizeof(buf), %s%i%s%i,
+ devname, bus_id, mediastr, unit_id);
+} else {
+snprintf(buf, sizeof(buf), %s%s%i,
+ devname, mediastr, unit_id);
+}
bdrv = bdrv_new(buf);
drives_table[nb_drives].bdrv = bdrv;
drives_table[nb_drives].type = type;
Re: [Qemu-devel] Windows build broken
2007/12/12, C.W. Betts [EMAIL PROTECTED]:
Could you perhaps give a patch? I don't feel like going through and
changing every instance of BlockInterfaceType to something else.
Having a closer look I think the underlying problem is a name conflict with
a #define in Mingw's header file basetyps.h, so renaming variables looks
right to me. Patch attached.
Regards,
*** sysemu.h
--- sysemu.h
--- sysemu.h 2 Dec 2007 04:51:08 - 1.2
+++ sysemu.h 12 Dec 2007 19:17:47 -
@@ -122,7 +122,7 @@
typedef struct DriveInfo {
BlockDriverState *bdrv;
-BlockInterfaceType interface;
+BlockInterfaceType binterface;
int bus;
int unit;
} DriveInfo;
@@ -134,8 +134,8 @@
int nb_drives;
DriveInfo drives_table[MAX_DRIVES+1];
-extern int drive_get_index(BlockInterfaceType interface, int bus, int unit);
-extern int drive_get_max_bus(BlockInterfaceType interface);
+extern int drive_get_index(BlockInterfaceType binterface, int bus, int unit);
+extern int drive_get_max_bus(BlockInterfaceType binterface);
/* serial ports */
*** vl.c
--- vl.c
--- vl.c 10 Dec 2007 20:00:10 - 1.378
+++ vl.c 12 Dec 2007 19:17:09 -
@@ -4811,14 +4811,14 @@
return nb_drives_opt++;
}
-int drive_get_index(BlockInterfaceType interface, int bus, int unit)
+int drive_get_index(BlockInterfaceType binterface, int bus, int unit)
{
int index;
/* seek interface, bus and unit */
for (index = 0; index nb_drives; index++)
-if (drives_table[index].interface == interface
+if (drives_table[index].binterface == binterface
drives_table[index].bus == bus
drives_table[index].unit == unit)
return index;
@@ -4826,14 +4826,14 @@
return -1;
}
-int drive_get_max_bus(BlockInterfaceType interface)
+int drive_get_max_bus(BlockInterfaceType binterface)
{
int max_bus;
int index;
max_bus = -1;
for (index = 0; index nb_drives; index++) {
-if(drives_table[index].interface == interface
+if(drives_table[index].binterface == binterface
drives_table[index].bus max_bus)
max_bus = drives_table[index].bus;
}
@@ -4846,7 +4846,7 @@
char file[1024];
char devname[128];
const char *mediastr = ;
-BlockInterfaceType interface;
+BlockInterfaceType binterface;
enum { MEDIA_DISK, MEDIA_CDROM } media;
int bus_id, unit_id;
int cyls, heads, secs, translation;
@@ -4875,11 +4875,11 @@
!strcmp(machine-name, SS-600MP) ||
!strcmp(machine-name, versatilepb) ||
!strcmp(machine-name, versatileab)) {
-interface = IF_SCSI;
+binterface = IF_SCSI;
max_devs = MAX_SCSI_DEVS;
strcpy(devname, scsi);
} else {
-interface = IF_IDE;
+binterface = IF_IDE;
max_devs = MAX_IDE_DEVS;
strcpy(devname, ide);
}
@@ -4906,22 +4906,22 @@
if (get_param_value(buf, sizeof(buf), if, str)) {
strncpy(devname, buf, sizeof(devname));
if (!strcmp(buf, ide)) {
- interface = IF_IDE;
+ binterface = IF_IDE;
max_devs = MAX_IDE_DEVS;
} else if (!strcmp(buf, scsi)) {
- interface = IF_SCSI;
+ binterface = IF_SCSI;
max_devs = MAX_SCSI_DEVS;
} else if (!strcmp(buf, floppy)) {
- interface = IF_FLOPPY;
+ binterface = IF_FLOPPY;
max_devs = 0;
} else if (!strcmp(buf, pflash)) {
- interface = IF_PFLASH;
+ binterface = IF_PFLASH;
max_devs = 0;
} else if (!strcmp(buf, mtd)) {
- interface = IF_MTD;
+ binterface = IF_MTD;
max_devs = 0;
} else if (!strcmp(buf, sd)) {
- interface = IF_SD;
+ binterface = IF_SD;
max_devs = 0;
} else {
fprintf(stderr, qemu: '%s' unsupported bus type '%s'\n, str, buf);
@@ -5036,7 +5036,7 @@
if (unit_id == -1) {
unit_id = 0;
- while (drive_get_index(interface, bus_id, unit_id) != -1) {
+ while (drive_get_index(binterface, bus_id, unit_id) != -1) {
unit_id++;
if (max_devs unit_id = max_devs) {
unit_id -= max_devs;
@@ -5057,23 +5057,23 @@
* ignore multiple definitions
*/
-if (drive_get_index(interface, bus_id, unit_id) != -1)
+if (drive_get_index(binterface, bus_id, unit_id) != -1)
return 0;
/* init */
-if (interface == IF_IDE || interface == IF_SCSI)
+if (binterface == IF_IDE || binterface == IF_SCSI)
mediastr = (media == MEDIA_CDROM) ? -cd : -hd;
snprintf(buf, sizeof(buf), max_devs ? %1$s%4$i%2$s%3$i : %s%s%i,
devname, mediastr, unit_id, bus_id);
bdrv = bdrv_new(buf);
drives_table[nb_drives].bdrv = bdrv;
-drives_table[nb_drives].interface = interface;
+drives_table[nb_drives].binterface = binterface;
drives_table[nb_drives].bus = bus_id;
drives_table[nb_drives].unit = unit_id;
nb_drives++;
-switch(interface) {
+
Re: [Qemu-devel] qemu fpu/softfloat-specialize.h fpu/softfloat.c...
2007/11/21, Paul Brook [EMAIL PROTECTED]: Ok the problem comes from bad copypaste. Please find a patch below that fixes the problem on MIPS. av = float64_val(a); -bv = float64_val(a); +bv = float64_val(b); Applied, thanks for tracking this down. Sorry about the breakage. Paul Hi, Shouldn't these lines in COMPARE be fixed also? av = float ## s ## _val(a); \ bv = float ## s ## _val(a); \ Regards, Edu
Re: [Qemu-devel] fake device to access to host fs
2007/11/8, Tristan Gingold [EMAIL PROTECTED]: Hi, has anyone already implemented a fake device to access to the host FS ? I am planning to implement one soon, but if it is already available... Thanks, Tristan. Hi, Have a look to the vvfat block device. Regards, Edu
[Qemu-devel] [Patch] VNC: Fix crash with non-resizing clients
Hi,
2007/9/25, GUERRAZ Francois [EMAIL PROTECTED]:
About your VNC problems : I have had problems w/ vnc too (see
http://qemu-forum.ipi.fi/viewtopic.php?p=10468) but had no answer as
well...
This problem happens when the VNC client doesn't support the DesktopSize
pseudo-encoding. Qemu crashes when the guest resizes down its display and
the VNC client sends a SetPixelFormat afterwards.
Attached patch should fix this. It also forces a full buffer update after
resize.
Regards,
Edu
*** vnc.c 30 Sep 2007 13:01:15 - 1.25
--- vnc.c 3 Oct 2007 18:44:17 -
@@ -289,15 +289,19 @@
ds-width = w;
ds-height = h;
ds-linesize = w * vs-depth;
-if (vs-csock != -1 vs-has_resize size_changed) {
- vnc_write_u8(vs, 0); /* msg id */
- vnc_write_u8(vs, 0);
- vnc_write_u16(vs, 1); /* number of rects */
- vnc_framebuffer_update(vs, 0, 0, ds-width, ds-height, -223);
- vnc_flush(vs);
- vs-width = ds-width;
- vs-height = ds-height;
+if (size_changed) {
+if (vs-csock != -1 vs-has_resize) {
+vnc_write_u8(vs, 0); /* msg id */
+vnc_write_u8(vs, 0);
+vnc_write_u16(vs, 1); /* number of rects */
+vnc_framebuffer_update(vs, 0, 0, ds-width, ds-height, -223);
+vnc_flush(vs);
+}
+memset(vs-dirty_row, 0xFF, sizeof(vs-dirty_row));
+memset(vs-old_data, 42, ds-linesize * ds-height);
}
+vs-width = ds-width;
+vs-height = ds-height;
}
/* fastest code */
Re: [Qemu-devel] [Patch] VNC: Fix crash with non-resizing clients
2007/10/3, Daniel P. Berrange [EMAIL PROTECTED]: The memset calls in that patch are bogus not correctly fixing the buffer update problem. You're merely setting the 'old data' to have pixel value 42 - if the guest OS framebuffer happens to also have aras with pixel value of 42 too, the frame buffer will still not correctly update. The root problem is overly-aggressive update minimization logic in vnc_update_client. This is in turn flawed beause the dirty_row aray is trying to encode two separate concepts - areas which are dirty, and areas which need to be sent to the client. The latter are a superset of the former, but the code in vnc_update_client minimizes based on dirtiness, so updates will get missed out. Setting the old data to 42 merely changes which areas will get missed updates. Agreed. I just used the same hack that is scattered around several other places to make a patch quickly. The QEMU code in Xen has added a update_row field, separate from the dirty_row field. Thus after a resize it can update the entire framebuffer, regardless of whether QEMU's copy of the framebuffer is dirty wrt to the guest copy. I think that VNC server needs a deep rework, as several qemu related projects have done, but meanwhile correcting bugs with small non-intrusive patches may be the way to go. Edu.
[Qemu-devel] [Patch] Support UltraVNC clients
Hi,
UltraVNC clients report non standard RFB protocol 3.4. Attached patch makes
vnc server treat them as 3.3.
Regards,
Edu
*** vnc.c 17 Sep 2007 08:09:45 - 1.24
--- vnc.c 26 Sep 2007 22:44:57 -
@@ -1818,6 +1818,7 @@
VNC_DEBUG(Client request protocol version %d.%d\n, vs-major, vs-minor);
if (vs-major != 3 ||
(vs-minor != 3
+ vs-minor != 4
vs-minor != 5
vs-minor != 7
vs-minor != 8)) {
@@ -1827,10 +1828,10 @@
vnc_client_error(vs);
return 0;
}
-/* Some broken client report v3.5 which spec requires to be treated
+/* Some broken clients report v3.4 or v3.5, which spec requires to be treated
* as equivalent to v3.3 by servers
*/
-if (vs-minor == 5)
+if (vs-minor == 4 || vs-minor == 5)
vs-minor = 3;
if (vs-minor == 3) {
Re: [Qemu-devel] vnc with german keymap
2007/7/6, Juergen Lock [EMAIL PROTECTED]: On Thu, Jul 05, 2007 at 10:42:03AM +0200, Eduardo Felipe wrote: Your VNC client probably sends deadkey messages... or maybe I have a complicated way to handle simple things :) Yup, I tested with tightvnc-1.3.8. I've tried tightvnc and it does send deadkey messages. By contrast, RealVNC is an example of client that sends extended Latin-1 (or similar) characters. (You might want to explain this fact on the list tho, it may have been the reason your patch wasn't committed...) Bye, Juergen Agreed, cc'ing. I just forgot to Reply-to-all last time... Regards, Edu
Re: [Qemu-devel] vnc with german keymap
2007/7/4, Juergen Lock [EMAIL PROTECTED]: Ah, thanx, I didnt see that one! :) I have a qeuestion tho: does this patch do deadkey handling on the host? Yes. IIRC I needed that because some VNC clients I tested didn't send dead keys to the server. They just waited for a full character to be available in its buffer to send the KeyEvent message, as they assume the server will know how to represent it. That is, if I press ´ and o in some VNC clients, only an ó (0x00f3) message is sent after pressing the last key, not the 0xfe51 / 0x006f combination. The server (qemu) has to know how to build the character for its guest. Because I didn't have to do anything like that for the de patch, the guest could do that itself just fine. (tested with a linux livecd guest with (under X) and without deadkeys (console).) Your VNC client probably sends deadkey messages... or maybe I have a complicated way to handle simple things :) Regards, Edu
Re: [Qemu-devel] vnc with german keymap
Hi,
Some time ago I made a patch to handle keyboard localization for vnc:
http://lists.gnu.org/archive/html/qemu-devel/2006-08/msg00129.html
It is outdated and most probably won't apply to current CVS, but with some
tweaking it can improve things a bit.
Regads,
Eduardo Felipe
2007/7/4, Juergen Lock [EMAIL PROTECTED]:
Hi!
I got a report yesterday of -vnc not working right with german
keymaps (I hadn't really played with -vnc yet so I hadn't noticed),
and came up with the following hack: (which still needs -k de,
that just wasn't enough)
Index: qemu/vnc.c
@@ -763,7 +763,31 @@
{
int keycode;
+#if 1
+/* XXX fixup some de keysyms (use with -k de) */
+if ((sym 0x) == 0xfe03)/* Alt_Gr - Alt_R */
+ sym = 0xffea;
+if ((sym 0x) == 0xfe50)/* grave */
+ sym = '`';
+#if 0
+if ((sym 0x) == 0xfe51)/* '/acute (gets mixed up with #) */
+ sym = '\'';
+#endif
+if ((sym 0x) == 0xfe52)/* asciicircum */
+ sym = '^';
+if ((sym 0x) == 0xfe53)/* asciitilde */
+ sym = '~';
+#endif
keycode = keysym2scancode(vs-kbd_layout, sym 0x);
+#if 1
+/* '/acute key needs special treatment */
+if (!keycode (sym 0x) == 0xfe51)/* acute */
+ keycode = 0xd;
+#endif
+#ifdef VNCDEBUGKEYS
+printf(do_key_event down %d, sym 0x%x, keycode 0x%x\n,
+ down, (int) sym, keycode);
+#endif
/* QEMU console switch */
switch(keycode) {
I wasn't able to fix this by editing vnc_keysym.h and/or keymaps
because those dont take duplicate definitions, but this is certainly
`somewhat' ugly; anyone care to fix it for real? :)
Thanx,
Juergen
Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU
I think I could not explain my question regarding addl %ebx, (%eax). What I wanted to ask was that this instruction also accesses the memory and I also need to intercept it within a transaction. Incase of addl %ebx, (%eax), Are the functions under /* CPU memory access without any memory or io remapping */ called in case of this instruction. Yes. Just look how the instruction is translated into opcodes and you'll see how it works. You can use the -d switch for this. Secondly, there is a function in exec.c called cpu_physical_memory_rw. Is it easier to hack into this fuction to intercept the memory references. That function is used by emulated hardware devices to interact with memory ( e.g. DMA to write and read memory chunks). Translated guest code does not use it. Regards, Eduardo
Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU
2007/4/25, Atif Hashmi [EMAIL PROTECTED]: Instructions like addl %ebx, (%eax) are also considered to be memory refernce instructions. Do these type of instructions also refer to the functions that you mentioned. No. You are using __asm_volatile(mov %al %al) to mark the start of your transaction and __asm_volatile(mov %bl %bl) to mark the end. What I meant is that your compiler could generate mov %al,%al or mov %bl,%bl in any other place for whatever reason when it compiles C code. Also your guest OS or any other program running in it can use these two instructions too. Both cases would affect in what you intend to do. Secondly, what is the purpose of undef ASM_SOFTMMU If ASM_SOFTMMU is defined, pure assembly memory access routines are used (faster). If it is not defined, alternative C routines are used, which are slower but easier to modify. Regards, Eduardo
Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU
Hi, You have a description of memory access instruction format in cpu-all.h, under /* CPU memory access without any memory or io remapping */ These instructions are defined in softmmu_header.h. If you don't care too much about performance it will be easier to modify the code written in C (undef ASM_SOFTMMU in op.c). Regards, Eduardo
Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU
Hi Atif, Your code seems quite ok to me. Just try including stored_eip inside the DisasContext, otherwise you'll lose its value between calls to disas_insn function. Also make sure that the instructions you are using as markers are not executed elsewhere, as your compiler could generate them inside regular code or they could already exist in your OS. Regards, Eduardo
Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU
Hi
2007/4/17, Atif Hashmi [EMAIL PROTECTED]:
But this prints Transaction restart once and then the program finishes.
This means that commit transaction is not called the second time. Could you
please tell me what am I doing wrong?
Helper functions are outside the translated opcode stream and are invoked by
call/ret:
.--.
| |
| ---+-- helper_StartTransaction()
| --+---/
| |
| |
| ---+-- helper_CommitTransaction()
| --+---/
| |
'--'
When you longjmp from helper_CommitTransaction to helper_StartTransaction
it's probable that you return back to the point where
helper_CommitTransaction should have returned to, as it is the last address
stored in the stack.
Anyway, guest code between the start and the end of the transaction should
not be rerun without updating guest machine state (eip, flags, etc.).
You should better forget about using setjmp/longjmp. Maybe something like
this could do the trick:
when translating mov %al,%al:
{
...
...
store the address (eip) of mov %al,%al instruction somewhere
gen_op_start_transaction();
}
when translating mov %bl, %bl:
{
...
...
gen_op_commit_transaction(stored_eip);
gen_eob(s); // Stop translation to force guest state updating
}
op_commit_transaction should look like:
{
if ( helper_CommitTransaction() ) // helper should return !=0 on error
EIP = PARAM1;
}
Regards,
Eduardo
Re: [Qemu-devel] time inside qemu
Hi, I just tried with cpu_disable_ticks() and cpu_enable_ticks(). It seems to work partially: at least now system date and time are out of sync.. Maybe a more accurate way to do this is mimicking stop and continue monitor commands: vm_stop(EXCP_INTERRUPT); [SystemC simulation] vm_start(); This just takes SystemC emulation time out of the equation. You cannot make any reliable performance measure of qemu's translated code, as already mentioned, but the former may be enough for your requirements. Regards, Eduardo Felipe
Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)
Sorry, I'm afraid I badly mixed up things in my mind. vncrec and pyvnc2swf record VNC server responses, not client actions, so they will hardly be of any help. To record and replay client actions these tools are more appropriate: http://cyberelk.net/tim/rfbproxy/ http://cyberelk.net/tim/rfbplaymacro/ Although they seem not to be available at this moment... Regards, Eduardo
Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU
Hi Atif,
In target-i386/translate.c, there are many variants of mov i.e.
case 0x89: /* mov Gv, Ev */
case 0xc7: /* mov Ev, Iv */
case 0x8b: /* mov Ev, Gv */
case 0x8e: /* mov seg, Gv */
That's true. I forgot the fact that mov %eax,%eax can be both:
0x89 0xC0
0x8B 0xC0
It's up to the compiler to choose which one to use.
which one do you think will be called when mov %eax, %eax instruction is
translated.
I printed the value of modrm inside the case 0x89 but the value remains
the same whether I use %eax or %ebx.
Secondly, How can I extract the source and destination registers from
modrm.
modrm is the byte following the 0x89 or 0x8B opcode. After
modrm = ldub_code(s-pc++);
you can decode it this way (in binary):
XXYYYZZZ
XX -- Indexing mode
YYY -- Destination register
ZZZ -- Source register
0xC0 is the value you are looking for 11 000 000 -- (no
indexing)(%eax)(%eax).
You can find more information here:
http://pdos.csail.mit.edu/6.828/2005/readings/i386/s17_02.htm
One more thing: you may want to check operand size. It's on ot variable,
and its meaning (from translate.c):
enum {
OT_BYTE = 0,
OT_WORD,
OT_LONG,
OT_QUAD,
};
being 8, 16, 32 and 64 bits respectively.
Regards,
Eduardo
Re: [Qemu-devel] Feature proposal: USB devices over TCP
Hi Anthony, I don't know all that much about USB, but I think the most useful way to do this would be to do something that's protocol compatible with USBIP. Neither I do. I didn't know anything about USB/IP, it would be cool to be protocol compatible with it. As we have to start from scratch, USB/IP can be a very good reference. We could then tunnel this traffic over VNC and allow for exposing local USB devices to a remote VM. I don't think that tunneling traffic through VNC is possible. In QEMU the VNC implementation is asynchronous, while the USB layer expects an immediate response to any request. Think of a virtual desktop being hosted on a server and exposed on a thin client. If you could plug in your iPod and it would just work with the VM, that would be an exceedingly cool feature. Are you familiar with USBIP? If so, does this sound reasonable? It would be cool indeed. Maybe some wrapper around libusb could do the trick for host OSes where no USB/IP server is available. I'll have a look at USB/IP. Regards, Eduardo Felipe
Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU
Hi, Your should create a new helper function in \target-i386\helper.c to perform whatever you want QEMU to do when movl %eax,%eax is found. To invoke that function create a new opcode in \target-i386\op.c. That opcode should only call your helper function. Finally, modify \target-i386\translate.c to generate your opcode when movl %eax,%eax is translated. Look for the string 0x89, you can find out target and source registers of the move operation from variable modrm, so only %eax is considered. Regards, Eduardo
Re: [Qemu-devel] Problem with windows qemu port
-monitor option is not supported. The server variants of the command work for me on Windows, though. Try: -monitor tcp:127.0.0.1:9100,server or just -monitor tcp::9100,server to start qemu in server mode listening to port 9100. Then make your GUI connect to qemu, instead of the other way around. Regards, Eduardo Felipe ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
