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

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



On 2014/7/2 23:27, Michael S. Tsirkin wrote:
On Wed, Jul 02, 2014 at 03:15:02PM +0000, Ross Philipson wrote:
-----Original Message-----
From: Paolo Bonzini [mailto:pbonzini@xxxxxxxxxx]
Sent: Wednesday, July 02, 2014 7:33 AM
To: Ross Philipson; Michael S. Tsirkin; Stefano Stabellini
Cc: peter.maydell@xxxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxx; Allen M.
Kay; Kelly.Zytaruk@xxxxxxx; qemu-devel@xxxxxxxxxx;
yang.z.zhang@xxxxxxxxx; anthony@xxxxxxxxxxxxx; Anthony Perard; Chen,
Tiejun
Subject: Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough
support

Il 01/07/2014 19:39, Ross Philipson ha scritto:

We do IGD pass-through in our project (XenClient). The patches
originally came from our project. We surface the same ISA bridge and
have never had activation issues on any version of Widows from XP to
Win8. We do not normally run server platforms so I can't say for sure
there.

The problem is not activation, the problem is that the patches are
making assumptions on the driver and the firmware that might work today
but are IMHO just not sane.

Sure I don't think anybody is suggesting that activation is
the main problem. It was just a potential problem with respect
to one of the proposed solutions.

When we first started doing this (back in 2009ish) we ran into
all these problems with surfacing ISA bridges, giving guest
drivers access to registers in the host bridge. etc. Nothing seemed
sane; I sympathize.

At some level, maybe Paolo is right.  Ignore existing drivers and ask
intel developers to update their drivers to do something sane on
hypervisors, even if they do ugly things on real hardware.

A simple proposal since what I wrote earlier though apparently wasn't
very clear:

   Detect Xen subsystem vendor id on vga card.
   If there, avoid poking at chipset. Instead
        - use subsystem device # for card type
        - use second half of BAR0 of device
        - instead of access to pci host

hypervisors will simply take BAR0 and double it in size,
make second part map to what would be the pci host.

Tiejun, is there a chance this can be done not only
on Linux but on windows as well?

MST,

Looks this is paravirtualizaed way, right?

I can post this requirement to check but please make sure I really understand what you mean,

#1 We need to define a new Xen subsystem vendor id and emulate this value on vga card

#2 Native driver need to do:

* if the subsystem id on vga is that emulated XEN subsystem id, the native driver can get all necessary access including PCI host bridge at 0.0 and ISA bridge at 1f.0 from second half of that emulated BAR0 double the real size.

Right? If yes, I'd like to ask them.

But question is how to walk from PCI config on PCI host to BAR0 on VGA:

        dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));

        pci_write/read_config_dword(dev_priv->bridge_dev,,,)

Thanks
Tiejun




I would have no problem with a clean patchset that adds a new machine
type and doesn't touch code in "-M pc", but it looks like mst disagrees.
   Ultimately, if a patchset is too hacky for upstream, you can include
it in your downstream XenClient (and XenServer) QEMU branch.  It
happens.

Paolo

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date:
06/30/14


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