[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC][PATCH 4/5] tools:firmware:hvmloader: reserve RMRR mappings in e820



>>> On 08.08.14 at 10:39, <tiejun.chen@xxxxxxxxx> wrote:
> On 2014/8/8 15:43, Jan Beulich wrote:
>> More reasonable, albeit now you lost the fetch-just-once behavior.
>> Furthermore - do you really need this to be a dynamic allocation?
> 
> So,
> 
> diff --git a/tools/firmware/hvmloader/util.c 
> b/tools/firmware/hvmloader/util.c
> index 80d822f..d55773e 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -766,6 +766,17 @@ struct shared_info *get_shared_info(void)
>       return shared_info;
>   }
> 
> +struct e820map *get_rmrr_map_info(void)
> +{
> +    if ( rmrr_e820map.nr_map )
> +        return &rmrr_e820map;
> +
> +    if ( hypercall_memory_op(XENMEM_RMRR_memory_map, &rmrr_e820map) != 0 )
> +        BUG();
> +
> +    return &rmrr_e820map;
> +}

Still not quite, since now you still re-invoke the hypercall if the first
one didn't return any entries (e.g. on a VT-d-less system).

> --- a/tools/firmware/hvmloader/util.h
> +++ b/tools/firmware/hvmloader/util.h
> @@ -236,6 +236,8 @@ unsigned long create_pir_tables(void);
>   void smp_initialise(void);
> 
>   #include "e820.h"
> +struct e820map rmrr_e820map;
> +struct e820map *get_rmrr_map_info(void);
>   int build_e820_table(struct e820entry *e820,
>                        unsigned int lowmem_reserved_base,
>                        unsigned int bios_image_base);
> 
> 
>> The structure you use right now is fixed size. Which gets me to
>> another point though: Is it said in any part of the VT-d spec that
>> there is an upper limit to the number of RMRRs? The re-use of the
> 
> After look up some relevant info in VT-D specs, I think we have no any 
> direct field to limit the number of RMRRs. Just in 8.1 DMA Remapping 
> Reporting Structure, there are some fields to be referred here:
> 
> #1 Length:
> 
> in bytes, of the description table including the length of the 
> associated remapping structures.
> 
> #2 Remapping Structures[]:
> 
> A list of structures. The list will contain one or more DMA Remapping 
> Hardware Unit Definition (DRHD) structures, and zero or more Reserved 
> Memory Region Reporting (RMRR) and Root Port ATS Capability Reporting 
> (ATSR) structures.
> 
> Seems no any explicit restriction.

IOW a fixed-length interface structure isn't a proper fit here.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.