Dong, Eddie wrote:
>
>
>> Since we don't emulate 3Dnow instructions, a #UD will be
>> injected instead.
>>
>>
> OK, how many architecture specific instructiosn are emulated now?
>
Just vmcall/vmmcall (which is emulated once, then patched).
> Or what is planed to be implemented? If
Dong, Eddie wrote:
> A little bit suspicion for the usage model too :(
> The CPUID feature list can't be changed dynamically, so I doutb
> if a real user will give up performance at beginning when he/she
> starts the guest for "maybe" future migration cross host platform.
>
> A VT or SVM enabled ma
Sent: 2007年12月16日 20:50
To: Joerg Roedel
Cc: kvm-devel; Avi Kivity
Subject: Re: [kvm-devel] question on #UD emulation
Joerg Roedel wrote:
On Sun, Dec 16, 2007 at 01:32:40PM +0200, Avi Kivity wrote:
>
>Since we don't emulate 3Dnow instructions, a #UD will be
>injected instead.
>
OK, how many architecture specific instructiosn are emulated now?
Or what is planed to be implemented? If no, then adding those
emulation in KVM just means dead code.
thx,eddie
--
Joerg Roedel wrote:
On Sun, Dec 16, 2007 at 01:32:40PM +0200, Avi Kivity wrote:
> Dong, Eddie wrote:
>
> > BTW, do we need to support live migrating an AMD VM to Intel
platform or
> > vice versa
>
> Yes, it allows users to buy the machines with the best cost/performance
> ratio, rather than co
On Sun, Dec 16, 2007 at 01:32:40PM +0200, Avi Kivity wrote:
> Dong, Eddie wrote:
>
> > BTW, do we need to support live migrating an AMD VM to Intel platform or
> > vice versa
>
> Yes, it allows users to buy the machines with the best cost/performance
> ratio, rather than continue to buy machines
Dong, Eddie wrote:
> Avi/Anthony:
> Following commit added #UD trap in KVM and do emulation in KVM.
> It is good to avoid the mis hypercall instruction issue, but I am not
> sure if it will have any serious side effect. I am blind to AMD
> instruction, I assume, for example, AMD 3D now instru
