[XenPPC] Re: Third release candidate for 3.1.3
On Wed, Jan 30, 2008 at 09:41:36AM +, Keir Fraser wrote: > 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. I did some very basic testing of bits based upon 3.1.3rc3 and discovered nothing new that's broken, so seems good from my part regards john ___ 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 Sun, Oct 22, 2006 at 05:09:35PM -0400, Jimi Xenidis wrote:
> Hollis and I touched on this and has been the bane of our existence
> since we were required to have Xen interpret user level pointers,
> thread started here:
> http://lists.xensource.com/archives/html/xen-devel/2005-08/
> msg00719.html
>
> 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).
Yes, we should have something better. At the moment I'm trying to clear
out our patch queue (we only have a few hacks left really now...)
The "special pages" idea of yours sounds workable if the
xc_get_pfn_list() thing can be fixed.
> 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)
This would be a little uncomfortable, if only because it's an extra
system call every time. Also letting userspace pin translations in
memory would be troublesome.
> BTW: John, how do you solve the minor faults?!
We currently interpret the ioctl in the privcmd driver and softlock the
mappings in. Which isn't very nice for all the reasons you point out.
regards
john
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [PATCH] architecture-specific stuff in xend
On Thu, Aug 10, 2006 at 04:12:37PM -0500, Hollis Blanchard wrote: > John, would you extend this scheme to cover host OS differences? I think I think it makes sense to use a parallel scheme of xen/xend/host/ for those parameters. That is, the way you've done this looks good to me. > tools/python/xen/util/Brctl.py, wouldn't it make more sense to replace > that file entirely depending on the host OS? Yes. As it is, it's only used for the vnet stuff, which only exists on Linux, so it's not a super-big problem right now. thanks john ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] architecture-specific stuff in xend
On Tue, Aug 08, 2006 at 11:15:18AM -0500, Hollis Blanchard wrote: > > On Solaris some of the Xen binaries/scripts live > > in different locations in order to meet our file system requirements. > > Does that impact code under tools/python/xen much? Very little, but it does affect the location of the network scripts, for example. > > Presumably you could do the instance() singleton trick? > > Not sure what you mean. See XendRoot.py's instance(). > Actually, you bring up a good point: since we have no state (at least > not in the examples I'm thinking of), we really don't want/need a class; > a module would do just fine. So we could have separate files/modules > with just plain functions: > > platform/ia64.py: > def init_reservation(mem_kb): > return something > > platform/platform.py: > import xen.xend.platform.ia64 as platform We'd still need something to import the right bits... regards john ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] architecture-specific stuff in xend
On Tue, Aug 08, 2006 at 10:34:25AM -0500, Hollis Blanchard wrote:
> Rather than having these inline tests everywhere ("if os.uname()[4] in
> ('ia64', 'ppc64'):"), would it make more sense to have some sort of
> "architecture" object, and do things like:
It'd be good if it were slightly more general and covered other system
stuff too (namely OS). On Solaris some of the Xen binaries/scripts live
in different locations in order to meet our file system requirements.
> I'm not sure how/where to instantiate the arch object though.
Presumably you could do the instance() singleton trick?
regards
john
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
