|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC 3/7] xen/arm: Enable the compilation of mem_access and mem_event on ARM.
>>> On 22.08.14 at 11:30, <tamas.lengyel@xxxxxxxxxxxx> wrote:
> --- a/xen/arch/arm/domctl.c
> +++ b/xen/arch/arm/domctl.c
> @@ -11,10 +11,17 @@
> #include <xen/sched.h>
> #include <xen/hypercall.h>
> #include <public/domctl.h>
> +#include <asm/guest_access.h>
> +#include <xen/mem_event.h>
> +#include <public/mem_event.h>
>
> long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
> XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
> {
> +
> + long ret;
> + bool_t copyback = 0;
> +
> switch ( domctl->cmd )
> {
> case XEN_DOMCTL_cacheflush:
> @@ -23,17 +30,38 @@ long arch_do_domctl(struct xen_domctl *domctl, struct
> domain *d,
> unsigned long e = s + domctl->u.cacheflush.nr_pfns;
>
> if ( domctl->u.cacheflush.nr_pfns > (1U<<MAX_ORDER) )
> - return -EINVAL;
> + {
> + ret = -EINVAL;
> + break;
> + }
>
> if ( e < s )
> - return -EINVAL;
> + {
> + ret = -EINVAL;
> + break;
> + }
>
> - return p2m_cache_flush(d, s, e);
> + ret = p2m_cache_flush(d, s, e);
> }
> + break;
What's wrong with the code above?
> +
> + case XEN_DOMCTL_mem_event_op:
> + {
> + ret = mem_event_domctl(d, &domctl->u.mem_event_op,
> + guest_handle_cast(u_domctl, void));
> + copyback = 1;
> + }
Pointless curly braces. Furthermore this already goes beyond what
the subject says, so you may want to adjust the title.
> + break;
>
> default:
> - return subarch_do_domctl(domctl, d, u_domctl);
> + ret = subarch_do_domctl(domctl, d, u_domctl);
> + break;
Again an unnecessary change.
> @@ -1111,18 +1114,27 @@ int xenmem_add_to_physmap_one(
>
> long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg)
> {
> - switch ( op )
> +
> + long rc;
> +
> + switch ( op & MEMOP_CMD_MASK )
> {
> /* XXX: memsharing not working yet */
> case XENMEM_get_sharing_shared_pages:
> case XENMEM_get_sharing_freed_pages:
> return 0;
> + case XENMEM_access_op:
Missing blank line before new case.
> + {
> + rc = mem_access_memop(op, guest_handle_cast(arg,
> xen_mem_access_op_t));
> + break;
> + }
Pointless curly braces again.
> default:
> - return -ENOSYS;
> + rc = -ENOSYS;
> + break;
Unnecessary change again.
> --- a/xen/common/mem_access.c
> +++ b/xen/common/mem_access.c
> @@ -29,8 +29,6 @@
> #include <xen/mem_event.h>
> #include <xsm/xsm.h>
>
> -#ifdef CONFIG_X86
> -
> int mem_access_memop(unsigned long cmd,
> XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg)
> {
> @@ -45,9 +43,11 @@ int mem_access_memop(unsigned long cmd,
> if ( rc )
> return rc;
>
> +#ifdef CONFIG_X86
> rc = -EINVAL;
> if ( !is_hvm_domain(d) )
> goto out;
> +#endif
Ugly, but well, I don't see a nice alternative.
> --- a/xen/common/mem_event.c
> +++ b/xen/common/mem_event.c
> @@ -20,16 +20,19 @@
> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> */
>
> -#ifdef CONFIG_X86
> -
> +#include <xen/sched.h>
> #include <asm/domain.h>
> #include <xen/event.h>
> #include <xen/wait.h>
> #include <asm/p2m.h>
> #include <xen/mem_event.h>
> #include <xen/mem_access.h>
> +
> +#ifdef CONFIG_X86
> #include <asm/mem_paging.h>
> #include <asm/mem_sharing.h>
> +#endif
Wouldn't that warrant introduction of HAVE_MEM_SHARING and
HAVE_MEM_PAGING?
> @@ -538,6 +543,8 @@ int mem_event_domctl(struct domain *d,
> xen_domctl_mem_event_op_t *mec,
> {
> case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE:
> {
> +
> +#ifdef CONFIG_X86
Bogus blank line above the #ifdef.
> rc = -ENODEV;
> /* Only HAP is supported */
> if ( !hap_enabled(d) )
> @@ -546,6 +553,7 @@ int mem_event_domctl(struct domain *d,
> xen_domctl_mem_event_op_t *mec,
> /* Currently only EPT is supported */
> if ( !cpu_has_vmx )
> break;
> +#endif
Code like what's getting enclosed in the #ifdef here should really
get abstracted out up front.
> +typedef enum {
> + p2m_access_n = 0, /* No access permissions allowed */
> + p2m_access_r = 1,
> + p2m_access_w = 2,
> + p2m_access_rw = 3,
> + p2m_access_x = 4,
> + p2m_access_rx = 5,
> + p2m_access_wx = 6,
> + p2m_access_rwx = 7
> +
> + /* NOTE: Assumed to be only 4 bits right now */
The comment seems bogus (i.e. blindly copied from x86). Furthermore
I think all the types above are really generic, i.e. may warrant placing
in a common header (with a per-arch define of extra types to be
added).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |