[Xen-ia64-devel] Xen/IPF Unstable CS#17671 Status Report --- one issue fixed, one issue still existed

2008-05-18 Thread Zhang, Jingke
Hi all,
With Cset#17671, qcow creating issue was fixed! It can use qcow
file to create a VTI with disk = [ 'tap:qcow:/***,hda,w' ] config
file. 

One old issue still existed:
==
Windows guest still can not be booted up.
--- VTI_Windows2008 can not be booted. When we ran bootmgfw.efi,
it would also report failure in the qemu screen. 
--- VTI_Windows2003, both SP1 and SP2 guest will crash at
starting windows...
 

Detail Xen/IA64 Unstable Cset #17671 Status Report


Test Result Summary:
# total case:   18
# passed case: 15
# failed case:   3

Testing Environment:
platform: Tiger4
processor: Itanium 2 Processor
logic Processors number: 8 (2 processors with Dual Core)
pal version: 9.08
service os: RHEL4u3 IA64 SMP with 2 VCPUs
vti guest os: RHEL4u2  RHEL4u3
xenU guest os: RHEL4u2
xen ia64 unstable tree: 17671
xen schedule: credit
gfw: open guest firmware Cset#122

Detailed Test Results:

Passed case id  Description
SaveRestoreSaveRestore
VTI_PV  Linux VTI PV
Two_UP_VTI_Co2  UP_VTI (mem=256)
One_UP_VTI 1 UP_VTI (mem=256)
One_UP_XenU 1 UP_xenU(mem=256)
SMPVTI_LTP  VTI (vcpus=4, mem=512) run LTP
SMPVTI_and_SMPXenU  1 VTI + 1 xenU (mem=256 vcpus=2)
Two_SMPXenU_Coexist 2 xenU (mem=256, vcpus=2)
One_SMPVTI_4096M1 VTI (vcpus=2, mem=4096M)
SMPVTI_Network  1 VTI (mem=256,vcpu=2) and'ping'
SMPXenU_Network 1 XenU (vcpus=2) and 'ping'
One_SMP_XenU1 SMP xenU (vcpus=2)
One_SMP_VTI 1 SMP VTI (vcpus=2)
SMPVTI_Kernel_Build VTI (vcpus=4) and do KernelBuild
UPVTI_Kernel_Build  1 UP VTI and do kernel build



(all the cases containing windows VTI)
Failed case id  Description
SMPVTI_Windows  SMPVTI windows(vcpu=2)
SMPWin_SMPVTI_SMPxenU   SMPVTI Linux/Windows  XenU
VTI_Windows_PV  Windows VTI PV



Thanks,
Zhang Jingke


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


[Xen-ia64-devel] Re: [PATCH 00/15] ia64/pv_ops take 5

2008-05-18 Thread Isaku Yamahata
On Fri, May 16, 2008 at 05:06:21PM -0700, Luck, Tony wrote:
 I started looking at this patch set.

Thank you for your time.


 Parts 1-9 applied ok, but part10 (entry.S) failed to apply because of
 recent changes to this file to fix the problems with warnings when
 trying to get locks with interrupts blocked.
 
 I thought this would be a good point to test the bisectability
 of this patch set and started a build with just parts 1-9 applied.
 The build was perfectly clean, but the kernel hung during boot
 (possibly when first trying to run user processes by the look
 of the last few messages on the console.

I'll rebase/debug the patches and resend them.
My native case test is done under Xen HVM(full virtualized)
domain.


 The code with parts 1-9 applied still looks readable, but I
 think we may need some documentation later to help with maintainability.

I'll write it. It will be under linux-2.6/Documentation/ia64/.

  
 Perhaps even a tool that can check to make sure people don't add
 direct uses of instructions to .S files that need to be
 paravirtualized.

Yes, I also really want such a tool and I've thought of it.
I want to prevent people from accidently breaking paravirtualization
and only a way to do so would be by enforcing.
I think it can be easily achived by CPP macro trick.
At worst a simple .s (or .o) parser.

-- 
yamahata

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