[XenPPC] Re: [Xen-devel] [Patch] [RFC] avoid debugger_trap when we don't expect
On 30/1/08 08:48, Akio Takebe [EMAIL PROTECTED] wrote: This doesn't need to be fixed on x86 -- the int3 handler will return silently if the debugger is not configured. It would be nice if the ia64 handler would do the same. If that is not possible then change only ia64 code and if you need to be able to probe gdbstub configuration then add a public function to do that rather than grope at internal state. The same goes for powerpc, *if* it is broken in the first place. I know the int3 hanlder return well on x86 if it is not configured. But the route may be not safe. The debugger_trap is called after hypervisor panic and dom0 panic. So I want to avoid the needless route for kexec/kdump. Oh no, then all bets are off. :-) We could be screwed and fail to kexec no matter what we do. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Third release candidate for 3.1.3
A new releaase candidate is tagged in http://xenbits.xensource.com/xen-3.1-testing.hg. Assuming no problems are revealed by testing, I'd like to make this the proper 3.1.3 release asap. Thanks, Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [PATCH] nr_cpus calculation problem due to incorrect sockets_per_node
No changes are allowed to the tools interfaces within a stable release
series. It'll be in 3.2.0 in a few weeks time.
-- Keir
On 29/10/07 15:37, beth kon [EMAIL PROTECTED] wrote:
Hi. Wondering if this patch has been reviewed and could be considered
for inclusion in 3.2. Sorry about the late request. You were asking for
input last week.
beth kon wrote:
Testing on an 8-node 128-way NUMA machine has exposed a problem with
Xen's nr_cpus calculation. In this case, since Xen cuts off recognized
CPUs at 32, the machine appears to have 16 CPUs on the first and
second nodes and none on the remaining nodes. Given this asymmetry,
the calculation of sockets_per_node (which is later used to calculate
nr_cpus) is incorrect:
pi-sockets_per_node = num_online_cpus() /(num_online_nodes() *
pi-cores_per_socket * pi-threads_per_core);
The most straightforward solution is to remove sockets_per_node, and
instead determine nr_cpus directly from num_online_cpus.
This patch has been tested on x86_64 NUMA machines.
diff -r b4278beaf354 docs/man/xm.pod.1
--- a/docs/man/xm.pod.1 Wed Oct 17 13:12:03 2007 +0100
+++ b/docs/man/xm.pod.1 Wed Oct 17 20:09:46 2007 -0700
@@ -446,7 +446,6 @@ page more readable):
machine: i686
nr_cpus: 2
nr_nodes : 1
- sockets_per_node : 2
cores_per_socket : 1
threads_per_core : 1
cpu_mhz: 696
diff -r b4278beaf354 tools/python/xen/lowlevel/xc/xc.c
--- a/tools/python/xen/lowlevel/xc/xc.c Wed Oct 17 13:12:03 2007 +0100
+++ b/tools/python/xen/lowlevel/xc/xc.c Wed Oct 17 20:09:46 2007 -0700
@@ -721,7 +721,7 @@ static PyObject *pyxc_physinfo(XcObject
max_cpu_id, info.max_cpu_id,
threads_per_core, info.threads_per_core,
cores_per_socket, info.cores_per_socket,
-sockets_per_node, info.sockets_per_node,
+nr_cpus, info.nr_cpus,
total_memory,
pages_to_kib(info.total_pages),
free_memory,
pages_to_kib(info.free_pages),
scrub_memory,
pages_to_kib(info.scrub_pages),
diff -r b4278beaf354 tools/python/xen/xend/XendNode.py
--- a/tools/python/xen/xend/XendNode.py Wed Oct 17 13:12:03 2007 +0100
+++ b/tools/python/xen/xend/XendNode.py Wed Oct 17 20:09:46 2007 -0700
@@ -475,7 +475,7 @@ class XendNode:
cpu_info = {
nr_nodes: phys_info[nr_nodes],
-sockets_per_node: phys_info[sockets_per_node],
+nr_cpus: phys_info[nr_cpus],
cores_per_socket: phys_info[cores_per_socket],
threads_per_core: phys_info[threads_per_core]
}
@@ -580,17 +580,9 @@ class XendNode:
str='none\n'
return str[:-1];
-def count_cpus(self, pinfo):
-count=0
-node_to_cpu=pinfo['node_to_cpu']
-for i in range(0, pinfo['nr_nodes']):
-count+=len(node_to_cpu[i])
-return count;
-
def physinfo(self):
info = self.xc.physinfo()
-info['nr_cpus'] = self.count_cpus(info)
info['cpu_mhz'] = info['cpu_khz'] / 1000
# physinfo is in KiB, need it in MiB
@@ -600,7 +592,6 @@ class XendNode:
ITEM_ORDER = ['nr_cpus',
'nr_nodes',
- 'sockets_per_node',
'cores_per_socket',
'threads_per_core',
'cpu_mhz',
diff -r b4278beaf354 tools/python/xen/xm/main.py
--- a/tools/python/xen/xm/main.py Wed Oct 17 13:12:03 2007 +0100
+++ b/tools/python/xen/xm/main.py Wed Oct 17 20:09:46 2007 -0700
@@ -1667,9 +1667,8 @@ def xm_info(args):
release: getVal([software_version, release]),
version: getVal([software_version, version]),
machine: getVal([software_version, machine]),
-nr_cpus: len(getVal([host_CPUs], [])),
+nr_cpus: getVal([cpu_configuration, nr_cpus]),
nr_nodes: getVal([cpu_configuration, nr_nodes]),
-sockets_per_node: getVal([cpu_configuration,
sockets_per_node]),
cores_per_socket: getVal([cpu_configuration,
cores_per_socket]),
threads_per_core: getVal([cpu_configuration,
threads_per_core]),
cpu_mhz: getCpuMhz(),
diff -r b4278beaf354 tools/xenmon/xenbaked.c
--- a/tools/xenmon/xenbaked.c Wed Oct 17 13:12:03 2007 +0100
+++ b/tools/xenmon/xenbaked.c Wed Oct 17 20:09:46 2007 -0700
@@ -460,10 +460,7 @@ unsigned int get_num_cpus(void)
xc_interface_close(xc_handle);
opts.cpu_freq = (double)physinfo.cpu_khz/1000.0;
-return (physinfo.threads_per_core *
-
[XenPPC] Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue
Can you please provide a patch to apply to xen-3.1-testing.pq.hg? The patches you add to the queue should have the same style of changeset comment as the existing ones -- 'hg export' format plus the two xen-unstable changeset references immediately after the signed-off-by line(s). I've cc'ed Ben Guthro since he also has proposed a few patches, and I'd like to receive a patch from him for those too. Including 15185, since I changed my mind on that one! Fix the odd characters in changeset comments at the same time, if they're still causing you problems. Thanks, Keir On 11/9/07 16:15, Alex Williamson [EMAIL PROTECTED] wrote: Updated cset numbers now that all the ia64 patches are merged into mainline... On Mon, 2007-09-10 at 13:18 -0600, Alex Williamson wrote: http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?rev/6644d8486266 ia64/15762:6644d8486266 - cleanup NVRAM failure case Now http://xenbits.xensource.com/staging/xen-unstable.hg?rev/6644d8486266 15850:6644d8486266 http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?rev/f88eea67a469 *ia64/15764:f88eea67a469 - move NVRAM from /usr to /var Now http://xenbits.xensource.com/staging/xen-unstable.hg?rev/f88eea67a469 15852:f88eea67a469 (but you'll still need to use the modified version attached previously) Thanks, Alex ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Xen 3.1.1 -- initial patchqueue
Hi, A provisional patchqueue for Xen 3.1.1 is available at http://xenbits.xensource.com/xen-3.1-testing.pq.hg. This pq partners with http://xenbits.xensource.com/xen-3.1-testing.hg. Please kick this pq around and check whether the patches you want to see in 3.1.1 are included. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue
On 10/9/07 13:03, Ben Guthro [EMAIL PROTECTED] wrote: 15185-1f8fb764f843 http://xenbits.xensource.com/xen-unstable.hg?rev/1f8fb764f843 I'm inclined not to backport this one. 15806-577313e3c0a6 (not exactly crucial, but would be nice) http://xenbits.xensource.com/xen-unstable.hg?rev/577313e3c0a6 Yes could take this one. The two Linux changesets are not applicable to 3.1. -- Keir linux: 189-720571c2139e http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/720571c2139e 193-9e03bcda0054 http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/9e03bcda0054 ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [PATCH 0/7] xencomm take 3: preparation for consolidation and various fixes
On 14/8/07 10:50, Isaku Yamahata [EMAIL PROTECTED] wrote: This take 3 patch series is for xencomm consolidation and various fixes. I split up the xen side patch into 4 smaller ones and cleaned them up. Linux side patch is same as previous one. The issue is the complexity and the multi page support. So I think that 3/7, 4/7 and 7/7 are moot, other patches can be merged. All applied but 3, 4, 7. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [PATCH 0/4] xencomm take 2: preparation for consolidation and various fixes
I'll apply these if Alex and Hollis will ack them. -- Keir On 13/8/07 04:59, Isaku Yamahata [EMAIL PROTECTED] wrote: This updated patch series is for xencomm consolidation and various fixes based on Hollis's comment. Changes from take 1: xen side varisous fixes and preparation for consolidation - sorted out the maddr and vaddr issue - returning an error with warning message instead of panicing domain. linux side various fixes and preparation for consolidation - update gcc work around. It is a generic issue, not ia64 specific. 3/4 and 4/4 patch is same. [PATCH 1/4] xencomm take 2: xen side varisous fixes and preparation for consolidation [PATCH 2/4] xencomm take 2: linux side various fixes and preparation for consolidation [PATCH 3/4] xencomm take 2: linux side introduce struct xencomm_handle * [PATCH 4/4] xencomm take 2: linux side remove xencomm page size limit Thanks, ___ Xen-devel mailing list [EMAIL PROTECTED] http://lists.xensource.com/xen-devel ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [PATCH 0/4] xencomm take 2: preparation for consolidation and various fixes
On 13/8/07 13:44, Alex Williamson [EMAIL PROTECTED] wrote: On Mon, 2007-08-13 at 10:10 +0100, Keir Fraser wrote: I'll apply these if Alex and Hollis will ack them. They look OK to me. Acked-by: Alex Williamson [EMAIL PROTECTED] Okay, just needs someone from the PPC side to comment, then. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Re: [Xen-devel] [PATCH 6 of 6] [XEN][LINUX] Add 32-bit privcmd ioctlconversion for 64-b
On 9/7/07 10:03, Jan Beulich [EMAIL PROTECTED] wrote: We've already fixed all the shared structures (e.g. sysctl) to use explicitly-sized types, so the PowerPC port has always had proper interfaces. For example, look at the definition of xen_ulong_t on the different architectures. The x86 interfaces were frozen too early, cementing this problem for you. Oh, sorry, I forgot that you had this taken care of implicitly on PPC. I had hoped we could leverage the code you are adding for x86, but - no luck. I think the only structure that actually needs conversion is the xen_pfn_t array in privcmd_mmapbatch. So it's not as bad as it first appears. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [PATCH] Take a writer lock for mmap_sem.
On 9/7/07 16:45, Hollis Blanchard [EMAIL PROTECTED] wrote: My mistake, I meant to send this separately. In 2.6.17, we did our own locking inside direct_remap_pfn_range(). In the current Linux tree though, the locking is done in privcmd_ioctl(). However, since direct_remap_pfn_range() is modifying the mm_struct, shouldn't that be a a write lock rather than a read lock? Ah yes, agreed. All other callers seem to get this implicitly because they are -mmap handlers. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Re: [Xen-changelog] [linux-2.6.18-xen] Add #ifdef ARCH_HAS_DEV_MEM to archtecture specific file_operations.
On 9/7/07 20:20, Hollis Blanchard [EMAIL PROTECTED] wrote: By the way, I wonder how PPC manages to build both drivers/char/mem.c and drivers/xen/char/mem.c without ARCH_HAS_DEV_MEM? The model is supposed to be that mem_fops defined by the Xen file is picked up by the generic file. If !ARCH_HAS_DEV_MEM then that doesn't happen -- so who picks up the Xen mem_fops? Hmmm, yeah. Looks like we haven't tested that... :) If you don't need to build both then there is potentially no problem with the Xen file hijacking the xlate_dev_mem() functions. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] please pull PowerPC trees
Changes inside powerpc files are fine. Obviously powerpc-specific changes inside common files are usually fine. Changes to locking protocols in common files (e.g., changed usage of mmap_sem in privcmd.c) is *not* fine. Please post patches for that kind of thing. -- Keir On 6/7/07 22:29, Hollis Blanchard [EMAIL PROTECTED] wrote: Hi Keir, thanks for merging the Linux patches we've been discussing. Please pull PowerPC Xen Linux support from http://xenbits.xensource.com/ext/ppc/linux-2.6.18-xen.hg Then, please pull from http://xenbits.xensource.com/ext/ppc/xen-unstable.hg Among other things, it includes changes necessary to run the new Linux 2.6.18 kernel. Thanks! ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [PATCH 6 of 6] [XEN][LINUX] Add 32-bit privcmd ioctlconversion for 64-bit kernels
On 6/7/07 09:09, Jan Beulich [EMAIL PROTECTED] wrote: --- a/fs/compat_ioctl.c Thu Jul 05 17:25:47 2007 -0500 +++ b/fs/compat_ioctl.c Thu Jul 05 17:26:48 2007 -0500 @@ -2948,6 +2953,18 @@ COMPATIBLE_IOCTL(LPRESET) /*LPGETSTATS not implemented, but no kernels seem to compile it in anyways*/ COMPATIBLE_IOCTL(LPGETFLAGS) HANDLE_IOCTL(LPSETTIMEOUT, lp_timeout_trans) + +#ifdef CONFIG_XEN +HANDLE_IOCTL(IOCTL_PRIVCMD_MMAP_32, privcmd_ioctl_32) +HANDLE_IOCTL(IOCTL_PRIVCMD_MMAPBATCH_32, privcmd_ioctl_32) +COMPATIBLE_IOCTL(IOCTL_PRIVCMD_HYPERCALL) Where does the hypercall argument translation happen? I'll check in patches 1-5 now, addressing Jan's minor comments. Sounds like this one needs at least an email response, or maybe another iteration. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [PATCH 5 of 6] [XEN][LINUX] Refactor grant table allocation into arch-specific code
Patches 1 thru 4 are applied. This one (patch 5) breaks the x86 build and
even if that is fixed breaks the semantics of gnttab_map()
(apply_to_page_range() is invoked on every call, not just when
shared==NULL).
-- Keir
On 5/7/07 23:27, Hollis Blanchard [EMAIL PROTECTED] wrote:
3 files changed, 27 insertions(+), 18 deletions(-)
arch/ia64/xen/hypervisor.c |5 +
drivers/xen/core/gnttab.c | 38 --
include/xen/gnttab.h |2 ++
# HG changeset patch
# User Hollis Blanchard [EMAIL PROTECTED]
# Date 1183674347 18000
# Node ID 9def23611685442dc9688ad8f81db9a5031b4b5f
# Parent 790e4d5567dcd8bfb42ae1e67ad1f3dffd29ece1
[XEN][LINUX] Refactor grant table allocation into arch-specific code.
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
diff -r 790e4d5567dc -r 9def23611685 arch/ia64/xen/hypervisor.c
--- a/arch/ia64/xen/hypervisor.c Thu Jul 05 16:58:26 2007 -0500
+++ b/arch/ia64/xen/hypervisor.c Thu Jul 05 17:25:47 2007 -0500
@@ -408,6 +408,11 @@ __xen_destroy_contiguous_region(unsigned
#include linux/mm.h
#include xen/interface/xen.h
#include xen/gnttab.h
+
+void *arch_gnttab_alloc_shared(unsigned long *frames)
+{
+ return __va(frames[0] PAGE_SHIFT);
+}
static void
gnttab_map_grant_ref_pre(struct gnttab_map_grant_ref *uop)
diff -r 790e4d5567dc -r 9def23611685 drivers/xen/core/gnttab.c
--- a/drivers/xen/core/gnttab.c Thu Jul 05 16:58:26 2007 -0500
+++ b/drivers/xen/core/gnttab.c Thu Jul 05 17:25:47 2007 -0500
@@ -430,7 +430,7 @@ static inline unsigned int max_nr_grant_
#ifdef CONFIG_XEN
-#ifndef __ia64__
+#ifdef __x86__
static int map_pte_fn(pte_t *pte, struct page *pmd_page,
unsigned long addr, void *data)
{
@@ -448,7 +448,22 @@ static int unmap_pte_fn(pte_t *pte, stru
set_pte_at(init_mm, addr, pte, __pte(0));
return 0;
}
-#endif
+
+void *arch_gnttab_alloc_shared(unsigned long *frames)
+{
+ unsigned long *_frames = frames;
+ struct vm_struct *area;
+
+ area = alloc_vm_area(PAGE_SIZE * max_nr_grant_frames());
+ BUG_ON(area == NULL);
+
+ rc = apply_to_page_range(init_mm, (unsigned long)area-addr,
+ PAGE_SIZE * nr_gframes,
+ map_pte_fn, _frames);
+ BUG_ON(rc);
+ return area-addr;
+}
+#endif /* __x86__ */
static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
{
@@ -473,21 +488,8 @@ static int gnttab_map(unsigned int start
BUG_ON(rc || setup.status);
-#ifndef __ia64__
- if (shared == NULL) {
- struct vm_struct *area;
- area = alloc_vm_area(PAGE_SIZE * max_nr_grant_frames());
- BUG_ON(area == NULL);
- shared = area-addr;
- }
- rc = apply_to_page_range(init_mm, (unsigned long)shared,
- PAGE_SIZE * nr_gframes,
- map_pte_fn, frames);
- BUG_ON(rc);
-frames -= nr_gframes; /* adjust after map_pte_fn() */
-#else
- shared = __va(frames[0] PAGE_SHIFT);
-#endif
+ if (shared == NULL)
+ shared = arch_gnttab_alloc_shared(frames);
kfree(frames);
@@ -623,7 +625,7 @@ int gnttab_resume(void)
int gnttab_suspend(void)
{
-#ifndef __ia64__
+#ifdef CONFIG_X86
apply_to_page_range(init_mm, (unsigned long)shared,
PAGE_SIZE * nr_grant_frames,
unmap_pte_fn, NULL);
diff -r 790e4d5567dc -r 9def23611685 include/xen/gnttab.h
--- a/include/xen/gnttab.h Thu Jul 05 16:58:26 2007 -0500
+++ b/include/xen/gnttab.h Thu Jul 05 17:25:47 2007 -0500
@@ -117,6 +117,8 @@ int gnttab_suspend(void);
int gnttab_suspend(void);
int gnttab_resume(void);
+void *arch_gnttab_alloc_shared(unsigned long *frames);
+
static inline void
gnttab_set_map_op(struct gnttab_map_grant_ref *map, maddr_t addr,
uint32_t flags, grant_ref_t ref, domid_t domid)
___
Xen-devel mailing list
[EMAIL PROTECTED]
http://lists.xensource.com/xen-devel
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [Xen-devel] Re: [XenPPC] [PATCH][POWERPC] Fix missing '{' for mm.c in xen-unstable
On 6/7/07 16:33, Hollis Blanchard [EMAIL PROTECTED] wrote: Doh, thanks. I have had this locally, but apparently forgot to push it... I will apply to the PPC tree, along with a few other changes, and push upstream later. Ah, I just threw it into the xen-unstable main tree. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [PATCH 3 of 6] [XEN][LINUX] Add architecture-generic xencomm infrastructure
On 5/7/07 22:08, Hollis Blanchard [EMAIL PROTECTED] wrote: diff -r 001c42f8079e -r e2681868041e drivers/xen/Kconfig --- a/drivers/xen/Kconfig Thu Jul 05 16:01:18 2007 -0500 +++ b/drivers/xen/Kconfig Thu Jul 05 16:01:18 2007 -0500 @@ -278,4 +278,7 @@ config XEN_BALLOON bool default y +config XEN_XENCOMM + bool + Shouldn't this have a 'depends on', and 'default y'? -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [PATCH 6 of 6] [XEN][LINUX] Add 32-bit privcmd ioctl conversion for 64-bit kernels
CONFIG_COMPAT stuff doesn't belong in include/xen/public/privcmd.h. That
header is shared with userspace so it should stay clean. Make a new one in
include/xen, or in drivers/xen/privcmd, whichever makes most sense.
-- Keir
On 5/7/07 22:08, Hollis Blanchard [EMAIL PROTECTED] wrote:
5 files changed, 113 insertions(+), 2 deletions(-)
drivers/xen/Makefile |2
drivers/xen/privcmd/Makefile |3 -
drivers/xen/privcmd/compat_privcmd.c | 72 ++
fs/compat_ioctl.c| 16 +++
include/xen/public/privcmd.h | 22 ++
# HG changeset patch
# User Hollis Blanchard [EMAIL PROTECTED]
# Date 1183669279 18000
# Node ID 7cae4be9db6be7b7d0c91dbb785ae14261c7116d
# Parent 3ece3641ec01362c4333c74688a7f04ae4706ba4
[XEN][LINUX] Add 32-bit privcmd ioctl conversion for 64-bit kernels.
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
diff -r 3ece3641ec01 -r 7cae4be9db6b drivers/xen/Makefile
--- a/drivers/xen/Makefile Thu Jul 05 16:01:19 2007 -0500
+++ b/drivers/xen/Makefile Thu Jul 05 16:01:19 2007 -0500
@@ -1,7 +1,6 @@ obj-y += core/
obj-y += core/
obj-y += console/
obj-y += evtchn/
-obj-y += privcmd/
obj-y += xenbus/
obj-y += gntdev/
obj-y += char/
@@ -18,3 +17,4 @@ obj-$(CONFIG_XEN_PCIDEV_FRONTEND) += pci
obj-$(CONFIG_XEN_PCIDEV_FRONTEND) += pcifront/
obj-$(CONFIG_XEN_FRAMEBUFFER) += fbfront/
obj-$(CONFIG_XEN_KEYBOARD) += fbfront/
+obj-$(CONFIG_XEN_PRIVCMD) += privcmd/
diff -r 3ece3641ec01 -r 7cae4be9db6b drivers/xen/privcmd/Makefile
--- a/drivers/xen/privcmd/Makefile Thu Jul 05 16:01:19 2007 -0500
+++ b/drivers/xen/privcmd/Makefile Thu Jul 05 16:01:19 2007 -0500
@@ -1,2 +1,3 @@
-obj-$(CONFIG_XEN_PRIVCMD) := privcmd.o
+obj-y += privcmd.o
+obj-$(CONFIG_COMPAT) += compat_privcmd.o
diff -r 3ece3641ec01 -r 7cae4be9db6b drivers/xen/privcmd/compat_privcmd.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/drivers/xen/privcmd/compat_privcmd.c Thu Jul 05 16:01:19 2007 -0500
@@ -0,0 +1,72 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Copyright (C) IBM Corp. 2006
+ *
+ * Authors: Jimi Xenidis [EMAIL PROTECTED]
+ */
+
+#include linux/config.h
+#include linux/compat.h
+#include linux/ioctl.h
+#include linux/syscalls.h
+#include asm/hypervisor.h
+#include asm/uaccess.h
+#include xen/public/privcmd.h
+
+int privcmd_ioctl_32(int fd, unsigned int cmd, unsigned long arg)
+{
+ int ret;
+
+ switch (cmd) {
+ case IOCTL_PRIVCMD_MMAP_32: {
+ struct privcmd_mmap *p;
+ struct privcmd_mmap_32 *p32;
+ struct privcmd_mmap_32 n32;
+
+ p32 = compat_ptr(arg);
+ p = compat_alloc_user_space(sizeof(*p));
+ if (copy_from_user(n32, p32, sizeof(n32)) ||
+ put_user(n32.num, p-num) ||
+ put_user(n32.dom, p-dom) ||
+ put_user(compat_ptr(n32.entry), p-entry))
+ return -EFAULT;
+
+ ret = sys_ioctl(fd, IOCTL_PRIVCMD_MMAP, (unsigned long)p);
+ }
+ break;
+ case IOCTL_PRIVCMD_MMAPBATCH_32: {
+ struct privcmd_mmapbatch *p;
+ struct privcmd_mmapbatch_32 *p32;
+ struct privcmd_mmapbatch_32 n32;
+
+ p32 = compat_ptr(arg);
+ p = compat_alloc_user_space(sizeof(*p));
+ if (copy_from_user(n32, p32, sizeof(n32)) ||
+ put_user(n32.num, p-num) ||
+ put_user(n32.dom, p-dom) ||
+ put_user(n32.addr, p-addr) ||
+ put_user(compat_ptr(n32.arr), p-arr))
+ return -EFAULT;
+
+ ret = sys_ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH, (unsigned long)p);
+ }
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ return ret;
+}
diff -r 3ece3641ec01 -r 7cae4be9db6b fs/compat_ioctl.c
--- a/fs/compat_ioctl.c Thu Jul 05 16:01:19 2007 -0500
+++ b/fs/compat_ioctl.c Thu Jul 05 16:01:19 2007 -0500
@@ -123,6 +123,10 @@
#include linux/dvb/frontend.h
#include linux/dvb/video.h
#include linux/lp.h
+
+#include xen/interface/xen.h
+#include xen/public/evtchn.h
+#include xen/public/privcmd.h
/* Aiee. Someone does not find a difference between int and long */
#define EXT2_IOC32_GETFLAGS _IOR('f', 1, int)
@@ -2948,6 +2952,18 @@ COMPATIBLE_IOCTL(LPRESET)
/*LPGETSTATS not implemented, but no kernels seem to compile it in anyways*/
COMPATIBLE_IOCTL(LPGETFLAGS)
HANDLE_IOCTL(LPSETTIMEOUT, lp_timeout_trans)
+
+#ifdef
Re: [XenPPC] Re: [Xen-devel] [PATCH 3 of 6] [XEN][LINUX] Add architecture-generic xencomm infrastructure
On 5/7/07 22:35, Hollis Blanchard [EMAIL PROTECTED] wrote: +config XEN_XENCOMM + bool + Shouldn't this have a 'depends on', and 'default y'? This will be selected by architectures that need it. If that means it is automatically be handled by the build system and won't appear in 'make menuconfig' then that's fine. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [PATCH 4 of 6] [XEN][LINUX] #ifdef x86-specific alloc_vm_area()
On 5/7/07 22:08, Hollis Blanchard [EMAIL PROTECTED] wrote: [XEN][LINUX] #ifdef x86-specific alloc_vm_area(). Since neither IA64 nor PowerPC wants this code, in the future it should really be moved out of drivers/xen/ Signed-off-by: Hollis Blanchard [EMAIL PROTECTED] The IA64 version will get merged into drivers/xen/util at some point, so the old todo message still applies. x86 will need an ia64-style one for supporting e.g., backend-pv-drivers-on-hvm. Probably just getting rid of XXX/TODO messages altogether is fine. It's fairly obvious there may be work to be done wherever #ifdef arch crops up in driver code. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] dom0 auto-translate mmap()
On 11/6/07 17:42, Hollis Blanchard [EMAIL PROTECTED] wrote: The net is that I would like to remove the above test. I wonder why it was added in the first place? Somebody has a privileged autotranslate domain and mistakenly tried to run the domain building tools? Interesting. How does this work for ia64 currently? I think ia64 always runs in auto-translate mode. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Re: [Xen-changelog] [xen-unstable] xen: Split domain_flags into discrete first-class fields in the
On 5/4/07 16:56, Keir Fraser [EMAIL PROTECTED] wrote: On 5/4/07 16:44, Hollis Blanchard [EMAIL PROTECTED] wrote: This is an interface problem: using the interface in a way that works on x86 fails on other architectures. PLEASE let's redefine the interface to prevent this from happening. In this case, that means replacing the xchg() macro with static inline xchg(atomic_t *ptr, atomic_t val) and changing the type of 'is_dying'. Just need to define bool_t appropriately. What do you need: a long? Does PowerPC support atomic byte loads and stores by the way (i.e., concurrent loads and stores to adjacent bytes by different processors do not conflict with each other)? In which case it might be worth keeping bool_t and defining atomic_bool_t or atomic_rmw_bool_t for bools that need to be atomically read-modified-written. That would avoid bloating critical structures for the few bools that need atomic r-m-w semantics. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: please pull xenppc-unstable-merge.hg
On 21/3/07 23:48, Hollis Blanchard [EMAIL PROTECTED] wrote: Hi Keir, please pull from http://xenbits.xensource.com/ext/xenppc-unstable-merge.hg Done. It looks like that will bring in about 775 changesets without changing any code, but that's the amount of work you would have gotten all along; it's just coming in all at once (flooding xen-changelog). Also, not all of them have proper DCO lines. What do you think? I think you should have a flag day for all ppc developers where you export any patches that you want to keep that aren't in xen-unstable, throw away xenppc-unstable, and rebase to xen-unstable. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: Periodic VIRQ_TIMER required?
On 9/3/07 21:16, Hollis Blanchard [EMAIL PROTECTED] wrote: So in conclusion, I think we'll need the legacy behavior, though it might be interesting for us in the future to modify Linux to use hcalls to create timer events. Okay. That¹s where Jeremy is going with the paravirt_ops patches (for x86 only right now, of course). Linux 2.6 now has dynticks (as of 2.6.21-rc I think) which means the kernel can run tickless, which is nice when running in a virtualised environment. I¹ll give you back the old behaviour for now. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] please pull xenppc-unstable-merge.hg
The xenppc-unstable is already merged and fixed. -- Keir On 5/3/07 19:24, Hollis Blanchard [EMAIL PROTECTED] wrote: There are two patches that touch common code: * Add a guest_physmap hook for max_mem changes. We've finally gotten around to removing a hack we've carried in the PowerPC tree for a while and we're using the guest_physmap_* hooks instead. At least for now we're using an array for p2m translation, and that means we need to know how big to make it. * Yamahata-san's PowerPC dynamic grant table patch. It looked a little hairy to me, but when I sat down with it I couldn't figure out how to improve it, at least until PowerPC gets rid of some assumptions about MFN locations. I had accidentally added a file in xen/include/asm (instead of asm-powerpc), which made asm a directory and broke the symlink creation. I've fixed that now. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Re: [Xen-devel] [PATCH] [GNTTAB] expandable grant table
On 26/2/07 23:31, Hollis Blanchard [EMAIL PROTECTED] wrote: Hi Yamahata-san, thanks very much for your patch! I'm confused about one thing though: why do we need to take a lock to read d-grant_table-nr_grant_frames? It's a simple integer, so no lock is required or useful. I haven't got the ppc code immediately to hand but the x86 code will dynamically grow the grant table based on requests made via the add_to_physmap hypercall, hence it needs to take the lock. I see ia64 takes it also even though it only reads from nr_grant_frames (it won;t dynamically expand via the add_to_physmap hypercall). That's possibly overkill although there is some concern over reading nr_grant_frames versus looking up a grant-table page that appears within the range [0, nr_grant_frames-1] which taking the lock trivially sidesteps. If ia64 didn't take the lock it might be possible to see an increased value of nr_grant_frames that the expand function hadn't yet fully installed the new grant-table pages for yet. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Re: [Xen-devel] [PATCH] [GNTTAB] expandable grant table
On 27/2/07 00:05, Hollis Blanchard [EMAIL PROTECTED] wrote: I don't believe that's a concern, since updating grant_table-nr_grant_frames is the very last step in gnttab_grow_table(), and it will only grow. If there's a memory barrier before the update of nr_grant_frames, explicitly or implied, then removing the locking from add_to_physmap is fine. Otherwise not: reading an integer is atomic, but using that as a flag to indicate presence of other state updated under the same lock is just a little bit suspect (but might be okay). -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Re: [Xen-changelog] [xen-unstable] [HVM] save restore: new hyper-call
On 19/1/07 17:50, Hollis Blanchard [EMAIL PROTECTED] wrote: This patch breaks PowerPC, which does not supply arch_(get| set)hvm_ctxt(). In fact, I don't see where IA64 supplies these either. Please revert and refactor into arch_do_domctl(), thanks. Now done. K. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] schedule() vs softirqs
On 15/12/06 17:27, Hollis Blanchard [EMAIL PROTECTED] wrote: We recently uncovered a bug on PowerPC where if a timer tick arrives just inside schedule() while interrupts are still enabled, the decrementer is never reprogrammed to that appropriate value. This is because once inside schedule(), we never handle any subsequent softirqs: we call context_switch() and resume the guest. Easily fixed. You need to handle softirqs in the exit path to guest context. You need to do this final check with interrupts disabled to avoid races. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] schedule() vs softirqs
On 15/12/06 20:41, Hollis Blanchard [EMAIL PROTECTED] wrote: It's an issue with any architecture with a large number of registers which aren't automatically saved by hardware (and a C ABI that makes some of them non-volatile). x86 has a small number of registers. ia64 automatically saves them (from what I understand). So of the currently-supported architectures, yes, that leaves PowerPC. I see. It sounds like returning from context_switch() is perhaps the right thing for powerpc. That would be easier if you have per-cpu stacks (like ia64). If not there are issues in saving register state later (and hence delaying your call to context_saved()) as there are calls to do_softirq() outside your asm code (well, not many, but there is one in domain.c for example) where you won't end up executing your do_softirq() wrapper. In general we'd like to reserve the right to include voluntary yield points, and that won't mix well with lazy register saves and per-physical-cpu stacks. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [PATCH][XEN][POWERPC] allocate shadow memory for PPC Linux domains
On 8/12/06 8:25 pm, Hollis Blanchard [EMAIL PROTECTED] wrote: Allocate shadow memory for PPC Linux domains. Signed-off-by: Hollis Blanchard [EMAIL PROTECTED] Just check all these patches into the PPC tree and I¹ll merge them into unstable with the rest. I always check the diff when I merge anyway. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: Question about: [LINUX] Various fixes for mmapping I/O and foreign memory pages.
On 13/11/06 8:50 pm, Jimi Xenidis [EMAIL PROTECTED] wrote: auto-translate guests can use remap_pfn_range() rather than direct_remap_pfn_range(). This change was specifically made so that mmap of /dev/mem would work (i.e., mapping of I/O memory) on mini-xen (dom0 guest running on minimal non-virtualising Xen shim). And code says: kfraser 12392: /* Unsupported for auto-translate guests. */ kfraser 12392: if (xen_feature(XENFEAT_auto_translated_physmap)) kfraser 12392: return -ENOSYS; Is there a privcmd that auto-translate guests can use or are you expecting someone to fill this functionality in? This needs filling in. Specifically: how will another domain's memory appear in the local pseudophysical memory map (since that is the address space of guest pagetable entries)? -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [PATCH] xencomm, xenmem and hypercall continuation
On 10/11/06 5:49 am, Isaku Yamahata [EMAIL PROTECTED] wrote: fix xenmem hypercall for non-trivial xencomm arch(i.e. ia64, and powerpc) On ia64 and powerpc, guest_handle_add_offset() effect persists over hypercall continuation because its consumed offset is recorced in guest domains memory space. On the other hand, x86 guest_handle_add_offset() effect is volatile over hypercall continuation. So xenmem hypercall(more specifically increase_reservation, decrease_reservaton, populate_memory and exchange) is broken on ia64 and powerpc. #ifdef/ifndef CONFIG_X86 is used to solve this issue without breaking the existing ABI. #ifdef is ugly, but it would be difficult to solve this issue without #ifdef and to preserve the existing ABI simaltaneously. There must be a cleaner solution. We're not going to ifdef all over the place. Does xencomm have to persist the offset increments in guest memory (does the guest depend on this)? Could it undo these effects across continuations so that guest_handle_add_offset works properly? -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [PATCH] xencomm, xenmem and hypercall continuation
On 10/11/06 08:45, Isaku Yamahata [EMAIL PROTECTED] wrote: - introduce guest_handle_add_offset_after_continuatiton() and replace guest_handle_add_offset() in memory.c with it. leave do_multicall() and guest_console_write() as is. This is the best option I think. But I'm loathe to make it part of the guest_handle API. We should avoid getting into this mess in the first place for future hypercalls, so this will be a memory-specific function. We should stick it at the top of memory.c, with a comment and make it a no-op dependent on something like ARCH_HAS_XENCOMM (or just __ia64__ || __powerpc__ would be fine, actually, since it's just one place). -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] RFC: PowerPC and VIO
On 30/10/06 8:51 pm, Jimi Xenidis [EMAIL PROTECTED] wrote: Immediate questions do come to mind: Why do we return the MFN on a GNTTABOP_map_grant_ref? It's the *dev* *bus* *addr*. The one you program into your device's DMA engine. We can't hide that. Yes, in future it will not necessarily be the MFN (as would be seen on the FSB) as the device bus will be in a different address-translation space. -- Keir Shouldn't that all be hidden? I use it now, but can I depend on it in the future? ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn
On 20/10/06 13:29, Gerd Hoffmann [EMAIL PROTECTED] wrote: I'm not after the xc_get_pfn_list hypercall, but the (appearently?) other hypercall Keir mentioned ... Could be xc_domain_memory_increase_reservation() or xc_domain_memory_populate_physmap() ... Oh, it's called from xend python land somewhere... :-) -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn
On 18/10/06 10:57 pm, Jimi Xenidis [EMAIL PROTECTED] wrote: It looks like IA64 has introduced a start_pfn for xc_get_pfn_list(). The PPC port requires this as well since it allows us to fill in the page_array a little bit at a time. I can either replicate the IA64 ifdef logic (yuk!) or we can formally add a start_pfn to this interface, since it _is_ a formal member of the data structure. I'll take a stab at it, if it is acceptable. Where is the ifdef logic? -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn
On 19/10/06 14:12, Jimi Xenidis [EMAIL PROTECTED] wrote: use the start_pfn member of struct xen_domctl_getmemlist Fix all callers and change xen to pay attention to it, I think I have the x86-xen patch. Sure. Actually this interface is going away for x86, but not in the immediate future. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn
On 19/10/06 14:54, Jimi Xenidis [EMAIL PROTECTED] wrote: use the start_pfn member of struct xen_domctl_getmemlist Fix all callers and change xen to pay attention to it, I think I have the x86-xen patch. Sure. Actually this interface is going away for x86, but not in the immediate future. Any hints, I'd like to go away for PPC as well :) It's only really used to get pages in PFN order. This can be done by other means -- for paravirt save/restore we access the guest's own P2M table; for HVM guests I intend to change the mapping interface so that all callers specify pages by PFN rather than MFN. That pretty much leaves only the domain builder. I could leave the interface just for that I suppose, but equally we could fill in the initial P2M table when we allocate the domain's initial memory reservation (since that hypercall returns the PFNs). Maybe we won't kill the domctl after all, but we'll certainly be using it a whole lot less. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [PATCH 0/3][XM-TEST] Updates to xm-test ramdisk code
On 29/9/06 5:52 am, Hollis Blanchard [EMAIL PROTECTED] wrote: 1: Instead of using a dated snapshot (which no longer exists) use buildroot-snapshot. 2: Remove hardcoded references to i386. 3: Rename configs/buildroot - configs/buildroot-i386 and update Makefiles. With patches applied x86 still builds an initrd.img Feedback appreciated. Who maintains xm-test and could take a look at these patches? Ewan Mellor normally would. He's on holiday until Monday. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [PATCH][XEN] __trap_to_gdb should return something different
On 22/9/06 4:07 pm, Jimi Xenidis [EMAIL PROTECTED] wrote: --text follows this line-- This patch allows the caller to find out if the gdbstub actually did anything. Signed-off-by: Jimi Xenidis [EMAIL PROTECTED] What different actions do you envisage the caller will take? If they are reasonable, perhaps they should be explicitly specified in a return-code enumeration? -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] What actually destroys a domain?
On 12/9/06 14:05, Jimi Xenidis [EMAIL PROTECTED] wrote: Xenconsoled's mapping of the console page should keep the domain alive. hmm, I'm having trouble associating the mapping and a refcount of some sort somewhere, any pointers? See share_xen_page_with_guest() in arch/x86/mm.c. The refcnt is dropped when xenheap_pages field reduces to zero in common/page_alloc.c:free_domheap_pages(). -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: Resend: [Xen-devel] [PATCH][TOOLS] Fix xenconsoled SEGV if domain is destroyed while connected.
On 27/8/06 11:01 pm, Jimi Xenidis [EMAIL PROTECTED] wrote: Any response to this? http://lists.xensource.com/archives/html/xen-devel/2006-08/ msg01315.html It's fine. I'm just behind on applying patches. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] RFC: xencomm in common
On 21/8/06 9:03 am, Tristan Gingold [EMAIL PROTECTED] wrote: xencomm is the ppc infrastructure to do hypercalls with guest physical addresses instead of virtual address. Because ia64 should also use physicall address, I think it's better to re-use the ppc code and to put into common code. I'd propose to submit this patch is every part is OK (ie no NAK). This patch creates include/xen/xencomm_access.h which is to be included by asm/guest_access.h. It also creates common/xencomm.c which is compiled only if HAS_XENCOMM is y in Rules.mk. Fine in principle. Specific comments: * powerpc should be cleaned up at the same time to use the common infrastructure. I don't want duplicated code hanging around in arch/powerpc * The code you add to common/ should obey the coding style of other files in that directory * Arguably we should have an asm-generic for the xencomm guest-access macros. That's a Linux-ism which I think fits well in this particular case. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] RFC: xencomm in common
On 21/8/06 10:20 am, Tristan Gingold [EMAIL PROTECTED] wrote: Fine in principle. Specific comments: * powerpc should be cleaned up at the same time to use the common infrastructure. I don't want duplicated code hanging around in arch/powerpc I have attached a blindly-made patch again powerpc files. If ppc people could check this, I'd be happy. * The code you add to common/ should obey the coding style of other files in that directory * Arguably we should have an asm-generic for the xencomm guest-access macros. That's a Linux-ism which I think fits well in this particular case. Taken into account in this updated patch. Looks better. I assume you'll resend with signed-off-by when you want these applied. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] [POWERPC] fix vga.c compilation
On 16/8/06 1:30 am, Hollis Blanchard [EMAIL PROTECTED] wrote: Looks like I bungled this whitespace; could you fix when you commit please? It would probably be best to combine this patch with the ia64 patch and put both our signed-off lines on it. (I'll sign off on Alex's changes, FWIW.) I don't think the diffs between the arches should be sufficient to warrant whole new header files. I'll cook up a combined patch and post it,. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [Xen-devel] Re: [XenPPC] [PATCH] [POWERPC] fix vga.c compilation
On 16/8/06 2:59 pm, Alex Williamson [EMAIL PROTECTED] wrote: In general this looks a lot better, but I think ia64 is still going to have trouble with the chunk below. It seems that a VGA card operating in a standard text mode doesn't necessarily respond to all of these addresses. On some ia64 platforms that causes a hard fail response (the bus goes fatal and a reboot follows). On my system, the 0xB8000 test looks like it will probably work, but we never get there because either the 0xA or the 0xB test will cause the hardfail. Do we need to poke the card through I/O port space to get it into the right mode before probing it in MMIO space? I don't know enough about the VGA programming model to be able to do that. The card works once we start talking to it correctly, but this probe is a little too brute force. Thanks, Actually I'm not sure this is particularly necessary for headless x86 either. I could move the test to the end of setup_vga(), and only probe 0xb8000? x86 is more 'resilient' to random memory and port accesses. I don't think it'll matter that we do lots of port accesses even if a vga adapter isn't present. If we keep the conventional-ram test as well, then that'll be the same level of checking that Linux does on ia64. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Re: [Xen-changelog] [xen-unstable] [IA64] Creates tools/libxc/ia64 directory.
On 28 Jul 2006, at 20:17, Hollis Blanchard wrote: I'm not sure this is the best way. We'll need to do the same thing for xc_ppc_linux_build.c, but it seems a little silly to unconditionally include powerpc/Makefile as well... perhaps -include $(XEN_TARGET_ARCH)/Makefile would suffice? That's actually what I ended up checking in. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
