diff mbox

[RFC,09/14] xen: vmx: Introduce a Hyper call to set subpage

Message ID 2a15e2d69dcc0528341a487ef58f11dde18d8a2c.1508397860.git.yi.z.zhang@linux.intel.com (mailing list archive)
State New, archived
Headers show

Commit Message

Zhang, Yi Oct. 19, 2017, 8:13 a.m. UTC 
From: Zhang Yi Z <yi.z.zhang@linux.intel.com>

The Hypercall is defined as HVMOP_set_subpage

And the Interface's parameters is defined as

struct xen_hvm_subpage {
    domid_t  domid;
    uint32_t access_map;
    uint64_t gfn;
}

The user application: xl, or some other security control daemon. will
set the protection bitmap via this hyper call.

Signed-off-by: Zhang Yi Z <yi.z.zhang@linux.intel.com>
---
 xen/arch/x86/hvm/hvm.c          | 8 ++++++++
 xen/include/public/hvm/hvm_op.h | 9 +++++++++
 2 files changed, 17 insertions(+)

Comments

Tamas K Lengyel Oct. 19, 2017, 6:34 p.m. UTC | #1 
On Thu, Oct 19, 2017 at 2:13 AM, Zhang Yi <yi.z.zhang@linux.intel.com> wrote:
> From: Zhang Yi Z <yi.z.zhang@linux.intel.com>
>
> The Hypercall is defined as HVMOP_set_subpage

Are there any expected use-cases where a HVM guest would need access
to this hypercall? Is spp compatible with #VE? If not, I think it
would be better to integrate this with the existing xen_mem_access_op.
Zhang, Yi Oct. 20, 2017, 8:41 a.m. UTC | #2 
On 2017-10-19 at 12:34:07 -0600, Tamas K Lengyel wrote:
> On Thu, Oct 19, 2017 at 2:13 AM, Zhang Yi <yi.z.zhang@linux.intel.com> wrote:
> > From: Zhang Yi Z <yi.z.zhang@linux.intel.com>
> >
> > The Hypercall is defined as HVMOP_set_subpage
> 
> Are there any expected use-cases where a HVM guest would need access
> to this hypercall? Is spp compatible with #VE? If not, I think it
> would be better to integrate this with the existing xen_mem_access_op.

That a good point Tamas, I'm considering to use this hypercall from a
HVM guest, then it would be simple and useful if a HVM guest can control
it by itself, there already somebody are investigating on it. So let us
wait a while for this hypercall.
diff mbox

Patch

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 0b1aba7..54cd916 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4694,6 +4694,14 @@  long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
         rc = do_altp2m_op(arg);
         break;
 
+    case HVMOP_set_subpage: {
+        xen_hvm_subpage_t subpage;
+
+        if ( copy_from_guest(&subpage, arg, 1 ) )
+            return -EFAULT;
+        break;
+    }
+
     default:
     {
         gdprintk(XENLOG_DEBUG, "Bad HVM op %ld.\n", op);
diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
index 0bdafdf..0fa5b88 100644
--- a/xen/include/public/hvm/hvm_op.h
+++ b/xen/include/public/hvm/hvm_op.h
@@ -205,6 +205,15 @@  struct xen_hvm_altp2m_domain_state {
 };
 typedef struct xen_hvm_altp2m_domain_state xen_hvm_altp2m_domain_state_t;
 DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_domain_state_t);
+#define HVMOP_set_subpage          26
+struct xen_hvm_subpage {
+    domid_t  domid;
+    uint32_t access_map;
+    uint64_t gfn;
+};
+typedef struct xen_hvm_subpage xen_hvm_subpage_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_subpage_t);
+
 
 struct xen_hvm_altp2m_vcpu_enable_notify {
     uint32_t vcpu_id;