[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



On 08/14/2014 06:59 PM, Jan Beulich wrote:
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.

Is this specific to VMX or does SVM have the same problem (I am not aware of this but I might be wrong). Because if it doesn't then I think Tamas' [PATCH v6 2/4] should have SVM report actual bits.

If, OTOH, you need both return same results for consistency then I wonder whether we could move this up the stack into HVM common code.

-boris


_______________________________________________
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®.