Linux Virtualization - Feb 2020 - [PATCH] x86/ioperm: add new paravirt function update_io_bitmap

On 18.02.20 22:03, Thomas Gleixner wrote:
> Juergen Gross <jgross at suse.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 at suse.com>
>> Cc: <stable at vger.kernel.org> # 5.5
>> Signed-off-by: Juergen Gross <jgross at suse.com>
>> Reviewed-by: Jan Beulich <jbeulich at suse.com>
>> Tested-by: Jan Beulich <jbeulich at suse.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.

Our CI tests tend do be more text console based for dom0.


Juergen

On 19.02.2020 06:35, J?rgen Gro? wrote:
> On 18.02.20 22:03, Thomas Gleixner wrote:
>> Juergen Gross <jgross at suse.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 at suse.com>
>>> Cc: <stable at vger.kernel.org> # 5.5
>>> Signed-off-by: Juergen Gross <jgross at suse.com>
>>> Reviewed-by: Jan Beulich <jbeulich at suse.com>
>>> Tested-by: Jan Beulich <jbeulich at suse.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

J?rgen Gro? <jgross at suse.com> writes:
> On 18.02.20 22:03, Thomas Gleixner wrote:
>> 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.
>
> Our CI tests tend do be more text console based for dom0.
tools/testing/selftests/x86/io[perm|pl] should have caught that as well,
right? If not, we need to fix the selftests.

Thanks,

        tglx

On 19.02.20 10:22, Thomas Gleixner wrote:
> J?rgen Gro? <jgross at suse.com> writes:
>> On 18.02.20 22:03, Thomas Gleixner wrote:
>>> 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.
>>
>> Our CI tests tend do be more text console based for dom0.
> 
> tools/testing/selftests/x86/io[perm|pl] should have caught that as well,
> right? If not, we need to fix the selftests.
Hmm, yes. Thanks for the pointer.

Will ask our testing specialist what is done in this regard and how it
can be enhanced.


Juergen