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/
Home Products Support Community News


RE: [Xen-devel] [Patch 2/2] Add dom0_get_sectioninfo for XEN/VTI

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [Patch 2/2] Add dom0_get_sectioninfo for XEN/VTI
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Fri, 17 Jun 2005 09:37:52 +0100
Delivery-date: Fri, 17 Jun 2005 08:36:57 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcVyXcIsVytcYfebSZSjZoKeCr8e2wAuM30g
Thread-topic: [Xen-devel] [Patch 2/2] Add dom0_get_sectioninfo for XEN/VTI
> +/* Request section info which describes memory holes in guest    
> + * physical layer, like mmio, etc. When sections is NULL, return
> + * number of holes. When sections is valid, return section info  
> + * upon requested number.                                        
> + * (ia64 specific now, but should adapt to other arch with holes)
> + */                                                              
> +typedef struct {                                                 
> +    domid_t domain;          /* Domain to be affected */       
> +    u32 section_nr;          /* How many holes existing? */    
> +    dom0_section_t *sections;        /* List to contain 
> section info */
> +} dom0_get_sectioninfo_t;                                        

I'd like to know more about how your propose using this. On x86 VT-x,
the domain builder created the e820 memory map for the domain, so it's
already known outside Xen (including where the various devices live
within the mmio region, which Xen doesn't know). 

In any event, can't your pursuade your unmodified IA64 domains that the
MMIO region lives after the end of RAM? Or is it determined to have it
below 4GB or something? 
It may be convention to have it below 4GB, but does the code actually
break if its above?


Xen-devel mailing list