All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: "Cooper, Andrew" <andrew.cooper3@citrix.com>,
	"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>,
	"Paul Durrant" <paul@xen.org>
Subject: RE: [PATCH v2 1/3] x86/IOMMU: mark IOMMU / intremap not in use when ACPI tables are missing
Date: Fri, 29 Oct 2021 08:44:38 +0000	[thread overview]
Message-ID: <BN9PR11MB5433E504303B916154265E678C879@BN9PR11MB5433.namprd11.prod.outlook.com> (raw)
In-Reply-To: <ffe7f130-9034-50d0-ab0a-06933dde88d8@suse.com>

> From: Jan Beulich <jbeulich@suse.com>
> Sent: Friday, October 22, 2021 1:59 PM
> 
> On 21.10.2021 11:58, Jan Beulich wrote:
> > x2apic_bsp_setup() gets called ahead of iommu_setup(), and since x2APIC
> > mode (physical vs clustered) depends on iommu_intremap, that variable
> > needs to be set to off as soon as we know we can't / won't enable
> > interrupt remapping, i.e. in particular when parsing of the respective
> > ACPI tables failed. Move the turning off of iommu_intremap from AMD
> > specific code into acpi_iommu_init(), accompanying it by clearing of
> > iommu_enable.
> >
> > Take the opportunity and also fully skip ACPI table parsing logic on
> > VT-d when both "iommu=off" and "iommu=no-intremap" are in effect
> anyway,
> > like was already the case for AMD.
> >
> > The tag below only references the commit uncovering a pre-existing
> > anomaly.
> >
> > Fixes: d8bd82327b0f ("AMD/IOMMU: obtain IVHD type to use earlier")
> > Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Ouch, forgot to Cc Kevin; now added.

Reviewed-by: Kevin Tian <kevin.tian@intel.com>

> 
> Jan
> 
> > ---
> > While the change here deals with apic_x2apic_probe() as called from
> > x2apic_bsp_setup(), the check_x2apic_preenabled() path looks to be
> > similarly affected. That call occurs before acpi_boot_init(), which is
> > what calls acpi_iommu_init(). The ordering in setup.c is in part
> > relatively fragile, which is why for the moment I'm still hesitant to
> > move the generic_apic_probe() call down. Plus I don't have easy access
> > to a suitable system to test this case. Thoughts?
> > ---
> > v2: Treat iommu_enable and iommu_intremap as separate options.
> >
> > --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> > +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> > @@ -183,9 +183,6 @@ int __init acpi_ivrs_init(void)
> >  {
> >      int rc;
> >
> > -    if ( !iommu_enable && !iommu_intremap )
> > -        return 0;
> > -
> >      rc = amd_iommu_get_supported_ivhd_type();
> >      if ( rc < 0 )
> >          return rc;
> > @@ -193,10 +190,7 @@ int __init acpi_ivrs_init(void)
> >      ivhd_type = rc;
> >
> >      if ( (amd_iommu_detect_acpi() !=0) || (iommu_found() == 0) )
> > -    {
> > -        iommu_intremap = iommu_intremap_off;
> >          return -ENODEV;
> > -    }
> >
> >      iommu_init_ops = &_iommu_init_ops;
> >
> > --- a/xen/drivers/passthrough/vtd/dmar.c
> > +++ b/xen/drivers/passthrough/vtd/dmar.c
> > @@ -777,11 +777,7 @@ static int __init acpi_parse_dmar(struct
> >      dmar = (struct acpi_table_dmar *)table;
> >      dmar_flags = dmar->flags;
> >
> > -    if ( !iommu_enable && !iommu_intremap )
> > -    {
> > -        ret = -EINVAL;
> > -        goto out;
> > -    }
> > +    ASSERT(iommu_enable || iommu_intremap);
> >
> >      if ( !dmar->width )
> >      {
> > --- a/xen/drivers/passthrough/x86/iommu.c
> > +++ b/xen/drivers/passthrough/x86/iommu.c
> > @@ -41,6 +41,24 @@ enum iommu_intremap __read_mostly iommu_
> >  bool __read_mostly iommu_intpost;
> >  #endif
> >
> > +void __init acpi_iommu_init(void)
> > +{
> > +    int ret;
> > +
> > +    if ( !iommu_enable && !iommu_intremap )
> > +        return;
> > +
> > +    ret = acpi_dmar_init();
> > +    if ( ret == -ENODEV )
> > +        ret = acpi_ivrs_init();
> > +
> > +    if ( ret )
> > +    {
> > +        iommu_enable = false;
> > +        iommu_intremap = iommu_intremap_off;
> > +    }
> > +}
> > +
> >  int __init iommu_hardware_setup(void)
> >  {
> >      struct IO_APIC_route_entry **ioapic_entries = NULL;
> > --- a/xen/include/asm-x86/acpi.h
> > +++ b/xen/include/asm-x86/acpi.h
> > @@ -141,16 +141,10 @@ extern u32 x86_acpiid_to_apicid[];
> >  extern u32 pmtmr_ioport;
> >  extern unsigned int pmtmr_width;
> >
> > +void acpi_iommu_init(void);
> >  int acpi_dmar_init(void);
> >  int acpi_ivrs_init(void);
> >
> > -static inline int acpi_iommu_init(void)
> > -{
> > -    int ret = acpi_dmar_init();
> > -
> > -    return ret == -ENODEV ? acpi_ivrs_init() : ret;
> > -}
> > -
> >  void acpi_mmcfg_init(void);
> >
> >  /* Incremented whenever we transition through S3. Value is 1 during boot.
> */
> >
> >


  reply	other threads:[~2021-10-29  8:45 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-21  9:57 [PATCH v2 0/3] x86/IOMMU: enabled / intremap handling Jan Beulich
2021-10-21  9:58 ` [PATCH v2 1/3] x86/IOMMU: mark IOMMU / intremap not in use when ACPI tables are missing Jan Beulich
2021-10-22  5:59   ` Jan Beulich
2021-10-29  8:44     ` Tian, Kevin [this message]
2021-10-22 15:52   ` Roger Pau Monné
2021-11-02 10:07     ` Jan Beulich
2021-11-02 10:26       ` Roger Pau Monné
2021-10-21  9:58 ` [PATCH v2 2/3] x86/APIC: avoid iommu_supports_x2apic() on error path Jan Beulich
2021-10-25  8:41   ` Roger Pau Monné
2021-10-21  9:59 ` [PATCH v2 3/3] AMD/IOMMU: iommu_enable vs iommu_intremap Jan Beulich
2021-10-25 10:28   ` Roger Pau Monné
2021-11-02 10:13     ` Jan Beulich
2021-11-02 11:03       ` Roger Pau Monné
2021-11-02 14:00         ` Jan Beulich
2021-11-02 14:59           ` Roger Pau Monné
2021-11-03  9:46         ` Jan Beulich
2021-11-03 15:06           ` Roger Pau Monné
2021-11-03 15:15             ` Jan Beulich
2021-11-03 17:00               ` Roger Pau Monné
2021-11-02 10:17 ` [PATCH v2 0/3] x86/IOMMU: enabled / intremap handling Jan Beulich
2021-11-03 11:01   ` [PATCH v2 0/3][4.16] " Jan Beulich
2021-11-03 16:19     ` Ian Jackson
2021-11-04  8:15       ` Jan Beulich
2021-11-04 11:10         ` Ian Jackson

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=BN9PR11MB5433E504303B916154265E678C879@BN9PR11MB5433.namprd11.prod.outlook.com \
    --to=kevin.tian@intel.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=paul@xen.org \
    --cc=roger.pau@citrix.com \
    --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.