[libvirt] [PATCH 3/3] qemu: Forbid user aliases for USB controllers

[Peter Krempa]

On Mon, Mar 12, 2018 at 13:12:27 +0100, Michal Privoznik wrote:
> On 03/12/2018 10:04 AM, Peter Krempa wrote:
> > On Fri, Mar 09, 2018 at 12:56:13 +0100, Michal Privoznik wrote:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1552127
> >>
> >> These are bit different than other devices. Their alias also
> >> specify the name of the bus. For instance, if there are these
> >> 'joined' USB devices:
> >>
> >>   <controller type='usb' index='0' model='ich9-ehci1'>
> >>     <alias name='ua-myUSB'/>
> >>     <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x7'/>
> >>   </controller>
> >>   <controller type='usb' index='0' model='ich9-uhci1'>
> >>     <master startport='0'/>
> >>     <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0' multifunction='on'/>
> >>   </controller>
> >>
> >> which translates to cmd line as:
> >>
> >>   -device ich9-usb-ehci1,id=ua-myUSB,bus=pci.0,addr=0x4.0x7
> >>   -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4
> >>
> >> The problem is that UHCI is still trying to serve 'usb.0' bus.
> >> Rather than trying to come up with some complicated algorithm to
> >> make everything work, lets forbid user aliases for USB
> >> controllers.
> > 
> > I'm not a fan of this. This creates situations where the user is not
> > able to know which devices support user aliases and which don't. If
> > there isn't a technical problem preventing this from working we should
> > not forbid it.
> > 
> 
> Thing is I think we are facing technical problem. Let me give you an example:
> 
>   <controller type='usb' index='0' model='ich9-ehci1'>
>     <alias name='ua-myUSB1'/>
>     <address type='pci' domain='0' bus='0' slot='4' function='7'/>
>   </controller>
>   <controller type='usb' index='0' model='ich9-uhci1'>
>     <alias name='ua-myUSB2'/>
>     <master startport='0'/>
>     <address type='pci' domain='0' bus='0' slot='4' function='0' multifunction='on'/>
>   </controller>
>   <controller type='usb' index='0' model='ich9-uhci2'>
>     <alias name='ua-myUSB3'/>
>     <master startport='2'/>
>     <address type='pci' domain='0' bus='0' slot='4' function='1'/>
>   </controller>
>   <controller type='usb' index='0' model='ich9-uhci3'>
>     <alias name='ua-myUSB3'/>
>     <master startport='4'/>
>     <address type='pci' domain='0' bus='0' slot='4' function='2'/>
>   </controller>
> 
> What should the generated command line look like? To my knowledge, these
> ich9-XhciN devices are tricky and their id= attribute gives also name to
> the bus they are creating.

I don't have deep technical knowledge of how the USB sub-controllers
work, but allowing an user alias for the master controller should be
possible even now, only the code generating the commandline/alias for
the sub-controller needs to be fixed to use the proper one.

For the issue of using different alias for controllers which need to
have the same, you could forbid that configuration.

Another option would be to allow the same alias, but that would not be
really different from the situation where users need to know which
support duplicate aliases, so I'd not go that way.

Yet another option is to treat the alias of the sub-controllers as an
opaque string and use the proper master alias on the commandline. This
will turn the alias of the sub-controllers into a unused user-provided
identifier, but would not break the assumptions of unique aliases and
would allow the controllers to work properly.

Peter

P.S.: The best option would be not to pass the user alias on the
commandline at all and reat it opaque strings. But it's too late for
that.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180315/410d180b/attachment-0001.sig>