From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IUlyC-0000l3-0J for qemu-devel@nongnu.org; Mon, 10 Sep 2007 12:18:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IUlyA-0000kk-Jw for qemu-devel@nongnu.org; Mon, 10 Sep 2007 12:18:39 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IUlyA-0000kh-Eb for qemu-devel@nongnu.org; Mon, 10 Sep 2007 12:18:38 -0400 Received: from 149.red-80-37-155.staticip.rima-tde.net ([80.37.155.149] helo=claunia.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IUly9-0000rr-UA for qemu-devel@nongnu.org; Mon, 10 Sep 2007 12:18:38 -0400 Received: from localhost (localhost [127.0.0.1]) by claunia.com (Postfix) with ESMTP id 243C31E0523C for ; Mon, 10 Sep 2007 17:18:36 +0100 (BST) Received: from claunia.com ([127.0.0.1]) by localhost (hecate.claunia.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26314-07 for ; Mon, 10 Sep 2007 17:18:22 +0100 (BST) Received: from hermes (80.224.24.149.static.user.ono.com [80.224.24.149]) by claunia.com (Postfix) with ESMTP id 850411E0520A for ; Mon, 10 Sep 2007 17:18:22 +0100 (BST) Date: Fri, 07 Sep 2007 17:18:16 +0100 Subject: Re: [Qemu-devel] expose host CPU features to guests: Take 2 From: "Natalia Portillo" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <20070905174530.GA3945@karma.qumranet.com> <20070910074005.GA26869@karma.qumranet.com> <20070910120125.GA31345@karma.qumranet.com> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <20070910120125.GA31345@karma.qumranet.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi, > On Mon, Sep 10, 2007 at 12:47:51PM +0100, Natalia Portillo wrote: >> I don't see in what is it useful without KVM/KQEMU. > > It is not. I tried to be clear about it in my post. Sorry for not being > clearer. Ok now understood. >> And even with them there are some instructions that can't be accesible >> without KQEMU/KVM prepared for them. > > I suspect this is true. For example, in my patch I blocked ACPI and VMX. > Still, those features that ARE exposed to the guest, speed it up. Isn't > it the Right Thing? Well, I prefer to say "it is a right thing" :p >> And, the -cpu option, should be enabled in x86 and x86_64 to >> enable/disable emulation of instructions (and them cpuid adjusted to >> indicate them). > > I'm not sure I understand this comment. If you mean that -cpu should not > expose a feature that is not emulated by qemu, I agree. I mean there should be a -cpu 8086, 286, 386, 486, pentium, pentium2, so on If you use 8086, qemu should behave as a 16-bit real-mode only processor doing an "unknown instruction" exception on anything not defined in the 8086 real processor. And so on. And also behave, at identification (CPUID, or legacy identification), like the selected CPU (for example -cpu 486 says family 4 model x stepping y, no l2 cache, so on) This can help some operating systems that hangs on unexpected identifications (NT 3.xx is the best example, as happens also on real hardware), and identifying badly implemented instructions on behave of cpu family (for example, in pentium an OS works flawlessly, in pentium2 an OS hangs just before sending CMOV instruction). If you implement it, count with my vote for inclusion :p (As I think x86, and x86-64 are the only ones archs that still dont implement -cpu in qemu. and remember, please, x86_64 only composes from pentium4 upwards and athlon64 upwards, no sense to behave like 386 in x86-64 emulator lol) Regards