[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 Thu, Jun 26, 2014 at 01:30:42PM +0200, Paolo Bonzini wrote:
> Il 26/06/2014 13:26, Michael S. Tsirkin ha scritto:
> >On Thu, Jun 26, 2014 at 12:03:58PM +0200, 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.
> >>
> >>Paolo
> >
> >I think v5 goes a bit overboard and overrides too many registers,
> >driver likely needs much less.
> >
> >But IMHO retro-fitting this into PIIX is where the problem is.
> >We could invent 1000 ways to do this, all of varying levels of
> >ugliness.
> >
> >But why don't we start by more or less cleanly emulating what the driver
> >needs?  If we start with Q35 - it shouldn't be hard to tweak it's MCH to
> >add the necessary config space, right?
> >
> >I know xen doesn't support q35 now but it's opensource :)
> >
> >I think that's a good step 1. We can do PV hacks on top if we
> >decide they aren't too painful.
> I don't think it's a PV hack.  It should be this way in real hardware too

But it isn't.

> (not exactly _this_ hack, but at least no improper relationship among

Well that dependency between devices is common for embedded hardware,
and this is what we have here.

> Once you add nested virtualization and nested device assignment to the mix,
> hacking subsystem IDs simply does not scale.
> Paolo

I'm not talking about subsystem id either, I'm talking about
closely emulating the physical system that driver expects.
In particular this definitely means not starting with PIIX :)


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.