Re: [PATCH] arm64/kvm: Add generic v8 KVM target

[Marc Zyngier <marc.zyngier@arm.com>]

On 25/06/15 13:40, Marc Zyngier wrote:
> On 25/06/15 13:30, Christoffer Dall wrote:
>> On Wed, Jun 24, 2015 at 10:32:38AM +0100, Marc Zyngier wrote:
>>> Hi Christoffer,
>>>
>>> On 24/06/15 09:51, Christoffer Dall wrote:
>>>> On Wed, Jun 24, 2015 at 09:29:56AM +0100, Marc Zyngier wrote:
>>>>> On 22/06/15 09:44, Peter Maydell wrote:
>>>>>> On 17 June 2015 at 10:00, Suzuki K. Poulose <suzuki.poulose@arm.com> wrote:
>>>>>>> From: "Suzuki K. Poulose" <suzuki.poulose@arm.com>
>>>>>>>
>>>>>>> This patch adds a generic ARM v8 KVM target cpu type for use
>>>>>>> by the new CPUs which eventualy ends up using the common sys_reg
>>>>>>> table. For backward compatibility the existing targets have been
>>>>>>> preserved. Any new target CPU that can be covered by generic v8
>>>>>>> sys_reg tables should make use of the new generic target.
>>>>>>
>>>>>> How do you intend this to work for cross-host migration?
>>>>>
>>>>> It is not meant to work for cross migration at all.
>>>>>
>>>>>> Is the idea that the kernel guarantees that "generic" looks
>>>>>> 100% the same to the guest regardless of host hardware? I'm
>>>>>> not sure that can be made to work, given impdef differences
>>>>>> in ID register values, bp/wp registers, and so on.
>>>>>>
>>>>>> Given that, it seems to me that we still need to provide
>>>>>> KVM_ARM_TARGET_$THISCPU defines so userspace can request
>>>>>> a specific guest CPU flavour; so what does this patch
>>>>>> provide that isn't already provided by just having userspace
>>>>>> query for the "preferred" CPU type as it does already?
>>>>>
>>>>> The way I see this working is that a "generic" CPU cannot be migrated
>>>>> (because we don't know anything about it). If it can be identified as a
>>>>> known (non generic) implementation, then we can migrate it.
>>>>>
>>>> Concretely, how should this work?  Be enforced by userspace or should we
>>>> deny certain SET_ONE_REG operations from working on this target?
>>>
>>> I can definitely see MIDR overriding failing on a generic CPU. Also, you
>>> shouldn't be able to select a generic CPU if we know about the physical CPU.
>>>
>>
>> If I am migrating from an A57 to an A53, but the VM was started as
>> "generic CPU" then we rely on the user discovering that this is not
>> supported when trying to set the MIDR from userspace in KVM?
> 
> A57 to A53 is probably a bad example because we actively support both.
> So let's replace your A57 with an A72. With this patch, the A72 would be
> reported as "generic CPU", and MIDR access would fail on the A53.

Having thought about this a bit more...

It should always be possible to emulate a "known" CPU on a generic host,
and it should be able to migrate. The case we can't migrate is when we
let the guest be generic (which I guess should really be unknown, and
not generic).

So if the user specify "-cpu cortex-a57" on the command line, the guest
should be able to migrate from an A72 to an A53. if the user specified
"-cpu host", the resulting guest won't be able to migrate.

Does it make sense?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...