What is the right way to query how many vcpus a guest is using? As I
mentioned earlier it would seem to fall under the heading of
GETDOMAININFO, but that obviously doesn''t work.
-Kip
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
SMP save/restore is work in progress so I expect this kind of vital info isn''t exported via the control interfaces at all right now. -- Keir On 29 Apr 2005, at 21:08, Kip Macy wrote:> What is the right way to query how many vcpus a guest is using? As I > mentioned earlier it would seem to fall under the heading of > GETDOMAININFO, but that obviously doesn''t work. > > -Kip > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
* Kip Macy <kip.macy@gmail.com> [2005-04-29 15:09]:> What is the right way to query how many vcpus a guest is using? As I > mentioned earlier it would seem to fall under the heading of > GETDOMAININFO, but that obviously doesn''t work.I posted a [1]patch a while back that surfaced that info in the GETDOMAININFO call. I''m still working more into that patch to support a cpumap which designate which physical cpus a vcpu may use, the current form of that patch is [2]here. 1. http://lists.xensource.com/archives/html/xen-devel/2005-04/msg00412.html 2. http://lists.xensource.com/archives/html/xen-devel/2005-04/msg00890.html -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 ryanh@us.ibm.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Thanks. I need this for coredump and debugging on SMP domains.
I didn''t feel like querying successively higher exec_domains until a
call failed ;-)
-Kip
On 4/29/05, Ryan Harper <ryanh@us.ibm.com> wrote:> * Kip Macy <kip.macy@gmail.com> [2005-04-29 15:09]:
> > What is the right way to query how many vcpus a guest is using? As I
> > mentioned earlier it would seem to fall under the heading of
> > GETDOMAININFO, but that obviously doesn''t work.
>
> I posted a [1]patch a while back that surfaced that info in the
> GETDOMAININFO call. I''m still working more into that patch to
support
> a cpumap which designate which physical cpus a vcpu may use, the current
> form of that patch is [2]here.
>
> 1.
http://lists.xensource.com/archives/html/xen-devel/2005-04/msg00412.html
> 2.
http://lists.xensource.com/archives/html/xen-devel/2005-04/msg00890.html
>
> --
> Ryan Harper
> Software Engineer; Linux Technology Center
> IBM Corp., Austin, Tx
> (512) 838-9253 T/L: 678-9253
> ryanh@us.ibm.com
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
> * Kip Macy <kip.macy@gmail.com> [2005-04-29 15:09]: > > What is the right way to query how many vcpus a guest is using? As I > > mentioned earlier it would seem to fall under the heading of > > GETDOMAININFO, but that obviously doesn''t work. > > I posted a [1]patch a while back that surfaced that info in the > GETDOMAININFO call. I''m still working more into that patch to support > a cpumap which designate which physical cpus a vcpu may use, the current > form of that patch is [2]here. > > 1. http://lists.xensource.com/archives/html/xen-devel/2005-04/msg00412.html > 2. http://lists.xensource.com/archives/html/xen-devel/2005-04/msg00890.htmlThere''s already a cpumask in Xen for physical CPUs (or will be -- it''s called cpuset right now, but that''s going to change to fit the Linux convention). It probably makes sense to rename cpumap to vcpumask, or at least to vcpumap. Also I''d change the appearances of the mask in the dom0 interface from: cpumap_t cpumap[MAX_VIRT_CPUS] And: cpumap_t *cpumap To: u8 vcpumask[MAX_VCPUID/8] Having an array of ''_t'' is odd as each entry in the array is really logically just a single bit. And I would like to separate the size of the array at the admin interfaces from MAX_VIRT_CPUS: it would be nice to be able to increase MAX_VIRT_CPUS without changing the admin interface. That''s why I''d add something like MAX_VCPUID (probably set it to 256). I cc''ed Christian because he is merging one of your patches at the moment. It might be the one without the cpumap additions though. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote:> Also I''d change the appearances of the mask in the dom0 interface from: > cpumap_t cpumap[MAX_VIRT_CPUS] > And: > cpumap_t *cpumap > To: > u8 vcpumask[MAX_VCPUID/8]u8 vcpumask[MAX_VCPUID/8 + 1]> Having an array of ''_t'' is odd as each entry in the array is really > logically just a single bit. And I would like to separate the size of > the array at the admin interfaces from MAX_VIRT_CPUS: it would be nice > to be able to increase MAX_VIRT_CPUS without changing the admin > interface. That''s why I''d add something like MAX_VCPUID (probably set > it to 256).255 (if it''s the maximum ID rather than the number of IDs). -- David Hopwood <david.nospam.hopwood@blueyonder.co.uk> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>> 1. >> http://lists.xensource.com/archives/html/xen-devel/2005-04/ >> msg00412.html >> 2. >> http://lists.xensource.com/archives/html/xen-devel/2005-04/ >> msg00890.html > > There''s already a cpumask in Xen for physical CPUs (or will be -- it''s > called cpuset right now, but that''s going to change to fit the Linux > convention). > > It probably makes sense to rename cpumap to vcpumask, or at least to > vcpumap.Just ignore my previous email -- I completely misunderstood that the cpumaps you added really are physical cpu maps and not virtual cpu maps. cpumap_t is a reasonable name as at least it won''t conflict with type names internal to Xen. However, why pass a pointer to a cpumap_t into PINCPU? And should we cater now for systems with too many cpus to be represented by a long? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> cpumap_t is a reasonable name as at least it won''t conflict > with type names internal to Xen. > > However, why pass a pointer to a cpumap_t into PINCPU? And > should we cater now for systems with too many cpus to be > represented by a long?I think so -- might as well get the interface right. I was thinking something like the fd mask that get''s passed to select, where you sepcify the highest set bit. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 30 Apr 2005, at 19:03, Ian Pratt wrote:>> cpumap_t is a reasonable name as at least it won''t conflict >> with type names internal to Xen. >> >> However, why pass a pointer to a cpumap_t into PINCPU? And >> should we cater now for systems with too many cpus to be >> represented by a long? > > I think so -- might as well get the interface right. I was thinking > something like the fd mask that get''s passed to select, where you > sepcify the highest set bit.In some cases Xen returns a cpumap to the guest (in getdomaininfo). In that case the fd mask trick won''t really work as the guest needs to know in advance the biggetst map that Xen may return. Anyway, a map of 256 bits is going to give us a fair amount of headroom I think. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > I think so -- might as well get the interface right. I was thinking > > something like the fd mask that get''s passed to select, where you > > sepcify the highest set bit. > > In some cases Xen returns a cpumap to the guest (in > getdomaininfo). In that case the fd mask trick won''t really > work as the guest needs to know in advance the biggetst map > that Xen may return. Anyway, a map of > 256 bits is going to give us a fair amount of headroom I think.Why do we need to ever return a cpumap to the guest? Being able to read CPU pining information out isn''t very useful, and both CPUs and VCPUs can be enumerated in the normal manner. Is there something I''ve forgotten? Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
* Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> [2005-05-02 09:07]:> > > > I think so -- might as well get the interface right. I was thinking > > > something like the fd mask that get''s passed to select, where you > > > sepcify the highest set bit. > > > > In some cases Xen returns a cpumap to the guest (in > > getdomaininfo). In that case the fd mask trick won''t really > > work as the guest needs to know in advance the biggetst map > > that Xen may return. Anyway, a map of > > 256 bits is going to give us a fair amount of headroom I think. > > Why do we need to ever return a cpumap to the guest? Being able to read > CPU pining information out isn''t very useful, and both CPUs and VCPUs > can be enumerated in the normal manner. Is there something I''ve > forgotten?If I were writing a load-balancing app I''d like to know where a domains'' vcpus are pinnable. You had previously requested the cpumap to support setting a list of physical cpus on which a vcpu can run. It seems odd (to me) to allow the setting of a variable, but to not be able to see what the current value is. Such an interface requires me to always send a pin operation to ensure the cpumap is set how I want since I cannot confirm the current value. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 ryanh@us.ibm.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 2 May 2005, at 16:21, Ryan Harper wrote:> If I were writing a load-balancing app I''d like to know where a > domains'' > vcpus are pinnable. You had previously requested the cpumap to support > setting a list of physical cpus on which a vcpu can run. It seems odd > (to me) to allow the setting of a variable, but to not be able to see > what > the current value is. Such an interface requires me to always send a > pin operation to ensure the cpumap is set how I want since I cannot > confirm the current value.Makes sense to me. cpumap_t should be bigger than a long then, to allow for future growth. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel