On 01/30/2019 08:29 AM, Cornelia Huck wrote:
On Tue, 29 Jan 2019 20:39:33 +0100
Halil Pasic wrote:
On Tue, 29 Jan 2019 10:58:40 +0100
Cornelia Huck wrote:
The problem I see with the let the hardware sort it out is that, for
that to work, we need to juggle multiple translations simultaneo
On Tue, 29 Jan 2019 20:39:33 +0100
Halil Pasic wrote:
> On Tue, 29 Jan 2019 10:58:40 +0100
> Cornelia Huck wrote:
>
> > > > > The problem I see with the let the hardware sort it out is that, for
> > > > > that to work, we need to juggle multiple translations simultaneously
> > > > > (or am I wr
On Tue, 29 Jan 2019 10:58:40 +0100
Cornelia Huck wrote:
> > > > The problem I see with the let the hardware sort it out is that, for
> > > > that to work, we need to juggle multiple translations simultaneously
> > > > (or am I wrong?). Doing that does not appear particularly simple to
> > > > me.
On Tue, 29 Jan 2019 09:14:40 -0500
Eric Farman wrote:
> On 01/29/2019 05:20 AM, Cornelia Huck wrote:
> > On Mon, 28 Jan 2019 16:48:10 -0500
> > Eric Farman wrote:
> >
> >> On 01/28/2019 02:15 PM, Halil Pasic wrote:
> >>> On Mon, 28 Jan 2019 18:09:48 +0100
> >>> Cornelia Huck wrote:
> >
On 01/29/2019 05:20 AM, Cornelia Huck wrote:
On Mon, 28 Jan 2019 16:48:10 -0500
Eric Farman wrote:
On 01/28/2019 02:15 PM, Halil Pasic wrote:
On Mon, 28 Jan 2019 18:09:48 +0100
Cornelia Huck wrote:
I guess if
the ssch() returns with non cc == 0 the CP_PENDING ---IRQ---> IDLE
transitio
On Mon, 28 Jan 2019 16:48:10 -0500
Eric Farman wrote:
> On 01/28/2019 02:15 PM, Halil Pasic wrote:
> > On Mon, 28 Jan 2019 18:09:48 +0100
> > Cornelia Huck wrote:
> I guess if
> > the ssch() returns with non cc == 0 the CP_PENDING ---IRQ---> IDLE
> > transition
> > won't take place. And I guess
On Mon, 28 Jan 2019 20:15:48 +0100
Halil Pasic wrote:
> On Mon, 28 Jan 2019 18:09:48 +0100
> Cornelia Huck wrote:
>
> > On Fri, 25 Jan 2019 15:01:01 +0100
> > Halil Pasic wrote:
> >
> > > On Fri, 25 Jan 2019 13:58:35 +0100
> > > Cornelia Huck wrote:
> >
> > > > - The code should not b
On Mon, 28 Jan 2019 20:30:00 +0100
Halil Pasic wrote:
> On Mon, 28 Jan 2019 18:13:55 +0100
> Cornelia Huck wrote:
>
> > On Fri, 25 Jan 2019 17:04:04 +0100
> > Halil Pasic wrote:
> >
> > > Do we expect userspace/QEMU to fence the bad scenarios as tries to do
> > > today, or is this supposed
On 01/28/2019 12:24 PM, Cornelia Huck wrote:
On Fri, 25 Jan 2019 10:57:38 -0500
Eric Farman wrote:
On 01/25/2019 07:58 AM, Cornelia Huck wrote:
On Fri, 25 Jan 2019 11:24:37 +0100
Cornelia Huck wrote:
On Thu, 24 Jan 2019 21:37:44 -0500
Eric Farman wrote:
On 01/24/2019 09:25 PM, E
On 01/28/2019 02:15 PM, Halil Pasic wrote:
On Mon, 28 Jan 2019 18:09:48 +0100
Cornelia Huck wrote:
On Fri, 25 Jan 2019 15:01:01 +0100
Halil Pasic wrote:
On Fri, 25 Jan 2019 13:58:35 +0100
Cornelia Huck wrote:
- The code should not be interrupted while we process the channel
progra
On Mon, 28 Jan 2019 18:13:55 +0100
Cornelia Huck wrote:
> On Fri, 25 Jan 2019 17:04:04 +0100
> Halil Pasic wrote:
>
> > Do we expect userspace/QEMU to fence the bad scenarios as tries to do
> > today, or is this supposed to change to hardware should sort out
> > requests whenever possible.
>
>
On Mon, 28 Jan 2019 18:09:48 +0100
Cornelia Huck wrote:
> On Fri, 25 Jan 2019 15:01:01 +0100
> Halil Pasic wrote:
>
> > On Fri, 25 Jan 2019 13:58:35 +0100
> > Cornelia Huck wrote:
>
> > > - The code should not be interrupted while we process the channel
> > > program, do the ssch etc. We wa
On Fri, 25 Jan 2019 15:22:56 -0500
Eric Farman wrote:
> If we come into mdev_write with state=BUSY and we get the lock,
> copy_from_user, and do our jump table we go to fsm_io_busy to set
> ret_code and return -EAGAIN. Why then don't we set the jump table for
> state=NOT_OPER||STANDBY to do s
On Fri, 25 Jan 2019 10:57:38 -0500
Eric Farman wrote:
> On 01/25/2019 07:58 AM, Cornelia Huck wrote:
> > On Fri, 25 Jan 2019 11:24:37 +0100
> > Cornelia Huck wrote:
> >
> >> On Thu, 24 Jan 2019 21:37:44 -0500
> >> Eric Farman wrote:
> >>
> >>> On 01/24/2019 09:25 PM, Eric Farman wrote:
>
On Fri, 25 Jan 2019 17:04:04 +0100
Halil Pasic wrote:
> Do we expect userspace/QEMU to fence the bad scenarios as tries to do
> today, or is this supposed to change to hardware should sort out
> requests whenever possible.
Does my other mail answer that?
> The problem I see with the let the har
On Fri, 25 Jan 2019 15:01:01 +0100
Halil Pasic wrote:
> On Fri, 25 Jan 2019 13:58:35 +0100
> Cornelia Huck wrote:
> > - The code should not be interrupted while we process the channel
> > program, do the ssch etc. We want the caller to try again later (i.e.
> > return -EAGAIN)
(...)
> >
On 01/25/2019 05:24 AM, Cornelia Huck wrote:
On Thu, 24 Jan 2019 21:37:44 -0500
Eric Farman wrote:
On 01/24/2019 09:25 PM, Eric Farman wrote:
On 01/21/2019 06:03 AM, Cornelia Huck wrote:
[1] I think these changes are cool. We end up going into (and staying
in) state=BUSY if we get cc
On 01/25/2019 07:58 AM, Halil Pasic wrote:
On Thu, 24 Jan 2019 21:25:10 -0500
Eric Farman wrote:
private = dev_get_drvdata(mdev_parent_dev(mdev));
- if (private->state != VFIO_CCW_STATE_IDLE)
+ if (private->state == VFIO_CCW_STATE_NOT_OPER ||
+ private->state =
On Fri, 25 Jan 2019 15:21:54 +0100
Cornelia Huck wrote:
> On Fri, 25 Jan 2019 15:01:01 +0100
> Halil Pasic wrote:
>
> > On Fri, 25 Jan 2019 13:58:35 +0100
> > Cornelia Huck wrote:
>
> > > - We currently do not want the user space to submit another channel
> > > program while the first one i
On 01/25/2019 07:58 AM, Cornelia Huck wrote:
On Fri, 25 Jan 2019 11:24:37 +0100
Cornelia Huck wrote:
On Thu, 24 Jan 2019 21:37:44 -0500
Eric Farman wrote:
On 01/24/2019 09:25 PM, Eric Farman wrote:
On 01/21/2019 06:03 AM, Cornelia Huck wrote:
[1] I think these changes are cool. We
On Fri, 25 Jan 2019 15:01:01 +0100
Halil Pasic wrote:
> On Fri, 25 Jan 2019 13:58:35 +0100
> Cornelia Huck wrote:
> > - We currently do not want the user space to submit another channel
> > program while the first one is still in flight. As submitting another
> > one is a valid request, how
On Fri, 25 Jan 2019 13:58:35 +0100
Cornelia Huck wrote:
> On Fri, 25 Jan 2019 11:24:37 +0100
> Cornelia Huck wrote:
>
> > On Thu, 24 Jan 2019 21:37:44 -0500
> > Eric Farman wrote:
> >
> > > On 01/24/2019 09:25 PM, Eric Farman wrote:
> > > >
> > > >
> > > > On 01/21/2019 06:03 AM, Cornelia
On Thu, 24 Jan 2019 21:37:44 -0500
Eric Farman wrote:
> >> @@ -188,25 +192,30 @@ static ssize_t vfio_ccw_mdev_write(struct
> >> mdev_device *mdev,
> >> {
> >> struct vfio_ccw_private *private;
> >> struct ccw_io_region *region;
> >> + int ret;
> >> if (*ppos + count > size
On Fri, 25 Jan 2019 11:24:37 +0100
Cornelia Huck wrote:
> On Thu, 24 Jan 2019 21:37:44 -0500
> Eric Farman wrote:
>
> > On 01/24/2019 09:25 PM, Eric Farman wrote:
> > >
> > >
> > > On 01/21/2019 06:03 AM, Cornelia Huck wrote:
>
> > > [1] I think these changes are cool. We end up going
On Thu, 24 Jan 2019 21:25:10 -0500
Eric Farman wrote:
> > private = dev_get_drvdata(mdev_parent_dev(mdev));
> > - if (private->state != VFIO_CCW_STATE_IDLE)
> > + if (private->state == VFIO_CCW_STATE_NOT_OPER ||
> > + private->state == VFIO_CCW_STATE_STANDBY)
> > return
On Thu, 24 Jan 2019 14:16:21 -0500
Eric Farman wrote:
> On 01/23/2019 08:34 AM, Cornelia Huck wrote:
> > On Wed, 23 Jan 2019 14:06:01 +0100
> > Halil Pasic wrote:
> >
> >> On Wed, 23 Jan 2019 11:34:47 +0100
> >> Cornelia Huck wrote:
> >
> >> Yes, one can usually think of interfaces as c
On Thu, 24 Jan 2019 21:37:44 -0500
Eric Farman wrote:
> On 01/24/2019 09:25 PM, Eric Farman wrote:
> >
> >
> > On 01/21/2019 06:03 AM, Cornelia Huck wrote:
> > [1] I think these changes are cool. We end up going into (and staying
> > in) state=BUSY if we get cc=0 on the SSCH, rather than i
On 01/24/2019 09:25 PM, Eric Farman wrote:
On 01/21/2019 06:03 AM, Cornelia Huck wrote:
Rework handling of multiple I/O requests to return -EAGAIN if
we are already processing an I/O request. Introduce a mutex
to disallow concurrent writes to the I/O region.
The expectation is that userspa
On 01/21/2019 06:03 AM, Cornelia Huck wrote:
Rework handling of multiple I/O requests to return -EAGAIN if
we are already processing an I/O request. Introduce a mutex
to disallow concurrent writes to the I/O region.
The expectation is that userspace simply retries the operation
if it gets -EA
On 01/23/2019 08:34 AM, Cornelia Huck wrote:
On Wed, 23 Jan 2019 14:06:01 +0100
Halil Pasic wrote:
On Wed, 23 Jan 2019 11:34:47 +0100
Cornelia Huck wrote:
Yes, one can usually think of interfaces as contracts: both sides need
to keep their end for things to work as intended. Unfortunate
On 01/24/2019 05:19 AM, Cornelia Huck wrote:
On Thu, 24 Jan 2019 11:08:02 +0100
Pierre Morel wrote:
On 23/01/2019 11:21, Cornelia Huck wrote:
On Tue, 22 Jan 2019 19:33:46 +0100
Halil Pasic wrote:
On Mon, 21 Jan 2019 12:03:51 +0100
Cornelia Huck wrote:
--- a/drivers/s390/cio/vfio
On Thu, 24 Jan 2019 11:19:34 +0100
Cornelia Huck wrote:
> On Thu, 24 Jan 2019 11:08:02 +0100
> Pierre Morel wrote:
>
> > On 23/01/2019 11:21, Cornelia Huck wrote:
> > > On Tue, 22 Jan 2019 19:33:46 +0100
> > > Halil Pasic wrote:
> > >
> > >> On Mon, 21 Jan 2019 12:03:51 +0100
> > >> Corneli
On 24/01/2019 11:19, Cornelia Huck wrote:
On Thu, 24 Jan 2019 11:08:02 +0100
Pierre Morel wrote:
On 23/01/2019 11:21, Cornelia Huck wrote:
On Tue, 22 Jan 2019 19:33:46 +0100
Halil Pasic wrote:
On Mon, 21 Jan 2019 12:03:51 +0100
Cornelia Huck wrote:
--- a/drivers/s390/cio/vfio_ccw_p
On 23/01/2019 11:21, Cornelia Huck wrote:
On Tue, 22 Jan 2019 19:33:46 +0100
Halil Pasic wrote:
On Mon, 21 Jan 2019 12:03:51 +0100
Cornelia Huck wrote:
--- a/drivers/s390/cio/vfio_ccw_private.h
+++ b/drivers/s390/cio/vfio_ccw_private.h
@@ -28,6 +28,7 @@
* @mdev: pointer to the mediated d
On Wed, 23 Jan 2019 14:30:51 +0100
Halil Pasic wrote:
> On Wed, 23 Jan 2019 11:21:12 +0100
> Cornelia Huck wrote:
>
> > On Tue, 22 Jan 2019 19:33:46 +0100
> > Halil Pasic wrote:
> >
> > > On Mon, 21 Jan 2019 12:03:51 +0100
> > > Cornelia Huck wrote:
> > >
> > > > --- a/drivers/s390/cio/
On Thu, 24 Jan 2019 11:08:02 +0100
Pierre Morel wrote:
> On 23/01/2019 11:21, Cornelia Huck wrote:
> > On Tue, 22 Jan 2019 19:33:46 +0100
> > Halil Pasic wrote:
> >
> >> On Mon, 21 Jan 2019 12:03:51 +0100
> >> Cornelia Huck wrote:
> >>
> >>> --- a/drivers/s390/cio/vfio_ccw_private.h
> >>>
On Wed, 23 Jan 2019 11:21:12 +0100
Cornelia Huck wrote:
> On Tue, 22 Jan 2019 19:33:46 +0100
> Halil Pasic wrote:
>
> > On Mon, 21 Jan 2019 12:03:51 +0100
> > Cornelia Huck wrote:
> >
> > > --- a/drivers/s390/cio/vfio_ccw_private.h
> > > +++ b/drivers/s390/cio/vfio_ccw_private.h
> > > @@ -28,
On Wed, 23 Jan 2019 14:06:01 +0100
Halil Pasic wrote:
> On Wed, 23 Jan 2019 11:34:47 +0100
> Cornelia Huck wrote:
> Yes, one can usually think of interfaces as contracts: both sides need
> to keep their end for things to work as intended. Unfortunately the
> vfio-ccw iterface is not a very well
On Wed, 23 Jan 2019 11:34:47 +0100
Cornelia Huck wrote:
> On Tue, 22 Jan 2019 20:03:31 +0100
> Halil Pasic wrote:
>
> > On Tue, 22 Jan 2019 18:26:17 +0100
> > Cornelia Huck wrote:
> >
> > > On Tue, 22 Jan 2019 13:46:12 +0100
> > > Halil Pasic wrote:
>
> > > > Unsolicited interrupts are anot
On Tue, 22 Jan 2019 20:03:31 +0100
Halil Pasic wrote:
> On Tue, 22 Jan 2019 18:26:17 +0100
> Cornelia Huck wrote:
>
> > On Tue, 22 Jan 2019 13:46:12 +0100
> > Halil Pasic wrote:
> > > Unsolicited interrupts are another
> > > piece of cake -- I have no idea how may of those do we get.
> >
>
On Tue, 22 Jan 2019 19:33:46 +0100
Halil Pasic wrote:
> On Mon, 21 Jan 2019 12:03:51 +0100
> Cornelia Huck wrote:
>
> > --- a/drivers/s390/cio/vfio_ccw_private.h
> > +++ b/drivers/s390/cio/vfio_ccw_private.h
> > @@ -28,6 +28,7 @@
> > * @mdev: pointer to the mediated device
> > * @nb: notifi
On Mon, 21 Jan 2019 12:03:51 +0100
Cornelia Huck wrote:
> --- a/drivers/s390/cio/vfio_ccw_private.h
> +++ b/drivers/s390/cio/vfio_ccw_private.h
> @@ -28,6 +28,7 @@
> * @mdev: pointer to the mediated device
> * @nb: notifier for vfio events
> * @io_region: MMIO region to input/output I/O arg
On Tue, 22 Jan 2019 12:17:37 +0100
Halil Pasic wrote:
> On Tue, 22 Jan 2019 11:29:26 +0100
> Cornelia Huck wrote:
>
> > On Mon, 21 Jan 2019 21:20:18 +0100
> > Halil Pasic wrote:
> >
> > > On Mon, 21 Jan 2019 12:03:51 +0100
> > > Cornelia Huck wrote:
> > >
> > > > Rework handling of mult
On Tue, 22 Jan 2019 18:26:17 +0100
Cornelia Huck wrote:
> On Tue, 22 Jan 2019 13:46:12 +0100
> Halil Pasic wrote:
>
> > On Tue, 22 Jan 2019 12:53:22 +0100
> > Cornelia Huck wrote:
> >
> > > On Tue, 22 Jan 2019 12:17:37 +0100
> > > Halil Pasic wrote:
> > >
> > > > On Tue, 22 Jan 2019 11:29
On Tue, 22 Jan 2019 12:53:22 +0100
Cornelia Huck wrote:
> On Tue, 22 Jan 2019 12:17:37 +0100
> Halil Pasic wrote:
>
> > On Tue, 22 Jan 2019 11:29:26 +0100
> > Cornelia Huck wrote:
> >
> > > On Mon, 21 Jan 2019 21:20:18 +0100
> > > Halil Pasic wrote:
> > >
> > > > On Mon, 21 Jan 2019 12:03
On Tue, 22 Jan 2019 13:46:12 +0100
Halil Pasic wrote:
> On Tue, 22 Jan 2019 12:53:22 +0100
> Cornelia Huck wrote:
>
> > On Tue, 22 Jan 2019 12:17:37 +0100
> > Halil Pasic wrote:
> >
> > > On Tue, 22 Jan 2019 11:29:26 +0100
> > > Cornelia Huck wrote:
> > >
> > > > On Mon, 21 Jan 2019 21:
On Tue, 22 Jan 2019 11:29:26 +0100
Cornelia Huck wrote:
> On Mon, 21 Jan 2019 21:20:18 +0100
> Halil Pasic wrote:
>
> > On Mon, 21 Jan 2019 12:03:51 +0100
> > Cornelia Huck wrote:
> >
> > > Rework handling of multiple I/O requests to return -EAGAIN if
> > > we are already processing an I/O re
On Mon, 21 Jan 2019 21:20:18 +0100
Halil Pasic wrote:
> On Mon, 21 Jan 2019 12:03:51 +0100
> Cornelia Huck wrote:
>
> > Rework handling of multiple I/O requests to return -EAGAIN if
> > we are already processing an I/O request. Introduce a mutex
> > to disallow concurrent writes to the I/O regi
On Mon, 21 Jan 2019 12:03:51 +0100
Cornelia Huck wrote:
> Rework handling of multiple I/O requests to return -EAGAIN if
> we are already processing an I/O request. Introduce a mutex
> to disallow concurrent writes to the I/O region.
>
> The expectation is that userspace simply retries the operat
Rework handling of multiple I/O requests to return -EAGAIN if
we are already processing an I/O request. Introduce a mutex
to disallow concurrent writes to the I/O region.
The expectation is that userspace simply retries the operation
if it gets -EAGAIN.
We currently don't allow multiple ssch requ
50 matches
Mail list logo
