[Qemu-devel] [PATCH] bsd-user: Fix possible memory leaks
These errors were reported by cppcheck:
bsd-user/elfload.c:1076: error: Memory leak: s
bsd-user/elfload.c:1079: error: Memory leak: syms
Cc: Blue Swirl
Signed-off-by: Stefan Weil
---
bsd-user/elfload.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/bsd-user/elfload.c b/bsd-user/elfload.c
index 7374912..313ddc6 100644
--- a/bsd-user/elfload.c
+++ b/bsd-user/elfload.c
@@ -1072,11 +1072,16 @@ static void load_symbols(struct elfhdr *hdr, int fd)
/* Now know where the strtab and symtab are. Snarf them. */
s = malloc(sizeof(*s));
syms = malloc(symtab.sh_size);
-if (!syms)
+if (!syms) {
+free(s);
return;
+}
s->disas_strtab = strings = malloc(strtab.sh_size);
-if (!s->disas_strtab)
+if (!s->disas_strtab) {
+free(s);
+free(syms);
return;
+}
lseek(fd, symtab.sh_offset, SEEK_SET);
if (read(fd, syms, symtab.sh_size) != symtab.sh_size)
--
1.7.2.3
[Qemu-devel] Re: [PATCH] bsd-user: Fix possible memory leaks
On Sun, Jan 16, 2011 at 12:56 PM, Stefan Weil wrote:
> These errors were reported by cppcheck:
>
> bsd-user/elfload.c:1076: error: Memory leak: s
> bsd-user/elfload.c:1079: error: Memory leak: syms
>
> Cc: Blue Swirl
> Signed-off-by: Stefan Weil
> ---
> bsd-user/elfload.c | 9 +++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/bsd-user/elfload.c b/bsd-user/elfload.c
> index 7374912..313ddc6 100644
> --- a/bsd-user/elfload.c
> +++ b/bsd-user/elfload.c
> @@ -1072,11 +1072,16 @@ static void load_symbols(struct elfhdr *hdr, int fd)
> /* Now know where the strtab and symtab are. Snarf them. */
> s = malloc(sizeof(*s));
> syms = malloc(symtab.sh_size);
> - if (!syms)
> + if (!syms) {
If we used qemu_malloc(), this wouldn't happen since it will exit if
malloc() fails. But is that OK, maybe we want to load the file without
symbols then?
Re: [Qemu-devel] [PATCH] bsd-user: Fix possible memory leaks
On 16 January 2011 12:56, Stefan Weil wrote:
> diff --git a/bsd-user/elfload.c b/bsd-user/elfload.c
> index 7374912..313ddc6 100644
> --- a/bsd-user/elfload.c
> +++ b/bsd-user/elfload.c
> @@ -1072,11 +1072,16 @@ static void load_symbols(struct elfhdr *hdr, int fd)
> /* Now know where the strtab and symtab are. Snarf them. */
> s = malloc(sizeof(*s));
> syms = malloc(symtab.sh_size);
> - if (!syms)
> + if (!syms) {
> + free(s);
> return;
> + }
> s->disas_strtab = strings = malloc(strtab.sh_size);
> - if (!s->disas_strtab)
> + if (!s->disas_strtab) {
> + free(s);
> + free(syms);
> return;
> + }
>
> lseek(fd, symtab.sh_offset, SEEK_SET);
> if (read(fd, syms, symtab.sh_size) != symtab.sh_size)
Don't we also need to free s, syms and strings in the
places later in the function where we return early
(if read() calls fail)?
The function also has an unchecked call to realloc().
(All these things are handled correctly in the linux-user/
version of this function.)
Blue Swirl wrote:
> If we used qemu_malloc(), this wouldn't happen since it will exit if
> malloc() fails. But is that OK, maybe we want to load the file without
> symbols then?
AFAICT symbols are only used for debug tracing, so carrying
on without them is a reasonable strategy. (Although if you
fail a malloc this early on the chances of successfully running
anything are not good, so it's a bit moot.)
-- PMM
[Qemu-devel] [Bug 584153] Re: no useful error message when tap device open fails
** Changed in: qemu Status: In Progress => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/584153 Title: no useful error message when tap device open fails Status in QEMU: Fix Committed Status in “qemu-kvm” package in Debian: Fix Released Bug description: When using tap network devices and it fails, qemu gives no information about what the problem is (permission denied, device busy or other), making debugging of such situations, especially for newbies, very difficult. The proposed patch just adds strerror() around the place, making it more friendly. See also Debian bug#578154, http://bugs.debian.org/cgi- bin/bugreport.cgi?bug=578154 and a discussion on qemu-devel at http://marc.info/?t=12719287523 .
[Qemu-devel] [Bug 573827] Re: QEMU 0.12.3 crashes on incomplete USB serial device parameter
** Changed in: qemu Status: In Progress => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/573827 Title: QEMU 0.12.3 crashes on incomplete USB serial device parameter Status in QEMU: Fix Committed Bug description: When calling qemu by "qemu -usbdevice serial" (i.e. with an incomplete specification of the USB serial device), qemu crashes with a segfault. Debugging the problem has revealed that usb_serial_init() in usb- serial.c does not handle the incomplete parameter. The attached patch fixes the issue.
Re: [Qemu-devel] TCG flow vs dyngen
On Wed, Dec 15, 2010 at 4:17 AM, Stefano Bonifazi wrote: > On 12/11/2010 03:44 PM, Blue Swirl wrote: > > Hi! > Thank you very much! Knowing exactly where I should check, in a so big > project helped me very much!! > Anyway after having spent more than 2 days on that code I still can't > understand how it works the real execution: > > in cpu-exec.c : cpu_exec_nocache i find: > >> /* execute the generated code */ >>next_tb = tcg_qemu_tb_exec(tb->tc_ptr); > > and in cpu-exec.c : cpu_exec > >> /* execute the generated code */ >> >>next_tb = tcg_qemu_tb_exec(tc_ptr); > > so I thought tcg_qemu_tb_exec "function" should do the work of executing the > translated binary in the host. > But then I found out it is just a define in tcg.h: > >> #define tcg_qemu_tb_exec(tb_ptr) ((long REGPARM (*)(void >> *))code_gen_prologue)(tb_ptr) > > and again in exec.c > >> uint8_t code_gen_prologue[1024] code_gen_section; > > Maybe I have some problems with that C syntax, but I really don't understand > what happens there.. how the execution happens! > > Here instead with QEMU/TCG I understood that at runtime the target binary > is translated into host binary (somehow) .. but then.. how can this new host > binary be run? Shall the host code at runtime do some sort of (assembly > speaking) branch jump to an area of memory with new host binary instructions > .. and then jump back to the old process binary code? 1. As I know, the host codes translated from the target instructions exist by the format of object file, that’s why they can be executed directly. 2. I think you catch the right concept in some point of view, one part of the internal of QEMU does such jump & back works certainly. > If so, can you explain me how this happens in those lines of code? I only can give a rough profile, the code you listed do a simple thing: Modify the pointer of the host code execution to point the next address that the host processor should continue to execute. > I am just a student.. unluckily at university they just tell you that a cpu > follows some sort of "fetch ->decode->execute" flow .. but then you open > QEMU.. and wow there is a huge gap for understanding it, and no books where > to study it! ;) The QEMU is not used to simulate the every details of the processor should behave, it just try to approximate the necessary operations what a machine should be! “fetch->decode->execute” flow only need to be concerned when you involve into the hardware design. Raphaël Lefèvre
[Qemu-devel] [Bug 581737] Re: Can't read e1000 NIC EEPROM on NetBSD guest
** Changed in: qemu Status: Incomplete => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/581737 Title: Can't read e1000 NIC EEPROM on NetBSD guest Status in QEMU: Fix Committed Bug description: QEMU Version: qemu-0.12.4 Host OS: NetBSD/i386 5.0.2 Guest OS: NetBSD/i386 5.1_RC1 On this environment, guest NetBSD tries to attach e1000 NIC using its own wm(4) driver but fails to read EEPROM as the following: --- NetBSD 5.1_RC1 (GENERIC) #0: Sat Apr 24 23:26:09 UTC 2010 bui...@b7.netbsd.org:/home/builds/ab/netbsd-5-1-RC1/i386/201004250032Z-obj/home/builds/ab/ netbsd-5-1-RC1/src/sys/arch/i386/compile/GENERIC total memory = 127 MB avail memory = 113 MB Bochs Bochs : drm at vga1 not configured wm0 at pci0 dev 3 function 0: Intel i82540EM 1000BASE-T Ethernet, rev. 3 wm0: interrupting at irq 11 wm0: unable to read Ethernet address isa0 at pcib0 : --- You can reproduce this with NetBSD/i386 install CD image: ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-5.1_RC1/iso/i386cd-5.1_RC1.iso % qemu -cdrom i386cd-5.1_RC1.iso -boot d ---in QEMU window--- [type ^C to quit installer] # dmesg | grep wm0 -- Per DBGOUT(EEPROM) messages, it show too large eecd_state.bitnum values, i.e. EEPROM state is not reset properly. The set_eecd() function in e1000.c clears EEPROM internal state values on SK rising edge during CS==L. But according to FM93C06 EEPROM (which is MicroWire compatible) data sheet, EEPROM internal status should be cleared on CS rise edge regardless of SK input: "... a rising edge on this signal is required to reset the internal state-machine to accept a new cycle .." Intel's em driver seems to explicitly raise and lower SK output after CS is negated in em_standby_eeprom() so many other OSes that use Intel's driver don't have this problem with current e1000.c implementation, but I can't find articles that say the MICROWIRE or EEPROM spec requires such sequence. With the attached patch, NetBSD guest properly gets MAC address from e1000 NIC EEPROM.
[Qemu-devel] [Bug 578346] Re: ATA IDENTIFY DEVICE word 64 doesn't describe available PIO modes
** Changed in: qemu Status: New => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/578346 Title: ATA IDENTIFY DEVICE word 64 doesn't describe available PIO modes Status in QEMU: Fix Committed Bug description: The IDENTIFY DEVICE data provided by Qemu ATA devices lacks good information in word 64. Word 64 describes PIO mode capabilities. NetBSD guests (perhaps dubiously) expect to find PIO modes 3 and/or 4 to be available before enabling Ultra DMA modes on the controller/device. This leads to NetBSD guests using PIO mode 0. NetBSD guests will accept values in the range of 0x00 through 0x1f (though at least one bit must be set for DMA to be considered) in word 64. Currently, ide_atapi_identify() sets this word to 0x3f in the USE_DMA_CDROM case and 0x01 otherwise. ide_identify() doesn't set this word at all. I recommend that these both be adjusted to 0x3, which parallels many real drives in the wild, as well as what a ATA8-ACS draft says SATA drives should have in word 64.
Re: [Qemu-devel] TCG flow vs dyngen
On 01/16/2011 03:46 PM, Raphael Lefevre wrote: On Wed, Dec 15, 2010 at 4:17 AM, Stefano Bonifazi wrote: > On 12/11/2010 03:44 PM, Blue Swirl wrote: > > Hi! > Thank you very much! Knowing exactly where I should check, in a so big > project helped me very much!! > Anyway after having spent more than 2 days on that code I still can't > understand how it works the real execution: > > in cpu-exec.c : cpu_exec_nocache i find: > >> /* execute the generated code */ >>next_tb = tcg_qemu_tb_exec(tb->tc_ptr); > > and in cpu-exec.c : cpu_exec > >> /* execute the generated code */ >> >>next_tb = tcg_qemu_tb_exec(tc_ptr); > > so I thought tcg_qemu_tb_exec "function" should do the work of executing the > translated binary in the host. > But then I found out it is just a define in tcg.h: > >> #define tcg_qemu_tb_exec(tb_ptr) ((long REGPARM (*)(void >> *))code_gen_prologue)(tb_ptr) > > and again in exec.c > >> uint8_t code_gen_prologue[1024] code_gen_section; > > Maybe I have some problems with that C syntax, but I really don't understand > what happens there.. how the execution happens! > > Here instead with QEMU/TCG I understood that at runtime the target binary > is translated into host binary (somehow) .. but then.. how can this new host > binary be run? Shall the host code at runtime do some sort of (assembly > speaking) branch jump to an area of memory with new host binary instructions > .. and then jump back to the old process binary code? 1. As I know, the host codes translated from the target instructions exist by the format of object file, that’s why they can be executed directly. 2. I think you catch the right concept in some point of view, one part of the internal of QEMU does such jump & back works certainly. > If so, can you explain me how this happens in those lines of code? I only can give a rough profile, the code you listed do a simple thing: Modify the pointer of the host code execution to point the next address that the host processor should continue to execute. > I am just a student.. unluckily at university they just tell you that a cpu > follows some sort of "fetch ->decode->execute" flow .. but then you open > QEMU.. and wow there is a huge gap for understanding it, and no books where > to study it! ;) The QEMU is not used to simulate the every details of the processor should behave, it just try to approximate the necessary operations what a machine should be! “fetch->decode->execute” flow only need to be concerned when you involve into the hardware design. Raphaël Lefèvre Thank you very much! I've already solved this problem.. Right now I am fighting with the possibility of changing qemu-user code for making it run several binaries in succession .. But it seems to remember the first translated code.. Nobody answered to my post about it, do you have any idea?
Re: [Qemu-devel] [PATCH] bsd-user: Fix possible memory leaks
Am 16.01.2011 15:07, schrieb Peter Maydell:
On 16 January 2011 12:56, Stefan Weil wrote:
diff --git a/bsd-user/elfload.c b/bsd-user/elfload.c
index 7374912..313ddc6 100644
--- a/bsd-user/elfload.c
+++ b/bsd-user/elfload.c
@@ -1072,11 +1072,16 @@ static void load_symbols(struct elfhdr *hdr,
int fd)
/* Now know where the strtab and symtab are. Snarf them. */
s = malloc(sizeof(*s));
syms = malloc(symtab.sh_size);
-if (!syms)
+if (!syms) {
+free(s);
return;
+}
s->disas_strtab = strings = malloc(strtab.sh_size);
-if (!s->disas_strtab)
+if (!s->disas_strtab) {
+free(s);
+free(syms);
return;
+}
lseek(fd, symtab.sh_offset, SEEK_SET);
if (read(fd, syms, symtab.sh_size) != symtab.sh_size)
Don't we also need to free s, syms and strings in the
places later in the function where we return early
(if read() calls fail)?
You are correct. cppcheck only reports the first location in a function.
I should have called it again after my modifications.
The function also has an unchecked call to realloc().
(All these things are handled correctly in the linux-user/
version of this function.)
The realloc() is handled in linux-user, but not in a correct way.
A new version of my patch fixes the missing memory leaks
and realloc for bsd-user.
A second patch is needed to fix realloc for linux-user, too.
Blue Swirl wrote:
If we used qemu_malloc(), this wouldn't happen since it will exit if
malloc() fails. But is that OK, maybe we want to load the file without
symbols then?
AFAICT symbols are only used for debug tracing, so carrying
on without them is a reasonable strategy. (Although if you
fail a malloc this early on the chances of successfully running
anything are not good, so it's a bit moot.)
-- PMM
[Qemu-devel] [PATCH v2] bsd-user: Fix possible memory leaks and wrong realloc call
These errors were reported by cppcheck:
[bsd-user/elfload.c:1108]: (error) Common realloc mistake: "syms" nulled but
not freed upon failure
[bsd-user/elfload.c:1076]: (error) Memory leak: s
[bsd-user/elfload.c:1079]: (error) Memory leak: syms
v2:
* The previous fix for memory leaks was incomplete (thanks to Peter Maydell for
te hint).
* Fix wrong realloc usage, too.
Cc: Blue Swirl
Signed-off-by: Stefan Weil
---
bsd-user/elfload.c | 37 +++--
1 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/bsd-user/elfload.c b/bsd-user/elfload.c
index 7374912..1ef1f97 100644
--- a/bsd-user/elfload.c
+++ b/bsd-user/elfload.c
@@ -1044,7 +1044,7 @@ static void load_symbols(struct elfhdr *hdr, int fd)
struct elf_shdr sechdr, symtab, strtab;
char *strings;
struct syminfo *s;
-struct elf_sym *syms;
+struct elf_sym *syms, *new_syms;
lseek(fd, hdr->e_shoff, SEEK_SET);
for (i = 0; i < hdr->e_shnum; i++) {
@@ -1072,15 +1072,24 @@ static void load_symbols(struct elfhdr *hdr, int fd)
/* Now know where the strtab and symtab are. Snarf them. */
s = malloc(sizeof(*s));
syms = malloc(symtab.sh_size);
-if (!syms)
+if (!syms) {
+free(s);
return;
+}
s->disas_strtab = strings = malloc(strtab.sh_size);
-if (!s->disas_strtab)
+if (!s->disas_strtab) {
+free(s);
+free(syms);
return;
+}
lseek(fd, symtab.sh_offset, SEEK_SET);
-if (read(fd, syms, symtab.sh_size) != symtab.sh_size)
+if (read(fd, syms, symtab.sh_size) != symtab.sh_size) {
+free(s);
+free(syms);
+free(strings);
return;
+}
nsyms = symtab.sh_size / sizeof(struct elf_sym);
@@ -1105,13 +1114,29 @@ static void load_symbols(struct elfhdr *hdr, int fd)
#endif
i++;
}
-syms = realloc(syms, nsyms * sizeof(*syms));
+
+ /* Attempt to free the storage associated with the local symbols
+that we threw away. Whether or not this has any effect on the
+memory allocation depends on the malloc implementation and how
+many symbols we managed to discard. */
+new_syms = realloc(syms, nsyms * sizeof(*syms));
+if (new_syms == NULL) {
+free(s);
+free(syms);
+free(strings);
+return;
+}
+syms = new_syms;
qsort(syms, nsyms, sizeof(*syms), symcmp);
lseek(fd, strtab.sh_offset, SEEK_SET);
-if (read(fd, strings, strtab.sh_size) != strtab.sh_size)
+if (read(fd, strings, strtab.sh_size) != strtab.sh_size) {
+free(s);
+free(syms);
+free(strings);
return;
+}
s->disas_num_syms = nsyms;
#if ELF_CLASS == ELFCLASS32
s->disas_symtab.elf32 = syms;
--
1.7.2.3
Re: [Qemu-devel] Tracking unfreed tcg temps
On Tue, Jan 11, 2011 at 11:55:33PM +0100, Aurelien Jarno wrote: > On Tue, Jan 11, 2011 at 06:09:06AM -0600, Peter Maydell wrote: > > The ARM target-arm/translate.c file has some code in it which tries to > > track the number of TCG temporaries allocated during translation of an > > ARM instruction and complain if they are not freed by the end of that > > instruction. So new_tmp() allocates a temp with tcg_temp_new_i32() and > > increments the count; dead_tmp() calls tcg_temp_free() and decrements > > the count. If at the end of translating an instruction the count isn't > > zero we print a warning: > > > > fprintf(stderr, "Internal resource leak before %08x\n", dc->pc); > > > > However there are a lot of code paths which will trigger this warning; > > generally these are for invalid encodings where we only notice that > > the opcode is invalid after having loaded the input operands, so we've > > allocated a temp but the generate-UNDEF-exception exit path doesn't > > free it. > > > > tcg/README says that failure to free a temporary is not very harmful, > > because it just means more memory usage and slower translation. (On > > the other hand there seems to be a hardcoded TCG_MAX_TEMPS limit on > > the number of temporaries, which suggests that freeing temporaries is > > important and the README is misleading?) > > This temporary is only valid for a given TB, so the leak is not going to > take more and more memory. On the other hand, if it is easy to trigger > such leaks with non-priviledged instructions and reach TCG_MAX_TEMPS, > this means that a simple user on a virtual machine can crash it. No risk > of security issue, but at least a DoS. > > Note also that our register spill strategy is not really optimized, so > the generated code might be less optimized in such cases. > > > So what's the best thing to do with this temporary-tracking code? > > > > (1) just get rid of it as it is misguided > > I think it is something important to make sure temp are correctly freed. > OTOH, it's maybe not a good idea to expose such message to users. > > > (2) tweak it so that we don't complain about non-freed temps if this > > is the end of the TB anyway [since the invalid-encoding case will > > always result in ending the TB] > > That might be a temporary solution. > > > (3) rework all the code which catches invalid encodings so that we can > > identify undefined instructions before we have done any of the > > preparatory loading of operands that is causing the warning to trigger > > > > [If it is useful to track not-freed-temps like this shouldn't the > > code be in tcg and not ad-hoc in target-arm anyway?] > > I guess this is currently only done in target-arm, as it is loading > registers a bit differently than other targets. Other targets, or at > least some of them, tends to have a short par of code between > tcg_temp_new() and tcg_temp_free(), so it's easier to verify manually. > This is also probably related to the way the instruction space is split, > and for sure thumb doesn't help here. Looking at https://bugs.launchpad.net/qemu/+bug/702885 , it actually seems that resource leak can be the reverse: tcg temps that are freed twice. It can be something dangerous, at it can free the wrong temp. Looking at the code, one of the problem of the ARM target is that some functions free temps passed in arguments, some other don't. I am not sure if it is best to let the caller or the callee free temp arguments, but for sure it's best to have it consistent all along translate.c to avoid coding errors. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] TCG flow vs dyngen
On Sun, Jan 16, 2011 at 11:21 PM, Stefano Bonifazi wrote: > > Thank you very much! > I've already solved this problem.. Right now I am fighting with the > possibility of changing qemu-user code for making it run several binaries in > succession .. But it seems to remember the first translated code.. Nobody > answered to my post about it, do you have any idea? > Sorry for my belated on this discussion, after I searched for the topics you posted, it seems two main problems are unsolved? (Am I right?? I'm not sure...) 1. "I edited QEMU user, more exactly qemu-ppc launching the main function (inside main.c) from another c function I created, passing it the appropriate parameters. ...balabala" at Jan, 2011 2. "how can I check the number of target cpu cycles or target instructions executed inside qemu-user (i.e. qemu-ppc)? Is there any variable I can inspect for such informations?" at Dec, 2010 If I'm not correct, please let me know where the problem is. Raphaël Lefèvre
[Qemu-devel] [Bug 659276] Re: Accessing Century byte via RTC
The century register is only present in "recent" version of the chip, and is at an address corresponding to the NVRAM memory. It is not manipulated directly by the RTC and therefore is always in BCD format. The current QEMU implementation is correct. ** Changed in: qemu Status: New => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/659276 Title: Accessing Century byte via RTC Status in QEMU: Invalid Bug description: With the RTC configure for Binary instead of BCD I am getting the incorrect result for Century. mov al, 0x0B; Set RTC to binary mode out 0x70, al in al, 0x71 bts ax, 2 mov bl, al mov al, 0x0B out 0x70, al mov al, bl out 0x71, al mov al, 0x32; Century out 0x70, al in al, 0x71 In QEMU 0.12.5 it returns 0x20 but should return 0x14. The following work correctly: mov al, 0x09; Year out 0x70, al in al, 0x71 mov al, 0x08; Month out 0x70, al in al, 0x71 mov al, 0x07; Day out 0x70, al in al, 0x71
Re: [Qemu-devel] TCG flow vs dyngen
Sorry for my belated on this discussion, after I searched for the topics you posted, it seems two main problems are unsolved? (Am I right?? I'm not sure...) 1. "I edited QEMU user, more exactly qemu-ppc launching the main function (inside main.c) from another c function I created, passing it the appropriate parameters. ...balabala" at Jan, 2011 2. "how can I check the number of target cpu cycles or target instructions executed inside qemu-user (i.e. qemu-ppc)? Is there any variable I can inspect for such informations?" at Dec, 2010 If I'm not correct, please let me know where the problem is. Raphaël Lefèvre Hi! Thank you very much for Your concern! Honestly I had lost hope in any help, I even contacted directly some developers in this mailing list without luck! I am a student who needs to use qemu for a project where it will be used for its capabilities of running PowerPC code. As you can imagine qemu goes far beyond the knowledge in electronics and computer science of a student. Nevertheless I have to do that! I have been studying all the possible technical documents available in the internet, but it is really not much at all , not sufficient for getting the code and being able of understanding it .. It is in C, even not modular C++ Anyway with some help from this mailing list, and a lot of studying about assembly, loaders, compilers.. I am going on, though there are still big problems due of the nature of the QEMU code.. First of all, I am starting from qemu-user, more specifically, qemu-ppc as I don't need the full system capabilities, and it is easier for me to control the binary target memory with qemu-user. Originally I started with a lot of work on libqemu .. until some developer here told me it was deprecated (though still in the source) and not working fine. I edited the code of qemu-ppc so that another function of mine calls qemu-user main, with the appropriate parameters.. The pursued goal was to launch it several times with different target binaries in succession.. For some reason, I still can't find out, qemu code remembers the old code, running it instead of the new loaded binary.. and if I flush the cache of translated code before loading a new binary it stops and can't go on! My workaround to this problem was compiling qemu-ppc as a dynamic library and load it at runtime.. I also managed to load multiple copies of it (with dlmopen each at a different address space) ..in fact I need to run more than one qemu-ppc at the same time but a new big problem popped up now: the target binary is loaded always at a fixed address.. no matter if another qemu-ppc already loaded code there.. it is like the internal elf loader can't understand those addresses are not available, and then relocate them .. I tried to link (ld) the binary target elf as position independent code, but then qemu-ppc complains it can't find /usr/lib/libc.so.1 and /usr/lib/ld.so.1 To sum up the problems are (in order of importance): - making the elf loader relocate the target code into other addresses when the default ones (I guess those embedded into the target binary when it is not compiled as position independent code) are taken - making qemu-user able of running more than one target binary in succession - counting qemu-user executed instructions My university is a public one, so my project will be open to the community, I will also upload the documentation I am writing about qemu coming from the knowledge I am acquiring working on it, so that, I hope, other people will find less frustrating the first steps into developing qemu! Any help will be more than welcome! Thank you in advance! Stefano B.
Re: [Qemu-devel] TCG flow vs dyngen
2011/1/16 Stefano Bonifazi : > My workaround to this problem was compiling qemu-ppc as a dynamic library > and load it at runtime.. I also managed to load multiple copies of it (with > dlmopen each at a different address space) ..in fact I need to run more than > one qemu-ppc at the same time This approach seems very unlikely to work -- in general qemu in both system and user mode assumes that there is only one instance running in the host process address space, and things are bound to clash. (Linux doesn't seem to have dlmopen but google suggests that it puts the library in its own namespace but not its own address space.) Running each qemu as its own process and using interprocess communication for whatever coordination you need between the various instances seems more likely to be workable to me. This will also fix your "can't run more than one binary in succession" problem, because you can just have the first qemu run and exit as normal and launch a second qemu to run the second binary. -- PMM
[Qemu-devel] [PATCH] usb-hid: modifiers should generate an event
When a modifier key is pressed or released, the USB HID keyboard still
answers NAK, unless another key is also pressed or released.
The patch fixes that by calling usb_hid_changed() when a modifier key
is pressed or released.
Signed-off-by: Aurelien Jarno
---
hw/usb-hid.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/hw/usb-hid.c b/hw/usb-hid.c
index e8de301..12bf46f 100644
--- a/hw/usb-hid.c
+++ b/hw/usb-hid.c
@@ -460,15 +460,18 @@ static void usb_keyboard_event(void *opaque, int keycode)
case 0xe0:
if (s->modifiers & (1 << 9)) {
s->modifiers ^= 3 << 8;
+usb_hid_changed(hs);
return;
}
case 0xe1 ... 0xe7:
if (keycode & (1 << 7)) {
s->modifiers &= ~(1 << (hid_code & 0x0f));
+usb_hid_changed(hs);
return;
}
case 0xe8 ... 0xef:
s->modifiers |= 1 << (hid_code & 0x0f);
+usb_hid_changed(hs);
return;
}
--
1.7.2.3
Re: [Qemu-devel] [PATCH] USB keyboard emulation key mapping error - debian#578846
On Mon, Oct 18, 2010 at 04:55:25PM +0400, Michael Tokarev wrote:
> Brad Jorsch writes (
> http://bugs.debian.org/578846 ):
>
> The USB keyboard emulation's translation table in hw/usb-hid.c doesn't
> match the codes actually sent for the Logo (a.k.a. "Windows") or Menu
> keys. This results in the guest OS not being able to receive these keys
> at all when the USB keyboard emulation is being used.
>
> In particular, both the keymap in /usr/share/kvm/keymaps/modifiers and
> the evdev table in x_keymap.c map these keys to 0xdb, 0xdc, and 0xdd,
> while usb_hid_usage_keys[] seems to be expecting them to be mapped to
> 0x7d, 0x7e, and 0x7f.
>
> The attached patch seems to fix the problem, at least in my (limited)
> testing.
>
> This indeed fixes the problem, which is indeed exist.
>
> http://bugs.debian.org/578846
> http://bugs.debian.org/600593 (cloned from the above against different pkg)
> https://bugs.launchpad.net/qemu/+bug/584139
>
> Signed-Off-By: Brad Jorsch
> Signed-Off-By: Michael Tokarev
>
> diff --git a/hw/usb-hid.c b/hw/usb-hid.c
> --- a/hw/usb-hid.c
> +++ b/hw/usb-hid.c
> @@ -401,3 +401,3 @@ static const uint8_t usb_hid_usage_keys[0x100] = {
> 0x51, 0x4e, 0x49, 0x4c, 0x00, 0x00, 0x00, 0x00,
> -0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +0x00, 0x00, 0x00, 0xe3, 0xe7, 0x65, 0x00, 0x00,
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>
>
Thanks, applied.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
[Qemu-devel] [Bug 584139] Re: keymapping error for usb keyboard (windows/menu keys)
** Changed in: qemu Status: New => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/584139 Title: keymapping error for usb keyboard (windows/menu keys) Status in QEMU: Fix Committed Status in “qemu-kvm” package in Debian: Fix Released Bug description: The windows and menu keys for usb keyboard in qemu are wrong. They're correct for "ps/2" keyboard emulation however. See Debian bug#578846: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578846. Here's the proposed fix: --- a/hw/usb-hid.c +++ b/hw/usb-hid.c @@ -399,3 +399,3 @@ 0x51, 0x4e, 0x49, 0x4c, 0x00, 0x00, 0x00, 0x00, -0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, +0x00, 0x00, 0x00, 0xe3, 0xe7, 0x65, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
Re: [Qemu-devel] TCG flow vs dyngen
Thank you very much for Your fast reply! On 01/16/2011 07:29 PM, Peter Maydell wrote: Linux doesn't seem to have dlmopen http://www.unix.com/man-page/All/3c/dlmopen/ #define __USE_GNU #include lib_handle1 = dlmopen(LM_ID_NEWLM,"./libqemu-ppc.so", RTLD_NOW); I am developing that on a clean ubuntu 10.10 but google suggests that it puts the library in its own namespace but not its own address space. I need to make the different instances of qemu-user exchange data .. obviously keeping all of them in the same address space would be the easiest way (unless I have to change all qemu code ;) ) Running each qemu as its own process and using interprocess communication for whatever coordination you need between the various instances seems more likely to be workable to me. This will also fix your "can't run more than one binary in succession" problem, because you can just have the first qemu run and exit as normal and launch a second qemu to run the second binary. -- PMM Exactly, it was the easiest way also for me.. and I've already done it, works smoothly .. the only big problem is that it is not good for my teacher.. he says it should work the dynamic library way o.O Working with libraries even solved the problem of consecutive runs, though according to me it is not good a software when you must reboot it for making it run again fine.. sounds more Windows style :D Clearly it makes memory "dirty" and do not clean after the target process completes its execution.. leaving the OS care about it. I tried zeroing all global variables before starting a new execution without results (other than making it stall) .. After very long time spent trying to find a solution I think the problem should be with the mmap' ings stuff in the loader .. the same reason why 2 different libraries with their own namespaces clash according to me.. the elf loaders work globally within the unique address space .. I think for a guru of loaders-linkers should not be so difficult to patch it.. but not for a student who almost heard about them for the first time ;) Any help is very appreciated :) Thank you again! Stefano B.
Re: [Qemu-devel] TCG flow vs dyngen
2011/1/17 Stefano Bonifazi : > > Hi! > Thank you very much for Your concern! > Honestly I had lost hope in any help, I even contacted directly some > developers in this mailing list without luck! I guess many good developers in mailing list are still try their best to solve your problems, such as Blue Swirl, Paolo Bonzini, Stefan Weil, Peter Maydell, Mulyadi Santosa, Andreas Färber and Alexander Graf (hope I won't lost anyone that had helped you, and the order of name list without any meaning) ...etc., every developer has his expertises, and it is hard to recognize all of the activities of qemu. Please trust one thing: you are not alone:). > I am a student who needs to use qemu for a project where it will be used for > its capabilities of running PowerPC code. > As you can imagine qemu goes far beyond the knowledge in electronics and > computer science of a student. Nevertheless I have to do that! > I have been studying all the possible technical documents available in the > internet, but it is really not much at all , not sufficient for getting the > code and being able of understanding it .. It is in C, even not modular C++ Due to the lack of tehnical document of qemu and you are a student (maybe study for master/phd degree?), some literatures that published on IEEE/ACM may give you some inspiration and help (suppose that your university have bought the authority for download). As I know, though the issue of qemu is relative new for the academia, there still are literatures have been discussed. Maybe you can find which research domain categorized that is most approximative to your works. If any literature has inspired you or related to your research, don't hasitate to discuss. > Anyway with some help from this mailing list, and a lot of studying about > assembly, loaders, compilers.. I am going on, though there are still big > problems due of the nature of the QEMU code.. > First of all, I am starting from qemu-user, more specifically, qemu-ppc as I > don't need the full system capabilities, and it is easier for me to control > the binary target memory with qemu-user. Is there any reason why should you use the user mode of qemu, not the system mode? Sometime, the system mode of qemu will release you from the nightmare for managing the memory hierarchy. Maybe you can start from talking about what is the original goal of the project instead of falling into the hell of code tracing. > Originally I started with a lot of work on libqemu .. until some developer > here told me it was deprecated (though still in the source) and not working > fine. > I edited the code of qemu-ppc so that another function of mine calls > qemu-user main, with the appropriate parameters.. The pursued goal was to > launch it several times with different target binaries in succession.. > For some reason, I still can't find out, qemu code remembers the old code, > running it instead of the new loaded binary.. and if I flush the cache of > translated code before loading a new binary it stops and can't go on! > My workaround to this problem was compiling qemu-ppc as a dynamic library > and load it at runtime.. I also managed to load multiple copies of it (with > dlmopen each at a different address space) ..in fact I need to run more than > one qemu-ppc at the same time but a new big problem popped up now: the I need to thanks the Peter Maydell explained the principle that I'm not familiar with. And from your description, would you want to invoke multi-cores? Because I cannot imagine which application need to run multiple qemu-ppc at the same time. > target binary is loaded always at a fixed address.. no matter if another > qemu-ppc already loaded code there.. it is like the internal elf loader > can't understand those addresses are not available, and then relocate them > .. > I tried to link (ld) the binary target elf as position independent code, but > then qemu-ppc complains it can't find /usr/lib/libc.so.1 and > /usr/lib/ld.so.1 > The above description seems to be out of my scope to answer, because I only studied on system mode of qemu. > To sum up the problems are (in order of importance): > - making the elf loader relocate the target code into other addresses when > the default ones (I guess those embedded into the target binary when it is > not compiled as position independent code) are taken Maybe the problem only can be solved by re-write the loader if you insist to use user mode. (just as your response to Peter) > - making qemu-user able of running more than one target binary in > succession Will m"ore than one target binary in succession (assume A then B then C)" be achieved by "compile ABC into one binary in sequence"? > - counting qemu-user executed instructions I guess all the works before this are for the goal: "counting qemu-user executed instructions", am I right? If so, the paper published in IEEE 2010 maybe give some help (I guess) http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5475901 (Make
Re: [Qemu-devel] TCG flow vs dyngen
2011/1/16 Stefano Bonifazi : > I need to make the different instances of qemu-user exchange data .. > obviously keeping all of them in the same address space would be the easiest > way (unless I have to change all qemu code ;) ) The problem is that you're trying to break a fundamental assumption made by a lot of qemu code. That's a large job which involves understanding, checking and possibly changing lots of already written code. In contrast, the code you need to exchange data between the instances is going to be fairly small and self contained and you'll already understand it because you've written it/will write it. I think it's pretty clear which one is going to be easier. >> Running each qemu as its own >> process and using interprocess communication for whatever >> coordination you need between the various instances seems >> more likely to be workable to me. > Exactly, it was the easiest way also for me.. and I've already done it, > works smoothly .. the only big problem is that it is not good for my > teacher.. he says it should work the dynamic library way o.O I think he's wrong. (You might like to think about what happens if the program being emulated in qemu user-mode does a fork()). Basically you're trying to do things the hard way; maybe you can get something that sort of works in the subset of cases you care about, but why on earth put in that much time and effort on something irrelevant to the actual problem you're trying to work on? -- PMM
Re: [Qemu-devel] [PATCH v2] gdbstub: Close connection in gdb_exit
On Thu, Jan 13, 2011 at 12:46:57PM +0100, Fabien Chouteau wrote:
> On Windows, this is required to flush the remaining data in the IO stream,
> otherwise Gdb do not receive the last packet.
>
> Version 2:
>Fix linux-user build error.
Applied, thanks.
>
> Signed-off-by: Fabien Chouteau
> ---
> gdbstub.c |6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/gdbstub.c b/gdbstub.c
> index 0aa081b..d6556c9 100644
> --- a/gdbstub.c
> +++ b/gdbstub.c
> @@ -2391,6 +2391,12 @@ void gdb_exit(CPUState *env, int code)
>
>snprintf(buf, sizeof(buf), "W%02x", (uint8_t)code);
>put_packet(s, buf);
> +
> +#ifndef CONFIG_USER_ONLY
> + if (s->chr) {
> + qemu_chr_close(s->chr);
> + }
> +#endif
> }
>
> #ifdef CONFIG_USER_ONLY
> --
> 1.7.1
>
>
Re: [Qemu-devel] TCG flow vs dyngen
Hi! In case you are interested in helping me, I'll give you a big piece of news I've just got (even my teacher is not informed yet! :) ) I've just managed to make more than one instance of qemu-user run at the same time linking the target code with a specified address for the code section (-Ttext address of ld). It works fine and this proves my idea that the problem is within the elf loader.. Making it relocate the target code properly would fix the problem ;) Now let's work on it :) Regards, Stefano B. On 01/16/2011 08:02 PM, Stefano Bonifazi wrote: Thank you very much for Your fast reply! On 01/16/2011 07:29 PM, Peter Maydell wrote: Linux doesn't seem to have dlmopen http://www.unix.com/man-page/All/3c/dlmopen/ #define __USE_GNU #include lib_handle1 = dlmopen(LM_ID_NEWLM,"./libqemu-ppc.so", RTLD_NOW); I am developing that on a clean ubuntu 10.10 but google suggests that it puts the library in its own namespace but not its own address space. I need to make the different instances of qemu-user exchange data .. obviously keeping all of them in the same address space would be the easiest way (unless I have to change all qemu code ;) ) Running each qemu as its own process and using interprocess communication for whatever coordination you need between the various instances seems more likely to be workable to me. This will also fix your "can't run more than one binary in succession" problem, because you can just have the first qemu run and exit as normal and launch a second qemu to run the second binary. -- PMM Exactly, it was the easiest way also for me.. and I've already done it, works smoothly .. the only big problem is that it is not good for my teacher.. he says it should work the dynamic library way o.O Working with libraries even solved the problem of consecutive runs, though according to me it is not good a software when you must reboot it for making it run again fine.. sounds more Windows style :D Clearly it makes memory "dirty" and do not clean after the target process completes its execution.. leaving the OS care about it. I tried zeroing all global variables before starting a new execution without results (other than making it stall) .. After very long time spent trying to find a solution I think the problem should be with the mmap' ings stuff in the loader .. the same reason why 2 different libraries with their own namespaces clash according to me.. the elf loaders work globally within the unique address space .. I think for a guru of loaders-linkers should not be so difficult to patch it.. but not for a student who almost heard about them for the first time ;) Any help is very appreciated :) Thank you again! Stefano B.
Re: [Qemu-devel] TCG flow vs dyngen
2011/1/17 Stefano Bonifazi : > Hi! > In case you are interested in helping me, I'll give you a big piece of news > I've just got (even my teacher is not informed yet! :) ) > I've just managed to make more than one instance of qemu-user run at the > same time linking the target code with a specified address for the code > section (-Ttext address of ld). > It works fine and this proves my idea that the problem is within the elf > loader.. > Making it relocate the target code properly would fix the problem ;) > Now let's work on it :) > Regards, > Stefano B. > Congratulation~ just keep going on~! Raphaël Lefèvre
Re: [Qemu-devel] [PATCH] m48t59: Fix a wrong opaque passed to nvram read and write routines
On Sun, Jan 02, 2011 at 07:44:49PM +0100, Hervé Poussineau wrote:
> This unregresses Sun4m and PPC prep/ref405ep machines
>
> Signed-off-by: Hervé Poussineau
> ---
> hw/m48t59.c | 11 ++-
> 1 files changed, 6 insertions(+), 5 deletions(-)
Thanks, applied.
> diff --git a/hw/m48t59.c b/hw/m48t59.c
> index 6991e2e..2020487 100644
> --- a/hw/m48t59.c
> +++ b/hw/m48t59.c
> @@ -642,6 +642,7 @@ M48t59State *m48t59_init(qemu_irq IRQ, target_phys_addr_t
> mem_base,
> DeviceState *dev;
> SysBusDevice *s;
> M48t59SysBusState *d;
> +M48t59State *state;
>
> dev = qdev_create(NULL, "m48t59");
> qdev_prop_set_uint32(dev, "type", type);
> @@ -649,18 +650,18 @@ M48t59State *m48t59_init(qemu_irq IRQ,
> target_phys_addr_t mem_base,
> qdev_prop_set_uint32(dev, "io_base", io_base);
> qdev_init_nofail(dev);
> s = sysbus_from_qdev(dev);
> +d = FROM_SYSBUS(M48t59SysBusState, s);
> +state = &d->state;
> sysbus_connect_irq(s, 0, IRQ);
> if (io_base != 0) {
> -register_ioport_read(io_base, 0x04, 1, NVRAM_readb, s);
> -register_ioport_write(io_base, 0x04, 1, NVRAM_writeb, s);
> +register_ioport_read(io_base, 0x04, 1, NVRAM_readb, state);
> +register_ioport_write(io_base, 0x04, 1, NVRAM_writeb, state);
> }
> if (mem_base != 0) {
> sysbus_mmio_map(s, 0, mem_base);
> }
>
> -d = FROM_SYSBUS(M48t59SysBusState, s);
> -
> -return &d->state;
> +return state;
> }
>
> M48t59State *m48t59_init_isa(uint32_t io_base, uint16_t size, int type)
> --
> 1.7.2.3
>
>
>
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH, RFC 3/4] prep: Fix duplicate ISA IDE IRQ
On Tue, Dec 14, 2010 at 01:49:17AM +0100, Andreas Färber wrote: > Calling isa_ide_init() twice with the same IRQ 13 fails: > > qemu: hardware error: isa irq 13 already assigned > > Use a different IRQ (14) for the second one to avoid this. I am not sure it is actually a good idea. While it fixes the QEMU error, it breaks the kernel boot which waits for both IDE channels on IRQ 13. This causes an endless boot, so the machine never finishes to boot: | ide0 at 0x1f0-0x1f7,0x3f6 on irq 13 | ide1 at 0x170-0x177,0x376 on irq 13 (shared with ide0) | hda: max request size: 512KiB | hda: 20971520 sectors (10737 MB) w/256KiB Cache, CHS=16383/255/63 | hda: cache flushes supported | hda: hda1 hda2 | ide-cd: cmd 0x5a timed out | hdc: lost interrupt | ide-cd: cmd 0x5a timed out | hdc: lost interrupt | hdc: ATAPI 4X CD-ROM drive, 512kB Cache | Uniform CD-ROM driver Revision: 3.20 | hdc: lost interrupt | ide-cd: cmd 0x3 timed out | hdc: lost interrupt | ide-cd: cmd 0x3 timed out | hdc: lost interrupt | hdc: lost interrupt | ... As a temporary workaround it seems better to disable the second IDE channel, this solution works. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] RFC: mass comment conversion from C99 to C89
On 15 January 2011 16:02, Blue Swirl wrote: > With the sed script below (my first I think), I'm able to convert most > files in QEMU from C99 comment style to C89. When successive line with > C99 comments are converted, the comments are merged. Two files > (hw/rtl8139.c and microblaze-dis.c) still fail. > > Is this a good idea? I'm a bit wary of this kind of wide-scale no-semantic-change commit (and more so for things like indent, brace and whitespace fixes which can affect large chunks of actual code), because it makes it harder to deal with qemu forks (especially if you were hoping to be able to periodically rebase with an eye to eventually getting changes back into mainline qemu). This particular changeset doesn't touch target-arm so it doesn't affect me personally, though. -- PMM
[Qemu-devel] Re: [PATCH uq/master 2/2] MCE, unpoison memory address across reboot
On Fri, 2011-01-14 at 16:38 +0800, Jan Kiszka wrote: > Am 14.01.2011 02:51, Huang Ying wrote: > > On Thu, 2011-01-13 at 17:01 +0800, Jan Kiszka wrote: > >> Am 13.01.2011 09:34, Huang Ying wrote: [snip] > >>> + > >>> +void kvm_unpoison_all(void *param) > >> > >> Minor nit: This can be static now. > > > > In uq/master, it can be make static. But in kvm/master, kvm_arch_init > > is not compiled because of conditional compiling, so we will get warning > > and error for unused symbol. Should we consider kvm/master in this > > patch? > > qemu-kvm is very close to switching to upstream kvm_*init. As long as it > requires this service in its own modules, it will have to patch this > detail. It does this for other functions already. OK. I will change this. [snip] > >> As indicated, I'm sitting on lots of fixes and refactorings of the MCE > >> user space code. How do you test your patches? Any suggestions how to do > >> this efficiently would be warmly welcome. > > > > We use a self-made test script to test. Repository is at: > > > > git://git.kernel.org/pub/scm/utils/cpu/mce/mce-test.git > > > > The kvm test script is in kvm sub-directory. > > > > The qemu patch attached is need by the test script. > > > > Yeah, I already found this yesterday and started reading. I was just > searching for p2v in qemu, but now it's clear where it comes from. Will > have a look (if you want to preview my changes: > git://git.kiszka.org/qemu-kvm.git queues/kvm-upstream). > > I was almost about to use MADV_HWPOISON instead of the injection module. > Is there a way to recover the fake corruption afterward? I think that > would allow to move some of the test logic into qemu and avoid p2v which > - IIRC - was disliked upstream. I don't know how to fully recover from MADV_HWPOISON. You can recover the virtual address space via qemu_ram_remap() introduced in 1/2 of this patchset. But you will lose one or several physical pages for each testing. I think that may be not a big issue for a testing machine. Ccing Andi and Fengguang, they know more than me about MADV_HWPOISON. > Also, is there a way to simulate corrected errors (BUS_MCEERR_AO)? BUS_MCEERR_AO is recoverable uncorrected error instead of corrected error. The test script is for BUS_MCEERR_AO and BUS_MCEERR_AR. To see the effect of pure BUS_MCEERR_AO, just remove the memory accessing loop (memset) in tools/simple_process/simple_process.c. Best Regards, Huang Ying
[Qemu-devel] Re: [PATCH v2 3/3] checkpatch: adjust to QEMUisms
On 01/15/2011 06:45 PM, Blue Swirl wrote:
+ if ($level == 0 && !$block =~ /^\s*\{/ && !$allowed) {
I'm not a Perl expert at all, but I think you need parentheses for the
argument of "!":
if ($level == 0 && !($block =~ /^\s*\{/) && !$allowed) {
Paolo
Re: [Qemu-devel] paravirtual mouse/tablet
There are three cases: (1) no pressure supported (i.e. your mouse moving around in the vnc window and qemu reporting this as tablet coordinates). (2) just pen/finger present/not present supported. pressure jumps between 0 and max (and we can make max == 1 in that case). Phew - that's one of the bits where touchpads and tablets behave differently IIUC. For touchpads, pressing means movement happens. For tablets, pressing means an actual press, as if you would press your pencil on a sheet of paper. So for tablets, pressure==1 basically means click. I wouldn't make a difference from the virtual hardware perspective. If something touches the pad/tablet surface we'll report the position where it happened (and the pressure if supported). Whenever this is interpreted as click or not is up to the guest. Now the thing is that multitouch gestures might take non-click pressure into account for their calculations. So we need pressure for movements on touchpads, but with tablets, we only need pressure when clicks happen. For everyone else, clicks would just be a button press. -EPARSE. What is "non-click pressure" ? cheers, Gerd
