KVM Sync-up call, Dec 3rd, 2013
Attendees:
- Christoffer Dall (Linaro)
- Antonios Motakis (VOS)
- Mian Hamayun (VOS)
- Serge Broslavski (Linaro)
- Peter Maydell (ARM/Linaro)
- Alex Bennee (Linaro)
- Cladio Fontana (Huawei/Linaro)
- Diana Craciun (Freescale)
- Marc Zyngier (ARM)
- Wei Huang (Samsung)
- Andre Przywara (Linaro)
- Richard Phelan (ARM)
Agenda:
- Updates from everyone working on KVM/ARM
- KVM/ARM Image format (GPT + EFI Partition, runs UEFI in guests)
- PCIe emulation in QEMU for KVM (can we do this now?)
- Open floor.
Minutes:
- Updates from everyone working on KVM/ARM
* KVM side (Linaro, Christoffer)
- We are working on Migration, patches are
awaiting review and review comments addressing on both kernel
and qemu side, working on complete PSCI support, guest
debugging support work is ongoing, libvirt support for v7/v8
upstreamed.
* QEMU side (Linaro, Peter)
- mach-virt for v7, patches have been on the list, going to be merged
- kvm control for v8, patches are on the list, have reworked the
original VOS patch set
- ARMv8 TCG work is ongoing
* ARM (Marc)
- Spending most time on GICv3, waiting for internal review before
requesting public review.
- Scalability patches, merged trapping of WFE, improves performance
on oversubscribed VM.
- Patches merged to fix guest endianness, we have what is needed
on the kernel side for big-endian guests
- Started working on mixed CPU support to support migrating from an
A15 to an A7, or from A57 to A53.
* VOS
- Antionios working on VFIO. Kernel side for VFIO for platform
devices. Works using the IOMMU API, should be compatible with
Samsung System MMU and ARM SMMU.
- Marc asked how VOS is dealing with the missing Stage-2 semantics
for the IOMMU interface. Antionios is not concerned with this at
this point, but will consider it later on. Marc stressed that
looking at this early is important.
* Freescale
- Diana explained that they are mostly trying to understand current
code and what is required to run on Freescale platforms.
* Samsung
- Looking at KVM to support their platforms.
- KVM/ARM Image format (GPT + EFI Partition, runs UEFI in guests):
* Marc said the content of the discussion from LCU needs to be
distributed more broadly.
* We discussed whether this requires a fixed machine model of some
sort or whether it makes sense to drive UEFI completely dynamically
from, for example, device tree. This should be discussed more
broadly in public.
* Marc suggested an e-mail thread discussed on, UEFI, kvmarm,
qemu-devel, cross-distro.
- PCIe emulation in QEMU for KVM (can we do this now?)
* Andre explained that in Dublin we were looking for a PCI controller
that could be used for an emulated QEMU model.
* Apparently the Calxeda controller is not great, but is "the best of
the worst", but there is no upstream kernel driver for this.
* We could model a QEMU host controller device against the kernel
driver.
* On the Calxeda memory map we are limited to a single PCI bridge,
but this may be unrelated to the future QEMU implementation.
* Marc asked if the driver assumes a 32-bit base address or a 64-bit
address. Andre said that it should be theoretical possible and
needs to be investigated.
* Peter said that from the QEMU side we need a kernel driver that we
can model things against. Ideally the controller is not tied up
too much with SoC power management.
* Peter also said that we need access to a public data sheet or specs
so we can verify the QEMU implementation. Alternatively, a spec
under NDA to someone implementing the model could be used, but it
makes reviews more difficult. You do need a hardware spec, because
the kernel may do things incorrectly because it is buggy and may
only use a subset of the hardware features and it becomes a
maintenance problem.
* Christoffer asked if we could get access to the Calxeda PCI
controller specs. Andre said getting this access does not look
easy, but he is still waiting for a final response.
* From a QEMU maintainer point of view, Peter said it would be great
to have access to PCI specs to review the code, but if not, he
could still review the code written by someone with access to the
specs, but would require that the reference test platform (the
kernel support), is actually tested thoroughly on real hardware.
- Marc's U-Boot PSCI implementaion
* Has PSCI 'firmware' running in secure RAM on the Allwinner board.
SMP boots on Allwinner without board-support for SMP in the kernel.
* Andre said he would review the code, and Marc said he has a revised
version of the patch set he would send out.
- Performance:
* Richard asked if have any new benchmarks or numbers.
* Christoffer explained that we found an optimization on the VGIC
code by using a non-atomic operation.
* The world-switch reordering to use preload instructions are still
to be done by Marc or Christoffer, but is slightly more complicated
than first anticipated.
* There is a difference in performance between 500 to 1000 cycles on
the world-switch path (depending on how much code you measure)
between r0p4 (arndale) and TC2 (r1p?)
* There is also a VGIC optimizations branch on an old code base that
written by Christoffer that should be revived and properly
measured.
- vcpu->requests work from Christoffer reworks a lot of ARM-specific
quirks:
* Marc had a quick look and it looks like the right thing to do.
* Christoffer will send out patches soon.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
