On 07/11/2018 14:59, Halil Pasic wrote:
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?
OK, I undertand, you want to make an optimization and kick one idle CPU
not having the interrupt masked.
Seems right for me, but I think we could implement this later.
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...
I mean:
All if CPU are idle with interrupt masked for adapter interrupt...
1) dispatching will not help, obviously.
2) setting the IAM will be contra productive since:
2.1) if we get an adapter interrupt and at this moment CPU are still
with interrupt masked we will land in the GAL interrupt, we still have
no reason to dispatch and we will not get another interrupt
2.2) if we get any interrupt making one CPU change its PSW or CR6,
instead of getting the next adapter interrupt delivered to the guest we
will land in the GAL interrupt and will need to dispatch a vcpu instead
of letting the hardware do the job
Halil
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
