RE: [Xen-ia64-devel] flush.S not para-virtualized

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Tristan Gingold [mailto:Tristan.Gingold@xxxxxxxx]
>Sent: 2006年3月27日 23:52
>
>Le Lundi 27 Mars 2006 17:24, Magenheimer, Dan (HP Labs Fort Collins)
>a écrit :
>> Agreed, this needs to be paravirtualized.
>So, everybody agree.
>I will add a fc.i hyperprivop.
>
>However, I fear the hyperprivop-ized version of flush.S would be very
>slow.
>Should we also create an hyperprivop for something like
>flush_icache_range ?
>
>Tristan.

Normally more thinking brings more questions. :-) SDM says:

When executed at privilege level 0, fc and fc.i perform no access rights or 
protection key checks. At other privilege levels, fc and fc.i perform access 
rights checks as if they were 1-byte reads, but do not perform any 
protection key checks (regardless of PSR.pk).

Easy to see hint here to protect memory pages of higher region can't be 
affected by lower privilege level, or else the performance may be affected 
a lot by malicious programs. Then let's see which cases 1-byte reads 
can't pass access rights checks in current environment:

First we have TLB.pl == 2, and xenlinux kernel also executes at cpl==2. In 
all 8 types of access rights, 0-6 all support read at same privilege level 
with only exception as type 7 (execute,promote/read,execute). However 
that page is special to contain 'epc' instruction. Content on that page is 
normally fixed and stable, and it's difficult to find good reason to flush 
cache entry for that page.

If it's true with only one weak exception, is it really worthy of virtualizing 
fc.i? :-)

Thanks,
Kevin

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