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

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 08/14/2014 06:59 PM, Jan Beulich wrote:
>>>> On 15.08.14 at 00:34, <kevin.tian@intel.com> wrote:
>>>   From: Jan Beulich [mailto:JBeulich@suse.com]
>>> Sent: Thursday, August 14, 2014 1:40 PM
>>>
>>>>>> On 14.08.14 at 18:49, <andrew.cooper3@citrix.com> wrote:
>>>> On 14/08/14 17:43, Tian, Kevin wrote:
>>>>> but doing so just moves from one incomplete solution (where
>>>>> read-modify-write is not treated as read-violation) to another
>>>>> incomplete solution (where all writes are treated read-violation). If
>>>>> there's actual usage relying on accurate read-violation information,
>>>>> either solution doesn't work. So I don't see the value of this change.
>>>>>
>>>> I would agree.  Anything using this information will have to have
>>>> detailed knowledge of what the hardware is capable of reporting, to
>>>> understand the information it has to hand.
>>>>
>>>> I think Xen should faithfully pass on what hardware reports.  It will be
>>>> more useful to the consumer than blurring the details like this.
>>> Not if it's unreliable. Plus on x86 elsewhere write access implies
>>> read access anyway. If you look at the draft patch I had sent
>>> Tamas (which I intend to rebase on his series), you'll see that
>>> there the change here is actually strictly needed.
>>>
>> I think you're mixing the behavior and policy here. from behavior p.o.v,
>> we should keep whatever hardware reports, which describes the behavior
>> of the instruction causing violation whether it's a write operation or read
>> operation. From policy p.o.v, you may treat a write operation as read
>> operation in specific code paths (if access==read || access ==write).
> 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.

If, OTOH, you need both return same results for consistency then I 
wonder whether we could move this up the stack into HVM common code.

-boris