Re: [Xen-devel] [PATCH RFC] x86/altp2m: fix display frozen when switching to a new view early

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 9/19/18 3:15 PM, George Dunlap wrote:
>> * has p2m_init_altp2m_ept() copy over max_mapped_pfn,
>>   logdirty_ranges, global_logdirty, ept.ad and default_access
>>   from the hostp2m (the latter more for completeness than for any
>>   other reason).
> I think this is probably the right approach.  These values change
> rarely, but after a misconfig are read repeatedly.  So it's probably a
> lot more efficient to propagate changes when they happen, rather than
> trying to keep a single master copy.  However...
> 
>> We should discuss if just copying over
>>   logdirty_ranges (which is a pointer) is sufficient, or if
>>   this code requires more synchronization).
> It's clearly not sufficient. :-)  The logdirty_ranges struct is
> protected by the lock of the p2m structure that contains it; if you
> point to it from a different p2m structure, then you'll have
> inconsistent logging, and you'll have problems if one vcpu is reading
> the structure while another is modifying it.
> 
> Another issue is that it doesn't look like you're propagating updates to
> this shared state either -- if someone enables or disables
> global_logdirty, or changes default_access, the altp2ms will still have
> the old value.
> 
> I wonder if we should collect the various bits that need to be kept in
> sync between hostp2m/altp2ms, put them all in a 'sync' sub-struct within
> the p2m, and enforce using a function / macro to modify the values inside.

I'm not sure how to put ept.ad in the new sync sub-struct - putting the
full ept in there feels like overkill, and just putting a new variable
to symbolize .ad feels convoluted.


Thanks,
Razvan

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