David Gibson <da...@gibson.dropbear.id.au> writes: > On Mon, Mar 14, 2022 at 07:10:10PM -0300, Fabiano Rosas wrote: >> David Gibson <da...@gibson.dropbear.id.au> writes: >> >> > On Tue, Mar 08, 2022 at 10:23:59PM -0300, Fabiano Rosas wrote: >>
... >> To satisfy TCG we could keep a spapr capability as ON and usually the >> guest would pass cap-gtse=off when running with KVM. However this >> doesn't work because this crash happens precisely because the nested >> guest doesn't know that it needs to use cap-rpt-invalidate=on. Another >> cap wouldn't help. >> >> So I think the only way to have a spapr capability for this is if TCG >> always defaults to ON and KVM always defaults to OFF. But then we would >> be changing guest visible behaviour depending on host properties. > > Ok, I'd forgotten we already have cap-rpt-invalidate. It still > defaults to OFF for now, which might help us. > > What's clear is that we should never disable GTSE if > cap-rpt-invalidate is off - qemu should enforce that before even > starting the guest if at all possible. > > What's less clear to me is if we want to enable GTSE by default or > not, in the cases where we're able to choose. Would always disabling > GTSE when cap-rpt-invalidate=on be ok? Or do we want to be able to > control GTSE separately. In that case we might need a second cap, but > it would need inverted sense, so e.g. cap-disable-gtse. GTSE and cap-rpt-invalidate can be looked at as independent such that we can do GTSE=1 or GTSE=0 with cap-rpt-invalidate=on. But GTSE=0 with cap-rpt-invalidate=off is not allowed/possible. GTSE value is what is negotiated via CAS so we should let the hypervisor inform the guest whether it can do GTSE 0 or 1. The challenge IIUC is Qemu always assumed GTSE=1 which is not true in the case of nested virt where L1 guest that is booted with GTSE=0. with cap-disable-gtse how would one interpret that? Whether hypervisor have the capability to disable gtse? > > I believe a guest that is expecting GTSE==0 should work if > LPCR[GTSE]==1, just not optimally (as long as H_RPT_INVALIDATE is > still available, of course). Is that right? That is correct. -aneesh