All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yu Zhao <yu.zhao@uniscape.net>
To: Espen Skoglund <espen.skoglund@netronome.com>
Cc: "Kay, Allen M" <allen.m.kay@intel.com>,
	"Zhao, Yu" <yu.zhao@intel.com>,
	xen-devel@lists.xensource.com, "Han,
	Weidong" <weidong.han@intel.com>,
	Keir Fraser <keir.fraser@eu.citrix.com>
Subject: Re: [PATCH] [VTD] Remove PCI device enumeration for	dom0 in Xen
Date: Wed, 22 Oct 2008 23:39:02 +0800	[thread overview]
Message-ID: <48FF4916.9070502@uniscape.net> (raw)
In-Reply-To: <18687.9027.201750.98978@gargle.gargle.HOWL>

Espen Skoglund wrote:
> [Keir Fraser]
>> On 22/10/08 13:38, "Espen Skoglund" <espen.skoglund@netronome.com> wrote:
> 
>>>> Xen 3.3 should continue to work with older dom0 kernels. However,
>>>> now that iommu is *disabled* by default, will this mean that it
>>>> would continue to work with older dom0 kernels so long as iommu is
>>>> not enabled on the Xen command line? This should be tested and
>>>> confirmed with this patch applied.  If so, I would accept it.
>>> Users of pci_lock_pdev() and pci_lock_domain_pdev() would not be
>>> able to find the PCI device unless it has been registered by dom0.
>>> Apart from the iommu code, the only user affected would be the MSI
>>> code which looks up the PCI device before enabling MSIs on it.  As
>>> such, you would not be able to enable MSIs if you have an old dom0
>>> kernel.
> 
>> Is there any disadvantage to keeping this legacy code in Xen, apart
>> from it annoyingly sitting there?
> 
> You would get a list of PCI devices in Xen containing entries that are
> not necessarily in use.  Some of the entries might even be bogus.
> Apart from some annoying extra code and additional entries in the
> IOMMU page tables, I don't think there is much of a problem.  There
> could be some potential problems if Xen at a future stage decides to
> do some in-hypervisor cleverness with all known PCI devices (a not
> very likely scenario IMHO).

We would have bus number rebalance (hotplug, etc.) and PCI domain 
support in the future, which may require hypervisor to keep consistent 
device list with dom0 kernel. If we don't remove the code, we still have 
to fix the list up.

Thanks,
Yu

  reply	other threads:[~2008-10-22 15:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-22  8:59 [PATCH] [VTD] Remove PCI device enumeration for dom0 in Xen Han, Weidong
2008-10-22  9:29 ` Zhao, Yu
2008-10-22 10:42 ` Keir Fraser
2008-10-22 12:38   ` Espen Skoglund
2008-10-22 12:43     ` Keir Fraser
2008-10-22 12:57       ` Espen Skoglund
2008-10-22 15:39         ` Yu Zhao [this message]
2008-10-22 13:15       ` Han, Weidong
2008-10-22 13:19         ` Espen Skoglund
2008-10-22 13:26           ` Han, Weidong

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=48FF4916.9070502@uniscape.net \
    --to=yu.zhao@uniscape.net \
    --cc=allen.m.kay@intel.com \
    --cc=espen.skoglund@netronome.com \
    --cc=keir.fraser@eu.citrix.com \
    --cc=weidong.han@intel.com \
    --cc=xen-devel@lists.xensource.com \
    --cc=yu.zhao@intel.com \
    /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.