Resend from different email -- not sure what happened = to my first 2 attempts!=0A=0AHi,=0A=0AI've been working on getting the mai= nline qemu tree working on SmartOS (illumos), the current qemu support see= ms to be a branch of qemu-kvm and we've been having some problems getting = spice working, so moving to the main qemu tree seemed sensible.=0A=0AAnywa= y, couple of questions=85=0A=0A1. Are you happy to accept patches that ena= ble this? =0A - There are a few build related things that don't work =85= assumption of sh being bash, missing -64 argument to dtrace etc. =0A - Th= ere are also some dtrace language problems with tracetool (no support for = bool, and self being reserved.) =0A - More fundamentally some object linki= ng issues with dtrace which I'll need some help to find the best way to re= solve.=0A - Specific #ifdef CONFIG_SOLARIS/__sun__ stuff to support differ= ences=0A - ultimately the support for vnic's =85 but I haven't even looked= at that yet.=0A=0A The current state is that it's working ok for Windows = guests, and non-KVM for Linux, but kvm & linux seems to fail, hence qu= estion number 2.=0A=0A2. The last thing that happens when I try to boot li= nux with kvm enabled is some apic mmio accesses, then it stops at a hlt in= struction and never gets going again. Is there something I can enable to h= elp debug this? Or has anyone else seen similar behaviour? I've run out of= places to look.=0A=0AMany thanks,=0A=0ALee.

On 15/03/2012 11:56, Stefan Hajnoczi wrote:
=0A=0A

Anywa=
y, couple of questions=85=0A=0A1. Are you happy to accept patches that ena=
ble this?=0A	- There are a few build related things that don't work =85 as=
sumption of sh=0Abeing bash, missing -64 argument to dtrace etc.=0A

<= /blockquote>=0A

Sounds good, but have you checked the Joye=
nt qemu-kvm Illumos port to=0Asee what fixes they already have?=0A=0Ahttps=
://github.com/joyent/illumos-kvm-cmd

=
Yes, they have solved the same problems .. however the build mechanism= seems to be sufficiently different that things need to be done slightly d= ifferently for qemu.git.

These aren't complex changes and amount to= generally only a couple of lines.

The illumos-kvm-cmd tree seems t= o be only updated to address joyent live-image build requirements, and has= n't really moved in about 7 months. I've been posting profusely on the sma= rtos mailing list and they also don't seem that concerned about this work.=

However, there are a few of us that would like to get spice up and= running and the illumos fork doesn't seem like a sensible place to start = when they are so far behind.

They have said that they will incorpor= ate the spice work once it's complete, so I'm pretty confident that we can= push them to the main qemu tree at that point.

=0A

	- More fundamentally some object linking issues with dtrace which I'll=
 need=0Asome help to find the best way to resolve.=0A
I think Joyent has already done this, they said they use QEMU= tracing=0Awith DTrace as the backend.=0A

Yes they have, but again the build mechanism has changed quite si= gnificantly.

The basic issue here is that dtrace on Illumos seems t= o need all objects to be provided to it when you create the dtrace provide= r object, I'm guessing it uses the objects to work out which probes to act= ually include ... if you don't provide any objects you get an output objec= t with none of the symbols you need in it.

So for each binary creat= ed you need to do something like...

dtrace -o <binary>-dtrace= .o -G -s <dtrace-source> <all-the-objects-used-by-the-binary><= br>
... then include the specific <binary>-drace.o when linking t= he main binary.=0A

So yo=
u are using qemu.git/master with the IllumOS KVM port?=0A=0AI think what y=
ou are trying to do makes sense - IllumOS as a host OS=0Aand QEMU platform=
 should be actively involved in the upstream QEMU=0Acommunity.  But you ma=
y want to first check the Joyent port to see=0Awhat can easily be upstream=
ed and also try talking with them if you=0Ahaven't already.  I'm not sure =
why things aren't being pushed upstream=0Abut perhaps the process can be s=
tarted.=0A

Yes, and (other than m= y Linux issue) it's working well.

The changes needed to get it work= ing are pretty minimal, most of them are #ifdef's around KVM_CAP's that ar= e assumed to be defined (at least in some of the code.)

The specifi= c code changes boil down to:
- a different mechanism for creating a vcp= u 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=3D0 from the ioctl (exernal interrupt)

... which amounts to pr= obably less than 50 lines of changes, and again the code structure is pret= ty different to their port, so I think it's easier to apply new rather tha= n push upstream.

I would have thought that applying this (minimal) = stuff to the qemu.git tree and using that for illumos would remove the nee= d for a specific joyent version, and hence be a good thing.

The joy= ent guys are very focused (understandably) on their specific needs, howeve= r if someone else is prepared to do the work they do seem pretty willing t= o adopt it.

Regards,

Lee.

=0A