Re: [Qemu-devel] Re: start qemu failed with --enable-kvm -vga std

[Glauber Costa]

On Wed, Apr 8, 2009 at 2:20 PM, Jan Kiszka <address@hidden> wrote:
> Glauber Costa wrote:
>> On Wed, Apr 8, 2009 at 2:02 PM, Jan Kiszka <address@hidden> wrote:
>>> Glauber Costa wrote:
>>>> On Wed, Apr 8, 2009 at 1:34 PM, Jan Kiszka <address@hidden> wrote:
>>>>> Glauber Costa wrote:
>>>>>> On Wed, Apr 8, 2009 at 10:12 AM, Anthony Liguori <address@hidden> wrote:
>>>>>>> Peng Huang wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> The HEAD version qemu can not execute a VM with --enable-kvm -vga std 
>>>>>>>> or
>>>>>>>> -vga vmware on kernel 2.6.29.1-46.fc11.x86_64. I found it is because 
>>>>>>>> of qemu
>>>>>>>> call cpu_register_physical_memory with a wrong size. Below patch can 
>>>>>>>> fix it
>>>>>>>> on my box. Please test it.
>>>>>>> Glauber came up with a similar patch for kvm-userspace and is currently
>>>>>>> attempting to root cause the issue.
>>>>>> I believe this is in fact the root cause. KVM slot management code
>>>>>> probably require
>>>>>> memory to be page aligned. By trying to register a region that is not
>>>>>> page aligned,
>>>>>> the ioctl may fail. I, however, did not see this happening in qemu
>>>>>> upstream (only kvm-userspace),
>>>>>> and have absolutely no idea about why. But the patch makes perfect sense 
>>>>>> to me.
>>>>>>
>>>>> But this really sounds like a limitation that should better be fixed in
>>>>> the kvm layer, not the device/machine code.
>>>>>
>>>>> We only map ROM regions here. So rounding them up/down and sending
>>>>> properly aligned requests to the kernel should finally have the same
>>>>> result for all involved pages. Only if non-compatible regions overlap
>>>>> due to such roundings, we should bail out - and start to consider
>>>>> changing device code.
>>>> I've considered this, but then the alignment constraints become implicit,
>>>> rather than explicit. Consider the option rom registration code itself.
>>>>
>>>> We should start loading option roms right after vga. If kvm layer
>>> Unless I misread something, this is about option ROMs after VGA ROM.
>>>
>>>> aligns the region
>>>> implicitly, then where will option roms start? At better, we would have to 
>>>> tell
>>>> qemu back that such an alignment were made, to start looking for option
>>>> roms in the right place.
>>>>
>>> My ideas is to merge both ROM regions (given we are actually talking
>>> about compatible stuff here): the 2k VGA ROM would first be expanded to
>>> 4k, then the next option ROM starting after the VGA would extend the
>>> latter. But that's plain theory so far.
>>>
>>>> I believe being explicit, and requiring page alignment is safer, and
>>>> does not hurt.
>>> In this case, we would waste 2k of (sometimes) precious low mem...
>>>
>>
>> If we can merge the regions, then I agree with you. We'll probably have an
>> alignment requirement anyway, but it can well be handled in kvm layer.
>>
>> However, as you ack yourself, it is likely to take some time. In the mean 
>> time,
>> I believe this fix is acceptable. Unless you're planning on having something
>> to fix it in the next few days.
>
> Easter is coming - if I find my eggs quickly, there might be some time
> left... ;)
>
> I leave the decision up to the maintainers if we should merge this
> workaround first, or wait a bit longer until we know for sure if we can
> fix it in a cleaner way.
In all seriousness, no matter how good your series for improving kvm
registration
are, it is unlikely to hit the stable branch. So I believe a good deal
would have something
on the line of this patch applied to stable, leaving unstable as is,
until we can find a better
solution.

What do you think, anthony?


-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."