[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: x86/PV: (lack of) MTRR exposure
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Fri, 29 Apr 2022 12:07:33 +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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=k2H+bL2KcMUVVnQEklaMinDUUpUYPRANCBMMCDnBRL4=; b=DwE6/q5oAz+xJ6hLdqWGy9lbyNmUOtlSotJq0b+asJXYXwNQytNG/ZOZl8P1ULSNzWU6sSf8oy5ezcACySb6BZDIaTGSTXGzpJkleMmzaj2Za7FPkQMGE9ujYZJmq/YoDDfCAyFtGbB2l/LEvW9pCmPnqkw8/BxaVyZ+FTSP1jWEDGHEAcJFWXcDM9h7audhzMdg/wlNrbpg+eWWI1Ssd/qoiCk2dYLAr/uSd0y23p55Yy8QfOnUAXx0+1beCgTtHPubAquclXmSp9iBj4oqTRtpw03aecoPIHHj308cnnZxbVojhG9LQRVhx0/DzbNghcVcoNlXciYnNqu1Yw3jIw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kWkxp4r+XIPhg6iXX2Tm3a6t4pdEe9VzUyiemzHUeBIwcrnrVlC7E6pgU9pojWTFlos6kzAlTbeqh1g8K9Ov8afrNJV8kayYeVYq08AK5sTkQKK6q5LW0ucgg96fpLuTDuHFM+New2jCmacIkRfe4yu2T+v99jKslXH2VkQU6kJxIRJfArHwCLI6Pc9nKp5bqgJ1wk+cta3AMB/OtMFrjULHZmgh52P7yCR1aJU5cov/PbKsx4YBWOfW5FUcqZVb6SdAkn3cKZqbeQ7+7uQdHwy7JArf8HUsBAuepsiGex0n/wggFKBweIZYs/bvdz0taMp0wJPWasx+2z7RDOUjlA==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Fri, 29 Apr 2022 10:08:16 +0000
- Ironport-data: A9a23:xBkFeq1K4JF3OvFZkvbD5fxwkn2cJEfYwER7XKvMYLTBsI5bpzAGz GcdWWyGM62NNzSke94lbo2x/B4A7MWAn4I1Tws4pC1hF35El5HIVI+TRqvS04J+DSFhoGZPt Zh2hgzodZhsJpPkjk7xdOCn9xGQ7InQLlbGILes1htZGEk1EU/NtTo5w7Rj2tIy0IDja++wk YiaT/P3aQfNNwFcagr424rbwP+4lK2v0N+wlgVWicFj5DcypVFMZH4sDfjZw0/DaptVBoaHq 9Prl9lVyI97EyAFUbtJmp6jGqEDryW70QKm0hK6UID66vROS7BbPg/W+5PwZG8O4whlkeydx /0VkMeoU140Y5fXs8kabThVOnp1OopZreqvzXiX6aR/zmXgWl61mrBEKhFzOocVvOFqHWtJ6 PoUbigXaQyOjP63x7T9TfRwgsMkL4/gO4Z3VnNIlGmFS6p5B82TBfyVu7e03x9p7ixKNezZa McDLyJmcTzLYgFVO0dRA5U79AutrianLWcF8gvNzUYxy1rOi1xN6L3fCdzqXobXHMdqtXbfo 22TqgwVBTlfbrRz0wGt8Hihm+vOliPTQ58JGfuz8fsCqFeU3G0IThoNSUG8v+K6m2a5QdtUL 0FS8S0rxYAw+1asVcLVRACjrTiPuRt0c8FLD+Qw5QWJy6zVywWUHG4JSnhGctNOnN87Q3km2 0GEm/vtBCdzq/uFRHSF7LCWoDiufy8PIgc/iTQsSAIE55zpptE1hxeWF9J7Svfq0JvyBC36x C2MoG4mnbIPgMUX1qK9u1fanzaroZuPRQkwjunKYl+YAspCTNbNT+SVBZLztp6s8K7xooG9g UU5
- Ironport-hdrordr: A9a23:ItGFHKBiZEvPQ27lHeg/sceALOsnbusQ8zAXPh9KJCC9I/bzqy nxpp8mPH/P5wr5lktQ/OxoHJPwOU80lKQFmLX5WI3PYOCIgguVxe1ZnOjfKnjbalbDH41mpN tdmspFebrN5DFB5K6VgTVQUexQpuVvmJrY+Ns2pE0dKT2CBZsQjTuQXW2gYzdLrUR9dNMEPa vZwvACiyureHwRYMj+Ln4ZX9Lbr9mOsJ79exYJCzMu9QHL1FqTmfXHOind+i1bfyJEwL8k/2 SAuwvl5p+7u/X+7hPHzWfc47lfhdOk4NpeA86njNQTN1zX+06VTbUkf4fHkCE+oemp5lpvuN 7Qoy04N8A20H/VdnHdm2qY5+FNuAxem0PK+Bu9uz/OsMb5TDU1B45qnoRCaCbU7EImoZVVzL 9L93jxjesZMTrw2ADGo/TYXRBjkUS55VA4l/QIsnBZWYwCLJdMsI0k+l9PGptoJlO31GkeKp guMCjg3ocXTbvDBEqp/VWHgebcE0jbJy32DHTr4aeuonprdHMQ9Tps+CVQpAZEyHsHceg72w 31CNUWqFhwdL5mUUtcPpZ3fSLlMB26ffrzWFjiUmjPJeUgB0/njaLRzfEc2NyKEaZ4vqfa3q 6xGm9liQ==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Fri, Apr 29, 2022 at 11:50:39AM +0200, Jan Beulich wrote:
> On 28.04.2022 23:30, Boris Ostrovsky wrote:
> >
> > On 4/28/22 11:53 AM, Jan Beulich wrote:
> >> Hello,
> >>
> >> in the course of analyzing the i915 driver causing boot to fail in
> >> Linux 5.18 I found that Linux, for all the years, has been running
> >> in PV mode as if PAT was (mostly) disabled. This is a result of
> >> them tying PAT initialization to MTRR initialization, while we
> >> offer PAT but not MTRR in CPUID output. This was different before
> >> our moving to CPU featuresets, and as such one could view this
> >> behavior as a regression from that change.
> >>
> >> The first question here is whether not exposing MTRR as a feature
> >> was really intended, in particular also for PV Dom0. The XenoLinux
> >> kernel and its forward ports did make use of XENPF_*_memtype to
> >> deal with MTRRs. That's functionality which (maybe for a good
> >> reason) never made it into the pvops kernel. Note that PVH Dom0
> >> does have access to the original settings, as the host values are
> >> used as initial state there.
> >
> >
> > Initially MTRR was supposed to be supported but it was shot down by x86
> > maintainers who strongly suggested to use PAT.
> >
> >
> > https://lists.xen.org/archives/html/xen-devel/2010-09/msg01634.html
>
> I recall Ingo's dislike, yes. But them suggesting to use PAT when
> PAT depends on MTRR internally is, well, odd. Plus there continues
> to be the question why PVH Dom0 should see (and be able to play
> with) MTRRs, when PV Dom0 can't even learn their values.
Oh, I didn't realize the handling of MTRR in PVH dom0 was a question,
sorry.
I don't think it makes sense to limit PVH dom0 access to MTRR if that
then implies changes to Linux when running in PVH mode so it can use
PAT, and likely changes to Xen in order to avoid using MTRR when
calculating the effective cache types (ie: in epte_get_entry_emt).
I also don't think there's a need to have this kind of feature parity
between PVH and PV dom0s. IMO we should expose whatever is required
or makes the implementation of guests easier. For PVH we could always
stop reporting the CPUID MTRR bit and thus stop exposing MTRRs and
guests should cope.
Thanks, Roger.
|
