| Message ID | 1240955602.24625.57.camel@slate.austin.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hollis Blanchard wrote: > On Thu, 2009-04-23 at 18:40 +0300, Avi Kivity wrote: > >> Still missing: >> - I have not tested powerpc or ia64. Patches welcome! >> > > This repository seems pretty messed up; I'm not even sure what you want > from me. Since PPC is now supported in upstream QEMU, does it really matter if it works in qemu-kvm.git? Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Apr 28, 2009 at 7:20 PM, Anthony Liguori <anthony@codemonkey.ws> wrote: > Hollis Blanchard wrote: >> >> On Thu, 2009-04-23 at 18:40 +0300, Avi Kivity wrote: >> >>> >>> Still missing: >>> - I have not tested powerpc or ia64. Â Patches welcome! >>> >> >> This repository seems pretty messed up; I'm not even sure what you want >> from me. > > Since PPC is now supported in upstream QEMU, does it really matter if it > works in qemu-kvm.git? Yes. There are people (me) who still rely on building everything from the same source. It can only be done by the superset (qemu-kvm.git)
Glauber Costa wrote: > Yes. There are people (me) who still rely on building everything from > the same source. > It can only be done by the superset (qemu-kvm.git) > Fedora doesn't package a KVM enabled qemu-system-ppcemb, do they? Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2009-04-28 at 17:20 -0500, Anthony Liguori wrote: > Hollis Blanchard wrote: > > On Thu, 2009-04-23 at 18:40 +0300, Avi Kivity wrote: > > > >> Still missing: > >> - I have not tested powerpc or ia64. Patches welcome! > >> > > > > This repository seems pretty messed up; I'm not even sure what you want > > from me. > Since PPC is now supported in upstream QEMU, does it really matter if it > works in qemu-kvm.git? I was going to take that position too, except Avi asked me specifically if some of the code inside TARGET_I386 ifdefs in qemu-kvm.c works for other architectures. Since it's a safe bet that some version of this code will probably be submitted to qemu-devel, I figured I'd try a build test... and discovered that qemu-kvm.git was released a little prematurely.
On Tue, 2009-04-28 at 17:28 -0500, Anthony Liguori wrote: > Glauber Costa wrote: > > Yes. There are people (me) who still rely on building everything from > > the same source. > > It can only be done by the superset (qemu-kvm.git) > > > > Fedora doesn't package a KVM enabled qemu-system-ppcemb, do they? The more people who notice when the PowerPC build breaks, the better.
Hollis Blanchard wrote: > On Thu, 2009-04-23 at 18:40 +0300, Avi Kivity wrote: > >> Still missing: >> - I have not tested powerpc or ia64. Patches welcome! >> > > This repository seems pretty messed up; I'm not even sure what you want > from me. Some of the bigger problems: > > * configure completely ignores --kerneldir and only uses > kvm/kernel headers instead. > That's intentional. > * The headers in kvm/kernel/arch/foo seem to be the important > ones, but they have odd ifdefs at the top and I'm not sure how > they should be generated. > They were generated by the old 'make sync' to remove CONFIG_ dependencies. I guess a better way to generate them is a 'make headers-install' from the kernel tree and grab the results. > * "make -C kvm/kernel sync" doesn't even come close to working. > One of the goals of qemu-kvm.git was to have a standalone repository so I could release kvm-kmod and qemu-kvm independently. > There are a host of other issues and confusing issues, even with a fresh > checkout. In general it seems like the mess that was kvm-userspace has > been rearranged, and as a consequence is even worse than before. > Can you detail specific grievances? Please exclude temporary brokenness that was the result of the change. > How am I supposed to create kvm/kernel/arch/powerpc/include/asm/*? Just > cp from a Linux tree, or must I add funny ifdefs somehow? > cp from a Linux tree won't compile. The results of the old 'make sync' would do, but a 'make headers-install' is probably better. > Here's one patch that I think will be needed: > > > Set kvm_arch=powerpc for PPC builds. > > The name of the Linux arch directory is "powerpc", not "ppc". > > Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com> > > diff --git a/configure b/configure > index fc0fb9b..257cf02 100755 > --- a/configure > +++ b/configure > @@ -816,6 +816,9 @@ case "$cpu" in > i386 | x86_64) > kvm_arch="x86" > ;; > + ppc) > + kvm_arch="powerpc" > + ;; > *) > kvm_arch="$cpu" > ;; > > > Applied, thanks.
Hollis Blanchard wrote: >> Since PPC is now supported in upstream QEMU, does it really matter if it >> works in qemu-kvm.git? >> > > I was going to take that position too, except Avi asked me specifically > if some of the code inside TARGET_I386 ifdefs in qemu-kvm.c works for > other architectures. > > In that case it's sufficient to have the build system use the upstream kvm integration (CONFIG_KVM) rather than the qemu-kvm integration (USE_KVM).
On Wed, 2009-04-29 at 11:29 +0300, Avi Kivity wrote: > > > > * configure completely ignores --kerneldir and only uses > > kvm/kernel headers instead. > > > > That's intentional. Huh? If --kerneldir does nothing, why does it exist? > > * The headers in kvm/kernel/arch/foo seem to be the important > > ones, but they have odd ifdefs at the top and I'm not sure > how > > they should be generated. > > > > They were generated by the old 'make sync' to remove CONFIG_ > dependencies. I guess a better way to generate them is a 'make > headers-install' from the kernel tree and grab the results. 'make headers_install' only produces include/asm/kvm.h, which apparently is not sufficient. I can use output from an old 'make sync' for now, but obviously that doesn't help with future changes to these headers. Defining a process for updating those headers would be useful. I'll send patches separately.
On Wed, 2009-04-29 at 11:31 +0300, Avi Kivity wrote: > Hollis Blanchard wrote: > >> Since PPC is now supported in upstream QEMU, does it really matter if it > >> works in qemu-kvm.git? > >> > > > > I was going to take that position too, except Avi asked me specifically > > if some of the code inside TARGET_I386 ifdefs in qemu-kvm.c works for > > other architectures. > > In that case it's sufficient to have the build system use the upstream > kvm integration (CONFIG_KVM) rather than the qemu-kvm integration (USE_KVM). OK, I give up... how is this supposed to work? Nobody ever sets CONFIG_KVM or KVM_UPSTREAM, but there are a couple tests for it. Glauber once sent a patch related to that, but I don't see how it helps. For reference, the actual error is about a hundred instances of e.g. /home/hollisb/source/qemu-kvm.git/vl.c:3393: undefined reference to `kvm_allowed'
Hollis Blanchard wrote: > On Wed, 2009-04-29 at 11:29 +0300, Avi Kivity wrote: > >> >>> * configure completely ignores --kerneldir and only uses >>> kvm/kernel headers instead. >>> >>> >> That's intentional. >> > > Huh? If --kerneldir does nothing, why does it exist? > BTW Avi, if you intend on carrying the KVM kernel headers in qemu-kvm, I see no strong reason not to do the same in QEMU. I'd like to move them from kvm/kernel/include to kvm/include. I'm open to suggestion actually. How often do you intend on updating the headers? Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Anthony Liguori wrote: > Hollis Blanchard wrote: >> On Wed, 2009-04-29 at 11:29 +0300, Avi Kivity wrote: >> >>> >>>> * configure completely ignores --kerneldir and only uses >>>> kvm/kernel headers instead. >>>> >>> That's intentional. >>> >> >> Huh? If --kerneldir does nothing, why does it exist? >> > > BTW Avi, if you intend on carrying the KVM kernel headers in qemu-kvm, > I see no strong reason not to do the same in QEMU. That's the plan. > > I'd like to move them from kvm/kernel/include to kvm/include. I'm > open to suggestion actually. > > How often do you intend on updating the headers? For qemu-kvm.git, as often as they're updated in kvm.git. For qemu.git, every major Linux release. This way we don't commit to an ABI which may change.
Hollis Blanchard wrote: >> In that case it's sufficient to have the build system use the upstream >> kvm integration (CONFIG_KVM) rather than the qemu-kvm integration (USE_KVM). >> > > OK, I give up... how is this supposed to work? Nobody ever sets > CONFIG_KVM or KVM_UPSTREAM, but there are a couple tests for it. Glauber > once sent a patch related to that, but I don't see how it helps. > KVM_UPSTREAM is just a marker to let us know which parts of upstream qemu/kvm integration conflict with qemu-kvm.git.
Hollis Blanchard wrote: >>> >>> >> They were generated by the old 'make sync' to remove CONFIG_ >> dependencies. I guess a better way to generate them is a 'make >> headers-install' from the kernel tree and grab the results. >> > > 'make headers_install' only produces include/asm/kvm.h, which apparently > is not sufficient. > That's a bug then. People should be able to use kvm without copying and hacking headers from the kernel source tree. > I can use output from an old 'make sync' for now, but obviously that > doesn't help with future changes to these headers. Defining a process > for updating those headers would be useful. > I plan to setup a script for that (basically an updated make sync).
Hollis Blanchard wrote: > On Wed, 2009-04-29 at 11:29 +0300, Avi Kivity wrote: > >> >>> * configure completely ignores --kerneldir and only uses >>> kvm/kernel headers instead. >>> >>> >> That's intentional. >> > > Huh? If --kerneldir does nothing, why does it exist? > --kerneldir predates the inclusion of headers in qemu-kvm.git.
On Fri, May 01, 2009 at 04:23:45PM -0500, Hollis Blanchard wrote: > I can use output from an old 'make sync' for now, but obviously that > doesn't help with future changes to these headers. Defining a > process for updating those headers would be useful. Two thumbs up. People doing kvm development which is not-quite-yet ready for upstream inclusion will appreciate having a way of keeping their (changed) kernel headers in sync with the userspace bits as transparently as possible. Cheers, Muli
On Sat, 2009-05-02 at 10:52 +0300, Avi Kivity wrote: > Hollis Blanchard wrote: > >> In that case it's sufficient to have the build system use the upstream > >> kvm integration (CONFIG_KVM) rather than the qemu-kvm integration (USE_KVM). > >> > > > > OK, I give up... how is this supposed to work? Nobody ever sets > > CONFIG_KVM or KVM_UPSTREAM, but there are a couple tests for it. Glauber > > once sent a patch related to that, but I don't see how it helps. > > > > KVM_UPSTREAM is just a marker to let us know which parts of upstream > qemu/kvm integration conflict with qemu-kvm.git. OK, so where do I define KVM_UPSTREAM? Also, where do I define CONFIG_KVM? I would expect the configure script to do that, but apparently it does not.
diff --git a/configure b/configure index fc0fb9b..257cf02 100755 --- a/configure +++ b/configure @@ -816,6 +816,9 @@ case "$cpu" in i386 | x86_64) kvm_arch="x86" ;; + ppc) + kvm_arch="powerpc" + ;; *) kvm_arch="$cpu" ;;