On Thu, 2014-08-14 at 01:44 +0200, Laszlo Ersek wrote:
> On 08/14/14 01:17, Laszlo Ersek wrote:
>
> > - With KVM, the lack of loading MTRR state from KVM, combined with the
> > (partial) storing of MTRR state to KVM, has two consequences:
> > - migration invalidates (loses) MTRR state,
>
> I'
On 08/14/14 01:17, Laszlo Ersek wrote:
> - With KVM, the lack of loading MTRR state from KVM, combined with the
> (partial) storing of MTRR state to KVM, has two consequences:
> - migration invalidates (loses) MTRR state,
I'll concede that migration *already* loses MTRR state (on KVM), even
b
On 08/14/14 00:06, Alex Williamson wrote:
> On Wed, 2014-08-13 at 22:33 +0200, Laszlo Ersek wrote:
>> a number of comments -- feel free to address or ignore each as you see fit:
>>
>> On 08/13/14 21:09, Alex Williamson wrote:
>>> mappings which are now stale after reset. The result is that OVMF
>
On Wed, 2014-08-13 at 22:33 +0200, Laszlo Ersek wrote:
> a number of comments -- feel free to address or ignore each as you see fit:
>
> On 08/13/14 21:09, Alex Williamson wrote:
> > The SDM specifies (June 2014 Vol3 11.11.5):
> >
> > On a hardware reset, the P6 and more recent processors cle
a number of comments -- feel free to address or ignore each as you see fit:
On 08/13/14 21:09, Alex Williamson wrote:
> The SDM specifies (June 2014 Vol3 11.11.5):
>
> On a hardware reset, the P6 and more recent processors clear the
> valid flags in variable-range MTRRs and clear the E fl
The SDM specifies (June 2014 Vol3 11.11.5):
On a hardware reset, the P6 and more recent processors clear the
valid flags in variable-range MTRRs and clear the E flag in the
IA32_MTRR_DEF_TYPE MSR to disable all MTRRs. All other bits in the
MTRRs are undefined.
We currently do none
