[Xen-ia64-devel] [Patch] Follow new interrupt deliver mechanism for PV-on-HVM/IPF
Hi all,
I modified to follow new interrupt deliver mechanism for PV-on-HVM/IPF.
New interrupt deliver mechanism changed GSI of pseudo hardware for
PV-on-HVM. So, old get_callback_irq function can't get GSI of it.
In this case, I modified that PV-driver notices Requester-ID(RID) to
hypervisor as callback irq with RID marker(MSB).
RID contains a bus number, a device number and a function number.
(cf. PCI-Express spec)
* pvdrv.patch
- Modify to change the spec of callback IRQ in PV-driver side.
* hyper.patch
- Modify to change the spec of callback IRQ in hypervisor side.
I tested with our simple test of PV-on-HVM on RHEL4 U4.
Thanks,
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 656f00fcd551061c268b73bfe9d7b92a2f53bdcc
# Parent 6e68e8a8cc99717b372c482efa0e153e868ae6f4
Follow new interrupt deliver mechanism for PV-on-HVM/IPF (driver side)
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r 6e68e8a8cc99 -r 656f00fcd551
unmodified_drivers/linux-2.6/platform-pci/platform-pci.c
--- a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c Mon Dec 18
10:56:34 2006 -0700
+++ b/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c Tue Dec 19
18:22:05 2006 +0900
@@ -182,12 +182,16 @@ static int get_callback_irq(struct pci_d
static int get_callback_irq(struct pci_dev *pdev)
{
#ifdef __ia64__
- int irq;
+ int irq, rid;
for (irq = 0; irq 16; irq++) {
if (isa_irq_to_vector(irq) == pdev-irq)
return irq;
}
- return 0;
+ /* use Requester-ID as callback_irq */
+ /* RID: '#bus(8)#dev(5)#func(3)' (cf. PCI-Express spec) */
+ rid = ((pdev-bus-number 0xff) 8) | pdev-devfn;
+ printk(KERN_INFO DRV_NAME :use Requester-ID(%04x) as callback irq\n,
rid);
+ return rid | (1 31); /* with RID marker(MSB) */
#else /* !__ia64__ */
return pdev-irq;
#endif
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 8217a7ba6d9adbadeda939756346bcedb080a0f8
# Parent 656f00fcd551061c268b73bfe9d7b92a2f53bdcc
Follow new interrupt deliver mechanism for PV-on-HVM/IPF (hypervisor side)
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r 656f00fcd551 -r 8217a7ba6d9a xen/arch/ia64/vmx/vmx_process.c
--- a/xen/arch/ia64/vmx/vmx_process.c Tue Dec 19 18:22:05 2006 +0900
+++ b/xen/arch/ia64/vmx/vmx_process.c Tue Dec 19 18:23:33 2006 +0900
@@ -212,8 +212,18 @@ void leave_hypervisor_tail(struct pt_reg
if (callback_irq != 0 local_events_need_delivery()) {
/* change level for para-device callback irq */
/* use level irq to send discrete event */
-viosapic_set_irq(d, callback_irq, 1);
-viosapic_set_irq(d, callback_irq, 0);
+if (callback_irq (1 31) /* RID marker(MSB) */) {
+/* case of using Requester-ID as callback irq */
+/* RID: '#bus(8)#dev(5)#func(3)' */
+int rid = (callback_irq ~(1 31));
+viosapic_set_pci_irq(d, ((rid 3) 0x1f), 0, 1);
+viosapic_set_pci_irq(d, ((rid 3) 0x1f), 0, 0);
+}
+else {
+/* case of using GSI as callback irq */
+viosapic_set_irq(d, callback_irq, 1);
+viosapic_set_irq(d, callback_irq, 0);
+}
}
}
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch] sn2 - only get nasid from nodepda if sn_nodepda is available
Hi,
This one solves the problem where sn2_send_IPI() would cause a page
fault because sn_nodepda is not yet available at the time we try and
deference it to get the nasid.
This patch falls back to making the SAL call until sn_nodepda is
available.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
Cheers,
Jes
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1166528481 -3600
# Node ID 665284c4a8e733114ee2992f47bf5d11d0888458
# Parent 0634616feb430b010cb1e7eb3bf8b31c43a9e5c9
fall back to getting nasid from sal cal if sn_nodepda is not yet available
diff -r 0634616feb43 -r 665284c4a8e7 xen/arch/ia64/linux-xen/sn/kernel/sn2_smp.c
--- a/xen/arch/ia64/linux-xen/sn/kernel/sn2_smp.c Mon Dec 18 09:55:52
2006 +0100
+++ b/xen/arch/ia64/linux-xen/sn/kernel/sn2_smp.c Tue Dec 19 12:41:21
2006 +0100
@@ -438,6 +438,11 @@ void sn2_send_IPI(int cpuid, int vector,
int nasid;
physid = cpu_physical_id(cpuid);
+#ifdef XEN
+ if (!sn_nodepda) {
+ ia64_sn_get_sapic_info(physid, nasid, NULL, NULL);
+ } else
+#endif
nasid = cpuid_to_nasid(cpuid);
/* the following is used only when starting cpus at boot time */
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] semget05.c: initialize MAXIDS and getmaxid.
semget05.c uses an uninitialized variable, getmaxid, and sets MAXIDS
to garbage value. This patch initialize it properly.
Without this patch, semget05 fails on ia64 as follows
$ ./semget05
semget051 BROK : Unexpected signal 11 received.
$ ./semget05 -e
semget051 BROK : Didn't get ENOSPC in test setup - errno = 17 : File
exists
thanks.
--- ./semget05.c.orig 2006-12-19 20:57:44.0 +0900
+++ ./semget05.c2006-12-19 21:12:54.0 +0900
@@ -72,7 +72,7 @@ int num_sems = 0; /* count the semaphor
int main(int ac, char **av)
{
- int lc,getmaxid;/* loop counter */
+ int lc; /* loop counter */
char *msg; /* message returned from parse_opts */
FILE *fp;
@@ -83,21 +83,28 @@ int main(int ac, char **av)
/* Set the MAXIDS for the specific machine by reading the system limit
for SEMMNI - The maximum number of sempahore sets
*/
- if((fp = fopen(/proc/sys/kernel/sem, r)) != NULL)
- {
- for(lc= 0; lc 4; lc++)
- {
- if(lc == 3)
- {
- if(getmaxid MAXIDS)
- MAXIDS=getmaxid;
- }
- }
+ if((fp = fopen(/proc/sys/kernel/sem, r)) != NULL) {
+ int getmaxid;
+ for(lc = 0; lc 4; lc++) {
+ if (fscanf(fp, %d, getmaxid) 0) {
+ tst_brkm(TBROK, cleanup,
+can't parse /proc/sys/kernel/sem %s,
+strerror(errno));
+ }
+ if(lc == 3) {
+ if(getmaxid MAXIDS)
+ MAXIDS=getmaxid;
+ }
+ }
- }
+ }
fclose(fp);
sem_id_arr = (int*)malloc(sizeof(int)*MAXIDS);
+ if (sem_id_arr == NULL) {
+ tst_brkm(TBROK, cleanup, can't allocate memory for sem id %s,
+strerror(errno));
+ }
setup();/* global setup */
--
yamahata
___
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 [ww50]
On Fri, Dec 15, 2006 at 05:10:16PM +0900, KUWAMURA Shin'ya wrote: I updated ltp's version to 20061121. Test cases marked with LTP's bug disappeared, but two new cases (semget05 and semop04) failed. Details: semget051 BROK : Unexpected signal 11 received. This seems semget05 bug. semop04 1 BROK : couldn't create semaphore in setup semop04 2 BROK : Remaining cases broken semop04 passes on my environment as follows Is this reproducable? $ ./semop04 semop04 1 PASS : expected failure - errno = 11 : Resource temporarily unavailable semop04 2 PASS : expected failure - errno = 11 : Resource temporarily unavailable -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch] don't dereference xen_start_info when running on raw hardware
Hi,
On ia64 we don't create a xen_start_info when running on raw hardware
so the pointer is NULL. Doesn't work very well with the original
implementation of is_initial_xendomain() :-)
Cheers,
Jes
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1166546932 -3600
# Node ID 9411fcd9abdeb59fa5a2b3c3f54e1d0432d616c4
# Parent aabb5fba6a2e12beec379f24fe9ddd656d09c98f
Check we are running under Xen before trying to dereference
xen_start_info! xen_start_info is NULL on ia64 if running raw
hardware.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r aabb5fba6a2e -r 9411fcd9abde
linux-2.6-xen-sparse/include/asm-ia64/hypervisor.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/hypervisor.hTue Dec 19
12:36:12 2006 +0100
+++ b/linux-2.6-xen-sparse/include/asm-ia64/hypervisor.hTue Dec 19
17:48:52 2006 +0100
@@ -215,7 +215,15 @@ asmlinkage int xprintk(const char *fmt,
#endif /* CONFIG_XEN || CONFIG_VMX_GUEST */
#ifdef CONFIG_XEN_PRIVILEGED_GUEST
-#define is_initial_xendomain() (xen_start_info-flags SIF_INITDOMAIN)
+#define is_initial_xendomain() \
+({ \
+ int retval; \
+ if (is_running_on_xen())\
+ retval = xen_start_info-flags SIF_INITDOMAIN;\
+ else\
+ retval = 0; \
+ retval; \
+})
#else
#define is_initial_xendomain() 0
#endif
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch] don't allocate bitmap from low pool
Hi,
There is no reason to allocate this bitmap from the low pages pool
since all pages are identity mapped on ia64.
With this and the previous patch I posted, I can boot the dom0 kernel
directly on sn hardware.
Cheers,
Jes
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1166547207 -3600
# Node ID cc58c14826cd9e25be9653dbbe9ebb1b9f27579d
# Parent 9411fcd9abdeb59fa5a2b3c3f54e1d0432d616c4
No need to allocate contiguous_bitmap out of the low pages pool as all
pages are directly accessible on an ia64.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 9411fcd9abde -r cc58c14826cd
linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c
--- a/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c Tue Dec 19 17:48:52
2006 +0100
+++ b/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c Tue Dec 19 17:53:27
2006 +0100
@@ -60,7 +60,7 @@ contiguous_bitmap_init(unsigned long end
contiguous_bitmap_init(unsigned long end_pfn)
{
unsigned long size = (end_pfn + 2 * BITS_PER_LONG) 3;
- contiguous_bitmap = alloc_bootmem_low_pages(size);
+ contiguous_bitmap = alloc_bootmem_pages(size);
BUG_ON(!contiguous_bitmap);
memset(contiguous_bitmap, 0, size);
}
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] Follow new interrupt deliver mechanism for PV-on-HVM/IPF
On Tue, 2006-12-19 at 20:01 +0900, DOI Tsunehisa wrote:
--- a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.cMon Dec
18 10:56:34 2006 -0700
+++ b/unmodified_drivers/linux-2.6/platform-pci/platform-pci.cTue Dec
19 18:22:05 2006 +0900
@@ -182,12 +182,16 @@ static int get_callback_irq(struct pci_d
static int get_callback_irq(struct pci_dev *pdev)
{
#ifdef __ia64__
- int irq;
+ int irq, rid;
for (irq = 0; irq 16; irq++) {
if (isa_irq_to_vector(irq) == pdev-irq)
return irq;
}
- return 0;
+ /* use Requester-ID as callback_irq */
+ /* RID: '#bus(8)#dev(5)#func(3)' (cf. PCI-Express spec) */
+ rid = ((pdev-bus-number 0xff) 8) | pdev-devfn;
+ printk(KERN_INFO DRV_NAME :use Requester-ID(%04x) as callback irq\n,
rid);
+ return rid | (1 31); /* with RID marker(MSB) */
Ok, except (1 31) needs to be defined in a common header somewhere
so it's not just a random magic bit. 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
[Xen-ia64-devel] Re: [patch] don't dereference xen_start_info when running on raw hardware
On Tue, 2006-12-19 at 17:57 +0100, Jes Sorensen wrote: Hi, On ia64 we don't create a xen_start_info when running on raw hardware so the pointer is NULL. Doesn't work very well with the original implementation of is_initial_xendomain() :-) I applied a little bit smaller version of this. 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
[Xen-ia64-devel] Re: [patch] don't allocate bitmap from low pool
On Tue, 2006-12-19 at 17:59 +0100, Jes Sorensen wrote: Hi, There is no reason to allocate this bitmap from the low pages pool since all pages are identity mapped on ia64. With this and the previous patch I posted, I can boot the dom0 kernel directly on sn hardware. Applied. 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
[Xen-ia64-devel] Re: [patch] sn2 - only get nasid from nodepda if sn_nodepda is available
On Tue, 2006-12-19 at 12:44 +0100, Jes Sorensen wrote: Hi, This one solves the problem where sn2_send_IPI() would cause a page fault because sn_nodepda is not yet available at the time we try and deference it to get the nasid. This patch falls back to making the SAL call until sn_nodepda is available. Applied to the sn2+machvec tree. 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] Follow new interrupt deliver mechanism for PV-on-HVM/IPF
Hi Alex, Thank you for your comment. You (alex.williamson) said: +return rid | (1 31); /* with RID marker(MSB) */ Ok, except (1 31) needs to be defined in a common header somewhere so it's not just a random magic bit. Thanks, I agree it. I think that the definition should be in xen/include/public/hvm/params.h or xen/include/public/arch-ia64.h. What do you think about this ? - 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] Follow new interrupt deliver mechanism for PV-on-HVM/IPF
On Wed, 2006-12-20 at 08:29 +0900, [EMAIL PROTECTED] wrote: Hi Alex, Thank you for your comment. You (alex.williamson) said: + return rid | (1 31); /* with RID marker(MSB) */ Ok, except (1 31) needs to be defined in a common header somewhere so it's not just a random magic bit. Thanks, I agree it. I think that the definition should be in xen/include/public/hvm/params.h or xen/include/public/arch-ia64.h. What do you think about this ? It's ia64 specific, so arch-ia64.h seems more appropriate. Just an FYI, I think we're close enough to when Keir wants to make a final 3.0.4 release that I don't plan to request another pull of the xen-ia64 tree unless it's absolutely necessary. If you think this is necessary for 3.0.4, please provide justification. 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
[Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#13091
Xen/IA64 Healthiness Report Several issues: 1. If we enable MT and make xen0 to be UP, all the cases can pass. 2. If we disable MT and make xen0 to be SMP, VTI booting speed is very slow and SMPVTI_LTP performed slowly. Testing Environment: Platform: Tiger4 Processor: Itanium 2 Processor Logic Processors number: 8 (2 processors with Due Core) Service OS: RHEL4u3 IA64 SMP with 2 VCPUs VTI Guest OS: RHEL4u2 RHEL4u3 XenU Guest OS: RHEL4u2 Xen IA64 Unstable tree: 13091:c3b455c4676c Xen Schedule: credit VTI Guest Firmware Flash.fd.2006.12.01 MD5: 09a224270416036a8b4e6f8496e97854 Summary Test Report: - Total cases: 16 Passed:16 Failed: 0 Case Name Status Case Description Four_SMPVTI_Coexistpass 4 VTI (mem=256, vcpus=2) Two_UP_VTI_Co pass 2 UP_VTI (mem=256) One_UP_VTIpass1 UP_VTI (mem=256) One_UP_XenU pass1 UP_xenU(mem=256) SMPVTI_LTPpassVTI (vcpus=4, mem=512) run LTP SMPVTI_and_SMPXenU pass 1 VTI + 1 xenU (mem=256 vcpus=2) Two_SMPXenU_Coexistpass2 xenU (mem=256, vcpus=2) One_SMPVTI_4096M pass 1 VTI (vcpus=2, mem=4096M) SMPVTI_Network pass 1 VTI (mem=256,vcpu=2) and 'ping' SMPXenU_Networkpass 1 XenU (vcpus=2) and 'ping' One_SMP_XenU pass 1 SMP xenU (vcpus=2) One_SMP_VTIpass 1 SMP VTI (vcpus=2) SMPVTI_Kernel_Build pass VTI (vcpus=4) and do Kernel Build Four_SMPVTI_Coexist pass 4 VTI domains( mem=256, vcpu=2) SMPVTI_Windows pass SMPVTI windows(vcpu=2) SMPWin_SMPVTI_SMPxenU pass SMPVTI Linux/Windows XenU UPVTI_Kernel_Build pass 1 UP VTI and do kernel build Notes: - The last stable changeset: - 12014:9c649ca5c1cc Thanks, Zhangjingke ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] Follow new interrupt deliver mechanism for PV-on-HVM/IPF
You (alex.williamson) said: I think that the definition should be in xen/include/public/hvm/params.h or xen/include/public/arch-ia64.h. What do you think about this ? It's ia64 specific, so arch-ia64.h seems more appropriate. Thank you for your advice. I'll modify the code with your opinion. Just an FYI, I think we're close enough to when Keir wants to make a final 3.0.4 release that I don't plan to request another pull of the xen-ia64 tree unless it's absolutely necessary. If you think this is necessary for 3.0.4, please provide justification. Thanks, In current xen-ia64 tree, PV-on-HVM feature does not work, thus this fix is necessary, I think. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [Xen-devel] Question about evtchn_callback reentry
Keir Fraser write on 2006年12月18日 21:42: On 18/12/06 11:24, Keir Fraser [EMAIL PROTECTED] wrote: Okay, so I remember now that of course the APIC divides these into 16 priority levels so that does rather restrict the maximum nesting. I'll be happy to consider adding prioritisation (or just complete disallow of nesting) for 3.0.5. Hi Keir, I did a experiment, If we completely disallow of nesting. Even dom0 can't boot. I suspected timer interrupt is blocked by other events. --Anthony -- Keir ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [Xen-devel] unnecessary VCPU migration happens again
Emmanuel Ackaouy write on 2006年12月19日 17:00: On Dec 19, 2006, at 8:02, Xu, Anthony wrote: Can you dump the credit scheduler stat counter before and after you run the benchmark? (^A^A^A on the dom0/hypervisor console to switch to the hypervisor and then type the r key to dump scheduler info). That along with an idea of the elapsed time between the two stat samples would be handy. Hi Emmanuel, I got the dump scheduler info. The evironment is, Two sockects, two cores per sockect. Dom0 is UP, DomVTI is 2 VCPU SMP, There are 4 physical CPUs, There are 3 VCPUs totally. We run Kernel Build on VTI domain. make -j3 Before running KB (XEN) *** Serial input - DOM0 (type 'CTRL-a' three times to switch input to Xen). (XEN) *** Serial input - Xen (type 'CTRL-a' three times to switch input to DOM0). (XEN) Scheduler: SMP Credit Scheduler (credit) (XEN) info: (XEN) ncpus = 4 (XEN) master = 0 (XEN) credit = 1200 (XEN) credit balance = 0 (XEN) weight = 0 (XEN) runq_sort = 12233 (XEN) default-weight = 256 (XEN) msecs per tick = 10ms (XEN) credits per tick = 100 (XEN) ticks per tslice = 3 (XEN) ticks per acct = 3 (XEN) idlers: 0xf (XEN) stats: (XEN) schedule = 4521191 (XEN) acct_run = 12233 (XEN) acct_no_work = 26827 (XEN) acct_balance = 7 (XEN) acct_reorder = 0 (XEN) acct_min_credit= 0 (XEN) acct_vcpu_active = 4197 (XEN) acct_vcpu_idle = 4197 (XEN) vcpu_sleep = 16 (XEN) vcpu_wake_running = 140923 (XEN) vcpu_wake_onrunq = 0 (XEN) vcpu_wake_runnable = 2016395 (XEN) vcpu_wake_not_runnable = 0 (XEN) vcpu_park = 0 (XEN) vcpu_unpark= 0 (XEN) tickle_local_idler = 2016206 (XEN) tickle_local_over = 2 (XEN) tickle_local_under = 39 (XEN) tickle_local_other = 0 (XEN) tickle_idlers_none = 0 (XEN) tickle_idlers_some = 204 (XEN) load_balance_idle = 2432213 (XEN) load_balance_over = 132 (XEN) load_balance_other = 0 (XEN) steal_trylock_failed = 12730 (XEN) steal_peer_idle= 1197122 (XEN) migrate_queued = 169 (XEN) migrate_running= 213 (XEN) dom_init = 4 (XEN) dom_destroy= 1 (XEN) vcpu_init = 9 (XEN) vcpu_destroy = 2 (XEN) active vcpus: (XEN) NOW=0x01114A1FE784 (XEN) CPU[00] tick=117181, sort=12233, sibling=0x1, core=0x5 (XEN) run: [32767.0] pri=-64 flags=0 cpu=0 (XEN) CPU[01] tick=117189, sort=12233, sibling=0x2, core=0xa (XEN) run: [32767.1] pri=-64 flags=0 cpu=1 (XEN) CPU[02] tick=117196, sort=12233, sibling=0x4, core=0x5 (XEN) run: [32767.2] pri=-64 flags=0 cpu=2 (XEN) CPU[03] tick=117176, sort=12233, sibling=0x8, core=0xa (XEN) run: [32767.3] pri=-64 flags=0 cpu=3 After running KB (XEN) Scheduler: SMP Credit Scheduler (credit) (XEN) info: (XEN) ncpus = 4 (XEN) master = 0 (XEN) credit = 1200 (XEN) credit balance = 0 (XEN) weight = 0 (XEN) runq_sort = 42999 (XEN) default-weight = 256 (XEN) msecs per tick = 10ms (XEN) credits per tick = 100 (XEN) ticks per tslice = 3 (XEN) ticks per acct = 3 (XEN) idlers: 0xf (XEN) stats: (XEN) schedule = 8233816 (XEN) acct_run = 42999 (XEN) acct_no_work = 28931 (XEN) acct_balance = 47 (XEN) acct_reorder = 0 (XEN) acct_min_credit= 0 (XEN) acct_vcpu_active = 9963 (XEN) acct_vcpu_idle = 9963 (XEN) vcpu_sleep = 16 (XEN) vcpu_wake_running = 240904 (XEN) vcpu_wake_onrunq = 0 (XEN) vcpu_wake_runnable = 3697995 (XEN) vcpu_wake_not_runnable = 0 (XEN) vcpu_park = 0 (XEN) vcpu_unpark= 0 (XEN) tickle_local_idler = 3697336 (XEN) tickle_local_over = 18 (XEN) tickle_local_under = 148 (XEN) tickle_local_other = 0 (XEN) tickle_idlers_none = 0 (XEN) tickle_idlers_some = 669 (XEN) load_balance_idle = 4394421 (XEN) load_balance_over = 503 (XEN) load_balance_other = 0 (XEN) steal_trylock_failed = 23268 (XEN) steal_peer_idle= 3014315 (XEN) migrate_queued = 533 (XEN) migrate_running= 743 (XEN) dom_init = 4 (XEN) dom_destroy= 1
Re: [Xen-ia64-devel] [Patch] Follow new interrupt deliver mechanism for PV-on-HVM/IPF
Hi Alex,
[EMAIL PROTECTED] wrote:
You (alex.williamson) said:
I think that the definition should be in xen/include/public/hvm/params.h
or xen/include/public/arch-ia64.h.
What do you think about this ?
It's ia64 specific, so arch-ia64.h seems more appropriate.
Thank you for your advice. I'll modify the code with your opinion.
I modified this patch, and tested it.
Just an
FYI, I think we're close enough to when Keir wants to make a final 3.0.4
release that I don't plan to request another pull of the xen-ia64 tree
unless it's absolutely necessary. If you think this is necessary for
3.0.4, please provide justification. Thanks,
In current xen-ia64 tree, PV-on-HVM feature does not work, thus
this fix is necessary, I think.
My opinion is that..
* New interrupt deliver mechanism broke PV-on-HVM feature, thus
it doesn't work with current xen-ia64 tree.
* This fix is necessary for re-enabling PV-on-HVM feature on IPF.
Thanks,
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 6870c9948e5c63cd9ba8d9427b70f91ec467605e
# Parent 934315daf75988b8b5b6cc370d6114ec014ed20b
Follow new interrupt deliver mechanism for PV-on-HVM/IPF (driver side)
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r 934315daf759 -r 6870c9948e5c
unmodified_drivers/linux-2.6/platform-pci/platform-pci.c
--- a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c Wed Dec 20
11:36:49 2006 +0900
+++ b/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c Wed Dec 20
11:38:31 2006 +0900
@@ -182,12 +182,16 @@ static int get_callback_irq(struct pci_d
static int get_callback_irq(struct pci_dev *pdev)
{
#ifdef __ia64__
- int irq;
+ int irq, rid;
for (irq = 0; irq 16; irq++) {
if (isa_irq_to_vector(irq) == pdev-irq)
return irq;
}
- return 0;
+ /* use Requester-ID as callback_irq */
+ /* RID: '#bus(8)#dev(5)#func(3)' (cf. PCI-Express spec) */
+ rid = ((pdev-bus-number 0xff) 8) | pdev-devfn;
+ printk(KERN_INFO DRV_NAME :use Requester-ID(%04x) as callback irq\n,
rid);
+ return rid | HVM_PARAM_CALLBACK_IRQ_USING_RID;
#else /* !__ia64__ */
return pdev-irq;
#endif
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 934315daf75988b8b5b6cc370d6114ec014ed20b
# Parent c3b455c4676c6446cd541d4c67a521609d046ddb
Follow new interrupt deliver mechanism for PV-on-HVM/IPF (hypervisor side)
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r c3b455c4676c -r 934315daf759 xen/arch/ia64/vmx/vmx_process.c
--- a/xen/arch/ia64/vmx/vmx_process.c Tue Dec 19 13:31:48 2006 -0700
+++ b/xen/arch/ia64/vmx/vmx_process.c Wed Dec 20 11:36:49 2006 +0900
@@ -212,8 +212,18 @@ void leave_hypervisor_tail(struct pt_reg
if (callback_irq != 0 local_events_need_delivery()) {
/* change level for para-device callback irq */
/* use level irq to send discrete event */
-viosapic_set_irq(d, callback_irq, 1);
-viosapic_set_irq(d, callback_irq, 0);
+if (callback_irq HVM_PARAM_CALLBACK_IRQ_USING_RID) {
+/* case of using Requester-ID as callback irq */
+/* RID: '#bus(8)#dev(5)#func(3)' */
+int rid = callback_irq ~HVM_PARAM_CALLBACK_IRQ_USING_RID;
+viosapic_set_pci_irq(d, ((rid 3) 0x1f), 0, 1);
+viosapic_set_pci_irq(d, ((rid 3) 0x1f), 0, 0);
+}
+else {
+/* case of using GSI as callback irq */
+viosapic_set_irq(d, callback_irq, 1);
+viosapic_set_irq(d, callback_irq, 0);
+}
}
}
diff -r c3b455c4676c -r 934315daf759 xen/include/public/arch-ia64.h
--- a/xen/include/public/arch-ia64.hTue Dec 19 13:31:48 2006 -0700
+++ b/xen/include/public/arch-ia64.hWed Dec 20 11:36:49 2006 +0900
@@ -61,6 +61,10 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
#define VIRQ_ITCVIRQ_ARCH_0 /* V. Virtual itc timer */
#define VIRQ_MCA_CMCVIRQ_ARCH_1 /* MCA cmc interrupt */
#define VIRQ_MCA_CPEVIRQ_ARCH_2 /* MCA cpe interrupt */
+
+/* Arch specific callback irq definition */
+/* using Requester-ID(RID) as callback irq */
+#define HVM_PARAM_CALLBACK_IRQ_USING_RID(1 31)
/* Maximum number of virtual CPUs in multi-processor guests. */
/* WARNING: before changing this, check that shared_info fits on a page */
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
