A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Wed, Jul 28, 2021 at 01:38:58PM +0000, Wang, Zhi A wrote: > Hi Jason: > > I guess those APIs you were talking about are KVM-only. For other > hypervisors, e.g. Xen, ARCN cannot use the APIs you mentioned. Not sure if > you have already noticed that VFIO is KVM-only right now. Please wrap your lines properly :( > GVT-g is designed for many hypervisors not only KVM. In the design, we > implemented an abstraction layer for different hypervisors. You can check the > link in the previous email which has an example of how the MPT module "xengt" > supports GVT-g running under Xen. > For example, injecting a msi in VFIO/KVM is via playing with eventfd. But in > Xen, we need to issue a hypercall from Dom0. So does others, like querying > mappings between GFN and HFN. Some GPU related emulation logic might be > implemented differently under different hypervisors because different > hypervisors might provide not exact the APIs we want. That's the reason why > they get a callback in the MPT (yet not perfect.) > > As you can see, to survive from this situation, we have to rely on an > abstraction layer so that we can prevent introducing coding blocks like in > the core logic: > > If (in_hypervisor_xen) > Issue hypercalls > else if (in_hypervisor_kvm) > Play with eventfds. > Else if (in_hypervisor_other) > xxxx That's horrid, and slow, please do this properly. > Thus some of the APIs have to be wrapped in the MPT module in GVT-g design. > > Sadly, not all customers are motivated or allowed to get their > hypervisor-specific modules into the kernel. We have a customer who runs > GVT-g with their private hypervisor. In this case, they don't want to get > their "xxxgt" MPT module into upstream since their hypervisor has been in the > kernel yet. Also, we have customers who ported the GVT-g to QNX which is > another widely used commercial hypervisor in the industry. They can't get the > "qnxgt" MPT module into upstream since it's not allowed. Why is it not allowed? > We do understand the situation and try to figure out a solution that can > fulfill expectations from different people in the community and also > customers. > > According to Greg KH's comments, we are collecting the requirements of MPT > modules from other open-source hypervisors in the kernel, e.g. ACRN, to see > if they can get another MPT module into the kernel, which will show an > example that how the MPT abstraction can benefit. Also, we are evaluating the > impact on our customers if we have to remove MPT abstraction in the kernel > because there is only one MPT module. Until that happens, can we please just remove the unneeded layer here as no one is using it? Then, when you have a real user for this type of middle-layer, you can add it back? We have no need for it now. thanks, greg k-h _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
