[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [PATCH v19 for-4.14 01/13] x86/mem_sharing: block interrupt injection for forks


  • To: "Lengyel, Tamas" <tamas.lengyel@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Tue, 9 Jun 2020 23:53:11 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Idu8MoGDiheqPhqpXQ5cBxu78CtPxyFHMKB4nyBFHuA=; b=JWzdl5JUTgorhFy91x1GWtGEGVGG8PBolzf95/abjbePYX757qCI0ooAcIv6ItUXVVqxK0Pycks/9r0lEaVureo8B31xXvNxZvpO9UWAw4bXu5ocPMSUPUpb36sn9CgTZ5BMg9agp5c49AtXe+Rw7okxEmycT4HNVIjxn7lSZ33ioVtULn3pR+Tp+BOlTrcBt9On/1qJfyzGHFMD+weeom09YGBBwyyaiB+BUcKzNidVTZ1Iw+U7tQ3ymXhAnqZwzEQzsgNO9kJ0ydaJzLGhf4Qxpo/DXv+6sCt76pHqsusX/ZG7NfMWIA+WpeoheeUp7YLOOvjnRTYve40tuFPxDg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Mg8eTHDps640Q1dfC+N2TgQKbuiFaorcABOBHCEKBbDEyKp1IsoBnzk+ien/nbGhXN7kAAIvvxhngPZiT1GORw1eEOjcUFNpYDHQeAAcOyUMkKlGEEdjWnShdLmzjCLc8mDltKyDMo+HKtMhQ6xsL6YyoUPX113Ef+KPnDlIOX/NlQa2hkvXA6kkn6TEcmbY8/8JCNUrQqrHXwblkY/HVVg1aBP/syiFnSxVqOa+rJZGXtfuOhHHYd5H6Le4NLS4xLD7eLQH//wdKdh7h7iMANh2oIj+3FRdqqMeWFcMGFUWXOuJytqdBGewf3l9X0MKBWqGK8l81SMfYPQS9uEP0A==
  • Authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=intel.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Tamas K Lengyel <tamas@xxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Tue, 09 Jun 2020 23:53:24 +0000
  • Dlp-product: dlpe-windows
  • Dlp-reaction: no-action
  • Dlp-version: 11.2.0.6
  • Ironport-sdr: BcHilgKA5Uhn85YuR4C9YpzHmsoIFlAvK/LyJu5E2qESxT0zyDS1fwfGgIWoatufkogmkXAX14 qSA3pW+MY1LA==
  • Ironport-sdr: AYOQbkY+EpXjge3byPdsUher9dE5q+vgpvJmG+7Q91/JKgSSNbvAHs2DcC/nJBxWTcRGSD0IAg 61k47Suxfp0Q==
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHWOBerUwuHg20nGUicDfuX+ypR+ajQ/TJwgAADv5A=
  • Thread-topic: [PATCH v19 for-4.14 01/13] x86/mem_sharing: block interrupt injection for forks

> From: Tian, Kevin
> Sent: Wednesday, June 10, 2020 7:44 AM
> 
> > From: Lengyel, Tamas <tamas.lengyel@xxxxxxxxx>
> > Sent: Monday, June 1, 2020 9:22 PM
> >
> > When running VM forks without device models (QEMU), it may
> > be undesirable for Xen to inject interrupts. When creating such forks from
> > Windows VMs we have observed the kernel trying to process interrupts
> > immediately after the fork is executed. However without QEMU running
> such
> > interrupt handling may not be possible because it may attempt to interact
> > with
> > devices that are not emulated by a backend. In the best case scenario such
> 
> I asked this question before. the interrupts could come from Xen itself, e.g.
> due to timer virtualization. So I didn't get why it's desired to block all
> interrupts
> just because no QEMU is running. Also it's weird why Windows VMs are
> observed to process interrupts that are generated by QEMU when no such
> backend emulation exists at all. It sounds like a workaround instead of a real
> fix...

ok, I rechecked your reply. Looks it's about the case that parent VM has QEMU
and pending interrupts while you fork it into child VMs without QEMU so those
pending interrupts become problematic.

Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>

> 
> 
> > interrupt handling would only present a detour in the VM forks' execution
> > flow, but in the worst case as we actually observed can completely stall it.
> > By disabling interrupt injection a fuzzer can exercise the target code
> without
> > interference. For other use-cases this option probably doesn't make sense,
> > that's why this is not enabled by default.
> >
> > Forks & memory sharing are only available on Intel CPUs so this only
> applies
> > to vmx. Note that this is part of the experimental VM forking feature that's
> > completely disabled by default and can only be enabled by using
> > XEN_CONFIG_EXPERT during compile time.
> >
> > Signed-off-by: Tamas K Lengyel <tamas.lengyel@xxxxxxxxx>
> > Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> > ---
> >  xen/arch/x86/hvm/vmx/intr.c      | 6 ++++++
> >  xen/arch/x86/mm/mem_sharing.c    | 6 +++++-
> >  xen/include/asm-x86/hvm/domain.h | 2 +-
> >  xen/include/public/memory.h      | 3 +++
> >  4 files changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
> > index 000e14af49..80bfbb4787 100644
> > --- a/xen/arch/x86/hvm/vmx/intr.c
> > +++ b/xen/arch/x86/hvm/vmx/intr.c
> > @@ -256,6 +256,12 @@ void vmx_intr_assist(void)
> >      if ( unlikely(v->arch.vm_event) && v->arch.vm_event->sync_event )
> >          return;
> >
> > +#ifdef CONFIG_MEM_SHARING
> > +    /* Block event injection for VM fork if requested */
> > +    if ( unlikely(v->domain->arch.hvm.mem_sharing.block_interrupts) )
> > +        return;
> > +#endif
> > +
> >      /* Crank the handle on interrupt state. */
> >      pt_vector = pt_update_irq(v);
> >
> > diff --git a/xen/arch/x86/mm/mem_sharing.c
> > b/xen/arch/x86/mm/mem_sharing.c
> > index 19922ab5d1..c428fd16ce 100644
> > --- a/xen/arch/x86/mm/mem_sharing.c
> > +++ b/xen/arch/x86/mm/mem_sharing.c
> > @@ -2106,7 +2106,8 @@ int
> >
> mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op
> > _t) arg)
> >          rc = -EINVAL;
> >          if ( mso.u.fork.pad )
> >              goto out;
> > -        if ( mso.u.fork.flags & ~XENMEM_FORK_WITH_IOMMU_ALLOWED )
> > +        if ( mso.u.fork.flags &
> > +             ~(XENMEM_FORK_WITH_IOMMU_ALLOWED |
> > XENMEM_FORK_BLOCK_INTERRUPTS) )
> >              goto out;
> >
> >          rc = rcu_lock_live_remote_domain_by_id(mso.u.fork.parent_domain,
> > @@ -2134,6 +2135,9 @@ int
> >
> mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op
> > _t) arg)
> >              rc = hypercall_create_continuation(__HYPERVISOR_memory_op,
> >                                                 "lh", XENMEM_sharing_op,
> >                                                 arg);
> > +        else if ( !rc && (mso.u.fork.flags &
> > XENMEM_FORK_BLOCK_INTERRUPTS) )
> > +            d->arch.hvm.mem_sharing.block_interrupts = true;
> > +
> >          rcu_unlock_domain(pd);
> >          break;
> >      }
> > diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-
> > x86/hvm/domain.h
> > index 95fe18cddc..9d247baf4d 100644
> > --- a/xen/include/asm-x86/hvm/domain.h
> > +++ b/xen/include/asm-x86/hvm/domain.h
> > @@ -67,7 +67,7 @@ struct hvm_ioreq_server {
> >  #ifdef CONFIG_MEM_SHARING
> >  struct mem_sharing_domain
> >  {
> > -    bool enabled;
> > +    bool enabled, block_interrupts;
> >
> >      /*
> >       * When releasing shared gfn's in a preemptible manner, recall where
> > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> > index dbd35305df..850bd72c52 100644
> > --- a/xen/include/public/memory.h
> > +++ b/xen/include/public/memory.h
> > @@ -536,7 +536,10 @@ struct xen_mem_sharing_op {
> >          } debug;
> >          struct mem_sharing_op_fork {      /* OP_FORK */
> >              domid_t parent_domain;        /* IN: parent's domain id */
> > +/* Only makes sense for short-lived forks */
> >  #define XENMEM_FORK_WITH_IOMMU_ALLOWED (1u << 0)
> > +/* Only makes sense for short-lived forks */
> > +#define XENMEM_FORK_BLOCK_INTERRUPTS   (1u << 1)
> >              uint16_t flags;               /* IN: optional settings */
> >              uint32_t pad;                 /* Must be set to 0 */
> >          } fork;
> > --
> > 2.25.1


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.