Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 11 Sep 2019 12:30:35 +0100
Message-ID: <86ftl3rrxg.wl-maz@kernel.org>
From:   Marc Zyngier <maz@kernel.org>
To:     "Jianyong Wu (Arm Technology China)" <Jianyong.Wu@arm.com>
Cc:     "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "pbonzini@redhat.com" <pbonzini@redhat.com>,
        "sean.j.christopherson@intel.com" <sean.j.christopherson@intel.com>,
        "richardcochran@gmail.com" <richardcochran@gmail.com>,
        Mark Rutland <Mark.Rutland@arm.com>,
        Will Deacon <Will.Deacon@arm.com>,
        Suzuki Poulose <Suzuki.Poulose@arm.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Steve Capper <Steve.Capper@arm.com>,
        "Kaly Xin (Arm Technology China)" <Kaly.Xin@arm.com>,
        "Justin He (Arm Technology China)" <Justin.He@arm.com>
Subject: Re: [RFC PATCH 3/3] Enable ptp_kvm for arm64
In-Reply-To: <HE1PR0801MB1676847C0A84473797BF4346F4B10@HE1PR0801MB1676.eurprd08.prod.outlook.com>
References: <20190829063952.18470-1-jianyong.wu@arm.com>
        <20190829063952.18470-4-jianyong.wu@arm.com>
        <4d04867c-2188-9574-fbd1-2356c6b99b7d@kernel.org>
        <HE1PR0801MB16768ED94EA50010EEF634EAF4BA0@HE1PR0801MB1676.eurprd08.prod.outlook.com>
        <86h85osbzz.wl-maz@kernel.org>
        <HE1PR0801MB16768BE47D3D1F0662DDC3C7F4B70@HE1PR0801MB1676.eurprd08.prod.outlook.com>
        <86blvtsodw.wl-maz@kernel.org>
        <HE1PR0801MB16769814863B26F3B5DC708FF4B60@HE1PR0801MB1676.eurprd08.prod.outlook.com>
        <HE1PR0801MB1676847C0A84473797BF4346F4B10@HE1PR0801MB1676.eurprd08.prod.outlook.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
 FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/26
 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO)
Organization: Approximate
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, 11 Sep 2019 11:06:18 +0100,
"Jianyong Wu (Arm Technology China)" <Jianyong.Wu@arm.com> wrote:
> 
> Hi Marc,
> 
> I think there are three points for the migration issue of ptp_kvm,
> where a VM using ptp_kvm migrates to a host without ptp_kvm support.
> 
> First: how does it impact the VM having migrated?
> I run a VM with ptp_kvm support in guest but not support in
> host. the ptp0 will return 0 when get time from it which can't pass
> the check of chrony, then chrony will choose another clocksource.
> From this point, VM will only get lost in precision of time sync.

"only" is a bit of an understatement. Once the guest has started
relying on a service, it seems rather harsh to pretend this service
doesn't exist anymore. It could well be that the VM cannot perform its
function if the precision is not good enough.

The analogy is the Spectre-v2 mitigation, which is implemented as a
hypercall. Nothing will break if you migrate to a host that doesn't
support the mitigation, but the guest will now be unsafe. Is that
acceptable? the answer is of course "no".

> Second: how to check the failure of the ptp kvm service
> when there is no ptp kvm service, hypercall will go into default
> ops, so we can check the return value which can inform us the
> failure.

Sure. But that's still an issue. The VM relied on the service, and the
service isn't available anymore.

> Third: how to inform VMM
> There is ioctl cmd call "KVM_CHECK_EXTENSION" in kvm, which may do
> that thing. Accordingly, qemu should be offered the support which
> will block us.  We can try to add this support in kvm but we are not
> sure the response from qemu side.

It doesn't matter whether QEMU implements that check or . The
important thing is that we give userspace a way to check this for
this, and having a capability that can be checked against is probably
the right thing to do.

Thanks,

	M.

-- 
Jazz is not dead, it just smells funny.