[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] xen kernel: build failure
>>> On 28.11.11 at 13:16, Jean Guyader <jean.guyader@xxxxxxxxxxxxx> wrote: > On 28/11 11:59, Jean Guyader wrote: >> On 23/11 04:41, Jan Beulich wrote: >> > >>> On 23.11.11 at 17:31, Jean Guyader <jean.guyader@xxxxxxxxx> wrote: >> > > On 25 October 2011 13:35, Keir Fraser <keir.xen@xxxxxxxxx> wrote: >> > >> On 25/10/2011 12:08, "Christoph Egger" <Christoph.Egger@xxxxxxx> wrote: >> > >> >> > >>> >> > >>> Hi, >> > >>> >> > >>> Compiling the xen kernel fails with: >> > >>> >> > >>> xen/arch/x86/domain.c: In function 'alloc_domain_struct' >> > >>> xen/arch/x86/domain.c:191: error: negative width in bit-field >> > >>> '<anonymous>' >> > >> >> > >> Problem is that struct domain has grown bigger than a page for some > reason, >> > >> in your build environment. >> > >> >> > >> I can't reproduce this. >> > >> >> > >>> Removing the line >> > >>> >> > >>> BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE); >> > >>> >> > >>> makes xen kernel compile again. >> > >> >> > >> But not actually work properly. We only allocate a single page for the >> > >> domain struct. If the struct is bigger than a page, you'll get memory >> > >> corruption at run time. >> > >> >> > > >> > > Is there a reason for that? >> > >> > Of course there is: Post-boot there shouldn't be any allocations of >> > order greater than zero. This is a generally advisable thing, given that >> > Xen can't reclaim memory arbitrarily from domains, and in particular >> > also necessary for tmem. >> > >> > > What would be the recommended to add something >> > > into the struct domain now if we can't make it bigger than a page. >> > >> > Put a pointer to your data (or larger parts that are already there) >> > instead of the data itself into struct domain, and allocate it >> > separately. (You may have seen a patch from Olaf Hering late >> > yesterday or earlier today that moved the mem_event pieces out >> > of there for this very reason.) >> > >> > >> >> I've printed sizeof (struct domain) on boot with xen-unstable and it's >> exactly a PAGE big. That mean that if I want a add a value to the struct >> domain (event a pointer) I will have to make some room first. >> > > I can see two candidates, that could be turned into pointers in arch_domain > for x86: > > /* nestedhvm: translate l2 guest physical to host physical */ > struct p2m_domain *nested_p2m[MAX_NESTEDP2M]; > mm_lock_t nested_p2m_lock; > or > struct PITState vpit; > > Let me know which one I should pick. Maybe I should modify both to save > some space for later. As written earlier, I think you should leverage Olaf Hering's patch to split out the three "struct mem_event_domain" instances. Other candidates would be the watchdog related items or the evtchn array (the latter would need to be converted to a simple pointer anyway at some point in order to support more than 4096 event channels per domain). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |