xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@arm.com>
To: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, xen-devel@lists.xen.org
Cc: edgar.iglesias@xilinx.com, sstabellini@kernel.org,
	Steve Capper <Steve.Capper@arm.com>,
	Andre Przywara <andre.przywara@arm.com>,
	Shannon Zhao <shannon.zhao@linaro.org>,
	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: Mon, 23 May 2016 11:29:31 +0100	[thread overview]
Message-ID: <5742DB8B.7050603@arm.com> (raw)
In-Reply-To: <1463759488-11900-1-git-send-email-edgar.iglesias@gmail.com>

Hello Edgar,

I have CCed a couple of people from ARM to get more input on it.

On 20/05/16 16:51, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com>
>
> This series adds support for mapping mmio-sram nodes into dom0
> as MEMORY, cached and with RWX perms.

Can you explain why you chose to map those nodes as MEMORY, cached and 
with RWX perms?

>
> Dom0 can then choose to further restrict these mappings if needed.
> We only look at the outer mmio-sram region. The sub-area nodes that
> describe allocations within the mmio-sram region are only meaningful
> to the guest AFAICT.
>
> In an attempt to avoid growing the already fairly large domain_build.c
> file, I've tried to implement a distributed way to deal with these kind
> of special/custom mapping needs. These can live outside of domain_build.c
> and are registerd by means of a .map method in the device_spec.
>
> If this approach is not good, I'm happy to bin it and try something else.

We will have a similar problem when using ACPI for DOM0 or mapping a 
such MMIO to the guest. The hypercalls XENMAPSPACE_dev_mmio and 
XEN_DOMCTL_memory_mapping do not provide enough information to know the 
attribute to be used for mapping.

MMIO are always mapped in Stage-2 with Device_nGnRE, which is quite 
restrictive. This would also impact any MMIO regions, such as the video 
RAM buffer, that could be mapped write-combine.

After reading the ARM ARM (B2.8.2 ARM DII 0486.i), I think we could 
relax the stage-2 mapping by using Device_GRE for all the device MMIOs 
but the GIC.

We have to keep the GIC MMIO with the most restrictive memory attribute 
to avoid potential side-effect when Xen is switching between multiple 
vCPUs. All the other devices will be exclusive to a specific guest, so 
the guest can handle the device the way it wants. This may require some 
extra-care when reassigning the device to another domain.

Edgar, would Device_GRE be fine for you?

Note, that XENMAPSPACE_dev_mmio has been introduced in Xen 4.7 (which is 
due in a couple of weeks) and part of the stable ABI. So if it is not 
possible to relax the memory attribute, it might be worth to think 
fixing/reverting the hypercall for 4.7. Otherwise we would have to 
introduce a new one in the next release.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  parent reply	other threads:[~2016-05-23 10:29 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 ` Julien Grall [this message]
2016-05-23 11:56   ` [RFC for-4.8 0/6] xen/arm: Add support for mapping mmio-sram nodes into dom0 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
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=5742DB8B.7050603@arm.com \
    --to=julien.grall@arm.com \
    --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=shannon.zhao@linaro.org \
    --cc=sstabellini@kernel.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).