| Message ID | 20190516111253.4494-1-thuth@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | KVM selftests for s390x | expand |
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
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
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
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
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