On 11/06/2018 07:31 PM, Pierre Morel wrote: > On 06/11/2018 18:54, Cornelia Huck wrote: >> On Tue, 6 Nov 2018 17:54:17 +0100 >> Halil Pasic <pasic@xxxxxxxxxxxxx> wrote: >> >>> On Thu, 25 Oct 2018 14:37:45 +0200 >>> Michael Mueller <mimu@xxxxxxxxxxxxx> wrote: >>> >>>> This metric will allow to identify how many vcpus are currently >>>> running for a given kvm in SIE context. Its value is between 0 and >>>> the number of vcpus defined for the kvm guest, but never lager than >>>> the number of cpus available to the KVM host in total. >>>> >>>> This metric is required to decide if the GISA IAM has to be restored >>>> from the kvm arch field of the guest. That will be the case when no >>>> vcpu is in SIE context. (vcpus_in_sie == 0) >>>> >>> >>> Mimu, we just spoke about -- thus a reminder for us, and a FYI for >>> the rest. vcpus_in_sie != 0 does not necessarily mean that FW can >>> deliver GISA interrupts to the guest (and thus we don't have to >>> dispatch a suitable vcpu): if all cpus in SIE mask IO interrupts it >>> does not really matter that they are in SIE. I.e. we should still get >>> alerted and try to dispatch an eligible vcpu. > > If I understood well, I do not agree. I don't think you understood well. > If all the vCPU have ISC masked in CR6 we do not need to dispatch the vCPU, running or not. > If running, > The first vCPU that will load CR6 with at least one bit of the ISC being one will be scheduled by the firmware. > Let me help you with an example. Our guest has 3 vCPUs. One (CPU1) of those is doing something very important real-time-ish stuff and is currently in SIE with all maskable interrupts shut off (the stuff is very important). The other two vCPUs (CPU2 and CPU3) are open for IO interrupts but idle, that is not in SIE. AFAIU we should opt for getting alerted and kicking CPU2 or CPU3 in this case, as we can not assume that CPU1 will open up for interrupts any time soon. I read your text like, you think we can make that assumption. Did I misunderstand you? If not, why do you think we can make that assumption? > We should not set the IAM if a vCPU with interrupt not masked is running because we will get the alert prior to the guest and loose the benefit of an interrupt directly sent to the guest. > I agree with this point. > The design done here is right. > >> >> So, do we need to restore the IAM as well if all cpus in SIE have I/O >> interrupts masked? Or is it just some dispatching we have to do? >> To me setting IAM looks like our best option. > > If not running, I think this is the right question. > > We should not restore the IAM and should not dispatch the vCPU. > However I am not sure that dispatching the vCPU causes a problem. > > Restoring the IAM would prevent the GISA to be delivered if another interrupt arrives. > Pierre, I'm a bit confused... Halil
