[Top][All Lists]

[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:02:38 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

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


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

reply via email to

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