From: Jan Kiszka <jan.kiszka@web.de>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Cc: "Alexey Zaytsev" <alexey.zaytsev@gmail.com>,
kvm <kvm@vger.kernel.org>,
"Marcelo Tosatti" <mtosatti@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"Avi Kivity" <avi@redhat.com>,
"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH 2/2] Expose tsc deadline timer cpuid to guest
Date: Fri, 09 Mar 2012 21:52:29 +0100 [thread overview]
Message-ID: <4F5A6D8D.2040104@web.de> (raw)
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350D749C@SHSMSX101.ccr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 4644 bytes --]
On 2012-03-09 20:09, Liu, Jinsong wrote:
> Jan Kiszka wrote:
>> On 2012-03-09 19:27, Liu, Jinsong wrote:
>>> Jan Kiszka wrote:
>>>> On 2012-03-06 08:49, Liu, Jinsong wrote:
>>>>> Jan,
>>>>>
>>>>> Any comments? I feel some confused about your point 'disable cpuid
>>>>> feature for older machine types by default': are you planning a
>>>>> common approach for this common issue, or, you just ask me a
>>>>> specific solution for the tsc deadline timer case?
>>>>
>>>> I think a generic solution for this can be as simple as passing a
>>>> feature exclusion mask to cpu_init. You could simple append a string
>>>> of "-feature1,-feature2" to the cpu model that is specified on
>>>> creation. And that string could be defined in the compat machine
>>>> descriptions. Does this make sense?
>>>>
>>>
>>> Jan, to prevent misunderstanding, I elaborate my understanding of
>>> your points below (if any misunderstanding please point out to me):
>>> =====================
>>> Your target is, to migrate from A(old qemu) to B(new qemu) by
>>> 1. at A: qemu-version-A [-cpu whatever] // currently the
>>> default machine type is pc-A
>>> 2. at B: qemu-version-B -machine pc-A [-cpu whatever] -feature1
>>> -feature2
>>>
>>> B run new qemu-version-B (w/ new features 'feature1' and
>>> 'feature2'), but when B runs w/ compat '-machine pc-A', vm should
>>> not see 'feature1' and 'feature2', so commandline append string to
>>> cpu model '-cpu whatever -feature1 -feature2' to hidden new feature1
>>> and feature2 to vm, hence vm can see same cpuid features (at B) as
>>> those at A (which means, no feature1, no feature2)
>>> =====================
>>>
>>> If my understanding of your thoughts is right, I think currently
>>> qemu has satisfied your target, code refer to
>>> pc_cpus_init(cpu_model) ...... cpu_init(cpu_model)
>>> --> cpu_x86_register(*env, cpu_model)
>>> --> cpu_x86_find_by_name(*def, cpu_model) // parse '+/-
>>>
>>> features', generate feature masks plus_features... // and
>>> minus_features...(this is feature exclusion masks you want)
>>> I think your point 'define in the compat machine description' is
>>> unnecessary.
>>
>> The user would have to specify the new feature as exclusions
>> *manually* on the command line if -machine pc-A doesn't inject them
>> *automatically*. So it is necessary to enhance qemu in this regard.
>>
>
> ... You suggest 'append a string of "-feature1,-feature2" to the cpu model that is specified on creation' at your last email.
> Could you tell me other way user exclude features? I only know qemu command line :-(
I was thinking of something like
diff --git a/hw/boards.h b/hw/boards.h
index 667177d..2bae071 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -28,6 +28,7 @@ typedef struct QEMUMachine {
int is_default;
const char *default_machine_opts;
GlobalProperty *compat_props;
+ const char *compat_cpu_features;
struct QEMUMachine *next;
} QEMUMachine;
diff --git a/hw/pc.c b/hw/pc.c
index bb9867b..4d11559 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -949,8 +949,9 @@ static CPUState *pc_new_cpu(const char *cpu_model)
return env;
}
-void pc_cpus_init(const char *cpu_model)
+void pc_cpus_init(const char *cpu_model, const char *append_features)
{
+ char *model_and_features;
int i;
/* init CPUs */
@@ -961,10 +962,13 @@ void pc_cpus_init(const char *cpu_model)
cpu_model = "qemu32";
#endif
}
+ model_and_features = g_strconcat(cpu_model, ",", append_features, NULL);
for(i = 0; i < smp_cpus; i++) {
- pc_new_cpu(cpu_model);
+ pc_new_cpu(model_and_features);
}
+
+ g_free(model_and_features);
}
void pc_memory_init(MemoryRegion *system_memory,
However, getting machine.compat_cpu_features to pc_cpus_init is rather
ugly. And we will have CPU devices with real properties soon. Then the
compat feature string could be passed that way, without changing any
machine init function.
Andreas, do you expect CPU devices to be ready for qemu 1.1? We would
need them to pass a feature exclusion mask from machine.compat_props to
the (x86) CPU init code.
Well, given that introducing some intermediate solution for this would
be complex and hacky and that there is a way to configure tsc_deadline
for old machines away, though only an explicit one, I could live with
postponing the feature mask after the CPU device conversion. But the
last word will have the maintainers.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2012-03-09 20:52 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-28 21:55 [Qemu-devel] [PATCH 2/2] Expose tsc deadline timer cpuid to guest Liu, Jinsong
2012-01-04 16:48 ` Jan Kiszka
2012-01-05 20:07 ` Liu, Jinsong
2012-01-05 20:34 ` Jan Kiszka
2012-01-07 18:23 ` Liu, Jinsong
2012-01-08 21:24 ` Jan Kiszka
2012-02-27 16:05 ` Liu, Jinsong
2012-02-27 17:18 ` Jan Kiszka
2012-02-28 10:30 ` Liu, Jinsong
2012-03-06 7:49 ` Liu, Jinsong
2012-03-06 10:14 ` Jan Kiszka
2012-03-09 18:27 ` Liu, Jinsong
2012-03-09 18:56 ` Jan Kiszka
2012-03-09 19:09 ` Liu, Jinsong
2012-03-09 20:52 ` Jan Kiszka [this message]
2012-03-10 1:07 ` Andreas Färber
2012-03-11 18:54 ` Liu, Jinsong
2012-03-12 17:21 ` Eduardo Habkost
2012-03-25 8:51 ` Liu, Jinsong
2012-03-09 19:29 ` Liu, Jinsong
2012-03-19 22:35 ` Rik van Riel
2012-03-20 12:53 ` Liu, Jinsong
2012-03-20 13:33 ` Eduardo Habkost
2012-03-23 3:49 ` Liu, Jinsong
2012-03-23 13:46 ` Eduardo Habkost
2012-03-23 14:17 ` Liu, Jinsong
[not found] <20120419200331.GB19463@otherpad.lan.raisama.net>
[not found] ` <4F913696.20301@siemens.com>
[not found] ` <20120420150005.GW3169@otherpad.lan.raisama.net>
[not found] ` <4F917E75.2080003@siemens.com>
[not found] ` <20120420153656.GX3169@otherpad.lan.raisama.net>
[not found] ` <4F926086.3020307@web.de>
[not found] ` <20120423144818.GA3169@otherpad.lan.raisama.net>
[not found] ` <4F9583DD.10807@siemens.com>
[not found] ` <20120423200214.GG3169@otherpad.lan.raisama.net>
[not found] ` <4F96CF9F.9060302@siemens.com>
[not found] ` <20120424171925.GT3169@otherpad.lan.raisama.net>
2012-06-14 19:02 ` Liu, Jinsong
2012-06-14 19:12 ` Eduardo Habkost
2012-06-14 19:18 ` Liu, Jinsong
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=4F5A6D8D.2040104@web.de \
--to=jan.kiszka@web.de \
--cc=afaerber@suse.de \
--cc=alexey.zaytsev@gmail.com \
--cc=avi@redhat.com \
--cc=jinsong.liu@intel.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=qemu-devel@nongnu.org \
/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;
as well as URLs for NNTP newsgroup(s).