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

Re: [Xen-devel] Porting PV-on-HVM for ia64 platform

To: <Doi.Tsunehisa@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Porting PV-on-HVM for ia64 platform
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Sun, 27 Aug 2006 15:51:29 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sun, 27 Aug 2006 07:51:48 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200608262152.k7QLq3Q08704@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: AcbJ6EcnhZn35jXbEdukHgAKle7CWA==
Thread-topic: [Xen-devel] Porting PV-on-HVM for ia64 platform
User-agent: Microsoft-Entourage/11.2.5.060620


On 26/8/06 10:52 pm, "Doi.Tsunehisa@xxxxxxxxxxxxxx"
<Doi.Tsunehisa@xxxxxxxxxxxxxx> wrote:

>   In IPF, V2P address translation uses TR, TC and VHPT. VHPT is like page
> table in x86 platform, and TC is like TLB in it exept for direct handling
> posibility. But TR is specific for IPF. TR is controled directly with MM,
> its entry does not be deleted by hardware if MM does not control it.
> 
>   In additionaly, TR, TC and VHPT can use flexible page size for each entry.
> Thus normal linux kernel uses a TR entry for kernel virtual space. So, in HVM
> domain on IPF, it is difficult to change a part of P2M map of kernel virtual
> space without MM modification.

What's a TR? Assuming some sort of virtual->physical translation record, you
couldn't have simple single mapping for the entire kernel va space because
it won't map onto a contiguous block of physical addresses? There must be
something doing translation from the guest's view of fake contiguous
physical memory to underlying real scattered pages -- whatever structure
that is is the one that gets modified by that memory_op.

 -- Keir



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