On 05/03/2021 14:21, Jan Beulich wrote: > On 05.03.2021 15:18, Jan Beulich wrote: >> On 05.03.2021 15:12, Andrew Cooper wrote: >>> On 05/03/2021 13:53, Jan Beulich wrote: >>>> On 05.03.2021 13:49, Andrew Cooper wrote: >>>>> Exactly as with c/s f40e1c52e4, this is inappropriate for a stable >>>>> library. >>>>> >>>>> That change actually broke the build with: >>>>> >>>>> include/xendevicemodel.h:52:5: error: unknown type name 'ioservid_t' >>>>> ioservid_t *id); >>>>> ^ >>>>> >>>>> as libxendevicemodel.h now uses a type it can't see a typedef for. >>>>> However, >>>>> nothing noticed because the header.chk logic is also broken (fixed >>>>> subsequently). >>>> While I agree up to here, ... >>>> >>>>> Strip the guard from the public header, and remove compensation from >>>>> devicemodel's private.h >>>> ... I'm unconvinced that entirely dropping the guard from the >>>> public header is wanted (or needed): We use these to make clear >>>> that in particular kernels aren't supposed to make use of the >>>> enclosed entities. If a type needs exposing, it (and only it) >>>> wants moving ou of the guarded region imo. >>> DMOP was invented specifically so a kernel module (i915, for Intel >>> gVT-g) was independent of the domctl ABI version. >>> >>> Improving the life of dom0 userspace was an intended consequence, but >>> not the driving force behind the change. >> This is news to me - so far it had been my understanding that it >> was introduced to have a way for the kernel to audit and hand on >> requests to the hypervisor without needing to know all the inner >> details. I wasn't even aware a kernel module was using any of >> these. > And indeed, quote from docs/designs/dmop.markdown: > > "The aim of DMOP is to prevent a compromised device model from > compromising domains other than the one it is providing emulation > for (which is therefore likely already compromised)." > > And it goes on discussing only the purpose that I've been aware > of.
The use in the dom0 kernel wasn't kept secret in the slightest. It was discussed on at the time, and at dev summits. But upstream tends to only remember/care about the bits which pertain directly to upstream, and the design particulars of the DMOP ABI were specifically for userspace. ~Andrew
