Xen devel - Nov 2009 - [PATCH] tweak memory error correction field in the SMBIOS data

Microsoft''s Windows logo certified hardware requires single- or
multi-bit ECC; since the SVVP certification runs the same test
on the guest, Xen domains will currently fail it.

This patch fixes it.
---
 tools/firmware/hvmloader/smbios.c |   14 +++++++++-----
 1 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/tools/firmware/hvmloader/smbios.c
b/tools/firmware/hvmloader/smbios.c
--- a/tools/firmware/hvmloader/smbios.c
+++ b/tools/firmware/hvmloader/smbios.c
@@ -455,7 +455,7 @@
     
     p->location = 0x01; /* other */
     p->use = 0x03; /* system memory */
-    p->error_correction = 0x01; /* other */
+    p->error_correction = 0x06; /* Multi-bit ECC to make Microsoft happy */
     p->maximum_capacity = memsize * 1024;
     p->memory_error_information_handle = 0xfffe; /* none provided */
     p->number_of_memory_devices = nr_mem_devs;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

You mean all Windows version will requires ECC? 

--jyh

xen-devel-bounces@lists.xensource.com wrote:
> Microsoft''s Windows logo certified hardware requires single- or
> multi-bit ECC; since the SVVP certification runs the same test
> on the guest, Xen domains will currently fail it.
> 
> This patch fixes it.
> ---
> tools/firmware/hvmloader/smbios.c |   14 +++++++++-----
> 1 files changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/firmware/hvmloader/smbios.c
> b/tools/firmware/hvmloader/smbios.c
> --- a/tools/firmware/hvmloader/smbios.c
> +++ b/tools/firmware/hvmloader/smbios.c
> @@ -455,7 +455,7 @@
> 
>     p->location = 0x01; /* other */
>     p->use = 0x03; /* system memory */
> -    p->error_correction = 0x01; /* other */
> +    p->error_correction = 0x06; /* Multi-bit ECC to make
> Microsoft happy */
>     p->maximum_capacity = memsize * 1024;
>     p->memory_error_information_handle = 0xfffe; /* none provided */
>     p->number_of_memory_devices = nr_mem_devs;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 11/25/2009 04:06 AM, Jiang, Yunhong wrote:
> You mean all Windows version will requires ECC?
No, it''s just a requirement of the Windows *Hardware* Logo Program 
(probably for server hardware only, I don''t know).  But it affects the 
SVVP testing too.

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Paolo Bonzini <pbonzini@redhat.com> writes:
> Microsoft''s Windows logo certified hardware requires single- or
> multi-bit ECC; since the SVVP certification runs the same test
> on the guest, Xen domains will currently fail it.
>
> -    p->error_correction = 0x01; /* other */
> +    p->error_correction = 0x06; /* Multi-bit ECC to make Microsoft
happy */

That''s lying if the host doesn''t support ECC.

It would be better if you checked that on the host and then
set it appropiately in the guest too.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

So with your patch, even if host has no ECC support, you will still tell guest
that the memory has ECC?

Generally, I don''t think it is a good idea to present guest with
capability more than host can provide, unless you can provide that capability
through software emulation.
But I don;t think you can emulate ECC memory through software method.

--jyh

Paolo Bonzini wrote:
> On 11/25/2009 04:06 AM, Jiang, Yunhong wrote:
>> You mean all Windows version will requires ECC?
> 
> No, it''s just a requirement of the Windows *Hardware* Logo Program
> (probably for server hardware only, I don''t know).  But it affects
> the SVVP testing too. 
> 
> Paolo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 11/25/2009 04:00 PM, Jiang, Yunhong wrote:
> So with your patch, even if host has no ECC support, you will still
> tell guest that the memory has ECC?
Yes, but I don''t think it''s of great importance.  I''m
just pleasing a
test with the simplest possible 1-line fix.  Do you know of anything 
that actually cares (i.e. not just "shows it to the user") about that 
particular DMI field, and does something different if it reads "ECC"?

For that matter, hvmloader is already saying that the host is running at 
some number of megahertz, which does not make sense for virtualization 
because the host may be loaded and slow down the guest.

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Paolo Bonzini wrote:
> On 11/25/2009 04:00 PM, Jiang, Yunhong wrote:
>> So with your patch, even if host has no ECC support, you will still
>> tell guest that the memory has ECC?
> 
> Yes, but I don''t think it''s of great importance. 
I''m just pleasing a
> test with the simplest possible 1-line fix.  Do you know of anything
> that actually cares (i.e. not just "shows it to the user") about
that
> particular DMI field, and does something different if it reads
"ECC"?
One possible situation is, considering a host without ECC. When the host
detected 1 bit memory error, it may raises #MCE. If we try to inject this #MCE
to guest, guest will be confused, since DMI have report ECC support already.

Of course, I don''t know if any host system will raise #MCE for such
error, so it''s more about a feeling that present guest with more
capability than what host can provide is something tricky.
> 
> For that matter, hvmloader is already saying that the host is
> running at
> some number of megahertz, which does not make sense for virtualization
> because the host may be loaded and slow down the guest.
Yes, but timer virtualization (especially the TSC virtualization) has taken a
lot of effort on this  so that it make sense to guest, although sometime is
relaxed with different timer mode.

--jyh
> 
> Paolo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 11/26/2009 02:21 AM, Jiang, Yunhong wrote:
> When the host detected 1 bit memory error, it may raises #MCE
Does MCE distinguish single- or multi-bit errors?  Multi-bit ECC makes 
errors less likely, not impossible.

I know it''s not optimal, I just don''t think it''s
worth the effort.
Besides it could become wrong anyway after migration.

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Paolo Bonzini wrote:
> On 11/26/2009 02:21 AM, Jiang, Yunhong wrote:
>> When the host detected 1 bit memory error, it may raises #MCE
> 
> Does MCE distinguish single- or multi-bit errors?  Multi-bit ECC makes
> errors less likely, not impossible.
That depends on implementation, I think.
> 
> I know it''s not optimal, I just don''t think it''s
worth the effort.
> Besides it could become wrong anyway after migration.
Noticed Andi''s response for the mail that "It would be better if
you checked that on the host and then set it appropiately in the guest
too." and agree with this idea.

For migration, I think this only extend the host requirement from CPU to memory.
For example, we can''t migrate guest from host supporting SSE4
instruciton to host does not support it if we don''t limit
guest''s CPUID.

Also, another potential issue is, not sure if Windows guest will utilize the ECC
support or not, although it should not.

BTW, I''m not against the change, which is not critical.

--jyh

> 
> Paolo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel