[Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Li Zhang]

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?

Any comment is appreciated.

Thanks. :)

-- 
Best Regards
Li

IBM LTC, China System&Technology Lab, Beijing

[Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[li zhang]

[-- Attachment #1: Type: text/plain, Size: 509 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 636 bytes --]

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[li zhang]

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]

Hi Anthony,

Any comment on this?

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

[-- Attachment #2: Type: text/html, Size: 1196 bytes --]

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Benjamin Herrenschmidt]

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.

-vga should only affect vga (a shortcut for -device
pick_your_vga_poison) 

-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).

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
> 
> 

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Anthony Liguori]

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.

>
> -vga should only affect vga (a shortcut for -device
> pick_your_vga_poison)

Ack.

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

I think it's over thinking it though.  There's little harm in having a usb 
controller present all the time.

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
>>
>>
>
>

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[li zhang]

[-- Attachment #1: Type: text/plain, Size: 2682 bytes --]

On Wed, Jun 6, 2012 at 1:42 PM, Anthony Liguori <aliguori@us.ibm.com> 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.
>
>
>
>> -vga should only affect vga (a shortcut for -device
>> pick_your_vga_poison)
>>
>
> Ack.
>
>
>
>> -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.
>

Thanks Anthony.
It's a better way to introduce one machine option.  :)


> I think it's over thinking it though.  There's little harm in having a usb
> controller present all the time.
>

 Got it.
 Thanks.


>
> 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
>>>
>>>
>>>
>>
>>
>


-- 

Best Regards
-Li

[-- Attachment #2: Type: text/html, Size: 4429 bytes --]

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Benjamin Herrenschmidt]

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.

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
> >>
> >>
> >
> >

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Andreas Färber]

Am 06.06.2012 05:31, schrieb Benjamin Herrenschmidt:
> On Wed, 2012-06-06 at 10:52 +0800, li zhang wrote:
[context: sPAPR]
> -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).
[...]
> 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).
[snip]

ppc64 mac99 should already do so, Alex once added code for that.
Compare hw/ppc_newworld.c.

Regards,
Andreas

P.S. It's not just an IBM topic, cc'ing ppc maintainer and list. ;)

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Anthony Liguori]

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.

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.

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
>>>>
>>>>
>>>
>>>
>
>

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Benjamin Herrenschmidt]

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
> >>>>
> >>>>
> >>>
> >>>
> >
> >

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Anthony Liguori]

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<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 ?

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<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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
>

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[li zhang]

