From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: KVM Processor cache size Date: Mon, 02 Aug 2010 18:40:38 -0500 Message-ID: <4C575776.30106@codemonkey.ws> References: <4C56BF6F.9040402@amd.com> <4C56C353.7020607@redhat.com> <4C5745BC.30908@codemonkey.ws> <4C574CC3.2040703@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Ricardo Martins , "kvm@vger.kernel.org" To: Andre Przywara Return-path: Received: from mail-iw0-f174.google.com ([209.85.214.174]:49201 "EHLO mail-iw0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750836Ab0HBXkn (ORCPT ); Mon, 2 Aug 2010 19:40:43 -0400 Received: by iwn7 with SMTP id 7so4530234iwn.19 for ; Mon, 02 Aug 2010 16:40:43 -0700 (PDT) In-Reply-To: <4C574CC3.2040703@amd.com> Sender: kvm-owner@vger.kernel.org List-ID: On 08/02/2010 05:54 PM, Andre Przywara wrote: > Anthony Liguori wrote: >> On 08/02/2010 08:08 AM, Avi Kivity wrote: >>> On 08/02/2010 03:51 PM, Andre Przywara wrote: >>>> I sent a patch to include the cache size when using -cpu host, but >>>> this has been n'acked because the benefit is not clear. >>> Anthony, why was this NACKed? First, there are programs which query >>> the cache size. That's why it's exposed! Second, -cpu host is for >>> exposing as many host cpu features as we can, not just those we have >>> an immediate use for. It's like 'cp -a' dropping attributes the >>> author didn't care about. >> >> That's exactly what the code does today BTW. The kernel module >> filters cpuid flags, qemu filters additional flags, and we don't pass >> everything through anyway. >> >> -cpu host is a mess and needs some love. > The mentioned patch addresses this to some degree, where it creates a > list of CPUID leafs which can be safely passed through. There are some > which we should not (and sometimes must not) propagate (think of host > topology and power management), but these should not block the useful > ones. CPUID transports a lot of different information, so we should > also distinguish here. > >> It's impossible to use correctly today in a production environment if >> you care about reliably generating the same guest visible interface. > Do you mean by this that the guest sees a different CPU model on each > host it is started? No, I mean that even if you say -cpu host and record feature flags of the machine your own, since we mask out certain features in both QEMU and KVM, the resulting set of features is not discoverable which means you can't recreate them somewhere else. > Actually this is a default scenario for native machines and CPUID was > introduced for applications to adapt to this. Yes, but virtualization is not supposed to expose the underlying hardware. The vendor_id bit is a harder problem that I'm willing to ignore in this discussion. I understand why we have to do this today. Regards, Anthony Liguori > So if you leave migration aside, -cpu host is actually the natural way. > > Regards, > Andre. >