Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6;
References: <cover.1693311370.git.viresh.kumar@linaro.org>
 <52b07a3861a34fb0deb6251bae8bd885815c6944.1693311370.git.viresh.kumar@linaro.org>
 <fb79fa9a-e91c-4bb7-8aee-c384b99df953@suse.com>
 <20231005063231.vqwhfnlc64phwmto@vireshk-i7>
User-agent: mu4e 1.11.22; emacs 29.1.50
From:   Alex =?utf-8?Q?Benn=C3=A9e?= <alex.bennee@linaro.org>
To:     Viresh Kumar <viresh.kumar@linaro.org>
Cc:     Juergen Gross <jgross@suse.com>,
        Stefano Stabellini <sstabellini@kernel.org>,
        Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        stratos-dev@op-lists.linaro.org,
        Erik Schilling <erik.schilling@linaro.org>,
        Manos Pitsidianakis <manos.pitsidianakis@linaro.org>,
        Mathieu Poirier <mathieu.poirier@linaro.org>,
        linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/2] xen: privcmd: Add support for ioeventfd
Date:   Mon, 09 Oct 2023 10:40:48 +0100
In-reply-to: <20231005063231.vqwhfnlc64phwmto@vireshk-i7>
Message-ID: <877cnwqg27.fsf@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


Viresh Kumar <viresh.kumar@linaro.org> writes:

> On 29-09-23, 07:46, Juergen Gross wrote:
>> On 29.08.23 14:29, Viresh Kumar wrote:
>> > +static irqreturn_t ioeventfd_interrupt(int irq, void *dev_id)
>> > +{
>> > +	struct ioreq_port *port =3D dev_id;
>> > +	struct privcmd_kernel_ioreq *kioreq =3D port->kioreq;
>> > +	struct ioreq *ioreq =3D &kioreq->ioreq[port->vcpu];
>> > +	struct privcmd_kernel_ioeventfd *kioeventfd;
>> > +	unsigned int state =3D STATE_IOREQ_READY;
>> > +
>> > +	if (ioreq->state !=3D STATE_IOREQ_READY ||
>> > +	    ioreq->type !=3D IOREQ_TYPE_COPY || ioreq->dir !=3D IOREQ_WRITE)
>> > +		return IRQ_NONE;
>> > +
>> > +	smp_mb();
>> > +	ioreq->state =3D STATE_IOREQ_INPROCESS;
>> > +
>> > +	mutex_lock(&kioreq->lock);
>> > +	list_for_each_entry(kioeventfd, &kioreq->ioeventfds, list) {
>> > +		if (ioreq->addr =3D=3D kioeventfd->addr + VIRTIO_MMIO_QUEUE_NOTIFY =
&&
>> > +		    ioreq->size =3D=3D kioeventfd->addr_len &&
>> > +		    (ioreq->data & QUEUE_NOTIFY_VQ_MASK) =3D=3D kioeventfd->vq) {
>> > +			eventfd_signal(kioeventfd->eventfd, 1);
>> > +			state =3D STATE_IORESP_READY;
>> > +			break;
>> > +		}
>> > +	}
>> > +	mutex_unlock(&kioreq->lock);
>> > +
>> > +	smp_mb();
>>=20
>> Is this really needed after calling mutex_unlock()? I think you are tryi=
ng to
>> avoid any accesses to go past ioreq->state modification. If so, add a co=
mment
>> (either why you need the barrier, or that you don't need it due to the u=
nlock).
>
> Right, want all writes to finish before updating state.

I thought generally sync points act as full barriers. Doing a bunch of
grepping I think ends at:

  static __always_inline bool __mutex_unlock_fast(struct mutex *lock)
  {
          unsigned long curr =3D (unsigned long)current;

          return atomic_long_try_cmpxchg_release(&lock->owner, &curr, 0UL);
  }

so you should already have completed your writes by that point.

>
>> In general, shouldn't the state be checked and modified in the locked ar=
ea?
>
> The handler runs separately for each vcpu and shouldn't run in parallel f=
or the
> same vcpu. And so only one thread should ever be accessing ioreq port str=
ucture.
>
> The lock is there to protect the ioeventfds list (as mentioned in struct
> declaration) against parallel access, as threads for different vcpus may =
end up
> accessing it simultaneously.


--=20
Alex Benn=C3=A9e
Virtualisation Tech Lead @ Linaro