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 :|