>>> On 24.06.15 at 18:21, <boris.ostrov...@oracle.com> wrote:
> On 06/24/2015 08:10 AM, Jan Beulich wrote:
>>>>> On 24.06.15 at 13:42, <boris.ostrov...@oracle.com> wrote:
>>> On 06/24/2015 03:57 AM, Jan Beulich wrote:
>>>>>>> On 24.06.15 at 04:53, <boris.ostrov...@oracle.com> wrote:
>>>>> On 06/23/2015 09:22 AM, Jan Beulich wrote:
>>>>>>> --- a/xen/arch/x86/hvm/hvm.c
>>>>>>> +++ b/xen/arch/x86/hvm/hvm.c
>>>>>>> @@ -2320,12 +2320,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
>>>>>>> v->arch.hvm_vcpu.inject_trap.vector = -1;
>>>>>>>
>>>>>>> if ( is_pvh_domain(d) )
>>>>>>> - {
>>>>>>> - v->arch.hvm_vcpu.hcall_64bit = 1; /* PVH 32bitfixme. */
>>>>>>> - /* This is for hvm_long_mode_enabled(v). */
>>>>>>> - v->arch.hvm_vcpu.guest_efer = EFER_LMA | EFER_LME;
>>>>>>> return 0;
>>>>>>> - }
>>>>>> With this removed, is there any guarantee that hvm_set_mode()
>>>>>> will be called for each vCPU?
>>>>> IIUIC, toolstack is required to call XEN_DOMCTL_set_address_size which
>>>>> results in a call to switch_compat/native(), which loop over all VCPUs,
>>>>> calling set_mode.
>>>> I don't recall this being a strict requirement. I think a PV 64-bit
>>>> guest would start fine without.
>>> We do call it via libxl__build_pv() -> xc_dom_boot_mem_init() ->
>>> arch_setup_mem_init() -> x86_compat().
>> Right, that's in our tool stack. The question though was whether it's
>> a requirement to be called.
>
> Since this change will assume that this domctl is called for both 32-
> and 64-bit --- yes, this becomes a requirement for 64-bit PVH guests.
But that's the whole point of my question - it isn't right now, and
hence I don't think it should become a requirement. Instead I
think state should start out to be ready for a 64-bit guest just
like it does for PV.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
