Re: [Xen-devel] [PATCH v6 2/4] x86/hvm: Treat non-instruction fetch nested page faults also as read violations

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.08.14 at 17:09, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 08/15/2014 11:01 AM, Jan Beulich wrote:
>>>>> On 15.08.14 at 16:31, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>> On 08/14/2014 06:59 PM, Jan Beulich wrote:
>>>> No - the hardware specifically does _not_ guarantee to report the
>>>> actual characteristics of a read-modify-write instruction. Or at least
>>>> that's what your documentation warns about. And to be on the safe
>>>> side, treating all writes as also being reads is the better option than
>>>> to mistakenly treat r-m-w as just w.
>>> Is this specific to VMX or does SVM have the same problem (I am not
>>> aware of this but I might be wrong). Because if it doesn't then I think
>>> Tamas' [PATCH v6 2/4] should have SVM report actual bits.
>> You as the SVM maintainer should know better than me... With
>> NPT using "normal" page fault error codes, there is not even an
>> indication for read access. Tamas's patches adjust the current
>> misbehavior too in that at least instruction fetches no longer get
>> reported as reads.
> 
> What I am asking is whether
> 
>     .read_access = !(pfec & (PFEC_insn_fetch | PFEC_write_access))
> 
> would be more appropriate.

Ah, no, clearly not: Again - read-modify-write instructions _have_
to be reported as being reads and writes. Reporting simply writes
as reads too is the smaller of the two "evils" here. If anything we
could introduce a "maybe-read" flag that gets set when don't know
for sure.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel