Keir, I''m having the impression that this c/s unintentionally modifies behavior in certain ways: - map_vcpu_info() no longer sets evtchn_upcall_mask for a newly mapped info struct - VCPUOP_initialise no longer fails when a vCPU didn''t have a proper info struct installed - the changes to xen/common/event_channel.c make it so that dummy_vcpu_info can be written to, and hence subsequently initialized vcpu_info structs would have unpredictable initial state Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 02/11/2009 08:17, "Jan Beulich" <JBeulich@novell.com> wrote:> - map_vcpu_info() no longer sets evtchn_upcall_mask for a newly mapped > info struct > - VCPUOP_initialise no longer fails when a vCPU didn''t have a proper info > struct installed > - the changes to xen/common/event_channel.c make it so that > dummy_vcpu_info can be written to, and hence subsequently initialized > vcpu_info structs would have unpredictable initial stateThanks, I''ve applied fixes as c/s 20390. The first issue is a genuine bug. The second I think is not a critical issue, but since no good comes of starting a vcpu without its own info structure, we may as well check-and-fail in this case. The third issue I think does not matter, since the first two fixes ensure that a vcpu will have a cleanly-initialised info structure before it ever runs. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 11/02/09 00:17, Jan Beulich wrote:> Keir, > > I''m having the impression that this c/s unintentionally modifies behavior in > certain ways: > > - map_vcpu_info() no longer sets evtchn_upcall_mask for a newly mapped > info struct > - VCPUOP_initialise no longer fails when a vCPU didn''t have a proper info > struct installed > - the changes to xen/common/event_channel.c make it so that > dummy_vcpu_info can be written to, and hence subsequently initialized > vcpu_info structs would have unpredictable initial state >What''s the real changeset id you''re referring to? The small-integer numbers are only locally valid (and globally by coincidence), and 20384 here doesn''t seem at all relevant to your points. I you''re referring to f74f0c1ae8ab, which is 21773 in my tree... J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 02/11/2009 21:08, "Jeremy Fitzhardinge" <jeremy@goop.org> wrote:> What''s the real changeset id you''re referring to? The small-integer > numbers are only locally valid (and globally by coincidence), and 20384 > here doesn''t seem at all relevant to your points. > > I you''re referring to f74f0c1ae8ab, which is 21773 in my tree...Yes, that''s the one. K. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> Jeremy Fitzhardinge <jeremy@goop.org> 02.11.09 22:08 >>> >What''s the real changeset id you''re referring to? The small-integer >numbers are only locally valid (and globally by coincidence), and 20384 >here doesn''t seem at all relevant to your points.Hmm, I think http://xenbits.xensource.com/xen-unstable.hg can reasonably be considered a canonical reference, and hence I would assume that using the small number ids is uniquely identifying a c/s. Furthermore, using the full ids doesn''t allow easily judging how long ago the referred to c/s was committed, including immediately knowing which releases it may have been part of. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 11/03/09 02:09, Jan Beulich wrote:> Hmm, I think http://xenbits.xensource.com/xen-unstable.hg can > reasonably be considered a canonical reference, and hence I would > assume that using the small number ids is uniquely identifying a c/s. >I have a repo here which is what I''m going to refer to if you highlight a particular changeset for some reason. If I have to go back to xenbits to map a local change number to a changeset id then that''s pretty awkward (particularly if I''m not online at the time).> Furthermore, using the full ids doesn''t allow easily judging how long > ago the referred to c/s was committed, including immediately knowing > which releases it may have been part of. >That''s pretty easy to determine once you look it up. I don''t know that I have a good idea about how change numbers relate to releases anyway. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel