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 :|
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list