Hi, Just a heads up that I''m pushing a new 2.6.27 based kernel-xen to rawhide. This includes Jeremy Fitzhardinge''s xen-64bit tree[1] in place of Eduardo''s xen-pvops-64.git tree. Basically, Jeremy has half of the 64 bit Xen work merged for 2.6.27 already and the other half is queued up, hopefully to be included before the merge window ends. If we can get that stuff some testing, perhaps it might help the cause of getting it merged. This is all irrelevant if the build fails, of course :-) http://koji.fedoraproject.org/koji/taskinfo?taskID=725025 Cheers, Mark. [1] - http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=shortlog;h=xen-64bit
On Fri, Jul 18, 2008 at 05:26:58PM +0100, Mark McLoughlin wrote:> Hi, > Just a heads up that I''m pushing a new 2.6.27 based kernel-xen to > rawhide. This includes Jeremy Fitzhardinge''s xen-64bit tree[1] in place > of Eduardo''s xen-pvops-64.git tree. > > Basically, Jeremy has half of the 64 bit Xen work merged for 2.6.27 > already and the other half is queued up, hopefully to be included before > the merge window ends. If we can get that stuff some testing, perhaps it > might help the cause of getting it merged. > > This is all irrelevant if the build fails, of course :-)Seems to have succeeded, so how about putting it into the real kernel RPM directly, and finally kill kernel-xen as an RPM :-) Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Fri, 2008-07-18 at 19:10 +0100, Daniel P. Berrange wrote:> On Fri, Jul 18, 2008 at 05:26:58PM +0100, Mark McLoughlin wrote: > > Hi, > > Just a heads up that I''m pushing a new 2.6.27 based kernel-xen to > > rawhide. This includes Jeremy Fitzhardinge''s xen-64bit tree[1] in place > > of Eduardo''s xen-pvops-64.git tree. > > > > Basically, Jeremy has half of the 64 bit Xen work merged for 2.6.27 > > already and the other half is queued up, hopefully to be included before > > the merge window ends. If we can get that stuff some testing, perhaps it > > might help the cause of getting it merged. > > > > This is all irrelevant if the build fails, of course :-) > > Seems to have succeeded, so how about putting it into the real kernel > RPM directly, and finally kill kernel-xen as an RPM :-)Yes, I''d very much like to make that happen soon. There are two considerations, though: 1) The second half of the xen x86_64 DomU work has not yet been merged upstream. It''s a fairly big patch: 49 files changed, 2344 insertions(+), 913 deletions(-) so, if it doesn''t get merged, it''s possible it''s easier to maintain that patch in a separate kernel-xen RPM. It''s also questionable as to whether the stock kernel RPM maintainers would be willing to carry such a big patch. The 2.6.27 merge window is still open, though, so hopefully Ingo will push it up to Linus before it closes and this point will be moot. 2) For the same reasons, if we kill the separate kernel-xen RPM, that restricts our ability to pull in a work-in-progress Dom0 tree in future. I expect if we do kill kernel-xen, we won''t see Dom0 in Fedora until it''s fully upstream. Since so little progress is being made currently on the Dom0 front, though, I don''t think this is a good reason to hold off on merging the RPMs. So, my plan is to push ahead with killing off the separate RPM if the rest of x86_64 DomU gets merged. If it doesn''t, then we''ll need to take a closer look at how invasive the patch is and discuss it with the core kernel RPM maintainers. Cheers, Mark.
On Mon, 2008-07-21 at 14:13 +0100, Mark McLoughlin wrote:> On Fri, 2008-07-18 at 19:10 +0100, Daniel P. Berrange wrote: > > On Fri, Jul 18, 2008 at 05:26:58PM +0100, Mark McLoughlin wrote: > > > Hi, > > > Just a heads up that I''m pushing a new 2.6.27 based kernel-xen to > > > rawhide. This includes Jeremy Fitzhardinge''s xen-64bit tree[1] in place > > > of Eduardo''s xen-pvops-64.git tree. > > > > > > Basically, Jeremy has half of the 64 bit Xen work merged for 2.6.27 > > > already and the other half is queued up, hopefully to be included before > > > the merge window ends. If we can get that stuff some testing, perhaps it > > > might help the cause of getting it merged. > > > > > > This is all irrelevant if the build fails, of course :-) > > > > Seems to have succeeded, so how about putting it into the real kernel > > RPM directly, and finally kill kernel-xen as an RPM :-) > > Yes, I''d very much like to make that happen soon. > > There are two considerations, though: > > 1) The second half of the xen x86_64 DomU work has not yet been > merged upstream. It''s a fairly big patch: > > 49 files changed, 2344 insertions(+), 913 deletions(-) > > so, if it doesn''t get merged,Sweet, Ingo has just pushed it up to Linus: http://lkml.org/lkml/2008/7/21/201 Cheers, Mark.
On Mon, Jul 21, 2008 at 05:15:41PM +0100, Mark McLoughlin wrote:> On Mon, 2008-07-21 at 14:13 +0100, Mark McLoughlin wrote: > > On Fri, 2008-07-18 at 19:10 +0100, Daniel P. Berrange wrote: > > > On Fri, Jul 18, 2008 at 05:26:58PM +0100, Mark McLoughlin wrote: > > > > Hi, > > > > Just a heads up that I''m pushing a new 2.6.27 based kernel-xen to > > > > rawhide. This includes Jeremy Fitzhardinge''s xen-64bit tree[1] in place > > > > of Eduardo''s xen-pvops-64.git tree. > > > > > > > > Basically, Jeremy has half of the 64 bit Xen work merged for 2.6.27 > > > > already and the other half is queued up, hopefully to be included before > > > > the merge window ends. If we can get that stuff some testing, perhaps it > > > > might help the cause of getting it merged. > > > > > > > > This is all irrelevant if the build fails, of course :-) > > > > > > Seems to have succeeded, so how about putting it into the real kernel > > > RPM directly, and finally kill kernel-xen as an RPM :-) > > > > Yes, I''d very much like to make that happen soon. > > > > There are two considerations, though: > > > > 1) The second half of the xen x86_64 DomU work has not yet been > > merged upstream. It''s a fairly big patch: > > > > 49 files changed, 2344 insertions(+), 913 deletions(-) > > > > so, if it doesn''t get merged, > > Sweet, Ingo has just pushed it up to Linus: > > http://lkml.org/lkml/2008/7/21/201 >That''s really nice progress with upstream merging.. I still think it might be a good idea to keep separate kernel-xen until upstream has "all" the needed features.. Like said, adding dom0 patches should be easier to separate rpm? -- Pasi
On Thu, Jul 24, 2008 at 01:32:37PM +0300, Pasi K?rkk?inen wrote:> On Mon, Jul 21, 2008 at 05:15:41PM +0100, Mark McLoughlin wrote: > > On Mon, 2008-07-21 at 14:13 +0100, Mark McLoughlin wrote: > > > On Fri, 2008-07-18 at 19:10 +0100, Daniel P. Berrange wrote: > > > > On Fri, Jul 18, 2008 at 05:26:58PM +0100, Mark McLoughlin wrote: > > > > > Hi, > > > > > Just a heads up that I''m pushing a new 2.6.27 based kernel-xen to > > > > > rawhide. This includes Jeremy Fitzhardinge''s xen-64bit tree[1] in place > > > > > of Eduardo''s xen-pvops-64.git tree. > > > > > > > > > > Basically, Jeremy has half of the 64 bit Xen work merged for 2.6.27 > > > > > already and the other half is queued up, hopefully to be included before > > > > > the merge window ends. If we can get that stuff some testing, perhaps it > > > > > might help the cause of getting it merged. > > > > > > > > > > This is all irrelevant if the build fails, of course :-) > > > > > > > > Seems to have succeeded, so how about putting it into the real kernel > > > > RPM directly, and finally kill kernel-xen as an RPM :-) > > > > > > Yes, I''d very much like to make that happen soon. > > > > > > There are two considerations, though: > > > > > > 1) The second half of the xen x86_64 DomU work has not yet been > > > merged upstream. It''s a fairly big patch: > > > > > > 49 files changed, 2344 insertions(+), 913 deletions(-) > > > > > > so, if it doesn''t get merged, > > > > Sweet, Ingo has just pushed it up to Linus: > > > > http://lkml.org/lkml/2008/7/21/201 > > > > That''s really nice progress with upstream merging.. > > I still think it might be a good idea to keep separate kernel-xen until > upstream has "all" the needed features.. > > Like said, adding dom0 patches should be easier to separate rpm?Possibly - that''s TDB when we have working Dom0 patches again. The Dom0 patches will have to work against latest LKML tree, so it might turn out to be easy to do against the main kernel RPM. It really depends how unstable/invasive Dom0 bits are. This is a decision that is independant of the guest stuff though. In terms of guest support, we absolutely want 1 kernel for F10. A core point of paravirt_ops is that a single kernel binary can boot and auto detect the hypervisor its running on. This means we can get rid of the separate vmlinuz/initrd in the install trees, get rid of anaconda logic to install a different kernel in Xen guests, and lots of other cleanup. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Thu, 2008-07-24 at 13:32 +0300, Pasi Kärkkäinen wrote:> I still think it might be a good idea to keep separate kernel-xen until > upstream has "all" the needed features.. > > Like said, adding dom0 patches should be easier to separate rpm?Yeah, it''s a trade-off. But consider: a) davej is rebasing the stock kernel up to twice daily; it would be a huge time sync to try and keep kernel-xen in sync with that pace; b) There''s relatively little Dom0 work going on a the moment, so there''s little chance of having usable Dom0 patches for Fedora 10 c) It''s not inconceivable that we could add work-in-progress Dom0 patches to kernel/devel; the bar would be higher than for kernel-xen, though I sent a bunch of patches to fedora-kernel-list yesterday: https://www.redhat.com/archives/fedora-kernel-list/2008-July/thread.html#00062 Cheers, Mark.
On Thu, Jul 24, 2008 at 11:37:05AM +0100, Daniel P. Berrange wrote:> On Thu, Jul 24, 2008 at 01:32:37PM +0300, Pasi K?rkk?inen wrote: > > On Mon, Jul 21, 2008 at 05:15:41PM +0100, Mark McLoughlin wrote: > > > On Mon, 2008-07-21 at 14:13 +0100, Mark McLoughlin wrote: > > > > On Fri, 2008-07-18 at 19:10 +0100, Daniel P. Berrange wrote: > > > > > On Fri, Jul 18, 2008 at 05:26:58PM +0100, Mark McLoughlin wrote: > > > > > > Hi, > > > > > > Just a heads up that I''m pushing a new 2.6.27 based kernel-xen to > > > > > > rawhide. This includes Jeremy Fitzhardinge''s xen-64bit tree[1] in place > > > > > > of Eduardo''s xen-pvops-64.git tree. > > > > > > > > > > > > Basically, Jeremy has half of the 64 bit Xen work merged for 2.6.27 > > > > > > already and the other half is queued up, hopefully to be included before > > > > > > the merge window ends. If we can get that stuff some testing, perhaps it > > > > > > might help the cause of getting it merged. > > > > > > > > > > > > This is all irrelevant if the build fails, of course :-) > > > > > > > > > > Seems to have succeeded, so how about putting it into the real kernel > > > > > RPM directly, and finally kill kernel-xen as an RPM :-) > > > > > > > > Yes, I''d very much like to make that happen soon. > > > > > > > > There are two considerations, though: > > > > > > > > 1) The second half of the xen x86_64 DomU work has not yet been > > > > merged upstream. It''s a fairly big patch: > > > > > > > > 49 files changed, 2344 insertions(+), 913 deletions(-) > > > > > > > > so, if it doesn''t get merged, > > > > > > Sweet, Ingo has just pushed it up to Linus: > > > > > > http://lkml.org/lkml/2008/7/21/201 > > > > > > > That''s really nice progress with upstream merging.. > > > > I still think it might be a good idea to keep separate kernel-xen until > > upstream has "all" the needed features.. > > > > Like said, adding dom0 patches should be easier to separate rpm? > > Possibly - that''s TDB when we have working Dom0 patches again. The Dom0 > patches will have to work against latest LKML tree, so it might turn > out to be easy to do against the main kernel RPM. It really depends how > unstable/invasive Dom0 bits are. This is a decision that is independant > of the guest stuff though. >Ok.> In terms of guest support, we absolutely want 1 kernel for F10. A core > point of paravirt_ops is that a single kernel binary can boot and auto > detect the hypervisor its running on. This means we can get rid of the > separate vmlinuz/initrd in the install trees, get rid of anaconda logic > to install a different kernel in Xen guests, and lots of other cleanup. >That makes sense. Thanks. -- Pasi