>>> On 13.12.17 at 08:12, <ppircal...@bitdefender.com> 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
