On Thu, Jul 19, 2007 at 01:17:37AM +0100, Daniel P. Berrange wrote:
> So we need some form of element under the <devices> section per device to
> map through. At minimum this will need the source device info. If we are
> to support unplugging of USB devices in QEMU it is neccessary to have the
> target device id - this is generated by QEMU when attaching the USB device.
>
> So to attach a device:
>
> <host bus='usb'>
> <source device="003.001"/>
> </host>
>
> Or
>
> <host bus='usb'>
> <source vendor='0483' product='2016'>
> </host>
>
> The first form is useful for live hotplug - where you know the exact device
> instance. The second form is useful for permanent config - you don't know
> what device id it'll have since it may be plugged into the host in any order.
>
> When splitting the XML back out, QEMU would fill in the target info giving
> us either:
>
> <host bus='usb'>
> <source dev='003.001'/>
> <target dev='001.005'/>
> </host>
>
> Or
>
> <host bus='usb'>
> <source vendor='0483' product='2016'/>
> <target dev='001.005'/>
> </host>
>
> This is suitable for giving to virDomainDetachDevice() - we use the target
> dev for the QEMU monitor 'usb-detach' command.
Hum, that's the usual internal/external naming problem. Both have different
context of use and life span. The vendor/product identifies the kind of device,
it may not be sufficient to actually identify one of them (one could perfectly
plug two usb mouse one for each side of keyboard), but it's the identifier
which describe the functional requirement. And the other one is an internal
name which may change over time.
IMHO you should output both, then depending how you will reuse that XML
fragment one or the other may be used, this could actually be one argument to
split the device definition entry point and the device modification. For
the definition you would use the vendor/product identifiers, while for example
to simulate a disk change on an USB CDRom reader you would use device numbers.
<host bus='usb'>
<device vendor='0471' product='0311' name='Philips PCVC740K ToUcam Pro'/>
<source dev='003.001'/>
<target dev='001.005'/>
</host>
At the XML format you would require device or source to be present, possibly
both and name would be an optional attribute (which need to be XML escaped).
> Now PCI would be similar - no hotplug to worry about here though, and no
> need (or availability) or target info. So the XML would simply be
>
> <host bus='pci'>
> <source dev='00:1f.3'/>
> </host>
>
You may still have twice the same kind of card plugged on a PCI bus
so just vendor/product doesn't sound sufficient to me. PCI device are
more likely to be static, I would consider vendor/product to be user
informations, but the code would always use the device if present.
> NB I choose 'host' as the element name since we're basically giving the
> guest an arbitrary host device. My previous email had thought about
> calling it 'bus' but we're not really defining a bus in this context and
> there may very well be some scenario in the future where we do need to
> represent the concept of a 'bus' in the XML directly.
Fine by me.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list