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

Re: [Xen-devel] [PATCH] x86/xen: do not identity map E820 memory regions that are UNUSABLE



On 12/07/2013 20:33, Konrad Rzeszutek Wilk wrote:
> 
> So the 'HYPERVISOR_update_va_mapping' fails b/c we include it in the
> xen_set_identify_and_release_chunk.

That's what I understand.

> Why not make the logic that sets "gaps"
> and E820_RESERVED regions to omit E820_UNUSABLE regions? That would solve
> it as well - and we won't be messing with the E820.

I suppose we could do what you suggest but there would have to be a
xen_release_chunk() function added, otherwise you would waste the frames
in that region.

I remain unconvinced that adding pointless unusable regions into the
dom0's memory map makes any sense.

>>> OK. What about the BIOS manufacturing [unusable regions?
>>
>> What about it? As a PV guest we don't care what the machine memory map
>> looks like, /except/ as a means to find interesting bits of hardware
>> that we want 1:1 mappings for.
> 
> Right but now you are converting it from 1:1 to a RAM region - where we
> don't do 1:1.

No, it's leaving it as a RAM region, as setup by Xen (and as marked as
such in the pseudo-physical map).

I guess I still haven't explained very well what the (confusing) setup
code is trying to do.

1. Get psuedo-physical memory map.

2. Get machine memory map.

3. For each "interesting" (reserved or MMIO hole) region in the machine
   memory map:

   a. Add reserved region or hole to pseudo-physical memory map.
   b. Release memory.
   c. Set as 1:1 in p2m.
   d. Update any existing mappings.

The code as-is doesn't work like that but the end result should be the same.

David


_______________________________________________
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®.