Jamie Lokier wrote:
Jocelyn Mayer wrote:
Well, it may be needed to integrate the "-cpu host" option.
But I think it's a really bad idea that running qemu without the -cpu
option would not act the same on different host. When I want to test
qemu with the same command line, I want it to behave
Jocelyn Mayer wrote:
> Well, it may be needed to integrate the "-cpu host" option.
> But I think it's a really bad idea that running qemu without the -cpu
> option would not act the same on different host. When I want to test
> qemu with the same command line, I want it to behave exactly the same,
On Tue, Sep 25, 2007 at 03:07:44PM +0200, Jocelyn Mayer wrote:
> > So, running qemu without any parameters would use host capabilities if
> > kvm is available and the default qemu cpu if not. The -cpu option can
> > be used to override this if necessary.
>
> Well, it may be needed to integrate th
Paul Brook wrote:
Indeed for regular qemu this is useless. But it is useful for kqemu
(for which there is support in mainline qemu), and for kvm (which we
hope to merge one day).
And, as discussed before, it should be asking the hypervisor what features it
supports instead of trying to g
Jocelyn Mayer wrote:
On Tue, 2007-09-25 at 13:36 +0200, Avi Kivity wrote:
J. Mayer wrote:
On Tue, 2007-09-25 at 12:40 +0200, Avi Kivity wrote:
Avi Kivity wrote:
I've got a remark about this: why this has to be added to the
On Tue, 2007-09-25 at 13:36 +0200, Avi Kivity wrote:
> J. Mayer wrote:
> > On Tue, 2007-09-25 at 12:40 +0200, Avi Kivity wrote:
> >
> >> Avi Kivity wrote:
> >>
> >
> >
> >
> I've got a remark about this: why this has to be added to the Qemu
> cod
On Tuesday 25 September 2007, Avi Kivity wrote:
> J. Mayer wrote:
> > On Tue, 2007-09-25 at 11:01 +0200, Avi Kivity wrote:
> >> Dan Kenigsberg wrote:
> >>> On Tue, Sep 25, 2007 at 03:28:24AM +0200, andrzej zaborowski wrote:
> Hi,
>
> On 24/09/2007, Dan Kenigsberg <[EMAIL PROTECTED]>
Avi Kivity wrote:
J. Mayer wrote:
On Tue, 2007-09-25 at 12:40 +0200, Avi Kivity wrote:
Avi Kivity wrote:
I've got a remark about this: why this has to be added to the Qemu
code ?
Imho, all is needed is an implementation of the -cpu option for
x86/x86_64 target. Th
J. Mayer wrote:
> On Tue, 2007-09-25 at 12:40 +0200, Avi Kivity wrote:
>
>> Avi Kivity wrote:
>>
>
>
>
I've got a remark about this: why this has to be added to the Qemu
code ?
Imho, all is needed is an implementation of the -cpu option for
On Tue, 2007-09-25 at 12:40 +0200, Avi Kivity wrote:
> Avi Kivity wrote:
> >>>
> >>>
> >> I've got a remark about this: why this has to be added to the Qemu
> >> code ?
> >> Imho, all is needed is an implementation of the -cpu option for
> >> x86/x86_64 target. Then, an external tool (e
Avi Kivity wrote:
>>>
>>>
>> I've got a remark about this: why this has to be added to the Qemu
>> code ?
>> Imho, all is needed is an implementation of the -cpu option for
>> x86/x86_64 target. Then, an external tool (even a shell script) can be
>> used to determine what is the host CP
andrzej zaborowski wrote:
Hi,
On 24/09/2007, Dan Kenigsberg <[EMAIL PROTECTED]> wrote:
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
J. Mayer wrote:
> On Tue, 2007-09-25 at 11:01 +0200, Avi Kivity wrote:
>
>> Dan Kenigsberg wrote:
>>
>>> On Tue, Sep 25, 2007 at 03:28:24AM +0200, andrzej zaborowski wrote:
>>>
>>>
Hi,
On 24/09/2007, Dan Kenigsberg <[EMAIL PROTECTED]> wrote:
On Tue, 2007-09-25 at 11:01 +0200, Avi Kivity wrote:
> Dan Kenigsberg wrote:
> > On Tue, Sep 25, 2007 at 03:28:24AM +0200, andrzej zaborowski wrote:
> >
> >> Hi,
> >>
> >> On 24/09/2007, Dan Kenigsberg <[EMAIL PROTECTED]> wrote:
> >>
> >>> As with previous "Takes" of this patch, its purpose
Dan Kenigsberg wrote:
> On Tue, Sep 25, 2007 at 03:28:24AM +0200, andrzej zaborowski wrote:
>
>> Hi,
>>
>> On 24/09/2007, Dan Kenigsberg <[EMAIL PROTECTED]> wrote:
>>
>>> As with previous "Takes" of this patch, its purpose is to expose host
>>> +{
>>> +asm("cpuid"
>>> +: "=a" (*
On Tue, Sep 25, 2007 at 03:28:24AM +0200, andrzej zaborowski wrote:
> Hi,
>
> On 24/09/2007, Dan Kenigsberg <[EMAIL PROTECTED]> wrote:
> > As with previous "Takes" of this patch, its purpose is to expose host
> > +{
> > +asm("cpuid"
> > +: "=a" (*ax),
> > + "=b" (*bx),
> > +
Hi,
On 24/09/2007, Dan Kenigsberg <[EMAIL PROTECTED]> wrote:
> 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
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
On Friday 07 September 2007, Natalia Portillo wrote:
> and remember, please, x86_64 only composes from pentium4 upwards and
> athlon64 upwards, no sense to behave like 386 in x86-64 emulator lol)
Actually, there is. Isn't the x86_64 emulator required to use kqemu on x86_64?
Or does the -cpu 486 o
Dan Kenigsberg wrote:
> On Mon, Sep 10, 2007 at 12:47:51PM +0100, Natalia Portillo wrote:
> > I don't see in what is it useful without KVM/KQEMU.
>
> It is not. I tried to be clear about it in my post. Sorry for not being
> clearer.
Some day it may be useful without KVM/KQEMU, but not for a long
Hi,
On Mon, Sep 10, 2007 at 12:47:51PM +0100, Natalia Portillo wrote:
I don't see in what is it useful without KVM/KQEMU.
It is not. I tried to be clear about it in my post. Sorry for not being
clearer.
Ok now understood.
And even with them there are some instructions that can't be accesib
On Mon, Sep 10, 2007 at 12:47:51PM +0100, Natalia Portillo wrote:
> I don't see in what is it useful without KVM/KQEMU.
It is not. I tried to be clear about it in my post. Sorry for not being
clearer.
> And even with them there are some instructions that can't be accesible
> without KQEMU/KVM p
I don't see in what is it useful without KVM/KQEMU.
And even with them there are some instructions that can't be accesible
without KQEMU/KVM prepared for them.
And, the -cpu option, should be enabled in x86 and x86_64 to
enable/disable emulation of instructions (and them cpuid adjusted to
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
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
25 matches
Mail list logo
