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

Re: [Xen-devel] [PATCH v4 4/7] X86: generic MSRs save/restore



Jan Beulich wrote:
>>>> On 02.12.13 at 13:12, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
>> Jan Beulich wrote:
>>>>>> On 02.12.13 at 09:52, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
>>>>>> wrote: 
>>>> --- a/xen/include/public/arch-x86/hvm/save.h
>>>> +++ b/xen/include/public/arch-x86/hvm/save.h
>>>> @@ -592,9 +592,22 @@ struct hvm_tsc_adjust {
>>>> 
>>>>  DECLARE_HVM_SAVE_TYPE(TSC_ADJUST, 19, struct hvm_tsc_adjust);
>>>> 
>>>> +#define MSR_SAVE_LOAD_MAX 16
>>> 
>>> Please don't - let's keep this flexible, with dynamic sizing similar
>>> to how the variable size XSAVE record is being dealt with.
>>> 
>> 
>> Sorry, I didn't figure out how to, considering the format
>> requirement like hvm_save_entry()/ hvm_load_entry() and macro.
>> 
>> XSAVE itself are not variable size -- it allocate at init per max
>> feature size requirement (but dynamically xsave/xrstor partial of
>> the buffer). 
> 
> And you could do the same - collect at boot time how many MSRs
> you might need to save at most (paralleling
> HVM_CPU_XSAVE_SIZE(xfeature_mask)), but save only as much as
> is needed (paralleling HVM_CPU_XSAVE_SIZE(v->arch.xcr0_accum)).
> 

Seems it can hardly find a generic way to collect what MSRs need save/restore, 
however, it's in fact quite easy for programmer who add specific MSR 
save/restore code -- based on this we implement patches which removed the 
non-extensible MSR_SAVE_LOAD_MAX. Patches will send out later.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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