On Wed, Feb 25, 2009 at 07:16:28PM +0000, Mark McLoughlin wrote: > On Wed, 2009-02-25 at 17:51 +0000, Daniel P. Berrange wrote: > > On Tue, Feb 24, 2009 at 10:21:48PM +0000, Mark McLoughlin wrote: > > > Before starting a guest virNodeDeviceAttach() is intended > > > to be called on all node devices to be assigned to a guest, > > > followed by virNodeDeviceReset() on those devices. > > > > > > Once the guest has been shutdown, virNodeDeviceReset() > > > followed by virNodeDeviceReAttach() should be called in > > > order to make the device available to the host again. > > > > > > This patch merely adds the APIs and stubs out the driver > > > implementations. > > > > While I can see a point in providing public APIs to attach/detach > > drivers to devices - because we need this for Xen driver PCI > > passthrough, I'm not sure theres a compelling need for exposing > > a reset function, because both Xen & your KVM impl are quite > > happy doing the resets themselves. > > The idea with the reset function is that calling reset is a way for the > app to query whether this is an assignable device - e.g. if the user > chooses a given NIC to pass through in one of the early screens in > virt-manager, we can give a "you can't assign that device" error at that > point rather than just having the guest fail to start up much later on. I wonder if we should generalize that beyond just host device, to cover VM device hotplug in general, passing in the same XML doc you'd use for the subsequent virDomainAttachDevice() call. virDomainCanAttachDevice(virDomainPtr dom, const char *xml); Though, obviously that won't help for scenarios before a virDomainPtr exists. So might also want a way to ask whether a device is likely to be supported before creating a VM virConnectSupportsDevice(virConnectPtr conn, const char *xml) But then maybe this is getting into overkill, and just rename the reset function to int virNodeDeviceAssignable(virNodeDevicePtr dev); so we're not explicitly saying 'reset' is the test we're doing, even though that may be the internal impl 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