| Message ID | 1531587940-2490-10-git-send-email-christoffer.dall@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 14/07/18 18:05, Christoffer Dall wrote: > Update the documentation to reflect the ordering requirements of > restoring GICv2 distributor registers and remove outdated limitations in > the documentation while we're at it. > > Signed-off-by: Christoffer Dall <christoffer.dall@arm.com> > --- > Documentation/virtual/kvm/devices/arm-vgic.txt | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/Documentation/virtual/kvm/devices/arm-vgic.txt b/Documentation/virtual/kvm/devices/arm-vgic.txt > index b3ce126..c9a6393 100644 > --- a/Documentation/virtual/kvm/devices/arm-vgic.txt > +++ b/Documentation/virtual/kvm/devices/arm-vgic.txt > @@ -49,9 +49,12 @@ Groups: > index is specified with the vcpu_index field. Note that most distributor > fields are not banked, but return the same value regardless of the > vcpu_index used to access the register. > - Limitations: > - - Priorities are not implemented, and registers are RAZ/WI > - - Currently only implemented for KVM_DEV_TYPE_ARM_VGIC_V2. > + > + GICD_IIDR.Revision is updated when the KVM implementation of an emulated > + GICv2 is changed. Userspace should read GICD_IIDR from KVM and write back > + the read value to confirm its expected behavior is aligned with the KVM > + implementation. To properly restore the interrupt group configuration, > + GICD_IIDR should be written before any other registers. I'd like to make it crystal clear that writing to IIDR doesn't allow to select a behaviour, and is merely a confirmation that host and guest do agree on either revision 0 (no write) or revision n (n being read and written back). Also, on ordering: does the write to IIDR have to happen before any write to other distributor registers? Or to any GIC register? I think you mean the former, but I wonder if we shouldn't mandate the latter, just to be sure... > Errors: > -ENXIO: Getting or setting this register is not yet supported > -EBUSY: One or more VCPUs are running > @@ -94,9 +97,6 @@ Groups: > use the lower 5 bits to communicate with the KVM device and must shift the > value left by 3 places to obtain the actual priority mask level. > > - Limitations: > - - Priorities are not implemented, and registers are RAZ/WI > - - Currently only implemented for KVM_DEV_TYPE_ARM_VGIC_V2. > Errors: > -ENXIO: Getting or setting this register is not yet supported > -EBUSY: One or more VCPUs are running > Finally, do we want to to extend the same requirements to GICv3, for the sake of uniformity? Thanks, M.
On Mon, Jul 16, 2018 at 09:52:04AM +0100, Marc Zyngier wrote: > On 14/07/18 18:05, Christoffer Dall wrote: > > Update the documentation to reflect the ordering requirements of > > restoring GICv2 distributor registers and remove outdated limitations in > > the documentation while we're at it. > > > > Signed-off-by: Christoffer Dall <christoffer.dall@arm.com> > > --- > > Documentation/virtual/kvm/devices/arm-vgic.txt | 12 ++++++------ > > 1 file changed, 6 insertions(+), 6 deletions(-) > > > > diff --git a/Documentation/virtual/kvm/devices/arm-vgic.txt b/Documentation/virtual/kvm/devices/arm-vgic.txt > > index b3ce126..c9a6393 100644 > > --- a/Documentation/virtual/kvm/devices/arm-vgic.txt > > +++ b/Documentation/virtual/kvm/devices/arm-vgic.txt > > @@ -49,9 +49,12 @@ Groups: > > index is specified with the vcpu_index field. Note that most distributor > > fields are not banked, but return the same value regardless of the > > vcpu_index used to access the register. > > - Limitations: > > - - Priorities are not implemented, and registers are RAZ/WI > > - - Currently only implemented for KVM_DEV_TYPE_ARM_VGIC_V2. > > + > > + GICD_IIDR.Revision is updated when the KVM implementation of an emulated > > + GICv2 is changed. Userspace should read GICD_IIDR from KVM and write back > > + the read value to confirm its expected behavior is aligned with the KVM > > + implementation. To properly restore the interrupt group configuration, > > + GICD_IIDR should be written before any other registers. > > I'd like to make it crystal clear that writing to IIDR doesn't allow to > select a behaviour, and is merely a confirmation that host and guest do > agree on either revision 0 (no write) or revision n (n being read and > written back). > > Also, on ordering: does the write to IIDR have to happen before any > write to other distributor registers? Or to any GIC register? I think > you mean the former, but I wonder if we shouldn't mandate the latter, > just to be sure... > I was thinking that IIDR should simply be the very first thing you write, I'll clarify the intent. > > Errors: > > -ENXIO: Getting or setting this register is not yet supported > > -EBUSY: One or more VCPUs are running > > @@ -94,9 +97,6 @@ Groups: > > use the lower 5 bits to communicate with the KVM device and must shift the > > value left by 3 places to obtain the actual priority mask level. > > > > - Limitations: > > - - Priorities are not implemented, and registers are RAZ/WI > > - - Currently only implemented for KVM_DEV_TYPE_ARM_VGIC_V2. > > Errors: > > -ENXIO: Getting or setting this register is not yet supported > > -EBUSY: One or more VCPUs are running > > > > Finally, do we want to to extend the same requirements to GICv3, for the > sake of uniformity? Probably. I'll check the userspace implementation if that would break compatibility with today. Thanks, -Christoffer IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Mon, Jul 16, 2018 at 09:52:04AM +0100, Marc Zyngier wrote: > On 14/07/18 18:05, Christoffer Dall wrote: > > Update the documentation to reflect the ordering requirements of > > restoring GICv2 distributor registers and remove outdated limitations in > > the documentation while we're at it. > > > > Signed-off-by: Christoffer Dall <christoffer.dall@arm.com> > > --- > > Documentation/virtual/kvm/devices/arm-vgic.txt | 12 ++++++------ > > 1 file changed, 6 insertions(+), 6 deletions(-) > > > > diff --git a/Documentation/virtual/kvm/devices/arm-vgic.txt b/Documentation/virtual/kvm/devices/arm-vgic.txt > > index b3ce126..c9a6393 100644 > > --- a/Documentation/virtual/kvm/devices/arm-vgic.txt > > +++ b/Documentation/virtual/kvm/devices/arm-vgic.txt > > @@ -49,9 +49,12 @@ Groups: > > index is specified with the vcpu_index field. Note that most distributor > > fields are not banked, but return the same value regardless of the > > vcpu_index used to access the register. > > - Limitations: > > - - Priorities are not implemented, and registers are RAZ/WI > > - - Currently only implemented for KVM_DEV_TYPE_ARM_VGIC_V2. > > + > > + GICD_IIDR.Revision is updated when the KVM implementation of an emulated > > + GICv2 is changed. Userspace should read GICD_IIDR from KVM and write back > > + the read value to confirm its expected behavior is aligned with the KVM > > + implementation. To properly restore the interrupt group configuration, > > + GICD_IIDR should be written before any other registers. > > I'd like to make it crystal clear that writing to IIDR doesn't allow to > select a behaviour, and is merely a confirmation that host and guest do > agree on either revision 0 (no write) or revision n (n being read and > written back). > But that's not really true though, because userspace can read rev 0, and still have "no write", or read and write n for n >= 1 and have "write". I guess I'm not completely sure which wording you'd like me to add? Thanks, -Christoffer IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On 16/07/18 11:34, Christoffer Dall wrote: > On Mon, Jul 16, 2018 at 09:52:04AM +0100, Marc Zyngier wrote: >> On 14/07/18 18:05, Christoffer Dall wrote: >>> Update the documentation to reflect the ordering requirements of >>> restoring GICv2 distributor registers and remove outdated limitations in >>> the documentation while we're at it. >>> >>> Signed-off-by: Christoffer Dall <christoffer.dall@arm.com> >>> --- >>> Documentation/virtual/kvm/devices/arm-vgic.txt | 12 ++++++------ >>> 1 file changed, 6 insertions(+), 6 deletions(-) >>> >>> diff --git a/Documentation/virtual/kvm/devices/arm-vgic.txt b/Documentation/virtual/kvm/devices/arm-vgic.txt >>> index b3ce126..c9a6393 100644 >>> --- a/Documentation/virtual/kvm/devices/arm-vgic.txt >>> +++ b/Documentation/virtual/kvm/devices/arm-vgic.txt >>> @@ -49,9 +49,12 @@ Groups: >>> index is specified with the vcpu_index field. Note that most distributor >>> fields are not banked, but return the same value regardless of the >>> vcpu_index used to access the register. >>> - Limitations: >>> - - Priorities are not implemented, and registers are RAZ/WI >>> - - Currently only implemented for KVM_DEV_TYPE_ARM_VGIC_V2. >>> + >>> + GICD_IIDR.Revision is updated when the KVM implementation of an emulated >>> + GICv2 is changed. Userspace should read GICD_IIDR from KVM and write back >>> + the read value to confirm its expected behavior is aligned with the KVM >>> + implementation. To properly restore the interrupt group configuration, >>> + GICD_IIDR should be written before any other registers. >> >> I'd like to make it crystal clear that writing to IIDR doesn't allow to >> select a behaviour, and is merely a confirmation that host and guest do >> agree on either revision 0 (no write) or revision n (n being read and >> written back). >> > > But that's not really true though, because userspace can read rev 0, and > still have "no write", or read and write n for n >= 1 and have "write". > > I guess I'm not completely sure which wording you'd like me to add? I'm not sure either, because I find the behaviour of this register a bit odd. We always default to rev 0, and allow the behaviour to be switched to rev 2 if we write 2 to it. But we can't select rev 1. So in a way, it is not a revision selection API (like we have with the ITS), but a "I don't want rev 0" API. It works for what we have now, but I'm not sure how future proof it is (I guess we can cross that bridge when we get there). Another thing is that the guest will always see rev 2, even when it runs with the rev 0 behaviour, which is quite bizarre. M.
On Mon, Jul 16, 2018 at 12:07:04PM +0100, Marc Zyngier wrote: > On 16/07/18 11:34, Christoffer Dall wrote: > > On Mon, Jul 16, 2018 at 09:52:04AM +0100, Marc Zyngier wrote: > >> On 14/07/18 18:05, Christoffer Dall wrote: > >>> Update the documentation to reflect the ordering requirements of > >>> restoring GICv2 distributor registers and remove outdated limitations in > >>> the documentation while we're at it. > >>> > >>> Signed-off-by: Christoffer Dall <christoffer.dall@arm.com> > >>> --- > >>> Documentation/virtual/kvm/devices/arm-vgic.txt | 12 ++++++------ > >>> 1 file changed, 6 insertions(+), 6 deletions(-) > >>> > >>> diff --git a/Documentation/virtual/kvm/devices/arm-vgic.txt b/Documentation/virtual/kvm/devices/arm-vgic.txt > >>> index b3ce126..c9a6393 100644 > >>> --- a/Documentation/virtual/kvm/devices/arm-vgic.txt > >>> +++ b/Documentation/virtual/kvm/devices/arm-vgic.txt > >>> @@ -49,9 +49,12 @@ Groups: > >>> index is specified with the vcpu_index field. Note that most distributor > >>> fields are not banked, but return the same value regardless of the > >>> vcpu_index used to access the register. > >>> - Limitations: > >>> - - Priorities are not implemented, and registers are RAZ/WI > >>> - - Currently only implemented for KVM_DEV_TYPE_ARM_VGIC_V2. > >>> + > >>> + GICD_IIDR.Revision is updated when the KVM implementation of an emulated > >>> + GICv2 is changed. Userspace should read GICD_IIDR from KVM and write back > >>> + the read value to confirm its expected behavior is aligned with the KVM > >>> + implementation. To properly restore the interrupt group configuration, > >>> + GICD_IIDR should be written before any other registers. > >> > >> I'd like to make it crystal clear that writing to IIDR doesn't allow to > >> select a behaviour, and is merely a confirmation that host and guest do > >> agree on either revision 0 (no write) or revision n (n being read and > >> written back). > >> > > > > But that's not really true though, because userspace can read rev 0, and > > still have "no write", or read and write n for n >= 1 and have "write". > > > > I guess I'm not completely sure which wording you'd like me to add? > I'm not sure either, because I find the behaviour of this register a bit > odd. We always default to rev 0, Not quite. From the PoV of the guest, we default to rev 2 (which it cannot differentiate from rev 1), becasue it is itself allowed to change the groups, which it couldn't do in rev 0. However, from the PoV of userspace... > and allow the behaviour to be switched > to rev 2 if we write 2 to it. But we can't select rev 1. For future changes, which are likely to be unrelated to IGROUPR, you get rev N behavior where N is the most recent N, except that IGROUPR won't be writable unless userspace confirms that it knows about revisions. > > So in a way, it is not a revision selection API (like we have with the > ITS), but a "I don't want rev 0" API. It works for what we have now, but > I'm not sure how future proof it is (I guess we can cross that bridge > when we get there). This is by design. I would like to avoid having switch (rev) { case 2: logic2(); case 3: logic3(); case 4: logic4(); } spread out over all uaccess writes. Instead, I'd like for the GICD_IIDR write to fail, and let userspace deal with things for the future. However, the problem is that we don't have any such logic to use right now, and therefore we have to support the backwards compat case now. We could introduce a separate attribute on the GIC (IGROUPR_WRITABLE) instead, I just found it less noisy to piggy back on the GICD_IIDR. Is that acceptable? > > Another thing is that the guest will always see rev 2, even when it runs > with the rev 0 behaviour, which is quite bizarre. > I don't think this is bizarre. As it stand now, it will see rev 1 behavior, which is identical from the guest PoV to rev 2 behavior. And I don't think there's anything in the architecture that says that a revision change must be directly observable by the guest? In any case, I've come up with a new proposal for some documentation and I hope it will be more to your liking. Thanks, -Christoffer
diff --git a/Documentation/virtual/kvm/devices/arm-vgic.txt b/Documentation/virtual/kvm/devices/arm-vgic.txt index b3ce126..c9a6393 100644 --- a/Documentation/virtual/kvm/devices/arm-vgic.txt +++ b/Documentation/virtual/kvm/devices/arm-vgic.txt @@ -49,9 +49,12 @@ Groups: index is specified with the vcpu_index field. Note that most distributor fields are not banked, but return the same value regardless of the vcpu_index used to access the register. - Limitations: - - Priorities are not implemented, and registers are RAZ/WI - - Currently only implemented for KVM_DEV_TYPE_ARM_VGIC_V2. + + GICD_IIDR.Revision is updated when the KVM implementation of an emulated + GICv2 is changed. Userspace should read GICD_IIDR from KVM and write back + the read value to confirm its expected behavior is aligned with the KVM + implementation. To properly restore the interrupt group configuration, + GICD_IIDR should be written before any other registers. Errors: -ENXIO: Getting or setting this register is not yet supported -EBUSY: One or more VCPUs are running @@ -94,9 +97,6 @@ Groups: use the lower 5 bits to communicate with the KVM device and must shift the value left by 3 places to obtain the actual priority mask level. - Limitations: - - Priorities are not implemented, and registers are RAZ/WI - - Currently only implemented for KVM_DEV_TYPE_ARM_VGIC_V2. Errors: -ENXIO: Getting or setting this register is not yet supported -EBUSY: One or more VCPUs are running
Update the documentation to reflect the ordering requirements of restoring GICv2 distributor registers and remove outdated limitations in the documentation while we're at it. Signed-off-by: Christoffer Dall <christoffer.dall@arm.com> --- Documentation/virtual/kvm/devices/arm-vgic.txt | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) -- 2.7.4 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.