From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36825) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScT1B-0001RU-RP for qemu-devel@nongnu.org; Wed, 06 Jun 2012 23:04:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ScT19-0003Ii-MR for qemu-devel@nongnu.org; Wed, 06 Jun 2012 23:04:13 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:50257) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScT19-0003IP-D4 for qemu-devel@nongnu.org; Wed, 06 Jun 2012 23:04:11 -0400 Received: by dadv2 with SMTP id v2so233886dad.4 for ; Wed, 06 Jun 2012 20:04:09 -0700 (PDT) Message-ID: <4FD01A1F.90108@codemonkey.ws> Date: Thu, 07 Jun 2012 11:03:59 +0800 From: Anthony Liguori MIME-Version: 1.0 References: <1338953515.7150.150.camel@pasglop> <4FCEEDC5.7090807@us.ibm.com> <1339017219.7150.170.camel@pasglop> <4FD000B6.8060308@us.ibm.com> <1339038020.24838.6.camel@pasglop> In-Reply-To: <1339038020.24838.6.camel@pasglop> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: li zhang , qemu-devel@nongnu.org, zhlcindy@linux.vnet.ibm.com On 06/07/2012 11:00 AM, Benjamin Herrenschmidt wrote: > On Thu, 2012-06-07 at 09:15 +0800, Anthony Liguori wrote: > >> You misunderstand what I'm saying. >> >> -nodefault is a dumb option. It's semantics are poorly defined because it >> depends on machine. Further complicating those semantics by adding more magic >> for -M spapr just makes the situation worse. >> >> I'm suggesting to make use of the -machine option to allow usb to be disabled. So: >> >> qemu-system-ppc64 -machine type=spapr,usb=off >> >> libvirt can still happily name the usb controller whatever it wants. But the >> end result is a less magical command line. > > Allright, what I was missing is -machine option with arguments, I only > knew about -M :-) > > That definitely sounds like the right way to go. However, I do wonder to > what extent we should still also support -nodefault because that's what > libvirt does today or we just don't give a shit ? Well -nodefault will already suppress a bunch of things but you don't have to worry about -nodefault being the mechanism to suppress everything. Regards, Anthony Liguori > Li, can you do something along the lines of what Anthony described ? By > default, you should have -vga std and usb OHCI with mouse and keyboard. > > Feel free to replace the patches I currently have in our internal tree > for enabling -vga etc... and post the result publicly, however, please > note in the comments that for that stuff to work, there's a dependency > on the iommu patch series. > > Cheers, > Ben. > >> Regards, >> >> Anthony Liguori >> >>> >>> The problem is that for things created "by default", libvirt then makes >>> horrible assumptions about the default 'names' and bus names as well, >>> which is why it's generally somewhat saner to let it create the machine >>> from scratch (well, sorry for putting "sane" and "libvirt" in the same >>> sentence but you get my idea I think :-) >>> >>>>> -vga should only affect vga (a shortcut for -device >>>>> pick_your_vga_poison) >>>> >>>> Ack. >>> >>> (Note: This is in reference to our current internal patch which >>> automagically adds OHCI and USB kbd + mouse when you do -vga, that's not >>> something that should survive upstream). >>> >>>>> -usb should be essentially useless by default unless -nodefault is >>>>> passed in which case it is necessary to enable usb support, and -device >>>>> (or equivalent) to manually add the keyboard and mouse (libvirt). >>>> >>>> If you want pseries to always have usb, just make it there by default and yeah, >>>> -usb would be useless. If you want the option to not have usb, introduce a >>>> machine option I guess. >>> >>> Ah, I'm not familiar with "machine options" ... or do you mean another >>> machine type ? ie -M pseries_nousb ? :-) >>> >>> The problem with things like USB by default is that libvirt will fuckup >>> (at least that's my understanding from what Li says) bcs it's going to >>> try to create a separate USB bus and can't seem to figure out how to >>> reference the existing one, etc... In fact it even tries to re-use the >>> PCI bus/dev where the original OHCI is created an that clashes. >>> >>>> I think it's over thinking it though. There's little harm in having a usb >>>> controller present all the time. >>> >>> That makes more sense I agree, I'm just annoyed by the whole libvirt >>> business which seems to have some pretty hard assumptions that with >>> -nodefault you don't get anything by default, and I think it makes some >>> sense to keep that option around. >>> >>> Cheers, >>> Ben. >>> >>>> Regards, >>>> >>>> Anthony Liguori >>>> >>>>> >>>>> That's the best I can think of ... however it might be a bit tricky >>>>> seeing how qemu does things in vl.c at the moment, we might want to >>>>> introduce a default_usb variable which is used to set usb_enabled. >>>>> >>>>> BTW. The mac models should essentially behave the same, at least the >>>>> 64-bit one (32-bit supports CUDA for keyboard/mouse so USB isn't >>>>> strictly necessary). >>>>> >>>>> Cheers, >>>>> Ben. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> On Tue, Jun 5, 2012 at 5:48 PM, li zhang wrote: >>>>>> Hi all, >>>>>> >>>>>> For pseries, when creating VMs with "-vga std", >>>>>> it requires usb mouse and usb kbd devices to be added. >>>>>> >>>>>> But with default options, vga is enabled and usb is disabled. >>>>>> User may use default options as the following commands: >>>>>> >>>>>> $qemu -M pseries >>>>>> >>>>>> If vga is enabled, usb mouse and usb kbd is disabled, >>>>>> the mouse and kbd can't be used. So it's very hard for >>>>>> users to use. >>>>>> >>>>>> I think it's necessary to enable usb with default options. >>>>>> >>>>>> Any idea about that? >>>>>> Your comments are very appreciated. :) >>>>>> >>>>>> Thanks. >>>>>> -Li >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> Best Regards >>>>>> -Li >>>>>> >>>>>> >>>>> >>>>> >>> >>> > > >