On Tue, Apr 19, 2022 at 05:12:36PM +0200, Jason A. Donenfeld wrote:
> Hey Alex,
>
> On Thu, Mar 10, 2022 at 12:18 PM Alexander Graf wrote:
> > I agree on the slightly racy compromise and that it's a step into the
> > right direction. Doing this is a no brainer IMHO and I like the proc
> > based p
Hey Alex,
On Thu, Mar 10, 2022 at 12:18 PM Alexander Graf wrote:
> I agree on the slightly racy compromise and that it's a step into the
> right direction. Doing this is a no brainer IMHO and I like the proc
> based poll approach.
Alright. I'm going to email a more serious patch for that in the
On Thu, Mar 10, 2022 at 12:18:04PM +0100, Alexander Graf wrote:
> I agree on the slightly racy compromise
Thought hard about this, I think I agree, and I guess as a minimum we
can start with at least the ACPI+RNG patch, right? That will already
address wireguard ...
--
MST
On 09.03.22 23:02, Jason A. Donenfeld wrote:
Hi Alex,
On Wed, Mar 9, 2022 at 3:10 AM Alexander Graf wrote:
The vmgenid driver basically works, though it is racy, because that ACPI
notification can arrive after the system is already running again. This
I believe enough people already pointed
Hi Alex,
On Wed, Mar 9, 2022 at 3:10 AM Alexander Graf wrote:
> > The vmgenid driver basically works, though it is racy, because that ACPI
> > notification can arrive after the system is already running again. This
>
>
> I believe enough people already pointed out that this assumption is
> incorr
On 01.03.22 16:42, Jason A. Donenfeld wrote:
Hey folks,
Having finally wrapped up development of the initial vmgenid driver, I
thought I'd pull together some thoughts on vmgenid, notification, and
propagating, from disjointed conversations I've had with a few of you
over the last several weeks
On Wed, Mar 02, 2022 at 05:32:07PM +0100, Jason A. Donenfeld wrote:
> Hi Michael,
>
> On Wed, Mar 02, 2022 at 11:22:46AM -0500, Michael S. Tsirkin wrote:
> > > Because that 16 byte read of vmgenid is not atomic. Let's say you read
> > > the first 8 bytes, and then the VM is forked.
> >
> > But at
On Wed, Mar 02, 2022 at 05:32:07PM +0100, Jason A. Donenfeld wrote:
> Hi Michael,
>
> On Wed, Mar 02, 2022 at 11:22:46AM -0500, Michael S. Tsirkin wrote:
> > > Because that 16 byte read of vmgenid is not atomic. Let's say you read
> > > the first 8 bytes, and then the VM is forked.
> >
> > But at
On Wed, Mar 02, 2022 at 04:36:49PM +0100, Jason A. Donenfeld wrote:
> Hi Michael,
>
> On Wed, Mar 02, 2022 at 10:20:25AM -0500, Michael S. Tsirkin wrote:
> > So writing some code:
> >
> > 1:
> > put plaintext in a buffer
> > put a key in a buffer
> > put the nonce for that encryption
Hi Michael,
On Wed, Mar 02, 2022 at 11:22:46AM -0500, Michael S. Tsirkin wrote:
> > Because that 16 byte read of vmgenid is not atomic. Let's say you read
> > the first 8 bytes, and then the VM is forked.
>
> But at this point when VM was forked plaintext key and nonce are all in
> buffer, and yo
On Wed, Mar 02, 2022 at 04:36:49PM +0100, Jason A. Donenfeld wrote:
> Hi Michael,
>
> On Wed, Mar 02, 2022 at 10:20:25AM -0500, Michael S. Tsirkin wrote:
> > So writing some code:
> >
> > 1:
> > put plaintext in a buffer
> > put a key in a buffer
> > put the nonce for that encryption
Hi Michael,
On Wed, Mar 02, 2022 at 10:20:25AM -0500, Michael S. Tsirkin wrote:
> So writing some code:
>
> 1:
> put plaintext in a buffer
> put a key in a buffer
> put the nonce for that encryption in a buffer
>
> if vm gen id != stored vm gen id
> stored v
On Wed, Mar 02, 2022 at 04:14:56PM +0100, Jason A. Donenfeld wrote:
> Hi Michael,
>
> On Wed, Mar 2, 2022 at 3:46 PM Michael S. Tsirkin wrote:
> > I just don't see how "value changed while it was read" is so different
> > from "value changed one clock after it was read". Since we don't detect
>
Hi Michael,
On Wed, Mar 2, 2022 at 3:46 PM Michael S. Tsirkin wrote:
> I just don't see how "value changed while it was read" is so different
> from "value changed one clock after it was read". Since we don't detect
> the latter I don't see why we should worry about the former.
The "barrier" is
On Wed, Mar 02, 2022 at 02:55:29PM +0100, Jason A. Donenfeld wrote:
> Hi Michael,
>
> On Wed, Mar 02, 2022 at 07:58:33AM -0500, Michael S. Tsirkin wrote:
> > > There's also the atomicity aspect, which I think makes your benchmark
> > > not quite accurate. Those 16 bytes could change between the fi
Hey again,
On Tue, Mar 01, 2022 at 04:42:47PM +0100, Jason A. Donenfeld wrote:
> For (B), it's a little bit trickier. But I think our options follow the
> same rubric. We can expose a generation counter in the vDSO, with
> semantics akin to the extern integer I described above. Or we could
> expos
On Wed, Mar 02, 2022 at 12:26:27PM +0100, Jason A. Donenfeld wrote:
> Hey Michael,
>
> Thanks for the benchmark.
>
> On Wed, Mar 2, 2022 at 9:30 AM Michael S. Tsirkin wrote:
> > So yes, the overhead is higher by 50% which seems a lot but it's from a
> > very small number, so I don't see why it's
Hi Michael,
On Wed, Mar 02, 2022 at 07:58:33AM -0500, Michael S. Tsirkin wrote:
> > There's also the atomicity aspect, which I think makes your benchmark
> > not quite accurate. Those 16 bytes could change between the first and
> > second word (or between the Nth and N+1th word for N<=3 on 32-bit)
Hey Michael,
Thanks for the benchmark.
On Wed, Mar 2, 2022 at 9:30 AM Michael S. Tsirkin wrote:
> So yes, the overhead is higher by 50% which seems a lot but it's from a
> very small number, so I don't see why it's a show stopper, it's not by a
> factor of 10 such that we should sacrifice safety
On Tue, Mar 01, 2022 at 07:37:06PM +0100, Jason A. Donenfeld wrote:
> Hi Michael,
>
> On Tue, Mar 1, 2022 at 6:17 PM Michael S. Tsirkin wrote:
> > Hmm okay, so it's a performance optimization... some batching then? Do
> > you really need to worry about every packet? Every 64 packets not
> > enoug
On Wed, Mar 02, 2022 at 02:42:37AM -0500, Michael S. Tsirkin wrote:
> On Tue, Mar 01, 2022 at 07:37:06PM +0100, Jason A. Donenfeld wrote:
> > Hi Michael,
> >
> > On Tue, Mar 1, 2022 at 6:17 PM Michael S. Tsirkin wrote:
> > > Hmm okay, so it's a performance optimization... some batching then? Do
>
On Tue, Mar 01, 2022 at 07:37:06PM +0100, Jason A. Donenfeld wrote:
> Hi Michael,
>
> On Tue, Mar 1, 2022 at 6:17 PM Michael S. Tsirkin wrote:
> > Hmm okay, so it's a performance optimization... some batching then? Do
> > you really need to worry about every packet? Every 64 packets not
> > enoug
On Tue, Mar 1, 2022 at 8:41 PM Greg KH wrote:
>
> On Tue, Mar 01, 2022 at 07:24:11PM +0100, Jason A. Donenfeld wrote:
> > Hi Greg,
> >
> > On Tue, Mar 1, 2022 at 7:01 PM Greg KH wrote:
> > > A notifier block like this makes sense, but why tie onto the PM_ stuff?
> > > This isn't power management
On Tue, Mar 01, 2022 at 07:24:11PM +0100, Jason A. Donenfeld wrote:
> Hi Greg,
>
> On Tue, Mar 1, 2022 at 7:01 PM Greg KH wrote:
> > A notifier block like this makes sense, but why tie onto the PM_ stuff?
> > This isn't power management issues, it's a system-wide change that I am
> > sure others
Hi Michael,
On Tue, Mar 1, 2022 at 6:17 PM Michael S. Tsirkin wrote:
> Hmm okay, so it's a performance optimization... some batching then? Do
> you really need to worry about every packet? Every 64 packets not
> enough? Packets are after all queued at NICs etc, and VM fork can
> happen after the
Hi Greg,
On Tue, Mar 1, 2022 at 7:01 PM Greg KH wrote:
> A notifier block like this makes sense, but why tie onto the PM_ stuff?
> This isn't power management issues, it's a system-wide change that I am
> sure others will want to know about that doesn't reflect any power
> changes.
>
> As much as
On Tue, Mar 01, 2022 at 04:42:47PM +0100, Jason A. Donenfeld wrote:
> The easy way, and the way that I think I prefer, would be to just have a
> sync notifier_block for this, just like we have with
> register_pm_notifier(). From my perspective, it'd be simplest to just
> piggy back on the already e
On Tue, Mar 01, 2022 at 05:28:48PM +0100, Jason A. Donenfeld wrote:
> Hi Laszlo,
>
> On Tue, Mar 01, 2022 at 05:15:21PM +0100, Laszlo Ersek wrote:
> > > If we had a "pull" model, rather than just expose a 16-byte unique
> > > identifier, the vmgenid virtual hardware would _also_ expose a
> > > wor
Hi Michael,
On Tue, Mar 01, 2022 at 11:21:38AM -0500, Michael S. Tsirkin wrote:
> > If we had a "pull" model, rather than just expose a 16-byte unique
> > identifier, the vmgenid virtual hardware would _also_ expose a
> > word-sized generation counter, which would be incremented every time the
> >
Hi Laszlo,
On Tue, Mar 01, 2022 at 05:15:21PM +0100, Laszlo Ersek wrote:
> > If we had a "pull" model, rather than just expose a 16-byte unique
> > identifier, the vmgenid virtual hardware would _also_ expose a
> > word-sized generation counter, which would be incremented every time the
> > unique
On Tue, Mar 01, 2022 at 04:42:47PM +0100, Jason A. Donenfeld wrote:
> Hey folks,
>
> Having finally wrapped up development of the initial vmgenid driver, I
> thought I'd pull together some thoughts on vmgenid, notification, and
> propagating, from disjointed conversations I've had with a few of yo
On 03/01/22 16:42, Jason A. Donenfeld wrote:
> Hey folks,
>
> Having finally wrapped up development of the initial vmgenid driver, I
> thought I'd pull together some thoughts on vmgenid, notification, and
> propagating, from disjointed conversations I've had with a few of you
> over the last sever
Hey folks,
Having finally wrapped up development of the initial vmgenid driver, I
thought I'd pull together some thoughts on vmgenid, notification, and
propagating, from disjointed conversations I've had with a few of you
over the last several weeks.
The basic problem is: VMs can be cloned, forke
33 matches
Mail list logo
