[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 1/4] x86: stop handling MSR_IA32_BNDCFGS save/restore in implementation code



>>> On 13.03.19 at 17:05, <Paul.Durrant@xxxxxxxxxx> wrote:
>> From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of 
>> Jan Beulich
>> Sent: 13 March 2019 15:55
>> 
>> >>> On 11.03.19 at 19:09, <paul.durrant@xxxxxxxxxx> wrote:
>> > --- a/xen/include/asm-x86/msr.h
>> > +++ b/xen/include/asm-x86/msr.h
>> > @@ -328,7 +328,7 @@ int init_vcpu_msr_policy(struct vcpu *v);
>> >   * These functions are also used by the migration logic, so need to cope 
>> > with
>> >   * being used outside of v's context.
>> >   */
>> > -int guest_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val);
>> > +int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val);
>> 
>> I find this pretty undesirable, and I'd like to at least put out
>> for discussion a means how to avoid it: Any entity being
>> passed a const struct vcpu *cv can get hold of a non-const
>> one by doing
>> 
>>     struct vcpu *v = cv->domain->vcpu[cv->vcpu_id];
>> 
> 
> Looks kind of odd, but of course it will certainly work.
> 
>> Of course this shouldn't be used arbitrarily, but to hide an
>> implementation detail like that of vmx_vmcs_enter() I think
>> this could be justified. Thoughts?
>> 
> 
> I guess the question is at what level to do this? Probably in the hvm code 
> rather than in the vmx code.

I think it should be in VMX code, as that's where the
vmx_vmcs_enter() oddity lives.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.