From: "Limonciello, Mario" <mario.limonciello@amd.com>
To: Grzegorz Jaszczyk <jaz@semihalf.com>,
"Rafael J. Wysocki" <rafael@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Dmytro Maluka <dmy@semihalf.com>,
Sean Christopherson <seanjc@google.com>,
Dominik Behr <dbehr@google.com>,
upstream@semihalf.com,
Zide Chen <zide.chen@intel.corp-partner.google.com>,
Len Brown <lenb@kernel.org>, Hans de Goede <hdegoede@redhat.com>,
Mark Gross <markgross@kernel.org>, Pavel Machek <pavel@ucw.cz>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Sachi King <nakato@nakato.io>,
"open list:ACPI" <linux-acpi@vger.kernel.org>,
"open list:X86 PLATFORM DRIVERS"
<platform-driver-x86@vger.kernel.org>,
"open list:HIBERNATION (aka Software Suspend,
aka swsusp)" <linux-pm@vger.kernel.org>
Subject: Re: [RFC PATCH 1/2] suspend: extend S2Idle ops by new notify handler
Date: Wed, 20 Jul 2022 10:22:15 -0500 [thread overview]
Message-ID: <352edf44-5983-403f-b8f8-5dfbd92ea32d@amd.com> (raw)
In-Reply-To: <CAH76GKO9sxnuLM--x6sg7m3bC_NgvLA94N6jHA-+5gW741-ByQ@mail.gmail.com>
>> It looks like you want suspend-to-idle to behave like S3 and it won't.
>
> In a way, yes, we compensate for the lack of something like PM1_CNT to
> trap on for detecting that the guest is suspending.
> We could instead force the guest to use S3 but IMO it is undesirable,
> since it generally does make a difference which suspend mode is used
> in the guest, s2idle or S3, e.g some drivers check which suspend type
> is used and based on that behaves differently during suspend. One of
> the example is:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Fv5.18.12%2Fsource%2Fdrivers%2Fgpu%2Fdrm%2Famd%2Famdgpu%2Famdgpu_drv.c%23L2323&data=05%7C01%7Cmario.limonciello%40amd.com%7C7bdd972291324d03847e08da6a51ff4f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637939197694682503%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5M1sn3iRybQzSFi3ojQ4YTJuW41DlgJNl5sxbWEvLBQ%3D&reserved=0
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Fv5.18.12%2Fsource%2Fdrivers%2Fgpu%2Fdrm%2Famd%2Famdgpu%2Famdgpu_acpi.c%23L1069&data=05%7C01%7Cmario.limonciello%40amd.com%7C7bdd972291324d03847e08da6a51ff4f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637939197694682503%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fIrLmZAgpIRPYO4to4uYUoBSEWXmz1lr%2BTnR14kAfvM%3D&reserved=0
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Fv5.18.12%2Fsource%2Fdrivers%2Fgpu%2Fdrm%2Famd%2Famdgpu%2Famdgpu_gfx.c%23L583&data=05%7C01%7Cmario.limonciello%40amd.com%7C7bdd972291324d03847e08da6a51ff4f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637939197694682503%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SNsbmpV4HrgA%2Bkff4JzRodNDzKvwM5tnkGDvrKO44dc%3D&reserved=0
>
Actually I recently was suggesting a change to add this detection to
another driver to set a policy and Rafael pushed back. He's actively
removing it from other places in the kernel.
For amdgpu stuff you pointed above, are you wanting to pass through the
PCIe GPU device to a guest and then suspend that guest? Or is this just
illustrative?
For a dGPU I would expect it works, but I don't think passing an APU's
GPU PCIe endpoint would functionally work (there were bugs reported on
this I recall).
That code path you point out only has special handling for APU when
headed to S0ix and that's because the GPU driver happens to be where the
control point is for some common silicon functions. If the bug I
mentioned about PCIe passthrough of the APU GPU endpoint to the guest is
fixed and the guest needs to do s0ix when the host doesn't we're going
to have other breakage to worry about because of that common silicon
functionality I mentioned.
next prev parent reply other threads:[~2022-07-20 15:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-07 12:53 [RFC PATCH 0/2] x86: allow to notify host about guest entering s2idle Grzegorz Jaszczyk
2022-07-07 12:53 ` [RFC PATCH 1/2] suspend: extend S2Idle ops by new notify handler Grzegorz Jaszczyk
2022-07-19 18:08 ` Rafael J. Wysocki
2022-07-20 13:15 ` Grzegorz Jaszczyk
2022-07-20 15:22 ` Limonciello, Mario [this message]
2022-07-20 15:54 ` Grzegorz Jaszczyk
2022-08-22 9:26 ` Grzegorz Jaszczyk
2022-09-12 14:44 ` Grzegorz Jaszczyk
2022-11-30 12:25 ` Grzegorz Jaszczyk
2023-02-06 18:58 ` Rafael J. Wysocki
2022-07-07 12:53 ` [RFC PATCH 2/2] platform/x86: Add virtual PMC driver used for S2Idle Grzegorz Jaszczyk
2022-07-07 15:51 ` Randy Dunlap
2022-07-07 15:27 ` [RFC PATCH 0/2] x86: allow to notify host about guest entering s2idle Limonciello, Mario
2022-07-15 13:27 ` Grzegorz Jaszczyk
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=352edf44-5983-403f-b8f8-5dfbd92ea32d@amd.com \
--to=mario.limonciello@amd.com \
--cc=dbehr@google.com \
--cc=dmy@semihalf.com \
--cc=hdegoede@redhat.com \
--cc=jaz@semihalf.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=markgross@kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=nakato@nakato.io \
--cc=pavel@ucw.cz \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=seanjc@google.com \
--cc=upstream@semihalf.com \
--cc=zide.chen@intel.corp-partner.google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox