Re: [Xen-devel] [PATCH 7/8] x86/EPT: split super pages upon mismatching memory types

[Tim Deegan <tim@xxxxxxx>]

At 15:36 +0000 on 26 Mar (1395844618), Jan Beulich wrote:
> ... between constituent pages. To indicate such, the page order is
> being passed down to the vMTRR routines, with a negative return value
> (possible only on order-non-zero pages) indicating such collisions.
> 
> Some code redundancy reduction is being done to ept_set_entry() along
> the way, allowing the new handling to be centralized to a single place
> there.
> 
> In order to keep ept_set_entry() fast and simple, the actual splitting
> is being deferred to the EPT_MISCONFIG VM exit handler.

You expect that to be rare, right?  We're not going to incur a lot of
extra pagefaults?

> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> One open question is whether it is okay for memory allocation (for an
> intermediate page table) failure to be fatal to the domain. If it
> isn't, then deferring the splitting work from ept_set_entry() to
> ept_handle_misconfig() is not an option. But even with that eliminated
> there's then still potential for ept_handle_misconfig() needing to
> split pages, and it would then need to be determined how to gracefully
> handle that.

Hmmm, true.  Since we can't tell in advance how much memory will be
needed, it's not possible to detect all the errors up front.  And I
can't think of a nice way to fail later on that doesn't go back to
having large loops over many gfns.  So I think we have to live with it.

Reviewed-by: Tim Deegan <tim@xxxxxxx>

Cheers,

Tim.

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