From: "Michael S. Tsirkin" <mst@redhat.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Richard Cochran <richardcochran@gmail.com>,
Peter Hilber <peter.hilber@opensynergy.com>,
linux-kernel@vger.kernel.org, virtualization@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, linux-rtc@vger.kernel.org,
"Ridoux, Julien" <ridouxj@amazon.com>,
virtio-dev@lists.linux.dev, "Luu, Ryan" <rluu@amazon.com>,
"Chashper, David" <chashper@amazon.com>,
"Mohamed Abuelfotoh, Hazem" <abuehaze@amazon.com>,
"Christopher S . Hall" <christopher.s.hall@intel.com>,
Jason Wang <jasowang@redhat.com>,
John Stultz <jstultz@google.com>,
netdev@vger.kernel.org, Stephen Boyd <sboyd@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
Marc Zyngier <maz@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Alessandro Zummo <a.zummo@towertech.it>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
qemu-devel <qemu-devel@nongnu.org>,
Simon Horman <horms@kernel.org>
Subject: Re: [PATCH] ptp: Add vDSO-style vmclock support
Date: Fri, 26 Jul 2024 01:55:45 -0400 [thread overview]
Message-ID: <20240726012933-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20240726010511-mutt-send-email-mst@kernel.org>
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
> > > > > the ABI issue - kernel has its own ABI against userspace,
> > > > > devices have their own ABI against kernel.
> > > > > It'd mean we need a way to detect that interrupt was sent,
> > > > > maybe yet another counter inside that structure.
> > > > >
> > > > > WDYT?
> > > > >
> > > > > By the way the same idea would work for snapshots -
> > > > > some people wanted to expose that info to userspace, too.
> >
> > 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 passing it on to userspace via a different ABI.
> >
> > It ends up being complex and intricate, and requiring a lot of new
> > kernel and userspace support. I gave up on it in the end for snapshots,
> > and didn't go there again for this.
>
> Maybe become you insist on using ACPI?
> I see a fairly simple way to do it. For example, with virtio:
>
> one vq per CPU, with a single outstanding buffer,
> callback copies from the buffer into the userspace
> visible memory.
>
> Want me to show you the code?
Couldn't resist, so I wrote a bit of this code.
Fundamentally, we keep a copy of the hypervisor abi
in the device:
struct virtclk_info *vci {
struct vmclock_abi abi;
};
each vq will has its own copy:
struct virtqueue_info {
struct scatterlist sg[];
struct vmclock_abi abi;
}
we add it during probe:
sg_init_one(vqi->sg, &vqi->abi, sizeof(vqi->abi));
virtqueue_add_inbuf(vq,
vqi->sg, 1,
&vq->vabi,
GFP_ATOMIC);
We set the affinity for each vq:
for (i = 0; i < num_online_cpus(); i++)
virtqueue_set_affinity(vi->vq[i], i);
(virtio net does it, and it handles cpu hotplug as well)
each vq callback would do:
static void vmclock_cb(struct virtqueue *vq)
{
struct virtclk_info *vci = vq->vdev->priv;
struct virtqueue_info *vqi = vq->priv;
void *buf;
unsigned int len;
buf = virtqueue_get_buf(vq, &len);
if (!buf)
return;
BUG_ON(buf != &vq->abi);
spin_lock(vci->lock);
if (memcmp(&vci->abi, &vqi->abi, sizeof(vqi->abi))) {
memcpy(&vci->abi, &vqi->abi, sizeof(vqi->abi));
}
/* Update the userspace visible structure now */
.....
/* Re-add the buffer */
virtqueue_add_inbuf(vq,
vqi->sg, 1,
&vqi->abi,
GFP_ATOMIC);
spin_unlock(vi->lock);
}
That's it!
Where's the problem here?
--
MST
next prev parent reply other threads:[~2024-07-26 5:56 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-24 17:16 [PATCH] ptp: Add vDSO-style vmclock support David Woodhouse
2024-07-25 5:48 ` Michael S. Tsirkin
2024-07-25 9:56 ` David Woodhouse
2024-07-25 11:31 ` Daniel P. Berrangé
2024-07-25 11:53 ` David Woodhouse
2024-07-25 12:00 ` Daniel P. Berrangé
2024-07-25 12:17 ` Michael S. Tsirkin
2024-07-25 12:27 ` David Woodhouse
2024-07-25 12:29 ` Michael S. Tsirkin
2024-07-25 12:31 ` David Woodhouse
2024-07-25 12:33 ` Michael S. Tsirkin
2024-07-25 13:50 ` David Woodhouse
2024-07-25 14:11 ` Michael S. Tsirkin
2024-07-25 15:18 ` David Woodhouse
2024-07-25 16:38 ` Michael S. Tsirkin
2024-07-25 19:35 ` David Woodhouse
2024-07-25 20:50 ` Michael S. Tsirkin
2024-07-25 21:00 ` David Woodhouse
2024-07-25 21:04 ` Michael S. Tsirkin
2024-07-25 21:29 ` David Woodhouse
2024-07-25 21:47 ` Michael S. Tsirkin
2024-07-25 22:20 ` David Woodhouse
2024-07-26 6:06 ` Michael S. Tsirkin
2024-07-26 8:35 ` David Woodhouse
2024-07-26 12:52 ` Michael S. Tsirkin
2024-07-26 13:00 ` David Woodhouse
2024-07-26 13:04 ` Michael S. Tsirkin
2024-07-26 13:08 ` David Woodhouse
2024-07-26 5:09 ` Michael S. Tsirkin
2024-07-26 5:55 ` Michael S. Tsirkin [this message]
2024-07-26 8:06 ` David Woodhouse
2024-07-26 12:47 ` Michael S. Tsirkin
2024-07-26 12:51 ` David Woodhouse
2024-07-26 16:49 ` Jonathan Cameron via
2024-07-26 18:28 ` David Woodhouse
2024-07-28 10:37 ` Michael S. Tsirkin
2024-07-28 13:07 ` David Woodhouse
2024-07-28 15:23 ` Michael S. Tsirkin
2024-07-29 6:45 ` David Woodhouse
2024-07-25 5:54 ` Michael S. Tsirkin
2024-07-25 10:00 ` David Woodhouse
2024-07-25 11:20 ` Paolo Abeni
2024-07-25 11:49 ` David Woodhouse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240726012933-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=a.zummo@towertech.it \
--cc=abuehaze@amazon.com \
--cc=alexandre.belloni@bootlin.com \
--cc=chashper@amazon.com \
--cc=christopher.s.hall@intel.com \
--cc=daniel.lezcano@linaro.org \
--cc=dwmw2@infradead.org \
--cc=horms@kernel.org \
--cc=jasowang@redhat.com \
--cc=jstultz@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=peter.hilber@opensynergy.com \
--cc=qemu-devel@nongnu.org \
--cc=richardcochran@gmail.com \
--cc=ridouxj@amazon.com \
--cc=rluu@amazon.com \
--cc=sboyd@kernel.org \
--cc=tglx@linutronix.de \
--cc=virtio-dev@lists.linux.dev \
--cc=virtualization@lists.linux.dev \
--cc=xuanzhuo@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).