[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <053924e2d08b4744b9fd10337e83ab2d@AcuMS.aculab.com>
Date: Wed, 16 Oct 2019 14:14:45 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Paolo Bonzini' <pbonzini@...hat.com>,
Xiaoyao Li <xiaoyao.li@...el.com>,
Thomas Gleixner <tglx@...utronix.de>
CC: Sean Christopherson <sean.j.christopherson@...el.com>,
Fenghua Yu <fenghua.yu@...el.com>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
H Peter Anvin <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"Dave Hansen" <dave.hansen@...el.com>,
Radim Krcmar <rkrcmar@...hat.com>,
Ashok Raj <ashok.raj@...el.com>,
Tony Luck <tony.luck@...el.com>,
Dan Williams <dan.j.williams@...el.com>,
Sai Praneeth Prakhya <sai.praneeth.prakhya@...el.com>,
Ravi V Shankar <ravi.v.shankar@...el.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
x86 <x86@...nel.org>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: RE: [PATCH v9 09/17] x86/split_lock: Handle #AC exception for split
lock
For the smt case, can you make #AC enable a property of the process?
Then disable it on the core if either smt process requires it be disabled?
This would mean that is a 'mixed environment' not all split accesses
would actually generate #AC - but enough would to detect broken code
that doesn't have #AC explicitly disabled.
I'm not sure you'd want a guest to flip #AC enable based on the process
it is scheduling, but it might work for the base metal scheduler.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists