Xen ARM TODO: Difference between revisions

From Xen
Jump to navigationJump to search
No edit summary
No edit summary
 
(6 intermediate revisions by 4 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
|Project=vGIC interrupt prioritisation
⚫
|Desc=
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.
}}

{{Open Project
|Project=VCPU virtual time support
|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.
}}

{{Open Project
|Project=IOMMU support in Xen
|Desc=
write a driver in Xen for the ARM System Memory Management Unit (SMMU), use it to assign devices to Dom0.
|References=In Progress: http://lists.xen.org/archives/html/xen-devel/2014-02/msg00670.html
}}


{{Open Project
{{Open Project
Line 43: Line 10:
|Desc=
|Desc=
Make VM save/restore and VM migration work on ARM.
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=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=Use Superpage mappings for P2M
|Project=PCI device assignment to DomUs
|Desc=
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=
|Desc=
Assign one or more devices to an unprivileged guest, re-program the SMMU accordingly.
Assign one or more devices to an unprivileged guest, re-program the SMMU accordingly.
Line 59: Line 20:


{{Open Project
{{Open Project
|Project=Expose Wallclock time to guests
|Project=ITS support
⚫
|Desc=
|Desc=Current Xen on ARM does not popular the wallclock time fields of the shared info with anything useful. It should do so...
Physical and virtual ITS support for GICv3.
}}
|References=Work underway: http://marc.info/?i=1426775889-29442-1-git-send-email-vijay.kilari%40gmail.com

{{Open Project
|Project=Support GIC v3
|Desc=New hardware will come with GIC v3. Currently Xen only support GIC v2
}}
}}


Line 76: Line 34:


{{Open Project
{{Open Project
|Project=Support for DT /chosen/stdout-path node
|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=ePAPR 1.1 3.5 defines the /chosen/stdout-path property which contains the path to the serial device as a string.
⚫
|References=http://lists.xen.org/archives/html/xen-devel/2016-04/msg03157.html

We could potentially make two uses of this:

* Xen itself could use this property if it is present to set the default dtuart= option, saving users the hassle.
* We could pass a suitable /chosen/stdout-path to dom0 to cause it to use hvc0 by default. This needs thinking through since hvc0 doesn't itself have a dt node.

|References=https://www.power.org/documentation/epapr-version-1-1/ https://git.kernel.org/linus/a208ffd251d08ed7ba6bdf3ae1e423373fb12d3d https://git.kernel.org/linus/3482f2c52b77bf6596e24aae82e204a0603eba66
}}
}}



[[Category:XenARM]]
[[Category:XenARM]]

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
Retrieved from "https://wiki.xenproject.org/index.php?title=Xen_ARM_TODO&oldid=16720"