[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> 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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.