On 28/04/2020 08:55, Joerg Roedel wrote: > On Mon, Apr 27, 2020 at 10:37:41AM -0700, Andy Lutomirski wrote: >> I have a somewhat serious question: should we use IST for #VC at all? >> As I understand it, Rome and Naples make it mandatory for hypervisors >> to intercept #DB, which means that, due to the MOV SS mess, it's sort >> of mandatory to use IST for #VC. But Milan fixes the #DB issue, so, >> if we're running under a sufficiently sensible hypervisor, we don't >> need IST for #VC. > The reason for #VC being IST is not only #DB, but also SEV-SNP. SNP adds > page ownership tracking between guest and host, so that the hypervisor > can't remap guest pages without the guest noticing. > > If there is a violation of ownership, which can happen at any memory > access, there will be a #VC exception to notify the guest. And as this > can happen anywhere, for example on a carefully crafted stack page set > by userspace before doing SYSCALL, the only robust choice for #VC is to > use IST. The kernel won't ever touch the guest stack before restoring %rsp in the syscall path, but the (minimum 2) memory accesses required to save the user %rsp and load the kernel stack may be subject to #VC exceptions, as are instruction fetches at the head of the SYSCALL path. So yes - #VC needs IST. Sorry for the noise. (That said, it is unfortunate that the hypervisor messing with the memory backing the guest #VC handler results in an infinite loop, rather than an ability to cleanly terminate.) ~Andrew _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
