[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC v2] pvh: clearly specify used parameters in vcpu_guest_context
On 19/11/13 11:34, George Dunlap wrote: > On 11/18/2013 06:18 PM, Roger Pau Monne wrote: >> if ( has_hvm_container_vcpu(v) ) >> { >> - /* >> - * NB: TF_kernel_mode is set unconditionally for HVM guests, >> - * so we always use the gs_base_kernel here. If we change this >> - * function to imitate the PV functionality, we'll need to >> - * make it pay attention to the kernel bit. >> - */ >> - hvm_set_info_guest(v, compat ? 0 : c.nat->gs_base_kernel); > > I think we still need to call hvm_set_info_guest() here -- there is > other stuff being set up, and it was called (without the extra argument > for gs_base_kernel) before the PVH patch series went in. > > (See c/s 35b1e07.) I see, I will restore the hvm_set_info_guest call, good catch. > >> >> if ( is_hvm_vcpu(v) || v->is_initialised ) >> goto out; >> >> + if ( c.nat->ctrlreg[0] ) { >> + v->arch.hvm_vcpu.guest_cr[0] |= c.nat->ctrlreg[0]; >> + hvm_update_guest_cr(v, 0); >> + } >> + >> + if ( c.nat->ctrlreg[4] ) { >> + v->arch.hvm_vcpu.guest_cr[4] |= c.nat->ctrlreg[4]; >> + hvm_update_guest_cr(v, 4); >> + } > > I thought the idea was that he would set cr0, cr3, and cr4 for all HVM > guests, rather than special-casing PVH guests? Well, I was just trying to make the PVH AP bringup interface stable, without messing much with HVM (not that we shouldn't aim to do it for HVM guests also), but I think the main concern now is releasing 4.4 with a stable interface for PVH guests. Thanks, Roger. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |