xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: Tamas K Lengyel <tklengyel@sec.in.tum.de>, xen-devel@lists.xen.org
Cc: ian.campbell@citrix.com, tim@xen.org, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, andres@lagarcavilla.org,
	jbeulich@suse.com, dgdegra@tycho.nsa.gov
Subject: Re: [PATCH v4 09/16] xen/arm: p2m type definitions and changes
Date: Mon, 08 Sep 2014 17:06:58 -0700	[thread overview]
Message-ID: <540E44A2.1050301@linaro.org> (raw)
In-Reply-To: <1409907524-12509-10-git-send-email-tklengyel@sec.in.tum.de>

Hi Tamas,

On 05/09/14 01:58, Tamas K Lengyel wrote:
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index 06c93a0..b2009ee 100644
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -2,9 +2,54 @@

[..]

> +#include <public/memory.h>
> +#include <public/mem_event.h>

Why do you need this 2 includes?

>
>   struct domain;
>
> +/* List of possible type for each page in the p2m entry.
> + * The number of available bit per page in the pte for this purpose is 4 bits.
> + * So it's possible to only have 16 fields. If we run out of value in the
> + * future, it's possible to use higher value for pseudo-type and don't store
> + * them in the p2m entry.
> + */
> +typedef enum {
> +    p2m_invalid = 0,    /* Nothing mapped here */
> +    p2m_ram_rw,         /* Normal read/write guest RAM */
> +    p2m_ram_ro,         /* Read-only; writes are silently dropped */
> +    p2m_mmio_direct,    /* Read/write mapping of genuine MMIO area */
> +    p2m_map_foreign,    /* Ram pages from foreign domain */
> +    p2m_grant_map_rw,   /* Read/write grant mapping */
> +    p2m_grant_map_ro,   /* Read-only grant mapping */
> +    /* The types below are only used to decide the page attribute in the P2M */
> +    p2m_iommu_map_rw,   /* Read/write iommu mapping */
> +    p2m_iommu_map_ro,   /* Read-only iommu mapping */
> +    p2m_max_real_type,  /* Types after this won't be store in the p2m */
> +} p2m_type_t;
> +

Any reason to move the enum earlier? If not, I would prefer to keep at 
the same place. It will be easier with git-blame to find when a new type 
has been added.

> +/*
> + * Additional access types, which are used to further restrict
> + * the permissions given by the p2m_type_t memory type. Violations
> + * caused by p2m_access_t restrictions are sent to the mem_event
> + * interface.
> + *
> + * The access permissions are soft state: when any ambigious change of page

ambiguous

[..]

> +    /* Default P2M access type for each page in the the domain: new pages,
> +     * swapped in pages, cleared pages, and pages that are ambiquously

Did you intend to mean ambiguously rather than ambiquously?

[..]

> +/* get host p2m table */
> +#define p2m_get_hostp2m(d) (&((d)->arch.p2m))
> +
> +/* mem_event and mem_access are supported on all ARM */

I don't find "all ARM" clear. I would replace by "any ARM guest"

Regards,

-- 
Julien Grall

  reply	other threads:[~2014-09-09  0:06 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-05  8:58 [PATCH v4 00/16] Mem_event and mem_access for ARM Tamas K Lengyel
2014-09-05  8:58 ` [PATCH v4 01/16] xen: Relocate mem_access and mem_event into common Tamas K Lengyel
2014-09-05  9:14   ` Jan Beulich
2014-09-05  9:45     ` Tamas K Lengyel
2014-09-05 10:07       ` Jan Beulich
2014-09-05 10:36         ` Tamas K Lengyel
2014-09-05 10:48           ` Jan Beulich
2014-09-05 10:52             ` Tamas K Lengyel
2014-09-05 11:26               ` Jan Beulich
2014-09-05 11:30                 ` Tamas K Lengyel
2014-09-05 11:46                   ` Jan Beulich
2014-09-05  8:58 ` [PATCH v4 02/16] xen: Relocate p2m_mem_access_resume to mem_access common Tamas K Lengyel
2014-09-05  9:16   ` Jan Beulich
2014-09-05  9:25     ` Tamas K Lengyel
2014-09-05  9:43       ` Jan Beulich
2014-09-05  9:48         ` Tamas K Lengyel
2014-09-05  8:58 ` [PATCH v4 03/16] xen: Relocate struct npfec definition into common Tamas K Lengyel
2014-09-05  8:58 ` [PATCH v4 04/16] xen: Relocate mem_event_op domctl and access_op memop " Tamas K Lengyel
2014-09-05  9:23   ` Jan Beulich
2014-09-05  9:29     ` Tamas K Lengyel
2014-09-05  8:58 ` [PATCH v4 05/16] xen/mem_event: Clean out superfluous white-spaces Tamas K Lengyel
2014-09-05  8:58 ` [PATCH v4 06/16] xen/mem_event: Relax error condition on debug builds Tamas K Lengyel
2014-09-05  9:25   ` Jan Beulich
2014-09-05  9:26     ` Tamas K Lengyel
2014-09-05  8:58 ` [PATCH v4 07/16] xen/mem_event: Abstract architecture specific sanity checks Tamas K Lengyel
2014-09-05  9:28   ` Jan Beulich
2014-09-05  9:35     ` Tamas K Lengyel
2014-09-05  9:44       ` Jan Beulich
2014-09-05  9:47         ` Tamas K Lengyel
2014-09-05  8:58 ` [PATCH v4 08/16] xen/mem_access: Abstract architecture specific sanity check Tamas K Lengyel
2014-09-05  9:29   ` Jan Beulich
2014-09-05  9:51     ` Tamas K Lengyel
2014-09-05  8:58 ` [PATCH v4 09/16] xen/arm: p2m type definitions and changes Tamas K Lengyel
2014-09-09  0:06   ` Julien Grall [this message]
2014-09-05  8:58 ` [PATCH v4 10/16] xen/arm: Add set access required domctl Tamas K Lengyel
2014-09-09  0:07   ` Julien Grall
2014-09-12 15:54     ` Tamas K Lengyel
2014-09-05  8:58 ` [PATCH v4 11/16] xen/arm: Data abort exception (R/W) mem_events Tamas K Lengyel
2014-09-09  0:25   ` Julien Grall
2014-09-05  8:58 ` [PATCH v4 12/16] xen/arm: Instruction prefetch abort (X) mem_event handling Tamas K Lengyel
2014-09-05  8:58 ` [PATCH v4 13/16] xen/arm: Shatter large pages when using mem_acces Tamas K Lengyel
2014-09-05  8:58 ` [PATCH v4 14/16] xen/arm: Enable the compilation of mem_access and mem_event on ARM Tamas K Lengyel
2014-09-05  8:58 ` [PATCH v4 15/16] tools/libxc: Allocate magic page for mem access " Tamas K Lengyel
2014-09-05  8:58 ` [PATCH v4 16/16] tools/tests: Enable xen-access " Tamas K Lengyel
2014-09-09  0:29   ` Julien Grall

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=540E44A2.1050301@linaro.org \
    --to=julien.grall@linaro.org \
    --cc=andres@lagarcavilla.org \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=stefano.stabellini@citrix.com \
    --cc=tim@xen.org \
    --cc=tklengyel@sec.in.tum.de \
    --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).