Re: [PATCH] Support for QEMU's CVS

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Anthony Liguori wrote:
> Avi Kivity wrote:
>> There are four issues I can see:
>>
>> - if there are multiple sources of kvm userspace, there are bound to 
>> be problems with incompatible kernel API and userspace, especially as 
>> I have plans for extensive changes to the API.  I'll go and implement 
>> a version check now, so that doesn't become a barrier to anything.  A 
>> submission to qemu-devel should include this check.
>
> With KQEMU, you have to pair a version of KQEMU with the appropriate 
> version of QEMU.  I don't think there's much of a problem doing 
> something like this for KVM for the short term until API gets more 
> stable (provided there's a version check so the error is useful to the 
> user).
>

The version check is now in.

>
>>> diff -r 2eac80033ea0 hw/usb-hid.c
>>> --- a/hw/usb-hid.c    Tue Dec 19 09:31:34 2006 +0000
>>> +++ b/hw/usb-hid.c    Wed Dec 20 23:01:25 2006 -0600
>>> @@ -169,7 +169,9 @@ static const uint8_t qemu_tablet_config_
>>>      0x81,       /*  u8  ep_bEndpointAddress; IN Endpoint 1 */
>>>       0x03,       /*  u8  ep_bmAttributes; Interrupt */
>>>       0x08, 0x00, /*  u16 ep_wMaxPacketSize; */
>>> -    0x03,       /*  u8  ep_bInterval; (255ms -- usb 2.0 spec) */
>>> +    /* Temporarily increase usb polling interval to prevent cpu
>>> +     * saturation (3 ms is way too often for kvm) */
>>> +    0x33,       /*  u8  ep_bInterval; (255ms -- usb 2.0 spec) */
>>>   
>>
>> This might be a good change for qemu, but on the other hand this is a 
>> kvm deficiency that is forced on non-kvm users.
>
> Brad Campbell (who wrote the original HID description) has recently 
> posted a patch that changes the interval to 0x20.  0x03 was causing a 
> performance problems with Windows guests (there's a pretty recent 
> thread on qemu-devel about it).
>
> How did you arrive at 0x33 btw?  IIRC, Brad stopped at 0x20 as he saw 
> no performance improvement beyond it.  If KVM needs at least 0x33 then 
> provided there is no negative impact to QEMU I don't really see a 
> problem with it.

It's just a random number, the first I tried. 0x20 would probably work 
just as well (30 interrupts/sec)

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV