Just bumping this to see if there is any feedback, I haven't had a chance to review the latest quarterly drop yet but I'm eager to get the local Xen support working in a way that is inline with the maintainers' vision. 


On Thu, Aug 9, 2018 at 11:52 AM Brendan Kerrigan <brendank310@gmail.com> wrote:

Hello all,


I've put together an OpenEmbedded layer for building the components of gvt-g for Xen, located at:

It is currently untested outside of all the necessary components building, but I'll be working toward moving the project along to provide a minimal example of a working gvt-g distribution on Xen (perhaps KVM in the future also). While working on putting it together, I was getting some kernel build failures related to force pushing of amended commits on the topic/gvtg-xengt branch. If possible in the future, can this practice be avoided?

[Zhang, Xiong Y] no, it couldn’t be avoided. As topic/gvtg-xengt branch contain non-upstreamed xengt and live migration patch set,  upstream developer doesn’t know our non-upstreamed patch and developer’s new patch may conflict with us, then we have to refresh and reconstruct these non-upstreamed patch set and force update it to git hub.



Additionally, I'd like to offer to help bring the local dma-buf support (back?) to the Xen portion of the project, though I'd like to hear from the project owners what their plans are for that feature. Is the intention to bring VFIO/mdev support to Xen, or to do the support in a Xen specific way (adding ioctl and mmap handlers to the xengt MPT)? I don't have a real preference as to the approach, both have their pros and cons.

[Zhang, Xiong Y] It seems Xen community doesn’t have plan to import VFIO/mdev. So it is better to implement it in another way.



Brendan Kerrigan