Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

["Chen, Tiejun" <tiejun.chen@intel.com>]

On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>
>>>>>
>>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>>
>>>>
>>>> Are you saying the config space in the video device?
>>>
>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>> MMIO BAR.
>>>
>>
>> As I mentioned previously, the IGD guy told me we have no any unused a
>> offset or BAR in the config space.
>>
>> And guy who are responsible for the native driver seems not be accept to
>> extend some magic offset of an existing MMIO BAR.
>>
>> In addition I think in a short time its not possible to migrate i440fx to
>> q35 as a PCIe machine of xen.
>
> That seems like a weak motivation.  I don't see a need to get something
> merged upstream in a short time: this seems sure to miss 2.1,
> so you have the time to make it architecturally sound.
> "Making existing guests work" would be a better motivation.

Yes.

> Isn't this possible with an mch chipset?

If you're saying q35, I mean AFAIK we have no any plan to migrate to 
this MCH in xen case. Additionally, I think I should follow this feature 
after q35 can work for xen scenario.

>
>
>> So could we do this step by step:
>>
>> #1 phase: We just cover current qemu-xen implementation based on i44fx, so
>> still provide that pseudo ISA bridge at 00:1f.0 as we already did.
>
> By the way there is no reason to put it at 00:1f.0 specifically I think.
> So it seems simple: create a dummy device that gets device and
> vendor id as properties. If you really like, add an option to get values

Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx 
passthrough: create pseudo intel isa bridge. There, we fake this device 
just at 00:1f.0.

But you guys don't like this, and shouldn't this be just this point we 
discussing now?

If you guys agree that , everything is fine.

> from sysfs: device and vendor id are world readable, so just get them
> directly and not through xen wrappers, this way you can open the files
> RO and not RW.
> You seem to poke at revision as well, I don't see
> driver looking at that - strictly necessary?
> If yes please patch host kernel to expose that info in sysfs,
> though we can fall back on pci config if not there.
>
> MCH (bridge_dev) hacks in i915 are nastier.
> To clean them up, we really have to have an explicit driver for this
> bridge, not a pass-through device.  Long term, the right thing to do is
> likely to extend host driver and expose the necessary information in
> sysfs on host kernel.
>
>

I'm a bit confused. Any sysfs should be filled by the associated PCIe 
device, shouldn't it? So qemu still need to emulate this PCIe device 
firstly, then set properties into sysfs.

>
>
>> #2 phase: Now, we will choose a capability ID that won't be conflicting with
>> others. To do this properly, we need to get one from PCI SIG group. To have
>> this workable and consistently validated, this method shouldn't be virt
>> specific. Then native driver should use the same method.
>
> You mean you will be able to talk sense into hardware guys?
> I doubt that. If they could be convinced to make e.g. i915 base a

We're negotiating this, so this is just our long term solution we figure 
out currently.

> proper BAR, why didn't they?

We already have no any free BAR as we mentioned previously.

>
>
>> So when xen work on
>> q35 PCIe machine, we can walk this way.
>
> If you are emulating MCH anyway, pick one that is close
> to what i915 driver expects. It would then work with existing

Looks you guys prefer we create a new MCH anyway, right? But is it 
necessary to create a new based on i440fx just for a little change?

Thanks
Tiejun

> devices, without new capability IDs.
>
>
>> Anthony,
>>
>> Any comments to address this in xen case?
>>
>> Thanks
>> Tiejun
>
>