On 01/28/2010 02:43 AM, Alexander Graf wrote:
On 28.01.2010, at 09:19, Arnd Bergmann wrote:
On Monday 25 January 2010, Dor Laor wrote:
x86 qemu64
x86 phenom
x86 core2duo
x86kvm64
x86 qemu32
x86 coreduo
x86 486
x8
On Thursday 28 January 2010, Alexander Graf wrote:
> > That option IMHO should just show up as identical to the host cpu, with
> > the exception of features that are not supported in the guest.
>
> That's exactly what -cpu host is. IIRC it's the default now.
Ah, cool. Sorry for my ignorance here.
On 28.01.2010, at 09:19, Arnd Bergmann wrote:
> On Monday 25 January 2010, Dor Laor wrote:
>> x86 qemu64
>> x86 phenom
>> x86 core2duo
>> x86kvm64
>> x86 qemu32
>> x86 coreduo
>> x86 486
>> x86 pentium
>> x86
On Monday 25 January 2010, Dor Laor wrote:
> x86 qemu64
> x86 phenom
> x86 core2duo
> x86kvm64
> x86 qemu32
> x86 coreduo
> x86 486
> x86 pentium
> x86 pentium2
> x86 pentium3
> x86 athlon
> x
On 01/26/2010 02:26 AM, Gerd Hoffmann wrote:
On 01/25/10 23:35, Dor Laor wrote:
On 01/25/2010 04:21 PM, Anthony Liguori wrote:
Another way to look at this is that implementing a somewhat arbitrary
policy within QEMU's .c files is something we should try to avoid.
Implementing arbitrary policy i
On 01/25/10 23:35, Dor Laor wrote:
On 01/25/2010 04:21 PM, Anthony Liguori wrote:
Another way to look at this is that implementing a somewhat arbitrary
policy within QEMU's .c files is something we should try to avoid.
Implementing arbitrary policy in our default config file is a fine thing
to d
On 01/25/2010 04:21 PM, Anthony Liguori wrote:
On 01/25/2010 03:08 AM, Dor Laor wrote:
qemu-config.[ch], taking a new command line that parses the argument via
QemuOpts, then passing the parsed options to a target-specific function
that then builds the table of supported cpus.
It should just be
On 01/25/2010 03:08 AM, Dor Laor wrote:
qemu-config.[ch], taking a new command line that parses the argument via
QemuOpts, then passing the parsed options to a target-specific function
that then builds the table of supported cpus.
It should just be a matter of adding qemu_cpudefs_opts to
Isn't
Dor Laor wrote:
> x86 qemu64
> x86 phenom
> x86 core2duo
> x86kvm64
> x86 qemu32
> x86 coreduo
> x86 486
> x86 pentium
> x86 pentium2
> x86 pentium3
> x86 athlon
> x86 n270
I wond
On 01/21/2010 05:05 PM, Anthony Liguori wrote:
On 01/20/2010 07:18 PM, john cooper wrote:
Chris Wright wrote:
* Daniel P. Berrange (berra...@redhat.com) wrote:
To be honest all possible naming schemes for '-cpu' are just as
unfriendly as each other. The only user friendly option is '-cpu host'
On 01/21/2010 10:43 AM, john cooper wrote:
Anthony Liguori wrote:
On 01/20/2010 07:18 PM, john cooper wrote:
I can appreciate the concern of wanting to get this
as "correct" as possible.
This is the root of the trouble. At the qemu layer, we try to focus on
being correct.
Jamie Lokier wrote:
> I think we can all agree that there is no point looking for a familiar
> -cpu naming scheme because there aren't any familiar and meaningful names
> these days.
Even if we dismiss the Intel coined names as internal
code names, there is still VMW's use of them in this
space w
Jamie Lokier wrote:
> Do you mean that more powerful management tools to support safe
> migration will maintain _their own_ processor model tables, and
> perform their calculations using their own tables instead of querying
> qemu, and therefore not have any need of qemu's built in table?
I would
john cooper wrote:
> I can appreciate the argument above, however the goal was
> choosing names with some basis in reality. These were
> recommended by our contacts within Intel, are used by VmWare
> to describe their similar cpu models, and arguably have fallen
> to defacto usage as evidenced by
john cooper wrote:
> > I foresee wanting to iterate over the models and pick the latest one
> > which a host supports - on the grounds that you have done the hard
> > work of ensuring it is a reasonably good performer, while "probably"
> > working on another host of similar capability when a new ho
john cooper wrote:
> kvm itself can modify flags exported from qemu to a guest.
I would hope for an option to request that qemu doesn't run if the
guest won't get the cpuid flags requested on the command line.
-- Jamie
On Thu, Jan 21, 2010 at 2:39 PM, Andre Przywara wrote:
> john cooper wrote:
>>
>> Chris Wright wrote:
>>>
>>> * Daniel P. Berrange (berra...@redhat.com) wrote:
To be honest all possible naming schemes for '-cpu ' are just as
unfriendly as each other. The only user friendly option is
Anthony Liguori wrote:
> On 01/20/2010 07:18 PM, john cooper wrote:
>> I can appreciate the concern of wanting to get this
>> as "correct" as possible.
>>
>
> This is the root of the trouble. At the qemu layer, we try to focus on
> being correct.
>
> Management tools are typically the layer
On 01/20/2010 07:18 PM, john cooper wrote:
Chris Wright wrote:
* Daniel P. Berrange (berra...@redhat.com) wrote:
To be honest all possible naming schemes for '-cpu' are just as
unfriendly as each other. The only user friendly option is '-cpu host'.
IMHO, we should just pick a concise
john cooper wrote:
Chris Wright wrote:
* Daniel P. Berrange (berra...@redhat.com) wrote:
To be honest all possible naming schemes for '-cpu ' are just as
unfriendly as each other. The only user friendly option is '-cpu host'.
IMHO, we should just pick a concise naming scheme & document it. G
Chris Wright wrote:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
>> To be honest all possible naming schemes for '-cpu ' are just as
>> unfriendly as each other. The only user friendly option is '-cpu host'.
>>
>> IMHO, we should just pick a concise naming scheme & document it. Given
>> the
* Daniel P. Berrange (berra...@redhat.com) wrote:
> To be honest all possible naming schemes for '-cpu ' are just as
> unfriendly as each other. The only user friendly option is '-cpu host'.
>
> IMHO, we should just pick a concise naming scheme & document it. Given
> they are all equally unfriend
On 01/20/2010 02:26 PM, Daniel P. Berrange wrote:
To be honest all possible naming schemes for '-cpu' are just as
unfriendly as each other. The only user friendly option is '-cpu host'.
IMHO, we should just pick a concise naming scheme& document it. Given
they are all equally unfriendly, the on
On Wed, Jan 20, 2010 at 03:09:53PM -0500, john cooper wrote:
> Anthony Liguori wrote:
> > On 01/19/2010 02:03 PM, Chris Wright wrote:
> >> * Anthony Liguori (anth...@codemonkey.ws) wrote:
> >>
> >>> I'm very much against having -cpu Nehalem. The whole point of this is
> >>> to make things easie
Jamie Lokier wrote:
> john cooper wrote:
>> As before a cpu feature 'check' option is added which warns when
>> feature flags (either implicit in a cpu model or explicit on the
>> command line) would have otherwise been quietly unavailable to a
>> guest:
>>
>> # qemu-system-x86_64 ... -cpu Neha
Anthony Liguori wrote:
> On 01/19/2010 02:03 PM, Chris Wright wrote:
>> * Anthony Liguori (anth...@codemonkey.ws) wrote:
>>
>>> I'm very much against having -cpu Nehalem. The whole point of this is
>>> to make things easier for a user and for most of the users I've
>>> encountered, -cpu Nehalem
Jamie Lokier wrote:
> Anthony Liguori wrote:
>> On 01/18/2010 10:45 AM, john cooper wrote:
>>> x86 Conroe Intel Celeron_4x0 (Conroe/Merom Class Core 2)
>>> x86 Penryn Intel Core 2 Duo P9xxx (Penryn Class Core 2)
>>> x86 Nehalem Intel Core i7 9xx (Nehalem
On Wed, Jan 20, 2010 at 08:21:44AM -0600, Anthony Liguori wrote:
> On 01/19/2010 06:15 PM, Chris Wright wrote:
> >* Anthony Liguori (anth...@codemonkey.ws) wrote:
> >>On 01/19/2010 02:03 PM, Chris Wright wrote:
> >>>* Anthony Liguori (anth...@codemonkey.ws) wrote:
> >>>
> I'm very much against
On 01/19/2010 06:15 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
On 01/19/2010 02:03 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
I'm very much against having -cpu Nehalem. The whole point of this is
to make things eas
Anthony Liguori wrote:
> On 01/19/2010 02:03 PM, Chris Wright wrote:
> >* Anthony Liguori (anth...@codemonkey.ws) wrote:
> >
> >>I'm very much against having -cpu Nehalem. The whole point of this is
> >>to make things easier for a user and for most of the users I've
> >>encountered, -cpu Nehale
* Anthony Liguori (anth...@codemonkey.ws) wrote:
> On 01/19/2010 02:03 PM, Chris Wright wrote:
>> * Anthony Liguori (anth...@codemonkey.ws) wrote:
>>
>>> I'm very much against having -cpu Nehalem. The whole point of this is
>>> to make things easier for a user and for most of the users I've
>>
On 01/19/2010 02:03 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
I'm very much against having -cpu Nehalem. The whole point of this is
to make things easier for a user and for most of the users I've
encountered, -cpu Nehalem is just as obscure as -cpu
qemu64,-sse
* Jamie Lokier (ja...@shareable.org) wrote:
> Chris Wright wrote:
> > * Anthony Liguori (anth...@codemonkey.ws) wrote:
> > > I'm very much against having -cpu Nehalem. The whole point of this is
> > > to make things easier for a user and for most of the users I've
> > > encountered, -cpu Nehal
john cooper wrote:
> As before a cpu feature 'check' option is added which warns when
> feature flags (either implicit in a cpu model or explicit on the
> command line) would have otherwise been quietly unavailable to a
> guest:
>
> # qemu-system-x86_64 ... -cpu Nehalem,check
> warning: ho
Chris Wright wrote:
> * Anthony Liguori (anth...@codemonkey.ws) wrote:
> > I'm very much against having -cpu Nehalem. The whole point of this is
> > to make things easier for a user and for most of the users I've
> > encountered, -cpu Nehalem is just as obscure as -cpu
> > qemu64,-sse3,+vmx,.
Anthony Liguori wrote:
> On 01/18/2010 10:45 AM, john cooper wrote:
> > x86 Conroe Intel Celeron_4x0 (Conroe/Merom Class Core 2)
> > x86 Penryn Intel Core 2 Duo P9xxx (Penryn Class Core 2)
> > x86 Nehalem Intel Core i7 9xx (Nehalem Class Core i7)
> >
* Anthony Liguori (anth...@codemonkey.ws) wrote:
> I'm very much against having -cpu Nehalem. The whole point of this is
> to make things easier for a user and for most of the users I've
> encountered, -cpu Nehalem is just as obscure as -cpu
> qemu64,-sse3,+vmx,...
What name will these users
On 01/18/2010 10:45 AM, john cooper wrote:
This is a rework of the prior version which adds definitions
for contemporary processors selected via -cpu, as an
alternative to the existing use of "-cpu qemu64" augmented
with a series of feature flags.
The primary motivation was determination of a le
This is a rework of the prior version which adds definitions
for contemporary processors selected via -cpu , as an
alternative to the existing use of "-cpu qemu64" augmented
with a series of feature flags.
The primary motivation was determination of a least common
denominator within a given proces
john cooper wrote:
> {
> +.name = "Merom",
> +.level = 2,
> +.vendor1 = CPUID_VENDOR_INTEL_1,
> +.vendor2 = CPUID_VENDOR_INTEL_2,
> +.vendor3 = CPUID_VENDOR_INTEL_3,
> +.family = 6, /* P6 */
> +.model = 2,
> +.stepping = 3,
> +
On 12/21/2009 08:46 AM, john cooper wrote:
This adds definitions for contemporary processors
which may be selected via -cpu, as an
alternative to the existing use of -cpu qemu64
augmented with a series of feature flags.
The primary motivation was determination of a
least common denominator withi
This adds definitions for contemporary processors
which may be selected via -cpu , as an
alternative to the existing use of -cpu qemu64
augmented with a series of feature flags.
The primary motivation was determination of a
least common denominator within a given processor
class for simplification
42 matches
Mail list logo
