Skip to content

OpenXT Task List

Jump to bottom Edit New page
Ross Philipson edited this page Feb 18, 2015 · 31 revisions

Task List - A Starting Point

This is a first cut of putting together a task list of things that need to get done or we would like to get done. Each top level item may has a sub-list of smaller tasks listed. Many of these items were on other people's lists too (others involved in the OpenXT project). I am not including effort/time estimates or trying to prioritize these items at this time. I started it here on this wiki so it can be discussed, modified, added to, etc. Eventually we would want to get these items into Jira (and the details of how to do that may need discussion also). I did not use a table because they are not very friendly when using the Github wikis. Please feel free to edit...

List

Update TBOOT

Our current TBOOT if quite old. It needs a serious upgrade to the latest. This would be an ongoing task as new TBOOT versions are released. Update schedules would have to be carefully planned.

  • Update to the newest TBOOT.
  • Clean up the patch queue and upstream patches where possible.
  • Update TPM tools and remove custom ones (Phil knows about this).
  • Patch for CVE-2014-5118

Update Xen

We would like to track upstream as closely as possible and minimize our patch queue. This would be an ongoing task as new Xen versions are released. Update schedules would have to be carefully planned.

  • First move to Xen 4.3.x (is 4.3.3 the latest?)
  • Update to Xen 4.5 (or newer).
  • Clean up the patch queue and upstream patches where possible.
  • Get rid of unneeded patches, old functionality, etc.

Update Dom0 Kernel

Again, we would like to track upstream as closely as possible and minimize our patch queue. This would be an ongoing task as new Kernel versions are released or new hardware support is needed. Update schedules would have to be carefully planned.

  • Update to latest reasonable Linux 3.x. Maybe stick with LTS ones?
  • Download from kernel.org and don't use Ubuntu kernels (like linux-3.11.10.4.tar.gz).
  • Move to 64b kernel?
  • Clean up the patch queue.

Update QEMU

Currently OpenXT is moving to 1.4. The next step would be to move even further upstream. This might not be as regular a move as with Xen or Linux.

  • Finish move to 1.4 (in progress).
  • Get rid of unneeded patches, old functionality, etc.
  • TODO other items here?

Open Embedded Enhancements

Moving to a new OE and using layers. TODO leaving mostly for others to fill in.

  • Update OE to "dizzy"
  • Remove/eliminate redundant recipes that conflict/overlap with upstream
  • Upstream recipes that aren't openxt-specific package but might find a good home in another upstream layer.
  • Uprev bitbake & upstream/eliminate bitbake patches/classes where possible.
  • Simplify do_build.sh, finding what solutions the OE community use to the work done in it and adopting or innovating in OE where possible.
  • Look at moving back to the standard OE approach of referencing the openxt repositories by commit ID and secure content hash rather by branch. As well as making OpenXT less unusual this would make versioning simpler since you'd need to consider versions in many fewer repositories which makes consistent updates to OpenXT easier (get your work merged into central repositories and then later get the updates made to openxt's OE recipes to move standard builds over to it). We'd still need good workflows for developers to test their changes to OpenXT specific components.
  • Create a layer repo for each of the major patch queues (undo the big move of all the pq repos into xenclient-oe).

PV USB

This is a blanket item to cover all the PV USB work. Some of the specifics...

  • Stabilize the new PV USB solution in OpenXT (in progresss)
  • Create a Linux front end driver (in progress)
  • Upstream the drivers into Linux and the XenServer Windows PV drivers.
  • Upstream usbback into Xen.
  • USB 3

Dependencies: XenServer PV Windows Drivers

XenServer PV Windows Drivers

The current PV driver set is a very old version of the XenServer drivers. People on the XenServer and platform teams at Citrix did a huge amount of work to open source the latest XenServer drivers and it seems they are becoming the industry standard: https://github.com/xenserver

  • Integrate the XenServer PV Windows drivers into OpenXT (building/packaging/etc).
  • Make OpenXT additional drivers work with the XenServer drivers (esp. xenbus).
  • Modification to the SDK Windows bits to use the new XenServer drivers.

OpenXT PV Linux Drivers

For historic reasons, XT has its own set of PV Linux drivers for use in HVM guests. These include XT only drivers like xc-v4v, xc-audo and xc-vusb. It also includes duplicate xenbus, xc-blkfront and xc-netfront. Since this later set has fully functioning counterparts in modern PVOPS kernels, they are not needed.

  • Get rid of the duplicate drivers.
  • Re-base the remaining drives on PVOPS xenbus.

