| Message ID | 20090706143546.GB28046@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 07/06/2009 05:35 PM, Gleb Natapov wrote: > 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.
Avi Kivity wrote: > On 07/06/2009 05:35 PM, Gleb Natapov wrote: >> 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
On 07/07/2009 09:45 PM, Jan Kiszka wrote: > 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.
On Tuesday 07 July 2009 09:47:29 pm Avi Kivity wrote: [...] > 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
On 07/07/2009 11:53 PM, Daniel Gollub wrote: > On Tuesday 07 July 2009 09:47:29 pm Avi Kivity wrote: > [...] > >> 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. > 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. > 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.
On Wednesday 08 July 2009 06:54:09 am Avi Kivity wrote: > > 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 ... > > > 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
On 07/08/2009 05:45 PM, Daniel Gollub wrote: > 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. > I can easily add the hook. > 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. > - any non-default compiler flags? > Not from me, but if someone has a favorite flag, we can test it. > - which combination of configuration should get tested? > * w/o --disable-kvm > * ... > Let's hear the list... > - 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.
Daniel Gollub wrote: > On Wednesday 08 July 2009 06:54:09 am Avi Kivity wrote: >>> 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 ... > >>> 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?) 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? > - 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). > - 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
On Wednesday 08 July 2009 05:18:41 pm Jan Kiszka wrote: > > 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 > 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 .... > > > - 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. > > > - 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) With every commit, or nightly/once-per-day? > - building for 32 and 64-bit hosts Yes, thats planned. > > 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 ... > 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. > 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
diff --git a/hw/pc.c b/hw/pc.c index 43e2f29..cf84416 100644 --- a/hw/pc.c +++ b/hw/pc.c @@ -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); } diff --git a/qemu-kvm.c b/qemu-kvm.c index c5cd038..c57df57 100644 --- a/qemu-kvm.c +++ b/qemu-kvm.c @@ -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); +} diff --git a/qemu-kvm.h b/qemu-kvm.h index eb99bc4..ce22bed 100644 --- a/qemu-kvm.h +++ b/qemu-kvm.h @@ -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;