All of lore.kernel.org
 help / color / mirror / Atom feed
From: Weidong Han <weidong.han@intel.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: 'Avi Kivity' <avi@redhat.com>,
	"'iommu@lists.linux-foundation.org'"
	<iommu@lists.linux-foundation.org>, 'kvm' <kvm@vger.kernel.org>,
	"Kay, Allen M" <allen.m.kay@intel.com>
Subject: Re: [PATCH] VT-d: fix PCI device detach from virtual machine
Date: Thu, 17 Jun 2010 11:35:46 +0800	[thread overview]
Message-ID: <4C199812.4080703@intel.com> (raw)
In-Reply-To: <1276557557.2063.43.camel@macbook.infradead.org>

David Woodhouse wrote:
> On Thu, 2009-02-26 at 17:31 +0800, Han, Weidong wrote:
>   
>> When assign a device behind conventional PCI bridge or PCIe to
>> PCI/PCI-x bridge to a domain, it must assign its bridge and may
>> also need to assign secondary interface to the same domain. 
>>
>> Dependent assignment is already there, but dependent
>> deassignment is missed when detach device from virtual machine.
>> This results in conventional PCI device assignment failure after
>> it has been assigned once. This patch addes dependent
>> deassignment, and fixes the issue. 
>>     
>
> Um, this code makes my head hurt.
>
> Why are we doing this in the first place? Because the IOMMU works on the
> source-id in PCIe transactions, the pci_find_upstream_pcie_bridge()
> function effectively tells us which PCI device our own device will be
> masquerading as, for the purposes of DMA.
>
> So why do we bother setting up a context in the IOMMU for the device
> itself, when no DMA will ever appear to come from this device? And
>   
if the device is behind PCI Express-to-PCI/PCI-X bridge, the source-id 
may be the device bdf or the
source-id provided by the bridge. so it needs to map the device itself.
> likewise why do we bother setting up a context for intermediate PCI
> bridges?
>   
I'm not sure if the intermediate PCI bridges are necessary. need to 
check PCI spec.
> Why not just jump straight to the 'DMA proxy' device, and use that
> _only_?
>   
What's the 'DMA proxy' device? is it the upstream pcie-to-pci bridge?
> We'll have to cope with multiple devices behind the same 'proxy', but it
> looks like our handling of that is totally screwed already...  what
> happens right now if you have two PCI devices behind the same PCIe-PCI
> bridge, and try to attach both of them to different domains... or both
> to the _same_ domain, in fact, and then detach just one of them. I think
> the answer to the latter question is that your newly-added
> iommu_detach_dependent_devices() routine will tear down the mapping on
> the 'proxy' device and faults will start happening for the device which
> is supposed to still be mapped?
>   
all the device behind a pcie-to-pci bridge must be co-assigned to a 
single domain. So it also require users to detach them together.

Regards,
Weidong
> Confused... and tempted to rip it all out and start over.
>
>   


  parent reply	other threads:[~2010-06-17  3:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-26  9:31 [PATCH] VT-d: fix PCI device detach from virtual machine Han, Weidong
2010-06-14 23:19 ` David Woodhouse
2010-06-15 14:10   ` Joerg Roedel
2010-06-15 14:52     ` David Woodhouse
2010-06-17  3:35   ` Weidong Han [this message]
2010-06-17  8:49     ` David Woodhouse
2010-06-17  9:15       ` Weidong Han

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=4C199812.4080703@intel.com \
    --to=weidong.han@intel.com \
    --cc=allen.m.kay@intel.com \
    --cc=avi@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=kvm@vger.kernel.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.