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