From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19VoDN-0001QQ-Lf for qemu-devel@nongnu.org; Fri, 27 Jun 2003 04:04:13 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19Vo9H-0007XR-NY for qemu-devel@nongnu.org; Fri, 27 Jun 2003 04:00:00 -0400 Received: from host244-0.pool80116.interbusiness.it ([80.116.0.244] helo=dragas.dyndns.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Vo4n-0003XT-AR for qemu-devel@nongnu.org; Fri, 27 Jun 2003 03:55:23 -0400 Date: Fri, 27 Jun 2003 09:54:18 +0200 From: Stefano Marinelli Subject: Re: [Qemu-devel] Qemu is a wonderful (and presentation) Message-ID: <20030627075418.GA25234@dragas.dyndns.org> References: <20030626155242.GA20861@dragas.dyndns.org> <3EFB2E1D.8000502@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EFB2E1D.8000502@free.fr> Reply-To: qemu-devel@nongnu.org List-Id: List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , To: qemu-devel@nongnu.org On Thu, Jun 26, 2003 at 07:32:13PM +0200, Fabrice Bellard wrote: > 1) Some weird x86 instructions or behaviors are still lacking (for > example: full task gate support, call gates, segment limit checks). It > is easy to add but difficult to debug, especially if you don't have the > source code of the guest OS. I understand...something strange could happen and we aren't able to find out what and why... > 2) If the guest OS wants access to memory beyond 0xc0000000, the current > MMU emulation won't work. It can be solved by using a software MMU > emulation (slower) or by using various tricks with the segment registers > provided the guest OS does not use the full address range. The software > MMU will be implemented someday as some people need it to have an exact > full system emulation. For the rest, it depends on the number of people > who ask it :-) The optimal solution would require a tricky host kernel > patch, but in this case it can be more tempting to use plex86. Ok,I see. I think that the kernel patch should be the last resort, since it would be better to be able to launch an unpatched kernel (it would be quite difficult to launch closed source operating systems).Currently the emulation speed is really high...I think that a well implemented software MMU won't slow down too much (the system would be still well usable). And, if it will be made by you, I'm sure it will be a good piece of software :) > unless many people ask it. Another solution is to integrate QEMU in > bochs to reuse all its PC hardware emulation stuff. This could be a good idea. bochs hardware emulation is well done, the teacher show's following me with my thesis programmed the tun/tap module :) Anyway, do you think that an integration with bochs will be difficult to do? In this way, bochs could be improved on x86 and PPC. VMWare is great, while (for now) there isn't anything similar in the Open Source world (well MacONLinux, but it's only for Mac) > Currently, I think launching *BSD would not require many changes (maybe > it already works - I did not test. If you give me a working image I can > look at it). I may add IDE emulation soon as it can be quite useful even > with Linux. I understand. I'd like to try to produce a *BSD image to see what happens. Anyway, thanks for replying in a so complete way and thanks for this wonderful software you're doing. I hope I'll have the possibility to do something for this project :) -- ------------------------------------------------- Stefano Marinelli -------------------------------------------------