Re: [Xen-cim] Removing HostedDependency relationships

[Daniel Hiltgen <dhiltgen@xxxxxxxxxx>]

On Mon, Jul 17, 2006 at 03:57:28PM -0600, Jim Fehlig wrote:
> Gareth S Bestor wrote:
> >
> >The HostedDependency association is only necessary when you have a 
> >direct pass-thru device, which today in our Xen CIM providers we do 
> >not (but will soon for, say, the PCI devices). So yes, these 
> >associations are certainly not *required* for the initial set of 
> >supported Xen device types we have today. As background, these 
> >associations were coded to provide a path from the virtual devices to 
> >the physical devices backing them *before* the resource pools were put 
> >in. In the case of Xen_Processor and Xen_Memory, the physical 
> >processor and memory need to be mapped into their respective pools, 
> >and the virtual devices' setting data associated with the pool instead 
> >(via AllocatedFromPool)
> >
> >However, this brings up the interesting question of whether it is 
> >strictly *not* allowed to have this association when you do not have 
> >direct resource assignement? Or put another way, are we willing to say 
> >that a virtual LogicalDevice that has a HostedDependency (to a 
> >physicla device) is therefore (always) a direct pass-thru assignment?
> >
> 
> Hmm, processor is an interesting case.  You can pin multiple guest VCPUs 
> to a PCPU.  In this case the virtual resource always maps to the same 
> physical resource, but the physical resource is shared as well.  Maybe I 
> should keep HostedProcessor around to depict this affinity.

The Resource Allocation Profile doesn't address affinity, and the
Virtual CPU Profile hasn't been written yet, so this behavior is
undefined.  I don't think HostedDependency is the right mechanism to
convey that behavior.  This seems like more of a setting detail than
run-time data.  We need a distinction between pinning a virtual CPU and
requesting that a virtual CPU be scheduled someplace but allowed to run
elsewhere.  As currently defined RASD only has a mechanism for pinning.

Daniel

-- 
Daniel Hiltgen (dhiltgen@xxxxxxxxxx)  650-384-4156
Virtual Infrastructure Management CIM SDK

_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim