From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C7E72C49ED6 for ; Wed, 11 Sep 2019 11:30:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A0B262089F for ; Wed, 11 Sep 2019 11:30:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1568201444; bh=k77V0MPAFdx1Jg694rYvf1EyWYhe2DxcVjGmMcHMLS0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=uLEbGl7eS20jcG/w8Vi2oq5b/Ee/APEPpJo4N7uTPS07d/Hak6F9QO/D+MbxiR9l/ Q5TWM9ypUCC/8mH4/Lcl8t61h/tzL5GPV6ZzECS5GyVW7gRBKsOf9PBIxljMyN8FJi DvPCfseceR+CQQAeozj1fHAbONyhJmtzhfsf3+Eo= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727302AbfIKLal (ORCPT ); Wed, 11 Sep 2019 07:30:41 -0400 Received: from foss.arm.com ([217.140.110.172]:45910 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726341AbfIKLal (ORCPT ); Wed, 11 Sep 2019 07:30:41 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 35F6B28; Wed, 11 Sep 2019 04:30:40 -0700 (PDT) Received: from big-swifty.misterjones.org (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 394263F59C; Wed, 11 Sep 2019 04:30:37 -0700 (PDT) Date: Wed, 11 Sep 2019 12:30:35 +0100 Message-ID: <86ftl3rrxg.wl-maz@kernel.org> From: Marc Zyngier To: "Jianyong Wu (Arm Technology China)" Cc: "netdev@vger.kernel.org" , "pbonzini@redhat.com" , "sean.j.christopherson@intel.com" , "richardcochran@gmail.com" , Mark Rutland , Will Deacon , Suzuki Poulose , "linux-kernel@vger.kernel.org" , Steve Capper , "Kaly Xin (Arm Technology China)" , "Justin He (Arm Technology China)" Subject: Re: [RFC PATCH 3/3] Enable ptp_kvm for arm64 In-Reply-To: References: <20190829063952.18470-1-jianyong.wu@arm.com> <20190829063952.18470-4-jianyong.wu@arm.com> <4d04867c-2188-9574-fbd1-2356c6b99b7d@kernel.org> <86h85osbzz.wl-maz@kernel.org> <86blvtsodw.wl-maz@kernel.org> 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: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, 11 Sep 2019 11:06:18 +0100, "Jianyong Wu (Arm Technology China)" 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.