Re: [kvm-devel] [PATCH] KVM: emulator: Only allow VMCALL/VMMCALL trapped by #UD

[Dong, E. <edd...@in...>]

Avi Kivity wrote:
> Dong, Eddie wrote:
>>>>> If migration happens while rip is in the hypercall page, and if
>>>>> the=20
>>>>>=20
>>>>>=20
>>>> I didn't quit catch here. The source VM vCPU is in Qemu migration
>>>> part, The target VM VCPU is always waiting for migration
>>>> data/command. If you mean SMP case, all target VCPUs are in waiting
>>>> for data/cmd, and I assume source VCPUs are all in Qemu known
>>>> state, not?=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>> I'm talking about the guest rip.  The guest is not aware of the
>>> migration.=20
>>>=20
>>> Suppose that on the last copy that the guest rip is
>>> (hypercall_page_virt + 3).  This address might be in the middle of
>>> some instruction on the hypercall page on the target machine.  You
>>> need to fix up rip and=20
>>>=20
>>=20
>> This depends on how the hypercall page instruction is generated.
>> In Xen's construction, the code in hypercall page is exactly same
>> between SVM & VMX except the VMCALL/VMMCALL instruction itself.
>>=20
>>=20
>=20
> If you make the assumption that the hypercall is a single 3-byte

Mmm, I am not and actually it doesn't care what opcode is used=20
and how long it is. We need to assume the pre-instructions and post
instructions are same, and it is totally in VMM plate.

Well, using #UD to emulate cross-architecture VMCALL/VMMCALL
need to assume the opcode won't be used in other architecture.

> instruction, then you might as well patch it directly.  Of course it
> depends on Intel and AMD not reusing each other's opcodes. =20

Besides the opcode concern and potential bug like Eric & Sheng fixed,
 the performance of using #UD method is worse than using hypercall page.

thx,eddie