>>> On 11.12.17 at 22:59, <pbonzini@xxxxxxxxxx> wrote: > On 08/12/2017 09:49, Jan Beulich wrote: >>> + * The layout of each entry in the memory map table is as follows and no >>> + * padding is used between entries in the array: >>> + * >>> + * 0 +----------------+ >>> + * | addr | Base address >>> + * 8 +----------------+ >>> + * | size | Size of mapping >>> + * 16 +----------------+ >>> + * | type | E820_TYPE_xxx >>> + * 20 +----------------| >> I'm not convinced of re-using E820 types here. I can see that this >> might ease the consumption in Linux, but I don't think there should >> be any connection to x86 aspects here - the data being supplied is >> x86-agnostic, and Linux'es placement of the header is also making >> no connection to x86 (oddly enough, the current placement in the >> Xen tree does, for a reason which escapes me). > > FWIW, e820 types are now part of the ACPI standard. So using them is > not necessarily related to x86, and reasonably x86-agnostic. Sort of - the description of it starts with "This interface is used in real mode only on IA-PC-based systems ..." But it being there is useful in another way: It shows that there's an optional field making the full structure 64-bit aligned again. (It at the same time shows - I admit I had forgotten about this aspect - that the structure size isn't fixed in the first place, so consumers have to convert [truncate/extend] the output to their internal representation anyway, and hence there's even less of a reason to tie the proposed structure's layout to the E820 one.) Jan
