On Thu, Jun 7, 2012 at 12:43 PM, Anthony Liguori <aligu...@us.ibm.com>wrote:

> On 06/07/2012 12:39 PM, li zhang wrote:
>
>> On Thu, Jun 7, 2012 at 9:15 AM, Anthony Liguori<aligu...@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'
>
> Got it.
Thanks.


> 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<zhlci...@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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 

Best Regards
-Li

Reply via email to