From: Andre Przywara <andre.przywara@amd.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Avi Kivity <avi@redhat.com>,
Ricardo Martins <ricardo.martins.br@gmail.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: KVM Processor cache size
Date: Tue, 3 Aug 2010 00:54:59 +0200 [thread overview]
Message-ID: <4C574CC3.2040703@amd.com> (raw)
In-Reply-To: <4C5745BC.30908@codemonkey.ws>
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? Actually this is a default scenario for native
machines and CPUID was introduced for applications to adapt to this.
So if you leave migration aside, -cpu host is actually the natural way.
Regards,
Andre.
--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 488-3567-12
next prev parent reply other threads:[~2010-08-02 22:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-02 11:45 KVM Processor cache size Ricardo Martins
2010-08-02 12:51 ` Andre Przywara
2010-08-02 13:08 ` Avi Kivity
2010-08-02 22:22 ` Anthony Liguori
2010-08-02 22:35 ` Andre Przywara
2010-08-02 23:38 ` Anthony Liguori
2010-08-03 5:38 ` Avi Kivity
2010-08-03 5:33 ` Avi Kivity
2010-08-02 22:25 ` Anthony Liguori
2010-08-02 22:54 ` Andre Przywara [this message]
2010-08-02 23:40 ` Anthony Liguori
2010-08-03 5:41 ` Avi Kivity
2010-08-02 13:49 ` Ulrich Drepper
2010-08-02 18:38 ` Ricardo Martins
2010-08-02 22:24 ` Andre Przywara
2010-08-02 22:15 ` Andre Przywara
2010-08-02 22:23 ` Anthony Liguori
2010-08-02 22:42 ` Andre Przywara
2010-08-02 23:36 ` Anthony Liguori
2010-08-03 6:25 ` Dor Laor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C574CC3.2040703@amd.com \
--to=andre.przywara@amd.com \
--cc=anthony@codemonkey.ws \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=ricardo.martins.br@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox