Re: [Xen-devel] [PATCH RFC v2 1/4] x86/mm: Shadow and p2m changes for PV mem_access

[Tim Deegan <tim@xxxxxxx>]

At 18:31 +0000 on 28 Aug (1409247071), Aravindh Puthiyaparambil (aravindp) 
wrote:
> >> >That's not necessarily enough, but at least presumably the right
> >> >route: You also need to avoid fiddling with struct page_info fields
> >> >that may be used (now or in the future) for other purposes, i.e.
> >> >you need to gate the setting of the flags by more than just
> >> >is_pv_domain().
> >>
> >> Coupled with your response to the other thread, I am thinking I should
> >move away from using the shadow_flags for access permissions. Tim's other
> >suggestion was to try and re-use the p2m-pt implementation.
> >>
> >
> >I think you should be OK to use shadow_flags here -- after all the
> >shadow code relies on being able to use them for any guest data page
> >once shadow mode is enabled.
> 
> Yes, I agree. In fact using the p2m-pt implementation is not going to help 
> getting around the hypercall continuation issue.
> 
> >To avoid touching them before shadow mode is actually enabled you
> >could reshuffle the encodings so that 0 is 'default' (shadow code
> >absolutely relies on this field being 0 when shadow more is enabled so
> >any other user will have to maintain that).
> 
> Do you mean the p2m_access_t enum when you say encoding?

Not necessarily - but you _could_ reorder the enum (and add a comment
so make sure that other people don't reorder it again) if that does
what you want.  Alternatively, you could use one more bit of
the shadow flags as a 'valid' bit for the access bits, where readers
would replace invalid mappings with whatever the correct default value
is.

One other question occurs to me: what about the case of enabling,
disabling and re-enabling the mem-access feature?  Is it OK that
access permissions will be retained from the first use into the second
or do they need to be reset somehow?

Cheers,

Tim.

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