Re: [Qemu-devel] Illumos/SmarOS support

[Stefan Hajnoczi]

On Thu, Mar 15, 2012 at 12:39 PM,  <address@hidden> wrote:
>> On 15/03/2012 11:56, Stefan Hajnoczi wrote:
>> I think what you are trying to do makes sense - IllumOS as a host OS
>> and QEMU platform should be actively involved in the upstream QEMU
>> community.  But you may want to first check the Joyent port to see
>> what can easily be upstreamed and also try talking with them if you
>> haven't already.  I'm not sure why things aren't being pushed upstream
>> but perhaps the process can be started.
>
>
> Yes, and (other than my Linux issue) it's working well.
>
> The changes needed to get it working are pretty minimal, most of them are
> #ifdef's around KVM_CAP's that are assumed to be defined (at least in some
> of the code.)
>
> The specific code changes boil down to:
> - a different mechanism for creating a vcpu filehandle (which is cloned from
> /dev/kvm rather than the return code of KVM_CREATE_VCPU)
> - some of the kvm ioctls using different filehandles.
> - the requirement to lock guest memory
> - a KVM_EXIT_INTR case with ret=0 from the ioctl (exernal interrupt)
>
> ... which amounts to probably less than 50 lines of changes, and again the
> code structure is pretty different to their port, so I think it's easier to
> apply new rather than push upstream.
>
> I would have thought that applying this (minimal) stuff to the qemu.git tree
> and using that for illumos would remove the need for a specific joyent
> version, and hence be a good thing.
>
> The joyent guys are very focused (understandably) on their specific needs,
> however if someone else is prepared to do the work they do seem pretty
> willing to adopt it.

Okay, that's important because doing a porting/upstreaming effort like
this also has a big human or political element.  If they are
supportive then it's more likely everyone involved will end up with a
qemu.git tree they like and can use.

My main concern with the KVM functionality is that Joyent is leading
the kernel side and you are leading the upstream qemu.git side - this
means there needs to be collaboration.  Perhaps you can CC your
qemu-devel patches to an illumos/joyent mailing list so that it's
always clear where you're headed.  That way, folks experienced with
the IllumOS KVM kernel interface can review and give advice.  The
scenario to avoid would be for upstream qemu.git to have IllumOS
support merged but it breaks because the KVM kernel side goes in a
different direction.

Anway, your plan to get patches upstream sounds good to me.

Stefan