* Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc
From: Christoph Hellwig @ 2020-04-08 15:36 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Peter Zijlstra, Randy Dunlap, Christoph Hellwig, Andrew Morton,
K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Wei Liu, x86,
David Airlie, Daniel Vetter, Laura Abbott, Sumit Semwal,
Sakari Ailus, Minchan Kim, Nitin Gupta, Robin Murphy,
Christophe Leroy, linuxppc-dev, linux-hyperv, dri-devel,
linaro-mm-sig, linux-arch, linux-mm, iommu, linux-arm-kernel,
linux-s390, bpf, linux-kernel
In-Reply-To: <20200408151519.GQ21484@bombadil.infradead.org>
On Wed, Apr 08, 2020 at 08:15:19AM -0700, Matthew Wilcox wrote:
> > > > config ZSMALLOC_PGTABLE_MAPPING
> > > > bool "Use page table mapping to access object in zsmalloc"
> > > > - depends on ZSMALLOC
> > > > + depends on ZSMALLOC=y
> > >
> > > It's a bool so this shouldn't matter... not needed.
> >
> > My mm/Kconfig has:
> >
> > config ZSMALLOC
> > tristate "Memory allocator for compressed pages"
> > depends on MMU
> >
> > which I think means it can be modular, no?
>
> Randy means that ZSMALLOC_PGTABLE_MAPPING is a bool, so I think hch's patch
> is wrong ... if ZSMALLOC is 'm' then ZSMALLOC_PGTABLE_MAPPING would become
> 'n' instead of 'y'.
In Linus' tree you can select PGTABLE_MAPPING=y with ZSMALLOC=m,
and that fits my understanding of the kbuild language. With this
patch I can't anymore.
^ permalink raw reply
* Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc
From: Randy Dunlap @ 2020-04-08 15:36 UTC (permalink / raw)
To: Matthew Wilcox, Peter Zijlstra
Cc: Christoph Hellwig, Andrew Morton, K. Y. Srinivasan, Haiyang Zhang,
Stephen Hemminger, Wei Liu, x86, David Airlie, Daniel Vetter,
Laura Abbott, Sumit Semwal, Sakari Ailus, Minchan Kim,
Nitin Gupta, Robin Murphy, Christophe Leroy, linuxppc-dev,
linux-hyperv, dri-devel, linaro-mm-sig, linux-arch, linux-mm,
iommu, linux-arm-kernel, linux-s390, bpf, linux-kernel
In-Reply-To: <20200408151519.GQ21484@bombadil.infradead.org>
On 4/8/20 8:15 AM, Matthew Wilcox wrote:
> On Wed, Apr 08, 2020 at 05:12:03PM +0200, Peter Zijlstra wrote:
>> On Wed, Apr 08, 2020 at 08:01:00AM -0700, Randy Dunlap wrote:
>>> Hi,
>>>
>>> On 4/8/20 4:59 AM, Christoph Hellwig wrote:
>>>> diff --git a/mm/Kconfig b/mm/Kconfig
>>>> index 36949a9425b8..614cc786b519 100644
>>>> --- a/mm/Kconfig
>>>> +++ b/mm/Kconfig
>>>> @@ -702,7 +702,7 @@ config ZSMALLOC
>>>>
>>>> config ZSMALLOC_PGTABLE_MAPPING
>>>> bool "Use page table mapping to access object in zsmalloc"
>>>> - depends on ZSMALLOC
>>>> + depends on ZSMALLOC=y
>>>
>>> It's a bool so this shouldn't matter... not needed.
>>
>> My mm/Kconfig has:
>>
>> config ZSMALLOC
>> tristate "Memory allocator for compressed pages"
>> depends on MMU
>>
>> which I think means it can be modular, no?
ack. I misread it.
> Randy means that ZSMALLOC_PGTABLE_MAPPING is a bool, so I think hch's patch
> is wrong ... if ZSMALLOC is 'm' then ZSMALLOC_PGTABLE_MAPPING would become
> 'n' instead of 'y'.
sigh, I wish that I had meant that. :)
thanks.
--
~Randy
^ permalink raw reply
* Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc
From: Randy Dunlap @ 2020-04-08 15:37 UTC (permalink / raw)
To: Christoph Hellwig, Matthew Wilcox
Cc: Peter Zijlstra, Andrew Morton, K. Y. Srinivasan, Haiyang Zhang,
Stephen Hemminger, Wei Liu, x86, David Airlie, Daniel Vetter,
Laura Abbott, Sumit Semwal, Sakari Ailus, Minchan Kim,
Nitin Gupta, Robin Murphy, Christophe Leroy, linuxppc-dev,
linux-hyperv, dri-devel, linaro-mm-sig, linux-arch, linux-mm,
iommu, linux-arm-kernel, linux-s390, bpf, linux-kernel
In-Reply-To: <20200408153602.GA28081@lst.de>
On 4/8/20 8:36 AM, Christoph Hellwig wrote:
> On Wed, Apr 08, 2020 at 08:15:19AM -0700, Matthew Wilcox wrote:
>>>>> config ZSMALLOC_PGTABLE_MAPPING
>>>>> bool "Use page table mapping to access object in zsmalloc"
>>>>> - depends on ZSMALLOC
>>>>> + depends on ZSMALLOC=y
>>>>
>>>> It's a bool so this shouldn't matter... not needed.
>>>
>>> My mm/Kconfig has:
>>>
>>> config ZSMALLOC
>>> tristate "Memory allocator for compressed pages"
>>> depends on MMU
>>>
>>> which I think means it can be modular, no?
>>
>> Randy means that ZSMALLOC_PGTABLE_MAPPING is a bool, so I think hch's patch
>> is wrong ... if ZSMALLOC is 'm' then ZSMALLOC_PGTABLE_MAPPING would become
>> 'n' instead of 'y'.
>
> In Linus' tree you can select PGTABLE_MAPPING=y with ZSMALLOC=m,
> and that fits my understanding of the kbuild language. With this
> patch I can't anymore.
>
Makes sense. thanks.
--
~Randy
^ permalink raw reply
* Re: [PATCH 02/28] staging: android: ion: use vmap instead of vm_map_ram
From: Christoph Hellwig @ 2020-04-08 15:40 UTC (permalink / raw)
To: Hillf Danton
Cc: Christoph Hellwig, Andrew Morton, Christophe Leroy,
Peter Zijlstra, linuxppc-dev, linux-hyperv, dri-devel,
linaro-mm-sig, linux-arch, linux-mm, iommu, syzkaller-bugs,
linux-arm-kernel, linux-s390, bpf, linux-kernel
In-Reply-To: <20200408124833.13032-1-hdanton@sina.com>
On Wed, Apr 08, 2020 at 08:48:33PM +0800, Hillf Danton wrote:
> > - void *addr = vm_map_ram(pages, num, -1, pgprot);
> > + void *addr = vmap(pages, num, VM_MAP);
>
> A merge glitch?
>
> void *vmap(struct page **pages, unsigned int count,
> unsigned long flags, pgprot_t prot)
Yes, thanks for the headsup, you were as fast as the build bot :)
Fixed now.
^ permalink raw reply
* Re: [PATCH] Drivers: hv: vmbus: Disallow the freeze PM operation
From: Vitaly Kuznetsov @ 2020-04-08 15:47 UTC (permalink / raw)
To: Dexuan Cui
Cc: kys, haiyangz, sthemmin, wei.liu, linux-hyperv, linux-kernel,
mikelley
In-Reply-To: <1586296907-53744-1-git-send-email-decui@microsoft.com>
Dexuan Cui <decui@microsoft.com> writes:
> Before the hibernation patchset (e.g. f53335e3289f), a Linux VM on Hyper-V
> can run "echo freeze > /sys/power/state" (or "systemctl suspend")
> to freeze the system. The user can press the keyboard or move the mouse
> to wake up the VM. Note: the two aforementioned commands are equivalent
> here, because Hyper-V doesn't support the guest ACPI S3 state.
>
> With the hibernation patchset, a Linux VM on Hyper-V can hibernate to disk
> and resume back; however, the 'freeze' operation is broken for Hyper-V
> Generation-2 VM (which doesn't have a legacy keyboard/mouse): when the
> vmbus devices are suspended, the VM can not receive any interrupt from
> the synthetic keyboard/mouse devices, so there is no way to wake up the
> VM. This is not an issue for Generaton-1 VM, because it looks the legacy
> keyboard/mouse devices can still be used to wake up the VM in my test.
>
> IMO 'freeze' in a Linux VM on Hyper-V is not really useful in practice,
> so let's disallow the operation for both Gen-1 and Gen-2 VMs, even if
> it's not an issue for Gen-1 VMs.
Suspend-to-idle may not be very useful indeed, however, it worked before
and I think we can just fix it. In particular, why do we need to do
anything when we are not hibernating?
>
> Fixes: f53335e3289f ("Drivers: hv: vmbus: Suspend/resume the vmbus itself for hibernation")
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
> ---
> drivers/hv/vmbus_drv.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index 029378c..82a4327 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -28,6 +28,7 @@
> #include <linux/notifier.h>
> #include <linux/ptrace.h>
> #include <linux/screen_info.h>
> +#include <linux/suspend.h>
> #include <linux/kdebug.h>
> #include <linux/efi.h>
> #include <linux/random.h>
> @@ -2357,6 +2358,23 @@ static void hv_synic_resume(void)
> .resume = hv_synic_resume,
> };
>
> +/*
> + * Note: "freeze/suspend" here means "systemctl suspend".
> + * "systemctl hibernate" is still supported.
Let's not use systemd terminology in kernel, let's use the ones from
admin-guide/pm/sleep-states.rst (Suspend-to-Idle/Standby/Suspend-to-RAM/
Hibernation).
> + */
> +static int hv_pm_notify(struct notifier_block *nb,
> + unsigned long val, void *ign)
> +{
> + if (val == PM_SUSPEND_PREPARE) {
> + pr_info("freeze/suspend is not supported\n");
> + return NOTIFY_BAD;
> + }
> +
> + return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block hv_pm_nb;
> +
> static int __init hv_acpi_init(void)
> {
> int ret, t;
> @@ -2389,6 +2407,8 @@ static int __init hv_acpi_init(void)
> hv_setup_crash_handler(hv_crash_handler);
>
> register_syscore_ops(&hv_synic_syscore_ops);
> + hv_pm_nb.notifier_call = hv_pm_notify;
> + register_pm_notifier(&hv_pm_nb);
>
> return 0;
>
> @@ -2402,6 +2422,7 @@ static void __exit vmbus_exit(void)
> {
> int cpu;
>
> + unregister_pm_notifier(&hv_pm_nb);
> unregister_syscore_ops(&hv_synic_syscore_ops);
>
> hv_remove_kexec_handler();
--
Vitaly
^ permalink raw reply
* Re: [PATCH v1] x86: hyperv: report value of misc_features
From: Vitaly Kuznetsov @ 2020-04-08 15:54 UTC (permalink / raw)
To: Olaf Hering
Cc: K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Wei Liu,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
x86, linux-hyperv, linux-kernel, Michael Kelley
In-Reply-To: <20200407172739.31371-1-olaf@aepfle.de>
Olaf Hering <olaf@aepfle.de> writes:
> A few kernel features depend on ms_hyperv.misc_features, but unlike its
> siblings ->features and ->hints, the value was never reported during boot.
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> ---
> arch/x86/kernel/cpu/mshyperv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> index caa032ce3fe3..53706fb56433 100644
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -227,8 +227,8 @@ static void __init ms_hyperv_init_platform(void)
> ms_hyperv.misc_features = cpuid_edx(HYPERV_CPUID_FEATURES);
> ms_hyperv.hints = cpuid_eax(HYPERV_CPUID_ENLIGHTMENT_INFO);
>
> - pr_info("Hyper-V: features 0x%x, hints 0x%x\n",
> - ms_hyperv.features, ms_hyperv.hints);
> + pr_info("Hyper-V: features 0x%x, hints 0x%x, misc 0x%x\n",
> + ms_hyperv.features, ms_hyperv.hints, ms_hyperv.misc_features);
Several spare thoughts:
I'm always struggling to remember what is what here as these names don't
correspond to TLFS, could we maybe come up with better naming, e.g.
"Features.EAX", "Features.EDX", "Recommendations.EAX",...
On the other hand, there is more, e.g. nested virtualization
features. How is it useful for all users to see this in dmesg every
time? If we need it for development purposes, we can always run 'cpuid'
so maybe let's drop this altogether or print only with pr_debug?
(Honestly: no strong opinion here, deferring to Microsoft folks).
>
> ms_hyperv.max_vp_index = cpuid_eax(HYPERV_CPUID_IMPLEMENT_LIMITS);
> ms_hyperv.max_lp_index = cpuid_ebx(HYPERV_CPUID_IMPLEMENT_LIMITS);
>
--
Vitaly
^ permalink raw reply
* Re: decruft the vmalloc API
From: Russell King - ARM Linux admin @ 2020-04-08 16:03 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Andrew Morton, K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger,
Wei Liu, x86, David Airlie, Daniel Vetter, Laura Abbott,
Sumit Semwal, Sakari Ailus, Minchan Kim, Nitin Gupta,
Christophe Leroy, linux-arch, linux-hyperv, linux-s390,
Peter Zijlstra, linuxppc-dev, linux-kernel, dri-devel,
linaro-mm-sig, linux-mm, iommu, bpf, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20200408115926.1467567-1-hch@lst.de>
On Wed, Apr 08, 2020 at 01:58:58PM +0200, Christoph Hellwig wrote:
> Hi all,
>
> Peter noticed that with some dumb luck you can toast the kernel address
> space with exported vmalloc symbols.
>
> I used this as an opportunity to decruft the vmalloc.c API and make it
> much more systematic. This also removes any chance to create vmalloc
> mappings outside the designated areas or using executable permissions
> from modules. Besides that it removes more than 300 lines of code.
I haven't read all your patches yet.
Have you tested it on 32-bit ARM, where the module area is located
_below_ PAGE_OFFSET and outside of the vmalloc area?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
^ permalink raw reply
* Re: decruft the vmalloc API
From: Christoph Hellwig @ 2020-04-08 16:07 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Christoph Hellwig, Andrew Morton, K. Y. Srinivasan, Haiyang Zhang,
Stephen Hemminger, Wei Liu, x86, David Airlie, Daniel Vetter,
Laura Abbott, Sumit Semwal, Sakari Ailus, Minchan Kim,
Nitin Gupta, Christophe Leroy, linux-arch, linux-hyperv,
linux-s390, Peter Zijlstra, linuxppc-dev, linux-kernel, dri-devel,
linaro-mm-sig, linux-mm, iommu, bpf, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20200408160324.GS25745@shell.armlinux.org.uk>
On Wed, Apr 08, 2020 at 05:03:24PM +0100, Russell King - ARM Linux admin wrote:
> I haven't read all your patches yet.
>
> Have you tested it on 32-bit ARM, where the module area is located
> _below_ PAGE_OFFSET and outside of the vmalloc area?
I have not tested it. However existing in-kernel users that use
different areas (and we have quite a few of those) have not been
changed at all. I think the arm32 module loader (like various other
module loaders) falls into that category.
^ permalink raw reply
* RE: [PATCH] Drivers: hv: vmbus: Disallow the freeze PM operation
From: Dexuan Cui @ 2020-04-08 17:43 UTC (permalink / raw)
To: vkuznets
Cc: KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
wei.liu@kernel.org, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org, Michael Kelley
In-Reply-To: <877dyq2d4p.fsf@vitty.brq.redhat.com>
> From: Vitaly Kuznetsov <vkuznets@redhat.com>
> Sent: Wednesday, April 8, 2020 8:47 AM
> > IMO 'freeze' in a Linux VM on Hyper-V is not really useful in practice,
> > so let's disallow the operation for both Gen-1 and Gen-2 VMs, even if
> > it's not an issue for Gen-1 VMs.
>
> Suspend-to-idle may not be very useful indeed, however, it worked before
> and I think we can just fix it.
How can we fix Suspend-to-idle for a Gen-2 VM, in which no device can work
as wakeup devices? Note: in the case of Suspend-to-idle, now all the vmbus
devices including the synthetic keyboard/mouse are suspended completely.
Are you suggesting hv_vmbus should distinguish Suspend-to-idle from
hibernation, and for the former hv_vmbus should not suspend the synthetic
keyboard/mouse? This should be doable but IMO this is not a very trivial
effort, and I'm trying to avoid it since IMO Suspend-to-idle is not really
useful in practice for a Linux VM on Hyper-V. :-)
> In particular, why do we need to do
> anything when we are not hibernating?
Are you suggesting hv_vmbus should not suspend the vmbus devices at all
in the case of Suspend-to-idle?
> > +/*
> > + * Note: "freeze/suspend" here means "systemctl suspend".
> > + * "systemctl hibernate" is still supported.
>
> Let's not use systemd terminology in kernel, let's use the ones from
> admin-guide/pm/sleep-states.rst (Suspend-to-Idle/Standby/Suspend-to-RAM/
> Hibernation).
> --
> Vitaly
Thanks! I'll use the accurate terms.
Thanks,
-- Dexuan
^ permalink raw reply
* RE: [PATCH] Drivers: hv: vmbus: Disallow the freeze PM operation
From: Vitaly Kuznetsov @ 2020-04-08 19:24 UTC (permalink / raw)
To: Dexuan Cui
Cc: KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
wei.liu@kernel.org, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org, Michael Kelley
In-Reply-To: <HK0P153MB02732CCBDFA879FCE5CA48C7BFC00@HK0P153MB0273.APCP153.PROD.OUTLOOK.COM>
Dexuan Cui <decui@microsoft.com> writes:
>> From: Vitaly Kuznetsov <vkuznets@redhat.com>
>> Sent: Wednesday, April 8, 2020 8:47 AM
>> > IMO 'freeze' in a Linux VM on Hyper-V is not really useful in practice,
>> > so let's disallow the operation for both Gen-1 and Gen-2 VMs, even if
>> > it's not an issue for Gen-1 VMs.
>>
>> Suspend-to-idle may not be very useful indeed, however, it worked before
>> and I think we can just fix it.
>
> How can we fix Suspend-to-idle for a Gen-2 VM, in which no device can work
> as wakeup devices? Note: in the case of Suspend-to-idle, now all the vmbus
> devices including the synthetic keyboard/mouse are suspended completely.
>
> Are you suggesting hv_vmbus should distinguish Suspend-to-idle from
> hibernation, and for the former hv_vmbus should not suspend the synthetic
> keyboard/mouse?
Yes, basically.
> This should be doable but IMO this is not a very trivial
> effort, and I'm trying to avoid it since IMO Suspend-to-idle is not really
> useful in practice for a Linux VM on Hyper-V. :-)
Well, to me it's equally (not) useful in all other cases :-) I think we
should Cc: linux-pm@vger.kernel.org and someone will describe a real
world usecase to educate us, we'll then see if there is any Hyper-V
specifics.
>
>> In particular, why do we need to do
>> anything when we are not hibernating?
>
> Are you suggesting hv_vmbus should not suspend the vmbus devices at all
> in the case of Suspend-to-idle?
That what we were doing prior to the hibernation series, right? AFAIU
suspend-to-idle is basically 'no processes are scheduled' mode but we
don't really need to do anything with devices.
>
>> > +/*
>> > + * Note: "freeze/suspend" here means "systemctl suspend".
>> > + * "systemctl hibernate" is still supported.
>>
>> Let's not use systemd terminology in kernel, let's use the ones from
>> admin-guide/pm/sleep-states.rst (Suspend-to-Idle/Standby/Suspend-to-RAM/
>> Hibernation).
>> --
>> Vitaly
>
> Thanks! I'll use the accurate terms.
>
> Thanks,
> -- Dexuan
>
--
Vitaly
^ permalink raw reply
* RE: [PATCH] Drivers: hv: vmbus: Disallow the freeze PM operation
From: Dexuan Cui @ 2020-04-08 19:42 UTC (permalink / raw)
To: vkuznets
Cc: KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
wei.liu@kernel.org, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org, Michael Kelley
In-Reply-To: <87v9m9233b.fsf@vitty.brq.redhat.com>
> From: Vitaly Kuznetsov <vkuznets@redhat.com>
> Sent: Wednesday, April 8, 2020 12:24 PM
> To: Dexuan Cui <decui@microsoft.com>
> > ...
> > This should be doable but IMO this is not a very trivial
> > effort, and I'm trying to avoid it since IMO Suspend-to-idle is not really
> > useful in practice for a Linux VM on Hyper-V. :-)
>
> Well, to me it's equally (not) useful in all other cases :-) I think we
> should Cc: linux-pm@vger.kernel.org and someone will describe a real
> world usecase to educate us, we'll then see if there is any Hyper-V
> specifics.
Maybe I should support Suspend-to-idle, anyway. :-)
> >> In particular, why do we need to do
> >> anything when we are not hibernating?
> >
> > Are you suggesting hv_vmbus should not suspend the vmbus devices at all
> > in the case of Suspend-to-idle?
>
> That what we were doing prior to the hibernation series, right? AFAIU
Yes.
> suspend-to-idle is basically 'no processes are scheduled' mode but we
> don't really need to do anything with devices.
Got it. Let me try to make a patch to revert to the old behavior for
Suspend-to-idle.
Thanks,
-- Dexuan
^ permalink raw reply
* RE: [PATCH V4 6/6] x86/Hyper-V: Report crash data in die() when panic_on_oops is set
From: Michael Kelley @ 2020-04-08 20:19 UTC (permalink / raw)
To: ltykernel@gmail.com, KY Srinivasan, Haiyang Zhang,
Stephen Hemminger, Wei Liu, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, hpa@zytor.com, x86@kernel.org, arnd@arndb.de
Cc: Tianyu Lan, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
vkuznets
In-Reply-To: <20200406155331.2105-7-Tianyu.Lan@microsoft.com>
From: Tianyu Lan <Tianyu.Lan@microsoft.com> Sent: Monday, April 6, 2020 8:54 AM
>
> When oops happens with panic_on_oops unset, the oops
> thread is killed by die() and system continues to run.
> In such case, guest should not report crash register
> data to host since system still runs. Check panic_on_oops
> and return directly in hyperv_report_panic() when the function
> is called in the die() and panic_on_oops is unset. Fix it.
>
> Fixes: 7ed4325a44ea ("Drivers: hv: vmbus: Make panic reporting to be more useful")
> Signed-off-by: Tianyu Lan <Tianyu.Lan@microsoft.com>
> ---
> Change since v3:
> - Fix compile error.
> - Add fix commit in the change log
> ---
> arch/x86/hyperv/hv_init.c | 6 +++++-
> drivers/hv/vmbus_drv.c | 5 +++--
> include/asm-generic/mshyperv.h | 2 +-
> 3 files changed, 9 insertions(+), 4 deletions(-)
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
^ permalink raw reply
* Re: [PATCH 17/28] mm: remove the prot argument from vm_map_ram
From: Gao Xiang @ 2020-04-09 0:39 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Andrew Morton, K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger,
Wei Liu, x86, David Airlie, Daniel Vetter, Laura Abbott,
Sumit Semwal, Sakari Ailus, Minchan Kim, Nitin Gupta,
Robin Murphy, Christophe Leroy, Peter Zijlstra, linuxppc-dev,
linux-hyperv, dri-devel, linaro-mm-sig, linux-arch, linux-mm,
iommu, linux-arm-kernel, linux-s390, bpf, linux-kernel
In-Reply-To: <20200408115926.1467567-18-hch@lst.de>
On Wed, Apr 08, 2020 at 01:59:15PM +0200, Christoph Hellwig wrote:
> This is always GFP_KERNEL - for long term mappings with other properties
> vmap should be used.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c | 2 +-
> drivers/media/common/videobuf2/videobuf2-dma-sg.c | 3 +--
> drivers/media/common/videobuf2/videobuf2-vmalloc.c | 3 +--
> fs/erofs/decompressor.c | 2 +-
For EROFS part,
Acked-by: Gao Xiang <xiang@kernel.org>
Thanks,
Gao Xiang
^ permalink raw reply
* Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc
From: Benjamin Herrenschmidt @ 2020-04-09 8:54 UTC (permalink / raw)
To: Daniel Vetter, Christoph Hellwig
Cc: Andrew Morton, K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger,
Wei Liu, x86, David Airlie, Laura Abbott, Sumit Semwal,
Sakari Ailus, Minchan Kim, Nitin Gupta, Robin Murphy,
Christophe Leroy, Peter Zijlstra, linuxppc-dev, linux-hyperv,
dri-devel, linaro-mm-sig, linux-arch, linux-mm, iommu,
linux-arm-kernel, linux-s390, bpf, linux-kernel
In-Reply-To: <20200408122504.GO3456981@phenom.ffwll.local>
On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
> On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
> > If this code was broken for non-coherent caches a crude powerpc hack
> > isn't going to help anyone else. Remove the hack as it is the last
> > user of __vmalloc passing a page protection flag other than PAGE_KERNEL.
>
> Well Ben added this to make stuff work on ppc, ofc the home grown dma
> layer in drm from back then isn't going to work in other places. I guess
> should have at least an ack from him, in case anyone still cares about
> this on ppc. Adding Ben to cc.
This was due to some drivers (radeon ?) trying to use vmalloc pages for
coherent DMA, which means on those 4xx powerpc's need to be non-cached.
There were machines using that (440 based iirc), though I honestly
can't tell if anybody still uses any of it.
Cheers,
Ben.
> -Daniel
>
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > ---
> > drivers/gpu/drm/drm_scatter.c | 11 +----------
> > 1 file changed, 1 insertion(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c
> > index ca520028b2cb..f4e6184d1877 100644
> > --- a/drivers/gpu/drm/drm_scatter.c
> > +++ b/drivers/gpu/drm/drm_scatter.c
> > @@ -43,15 +43,6 @@
> >
> > #define DEBUG_SCATTER 0
> >
> > -static inline void *drm_vmalloc_dma(unsigned long size)
> > -{
> > -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
> > - return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL));
> > -#else
> > - return vmalloc_32(size);
> > -#endif
> > -}
> > -
> > static void drm_sg_cleanup(struct drm_sg_mem * entry)
> > {
> > struct page *page;
> > @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void *data,
> > return -ENOMEM;
> > }
> >
> > - entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
> > + entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
> > if (!entry->virtual) {
> > kfree(entry->busaddr);
> > kfree(entry->pagelist);
> > --
> > 2.25.1
> >
>
>
^ permalink raw reply
* Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc
From: Daniel Vetter @ 2020-04-09 9:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Christoph Hellwig, Andrew Morton, K. Y. Srinivasan, Haiyang Zhang,
Stephen Hemminger, Wei Liu, X86 ML, David Airlie, Laura Abbott,
Sumit Semwal, Sakari Ailus, Minchan Kim, Nitin Gupta,
Robin Murphy, Christophe Leroy, Peter Zijlstra, linuxppc-dev,
linux-hyperv, dri-devel,
moderated list:DMA BUFFER SHARING FRAMEWORK,
open list:GENERIC INCLUDE/A..., Linux MM,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>,,
Linux ARM, linux-s390, bpf, Linux Kernel Mailing List
In-Reply-To: <eb48f7b6327e482ea9911b129210c0417ab48345.camel@kernel.crashing.org>
On Thu, Apr 9, 2020 at 10:54 AM Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>
> On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
> > On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
> > > If this code was broken for non-coherent caches a crude powerpc hack
> > > isn't going to help anyone else. Remove the hack as it is the last
> > > user of __vmalloc passing a page protection flag other than PAGE_KERNEL.
> >
> > Well Ben added this to make stuff work on ppc, ofc the home grown dma
> > layer in drm from back then isn't going to work in other places. I guess
> > should have at least an ack from him, in case anyone still cares about
> > this on ppc. Adding Ben to cc.
>
> This was due to some drivers (radeon ?) trying to use vmalloc pages for
> coherent DMA, which means on those 4xx powerpc's need to be non-cached.
>
> There were machines using that (440 based iirc), though I honestly
> can't tell if anybody still uses any of it.
agp subsystem still seems to happily do that (vmalloc memory for
device access), never having been ported to dma apis (or well
converted to iommu drivers, which they kinda are really). So I think
this all still works exactly as back then, even with the kms radeon
drivers. Question really is whether we have users left, and I have no
clue about that either.
Now if these boxes didn't ever have agp then I think we can get away
with deleting this, since we've already deleted the legacy radeon
driver. And that one used vmalloc for everything. The new kms one does
use the dma-api if the gpu isn't connected through agp.
-Daniel
> Cheers,
> Ben.
>
> > -Daniel
> >
> > >
> > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > > ---
> > > drivers/gpu/drm/drm_scatter.c | 11 +----------
> > > 1 file changed, 1 insertion(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c
> > > index ca520028b2cb..f4e6184d1877 100644
> > > --- a/drivers/gpu/drm/drm_scatter.c
> > > +++ b/drivers/gpu/drm/drm_scatter.c
> > > @@ -43,15 +43,6 @@
> > >
> > > #define DEBUG_SCATTER 0
> > >
> > > -static inline void *drm_vmalloc_dma(unsigned long size)
> > > -{
> > > -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
> > > - return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL));
> > > -#else
> > > - return vmalloc_32(size);
> > > -#endif
> > > -}
> > > -
> > > static void drm_sg_cleanup(struct drm_sg_mem * entry)
> > > {
> > > struct page *page;
> > > @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void *data,
> > > return -ENOMEM;
> > > }
> > >
> > > - entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
> > > + entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
> > > if (!entry->virtual) {
> > > kfree(entry->busaddr);
> > > kfree(entry->pagelist);
> > > --
> > > 2.25.1
> > >
> >
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc
From: Gerhard Pircher @ 2020-04-09 11:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Daniel Vetter, Christoph Hellwig
Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan,
Sumit Semwal, linux-arch, linux-s390, Wei Liu, Stephen Hemminger,
x86, Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang,
linaro-mm-sig, bpf, linux-arm-kernel, Robin Murphy, linux-kernel,
Minchan Kim, iommu, Sakari Ailus, Andrew Morton, linuxppc-dev
In-Reply-To: <eb48f7b6327e482ea9911b129210c0417ab48345.camel@kernel.crashing.org>
Am 09.04.20 um 10:54 schrieb Benjamin Herrenschmidt:
> On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
>> On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
>>> If this code was broken for non-coherent caches a crude powerpc hack
>>> isn't going to help anyone else. Remove the hack as it is the last
>>> user of __vmalloc passing a page protection flag other than PAGE_KERNEL.
>>
>> Well Ben added this to make stuff work on ppc, ofc the home grown dma
>> layer in drm from back then isn't going to work in other places. I guess
>> should have at least an ack from him, in case anyone still cares about
>> this on ppc. Adding Ben to cc.
>
> This was due to some drivers (radeon ?) trying to use vmalloc pages for
> coherent DMA, which means on those 4xx powerpc's need to be non-cached.
>
> There were machines using that (440 based iirc), though I honestly
> can't tell if anybody still uses any of it.
The first-gen amigaone platform (6xx/book32s) uses the radeon driver
together with non-coherent DMA. However this only ever worked reliably
for DRI1.
br,
Gerhard
> Cheers,
> Ben.
>
>> -Daniel
>>
>>>
>>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>>> ---
>>> drivers/gpu/drm/drm_scatter.c | 11 +----------
>>> 1 file changed, 1 insertion(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c
>>> index ca520028b2cb..f4e6184d1877 100644
>>> --- a/drivers/gpu/drm/drm_scatter.c
>>> +++ b/drivers/gpu/drm/drm_scatter.c
>>> @@ -43,15 +43,6 @@
>>>
>>> #define DEBUG_SCATTER 0
>>>
>>> -static inline void *drm_vmalloc_dma(unsigned long size)
>>> -{
>>> -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
>>> - return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL));
>>> -#else
>>> - return vmalloc_32(size);
>>> -#endif
>>> -}
>>> -
>>> static void drm_sg_cleanup(struct drm_sg_mem * entry)
>>> {
>>> struct page *page;
>>> @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void *data,
>>> return -ENOMEM;
>>> }
>>>
>>> - entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
>>> + entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
>>> if (!entry->virtual) {
>>> kfree(entry->busaddr);
>>> kfree(entry->pagelist);
>>> --
>>> 2.25.1
>>>
>>
>>
>
^ permalink raw reply
* Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc
From: Alex Deucher @ 2020-04-09 14:19 UTC (permalink / raw)
To: Daniel Vetter
Cc: Benjamin Herrenschmidt, linux-hyperv, David Airlie, dri-devel,
Linux MM, K. Y. Srinivasan, open list:GENERIC INCLUDE/A...,
linux-s390, Wei Liu, Stephen Hemminger, X86 ML, Christoph Hellwig,
Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang,
moderated list:DMA BUFFER SHARING FRAMEWORK, bpf, Linux ARM,
Christophe Leroy, Robin Murphy, Linux Kernel Mailing List,
Minchan Kim,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>,,
Sakari Ailus, Andrew Morton, linuxppc-dev
In-Reply-To: <CAKMK7uHtkLvdsWFGiAtkzVa5mpnDvXkn3CHZQ6bgJ_enbyAc8A@mail.gmail.com>
On Thu, Apr 9, 2020 at 5:41 AM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Thu, Apr 9, 2020 at 10:54 AM Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> >
> > On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
> > > On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
> > > > If this code was broken for non-coherent caches a crude powerpc hack
> > > > isn't going to help anyone else. Remove the hack as it is the last
> > > > user of __vmalloc passing a page protection flag other than PAGE_KERNEL.
> > >
> > > Well Ben added this to make stuff work on ppc, ofc the home grown dma
> > > layer in drm from back then isn't going to work in other places. I guess
> > > should have at least an ack from him, in case anyone still cares about
> > > this on ppc. Adding Ben to cc.
> >
> > This was due to some drivers (radeon ?) trying to use vmalloc pages for
> > coherent DMA, which means on those 4xx powerpc's need to be non-cached.
> >
> > There were machines using that (440 based iirc), though I honestly
> > can't tell if anybody still uses any of it.
>
> agp subsystem still seems to happily do that (vmalloc memory for
> device access), never having been ported to dma apis (or well
> converted to iommu drivers, which they kinda are really). So I think
> this all still works exactly as back then, even with the kms radeon
> drivers. Question really is whether we have users left, and I have no
> clue about that either.
>
> Now if these boxes didn't ever have agp then I think we can get away
> with deleting this, since we've already deleted the legacy radeon
> driver. And that one used vmalloc for everything. The new kms one does
> use the dma-api if the gpu isn't connected through agp.
All radeons have a built in remapping table to handle non-AGP systems.
On the earlier radeons it wasn't quite as performant as AGP, but it
was always more reliable because AGP is AGP. Maybe it's time to let
AGP go?
Alex
> -Daniel
>
> > Cheers,
> > Ben.
> >
> > > -Daniel
> > >
> > > >
> > > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > > > ---
> > > > drivers/gpu/drm/drm_scatter.c | 11 +----------
> > > > 1 file changed, 1 insertion(+), 10 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c
> > > > index ca520028b2cb..f4e6184d1877 100644
> > > > --- a/drivers/gpu/drm/drm_scatter.c
> > > > +++ b/drivers/gpu/drm/drm_scatter.c
> > > > @@ -43,15 +43,6 @@
> > > >
> > > > #define DEBUG_SCATTER 0
> > > >
> > > > -static inline void *drm_vmalloc_dma(unsigned long size)
> > > > -{
> > > > -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
> > > > - return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL));
> > > > -#else
> > > > - return vmalloc_32(size);
> > > > -#endif
> > > > -}
> > > > -
> > > > static void drm_sg_cleanup(struct drm_sg_mem * entry)
> > > > {
> > > > struct page *page;
> > > > @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void *data,
> > > > return -ENOMEM;
> > > > }
> > > >
> > > > - entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
> > > > + entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
> > > > if (!entry->virtual) {
> > > > kfree(entry->busaddr);
> > > > kfree(entry->pagelist);
> > > > --
> > > > 2.25.1
> > > >
> > >
> > >
> >
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc
From: Daniel Vetter @ 2020-04-09 14:57 UTC (permalink / raw)
To: Alex Deucher
Cc: Benjamin Herrenschmidt, linux-hyperv, David Airlie, dri-devel,
Linux MM, K. Y. Srinivasan, open list:GENERIC INCLUDE/A...,
linux-s390, Wei Liu, Stephen Hemminger, X86 ML, Christoph Hellwig,
Peter Zijlstra, Laura Abbott, Nitin Gupta, Haiyang Zhang,
moderated list:DMA BUFFER SHARING FRAMEWORK, bpf, Linux ARM,
Christophe Leroy, Robin Murphy, Linux Kernel Mailing List,
Minchan Kim,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>,,
Sakari Ailus, Andrew Morton, linuxppc-dev
In-Reply-To: <CADnq5_MjTSm6j=_8huVQ854H6jXY5Rg36wc31QDfOpfjfscWxA@mail.gmail.com>
On Thu, Apr 9, 2020 at 4:19 PM Alex Deucher <alexdeucher@gmail.com> wrote:
>
> On Thu, Apr 9, 2020 at 5:41 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > On Thu, Apr 9, 2020 at 10:54 AM Benjamin Herrenschmidt
> > <benh@kernel.crashing.org> wrote:
> > >
> > > On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
> > > > On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
> > > > > If this code was broken for non-coherent caches a crude powerpc hack
> > > > > isn't going to help anyone else. Remove the hack as it is the last
> > > > > user of __vmalloc passing a page protection flag other than PAGE_KERNEL.
> > > >
> > > > Well Ben added this to make stuff work on ppc, ofc the home grown dma
> > > > layer in drm from back then isn't going to work in other places. I guess
> > > > should have at least an ack from him, in case anyone still cares about
> > > > this on ppc. Adding Ben to cc.
> > >
> > > This was due to some drivers (radeon ?) trying to use vmalloc pages for
> > > coherent DMA, which means on those 4xx powerpc's need to be non-cached.
> > >
> > > There were machines using that (440 based iirc), though I honestly
> > > can't tell if anybody still uses any of it.
> >
> > agp subsystem still seems to happily do that (vmalloc memory for
> > device access), never having been ported to dma apis (or well
> > converted to iommu drivers, which they kinda are really). So I think
> > this all still works exactly as back then, even with the kms radeon
> > drivers. Question really is whether we have users left, and I have no
> > clue about that either.
> >
> > Now if these boxes didn't ever have agp then I think we can get away
> > with deleting this, since we've already deleted the legacy radeon
> > driver. And that one used vmalloc for everything. The new kms one does
> > use the dma-api if the gpu isn't connected through agp.
>
> All radeons have a built in remapping table to handle non-AGP systems.
> On the earlier radeons it wasn't quite as performant as AGP, but it
> was always more reliable because AGP is AGP. Maybe it's time to let
> AGP go?
I'd be very much in favour of that, if we can just use the integrated
gart and drop agp fast writes wobbliness on the floor. I think the
only other modern driver using agp would be nouveau at that point.
-Daniel
>
> Alex
>
> > -Daniel
> >
> > > Cheers,
> > > Ben.
> > >
> > > > -Daniel
> > > >
> > > > >
> > > > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > > > > ---
> > > > > drivers/gpu/drm/drm_scatter.c | 11 +----------
> > > > > 1 file changed, 1 insertion(+), 10 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c
> > > > > index ca520028b2cb..f4e6184d1877 100644
> > > > > --- a/drivers/gpu/drm/drm_scatter.c
> > > > > +++ b/drivers/gpu/drm/drm_scatter.c
> > > > > @@ -43,15 +43,6 @@
> > > > >
> > > > > #define DEBUG_SCATTER 0
> > > > >
> > > > > -static inline void *drm_vmalloc_dma(unsigned long size)
> > > > > -{
> > > > > -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
> > > > > - return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL));
> > > > > -#else
> > > > > - return vmalloc_32(size);
> > > > > -#endif
> > > > > -}
> > > > > -
> > > > > static void drm_sg_cleanup(struct drm_sg_mem * entry)
> > > > > {
> > > > > struct page *page;
> > > > > @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void *data,
> > > > > return -ENOMEM;
> > > > > }
> > > > >
> > > > > - entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
> > > > > + entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
> > > > > if (!entry->virtual) {
> > > > > kfree(entry->busaddr);
> > > > > kfree(entry->pagelist);
> > > > > --
> > > > > 2.25.1
> > > > >
> > > >
> > > >
> > >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH 01/28] x86/hyperv: use vmalloc_exec for the hypercall page
From: Wei Liu @ 2020-04-09 15:52 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Andrew Morton, K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger,
Wei Liu, x86, David Airlie, Daniel Vetter, Laura Abbott,
Sumit Semwal, Sakari Ailus, Minchan Kim, Nitin Gupta,
Robin Murphy, Christophe Leroy, Peter Zijlstra, linuxppc-dev,
linux-hyperv, dri-devel, linaro-mm-sig, linux-arch, linux-mm,
iommu, linux-arm-kernel, linux-s390, bpf, linux-kernel
In-Reply-To: <20200408115926.1467567-2-hch@lst.de>
On Wed, Apr 08, 2020 at 01:58:59PM +0200, Christoph Hellwig wrote:
> Use the designated helper for allocating executable kernel memory, and
> remove the now unused PAGE_KERNEL_RX define.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Wei Liu <wei.liu@kernel.org>
^ permalink raw reply
* Re: [PATCH 09/28] mm: rename CONFIG_PGTABLE_MAPPING to CONFIG_ZSMALLOC_PGTABLE_MAPPING
From: Minchan Kim @ 2020-04-09 15:59 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Andrew Morton, K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger,
Wei Liu, x86, David Airlie, Daniel Vetter, Laura Abbott,
Sumit Semwal, Sakari Ailus, Nitin Gupta, Robin Murphy,
Christophe Leroy, Peter Zijlstra, linuxppc-dev, linux-hyperv,
dri-devel, linaro-mm-sig, linux-arch, linux-mm, iommu,
linux-arm-kernel, linux-s390, bpf, linux-kernel
In-Reply-To: <20200408115926.1467567-10-hch@lst.de>
On Wed, Apr 08, 2020 at 01:59:07PM +0200, Christoph Hellwig wrote:
> Rename the Kconfig variable to clarify the scope.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Minchan Kim <minchan@kernel.org>
^ permalink raw reply
* Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc
From: Minchan Kim @ 2020-04-09 16:08 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Andrew Morton, K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger,
Wei Liu, x86, David Airlie, Daniel Vetter, Laura Abbott,
Sumit Semwal, Sakari Ailus, Nitin Gupta, Robin Murphy,
Christophe Leroy, Peter Zijlstra, linuxppc-dev, linux-hyperv,
dri-devel, linaro-mm-sig, linux-arch, linux-mm, iommu,
linux-arm-kernel, linux-s390, bpf, linux-kernel,
sergey.senozhatsky
In-Reply-To: <20200408115926.1467567-11-hch@lst.de>
On Wed, Apr 08, 2020 at 01:59:08PM +0200, Christoph Hellwig wrote:
> This allows to unexport map_vm_area and unmap_kernel_range, which are
> rather deep internal and should not be available to modules.
Even though I don't know how many usecase we have using zsmalloc as
module(I heard only once by dumb reason), it could affect existing
users. Thus, please include concrete explanation in the patch to
justify when the complain occurs.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> mm/Kconfig | 2 +-
> mm/vmalloc.c | 2 --
> 2 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 36949a9425b8..614cc786b519 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -702,7 +702,7 @@ config ZSMALLOC
>
> config ZSMALLOC_PGTABLE_MAPPING
> bool "Use page table mapping to access object in zsmalloc"
> - depends on ZSMALLOC
> + depends on ZSMALLOC=y
> help
> By default, zsmalloc uses a copy-based object mapping method to
> access allocations that span two pages. However, if a particular
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 3375f9508ef6..9183fc0d365a 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -2046,7 +2046,6 @@ void unmap_kernel_range(unsigned long addr, unsigned long size)
> vunmap_page_range(addr, end);
> flush_tlb_kernel_range(addr, end);
> }
> -EXPORT_SYMBOL_GPL(unmap_kernel_range);
>
> int map_vm_area(struct vm_struct *area, pgprot_t prot, struct page **pages)
> {
> @@ -2058,7 +2057,6 @@ int map_vm_area(struct vm_struct *area, pgprot_t prot, struct page **pages)
>
> return err > 0 ? 0 : err;
> }
> -EXPORT_SYMBOL_GPL(map_vm_area);
>
> static inline void setup_vmalloc_vm_locked(struct vm_struct *vm,
> struct vmap_area *va, unsigned long flags, const void *caller)
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH v1] x86: hyperv: report value of misc_features
From: Wei Liu @ 2020-04-09 16:26 UTC (permalink / raw)
To: Vitaly Kuznetsov
Cc: Olaf Hering, K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger,
Wei Liu, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, x86, linux-hyperv, linux-kernel, Michael Kelley
In-Reply-To: <874ktu2csk.fsf@vitty.brq.redhat.com>
On Wed, Apr 08, 2020 at 05:54:35PM +0200, Vitaly Kuznetsov wrote:
> Olaf Hering <olaf@aepfle.de> writes:
>
> > A few kernel features depend on ms_hyperv.misc_features, but unlike its
> > siblings ->features and ->hints, the value was never reported during boot.
> >
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > ---
> > arch/x86/kernel/cpu/mshyperv.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> > index caa032ce3fe3..53706fb56433 100644
> > --- a/arch/x86/kernel/cpu/mshyperv.c
> > +++ b/arch/x86/kernel/cpu/mshyperv.c
> > @@ -227,8 +227,8 @@ static void __init ms_hyperv_init_platform(void)
> > ms_hyperv.misc_features = cpuid_edx(HYPERV_CPUID_FEATURES);
> > ms_hyperv.hints = cpuid_eax(HYPERV_CPUID_ENLIGHTMENT_INFO);
> >
> > - pr_info("Hyper-V: features 0x%x, hints 0x%x\n",
> > - ms_hyperv.features, ms_hyperv.hints);
> > + pr_info("Hyper-V: features 0x%x, hints 0x%x, misc 0x%x\n",
> > + ms_hyperv.features, ms_hyperv.hints, ms_hyperv.misc_features);
>
> Several spare thoughts:
>
> I'm always struggling to remember what is what here as these names don't
> correspond to TLFS, could we maybe come up with better naming, e.g.
>
> "Features.EAX", "Features.EDX", "Recommendations.EAX",...
>
> On the other hand, there is more, e.g. nested virtualization
> features. How is it useful for all users to see this in dmesg every
> time? If we need it for development purposes, we can always run 'cpuid'
> so maybe let's drop this altogether or print only with pr_debug?
>
> (Honestly: no strong opinion here, deferring to Microsoft folks).
I think making them closer to TLFS is a good idea.
Leaving them always printed is not a big concern to me. Sometimes you
don't get to run `cpuid` if the kernel crashes early.
Olaf's patch is fine as-is. I'm happy to take this patch (if not already
taken by x86 maintainers) given it makes at least one developer's life
easier.
Wei.
>
> >
> > ms_hyperv.max_vp_index = cpuid_eax(HYPERV_CPUID_IMPLEMENT_LIMITS);
> > ms_hyperv.max_lp_index = cpuid_ebx(HYPERV_CPUID_IMPLEMENT_LIMITS);
> >
>
> --
> Vitaly
>
^ permalink raw reply
* [PATCH v1 0/1] x86/kvm/hyper-v: Add support to SYNIC exit on EOM
From: Jon Doron @ 2020-04-09 16:37 UTC (permalink / raw)
To: kvm, linux-hyperv; +Cc: vkuznets, Jon Doron
According to the TLFS:
"A write to the end of message (EOM) register by the guest causes the
hypervisor to scan the internal message buffer queue(s) associated with
the virtual processor.
If a message buffer queue contains a queued message buffer, the hypervisor
attempts to deliver the message.
Message delivery succeeds if the SIM page is enabled and the message slot
corresponding to the SINTx is empty (that is, the message type in the
header is set to HvMessageTypeNone).
If a message is successfully delivered, its corresponding internal message
buffer is dequeued and marked free.
If the corresponding SINTx is not masked, an edge-triggered interrupt is
delivered (that is, the corresponding bit in the IRR is set).
This register can be used by guests to poll for messages. It can also be
used as a way to drain the message queue for a SINTx that has
been disabled (that is, masked)."
So basically this means that we need to exit on EOM so the hypervisor
will have a chance to send all the pending messages regardless of the
SCONTROL mechnaisim.
Jon Doron (1):
x86/kvm/hyper-v: Add support to SYNIC exit on EOM
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/hyperv.c | 65 +++++++++++++++++++++++++++++----
arch/x86/kvm/hyperv.h | 1 +
arch/x86/kvm/x86.c | 5 +++
include/uapi/linux/kvm.h | 1 +
5 files changed, 65 insertions(+), 8 deletions(-)
--
2.24.1
^ permalink raw reply
* [PATCH v1 1/1] x86/kvm/hyper-v: Add support to SYNIC exit on EOM
From: Jon Doron @ 2020-04-09 16:37 UTC (permalink / raw)
To: kvm, linux-hyperv; +Cc: vkuznets, Jon Doron
In-Reply-To: <20200409163745.573547-1-arilou@gmail.com>
According to the TLFS a write to the EOM register by the guest
causes the hypervisor to scan for any pending messages and if there
are any it will try to deliver them.
To do this we must exit so any pending messages can be written.
Signed-off-by: Jon Doron <arilou@gmail.com>
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/hyperv.c | 65 +++++++++++++++++++++++++++++----
arch/x86/kvm/hyperv.h | 1 +
arch/x86/kvm/x86.c | 5 +++
include/uapi/linux/kvm.h | 1 +
5 files changed, 65 insertions(+), 8 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 42a2d0d3984a..048a1db488e2 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -548,6 +548,7 @@ struct kvm_vcpu_hv_synic {
DECLARE_BITMAP(vec_bitmap, 256);
bool active;
bool dont_zero_synic_pages;
+ bool enable_eom_exit;
};
/* Hyper-V per vcpu emulation context */
diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
index bcefa9d4e57e..7432f67b2746 100644
--- a/arch/x86/kvm/hyperv.c
+++ b/arch/x86/kvm/hyperv.c
@@ -186,6 +186,49 @@ static void kvm_hv_notify_acked_sint(struct kvm_vcpu *vcpu, u32 sint)
srcu_read_unlock(&kvm->irq_srcu, idx);
}
+static int synic_read_msg(struct kvm_vcpu_hv_synic *synic, u32 sint,
+ struct hv_message_header *msg)
+{
+ struct kvm_vcpu *vcpu = synic_to_vcpu(synic);
+ int msg_off = offsetof(struct hv_message_page, sint_message[sint]);
+ gfn_t msg_page_gfn;
+ int r;
+
+ if (!(synic->msg_page & HV_SYNIC_SIMP_ENABLE))
+ return -ENOENT;
+
+ msg_page_gfn = synic->msg_page >> PAGE_SHIFT;
+
+ r = kvm_vcpu_read_guest_page(vcpu, msg_page_gfn, msg, msg_off,
+ sizeof(*msg));
+ if (r < 0)
+ return r;
+
+ return 0;
+}
+
+static bool synic_should_exit_for_eom(struct kvm_vcpu_hv_synic *synic)
+{
+ int i;
+
+ if (!synic->enable_eom_exit)
+ return false;
+
+ for (i = 0; i < ARRAY_SIZE(synic->sint); i++) {
+ struct hv_message_header hv_hdr;
+ /* If we failed to read from the msg slot then we treat this
+ * msg slot as free */
+ if (synic_read_msg(synic, i, &hv_hdr) < 0)
+ continue;
+
+ /* See if this msg slot has a pending message */
+ if (hv_hdr.message_flags.msg_pending == 1)
+ return true;
+ }
+
+ return false;
+}
+
static void synic_exit(struct kvm_vcpu_hv_synic *synic, u32 msr)
{
struct kvm_vcpu *vcpu = synic_to_vcpu(synic);
@@ -254,6 +297,9 @@ static int synic_set_msr(struct kvm_vcpu_hv_synic *synic,
for (i = 0; i < ARRAY_SIZE(synic->sint); i++)
kvm_hv_notify_acked_sint(vcpu, i);
+
+ if (!host && synic_should_exit_for_eom(synic))
+ synic_exit(synic, msr);
break;
}
case HV_X64_MSR_SINT0 ... HV_X64_MSR_SINT15:
@@ -571,8 +617,9 @@ static int synic_deliver_msg(struct kvm_vcpu_hv_synic *synic, u32 sint,
struct hv_message_header hv_hdr;
int r;
- if (!(synic->msg_page & HV_SYNIC_SIMP_ENABLE))
- return -ENOENT;
+ r = synic_read_msg(synic, sint, &hv_hdr);
+ if (r < 0)
+ return r;
msg_page_gfn = synic->msg_page >> PAGE_SHIFT;
@@ -582,12 +629,6 @@ static int synic_deliver_msg(struct kvm_vcpu_hv_synic *synic, u32 sint,
* is only called in vcpu context so the entire update is atomic from
* guest POV and thus the exact order here doesn't matter.
*/
- r = kvm_vcpu_read_guest_page(vcpu, msg_page_gfn, &hv_hdr.message_type,
- msg_off + offsetof(struct hv_message,
- header.message_type),
- sizeof(hv_hdr.message_type));
- if (r < 0)
- return r;
if (hv_hdr.message_type != HVMSG_NONE) {
if (no_retry)
@@ -785,6 +826,14 @@ int kvm_hv_activate_synic(struct kvm_vcpu *vcpu, bool dont_zero_synic_pages)
return 0;
}
+int kvm_hv_synic_enable_eom(struct kvm_vcpu *vcpu)
+{
+ struct kvm_vcpu_hv_synic *synic = vcpu_to_synic(vcpu);
+
+ synic->enable_eom_exit = true;
+ return 0;
+}
+
static bool kvm_hv_msr_partition_wide(u32 msr)
{
bool r = false;
diff --git a/arch/x86/kvm/hyperv.h b/arch/x86/kvm/hyperv.h
index 757cb578101c..ff89f0ff103c 100644
--- a/arch/x86/kvm/hyperv.h
+++ b/arch/x86/kvm/hyperv.h
@@ -56,6 +56,7 @@ void kvm_hv_irq_routing_update(struct kvm *kvm);
int kvm_hv_synic_set_irq(struct kvm *kvm, u32 vcpu_id, u32 sint);
void kvm_hv_synic_send_eoi(struct kvm_vcpu *vcpu, int vector);
int kvm_hv_activate_synic(struct kvm_vcpu *vcpu, bool dont_zero_synic_pages);
+int kvm_hv_synic_enable_eom(struct kvm_vcpu *vcpu);
void kvm_hv_vcpu_init(struct kvm_vcpu *vcpu);
void kvm_hv_vcpu_postcreate(struct kvm_vcpu *vcpu);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 027dfd278a97..0def4ab31dc1 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3350,6 +3350,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_HYPERV_SPIN:
case KVM_CAP_HYPERV_SYNIC:
case KVM_CAP_HYPERV_SYNIC2:
+ case KVM_CAP_HYPERV_SYNIC_EOM:
case KVM_CAP_HYPERV_VP_INDEX:
case KVM_CAP_HYPERV_EVENTFD:
case KVM_CAP_HYPERV_TLBFLUSH:
@@ -4209,6 +4210,10 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
return -EINVAL;
switch (cap->cap) {
+ case KVM_CAP_HYPERV_SYNIC_EOM:
+ kvm_hv_synic_enable_eom(vcpu);
+ return 0;
+
case KVM_CAP_HYPERV_SYNIC2:
if (cap->args[0])
return -EINVAL;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 428c7dde6b4b..78172ad156d8 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1017,6 +1017,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_S390_VCPU_RESETS 179
#define KVM_CAP_S390_PROTECTED 180
#define KVM_CAP_PPC_SECURE_GUEST 181
+#define KVM_CAP_HYPERV_SYNIC_EOM 182
#ifdef KVM_CAP_IRQ_ROUTING
--
2.24.1
^ permalink raw reply related
* Re: [PATCH V4 6/6] x86/Hyper-V: Report crash data in die() when panic_on_oops is set
From: Wei Liu @ 2020-04-09 16:40 UTC (permalink / raw)
To: Michael Kelley
Cc: ltykernel@gmail.com, KY Srinivasan, Haiyang Zhang,
Stephen Hemminger, Wei Liu, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, hpa@zytor.com, x86@kernel.org, arnd@arndb.de,
Tianyu Lan, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
vkuznets, Wei Liu
In-Reply-To: <MW2PR2101MB10524CB8CBF3FE49C2EDAA8DD7C00@MW2PR2101MB1052.namprd21.prod.outlook.com>
On Wed, Apr 08, 2020 at 08:19:47PM +0000, Michael Kelley wrote:
> From: Tianyu Lan <Tianyu.Lan@microsoft.com> Sent: Monday, April 6, 2020 8:54 AM
> >
> > When oops happens with panic_on_oops unset, the oops
> > thread is killed by die() and system continues to run.
> > In such case, guest should not report crash register
> > data to host since system still runs. Check panic_on_oops
> > and return directly in hyperv_report_panic() when the function
> > is called in the die() and panic_on_oops is unset. Fix it.
> >
> > Fixes: 7ed4325a44ea ("Drivers: hv: vmbus: Make panic reporting to be more useful")
> > Signed-off-by: Tianyu Lan <Tianyu.Lan@microsoft.com>
> > ---
> > Change since v3:
> > - Fix compile error.
> > - Add fix commit in the change log
> > ---
> > arch/x86/hyperv/hv_init.c | 6 +++++-
> > drivers/hv/vmbus_drv.c | 5 +++--
> > include/asm-generic/mshyperv.h | 2 +-
> > 3 files changed, 9 insertions(+), 4 deletions(-)
>
> Reviewed-by: Michael Kelley <mikelley@microsoft.com>
It seems to me only the last patch is new, others are already in my
tree, so I only apply the last one.
Let me know if my understanding is wrong.
Wei.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox