[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


 


Rackspace

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