| Message ID | 1296658172-16609-3-git-send-email-anthony.perard@citrix.com |
|---|---|
| State | New |
| Headers | show |
On 02/02/2011 08:49 AM, anthony.perard@citrix.com wrote: > From: Anthony PERARD<anthony.perard@citrix.com> > > Signed-off-by: Anthony PERARD<anthony.perard@citrix.com> > Acked-by: Alexander Graf<agraf@suse.de> > Is this really necessary? The advantage to building globally is that it keeps the code from getting unnecessary i386-isms. Regards, Anthony Liguori > --- > Makefile.objs | 4 ---- > Makefile.target | 4 +++- > configure | 5 +---- > 3 files changed, 4 insertions(+), 9 deletions(-) > > diff --git a/Makefile.objs b/Makefile.objs > index 93406ff..d91b9bc 100644 > --- a/Makefile.objs > +++ b/Makefile.objs > @@ -150,10 +150,6 @@ slirp-obj-y += slirp.o mbuf.o misc.o sbuf.o socket.o tcp_input.o tcp_output.o > slirp-obj-y += tcp_subr.o tcp_timer.o udp.o bootp.o tftp.o > common-obj-$(CONFIG_SLIRP) += $(addprefix slirp/, $(slirp-obj-y)) > > -# xen backend driver support > -common-obj-$(CONFIG_XEN) += xen_backend.o xen_devconfig.o > -common-obj-$(CONFIG_XEN) += xen_console.o xenfb.o xen_disk.o xen_nic.o > - > ###################################################################### > # libuser > > diff --git a/Makefile.target b/Makefile.target > index b0ba95f..db29e96 100644 > --- a/Makefile.target > +++ b/Makefile.target > @@ -206,7 +206,9 @@ QEMU_CFLAGS += $(VNC_JPEG_CFLAGS) > QEMU_CFLAGS += $(VNC_PNG_CFLAGS) > > # xen backend driver support > -obj-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o > +obj-$(CONFIG_XEN) += xen_backend.o xen_devconfig.o > +obj-$(CONFIG_XEN) += xen_console.o xenfb.o xen_disk.o xen_nic.o > +obj-i386-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o > > # Inter-VM PCI shared memory > obj-$(CONFIG_KVM) += ivshmem.o > diff --git a/configure b/configure > index 210670c..5a9121d 100755 > --- a/configure > +++ b/configure > @@ -1151,7 +1151,6 @@ int main(void) { xs_daemon_open(); xc_interface_open(); return 0; } > EOF > if compile_prog "" "$xen_libs" ; then > xen=yes > - libs_softmmu="$xen_libs $libs_softmmu" > else > if test "$xen" = "yes" ; then > feature_not_found "xen" > @@ -2674,9 +2673,6 @@ if test "$bluez" = "yes" ; then > echo "CONFIG_BLUEZ=y">> $config_host_mak > echo "BLUEZ_CFLAGS=$bluez_cflags">> $config_host_mak > fi > -if test "$xen" = "yes" ; then > - echo "CONFIG_XEN=y">> $config_host_mak > -fi > if test "$io_thread" = "yes" ; then > echo "CONFIG_IOTHREAD=y">> $config_host_mak > echo "CONFIG_THREAD=y">> $config_host_mak > @@ -3012,6 +3008,7 @@ case "$target_arch2" in > i386|x86_64) > if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then > echo "CONFIG_XEN=y">> $config_target_mak > + echo "LIBS+=$xen_libs">> $config_target_mak > fi > esac > case "$target_arch2" in >
On Thu, Feb 24, 2011 at 16:11, Anthony Liguori <anthony@codemonkey.ws> wrote: > Is this really necessary? The advantage to building globally is that it > keeps the code from getting unnecessary i386-isms. Nop, is not necessary, I add this patch after this mail: http://lists.nongnu.org/archive/html/qemu-devel/2010-12/msg00044.html
On 02/24/2011 10:25 AM, Anthony PERARD wrote: > On Thu, Feb 24, 2011 at 16:11, Anthony Liguori<anthony@codemonkey.ws> wrote: > >> Is this really necessary? The advantage to building globally is that it >> keeps the code from getting unnecessary i386-isms. >> > Nop, is not necessary, I add this patch after this mail: > http://lists.nongnu.org/archive/html/qemu-devel/2010-12/msg00044.html > Alex, do you feel strongly here? Regards, Anthony Liguori
On 2011-02-24 18:27, Anthony Liguori wrote: > On 02/24/2011 10:25 AM, Anthony PERARD wrote: >> On Thu, Feb 24, 2011 at 16:11, Anthony Liguori<anthony@codemonkey.ws> wrote: >> >>> Is this really necessary? The advantage to building globally is that it >>> keeps the code from getting unnecessary i386-isms. >>> >> Nop, is not necessary, I add this patch after this mail: >> http://lists.nongnu.org/archive/html/qemu-devel/2010-12/msg00044.html >> > > Alex, do you feel strongly here? I'm not Alex, but I brought this issue up: Either build xen bits once for all archs or restrict it to the only foreseeable arch with support in qemu. But please don't built it for each and every target separately. BTW: > index b0ba95f..db29e96 100644 > --- a/Makefile.target > +++ b/Makefile.target > @@ -206,7 +206,9 @@ QEMU_CFLAGS += $(VNC_JPEG_CFLAGS) > QEMU_CFLAGS += $(VNC_PNG_CFLAGS) > > # xen backend driver support > -obj-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o > +obj-$(CONFIG_XEN) += xen_backend.o xen_devconfig.o > +obj-$(CONFIG_XEN) += xen_console.o xenfb.o xen_disk.o xen_nic.o > +obj-i386-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o Why restricting the last line to i386? Doesn't CONFIG_XEN also control here if the arch is xen-capable? Thanks, Jan
On 02/24/2011 11:46 AM, Jan Kiszka wrote: > On 2011-02-24 18:27, Anthony Liguori wrote: > >> On 02/24/2011 10:25 AM, Anthony PERARD wrote: >> >>> On Thu, Feb 24, 2011 at 16:11, Anthony Liguori<anthony@codemonkey.ws> wrote: >>> >>> >>>> Is this really necessary? The advantage to building globally is that it >>>> keeps the code from getting unnecessary i386-isms. >>>> >>>> >>> Nop, is not necessary, I add this patch after this mail: >>> http://lists.nongnu.org/archive/html/qemu-devel/2010-12/msg00044.html >>> >>> >> Alex, do you feel strongly here? >> > I'm not Alex, but I brought this issue up: > > Either build xen bits once for all archs or restrict it to the only > foreseeable arch with support in qemu. But please don't built it for > each and every target separately. > Oh yes, I misunderstood. I thought we had previously built it for all architectures. Yes, we should only build it once. Regards, Anthony Liguori > BTW: > > >> index b0ba95f..db29e96 100644 >> --- a/Makefile.target >> +++ b/Makefile.target >> @@ -206,7 +206,9 @@ QEMU_CFLAGS += $(VNC_JPEG_CFLAGS) >> QEMU_CFLAGS += $(VNC_PNG_CFLAGS) >> >> # xen backend driver support >> -obj-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o >> +obj-$(CONFIG_XEN) += xen_backend.o xen_devconfig.o >> +obj-$(CONFIG_XEN) += xen_console.o xenfb.o xen_disk.o xen_nic.o >> +obj-i386-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o >> > Why restricting the last line to i386? Doesn't CONFIG_XEN also control > here if the arch is xen-capable? > > Thanks, > Jan > >
On 24.02.2011, at 18:59, Anthony Liguori wrote: > On 02/24/2011 11:46 AM, Jan Kiszka wrote: >> On 2011-02-24 18:27, Anthony Liguori wrote: >> >>> On 02/24/2011 10:25 AM, Anthony PERARD wrote: >>> >>>> On Thu, Feb 24, 2011 at 16:11, Anthony Liguori<anthony@codemonkey.ws> wrote: >>>> >>>> >>>>> Is this really necessary? The advantage to building globally is that it >>>>> keeps the code from getting unnecessary i386-isms. >>>>> >>>>> >>>> Nop, is not necessary, I add this patch after this mail: >>>> http://lists.nongnu.org/archive/html/qemu-devel/2010-12/msg00044.html >>>> >>>> >>> Alex, do you feel strongly here? >>> >> I'm not Alex, but I brought this issue up: >> >> Either build xen bits once for all archs or restrict it to the only >> foreseeable arch with support in qemu. But please don't built it for >> each and every target separately. >> > > Oh yes, I misunderstood. I thought we had previously built it for all architectures. Yes, we should only build it once. There's really no point in building it for anything but x86. Xen has never had been broadly used in PV mode on non-x86. Not sure ports even exist. Alex
On Fri, 11 Mar 2011, Alexander Graf wrote: > > On 24.02.2011, at 18:59, Anthony Liguori wrote: > > > On 02/24/2011 11:46 AM, Jan Kiszka wrote: > >> On 2011-02-24 18:27, Anthony Liguori wrote: > >> > >>> On 02/24/2011 10:25 AM, Anthony PERARD wrote: > >>> > >>>> On Thu, Feb 24, 2011 at 16:11, Anthony Liguori<anthony@codemonkey.ws> wrote: > >>>> > >>>> > >>>>> Is this really necessary? The advantage to building globally is that it > >>>>> keeps the code from getting unnecessary i386-isms. > >>>>> > >>>>> > >>>> Nop, is not necessary, I add this patch after this mail: > >>>> http://lists.nongnu.org/archive/html/qemu-devel/2010-12/msg00044.html > >>>> > >>>> > >>> Alex, do you feel strongly here? > >>> > >> I'm not Alex, but I brought this issue up: > >> > >> Either build xen bits once for all archs or restrict it to the only > >> foreseeable arch with support in qemu. But please don't built it for > >> each and every target separately. > >> > > > > Oh yes, I misunderstood. I thought we had previously built it for all architectures. Yes, we should only build it once. > > There's really no point in building it for anything but x86. Xen has never had been broadly used in PV mode on non-x86. Not sure ports even exist. > There is an ia64 port available, but restricting xen to x86 makes sense at least for the moment. BTW qemu is mainly used in HVM mode on xen, but considering that cpu emulation is not needed, qemu x86 would probably work for the ia64 case too: this is how qemu-xen is used on ia64 at the moment, even though in the qemu-xen case xen is not an accelerator but a new target with a set of hardware devices very similar to x86.
diff --git a/Makefile.objs b/Makefile.objs index 93406ff..d91b9bc 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -150,10 +150,6 @@ slirp-obj-y += slirp.o mbuf.o misc.o sbuf.o socket.o tcp_input.o tcp_output.o slirp-obj-y += tcp_subr.o tcp_timer.o udp.o bootp.o tftp.o common-obj-$(CONFIG_SLIRP) += $(addprefix slirp/, $(slirp-obj-y)) -# xen backend driver support -common-obj-$(CONFIG_XEN) += xen_backend.o xen_devconfig.o -common-obj-$(CONFIG_XEN) += xen_console.o xenfb.o xen_disk.o xen_nic.o - ###################################################################### # libuser diff --git a/Makefile.target b/Makefile.target index b0ba95f..db29e96 100644 --- a/Makefile.target +++ b/Makefile.target @@ -206,7 +206,9 @@ QEMU_CFLAGS += $(VNC_JPEG_CFLAGS) QEMU_CFLAGS += $(VNC_PNG_CFLAGS) # xen backend driver support -obj-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o +obj-$(CONFIG_XEN) += xen_backend.o xen_devconfig.o +obj-$(CONFIG_XEN) += xen_console.o xenfb.o xen_disk.o xen_nic.o +obj-i386-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o # Inter-VM PCI shared memory obj-$(CONFIG_KVM) += ivshmem.o diff --git a/configure b/configure index 210670c..5a9121d 100755 --- a/configure +++ b/configure @@ -1151,7 +1151,6 @@ int main(void) { xs_daemon_open(); xc_interface_open(); return 0; } EOF if compile_prog "" "$xen_libs" ; then xen=yes - libs_softmmu="$xen_libs $libs_softmmu" else if test "$xen" = "yes" ; then feature_not_found "xen" @@ -2674,9 +2673,6 @@ if test "$bluez" = "yes" ; then echo "CONFIG_BLUEZ=y" >> $config_host_mak echo "BLUEZ_CFLAGS=$bluez_cflags" >> $config_host_mak fi -if test "$xen" = "yes" ; then - echo "CONFIG_XEN=y" >> $config_host_mak -fi if test "$io_thread" = "yes" ; then echo "CONFIG_IOTHREAD=y" >> $config_host_mak echo "CONFIG_THREAD=y" >> $config_host_mak @@ -3012,6 +3008,7 @@ case "$target_arch2" in i386|x86_64) if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then echo "CONFIG_XEN=y" >> $config_target_mak + echo "LIBS+=$xen_libs" >> $config_target_mak fi esac case "$target_arch2" in