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

On 25/06/15 13:40, Marc Zyngier wrote:

On 25/06/15 13:30, Christoffer Dall wrote:

quoted

On Wed, Jun 24, 2015 at 10:32:38AM +0100, Marc Zyngier wrote:

quoted

Hi Christoffer,

On 24/06/15 09:51, Christoffer Dall wrote:

quoted

On Wed, Jun 24, 2015 at 09:29:56AM +0100, Marc Zyngier wrote:

quoted

On 22/06/15 09:44, Peter Maydell wrote:

quoted

On 17 June 2015 at 10:00, Suzuki K. Poulose [off-list ref] wrote:

quoted

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.

quoted

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...