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 for-4.5 v10 15/19] xen/arm: Temporarily disable mem_access for hypervisor access
Date: Fri, 26 Sep 2014 14:43:41 +0200 [thread overview]
Message-ID: <54255F7D.8070107@linaro.org> (raw)
In-Reply-To: <CAErYnsjZoBZsqrnH3cpzJBJantt+9_-YAOQG6412_LHxddVCAQ@mail.gmail.com>
Hello Tamas,
On 26/09/2014 10:39, Tamas K Lengyel wrote:
> On Thu, Sep 25, 2014 at 6:19 PM, Julien Grall <julien.grall@linaro.org
> <mailto:julien.grall@linaro.org>> wrote:
> I don't think that modifying temporary the permission is the right
> thing to do because:
> - p2m_set_mem_access is called 2 times which means 2 TLB
> flush (and I'm not counting the table mapping), ie it's very slow
> - The other VCPU of the guest are still running. So you may
> not catch unwanted access.
>
>
> That is a problem. The only way around that I see is to pause the domain
> for the duration of this copy in case the mem_access permissions need to
> be disabled.
[..]
> So you mean only check the mem_access permissions when we failed to get
> the page. I'm not sure what you propose afterwards. If there is a
> mem_access restriction, just return an -errno? It would mean if a
> mem_access listener is trapped that page than the guest can't execute
> the hypercall. Since we would also want this system to be invisible to
> the guest, that I'm affraid is not a good approach.
The P2M is storing the type of the mapping. With this type you can
easily know if the previous mapping was read/write and therefore know if
the guest can effectively copy data to the page or not.
I don't see why we would need something more complicate as we want
ignore mem_access for now.
Regards,
--
Julien Grall
next prev parent reply other threads:[~2014-09-26 12:43 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-25 11:56 [PATCH for-4.5 v10 00/19] Mem_event and mem_access for ARM Tamas K Lengyel
2014-09-25 11:56 ` [PATCH for-4.5 v10 01/19] xen: Relocate mem_access and mem_event into common Tamas K Lengyel
2014-09-25 11:56 ` [PATCH for-4.5 v10 02/19] xen: Relocate struct npfec definition " Tamas K Lengyel
2014-09-25 11:56 ` [PATCH for-4.5 v10 03/19] xen: Relocate p2m_access_t into common and swap the order Tamas K Lengyel
2014-09-25 11:56 ` [PATCH for-4.5 v10 04/19] xen: Relocate p2m_mem_access_resume to mem_access common Tamas K Lengyel
2014-09-25 18:59 ` Tim Deegan
2014-09-26 14:34 ` Jan Beulich
2014-09-26 19:54 ` Tamas K Lengyel
2014-09-25 11:56 ` [PATCH for-4.5 v10 05/19] xen: Relocate set_access_required domctl into common Tamas K Lengyel
2014-09-25 11:56 ` [PATCH for-4.5 v10 06/19] xen: Relocate mem_event_op domctl and access_op memop " Tamas K Lengyel
2014-09-25 18:59 ` Tim Deegan
2014-09-25 11:56 ` [PATCH for-4.5 v10 07/19] xen/mem_event: Clean out superfluous white-spaces Tamas K Lengyel
2014-09-25 11:56 ` [PATCH for-4.5 v10 08/19] xen/mem_event: Relax error condition on debug builds Tamas K Lengyel
2014-09-25 11:56 ` [PATCH for-4.5 v10 09/19] xen/mem_event: Abstract architecture specific sanity checks Tamas K Lengyel
2014-09-25 11:56 ` [PATCH for-4.5 v10 10/19] xen/mem_access: Abstract architecture specific sanity check Tamas K Lengyel
2014-09-26 14:05 ` Jan Beulich
2014-09-25 11:56 ` [PATCH for-4.5 v10 11/19] xen/arm: p2m changes for mem_access support Tamas K Lengyel
2014-09-25 11:56 ` [PATCH for-4.5 v10 12/19] xen/arm: Implement domain_get_maximum_gpfn Tamas K Lengyel
2014-09-25 11:56 ` [PATCH for-4.5 v10 13/19] xen/arm: Add p2m_set_permission and p2m_shatter_page helpers Tamas K Lengyel
2014-09-25 11:56 ` [PATCH for-4.5 v10 14/19] xen/arm: Data abort exception (R/W) mem_events Tamas K Lengyel
2014-09-25 11:56 ` [PATCH for-4.5 v10 15/19] xen/arm: Temporarily disable mem_access for hypervisor access Tamas K Lengyel
2014-09-25 16:19 ` Julien Grall
2014-09-26 8:39 ` Tamas K Lengyel
2014-09-26 12:43 ` Julien Grall [this message]
2014-09-26 13:29 ` Tamas K Lengyel
2014-09-26 13:41 ` Julien Grall
2014-09-26 13:45 ` Tamas K Lengyel
2014-09-26 15:55 ` Ian Campbell
2014-09-25 11:56 ` [PATCH for-4.5 v10 16/19] xen/arm: Instruction prefetch abort (X) mem_event handling Tamas K Lengyel
2014-09-25 11:56 ` [PATCH for-4.5 v10 17/19] xen/arm: Enable the compilation of mem_access and mem_event on ARM Tamas K Lengyel
2014-09-25 11:56 ` [PATCH for-4.5 v10 18/19] tools/libxc: Allocate magic page for mem access " Tamas K Lengyel
2014-09-25 11:56 ` [PATCH for-4.5 v10 19/19] tools/tests: Enable xen-access " 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=54255F7D.8070107@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).