On Tue, Mar 31, 2009 at 10:10:14AM +0200, Gerd Hoffmann wrote:
Hi,
> +static const char *
> +pciFindStubDriver(virConnectPtr conn)
> +{
> + char drvpath[PATH_MAX];
> + int probed = 0;
> +
> +recheck:
> + pciDriverDir(drvpath, sizeof(drvpath), "pci-stub");
> + if (virFileExists(drvpath))
> + return "pci-stub";
> + pciDriverDir(drvpath, sizeof(drvpath), "pciback");
> + if (virFileExists(drvpath))
> + return "pciback";
> +
> + if (!probed) {
> + const char *const stubprobe[] = { MODPROBE, "pci-stub", NULL };
> + const char *const backprobe[] = { MODPROBE, "pciback", NULL };on
xen.
> +
> + probed = 1;
> + if (virRun(conn, stubprobe, NULL) < 0 &&
> + virRun(conn, backprobe, NULL) < 0) {
> char ebuf[1024];
> - VIR_WARN(_("modprobe %s failed: %s"), stub_module,
> + VIR_WARN(_("failed to load pci-stub or pciback drivers:
%s"),
> virStrerror(errno, ebuf, sizeof ebuf));
> + return 0;
> }
> +
> + goto recheck;
> }
I'd tend to reverse that ordering. It isn't a issue today, but once
pv_ops/dom0 gets pciback support you might actually have both modules
present for a given kernel.
pci-stub doesn't do anything special and will load just fine in any
environment. pciback is xen-specific (especially the part which handles
pci passthrough to pv domains) and should not load when not running on xen.
Ahh, I was assuming that pciback would just go the way of the dodo
when dom0 pvops merged. I had forgotten it would still be needed for
pure PV pci passthrough without VT-d. So reversing it seems reasonable
Regards,
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://ovirt.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|