Re: [Xen-ia64-devel] [Patch] iosapic virtualization again
Le Mercredi 22 Février 2006 17:34, Tian, Kevin a écrit : Several coding style comments: 1. + if (vector == IA64_TIMER_VECTOR || vector == IA64_IPI_VECTOR) + return 0; For this point, I second Eddie to have irq descriptor add a flag to indicate whether belonging to xen or guest, instead of hardcode here. You can grep IRQ_GUEST in xen/arch/x86. Though guest SMP and driver domain is not ready yet, interface should be designed clean and well to allow better cooperation between guest and xen. 2. Not sure why you pull in iosapic.h into your patch. Seems no modification there which just need copy from linux source at compile time. If you really want to include this file, you can avoid adding xen_iosapic_write in c file and instead move its content to iosapic_write defined in iosapic.h I suppose you speak about the iosapic.h for linux. I have removed the iosapic_version() declaration, since it has been modified and is never used outside iosapic. 3. Why ifdef XEN but nothing changed: +#ifdef XEN + vector = assign_irq_vector(AUTO_ASSIGN); +#else + /* If vector is running out, we try to find a sharable vector */ +#endif + vector = assign_irq_vector(AUTO_ASSIGN); Correct. 4. It's ugly to see: +#define VCPU_XEN ((struct vcpu *)1) Also no place to init vcpu with this value, however later it's checked when reflecting interrupt Maybe I should remove this ? Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [Patch] iosapic virtualization again
From: Tristan Gingold [mailto:[EMAIL PROTECTED] Sent: 2006年2月23日 16:15 2. Not sure why you pull in iosapic.h into your patch. Seems no modification there which just need copy from linux source at compile time. If you really want to include this file, you can avoid adding xen_iosapic_write in c file and instead move its content to iosapic_write defined in iosapic.h I suppose you speak about the iosapic.h for linux. Yes. I have removed the iosapic_version() declaration, since it has been modified and is never used outside iosapic. Then you should stick to CONFIG_XEN for future track of updates. Also since this file is changed, I think you can remove xen_iosapic_write and instead extend iosapic_write in iosapic.h to have that check upon running_on_xen. This can reduce modifications in iosapic.c to replace iosapic_write with xen_iosapic_write. Same goes for read. 4. It's ugly to see: +#define VCPU_XEN ((struct vcpu *)1) Also no place to init vcpu with this value, however later it's checked when reflecting interrupt Maybe I should remove this ? Yes. There's better way to indicate ownership of the specific vector. Xen is started from Linux and then same concept is inherited that so-called irq is the basic unit from system point of view. For small ia64 system, irq equals to vector but not true for large system. So it's natural to have guest indicator at irq level, like in irq_desc instead of at lower rte level, since multiple RTEs can be routed to same vector/irq. You can see from linux history, interrupt sub-system evolves from initial 80% (maybe inaccurate;-) arch dependent to nowadays 80% arch independent. To this point, we should follow common model defined in xen world. See xen/arch/x86/irq.c, which shows you the picture what we suggest to follow. ;-) Thanks, Kevin ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] SMP_HOST: map pal code on smp host
On up host, only when rr7 is changed, efi_map_pal_code() is called to remap pal code on new rr7. But on smp host, efi_map_pal_code is also called to map pal code for other processors, which may not satisfy rr7 change condition, thus pal code may not be mapped in some processors, while ia64_pal_halt_light called in startup_cpu_idle_loop will cause machine crash. Tristan, I know you booted domain0 on smp boot several months ago, but I can't understand why you didn't encounter this issue. Signed-off-by: Anthony Xu [EMAIL PROTECTED] Thanks, -Anthony map_pal_code_on_smp_host.patch Description: map_pal_code_on_smp_host.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Weekly benchmark results [2/3rd week]
Hi, Dan and Alex I think this issue is only on ia64. I seem that [EMAIL PROTECTED]/char/mem.c is used on ia64, but [EMAIL PROTECTED]/xen/char/mem.c is used on x86. So I think pfn or kva aren't set correctly. We tried to boot domU with revesing cset xen-ia64-ustable.8790 and it was good work. I'm still debugging it. :- Best Regards, Akio Takebe Confirmed cset xen-unstable 8783 fails while 8782 succeeds. Perhaps there's something different about mmap on RH vs Suse and Debian? Perhaps only on ia64? ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] VTI: Fix two bugs
1. Vmx_check_pending_irq should not be called in vmx_vcpu_set_eoi, because vmx_vcpu_increment_iip is called after vmx_vcpu_set_eoi. That is, the first instruction of guest interrupt handler will be skipped. 2. Remove code segment which was used to send events to VTIdomain, when dom0 was VTIdomain. This is not needed any more, and will cause VTIdomain on SMP-HOST complain Unexpected interrupt ... . Signed-off-by: Anthony Xu [EMAIL PROTECTED] Thanks, -Anthony vtidom0224.patch Description: vtidom0224.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Provides right frequency ratio andbasefor VTi domain
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Xu, Anthony Sent: 2006年2月24日 13:15 To: Alex Williamson; Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [PATCH] Provides right frequency ratio andbasefor VTi domain From: AlexWilliamson Sent: 2006年2月24日 10:17 General question for the group, is updating the xen-ia64 tree once a week sufficient for people? As I get more comfortable with it I'll try to push individual patches, but for the moment it's convenient to group them together and do one bulk commit. Thanks, Alex Updating the xen-ia64 tree once a week is sufficient, as for pushing patch, it should be case by case. Most patches can be pushed once a week; special patches should be treated specially. It's the author's responsibility to mark this is a special patch, and should be pushed out ASAP. What I mean is synchronize xen-ia64 and xen tree once a week, patches should be checked into xen-ia64 tree ASAP to avoid patch conflict, some special patches should be checked into xen tree ASAP Thanks, -Anthony ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
