Re: [Qemu-devel] [RFC 0/2] target-arm: Provide '-cpu host' when running KVM

[Alexander Graf]

On 14.08.2013, at 10:27, Marc Zyngier wrote:

> On 2013-08-14 09:16, Alexander Graf wrote:
>> On 14.08.2013, at 10:11, Marc Zyngier wrote:
>> 
>>> On 2013-08-14 07:32, Alexander Graf wrote:
>>>> On 13.08.2013, at 20:03, Peter Maydell wrote:
>>>> 
>>>>> These patches add support to target-arm for '-cpu host'.
>>>>> The general semantics are the same as for ppc and x86 (ie "whatever
>>>>> the host kernel can support that looks basically like the host
>>>>> CPU"), but the mechanism is a little different.
>>>>> 
>>>>> The kernel API (currently still proposed rather than implemented,
>>>>> hence the RFC nature of this patchset) is that the existing
>>>>> KVM_ARM_VCPU_INIT supports a new 'target' value KVM_ARM_TARGET_HOST,
>>>>> which it treats as "whatever you are". On the userspace side,
>>>>> we use this if the kernel supports it. If it doesn't then we
>>>>> know the kernel must be an A15-on-A15 only one, and so can
>>>>> safely implement '-cpu host' with KVM_ARM_TARGET_CORTEX_A15.
>>>> 
>>>> How do you know what core specific registers QEMU can expect from
>>>> this particular CPU? Imagine ARM changes the MMU implementation in the
>>>> next ARMv8 CPU. With -cpu host you wouldn't be able to support gdbstub
>>>> anymore, because you wouldn't know whether the MMU format is the old
>>>> or the new one.
>>> 
>>> Well, we're already there. A15 supports both classic page tables and LPAE.
>>> 
>>> You can discover which one is being used by inspecting the guest, and I'd
>>> fully expect future versions of the architecture to expose bits in the ID
>>> registers indicating the various supported extensions.
>> 
>> Can you fetch those from user space? If so, we should probably create
>> a "host" CPU type class on the fly from the host's ID registers that
>> adjusts itself to the correct callbacks.
> 
> All the ID registers are available to userspace as part of the one-reg API. 
> What the guest actually uses (for example classic vs LPAE) can be found out 
> by looking at other registers (in this example SCTRL) that have to be 
> exported anyway (at least for VM migration).

So can we access those even when the vcpu hasn't been init'ed yet? If so, how 
about the following flow of things for -cpu host:

  - QEMU fetches host target type via ioctl (how will this work for big-little?)
  - QEMU fetches ID registers, feature flags, etc via one-reg (or are they also 
available via auxv?), puts them into its internal "this is my cpu type" fields 
for the cpu object / class.
  - QEMU calls VCPU_INIT with the type it fetched via ioctl.

Or would it make sense to model it like it's done on x86 where we also filter 
feature flags in QEMU and KVM to make sure we only expose a compatible subset?


Alex