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

RE: [PATCH v3 20/23] VT-d: free all-empty page tables


  • To: "Beulich, Jan" <JBeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Fri, 18 Feb 2022 05:20:29 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=55WpNPG1YQ4oNB2e4F6gEqonZ7TVbRzDH6W+HYJNnmU=; b=mypLZWSnFg0w0+dBin2tAxsv8NdyCJluGUXC1FqXyceFPi6iWrpZ7P1knbf2/IzsmKnsYFdgeFiUTU2D+cdqPfKiMVW4/gMfA6RRi1gSAbs6xnKAlUACfT1maJhWL7edvz7thbNDtrg6hNrhzDYZ/j0r1ThkNSgdlcMlQvG37nFClyK7zMnpt2E6I9sNVxm0fjWBZuVS7hHVEL8I7Ia9nXbUmYqjXKBIPrZBTSa213341u4KrtWmHs6C9byT6GnlX9FJhGIcM5I5DDaC0EB5GepMkeiRVZ4tCM99KkWnIQLHj/j1oLjsbiDcvvmunOHdWP4qXVXzXVIcxOlmtsGlDg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eAQKMHG3rKsqIwsvSEeOe1Ti/OSPySwGY/l4jp53krRvQ5lL7oycnNJEzxdk7VPFvw7cv8Z4QrGmBlM8GsrhBVGqFmwhAXVIjkdJH5mur7iM2AM7kf8vZxZa/WQDygbPI8d4BlMaPvnkrUcuJkRTa+SjQG+Qj78Da3UwH6+TaLk4u+eI/qMQdC3uNEMCbOdrhwA5Rmp7wN9OAENqpS1mzOREVCKtqFS7MXf0/5pTUosZfEmuJI8kBtKts69l/7WhsLpL07uscLV/S/waXNTXSr72uc1MKN3w9m8htAANhpbPlEfDkRuEVEhrDxG/gBmBXDqcHm7TFGSPso5Npd/f9A==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com;
  • Cc: "Cooper, Andrew" <andrew.cooper3@xxxxxxxxxx>, Paul Durrant <paul@xxxxxxx>, Pau Monné, Roger <roger.pau@xxxxxxxxxx>
  • Delivery-date: Fri, 18 Feb 2022 05:20:44 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHYBkBAHcUqxDPFCEWIL9jRoPTFzayZAFJQ
  • Thread-topic: [PATCH v3 20/23] VT-d: free all-empty page tables

> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: Tuesday, January 11, 2022 12:36 AM
> 
> When a page table ends up with no present entries left, it can be
> replaced by a non-present entry at the next higher level. The page table
> itself can then be scheduled for freeing.
> 
> Note that while its output isn't used there yet,
> pt_update_contig_markers() right away needs to be called in all places
> where entries get updated, not just the one where entries get cleared.
> 
> Note further that while pt_update_contig_markers() updates perhaps
> several PTEs within the table, since these are changes to "avail" bits
> only I do not think that cache flushing would be needed afterwards. Such
> cache flushing (of entire pages, unless adding yet more logic to me more
> selective) would be quite noticable performance-wise (very prominent
> during Dom0 boot).
> 
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> v3: Properly bound loop. Re-base over changes earlier in the series.
> v2: New.
> ---
> The hang during boot on my Latitude E6410 (see the respective code
> comment) was pretty close after iommu_enable_translation(). No errors,
> no watchdog would kick in, just sometimes the first few pixel lines of
> the next log message's (XEN) prefix would have made it out to the screen
> (and there's no serial there). It's been a lot of experimenting until I
> figured the workaround (which I consider ugly, but halfway acceptable).
> I've been trying hard to make sure the workaround wouldn't be masking a
> real issue, yet I'm still wary of it possibly doing so ... My best guess
> at this point is that on these old IOMMUs the ignored bits 52...61
> aren't really ignored for present entries, but also aren't "reserved"
> enough to trigger faults. This guess is from having tried to set other

Is this machine able to capture any VT-d faults before? If yes maybe
you will observe more information if trying to tweak those bits at a later
time (instead of when iommu is enabled)?

Thanks
Kevin

 


Rackspace

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