It certainly seems that you need all of the functions in drivers/xen/util.c, ie alloc_vm_area, free_vm_area, lock_vm_area and unlock_vm_area to be exported in order build a loadable xen driver. Can these be added? Thanks, Nick>Date: Thu, 19 Jan 2006 19:14:21 +0000 >From: Keir Fraser <Keir.Fraser@cl.cam.ac.uk> >Subject: Re: [Xen-devel] EXPORT_SYMBOL for get_vm_area ... >To: Himanshu Raj <rhim@cc.gatech.edu> >Cc: xen-devel@lists.xensource.com >Message-ID: <27575039d47752db8a244204172080c8@cl.cam.ac.uk> >Content-Type: text/plain; charset=US-ASCII; format=flowed > > >On 16 Jan 2006, at 05:34, Himanshu Raj wrote: > > > >>Hi Folks, >> >>To build drivers externally using >>linux-2.6-xen-sparse/drivers/xen/util.c, >>I need the symbols get_vm_area and remove_vm_area exported (they were >>exported >>previously - not any more in the latest version). >> >>Am I missing something here? >> >> > >Do you mean alloc_vm_area and free_vm_area? get/remove_vm_area >shouldn''t be getting directly referenced from our driver modules. > > -- Keir > > > > >------------------------------ > >Message: 2 >Date: Thu, 19 Jan 2006 19:32:01 +0000 >From: Keir Fraser <Keir.Fraser@cl.cam.ac.uk> >Subject: Re: [Xen-devel] Support for AGP aperture as IOMMU in AMD64 > mode [2/2] >To: "Langsdorf, Mark" <mark.langsdorf@amd.com> >Cc: xen-devel@lists.xensource.com >Message-ID: <bd4a929caa2d8de8aa371c18f59bc751@cl.cam.ac.uk> >Content-Type: text/plain; charset=US-ASCII; format=flowed > > >On 16 Jan 2006, at 23:50, Langsdorf, Mark wrote: > > > >>These are the diffs against the pristine versions of >>arch/x86_64/kernel/[aperture.c,pci-gart.c] to better >>show the changes necessary to adapt those files to >>Xen. >> >>They were included with the patch and should not be >>applied again. >> >> > >Changes to these files will have to be merged upstream into the native >x86/64 files. Hence they need cleaning up and posting to linux-kernel >and Andi Kleen. At the moment they don''t quite pass muster. > >A few things I can see are: why disable call to e820_mapped()? I see >you added an implementation for that in the main patch you sent out. If >it''s not right to call it at that point in aperture.c then we need to >come up with a cleaner abstraction. virt_to_gart/gart_to_virt should be >moved to our agp.h if we want to keep them. Alternatively you only use >them a couple of times so expanding them at the call site would be >okay. You unconditionally allocate a table to the ''gatt'' variable, but >only set the agp_gatt_table variable if it is NULL. Should you free the >table if agp_gatt_table!=NULL? Can that ever happen, and if so why not >on native? > >The big patch you sent out we also need to go through in some detail. >It''s rather bigger than I would have expected. Hopefully there is some >possibility of cleaning up and keeping things closer to the native >original source files. > > Cheers, > Keir > > > > >------------------------------ > >Message: 3 >Date: Thu, 19 Jan 2006 12:19:53 -0500 >From: Jeremy Katz <katzj@redhat.com> >Subject: Re: [Xen-devel] [PATCH 0/3] domUloader >To: Anthony Liguori <aliguori@us.ibm.com> >Cc: Xen development list <xen-devel@lists.xensource.com>, Kurt Garloff > <garloff@suse.de> >Message-ID: <1137691193.2740.43.camel@bree.local.net> >Content-Type: text/plain > >On Wed, 2006-01-18 at 22:31 -0600, Anthony Liguori wrote: > > >>On a side note, one thing we all have to think about is how a boot >>loader would work with something like a virtual framebuffer. >> >> > >Yeah :/ > > > >>It may be time to start thinking about writing a first class domU >>bootloader. Something that just sets up a page table that maps the pfns >>linearly and enough XenBus to read from a virtual disk. We can reuse >>code from grub for filesystem parsing (or even write it from >>scratch--it''s not that hard to just read from a filesystem). >> >>We could also use mini-OS as a base. >> >> > >The problem is where does something like this end? So we add a basic >blkfront. Then someone wants to do some form of netboot. Or boot on >iSCSI. Or they use something like GFS or OCFS2 which require >significantly more infrastructure than most filesystems. And then, >there is a world of pain :/ > >Unfortunately, I am completely convinced that the right thing is to have >the kernel for domU inside the domU''s filesystem because anything else >is just fundamentally not manageable. So, perhaps we do have to just >suck it up and go the path of what''s essentially mini-OS as a domU >"bios" > >Jeremy > > > > >------------------------------ > >Message: 4 >Date: Thu, 19 Jan 2006 16:50:02 -0600 >From: Anthony Liguori <aliguori@us.ibm.com> >Subject: [Xen-devel] New Release Process >To: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>, xen-devel > <xen-devel@lists.xensource.com> >Message-ID: <43D0179A.5050905@us.ibm.com> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >Hi Ian, > >I was hoping you could clarify what the decisions were for the new >release process that you proposed at the Winter XenSummit. > >Your original slides aren''t online yet and I''m not sure if the final >decision deviated from your slides.. > >Thanks! > >Regards, > >Anthony Liguori > > > >------------------------------ > >Message: 5 >Date: Thu, 19 Jan 2006 18:10:11 -0600 >From: "Langsdorf, Mark" <mark.langsdorf@amd.com> >Subject: RE: [Xen-devel] Support for AGP aperture as IOMMU in AMD64 > mode [2/2] >To: "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk> >Cc: xen-devel@lists.xensource.com >Message-ID: > <84EA05E2CA77634C82730353CBE3A84303218ACE@SAUSEXMB1.amd.com> >Content-Type: text/plain; charset=us-ascii > > > > > >>-----Original Message----- >>From: xen-devel-bounces@lists.xensource.com >>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of >>Keir Fraser >>Sent: Thursday, January 19, 2006 1:32 PM >>To: Langsdorf, Mark >>Cc: xen-devel@lists.xensource.com >>Subject: Re: [Xen-devel] Support for AGP aperture as IOMMU in >>AMD64 mode [2/2] >> >> >> >>On 16 Jan 2006, at 23:50, Langsdorf, Mark wrote: >> >> >> >>>These are the diffs against the pristine versions of >>>arch/x86_64/kernel/[aperture.c,pci-gart.c] to better show >>> >>> >>the changes >> >> >>>necessary to adapt those files to Xen. >>> >>>They were included with the patch and should not be >>>applied again. >>> >>> >>Changes to these files will have to be merged upstream into >>the native x86/64 files. Hence they need cleaning up and >>posting to linux-kernel and Andi Kleen. At the moment they >>don''t quite pass muster. >> >> > >Some of those change are definitely Xen specific, such as the >switch from virt_to_phys() to virt_to_bus around line 416, >and the switch from __get_free_pages to alloc_gatt_pages near >line 740. Similarly, I had to introduce some hypervisor calls >to get the true size of memory so that the GART is enabled even >if dom0 has less than 4 GB of memory. > > > >>A few things I can see are: why disable call to e820_mapped()? >> >> > >Couldn''t get the implementation of e820_mapped() to work right, >and missed I had the debug statement in there still. Any ideas >on what I''m doing wrong in e820_mapped? > > > >>virt_to_gart/gart_to_virt should be moved to our agp.h if we >>want to keep them. Alternatively you only use them a couple >>of times so expanding them at the call site would be okay. >> >> > >Done. > > > >>You unconditionally allocate a table to the ''gatt'' variable, but >>only set the agp_gatt_table variable if it is NULL. Should >>you free the table if agp_gatt_table!=NULL? Can that ever happen, >>and if so why not on native? >> >> > >agp_gatt_table is set in the AGP code on native. I can''t figure >out why Xen isn''t setting it right, hence the work-around. > >Looking at that code again, the else statement makes no sense and >should probably be removed. > > > >>The big patch you sent out we also need to go through in some detail. >>It''s rather bigger than I would have expected. Hopefully >>there is some possibility of cleaning up and keeping things closer >>to the native original source files. >> >> > >Most of the big patch is adding 3 mostly unmodified files >from arch/x86_64/kernel to arch/xen/x86_64/kernel. The >rest of the code changes are pretty minor. > >If you want, I can restructure the patch to reflect - >submit 1 patch to add pci-dma.c, pci-gart.c, and >aperture.c, and another set of patches to reflect the >incremental changes to those files. Would that help? > >-Mark Langsdorf >AMD, Inc. > > > > >------------------------------ > >Message: 6 >Date: Thu, 19 Jan 2006 16:30:35 -0800 >From: "Cihula, Joseph" <joseph.cihula@intel.com> >Subject: RE: [PATCH] Re: [Xen-devel] [PATCH 0/3] domUloader >To: "Tim Deegan" <Tim.Deegan@cl.cam.ac.uk>, "Jeremy Katz" > <katzj@redhat.com> >Cc: xen-devel@lists.xensource.com >Message-ID: > <CA95C29D57188841ABB072EA7357C00D0ABA30C9@orsmsx402.amr.corp.intel.com> > >Content-Type: text/plain; charset="us-ascii" > >On Thursday, January 19, 2006 5:06 AM, Tim Deegan <> wrote: > > > >>On Wed, Jan 18, 2006 at 01:07:00PM -0500, Jeremy Katz wrote: >> >> >>>Sounds reasonable enough, although I''ll have to look at it a little >>>closer when I get back from Austin. FWIW, partition table handling >>>in pygrub should work fine (I''m installing to full disk vbds with >>>partition tables regularly) >>> >>> >>The partition handling is only enough to find the "active" partition, >>so it doesn''t handle extended partitions. That''s not a problem for >>pygrub, but would need to be done to have the extraction tool handle >>partitions properly. >> >>Also, it doesn''t work if your e2fsprogs are too old to have >>ext2fs_open2() -- again, not really a bug but the failure mode is a >>bit ugly, and the version in the Xen 3 tarball has this problem. Is >>there some way of telling from inside a python script whether the >>pygrub library is going to be able to read partitions or not? >> >> > >I think that we also need to consider the maintainability aspects of the >two choices. If we want to add new features or support, it would be >best if we only had to modify one code base. For example, adding TPM >support. > >It is also conceivable that in the future, a domU''s filesystem could be >(partially) encrypted ala MSFT Vista. Coupled with a de-privileged dom0 >(or disk driver domain), this might force us into (or require for >maintaining security) a pyGRUB-based solution. > >As I understand it, pyGRUB (with Tim''s patch) is a superset of >domUloader, at least from a functionality perspective. If so, this >would seem to make it a better choice for a single code base. > >Joseph Cihula >(Linux) Software Security Architect >Open Source Technology Center >Intel Corp. > >*** These opinions are not necessarily those of my employer *** > > > >------------------------------ > >Message: 7 >Date: Fri, 20 Jan 2006 09:12:05 +0800 >From: "Yu, Ke" <ke.yu@intel.com> >Subject: [Xen-devel] [PATCH][RESEND] make xm reboot work for vmx > domain >To: <Xen-devel@lists.xensource.com> >Message-ID: <8126E4F969BA254AB43EA03C59F44E840488B818@pdsmsx404> >Content-Type: text/plain; charset="us-ascii" > ># HG changeset patch ># User Yu Ke <ke.yu@intel.com> ># Node ID 21bcf6e59fafb61e32521f54ff3890367cfc7e4d ># Parent 8d6edcf06f9b21cd7db68bdeb40c13ac3de60c12 > >This patch makes xm reboot/shutdown work for vmx doamin. > >xm reboot failed due to two issues: >1. no mechanism to change XendDomainInfo.info to trigger domain reboot >2. ioemu blkif parameter is missing during reboot, thus device model >recreation will fail. > >This patch fixes these issues by >1. introducing a xswatch to monitor the control/shutdown node. once >fired, it will change the XendDomainInfo.info to trigger domain reboot >2. saving the ioemu blkif parameter in xen store just like DomU does. > >Signed-off-by: Yu Ke <ke.yu@intel.com> > >diff -r 8d6edcf06f9b -r 21bcf6e59faf tools/python/xen/xend/image.py >--- a/tools/python/xen/xend/image.py Tue Jan 17 16:09:03 2006 +0100 >+++ b/tools/python/xen/xend/image.py Wed Jan 18 15:52:12 2006 +0800 >@@ -25,6 +25,7 @@ > from xen.xend.XendError import VmError > from xen.xend.XendLogging import log > from xen.xend.server.netif import randomMAC >+from xen.xend.xenstore.xswatch import xswatch > > > xc = xen.lowlevel.xc.xc() >@@ -228,6 +229,8 @@ > log.debug("vcpus = %d", self.vm.getVCpuCount()) > log.debug("acpi = %d", self.acpi) > log.debug("apic = %d", self.apic) >+ >+ self.register_shutdown_watch() > > return xc.vmx_build(dom = self.vm.getDomid(), > image = self.kernel, >@@ -365,6 +368,7 @@ > return vncconnect > > def destroy(self): >+ self.unregister_shutdown_watch(); > import signal > if not self.pid: > return >@@ -398,6 +402,41 @@ > else: > return 1 + ((mem_mb + 3) >> 2) > >+ def register_shutdown_watch(self): >+ """ add xen store watch on control/shutdown """ >+ self.shutdownWatch = xswatch(self.vm.dompath + >"/control/shutdown", \ >+ self.vmx_shutdown) >+ log.debug("vmx shutdown watch registered") >+ >+ def unregister_shutdown_watch(self): >+ """Remove the watch on the control/shutdown, if any. Nothrow >+ guarantee.""" >+ >+ try: >+ if self.shutdownWatch: >+ self.shutdownWatch.unwatch() >+ except: >+ log.exception("Unwatching vmx shutdown watch failed.") >+ self.shutdownWatch = None >+ log.debug("vmx shutdown watch unregistered") >+ >+ def vmx_shutdown(self, _): >+ """ watch call back on node control/shutdown, >+ if node changed, this function will be called >+ """ >+ from xen.xend.XendDomainInfo import shutdown_reasons >+ xd = xen.xend.XendDomain.instance() >+ vm = xd.domain_lookup( self.vm.getDomid() ) >+ >+ reason = vm.readDom(''control/shutdown'') >+ log.debug("vmx_shutdown fired, shutdown reason=%s", reason) >+ for x in shutdown_reasons.keys(): >+ if shutdown_reasons[x] == reason: >+ vm.info[''shutdown''] = 1 >+ vm.info[''shutdown_reason''] = x >+ vm.refreshShutdown(vm.info) >+ >+ return 1 # Keep watching > > """Table of image handler classes for virtual machine images. Indexed >by > image type. >diff -r 8d6edcf06f9b -r 21bcf6e59faf >tools/python/xen/xend/server/blkif.py >--- a/tools/python/xen/xend/server/blkif.py Tue Jan 17 16:09:03 2006 >+0100 >+++ b/tools/python/xen/xend/server/blkif.py Wed Jan 18 15:52:12 2006 >+0800 >@@ -42,10 +42,6 @@ > """@see DevController.getDeviceDetails""" > > dev = sxp.child_value(config, ''dev'') >- if ''ioemu:'' in dev: >- return (None,{},{}) >- >- devid = blkif.blkdev_name_to_number(dev) > > (typ, params) = string.split(sxp.child_value(config, ''uname''), >'':'', 1) > back = { ''dev'' : dev, >@@ -54,7 +50,13 @@ > ''mode'' : sxp.child_value(config, ''mode'', ''r'') > } > >- front = { ''virtual-device'' : "%i" % devid } >+ if ''ioemu:'' in dev: >+ (dummy, dev1) = string.split(dev, '':'', 1) >+ devid = blkif.blkdev_name_to_number(dev1) >+ front = {} >+ else: >+ devid = blkif.blkdev_name_to_number(dev) >+ front = { ''virtual-device'' : "%i" % devid } > > return (devid, back, front) > >-------------- next part -------------- >A non-text attachment was scrubbed... >Name: reboot4.patch >Type: application/octet-stream >Size: 4289 bytes >Desc: reboot4.patch >Url : http://lists.xensource.com/archives/html/xen-devel/attachments/20060120/af5c0cea/reboot4.obj > >------------------------------ > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel > > >End of Xen-devel Digest, Vol 11, Issue 86 >***************************************** > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sorry, sent too soon, have changed title and deleted unneccessary text Nick Logan wrote:> It certainly seems that you need all of the functions in > drivers/xen/util.c, ie alloc_vm_area, free_vm_area, lock_vm_area and > unlock_vm_area to be exported in order build a loadable xen driver. > Can these be added? > > Thanks, > > Nick > >> Date: Thu, 19 Jan 2006 19:14:21 +0000 >> From: Keir Fraser <Keir.Fraser@cl.cam.ac.uk> >> Subject: Re: [Xen-devel] EXPORT_SYMBOL for get_vm_area ... >> To: Himanshu Raj <rhim@cc.gatech.edu> >> Cc: xen-devel@lists.xensource.com >> Message-ID: <27575039d47752db8a244204172080c8@cl.cam.ac.uk> >> Content-Type: text/plain; charset=US-ASCII; format=flowed >> >> >> On 16 Jan 2006, at 05:34, Himanshu Raj wrote: >> >> >> >>> Hi Folks, >>> >>> To build drivers externally using >>> linux-2.6-xen-sparse/drivers/xen/util.c, >>> I need the symbols get_vm_area and remove_vm_area exported (they >>> were exported >>> previously - not any more in the latest version). >>> >>> Am I missing something here? >>> >> >> >> Do you mean alloc_vm_area and free_vm_area? get/remove_vm_area >> shouldn''t be getting directly referenced from our driver modules. >> >> -- Keir >> >> >>_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Muli Ben-Yehuda
2006-Jan-25 14:25 UTC
Re: [Xen-devel] Re: Xen-devel Digest, Vol 11, Issue 86
On Wed, Jan 25, 2006 at 11:36:11AM +0000, Nick Logan wrote:> It certainly seems that you need all of the functions in > drivers/xen/util.c, ie alloc_vm_area, free_vm_area, lock_vm_area and > unlock_vm_area to be exported in order build a loadable xen driver. Can > these be added?Just curious, why do you need loadable Xen drivers? Cheers, Muli -- Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, Jan 25, 2006 at 04:25:41PM +0200, Muli Ben-Yehuda wrote:> On Wed, Jan 25, 2006 at 11:36:11AM +0000, Nick Logan wrote: > > It certainly seems that you need all of the functions in > > drivers/xen/util.c, ie alloc_vm_area, free_vm_area, lock_vm_area and > > unlock_vm_area to be exported in order build a loadable xen driver. Can > > these be added?These functions are only needed to build the backend drivers as modules. While this seems like it should be possible, the possibility of removing the backend while frontends exists is a BAD idea and probably should not be possible (unless we have an infrastructure similar to one described by Harry Butterworht).> > Just curious, why do you need loadable Xen drivers?To break Xen in new and interesting ways! Thanks, Jon _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jon Mason wrote:>On Wed, Jan 25, 2006 at 04:25:41PM +0200, Muli Ben-Yehuda wrote: > > >>On Wed, Jan 25, 2006 at 11:36:11AM +0000, Nick Logan wrote: >> >> >>>It certainly seems that you need all of the functions in >>>drivers/xen/util.c, ie alloc_vm_area, free_vm_area, lock_vm_area and >>>unlock_vm_area to be exported in order build a loadable xen driver. Can >>>these be added? >>> >>> > >These functions are only needed to build the backend drivers as modules. >While this seems like it should be possible, the possibility of removing >the backend while frontends exists is a BAD idea and probably should not >be possible (unless we have an infrastructure similar to one described >by Harry Butterworht). > > > >>Just curious, why do you need loadable Xen drivers? >> >> > >To break Xen in new and interesting ways! > >Thanks, >Jon > >Some background to my questions. I am currently investigating the port on the Veritas volume manager and filesystem to the xen architecture. The logical approach is to use the volume manager in Dom0 and the filesystem in DomU and this can currently be done using the vbd driver. However the filesystem in DomU then just sees the volume as a disk partition and is unable to make use of a number of private functions supplied by the volume manager to provide the filesystem with additional functionality and performance. Therefore I am investigating the implementation of a virtual volume driver that would provide those private functions in DomU. There is no need for this driver to be included in the xen source, hence the need for a loadable driver. Nick _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, Jan 26, 2006 at 09:51:56AM +0000, Nick Logan wrote:> Some background to my questions. I am currently investigating the port > on the Veritas volume manager and filesystem to the xen architecture. > The logical approach is to use the volume manager in Dom0 and the > filesystem in DomU and this can currently be done using the vbd driver. > However the filesystem in DomU then just sees the volume as a disk > partition and is unable to make use of a number of private functions > supplied by the volume manager to provide the filesystem with additional > functionality and performance. Therefore I am investigating the > implementation of a virtual volume driver that would provide those > private functions in DomU. There is no need for this driver to be > included in the xen source, hence the need for a loadable driver.Considering that Xen drivers will end up in the Linux tree in the (hopefully) not too distant future, and the Linux community''s well known aversion for out of tree modules, please consider submitting it. It will make your life a whole lot easier in the long run. Cheers, Muli -- Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Muli Ben-Yehuda wrote:>On Thu, Jan 26, 2006 at 09:51:56AM +0000, Nick Logan wrote: > > > >>Some background to my questions. I am currently investigating the port >>on the Veritas volume manager and filesystem to the xen architecture. >>The logical approach is to use the volume manager in Dom0 and the >>filesystem in DomU and this can currently be done using the vbd driver. >>However the filesystem in DomU then just sees the volume as a disk >>partition and is unable to make use of a number of private functions >>supplied by the volume manager to provide the filesystem with additional >>functionality and performance. Therefore I am investigating the >>implementation of a virtual volume driver that would provide those >>private functions in DomU. There is no need for this driver to be >>included in the xen source, hence the need for a loadable driver. >> >> > >Considering that Xen drivers will end up in the Linux tree in the >(hopefully) not too distant future, and the Linux community''s well >known aversion for out of tree modules, please consider submitting >it. It will make your life a whole lot easier in the long run. > >Cheers, >Muli > >Thanks for the suggestion. I''ll certainly consider submitting it as it clearly will have to be a GPL module, but as the associated filesystem and volume manager are not in the tree I''d like to have the option of having it out of the tree. Nick _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel