[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e1617641-2106-cd81-628f-569b1a8cf1f7@suse.com>
Date: Wed, 19 Feb 2020 09:29:41 +0100
From: Jan Beulich <jbeulich@...e.com>
To: Jürgen Groß <jgross@...e.com>,
Thomas Gleixner <tglx@...utronix.de>
Cc: xen-devel@...ts.xenproject.org, x86@...nel.org,
linux-kernel@...r.kernel.org,
virtualization@...ts.linux-foundation.org,
Thomas Hellstrom <thellstrom@...are.com>,
Stefano Stabellini <sstabellini@...nel.org>,
"VMware, Inc." <pv-drivers@...are.com>, stable@...r.kernel.org,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>
Subject: Re: [PATCH] x86/ioperm: add new paravirt function update_io_bitmap
On 19.02.2020 06:35, Jürgen Groß wrote:
> On 18.02.20 22:03, Thomas Gleixner wrote:
>> Juergen Gross <jgross@...e.com> writes:
>>> Commit 111e7b15cf10f6 ("x86/ioperm: Extend IOPL config to control
>>> ioperm() as well") reworked the iopl syscall to use I/O bitmaps.
>>>
>>> Unfortunately this broke Xen PV domains using that syscall as there
>>> is currently no I/O bitmap support in PV domains.
>>>
>>> Add I/O bitmap support via a new paravirt function update_io_bitmap
>>> which Xen PV domains can use to update their I/O bitmaps via a
>>> hypercall.
>>>
>>> Fixes: 111e7b15cf10f6 ("x86/ioperm: Extend IOPL config to control ioperm() as well")
>>> Reported-by: Jan Beulich <jbeulich@...e.com>
>>> Cc: <stable@...r.kernel.org> # 5.5
>>> Signed-off-by: Juergen Gross <jgross@...e.com>
>>> Reviewed-by: Jan Beulich <jbeulich@...e.com>
>>> Tested-by: Jan Beulich <jbeulich@...e.com>
>>
>> Duh, sorry about that and thanks for fixing it.
>>
>> BTW, why isn't stuff like this not catched during next or at least
>> before the final release? Is nothing running CI on upstream with all
>> that XEN muck active?
>
> This problem showed up by not being able to start the X server (probably
> not the freshest one) in dom0 on a moderate aged AMD system.
Not the freshest one, yes, but also on a system where KMS would not
be available (my success rate with KMS is rather low overall, and
with newer Linux I see rather more systems to stop working than ones
to become working, but I simply don't have the time to investigate).
Jan
Powered by blists - more mailing lists