Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 04/11/2018 11:17 PM, Tamas K Lengyel wrote:
> On Wed, Apr 11, 2018 at 12:39 AM, Razvan Cojocaru
> <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> Also related to this part of the altp2m design, I've also noticed that
>> creating a new EPT view with libxc involves this function:
>>
>> int xc_altp2m_create_view(xc_interface *handle, uint32_t domid,
>>                           xenmem_access_t default_access,
>>                           uint16_t *view_id);
>>
>> However, default_access is completely ignored. If this was meant to
>> reset all pages to that access it's trivial to wire it in into the
>> hypervisor (we could just iterate through all guest pages from 0 to
>> max_gpfn and set the access) - but in light of this issue that's not a
>> good thing to do. Or, rather, it was meant to specify the default_access
>> for new pages where it is not explicitly specified?
> 
> I don't think the function of default_access for an altp2m was
> settled, so both of these would sound to me like a valid setup. I
> personally would prefer that if the default_access is specified and
> it's not rwx it would result in the entire altp2m view getting
> populated right there instead of it being done lazily. The whole
> lazy-population of the altp2m views has been nothing but a headache.
> Add to that the fact that views get completely reset under certain
> situations without any indication being given to the application using
> it.. might be time we rethink these parts of altp2m to make it more
> robust.

Do you mean the p2m_altp2m_lazy_copy() logic in
hvm_hap_nested_page_fault()? That took a while to wrap my head around.

Ideally a new view would immediately upon creation copy the default
view. Later on, it would be updated (kept in sync) by
p2m_altp2m_propagate_change(). That's the theory anyway.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel