CC linux-next, Al Viro.
On 12.10.20 09:54, Sven Schnelle wrote:
> Hi,
>
> on s390 i see the following crash with linux-next:
>
> [ 4525.432605] Unable to handle kernel pointer dereference in virtual kernel
> address space
> [ 4525.432612] Failing address: TEID: 0483
On 28.09.20 11:12, Janosch Frank wrote:
> On 9/23/20 2:47 PM, Paolo Bonzini wrote:
>> On 22/09/20 03:48, Sean Christopherson wrote:
>>> This should be genericized to not be SEV specific. TDX has a similar
>>> scarcity issue in the form of key IDs, which IIUC are analogous to SEV ASIDs
>>> (gave my
On 04.05.20 18:47, Oleg Nesterov wrote:
> uprobe_write_opcode() must not cross page boundary; prepare_uprobe()
> relies on arch_uprobe_analyze_insn() which should validate "vaddr" but
> some architectures (csky, s390, and sparc) don't do this.
I think the idea was that the uprobe instruction is
On 04.05.20 23:08, Stephen Rothwell wrote:
> Hi Mike,
>
> On Mon, 4 May 2020 18:44:10 +0300 Mike Rapoport wrote:
>>
>> Ho Christian,
>>
>> On Mon, May 04, 2020 at 04:50:06PM +0200, Christian Borntraeger wrote:
>>> Mike,
>>> commit 51a2f644f
On 05.05.20 14:34, Dave Hansen wrote:[...]
>> I'm not sure what exactly the requirements for your use case are; if those
>> are significantly differently, maybe we can work together to find an
>> approach that works for both?
>
> I'm actually trying to figure out what to do with AMD's SEV. The
On 05.05.20 15:55, Ulrich Weigand wrote:
> On Tue, May 05, 2020 at 05:34:45AM -0700, Dave Hansen wrote:
>> On 5/4/20 6:41 AM, Ulrich Weigand wrote:
>>> You're right that there is no mechanism to prevent new references,
>>> but that's really never been the goal either. We're simply trying
>>> to
On 05.05.20 16:01, Christian Borntraeger wrote:
>
>
> On 05.05.20 15:55, Ulrich Weigand wrote:
>> On Tue, May 05, 2020 at 05:34:45AM -0700, Dave Hansen wrote:
>>> On 5/4/20 6:41 AM, Ulrich Weigand wrote:
>>>> You're right that there is no mechanism t
On 05.05.20 16:24, Dave Hansen wrote:
> On 5/5/20 7:00 AM, Christian Borntraeger wrote:
>> We are certainly not married to our approach. I would happily extend/change
>> this to anything that works for your case and the s390 case. So can you
>> outline
>> your requir
On 05.05.20 16:34, Dave Hansen wrote:
> On 5/5/20 7:31 AM, Christian Borntraeger wrote:
>>> So, the requirements are:
>>>
>>> 1. Allow host-side DMA and CPU access to shared pages
>>> 2. Stop host-side DMA and CPU access to encrypted pages
>>> 3
On 05.05.20 16:33, Ulrich Weigand wrote:
> On Tue, May 05, 2020 at 04:03:00PM +0200, Christian Borntraeger wrote:
>>> Just looked at
>>> commit 88b1a17dfc3ed7728316478fae0f5ad508f50397 mm: add 'try_get_page()'
>>> helper function
>>>
>>
Adding Stefan Raspl, who has done a lot of kvm_stat work in the past.
On 05.05.20 19:21, Paolo Bonzini wrote:
> On 05/05/20 19:07, David Rientjes wrote:
>>> I am totally in favor of having a binary format, but it should be
>>> introduced as a separate series on top of this one---and preferably by
On 12.05.20 19:39, Philipp Rudo wrote:
> Hi Lianbo,
>
> stupid me obviously never tested the kdump+initrd combination...
>
> The patch below fixed the problem for me. Could please give it a try, too.
>
> Thanks
> Philipp
>
> ---
>
> From 3f77088c9139582261d2e3ee6476324fc1ded401 Mon Sep 17 0
> the pages are never freed to the page allocator.
>
> So these pages look like allocated pages that are unmovable (esp.
> PG_reserved), and therefore, memory offlining fails early, when trying to
> isolate the page range.
>
> We only have to care about the exchange area, make
On 21.08.20 21:56, Tony Krowiak wrote:
> This patch refactor's the vfio_ap device driver to use the AP bus's
> ap_get_qdev() function to retrieve the vfio_ap_queue struct containing
> information about a queue that is bound to the vfio_ap device driver.
> The bus's ap_get_qdev() function retriev
On 21.08.20 21:56, Tony Krowiak wrote:
> diff --git a/drivers/s390/crypto/vfio_ap_private.h
> b/drivers/s390/crypto/vfio_ap_private.h
> index a2aa05bec718..57da703b549a 100644
> --- a/drivers/s390/crypto/vfio_ap_private.h
> +++ b/drivers/s390/crypto/vfio_ap_private.h
> @@ -87,6 +87,7 @@ struct a
On 28.08.20 16:03, Gerald Schaefer wrote:
[...]
> We came up with two possible fix-ups, both will introduce some gup-specific
> helper functions, which will have no effect on other archs than s390.
>
> Patch 1 is the solution that has already been discussed in
> https://lkml.kernel.org/r/201904
On 08.09.20 07:06, Christophe Leroy wrote:
>
>
> Le 07/09/2020 à 20:00, Gerald Schaefer a écrit :
>> From: Alexander Gordeev
>>
>> Commit 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast
>> code") introduced a subtle but severe bug on s390 with gup_fast, due to
>> dynamic pa
On 17.10.20 20:09, Alexander Graf wrote:
> Hi Jason,
>
> On 17.10.20 15:24, Jason A. Donenfeld wrote:
>>
>> After discussing this offline with Jann a bit, I have a few general
>> comments on the design of this.
>>
>> First, the UUID communicated by the hypervisor should be consumed by
>> the ke
On 11.11.20 09:18, Christoph Hellwig wrote:
> On Tue, Nov 10, 2020 at 06:21:22PM -0800, Nick Desaulniers wrote:
>> Sorry, I think this patch may be causing a regression for us for s390?
>> https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/432129279#L768
>>
>> (via https://l
gt; Cc: Alasdair Kergon
> Cc: Mike Snitzer
> Cc: dm-de...@redhat.com
> Cc: Heiko Carstens
> Cc: Vasily Gorbik
> Cc: Christian Borntraeger
> Cc: linux-s...@vger.kernel.org
> ---
> drivers/md/dm-writecache.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
On 15.07.20 18:25, Collin Walling wrote:
> On 7/13/20 12:50 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the kvms390 tree got a conflict in:
>>
>> include/uapi/linux/kvm.h
>>
>> between commit:
>>
>> 1aa561b1a4c0 ("kvm: x86: Add "last CPU" to some KVM_EXIT informa
access
>>>> attempt.
>>>>
>>>> Signed-off-by: Pierre Morel
>>>> Reviewed-by: Cornelia Huck
>>>> Acked-by: Halil Pasic
>>>> Acked-by: Christian Borntraeger
>>>> ---
>>>> arch/s390/mm/init.c | 28 +
Signed-off-by: Pierre Morel
> Reviewed-by: Cornelia Huck
> Reviewed-by: Halil Pasic
Acked-by: Christian Borntraeger
> ---
> drivers/virtio/Kconfig| 6 ++
> drivers/virtio/virtio.c | 15 +++
> include/linux/virtio_config.h | 10 ++
>
#x27;s
> the case.
>
> Signed-off-by: Pierre Morel
> Reviewed-by: Cornelia Huck
> Reviewed-by: Halil Pasic
Acked-by: Christian Borntraeger
Michael, I am fine if this patch goes via the virtio tree.
> ---
> arch/s390/Kconfig | 1 +
> arch/s390/mm/init.c | 11
On 18.09.20 19:02, Tony Krowiak wrote:
> Attempting to unregister Guest Interruption Subclass (GISC) when the
> link between the matrix mdev and KVM has been removed results in the
> following:
>
>"Kernel panic -not syncing: Fatal exception: panic_on_oops"
I think the full backtrace would
t on:
Acked-by: Christian Borntraeger
> ---
> arch/s390/include/asm/pci.h | 1 +
> arch/s390/pci/pci_clp.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
> index 99b92c3..882e233 100644
> --- a/arch
On 19.09.20 17:28, Matthew Rosato wrote:
> We'll need to keep track of whether or not the byte string in util_str is
> valid and thus needs to be passed to a vfio-pci passthrough device.
>
> Signed-off-by: Matthew Rosato
If this goes via the vfio tree,
Acked-by: Chri
c: Huacai Chen
> Cc: Aleksandar Markovic
> Cc: linux-m...@vger.kernel.org
> Cc: Paul Mackerras
> Cc: kvm-...@vger.kernel.org
> Cc: Christian Borntraeger
> Cc: Janosch Frank
> Cc: David Hildenbrand
> Cc: Cornelia Huck
> Cc: Claudio Imbrenda
> Cc: Vitaly Kuznet
On 24.09.20 00:45, Sean Christopherson wrote:
> This series introduces a concept we've discussed a few times in x86 land.
> The crux of the problem is that x86 has a few cases where KVM could
> theoretically encounter a software or hardware bug deep in a call stack
> without any sane way to prop
On 22.09.20 12:30, Zhenzhong Duan wrote:
> With new ioctl(ZCRYPT_PERDEV_REQCNT) introduced, kernel use dynamic
> allocation for the 256 element array of unsigned integers for the number
> of successfully completed requests per device. It's not a static array of
> 64 elements any more.
>
> Fixes: a
Michael,
are you going to pick this series?
On 10.09.20 10:53, Pierre Morel wrote:
> Hi all,
>
> The goal of the series is to give a chance to the architecture
> to validate VIRTIO device features.
>
> I changed VIRTIO_F_IOMMU_PLATFORM to VIRTIO_F_ACCESS_PLATFORM
> I forgot in drivers/virtio/K
On 30.06.20 19:57, Luis Chamberlain wrote:
> On Fri, Jun 26, 2020 at 02:54:10AM +, Luis Chamberlain wrote:
>> On Wed, Jun 24, 2020 at 08:37:55PM +0200, Christian Borntraeger wrote:
>>>
>>>
>>> On 24.06.20 20:32, Christian Borntraeger wrote:
>>>
On 01.07.20 15:53, Luis Chamberlain wrote:
> On Wed, Jul 01, 2020 at 10:24:29PM +0900, Tetsuo Handa wrote:
>> On 2020/07/01 19:08, Christian Borntraeger wrote:
>>>
>>>
>>> On 30.06.20 19:57, Luis Chamberlain wrote:
>>>> On Fri, Jun 26, 2020 at 02
On 01.07.20 17:38, Luis Chamberlain wrote:
> On Wed, Jul 01, 2020 at 11:08:57PM +0900, Tetsuo Handa wrote:
>> On 2020/07/01 22:53, Luis Chamberlain wrote:
Well, it is not br_stp_call_user() but br_stp_start() which is expecting
to set sub_info->retval for both KWIFEXITED() case and KWI
On 01.07.20 17:58, Luis Chamberlain wrote:
[...]
>>>
>>> Ah, well that would be a different fix required, becuase again,
>>> br_stp_start() does not untangle the correct error today really.
>>> I also I think it would be odd odd that SIGSEGV or another signal
>>> is what was terminating Christ
On 04.06.19 19:19, Paolo Bonzini wrote:
> On 23/05/19 18:43, Thomas Huth wrote:
>> This patch series enables the KVM selftests for s390x. As a first
>> test, the sync_regs from x86 has been adapted to s390x, and after
>> a fix for KVM_CAP_MAX_VCPU_ID on s390x, the kvm_create_max_vcpus
>> is now
On 05.06.19 01:25, Sasha Levin wrote:
> From: Christian Borntraeger
>
> [ Upstream commit 19ec166c3f39fe1d3789888a74cc95544ac266d4 ]
>
> kselftests exposed a problem in the s390 handling for memory slots.
> Right now we only do proper memory slot handling for creation of
On 28.05.19 02:53, Wanpeng Li wrote:
> From: Wanpeng Li
>
> The target vCPUs are in runnable state after vcpu_kick and suitable
> as a yield target. This patch implements the sched yield hypercall.
>
> 17% performace increase of ebizzy benchmark can be observed in an
> over-subscribe environme
Paolo, Radim,
would you consider this patch (or the full series) as 5.2 material or 5.3
material?
On 23.05.19 18:43, Thomas Huth wrote:
> KVM_CAP_MAX_VCPU_ID is currently always reporting KVM_MAX_VCPU_ID on all
> architectures. However, on s390x, the amount of usable CPUs is determined
> during
On 28.05.19 14:53, Cornelia Huck wrote:
> On Tue, 28 May 2019 13:00:30 +0200
> Christian Borntraeger wrote:
>
>> Paolo, Radim,
>>
>> would you consider this patch (or the full series) as 5.2 material or 5.3
>> material?
>
> FWIW, I'd consider
On 03.06.19 04:31, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 2ee567d31a5812cf93c0ec943b142de252ce1cff ("KVM: selftests: enable
> pgste option for the linker on s390")
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
>
Arnd,
with kernel headers from the latest kernel QEMU fails to build if the user run
configure with --target-list=s390x-linux-user:
when the kernel has commit 0768e17073dc527ccd18ed5f96ce85f9985e9115
net: socket: implement 64-bit timestamps
/root/rpmbuild/BUILD/qemu-4.0.50/linux-user/ioct
On 16.06.20 18:35, Peter Xu wrote:
> Hi, Alexander,
>
> On Tue, Jun 16, 2020 at 05:59:33PM +0200, Alexander Gordeev wrote:
>>> @@ -489,21 +489,7 @@ static inline vm_fault_t do_exception(struct pt_regs
>>> *regs, int access)
>>> if (unlikely(fault & VM_FAULT_ERROR))
>>> goto out
On 17.06.20 18:06, Peter Xu wrote:
> Hi, Christian,
>
> On Wed, Jun 17, 2020 at 08:19:29AM +0200, Christian Borntraeger wrote:
>>
>>
>> On 16.06.20 18:35, Peter Xu wrote:
>>> Hi, Alexander,
>>>
>>> On Tue, Jun 16, 2020 at 05:59:33PM +
On 11.05.20 22:17, Steven Rostedt wrote:
> On Mon, 11 May 2020 08:07:51 +0200
> Sven Schnelle wrote:
>
>> Thanks for noticing, looks like i missed them.
>>
>> Acked-by: Sven Schnelle
>
> As this is s390 specific, will it be going through the s390 repo?
Yes.
I will pick this up. Vasily will th
On 08.05.20 16:07, YueHaibing wrote:
> commit 657480d9c015 ("s390: support KPROBES_ON_FTRACE")
> left behind this, remove it.
>
> Signed-off-by: YueHaibing
> ---
> arch/s390/kernel/ftrace.c | 16
> 1 file changed, 16 deletions(-)
>
> diff --git a/arch/s390/kernel/ftrace.c b/
On 12.05.20 17:21, Alexander Gordeev wrote:
> Commit 2d626158 ("lib: rework bitmap_parse()") does
> not take into account order of halfwords on 64-bit
> big endian architectures.
Karsten reported that this broke receive packet steering in 5.5 and later.
So we should add cc stable and a Fixes ta
ot devices
> without VIRTIO_F_IOMMU_PLATFORM.
>
> Signed-off-by: Pierre Morel
Acked-by: Christian Borntraeger
Shouldnt we maybe add a pr_warn if that happens to help the admins to
understand what is going on?
> ---
> arch/s390/mm/init.c | 6 ++
> drivers/virtio/v
On 16.06.20 16:26, Tony Krowiak wrote:
> I would greatly appreciate some attention to this patch series ... Please?
Any idea about the kernel test build mails? Are these patches maybe against
a wrong tree?
On 05.06.20 23:39, Tony Krowiak wrote:
> This patch refactor's the vfio_ap device driver to use the AP bus's
> ap_get_qdev() function to retrieve the vfio_ap_queue struct containing
> information about a queue that is bound to the vfio_ap device driver.
> The bus's ap_get_qdev() function retriev
On 05.06.20 23:39, Tony Krowiak wrote:
[..]
> --- a/drivers/s390/crypto/vfio_ap_private.h
> +++ b/drivers/s390/crypto/vfio_ap_private.h
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
>
> #include "ap_bus.h"
>
> @@ -90,8 +91,6 @@ struct ap_matrix_mdev {
>
> extern
On 05.06.20 23:39, Tony Krowiak wrote:
[...]
> +static void vfio_ap_mdev_link_queues(struct ap_matrix_mdev *matrix_mdev,
> + enum qlink_type type,
> + unsigned long qlink_id)
> +{
> + unsigned long id;
> + struct vfio_ap_q
On 23.06.20 16:23, Christian Borntraeger wrote:
>
>
> On 23.06.20 16:11, Christian Borntraeger wrote:
>> Jens Markwardt reported a regression in the linux-next runs. with "umh: fix
>> processed error when UMH_WAIT_PROC is used" (from linux-next) a linux bridge
On 03/29/2017 11:21 AM, James Hogan wrote:
> On Wed, Mar 29, 2017 at 02:08:32PM +1100, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the kvms390 tree got a conflict in:
>>
>> include/uapi/linux/kvm.h
>>
>> between commits:
>>
>> a8a3c426772e ("KVM: MIPS: Add VZ & TE capab
On 04/13/2017 10:19 PM, Radim Krčmář wrote:
> The only user of KVM_MAX_VCPU is switched to kvm->max_vcpu.
>
> The limit could have been INT_MAX as it makes no difference, but there
> is no point in making it bigger than KVM_MAX_VCPU_ID.
>
> Signed-off-by: Radim Krčmář
> ---
> arch/x86/include/a
On 04/19/2017 01:28 PM, Peter Zijlstra wrote:
>
> So the thing Maz complained about is because KVM assumes
> synchronize_srcu() is 'free' when there is no srcu_read_lock() activity.
> This series 'breaks' that.
Why is such a behaviour change not mentioned in the cover letter?
I could not find any
On 04/19/2017 03:22 PM, Paul E. McKenney wrote:
> On Wed, Apr 19, 2017 at 01:48:08PM +0200, Christian Borntraeger wrote:
>> On 04/19/2017 01:28 PM, Peter Zijlstra wrote:
>>>
>>> So the thing Maz complained about is because KVM assumes
>>> synchroni
On 04/27/2017 05:29 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the kvms390 tree got a conflict in:
>
> arch/s390/include/asm/cpacf.h
>
> between commit:
>
> 985a9d20daa6 ("s390/crypto: Renaming PPNO to PRNO.")
>
> from the s390 tree and commit:
>
> 152c1c8d60e
On 04/28/2017 12:21 AM, Florian Fainelli wrote:
> On 04/27/2017 02:16 PM, Florian Fainelli wrote:
>> Hi Herbert,
>>
>> On 04/26/2017 10:44 PM, Herbert Xu wrote:
>>> On Tue, Apr 25, 2017 at 10:48:22AM -0400, David Miller wrote:
From: Florian Westphal
Date: Tue, 25 Apr 2017 16:17:49 +0200
On 04/28/2017 01:31 PM, Herbert Xu wrote:
> On Fri, Apr 28, 2017 at 12:23:15PM +0200, Christian Borntraeger wrote:
>>
>> I can reproduce this boot failure on s390 bisected to
>> commit 6d684e54690caef45cf14051ddeb7c71beeb681b
>>rhashtable: Cap total number of entri
Arnaldo,
since 4.10 perf annotate fails with error -95 on s390.
This contains a fix for 4.11 (maybe CC stable for 4.10?) and
an extension to implement jump detection.
Christian Borntraeger (2):
s390/perf: fix perf annotate error -95 (4.10 regression)
perf/s390: implement jump types for perf
hile power was added so lets add s390 as well.
While at it make sure to implement the branch and jump types.
Signed-off-by: Christian Borntraeger
Fixes: 786c1b51844 "perf annotate: Start supporting cross arch annotation"
Cc: Arnaldo Carvalho de Melo
---
tools/perf/util/annotate.c
Implement simple detection for all kind of jumps and branches.
Signed-off-by: Christian Borntraeger
---
tools/perf/arch/s390/annotate/instructions.c | 30
tools/perf/util/annotate.c | 2 ++
2 files changed, 32 insertions(+)
create mode 100644
On 04/06/2017 10:20 PM, Radim Krčmář wrote:
> We have kvm_arch_vcpu_should_kick() to decide whether the target cpu
> needs to be kicked. The previous condition was wrong, because
> architectures that don't use vcpu->mode would not get interrupts and
> also suboptimal, because it sent IPI in cases
cessed with bit operations, because
> we'll be clearing them later.
>
> Signed-off-by: Radim Krčmář
Patch itself looks sane
Reviewed-by: Christian Borntraeger
one question:
> static inline bool kvm_check_request(int req, struct kvm_vcpu *vcpu)
> {
> -
On 04/06/2017 10:20 PM, Radim Krčmář wrote:
> The #ifndef was protecting a missing halt_wakeup stat, but that is no
> longer necessary.
Acked-by: Christian Borntraeger
>
> Signed-off-by: Radim Krčmář
> ---
> virt/kvm/kvm_main.c | 2 --
> 1 file changed, 2 deletions(-)
&
On 04/07/2017 05:23 PM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Apr 06, 2017 at 09:51:51AM +0200, Christian Borntraeger escreveu:
>> since 4.10 perf annotate exits on s390 with an "unknown error -95".
>> Turns out that commit 786c1b51844d ("perf annotate:
----------
>> perf/core improvements and fixes:
>>
>> User visible:
>>
>> - Support s390 jump instructions in perf annotate (Christian Borntraeger)
>>
>> - When failing to setup multiple events (e.g. '-e irq_vectors:*'), state
>
On 06/28/2017 08:02 AM, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 9 Jun 2017 14:28:56 +1000 Stephen Rothwell
> wrote:
>>
>> Today's linux-next merge of the kvms390 tree got a conflict in:
>>
>> arch/s390/include/asm/kvm_host.h
>>
>> between commit:
>>
>> 2387149eade2 ("KVM: improve arch
b15b3ab2b0e30bb752793
> Author: Christian Borntraeger
> Date: Tue Feb 2 21:46:33 2016 -0800
>
> alpha/dma: use common noop dma ops
>
Hi Christoph,
are you providing a fix (or a jensen removal) or do you expect a fix from me?
> which switches pci-noop.c to use generic code,
Fixes: 4036e387 ("KVM: s390: ioctls to get and set guest storage attributes")
> Signed-off-by: Gleb Fotengauer-Malinovskiy
Acked-by: Christian Borntraeger
Out of curiosity, how did you notice that?
> ---
> include/uapi/linux/kvm.h | 2 +-
> 1 file changed, 1 insertion(+), 1
On 07/10/2017 11:23 PM, Gleb Fotengauer-Malinovskiy wrote:
> On Mon, Jul 10, 2017 at 08:43:12PM +0200, Christian Borntraeger wrote:
>> On 07/10/2017 04:44 PM, Gleb Fotengauer-Malinovskiy wrote:
>>> This ioctl actually writes to parameter too.
>>
>> Maybe rephrase t
Fixed. thanks a lot.
On 02/20/2018 09:51 PM, Stephen Rothwell wrote:
> Hi all,
>
> Commits
>
> 6558ff10e614 ("Kconfig : Remove HAS_IOMEM dependency for Graphics support")
> 60da5bfd79f7 ("s390/char : Rename EBCDIC keymap variables")
> 74113cf840c7 ("s390/setup : enable display support for
On 02/19/2018 04:47 PM, Farhan Ali wrote:
> The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on HAS_IOMEM.")'
> added the HAS_IOMEM dependecy for "Graphics support". This disabled the
> "Graphics support" menu for S390. But if we enable VT layer for S390,
> we would also need to enab
On 02/19/2018 05:38 PM, Farhan Ali wrote:
>
>
> On 02/19/2018 11:25 AM, Thomas Huth wrote:
>> On 19.02.2018 16:47, Farhan Ali wrote:
>>> The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on
>>> HAS_IOMEM.")'
>>> added the HAS_IOMEM dependecy for "Graphics support". This disabled th
On 02/21/2018 11:05 AM, Christian Borntraeger wrote:
>
>
> On 02/19/2018 05:38 PM, Farhan Ali wrote:
>>
>>
>> On 02/19/2018 11:25 AM, Thomas Huth wrote:
>>> On 19.02.2018 16:47, Farhan Ali wrote:
>>>> The 'commit e25df1205f37 (&
On 02/21/2018 11:32 AM, Cornelia Huck wrote:
> On Wed, 21 Feb 2018 11:22:38 +0100
> Christian Borntraeger wrote:
>
>> On 02/21/2018 11:05 AM, Christian Borntraeger wrote:
>>>
>>>
>>> On 02/19/2018 05:38 PM, Farhan Ali wrote:
>>>&g
On 02/21/2018 12:14 PM, Thomas Huth wrote:
> On 21.02.2018 12:09, Christian Borntraeger wrote:
>>
>>
>> On 02/21/2018 11:32 AM, Cornelia Huck wrote:
>>> On Wed, 21 Feb 2018 11:22:38 +0100
>>> Christian Borntraeger wrote:
>>>
>>
On 02/21/2018 12:29 PM, Thomas Huth wrote:
> On 21.02.2018 12:22, Christian Borntraeger wrote:
>>
>>
>> On 02/21/2018 12:14 PM, Thomas Huth wrote:
>>> On 21.02.2018 12:09, Christian Borntraeger wrote:
>>>>
>>>>
>>>> On 02/21/2018
On 02/21/2018 01:07 PM, Cornelia Huck wrote:
[...]
>>> But if you need to enable PCI to get IOMEM, I wonder why this patch here
>>> is needed at all? The Graphics menu / VT dummy console should be
>>> available in the config if IOMEM is enabled anyway?
>>
>> That is a good question. With CONFIG
On 02/21/2018 05:39 PM, Farhan Ali wrote:
>
>
> On 02/21/2018 07:11 AM, Christian Borntraeger wrote:
>>
>>
>> On 02/21/2018 01:07 PM, Cornelia Huck wrote:
>> [...]
>>>>> But if you need to enable PCI to get IOMEM, I wonder why this patch her
02/08/2018 02:11 PM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> [ dri-devel ML & arch/[score,um] Maintainers added to Cc: ]
>
> On Friday, February 02, 2018 08:59:57 AM Christian Borntraeger wrote:
>> On 02/01/2018 07:41 PM, Farhan Ali wrote:
>>> The
On 02/14/2018 02:03 AM, David Rientjes wrote:
> On Tue, 13 Feb 2018, Paolo Bonzini wrote:
>
The KVM_SET_GSI_ROUTING ioctl does a vmalloc() of
sizeof(struct kvm_irq_routing_entry) multiplied by a user-supplied value.
This can be up to 4096 entries on architectures such as arm64 and
On 02/14/2018 11:10 AM, Paolo Bonzini wrote:
> On 14/02/2018 02:03, David Rientjes wrote:
>> On Tue, 13 Feb 2018, Paolo Bonzini wrote:
>>
> The KVM_SET_GSI_ROUTING ioctl does a vmalloc() of
> sizeof(struct kvm_irq_routing_entry) multiplied by a user-supplied value.
> This can be up to
On 02/08/2018 02:11 PM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> [ dri-devel ML & arch/[score,um] Maintainers added to Cc: ]
>
> On Friday, February 02, 2018 08:59:57 AM Christian Borntraeger wrote:
>> On 02/01/2018 07:41 PM, Farhan Ali wrote:
>>> The
An even simpler approach would be:
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index cbe1d978693a..35b7aba4b6a0 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -952,6 +952,10 @@ config S390_HYPFS_FS
source "arch/s390/kvm/Kconfig"
+config DUMMY_CONSOLE
+ bool
+ def
To enable the virtual terminal layer with virtio-gpu, we need to
provide the dummy console. This console is hidden behind CONFIG_IOMEM
via the graphics support. Instead of fully enabling the graphic
drivers lets just provide a Kconfig option for the dummy console.
Signed-off-by: Christian
On 02/15/2018 12:26 PM, Geert Uytterhoeven wrote:
> Hi Christian,
>
> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
> wrote:
>> To enable the virtual terminal layer with virtio-gpu, we need to
>> provide the dummy console. This console is hidden behind CONFIG_I
On 02/15/2018 12:57 PM, Thomas Huth wrote:
> On 15.02.2018 12:26, Geert Uytterhoeven wrote:
>> Hi Christian,
>>
>> On Thu, Feb 15, 2018 at 12:14 PM, Christian Borntraeger
>> wrote:
>>> To enable the virtual terminal layer with virtio-gpu, we need to
>>
On 01/30/2018 02:02 AM, Dan Williams wrote:
> array_index_nospec() is proposed as a generic mechanism to mitigate
> against Spectre-variant-1 attacks, i.e. an attack that bypasses boundary
> checks via speculative execution. The array_index_nospec()
> implementation is expected to be safe for cur
On 02/08/2018 02:11 PM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> [ dri-devel ML & arch/[score,um] Maintainers added to Cc: ]
>
> On Friday, February 02, 2018 08:59:57 AM Christian Borntraeger wrote:
>> On 02/01/2018 07:41 PM, Farhan Ali wrote:
>>> The
I can see this warnings as well and yes, kvm_arch_irq_routing_update seems to
be available
for CONFIG_HAVE_KVM_EVENTFD=y and =n.
Seems that irqchip.c is compile independly from CONFIG_HAVE_KVM_EVENTFD,
so
Acked-by: Christian Borntraeger
On 02/22/2018 01:05 PM, Sebastian Ott wrote:
> Move
On 02/01/2018 07:41 PM, Farhan Ali wrote:
> The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on HAS_IOMEM.")'
> added the HAS_IOMEM dependecy for "Graphics support". This disabled the
> "Graphics support" menu for S390. But if we enable VT layer for S390,
> we would also need to enable
On 02/19/2018 02:35 PM, Farhan Ali wrote:
>
>
> On 02/15/2018 07:02 AM, Christian Borntraeger wrote:
>>
>>
>> On 02/15/2018 12:57 PM, Thomas Huth wrote:
>>> On 15.02.2018 12:26, Geert Uytterhoeven wrote:
>>>> Hi Christian,
>>>>
Added to my linux next tree to check for any fallout.
On 02/19/2018 04:47 PM, Farhan Ali wrote:
> Hi,
>
> This series of patches add support for an additional tty
> and console for a S390 KVM guest using a virtio-gpu device[1].
>
> Patch 1 enables the "Graphics support" menu which is
> needed t
On 02/08/2018 10:35 PM, David Rientjes wrote:
> The KVM_SET_GSI_ROUTING ioctl does a vmalloc() of
> sizeof(struct kvm_irq_routing_entry) multiplied by a user-supplied value.
> This can be up to 4096 entries on architectures such as arm64 and s390
> (and the upper bound may be increased on s390 ev
This one has been in linux-next for some days. I can carry this via the kvm/s390
tree, but I would like to get ack from at least Bartlomiej. Please also look at
patch 3 which also touches drivers/video/console/Kconfig.
Adding Greg, as I would like an ack from him for patch 3.
On 02/22/2018 05:2
lications
> (eg: via Libvirt's virsh console).
>
> Signed-off-by: Farhan Ali
> Acked-by: Christian Borntraeger
> Reviewed-by: Thomas Huth
> ---
> arch/s390/kernel/setup.c | 2 ++
> drivers/tty/Kconfig | 2 +-
> drivers/video/console/Kconfig | 2 +-
>
On 12/22/2017 09:10 PM, Christian Borntraeger wrote:
> I will give that commit a try. Thanks.
>
> On 12/22/2017 05:00 PM, Bart Van Assche wrote:
>> On Fri, 2017-12-22 at 10:53 +0100, Christian Borntraeger wrote:
>>> any quick ideas?
>>
>> Hello Christian
he changes in this cset don't cause or require changes in tools/perf/,
> so just update the copy to silence the build warning.
>
> Cc: Adrian Hunter
> Cc: Christian Borntraeger
> Cc: David Ahern
> Cc: Jiri Olsa
> Cc: Namhyung Kim
> Cc: Radim Krčmář
> Cc: Wang Na
901 - 1000 of 1093 matches
Mail list logo
