[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <b49d3c1f-6682-4230-b4b1-44bf3597c326@linux.alibaba.com>
Date: Sat, 30 Aug 2025 16:41:44 +0800
From: Wen Gu <guwen@...ux.alibaba.com>
To: David Woodhouse <dwmw2@...radead.org>,
Richard Cochran <richardcochran@...il.com>, Jakub Kicinski <kuba@...nel.org>
Cc: andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com,
pabeni@...hat.com, xuanzhuo@...ux.alibaba.com, dust.li@...ux.alibaba.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH net-next v4] ptp: add Alibaba CIPU PTP clock driver
On 2025/8/22 15:43, David Woodhouse wrote:
> On Fri, 2025-08-22 at 10:07 +0800, Wen Gu wrote:
>>
>> Hi David,
>>
>> How does vmclock work in a bare‑metal scenario, given that there is no
>> guest–hypervisor architecture?
>>
>> You mentioned "vmclock over PCI", do you mean passing a PCI device to the
>> bare‑metal? What is this PCI device, and which driver does it use?
>
Hi David, sorry for the late reply, my mailbox misclassified this mail.
> It would need PCIe PTM to synchronize against the host's arch timer or
> TSC, which you said you don't have on the CIPU. We don't have PTM
> either, so there is no existing defined PCI device.
>
I see. that's what I thought, in our scenario VM and bare metal can not
use a unified way based on vmclock to achieve PTP clock currently.
> I'm in the process of writing up a specification for the vmclock
> device. It doesn't really contain much information that isn't already
> in the QEMU and Linux code; it'll just be an easier way to find it
> rather than reading GPL'd code, which is problematic for some.
>
> I *could* add a PCI transport, but I figured it was easy enough to do
> that later if anyone implements one.
Understood, thanks for the update.
Powered by blists - more mailing lists