2017-03-28 13:54 GMT+02:00 Wei Liu <wei.l...@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.innovati...@gmail.com> > wrote: > > > > > > 2017-03-26 15:04 GMT+02:00 Wei Liu <wei.l...@citrix.com <mailto: > wei.l...@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. >
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
