qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Xen-devel] [v2][PATCH] libxl: add one machine property


From: Chen, Tiejun
Subject: Re: [Qemu-devel] [Xen-devel] [v2][PATCH] libxl: add one machine property to support IGD GFX passthrough
Date: Thu, 26 Feb 2015 14:35:42 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

On 2015/2/18 21:22, Ian Campbell wrote:
On Wed, 2015-02-11 at 10:45 +0800, Chen, Tiejun wrote:
On 2015/2/9 19:05, Ian Campbell wrote:
On Mon, 2015-02-09 at 14:28 +0800, Chen, Tiejun wrote:

What about this?

I've not read the code in detail,since I'm travelling but from a quick
glance it looks to be implementing the sort of thing I meant, thanks.

Thanks for your time.


A couple of higher level comments:

I'd suggest to put the code for reading the vid/did into a helper
function so it can be reused.

Looks good.


You might like to optionally consider add a forcing option somehow so
that people with new devices not in the list can control things without
the need to recompile (e.g. gfx_passthru_kind_override?). Perhaps that
isn't needed for a first cut though and it would be a libxl API so
thought required.

What about 'gfx_passthru_force'? Because what we're doing is, we want to
make sure if we have a such a IGD that needs to workaround by posting a
parameter to qemu. So in case of non-listed devices we just need to
provide a bool to force this regardless of that real device.


Sorry for this delay response due to our routine Chinese New Year.

If we are going to do this then I think we need to arrange for the
interface to be able to express the need to force the workarounds for a
particular device. IOW a boolean will not suffice since it doesn't
indicate that IGD workarounds are needed.

Probably it would be simplest to just leave this functionality out for
the time being and revisit if/when maintaining the list becomes an
annoyance or an end user trips over it.


You mean we should maintain one list to save all targeted devices, then tools uses ids as an index to lookup this list to pass something to qemu.

But actually one question that I have always been thinking about is, its really a responsibility of Xen to determine which device type should be passed by probing that pair of vendor and device ids? Xen is just one of so many approaches to qemu so such a rare workaround option can be passed actively by any user, instead of Xen. Furthermore, its becoming flexible as well to those cases we want to force overriding this.

So I think qemu should mainly plays this role. If qemu realizes we're passing through a IGD or other targeted device, it should post a warning or even error message to indicate what right behavior is needed, or what is that potential risk by default.

Thanks
Tiejun




reply via email to

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