[-- Attachment #1: Type: text/plain, Size: 6900 bytes --]

On Thu, Jun 7, 2012 at 9:15 AM, Anthony Liguori <aliguori@us.ibm.com> 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.
>>
>
> 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
>

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<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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>>
>


-- 

Best Regards
-Li

[-- Attachment #2: Type: text/html, Size: 9985 bytes --]

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Anthony Liguori]

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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
>

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[li zhang]

[-- Attachment #1: Type: text/plain, Size: 5212 bytes --]

On Thu, Jun 7, 2012 at 11:00 AM, Benjamin Herrenschmidt <benh@au1.ibm.com>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 <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.
>
> OK. I will do it.

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

I see.
Thanks.

>
> 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
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >
> > >
>
>
>


-- 

Best Regards
-Li

[-- Attachment #2: Type: text/html, Size: 7566 bytes --]

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[li zhang]

[-- Attachment #1: Type: text/plain, Size: 6374 bytes --]

On Thu, Jun 7, 2012 at 12:43 PM, Anthony Liguori <aliguori@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<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'
>
> 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<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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 

Best Regards
-Li

[-- Attachment #2: Type: text/html, Size: 9049 bytes --]

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Markus Armbruster]

Anthony Liguori <aliguori@us.ibm.com> writes:

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

Without -nodefaults, you get the machine the developers think most
people want.  Example: you may get a default serial device.  Whether you
get one and which one you get depends on the machine.

With -nodefaults, you get a variant of the same machine with those
optional devices omitted the developers think somebody might want to
suppress or define himself.

Both are "defined" the same way: you get what you get, and the
developers promise not to change it too much.

For some kinds of devices, there's magic to make user-defined devices
replace default devices.  Example: -serial and -device isa-serial
suppress the default serial device.

For some kinds of devices, there's a device-specific way to suppress
default devices.  Example: -serial none suppresses the default serial
device.  Counter-example: you can't suppress the default floppy
(frontend if the machine supports floppies, backend whether it does or
not) other than with -nodefaults.

The truly "poor" bit in -nodefaults is the name: I keep reading "node
faults" %-)

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

The USB host controller is currently disabled by default on all
machines.  If we enable it by default (which I think is a good idea), we
may want to give users a way to suppress it.

Your proposed -M parameter usb is yet another device-specific way to
suppress default devices.  We got a few, one more won't kill us.  Much
better would be adding a device-independent way to suppress a default
device.

Adding default USB suppression without having -nodefaults cover it is
something new, though: -nodefaults no longer omits optional devices "the
developers think somebody might want to suppress or define himself".
Feels like reneging on what -nodefaults promised to do.  I'd recommend
to think twice about that.

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Hans de Goede]

Hi,

Sorry for jumping in the middle of the thread, I missed the beginning
of this. Enabling USB by default, esp. emulating a USB mouse by default
is a *bad* idea. They way the periodic schedule of the various USB
controllers works means that emulating a USB device means a 1000 vm exits
per second extra, even when the vm is completely idle! USB powermanagement
can be used to negate this, but this is off in both Linux and Windows for
HID devices by default because there are too many broken HID devices.

Regards,

Hans

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Benjamin Herrenschmidt]

On Thu, 2012-06-07 at 10:32 +0200, Hans de Goede wrote:
> Hi,
> 
> Sorry for jumping in the middle of the thread, I missed the beginning
> of this. Enabling USB by default, esp. emulating a USB mouse by default
> is a *bad* idea. They way the periodic schedule of the various USB
> controllers works means that emulating a USB device means a 1000 vm exits
> per second extra, even when the vm is completely idle! USB powermanagement
> can be used to negate this, but this is off in both Linux and Windows for
> HID devices by default because there are too many broken HID devices.

On the other hand it is the only choice of input device on some
platforms such as pseries (and MacG5 when I get to make it work :-)

Would it be possible to "whitelist" the QEMU emulated HID devices
in the kernel to enable dynamic PM for them (at least when they sit
alone on the bus) ? Or is our emulation busted too ?

At least that would improve the situation in the long run...

Side note: It might be able to add an option at least to OHCI and EHCI
to relax a bit the correctness of the emulation and dramatically reduce
the number of exits.

One way to do that is to simply reduce the timer by a factor of 10 or
100 (and increment frame numbers in bulk). This could be reasonably
safely done when SOF interrupts aren't enabled, especially when only HID
devices are on the bus. We could alternatively schedule additional
arbitrary frames in between whenever a HID event is actually present.

Cheers,
Ben.

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Paolo Bonzini]

Il 07/06/2012 10:40, Benjamin Herrenschmidt ha scritto:
> On Thu, 2012-06-07 at 10:32 +0200, Hans de Goede wrote:
>> Hi,
>>
>> Sorry for jumping in the middle of the thread, I missed the beginning
>> of this. Enabling USB by default, esp. emulating a USB mouse by default
>> is a *bad* idea. They way the periodic schedule of the various USB
>> controllers works means that emulating a USB device means a 1000 vm exits
>> per second extra, even when the vm is completely idle! USB powermanagement
>> can be used to negate this, but this is off in both Linux and Windows for
>> HID devices by default because there are too many broken HID devices.
> 
> On the other hand it is the only choice of input device on some
> platforms such as pseries (and MacG5 when I get to make it work :-)
> 
> Would it be possible to "whitelist" the QEMU emulated HID devices
> in the kernel to enable dynamic PM for them (at least when they sit
> alone on the bus) ? Or is our emulation busted too ?

At least in Fedora they are; from /usr/lib/udev/rules.d/42-usb-hid-pm.rules:

ACTION=="add", SUBSYSTEM=="usb", ATTR{product}=="QEMU USB Mouse", ATTR{serial}=="42", TEST=="power/control", ATTR{power/control}="auto"
ACTION=="add", SUBSYSTEM=="usb", ATTR{product}=="QEMU USB Tablet", ATTR{serial}=="42", TEST=="power/control", ATTR{power/control}="auto"
ACTION=="add", SUBSYSTEM=="usb", ATTR{product}=="QEMU USB Keyboard", ATTR{serial}=="42", TEST=="power/control", ATTR{power/control}="auto"

Paolo

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Hans de Goede]

Hi,

On 06/07/2012 10:40 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2012-06-07 at 10:32 +0200, Hans de Goede wrote:
>> Hi,
>>
>> Sorry for jumping in the middle of the thread, I missed the beginning
>> of this. Enabling USB by default, esp. emulating a USB mouse by default
>> is a *bad* idea. They way the periodic schedule of the various USB
>> controllers works means that emulating a USB device means a 1000 vm exits
>> per second extra, even when the vm is completely idle! USB powermanagement
>> can be used to negate this, but this is off in both Linux and Windows for
>> HID devices by default because there are too many broken HID devices.
>
> On the other hand it is the only choice of input device on some
> platforms such as pseries (and MacG5 when I get to make it work :-)

