> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, October 5, 2018 7:32 PM
>
> A few pieces of the handling here are (no longer?) vendor specific, and
> hence there's no point in replicating the code. Make sure not otherwise
> pre-filled fields of struct hvm_hw_cpu instances are zero
>>> On 05.10.18 at 14:18, wrote:
> On 05/10/18 12:31, Jan Beulich wrote:
>> A few pieces of the handling here are (no longer?) vendor specific, and
>> hence there's no point in replicating the code.
>
> EFER probably was vendor specific originally. The control registers
> really shouldn't have
On 10/5/18 7:31 AM, Jan Beulich wrote:
> A few pieces of the handling here are (no longer?) vendor specific, and
> hence there's no point in replicating the code. Make sure not otherwise
> pre-filled fields of struct hvm_hw_cpu instances are zero filled before
> calling the vendor "save" hook,
On 05/10/18 12:31, Jan Beulich wrote:
> A few pieces of the handling here are (no longer?) vendor specific, and
> hence there's no point in replicating the code.
EFER probably was vendor specific originally. The control registers
really shouldn't have been...
> Make sure not otherwise
>
On 10/5/18 2:31 PM, Jan Beulich wrote:
> A few pieces of the handling here are (no longer?) vendor specific, and
> hence there's no point in replicating the code. Make sure not otherwise
> pre-filled fields of struct hvm_hw_cpu instances are zero filled before
> calling the vendor "save" hook,
A few pieces of the handling here are (no longer?) vendor specific, and
hence there's no point in replicating the code. Make sure not otherwise
pre-filled fields of struct hvm_hw_cpu instances are zero filled before
calling the vendor "save" hook, eliminating the need for the hook
functions to
