|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v1 1/2] x86: add p2m_ram_wp
>>> On 28.07.14 at 19:55, <wei.ye@xxxxxxxxx> wrote:
> xen/arch/x86/hvm/hvm.c | 8 +++++++-
> xen/arch/x86/mm/p2m-ept.c | 1 +
> xen/include/asm-x86/p2m.h | 8 +++++++-
> 3 files changed, 15 insertions(+), 2 deletions(-)
This can't be complete: At the very least p2m-pt.c also needs a change
similar to the one to p2m-ept.c.
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2738,7 +2738,8 @@ int hvm_hap_nested_page_fault(paddr_t gpa,
> * If this GFN is emulated MMIO or marked as read-only, pass the fault
> * to the mmio handler.
> */
> - if ( (p2mt == p2m_mmio_dm) ||
> + if ( (p2mt == p2m_mmio_dm) ||
> + (p2mt == p2m_ram_wp) ||
> (access_w && (p2mt == p2m_ram_ro)) )
Comparing your change with the surrounding existing code, you
would pass even reads happening to fault (perhaps for another
reason) to the DM, other than done for p2m_ram_ro. I don't think
that's correct.
> @@ -3829,6 +3830,11 @@ static enum hvm_copy_result __hvm_copy(
> put_page(page);
> return HVMCOPY_unhandleable;
> }
> + if ( p2m_is_wp_ram(p2mt) )
> + {
> + put_page(page);
> + return HVMCOPY_bad_gfn_to_mfn;
> + }
And again this change can't be complete: __hvm_clear() would also
need a similar change.
> @@ -167,6 +169,9 @@ typedef unsigned int p2m_query_t;
> * and must not be touched. */
> #define P2M_BROKEN_TYPES (p2m_to_mask(p2m_ram_broken))
>
> +/* Write protection types */
> +#define P2M_WP_TYPES (p2m_to_mask(p2m_ram_wp))
> +
> /* Useful predicates */
> #define p2m_is_ram(_t) (p2m_to_mask(_t) & P2M_RAM_TYPES)
> #define p2m_is_hole(_t) (p2m_to_mask(_t) & P2M_HOLE_TYPES)
> @@ -191,6 +196,7 @@ typedef unsigned int p2m_query_t;
> #define p2m_is_any_ram(_t) (p2m_to_mask(_t) & \
> (P2M_RAM_TYPES | P2M_GRANT_TYPES | \
> p2m_to_mask(p2m_map_foreign)))
> +#define p2m_is_wp_ram(_t) (p2m_to_mask(_t) & P2M_WP_TYPES)
To me such single-type classes don't seem very useful. Agreed
there are a number of pre-existing ones, but for classes where
future extensions are rather hard to imagine I wouldn't needlessly
add classes right away. But Tim (whom you failed to Cc anyway)
will have the final say here.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |