[Qemu-devel] Qemu
Hello, My name is Wayne. I've been using your product to expirement with Damn Small Linux. I have versions 0.7.2 and 0.8.1 installed on my computer. It was working just fine, but now it's not. Do I need to uninstall the 0.7.2 version? It keeps telling me Qemu acceleration layer is not activated. Can you help? Thank You for your time. Any input would be much appreciated. I hope that I've sent my email to the right place! _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: QEMU 0.8.1 and vnc
Anthony Liguori wrote: > Exactly. If you have a good network connection, you'll tend to get > lucky. The conditions for this race to happen are 1) a server receives > a SetPixelFormat with a different BPP 2) the server has already sent > data on the wire in the previous BPP but the client did not receive it > before sending the SetPixelFormat message. > > Changing the BPP is rare. RealVNC does it because it attempts to be > smart about reducing bandwidth (it drops down to 8bpp and then goes back > up to 32bpp if the transfer rate is fast enough). > > The best way to avoid this behavior is to use AutoSelect=0 FullColor=1 > on the vncviewer command line. How do other VNC servers avoid this problem, or do they all have it? -- Jamie ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu qemu-doc.texi
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/05/13 16:55:46 Modified files: . : qemu-doc.texi Log message: Update ARM board documentation. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/qemu-doc.texi.diff?tr1=1.88&tr2=1.89&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu Makefile
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/05/13 16:54:03 Modified files: . : Makefile Log message: Move all: target first. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/Makefile.diff?tr1=1.100&tr2=1.101&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: QEMU 0.8.1 and vnc
Paul Brook wrote: On Saturday 13 May 2006 16:15, Chris Wilson wrote: Hi Anthony, On Fri, 12 May 2006, Anthony Liguori wrote: A problem arises when the client sends a SetPixelFormat message. There is no "ack" message from the server so the client has to assume that as soon as it sends out the message, the server is now using the new pixel format. RealVNC uses totally synchronous IO routines so in practice, the window for this race condition is small for them. It definitely can occur though and I've reproduced it with a normal VNC server. Since the QEmu VNC code is completely asynchronous, we have a much larger window where this race can occur. The easiest thing to do is avoid the race all together and not have your client use SetPixelFormat frequently. Please forgive my ignorance, but why is there a race condition here? You have exactly one socket open between client and server. It's a TCP socket so out-of-order delivery or missing messages is impossible. Yes, but it's a bidirectional connection. The client doesn't know if the packet it just received was send before or after the server received the SetPixelFormat message. Exactly. If you have a good network connection, you'll tend to get lucky. The conditions for this race to happen are 1) a server receives a SetPixelFormat with a different BPP 2) the server has already sent data on the wire in the previous BPP but the client did not receive it before sending the SetPixelFormat message. Changing the BPP is rare. RealVNC does it because it attempts to be smart about reducing bandwidth (it drops down to 8bpp and then goes back up to 32bpp if the transfer rate is fast enough). The best way to avoid this behavior is to use AutoSelect=0 FullColor=1 on the vncviewer command line. Regards, Anthony Liguori Paul ___ 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
[Qemu-devel] System emulation for MIPS AR7
AR7 is a MIPS 4KEc based system used in WLAN and DSL routers. A patched version of QEMU CVS HEAD allows running of OpenWrt, a Linux distribution for routers. The serial console works, but large parts of the hardware emulation are still very rudimentary. Sorry, my patches are still not ready for integration in CVS HEAD, but those who are interested can get everything needed from this URL: http://developer.berlios.de/project/shownotes.php?release_id=10059 Regards Stefan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu Makefile.target
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/05/13 16:30:17 Modified files: . : Makefile.target Log message: Add dependency on config.h and config-host.h. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/Makefile.target.diff?tr1=1.109&tr2=1.110&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu ./Makefile.target ./vl.h hw/acpi.c hw/ide....
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/05/13 16:11:23 Modified files: . : Makefile.target vl.h hw : acpi.c ide.c pc.c pci.c ppc_chrp.c sun4m.c sun4u.c usb-uhci.c usb.h versatilepb.c Added files: hw : apb_pci.c grackle_pci.c pci_host.h piix_pci.c prep_pci.c unin_pci.c versatile_pci.c Log message: Rearrange PCI host emulation code. Add ARM PCI emulation. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/Makefile.target.diff?tr1=1.108&tr2=1.109&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.h.diff?tr1=1.118&tr2=1.119&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/acpi.c.diff?tr1=1.3&tr2=1.4&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/apb_pci.c?rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/grackle_pci.c?rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/ide.c.diff?tr1=1.42&tr2=1.43&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/pc.c.diff?tr1=1.54&tr2=1.55&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/pci.c.diff?tr1=1.24&tr2=1.25&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/pci_host.h?rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/piix_pci.c?rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/ppc_chrp.c.diff?tr1=1.21&tr2=1.22&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/prep_pci.c?rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/sun4m.c.diff?tr1=1.16&tr2=1.17&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/sun4u.c.diff?tr1=1.8&tr2=1.9&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/unin_pci.c?rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/usb-uhci.c.diff?tr1=1.8&tr2=1.9&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/usb.h.diff?tr1=1.4&tr2=1.5&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/versatile_pci.c?rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/versatilepb.c.diff?tr1=1.2&tr2=1.3&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: QEMU 0.8.1 and vnc
On Saturday 13 May 2006 16:15, Chris Wilson wrote: > Hi Anthony, > > On Fri, 12 May 2006, Anthony Liguori wrote: > > A problem arises when the client sends a SetPixelFormat message. There > > is no "ack" message from the server so the client has to assume that as > > soon as it sends out the message, the server is now using the new pixel > > format. RealVNC uses totally synchronous IO routines so in practice, the > > window for this race condition is small for them. It definitely can > > occur though and I've reproduced it with a normal VNC server. > > > > Since the QEmu VNC code is completely asynchronous, we have a much larger > > window where this race can occur. The easiest thing to do is avoid the > > race all together and not have your client use SetPixelFormat frequently. > > Please forgive my ignorance, but why is there a race condition here? You > have exactly one socket open between client and server. It's a TCP socket > so out-of-order delivery or missing messages is impossible. Yes, but it's a bidirectional connection. The client doesn't know if the packet it just received was send before or after the server received the SetPixelFormat message. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: QEMU 0.8.1 and vnc
Hi Anthony, On Fri, 12 May 2006, Anthony Liguori wrote: A problem arises when the client sends a SetPixelFormat message. There is no "ack" message from the server so the client has to assume that as soon as it sends out the message, the server is now using the new pixel format. RealVNC uses totally synchronous IO routines so in practice, the window for this race condition is small for them. It definitely can occur though and I've reproduced it with a normal VNC server. Since the QEmu VNC code is completely asynchronous, we have a much larger window where this race can occur. The easiest thing to do is avoid the race all together and not have your client use SetPixelFormat frequently. Please forgive my ignorance, but why is there a race condition here? You have exactly one socket open between client and server. It's a TCP socket so out-of-order delivery or missing messages is impossible. Presumably the VNC protocol does not allow you to send a message in the middle of another one. So at any given time, the process/thread that controls the socket should know exactly what pixel format it's expected to send messages, at the time of transmission, based on the last SetPixelFormat that has been dispatched. If you have multiple threads encoding messages at the same, then I can see how one thread could start encoding a block for a particular endianness, and meanwhile another thread is sending a SetPixelFormat message which would change the endianness. If that were the case, then you could have the block sender detect that SetPixelFormat had been sent, at the end of its encoding process, and start encoding again using the new pixel format. But surely the virtual graphics card would be the source of both types of messages, and surely its code runs only in a single thread? Anything else would seem bizarre to me. Thanks in advance for enlightenment. Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson < at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu Makefile
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/05/13 13:55:08 Modified files: . : Makefile Log message: Allow parallel make. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/Makefile.diff?tr1=1.99&tr2=1.100&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
