Re: [PATCH v8 3/7] KVM: Support dirty ring in conjunction with bitmap

[Marc Zyngier <maz@kernel.org>]

On Mon, 07 Nov 2022 14:59:41 +0000,
Peter Xu <peterx@redhat.com> wrote:
> 
> On Mon, Nov 07, 2022 at 09:21:35AM +0000, Marc Zyngier wrote:
> > On Sun, 06 Nov 2022 21:06:43 +0000,
> > Peter Xu <peterx@redhat.com> wrote:
> > > 
> > > It's definitely not the case for x86, but if it's true for
> > > arm64, then could the DMA be spread across all the guest pages?
> > > If it's also true, I really don't know how this will work..
> > 
> > Of course, all pages can be the target of DMA. It works the same way
> > it works for the ITS: you sync the state, you obtain the dirty bits,
> > you move on.
> > 
> > And mimicking what x86 does is really not my concern (if you still
> > think that arm64 is just another flavour of x86, stay tuned!  ;-).
> 
> I didn't mean so, I should probably stop mentioning x86. :)

Please! I turned off my last x86 development machine over the weekend,
and my x86 laptop is now a glorified window manager... ;-)

> I had some sense already from the topics in past few years of kvm forum.
> Yeah I'll be looking forward to anything more coming.

Yup. Hopefully we won't have to wait for too long to see this stuff (I
had good discussions on the subject at both KF and Plumbers in Dublin
earlier this year).

> > > We're only syncing the dirty bitmap once right now with the
> > > protocol.  If that can cover most of the guest mem, it's same as
> > > non-live.  If we sync it periodically, then it's the same as
> > > enabling dirty-log alone and the rings are useless.
> > 
> > I'm glad that you finally accept it: the ring *ARE* useless in the
> > general sense. Only limited, CPU-only workloads can make any use of
> > the current design. This probably covers a large proportion of what
> > the cloud vendors do, but this doesn't work for general situations
> > where you have a stream of dirty pages originating outside of the
> > CPUs.
> 
> The ring itself is really not the thing to blame, IMHO it's a good attempt
> to try out de-coupling guest size in regard of dirty tracking from kvm.  It
> may not be perfect, but it may still service some of the goals, e.g., at
> least it allows the user app to detect per-vcpu information and also since
> there's the ring full events we can do something more than before like the
> vcpu throttling that China Telecom does with the ring structures.

I don't disagree with that: for vcpu-based workloads, the rings are
great and doing their job. It's just that there is another side to
this problem, and you'll have to deal with both eventually. We're just
ahead of the curve here...

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm