| 2020-12-17 19:51:21 |
Joseph Salisbury |
bug |
|
|
added bug |
| 2021-01-13 15:50:14 |
Marcelo Cerri |
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")
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. |
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. |
|
| 2021-01-13 15:51:26 |
Marcelo Cerri |
nominated for series |
|
Ubuntu Bionic |
|
| 2021-01-13 15:51:26 |
Marcelo Cerri |
bug task added |
|
linux-azure (Ubuntu Bionic) |
|
| 2021-01-13 15:51:26 |
Marcelo Cerri |
nominated for series |
|
Ubuntu Groovy |
|
| 2021-01-13 15:51:26 |
Marcelo Cerri |
bug task added |
|
linux-azure (Ubuntu Groovy) |
|
| 2021-01-13 15:51:26 |
Marcelo Cerri |
nominated for series |
|
Ubuntu Focal |
|
| 2021-01-13 15:51:26 |
Marcelo Cerri |
bug task added |
|
linux-azure (Ubuntu Focal) |
|
| 2021-01-13 15:51:32 |
Marcelo Cerri |
linux-azure (Ubuntu): assignee |
|
Marcelo Cerri (mhcerri) |
|
| 2021-01-13 15:51:34 |
Marcelo Cerri |
linux-azure (Ubuntu Bionic): assignee |
|
Marcelo Cerri (mhcerri) |
|
| 2021-01-13 15:51:36 |
Marcelo Cerri |
linux-azure (Ubuntu Focal): assignee |
|
Marcelo Cerri (mhcerri) |
|
| 2021-01-13 15:51:37 |
Marcelo Cerri |
linux-azure (Ubuntu Groovy): assignee |
|
Marcelo Cerri (mhcerri) |
|
| 2021-01-13 15:51:44 |
Marcelo Cerri |
bug task added |
|
linux-azure-4.15 (Ubuntu) |
|
| 2021-01-13 15:51:49 |
Marcelo Cerri |
linux-azure-4.15 (Ubuntu): assignee |
|
Marcelo Cerri (mhcerri) |
|
| 2021-01-13 15:51:56 |
Marcelo Cerri |
linux-azure (Ubuntu Bionic): assignee |
Marcelo Cerri (mhcerri) |
|
|
| 2021-01-13 15:52:00 |
Marcelo Cerri |
linux-azure (Ubuntu Bionic): status |
New |
Invalid |
|
| 2021-01-13 15:52:05 |
Marcelo Cerri |
linux-azure-4.15 (Ubuntu Focal): status |
New |
Invalid |
|
| 2021-01-13 15:52:07 |
Marcelo Cerri |
linux-azure-4.15 (Ubuntu Groovy): status |
New |
Invalid |
|
| 2021-01-13 15:52:09 |
Marcelo Cerri |
linux-azure-4.15 (Ubuntu Bionic): assignee |
|
Marcelo Cerri (mhcerri) |
|
| 2021-01-18 20:43:08 |
Marcelo Cerri |
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. |
[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. |
|
| 2021-01-18 20:56:29 |
Marcelo Cerri |
linux-azure (Ubuntu Focal): status |
New |
In Progress |
|
| 2021-01-18 20:56:32 |
Marcelo Cerri |
linux-azure-4.15 (Ubuntu Bionic): status |
New |
In Progress |
|
| 2021-01-18 20:56:34 |
Marcelo Cerri |
linux-azure (Ubuntu Groovy): status |
New |
In Progress |
|
| 2021-01-20 10:48:52 |
Stefan Bader |
linux-azure-4.15 (Ubuntu Bionic): importance |
Undecided |
Medium |
|
| 2021-01-20 10:48:58 |
Stefan Bader |
linux-azure (Ubuntu Groovy): importance |
Undecided |
Medium |
|
| 2021-01-20 10:49:00 |
Stefan Bader |
linux-azure (Ubuntu Focal): importance |
Undecided |
Medium |
|
| 2021-01-26 06:12:48 |
Kelsey Steele |
linux-azure-4.15 (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2021-01-26 06:12:51 |
Kelsey Steele |
linux-azure (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
| 2021-01-26 06:12:54 |
Kelsey Steele |
linux-azure (Ubuntu Groovy): status |
In Progress |
Fix Committed |
|
| 2021-02-18 18:47:08 |
Dexuan Cui |
bug |
|
|
added subscriber Dexuan Cui |
| 2021-03-02 14:23:19 |
Marcelo Cerri |
linux-azure (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2021-03-02 14:23:23 |
Marcelo Cerri |
linux-azure-4.15 (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2021-03-02 14:23:25 |
Marcelo Cerri |
linux-azure (Ubuntu Groovy): status |
Fix Committed |
Fix Released |
|
