On Fri, 6 Aug 2021, Oleksandr Tyshchenko wrote: > Hello, all. > > I would like to clarify some bits regarding a possible update for "Xen device tree bindings for the guest" [1]. > > A bit of context: > We are considering extending "reg" property under the hypervisor node and we would like to avoid breaking backward compatibility. > So far, the "reg" was used to carry a single region for the grant table mapping only and it's size is quite small for the new improvement > we are currently working on. > > What we want to do is to extend the current region [reg: 0] and add an extra regions [reg: 1-N] to be used as a safe address space for any > Xen specific mappings. But, we need to be careful about running "new" guests (with the improvement being built-in already) on "old" Xen > which is not aware of the extended regions, so we need the binding to be extended in a backward compatible way. In order to detect whether > we are running on top of the "new" Xen (and it provides us enough space to be used for improvement), we definitely need some sign to > indicate that. > > Could you please clarify, how do you expect the binding to be changed in the backward compatible way? > - by adding an extra compatible (as it is a change of the binding technically) > - by just adding new property (xen,***) to indicate that "reg" contains enough space > - other option The current description is: - reg: specifies the base physical address and size of a region in memory where the grant table should be mapped to, using an HYPERVISOR_memory_op hypercall [...] Although it says "a region" I think that adding multiple ranges would be fine and shouldn't break backward compatibility. In addition, the purpose of the region was described as "where the grant table should be mapped". In other words, it is a safe address range where the OS can map Xen special pages. Your proposal is to extend the region to be bigger to allow the OS to map more Xen special pages. I think it is a natural extension to the binding, which should be backward compatible. Rob, I am not sure what is commonly done in these cases. Maybe we just need an update to the description of the binding? I am also fine with adding a new compatible string if needed.
