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

Re: [PATCH 2/2] x86/shadow: mark more of sh_page_fault() HVM-only


  • To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • Date: Fri, 20 Jan 2023 15:24:02 +0000
  • Accept-language: en-GB, en-US
  • 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9FyDFegZWA77cL2zFRx/jQPKAl4s+UblQw0qsBskao8=; b=Xthi5kkZYx8xdZJCitj9X1yuO/ufB1xvg6K/KshhRBMuRyWQR/JhCF9qIaEnXftEG0A6a7Z6WpluZ0keEis2Y4ihYzktxTXCt4AQH/URRd/CEinTOf8us+7P42heOyqBBB4t/t1cWBytFCGgVqeXDPbSL9izvGeI5e4PwUxeDmK2dnCooP1FpoVs1WFl7wSdV+QMXYbOQTr5Xlhkh8YI/pFxF6b+IbYBR3nG4xZAXhvW7Jskp7gTht09yQXQFFW+NBpsbwBivp78oj1s61c5EPkKeQrsKXD2dFB3uFHV5mG4ioty9Z3XR4TZQd3NkMHqZlRkLOWEIKupI9FoluTMLQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dXu7E7B6Ausmz46JFhlxQocqteXDRAMYnsNJ4VRCWoJANOdKBWhyvEPrO0Dl2FNE+JKQgr1z5cINoDiEtAmc0Fj6k9oDsMrG0ZCoOaLjL+88jA2+nDOC6/M+6WxFTXZw1vNWHHl6cSGaW9c0+/lrh10wn4Xw8HiuCYg17RNVBRMfNjid7e8t5l2x9ThkIudMVmqhDP54Vrg/3Op9ibcvY30dfccy36iYgqSmZhXmx7QBvPCTE4ZlnfpuNRfwaTqk0UZJ5w73DDaVXVJhtbWox6ztGZjXaV4fRpumwABCtJoPLJ10X1FTiQ9VZfa3ndtmgoYJG/GdJ8TTdURzmjmk8w==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, "Tim (Xen.org)" <tim@xxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxx>
  • Delivery-date: Fri, 20 Jan 2023 15:24:40 +0000
  • Ironport-data: A9a23:95RdlK9nGsJG2vL4rVNiDrUDsH+TJUtcMsCJ2f8bNWPcYEJGY0x3n zMaDzyCP6uJYjOhfdp0Ody+o09QvsDTm9IyQAA/q308E34SpcT7XtnIdU2Y0wF+jCHgZBk+s 5hBMImowOQcFCK0SsKFa+C5xZVE/fjUAOG6UKucYHsZqTZMEE8JkQhkl/MynrlmiN24BxLlk d7pqojUNUTNNwRcawr40Ire7kIw1BjOkGlA5AdmPKoT5AW2e0Q9V/rzG4ngdxMUfaEMdgKKb 76r5K20+Grf4yAsBruN+losWhRXKlJ6FVHmZkt+A8BOsDAbzsAB+v9T2M4nQVVWk120c+VZk 72hg3ASpTABZcUgkMxFO/VR/roX0aduoNcrKlDn2SCfItGvn9IBDJyCAWlvVbD09NqbDklFr +MYKxowaCm4rMSHn7ypU8dLj5Q8eZyD0IM34hmMzBn/JNN/GdXmfP+P4tVVmjAtmspJAPDSI dIDbiZiZwjBZBsJPUoLDJU5n6GjgXyXnz9w8QrJ4/ZopTWOilUpjNABM/KMEjCObexTklyVu STt+GPhDwtBHNee1SCE4jSngeqncSbTCdlPTOTjpqACbFu7y1UROEAnDHCHut7mrG2iWMoOL k49w397xUQ13AnxJjXnZDW6qnOZuh8XW/JLDvY3rgqKz8L88wufQ2QJUDNFQNgnr9MtAywn0 EeTmNHkDiApt6eaIVqC8p+EoDX0PjIaRUceZCosXQYDpd75r+kOYgnnS99iFOuwkYfzEDSpm zSS9nFm2/MUkNIB0Li98RbfmTWwq5PVTwkzoALKQmai6QA/b4mgD2C11WXmAT97BN7xZjG8U LIswZb2ADwmZX1VqBGwfQ==
  • Ironport-hdrordr: A9a23:Rucbw6z6wP4nb5NACKIqKrPwBL1zdoMgy1knxilNoH1uHfBw8v rEoB11726StN98YhAdcKm7Scy9qBDnm6Kdn7NhWYtKBzOW21dARbsKheGOrwEIcBefygcy79 YZT0FWMqyTMXFKyer8/QmkA5IB7bC8gduVbD7lvhFQpNdRGthd0zs=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHZLAix9A0R4pcRYE+MObCQxsOEfa6nbmCA
  • Thread-topic: [PATCH 2/2] x86/shadow: mark more of sh_page_fault() HVM-only

On 19/01/2023 1:19 pm, Jan Beulich wrote:
> Neither p2m_mmio_dm nor the types p2m_is_readonly() checks for are
> applicable to PV; specifically get_gfn() won't ever return such a type
> for PV domains. Adjacent to those checks is yet another is_hvm_...()
> one. With that block made conditional, another conditional block near
> the end of the function can be widened.

Why?  I presume you're referring to the emulate_readonly label?

Could I request "with that block made condition, the emulate_readonly
label becomes conditional too."

"widened" is actually widened in both direction, AFAICT. to include both
the emulate_readonly and mmio labels.

But looking at the code, I think we mean emulated mmio only, because it
comes from p2m_mmio_dm only ?

>
> Furthermore the shadow_mode_refcounts() check immediately ahead of the
> aforementioned newly inserted #ifdef

This would be far easier to follow if you said the emulate label.

>  renders redundant two subsequent
> is_hvm_domain() checks (the latter of which was already redundant with
> the former).
>
> Also guest_mode() checks are pointless when we already know we're
> dealing with a HVM domain.
>
> Finally style-adjust a comment which otherwise would be fully visible as
> patch context anyway.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

So I think this is all ok, but honestly it would be far easier to review
if it was split into two patches - first the #ifdef rearranging, and the
cleanup second.

> ---
> I'm not convinced of the usefulness of the ASSERT() immediately after
> the "mmio" label. Additionally I think the code there would better move
> to the single place where we presently have "goto mmio", bringing things
> more in line with the other handle_mmio_with_translation() invocation
> site.

That would remove the poorly named label, and make it clearly emulated
mmio only.  So 3 patches with this movement as the first one?

~Andrew

 


Rackspace

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