On Wed, 22 Apr 2015 11:16:00 +0200 Alexander Graf <ag...@suse.de> wrote:
> On 04/22/2015 10:32 AM, Cornelia Huck wrote: > > On Tue, 21 Apr 2015 21:09:05 +0200 > > Alexander Graf <ag...@suse.de> wrote: > > > >> On 04/17/2015 09:52 AM, Cornelia Huck wrote: > >>> From: Xu Wang <gesa...@linux.vnet.ibm.com> > >>> > >>> 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 <gesa...@linux.vnet.ibm.com> > >>> Reviewed-by: David Hildenbrand <d...@linux.vnet.ibm.com> > >>> Signed-off-by: Cornelia Huck <cornelia.h...@de.ibm.com> > >> 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. I don't know... having a device for e.g. a hypercall that changes some timing characteristics feels a bit artificial to me.
