separate domain info and vcpu context

separate domain info and vcpu context

[Kip Macy]

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

RE: separate domain info and vcpu context

[Ian Pratt]

 

> 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  

Re: separate domain info and vcpu context

[Kip Macy]

> 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

RE: separate domain info and vcpu context

[Ian Pratt]

> 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 *)ctxt

Yes.

Ian

Re: separate domain info and vcpu context

[Keir Fraser]

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 *)ctxt

GETVCPUCONTEXT?

A more descriptive name and clashes less badly with GETDOMAININFO.

  -- Keir

Re: separate domain info and vcpu context

[Kip Macy]

> 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