On 18.06.2018 18:35, Ahmed Soliman wrote: > Shortly after I sent the first email, we found that there is another > way to achieve this kind of communication, via KVM Hypercalls, I think > they are underutilised in kvm, but they exist. > > We also found that they are architecture dependent, but the advantage > is that one doesn't need to create QEMU<-> kvm interface > > So from our point of view it is either have things easily compatible > with many architectures out of the box (virtio) VS compatiability with > almost every front end including QEMU and any other one without > modification (Hypercalls)? My gut feeling (I might of course be wrong) is that hypercalls will not be accepted easily in KVM (I assume only if it is really highly specialized for e.g. x86 and/or required very early during boot and/or has very specific performance requirements - e.g. pvspinlocks or kvmclock). > > If it is the case, We might stick to hypercalls at the beginning, > because it can be easily tested with out modifying QEMU, but then > later we can move to virtio if there turned out to be clearer > advantage, especially performance wise. hypercalls might be good for prototyping, but I assume that the challenging part will rather be a clean KVM mmu interface. And once you have that, a kernel interface might not be too hard (I remember some work being done by malwarebytes). > > Does that sounds like good idea? > I wanted to make sure because maybe maybe hypercalls aren't that much > used in kvm for a reason, so I wanted to verify that. I assume the same. Another thing to note is performance, having to go via QEMU might be performance wise not that good. (usually chunking is the answer to reduce the overhead). But if it is really a "protect once, forget until reboot" thing, that should not be relevant. -- Thanks, David / dhildenb _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
