From: Julien Grall <julien@xen.org>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org,
Stefano Stabellini <stefano.stabellini@xilinx.com>,
Volodymyr_Babchuk@epam.com
Subject: Re: [PATCH 12/12] xen/arm: call iomem_permit_access for passthrough devices
Date: Wed, 27 May 2020 19:09:52 +0100 [thread overview]
Message-ID: <0f79d268-b154-0674-4c33-a06a0b585142@xen.org> (raw)
In-Reply-To: <alpine.DEB.2.21.2005260941250.27502@sstabellini-ThinkPad-T480s>
Hi Stefano,
On 26/05/2020 17:46, Stefano Stabellini wrote:
> On Sun, 24 May 2020, Julien Grall wrote:
>> On 30/04/2020 14:01, Julien Grall wrote:
>>> On 29/04/2020 21:47, Stefano Stabellini wrote:
>>>> On Wed, 15 Apr 2020, Julien Grall wrote: But doesn't it make sense to give
>>>> domU permission if it is going to get
>>>> the memory mapped? But admittedly I can't think of something that would
>>>> break because of the lack of the iomem_permit_access call in this code
>>>> path.
>>>
>>> On Arm, the permissions are only useful if you plan you DomU to delegate the
>>> regions to another domain. As your domain is not even aware it is running on
>>> Xen (we don't expose 'xen' node in the DT), it makes little sense to add the
>>> permission.
>>
>> I actually found one use when helping a user last week. You can dump the list
>> of MMIO regions assigned to a guest from Xen Console.
>>
>> This will use d->iomem_caps that is modified via iomem_permit_access().
>> Without it, there is no easy way to confirm the list of MMIO regions assigned
>> to a guest. Although...
>>
>>> Even today, you can map IOMEM to a DomU and then revert the permission right
>>> after. They IOMEM will still be mapped in the guest and it will act normaly.
>>
>> ... this would not help the case where permissions are reverted. But I am
>> assuming this shouldn't happen for Dom0less.
>
> Thank you for looking into this
>
>
>> Stefano, I am not sure what's your plan for the series itself for Xen 4.14. I
>> think this patch could go in now. Any thoughts?
>
> For the series: I have addresses all comments in my working tree except
> for the ones on memory allocation (the thread "xen: introduce
> reserve_heap_pages"). It looks like that part requires a complete
> rewrite, and it seems that the new code is not trivial to write. So I am
> thinking of not targeting 4.14. What do you think? Do you think the new
> code should be "easy" enough that I could target 4.14?
It may be a stretch with the code freeze on Friday. I would suggest to
send it when it is ready and we can either include in Xen 4.14 or as
soon as the tree re-open.
>
> For this patch: it is fine to go in now, doesn't have to wait for the
> series.
Feel free to add my ack on the patch.
Cheers,
--
Julien Grall
next prev parent reply other threads:[~2020-05-27 18:10 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-15 1:02 [PATCH 0/12] direct-map DomUs Stefano Stabellini
2020-04-15 1:02 ` [PATCH 01/12] xen: introduce xen_dom_flags Stefano Stabellini
2020-04-15 9:12 ` Jan Beulich
2020-04-15 13:26 ` Julien Grall
2020-04-29 23:57 ` Stefano Stabellini
2020-04-15 1:02 ` [PATCH 02/12] xen/arm: introduce arch_xen_dom_flags and direct_map Stefano Stabellini
2020-04-15 10:27 ` Jan Beulich
2020-04-15 11:27 ` Andrew Cooper
2020-04-30 0:34 ` Stefano Stabellini
2020-04-15 1:02 ` [PATCH 03/12] xen/arm: introduce 1:1 mapping for domUs Stefano Stabellini
2020-04-15 13:36 ` Julien Grall
2020-05-01 1:26 ` Stefano Stabellini
2020-05-01 8:30 ` Julien Grall
2020-05-09 0:07 ` Stefano Stabellini
2020-05-09 9:56 ` Julien Grall
2020-04-15 1:02 ` [PATCH 04/12] xen: split alloc_heap_pages in two halves for reusability Stefano Stabellini
2020-04-15 11:22 ` Wei Liu
2020-04-17 10:02 ` Jan Beulich
2020-04-29 23:09 ` Stefano Stabellini
2020-04-15 1:02 ` [PATCH 05/12] xen: introduce reserve_heap_pages Stefano Stabellini
2020-04-15 13:24 ` Julien Grall
2020-04-17 10:11 ` Jan Beulich
2020-04-29 22:46 ` Stefano Stabellini
2020-04-30 6:29 ` Jan Beulich
2020-04-30 16:21 ` Stefano Stabellini
2020-05-04 9:16 ` Jan Beulich
2020-04-30 14:51 ` Julien Grall
2020-04-30 17:00 ` Stefano Stabellini
2020-04-30 18:27 ` Julien Grall
2020-05-12 1:10 ` Stefano Stabellini
2020-05-12 8:57 ` Julien Grall
2020-04-15 1:02 ` [PATCH 06/12] xen/arm: reserve 1:1 memory for direct_map domUs Stefano Stabellini
2020-04-15 13:38 ` Julien Grall
2020-04-15 1:02 ` [PATCH 07/12] xen/arm: new vgic: rename vgic_cpu/dist_base to c/dbase Stefano Stabellini
2020-04-15 13:41 ` Julien Grall
2020-04-15 1:02 ` [PATCH 08/12] xen/arm: if is_domain_direct_mapped use native addresses for GICv2 Stefano Stabellini
2020-04-15 14:00 ` Julien Grall
2020-05-01 1:26 ` Stefano Stabellini
2020-05-01 8:23 ` Julien Grall
2020-05-09 0:06 ` Stefano Stabellini
2020-04-15 1:02 ` [PATCH 09/12] xen/arm: if is_domain_direct_mapped use native addresses for GICv3 Stefano Stabellini
2020-04-15 14:09 ` Julien Grall
2020-05-01 1:31 ` Stefano Stabellini
2020-05-01 8:40 ` Julien Grall
2020-05-09 0:06 ` Stefano Stabellini
2020-04-15 1:02 ` [PATCH 10/12] xen/arm: if is_domain_direct_mapped use native UART address for vPL011 Stefano Stabellini
2020-04-15 14:11 ` Julien Grall
2020-05-01 1:26 ` Stefano Stabellini
2020-05-01 8:09 ` Julien Grall
2020-05-09 0:07 ` Stefano Stabellini
2020-05-09 10:11 ` Julien Grall
2020-05-11 22:58 ` Stefano Stabellini
2020-04-15 1:02 ` [PATCH 11/12] xen/arm: if xen_force don't try to setup the IOMMU Stefano Stabellini
2020-04-15 14:12 ` Julien Grall
2020-04-29 21:55 ` Stefano Stabellini
2020-04-30 13:51 ` Julien Grall
2020-05-01 1:25 ` Stefano Stabellini
2020-04-15 1:02 ` [PATCH 12/12] xen/arm: call iomem_permit_access for passthrough devices Stefano Stabellini
2020-04-15 14:18 ` Julien Grall
2020-04-29 20:47 ` Stefano Stabellini
2020-04-30 13:01 ` Julien Grall
2020-05-24 14:12 ` Julien Grall
2020-05-26 16:46 ` Stefano Stabellini
2020-05-27 18:09 ` Julien Grall [this message]
2020-04-16 8:59 ` [PATCH 0/12] direct-map DomUs Julien Grall
2020-04-29 20:16 ` Stefano Stabellini
2020-04-30 12:54 ` Julien Grall
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=0f79d268-b154-0674-4c33-a06a0b585142@xen.org \
--to=julien@xen.org \
--cc=Volodymyr_Babchuk@epam.com \
--cc=sstabellini@kernel.org \
--cc=stefano.stabellini@xilinx.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 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.