> > > +bool cpu_cache_has_invalidate_memregion(void)
> > > +{
> > > + guard(spinlock_irqsave)(&scfm_lock);
> > > + return !!scfm_data;
> >
> > Lock seems pointless here.
> >
> > More concerning is this diverges from the original intent of this
> > function which was to disable physical address space manipulation from
> > virtual environments.
>
> Sure. We don't loose that - it just moved out to the registration framework
> for devices. If a future VM actually wants to expose paravirt interfaces
> via device emulation then they can.
>
> Maybe we can call from here to see if any device drivers actually registered.
> That's not a guarantee that all relevant ones did (yet) but it at least
> will result in warnings for the virtual machine case.
>
> >
> > Now, different archs may have reason to diverge here but the fact that
> > the API requirements are non-obvious points at a minimum to missing
> > documentation if not missing cross-arch consensus.
>
> I'll see if I can figure out appropriate documentation for that.
>
Hi Dan,
I'm struggling a little for what these requirements should be (and hence the
documentation). Do you think having the possibility for us to go from returning
that we have no support to later returning that we have support as additional
drivers arrive is acceptable? Potentially the opposite as well if someone is
unbinding the drivers.
So for x86 it's simple as you use an explicit cpu feature check on whether
it is in a hypervisor. For architectures using explicit 'drivers' (because
the interface is in MMIO or similar) there need be no difference between
the 'is it a VM' check and the 'do we have the hardware'.
If someone chooses to emulate (or pass through) the hardware interface then
they get to make it do something sane.
On a somewhat related note, I don't yet have a good answer for how, in
a complex system we know all the drivers have arrived and hence the
flush will be complete once they all acknowledge.
Could do an ACPI _DSM that returns a list of IDs and check drivers are
bound to them but would need to get that into some spec or other
which might take a while.
For now I'm taking the view that there are many ways to shoot yourself
in a the foot if you can control driver binding, so this isn't a blocker,
more of a nice to have.
I'll send out the new (simpler) code next week (so post rc1)
Jonathan
