qemu-block
[Top][All Lists]
Advanced

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

Re: [PATCH 2/5] libvduse: Add VDUSE (vDPA Device in Userspace) library


From: Stefan Hajnoczi
Subject: Re: [PATCH 2/5] libvduse: Add VDUSE (vDPA Device in Userspace) library
Date: Tue, 8 Feb 2022 08:02:50 +0000

On Tue, Feb 08, 2022 at 02:42:41PM +0800, Yongji Xie wrote:
> On Mon, Feb 7, 2022 at 10:01 PM Stefan Hajnoczi <stefanha@redhat.com> wrote:
> >
> > On Tue, Jan 25, 2022 at 09:17:57PM +0800, Xie Yongji wrote:
> > > +int vduse_dev_handler(VduseDev *dev)
> > > +{
> > > +    struct vduse_dev_request req;
> > > +    struct vduse_dev_response resp = { 0 };
> > > +    VduseVirtq *vq;
> > > +    int i, ret;
> > > +
> > > +    ret = read(dev->fd, &req, sizeof(req));
> >
> > This file descriptor is blocking? I guess the assumption is that the
> > kernel VDUSE code always enqueues at least one struct vduse_dev_request,
> > so userspace will not block when the file descriptor becomes readable?
> >
> 
> Yes, that's true. We can always get one entire request if the file
> descriptor becomes readable.

Okay, then the code is fine. We trust the kernel not to block us. While
it is possible to get spurious select(2)/poll(2) ready file descriptors
in the general case (e.g. multiple processes monitoring the same file),
I don't think that can happen in this case.

Attachment: signature.asc
Description: PGP signature


reply via email to

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