Re: [Xen-devel] [PATCH v6 2/4] x86/hvm: Treat non-instruction fetch nested page faults also as read violations

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Friday, August 15, 2014 2:24 PM
> 
> >>> On 15.08.14 at 22:17, <kevin.tian@xxxxxxxxx> wrote:
> > Though I understand the merit of your overall patch, the discussion
> > around r/w violations are not directly related to the optimization
> > your patch brings (the real reason is from available GLA info at
> > VM-exit). It' just because you code the patch that way, so
> > __hvmemul_read purely assumes NPFEC_read_access if not is
> > NPFEC_insn_fetch, and then read-modify-write can't enter the
> > fast path w/o faking read.
> 
> That's right, yes.
> 
> > If my understanding is correct, why not just do whatever tricks
> > here in nestedhvm_hap_nested_page_fault, while keeping arch
> > specific code unchanged?
> 
> Because the net effect is the same, and because getting is into
> final shape right away rather than having two layers fiddling with
> it seems cleaner? 

I still think another way cleaner since you can enforce whatever
policy in a centralized place, and it's more flexible if there does
have some usages relying on the raw hardware reported violations
(say statistics of r/w violations... though either way is inaccurate
but my gut-feeling is the # of pure writes is much higher than # of
read-modify-writes, so treating all writes as reads just cause more
bias)

> Counter question: Why can't the hardware
> report true characteristics right away?
> 

when spec says so, there is a reason but I can't tell here. :-)


Thanks
Kevin

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