GSoC'20 Interested Student: Adding support to Jailhouse Hypervisor

Jan Kiszka jan.kiszka at web.de
Mon Mar 30 11:15:38 UTC 2020


On 30.03.20 10:02, PRAKHAR BANSAL wrote:
> Hi Jan,
>
> On Sat, Mar 28, 2020 at 4:12 AM Jan Kiszka <jan.kiszka at web.de
> <mailto:jan.kiszka at 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?

With all non-root cells - the root cell will be occupied already (it
runs libvirt e.g.).

>
> 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.

Sure, please go ahead.

Jan

>
> 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.kiszka at web.de
>     <mailto:jan.kiszka at web.de>
>      > <mailto:jan.kiszka at web.de <mailto:jan.kiszka at 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
>      >
>





More information about the libvir-list mailing list