On 07/01/2009 15:13, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx> wrote:
>>> But shouldn't [xenheap_phys_start, xenheap_phys_end] represent all of the
>>> memory that the hypervisor "owns" and which must be protected from even
>>> privileged domain writes (modulo the real mode/trampoline code, which has
>>> its
>>> own variables that represent its range)? While it may be "OK" on 32b
>>> systems,
>>> it is not "logically correct" and does not match 64b systems (where this low
>>> memory is not so protected). Would it break anything to set
>>> xenheap_phys_start to __pa(&_start) for 32b builds?
>> 
>> So what issue does this fix for you?
>
> It moves the '#ifdef __x86_64__' in a couple of places in an upcoming patch
> into just setup.c ;-) So practically speaking, it is not very important. But
> it seems like it would just be cleaner, today, to have this variable (and
> xen_phys_start?) be consistent across builds; and thus, usable with the
> intended meaning in the future.
Xenheap will disappear entirely on x86/64 in future. So long term is that
i386 and x86/64 are actually to diverge significantly in this area.
Of course I'll consider any patch on its own merits of usefulness and
cleanliness.
 -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel