Message-ID: <HE1PR0801MB1676847C0A84473797BF4346F4B10@HE1PR0801MB1676.eurprd08.prod.outlook.com>
Date:   Wed, 11 Sep 2019 10:06:18 +0000
From:   "Jianyong Wu (Arm Technology China)" <Jianyong.Wu@....com>
To:     Marc Zyngier <maz@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "sean.j.christopherson@...el.com" <sean.j.christopherson@...el.com>,
        "richardcochran@...il.com" <richardcochran@...il.com>,
        Mark Rutland <Mark.Rutland@....com>,
        Will Deacon <Will.Deacon@....com>,
        Suzuki Poulose <Suzuki.Poulose@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Steve Capper <Steve.Capper@....com>,
        "Kaly Xin (Arm Technology China)" <Kaly.Xin@....com>,
        "Justin He (Arm Technology China)" <Justin.He@....com>
Subject: RE: [RFC PATCH 3/3] Enable ptp_kvm for arm64

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.

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

WDYT?

Jianyong Wu
Thanks

> -----Original Message-----
> From: Jianyong Wu (Arm Technology China)
> Sent: Tuesday, September 10, 2019 6:29 PM
> To: Marc Zyngier <maz@...nel.org>
> Cc: netdev@...r.kernel.org; pbonzini@...hat.com;
> sean.j.christopherson@...el.com; richardcochran@...il.com; Mark Rutland
> <Mark.Rutland@....com>; Will Deacon <Will.Deacon@....com>; Suzuki
> Poulose <Suzuki.Poulose@....com>; linux-kernel@...r.kernel.org; Steve
> Capper <Steve.Capper@....com>; Kaly Xin (Arm Technology China)
> <Kaly.Xin@....com>; Justin He (Arm Technology China)
> <Justin.He@....com>
> Subject: RE: [RFC PATCH 3/3] Enable ptp_kvm for arm64
>
> Hi Marc,
>
> > -----Original Message-----
> > From: Marc Zyngier <maz@...nel.org>
> > Sent: Monday, September 9, 2019 7:25 PM
> > To: Jianyong Wu (Arm Technology China) <Jianyong.Wu@....com>
> > Cc: netdev@...r.kernel.org; pbonzini@...hat.com;
> > sean.j.christopherson@...el.com; richardcochran@...il.com; Mark
> > Rutland <Mark.Rutland@....com>; Will Deacon <Will.Deacon@....com>;
> > Suzuki Poulose <Suzuki.Poulose@....com>; linux-kernel@...r.kernel.org;
> > Steve Capper <Steve.Capper@....com>; Kaly Xin (Arm Technology China)
> > <Kaly.Xin@....com>; Justin He (Arm Technology China)
> > <Justin.He@....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 not.
> > > >
> > > 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 chrony 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 confidential and may also be privileged. If you are not the intended recipient, please 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.

Powered by blists - more mailing lists