Ok, then we can make it default on those platforms, but not everywhere?

> Would it be possible to "whitelist" the QEMU emulated HID devices
> in the kernel to enable dynamic PM for them (at least when they sit
> alone on the bus) ?

Yes, Linux already does this for the qemu usb tablet (not in the kernel
but with udev rules, but the result is the same), but this won't help
windows vms. IOW lets not have usb on by default on x86 please :)

> Or is our emulation busted too ?

No.

> At least that would improve the situation in the long run...
>
> Side note: It might be able to add an option at least to OHCI and EHCI
> to relax a bit the correctness of the emulation and dramatically reduce
> the number of exits.
>
> One way to do that is to simply reduce the timer by a factor of 10 or
> 100 (and increment frame numbers in bulk). This could be reasonably
> safely done when SOF interrupts aren't enabled, especially when only HID
> devices are on the bus. We could alternatively schedule additional
> arbitrary frames in between whenever a HID event is actually present.
>

We (me and Gerd Hoffmann) have investigated that, and experimented with it.
It will work for simply devices, but isochronous devices break. The real
solution at least for x86 vms is to get the XHCI emulation finished, as
the XHCI controller has a much nicer hw interface from an emulation pov,
and it can handle usb 1-3 devices.

Regards,

Hans

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Gerd Hoffmann]

  Hi,

> Would it be possible to "whitelist" the QEMU emulated HID devices
> in the kernel to enable dynamic PM for them (at least when they sit
> alone on the bus) ? Or is our emulation busted too ?

The emulation was fixed a while ago (IIRC 0.14+ works correctly).
upstream udev got rules to enable pm for (fixed) qemu hid devices.  So
with recent linux guests this shouldn't be an issue any more.  Older
linux distros and windows guests do still suffer without manual
invention though.

cheers,
  Gerd

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Gerd Hoffmann]

  Hi,

> We (me and Gerd Hoffmann) have investigated that, and experimented with it.
> It will work for simply devices, but isochronous devices break. The real
> solution at least for x86 vms is to get the XHCI emulation finished, as
> the XHCI controller has a much nicer hw interface from an emulation pov,
> and it can handle usb 1-3 devices.

xhci emulation (in qemu-1.1) is good enougth to handle usb-tablet, so
feel free to play with it today :)

cheers,
  Gerd

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Benjamin Herrenschmidt]

On Thu, 2012-06-07 at 10:52 +0200, Hans de Goede wrote:
> > At least that would improve the situation in the long run...
> >
> > Side note: It might be able to add an option at least to OHCI and EHCI
> > to relax a bit the correctness of the emulation and dramatically reduce
> > the number of exits.
> >
> > One way to do that is to simply reduce the timer by a factor of 10 or
> > 100 (and increment frame numbers in bulk). This could be reasonably
> > safely done when SOF interrupts aren't enabled, especially when only HID
> > devices are on the bus. We could alternatively schedule additional
> > arbitrary frames in between whenever a HID event is actually present.
> >
> 
> We (me and Gerd Hoffmann) have investigated that, and experimented with it.
> It will work for simply devices, but isochronous devices break. The real
> solution at least for x86 vms is to get the XHCI emulation finished, as
> the XHCI controller has a much nicer hw interface from an emulation pov,
> and it can handle usb 1-3 devices.

I absolutely agree, but it will take some time for xhci to trickle
(especially since most powerpc distros today don't have it guest side,
we only recently endian-fixed the driver).

In the meantime, this approach you experimented with would be very
useful for us  in the common case where there is no isochronous device.
It shouldn't be too hard for the emulator to switch back to "normal"
frames if an ISO EP is present, no ?

That would solve the 99% case of just keyboard and mouse on all those
machines.

Do you have some patches around from those earlier experiments that we
could try to revive, at least for OHCI ?

Cheers,
Ben.

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Benjamin Herrenschmidt]

On Thu, 2012-06-07 at 11:05 +0200, Gerd Hoffmann wrote:
> > We (me and Gerd Hoffmann) have investigated that, and experimented with it.
> > It will work for simply devices, but isochronous devices break. The real
> > solution at least for x86 vms is to get the XHCI emulation finished, as
> > the XHCI controller has a much nicer hw interface from an emulation pov,
> > and it can handle usb 1-3 devices.
> 
> xhci emulation (in qemu-1.1) is good enougth to handle usb-tablet, so
> feel free to play with it today :)

I don't think we've tried it on big-endian yet :-) Li, is that something
you team can have a look at (separately from these patches).

Cheers,
Ben.

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Anthony Liguori]

