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

[Jan Kiszka <jan.kiszka@siemens.com>]

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

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.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux