Adding a side note in agenda from Linaro networking group.
Thanks.On 30 August 2013 03:03, Christoffer Dall <christoffer.dall@xxxxxxxxxx> wrote:
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.
LNG - Interested to work on above similar feature taking Antonio's VFIO-arm patch set as a reference for arm networking processor, development involved changes in qemu, kvm side for platform devices. It would be good to know freescale development status so as to avoid rework.
- 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
_______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
