[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] xen_phys_start for 32b
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] > Sent: Wednesday, January 07, 2009 12:54 AM > > On 06/01/2009 22:19, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx> wrote: > > >> It's not used for domheap either. In fact it's not really used at all. > >> Hence > >> encompassing it within xenheap_phys_start to xenheap_phys_end works okay. > >> > > > > 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. Joe _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |