Introduce scatter-gather scatterlists

[Abyss-W4tcher]

Hello,

scatter-gather lists allow to scatter (store) or gather (retrieve) data, and is notably used for DMA data transfer. It is useful when allocating contiguous large chunks of data is not possible/easy. Here, obviously, we only need the gather mechanisms :). These capabilities will be needed for later/potential DMA buffers extraction capabilities.

A general doc. for the curious : https://jungo.com/windriver/scatter-gather-or-contiguous-dma-data-transfer/

[ikelos]

Generally looks good, comments and typing information are much appreciated. The main sticking point is how to determine which layer is the physical layer for which there's no guaranteed method at the moment (and this make assumptions about the intel layer). We should really solve that before merging this (and yes, we may already have done similar things in the code base, but that just adds to the case of needing to fix the situation).

[ikelos]

So this is... fragile. For Intel layers, the underlying layer will likely be memory_layer (but not in the case of a virtualized intel system, for instance), and there's no telling that Arm's lower layer will be called memory_layer. I don't immediately have a better way of doing this. The layer's dependencies list would tell you all the layers it lives on top of, and they're likely to be in order, but short of mapping an address down a layer (and if you pick the wrong one, you might hit swap or something else) there's no guaranteed way of knowing how the layers all fit together... Any thoughts how best to handle this?

[Abyss-W4tcher]

Ok, so here it can be a bit tricky, as we are "blind" of the layer position in the stacking list. However, pdbscan, linux.py and mac.py will refer to the physical layer by the config key "memory_layer", which is a TranslationLayerRequirement for Intel. We can use this information to determine where we are. FYI, the AArch64 implementation has no reason to change this naming, which would only complicate things I think.

Consequently, this implementation should do the trick :

# Either physical is layer-1 because we are a module layer, either physical is the current layer
physical_layer_name = self.context.layers[self.vol.layer_name].config.get(
    "memory_layer", self.vol.layer_name
)
physical_layer = self.context.layers[physical_layer_name]

[ikelos]

Yep, definitely need to use the code above to get it from this object's layer. At the moment all plugins only deal with one image, but that's absolutely not the intention long term.

[Abyss-W4tcher]

Change has been applied.