From: Stefano Stabellini <sstabellini@kernel.org>
To: Julien Grall <julien.grall@arm.com>
Cc: edgar.iglesias@xilinx.com,
Stefano Stabellini <sstabellini@kernel.org>,
Steve Capper <Steve.Capper@arm.com>,
Andre Przywara <andre.przywara@arm.com>,
xen-devel@lists.xen.org, Shannon Zhao <shannon.zhao@linaro.org>,
"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
Wei Chen <Wei.Chen@linaro.org>
Subject: Re: [RFC for-4.8 0/6] xen/arm: Add support for mapping mmio-sram nodes into dom0
Date: Wed, 25 May 2016 11:00:29 +0100 (BST) [thread overview]
Message-ID: <alpine.DEB.2.10.1605251059270.2958@sstabellini-ThinkPad-X260> (raw)
In-Reply-To: <574575C7.1090002@arm.com>
On Wed, 25 May 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 25/05/16 10:43, Stefano Stabellini wrote:
> > > For SRAM it would be normal memory uncached (?) when the property
> > > "no-memory-wc" is not present, else TBD.
> > >
> > > I suspect we would have to relax more MMIOs in the future. Rather than
> > > providing a function to map, the code is very similar except the memory
> > > attribute, I suggest to provide a list of compatible with the memory
> > > attribute
> > > to use.
> > >
> > > All the children node would inherit the memory attribute of the parent.
> > >
> > > What do you think?
> >
> > That would work for device tree, but we still need to rely on the
> > hypercall for ACPI systems.
> >
> > Given that it is not easy to add an additional parameter to
> > XENMEM_add_to_physmap_range, I think we'll have to provide a new
> > hypercall to allow setting attributes other than the Xen default. That
> > could be done in Xen 4.8 and Linux >= 4.9.
>
> There is no need to introduce a new hypercall. The XENMEM_add_to_physmap_batch
> contains an unused field ('foreign_id', to be renamed) for mapping device
> MMIOs (see Jan's mail [1]).
>
> XENMEM_add_to_physmap will always map with the default memory attribute
> (Device_nGnRnE) and if the kernel want to use another memory attribute, it
> will have to use XENMEM_add_to_physmap_batch.
>
> With the plan suggested in [2], there are no modifications required in Linux
> for the moment.
>
> Regards,
>
> [1] http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg02341.html
> [2] http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg02347.html
I read the separate thread. Sounds good.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-05-25 10:00 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-20 15:51 [RFC for-4.8 0/6] xen/arm: Add support for mapping mmio-sram nodes into dom0 Edgar E. Iglesias
2016-05-20 15:51 ` [RFC for-4.8 1/6] xen/arm: Add device_get_desc() Edgar E. Iglesias
2016-05-20 15:51 ` [RFC for-4.8 2/6] xen/arm: Add an optional map function to the device descriptor Edgar E. Iglesias
2016-05-20 15:51 ` [RFC for-4.8 3/6] xen/arm: Add a DEVICE_MEMORY class Edgar E. Iglesias
2016-05-20 15:51 ` [RFC for-4.8 4/6] xen/arm: Add helper functions to map RWX memory regions Edgar E. Iglesias
2016-05-23 15:36 ` Julien Grall
2016-05-24 14:14 ` Edgar E. Iglesias
2016-05-20 15:51 ` [RFC for-4.8 5/6] xen/arm: Add an mmio-sram device Edgar E. Iglesias
2016-05-20 15:51 ` [RFC for-4.8 6/6] xen/arm: Avoid multiple dev class lookups in handle_node Edgar E. Iglesias
2016-05-23 10:29 ` [RFC for-4.8 0/6] xen/arm: Add support for mapping mmio-sram nodes into dom0 Julien Grall
2016-05-23 11:56 ` Edgar E. Iglesias
2016-05-23 13:02 ` Julien Grall
2016-05-23 14:02 ` Edgar E. Iglesias
2016-05-23 15:13 ` Julien Grall
2016-05-23 15:42 ` Edgar E. Iglesias
2016-05-24 19:44 ` Julien Grall
2016-05-25 9:43 ` Stefano Stabellini
2016-05-25 9:52 ` Julien Grall
2016-05-25 10:00 ` Stefano Stabellini [this message]
2016-05-25 10:35 ` Edgar E. Iglesias
2016-05-25 13:29 ` Edgar E. Iglesias
2016-05-25 14:24 ` Julien Grall
2016-06-03 13:10 ` Edgar E. Iglesias
2016-05-25 9:31 ` Stefano Stabellini
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.1605251059270.2958@sstabellini-ThinkPad-X260 \
--to=sstabellini@kernel.org \
--cc=Steve.Capper@arm.com \
--cc=Wei.Chen@linaro.org \
--cc=andre.przywara@arm.com \
--cc=edgar.iglesias@gmail.com \
--cc=edgar.iglesias@xilinx.com \
--cc=julien.grall@arm.com \
--cc=shannon.zhao@linaro.org \
--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).