[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Requesting a freeze exception for vm_event memory introspection helpers
On Mon, Jul 13, 2015 at 05:10:21PM +0300, Razvan Cojocaru wrote: > On 07/13/2015 04:51 PM, Wei Liu wrote: > > On Mon, Jul 13, 2015 at 10:35:44AM +0300, Razvan Cojocaru wrote: > >> Hello, > >> > >> I'd like to ask for a freeze exception for the "vm_event memory > >> introspection helpers" series. > >> > >> [PATCH 1/3] xen/mem_access: Support for memory-content hiding > >> [PATCH 2/3] xen/vm_event: Support for guest-requested events > >> [PATCH 3/3] xen/vm_event: Deny register writes if refused by > >> vm_event reply > >> > >> All patches have been acked by at least one person (though patch 1 is > >> still under some discussion). > >> > >> 1. Benefits of the series making it in this release: > >> > >> * Probably the most important benefit is that 4.6 development has been > >> very open to refactoring vm_events, and patch 3/3 makes vm_events behave > >> in a consistent manner (all register-write vm_events are pre-write events). > >> > >> * There are 3rd parties interested in these features (Tamas, for > >> example, has already expressed interest in uses of patch 1/1). > >> > > > > These aren't really good arguments for getting this in for 4.6. It would > > be easy for you and Tamas to carry three patches for a while. > > > > What are the impact to end users (end users -- meaning either system > > administrator that sets up Xen and other developers who want to use the > > new interface you introduce)? Does this series consist of the last > > missing pieces of a feature? > > Not just missing pieces of a feature, the guest-requested (formerly > VMCALL) vm_event patch is crucial for memory introspection, and without > the first patch it's very difficult to resume monitoring Windows guests > that have been put in hybernate-mode (instead of powered off). > Right, so with these three patches, memory introspection is a complete feature (as in, to cover most use cases)? Or is it still a work in progress even after these patches are merged? > I don't follow the impact question, sorry. If an administrator doesn't > use these features, the impact (in terms of speed and resources) should > be next to nothing. > OK, let me be specific. If I'm to build a product by either using Xen as out-of-box virtualisation platform or building my own software on top of Xen, would it make any *big* difference if I have your three patches? The "big difference" is the impact (benefit) I'm looking at, from users' point of view. > If a freeze exception for the whole series is not an option at this > point, would it be appropriate to just drop patches requiring more > review and get the more acked ones in? > I'm not saying it's not possible. I'm trying to make sense of what is going on at the moment. Maybe other maintainers can help enlighten me and express their preference? And I guess with your maintainer's hat on it would be a "yes, let's merge them" from you. :-) Wei. > > Thanks, > Razvan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |