On 10.02.20 19:17, David Hildenbrand wrote: > On 07.02.20 12:39, Christian Borntraeger wrote: >> From: Claudio Imbrenda <imbrenda@xxxxxxxxxxxxx> >> >> With the introduction of protected KVM guests on s390 there is now a >> concept of inaccessible pages. These pages need to be made accessible >> before the host can access them. >> >> While cpu accesses will trigger a fault that can be resolved, I/O >> accesses will just fail. We need to add a callback into architecture >> code for places that will do I/O, namely when writeback is started or >> when a page reference is taken. > > My question would be: What guarantees that the page will stay accessible > (for I/O)? IIRC, pages can be converted back to secure/inaccessible > whenever the guest wants to access them. How will that be dealt with? Yes, in patch 5 we do use the page lock, PageWriteBack and page_ref_freeze to only make the page secure again if no I/O is going to be started or still running. We have minimized the common code impact (just these 3 callbacks) so that architecture code can do the right thing. > > I would assume some magic counter that tracks if the page still has to > remain accessible. Once all clients that require the page to be > "accessible" on the I/O path are done, the page can be made inaccessible > again. But then, I would assume there would be something like a > > /* make page accessible and make sure the page will remain accessible */ > arch_get_page_accessible(page); > > /* we're done dealing with the page content */ > arch_put_page_accessible(page); > > You mention page references. I think you should elaborate how that is > expected to work in the patch description more detailed. > > > (side note: I assume you guys have a plan for dealing with kdump wanting > to dump inaccessible pages. the kexec kernel would have to talk to the > UV to convert pages - and also make pages accessible on the I/O path I > guess - or one would want to mark and skip encrypted pages completely in > kdump somehow, as the content is essentially garbage) On kexec and kdump the ultravisor is called as part of the the diagnose 308 subcodes 0 and 1 to make sure that a: kdump works (no fault on a previously secure page) and b: the content of the secure page is no longer accessible.
