It appears that these commands (and code backing these commands) do no sanity checking and could potentially get the system to crash if the values picked are not appropriate. For instance one can set the mem-max value to a value that appears reasonable and basically render the machine unusable. Consider the case where max value being set is less than what is currently allocated to the domain. All subsequent allocations will fail and these failures are considered fatal in Linux (look at hypervisor.c). Once the domain is up, does it even make sense to lower the max_mem parameter without risking crashing the system? Minimally, we should ensure that the mem_max value is at least equal to what the current domain allocation is. I have a trivial patch to xen that implements this logic. This patch fixes a bug we have in our bugzilla against SLES10. Would there be interest in such a patch. Regards, K. Y _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ky Srinivasan wrote:> It appears that these commands (and code backing these commands) do no > sanity checking and could potentially get the system to crash if the > values picked are not appropriate. For instance one can set the mem-max > value to a value that appears reasonable and basically render the > machine unusable. Consider the case where max value being set is less > than what is currently allocated to the domain. All subsequent > allocations will fail and these failures are considered fatal in Linux > (look at hypervisor.c). Once the domain is up, does it even make sense > to lower the max_mem parameter without risking crashing the system? > Minimally, we should ensure that the mem_max value is at least equal to > what the current domain allocation is. I have a trivial patch to xen > that implements this logic. This patch fixes a bug we have in our > bugzilla against SLES10. Would there be interest in such a patch. >I''m slightly concerned about the subtle race condition it would introduce. If there''s no reason to set max-mem below current reservation (if it causes crashes which I don''t really understand why it would) then I think it would be something best enforced within the hypervisor. Why, exactly, would setting max-mem below the current reservation cause problems in the guest? I guess it may fail because of grant transfer ops (in which case, we really ought to enforce it at the hypervisor level). Regards, Anthony Liguori> Regards, > > K. Y > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 14 Apr 2006, at 02:48, Anthony Liguori wrote:> I''m slightly concerned about the subtle race condition it would > introduce. If there''s no reason to set max-mem below current > reservation (if it causes crashes which I don''t really understand why > it would) then I think it would be something best enforced within the > hypervisor. > > Why, exactly, would setting max-mem below the current reservation > cause problems in the guest? I guess it may fail because of grant > transfer ops (in which case, we really ought to enforce it at the > hypervisor level).xen_create_contiguous_region() will get *quite* upset if it gives up memory pages to Xen in good faith and gets nothing in return. :-) Not allowing max allocation to be set lower than current allocation sounds like a sensible enforcement for the hypervisor, and I think that should avoid crashes. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
The patch I have is for the hypervisor. The reason for the crash is the current Linux code cannot deal with a failure when it tries to give up a contiguous region and repopulate the the region with potentially non-contiguous pages (refer to hypervisor.c for this). Regards, K. Y>>> Anthony Liguori <aliguori@us.ibm.com> 04/13/06 9:48 pm >>>Ky Srinivasan wrote:> It appears that these commands (and code backing these commands) dono> sanity checking and could potentially get the system to crash if the > values picked are not appropriate. For instance one can set the mem-max> value to a value that appears reasonable and basically render the > machine unusable. Consider the case where max value being set isless> than what is currently allocated to the domain. All subsequent > allocations will fail and these failures are considered fatal inLinux> (look at hypervisor.c). Once the domain is up, does it even makesense> to lower the max_mem parameter without risking crashing the system? > Minimally, we should ensure that the mem_max value is at least equalto> what the current domain allocation is. I have a trivial patch to xen > that implements this logic. This patch fixes a bug we have in our > bugzilla against SLES10. Would there be interest in such a patch. >I''m slightly concerned about the subtle race condition it would introduce. If there''s no reason to set max- mem below current reservation (if it causes crashes which I don''t really understand why it would) then I think it would be something best enforced within the hypervisor. Why, exactly, would setting max- mem below the current reservation cause problems in the guest? I guess it may fail because of grant transfer ops (in which case, we really ought to enforce it at the hypervisor level). Regards, Anthony Liguori> Regards, > > K. Y > > > > _______________________________________________ > Xen- devel mailing list > Xen- devel@lists.xensource.com > http://lists.xensource.com/xen- devel >_______________________________________________ Xen- devel mailing list Xen- devel@lists.xensource.com http://lists.xensource.com/xen- devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel