From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: gross qemu behavior Date: Fri, 04 Apr 2014 11:34:20 +0200 Message-ID: <533E7C9C.7000709@redhat.com> References: <5335376102000078000033DA@nat28.tlf.novell.com> <53394C620200007800003AE8@nat28.tlf.novell.com> <533E712D02000078000057CE@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WW0W9-0008CZ-Pk for xen-devel@lists.xenproject.org; Fri, 04 Apr 2014 09:34:34 +0000 In-Reply-To: <533E712D02000078000057CE@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Stefano Stabellini Cc: anthony.perard@citrix.com, xen-devel List-Id: xen-devel@lists.xenproject.org Il 04/04/2014 08:45, Jan Beulich ha scritto: > Implying that any execution of code in the ROM would be fully > emulated. ROM is never executed in place. It is always copied to low RAM and executed from there. It might slow down the copy. In fact, on AMD it is not always possible to execute from ROM; if the ROM includes page tables, as was the case for example for 64-bit OVMF, it crashes because NPT expects page tables to be in writable guest memory. > Very odd, but fitting the picture of trying to be as slow > as possible (in the context of the breakage introduced by > ef437690 "x86/HVM: correct CPUID leaf 80000008 handling" I > had to run qemu-traditional and qemu-upstream, and the > performance of the guest visibly _much_ better with the former, > which I consider rather worrying). That's quite unexpected. What was your configuration and workload? And what was slower exactly? Disk, network or video (as an initial simplification). Paolo