WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 0/5] pcie io space multiplexing for bootable pass

On Fri, May 29, 2009 at 10:27:14AM +0800, Tian, Kevin wrote:
> >From: Isaku Yamahata [mailto:yamahata@xxxxxxxxxxxxx] 
> >Sent: 2009年5月28日 18:52
> >> How about same box used
> >> in native environment, where how admin can judge which PCI-e slot
> >> is allocated with I/O ports for bootable purpose?
> >
> >I'm not sure I understand your point.
> >You mean there should be a way for an admin to know easily 
> >which pcie slot
> >is specified?
> >The admins should know what they did. They know what kernel 
> >command line
> >they passed to the kernel. or /proc/cmdline.
> >
> 
> In a native case, as you said, only 16 or fewer (if legacy ISA card
> exists) PCI-e slots can be assigned with I/O resources. Say an
> admin wants to insert a bootable card. How can this guy know 
> which slot will be granted with I/O resources by kernel? Does 
> native Linux provide similar cmdline as your approach to assign
> which slot to be I/O capable? Or admin has to use lspci with
> assumption that next boot kernel will assign I/O in same way?

Oh I see. The answers are
- The admin has to lspci or /proc/iomem.
and
- no
and
- yes

In general, the admin usually doesn't have to worry how IO space is
assigned to PCIe slot where kernel is running on native.
It doesn't matter for OS because almost all device drivers for PCIe
cards don't access IO space. The IO space is accessed only by ROM BIOS
on the card.
In order to avoid the issues you described above, the PCIe specification
encourages hardware vendors to provide memory space for OS device drivers
and to use IO space only for booting OS,
i.e. IO space should be used only by ROM BIOS and OS device drivers
shouldn't access IO space.
Of course, there might be exceptions.

"boot" is the key. On native environment "boot" from a PCIe device
takes place only one time before OS involved. Once OS booted, it doesn't
care about IO space.
On the other hand on virtualized environment with pass-through PCIe cards,
"booting" guest OS takes place many times from arbitrary PCIe cards.
Here the need for IO space multiplexing arises. I hardly see any other
use case.

thanks,
-- 
yamahata

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