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

["Aravindh Puthiyaparambil (aravindp)" <aravindp@xxxxxxxxx>]

>> I currently see the CR0.WP=0 with interrupts disabled as the most
>> viable solution going.  That is not to say that there isn't a better
>> solution, but I can't currently spot a plausible alternative.
>
>Yes, temporarily adjusting the pagetables sounds like madness -- in order to
>avoid other guest VCPUs using the temporary mappings to subvert the write
>protection you'd have to pause them and that's going to risk deadlocks.

I agree it is madness. It was my desperation coming through :-)

>Temporarily disabling CR0.WP is nasty too but even with interrupts enabled I
>think it's better.  We don't do any guest-space writes from interrupt handlers
>(since we can't guarantee an interrupt would arrive in the right context).
>
>It would want a backstop assertion (in, say the cntext swicth or
>return-to-guest) to catch any new paths that leave CR0.WP disabled.
>
>For completeness, the other solutions on offer are:
>- have the three (?) paths in question detect write faults and
>  use HVM-like map-write-unmap code in that case.
>- have the three paths in question _always_ map and unmap their
>  targets when current vcpu is PV+shadow+memaccess.
>- trap and emulate Xen writes and detect/fix this case in that path.
>
>I think I'm going to NAK the temporarily-frob-the-PTE and trap-and-emulate
>ideas, but I'd be happy with using explicit mappings or with disabling CR0.WP.

I am going to try the CR0.WP route first. If that does not work well I will try 
the explicit mapping route.

Thanks,
Aravindh


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