linux-kernel - Re: Does it make sense to flush ap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <86mujucftn.wl-marc.zyngier@arm.com>
Date:   Fri, 10 May 2019 19:41:40 +0100
From:   Marc Zyngier <marc.zyngier@....com>
To:     Heyi Guo <guoheyi@...wei.com>
Cc:     <linux-kernel@...r.kernel.org>,
        Christoffer Dall <christoffer.dall@....com>,
        wanghaibin 00208455 <wanghaibin.wang@...wei.com>
Subject: Re: Does it make sense to flush ap_list of offlined vcpu?

On Thu, 09 May 2019 16:26:04 +0100,
Heyi Guo <guoheyi@...wei.com> wrote:
> 
> Hi folks,
> 
> When guest OS calls PSCI CPU_OFF, the corresponding VCPU will be put
> in sleep state. But if there is still IRQ remaining in this VCPU's
> ap_list, this will block all the following triggers of this IRQ even
> to other VCPUs. Does it make sense to flush the ap_list of the VCPU
> when it is requested to be offlined? Or did I miss something?

I can't see a good reason to do so: If a vcpu gets offlined, the guest
OS has to move interrupt routed to that vcpu to another one. There is
nothing in the GIC architecture that the interrupt will be moved to
another vcpu (well, it could be done with 1:N, which is not really
virtualizable, and not advertised by KVM). That's not different from
what would happen on bare metal.

Thanks,

	M.

-- 
Jazz is not dead, it just smell funny.