> > > 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. > > DT nodes documented in Documentation/devicetree/bindings are about as > good as DT node formalism gets, right? Currently the hypervisor node > is only documented separately in the arm/ and powerpc/ dirs, so maybe > a Documentation/devicetree/bindings/hypervisor.txt file would be a good > addition in order to make the common node official. >From my PoV, each hypervisor has its own binding, which is identified by its set of compatible strings, and node naming colliding on "/hypervisor" is coincidental. We can suggest that "/hypervisor" is the usual name for a node related to a hypervisor, but that tells us nothing about the format of the node. > > 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. > > As I pointed out, it's possible to fake one hypervisor with another, > but only if the guest knows just one (standard) place too look. For a hypervisor to impersonate another, it just needs to do whatever that other hypervisor does. The guest needs to know where to look for the info relating to the hypervisor being impersonated, but that does not require a common location. > For example, if Windows guests were taught to look for a particular > ACPI table to learn about their HyperV features, then KVM could fake > that table and also emulate the hypercalls. This requires KVM to provide those services and for the information to be in the appropriate location. This does not require all hypervisors to place information in the same location, nor for there to be a common format for that information. > Besides, tools like virt-what would benefit from knowing where to > look, etc. This is a different case, for which a common location would likely be helpful, though not complete. > So, if we go the ACPI table route, then I think it should be a > hypervisor and architecture agnostic table. Just as the "hypervisor" > node is super generically named, and it's up to the compatible strings > to sort it out. > > (btw, the hypervisor node already supports faking other hypervisors with > its compatible string. You could specify "linux,kvm" first, and > "xen,xen" second, if you had the capability to emulate the later.) Evidently we have different views w.r.t. binding to tables. >From my PoV, a node which we don't recognise the compatible string for (which is not a legacy node with a static path) is something we know nothing about, and any name applied to the node is just there to help the casual reader. For there to be a contract as to the purpose and format of the node, there should be a compatible string list. Thanks, Mark. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
