qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [v3][PATCH 2/2] libxl: introduce gfx_passthru_kind


From: Ian Campbell
Subject: Re: [Qemu-devel] [v3][PATCH 2/2] libxl: introduce gfx_passthru_kind
Date: Fri, 27 Mar 2015 09:54:06 +0000

On Fri, 2015-03-27 at 09:29 +0800, Chen, Tiejun wrote:
> On 2015/3/26 18:06, Ian Campbell wrote:
> > On Thu, 2015-03-26 at 08:53 +0800, Chen, Tiejun wrote:
> >>> Hrm, OK. I suppose we can live with autodetect and igd both meaning igd
> >>> and whoever adds a new type will have to remember to add a check for
> >>> qemu-trad then.
> >>>
> >>
> >> When we really have to introduce a new type, this means we probably need
> >> to change something inside qemu codes. So a new type should just go into
> >> that table to support qemu upstream since now we shouldn't refactor
> >> anything in qemu-xen-traditional, right?
> >
> > We'd want to error out on attempts to use qemu-xen-trad with non-IGD
> > passthru.
> >
> 
> On qemu-xen-traditional side, we always recognize this as BOOLEAN,
> 
>          if (libxl_defbool_val(b_info->u.hvm.gfx_passthru)) { 
> 
>              flexarray_append(dm_args, "-gfx_passthru"); 
> 
>          }
> 
> Additionally, this is also clarified explicitly in manpage, and 
> especially we don't change this behavior now, so I'm just wondering why 
> we should do this :)

If someone does gfx_passthru = "foobar" and device_model_version =
"qemu-xen-traditional" in their xl config then it would be rather mean
of us to silently enable IGD passthru for them instead. When this occurs
libxl should notice and fail.

IGD is currently the only option, so this code would be needed when
someone adds "foobar" support.

Ian.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]