qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/6] s390/kvm: diag288 instruction interception


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH 3/6] s390/kvm: diag288 instruction interception and handling
Date: Wed, 22 Apr 2015 11:16:00 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

On 04/22/2015 10:32 AM, Cornelia Huck wrote:
On Tue, 21 Apr 2015 21:09:05 +0200
Alexander Graf <address@hidden> wrote:

On 04/17/2015 09:52 AM, Cornelia Huck wrote:
From: Xu Wang <address@hidden>

Intercept the diag288 requests from kvm guests, and hand the
requested command to the diag288 watchdog device for further
handling.

Signed-off-by: Xu Wang <address@hidden>
Reviewed-by: David Hildenbrand <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>
We're getting a lot of random devices allocating diag intercepts. Can't
we make this an actual interface, similar to the hypercall registration
on sPAPR?
I've looked at the sPAPR hcall code, and it seems to basically provide
a table with a nice registration interface (we already use something
similar for the diagnose 500 virtio subcodes, btw.)

While we could move our basic diagnose handling over to a table-like
approach and registering new diagnoses, I think this is orthogonal to
introducing a diag288 watchdog device: It just makes sense to model the
watchdog as a device that just happens to be poked via a diagnose. If
we introduce any further diagnoses to manipulate timing etc., I agree
we don't want to add a device for each of these.

My thinking was in the opposite level. I really like the idea of having separate devices for each function. But I think that they should be completely self-contained with well defined interfaces.


Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]