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] [RFC] grant table API clean up and performancetunin

To: "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] [RFC] grant table API clean up and performancetuning memo
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Tue, 28 Mar 2006 19:46:13 +0800
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 28 Mar 2006 11:47:39 +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: AcZSTPurTqRUeyEPSty5TAAgjVx9rwADcn7A
Thread-topic: [Xen-ia64-devel] [RFC] grant table API clean up and performancetuning memo
>From: Isaku Yamahata [mailto:yamahata@xxxxxxxxxxxxx]
>Sent: 2006年3月28日 17:50
>
>Hi Kevin. Thanks for your comment.
>Please note that I listed these ideas for discussion.
>I don't necessary have concreate implementation idea about them.
>Some might be good, some might be bad.

Definitely. Discussion makes things clear. :-)

>>
>> Since frame within grant table entry is gmfn and xen is aware whether this 
>> gmfn
>> equals to mfn or not, there's no need to change concept of host_addr and you 
>> can
>> just deliver a dummy va address.
>
>I agree. I had a vague similar model in my mind
>You made it very clear.
>I guess that grant table on translate x86 isn't supported yet, right?

The grant table exists on current translate x86. From virtual driver code, 
there're places checking against translated mode. I'm not sure about dom0, 
but for domU, the grant table gpfns are kept adjacent to console gpfn by 
control panel. 

I sent out a question about current status of translated mode on xen-devel 
and you may follow up with further questions.

>
>> How about record read-only property in the p2m table of that domain? Later 
>> when
>> inserting entry into VHPT table and mTLB, p2m entry can be checked to set
>read-only
>> flag.
>
>I meant the P2M table by
>'Xen/IA64 software address translation page table'
>so that you and I reached the same conclusion.

Yes, and sorry for misunderstanding here.

>
>> >- trust privileged domains
>> >  Xen/IA64 trust privileged domain(dom0) to flush tlb cache.
>>
>> What do you mean by "trust"? Purge instruction still traps to xen since 
>> xenlinux is
>> running as less privilege level. Maybe I didn't understand your point here.
>
>When a granted page is unmapped or a page is disassociated
>from pseudo physical address, xen/IA64 must flush tlb/VHPT.
>Otherwise it might be possible for a malicious domain to read/write
>the page using unflushed virtual address after the page is recyecled
>and used for other purpose.
>If we assume that dom0 isn't malicious so that it issues
>appropriate tlb flush after unmapping/disassociating and doesn't read/write
>a unmapped/disassociated page, then we can skip tlb/VHPT flush in xen/IA64
>when unmapping/disassociating.

I'm not sure whether we can really gain even by trusting dom0. Aside from 
more context switches added (since flush request starts from dom0), you 
still need to flush tlb/VHPT on all LPs that dom0 is running on. It's natural 
to say that dom0 has one vcpu on each LP (current x86 guest SMP model), 
and in that case, once xen receives flush request from dom0, tlb/VHPT flush 
is required on all LPs for specified range... Is there any more difference 
except 
flush time? :-)

Thanks,
Kevin

>
>This is a trade-off between performance and security so this
>should be the last one which is evaluated.
>

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