All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
	Jason Andryuk <jason.andryuk@amd.com>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: Re: [PATCH 2/2] iommu/amd-vi: do not zero IOMMU MMIO region
Date: Wed, 6 May 2026 10:58:07 +0200	[thread overview]
Message-ID: <afsCn28tVltkg0u5@macbook.local> (raw)
In-Reply-To: <41ec5134-b117-47ee-8e59-682ac1e4a69f@citrix.com>

On Wed, May 06, 2026 at 09:20:07AM +0100, Andrew Cooper wrote:
> On 06/05/2026 8:37 am, Roger Pau Monne wrote:
> > Attempting to memset the whole IOMMU MMIO region to zero is dangerous to
> > say the least.  We don't know what registers might be there, neither what
> > values might be safe for those registers.
> 
> Minor grammar.  "there, nor which values".
> 
> > On a forthcoming platform doing
> > the zeroing of the MMIO region can put the IOMMU in a broken state,
> 
> "does put"
> 
> > which is not recovered by the IOMMU initialization procedure in Xen.
> 
> "recoverable".
> 
> > diff --git a/xen/drivers/passthrough/amd/iommu_init.c b/xen/drivers/passthrough/amd/iommu_init.c
> > index 76ae78e5ea53..8bf5ca4de18f 100644
> > --- a/xen/drivers/passthrough/amd/iommu_init.c
> > +++ b/xen/drivers/passthrough/amd/iommu_init.c
> > @@ -1367,11 +1355,14 @@ static int __init amd_iommu_prepare_one(struct amd_iommu *iommu)
> >  {
> >      int rc = alloc_ivrs_mappings(iommu->sbdf.seg);
> >  
> > -    if ( !rc )
> > -        rc = map_iommu_mmio_region(iommu);
> >      if ( rc )
> >          return rc;
> >  
> > +    iommu->mmio_base = ioremap(iommu->mmio_base_phys,
> > +                               IOMMU_MMIO_REGION_LENGTH);
> > +    if ( !iommu->mmio_base )
> > +        return -ENOMEM;
> > +
> >      get_iommu_features(iommu);
> >  
> >      /*
> > @@ -1381,6 +1372,11 @@ static int __init amd_iommu_prepare_one(struct amd_iommu *iommu)
> >      if ( amd_iommu_max_paging_mode < amd_iommu_min_paging_mode )
> >          return -ERANGE;
> >  
> > +    /* Read current control register and forcefully disable the IOMMU. */
> > +    iommu->ctrl.raw = readq(iommu->mmio_base + IOMMU_CONTROL_MMIO_OFFSET);
> > +    disable_iommu(iommu, true);
> > +    iommu->ctrl.raw = 0;
> > +
> >      return 0;
> >  } 
> 
> These two things are unrelated at want splitting into separate patches
> at a minimum.  The removal of memset() critically needs backporting.

But is it safe to backport the memset without also backporting the
disabling side?  We might then be dealing with an enabled IOMMU which
could lead to all sorts of fun.

> As for disabling the IOMMU, I'm not certain it's wise.
> 
> Linux can already "bring up" an already-live IOMMU and Xen needs to gain
> this ability in due course.  This is mainly for supporting PreBoot DMA
> Protection, but also for things like the kexec environment.

Note that Linux (when not booted from kdump) will do a similar sequence of
what I'm attempting to do here for Xen and will call iommu_disable()
ahead of attempting to enable the IOMMU.

I understand that when Xen supports kdump or preboot DMA protection we
would need to be more careful there, but going from zeroing the whole
MMIO area (which disables everything) to not doing any kind of
disabling is IMO a dangerous approach, and I would rather backport a
change that at least attempts to make sure the IOMMU is disabled.

Thanks, Roger.


  parent reply	other threads:[~2026-05-06  8:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-06  7:37 [PATCH 0/2] iommu/amd-vi: remove zeroing of MMIO region Roger Pau Monne
2026-05-06  7:37 ` [PATCH 1/2] iommu/amd-vi: allow disable_iommu() against non-initialized IOMMUs Roger Pau Monne
2026-05-06  8:19   ` Jan Beulich
2026-05-06  7:37 ` [PATCH 2/2] iommu/amd-vi: do not zero IOMMU MMIO region Roger Pau Monne
2026-05-06  8:20   ` Andrew Cooper
2026-05-06  8:32     ` Jan Beulich
2026-05-06  9:02       ` Andrew Cooper
2026-05-06  9:27         ` Jan Beulich
2026-05-06  8:58     ` Roger Pau Monné [this message]
2026-05-06  9:41       ` Andrew Cooper
2026-05-06  8:28   ` Jan Beulich
2026-05-06  8:43     ` Roger Pau Monné
2026-05-06  9:17       ` Jan Beulich
2026-05-06  9:20         ` Roger Pau Monné
2026-05-06  9:28           ` 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=afsCn28tVltkg0u5@macbook.local \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jason.andryuk@amd.com \
    --cc=jbeulich@suse.com \
    --cc=teddy.astie@vates.tech \
    --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.