On Fri, 15 Feb 2019 17:26:02 +0000 Dave Martin <Dave.Martin at arm.com> wrote: > On Fri, Feb 15, 2019 at 11:42:27AM +0000, Marc Zyngier wrote: > > On Fri, 15 Feb 2019 09:58:57 +0000, > > Andre Przywara <andre.przywara at arm.com> wrote: > > > > > > On Wed, 30 Jan 2019 11:39:00 +0000 > > > Andre Przywara <andre.przywara at arm.com> wrote: > > > > > > Peter, Marc, Christoffer, > > > > > > can we have an opinion on whether it's useful to introduce some > > > common scheme for firmware workaround system registers (parts of > > > KVM_REG_ARM_FW_REG(x)), which would allow checking them for > > > compatibility between two kernels without specifically knowing about > > > them? > > > Dave suggested to introduce some kind of signed encoding in the 4 > > > LSBs for all those registers (including future ones), where 0 means > > > UNKNOWN and greater values are better. So without knowing about the > > > particular register, one could judge whether it's safe to migrate. > > > I am just not sure how useful this is, given that QEMU seems to ask > > > the receiving kernel about any sysreg, and doesn't particularly care > > > about the meaning of those registers. And I am not sure we really > > > want to introduce some kind of forward looking scheme in the kernel > > > here, short of a working crystal ball. I think the kernel policy was > > > always to be as strict as possible about those things. > > > > I honestly don't understand how userspace can decide whether a given > > configuration is migratable or not solely based on the value of such a > > register. In my experience, the target system has a role to play, and > > is the only place where we can find out about whether migration is > > actually possible. > > Both origin and target system need to be taken into account. I don't > think that's anything new. Well, that was what I understood from Andre's question. > > > As you said, userspace doesn't interpret the data, nor should it. It > > is only on the receiving end that compatibility is assessed and > > whether some level of compatibility can be safely ensured. > > > > So to sum it up, I don't believe in this approach as a general way of > > describing the handling or errata. > > For context, my idea attempted to put KVM, not userspace, in charge of > the decision: userspace applies fixed comparison rules determined ahead > of time, but KVM supplies the values compared (and hence determines the > result). > > My worry was that otherwise we may end up with a wild-west tangle of > arbitrary properties that userspace needs specific knowledge about. And this is where our understanding differs. I do not think userspace has to care at all. All it has to do is to provide the saved register values to the target system, and let KVM accept or refuse these settings. I can't see what providing a set of predefined values back to userspace gains us. An unknown register on the target system fails the restore phase: that's absolutely fine, as we don't want to run on a system that doesn't know about the mitigation. An incompatible value fails the restore as well, as KVM itself finds that this is a service it cannot safely provide. No userspace involvement, no QEMU upgrade required. Only the kernel knows about it. > We can tolerate a few though. If we accumulate a significant number > of errata/vulnerability properties that need to be reported to > userspace, this may be worth revisiting. If not, it doesn't matter. Andre: if you want this to make it into 5.1, the time is now. Thanks, M. -- Without deviation from the norm, progress is not possible.
