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 a
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 point
> > 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
--
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 disab
Paul Brook wrote:
> 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
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 a
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.
>
>
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 user
Jamie Lokier wrote:
> 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 Pr
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 t
Jamie Lokier wrote:
> 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 wi
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 t
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 perhap
> > 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
14 matches
Mail list logo
