All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Yazen Ghannam <yazen.ghannam@amd.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	 Libing He <libhe@redhat.com>, David Arcari <darcari@redhat.com>,
	 Mario Limonciello <mario.limonciello@amd.com>
Subject: Re: [PATCH] x86/CPU/AMD: Ignore invalid reset reason value
Date: Thu, 24 Jul 2025 13:58:45 -0700	[thread overview]
Message-ID: <aIKehTDgP-Nu36ol@google.com> (raw)
In-Reply-To: <27E487FE-EC8D-42AC-B259-F8A18776C802@alien8.de>

On Wed, Jul 23, 2025, Borislav Petkov wrote:
> On July 23, 2025 9:34:26 PM GMT+03:00, Yazen Ghannam <yazen.ghannam@amd.com> wrote:
> >On Tue, Jul 22, 2025 at 06:56:15PM +0200, Borislav Petkov wrote:
> >> On Mon, Jul 21, 2025 at 06:11:54PM +0000, Yazen Ghannam wrote:
> >> > The reset reason value may be "all bits set", e.g. 0xFFFFFFFF. This is a
> >> > commonly used error response from hardware. This may occur due to a real
> >> > hardware issue or when running in a VM.
> >> 
> >> Well, which is it Libing is reporting? VM or a real hw issue?
> >> 
> >
> >In this case, it was a VM.
> >
> >> If it is a VM, is that -1 the only thing a VMM returns when reading that
> >> MMIO address or can it be anything?
> >> 
> >> If latter, you need to check X86_FEATURE_HYPERVISOR.
> >> 
> >> Same for a real hw issue.
> >> 
> >> IOW, is -1 the *only* invalid data we can read here or are we playing
> >> whack-a-mole with it?
> >> 
> >
> >I see you're point, but I don't think we can know for sure all possible
> >cases. There are some reserved bits that shouldn't be set. But these
> >definitions could change in the future.
> >
> >And it'd be a pain to try and verify combinations of bits and configs.
> >Like can bit A and B be set together, or can bit C be set while running
> >in a VM, or can bit D ever be set on Model Z? 
> >
> >The -1 (all bits set) is the only "applies to all cases" invalid data,
> >since this is a common hardware error response. So we can at least check
> >for this.
> >
> >Thanks,
> >Yazen
> 
> I think you should check both: HV or -1.
> 
> HV covers the VM angle as they don't emulate this

You can't possibly know that.  If there exists a hardware spec of any kind, it's
fair game for emulation.

> and we simply should disable this functionality when running as a guest.
> 
> -1 covers the known-bad hw value.

And in a guest, -1, i.e. 0xffffffff is all but guaranteed to come from the VMM
providing PCI master abort semantics for reads to MMIO where no device exists.
That's about as "architectural" of behavior as you're going to get, so I don't
see any reason to assume no VMM will every emulate whatever this feature is.

  parent reply	other threads:[~2025-07-24 20:58 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-21 18:11 [PATCH] x86/CPU/AMD: Ignore invalid reset reason value Yazen Ghannam
2025-07-21 18:11 ` Yazen Ghannam
2025-07-21 18:13 ` Mario Limonciello
2025-07-22 16:56 ` Borislav Petkov
2025-07-23 18:34   ` Yazen Ghannam
2025-07-23 19:35     ` Borislav Petkov
2025-07-23 19:46       ` Yazen Ghannam
2025-07-24 20:58       ` Sean Christopherson [this message]
2025-07-24 21:02         ` Mario Limonciello
2025-07-24 21:32           ` Sean Christopherson
2025-07-25  6:50             ` Borislav Petkov
2025-08-15 21:39               ` Sean Christopherson
2025-08-15 22:04                 ` Borislav Petkov
2025-08-15 22:49                   ` Sean Christopherson
2025-08-16  8:42                     ` Borislav Petkov
2025-08-18 14:24                       ` Sean Christopherson
2025-08-18 14:31                         ` Borislav Petkov
2025-08-18 15:35                           ` Sean Christopherson
2025-08-18 14:52 ` [tip: x86/urgent] " tip-bot2 for Yazen Ghannam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aIKehTDgP-Nu36ol@google.com \
    --to=seanjc@google.com \
    --cc=bp@alien8.de \
    --cc=darcari@redhat.com \
    --cc=libhe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=x86@kernel.org \
    --cc=yazen.ghannam@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.