Hi Jan, Thanks for the reply!
I was only considering the command-line tool "code" for reference to the Jailhouse kernel API(ioctl calls) because I didn't find a documentation of the Jailhouse kernel APIs. For the second part as you mentioned that Jailhouse can only create cells with the constraints defined in the root cell configuration. I have a few questions regarding that. 1. Is there a way to know if Jailhouse is enabled on the host and get the root cell configuration(s) from Jailhouse through an API? This can be used while binding the libvirt to the Jailhouse hypervisor. 2. If Jailhouse is not enabled(again can we know this using some API) then, can libvirt enable/disable Jailhouse during the libvirt binding of the Jailhouse driver with a given set of Jailhouse cell configurations describing a complete partitioned system? 3. I was wondering, as you mentioned that libvirt driver should check for mismatch of the cell configuration with the root cell configuration, the question is, isn't that done by Jailhouse itself? If yes, then libvirt can just pass on the cell creation requests to Jailhouse and return the response to the user as it is, rather than driver doing any such mismatch check. -Prakhar On Thu, Mar 26, 2020 at 1:49 AM Jan Kiszka <jan.kis...@web.de> wrote: > Hi Prakhar, > > On 25.03.20 05:36, PRAKHAR BANSAL wrote: > > Hi Jan, > > > > Thanks for the reply. I looked deeper into the libvirt and Jailhouse > > source code and found following two things that seem relevant to the > > project I am interested in. > > > > - Libvirt driver interface at [libvirt.git] > > <https://libvirt.org/git/?p=libvirt.git;a=tree;hb=HEAD> / src > > <https://libvirt.org/git/?p=libvirt.git;a=tree;f=src;hb=HEAD> / driver.h > > < > https://libvirt.org/git/?p=libvirt.git;a=blob_plain;f=src/driver.h;hb=HEAD > > > > - Jailhouse tool, which is using the ioctl API of the Jailhouse, > > available at > > https://github.com/siemens/jailhouse/blob/master/tools/jailhouse.c. > > > > With the help of the above two, it looks like, a libvirt driver for the > > Jailhouse can be implemented. Let me know if I am moving in the right > > direction so far. > > From the Jailhouse perspective, it is important to not consider the > command line tool an interface anymore (like in the first prototype) but > build on top of the Linux driver API (ioctls, sysfs). There is already a > Python library which started to abstract this interface for > Jailhouse-internal use cases. However, I strongly suspect libvirt will > rather want a native binding. > > > > > I have been looking at the other libvirt driver implementations for > > hypervisors like HyperV and VMware to understand their implementation > > and learn from there. > > As Jailhouse is a static partitioning hypervisor without abstraction of > the underlying hardware, your starting point for the libvirt binding > should be a given set of Jailhouse cell configurations describing a > complete partitioned system. So rather than instantiating on demand a > domain (Jailhouse cell) with, say, a network adapter, the driver should > match a user request for a domain against the configuration set and use > what is there - or report the mismatch. What it could organize, though, > is interconnecting cells that have a (preconfigured) virtual network > link to the root cell. > > Due to this different concept, there will be no 1:1 mapping for > commodity hypervisor drivers to the Jailhouse scenario. Still, studying > what they do is useful and needed in order to understand what "normally" > happens and find a reasonable translation. This is probably the most > challenging part of the project. > > Jan >
