<div dir="ltr">Hi Jan,<div> </div><div>I have shared the draft proposal link with libvirt on GSoC's system.</div><div>Could you please check and provide your feedback, if possible.</div><div> </div><div>Thanks,</div><div>Prakhar</div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 31, 2020 at 1:47 AM Jan Kiszka <<a href="mailto:jan.kiszka@web.de">jan.kiszka@web.de</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On 31.03.20 04:43, PRAKHAR BANSAL wrote: > Hi Jan, > > Thanks for the confirmation to proceed on project proposal. > > Also, I tried installing Jailhouse on my VM after enabling VT-x/EPT and > IOMMU for my VM(Guest OS- Ubuntu 18.04) on VMware fusion hypervisor with > MacOS on the host side. > However, Jailhouse hardware check was failed because of missing > *Preemption timer and Virtualize APIC access*, could you please suggest, > if this is hardware limitation? Is there any workaround here? You will need a hypervisor that supports both when nesting, but I have no idea if there is one for the Mac. What is known to work is KVM on Linux hosts. > My laptop's processor is Intel quad-core i7. > > image.png > > Also, could you please suggest, if I can talk to you through an IRC or > slack channel since it is a bit hard to communicate over email every time. I'll be listening on #jailhouse, <a href="http://irc.freenode.net" rel="noreferrer" target="_blank">irc.freenode.net</a>. Jan > > Thanks, > Prakhar > > > On Mon, Mar 30, 2020 at 6:15 AM Jan Kiszka <<a href="mailto:jan.kiszka@web.de" target="_blank">jan.kiszka@web.de</a> > <mailto:<a href="mailto:jan.kiszka@web.de" target="_blank">jan.kiszka@web.de</a>>> wrote: > > On 30.03.20 10:02, PRAKHAR BANSAL wrote: > > Hi Jan, > > > > On Sat, Mar 28, 2020 at 4:12 AM Jan Kiszka <<a href="mailto:jan.kiszka@web.de" target="_blank">jan.kiszka@web.de</a> > <mailto:<a href="mailto:jan.kiszka@web.de" target="_blank">jan.kiszka@web.de</a>> > > <mailto:<a href="mailto:jan.kiszka@web.de" target="_blank">jan.kiszka@web.de</a> <mailto:<a href="mailto:jan.kiszka@web.de" target="_blank">jan.kiszka@web.de</a>>>> 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 > > > <a href="https://github.com/siemens/jailhouse/blob/master/Documentation/sysfs-entries.txt" rel="noreferrer" target="_blank">https://github.com/siemens/jailhouse/blob/master/Documentation/sysfs-entries.txt</a> > > 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] > > > <a href="https://groups.google.com/d/msgid/jailhouse-dev/CADiTV-1QiRhSWZnw%2BkHhJMO-BoA4sAcOmTkQE7ZWbHkGh3Jexw%40mail.gmail.com" rel="noreferrer" target="_blank">https://groups.google.com/d/msgid/jailhouse-dev/CADiTV-1QiRhSWZnw%2BkHhJMO-BoA4sAcOmTkQE7ZWbHkGh3Jexw%40mail.gmail.com</a> > > > > > > > > -Prakhar > > > > > > On Thu, Mar 26, 2020 at 1:49 AM Jan Kiszka > <<a href="mailto:jan.kiszka@web.de" target="_blank">jan.kiszka@web.de</a> <mailto:<a href="mailto:jan.kiszka@web.de" target="_blank">jan.kiszka@web.de</a>> > > <mailto:<a href="mailto:jan.kiszka@web.de" target="_blank">jan.kiszka@web.de</a> <mailto:<a href="mailto:jan.kiszka@web.de" target="_blank">jan.kiszka@web.de</a>>> > > > <mailto:<a href="mailto:jan.kiszka@web.de" target="_blank">jan.kiszka@web.de</a> <mailto:<a href="mailto:jan.kiszka@web.de" target="_blank">jan.kiszka@web.de</a>> > <mailto:<a href="mailto:jan.kiszka@web.de" target="_blank">jan.kiszka@web.de</a> <mailto:<a href="mailto:jan.kiszka@web.de" target="_blank">jan.kiszka@web.de</a>>>>> 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] > > > > > <<a href="https://libvirt.org/git/?p=libvirt.git;a=tree;hb=HEAD" rel="noreferrer" target="_blank">https://libvirt.org/git/?p=libvirt.git;a=tree;hb=HEAD</a>> / src > > > > > > <<a href="https://libvirt.org/git/?p=libvirt.git;a=tree;f=src;hb=HEAD" rel="noreferrer" target="_blank">https://libvirt.org/git/?p=libvirt.git;a=tree;f=src;hb=HEAD</a>> / > > > driver.h > > > > > > > > > > <<a href="https://libvirt.org/git/?p=libvirt.git;a=blob_plain;f=src/driver.h;hb=HEAD" rel="noreferrer" target="_blank">https://libvirt.org/git/?p=libvirt.git;a=blob_plain;f=src/driver.h;hb=HEAD</a>> > > > > - Jailhouse tool, which is using the ioctl API of the > > Jailhouse, > > > > available at > > > > > > <a href="https://github.com/siemens/jailhouse/blob/master/tools/jailhouse.c" rel="noreferrer" target="_blank">https://github.com/siemens/jailhouse/blob/master/tools/jailhouse.c</a>. > > > > > > > > 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 > > > > > > </blockquote></div>