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
|
Home