Date: Thu, 19 Jan 2006 19:14:21 +0000
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] EXPORT_SYMBOL for get_vm_area ...
To: Himanshu Raj <rhim@xxxxxxxxxxxxx>
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Message-ID: <27575039d47752db8a244204172080c8@xxxxxxxxxxxx>
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@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Support for AGP aperture as IOMMU in AMD64
mode [2/2]
To: "Langsdorf, Mark" <mark.langsdorf@xxxxxxx>
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Message-ID: <bd4a929caa2d8de8aa371c18f59bc751@xxxxxxxxxxxx>
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@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0/3] domUloader
To: Anthony Liguori <aliguori@xxxxxxxxxx>
Cc: Xen development list <xen-devel@xxxxxxxxxxxxxxxxxxx>, Kurt Garloff
<garloff@xxxxxxx>
Message-ID: <1137691193.2740.43.camel@xxxxxxxxxxxxxx>
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@xxxxxxxxxx>
Subject: [Xen-devel] New Release Process
To: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, xen-devel
<xen-devel@xxxxxxxxxxxxxxxxxxx>
Message-ID: <43D0179A.5050905@xxxxxxxxxx>
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@xxxxxxx>
Subject: RE: [Xen-devel] Support for AGP aperture as IOMMU in AMD64
mode [2/2]
To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Message-ID:
<84EA05E2CA77634C82730353CBE3A84303218ACE@xxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii
-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
Keir Fraser
Sent: Thursday, January 19, 2006 1:32 PM
To: Langsdorf, Mark
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxx>
Subject: RE: [PATCH] Re: [Xen-devel] [PATCH 0/3] domUloader
To: "Tim Deegan" <Tim.Deegan@xxxxxxxxxxxx>, "Jeremy Katz"
<katzj@xxxxxxxxxx>
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Message-ID:
<CA95C29D57188841ABB072EA7357C00D0ABA30C9@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxx>
Subject: [Xen-devel] [PATCH][RESEND] make xm reboot work for vmx
domain
To: <Xen-devel@xxxxxxxxxxxxxxxxxxx>
Message-ID: <8126E4F969BA254AB43EA03C59F44E840488B818@pdsmsx404>
Content-Type: text/plain; charset="us-ascii"
# HG changeset patch
# User Yu Ke <ke.yu@xxxxxxxxx>
# 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@xxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
End of Xen-devel Digest, Vol 11, Issue 86
*****************************************
