On Thu, Jun 7, 2012 at 9:15 AM, Anthony Liguori
<address@hidden> wrote:
On 06/07/2012 05:13 AM, Benjamin Herrenschmidt wrote:
On Wed, 2012-06-06 at 13:42 +0800, Anthony Liguori wrote:
On 06/06/2012 11:31 AM, Benjamin Herrenschmidt wrote:
On Wed, 2012-06-06 at 10:52 +0800, li zhang wrote:
Hi Anthony,
Any comment on this?
Allright, this is all quite confusing...
He's what I think should happen:
When no option is passed -at-all-, we should have vga std and usb ohci +
usb mouse + usb ps2.
When -nodefault is passed, we should have none of the above.
-nodefault is a pretty ugly hack. I don't think there's any good reason to
involve -nodefault into this discussion.
Well, it's pretty fundamental to how libvirt does thing afaik...
Take pseries, by "default" today it has a vscsi, a vterm etc.... but
with -nodefault, none of this so libvirt can create them manually.
-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
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 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<address@hidden> 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