Paul Brook wrote:
What you really want to do is ask your virtualization module what
features it supports.
Yes, that needs to be an additional filter.
I'd have thought that would be the *only* interesting set for autodetection.
If that means the same as the features which are
Avi Kivity wrote:
Well, the guest will invoke its own workaround logic to disable buggy
features, so I see no issue here.
The guest can only do this if it has exactly the correct id
information for the host processor (e.g. This is an Intel Pentium Pro
model XXX), not just the list of safe to
Avi Kivity wrote:
Let's start with '-cpu host' as 'cpu host-cpuid' and implement '-cpu
host-os' on the first bug report? I have a feeling we won't ever see it.
I have a feeling you won't ever see it either, but not because it's a
missing feature.
Instead, I think a very small number of users
Jamie Lokier wrote:
Avi Kivity wrote:
Let's start with '-cpu host' as 'cpu host-cpuid' and implement '-cpu
host-os' on the first bug report? I have a feeling we won't ever see it.
I have a feeling you won't ever see it either, but not because it's a
missing feature.
Instead, I
On Sunday 09 September 2007, Jamie Lokier wrote:
Avi Kivity wrote:
Let's start with '-cpu host' as 'cpu host-cpuid' and implement '-cpu
host-os' on the first bug report? I have a feeling we won't ever see it.
In other words, host-os is what _I'd_ implement because I care too
much about
Avi Kivity wrote:
I agree. If the host OS has disabled a feature, it's a fair bet it's done
that for a reason.
The reason may not be relevant to the guest.
For most guests the relevant features are those which work correctly
and efficiently on the virtual CPU.
If the host OS has disabled a
What you really want to do is ask your virtualization module what
features it supports.
Yes, that needs to be an additional filter.
I'd have thought that would be the *only* interesting set for autodetection.
Paul
-
Paul Brook wrote:
What you really want to do is ask your virtualization module what
features it supports.
Yes, that needs to be an additional filter.
I'd have thought that would be the *only* interesting set for autodetection.
Yes, you're right. It's pointless to issue
Anthony Liguori wrote:
I like this idea but I have some suggestions about the general approach.
I think instead of defining another machine type, it would be better to
just have a command line option like -cpuid that took a comma separate
string of features with all meaning all features that
Paul Brook wrote:
I think qemu-cvs has a -cpu option for non-x86 which could be used for
this. Agree machine types are the wrong approach.
Yep, machine types are already used to switch between a different concept
so using the new -cpu option would make sense. Could perhaps extend the
I think qemu-cvs has a -cpu option for non-x86 which could be used for
this. Agree machine types are the wrong approach.
Yep, machine types are already used to switch between a different concept
so using the new -cpu option would make sense. Could perhaps extend the
syntax so that
11 matches
Mail list logo
