Difference between revisions of "Xen ARM TODO"

From Xen
 
(11 intermediate revisions by 5 users not shown)
Line 3: Line 3:
   
 
== In progress ==
 
== In progress ==
 
== Known Bugs ==
 
=== General ===
 
 
==== Domain 0 memory limitation due to 1:1 mapping ====
 
 
The use of the 1:1 workaround for dom0's memory (needed on platforms without an I/O SMMU, which is currently all) limits the maximum size of dom0. By carefully positioning the Xen and initial kernel/initrd/dtb binaries at the top of RAM dom0 is able to make use of up to 1/2 of the host RAM. The remainder is available for guest use. In general dom0 should be made quite small anyway. For more information see:
 
* http://lists.xen.org/archives/html/xen-devel/2013-12/msg02239.html
 
* http://lists.xen.org/archives/html/xen-devel/2014-01/msg00885.html
 
 
This should be addressed in a future release by supporting multiple memory banks for dom0.
 
 
=== Versatile Express ===
 
 
=== Arndale Board ===
 
   
 
== Open Work Items ==
 
== Open Work Items ==
   
 
{{Open Project
 
{{Open Project
|Project=vGIC interrupt prioritisation
+
|Project=Save/restore and migration
 
|Desc=
 
|Desc=
  +
Make VM save/restore and VM migration work on ARM.
Currently the vGIC only implements a very basic form of interrupt priority, in particular it is not able to preempt an inflight lower priority interrupt when a new higher priority one occurs. The emulation needs to consider the vCPUs current IAR as well as the priorities of pending and inflight interrupts.
 
  +
|References=An initial prototype was written a couple of years ago for arm32 but never completed: http://lists.xen.org/archives/html/xen-devel/2014-06/msg02076.html
 
}}
 
}}
   
 
{{Open Project
 
{{Open Project
|Project=VCPU virtual time support
+
|Project=PCI device assignment to DomUs
  +
|Desc=
|Desc=Currently the concept of virtual time exposed to the guests is very simplistic and is just a static offset from physical time based on the time when the guest was started. We need to consider if this is actually what is needed/wanted and consider cases such as stolen time etc.
 
  +
Assign one or more devices to an unprivileged guest, re-program the SMMU accordingly.
 
}}
 
}}
   
 
{{Open Project
 
{{Open Project
|Project=IOMMU support in Xen
+
|Project=ITS support
 
|Desc=
 
|Desc=
  +
Physical and virtual ITS support for GICv3.
write a driver in Xen for the ARM System Memory Management Unit (SMMU), use it to assign devices to Dom0.
 
  +
|References=Work underway: http://marc.info/?i=1426775889-29442-1-git-send-email-vijay.kilari%40gmail.com
 
}}
 
}}
   
 
{{Open Project
 
{{Open Project
|Project=Save/restore and migration
+
|Project=More flexible early printk support
  +
|Desc=Allow a single Xen binary to support multiple platforms for early_printk
|Desc=
 
  +
Rather than parsing the DTB early in asm to get the command line it would probably be sufficient to have a magic hex byte at a specific offset which could be edited by a simple tool.
Make VM save/restore and VM migration work on ARM.
 
|References=InProgress: http://lists.xen.org/archives/html/xen-devel/2013-10/msg00192.html
+
|References=http://lists.xen.org/archives/html/xen-devel/2014-02/msg01880.html
 
}}
 
}}
  +
 
{{Open Project
 
{{Open Project
|Project=Use Superpage mappings for P2M
+
|Project=Investigation on HCR.FB
  +
|Desc=Setting HCR.FB will upgrade local flush instructions (TLB, instruction cache, branch predictor) to innershareable. It would be nice to benchmark the performance impact on a UP-aware kernel and see if this could be reduced by flushing when a vCPU is migrating to another physical CPUs.
|Desc=
 
  +
|References=http://lists.xen.org/archives/html/xen-devel/2016-04/msg03157.html
Currently we use 4K pages everywhere. Xen should attempt to use 2MB mappings in the P2M wherever possible.
 
This will have significant performance benefits.
 
Need to do 2MB ballooning too.
 
}}
 
{{Open Project
 
|Project=Device assignment to DomUs
 
|Desc=
 
Assign one or more devices to an unprivileged guest, re-program the SMMU accordingly.
 
 
}}
 
}}
   
  +
[[Category:XenARM]]
{{Open Project
 
|Project=Expose Wallclock time to guests
 
|Desc=Current Xen on ARM does not popular the wallclock time fields of the shared info with anything useful. It should do so...
 
}}
 

Latest revision as of 10:22, 27 April 2016

This is a list of open work items and known bugs for the Xen on ARM with virtualization extension project.


In progress

Open Work Items

Save/restore and migration
Contact: xen-devel@lists.xen.org
Description: Make VM save/restore and VM migration work on ARM.
References: An initial prototype was written a couple of years ago for arm32 but never completed: http://lists.xen.org/archives/html/xen-devel/2014-06/msg02076.html

PCI device assignment to DomUs
Contact: xen-devel@lists.xen.org
Description: Assign one or more devices to an unprivileged guest, re-program the SMMU accordingly.
References: Not specified, useful references.

ITS support
Contact: xen-devel@lists.xen.org
Description: Physical and virtual ITS support for GICv3.
References: Work underway: http://marc.info/?i=1426775889-29442-1-git-send-email-vijay.kilari%40gmail.com

More flexible early printk support
Contact: xen-devel@lists.xen.org
Description: Allow a single Xen binary to support multiple platforms for early_printk Rather than parsing the DTB early in asm to get the command line it would probably be sufficient to have a magic hex byte at a specific offset which could be edited by a simple tool.
References: http://lists.xen.org/archives/html/xen-devel/2014-02/msg01880.html

Investigation on HCR.FB
Contact: xen-devel@lists.xen.org
Description: Setting HCR.FB will upgrade local flush instructions (TLB, instruction cache, branch predictor) to innershareable. It would be nice to benchmark the performance impact on a UP-aware kernel and see if this could be reduced by flushing when a vCPU is migrating to another physical CPUs.
References: http://lists.xen.org/archives/html/xen-devel/2016-04/msg03157.html