Patchwork [V10,02/15] xen: Make xen build only on x86 target.

login
register
mail settings
Submitter Anthony PERARD
Date Feb. 2, 2011, 2:49 p.m.
Message ID <1296658172-16609-3-git-send-email-anthony.perard@citrix.com>
Download mbox | patch
Permalink /patch/81470/
State New
Headers show

Comments

Anthony PERARD - Feb. 2, 2011, 2:49 p.m.
From: Anthony PERARD <anthony.perard@citrix.com>

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Alexander Graf <agraf@suse.de>
---
 Makefile.objs   |    4 ----
 Makefile.target |    4 +++-
 configure       |    5 +----
 3 files changed, 4 insertions(+), 9 deletions(-)
Anthony Liguori - Feb. 24, 2011, 4:11 p.m.
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
>
Anthony PERARD - Feb. 24, 2011, 4:25 p.m.
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
Anthony Liguori - Feb. 24, 2011, 5:27 p.m.
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
Jan Kiszka - Feb. 24, 2011, 5:46 p.m.
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
Anthony Liguori - Feb. 24, 2011, 5:59 p.m.
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
>
>
Alexander Graf - March 11, 2011, 6:20 a.m.
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
Stefano Stabellini - March 11, 2011, 11:15 a.m.
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.

Patch

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