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

Re: [for-4.15][PATCH v2 1/5] xen/x86: p2m: Don't map the special pages in the IOMMU page-tables

  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Wed, 10 Feb 2021 16:24:55 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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=EjsImBlz3+FL/q/Zd8u4pOch7FZ1qhKtrHNIEJ8Lqpc=; b=d9Fkj6wXYLXlNfaBCFVNRK3aCv8feOTQ9+fxhRyHp+y04GmSYnpCMPakXkoIfFNCyywG10EvXuXAt904j9K77djI4PA1dPM96bPuYTzDysxgMFzzFl2DAIKR0y6hLnZahYlMx+Amk/ikB3HZJr+QR/4yJcBJix73+ZSLOQrUzQ2P+52TKGYGfKWtf58bMeiJNN0PUhwTHysGt0bBDTiqecrKuK309qrLPcUD+CwP3IY1siTxWHLLVcW2T0btjD0pX1/9fnFGri5xTTj0mz9XloKHFjdQFoNYbvslqkQkgCyLK/511rgJ+rO24xAC3CbbEw+uWyOx5nctXmyEZduJ1g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Da3/gl/EjEgfBO0l0dAFkEfVX0hD4jCFe8dGZlrFweunE4qxcc+7WTge6yIjplx9ai9rUK51L+2amm9ewgLFRDqc575SnrH1KSUej2fDhm8K+EsTV8TY/ervyD0s2YOjxMmIQCMh51WqulYlm9KMREfEZ/loW9RY1iEfANOHp6MWrf96lzY9EHrrBtxCBJ8fH1Ccy4ApddCSc2l8AS9tqsxmlLYJPbGiRspSfFyxDY7bDzE0QXWLO+LT0tyUjdGBYryerwna4puMAVN6nsNx1++0w60tXALKwvcT8B4x4UMlsNySNd8GH2RLZYdqHynvVG2ZB4aScjXaEMSTZ8VqJw==
  • Authentication-results: esa2.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: <xen-devel@xxxxxxxxxxxxxxxxxxxx>, <hongyxia@xxxxxxxxxxxx>, <iwj@xxxxxxxxxxxxxx>, Julien Grall <jgrall@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Julien Grall <julien@xxxxxxx>
  • Delivery-date: Wed, 10 Feb 2021 15:25:27 +0000
  • Ironport-sdr: uhOn8mhcw0iueE0B+S3PwMfm3OQBkD8PBFRNGpOsbVdGqE3uQOMtG8xN1kLHS8NPl4urV36CFO DtqmoH2Pkpi5phorW7tAyuek240meIId2zLIlxOPq8xjpJt1gcrf3ooY7JiNM3yZOF2SHVXzPZ FjxgIvlYa1tBmYfCYt12dQC7gUHF9Aa425ZwE9iStI+irIncnWvXQwxF2P3MsEqpP9L+LLyrQO 9TbLzltIo8oPyJmEmUgt+7y7oIUjhDAAUqENz83/AJvxbbx3aAFT16ryU2bhfJA91/ggai+Lmo SeQ=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Wed, Feb 10, 2021 at 02:12:38PM +0100, Jan Beulich wrote:
> On 10.02.2021 12:54, Roger Pau Monné wrote:
> > On Wed, Feb 10, 2021 at 11:48:40AM +0000, Julien Grall wrote:
> >> It feels wrong to me to setup a per-domain mapping when initializing the
> >> first vCPU.
> >>
> >> But, I was under the impression that there is plan to remove
> >> XEN_DOMCTL_max_vcpus. So it would only buy just a bit of time...
> > 
> > I was also under that impression. We could setup the lapic access page
> > at vlapic_init for the BSP (which is part of XEN_DOMCTL_max_vcpus
> > ATM).
> > 
> > But then I think there should be some kind of check to prevent
> > populating either the CPU or the IOMMU page tables at domain creation
> > hypercall, and so the logic to free CPU table tables on failure could
> > be removed.
> I can spot paging_final_teardown() on an error path there, but I
> don't suppose that's what you mean? I guess I'm not looking in
> the right place (there are quite a few after all) ...

Well, I assume some freeing of the EPT page tables must happen on
error paths, or else we would be leaking them like IOMMU tables are
leaked currently?

Maybe I've not correctly understanding the issue here.




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