[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87mu9fr4ky.fsf@nanos.tec.linutronix.de>
Date: Tue, 18 Feb 2020 22:03:09 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Juergen Gross <jgross@...e.com>, xen-devel@...ts.xenproject.org,
x86@...nel.org, linux-kernel@...r.kernel.org,
virtualization@...ts.linux-foundation.org
Cc: Juergen Gross <jgross@...e.com>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Hellstrom <thellstrom@...are.com>,
"VMware\, Inc." <pv-drivers@...are.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Stefano Stabellini <sstabellini@...nel.org>,
stable@...r.kernel.org
Subject: Re: [PATCH] x86/ioperm: add new paravirt function update_io_bitmap
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?
Thanks,
tglx
Powered by blists - more mailing lists