[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BYAPR21MB1688B9B05B7796FD8D7D50DDD7059@BYAPR21MB1688.namprd21.prod.outlook.com>
Date: Mon, 14 Nov 2022 17:25:19 +0000
From: "Michael Kelley (LINUX)" <mikelley@...rosoft.com>
To: Dave Hansen <dave.hansen@...el.com>,
"hpa@...or.com" <hpa@...or.com>, KY Srinivasan <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
"wei.liu@...nel.org" <wei.liu@...nel.org>,
Dexuan Cui <decui@...rosoft.com>,
"luto@...nel.org" <luto@...nel.org>,
"peterz@...radead.org" <peterz@...radead.org>,
"davem@...emloft.net" <davem@...emloft.net>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"kuba@...nel.org" <kuba@...nel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"lpieralisi@...nel.org" <lpieralisi@...nel.org>,
"robh@...nel.org" <robh@...nel.org>, "kw@...ux.com" <kw@...ux.com>,
"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
"arnd@...db.de" <arnd@...db.de>,
"hch@...radead.org" <hch@...radead.org>,
"m.szyprowski@...sung.com" <m.szyprowski@...sung.com>,
"robin.murphy@....com" <robin.murphy@....com>,
"thomas.lendacky@....com" <thomas.lendacky@....com>,
"brijesh.singh@....com" <brijesh.singh@....com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>,
"bp@...en8.de" <bp@...en8.de>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
Tianyu Lan <Tianyu.Lan@...rosoft.com>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"sathyanarayanan.kuppuswamy@...ux.intel.com"
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
"ak@...ux.intel.com" <ak@...ux.intel.com>,
"isaku.yamahata@...el.com" <isaku.yamahata@...el.com>,
"Williams, Dan J" <dan.j.williams@...el.com>,
"jane.chu@...cle.com" <jane.chu@...cle.com>,
"seanjc@...gle.com" <seanjc@...gle.com>,
"tony.luck@...el.com" <tony.luck@...el.com>,
"x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>
Subject: RE: [PATCH v2 01/12] x86/ioremap: Fix page aligned size calculation
in __ioremap_caller()
From: Dave Hansen <dave.hansen@...el.com> Sent: Monday, November 14, 2022 8:58 AM
>
> On 11/14/22 08:53, Michael Kelley (LINUX) wrote:
> >> Because, first of all, that "Mappings have to be page-aligned" thing is
> >> (now) doing more than page-aligning things. Second, the moment you mask
> >> out the metadata bits, the 'size' calculation gets harder. Doing it in
> >> two phases (page alignment followed by metadata bit masking) breaks up
> >> the two logical operations.
> >>
> > Work for me. Will do this in v3.
>
> Kirill also made a good point about TDX: it isn't affected by this
> because it always passes *real* (no metadata bits set) physical
> addresses in here. Could you double check that you don't want to do the
> same for your code?
>
Yes, we want to do the same for the Hyper-V vTOM code. And when this
full patch set is applied, we're only passing in *real* physical addresses and
are not depending on __ioremap_caller() doing any masking.
But this patch set is executing a transition from current code, which passes
physical addresses with metadata bits set (i.e., the vTOM bit), to the new
approach, which does not. There are several places in the current Hyper-V
vTOM code that need changes to make this transition. These changes are
non-trivial, and I don't want to have to cram them all into one big patch.
By making this fix, the current code continues to work throughout this
patch series while the changes are incrementally made in multiple
individual patches. But when it's all done, we won't be passing any
physical addresses with the vTOM bit set.
Note that current code works and doesn't hit the bug because the
global variable physical_mask includes the vTOM bit as part of the
physical address. But Patch 5 of the series removes the vTOM bit
from physical_mask. At that point, the current __ioremap_caller()
code breaks due to the bug. By fixing the bug, the current Hyper-V
vTOM code continues to work until all the changes can be completed
(which is Patch 10 of the series).
Perhaps it's convoluted, but basically I'm trying to avoid having to merge
Patches 5 thru 10 into one big patch. And since the current
__ioremap_caller() is wrong anyway, fixing it made everything smoother.
Michael
Powered by blists - more mailing lists