linux-kernel - Re: [PATCH v2] enable x2APIC without interrupt remapping under KVM

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] [day] [month] [year] [list]

Date:	Mon, 29 Jun 2009 04:48:44 -0700
From:	Suresh Siddha <suresh.b.siddha@...el.com>
To:	Gleb Natapov <gleb@...hat.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Sheng Yang <sheng@...ux.intel.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"avi@...hat.com" <avi@...hat.com>
Subject: Re: [PATCH v2] enable x2APIC without interrupt remapping under KVM

On Mon, 2009-06-29 at 04:25 -0700, Gleb Natapov wrote:
> I left interrupt masking in enable_IR_x2apic() because interrupt should
> be masked during transition to x2apic mode, so it can't be moved to
> enable_IR(). I moved io-apic into enable_IR() because the state of
> io-apic depend on whether IR was enabled or not, so I left it close to
> IR enabling logic.

This can be based on the outcome of enable_IR().

>  Also io-apic masking can fail, but we still want to
> enable x2apic on KVM if possible, and moving io-apic masking to
> enable_IR_x2apic() will complicate the logic.

io-apic masking can fail because of memory allocation failures, right?
If we want a simple solution, we can skip both x2apic and IR. This is
not going to be common scenario anyhow. If we really hit this, we will
worry about more things than x2apic :)

> 
> > Can we keep it together so that it will be easy to read and understand
> > that we first do the interrupt subsystem mask, try enabling IR and
> > x2apic and  unmask the interrupt subsystem.
> > 
> For io-apic this is not 100% symmetric. We mask io-apic, enable IR and
> if this succeeds we do not unmask io-apic.

Correct. Can we do the same, otherwise we might have a situation (under
kvm atleast) where io-apic will be active while we will be changing the
cpu mode. Just trying to be defensive as these might lead to hard to
debug corner case conditions.

thanks,
suresh

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/