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.
Thanks,
- Tsunehisa Doi
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home