* c/s 20384
@ 2009-11-02 8:17 Jan Beulich
2009-11-02 9:40 ` Keir Fraser
2009-11-02 21:08 ` Jeremy Fitzhardinge
0 siblings, 2 replies; 6+ messages in thread
From: Jan Beulich @ 2009-11-02 8:17 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: c/s 20384
2009-11-02 8:17 c/s 20384 Jan Beulich
@ 2009-11-02 9:40 ` Keir Fraser
2009-11-02 21:08 ` Jeremy Fitzhardinge
1 sibling, 0 replies; 6+ messages in thread
From: Keir Fraser @ 2009-11-02 9:40 UTC (permalink / raw)
To: Jan Beulich; +Cc: 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 state
Thanks, 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: c/s 20384
2009-11-02 8:17 c/s 20384 Jan Beulich
2009-11-02 9:40 ` Keir Fraser
@ 2009-11-02 21:08 ` Jeremy Fitzhardinge
2009-11-02 21:39 ` Keir Fraser
2009-11-03 10:09 ` Jan Beulich
1 sibling, 2 replies; 6+ messages in thread
From: Jeremy Fitzhardinge @ 2009-11-02 21:08 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Keir Fraser
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: c/s 20384
2009-11-02 21:08 ` Jeremy Fitzhardinge
@ 2009-11-02 21:39 ` Keir Fraser
2009-11-03 10:09 ` Jan Beulich
1 sibling, 0 replies; 6+ messages in thread
From: Keir Fraser @ 2009-11-02 21:39 UTC (permalink / raw)
To: Jeremy Fitzhardinge, Jan Beulich; +Cc: 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: c/s 20384
2009-11-02 21:08 ` Jeremy Fitzhardinge
2009-11-02 21:39 ` Keir Fraser
@ 2009-11-03 10:09 ` Jan Beulich
2009-11-03 19:06 ` Jeremy Fitzhardinge
1 sibling, 1 reply; 6+ messages in thread
From: Jan Beulich @ 2009-11-03 10:09 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: xen-devel, Keir Fraser
>>> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: c/s 20384
2009-11-03 10:09 ` Jan Beulich
@ 2009-11-03 19:06 ` Jeremy Fitzhardinge
0 siblings, 0 replies; 6+ messages in thread
From: Jeremy Fitzhardinge @ 2009-11-03 19:06 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Keir Fraser
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-11-03 19:06 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-11-02 8:17 c/s 20384 Jan Beulich
2009-11-02 9:40 ` Keir Fraser
2009-11-02 21:08 ` Jeremy Fitzhardinge
2009-11-02 21:39 ` Keir Fraser
2009-11-03 10:09 ` Jan Beulich
2009-11-03 19:06 ` Jeremy Fitzhardinge
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.