[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |