[Qemu-devel] [Bug 921208] Re: win7/x64 installer hangs on startup with 0x0000005d.
Michael, this bug cannot be solved with a reconfiguration, it's actually a TCG emulation bug. There is an experimental patch on the QEMU mailing list you should have a look at -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/921208 Title: win7/x64 installer hangs on startup with 0x005d. Status in QEMU: Confirmed Status in “qemu” package in Ubuntu: Triaged Bug description: hi, during booting win7/x64 installer i'm observing a bsod with 0x005d ( msdn: unsupported_processor ). used command line: qemu-system-x86_64 -m 2048 -hda w7-system.img -cdrom win7_x64.iso -boot d adding '-machine accel=kvm' instead of default tcg accel helps to boot. installed software: qemu-1.0 linux-3.2.1 glibc-2.14.1 gcc-4.6.2 hw cpu: processor : 0..7 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz stepping: 7 microcode : 0x14 cpu MHz : 1995.739 cache size : 6144 KB physical id : 0 siblings: 8 core id : 3 cpu cores : 4 apicid : 7 initial apicid : 7 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid bogomips: 3992.23 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/921208/+subscriptions
Re: [Qemu-devel] TCG x86-64 'bt' insn
Hi Peter, sure, that's fine too :). I just meant great that it will be picked up in a future version :) Thanks! -Clemens On Sat, Apr 19, 2014 at 3:50 PM, Peter Maydell peter.mayd...@linaro.orgwrote: On 19 April 2014 23:41, Clemens Kolbitsch kolbit...@lastline.com wrote: Thanks guys, awesome feedback and glad to see it was picked up in QEMU 2.0 :) This didn't go into 2.0 -- it arrived somewhat late for that. It'll get into 2.1 (and perhaps 2.0.1, if anybody cares enough to cc stable on it). thanks -- PMM
Re: [Qemu-devel] [PATCH] target-i386: Preserve the Z bit for bt/bts/btr/btc
Great, thanks for the feedback and the fix Richard!
On Wed, Apr 9, 2014 at 1:56 PM, Richard Henderson r...@twiddle.net wrote:
Older Intel manuals (pre-2010) describe Z as undefined, but AMD and
newer Intel manuals describe Z as unchanged.
Signed-off-by: Richard Henderson r...@twiddle.net
---
target-i386/translate.c | 40 +++-
1 file changed, 31 insertions(+), 9 deletions(-)
---
Clemens, your patch fails to fix flags computation for bts/btr/btc,
which should be done similarly to bt.
And to answer your question, no, QEMU does not make any assumptions
about undefined flags. We often set them to zero, just because that
is easier than any other setting.
r~
diff --git a/target-i386/translate.c b/target-i386/translate.c
index 02625e3..032b0fd 100644
--- a/target-i386/translate.c
+++ b/target-i386/translate.c
@@ -6708,41 +6708,63 @@ static target_ulong disas_insn(CPUX86State *env,
DisasContext *s,
}
bt_op:
tcg_gen_andi_tl(cpu_T[1], cpu_T[1], (1 (3 + ot)) - 1);
+tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]);
switch(op) {
case 0:
-tcg_gen_shr_tl(cpu_cc_src, cpu_T[0], cpu_T[1]);
-tcg_gen_movi_tl(cpu_cc_dst, 0);
break;
case 1:
-tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]);
tcg_gen_movi_tl(cpu_tmp0, 1);
tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]);
tcg_gen_or_tl(cpu_T[0], cpu_T[0], cpu_tmp0);
break;
case 2:
-tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]);
tcg_gen_movi_tl(cpu_tmp0, 1);
tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]);
-tcg_gen_not_tl(cpu_tmp0, cpu_tmp0);
-tcg_gen_and_tl(cpu_T[0], cpu_T[0], cpu_tmp0);
+tcg_gen_andc_tl(cpu_T[0], cpu_T[0], cpu_tmp0);
break;
default:
case 3:
-tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]);
tcg_gen_movi_tl(cpu_tmp0, 1);
tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]);
tcg_gen_xor_tl(cpu_T[0], cpu_T[0], cpu_tmp0);
break;
}
-set_cc_op(s, CC_OP_SARB + ot);
if (op != 0) {
if (mod != 3) {
gen_op_st_v(s, ot, cpu_T[0], cpu_A0);
} else {
gen_op_mov_reg_v(ot, rm, cpu_T[0]);
}
+}
+
+/* Delay all CC updates until after the store above. Note that
+ C is the result of the test, Z is unchanged, and the others
+ are all undefined. */
+switch (s-cc_op) {
+case CC_OP_MULB ... CC_OP_MULQ:
+case CC_OP_ADDB ... CC_OP_ADDQ:
+case CC_OP_ADCB ... CC_OP_ADCQ:
+case CC_OP_SUBB ... CC_OP_SUBQ:
+case CC_OP_SBBB ... CC_OP_SBBQ:
+case CC_OP_LOGICB ... CC_OP_LOGICQ:
+case CC_OP_INCB ... CC_OP_INCQ:
+case CC_OP_DECB ... CC_OP_DECQ:
+case CC_OP_SHLB ... CC_OP_SHLQ:
+case CC_OP_SARB ... CC_OP_SARQ:
+case CC_OP_BMILGB ... CC_OP_BMILGQ:
+/* Z was going to be computed from the non-zero status of
CC_DST.
+ We can get that same Z value (and the new C value) by
leaving
+ CC_DST alone, setting CC_SRC, and using a CC_OP_SAR of the
+ same width. */
tcg_gen_mov_tl(cpu_cc_src, cpu_tmp4);
-tcg_gen_movi_tl(cpu_cc_dst, 0);
+set_cc_op(s, ((s-cc_op - CC_OP_MULB) 3) + CC_OP_SARB);
+break;
+default:
+/* Otherwise, generate EFLAGS and replace the C bit. */
+gen_compute_eflags(s);
+tcg_gen_deposit_tl(cpu_cc_src, cpu_cc_src, cpu_tmp4,
+ ctz32(CC_C), 1);
+break;
}
break;
case 0x1bc: /* bsf / tzcnt */
--
1.9.0
--
Clemens Kolbitsch
Security Researcher
kolbit...@lastline.com
Mobile +1 (206) 356-7745
Land +1 (805) 456-7076
Lastline, Inc.
6950 Hollister Avenue, Suite 101
Goleta, CA 93117
www.lastline.com
Re: [Qemu-devel] TCG x86-64 'bt' insn
Thanks guys, awesome feedback and glad to see it was picked up in QEMU 2.0 :) On Sat, Apr 19, 2014 at 3:21 PM, Peter Maydell peter.mayd...@linaro.orgwrote: On 19 April 2014 23:04, Paolo Bonzini pbonz...@redhat.com wrote: The new code should apply to btc/btr/bts too. ...see also RTH's patch: https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg01455.html thanks -- PMM -- Clemens Kolbitsch Security Researcher kolbit...@lastline.com Mobile +1 (206) 356-7745 Land +1 (805) 456-7076 Lastline, Inc. 6950 Hollister Avenue, Suite 101 Goleta, CA 93117 www.lastline.com
[Qemu-devel] TCG x86-64 'bt' insn
Hi guys,
I have to revive a rather old thread [1,2]. A quick summary of the issue:
TCG emulates the BT (bit-test) instruction using a SAR to re-compute
eflags. While SAR affects all flags, BT only affects the C-flag and leaves
the Z-flag unaffected/unchanged [3].
According to the x86 manual, the current behavior is correct (although not
perfect performance-wise), but NOT correct according to newer Intel CPU
instruction sets (such as x86-64). What has caused some confusion in the
past it seems is that AMD's manual mentions that all flags other than the
C-flag are undefined (just like in Intel's old x86 manual).
A patch has been suggested (although not applied) before [2] and I was
trying to update and try the patch to the QEMU 2.0 RC2, but it seems not to
be working (causes a BSOD on Windows guests).
BTW: I have a program that seg-faults on Windows clients (32 as well as 64
bit guest OSes) in vanilla QEMU 2.0 RC2 (just like in previous versions),
so this is not just of theoretical importance :)
Can somebody say if there is something that I'm doing obviously wrong?
*NON-FUNCTIONAL PATCH!*
--- ../orig/qemu-2.0.0-rc2/target-i386/translate.c 2014-04-08
12:38:58.0 -0700
+++ target-i386/translate.c 2014-04-09 10:08:43.252084947 -0700
@@ -6710,8 +6710,14 @@
tcg_gen_andi_tl(cpu_T[1], cpu_T[1], (1 (3 + ot)) - 1);
switch(op) {
case 0:
-tcg_gen_shr_tl(cpu_cc_src, cpu_T[0], cpu_T[1]);
-tcg_gen_movi_tl(cpu_cc_dst, 0);
+/* whatever the last CC-op is - recompute now so we can OR-in
+ * updated results */
+gen_update_cc_op(s);
+gen_compute_eflags(s);
+tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]);
+tcg_gen_andi_tl(cpu_tmp4, cpu_tmp4, CC_C);
+tcg_gen_or_tl(cpu_cc_src, cpu_cc_src, cpu_tmp4);
+set_cc_op(s, CC_OP_EFLAGS);
break;
case 1:
tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]);
@@ -6734,8 +6740,8 @@
tcg_gen_xor_tl(cpu_T[0], cpu_T[0], cpu_tmp0);
break;
}
-set_cc_op(s, CC_OP_SARB + ot);
if (op != 0) {
+set_cc_op(s, CC_OP_SARB + ot);
if (mod != 3) {
gen_op_st_v(s, ot, cpu_T[0], cpu_A0);
} else {
Thanks, I'd really appreciate any input you can provide.
-Clemens
[1] http://lists.gnu.org/archive/html/qemu-devel/2010-11/msg00442.html
[2] http://lists.gnu.org/archive/html/qemu-devel/2010-11/msg00764.html
[3] page 148
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf
--
Clemens Kolbitsch
Security Researcher
kolbit...@lastline.com
Mobile +1 (206) 356-7745
Land +1 (805) 456-7076
Lastline, Inc.
6950 Hollister Avenue, Suite 101
Goleta, CA 93117
www.lastline.com
Re: [Qemu-devel] TCG x86-64 'bt' insn
Hi,
quick follow-up. *As always* you find a problem right after asking for help
:). The updated patch does not cause BSOD on Windows guests, but neither
does it fix the actual problem (of the program seg-faulting)
I would really appreciate any feedback on the proposed patch below - the
difference to the previous patch is that we clear out undefined flags and
only keep the Z-flag (and update the C-flag)
--- ../orig/qemu-2.0.0-rc2/target-i386/translate.c 2014-04-08
12:38:58.0 -0700
+++ target-i386/translate.c 2014-04-09 10:48:25.264200230 -0700
@@ -6710,8 +6710,15 @@
tcg_gen_andi_tl(cpu_T[1], cpu_T[1], (1 (3 + ot)) - 1);
switch(op) {
case 0:
-tcg_gen_shr_tl(cpu_cc_src, cpu_T[0], cpu_T[1]);
-tcg_gen_movi_tl(cpu_cc_dst, 0);
+/* whatever the last CC-op is - recompute now so we can OR-in
+ * updated results */
+gen_update_cc_op(s); // ? needed ?
+gen_compute_eflags(s);
+tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]);
+tcg_gen_andi_tl(cpu_tmp4, cpu_tmp4, CC_C);
+tcg_gen_andi_tl(cpu_cc_src, cpu_cc_src, CC_Z);
+tcg_gen_or_tl(cpu_cc_src, cpu_cc_src, cpu_tmp4);
+set_cc_op(s, CC_OP_EFLAGS);
break;
case 1:
tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]);
@@ -6734,8 +6741,8 @@
tcg_gen_xor_tl(cpu_T[0], cpu_T[0], cpu_tmp0);
break;
}
-set_cc_op(s, CC_OP_SARB + ot);
if (op != 0) {
+set_cc_op(s, CC_OP_SARB + ot);
if (mod != 3) {
gen_op_st_v(s, ot, cpu_T[0], cpu_A0);
} else {
Last another general question: Does TCG make any assumptions that undefined
flags are set to 0? I see that most flag-computations set undefined flags
to 0 - is this just a convention or really a requirement?
Thanks guys!
-Clemens
On Wed, Apr 9, 2014 at 10:33 AM, Clemens Kolbitsch
kolbit...@lastline.comwrote:
Hi guys,
I have to revive a rather old thread [1,2]. A quick summary of the issue:
TCG emulates the BT (bit-test) instruction using a SAR to re-compute
eflags. While SAR affects all flags, BT only affects the C-flag and leaves
the Z-flag unaffected/unchanged [3].
According to the x86 manual, the current behavior is correct (although not
perfect performance-wise), but NOT correct according to newer Intel CPU
instruction sets (such as x86-64). What has caused some confusion in the
past it seems is that AMD's manual mentions that all flags other than the
C-flag are undefined (just like in Intel's old x86 manual).
A patch has been suggested (although not applied) before [2] and I was
trying to update and try the patch to the QEMU 2.0 RC2, but it seems not to
be working (causes a BSOD on Windows guests).
BTW: I have a program that seg-faults on Windows clients (32 as well as 64
bit guest OSes) in vanilla QEMU 2.0 RC2 (just like in previous versions),
so this is not just of theoretical importance :)
Can somebody say if there is something that I'm doing obviously wrong?
*NON-FUNCTIONAL PATCH!*
--- ../orig/qemu-2.0.0-rc2/target-i386/translate.c 2014-04-08
12:38:58.0 -0700
+++ target-i386/translate.c 2014-04-09 10:08:43.252084947 -0700
@@ -6710,8 +6710,14 @@
tcg_gen_andi_tl(cpu_T[1], cpu_T[1], (1 (3 + ot)) - 1);
switch(op) {
case 0:
-tcg_gen_shr_tl(cpu_cc_src, cpu_T[0], cpu_T[1]);
-tcg_gen_movi_tl(cpu_cc_dst, 0);
+/* whatever the last CC-op is - recompute now so we can OR-in
+ * updated results */
+gen_update_cc_op(s);
+gen_compute_eflags(s);
+tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]);
+tcg_gen_andi_tl(cpu_tmp4, cpu_tmp4, CC_C);
+tcg_gen_or_tl(cpu_cc_src, cpu_cc_src, cpu_tmp4);
+set_cc_op(s, CC_OP_EFLAGS);
break;
case 1:
tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]);
@@ -6734,8 +6740,8 @@
tcg_gen_xor_tl(cpu_T[0], cpu_T[0], cpu_tmp0);
break;
}
-set_cc_op(s, CC_OP_SARB + ot);
if (op != 0) {
+set_cc_op(s, CC_OP_SARB + ot);
if (mod != 3) {
gen_op_st_v(s, ot, cpu_T[0], cpu_A0);
} else {
Thanks, I'd really appreciate any input you can provide.
-Clemens
[1] http://lists.gnu.org/archive/html/qemu-devel/2010-11/msg00442.html
[2] http://lists.gnu.org/archive/html/qemu-devel/2010-11/msg00764.html
[3] page 148
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf
[Qemu-devel] Self-modifying code with REP-prefix on TCG
Hi guys, a quick search on the archives did not reveal anything - if this is already a known issue, please don't kick me ;) We encountered an issue using TCG, where self-modifying code is overwriting the executing instruction, causing different behavior in TCG and a real CPU. Clearly, when code is overwriting itself, the QEMU logic will detect and invalidate the TB - and one would assume this is the correct behavior. However, when the current instruction has a REP-prefix, this should cause the ORIGINAL instruction to execute, and NOT generate an exception. Since TCG uses a loop, however, a repeated invocation of the REP'ed instruction will cause an exception, TCG retranslates the TB, and QEMU will execute the new code. For example: seg000:0039083D loc_39083D:. seg000:0039083D E8 00 00 00 00 call$+5 seg000:00390842 59 pop ecx seg000:00390843 8D BB 00 10 40 00lea edi, (loc_39 - 0FFF8F000h)[ebx] seg000:00390849 29 F9sub ecx, edi seg000:0039084B 83 C1 10 add ecx, 10h seg000:0039084E 30 C0xor al, al seg000:00390850 FC cld ; here ECX = 0x852 and EDI = 0x39 ; so at the step 0x851 the instruction rewrites itself ; but EIP stays the same = 0x00390851 ; and instruction becomes invalid ; seg000:00390851 00 AA.. ; when QEMU tries to regenerate TB ; the generated instruction throws an exception seg000:00390851 F3 AArep stosb seg000:00390853 56 pushesi seg000:00390854 C3 retn On a real CPU, the instruction becomes invalid when overwritten, but the CPU continues execution without raising an exception (because it's already been loaded into the execution registers). Getting around this is not trivial, so if it's a new issue, does anyone have an idea how to approach it most meaningfully? I was thinking about detecting this very specific case and marking the TB for re-translation only after the TB is exited, but this is not very clean and also somewhat prone to errors. Thanks! -Clemens -- Clemens Kolbitsch Security Researcher kolbit...@lastline.com Mobile +1 (206) 356-7745 Land +1 (805) 456-7076 Lastline, Inc. 6950 Hollister Avenue, Suite 101 Goleta, CA 93117 www.lastline.com
Re: [Qemu-devel] FPU x86 instructions error
On Sun, May 26, 2013 at 7:54 AM, Andreas Färber afaer...@suse.de wrote: Hi, Am 24.05.2013 23:44, schrieb Paolo Bonzini: Il 24/05/2013 23:39, Clemens Kolbitsch ha scritto: we recently had an issue with running a program using FPU instructions to obtain the current EIP (basically a weird way of call 0; pop eax) that was not working on QEMU (with TCG). Looking at the problem, we found this patch to be useful/fixing the issue: https://launchpadlibrarian.net/140457932/patch-qemu-1.5.0-fpip.diff Looking through the DEVEL archives, I found this patch http://lists.nongnu.org/archive/html/qemu-devel/2011-06/msg01206.html that adds the FPU flags to the environment, but is only using them for KVM. I was wondering - since the above patch is rather old, you have probably come across it before - if there was a reason for not including it in QEMU (I checked in git:master and it's not applied). If there isn't, maybe it'd be worth re-considering :) For the TCG patch, there is no Signed-off-by and using a helper is not necessary. Clemens, generally we can't just take another person's patch and apply it - that's what we need the Signed-off-by for. Your post is the only Google hit for that link and no hits for fpip in my archive - you'll need to contact the author to obtain her Sob and properly submit it to qemu-devel - or post a patch yourself that is not based on that one. Andreas, thanks for that info - that makes it much clearer. Since the patch is rather short, it will be difficult, but we can give it a shot :) http://wiki.qemu.org/Contribute/SubmitAPatch For the KVM patch, it simply fell through the cracks, I believe. It didn't: http://git.qemu.org/?p=qemu.git;a=commit;h=42cc8fa620cbc73e349e96d84cf46469e828ec34 (I was about to suggest placing the non-TCG fields into X86CPU. :)) Yes, I think that was a misunderstanding. I was trying to say that for first one didn't get picked up and the second one is just a prerequisite -- not that it was missing as well :) thanks! -Clemens
[Qemu-devel] FPU x86 instructions error
Hi guys, we recently had an issue with running a program using FPU instructions to obtain the current EIP (basically a weird way of call 0; pop eax) that was not working on QEMU (with TCG). Looking at the problem, we found this patch to be useful/fixing the issue: https://launchpadlibrarian.net/140457932/patch-qemu-1.5.0-fpip.diff Looking through the DEVEL archives, I found this patch http://lists.nongnu.org/archive/html/qemu-devel/2011-06/msg01206.html that adds the FPU flags to the environment, but is only using them for KVM. I was wondering - since the above patch is rather old, you have probably come across it before - if there was a reason for not including it in QEMU (I checked in git:master and it's not applied). If there isn't, maybe it'd be worth re-considering :) thanks! -Clemens -- Clemens Kolbitsch Security Researcher kolbit...@lastline.com Lastline, Inc. 6950 Hollister Avenue, Suite 101 Goleta, CA 93117 www.lastline.com
Re: [Qemu-devel] Disabling KVM on the fly
On Thu, Oct 18, 2012 at 10:24 AM, Jan Kiszka jan.kis...@siemens.com wrote: On 2012-10-18 08:29, Paolo Bonzini wrote: Il 17/10/2012 20:37, Jan Kiszka ha scritto: On 2012-10-17 18:44, Paolo Bonzini wrote: Il 17/10/2012 18:37, Clemens Kolbitsch ha scritto: Guys, I know this is question might seem a bit odd, but I'm curious: Has anyone ever tried to write code to disable KVM on the fly / is it at all possible? I have a situation where I need to use TCG for certain parts of the code, but would love to have acceleration for everything else. My idea was to pause the VM, then use the snapshotting mechanism to dump the state, and then to resume the snapshot, but writing the KVM state into the non-KVM structures. As a start, you can try using migrate exec:catfoo.save with a KVM machine and -incoming 'exec:cat foo.save' with a TCG machine. The main problem should be that TCG doesn't implement kvmclock. If you disable the KVM interrupt controller and timer (which is just an implementation detail, not a hardware difference), Unnecessary. Both models (KVM in-kernel and QEMU userspace) are compatible - in the absence of bugs. He wants to really switch it on the fly---not just migrate out and in---and for that you need to disable the KVM-specific devices. Well, that's even more unrealistic than via migration. I am just looking for a way to do it, regardless whether it causes a big performance penalty due to migration, etc. Even if this means preparing a special environment (emulating specific hardware, etc), this is fine with me. Thanks a lot for all the feedback, now I know what I will have to look into! -Clemens
[Qemu-devel] Disabling KVM on the fly
Guys, I know this is question might seem a bit odd, but I'm curious: Has anyone ever tried to write code to disable KVM on the fly / is it at all possible? I have a situation where I need to use TCG for certain parts of the code, but would love to have acceleration for everything else. My idea was to pause the VM, then use the snapshotting mechanism to dump the state, and then to resume the snapshot, but writing the KVM state into the non-KVM structures. I know nothing of that sort is implemented at this point. Leaving aside the issue of certain CPUID instructions suddenly returning different results, are there obvious problems even trying to go down that road? Would love to hear some thoughts on this - don't hesitate to tell me that's stupid and impossible because XYZ (assuming you also fill in the blanks ;) ) Thanks! Clemens -- Clemens Kolbitsch Security Researcher kolbit...@lastline.com +1 (206) 356-7745 Lastline, Inc. 6950 Hollister Avenue, Suite 101 Goleta, CA 93117 www.lastline.com
[Qemu-devel] [Bug 921208] Re: win7/x64 installer hangs on startup with 0x0000005d.
Hi Rolando, thanks for this detailed report. Since you mention that Windows7 runs fine for you, you gotten me really curious. Could you please post the exact command line you are using (e.g., what additional hardware you are emulating, etc.), the build version, the host system, etc. I'm pretty sure that the BSOD occurs in some specific (but default) Windows driver, because I can boot and run Win7 without problems in safe-mode (where this specific module/driver might not be loaded or executed). BTW, I'm emulating a 64bit Windows, same for you? Further, I have actually traced the execution of Win7 to a point where I even see WHY a BSOD occurs. The code executes a BOUND instruction that is i386-only, so not available in 64bit mode. A wild guess would be that this happens because some CPU-ID instruction returned an invalid bit at some point causing windows to install an invalid driver or go down a wrong path. A last question: I assume you installed Windows with KVM, right? Because 1) without it it's just too painfully slow :) and 2) the installer crashes for me without KVM. Thanks! -Clemens -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/921208 Title: win7/x64 installer hangs on startup with 0x005d. Status in QEMU: Confirmed Bug description: hi, during booting win7/x64 installer i'm observing a bsod with 0x005d ( msdn: unsupported_processor ). used command line: qemu-system-x86_64 -m 2048 -hda w7-system.img -cdrom win7_x64.iso -boot d adding '-machine accel=kvm' instead of default tcg accel helps to boot. installed software: qemu-1.0 linux-3.2.1 glibc-2.14.1 gcc-4.6.2 hw cpu: processor : 0..7 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz stepping: 7 microcode : 0x14 cpu MHz : 1995.739 cache size : 6144 KB physical id : 0 siblings: 8 core id : 3 cpu cores : 4 apicid : 7 initial apicid : 7 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid bogomips: 3992.23 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/921208/+subscriptions
[Qemu-devel] [Bug 921208] Re: win7/x64 installer hangs on startup with 0x0000005d.
We have been discussing this issue on the QEMU mailing list. It is of CPU definition, but none of the current configurations allow QEMU to boot Windows7 64bit WITHOUT KVM. The issue behind it is that the TCG (code generator) might not fully support all CPU bits required by Win7. There is a patch to bypass this problem, but the OS still does not boot reliably (BSODs occur after a few minutes). Note that it works with KVM enabled -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/921208 Title: win7/x64 installer hangs on startup with 0x005d. Status in QEMU: Confirmed Bug description: hi, during booting win7/x64 installer i'm observing a bsod with 0x005d ( msdn: unsupported_processor ). used command line: qemu-system-x86_64 -m 2048 -hda w7-system.img -cdrom win7_x64.iso -boot d adding '-machine accel=kvm' instead of default tcg accel helps to boot. installed software: qemu-1.0 linux-3.2.1 glibc-2.14.1 gcc-4.6.2 hw cpu: processor : 0..7 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz stepping: 7 microcode : 0x14 cpu MHz : 1995.739 cache size : 6144 KB physical id : 0 siblings: 8 core id : 3 cpu cores : 4 apicid : 7 initial apicid : 7 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid bogomips: 3992.23 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/921208/+subscriptions
Re: [Qemu-devel] QEMU (no kvm) Win7 (64bit) boot error [PATCH 1/1]
Brendan,
I was also getting the same BSOD error codes. I was very busy with
other stuff recently, so I pretty much didn't get any further than
what I said in my last mail. But I'm more than happy helping out if
you need anything debugging this. Just let me know
-Clemens
On Thu, Sep 27, 2012 at 4:55 PM, Brendan Dolan-Gavitt
brenda...@gatech.edu wrote:
I also debugged this issue today and ended up in the same place --
after enabling the CPUID_DE bit in cpuid.c, I am able to start the
Windows 7 x64 installer, but it bluescreens with various messages
after a minute or so (with various codes like
DRIVER_IRQL_NOT_LESS_OR_EQUAL, KMODE_EXCEPTION_NOT_HANDLED, etc.).
As far as I can tell, CPUID_DE says whether the CPU supports setting
I/O breakpoints (break on in, out, ins, outs), and slightly changes
how accesses to DR4 and DR5 behave. This is further controlled by a
bit in the CR4 register. TCG does not support this yet; there is a
comment in target-i386/helper.c:
void hw_breakpoint_insert(CPUState *env, int index)
{
[...]
case 2:
/* No support for I/O watchpoints yet */
break;
[...]
}
I doubt this is the root cause of the Win7 x64 bluescreens, though; it
seems pretty unlikely that the installer would be trying to use I/O
debugging. I'll try to find the time to verify that no code is trying
to set CR4.DE, though.
So, I would also support having this bit turned on by default so that
more people can investigate these crashes. I'll certainly be looking
into them when I have time.
For what it's worth, Windows 7 32-bit works quite well when running
under qemu-system-x86_64.
-Brendan
For the sake of completeness, here's what I found in Intel's
documentation on CPUID_DE, CR4.DE, and I/O breakpoints:
Bit 2, DE. Debugging Extensions. Support for I/O breakpoints,
including CR4.DE for controlling the feature, and optional trapping of
accesses to DR4 and DR5.
[...]
Debug Registers DR4 and DR5
Debug registers DR4 and DR5 are reserved when debug extensions are
enabled (when the DE flag in control register CR4 is set) and attempts
to reference the DR4 and DR5 registers cause invalid-opcode exceptions
(#UD). When debug extensions are not enabled (when the DE flag is
clear), these registers are aliased to debug registers DR6 and DR7.
[...]
Debug Control Register (DR7)
[...]
R/W0 through R/W3 (read/write) fields (bits 16, 17, 20, 21, 24, 25,
28, and 29) — Specifies the breakpoint condition for the corresponding
breakpoint. The DE (debug extensions) flag in control register CR4
determines how the bits in the R/Wn fields are interpreted. When the
DE flag is set, the processor interprets bits as follows:
00 -- Break on instruction execution only.
01 -- Break on data writes only.
10 -- Break on I/O reads or writes.
11 -- Break on data reads or writes but not instruction fetches.
When the DE flag is clear, the processor interprets the R/Wn bits the
same as for the Intel386TM and Intel486TM
processors, which is as follows:
00 -- Break on instruction execution only.
01 -- Break on data writes only.
10 -- Undefined.
11 -- Break on data reads or writes but not instruction fetches.
On Mon, Sep 17, 2012 at 2:54 PM, Clemens Kolbitsch
kolbit...@lastline.com wrote:
On Mon, Sep 17, 2012 at 11:19 AM, Aurelien Jarno aurel...@aurel32.net
wrote:
On Mon, Sep 17, 2012 at 10:27:35AM -0700, Clemens Kolbitsch wrote:
On Mon, Sep 10, 2012 at 10:31 AM, Aurelien Jarno aurel...@aurel32.net
wrote:
On Mon, Sep 10, 2012 at 06:23:43PM +0200, Stefan Weil wrote:
Am 10.09.2012 08:19, schrieb Clemens Kolbitsch:
On Sat, Sep 8, 2012 at 11:22 AM, Clemens Kolbitsch
kolbit...@lastline.com wrote:
On Fri, Sep 7, 2012 at 9:26 PM, Stefan Weil s...@weilnetz.de wrote:
Am 08.09.2012 02:48, schrieb Clemens Kolbitsch:
Hi guys,
I need to run Win7 64bit in Qemu without KVM support. I found a few
messages concerning the unsupported architecture problem (Windows
shows a BSOD with STOP 0x005D ... on boot), for example
http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg01623.html
or
http://permalink.gmane.org/gmane.comp.emulators.qemu/92457
but I don't think there was ever a solution to the problem - at
least
what is proposed does not work (I've tried stable and GIT versions).
Since I have a decent background of modifying the Qemu internals,
I'm
more than happy to contribute to solving this issue, but I'm not
sure
if anyone is currently working on it (i.e., I don't want to start
at 0
in case someone is about to release a patch).
Please let me know if there is already a know solution/workaround or
whoever might be working on it, please ping me so we can sync.
BTW, in case this is necessary, here are the details of what I
need/what is not working:
Qemu: current git-trunk,
x86_64-softmmu$ ./qemu-system-x86_64 --version
QEMU emulator version 1.2.50, Copyright (c) 2003-2008 Fabrice
Bellard
Re: [Qemu-devel] QEMU (no kvm) Win7 (64bit) boot error [PATCH 1/1]
On Mon, Sep 10, 2012 at 10:31 AM, Aurelien Jarno aurel...@aurel32.net wrote:
On Mon, Sep 10, 2012 at 06:23:43PM +0200, Stefan Weil wrote:
Am 10.09.2012 08:19, schrieb Clemens Kolbitsch:
On Sat, Sep 8, 2012 at 11:22 AM, Clemens Kolbitsch
kolbit...@lastline.com wrote:
On Fri, Sep 7, 2012 at 9:26 PM, Stefan Weil s...@weilnetz.de wrote:
Am 08.09.2012 02:48, schrieb Clemens Kolbitsch:
Hi guys,
I need to run Win7 64bit in Qemu without KVM support. I found a few
messages concerning the unsupported architecture problem (Windows
shows a BSOD with STOP 0x005D ... on boot), for example
http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg01623.html
or
http://permalink.gmane.org/gmane.comp.emulators.qemu/92457
but I don't think there was ever a solution to the problem - at least
what is proposed does not work (I've tried stable and GIT versions).
Since I have a decent background of modifying the Qemu internals, I'm
more than happy to contribute to solving this issue, but I'm not sure
if anyone is currently working on it (i.e., I don't want to start at 0
in case someone is about to release a patch).
Please let me know if there is already a know solution/workaround or
whoever might be working on it, please ping me so we can sync.
BTW, in case this is necessary, here are the details of what I
need/what is not working:
Qemu: current git-trunk,
x86_64-softmmu$ ./qemu-system-x86_64 --version
QEMU emulator version 1.2.50, Copyright (c) 2003-2008 Fabrice Bellard
host: 64bit, Ubuntu LTS12.04
guest: 64bit Windows 7, no KVM possible
Thanks!
-Clemens
Hi Clemens,
AFAIK, nobody is working on this issue which exists for a long time now.
It would be great if you could find a solution to make QEMU without KVM
work with Windows guests.
Hi Stefan,
thanks for the info. I'll work on it then - hopefully I can come back
with a patch soon!
PS: It's QEMU, not Qemu. I modified the subject in my reply :-)
hehe, old habbit :) I'll try to remember - but why is the ML then
called Qemu-devel ? ;)
After a first night of debugging, I have come up with a simple patch.
I'm still testing and it seems it's not the ultimate solution yet
(there are still bluescreens), but it already gets you much further
while booting (using either the install CD or an actual image).
This diffs against the current stable-1.1. As you can see, one of the
feature bits of the CPUID are removed due to TCG not supporting them
(or the TCG bitmask is just missing them). Since Qemu uses CPUID_DE in
QEMU :-)
other locations, I'm assuming the bitmask is just wrong.
Can someone confirm that TCG supports CPUID_DE ? If not, I'll need to
work on this, otherwise I'll investigate why Win7 still crashes with a
BSOD.
Thanks!
Clemens
qemu$ git diff
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 388bc5c..f2af36d 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -259,7 +259,8 @@ typedef struct x86_def_t {
CPUID_PAE | CPUID_MCE | CPUID_CX8 | CPUID_APIC | CPUID_SEP | \
CPUID_MTRR | CPUID_PGE | CPUID_MCA | CPUID_CMOV | CPUID_PAT | \
CPUID_PSE36 | CPUID_CLFLUSH | CPUID_ACPI | CPUID_MMX | \
- CPUID_FXSR | CPUID_SSE | CPUID_SSE2 | CPUID_SS)
+ CPUID_FXSR | CPUID_SSE | CPUID_SSE2 | CPUID_SS | \
+ CPUID_DE) /* needed by Win7 64bit */
/* partly implemented:
CPUID_MTRR, CPUID_MCA, CPUID_CLFLUSH (needed for Win64)
CPUID_PSE36 (needed for Solaris) */
Hi Clemens,
indeed, it looks like CPUID_DE fixes that BSOD with STOP 0x005D
In my test scenario Windows now reboots instead of showing the BSOD.
This commit added the TCG feature bit trimming which broke Windows:
commit 551a2dec8fa55006a68393b9d6fb63577d2b3f1c
Autor:Andre Przywara andre.przyw...@amd.com Do Mär 11 14:39:03
2010
Eintragender:Aurelien Jarno aurel...@aurel32.net Sa Mär 13
16:50:54 2010
x86/cpuid: add TCG feature bit trimming
In KVM we trim the user provided CPUID bits to match the host CPU's
one. Introduce a similar feature to QEMU/TCG. Create a mask of TCG's
capabilities and apply it to the user bits.
This allows to let the CPU models reflect their native archetypes.
Signed-off-by: Andre Przywara andre.przyw...@amd.com
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
Andre, why don't we set the requested feature bits - no matter what
TCG provides?
Well the CPU flags are supposed to represent what a code can use. If we
announce things that we don't support, some code might enable some
features or instructions that are just causing an illegal instruction.
Now the question is to know if DE is implemented in TCG or not. It
*seems* there are some parts implemented, but not fully.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
Aurelien,
I understand
Re: [Qemu-devel] QEMU (no kvm) Win7 (64bit) boot error [PATCH 1/1]
On Mon, Sep 17, 2012 at 11:19 AM, Aurelien Jarno aurel...@aurel32.net wrote:
On Mon, Sep 17, 2012 at 10:27:35AM -0700, Clemens Kolbitsch wrote:
On Mon, Sep 10, 2012 at 10:31 AM, Aurelien Jarno aurel...@aurel32.net
wrote:
On Mon, Sep 10, 2012 at 06:23:43PM +0200, Stefan Weil wrote:
Am 10.09.2012 08:19, schrieb Clemens Kolbitsch:
On Sat, Sep 8, 2012 at 11:22 AM, Clemens Kolbitsch
kolbit...@lastline.com wrote:
On Fri, Sep 7, 2012 at 9:26 PM, Stefan Weil s...@weilnetz.de wrote:
Am 08.09.2012 02:48, schrieb Clemens Kolbitsch:
Hi guys,
I need to run Win7 64bit in Qemu without KVM support. I found a few
messages concerning the unsupported architecture problem (Windows
shows a BSOD with STOP 0x005D ... on boot), for example
http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg01623.html
or
http://permalink.gmane.org/gmane.comp.emulators.qemu/92457
but I don't think there was ever a solution to the problem - at least
what is proposed does not work (I've tried stable and GIT versions).
Since I have a decent background of modifying the Qemu internals, I'm
more than happy to contribute to solving this issue, but I'm not sure
if anyone is currently working on it (i.e., I don't want to start at 0
in case someone is about to release a patch).
Please let me know if there is already a know solution/workaround or
whoever might be working on it, please ping me so we can sync.
BTW, in case this is necessary, here are the details of what I
need/what is not working:
Qemu: current git-trunk,
x86_64-softmmu$ ./qemu-system-x86_64 --version
QEMU emulator version 1.2.50, Copyright (c) 2003-2008 Fabrice Bellard
host: 64bit, Ubuntu LTS12.04
guest: 64bit Windows 7, no KVM possible
Thanks!
-Clemens
Hi Clemens,
AFAIK, nobody is working on this issue which exists for a long time
now.
It would be great if you could find a solution to make QEMU without KVM
work with Windows guests.
Hi Stefan,
thanks for the info. I'll work on it then - hopefully I can come back
with a patch soon!
PS: It's QEMU, not Qemu. I modified the subject in my reply :-)
hehe, old habbit :) I'll try to remember - but why is the ML then
called Qemu-devel ? ;)
After a first night of debugging, I have come up with a simple patch.
I'm still testing and it seems it's not the ultimate solution yet
(there are still bluescreens), but it already gets you much further
while booting (using either the install CD or an actual image).
This diffs against the current stable-1.1. As you can see, one of the
feature bits of the CPUID are removed due to TCG not supporting them
(or the TCG bitmask is just missing them). Since Qemu uses CPUID_DE in
QEMU :-)
other locations, I'm assuming the bitmask is just wrong.
Can someone confirm that TCG supports CPUID_DE ? If not, I'll need to
work on this, otherwise I'll investigate why Win7 still crashes with a
BSOD.
Thanks!
Clemens
qemu$ git diff
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 388bc5c..f2af36d 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -259,7 +259,8 @@ typedef struct x86_def_t {
CPUID_PAE | CPUID_MCE | CPUID_CX8 | CPUID_APIC | CPUID_SEP |
\
CPUID_MTRR | CPUID_PGE | CPUID_MCA | CPUID_CMOV | CPUID_PAT
| \
CPUID_PSE36 | CPUID_CLFLUSH | CPUID_ACPI | CPUID_MMX | \
- CPUID_FXSR | CPUID_SSE | CPUID_SSE2 | CPUID_SS)
+ CPUID_FXSR | CPUID_SSE | CPUID_SSE2 | CPUID_SS | \
+ CPUID_DE) /* needed by Win7 64bit */
/* partly implemented:
CPUID_MTRR, CPUID_MCA, CPUID_CLFLUSH (needed for Win64)
CPUID_PSE36 (needed for Solaris) */
Hi Clemens,
indeed, it looks like CPUID_DE fixes that BSOD with STOP 0x005D
In my test scenario Windows now reboots instead of showing the BSOD.
This commit added the TCG feature bit trimming which broke Windows:
commit 551a2dec8fa55006a68393b9d6fb63577d2b3f1c
Autor:Andre Przywara andre.przyw...@amd.com Do Mär 11 14:39:03
2010
Eintragender:Aurelien Jarno aurel...@aurel32.net Sa Mär 13
16:50:54 2010
x86/cpuid: add TCG feature bit trimming
In KVM we trim the user provided CPUID bits to match the host CPU's
one. Introduce a similar feature to QEMU/TCG. Create a mask of TCG's
capabilities and apply it to the user bits.
This allows to let the CPU models reflect their native archetypes.
Signed-off-by: Andre Przywara andre.przyw...@amd.com
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
Andre, why don't we set the requested feature bits - no matter what
TCG provides?
Well the CPU flags are supposed to represent what a code can use. If we
announce things that we don't support, some code might enable some
features or instructions that are just causing an illegal instruction
Re: [Qemu-devel] Rethinking missed tick catchup
On 2012-09-12 15:54, Anthony Liguori wrote: Hi, We've been running into a lot of problems lately with Windows guests and I think they all ultimately could be addressed by revisiting the missed tick catchup algorithms that we use. Mike and I spent a while talking about it yesterday and I wanted to take the discussion to the list to get some additional input. Here are the problems we're seeing: 1) Rapid reinjection can lead to time moving faster for short bursts of time. We've seen a number of RTC watchdog BSoDs and it's possible that at least one cause is reinjection speed. 2) When hibernating a host system, the guest gets is essentially paused for a long period of time. This results in a very large tick catchup while also resulting in a large skew in guest time. I've gotten reports of the tick catchup consuming a lot of CPU time from rapid delivery of interrupts (although I haven't reproduced this yet). Guys, not much that I can contribute to solving the problem, but I have a bunch of VMs where this happens _every_ time I resume a snapshot (but without hibernating). In case this could be a connected problem and you need help testing a patch, I'm more than happy to help. -Clemens
Re: [Qemu-devel] QEMU (no kvm) Win7 (64bit) boot error
On Sat, Sep 8, 2012 at 11:22 AM, Clemens Kolbitsch
kolbit...@lastline.com wrote:
On Fri, Sep 7, 2012 at 9:26 PM, Stefan Weil s...@weilnetz.de wrote:
Am 08.09.2012 02:48, schrieb Clemens Kolbitsch:
Hi guys,
I need to run Win7 64bit in Qemu without KVM support. I found a few
messages concerning the unsupported architecture problem (Windows
shows a BSOD with STOP 0x005D ... on boot), for example
http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg01623.html
or
http://permalink.gmane.org/gmane.comp.emulators.qemu/92457
but I don't think there was ever a solution to the problem - at least
what is proposed does not work (I've tried stable and GIT versions).
Since I have a decent background of modifying the Qemu internals, I'm
more than happy to contribute to solving this issue, but I'm not sure
if anyone is currently working on it (i.e., I don't want to start at 0
in case someone is about to release a patch).
Please let me know if there is already a know solution/workaround or
whoever might be working on it, please ping me so we can sync.
BTW, in case this is necessary, here are the details of what I
need/what is not working:
Qemu: current git-trunk,
x86_64-softmmu$ ./qemu-system-x86_64 --version
QEMU emulator version 1.2.50, Copyright (c) 2003-2008 Fabrice Bellard
host: 64bit, Ubuntu LTS12.04
guest: 64bit Windows 7, no KVM possible
Thanks!
-Clemens
Hi Clemens,
AFAIK, nobody is working on this issue which exists for a long time now.
It would be great if you could find a solution to make QEMU without KVM
work with Windows guests.
Hi Stefan,
thanks for the info. I'll work on it then - hopefully I can come back
with a patch soon!
PS: It's QEMU, not Qemu. I modified the subject in my reply :-)
hehe, old habbit :) I'll try to remember - but why is the ML then
called Qemu-devel ? ;)
After a first night of debugging, I have come up with a simple patch.
I'm still testing and it seems it's not the ultimate solution yet
(there are still bluescreens), but it already gets you much further
while booting (using either the install CD or an actual image).
This diffs against the current stable-1.1. As you can see, one of the
feature bits of the CPUID are removed due to TCG not supporting them
(or the TCG bitmask is just missing them). Since Qemu uses CPUID_DE in
other locations, I'm assuming the bitmask is just wrong.
Can someone confirm that TCG supports CPUID_DE ? If not, I'll need to
work on this, otherwise I'll investigate why Win7 still crashes with a
BSOD.
Thanks!
Clemens
qemu$ git diff
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 388bc5c..f2af36d 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -259,7 +259,8 @@ typedef struct x86_def_t {
CPUID_PAE | CPUID_MCE | CPUID_CX8 | CPUID_APIC | CPUID_SEP | \
CPUID_MTRR | CPUID_PGE | CPUID_MCA | CPUID_CMOV | CPUID_PAT | \
CPUID_PSE36 | CPUID_CLFLUSH | CPUID_ACPI | CPUID_MMX | \
- CPUID_FXSR | CPUID_SSE | CPUID_SSE2 | CPUID_SS)
+ CPUID_FXSR | CPUID_SSE | CPUID_SSE2 | CPUID_SS | \
+ CPUID_DE) /* needed by Win7 64bit */
/* partly implemented:
CPUID_MTRR, CPUID_MCA, CPUID_CLFLUSH (needed for Win64)
CPUID_PSE36 (needed for Solaris) */
Re: [Qemu-devel] QEMU (no kvm) Win7 (64bit) boot error
On Mon, Sep 10, 2012 at 9:23 AM, Stefan Weil s...@weilnetz.de wrote:
Am 10.09.2012 08:19, schrieb Clemens Kolbitsch:
On Sat, Sep 8, 2012 at 11:22 AM, Clemens Kolbitsch
kolbit...@lastline.com wrote:
On Fri, Sep 7, 2012 at 9:26 PM, Stefan Weil s...@weilnetz.de wrote:
Am 08.09.2012 02:48, schrieb Clemens Kolbitsch:
Hi guys,
I need to run Win7 64bit in Qemu without KVM support. I found a few
messages concerning the unsupported architecture problem (Windows
shows a BSOD with STOP 0x005D ... on boot), for example
http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg01623.html
or
http://permalink.gmane.org/gmane.comp.emulators.qemu/92457
but I don't think there was ever a solution to the problem - at least
what is proposed does not work (I've tried stable and GIT versions).
Since I have a decent background of modifying the Qemu internals, I'm
more than happy to contribute to solving this issue, but I'm not sure
if anyone is currently working on it (i.e., I don't want to start at 0
in case someone is about to release a patch).
Please let me know if there is already a know solution/workaround or
whoever might be working on it, please ping me so we can sync.
BTW, in case this is necessary, here are the details of what I
need/what is not working:
Qemu: current git-trunk,
x86_64-softmmu$ ./qemu-system-x86_64 --version
QEMU emulator version 1.2.50, Copyright (c) 2003-2008 Fabrice Bellard
host: 64bit, Ubuntu LTS12.04
guest: 64bit Windows 7, no KVM possible
Thanks!
-Clemens
Hi Clemens,
AFAIK, nobody is working on this issue which exists for a long time now.
It would be great if you could find a solution to make QEMU without KVM
work with Windows guests.
Hi Stefan,
thanks for the info. I'll work on it then - hopefully I can come back
with a patch soon!
PS: It's QEMU, not Qemu. I modified the subject in my reply :-)
hehe, old habbit :) I'll try to remember - but why is the ML then
called Qemu-devel ? ;)
After a first night of debugging, I have come up with a simple patch.
I'm still testing and it seems it's not the ultimate solution yet
(there are still bluescreens), but it already gets you much further
while booting (using either the install CD or an actual image).
This diffs against the current stable-1.1. As you can see, one of the
feature bits of the CPUID are removed due to TCG not supporting them
(or the TCG bitmask is just missing them). Since Qemu uses CPUID_DE in
QEMU :-)
other locations, I'm assuming the bitmask is just wrong.
Can someone confirm that TCG supports CPUID_DE ? If not, I'll need to
work on this, otherwise I'll investigate why Win7 still crashes with a
BSOD.
Thanks!
Clemens
qemu$ git diff
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 388bc5c..f2af36d 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -259,7 +259,8 @@ typedef struct x86_def_t {
CPUID_PAE | CPUID_MCE | CPUID_CX8 | CPUID_APIC | CPUID_SEP | \
CPUID_MTRR | CPUID_PGE | CPUID_MCA | CPUID_CMOV | CPUID_PAT | \
CPUID_PSE36 | CPUID_CLFLUSH | CPUID_ACPI | CPUID_MMX | \
- CPUID_FXSR | CPUID_SSE | CPUID_SSE2 | CPUID_SS)
+ CPUID_FXSR | CPUID_SSE | CPUID_SSE2 | CPUID_SS | \
+ CPUID_DE) /* needed by Win7 64bit */
/* partly implemented:
CPUID_MTRR, CPUID_MCA, CPUID_CLFLUSH (needed for Win64)
CPUID_PSE36 (needed for Solaris) */
Hi Clemens,
indeed, it looks like CPUID_DE fixes that BSOD with STOP 0x005D
In my test scenario Windows now reboots instead of showing the BSOD.
This commit added the TCG feature bit trimming which broke Windows:
commit 551a2dec8fa55006a68393b9d6fb63577d2b3f1c
Autor:Andre Przywara andre.przyw...@amd.com Do Mär 11 14:39:03 2010
Eintragender:Aurelien Jarno aurel...@aurel32.net Sa Mär 13 16:50:54
2010
x86/cpuid: add TCG feature bit trimming
In KVM we trim the user provided CPUID bits to match the host CPU's
one. Introduce a similar feature to QEMU/TCG. Create a mask of TCG's
capabilities and apply it to the user bits.
This allows to let the CPU models reflect their native archetypes.
Signed-off-by: Andre Przywara andre.przyw...@amd.com
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
Andre, why don't we set the requested feature bits - no matter what TCG
provides?
Stefan,
could you tell me what QEMU ( ;-) ) HW configuration you use for your
testing? I'm able to boot, but it still is very unstable - after a few
seconds of running, I still run into BSODs. I think it's independent
of the bug I was working on, but I'd like to test some more.
BTW, I'm actually quite confident that the missing CPU-ID bit caused
the 0x5D booting BSOD, since I took two kernel boot traces (one of
QEMU stable crashing and a working VM) and the location the traces
branched off from each other was where the CPU-ID bits were checked
(and this one feature bit was the only thing that was not set
Re: [Qemu-devel] QEMU (no kvm) Win7 (64bit) boot error
On Fri, Sep 7, 2012 at 9:26 PM, Stefan Weil s...@weilnetz.de wrote: Am 08.09.2012 02:48, schrieb Clemens Kolbitsch: Hi guys, I need to run Win7 64bit in Qemu without KVM support. I found a few messages concerning the unsupported architecture problem (Windows shows a BSOD with STOP 0x005D ... on boot), for example http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg01623.html or http://permalink.gmane.org/gmane.comp.emulators.qemu/92457 but I don't think there was ever a solution to the problem - at least what is proposed does not work (I've tried stable and GIT versions). Since I have a decent background of modifying the Qemu internals, I'm more than happy to contribute to solving this issue, but I'm not sure if anyone is currently working on it (i.e., I don't want to start at 0 in case someone is about to release a patch). Please let me know if there is already a know solution/workaround or whoever might be working on it, please ping me so we can sync. BTW, in case this is necessary, here are the details of what I need/what is not working: Qemu: current git-trunk, x86_64-softmmu$ ./qemu-system-x86_64 --version QEMU emulator version 1.2.50, Copyright (c) 2003-2008 Fabrice Bellard host: 64bit, Ubuntu LTS12.04 guest: 64bit Windows 7, no KVM possible Thanks! -Clemens Hi Clemens, AFAIK, nobody is working on this issue which exists for a long time now. It would be great if you could find a solution to make QEMU without KVM work with Windows guests. Hi Stefan, thanks for the info. I'll work on it then - hopefully I can come back with a patch soon! PS: It's QEMU, not Qemu. I modified the subject in my reply :-) hehe, old habbit :) I'll try to remember - but why is the ML then called Qemu-devel ? ;) -Clemens
[Qemu-devel] Qemu (no kvm) Win7 (64bit) boot error
Hi guys, I need to run Win7 64bit in Qemu without KVM support. I found a few messages concerning the unsupported architecture problem (Windows shows a BSOD with STOP 0x005D ... on boot), for example http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg01623.html or http://permalink.gmane.org/gmane.comp.emulators.qemu/92457 but I don't think there was ever a solution to the problem - at least what is proposed does not work (I've tried stable and GIT versions). Since I have a decent background of modifying the Qemu internals, I'm more than happy to contribute to solving this issue, but I'm not sure if anyone is currently working on it (i.e., I don't want to start at 0 in case someone is about to release a patch). Please let me know if there is already a know solution/workaround or whoever might be working on it, please ping me so we can sync. BTW, in case this is necessary, here are the details of what I need/what is not working: Qemu: current git-trunk, x86_64-softmmu$ ./qemu-system-x86_64 --version QEMU emulator version 1.2.50, Copyright (c) 2003-2008 Fabrice Bellard host: 64bit, Ubuntu LTS12.04 guest: 64bit Windows 7, no KVM possible Thanks! -Clemens
Re: [Qemu-devel] Relative/Absolute timing snapshot problem
On 03/18/11 21:39, Clemens Kolbitsch wrote: Hi list, strange situation: When I create a snapshot using Qemu 0.14.0 stable, everything works smoothly and resuming the CPU takes about 1-2 seconds. If I don't use the snapshot file for some time, the time it takes to resume grows by 2-3 seconds per day. At the moment, I'm looking at a snapshot file from last week and it takes nearly 30 seconds to load. Funny thing about it: if I turn my system time back to the date when the snapshot was created (or before that), resuming CPU works within the expected 1-2 seconds. I have _very briefly_ looked into it and it seems like Qemu spends an aweful long amount of time catching up with timer execution -- is it possible that these are stored using absolute time instead of relative timing? I am using qcow2 file format, because I absolutely rely on CPU-snapshots and support for base-files. I have read here and there that it is more or less broken (or at least very slow), but with the correct cache-options it works for me (except for this bug, of course). Has anyone encountered this or should I start looking into it (although I have some experience with the core source, I'm not very experienced with the snapshotting code). Hi Clemens, Could you clarify what you are doing, when you say snapshot do you mean a savevm operation (ie. checkpoint) or a disk snapshot? Cheers, Jes I Jes, sorry for not being clear: I use a savevm operation. Following setup: I have a base file (qcow2 or qew format) and a snapshot file (generated via 'qemu-img create -b basefile -f qcow2 snapshotfile') and boot the snapshot file. Once the system (WinXP SP3 guest) has fully started, I create a snapshot (savevm foo) and exit the emulator. Later, I resume the snapshot by starting Qemu with the snapshotfile and say 'loadvm foo'. Actually, I found that the times I gave in my last email were way underestimated. The time difference is MUCH larger than 2-3 seconds per day. A week-old snapshot can take minutes to load on a reasonably idle host machine. --Clemens
[Qemu-devel] Relative/Absolute timing snapshot problem
Hi list, strange situation: When I create a snapshot using Qemu 0.14.0 stable, everything works smoothly and resuming the CPU takes about 1-2 seconds. If I don't use the snapshot file for some time, the time it takes to resume grows by 2-3 seconds per day. At the moment, I'm looking at a snapshot file from last week and it takes nearly 30 seconds to load. Funny thing about it: if I turn my system time back to the date when the snapshot was created (or before that), resuming CPU works within the expected 1-2 seconds. I have _very briefly_ looked into it and it seems like Qemu spends an aweful long amount of time catching up with timer execution -- is it possible that these are stored using absolute time instead of relative timing? I am using qcow2 file format, because I absolutely rely on CPU-snapshots and support for base-files. I have read here and there that it is more or less broken (or at least very slow), but with the correct cache-options it works for me (except for this bug, of course). Has anyone encountered this or should I start looking into it (although I have some experience with the core source, I'm not very experienced with the snapshotting code). Thanks, Clemens
[Qemu-devel] TB monitoring
Guys, I need a Qemu-internals expert to help me out here: I'm trying to monitor execution of certain (user-land) TBs in a i386-softmmu system. For this, the cpu-main loop has been patched: Before jumping into a TB's generated code, I first check its guest-virtual start address whether it matches any of my monitored EIPs. Obviously, this only works for monitoring function starts (or other locations where a new TB is guaranteed to start) and with TB-chaining turned off. So far, this has been working great (for years even). Now I tried to improve the performance of my monitoring system by doing the following: Each TB is associated with an additional 2 bits (in the cflags): seen-before and monitored. Whenever I check a TB, I also set its seen- before flag and update the monitored bit (if the TB contains a monitored start EIP). Since a TB might be shared between two guest processes (the system is monitoring a Windows XP guest), I also save the a guest-process unique ID with the TB (using some bits from its CR3). With this, I can skip checking a TB if its seen-before bit is set, but the monitored is clear. If the TB's guest-process-ID is different from the currently executing process-ID I just reset the seen-before bit (which forces the EIP analysis). I have tried this on various programs, running inside my guest and it seems to be fast and working (almost ;-)). However, sometimes (*very* rarely), the above approach misses a monitored TB (skips analysis). Could someone comment on my approach, maybe including some of the following thoughts: 1) is it possible that a TB grows ... i.e., it merges with a second TB where the second is monitored but the first one isn't? 2) are there any situations how a TB can be created without going through tb_alloc (which internally resets the cflags and thus my bits)? Note that my code is based on Qemu 0.9.1 (if you wonder why I refer to certain old-style Qemu-internals). Any help would be greatly appreciated!! If you need some more information or don't fully understand the problem, please don't hesitate to ask. Thanks!! Clemens
[Qemu-devel] i386 emulation bug: mov reg, [addr]
Hi list,
I'm experiencing a strange emulation bug with the op-code below. The
instruction raises a segfault in the application (running on the guest),
however, if I enable KVM to run the exact same application, no segfault is
raised.
0x0080023b: 8b 04 65 11 22 33 44mov regEAX, [0x44332211]
where 11 22 33 44 is just some address. According to gdb (on a 32bit little-
endian machine), this instruction can be disassembled as a mov address to
reg-eax.
I have added some debugging code to the disas_insn function in translate.c to
find out that the code is disassembled to the following blocks:
(NOTE: this debugging comes from an old qemu version where the old TB-style
code was still used. HOWEVER, the same bug is still happening when used on the
0.11.0 source branch).
0x0080023b: disassemble 7 bytes (to 0x00800242)
0x001: movl_A0_im 0x44332211
0x002: addl_A0_ESP_s1
0x003: ldl_user_T0_A0
0x004: movl_EAX_T0
So, as you can see, everything seems correct, but there is an additional
(second) TB that messes everything up. In fact, the segfault happens because
whatever is in ESP (shifted by one) is added to the address (which might then
not be a valid address).
As I said, the code might crash in old versions of Qemu just like in the
0.11.0 source branch and works fine if I use KVM (because the user code is not
emulated of course).
Since this is such a fundamental problem, I don't quite understand how this
could stay hidden so long... or maybe there is an error on my side :-/
Any help on this is greatly appreciated!!
--Clemens
---
some additional debugging information: I have traced down the problem to the
following call in translate.c:
static void gen_lea_modrm(DisasContext *s, int modrm, int *reg_ptr, int
*offset_ptr)
{
...
if (s-aflag) {
/// !! we take this path !!
...
if (base == 4) {
/// !! we take this path !!
havesib = 1;
code = ldub_code(s-pc++);
scale = (code 6) 3;
index = ((code 3) 7) | REX_X(s);
base = (code 7);
}
base |= REX_B(s);
switch (mod) {
...
default:
case 2:
/// !! 4byte load: we take this path !!
disp = ldl_code(s-pc);
s-pc += 4;
break;
}
if (base = 0) {
/* for correct popl handling with esp */
...
} else {
#ifdef TARGET_X86_64
if (s-aflag == 2) {
gen_op_movq_A0_im(disp);
} else
#endif
{
/// !! this is still ok, we need the address !!!
gen_op_movl_A0_im(disp);
}
}
/* XXX: index == 4 is always invalid */
if (havesib (index != 4 || scale != 0)) {
#ifdef TARGET_X86_64
if (s-aflag == 2) {
gen_op_addq_A0_reg_sN(scale, index);
} else
#endif
{
/// !! this does the evil !!
gen_op_addl_A0_reg_sN(scale, index);
}
}
[Qemu-devel] Re: Re: Atheros Wireless Device Emulation
Hello! Since I cannot guarantee that the code will be on my server forever, I'll post the CVS-patch here once more. Furthermore, I'll split it into smaller sections and put it inline, so the chance of getting it reviewed are a little bigger ;-) Also, here are some comments I posted mistakenly into a message that was not attached to the wlan-device thread: -- Some more infos on the wlan emulation: - if you cannot connect to the router (happens to me sometimes with windows guests), simply cancel connecting and retry - i experienced problems when getting a dynamic ip from qemu (dhcp) when using multiple NICs. Simply disable all other NICs and it always worked for me or use static IPs. - Inbound connections still buggy - Still does not work with current CVS of Madwifi drivers. Use MadWifi 0.9.3 (and don't forget to use the _linux_ model type as explained in previous posts) - I just tried the patch and got a qemu: fatal: triple fault ... i restarted qemu and everything worked fine. either there is still a major bug in my code, or the snapshots inside my image were a little messed up. Have fun with the code ;-) -- Briefly documented patches will come in the next posts --Clemens
[Qemu-devel] Re: Re: Re: Atheros Wireless Device Emulation
Patch #1:
Necessary changes to Qemu itself... Makefile and hw/pci.c to include the
device:
diff -Naur qemu/hw/pci.c qemu-altered/hw/pci.c
--- qemu/hw/pci.c 2008-02-03 03:20:18.0 +0100
+++ qemu-altered/hw/pci.c 2008-03-01 12:59:50.0 +0100
@@ -636,6 +636,8 @@
pci_i82559er_init(bus, nd, devfn);
} else if (strcmp(nd-model, rtl8139) == 0) {
pci_rtl8139_init(bus, nd, devfn);
+} else if (strncmp(nd-model, atheros_wlan, 12) == 0) {
+pci_Atheros_WLAN_init(bus, nd, devfn);
} else if (strcmp(nd-model, e1000) == 0) {
pci_e1000_init(bus, nd, devfn);
} else if (strcmp(nd-model, pcnet) == 0) {
diff -Naur qemu/hw/pci.h qemu-altered/hw/pci.h
--- qemu/hw/pci.h 2008-02-03 03:20:18.0 +0100
+++ qemu-altered/hw/pci.h 2008-03-01 13:00:20.0 +0100
@@ -126,6 +126,10 @@
void pci_rtl8139_init(PCIBus *bus, NICInfo *nd, int devfn);
+/* atheros_wlan.c */
+
+void pci_Atheros_WLAN_init(PCIBus *bus, NICInfo *nd, int devfn);
+
/* e1000.c */
void pci_e1000_init(PCIBus *bus, NICInfo *nd, int devfn);
diff -Naur qemu/Makefile.target qemu-altered/Makefile.target
--- qemu/Makefile.target2008-02-27 18:53:27.0 +0100
+++ qemu-altered/Makefile.target2008-03-01 12:58:54.0 +0100
@@ -528,6 +528,8 @@
OBJS += pcnet.o
OBJS += rtl8139.o
OBJS += e1000.o
+OBJS += atheros_wlan.o atheros_wlan_io.o atheros_wlan_ap.o
+OBJS += atheros_wlan_packet.o atheros_wlan_crc32.o
ifeq ($(TARGET_BASE_ARCH), i386)
# Hardware support
[Qemu-devel] Re: Re: Re: Atheros Wireless Device Emulation
Patch #2:
Setup code for the device
diff -Naur qemu/hw/atheros_wlan.c qemu-altered/hw/atheros_wlan.c
--- qemu/hw/atheros_wlan.c 1970-01-01 01:00:00.0 +0100
+++ qemu-altered/hw/atheros_wlan.c 2008-03-01 12:33:11.0 +0100
@@ -0,0 +1,348 @@
+/**
+ * QEMU WLAN device emulation
+ *
+ * Copyright (c) 2008 Clemens Kolbitsch
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the
rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ *
+ * Modifications:
+ * 2008-February-24 Clemens Kolbitsch :
+ * New implementation based on ne2000.c
+ *
+ */
+
+#include hw.h
+#include pci.h
+#include pc.h
+#include net.h
+
+
+#include stdio.h
+#include stdlib.h
+#include sys/types.h
+#include sys/shm.h
+#include sys/stat.h
+#include sys/socket.h
+#include sys/ipc.h
+#include sys/sem.h
+#include sys/mman.h
+#include netinet/in.h
+#include netdb.h
+#include string.h
+#include unistd.h
+#include fcntl.h
+
+#include signal.h
+
+#include time.h
+#include sys/time.h
+
+/*
+ * PCI and EEPROM definitions
+ */
+#include hw/atheros_wlan.h
+#include hw/atheros_wlan_io.h
+#include hw/atheros_wlan_ap.h
+#include hw/atheros_wlan_eeprom.h
+
+/*
+ * MadWifi OPENHAL atheros constants
+ */
+#include hw/ath5k_hw.h
+#include hw/ath5kreg.h
+#include hw/ath5k.h
+
+
+static void Atheros_WLAN_reset(NICInfo *nd, Atheros_WLANState *s)
+{
+ DEBUG_PRINT((reset\n));
+
+ /*
+* Restore mac address
+*/
+ memcpy(s-macaddr, nd-macaddr, 6);
+
+ /*
+* data from my local AR5212 device
+*/
+ SET_MEM_L(s-mem, 12, 0);
+ SET_MEM_L(s-mem, AR5K_SREV, 86);
+ SET_MEM_L(s-mem, AR5K_PCICFG, 0x00010014);
+ SET_MEM_L(s-mem, AR5K_PHY_CHIP_ID, 65);
+ SET_MEM_L(s-mem, AR5K_SLEEP_CTL, 0x0001);
+ SET_MEM_L(s-mem, 0x9820, 0x02020200);
+
+ Atheros_WLAN_update_irq(s);
+}
+
+void Atheros_WLAN_setup_type(NICInfo *nd, PCIAtheros_WLANState *d)
+{
+ // create buffer large enough to
+ // do all checks
+ char *device_name;
+ char nd_model[128];
+ uint8_t *pci_conf;
+ Atheros_WLANState *s;
+
+ device_name = nd_model;
+ pci_conf = d-dev.config;
+ s = d-Atheros_WLAN;
+
+ snprintf(nd_model, sizeof(nd_model), %s, nd-model);
+
+
+ // skip atheros_wlan
+ // if it had not been part of nd-model, this
+ // module would not be loaded anyways!!
+ device_name += 12;
+ DEBUG_PRINT_AP((Loading virtual wlan-pci device...\n));
+ if (strncmp(device_name, _winxp, 6) == 0)
+ {
+ s-device_driver_type = WINXP_DRIVER;
+ DEBUG_PRINT_AP(( * Make sure you are using a MS Windows
driver!!\n));
+
+ // skip _winxp
+ device_name += 6;
+ }
+ else if (strncmp(device_name, _linux, 6) == 0)
+ {
+ s-device_driver_type = LINUX_DRIVER;
+ DEBUG_PRINT_AP(( * Make sure you are using a MadWifi
driver!!\n));
+
+ // skip _linux
+ device_name += 6;
+ }
+ else
+ {
+ s-device_driver_type = LINUX_DRIVER;
+ DEBUG_PRINT_AP(( * Unknown driver type '%s'... defaulting to
Linux... Make
sure you are using a MadWifi driver!!\n, nd-model));
+ }
+
+ if (strncmp(device_name, _HPW400, 7) == 0)
+ {
+ s-eeprom_data = (u_int32_t*)Atheros_WLAN_eeprom_data_HPW400;
+ s-eeprom_size = sizeof(Atheros_WLAN_eeprom_data_HPW400);
+
+ memcpy(pci_conf, Atheros_WLAN_pci_config_HPW400, 256);
+
+ DEBUG_PRINT_AP(( * Using EEPROM and device configuration of HP
W400!!
\n));
+
+ // skip _HPW400
+ device_name += 7;
+ }
+ else if (strncmp(device_name, _MacBook, 8) == 0)
+ {
+ s-eeprom_data = (u_int32_t*)Atheros_WLAN_eeprom_data_MacBook;
+ s-eeprom_size = sizeof(Atheros_WLAN_eeprom_data_MacBook
[Qemu-devel] Re: Re: Re: Atheros Wireless Device Emulation
Patch #3:
Setup code definitions. The 802.11 data structures, device memory, and
debugging macros.
diff -Naur qemu/hw/atheros_wlan.h qemu-altered/hw/atheros_wlan.h
--- qemu/hw/atheros_wlan.h 1970-01-01 01:00:00.0 +0100
+++ qemu-altered/hw/atheros_wlan.h 2008-03-01 12:33:11.0 +0100
@@ -0,0 +1,345 @@
+/**
+ * QEMU WLAN device emulation
+ *
+ * Copyright (c) 2008 Clemens Kolbitsch
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the
rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ *
+ * Modifications:
+ * 2008-February-24 Clemens Kolbitsch :
+ * New implementation based on ne2000.c
+ *
+ */
+
+#ifndef atheros_wlan_h
+#define atheros_wlan_h 1
+
+
+#include stdio.h
+#include stdlib.h
+#include sys/types.h
+#include sys/shm.h
+#include sys/stat.h
+#include sys/socket.h
+#include sys/ipc.h
+#include sys/sem.h
+#include sys/mman.h
+#include netinet/in.h
+#include netdb.h
+#include string.h
+#include unistd.h
+#include fcntl.h
+
+
+/*
+ * debug Atheros_WLAN card
+ *
+ * i.e. show all access traces
+ */
+// #define DEBUG_Atheros_WLAN 1
+// #define DEBUG_Atheros_AP_WLAN 1
+
+#define PCI_FREQUENCY 3300L
+
+#if defined (DEBUG_Atheros_WLAN)
+# define DEBUG_PRINT(x) do { struct timeval __tt; gettimeofday(__tt, NULL);
printf(%u:%u , __tt.tv_sec, __tt.tv_usec); printf x ; } while (0)
+#else
+# define DEBUG_PRINT(x)
+#endif
+
+#if defined (DEBUG_Atheros_AP_WLAN)
+# define DEBUG_PRINT_AP(x) printf x ;
+#else
+# define DEBUG_PRINT_AP(x)
+#endif
+
+
+
+/*
+ * The madwifi driver crashes if too
+ * many frames are in the receive
+ * queue linked list
+ *
+ * This can happen when interrupts are
+ * not picked up right away (what can
+ * happen due to qemu's lazy interrupt
+ * checking/handling)!!
+ *
+ * UPDATE: BinaryHAL suddenly seems to
+ * work with the WINDOWS_RX_FRAME as well
+ * which is even better (because more frames
+ * may be received concurrently...)
+ */
+#define MAX_CONCURRENT_RX_FRAMES_WINDOWS_OR_OPEN_HAL 999
+#define MAX_CONCURRENT_RX_FRAMES_BINARY_HAL10
+#define MAX_CONCURRENT_RX_FRAMES
MAX_CONCURRENT_RX_FRAMES_WINDOWS_OR_OPEN_HAL
+
+/*
+ * In case we are connecting with a windows guest OS
+ * (or the ndiswrapper of the windows driver) we must
+ * define this macro... otherwise no packets will be
+ * received.
+ *
+ * If connecting with a linux guest/madwifi with the
+ * macro defined it won't work on the other hand!!!
+ */
+#define WINXP_DRIVER 1
+#define LINUX_DRIVER 2
+
+#define PCI_CONFIG_AR5212 1
+#define PCI_CONFIG_AR5424 2
+
+
+
+
+
+#defineIEEE80211_IDLE 0xff
+
+#defineIEEE80211_TYPE_MGT 0x00
+#defineIEEE80211_TYPE_CTL 0x01
+#defineIEEE80211_TYPE_DATA 0x02
+
+#defineIEEE80211_TYPE_MGT_SUBTYPE_BEACON 0x08
+#defineIEEE80211_TYPE_MGT_SUBTYPE_ACTION 0x0d
+#defineIEEE80211_TYPE_MGT_SUBTYPE_PROBE_REQ0x04
+#defineIEEE80211_TYPE_MGT_SUBTYPE_PROBE_RESP 0x05
+#defineIEEE80211_TYPE_MGT_SUBTYPE_AUTHENTICATION 0x0b
+#defineIEEE80211_TYPE_MGT_SUBTYPE_DEAUTHENTICATION 0x0c
+#defineIEEE80211_TYPE_MGT_SUBTYPE_ASSOCIATION_REQ 0x00
+#defineIEEE80211_TYPE_MGT_SUBTYPE_ASSOCIATION_RESP 0x01
+#defineIEEE80211_TYPE_MGT_SUBTYPE_DISASSOCIATION 0x09
+
+#defineIEEE80211_TYPE_CTL_SUBTYPE_ACK 0x0d
+
+#defineIEEE80211_TYPE_DATA_SUBTYPE_DATA0x00
+
+
+#defineIEEE80211_BEACON_PARAM_SSID 0x00
+#defineIEEE80211_BEACON_PARAM_SSID_STRING \x00
+#defineIEEE80211_BEACON_PARAM_RATES0x01
+#defineIEEE80211_BEACON_PARAM_RATES_STRING \x01
+#defineIEEE80211_BEACON_PARAM_CHANNEL 0x03
[Qemu-devel] Re: Re: Re: Atheros Wireless Device Emulation
Patch #4:
Virtual access point code. It is based on a message queue and a timer that
repeatedly injects the ingoing messages and replies into the queue. Outgoing
messages are parsed to extract the IP-datagram from the wireless packet and
passed on to Qemu.
There are 3 important functions here:
- Atheros_WLAN_handle_frame, is the AP state machine. Really simplified but
sufficient ;-)
- Atheros_WLAN_handleRxBuffer, inject a packet into the guest driver
- Atheros_WLAN_handleTxBuffer, extract a packet from the guest driver
diff -Naur qemu/hw/atheros_wlan_ap.c qemu-altered/hw/atheros_wlan_ap.c
--- qemu/hw/atheros_wlan_ap.c 1970-01-01 01:00:00.0 +0100
+++ qemu-altered/hw/atheros_wlan_ap.c 2008-03-01 12:33:11.0 +0100
@@ -0,0 +1,771 @@
+/**
+ * QEMU WLAN access point emulation
+ *
+ * Copyright (c) 2008 Clemens Kolbitsch
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the
rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ *
+ * Modifications:
+ * 2008-February-24 Clemens Kolbitsch :
+ * New implementation based on ne2000.c
+ *
+ */
+
+
+#include hw.h
+#include pci.h
+#include pc.h
+#include net.h
+#include qemu-timer.h
+
+
+#include stdio.h
+#include stdlib.h
+#include sys/types.h
+#include sys/shm.h
+#include sys/stat.h
+#include sys/socket.h
+#include sys/ipc.h
+#include sys/sem.h
+#include sys/mman.h
+#include netinet/in.h
+#include netdb.h
+#include string.h
+#include unistd.h
+#include fcntl.h
+
+#include signal.h
+
+#include time.h
+#include sys/time.h
+
+/*
+ * PCI and EEPROM definitions
+ */
+#include hw/atheros_wlan.h
+#include hw/atheros_wlan_ap.h
+#include hw/atheros_wlan_io.h
+#include hw/atheros_wlan_packet.h
+
+/*
+ * MadWifi OPENHAL atheros constants
+ */
+#include hw/ath5k_hw.h
+#include hw/ath5kreg.h
+#include hw/ath5k.h
+
+static int semaphore_helper(int semaphore, int sem_op, int semaphore_nr,
short flags)
+{
+ struct sembuf semp;
+ semp.sem_num = semaphore_nr;
+ semp.sem_op = sem_op;
+ semp.sem_flg = flags;
+
+ if (semaphore == -1)
+ {
+ /*
+* We don't have a semaphore... probably not
+* that bad, but having one is better :-)
+*/
+ return -1;
+ }
+
+ int ret;
+ while ((ret = semop(semaphore, semp, 1)) 0)
+ {
+ if (errno == EAGAIN flags == IPC_NOWAIT)
+ {
+ return errno;
+ }
+ else if (errno != EINTR)
+ {
+ fprintf(stderr, Semaphore error: 0x%x / %u\n, errno,
errno);
+ return errno;
+ }
+ }
+
+ return ret;
+}
+
+
+static int signal_semaphore(int semaphore, int semaphore_nr)
+{
+ return semaphore_helper(semaphore, 1, semaphore_nr, 0);
+}
+static int wait_semaphore(int semaphore, int semaphore_nr)
+{
+ return semaphore_helper(semaphore, -1, semaphore_nr, 0);
+}
+
+void Atheros_WLAN_insert_frame(Atheros_WLANState *s, struct mac80211_frame
*frame)
+{
+ struct mac80211_frame *i_frame;
+
+ wait_semaphore(s-access_semaphore, 0);
+
+ s-inject_queue_size++;
+ i_frame = s-inject_queue;
+ if (!i_frame)
+ {
+ s-inject_queue = frame;
+ }
+ else
+ {
+ while (i_frame-next_frame)
+ {
+ i_frame = i_frame-next_frame;
+ }
+
+ i_frame-next_frame = frame;
+ }
+
+ if (!s-inject_timer_running)
+ {
+ // if the injection timer is not
+ // running currently, let's schedule
+ // one run...
+ s-inject_timer_running = 1;
+ qemu_mod_timer(s-inject_timer, qemu_get_clock(rt_clock) + 5);
+ }
+
+ signal_semaphore(s-access_semaphore, 0);
+}
+
+static void Atheros_WLAN_beacon_timer(void *opaque)
+{
+ struct mac80211_frame *frame
[Qemu-devel] Re: Re: Re: Atheros Wireless Device Emulation
Patch #5:
The most important/difficult/ugly part: Hardware I/O. It is handled over a
direclty
mapped memory regions that is written to/read from the device driver code. Based
on ath5k and plenty of reverse engineering.
NOTE: I did NOT reimplement the hardware!! I simply handled the events as they
come
in and mess with the device memory to fake a real device. Thus the code is
quite hard to
understand. Sorry *g*
diff -Naur qemu/hw/atheros_wlan_io.c qemu-altered/hw/atheros_wlan_io.c
--- qemu/hw/atheros_wlan_io.c 1970-01-01 01:00:00.0 +0100
+++ qemu-altered/hw/atheros_wlan_io.c 2008-03-01 12:33:11.0 +0100
@@ -0,0 +1,1188 @@
+/**
+ * QEMU WLAN device emulation
+ *
+ * Copyright (c) 2008 Clemens Kolbitsch
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ *
+ * Modifications:
+ * 2008-February-24 Clemens Kolbitsch :
+ * New implementation based on ne2000.c
+ *
+ */
+
+
+#include hw.h
+#include pci.h
+#include pc.h
+#include net.h
+
+
+#include stdio.h
+#include stdlib.h
+#include sys/types.h
+#include sys/shm.h
+#include sys/stat.h
+#include sys/socket.h
+#include sys/ipc.h
+#include sys/sem.h
+#include sys/mman.h
+#include netinet/in.h
+#include netdb.h
+#include string.h
+#include unistd.h
+#include fcntl.h
+
+#include signal.h
+
+#include time.h
+#include sys/time.h
+
+#include hw/atheros_wlan.h
+#include hw/atheros_wlan_ap.h
+
+
+/*
+ * MadWifi OPENHAL atheros constants
+ */
+#include hw/ath5k.h
+#include hw/ath5k_hw.h
+#include hw/ath5kreg.h
+
+
+static const struct Atheros_WLAN_frequency Atheros_WLAN_frequency_data[] =
+ {
+ { 20689, 3077, 2412 }, // channel 1
+ { 20715, 3078, 2417 }, // channel 2
+ { 20689, 3079, 2422 }, // channel 3
+ { 20715, 3079, 2427 }, // channel 4
+ { 20529, 3076, 2432 }, // channel 5
+ { 20507, 3078, 2437 }, // channel 6
+ { 20529, 3078, 2442 }, // channel 7
+ { 20507, 3079, 2447 }, // channel 8
+ { 20529, 3077, 2452 }, // channel 9
+ { 20635, 3078, 2457 }, // channel 10
+ { 20529, 3079, 2462 }, // channel 11
+ { 20635, 3079, 2467 }, // channel 12
+ { 20657, 3076, 2472 }, // channel 13
+ { 20529, 1029, 2484 } // channel 14
+ };
+
+/*
+ * NOTE: By using this function instead
+ * of accessing the array directly through
+ * an index, we can leave out parts of the
+ * EEPROM data!!
+ */
+static int get_eeprom_data(Atheros_WLANState *s, uint32_t addr, uint32_t *val)
+{
+ if (val == NULL)
+ {
+ return 1;
+ }
+
+ // why?? but seems necessary...
+ addr--;
+
+ if ((addr 0) || (addr s-eeprom_size))
+ {
+ return 2;
+ }
+
+ *val = s-eeprom_data[addr];
+ return 0;
+}
+
+
+
+
+
+
+void updateFrequency(Atheros_WLANState *s)
+{
+ int i;
+ u_int32_t new_frequency = 0;
+ for (i=0; i sizeof(Atheros_WLAN_frequency_data) /
sizeof(Atheros_WLAN_frequency_data[0]); i++)
+ {
+ if (Atheros_WLAN_frequency_data[i].value1 !=
s-current_frequency_partial_data[0])
+ continue;
+
+ if (Atheros_WLAN_frequency_data[i].value2 !=
s-current_frequency_partial_data[1])
+ continue;
+
+ new_frequency = Atheros_WLAN_frequency_data[i].frequency;
+ break;
+ }
+
+ if (new_frequency)
+ {
+ s-current_frequency = new_frequency;
+ }
+}
+
+
+
+static uint32_t mm_readl(Atheros_WLANState *s, target_phys_addr_t addr);
+static void mm_writel(Atheros_WLANState *s, target_phys_addr_t addr, uint32_t
val);
+
+static void Atheros_WLAN_mmio_writeb(void
[Qemu-devel] Re: Re: Re: Atheros Wireless Device Emulation
Patch #6:
802.11 packet definitions. Code to create beacon frames, probe responses,
authentication frames, association replies, etc.
diff -Naur qemu/hw/atheros_wlan_packet.c qemu-altered/hw/atheros_wlan_packet.c
--- qemu/hw/atheros_wlan_packet.c 1970-01-01 01:00:00.0 +0100
+++ qemu-altered/hw/atheros_wlan_packet.c 2008-03-01 12:33:11.0
+0100
@@ -0,0 +1,481 @@
+/**
+ * QEMU WLAN access point emulation
+ *
+ * Copyright (c) 2008 Clemens Kolbitsch
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ *
+ * Modifications:
+ * 2008-February-24 Clemens Kolbitsch :
+ * New implementation based on ne2000.c
+ *
+ */
+
+
+#include hw.h
+#include pci.h
+#include pc.h
+#include net.h
+
+
+#include stdio.h
+#include stdlib.h
+#include sys/types.h
+#include sys/shm.h
+#include sys/stat.h
+#include sys/socket.h
+#include sys/ipc.h
+#include sys/sem.h
+#include sys/mman.h
+#include netinet/in.h
+#include netdb.h
+#include string.h
+#include unistd.h
+#include fcntl.h
+
+
+#include hw/atheros_wlan.h
+#include hw/atheros_wlan_crc32.h
+#include hw/atheros_wlan_packet.h
+
+#define FRAME_INSERT(_8bit_data) buf[i++] = _8bit_data
+
+
+static int insertCRC(struct mac80211_frame *frame, uint32_t frame_length)
+{
+ unsigned long crc;
+ unsigned char *fcs = (char*)frame;
+
+ crc = crc32_ccitt(fcs, frame_length);
+ memcpy(fcs[frame_length], crc, 4);
+
+ return frame_length + 4;
+}
+
+
+void Atheros_WLAN_init_frame(Atheros_WLANState *s, struct mac80211_frame
*frame)
+{
+ if (!frame)
+ return;
+
+ frame-sequence_control.sequence_number = s-inject_sequence_number++;
+ memcpy(frame-source_address, s-ap_macaddr, 6);
+ memcpy(frame-bssid_address, s-ap_macaddr, 6);
+
+ frame-frame_length = insertCRC(frame, frame-frame_length);
+}
+
+
+struct mac80211_frame *Atheros_WLAN_create_beacon_frame()
+{
+ unsigned int i;
+ unsigned char *buf;
+ struct mac80211_frame *frame;
+
+ frame = (struct mac80211_frame *)malloc(sizeof(struct mac80211_frame));
+ if (!frame)
+ {
+ return NULL;
+ }
+
+ frame-next_frame = NULL;
+ frame-frame_control.protocol_version = 0;
+ frame-frame_control.type = IEEE80211_TYPE_MGT;
+ frame-frame_control.sub_type = IEEE80211_TYPE_MGT_SUBTYPE_BEACON;
+ frame-frame_control.flags = 0;
+ frame-duration_id = 0;
+ frame-sequence_control.fragment_number = 0;
+
+ for (i=0; i6; frame-destination_address[i] = 0xff, i++);
+
+ i = 0;
+ buf = (unsigned char*)frame-data_and_fcs;
+
+ /*
+* Fixed params... typical AP params (12 byte)
+*
+* They include
+* - Timestamp
+* - Beacon Interval
+* - Capability Information
+*/
+ FRAME_INSERT(0x8d);
+ FRAME_INSERT(0x61);
+ FRAME_INSERT(0xa5);
+ FRAME_INSERT(0x18);
+ FRAME_INSERT(0x00);
+ FRAME_INSERT(0x00);
+ FRAME_INSERT(0x00);
+ FRAME_INSERT(0x00);
+ FRAME_INSERT(0x64);
+ FRAME_INSERT(0x00);
+ FRAME_INSERT(0x01);
+ FRAME_INSERT(0x00);
+
+ FRAME_INSERT(IEEE80211_BEACON_PARAM_SSID);
+ FRAME_INSERT(4);// length
+ FRAME_INSERT('Q'); // SSID
+ FRAME_INSERT('L'); // SSID
+ FRAME_INSERT('a'); // SSID
+ FRAME_INSERT('n'); // SSID
+
+ FRAME_INSERT(IEEE80211_BEACON_PARAM_RATES);
+ FRAME_INSERT(8);// length
+ FRAME_INSERT(0x82);
+ FRAME_INSERT(0x84);
+ FRAME_INSERT(0x8b);
+ FRAME_INSERT(0x96);
+ FRAME_INSERT(0x24);
+ FRAME_INSERT(0x30);
+ FRAME_INSERT(0x48);
+ FRAME_INSERT(0x6c);
+
+ FRAME_INSERT(IEEE80211_BEACON_PARAM_CHANNEL);
+ FRAME_INSERT(1);// length
+ FRAME_INSERT(0x09);
+
+ frame-frame_length = IEEE80211_HEADER_SIZE + i
[Qemu-devel] Re: Re: Re: Atheros Wireless Device Emulation
Patch #8:
CRC32 helper code. Sorry if there is already some global function that could
be used for this purpose. Simply took the code from Wireshark (license and
header documentation unchanged obviously).
diff -Naur qemu/hw/atheros_wlan_crc32.c qemu-altered/hw/atheros_wlan_crc32.c
--- qemu/hw/atheros_wlan_crc32.c1970-01-01 01:00:00.0 +0100
+++ qemu-altered/hw/atheros_wlan_crc32.c2008-03-01 12:33:11.0
+0100
@@ -0,0 +1,238 @@
+/* crc32.c
+ * CRC-32 routine
+ *
+ * $Id: crc32.c 18197 2006-05-21 05:12:17Z sahlberg $
+ *
+ * Wireshark - Network traffic analyzer
+ * By Gerald Combs [EMAIL PROTECTED]
+ * Copyright 1998 Gerald Combs
+ *
+ * Copied from README.developer
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Credits:
+ *
+ * Table from Solomon Peachy
+ * Routine from Chris Waters
+ */
+
+#include atheros_wlan_crc32.h
+
+/*
+ * Table for the AUTODIN/HDLC/802.x CRC.
+ *
+ * Polynomial is
+ *
+ * x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^8 + x^7 +
+ * x^5 + x^4 + x^2 + x + 1
+ */
+const guint32 crc32_ccitt_table[256] = {
+0x, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419,
+0x706af48f, 0xe963a535, 0x9e6495a3, 0x0edb8832, 0x79dcb8a4,
+0xe0d5e91e, 0x97d2d988, 0x09b64c2b, 0x7eb17cbd, 0xe7b82d07,
+0x90bf1d91, 0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de,
+0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7, 0x136c9856,
+0x646ba8c0, 0xfd62f97a, 0x8a65c9ec, 0x14015c4f, 0x63066cd9,
+0xfa0f3d63, 0x8d080df5, 0x3b6e20c8, 0x4c69105e, 0xd56041e4,
+0xa2677172, 0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,
+0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940, 0x32d86ce3,
+0x45df5c75, 0xdcd60dcf, 0xabd13d59, 0x26d930ac, 0x51de003a,
+0xc8d75180, 0xbfd06116, 0x21b4f4b5, 0x56b3c423, 0xcfba9599,
+0xb8bda50f, 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
+0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d, 0x76dc4190,
+0x01db7106, 0x98d220bc, 0xefd5102a, 0x71b18589, 0x06b6b51f,
+0x9fbfe4a5, 0xe8b8d433, 0x7807c9a2, 0x0f00f934, 0x9609a88e,
+0xe10e9818, 0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,
+0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e, 0x6c0695ed,
+0x1b01a57b, 0x8208f4c1, 0xf50fc457, 0x65b0d9c6, 0x12b7e950,
+0x8bbeb8ea, 0xfcb9887c, 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3,
+0xfbd44c65, 0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2,
+0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb, 0x4369e96a,
+0x346ed9fc, 0xad678846, 0xda60b8d0, 0x44042d73, 0x33031de5,
+0xaa0a4c5f, 0xdd0d7cc9, 0x5005713c, 0x270241aa, 0xbe0b1010,
+0xc90c2086, 0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
+0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4, 0x59b33d17,
+0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad, 0xedb88320, 0x9abfb3b6,
+0x03b6e20c, 0x74b1d29a, 0xead54739, 0x9dd277af, 0x04db2615,
+0x73dc1683, 0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8,
+0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1, 0xf00f9344,
+0x8708a3d2, 0x1e01f268, 0x6906c2fe, 0xf762575d, 0x806567cb,
+0x196c3671, 0x6e6b06e7, 0xfed41b76, 0x89d32be0, 0x10da7a5a,
+0x67dd4acc, 0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,
+0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252, 0xd1bb67f1,
+0xa6bc5767, 0x3fb506dd, 0x48b2364b, 0xd80d2bda, 0xaf0a1b4c,
+0x36034af6, 0x41047a60, 0xdf60efc3, 0xa867df55, 0x316e8eef,
+0x4669be79, 0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
+0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f, 0xc5ba3bbe,
+0xb2bd0b28, 0x2bb45a92, 0x5cb36a04, 0xc2d7ffa7, 0xb5d0cf31,
+0x2cd99e8b, 0x5bdeae1d, 0x9b64c2b0, 0xec63f226, 0x756aa39c,
+0x026d930a, 0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713,
+0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38, 0x92d28e9b,
+0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21, 0x86d3d2d4, 0xf1d4e242,
+0x68ddb3f8, 0x1fda836e, 0x81be16cd, 0xf6b9265b, 0x6fb077e1,
+0x18b74777, 0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c,
+0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45, 0xa00ae278,
+0xd70dd2ee, 0x4e048354, 0x3903b3c2, 0xa7672661, 0xd06016f7,
+0x4969474d, 0x3e6e77db, 0xaed16a4a,
[Qemu-devel] Re: Re: Atheros Wireless Device Emulation
On Friday 29 February 2008 19:22:53 Sylvain Petreolle wrote: Look at pci.c.rej. Because of the lines of the recent e1000 pci card inclusion, patch refuses to apply it. Its just a matter of resynch... Now I got it ;-) This one (http://stud4.tuwien.ac.at/~e0126605/qemu_atheros/atheros_wlan.patch) is for the current CVS version. Do we have writing access to the CVS?? Since I doubt it, could someone apply the patch (in case you think it is good enough ;-) ) Some more infos on the wlan emulation: - if you cannot connect to the router (happens to me sometimes with windows guests), simply cancel connecting and retry - i experienced problems when getting a dynamic ip from qemu (dhcp) when using multiple NICs. Simply disable all other NICs and it always worked for me or use static IPs. - Inbound connections still buggy - Still does not work with current CVS of Madwifi drivers. Use MadWifi 0.9.3 (and don't forget to use the _linux_ model type as explained in previous posts) - I just tried the patch and got a qemu: fatal: triple fault ... i restarted qemu and everything worked fine. either there is still a major bug in my code, or the snapshots inside my image were a little messed up. Have fun with the code ;-) --Clemens
[Qemu-devel] Re: Qemu-devel Digest, Vol 59, Issue 88
On Friday 29 February 2008 19:22:53 Sylvain Petreolle wrote: Look at pci.c.rej. Because of the lines of the recent e1000 pci card inclusion, patch refuses to apply it. Its just a matter of resynch... ok thanks. will take a look at it!
[Qemu-devel] Re: Atheros Wireless Device Emulation
On Thursday 28 February 2008 15:12:20 [EMAIL PROTECTED] wrote: Atheros Wireless Device Emulation Hm... seems attachments don't go too well. Since it is a 9.500 LOC patch, I put here for download: http://stud4.tuwien.ac.at/~e0126605/qemu_atheros/atheros_wlan.patch Cheers
Re: [Qemu-devel] performance monitor
On Friday 04 January 2008 09:49:22 Rob Landley wrote: On Thursday 03 January 2008 15:38:02 Clemens Kolbitsch wrote: Does anyone have an idea on how I can measure performance in qemu to a somewhat accurate level? hwclock --show time1 tar xvjf linux-2.6.23.tar.bz2 cd linux-2.6.23 make allnoconfig make cd .. hwclock --show time2 Do that on host and client, and you've got a ratio of the performance of qemu to your host that should be good to within a few percent. I have modified qemu (the memory handling) and the linux kernel and want to find out the penalty this introduced... does anyone have any comments / ideas on this? If it's something big, you can compare the result in minutes and seconds. That's probably the best you're going to do. (Although really you want hwclock --show before and after, and then do the math. That tunnels out to the host system to get its idea of the time, which doesn't get thrown off by timer interrupt delivery (as a signal) getting deferred by the host system's scheduler. Of course the fact that hwclock _takes_ a second or so to read the clock is a bit of a downer, but anything that takes less than a minute or so to run isn't going to give you a very accurate time because the performance of qemu isn't constant, and your results are going to skew all over the place. Especially for small things, the performance varies from run to run. Start by imagining qemu as having the mother of all page fault latencies. The cost of faulting code into the L2 cache includes dynamic recompilation, which is expensive. Worse, when the dynamic recompilation buffer fills up it blanks the whole thing, and recompiles every new page it hits one at a time until the buffer fills up again. (What is it these days, 16 megs of translated code before it resets?) No LRU or anything, no cache management at _all_, just when the bucket fills up, dump it and start over. (Well, that's what it did back around the last stable release anyway. It has been almost a year since then, so maybe it's changed. I've been busy with other things and not really keeping track of changes that didn't affect what I could and couldn't get to run.) So anyway, depending on what code you run in what order, the performance can _differ_ from one run to the next due to when the cache gets blanked and stuff gets retranslated. By a lot. There's no obvious way to predict this or control it. And the software clock inside your emulated system can lie to you about it if timer interrupts get deferred. All this should pretty much average out if you do something big with lots of execs (like build a linux kernel from source). But if you do something small expect serious butterfly effects. Expect microbenchmarks to swing around wildly. Quick analogy: you know the performance difference faulting your executable in from disk vs running it out of cache? Imagine a daemon that makes random intermittent calls to echo 1 /proc/sys/vm/drop_caches, and now try to do a sane benchmark. No matter what you use to measure, what you're measuring isn't going to be consistent from one run to the next. Performance should be better (and more stable) with kqemu or kvm. Maybe that you can benchmark sanely, I wouldn't know. Ask somebody else. :) P.S. Take the above with a large grain of salt, I'm not close to an expert in this area... :-) Ok. What you've said pretty much covers how I've made up my mind in the last couple of hours trying to think about the problem *g* Guess I'll have to be happy counting TLB misses and page faults, adding up executed instructions (in user/kernel mode) per process and doing some timing stuff... then running the examples a lot of times, making an average of all numbers and finally just ignoring them since I *know* that they are bogus ;-) No, seriously... I understand the problem, but I think the above is the best I can do since I'm really only interested in the effekt it has on QEMU for the moment :-) Thanks again for your ideas!!
[Qemu-devel] performance monitor
hi! has anyone ever used some real performance monitoring tools (like papiex, perfex, pfmon, etc.) on qemu? i'm running a debian linux and would like to time some applications inside qemu and have tried the perfmon2 kernel-patch (http://perfmon2.sourceforge.net/) for testing. sadly, it does not work... dmesg tells me that the CPU is not identified correctly (unsupported family=6). Now i am not really sure what type of hardware-support the monitor relies on (i think PMU is the correct term, but I'm not sure about that) and what CPUs are supported (dmesg tells me that qemu simulates a Pentium M, but that's probably because I've compiled the kernel on my *real* Pentium M). ... Ok, to cut a long question short: Is there any hardware support im qemu for doing monitoring (that goes deeper than using time) and has anyone ever tested something that could work? Thanks! Clemens
Re: [Qemu-devel] performance monitor
On Thursday 03 January 2008 22:29:06 Paul Brook wrote: ... Ok, to cut a long question short: Is there any hardware support im qemu for doing monitoring (that goes deeper than using time) and has anyone ever tested something that could work? Probably your application wants the performance counters. Qemu doesn't emulate those. Besides which, qemu is not cycle accurate. Any performance measurements your make are pretty much meaningless, and bear absolutely no relationship to real hardware. Thanks for the quick answer Paul! Not really what I wanted to hear, but probably true ;-) Does anyone have an idea on how I can measure performance in qemu to a somewhat accurate level? I have modified qemu (the memory handling) and the linux kernel and want to find out the penalty this introduced... does anyone have any comments / ideas on this? Thanks!
Re: [Qemu-devel] performance monitor
On Thursday 03 January 2008 23:07:07 you wrote: Does anyone have an idea on how I can measure performance in qemu to a somewhat accurate level? I have modified qemu (the memory handling) and the linux kernel and want to find out the penalty this introduced... does anyone have any comments / ideas on this? Short answer is you probably can't. And even if you can I won't believe tyour results unless you've verified them on real hardware :-) With the exception of some very small embedded cores, Modern CPUs have complex out of order execution pipelines and multi-level cache hierarchies. It's common for performance to be dominated by these secondary factors rather than raw instruction throughput. Exactly what features dominate performance is very application specific. Determining which factor dominates is unlikely to be something qemu can help with. However if e.g. you know that for your application there's a good correlation was between performance and L2 cache misses you could instrument qemu to and a L1/L2 cache model. The overhead will be fairly severe (easily 10x slower), and completely screw up any realtime measurements. However it would produce some useful cache use statistics that you could use to guesstimate actual performance. This is similar to how cachegrind works. Obviously if your application isn't cache bound then these figures will be meaningless. Well, the measuring I had in mind partly concentrats on TLB misses, page faults, etc. (in addition to the cycle measuring). guess i'll have to implement something for myself in qemu :-/ But thanks a lot for helping me out!
Re: [Qemu-devel] performance monitor
On Thursday 03 January 2008 23:18:58 Paul Brook wrote: Well, the measuring I had in mind partly concentrats on TLB misses, page faults, etc. (in addition to the cycle measuring). guess i'll have to implement something for myself in qemu :-/ Be aware that the TLB qemu uses behaves very differently to a real CPU TLB. If you want to get TLB miss statistics you'll need to model a real TLB for that separately. Sure, yes. But I don't even care what it would be like on a real CPU. I just want to know the impact it has on the emulated CPU ;-) Page faults should be straightforward, but any half-decent guest OS would be able to tell you those anyway. True *g*
Re:[Qemu-devel] Kernel panic - not syncing: No init found. Trypassing init= option to kernel.
On Friday 19 October 2007 09:13:40 [EMAIL PROTECTED] wrote: Then I try this command: qemu -m 32 hda rootfs.img kernel linux-2.6.18.1/arch/i386/boot/bzImage -append “root=/dev/hda \clock=pit” and I get the error... I tried to pass init=/sbin/init or init=/bin/init but it doesn't help... Hi! Although allmost every documentation tells you to use exactly what you did, I always use qemu [] -append root=/dev/hda1 (note HDA1 instead HDA) and direct booting works fine for me :-) Clemens
Re: RE: [Qemu-devel] Kernel panic - not syncing: No init found.
are you passing an initrd to qemu? i call qemu like this: qemu \ -hda image \ -boot c \ -net user \ -net nic,vlan=0,model=rtl8139 \ -initrd initrd \ -append root=/dev/hda1 \ -kernel kernel \ -no-kqemu whereas kernel is a link to the bzImage and initrd links to a file i have created inside qemu using mkinitramfs Clemens On Friday 19 October 2007 10:54:58 [EMAIL PROTECTED] wrote: If I do this I got a VFS problem Not syncing: VFS: Unable to mount root fs on unknown-block(3,1.) I also tried to enable reiserfs support. I read on a forum that this may be a solution to the init problem. In my case it wasn't a working solution. From: [EMAIL PROTECTED] To: qemu-devel@nongnu.org; [EMAIL PROTECTED] Subject: Re:[Qemu-devel] Kernel panic - not syncing: No init found. Trypassinginit= option to kernel. Date: Fri, 19 Oct 2007 09:19:59 +0200 CC: On Friday 19 October 2007 09:13:40 [EMAIL PROTECTED] wrote: Then I try this command: qemu -m 32 hda rootfs.img kernel linux-2.6.18.1/arch/i386/boot/bzImage -append “root=/dev/hda \clock=pit” and I get the error... I tried to pass init=/sbin/init or init=/bin/init but it doesn't help... Hi! Although allmost every documentation tells you to use exactly what you did, I always use qemu [] -append root=/dev/hda1 (note HDA1 instead HDA) and direct booting works fine for me :-) Clemens
[Qemu-devel] i386 page fault recovery / user-code continuation
hi everyone! I have a question concerning how i386 execution is continued after a page fault has occured... What I have understood so far: In the executing TB the TLB is checked and if the address is not found __ld (e.g. __ldl_user) is called. this calls lb_fill (if it really has to) which in turns asks cpu_x86_handle_mmu_fault if it is really a page fault or just a TLB miss... if it is a fault however, tb_find_pc finds the TB and its last assembler instruction and uses raise_exception_err to jump to the main-loop and handle the fault there --- I hope this is correct so far :-) My question now: where does the execution continue after the fault has been handled? the saved assembler-instruction is the instruction AFTER call __ldl_user , what does not really make sense to jump back to... Does cpu_restore_state find out what the last executing, translated op-code was, restores that and continues at the BEGINNING of that op-code TB?? If someone could help me out on this, it'd be really appreciated ;-) Thanks!!!
[Qemu-devel] CPU_TLB_BITS / CPU_TLB_SIZE
hi everyone! if i want to increase the size of my TLB (for emulating an i386 processor), is it enough to simply increase CPU_TLB_BITS (e.g. by one)?? Or are there any side effects to that I should be aware of? Thanks!
Re: [Qemu-devel] CPU_TLB_BITS / CPU_TLB_SIZE
On Thursday 04 October 2007 15:05:22 Thiemo Seufer wrote: Clemens Kolbitsch wrote: hi everyone! if i want to increase the size of my TLB (for emulating an i386 processor), is it enough to simply increase CPU_TLB_BITS (e.g. by one)?? IIRC CPU_TLB_BITS needs to be a 2^n value. sure that you don't confuse that with CPU_TLB_SIZE? CPU_TLB_SIZE will always be a 2^n value because of its definition #define CPU_TLB_SIZE (1 CPU_TLB_BITS) but honestly, I don't know (that's why i asked in the first place ;-) ) can someone back up thiemo's opinion? (or can you give me a hint on where this constraint is necessary?) thanks!!
[Qemu-devel] using pthread in qemu
hi! i know... i have been told not to use them, but i just HAVE TO for the moment :-( i need to run a second thread inside my hardware module which is not a problem as long as i don't use the qcow2 image format. when i switch to qcow2, qemu's main thread hangs because the second thread is waiting for a semaphore... does anyone know how to tell the second pthread not to block the primary thread?? as always --- any help is greatly appreciated!! Clemens
[Qemu-devel] Re: using pthread in qemu
On Wednesday 03 October 2007 13:04:33 you wrote: hi! i know... i have been told not to use them, but i just HAVE TO for the moment :-( i need to run a second thread inside my hardware module which is not a problem as long as i don't use the qcow2 image format. when i switch to qcow2, qemu's main thread hangs because the second thread is waiting for a semaphore... does anyone know how to tell the second pthread not to block the primary thread?? as always --- any help is greatly appreciated!! Clemens ok... i solved my problem using the qemu_timers works just fine ;-)
[Qemu-devel] softmmu_header: ldb_kernel vs. ldsb_kernel
hi everyone! i have a (maybe rather tricky) question: why do you define 2 different inline load-functions in softmmu_header: static inline int glue(glue(lds, SUFFIX), MEMSUFFIX)(target_ulong ptr) vs. static inline RES_TYPE glue(glue(ld, USUFFIX), MEMSUFFIX)(target_ulong ptr) ?? Obviously this is for signed/unsigned access... but why do you need it? In case there is a TLB miss, both functions call the same function (e.g. __ldl_mmu) -- the return value cannot differ that much. The only difference I see (that really matters) is how the bytes are copied to the result-pointer (i.e. using movzbl vs. movsbl)... but that's it. If there is some deeper reason behind that - could you please point that out to me? And if there is such a thing, why is it not necessary for storing (e.g. stb_kernel)?? Thanks!! Clemens
[Qemu-devel] qcow2 vs. image file format -- pci device
hi everyone! i have a strange problem (at least to me it seems strange :-) ): i have implemented a pci device (Network IC) and it works just fine when using a standard image. however i now want to support snapshotting... i started to convert my image into the qcow2 format and suddenly my code does not work any more... even if i uncomment everything that has to do with snapshotting in my code, it still blocks during qemu startup. the thing that could cause this: i use 2 additional threads in my NIC code ... each is working with semaphores that might cause problems. is there something in particular i have to be careful of when using qcow2 file format? thanks!!
Re: Re: [Qemu-devel] softmmu macro meaning
On Thursday 27 September 2007 16:01:08 [EMAIL PROTECTED] wrote: does the MEMSUFFIX macro (kernel / user) mean that the memory is access by code running in ring0/ring3 or does this tell about the memory region being access (mem or TASK_SIZE / 0xc000)? The former. ok :-) and while I'm asking two other related questions I just don't quite understand: 1.) why does the TLB (e.g. tlb_table[CPU_MEM_INDEX][...]) have 2 different arrays? is this because some CPU offer different page sizes depending on a TASK_SIZE border or something?? It makes more sense if you realize it's kernel/user mode not address space. ok... so it's really 1 for user-mode and 1 for kernel-mode... but will kernel mode always use the TLB[0] for address translation (even for addresses at e.g. 0x0800) and user mode TLB[1] (even for e.g. 0xc000abcd)? (or the other way round...) 2.) the MMUSUFFIX macro (mmu / cmmu) what does this stand for?? cmmu is used to read code to execute, IIRC (different permissions). ok, thanks!!
Re: [Qemu-devel] softmmu macro meaning
On Thursday 27 September 2007 17:27:32 Daniel Jacobowitz wrote: On Thu, Sep 27, 2007 at 05:02:46PM +0200, Clemens Kolbitsch wrote: but will kernel mode always use the TLB[0] for address translation (even for addresses at e.g. 0x0800) and user mode TLB[1] (even for e.g. 0xc000abcd)? (or the other way round...) Which set of TLBs are used depends completely on the current processor mode. It has nothing to do with the address. ok perfect :-) thanks!!
[Qemu-devel] Serial Console / NoGraphic
hi! i've been trying around for quite some time now trying to start qemu without the graphic screen... can someone tell me exactly what I'm supposed to do?? i want to redirect the output of my i386 debian linux to my host-console (also a i386 debian) to fully see the output of a kernel panic (see previous messages i have posted). i'm starting qemu: qemu -hda myimage -boot c -kernel-kqemu -kernel mykernel -initrd myinitrd -append root=/dev/hda1 console=/dev/ttyS0 -nographic after tons of trial-and-error i finally got my system to boot, however, the login-screen is not displayed (i see all output of the starting system up until the login:). how do i connect to the serial line now to get to the login?? i have tried minicom, however that seems to just hang :-( should i use (tell qemu to use) a different virtual serial console?? how to i start minicom correctly?? could you give me the parameter set you guys are using for 1.) qemu 2.) connector (minicom???) 3.) what i have to enable inside my guest-system (i have checked that /etc/securetty include ttyS0 already) any help will - as always - be greatly appreciated!! thanks :-)
[Qemu-devel] Re: Serial Console / NoGraphic
On Tuesday 25 September 2007 12:04:17 Clemens Kolbitsch wrote: hi! i've been trying around for quite some time now trying to start qemu without the graphic screen... can someone tell me exactly what I'm supposed to do?? i want to redirect the output of my i386 debian linux to my host-console (also a i386 debian) to fully see the output of a kernel panic (see previous messages i have posted). i'm starting qemu: qemu -hda myimage -boot c -kernel-kqemu -kernel mykernel -initrd myinitrd -append root=/dev/hda1 console=/dev/ttyS0 -nographic after tons of trial-and-error i finally got my system to boot, however, the login-screen is not displayed (i see all output of the starting system up until the login:). how do i connect to the serial line now to get to the login?? i have tried minicom, however that seems to just hang :-( should i use (tell qemu to use) a different virtual serial console?? how to i start minicom correctly?? could you give me the parameter set you guys are using for 1.) qemu 2.) connector (minicom???) 3.) what i have to enable inside my guest-system (i have checked that /etc/securetty include ttyS0 already) any help will - as always - be greatly appreciated!! thanks :-) hi! i finally found out that it was all just a configuration problem inside my guest :-) for anyone having the same problem: qemu myimage -serial stdio -nographic is totally sufficient as long as you tell linux to start getty listening on a serial console (make sure that GRUB tells your kernel to include console=/dev/ttyS0). in my case (a newer debian system) this was adding a file to /etc/event.d/ called ttyS0 containing the line /sbin/getty -L /dev/ttyS0 38400 vt100 maybe it helps someone :-)
Re: [Qemu-devel] Publicating with QEMU
On Thursday 20 September 2007 16:08:51 Thiemo Seufer wrote: Clemens Kolbitsch wrote: Hi guys! Short question: I'm having a speech at BlackHat Japan in Oktober about something I made with qemu. Basically it is a new hardware type (so it is just an additional file in the hw-subdirectory) --- it's the wireless device I have been asking questions for a couple of months ago in case someone remembers (there will be some code for you guys soon ;-) ). For the conference CD, they want me to give them my code. Is it ok if i just send them the whole qemu code I have here (I have only modified the Makefile to include my hw/myfile.c) --- i just want to make sure that the version is right and it compiles out of the box. As a general note, if you have modifications which are useful to a wider audience, consider to submit them as patches to this mailing list. Is that OK with the GPL stuff?? I include all the READMEs that come with QEMU svn, and I don't claim to be the author of QEMU or anything. Just want to do it correctly ;-) Yes, that's fine. (You can check for yourself, the GPL isn't as incomprehensible as some other software licenses.) Any advice, comments, etc.? Make sure to mark your version as a modified one, so people come to you when they have questions, and don't ask us about bugs/features we never heard of. :-) Thiemo perfect -- thanks! once we get all the publication stuff behind us, you'll hear from us -- promised :-) to turn our code into a standard network card shouldn't be too much of work and it's acually quite cool to have a wireless network inside qemu. doesn't help much besides increasing the coolness factor, though ;-) bye
[Qemu-devel] Publicating with QEMU
Hi guys! Short question: I'm having a speech at BlackHat Japan in Oktober about something I made with qemu. Basically it is a new hardware type (so it is just an additional file in the hw-subdirectory) --- it's the wireless device I have been asking questions for a couple of months ago in case someone remembers (there will be some code for you guys soon ;-) ). For the conference CD, they want me to give them my code. Is it ok if i just send them the whole qemu code I have here (I have only modified the Makefile to include my hw/myfile.c) --- i just want to make sure that the version is right and it compiles out of the box. Is that OK with the GPL stuff?? I include all the READMEs that come with QEMU svn, and I don't claim to be the author of QEMU or anything. Just want to do it correctly ;-) Any advice, comments, etc.? Thanks!
[Qemu-devel] Re: SoftMMU address tracing
hi! finally found out why it did not work ... the problem was kqemu after all. after compiling qemu with kqemu-support disabled, the address translation/access worked as expected :-) is there a good documentation/technical paper online that could help me understand how address handling is done using kqemu? thanks!! hi! ah... i'm going crazy... could someone help me please: i'm still (as previously posted on irc) trying to catch when the guest OS (or a program running in it) accesses a certain virtual address (e.g. reads from it). my guest code is something like: ... unsigned long *p = (unsigned long*)0xdeadbeef; unsigned long l = *p; ... now, i know it is compiled into something like this: ... movl $0xdeadbeef,0xfff8(%ebp) mov 0xfff8(%ebp),%eax mov (%eax),%eax ... what will be translated by qemu into something like ... movl_A0_EAX ldl_kernel_T0_A0 movl_EAX_T0 ... I hope that that's correct up to here (i'm not quite sure about the ldl_kernel as it could also be ldl_user!!). but... as ldl_(kernel|user)_T0_A0 simply calls the ld-functions in softmmu_header i inserted a line into these functions that simply dumps out the currently accessed address (i.e. the parameter ptr) to stdout. i run qemu and grep for my deadbeef output, but it NEVER occurs!! how can that be?? I've been trying for hours now, could someone please help me here?? don't know if that makes a difference but i've tried using -kernel-kqemu and also without kqemu. any help is greatly appreciated ... thanks!!
[Qemu-devel] SoftMMU address tracing
hi! ah... i'm going crazy... could someone help me please: i'm still (as previously posted on irc) trying to catch when the guest OS (or a program running in it) accesses a certain virtual address (e.g. reads from it). my guest code is something like: ... unsigned long *p = (unsigned long*)0xdeadbeef; unsigned long l = *p; ... now, i know it is compiled into something like this: ... movl $0xdeadbeef,0xfff8(%ebp) mov 0xfff8(%ebp),%eax mov (%eax),%eax ... what will be translated by qemu into something like ... movl_A0_EAX ldl_kernel_T0_A0 movl_EAX_T0 ... I hope that that's correct up to here (i'm not quite sure about the ldl_kernel as it could also be ldl_user!!). but... as ldl_(kernel|user)_T0_A0 simply calls the ld-functions in softmmu_header i inserted a line into these functions that simply dumps out the currently accessed address (i.e. the parameter ptr) to stdout. i run qemu and grep for my deadbeef output, but it NEVER occurs!! how can that be?? I've been trying for hours now, could someone please help me here?? don't know if that makes a difference but i've tried using -kernel-kqemu and also without kqemu. any help is greatly appreciated ... thanks!!
Re: Re: [Qemu-devel] Linux KDE vs. Windows
Am 24.07.2007 um 15:32 schrieb Clemens Kolbitsch: i'm emulating i386 (what else when using windows *g*) [...] just in case someone knows :-) As far as I recall, in chronological order: alpha, ia64, amd64. ;-) ok.. ok ... my fault ;-)
[Qemu-devel] softMMU / MOV translation
hi! i tried asking this in the irc but got no answer, hope someone can help me here :-) i'm working on memory-protection for my mather's thesis and have to dig into qemu memory management... could someone help me here please? i have the following problem: i'm trying to understand the dynamic translation for the following mov-opcode (it's taken from the qemu log with log asm_in,asm_out): IN: 0xc011c9f2: mov0x60(%esi),%edx the hex-code would be 0x8b 0x56 0x60 ... OUT: OUT: [size=455] 0x08d30fa0: mov0x18(%ebp),%edi 0x08d30fa3: add$0x60,%edi 0x08d30fa9: mov%edi,%edx 0x08d30fab: mov%edi,%eax 0x08d30fad: shr$0x8,%edx 0x08d30fb0: and$0xf003,%eax 0x08d30fb5: and$0xff0,%edx 0x08d30fbb: lea0x350(%edx,%ebp,1),%edx 0x08d30fc2: cmp(%edx),%eax 0x08d30fc4: mov%edi,%eax 0x08d30fc6: je 0x8d30fd4 0x08d30fc8: push $0x0 0x08d30fca: call 0x80ee06a // __ldl_mmu 0x08d30fcf: pop%edx 0x08d30fd0: mov%eax,%ebx 0x08d30fd2: jmp0x8d30fd9 0x08d30fd4: add0xc(%edx),%eax 0x08d30fd7: mov(%eax),%ebx // possibly the output of gen_op_ld_T0_A0 [ot]+ s-mem_index](); 0x08d30fd9: mov%ebx,0x8(%ebp) // this is the output of gen_op_mov_reg_T0 [ot][reg](); (translate.c:4005) ... therefore, i think the following code in translate.c should be executed: case 0x8b: /* mov Ev, Gv */ if ((b 1) == 0) ot = OT_BYTE; else ot = OT_WORD + dflag; modrm = ldub_code(s-pc++); reg = ((modrm 3) 7) | rex_r; gen_ldst_modrm(s, modrm, ot, OR_TMP0, 0); gen_op_mov_reg_T0[ot][reg](); break; i debugged some time and found out that the last gen_op gen_op_mov_reg_T0[ot][reg](); only produces mov%ebx,0x8(%ebp). thus, the rest of the OUT-codes is produced by gen_ldst_modrm(s, modrm, ot, OR_TMP0, 0); however, i tried reading through the code but i could not find the function where 0x08d30fca: call 0x80ee06a // __ldl_mmu is inserted into the translation-buffer... i (think to) know why it must be inserted, but i just cannot figure out where it is put into the buffer. if someone could point that out, it would help me a LOT! thanks, Clemens
[Qemu-devel] Re: softMMU / MOV translation
i think to have found it in translate.c:
/* sign does not matter, except for lidt/lgdt call (TODO: fix it) */
static GenOpFunc *gen_op_ld_T0_A0[3 * 4] = {
gen_op_ldub_raw_T0_A0,
gen_op_lduw_raw_T0_A0,
gen_op_ldl_raw_T0_A0,
X86_64_ONLY(gen_op_ldq_raw_T0_A0),
#ifndef CONFIG_USER_ONLY
gen_op_ldub_kernel_T0_A0,
gen_op_lduw_kernel_T0_A0,
gen_op_ldl_kernel_T0_A0,
X86_64_ONLY(gen_op_ldq_kernel_T0_A0),
gen_op_ldub_user_T0_A0,
gen_op_lduw_user_T0_A0,
gen_op_ldl_user_T0_A0,
X86_64_ONLY(gen_op_ldq_user_T0_A0),
#endif
};
gen_op_ldl_kernel_T0_A0
looks quite promising. however, i still have not found the code (e.g. in op.c)
that actually includes the call opcode (i find it in the disassembled code
of the qemu-binary, though).
is it generated somehow by gcc? the only thing that looks similar are the
ld-functions in softmmu_header:
static inline RES_TYPE glue(glue(ld, USUFFIX), MEMSUFFIX)(target_ulong ptr)
however, if i understand the macro-defs right, these functions are not
built...
maybe someone could point that out?
On Wednesday 25 July 2007 02:04:47 pm you wrote:
hi!
i tried asking this in the irc but got no answer, hope someone can help me
here :-)
i'm working on memory-protection for my mather's thesis and have to dig
into qemu memory management... could someone help me here please? i have
the following problem:
i'm trying to understand the dynamic translation for the following
mov-opcode (it's taken from the qemu log with log asm_in,asm_out):
IN:
0xc011c9f2: mov0x60(%esi),%edx
the hex-code would be 0x8b 0x56 0x60
...
OUT:
OUT: [size=455]
0x08d30fa0: mov0x18(%ebp),%edi
0x08d30fa3: add$0x60,%edi
0x08d30fa9: mov%edi,%edx
0x08d30fab: mov%edi,%eax
0x08d30fad: shr$0x8,%edx
0x08d30fb0: and$0xf003,%eax
0x08d30fb5: and$0xff0,%edx
0x08d30fbb: lea0x350(%edx,%ebp,1),%edx
0x08d30fc2: cmp(%edx),%eax
0x08d30fc4: mov%edi,%eax
0x08d30fc6: je 0x8d30fd4
0x08d30fc8: push $0x0
0x08d30fca: call 0x80ee06a // __ldl_mmu
0x08d30fcf: pop%edx
0x08d30fd0: mov%eax,%ebx
0x08d30fd2: jmp0x8d30fd9
0x08d30fd4: add0xc(%edx),%eax
0x08d30fd7: mov(%eax),%ebx // possibly the output of
gen_op_ld_T0_A0
[ot]+ s-mem_index]();
0x08d30fd9: mov%ebx,0x8(%ebp)// this is the output of
gen_op_mov_reg_T0 [ot][reg](); (translate.c:4005)
...
therefore, i think the following code in translate.c should be executed:
case 0x8b: /* mov Ev, Gv */
if ((b 1) == 0)
ot = OT_BYTE;
else
ot = OT_WORD + dflag;
modrm = ldub_code(s-pc++);
reg = ((modrm 3) 7) | rex_r;
gen_ldst_modrm(s, modrm, ot, OR_TMP0, 0);
gen_op_mov_reg_T0[ot][reg]();
break;
i debugged some time and found out that the last gen_op
gen_op_mov_reg_T0[ot][reg]();
only produces
mov%ebx,0x8(%ebp).
thus, the rest of the OUT-codes is produced by
gen_ldst_modrm(s, modrm, ot, OR_TMP0, 0);
however, i tried reading through the code but i could not find the function
where
0x08d30fca: call 0x80ee06a // __ldl_mmu
is inserted into the translation-buffer... i (think to) know why it must be
inserted, but i just cannot figure out where it is put into the buffer.
if someone could point that out, it would help me a LOT!
thanks,
Clemens
[Qemu-devel] Re: Re: softMMU / MOV translation
found the functions in target-xxx/ops_mem.h the macros confused my grepping, but how much more self-speaking can a filename be *gg* ?? oh well... i found it :-)
Re: Re: [Qemu-devel] softMMU / MOV translation
Hi Clemens, if you enable log asm_in,op,op_opt,asm_out you will see the intermediate code used during translation. The opcodes are generated from the macros you already found in softmmu_header.h by target-i386/ops_mem.h included from target-i386/op.c Hope this helps, Eddie well... you probably saw that i already found it :-) -- and i did exactly this to find it *g* thanks anyways!!
[Qemu-devel] Linux KDE vs. Windows
hi! i've got a questions... just out of curiosity: when emulating windows xp, i get quite good speeds. however, when running linux, i can only work with it when turning off kde... it is WAY too slow. is there a known reason for that / does anyone know what i could be doing wrong? i'm emulating i386 (what else when using windows *g*) on a i386 using kqemu, newest version of qemu... just in case someone knows :-) greets, Clemens
Re: Re: [Qemu-devel] Linux KDE vs. Windows
hi christian, thanks for the reply... looks like a good explanation *gg* ... why didn't i try that before posting (haven't done it yet, but looks reasonable :-) )?? greets! allocate more ram to your qemu guest it's the -m switch. Default is 128M, way too low for KDE. Try first 192, 256, and then 512 if you can afford it. On 7/24/07, Clemens Kolbitsch [EMAIL PROTECTED] wrote: hi! i've got a questions... just out of curiosity: when emulating windows xp, i get quite good speeds. however, when running linux, i can only work with it when turning off kde... it is WAY too slow. is there a known reason for that / does anyone know what i could be doing wrong? i'm emulating i386 (what else when using windows *g*) on a i386 using kqemu, newest version of qemu... just in case someone knows :-) greets, Clemens
[Qemu-devel] Re: sidt problem
hi!
just wanted to post that i found out what is really the problem...
obviously this is one of the restrictions in a virtual machine and thus
not a bug (as most of you probably know already).
it'd still be cool if it could be fixed somehow... though this seems
more of an academic thing than a programmer's job :-)
greets!
Clemens Kolbitsch wrote:
hi everyone!
i have a strange problem:
i use the following code on my linux 2.6.20 (kubuntu debian, i386) to
dynamically get the location of the system-call table (as can also be
found in /proc/kallsyms -- sys_call_table) as it is quite
interesting for new exploits ( :-) )
on a real cpu this works fine, however crashes in qemu... obviously
there is a bug somewhere. i have not found my way that deep into the
qemu source, so i cannot really help to find the bug.
well, here is the code:
struct
{
unsigned short limit;
unsigned int base;
} __attribute__ ((packed)) idtr;
struct
{
unsigned short off1;
unsigned short sel;
unsigned char none, flags;
unsigned short off2;
} __attribute__ ((packed)) *igd;
unsigned long *sys_call;
unsigned char *pc;
// find idt_table
__asm__(sidt %0 : :m(idtr));
// find system_call
igd = idtr.base + 8 * 0x80;
// !!!
// the next line crashes
// !!!
sys_call = (igd-off2 16) | igd-off1;
// find sys_call_table
// ff 14 85 XX XX XX XX call sys_call_table(,%eax,4)
sys_call_table = 0x0;
pc = (char*)sys_call;
// check the first 100 bytes in system_call
for (i = 0; i 100; ++i)
{
if ((*(long*)++pc 8) == 0x8514ff00)
{
sys_call_table = *(long*)(pc+3);
break;
}
}
maybe, someone has time to look at this problem (by the way, i use the
same system inside qemu as on my laptop)
greets!!
[Qemu-devel] Debugging guest OS / tracing instruction pointer
hi! i'm looking for a way to monitor the eip register. is there a simple way to do this? i know that that produces tons of data... even better would be to know where i could intercept the main-loop (exec_cpu ??) to check for a certain eip value... could someone assist me doing that? thanks!
Re: [Qemu-devel] Debugging guest OS / tracing instruction pointer
Paul Brook wrote: On Thursday 14 June 2007, Clemens Kolbitsch wrote: hi! i'm looking for a way to monitor the eip register. is there a simple way to do this? i know that that produces tons of data... even better would be to know where i could intercept the main-loop (exec_cpu ??) to check for a certain eip value... qemu already has mechanisms for supporting debugger breakpoints. Sounds like you want something very similar. Paul the thing is: i want to monitor the eip... or where the code will jump NEXT. the code there is never executed (as it results in a kernel failure) e.g. i know a buffer overflow will set the return-pointer to 0xABCD and ret is executed i want the breakpoint to hit when using casual breakpoints, i think the code there must be executed (i.e. the jump must be successful .. what will definitely not be the case with 0xABCD) thanks!
[Qemu-devel] Detecting Client OS BSOF/Kernel Oops
Hi! I'd like to detect if the client OS crashes... right now, only for linux, but windows systems will become interesting for me as well in the future... Is there an easy way of detecting if a BSOD or a kernel oops happened?? Maybe that'd be possible by checking if the IP is inside a certain range (I could find that location, I think... it does not have to be working generically... for specific client OS would be sufficient)!! Thanks!
[Qemu-devel] Re: Qemu-devel Digest, Vol 50, Issue 70
[EMAIL PROTECTED] wrote: Send Qemu-devel mailing list submissions to qemu-devel@nongnu.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.nongnu.org/mailman/listinfo/qemu-devel or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of Qemu-devel digest... Today's Topics: 1. qemu vl.c (Paul Brook) 2. QEMU/PCI shutdown event (Clemens Kolbitsch) 3. qemu/hw pxa.h pxa2xx.c (Andrzej Zaborowski) 4. RE: QEMU/PCI shutdown event (Dor Laor) 5. kqemu and 2.6.22-rc3 (Xavier Gnata) 6. qemu mips-dis.c (Thiemo Seufer) 7. qemu/linux-user syscall.c (Thiemo Seufer) 8. Re: qemu/linux-user syscall.c (Paul Brook) -- Message: 1 Date: Mon, 28 May 2007 02:29:59 + From: Paul Brook [EMAIL PROTECTED] Subject: [Qemu-devel] qemu vl.c To: qemu-devel@nongnu.org Message-ID: [EMAIL PROTECTED] CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 07/05/28 02:29:59 Modified files: . : vl.c Log message: Fix tap device counting. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.302r2=1.303 -- Message: 2 Date: Mon, 28 May 2007 13:05:29 +0200 From: Clemens Kolbitsch [EMAIL PROTECTED] Subject: [Qemu-devel] QEMU/PCI shutdown event To: qemu-devel@nongnu.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed hi everyone! i'm programming a pci-device that includes some threads socket-connections (that allow remote debugging of my device). however, i want to cleanly shutdown all threads and sockets when qemu exits... is there an easy way of getting informed of a qemu shutdown? (something similar to pci_device_init...) thanks!! -- Message: 3 Date: Mon, 28 May 2007 11:26:16 + From: Andrzej Zaborowski [EMAIL PROTECTED] Subject: [Qemu-devel] qemu/hw pxa.h pxa2xx.c To: qemu-devel@nongnu.org Message-ID: [EMAIL PROTECTED] CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/05/28 11:26:16 Modified files: hw : pxa.h pxa2xx.c Log message: Remove a local subpage IO hack, now that general subpage IO works. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa.h?cvsroot=qemur1=1.5r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx.c?cvsroot=qemur1=1.13r2=1.14 -- Message: 4 Date: Mon, 28 May 2007 04:46:41 -0700 From: Dor Laor [EMAIL PROTECTED] Subject: RE: [Qemu-devel] QEMU/PCI shutdown event To: qemu-devel@nongnu.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii hi everyone! i'm programming a pci-device that includes some threads socket-connections (that allow remote debugging of my device). however, i want to cleanly shutdown all threads and sockets when qemu exits... is there an easy way of getting informed of a qemu shutdown? (something similar to pci_device_init...) thanks!! You can use qemu_register_reset handler. Note that it get's called when the guests exits but not if you just quit the monitor. dear qemu-developers, i think it would be very helpful, if such a possibility exists.. maybe you could consider implementing this in a future release :-) just a suggestion ;-) greets!
RE: [Qemu-devel] QEMU/PCI shutdown event
hi everyone! i'm programming a pci-device that includes some threads socket-connections (that allow remote debugging of my device). however, i want to cleanly shutdown all threads and sockets when qemu exits... is there an easy way of getting informed of a qemu shutdown? (something similar to pci_device_init...) thanks!! You can use qemu_register_reset handler. Note that it get's called when the guests exits but not if you just quit the monitor. dear qemu-developers, i think it would be very helpful, if such a possibility exists.. maybe you could consider implementing this in a future release :-) just a suggestion ;-) greets! sorry for this aweful post!! seems i forgot to delete half the message :-(
[Qemu-devel] Adding multiple files to qemu Makefile ... a pain
hi! sorry that I'm posting for such a dumb thing, but I'm going crazy Up until now, I had a single file added to the qemu/hw folder. after adding VL_OBJS += myfile.o everything compiled without problems. but now my project grew too large and i wanted to split everything into multiple header- and source-files (all inside qemu/hw). Now, I've been sitting here for hours trying to get everything working, without success (obviously, otherwise I wouldn't be asking ;-) ) What adoptions do I have to make to Makefile(.target) to add new headersource files (best would be if I could add a seperate folder inside qemu/hw/) thanks and sorry for such a basic-gcc/makefile question :-( greets!!
[Qemu-devel] Accepting socket connections in qemu (not the client... the emulator)
hi! my virtual device inside qemu (a pci device) is listening for socket-(tcp)-connections. however, accept() always fails (code works fine if not executed inside the qemu-process)... now i'm wondering if qemu interferes somehow... is that possible? frustrated *gg*
[Qemu-devel] Re: Accepting socket connections in qemu (not the client... the emulator)
Clemens Kolbitsch wrote: hi! my virtual device inside qemu (a pci device) is listening for socket-(tcp)-connections. however, accept() always fails (code works fine if not executed inside the qemu-process)... now i'm wondering if qemu interferes somehow... is that possible? frustrated *gg* ok i found an answer to it. obviously, qemu has to handle interrupt-signals (e.g. from its client-os). this interrupts accepting connections. very bad for me, but at least a logical reason :-/
Re: [Qemu-devel] Re: Accepting socket connections in qemu (not the client... the emulator)
Johannes Schindelin wrote: Hi, On Tue, 29 May 2007, Clemens Kolbitsch wrote: Clemens Kolbitsch wrote: my virtual device inside qemu (a pci device) is listening for socket-(tcp)-connections. however, accept() always fails (code works fine if not executed inside the qemu-process)... now i'm wondering if qemu interferes somehow... is that possible? frustrated *gg* ok i found an answer to it. obviously, qemu has to handle interrupt-signals (e.g. from its client-os). this interrupts accepting connections. very bad for me, but at least a logical reason :-/ I guess that you use the Slirp device. This device is masqueraded to the outside, so unless you use something different, like VLAN or TAP, you can only make it work using a tunnel. no... i think you misunderstand... I'm trying to accept a socket inside the qemu-emulation-process. not inside the simulated operating system.
[Qemu-devel] QEMU/PCI shutdown event
hi everyone! i'm programming a pci-device that includes some threads socket-connections (that allow remote debugging of my device). however, i want to cleanly shutdown all threads and sockets when qemu exits... is there an easy way of getting informed of a qemu shutdown? (something similar to pci_device_init...) thanks!!
Re: RE: [Qemu-devel] QEMU/PCI shutdown event
hi everyone! i'm programming a pci-device that includes some threads socket-connections (that allow remote debugging of my device). however, i want to cleanly shutdown all threads and sockets when qemu exits... is there an easy way of getting informed of a qemu shutdown? (something similar to pci_device_init...) thanks!! You can use qemu_register_reset handler. Note that it get's called when the guests exits but not if you just quit the monitor. hm... since i'm really tearing down qemu quite often (sigint) that's not really a solutions for me, but thanks!! If nothing else works, i'll give it a try :-) any other ideas?
[Qemu-devel] Getting started programming a HW Device
Hi everyone! Could someone please point out some links to a good documentation and/or tutorial on how to write hardware devices for qemu? I have been reading through the parallel ne2k code and - although it is not that hard - just do not get all the information necessary it seems. are there some places, where functions like - qemu_chr_ioctl - cpu_register_io_memory - pci_register_io_memory - pci_register_device - etc. are described shortly (or even in more detail ;-) )? My current problem is the following: While loading a module in the client-os it get the error cannot reserve PCI memory region (from the dadwifi (yes - not madwifi) ath_pci module). What do i have to do in order to get this right? cheers!
[Qemu-devel] Create Fake PCI Cards
Hi everyone! I've read some posts in the qemu-mailinglist archives about the idea of a pci-proxy (allowing the client-os to access the host-os-pci devices) and the problems related to that. now, I want to make something similar and wonder if there is already some source code that does all that already (because a big part of it might exist in the proxy mentioned or even in the standard qemu-ethernet-device): I want to create a fake/virtual pci device that only exists in the vm. so basically it boils down to adding a new (wireless) device that is not connected to anything and that i can write data to/read data from the device driver runnnig inside of qemu. Any help would be greatly appreciated! Clemens
Re: [Qemu-devel] Create Fake PCI Cards
Paul Brook wrote: I want to create a fake/virtual pci device that only exists in the vm. so basically it boils down to adding a new (wireless) device that is not connected to anything and that i can write data to/read data from the device driver runnnig inside of qemu. Qemu already has many emulated PCI devices. Look at those. Paul yeah... to be honest, i postet the message about 2 mins too early. right afterwards i found the pci-proxy and similar things and started to understand the code-flow what i'm trying to do now is to make this fake wireless device. however, i originally wanted to write an virtual driver for an atheros chipset, but the hardware-access layer is not open-source. so, does anyone know of a chip that is used regurarly and that has an open-source hal? thanks!!
[Qemu-devel] wireless pci device driver
If you need a wireless PCI device, I can provide code for TNETW1130 (ACX111). Get it from http://svn.berlios.de/svnroot/repos/ar7-firmware/qemu/trunk/hw/tnetw1130.c It works partially with an emulated Linux 2.6.20: the PCI card is recognized, and it loads firmware. wow!! it'll take a good look at that... the whole day i've been trying to reverse engineer some of the atheros driver (obviously without any good results due to my poor knowledge of this stuff). this could save me A LOT of work!! greets, Clemens
