[Xen-ia64-devel] Xen bug#1253 has been fixed on IA32
Hi Isaku, Latest IPF Cset has the xen bug#1253, which has been fixed by xen-unstable Cset#17682 (http://xenbits.xensource.com/xen-unstable.hg?rev/4b4b829e34a2). Could you please merge it in the next Cset? Thank you! Bug#1253: summary is The saved domain with qcow image cannot be restored. Link is http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1253. 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] fix zero extending for mmio ld1/2/4 emulation in KVM
Isaku Yamahata wrote:
Hi Jes.
Good catch.
I thought similar fix is necessary for xen/ia64 and checked the code.
It was fixed differently. I think the unnecessary divergence is undesirable.
What do you think the following fix according?
Hi Isaku,
I tried this fix for KVM, but it didn't work since the data returned is
a full word (64 bit) and it seems to get crippled in the process, so
we cannot use your patch :(
Cheers,
Jes
Only copy in the data actually requested by the instruction emulation
and zero pad the destination register first. This avoids the problem
where emulated mmio access got garbled data from ld2.acq instructions
in the vga console driver.
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
Cc: Jes Sorensen [EMAIL PROTECTED]
diff --git a/arch/ia64/kvm/mmio.c b/arch/ia64/kvm/mmio.c
index 351bf70..e6f194a 100644
--- a/arch/ia64/kvm/mmio.c
+++ b/arch/ia64/kvm/mmio.c
@@ -154,6 +154,9 @@ static void mmio_access(struct kvm_vcpu *vcpu, u64 src_pa,
u64 *dest,
p-u.ioreq.dir = dir;
if (dir == IOREQ_WRITE)
p-u.ioreq.data = *dest;
+ else
+ /* it's necessary to ensure zero extending */
+ p-u.ioreq.data = 0;
p-u.ioreq.state = STATE_IOREQ_READY;
vmm_transition(vcpu);
On Tue, May 20, 2008 at 01:13:50PM +0200, Jes Sorensen wrote:
Matthew Chapman wrote:
Jes,
Glad you tracked it down. Can I suggest rather than using memcpy, a
more efficient way might be something like...
#define ZERO_EXTEND(x,bits) ((x) (~0UL (64-(bits
*dest = ZERO_EXTEND(p-u.ioreq.data, 8*s);
Much nicer indeed!
Here's a pretty version - Tony will you apply this one instead.
Cheers,
Jes
Only copy in the data actually requested by the instruction emulation
and zero pad the destination register first. This avoids the problem
where emulated mmio access got garbled data from ld2.acq instructions
in the vga console driver.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
---
arch/ia64/kvm/mmio.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.git/arch/ia64/kvm/mmio.c
===
--- linux-2.6.git.orig/arch/ia64/kvm/mmio.c
+++ linux-2.6.git/arch/ia64/kvm/mmio.c
@@ -159,7 +159,8 @@
if (p-u.ioreq.state == STATE_IORESP_READY) {
if (dir == IOREQ_READ)
- *dest = p-u.ioreq.data;
+ /* it's necessary to ensure zero extending */
+ *dest = p-u.ioreq.data (~0UL (64-(s*8)));
} else
panic_vm(vcpu);
out:
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Xen/IPF Unstable CS#17677 Status Report
Hi jingke: Pls copy a newest RPM of XEN/IA64 and GFW you used to [EMAIL PROTECTED]:~/, I can't open website of QA's building system. Though Isaku work around it, I will root fix it. Good good study,day day up ! ^_^ -Wing(zhang xin) OTC,Intel Corporation -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zhang, Jingke Sent: 2008?5?20? 15:18 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] Xen/IPF Unstable CS#17677 Status Report Hi all, No new issue was found in this nightly test. Old issue (1): == Windows guest 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 #17677 Status Report === = Test Result Summary: # total case: 17 # passed case: 15 # failed case: 2 === = 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: 17677 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 === = Thanks, Zhang Jingke ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [patch] fix zero extending for mmio ld1/2/4 emulation in KVM
unnecessary divergence is
undesirable.
Good point, we should keep kvm/ia64 and xen/ia64 the same code base as
possible.
Anthony
Isaku Yamahata wrote:
Hi Jes.
Good catch.
I thought similar fix is necessary for xen/ia64 and checked the code.
It was fixed differently. I think the unnecessary divergence is
undesirable.
What do you think the following fix according?
Only copy in the data actually requested by the instruction emulation
and zero pad the destination register first. This avoids the problem
where emulated mmio access got garbled data from ld2.acq instructions
in the vga console driver.
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
Cc: Jes Sorensen [EMAIL PROTECTED]
diff --git a/arch/ia64/kvm/mmio.c b/arch/ia64/kvm/mmio.c
index 351bf70..e6f194a 100644
--- a/arch/ia64/kvm/mmio.c
+++ b/arch/ia64/kvm/mmio.c
@@ -154,6 +154,9 @@ static void mmio_access(struct kvm_vcpu *vcpu,
u64 src_pa, u64 *dest, p-u.ioreq.dir = dir;
if (dir == IOREQ_WRITE)
p-u.ioreq.data = *dest;
+ else
+ /* it's necessary to ensure zero extending */
+ p-u.ioreq.data = 0;
p-u.ioreq.state = STATE_IOREQ_READY;
vmm_transition(vcpu);
On Tue, May 20, 2008 at 01:13:50PM +0200, Jes Sorensen wrote:
Matthew Chapman wrote:
Jes,
Glad you tracked it down. Can I suggest rather than using memcpy, a
more efficient way might be something like...
#define ZERO_EXTEND(x,bits) ((x) (~0UL (64-(bits
*dest = ZERO_EXTEND(p-u.ioreq.data, 8*s);
Much nicer indeed!
Here's a pretty version - Tony will you apply this one instead.
Cheers,
Jes
Only copy in the data actually requested by the instruction emulation
and zero pad the destination register first. This avoids the problem
where emulated mmio access got garbled data from ld2.acq
instructions in the vga console driver.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
---
arch/ia64/kvm/mmio.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.git/arch/ia64/kvm/mmio.c
===
--- linux-2.6.git.orig/arch/ia64/kvm/mmio.c
+++ linux-2.6.git/arch/ia64/kvm/mmio.c
@@ -159,7 +159,8 @@
if (p-u.ioreq.state == STATE_IORESP_READY) {
if (dir == IOREQ_READ)
-*dest = p-u.ioreq.data;
+/* it's necessary to ensure zero extending */
+*dest = p-u.ioreq.data (~0UL (64-(s*8)));
} else
panic_vm(vcpu);
out:
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [patch] fix zero extending for mmio ld1/2/4 emulation in KVM
Xu, Anthony wrote: unnecessary divergence is undesirable. Good point, we should keep kvm/ia64 and xen/ia64 the same code base as possible. It would be nice, but the KVM codebase has already been modified a lot, just the reformatting in order to be acceptable to the Linux kernel. I don't think it's realistic to keep them identical. Cheers, Jes ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Xen/IPF Unstable CS#17699 Status Report --- no new issue
Hi all, All the cases passed in this Cset. Detail Xen/IA64 Unstable Cset #17699 Status Report Test Result Summary: # total case: 17 # passed case: 17 # failed case: 0 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: 17699 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 SMPVTI_Windows SMPVTI windows(vcpu=2) SMPWin_SMPVTI_SMPxenU SMPVTI Linux/Windows XenU --- Failed case id Description Thanks, Zhang Jingke ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Xen Itanium features available in Xen HVM?
On Thu, May 15, 2008 at 09:36:59AM -0700, Paul Leisy wrote: Hi Tristan, Hi, did I forget to reply ? Seems so. Thank you for the comments. This really helps since I'm pretty new to Xen. Here are more questions and assumptions I'm making: I agree that it's important to know which PKR is used by the HP-UX IVTs if we go with the plan of sharing a PKR. What about this approach--- Since HP-UX must use a key (PKR) for IVT and I assume an ITR and DTR, Xen could observe when HP-UX sets the IVA and the ITR and the DTR before it enters virtual mode. If the ITR is covering the IVA, then it's a good bet that the key in the ITR is for the IVT. Does this sound reasonable? Yes it does. Another assumption is that once HP-UX sets up the IVT areas with ITR and DTR (along with key) to cover them, they won't change. Reasonable too. However if two different guests use two different PK, switching from one to the other will be harder... I thought there was a huge disadvantage to using M-N map of PKRs. For example, if HP-UX set up all 16 PKRs and Xen has to steal one for it's use, Xen could end up with a case where many accesses by the guest will get false Key miss faults and Xen will have to handle each one? Right but this is also true for itc/itr which are virtualized. Xen gets a key miss fault, determines that the key for the access was stolen by Xen, then Xen has to put back the original guest key and pick another guest key to steal. Then return to guest so that it can make the access. Doesn't that create performance overhead and mess with TLBs (since they contain keys). I don't think this messes with TLBs. What do you have in mind ? M-N map will add overhead (but virtualization adds overhead in any case). But if N M (ie you have more virtual PKR than hard one), it will save fault injection to the guest. On the other hand, perhaps HP-UX never uses all 16 PKRs and it's no big deal to steal one for Xen. I know pretty much zero about HP-UX. All guesses at this point. Sure. We will know more about HPUX once it will start to run in Xen! Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
