[Xen-devel] Re: [PATCH] xen,tools: pincpu use vcpu and cpumap_t - Ryan Harper - com.xensource.lists.xen-devel

2 messages in com.xensource.lists.xen-devel[Xen-devel] Re: [PATCH] xen,tools: pi...

From	Sent On	Attachments
Ian Pratt	26 Apr 2005 17:50
Ryan Harper	27 Apr 2005 07:04

Subject:	[Xen-devel] Re: [PATCH] xen,tools: pincpu use vcpu and cpumap_t
From:	Ryan Harper (rya...@us.ibm.com)
Date:	04/27/2005 07:04:34 AM
List:	com.xensource.lists.xen-devel

* Ian Pratt <m+Ian....@cl.cam.ac.uk> [2005-04-27 08:55]:

int err, errno_saved; dom0_op_t op; + u32 vcpu = 0; /* FIXME, hard coded initial pin to vcpu 0 */ + cpumap_t cpumap = 1<<cpu;

Ryan, I haven't looked at the whole patch yet, but this comment worried me, as it reminded me of a slightly wider change that I think we need to address at the same time.

We should remove the initial CPU allocation algorithm from xen altogether, and leave it to xend (implementing the same ht-aware algorithm), setting an appropriate pin map for each vcpu. The whole

This patch is pretty big as it is, do you want me to move the cpu allocation out in this patch, or can I follow this patch up with another that moves the allocation out into xend?

pining stuff should be removed from xc_domain_create too as it doesn't belong there.

Hrm, I believe this is a recent change from Keir:

http://lists.xensource.com/archives/html/xen-changelog/2005-04/msg00279.html

I'd be inclined to go for something bigger than a long for the size of the bitmap in the xc interface, even if we only look at the first 32/64 bits within Xen.

OK. I chose an unsigned long as that was what you had indicated we would go with in Xen 3.0. How many bits would like to see the xc interface use?