On 28 July 2024 16:23:49 BST, "Michael S. Tsirkin" wrote:
>On Sun, Jul 28, 2024 at 02:07:01PM +0100, David Woodhouse wrote:
>> On 28 July 2024 11:37:04 BST, "Michael S. Tsirkin" wrote:
>> >Glad you asked :)
>>
>> Heh, I'm not sure I'm so glad. Did I mention I hate ACPI? Perhaps it's still
>> no
On Sun, Jul 28, 2024 at 02:07:01PM +0100, David Woodhouse wrote:
> On 28 July 2024 11:37:04 BST, "Michael S. Tsirkin" wrote:
> >Glad you asked :)
>
> Heh, I'm not sure I'm so glad. Did I mention I hate ACPI? Perhaps it's still
> not too late for me just to define a DT binding and use PRP0001 for
On 28 July 2024 11:37:04 BST, "Michael S. Tsirkin" wrote:
>Glad you asked :)
Heh, I'm not sure I'm so glad. Did I mention I hate ACPI? Perhaps it's still
not too late for me just to define a DT binding and use PRP0001 for it :)
>Long story short, QEMUVGID is indeed out of spec, but it works
>bo
On Fri, Jul 26, 2024 at 07:28:28PM +0100, David Woodhouse wrote:
> On 26 July 2024 17:49:58 BST, Jonathan Cameron
> wrote:
> >On Thu, 25 Jul 2024 14:50:50 +0100
> >David Woodhouse wrote:
> >
> >> On Thu, 2024-07-25 at 08:33 -0400, Michael S. Tsirkin wrote:
> >> > On Thu, Jul 25, 2024 at 01:31:19
On 26 July 2024 17:49:58 BST, Jonathan Cameron
wrote:
>On Thu, 25 Jul 2024 14:50:50 +0100
>David Woodhouse wrote:
>
>> On Thu, 2024-07-25 at 08:33 -0400, Michael S. Tsirkin wrote:
>> > On Thu, Jul 25, 2024 at 01:31:19PM +0100, David Woodhouse wrote:
>> > > On Thu, 2024-07-25 at 08:29 -0400, Mi
On Thu, 25 Jul 2024 14:50:50 +0100
David Woodhouse wrote:
> On Thu, 2024-07-25 at 08:33 -0400, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2024 at 01:31:19PM +0100, David Woodhouse wrote:
> > > On Thu, 2024-07-25 at 08:29 -0400, Michael S. Tsirkin wrote:
> > > > On Thu, Jul 25, 2024 at 01:2
On Fri, 2024-07-26 at 09:04 -0400, Michael S. Tsirkin wrote:
> On Fri, Jul 26, 2024 at 02:00:25PM +0100, David Woodhouse wrote:
> > On Fri, 2024-07-26 at 08:52 -0400, Michael S. Tsirkin wrote:
> > > On Fri, Jul 26, 2024 at 09:35:51AM +0100, David Woodhouse wrote:
> > > > But for this use case, we o
On Fri, Jul 26, 2024 at 02:00:25PM +0100, David Woodhouse wrote:
> On Fri, 2024-07-26 at 08:52 -0400, Michael S. Tsirkin wrote:
> > On Fri, Jul 26, 2024 at 09:35:51AM +0100, David Woodhouse wrote:
> > > But for this use case, we only need a memory region that the hypervisor
> > > can update. We don
On Fri, 2024-07-26 at 08:52 -0400, Michael S. Tsirkin wrote:
> On Fri, Jul 26, 2024 at 09:35:51AM +0100, David Woodhouse wrote:
> > But for this use case, we only need a memory region that the hypervisor
> > can update. We don't need any of that complexity of gratuitously
> > interrupting all the v
On Fri, Jul 26, 2024 at 09:35:51AM +0100, David Woodhouse wrote:
> But for this use case, we only need a memory region that the hypervisor
> can update. We don't need any of that complexity of gratuitously
> interrupting all the vCPUs just to ensure that none of them can be
> running userspace whil
On Fri, 2024-07-26 at 08:47 -0400, Michael S. Tsirkin wrote:
> On Fri, Jul 26, 2024 at 09:06:29AM +0100, David Woodhouse wrote:
> > That's great. You don't even need it to be per-vCPU if you let the
> > hypervisor write directly to the single physical location that's mapped
> > to userspace. It can
On Fri, Jul 26, 2024 at 09:06:29AM +0100, David Woodhouse wrote:
> That's great. You don't even need it to be per-vCPU if you let the
> hypervisor write directly to the single physical location that's mapped
> to userspace. It can do that before it even starts *running* the vCPUs
> after migration.
On Fri, 2024-07-26 at 02:06 -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 11:20:56PM +0100, David Woodhouse wrote:
> > We're rolling out the AMZNVCLK device for internal use cases, and plan
> > to add it in public instances some time later.
>
> Let's be real. If amazon does something
On Fri, 2024-07-26 at 01:55 -0400, Michael S. Tsirkin wrote:
> On Fri, Jul 26, 2024 at 01:09:24AM -0400, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2024 at 10:29:18PM +0100, David Woodhouse wrote:
> > > > > > Then can't we fix it by interrupting all CPUs right after LM?
> > > > > >
> > > > > >
On Thu, Jul 25, 2024 at 11:20:56PM +0100, David Woodhouse wrote:
> We're rolling out the AMZNVCLK device for internal use cases, and plan
> to add it in public instances some time later.
Let's be real. If amazon does something in its own hypervisor, and the
only way to use that is to expose the in
On Fri, Jul 26, 2024 at 01:09:24AM -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 10:29:18PM +0100, David Woodhouse wrote:
> > > > > Then can't we fix it by interrupting all CPUs right after LM?
> > > > >
> > > > > To me that seems like a cleaner approach - we then compartmentalize
> >
On Thu, Jul 25, 2024 at 10:29:18PM +0100, David Woodhouse wrote:
> > > > Then can't we fix it by interrupting all CPUs right after LM?
> > > >
> > > > To me that seems like a cleaner approach - we then compartmentalize
> > > > the ABI issue - kernel has its own ABI against userspace,
> > > > devic
On Thu, 2024-07-25 at 17:47 -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 10:29:18PM +0100, David Woodhouse wrote:
> > Those people included me. I wanted to interrupt all the vCPUs, even the
> > ones which were in userspace at the moment of migration, and have the
> > kernel deal with
On Thu, Jul 25, 2024 at 10:29:18PM +0100, David Woodhouse wrote:
> > > > Then can't we fix it by interrupting all CPUs right after LM?
> > > >
> > > > To me that seems like a cleaner approach - we then compartmentalize
> > > > the ABI issue - kernel has its own ABI against userspace,
> > > > devic
On Thu, 2024-07-25 at 17:04 -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 10:00:24PM +0100, David Woodhouse wrote:
> > On Thu, 2024-07-25 at 16:50 -0400, Michael S. Tsirkin wrote:
> > > On Thu, Jul 25, 2024 at 08:35:40PM +0100, David Woodhouse wrote:
> > > > On Thu, 2024-07-25 at 12:38
On Thu, Jul 25, 2024 at 10:00:24PM +0100, David Woodhouse wrote:
> On Thu, 2024-07-25 at 16:50 -0400, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2024 at 08:35:40PM +0100, David Woodhouse wrote:
> > > On Thu, 2024-07-25 at 12:38 -0400, Michael S. Tsirkin wrote:
> > > > On Thu, Jul 25, 2024 at 04:
On Thu, 2024-07-25 at 16:50 -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 08:35:40PM +0100, David Woodhouse wrote:
> > On Thu, 2024-07-25 at 12:38 -0400, Michael S. Tsirkin wrote:
> > > On Thu, Jul 25, 2024 at 04:18:43PM +0100, David Woodhouse wrote:
> > > > The use case isn't necessar
On Thu, Jul 25, 2024 at 08:35:40PM +0100, David Woodhouse wrote:
> On Thu, 2024-07-25 at 12:38 -0400, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2024 at 04:18:43PM +0100, David Woodhouse wrote:
> > > The use case isn't necessarily for all users of gettimeofday(), of
> > > course; this is for tho
On Thu, 2024-07-25 at 12:38 -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 04:18:43PM +0100, David Woodhouse wrote:
> > The use case isn't necessarily for all users of gettimeofday(), of
> > course; this is for those applications which *need* precision time.
> > Like distributed databas
On Thu, Jul 25, 2024 at 04:18:43PM +0100, David Woodhouse wrote:
> On Thu, 2024-07-25 at 10:11 -0400, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2024 at 02:50:50PM +0100, David Woodhouse wrote:
> > > Even if the virtio-rtc specification were official today, and I was
> > > able to expose it via
On Thu, 2024-07-25 at 10:11 -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 02:50:50PM +0100, David Woodhouse wrote:
> > Even if the virtio-rtc specification were official today, and I was
> > able to expose it via PCI, I probably wouldn't do it that way. There's
> > just far more in vir
On Thu, Jul 25, 2024 at 02:50:50PM +0100, David Woodhouse wrote:
> Even if the virtio-rtc specification were official today, and I was
> able to expose it via PCI, I probably wouldn't do it that way. There's
> just far more in virtio-rtc than we need; the simple shared memory
> region is perfectly
On Thu, 2024-07-25 at 08:33 -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 01:31:19PM +0100, David Woodhouse wrote:
> > On Thu, 2024-07-25 at 08:29 -0400, Michael S. Tsirkin wrote:
> > > On Thu, Jul 25, 2024 at 01:27:49PM +0100, David Woodhouse wrote:
> > > > On Thu, 2024-07-25 at 08:17
On Thu, Jul 25, 2024 at 01:31:19PM +0100, David Woodhouse wrote:
> On Thu, 2024-07-25 at 08:29 -0400, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2024 at 01:27:49PM +0100, David Woodhouse wrote:
> > > On Thu, 2024-07-25 at 08:17 -0400, Michael S. Tsirkin wrote:
> > > > On Thu, Jul 25, 2024 at 10:
On Thu, 2024-07-25 at 08:29 -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 01:27:49PM +0100, David Woodhouse wrote:
> > On Thu, 2024-07-25 at 08:17 -0400, Michael S. Tsirkin wrote:
> > > On Thu, Jul 25, 2024 at 10:56:05AM +0100, David Woodhouse wrote:
> > > > > Do you want to just help
On Thu, Jul 25, 2024 at 01:27:49PM +0100, David Woodhouse wrote:
> On Thu, 2024-07-25 at 08:17 -0400, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2024 at 10:56:05AM +0100, David Woodhouse wrote:
> > > > Do you want to just help complete virtio-rtc then? Would be easier than
> > > > trying to keep
On Thu, 2024-07-25 at 08:17 -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 10:56:05AM +0100, David Woodhouse wrote:
> > > Do you want to just help complete virtio-rtc then? Would be easier than
> > > trying to keep two specs in sync.
> >
> > The ACPI version is much more lightweight an
On Thu, Jul 25, 2024 at 10:56:05AM +0100, David Woodhouse wrote:
> > Do you want to just help complete virtio-rtc then? Would be easier than
> > trying to keep two specs in sync.
>
> The ACPI version is much more lightweight and doesn't take up a
> valuable PCI slot#. (I know, you can do virtio wi
On Thu, Jul 25, 2024 at 12:53:34PM +0100, David Woodhouse wrote:
> On Thu, 2024-07-25 at 12:31 +0100, Daniel P. Berrangé wrote:
> > On Thu, Jul 25, 2024 at 10:56:05AM +0100, David Woodhouse wrote:
> > > Hi Michael, thanks for the review!
> > >
> > > On Thu, 2024-07-25 at 01:48 -0400, Michael S. Ts
On Thu, 2024-07-25 at 12:31 +0100, Daniel P. Berrangé wrote:
> On Thu, Jul 25, 2024 at 10:56:05AM +0100, David Woodhouse wrote:
> > Hi Michael, thanks for the review!
> >
> > On Thu, 2024-07-25 at 01:48 -0400, Michael S. Tsirkin wrote:
> > > Do you want to just help complete virtio-rtc then? Would
On Thu, 2024-07-25 at 13:20 +0200, Paolo Abeni wrote:
>
>
> Just a bunch of 'nits below
Thank you. Fixed in
https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/vmclock
I'll post a new version once I've finished resolving mst's and any
other feedback.
smime.p7s
Description: S/
On Thu, Jul 25, 2024 at 10:56:05AM +0100, David Woodhouse wrote:
> Hi Michael, thanks for the review!
>
> On Thu, 2024-07-25 at 01:48 -0400, Michael S. Tsirkin wrote:
> > On Wed, Jul 24, 2024 at 06:16:37PM +0100, David Woodhouse wrote:
> > > From: David Woodhouse
> > >
> > > The vmclock "device"
Hi,
Just a bunch of 'nits below
On 7/24/24 19:16, David Woodhouse wrote:
diff --git a/drivers/ptp/ptp_vmclock.c b/drivers/ptp/ptp_vmclock.c
new file mode 100644
index ..9c508c21c062
--- /dev/null
+++ b/drivers/ptp/ptp_vmclock.c
[...]
+/*
+ * Multiply a 64-bit count by a 64-bit t
On Thu, 2024-07-25 at 01:54 -0400, Michael S. Tsirkin wrote:
> one other thing worth mentioning is that this design can't work
> with confidential computing setups. By comparison, mapping e.g. a
> range in a PCI BAR would work for these setups.
Why so? This is just like mapping a PCI BAR, isn't it
Hi Michael, thanks for the review!
On Thu, 2024-07-25 at 01:48 -0400, Michael S. Tsirkin wrote:
> On Wed, Jul 24, 2024 at 06:16:37PM +0100, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > The vmclock "device" provides a shared memory region with precision clock
> > information. By using
On Wed, Jul 24, 2024 at 06:16:37PM +0100, David Woodhouse wrote:
> From: David Woodhouse
>
> The vmclock "device" provides a shared memory region with precision clock
> information. By using shared memory, it is safe across Live Migration.
>
> Like the KVM PTP clock, this can convert TSC-based c
On Wed, Jul 24, 2024 at 06:16:37PM +0100, David Woodhouse wrote:
> From: David Woodhouse
>
> The vmclock "device" provides a shared memory region with precision clock
> information. By using shared memory, it is safe across Live Migration.
>
> Like the KVM PTP clock, this can convert TSC-based c
From: David Woodhouse
The vmclock "device" provides a shared memory region with precision clock
information. By using shared memory, it is safe across Live Migration.
Like the KVM PTP clock, this can convert TSC-based cross timestamps into
KVM clock values. Unlike the KVM PTP clock, it does so o
43 matches
Mail list logo
