Re: [Qemu-devel] 0.9.0 Win32 Tap inferface PPC Guest issue
Ok I located the source of the problem.
The code in main_loop_wait() that uses WaitForMultipleObjects will only
service one object that woke it up.
What is occuring is that the host_alarm timer is being serviced anytime
the tap_semaphore is also signaled, therefore the tap callback function is
never called while at the same time the tap_semaphore count is
decremented. This guarantees that the callback function will never get
services if that particular timing continues.
This is likely something that won't occur on every system because of the
nature of the timing, but it is a problem.
I'm working on a better fix as right now my solution is to poll all the
objects after a wakeup to see who really is signaled.
In order to do that you must use an Event Object in Manual Reset Mode.
vl.c
void main_loop_wait(int timeout)
...
WaitObjects *w = wait_objects;
ret = WaitForMultipleObjects(w-num, w-events, FALSE, timeout);
if (WAIT_OBJECT_0 + 0 = ret ret = WAIT_OBJECT_0 + w-num - 1)
{
if (w-func[ret - WAIT_OBJECT_0])
w-func[ret - WAIT_OBJECT_0](w-opaque[ret -
WAIT_OBJECT_0]);
} else if (ret == WAIT_TIMEOUT) {
} else {
err = GetLastError();
fprintf(stderr, Wait error %d %d\n, ret, err);
}
...
Ely Soto
-
Notice: This e-mail is intended solely for use of the individual
or entity to which it is addressed and may contain information that
is proprietary, privileged and exempt from disclosure under
applicable law. If the reader is not the intended recipient or
agent responsible for delivering the message to the intended
recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly
prohibited. This communication may also contain data subject to
U.S. export laws. If so, that data subject to the International
Traffic in Arms Regulation cannot be disseminated, distributed or
copied to foreign nationals, residing in the U.S. or abroad, absent
the express prior approval of the U.S. Department of State. If
you have received this communication in error, please notify the
sender by reply e-mail and destroy the e-mail message and any
physical copies made of the communication. Thank you.
Re: [Qemu-devel] 0.9.0 Win32 Tap inferface PPC Guest issue
Ok this is the fix I came up with.
Basically it will check all the other objects that could potentially be
waiting for service. This will prevent one high priority object from
starving the rest.
I'm not certain what the intention for the timeout 0 check but this
completely prevented any wait object servicing on my machine.
The Tap interface now works smoothly without issue.
Diff/patch for 0.9.0 release version of vl.c
==
5840c5840
int ret, nfds;
---
int ret, ret2, nfds, i;
5851c5851
if (ret == 0 timeout 0) {
---
if (ret == 0) {
5858a5859,5873
/* Check for additional signaled events */
for(i = (ret - WAIT_OBJECT_0 + 1); i w-num; i++) {
/* Check if event is signaled */
ret2 = WaitForSingleObject(w-events[i], 0);
if(ret2 == WAIT_OBJECT_0) {
if (w-func[i])
w-func[i](w-opaque[i]);
} else if (ret2 == WAIT_TIMEOUT) {
} else {
err = GetLastError();
fprintf(stderr, WaitForSingleObject error %d %d\n,
i, err);
}
}
5862c5877
fprintf(stderr, Wait error %d %d\n, ret, err);
---
fprintf(stderr, WaitForMultipleObjects error %d %d\n, ret,
err);
==
Diff/patch for version 1.279 of vl.c
==
6146c6146
int ret, nfds;
---
int ret, ret2, nfds, i;
6157c6157
if (ret == 0 timeout 0) {
---
if (ret == 0) {
6164a6165,6179
/* Check for additional signaled events */
for(i = (ret - WAIT_OBJECT_0 + 1); i w-num; i++) {
/* Check if event is signaled */
ret2 = WaitForSingleObject(w-events[i], 0);
if(ret2 == WAIT_OBJECT_0) {
if (w-func[i])
w-func[i](w-opaque[i]);
} else if (ret2 == WAIT_TIMEOUT) {
} else {
err = GetLastError();
fprintf(stderr, WaitForSingleObject error %d %d\n,
i, err);
}
}
6168c6183
fprintf(stderr, Wait error %d %d\n, ret, err);
---
fprintf(stderr, WaitForMultipleObjects error %d %d\n, ret,
err);
==
Ely Soto
Ely Soto [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
04/09/2007 01:54 PM
Please respond to
qemu-devel@nongnu.org
To
qemu-devel@nongnu.org
cc
Subject
Re: [Qemu-devel] 0.9.0 Win32 Tap inferface PPC Guest issue
Ok I located the source of the problem.
The code in main_loop_wait() that uses WaitForMultipleObjects will only
service one object that woke it up.
What is occuring is that the host_alarm timer is being serviced anytime
the tap_semaphore is also signaled, therefore the tap callback function is
never called while at the same time the tap_semaphore count is
decremented. This guarantees that the callback function will never get
services if that particular timing continues.
This is likely something that won't occur on every system because of the
nature of the timing, but it is a problem.
I'm working on a better fix as right now my solution is to poll all the
objects after a wakeup to see who really is signaled.
In order to do that you must use an Event Object in Manual Reset Mode.
vl.c
void main_loop_wait(int timeout)
...
WaitObjects *w = wait_objects;
ret = WaitForMultipleObjects(w-num, w-events, FALSE, timeout);
if (WAIT_OBJECT_0 + 0 = ret ret = WAIT_OBJECT_0 + w-num - 1)
{
if (w-func[ret - WAIT_OBJECT_0])
w-func[ret - WAIT_OBJECT_0](w-opaque[ret -
WAIT_OBJECT_0]);
} else if (ret == WAIT_TIMEOUT) {
} else {
err = GetLastError();
fprintf(stderr, Wait error %d %d\n, ret, err);
}
...
Ely Soto
-
Notice: This e-mail is intended solely for use of the individual
or entity to which it is addressed and may contain information that
is proprietary, privileged and exempt from disclosure under
applicable law. If the reader is not the intended recipient or
agent responsible for delivering the message to the intended
recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly
prohibited. This communication may also contain data subject to
U.S. export laws. If so, that data subject to the International
Traffic in Arms Regulation cannot be disseminated, distributed or
copied to foreign nationals, residing in the U.S. or abroad, absent
the express prior approval of the U.S. Department of State. If
you have received this communication in error, please notify the
sender by reply e-mail and destroy the e-mail message and any
physical copies made of the communication. Thank you.
[Qemu-devel] 0.9.0 Win32 Tap inferface PPC Guest issue
I'm having an issue getting the 0.9.0 build ppc to work with tap. OpenVPN 2.09 Relevant Parameters -net nic -net tap,ifname=tap-lan 0.8.2 works quite well. I've narrowed the break to the change described here. http://lists.gnu.org/archive/html/qemu-devel/2006-08/msg00243.html Backing this out of the 0.9.0 gets tap networking working again. I'll keep investigating. Ely Soto, Flight Software Engineer Orbital Sciences Corp. Dulles, VA. [EMAIL PROTECTED] Office No. 703-406-5341 Mobile No. 703-403-7077 - Notice: This e-mail is intended solely for use of the individual or entity to which it is addressed and may contain information that is proprietary, privileged and exempt from disclosure under applicable law. If the reader is not the intended recipient or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. This communication may also contain data subject to U.S. export laws. If so, that data subject to the International Traffic in Arms Regulation cannot be disseminated, distributed or copied to foreign nationals, residing in the U.S. or abroad, absent the express prior approval of the U.S. Department of State. If you have received this communication in error, please notify the sender by reply e-mail and destroy the e-mail message and any physical copies made of the communication. Thank you.
Re: [Qemu-devel] 0.9.0 Win32 Tap inferface PPC Guest issue
Further details:
This call functions correctly and returns true.
tap-win32.c, line 534
ReleaseSemaphore(overlapped-tap_semaphore, 1, NULL)
However, WaitForMultipleObjects never returns successfully to execute the
callback function.
vl.c, line 5859
main_loop_wait()
...
ret = WaitForMultipleObjects(w-num, w-events, FALSE, timeout);
if (WAIT_OBJECT_0 + 0 = ret ret = WAIT_OBJECT_0 + w-num - 1)
{
...
Ely Soto, Flight Software Engineer
Orbital Sciences Corp. Dulles, VA.
[EMAIL PROTECTED]
Office No. 703-406-5341
Mobile No. 703-403-7077
-
Notice: This e-mail is intended solely for use of the individual
or entity to which it is addressed and may contain information that
is proprietary, privileged and exempt from disclosure under
applicable law. If the reader is not the intended recipient or
agent responsible for delivering the message to the intended
recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly
prohibited. This communication may also contain data subject to
U.S. export laws. If so, that data subject to the International
Traffic in Arms Regulation cannot be disseminated, distributed or
copied to foreign nationals, residing in the U.S. or abroad, absent
the express prior approval of the U.S. Department of State. If
you have received this communication in error, please notify the
sender by reply e-mail and destroy the e-mail message and any
physical copies made of the communication. Thank you.
Re: [Qemu-devel] 0.9.0 Win32 Tap inferface PPC Guest issue
Initially it looks like it may be some sort of timing issue. It happened to start working a bit without any code changes after I was stepping through the code. Can't reproduce that yet. Ely Soto - Notice: This e-mail is intended solely for use of the individual or entity to which it is addressed and may contain information that is proprietary, privileged and exempt from disclosure under applicable law. If the reader is not the intended recipient or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. This communication may also contain data subject to U.S. export laws. If so, that data subject to the International Traffic in Arms Regulation cannot be disseminated, distributed or copied to foreign nationals, residing in the U.S. or abroad, absent the express prior approval of the U.S. Department of State. If you have received this communication in error, please notify the sender by reply e-mail and destroy the e-mail message and any physical copies made of the communication. Thank you.
Re: [Qemu-devel] [PATCH] PPC32 Trace Exception and Trap instruction
Excellent, I had encountered that bug earlier on when trying to debug
using workbench.
Are you guys developing a BSP for qemu?
I have a partially working one.
Ely Soto
Jason Wessel [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
12/27/2006 11:05 AM
Please respond to
qemu-devel@nongnu.org
To
qemu-devel@nongnu.org
cc
Subject
[Qemu-devel] [PATCH] PPC32 Trace Exception and Trap instruction
Please add this patch to CVS.
The patch has two purposes:
1) The NIP needs to be updated for a tw instruction.
I found that when executing protected mode traps
the PC was always set to the begining of the code
generation block instead of the instruction the trap
occurred on.
The usual PPC breakpoint instruction is:
7d 82 10 08 twger2,r2 (Trap when rA = rB)
2) Single stepping was fixed up earlier in the year
for using a debugger connected to the QEMU
gdb stub. Now it is enabled for connecting a
runtime single stepping with the trace trap so you
can use ptrace() or even debug KGDB.
signed-off-by: [EMAIL PROTECTED]
Thanks,
Jason.
Index: qemu/target-ppc/helper.c
===
--- qemu.orig/target-ppc/helper.c
+++ qemu/target-ppc/helper.c
@@ -1113,8 +1113,6 @@ void do_interrupt (CPUState *env)
}
goto store_next;
case EXCP_TRACE: /* 0x0D00 */
-/* XXX: TODO */
-cpu_abort(env, Trace exception is not implemented yet !\n);
goto store_next;
case EXCP_PERF: /* 0x0F00 */
/* XXX: TODO */
Index: qemu/target-ppc/translate.c
===
--- qemu.orig/target-ppc/translate.c
+++ qemu/target-ppc/translate.c
@@ -1956,6 +1956,8 @@ GEN_HANDLER(tw, 0x1F, 0x04, 0xFF, 0x
{
gen_op_load_gpr_T0(rA(ctx-opcode));
gen_op_load_gpr_T1(rB(ctx-opcode));
+/* Update the nip since this might generate a trap exception */
+gen_op_update_nip(ctx-nip);
gen_op_tw(TO(ctx-opcode));
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
-
Notice: This e-mail is intended solely for use of the individual
or entity to which it is addressed and may contain information that
is proprietary, privileged and exempt from disclosure under
applicable law. If the reader is not the intended recipient or
agent responsible for delivering the message to the intended
recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly
prohibited. This communication may also contain data subject to
U.S. export laws. If so, that data subject to the International
Traffic in Arms Regulation cannot be disseminated, distributed or
copied to foreign nationals, residing in the U.S. or abroad, absent
the express prior approval of the U.S. Department of State. If
you have received this communication in error, please notify the
sender by reply e-mail and destroy the e-mail message and any
physical copies made of the communication. Thank you.___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] PPC Bug Report - Trap Exception setting SRR0 incorrectly
PPC Bug Only Call Stack op_helper.c : do_tw() op_helper.c : do_raise_exception_err() op_helper.c : cpu_loop_exit() op_helper.c : longjmp() ??? helper.c : do_interrupt() Normally when an exception gets to do_interrupt(), env-nip is set to the instruction after the one causing the exception. However, a trap instruction arrives at the do_interrupt() with the env-nip set at the instruction that caused the exception. This causes an the SRR0 to get set incorrectly to one instruction back when calling the exception handler. I'm still learning the code so I'm still trying to figure out the right fix since its possible that more exceptions are affected. I've already verified that forcing the env-nip forward for just the trap case fixes the execution. From the middle of helper.c : do_interrupt() case EXCP_TRAP: goto store_current; From the bottom of helper.c : do_interrupt() store_current: /* save current instruction location */ *srr_0 = (env-nip - 4) 0xULL; break; store_next: /* save next instruction location */ *srr_0 = env-nip 0xULL; break; I discovered this because I'm trying to get a vxworks debugger working when the os is running. Ohh ya, I've got a VxWorks 6.3 kernel up and running on PPC QEMU. 8-) Custom BSP and all. - Notice: This e-mail is intended solely for use of the individual or entity to which it is addressed and may contain information that is proprietary, privileged and exempt from disclosure under applicable law. If the reader is not the intended recipient or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. This communication may also contain data subject to U.S. export laws. If so, that data subject to the International Traffic in Arms Regulation cannot be disseminated, distributed or copied to foreign nationals, residing in the U.S. or abroad, absent the express prior approval of the U.S. Department of State. If you have received this communication in error, please notify the sender by reply e-mail and destroy the e-mail message and any physical copies made of the communication. Thank you.___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] PowerPC Decrementer Clock Rate
Hi, Does the time-base setting below signify that the PowerPC Decrementer is at 100MHz or is it the CPU? This isn't completely obvious because sometimes you have something like 4 bus clocks per decrementer increment. ... ppc_prep.c /* Set time-base frequency to 100 Mhz */ cpu_ppc_tb_init(env, 100UL * 1000UL * 1000UL); ... Thanks, Ely Soto Notice: This e-mail is intended solely for use of the individual or entity to which it is addressed and may contain information that is proprietary, privileged and exempt from disclosure under applicable law. If the reader is not the intended recipient or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. This communication may also contain data subject to U.S. export laws. If so, that data subject to the International Traffic in Arms Regulation cannot be disseminated, distributed or copied to foreign nationals, residing in the U.S. or abroad, absent the express prior approval of the U.S. Department of State. If you have received this communication in error, please notify the sender by reply e-mail and destroy the e-mail message and any physical copies made of the communication. Thank you. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] PPC LFDU instruction emulation problem?
I seem to hit a weird emulation issue. I'm still new so take what I say with a grain of salt. In my tests the LFDU instruction is not updating the Condition Register ($CR) when the condition becomes ZERO. The following assembly will loop forever. falconScrubFloop: lfdu 0,8(r17) /* load floating point value and increment register ( f0 - ($r17) and $r17 += 8 */ bc 16,0,falconScrubFloop /* branch till counter == 0, This is equivalent to bdnz or branch if not zero */ The MSR is set to allow floating point $MSR = 0x2000. Not sure what's going on yet. Ely Soto, Flight Software Engineer Orbital Sciences Corp. Dulles, VA. [EMAIL PROTECTED] Office No. 703-406-5341 Mobile No. 703-403-7077 Notice: This e-mail is intended solely for use of the individual or entity to which it is addressed and may contain information that is proprietary, privileged and exempt from disclosure under applicable law. If the reader is not the intended recipient or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. This communication may also contain data subject to U.S. export laws. If so, that data subject to the International Traffic in Arms Regulation cannot be disseminated, distributed or copied to foreign nationals, residing in the U.S. or abroad, absent the express prior approval of the U.S. Department of State. If you have received this communication in error, please notify the sender by reply e-mail and destroy the e-mail message and any physical copies made of the communication. Thank you. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PPC LFDU instruction emulation problem?
Ok, it seems to be my mistake. bdnz or bc 16,0,target decrements ctr then branches when zero. However, in the qemu monitor, info registers doesn't seem to update $ctr. Ely Soto [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 09/22/2006 11:20 AM Please respond to qemu-devel@nongnu.org To qemu-devel@nongnu.org cc Subject [Qemu-devel] PPC LFDU instruction emulation problem? I seem to hit a weird emulation issue. I'm still new so take what I say with a grain of salt. In my tests the LFDU instruction is not updating the Condition Register ($CR) when the condition becomes ZERO. The following assembly will loop forever. falconScrubFloop: lfdu0,8(r17) /* load floating point value and increment register ( f0 - ($r17) and $r17 += 8 */ bc16,0,falconScrubFloop /* branch till counter == 0, This is equivalent to bdnz or branch if not zero */ The MSR is set to allow floating point $MSR = 0x2000. Not sure what's going on yet. Notice: This e-mail is intended solely for use of the individual or entity to which it is addressed and may contain information that is proprietary, privileged and exempt from disclosure under applicable law. If the reader is not the intended recipient or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. This communication may also contain data subject to U.S. export laws. If so, that data subject to the International Traffic in Arms Regulation cannot be disseminated, distributed or copied to foreign nationals, residing in the U.S. or abroad, absent the express prior approval of the U.S. Department of State. If you have received this communication in error, please notify the sender by reply e-mail and destroy the e-mail message and any physical copies made of the communication. Thank you.___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] No response from qemu
Hi everyone. I'm fairly new to QEMU. I'm in the process of beginning to attempt to create a guest VxWorks installation. So far the idea is that I'll have to customize a BSP (Board Support Package) to match the emulated PPC hardware. At this point I've just gotten qemu to build using MingGW and Eclipse and have been delving into the source. Took me a while to figure out how to set it up. Has anyone ever attempted anything like this? It seems to me that I'm going to have to replace the bios file with my custom vxWorks Image. My first attempt without debug capability had Qemu stating that I was executing Zeros. Otherwise I'd have to create a bootable .img file with my vxworks install inside it and have the BIOS bootstrap it. Can't quite figure out how to create that sort of image yet. Anyway. Just thought I'd introduce myself. Ely Soto Notice: This e-mail is intended solely for use of the individual or entity to which it is addressed and may contain information that is proprietary, privileged and exempt from disclosure under applicable law. If the reader is not the intended recipient or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. This communication may also contain data subject to U.S. export laws. If so, that data subject to the International Traffic in Arms Regulation cannot be disseminated, distributed or copied to foreign nationals, residing in the U.S. or abroad, absent the express prior approval of the U.S. Department of State. If you have received this communication in error, please notify the sender by reply e-mail and destroy the e-mail message and any physical copies made of the communication. Thank you. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
