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

Re: [Xen-devel] [PATCH v4 04/16] xen: Relocate mem_event_op domctl and access_op memop into common.






On Fri, Sep 5, 2014 at 11:23 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>> On 05.09.14 at 10:58, <tklengyel@xxxxxxxxxxxxx> wrote:
> Signed-off-by: Tamas K Lengyel <tklengyel@xxxxxxxxxxxxx>
> ---
> v4: Don't remove memop handling from x86_64/compat and style fixes.

Here you acted a little too lax one the previous version's comments
I gave: If the handling of the native memop gets moved from
arch/x86/ to common/, so should the compat one do.


Ah yes, that would make sense.
 
> @@ -967,6 +968,12 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>      }
>      break;
>
> +    case XEN_DOMCTL_mem_event_op:
> +        ret = mem_event_domctl(d, &op->u.mem_event_op,
> +                               guest_handle_cast(u_domctl, void));
> +        copyback = 1;
> +        break;
> +
>      default:
>          ret = arch_do_domctl(op, d, u_domctl);
>          break;

Additions of new domctls are fine to go here, but moving existing
ones here from arch code should try to put it in a place at least
roughly expectable by the actual domctl number (I'm not sure the
switch statement is fully ordered, but at least I'm pretty sure you'll
find it to at least be approximately).


Ack.
 
> @@ -969,6 +970,10 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>
>          break;
>
> +    case XENMEM_access_op:
> +        rc = mem_access_memop(cmd, guest_handle_cast(arg, xen_mem_access_op_t));
> +        break;
> +
>      default:
>          rc = arch_memory_op(cmd, arg);
>          break;

Same here then, obviously.

Jan


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

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

 


Rackspace

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