Might it make sense to to add a separate hypercall for getting a
vcpu''s context? It would be cleaner from my standpoint to have
exec_domain be an OUT variable that indicates the number of vcpus in
use. It seems a bit odd getting generic info for a domain and then
specific context for one of the vcpus.
-Kip
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
> Might it make sense to to add a separate hypercall for > getting a vcpu''s context? It would be cleaner from my > standpoint to have exec_domain be an OUT variable that > indicates the number of vcpus in use. It seems a bit odd > getting generic info for a domain and then specific context > for one of the vcpus.I guess it might make sense to split the hypercall in two, as there are several cases where we we don''t ask for the VCPU info. I would like both calls to return the number of VCPUs in use, but we still want the ''give me VCPU x or the next active one if it doesn''t exist'' enumeration scheme since VCPUs can potentially be sparse. Go for it! Cheers, Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> I would like both calls to return the number of VCPUs in use, but we > still want the ''give me VCPU x or the next active one if it doesn''t > exist'' enumeration scheme since VCPUs can potentially be sparse. Go for > it! >Why should GETDOMAINCONTEXT also return the number of active VCPUs? That seems redundant. It would make more sense to me for it to take exec_domain as an in/out variable. The value coming in would be the index into the active CPUs and the out value would be the actual vcpu number. So if you were running with 4 vcpus but only the 4th vcpu was active, the caller would set exec_domain to 0 and then xen would set exec_domain to 3. I''d like to keep the number of iterations to 1, so just to clarify - in GETDOMAININFO, exec_domain will be changed to out variable n_active_vcpus, ctxt will be removed. - GETDOMAINCONTEXT will have two fields, (u16)exec_domain described above and (vcpu_guest_context_t *)ctxt Thanks. -Kip _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Why should GETDOMAINCONTEXT also return the number of active VCPUs?There''s no need.> That seems redundant. It would make more sense to me for it > to take exec_domain as an in/out variable. The value coming > in would be the index into the active CPUs and the out value > would be the actual vcpu number. So if you were running with > 4 vcpus but only the 4th vcpu was active, the caller would > set exec_domain to 0 and then xen would set exec_domain to 3. > > I''d like to keep the number of iterations to 1, so just to clarify > - in GETDOMAININFO, exec_domain will be changed to out > variable n_active_vcpus, ctxt will be removed.Yes.> - GETDOMAINCONTEXT will have two fields, (u16)exec_domain > described above and (vcpu_guest_context_t *)ctxtYes. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 8 May 2005, at 19:09, Kip Macy wrote:> GETDOMAINCONTEXT will have two fields, (u16)exec_domain described > above and (vcpu_guest_context_t *)ctxtGETVCPUCONTEXT? A more descriptive name and clashes less badly with GETDOMAININFO. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> GETVCPUCONTEXT? > > A more descriptive name and clashes less badly with GETDOMAININFO. >Yes, GETVCPUCONTEXT is a more accurate name. That thought was nagging at me but I wasn''t sure it mattered. Change noted. -Kip _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel