[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] [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] Re: [Xen-devel] [Patch] [RFC] avoid debugger_trap when we don't expect
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. -- Keir On 30/1/08 05:03, "Akio Takebe" <[EMAIL PROTECTED]> wrote: > Hi, > > This patch avoid debugger_trap when we don't setup a debugger. > > kexec_crash() is called after debugger_trap_immediate(). > Because we want to use the safe path at kexecing, > we should avoid the debugger path. > And the trap is a needless work. > > Signed-off-by: Akio Takebe <[EMAIL PROTECTED]> > > Best Regards, > > Akio Takebe > ___ > 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] 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
[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] Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue
Or mercurial has a dependency that behaves differently on your system. This patchqueue is only temporary until the 3.1.1 release -- I'd just modify that one patch in your private repo to exclude the troublesome character. -- Keir On 10/9/07 13:48, "Ben Guthro" <[EMAIL PROTECTED]> wrote: > > Keir Fraser wrote: >> We're using mercurial patchqueues. Mercurial version 0.9.1. I've just cloned >> and applied the patch queue from scratch with no problems. >> >> -- Keir >> > Perhaps it is a regression in the behavior of hg? I am using 0.9.3, and > cannot get the patch queue to apply: > > > [EMAIL PROTECTED] dev]$ rm -rf xen-3.1.hg/ > [EMAIL PROTECTED] dev]$ hg clone -q > http://xenbits.xensource.com/xen-3.1-testing.hg xen-3.1.1.hg > abort: destination 'xen-3.1.1.hg' already exists > [EMAIL PROTECTED] dev]$ rm -rf xen-3.1.1.hg/ > [EMAIL PROTECTED] dev]$ hg clone -q > http://xenbits.xensource.com/xen-3.1-testing.hg xen-3.1.1.hg > [EMAIL PROTECTED] dev]$ cd xen-3.1.1.hg/.hg > [EMAIL PROTECTED] .hg]$ hg clone -q > http://xenbits.xensource.com/xen-3.1-testing.pq.hg patches > [EMAIL PROTECTED] .hg]$ cd .. > [EMAIL PROTECTED] xen-3.1.1.hg]$ hg qpush -a > applying 15023-6e597e529fea > applying 15035-23c4790512db > applying 15038-e19ddfa781c5 > applying 15039-60240a72e2b2 > applying 15043-759d924af6d8 > applying 15044-03a13457d993 > applying 15045-5f6da38ff828 > applying 15046-e527b4ff1948 > applying 15048-e33cce8fa400 > applying 15049-174995130550 > applying 15051-384a29655270 > applying 15052-65ce4866d20b > applying 15053-3ecf51689671 > applying 15056-a605044ecb33 > applying 15057-75b4c7cb007d > applying 15058-3581a77791e3 > applying 15061-05ea0d79a92f > applying 15062-b2adb797900a > applying 15063-807f374e720d > applying 15064-eb027b704dc5 > applying 15065-f4390e34ad12 > applying 15066-9e9c09c75110 > applying 15067-c027880b50b4 > applying 15068-dc4324d3fbb0 > applying 15069-cb006eecd6f5 > applying 15070-fbce94a9feaa > applying 15072-d4a0706d6747 > applying 15073-e1f43038f1d8 > applying 15074-5c7a1e3abd54 > applying 15075-5efb46bfbcac > applying 15076-9ec165fa8128 > applying 15077-711bfe07999b > applying 15078-6145e5508d6b > abort: decoding near 'Ingard Mev�g bytes in position 186-188: invalid data! > transaction abort! > rollback completed > [EMAIL PROTECTED] xen-3.1.1.hg]$ hg --version > Mercurial Distributed SCM (version 0.9.3) > > Copyright (C) 2005, 2006 Matt Mackall <[EMAIL PROTECTED]> > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > ___ 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
We're using mercurial patchqueues. Mercurial version 0.9.1. I've just cloned and applied the patch queue from scratch with no problems. -- Keir On 10/9/07 13:28, "Ben Guthro" <[EMAIL PROTECTED]> wrote: > Also - what tool are you using to apply these patches? > > mercurial queues seem to be incompatible with some of the non utf-8 > characters in some of the patches: > > applying 15075-5efb46bfbcac > applying 15076-9ec165fa8128 > applying 15077-711bfe07999b > applying 15078-6145e5508d6b > abort: decoding near 'Ingard Mev�g bytes in position 186-188: invalid data! > transaction abort! > rollback completed > > Ben Guthro wrote: >> Keir Fraser wrote: >>> 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. >>> >> If I recall - It applied against our 3.1 tree without any >> backporting...we just exported, and applied it. It increased >> performance on Caneland machines greatly. Test results against our 3.1 >> based product below: >> >> >> At Ben's request, I did a quick evaluation of the APIC TPR patch for >> Caneland. >> I used yesterday's build to establish a baseline for booting, running >> SPECjbb2005, and >> netperf on a SMP XP guest. I then repeated the tests with a custom >> kernel. The patch >> showed significant improvement for 2 of the 3 tests I used. Here are >> the results: >> >> Test 20070816 Patch % Improvement >> Boot time - Seconds 62.6 40.5 35% >> SPECjbb2005 OPs/Sec 35216 35686 1% >> TCP XMIT (MBits/sec) 70.2 309.5 341% >> TCP RCV (MBits/Sec) 122.3 423.5 246% >> >> These tests were done on a Caneland, with 4 quad-core sockets and 32GB >> of memory. >> The guest is Windows XP Professional with SP2, 2 CPUs, 2GB memory. >> This afternoon, >> I'll repeat the experiment on a non-Caneland machine to see if there >> are any >> side effects. >> >> >> >>> The two Linux changesets are not applicable to 3.1. >> Yes, of course...my mistake. I forgot to weed out my "unstable-only" >> patches from the list. >> >> >> ___ >> 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] 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] 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] [PATCH 2/3] xencomm take 4: xen side multiple page support
On 28/8/07 07:17, "Isaku Yamahata" <[EMAIL PROTECTED]> wrote:
> +static int
> +xencomm_ctxt_next(struct xencomm_ctxt *ctxt, int i)
> +{
> +BUG_ON(i >= ctxt->nr_addrs);
> +/* in i == 0 case, we already calculated in xecomm_addr_init() */
> +if ( i != 0 )
> +ctxt->address++;
This function may deserve a comment -- what is it for? The 'i == 0' comment
is confusing, and appears to refer to a function that doesn't exist (I
couldn't find any function with suffix _addr_init()).
These patches are all in the staging tree now, so provide delta patches to
apply on top.
-- 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/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
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
[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] todays xen-unstable is throwing gcc errors when compiling on PPC
This problem is caused by my patch which moved the addition of
-fno-strict-aliasing to CFLAGS into Config.mk. At the same time I *removed*
-fno-strict-aliasing from arch/{x86,powerpc,ia64}/Rules.mk. My assumption
was that everyone would simply add to the CFLAGS created by Config.mk and
xen/Rules.mk, just to add arch-specific extras.
I see you do not do this because you have a 'CFLAGS :=' in your
arch/powerpc/Rules.mk. So you need to do one of:
1. Get rid of the 'CFLAGS :=' and simply adapt the generic CFLAGS.
2. Add CFLAGS += -fno-strict-aliasing back into your Rules.mk.
Unless there is a good reason to do otherwise, (1) is the way to go.
-- Keir
On 9/7/07 21:11, "Jerone Young" <[EMAIL PROTECTED]> wrote:
> When compiling Xen on PPC today I get the following error that is being
> caused by casting (u32 *). Once the cast is removed all is well and
> things compile fine. Is this happening on x86 or x86-64 ? I'm using gcc
> 4.1.0 on Suse SLES 10.
>
> There Error:
> grant_table.c: In function gnttab_prepare_for_transfer¹:
> grant_table.c:825: warning: dereferencing type-punned pointer will break
> strict-aliasing rules
> grant_table.c: In function __acquire_grant_for_copy¹:
> grant_table.c:1055: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
> grant_table.c:1080: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
> grant_table.c:1080: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
> grant_table.c:1080: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
> grant_table.c:1080: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
> grant_table.c:1080: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
> make[3]: *** [grant_table.o] Error 1
> make[3]: Leaving directory `/Work/xen-unstable.hg/xen/common'
> make[2]: *** [/Work/xen-unstable.hg/xen/common/built_in.o] Error 2
> make[2]: Leaving directory `/Work/xen-unstable.hg/xen/arch/powerpc'
> make[1]: *** [/Work/xen-unstable.hg/xen/xen] Error 2
> make[1]: Leaving directory `/Work/xen-unstable.hg/xen'
> make: *** [build] Error 2
>
>
>
> ___
> 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] 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] [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
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] 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
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 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
> #include
> #include
> +
> +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
[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
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 0 of 6] PowerPC Linux patches
On 5/7/07 22:08, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote: > These patches reorganize arch-generic Xen Linux code, so I'm sending them by > mail for review. If they are acceptable, I will commit them (and the PowerPC > code that depends on them) to the PowerPC Linux tree so you can pull from > there. > > Please review. Done, and three replies sent. I'll check them in myself. I don't pull in changes to common code from foreign trees as it's too much of a pain to review the changesets. If there are common-code changes in a foreign tree, I don't pull. This has worked fine with ia64 for a long time. -- 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 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] [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
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +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
> #include
> #include
> +
> +#include
> +#include
> +#include
>
> /* 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 CONFIG_XEN
> +HANDLE_IOCTL(IOCTL_PRIVCMD_MMAP_32,
[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] dom0 auto-translate mmap()
On 11/6/07 17:51, "Keir Fraser" <[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. Oh, I see they have their own mmap function. Yes, I think the test can safely be removed. -- 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: [Xen-devel] Re: [Xen-changelog] [xen-unstable] xen: Split domain_flags into discrete first-class fields in the
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? -- 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
Re: [XenPPC] Re: New domain builder in xen-unstable
On 6/3/07 20:56, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote: > Hi Keir, it turns out I was confused about libxc, and we were depending > on the just-removed ELF loader. I'm fixing that now; please give me a > heads-up on the 3.0.5 release so I'm not caught out. You have a couple of weeks at least. > Aside from that, it seems that xc_linux_build() is actually not called > by anybody any longer. It looks like changeset a20ec270998b (from > Brendan) removed the call from xc.c, replacing it with a call to the > "new style" domain builder via xc_dom_linux_build(). > > The new domain builder infrastructure is not flexible enough for > PowerPC, so we're sticking with our own xc_linux_build(). It sounded > before like that would be possible, so I assume a20ec270998b was just an > oversight? Hmm yes. You can #ifdef in the Python wrapper for now. But I'm surprised that you can't move to the new domain builder at all -- it has hooks for arch-dependent code to be inserted already, and we could add more if there's a need. -- 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 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
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
[XenPPC] Re: [Xen-devel] please pull xenppc-unstable-merge.hg
On 14/2/07 16:44, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote: > On Fri, 2007-02-09 at 14:58 -0600, Hollis Blanchard wrote: >> Hi Keir, please pull from >> http://xenbits.xensource.com/ext/xenppc-unstable-merge.hg >> >> Among the PPC updates are the two libelf patches I sent separately. > > Hi Keir, any comments on this? Assuming all looks okay I'll merge the ppc tree in tomorrow morning. Can I delete the old elf code after doing this merge (i.e., are you using libelf now)? -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] /dev/mem and xlate_dev_mem_ptr*()
On 27/1/07 12:49 pm, "Jimi Xenidis" <[EMAIL PROTECTED]> wrote: > in the 2.6.18 linux of the sparse tree you have: > drivers/xen/char/mem.c using xlate_dev_mem_ptr as 2 args. > > What is the story with this? has the interface changed from under you? > Why not invent a new interface that does not conflict, since this is > your code? The functions are used only by the /dev/mem driver so really they belong to us, if you choose to build with our alternative driver. The original interface is unimplementable over Xen (since we do not have 1:1 mappings of everything). If those changes get merged upstream I would expect a size parameter would get added to the function in upstream too. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: New domain builder in xen-unstable
On 26/1/07 5:04 pm, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote: >> Not sure what you mean by "our own domain builder"; we've been >> implementing xc_linux_build() for quite a while now (and thus integrated >> with xend). > > Sorry, I misunderstood. I was seeing all the libelf churn, and I missed > the fact that xc_linux_build() is going away entirely (?). > > I'm still not sure what you mean by "our own domain builder" -- there is > simply no way we're going to add more ifdefs to > tools/libxc/xc_linux_build.c (or equivalent)... xc_linux_build() is still provided in the 'new world' and is still used by xend. For ia64/x86 it is now a thin wrapper around Gerd's new domain-building infrastructure. For ppc you can continue to have your very own version under libxc/powerpc if you want to, and not use Gerd's new domain-building infrastructure. But the elf code that you rely on is going away, so you need to move to using libelf, which I'm sure Gerd can give you some pointers about. -- 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 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] schedule() vs softirqs
On 15/12/06 19:09, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote: > Ah OK, I see now how x86 is doing that. I don't think that code flow > really makes sense: why would you jump out of do_softirq() into assembly > just to call do_softirq() again? Well, that's the way it works out on x86. It is a bit odd, but it works and is unlikely to affect performance. I think returning from schedule() would have its own problems (e.g., context switch from idle domain to guest would return to the idle loop, which we'd need explicit code to bail from, etc). > Also, that doesn't solve the lazy register saving problem. I assume this is a PPC-specific issue? > However, I think I see how we can implement our desired context_switch() > scheme in arch-specific code. The context_switch() call in schedule() > will return, so please don't add a BUG() after that. :) We already support this mode of operation for IA64 which always returns from schedule(). -- 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 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] [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 10:42, "Isaku Yamahata" <[EMAIL PROTECTED]> wrote: >> 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). > > Here is the patch. Powerpc guys may have their own idea, though. > Unfortunately 4 #ifndef's are needed. That's still pretty bad. I'll rewrite the hypercall to avoid using guest_handle_add_offset(). -- 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] [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] 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] [PATCH] don't use mlock() with Solaris tools
On 22/10/06 22:09, "Jimi Xenidis" <[EMAIL PROTECTED]> wrote:
> I cannot speak for Hollis (I think he may actually disagree with me)
> but see this as an opportunity to design something better, or at
> least have the debat (again).
> What might be a better alternative an to actually have an allocate
> call rather than an mlock call where the arches and OSes could to
> what is best for them.
> So what is done on x86 could be:
>do { x = alloca(len); mlock (x, len); } while (0)
>
> but where solaris and other arches could do something more.
It would change the API too, since memory buffers passed in by callers to
libxc would also need to be allocated in a special way. Unless you would be
prepared to perform the hypercall on a shadow buffer and then copy to the
caller buffer, which I suppose would be a simpler API.
John's patch is fine 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] [TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn
On 20/10/06 09:01, "Gerd Hoffmann" <[EMAIL PROTECTED]> wrote: >> 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). > > Who does that hypercall btw? Seems not to be somewhere in the > xc_linux_build() code path ... Everyone goes through xc_get_pfn_list() (except ia64, who are 'special' ;-). -- 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 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 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] [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 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
Re: [XenPPC] Re: [Xen-devel] [PATCH 0/6][TOOLS][XM-TEST] [v2] Update xm-test to support new architectures
On 3/10/06 17:39, "Aron Griffis" <[EMAIL PROTECTED]> wrote: > Keir Fraser wrote: [Tue Oct 03 2006, 11:59:28AM EDT] >> Xen-unstable is currently a staging tree for xen-3.0.3-testing. Development >> is frozen until 3.0.3-0 is released. > > Hi Keir, > > Why are you doing it this way? I thought a staging tree was somewhere > you could test builds prior to moving changesets to the live tree, so > you could yank the changesets, reset the staging tree, etc. without > affecting anybody. Shouldn't there be a separate staging tree for > xen-3.0.3-testing? Plus if xen-unstable is staging for > xen-3.0.3-testing, then it seems like branching was pointless. Since development is frozen to concentrate on bug fixing, we may as well use xen-unstable as the staging point for candidate patches rather than creating an entirely new tree. Creating an explicit xen-3.0.3-testing tree and announcing official release candidates encourages a broader range of people to test the code (many will not touch xen-unstable at all). Development is not frozen because we are using xen-unstable as a staging tree. It is frozen simply because we are at the bug-fixing stage in the release cycle. -- 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 0/6][TOOLS][XM-TEST] [v2] Update xm-test to support new architectures
On 3/10/06 16:53, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote: >> I've got no particular problem with these patches (we'll host the >> buildroot tar on xenbits, which was the only query). The tree's >> feature-frozen now though -- we're at RC2 -- so these will drop in >> immediately after the release. > > Which tree, xen-3.0.3-testing? I was asking about xen-unstable... Xen-unstable is currently a staging tree for xen-3.0.3-testing. Development is frozen until 3.0.3-0 is released. -- 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 25/9/06 15:09, "Jimi Xenidis" <[EMAIL PROTECTED]> wrote:
> Here is the code that cares:
>
> #ifdef CRASH_DEBUG
> if (__trap_to_gdb(regs, cookie) == 0)
> return;
> #endif /* CRASH_DEBUG */
>
> printk("%s: type: 0x%lx\n", __func__, cookie);
> show_backtrace_regs(regs);
> machine_halt();
>
> NOTE: we will revisit the call to machine_halt() later, we can't use
> panic() because right now we'll end up back in this fuction.
Yeah, ok this is quite reasonable.
-- 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 25/9/06 14:27, "Jimi Xenidis" <[EMAIL PROTECTED]> wrote: > Currently there are two failure cases: >1) GDB had no transport available for its use (UART or otherwise) >2) "unexpected trap", usually another trap occurs while gdb is in > control > > I suppose we could have (1) -EIO and (2) -EBUSY. > My logic was that either gdb was available or not and that I needed > to continue as if gdb was not enabled at all. How would your behaviour differ if gdbstub actually ran and eventually returned control to you, versus the trap into the debugger being a simple no-op? Surely the caller doesn't really care either way? -- 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 13/9/06 10:23, "Keir Fraser" <[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(). Sorry, I'm talking rubbish here. As you say, the relevant code is actually in the foreign mapping paths (e.g., in arch/x86/mm.c). Those paths do a get_page() on the foreign page. This stops it being removed from the domU page list. A non-empty page list holds a reference on the domU. So the domU will not die until that foreign mapping is destroyed. -- 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: [Xen-devel] What actually destroys a domain?
Xenconsoled's mapping of the console page should keep the domain alive. -- Keir On 12/9/06 2:22 am, "Jimi Xenidis" <[EMAIL PROTECTED]> wrote: > > Collegues say that x86 does not have this problem, however on PowerPC if you: > 1) start a domain > 2) attach console > 3) destroy the domain > > The xenconsole client stays connected because xenconsoled does not close > the PTY. A character on the client will kick the close and all is > well. Xenconsoled _does_ get the watch event, but the domain is > completely destroyed and xc_domain_getinfo does not find it to > eventually close() the PTY > > It is possible that PowerPC is missing a get_domain(), perhpas by a > resource held by xenconsoled? > Any thoughts? > -JX > > ___ > 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] should vcpu_pause()/vcpu_sleep_nosync() give up?
On 7/9/06 14:37, "Jimi Xenidis" <[EMAIL PROTECTED]> wrote: >> these assumptions are likely not true and the CPU has gone >> down taking some locks with it. > > Hypervisors should increase the availability of the machine as a > whole, PPC machines tend to have many HA features that when unhandled > (mostly ECC) can cause a CPU to go down. Unhandled errors should make the *machine* fail-stop, not just one CPU. High availability is important, but getting the correct answer from your computations tends to rank higher. If hardware detects an unrecoverable error that cannot be handled sanely in software either, I think most people would agree it's time for a reboot. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] should vcpu_pause()/vcpu_sleep_nosync() give up?
On 6/9/06 2:18 pm, "Jimi Xenidis" <[EMAIL PROTECTED]> wrote: > First off, I realize I have an SMP bug where my second processor is > hung somewhere, I'm not sure where, but for the sake of this argument > lets assume it has suffered an unrecoverable fault. > > My primary CPU is fine and is hung in vcpu_sleep_nosync() because the > secondary will not clear its _VCPUF_running bit. ITYM vcpu_sleep_sync(). Hint is in the name. ;-) The nosync variant does not spin on the _running flag. > While I have this error I would like to give up and try and recover > from it. > How long is long enuff? > thoughts? Holy crap! Are you assuming that the offline CPU was not running anything other than the idle loop or guest code, and that you'll simply destroy the guest if one was running (since you can't really continue it)? Given that this is a software bug, these assumptions are likely not true and the CPU has gone down taking some locks with it. However, being optimistic, I suppose a few 100ms would be plenty to know that something is probably up. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [Xen-devel] [PATCH][XEN] remove include checks from domctl.h and sysctl.h
On 5/9/06 21:17, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote: > A very similar problem hits us when building Linux. Without __XEN__ or > __XEN_TOOLS__ defined, Linux gets a __XEN_INTERFACE_VERSION__ of 0, and > so the current API will never be used (regardless of what the tools > tried to do). > > Are you intentionally requiring that Linux do this? If so, in which > Linux header file would you like this to go? > #define __XEN_INTERFACE_VERSION__ __XEN_LATEST_INTERFACE_VERSION__ It's defined for you in drivers/xen/Kconfig. All other arches then fold it into CFLAGS in arch//Makefile. This ensures that it is defined absolutely *everywhere*, avoiding the possibility of having it defined as latest versionin one place and zero in an other (which would be really confusing). That's what I'd recommend for powerpc as well, even though it probably requires you to modify a file that's otherwise 'Xen clean'. > Or perhaps, since the kernel is acting as a proxy for the tools, you > would rather see this? > #define __XEN_TOOLS__ Yes, but only in the file that does the virt-to-phys conversions on the domctl/sysctl interfaces. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [PATCH][XEN] remove include checks from domctl.h and sysctl.h
On 5/9/06 20:33, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote: >> That's not going to be true for PowerPC and soon IA64. >> >> Because of Xen's use of pointers for hypercall parameters, we need the >> kernel to translate virtual addresses to physical addresses. That means >> any time a new hypercall is introduced to the tools, our kernel needs to >> change to translate the new data structure. > > Therefore, the following patch is required. Please apply. > > [XEN] remove include checks from domctl.h and sysctl.h > Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]> No thanks: we really don't want inclusion of those header files to slip into use in kernel builds. I suggest limiting your touching of domctl/sysctl to one source file in Linux, and compile that file with -D__XEN_TOOLS__. This will help ensure that you can at least limit the kernel tainting to one (potentially upgradeable) module. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Re: [patch] fix void* arithmetic
On 29/8/06 10:18 pm, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote: >> Looks like PPC is the only arch using -Wpointer-arith, is there a reason >> for that? > > Is there are reason the other architectures *aren't* using it? > > We have some extra warnings enabled because they've helped us in the > past (such as -Wshadow). Given that we're just playing janitor for > everyone else's code though, I think we're about to abandon that one. We have code borrowed from Linux that doesn't like -Wpointer-arith very much, so we took the pragmatic path here. -- 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 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
[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] fix vga.c compilation
On 16/8/06 4:35 pm, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote: > On Wed, 2006-08-16 at 11:49 +0100, Keir Fraser wrote: >> @@ -159,12 +160,8 @@ >> * into a single 16-bit quantity */ >> #define VGA_OUT16VAL(v, r) (((v) << 8) | (r)) >> >> -#if defined(__i386__) || defined(__x86_64__) >> -# define vgabase 0 >> -# define VGA_OUTW_WRITE >> -# define vga_readb(x) (*(x)) >> -# define vga_writeb(x,y) (*(y) = (x)) >> -#endif >> +#define vgabase 0 /* use in/out port-access macros */ >> +#define VGA_OUTW_WRITE/* can use outw instead of 2xoutb */ > > When would you redefine vgabase? Right there, with ifdef's, when an arch comes along that requires it. >> +const struct font_desc font_vga_8x8, font_vga_8x14, font_vga_8x16; > > I think there could be a cleaner separation between console.c and vga.c, > and that would avoid needing to redefine these symbols. For example, > right now cls(), init_vga(), and others still live in console.c, most of > them manually testing vgacon_enabled. > > What would be better is a system where console drivers (i.e. serial and > vga) register themselves at boot time, so console.c putchar() becomes: Well, that'd be more important if it were likely that the powerpc dummy versions were going to stick around. Since they're not, I don't think we need to over-engineer a solution looking for a problem. -- 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
Re: [Xen-devel] Re: [XenPPC] [PATCH] [POWERPC] fix vga.c compilation
On 16/8/06 10:15 am, "Keir Fraser" <[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,. Here you go. Arch/powerpc/vga.c isn't great but I assume it's temporary until vga support is fixed properly. If you think it looks okay I'll apply it. Also Sign-off or Ack if you like. -- Keir vga-fix.patch Description: Binary data ___ 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
[XenPPC] Re: [Xen-devel] Re: [Xen-changelog] [XENBUS] Avoid direct use of xen_start_info.
On 14/8/06 8:37 pm, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote: > Could we abstract this part more please? I think calling into an > arch-provided xen_get_store_mfn() function would be good. (And of course > the same for store_evtchn and the console_* equivalents.) No, that's it from Steve's patch queue. Further cleanup here would be nice though, so please send patches. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Re: [PATCH] [LIBXC] add architecture-specific parameter to xc_linux_build()
On 9/8/06 4:14 pm, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote: > That direction certainly seems like a good one to me. > > In this case, we need to load the device tree into the domain's memory > and pass its address in a register (i.e. via xc_vcpu_setcontext). > Currently it doesn't look like xc_vcpu_setcontext is exposed to python > for us to use. What would you like to see here? Hmmm... I was expecting you'd want a ppc-specific libxenguest or libxenctrl function, but I guess maybe you could do it by more generic means. That would obviously be much preferable if it's possible. Could a copy_to/from_guest interface exposed to Python be used? Or does the device tree need some processing in C into an appropriate format for writing into guest memory? As for set/get_vcpu_context, the context could be expressed as a Python dictionary mapping register names to (reasonably constrained) long values. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [PATCH] [LIBXC] add architecture-specific parameter to xc_linux_build()
On 9/8/06 4:00 pm, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote: >> The diffstat doesn't correspond to the patch. Can I ignore the diffstat? > > Sorry for being unclear. The diffstat corresponds to the contents of the > xenppc-unstable-merge.hg tree, which I was asking you to pull. Ah, I missed that bit. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Re: [PATCH] [LIBXC] add architecture-specific parameter to xc_linux_build()
On 9/8/06 10:56 am, "Keir Fraser" <[EMAIL PROTECTED]> wrote: >> Keir, this patch applies on top of the xc.c whitespace patch I just >> sent, and also on top of the contents of xenppc-unstable-merge.hg >> (because we've moved xc_ppc_linux_build.c into its own directory). We >> also have a couple important fixes in there anyways, so now would be a >> good time to pull. :) > > The diffstat doesn't correspond to the patch. Can I ignore the diffstat? Actually I'm not sure about this approach at all. Couldn't specifying the open firmware tree be done separately from the build (e.g., just after)? Maybe hooked off the new proposed 'platform object' in xend. Xc_linux_build is really ugly enough already: I think in future we would like to split xc_linux_build up into smaller API functions, even for x86, and that the patch you propose goes in the opposite direction to this. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [PATCH] [LIBXC] add architecture-specific parameter to xc_linux_build()
On 8/8/06 9:28 pm, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote: > Keir, this patch applies on top of the xc.c whitespace patch I just > sent, and also on top of the contents of xenppc-unstable-merge.hg > (because we've moved xc_ppc_linux_build.c into its own directory). We > also have a couple important fixes in there anyways, so now would be a > good time to pull. :) The diffstat doesn't correspond to the patch. Can I ignore the diffstat? -- 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
[XenPPC] Re: [patch] [ppc] use xen_ulong_t in start_info
On 27 Jul 2006, at 21:40, Hollis Blanchard wrote: Keir, you mentioned that start_info probably doesn't make much sense for PowerPC. However, if for no other reason than linux/drivers/xen has many references to it, we'd like to fix it for now and figure out how to replace it later. I think that structure is quite x86-specific. I'd be happy to see direct references to start_info replaced in drivers/xen. Obvious (and ugly) low-hanging fruit is test for SIF_INITDOMAIN. Replacing with arch-specific is_initial_domain() or similar would be a great patch to receive. A couple of the others (e.g., console_mfn, store_mfn) are a bit harder -- how do you communicate those on ppc? -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [RFC PATCH 28/33] Add Xen grant table support
On 25 Jul 2006, at 19:30, Hollis Blanchard wrote: I object to these uses of (synch_)cmpxchg on a uint16_t in common code. Many architectures, including PowerPC, do not support 2-byte atomic operations, but this code is common to all Xen architectures. We'll use synch_cmpxchg_subword() in the next iteration of these patches. It's already been applied to our main Xen repository but hadn't been applied to our merge repo when these patches were created. -- Keir ___ Xen-ppc-devel mailing list [EMAIL PROTECTED] http://lists.xensource.com/xen-ppc-devel
