Re: [Xen-cim] Removing HostedDependency relationships

[Gareth S Bestor <bestorga@xxxxxxxxxx>]

I see your point. But I dont think the HostedDependency semantics, as used in the Resource Allocation Profile, necessarrily implies that only *one* virtual LogicalDevice can be associated to a particular physical LogicalDevice. So we may be fine with using it for CPU pinning, even when multiple VCPUs may be pinned to the same physical CPU.

- G

Jim Fehlig <jfehlig@xxxxxxxxxx>

Jim Fehlig <jfehlig@xxxxxxxxxx>

07/17/06 02:57 PM

To	Gareth S Bestor/Poughkeepsie/IBM@IBMUS
cc	dhiltgen@xxxxxxxxxx, xen-cim@xxxxxxxxxxxxxxxxxxx
Subject	Re: [Xen-cim] Removing HostedDependency relationships

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.

Jim

>
> - G
>
>
> Inactive hide details for Jim Fehlig <jfehlig@xxxxxxxxxx>Jim Fehlig 
> <jfehlig@xxxxxxxxxx>
>
>
>                         *Jim Fehlig <jfehlig@xxxxxxxxxx>*
>                         Sent by: xen-cim-bounces@xxxxxxxxxxxxxxxxxxx
>
>                         07/17/06 02:12 PM
>
> 		 
>
> To
> 		 
> xen-cim@xxxxxxxxxxxxxxxxxxx
>
> cc
> 		 
>
> Subject
> 		 
> [Xen-cim] Removing HostedDependency relationships
>
> 		 
>
>
> I'm debating whether we need Xen_HostedProcessor, Xen_HostedMemory, 
> and Xen_HostedNetworkPort associations. From Resource Allocation Profile:
> /
> 6.3.2 Relationship between Host Resource and Virtual Resource
> When there is a 1-1 correspondence between the Host Resource and the 
> Virtual Resource, the
> HostedDependency association can be used to indicate the correspondence.
>
> In systems where the Virtual Resource always maps to the same Host 
> Resource, the HostedDependency
> association may be used to reflect this relationship. Implementations 
> which support scheduling across the
> pool of host resources transparent to the consumer would not expose 
> the HostedDependency association
> as this relationship could change very frequently/
>
>
> HostedProcessor certain falls into this category. HostedMemory as well 
> since there is no way to map guest's allocated memory to some physical 
> (or logical) host memory. Not sure about HostedNetworkPort. Certainly 
> in simple configurations it is not needed and one could argue in 
> simple cases NetworkPort is fully synthetic. I have not played with 
> the plethora of network configurations possible, so perhaps this 
> association is needed in some cases (e.g. pci passthru of some network 
> card).
>
> Comments about removing these classes and associated code?
>
> Jim_______________________________________________
> Xen-cim mailing list
> Xen-cim@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-cim
>

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