|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 08/15] x86/altp2m: add control of suppress_ve.
>>> On 10.07.15 at 02:52, <edmund.h.white@xxxxxxxxx> wrote:
> @@ -1528,16 +1528,17 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned
> long gla,
> vm_event_request_t *req;
> int rc;
> unsigned long eip = guest_cpu_user_regs()->eip;
> + bool_t sve;
>
> /* First, handle rx2rw conversion automatically.
> * These calls to p2m->set_entry() must succeed: we have the gfn
> * locked and just did a successful get_entry(). */
> gfn_lock(p2m, gfn, 0);
> - mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, 0, NULL);
> + mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, 0, NULL, &sve);
>
> if ( npfec.write_access && p2ma == p2m_access_rx2rw )
> {
> - rc = p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt,
> p2m_access_rw);
> + rc = p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt,
> p2m_access_rw, sve);
> ASSERT(rc == 0);
> gfn_unlock(p2m, gfn, 0);
> return 1;
> @@ -1546,7 +1547,7 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long
> gla,
> {
> ASSERT(npfec.write_access || npfec.read_access || npfec.insn_fetch);
> rc = p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
> - p2mt, p2m_access_rwx);
> + p2mt, p2m_access_rwx, -1);
So why -1 here ...
> @@ -1566,14 +1567,14 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned
> long gla,
> else
> {
> gfn_lock(p2m, gfn, 0);
> - mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, 0, NULL);
> + mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, 0, NULL, &sve);
> if ( p2ma != p2m_access_n2rwx )
> {
> /* A listener is not required, so clear the access
> * restrictions. This set must succeed: we have the
> * gfn locked and just did a successful get_entry(). */
> rc = p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
> - p2mt, p2m_access_rwx);
> + p2mt, p2m_access_rwx, sve);
... but sve here, when -1 means "retain current setting" anyway?
(Same question applies elsewhere.)
While I'd preferable see this simplified, either way
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |