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

[Tim Deegan <tim@xxxxxxx>]

At 00:30 +0100 on 27 Aug (1409095841), Andrew Cooper wrote:
> 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.

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.

Tim.

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