[I missed this KVM call but the stuff about -cpu host ties into an issue we've been grappling with for ARM KVM, so it seems a reasonable jumping-off-point.] On 6 August 2013 16:15, Juan Quintela <quintela@xxxxxxxxxx> wrote: > 2013-08-06 > ---------- > > What libvirt needs/miss Today? > - how to handle machine types? creating them inside qemu? > - qemu --cpu help > only shows cpus, not what features qemu will use > - qemu -cpu host > what does this exactly means? kvm removes same flags. > - Important to know if migration would work. > - Machine types sometimes disable some feature, so cpu alone is not > enough. > - kernel removes some features because it knows it can't be virtualised > - qemu adds some others because it knows it don't need host support > - and then lots of features in the middle So, coming at this from an ARM perspective: Should any target arch that supports KVM also support "-cpu host"? If so, what should it do? Is there a description somewhere of what the x86 and PPC semantics of -cpu host are? For ARM you can't get at feature info of the host from userspace (unless you want to get into parsing /proc/cpuinfo), so my current idea is to have KVM_ARM_VCPU_INIT support a target-cpu-type which means "whatever host CPU is". Then when we've created the vcpu we can populate QEMU's idea of what the CPU features are by using the existing ioctls for reading the cp15 registers of the vcpu. The other unresolved thing is what "-cpu host" ought to mean for the CPU's on-chip peripherals (of which the major one is the interrupt controller) -- if the host is an A57 should this imply that you always get the A57's GICv3, or is it OK to provide an A57 with a GICv2? At the moment QEMU models the per-cpu peripherals in a somewhat more semi-detached fashion than is the case in silicon, treating them as more a part of the board model than of the cpu itself. Having '-cpu host' not affect them might be the pragmatic choice, since it fits with what QEMU currently does and with kernel-side situations where the host CPU may only be able to show the guest VM a GICv2 view of the world (or only a GICv3, as the case may be). For this to work it does require that guests figure out what their per-cpu peripherals are by looking at the device tree rather than saying "oh, this is an A57, I know all A57s have this", of course... -- PMM -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
