_kvm_s390_real_to_abs(u32 prefix, unsigned long
gra)
Just a matter of taste, but maybe this could be named differently?
kvm_s390_real2abs_prefix() ? kvm_s390_prefix_real_to_abs()?
Anyway:
Reviewed-by: Thomas Huth
On 05/11/2020 09.18, Chenyi Qiang wrote:
This unit-test is intended to test the KVM support for Protection Keys
for Supervisor Pages (PKS). If CR4.PKS is set in long mode, supervisor
pkeys are checked in addition to normal paging protections and Access or
Write can be disabled via a MSR update
On 12/01/2021 22.42, Ben Gardon wrote:
In order to add an iteration -1 to indicate that the memory population
phase has not yet completed, convert the interations counters to ints.
No functional change intended.
Reviewed-by: Jacob Xu
Signed-off-by: Ben Gardon
---
hile (READ_ONCE(vcpu_last_completed_iteration[vcpu_id])
+ != iteration)
+ ;
}
ts_diff = timespec_elapsed(start);
Reviewed-by: Thomas Huth
On 29/05/2020 09.43, Like Xu wrote:
> When the full-width writes capability is set, use the alternative MSR
> range to write larger sign counter values (up to GP counter width).
>
> Signed-off-by: Like Xu
> ---
> lib/x86/msr.h | 1 +
> x86/pmu.c | 125
On 18/09/2019 22.54, Greg Kurz wrote:
> On Wed, 18 Sep 2019 18:44:36 +0200
> Greg Kurz wrote:
>
>> On Wed, 11 Sep 2019 21:52:35 +0200
>> Thomas Huth wrote:
>>
>>> After the kfree()s haven been removed in the previous
>>> commit 9798f4ea71ea
On 13/09/2019 09.37, David Hildenbrand wrote:
> On 13.09.19 09:34, Thomas Huth wrote:
>> On 13/09/2019 09.20, Cornelia Huck wrote:
>>> On Thu, 12 Sep 2019 13:23:38 +0200
>>> Thomas Huth wrote:
>>>
>>>> Hmm, we already talked about deprecating su
On 13/09/2019 09.20, Cornelia Huck wrote:
> On Thu, 12 Sep 2019 13:23:38 +0200
> Thomas Huth wrote:
>
>> Hmm, we already talked about deprecating support for pre-3.15 kernel
>> stuff in the past (see
>> https://wiki.qemu.org/ChangeLog/2.12#Future_incompatible_change
so that we
immediately get a proper error code in case we add more interrupt
types to do_inject_vcpu() without updating s390int_to_s390irq()
sometime in the future.
Cc: sta...@vger.kernel.org
Reviewed-by: David Hildenbrand
Reviewed-by: Christian Borntraeger
Signed-off-by: Thomas Huth
---
arch/s
On 12/09/2019 12.52, Christian Borntraeger wrote:
>
>
> On 12.09.19 11:20, Thomas Huth wrote:
>> On 12/09/2019 11.14, David Hildenbrand wrote:
>>> On 12.09.19 11:00, Thomas Huth wrote:
>>>> When the userspace program runs the KVM_S390_INTERRUPT ioctl to injec
On 12/09/2019 12.47, Christian Borntraeger wrote:
>
>
> On 12.09.19 11:00, Thomas Huth wrote:
>> When the userspace program runs the KVM_S390_INTERRUPT ioctl to inject
>> an interrupt, we convert them from the legacy struct kvm_s390_interrupt
>> to the
On 12/09/2019 11.14, David Hildenbrand wrote:
> On 12.09.19 11:00, Thomas Huth wrote:
>> When the userspace program runs the KVM_S390_INTERRUPT ioctl to inject
>> an interrupt, we convert them from the legacy struct kvm_s390_interrupt
>> to the new struct kvm_s390_irq via t
in s390int_to_s390irq(), too.
And while we're at it, make sure that s390int_to_s390irq() now
directly returns -EINVAL for unknown interrupt types, so that we
do not run into this problem again in case we add more interrupt
types to do_inject_vcpu() sometime in the future.
Signed-off-by: Thomas Huth
It's not required, so drop it to make it clear that this interrupt
does not have any extra parameters.
Signed-off-by: Thomas Huth
---
arch/s390/kvm/interrupt.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
index
After the kfree()s haven been removed in the previous
commit 9798f4ea71ea ("fix rollback when kvmppc_xive_create fails"),
the code can be simplified even more to simply always "return ret"
now.
Signed-off-by: Thomas Huth
---
arch/powerpc/kvm/book3s_xive.c| 5 +--
On 04/09/2019 11.15, David Hildenbrand wrote:
> On 04.09.19 11:11, Christian Borntraeger wrote:
>>
>>
>> On 04.09.19 11:05, David Hildenbrand wrote:
>>> On 04.09.19 10:51, Thomas Huth wrote:
>>>> If unknown bits are set in kvm_valid_regs or k
On 04/09/2019 11.05, David Hildenbrand wrote:
> On 04.09.19 10:51, Thomas Huth wrote:
>> If unknown bits are set in kvm_valid_regs or kvm_dirty_regs, this
>> clearly indicates that something went wrong in the KVM userspace
>> application. The x86 variant of KVM already contai
Avoid invalid bits in kvm_valid_regs and kvm_dirty_regs on s390x.
v2:
- Split the single patch from v1 into two separate patches
(I've kept the Reviewed-bys from v1, but if you don't agree with the
patch description of the 2nd patch, please complain)
Thomas Huth (2):
KVM: s390
Borntraeger
Reviewed-by: Cornelia Huck
Signed-off-by: Thomas Huth
---
arch/s390/include/uapi/asm/kvm.h | 6 ++
arch/s390/kvm/kvm-s390.c | 4
2 files changed, 10 insertions(+)
diff --git a/arch/s390/include/uapi/asm/kvm.h b/arch/s390/include/uapi/asm/kvm.h
index 47104e5b47fd
Huck
Signed-off-by: Thomas Huth
---
.../selftests/kvm/s390x/sync_regs_test.c | 30 +++
1 file changed, 30 insertions(+)
diff --git a/tools/testing/selftests/kvm/s390x/sync_regs_test.c
b/tools/testing/selftests/kvm/s390x/sync_regs_test.c
index bbc93094519b..d5290b4ad636 100644
.
Signed-off-by: Thomas Huth
---
arch/s390/include/uapi/asm/kvm.h | 6
arch/s390/kvm/kvm-s390.c | 4 +++
.../selftests/kvm/s390x/sync_regs_test.c | 30 +++
3 files changed, 40 insertions(+)
diff --git a/arch/s390/include/uapi/asm/kvm.h b/arch
On 29/08/2019 15.26, Christian Borntraeger wrote:
>
>
> On 29.08.19 15:07, Thomas Huth wrote:
>> Check that we can write and read the guest memory with this s390x
>> ioctl, and that some error cases are handled correctly.
>>
>> Signed-off-by: Thomas Huth
>>
Check that we can write and read the guest memory with this s390x
ioctl, and that some error cases are handled correctly.
Signed-off-by: Thomas Huth
---
v3:
- Replaced wrong copy-n-pasted report string with a proper one
- Check for errno after calling the ioctl with size = 0
tools/testing
n to for
> +KVM_S390_MEMOP_LOGICAL_READ, or where the data that should be written is
> +stored for a KVM_S390_MEMOP_LOGICAL_WRITE. When KVM_S390_MEMOP_F_CHECK_ONLY
> +is specified, "buf" is unused and can be NULL. "ar" designates the access
> +register number to be used; the valid range is 0..15.
>
> The "reserved" field is meant for future extensions. It is not used by
> KVM with the currently defined set of flags.
>
Reviewed-by: Thomas Huth
On 29/08/2019 14.21, Janosch Frank wrote:
> On 8/29/19 2:14 PM, Thomas Huth wrote:
>> Check that we can write and read the guest memory with this s390x
>> ioctl, and that some error cases are handled correctly.
>>
>> Signed-off-by: Thomas Huth
>> ---
>> v
ause a kernel warning.
Signed-off-by: Thomas Huth
---
v2: Check mop->size to be non-zero
arch/s390/kvm/kvm-s390.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index f329dcb3f44c..49d779ae 100644
--- a/arch/s39
Check that we can write and read the guest memory with this s390x
ioctl, and that some error cases are handled correctly.
Signed-off-by: Thomas Huth
---
v2: Check the ioctl also with "size" set to 0
tools/testing/selftests/kvm/Makefile | 1 +
tools/testing/selftests/kvm/s39
On 29/08/2019 13.15, Janosch Frank wrote:
[...]
> By the way, I think we want to check mop->size for 0 before giving it to
> vmalloc and working with it.
You're right! This currently triggers a kernel warning message with a
Call Trace! I'll add a check to my new memop selftest and send a patch...
On 29/08/2019 13.18, Cornelia Huck wrote:
[...]
>
> Btw: should Documentation/virt/kvm/api.txt spell out the valid range
> for ar explicitly?
>
That certainly would not hurt. Care to send a patch, or shall I assemble
one?
Thomas
eck somewhere deep down
the calling chain, so let's add another check to kvm_s390_guest_mem_op()
directly.
Signed-off-by: Thomas Huth
---
arch/s390/kvm/kvm-s390.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index f329dcb3f
Check that we can write and read the guest memory with this s390x
ioctl, and that some error cases are handled correctly.
Signed-off-by: Thomas Huth
---
This test uses the ucall() interface, so this patch needs to be applied
on top of my "Implement ucall() for s390x" patch (which is
The FSF does not reside in "675 Mass Ave, Cambridge" anymore...
let's simply use proper SPDX identifiers instead.
Signed-off-by: Thomas Huth
---
arch/powerpc/include/uapi/asm/spu_info.h | 14 --
arch/powerpc/kernel/eeh_driver.c | 18 +-
ar
On 26/08/2019 09.57, Peter Xu wrote:
> The dirty_log_test is failing on some old machines like Xeon E3-1220
> with tripple faults when writting to the tracked memory region:
>
> Test iterations: 32, interval: 10 (ms)
> Testing guest mode: PA-bits:52, VA-bits:48, 4K pages
> guest physical
On s390x, we can neither exit via PIO nor MMIO, but have to use an
instruction like DIAGNOSE. Now that ucall() is implemented, we can
use it in the sync_reg_test on s390x, too.
Reviewed-by: Andrew Jones
Signed-off-by: Thomas Huth
---
tools/testing/selftests/kvm/Makefile | 2 +-
tools
in ucall.c currently looks more complex than
required. Let's split this up into architecture specific ucall.c
files instead, so we can get rid of the #ifdefs and the unnecessary
ucall_type_t handling.
Reviewed-by: Andrew Jones
Signed-off-by: Thomas Huth
---
tools/testing/selftests/kvm/Makefile
in the dirty_log patch
Thomas Huth (3):
KVM: selftests: Split ucall.c into architecture specific files
KVM: selftests: Implement ucall() for s390x
KVM: selftests: Enable dirty_log_test on s390x
tools/testing/selftests/kvm/Makefile | 9 +-
tools/testing/selftests/kvm
into this area.
0xc000 seems to be a good alternative that should work on x86
and aarch64, too.
Acked-by: Paolo Bonzini
Reviewed-by: Andrew Jones
Signed-off-by: Thomas Huth
---
tools/testing/selftests/kvm/Makefile | 1 +
tools/testing/selftests/kvm/dirty_log_test.c | 59
The kvm_create_max_vcpus test has been moved to the main directory,
and sync_regs_test is now available on s390x, too.
Signed-off-by: Thomas Huth
---
tools/testing/selftests/kvm/.gitignore | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kvm
On 31/07/2019 15.32, Thomas Huth wrote:
> Implement the ucall() interface on s390x to be able to use the
> dirty_log_test KVM selftest on s390x, too.
>
> v2:
> - Split up ucall.c into architecture specific files
> - Removed some #ifdef __s390x__ in the dirty_log patch
&
Implement the ucall() interface on s390x to be able to use the
dirty_log_test KVM selftest on s390x, too.
v2:
- Split up ucall.c into architecture specific files
- Removed some #ifdef __s390x__ in the dirty_log patch
Thomas Huth (3):
KVM: selftests: Split ucall.c into architecture specific
into this area.
0xc000 seems to be a good alternative that should work on x86
and aarch64, too.
Acked-by: Paolo Bonzini
Signed-off-by: Thomas Huth
---
tools/testing/selftests/kvm/Makefile | 1 +
tools/testing/selftests/kvm/dirty_log_test.c | 59 +---
2 files changed, 53
in ucall.c currently looks more complex than
required. Let's split this up into architecture specific ucall.c
files instead, so we can get rid of the #ifdefs and the unnecessary
ucall_type_t handling.
Signed-off-by: Thomas Huth
---
tools/testing/selftests/kvm/Makefile | 6 +-
tools/testing
On s390x, we can neither exit via PIO nor MMIO, but have to use an
instruction like DIAGNOSE. Now that ucall() is implemented, we can
use it in the sync_reg_test on s390x, too.
Signed-off-by: Thomas Huth
---
tools/testing/selftests/kvm/Makefile | 2 +-
tools/testing/selftests/kvm/lib
On 31/07/2019 12.28, Andrew Jones wrote:
> On Wed, Jul 31, 2019 at 11:43:16AM +0200, Thomas Huth wrote:
>> On 30/07/2019 12.48, Andrew Jones wrote:
>>> On Tue, Jul 30, 2019 at 12:01:11PM +0200, Thomas Huth wrote:
>>>> On s390x, we can neither exit via
On 30/07/2019 12.48, Andrew Jones wrote:
> On Tue, Jul 30, 2019 at 12:01:11PM +0200, Thomas Huth wrote:
>> On s390x, we can neither exit via PIO nor MMIO, but have to use
>> an instruction like DIAGNOSE. While we're at it, rename UCALL_PIO
>> to UCALL_DEFAULT, since PIO onl
On 30/07/2019 12.57, Andrew Jones wrote:
> On Tue, Jul 30, 2019 at 12:01:12PM +0200, Thomas Huth wrote:
>> To run the dirty_log_test on s390x, we have to make sure that we
>> access the dirty log bitmap with little endian byte ordering and
>> we have to properly align the
On 30/07/2019 16.57, Christian Borntraeger wrote:
>
>
> On 30.07.19 12:01, Thomas Huth wrote:
>> To run the dirty_log_test on s390x, we have to make sure that we
>> access the dirty log bitmap with little endian byte ordering and
>> we have to properly align the memslo
mented, we can use it in the sync_reg_test
on s390x, too.
Signed-off-by: Thomas Huth
---
.../testing/selftests/kvm/include/kvm_util.h | 2 +-
tools/testing/selftests/kvm/lib/ucall.c | 34 +++
.../selftests/kvm/s390x/sync_regs_test.c | 6 ++--
3 files changed, 32
Implement the ucall() interface on s390x to be able to use the
dirty_log_test KVM selftest on s390x, too.
Thomas Huth (2):
KVM: selftests: Implement ucall() for s390x
KVM: selftests: Enable dirty_log_test on s390x
tools/testing/selftests/kvm/Makefile | 1 +
tools/testing/selftests
to for the first time, so
we have to make sure that we touch all pages during the first
iteration to keep the test in sync here.
Signed-off-by: Thomas Huth
---
tools/testing/selftests/kvm/Makefile | 1 +
tools/testing/selftests/kvm/dirty_log_test.c | 70 ++--
2 files changed, 66
The FSF does not reside in "675 Mass Ave, Cambridge" anymore...
let's replace the old GPL boilerplate code with a proper SPDX
identifier instead.
Signed-off-by: Thomas Huth
---
kernel/configs.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/kernel
the vCPUs.
Signed-off-by: Thomas Huth
---
RFC since the stubs are a little bit ugly (does someone here like
to implement them?), and since it's a little bit annoying that
you have to raise the ulimit for this test in case the kernel provides
more vCPUs than the default ulimit...
tools/testing
We already provide the LGPL-2.0 text in LICENSES/preferred/LGPL-2.0,
so there is no need for this additional copy here.
Signed-off-by: Thomas Huth
---
arch/sparc/lib/COPYING.LIB | 481 -
1 file changed, 481 deletions(-)
delete mode 100644 arch/sparc/lib
On 24/05/2019 20.59, Aaro Koskinen wrote:
> Hi,
>
> On Fri, May 24, 2019 at 06:00:18PM +0300, Aaro Koskinen wrote:
>> Please don't delete OMAP boards quite yet :) In the mainline kernel
>> they are not orphaned, they frequently get tested using actual hardware,
>> and QEMU would help in
On 24/05/2019 10.29, Christian Borntraeger wrote:
>
>
> On 23.05.19 19:40, Andrew Jones wrote:
>> On Thu, May 23, 2019 at 06:43:05PM +0200, Thomas Huth wrote:
>>> On s390x, there is a constraint that memory regions have to be aligned
>>> to 1M (or running t
to be usable on s390x), so it simply drops out of the VM with
a diag 0x501 breakpoint instead.
Signed-off-by: Thomas Huth
---
MAINTAINERS | 1 +
tools/testing/selftests/kvm/Makefile | 2 +
.../selftests/kvm/s390x/sync_regs_test.c | 151
There is nothing x86-specific in the test apart from the VM_MODE_P52V48_4K
which we can now replace with VM_MODE_DEFAULT. Thus let's move the file to
the main folder and enable it for aarch64 and s390x, too.
Signed-off-by: Thomas Huth
---
tools/testing/selftests/kvm/Makefile
-off-by: Thomas Huth
---
arch/mips/kvm/mips.c | 3 +++
arch/powerpc/kvm/powerpc.c | 3 +++
arch/s390/kvm/kvm-s390.c | 1 +
arch/x86/kvm/x86.c | 3 +++
virt/kvm/arm/arm.c | 3 +++
virt/kvm/kvm_main.c| 2 --
6 files changed, 13 insertions(+), 2 deletions(-)
diff --git
On s390x, there is a constraint that memory regions have to be aligned
to 1M (or running the VM will fail). Introduce a new "alignment" variable
in the vm_userspace_mem_region_add() function which now can be used for
both, huge page and s390x alignment requirements.
Signed-off-by: T
Code that takes care of basic CPU setup, page table walking, etc.
Signed-off-by: Thomas Huth
---
MAINTAINERS | 1 +
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/include/s390x/processor.h | 22 ++
.../selftests/kvm/lib/s390x
it fixed in advance.)
Reported-by: Thomas Huth
Signed-off-by: Andrew Jones
---
tools/testing/selftests/kvm/lib/aarch64/processor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kvm/lib/aarch64/processor.c
b/tools/testing/selftests/kvm/lib/aarch64
This will be required later for tests like the kvm_create_max_vcpus
test that do not use the vm_create_default() function.
Signed-off-by: Thomas Huth
---
tools/testing/selftests/kvm/include/kvm_util.h | 6 ++
tools/testing/selftests/kvm/lib/aarch64/processor.c | 2 +-
tools/testing
struct kvm_nested_state is only available on x86 so far. To be able
to compile the code on other architectures as well, we need to wrap
the related code with #ifdefs.
Reviewed-by: Andrew Jones
Signed-off-by: Thomas Huth
---
tools/testing/selftests/kvm/include/kvm_util.h | 2 ++
tools/testing
The struct kvm_vcpu_events code is only available on certain architectures
(arm, arm64 and x86). To be able to compile kvm_util.c also for other
architectures, we have to fence the code with __KVM_HAVE_VCPU_EVENTS.
Reviewed-by: David Hildenbrand
Signed-off-by: Thomas Huth
---
tools/testing
rew Jones (1):
kvm: selftests: aarch64: fix default vm mode
Thomas Huth (8):
KVM: selftests: Wrap vcpu_nested_state_get/set functions with x86
guard
KVM: selftests: Guard struct kvm_vcpu_events with
__KVM_HAVE_VCPU_EVENTS
KVM: selftests: Introduce a VM_MODE_DEFAULT macro for the defa
On 22/05/2019 20.19, Aaro Koskinen wrote:
> Hi,
>
> On Wed, May 22, 2019 at 11:33:41AM +0200, Corentin Labbe wrote:
>> qemu-system-arm -M help |grep OMAP
>> cheetah Palm Tungsten|E aka. Cheetah PDA (OMAP310)
>> n800 Nokia N800 tablet aka. RX-34 (OMAP2420)
>> n810
On 23/05/2019 12.56, Andrew Jones wrote:
> On Thu, May 16, 2019 at 01:12:53PM +0200, Thomas Huth wrote:
>> The test is an adaption of the same test for x86. Note that there
>> are some differences in the way how s390x deals with the kvm_valid_regs
>> in struct kvm_run, so
struct kvm_nested_state is only available on x86 so far. To be able
to compile the code on other architectures as well, we need to wrap
the related code with #ifdefs.
Signed-off-by: Thomas Huth
---
tools/testing/selftests/kvm/include/kvm_util.h | 2 ++
tools/testing/selftests/kvm/lib/kvm_util.c
-75,7 +75,7 @@ void set_revision_id_for_vmcs12(struct kvm_nested_state
> *state,
> u32 vmcs12_revision)
> {
> /* Set revision_id in vmcs12 to vmcs12_revision. */
> - *(u32 *)(state->data) = vmcs12_revision;
> + memcpy(state->data, _revision, sizeof(u32));
> }
>
> void set_default_state(struct kvm_nested_state *state)
>
Reviewed-by: Thomas Huth
On 20/05/2019 13.20, Paolo Bonzini wrote:
> On 16/05/19 13:12, 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.
>>
>> Please note that the ucall() interface is not used y
The check for entry->index == 0 is done twice. One time should
be sufficient.
Suggested-by: Vitaly Kuznetsov
Signed-off-by: Thomas Huth
---
Vitaly already noticed this in his review to the "Fix a condition
in test_hv_cpuid()" patch a couple of days ago, but so far I haven't
s
On 20/05/2019 09.12, Christian Borntraeger wrote:
>
> On 16.05.19 13:12, Thomas Huth wrote:
>> The struct kvm_vcpu_events code is only available on certain architectures
>> (arm, arm64 and x86). To be able to compile kvm_util.c also for other
>> architectures, we'
On 17/05/2019 11.41, Vitaly Kuznetsov wrote:
> Peter Xu writes:
>
>> On Fri, May 17, 2019 at 11:04:45AM +0200, Thomas Huth wrote:
>>> So far the KVM selftests are compiled without any compiler warnings
>>> enabled. That's quite bad, since we miss a lot of possible b
).
Signed-off-by: Thomas Huth
---
v2:
- Rebased to kvm/queue
- Fix warnings in state_test.c and evmcs_test.c, too
tools/testing/selftests/kvm/Makefile | 4 +++-
tools/testing/selftests/kvm/dirty_log_test.c | 6 +-
tools/testing/selftests/kvm/lib/
On 17/05/2019 04.45, Peter Xu wrote:
> Hi, Thomas,
>
> On Thu, May 16, 2019 at 03:02:57PM +0200, Thomas Huth wrote:
>> So far the KVM selftests are compiled without any compiler warnings
>> enabled. That's quite bad, since we miss a lot of possible bugs this
>> way. L
So far the KVM selftests are compiled without any compiler warnings
enabled. That's quite bad, since we miss a lot of possible bugs this
way. Let's enable at least "-Wall" and some other useful warning flags
now.
Signed-off-by: Thomas Huth
---
This patch fixes most of the warnings
On 16/05/2019 13.30, David Hildenbrand wrote:
> On 16.05.19 13:12, Thomas Huth wrote:
>> On s390x, there is a constraint that memory regions have to be aligned
>> to 1M (or running the VM will fail). Introduce a new "alignment" variable
>> in the vm_userspace_mem_
a DIAG hypercall
here, which is what the sync_reg test is currently using, too...).
Thomas Huth (4):
KVM: selftests: Guard struct kvm_vcpu_events with
__KVM_HAVE_VCPU_EVENTS
KVM: selftests: Align memory region addresses to 1M on s390x
KVM: selftests: Add processor code for s390x
KVM
The struct kvm_vcpu_events code is only available on certain architectures
(arm, arm64 and x86). To be able to compile kvm_util.c also for other
architectures, we've got to fence the code with __KVM_HAVE_VCPU_EVENTS.
Signed-off-by: Thomas Huth
---
tools/testing/selftests/kvm/include/kvm_util.h
to be usable on s390x), so it simply drops out of the VM with
a diag 0x501 breakpoint instead.
Signed-off-by: Thomas Huth
---
MAINTAINERS | 1 +
tools/testing/selftests/kvm/Makefile | 2 +
.../selftests/kvm/s390x/sync_regs_test.c | 151
Code that takes care of basic CPU setup, page table walking, etc.
Signed-off-by: Thomas Huth
---
MAINTAINERS | 1 +
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/include/s390x/processor.h | 22 ++
.../selftests/kvm/lib/s390x
On s390x, there is a constraint that memory regions have to be aligned
to 1M (or running the VM will fail). Introduce a new "alignment" variable
in the vm_userspace_mem_region_add() function which now can be used for
both, huge page and s390x alignment requirements.
Signed-off-by: T
The blackfin architecture has been removed a while ago, so there is
no more need to declare uclinux_ram_map as a global structure.
Signed-off-by: Thomas Huth
---
drivers/mtd/maps/uclinux.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/mtd/maps/uclinux.c b
On 08/04/2019 09.09, David Hildenbrand wrote:
> On 07.04.19 14:55, Thomas Huth wrote:
>> If CONFIG_PGSTE is not set (e.g. when compiling without KVM), GCC complains:
>>
>> CC arch/s390/mm/pgtable.o
>> arch/s390/mm/pgtable.c:413:15: warning: ‘pmd_alloc_map’ defined
)
^
Wrap the function with "#ifdef CONFIG_PGSTE" to silence the warning.
Signed-off-by: Thomas Huth
---
arch/s390/mm/pgtable.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
index 8485d6dc2754..9ebd01219812 100644
--- a/ar
When reading the "See below" here, I'd expect to find some further
description of "Odd Fixes" a little bit later in the file. However,
as far as I can see, there is no further description available. Thus
let's simply remove these deceptive two words.
Signed-off-by: Thomas Huth
On 25.06.2018 10:02, Christian Borntraeger wrote:
>
>
> On 06/25/2018 09:27 AM, Christian Borntraeger wrote:
>> Also adding QEMU.
>>
>> On 06/25/2018 09:10 AM, Christian Borntraeger wrote:
>>>
>>>
>>> On 06/22/2018 09:47 PM, Guenter Roeck wrote:
Hi,
starting with commit
On 25.06.2018 10:02, Christian Borntraeger wrote:
>
>
> On 06/25/2018 09:27 AM, Christian Borntraeger wrote:
>> Also adding QEMU.
>>
>> On 06/25/2018 09:10 AM, Christian Borntraeger wrote:
>>>
>>>
>>> On 06/22/2018 09:47 PM, Guenter Roeck wrote:
Hi,
starting with commit
On 13.04.2018 16:32, Daniel Vetter wrote:
> On Fri, Apr 13, 2018 at 11:40 AM, Thomas Huth <th...@redhat.com> wrote:
>> By enabling the DRM code for virtio-gpu on S390, you currently also get
>> all the code that is enabled by CONFIG_HDMI and CONFIG_I2C automatically.
>>
On 13.04.2018 16:32, Daniel Vetter wrote:
> On Fri, Apr 13, 2018 at 11:40 AM, Thomas Huth wrote:
>> By enabling the DRM code for virtio-gpu on S390, you currently also get
>> all the code that is enabled by CONFIG_HDMI and CONFIG_I2C automatically.
>> This is quit
and CONFIG_I2C. These two patches now refactor the DRM code a little bit
so that we can compile it also without CONFIG_HDMI and CONFIG_I2C.
Thomas Huth (2):
drivers/gpu/drm: Move CONFIG_HDMI-dependent code to a separate file
drivers/gpu/drm: Make the DRM code compilable without CONFIG_I2C
drivers
e Makefile to only compile the affected files
with CONFIG_I2C=y and disable some I2C-related code in drm_edid.c.
Signed-off-by: Thomas Huth <th...@redhat.com>
---
drivers/gpu/drm/Kconfig| 4 ++--
drivers/gpu/drm/Makefile | 16 +---
drivers/gpu/drm/drm_edid.c | 10 +++---
3 f
and CONFIG_I2C. These two patches now refactor the DRM code a little bit
so that we can compile it also without CONFIG_HDMI and CONFIG_I2C.
Thomas Huth (2):
drivers/gpu/drm: Move CONFIG_HDMI-dependent code to a separate file
drivers/gpu/drm: Make the DRM code compilable without CONFIG_I2C
drivers
e Makefile to only compile the affected files
with CONFIG_I2C=y and disable some I2C-related code in drm_edid.c.
Signed-off-by: Thomas Huth
---
drivers/gpu/drm/Kconfig| 4 ++--
drivers/gpu/drm/Makefile | 16 +---
drivers/gpu/drm/drm_edid.c | 10 +++---
3 files changed, 18 inserti
he related code to a separate file for this.
Signed-off-by: Thomas Huth <th...@redhat.com>
---
drivers/gpu/drm/Kconfig | 2 +-
drivers/gpu/drm/Makefile| 1 +
drivers/gpu/drm/drm_crtc_internal.h | 2 +
drivers/gpu/drm/drm_edid.
he related code to a separate file for this.
Signed-off-by: Thomas Huth
---
drivers/gpu/drm/Kconfig | 2 +-
drivers/gpu/drm/Makefile| 1 +
drivers/gpu/drm/drm_crtc_internal.h | 2 +
drivers/gpu/drm/drm_edid.c | 163 +---
drive
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 11:32 AM, Cornelia Huck wrote:
>>>> On Wed, 21 Feb 20
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 11:32 AM, Cornelia Huck wrote:
>>>> On Wed, 21 Feb
ote:
>>>>
>>>>
>>>> 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:
>>>&g
t;>>>
>>>> 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 (&qu
1 - 100 of 214 matches
Mail list logo
