[RFC,11/37] DOCUMENTATION: protvirt: Interrupt injection
diff mbox series

Message ID 20191024114059.102802-12-frankja@linux.ibm.com
State New
Headers show
Series
  • KVM: s390: Add support for protected VMs
Related show

Commit Message

Janosch Frank Oct. 24, 2019, 11:40 a.m. UTC
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(+)

Comments

Cornelia Huck Nov. 14, 2019, 1:09 p.m. UTC | #1
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."

?
Claudio Imbrenda Nov. 14, 2019, 1:25 p.m. UTC | #2
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)
Cornelia Huck Nov. 14, 2019, 1:47 p.m. UTC | #3
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."

?
Janosch Frank Nov. 14, 2019, 4:33 p.m. UTC | #4
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?

Patch
diff mbox series

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.