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