xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Tamas K Lengyel <tamas.lengyel@zentific.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH for-4.5 v6 13/17] xen/arm: Data abort exception (R/W) mem_events.
Date: Tue, 16 Sep 2014 17:50:43 +0100	[thread overview]
Message-ID: <1410886243.23505.16.camel@citrix.com> (raw)
In-Reply-To: <CAErYnsgs0TQ-GjQCA7z+=WUAE1-w2tkDE9CoO5OwrQCBnBbOOQ@mail.gmail.com>

On Tue, 2014-09-16 at 12:07 +0200, Tamas K Lengyel wrote:

>         In the trap handlers only permission faults are checked
>         against the mem_access radix tree, so that already cuts down
>         overhead to a conditional. In my experiments I haven't seen a
>         single instance of a permission fault happening which I didn't
>         cause myself. In p2m modifications as long as the default
>         mem_access is rwx, the code path is the same as before for
>         large pages. For 4k pages when adding them with rwx permission
>         it does have an extra radix tree lookup to clean any potential
>         setting in the radix tree for that page, but that is really
>         just a safety check on my part and if overhead with it is a
>         problem it can be removed. IMHO in the default case the radix
>         tree is empty, so that lookup is essentially just another
>         conditional.

With the radix tree lookup functions it isn't trivially easy to reason
that they turn into an almost-nop on an empty tree, so I'm not sure.
It's an out of line function call and at least 2 pointer indirections
from the looks of it.

Perhaps we could add an explicit value for p2m->default_access which
causes the tree never to even get touched?

> 
> While the code logic is in theory the same, unfortunately there are
> significant differences between handling locks, which makes it not
> possible to have this code in common. There are also some style
> differences, like ARM doesn't have set_entry/get_entry pointers in the
> p2m_domain, as on ARM we don't need to dynamically support different
> types for those functions (no need to abstract them). The parts that
> could be in common are only a couple lines here and there which don't
> really justify having them in common as separate functions.

We can add new arch-generic wrappers for things if it makes sense, like
e.g. guest_physmap_add_entry or map_mmio_regions etc. Do you tihnk that
would help/make sense here?

Ian.

  reply	other threads:[~2014-09-16 16:50 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-15 14:02 [PATCH for-4.5 v6 00/17] Mem_event and mem_access for ARM Tamas K Lengyel
2014-09-15 14:02 ` [PATCH for-4.5 v6 01/17] xen: Relocate mem_access and mem_event into common Tamas K Lengyel
2014-09-15 14:02 ` [PATCH for-4.5 v6 02/17] xen: Relocate p2m_mem_access_resume to mem_access common Tamas K Lengyel
2014-09-15 14:02 ` [PATCH for-4.5 v6 03/17] xen: Relocate struct npfec definition into common Tamas K Lengyel
2014-09-15 14:02 ` [PATCH for-4.5 v6 04/17] xen: Relocate mem_event_op domctl and access_op memop " Tamas K Lengyel
2014-09-15 14:02 ` [PATCH for-4.5 v6 05/17] x86/p2m: Typo fix for spelling ambiguous Tamas K Lengyel
2014-09-15 14:02 ` [PATCH for-4.5 v6 06/17] xen/mem_event: Clean out superfluous white-spaces Tamas K Lengyel
2014-09-15 14:02 ` [PATCH for-4.5 v6 07/17] xen/mem_event: Relax error condition on debug builds Tamas K Lengyel
2014-09-15 14:02 ` [PATCH for-4.5 v6 08/17] xen/mem_event: Abstract architecture specific sanity checks Tamas K Lengyel
2014-09-15 14:02 ` [PATCH for-4.5 v6 09/17] xen/mem_access: Abstract architecture specific sanity check Tamas K Lengyel
2014-09-15 14:02 ` [PATCH for-4.5 v6 10/17] xen/arm: p2m type definitions and changes Tamas K Lengyel
2014-09-15 22:35   ` Ian Campbell
2014-09-16  8:49     ` Tamas K Lengyel
2014-09-16 13:27       ` Ian Campbell
2014-09-16 20:38         ` Julien Grall
2014-09-16 21:52           ` Tamas K Lengyel
2014-09-15 14:02 ` [PATCH for-4.5 v6 11/17] xen/arm: Add set access required domctl Tamas K Lengyel
2014-09-15 22:37   ` Ian Campbell
2014-09-16  8:37     ` Tamas K Lengyel
2014-09-15 22:38   ` Ian Campbell
2014-09-16  8:33     ` Tamas K Lengyel
2014-09-16 13:25       ` Ian Campbell
2014-09-15 14:02 ` [PATCH for-4.5 v6 12/17] xen/arm: Implement domain_get_maximum_gpfn Tamas K Lengyel
2014-09-15 22:39   ` Ian Campbell
2014-09-16  8:02     ` Tamas K Lengyel
2014-09-16 16:44       ` Ian Campbell
2014-09-16 17:09         ` Tamas K Lengyel
2014-09-15 14:02 ` [PATCH for-4.5 v6 13/17] xen/arm: Data abort exception (R/W) mem_events Tamas K Lengyel
2014-09-15 22:53   ` Ian Campbell
     [not found]     ` <CAErYnshu0vJJMxWwu4eo2MZf=q_g2H123p6VUk_4a9f12vYLjg@mail.gmail.com>
2014-09-16 10:07       ` Tamas K Lengyel
2014-09-16 16:50         ` Ian Campbell [this message]
2014-09-16 17:08           ` Tamas K Lengyel
2014-09-18 18:54   ` Ian Campbell
2014-09-18 20:09     ` Tamas K Lengyel
2014-09-19  9:05       ` Tamas K Lengyel
2014-09-22  9:11         ` Ian Campbell
2014-09-22 17:18           ` Tamas K Lengyel
2014-09-15 14:02 ` [PATCH for-4.5 v6 14/17] xen/arm: Instruction prefetch abort (X) mem_event handling Tamas K Lengyel
2014-09-18 18:59   ` Ian Campbell
2014-09-18 20:12     ` Tamas K Lengyel
2014-09-15 14:02 ` [PATCH for-4.5 v6 15/17] xen/arm: Enable the compilation of mem_access and mem_event on ARM Tamas K Lengyel
2014-09-15 14:02 ` [PATCH for-4.5 v6 16/17] tools/libxc: Allocate magic page for mem access " Tamas K Lengyel
2014-09-15 14:02 ` [PATCH for-4.5 v6 17/17] tools/tests: Enable xen-access " Tamas K Lengyel
2014-09-18 19:02   ` Ian Campbell
2014-09-22 18:48     ` Tamas K Lengyel
2014-09-23 12:18       ` Ian Campbell
2014-10-01 17:32         ` Aravindh Puthiyaparambil (aravindp)

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=1410886243.23505.16.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=tamas.lengyel@zentific.com \
    --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).