From: Anthony Liguori <aliguori@us.ibm.com>
To: li zhang <zhlcindy@gmail.com>
Cc: Benjamin Herrenschmidt <benh@au1.ibm.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 12:43:19 +0800 [thread overview]
Message-ID: <4FD03167.30906@us.ibm.com> (raw)
In-Reply-To: <CAD8of+qQ0-ZpbBTmk_swYF1zEgWE_yf0ECdqFLf0bSitg_dnQg@mail.gmail.com>
On 06/07/2012 12:39 PM, li zhang wrote:
> On Thu, Jun 7, 2012 at 9:15 AM, Anthony Liguori<aliguori@us.ibm.com> wrote:
>
> Hi Anthony,
>
> I think we can add usb to machine option, and set usb on as default in
> qemu, right?
> Does it conflict with "-device pci-ohci" ?
libvirt would want to pass '-machine type=pseries,usb=off' instead of passing
'-M pseries'.
It could then use '-device pci-ohci'
Regards,
Anthony Liguori
>
> Libvirt will parse a xmlfile to qemu commands with -nodefault
> configuration.
>
> For example:
> /home/zhlbj/development/qemu-impreza/ppc64-softmmu/qemu-system-ppc64 -M
> pseries -enable-kvm -m 1024 -mem-prealloc -mem-path
> /dev/hugepages/libvirt/qemu -smp 2,sockets=2,cores=1,threads=1 -name $1
> -nodefconfig -nodefaults -chardev
> socket,id=charmonitor,path=/usr/local/var/lib/libvirt/qemu/$1.monitor,server,nowait
> -mon chardev=charmonitor,id=monitor,mode=readline -rtc base=utc -device
> spapr-vscsi,id=scsi0 -drive
> file=/home/zhlbj/kvm-test/fedora.img,if=none,id=drive-scsi0-0-0,format=raw
> -device
> scsi-disk,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0,bootindex=1
> -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0 -device
> pci-ohci,id=usb,bus=pci,addr=0x1.0x2 -vnc 127.0.0.1:12 -vga std -device
> virtio-balloon-pci,id=balloon0,bus=pci,addr=0x3
>
> I think we still need to use "-device " option to add usb controller for
> configuring specific usb model.
>
>
>
>> libvirt can still happily name the usb controller whatever it wants. But
>> the end result is a less magical command line.
>>
>> 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.
>>>
>>
> Yes, this problem is that: when the usb_enable is set as 1, it will create
> one pci-ohci controller.
> When the command is using "-device pci-ohci", it will create another
> pci-ohci controller.
> And one error occurs. I traced the code, it shows that there two places to
> call
> pci_create_multifunction(bus, devfn, bool, "pci-ohci").
>
> One place is in the spapr.c, it means that when vga is enabled, usb_enable
> is set 1.
> it will create one pci-ohci controller.
> Another place is in the vl.c,
> if (qemu_opts_foreach(qemu_find_opts("device"), device_help_func, NULL, 0)
> != 0)
> It will create another pci-ohci controller according to "-device pci-ohci"
> option.
> It seems that usb_enable variable setting and "-device pci-ohci" option
> conflict.
> It can't detect the existing pci-ohci controller.
>
>
>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
>
next prev parent reply other threads:[~2012-06-07 4:44 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
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 [this message]
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=4FD03167.30906@us.ibm.com \
--to=aliguori@us.ibm.com \
--cc=benh@au1.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.