El 13/07/15 a les 16.01, Jan Beulich ha escrit:
>>>> On 03.07.15 at 13:34, <roger....@citrix.com> wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -795,6 +795,15 @@ int arch_set_info_guest(
>> c.nat->fs_base || c.nat->gs_base_user)) )
>> return -EINVAL;
>> }
>> + else if ( is_hvm_domain(d) )
>> + {
>> + if ( c(ctrlreg[0]) || c(ctrlreg[1]) || c(ctrlreg[2]) ||
>> + c(ctrlreg[3]) || c(ctrlreg[4]) || c(ctrlreg[5]) ||
>> + c(ctrlreg[6]) || c(ctrlreg[7]) || c(ldt_base) ||
>> + c(ldt_ents) || c(kernel_ss) || c(kernel_sp) ||
>> + c(gdt_ents) )
>> + return -EINVAL;
>> + }
>
> In addition to what Andrew said - is the use of c() here really correct
> considering
>
> compat = is_pv_32bit_domain(d);
>
> #define c(fld) (compat ? (c.cmp->fld) : (c.nat->fld))
>
> near the beginning of the function?
I've been thinking about this. Since HVM vCPUs are always started in
32bit mode, I would ideally like to use the vcpu_guest_context_x86_32_t
struct to set the vCPU context. This means that for HVM guests "compat"
should always be true.
The problem is that inside of the guest there's no notion of
vcpu_guest_context_x86_32_t or vcpu_guest_context_x86_64_t, there's only
vcpu_guest_context, which defaults to the native bitness of the guest.
So if your guest is running in 64bit mode vcpu_guest_context is aliased
to vcpu_guest_context_x86_64_t by default.
TBH I'm not sure about the best way to solve this. Should
vcpu_guest_context_x86_32_t and vcpu_guest_context_x86_64_t be exposed
to the guest like it's done for the tools?
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
