From: "Michael S. Tsirkin" <mst@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: virtualization@lists.osdl.org
Subject: Re: INDIRECT and NEXT
Date: Thu, 22 Oct 2009 11:37:45 +0200 [thread overview]
Message-ID: <20091022093745.GA27765@redhat.com> (raw)
In-Reply-To: <200910191304.20748.rusty@rustcorp.com.au>
On Mon, Oct 19, 2009 at 01:04:20PM +1030, Rusty Russell wrote:
> On Mon, 5 Oct 2009 01:07:34 am Michael S. Tsirkin wrote:
> > Hi!
> > I note that chaining INDIRECT descriptors with NEXT
> > currently is broken in lguest, because current
> > ring index gets overwritten.
>
> I agree this should be fixed, but not quite sure what you're referring to.
>
> I could force indirect and reproduce it, but I figure asking you for details
> would be more efficient :)
>
> Thanks!
> Rusty.
I refer to this code in lguest:
/*
* If this is an indirect entry, then this buffer contains a descriptor
* table which we handle as if it's any normal descriptor chain.
*/
if (desc[i].flags & VRING_DESC_F_INDIRECT) {
if (desc[i].len % sizeof(struct vring_desc))
errx(1, "Invalid size for indirect buffer table");
max = desc[i].len / sizeof(struct vring_desc);
desc = check_pointer(desc[i].addr, desc[i].len);
i = 0;
}
do {
/* Grab the first descriptor, and check it's OK. */
iov[*out_num + *in_num].iov_len = desc[i].len;
iov[*out_num + *in_num].iov_base
= check_pointer(desc[i].addr, desc[i].len);
/* If this is an input descriptor, increment that count. */
if (desc[i].flags & VRING_DESC_F_WRITE)
(*in_num)++;
else {
/*
* If it's an output descriptor, they're all supposed
* to come before any input descriptors.
*/
if (*in_num)
errx(1, "Descriptor has out after in");
(*out_num)++;
}
/* If we've got too many, that implies a descriptor loop. */
if (*out_num + *in_num > max)
errx(1, "Looped descriptor");
} while ((i = next_desc(desc, i, max)) != max);
Imagine an indirect entry where NEXT bit is also set.
This would be useful for when we can't fit a descriptor
in a single indirect entry. This won't work now because
we set 'i = 0' above. A solution would be to move handling
indirect entry out to a separate function.
--
MST
next prev parent reply other threads:[~2009-10-22 9:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20091004143734.GB17578@redhat.com>
2009-10-19 2:34 ` INDIRECT and NEXT Rusty Russell
2009-10-22 9:37 ` Michael S. Tsirkin [this message]
2009-10-23 3:31 ` Rusty Russell
2009-10-23 6:36 ` Michael S. Tsirkin
2009-10-23 9:20 ` Rusty Russell
2009-10-23 9:30 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091022093745.GA27765@redhat.com \
--to=mst@redhat.com \
--cc=rusty@rustcorp.com.au \
--cc=virtualization@lists.osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.