On 06/07/2012 04:07 PM, Markus Armbruster wrote:
> Anthony Liguori<aliguori@us.ibm.com>  writes:
>
>> 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.
>>
>> 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.
>
> Without -nodefaults, you get the machine the developers think most
> people want.  Example: you may get a default serial device.  Whether you
> get one and which one you get depends on the machine.
>
> With -nodefaults, you get a variant of the same machine with those
> optional devices omitted the developers think somebody might want to
> suppress or define himself.
>
> Both are "defined" the same way: you get what you get, and the
> developers promise not to change it too much.
>
> For some kinds of devices, there's magic to make user-defined devices
> replace default devices.  Example: -serial and -device isa-serial
> suppress the default serial device.
>
> For some kinds of devices, there's a device-specific way to suppress
> default devices.  Example: -serial none suppresses the default serial
> device.  Counter-example: you can't suppress the default floppy
> (frontend if the machine supports floppies, backend whether it does or
> not) other than with -nodefaults.
>
> The truly "poor" bit in -nodefaults is the name: I keep reading "node
> faults" %-)
>
>> 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.
>
> The USB host controller is currently disabled by default on all
> machines.  If we enable it by default (which I think is a good idea), we
> may want to give users a way to suppress it.
>
> Your proposed -M parameter usb is yet another device-specific way to
> suppress default devices.  We got a few, one more won't kill us.  Much
> better would be adding a device-independent way to suppress a default
> device.
>
> Adding default USB suppression without having -nodefaults cover it is
> something new, though: -nodefaults no longer omits optional devices "the
> developers think somebody might want to suppress or define himself".
> Feels like reneging on what -nodefaults promised to do.  I'd recommend
> to think twice about that.

I think we have a different world view.

I see 'qemu -machine foo' as creating some useful variant of 'foo' where 'foo' 
is a user visible concept like a PC, or a Beagle board, or a pSeries machine.

If I went to Fry's an bought a PC, I'd expect to plug it in and for it to have 
everything I needed including USB.  If I'm cheap, maybe I want to lower the 
amount of RAM or reuse the VGA card I bought for Christmas to play Halo 15 with.

I see machine options as a way to customize that PC.  Maybe I want to not 
include USB by default because I have some religious opposition to protocols 
that start with 'U'.

Machine configuration options are the QEMU equivalent of the drop-down box where 
you select options when buying a laptop from Dell.

'-nodefault' is like buying a PC out of a back of an unmarked van on a street 
corner.  God knows why it doesn't come with a serial port.  Maybe that got 
broken while it was being stolen during a break in.  Maybe it's got a VGA card 
but no disk controller because they sold the VGA card separately to make more money.

What libvirt really wants is to buy the *components* of a PC and build it from 
scratch.  They want to separately buy the mother board, the case, the graphics 
adapter, etc.  libvirt is the 16-year kid with pimples who spends Saturday night 
reading Newegg to find the new 750W power supply that's water cooled and tricked 
out with LEDs that I'm sure we all were at some point in our lives.

So I guess this is the long way of saying, let's not provide an interface from 
the back of an unmarked van.  Let's either provide a nice drop-down menu 
(-machine options) or provide a Newegg catalog that has every component in it.

Regards,

Anthony Liguori

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Li Zhang]

On 06/07/2012 05:17 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2012-06-07 at 11:05 +0200, Gerd Hoffmann wrote:
>>> We (me and Gerd Hoffmann) have investigated that, and experimented with it.
>>> It will work for simply devices, but isochronous devices break. The real
>>> solution at least for x86 vms is to get the XHCI emulation finished, as
>>> the XHCI controller has a much nicer hw interface from an emulation pov,
>>> and it can handle usb 1-3 devices.
>>
>> xhci emulation (in qemu-1.1) is good enougth to handle usb-tablet, so
>> feel free to play with it today :)
>
> I don't think we've tried it on big-endian yet :-) Li, is that something
> you team can have a look at (separately from these patches).
>
Sure, we can have a look at it. :)

> Cheers,
> Ben.
>
>


-- 
Best Regards
Li

IBM LTC, China System&Technology Lab, Beijing

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Hans de Goede]

Hi,

On 06/07/2012 11:16 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2012-06-07 at 10:52 +0200, Hans de Goede wrote:
>>> At least that would improve the situation in the long run...
>>>
>>> Side note: It might be able to add an option at least to OHCI and EHCI
>>> to relax a bit the correctness of the emulation and dramatically reduce
>>> the number of exits.
>>>
>>> One way to do that is to simply reduce the timer by a factor of 10 or
>>> 100 (and increment frame numbers in bulk). This could be reasonably
>>> safely done when SOF interrupts aren't enabled, especially when only HID
>>> devices are on the bus. We could alternatively schedule additional
>>> arbitrary frames in between whenever a HID event is actually present.
>>>
>>
>> We (me and Gerd Hoffmann) have investigated that, and experimented with it.
>> It will work for simply devices, but isochronous devices break. The real
>> solution at least for x86 vms is to get the XHCI emulation finished, as
>> the XHCI controller has a much nicer hw interface from an emulation pov,
>> and it can handle usb 1-3 devices.
>
> I absolutely agree, but it will take some time for xhci to trickle
> (especially since most powerpc distros today don't have it guest side,
> we only recently endian-fixed the driver).
>
> In the meantime, this approach you experimented with would be very
> useful for us  in the common case where there is no isochronous device.
> It shouldn't be too hard for the emulator to switch back to "normal"
> frames if an ISO EP is present, no ?

That should be possible yes. Note though that although slowing down the
timer will only break isoc. stuff, it will for example also slow down
usb mass storage devices.

> That would solve the 99% case of just keyboard and mouse on all those
> machines.
>
> Do you have some patches around from those earlier experiments that we
> could try to revive, at least for OHCI ?

No, I only did this for EHCI, which may still have an option to enable
this today. Gerd may have done this for UHCI too, Gerd ?

Regards,

Hans

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Markus Armbruster]

[cc: Dan to give him a chance to correct whatever underinformed nonsense
I might spout on libvirt]

Anthony Liguori <aliguori@us.ibm.com> writes:

> On 06/07/2012 04:07 PM, Markus Armbruster wrote:
>> Anthony Liguori<aliguori@us.ibm.com>  writes:
>>
>>> 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.
>>>
>>> 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.
>>
>> Without -nodefaults, you get the machine the developers think most
>> people want.  Example: you may get a default serial device.  Whether you
>> get one and which one you get depends on the machine.
>>
>> With -nodefaults, you get a variant of the same machine with those
>> optional devices omitted the developers think somebody might want to
>> suppress or define himself.
>>
>> Both are "defined" the same way: you get what you get, and the
>> developers promise not to change it too much.
>>
>> For some kinds of devices, there's magic to make user-defined devices
>> replace default devices.  Example: -serial and -device isa-serial
>> suppress the default serial device.
>>
>> For some kinds of devices, there's a device-specific way to suppress
>> default devices.  Example: -serial none suppresses the default serial
>> device.  Counter-example: you can't suppress the default floppy
>> (frontend if the machine supports floppies, backend whether it does or
>> not) other than with -nodefaults.
>>
>> The truly "poor" bit in -nodefaults is the name: I keep reading "node
>> faults" %-)
>>
>>> 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.
>>
>> The USB host controller is currently disabled by default on all
>> machines.  If we enable it by default (which I think is a good idea), we
>> may want to give users a way to suppress it.
>>
>> Your proposed -M parameter usb is yet another device-specific way to
>> suppress default devices.  We got a few, one more won't kill us.  Much
>> better would be adding a device-independent way to suppress a default
>> device.
>>
>> Adding default USB suppression without having -nodefaults cover it is
>> something new, though: -nodefaults no longer omits optional devices "the
>> developers think somebody might want to suppress or define himself".
>> Feels like reneging on what -nodefaults promised to do.  I'd recommend
>> to think twice about that.
>
> I think we have a different world view.
>
> I see 'qemu -machine foo' as creating some useful variant of 'foo'
> where 'foo' is a user visible concept like a PC, or a Beagle board, or
> a pSeries machine.
>
> If I went to Fry's an bought a PC, I'd expect to plug it in and for it
> to have everything I needed including USB.  If I'm cheap, maybe I want
> to lower the amount of RAM or reuse the VGA card I bought for
> Christmas to play Halo 15 with.
>
> I see machine options as a way to customize that PC.  Maybe I want to
> not include USB by default because I have some religious opposition to
> protocols that start with 'U'.
>
> Machine configuration options are the QEMU equivalent of the drop-down
> box where you select options when buying a laptop from Dell.
>
> '-nodefault' is like buying a PC out of a back of an unmarked van on a
> street corner.  God knows why it doesn't come with a serial port.
> Maybe that got broken while it was being stolen during a break in.
> Maybe it's got a VGA card but no disk controller because they sold the
> VGA card separately to make more money.

Entertaining imagery, but hardly a fair description of what -nodefaults
does.  -nodefaults is shorthand for "deselect everything in the drop
down box".  God knows why the drop down box has "disable serial port",
but it has.  God knows why the drop down box is so ugly and hard to use,
but it is.  Maybe we could happily do without the "deselect everything"
shorthand if the drop down box didn't suck so much, but it does.

