[RFC,V2,6/6] xen: introduce xenpv-softmmu.mak

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 configure                         |    7 +++++--
 default-configs/xenpv-softmmu.mak |    2 ++
 2 files changed, 7 insertions(+), 2 deletions(-)
 create mode 100644 default-configs/xenpv-softmmu.mak

I realize now that patch #5 and #6 of this series feel through the
cracks. Could you please rebase and resend?

On Mon, 27 Jan 2014, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  configure                         |    7 +++++--
>  default-configs/xenpv-softmmu.mak |    2 ++
>  2 files changed, 7 insertions(+), 2 deletions(-)
>  create mode 100644 default-configs/xenpv-softmmu.mak
> 
> diff --git a/configure b/configure
> index 549b9cc..b713d93 100755
> --- a/configure
> +++ b/configure
> @@ -4391,7 +4391,7 @@ supported_xen_target() {
>      test "$xen" = "yes" || return 1
>      test "$target_softmmu" = "yes" || return 1
>      case "$target_name:$cpu" in
> -        i386:i386 | i386:x86_64 | x86_64:i386 | x86_64:x86_64)
> +        i386:i386 | i386:x86_64 | x86_64:i386 | x86_64:x86_64 | xenpv:*)
>              return 0
>          ;;
>      esac
> @@ -4538,6 +4538,9 @@ case "$target_name" in
>    ;;
>    unicore32)
>    ;;
> +  xenpv)
> +    TARGET_ARCH=xenpv
> +  ;;
>    xtensa|xtensaeb)
>      TARGET_ARCH=xtensa
>    ;;
> @@ -4567,7 +4570,7 @@ echo "TARGET_ABI_DIR=$TARGET_ABI_DIR" >> $config_target_mak
>  
>  if supported_xen_target; then
>      echo "CONFIG_XEN=y" >> $config_target_mak
> -    if test "$xen_pci_passthrough" = yes; then
> +    if test "$target_name" != "xenpv" -a "$xen_pci_passthrough" = yes; then
>          echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak"
>      fi
>  fi
> diff --git a/default-configs/xenpv-softmmu.mak b/default-configs/xenpv-softmmu.mak
> new file mode 100644
> index 0000000..773f128
> --- /dev/null
> +++ b/default-configs/xenpv-softmmu.mak
> @@ -0,0 +1,2 @@
> +# Default configuration for xenpv-softmmu
> +# Yes it is empty as we don't need to include any device emulation code
> -- 
> 1.7.10.4
>

On Fri, Jul 04, 2014 at 04:10:13PM +0100, Stefano Stabellini wrote:
> I realize now that patch #5 and #6 of this series feel through the
> cracks. Could you please rebase and resend?
> 

Hi Peter and Paolo

I would like to ask for your suggestion on how to move this forward.

The first few refactoring patches have been upstreamed.  These two
patches (and a dependency patch which is not included here) seem to be
the last missing bits to have QEMU binary for Xen on ARM.  We would
really like to find a way to upstream these changes and avoid forking.


Wei.

On Wed, 9 Jul 2014, Wei Liu wrote:
> On Fri, Jul 04, 2014 at 04:10:13PM +0100, Stefano Stabellini wrote:
> > I realize now that patch #5 and #6 of this series feel through the
> > cracks. Could you please rebase and resend?
> > 
> 
> Hi Peter and Paolo
> 
> I would like to ask for your suggestion on how to move this forward.
> 
> The first few refactoring patches have been upstreamed.  These two
> patches (and a dependency patch which is not included here) seem to be
> the last missing bits to have QEMU binary for Xen on ARM.  We would
> really like to find a way to upstream these changes and avoid forking.

Actually I don't think that this could cause any forking (at least in
upstream Xen) even if the patches are not accepted. But it would be nice
to have a smaller and lighter QEMU for ARM with just the PV backend.
Otherwise we'll have to run a big fat qemu-system-i386 even for ARM
guests, a bit overkill given that we only need the backends.