[Top][All Lists]

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

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

From: Glauber Costa
Subject: Re: [Qemu-devel] Re: start qemu failed with --enable-kvm -vga std
Date: Wed, 8 Apr 2009 14:23:48 -0300

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 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"

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

reply via email to

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