From: "Jan Beulich" <JBeulich@suse.com>
To: Tamas K Lengyel <tamas.lengyel@zentific.com>
Cc: keir@xen.org, ian.campbell@citrix.com, tim@xen.org,
ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
stefano.stabellini@citrix.com, andres@lagarcavilla.org,
dgdegra@tycho.nsa.gov
Subject: Re: [PATCH RFC 3/7] xen/arm: Enable the compilation of mem_access and mem_event on ARM.
Date: Tue, 26 Aug 2014 14:51:54 +0100 [thread overview]
Message-ID: <53FCAD1A020000780002DA27@mail.emea.novell.com> (raw)
In-Reply-To: <1408699832-13325-4-git-send-email-tamas.lengyel@zentific.com>
>>> On 22.08.14 at 11:30, <tamas.lengyel@zentific.com> 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
next prev parent reply other threads:[~2014-08-26 13:51 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-22 9:30 [PATCH RFC 0/7] Mem_event and mem_access for ARM Tamas K Lengyel
2014-08-22 9:30 ` [PATCH RFC 1/7] xen: Relocate mem_access and mem_event into common Tamas K Lengyel
2014-08-25 17:19 ` Andres Lagar Cavilla
2014-08-26 10:52 ` Tamas K Lengyel
2014-08-26 12:42 ` Jan Beulich
2014-08-26 13:25 ` Tamas K Lengyel
2014-08-26 13:34 ` Jan Beulich
2014-08-26 14:42 ` Tamas K Lengyel
2014-08-26 15:32 ` Jan Beulich
2014-08-26 16:30 ` Tamas K Lengyel
2014-08-27 6:29 ` Jan Beulich
2014-08-22 9:30 ` [PATCH RFC 2/7] xen/mem_event: Clean out superflous white-spaces Tamas K Lengyel
2014-08-25 17:20 ` Andres Lagar Cavilla
2014-08-26 13:35 ` Jan Beulich
2014-08-26 13:59 ` Tamas K Lengyel
2014-08-22 9:30 ` [PATCH RFC 3/7] xen/arm: Enable the compilation of mem_access and mem_event on ARM Tamas K Lengyel
2014-08-25 17:25 ` Andres Lagar Cavilla
2014-08-26 8:32 ` Tamas K Lengyel
2014-08-26 13:51 ` Jan Beulich [this message]
[not found] ` <CAErYnshbvgxzBVSPu0mM3UUc0kr_zfENiHw9KmT=30-kpy_DZA@mail.gmail.com>
2014-08-26 14:38 ` Jan Beulich
2014-08-26 15:21 ` Tamas K Lengyel
2014-08-26 15:33 ` Jan Beulich
2014-08-22 9:30 ` [PATCH RFC 4/7] tools/libxc: Allocate magic page for mem access " Tamas K Lengyel
2014-08-22 9:30 ` [PATCH RFC 5/7] xen/arm: Data abort exception (R/W) mem_events Tamas K Lengyel
2014-08-22 9:30 ` [PATCH RFC 6/7] xen/arm: Instruction prefetch abort (X) mem_event handling Tamas K Lengyel
2014-08-22 9:30 ` [PATCH RFC 7/7] tools/tests: Enable xen-access on ARM Tamas K Lengyel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53FCAD1A020000780002DA27@mail.emea.novell.com \
--to=jbeulich@suse.com \
--cc=andres@lagarcavilla.org \
--cc=dgdegra@tycho.nsa.gov \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=keir@xen.org \
--cc=stefano.stabellini@citrix.com \
--cc=tamas.lengyel@zentific.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).