xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: xen-devel@lists.xenproject.org, stefano.stabellini@citrix.com,
	ian.campbell@citrix.com, Xiantao Zhang <xiantao.zhang@intel.com>,
	tim@xen.org
Subject: Re: [PATCH v5 12/14] xen/arm: p2m: Clean cache PT when the IOMMU doesn't support coherent walk
Date: Wed, 14 May 2014 14:08:11 +0100	[thread overview]
Message-ID: <537386DB020000780001228B@mail.emea.novell.com> (raw)
In-Reply-To: <5373654C.6010206@linaro.org>

>>> On 14.05.14 at 14:45, <julien.grall@linaro.org> wrote:
> On 05/14/2014 10:25 AM, Jan Beulich wrote:
>>>>> On 14.05.14 at 11:09, <julien.grall@linaro.org> wrote:
>>>>> @@ -139,6 +147,7 @@ struct iommu_ops {
>>>>>       void (*iotlb_flush)(struct domain *d, unsigned long gfn, unsigned int 
> page_count);
>>>>>       void (*iotlb_flush_all)(struct domain *d);
>>>>>       void (*dump_p2m_table)(struct domain *d);
>>>>> +    uint32_t (*features)(struct domain *d);
>>>>
>>>> I think I said this on an earlier round already - for future extensibility
>>>> this should return "const unsigned long *", and get accessed by the
>>>> wrapper function using test_bit(). Or even better without an accessor
>>>> function at all, just directly having a "const unsigned long *" field here.
>>>> Unless of course the backend implementation - which isn't part of this
>>>> patch - would have difficulty setting up a suitable bitfield during (early)
>>>> initialization.
>>>
>>> The SMMU drivers handle multiple SMMUs. Each SMMU can have different 
>>> specifications (e.g coherent walk support or not).
>>>
>>> As each domain doesn't use all SMMUs, we might be able to avoid flushing 
>>> PT on some of them. That's why I've choose to use a callback with the 
>>> domain in parameter.
>>>
>>> I don't like the solution which return "unsigned long *" because we are 
>>> assuming the driver will always a valid pointer (for instance with 2 
>>> unsigned long), even if he doesn't need it.
>> 
>> In that case simply make this a bitmap embedded in struct iommu_ops,
>> which the driver has to populate suitably early. That way the individual
>> drivers don't need to care about the eventually growing size.
> 
> That doesn't really help me. Because a same platform can have a mix of
> SMMU support coherent walk or not.
> 
> For optimization it would be better to have a per-domain feature.

Oh, right, I didn't pay attention to you passing a domain into the
query.

> What about creating a callback:
> iommu_has_feature(struct domain *d, enum iommu_feature)
> 
> and let the driver handling the feature?

That sounds fine as long as you don't expect such to sit on any hot
path (indirect calls are expensive not only on x86 I think).

Jan

  reply	other threads:[~2014-05-14 13:08 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-13 15:50 [PATCH v5 00/14] IOMMU support for ARM Julien Grall
2014-05-13 15:50 ` [PATCH v5 01/14] xen/arm: Introduce flush_tlb_domain Julien Grall
2014-05-14 13:28   ` Ian Campbell
2014-05-14 13:29     ` Julien Grall
2014-05-13 15:50 ` [PATCH v5 02/14] xen/passthrough: amd: Remove domain_id from hvm_iommu Julien Grall
2014-05-13 15:50 ` [PATCH v5 03/14] xen/passthrough: amd: rename iommu_has_feature into amd_iommu_has_feature Julien Grall
2014-05-13 15:50 ` [PATCH v5 04/14] xen/passthrough: vtd: iommu_set_hwdom_mapping is VTD specific Julien Grall
2014-05-13 15:50 ` [PATCH v5 05/14] xen/passthrough: rework hwdom_pvh_reqs to use it also on ARM Julien Grall
2014-05-13 15:50 ` [PATCH v5 06/14] xen/passthrough: iommu: Split generic IOMMU code Julien Grall
2014-05-13 15:50 ` [PATCH v5 07/14] xen/passthrough: iommu: Introduce arch specific code Julien Grall
2014-05-13 15:50 ` [PATCH v5 08/14] xen/passthrough: iommu: Basic support of device tree assignment Julien Grall
2014-05-13 15:50 ` [PATCH v5 09/14] xen/passthrough: Introduce IOMMU ARM architecture Julien Grall
2014-05-13 15:50 ` [PATCH v5 10/14] MAINTAINERS: Add drivers/passthrough/arm Julien Grall
2014-05-13 15:50 ` [PATCH v5 11/14] xen/arm: Don't give IOMMU devices to dom0 when iommu is disabled Julien Grall
2014-05-13 15:50 ` [PATCH v5 12/14] xen/arm: p2m: Clean cache PT when the IOMMU doesn't support coherent walk Julien Grall
2014-05-14  7:18   ` Jan Beulich
2014-05-14  9:09     ` Julien Grall
2014-05-14  9:25       ` Jan Beulich
2014-05-14 12:45         ` Julien Grall
2014-05-14 13:08           ` Jan Beulich [this message]
2014-05-14 13:11             ` Julien Grall
2014-05-14 13:15               ` Jan Beulich
2014-05-14 13:56                 ` Julien Grall
2014-05-13 15:50 ` [PATCH v5 13/14] xen/arm: grant: Add another entry to map MFN 1:1 in dom0 p2m Julien Grall
2014-05-13 15:50 ` [PATCH v5 14/14] drivers/passthrough: arm: Add support for SMMU drivers Julien Grall
2014-05-14  7:29   ` Jan Beulich
2014-05-14 12:47     ` Julien Grall
2014-05-14 14:05 ` [PATCH v5 00/14] IOMMU support for ARM Ian Campbell
2014-05-14 14:13   ` Julien Grall
2014-05-14 14:35   ` Jan Beulich

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=537386DB020000780001228B@mail.emea.novell.com \
    --to=jbeulich@suse.com \
    --cc=ian.campbell@citrix.com \
    --cc=julien.grall@linaro.org \
    --cc=stefano.stabellini@citrix.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xiantao.zhang@intel.com \
    /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).