Re: [PATCH v5 07/18] s390x: protvirt: Inhibit balloon when switching to protected mode

From: Cornelia Huck <cohuck@redhat.com>
To: Janosch Frank <frankja@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
	qemu-s390x@nongnu.org, qemu-devel@nongnu.org,
	David Hildenbrand <david@redhat.com>
Subject: Re: [PATCH v5 07/18] s390x: protvirt: Inhibit balloon when switching to protected mode
Date: Wed, 26 Feb 2020 19:24:04 +0100	[thread overview]
Message-ID: <20200226192404.57b6ef61.cohuck@redhat.com> (raw)
In-Reply-To: <556c23cb-7648-f4f6-aef4-728a164d9502@linux.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 2645 bytes --]

On Wed, 26 Feb 2020 16:30:32 +0100
Janosch Frank <frankja@linux.ibm.com> wrote:

> On 2/26/20 4:16 PM, David Hildenbrand wrote:
> > On 26.02.20 16:06, Christian Borntraeger wrote:  
> >>
> >>
> >> On 26.02.20 15:59, David Hildenbrand wrote:  
> >>> On 26.02.20 13:20, Janosch Frank wrote:  
> >>>> Ballooning in protected VMs can only be done when the guest shares the
> >>>> pages it gives to the host. Hence, until we have a solution for this
> >>>> in the guest kernel, we inhibit ballooning when switching into
> >>>> protected mode and reverse that once we move out of it.  
> >>>
> >>> I don't understand what you mean here, sorry. zapping a page will mean
> >>> that a fresh one will be faulted in when accessed. And AFAIK, that means
> >>> it will be encrypted again when needed.
> >>>
> >>> Is that more like the UV will detect this as an integrity issue and
> >>> crash the VM?  
> >>
> >> yes, the UV will detect a fresh page as an integrity issue.
> >> Only if the page was defined to be shared by the guest, we would avoid the
> >> integrity check.
> >>  
> > 
> > Please make that clearer in the patch description. With that
> > 
> > Reviewed-by: David Hildenbrand <david@redhat.com>
> >   
> 
> How about:
> s390x: protvirt: Inhibit balloon when switching to protected mode
> 
> Ballooning in protected VMs can only be done when the guest shares the
> pages it gives to the host. If pages are not shared, the integrity
> checks will fail once those pages have been altered and are given back
> to the guest.

This makes sense to me...

> 
> Hence, until we have a solution for this in the guest kernel, we
> inhibit ballooning when switching into protected mode and reverse that
> once we move out of it.

...however, I'm scratching my head here.

If we have a future guest that knows how to handle this, how do we
know? We know that the current Linux driver clears
VIRTIO_F_IOMMU_PLATFORM during feature negotiation, and presumably a
guest that knows how to handle this will not do that. But it still
won't work as expected, as we inhibit ballooning...

So, either
- we don't inhibit ballooning now; any guest that clears the (required)
  virtio feature bit won't be able to drive the virtio-balloon device
  anyway, but a future guest that negotiates the bit would work; or
- we inhibit ballooning now; no guest can therefore use ballooning,
  regardless what they are doing or not doing (this includes guests
  that negotiate the feature bit, but fail to handle pages properly).

Or is there some other reason why we need to inhibit ballooning for
protected vms?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]