| Message ID | 202012071807.0B7I7TJq033563@m5p.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [RFC] xen/arm: domain_build: Ignore empty memory bank | expand |
On Mon, Dec 07, 2020 at 07:36:11AM -0800, Elliott Mitchell wrote: > Commit 5a37207df52066efefe419c677b089a654d37afc changed this behavior to > ignore such banks. Unfortunately this means these empty nodes are > visible to code which accesses the device trees. Have domain_build also > ignore these entries. It is implicit, but I discovered 7d2b21fd36c2a47799eed71c67bae7faa1ec4272 actually broke Xen for me. As such I believe this should get into stable-4.14 as a bugfix. Taking a second look, that error message is bad. The preliminary fix I came up with was: if(!addr) continue; As I thought the 0 it was reporting was an address of 0. Perhaps "Unable to retrieve address for index %u of %s\n"? (I opted for testing size after finding the source of the bug and decided duplicating behavior was better)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index e824ba34b0..0b83384bd3 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -1405,6 +1405,11 @@ static int __init handle_device(struct domain *d, struct dt_device_node *dev, { struct map_range_data mr_data = { .d = d, .p2mt = p2mt }; res = dt_device_get_address(dev, i, &addr, &size); + + /* Some DT may describe empty bank, ignore them */ + if ( !size ) + continue; + if ( res ) { printk(XENLOG_ERR "Unable to retrieve address %u for %s\n",
Previously Xen had stopped processing Device Trees if an empty (size == 0) memory bank was found. Commit 5a37207df52066efefe419c677b089a654d37afc changed this behavior to ignore such banks. Unfortunately this means these empty nodes are visible to code which accesses the device trees. Have domain_build also ignore these entries. Signed-off-by: Elliott Mitchell <ehem+xen@m5p.com> --- Looking at this, I think the problem is likely even larger than this and really needs a proper solution closer to the core of the device-tree code. Likely either all device-tree handling code needs to be audited for ignoring zero-size entries, or the core should take care of these and nothing outside of xen/common/device_tree.c should ever see these (except perhaps to confirm such entries exist as flags). Notably this is the *second* location where zero-size device-tree entries need to be ignored, action might be worthwhile before a third is confirmed. --- xen/arch/arm/domain_build.c | 5 +++++ 1 file changed, 5 insertions(+)