[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 1/2] x86: correct is_pv_domain() when !CONFIG_PV
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Thu, 15 Apr 2021 12:53:07 +0200
- 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=s+bnCOuqyrlT2GlTpm6EFhRjWFvQaeXnuOrSnm6KZGM=; b=GMmw8PQVW+QLFU4EcpN2fDRkAAqKXvMOMVxRkPc7nUHyfxcTGebilePQYM8HrZsGjdQmYDTdOg+vPnG6rW4soo+y3F78HaPvLLcPl5nPZ3KPH5Dqmm84NRUjMkqZgvOwsq+mIPAu62BYIL+vOA+TmfFk/7jqI59P4P+MrMymBpq/akjddfLR/WLKrax609j985AdRIxTXFgHapYQUAMSq61l9Z+31Bklo/m6aKwO0M7E7jksSTXgC2aYb5GOS9Il/fKJ7+UF2RtcIrHsABInTm+4th1B+CwOuPTdObw8rbLiRCSWULv2H8584+pZ/dWpLbn/8yqzVXIJBON+ytiGbw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cXOrejAbdRxOfQ+w8h/ZiGusRtukTzQV98v9hvGcCTFOoqUDlNYjmTJZ7xmMmEim+tNGEgUimgfVzEuNwHssJ2iAG+d1I8/qwOt0chfX318jjCp8dHhmjZbF+KoojLuHwlD6U7q3+y5bnlb4DOFlc1uKQB3Ub6z/TMJZCgGbiVGUpcezaF0NDApXe5ESFzAZvRSac1aK05R5zyJx2ZrBcVqYfB/N4k/AwfD6V/J3ehA+7QGhTHu1xdVJE6GjDGb8t1T/JW9XHjGMv0deP4K8xESrZo9pp+g8tFrFeq4JeR+lgK/RxH22d3ENL+GCL63RhaA98fVjySzq4mUDb2p9Nw==
- Authentication-results: esa2.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "Andrew Cooper" <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
- Delivery-date: Thu, 15 Apr 2021 10:53:23 +0000
- Ironport-hdrordr: A9a23:tSNGYqBzAFrwT97lHeg/tMeALOonbusQ8zAX/mhLY1h8btGYm8 eynP4SyB/zj3IrVGs9nM2bUZPvfVr1zrQwxYUKJ7+tUE3duGWuJJx/9oeK+VLdMgXE3Kpm2a 9kGpITNPTZEUV6gcHm4AOxDtYnx529/Lq1gPrFpk0McShBQchbnmFEIyycFVB7QxQDKJoiDZ yH5tdGoT3IQwVrUu2QAH4ZU+/f4+DajZ6OW299OzcLyimryQmp5rnzDgSC0n4lMg9n7L8+/Q H+4mnEz4q5tfXT8G6560by6NBslMLl2p9/AqW3+7QoAxHNrirtW4h7Qb2Fu1kO0ZGSwXInis PFrRtlH+kb0QKoQkiPrRHg2xbt3V8VgheIozLo4gqA0L7EbQk3BMZbiYVSfgGx0TtagPhG3L 9WxGXcjpJLDHr77VXAzuLVXBJnnFfcmwtarccviRVkIOwjQY4Uh4ke8ERJKYwHDSL35as2ed Mecv301bJ4d0iXYGveuXQq6NuwXm4rFhPDeUQavNeJugIm0ExR/g89/ogyj30A/JUyR91t4P nFCL1hkPVrQtUNZaxwKe8dSaKMeyPwaCOJFFjXDUXsFakBNX6IgYXw+q8J6Oajf4FN5Icumb zaOWko9VIaSgbLM4mjzZdL+hfCTCGWRjL20PxT4JB/p/nVWKfrCyueU1oj+vHQ4sk3M4n+Yb KeKZhWC/jsIS/FAoBSxTDzXJFUND0wS8sQltEnW0+fg87CJ4Hw39arMsr7Ff7IK3IJS2n/Cn wMUHzYP8Nb9H2mXXf+nVzwVhrWCwnC1KM1NJKf0/kYyYALOIEJmBMSk06F6saCLiAHlqQ3eU B5MY72i6/TnxjzwU/4q0FSfjZNBEdc57vtF1lQoxURDk/yebEf//KSZH5Vx3nCAhNkVcvZHE p+qj1MiOyKBq3V4RpnJ8OsM2qcgXdWjmmNVY0glqqK4tqgXIg5AJYgUKlYDh7KCBRxpAZvpA 54GUw5b36aMgmrpbSujZQSCu2aXcJ7mh2XLcldrm+aiV+Rvvg1RnwQXyenVOmehQpGfUsSun RBt4skxJaQkzemLmUyxMA1KkdFZmisDLVaNwidf4lPlrf3eAZ/cHeSiVWh+mIOU1uv039Xqn 3qLCWSd/2OOFZbt3xC+ovB8V9/dAymDglNQ0E/lbc4OXXNu3513+POW7G61HGJbEAehssHNi veXDcUKgRy5ty+2RKPggyeHXE+yphGBJ2aMJ0TN5Xonl+9IoyBkq8LW8JO9JF+Ldb0r6slV/ mcdwL9FkKPN8oZnyiu4lArNyl/pCN6zbfG2Bj54HO523B6K/zIO1hiT6waJdbZz2WMfYf97L xJyfYO+c23OSHNT/TD74f9RTtKMAnSrm67VPtAk+EdgYsC8J9IW6DGWj7J3kxd1BowLM3IhF oTKZ4LlYzpC8tKRYguYCpX8VoiqcSXIGYqugLwBPUifVtFtQ6tA/q5p57Jo6EoGEuPuU/ZPk Se6TRU+57+LmG+/I9fL6I7OmJNbkcgrFxk4eOZboXVTCGnbftK8lb/EnizdtZmOeW4MIRVih Zx+NeTmeCLMwL+xQDLpDN+Zpt0zFzPe7L6PCu8XchS89K7PlyQgqylpO6L5Q2HNgeTWgA/no 1KdUsZc8JZrCIt5bdHixSPdg==
- Ironport-sdr: g0HMG15E3+ihH/3TFl7J5XbJ0AkVj7b+ijIjSI0yJd55AW/ffBH1Zix5JhVKOg+fVHlJvvhKT4 Qfbf0vLIyTQotwty7qaxVpQZ3kg6Sb76DFNgTtkd30hhs3BNtUPGMfI3GCAxf0CLDkLXHS2b4G Pz8/PeQ09YCVfEuzivnTJqFEvTBEQfCRHQCWJO9J7RYIwdt+3Rm2U/IQMgpjN1asMANaIiTpx3 vf19S+r3NX74gy2X0BfEwnqi8Qy6I/lOVs2HYfLj7Lve1HeRocdFWz+K+RsfFAVM4PzcFXiP7h 9/Q=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Thu, Apr 15, 2021 at 11:34:55AM +0200, Jan Beulich wrote:
> On x86, idle and other system domains are implicitly PV. While I
> couldn't spot any cases where this is actively a problem, some cases
> required quite close inspection to be certain there couldn't e.g. be
> some ASSERT_UNREACHABLE() that would trigger in this case. Let's be on
> the safe side and make sure these always have is_pv_domain() returning
> true.
>
> For the build to still work, this requires a few adjustments elsewhere.
> In particular is_pv_64bit_domain() now gains a CONFIG_PV dependency,
> which means that is_pv_32bit_domain() || is_pv_64bit_domain() is no
> longer guaranteed to be the same as is_pv_domain().
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> v2: Add comment.
Sorry for not replying earlier, I've been thinking about this because
I don't really like this approach as I think it makes code harder to
follow for two reasons, first is_pv_32bit_domain() ||
is_pv_64bit_domain() != is_pv_domain(), which I could live with, and
then also is_pv_64bit_domain() returning different values for system
domains depending on whether CONFIG_PV is enabled.
Given that AFAICT this patch is not fixing any actively identified
issue I would rather prefer to introduce is_system_domain and use it
when appropriate?
I think that would be clearer long term, and avoid tying ourselves
deeper into aliasing system domain with PV domains.
Thanks, Roger.
|
