On 11/14/19 2:47 PM, Cornelia Huck wrote: > On Thu, 14 Nov 2019 14:25:00 +0100 > Claudio Imbrenda <imbrenda@xxxxxxxxxxxxx> wrote: > >> On Thu, 14 Nov 2019 14:09:46 +0100 >> Cornelia Huck <cohuck@xxxxxxxxxx> wrote: >> >>> On Thu, 24 Oct 2019 07:40:33 -0400 >>> Janosch Frank <frankja@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> >>>> --- >>>> 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?
Attachment:
signature.asc
Description: OpenPGP digital signature
