| Message ID | 20191024114059.102802-12-frankja@linux.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: s390: Add support for protected VMs | expand |
On Thu, 24 Oct 2019 07:40:33 -0400 Janosch Frank <frankja@linux.ibm.com> wrote: > Interrupt injection has changed a lot for protected guests, as KVM > can't access the cpus' lowcores. New fields in the state description, > like the interrupt injection control, and masked values safeguard the > guest from KVM. > > Let's add some documentation to the interrupt injection basics for > protected guests. > > Signed-off-by: Janosch Frank <frankja@linux.ibm.com> > --- > Documentation/virtual/kvm/s390-pv.txt | 27 +++++++++++++++++++++++++++ > 1 file changed, 27 insertions(+) > > diff --git a/Documentation/virtual/kvm/s390-pv.txt b/Documentation/virtual/kvm/s390-pv.txt > index 86ed95f36759..e09f2dc5f164 100644 > --- a/Documentation/virtual/kvm/s390-pv.txt > +++ b/Documentation/virtual/kvm/s390-pv.txt > @@ -21,3 +21,30 @@ normally needed to be able to run a VM, some changes have been made in > SIE behavior and fields have different meaning for a PVM. SIE exits > are minimized as much as possible to improve speed and reduce exposed > guest state. > + > + > +Interrupt injection: > + > +Interrupt injection is safeguarded by the Ultravisor and, as KVM lost > +access to the VCPUs' lowcores, is handled via the format 4 state > +description. > + > +Machine check, external, IO and restart interruptions each can be > +injected on SIE entry via a bit in the interrupt injection control > +field (offset 0x54). If the guest cpu is not enabled for the interrupt > +at the time of injection, a validity interception is recognized. The > +interrupt's data is transported via parts of the interception data > +block. "Data associated with the interrupt needs to be placed into the respective fields in the interception data block to be injected into the guest." ? > + > +Program and Service Call exceptions have another layer of > +safeguarding, they are only injectable, when instructions have > +intercepted into KVM and such an exception can be an emulation result. I find this sentence hard to parse... not sure if I understand it correctly. "They can only be injected if the exception can be encountered during emulation of instructions that had been intercepted into KVM." ? > + > + > +Mask notification interceptions: > +As a replacement for the lctl(g) and lpsw(e) interception, two new > +interception codes have been introduced. One which tells us that CRs > +0, 6 or 14 have been changed and therefore interrupt masking might > +have changed. And one for PSW bit 13 changes. The CRs and the PSW in Might be helpful to mention that this bit covers machine checks, which do not get a separate bit in the control block :) > +the state description only contain the mask bits and no further info > +like the current instruction address. "The CRs and the PSW in the state description only contain the bits referring to interrupt masking; other fields like e.g. the current instruction address are zero." ?
On Thu, 14 Nov 2019 14:09:46 +0100 Cornelia Huck <cohuck@redhat.com> wrote: > On Thu, 24 Oct 2019 07:40:33 -0400 > Janosch Frank <frankja@linux.ibm.com> wrote: > > > Interrupt injection has changed a lot for protected guests, as KVM > > can't access the cpus' lowcores. New fields in the state > > description, like the interrupt injection control, and masked > > values safeguard the guest from KVM. > > > > Let's add some documentation to the interrupt injection basics for > > protected guests. > > > > Signed-off-by: Janosch Frank <frankja@linux.ibm.com> > > --- > > Documentation/virtual/kvm/s390-pv.txt | 27 > > +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) > > > > diff --git a/Documentation/virtual/kvm/s390-pv.txt > > b/Documentation/virtual/kvm/s390-pv.txt index > > 86ed95f36759..e09f2dc5f164 100644 --- > > a/Documentation/virtual/kvm/s390-pv.txt +++ > > b/Documentation/virtual/kvm/s390-pv.txt @@ -21,3 +21,30 @@ normally > > needed to be able to run a VM, some changes have been made in SIE > > behavior and fields have different meaning for a PVM. SIE exits are > > minimized as much as possible to improve speed and reduce exposed > > guest state. + > > + > > +Interrupt injection: > > + > > +Interrupt injection is safeguarded by the Ultravisor and, as KVM > > lost +access to the VCPUs' lowcores, is handled via the format 4 > > state +description. > > + > > +Machine check, external, IO and restart interruptions each can be > > +injected on SIE entry via a bit in the interrupt injection control > > +field (offset 0x54). If the guest cpu is not enabled for the > > interrupt +at the time of injection, a validity interception is > > recognized. The +interrupt's data is transported via parts of the > > interception data +block. > > "Data associated with the interrupt needs to be placed into the > respective fields in the interception data block to be injected into > the guest." > > ? when a normal guest intercepts an exception, depending on the exception type, the parameters are saved in the state description at specified offsets, between 0xC0 amd 0xF8 to perform interrupt injection for secure guests, the same fields are used to specify the interrupt parameters that should be injected into the guest > > + > > +Program and Service Call exceptions have another layer of > > +safeguarding, they are only injectable, when instructions have > > +intercepted into KVM and such an exception can be an emulation > > result. > > I find this sentence hard to parse... not sure if I understand it > correctly. > > "They can only be injected if the exception can be encountered during > emulation of instructions that had been intercepted into KVM." yes > > > + > > + > > +Mask notification interceptions: > > +As a replacement for the lctl(g) and lpsw(e) interception, two new > > +interception codes have been introduced. One which tells us that > > CRs +0, 6 or 14 have been changed and therefore interrupt masking > > might +have changed. And one for PSW bit 13 changes. The CRs and > > the PSW in > > Might be helpful to mention that this bit covers machine checks, which > do not get a separate bit in the control block :) > > > +the state description only contain the mask bits and no further > > info +like the current instruction address. > > "The CRs and the PSW in the state description only contain the bits > referring to interrupt masking; other fields like e.g. the current > instruction address are zero." wait state is saved too CC is write only, and is only inspected by hardware/firmware when KVM/qemu is interpreting an instruction that expects a new CC to be set, and then only the expected CCs are allowed (e.g. if an instruction only allows CC 0 or 3, 2 cannot be specified)
On Thu, 14 Nov 2019 14:25:00 +0100 Claudio Imbrenda <imbrenda@linux.ibm.com> wrote: > On Thu, 14 Nov 2019 14:09:46 +0100 > Cornelia Huck <cohuck@redhat.com> wrote: > > > On Thu, 24 Oct 2019 07:40:33 -0400 > > Janosch Frank <frankja@linux.ibm.com> wrote: > > > > > Interrupt injection has changed a lot for protected guests, as KVM > > > can't access the cpus' lowcores. New fields in the state > > > description, like the interrupt injection control, and masked > > > values safeguard the guest from KVM. > > > > > > Let's add some documentation to the interrupt injection basics for > > > protected guests. > > > > > > Signed-off-by: Janosch Frank <frankja@linux.ibm.com> > > > --- > > > Documentation/virtual/kvm/s390-pv.txt | 27 > > > +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) > > > > > > diff --git a/Documentation/virtual/kvm/s390-pv.txt > > > b/Documentation/virtual/kvm/s390-pv.txt index > > > 86ed95f36759..e09f2dc5f164 100644 --- > > > a/Documentation/virtual/kvm/s390-pv.txt +++ > > > b/Documentation/virtual/kvm/s390-pv.txt @@ -21,3 +21,30 @@ normally > > > needed to be able to run a VM, some changes have been made in SIE > > > behavior and fields have different meaning for a PVM. SIE exits are > > > minimized as much as possible to improve speed and reduce exposed > > > guest state. + > > > + > > > +Interrupt injection: > > > + > > > +Interrupt injection is safeguarded by the Ultravisor and, as KVM > > > lost +access to the VCPUs' lowcores, is handled via the format 4 > > > state +description. > > > + > > > +Machine check, external, IO and restart interruptions each can be > > > +injected on SIE entry via a bit in the interrupt injection control > > > +field (offset 0x54). If the guest cpu is not enabled for the > > > interrupt +at the time of injection, a validity interception is > > > recognized. The +interrupt's data is transported via parts of the > > > interception data +block. > > > > "Data associated with the interrupt needs to be placed into the > > respective fields in the interception data block to be injected into > > the guest." > > > > ? > > when a normal guest intercepts an exception, depending on the exception > type, the parameters are saved in the state description at specified > offsets, between 0xC0 amd 0xF8 > > to perform interrupt injection for secure guests, the same fields are > used to specify the interrupt parameters that should be injected into > the guest Ok, maybe add that as well. > > > > + > > > +Program and Service Call exceptions have another layer of > > > +safeguarding, they are only injectable, when instructions have > > > +intercepted into KVM and such an exception can be an emulation > > > result. > > > > I find this sentence hard to parse... not sure if I understand it > > correctly. > > > > "They can only be injected if the exception can be encountered during > > emulation of instructions that had been intercepted into KVM." > > yes > > > > > > + > > > + > > > +Mask notification interceptions: > > > +As a replacement for the lctl(g) and lpsw(e) interception, two new > > > +interception codes have been introduced. One which tells us that > > > CRs +0, 6 or 14 have been changed and therefore interrupt masking > > > might +have changed. And one for PSW bit 13 changes. The CRs and > > > the PSW in > > > > Might be helpful to mention that this bit covers machine checks, which > > do not get a separate bit in the control block :) > > > > > +the state description only contain the mask bits and no further > > > info +like the current instruction address. > > > > "The CRs and the PSW in the state description only contain the bits > > referring to interrupt masking; other fields like e.g. the current > > instruction address are zero." > > wait state is saved too > > CC is write only, and is only inspected by hardware/firmware when > KVM/qemu is interpreting an instruction that expects a new CC to be set, > and then only the expected CCs are allowed (e.g. if an instruction only > allows CC 0 or 3, 2 cannot be specified) So I'm wondering how much of that should go into the document... maybe just "The CRs and the PSW in the state description contain less information than for normal guests: most information that does not refer to interrupt masking is not available to the hypervisor." ?
On 11/14/19 2:47 PM, Cornelia Huck wrote: > On Thu, 14 Nov 2019 14:25:00 +0100 > Claudio Imbrenda <imbrenda@linux.ibm.com> wrote: > >> On Thu, 14 Nov 2019 14:09:46 +0100 >> Cornelia Huck <cohuck@redhat.com> wrote: >> >>> On Thu, 24 Oct 2019 07:40:33 -0400 >>> Janosch Frank <frankja@linux.ibm.com> wrote: >>> >>>> Interrupt injection has changed a lot for protected guests, as KVM >>>> can't access the cpus' lowcores. New fields in the state >>>> description, like the interrupt injection control, and masked >>>> values safeguard the guest from KVM. >>>> >>>> Let's add some documentation to the interrupt injection basics for >>>> protected guests. >>>> >>>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> >>>> --- >>>> Documentation/virtual/kvm/s390-pv.txt | 27 >>>> +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) >>>> >>>> diff --git a/Documentation/virtual/kvm/s390-pv.txt >>>> b/Documentation/virtual/kvm/s390-pv.txt index >>>> 86ed95f36759..e09f2dc5f164 100644 --- >>>> a/Documentation/virtual/kvm/s390-pv.txt +++ >>>> b/Documentation/virtual/kvm/s390-pv.txt @@ -21,3 +21,30 @@ normally >>>> needed to be able to run a VM, some changes have been made in SIE >>>> behavior and fields have different meaning for a PVM. SIE exits are >>>> minimized as much as possible to improve speed and reduce exposed >>>> guest state. + >>>> + >>>> +Interrupt injection: >>>> + >>>> +Interrupt injection is safeguarded by the Ultravisor and, as KVM >>>> lost +access to the VCPUs' lowcores, is handled via the format 4 >>>> state +description. >>>> + >>>> +Machine check, external, IO and restart interruptions each can be >>>> +injected on SIE entry via a bit in the interrupt injection control >>>> +field (offset 0x54). If the guest cpu is not enabled for the >>>> interrupt +at the time of injection, a validity interception is >>>> recognized. The +interrupt's data is transported via parts of the >>>> interception data +block. >>> >>> "Data associated with the interrupt needs to be placed into the >>> respective fields in the interception data block to be injected into >>> the guest." >>> >>> ? >> >> when a normal guest intercepts an exception, depending on the exception >> type, the parameters are saved in the state description at specified >> offsets, between 0xC0 amd 0xF8 >> >> to perform interrupt injection for secure guests, the same fields are >> used to specify the interrupt parameters that should be injected into >> the guest > > Ok, maybe add that as well. > >> >>>> + >>>> +Program and Service Call exceptions have another layer of >>>> +safeguarding, they are only injectable, when instructions have >>>> +intercepted into KVM and such an exception can be an emulation >>>> result. >>> >>> I find this sentence hard to parse... not sure if I understand it >>> correctly. >>> >>> "They can only be injected if the exception can be encountered during >>> emulation of instructions that had been intercepted into KVM." >> >> yes >> >>> >>>> + >>>> + >>>> +Mask notification interceptions: >>>> +As a replacement for the lctl(g) and lpsw(e) interception, two new >>>> +interception codes have been introduced. One which tells us that >>>> CRs +0, 6 or 14 have been changed and therefore interrupt masking >>>> might +have changed. And one for PSW bit 13 changes. The CRs and >>>> the PSW in >>> >>> Might be helpful to mention that this bit covers machine checks, which >>> do not get a separate bit in the control block :) >>> >>>> +the state description only contain the mask bits and no further >>>> info +like the current instruction address. >>> >>> "The CRs and the PSW in the state description only contain the bits >>> referring to interrupt masking; other fields like e.g. the current >>> instruction address are zero." >> >> wait state is saved too >> >> CC is write only, and is only inspected by hardware/firmware when >> KVM/qemu is interpreting an instruction that expects a new CC to be set, >> and then only the expected CCs are allowed (e.g. if an instruction only >> allows CC 0 or 3, 2 cannot be specified) > > So I'm wondering how much of that should go into the document... maybe > just > > "The CRs and the PSW in the state description contain less information > than for normal guests: most information that does not refer to > interrupt masking is not available to the hypervisor." > > ? > I'm not liking that too much and I'm also asking myself it makes sense to fix documentation via mails. How about an etherpad?
diff --git a/Documentation/virtual/kvm/s390-pv.txt b/Documentation/virtual/kvm/s390-pv.txt index 86ed95f36759..e09f2dc5f164 100644 --- a/Documentation/virtual/kvm/s390-pv.txt +++ b/Documentation/virtual/kvm/s390-pv.txt @@ -21,3 +21,30 @@ normally needed to be able to run a VM, some changes have been made in SIE behavior and fields have different meaning for a PVM. SIE exits are minimized as much as possible to improve speed and reduce exposed guest state. + + +Interrupt injection: + +Interrupt injection is safeguarded by the Ultravisor and, as KVM lost +access to the VCPUs' lowcores, is handled via the format 4 state +description. + +Machine check, external, IO and restart interruptions each can be +injected on SIE entry via a bit in the interrupt injection control +field (offset 0x54). If the guest cpu is not enabled for the interrupt +at the time of injection, a validity interception is recognized. The +interrupt's data is transported via parts of the interception data +block. + +Program and Service Call exceptions have another layer of +safeguarding, they are only injectable, when instructions have +intercepted into KVM and such an exception can be an emulation result. + + +Mask notification interceptions: +As a replacement for the lctl(g) and lpsw(e) interception, two new +interception codes have been introduced. One which tells us that CRs +0, 6 or 14 have been changed and therefore interrupt masking might +have changed. And one for PSW bit 13 changes. The CRs and the PSW in +the state description only contain the mask bits and no further info +like the current instruction address.
Interrupt injection has changed a lot for protected guests, as KVM can't access the cpus' lowcores. New fields in the state description, like the interrupt injection control, and masked values safeguard the guest from KVM. Let's add some documentation to the interrupt injection basics for protected guests. Signed-off-by: Janosch Frank <frankja@linux.ibm.com> --- Documentation/virtual/kvm/s390-pv.txt | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+)