qemu-devel
[Top][All Lists]
Advanced

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

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


From: Chen, Tiejun
Subject: Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support
Date: Mon, 30 Jun 2014 15:24:58 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

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





reply via email to

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