All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.