On Fri, Feb 04, 2022 at 03:13:52PM +0100, Jan Beulich wrote:
> On 04.02.2022 15:08, Thomas Gleixner wrote:
> > On Fri, Feb 04 2022 at 10:23, Jan Beulich wrote:
> >> On 30.11.2021 12:09, Jan Beulich wrote:
> >>> I think it is b968e84b509d ("x86/iopl: Fake iopl(3) CLI/STI usage")
> >>> which uncovere
On 04.02.2022 15:08, Thomas Gleixner wrote:
> On Fri, Feb 04 2022 at 10:23, Jan Beulich wrote:
>> On 30.11.2021 12:09, Jan Beulich wrote:
>>> I think it is b968e84b509d ("x86/iopl: Fake iopl(3) CLI/STI usage")
>>> which uncovered an issue with get_desc() trying to access the GDT, as
>>> introduced
On Fri, Feb 04 2022 at 10:23, Jan Beulich wrote:
> On 30.11.2021 12:09, Jan Beulich wrote:
>> I think it is b968e84b509d ("x86/iopl: Fake iopl(3) CLI/STI usage")
>> which uncovered an issue with get_desc() trying to access the GDT, as
>> introduced by 670f928ba09b ("x86/insn-eval: Add utility funct
On 30.11.2021 12:09, Jan Beulich wrote:
> I think it is b968e84b509d ("x86/iopl: Fake iopl(3) CLI/STI usage")
> which uncovered an issue with get_desc() trying to access the GDT, as
> introduced by 670f928ba09b ("x86/insn-eval: Add utility function to
> get segment descriptor"). When running in a P
Hello,
I think it is b968e84b509d ("x86/iopl: Fake iopl(3) CLI/STI usage")
which uncovered an issue with get_desc() trying to access the GDT, as
introduced by 670f928ba09b ("x86/insn-eval: Add utility function to
get segment descriptor"). When running in a PV domain under Xen, the
(hypervisor's) G