Re: [Xen-devel] [PATCH 09/17] [V3]PVH xen: create PVH vmcs, and initialization

[Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>]

On Mon, 15 Apr 2013 16:47:49 +0100
"Jan Beulich" <JBeulich@xxxxxxxx> wrote:

> > +
> > +    v->arch.hvm_vcpu.hcall_64bit = 1;
> 
> One more case of not being 32-bit ready, but also not having an
> easy way to spot the place later?

Ok, I'll add tag like : /* PVH: 32bitfixme */

> > +
> > +    /* 
> > +     * During domain shutdown:
> > pvh_vmx_vmexit_handler->emulate_privileged_op
> > +     * -> guest_io_read -> pv_pit_handler -> handle_speaker_io ->
> > _spin_lock
> > +     *  so we call pit_init to initialize the spin lock.
> > +     */
> > +    if ( v->vcpu_id == 0 )
> > +        pit_init(v, cpu_khz);
> 
> I'm sorry, but - what? This is either a generic (i.e. not shutdown
> specific) problem (and then the comment is misleading), or you
> have a problem with the shutdown path that should be fixed
> there, not with some hacky workaround.

Yeah, OK. I put a note to go thru the shutdown path. Need to figure
whats going on the linux side. I'll look into it.

> > @@ -4514,6 +4591,8 @@ static int hvm_memory_event_traps(long p,
> > uint32_t reason, 
> >  void hvm_memory_event_cr0(unsigned long value, unsigned long old) 
> >  {
> > +    if ( is_pvh_vcpu(current) )
> > +        return;
> 
> This is temporary only, isn't it? If so, it should be clearly marked
> as such.

I am not sure what these event calls are about, I guessed it was for
some external debugger? 

thanks
M


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