Received-SPF: pass (google.com: domain of linux-kernel+bounces-182156-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Fri, 17 May 2024 16:48:28 +0300
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>, Adam Dunlap <acdunlap@google.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH v1 1/1] x86/cpu: Fix boot on Intel Quark X1000
Message-ID: <ZkdgLI8PGutkQGKK@smile.fi.intel.com>
References: <20240516173928.3960193-1-andriy.shevchenko@linux.intel.com>
 <8286f8b9-488c-418f-8bad-d23871a8afab@intel.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8286f8b9-488c-418f-8bad-d23871a8afab@intel.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo

On Thu, May 16, 2024 at 11:21:13AM -0700, Dave Hansen wrote:
> On 5/16/24 10:39, Andy Shevchenko wrote:
> > The initial change to set x86_virt_bits to the correct value straight
> > away broke boot on Intel Quark X1000 CPUs (which are family 5, model 9,
> > stepping 0)
> 
> Do you know what _actually_ broke?  Like was there a crash somewhere?

Nope, I have no a single character to tell anything about this.
Note, earlyprintk may not be helpful as this SoC doesn't have legacy UARTs.

> > With deeper investigation it appears that the Quark doesn't have
> > the bit 19 set in 0x01 CPUID leaf, which means it doesn't provide
> > any clflush instructions and hence the cache alignment is set to 0.
> > The actual cache line size is 16 bytes, hence we may set the alignment
> > accordingly. At the same time the physical and virtual address bits
> > are retrieved via 0x80000008 CPUID leaf.
> 
> This seems to be saying that ->x86_clflush_size must come from CPUID.
> But there _are_ CPUID-independent defaults set in identify_cpu().  How
> do those fit in?

Where? The mentioned fbf6449f84bf dropped those for this case.

> > Note, we don't really care about the value of x86_clflush_size as it
> > is either used with a proper check for the instruction to be present,
> > or, like in PCI case, it assumes 32 bytes for all supported 32-bit CPUs
> > that have actually smaller cache line sizes and don't advertise it.
> 
> Are you trying to say that having ->x86_clflush_size==0 is not fatal
> while having ->x86_cache_alignment==0 _is_ fatal?

I'm only saying that clflush is not implemented there and having
a dangled value is not a problem.

But it indeed implies what you are saying.

> > The commit fbf6449f84bf ("x86/sev-es: Set x86_virt_bits to the correct
> > value straight away, instead of a two-phase approach") basically
> > revealed the issue that has been present from day 1 of introducing
> > the Quark support.
> 
> How did it do that, exactly?  It's still not crystal clear.

See above, it removes, like you said, the CPUID independent defaults which
were set unconditionally and implied that cache alignment should come from
CPUID (clflush bits).

..

> > +	/*
> > +	 * The Quark doesn't have bit 19 set in 0x01 CPUID leaf, which means
> > +	 * it doesn't provide any clflush instructions and hence the cache
> > +	 * alignment is set to 0. The actual cache line size is 16 bytes,
> > +	 * hence set the alignment accordingly. At the same time the physical
> > +	 * and virtual address bits are retrieved via 0x80000008 CPUID leaf.
> > +	 */
> > +	if (c->x86 == 5 && c->x86_model == 9)
> > +		c->x86_cache_alignment = 16;
> 
> What are the odds that another CPU has this issue?

I'm not sure I follow.

> I'm thinking we should just set a default in addition to hacking around this
> for Quark.

-- 
With Best Regards,
Andy Shevchenko