From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Logan Subject: Re: Xen-devel Digest, Vol 11, Issue 86 Date: Wed, 25 Jan 2006 11:36:11 +0000 Message-ID: <43D762AB.2010702@symantec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir.Fraser@cl.cam.ac.uk Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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 >Subject: Re: [Xen-devel] EXPORT_SYMBOL for get_vm_area ... >To: Himanshu Raj >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 >Subject: Re: [Xen-devel] Support for AGP aperture as IOMMU in AMD64 > mode [2/2] >To: "Langsdorf, Mark" >Cc: xen-devel@lists.xensource.com >Message-ID: >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 >Subject: Re: [Xen-devel] [PATCH 0/3] domUloader >To: Anthony Liguori >Cc: Xen development list , Kurt Garloff > >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 >Subject: [Xen-devel] New Release Process >To: Ian Pratt , xen-devel > >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" >Subject: RE: [Xen-devel] Support for AGP aperture as IOMMU in AMD64 > mode [2/2] >To: "Keir Fraser" >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" >Subject: RE: [PATCH] Re: [Xen-devel] [PATCH 0/3] domUloader >To: "Tim Deegan" , "Jeremy Katz" > >Cc: xen-devel@lists.xensource.com >Message-ID: > > >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" >Subject: [Xen-devel] [PATCH][RESEND] make xm reboot work for vmx > domain >To: >Message-ID: <8126E4F969BA254AB43EA03C59F44E840488B818@pdsmsx404> >Content-Type: text/plain; charset="us-ascii" > ># HG changeset patch ># User Yu Ke ># 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 > >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 >***************************************** > >