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
5 messages in com.xensource.lists.xen-cimRe: [Xen-cim] Removing HostedDependen...
.gif, .gif, .gif