Building a custom Xen hypervisor

[brettstahlman]

The User's Manual recommends using Petalinux to build the Xen kernel. I don't recall ever running Petalinux, so I'm assuming the xen.ub I've been using is a pre-compiled binary that ships with XZD. I need to customize Xen, but would prefer doing so without Petalinux: i.e., I'd prefer simply incorporating the Xen source into my project and configuring/building the standard Xen way. Is this possible, or does Petalinux contain some "secret sauce" that would be difficult to replace? If I can simply download and build the Xen source, what are the version constraints? I'm currently using the 2016.3 release of the Xilinx toolchain. If I do need to use Petalinux, is there an easy way to use it to build Xen only (and not Dom0 kernel, U-Boot, FSBL, etc...)?

Thanks,
Brett S.

[Nathan.Studer]

Xen is built as part of the 'petalinux-build' command.  If you want to customize Xen, you can delete the xen source code in the PetaLinux project and replace it with your own.  It is located at "components/apps/xen/xen-src".  

The other option is to cross compile Xen, which would be similar to step 5.3.7 in the manual except building the default target instead of 'dist-tools'.  With this option you would also have to add a u-boot header to the resulting Xen binary.

     Nate

[brettstahlman]

(10-05-2017, 06:20 PM)Nathan.Studer Wrote: Xen is built as part of the 'petalinux-build' command.  If you want to customize Xen, you can delete the xen source code in the PetaLinux project and replace it with your own.  It is located at "components/apps/xen/xen-src".  

The other option is to cross compile Xen, which would be similar to step 5.3.7 in the manual except building the default target instead of 'dist-tools'.  With this option you would also have to add a u-boot header to the resulting Xen binary.

     Nate

Ok. So IIUC, I should run 'petalinux-create' to create a new project (which will contain pristine Xen source code), then run 'petalinux-config' to configure, make my code modifications, then build with 'petalinux-build', after which, I should have a xen.ub I can substitute for the one I've been using. Correct?

Thanks,
Brett S.

---

(10-05-2017, 06:46 PM)brettstahlman Wrote:

(10-05-2017, 06:20 PM)Nathan.Studer Wrote: Xen is built as part of the 'petalinux-build' command.  If you want to customize Xen, you can delete the xen source code in the PetaLinux project and replace it with your own.  It is located at "components/apps/xen/xen-src".  

The other option is to cross compile Xen, which would be similar to step 5.3.7 in the manual except building the default target instead of 'dist-tools'.  With this option you would also have to add a u-boot header to the resulting Xen binary.

     Nate

Ok. So IIUC, I should run 'petalinux-create' to create a new project (which will contain pristine Xen source code), then run 'petalinux-config' to configure, make my code modifications, then build with 'petalinux-build', after which, I should have a xen.ub I can substitute for the one I've been using. Correct?

Thanks,
Brett S.

Actually, I was just reading about the "Bare Metal Guest" capability, and was wondering whether it might provide the capability I need without resorting to a customized Xen kernel. Is it possible to give a BMC read access to specific memory addresses (either guest-virtual or guest-physical) within an arbitrary DomU? I know there are inter-domain communication mechanisms (e.g., libvchan, grant tables), but what I'm interested in is not necessarily 2-way communication, but simply letting the BMC read a DomU's memory directly. Do you know whether this is possible?

Thanks,
Brett S.

[jarvis_roach]

Brett S.,

The "best" way is to use the grant table mechanism in Xen to share memory. The Xen Project has been looking at ways to automate that via the guest .cfg file, see https://lists.xen.org/archives/html/xen-...03242.html.

You can also use the iomem attribute in a guest's .cfg to give it arbitrary access to a memory location. However, you may need to play some other tricks with Xen and Linux (dom0) to keep them from using that memory location for other purposes (like kernel data structures). I've been able to do that by creating a hole in the "memory" node in the device tree, and adding a UIO device that maps in hole. Unfortunately, this has the side effect of being treated as DEVICE memory, so no unaligned access, caching, or pre-fetching. However, that approach would let you do simple messaging, albeit not at full DDR performance.