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
I've put together an OpenEmbedded layer for building the components of gvt-g for Xen,
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
[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.