All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Brian Woods <brian.woods@amd.com>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Subject: Re: [PATCH v5 6/6] amd/iommu: skip bridge devices when updating IOMMU page tables
Date: Wed, 21 Nov 2018 12:51:31 +0100	[thread overview]
Message-ID: <20181121115131.wjpmhjsnesfdw2c4@mac> (raw)
In-Reply-To: <5BF53A5A02000078001FE684@prv1-mh.provo.novell.com>

On Wed, Nov 21, 2018 at 03:58:34AM -0700, Jan Beulich wrote:
> >>> On 21.11.18 at 11:37, <roger.pau@citrix.com> wrote:
> > On Wed, Nov 21, 2018 at 02:21:36AM -0700, Jan Beulich wrote:
> >> >>> On 21.11.18 at 00:26, <Brian.Woods@amd.com> wrote:
> >> > The original commit 0af438757d455f8eb6b5a6ae9a990ae245f230fd
> >> > 
> >> > The commit that adds is_hardware_domain (and rearrange things)
> >> > 7c275549f46c5c46611592f7107c1345e93ed457
> >> > 
> >> > The orginal commit used the function like
> >> > setup_dom0_pci_devices(d, amd_iommu_setup_dom0_device);
> >> > which was because IOMMU needed to skip the host bridge devices on dom0.
> >> > 
> >> > So I assume you added the is_hardware_domain because it only needed to
> >> > be done on dom0.  I'm not familiar with the IOMMU/PCI history wrt to
> >> > what it mapped/passed through so.
> >> 
> >> Well, I added it presumably to retain original semantics. I still
> >> think that the extra check would better be dropped there, not
> >> the least to also cover the case of devices eventually getting
> >> assigned to dom_xen.
> >> 
> >> Looking at this another time I find some other questionable
> >> aspect though (both to pre-existing code and to the change
> >> made here): "host bridge" != "bridge". The title here as much
> >> as the comment next to the original piece of code both
> >> suggest the wider general category is meant, but the code
> >> cloned checks for host bridges only. In
> >> amd_iommu_add_device() the check is used solely to emit a
> >> less scary log message, but the change here goes beyond
> >> that.
> > 
> > The check in amd_iommu_add_device allows host bridge devices to be
> > assigned to the hardware domain without returning an error since they
> > are not behind an IOMMU. Note that even if amd_iommu_add_device
> > returned an error the device would still be added to the hardware
> > domain since the error is eaten by setup_one_hwdom_device and the
> > device is assigned to the hardware domain regardless.
> 
> Hence me saying this check is mainly/just to make the log message
> less scary.
> 
> > So either all devices that are not behind an IOMMU are not assigned to
> > the hardware domain, or update_paging_mode needs this workaround in
> > order to be able to handle IOMMU page table expansion for the hardware
> > domain.
> 
> It looks like we're talking about different aspects: I don't put under
> question that assignment wants to be avoided. What I question is
> why the avoidance gets restricted to the hardware domain.

Not having written this code I can only make guesses. I would say this
is because you don't want to hand a PCI host bridge to a guest so it
cannot play with the registers there and likely move the MCFG or the
MMIO windows. I think the passthrough code in QEMU would already
prevent any such accesses.

> And then the secondary question I put up was why this restriction
> applies to host bridges only, despite title here and comment there
> saying "bridge" in general.

I think this needs to be answered by AMD, but one possibility is that
host bridges are the only bridges that are not behind an IOMMU, the
rest of bridges are expected to be behind an IOMMU.

Thanks, Roger.

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

  reply	other threads:[~2018-11-21 11:51 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-20 16:01 [PATCH v5 0/6] x86/pvh: fixes for PVH Dom0 Roger Pau Monne
2018-11-20 16:01 ` [PATCH v5 1/6] vpci: fix updating the command register Roger Pau Monne
2018-11-26 11:20   ` Jan Beulich
2018-11-20 16:01 ` [PATCH v5 2/6] vpci: fix deferral of long operations Roger Pau Monne
2018-11-26 11:26   ` Jan Beulich
2018-11-26 11:41   ` Jan Beulich
2018-11-26 11:57     ` Paul Durrant
2018-11-20 16:01 ` [PATCH v5 3/6] vpci/msix: carve p2m hole for MSIX MMIO regions Roger Pau Monne
2018-11-20 16:01 ` [PATCH v5 4/6] pci: add a segment parameter to pci_hide_device Roger Pau Monne
2018-11-26 11:29   ` Jan Beulich
2018-11-20 16:01 ` [PATCH v5 5/6] amd/iommu: assign iommu devices to Xen Roger Pau Monne
2018-11-20 16:14   ` Jan Beulich
2018-11-20 16:01 ` [PATCH v5 6/6] amd/iommu: skip bridge devices when updating IOMMU page tables Roger Pau Monne
2018-11-20 16:45   ` Jan Beulich
2018-11-20 23:26     ` Woods, Brian
2018-11-21  9:21       ` Jan Beulich
2018-11-21 10:37         ` Roger Pau Monné
2018-11-21 10:58           ` Jan Beulich
2018-11-21 11:51             ` Roger Pau Monné [this message]
2018-11-21 13:23               ` Jan Beulich
2018-11-22 12:47                 ` Roger Pau Monné
2018-11-22 13:20                   ` Jan Beulich
2018-11-23 14:36                     ` Roger Pau Monné
     [not found]                       ` <60B388B7020000D60063616D@prv1-mh.provo.novell.com>
2018-11-26  8:42                         ` 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=20181121115131.wjpmhjsnesfdw2c4@mac \
    --to=roger.pau@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=brian.woods@amd.com \
    --cc=suravee.suthikulpanit@amd.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.