2017-03-28 13:54 GMT+02:00 Wei Liu <wei.liu2@citrix.com>:

> On Tue, Mar 28, 2017 at 10:21:14AM +0100, Lars Kurth wrote:
> > Hi all,
> >
> > I wanted to add a few thoughts here, as this is clearly one of the
> harder tasks.
>
> It's really hard. I don't even expect an experienced Xen developer to be
> able to finish all three goals in three months.
>
> Felix, don't feel frustrated if you don't have everything figured out
> because even I have not had everything figured out. ;-)
>
> >
> > > On 27 Mar 2017, at 14:07, Felix Schmoll <eggi.innovations@gmail.com>
> wrote:
> > >
> > > 2017-03-26 15:04 GMT+02:00 Wei Liu <wei.liu2@citrix.com <mailto:
> wei.liu2@citrix.com>>:
> > > On Sun, Mar 26, 2017 at 01:33:08PM +0200, Felix Schmoll wrote:
> > > [...]
> > > > > So just one last time to be clear about this: You can't just ignore
> > > > interrupts and write all other edges to a shared memory region, like
> the
> > > > KCOV feature the syzkaller uses does,
> > >
> > > Yes, you can.
> > >
> > > Since you mention that, let's break things down a bit more.
> > >
> > > [snip]
> > >
> > > Feel free to speak your thought. This project is meant to be beneficial
> > > to both you and the Xen project. I would be quite delighted to hear
> your
> > > understanding of the project.
> > >
> > > Principally I would be fine with either the tracing or the
> > > prototype, I find it however much more difficult to imagine what
> > > successfully implementing the tracing would look like and how to
> > > write a good proposal that goes into specifics. Writing a
> > > proof-of-concept/prototype is easier in that regard as success would
> > > be just defined by "does it run".
> >
> > I think there may be other possibilities to structure a proposal, e.g.
> > a prototype (or set of experiments) followed by a design and/or gap
> > analysis that could be community reviewed (and checked into our docs
> > tree). We could also build in a blog post (or similar). The challenge
> > is to come up with a structure that ensures that we make progress on
> > understanding the problem space and that you have something to show
> > and refer to at the end of the project.
> >
> > I am just throwing this in as a possibility, but obviously Wei would
> > have to agree with it.
> >
>
> Yes, that's doable.
>
> I don't think we need to necessarily narrow down the deliverables to
> "code" or "patch". I agree having some incomplete code and a doc in the
> end is acceptable to me.
>
> I think up to this point we have clear understanding of at least one of
> the components (the tracing bit). That could be the first level
> deliverable. The component to bridge the fuzzer and the hypervisor is
> not yet clear, but I think a prototype for that is possible.
>
> > > What I'm having in my mind right now is still a rather vague notion
> > > of how the tracing output looks like and an a bunch of ideas on what
> > > afl and syzkaller do, combined with huge gaps in how Xen "really"
> > > works. That will certainly start to clear up once I start really
> > > digging into it, but until then I have to rely mostly on your
> > > intuition in terms of what is realistic in what timeframe.
> >
> > I would maybe suggest that you and Wei have a discussion on IRC to
> > discuss the pro's and con's of the two different approaches and to see
> > what is realistic.
> >
>
> Yes. That would be good.
>

I'm free every afternoon this week (German time, I suppose you're in
Europe), so just let me know at least three hours in advance when you're
free
to have a chat.

Felix


> > > Now if I have to decide between the two, I'd still prefer the
> > > tracing, since on the one hand being the author of a hypercall seems
> > > to be pretty cool, and on the other hand learning the actual
> > > contribution process and writing something ready for deployment
> > > seems much more valuable.
> >
> > It is also worth noting that the contribution process for a design or
> > similar would be the same than for code (we tend to store such
> > documents in [xen.git] / docs ).
> >
>
> Correct.
>
> Wei.
>