WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-cim

Re: [Xen-cim] Removing HostedDependency relationships

To: Jim Fehlig <jfehlig@xxxxxxxxxx>, dhiltgen@xxxxxxxxxx
Subject: Re: [Xen-cim] Removing HostedDependency relationships
From: Gareth S Bestor <bestorga@xxxxxxxxxx>
Date: Mon, 17 Jul 2006 14:27:08 -0700
Cc: xen-cim@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 17 Jul 2006 14:27:36 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <44BBFD20.4020802@xxxxxxxxxx>
List-help: <mailto:xen-cim-request@lists.xensource.com?subject=help>
List-id: xen-cim mailing list <xen-cim.lists.xensource.com>
List-post: <mailto:xen-cim@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-cim>, <mailto:xen-cim-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-cim>, <mailto:xen-cim-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-cim-bounces@xxxxxxxxxxxxxxxxxxx

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?

- 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

GIF image

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