Just ran into this problem trying to build a linux-2.6.18-xen dom0 which appears suspiciously related to a recent patch. I haven''t tried a new clone and build, but did do a make clean. I''ll try a fresh clone, but that will take hours so thought I would report it first. CC [M] drivers/xen/pciback/conf_space_header.o CC [M] drivers/xen/pciback/conf_space_capability.o CC [M] drivers/xen/pciback/conf_space_capability_vpd.o CC [M] drivers/xen/pciback/conf_space_capability_pm.o CC [M] drivers/xen/pciback/conf_space_quirks.o CC [M] drivers/xen/pciback/conf_space_capability_msi.o CC [M] drivers/xen/pciback/vpci.o LD [M] drivers/xen/pciback/pciback.o CC [M] drivers/xen/scsiback/interface.o /root/src/xen/linux-2.6.18-xen.hg/drivers/xen/scsiback/interface.c: In function map_frontend_page: /root/src/xen/linux-2.6.18-xen.hg/drivers/xen/scsiback/interface.c:77: error: GNTST_eagain undeclared (first use in this function) /root/src/xen/linux-2.6.18-xen.hg/drivers/xen/scsiback/interface.c:77: error: (Each undeclared identifier is reported only once /root/src/xen/linux-2.6.18-xen.hg/drivers/xen/scsiback/interface.c:77: error: for each function it appears in.) make[8]: *** [drivers/xen/scsiback/interface.o] Error 1 make[7]: *** [drivers/xen/scsiback] Error 2 make[6]: *** [drivers/xen] Error 2 make[5]: *** [drivers] Error 2 make[4]: *** [modules] Error 2 make[3]: *** [modules] Error 2 make[3]: Leaving directory `/root/src/xen/xen-unstable.hg/build-linux-2.6.18-xen_x86_32'' make[2]: *** [build] Error 1 make[2]: Leaving directory `/root/src/xen/xen-unstable.hg'' make[1]: *** [linux-2.6-xen-install] Error 2 make[1]: Leaving directory `/root/src/xen/xen-unstable.hg'' make: *** [install-kernels] Error 1 [root@dmagenhe-nsvpn-dhcp-141-144-22-9 xen-unstable.hg]# hg tip changeset: 20712:d30244049f7e tag: tip user: Keir Fraser <keir.fraser@citrix.com> date: Tue Dec 22 13:39:12 2009 +0000 summary: VT-d: improve RMRR region handling [root@dmagenhe-nsvpn-dhcp-141-144-22-9 xen-unstable.hg]# cd ../linux-2.6.18-xen.hg/ [root@dmagenhe-nsvpn-dhcp-141-144-22-9 linux-2.6.18-xen.hg]# hg tip changeset: 968:89bb6edd1b98 tag: tip user: Keir Fraser <keir.fraser@citrix.com> date: Tue Dec 22 13:30:45 2009 +0000 summary: Sync Xen public headers for Xen 4.0. [root@dmagenhe-nsvpn-dhcp-141-144-22-9 linux-2.6.18-xen.hg]# _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 22/12/2009 17:04, "Dan Magenheimer" <dan.magenheimer@oracle.com> wrote:> Just ran into this problem trying to build a linux-2.6.18-xen dom0 which > appears suspiciously related to a recent patch. > > I haven''t tried a new clone and build, but did do a make clean. > > I''ll try a fresh clone, but that will take hours so thought I would > report it first.I will fix. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 22/12/2009 17:04, "Dan Magenheimer" <dan.magenheimer@oracle.com> wrote:> Just ran into this problem trying to build a linux-2.6.18-xen dom0 which > appears suspiciously related to a recent patch. > > I haven''t tried a new clone and build, but did do a make clean. > > I''ll try a fresh clone, but that will take hours so thought I would > report it first.Fixed by c/s 969, which puts the grant_table.h public header changes introduced by the paging/sharing patches properly into xen-unstable, and then syncs them back into linux-2.6.18-xen. *However*, cc''ing Gregor and Patrick as that raises the question of why this wasn''t noticed sooner. Why do we have grant-table interface extensions being defined in a guest, but apparently no use of them (and hence no implementation of them?) in Xen itself? I''m talking about GNTMAP_can_fail/GNTCOPY_can_fail/GNTST_eagain -- is linux-2.6.18-xen defining using these just for its own amusement? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Grzegorz Milos
2009-Dec-22 22:33 UTC
Re: [Xen-devel] build problem in linux-2.6.18-xen.hg?
> *However*, cc''ing Gregor and Patrick as that raises the question of why this > wasn''t noticed sooner. Why do we have grant-table interface extensions being > defined in a guest, but apparently no use of them (and hence no > implementation of them?) in Xen itself? I''m talking about > GNTMAP_can_fail/GNTCOPY_can_fail/GNTST_eagain -- is linux-2.6.18-xen > defining using these just for its own amusement?GNTMAP_* are meant to be used by Xen, however at the moment we''ve got some leftovers from the original approach we used to handle OOM conditions. In there, we maintained a pool of pages to handle certain ''critical'' operations which should not fail (such as unsharing grated pages). However, it quickly turned out that the memory pool would have to grow unacceptably large. A more invasive approach, which we finally decide to take, was to fixup all grant op callers to handle EAGAIN. The last remaining patch (which I''m already working on) is to cleanup the mem pool code in Xen, and return EAGAIN on failure instead. For the time being, I have an explicit check (with a BUG()) on failed page unshares, so that they''ll never go unnoticed. Thanks Gregor _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel