Hi Jan, On Sat, Mar 28, 2020 at 4:12 AM Jan Kiszka <jan.kis...@web.de> wrote:
> On 28.03.20 08:47, PRAKHAR BANSAL wrote: > > 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. > > Right, the IOCTL API is not documented so far. It is currently only used > inside the Jailhouse project. This needs to be formalized when there > shall be external users like a libvirt driver. > > That might be a nice small contribution task: Create some > Documentation/driver-interfaces.md that describes the IOCTLs along with > their parameter structures and that also includes the current > sysfs-entries.txt as a section. Then send this as patch here. I'll help > out when details are not clear from reading the code. > > Sure. I will do that. > > > > 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. > > Look at > > https://github.com/siemens/jailhouse/blob/master/Documentation/sysfs-entries.txt > for what is reported as runtime information. Full configurations can't > be read back at this point. This might be reconsidered in the light of > [1], but I wouldn't plat for that yet. > Ok, sure. I am looking into it. > > > > > 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? > > With the API above and a given configuration set, yes. The config set > would have to be provided to the libvirt driver in some to-be-defined > way (e.g. /etc/libvirt/jailhouse.conf -> /etc/libvirt/jailhouse/*.cell). > > Cool, got it. Thanks! > > > > 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. > > With matching I'm referring to a libvirt user request like "create a > domain with 2 CPUs", while there are no cells left that have more than > one CPU. Or "give the domain 1G RAM", and you need to find an available > cell with that much memory. Those are simple examples. A request that > states "connect the domain to the host network A" implies that a cell > has a shared-memory link to, say, the root cell that can be configured > to bridge this. But let's keep that for later and start as simple as > possible. > Do I need to match the libvirt user-requested cell config with only root cells or with all cells present at that time? I wanted to request you for a favor for the proposal as the deadline is approaching. Could I prepare a proposal for this project based on our discussion here and improve it later based on feedback comments after the deadline? I understand that I got late in starting on the project search and selection. Thanks, Prakhar > > Jan > > [1] > > https://groups.google.com/d/msgid/jailhouse-dev/CADiTV-1QiRhSWZnw%2BkHhJMO-BoA4sAcOmTkQE7ZWbHkGh3Jexw%40mail.gmail.com > > > > > -Prakhar > > > > On Thu, Mar 26, 2020 at 1:49 AM Jan Kiszka <jan.kis...@web.de > > <mailto: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 > > > >