> What libvirt really wants is to buy the *components* of a PC and build
> it from scratch.  They want to separately buy the mother board, the
> case, the graphics adapter, etc.  libvirt is the 16-year kid with
> pimples who spends Saturday night reading Newegg to find the new 750W
> power supply that's water cooled and tricked out with LEDs that I'm
> sure we all were at some point in our lives.

Again, entertaining imagery, but hardly a fair description of libvirt's
motivation.

Things libvirt really wants:

* Stable names.  Many default devices don't get any.  Yes, we can fix
  that.  Until we do, the only way to get names is to suppress default
  devices and define them yourself.

* Expose QEMU features to its users.  In particular, if a device is
  optional in QEMU, libvirt wants to be able to control its "enable"
  bit.  As it is, -nodefaults is the only way that works the same for
  all default devices, and for some of them it's the only way that works
  at all.

> So I guess this is the long way of saying, let's not provide an
> interface from the back of an unmarked van.  Let's either provide a
> nice drop-down menu (-machine options) or provide a Newegg catalog
> that has every component in it.

I doubt we're actually disagreeing on anything substantial.

I'm sure we can improve on -nodefaults.  But let's not break its core
feature "disable all default devices that can be disabled" before we
actually provide a working alternative that satisfies the needs of its
users.

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Benjamin Herrenschmidt]

On Thu, 2012-06-07 at 11:50 +0200, Hans de Goede wrote:
> > In the meantime, this approach you experimented with would be very
> > useful for us  in the common case where there is no isochronous device.
> > It shouldn't be too hard for the emulator to switch back to "normal"
> > frames if an ISO EP is present, no ?
> 
> That should be possible yes. Note though that although slowing down the
> timer will only break isoc. stuff, it will for example also slow down
> usb mass storage devices.

Sure, I was thinking about something a bit smarter that would "throttle"
the timer based on what kind of EPs have active TDs (that might imply a
delay reacting to a brand new TD but with a bit of smarts such as a
delay before throttling back, "completions" from sub-devices in qemu
triggering an immediate processing, etc... should be doable).

However...

> > That would solve the 99% case of just keyboard and mouse on all those
> > machines.
> >
> > Do you have some patches around from those earlier experiments that we
> > could try to revive, at least for OHCI ?
> 
> No, I only did this for EHCI, which may still have an option to enable
> this today. Gerd may have done this for UHCI too, Gerd ? 

Ok, what I really care about is OHCI, so at this point, it's basically
not there. So either I decide what Linux does today to enable PM is good
enough or I get my hands dirty :-)

We'll see, it's not an emergency at this stage, I might come up with
something if I get a chance.

Cheers,
Ben.

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Gerd Hoffmann]

  Hi,

>> In the meantime, this approach you experimented with would be very
>> useful for us  in the common case where there is no isochronous device.
>> It shouldn't be too hard for the emulator to switch back to "normal"
>> frames if an ISO EP is present, no ?
> 
> That should be possible yes. Note though that although slowing down the
> timer will only break isoc. stuff, it will for example also slow down
> usb mass storage devices.

Should depend on actual transfers, but yes.  ehci (with patches in
todays pull request) will reduce wakeup rate when there are no TDs in
the async schedule to process (and the periodic schedule is disabled).
As long as data is transfered ehci goes on at full wakeup rate (and speed).

The ehci async schedule was also moved to a bottom half so it can easily
kicked without a timer, for example from the packet completion callback.
 That doesn't eliminate the need for timers though as the guest can hook
in new TDs without ringing a doorbell, so we have to poll now and then
(this is one place where the xhci design is much more
virtualization-friendly, when queuing new requests the os must write to
a doorbell mmio register, so no need for a timer just to check for work).

periodic schedule is a bit trickier, but should be doable too.  There is
no urgent need though as the hid devices are 1.1 and thus not handled by
ehci anyway.

> No, I only did this for EHCI, which may still have an option to enable
> this today. Gerd may have done this for UHCI too, Gerd ?

Didn't, but should be possible.  Not sure how much it buys us as it
doesn't save any work for uhci, we can just batch the work (i.e. handle
10 frames at once), but at least the wakeup rate goes down which should
help a bit.

Enabling power management in the guest helps alot more as the guest will
completely suspend uhci when idle and there will be no polling and no
timer at all.

cheers,
  Gerd

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Anthony Liguori]

On 06/07/2012 06:05 PM, Markus Armbruster wrote:
> [cc: Dan to give him a chance to correct whatever underinformed nonsense
> I might spout on libvirt]

Don't see Dan on CC so I'll add him...


> Anthony Liguori<aliguori@us.ibm.com>  writes:
 >>
