|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |