On 15/03/2012 11:56, Stefan Hajnoczi wrote:
Anyway, couple of questions…
1. Are you happy to accept patches that enable this?
- There are a few build related things that don't work … assumption of sh
being bash, missing -64 argument to dtrace etc.
Sounds good, but have you checked the Joyent qemu-kvm Illumos port to
see what fixes they already have?
https://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 differently for qemu.git.
These aren't complex changes and amount to generally only a couple of lines.
The illumos-kvm-cmd tree seems to be only updated to address joyent live-image build requirements, and hasn't really moved in about 7 months. I've been posting profusely on the smartos 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 incorporate 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.
- More fundamentally some object linking issues with dtrace which I'll need
some help to find the best way to resolve.
I think Joyent has already done this, they said they use QEMU tracing
with DTrace as the backend.
Yes they have, but again the build mechanism has changed quite significantly.
The basic issue here is that dtrace on Illumos seems to need all objects to be provided to it when you create the dtrace provider object, I'm guessing it uses the objects to work out which probes to actually include ... if you don't provide any objects you get an output object with none of the symbols you need in it.
So for each binary created you need to do something like...
dtrace -o <binary>-dtrace.o -G -s <dtrace-source> <all-the-objects-used-by-the-binary>
... then include the specific <binary>-drace.o when linking the main binary.
So you are using qemu.git/master with the IllumOS KVM port?
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.
Regards,
Lee.