KVM/ARM Technical Sync-up - Sep 10, 2013
========================================
Present
-------
- Prasun
- Serge
- Chegu
- Mian
- Stuart
- Alex
- Don Dutile
- Mian Hamayun
- Richard
- Marc
- Peter
Minutes
-------
- Migration on ARMv8-A, what do we need besides the v7 work?
* Work on QEMU would have to be done. System register emulation not
ready in QEMU yet, and only when that code is written will we add
save/restore mapping.
* Alex: Started cleaning up TCG patches, they are very aarch64 focused.
Q: Where do registers go that are 32 bit in the guest?
A: There is an architectural map between the two states.
Specific 32-bit state in standard system registers.
- Christoffer asked people to review patches:
* huge pages series
* VGIC and timer save/restore series
* Marc will try this for an early -rc2 release
- Marc asked if someone could look at the 64-K mapping offset
restriction for the vgic.
* Christoffer to look into this
- Number of IRQs supported by the VGIC:
* The kernel currently has a static define of the maximum number of
IRQs supported by the VGIC exported to guests. The number of IRQs
is actually an attribute of the CPU Core and therefore user space
should be able to tell the kernel how many CPUs are supported, but
dynamic allocation of per-IRQ state in the kernel may not be an
easy solution.
* Marc: has had a look at code.
Current logic is based on bitmaps, which are efficient when size
known at compile-time. Becomes slow in critical paths when we
start doing logical operations (e.g. ANDs on bitmaps). For
example, writing to an enable distributor register, requires to
recompute the whole state, would become incredibly slow with
dynamic allocation.
If masking is used for RT linux it is going to suffer in a VM. Use
case to keep in mind. Alex suggests keeping some state in bitmaps
and some state dynamically allocated. Marc suggests having a look
and come up with a benchmark number for the vgic.
Note: On mach-virt we only support 128 IRQs (which should be
sufficient for the mach-virt platform) and the problem therefore
only exists for emulation of real systems.
- Cortex-A7 support
* Missed some context, dropped the call
* A7-on-A7, in KVM/ARM, Freescale will look into this
* AllWinner A7 device on Marc's desk, looking for a kernel that boots
it.
* Init problem on Cortex-A7, potentially a race on the firmware or
bootloader.
* Christoffer is going to look into this as well.
- QEMU KVM Control Patches from VOS
* VOS to resubmit patch version soon, latest next week
* Peter said user interface should still be -cpu host, but the
implementation should try the core types known for backwards
compatibility anyway.
* Alex asked if the aarch64 enablement patches (preparation patch
set) will get in. One minor comment from Alex to the patch set,
otherwise it will go in today.
Please remember to send out any agenda items you may have for next call
on Sep 24 2013.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
