Hello,
Below is a proposed patch for a bug that I have noticed on
Debian versions of Xen going back to at least Xen 4.8, which
shipped with Debian 9 in 2017. In fact, the last Debian version
of Xen that did not have the bug was Xen 4.4 that shipped
with Debian 8 back in 2015. The bug causes passt
On 3/11/2022 3:09 AM, Jan Beulich wrote:
On 11.03.2022 06:01, Chuck Zmudzinski wrote:
Further research showed that these two pages at 0xcc490 are for the
Intel IGD opregion, and because this memory is not permitted to be
accessed by the domain, the passthrough of an Intel IGD to a Linux
HVM
On 3/11/22 8:47 AM, Chuck Zmudzinski wrote:
> On 3/11/2022 3:09 AM, Jan Beulich wrote:
>>
>> Thanks for this analysis. It looks quite plausible (but the question
>> of 2 vs 3 pages of course needs resolving).
>>
>>
>>
>
> After resolving the questio
On 3/11/22 3:09 AM, Jan Beulich wrote:
On 11.03.2022 06:01, Chuck Zmudzinski wrote:
Here is the patch that fixes the bug on Debian sid/Xen 4.16:
As to an actual patch for us to take - please see
docs/process/sending-patches.pandoc for the formal requirements.
(Note this was recently
emory)
Backport: 4.12+
Signed-off-by: Chuck Zmudzinski
---
tools/libs/light/libxl_pci.c | 72
1 file changed, 72 insertions(+)
diff --git a/tools/libs/light/libxl_pci.c b/tools/libs/light/libxl_pci.c
index 4bbbfe9f16..a4fc473de9 100644
--- a/tools/libs/
On 3/14/22 3:26 AM, Jan Beulich wrote:
On 11.03.2022 21:35, Chuck Zmudzinski wrote:
So my only question is:
Is it proper to include header files from tools/firmware/hvmloader in
tools/libs/light/libxl_pci.c ?
No, it certainly is not.
Jan
That's a relief, because if if was prop
On 3/15/2022 7:38 AM, Jan Beulich wrote:
On 14.03.2022 04:41, Chuck Zmudzinski wrote:
Fixes: abfb006f1ff4 (tools/libxl: explicitly grant access to needed
I/O-memory ranges)
Fixes: 0561e1f01e87 (xen/common: do not implicitly permit access to
mapped I/O memory)
Backport: 4.12+
Just fyi: This
On 3/15/22 7:38 AM, Jan Beulich wrote:
On 14.03.2022 04:41, Chuck Zmudzinski wrote:
Fixes: abfb006f1ff4 (tools/libxl: explicitly grant access to needed I/O-memory
ranges)
Fixes: 0561e1f01e87 (xen/common: do not implicitly permit access to mapped I/O
memory)
Backport: 4.12+
Just fyi: This is
On 3/15/22 7:38 AM, Jan Beulich wrote:
On 14.03.2022 04:41, Chuck Zmudzinski wrote:
@@ -610,6 +612,45 @@ out:
return ret;
}
+static uint32_t sysfs_dev_get_igd_opregion(libxl__gc *gc,
+ libxl_device_pci *pci)
+{
+char
On 3/15/2022 9:27 PM, Chuck Zmudzinski wrote:
On 3/15/22 7:38 AM, Jan Beulich wrote:
On 14.03.2022 04:41, Chuck Zmudzinski wrote:
@@ -610,6 +612,45 @@ out:
return ret;
}
+static uint32_t sysfs_dev_get_igd_opregion(libxl__gc *gc
On 3/15/22 7:38 AM, Jan Beulich wrote:
On 14.03.2022 04:41, Chuck Zmudzinski wrote:
+ret = xc_domain_iomem_permission(CTX->xch, stubdom_domid,
+ vga_iomem_start,
+ IGD_OPREGION_PAGES, 1);
+if (
On 3/30/22 1:15 PM, Anthony PERARD wrote:
Hi Chuck,
On Sun, Mar 13, 2022 at 11:41:37PM -0400, Chuck Zmudzinski wrote:
When gfx_passthru is enabled for the Intel IGD, hvmloader maps the IGD
opregion to the guest but libxl does not grant the guest permission to
I'm not reading the same
On 3/30/22 1:27 PM, Andrew Cooper wrote:
On 30/03/2022 18:15, Anthony PERARD wrote:
Some more though on that, looking at QEMU, it seems that there's already
a call to xc_domain_iomem_permission(), in igd_write_opregion().
This has been discussed before, but noone's done anything about it.
It's
On 3/30/22 2:45 PM, Jason Andryuk wrote:
On Fri, Mar 18, 2022 at 4:13 AM Jan Beulich wrote:
On 14.03.2022 04:41, Chuck Zmudzinski wrote:
When gfx_passthru is enabled for the Intel IGD, hvmloader maps the IGD
opregion to the guest but libxl does not grant the guest permission to
access the
On 3/31/2022 8:23 AM, Jason Andryuk wrote:
On Thu, Mar 31, 2022 at 12:34 AM Chuck Zmudzinski wrote:
On 3/30/22 2:45 PM, Jason Andryuk wrote:
On Fri, Mar 18, 2022 at 4:13 AM Jan Beulich wrote:
On 14.03.2022 04:41, Chuck Zmudzinski wrote:
When gfx_passthru is enabled for the Intel IGD
On 3/31/2022 8:29 AM, Jason Andryuk wrote:
On Wed, Mar 30, 2022 at 11:54 PM Chuck Zmudzinski wrote:
On 3/30/22 1:27 PM, Andrew Cooper wrote:
This has been discussed before, but noone's done anything about it.
It's a massive layering violation for QEMU to issue
xc_domain_iomem_
On 3/30/22 1:15 PM, Anthony PERARD wrote:
Hi Chuck,
On Sun, Mar 13, 2022 at 11:41:37PM -0400, Chuck Zmudzinski wrote:
When gfx_passthru is enabled for the Intel IGD, hvmloader maps the IGD
opregion to the guest but libxl does not grant the guest permission to
I'm not reading the same
On 3/31/22 10:19 AM, Jason Andryuk wrote:
On Thu, Mar 31, 2022 at 10:05 AM Chuck Zmudzinski wrote:
That still doesn't answer my question - will the Qemu upstream
accept the patches that move the hypercalls to the toolstack? If
not, we have to live with what we have now, which is tha
On 3/30/22 1:15 PM, Anthony PERARD wrote:
Hi Chuck,
On Sun, Mar 13, 2022 at 11:41:37PM -0400, Chuck Zmudzinski wrote:
When gfx_passthru is enabled for the Intel IGD, hvmloader maps the IGD
opregion to the guest but libxl does not grant the guest permission to
I'm not reading the same
On 3/31/22 2:32 PM, Chuck Zmudzinski wrote:
On 3/30/22 1:15 PM, Anthony PERARD wrote:
Hi Chuck,
On Sun, Mar 13, 2022 at 11:41:37PM -0400, Chuck Zmudzinski wrote:
When gfx_passthru is enabled for the Intel IGD, hvmloader maps the IGD
opregion to the guest but libxl does not grant the guest
On 3/30/22 2:45 PM, Jason Andryuk wrote:
On Fri, Mar 18, 2022 at 4:13 AM Jan Beulich wrote:
On 14.03.2022 04:41, Chuck Zmudzinski wrote:
When gfx_passthru is enabled for the Intel IGD, hvmloader maps the IGD
opregion to the guest but libxl does not grant the guest permission to
access the
On 4/1/22 9:21 AM, Chuck Zmudzinski wrote:
On 3/30/22 2:45 PM, Jason Andryuk wrote:
On Fri, Mar 18, 2022 at 4:13 AM Jan Beulich wrote:
On 14.03.2022 04:41, Chuck Zmudzinski wrote:
When gfx_passthru is enabled for the Intel IGD, hvmloader maps the IGD
opregion to the guest but libxl does not
On 4/1/22 9:21 AM, Chuck Zmudzinski wrote:
On 3/30/22 2:45 PM, Jason Andryuk wrote:
On Fri, Mar 18, 2022 at 4:13 AM Jan Beulich wrote:
On 14.03.2022 04:41, Chuck Zmudzinski wrote:
When gfx_passthru is enabled for the Intel IGD, hvmloader maps the IGD
opregion to the guest but libxl does
On 4/6/22 9:10 AM, Jason Andryuk wrote:
On Tue, Apr 5, 2022 at 9:31 PM Chuck Zmudzinski wrote:
Correction (sorry for the confusion):
I didn't know I needed to replace more than just a
re-built i915.ko module to enable the patch
for testing. When I updated the entire Debian kernel
pa
On 4/6/22 9:10 AM, Jason Andryuk wrote:
On Tue, Apr 5, 2022 at 9:31 PM Chuck Zmudzinski wrote:
Correction (sorry for the confusion):
I didn't know I needed to replace more than just a
re-built i915.ko module to enable the patch
for testing. When I updated the entire Debian kernel
pa
Good day,
You're looking for this document i was focusing on a week ago, i believe. Anyway, here's the url to this doc below:
https://tutiendafit.com.mx/olea/sndaem
On 3/15/22 7:38 AM, Jan Beulich wrote:
> On 14.03.2022 04:41, Chuck Zmudzinski wrote:
>> Fixes: abfb00
On 7/17/22 3:55 AM, Thorsten Leemhuis wrote:
> Hi Juergen!
>
> On 15.07.22 16:25, Juergen Gross wrote:
> > Today PAT can't be used without MTRR being available, unless MTRR is at
> > least configured via CONFIG_MTRR and the system is running as Xen PV
> > guest. In this case PAT is automatically av
On 7/19/22 11:15 AM, Borislav Petkov wrote:
> On Fri, Jul 15, 2022 at 04:25:49PM +0200, Juergen Gross wrote:
> > Today PAT is usable only with MTRR being active, with some nasty tweaks
> > to make PAT usable when running as Xen PV guest, which doesn't support
> > MTRR.
> >
> > The reason for this
On 8/13/2022 1:20 PM, Borislav Petkov wrote:
> On Sat, Aug 13, 2022 at 12:56:44PM -0400, Chuck Zmudzinski wrote:
> > Why has Juergen not at least responded in some way to the
> > comments that Boris has made here? Why has Boris not
> > pinged Juergen by now,
>
> How a
On 8/13/2022 5:48 PM, Borislav Petkov wrote:
> On Sat, Aug 13, 2022 at 05:40:34PM -0400, Chuck Zmudzinski wrote:
> > I did a search for Juergen Gross on lkml and he is active submitting and
> > reviewing patches during the past few weeks. However, he is ignoring
> > comment
On 8/13/2022 12:56 PM, Chuck Zmudzinski wrote:
> On 7/17/22 3:55 AM, Thorsten Leemhuis wrote:
> > Hi Juergen!
> >
> > On 15.07.22 16:25, Juergen Gross wrote: ...
>
> Hi Thorsten,
>
> This appears stalled again and we are now over three months
> from the firs
On 8/14/2022 3:42 AM, Chuck Zmudzinski wrote:
> On 8/13/2022 12:56 PM, Chuck Zmudzinski wrote:
> > On 7/17/22 3:55 AM, Thorsten Leemhuis wrote:
> > > Hi Juergen!
> > >
> > > On 15.07.22 16:25, Juergen Gross wrote: ...
> >
> > Hi Thorsten,
> &
On 8/14/2022 5:50 AM, Greg KH wrote:
> On Sun, Aug 14, 2022 at 05:19:12AM -0400, Chuck Zmudzinski wrote:
> > Well, that did not take long. Juergen responded with a message,
> > which is encrypted and not delivered to my mailbox because I do not
> > have the PGP keys,
On 8/14/2022 9:01 AM, Greg KH wrote:
> On Sun, Aug 14, 2022 at 08:08:30AM -0400, Chuck Zmudzinski wrote:
> > On 8/14/2022 5:50 AM, Greg KH wrote:
> > > On Sun, Aug 14, 2022 at 05:19:12AM -0400, Chuck Zmudzinski wrote:
> > > > Well, that did not take long. Ju
On 8/14/2022 9:01 AM, Greg KH wrote:
> The To: line had your address in it, so it was sent to you, and again,
> it was not encrypted as you claimed, but rather just signed to verify he
> was the sender. That's not making anything difficult for anyone, so I
> think you owe him an apology here, espe
On 8/14/22 4:08 AM, Juergen Gross wrote:
> > On 8/13/2022 12:56 PM, Chuck Zmudzinski wrote:
> >
> > This is a fairly long message but I think what I need to say
> > here is important for the future success of Linux and open
> > source software, so here goes
&
On 8/14/2022 9:01 AM, Greg KH wrote:
> On Sun, Aug 14, 2022 at 08:08:30AM -0400, Chuck Zmudzinski wrote:
> > On 8/14/2022 5:50 AM, Greg KH wrote:
> > > On Sun, Aug 14, 2022 at 05:19:12AM -0400, Chuck Zmudzinski wrote:
> > > > Well, that did not take long. Ju
On 8/15/2022 2:00 PM, Thorsten Leemhuis wrote:
> Hi Chuck!
>
> On 15.08.22 18:56, Chuck Zmudzinski wrote:
> >
> > I am forwarding this to you to help you cut through the noise.
>
> Sorry for not replying earlier, I ignored this thread and all other
> non-urgent mai
On 8/16/2022 10:41 AM, Thorsten Leemhuis wrote:
> On 15.08.22 20:17, Chuck Zmudzinski wrote:
> > On 8/15/2022 2:00 PM, Thorsten Leemhuis wrote:
> >
> >> And FWIW: I've seen indicators that a solution to resolve this is
> >> hopefully pretty close now.
> &
On 8/16/2022 12:53 PM, Thorsten Leemhuis wrote:
> On 16.08.22 18:16, Chuck Zmudzinski wrote:
> > On 8/16/2022 10:41 AM, Thorsten Leemhuis wrote:
> >> On 15.08.22 20:17, Chuck Zmudzinski wrote:
> >>> On 8/15/2022 2:00 PM, Thorsten Leemhuis wrote:
> >>>
&g
On 8/13/2022 6:41 PM, Chuck Zmudzinski wrote:
> On 8/13/2022 5:48 PM, Borislav Petkov wrote:
> > On Sat, Aug 13, 2022 at 05:40:34PM -0400, Chuck Zmudzinski wrote:
> > > I did a search for Juergen Gross on lkml and he is active submitting and
> > > reviewing patche
On 7/14/2022 10:07 PM, Chuck Zmudzinski wrote:
> On 7/14/2022 1:30 AM, Thorsten Leemhuis wrote:
>
> >
> > Sorry, have to ask: is this supposed to finally fix this regression?
> > https://lore.kernel.org/regressions/YnHK1Z3o99eMXsVK@mail-itl/
>
> Yes that's the fi
On 8/16/22 1:28 PM, Chuck Zmudzinski wrote:
> On 8/16/2022 12:53 PM, Thorsten Leemhuis wrote:
>
> >
> > regzbot will notice when the patch hit's Linux next,
>
> IIUC, regzbot might not notice because the patch lacks a Link: tag
> to the original regression report
On 1/16/23 10:33, Igor Mammedov wrote:
> On Fri, 13 Jan 2023 16:31:26 -0500
> Chuck Zmudzinski wrote:
>
>> On 1/13/23 4:33 AM, Igor Mammedov wrote:
>> > On Thu, 12 Jan 2023 23:14:26 -0500
>> > Chuck Zmudzinski wrote:
>> >
>> >> On 1/12/
On 1/17/2023 5:35 AM, Igor Mammedov wrote:
> On Mon, 16 Jan 2023 13:00:53 -0500
> Chuck Zmudzinski wrote:
>
> > On 1/16/23 10:33, Igor Mammedov wrote:
> > > On Fri, 13 Jan 2023 16:31:26 -0500
> > > Chuck Zmudzinski wrote:
> > >
> > >> On 1
On 1/17/2023 5:35 AM, Igor Mammedov wrote:
> On Mon, 16 Jan 2023 13:00:53 -0500
> Chuck Zmudzinski wrote:
>
> > On 1/16/23 10:33, Igor Mammedov wrote:
> > > On Fri, 13 Jan 2023 16:31:26 -0500
> > > Chuck Zmudzinski wrote:
> > >
> > >> On 1
On 1/17/2023 6:04 AM, Igor Mammedov wrote:
> On Mon, 16 Jan 2023 13:00:53 -0500
> Chuck Zmudzinski wrote:
>
> > On 1/16/23 10:33, Igor Mammedov wrote:
> > > On Fri, 13 Jan 2023 16:31:26 -0500
> > > Chuck Zmudzinski wrote:
> > >
> > >> On 1
On 1/17/2023 11:27 PM, Alex Williamson wrote:
> On Tue, 17 Jan 2023 19:15:57 -0500
> Chuck Zmudzinski wrote:
>
> > On 1/17/2023 6:04 AM, Igor Mammedov wrote:
> > > On Mon, 16 Jan 2023 13:00:53 -0500
> > > Chuck Zmudzinski wrote:
> > >
>
On 1/20/2023 11:57 AM, Stefano Stabellini wrote:
> On Tue, 17 Jan 2023, Chuck Zmudzinski wrote:
> > On 1/17/2023 6:04 AM, Igor Mammedov wrote:
> > > On Mon, 16 Jan 2023 13:00:53 -0500
> > > Chuck Zmudzinski wrote:
> > >
> > > > On 1/16/23 10:33, Ig
On 1/20/2023 11:01 AM, Igor Mammedov wrote:
> On Tue, 17 Jan 2023 09:50:23 -0500
> Chuck Zmudzinski wrote:
>
> > On 1/17/2023 5:35 AM, Igor Mammedov wrote:
> > > On Mon, 16 Jan 2023 13:00:53 -0500
> > > Chuck Zmudzinski wrote:
> > >
> > > >
On 1/20/23 4:34 PM, Stefano Stabellini wrote:
> On Sat, 14 Jan 2023, Chuck Zmudzinski wrote:
> > Intel specifies that the Intel IGD must occupy slot 2 on the PCI bus,
> > as noted in docs/igd-assign.txt in the Qemu source code.
> >
> > Currently, when the xl toolstack
t,
and function values as well as by checking that gfx_passthru is enabled,
the device class is VGA, and the device vendor in Intel.
Signed-off-by: Chuck Zmudzinski
---
Notes that might be helpful to reviewers of patched code in hw/xen:
The new functions and types are based on reco
On 1/20/2023 4:34 PM, Stefano Stabellini wrote:
> On Sat, 14 Jan 2023, Chuck Zmudzinski wrote:
> > Intel specifies that the Intel IGD must occupy slot 2 on the PCI bus,
> > as noted in docs/igd-assign.txt in the Qemu source code.
> >
> > Currently, when the xl toolstack
On 1/6/2023 9:03 AM, Anthony PERARD wrote:
> On Sun, Jan 01, 2023 at 06:52:03PM -0500, Chuck Zmudzinski wrote:
> > Intel specifies that the Intel IGD must occupy slot 2 on the PCI bus,
> > as noted in docs/igd-assign.txt in the Qemu source code.
> >
> > Currently, when
t,
and function values as well as by checking that gfx_passthru is enabled,
the device class is VGA, and the device vendor in Intel.
Signed-off-by: Chuck Zmudzinski
---
Notes that might be helpful to reviewers of patched code in hw/xen:
The new functions and types are based on reco
On 1/21/23 1:06 PM, Chuck Zmudzinski wrote:
> On 1/6/2023 9:03 AM, Anthony PERARD wrote:
>> On Sun, Jan 01, 2023 at 06:52:03PM -0500, Chuck Zmudzinski wrote:
>> > Intel specifies that the Intel IGD must occupy slot 2 on the PCI bus,
>> > as noted in docs/igd-assign.
On 1/22/23 3:40 AM, Michael S. Tsirkin wrote:
> On Sat, Jan 21, 2023 at 07:57:02PM -0500, Chuck Zmudzinski wrote:
>> Intel specifies that the Intel IGD must occupy slot 2 on the PCI bus,
>> as noted in docs/igd-assign.txt in the Qemu source code.
>>
>> Currently, when
On 1/25/2023 6:37 AM, Anthony PERARD wrote:
> On Tue, Jan 10, 2023 at 02:32:01AM -0500, Chuck Zmudzinski wrote:
> > I call attention to the commit message of the first patch which points
> > out that using the "pc" machine and adding the xen platform device on
> > th
On 1/25/2023 6:37 AM, Anthony PERARD wrote:
> On Tue, Jan 10, 2023 at 02:32:01AM -0500, Chuck Zmudzinski wrote:
> > I call attention to the commit message of the first patch which points
> > out that using the "pc" machine and adding the xen platform device on
> > th
On 1/25/23 6:19 PM, Chuck Zmudzinski wrote:
> On 1/25/2023 6:37 AM, Anthony PERARD wrote:
>> On Tue, Jan 10, 2023 at 02:32:01AM -0500, Chuck Zmudzinski wrote:
>> > I call attention to the commit message of the first patch which points
>> > out that using the &quo
On 1/29/23 7:38 PM, Chuck Zmudzinski wrote:
> On 1/25/23 6:19 PM, Chuck Zmudzinski wrote:
>> On 1/25/2023 6:37 AM, Anthony PERARD wrote:
>>> On Tue, Jan 10, 2023 at 02:32:01AM -0500, Chuck Zmudzinski wrote:
>>> > I call attention to the commit message of the first pat
the
sysemu/xen.h header file as the test to determine whether or not
to use the igd-passthrough-i440FX pci host device instead of the
normal i440FX pci host device.
Fixes: 998250e97661 ("xen, gfx passthrough: register host bridge specific to
passthrough")
Signed-off-by: Chuck Zmudzinsk
uot; machine to the "pc" machine
but there is no degredation in performance, just a possible need
to reset the display resolution to the desired value.
Signed-off-by: Chuck Zmudzinski
---
Sorry about how long this discussion is, but it is helpful to again
bring together all the con
capability of the device in Linux guests with the end
result being that the Linux guest never completes the boot process.
Fixes: 2e87512eccf3
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1061
Buglink: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988333
Signed-off-by: Chuck Zmudzinski
the vendor be Intel,
because only Intel IGD devices have an Intel OpRegion. These are the
same checks hvmloader and libxl do to determine if the Intel OpRegion
needs to be mapped into the guest's memory.
Signed-off-by: Chuck Zmudzinski
---
hw/xen/xen_pt_config_init.c | 4
1 file chang
://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988333
Signed-off-by: Chuck Zmudzinski
---
v2: Edit the commit message to more accurately describe the cause
of the error.
hw/xen/xen_pt_config_init.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/xen/xen_pt_config_init.c b
lying this patch.
Signed-off-by: Chuck Zmudzinski
---
v2: * Move the comment to an appropriate place after applying this patch
* Mention that the comment is moved in the commit message
v2 addresses the comment by Anthony Perard on the original
version of this patch.
hw/xen/xen_pt_config_i
On 6/17/22 9:07 AM, Anthony PERARD wrote:
On Fri, Jun 10, 2022 at 12:23:35PM -0400, Chuck Zmudzinski wrote:
Currently we are creating a register group for the Intel IGD OpRegion
for every device we pass through, but the XEN_PCI_INTEL_OPREGION
register group is only valid for an Intel IGD. Add a
On 6/17/22 9:46 AM, Anthony PERARD wrote:
On Thu, Mar 31, 2022 at 03:44:33PM -0400, Chuck Zmudzinski wrote:
On 3/31/22 10:19 AM, Jason Andryuk wrote:
On Thu, Mar 31, 2022 at 10:05 AM Chuck Zmudzinski wrote:
That still doesn't answer my question - will the Qemu upstream
accept the pa
lying this patch.
Signed-off-by: Chuck Zmudzinski
Reviewed-by: Anthony PERARD
---
v2: * Move the comment to an appropriate place after applying this patch
* Mention that the comment is moved in the commit message
v2 addresses the comment by Anthony Perard on the original
version of this patch
://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988333
Signed-off-by: Chuck Zmudzinski
Reviewed-by: Anthony PERARD
---
v2: Edit the commit message to more accurately describe the cause
of the error.
v3: * Add Reviewed-By: Anthony Perard
* Add qemu-sta...@nongnu.org to recipients to indicate the
gitlab.com/qemu-project/qemu/-/issues/1061
Buglink: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988333
Signed-off-by: Chuck Zmudzinski
Reviewed-by: Anthony PERARD
---
v2: Edit the commit message to more accurately describe the cause
of the error.
v3: * Add Reviewed-By: Anthony Perard
On 7/5/22 12:14 PM, Borislav Petkov wrote:
> On Tue, Jul 05, 2022 at 05:56:36PM +0200, Jan Beulich wrote:
> > Re-using pat_disabled like you do in your suggestion below won't
> > work, because mtrr_bp_init() calls pat_disable() when MTRRs
> > appear to be disabled (from the kernel's view). The goal
On 7/5/22 12:14 PM, Borislav Petkov wrote:
> On Tue, Jul 05, 2022 at 05:56:36PM +0200, Jan Beulich wrote:
> > Re-using pat_disabled like you do in your suggestion below won't
> > work, because mtrr_bp_init() calls pat_disable() when MTRRs
> > appear to be disabled (from the kernel's view). The goal
On 7/5/22 12:14 PM, Borislav Petkov wrote:
> On Tue, Jul 05, 2022 at 05:56:36PM +0200, Jan Beulich wrote:
> > Re-using pat_disabled like you do in your suggestion below won't
> > work, because mtrr_bp_init() calls pat_disable() when MTRRs
> > appear to be disabled (from the kernel's view). The goal
On 7/11/2022 10:31 AM, Juergen Gross wrote:
> On 11.07.22 16:18, Chuck Zmudzinski wrote:
> > On 7/5/22 12:14 PM, Borislav Petkov wrote:
> >> On Tue, Jul 05, 2022 at 05:56:36PM +0200, Jan Beulich wrote:
> >>> Re-using pat_disabled like you do in your suggestion b
On 7/12/2022 2:04 AM, Jan Beulich wrote:
> On 11.07.2022 19:41, Chuck Zmudzinski wrote:
> > Moreover... (please move to the bottom of the code snippet
> > for more information about my tests in the Xen PV environment...)
> >
> > void init_cache_modes(void
On 7/12/2022 9:32 AM, Juergen Gross wrote:
> On 12.07.22 15:22, Chuck Zmudzinski wrote:
> > On 7/12/2022 2:04 AM, Jan Beulich wrote:
> >> On 11.07.2022 19:41, Chuck Zmudzinski wrote:
> >>> Moreover... (please move to the bottom of the code snippet
> >>>
On 7/12/22 11:30 AM, Juergen Gross wrote:
> On 12.07.22 17:09, Chuck Zmudzinski wrote:
> > On 7/12/2022 9:32 AM, Juergen Gross wrote:
> >> On 12.07.22 15:22, Chuck Zmudzinski wrote:
> >>> On 7/12/2022 2:04 AM, Jan Beulich wrote:
> >>>>
t support it")
Cc: sta...@vger.kernel.org
Signed-off-by: Chuck Zmudzinski
---
Reminder: This patch is a regression fix that is needed on stable
versions 5.17 and later.
arch/x86/mm/pat/memtype.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/x86/mm/pat/memtype.c
On 7/12/22 2:36 PM, Greg KH wrote:
> On Tue, Jul 12, 2022 at 02:20:37PM -0400, Chuck Zmudzinski wrote:
> > The commit 99c13b8c8896d7bcb92753bf
> > ("x86/mm/pat: Don't report PAT on CPUs that don't support it")
> > incorrectly failed to account for the ca
On 7/12/22 2:27 PM, Juergen Gross wrote:
> On 12.07.22 20:20, Chuck Zmudzinski wrote:
> > The commit 99c13b8c8896d7bcb92753bf
> > ("x86/mm/pat: Don't report PAT on CPUs that don't support it")
> > incorrectly failed to account for the case in init_cache
On 7/12/22 3:18 PM, Chuck Zmudzinski wrote:
> On 7/12/22 2:27 PM, Juergen Gross wrote:
> > On 12.07.22 20:20, Chuck Zmudzinski wrote:
> > > The commit 99c13b8c8896d7bcb92753bf
> > > ("x86/mm/pat: Don't report PAT on CPUs that don't support it")
&
On 7/12/22 3:26 PM, Greg KH wrote:
> On Tue, Jul 12, 2022 at 03:16:01PM -0400, Chuck Zmudzinski wrote:
> > On 7/12/22 2:36 PM, Greg KH wrote:
> > > On Tue, Jul 12, 2022 at 02:20:37PM -0400, Chuck Zmudzinski wrote:
> > > > The commit 99c13b8c8896d7bcb92753bf
> >
des() also needs
moving to .init.text (where it could/should have lived already before).
Fixes: 99c13b8c8896d7bcb92753bf ("x86/mm/pat: Don't report PAT on CPUs that
don't support it")
Co-developed-by: Jan Beulich
Cc: sta...@vger.kernel.org
Signed-off-by: Chuck Zmudzinski
---
v2:
On 7/13/22 2:18 AM, Jan Beulich wrote:
> On 13.07.2022 03:36, Chuck Zmudzinski wrote:
> > v2: *Add force_pat_disabled variable to fix "nopat" on Xen PV (Jan Beulich)
> > *Add the necessary code to incorporate the "nopat" fix
> > *void init_cache_mo
On 7/13/2022 5:09 AM, Jan Beulich wrote:
> On 13.07.2022 10:51, Chuck Zmudzinski wrote:
> > On 7/13/22 2:18 AM, Jan Beulich wrote:
> >> On 13.07.2022 03:36, Chuck Zmudzinski wrote:
> >>> v2: *Add force_pat_disabled variable to fix "nopat" on Xen PV (Jan
>
On 7/13/2022 6:36 AM, Chuck Zmudzinski wrote:
> On 7/13/2022 5:09 AM, Jan Beulich wrote:
> > On 13.07.2022 10:51, Chuck Zmudzinski wrote:
> > > On 7/13/22 2:18 AM, Jan Beulich wrote:
> > >> On 13.07.2022 03:36, Chuck Zmudzinski wrote:
> > >>> v2: *Add
On 7/13/2022 9:34 AM, Jan Beulich wrote:
> On 13.07.2022 13:10, Chuck Zmudzinski wrote:
> > On 7/13/2022 6:36 AM, Chuck Zmudzinski wrote:
> >> On 7/13/2022 5:09 AM, Jan Beulich wrote:
> >>> On 13.07.2022 10:51, Chuck Zmudzinski wrote:
> >>>> On 7
On 7/13/2022 9:52 AM, Jan Beulich wrote:
> On 13.07.2022 15:49, Chuck Zmudzinski wrote:
> > On 7/13/2022 9:34 AM, Jan Beulich wrote:
> >> On 13.07.2022 13:10, Chuck Zmudzinski wrote:
> >>> On 7/13/2022 6:36 AM, Chuck Zmudzinski wrote:
> >>>> On 7/1
On 7/13/2022 9:45 AM, Juergen Gross wrote:
> On 13.07.22 15:34, Jan Beulich wrote:
> > On 13.07.2022 13:10, Chuck Zmudzinski wrote:
> >> On 7/13/2022 6:36 AM, Chuck Zmudzinski wrote:
> >>> On 7/13/2022 5:09 AM, Jan Beulich wrote:
> >>>> On 13.07.2022 1
On 7/13/2022 9:45 AM, Juergen Gross wrote:
> >> On 7/13/2022 6:36 AM, Chuck Zmudzinski wrote:
> >> And in addition, if we are going to backport this patch to
> >> all current stable branches, we better have a really, really,
> >> good reason for cha
On 7/13/2022 3:07 PM, Chuck Zmudzinski wrote:
> On 7/13/2022 9:45 AM, Juergen Gross wrote:
> > >> On 7/13/2022 6:36 AM, Chuck Zmudzinski wrote:
> > >> And in addition, if we are going to backport this patch to
> > >> all current stable branches, we better ha
On 7/13/2022 3:22 PM, Chuck Zmudzinski wrote:
> On 7/13/2022 3:07 PM, Chuck Zmudzinski wrote:
> > On 7/13/2022 9:45 AM, Juergen Gross wrote:
> > > >> On 7/13/2022 6:36 AM, Chuck Zmudzinski wrote:
> > > >> And in addition, if we are going to backport th
On 7/13/2022 9:45 AM, Juergen Gross wrote:
> On 13.07.22 15:34, Jan Beulich wrote:
> > On 13.07.2022 13:10, Chuck Zmudzinski wrote:
> >> On 7/13/2022 6:36 AM, Chuck Zmudzinski wrote:
> >>> On 7/13/2022 5:09 AM, Jan Beulich wrote:
> >>>> On 13.07.2022 1
On 7/5/22 6:57 AM, Thorsten Leemhuis wrote:
> [CCing tglx, mingo, Boris and Juergen]
>
> On 04.07.22 14:26, Jan Beulich wrote:
> > On 04.07.2022 13:58, Thorsten Leemhuis wrote:
> >> On 25.05.22 10:55, Jan Beulich wrote:
> >>> On 28.04.2022 16:50, Jan Beulich wrote:
> The latest with commit bdd
On 7/14/2022 1:17 PM, Chuck Zmudzinski wrote:
> On 7/5/22 6:57 AM, Thorsten Leemhuis wrote:
> > [CCing tglx, mingo, Boris and Juergen]
> >
> > On 04.07.22 14:26, Jan Beulich wrote:
> > > On 04.07.2022 13:58, Thorsten Leemhuis wrote:
> > >> On 25.
On 7/14/2022 6:33 PM, Chuck Zmudzinski wrote:
> On 7/14/2022 1:17 PM, Chuck Zmudzinski wrote:
> > On 7/5/22 6:57 AM, Thorsten Leemhuis wrote:
> > > [CCing tglx, mingo, Boris and Juergen]
> > >
> > > On 04.07.22 14:26, Jan Beulich wrote:
> > > &
On 7/14/2022 1:30 AM, Thorsten Leemhuis wrote:
> On 13.07.22 03:36, Chuck Zmudzinski wrote:
> > The commit 99c13b8c8896d7bcb92753bf
> > ("x86/mm/pat: Don't report PAT on CPUs that don't support it")
> > incorrectly failed to account for the case in init_c
On 7/14/2022 1:40 AM, Juergen Gross wrote:
> On 13.07.22 03:36, Chuck Zmudzinski wrote:
> > The commit 99c13b8c8896d7bcb92753bf
> > ("x86/mm/pat: Don't report PAT on CPUs that don't support it")
> > incorrectly failed to account for the case in init_cache
1 - 100 of 233 matches
Mail list logo
