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 00:34, <kevin.tian@xxxxxxxxx> wrote:
>>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Thursday, August 14, 2014 1:40 PM
>> 
>> >>> On 14.08.14 at 18:49, <andrew.cooper3@xxxxxxxxxx> 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.

Jan


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