On Wed, 2010-05-19 at 22:34 -0700, Chris Wright wrote:
* Alex Williamson (alex.williamson(a)redhat.com) wrote:
> @@ -1378,6 +1420,9 @@ int qemudExtractVersionInfo(const char *qemu,
> &version, &is_kvm, &kvm_version) == -1)
> goto cleanup2;
>
> + if (flags & QEMUD_CMD_FLAG_DEVICE)
> + qemudParsePCIDeviceStrs(qemu, &flags);
> +
looks like this is called early enough for both cmdline and monitor
interface
Yes, it should be.
> + /* XXX don't hard code segment */
You don't need to, just...
> + if (virAsprintf(&path,
"/sys/bus/pci/devices/0000:%02x:%02x.%01x/config",
/
s/0000/%04x/ --------------------------------------
> + dev->source.subsys.u.pci.bus,
dev->source.subsys.u.pci.slot,
and add dev->source.subsys.u.pci.domain
Oh good, I meant to look, but obviously forgot. Fixed.
> + dev->source.subsys.u.pci.function) <
0) {
> + virReportOOMError();
> + return -1;
> + }
> +
> + configfd = open(path, O_RDWR, 0);
Should probably report an open failure to aid debugging.
Done.
> --- a/src/qemu/qemu_driver.c
> +++ b/src/qemu/qemu_driver.c
> @@ -7567,7 +7567,7 @@ static int qemudDomainAttachHostPciDevice(struct qemud_driver
*driver,
> if (qemuDomainPCIAddressEnsureAddr(priv->pciaddrs,
&hostdev->info) < 0)
> goto error;
>
> - if (!(devstr = qemuBuildPCIHostdevDevStr(hostdev)))
> + if (!(devstr = qemuBuildPCIHostdevDevStr(hostdev, -1)))
Looks like this is dynamically assigning host PCI device to running guest,
we should still be able to pass fd here. That will complicate the qemu
side to be able to accept the fd.
We could certainly open the file and pass an fd, but I don't know how to
let qemu make use of it after it's been spawned, so I reverted to
existing behavior here. Thanks,
Alex