Re: [PATCH v5 1/6] target/i386: Update EPYC CPU model for Cache property, RAS, SVM feature bits

[Zhao Liu <zhao1.liu@intel.com>]

On Wed, Feb 26, 2025 at 02:28:35PM -0600, Moger, Babu wrote:
> Date: Wed, 26 Feb 2025 14:28:35 -0600
> From: "Moger, Babu" <babu.moger@amd.com>
> Subject: Re: [PATCH v5 1/6] target/i386: Update EPYC CPU model for Cache
>  property, RAS, SVM feature bits
> 
> Hi John,
> 
> On 2/25/25 11:01, John Allen wrote:
> > On Thu, Feb 20, 2025 at 06:59:34PM +0800, Zhao Liu wrote:
> >> And one more thing :-) ...
> >>
> >>>  static const CPUCaches epyc_rome_cache_info = {
> >>>      .l1d_cache = &(CPUCacheInfo) {
> >>>          .type = DATA_CACHE,
> >>> @@ -5207,6 +5261,25 @@ static const X86CPUDefinition builtin_x86_defs[] = {
> >>>                  },
> >>>                  .cache_info = &epyc_v4_cache_info
> >>>              },
> >>> +            {
> >>> +                .version = 5,
> >>> +                .props = (PropValue[]) {
> >>> +                    { "overflow-recov", "on" },
> >>> +                    { "succor", "on" },
> >>
> >> When I checks the "overflow-recov" and "succor" enabling, I find these 2
> >> bits are set unconditionally.
> >>
> >> I'm not sure if all AMD platforms support both bits, do you think it's
> >> necessary to check the host support?
> > 
> > Hi Zhao,
> > 
> > IIRC, we intentionally set these unconditionally since there is no
> > specific support needed from the host side for guests to use these bits
> > to handle MCEs. See the original discussion and rationale in this
> > thread:
> > 
> > https://lore.kernel.org/all/20230706194022.2485195-2-john.allen@amd.com/
> > 
> > However, this discussion only applied to the SUCCOR feature and not the
> > OVERFLOW_RECOV feature and now that you bring it up, I'm second guessing
> > whether we can apply the same thinking to OVERFLOW_RECOV. I think we may
> > want to keep setting the SUCCOR bit unconditionally, but we may want to
> > handle OVERFLOW_RECOV normally. I'll have to track down some old
> > hardware to see how this behaves when the hardware doesn't support it.

Yes, thanks!

> Yes. We need to verify it on pre-EPYC hardware. Please let us know how it
> goes.
> 
> But, this series updates only the EPYC based CPU models. It should not be
> a concern here. Right?

Yes, it doesn't block this series. :-)

Thank you both,
Zhao