On 26/06/14 11:12, Paolo Bonzini wrote: > Il 26/06/2014 11:44, James Hogan ha scritto: >> This patchset has a few improvements & minor fixes for MIPS KVM support. >> >> Patches 1-2 are fixes for forward compatibility of savevm with MIPS KVM. >> Patch 3 just corrects comments and an error message. >> Patch 4 adds errors when the wrong type of kernel is provided. >> >> James Hogan (4): >> mips/kvm: Init EBase to correct KSEG0 >> mips_malta: Change default KVM cpu to 24Kc (no FP) >> mips_malta: Remove incorrect KVM T&E references >> mips_malta: Catch kernels linked at wrong address >> >> hw/mips/mips_malta.c | 27 +++++++++++++++++++++++---- >> target-mips/translate.c | 8 +++++++- >> 2 files changed, 30 insertions(+), 5 deletions(-) >> > > Looks good, I'm just a bit unsure about patch 2. Is FPU support on the > todo list? Is the idea to add a KVM capability when you add it? At the moment KVM exposes a certain configuration to the guest, regardless of what QEMU thinks the configuration is (see kvm_trap_emul_vcpu_setup()). Patch 2 simply changes QEMU to match what KVM is emulating. FP is definitely on the todo list for VZ at least (and should in theory be doable in T&E too), but I haven't thought too much about the details yet. I'd guess a KVM capability to indicate that KVM supports the API would make sense. Even then there are multiple configurations that might want to be used/distinguished somehow, e.g.: * never support FP in guest (probably default for backward compatibility) * always support FP, always via emulation in hypervisor (all FP instructions trapping) * always support FP, using hardware if available (minimal trapping to guarantee guest sees an FPU) * support FP only if host supports it, using hardware (minimal trapping if hardware, trapping to guest OS to emulate FP if not) Maybe which one of the above is chosen would affect what fields can be read/written to guest Config registers with GET/SET_ONE_REG API (probing guest config registers is closely analogous to how VZ hypervisor controls/probes what features are/can be exposed to the guest). Cheers James -- 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
