[Kernel-packages] [Bug 1908569] Re: video: hyperv_fb: Fix the cache type when mapping the VRAM
This fix was already released to -updates via upstream stable updates to
the following Azure kernel versions:
4.15.0-1108.120
5.4.0-1040.42
5.8.0-1023.25
** Changed in: linux-azure (Ubuntu Focal)
Status: Fix Committed => Fix Released
** Changed in: linux-azure-4.15 (Ubuntu Bionic)
Status: Fix Committed => Fix Released
** Changed in: linux-azure (Ubuntu Groovy)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-azure in Ubuntu.
https://bugs.launchpad.net/bugs/1908569
Title:
video: hyperv_fb: Fix the cache type when mapping the VRAM
Status in linux-azure package in Ubuntu:
New
Status in linux-azure-4.15 package in Ubuntu:
New
Status in linux-azure source package in Bionic:
Invalid
Status in linux-azure-4.15 source package in Bionic:
Fix Released
Status in linux-azure source package in Focal:
Fix Released
Status in linux-azure-4.15 source package in Focal:
Invalid
Status in linux-azure source package in Groovy:
Fix Released
Status in linux-azure-4.15 source package in Groovy:
Invalid
Bug description:
[Impact]
We identified a problem that is causing slow logging to the console
for customers.
The following commit resolves this issue as well as other cache relates
issues:
325073ae3485 ("video: hyperv_fb: Fix the cache type when mapping the VRAM")
(marcelo.cerri: it's actually commit id
5f1251a48c17b54939d7477305e39679a565382c in the mainline kernel)
Patch details from it's commit message:
x86 Hyper-V used to essentially always overwrite the effective cache type
of guest memory accesses to WB. This was problematic in cases where there
is a physical device assigned to the VM, since that often requires that
the VM should have control over cache types. Thus, on newer Hyper-V since
2018, Hyper-V always honors the VM's cache type, but unexpectedly Linux VM
users start to complain that Linux VM's VRAM becomes very slow, and it
turns out that Linux VM should not map the VRAM uncacheable by ioremap().
Fix this slowness issue by using ioremap_cache().
With this change, the VRAM on new Hyper-V is as fast as regular RAM, so
it's no longer necessary to use the hacks we added to mitigate the
slowness, i.e. we no longer need to allocate physical memory and use
it to back up the VRAM in Generation-1 VM, and we also no longer need to
allocate physical memory to back up the framebuffer in a Generation-2 VM
and copy the framebuffer to the real VRAM. A further big change will
address these for v5.11.
Microsoft would like to request this patch in all supported releases.
[Test Case]
The test is very simple. When using the console in a local Hyper-V
instance and running a command with output with several lines (ie `ls
-l /`) the output delay is very noticeable and it should be
instantaneous with the fix.
[Where problems could occur]
The change might cause regressions in the hyperv_fb driver, affecting
one of the alternatives users have to debug problems.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1908569/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1908569] Re: video: hyperv_fb: Fix the cache type when mapping the VRAM
** Changed in: linux-azure-4.15 (Ubuntu Bionic)
Status: In Progress => Fix Committed
** Changed in: linux-azure (Ubuntu Focal)
Status: In Progress => Fix Committed
** Changed in: linux-azure (Ubuntu Groovy)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-azure in Ubuntu.
https://bugs.launchpad.net/bugs/1908569
Title:
video: hyperv_fb: Fix the cache type when mapping the VRAM
Status in linux-azure package in Ubuntu:
New
Status in linux-azure-4.15 package in Ubuntu:
New
Status in linux-azure source package in Bionic:
Invalid
Status in linux-azure-4.15 source package in Bionic:
Fix Committed
Status in linux-azure source package in Focal:
Fix Committed
Status in linux-azure-4.15 source package in Focal:
Invalid
Status in linux-azure source package in Groovy:
Fix Committed
Status in linux-azure-4.15 source package in Groovy:
Invalid
Bug description:
[Impact]
We identified a problem that is causing slow logging to the console
for customers.
The following commit resolves this issue as well as other cache relates
issues:
325073ae3485 ("video: hyperv_fb: Fix the cache type when mapping the VRAM")
(marcelo.cerri: it's actually commit id
5f1251a48c17b54939d7477305e39679a565382c in the mainline kernel)
Patch details from it's commit message:
x86 Hyper-V used to essentially always overwrite the effective cache type
of guest memory accesses to WB. This was problematic in cases where there
is a physical device assigned to the VM, since that often requires that
the VM should have control over cache types. Thus, on newer Hyper-V since
2018, Hyper-V always honors the VM's cache type, but unexpectedly Linux VM
users start to complain that Linux VM's VRAM becomes very slow, and it
turns out that Linux VM should not map the VRAM uncacheable by ioremap().
Fix this slowness issue by using ioremap_cache().
With this change, the VRAM on new Hyper-V is as fast as regular RAM, so
it's no longer necessary to use the hacks we added to mitigate the
slowness, i.e. we no longer need to allocate physical memory and use
it to back up the VRAM in Generation-1 VM, and we also no longer need to
allocate physical memory to back up the framebuffer in a Generation-2 VM
and copy the framebuffer to the real VRAM. A further big change will
address these for v5.11.
Microsoft would like to request this patch in all supported releases.
[Test Case]
The test is very simple. When using the console in a local Hyper-V
instance and running a command with output with several lines (ie `ls
-l /`) the output delay is very noticeable and it should be
instantaneous with the fix.
[Where problems could occur]
The change might cause regressions in the hyperv_fb driver, affecting
one of the alternatives users have to debug problems.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1908569/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1908569] Re: video: hyperv_fb: Fix the cache type when mapping the VRAM
** Changed in: linux-azure-4.15 (Ubuntu Bionic)
Importance: Undecided => Medium
** Changed in: linux-azure (Ubuntu Groovy)
Importance: Undecided => Medium
** Changed in: linux-azure (Ubuntu Focal)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-azure in Ubuntu.
https://bugs.launchpad.net/bugs/1908569
Title:
video: hyperv_fb: Fix the cache type when mapping the VRAM
Status in linux-azure package in Ubuntu:
New
Status in linux-azure-4.15 package in Ubuntu:
New
Status in linux-azure source package in Bionic:
Invalid
Status in linux-azure-4.15 source package in Bionic:
In Progress
Status in linux-azure source package in Focal:
In Progress
Status in linux-azure-4.15 source package in Focal:
Invalid
Status in linux-azure source package in Groovy:
In Progress
Status in linux-azure-4.15 source package in Groovy:
Invalid
Bug description:
[Impact]
We identified a problem that is causing slow logging to the console
for customers.
The following commit resolves this issue as well as other cache relates
issues:
325073ae3485 ("video: hyperv_fb: Fix the cache type when mapping the VRAM")
(marcelo.cerri: it's actually commit id
5f1251a48c17b54939d7477305e39679a565382c in the mainline kernel)
Patch details from it's commit message:
x86 Hyper-V used to essentially always overwrite the effective cache type
of guest memory accesses to WB. This was problematic in cases where there
is a physical device assigned to the VM, since that often requires that
the VM should have control over cache types. Thus, on newer Hyper-V since
2018, Hyper-V always honors the VM's cache type, but unexpectedly Linux VM
users start to complain that Linux VM's VRAM becomes very slow, and it
turns out that Linux VM should not map the VRAM uncacheable by ioremap().
Fix this slowness issue by using ioremap_cache().
With this change, the VRAM on new Hyper-V is as fast as regular RAM, so
it's no longer necessary to use the hacks we added to mitigate the
slowness, i.e. we no longer need to allocate physical memory and use
it to back up the VRAM in Generation-1 VM, and we also no longer need to
allocate physical memory to back up the framebuffer in a Generation-2 VM
and copy the framebuffer to the real VRAM. A further big change will
address these for v5.11.
Microsoft would like to request this patch in all supported releases.
[Test Case]
The test is very simple. When using the console in a local Hyper-V
instance and running a command with output with several lines (ie `ls
-l /`) the output delay is very noticeable and it should be
instantaneous with the fix.
[Where problems could occur]
The change might cause regressions in the hyperv_fb driver, affecting
one of the alternatives users have to debug problems.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1908569/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1908569] Re: video: hyperv_fb: Fix the cache type when mapping the VRAM
SRU submission: https://lists.ubuntu.com/archives/kernel-
team/2021-January/116548.html
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-azure in Ubuntu.
https://bugs.launchpad.net/bugs/1908569
Title:
video: hyperv_fb: Fix the cache type when mapping the VRAM
Status in linux-azure package in Ubuntu:
New
Status in linux-azure-4.15 package in Ubuntu:
New
Status in linux-azure source package in Bionic:
Invalid
Status in linux-azure-4.15 source package in Bionic:
In Progress
Status in linux-azure source package in Focal:
In Progress
Status in linux-azure-4.15 source package in Focal:
Invalid
Status in linux-azure source package in Groovy:
In Progress
Status in linux-azure-4.15 source package in Groovy:
Invalid
Bug description:
[Impact]
We identified a problem that is causing slow logging to the console
for customers.
The following commit resolves this issue as well as other cache relates
issues:
325073ae3485 ("video: hyperv_fb: Fix the cache type when mapping the VRAM")
(marcelo.cerri: it's actually commit id
5f1251a48c17b54939d7477305e39679a565382c in the mainline kernel)
Patch details from it's commit message:
x86 Hyper-V used to essentially always overwrite the effective cache type
of guest memory accesses to WB. This was problematic in cases where there
is a physical device assigned to the VM, since that often requires that
the VM should have control over cache types. Thus, on newer Hyper-V since
2018, Hyper-V always honors the VM's cache type, but unexpectedly Linux VM
users start to complain that Linux VM's VRAM becomes very slow, and it
turns out that Linux VM should not map the VRAM uncacheable by ioremap().
Fix this slowness issue by using ioremap_cache().
With this change, the VRAM on new Hyper-V is as fast as regular RAM, so
it's no longer necessary to use the hacks we added to mitigate the
slowness, i.e. we no longer need to allocate physical memory and use
it to back up the VRAM in Generation-1 VM, and we also no longer need to
allocate physical memory to back up the framebuffer in a Generation-2 VM
and copy the framebuffer to the real VRAM. A further big change will
address these for v5.11.
Microsoft would like to request this patch in all supported releases.
[Test Case]
The test is very simple. When using the console in a local Hyper-V
instance and running a command with output with several lines (ie `ls
-l /`) the output delay is very noticeable and it should be
instantaneous with the fix.
[Where problems could occur]
The change might cause regressions in the hyperv_fb driver, affecting
one of the alternatives users have to debug problems.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1908569/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1908569] Re: video: hyperv_fb: Fix the cache type when mapping the VRAM
** Changed in: linux-azure (Ubuntu Focal)
Status: New => In Progress
** Changed in: linux-azure-4.15 (Ubuntu Bionic)
Status: New => In Progress
** Changed in: linux-azure (Ubuntu Groovy)
Status: New => In Progress
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-azure in Ubuntu.
https://bugs.launchpad.net/bugs/1908569
Title:
video: hyperv_fb: Fix the cache type when mapping the VRAM
Status in linux-azure package in Ubuntu:
New
Status in linux-azure-4.15 package in Ubuntu:
New
Status in linux-azure source package in Bionic:
Invalid
Status in linux-azure-4.15 source package in Bionic:
In Progress
Status in linux-azure source package in Focal:
In Progress
Status in linux-azure-4.15 source package in Focal:
Invalid
Status in linux-azure source package in Groovy:
In Progress
Status in linux-azure-4.15 source package in Groovy:
Invalid
Bug description:
[Impact]
We identified a problem that is causing slow logging to the console
for customers.
The following commit resolves this issue as well as other cache relates
issues:
325073ae3485 ("video: hyperv_fb: Fix the cache type when mapping the VRAM")
(marcelo.cerri: it's actually commit id
5f1251a48c17b54939d7477305e39679a565382c in the mainline kernel)
Patch details from it's commit message:
x86 Hyper-V used to essentially always overwrite the effective cache type
of guest memory accesses to WB. This was problematic in cases where there
is a physical device assigned to the VM, since that often requires that
the VM should have control over cache types. Thus, on newer Hyper-V since
2018, Hyper-V always honors the VM's cache type, but unexpectedly Linux VM
users start to complain that Linux VM's VRAM becomes very slow, and it
turns out that Linux VM should not map the VRAM uncacheable by ioremap().
Fix this slowness issue by using ioremap_cache().
With this change, the VRAM on new Hyper-V is as fast as regular RAM, so
it's no longer necessary to use the hacks we added to mitigate the
slowness, i.e. we no longer need to allocate physical memory and use
it to back up the VRAM in Generation-1 VM, and we also no longer need to
allocate physical memory to back up the framebuffer in a Generation-2 VM
and copy the framebuffer to the real VRAM. A further big change will
address these for v5.11.
Microsoft would like to request this patch in all supported releases.
[Test Case]
The test is very simple. When using the console in a local Hyper-V
instance and running a command with output with several lines (ie `ls
-l /`) the output delay is very noticeable and it should be
instantaneous with the fix.
[Where problems could occur]
The change might cause regressions in the hyperv_fb driver, affecting
one of the alternatives users have to debug problems.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1908569/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1908569] Re: video: hyperv_fb: Fix the cache type when mapping the VRAM
** Description changed:
+ [Impact]
+
We identified a problem that is causing slow logging to the console for
customers.
The following commit resolves this issue as well as other cache relates
issues:
325073ae3485 ("video: hyperv_fb: Fix the cache type when mapping the VRAM")
(marcelo.cerri: it's actually commit id
5f1251a48c17b54939d7477305e39679a565382c in the mainline kernel)
Patch details from it's commit message:
x86 Hyper-V used to essentially always overwrite the effective cache type
of guest memory accesses to WB. This was problematic in cases where there
is a physical device assigned to the VM, since that often requires that
the VM should have control over cache types. Thus, on newer Hyper-V since
2018, Hyper-V always honors the VM's cache type, but unexpectedly Linux VM
users start to complain that Linux VM's VRAM becomes very slow, and it
turns out that Linux VM should not map the VRAM uncacheable by ioremap().
Fix this slowness issue by using ioremap_cache().
With this change, the VRAM on new Hyper-V is as fast as regular RAM, so
it's no longer necessary to use the hacks we added to mitigate the
slowness, i.e. we no longer need to allocate physical memory and use
it to back up the VRAM in Generation-1 VM, and we also no longer need to
allocate physical memory to back up the framebuffer in a Generation-2 VM
and copy the framebuffer to the real VRAM. A further big change will
address these for v5.11.
Microsoft would like to request this patch in all supported releases.
+
+ [Test Case]
+
+ The test is very simple. When using the console in a local Hyper-V
+ instance and running a command with output with several lines (ie `ls -l
+ /`) the output delay is very noticeable and it should be instantaneous
+ with the fix.
+
+ [Where problems could occur]
+
+ The change might cause regressions in the hyperv_fb driver, affecting
+ one of the alternatives users have to debug problems.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-azure in Ubuntu.
https://bugs.launchpad.net/bugs/1908569
Title:
video: hyperv_fb: Fix the cache type when mapping the VRAM
Status in linux-azure package in Ubuntu:
New
Status in linux-azure-4.15 package in Ubuntu:
New
Status in linux-azure source package in Bionic:
Invalid
Status in linux-azure-4.15 source package in Bionic:
New
Status in linux-azure source package in Focal:
New
Status in linux-azure-4.15 source package in Focal:
Invalid
Status in linux-azure source package in Groovy:
New
Status in linux-azure-4.15 source package in Groovy:
Invalid
Bug description:
[Impact]
We identified a problem that is causing slow logging to the console
for customers.
The following commit resolves this issue as well as other cache relates
issues:
325073ae3485 ("video: hyperv_fb: Fix the cache type when mapping the VRAM")
(marcelo.cerri: it's actually commit id
5f1251a48c17b54939d7477305e39679a565382c in the mainline kernel)
Patch details from it's commit message:
x86 Hyper-V used to essentially always overwrite the effective cache type
of guest memory accesses to WB. This was problematic in cases where there
is a physical device assigned to the VM, since that often requires that
the VM should have control over cache types. Thus, on newer Hyper-V since
2018, Hyper-V always honors the VM's cache type, but unexpectedly Linux VM
users start to complain that Linux VM's VRAM becomes very slow, and it
turns out that Linux VM should not map the VRAM uncacheable by ioremap().
Fix this slowness issue by using ioremap_cache().
With this change, the VRAM on new Hyper-V is as fast as regular RAM, so
it's no longer necessary to use the hacks we added to mitigate the
slowness, i.e. we no longer need to allocate physical memory and use
it to back up the VRAM in Generation-1 VM, and we also no longer need to
allocate physical memory to back up the framebuffer in a Generation-2 VM
and copy the framebuffer to the real VRAM. A further big change will
address these for v5.11.
Microsoft would like to request this patch in all supported releases.
[Test Case]
The test is very simple. When using the console in a local Hyper-V
instance and running a command with output with several lines (ie `ls
-l /`) the output delay is very noticeable and it should be
instantaneous with the fix.
[Where problems could occur]
The change might cause regressions in the hyperv_fb driver, affecting
one of the alternatives users have to debug problems.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1908569/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1908569] Re: video: hyperv_fb: Fix the cache type when mapping the VRAM
** Description changed:
We identified a problem that is causing slow logging to the console for
customers.
The following commit resolves this issue as well as other cache relates
issues:
325073ae3485 ("video: hyperv_fb: Fix the cache type when mapping the VRAM")
+
+ (marcelo.cerri: it's actually commit id
+ 5f1251a48c17b54939d7477305e39679a565382c in the mainline kernel)
Patch details from it's commit message:
x86 Hyper-V used to essentially always overwrite the effective cache type
of guest memory accesses to WB. This was problematic in cases where there
is a physical device assigned to the VM, since that often requires that
the VM should have control over cache types. Thus, on newer Hyper-V since
2018, Hyper-V always honors the VM's cache type, but unexpectedly Linux VM
users start to complain that Linux VM's VRAM becomes very slow, and it
turns out that Linux VM should not map the VRAM uncacheable by ioremap().
Fix this slowness issue by using ioremap_cache().
With this change, the VRAM on new Hyper-V is as fast as regular RAM, so
it's no longer necessary to use the hacks we added to mitigate the
slowness, i.e. we no longer need to allocate physical memory and use
it to back up the VRAM in Generation-1 VM, and we also no longer need to
allocate physical memory to back up the framebuffer in a Generation-2 VM
and copy the framebuffer to the real VRAM. A further big change will
address these for v5.11.
-
Microsoft would like to request this patch in all supported releases.
** Also affects: linux-azure (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: linux-azure (Ubuntu Groovy)
Importance: Undecided
Status: New
** Also affects: linux-azure (Ubuntu Focal)
Importance: Undecided
Status: New
** Changed in: linux-azure (Ubuntu)
Assignee: (unassigned) => Marcelo Cerri (mhcerri)
** Changed in: linux-azure (Ubuntu Focal)
Assignee: (unassigned) => Marcelo Cerri (mhcerri)
** Changed in: linux-azure (Ubuntu Groovy)
Assignee: (unassigned) => Marcelo Cerri (mhcerri)
** Also affects: linux-azure-4.15 (Ubuntu)
Importance: Undecided
Status: New
** Changed in: linux-azure-4.15 (Ubuntu)
Assignee: (unassigned) => Marcelo Cerri (mhcerri)
** Changed in: linux-azure (Ubuntu Bionic)
Status: New => Invalid
** Changed in: linux-azure-4.15 (Ubuntu Focal)
Status: New => Invalid
** Changed in: linux-azure-4.15 (Ubuntu Groovy)
Status: New => Invalid
** Changed in: linux-azure-4.15 (Ubuntu Bionic)
Assignee: (unassigned) => Marcelo Cerri (mhcerri)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-azure in Ubuntu.
https://bugs.launchpad.net/bugs/1908569
Title:
video: hyperv_fb: Fix the cache type when mapping the VRAM
Status in linux-azure package in Ubuntu:
New
Status in linux-azure-4.15 package in Ubuntu:
New
Status in linux-azure source package in Bionic:
Invalid
Status in linux-azure-4.15 source package in Bionic:
New
Status in linux-azure source package in Focal:
New
Status in linux-azure-4.15 source package in Focal:
Invalid
Status in linux-azure source package in Groovy:
New
Status in linux-azure-4.15 source package in Groovy:
Invalid
Bug description:
We identified a problem that is causing slow logging to the console
for customers.
The following commit resolves this issue as well as other cache relates
issues:
325073ae3485 ("video: hyperv_fb: Fix the cache type when mapping the VRAM")
(marcelo.cerri: it's actually commit id
5f1251a48c17b54939d7477305e39679a565382c in the mainline kernel)
Patch details from it's commit message:
x86 Hyper-V used to essentially always overwrite the effective cache type
of guest memory accesses to WB. This was problematic in cases where there
is a physical device assigned to the VM, since that often requires that
the VM should have control over cache types. Thus, on newer Hyper-V since
2018, Hyper-V always honors the VM's cache type, but unexpectedly Linux VM
users start to complain that Linux VM's VRAM becomes very slow, and it
turns out that Linux VM should not map the VRAM uncacheable by ioremap().
Fix this slowness issue by using ioremap_cache().
With this change, the VRAM on new Hyper-V is as fast as regular RAM, so
it's no longer necessary to use the hacks we added to mitigate the
slowness, i.e. we no longer need to allocate physical memory and use
it to back up the VRAM in Generation-1 VM, and we also no longer need to
allocate physical memory to back up the framebuffer in a Generation-2 VM
and copy the framebuffer to the real VRAM. A further big change will
address these for v5.11.
Microsoft would like to request this patch in all supported releases.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1908569/+subscriptions
--
