[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
> 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: > >> >> 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. > >> > > > > 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. Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |