All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Kevin Tian <kevin.tian@intel.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/5] IOMMU: iommu_intremap is x86-only
Date: Mon, 2 Mar 2020 11:07:16 +0100	[thread overview]
Message-ID: <cf139d45-13ba-668e-f2e9-b88180429db7@suse.com> (raw)
In-Reply-To: <d851c095-84a1-9edb-5905-64860fb1b7a7@citrix.com>

On 28.02.2020 21:16, Andrew Cooper wrote:
> On 28/02/2020 12:26, Jan Beulich wrote:
>> Provide a #define for other cases; it didn't seem worthwhile to me to
>> introduce an IOMMU_INTREMAP Kconfig option at this point.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> --- a/docs/misc/xen-command-line.pandoc
>> +++ b/docs/misc/xen-command-line.pandoc
>> @@ -1299,6 +1299,8 @@ boolean (e.g. `iommu=no`) can override t
>>      generation of IOMMUs only supported DMA remapping, and Interrupt Remapping
>>      appeared in the second generation.
>>  
>> +    This option is not valid on Arm.
> 
> The longevity of this comment would be greater if it were phrased as "is
> only valid on x86", especially given the RFC RISCV series on list.

How do we know how intremap is going to work on future ports?

>> @@ -90,8 +89,10 @@ static int __init parse_iommu_param(cons
>>              iommu_snoop = val;
>>          else if ( (val = parse_boolean("qinval", s, ss)) >= 0 )
>>              iommu_qinval = val;
>> +#ifndef iommu_intremap
>>          else if ( (val = parse_boolean("intremap", s, ss)) >= 0 )
>>              iommu_intremap = val ? iommu_intremap_full : iommu_intremap_off;
>> +#endif
> 
> The use of ifndef in particular makes the result very weird to read. 
> There appear to be no uses of iommu_intremap outside of x86 code, other
> than in this setup, so having it false in the !CONFIG_X86 case isn't
> helpful.
> 
> How about just guarding uses of the variable with IS_ENABLED(CONFIG_X86)
> and a common extern?  We use this DCE trick already to reduce the
> ifdefary in the code.

A common extern would mean to guard _all_ uses of the variable, also
reads. That's a lot of IS_ENABLED(CONFIG_X86) to add. Furthermore,
as said above, I'm unconvinced all future ports would be Arm-like in
this regard (historically at least ia64 wasn't).

The idea of using #ifdef like is done here is that a new port would
typically only need to adjust the conditional around the declaration/
#define to choose one of the two options. No other could would need
touching. IS_ENABLED(CONFIG_X86), otoh, would require all sites we'd
add now to be touched again when an x86-like port appears.

Jan

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

  reply	other threads:[~2020-03-02 10:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-28 12:24 [Xen-devel] [PATCH 0/5] IOMMU: restrict visibility/scope if certain variables Jan Beulich
2020-02-28 12:26 ` [Xen-devel] [PATCH 1/5] IOMMU: iommu_intremap is x86-only Jan Beulich
2020-02-28 20:16   ` Andrew Cooper
2020-03-02 10:07     ` Jan Beulich [this message]
2020-03-02 10:44       ` Julien Grall
2020-03-02 10:57         ` Jan Beulich
2020-03-02 11:25           ` Julien Grall
2020-02-28 12:26 ` [Xen-devel] [PATCH 2/5] IOMMU: iommu_intpost is x86/HVM-only Jan Beulich
2020-02-28 12:27 ` [Xen-devel] [PATCH 3/5] IOMMU: iommu_igfx is x86-only Jan Beulich
2020-02-28 12:27 ` [Xen-devel] [PATCH 4/5] IOMMU: iommu_qinval " Jan Beulich
2020-02-28 12:27 ` [Xen-devel] [PATCH 5/5] IOMMU: iommu_snoop is x86/HVM-only Jan Beulich
2020-02-28 20:20   ` Andrew Cooper
2020-03-02 10:14     ` Jan Beulich
2020-03-04 14:34 ` [Xen-devel] [PATCH 0/5] IOMMU: restrict visibility/scope if certain variables Julien Grall
2020-03-09  6:33 ` Tian, Kevin

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=cf139d45-13ba-668e-f2e9-b88180429db7@suse.com \
    --to=jbeulich@suse.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ian.jackson@citrix.com \
    --cc=julien@xen.org \
    --cc=kevin.tian@intel.com \
    --cc=konrad.wilk@oracle.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --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.