Re: [PATCH v1 00/11] KVM: s390: pv: implement lazy destroy

[Christian Borntraeger]

On 18.05.21 18:31, Claudio Imbrenda wrote:
> On Tue, 18 May 2021 18:22:42 +0200
> David Hildenbrand <david@xxxxxxxxxx> wrote:
>
> > On 18.05.21 18:19, Claudio Imbrenda wrote:
> > > On Tue, 18 May 2021 18:04:11 +0200
> > > Cornelia Huck <cohuck@xxxxxxxxxx> wrote:
> > >    
> > > > On Tue, 18 May 2021 17:36:24 +0200
> > > > Claudio Imbrenda <imbrenda@xxxxxxxxxxxxx> wrote:
> > > >   
> > > > > On Tue, 18 May 2021 17:05:37 +0200
> > > > > Cornelia Huck <cohuck@xxxxxxxxxx> wrote:
> > > > >       
> > > > > > On Mon, 17 May 2021 22:07:47 +0200
> > > > > > Claudio Imbrenda <imbrenda@xxxxxxxxxxxxx> wrote:
> > > >   
> > > > > > > This means that the same address space can have memory
> > > > > > > belonging to more than one protected guest, although only one
> > > > > > > will be running, the others will in fact not even have any
> > > > > > > CPUs.
> > > > > >
> > > > > > Are those set-aside-but-not-yet-cleaned-up pages still possibly
> > > > > > accessible in any way? I would assume that they only belong to
> > > > > > the
> > > > >
> > > > > in case of reboot: yes, they are still in the address space of the
> > > > > guest, and can be swapped if needed
> > > > >       
> > > > > > 'zombie' guests, and any new or rebooted guest is a new entity
> > > > > > that needs to get new pages?
> > > > >
> > > > > the rebooted guest (normal or secure) will re-use the same pages
> > > > > of the old guest (before or after cleanup, which is the reason of
> > > > > patches 3 and 4)
> > > >
> > > > Took a look at those patches, makes sense.
> > > >   
> > > > > the KVM guest is not affected in case of reboot, so the userspace
> > > > > address space is not touched.
> > > >
> > > > 'guest' is a bit ambiguous here -- do you mean the vm here, and the
> > > > actual guest above?
> > > >   
> > >
> > > yes this is tricky, because there is the guest OS, which terminates
> > > or reboots, then there is the "secure configuration" entity,
> > > handled by the Ultravisor, and then the KVM VM
> > >
> > > when a secure guest reboots, the "secure configuration" is
> > > dismantled (in this case, in a deferred way), and the KVM VM (and
> > > its memory) is not directly affected
> > >
> > > what happened before was that the secure configuration was
> > > dismantled synchronously, and then re-created.
> > >
> > > now instead, a new secure configuration is created using the same
> > > KVM VM (and thus the same mm), before the old secure configuration
> > > has been completely dismantled. hence the same KVM VM can have
> > > multiple secure configurations associated, sharing the same address
> > > space.
> > >
> > > of course, only the newest one is actually running, the other ones
> > > are "zombies", without CPUs.
> > >    
> >
> > Can a guest trigger a DoS?
>
> I don't see how
>
> a guest can fill its memory and then reboot, and then fill its memory
> again and then reboot... but that will take time, filling the memory
> will itself clean up leftover pages from previous boots.

In essence this guest will then synchronously wait for the page to be
exported and reimported, correct?
> "normal" reboot loops will be fast, because there won't be much memory
> to process
>
> I have actually tested mixed reboot/shutdown loops, and the system
> behaved as you would expect when under load.

I guess the memory will continue to be accounted to the memcg? Correct?