xen test results on Unisys ES7000

July 31, 2006

Configuration:

Unisys ES7000/one

x86_64

32 physical processors

32 GB RAM

SLES10 RC3 with xen-unstable changeset 10868

Ran xm-test (see results below) and successfully booted the following x86_64 SLES10 domUs:

a. A uni-processor DomU with 1GB of memory

b. A 4-processor DomU with 1GB of memory

c. A uni-processor DomU with 8GB of memory

d. A 4-processor DomU with 8GB of memory

e. A 32-processor DomU with 30GB memory

Issues: None

Xm-test execution summary:

PASS: 106

FAIL: 5

XPASS: 0

XFAIL: 3

Details:

XFAIL: 02_network_local_ping_pos

ping loopback failed for size 65507. ping eth0 failed for size
65507.

XFAIL: 05_network_dom0_ping_pos

Ping to dom0 failed for size 65507.

XFAIL: 11_network_domU_ping_pos

         Ping failed for size 1 48 64 512 1440 1500 1505 4096 4192 32767

65507.

FAIL: 12_network_domU_tcp_pos

         TCP hping2 failed for size 16384 24567 32767 65495.

FAIL: 13_network_domU_udp_pos

         UDP hping2 failed for size 32767 65495.

Thanks,

Sue Krysan

Linux Systems Group

Unisys Corporation

Thanks,

Sue Krysan

Linux Systems Group

Unisys Corporation

Thanks,

Sue Krysan

Linux Systems Group

Unisys Corporation

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Hello Keir,
This patch fixes a data corruption bug in hvm_pio_assist() of xen/arch/x86/hvm/io.c. When the OVERLAP flag is set and the guest is running in real-mode regs->es is used in the generation of the destination address passed to hvm_copy(). regs->es, however, has not been initialized and bad happens. Since __vmread() must be called to obtain regs->es to remedy the bug, this patch instead calls __vmread to obtain the GUEST_LINEAR_ADDRESS which removes the need to check if the guest is in real-mode and hence also the need to adjust addr. Since this block of code is executed so rarely, there is no measurable performance impact using this fix for real or protected mode guests.

Signed of by: Ross Maxfield <[email protected]>

@@ -374,12 +374,9 @@ static void hvm_pio_assist(struct cpu_us
             regs->edi += sign * p->count * p->size;
             if ( pio_opp->flags & OVERLAP )
             {
-                unsigned long addr = regs->edi;
-                if (hvm_realmode(current))
-                    addr += regs->es << 4;
-                if (sign > 0)
-                    addr -= p->size;
-                hvm_copy(&p->u.data, addr, p->size, HVM_COPY_OUT);
+                unsigned long addr;
+                __vmread(GUEST_LINEAR_ADDRESS, &addr);
+                hvm_copy(&p‑>u.data, addr, p‑>size, HVM_COPY_OUT);
             }
         }
         else /* p->dir == IOREQ_WRITE */

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Ross, should a __vmread be in an hvm specific function? Maybe I'm missing something but a __vmread VT instruction will GP on an AMD SVM platform.
Thanks for any clarification
Tom

This is not the right fix -- VMX-specific code in a generic HVM function, and it's too localised. I've made an alternative fix in c/s 10894 which will initialise those extra fields in the regs structure for all PIO requests. Please test when it reaches the public tree.

Thanks,
Keir