Re: [Qemu-devel] Re: [PATCH 01/32] use anonymous memory for kqemu.

[Ben Taylor]

On Fri, Oct 24, 2008 at 3:30 PM, Andreas Färber <address@hidden> wrote:
>
> Am 23.10.2008 um 17:20 schrieb Leonardo Reiter:
>
>> On Thu, Oct 23, 2008 at 11:08 AM, Leonardo Reiter <address@hidden>
>> wrote:
>>>
>>> This should be tested well on Solaris 10, especially with -m values
>>> approaching 1GB and -kernel-kqemu.  The Solaris version would use /tmp
>>> rather than /dev/shm, but iirc there were problems when using
>>> MAP_ANONYMOUS.
>>>
>>> Also, on Linux, does anyone know what minimum kernel version is needed
>>> to not need the /dev/shm hack?
>>>
>> Please disregard the Solaris bit as the 1.4.0 version of KQEMU is not
>> widely available there yet, so you can't use the SVN version of QEMU
>> with KQEMU anyway AFAIK.  I'd be glad to look at this in the (somewhat
>> distant) future and come up with a patch if anonymous memory on
>> Solaris is not stable.
>
> OpenSolaris.org has a kqemu version that I've been happily using there with
> SVN. It supposedly supports Solaris 9 and 8, so by inference 10 as well, I'd
> hope.
> http://www.opensolaris.org/os/project/qemu/downloads/

There are currently two versions.  1.3.0pre11 works with Solaris 9, 10 and
SXCE.  8 should work, but there are differences in the calls used in kqemu
depending on which kernel version of Solaris you're running.  that will work
with any svn up to the introduction of the 1.4.0 kqemu module.

I also ported 1.4.0pre1, and Juergen Keil and a Sun engineer found a couple
of bugs that should be squashed now.

However, the big problem I see is that the addition of c99 features
borks a qemu compile on Solaris, specfically around stdbool.h.
Turning on -std=c99 or -std=gnuc99 creates more problems because
gcc-3.4.3 provided by solaris doesn't accept the anonymous unions
that are prevalent around the new code, specifically nbd and vnc.

> Last time I heard it wasn't merged upstream, so it would be good to check
> how well the Solaris (and FreeBSD?) kqemu variants work with this series.
> Maybe merge into the current codebase before making too much assumptions for
> the new accel interface?
>

I'll give it a whirl.

Ben