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;
Received-SPF: TempError (protection.outlook.com: error in processing during
 lookup of arm.com: DNS Timeout)
From:   "Jianyong Wu (Arm Technology China)" <Jianyong.Wu@arm.com>
To:     Marc Zyngier <maz@kernel.org>
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
Thread-Topic: [RFC PATCH 3/3] Enable ptp_kvm for arm64
Thread-Index: AQHVXjSmk4aR/CraEk2ZVbEHwQusoKcR7cKAgAyZL9CAAXZNAIADI2mAgAAlXYCAAYC68IABgBYA
Date:   Wed, 11 Sep 2019 10:06:18 +0000
Message-ID: <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>
In-Reply-To: <HE1PR0801MB16769814863B26F3B5DC708FF4B60@HE1PR0801MB1676.eurprd08.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
Authentication-Results-Original: spf=none (sender IP is )
 smtp.mailfrom=Jianyong.Wu@arm.com; 
received-spf: None (protection.outlook.com: arm.com does not designate
 permitted sender hosts)
X-Microsoft-Antispam-Message-Info-Original: pjwXO5FSGD5AeZK9zQ4hRBREccrAq2uI9IAugROKh2oi2n865LAu+mrkrONyhFQcdGKRMKa6aL+uTu6lIY8Ii5heDE6930TjqlphAnsuEyoa9i0xWHn2293ftTuryx13dkQMHH1odOKBHM0Wo75DNZkGzT0QYoQ70l2xUJnGR8g5+G3Mb2AlHt5VjeU/S7Aywehg3jWb+D7S3+PxaLuVn69awdWGtPlouko4ja46bfq/rkVLu44Lk9wgOnmhslsfXCl9Wm6XrCGHbrPHAbvlPF7kysJXWFU3/kUC/hsGrZchGVz6+yI0PAilX+b2WKqjJ5cCA3JGDooP57DRRMZiAUcoKoTkNOqoQ4d184O0dubG8NX0LAdC+RkcHCg46AcaD10Qzz5CR+BA886j/hC8Vgyldck9qgpkhkiqEXK+RnA=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB1786
Original-Authentication-Results: spf=none (sender IP is )
 smtp.mailfrom=Jianyong.Wu@arm.com; 
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT035.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123;IPV:CAL;SCL:-1;CTRY:IE;EFV:NLI;SFV:NSPM;SFS:(10009020)(4636009)(39860400002)(136003)(346002)(376002)(396003)(13464003)(199004)(189003)(51444003)(40434004)(99286004)(7696005)(52536014)(97756001)(36906005)(316002)(356004)(229853002)(5660300002)(86362001)(54906003)(55016002)(9686003)(2906002)(66066001)(14454004)(47776003)(478600001)(26826003)(50466002)(22756006)(23726003)(6116002)(3846002)(25786009)(102836004)(53546011)(336012)(8936002)(476003)(446003)(126002)(63350400001)(11346002)(186003)(5024004)(486006)(14444005)(6246003)(26005)(4326008)(450100002)(6862004)(46406003)(70586007)(7736002)(70206006)(305945005)(76176011)(74316002)(76130400001)(8746002)(33656002)(81166006)(6506007)(81156014)(8676002);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR08MB3837;H:64aa7808-outbound-1.mta.getcheckrecipient.com;FPR:;SPF:TempError;LANG:en;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;A:1;MX:1;
X-MS-Office365-Filtering-Correlation-Id-Prvs: 50ab1a98-e595-4456-358d-08d7369fb067
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(710020)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020);SRVR:VI1PR08MB3837;
X-Forefront-PRVS: 0157DEB61B
X-Microsoft-Antispam-Message-Info: ZQ0o6Z9F+8p6ce0MhEvljVEc2TO//KtGycCo7Gykid18RsxaHpvtkf8r1+YgiOasB0s9RYu8Kc0eB7GaW6a6k9qY87pjgJv3AEkMev3ZTgmVys+nksEtuyJwp8eu5/kKjVFL4BMm3jkSbXs6lM2DeoqbqTS2dWI052jmXMcr8I2CooDXAwodbFAsJCf/wa91V3zCne831VSmZPpQsEh5zWXAV/CZ0LojVlxh630T86R0ZOwIUAHXVNMViyxTRTjyw0viFk7dixI9FP4UBdeiRDuWAg+3Hp8wZYoKQ8OXg5TVaJN4V3Vl+NTkztDiw0J0wplq38U9u8+PzPF6+fF8TepyEmlrC9hyCQPUHmn4w37YlUxY3/GYYIHNToPKD8LQHs99q30rZaziUAFEVpVXT1HrebiTZuveTZo7uzBZ1h4=
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2019 10:06:28.4486
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6f05adae-613e-42b6-42c6-08d7369fb688
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3837
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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, V=
M will only get lost in precision of time sync.

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.

