From: Thomas Huth <thuth@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Janosch Frank <frankja@linux.ibm.com>,
kvm@vger.kernel.org, Andrew Jones <drjones@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>,
"Shuah Khan" <shuah@kernel.org>,
"David Hildenbrand" <david@redhat.com>,
"Cornelia Huck" <cohuck@redhat.com>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-s390@vger.kernel.org
Subject: Re: [RFC PATCH 0/4] KVM selftests for s390x
Date: Mon, 20 May 2019 13:30:31 +0200 [thread overview]
Message-ID: <9423ba89-b10e-5e6e-3cc8-8088f3088233@redhat.com> (raw)
In-Reply-To: <b412e591-3983-ebef-510b-43f9b7be4147@redhat.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: thuth at redhat.com (Thomas Huth)
Subject: [RFC PATCH 0/4] KVM selftests for s390x
Date: Mon, 20 May 2019 13:30:31 +0200 [thread overview]
Message-ID: <9423ba89-b10e-5e6e-3cc8-8088f3088233@redhat.com> (raw)
In-Reply-To: <b412e591-3983-ebef-510b-43f9b7be4147@redhat.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: thuth@redhat.com (Thomas Huth)
Subject: [RFC PATCH 0/4] KVM selftests for s390x
Date: Mon, 20 May 2019 13:30:31 +0200 [thread overview]
Message-ID: <9423ba89-b10e-5e6e-3cc8-8088f3088233@redhat.com> (raw)
Message-ID: <20190520113031.1nJSwUBxm8sRhDxOawdxW8geBnipHq2Y6njDQLPdQ-s@z> (raw)
In-Reply-To: <b412e591-3983-ebef-510b-43f9b7be4147@redhat.com>
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
next prev parent reply other threads:[~2019-05-20 11:30 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-16 11:12 [RFC PATCH 0/4] KVM selftests for s390x Thomas Huth
2019-05-16 11:12 ` Thomas Huth
2019-05-16 11:12 ` thuth
2019-05-16 11:12 ` [RFC PATCH 1/4] KVM: selftests: Guard struct kvm_vcpu_events with __KVM_HAVE_VCPU_EVENTS Thomas Huth
2019-05-16 11:12 ` Thomas Huth
2019-05-16 11:12 ` thuth
2019-05-16 11:22 ` David Hildenbrand
2019-05-16 11:22 ` David Hildenbrand
2019-05-16 11:22 ` david
2019-05-20 7:12 ` Christian Borntraeger
2019-05-20 7:12 ` Christian Borntraeger
2019-05-20 7:12 ` borntraeger
2019-05-20 8:08 ` Thomas Huth
2019-05-20 8:08 ` Thomas Huth
2019-05-20 8:08 ` thuth
2019-05-20 8:13 ` Christian Borntraeger
2019-05-20 8:13 ` Christian Borntraeger
2019-05-20 8:13 ` borntraeger
2019-05-16 11:12 ` [RFC PATCH 2/4] KVM: selftests: Align memory region addresses to 1M on s390x Thomas Huth
2019-05-16 11:12 ` Thomas Huth
2019-05-16 11:12 ` thuth
2019-05-16 11:30 ` David Hildenbrand
2019-05-16 11:30 ` David Hildenbrand
2019-05-16 11:30 ` david
2019-05-16 11:59 ` Thomas Huth
2019-05-16 11:59 ` Thomas Huth
2019-05-16 11:59 ` thuth
2019-05-16 12:08 ` David Hildenbrand
2019-05-16 12:08 ` David Hildenbrand
2019-05-16 12:08 ` david
2019-05-16 11:12 ` [RFC PATCH 3/4] KVM: selftests: Add processor code for s390x Thomas Huth
2019-05-16 11:12 ` Thomas Huth
2019-05-16 11:12 ` thuth
2019-05-16 11:12 ` [RFC PATCH 4/4] KVM: selftests: Add the sync_regs test " Thomas Huth
2019-05-16 11:12 ` Thomas Huth
2019-05-16 11:12 ` thuth
2019-05-20 11:19 ` Paolo Bonzini
2019-05-20 11:19 ` Paolo Bonzini
2019-05-20 11:19 ` pbonzini
2019-05-23 10:56 ` Andrew Jones
2019-05-23 10:56 ` Andrew Jones
2019-05-23 10:56 ` drjones
2019-05-23 11:19 ` Thomas Huth
2019-05-23 11:19 ` Thomas Huth
2019-05-23 11:19 ` thuth
2019-05-20 11:20 ` [RFC PATCH 0/4] KVM selftests " Paolo Bonzini
2019-05-20 11:20 ` Paolo Bonzini
2019-05-20 11:20 ` pbonzini
2019-05-20 11:30 ` Thomas Huth [this message]
2019-05-20 11:30 ` Thomas Huth
2019-05-20 11:30 ` thuth
2019-05-20 11:43 ` Paolo Bonzini
2019-05-20 11:43 ` Paolo Bonzini
2019-05-20 11:43 ` pbonzini
2019-05-20 11:43 ` Paolo Bonzini
2019-05-22 8:44 ` Andrew Jones
2019-05-22 8:44 ` Andrew Jones
2019-05-22 8:44 ` drjones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9423ba89-b10e-5e6e-3cc8-8088f3088233@redhat.com \
--to=thuth@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=drjones@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=shuah@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.