All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleksandr <olekstysh@gmail.com>
To: Julien Grall <julien.grall@arm.com>,
	Andrii Anisov <andrii.anisov@gmail.com>,
	xen-devel@lists.xenproject.org
Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/arm: domain_build: Don't expose IOMMU specific properties to the guest
Date: Tue, 1 Oct 2019 19:07:59 +0300	[thread overview]
Message-ID: <d43ca714-130b-091b-79db-c20d1a6da2b0@gmail.com> (raw)
In-Reply-To: <e9ce8c39-fa90-461d-0958-a0b2a0cf968a@arm.com>


On 01.10.19 18:36, Julien Grall wrote:
> Hi Oleksandr,

Hi Julien



>
> On 01/10/2019 16:25, Oleksandr wrote:
>>
>> On 01.10.19 18:04, Julien Grall wrote:
>>> Hi,
>>
>> Hi Julien
>>
>>
>>>
>>> I am reviving the thread. I think we need a patch similar to this 
>>> one for Xen 4.13. This is because generic are now used by Xen so 
>>> they should be hidden from the hardware domain.
>>>
>>> Andrii, Oleksandr, can one of you look at it?
>>
>> I will be able to look at it probably at the end of the week if there 
>> is no urgency.
>
> That's fine, I think we can make a case to add it in Xen 4.13.
>
>>
>>
>>>
>>> Cheers,
>>>
>>> On 21/01/2019 17:04, Andrii Anisov wrote:
>>>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>
>>>> We don't passthrough IOMMU device to DOM0 even if it is not used by
>>>> Xen. Therefore exposing the properties that describe relationship
>>>> between master devices and IOMMUs does not make any sense.
>>>>
>>>> According to the:
>>>> 1. Documentation/devicetree/bindings/iommu/iommu.txt
>>>> 2. Documentation/devicetree/bindings/pci/pci-iommu.txt
>>>>
>>>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>> Acked-by: Julien Grall <julien.grall@arm.com>
>>>> ---
>>>>   xen/arch/arm/domain_build.c | 10 ++++++++++
>>>>   1 file changed, 10 insertions(+)
>>>>
>>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>>> index d2c63a8..15a08d6 100644
>>>> --- a/xen/arch/arm/domain_build.c
>>>> +++ b/xen/arch/arm/domain_build.c
>>>> @@ -540,6 +540,16 @@ static int __init write_properties(struct 
>>>> domain *d, struct kernel_info *kinfo,
>>>>               continue;
>>>>           }
>>>>   +        /* Don't expose IOMMU specific properties to the guest */
>>>> +        if ( dt_property_name_is_equal(prop, "iommus") )
>>>> +            continue;
>>>> +
>>>> +        if ( dt_property_name_is_equal(prop, "iommu-map") )
>>>> +            continue;
>>>> +
>>>> +        if ( dt_property_name_is_equal(prop, "iommu-map-mask") )
>>>> +            continue;
>>>> +
>>>>           res = fdt_property(kinfo->fdt, prop->name, prop_data, 
>>>> prop_len);
>>>>             if ( res )
>>>>
>>>
>> Julien, are you happy to see this patch as is, or do you have some 
>> comments regarding it?
>
> I have some comments on the cover letter for this patch. Please see [1].
>
> Thank you for having a look at the patch.
>
> Cheers,
>
> [1] <ed087980-a2b9-2fd4-7e84-446142e8176b@arm.com>

Looking briefly, I found two main points regarding that patch. This is 
how I understand them (please, correct me if I am wrong):

1. The IOMMU can be accessible by Dom0 (for example, if we pass 
"iommu=disabled" to Xen command line or it is enabled, but there is not 
suitable driver in Xen found).
There is no need to remove properties if Dom0 is already touching the IOMMU.
2. Generic IOMMU DT bindings is not used in Xen so far. There is no need 
to remove properties.

As I understand, both points are not actual anymore and nothing to 
modify in that patch, correct?

Because:

1. Giving the IOMMU to Dom0 is a bad idea.
2. Already supported.


-- 
Regards,

Oleksandr Tyshchenko


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-10-01 16:08 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-21 17:04 [PATCH 0/2] Dangling fixes for ARM iommu Andrii Anisov
2019-01-21 17:04 ` [PATCH 1/2] iommu/arm: Misc fixes for arch specific part Andrii Anisov
2019-01-21 17:04 ` [PATCH 2/2] xen/arm: domain_build: Don't expose IOMMU specific properties to the guest Andrii Anisov
2019-10-01 15:04   ` [Xen-devel] " Julien Grall
2019-10-01 15:25     ` Oleksandr
2019-10-01 15:36       ` Julien Grall
2019-10-01 16:07         ` Oleksandr [this message]
2019-10-01 19:07           ` Julien Grall
2019-10-03 12:18             ` Oleksandr
2019-10-07 21:02               ` Julien Grall
2019-10-08 15:34                 ` Oleksandr
2019-01-21 17:29 ` [PATCH 0/2] Dangling fixes for ARM iommu Julien Grall
2019-01-22 13:48   ` Andrii Anisov
2019-01-22 14:31     ` Julien Grall
2019-01-23 17:53       ` Andrii Anisov
2019-01-23 18:14         ` Julien Grall
2019-01-23 18:29           ` Andrii Anisov
2019-01-23 18:34             ` 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=d43ca714-130b-091b-79db-c20d1a6da2b0@gmail.com \
    --to=olekstysh@gmail.com \
    --cc=andrii.anisov@gmail.com \
    --cc=julien.grall@arm.com \
    --cc=oleksandr_tyshchenko@epam.com \
    --cc=sstabellini@kernel.org \
    --cc=volodymyr_babchuk@epam.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.