> From: Song, Jike
> Sent: Wednesday, January 20, 2016 5:00 PM
> >> BTW, that should be done in the 'bus' driver, right?
> >
> > I think you have some flexibility between the graphics driver and the
> > vfio-vgpu driver in where this is done. If we want vfio-vgpu to be
> > more generic, then vgpu device creation and management should probably
> > be done in the graphics driver and vfio-vgpu should be able to probe
> > that device and call back into the graphics driver to handle requests.
> > If it turns out there's not much for vfio-vgpu to share, ie. it's just
> > a passthrough for device specific emulation, then maybe we want a vfio-
> > intel-vgpu instead.
> >
>
> Good to know that.
Possibly let's 1st implement a vfio-intel-vgpu, since KVMGT is the only
customer of this design change. We can see how to better abstract
letter when there comes other vendor's vgpu support.
>
> >>
> >> Looks that things get more clear overall, with small exceptions.
> >> Thanks for the advice:)
> >
> > Yes, please let me know how I can help. Thanks,
> >
> > Alex
> >
>
> I will start the coding soon, will do :)
>
I would expect we can spell out next level tasks toward above
direction, upon which Alex can easily judge whether there are
some common VFIO framework changes that he can help.:-)
Thanks
Kevin
��.n��������+%������w��{.n�����o�^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
