Re: Advice on HYP interface for AsyncPF

[Mark Rutland <mark.rutland@arm.com>]

> > While the HVC immediate could be used to distinguish different types of
> > calls, the guest still needs to first determine that issuing a HVC is
> > not going to bring down the system, which requires it to know that a
> > suitable hypervisor is present.
> 
> Right. I forgot we don't have anything for this in the kvmarm world. I
> should have remembered, having just crossed this path for a different
> issue (virt-what). In the x86 world we have a cpuid that allows guests
> to see that they are a) a guest and b) of what type. The hypervisor can
> fake the type if it wishes. For example KVM can emulate HyperV, allowing
> Windows guests to use their "native" PV ops.
> 
> In the ARM world the hypervisor DT node does seem to be the closet
> equivalent that currently exists. Both Xen and ppc KVM use it already.
> Using this for DT guests means we'll need the ACPI solution though.

Sure.

> > > > Maybe we should adopt Xen's idea of a hypervisor node in DT where we
> > > > would describe the various services? How will that work with ACPI?
> > > 
> > > I don't think we'll ever have a "virt guest" ACPI table that we can
> > > use for this stuff, so this won't work for ACPI. But I think the ENOSYS
> > > probing should be sufficient for this anyway.
> > 
> > As mentioned above, I don't think that probing is safe.
> > 
> > What prevents us from creating a trivial "KVM guest" table that we can
> > use to determine that we can query more advanced info from KVM itself?
> > Given the point is to expose KVM-specific functionality, I don't see why
> > we need a more generic "virt guest" ACPI table.
> >
> 
> Just as the hypervisor node is more attractive with the consideration
> that it's being adopted by other parties (xen and kvmppc), any ACPI
> tables will be more likely to be accepted if they have buy-in from
> a greater audience. kvmarm would be the only consumer for the time
> being, but it'd be good if it was more general from the start,
> particularly if general kernel code would need to know about it.

I'm not sure I follow, given that there's no generic hypervisor node in
DT at the moment.

In the case of Xen there's a node with a "xen,xen" compatible string.

In the case of PPC KVM, there's a node with a "linux,kvm" compatible
string.

These don't have any overlap. I'm not sure what a generic node would buy
you short of detecting (some cases) when you're begin virtualised, given
you'd have to know about the particular hypervisor and/or services
anyway.

Mark.