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

Re: [Xen-devel] [PATCH 2/3] qemu-xen-trad: Correctly expose PCH ISA bridge for IGD passthrough



It has been a long time, but Pasi reminded me to follow this up.
Here is my feedback to your concern:

On Fri, Feb 8, 2013 at 3:51 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 07.02.13 at 18:43, "G.R." <firemeteor@xxxxxxxxxxxxxxxxxxxxx> wrote:
>>>
>>> For one I wonder whether this is really _always_ correct. I.e.
>>> the device at 00:1f.0 always being an ISA bridge. Wouldn't it
>>> be better to mirror whatever the host device says?
>>>
>> From the Intel driver code, it's looking for an intel ISA bridge.
>
> That doesn't mean that it always will be.
Unless you can 100% simulate the HW, you have to rely on the known
protocol between driver && HW.
I agree that they may switch to different protocol some day, but I
don't think we have any better choice.

>
>> So your question would be should it be always at 00:1f.0.
>> So far it seems that it is.
>
> Same thing here. We ought to be careful, or else we risk to
> introduce issues that pretty hard to locate, debug, and fix.
Since most (if not all) recent intel chipsets in the market have ISA
bridge at address 00:1f.0, simulate one at the same address to the
guest won't be so bad, given the current protocol between driver &&
HW.
But I guess your concern is about the hard-coded '00:1f.0' address.
Yes, I agree that this is not beautiful at all.
I don't mind changing it to probe the ISA bridge from host. But I'm
not familiar with qemu at all, could you show me the API to achieve
this purpose?

Also, if we really care about doing the 'correct' thing, I think we
should get rid of the default ISA bridge provided by qemu -- currently
it requires extra patches to linux i915 driver to work around. Anyway
to achieve this purpose?

Thanks,
Timothy (Rui)

_______________________________________________
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®.