[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 7/7] s390/kvm: In-kernel channel subsystem su
From: |
Christian Borntraeger |
Subject: |
Re: [Qemu-devel] [PATCH v2 7/7] s390/kvm: In-kernel channel subsystem support. |
Date: |
Thu, 20 Sep 2012 09:26:15 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 |
On 19/09/12 16:47, Alexander Graf wrote:
>
> On 04.09.2012, at 17:13, Cornelia Huck wrote:
>
>> Handle most support for channel I/O instructions in the kernel itself.
>>
>> Only asynchronous functions (such as the start function) need to be
>> handled by userspace.
>
> Phew. This is a lot of code for something that is usually handled in user
> space in the kvm
> world. The x86 equivalent would be an in-kernel PCI bus, right? Have you
> measured major
> performance penalties when running this from user space?
Conny is on vacation, but I will try to answer that based on the discussions
with Carsten
and Conny that we had the last 9 month. ( so Conny, Carsten please correct me,
if I got
something wrong).
In essence it is that way, because we have our interrupt delivery in the kernel.
Here is the story of how this evolved:
we started with a userspace solution but it turned out that this cannot work in
an
architecture-compliant way. The problem is that the channel subsystem interacts
with the
interrupts of the system. For example there is a "test pending interruption"
instruction, that
can clear pending interrupts (a pending interrupt must not be delivered after
tpi, but it might already
be queued in KVM for delivery on another cpu)
Since the channel subsystem and the interrupt delivery work so closely
together, to code structure
has to follow that. So there are two possible ways of implementing:
1. do basic channel subsystem (instructions + interrupts) and interrupt
handling in userspace
- e.g. qemu would have a call to kvm to ask for a cpu that can accept a certain
interrupt type
- if that cpu returns to qemu, qemu would then do the psw swap (deliver the
interrupt) and go back
to KVM_RUN.
Given that interrupts have a priority, that also means that in the long run
qemu would need to do
that for all kind interrupts, even those that the kernel currently handles. For
example if a
sigp and and I/O interrupt should be delivered to a cpu, you have problems to
obey the priorities
if kvm and qemu are allowed to do a psw swap
- we already had that variant prototyped, but it has its downsides:
- it makes things like vhost impossible (you have to go to userspace to
deliver an int)
- interrupts require an additional call into the kernel (get it out +
KVM_RUN, instead of
one KVM_S390_INTERRUPT call)
- (future) passthrough of ccw devices does require in kernel handling anyway
2. do basic channel subsystem in kvm
- the kernel handles the basic channel subsystem instruction to be able to have
the interrupt
delivery architecturally correct. qemu will implement the devices on this
in-kernel channel
subsystem. This will allow for things like vhost and it is also cheaper for
things that the
kernel already handles. The downside is, that the non-kvm case differs in qemu
(but Conny
left here userspace implementation in)
Please note, that the channel subsystem architecture is tightly coupled to the
cpu architecture
(e.g. by having instructions for interaction), so the comparison with PCI is
not fully correct
Christian
- [Qemu-devel] [PATCH v2 3/7] s390/kvm: In-kernel handling of I/O instructions., (continued)
- [Qemu-devel] [PATCH v2 3/7] s390/kvm: In-kernel handling of I/O instructions., Cornelia Huck, 2012/09/04
- [Qemu-devel] [PATCH v2 4/7] s390: Move css limits from drivers/s390/cio/ to include/asm/., Cornelia Huck, 2012/09/04
- [Qemu-devel] [PATCH v2 1/7] s390/kvm: Support for I/O interrupts., Cornelia Huck, 2012/09/04
- [Qemu-devel] [PATCH v2 5/7] s390: Make some css-related structures usable by non-cio code., Cornelia Huck, 2012/09/04
- [Qemu-devel] [PATCH v2 6/7] s390/kvm: Base infrastructure for enabling capabilities., Cornelia Huck, 2012/09/04
- [Qemu-devel] [PATCH v2 7/7] s390/kvm: In-kernel channel subsystem support., Cornelia Huck, 2012/09/04
- [Qemu-devel] [PATCH v2 2/7] s390/kvm: Add support for machine checks., Cornelia Huck, 2012/09/04
- Re: [Qemu-devel] [RFC PATCH v2 0/7] s390: virtual css host support., Avi Kivity, 2012/09/05