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)? 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. 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. On 18 June 2018 at 16:34, David Hildenbrand <david@xxxxxxxxxx> wrote: > On 16.06.2018 13:49, Ahmed Soliman wrote: >> Following up on these threads: >> - https://marc.info/?l=kvm&m=151929803301378&w=2 >> - http://www.openwall.com/lists/kernel-hardening/2018/02/22/18 >> >> I lost the original emails so I couldn't reply to them, and also sorry >> for being late, it was the end of semester exams. >> >> I was adviced on #qemu and #kernelnewbies IRCs to ask here as it will >> help having better insights. >> >> To wrap things up, the basic design will be a method for communication >> between host and guest is guest can request certain pages to be read >> only, and then host will force them to be read-only by guest until >> next guest reboot, then it will impossible for guest OS to have them >> as RW again. The choice of which pages to be set as read only is the >> guest's. So this way mixed pages can still be mixed with R/W content >> even if holds kernel code. >> >> I was planning to use KVM as my hypervisor, until I found out that KVM >> can't do that on its own so one will need a custom virtio driver to do >> this kind of guest-host communication/coordination, I am still >> sticking to KVM, and have no plans to do this for Xen at least for >> now, this means that in order to get it to work there must be a QEMU >> support our specific driver we are planning to write in order for >> things to work properly. >> >> The question is is this the right approach? or is there a simpler way >> to achieve this goal? >> > > Especially if you want to support multiple architectures in the long > term, virtio is the way to go. > > Design an architecture independent and extensible (+configurable) > interface and be happy :) This might of course require some thought. > > (and don't worry, implementing a virtio driver is a lot simpler than you > might think) > > But be aware that the virtio "hypervisor" side will be handled in QEMU, > so you'll need a proper QEMU->KVM interface to get things running. > > -- > > Thanks, > > David / dhildenb
