As with previous "Takes" of this patch, its purpose is to expose host
CPU features to guests. It proved rather helpful to KVM in various
benchmarks, and it should similarly speed kqemu up. Note that it does
not extend the set of emulated opcodes, only exposes what's supported by
the host CPU.
Anot
As with Take 1 of this patch, its purpose is to expose host CPU features to
guests. It proved rather helpful to KVM in various benchmarks, and it should
similarly speed kqemu up. Note that it does not extend the set of emulated
opcodes, only exposes what's supported by the host CPU.
I changed the
On Wed, Sep 05, 2007 at 10:34:45PM +0300, Avi Kivity wrote:
> Anthony Liguori wrote:
> > On Wed, 2007-09-05 at 20:45 +0300, [EMAIL PROTECTED] wrote:
> >
> >> Hi,
> >>
> >> It's a pity not to use a host CPU feature if it is available. This patch
> >> exposes host CPU features to guests. It allows
Anthony Liguori wrote:
> On Wed, 2007-09-05 at 20:45 +0300, [EMAIL PROTECTED] wrote:
>
>> Hi,
>>
>> It's a pity not to use a host CPU feature if it is available. This patch
>> exposes host CPU features to guests. It allows fine-tuning the presented
>> features from the command-line.
>>
>> The co
On Wed, 2007-09-05 at 20:45 +0300, [EMAIL PROTECTED] wrote:
> Hi,
>
> It's a pity not to use a host CPU feature if it is available. This patch
> exposes host CPU features to guests. It allows fine-tuning the presented
> features from the command-line.
>
> The code could use some serious clean ups
Hi,
It's a pity not to use a host CPU feature if it is available. This patch
exposes host CPU features to guests. It allows fine-tuning the presented
features from the command-line.
The code could use some serious clean ups, but I think it is interesting
enough right now. I'd be happy to hear you