Re: [Xen-devel] Xen 4.6 Development Update (two months reminder)

[Mihai DonÈu <mdontu@xxxxxxxxxxxxxxx>]

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 <mdontu@xxxxxxxxxxxxxxx> wrote:
> >>
> >> On Thu, 12 Mar 2015 10:21:56 +0000 wei.liu2@xxxxxxxxxx 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

Attachment: pgpBGlpcKm2A_.pgp
Description: OpenPGP digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel