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

[Glauber Costa <glommer@gmail.com>]

On Wed, Apr 8, 2009 at 2:20 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> Glauber Costa wrote:
>> On Wed, Apr 8, 2009 at 2:02 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>> Glauber Costa wrote:
>>>> On Wed, Apr 8, 2009 at 1:34 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>> Glauber Costa wrote:
>>>>>> On Wed, Apr 8, 2009 at 10:12 AM, Anthony Liguori <anthony@codemonkey.ws> 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... ;)

You're not planning to use this opportunity to fill qemu code with
easter eggs, are you? ;-)


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

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