[Qemu-devel] Questions on "hidden" functions in QEMU source code
Hi, I am looking at the source code of QEMU, and there are some mystery to me: some functions are not defined anywhere. For example, functions like compute_all_incb() and compute_c_incl() in target-i386/op.c are never defined anywhere. So how the compilation process generates these functions? Another question: micro-op are defined as OPPROTO, but OPPROTO is actually defined as empty in dyngen-exec.h #define OPPROTO So what is the point of using OPPROTO here? I am sure that there is a good reason to do that, but cannot figure it out. Many thanks, Jun
Re: [Qemu-devel] Questions on "hidden" functions in QEMU source code
On Tue, Oct 16, 2007 at 05:28:24PM +0900, Jun Koi wrote: > For example, functions like compute_all_incb() and compute_c_incl() in > target-i386/op.c are never defined anywhere. compute_all_inc* are defined in ops_template.h:~171. You'll notice that ops_template.h is included four times from op.c. > Another question: micro-op are defined as OPPROTO, but OPPROTO is > actually defined as empty in dyngen-exec.h > > #define OPPROTO > > So what is the point of using OPPROTO here? I am sure that there is a > good reason to do that, but cannot figure it out. Presumably so that attributes can be defined later if they're needed. Cheers, -- Stuart Brady
Re: [Qemu-devel] handling SIGWINCH with qemu -nographic
On Mon, Oct 15, 2007 at 06:15:29PM -0700, Jeff Carr wrote: > For those that might not be familiar with SIGWINCH, supporting it > would allow qemu -nographic to tell when the terminal is a different > size than 80x24. That would need support on the remote side (the getty) as well as on the terminal (minicom/tip/qemu -nographic/whatever). While this would be a nice feature (and support for propagating the TERM, LANG and LC_* variables might be nice, too), I'm doubtful as to whether this will ever happen. -- Stuart Brady
Re: [Qemu-devel] Questions on "hidden" functions in QEMU source code
Hi, On Tue, 16 Oct 2007, Stuart Brady wrote: > On Tue, Oct 16, 2007 at 05:28:24PM +0900, Jun Koi wrote: > > For example, functions like compute_all_incb() and compute_c_incl() in > > target-i386/op.c are never defined anywhere. > > compute_all_inc* are defined in ops_template.h:~171. You'll notice that > ops_template.h is included four times from op.c. If you wonder why it is included four times, this might help: http://libvncserver.sourceforge.net/qemu/qemu-templates-ala-Fabrice.txt Hth, Dscho
Re: [Qemu-devel] handling SIGWINCH with qemu -nographic
On 10/15/07 19:32, Paul Brook wrote: > qemu emulates a real machine. Signals are an operating system concept, so your > question makes no sense. Configure your guest OS exactly the same way you > would a real machine with a serial console. OK. I thought there might be a way. > The linux-user code is for the userspace emulation. You're obviously using > the > full system emulation. It seemed that's where the handler would have to go. I don't know if there is some way to pass that through a serial device. I wasn't sure if it would require some custom qemu serial driver for the guest.
[PATCH] Re: [Qemu-devel] QEMU keyboard issue with Gujin-2.2
Hello,
I have digged further my problem of keyboard problem when the mouse is
activated
using qemu (i.e. dummy char present in the keyboard buffer), and can say that
this patch solves completely the problem:
$ diff -urp qemu-0.9.0-init qemu-0.9.0
diff -urp qemu-0.9.0-init/hw/pckbd.c qemu-0.9.0/hw/pckbd.c
--- qemu-0.9.0-init/hw/pckbd.c 2007-02-05 23:01:54.0 +
+++ qemu-0.9.0/hw/pckbd.c 2007-10-16 20:32:40.0 +0100
@@ -202,7 +202,7 @@ static void kbd_write_command(void *opaq
#endif
switch(val) {
case KBD_CCMD_READ_MODE:
-kbd_queue(s, s->mode, 0);
+kbd_queue(s, s->mode, 1);
break;
case KBD_CCMD_WRITE_MODE:
case KBD_CCMD_WRITE_OBUF:
To reproduce my problem, just download "gujin install pack" install-2.2.tar.gz
from http://gujin.sf.net , then extract boot.144 to run qemu like:
i386-softmmu/qemu -fda boot.144 -L ~/qemu-0.9.0/pc-bios/
You should be able to see the problem immediately, and see it fixed with the
patch.
The problem seems to be that a keyboard IRQ is generated by this command, and
it is later converted to a "key typed" by re-reading the data port, when
interrupts
are re-enabled. I am not a specialist of rombios.c of bochs (but I did not need
to modify it), but Gujin is just using the BIOS mouse interface - not touching
I/O ports 0x60 and 0x64 (except enable A20).
I hope this patch will be included in the next release.
Thanks for the qemu software,
Etienne.
--
"Knowledge is not enough, we must apply." (Bruce Lee)
_
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail
Re: [Qemu-devel] RFC: Code fetch optimisation
On Mon, 2007-10-15 at 23:42 +0100, Paul Brook wrote: > > > VLE targets (x86, m68k) can translate almost a full page of instructions, > > > and a page boundary can be anywhere within that block. Once we've spanned > > > multiple pages there's not point stopping translation immediately. We may > > > as well translate as many instructions as we can on the second page. > > > > > > I'd guess most TB are much smaller than a page, so on average only a few > > > instructions are going to come after the page boundary. > > > > This leads me to another reflexion. For fixed length encoding targets, > > we always stop translation when reaching a page boundary. If we keep > > using the current model and we optimize the slow case, it would be > > possible to stop only if we cross 2 pages boundary during code > > translation, and it seems that this case is not likely to happen. If we > > keep the current behavior, we could remove the second page_addr element > > in the tb structure and maybe optimize parts of the tb management and > > invalidation code. > > The latter may be the only feasible option. > > Some targets (ARMv5, maybe others) do not have an explicit fault address for > MMU instruction faults. The faulting address is the address of the current > instruction when the fault occurs. Prefetch aborts are generated at > translation time, which effectively means the faulting instruction must be at > the start of a TB. Terminating the TB on a page boundary guarantees this > behavior. Well, we got the same behavior on PowerPC. What I was thinking of is that if we fix the VLE problems, the fix, if done in a proper way, could also allow benefit to RISC targets. What I don't know is; would we really have a benefit not stopping translation on page boundaries ? > For VLE targets we already get this wrong (the prefetch abort occurs some > time > before the faulting instruction executes). I don't know if this behavior is > permitted by the ISA, but it's definitely possible to construct cases where > it has visible effect. I think that it would be possible to do things properly. I'm not really sure what is the best solution to implement it but if, in the "slow case" path of the code fetch low-level routine, we call the get_physical_address or the cpu_get_phys_page_debug function, we then have a way to know if the code fetch is allowed. If it, we would just have to adjust our host_pc and host_pc_start for the next fetch to be optimized. If not, we could stop the translation and generate a "gen_op_raise_excp_error" to raise the exception at the right place, respecting the ISA insns execution ordering. Generating the exception from inside the TB won't be OK, as it may not be necessary on a second execution of the same TB, then the solution may be to link the TB with a special other TB that would just raise this exception and would be unlink once the exception has been treated. Or maybe the solution would just be to stop the translation knowing that the exception will be raised when trying to translate the first instruction in the next page. There still may be specific problems for instructions spanning 2 pages, using those solutions... -- J. Mayer <[EMAIL PROTECTED]> Never organized
Re: [Qemu-devel] handling SIGWINCH with qemu -nographic
Jeff Carr schrieb: > On 10/15/07 19:32, Paul Brook wrote: > >> qemu emulates a real machine. Signals are an operating system >> concept, so your >> question makes no sense. Configure your guest OS exactly the same way >> you >> would a real machine with a serial console. > > OK. I thought there might be a way. I think your question is quite reasonable. Imagine a Linux host running X Windows and a terminal like xterm or kconsole. Then run a program like "top" or "less" in this terminal. When a user changes the size of the console window, top, less and other console applications get notified of this change by SIGWINCH. Now run a similar program using QEMU's user mode emulation. Why should it not be possible to get SIGWINCH in QEMU and pass it on to the program in user mode emulation, so it can behave like a native Linux application and change its appearance? I don't think that implementing this is very difficult, so it will be done. Regards Stefan
[Qemu-devel] Mips target '-kernel' option bug
I failed to run Mips target test image on my amd64 machine and I now found the reason of the bug: the kernel loader code used in hw/mips_r4k.c and hw/mips_malta.c implicitelly assumes that the ram_addr_t is 32 bits long. Unfortunatelly, on 64 bits hosts, this won't be the case and the kernel load address then is over 4 GB. Then, when computing the initrd_offset, the code always concludes that there's not enough RAM available to load it at the top of the kernel. I found 2 ways of fixing the bug, but I don't know which one is correct in Mips execution environment. The first patch is to make the VIRT_TO_PHYS_ADDEND negative, thus translating the kernel virtual address from 0x8000 to the physical one 0x (instead of 0x1, when running on 64 bits hosts). The second solution would be to explicitelly always cast the kernel_high value to 32 bits. As I do not really know if some Mips target specific constraints would make one of the other solution prefered, I'd better let the specialist choose ! The good news is that, once this issue is fixed, the Mips test images run with the reverse-endian softmmu patch applied. -- J. Mayer <[EMAIL PROTECTED]> Never organized
Re: [Qemu-devel] handling SIGWINCH with qemu -nographic
> I think your question is quite reasonable. Imagine a Linux host > running X Windows and a terminal like xterm or kconsole. > Then run a program like "top" or "less" in this terminal. > When a user changes the size of the console window, top, less > and other console applications get notified of this change by SIGWINCH. > > Now run a similar program using QEMU's user mode emulation. > Why should it not be possible to get SIGWINCH in QEMU and > pass it on to the program in user mode emulation, so it can > behave like a native Linux application and change its appearance? > > I don't think that implementing this is very difficult, so it will be > done. Try doing the same thing with a real machine connected via a serial port. It won't work. The difference is that for local applications (and remote terminals via telnet or ssh) you have OOB mechanisms to transmit event data (e.g. terminal size). A UART only gives you a simple serial connection. If you want things like terminal resizing to work you need to run some more complicated protocol over the serial link, with appropriate tty emulation on either end. Paul
Re: [Qemu-devel] RFC: Code fetch optimisation
> Well, we got the same behavior on PowerPC. What I was thinking of is > that if we fix the VLE problems, the fix, if done in a proper way, could > also allow benefit to RISC targets. What I don't know is; would we > really have a benefit not stopping translation on page boundaries ? > > For VLE targets we already get this wrong (the prefetch abort occurs some > > time before the faulting instruction executes). I don't know if this > > behavior is permitted by the ISA, but it's definitely possible to > > construct cases where it has visible effect. > > I think that it would be possible to do things properly. > [...] Or maybe the solution would > just be to stop the translation knowing that the exception will be > raised when trying to translate the first instruction in the next page. I'd go for this one. It's approximately the same method currently used for RISC targets. In general think this will require target specific support. For RISC targets this is trivial. For x86/m68k figuring out the length of an insn is trickier. Detecting crossing a page boundary on subsequent insns in the load/mmu routines is problematic because it happens relatively late. In particular it may theoretically happen after we've output ops that change CPU state. I suspect the best solution is to backtrack (remove the generated ops) after decoding the insn if we discover we've passed a page boundary. The ld*_code routines can simply return garbage (e.g. zero) if the read is not on the first page. Trying to generate prefetch aborts at runtime sounds too hairy for my liking. Paul
Re: [Qemu-devel] RFC: Code fetch optimisation
> Well, we got the same behavior on PowerPC. What I was thinking of is > that if we fix the VLE problems, the fix, if done in a proper way, could > also allow benefit to RISC targets. What I don't know is; would we > really have a benefit not stopping translation on page boundaries ? [ I meant to say in my previous mail, but got cut during editing ] I suspect that we're going to want/need to break the TB to get the exception semantics right, so for RISC targets there's no point having TBs that span a page boundary. Paul
Re: [Qemu-devel] RFC: Code fetch optimisation
On Tue, 2007-10-16 at 23:00 +0100, Paul Brook wrote: > > Well, we got the same behavior on PowerPC. What I was thinking of is > > that if we fix the VLE problems, the fix, if done in a proper way, could > > also allow benefit to RISC targets. What I don't know is; would we > > really have a benefit not stopping translation on page boundaries ? > I suspect that we're going to want/need to break the TB to get the exception > semantics right, so for RISC targets there's no point having TBs that > span a > page boundary. My opinion is that this an optimisation that may be tried later, if it really give an advantage in terms of translation efficiency, which is far from being evident. Then, let's keep what works well and just try to solve the VLE problems for now... > > > For VLE targets we already get this wrong (the prefetch abort occurs some > > > time before the faulting instruction executes). I don't know if this > > > behavior is permitted by the ISA, but it's definitely possible to > > > construct cases where it has visible effect. > > > > I think that it would be possible to do things properly. > > [...] Or maybe the solution would > > just be to stop the translation knowing that the exception will be > > raised when trying to translate the first instruction in the next page. > > I'd go for this one. It's approximately the same method currently used for > RISC targets. > In general think this will require target specific support. For RISC targets > this is trivial. For x86/m68k figuring out the length of an insn is trickier. > > Detecting crossing a page boundary on subsequent insns in the load/mmu > routines is problematic because it happens relatively late. In particular it > may theoretically happen after we've output ops that change CPU state. > > I suspect the best solution is to backtrack (remove the generated ops) after > decoding the insn if we discover we've passed a page boundary. The ld*_code > routines can simply return garbage (e.g. zero) if the read is not on the > first page. The "incorrect" returned value may be target specific to be sure it's always an invalid opcode. Backtracking should not be hard if we register the last cc pointer each time we finish translating an insn. I'll think about this solution, which really seems feasible to me. > Trying to generate prefetch aborts at runtime sounds too hairy for my liking. It might be really tricky and is likely to be bugged, I agree. -- J. Mayer <[EMAIL PROTECTED]> Never organized
Re: [Qemu-devel] RFC: Code fetch optimisation
> > I suspect the best solution is to backtrack (remove the generated ops) > > after decoding the insn if we discover we've passed a page boundary. The > > ld*_code routines can simply return garbage (e.g. zero) if the read is > > not on the first page. > > The "incorrect" returned value may be target specific to be sure it's > always an invalid opcode. It doesn't matter whether it's valid or not, and we've no way of guaranteeing that anyway. We just have to make sure we don't generate an infinitely long instruction. On a related note, I notice that we don't enforce x86 instruction length limits. > Backtracking should not be hard if we register the last cc pointer each > time we finish translating an insn. I'll think about this solution, > which really seems feasible to me. Right. You only have to worry about backtracking the state that's lives across insns and is not constant within a TB. For x86 I think this is dc->pc, dc->cc_op, gen_opc_ptr and nb_gen_labels. Plus you need to reset dc->is_jmp to zero. gen_opparam_ptr is not used after disassembly, so can be ignored. Paul
