Re: [Xen-ia64-devel] [PATCH][RFC][IA64] Accelerate IDE PIO on HVM/IA64
Quoting Kouya SHIMURA [EMAIL PROTECTED]: This patch significantly accelerates IDE PIO on HVM/IA64: * reduces the installation time of Windows 2003 Server from 10 hours(!) to 50min. * accelerates Windows CrashDumping speed from 40KB/sec (It takes over three hours for 512MB guest) to 850KB/sec. All reason for above slowness is the overhead of IDE PIO. Of course Windows should use DMA mode but we can't handle it. (FYI. Once installed, Windows usually uses DMA mode) On the other hand, x86 arch is rescued from this issue since it has a CISC instruction and multiple PIO requests can be processed in qemu-dm at one transaction. So this patch gives no benefit for x86. There are some dirty hacks in this patch: * To begin with, is it permissive to delegate the part of process of qemu-dm to hypervisor? * Currently it uses remnant of buffered_iopage (for VGA). Maybe I should prepare another page for IDE PIO. * May I use #ifdef __ia64__ ? * and so on. Hi, clever idea! Two remarks: * you can't assume page size = 16KB. Xen can be compiled with other page sizes (and should work with other page sizes). As an easy approach, you can disable this optimization iff page size != 16KB (or use smaller buffers). * To be written data are not flushed directly. I suppose they are flushed while status is checked. Is it safe ? Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH] Re: [Xen-devel] Re: [PATCH 2/2] PV framebuffer
Hi, Markus Thank you for your suggestion. My config is attached as follows(see below) Anyway, I cannot find vfb and vkbd definition in RHEL5 package. Please give me appropriate config. kernel = /boot/efi/efi/xen/vmlinuz-2.6.16.29-xen-sakaia ramdisk = /boot/efi/efi/xen/initrd-2.6.16.29-xenU.img memory = 1024 name = rhel4-sakaia0 disk = [ 'file:/xen/image/fc6t3.img,hda1,w' ] vif = [ '' ] root = /dev/hda1 ro extra = nomca ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe xencons=xvc vnc = 1 vncpasswd=' ' Thanks Atsushi SAKAI Atsushi SAKAI [EMAIL PROTECTED] writes: Hi, Markus Finally Booting DomU is succesful with xenfb driver. But xen-vncfb is waiting in prhread_cond_wait. main xenfb_attach_dom xenfb_wait_for_backend_creation xenfb_wait_for_state xs_read_watch pthread_cond_wait And By doing xensore-ls, the keyword vfb is not appleared. From this consideration, I guess xen-vncfb has a problem. This waits for xend to create the xenstore directory. Is there any suggestion? Do you have vfb and vkbd configured in your /etc/xen/DOMNAME file? Could you post your config file here? c.f. During the survey, I found large difference your xenfn patch and FC6 xenfb code. Yes, FC-6 has an old version of the patch. Really old. Thanks Atsushi SAKAI ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [RFC] [PATCH 2/4][IA64][HVM] Windows 2003 server crashdump suppprt
[2/4] Xen common side. xm_osinit_xen_common_side.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [RFC] [PATCH 3/4][IA64][HVM] Windows 2003 server crashdump suppprt
[3/4] Xen arch/ia64 side. xm_osinit_xen_arch-ia64_side.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [RFC] [PATCH 4/4][IA64][HVM] Windows 2003 server crashdump suppprt
[4/4] Linux side. xm_osinit_linux_side.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [RFC] [PATCH 1/4][IA64][HVM] Windows 2003 server crashdump suppprt
[1/4] Tools side. xm_osinit_tools_side.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] fix warnings while rebooting
Hi Akio, I'm sorry, but I'm confused by your message. Are you saying there are two problems here? One problem in xen/ia64 and one problem in the e1000 driver? You sent a patch, I guess that is for xen-ia64-unstable, right? If that is ready to be applied, could you include a description of the problem and what the patch does? Regarding the e1000 bug, could you comment in the RH bug? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208599 Thanks, Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [RFC][PATCH] changed foreing ia64-domain page mapping semantic (was Re: [Xen-ia64-devel] xen-ia64-unstable.hg breakage)
On Thu, 2006-11-30 at 22:01 +0900, Isaku Yamahata wrote: With this patch, I can successfully create domU. The issue I haven't solved is how to initialize shared_info page. Currently the shared info for domU can be accessed only via fixed virtual address. With this patch, it is done in xen as work around when XEN_DOMCTL_arch_setup. Should XENMEM_add_to_physmap with XENMAPSPACE_shared_info be used? Any other Ideas? Hi Isaku, XENMEM_add_to_physmap/XENMAPSPACE_shared_info seems like it would better align with how it's done on x86. Why wouldn't we do it that way? Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel][PATCH]fix vti inital broken after merge
On Mon, 2006-12-04 at 09:54 +0800, Xu, Anthony wrote: Alex Williamson write on 2006年12月2日 1:44: I think it would be cleaner just to make the ia64 specific xc_set_hvm_param() ignore HVM_PARAM_PAE_ENABLED (or have the xen side of the hypercall ignore it). Alex, For HVM_INFO and HVM_PARAM_PAE_ENABLED, I think they are IA32-spicific, and should not be put in common path. Hi Anthony, Does that mean SMP HVM guests work with this patch? I was wondering if HVM_INFO is how x86 is setting up the number of vCPUs. I removed the code in tools/libxc/ia64/xc_ia64_hvm_build.c that appeared to handle this, so thought we might need to migrate to something like HVM_INFO to do that now. PAE is x86 specific of course, but it's part of the generic HVM params. It won't hurt anything to set the parameter on ia64, it just won't do anything. Maybe after 3.0.4 it would be worthwhile to create an interface for setting arch-specific parameters. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [PATCH 1/2] import linux/include/asm-ia64/uaccess.h for /dev/mem paravirtualization (was Re: [Xen-ia64-devel] [PATCH] paravirtualize /dev/mem to use X)
On Mon, 2006-11-20 at 16:01 +0900, Isaku Yamahata wrote: import linux/include/asm-ia64/uaccess.h for /dev/mem paravirtualization I applied these now with the latest merge from xen-unstable. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] fix warnings while rebooting
Hi, Aron
Hi Akio,
I'm sorry, but I'm confused by your message. Are you saying there are
two problems here? One problem in xen/ia64 and one problem in the
e1000 driver?
Yes, there are two problem here.
1. double free message is happened
2. CallTrace is happened
problem 1 is a issue of free_irq_vector.
My patch fix this problem.
problem 2 is a issue of some network drivers.
suspend handlers of e1000, tg3 and so on are not called free_irq().
free_irq() is called by only close handlers of them.
So if close handlers are not called before suspend handlers,
iosapic_unregister_intr() call WARN_ON(1).
iosapic_unregister_intr (unsigned int gsi)
{
unsigned long flags;
int irq, vector, index;
[snip...]
memset(iosapic_intr_info[vector], 0,
sizeof(struct iosapic_intr_info));
iosapic_intr_info[vector].low32 |= IOSAPIC_MASK;
INIT_LIST_HEAD(iosapic_intr_info[vector].rtes);
if (idesc-action) {
printk(KERN_ERR
interrupt handlers still exist on
IRQ %u\n, irq);
WARN_ON(1); HERE!!
}
/* Free the interrupt vector */
free_irq_vector(vector);
}
[snip...]
}
I think there are three solutions.
A. do # /etc/xen/scripts/network-bridge stop before reboot
I think this is the best solution. But if we do that, where is better?
/etc/init.d/network or /etc/init.d/xend?
And How do we do in the case of routing mode?
B. apply the e1000 patch(I think other driver also apply likely patch.)
I think the better solution.
But I'm not familiar with e1000 driver.
So I'd like to review it by RH Engineer and community people.
The patch is the below.
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=edd106fc8ac1826dbe231b70ce0762db24133e5c;hp=e78181feb0b94fb6afeaef3b28d4f5df1b847c98
C. ifdef the WARN_ON(1) in iosapic_unregister_intr.
This is the easiest solution.
And because Xen don't do I/O Hotplug, this may be the best.
You sent a patch, I guess that is for xen-ia64-unstable, right? If
that is ready to be applied, could you include a description of the
problem and what the patch does?
Yes, my patch is for xen-ia64-unstable.
My patch fix problem 1 (double free messages).
I already have patches for RHEL5 beta.
I'll send you soon if my patch is applied in xen-ia64-unstable.
- Bug escription
Please see the following two functions.
assign_irq_vector() is para-virulized, free_irq_vector() is not
para-virtualized.
So ia64_vector_mask is not used in dom0 kernel.
Though free_irq_vector() try to clear ia64_vector_mask in dom0 kernel,
ia64_vector_mask is always zero, so the double free message is happened.
int
assign_irq_vector (int irq)
{
int pos, vector;
#ifdef CONFIG_XEN
if (is_running_on_xen()) {
extern int xen_assign_irq_vector(int);
return xen_assign_irq_vector(irq);
}
#endif
again:
pos = find_first_zero_bit(ia64_vector_mask, IA64_NUM_DEVICE_VECTORS);
vector = IA64_FIRST_DEVICE_VECTOR + pos;
if (vector IA64_LAST_DEVICE_VECTOR)
return -ENOSPC;
if (test_and_set_bit(pos, ia64_vector_mask))
goto again;
return vector;
}
void
free_irq_vector (int vector)
{
int pos;
if (vector IA64_FIRST_DEVICE_VECTOR || vector
IA64_LAST_DEVICE_VECTOR)
return;
pos = vector - IA64_FIRST_DEVICE_VECTOR;
if (!test_and_clear_bit(pos, ia64_vector_mask))
printk(KERN_WARNING %s: double free!\n, __FUNCTION__);
HERE
}
- What the patch does?
I do that free_irq_vector() is para-virtualized.
Regarding the e1000 bug, could you comment in the RH bug?
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208599
Yes.
Best Regards,
Akio Takebe
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel][PATCH]fix vti inital broken after merge
Hi Alex: With this patch, SMP HVM only can boot as UP. Due to add_vcpus_hob() has been removed from build_hob(). Since parameter 'vcpus' not available in setup_guest(). We prefer to use index 'PAE' to save vcpus to xen in python code and get it back in setup_guest(). Codes probably like below: In arch-ia64.h: +/* HVM_PARAM_PAE_ENABLED not used in IA64, so we used this param to save vcpu + number */ +#define HVM_PARAM_VCPUS HVM_PARAM_PAE_ENABLE In xc.c: +#if defined(__ia64__) +xc_set_hvm_param(self-xc_handle, dom, HVM_PARAM_VCPUS, vcpus); +#endif In xc_ia64_hvm_build.c + xc_get_hvm_param(xc_handle, dom, HVM_PARAM_VCPUS, vcpus) Good good study,day day up ! ^_^ -Wing(zhang xin) OTC,Intel Corporation -Original Message- From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年12月5日 5:19 To: Xu, Anthony Cc: Zhang, Xing Z; xen-ia64-devel Subject: RE: [Xen-ia64-devel][PATCH]fix vti inital broken after merge On Mon, 2006-12-04 at 09:54 +0800, Xu, Anthony wrote: Alex Williamson write on 2006年12月2日 1:44: I think it would be cleaner just to make the ia64 specific xc_set_hvm_param() ignore HVM_PARAM_PAE_ENABLED (or have the xen side of the hypercall ignore it). Alex, For HVM_INFO and HVM_PARAM_PAE_ENABLED, I think they are IA32-spicific, and should not be put in common path. Hi Anthony, Does that mean SMP HVM guests work with this patch? I was wondering if HVM_INFO is how x86 is setting up the number of vCPUs. I removed the code in tools/libxc/ia64/xc_ia64_hvm_build.c that appeared to handle this, so thought we might need to migrate to something like HVM_INFO to do that now. PAE is x86 specific of course, but it's part of the generic HVM params. It won't hurt anything to set the parameter on ia64, it just won't do anything. Maybe after 3.0.4 it would be worthwhile to create an interface for setting arch-specific parameters. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel][PATCH]fix vti inital broken after merge
Alex Williamson write on 2006年12月5日 5:19: On Mon, 2006-12-04 at 09:54 +0800, Xu, Anthony wrote: Alex Williamson write on 2006年12月2日 1:44: Does that mean SMP HVM guests work with this patch? Yes, it works, HVM_INFO is only removed for IPF side. I was wondering if HVM_INFO is how x86 is setting up the number of vCPUs. I removed the code in tools/libxc/ia64/xc_ia64_hvm_build.c that appeared to handle this, so thought we might need to migrate to something like HVM_INFO to do that now. In IA32 side, it uses HVM_INFO to pass parameter to hvmloader. But in IPF side, it uses HOB interface to pass parameter to guest Firmware in a predifined address, such as vcpu number. SMP vti has nothing to do with HVM_INFO. We are working at SMP VTI, the root cause is that vcpu parameter is removed for Merge, we'll add it at somewhere, we'll send out patch ASAP. PAE is x86 specific of course, but it's part of the generic HVM params. It won't hurt anything to set the parameter on ia64, it just won't do anything. Maybe after 3.0.4 it would be worthwhile to create an interface for setting arch-specific parameters. Thanks, Agree, --Anthony Alex ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH][RFC][IA64] Accelerate IDE PIO on HVM/IA64
Hi, Tristan Thanks for your comments. * In any case, I have to allocate another page for IDE PIO buffer. Actually this patch works well on any size of buffer. The size is just trade-off with the performance. FYI, 2048 bytes seems to be enough for CDROM. * The location where data is being written has already been enclosed with the memory barrier. Since shared memory is used for the communication between hypervisor and qemu-dm. So I think it's safe. Actually it isn't guest's MP safe but I think guest OS must take responsibility for it. (Who reads the I/O port simultaneously?) Thanks, Kouya [EMAIL PROTECTED] writes: Quoting Kouya SHIMURA [EMAIL PROTECTED]: This patch significantly accelerates IDE PIO on HVM/IA64: * reduces the installation time of Windows 2003 Server from 10 hours(!) to 50min. * accelerates Windows CrashDumping speed from 40KB/sec (It takes over three hours for 512MB guest) to 850KB/sec. All reason for above slowness is the overhead of IDE PIO. Of course Windows should use DMA mode but we can't handle it. (FYI. Once installed, Windows usually uses DMA mode) On the other hand, x86 arch is rescued from this issue since it has a CISC instruction and multiple PIO requests can be processed in qemu-dm at one transaction. So this patch gives no benefit for x86. There are some dirty hacks in this patch: * To begin with, is it permissive to delegate the part of process of qemu-dm to hypervisor? * Currently it uses remnant of buffered_iopage (for VGA). Maybe I should prepare another page for IDE PIO. * May I use #ifdef __ia64__ ? * and so on. Hi, clever idea! Two remarks: * you can't assume page size = 16KB. Xen can be compiled with other page sizes (and should work with other page sizes). As an easy approach, you can disable this optimization iff page size != 16KB (or use smaller buffers). * To be written data are not flushed directly. I suppose they are flushed while status is checked. Is it safe ? Tristan. ___ Xen-devel mailing list [EMAIL PROTECTED] http://lists.xensource.com/xen-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[xen-ia64-devel][Patch] new fix vti broken after merger
Hi Alex: I admit there are some codes looking ugly with #if defined, I have no good way to deal with these IA32 specific codes without this method. About how to pass parameter vcpus, this may be a work around way before we found better solution. Good good study,day day up ! ^_^ -Wing(zhang xin) OTC,Intel Corporation fix_vti_broken_12671.patch Description: fix_vti_broken_12671.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH]Change to new interrupt deliver mechanism
Hi, I (Doi.Tsunehisa) said: Hmm.. Current implement needs the GSI for platform-pci to follow status of virtual IOSAPIC in hypervisor side. But, it's not certain value from virtual IOSAPIC at calling set_callback_irq hypercall. I'll be thinking more... I've investigated it, but I couldn't find the method to get GSI of platform-pci for PV-on-HVM driver. There is convert functions like isa_irq_to_vector() in linux kernel source. [arch/ia64/kernel/apci.c] int acpi_gsi_to_irq(u32 gsi, unsigned int *irq) [arch/ia64/kernel/iosapic.c] inline int gsi_to_vector (unsigned int gsi) But, these functions are not EXPORT_SYMBOLE, thus we can't use them for kernel module. So, I think that.. * Hypervisor becomes to be able to use both GSI and Vector for callback irq. - For example, if it is normal value, HV accepts it as GSI. If it is value which is set MSB, HV accepts it as Vector. * If hypervisor gets Vector as callback irq, hypervisor finds the GSI for the pseudo device from virtual interrupt controller setting. What do you think about this method ? Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH][RFC][IA64] Accelerate IDE PIO on HVM/IA64
Hi Kouya, With your patch, win2k3 installation can be done within 40 minutes! I have integrated #Cset12525 with the accelerating patch. It took 20 minutes to load file (you will see it in a blue screen). And then the guest quickly installed the win2k3 from the CD-ROM, totally within 40 minutes! What a wonderful patch! :) Thanks, Zhangjingke -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kouya SHIMURA Sent: Monday, December 04, 2006 10:28 AM To: [EMAIL PROTECTED]; xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] [PATCH][RFC][IA64] Accelerate IDE PIO on HVM/IA64 This patch significantly accelerates IDE PIO on HVM/IA64: * reduces the installation time of Windows 2003 Server from 10 hours(!) to 50min. * accelerates Windows CrashDumping speed from 40KB/sec (It takes over three hours for 512MB guest) to 850KB/sec. All reason for above slowness is the overhead of IDE PIO. Of course Windows should use DMA mode but we can't handle it. (FYI. Once installed, Windows usually uses DMA mode) On the other hand, x86 arch is rescued from this issue since it has a CISC instruction and multiple PIO requests can be processed in qemu-dm at one transaction. So this patch gives no benefit for x86. There are some dirty hacks in this patch: * To begin with, is it permissive to delegate the part of process of qemu-dm to hypervisor? * Currently it uses remnant of buffered_iopage (for VGA). Maybe I should prepare another page for IDE PIO. * May I use #ifdef __ia64__ ? * and so on. Please show me the right way. Thanks, Kouya Signed-off-by: Kouya Shimura [EMAIL PROTECTED] ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel][PATCH]Change to new interrupt deliver mechanism
[EMAIL PROTECTED] write on 2006年12月5日 12:05: Hi, I've investigated it, but I couldn't find the method to get GSI of platform-pci for PV-on-HVM driver. There is convert functions like isa_irq_to_vector() in linux kernel source. [arch/ia64/kernel/apci.c] int acpi_gsi_to_irq(u32 gsi, unsigned int *irq) [arch/ia64/kernel/iosapic.c] inline int gsi_to_vector (unsigned int gsi) But, these functions are not EXPORT_SYMBOLE, thus we can't use them for kernel module. So, I think that.. * Hypervisor becomes to be able to use both GSI and Vector for callback irq. - For example, if it is normal value, HV accepts it as GSI. If it is value which is set MSB, HV accepts it as Vector. * If hypervisor gets Vector as callback irq, hypervisor finds the GSI for the pseudo device from virtual interrupt controller setting. What do you think about this method ? Hi Doi, There is only one IOAPIC in IPF, So irq is equal to GSI, The sequence of platform_pci interrupt deliver is like below. 1. platform-pic.c cal set_callback_irq to tell HV the irq. 2. if there are callcack_irq, HV converts irq to vector by asking for VIOSAPIC, and HV directly pend this vector to one VCPU, Can this sequence work? Thanks --Anthony Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
