On Tue, Feb 24, 2009 at 10:35:37PM +0000, Mark McLoughlin wrote:
Hi,
The following two patches build on the previous series.
The idea is simple - when starting a guest, we should
automatically dettach and reset any devices assigned to it.
Rather than change the semantics of the existing
hostdev source, we only do this when the node device name is
used as the hostdev source. Directly specifying the device
address rather than its name can be seen as an option for
people who know what they're doing.
I don't like this idea really. The reason we use the PCI address in the
XML is because that is a guarenteed stable identifier. The names given
to nodedevices are currently under such a guarentee. So if we used the
nodedev naming and then a Fedora release switched from HAL to DeviceKit
nodedev drivers, any guests with PCI devs attached wouuld be broken.
NB, I *do* think we should define a standard stable naming for nodedevs,
that is identical whether using HAL of DeviceKit, but even if we had
that I don't particularly like idea of using the names here when we
already have a workable addressing scheme in the XML.
If we want to indicate whether the HV or caller should be responsible
for attach/detach/reset operations, we should just add some boolean
flag to the <hostdev> element. We'll also likely need to add something
to the capabilities XML format to identify what PCI passthrough features
are supported by a HV. eg, With your KVM patches we can mange the
attach/detach/reset stuff internally, or leave it upto the mgmt app.
The Xen impl though will have no such choice currently - XenD expects
that you've done the attach/detach yourself, and merely does the reset
stuff internally.
Perhaps allow for autoattach="yes|no" or managed="yes|no" to
indicate
whether we should do a detach/attach internally or not.
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 :|