Add kvm_set_boot_cpu_id() API.
PATCH RESEND 1/1 Add kvm_set_boot_cpu_id() API.
Old kernel assumed that apic id of a boot cpus is zero, recent kernels have an IOCTL to configure BSP's apic id. The patch adds API function to use this capability. The BSP apic id is set to zero (now explicitly) since QEMU/BIOS not ready yet to take full advantage of the new API.
hw/pc.c +1 -0
@@ -1131,6 +1131,7 @@ static void pc_init1(ram_addr_t ram_size,#endif } +kvm_set_boot_cpu_id (0 );for (i =0 ; i < smp_cpus; i++) { env =pc_new_cpu (cpu_model); }
qemu-kvm.c +17 -0
@@ -441,6 +441,18 @@ err:return NULL ; } +static int kvm_set_boot_vcpu_id (kvm_context_t kvm,uint32_t id) +{ +#ifdef KVM_CAP_SET_BOOT_CPU_ID +int r =ioctl (kvm->fd,KVM_CHECK_EXTENSION ,KVM_CAP_SET_BOOT_CPU_ID ); +if (r >0 ) +return ioctl (kvm->vm_fd,KVM_SET_BOOT_CPU_ID , id); +return -ENOSYS ; +#else +return -ENOSYS ; +#endif +} +int kvm_create_vm (kvm_context_t kvm) {int fd = kvm->fd;
@@ -2923,3 +2935,8 @@ void qemu_kvm_cpu_stop(CPUState *env)if (kvm_enabled ()) env->kvm_cpu_state.stopped =1 ; } + +int kvm_set_boot_cpu_id (uint32_t id) +{ +return kvm_set_boot_vcpu_id (kvm_context, id); +}
qemu-kvm.h +1 -0
@@ -80,6 +80,7 @@ int kvm_arch_try_push_interrupts(void *opaque);void kvm_arch_push_nmi (void *opaque);void kvm_arch_update_regs_for_sipi (CPUState *env);void kvm_arch_cpu_reset (CPUState *env); +int kvm_set_boot_cpu_id (uint32_t id);struct kvm_guest_debug ;struct kvm_debug_exit_arch ;
--
Gleb.
Avi Kivity
AppliedQuoted 5 lines · Gleb Natapov
Old kernel assumed that apic id of a boot cpus is zero, recent kernels have an IOCTL to configure BSP's apic id. The patch adds API function to use this capability. The BSP apic id is set to zero (now explicitly) since QEMU/BIOS not ready yet to take full advantage of the new API.
Applied, thanks.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 9 lines · Avi Kivity
Quoted 5 lines · Gleb Natapov
Old kernel assumed that apic id of a boot cpus is zero, recent kernels have an IOCTL to configure BSP's apic id. The patch adds API function to use this capability. The BSP apic id is set to zero (now explicitly) since QEMU/BIOS not ready yet to take full advantage of the new API.
Applied, thanks.
Also breaks --disable-kvm build. Avi, could you add a corresponding build run with all targets enabled to your pre-commit tests?
Jan
buildbot
Quoted 3 lines · Jan Kiszka
Also breaks --disable-kvm build. Avi, could you add a corresponding build run with all targets enabled to your pre-commit tests?
I'd like to solve this in a more general way: buildbot. That will allow testing a matrix of configs x host kernel x host arch. It should be easy to set up buildslaves on virtual machines running various targets, and I also have ppc and s390 accounts. My main interest is kvm-kmod which is becoming more and more difficult to maintain but also qemu-kvm.
If someone can help with setup, or even better, volunteer to setup and host the buildmaster, we can concentrate more on patches and less on breakage. Buildbot even has a 'try' command which lets submitters test patches.
Signature · 2 lines
I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
Re: buildbot
On Tuesday 07 July 2009 09:47:29 pm Avi Kivity wrote:
[...]
Quoted 4 lines
If someone can help with setup, or even better, volunteer to setup and host the buildmaster, we can concentrate more on patches and less on breakage. Buildbot even has a 'try' command which lets submitters test patches.
I would volunteer to setup and maintain the buildmaster. We could also provide some buildslaves for x86 and x86_64.
Unfortuatnely i'm completely new to the buildbot itself. Only did in the past brief checks of the documentation and feature overview. I already maintain some different continous build testing infrastrucute (based on ctest/cdash).
But i'm very interested in getting in touch with buildbot and to support the kvm project. So it might take some days before the buildmaster instance is running productive. So if there are no other takers i would start setting up the buildmaster host.
Best Regards,
Daniel
Signature · 8 lines
Daniel Gollub Geschaeftsfuehrer: Ralph Dehner FOSS Developer Unternehmenssitz: Vohburg B1 Systems GmbH Amtsgericht: Ingolstadt Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 EMail: [email protected] http://www.b1-systems.de Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D
Re: buildbot
Quoted 13 lines · Daniel Gollub
On Tuesday 07 July 2009 09:47:29 pm Avi Kivity wrote:
[...]Quoted 5 lines
If someone can help with setup, or even better, volunteer to setup and host the buildmaster, we can concentrate more on patches and less on breakage. Buildbot even has a 'try' command which lets submitters test patches.
I would volunteer to setup and maintain the buildmaster. We could also provide some buildslaves for x86 and
x86_64.
Thanks.
Quoted 5 lines
Unfortuatnely i'm completely new to the buildbot itself. Only did in the past brief checks of the documentation and feature overview. I already maintain some different continous build testing infrastrucute (based on ctest/cdash).
It doesn't have to be buildbot; anything that provides similar functionality and is reasonably well documented can be used.
Quoted 5 lines
But i'm very interested in getting in touch with buildbot and to support the kvm project. So it might take some days before the buildmaster instance is running productive. So if there are no other takers i would start setting up the buildmaster host.
Great. We can start with qemu-kvm.git (and qemu.git), as getting buildbot to understand how the external module works is not going to be trivial.
Signature · 2 lines
I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
Re: buildbot
Quoted 9 lines · Avi Kivity
Quoted 6 lines
Unfortuatnely i'm completely new to the buildbot itself. Only did in the past brief checks of the documentation and feature overview. I already maintain some different continous build testing infrastrucute (based on ctest/cdash).
It doesn't have to be buildbot; anything that provides similar functionality and is reasonably well documented can be used.
ctest/cdash doesn't have yet completed Git integration (AFAIK). Not quite sure about any other alternatives to buildbot, which support Git. I already started setting up buildbot last night in a test environment ...
Quoted 10 lines
Quoted 6 lines
But i'm very interested in getting in touch with buildbot and to support the kvm project. So it might take some days before the buildmaster instance is running productive. So if there are no other takers i would start setting up the buildmaster host.
Great. We can start with qemu-kvm.git (and qemu.git), as getting buildbot to understand how the external module works is not going to be trivial.
A local instance of buildbot with one master and one slave is already running for qemu-kvm.git (clone). Preparing now the final buildmaster host ...
Unfortunately there seems to be no Git-"poller" in buildbot, like for SVN. So there is need to install a Git post-receive hook on the repositories to trigger the buildbot-master:
http://buildbot.net/trac/browser/contrib/git_buildbot.py
I hope this ok. Otherwise we would need to setup mirror, which contains this hook.
Some further questions to the build test:
- incremental/quick or full/"safe" build tests?
(e.g. "make clean" before actual configuration/build?)
- any non-default compiler flags?
- which combination of configuration should get tested?
* w/o --disable-kvm
* ...
- which branches should get build-tested for qemu-kvm.git? just master in the beginning?
Best Regards,
Daniel
Signature · 8 lines
Daniel Gollub Geschaeftsfuehrer: Ralph Dehner FOSS Developer Unternehmenssitz: Vohburg B1 Systems GmbH Amtsgericht: Ingolstadt Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 EMail: [email protected] http://www.b1-systems.de Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D
Re: buildbot
Quoted 11 lines · Daniel Gollub
A local instance of buildbot with one master and one slave is already running for qemu-kvm.git (clone). Preparing now the final buildmaster host ...
Unfortunately there seems to be no Git-"poller" in buildbot, like for SVN. So there is need to install a Git post-receive hook on the repositories to trigger the buildbot-master:
http://buildbot.net/trac/browser/contrib/git_buildbot.pyI hope this ok. Otherwise we would need to setup mirror, which contains this hook.
I can easily add the hook.
Quoted 5 lines
Some further questions to the build test:
- incremental/quick or full/"safe" build tests? (e.g. "make clean" before actual configuration/build?)
I think clean builds + ccache give a good safety/performance tradeoff. qemu is pretty safe wrt incremental builds anyway.
Quoted 2 lines
- any non-default compiler flags?
Not from me, but if someone has a favorite flag, we can test it.
Quoted 4 lines
- which combination of configuration should get tested?
* w/o --disable-kvm
* ...
Let's hear the list...
Quoted 3 lines
- which branches should get build-tested for qemu-kvm.git? just master in the beginning?
master, next, stable-0.10
I also want more repositories: qemu.git, kvm.git, and kvm-kmod.git. The latter will be tricky since it references another repository, but we'll work it out.
Signature · 1 line
error compiling committee.c: too many arguments to function
Re: buildbot
In reply to Daniel GollubQuoted 31 lines · Daniel Gollub
Quoted 8 lines · Avi Kivity
Quoted 6 lines
Unfortuatnely i'm completely new to the buildbot itself. Only did in the past brief checks of the documentation and feature overview. I already maintain some different continous build testing infrastrucute (based on ctest/cdash).
It doesn't have to be buildbot; anything that provides similar functionality and is reasonably well documented can be used.
ctest/cdash doesn't have yet completed Git integration (AFAIK). Not quite sure about any other alternatives to buildbot, which support Git. I already started setting up buildbot last night in a test environment ...
Quoted 8 lines
Quoted 5 lines
But i'm very interested in getting in touch with buildbot and to support the kvm project. So it might take some days before the buildmaster instance is running productive. So if there are no other takers i would start setting up the buildmaster host.
Great. We can start with qemu-kvm.git (and qemu.git), as getting buildbot to understand how the external module works is not going to be trivial.
A local instance of buildbot with one master and one slave is already running for qemu-kvm.git (clone). Preparing now the final buildmaster host ...
Unfortunately there seems to be no Git-"poller" in buildbot, like for SVN. So there is need to install a Git post-receive hook on the repositories to trigger the buildbot-master:
http://buildbot.net/trac/browser/contrib/git_buildbot.py
Quoted 7 lines
I hope this ok. Otherwise we would need to setup mirror, which contains this hook.
Some further questions to the build test:
- incremental/quick or full/"safe" build tests? (e.g. "make clean" before actual configuration/build?)
Maybe a full rebuild once per day and incremental rebuilds for each update. I bet there will be a way to trigger also full rebuilds manually in case something looks fishy, right?
Quoted 1 line
- any non-default compiler flags?
Use as many as you can. Make sure all required libs are available on the host so that qemu(-kvm) enables the related features (e.g. xen).
Quoted 6 lines
- which combination of configuration should get tested?
* w/o --disable-kvm
* ...
- which branches should get build-tested for qemu-kvm.git? just master in the beginning?
Further wishes (I didn't thought too much about it, be prepared for more :->):
- out-of-tree build (currently broken in qemu-kvm)
- building for 32 and 64-bit hosts
Thanks for your effort so far! But I hope you are aware of the fact that maintaining the buildbot will also require some work. I would suggest to either make the setup description and scripts available for cloning your environment easily or arrange access for further contributors to distribute maintenance as far as reasonable and feasible. I would be someone interested in helping (as I hope it will safe me quite some time elsewhere).
Jan
Re: buildbot
Quoted 7 lines · Jan Kiszka
Quoted 4 lines
Some further questions to the build test:
- incremental/quick or full/"safe" build tests? (e.g. "make clean" before actual configuration/build?)
Maybe a full rebuild once per day and incremental rebuilds for each update.
Buildbot has a scheduler called "Nightly", which would perfectly fit here. You can schedule those full builds on e.g.: 23:00
Quoted 2 lines
I bet there will be a way to trigger also full rebuilds manually in case something looks fishy, right?
Not quite sure - need to check that. But there is buttoon "force build" on the web interface to retrigger a build, even if there was no "event" (e.g. commit). But this would also call the Build-Profile without the "make clean". But we could create a "cleanup" Build-Profile, which is using the same build directory. And do this "force build" for this "cleanup" Build-Profile.
But very likely there is such a feature and i just didn't found it yet ....
Quoted 5 lines
Quoted 2 lines
- any non-default compiler flags?
Use as many as you can. Make sure all required libs are available on the host so that qemu(-kvm) enables the related features (e.g. xen).
Ok.
Quoted 7 lines
Quoted 6 lines
- which combination of configuration should get tested?
* w/o --disable-kvm
* ...
- which branches should get build-tested for qemu-kvm.git? just master in the beginning?
Quoted 5 lines
Further wishes (I didn't thought too much about it, be prepared for more
:->):
- out-of-tree build (currently broken in qemu-kvm)
With every commit, or nightly/once-per-day?
Quoted 1 line
- building for 32 and 64-bit hosts
Yes, thats planned.
Quoted 3 lines
Thanks for your effort so far! But I hope you are aware of the fact that maintaining the buildbot will also require some work.
Sure, i already discussed that with my manager. I guess some of my colleagues will also support me on maintaing this environment ...
Quoted 4 lines
I would suggest to
either make the setup description and scripts available for cloning your environment easily or arrange access for further contributors to distribute maintenance as far as reasonable and feasible.
It's planned to setup the buildmaster in a VM. So if there is any HW failure or I run out of time, i would just handover the VM to someone else. The VM is dedicated to the buildmaster ...
I thought also about running a Git repository for the used buildmaster configuration. Since the master configuration contains all the build profiles.
Quoted 3 lines
I would be
someone interested in helping (as I hope it will safe me quite some time elsewhere).
Ok - cool. As soon the VM is up and running i'll contact you regarding remote access.
Best Regards,
Daniel
Signature · 8 lines
Daniel Gollub Geschaeftsfuehrer: Ralph Dehner FOSS Developer Unternehmenssitz: Vohburg B1 Systems GmbH Amtsgericht: Ingolstadt Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 EMail: [email protected] http://www.b1-systems.de Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D