Re: [Xen-devel] [PATCH 1/1] x86/PVHv2: Add memory map pointer to hvm_start_info struct

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 02.03.18 at 21:54, <maran.wilson@xxxxxxxxxx> wrote:
> The start info structure that is defined as part of the x86/HVM direct boot
> ABI and used for starting Xen PVH guests would be more versatile if it also
> included a way to pass information about the memory map to the guest. This
> would allow KVM guests to share the same entry point.

So is there no use for this with Xen at all? If so, I remain unconvinced
(and will probably defer to others). If not, I think adding the population
of the new data (under whatever conditions) should be part of this
(then) series, demonstrating that this isn't dead code.

> + * Version numbers of the hvm_start_info structure have evolved like this:
> + *
> + * Version 0:

Perhaps "Initial implementation" or some such? Leaving it completely
empty make it look a little odd as an item.

> @@ -86,6 +120,14 @@ struct hvm_start_info {
>      uint64_t cmdline_paddr;     /* Physical address of the command line.     
> */
>      uint64_t rsdp_paddr;        /* Physical address of the RSDP ACPI data    
> */
>                                  /* structure.                                
> */
> +    uint64_t memmap_paddr;   /* Physical address of an array of           */
> +                             /* hvm_memmap_table_entry. Only present in   */
> +                             /* version 1 and newer of the structure      */
> +    uint32_t memmap_entries; /* Number of entries in the memmap table.    */
> +                             /* Only present in version 1 and newer of    */
> +                             /* the structure. Value will be zero if      */
> +                             /* there is no memory map being provided.    */
> +    uint32_t reserved;

For both new reserved fields, please state in at least one of
formal definition and C implementation that they're required to be
set to zero in version 1. That'll open the road to assign meaning
to these fields perhaps without having to bump the version number.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel