[RFC,0/4] KVM selftests for s390x
mbox series

Message ID 20190516111253.4494-1-thuth@redhat.com
Headers show
Series
  • KVM selftests for s390x
Related show

Message

Thomas Huth May 16, 2019, 11:12 a.m. UTC
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 yet - since
s390x neither has PIO nor MMIO, this needs some more work first
before it becomes usable (we likely should use 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: selftests: Add the sync_regs test for s390x

 MAINTAINERS                                   |   2 +
 tools/testing/selftests/kvm/Makefile          |   3 +
 .../testing/selftests/kvm/include/kvm_util.h  |   2 +
 .../selftests/kvm/include/s390x/processor.h   |  22 ++
 tools/testing/selftests/kvm/lib/kvm_util.c    |  24 +-
 .../selftests/kvm/lib/s390x/processor.c       | 277 ++++++++++++++++++
 .../selftests/kvm/s390x/sync_regs_test.c      | 151 ++++++++++
 7 files changed, 476 insertions(+), 5 deletions(-)
 create mode 100644 tools/testing/selftests/kvm/include/s390x/processor.h
 create mode 100644 tools/testing/selftests/kvm/lib/s390x/processor.c
 create mode 100644 tools/testing/selftests/kvm/s390x/sync_regs_test.c

Comments

Paolo Bonzini May 20, 2019, 11:20 a.m. UTC | #1
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 yet - since
> s390x neither has PIO nor MMIO, this needs some more work first
> before it becomes usable (we likely should use a DIAG hypercall
> here, which is what the sync_reg test is currently using, too...).

No objections at all, though it would be like to have ucall plumbed in
from the beginning.

Paolo
Thomas Huth May 20, 2019, 11:30 a.m. UTC | #2
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 yet - since
>> s390x neither has PIO nor MMIO, this needs some more work first
>> before it becomes usable (we likely should use a DIAG hypercall
>> here, which is what the sync_reg test is currently using, too...).
> 
> No objections at all, though it would be like to have ucall plumbed in
> from the beginning.

I'm still looking at the ucall interface ... what I don't quite get yet
is the question why the ucall_type there is selectable during runtime?

Are there plans to have test that could either use UCALL_PIO or
UCALL_MMIO? If not, what about moving ucall_init() and ucall() to
architecture specific code in tools/testing/selftests/kvm/lib/aarch64/
and tools/testing/selftests/kvm/lib/x86_64 instead, and to remove the
ucall_type stuff again (so that x86 is hard-wired to PIO and aarch64
is hard-wired to MMIO)? ... then I could add a DIAG-based ucall
on s390x more easily, I think.

 Thomas
Paolo Bonzini May 20, 2019, 11:43 a.m. UTC | #3
On 20/05/19 13:30, Thomas Huth wrote:
>> No objections at all, though it would be like to have ucall plumbed in
>> from the beginning.
> I'm still looking at the ucall interface ... what I don't quite get yet
> is the question why the ucall_type there is selectable during runtime?
> 
> Are there plans to have test that could either use UCALL_PIO or
> UCALL_MMIO? If not, what about moving ucall_init() and ucall() to
> architecture specific code in tools/testing/selftests/kvm/lib/aarch64/
> and tools/testing/selftests/kvm/lib/x86_64 instead, and to remove the
> ucall_type stuff again (so that x86 is hard-wired to PIO and aarch64
> is hard-wired to MMIO)? ... then I could add a DIAG-based ucall
> on s390x more easily, I think.

Yes, that would work.  I think Andrew wanted the flexibility to use MMIO
on x86, but it's not really necessary to have it.

Paolo
Andrew Jones May 22, 2019, 8:44 a.m. UTC | #4
On Mon, May 20, 2019 at 01:43:06PM +0200, Paolo Bonzini wrote:
> On 20/05/19 13:30, Thomas Huth wrote:
> >> No objections at all, though it would be like to have ucall plumbed in
> >> from the beginning.
> > I'm still looking at the ucall interface ... what I don't quite get yet
> > is the question why the ucall_type there is selectable during runtime?
> > 
> > Are there plans to have test that could either use UCALL_PIO or
> > UCALL_MMIO? If not, what about moving ucall_init() and ucall() to
> > architecture specific code in tools/testing/selftests/kvm/lib/aarch64/
> > and tools/testing/selftests/kvm/lib/x86_64 instead, and to remove the
> > ucall_type stuff again (so that x86 is hard-wired to PIO and aarch64
> > is hard-wired to MMIO)? ... then I could add a DIAG-based ucall
> > on s390x more easily, I think.
> 
> Yes, that would work.  I think Andrew wanted the flexibility to use MMIO
> on x86, but it's not really necessary to have it.

If the flexibility isn't necessary, then I agree that it'll be nicer to
put the ucall_init() in arch setup code, avoiding the need to remember
it in each unit test.

Thanks,
drew