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

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

>From: Magenheimer, Dan (HP Labs Fort Collins)
>[mailto:dan.magenheimer@xxxxxx]
>
>Hmmm... Kevin, you may be right.  My memory is dim on this
>(as it was >15 months ago), but at some point an fc instruction
>in linux did cause an unexpected trap.  This was back when
>I was still working with a privified kernel, probably older
>than 2.6.9.  IIRC, the problem occurred during one of the
>patches in linux/arch/ia64/kernel/patch.c.

I have to say... you're right. Xenlinux will patch gate page (epc) at boot 
time, and fc is issued at that time. So we may just keep current logic 
without any modification:
        - Code to handle fc virtualization for that special case is there
        - Other cases like fc in flush.S doesn't need virtualization and 
performance is not affected

Thanks,
Kevin

>
>It's possible that this was due to a bug, or it may have
>been dealing with an epc page.
>
>Dan
>
>> -----Original Message-----
>> From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx]
>> Sent: Monday, March 27, 2006 9:16 AM
>> To: Tristan Gingold; Magenheimer, Dan (HP Labs Fort Collins);
>> xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: RE: [Xen-ia64-devel] flush.S not para-virtualized
>>
>> >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