[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v9] x86/altp2m: support for setting restrictions for an array of pages



>>> On 13.12.17 at 08:12, <ppircalabu@xxxxxxxxxxxxxxx> wrote:
> @@ -4619,6 +4623,38 @@ static int do_altp2m_op(
>                                      a.u.set_mem_access.view);
>          break;
>  
> +    case HVMOP_altp2m_set_mem_access_multi:
> +        if ( a.u.set_mem_access_multi.pad ||
> +             ( a.u.set_mem_access_multi.nr &&
> +               a.u.set_mem_access_multi.opaque >= 
> a.u.set_mem_access_multi.nr ) )

Why not simply >, which would avoid the need to check nr against
zero? Also if the more involved form really needs to stay for some
reason, then please remove the stray blanks inside the inner
parentheses. No matter which route is chosen, I guess this could
be taken care of while committing. Apart from this the patch looks
okay now to me, but as indicated before I'm not really wanting to
ack it; Tamas - having looked at this some more after the earlier
discussion I guess my main issue is with the existence of
XEN_ALTP2M_mixed. If there was no mode where external tools
could compete with in-guest altp2m accesses (other than that
allowed by XEN_ALTP2M_limited) I think I'd be fine giving my ack
following in particular George's earlier line of arguments.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.