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 01:20, <kevin.tian@xxxxxxxxx> wrote:
>>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Thursday, August 14, 2014 4:08 PM
>> 
>> >>> On 15.08.14 at 01:04, <kevin.tian@xxxxxxxxx> wrote:
>> >>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> >> Sent: Thursday, August 14, 2014 4:00 PM
>> >>
>> >> >>> On 15.08.14 at 00:34, <kevin.tian@xxxxxxxxx> wrote:
>> >> > 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.
>> >>
>> >
>> > but then you are mistakenly treating all other writes as reads too...
>> 
>> Right, but as said - that's the more safe of the two alternatives.
>> 
> 
> to decide which one is more 'safe', could you give some examples of
> how read violation is used today? If there's an usage very relying on 
> the exact read behavior, treating 'w' as 'r' could lead to significant
> difference. 

The intended use is that pending patch I referred to, aiming at
reducing the number of GLA->GPA translations we're doing during
instruction emulation, which makes a severe difference to many-
vCPU guests e.g. heavily using the HPET from all their vCPU-s.

Jan


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