Minutes from the KVM Sync-up Call on 27 Aug, 2013 ================================================= The sync-up meeting is held bi-weekly only and an invite can be requested from Christoffer Dall. The purpose of this call is purely technical and you should only be involved in this call if you are an engineer working on KVM/ARM or related technologies. - Christoffer Dall explained what Linaro is working on: migration v7, cross CPU type support, testing framework, qemu virtio-mmio, qemu mach-virt. - Marc Zyngier: Marc is the kvm/arm64 maintainer, and he looks after the vgic and timers and kvmtool. - Peter Maydell: qemu arm upstream maintainer, currently focusing on v8 kvm support in qemu trying to upstream patches that are floating around in this area. ARMv8 QEMU system support is next on the todo list. - Mark Burton from GreenSocs: worked on virtio-mmio, currently working on reverse execution with ARM guest for the target. - FreeScale: device assignment, platform device assignment, powerpc and arm-based devices as well. Working on QEMU side of device passthrough as well. - Antionios from VOS, working on device assignment as well. Also working on QEMU patches for using aarch64 KVM with QEMU by Mian. Seems to be some overlapping work. Concretely on aarch64, the patches are not released in an upstreamable fashion, but virtio and mach-virt are being upstreamed, which are prerequisites for the patch set. Future of ARMv8 KVM control patch set: VOS and Peter to coordinate progress. - QEMU "-cpu host" discussion: On x86 you create a set of features you wish, ask KVM which of those features are supported, KVM does a binary and of the two bitmasks and returns some virtual CPU with a particular feature set. End result, you end up with some virtual cpu, which may or may not resemble something that exists in real life, and there are no guarantees that a guest will boot with these combinations. On PowerPC they have a list of CPUs they support, just try to create some CPU that QEMU knows about. cpu host on powerpc probes the hardware and chooses something that looks like the host CPU that it runs on. Peter proposed the current work, where the host CPU is abstracted away from user space, and user space just says "create host-type VCPU" to the kernel, and user space then only queries the CPU for the info it needs from specific registers. For example, it can query the ID registers of the created virtual CPU. Alex pointed out that Gleb had suggested just presenting a custom virtual CPU. However, Marc explained that CPU feature registers don't tell the full story on ARM. A Cortex-A7 and Cortex-A15 are very different, but their flags look the same. Gleb raised the point that on x86 it turned out to be quite useful to create CPUs with specific feature sets, because KVM may not be able to handle the full feature set of the physical CPU, and therefore having partial support of a what a real-life core can do, shown to the guest, can be useful. This is especially relevant when new CPU cores come out and in the context of migration, where this is used today to support migration between, for example, Nahalem and Hasswell cores in an x86 cluster. Christoffer then raised the point that the ecosystem on ARM is just different than on x86, and current software, especially Linux, just doesn't check feature bits in the same way as on x86, but instead assumes the full properties of an ARM cpu to be available. Gleb doubted that this would continue to be the case when ARM moves into the server and networking space, and that both software and hardware may change more toward the way things work on x86. It was decided that if the API for KVM/ARM is changed to adding an ioctl that allows user space to query the kernel's preferred CPU model, which can then be fed back into the kernel (in contrast to being able to ask directly for a host type cpu), then we can always add more fine-grained settings of CPU feature bits later on, if and when the ARM ecosystem becomes more oriented towards server installations. - In general: To avoid duplicate work, people should should send out notice of future work to the list. If this is not possible due to contractual obligations, perhaps pinging the maintainers (Christoffer, Marc, and Peter) can provide some leeway. - Next meeting: The next meeting is on September 10th, please send me agenda items before that. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
