[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [v6][PATCH 6/7] hvmloader: check to reserved device memory maps in e820
>>> On 11.09.14 at 17:57, <JBeulich@xxxxxxxx> wrote: >>>> On 10.09.14 at 07:49, <tiejun.chen@xxxxxxxxx> wrote: >> +static unsigned int construct_rdm_e820_maps(unsigned int nr, >> + uint32_t nr_map, >> + struct > xen_mem_reserved_device_memory *map, >> + struct e820entry *e820) >> +{ >> + unsigned int i = 0, j = 0, m = 0, sum_nr = nr + nr_map; > > Some or all of the initializers here are pointless. > >> + uint64_t start, end, rdm_start, rdm_end; >> + unsigned int insert = 0, do_insert = 0; >> + >> + do_real_construct: >> + for ( i = 0; i < nr_map; i++ ) >> + { >> + rdm_start = map[i].start_pfn << PAGE_SHIFT; >> + rdm_end = rdm_start + map[i].nr_pages * PAGE_SIZE; > > Same comment as for an earlier patch. > >> + >> + for ( j = 0; j < nr - 1; j++ ) >> + { >> + end = e820[j].addr + e820[j].size; >> + start = e820[j+1].addr; > > So now you don't check the last region at all? You just need to make > this assignment conditional upon whether you're in the last iteration. Furthermore - I don't think an overlap with an E820_RESERVED or E820_UNUSABLE region would be a problem (you'd just need to extend the former or amend the latter) - you only check here rather than making sure no RAM gets placed into these address regions in the first place (or rather than relocating the RAM as is done for at least some MMIO/RAM overlaps) Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |