On 07/15/15 21:30, Xiao Guangrong wrote:
>
> Hi,
>
> I have posted the pachset to make OVMF happy and have CCed you guys,
> could you please check it if it works for you?
Sorry, I can't check it; I don't have an environment that exposes the
issue in the first place. Perhaps Alex can check it,
Hi,
I have posted the pachset to make OVMF happy and have CCed you guys,
could you please check it if it works for you?
On 07/15/2015 05:15 AM, Paolo Bonzini wrote:
The long delay that Alex reported (for the case when all guest memory
was set to UC up-front) is due to the fact that the SEC
On 07/15/15 00:37, Jordan Justen wrote:
> On 2015-07-14 14:29:11, Laszlo Ersek wrote:
>> On 07/14/15 23:15, Paolo Bonzini wrote:
The long delay that Alex reported (for the case when all guest memory
was set to UC up-front) is due to the fact that the SEC phase of OVMF
decompresses
On 07/15/15 00:37, Jordan Justen wrote:
On 2015-07-14 14:29:11, Laszlo Ersek wrote:
On 07/14/15 23:15, Paolo Bonzini wrote:
The long delay that Alex reported (for the case when all guest memory
was set to UC up-front) is due to the fact that the SEC phase of OVMF
decompresses an approximately
Hi,
I have posted the pachset to make OVMF happy and have CCed you guys,
could you please check it if it works for you?
On 07/15/2015 05:15 AM, Paolo Bonzini wrote:
The long delay that Alex reported (for the case when all guest memory
was set to UC up-front) is due to the fact that the SEC
On 07/15/15 21:30, Xiao Guangrong wrote:
Hi,
I have posted the pachset to make OVMF happy and have CCed you guys,
could you please check it if it works for you?
Sorry, I can't check it; I don't have an environment that exposes the
issue in the first place. Perhaps Alex can check it, or
Cc: edk2-devel list; Xiao Guangrong; k...@vger.kernel.org; g...@kernel.org;
mtosa...@redhat.com; linux-kernel@vger.kernel.org
Subject: Re: [edk2] MTRR setup in OVMF [was: PATCH v3 01/10 KVM: MMU: fix
decoding cache type from MTRR]
> The long delay that Alex reported (for the case when all gu
On 2015-07-14 14:29:11, Laszlo Ersek wrote:
> On 07/14/15 23:15, Paolo Bonzini wrote:
> >> The long delay that Alex reported (for the case when all guest memory
> >> was set to UC up-front) is due to the fact that the SEC phase of OVMF
> >> decompresses an approximately 1712 KB sized,
On 07/14/15 23:15, Paolo Bonzini wrote:
>> The long delay that Alex reported (for the case when all guest memory
>> was set to UC up-front) is due to the fact that the SEC phase of OVMF
>> decompresses an approximately 1712 KB sized, LZMA-compressed blob, to
>> approx. 896 KB worth of PEI drivers
> The long delay that Alex reported (for the case when all guest memory
> was set to UC up-front) is due to the fact that the SEC phase of OVMF
> decompresses an approximately 1712 KB sized, LZMA-compressed blob, to
> approx. 896 KB worth of PEI drivers and 8192 KB worth of DXE and UEFI
> drivers
Cross-posting to edk2-devel.
Original sub-thread starts here:
http://thread.gmane.org/gmane.linux.kernel/1952205/focus=1994315
On 07/13/15 17:15, Xiao Guangrong wrote:
>
>
> On 07/13/2015 11:13 PM, Paolo Bonzini wrote:
>> On 13/07/2015 16:45, Xiao Guangrong wrote:
+/* MTRR is
On 07/14/15 23:15, Paolo Bonzini wrote:
The long delay that Alex reported (for the case when all guest memory
was set to UC up-front) is due to the fact that the SEC phase of OVMF
decompresses an approximately 1712 KB sized, LZMA-compressed blob, to
approx. 896 KB worth of PEI drivers and 8192
Cross-posting to edk2-devel.
Original sub-thread starts here:
http://thread.gmane.org/gmane.linux.kernel/1952205/focus=1994315
On 07/13/15 17:15, Xiao Guangrong wrote:
On 07/13/2015 11:13 PM, Paolo Bonzini wrote:
On 13/07/2015 16:45, Xiao Guangrong wrote:
+/* MTRR is completely
The long delay that Alex reported (for the case when all guest memory
was set to UC up-front) is due to the fact that the SEC phase of OVMF
decompresses an approximately 1712 KB sized, LZMA-compressed blob, to
approx. 896 KB worth of PEI drivers and 8192 KB worth of DXE and UEFI
drivers --
On 2015-07-14 14:29:11, Laszlo Ersek wrote:
On 07/14/15 23:15, Paolo Bonzini wrote:
The long delay that Alex reported (for the case when all guest memory
was set to UC up-front) is due to the fact that the SEC phase of OVMF
decompresses an approximately 1712 KB sized, LZMA-compressed blob,
Cc: edk2-devel list; Xiao Guangrong; k...@vger.kernel.org; g...@kernel.org;
mtosa...@redhat.com; linux-kernel@vger.kernel.org
Subject: Re: [edk2] MTRR setup in OVMF [was: PATCH v3 01/10 KVM: MMU: fix
decoding cache type from MTRR]
The long delay that Alex reported (for the case when all guest
On 07/13/2015 11:13 PM, Paolo Bonzini wrote:
On 13/07/2015 16:45, Xiao Guangrong wrote:
+/* MTRR is completely disabled, use UC for all of physical
memory. */
+if (!(mtrr_state->enabled & 0x2))
+return MTRR_TYPE_UNCACHABLE;
actually disappears in commit fa61213746a7 (KVM:
On 13/07/2015 16:45, Xiao Guangrong wrote:
>> +/* MTRR is completely disabled, use UC for all of physical
>> memory. */
>> +if (!(mtrr_state->enabled & 0x2))
>> +return MTRR_TYPE_UNCACHABLE;
>>
>> actually disappears in commit fa61213746a7 (KVM: MTRR: simplify
>>
On 07/13/2015 03:32 PM, Paolo Bonzini wrote:
I'm seeing a significant regression in boot performance on Intel
hardware with assigned devices that bisects back to this patch. There's
a long delay with Seabios between the version splash and execution of
option ROMs, and a _very_ long delay with
On 12/07/2015 20:59, Xiao Guangrong wrote:
>
>
> On 07/13/2015 01:33 AM, Alex Williamson wrote:
>> On Wed, 2015-05-13 at 14:42 +0800, Xiao Guangrong wrote:
>>> There are some bugs in current get_mtrr_type();
>>> 1: bit 1 of mtrr_state->enabled is corresponding bit 11 of
>>>
On 07/13/2015 03:32 PM, Paolo Bonzini wrote:
I'm seeing a significant regression in boot performance on Intel
hardware with assigned devices that bisects back to this patch. There's
a long delay with Seabios between the version splash and execution of
option ROMs, and a _very_ long delay with
On 13/07/2015 16:45, Xiao Guangrong wrote:
+/* MTRR is completely disabled, use UC for all of physical
memory. */
+if (!(mtrr_state-enabled 0x2))
+return MTRR_TYPE_UNCACHABLE;
actually disappears in commit fa61213746a7 (KVM: MTRR: simplify
kvm_mtrr_get_guest_memory_type,
On 07/13/2015 11:13 PM, Paolo Bonzini wrote:
On 13/07/2015 16:45, Xiao Guangrong wrote:
+/* MTRR is completely disabled, use UC for all of physical
memory. */
+if (!(mtrr_state-enabled 0x2))
+return MTRR_TYPE_UNCACHABLE;
actually disappears in commit fa61213746a7 (KVM: MTRR:
On 12/07/2015 20:59, Xiao Guangrong wrote:
On 07/13/2015 01:33 AM, Alex Williamson wrote:
On Wed, 2015-05-13 at 14:42 +0800, Xiao Guangrong wrote:
There are some bugs in current get_mtrr_type();
1: bit 1 of mtrr_state-enabled is corresponding bit 11 of
IA32_MTRR_DEF_TYPE MSR which
Alex Williamson writes:
> On Wed, 2015-05-13 at 14:42 +0800, Xiao Guangrong wrote:
>> There are some bugs in current get_mtrr_type();
>> 1: bit 1 of mtrr_state->enabled is corresponding bit 11 of
>>IA32_MTRR_DEF_TYPE MSR which completely control MTRR's enablement
>>that means other bits
On 07/13/2015 01:33 AM, Alex Williamson wrote:
On Wed, 2015-05-13 at 14:42 +0800, Xiao Guangrong wrote:
There are some bugs in current get_mtrr_type();
1: bit 1 of mtrr_state->enabled is corresponding bit 11 of
IA32_MTRR_DEF_TYPE MSR which completely control MTRR's enablement
that
On Wed, 2015-05-13 at 14:42 +0800, Xiao Guangrong wrote:
> There are some bugs in current get_mtrr_type();
> 1: bit 1 of mtrr_state->enabled is corresponding bit 11 of
>IA32_MTRR_DEF_TYPE MSR which completely control MTRR's enablement
>that means other bits are ignored if it is cleared
>
On 07/13/2015 01:33 AM, Alex Williamson wrote:
On Wed, 2015-05-13 at 14:42 +0800, Xiao Guangrong wrote:
There are some bugs in current get_mtrr_type();
1: bit 1 of mtrr_state-enabled is corresponding bit 11 of
IA32_MTRR_DEF_TYPE MSR which completely control MTRR's enablement
that
Alex Williamson alex.william...@redhat.com writes:
On Wed, 2015-05-13 at 14:42 +0800, Xiao Guangrong wrote:
There are some bugs in current get_mtrr_type();
1: bit 1 of mtrr_state-enabled is corresponding bit 11 of
IA32_MTRR_DEF_TYPE MSR which completely control MTRR's enablement
that
On Wed, 2015-05-13 at 14:42 +0800, Xiao Guangrong wrote:
There are some bugs in current get_mtrr_type();
1: bit 1 of mtrr_state-enabled is corresponding bit 11 of
IA32_MTRR_DEF_TYPE MSR which completely control MTRR's enablement
that means other bits are ignored if it is cleared
2:
On Wed, May 13, 2015 at 02:42:19PM +0800, Xiao Guangrong wrote:
>There are some bugs in current get_mtrr_type();
>1: bit 1 of mtrr_state->enabled is corresponding bit 11 of
> IA32_MTRR_DEF_TYPE MSR which completely control MTRR's enablement
> that means other bits are ignored if it is cleared
There are some bugs in current get_mtrr_type();
1: bit 1 of mtrr_state->enabled is corresponding bit 11 of
IA32_MTRR_DEF_TYPE MSR which completely control MTRR's enablement
that means other bits are ignored if it is cleared
2: the fixed MTRR ranges are controlled by bit 0 of
On Wed, May 13, 2015 at 02:42:19PM +0800, Xiao Guangrong wrote:
There are some bugs in current get_mtrr_type();
1: bit 1 of mtrr_state-enabled is corresponding bit 11 of
IA32_MTRR_DEF_TYPE MSR which completely control MTRR's enablement
that means other bits are ignored if it is cleared
2:
There are some bugs in current get_mtrr_type();
1: bit 1 of mtrr_state-enabled is corresponding bit 11 of
IA32_MTRR_DEF_TYPE MSR which completely control MTRR's enablement
that means other bits are ignored if it is cleared
2: the fixed MTRR ranges are controlled by bit 0 of
34 matches
Mail list logo
