[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Qemu-devel] [RFC][PATCH 1/1] libxl: add one machine property to support IGD GFX passthrough



On Thu, Jan 29, 2015 at 08:41:24AM +0800, Chen, Tiejun wrote:
> On 2015/1/28 19:12, Wei Liu wrote:
> >On Wed, Jan 28, 2015 at 08:42:56AM +0800, Chen, Tiejun wrote:
> >>On 2015/1/27 22:40, Ian Jackson wrote:
> >>>Chen, Tiejun writes ("Re: [Qemu-devel] [RFC][PATCH 1/1] libxl: add one 
> >>>machine property to support IGD GFX passthrough"):
> >>>>On 2015/1/23 8:43, Chen, Tiejun wrote:
> >>>>>On 2015/1/22 8:51, Chen, Tiejun wrote:
> >>>>>>At this point I just concern here if we still use 'gfx_passthrou', at
> >>>>>>least it may look like a backward compatibility with older versions of
> >>>>>>qemu in Xen side, qemu-xen-traditional. But I'd like to follow your
> >>>>>>final option.
> >>>...
> >>>>>Any feedback to this option I should follow here?
> >>>>
> >>>>Ping...
> >>>
> >>>I think this is a question that qemu upstream should answer.
> >>>
> >>
> >>Actually this is just commented by Gerd in qemu upstream. So now looks in
> >>Xen side you guys don't have any objection to use 'igd-passthru' as well. If
> >>yes, I'm fine to adopt this.
> >>
> >
> >Yes, we would like to stay in line with upstream.
> 
> Wei,
> 
> Thanks for your response.
> 
> >
> >Just remember to handle old option in libxl if your old option is already
> >released by some older version of QEMUs.
> 
> I just drop that old option, -gfx_passthru, if we're under qemu upstream
> circumstance, like this,
> 

The question is, is there any version of qemu upstream that has
been released that has the old option (-gfx-passthru)?

This gives us a situation that we need to support both the old
(-gfx-passthru) and new (-igd-passthru) options. Presumably we (libxl)
would need to fork a qemu process to determine which option it has and
pass the right one.

Or you can try to keep both old and new option at the same time but
deprecate the old one. Then in a few qemu release cycles later (or
probably one year or two?) you can finally remove the old one. The point
is that to give downstream (in this case, Xen) time to cope with the
change.

> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -318,7 +318,10 @@ static char **
> libxl__build_device_model_args_old(libxl__gc *gc,
>              flexarray_vappend(dm_args, "-net", "none", NULL);
>          }
>          if (libxl_defbool_val(b_info->u.hvm.gfx_passthru)) {
> -            flexarray_append(dm_args, "-gfx_passthru");
> +            if (b_info->device_model_version !=
> +                LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
> +                flexarray_append(dm_args, "-gfx_passthru");
> +            }

I don't think this is right if upstream qemu also supports gfx-passthru.

However, you're modifying libxl__build_device_model_args_old, it
strongly suggests that it only affects qemu-trad. That means you don't
even need this patch...

Wei.

>          }
>      } else {
>          if (!sdl && !vnc)
> @@ -702,7 +705,10 @@ static char **
> libxl__build_device_model_args_new(libxl__gc *gc,
>              flexarray_append(dm_args, "none");
>          }
>          if (libxl_defbool_val(b_info->u.hvm.gfx_passthru)) {
> -            flexarray_append(dm_args, "-gfx_passthru");
> +            if (b_info->device_model_version !=
> +                LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
> +                flexarray_append(dm_args, "-gfx_passthru");
> +            }
>          }
>      } else {
>          if (!sdl && !vnc) {
> 
> Is this good enough?
> 
> Thanks
> Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.