[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH 0/2] Dettach and reset devices before assigning to guests

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.

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]