lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