Re: [Xen-devel] [PATCH] linux: allow pciback to be built as a module

[Ryan <hap9@xxxxxxxxxxxxxx>]

On Thu, 2006-03-09 at 10:26 +0100, Jan Beulich wrote:
> >> >> -               pcibios_set_master(dev);
> >> >> +               pci_set_master(dev);
> >> >
> >> >There's probably not any problem here, but most of pci_set_master is
> >> >already done in the frontend (when the frontend device driver calls
> >> >pci_set_master), I was trying to avoid duplicating the effects of
> >> >pci_set_master here by using pcibios_set_master instead.
> >> 
> >> The main reason for these changes is that only pci_* are exported, not 
> >> pcibios_*.
> >> 
> >
> >I think the only place where there could potentially be an issue is
> >changing pcibios_enable_device to pci_enable_device. pci_enable_device
> >calls pci_fixup_device which *may* have some side effects that a
> >non-linux driver domain may not expect or want. Maybe you could call
> >pci_enable_device_bars (which is exported) just like it's called in
> >pci_enable_device to skip the pci_fixup_device method.
> 
> I'm not certain about that - pci_fixup_device is called in a number of other 
> places
> (with different stage arguments), most notably in pci_init for *all* devices, 
> and
> hence not calling it here might result in inconsistencies. I would want to 
> either
> suppress all of the calls for a device handled outside dom0, or none. Since
> suppressing all (or reverting possible previous adjustments) is going to be at
> least difficult, I think letting the call happen here is better.
> 

Well it appears that all of the fixups done on the enable hook (there's
only 3 of them in 2.6.16-rc5!) are pretty innocent so I guess there
really isn't a concern about this now. By concern about the enable was
changing random registers while the domU thinks it is the only one in
charge of the card. All of the other calls to pci_fixup_device happen at
points in the kernel before the pci backend can prepare a device for
export so changes won't happen while a domU is controlling a device (the
pci_fixup_device call from pci_init happens on device_initcall,
drivers/pci gets linked in before drivers/xen so it should get called
first). the pci_fixup_device in pci_enable_device is the one point where
a fixup hook could change something significant without the domU aware.
It appears that there's nothing to worry about with the current code in
the kernel, but someone could always add a new fixup hook in the future.
I think the correct way to do this is use pci_enable_device_bars and
skip the pci_fixup_device, but I don't see any problem with just using
pci_enable_device right now.

Ryan


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