Third: how to inform VMM
There is ioctl cmd call "KVM_CHECK_EXTENSION" in kvm, which may do that thi=
ng. 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.

WDYT?

Jianyong Wu
Thanks

> -----Original Message-----
> From: Jianyong Wu (Arm Technology China)
> Sent: Tuesday, September 10, 2019 6:29 PM
> To: Marc Zyngier <maz@kernel.org>
> Cc: netdev@vger.kernel.org; pbonzini@redhat.com;
> sean.j.christopherson@intel.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; 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
>
> Hi Marc,
>
> > -----Original Message-----
> > From: Marc Zyngier <maz@kernel.org>
> > Sent: Monday, September 9, 2019 7:25 PM
> > To: Jianyong Wu (Arm Technology China) <Jianyong.Wu@arm.com>
> > Cc: netdev@vger.kernel.org; pbonzini@redhat.com;
> > sean.j.christopherson@intel.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;
> > 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
> >
> >
> > > > > > Other questions: how does this works with VM migration?
> > > > > > Specially when moving from a hypervisor that supports the
> > > > > > feature to one that
> > > > doesn't?
> > > > > >
> > > > > I think it won't solve the problem generated by VM migration and
> > > > > only for VMs in a single machine.  Ptp_kvm only works for VMs in
> > > > > the same machine.  But using ptp (not ptp_kvm) clock, all the
> > > > > machines in a low latency network environment can keep time sync
> > > > > in high precision, Then VMs move from one machine to another
> > > > > will obtain a high precision time sync.
> > > >
> > > > That's a problem. Migration must be possible from one host to
> > > > another, even if that means temporarily loosing some (or a lot of)
> > > > precision. The service must be discoverable from userspace on the
> > > > host so that the MVV can decie whether a migration is possible or n=
ot.
> > > >
> > > Don't worry, things will be not that bad.  ptp_kvm will not trouble
> > > the VM migration. This ptp_kvm is one clocksource of the clock pool
> > > for chrony. Chrony will choose the highest precision clock from the
> > > pool. If host does not support ptp_kvm, the ptp_kvm will not be
> > > chosen as the clocksouce of chrony.  We have roughly the same logic
> > > of implementation of ptp_kvm with x86, and ptp_kvm works well in
> > > x86.  so I think that will be the case for arm64.
> > >
> > > Maybe I miss your point, I have no idea of MVV and can't get related
> > > info from google.  Also I'm not clear of your last words of how to
> > > decide VM migration is possible?
> >
> > Sorry. s/MVV/VMM/. Basically userspace, such as QEMU.
> >
> > Here's an example: The guest runs on a PTP aware host, starts using
> > the PTP service and uses HVC calls to get its clock. We now migrate
> > the guest to a non PTP-aware host. The hypercalls are now going to
> > fail unexpectedly. Is that something that is acceptable? I don't think
> > it is. Once you've allowed a guest to use a service, this service
> > should be preserved. I'd be more confident if we gave to userspace the
> > indication that the hypervisor supports PTP. Userspace can then decide
> whether to perform migration or not.
> >
>
> It's really a point we should consider. let me check the behavior of chro=
ny in
> this scenario first.
>
> Thanks
> Jianyong Wu
>
> > Thanks,
> >
> >     M.
> >
> > --
> > Jazz is not dead, it just smells funny.
IMPORTANT NOTICE: The contents of this email and any attachments are confid=
ential and may also be privileged. If you are not the intended recipient, p=
lease notify the sender immediately and do not disclose the contents to any=
 other person, use it for any purpose, or store or copy the information in =
any medium. Thank you.