>>> On 17.05.18 at 13:49, <jgr...@suse.com> wrote:
> On 17/05/18 12:44, Jan Beulich wrote:
>>>>> On 17.05.18 at 11:48, <roger....@citrix.com> wrote:
>>> The function is supposed to return whether the MTRR and PAT state of
>>> two CPUs match. Currently this is not properly done because the test
>>> for the deftype and the enable bits required both the deftype and the
>>> enable bits to be different, while just one of those fields being
>>> different can already cause the MTRR states on the vCPU to not match.
>>> Fix this by changing the AND into an OR instead, so that either the
>>> deftype or the enabled bits being different will cause the function to
>>> return mismatching state.
>> This is by far not enough, but I didn't view the function as critical
>> enough to warrant sending out the patch I have right away.
>> Jan
>> x86/HVM: correct mtrr_pat_not_equal()
>> The two vCPU-s differring in MTRR-enabled state means MTRR settings are
>> not equal. Both vCPU-s having MTRRs disabled means only PAT needs to be
>> compared. Along those lines for fixed range MTRRs. Differring variable
>> range counts likewise mean settings are different overall.
>> Constify types and convert bool_t to bool.
>> Signed-off-by: Jan Beulich <jbeul...@suse.com>
> My Rab tag for Roger's patch is applicable here, too:
> Release-acked-by: Juergen Gross <jgr...@suse.com>

Thanks, but that depends on whether Andrew is willing to ack the
patch (with or without minor modifications).


Xen-devel mailing list

Reply via email to