On Mon, Aug 5, 2013 at 2:46 AM, Jan Kiszka <jan.kiszka@xxxxxx> wrote:
> On 2013-08-04 20:25, Gmail wrote:
>> 在 2013-8-5，2:08，Jan Kiszka <jan.kiszka@xxxxxx> 写道：
>>
>>> On 2013-08-04 20:04, Arthur Chunqi Li wrote:
>>>> @@ -432,6 +432,22 @@ enum Ctrl1 {
>>>> #define HYPERCALL_MASK 0xFFF
>>>> #define HYPERCALL_VMEXIT 0x1
>>>>
>>>> +
>>>> +extern u64 hypercall_field;
>>>> +extern u32 vpid_cnt;
>>>> +extern ulong fix_cr0_set, fix_cr0_clr;
>>>> +extern ulong fix_cr4_set, fix_cr4_clr;
>>>> +extern struct regs regs;
>>>> +extern struct vmx_test *current;
>>>> +extern bool launched;
>>>
>>> You didn't address my question if we need them all to write test cases
>>> or if some are actually core internal.
>> You are right. Not all global variants in last version is necessary for test cases, so I move some of them to vmx.c internal. The rest ones in this version are needed by tests to identify some states.
>
> I can imagine 'regs' very well, but I've doubt about the rest.
> 'current', 'launched'? Again, rather export on demand than in advance.
Yes, currently we only use 'regs'. I supposed that some of them "may"
used in the future. It's better to export on demand than in advance.
>
> Two additional questions, not directly related to the patch:
>
> 1. hypercall_field - why not passing this parameter via a register?
> Helps in case you have multiple guests running.
Passing param via registers will use at least one register and thus
the handling codes in exit handler will not get the whole registers
state. For multiple guests, we can simply move hypercall_field to the
guest related structure and every guest has its own one.
>
> 2. vpid_cnt - what's the purpose, why writing VPID at all? It's not
> needed, and not even supported on some CPUs.
Well, I was not quite sure if this is necessary when I write the first
version, while SDM says some initial affairs about it so I reserved
such a variant.
Arthur
>
> Jan
>
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
