Re: [Xen-devel] [V10 PATCH 10/23] PVH xen: domain create, context switch related code changes

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Tue, Aug 20, 2013 at 1:52 AM, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> On Fri, 16 Aug 2013 17:11:21 +0100
> "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>
>> >>> On 16.08.13 at 17:32, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
>> >>> wrote:
>> > On Wed, Jul 24, 2013 at 2:59 AM, Mukesh Rathor
> ......
>> >>
>> >>      set_bit(_VPF_in_reset, &v->pause_flags);
>> >>
>> >> + pvh_skip_pv_stuff:
>> >
>> > Any idea what this set_bit(_VPF_in_reset) stuff is?  It looks like
>> > it's set above, and cleared down near the bottom of the function if
>> > nothing gets screwed up.
>>
>> This is related to the preemptible vCPU reset (which
>> arch_set_info_guest() just re-uses), making sure that while there
>> is an incomplete state update for a vCPU 8because it may have got
>> preempted) the vCPU can't be unpaused.
>>
>> > It seems like if that set/clear pair is important, then PVH should
>> > do them both as well, shouldn't it?
>>
>> I thought I had checked this once - does it now bypass one of the
>> two?
>>
>> But then again, this is all about PV memory management, so perhaps
>> it was that way when I checked, and I decided it was fine.
>
> Ok, I'll just leave it as it is then. Setting it might confuse someone
> why it's being set for PVH. Clearing is harmless anyways :).

I think much more confusing is skipping the set.  Part of the reason I
was asking is that I was looking at re-organizing the function so that
all the stuff common to PVH and PV were at the top; Then instead of
the goto, you would just have two return's, one for HVM, one for PVH,
at the appropriate place; I backed off and asked when I saw this.

 -George

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