|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 18/18] PVH xen: introduce vmx_pvh.c
>>> On 10.07.13 at 02:33, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> On Tue, 09 Jul 2013 08:31:24 +0100
> "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>
>> >>> On 09.07.13 at 02:01, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
>> >>> wrote:
>> > On Mon, 8 Jul 2013 16:09:55 -0700
>> > Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
>> >
>> >> On Mon, 08 Jul 2013 09:31:17 +0100
>> >> "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> .......
>> Fine with me, except (as said before) ...
>>
>> > --- a/xen/arch/x86/hvm/hvm.c
>> > +++ b/xen/arch/x86/hvm/hvm.c
>> > @@ -4642,6 +4642,14 @@ enum hvm_intblk
>> > nhvm_interrupt_blocked(struct vcpu *v) return
>> > hvm_funcs.nhvm_intr_blocked(v); }
>> >
>> > +bool_t hvm_kernel_mode(const struct vcpu *v)
>> > +{
>> > + struct segment_register seg;
>> > +
>> > + hvm_get_segment_register((struct vcpu *)v, x86_seg_ss, &seg);
>>
>> .. for this cast.
>
> Like I said in prev email, changing the cast is very hard, as it trickles
> down all the way to vcpu_runnable thru SVM and VMX and would need changing
> vcpu_runnable itself and all callers of it. So, I can either leave the cast,
> or better just remove "const" from the sole caller using it, please LMK:
At first I wanted to say this is a no-go, but in fact you can't have
hvm_get_segment_register() have a const vcpu pointer: On VMX,
if v != current, this may involve a vcpu_pause, and that one
_can't_ have a const pointer passed.
Thus casting away the constness above is actively wrong without
an assertion proving v == current (the validity of which would
depend on whether this is used in the context switch path).
Hence sadly I have to agree to you removing the const from
vcpu_show_registers()' only parameter, no matter how wrong
that looks.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |