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

RE: [Xen-ia64-devel] RE: [Xen-ia64-full 68] Fwd: Topics to for Xen Summi

To: "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] RE: [Xen-ia64-full 68] Fwd: Topics to for Xen Summit discussion
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 12 Jan 2006 10:11:01 +0800
Cc: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>, Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>, jean-paul.pigache@xxxxxxxx, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 12 Jan 2006 02:18:01 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcYWi49D8M/AKCMPS76b/NDYnqeynAAjDtEg
Thread-topic: [Xen-ia64-devel] RE: [Xen-ia64-full 68] Fwd: Topics to for Xen Summit discussion
>From: Isaku Yamahata [mailto:yamahata@xxxxxxxxxxxxx]
>Sent: 2006年1月11日 16:45
>
>>
>> If we do this way, it's natural to let dom0 modify phys2mach table directly, 
>> right?
>
>By 'modify' do you mean that dom0 manages how to map
>phys2mach pages into the dom0 virtual address space, right?
>If so, xen must verify tlb related operations by dom0 to inhibit
>dom0 from writing to pte pages.

Let's hold until the summit, since Dan raised a good thread on list for 
discussion now. Taking Dan's terms here, my original suggestion is for P2M 
model where Xen constructs the phys2mach table within dom0's configured memory 
and dom0 can read/write that table/ptes completely together with notification 
to Xen for necessary case (Yes, it's current x86 model). Then xen doesn’t need 
inhibit dom0 from writing to pte pages.

If we go for VP model here like domU, dom0 even doesn't know phys2mach and thus 
xen also doesn't need inhibit. Dom0 just needs issue hypercall if actually want 
machine frame like DMA operation.

So the point is, once we export phys2mach to dom0, is it still necessary to 
make it read-only to dom0?

Another related question to think is, is it possible to eliminate direct write 
by dom0, if all modifications to phys2mach are accompanied with a set of 
hypercalls following? If true, we can encapsulate phys2mach change into 
hypercall implementations. For example, change phys2mach table within 
decrease_reservation instead of split for dom0 to write...

Thanks,
Kevin

>
>I think both proposals (yours and mine) may work well in functionality,
>I'm not sure which performs better.
>
>- Xen must verify dom0 tlb related operations to protect pte pages.
>  i.e. some checks must be added to vcpu_itr_d(), ...
>vs
>- Xen tlb miss handler check whether fault address is in the phys2mach
>  area and handles the fault specifically.
>  i.e. The tlb miss handler of xen/ia64 must be modified to handle
>  tlb misses in the phys2mach area.
>
>If I misunderstand, please correct.
>--
>yamahata

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