* Re: Xen-devel Digest, Vol 11, Issue 86
[not found] <E1Ezkwr-000797-RL@host-192-168-0-1-bcn-london>
@ 2006-01-25 11:36 ` Nick Logan
2006-01-25 11:40 ` EXPORT SYMBOL for alloc_vm_area Nick Logan
2006-01-25 14:25 ` Re: Xen-devel Digest, Vol 11, Issue 86 Muli Ben-Yehuda
0 siblings, 2 replies; 7+ messages in thread
From: Nick Logan @ 2006-01-25 11:36 UTC (permalink / raw)
To: Keir.Fraser; +Cc: xen-devel
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
>*****************************************
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread