Re: [Qemu-devel] [PATCH 0/4] QEMU MIPS KVM improvements for v2.1

[James Hogan]

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