[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <ac4b7441-2d17-922b-695e-98c01d87cd42@linux.vnet.ibm.com>
Date: Tue, 24 Apr 2018 10:40:56 +0200
From: Pierre Morel <pmorel@...ux.vnet.ibm.com>
To: Dong Jia Shi <bjsdjshi@...ux.vnet.ibm.com>
Cc: pasic@...ux.vnet.ibm.com, linux-s390@...r.kernel.org,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
cohuck@...hat.com
Subject: Re: [PATCH 01/10] vfio: ccw: Moving state change out of IRQ context
On 24/04/2018 08:54, Dong Jia Shi wrote:
> * Pierre Morel <pmorel@...ux.vnet.ibm.com> [2018-04-19 16:48:04 +0200]:
>
> [...]
>
>> @@ -94,9 +83,15 @@ static void vfio_ccw_sch_io_todo(struct work_struct *work)
>> static void vfio_ccw_sch_irq(struct subchannel *sch)
>> {
>> struct vfio_ccw_private *private = dev_get_drvdata(&sch->dev);
>> + struct irb *irb = this_cpu_ptr(&cio_irb);
>>
>> inc_irq_stat(IRQIO_CIO);
>> - vfio_ccw_fsm_event(private, VFIO_CCW_EVENT_INTERRUPT);
>> + memcpy(&private->irb, irb, sizeof(*irb));
>> +
>> + WARN_ON(work_pending(&private->io_work));
> Hmm, why do we need this?
The current design insure that we have not two concurrent SSCH requests.
How ever I want here to track spurious interrupt.
If we implement cancel, halt or clear requests, we also may trigger (AFAIU)
a second interrupts depending on races between instructions, controller
and device.
We do not need it strongly.
>
>> + queue_work(vfio_ccw_work_q, &private->io_work);
>> + if (private->completion)
>> + complete(private->completion);
>> }
>>
>> static int vfio_ccw_sch_probe(struct subchannel *sch)
> [...]
>
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
Powered by blists - more mailing lists