Xen devel - Oct 2008 - [PATCH] [VTD] Remove PCI device enumeration for dom0 in Xen

There are already PCI probe and remove callbacks in dom0 (c/s 593 in
linux-2.6.18-xen.hg). So it is not necessary to enumerate devices for
dom0 in Xen.

Espen had a patch (c/s 17975) to do the same thing, but his patch was
reverted in order to allow old dom0 kernels to work with iommu-capable
platforms. Xen 3.3 has been released for a few months, I think it''s
time
to clean up it. The rebased patch is attached.

Keir, what''s your opinion?

Signed-off-by: Espen Skoglund <espen.skoglund@netronome.com>
Signed-off-by: Weidong Han <weidong.han@intel.com>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Han, Weidong wrote:
> There are already PCI probe and remove callbacks in dom0 (c/s 593 in
linux-2.6.18-xen.hg). So it is not necessary to enumerate devices for dom0 in
Xen.
> 
> Espen had a patch (c/s 17975) to do the same thing, but his patch was
reverted in order to allow old dom0 kernels to work with iommu-capable
platforms. Xen 3.3 has been released for a few months, I think it''s
time to clean up it. The rebased patch is attached.
> 
> Keir, what''s your opinion?
> 
> Signed-off-by: Espen Skoglund <espen.skoglund@netronome.com>
> Signed-off-by: Weidong Han <weidong.han@intel.com>
> 
> 
Acked-by: Yu Zhao <yu.zhao@intel.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 22/10/08 09:59, "Han, Weidong" <weidong.han@intel.com> wrote:
> There are already PCI probe and remove callbacks in dom0 (c/s 593 in
> linux-2.6.18-xen.hg). So it is not necessary to enumerate devices for
> dom0 in Xen.
> 
> Espen had a patch (c/s 17975) to do the same thing, but his patch was
> reverted in order to allow old dom0 kernels to work with iommu-capable
> platforms. Xen 3.3 has been released for a few months, I think
it''s time
> to clean up it. The rebased patch is attached.
> 
> Keir, what''s your opinion?
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.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

[Keir Fraser]
> On 22/10/08 09:59, "Han, Weidong" <weidong.han@intel.com>
wrote:
>> There are already PCI probe and remove callbacks in dom0 (c/s 593 in
>> linux-2.6.18-xen.hg). So it is not necessary to enumerate devices for
>> dom0 in Xen.
>> 
>> Espen had a patch (c/s 17975) to do the same thing, but his patch was
>> reverted in order to allow old dom0 kernels to work with iommu-capable
>> platforms. Xen 3.3 has been released for a few months, I think
it''s time
>> to clean up it. The rebased patch is attached.
>> 
>> Keir, what''s your opinion?
> 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.

	eSk



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

[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).

	eSk




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser wrote:
> 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?
> 
 At present, I don''t see any other disadvantage on functionality, apart
from it annoyingly sitting there and it allocates two pdev for the same
bdf.

Regards,
Weidong


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

[Weidong Han]
> Keir Fraser wrote:
>> On 22/10/08 13:38, "Espen Skoglund"
<espen.skoglund@netronome.com>
>> wrote: 
>>> 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?
>> 
> At present, I don''t see any other disadvantage on functionality,
> apart from it annoyingly sitting there and it allocates two pdev for
> the same bdf.
Allocates two pdevs?  How?  alloc_pdev() will not allocate a new pdev
if the bdf already exists.  It will just return the existing one.

	eSk



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Espen Skoglund wrote:
> [Weidong Han]
>> Keir Fraser wrote:
>>> On 22/10/08 13:38, "Espen Skoglund"
<espen.skoglund@netronome.com>
>>> wrote:
>>>> 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?
>>> 
> 
>> At present, I don''t see any other disadvantage on
functionality,
>> apart from it annoyingly sitting there and it allocates two pdev for
>> the same bdf.
> 
> Allocates two pdevs?  How?  alloc_pdev() will not allocate a new pdev
> if the bdf already exists.  It will just return the existing one.
> 
You are right, it won''t allocate twice for one bdf. I made a mistake
-:(

Regards,
Weidong



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel