Received-SPF: pass (google.com: domain of linux-kernel+bounces-23101-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Thu, 11 Jan 2024 14:35:08 +0800 (CST)
From: Zheyun Shen <szy0127@sjtu.edu.cn>
To: Jason Wang <jasowang@redhat.com>, mst <mst@redhat.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>, 
	virtualization <virtualization@lists.linux.dev>, 
	david <david@redhat.com>, xuanzhuo <xuanzhuo@linux.alibaba.com>
Message-ID: <1824181559.1228150.1704954908335.JavaMail.zimbra@sjtu.edu.cn>
Subject: Re: [PATCH] driver/virtio: Add Memory Balloon Support for
 SEV/SEV-ES
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Thread-Index: l+gZfqyZiAOpiygeFB9+OsBBxO8d6Q==
Thread-Topic: driver/virtio: Add Memory Balloon Support for SEV/SEV-ES

On Wed, Jan 10, 2024 at 4:01=E2=80=AFPM Michael S. Tsirkin <mst@redhat.com>=
 wrote:
> Sorry I don't get what you are saying at all.
> Please format the commit log along the following lines:

> Currently .....
> This is bad because ...
> To fix ...
> As a result ...

> No way I am going to spead CONFIG_AMD_MEM_ENCRYPT all over the place=20
> like this.

I will try to find out a solution with fewer macros and send patch V2
with a more perspicuous commit log.


On Thur, Jan 11, 2024 at 11:20=E2=80=AFAM Jason Wang <jasowang@redhat.com> =
wrote:

> > For now, SEV pins guest's memory to avoid swapping or
> > moving ciphertext, but leading to the inhibition of
> > Memory Ballooning.
> >
> > In Memory Ballooning, only guest's free pages will be relocated
> > in balloon inflation and deflation, so the difference of plaintext
> > doesn't matter to guest.

> This seems only true if the page is zeroed, is this true here?

Sorry, I cannot figure out why the pages should be zeroed. I think
both host kernel and guest kernel assume that the pages are not=20
zeroed and will use kzalloc or manually zero them in real applications,
which is same as non-SEV environments.=20

I have tested in SEV-ES, reclaiming memory by balloon inflation and reuse=
=20
them after balloon deflation both works well with the patch. Hypervisor=20
can normally give the reclaimed memory from one CVM to another, or give=20
back to the origin CVM.