>> I think we have a different world view.
>>
>> I see 'qemu -machine foo' as creating some useful variant of 'foo'
>> where 'foo' is a user visible concept like a PC, or a Beagle board, or
>> a pSeries machine.
>>
>> If I went to Fry's an bought a PC, I'd expect to plug it in and for it
>> to have everything I needed including USB.  If I'm cheap, maybe I want
>> to lower the amount of RAM or reuse the VGA card I bought for
>> Christmas to play Halo 15 with.
>>
>> I see machine options as a way to customize that PC.  Maybe I want to
>> not include USB by default because I have some religious opposition to
>> protocols that start with 'U'.
>>
>> Machine configuration options are the QEMU equivalent of the drop-down
>> box where you select options when buying a laptop from Dell.
>>
>> '-nodefault' is like buying a PC out of a back of an unmarked van on a
>> street corner.  God knows why it doesn't come with a serial port.
>> Maybe that got broken while it was being stolen during a break in.
>> Maybe it's got a VGA card but no disk controller because they sold the
>> VGA card separately to make more money.
>
> Entertaining imagery, but hardly a fair description of what -nodefaults
> does.  -nodefaults is shorthand for "deselect everything in the drop
> down box".  God knows why the drop down box has "disable serial port",
> but it has.  God knows why the drop down box is so ugly and hard to use,
> but it is.  Maybe we could happily do without the "deselect everything"
> shorthand if the drop down box didn't suck so much, but it does.
>
>> What libvirt really wants is to buy the *components* of a PC and build
>> it from scratch.  They want to separately buy the mother board, the
>> case, the graphics adapter, etc.  libvirt is the 16-year kid with
>> pimples who spends Saturday night reading Newegg to find the new 750W
>> power supply that's water cooled and tricked out with LEDs that I'm
>> sure we all were at some point in our lives.
>
> Again, entertaining imagery, but hardly a fair description of libvirt's
> motivation.
>
> Things libvirt really wants:
>
> * Stable names.  Many default devices don't get any.  Yes, we can fix
>    that.  Until we do, the only way to get names is to suppress default
>    devices and define them yourself.
>
> * Expose QEMU features to its users.  In particular, if a device is
>    optional in QEMU, libvirt wants to be able to control its "enable"
>    bit.  As it is, -nodefaults is the only way that works the same for
>    all default devices, and for some of them it's the only way that works
>    at all.

I'll resist the urge to extend the analogy and just keep it simple.

-machine is an objectively better interface for achieving the above.  Here's why:

1) There is no way to determine when the semantics of -nodefault changes and no 
clear compatibility statement.

  a) Would it be okay to make -nodefault suppress the the IDE controller for -M 
pc at this point in time?

  b) Would it be okay to add USB by default and make -nodefault disable it?

  c) How does libvirt figure out when any of the above happens?

2) There is no way to figure out what -nodefault does without deep code 
inspection since it depends on each machine.

3) -machine is both discoverable (you can see when new options are added), but 
also has the ability to support compatibility.  If we decide to add usb by 
default, libvirt can see that 'usb' has been added and disable it.  If we decide 
to make the IDE device hide-able, we can add an 'ide' option and default it to True.

4) The -machine option supports sane backporting.  Since you can discover 
individual features of -machine, libvirt can deal with any combination of 
features being available.

We didn't have -machine when -nodefaults was introduces.  Now that we do, we 
should make good use of it.

Regards,

Anthony Liguori

>
>> So I guess this is the long way of saying, let's not provide an
>> interface from the back of an unmarked van.  Let's either provide a
>> nice drop-down menu (-machine options) or provide a Newegg catalog
>> that has every component in it.
>
> I doubt we're actually disagreeing on anything substantial.
>
> I'm sure we can improve on -nodefaults.  But let's not break its core
> feature "disable all default devices that can be disabled" before we
> actually provide a working alternative that satisfies the needs of its
> users.
>

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

[Markus Armbruster]

Anthony Liguori <anthony@codemonkey.ws> writes:

> On 06/07/2012 06:05 PM, Markus Armbruster wrote:
>> [cc: Dan to give him a chance to correct whatever underinformed nonsense
>> I might spout on libvirt]
>
> Don't see Dan on CC so I'll add him...
>
>
>> Anthony Liguori<aliguori@us.ibm.com>  writes:
>>>
>>> I think we have a different world view.
>>>
>>> I see 'qemu -machine foo' as creating some useful variant of 'foo'
>>> where 'foo' is a user visible concept like a PC, or a Beagle board, or
>>> a pSeries machine.
>>>
>>> If I went to Fry's an bought a PC, I'd expect to plug it in and for it
>>> to have everything I needed including USB.  If I'm cheap, maybe I want
>>> to lower the amount of RAM or reuse the VGA card I bought for
>>> Christmas to play Halo 15 with.
>>>
>>> I see machine options as a way to customize that PC.  Maybe I want to
>>> not include USB by default because I have some religious opposition to
>>> protocols that start with 'U'.
>>>
>>> Machine configuration options are the QEMU equivalent of the drop-down
>>> box where you select options when buying a laptop from Dell.
>>>
>>> '-nodefault' is like buying a PC out of a back of an unmarked van on a
>>> street corner.  God knows why it doesn't come with a serial port.
>>> Maybe that got broken while it was being stolen during a break in.
>>> Maybe it's got a VGA card but no disk controller because they sold the
>>> VGA card separately to make more money.
>>
>> Entertaining imagery, but hardly a fair description of what -nodefaults
>> does.  -nodefaults is shorthand for "deselect everything in the drop
>> down box".  God knows why the drop down box has "disable serial port",
>> but it has.  God knows why the drop down box is so ugly and hard to use,
>> but it is.  Maybe we could happily do without the "deselect everything"
>> shorthand if the drop down box didn't suck so much, but it does.
>>
>>> What libvirt really wants is to buy the *components* of a PC and build
>>> it from scratch.  They want to separately buy the mother board, the
>>> case, the graphics adapter, etc.  libvirt is the 16-year kid with
>>> pimples who spends Saturday night reading Newegg to find the new 750W
>>> power supply that's water cooled and tricked out with LEDs that I'm
>>> sure we all were at some point in our lives.
>>
>> Again, entertaining imagery, but hardly a fair description of libvirt's
>> motivation.
>>
>> Things libvirt really wants:
>>
>> * Stable names.  Many default devices don't get any.  Yes, we can fix
>>    that.  Until we do, the only way to get names is to suppress default
>>    devices and define them yourself.
>>
>> * Expose QEMU features to its users.  In particular, if a device is
>>    optional in QEMU, libvirt wants to be able to control its "enable"
>>    bit.  As it is, -nodefaults is the only way that works the same for
>>    all default devices, and for some of them it's the only way that works
>>    at all.
>
> I'll resist the urge to extend the analogy and just keep it simple.
>
> -machine is an objectively better interface for achieving the above.  Here's why:

Note that I'm not arguing against -machine at all.  Only against
breaking -nodefault before its replacement is fully ready.

> 1) There is no way to determine when the semantics of -nodefault
> changes and no clear compatibility statement.
>
>  a) Would it be okay to make -nodefault suppress the the IDE
> controller for -M 
> pc at this point in time?

Incompatible change, thus requires a new machine type.

Since pc is just an alias for the latest pc-X.Y, one could argue that
users of pc need to be prepared for incompatible changes when pc points
to a new pc-X.Y, and therefore we could make the change in a new pc-X.Y.
I'd think twice about that.  At least.

>  b) Would it be okay to add USB by default and make -nodefault disable it?

Same thing: new machine type.

>  c) How does libvirt figure out when any of the above happens?

It uses the machine types it knows, and gets updated for new machine
types.  Best it can do given what we offer it now.

> 2) There is no way to figure out what -nodefault does without deep
> code inspection since it depends on each machine.

Could be regarded as a documentation bug.

Other command line options have similar, although less serious issues.
For instance, -serial can

* replace the machine's default serial device, or

* add a new serial device (exact type depends on machine), or

* do nothing at all

depending on the machine.  Code inspection or experiment required to
figure it out.

That said, I'm all for simple options with documented or easily
discoverable semantics.

> 3) -machine is both discoverable (you can see when new options are
> added), but also has the ability to support compatibility.  If we
> decide to add usb by default, libvirt can see that 'usb' has been
> added and disable it.  If we decide to make the IDE device hide-able,
> we can add an 'ide' option and default it to True.

How should libvirt decide that the new and unknown option "usb" needs to
be disabled for backward compatibility, but the equally new and unknown
option "ide" needs to be left enabled?

> 4) The -machine option supports sane backporting.  Since you can
> discover individual features of -machine, libvirt can deal with any
> combination of features being available.
>
> We didn't have -machine when -nodefaults was introduces.  Now that we
> do, we should make good use of it.

Once again, that I'm not arguing against -machine at all.  Only against
breaking -nodefault before its replacement is fully ready.

> Regards,
>
> Anthony Liguori
>
>>
>>> So I guess this is the long way of saying, let's not provide an
>>> interface from the back of an unmarked van.  Let's either provide a
>>> nice drop-down menu (-machine options) or provide a Newegg catalog
>>> that has every component in it.
>>
>> I doubt we're actually disagreeing on anything substantial.
>>
>> I'm sure we can improve on -nodefaults.  But let's not break its core
>> feature "disable all default devices that can be disabled" before we
>> actually provide a working alternative that satisfies the needs of its
>> users.