Re: [Xen-devel] [PATCH RFC v13 06/20] pvh: vmx-specific changes

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.11.13 at 13:02, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
> On 08/10/13 09:45, Jan Beulich wrote:
>>>>> On 07.10.13 at 18:12, Tim Deegan <tim@xxxxxxx> wrote:
>>> At 17:06 +0100 on 07 Oct (1381165615), George Dunlap wrote:
>>>> On 07/10/13 16:55, Roger Pau Monnà wrote:
>>>>> On 23/09/13 18:49, George Dunlap wrote:
>>>>>> @@ -1028,12 +1129,28 @@ static int construct_vmcs(struct vcpu *v)
>>>>>>                 | (1U << TRAP_no_device);
>>>>>>       vmx_update_exception_bitmap(v);
>>>>>>   
>>>>>> +    /* In HVM domains, this happens on the realmode->paging
>>>>>> +     * transition.  Since PVH never goes through this transition, we
>>>>>> +     * need to do it at start-of-day. */
>>>>>> +    if ( is_pvh_domain(d) )
>>>>>> +        vmx_update_debug_state(v);
>>>>>> +
>>>>>>       v->arch.hvm_vcpu.guest_cr[0] = X86_CR0_PE | X86_CR0_ET;
>>>>>> +
>>>>>> +    /* PVH domains always start in paging mode */
>>>>>> +    if ( is_pvh_domain(d) )
>>>>>> +        v->arch.hvm_vcpu.guest_cr[0] |= X86_CR0_PG | X86_CR0_NE |
>>>>>> X86_CR0_WP;
>>>>>> +
>>>>>>       hvm_update_guest_cr(v, 0);
>>>>>>   
>>>>>> -    v->arch.hvm_vcpu.guest_cr[4] = 0;
>>>>>> +    v->arch.hvm_vcpu.guest_cr[4] = is_pvh_domain(d) ?
>>>>>> +        real_cr4_to_pv_guest_cr4(mmu_cr4_features)
>>>>> Here we need to mask the bits in CR4 that the guest isn't allowed to
>>>>> set. Right now Xen is setting the VMXE bit by default, which the guest
>>>>> is not able to modify, so if the guests tries to update CR4 based on the
>>>>> previous value Xen is going to complain:
>>>>>
>>>>> +        real_cr4_to_pv_guest_cr4(mmu_cr4_features) &
>>>>> +        ~HVM_CR4_GUEST_RESERVED_BITS(v)
>>>> Thanks for testing that -- I'll include it in the next spin-up.
>>> <harping on> This is the sort of thing that would be easier if PVH guests
>>> were just HVM ones with extra hypercalls. <harping off>
>> And indeed I'm rather puzzled by the simplistic re-use of a PV
>> construct: There are memory management related bits in CR4,
>> and with memory management not being PV for PVH guests,
>> this seems conceptually wrong.
> 
> What would be a better approach, do you think?

Split between the memory management related bits and the
others, taking the former from what HVM would and the latter
from how PV would.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel