From: Julien Grall <julien.grall@linaro.org>
To: Tamas K Lengyel <tamas.lengyel@zentific.com>
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>,
Ian Jackson <ian.jackson@eu.citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
Stefano Stabellini <stefano.stabellini@citrix.com>,
Andres Lagar-Cavilla <andres@lagarcavilla.org>,
Jan Beulich <jbeulich@suse.com>,
Daniel De Graaf <dgdegra@tycho.nsa.gov>,
Tamas K Lengyel <tklengyel@sec.in.tum.de>
Subject: Re: [PATCH v5 12/17] xen/arm: Data abort exception (R/W) mem_events.
Date: Fri, 12 Sep 2014 14:04:23 -0700 [thread overview]
Message-ID: <54135FD7.2010602@linaro.org> (raw)
In-Reply-To: <CAErYnsi5neiV78US79ifZ=9DpUuWd=P+nu2JomeC6mf-VLBk+w@mail.gmail.com>
Hello Tamas,
On 12/09/14 13:48, Tamas K Lengyel wrote:
>
>
> On Fri, Sep 12, 2014 at 10:35 PM, Julien Grall <julien.grall@linaro.org
> <mailto:julien.grall@linaro.org>> wrote:
>
> Hello Tamas,
>
> On 12/09/14 01:46, Tamas K Lengyel wrote:
>
> /* New mapping is superpage aligned,
> make it */
> pte = mfn_to_p2m_entry(*maddr >> PAGE_SHIFT,
> mattr, t, a);
> if ( level < 3 )
> @@ -663,6 +737,7 @@ static int apply_one_level(struct
> domain *d,
>
> memset(&pte, 0x00, sizeof(pte));
> p2m_write_pte(entry, pte, flush_cache);
> + radix_tree_delete(&p2m->mem_____access_settings,
> paddr_to_pfn(*addr));
>
> *addr += level_size;
> *maddr += level_size;
> @@ -707,6 +782,53 @@ static int apply_one_level(struct
> domain *d,
> *addr += PAGE_SIZE;
> return P2M_ONE_PROGRESS_NOP;
> }
> +
> + case MEMACCESS:
> + if ( level < 3 )
> + {
> + if ( !p2m_valid(orig_pte) )
> + {
> + (*addr)++;
>
>
> Why increment by 1? You the PTE doesn't contain valid
> mapping you
> want to skip the whole level range. ie:
>
> *addr += level_size;
>
>
> It doesn't make a difference, apply_p2m_changes is called with
> start=paddr, end=paddr+1 from a separate loop. So just
> incrementing it
> by one or a whole level achieves the same effect, that is, the
> apply_p2m_changes loop breaks.
>
>
> Actually it makes a lots of difference. If you increment by 1 the
> address, you will call up to level_size time your code before
> effectively going to the next level entry.
>
> This function can be called with *multiple page*.
>
>
> It can be, but it isn't. It makes no difference form my perspective so
> I'm fine with it either way.
Even in your case, this code will be called too often, and then make
your code slower. So please fix it, the other part of this function is
skipping the whole level in this case. There is no reason to decide to
not use it here.
> It is a bit less efficient for sure. However, the continuation setup for
> mem_access is in common/mem_access for XENMEM_access_op_set_access. In
> order to make use of apply_p2m_change to setup continuation I would have
> to remove that code from common and make it arch specific in both ARM
> and x86. Is that really a good idea just to have this optimization in ARM?
It's even far less efficient, mainly when you are applying on a batch of
PFN like xenaccess will do.
The common code won't be changed. I'm just asking to move the check in
apply_p2m_changes. It should not be a big deal.
Regards,
--
Julien Grall
next prev parent reply other threads:[~2014-09-12 21:04 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-10 13:28 [PATCH v5 00/17] Mem_event and mem_access for ARM Tamas K Lengyel
2014-09-10 13:28 ` [PATCH v5 01/17] xen: Relocate mem_access and mem_event into common Tamas K Lengyel
2014-09-10 13:28 ` [PATCH v5 02/17] xen: Relocate p2m_mem_access_resume to mem_access common Tamas K Lengyel
2014-09-11 20:16 ` Julien Grall
2014-09-12 8:56 ` Tamas K Lengyel
2014-09-10 13:28 ` [PATCH v5 03/17] xen: Relocate struct npfec definition into common Tamas K Lengyel
2014-09-10 13:28 ` [PATCH v5 04/17] xen: Relocate mem_event_op domctl and access_op memop " Tamas K Lengyel
2014-09-10 13:44 ` Jan Beulich
2014-09-10 13:28 ` [PATCH v5 05/17] xen/mem_event: Clean out superfluous white-spaces Tamas K Lengyel
2014-09-10 13:28 ` [PATCH v5 06/17] xen/mem_event: Relax error condition on debug builds Tamas K Lengyel
2014-09-10 13:28 ` [PATCH v5 07/17] xen/mem_event: Abstract architecture specific sanity checks Tamas K Lengyel
2014-09-10 13:28 ` [PATCH v5 08/17] xen/mem_access: Abstract architecture specific sanity check Tamas K Lengyel
2014-09-10 13:28 ` [PATCH v5 09/17] xen/arm: p2m type definitions and changes Tamas K Lengyel
2014-09-11 20:25 ` Julien Grall
2014-09-12 8:15 ` Tamas K Lengyel
2014-09-12 19:23 ` Julien Grall
2014-09-12 20:25 ` Tamas K Lengyel
2014-09-11 20:49 ` Julien Grall
2014-09-12 8:31 ` Tamas K Lengyel
2014-09-12 19:41 ` Julien Grall
2014-09-12 20:20 ` Tamas K Lengyel
2014-09-10 13:28 ` [PATCH v5 10/17] xen/arm: Add set access required domctl Tamas K Lengyel
2014-09-11 20:26 ` Julien Grall
2014-09-10 13:28 ` [PATCH v5 11/17] xen/arm: Implement domain_get_maximum_gpfn Tamas K Lengyel
2014-09-11 20:28 ` Julien Grall
2014-09-12 8:58 ` Tamas K Lengyel
2014-09-10 13:28 ` [PATCH v5 12/17] xen/arm: Data abort exception (R/W) mem_events Tamas K Lengyel
2014-09-11 21:19 ` Julien Grall
2014-09-12 8:46 ` Tamas K Lengyel
2014-09-12 20:35 ` Julien Grall
2014-09-12 20:48 ` Tamas K Lengyel
2014-09-12 21:04 ` Julien Grall [this message]
2014-09-10 13:28 ` [PATCH v5 13/17] xen/arm: Instruction prefetch abort (X) mem_event handling Tamas K Lengyel
2014-09-11 21:23 ` Julien Grall
2014-09-12 8:34 ` Tamas K Lengyel
2014-09-10 13:28 ` [PATCH v5 14/17] xen/arm: Enable the compilation of mem_access and mem_event on ARM Tamas K Lengyel
2014-09-10 13:28 ` [PATCH v5 15/17] xen: Extend getdomaininfo to return the domain's max_gpfn Tamas K Lengyel
2014-09-10 13:48 ` Jan Beulich
2014-09-10 13:55 ` Tamas K Lengyel
2014-09-10 13:28 ` [PATCH v5 16/17] tools/libxc: Allocate magic page for mem access on ARM Tamas K Lengyel
2014-09-10 13:28 ` [PATCH v5 17/17] tools/tests: Enable xen-access " Tamas K Lengyel
2014-09-11 21:29 ` Julien Grall
2014-09-12 8:50 ` Tamas K Lengyel
2014-09-12 9:01 ` Tamas K Lengyel
2014-09-10 13:51 ` [PATCH v5 00/17] Mem_event and mem_access for ARM Jan Beulich
2014-09-10 14:01 ` Tamas K Lengyel
2014-09-15 22:26 ` Ian Campbell
2014-09-16 8:00 ` Jan Beulich
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=54135FD7.2010602@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=tamas.lengyel@zentific.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).