Message ID | 20200203131957.383915-1-borntraeger@de.ibm.com (mailing list archive) |
---|---|
Headers | show |
Series | KVM: s390: Add support for protected VMs | expand |
On Mon, 3 Feb 2020 08:19:20 -0500 Christian Borntraeger <borntraeger@de.ibm.com> wrote: > Protected VMs (PVM) are KVM VMs, where KVM can't access the VM's state > like guest memory and guest registers anymore. Instead the PVMs are > mostly managed by a new entity called Ultravisor (UV), which provides > an API, so KVM and the PV can request management actions. > > PVMs are encrypted at rest and protected from hypervisor access while > running. They switch from a normal operation into protected mode, so > we can still use the standard boot process to load a encrypted blob > and then move it into protected mode. > > Rebooting is only possible by passing through the unprotected/normal > mode and switching to protected again. > > All patches are in the protvirtv2 branch of the korg s390 kvm git > (on top of Janoschs reset rework). > > Claudio presented the technology at his presentation at KVM Forum > 2019. Do you have a changelog from v1 somewhere? > > This contains a "pretty small" common code memory management change that > will allow paging, guest backing with files etc almost just like normal > VMs. Please note that the memory management part will still see some > changes to deal with a corner case for the adapter interrupt indicator > pages. So please focus on the non-mm parts (which hopefully has > everthing addressed in the next version). Claudio will work with Andrea > regarding this.
On 03.02.20 14:23, Cornelia Huck wrote: > On Mon, 3 Feb 2020 08:19:20 -0500 > Christian Borntraeger <borntraeger@de.ibm.com> wrote: > >> Protected VMs (PVM) are KVM VMs, where KVM can't access the VM's state >> like guest memory and guest registers anymore. Instead the PVMs are >> mostly managed by a new entity called Ultravisor (UV), which provides >> an API, so KVM and the PV can request management actions. >> >> PVMs are encrypted at rest and protected from hypervisor access while >> running. They switch from a normal operation into protected mode, so >> we can still use the standard boot process to load a encrypted blob >> and then move it into protected mode. >> >> Rebooting is only possible by passing through the unprotected/normal >> mode and switching to protected again. >> >> All patches are in the protvirtv2 branch of the korg s390 kvm git >> (on top of Janoschs reset rework). >> >> Claudio presented the technology at his presentation at KVM Forum >> 2019. > > Do you have a changelog from v1 somewhere? Probably too many things have changed. There is still the old branch protvirt that rebases almost fine on top of v5.5 so here are the differences that I can see - docs as rst instead of txt - memory management now with paging - MEMOP interface now different (new code points instead of abusing the old ones) - prefix page handling with intercept 112 (prefix not secure) - interrupt refreshing exits reworked according to review - fencing in several ioctls - based on reset rework - fixes fixes and fixes > >> >> This contains a "pretty small" common code memory management change that >> will allow paging, guest backing with files etc almost just like normal >> VMs. Please note that the memory management part will still see some >> changes to deal with a corner case for the adapter interrupt indicator >> pages. So please focus on the non-mm parts (which hopefully has >> everthing addressed in the next version). Claudio will work with Andrea >> regarding this. >
On Mon, 3 Feb 2020 14:32:52 +0100 Christian Borntraeger <borntraeger@de.ibm.com> wrote: > On 03.02.20 14:23, Cornelia Huck wrote: > > On Mon, 3 Feb 2020 08:19:20 -0500 > > Christian Borntraeger <borntraeger@de.ibm.com> wrote: > > > >> Protected VMs (PVM) are KVM VMs, where KVM can't access the VM's state > >> like guest memory and guest registers anymore. Instead the PVMs are > >> mostly managed by a new entity called Ultravisor (UV), which provides > >> an API, so KVM and the PV can request management actions. > >> > >> PVMs are encrypted at rest and protected from hypervisor access while > >> running. They switch from a normal operation into protected mode, so > >> we can still use the standard boot process to load a encrypted blob > >> and then move it into protected mode. > >> > >> Rebooting is only possible by passing through the unprotected/normal > >> mode and switching to protected again. > >> > >> All patches are in the protvirtv2 branch of the korg s390 kvm git > >> (on top of Janoschs reset rework). > >> > >> Claudio presented the technology at his presentation at KVM Forum > >> 2019. > > > > Do you have a changelog from v1 somewhere? > > Probably too many things have changed. > > There is still the old branch protvirt that rebases almost fine on top of v5.5 > so here are the differences that I can see > - docs as rst instead of txt > - memory management now with paging > - MEMOP interface now different (new code points instead of abusing the old ones) > - prefix page handling with intercept 112 (prefix not secure) > - interrupt refreshing exits reworked according to review > - fencing in several ioctls > - based on reset rework > - fixes fixes and fixes And also some fixes? :) Ok, I think I'll be able to make my way through this.
On 03.02.20 14:19, Christian Borntraeger wrote: > Protected VMs (PVM) are KVM VMs, where KVM can't access the VM's state > like guest memory and guest registers anymore. Instead the PVMs are > mostly managed by a new entity called Ultravisor (UV), which provides > an API, so KVM and the PV can request management actions. > > PVMs are encrypted at rest and protected from hypervisor access while > running. They switch from a normal operation into protected mode, so > we can still use the standard boot process to load a encrypted blob > and then move it into protected mode. > > Rebooting is only possible by passing through the unprotected/normal > mode and switching to protected again. > > All patches are in the protvirtv2 branch of the korg s390 kvm git > (on top of Janoschs reset rework). > > Claudio presented the technology at his presentation at KVM Forum > 2019. > > This contains a "pretty small" common code memory management change that > will allow paging, guest backing with files etc almost just like normal > VMs. Please note that the memory management part will still see some > changes to deal with a corner case for the adapter interrupt indicator > pages. So please focus on the non-mm parts (which hopefully has > everthing addressed in the next version). Claudio will work with Andrea > regarding this. > > Christian Borntraeger (3): > KVM: s390/mm: Make pages accessible before destroying the guest > KVM: s390: protvirt: Add SCLP interrupt handling > KVM: s390: protvirt: do not inject interrupts after start > > Claudio Imbrenda (3): > mm:gup/writeback: add callbacks for inaccessible pages > s390/mm: provide memory management functions for protected KVM guests > KVM: s390/mm: handle guest unpin events > > Janosch Frank (24): > DOCUMENTATION: protvirt: Protected virtual machine introduction > KVM: s390: add new variants of UV CALL > KVM: s390: protvirt: Add initial lifecycle handling > KVM: s390: protvirt: Add KVM api documentation > KVM: s390: protvirt: Secure memory is not mergeable > KVM: s390: protvirt: Handle SE notification interceptions > KVM: s390: protvirt: Instruction emulation > KVM: s390: protvirt: Handle spec exception loops > KVM: s390: protvirt: Add new gprs location handling > KVM: S390: protvirt: Introduce instruction data area bounce buffer > KVM: s390: protvirt: handle secure guest prefix pages > KVM: s390: protvirt: Write sthyi data to instruction data area > KVM: s390: protvirt: STSI handling > KVM: s390: protvirt: disallow one_reg > KVM: s390: protvirt: Only sync fmt4 registers > KVM: s390: protvirt: Add program exception injection > DOCUMENTATION: protvirt: Diag 308 IPL > KVM: s390: protvirt: Add diag 308 subcode 8 - 10 handling > KVM: s390: protvirt: UV calls diag308 0, 1 > KVM: s390: protvirt: Report CPU state to Ultravisor > KVM: s390: protvirt: Support cmd 5 operation state > KVM: s390: protvirt: Add UV debug trace > KVM: s390: protvirt: Mask PSW interrupt bits for interception 104 and > 112 > KVM: s390: protvirt: Add UV cpu reset calls > > Michael Mueller (4): > KVM: s390: protvirt: Add interruption injection controls > KVM: s390: protvirt: Implement interruption injection > KVM: s390: protvirt: Add machine-check interruption injection controls > KVM: s390: protvirt: Implement machine-check interruption injection > > Vasily Gorbik (3): > s390/protvirt: introduce host side setup > s390/protvirt: add ultravisor initialization > s390: add (non)secure page access exceptions handlers > > .../admin-guide/kernel-parameters.txt | 5 + > Documentation/virt/kvm/api.txt | 62 +++ > Documentation/virt/kvm/s390-pv-boot.rst | 64 +++ > Documentation/virt/kvm/s390-pv.rst | 103 ++++ > MAINTAINERS | 1 + > arch/s390/boot/Makefile | 2 +- > arch/s390/boot/uv.c | 20 +- > arch/s390/include/asm/gmap.h | 3 + > arch/s390/include/asm/kvm_host.h | 112 +++- > arch/s390/include/asm/mmu.h | 2 + > arch/s390/include/asm/mmu_context.h | 1 + > arch/s390/include/asm/page.h | 5 + > arch/s390/include/asm/pgtable.h | 35 +- > arch/s390/include/asm/uv.h | 265 +++++++++- > arch/s390/kernel/Makefile | 1 + > arch/s390/kernel/pgm_check.S | 4 +- > arch/s390/kernel/setup.c | 7 +- > arch/s390/kernel/uv.c | 271 ++++++++++ > arch/s390/kvm/Kconfig | 19 + > arch/s390/kvm/Makefile | 2 +- > arch/s390/kvm/diag.c | 7 + > arch/s390/kvm/intercept.c | 107 +++- > arch/s390/kvm/interrupt.c | 211 ++++++-- > arch/s390/kvm/kvm-s390.c | 486 ++++++++++++++++-- > arch/s390/kvm/kvm-s390.h | 56 ++ > arch/s390/kvm/priv.c | 9 +- > arch/s390/kvm/pv.c | 293 +++++++++++ > arch/s390/mm/fault.c | 87 ++++ > arch/s390/mm/gmap.c | 63 ++- > include/linux/gfp.h | 6 + > include/uapi/linux/kvm.h | 47 +- > mm/gup.c | 2 + > mm/page-writeback.c | 1 + > 33 files changed, 2217 insertions(+), 142 deletions(-) > create mode 100644 Documentation/virt/kvm/s390-pv-boot.rst > create mode 100644 Documentation/virt/kvm/s390-pv.rst > create mode 100644 arch/s390/kernel/uv.c > create mode 100644 arch/s390/kvm/pv.c > Due to the huge amount of review feedback (which makestime-consuming to review if one doesn't want to comment the same thing again), I suggest sending a new RFC rather soon-ish (e.g., on a weekly basis) - if nobody objects. Would at least make my life easier :)
On 05.02.20 12:34, David Hildenbrand wrote: > Due to the huge amount of review feedback (which makestime-consuming to > review if one doesn't want to comment the same thing again), I suggest > sending a new RFC rather soon-ish (e.g., on a weekly basis) - if nobody > objects. Would at least make my life easier :) I can send one this evening?
On Wed, 5 Feb 2020 12:38:07 +0100 Christian Borntraeger <borntraeger@de.ibm.com> wrote: > On 05.02.20 12:34, David Hildenbrand wrote: > > > Due to the huge amount of review feedback (which makestime-consuming to > > review if one doesn't want to comment the same thing again), I suggest > > sending a new RFC rather soon-ish (e.g., on a weekly basis) - if nobody > > objects. Would at least make my life easier :) > > I can send one this evening? > Perhaps not that fast; I have not yet made my way through all patches yet... let's wait until the end of the week?