UEFI Support

There may come a time when we see vendors begin to not support CSMs in their UEFI firmware any longer. OpenXT needs to be prepared for that. This mainly means supporting UEFI booting through GRUB2 using multiboot2 structures. For OpenXT this means TBOOT, Xen and Dom0 must have these new multiboot2 capabilities. It also means supporting GPT partitioning.

  • Updated TBOOT with multiboot2/EFI support.
  • Updated Xen with multiboot2/EFI support.
  • Ensure Dom0 kernel support for multiboot2/EFI.
  • Installer changes for supporting GPT.
  • Platform changes for supporting GPT.

Dependencies: Update TBOOT, Update Xen

Toolsack Core Changes

This seems like a very broad item but here it is specifically addressing the core pieces like xenmgr->xenvm->libxc.

  • Documentation! Especially the Haskell and OCaml bits. This will help in making some of the other decisions.
  • The future of the Ocaml code and moving to libxl (or something else).
  • Investigations into how well libxl scales.
  • The future of the Haskell code and what to do with xenmgr and friends.
  • Domain startup is tricky ... qemu-wrapper/dm-agent/svirt/.../qemu. We should do something about that (documentation at least).

Dependencies: Everything

Graphics Stack

This is the Display Handler project introducing a whole new graphics architecture.

  • RFC post for review.
  • XenGT/GVT-g plan for OpenXT
  • TODO leaving this for others to fill in.

Dependencies: Input Server Changes, PV USB, Superhid

Input Server Changes

The input server definitely needs a major overhaul and may need a complete redoing (to be seen).

  • First need a specification or RFC document as a starting point.
  • Using libinput was brought up as a possibility.
  • Changes to support new graphics stack.

Dependencies: Graphics Stack

Superhid

Superhid introduces a whole new way of creating virtual USB devices in guests, allowing guests to use native drivers and software to do all the standard HID business.

  • RFC post for review.
  • TODO more on this.

Dependencies: PV USB, Graphics Stack

Interdomain Communications

We have V4V currently. Do we push forward with it and fix it or consider another approach like one of the grant models. Note that V4V will never be upstreamed into Xen so this is a rather largish nail in the coffin.

  • RFC and discussions on how to proceed.
  • Possibly fixing V4V. This would also mean porting the Windows driver to the XenServer xenbus.
  • Fixing V4V also entails addressing issues that came up during the open source effort as well as known bugs.
  • V4V should have a socket class too.
  • Possibly using a grant model like libvchan. This would require writing a lot of new stuff.

Dependencies: XenServer PV Windows Drivers

Standardize RPC Communications

OpenXT currently has multiple RPC mechanisms and no real standards for interfaces and proxies etc.

  • DBus/DMBus, keep both move to just one of them? (DMBus and DBus overlap most of the time...)
  • Some DBus messages should be DMBus unless we decide to drop DMBus.
  • Bouncers & proxies should have libraries with interface handling and be consistent.
  • Statically linked binaries in stubdoms contributes to this mess and is unnecessary.

Audio Improvements

Really kind of a general bucket for audio related tasks and issues.

  • We don't even have PV audio support. We should.
  • Audio microphone.

BVT Automated Tests

The original BVT automated test framework was also pushed to open source under the openxt-extras organization. Good automated tests may be key to success of the overall project.

  • Improvements to the existing framework (in progress)
  • Deployment/integration within a larger build infrastructure.
  • Engineering participation in test writing.

Sync XT Improvements

  • implement postgresql as an alternative (or replacement if we can do migration?) to the use of the Oracle RDBMS.
  • selinux policy for the server
  • selinux policy for the client syncvm
  • an open source web interface for SyncXT

vTPM Integration

Adopting the vTPM work done in Xen and elsewhere in OpenXT.

  • Basic integration with existing vTPM solutions.
  • TODO and beyond that
  • TODO remote attestation, realm support, etc.

Documentation

OpenXT needs a plan for documentation. Currently there are just a bunch of PDFs pushed out in the open source effort.

  • What tools etc do we use to edit and maintain documentation.
  • Mechanisms for ensuring documentation is kept up to date and ready for eventual OpenXT release cycles.
  • Proper READMEs in the repos to explain what is in them.
Add a custom footer
Add a custom sidebar
Clone this wiki locally