All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@au1.ibm.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: li zhang <zhlcindy@gmail.com>,
	qemu-devel@nongnu.org, zhlcindy@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options
Date: Thu, 07 Jun 2012 13:00:20 +1000	[thread overview]
Message-ID: <1339038020.24838.6.camel@pasglop> (raw)
In-Reply-To: <4FD000B6.8060308@us.ibm.com>

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 <name> :-)
 
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 ?

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<zhlcindy@gmail.com>   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
> >>>>
> >>>>
> >>>
> >>>
> >
> >

  reply	other threads:[~2012-06-07  3:00 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-05  9:48 [Qemu-devel] [qemu-devel][RFC] Enable usb with default options li zhang
2012-06-06  2:52 ` li zhang
2012-06-06  3:31   ` Benjamin Herrenschmidt
2012-06-06  5:42     ` Anthony Liguori
2012-06-06  6:03       ` li zhang
2012-06-06 21:13       ` Benjamin Herrenschmidt
2012-06-07  1:15         ` Anthony Liguori
2012-06-07  3:00           ` Benjamin Herrenschmidt [this message]
2012-06-07  3:03             ` Anthony Liguori
2012-06-07  4:52             ` li zhang
2012-06-07  4:39           ` li zhang
2012-06-07  4:43             ` Anthony Liguori
2012-06-07  4:53               ` li zhang
2012-06-07  8:07           ` Markus Armbruster
2012-06-07  9:19             ` Anthony Liguori
2012-06-07 10:05               ` Markus Armbruster
2012-06-07 11:51                 ` Anthony Liguori
2012-06-12  8:06                   ` Markus Armbruster
2012-06-07  8:32         ` Hans de Goede
2012-06-07  8:40           ` Benjamin Herrenschmidt
2012-06-07  8:49             ` Paolo Bonzini
2012-06-07  8:52             ` Hans de Goede
2012-06-07  9:05               ` Gerd Hoffmann
2012-06-07  9:17                 ` Benjamin Herrenschmidt
2012-06-07  9:29                   ` Li Zhang
2012-06-07  9:16               ` Benjamin Herrenschmidt
2012-06-07  9:50                 ` Hans de Goede
2012-06-07 11:19                   ` Benjamin Herrenschmidt
2012-06-07 11:35                   ` Gerd Hoffmann
2012-06-07  8:54             ` Gerd Hoffmann
2012-06-06 22:14     ` Andreas Färber
  -- strict thread matches above, loose matches on Subject: below --
2012-06-05  7:19 Li Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1339038020.24838.6.camel@pasglop \
    --to=benh@au1.ibm.com \
    --cc=aliguori@us.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=zhlcindy@gmail.com \
    --cc=zhlcindy@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.