On 4/19/2016 4:46 PM, Paul Durrant wrote:
-----Original Message-----
From: Tian, Kevin [mailto:kevin.t...@intel.com]
Sent: 19 April 2016 05:51
To: Yu, Zhang; Jan Beulich; Paul Durrant; Nakajima, Jun
Cc: Andrew Cooper; George Dunlap; Lv, Zhiyuan; xen-devel@lists.xen.org;
Keir (Xen.org); Tim (Xen.org)
Subject: RE: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to
map guest ram with p2m_ioreq_server to an ioreq server
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: Thursday, April 14, 2016 5:57 PM
And with all three bits now possibly being clear, aren't we risking the
entries to be mis-treated as not-present ones?
Hah. You got me. Thanks! :)
Now I realized it would be difficult if we wanna to emulate the read
operations for HVM. According to Intel mannual, entry->r is to be
cleared, so should entry->w if we do not want ept misconfig. And
with both read and write permissions being forbidden, entry->x can
be
set only on processors with EXECUTE_ONLY capability.
To avoid any entry to be mis-treated as not-present. We have several
solutions:
a> do not support the read emulation for now - we have no such
usage
case;
b> add the check of p2m_t against p2m_ioreq_server in
is_epte_present -
a bit weird to me.
Which one do you prefer? or any other suggestions?
That question would also need to be asked to others who had
suggested supporting both. I'd be fine with a, but I also don't view
b as too awkward.
According to Intel mannual, an entry is regarded as not present, if
bit0:2 is 0. So adding a p2m type check in is_epte_present() means we
will change its semantics, if this is acceptable(with no hurt to
hypervisor). I'd prefer option b>
Perhaps time for the VMX maintainers to chime in - such a change is
acceptable
only if it doesn't result in changed hardware behavior. I can't think of any
such off
the top of my head, but this really should be confirmed by the
maintainers before
deciding to go such a route.
Thanks, Jan. :)
Jun & Kevin, any suggestions?
I'm a bit worried about this change, since it's a fundamental EPT
interface. Can we avoid supporting read emulation now?
I'm happy to drop the implementation of read emulation for the moment to keep
things simple, as long as it is kept in the interface.
Thanks, Paul.
So what's the benefit to keep the read in the interface, if we can
not support its emulation?
It could be easier to change the is_epte_present definition than
to remove the read emulation code, but either way would not be
difficult.
Yu
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel