On Mon, Feb 3, 2025 at 8:00 AM Kirill A. Shutemov <kirill@xxxxxxxxxxxxx> wrote: > > ... > > > > Are you hinting towards a model where TDX guest prohibits such call > > sites from being configured? I am not sure if it's a sustainable model > > if we just rely on the host not advertising these features as the > > guest kernel can still add new paths that are not controlled by the > > host that lead to *_safe_halt(). > > I've asked TDX module folks to provide additional information in ve_info > to help handle STI shadow correctly. They will implement it, but it will > take some time. What will the final solution look like? > > So we need some kind of stopgap until we have it. Does it make sense to carry the patch suggested by Sean [1] as a stopgap for now? [1] https://lore.kernel.org/lkml/Z5l6L3Hen9_Y3SGC@xxxxxxxxxx/ > > I am reluctant to commit to paravirt calls for this workaround. They will > likely stick forever. It is possible, I would like to avoid them. If not, > oh well. > > > > > 2) acpi_safe_halt() -> safe_halt() -> raw_safe_halt() -> arch_safe_halt() > > > > > > Have you checked why you get there? I don't see a reason for TDX guest to > > > get into ACPI idle stuff. We don't have C-states to manage. > > > > Apparently userspace VMM is advertising pblock_address through SSDT > > tables in my configuration which causes guests to enable ACPI cpuidle > > drivers. Do you know if future generations of TDX hardware will not > > support different c-states for TDX VMs? > > I have very limited understanding of power management, but I don't see how > C-states can be meaningfully supported by any virtualized environment. > To me, C-states only make sense for baremetal. One possibility is that host can convey guests about using "mwait" as cstate entry mechanism as an alternative to halt if supported. > > -- > Kiryl Shutsemau / Kirill A. Shutemov
