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

Re: [Xen-devel] xen_phys_start for 32b



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


 


Rackspace

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