[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4] x86/altp2m: Added xc_altp2m_set_mem_access_multi()
>>> On 10.10.17 at 16:13, <ppircalabu@xxxxxxxxxxxxxxx> wrote: > On Ma, 2017-10-10 at 06:28 -0600, Jan Beulich wrote:> > >> > > >> > > > >> > > > a.u.set_mem_access_multi.pfn_list, >> > + a.u.set_mem_access_multi.acc >> > ess_list, >> > + a.u.set_mem_access_multi.nr, >> > + a.u.set_mem_access_multi.opa >> > que, >> > + MEMOP_CMD_MASK, >> This not being a memop, re-using this value looks arbitrary. >> Unless it absolutely has to be this value, please either add a brief >> comment saying this just happens to fit your need or use a literal >> constant. > I will add a comment to clarify the reason for using MEMOP_CMD_MASK: > e.g. > /* MEMOP_CMD_MASK is used here to mirror the way > p2m_set_mem_access_multi() is called for the > XENMEM_access_op_set_access_multi case. */ But that's neither brief nor an actual reason (if at all it is a cosmetic one). A wider or more narrow mask would do, afaict. >> > + a.u.set_mem_access_multi.vie >> > w); >> > + if ( rc > 0 ) >> > + { >> > + a.u.set_mem_access_multi.opaque = rc; >> > + if ( __copy_field_to_guest(guest_handle_cast(arg, >> > xen_hvm_altp2m_op_t), &a, u.set_mem_access_multi.opaque) ) >> Long line. >> >> Also please consider adding a prereq patch changing the function's >> parameter to a properly typed handle, which will then make >> unnecessary using the not obviously correct cast here. Other >> copying back of individual fields in this function could then also be >> switched to __copy_field_to_guest(). > > Actually, changing the function's parameter to a typed handle could > complicate things a little for compat_altp2m_op. It should be modified > also to use a typed handle (compat_hvm_altp2m_op_t), which in case of > commands other than HVMOP_altp2m_set_mem_access_multi should be casted > to xen_hvm_altp2m_op_t before calling do_altp2m_op. > If the problem was only related to the code clarity, I think the new > implementation will be a little more difficult to follow. Hmm, likely true - it would help do_altp2m_op(), but would indeed look to harm the new ad hoc compat wrapper you add. >> > @@ -4586,6 +4613,57 @@ static int do_altp2m_op( >> > return rc; >> > } >> > >> > +static int compat_altp2m_op( >> > + XEN_GUEST_HANDLE_PARAM(void) arg) >> > +{ >> > + struct compat_hvm_altp2m_op a; >> > + union >> > + { >> > + XEN_GUEST_HANDLE_PARAM(void) hnd; >> > + struct xen_hvm_altp2m_op *altp2m_op; >> > + } nat; >> > + >> > + if ( !hvm_altp2m_supported() ) >> > + return -EOPNOTSUPP; >> > + >> > + if ( copy_from_gueWill change in the next patch iteration. >> > st(&a, arg, 1) ) This isn't the first time I see such a misplaced comment. Once again I can't make sense of it when being placed this way. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |