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


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

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: [Xen-ia64-devel] Re: [Xen-devel] Porting PV-on-HVM for ia64 platform
From: Doi.Tsunehisa@xxxxxxxxxxxxxx
Date: Mon, 28 Aug 2006 18:48:52 +0900
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 28 Aug 2006 02:49:13 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: Your message of Sun, 27 Aug 2006 15:51:29 +0100. <C1177001.1682%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C1177001.1682%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
You (Keir.Fraser) said:
> 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.

  Sorry, I had misunderstood the TR/TC emulation for VT-i domain.

  I thought that one virtual TR/TC entry was emulated with one physical
TC entry, and whole kernel virtual space used only one physical TC entry.
Thus, a part of pages in kenrnel virtual space could not remapping to
the other memory page, I thought.

  Today, I discussed with my co-worker about this feature. So, one
virtual TR/TC is emulated with some physical VHPT entry per Xen pagesize.
Thus, we should be able to implement with same method of x86 code.

  Currently, we are trying to modify PV-on-HVM feature for IPF with
the same method of x86 code. And in preliminary implement, we could do
the feature.

- Tsunehisa Doi

Xen-ia64-devel mailing list