>>> On 13.03.19 at 17:05, <paul.durr...@citrix.com> wrote: >> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of >> Jan Beulich >> Sent: 13 March 2019 15:55 >> >> >>> On 11.03.19 at 19:09, <paul.durr...@citrix.com> 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
