>>> On 27.11.17 at 12:37, <[email protected]> wrote: > On 27/11/17 09:53, Jan Beulich wrote: >>>>> On 25.11.17 at 19:15, <[email protected]> wrote: >>> @@ -1311,10 +1311,49 @@ long arch_do_domctl( >>> vmsrs->msr_count = nr_msrs; >>> else >>> { >>> + static const uint32_t msrs[] = { >>> + MSR_INTEL_MISC_FEATURES_ENABLES, >> ... is this really a non-optional MSR? In particular, >> calculate_hvm_max_policy() ties it to INTEL_PLATFORM_INFO, >> which in turn is being tied to running on an Intel CPU. >> calculate_pv_max_policy() is even more picky. I think you want >> to introduce a function in msr.c complementing guest_rdmsr() / >> guest_wrmsr(), similar to HVM's .init_msr() hook. > > Whether an MSR should be migrated depends on whether the guest is able > to use it.
Indeed, and the MSR here is unusable by a guest as long as Xen runs on an Intel CPU, regardless of the virtual CPU vendor. > I'm specifically looking to remove the concept of optional MSRs to avoid > duplicating the MSR policy logic, and risking it being different. In > reality, what this means is that the migration code will be expected to > cope with the union of all possible MSRs, and only actually get a subset > to put into the stream. If that's the goal, I think it would help if you said so in the patch description. Jan _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
