From: Stefano Stabellini <sstabellini@kernel.org>
To: Julien Grall <julien.grall@arm.com>
Cc: sstabellini@kernel.org, Wei Liu <wei.liu2@citrix.com>,
Benjamin Sanda <ben.sanda@dornerworks.com>,
George Dunlap <George.Dunlap@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
xen-devel <xen-devel@lists.xenproject.org>,
Keir Fraser <keir@xen.org>,
Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [PATCH v3 2/5] xentrace: Memory/Page Mapping support for DOMID_XEN on ARM
Date: Fri, 22 Apr 2016 10:42:07 +0100 (BST) [thread overview]
Message-ID: <alpine.DEB.2.10.1604221036250.6744@sstabellini-ThinkPad-X260> (raw)
In-Reply-To: <570D1A11.20001@arm.com>
On Tue, 12 Apr 2016, Julien Grall wrote:
> On 11/04/2016 10:52, George Dunlap wrote:
> > On Fri, Apr 8, 2016 at 6:58 PM, Andrew Cooper <andrew.cooper3@citrix.com>
> > wrote:
> > > On 08/04/16 16:49, Jan Beulich wrote:
> > > > > > > On 08.04.16 at 12:42, <julien.grall@arm.com> wrote:
> > > > > On 04/04/16 19:48, Benjamin Sanda wrote:
> > > > > > + else
> > > > > > + {
> > > > > > + /* retrieve the page to determine read/write or read only
> > > > > > mapping */
> > > > > > + mfn = paddr >> PAGE_SHIFT;
> > > > > > + if (mfn_valid(mfn))
> > > > > > + {
> > > > > > + page = mfn_to_page(mfn);
> > > > > > + *t = (page->u.inuse.type_info == PGT_writable_page ?
> > > > > > + p2m_ram_rw : p2m_ram_ro);
> > > > > Unfortunately, xenmem_add_to_physmap_one will ignore the return type
> > > > > and
> > > > > will always map using the type p2m_map_foreign. I would introduce
> > > > > a new type p2m_map_foreign_ro to allow read-only foreign mapping.
> > > > >
> > > > > I've looked at the x86 code (p2m_add_foreign) and I haven't been able
> > > > > to
> > > > > find how the page will be mapped read-only in the guest P2M.
> > > > > get_page_from_gfn will always return p2m_raw_rw for DOMID_XEN as it's
> > > > > a
> > > > > non translated domain.
> > > > >
> > > > > Andrew and Jan, do you know how this is supposed to work when xentrace
> > > > > is used in a HVM domain? Does x86 Xen always mapped Read-Write the
> > > > > page?
> > > > I don't think that case is being taken care of right now: xentrace
> > > > is to be used by privileged guests only anyway, and the only
> > > > HVM-like privileged guest would be a PVHv1 Dom0 (which likely
> > > > no-one cared about to make work with xentrace so far).
> > >
> > > Answer to questions of the form "Has anyone considered $X for a
> > > privileged HVM domain on x86" are almost always "No".
> > >
> > > The real question is whether the domain making the mapping needs to
> > > write into the pages or not. If xentrace has to update shared pointers,
> > > then it needs to be rw. If it simply consumes the data without any
> > > backwards notification, then it should be ro.
> >
> > It does access shared pointers, and so needs at lest one page to be
> > rw. At the moment there's sort of two levels: the "trace info"
> > page(s), mapped RO, which has the list of all the MFNs used for the
> > actual trace data, and the trace data MFNs themselves, which are
> > mapped RW.
> >
> > Re Julien's question about how DOMID_XEN pages are marked RO on x86
> > when get_page_from_gfn() always returns p2m_ram_rw: The answer is that
> > get_page_from_gfn() is only really used by the p2m code. For PV
> > guests, it's the page type that restricts a page's type to RO or RW.
> > trace.c calls share_xen_page_with_privileged_guests(), which on x86
> > calls xen/arch/x86/mm.c:share_xen_page_with_guest(), which sets the
> > type to PGT_writable_page.
>
> Thank you for the explanation.
>
> The ARM implementation of share_xen_page_with_guest is nearly the same as the
> x86 one. However, the type is never used so far for the P2M code.
>
> So far, all ARM domains have been auto-translated. DOMID_XEN is the first non
> auto-translated domain.
>
> We could make DOMID_XEN an auto-translated domain by introducing page table
> for dummy domain. This would make the code cleaner but use more memory
> (allocation of 3 level of page tables).
>
> Stefano, do you have any opinions on this?
If it is just one "if" or two the issue, I would keep DOMID_XEN as it is
now and deal with it as a special case. If we expect that we are going
to grow more "if domain_id == DOMID_XEN" all around the code base, then
I would follow your suggestion and make DOMID_XEN auto-translated. But
we don't need to decide now, we could go with the special if for the
moment and keep this in mind.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-04-22 9:42 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-04 18:48 [PATCH v3 0/5] xentrace/xenalyze Support on ARM Benjamin Sanda
2016-04-04 18:48 ` [PATCH v3 1/5] xentrace: Common Support for get_pg_owner/put_pg_owner on ARM and x86 Benjamin Sanda
2016-04-04 23:05 ` Andrew Cooper
2016-04-05 8:12 ` Jan Beulich
2016-04-14 19:59 ` Ben Sanda
2016-04-17 7:58 ` Jan Beulich
2016-04-04 18:48 ` [PATCH v3 2/5] xentrace: Memory/Page Mapping support for DOMID_XEN on ARM Benjamin Sanda
2016-04-08 10:42 ` Julien Grall
2016-04-08 15:49 ` Jan Beulich
2016-04-08 17:58 ` Andrew Cooper
2016-04-11 9:52 ` George Dunlap
2016-04-12 15:53 ` Julien Grall
2016-04-14 19:52 ` Ben Sanda
2016-04-20 12:48 ` Julien Grall
2016-04-22 9:42 ` Stefano Stabellini [this message]
2016-04-22 17:01 ` Julien Grall
2016-04-04 18:48 ` [PATCH v3 3/5] xentrace: Timestamp support for ARM platform Benjamin Sanda
2016-04-08 10:50 ` Julien Grall
2016-04-11 14:56 ` Konrad Rzeszutek Wilk
2016-04-04 18:48 ` [PATCH v3 4/5] xentrace: Trace Buffer Initialization on ARM Benjamin Sanda
2016-04-08 10:53 ` Julien Grall
2016-04-04 18:48 ` [PATCH v3 5/5] xenalyze: Build for Both ARM and x86 Platforms Benjamin Sanda
2016-04-05 8:09 ` [PATCH v3 0/5] xentrace/xenalyze Support on ARM Jan Beulich
2016-04-06 16:51 ` Ben Sanda
2016-04-06 16:59 ` Andrew Cooper
2016-04-06 17:03 ` Ben Sanda
2016-04-08 14:44 ` George Dunlap
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=alpine.DEB.2.10.1604221036250.6744@sstabellini-ThinkPad-X260 \
--to=sstabellini@kernel.org \
--cc=George.Dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=ben.sanda@dornerworks.com \
--cc=ian.jackson@eu.citrix.com \
--cc=julien.grall@arm.com \
--cc=keir@xen.org \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.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).