[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.