qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan Kiszka
Subject: [Qemu-devel] Re: start qemu failed with --enable-kvm -vga std
Date: Wed, 08 Apr 2009 19:20:56 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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.

Jan

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]