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 disa
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 disab
Hi Anthony,
Any comment on this?
Thanks.
On Tue, Jun 5, 2012 at 5:48 PM, li zhang 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 defau
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 m
On Wed, Jun 6, 2012 at 1:42 PM, 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 sho
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 sh
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 sh
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
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...
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 situati
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
On Thu, Jun 7, 2012 at 9:15 AM, Anthony Liguori 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:
>>
On 06/07/2012 12:39 PM, li zhang wrote:
On Thu, Jun 7, 2012 at 9:15 AM, Anthony Liguori 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'
On Thu, Jun 7, 2012 at 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 tho
On Thu, Jun 7, 2012 at 12:43 PM, Anthony Liguori wrote:
> On 06/07/2012 12:39 PM, li zhang wrote:
>
>> On Thu, Jun 7, 2012 at 9:15 AM, Anthony Liguori
>> 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
Anthony Liguori 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 co
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
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
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 wa
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 peri
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 enabl
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 emula
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
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 XH
On 06/07/2012 04:07 PM, Markus Armbruster wrote:
Anthony Liguori 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:
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 g
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
[cc: Dan to give him a chance to correct whatever underinformed nonsense
I might spout on libvirt]
Anthony Liguori writes:
> On 06/07/2012 04:07 PM, Markus Armbruster wrote:
>> Anthony Liguori writes:
>>
>>> On 06/07/2012 05:13 AM, Benjamin Herrenschmidt wrote:
On Wed, 2012-06-06 at 13:42
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
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. N
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 writes:
>>
I think we have a different world view.
I see 'qemu -machine foo' as creat
Anthony Liguori 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 writes:
>>>
>>> I think we have a different world
32 matches
Mail list logo
