On Monday 16 March 2015 18:18:22 Razvan Cojocaru wrote: > On 03/16/2015 06:00 PM, Lars Kurth wrote: > > > >> On 16 Mar 2015, at 13:01, Mihai Donțu wrote: > >> > >> On Thu, 12 Mar 2015 10:21:56 +0000 wei.liu2@citrix.com wrote: > >>> We are now two months into 4.6 development window. This is an email to keep > >>> track of all the patch series I gathered. It is by no means complete and / or > >>> acurate. Feel free to reply this email with new projects or correct my > >>> misunderstanding. > >>> > >>> = Timeline = > >>> > >>> We are planning on a 9-month release cycle, but we could also release a bit > >>> earlier if everything goes well (no blocker, no critical bug). > >>> > >>> * Development start: 6 Jan 2015 > >>> <=== We are here ===> > >>> * Feature Freeze: 10 Jul 2015 > >>> * RCs: TBD > >>> * Release Date: 9 Oct 2015 (could release earlier) > >>> > >>> The RCs and release will of course depend on stability and bugs, and > >>> will therefore be fairly unpredictable. > >>> > >>> Bug-fixes, if Acked-by by maintainer, can go anytime before the First > >>> RC. Later on we will need to figure out the risk of regression/reward > >>> to eliminate the possiblity of a bug introducing another bug. > >>> > >>> = Prognosis = > >>> > >>> The states are: none -> fair -> ok -> good -> done > >>> > >>> none - nothing yet > >>> fair - still working on it, patches are prototypes or RFC > >>> ok - patches posted, acting on review > >>> good - some last minute pieces > >>> done - all done, might have bugs > >>> > >>> = Bug Fixes = > >>> > >>> Bug fixes can be checked in without a freeze exception throughout the > >>> freeze, unless the maintainer thinks they are particularly high > >>> risk. In later RC's, we may even begin rejecting bug fixes if the > >>> broken functionality is small and the risk to other functionality is > >>> high. > >>> > >>> Document changes can go in anytime if the maintainer is OK with it. > >>> > >>> These are guidelines and principles to give you an idea where we're coming > >>> from; if you think there's a good reason why making an exception for you will > >>> help us make Xen better than not doing so, feel free to make your case. > >>> > >>> [...] > >> > >> I have been meaning to write this email for a while now, just to let > >> everyone know we're working on a couple more patches related to VM > >> introspection. They are not as big as our initial ones, but they do > >> bring in new functionality. > > > > Mihai, > > it would make Wei's life easier if you could provide headlines for those patches. That way they can be tracked before you post them > > For my part, the patches are: > > 1. xen: Add support for XSETBV vm_events > > This is basically VMX support for sending out an event on VMEXIT / > EXIT_REASON_XSETBV. Additional information sent out is the XCR (the > value of ECX). > > 2. xen: Support hybernating guests > > This patch cover two areas: A) send data (just a regular blob / buffer) > back to the HV in the vm_event response, and B) have that data returned > by the read function when emulating an instruction. Unless we do this, > monitored guests won't be able to properly wake up from hybernation. > > 3. xen: Support for VMCALL-based vm_events > > This is a modification of the VMCALL patch in my original RFC series, > which got dropped last year. The modification takes into account Andrew > Cooper's suggestion to just use a hypercall: > > http://lists.xen.org/archives/html/xen-devel/2014-07/msg01677.html > > 4. xen: Deny MSR writes if refused by the vm_event reply > > Preempt MSR writes that the monitoring application decides are evil. > > 5. xen: Implement actual write of CR values on xc_vcpu_setcontext() > > Although libxc's API leads one to believe that all info in the context > will be set for the guest, the CR values were actually ignored for HVM > guests. This patch addresses that problem. > > Hope this helps, Mihai will complete the picture with the rest. 6. xmalloc: pool integrity This is a simple mechanism that gives an early heads-up that the xen 'heap' has been corrupted. 7. tools: coding-style auto-adjustments This is not really related to memory introspection, it's just a script around clang-format which I put together while working on the introspection. It received positive feedback, but is a bit problematic for users of 'older' distributions (clang-format is rather new). 8. x86_emulate: dump the opcodes of unsupported instructions This is something I have not yet started to work, but I feel it will help me to easily extend the emulator, but dumping the opcodes of unsupported instructions (in debug mode). This way I can pasted them, dump the instruction with ndisasm or the like, and then proceed to making the proper adjustments. There was an even better idea from Andrew to ask the KVM folks to join forces into a common x86 emulator (since they've started from an older version of Xen's), but we're a bit time constrained now. :-( 9. x86_emulate: add support for unsupported instructions This should make Jan and the other folks happy, since they rejected our initial idea of a generic workaround and instead wanted us to improve the existing emulator. I don't know yet how much of an effort this will be. We will need a lot of testing to find all cases in which we VMEXIT and need to emulate the current instruction in order to prevent it from writing in memory. This is likely to turn into a set of patches. Regards, -- Mihai Donțu