> > 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. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
