Xen 3.1.1 -- initial patchqueue

Xen 3.1.1 -- initial patchqueue

[Keir Fraser]

Hi,

A provisional patchqueue for Xen 3.1.1 is available at
http://xenbits.xensource.com/xen-3.1-testing.pq.hg. This pq partners with
http://xenbits.xensource.com/xen-3.1-testing.hg.

Please kick this pq around and check whether the patches you want to see in
3.1.1 are included.

 -- Keir

Re: Xen 3.1.1 -- initial patchqueue

[Jambunathan K]

Keir

The fix discussed in the Xen-Devel thread "PCI Passthru: fn0 exported but not
fn1"  is not in the pq. Please include the same.

http://lists.xensource.com/archives/html/xen-devel/2007-08/msg00549.html
http://lists.xensource.com/archives/html/xen-devel/2007-08/msg00595.html
http://lists.xensource.com/archives/html/xen-devel/2007-08/msg00674.html

Regards,
Jambunathan K.

Keir Fraser wrote:
> Hi,
> 
> A provisional patchqueue for Xen 3.1.1 is available at
> http://xenbits.xensource.com/xen-3.1-testing.pq.hg. This pq partners with
> http://xenbits.xensource.com/xen-3.1-testing.hg.
> 
> Please kick this pq around and check whether the patches you want to see in
> 3.1.1 are included.
> 
>  -- Keir
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

Re: Xen 3.1.1 -- initial patchqueue

[Keir Fraser]

Forgot about that one. Will do.

 -- Keir



On 10/9/07 11:55, "Jambunathan K" <jambunathan@netxen.com> wrote:

> Keir
> 
> The fix discussed in the Xen-Devel thread "PCI Passthru: fn0 exported but not
> fn1"  is not in the pq. Please include the same.
> 
> http://lists.xensource.com/archives/html/xen-devel/2007-08/msg00549.html
> http://lists.xensource.com/archives/html/xen-devel/2007-08/msg00595.html
> http://lists.xensource.com/archives/html/xen-devel/2007-08/msg00674.html
> 
> Regards,
> Jambunathan K.
> 
> Keir Fraser wrote:
>> Hi,
>> 
>> A provisional patchqueue for Xen 3.1.1 is available at
>> http://xenbits.xensource.com/xen-3.1-testing.pq.hg. This pq partners with
>> http://xenbits.xensource.com/xen-3.1-testing.hg.
>> 
>> Please kick this pq around and check whether the patches you want to see in
>> 3.1.1 are included.
>> 
>>  -- Keir
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>> 
> 

Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue

[Ben Guthro]

The ones I can see missing from our local patch queue are:

Xen:
15185-1f8fb764f843
http://xenbits.xensource.com/xen-unstable.hg?rev/1f8fb764f843

15806-577313e3c0a6 (not exactly crucial, but would be nice)
http://xenbits.xensource.com/xen-unstable.hg?rev/577313e3c0a6

linux:
189-720571c2139e
http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/720571c2139e

193-9e03bcda0054
http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/9e03bcda0054


Keir Fraser wrote:
> Hi,
>
> A provisional patchqueue for Xen 3.1.1 is available at
> http://xenbits.xensource.com/xen-3.1-testing.pq.hg. This pq partners with
> http://xenbits.xensource.com/xen-3.1-testing.hg.
>
> Please kick this pq around and check whether the patches you want to see in
> 3.1.1 are included.
>
>  -- Keir
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>   

Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue

[Keir Fraser]

On 10/9/07 13:03, "Ben Guthro" <bguthro@virtualiron.com> wrote:

> 15185-1f8fb764f843
> http://xenbits.xensource.com/xen-unstable.hg?rev/1f8fb764f843

I'm inclined not to backport this one.

> 15806-577313e3c0a6 (not exactly crucial, but would be nice)
> http://xenbits.xensource.com/xen-unstable.hg?rev/577313e3c0a6

Yes could take this one.

The two Linux changesets are not applicable to 3.1.

 -- Keir

> linux:
> 189-720571c2139e
> http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/720571c2139e
> 
> 193-9e03bcda0054
> http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/9e03bcda0054

Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue

[Ben Guthro]

Keir Fraser wrote:
> On 10/9/07 13:03, "Ben Guthro" <bguthro@virtualiron.com> wrote:
>
>   
>> 15185-1f8fb764f843
>> http://xenbits.xensource.com/xen-unstable.hg?rev/1f8fb764f843
>>     
> I'm inclined not to backport this one.
>
>   
If I recall - It applied against our 3.1 tree without any 
backporting...we just exported, and applied it. It increased performance 
on Caneland machines greatly. Test results against our 3.1 based product 
below:

<test results>
At Ben's request, I did a quick evaluation of the APIC TPR patch for 
Caneland.
I used yesterday's build to establish a baseline for booting, running 
SPECjbb2005, and
netperf on a SMP XP guest. I then repeated the tests with a custom 
kernel. The patch
showed significant improvement for 2 of the 3 tests I used. Here are the 
results:

Test                 20070816     Patch    % Improvement
Boot time - Seconds    62.6        40.5         35%
SPECjbb2005 OPs/Sec   35216       35686          1%
TCP XMIT (MBits/sec)   70.2       309.5        341%
TCP RCV (MBits/Sec)   122.3       423.5        246%

These tests were done on a Caneland, with 4 quad-core sockets and 32GB 
of memory.
The guest is Windows XP Professional with SP2, 2 CPUs, 2GB memory. This 
afternoon,
I'll repeat the experiment on a non-Caneland machine to see if there are 
any
side effects.

</test results>

> The two Linux changesets are not applicable to 3.1.
>   
Yes, of course...my mistake. I forgot to weed out my "unstable-only" 
patches from the list.

Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue

[Ben Guthro]

Also - what tool are you using to apply these patches?

mercurial queues seem to be incompatible with some of the non utf-8 
characters in some of the patches:

applying 15075-5efb46bfbcac
applying 15076-9ec165fa8128
applying 15077-711bfe07999b
applying 15078-6145e5508d6b
abort: decoding near 'Ingard Mev�g <ingard': 'utf8' codec can't decode 
bytes in position 186-188: invalid data!
transaction abort!
rollback completed

Ben Guthro wrote:
> Keir Fraser wrote:
>> On 10/9/07 13:03, "Ben Guthro" <bguthro@virtualiron.com> wrote:
>>
>>> 15185-1f8fb764f843
>>> http://xenbits.xensource.com/xen-unstable.hg?rev/1f8fb764f843
>> I'm inclined not to backport this one.
>>
> If I recall - It applied against our 3.1 tree without any 
> backporting...we just exported, and applied it. It increased 
> performance on Caneland machines greatly. Test results against our 3.1 
> based product below:
>
> <test results>
> At Ben's request, I did a quick evaluation of the APIC TPR patch for 
> Caneland.
> I used yesterday's build to establish a baseline for booting, running 
> SPECjbb2005, and
> netperf on a SMP XP guest. I then repeated the tests with a custom 
> kernel. The patch
> showed significant improvement for 2 of the 3 tests I used. Here are 
> the results:
>
> Test 20070816 Patch % Improvement
> Boot time - Seconds 62.6 40.5 35%
> SPECjbb2005 OPs/Sec 35216 35686 1%
> TCP XMIT (MBits/sec) 70.2 309.5 341%
> TCP RCV (MBits/Sec) 122.3 423.5 246%
>
> These tests were done on a Caneland, with 4 quad-core sockets and 32GB 
> of memory.
> The guest is Windows XP Professional with SP2, 2 CPUs, 2GB memory. 
> This afternoon,
> I'll repeat the experiment on a non-Caneland machine to see if there 
> are any
> side effects.
>
> </test results>
>
>> The two Linux changesets are not applicable to 3.1.
> Yes, of course...my mistake. I forgot to weed out my "unstable-only" 
> patches from the list.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Xen 3.1.1 -- initial patchqueue

[Keir Fraser]

We're using mercurial patchqueues. Mercurial version 0.9.1. I've just cloned
and applied the patch queue from scratch with no problems.

 -- Keir

On 10/9/07 13:28, "Ben Guthro" <bguthro@virtualiron.com> wrote:

> Also - what tool are you using to apply these patches?
> 
> mercurial queues seem to be incompatible with some of the non utf-8
> characters in some of the patches:
> 
> applying 15075-5efb46bfbcac
> applying 15076-9ec165fa8128
> applying 15077-711bfe07999b
> applying 15078-6145e5508d6b
> abort: decoding near 'Ingard Mev�g <ingard': 'utf8' codec can't decode
> bytes in position 186-188: invalid data!
> transaction abort!
> rollback completed
> 
> Ben Guthro wrote:
>> Keir Fraser wrote:
>>> On 10/9/07 13:03, "Ben Guthro" <bguthro@virtualiron.com> wrote:
>>> 
>>>> 15185-1f8fb764f843
>>>> http://xenbits.xensource.com/xen-unstable.hg?rev/1f8fb764f843
>>> I'm inclined not to backport this one.
>>> 
>> If I recall - It applied against our 3.1 tree without any
>> backporting...we just exported, and applied it. It increased
>> performance on Caneland machines greatly. Test results against our 3.1
>> based product below:
>> 
>> <test results>
>> At Ben's request, I did a quick evaluation of the APIC TPR patch for
>> Caneland.
>> I used yesterday's build to establish a baseline for booting, running
>> SPECjbb2005, and
>> netperf on a SMP XP guest. I then repeated the tests with a custom
>> kernel. The patch
>> showed significant improvement for 2 of the 3 tests I used. Here are
>> the results:
>> 
>> Test 20070816 Patch % Improvement
>> Boot time - Seconds 62.6 40.5 35%
>> SPECjbb2005 OPs/Sec 35216 35686 1%
>> TCP XMIT (MBits/sec) 70.2 309.5 341%
>> TCP RCV (MBits/Sec) 122.3 423.5 246%
>> 
>> These tests were done on a Caneland, with 4 quad-core sockets and 32GB
>> of memory.
>> The guest is Windows XP Professional with SP2, 2 CPUs, 2GB memory.
>> This afternoon,
>> I'll repeat the experiment on a non-Caneland machine to see if there
>> are any
>> side effects.
>> 
>> </test results>
>> 
>>> The two Linux changesets are not applicable to 3.1.
>> Yes, of course...my mistake. I forgot to weed out my "unstable-only"
>> patches from the list.
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 

Re: Xen 3.1.1 -- initial patchqueue

[Ben Guthro]

Keir Fraser wrote:
> We're using mercurial patchqueues. Mercurial version 0.9.1. I've just cloned
> and applied the patch queue from scratch with no problems.
>
>  -- Keir
>   
Perhaps it is a regression in the behavior of hg? I am using 0.9.3, and 
cannot get the patch queue to apply:


[bguthro@bguthro dev]$ rm -rf xen-3.1.hg/
[bguthro@bguthro dev]$ hg clone -q 
http://xenbits.xensource.com/xen-3.1-testing.hg xen-3.1.1.hg
abort: destination 'xen-3.1.1.hg' already exists
[bguthro@bguthro dev]$ rm -rf xen-3.1.1.hg/
[bguthro@bguthro dev]$ hg clone -q 
http://xenbits.xensource.com/xen-3.1-testing.hg xen-3.1.1.hg
[bguthro@bguthro dev]$ cd xen-3.1.1.hg/.hg
[bguthro@bguthro .hg]$ hg clone -q 
http://xenbits.xensource.com/xen-3.1-testing.pq.hg patches
[bguthro@bguthro .hg]$ cd ..
[bguthro@bguthro xen-3.1.1.hg]$ hg qpush -a
applying 15023-6e597e529fea
applying 15035-23c4790512db
applying 15038-e19ddfa781c5
applying 15039-60240a72e2b2
applying 15043-759d924af6d8
applying 15044-03a13457d993
applying 15045-5f6da38ff828
applying 15046-e527b4ff1948
applying 15048-e33cce8fa400
applying 15049-174995130550
applying 15051-384a29655270
applying 15052-65ce4866d20b
applying 15053-3ecf51689671
applying 15056-a605044ecb33
applying 15057-75b4c7cb007d
applying 15058-3581a77791e3
applying 15061-05ea0d79a92f
applying 15062-b2adb797900a
applying 15063-807f374e720d
applying 15064-eb027b704dc5
applying 15065-f4390e34ad12
applying 15066-9e9c09c75110
applying 15067-c027880b50b4
applying 15068-dc4324d3fbb0
applying 15069-cb006eecd6f5
applying 15070-fbce94a9feaa
applying 15072-d4a0706d6747
applying 15073-e1f43038f1d8
applying 15074-5c7a1e3abd54
applying 15075-5efb46bfbcac
applying 15076-9ec165fa8128
applying 15077-711bfe07999b
applying 15078-6145e5508d6b
abort: decoding near 'Ingard Mev�g <ingard': 'utf8' codec can't decode 
bytes in position 186-188: invalid data!
transaction abort!
rollback completed
[bguthro@bguthro xen-3.1.1.hg]$ hg --version
Mercurial Distributed SCM (version 0.9.3)

Copyright (C) 2005, 2006 Matt Mackall <mpm@selenic.com>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Re: Xen 3.1.1 -- initial patchqueue

[Ian Campbell]

On Mon, 2007-09-10 at 08:48 -0400, Ben Guthro wrote:
> Keir Fraser wrote:
> > We're using mercurial patchqueues. Mercurial version 0.9.1. I've just cloned
> > and applied the patch queue from scratch with no problems.
> >
> >  -- Keir
> >   
> Perhaps it is a regression in the behavior of hg? I am using 0.9.3, and 
> cannot get the patch queue to apply:

Perhaps something in the environment, e.g. $LANG?

Ian.

Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue

[Keir Fraser]

Or mercurial has a dependency that behaves differently on your system. This
patchqueue is only temporary until the 3.1.1 release -- I'd just modify that
one patch in your private repo to exclude the troublesome character.

 -- Keir

On 10/9/07 13:48, "Ben Guthro" <bguthro@virtualiron.com> wrote:

> 
> Keir Fraser wrote:
>> We're using mercurial patchqueues. Mercurial version 0.9.1. I've just cloned
>> and applied the patch queue from scratch with no problems.
>> 
>>  -- Keir
>>   
> Perhaps it is a regression in the behavior of hg? I am using 0.9.3, and
> cannot get the patch queue to apply:
> 
> 
> [bguthro@bguthro dev]$ rm -rf xen-3.1.hg/
> [bguthro@bguthro dev]$ hg clone -q
> http://xenbits.xensource.com/xen-3.1-testing.hg xen-3.1.1.hg
> abort: destination 'xen-3.1.1.hg' already exists
> [bguthro@bguthro dev]$ rm -rf xen-3.1.1.hg/
> [bguthro@bguthro dev]$ hg clone -q
> http://xenbits.xensource.com/xen-3.1-testing.hg xen-3.1.1.hg
> [bguthro@bguthro dev]$ cd xen-3.1.1.hg/.hg
> [bguthro@bguthro .hg]$ hg clone -q
> http://xenbits.xensource.com/xen-3.1-testing.pq.hg patches
> [bguthro@bguthro .hg]$ cd ..
> [bguthro@bguthro xen-3.1.1.hg]$ hg qpush -a
> applying 15023-6e597e529fea
> applying 15035-23c4790512db
> applying 15038-e19ddfa781c5
> applying 15039-60240a72e2b2
> applying 15043-759d924af6d8
> applying 15044-03a13457d993
> applying 15045-5f6da38ff828
> applying 15046-e527b4ff1948
> applying 15048-e33cce8fa400
> applying 15049-174995130550
> applying 15051-384a29655270
> applying 15052-65ce4866d20b
> applying 15053-3ecf51689671
> applying 15056-a605044ecb33
> applying 15057-75b4c7cb007d
> applying 15058-3581a77791e3
> applying 15061-05ea0d79a92f
> applying 15062-b2adb797900a
> applying 15063-807f374e720d
> applying 15064-eb027b704dc5
> applying 15065-f4390e34ad12
> applying 15066-9e9c09c75110
> applying 15067-c027880b50b4
> applying 15068-dc4324d3fbb0
> applying 15069-cb006eecd6f5
> applying 15070-fbce94a9feaa
> applying 15072-d4a0706d6747
> applying 15073-e1f43038f1d8
> applying 15074-5c7a1e3abd54
> applying 15075-5efb46bfbcac
> applying 15076-9ec165fa8128
> applying 15077-711bfe07999b
> applying 15078-6145e5508d6b
> abort: decoding near 'Ingard Mev�g <ingard': 'utf8' codec can't decode
> bytes in position 186-188: invalid data!
> transaction abort!
> rollback completed
> [bguthro@bguthro xen-3.1.1.hg]$ hg --version
> Mercurial Distributed SCM (version 0.9.3)
> 
> Copyright (C) 2005, 2006 Matt Mackall <mpm@selenic.com>
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> 

Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue

[Brendan Cully]

On Monday, 10 September 2007 at 08:48, Ben Guthro wrote:
>
> Keir Fraser wrote:
>> We're using mercurial patchqueues. Mercurial version 0.9.1. I've
>> just cloned and applied the patch queue from scratch with no
>> problems.
>>   
> Perhaps it is a regression in the behavior of hg? I am using 0.9.3, and 
> cannot get the patch queue to apply:
...
> [bguthro@bguthro xen-3.1.1.hg]$ hg qpush -a
...
> applying 15078-6145e5508d6b
> abort: decoding near 'Ingard Mev�g <ingard': 'utf8' codec can't decode 
> bytes in position 186-188: invalid data!
> transaction abort!
> rollback completed

Looks like the patch header is latin-1 (or thereabouts) and your LANG
is utf-8. "LANG=latin-1 hg qpush" is likely to fix it, and
"HGENCODINGMODE=replace hg push -a" will silently replace any
undecodable characters with ?. Since this only applies to the patch
header it's probably fine for your purposes.

Re: Xen 3.1.1 -- initial patchqueue

[Ben Guthro]

[-- Attachment #1: Type: text/plain, Size: 342 bytes --]

Keir Fraser wrote:
> On 10/9/07 13:03, "Ben Guthro" <bguthro@virtualiron.com> wrote:
>
>   
>> 15185-1f8fb764f843
>> http://xenbits.xensource.com/xen-unstable.hg?rev/1f8fb764f843
>>     
>
> I'm inclined not to backport this one.
>   
Attached is the exported changeset, series file, and updated patch 
15473, should you change your mind.




[-- Attachment #2: 15473-300d1effb792 --]
[-- Type: text/plain, Size: 3673 bytes --]

# HG changeset patch
# User kfraser@localhost.localdomain
# Node ID 300d1effb792700ad231a9627443be4158b832a8
# Parent  d6078c9423555d7ada248594114ff041893bade6
Use short name format when reference to vcpu vmx union member.
Signed-off-by: Xin Li <xin.b.li@intel.com>
xen-unstable changeset: 15473:300d1effb792700ad231a9627443be4158b832a8
xen-unstable date: Fri Jul 06 14:36:34 2007 +0100

diff -r 3df9bf768ba3 xen/arch/x86/hvm/vmx/intr.c
--- a/xen/arch/x86/hvm/vmx/intr.c	Mon Sep 10 09:13:38 2007 -0400
+++ b/xen/arch/x86/hvm/vmx/intr.c	Mon Sep 10 09:13:38 2007 -0400
@@ -73,7 +73,7 @@
 
 static void enable_irq_window(struct vcpu *v)
 {
-    u32  *cpu_exec_control = &v->arch.hvm_vcpu.u.vmx.exec_control;
+    u32  *cpu_exec_control = &v->arch.hvm_vmx.exec_control;
     
     if ( !(*cpu_exec_control & CPU_BASED_VIRTUAL_INTR_PENDING) )
     {
diff -r 3df9bf768ba3 xen/arch/x86/hvm/vmx/vmcs.c
--- a/xen/arch/x86/hvm/vmx/vmcs.c	Mon Sep 10 09:13:38 2007 -0400
+++ b/xen/arch/x86/hvm/vmx/vmcs.c	Mon Sep 10 09:15:23 2007 -0400
@@ -316,7 +316,7 @@ static void construct_vmcs(struct vcpu *
     __vmwrite(VM_EXIT_CONTROLS, vmx_vmexit_control);
     __vmwrite(VM_ENTRY_CONTROLS, vmx_vmentry_control);
     __vmwrite(CPU_BASED_VM_EXEC_CONTROL, vmx_cpu_based_exec_control);
-    v->arch.hvm_vcpu.u.vmx.exec_control = vmx_cpu_based_exec_control;
+    v->arch.hvm_vmx.exec_control = vmx_cpu_based_exec_control;
     if ( vmx_cpu_based_exec_control & ACTIVATE_SECONDARY_CONTROLS )
         __vmwrite(SECONDARY_VM_EXEC_CONTROL, vmx_secondary_exec_control);
 
diff -r 3df9bf768ba3 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Mon Sep 10 09:13:38 2007 -0400
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Mon Sep 10 09:13:38 2007 -0400
@@ -417,8 +417,8 @@ static inline void vmx_save_dr(struct vc
 
     /* Clear the DR dirty flag and re-enable intercepts for DR accesses. */
     v->arch.hvm_vcpu.flag_dr_dirty = 0;
-    v->arch.hvm_vcpu.u.vmx.exec_control |= CPU_BASED_MOV_DR_EXITING;
-    __vmwrite(CPU_BASED_VM_EXEC_CONTROL, v->arch.hvm_vcpu.u.vmx.exec_control);
+    v->arch.hvm_vmx.exec_control |= CPU_BASED_MOV_DR_EXITING;
+    __vmwrite(CPU_BASED_VM_EXEC_CONTROL, v->arch.hvm_vmx.exec_control);
 
     savedebug(&v->arch.guest_context, 0);
     savedebug(&v->arch.guest_context, 1);
@@ -1410,9 +1410,9 @@ static void vmx_dr_access(unsigned long 
     __restore_debug_registers(v);
 
     /* Allow guest direct access to DR registers */
-    v->arch.hvm_vcpu.u.vmx.exec_control &= ~CPU_BASED_MOV_DR_EXITING;
+    v->arch.hvm_vmx.exec_control &= ~CPU_BASED_MOV_DR_EXITING;
     __vmwrite(CPU_BASED_VM_EXEC_CONTROL,
-              v->arch.hvm_vcpu.u.vmx.exec_control);
+              v->arch.hvm_vmx.exec_control);
 }
 
 /*
@@ -2967,15 +2967,15 @@ asmlinkage void vmx_vmexit_handler(struc
         break;
     case EXIT_REASON_PENDING_VIRT_INTR:
         /* Disable the interrupt window. */
-        v->arch.hvm_vcpu.u.vmx.exec_control &= ~CPU_BASED_VIRTUAL_INTR_PENDING;
+        v->arch.hvm_vmx.exec_control &= ~CPU_BASED_VIRTUAL_INTR_PENDING;
         __vmwrite(CPU_BASED_VM_EXEC_CONTROL,
-                  v->arch.hvm_vcpu.u.vmx.exec_control);
+                  v->arch.hvm_vmx.exec_control);
         break;
     case EXIT_REASON_PENDING_VIRT_NMI:
         /* Disable the NMI window. */
-        v->arch.hvm_vcpu.u.vmx.exec_control &= ~CPU_BASED_VIRTUAL_NMI_PENDING;
+        v->arch.hvm_vmx.exec_control &= ~CPU_BASED_VIRTUAL_NMI_PENDING;
         __vmwrite(CPU_BASED_VM_EXEC_CONTROL,
-                  v->arch.hvm_vcpu.u.vmx.exec_control);
+                  v->arch.hvm_vmx.exec_control);
         break;
     case EXIT_REASON_TASK_SWITCH:
         goto exit_and_crash;

[-- Attachment #3: series --]
[-- Type: text/plain, Size: 6811 bytes --]

15023-6e597e529fea
15035-23c4790512db
15038-e19ddfa781c5
15039-60240a72e2b2
15043-759d924af6d8
15044-03a13457d993
15045-5f6da38ff828
15046-e527b4ff1948
15048-e33cce8fa400
15049-174995130550
15051-384a29655270
15052-65ce4866d20b
15053-3ecf51689671
15056-a605044ecb33
15057-75b4c7cb007d
15058-3581a77791e3
15061-05ea0d79a92f
15062-b2adb797900a
15063-807f374e720d
15064-eb027b704dc5
15065-f4390e34ad12
15066-9e9c09c75110
15067-c027880b50b4
15068-dc4324d3fbb0
15069-cb006eecd6f5
15070-fbce94a9feaa
15072-d4a0706d6747
15073-e1f43038f1d8
15074-5c7a1e3abd54
15075-5efb46bfbcac
15076-9ec165fa8128
15077-711bfe07999b
15078-6145e5508d6b
15079-11a97dca57aa
15080-089696e0c603
15082-0fd2bf14f38a
15083-b9da101ed945
15128-f6928d636999
15130-a40967e39652
15132-17f6163ae930
15133-46095d5a59a9
15134-96915ca8d5f2
15135-e49b110cbb4a
15136-cc60c18247f1
15137-297d98f057e8
15138-471478a1b89e
15139-020530a6ff5c
15141-12a12637af46
15142-acee9e2c6f8b
15143-2623444e6d33
15144-f38f7f583f33
15147-36959baf05c0
15148-7ff65f888804
15149-8fcefab1d63b
15150-fe0499f6235c
15151-6223d154e55f
15152-853853686147
15153-f07c1bb86d6c
15154-965bf43c9f11
15155-1fde9ebb8019
15156-6a4af9502b4d
15157-3ef4a4d82130
15158-588bd40872ec
15160-21f1a7a7ea30
15161-e046da853ffc
15162-d1cce5bafe28
15163-16e376ed5638
15165-4730ec3d5ab3
15166-546044bfd49f
15167-9073caff4b63
15168-a717cb2fac90
15170-ca62b4b4f762
15171-cf3cf0d1b175
15173-88e41a91301c
15174-a00d55b15327
15175-c49987e71dae
15176-f0772865c85a
15177-33242afccb32
15178-1bad5a932df5
15179-152dc0d812b2
15183-63211a8027fa
xen-unstable.hg-15185.patch
15188-ae073ca6eb76
15189-2d7d33ac982a
15190-c9d66baad22b
15193-d1d5ceb3c3ff
15194-4c2b8ca4842c
15197-2d3034d0b36b
15199-13eca4bf2c69
15200-bd3d6b4c52ec
15207-c388a2ff1b8e
15208-6c636bd3f874
15209-20ccb03e738d
15214-5710c94e6539
15216-6f13c3be08fa
15217-7a16a499152c
15221-4f05a587cb6b
15222-0feaf2fc75d3
15223-c5cf3942b5da
15226-736e7cf0a3a5
15227-f5a71c9771a8
15228-677731eb734d
15232-d47415adf384
15233-3a413f011b8f
15235-a7601de2f733
15236-56bab6f498ac
15237-a5ae31a91b10
15238-345ae2e61ba0
15239-656b8175f4f2
15240-55230846b2f4
15243-3cc79ef896a2
15244-91aeaf000ca2
15245-608ddb14259b
15247-ac9d3bcc7a78
15248-7eeddd787d2f
15249-93f77a5a8437
15250-a43a03d53781
15251-6f06bd06ef47
15253-ebe4140fe4f8
15255-3d5f39c610ad
15256-2c8c6ca1296b
15258-bd94f75fe469
15259-35e38c9048c8
15261-112703751b19
15262-9766af047b6c
15263-feeca16435bf
15264-e1c54c14220a
15266-b515e66234e8
15267-be33028fcda5
15268-699f0c429620
15269-c56ebab69b84
15270-0f9d683a83ed
15272-30449e0e0a64
15273-7f9362a8ae3d
15274-ffdbe8aebde2
15275-b643179d7452
15276-4d8381679606
15277-912f7e312ec2
15278-a0c0c7efffca
15279-80eb95dc0dd9
15280-80577631fb87
15281-356588dda4bc
15283-e08cbd487414
15284-276b48771f1e
15285-b4c16658ca30
15287-ba61ec7df632
15288-f1ba2e652724
15289-8ad38aaaeb89
15290-56548d9a7ba7
15291-1feb91894e11
15373-58b6223074af
15374-b1eb43f94a3a
15375-342c85cfd00b
15376-c3f280acf41a
15377-75d82009ec70
15378-5794f9b80c3f
15379-8eaee9ef472f
15380-07688f8f5394
15381-f1ca92bf7e0f
15382-cb747a35e057
15383-896b536d66c9
15386-fb5077ecf9a4
15387-739d698986e9
15389-07be0266f6d8
15390-69658f935cc7
15391-fe3df33e2761
15393-63077ce6a7dc
15394-168b143a1a88
15395-3187ffc5272c
15396-2805246f6cac
15398-499bab040137
15399-45a44a9cbe8d
15400-005dd6b1cf8e
15401-79b180596baf
15402-799b3e4bfeac
15404-f50f0ec7dd2c
15406-296fd2598e00
15407-6310aebd34a6
15408-cf846f4d756f
15409-11bf94b2d51a
15410-a83632dfbb28
15411-5ec34f7f31ab
15412-acb7aa72fac7
15413-899a44cb6ef6
15414-3cf5052ba5e5
15415-04d4b7b6f5b7
15416-b35b8053012e
15417-015d9abeacfb
15418-3f76b2f76c2a
15420-b14bbd41e9dc
15421-c72a93cbcedb
15422-16f35bea00f8
15423-5eec9a8825d4
15424-87d34c8c2fe1
15427-4ab9e4bbd61b
15429-b370047d0fa0
15431-3362de397f1e
15432-d0608ecb56bc
15433-a5360bf18668
15434-b377a102f0eb
15435-ab95b9764b20
15436-2cdf8fef8d93
15437-713bac7cba46
15439-a3a0202af8a4
15441-6e8199e555a6
15442-7a31e37fec9e
15443-5d7160564381
15445-182446677b6b
15446-f85252ce203e
15449-1e04c4be12aa
15450-b528cb182cc7
15451-296ffa18524a
15453-0900fb1a3693
15454-83cbda5c1e1b
15455-c192e3241eb7
15456-eb2b7ce05f97
15457-08bcc54aee8e
15458-8adfd96f62ae
15459-842e085dbb77
15460-b8e8061c5a98
15461-0528bc25c404
15462-eb71f258e855
15463-56da8753ba8d
15464-f1b62eb7f8be
15465-9fa9346e1c70
15469-936aa542053d
15470-b01225c94f83
15472-d6078c942355
15473-300d1effb792
15474-2dee920e0fd7
15475-57398acc1480
15476-f20ee5bc9d28
15477-3196b63a7301
15478-05331a29f3cb
15480-daa07db3ca84
15483-eaf3aa32fa88
15497-8528da5be577
15498-41c8284cfc0c
15499-50c18666d660
15500-259bb15b2d1e
15501-107b9bde5e4d
15502-99143d572521
15503-27e993c80ceb
15508-ecb89c6ce615
15509-646ec1f2b41f
15510-5e8eb0cf2daf
15511-83fd4ad219cd
15522-0eec072e870a
15524-26eef8426110
15528-637ff26be6ff
15535-c6491ed12f84
15583-b27add01a929
15584-48c8244c47c7
15588-0aa2a954a6d1
15590-f479595a3c5c
15592-a17f20a0fd19
15595-1158b6115b14
15596-d99903a98ad0
15605-4721e9d836dd
15606-4197a1aad70b
15621-f85acff5bef5
15637-eff24408830c
15643-68260372b6da
15644-3ec3e2840a29
15660-66055f773d19
15661-7c5c3aa858cc
15671-0c79a9414f8d
15673-f343d3c16dcc
15674-07364f8574b8
15684-52e5c110aadb
15686-0120cca78435
15692-b82e6818fb31
15693-c229802cedbb
fix-qemu-dm-event-loop-crash
linux-30-45dfe4cfc5ef
linux-31-396dfc842377
linux-32-dd861cfb5d1a
linux-34-0301c1fd8c0d
linux-35-85b046c1da18
linux-42-c09686d2bbff
linux-47-33c3009e73ec
linux-65-87bb8705768a
linux-66-496e3157a35c
linux-68-cadc6d58a9e6
linux-74-cb50d25a9468
linux-78-0be610b725fa
linux-80-4a284f968015
linux-81-cb040341e05a
linux-82-11483a00c017
linux-93-08cf42135056
linux-94-d36fd1c5db16
linux-99-f15643dab1ca
linux-100-5a4e93508aa0
linux-101-5684370b1c4d
linux-103-a70de77dd8d3
linux-104-06cd871a5a98
linux-105-b3c2f84be0bb
linux-106-9942e31a3ec5
linux-136-34ebf92ad28d
linux-137-41918416db51
linux-141-5e294e29a43e
linux-144-d88e59a7334a
linux-145-3b0bce92b2f2
linux-146-726cd201f4cd
linux-147-88a17da7f336
linux-148-667228bf8fc5
linux-150-09c88868e344
linux-151-1372bc676080
linux-152-8d5ae51a09a6
linux-156-d2f9b7e36231
linux-157-877c2e42a701
linux-190-f30b59f550c2
15706-359707941ae8
15712-b55fe44438bc
15713-db21f714d37f
15714-3876b4e7cc0a
15717-8c77ae93f982
15719-c362bcee8047
15720-f2649861d594
15721-01c721fddb90
15724-fdffab15499d
15725-ef79bf6f0142
15730-256160ff19b7
15733-cd511c380e03
15734-2ece8ff05ce7
15735-458e8b37aec8
15773-f279d776fcb0
15778-2aee2e4eacc8
15779-505021d029eb
15780-7f53312a3297
15781-8e3abd893835
15782-8e9ec8711efa
15785-747b71c8c4a8
15786-828e1df114d4
15788-c868eab6c99b
15789-2eb38cefdcd9
15790-b485d8d7347a
15791-c398dad9d50a
15799-3738840029b4
15800-fba9884685fb
15801-b3689eb59c5e
15802-d032a17aced2
15807-0f196e11a143
15815-2f13d0f2b07c
15817-ca0938180509
15830-32f331858d75
15832-f779ee15c553
15833-05950e909ba6
linux-191-1e2284d885fb
linux-192-5ce5bd383ea9

[-- Attachment #4: xen-unstable.hg-15185.patch --]
[-- Type: text/x-patch, Size: 15755 bytes --]

diff -r 8f147a735faf xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Fri Aug 17 14:47:30 2007 -0400
+++ b/xen/arch/x86/hvm/hvm.c	Fri Aug 17 14:47:32 2007 -0400
@@ -224,6 +224,7 @@ int hvm_domain_initialise(struct domain 
 
     spin_lock_init(&d->arch.hvm_domain.pbuf_lock);
     spin_lock_init(&d->arch.hvm_domain.irq_lock);
+    spin_lock_init(&d->arch.hvm_domain.vapic_access_lock);
 
     rc = paging_enable(d, PG_refcounts|PG_translate|PG_external);
     if ( rc != 0 )
diff -r 8f147a735faf xen/arch/x86/hvm/vlapic.c
--- a/xen/arch/x86/hvm/vlapic.c	Fri Aug 17 14:47:30 2007 -0400
+++ b/xen/arch/x86/hvm/vlapic.c	Fri Aug 17 14:47:32 2007 -0400
@@ -79,8 +79,6 @@ static unsigned int vlapic_lvt_mask[VLAP
 #define vlapic_lvtt_period(vlapic)                              \
     (vlapic_get_reg(vlapic, APIC_LVTT) & APIC_LVT_TIMER_PERIODIC)
 
-#define vlapic_base_address(vlapic)                             \
-    (vlapic->hw.apic_base_msr & MSR_IA32_APICBASE_BASE)
 
 /*
  * Generic APIC bitmap vector update & search routines.
diff -r 8f147a735faf xen/arch/x86/hvm/vmx/intr.c
--- a/xen/arch/x86/hvm/vmx/intr.c	Fri Aug 17 14:47:30 2007 -0400
+++ b/xen/arch/x86/hvm/vmx/intr.c	Fri Aug 17 14:47:32 2007 -0400
@@ -67,13 +67,17 @@ static inline int is_interruptibility_st
     return __vmread(GUEST_INTERRUPTIBILITY_INFO);
 }
 
-#ifdef __x86_64__
 static void update_tpr_threshold(struct vlapic *vlapic)
 {
     int max_irr, tpr;
 
     if ( !cpu_has_vmx_tpr_shadow )
         return;
+
+#ifdef __i386__
+    if ( !vlapic->mmap_vtpr_enabled )
+        return;
+#endif
 
     if ( !vlapic_enabled(vlapic) || 
          ((max_irr = vlapic_find_highest_irr(vlapic)) == -1) )
@@ -85,9 +89,6 @@ static void update_tpr_threshold(struct 
     tpr = vlapic_get_reg(vlapic, APIC_TASKPRI) & 0xF0;
     __vmwrite(TPR_THRESHOLD, (max_irr > tpr) ? (tpr >> 4) : (max_irr >> 4));
 }
-#else
-#define update_tpr_threshold(v) ((void)0)
-#endif
 
 asmlinkage void vmx_intr_assist(void)
 {
diff -r 8f147a735faf xen/arch/x86/hvm/vmx/vmcs.c
--- a/xen/arch/x86/hvm/vmx/vmcs.c	Fri Aug 17 14:47:30 2007 -0400
+++ b/xen/arch/x86/hvm/vmx/vmcs.c	Fri Aug 17 14:47:32 2007 -0400
@@ -40,6 +40,7 @@
 /* Dynamic (run-time adjusted) execution control flags. */
 u32 vmx_pin_based_exec_control __read_mostly;
 u32 vmx_cpu_based_exec_control __read_mostly;
+u32 vmx_secondary_exec_control __read_mostly;
 u32 vmx_vmexit_control __read_mostly;
 u32 vmx_vmentry_control __read_mostly;
 
@@ -59,12 +60,16 @@ static u32 adjust_vmx_controls(u32 ctl_m
 
     return ctl;
 }
+
+#define vmx_has_secondary_exec_ctls \
+    (_vmx_cpu_based_exec_control & ACTIVATE_SECONDARY_CONTROLS)
 
 void vmx_init_vmcs_config(void)
 {
     u32 vmx_msr_low, vmx_msr_high, min, opt;
     u32 _vmx_pin_based_exec_control;
     u32 _vmx_cpu_based_exec_control;
+    u32 _vmx_secondary_exec_control = 0;
     u32 _vmx_vmexit_control;
     u32 _vmx_vmentry_control;
 
@@ -80,9 +85,8 @@ void vmx_init_vmcs_config(void)
            CPU_BASED_ACTIVATE_IO_BITMAP |
            CPU_BASED_USE_TSC_OFFSETING);
     opt = CPU_BASED_ACTIVATE_MSR_BITMAP;
-#ifdef __x86_64__
     opt |= CPU_BASED_TPR_SHADOW;
-#endif
+    opt |= ACTIVATE_SECONDARY_CONTROLS;
     _vmx_cpu_based_exec_control = adjust_vmx_controls(
         min, opt, MSR_IA32_VMX_PROCBASED_CTLS_MSR);
 #ifdef __x86_64__
@@ -92,7 +96,18 @@ void vmx_init_vmcs_config(void)
         _vmx_cpu_based_exec_control = adjust_vmx_controls(
             min, opt, MSR_IA32_VMX_PROCBASED_CTLS_MSR);
     }
+#elif defined(__i386__)
+    if ( !vmx_has_secondary_exec_ctls )
+        _vmx_cpu_based_exec_control &= ~CPU_BASED_TPR_SHADOW;
 #endif
+
+    if ( vmx_has_secondary_exec_ctls )
+    {
+        min = 0;
+        opt = SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
+        _vmx_secondary_exec_control = adjust_vmx_controls(
+            min, opt, MSR_IA32_VMX_PROCBASED_CTLS2);
+    }
 
     min = VM_EXIT_ACK_INTR_ON_EXIT;
     opt = 0;
@@ -113,6 +128,8 @@ void vmx_init_vmcs_config(void)
         vmcs_revision_id = vmx_msr_low;
         vmx_pin_based_exec_control = _vmx_pin_based_exec_control;
         vmx_cpu_based_exec_control = _vmx_cpu_based_exec_control;
+        if ( vmx_has_secondary_exec_ctls )
+            vmx_secondary_exec_control = _vmx_secondary_exec_control;
         vmx_vmexit_control         = _vmx_vmexit_control;
         vmx_vmentry_control        = _vmx_vmentry_control;
     }
@@ -121,6 +138,8 @@ void vmx_init_vmcs_config(void)
         BUG_ON(vmcs_revision_id != vmx_msr_low);
         BUG_ON(vmx_pin_based_exec_control != _vmx_pin_based_exec_control);
         BUG_ON(vmx_cpu_based_exec_control != _vmx_cpu_based_exec_control);
+        if ( vmx_has_secondary_exec_ctls )
+            BUG_ON(vmx_secondary_exec_control != _vmx_secondary_exec_control);
         BUG_ON(vmx_vmexit_control != _vmx_vmexit_control);
         BUG_ON(vmx_vmentry_control != _vmx_vmentry_control);
     }
@@ -296,6 +315,8 @@ static void construct_vmcs(struct vcpu *
     __vmwrite(VM_ENTRY_CONTROLS, vmx_vmentry_control);
     __vmwrite(CPU_BASED_VM_EXEC_CONTROL, vmx_cpu_based_exec_control);
     v->arch.hvm_vcpu.u.vmx.exec_control = vmx_cpu_based_exec_control;
+    if ( vmx_cpu_based_exec_control & ACTIVATE_SECONDARY_CONTROLS )
+        __vmwrite(SECONDARY_VM_EXEC_CONTROL, vmx_secondary_exec_control);
 
     if ( cpu_has_vmx_msr_bitmap )
         __vmwrite(MSR_BITMAP, virt_to_maddr(vmx_msr_bitmap));
@@ -422,7 +443,7 @@ static void construct_vmcs(struct vcpu *
     __vmwrite(CR4_READ_SHADOW, v->arch.hvm_vmx.cpu_shadow_cr4);
 
 #ifdef __x86_64__ 
-    /* VLAPIC TPR optimisation. */
+    /* CR8 based VLAPIC TPR optimization. */
     if ( cpu_has_vmx_tpr_shadow )
     {
         __vmwrite(VIRTUAL_APIC_PAGE_ADDR,
@@ -430,6 +451,16 @@ static void construct_vmcs(struct vcpu *
         __vmwrite(TPR_THRESHOLD, 0);
     }
 #endif
+
+    /* Memory-mapped based VLAPIC TPR optimization. */
+    if ( cpu_has_vmx_mmap_vtpr_optimization )
+    {
+        __vmwrite(VIRTUAL_APIC_PAGE_ADDR,
+                    page_to_maddr(vcpu_vlapic(v)->regs_page));
+        __vmwrite(TPR_THRESHOLD, 0);
+
+        vcpu_vlapic(v)->mmap_vtpr_enabled = 1;
+    }
 
     __vmwrite(GUEST_LDTR_SELECTOR, 0);
     __vmwrite(GUEST_LDTR_BASE, 0);
@@ -499,6 +530,18 @@ void vmx_do_resume(struct vcpu *v)
         vmx_load_vmcs(v);
         hvm_migrate_timers(v);
         vmx_set_host_env(v);
+    }
+
+    if ( !v->arch.hvm_vmx.launched && vcpu_vlapic(v)->mmap_vtpr_enabled )
+    {
+        struct page_info *pg = change_guest_physmap_for_vtpr(v->domain, 1);
+
+        if ( pg == NULL )
+        {
+            gdprintk(XENLOG_ERR, "change_guest_physmap_for_vtpr failed!\n");
+            domain_crash_synchronous();
+        }
+        __vmwrite(APIC_ACCESS_ADDR, page_to_maddr(pg));
     }
 
     debug_state = v->domain->debugger_attached;
diff -r 8f147a735faf xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Fri Aug 17 14:47:30 2007 -0400
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Fri Aug 17 14:47:32 2007 -0400
@@ -2593,6 +2593,114 @@ done:
     return 1;
 }
 
+struct page_info * change_guest_physmap_for_vtpr(struct domain *d,
+                                                 int enable_vtpr)
+{
+    struct page_info *pg;
+    unsigned long pfn, mfn;
+
+    spin_lock(&d->arch.hvm_domain.vapic_access_lock);
+
+    pg = d->arch.hvm_domain.apic_access_page;
+    pfn = paddr_to_pfn(APIC_DEFAULT_PHYS_BASE);
+
+    if ( enable_vtpr )
+    {
+        if ( d->arch.hvm_domain.physmap_changed_for_vlapic_access )
+            goto out;
+
+        if ( pg == NULL )
+            pg = alloc_domheap_page(d);
+        if ( pg == NULL )
+        {
+            gdprintk(XENLOG_ERR, "alloc_domheap_pages() failed!\n");
+            goto out;
+        }
+
+        mfn = page_to_mfn(pg);
+        d->arch.hvm_domain.apic_access_page = pg;
+
+        guest_physmap_add_page(d, pfn, mfn);
+
+        d->arch.hvm_domain.physmap_changed_for_vlapic_access = 1;
+
+        goto out;
+    }
+    else
+    {
+        if ( d->arch.hvm_domain.physmap_changed_for_vlapic_access )
+        {
+            mfn = page_to_mfn(pg);
+            guest_physmap_remove_page(d, pfn, mfn);
+            flush_tlb_mask(d->domain_dirty_cpumask);
+
+            d->arch.hvm_domain.physmap_changed_for_vlapic_access = 0;
+        }
+        pg = NULL;
+        goto out;
+    }
+
+out:
+    spin_unlock(&d->arch.hvm_domain.vapic_access_lock);
+    return pg;
+}
+
+static void check_vlapic_msr_for_vtpr(struct vcpu *v)
+{
+    struct vlapic *vlapic = vcpu_vlapic(v);
+    int    mmap_vtpr_enabled = vcpu_vlapic(v)->mmap_vtpr_enabled;
+    uint32_t tmp;
+
+
+    if ( vlapic_hw_disabled(vlapic) && mmap_vtpr_enabled )
+    {
+        vcpu_vlapic(v)->mmap_vtpr_enabled = 0;    
+
+#ifdef __i386__
+        v->arch.hvm_vcpu.u.vmx.exec_control &= ~CPU_BASED_TPR_SHADOW;
+        __vmwrite(CPU_BASED_VM_EXEC_CONTROL,
+                  v->arch.hvm_vcpu.u.vmx.exec_control);
+#elif defined(__x86_64__)
+        if ( !cpu_has_vmx_tpr_shadow )
+        {
+            v->arch.hvm_vcpu.u.vmx.exec_control &= ~CPU_BASED_TPR_SHADOW;
+            __vmwrite(CPU_BASED_VM_EXEC_CONTROL,
+                v->arch.hvm_vcpu.u.vmx.exec_control);
+        }
+#endif
+        tmp  = __vmread(SECONDARY_VM_EXEC_CONTROL);
+        tmp &= ~SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
+        __vmwrite(SECONDARY_VM_EXEC_CONTROL, tmp);
+
+        change_guest_physmap_for_vtpr(v->domain, 0);
+    }
+    else if ( !vlapic_hw_disabled(vlapic) && !mmap_vtpr_enabled &&
+              cpu_has_vmx_mmap_vtpr_optimization )
+    {
+        vcpu_vlapic(v)->mmap_vtpr_enabled = 1;
+
+        v->arch.hvm_vcpu.u.vmx.exec_control |=
+            ( ACTIVATE_SECONDARY_CONTROLS | CPU_BASED_TPR_SHADOW );
+        __vmwrite(CPU_BASED_VM_EXEC_CONTROL,
+                  v->arch.hvm_vcpu.u.vmx.exec_control);
+        tmp  = __vmread(SECONDARY_VM_EXEC_CONTROL);
+        tmp |= SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
+        __vmwrite(SECONDARY_VM_EXEC_CONTROL, tmp);
+
+        change_guest_physmap_for_vtpr(v->domain, 1);
+    }
+
+    if ( vcpu_vlapic(v)->mmap_vtpr_enabled &&
+        !vlapic_hw_disabled(vlapic) &&
+        (vlapic_base_address(vlapic) != APIC_DEFAULT_PHYS_BASE) )
+    {
+        gdprintk(XENLOG_ERR,
+                 "Local APIC base address is set to 0x%016"PRIx64"!\n",
+                  vlapic_base_address(vlapic));
+        domain_crash_synchronous();
+    }
+}
+
 static inline int vmx_do_msr_write(struct cpu_user_regs *regs)
 {
     u32 ecx = regs->ecx;
@@ -2621,6 +2729,7 @@ static inline int vmx_do_msr_write(struc
         break;
     case MSR_IA32_APICBASE:
         vlapic_msr_set(vcpu_vlapic(v), msr_content);
+        check_vlapic_msr_for_vtpr(v);
         break;
     default:
         if ( !long_mode_do_msr_write(regs) )
@@ -2955,6 +3064,15 @@ asmlinkage void vmx_vmexit_handler(struc
 
     case EXIT_REASON_TPR_BELOW_THRESHOLD:
         break;
+    case EXIT_REASON_APIC_ACCESS:
+    {
+        unsigned long offset;
+
+        exit_qualification = __vmread(EXIT_QUALIFICATION);
+        offset = exit_qualification & 0x0fffUL;        
+        handle_mmio(APIC_DEFAULT_PHYS_BASE | offset);
+        break;
+    }
 
     default:
     exit_and_crash:
diff -r 8f147a735faf xen/include/asm-x86/hvm/domain.h
--- a/xen/include/asm-x86/hvm/domain.h	Fri Aug 17 14:47:30 2007 -0400
+++ b/xen/include/asm-x86/hvm/domain.h	Fri Aug 17 14:47:32 2007 -0400
@@ -41,6 +41,11 @@ struct hvm_domain {
     s64                    tsc_frequency;
     struct pl_time         pl_time;
 
+    /* For memory-mapped vLAPIC/vTPR access optimization */
+    spinlock_t             vapic_access_lock;
+    int                    physmap_changed_for_vlapic_access : 1;
+    struct page_info       *apic_access_page;
+
     struct hvm_io_handler  io_handler;
 
     /* Lock protects access to irq, vpic and vioapic. */
diff -r 8f147a735faf xen/include/asm-x86/hvm/vlapic.h
--- a/xen/include/asm-x86/hvm/vlapic.h	Fri Aug 17 14:47:30 2007 -0400
+++ b/xen/include/asm-x86/hvm/vlapic.h	Fri Aug 17 14:47:32 2007 -0400
@@ -49,12 +49,17 @@
 #define vlapic_disabled(vlapic)    ((vlapic)->hw.disabled)
 #define vlapic_enabled(vlapic)     (!vlapic_disabled(vlapic))
 
+#define vlapic_base_address(vlapic)                             \
+    (vlapic->hw.apic_base_msr & MSR_IA32_APICBASE_BASE)
+
 struct vlapic {
     struct hvm_hw_lapic      hw;
     struct hvm_hw_lapic_regs *regs;
     struct periodic_time     pt;
     s_time_t                 timer_last_update;
     struct page_info         *regs_page;
+
+    int                      mmap_vtpr_enabled : 1;
 };
 
 static inline uint32_t vlapic_get_reg(struct vlapic *vlapic, uint32_t reg)
diff -r 8f147a735faf xen/include/asm-x86/hvm/vmx/vmcs.h
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h	Fri Aug 17 14:47:30 2007 -0400
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h	Fri Aug 17 14:47:32 2007 -0400
@@ -104,6 +104,7 @@ void vmx_vmcs_exit(struct vcpu *v);
 #define CPU_BASED_ACTIVATE_MSR_BITMAP   0x10000000
 #define CPU_BASED_MONITOR_EXITING       0x20000000
 #define CPU_BASED_PAUSE_EXITING         0x40000000
+#define ACTIVATE_SECONDARY_CONTROLS     0x80000000
 extern u32 vmx_cpu_based_exec_control;
 
 #define PIN_BASED_EXT_INTR_MASK         0x00000001
@@ -119,8 +120,16 @@ extern u32 vmx_vmexit_control;
 #define VM_ENTRY_DEACT_DUAL_MONITOR     0x00000800
 extern u32 vmx_vmentry_control;
 
+#define SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES 0x00000001
+extern u32 vmx_secondary_exec_control;
+
+#define cpu_has_vmx_virtualize_apic_accesses \
+    (vmx_secondary_exec_control & SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES)
 #define cpu_has_vmx_tpr_shadow \
     (vmx_cpu_based_exec_control & CPU_BASED_TPR_SHADOW)
+#define cpu_has_vmx_mmap_vtpr_optimization \
+    (cpu_has_vmx_virtualize_apic_accesses && cpu_has_vmx_tpr_shadow)
+
 #define cpu_has_vmx_msr_bitmap \
     (vmx_cpu_based_exec_control & CPU_BASED_ACTIVATE_MSR_BITMAP)
 extern char *vmx_msr_bitmap;
@@ -158,6 +167,8 @@ enum vmcs_field {
     TSC_OFFSET_HIGH                 = 0x00002011,
     VIRTUAL_APIC_PAGE_ADDR          = 0x00002012,
     VIRTUAL_APIC_PAGE_ADDR_HIGH     = 0x00002013,
+    APIC_ACCESS_ADDR                = 0x00002014,
+    APIC_ACCESS_ADDR_HIGH           = 0x00002015, 
     VMCS_LINK_POINTER               = 0x00002800,
     VMCS_LINK_POINTER_HIGH          = 0x00002801,
     GUEST_IA32_DEBUGCTL             = 0x00002802,
diff -r 8f147a735faf xen/include/asm-x86/hvm/vmx/vmx.h
--- a/xen/include/asm-x86/hvm/vmx/vmx.h	Fri Aug 17 14:47:30 2007 -0400
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h	Fri Aug 17 14:47:32 2007 -0400
@@ -32,6 +32,9 @@ void vmx_intr_assist(void);
 void vmx_intr_assist(void);
 void vmx_do_resume(struct vcpu *);
 void set_guest_time(struct vcpu *v, u64 gtime);
+
+extern struct page_info *change_guest_physmap_for_vtpr(struct domain *d,
+                                                       int enable_vtpr);
 
 /*
  * Exit Reasons
@@ -81,6 +84,7 @@ void set_guest_time(struct vcpu *v, u64 
 #define EXIT_REASON_MACHINE_CHECK       41
 
 #define EXIT_REASON_TPR_BELOW_THRESHOLD 43
+#define EXIT_REASON_APIC_ACCESS         44
 
 /*
  * Interruption-information format
diff -r 8f147a735faf xen/include/asm-x86/msr.h
--- a/xen/include/asm-x86/msr.h	Fri Aug 17 14:47:30 2007 -0400
+++ b/xen/include/asm-x86/msr.h	Fri Aug 17 14:47:32 2007 -0400
@@ -117,6 +117,7 @@ static inline void wrmsrl(unsigned int m
 #define MSR_IA32_VMX_CR0_FIXED1                 0x487
 #define MSR_IA32_VMX_CR4_FIXED0                 0x488
 #define MSR_IA32_VMX_CR4_FIXED1                 0x489
+#define MSR_IA32_VMX_PROCBASED_CTLS2            0x48b
 #define IA32_FEATURE_CONTROL_MSR                0x3a
 #define IA32_FEATURE_CONTROL_MSR_LOCK           0x1
 #define IA32_FEATURE_CONTROL_MSR_ENABLE_VMXON   0x4

[-- Attachment #5: Type: text/plain, Size: 138 bytes --]

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

Re: Xen 3.1.1 -- initial patchqueue

[Alex Williamson]

[-- Attachment #1: Type: text/plain, Size: 3650 bytes --]

On Mon, 2007-09-10 at 09:56 +0100, Keir Fraser wrote:
> Hi,
> 
> A provisional patchqueue for Xen 3.1.1 is available at
> http://xenbits.xensource.com/xen-3.1-testing.pq.hg. This pq partners with
> http://xenbits.xensource.com/xen-3.1-testing.hg.
> 
> Please kick this pq around and check whether the patches you want to see in
> 3.1.1 are included.

Hi Keir,

   Here's a proposed list of patches for ia64:

Must have fixes:

http://xenbits.xensource.com/xen-unstable.hg?rev/51f5bea7b0d8
15348:51f5bea7b0d8 - adds free_irq(), necessary for build

http://xenbits.xensource.com/xen-unstable.hg?rev/b46c2ff6dfb0
15331:b46c2ff6dfb0 - fixes boot on NUMA systems

http://xenbits.xensource.com/xen-unstable.hg?rev/f536eb8576ee
15579:f536eb8576ee - fix VTI domain shutdown

http://xenbits.xensource.com/xen-unstable.hg?rev/d4f59e652078
15096:d4f59e652078 - fix pcifront with CONFIG_NUMA

http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/1483ef74511b
linux/56:1483ef74511b - update for acm interface changes

http://lists.xensource.com/archives/html/xen-ia64-devel/2006-11/msg00358.html
ia64-sal-get-state-info - Avoid GFP_KERNEL allocation from interrupt
context.  This was only recently fixed in upstream and is dependent on
other patches.  This is the simple fix proposed on the mailing list.
Patch attached.

These are all related to working out bugs and save location for NVRAM
support (must have):

http://xenbits.xensource.com/xen-unstable.hg?rev/71377eab1874
15349:71377eab1874 - white space cleanup - necessary for subsequent
patches

http://xenbits.xensource.com/xen-unstable.hg?rev/634b7f7f8584
*15265:634b7f7f8584 - allow domu nvram saving to fail gracefully

http://xenbits.xensource.com/xen-unstable.hg?rev/1623f5f5094f
15364:1623f5f5094f - don't save NVRAM on PV guests

http://xenbits.xensource.com/xen-unstable.hg?rev/33cc64dcaead
15365:33cc64dcaead - create NVRAM save directory

http://xenbits.xensource.com/xen-unstable.hg?rev/fd0103b55504
15366:fd0103b55504 - error checking for creat NVRAM save directory

http://xenbits.xensource.com/xen-unstable.hg?rev/38d061886873
15555:38d061886873 - avoid saving garbage to NVRAM on config error

http://xenbits.xensource.com/xen-unstable.hg?rev/2a5b463f2e8d
15557:2a5b463f2e8d - fix NVRAM save on reboot

http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?rev/6644d8486266
ia64/15762:6644d8486266 - cleanup NVRAM failure case

http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?rev/f88eea67a469
*ia64/15764:f88eea67a469 - move NVRAM from /usr to /var

These add the PCI Controller backend (high want - driver domains on some
systems won't work without this):

http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/93a955c2bebb
linux/46:93a955c2bebb - introduces controller backend

http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/a62cfa35d3b5
*linux/55:a62cfa35d3b5 - add hypercall to register i/o spaces

http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/452c5d4a5537
*linux/61:452c5d4a5537 - enable controller as default PCI backend

http://xenbits.xensource.com/xen-unstable.hg?rev/601509daabfc
*15353:601509daabfc - xen side support for multiple i/o spaces

Patches with an asterisk above require some modification to apply (white
space/file location/invalid chunks).  I've attached the modified
versions below.  Also note that 15265 is intentionally applied after
15349 above.  There's some screwiness around a merge for these and it
was easier to modify the white space in the smaller one and apply it
later.

   Other ia64'ers, please speak up if there's something else missing.
Thanks,

	Alex


-- 
Alex Williamson                             HP Open Source & Linux Org.

[-- Attachment #2: 15265-634b7f7f8584-mod --]
[-- Type: text/plain, Size: 1719 bytes --]

# HG changeset patch
# User kfraser@localhost.localdomain
# Date 1181644323 -3600
# Node ID 634b7f7f8584f478c9e45a98998c7e7c1b8e3b3d
# Parent  e1c54c14220a4d4ab38d8a3d409ab678275a5426
[IA64] When a domU is destroyed, it will fall into NVRAM saving
path. But if there is no NVRAM file for the domU, the save operation
would fail. Then domU blocked by Xend's exception. This patch fixs
that issue.

Signed-off-by: Zhang Xin <xing.z.zhang@intel.com>

diff -r e1c54c14220a -r 634b7f7f8584 tools/libxc/ia64/xc_ia64_hvm_build.c
--- a/tools/libxc/ia64/xc_ia64_hvm_build.c	Tue Jun 12 11:29:27 2007 +0100
+++ b/tools/libxc/ia64/xc_ia64_hvm_build.c	Tue Jun 12 11:32:03 2007 +0100
@@ -712,11 +712,15 @@ int xc_ia64_save_to_nvram(int xc_handle,
     xc_get_hvm_param(xc_handle, dom, HVM_PARAM_NVRAM_FD, &nvram_fd);
 
     if ( !IS_VALID_NVRAM_FD(nvram_fd) )
-    {
         PERROR("Nvram not be initialized. Nvram save fail!\n");
-        return -1;
-    }
-    return copy_from_GFW_to_nvram(xc_handle, dom, (int)nvram_fd);	
+    else
+        copy_from_GFW_to_nvram(xc_handle, dom, (int)nvram_fd);	
+
+    // although save to nvram maybe fail, we don't return any error number
+    // to Xend. This is quite logical because damage of NVRAM on native would 
+    // not block OS's executive path. Return error number will cause an exception 
+    // of Xend and block XenU when it destroy.
+    return 0;
 }
 
 #define NVRAM_FILE_PATH	"/usr/lib/xen/boot/nvram_"
@@ -862,7 +866,10 @@ setup_guest(int xc_handle, uint32_t dom,
 		nvram_start = 0;
 	else
 		if ( copy_from_nvram_to_GFW(xc_handle, dom, (int)nvram_fd ) == -1 )
+		{
 			nvram_start = 0;
+			close(nvram_fd);
+		}
 
     vcpus = domctl.u.getdomaininfo.max_vcpu_id + 1;
 

[-- Attachment #3: ia64-15764-f88eea67a469-mod --]
[-- Type: text/plain, Size: 3569 bytes --]

# HG changeset patch
# User Alex Williamson <alex.williamson@hp.com>
# Date 1188325537 21600
# Node ID f88eea67a46997c79b56e5ba595f0572584d9d51
# Parent  c21bd325088a2161206bb0ae03ebf4a5bee5569e
[IA64] Move nvram from /usr to /var

Presently nvram is stored in /usr/lib/xen/boot/nvram_<domain> next to the guest
firmware.  This violates the FHS because /usr might be mounted read-only.  This
patch moves the nvram storage to /var/lib/xen/nvram/nvram_<domain>

Also clean up:
- references to stat_buf assumed that stat() had succeeded; use access()
  instead since it's easier and doesn't require stat_buf at all
- nvram_path[PATH_MAX] instead of nvram_path[100]
- strncpy(..., strlen(src)) is meaningless, re-order length tests to work
  correctly

Signed-off-by: Aron Griffis <aron@hp.com>

diff -r c21bd325088a -r f88eea67a469 tools/libxc/ia64/xc_ia64_hvm_build.c
--- a/tools/libxc/ia64/xc_ia64_hvm_build.c	Tue Aug 28 12:24:27 2007 -0600
+++ b/tools/libxc/ia64/xc_ia64_hvm_build.c	Tue Aug 28 12:25:37 2007 -0600
@@ -5,6 +5,7 @@
 #include "xc_elf.h"
 #include "xc_efi.h"
 #include <stdlib.h>
+#include <unistd.h>
 #include <zlib.h>
 #include "xen/arch-ia64.h"
 #include <xen/hvm/ioreq.h>
@@ -596,7 +597,7 @@ copy_from_nvram_to_GFW(int xc_handle, ui
     unsigned int nr_pages = NVRAM_SIZE >> PAGE_SHIFT;
     struct stat file_stat;
     char buf[NVRAM_SIZE] = {0};
-	
+
     if ( fstat(nvram_fd, &file_stat) < 0 )
     {
         PERROR("Cannot get Nvram file info! Guest will boot without "
@@ -759,43 +760,41 @@ int xc_ia64_save_to_nvram(int xc_handle,
     return 0;
 }
 
-#define NVRAM_DIR       "/usr/lib/xen/boot/"
-#define NVRAM_FILE_PATH "/usr/lib/xen/boot/nvram_"
+#define NVRAM_DIR         "/var/lib/xen/nvram/"
+#define NVRAM_FILE_PREFIX "nvram_"
 
 int xc_ia64_nvram_init(int xc_handle, char *dom_name, uint32_t dom)
 {
-    int file_path_len = strlen(NVRAM_FILE_PATH);
-    uint64_t nvram_fd = 0;
-    char nvram_path[100] = {0};
-    struct stat stat_buf;
-
-    if ( stat(NVRAM_DIR, &stat_buf) == -1 ) {
+    uint64_t nvram_fd;
+    char nvram_path[PATH_MAX] = NVRAM_DIR;
+
+    if ( access(nvram_path, R_OK|W_OK|X_OK) == -1 ) {
         if ( errno != ENOENT )
         {
-            PERROR("Error stat'ing NVRAM dir %s.", NVRAM_DIR);
+            PERROR("Error stat'ing NVRAM dir %s.", nvram_path);
             return -1;
         }
-        if ( mkdir(NVRAM_DIR, 0755) == -1 )
+        if ( mkdir(nvram_path, 0755) == -1 )
         {
-            PERROR("Unable to create NVRAM store directory %s.", NVRAM_DIR);
+            PERROR("Unable to create NVRAM store directory %s.", nvram_path);
             return -1;
         }
     }
 
-    if ( !(stat_buf.st_mode & S_IRUSR) || !(stat_buf.st_mode & S_IWUSR) )
-    {
+    if ( access(nvram_path, R_OK|W_OK|X_OK) == -1 ) {
         errno = EACCES;
-        PERROR("No R/W permission to NVRAM store directory %s.", NVRAM_DIR);
-        return -1;
-    }
-
-    strncpy(nvram_path, NVRAM_FILE_PATH, file_path_len);
-    if ( file_path_len + strlen(dom_name) + 1 > sizeof(nvram_path) )
+        PERROR("No RWX permission to NVRAM store directory %s.", nvram_path);
+        return -1;
+    }
+
+    if ( strlen(nvram_path) + strlen(NVRAM_FILE_PREFIX) +
+         strlen(dom_name) + 1 > sizeof(nvram_path) )
     {
         PERROR("Nvram file path is too long!\n");
         return -1;
     }
-    strcpy(nvram_path + file_path_len, dom_name);
+    strcat(nvram_path, NVRAM_FILE_PREFIX);
+    strcat(nvram_path, dom_name);
 
     nvram_fd = nvram_init(nvram_path);
     if ( nvram_fd == (uint64_t)(-1) )

[-- Attachment #4: linux-55-a62cfa35d3b5-mod --]
[-- Type: text/plain, Size: 2082 bytes --]

# HG changeset patch
# User Alex Williamson <alex.williamson@hp.com>
# Date 1181684903 21600
# Node ID a62cfa35d3b504d5ee1acd4a409a6fb3ee45a6bd
# Parent  bab3dd910801edf8763d55e0c8133bc08d1cbcfd
[IA64] Add HYPERVISOR_add_io_space

And call it to register new I/O spaces with Xen

Signed-off-by: Alex Williamson <alex.williamson@hp.com>

diff -r bab3dd910801 -r a62cfa35d3b5 arch/ia64/pci/pci.c
--- a/linux-2.6-xen-sparse/arch/ia64/pci/pci.c	Tue Jun 12 15:43:27 2007 -0600
+++ b/linux-2.6-xen-sparse/arch/ia64/pci/pci.c	Tue Jun 12 15:48:23 2007 -0600
@@ -164,6 +164,11 @@ new_space (u64 phys_base, int sparse)
 	i = num_io_spaces++;
 	io_space[i].mmio_base = mmio_base;
 	io_space[i].sparse = sparse;
+
+#ifdef CONFIG_XEN
+	if (is_initial_xendomain())
+		HYPERVISOR_add_io_space(phys_base, sparse, i);
+#endif
 
 	return i;
 }
diff -r bab3dd910801 -r a62cfa35d3b5 include/asm-ia64/hypercall.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/hypercall.h	Tue Jun 12 15:43:27 2007 -0600
+++ b/linux-2.6-xen-sparse/include/asm-ia64/hypercall.h	Tue Jun 12 15:48:23 2007 -0600
@@ -387,6 +387,15 @@ xencomm_arch_hypercall_perfmon_op(un
 {
 	return _hypercall4(int, ia64_dom0vp_op,
 			   IA64_DOM0VP_perfmon, cmd, arg, count);
+}
+
+static inline int
+HYPERVISOR_add_io_space(unsigned long phys_base,
+			unsigned long sparse,
+			unsigned long space_number)
+{
+	return _hypercall4(int, ia64_dom0vp_op, IA64_DOM0VP_add_io_space,
+			   phys_base, sparse, space_number);
 }
 
 // for balloon driver
diff -r bab3dd910801 -r a62cfa35d3b5 include/xen/interface/arch-ia64.h
--- a/xen/include/public/arch-ia64.h	Tue Jun 12 15:43:27 2007 -0600
+++ b/xen/include/public/arch-ia64.h	Tue Jun 12 15:48:23 2007 -0600
@@ -531,6 +531,9 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_conte
 /* get fpswa revision */
 #define IA64_DOM0VP_fpswa_revision      10
 
+/* Add an I/O port space range */
+#define IA64_DOM0VP_add_io_space        11
+
 // flags for page assignement to pseudo physical address space
 #define _ASSIGN_readonly                0
 #define ASSIGN_readonly                 (1UL << _ASSIGN_readonly)

[-- Attachment #5: linux-61-452c5d4a5537-mod --]
[-- Type: text/plain, Size: 1523 bytes --]

# HG changeset patch
# User Alex Williamson <alex.williamson@hp.com>
# Date 1181920189 21600
# Node ID 452c5d4a55370c3c3a6cb6740b45be911ca3741e
# Parent  b492ac038d613212da3ee16646168b56ef8833cc
[IA64] Default to Controller PCI backend

Signed-off-by: Alex Williamson <alex.williamson@hp.com>

diff -r b492ac038d61 -r 452c5d4a5537 buildconfigs/linux-defconfig_xen0_ia64
--- a/buildconfigs/linux-defconfig_xen0_ia64	Thu Jun 14 14:23:21 2007 -0600
+++ b/buildconfigs/linux-defconfig_xen0_ia64	Fri Jun 15 09:09:49 2007 -0600
@@ -1666,7 +1666,8 @@ CONFIG_XEN_PCIDEV_BACKEND=y
 CONFIG_XEN_PCIDEV_BACKEND=y
 # CONFIG_XEN_PCIDEV_BACKEND_VPCI is not set
 # CONFIG_XEN_PCIDEV_BACKEND_PASS is not set
-CONFIG_XEN_PCIDEV_BACKEND_SLOT=y
+# CONFIG_XEN_PCIDEV_BACKEND_SLOT is not set
+CONFIG_XEN_PCIDEV_BACKEND_CONTROLLER=y
 # CONFIG_XEN_PCIDEV_BE_DEBUG is not set
 CONFIG_XEN_TPMDEV_BACKEND=m
 CONFIG_XEN_BLKDEV_FRONTEND=y
diff -r b492ac038d61 -r 452c5d4a5537 buildconfigs/linux-defconfig_xen_ia64
--- a/buildconfigs/linux-defconfig_xen_ia64	Thu Jun 14 14:23:21 2007 -0600
+++ b/buildconfigs/linux-defconfig_xen_ia64	Fri Jun 15 09:09:49 2007 -0600
@@ -1666,7 +1666,8 @@ CONFIG_XEN_PCIDEV_BACKEND=y
 CONFIG_XEN_PCIDEV_BACKEND=y
 # CONFIG_XEN_PCIDEV_BACKEND_VPCI is not set
 # CONFIG_XEN_PCIDEV_BACKEND_PASS is not set
-CONFIG_XEN_PCIDEV_BACKEND_SLOT=y
+# CONFIG_XEN_PCIDEV_BACKEND_SLOT is not set
+CONFIG_XEN_PCIDEV_BACKEND_CONTROLLER=y
 # CONFIG_XEN_PCIDEV_BE_DEBUG is not set
 CONFIG_XEN_TPMDEV_BACKEND=m
 CONFIG_XEN_BLKDEV_FRONTEND=y

[-- Attachment #6: 15353-601509daabfc-mod --]
[-- Type: text/plain, Size: 10692 bytes --]

# HG changeset patch
# User Alex Williamson <alex.williamson@hp.com>
# Date 1181682425 21600
# Node ID 601509daabfc0f33bae7cc5c07ef620b41c4a7a0
# Parent  ba1f933f2382c95b9d735215f608ad3aa85eec4d
[IA64] Support for multiple I/O port spaces

Linux has support for multiple I/O port spaces on a system.  Depending
on the system configuration, this might allow for 64k of I/O port space
per PCI bus.  The "extended" I/O port ranges are described to the OS by
_CRS methods on PCI root devices in ACPI namespace.  For instance, on my
system, /proc/iomem shows several entries like these:

80000000000-80003ffffff : PCI Bus 0000:00 I/O Ports 01000000-0100ffff
80100000000-80103ffffff : PCI Bus 0000:01 I/O Ports 02000000-0200ffff
80200000000-80203ffffff : PCI Bus 0000:0a I/O Ports 03000000-0300ffff
80300000000-80303ffffff : PCI Bus 0000:0f I/O Ports 04000000-0400ffff
...

These describe MMIO ranges that provide I/O port ranges per PCI bus.
My /proc/ioports then shows entries like these:

01000000-0100ffff : PCI Bus 0000:00
  01001000-010010ff : 0000:00:04.0
02000000-0200ffff : PCI Bus 0000:01
  02001000-02001fff : PCI Bus #02
    02001000-0200107f : 0000:02:07.0
      02001000-0200107f : tulip
    02001080-020010ff : 0000:02:06.0
      02001080-020010ff : tulip
    02001100-0200117f : 0000:02:05.0
    02001180-020011ff : 0000:02:04.0
      02001180-020011ff : tulip
  02002000-0200203f : 0000:01:02.1
  02002040-0200207f : 0000:01:02.0
    02002040-0200207f : e1000
03000000-0300ffff : PCI Bus 0000:0a
...

Xen currently has no concept of these extended I/O port space ranges and
prevents dom0 from doing the MMIO transactions required to access these
ports.  This patch solves the problem.  First we need to make
ioports_permit/deny_access() aware that multiple I/O port ranges with
different MMIO base address exist.  Next we need to provide a mechanism
to register new I/O port spaces, for this I've created the dom0vp op
IA64_DOM0VP_add_io_space.  This allows dom0 to do the work of finding
the ranges in ACPI namespace since we don't want to add that kind of
bulk to Xen.  Finally, dom0 needs to make use of this interface when new
ranges are found.

Signed-off-by: Alex Williamson <alex.williamson@hp.com>

diff -r ba1f933f2382 -r 601509daabfc xen/arch/ia64/xen/dom0_ops.c
--- a/xen/arch/ia64/xen/dom0_ops.c	Tue Jun 12 14:58:39 2007 -0600
+++ b/xen/arch/ia64/xen/dom0_ops.c	Tue Jun 12 15:07:05 2007 -0600
@@ -363,6 +363,40 @@ dom0vp_fpswa_revision(XEN_GUEST_HANDLE(u
     return 0;
 }
 
+static unsigned long
+dom0vp_add_io_space(struct domain *d, unsigned long phys_base,
+                    unsigned long sparse, unsigned long space_number)
+{
+    unsigned int fp, lp;
+
+    /*
+     * Registering new io_space roughly based on linux
+     * arch/ia64/pci/pci.c:new_space()
+     */
+
+    /* Skip legacy I/O port space, we already know about it */
+    if (phys_base == 0)
+        return 0;
+
+    /*
+     * Dom0 Linux initializes io spaces sequentially, if that changes,
+     * we'll need to add thread protection and the ability to handle
+     * a sparsely populated io_space array.
+     */
+    if (space_number > MAX_IO_SPACES || space_number != num_io_spaces)
+        return -EINVAL;
+
+    io_space[space_number].mmio_base = phys_base;
+    io_space[space_number].sparse = sparse;
+
+    num_io_spaces++;
+
+    fp = space_number << IO_SPACE_BITS;
+    lp = fp | 0xffff;
+
+    return ioports_permit_access(d, fp, lp);
+}
+
 unsigned long
 do_dom0vp_op(unsigned long cmd,
              unsigned long arg0, unsigned long arg1, unsigned long arg2,
@@ -419,6 +453,9 @@ do_dom0vp_op(unsigned long cmd,
         ret = dom0vp_fpswa_revision(hnd);
         break;
     }
+    case IA64_DOM0VP_add_io_space:
+        ret = dom0vp_add_io_space(d, arg0, arg1, arg2);
+        break;
     default:
         ret = -1;
 		printk("unknown dom0_vp_op 0x%lx\n", cmd);
diff -r ba1f933f2382 -r 601509daabfc xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.c	Tue Jun 12 14:58:39 2007 -0600
+++ b/xen/arch/ia64/xen/mm.c	Tue Jun 12 15:07:05 2007 -0600
@@ -890,81 +890,144 @@ assign_domain_page(struct domain *d,
 }
 
 int
-ioports_permit_access(struct domain *d, unsigned long fp, unsigned long lp)
-{
+ioports_permit_access(struct domain *d, unsigned int fp, unsigned int lp)
+{
+    struct io_space *space;
+    unsigned long mmio_start, mmio_end, mach_start;
     int ret;
-    unsigned long off;
-    unsigned long fp_offset;
-    unsigned long lp_offset;
-
+
+    if (IO_SPACE_NR(fp) >= num_io_spaces) {
+        dprintk(XENLOG_WARNING, "Unknown I/O Port range 0x%x - 0x%x\n", fp, lp);
+        return -EFAULT;
+    }
+
+    /*
+     * The ioport_cap rangeset tracks the I/O port address including
+     * the port space ID.  This means port space IDs need to match
+     * between Xen and dom0.  This is also a requirement because
+     * the hypercall to pass these port ranges only uses a u32.
+     *
+     * NB - non-dom0 driver domains may only have a subset of the
+     * I/O port spaces and thus will number port spaces differently.
+     * This is ok, they don't make use of this interface.
+     */
     ret = rangeset_add_range(d->arch.ioport_caps, fp, lp);
     if (ret != 0)
         return ret;
 
-    /* Domain 0 doesn't virtualize IO ports space. */
-    if (d == dom0)
+    space = &io_space[IO_SPACE_NR(fp)];
+
+    /* Legacy I/O on dom0 is already setup */
+    if (d == dom0 && space == &io_space[0])
         return 0;
 
-    fp_offset = IO_SPACE_SPARSE_ENCODING(fp) & ~PAGE_MASK;
-    lp_offset = PAGE_ALIGN(IO_SPACE_SPARSE_ENCODING(lp));
-
-    for (off = fp_offset; off <= lp_offset; off += PAGE_SIZE)
-        (void)__assign_domain_page(d, IO_PORTS_PADDR + off,
-                                   __pa(ia64_iobase) + off, ASSIGN_nocache);
+    fp = IO_SPACE_PORT(fp);
+    lp = IO_SPACE_PORT(lp);
+
+    if (space->sparse) {
+        mmio_start = IO_SPACE_SPARSE_ENCODING(fp) & ~PAGE_MASK;
+        mmio_end = PAGE_ALIGN(IO_SPACE_SPARSE_ENCODING(lp));
+    } else {
+        mmio_start = fp & ~PAGE_MASK;
+        mmio_end = PAGE_ALIGN(lp);
+    }
+
+    /*
+     * The "machine first port" is not necessarily identity mapped
+     * to the guest first port.  At least for the legacy range.
+     */
+    mach_start = mmio_start | __pa(space->mmio_base);
+
+    if (space == &io_space[0]) {
+        mmio_start |= IO_PORTS_PADDR;
+        mmio_end |= IO_PORTS_PADDR;
+    } else {
+        mmio_start |= __pa(space->mmio_base);
+        mmio_end |= __pa(space->mmio_base);
+    }
+
+    while (mmio_start <= mmio_end) {
+        (void)__assign_domain_page(d, mmio_start, mach_start, ASSIGN_nocache); 
+        mmio_start += PAGE_SIZE;
+        mach_start += PAGE_SIZE;
+    }
 
     return 0;
 }
 
 static int
-ioports_has_allowed(struct domain *d, unsigned long fp, unsigned long lp)
-{
-    unsigned long i;
-    for (i = fp; i < lp; i++)
-        if (rangeset_contains_singleton(d->arch.ioport_caps, i))
+ioports_has_allowed(struct domain *d, unsigned int fp, unsigned int lp)
+{
+    for (; fp < lp; fp++)
+        if (rangeset_contains_singleton(d->arch.ioport_caps, fp))
             return 1;
+
     return 0;
 }
 
 int
-ioports_deny_access(struct domain *d, unsigned long fp, unsigned long lp)
+ioports_deny_access(struct domain *d, unsigned int fp, unsigned int lp)
 {
     int ret;
     struct mm_struct *mm = &d->arch.mm;
-    unsigned long off;
-    unsigned long io_ports_base;
-    unsigned long fp_offset;
-    unsigned long lp_offset;
+    unsigned long mmio_start, mmio_end, mmio_base;
+    unsigned int fp_base, lp_base;
+    struct io_space *space;
+
+    if (IO_SPACE_NR(fp) >= num_io_spaces) {
+        dprintk(XENLOG_WARNING, "Unknown I/O Port range 0x%x - 0x%x\n", fp, lp);
+        return -EFAULT;
+    }
 
     ret = rangeset_remove_range(d->arch.ioport_caps, fp, lp);
     if (ret != 0)
         return ret;
-    if (d == dom0)
-        io_ports_base = __pa(ia64_iobase);
+
+    space = &io_space[IO_SPACE_NR(fp)];
+    fp_base = IO_SPACE_PORT(fp);
+    lp_base = IO_SPACE_PORT(lp);
+
+    if (space->sparse) {
+        mmio_start = IO_SPACE_SPARSE_ENCODING(fp_base) & ~PAGE_MASK;
+        mmio_end = PAGE_ALIGN(IO_SPACE_SPARSE_ENCODING(lp_base));
+    } else {
+        mmio_start = fp_base & ~PAGE_MASK;
+        mmio_end = PAGE_ALIGN(lp_base);
+    }
+
+    if (space == &io_space[0] && d != dom0)
+        mmio_base = IO_PORTS_PADDR;
     else
-        io_ports_base = IO_PORTS_PADDR;
-
-    fp_offset = IO_SPACE_SPARSE_ENCODING(fp) & PAGE_MASK;
-    lp_offset = PAGE_ALIGN(IO_SPACE_SPARSE_ENCODING(lp));
-
-    for (off = fp_offset; off < lp_offset; off += PAGE_SIZE) {
-        unsigned long mpaddr = io_ports_base + off;
-        unsigned long port;
+        mmio_base = __pa(space->mmio_base);
+
+    for (; mmio_start < mmio_end; mmio_start += PAGE_SIZE) {
+        unsigned int port, range;
+        unsigned long mpaddr;
         volatile pte_t *pte;
         pte_t old_pte;
 
-        port = IO_SPACE_SPARSE_DECODING (off);
-        if (port < fp || port + IO_SPACE_SPARSE_PORTS_PER_PAGE - 1 > lp) {
+        if (space->sparse) {
+            port = IO_SPACE_SPARSE_DECODING(mmio_start);
+            range = IO_SPACE_SPARSE_PORTS_PER_PAGE - 1;
+        } else {
+            port = mmio_start;
+            range = PAGE_SIZE - 1;
+        }
+
+        port |= IO_SPACE_BASE(IO_SPACE_NR(fp));
+
+        if (port < fp || port + range > lp) {
             /* Maybe this covers an allowed port.  */
-            if (ioports_has_allowed(d, port,
-                                    port + IO_SPACE_SPARSE_PORTS_PER_PAGE - 1))
+            if (ioports_has_allowed(d, port, port + range))
                 continue;
         }
 
+        mpaddr = mmio_start | mmio_base;
         pte = lookup_noalloc_domain_pte_none(d, mpaddr);
         BUG_ON(pte == NULL);
         BUG_ON(pte_none(*pte));
 
-        // clear pte
+        /* clear pte */
         old_pte = ptep_get_and_clear(mm, mpaddr, pte);
     }
     domain_flush_vtlb_all(d);
diff -r ba1f933f2382 -r 601509daabfc xen/include/asm-ia64/iocap.h
--- a/xen/include/asm-ia64/iocap.h	Tue Jun 12 14:58:39 2007 -0600
+++ b/xen/include/asm-ia64/iocap.h	Tue Jun 12 15:07:05 2007 -0600
@@ -8,9 +8,9 @@
 #define __IA64_IOCAP_H__
 
 extern int ioports_permit_access(struct domain *d,
-                                 unsigned long s, unsigned long e);
+				 unsigned int s, unsigned int e);
 extern int ioports_deny_access(struct domain *d,
-                               unsigned long s, unsigned long e);
+			       unsigned int s, unsigned int e);
 
 #define ioports_access_permitted(d, s, e)               \
     rangeset_contains_range((d)->arch.ioport_caps, s, e)

[-- Attachment #7: ia64-sal-get-state-info --]
[-- Type: text/plain, Size: 707 bytes --]

[IA64] Use GFP_ATOMIC for ia64_sal_get_state_info()

This can be called in interrupt context.

Signed-off-by: Kazuhiro Suzuki <kaz@jp.fujitsu.com>
---

diff -r 9ac03e8238f6 linux-2.6-xen-sparse/include/asm-ia64/sal.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/sal.h	Fri Sep 07 10:19:22 2007 +0100
+++ b/linux-2.6-xen-sparse/include/asm-ia64/sal.h	Mon Sep 10 12:59:48 2007 -0600
@@ -703,7 +703,7 @@ ia64_sal_get_state_info (u64 sal_info_ty
 
 		if (xencomm_create(sal_info,
 		                   ia64_sal_get_state_info_size(sal_info_type),
-		                   &desc, GFP_KERNEL))
+		                   &desc, GFP_ATOMIC))
 			return 0;
 
 		SAL_CALL_REENTRANT(isrv, SAL_GET_STATE_INFO, sal_info_type, 0,

[-- Attachment #8: Type: text/plain, Size: 138 bytes --]

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

Re: Xen 3.1.1 -- initial patchqueue

[Alex Williamson]

   Updated cset numbers now that all the ia64 patches are merged into
mainline...

On Mon, 2007-09-10 at 13:18 -0600, Alex Williamson wrote:
> http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?rev/6644d8486266
> ia64/15762:6644d8486266 - cleanup NVRAM failure case

Now
http://xenbits.xensource.com/staging/xen-unstable.hg?rev/6644d8486266
15850:6644d8486266

> http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?rev/f88eea67a469
> *ia64/15764:f88eea67a469 - move NVRAM from /usr to /var

Now
http://xenbits.xensource.com/staging/xen-unstable.hg?rev/f88eea67a469
15852:f88eea67a469 (but you'll still need to use the modified version
attached previously)

Thanks,

	Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.

Re: Xen 3.1.1 -- initial patchqueue

[Keir Fraser]

Can you please provide a patch to apply to xen-3.1-testing.pq.hg? The
patches you add to the queue should have the same style of changeset comment
as the existing ones -- 'hg export' format plus the two xen-unstable
changeset references immediately after the signed-off-by line(s).

I've cc'ed Ben Guthro since he also has proposed a few patches, and I'd like
to receive a patch from him for those too. Including 15185, since I changed
my mind on that one! Fix the odd characters in changeset comments at the
same time, if they're still causing you problems.

 Thanks,
 Keir

On 11/9/07 16:15, "Alex Williamson" <alex.williamson@hp.com> wrote:

> 
>    Updated cset numbers now that all the ia64 patches are merged into
> mainline...
> 
> On Mon, 2007-09-10 at 13:18 -0600, Alex Williamson wrote:
>> http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?rev/6644d8486266
>> ia64/15762:6644d8486266 - cleanup NVRAM failure case
> 
> Now
> http://xenbits.xensource.com/staging/xen-unstable.hg?rev/6644d8486266
> 15850:6644d8486266
> 
>> http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?rev/f88eea67a469
>> *ia64/15764:f88eea67a469 - move NVRAM from /usr to /var
> 
> Now
> http://xenbits.xensource.com/staging/xen-unstable.hg?rev/f88eea67a469
> 15852:f88eea67a469 (but you'll still need to use the modified version
> attached previously)
> 
> Thanks,
> 
> Alex

[PATCH] Re: Xen 3.1.1 -- initial patchqueue

[Alex Williamson]

[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]

On Tue, 2007-09-11 at 18:43 +0100, Keir Fraser wrote:
> Can you please provide a patch to apply to xen-3.1-testing.pq.hg? The
> patches you add to the queue should have the same style of changeset comment
> as the existing ones -- 'hg export' format plus the two xen-unstable
> changeset references immediately after the signed-off-by line(s).

   Here you go.  I went ahead and fixed the odd character problem in
this patch since it was getting in my way too.  Thanks,

	Alex

Xen-3.1.1 patches for ia64
  - build fixes
  - NUMA system fixes
  - update for ACM interface
  - avoid allocating SAL logs w/ GFP_KERNEL
  - NVRAM fixes
  - PCI Controller backend
  - extended I/O port space support

Signed-off-by: Alex Williamson <alex.williamson@hp.com>
---

 15078-6145e5508d6b        |    2 
 b/15096-d4f59e652078      |   26 +
 b/15265-634b7f7f8584      |   48 ++
 b/15331-b46c2ff6dfb0      |   63 +++
 b/15348-51f5bea7b0d8      |   48 ++
 b/15349-71377eab1874      |  388 ++++++++++++++++++++++
 b/15353-601509daabfc      |  310 ++++++++++++++++++
 b/15364-1623f5f5094f      |   38 ++
 b/15365-33cc64dcaead      |   34 +
 b/15366-fd0103b55504      |   67 +++
 b/15555-38d061886873      |   73 ++++
 b/15557-2a5b463f2e8d      |   52 +++
 b/15579-f536eb8576ee      |   33 +
 b/15850-6644d8486266      |   31 +
 b/15852-f88eea67a469      |  104 ++++++
 b/ia64-sal-get-state-info |   19 +
 b/linux-46-93a955c2bebb   |  786 ++++++++++++++++++++++++++++++++++++++++++++++
 b/linux-55-a62cfa35d3b5   |   60 +++
 b/linux-56-1483ef74511b   |  101 +++++
 b/linux-61-452c5d4a5537   |   37 ++
 series                    |   19 +
 21 files changed, 2338 insertions(+), 1 deletion(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xen-3.1.1-ia64.pq.patch --]
[-- Type: text/x-patch; name=xen-3.1.1-ia64.pq.patch; charset=UTF-8, Size: 84781 bytes --]

diff -r 7ba52aa72ae5 15078-6145e5508d6b
--- a/15078-6145e5508d6b	Fri Sep 07 15:49:00 2007 +0100
+++ b/15078-6145e5508d6b	Tue Sep 11 11:54:34 2007 -0600
@@ -6,7 +6,7 @@ Xen-API.  This also serves as a good exa
 Xen-API.  This also serves as a good example of the use of XML::RPC::Client
 with the Xen-API.
 
-By Ingard Mevåg <ingard [at] mevaag [dot] no>.
+By Ingard Mevag <ingard [at] mevaag [dot] no>.
 
 Signed-off-by: Ewan Mellor <ewan@xensource.com>
 xen-unstable changeset: 15078:6145e5508d6b5ff188df250fb9c97e3e47762005
diff -r 7ba52aa72ae5 15096-d4f59e652078
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15096-d4f59e652078	Tue Sep 11 12:26:45 2007 -0600
@@ -0,0 +1,26 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1178548346 21600
+# Node ID d4f59e6520781a3f1d025e754d11992be68c309c
+# Parent  642a9bcaf19c63f12722a30d94de2ad2607d9d47
+[IA64] Fix PCI front with CONFIG_NUMA
+
+We get a bad pointer dereference if we don't fill something in
+here.  -1 will give us a global allocation, which is good enough
+until we have better NUMA support.
+
+Signed-off-by: Alex Williamson <alex.williamson@hp.com>
+xen-unstable changeset: 15096:d4f59e6520781a3f1d025e754d11992be68c309c
+xen-unstable date: Mon May 07 08:32:26 2007 -0600
+
+diff -r 642a9bcaf19c -r d4f59e652078 linux-2.6-xen-sparse/include/xen/pcifront.h
+--- a/linux-2.6-xen-sparse/include/xen/pcifront.h	Sun May 06 20:34:15 2007 -0600
++++ b/linux-2.6-xen-sparse/include/xen/pcifront.h	Mon May 07 08:32:26 2007 -0600
+@@ -62,6 +62,7 @@ static inline void pcifront_init_sd(stru
+ 	sd->segment = domain;
+ 	sd->acpi_handle = NULL;
+ 	sd->iommu = NULL;
++	sd->node = -1;
+ 	sd->windows = 0;
+ 	sd->window = NULL;
+ 	sd->platform_data = pdev;
diff -r 7ba52aa72ae5 15265-634b7f7f8584
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15265-634b7f7f8584	Tue Sep 11 12:27:10 2007 -0600
@@ -0,0 +1,48 @@
+# HG changeset patch
+# User kfraser@localhost.localdomain
+# Date 1181644323 -3600
+# Node ID 634b7f7f8584f478c9e45a98998c7e7c1b8e3b3d
+# Parent  e1c54c14220a4d4ab38d8a3d409ab678275a5426
+[IA64] When a domU is destroyed, it will fall into NVRAM saving
+path. But if there is no NVRAM file for the domU, the save operation
+would fail. Then domU blocked by Xend's exception. This patch fixs
+that issue.
+
+Signed-off-by: Zhang Xin <xing.z.zhang@intel.com>
+xen-unstable changeset: 15265:634b7f7f8584f478c9e45a98998c7e7c1b8e3b3d
+xen-unstable date: Tue Jun 12 11:32:03 2007 +0100
+
+diff -r e1c54c14220a -r 634b7f7f8584 tools/libxc/ia64/xc_ia64_hvm_build.c
+--- a/tools/libxc/ia64/xc_ia64_hvm_build.c	Tue Jun 12 11:29:27 2007 +0100
++++ b/tools/libxc/ia64/xc_ia64_hvm_build.c	Tue Jun 12 11:32:03 2007 +0100
+@@ -712,11 +712,15 @@ int xc_ia64_save_to_nvram(int xc_handle,
+     xc_get_hvm_param(xc_handle, dom, HVM_PARAM_NVRAM_FD, &nvram_fd);
+ 
+     if ( !IS_VALID_NVRAM_FD(nvram_fd) )
+-    {
+         PERROR("Nvram not be initialized. Nvram save fail!\n");
+-        return -1;
+-    }
+-    return copy_from_GFW_to_nvram(xc_handle, dom, (int)nvram_fd);	
++    else
++        copy_from_GFW_to_nvram(xc_handle, dom, (int)nvram_fd);	
++
++    // although save to nvram maybe fail, we don't return any error number
++    // to Xend. This is quite logical because damage of NVRAM on native would 
++    // not block OS's executive path. Return error number will cause an exception 
++    // of Xend and block XenU when it destroy.
++    return 0;
+ }
+ 
+ #define NVRAM_FILE_PATH	"/usr/lib/xen/boot/nvram_"
+@@ -862,7 +866,10 @@ setup_guest(int xc_handle, uint32_t dom,
+ 		nvram_start = 0;
+ 	else
+ 		if ( copy_from_nvram_to_GFW(xc_handle, dom, (int)nvram_fd ) == -1 )
++		{
+ 			nvram_start = 0;
++			close(nvram_fd);
++		}
+ 
+     vcpus = domctl.u.getdomaininfo.max_vcpu_id + 1;
+ 
diff -r 7ba52aa72ae5 15331-b46c2ff6dfb0
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15331-b46c2ff6dfb0	Tue Sep 11 12:27:33 2007 -0600
@@ -0,0 +1,63 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1180644428 21600
+# Node ID b46c2ff6dfb0de75e17fee01f0adc4d35d5e8322
+# Parent  148b6fc8f29b7b3de496e29f99afdd1e2cfb2bc4
+[IA64] Fix initialization order for buddy allocator
+
+Fix initialization order of buddy allocator to avoid panic
+on machines with multi NUMA node.
+
+Signed-off-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
+xen-unstable changeset: 15331:b46c2ff6dfb0de75e17fee01f0adc4d35d5e8322
+xen-unstable date: Thu May 31 14:47:08 2007 -0600
+
+diff -r 148b6fc8f29b -r b46c2ff6dfb0 xen/arch/ia64/linux-xen/setup.c
+--- a/xen/arch/ia64/linux-xen/setup.c	Thu May 31 11:42:40 2007 -0600
++++ b/xen/arch/ia64/linux-xen/setup.c	Thu May 31 14:47:08 2007 -0600
+@@ -506,13 +506,6 @@ setup_arch (char **cmdline_p)
+ 	if (early_console_setup(*cmdline_p) == 0)
+ 		mark_bsp_online();
+ 
+-#ifdef XEN
+-}
+-
+-void __init
+-late_setup_arch (char **cmdline_p)
+-{
+-#endif
+ #ifdef CONFIG_ACPI_BOOT
+ 	/* Initialize the ACPI boot-time table parser */
+ 	acpi_table_init();
+@@ -525,6 +518,13 @@ late_setup_arch (char **cmdline_p)
+ # endif
+ #endif /* CONFIG_APCI_BOOT */
+ 
++#ifdef XEN
++}
++
++void __init
++late_setup_arch (char **cmdline_p)
++{
++#endif
+ #ifndef XEN
+ 	find_memory();
+ #endif
+diff -r 148b6fc8f29b -r b46c2ff6dfb0 xen/arch/ia64/xen/xensetup.c
+--- a/xen/arch/ia64/xen/xensetup.c	Thu May 31 11:42:40 2007 -0600
++++ b/xen/arch/ia64/xen/xensetup.c	Thu May 31 14:47:08 2007 -0600
+@@ -433,12 +433,12 @@ void __init start_kernel(void)
+ 
+     alloc_dom0();
+ 
+-    end_boot_allocator();
+-
+     init_xenheap_pages(__pa(xen_heap_start), xenheap_phys_end);
+     printk("Xen heap: %luMB (%lukB)\n",
+ 	(xenheap_phys_end-__pa(xen_heap_start)) >> 20,
+ 	(xenheap_phys_end-__pa(xen_heap_start)) >> 10);
++
++    end_boot_allocator();
+ 
+     late_setup_arch(&cmdline);
+ 
diff -r 7ba52aa72ae5 15348-51f5bea7b0d8
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15348-51f5bea7b0d8	Tue Sep 11 12:27:55 2007 -0600
@@ -0,0 +1,48 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1181591988 21600
+# Node ID 51f5bea7b0d84d639a9823ddf1d27a71a869b6f4
+# Parent  154878b6ec4bf58fb3a9a6c6b420097b2f4a6f1e
+[IA64] create free_irq()
+
+This isn't well tested, since it's not likely to get called, but
+it is required to build.
+
+Signed-off-by: Alex Williamson <alex.williamson@hp.com>
+xen-unstable changeset: 15348:51f5bea7b0d84d639a9823ddf1d27a71a869b6f4
+xen-unstable date: Mon Jun 11 13:59:48 2007 -0600
+
+diff -r 154878b6ec4b -r 51f5bea7b0d8 xen/arch/ia64/xen/irq.c
+--- a/xen/arch/ia64/xen/irq.c	Mon Jun 11 13:46:42 2007 -0600
++++ b/xen/arch/ia64/xen/irq.c	Mon Jun 11 13:59:48 2007 -0600
+@@ -281,6 +281,30 @@ int setup_irq(unsigned int irq, struct i
+ 	return res;
+ }
+ 
++void free_irq(unsigned int irq)
++{
++	unsigned int vec;
++	unsigned long flags;
++	irq_desc_t *desc;
++
++	/* Get vector for IRQ.  */
++	if (acpi_gsi_to_irq(irq, &vec) < 0)
++		return;
++
++	desc = irq_descp(vec);
++
++	spin_lock_irqsave(&desc->lock, flags);
++	clear_bit(vec, ia64_xen_vector);
++	desc->action = NULL;
++	desc->depth = 1;
++	desc->status |= IRQ_DISABLED;
++	desc->handler->shutdown(vec);
++	spin_unlock_irqrestore(&desc->lock, flags);
++
++	while (desc->status & IRQ_INPROGRESS)
++		cpu_relax();
++}
++
+ /*
+  * HANDLING OF GUEST-BOUND PHYSICAL IRQS
+  */
diff -r 7ba52aa72ae5 15349-71377eab1874
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15349-71377eab1874	Tue Sep 11 12:28:11 2007 -0600
@@ -0,0 +1,388 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1181593145 21600
+# Node ID 71377eab1874e126caeb4c1869374befa07f1c70
+# Parent  51f5bea7b0d84d639a9823ddf1d27a71a869b6f4
+[IA64] White space cleanup from nvram patch
+
+This file is using space indenting.  No functional changes.
+
+Signed-off-by: Alex Williamson <alex.williamson@hp.com>
+xen-unstable changeset: 15349:71377eab1874e126caeb4c1869374befa07f1c70
+xen-unstable date: Mon Jun 11 14:19:05 2007 -0600
+
+diff -r 51f5bea7b0d8 -r 71377eab1874 tools/libxc/ia64/xc_ia64_hvm_build.c
+--- a/tools/libxc/ia64/xc_ia64_hvm_build.c	Mon Jun 11 13:59:48 2007 -0600
++++ b/tools/libxc/ia64/xc_ia64_hvm_build.c	Mon Jun 11 14:19:05 2007 -0600
+@@ -124,7 +124,7 @@ typedef enum {
+     HOB_TYPE_PAL_VM_INFO,
+     HOB_TYPE_PAL_VM_PAGE_SIZE,
+     HOB_TYPE_NR_VCPU,
+-	HOB_TYPE_NVRAM,
++    HOB_TYPE_NVRAM,
+     HOB_TYPE_MAX
+ } hob_type_t;
+ 
+@@ -135,14 +135,14 @@ static int add_nvram_hob(void* hob_buf, 
+ static int add_nvram_hob(void* hob_buf, unsigned long nvram_addr);
+ static int build_hob(void* hob_buf, unsigned long hob_buf_size,
+                      unsigned long dom_mem_size, unsigned long vcpus,
+-					 unsigned long nvram_addr);
++                     unsigned long nvram_addr);
+ static int load_hob(int xc_handle,uint32_t dom, void *hob_buf,
+                     unsigned long dom_mem_size);
+ 
+ static int
+ xc_ia64_build_hob(int xc_handle, uint32_t dom,
+                   unsigned long memsize, unsigned long vcpus,
+-				  unsigned long nvram_addr)
++                  unsigned long nvram_addr)
+ {
+     char   *hob_buf;
+ 
+@@ -251,7 +251,7 @@ static int
+ static int
+ build_hob(void* hob_buf, unsigned long hob_buf_size,
+           unsigned long dom_mem_size, unsigned long vcpus,
+-		  unsigned long nvram_addr)
++          unsigned long nvram_addr)
+ {
+     //Init HOB List
+     if (hob_init(hob_buf, hob_buf_size) < 0) {
+@@ -274,10 +274,10 @@ build_hob(void* hob_buf, unsigned long h
+         goto err_out;
+     }
+ 
+-	if (add_nvram_hob( hob_buf, nvram_addr ) < 0) {
+-		PERROR("Add nvram hob failed, buffer too small");
+-		goto err_out;
+-	}
++    if (add_nvram_hob( hob_buf, nvram_addr ) < 0) {
++        PERROR("Add nvram hob failed, buffer too small");
++        goto err_out;
++    }
+ 
+     return 0;
+ 
+@@ -342,7 +342,7 @@ static int
+ static int
+ add_nvram_hob(void *hob_buf, unsigned long nvram_addr)
+ {
+-	return hob_add(hob_buf, HOB_TYPE_NVRAM, &nvram_addr, sizeof(nvram_addr));
++    return hob_add(hob_buf, HOB_TYPE_NVRAM, &nvram_addr, sizeof(nvram_addr));
+ }
+ 
+ static const unsigned char config_pal_bus_get_features_data[24] = {
+@@ -576,49 +576,48 @@ static uint64_t
+ static uint64_t 
+ nvram_init(const char *nvram_path)
+ {
+-	uint64_t fd = 0;
+-	fd = open(nvram_path, O_CREAT|O_RDWR, 0666);
+-
+-	if ( fd < 0 )
+-	{
+-		PERROR("Nvram open failed at %s. Guest will boot without"
+-				" nvram support!\n", nvram_path);	
+-		return -1;
+-	}
+-
+-	return VALIDATE_NVRAM_FD(fd);
++    uint64_t fd = 0;
++    fd = open(nvram_path, O_CREAT|O_RDWR, 0666);
++
++    if ( fd < 0 )
++    {
++        PERROR("Nvram open failed at %s. Guest will boot without"
++               " nvram support!\n", nvram_path);	
++        return -1;
++    }
++
++    return VALIDATE_NVRAM_FD(fd);
+ }
+ 
+ static int 
+ copy_from_nvram_to_GFW(int xc_handle, uint32_t dom, int nvram_fd)
+ {
+-	unsigned int nr_pages = NVRAM_SIZE >> PAGE_SHIFT;
+-	struct stat file_stat;
+-	char buf[NVRAM_SIZE] = {0};
++    unsigned int nr_pages = NVRAM_SIZE >> PAGE_SHIFT;
++    struct stat file_stat;
++    char buf[NVRAM_SIZE] = {0};
+ 	
+-	if ( fstat(nvram_fd, &file_stat) < 0 )
+-	{
+-		PERROR("Cannot get Nvram file info! Guest will boot without "
+-			   "nvram support!\n");
+-		return -1;
+-	}
+-
+-	if ( 0 == file_stat.st_size )
+-	{
+-		DPRINTF("Nvram file create successful!\n");
+-		return 0;
+-	}
+-
+-	if ( read(nvram_fd, buf, NVRAM_SIZE) != NVRAM_SIZE )
+-	{
+-		PERROR("Load nvram fail. guest will boot without"
+-			   " nvram support!\n");
+-		return -1;
+-	}
+-
+-	return  xc_ia64_copy_to_domain_pages(xc_handle, dom, buf,
+-											NVRAM_START >> PAGE_SHIFT,
+-											nr_pages);
++    if ( fstat(nvram_fd, &file_stat) < 0 )
++    {
++        PERROR("Cannot get Nvram file info! Guest will boot without "
++               "nvram support!\n");
++        return -1;
++    }
++
++    if ( 0 == file_stat.st_size )
++    {
++        DPRINTF("Nvram file create successful!\n");
++        return 0;
++    }
++
++    if ( read(nvram_fd, buf, NVRAM_SIZE) != NVRAM_SIZE )
++    {
++        PERROR("Load nvram fail. guest will boot without"
++               " nvram support!\n");
++        return -1;
++    }
++
++    return  xc_ia64_copy_to_domain_pages(xc_handle, dom, buf,
++                                         NVRAM_START >> PAGE_SHIFT, nr_pages);
+ }
+ 
+ 
+@@ -630,121 +629,120 @@ static int
+ static int
+ copy_from_GFW_to_nvram(int xc_handle, uint32_t dom, int nvram_fd)
+ {
+-	xen_pfn_t *pfn_list = NULL;
+-	char *tmp_ptr = NULL;
+-	unsigned int nr_pages = 0;
+-	uint64_t addr_from_GFW_4k_align = 0;
+-	uint32_t offset = 0;
+-	uint64_t nvram_base_addr = 0;
+-	char buf[NVRAM_SIZE] = {0};
+-	int i;
+-
+-	
+-	// map one more page 
+-	nr_pages = (NVRAM_SIZE + PAGE_SIZE) >> PAGE_SHIFT;
+-	pfn_list = (xen_pfn_t *)malloc(sizeof(xen_pfn_t) * nr_pages);
+-	if ( NULL == pfn_list )
+-	{
+-		PERROR("Cannot allocate memory for nvram save!\n");
+-		close(nvram_fd);
+-		return -1;
+-	}
+-
+-	/* 
+-	 * GFW allocate memory dynamicly to save nvram data
+-	 * and save address of the dynamic memory at NVRAM_START. 
+-	 * To save nvram data to file, we must get the dynamic
+-	 * memory address first.
+-	 */
+-	pfn_list[0] = NVRAM_START >> PAGE_SHIFT;
+-	tmp_ptr = (char *)xc_map_foreign_range(xc_handle, dom, PAGE_SIZE,
+-			PROT_READ | PROT_WRITE, pfn_list[0]);
+-
+-	if ( NULL == tmp_ptr )
+-	{
+-		PERROR("Cannot get nvram data from GFW!\n");
+-		free(pfn_list);
+-		close(nvram_fd);
+-		return -1;
+-	}
+-
+-	addr_from_GFW_4k_align = *((uint64_t *)tmp_ptr);
+-	munmap(tmp_ptr, PAGE_SIZE);
+-
+-	// align address to 16k
+-	offset = addr_from_GFW_4k_align % ( 16 * MEM_K );
+-	addr_from_GFW_4k_align = addr_from_GFW_4k_align - offset;
+-	for ( i=0; i<nr_pages; i++ )
+-		pfn_list[i] = (addr_from_GFW_4k_align >> PAGE_SHIFT) + i;
+-
+-	tmp_ptr = (char *)xc_map_foreign_batch(xc_handle, dom,
+-						PROT_READ | PROT_WRITE, pfn_list, nr_pages);
+-	if ( NULL == tmp_ptr )
+-	{
+-		PERROR("Cannot get nvram data from GFW!\n");
+-		free(pfn_list);
+-		close(nvram_fd);
+-		return -1;
+-	}
+-
+-	// calculate nvram data base addrees
+-	nvram_base_addr = (uint64_t)(tmp_ptr + offset);
+-
+-	memcpy(buf, (void *)nvram_base_addr, NVRAM_SIZE);
+-	free(pfn_list);
+-	munmap(tmp_ptr, NVRAM_SIZE + PAGE_SIZE);
+-
+-	lseek(nvram_fd, 0, SEEK_SET);
+-	if ( write(nvram_fd, buf, NVRAM_SIZE) != NVRAM_SIZE )
+-	{
+-		PERROR("Save to nvram fail!\n");
+-		return -1;
+-	}
+-
+-	close(nvram_fd);
+-
+-	DPRINTF("Nvram save successful!\n");
+-
+-	return 0;
++    xen_pfn_t *pfn_list = NULL;
++    char *tmp_ptr = NULL;
++    unsigned int nr_pages = 0;
++    uint64_t addr_from_GFW_4k_align = 0;
++    uint32_t offset = 0;
++    uint64_t nvram_base_addr = 0;
++    char buf[NVRAM_SIZE] = {0};
++    int i;
++
++    // map one more page 
++    nr_pages = (NVRAM_SIZE + PAGE_SIZE) >> PAGE_SHIFT;
++    pfn_list = (xen_pfn_t *)malloc(sizeof(xen_pfn_t) * nr_pages);
++    if ( NULL == pfn_list )
++    {
++        PERROR("Cannot allocate memory for nvram save!\n");
++        close(nvram_fd);
++        return -1;
++    }
++
++    /* 
++     * GFW allocate memory dynamicly to save nvram data
++     * and save address of the dynamic memory at NVRAM_START. 
++     * To save nvram data to file, we must get the dynamic
++     * memory address first.
++     */
++    pfn_list[0] = NVRAM_START >> PAGE_SHIFT;
++    tmp_ptr = (char *)xc_map_foreign_range(xc_handle, dom, PAGE_SIZE,
++                                           PROT_READ | PROT_WRITE, pfn_list[0]);
++
++    if ( NULL == tmp_ptr )
++    {
++        PERROR("Cannot get nvram data from GFW!\n");
++        free(pfn_list);
++        close(nvram_fd);
++        return -1;
++    }
++
++    addr_from_GFW_4k_align = *((uint64_t *)tmp_ptr);
++    munmap(tmp_ptr, PAGE_SIZE);
++
++    // align address to 16k
++    offset = addr_from_GFW_4k_align % ( 16 * MEM_K );
++    addr_from_GFW_4k_align = addr_from_GFW_4k_align - offset;
++    for ( i=0; i<nr_pages; i++ )
++        pfn_list[i] = (addr_from_GFW_4k_align >> PAGE_SHIFT) + i;
++
++    tmp_ptr = (char *)xc_map_foreign_batch(xc_handle, dom,
++    PROT_READ | PROT_WRITE, pfn_list, nr_pages);
++    if ( NULL == tmp_ptr )
++    {
++        PERROR("Cannot get nvram data from GFW!\n");
++        free(pfn_list);
++        close(nvram_fd);
++        return -1;
++    }
++
++    // calculate nvram data base addrees
++    nvram_base_addr = (uint64_t)(tmp_ptr + offset);
++
++    memcpy(buf, (void *)nvram_base_addr, NVRAM_SIZE);
++    free(pfn_list);
++    munmap(tmp_ptr, NVRAM_SIZE + PAGE_SIZE);
++
++    lseek(nvram_fd, 0, SEEK_SET);
++    if ( write(nvram_fd, buf, NVRAM_SIZE) != NVRAM_SIZE )
++    {
++        PERROR("Save to nvram fail!\n");
++        return -1;
++    }
++
++    close(nvram_fd);
++
++    DPRINTF("Nvram save successful!\n");
++
++    return 0;
+ }
+ 
+ int xc_ia64_save_to_nvram(int xc_handle, uint32_t dom) 
+ {
+-	uint64_t nvram_fd = 0;
+-	xc_get_hvm_param(xc_handle, dom, HVM_PARAM_NVRAM_FD, &nvram_fd);
+-
+-	if ( !IS_VALID_NVRAM_FD(nvram_fd) )
+-	{
+-		PERROR("Nvram not be initialized. Nvram save fail!\n");
+-		return -1;
+-	}
+-	return copy_from_GFW_to_nvram(xc_handle, dom, (int)nvram_fd);	
++    uint64_t nvram_fd = 0;
++    xc_get_hvm_param(xc_handle, dom, HVM_PARAM_NVRAM_FD, &nvram_fd);
++
++    if ( !IS_VALID_NVRAM_FD(nvram_fd) )
++    {
++        PERROR("Nvram not be initialized. Nvram save fail!\n");
++        return -1;
++    }
++    return copy_from_GFW_to_nvram(xc_handle, dom, (int)nvram_fd);	
+ }
+ 
+ #define NVRAM_FILE_PATH	"/usr/lib/xen/boot/nvram_"
+ int xc_ia64_nvram_init(int xc_handle, char *dom_name, uint32_t dom)
+ {
+-	int file_path_len = strlen(NVRAM_FILE_PATH);
+-	uint64_t nvram_fd = 0;
+-	char nvram_path[100] = {0};
+-
+-	strncpy(nvram_path, NVRAM_FILE_PATH, file_path_len);
+-	if ( file_path_len + strlen(dom_name) + 1 > sizeof(nvram_path) )
+-	{
+-		PERROR("Nvram file path is too long!\n");
+-		return -1;
+-	}
+-	strcpy(nvram_path + file_path_len, dom_name);
+-
+-	nvram_fd = nvram_init(nvram_path);
+-	if ( nvram_fd == (uint64_t)(-1) )
+-	{
+-		xc_set_hvm_param(xc_handle, dom, HVM_PARAM_NVRAM_FD, 0);
+-		return -1;
+-	}
+-
+-	xc_set_hvm_param(xc_handle, dom, HVM_PARAM_NVRAM_FD, nvram_fd);
+-	return 0; 
++    int file_path_len = strlen(NVRAM_FILE_PATH);
++    uint64_t nvram_fd = 0;
++    char nvram_path[100] = {0};
++
++    strncpy(nvram_path, NVRAM_FILE_PATH, file_path_len);
++    if ( file_path_len + strlen(dom_name) + 1 > sizeof(nvram_path) )
++    {
++        PERROR("Nvram file path is too long!\n");
++        return -1;
++    }
++    strcpy(nvram_path + file_path_len, dom_name);
++
++    nvram_fd = nvram_init(nvram_path);
++    if ( nvram_fd == (uint64_t)(-1) )
++    {
++        xc_set_hvm_param(xc_handle, dom, HVM_PARAM_NVRAM_FD, 0);
++        return -1;
++    }
++
++    xc_set_hvm_param(xc_handle, dom, HVM_PARAM_NVRAM_FD, nvram_fd);
++    return 0; 
+ }
+ 
+ #define GFW_PAGES (GFW_SIZE >> PAGE_SHIFT)
diff -r 7ba52aa72ae5 15353-601509daabfc
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15353-601509daabfc	Tue Sep 11 12:28:40 2007 -0600
@@ -0,0 +1,310 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1181682425 21600
+# Node ID 601509daabfc0f33bae7cc5c07ef620b41c4a7a0
+# Parent  ba1f933f2382c95b9d735215f608ad3aa85eec4d
+[IA64] Support for multiple I/O port spaces
+
+Linux has support for multiple I/O port spaces on a system.  Depending
+on the system configuration, this might allow for 64k of I/O port space
+per PCI bus.  The "extended" I/O port ranges are described to the OS by
+_CRS methods on PCI root devices in ACPI namespace.  For instance, on my
+system, /proc/iomem shows several entries like these:
+
+80000000000-80003ffffff : PCI Bus 0000:00 I/O Ports 01000000-0100ffff
+80100000000-80103ffffff : PCI Bus 0000:01 I/O Ports 02000000-0200ffff
+80200000000-80203ffffff : PCI Bus 0000:0a I/O Ports 03000000-0300ffff
+80300000000-80303ffffff : PCI Bus 0000:0f I/O Ports 04000000-0400ffff
+...
+
+These describe MMIO ranges that provide I/O port ranges per PCI bus.
+My /proc/ioports then shows entries like these:
+
+01000000-0100ffff : PCI Bus 0000:00
+  01001000-010010ff : 0000:00:04.0
+02000000-0200ffff : PCI Bus 0000:01
+  02001000-02001fff : PCI Bus #02
+    02001000-0200107f : 0000:02:07.0
+      02001000-0200107f : tulip
+    02001080-020010ff : 0000:02:06.0
+      02001080-020010ff : tulip
+    02001100-0200117f : 0000:02:05.0
+    02001180-020011ff : 0000:02:04.0
+      02001180-020011ff : tulip
+  02002000-0200203f : 0000:01:02.1
+  02002040-0200207f : 0000:01:02.0
+    02002040-0200207f : e1000
+03000000-0300ffff : PCI Bus 0000:0a
+...
+
+Xen currently has no concept of these extended I/O port space ranges and
+prevents dom0 from doing the MMIO transactions required to access these
+ports.  This patch solves the problem.  First we need to make
+ioports_permit/deny_access() aware that multiple I/O port ranges with
+different MMIO base address exist.  Next we need to provide a mechanism
+to register new I/O port spaces, for this I've created the dom0vp op
+IA64_DOM0VP_add_io_space.  This allows dom0 to do the work of finding
+the ranges in ACPI namespace since we don't want to add that kind of
+bulk to Xen.  Finally, dom0 needs to make use of this interface when new
+ranges are found.
+
+Signed-off-by: Alex Williamson <alex.williamson@hp.com>
+xen-unstable changeset: 15353:601509daabfc0f33bae7cc5c07ef620b41c4a7a0
+xen-unstable date: Tue Jun 12 15:07:05 2007 -0600
+
+diff -r ba1f933f2382 -r 601509daabfc xen/arch/ia64/xen/dom0_ops.c
+--- a/xen/arch/ia64/xen/dom0_ops.c	Tue Jun 12 14:58:39 2007 -0600
++++ b/xen/arch/ia64/xen/dom0_ops.c	Tue Jun 12 15:07:05 2007 -0600
+@@ -363,6 +363,40 @@ dom0vp_fpswa_revision(XEN_GUEST_HANDLE(u
+     return 0;
+ }
+ 
++static unsigned long
++dom0vp_add_io_space(struct domain *d, unsigned long phys_base,
++                    unsigned long sparse, unsigned long space_number)
++{
++    unsigned int fp, lp;
++
++    /*
++     * Registering new io_space roughly based on linux
++     * arch/ia64/pci/pci.c:new_space()
++     */
++
++    /* Skip legacy I/O port space, we already know about it */
++    if (phys_base == 0)
++        return 0;
++
++    /*
++     * Dom0 Linux initializes io spaces sequentially, if that changes,
++     * we'll need to add thread protection and the ability to handle
++     * a sparsely populated io_space array.
++     */
++    if (space_number > MAX_IO_SPACES || space_number != num_io_spaces)
++        return -EINVAL;
++
++    io_space[space_number].mmio_base = phys_base;
++    io_space[space_number].sparse = sparse;
++
++    num_io_spaces++;
++
++    fp = space_number << IO_SPACE_BITS;
++    lp = fp | 0xffff;
++
++    return ioports_permit_access(d, fp, lp);
++}
++
+ unsigned long
+ do_dom0vp_op(unsigned long cmd,
+              unsigned long arg0, unsigned long arg1, unsigned long arg2,
+@@ -419,6 +453,9 @@ do_dom0vp_op(unsigned long cmd,
+         ret = dom0vp_fpswa_revision(hnd);
+         break;
+     }
++    case IA64_DOM0VP_add_io_space:
++        ret = dom0vp_add_io_space(d, arg0, arg1, arg2);
++        break;
+     default:
+         ret = -1;
+ 		printk("unknown dom0_vp_op 0x%lx\n", cmd);
+diff -r ba1f933f2382 -r 601509daabfc xen/arch/ia64/xen/mm.c
+--- a/xen/arch/ia64/xen/mm.c	Tue Jun 12 14:58:39 2007 -0600
++++ b/xen/arch/ia64/xen/mm.c	Tue Jun 12 15:07:05 2007 -0600
+@@ -890,81 +890,144 @@ assign_domain_page(struct domain *d,
+ }
+ 
+ int
+-ioports_permit_access(struct domain *d, unsigned long fp, unsigned long lp)
+-{
++ioports_permit_access(struct domain *d, unsigned int fp, unsigned int lp)
++{
++    struct io_space *space;
++    unsigned long mmio_start, mmio_end, mach_start;
+     int ret;
+-    unsigned long off;
+-    unsigned long fp_offset;
+-    unsigned long lp_offset;
+-
++
++    if (IO_SPACE_NR(fp) >= num_io_spaces) {
++        dprintk(XENLOG_WARNING, "Unknown I/O Port range 0x%x - 0x%x\n", fp, lp);
++        return -EFAULT;
++    }
++
++    /*
++     * The ioport_cap rangeset tracks the I/O port address including
++     * the port space ID.  This means port space IDs need to match
++     * between Xen and dom0.  This is also a requirement because
++     * the hypercall to pass these port ranges only uses a u32.
++     *
++     * NB - non-dom0 driver domains may only have a subset of the
++     * I/O port spaces and thus will number port spaces differently.
++     * This is ok, they don't make use of this interface.
++     */
+     ret = rangeset_add_range(d->arch.ioport_caps, fp, lp);
+     if (ret != 0)
+         return ret;
+ 
+-    /* Domain 0 doesn't virtualize IO ports space. */
+-    if (d == dom0)
++    space = &io_space[IO_SPACE_NR(fp)];
++
++    /* Legacy I/O on dom0 is already setup */
++    if (d == dom0 && space == &io_space[0])
+         return 0;
+ 
+-    fp_offset = IO_SPACE_SPARSE_ENCODING(fp) & ~PAGE_MASK;
+-    lp_offset = PAGE_ALIGN(IO_SPACE_SPARSE_ENCODING(lp));
+-
+-    for (off = fp_offset; off <= lp_offset; off += PAGE_SIZE)
+-        (void)__assign_domain_page(d, IO_PORTS_PADDR + off,
+-                                   __pa(ia64_iobase) + off, ASSIGN_nocache);
++    fp = IO_SPACE_PORT(fp);
++    lp = IO_SPACE_PORT(lp);
++
++    if (space->sparse) {
++        mmio_start = IO_SPACE_SPARSE_ENCODING(fp) & ~PAGE_MASK;
++        mmio_end = PAGE_ALIGN(IO_SPACE_SPARSE_ENCODING(lp));
++    } else {
++        mmio_start = fp & ~PAGE_MASK;
++        mmio_end = PAGE_ALIGN(lp);
++    }
++
++    /*
++     * The "machine first port" is not necessarily identity mapped
++     * to the guest first port.  At least for the legacy range.
++     */
++    mach_start = mmio_start | __pa(space->mmio_base);
++
++    if (space == &io_space[0]) {
++        mmio_start |= IO_PORTS_PADDR;
++        mmio_end |= IO_PORTS_PADDR;
++    } else {
++        mmio_start |= __pa(space->mmio_base);
++        mmio_end |= __pa(space->mmio_base);
++    }
++
++    while (mmio_start <= mmio_end) {
++        (void)__assign_domain_page(d, mmio_start, mach_start, ASSIGN_nocache); 
++        mmio_start += PAGE_SIZE;
++        mach_start += PAGE_SIZE;
++    }
+ 
+     return 0;
+ }
+ 
+ static int
+-ioports_has_allowed(struct domain *d, unsigned long fp, unsigned long lp)
+-{
+-    unsigned long i;
+-    for (i = fp; i < lp; i++)
+-        if (rangeset_contains_singleton(d->arch.ioport_caps, i))
++ioports_has_allowed(struct domain *d, unsigned int fp, unsigned int lp)
++{
++    for (; fp < lp; fp++)
++        if (rangeset_contains_singleton(d->arch.ioport_caps, fp))
+             return 1;
++
+     return 0;
+ }
+ 
+ int
+-ioports_deny_access(struct domain *d, unsigned long fp, unsigned long lp)
++ioports_deny_access(struct domain *d, unsigned int fp, unsigned int lp)
+ {
+     int ret;
+     struct mm_struct *mm = &d->arch.mm;
+-    unsigned long off;
+-    unsigned long io_ports_base;
+-    unsigned long fp_offset;
+-    unsigned long lp_offset;
++    unsigned long mmio_start, mmio_end, mmio_base;
++    unsigned int fp_base, lp_base;
++    struct io_space *space;
++
++    if (IO_SPACE_NR(fp) >= num_io_spaces) {
++        dprintk(XENLOG_WARNING, "Unknown I/O Port range 0x%x - 0x%x\n", fp, lp);
++        return -EFAULT;
++    }
+ 
+     ret = rangeset_remove_range(d->arch.ioport_caps, fp, lp);
+     if (ret != 0)
+         return ret;
+-    if (d == dom0)
+-        io_ports_base = __pa(ia64_iobase);
++
++    space = &io_space[IO_SPACE_NR(fp)];
++    fp_base = IO_SPACE_PORT(fp);
++    lp_base = IO_SPACE_PORT(lp);
++
++    if (space->sparse) {
++        mmio_start = IO_SPACE_SPARSE_ENCODING(fp_base) & ~PAGE_MASK;
++        mmio_end = PAGE_ALIGN(IO_SPACE_SPARSE_ENCODING(lp_base));
++    } else {
++        mmio_start = fp_base & ~PAGE_MASK;
++        mmio_end = PAGE_ALIGN(lp_base);
++    }
++
++    if (space == &io_space[0] && d != dom0)
++        mmio_base = IO_PORTS_PADDR;
+     else
+-        io_ports_base = IO_PORTS_PADDR;
+-
+-    fp_offset = IO_SPACE_SPARSE_ENCODING(fp) & PAGE_MASK;
+-    lp_offset = PAGE_ALIGN(IO_SPACE_SPARSE_ENCODING(lp));
+-
+-    for (off = fp_offset; off < lp_offset; off += PAGE_SIZE) {
+-        unsigned long mpaddr = io_ports_base + off;
+-        unsigned long port;
++        mmio_base = __pa(space->mmio_base);
++
++    for (; mmio_start < mmio_end; mmio_start += PAGE_SIZE) {
++        unsigned int port, range;
++        unsigned long mpaddr;
+         volatile pte_t *pte;
+         pte_t old_pte;
+ 
+-        port = IO_SPACE_SPARSE_DECODING (off);
+-        if (port < fp || port + IO_SPACE_SPARSE_PORTS_PER_PAGE - 1 > lp) {
++        if (space->sparse) {
++            port = IO_SPACE_SPARSE_DECODING(mmio_start);
++            range = IO_SPACE_SPARSE_PORTS_PER_PAGE - 1;
++        } else {
++            port = mmio_start;
++            range = PAGE_SIZE - 1;
++        }
++
++        port |= IO_SPACE_BASE(IO_SPACE_NR(fp));
++
++        if (port < fp || port + range > lp) {
+             /* Maybe this covers an allowed port.  */
+-            if (ioports_has_allowed(d, port,
+-                                    port + IO_SPACE_SPARSE_PORTS_PER_PAGE - 1))
++            if (ioports_has_allowed(d, port, port + range))
+                 continue;
+         }
+ 
++        mpaddr = mmio_start | mmio_base;
+         pte = lookup_noalloc_domain_pte_none(d, mpaddr);
+         BUG_ON(pte == NULL);
+         BUG_ON(pte_none(*pte));
+ 
+-        // clear pte
++        /* clear pte */
+         old_pte = ptep_get_and_clear(mm, mpaddr, pte);
+     }
+     domain_flush_vtlb_all(d);
+diff -r ba1f933f2382 -r 601509daabfc xen/include/asm-ia64/iocap.h
+--- a/xen/include/asm-ia64/iocap.h	Tue Jun 12 14:58:39 2007 -0600
++++ b/xen/include/asm-ia64/iocap.h	Tue Jun 12 15:07:05 2007 -0600
+@@ -8,9 +8,9 @@
+ #define __IA64_IOCAP_H__
+ 
+ extern int ioports_permit_access(struct domain *d,
+-                                 unsigned long s, unsigned long e);
++				 unsigned int s, unsigned int e);
+ extern int ioports_deny_access(struct domain *d,
+-                               unsigned long s, unsigned long e);
++			       unsigned int s, unsigned int e);
+ 
+ #define ioports_access_permitted(d, s, e)               \
+     rangeset_contains_range((d)->arch.ioport_caps, s, e)
diff -r 7ba52aa72ae5 15364-1623f5f5094f
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15364-1623f5f5094f	Tue Sep 11 12:28:55 2007 -0600
@@ -0,0 +1,38 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1181856742 21600
+# Node ID 1623f5f5094f4bc41be0d67f906b155e3704109c
+# Parent  a371cfbd62e8278e2bc9e6980eaa289c099f0ad8
+[IA64] Don't try to save nvram on PV domains
+
+Signed-off-by: Alex Williamson <alex.williamson@hp.com>
+xen-unstable changeset: 15364:1623f5f5094f4bc41be0d67f906b155e3704109c
+xen-unstable date: Thu Jun 14 15:32:22 2007 -0600
+
+diff -r a371cfbd62e8 -r 1623f5f5094f tools/libxc/ia64/xc_ia64_hvm_build.c
+--- a/tools/libxc/ia64/xc_ia64_hvm_build.c	Thu Jun 14 15:29:52 2007 -0600
++++ b/tools/libxc/ia64/xc_ia64_hvm_build.c	Thu Jun 14 15:32:22 2007 -0600
+@@ -709,11 +709,22 @@ copy_from_GFW_to_nvram(int xc_handle, ui
+ 
+ int xc_ia64_save_to_nvram(int xc_handle, uint32_t dom) 
+ {
++    xc_dominfo_t info;
+     uint64_t nvram_fd = 0;
++
++    if ( xc_domain_getinfo(xc_handle, dom, 1, &info) != 1 )
++    {
++        PERROR("Could not get info for domain");
++        return -1;
++    }
++
++    if ( !info.hvm )
++        return 0;
++
+     xc_get_hvm_param(xc_handle, dom, HVM_PARAM_NVRAM_FD, &nvram_fd);
+ 
+     if ( !IS_VALID_NVRAM_FD(nvram_fd) )
+-        PERROR("Nvram not be initialized. Nvram save fail!\n");
++        PERROR("Nvram not initialized. Nvram save failed!\n");
+     else
+         copy_from_GFW_to_nvram(xc_handle, dom, (int)nvram_fd);	
+ 	
diff -r 7ba52aa72ae5 15365-33cc64dcaead
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15365-33cc64dcaead	Tue Sep 11 12:29:18 2007 -0600
@@ -0,0 +1,34 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1181921109 21600
+# Node ID 33cc64dcaead095d4f8115a5b7f8565f5becaf1c
+# Parent  1623f5f5094f4bc41be0d67f906b155e3704109c
+[IA64] Create NVRAM save directory
+
+If you use RPM to install XEN, the directory(/usr/lib/xen/boot)
+will be removed when you un-install the RPM. This patch create
+that directory before NVRAM file creating.
+
+Signed-off-by: Zhang Xin <xing.z.zhang@intel.com>
+xen-unstable changeset: 15365:33cc64dcaead095d4f8115a5b7f8565f5becaf1c
+xen-unstable date: Fri Jun 15 09:25:09 2007 -0600
+
+diff -r 1623f5f5094f -r 33cc64dcaead tools/libxc/ia64/xc_ia64_hvm_build.c
+--- a/tools/libxc/ia64/xc_ia64_hvm_build.c	Thu Jun 14 15:32:22 2007 -0600
++++ b/tools/libxc/ia64/xc_ia64_hvm_build.c	Fri Jun 15 09:25:09 2007 -0600
+@@ -735,6 +735,7 @@ int xc_ia64_save_to_nvram(int xc_handle,
+     return 0;
+ }
+ 
++#define NVRAM_DIR       "/usr/lib/xen/boot/"
+ #define NVRAM_FILE_PATH	"/usr/lib/xen/boot/nvram_"
+ int xc_ia64_nvram_init(int xc_handle, char *dom_name, uint32_t dom)
+ {
+@@ -749,6 +750,7 @@ int xc_ia64_nvram_init(int xc_handle, ch
+         return -1;
+     }
+     strcpy(nvram_path + file_path_len, dom_name);
++    mkdir(NVRAM_DIR, 0765);
+ 
+     nvram_fd = nvram_init(nvram_path);
+     if ( nvram_fd == (uint64_t)(-1) )
diff -r 7ba52aa72ae5 15366-fd0103b55504
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15366-fd0103b55504	Tue Sep 11 12:29:48 2007 -0600
@@ -0,0 +1,67 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1181928874 21600
+# Node ID fd0103b55504bac392864de87d21506e18ba2d6b
+# Parent  33cc64dcaead095d4f8115a5b7f8565f5becaf1c
+[IA64] Add error checking to nvram store mkdir
+
+Signed-off-by: Alex Williamson <alex.williamson@hp.com>
+xen-unstable changeset: 15366:fd0103b55504bac392864de87d21506e18ba2d6b
+xen-unstable date: Fri Jun 15 11:34:34 2007 -0600
+
+diff -r 33cc64dcaead -r fd0103b55504 tools/libxc/ia64/xc_ia64_hvm_build.c
+--- a/tools/libxc/ia64/xc_ia64_hvm_build.c	Fri Jun 15 09:25:09 2007 -0600
++++ b/tools/libxc/ia64/xc_ia64_hvm_build.c	Fri Jun 15 11:34:34 2007 -0600
+@@ -578,7 +578,7 @@ nvram_init(const char *nvram_path)
+ nvram_init(const char *nvram_path)
+ {
+     uint64_t fd = 0;
+-    fd = open(nvram_path, O_CREAT|O_RDWR, 0666);
++    fd = open(nvram_path, O_CREAT|O_RDWR, 0644);
+ 
+     if ( fd < 0 )
+     {
+@@ -736,12 +736,34 @@ int xc_ia64_save_to_nvram(int xc_handle,
+ }
+ 
+ #define NVRAM_DIR       "/usr/lib/xen/boot/"
+-#define NVRAM_FILE_PATH	"/usr/lib/xen/boot/nvram_"
++#define NVRAM_FILE_PATH "/usr/lib/xen/boot/nvram_"
++
+ int xc_ia64_nvram_init(int xc_handle, char *dom_name, uint32_t dom)
+ {
+     int file_path_len = strlen(NVRAM_FILE_PATH);
+     uint64_t nvram_fd = 0;
+     char nvram_path[100] = {0};
++    struct stat stat_buf;
++
++    if ( stat(NVRAM_DIR, &stat_buf) == -1 ) {
++        if ( errno != ENOENT )
++        {
++            PERROR("Error stat'ing NVRAM dir %s.", NVRAM_DIR);
++            return -1;
++        }
++        if ( mkdir(NVRAM_DIR, 0755) == -1 )
++        {
++            PERROR("Unable to create NVRAM store directory %s.", NVRAM_DIR);
++            return -1;
++        }
++    }
++
++    if ( !(stat_buf.st_mode & S_IRUSR) || !(stat_buf.st_mode & S_IWUSR) )
++    {
++        errno = EACCES;
++        PERROR("No R/W permission to NVRAM store directory %s.", NVRAM_DIR);
++        return -1;
++    }
+ 
+     strncpy(nvram_path, NVRAM_FILE_PATH, file_path_len);
+     if ( file_path_len + strlen(dom_name) + 1 > sizeof(nvram_path) )
+@@ -750,7 +772,6 @@ int xc_ia64_nvram_init(int xc_handle, ch
+         return -1;
+     }
+     strcpy(nvram_path + file_path_len, dom_name);
+-    mkdir(NVRAM_DIR, 0765);
+ 
+     nvram_fd = nvram_init(nvram_path);
+     if ( nvram_fd == (uint64_t)(-1) )
diff -r 7ba52aa72ae5 15555-38d061886873
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15555-38d061886873	Tue Sep 11 12:30:14 2007 -0600
@@ -0,0 +1,73 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1183388724 21600
+# Node ID 38d0618868738b03611bdbb9f3fe29c73f1c34dd
+# Parent  89596982890b78ebceffc4c5803662adc3dddc73
+[IA64] Fix incorrect NVRAM saving if domain is destroyed by config error
+
+Nvram saving is always executed even if a domain is destroyed by a
+configuration parameter error.  In this case, Nvram saving function
+will get a bad address for the NVRAM data and save garbage into the
+NVRAM file. Configuring a wrong vif parameter can expose this issue.
+
+This patch fixes the issue by adding an address check function in
+NVRAM saving path.
+
+Signed-off-by: Zhang Xin <xing.z.zhang@intel.com>
+xen-unstable changeset: 15555:38d0618868738b03611bdbb9f3fe29c73f1c34dd
+xen-unstable date: Mon Jul 02 09:05:24 2007 -0600
+
+diff -r 89596982890b -r 38d061886873 tools/libxc/ia64/xc_ia64_hvm_build.c
+--- a/tools/libxc/ia64/xc_ia64_hvm_build.c	Mon Jul 02 08:51:59 2007 -0600
++++ b/tools/libxc/ia64/xc_ia64_hvm_build.c	Mon Jul 02 09:05:24 2007 -0600
+@@ -623,6 +623,21 @@ copy_from_nvram_to_GFW(int xc_handle, ui
+ 
+ 
+ /*
++ *Check is the address where NVRAM data located valid
++ */
++static int is_valid_address(void *addr)
++{
++    struct nvram_save_addr *p = (struct nvram_save_addr *)addr;	
++
++    if ( p->signature == NVRAM_VALID_SIG )
++        return 1;
++    else {
++        PERROR("Invalid nvram signature. Nvram save failed!\n");
++        return 0;
++    }
++}
++
++/*
+  * GFW use 4k page. when doing foreign map, we should 16k align
+  * the address and map one more page to guarantee all 64k nvram data 
+  * can be got.
+@@ -667,7 +682,11 @@ copy_from_GFW_to_nvram(int xc_handle, ui
+         return -1;
+     }
+ 
+-    addr_from_GFW_4k_align = *((uint64_t *)tmp_ptr);
++    /* Check is NVRAM data vaild */
++    if ( !is_valid_address(tmp_ptr) )
++        return -1;
++
++    addr_from_GFW_4k_align = ((struct nvram_save_addr *)tmp_ptr)->addr;
+     munmap(tmp_ptr, PAGE_SIZE);
+ 
+     // align address to 16k
+diff -r 89596982890b -r 38d061886873 xen/include/public/arch-ia64.h
+--- a/xen/include/public/arch-ia64.h	Mon Jul 02 08:51:59 2007 -0600
++++ b/xen/include/public/arch-ia64.h	Mon Jul 02 09:05:24 2007 -0600
+@@ -116,6 +116,12 @@ typedef unsigned long xen_ulong_t;
+ /* Nvram belongs to GFW memory space  */
+ #define NVRAM_SIZE       (MEM_K * 64)
+ #define NVRAM_START      (GFW_START + 10 * MEM_M)
++
++#define NVRAM_VALID_SIG 0x4650494e45584948 		// "HIXENIPF"
++struct nvram_save_addr {
++    unsigned long addr;
++    unsigned long signature;
++};
+ 
+ struct pt_fpreg {
+     union {
diff -r 7ba52aa72ae5 15557-2a5b463f2e8d
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15557-2a5b463f2e8d	Tue Sep 11 12:30:34 2007 -0600
@@ -0,0 +1,52 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1183390731 21600
+# Node ID 2a5b463f2e8dcb5b132062547f2ea76780d80aae
+# Parent  88ab11d8fd1c1052f0e0f1aa5b029c353d03b067
+[IA64] Fix NVRAM data cannot be saved when guest execute "reboot"
+
+Also fix "xm reboot" instruction in Xend.
+
+Signed-off-by: Zhang Xin <xing.z.zhang@intel.com>
+xen-unstable changeset: 15557:2a5b463f2e8dcb5b132062547f2ea76780d80aae
+xen-unstable date: Mon Jul 02 09:38:51 2007 -0600
+
+diff -r 88ab11d8fd1c -r 2a5b463f2e8d tools/ioemu/target-i386-dm/helper2.c
+--- a/tools/ioemu/target-i386-dm/helper2.c	Mon Jul 02 09:29:08 2007 -0600
++++ b/tools/ioemu/target-i386-dm/helper2.c	Mon Jul 02 09:38:51 2007 -0600
+@@ -140,6 +140,7 @@ void cpu_reset(CPUX86State *env)
+     if (xcHandle < 0)
+         fprintf(logfile, "Cannot acquire xenctrl handle\n");
+     else {
++        xc_domain_shutdown_hook(xcHandle, domid);
+         sts = xc_domain_shutdown(xcHandle, domid, SHUTDOWN_reboot);
+         if (sts != 0)
+             fprintf(logfile,
+diff -r 88ab11d8fd1c -r 2a5b463f2e8d tools/ioemu/vl.h
+--- a/tools/ioemu/vl.h	Mon Jul 02 09:29:08 2007 -0600
++++ b/tools/ioemu/vl.h	Mon Jul 02 09:38:51 2007 -0600
+@@ -1498,4 +1498,13 @@ void destroy_hvm_domain(void);
+ /* VNC Authentication */
+ #define AUTHCHALLENGESIZE 16
+ 
++#ifdef __ia64__
++static inline void xc_domain_shutdown_hook(int xc_handle, uint32_t domid)
++{
++	xc_ia64_save_to_nvram(xc_handle, domid);
++}
++#else
++#define xc_domain_shutdown_hook(xc_handle. domid)	do {} while (0)
++#endif
++
+ #endif /* VL_H */
+diff -r 88ab11d8fd1c -r 2a5b463f2e8d tools/python/xen/xend/XendDomainInfo.py
+--- a/tools/python/xen/xend/XendDomainInfo.py	Mon Jul 02 09:29:08 2007 -0600
++++ b/tools/python/xen/xend/XendDomainInfo.py	Mon Jul 02 09:38:51 2007 -0600
+@@ -459,6 +459,7 @@ class XendDomainInfo:
+             hvm_pvdrv = xc.hvm_get_param(self.domid, HVM_PARAM_CALLBACK_IRQ)
+             if not hvm_pvdrv:
+                 code = REVERSE_DOMAIN_SHUTDOWN_REASONS[reason]
++                xc.domain_destroy_hook(self.domid)
+                 log.info("HVM save:remote shutdown dom %d!", self.domid)
+                 xc.domain_shutdown(self.domid, code)
+ 
diff -r 7ba52aa72ae5 15579-f536eb8576ee
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15579-f536eb8576ee	Tue Sep 11 12:30:56 2007 -0600
@@ -0,0 +1,33 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1184175150 21600
+# Node ID f536eb8576eeb7363212911b02fbaff4918172df
+# Parent  a36c51f43fdb8734c1ea117334886aa47c4fd216
+[IA64] Fix VTi domain shutdown
+
+Event channel destruction is now done earlier, this patch does
+the corresponding modification in IA64 side. It fixes dom0 crash
+when VTI destroyed.
+
+Signed-off-by: Zhang Xin <xing.z.zhang@intel.com>
+xen-unstable changeset: 15579:f536eb8576eeb7363212911b02fbaff4918172df
+xen-unstable date: Wed Jul 11 11:32:30 2007 -0600
+
+diff -r a36c51f43fdb -r f536eb8576ee xen/arch/ia64/vmx/vmx_init.c
+--- a/xen/arch/ia64/vmx/vmx_init.c	Tue Jul 10 11:15:54 2007 -0600
++++ b/xen/arch/ia64/vmx/vmx_init.c	Wed Jul 11 11:32:30 2007 -0600
+@@ -283,9 +283,13 @@ static void vmx_create_event_channels(st
+ 	}
+ }
+ 
++/*
++ * Event channel has destoryed in domain_kill(), so we needn't
++ * do anything here
++ */
+ static void vmx_release_assist_channel(struct vcpu *v)
+ {
+-	free_xen_event_channel(v, v->arch.arch_vmx.xen_port);
++	return;
+ }
+ 
+ /*
diff -r 7ba52aa72ae5 15850-6644d8486266
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15850-6644d8486266	Tue Sep 11 12:31:12 2007 -0600
@@ -0,0 +1,31 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1187989754 21600
+# Node ID 6644d848626685f01d6832837fdb4ab2e06fffde
+# Parent  0cc2e0a1b2fcf0f46a23f51e691650893ae5aee9
+[IA64] Clean up NVRAM failure case
+
+copy_from_GFW_to_nvram() in libxc forgot munmap() if NVRAM data
+invalid.  Also it forgot free() and close() too.
+
+Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
+xen-unstable changeset: 15850:6644d848626685f01d6832837fdb4ab2e06fffde
+xen-unstable date: Fri Aug 24 15:09:14 2007 -0600
+
+diff -r 0cc2e0a1b2fc -r 6644d8486266 tools/libxc/ia64/xc_ia64_hvm_build.c
+--- a/tools/libxc/ia64/xc_ia64_hvm_build.c	Fri Aug 24 15:06:49 2007 -0600
++++ b/tools/libxc/ia64/xc_ia64_hvm_build.c	Fri Aug 24 15:09:14 2007 -0600
+@@ -684,7 +684,12 @@ copy_from_GFW_to_nvram(int xc_handle, ui
+ 
+     /* Check is NVRAM data vaild */
+     if ( !is_valid_address(tmp_ptr) )
+-        return -1;
++    {
++        free(pfn_list);
++        munmap(tmp_ptr, PAGE_SIZE);
++        close(nvram_fd);
++        return -1;
++    }
+ 
+     addr_from_GFW_4k_align = ((struct nvram_save_addr *)tmp_ptr)->addr;
+     munmap(tmp_ptr, PAGE_SIZE);
diff -r 7ba52aa72ae5 15852-f88eea67a469
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15852-f88eea67a469	Tue Sep 11 12:31:28 2007 -0600
@@ -0,0 +1,104 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1188325537 21600
+# Node ID f88eea67a46997c79b56e5ba595f0572584d9d51
+# Parent  c21bd325088a2161206bb0ae03ebf4a5bee5569e
+[IA64] Move nvram from /usr to /var
+
+Presently nvram is stored in /usr/lib/xen/boot/nvram_<domain> next to the guest
+firmware.  This violates the FHS because /usr might be mounted read-only.  This
+patch moves the nvram storage to /var/lib/xen/nvram/nvram_<domain>
+
+Also clean up:
+- references to stat_buf assumed that stat() had succeeded; use access()
+  instead since it's easier and doesn't require stat_buf at all
+- nvram_path[PATH_MAX] instead of nvram_path[100]
+- strncpy(..., strlen(src)) is meaningless, re-order length tests to work
+  correctly
+
+Signed-off-by: Aron Griffis <aron@hp.com>
+xen-unstable changeset: 15852:f88eea67a46997c79b56e5ba595f0572584d9d51
+xen-unstable date: Tue Aug 28 12:25:37 2007 -0600
+
+diff -r c21bd325088a -r f88eea67a469 tools/libxc/ia64/xc_ia64_hvm_build.c
+--- a/tools/libxc/ia64/xc_ia64_hvm_build.c	Tue Aug 28 12:24:27 2007 -0600
++++ b/tools/libxc/ia64/xc_ia64_hvm_build.c	Tue Aug 28 12:25:37 2007 -0600
+@@ -5,6 +5,7 @@
+ #include "xc_elf.h"
+ #include "xc_efi.h"
+ #include <stdlib.h>
++#include <unistd.h>
+ #include <zlib.h>
+ #include "xen/arch-ia64.h"
+ #include <xen/hvm/ioreq.h>
+@@ -596,7 +597,7 @@ copy_from_nvram_to_GFW(int xc_handle, ui
+     unsigned int nr_pages = NVRAM_SIZE >> PAGE_SHIFT;
+     struct stat file_stat;
+     char buf[NVRAM_SIZE] = {0};
+-	
++
+     if ( fstat(nvram_fd, &file_stat) < 0 )
+     {
+         PERROR("Cannot get Nvram file info! Guest will boot without "
+@@ -759,43 +760,41 @@ int xc_ia64_save_to_nvram(int xc_handle,
+     return 0;
+ }
+ 
+-#define NVRAM_DIR       "/usr/lib/xen/boot/"
+-#define NVRAM_FILE_PATH "/usr/lib/xen/boot/nvram_"
++#define NVRAM_DIR         "/var/lib/xen/nvram/"
++#define NVRAM_FILE_PREFIX "nvram_"
+ 
+ int xc_ia64_nvram_init(int xc_handle, char *dom_name, uint32_t dom)
+ {
+-    int file_path_len = strlen(NVRAM_FILE_PATH);
+-    uint64_t nvram_fd = 0;
+-    char nvram_path[100] = {0};
+-    struct stat stat_buf;
+-
+-    if ( stat(NVRAM_DIR, &stat_buf) == -1 ) {
++    uint64_t nvram_fd;
++    char nvram_path[PATH_MAX] = NVRAM_DIR;
++
++    if ( access(nvram_path, R_OK|W_OK|X_OK) == -1 ) {
+         if ( errno != ENOENT )
+         {
+-            PERROR("Error stat'ing NVRAM dir %s.", NVRAM_DIR);
++            PERROR("Error stat'ing NVRAM dir %s.", nvram_path);
+             return -1;
+         }
+-        if ( mkdir(NVRAM_DIR, 0755) == -1 )
++        if ( mkdir(nvram_path, 0755) == -1 )
+         {
+-            PERROR("Unable to create NVRAM store directory %s.", NVRAM_DIR);
++            PERROR("Unable to create NVRAM store directory %s.", nvram_path);
+             return -1;
+         }
+     }
+ 
+-    if ( !(stat_buf.st_mode & S_IRUSR) || !(stat_buf.st_mode & S_IWUSR) )
+-    {
++    if ( access(nvram_path, R_OK|W_OK|X_OK) == -1 ) {
+         errno = EACCES;
+-        PERROR("No R/W permission to NVRAM store directory %s.", NVRAM_DIR);
+-        return -1;
+-    }
+-
+-    strncpy(nvram_path, NVRAM_FILE_PATH, file_path_len);
+-    if ( file_path_len + strlen(dom_name) + 1 > sizeof(nvram_path) )
++        PERROR("No RWX permission to NVRAM store directory %s.", nvram_path);
++        return -1;
++    }
++
++    if ( strlen(nvram_path) + strlen(NVRAM_FILE_PREFIX) +
++         strlen(dom_name) + 1 > sizeof(nvram_path) )
+     {
+         PERROR("Nvram file path is too long!\n");
+         return -1;
+     }
+-    strcpy(nvram_path + file_path_len, dom_name);
++    strcat(nvram_path, NVRAM_FILE_PREFIX);
++    strcat(nvram_path, dom_name);
+ 
+     nvram_fd = nvram_init(nvram_path);
+     if ( nvram_fd == (uint64_t)(-1) )
diff -r 7ba52aa72ae5 ia64-sal-get-state-info
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/ia64-sal-get-state-info	Tue Sep 11 12:36:03 2007 -0600
@@ -0,0 +1,19 @@
+[IA64] Use GFP_ATOMIC for ia64_sal_get_state_info()
+
+This can be called in interrupt context.
+
+Signed-off-by: Kazuhiro Suzuki <kaz@jp.fujitsu.com>
+[patch from xen-ia64-devel mailing list]
+
+diff -r 9ac03e8238f6 linux-2.6-xen-sparse/include/asm-ia64/sal.h
+--- a/linux-2.6-xen-sparse/include/asm-ia64/sal.h	Fri Sep 07 10:19:22 2007 +0100
++++ b/linux-2.6-xen-sparse/include/asm-ia64/sal.h	Mon Sep 10 12:59:48 2007 -0600
+@@ -703,7 +703,7 @@ ia64_sal_get_state_info (u64 sal_info_ty
+ 
+ 		if (xencomm_create(sal_info,
+ 		                   ia64_sal_get_state_info_size(sal_info_type),
+-		                   &desc, GFP_KERNEL))
++		                   &desc, GFP_ATOMIC))
+ 			return 0;
+ 
+ 		SAL_CALL_REENTRANT(isrv, SAL_GET_STATE_INFO, sal_info_type, 0,
diff -r 7ba52aa72ae5 linux-46-93a955c2bebb
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/linux-46-93a955c2bebb	Tue Sep 11 12:32:53 2007 -0600
@@ -0,0 +1,786 @@
+# HG changeset patch
+# User kfraser@localhost.localdomain
+# Date 1181644618 -3600
+# Node ID 93a955c2bebbf3be1a4b455d106762ac179ee845
+# Parent  e5b50dd9fcf5aad4567ffe74a80c93ad55e383e2
+pciback: "Controller" pcibackend and frontend extensions.
+
+On ia64, we've run into the case where the I/O hierarchies are more
+complicated than the current set of driver domain backends can describe.
+Some platforms make use of translation offsets for I/O port and MMIO
+ranges.  Without knowledge of these translation offsets, devices are
+unusable by driver domains.  For instance, here's an example of a
+tulip card that lives under a PCI root bus making use of an I/O port
+translation:
+
+# lspci -v -s 02:05.0
+02:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
+        Subsystem: Hewlett-Packard Company Unknown device 125a
+        Flags: bus master, medium devsel, latency 128, IRQ 67
+        I/O ports at 2001100 [size=128]
+        Memory at 90102000 (32-bit, non-prefetchable) [size=1K]
+        Expansion ROM at 90080000 [disabled] [size=256K]
+
+# setpci -s 02:05.0 BASE_ADDRESS_0
+00001101
+
+# cat /proc/ioports
+...
+02000000-0200ffff : PCI Bus 0000:01
+  02001000-02001fff : PCI Bus #02
+    02001100-0200117f : 0000:02:05.0
+      02001100-0200117f : tulip
+...
+
+# cat /proc/iomem
+...
+80100000000-80103ffffff : PCI Bus 0000:01 I/O Ports 02000000-0200ffff
+...
+
+I/O port spaces are of course limited to 64k, but on this system
+multiple I/O port spaces are available (one per PCI root bridge in
+this case).  On ia64, I/O port spaces are typically a sparse encoding
+of an MMIO range.  The legacy I/O port range is decoded directly by
+the processor, additional ranges are decoded by the I/O hardware.  To
+access I/O port 0x1100 on this device, the driver needs to do an
+inb/outb to address 0x2001100.  The kernel will then swizzle the bits
+to create an MMIO transaction within the MMIO range for that set of
+I/O ports.
+
+To support this, I've created the "controller" backend as shown below.
+This is unfortunately an ia64-specific backend, but I don't see
+any mechanism to generically support the kinds of things this backend
+needs to do.  PCI controllers on ia64 are created to represent the PCI
+root bridges found in ACPI.  These root bridge ACPI nodes have _CRS
+(Current Resource Setting) methods that describe the address ranges
+consumed by the bus below the root bridge.  Address ranges described
+with a translation attribute make use of a translation offset to reach
+the desired address.  This information must be provided to a driver
+domain guest to allow it to access the devices.
+
+Given this architecture, the obvious choice is to create virtual PCI
+buses based on controllers.  All devices physically under the same
+controller are virtualized under the same domain:bus.  Within a bus,
+device slots are virtualized much like the slot backend.  The tricky
+part comes with how to describe the address translation for a
+controller to the guest driver domain.  For this, I chose to store the
+information in xenbus.  We already make use of the following keys for
+driver domains:
+
+root_num        /* Number of PCI roots exposed */
+root-X          /* domain:bus information for root X */
+
+To this, I've added:
+
+root-X-resources        /* number of resources for root X */
+root-X-resource-Y       /* resource umber Y for root X */
+root-resource-magic     /* synchronization/versioning for resource
+info */
+
+I debated for a while how to expose the root-X-resource-Y information
+and came up with a simple ASCII dump of the struct acpi_resource
+returned from the ACPI _CRS method.  This isn't quite a silly as it
+sounds because the structure is a fixed size regardless of word
+length, and it's contents are largely based on fixed tables found in
+the ACPI spec.  This makes it relatively immune to frequent changes.
+The PCI backend stores the ASCII byte stream of the controller
+resources into xenbus, the PCI frontend then extracts the byte stream,
+and decodes it back into a struct acpi_resource for use.
+
+The only changes to the existing code to support the frontend is a
+trivial addition of passing the bus number to pcifront_init_sd() and a
+hook to setup the root windows after the bus is scanned.  No changes
+are required for the controller backend.
+
+Signed-off-by: Alex Williamson <alex.williamson@hp.com>
+linux-2.6.18-xen changeset: 46:93a955c2bebbf3be1a4b455d106762ac179ee845
+linux-2.6.18-xen date: Tue Jun 12 11:36:58 2007 +0100
+
+diff -r e5b50dd9fcf5 -r 93a955c2bebb arch/ia64/pci/pci.c
+--- a/linux-2.6-xen-sparse/arch/ia64/pci/pci.c	Tue Jun 12 11:15:20 2007 +0100
++++ b/linux-2.6-xen-sparse/arch/ia64/pci/pci.c	Tue Jun 12 11:36:58 2007 +0100
+@@ -834,3 +834,31 @@ int pci_vector_resources(int last, int n
+ 
+ 	return count;
+ }
++
++#ifdef CONFIG_XEN
++void __devinit xen_add_resource(struct pci_controller *controller,
++				unsigned int domain, unsigned int bus,
++				struct acpi_resource *resource)
++{
++	struct pci_root_info info;
++	char *name;
++
++	name = kmalloc(16, GFP_KERNEL);
++	if (!name)
++		return;
++
++	sprintf(name, "PCI Bus %04x:%02x", domain, bus);
++	info.controller = controller;
++	info.name = name;
++
++	add_window(resource, &info);
++}
++EXPORT_SYMBOL(xen_add_resource);
++
++void __devinit xen_pcibios_setup_root_windows(struct pci_bus *bus,
++					      struct pci_controller *controller)
++{
++	pcibios_setup_root_windows(bus, controller);
++}
++EXPORT_SYMBOL(xen_pcibios_setup_root_windows);
++#endif
+diff -r e5b50dd9fcf5 -r 93a955c2bebb drivers/xen/Kconfig
+--- a/linux-2.6-xen-sparse/drivers/xen/Kconfig	Tue Jun 12 11:15:20 2007 +0100
++++ b/linux-2.6-xen-sparse/drivers/xen/Kconfig	Tue Jun 12 11:36:58 2007 +0100
+@@ -109,7 +109,8 @@ choice
+ choice
+ 	prompt "PCI Backend Mode"
+ 	depends on XEN_PCIDEV_BACKEND
+-	default XEN_PCIDEV_BACKEND_VPCI
++	default XEN_PCIDEV_BACKEND_VPCI if !IA64
++	default XEN_PCIDEV_BACKEND_CONTROLLER if IA64
+ 
+ config XEN_PCIDEV_BACKEND_VPCI
+ 	bool "Virtual PCI"
+@@ -138,6 +139,21 @@ config XEN_PCIDEV_BACKEND_SLOT
+ 	  For example, a device at 03:05.2 will be re-assigned to 00:00.0. A
+ 	  second device at 02:1a.1 will be re-assigned to 00:01.0.
+ 
++config XEN_PCIDEV_BACKEND_CONTROLLER
++	bool "Controller"
++	depends on IA64
++	---help---
++	  This PCI backend virtualizes the PCI bus topology by providing a
++	  virtual bus per PCI root device.  Devices which are physically under
++	  the same root bus will appear on the same virtual bus.  For systems
++	  with complex I/O addressing, this is the only backend which supports
++	  extended I/O port spaces and MMIO translation offsets.  This backend
++	  also supports slot virtualization.  For example, a device at
++	  0000:01:02.1 will be re-assigned to 0000:00:00.0.  A second device
++	  at 0000:02:05.0 (behind a P2P bridge on bus 0000:01) will be
++	  re-assigned to 0000:00:01.0.  A third device at 0000:16:05.0 (under
++	  a different PCI root bus) will be re-assigned to 0000:01:00.0.
++
+ endchoice
+ 
+ config XEN_PCIDEV_BE_DEBUG
+diff -r e5b50dd9fcf5 -r 93a955c2bebb drivers/xen/pciback/Makefile
+--- a/linux-2.6-xen-sparse/drivers/xen/pciback/Makefile	Tue Jun 12 11:15:20 2007 +0100
++++ b/linux-2.6-xen-sparse/drivers/xen/pciback/Makefile	Tue Jun 12 11:36:58 2007 +0100
+@@ -9,6 +9,7 @@ pciback-$(CONFIG_XEN_PCIDEV_BACKEND_VPCI
+ pciback-$(CONFIG_XEN_PCIDEV_BACKEND_VPCI) += vpci.o
+ pciback-$(CONFIG_XEN_PCIDEV_BACKEND_SLOT) += slot.o
+ pciback-$(CONFIG_XEN_PCIDEV_BACKEND_PASS) += passthrough.o
++pciback-$(CONFIG_XEN_PCIDEV_BACKEND_CONTROLLER) += controller.o
+ 
+ ifeq ($(CONFIG_XEN_PCIDEV_BE_DEBUG),y)
+ EXTRA_CFLAGS += -DDEBUG
+diff -r e5b50dd9fcf5 -r 93a955c2bebb drivers/xen/pciback/controller.c
+--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
++++ b/linux-2.6-xen-sparse/drivers/xen/pciback/controller.c	Tue Jun 12 11:36:58 2007 +0100
+@@ -0,0 +1,404 @@
++/*
++ * Copyright (C) 2007 Hewlett-Packard Development Company, L.P.
++ *      Alex Williamson <alex.williamson@hp.com>
++ *
++ * PCI "Controller" Backend - virtualize PCI bus topology based on PCI
++ * controllers.  Devices under the same PCI controller are exposed on the
++ * same virtual domain:bus.  Within a bus, device slots are virtualized
++ * to compact the bus.
++ *
++ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
++ * This program is free software; you can redistribute it and/or modify
++ * it under the terms of the GNU General Public License as published by
++ * the Free Software Foundation; either version 2 of the License, or
++ * (at your option) any later version.
++ *
++ * This program is distributed in the hope that it will be useful,
++ * but WITHOUT ANY WARRANTY; without even the implied warranty of
++ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
++ * GNU General Public License for more details.
++ *
++ * You should have received a copy of the GNU General Public License
++ * along with this program; if not, write to the Free Software
++ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
++ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
++ */
++
++#include <linux/acpi.h>
++#include <linux/list.h>
++#include <linux/pci.h>
++#include <linux/spinlock.h>
++#include "pciback.h"
++
++#define PCI_MAX_BUSSES	255
++#define PCI_MAX_SLOTS	32
++
++struct controller_dev_entry {
++	struct list_head list;
++	struct pci_dev *dev;
++	unsigned int devfn;
++};
++
++struct controller_list_entry {
++	struct list_head list;
++	struct pci_controller *controller;
++	unsigned int domain;
++	unsigned int bus;
++	unsigned int next_devfn;
++	struct list_head dev_list;
++};
++
++struct controller_dev_data {
++	struct list_head list;
++	unsigned int next_domain;
++	unsigned int next_bus;
++	spinlock_t lock;
++};
++
++struct walk_info {
++	struct pciback_device *pdev;
++	int resource_count;
++	int root_num;
++};
++
++struct pci_dev *pciback_get_pci_dev(struct pciback_device *pdev,
++				    unsigned int domain, unsigned int bus,
++				    unsigned int devfn)
++{
++	struct controller_dev_data *dev_data = pdev->pci_dev_data;
++	struct controller_dev_entry *dev_entry;
++	struct controller_list_entry *cntrl_entry;
++	struct pci_dev *dev = NULL;
++	unsigned long flags;
++
++	spin_lock_irqsave(&dev_data->lock, flags);
++
++	list_for_each_entry(cntrl_entry, &dev_data->list, list) {
++		if (cntrl_entry->domain != domain ||
++		    cntrl_entry->bus != bus)
++			continue;
++
++		list_for_each_entry(dev_entry, &cntrl_entry->dev_list, list) {
++			if (devfn == dev_entry->devfn) {
++				dev = dev_entry->dev;
++				goto found;
++			}
++		}
++	}
++found:
++	spin_unlock_irqrestore(&dev_data->lock, flags);
++
++	return dev;
++}
++
++int pciback_add_pci_dev(struct pciback_device *pdev, struct pci_dev *dev)
++{
++	struct controller_dev_data *dev_data = pdev->pci_dev_data;
++	struct controller_dev_entry *dev_entry;
++	struct controller_list_entry *cntrl_entry;
++	struct pci_controller *dev_controller = PCI_CONTROLLER(dev);
++	unsigned long flags;
++	int ret = 0, found = 0;
++
++	spin_lock_irqsave(&dev_data->lock, flags);
++
++	/* Look to see if we already have a domain:bus for this controller */
++	list_for_each_entry(cntrl_entry, &dev_data->list, list) {
++		if (cntrl_entry->controller == dev_controller) {
++			found = 1;
++			break;
++		}
++	}
++
++	if (!found) {
++		cntrl_entry = kmalloc(sizeof(*cntrl_entry), GFP_ATOMIC);
++		if (!cntrl_entry) {
++			ret =  -ENOMEM;
++			goto out;
++		}
++
++		cntrl_entry->controller = dev_controller;
++		cntrl_entry->next_devfn = PCI_DEVFN(0, 0);
++
++		cntrl_entry->domain = dev_data->next_domain;
++		cntrl_entry->bus = dev_data->next_bus++;
++		if (dev_data->next_bus > PCI_MAX_BUSSES) {
++			dev_data->next_domain++;
++			dev_data->next_bus = 0;
++		}
++
++		INIT_LIST_HEAD(&cntrl_entry->dev_list);
++
++		list_add_tail(&cntrl_entry->list, &dev_data->list);
++	}
++
++	if (PCI_SLOT(cntrl_entry->next_devfn) > PCI_MAX_SLOTS) {
++		/*
++		 * While it seems unlikely, this can actually happen if
++		 * a controller has P2P bridges under it.
++		 */
++		xenbus_dev_fatal(pdev->xdev, -ENOSPC, "Virtual bus %04x:%02x "
++				 "is full, no room to export %04x:%02x:%02x.%x",
++				 cntrl_entry->domain, cntrl_entry->bus,
++				 pci_domain_nr(dev->bus), dev->bus->number,
++				 PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
++		ret = -ENOSPC;
++		goto out;
++	}
++
++	dev_entry = kmalloc(sizeof(*dev_entry), GFP_ATOMIC);
++	if (!dev_entry) {
++		if (list_empty(&cntrl_entry->dev_list)) {
++			list_del(&cntrl_entry->list);
++			kfree(cntrl_entry);
++		}
++		ret = -ENOMEM;
++		goto out;
++	}
++
++	dev_entry->dev = dev;
++	dev_entry->devfn = cntrl_entry->next_devfn;
++
++	list_add_tail(&dev_entry->list, &cntrl_entry->dev_list);
++
++	cntrl_entry->next_devfn += PCI_DEVFN(1, 0);
++
++out:
++	spin_unlock_irqrestore(&dev_data->lock, flags);
++	return ret;
++}
++
++void pciback_release_pci_dev(struct pciback_device *pdev, struct pci_dev *dev)
++{
++	struct controller_dev_data *dev_data = pdev->pci_dev_data;
++	struct controller_list_entry *cntrl_entry;
++	struct controller_dev_entry *dev_entry = NULL;
++	struct pci_dev *found_dev = NULL;
++	unsigned long flags;
++
++	spin_lock_irqsave(&dev_data->lock, flags);
++
++	list_for_each_entry(cntrl_entry, &dev_data->list, list) {
++		if (cntrl_entry->controller != PCI_CONTROLLER(dev))
++			continue;
++
++		list_for_each_entry(dev_entry, &cntrl_entry->dev_list, list) {
++			if (dev_entry->dev == dev) {
++				found_dev = dev_entry->dev;
++				break;
++			}
++		}
++	}
++
++	if (!found_dev) {
++		spin_unlock_irqrestore(&dev_data->lock, flags);
++		return;
++	}
++
++	list_del(&dev_entry->list);
++	kfree(dev_entry);
++
++	if (list_empty(&cntrl_entry->dev_list)) {
++		list_del(&cntrl_entry->list);
++		kfree(cntrl_entry);
++	}
++
++	spin_unlock_irqrestore(&dev_data->lock, flags);
++	pcistub_put_pci_dev(found_dev);
++}
++
++int pciback_init_devices(struct pciback_device *pdev)
++{
++	struct controller_dev_data *dev_data;
++
++	dev_data = kmalloc(sizeof(*dev_data), GFP_KERNEL);
++	if (!dev_data)
++		return -ENOMEM;
++
++	spin_lock_init(&dev_data->lock);
++
++	INIT_LIST_HEAD(&dev_data->list);
++
++	/* Starting domain:bus numbers */
++	dev_data->next_domain = 0;
++	dev_data->next_bus = 0;
++
++	pdev->pci_dev_data = dev_data;
++
++	return 0;
++}
++
++static acpi_status write_xenbus_resource(struct acpi_resource *res, void *data)
++{
++	struct walk_info *info = data;
++	struct acpi_resource_address64 addr;
++	acpi_status status;
++	int i, len, err;
++	char str[32], tmp[3];
++	unsigned char *ptr, *buf;
++
++	status = acpi_resource_to_address64(res, &addr);
++
++	/* Do we care about this range?  Let's check. */
++	if (!ACPI_SUCCESS(status) ||
++	    !(addr.resource_type == ACPI_MEMORY_RANGE ||
++	      addr.resource_type == ACPI_IO_RANGE) ||
++	    !addr.address_length || addr.producer_consumer != ACPI_PRODUCER)
++		return AE_OK;
++
++	/*
++	 * Furthermore, we really only care to tell the guest about
++	 * address ranges that require address translation of some sort.
++	 */
++	if (!(addr.resource_type == ACPI_MEMORY_RANGE &&
++	      addr.info.mem.translation) &&
++	    !(addr.resource_type == ACPI_IO_RANGE &&
++	      addr.info.io.translation))
++		return AE_OK;
++	   
++	/* Store the resource in xenbus for the guest */
++	len = snprintf(str, sizeof(str), "root-%d-resource-%d",
++		       info->root_num, info->resource_count);
++	if (unlikely(len >= (sizeof(str) - 1)))
++		return AE_OK;
++
++	buf = kzalloc((sizeof(*res) * 2) + 1, GFP_KERNEL);
++	if (!buf)
++		return AE_OK;
++
++	/* Clean out resource_source */
++	res->data.address64.resource_source.index = 0xFF;
++	res->data.address64.resource_source.string_length = 0;
++	res->data.address64.resource_source.string_ptr = NULL;
++
++	ptr = (unsigned char *)res;
++
++	/* Turn the acpi_resource into an ASCII byte stream */
++	for (i = 0; i < sizeof(*res); i++) {
++		snprintf(tmp, sizeof(tmp), "%02x", ptr[i]);
++		strncat(buf, tmp, 2);
++	}
++
++	err = xenbus_printf(XBT_NIL, info->pdev->xdev->nodename,
++			    str, "%s", buf);
++
++	if (!err)
++		info->resource_count++;
++
++	kfree(buf);
++
++	return AE_OK;
++}
++
++int pciback_publish_pci_roots(struct pciback_device *pdev,
++			      publish_pci_root_cb publish_root_cb)
++{
++	struct controller_dev_data *dev_data = pdev->pci_dev_data;
++	struct controller_list_entry *cntrl_entry;
++	int i, root_num, len, err = 0;
++	unsigned int domain, bus;
++	char str[64];
++	struct walk_info info;
++
++	spin_lock(&dev_data->lock);
++
++	list_for_each_entry(cntrl_entry, &dev_data->list, list) {
++		/* First publish all the domain:bus info */
++		err = publish_root_cb(pdev, cntrl_entry->domain,
++				      cntrl_entry->bus);
++		if (err)
++			goto out;
++
++		/*
++ 		 * Now figure out which root-%d this belongs to
++		 * so we can associate resources with it.
++		 */
++		err = xenbus_scanf(XBT_NIL, pdev->xdev->nodename,
++				   "root_num", "%d", &root_num);
++
++		if (err != 1)
++			goto out;
++
++		for (i = 0; i < root_num; i++) {
++			len = snprintf(str, sizeof(str), "root-%d", i);
++			if (unlikely(len >= (sizeof(str) - 1))) {
++				err = -ENOMEM;
++				goto out;
++			}
++
++			err = xenbus_scanf(XBT_NIL, pdev->xdev->nodename,
++					   str, "%x:%x", &domain, &bus);
++			if (err != 2)
++				goto out;
++
++			/* Is this the one we just published? */
++			if (domain == cntrl_entry->domain &&
++			    bus == cntrl_entry->bus)
++				break;
++		}
++
++		if (i == root_num)
++			goto out;
++
++		info.pdev = pdev;
++		info.resource_count = 0;
++		info.root_num = i;
++
++		/* Let ACPI do the heavy lifting on decoding resources */
++		acpi_walk_resources(cntrl_entry->controller->acpi_handle,
++				    METHOD_NAME__CRS, write_xenbus_resource,
++				    &info);
++
++		/* No resouces.  OK.  On to the next one */
++		if (!info.resource_count)
++			continue;
++
++		/* Store the number of resources we wrote for this root-%d */
++		len = snprintf(str, sizeof(str), "root-%d-resources", i);
++		if (unlikely(len >= (sizeof(str) - 1))) {
++			err = -ENOMEM;
++			goto out;
++		}
++
++		err = xenbus_printf(XBT_NIL, pdev->xdev->nodename, str,
++				    "%d", info.resource_count);
++		if (err)
++			goto out;
++	}
++
++	/* Finally, write some magic to synchronize with the guest. */
++	len = snprintf(str, sizeof(str), "root-resource-magic");
++	if (unlikely(len >= (sizeof(str) - 1))) {
++		err = -ENOMEM;
++		goto out;
++	}
++
++	err = xenbus_printf(XBT_NIL, pdev->xdev->nodename, str,
++			    "%lx", (sizeof(struct acpi_resource) * 2) + 1);
++
++out:
++	spin_unlock(&dev_data->lock);
++
++	return err;
++}
++
++void pciback_release_devices(struct pciback_device *pdev)
++{
++	struct controller_dev_data *dev_data = pdev->pci_dev_data;
++	struct controller_list_entry *cntrl_entry, *c;
++	struct controller_dev_entry *dev_entry, *d;
++
++	list_for_each_entry_safe(cntrl_entry, c, &dev_data->list, list) {
++		list_for_each_entry_safe(dev_entry, d,
++					 &cntrl_entry->dev_list, list) {
++			list_del(&dev_entry->list);
++			pcistub_put_pci_dev(dev_entry->dev);
++			kfree(dev_entry);
++		}
++		list_del(&cntrl_entry->list);
++		kfree(cntrl_entry);
++	}
++
++	kfree(dev_data);
++	pdev->pci_dev_data = NULL;
++}
+diff -r e5b50dd9fcf5 -r 93a955c2bebb drivers/xen/pcifront/pci_op.c
+--- a/linux-2.6-xen-sparse/drivers/xen/pcifront/pci_op.c	Tue Jun 12 11:15:20 2007 +0100
++++ b/linux-2.6-xen-sparse/drivers/xen/pcifront/pci_op.c	Tue Jun 12 11:36:58 2007 +0100
+@@ -14,6 +14,122 @@
+ 
+ static int verbose_request = 0;
+ module_param(verbose_request, int, 0644);
++
++#ifdef __ia64__
++static void pcifront_init_sd(struct pcifront_sd *sd,
++			     unsigned int domain, unsigned int bus,
++			     struct pcifront_device *pdev)
++{
++	int err, i, j, k, len, root_num, res_count;
++	struct acpi_resource res;
++	unsigned int d, b, byte;
++	unsigned long magic;
++	char str[64], tmp[3];
++	unsigned char *buf, *bufp;
++	u8 *ptr;
++
++	memset(sd, 0, sizeof(*sd));
++
++	sd->segment = domain;
++	sd->node = -1;	/* Revisit for NUMA */
++	sd->platform_data = pdev;
++
++	/* Look for resources for this controller in xenbus. */
++	err = xenbus_scanf(XBT_NIL, pdev->xdev->otherend, "root_num",
++			   "%d", &root_num);
++	if (err != 1)
++		return;
++
++	for (i = 0; i < root_num; i++) {
++		len = snprintf(str, sizeof(str), "root-%d", i);
++		if (unlikely(len >= (sizeof(str) - 1)))
++			return;
++
++		err = xenbus_scanf(XBT_NIL, pdev->xdev->otherend,
++				   str, "%x:%x", &d, &b);
++		if (err != 2)
++			return;
++
++		if (d == domain && b == bus)
++			break;
++	}
++
++	if (i == root_num)
++		return;
++
++	len = snprintf(str, sizeof(str), "root-resource-magic");
++
++	err = xenbus_scanf(XBT_NIL, pdev->xdev->otherend,
++			   str, "%lx", &magic);
++
++	if (err != 1)
++		return; /* No resources, nothing to do */
++
++	if (magic != (sizeof(res) * 2) + 1) {
++		printk(KERN_WARNING "pcifront: resource magic mismatch\n");
++		return;
++	}
++
++	len = snprintf(str, sizeof(str), "root-%d-resources", i);
++	if (unlikely(len >= (sizeof(str) - 1)))
++		return;
++
++	err = xenbus_scanf(XBT_NIL, pdev->xdev->otherend,
++			   str, "%d", &res_count);
++
++	if (err != 1)
++		return; /* No resources, nothing to do */
++
++	sd->window = kzalloc(sizeof(*sd->window) * res_count, GFP_KERNEL);
++	if (!sd->window)
++		return;
++
++	/* magic is also the size of the byte stream in xenbus */
++	buf = kmalloc(magic, GFP_KERNEL);
++	if (!buf) {
++		kfree(sd->window);
++		sd->window = NULL;
++		return;
++	}
++
++	/* Read the resources out of xenbus */
++	for (j = 0; j < res_count; j++) {
++		memset(&res, 0, sizeof(res));
++		memset(buf, 0, magic);
++
++		len = snprintf(str, sizeof(str), "root-%d-resource-%d", i, j);
++		if (unlikely(len >= (sizeof(str) - 1)))
++			return;
++
++		err = xenbus_scanf(XBT_NIL, pdev->xdev->otherend, str,
++				   "%s", buf);
++		if (err != 1) {
++			printk(KERN_WARNING "pcifront: error reading "
++			       "resource %d on bus %04x:%02x\n",
++			       j, domain, bus);
++			continue;
++		}
++
++		bufp = buf;
++		ptr = (u8 *)&res;
++		memset(tmp, 0, sizeof(tmp));
++
++		/* Copy ASCII byte stream into structure */
++		for (k = 0; k < magic - 1; k += 2) {
++			memcpy(tmp, bufp, 2);
++			bufp += 2;
++
++			sscanf(tmp, "%02x", &byte);
++			*ptr = byte;
++			ptr++;
++		}
++
++		xen_add_resource(sd, domain, bus, &res);
++		sd->windows++;
++	}
++	kfree(buf);
++}
++#endif
+ 
+ static int errno_to_pcibios_err(int errno)
+ {
+@@ -207,7 +323,7 @@ int pcifront_scan_root(struct pcifront_d
+ 		err = -ENOMEM;
+ 		goto err_out;
+ 	}
+-	pcifront_init_sd(sd, domain, pdev);
++	pcifront_init_sd(sd, domain, bus, pdev);
+ 
+ 	b = pci_scan_bus_parented(&pdev->xdev->dev, bus,
+ 				  &pcifront_bus_ops, sd);
+@@ -217,6 +333,8 @@ int pcifront_scan_root(struct pcifront_d
+ 		err = -ENOMEM;
+ 		goto err_out;
+ 	}
++
++	pcifront_setup_root_resources(b, sd);
+ 	bus_entry->bus = b;
+ 
+ 	list_add(&bus_entry->list, &pdev->root_buses);
+diff -r e5b50dd9fcf5 -r 93a955c2bebb include/xen/pcifront.h
+--- a/linux-2.6-xen-sparse/include/xen/pcifront.h	Tue Jun 12 11:15:20 2007 +0100
++++ b/linux-2.6-xen-sparse/include/xen/pcifront.h	Tue Jun 12 11:36:58 2007 +0100
+@@ -26,7 +26,8 @@ pcifront_get_pdev(struct pcifront_sd *sd
+ 	return sd->pdev;
+ }
+ 
+-static inline void pcifront_init_sd(struct pcifront_sd *sd, int domain,
++static inline void pcifront_init_sd(struct pcifront_sd *sd,
++				    unsigned int domain, unsigned int bus,
+ 				    struct pcifront_device *pdev)
+ {
+ 	sd->domain = domain;
+@@ -45,10 +46,21 @@ static inline int pci_proc_domain(struct
+ }
+ #endif /* CONFIG_PCI_DOMAINS */
+ 
++static inline void pcifront_setup_root_resources(struct pci_bus *bus,
++						 struct pcifront_sd *sd)
++{
++}
++
+ #else /* __ia64__ */
+ 
++#include <linux/acpi.h>
+ #include <asm/pci.h>
+ #define pcifront_sd pci_controller
++
++extern void xen_add_resource(struct pci_controller *, unsigned int,
++			     unsigned int, struct acpi_resource *);
++extern void xen_pcibios_setup_root_windows(struct pci_bus *,
++					   struct pci_controller *);
+ 
+ static inline struct pcifront_device *
+ pcifront_get_pdev(struct pcifront_sd *sd)
+@@ -56,16 +68,10 @@ pcifront_get_pdev(struct pcifront_sd *sd
+ 	return (struct pcifront_device *)sd->platform_data;
+ }
+ 
+-static inline void pcifront_init_sd(struct pcifront_sd *sd, int domain,
+-				    struct pcifront_device *pdev)
++static inline void pcifront_setup_root_resources(struct pci_bus *bus,
++						 struct pcifront_sd *sd)
+ {
+-	sd->segment = domain;
+-	sd->acpi_handle = NULL;
+-	sd->iommu = NULL;
+-	sd->node = -1;
+-	sd->windows = 0;
+-	sd->window = NULL;
+-	sd->platform_data = pdev;
++	xen_pcibios_setup_root_windows(bus, sd);
+ }
+ 
+ #endif /* __ia64__ */
diff -r 7ba52aa72ae5 linux-55-a62cfa35d3b5
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/linux-55-a62cfa35d3b5	Tue Sep 11 12:33:14 2007 -0600
@@ -0,0 +1,60 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1181684903 21600
+# Node ID a62cfa35d3b504d5ee1acd4a409a6fb3ee45a6bd
+# Parent  bab3dd910801edf8763d55e0c8133bc08d1cbcfd
+[IA64] Add HYPERVISOR_add_io_space
+
+And call it to register new I/O spaces with Xen
+
+Signed-off-by: Alex Williamson <alex.williamson@hp.com>
+linux-2.6.18-xen changeset: 55:a62cfa35d3b504d5ee1acd4a409a6fb3ee45a6bd
+linux-2.6.18-xen date: Tue Jun 12 15:48:23 2007 -0600
+
+diff -r bab3dd910801 -r a62cfa35d3b5 arch/ia64/pci/pci.c
+--- a/linux-2.6-xen-sparse/arch/ia64/pci/pci.c	Tue Jun 12 15:43:27 2007 -0600
++++ b/linux-2.6-xen-sparse/arch/ia64/pci/pci.c	Tue Jun 12 15:48:23 2007 -0600
+@@ -164,6 +164,11 @@ new_space (u64 phys_base, int sparse)
+ 	i = num_io_spaces++;
+ 	io_space[i].mmio_base = mmio_base;
+ 	io_space[i].sparse = sparse;
++
++#ifdef CONFIG_XEN
++	if (is_initial_xendomain())
++		HYPERVISOR_add_io_space(phys_base, sparse, i);
++#endif
+ 
+ 	return i;
+ }
+diff -r bab3dd910801 -r a62cfa35d3b5 include/asm-ia64/hypercall.h
+--- a/linux-2.6-xen-sparse/include/asm-ia64/hypercall.h	Tue Jun 12 15:43:27 2007 -0600
++++ b/linux-2.6-xen-sparse/include/asm-ia64/hypercall.h	Tue Jun 12 15:48:23 2007 -0600
+@@ -387,6 +387,15 @@ xencomm_arch_hypercall_perfmon_op(un
+ {
+ 	return _hypercall4(int, ia64_dom0vp_op,
+ 			   IA64_DOM0VP_perfmon, cmd, arg, count);
++}
++
++static inline int
++HYPERVISOR_add_io_space(unsigned long phys_base,
++			unsigned long sparse,
++			unsigned long space_number)
++{
++	return _hypercall4(int, ia64_dom0vp_op, IA64_DOM0VP_add_io_space,
++			   phys_base, sparse, space_number);
+ }
+ 
+ // for balloon driver
+diff -r bab3dd910801 -r a62cfa35d3b5 include/xen/interface/arch-ia64.h
+--- a/xen/include/public/arch-ia64.h	Tue Jun 12 15:43:27 2007 -0600
++++ b/xen/include/public/arch-ia64.h	Tue Jun 12 15:48:23 2007 -0600
+@@ -531,6 +531,9 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_conte
+ /* get fpswa revision */
+ #define IA64_DOM0VP_fpswa_revision      10
+ 
++/* Add an I/O port space range */
++#define IA64_DOM0VP_add_io_space        11
++
+ // flags for page assignement to pseudo physical address space
+ #define _ASSIGN_readonly                0
+ #define ASSIGN_readonly                 (1UL << _ASSIGN_readonly)
diff -r 7ba52aa72ae5 linux-56-1483ef74511b
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/linux-56-1483ef74511b	Tue Sep 11 12:33:29 2007 -0600
@@ -0,0 +1,101 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1181685161 21600
+# Node ID 1483ef74511b1c9819212aac9f67232a66f71adf
+# Parent  a62cfa35d3b504d5ee1acd4a409a6fb3ee45a6bd
+[IA64] xencomm update for acm interface change
+
+Changed by c/s 15189:96915ca8d5f2 of xen-unstable.h
+
+Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
+linux-2.6.18-xen changeset: 56:1483ef74511b1c9819212aac9f67232a66f71adf
+linux-2.6.18-xen date: Tue Jun 12 15:52:41 2007 -0600
+
+diff -r a62cfa35d3b5 -r 1483ef74511b arch/ia64/xen/xcom_privcmd.c
+--- a/linux-2.6-xen-sparse/arch/ia64/xen/xcom_privcmd.c	Tue Jun 12 15:48:23 2007 -0600
++++ b/linux-2.6-xen-sparse/arch/ia64/xen/xcom_privcmd.c	Tue Jun 12 15:52:41 2007 -0600
+@@ -338,40 +338,39 @@ static int
+ static int
+ xencomm_privcmd_acm_op(privcmd_hypercall_t *hypercall)
+ {
+-	int cmd = hypercall->arg[0];
+-	void __user *arg = (void __user *)hypercall->arg[1];
++	void __user *arg = (void __user *)hypercall->arg[0];
++	xen_acmctl_t kern_arg;
+ 	struct xencomm_handle *op_desc;
+ 	struct xencomm_handle *desc = NULL;
+ 	int ret;
+ 
+-	switch (cmd) {
+-	case ACMOP_getssid:
+-	{
+-		struct acm_getssid kern_arg;
+-
+-		if (copy_from_user(&kern_arg, arg, sizeof (kern_arg)))
++	if (copy_from_user(&kern_arg, arg, sizeof(kern_arg)))
++		return -EFAULT;
++	if (kern_arg.interface_version != ACM_INTERFACE_VERSION)
++		return -ENOSYS;
++	
++	switch (kern_arg.cmd) {
++	case ACMOP_getssid: {
++		op_desc = xencomm_create_inline(&kern_arg);
++
++		ret = xencomm_create(
++			xen_guest_handle(kern_arg.u.getssid.ssidbuf),
++			kern_arg.u.getssid.ssidbuf_size, &desc, GFP_KERNEL);
++		if (ret)
++			return ret;
++
++		set_xen_guest_handle(kern_arg.u.getssid.ssidbuf, (void *)desc);
++
++		ret = xencomm_arch_hypercall_acm_op(op_desc);
++
++		xencomm_free(desc);
++
++		if (copy_to_user(arg, &kern_arg, sizeof(kern_arg)))
+ 			return -EFAULT;
+-
+-		op_desc = xencomm_create_inline(&kern_arg);
+-
+-		ret = xencomm_create(xen_guest_handle(kern_arg.ssidbuf),
+-		                     kern_arg.ssidbuf_size, &desc, GFP_KERNEL);
+-		if (ret)
+-			return ret;
+-
+-		set_xen_guest_handle(kern_arg.ssidbuf, (void *)desc);
+-
+-		ret = xencomm_arch_hypercall_acm_op(cmd, op_desc);
+-
+-		xencomm_free(desc);
+-
+-		if (copy_to_user(arg, &kern_arg, sizeof (kern_arg)))
+-			return -EFAULT;
+-
+-		return ret;
+-	}
+-	default:
+-		printk("%s: unknown acm_op cmd %d\n", __func__, cmd);
++		return ret;
++	}
++	default:
++		printk("%s: unknown acm_op cmd %d\n", __func__, kern_arg.cmd);
+ 		return -ENOSYS;
+ 	}
+ 
+diff -r a62cfa35d3b5 -r 1483ef74511b include/asm-ia64/hypercall.h
+--- a/linux-2.6-xen-sparse/include/asm-ia64/hypercall.h	Tue Jun 12 15:48:23 2007 -0600
++++ b/linux-2.6-xen-sparse/include/asm-ia64/hypercall.h	Tue Jun 12 15:52:41 2007 -0600
+@@ -157,9 +157,9 @@ xencomm_arch_hypercall_event_channel_op(
+ }
+ 
+ static inline int
+-xencomm_arch_hypercall_acm_op(unsigned int cmd, struct xencomm_handle *arg)
+-{
+-	return _hypercall2(int, acm_op, cmd, arg);
++xencomm_arch_hypercall_acm_op(struct xencomm_handle *arg)
++{
++	return _hypercall1(int, acm_op, arg);
+ }
+ 
+ static inline int
diff -r 7ba52aa72ae5 linux-61-452c5d4a5537
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/linux-61-452c5d4a5537	Tue Sep 11 12:33:45 2007 -0600
@@ -0,0 +1,37 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1181920189 21600
+# Node ID 452c5d4a55370c3c3a6cb6740b45be911ca3741e
+# Parent  b492ac038d613212da3ee16646168b56ef8833cc
+[IA64] Default to Controller PCI backend
+
+Signed-off-by: Alex Williamson <alex.williamson@hp.com>
+linux-2.6.18-xen changeset: 61:452c5d4a55370c3c3a6cb6740b45be911ca3741e
+linux-2.6.18-xen date: Fri Jun 15 09:09:49 2007 -0600
+
+diff -r b492ac038d61 -r 452c5d4a5537 buildconfigs/linux-defconfig_xen0_ia64
+--- a/buildconfigs/linux-defconfig_xen0_ia64	Thu Jun 14 14:23:21 2007 -0600
++++ b/buildconfigs/linux-defconfig_xen0_ia64	Fri Jun 15 09:09:49 2007 -0600
+@@ -1666,7 +1666,8 @@ CONFIG_XEN_PCIDEV_BACKEND=y
+ CONFIG_XEN_PCIDEV_BACKEND=y
+ # CONFIG_XEN_PCIDEV_BACKEND_VPCI is not set
+ # CONFIG_XEN_PCIDEV_BACKEND_PASS is not set
+-CONFIG_XEN_PCIDEV_BACKEND_SLOT=y
++# CONFIG_XEN_PCIDEV_BACKEND_SLOT is not set
++CONFIG_XEN_PCIDEV_BACKEND_CONTROLLER=y
+ # CONFIG_XEN_PCIDEV_BE_DEBUG is not set
+ CONFIG_XEN_TPMDEV_BACKEND=m
+ CONFIG_XEN_BLKDEV_FRONTEND=y
+diff -r b492ac038d61 -r 452c5d4a5537 buildconfigs/linux-defconfig_xen_ia64
+--- a/buildconfigs/linux-defconfig_xen_ia64	Thu Jun 14 14:23:21 2007 -0600
++++ b/buildconfigs/linux-defconfig_xen_ia64	Fri Jun 15 09:09:49 2007 -0600
+@@ -1666,7 +1666,8 @@ CONFIG_XEN_PCIDEV_BACKEND=y
+ CONFIG_XEN_PCIDEV_BACKEND=y
+ # CONFIG_XEN_PCIDEV_BACKEND_VPCI is not set
+ # CONFIG_XEN_PCIDEV_BACKEND_PASS is not set
+-CONFIG_XEN_PCIDEV_BACKEND_SLOT=y
++# CONFIG_XEN_PCIDEV_BACKEND_SLOT is not set
++CONFIG_XEN_PCIDEV_BACKEND_CONTROLLER=y
+ # CONFIG_XEN_PCIDEV_BE_DEBUG is not set
+ CONFIG_XEN_TPMDEV_BACKEND=m
+ CONFIG_XEN_BLKDEV_FRONTEND=y
diff -r 7ba52aa72ae5 series
--- a/series	Fri Sep 07 15:49:00 2007 +0100
+++ b/series	Tue Sep 11 13:40:54 2007 -0600
@@ -35,6 +35,7 @@ 15080-089696e0c603
 15080-089696e0c603
 15082-0fd2bf14f38a
 15083-b9da101ed945
+15096-d4f59e652078
 15128-f6928d636999
 15130-a40967e39652
 15132-17f6163ae930
@@ -147,6 +148,14 @@ 15289-8ad38aaaeb89
 15289-8ad38aaaeb89
 15290-56548d9a7ba7
 15291-1feb91894e11
+15331-b46c2ff6dfb0
+15348-51f5bea7b0d8
+15349-71377eab1874
+15265-634b7f7f8584
+15353-601509daabfc
+15364-1623f5f5094f
+15365-33cc64dcaead
+15366-fd0103b55504
 15373-58b6223074af
 15374-b1eb43f94a3a
 15375-342c85cfd00b
@@ -248,6 +257,9 @@ 15524-26eef8426110
 15524-26eef8426110
 15528-637ff26be6ff
 15535-c6491ed12f84
+15555-38d061886873
+15557-2a5b463f2e8d
+15579-f536eb8576ee
 15583-b27add01a929
 15584-48c8244c47c7
 15588-0aa2a954a6d1
@@ -277,7 +289,11 @@ linux-34-0301c1fd8c0d
 linux-34-0301c1fd8c0d
 linux-35-85b046c1da18
 linux-42-c09686d2bbff
+linux-46-93a955c2bebb
 linux-47-33c3009e73ec
+linux-55-a62cfa35d3b5
+linux-56-1483ef74511b
+linux-61-452c5d4a5537
 linux-65-87bb8705768a
 linux-66-496e3157a35c
 linux-68-cadc6d58a9e6
@@ -345,5 +361,8 @@ 15830-32f331858d75
 15830-32f331858d75
 15832-f779ee15c553
 15833-05950e909ba6
+15850-6644d8486266
+15852-f88eea67a469
 linux-191-1e2284d885fb
 linux-192-5ce5bd383ea9
+ia64-sal-get-state-info

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue

[Kouya Shimura]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 2994 bytes --]

Alex Williamson writes:
 >    Other ia64'ers, please speak up if there's something else missing.

Hi Keir and Alex,

Here's a list of additional(missing) patches for IA64:

Must have fixes for HVM:
http://xenbits.xensource.com/xen-unstable.hg?rev/8924215a5f95
15086-8924215a5f95 - fix VHPT insertion
http://xenbits.xensource.com/xen-unstable.hg?rev/31be207e005e
15113-31be207e005e - fix VHPT walk
http://xenbits.xensource.com/xen-unstable.hg?rev/7812598f65be
15115-7812598f65be - fix xen crash (vpd allocation)
http://xenbits.xensource.com/xen-unstable.hg?rev/d6309cfd1fdd
15116-d6309cfd1fdd - fix resource allocation (rid)
http://xenbits.xensource.com/xen-unstable.hg?rev/fd72e71de51a
15119-fd72e71de51a - fix Windows crash
http://xenbits.xensource.com/xen-unstable.hg?rev/afb27041a2ce
15122-afb27041a2ce - fix Windows crash
http://xenbits.xensource.com/xen-unstable.hg?rev/d30576123892
15307-d30576123892 - fix resource allocation (vpd size)
http://xenbits.xensource.com/xen-unstable.hg?rev/466f71b1e831
*15311-466f71b1e831 - fix crash of VTI domain
http://xenbits.xensource.com/xen-unstable.hg?rev/2fd72ec88a9a
15341-2fd72ec88a9a - fix boot of VTI domain

Must have fixes:
http://xenbits.xensource.com/xen-unstable.hg?rev/34f285b57b87
15568-34f285b57b87 - fix soft lock up 
http://xenbits.xensource.com/xen-unstable.hg?rev/9cd309378326
*15655-9cd309378326 - fix boot on NUMA systems
http://xenbits.xensource.com/xen-unstable.hg?rev/2796311c6a55
15742-2796311c6a55 - fix boot related MCA

Must have fixes for save/restore:
http://xenbits.xensource.com/xen-unstable.hg?rev/204046d99562
15090-204046d99562 - fix time_resume()
http://xenbits.xensource.com/xen-unstable.hg?rev/63263d715d43
15093-63263d715d43 - fix vcpu hotplug
http://xenbits.xensource.com/xen-unstable.hg?rev/1a010d9444ba
15103-1a010d9444ba - prevent softlock up message
http://xenbits.xensource.com/xen-unstable.hg?rev/8b9637467068
15107-8b9637467068 - fix save/restore

An attached patch can be applied to xen-3.1-testing.pq.hg.
Patches with an asterisk above are modified for xen-3.1-testing.hg.

Thanks,
Kouya

Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>

 15086-8924215a5f95 |   80 ++++++++++++++++++++++++
 15090-204046d99562 |  103 +++++++++++++++++++++++++++++++
 15093-63263d715d43 |  141 +++++++++++++++++++++++++++++++++++++++++++
 15103-1a010d9444ba |   33 ++++++++++
 15107-8b9637467068 |  172 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 15113-31be207e005e |  170 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 15115-7812598f65be |   28 ++++++++
 15116-d6309cfd1fdd |   31 +++++++++
 15119-fd72e71de51a |  101 +++++++++++++++++++++++++++++++
 15122-afb27041a2ce |   81 ++++++++++++++++++++++++
 15307-d30576123892 |   25 +++++++
 15311-466f71b1e831 |   82 +++++++++++++++++++++++++
 15341-2fd72ec88a9a |   48 ++++++++++++++
 15568-34f285b57b87 |   69 +++++++++++++++++++++
 15655-9cd309378326 |   46 ++++++++++++++
 15742-2796311c6a55 |   23 +++++++
 16 files changed, 1233 insertions(+)


[-- Attachment #2: xen-3.1.1-ia64-add.pq.patch --]
[-- Type: text/plain, Size: 46792 bytes --]

# HG changeset patch
# User Kouya Shimura <kouya@jp.fujitsu.com>
# Date 1189576945 -32400
# Node ID 41c9c4fcf3586947e3e79ad340da9d4ba7556294
# Parent  7ba52aa72ae5c0834df9570251ce7bf806a20a1d
Additional fixes for IA64.

diff -r 7ba52aa72ae5 -r 41c9c4fcf358 15086-8924215a5f95
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15086-8924215a5f95	Wed Sep 12 15:02:25 2007 +0900
@@ -0,0 +1,80 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1178222479 21600
+# Node ID 8924215a5f952d3127d24203a14e4b8d7e642a69
+# Parent  6cf6f49f26abd61e011a6513512478d7d2a0af70
+[IA64] Always insert entry to VHPT's head, or double TLB miss occurs.
+
+Always insert entry to VHPT head, or TLB miss will occur again although
+the translation exists in its collision chain.
+
+Signed-off-by: Zhang xiantao <xiantao.zhang@intel.com>
+Signed-off-by: Anthony Xu <anthony.xu@intel.com>
+xen-unstable changeset: 15086:8924215a5f952d3127d24203a14e4b8d7e642a69
+xen-unstable date: Thu May 03 14:01:19 2007 -0600
+
+diff -r 6cf6f49f26ab -r 8924215a5f95 xen/arch/ia64/vmx/vtlb.c
+--- a/xen/arch/ia64/vmx/vtlb.c	Thu May 03 13:55:28 2007 -0600
++++ b/xen/arch/ia64/vmx/vtlb.c	Thu May 03 14:01:19 2007 -0600
+@@ -150,33 +150,41 @@ static void vmx_vhpt_insert(thash_cb_t *
+     tag = ia64_ttag(ifa);
+     cch = head;
+     while (cch) {    
+-        if (INVALID_VHPT(cch)) {
+-            len = cch->len;
+-            cch->page_flags = pte;
+-            cch->len = len;
+-            cch->itir = rr.ps << 2;
+-            cch->etag = tag;
+-            return;
+-        }
++        if (INVALID_VHPT(cch))
++            break;
+         cch = cch->next;
+     }
+-
+-    if(head->len>=MAX_CCN_DEPTH){
+-        thash_recycle_cch(hcb, head);
+-        cch = cch_alloc(hcb);
++    if (cch) {
++        if (cch == head) {
++            len = head->len;
++        } else {
++            local_irq_disable();
++            cch->page_flags = head->page_flags;
++            cch->itir = head->itir;
++            cch->etag  = head->etag;
++            len = head->len;
++            local_irq_enable();
++        }
+     }
+     else{
+-        cch = __alloc_chain(hcb);
+-    }
+-    local_irq_disable();
+-    *cch = *head;
++        if (head->len >= MAX_CCN_DEPTH) {
++            thash_recycle_cch(hcb, head);
++            cch = cch_alloc(hcb);
++        } else {
++            cch = __alloc_chain(hcb);
++        }
++        local_irq_disable();
++        *cch = *head;
++        head->next = cch;
++        len = cch->len+1;
++        cch->len = 0;
++        local_irq_enable();
++    }
++
+     head->page_flags=pte;
++    head->len = len;
+     head->itir = rr.ps << 2;
+     head->etag=tag;
+-    head->next = cch;
+-    head->len = cch->len+1;
+-    cch->len = 0;
+-    local_irq_enable();
+     return;
+ }
+ 
diff -r 7ba52aa72ae5 -r 41c9c4fcf358 15090-204046d99562
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15090-204046d99562	Wed Sep 12 15:02:25 2007 +0900
@@ -0,0 +1,103 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1178223699 21600
+# Node ID 204046d995621fe88649daaaffa32ee42c18cdd4
+# Parent  a141484a91d0c420f1227e0914d61aaf74fb406b
+[IA64] Fix time_resume()
+
+Add missing exclusion in time_resume() and steal time accounting
+reinitialization after resume.
+
+Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
+xen-unstable changeset: 15090:204046d995621fe88649daaaffa32ee42c18cdd4
+xen-unstable date: Thu May 03 14:21:39 2007 -0600
+
+diff -r a141484a91d0 -r 204046d99562 linux-2.6-xen-sparse/arch/ia64/kernel/time.c
+--- a/linux-2.6-xen-sparse/arch/ia64/kernel/time.c	Thu May 03 14:14:41 2007 -0600
++++ b/linux-2.6-xen-sparse/arch/ia64/kernel/time.c	Thu May 03 14:21:39 2007 -0600
+@@ -267,6 +267,62 @@ static void init_missing_ticks_accountin
+ 	per_cpu(processed_stolen_time, cpu) = runstate->time[RUNSTATE_runnable]
+ 					    + runstate->time[RUNSTATE_offline];
+ }
++
++static int xen_ia64_settimefoday_after_resume;
++
++static int __init __xen_ia64_settimeofday_after_resume(char *str)
++{
++	xen_ia64_settimefoday_after_resume = 1;
++	return 1;
++}
++
++__setup("xen_ia64_settimefoday_after_resume",
++	 __xen_ia64_settimeofday_after_resume);
++
++/* Called after suspend, to resume time.  */
++void
++time_resume(void)
++{
++	unsigned int cpu;
++	
++	/* Just trigger a tick.  */
++	ia64_cpu_local_tick();
++
++	if (xen_ia64_settimefoday_after_resume) {
++		/* do_settimeofday() resets timer interplator */
++		struct timespec xen_time;
++		int ret;
++		efi_gettimeofday(&xen_time);
++
++		ret = do_settimeofday(&xen_time);
++		WARN_ON(ret);
++	} else {
++#if 0
++		/* adjust EFI time */
++		struct timespec my_time = CURRENT_TIME;
++		struct timespec xen_time;
++		static timespec diff;
++		struct xen_domctl domctl;
++		int ret;
++
++		efi_gettimeofday(&xen_time);
++		diff = timespec_sub(&xen_time, &my_time);
++		domctl.cmd = XEN_DOMCTL_settimeoffset;
++		domctl.domain = DOMID_SELF;
++		domctl.u.settimeoffset.timeoffset_seconds = diff.tv_sec;
++		ret = HYPERVISOR_domctl_op(&domctl);
++		WARN_ON(ret);
++#endif
++		/* Time interpolator remembers the last timer status.
++		   Forget it */
++		write_seqlock_irq(&xtime_lock);
++		time_interpolator_reset();
++		write_sequnlock_irq(&xtime_lock);
++	}
++
++	for_each_online_cpu(cpu)
++		init_missing_ticks_accounting(cpu);
++}
+ #else
+ #define init_missing_ticks_accounting(cpu) do {} while (0)
+ #endif
+diff -r a141484a91d0 -r 204046d99562 linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c
+--- a/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c	Thu May 03 14:14:41 2007 -0600
++++ b/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c	Thu May 03 14:21:39 2007 -0600
+@@ -863,19 +863,6 @@ direct_remap_pfn_range(struct vm_area_st
+ }
+ 
+ 
+-/* Called after suspend, to resume time.  */
+-void
+-time_resume(void)
+-{
+-	extern void ia64_cpu_local_tick(void);
+-
+-	/* Just trigger a tick.  */
+-	ia64_cpu_local_tick();
+-
+-	/* Time interpolator remembers the last timer status.  Forget it */
+-	time_interpolator_reset();
+-}
+-
+ ///////////////////////////////////////////////////////////////////////////
+ // expose p2m table
+ #ifdef CONFIG_XEN_IA64_EXPOSE_P2M
diff -r 7ba52aa72ae5 -r 41c9c4fcf358 15093-63263d715d43
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15093-63263d715d43	Wed Sep 12 15:02:25 2007 +0900
@@ -0,0 +1,141 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1178224706 21600
+# Node ID 63263d715d4309e7bccdd43d0f9c5c49be8c52ac
+# Parent  f8aede89c7065a5376a544c0b9bd49d4b22ac954
+[IA64] Fix vcpu hotplug
+
+When domain is saved and restored, the following message is printed out.
+bind_ipi_to_irqhandler()/bind_virq_to_irqhandler() should be called
+in process context.  Move the call from cpu_init() to __cpu_init() like x86.
+
+BUG: sleeping function called from invalid context at /src1/yamahata/hg/xen/ia64
+/my150/compile/test-0/xen-ia64-unstable.hg/linux-2.6.18-xen/mm/slab.c:2901
+in_atomic():0, irqs_disabled():1
+
+Call Trace:
+ [<a00000010001b190>] show_stack+0x50/0xa0
+                                sp=e0000000004ff8b0 bsp=e0000000004f9358
+ [<a00000010001b210>] dump_stack+0x30/0x60
+                                sp=e0000000004ffa80 bsp=e0000000004f9340
+ [<a000000100070f40>] __might_sleep+0x2c0/0x2e0
+                                sp=e0000000004ffa80 bsp=e0000000004f9318
+ [<a00000010012c230>] __kmalloc+0xb0/0x320
+                                sp=e0000000004ffa90 bsp=e0000000004f92e0
+ [<a0000001001a98d0>] proc_create+0x110/0x1c0
+                                sp=e0000000004ffa90 bsp=e0000000004f9298
+ [<a0000001001a9ca0>] proc_mkdir_mode+0x40/0xe0
+                                sp=e0000000004ffaa0 bsp=e0000000004f9268
+ [<a0000001001a9d70>] proc_mkdir+0x30/0x60
+                                sp=e0000000004ffab0 bsp=e0000000004f9240
+ [<a0000001000e97e0>] register_handler_proc+0x1a0/0x1e0
+                                sp=e0000000004ffab0 bsp=e0000000004f91f0
+ [<a0000001000e6420>] setup_irq+0x440/0x4e0
+                                sp=e0000000004ffb30 bsp=e0000000004f9198
+ [<a0000001000e68c0>] request_irq+0x140/0x1a0
+                                sp=e0000000004ffb30 bsp=e0000000004f9150
+ [<a0000001003e7a20>] bind_ipi_to_irqhandler+0x260/0x2c0
+                                sp=e0000000004ffb30 bsp=e0000000004f90e8
+ [<a000000100019780>] xen_register_percpu_irq+0x2c0/0x880
+                                sp=e0000000004ffb40 bsp=e0000000004f9098
+ [<a00000010001a1f0>] xen_smp_intr_init+0x170/0x1c0
+                                sp=e0000000004ffb40 bsp=e0000000004f9070
+ [<a00000010003d350>] cpu_init+0x1090/0x10e0
+                                sp=e0000000004ffb50 bsp=e0000000004f8fe0
+ [<a0000001000607a0>] start_secondary+0xc0/0x520
+                                sp=e0000000004ffe30 bsp=e0000000004f8f90
+ [<a0000001000105f0>] __end_ivt_text+0x6d0/0x700
+                                sp=e0000000004ffe30 bsp=e0000000004f8f90
+
+Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
+xen-unstable changeset: 15093:63263d715d4309e7bccdd43d0f9c5c49be8c52ac
+xen-unstable date: Thu May 03 14:38:26 2007 -0600
+
+diff -r f8aede89c706 -r 63263d715d43 linux-2.6-xen-sparse/arch/ia64/kernel/irq_ia64.c
+--- a/linux-2.6-xen-sparse/arch/ia64/kernel/irq_ia64.c	Thu May 03 14:27:26 2007 -0600
++++ b/linux-2.6-xen-sparse/arch/ia64/kernel/irq_ia64.c	Thu May 03 14:38:26 2007 -0600
+@@ -319,9 +319,9 @@ static struct irqaction resched_irqactio
+  * required.
+  */
+ static void
+-xen_register_percpu_irq (unsigned int vec, struct irqaction *action, int save)
+-{
+-	unsigned int cpu = smp_processor_id();
++xen_register_percpu_irq(unsigned int cpu, unsigned int vec,
++			 struct irqaction *action, int save)
++{
+ 	irq_desc_t *desc;
+ 	int irq = 0;
+ 
+@@ -423,7 +423,8 @@ xen_bind_early_percpu_irq (void)
+ 	 * BSP will face with such step shortly
+ 	 */
+ 	for (i = 0; i < late_irq_cnt; i++)
+-		xen_register_percpu_irq(saved_percpu_irqs[i].irq,
++		xen_register_percpu_irq(smp_processor_id(),
++					saved_percpu_irqs[i].irq,
+ 		                        saved_percpu_irqs[i].action, 0);
+ }
+ 
+@@ -479,11 +480,21 @@ static struct notifier_block unbind_evtc
+ #endif
+ 
+ DECLARE_PER_CPU(int, ipi_to_irq[NR_IPIS]);
++void xen_smp_intr_init_early(unsigned int cpu)
++{
++#ifdef CONFIG_SMP
++	unsigned int i;
++
++	for (i = 0; i < saved_irq_cnt; i++)
++		xen_register_percpu_irq(cpu, saved_percpu_irqs[i].irq,
++		                        saved_percpu_irqs[i].action, 0);
++#endif
++}
++
+ void xen_smp_intr_init(void)
+ {
+ #ifdef CONFIG_SMP
+ 	unsigned int cpu = smp_processor_id();
+-	unsigned int i = 0;
+ 	struct callback_register event = {
+ 		.type = CALLBACKTYPE_event,
+ 		.address = (unsigned long)&xen_event_callback,
+@@ -500,12 +511,9 @@ void xen_smp_intr_init(void)
+ 
+ 	/* This should be piggyback when setup vcpu guest context */
+ 	BUG_ON(HYPERVISOR_callback_op(CALLBACKOP_register, &event));
+-
+-	for (i = 0; i < saved_irq_cnt; i++)
+-		xen_register_percpu_irq(saved_percpu_irqs[i].irq,
+-		                        saved_percpu_irqs[i].action, 0);
+ #endif /* CONFIG_SMP */
+ }
++
+ #endif /* CONFIG_XEN */
+ 
+ void
+@@ -516,7 +524,8 @@ register_percpu_irq (ia64_vector vec, st
+ 
+ #ifdef CONFIG_XEN
+ 	if (is_running_on_xen())
+-		return xen_register_percpu_irq(vec, action, 1);
++		return xen_register_percpu_irq(smp_processor_id(), 
++					       vec, action, 1);
+ #endif
+ 
+ 	for (irq = 0; irq < NR_IRQS; ++irq)
+@@ -572,6 +581,14 @@ ia64_send_ipi (int cpu, int vector, int 
+ 		/* TODO: we need to call vcpu_up here */
+ 		if (unlikely(vector == ap_wakeup_vector)) {
+ 			extern void xen_send_ipi (int cpu, int vec);
++
++			/* XXX
++			 * This should be in __cpu_up(cpu) in ia64 smpboot.c
++			 * like x86. But don't want to modify it,
++			 * keep it untouched.
++			 */
++			xen_smp_intr_init_early(cpu);
++
+ 			xen_send_ipi (cpu, vector);
+ 			//vcpu_prepare_and_up(cpu);
+ 			return;
diff -r 7ba52aa72ae5 -r 41c9c4fcf358 15103-1a010d9444ba
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15103-1a010d9444ba	Wed Sep 12 15:02:25 2007 +0900
@@ -0,0 +1,33 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1178565164 21600
+# Node ID 1a010d9444baa9c1b44f42856f607ab584574315
+# Parent  7c176473786b4e96723f8fb3cd794cc4db8923e9
+[IA64] Prevent softlock up message when domain is restored.
+
+Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
+xen-unstable changeset: 15103:1a010d9444baa9c1b44f42856f607ab584574315
+xen-unstable date: Mon May 07 13:12:44 2007 -0600
+
+diff -r 7c176473786b -r 1a010d9444ba linux-2.6-xen-sparse/arch/ia64/kernel/time.c
+--- a/linux-2.6-xen-sparse/arch/ia64/kernel/time.c	Mon May 07 10:37:16 2007 -0600
++++ b/linux-2.6-xen-sparse/arch/ia64/kernel/time.c	Mon May 07 13:12:44 2007 -0600
+@@ -322,6 +322,8 @@ time_resume(void)
+ 
+ 	for_each_online_cpu(cpu)
+ 		init_missing_ticks_accounting(cpu);
++
++	touch_softlockup_watchdog();
+ }
+ #else
+ #define init_missing_ticks_accounting(cpu) do {} while (0)
+@@ -412,6 +414,9 @@ ia64_init_itm (void)
+ 	if (is_running_on_xen())
+ 		init_missing_ticks_accounting(smp_processor_id());
+ 
++	/* avoid softlock up message when cpu is unplug and plugged again. */
++	touch_softlockup_watchdog();
++
+ 	/* Setup the CPU local timer tick */
+ 	ia64_cpu_local_tick();
+ }
diff -r 7ba52aa72ae5 -r 41c9c4fcf358 15107-8b9637467068
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15107-8b9637467068	Wed Sep 12 15:02:25 2007 +0900
@@ -0,0 +1,172 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1178642391 21600
+# Node ID 8b96374670680257cbb988a17dfb88516ef0e7d7
+# Parent  d7303c4a9dabdc7b461e7915fb8cd9d03ff7570c
+[IA64] Make p2m exposure compatible with suspend/resume and fix one bug.
+
+Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
+xen-unstable changeset: 15107:8b96374670680257cbb988a17dfb88516ef0e7d7
+xen-unstable date: Tue May 08 10:39:51 2007 -0600
+
+diff -r d7303c4a9dab -r 8b9637467068 linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c
+--- a/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c	Tue May 08 09:09:17 2007 -0600
++++ b/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c	Tue May 08 10:39:51 2007 -0600
+@@ -48,6 +48,7 @@ static int p2m_expose_init(void);
+ static int p2m_expose_init(void);
+ #else
+ #define p2m_expose_init() (-ENOSYS)
++#define p2m_expose_resume() ((void)0)
+ #endif
+ 
+ EXPORT_SYMBOL(__hypercall);
+@@ -882,6 +883,8 @@ static struct resource p2m_resource = {
+ };
+ static unsigned long p2m_assign_start_pfn __read_mostly;
+ static unsigned long p2m_assign_end_pfn __read_mostly;
++static unsigned long p2m_expose_size;	// this is referenced only when resume.
++					// so __read_mostly doesn't make sense.
+ volatile const pte_t* p2m_pte __read_mostly;
+ 
+ #define GRNULE_PFN	PTRS_PER_PTE
+@@ -942,8 +945,15 @@ p2m_expose_dtr_call(struct notifier_bloc
+ 	unsigned int cpu = (unsigned int)(long)ptr;
+ 	if (event != CPU_ONLINE)
+ 		return 0;
+-	if (!(p2m_initialized && xen_ia64_p2m_expose_use_dtr))
+-		smp_call_function_single(cpu, &p2m_itr, &p2m_itr_arg, 1, 1);
++	if (p2m_initialized && xen_ia64_p2m_expose_use_dtr) {
++		unsigned int me = get_cpu();
++		if (cpu == me)
++			p2m_itr(&p2m_itr_arg);
++		else
++			smp_call_function_single(cpu, &p2m_itr, &p2m_itr_arg,
++						 1, 1);
++		put_cpu();
++	}
+ 	return 0;
+ }
+ 
+@@ -958,7 +968,6 @@ p2m_expose_init(void)
+ p2m_expose_init(void)
+ {
+ 	unsigned long num_pfn;
+-	unsigned long size = 0;
+ 	unsigned long p2m_size = 0;
+ 	unsigned long align = ~0UL;
+ 	int error = 0;
+@@ -1010,7 +1019,7 @@ p2m_expose_init(void)
+ 			p2m_convert_max_pfn = ROUNDUP(p2m_max_low_pfn,
+ 			                              granule_pfn);
+ 			num_pfn = p2m_convert_max_pfn - p2m_convert_min_pfn;
+-			size = num_pfn << PAGE_SHIFT;
++			p2m_expose_size = num_pfn << PAGE_SHIFT;
+ 			p2m_size = num_pfn / PTRS_PER_PTE;
+ 			p2m_size = ROUNDUP(p2m_size, granule_pfn << PAGE_SHIFT);
+ 			if (p2m_size == page_size)
+@@ -1030,7 +1039,7 @@ p2m_expose_init(void)
+ 		                                p2m_granule_pfn);
+ 		p2m_convert_max_pfn = ROUNDUP(p2m_max_low_pfn, p2m_granule_pfn);
+ 		num_pfn = p2m_convert_max_pfn - p2m_convert_min_pfn;
+-		size = num_pfn << PAGE_SHIFT;
++		p2m_expose_size = num_pfn << PAGE_SHIFT;
+ 		p2m_size = num_pfn / PTRS_PER_PTE;
+ 		p2m_size = ROUNDUP(p2m_size, p2m_granule_pfn << PAGE_SHIFT);
+ 		align = max(privcmd_resource_align,
+@@ -1054,14 +1063,14 @@ p2m_expose_init(void)
+ 	
+ 	error = HYPERVISOR_expose_p2m(p2m_convert_min_pfn,
+ 	                              p2m_assign_start_pfn,
+-	                              size, p2m_granule_pfn);
++	                              p2m_expose_size, p2m_granule_pfn);
+ 	if (error) {
+ 		printk(KERN_ERR P2M_PREFIX "failed expose p2m hypercall %d\n",
+ 		       error);
+ 		printk(KERN_ERR P2M_PREFIX "conv 0x%016lx assign 0x%016lx "
+-		       "size 0x%016lx granule 0x%016lx\n",
++		       "expose_size 0x%016lx granule 0x%016lx\n",
+ 		       p2m_convert_min_pfn, p2m_assign_start_pfn,
+-		       size, p2m_granule_pfn);;
++		       p2m_expose_size, p2m_granule_pfn);;
+ 		release_resource(&p2m_resource);
+ 		goto out;
+ 	}
+@@ -1104,6 +1113,49 @@ p2m_expose_cleanup(void)
+ }
+ #endif
+ 
++static void
++p2m_expose_resume(void)
++{
++	int error;
++
++	if (!xen_ia64_p2m_expose || !p2m_initialized)
++		return;
++
++	/*
++	 * We can't call {lock, unlock}_cpu_hotplug() because
++	 * they require process context.
++	 * We don't need them because we're the only one cpu and
++	 * interrupts are masked when resume.
++	 */
++	error = HYPERVISOR_expose_p2m(p2m_convert_min_pfn,
++	                              p2m_assign_start_pfn,
++	                              p2m_expose_size, p2m_granule_pfn);
++	if (error) {
++		printk(KERN_ERR P2M_PREFIX "failed expose p2m hypercall %d\n",
++		       error);
++		printk(KERN_ERR P2M_PREFIX "conv 0x%016lx assign 0x%016lx "
++		       "expose_size 0x%016lx granule 0x%016lx\n",
++		       p2m_convert_min_pfn, p2m_assign_start_pfn,
++		       p2m_expose_size, p2m_granule_pfn);;
++		p2m_initialized = 0;
++		smp_mb();
++		ia64_ptr(0x2, p2m_itr_arg.vaddr, p2m_itr_arg.log_page_size);
++		
++		/*
++		 * We can't call those clean up functions because they
++		 * require process context.
++		 */
++#if 0
++#ifdef CONFIG_XEN_IA64_EXPOSE_P2M_USE_DTR
++		if (xen_ia64_p2m_expose_use_dtr)
++			unregister_cpu_notifier(
++				&p2m_expose_dtr_hotplug_notifier);
++#endif
++		release_resource(&p2m_resource);
++#endif
++	}
++}
++
+ //XXX inlinize?
+ unsigned long
+ p2m_phystomach(unsigned long gpfn)
+@@ -1187,3 +1239,15 @@ xen_ia64_unmap_resource(struct resource*
+ 	xen_ia64_release_resource(res);
+ }
+ EXPORT_SYMBOL_GPL(xen_ia64_unmap_resource);
++
++///////////////////////////////////////////////////////////////////////////
++// suspend/resume
++void
++xen_post_suspend(int suspend_cancelled)
++{
++	if (suspend_cancelled)
++		return;
++	
++	p2m_expose_resume();
++	/* add more if necessary */
++}
+diff -r d7303c4a9dab -r 8b9637467068 linux-2.6-xen-sparse/include/asm-ia64/hypervisor.h
+--- a/linux-2.6-xen-sparse/include/asm-ia64/hypervisor.h	Tue May 08 09:09:17 2007 -0600
++++ b/linux-2.6-xen-sparse/include/asm-ia64/hypervisor.h	Tue May 08 10:39:51 2007 -0600
+@@ -168,6 +168,9 @@ xen_destroy_contiguous_region(unsigned l
+ 		__xen_destroy_contiguous_region(vstart, order);
+ }
+ 
++/* For drivers/xen/core/machine_reboot.c */
++#define HAVE_XEN_POST_SUSPEND
++void xen_post_suspend(int suspend_cancelled);
+ #endif /* !CONFIG_VMX_GUEST */
+ 
+ // for netfront.c, netback.c
diff -r 7ba52aa72ae5 -r 41c9c4fcf358 15113-31be207e005e
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15113-31be207e005e	Wed Sep 12 15:02:25 2007 +0900
@@ -0,0 +1,170 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1178833590 21600
+# Node ID 31be207e005eaf178c87c047d8827998d6122282
+# Parent  8745300bec4ec254b3e2426e4fb5e3f4a9e0e0bc
+[IA64] Handle speculative vhpt walk
+
+Since processor may support speculative VHPT walk,
+The long format VHPT head entry needs to be disabled
+before programming it.
+
+Signed-off-by: Anthony Xu <anthony.xu@intel.com>
+xen-unstable changeset: 15113:31be207e005eaf178c87c047d8827998d6122282
+xen-unstable date: Thu May 10 15:46:30 2007 -0600
+
+diff -r 8745300bec4e -r 31be207e005e xen/arch/ia64/vmx/vmx_ivt.S
+--- a/xen/arch/ia64/vmx/vmx_ivt.S	Thu May 10 15:18:27 2007 -0600
++++ b/xen/arch/ia64/vmx/vmx_ivt.S	Thu May 10 15:46:30 2007 -0600
+@@ -168,11 +168,11 @@ vmx_itlb_loop:
+     adds r16 = VLE_TITAG_OFFSET, r17
+     adds r19 = VLE_CCHAIN_OFFSET, r17
+     ;;
+-    ld8 r22 = [r16]
++    ld8 r24 = [r16]
+     ld8 r23 = [r19]
+     ;;
+     lfetch [r23]
+-    cmp.eq  p6,p7 = r20, r22
++    cmp.eq  p6,p7 = r20, r24
+     ;;
+ (p7)mov r17 = r23;
+ (p7)br.sptk vmx_itlb_loop
+@@ -180,10 +180,12 @@ vmx_itlb_loop:
+     ld8 r25 = [r17]
+     ld8 r27 = [r18]
+     ld8 r29 = [r28]
++    dep r22 = -1,r24,63,1    //set ti=1
+     ;;
+     st8 [r16] = r29, VLE_ITIR_OFFSET - VLE_TITAG_OFFSET
+     st8 [r28] = r22, VLE_ITIR_OFFSET - VLE_TITAG_OFFSET
+     extr.u r19 = r27, 56, 4
++    mf
+     ;;
+     ld8 r29 = [r16]
+     ld8 r22 = [r28]
+@@ -191,10 +193,11 @@ vmx_itlb_loop:
+     dep r25 = r19, r25, 56, 4
+     ;;
+     st8 [r16] = r22
+-    st8 [r28] = r29
++    st8 [r28] = r29, VLE_TITAG_OFFSET - VLE_ITIR_OFFSET
+     st8 [r18] = r25
+     st8 [r17] = r27
+     ;;
++    st8.rel [r28] = r24
+     itc.i r25
+     dv_serialize_data
+     mov r17=cr.isr
+@@ -246,11 +249,11 @@ vmx_dtlb_loop:
+     adds r16 = VLE_TITAG_OFFSET, r17
+     adds r19 = VLE_CCHAIN_OFFSET, r17
+     ;;
+-    ld8 r22 = [r16]
++    ld8 r24 = [r16]
+     ld8 r23 = [r19]
+     ;;
+     lfetch [r23]
+-    cmp.eq  p6,p7 = r20, r22
++    cmp.eq  p6,p7 = r20, r24
+     ;;
+ (p7)mov r17 = r23;
+ (p7)br.sptk vmx_dtlb_loop
+@@ -258,10 +261,12 @@ vmx_dtlb_loop:
+     ld8 r25 = [r17]
+     ld8 r27 = [r18]
+     ld8 r29 = [r28]
++    dep r22 = -1,r24,63,1    //set ti=1
+     ;;
+     st8 [r16] = r29, VLE_ITIR_OFFSET - VLE_TITAG_OFFSET
+     st8 [r28] = r22, VLE_ITIR_OFFSET - VLE_TITAG_OFFSET
+     extr.u r19 = r27, 56, 4
++    mf
+     ;;
+     ld8 r29 = [r16]
+     ld8 r22 = [r28]
+@@ -269,10 +274,11 @@ vmx_dtlb_loop:
+     dep r25 = r19, r25, 56, 4
+     ;;
+     st8 [r16] = r22
+-    st8 [r28] = r29
++    st8 [r28] = r29, VLE_TITAG_OFFSET - VLE_ITIR_OFFSET
+     st8 [r18] = r25
+     st8 [r17] = r27
+-    ;;    
++    ;;
++    st8.rel [r28] = r24 
+     itc.d r25
+     dv_serialize_data
+     mov r17=cr.isr
+diff -r 8745300bec4e -r 31be207e005e xen/arch/ia64/vmx/vtlb.c
+--- a/xen/arch/ia64/vmx/vtlb.c	Thu May 10 15:18:27 2007 -0600
++++ b/xen/arch/ia64/vmx/vtlb.c	Thu May 10 15:46:30 2007 -0600
+@@ -141,7 +141,7 @@ static void thash_recycle_cch(thash_cb_t
+ 
+ static void vmx_vhpt_insert(thash_cb_t *hcb, u64 pte, u64 itir, u64 ifa)
+ {
+-    u64 tag ,len;
++    u64 tag;
+     ia64_rr rr;
+     thash_data_t *head, *cch;
+     pte = pte & ~PAGE_FLAGS_RV_MASK;
+@@ -155,14 +155,12 @@ static void vmx_vhpt_insert(thash_cb_t *
+         cch = cch->next;
+     }
+     if (cch) {
+-        if (cch == head) {
+-            len = head->len;
+-        } else {
++        if (cch != head) {
+             local_irq_disable();
+             cch->page_flags = head->page_flags;
+             cch->itir = head->itir;
+             cch->etag  = head->etag;
+-            len = head->len;
++            head->ti = 1;
+             local_irq_enable();
+         }
+     }
+@@ -175,16 +173,17 @@ static void vmx_vhpt_insert(thash_cb_t *
+         }
+         local_irq_disable();
+         *cch = *head;
++        head->ti = 1;
+         head->next = cch;
+-        len = cch->len+1;
++        head->len = cch->len + 1;
+         cch->len = 0;
+         local_irq_enable();
+     }
+-
++    //here head is invalid
++    wmb();
+     head->page_flags=pte;
+-    head->len = len;
+     head->itir = rr.ps << 2;
+-    head->etag=tag;
++    *(volatile unsigned long*)&head->etag = tag;
+     return;
+ }
+ 
+diff -r 8745300bec4e -r 31be207e005e xen/arch/ia64/xen/vhpt.c
+--- a/xen/arch/ia64/xen/vhpt.c	Thu May 10 15:18:27 2007 -0600
++++ b/xen/arch/ia64/xen/vhpt.c	Thu May 10 15:46:30 2007 -0600
+@@ -78,11 +78,13 @@ void vhpt_insert (unsigned long vadr, un
+ 	struct vhpt_lf_entry *vlfe = (struct vhpt_lf_entry *)ia64_thash(vadr);
+ 	unsigned long tag = ia64_ttag (vadr);
+ 
+-	/* No need to first disable the entry, since VHPT is per LP
+-	   and VHPT is TR mapped.  */
++	/* Even though VHPT is per VCPU, still need to first disable the entry,
++	 * because the processor may support speculative VHPT walk.  */
++	vlfe->ti_tag = INVALID_TI_TAG;
++	wmb();
+ 	vlfe->itir = logps;
+ 	vlfe->page_flags = pte | _PAGE_P;
+-	vlfe->ti_tag = tag;
++	*(volatile unsigned long*)&vlfe->ti_tag = tag;
+ }
+ 
+ void vhpt_multiple_insert(unsigned long vaddr, unsigned long pte, unsigned long logps)
diff -r 7ba52aa72ae5 -r 41c9c4fcf358 15115-7812598f65be
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15115-7812598f65be	Wed Sep 12 15:02:25 2007 +0900
@@ -0,0 +1,28 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1178910424 21600
+# Node ID 7812598f65beaf4934cec9e01e0f538ada097da6
+# Parent  7d8acd319d5b5927ce40230d48132ba4301edf44
+[IA64] Return ENOMEM if VPD allocation failed
+
+Usually ASSRET() is "(void)0".  Therefore if VPD allocation
+fails with xenheap shortage or fragmentation, NULL pointer
+access occurs in vmx_final_setup_guest().
+This patch fixes it.
+
+Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
+xen-unstable changeset: 15115:7812598f65beaf4934cec9e01e0f538ada097da6
+xen-unstable date: Fri May 11 13:07:04 2007 -0600
+
+diff -r 7d8acd319d5b -r 7812598f65be xen/arch/ia64/vmx/vmx_init.c
+--- a/xen/arch/ia64/vmx/vmx_init.c	Thu May 10 15:55:22 2007 -0600
++++ b/xen/arch/ia64/vmx/vmx_init.c	Fri May 11 13:07:04 2007 -0600
+@@ -299,6 +299,8 @@ vmx_final_setup_guest(struct vcpu *v)
+ 
+ 	vpd = alloc_vpd();
+ 	ASSERT(vpd);
++	if (!vpd)
++		return -ENOMEM;
+ 
+ 	v->arch.privregs = (mapped_regs_t *)vpd;
+ 	vcpu_share_privregs_with_guest(v);
diff -r 7ba52aa72ae5 -r 41c9c4fcf358 15116-d6309cfd1fdd
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15116-d6309cfd1fdd	Wed Sep 12 15:02:25 2007 +0900
@@ -0,0 +1,31 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1178910552 21600
+# Node ID d6309cfd1fdd53c23fd8daf32afe67abb68b35d6
+# Parent  7812598f65beaf4934cec9e01e0f538ada097da6
+[IA64] Fix allocate_rid_range()
+
+Though there is a free ridblock_owner[], allocate_rid_range()
+cannot allocate it.
+
+Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
+xen-unstable changeset: 15116:d6309cfd1fdd53c23fd8daf32afe67abb68b35d6
+xen-unstable date: Fri May 11 13:09:12 2007 -0600
+
+diff -r 7812598f65be -r d6309cfd1fdd xen/arch/ia64/xen/regionreg.c
+--- a/xen/arch/ia64/xen/regionreg.c	Fri May 11 13:07:04 2007 -0600
++++ b/xen/arch/ia64/xen/regionreg.c	Fri May 11 13:09:12 2007 -0600
+@@ -157,9 +157,12 @@ int allocate_rid_range(struct domain *d,
+ 	for (i = n_rid_blocks; i < MAX_RID_BLOCKS; i += n_rid_blocks) {
+ 		if (ridblock_owner[i] == NULL) {
+ 			for (j = i; j < i + n_rid_blocks; ++j) {
+-				if (ridblock_owner[j])
++				if (ridblock_owner[j]) {
++					++j;
+ 					break;
++				}
+ 			}
++			--j;
+ 			if (ridblock_owner[j] == NULL)
+ 				break;
+ 		}
diff -r 7ba52aa72ae5 -r 41c9c4fcf358 15119-fd72e71de51a
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15119-fd72e71de51a	Wed Sep 12 15:02:25 2007 +0900
@@ -0,0 +1,101 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1179165121 21600
+# Node ID fd72e71de51a53f865e4e82d2bcca1c7664c9b04
+# Parent  c0de8feef4cda1cfe6bd926f8b9adbc1fbc8589b
+[IA64] Fix ptc.ga emulation
+
+cset14829(c42ae7839750) was incomplete.
+
+The region register 0 will be clobbered as follows.
+
+time    pcpu0   pcpu1   pcpu2
+ |      vcpu0   vcpu1   idle  // assignment of vcpu
+ V
+        1.vcpu0 issues ptc.ga
+        2.vcpu0 sends IPI to vcpu1(pcpu1)
+                3.vcpu1 migrates from pcpu1 to pcpu2
+                4.pcpu1 receives IPI of 2 and exec ptc_ga_remote_func()
+                5.pcpu1 saves and modifies vrr[0]
+                        6.vcpu1(pcpu2) modifies vrr[0]
+                7.pcpu1 restores vrr[0]         // vrr[0] of 6 is lost
+
+Windows will crash due to this issue.
+
+Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
+xen-unstable changeset: 15119:fd72e71de51a53f865e4e82d2bcca1c7664c9b04
+xen-unstable date: Mon May 14 11:52:01 2007 -0600
+
+diff -r c0de8feef4cd -r fd72e71de51a xen/arch/ia64/vmx/vmmu.c
+--- a/xen/arch/ia64/vmx/vmmu.c	Mon May 14 11:13:24 2007 -0600
++++ b/xen/arch/ia64/vmx/vmmu.c	Mon May 14 11:52:01 2007 -0600
+@@ -563,11 +563,17 @@ struct ptc_ga_args {
+ 
+ static void ptc_ga_remote_func (void *varg)
+ {
+-    u64 oldrid, moldrid, mpta, oldpsbits, vadr;
++    u64 oldrid, moldrid, mpta, oldpsbits, vadr, flags;
+     struct ptc_ga_args *args = (struct ptc_ga_args *)varg;
+     VCPU *v = args->vcpu;
+     vadr = args->vadr;
+ 
++    /* Try again if VCPU has migrated. */
++    if (v->processor != current->processor)
++        return;
++    vcpu_schedule_lock_irqsave(v, flags);
++    if (v->processor != current->processor)
++        goto bail;
+     oldrid = VMX(v, vrr[0]);
+     VMX(v, vrr[0]) = args->rid;
+     oldpsbits = VMX(v, psbits[0]);
+@@ -584,6 +590,9 @@ static void ptc_ga_remote_func (void *va
+     ia64_set_rr(0x0,moldrid);
+     ia64_set_pta(mpta);
+     ia64_dv_serialize_data();
++    args->vcpu = NULL;
++bail:
++    vcpu_schedule_unlock_irqrestore(v, flags);
+ }
+ 
+ 
+@@ -602,28 +611,21 @@ IA64FAULT vmx_vcpu_ptc_ga(VCPU *vcpu, u6
+         if (!v->is_initialised)
+             continue;
+ 
++        if (v == vcpu) {
++            vmx_vcpu_ptc_l(v, va, ps);
++            continue;
++        }
++
+         args.vcpu = v;
+-again: /* Try again if VCPU has migrated.  */
+-        proc = v->processor;
+-        if (proc != vcpu->processor) {
+-            /* Flush VHPT on remote processors.  */
+-            smp_call_function_single(v->processor,
+-                                     &ptc_ga_remote_func, &args, 0, 1);
+-            if (proc != v->processor)
+-                goto again;
+-        } else if (v == vcpu) {
+-            vmx_vcpu_ptc_l(v, va, ps);
+-        } else {
+-            vcpu_schedule_lock_irq(v);
++        do {
+             proc = v->processor;
+-            if (proc == vcpu->processor)
++            if (proc != vcpu->processor)
++                /* Flush VHPT on remote processors. */
++                smp_call_function_single(proc, &ptc_ga_remote_func,
++                                         &args, 0, 1);
++            else
+                 ptc_ga_remote_func(&args);
+-            else
+-                proc = INVALID_PROCESSOR;
+-            vcpu_schedule_unlock_irq(v);
+-            if (proc == INVALID_PROCESSOR)
+-                goto again;
+-        }
++        } while (args.vcpu != NULL);
+     }
+     return IA64_NO_FAULT;
+ }
diff -r 7ba52aa72ae5 -r 41c9c4fcf358 15122-afb27041a2ce
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15122-afb27041a2ce	Wed Sep 12 15:02:25 2007 +0900
@@ -0,0 +1,81 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1179333727 21600
+# Node ID afb27041a2ce4493b6c1d9cf87939858a96136d0
+# Parent  8c5ebe559a4ddfa05a6291a9b33ae29ea202a462
+[IA64] Fix deadlock of ptc.ga emulation
+
+ptc_ga_remote_func() might be invoked by IPI with a schedule_lock
+that is acquired. (e.g., inside of vcpu_migrate())
+It will cause a deadlock.
+
+Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
+xen-unstable changeset: 15122:afb27041a2ce4493b6c1d9cf87939858a96136d0
+xen-unstable date: Wed May 16 10:42:07 2007 -0600
+
+diff -r 8c5ebe559a4d -r afb27041a2ce xen/arch/ia64/vmx/vmmu.c
+--- a/xen/arch/ia64/vmx/vmmu.c	Tue May 15 15:32:23 2007 -0600
++++ b/xen/arch/ia64/vmx/vmmu.c	Wed May 16 10:42:07 2007 -0600
+@@ -563,13 +563,16 @@ static void ptc_ga_remote_func (void *va
+     struct ptc_ga_args *args = (struct ptc_ga_args *)varg;
+     VCPU *v = args->vcpu;
+     vadr = args->vadr;
++    int cpu = v->processor;
+ 
+     /* Try again if VCPU has migrated. */
+-    if (v->processor != current->processor)
++    if (cpu != current->processor)
+         return;
+-    vcpu_schedule_lock_irqsave(v, flags);
+-    if (v->processor != current->processor)
+-        goto bail;
++    local_irq_save(flags);
++    if (!spin_trylock(&per_cpu(schedule_data, cpu).schedule_lock))
++        goto bail2;
++    if (v->processor != cpu)
++        goto bail1;
+     oldrid = VMX(v, vrr[0]);
+     VMX(v, vrr[0]) = args->rid;
+     oldpsbits = VMX(v, psbits[0]);
+@@ -587,8 +590,10 @@ static void ptc_ga_remote_func (void *va
+     ia64_set_pta(mpta);
+     ia64_dv_serialize_data();
+     args->vcpu = NULL;
+-bail:
+-    vcpu_schedule_unlock_irqrestore(v, flags);
++bail1:
++    spin_unlock(&per_cpu(schedule_data, cpu).schedule_lock);
++bail2:
++    local_irq_restore(flags);
+ }
+ 
+ 
+@@ -598,7 +603,7 @@ IA64FAULT vmx_vcpu_ptc_ga(VCPU *vcpu, u6
+     struct domain *d = vcpu->domain;
+     struct vcpu *v;
+     struct ptc_ga_args args;
+-    int proc;
++    int cpu;
+ 
+     args.vadr = va;
+     vcpu_get_rr(vcpu, va, &args.rid);
+@@ -614,13 +619,15 @@ IA64FAULT vmx_vcpu_ptc_ga(VCPU *vcpu, u6
+ 
+         args.vcpu = v;
+         do {
+-            proc = v->processor;
+-            if (proc != vcpu->processor)
++            cpu = v->processor;
++            if (cpu != current->processor) {
++                spin_unlock_wait(&per_cpu(schedule_data, cpu).schedule_lock);
+                 /* Flush VHPT on remote processors. */
+-                smp_call_function_single(proc, &ptc_ga_remote_func,
++                smp_call_function_single(cpu, &ptc_ga_remote_func,
+                                          &args, 0, 1);
+-            else
++            } else {
+                 ptc_ga_remote_func(&args);
++            }
+         } while (args.vcpu != NULL);
+     }
+     return IA64_NO_FAULT;
diff -r 7ba52aa72ae5 -r 41c9c4fcf358 15307-d30576123892
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15307-d30576123892	Wed Sep 12 15:02:25 2007 +0900
@@ -0,0 +1,25 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1179779409 21600
+# Node ID d305761238924735fc00fc091b3cf0bb5949517d
+# Parent  6450f6287898ea5b2e7420647bf13cf709f949ce
+[IA64] Fix vpd size
+
+New pal has fixed vpd size issue, so change it to 64K to conform to Spec.
+
+Signed-off-by: Zhang xiantao <xiantao.zhang@intel.com>
+xen-unstable changeset: 15307:d305761238924735fc00fc091b3cf0bb5949517d
+xen-unstable date: Mon May 21 14:30:09 2007 -0600
+
+diff -r 6450f6287898 -r d30576123892 xen/include/asm-ia64/vmx_vpd.h
+--- a/xen/include/asm-ia64/vmx_vpd.h	Mon May 21 14:09:27 2007 -0600
++++ b/xen/include/asm-ia64/vmx_vpd.h	Mon May 21 14:30:09 2007 -0600
+@@ -29,7 +29,7 @@
+ #include <public/xen.h>
+ #include <xen/spinlock.h>
+ 
+-#define VPD_SHIFT	17	/* 128K requirement */
++#define VPD_SHIFT	16
+ #define VPD_SIZE	(1 << VPD_SHIFT)
+ 
+ typedef struct {
diff -r 7ba52aa72ae5 -r 41c9c4fcf358 15311-466f71b1e831
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15311-466f71b1e831	Wed Sep 12 15:02:25 2007 +0900
@@ -0,0 +1,82 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1180037788 21600
+# Node ID 466f71b1e8319927dca16bd16b05faa09fad0cdd
+# Parent  40542d29da2bda69fb3ed17b303e01d723b0aa9a
+[IA64] Fix ld.s emulation
+
+With this patch,
+* XEN correctly emulates ld.s for HVM
+* original memory attribute is preserved in vcpu->arch.vtlb
+
+Without this, XEN infrequently calls panic_domain() by mistake for windows.
+
+Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
+Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com>
+xen-unstable changeset: 15311:466f71b1e8319927dca16bd16b05faa09fad0cdd
+xen-unstable date: Thu May 24 14:16:28 2007 -0600
+
+diff -r d2ef85c6bf84 xen/arch/ia64/vmx/vmx_process.c
+--- a/xen/arch/ia64/vmx/vmx_process.c	Tue May 08 10:38:06 2007 +0100
++++ b/xen/arch/ia64/vmx/vmx_process.c	Wed Sep 12 14:46:46 2007 +0900
+@@ -311,6 +311,8 @@ vmx_hpw_miss(u64 vadr , u64 vec, REGS* r
+ 
+     if(is_physical_mode(v)&&(!(vadr<<1>>62))){
+         if(vec==2){
++            if (misr.sp) /* Refer to SDM Vol2 Table 4-11,4-12 */
++                return vmx_handle_lds(regs);
+             if (v->domain != dom0
+                 && __gpfn_is_io(v->domain, (vadr << 1) >> (PAGE_SHIFT + 1))) {
+                 emulate_io_inst(v,((vadr<<1)>>1),4);   //  UC
+@@ -323,9 +325,16 @@ vmx_hpw_miss(u64 vadr , u64 vec, REGS* r
+ 
+     if((data=vtlb_lookup(v, vadr,type))!=0){
+         if (v->domain != dom0 && type == DSIDE_TLB) {
++            if (misr.sp) { /* Refer to SDM Vol2 Table 4-10,4-12 */
++                if ((data->ma == VA_MATTR_UC) || (data->ma == VA_MATTR_UCE))
++                    return vmx_handle_lds(regs);
++            }
+             gppa = (vadr & ((1UL << data->ps) - 1)) +
+                    (data->ppn >> (data->ps - 12) << data->ps);
+             if (__gpfn_is_io(v->domain, gppa >> PAGE_SHIFT)) {
++                if (misr.sp)
++                    panic_domain(NULL, "ld.s on I/O page not with UC attr."
++                                 " pte=0x%lx\n", data->page_flags);
+                 if (data->pl >= ((regs->cr_ipsr >> IA64_PSR_CPL0_BIT) & 3))
+                     emulate_io_inst(v, gppa, data->ma);
+                 else {
+diff -r d2ef85c6bf84 xen/arch/ia64/vmx/vtlb.c
+--- a/xen/arch/ia64/vmx/vtlb.c	Tue May 08 10:38:06 2007 +0100
++++ b/xen/arch/ia64/vmx/vtlb.c	Wed Sep 12 14:46:46 2007 +0900
+@@ -500,6 +500,13 @@ u64 translate_phy_pte(VCPU *v, u64 *pte,
+         *pte |= VTLB_PTE_IO;
+         return -1;
+     }
++    /* Ensure WB attribute if pte is related to a normal mem page,
++     * which is required by vga acceleration since qemu maps shared
++     * vram buffer with WB.
++     */
++    if (phy_pte.ma != VA_MATTR_NATPAGE)
++        phy_pte.ma = VA_MATTR_WB;
++
+ //    rr.rrval = ia64_get_rr(va);
+ //    ps = rr.ps;
+     maddr = ((maddr & _PAGE_PPN_MASK) & PAGE_MASK) | (paddr & ~PAGE_MASK);
+@@ -521,14 +528,10 @@ void thash_purge_and_insert(VCPU *v, u64
+     vcpu_get_rr(current, ifa, &vrr.rrval);
+     mrr.rrval = ia64_get_rr(ifa);
+     if(VMX_DOMAIN(v)){
+-        /* Ensure WB attribute if pte is related to a normal mem page,
+-         * which is required by vga acceleration since qemu maps shared
+-         * vram buffer with WB.
+-         */
+-        if (!(pte & VTLB_PTE_IO) && ((pte & _PAGE_MA_MASK) != _PAGE_MA_NAT))
+-            pte &= ~_PAGE_MA_MASK;
+-
+         phy_pte = translate_phy_pte(v, &pte, itir, ifa);
++
++        if (pte & VTLB_PTE_IO)
++            ret = 1;
+         vtlb_purge(v, ifa, ps);
+         vhpt_purge(v, ifa, ps);
+         if (ps == mrr.ps) {
diff -r 7ba52aa72ae5 -r 41c9c4fcf358 15341-2fd72ec88a9a
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15341-2fd72ec88a9a	Wed Sep 12 15:02:25 2007 +0900
@@ -0,0 +1,48 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1181142830 21600
+# Node ID 2fd72ec88a9afa1af005b261d835ef8b42bbb5e8
+# Parent  9daa40cae3d6548f404bcfd4300e604185db6b64
+[IA64] Fix HVM boot failure
+
+HVM sometimes fails to boot with the message
+"Guest nested fault vector=0x5400!".
+
+The cause of this issue is that cr.ifs never be initialized in very
+first context switching. To optimize hypercall on HVM, cr.ifs is only
+set with the predicate pNonSys(pr5)=1.
+
+Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
+xen-unstable changeset: 15341:2fd72ec88a9afa1af005b261d835ef8b42bbb5e8
+xen-unstable date: Wed Jun 06 09:13:50 2007 -0600
+
+diff -r 9daa40cae3d6 -r 2fd72ec88a9a xen/arch/ia64/vmx/vmx_init.c
+--- a/xen/arch/ia64/vmx/vmx_init.c	Wed Jun 06 09:10:52 2007 -0600
++++ b/xen/arch/ia64/vmx/vmx_init.c	Wed Jun 06 09:13:50 2007 -0600
+@@ -51,6 +51,7 @@
+ #include <asm/viosapic.h>
+ #include <xen/event.h>
+ #include <asm/vlsapic.h>
++#include "entry.h"
+ 
+ /* Global flag to identify whether Intel vmx feature is on */
+ u32 vmx_enabled = 0;
+@@ -296,6 +297,7 @@ vmx_final_setup_guest(struct vcpu *v)
+ {
+ 	vpd_t *vpd;
+ 	int rc;
++	struct switch_stack *sw;
+ 
+ 	vpd = alloc_vpd();
+ 	ASSERT(vpd);
+@@ -331,6 +333,10 @@ vmx_final_setup_guest(struct vcpu *v)
+ 	/* Set up guest 's indicator for VTi domain*/
+ 	set_bit(ARCH_VMX_DOMAIN, &v->arch.arch_vmx.flags);
+ 
++	/* Initialize pNonSys=1 for the first context switching */
++	sw = (struct switch_stack *)vcpu_regs(v) - 1;
++	sw->pr = (1UL << PRED_NON_SYSCALL);
++
+ 	return 0;
+ }
+ 
diff -r 7ba52aa72ae5 -r 41c9c4fcf358 15568-34f285b57b87
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15568-34f285b57b87	Wed Sep 12 15:02:25 2007 +0900
@@ -0,0 +1,69 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1183662240 21600
+# Node ID 34f285b57b87e94948f9af22df80888452d85dce
+# Parent  40608e5e394ee4bcc5b68a4cbf49973f39327981
+[IA64] Fix soft lock up caused by xen_timer_interrupt()
+
+This patch intends to fix softlockup caused by xen_timer_interrupt().
+This is caused by local_cpu_data->itm_next and stime_irq, itc_at_irq
+inconsistency at CPU0 of hypervisor.  This patch sets stime_irq and
+itc_at_irq every time in xen_timer_interrupt() to avoid this soft
+lock up.
+
+In other words, it is caused by competition of local_cpu_data->itm_next
+and domain_itm in xen_timer_interrupt() and reprogram_timer() (more
+specific vcpu_set_next_timer()).
+
+For example:
+ 1) reprogram_timer() runs and set local_cpu_data->itm_next and set
+    domain_itm as next itm.
+ 2) xen_timer_interrupt() called but following condition is not satisfied:
+    while(time_after(ia64_get_itc(), local_cpu_data->itm_next)
+    This skips stime_irq and itc_at_irq setting.
+ 3) goto 1)
+ 4) sometimes local_cpu_data->itm_next is rollback because
+    ns_to_cycle()/IA64 is representing almost 32bit.
+    (This occured at reprogram_timer())
+ 5) It causes soft lock up.
+ 6) Hypervisor returns to work(not hang).
+
+To reproduce this issue, I do following configuration.
+
+ 1) boot Xen with pcpu=4 and Dom0 with vcpu=4
+ 2) boot domU1 with vcpu with vcpu-pin 0-1
+ 3) boot domU2 with vcpu with vcpu-pin 0-1
+ 4) run yes > /dev/null  2 process on domU1
+ 5) run nothing on domU2(to check softlock up occured or not)
+ 6) run kernel compile with -j4 on Dom0 continuously
+ 7) wait 4 or 8 hours to occur softlockup.
+
+Signed-off-by: Atsushi SAKAI <sakaia@jp.fujitsu.com>
+xen-unstable changeset: 15568:34f285b57b87e94948f9af22df80888452d85dce
+xen-unstable date: Thu Jul 05 13:04:00 2007 -0600
+
+diff -r 40608e5e394e -r 34f285b57b87 xen/arch/ia64/xen/xentime.c
+--- a/xen/arch/ia64/xen/xentime.c	Mon Jul 02 21:06:46 2007 -0600
++++ b/xen/arch/ia64/xen/xentime.c	Thu Jul 05 13:04:00 2007 -0600
+@@ -126,9 +126,7 @@ xen_timer_interrupt (int irq, void *dev_
+ 
+ 
+ 	new_itm = local_cpu_data->itm_next;
+-	while (time_after(ia64_get_itc(), new_itm)) {
+-		new_itm += local_cpu_data->itm_delta;
+-
++	while (1) {
+ 		if (smp_processor_id() == TIME_KEEPER_ID) {
+ 			/*
+ 			 * Here we are in the timer irq handler. We have irqs locally
+@@ -150,6 +148,10 @@ xen_timer_interrupt (int irq, void *dev_
+ 
+ 		local_cpu_data->itm_next = new_itm;
+ 
++		if (time_after(new_itm, ia64_get_itc())) 
++			break;
++
++		new_itm += local_cpu_data->itm_delta;
+ 	}
+ 
+ 	if (!is_idle_domain(current->domain) && !VMX_DOMAIN(current)) {
diff -r 7ba52aa72ae5 -r 41c9c4fcf358 15655-9cd309378326
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15655-9cd309378326	Wed Sep 12 15:02:25 2007 +0900
@@ -0,0 +1,46 @@
+# HG changeset patch
+# User kfraser@localhost.localdomain
+# Date 1185791296 -3600
+# Node ID 9cd309378326c6efe4ae8a1454faa730597d1560
+# Parent  c0fbee66aff63978addc5f8b263947553f606d08
+[IA64] Disable ACPI SRAT,SLIT table of dom0.
+
+  On some ia64 NUMA machine, we cannot boot dom0.
+  This issue is caused by different infomation LSAPIC and SRAT.
+  Xen-ia64 modify LSAPIC IDs of dom0, but it does not modify SRAT.
+  So we decide disabling SRAT, SLIT of dom0 as first step of NUMA
+  work.
+
+Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com>
+xen-unstable changeset: 15655:9cd309378326c6efe4ae8a1454faa730597d1560
+xen-unstable date: Mon Jul 30 11:28:16 2007 +0100
+
+diff -r d2ef85c6bf84 xen/arch/ia64/xen/dom_fw.c
+--- a/xen/arch/ia64/xen/dom_fw.c	Tue May 08 10:38:06 2007 +0100
++++ b/xen/arch/ia64/xen/dom_fw.c	Wed Sep 12 14:48:58 2007 +0900
+@@ -287,12 +287,25 @@ acpi_update_madt_checksum (unsigned long
+ /* base is physical address of acpi table */
+ static void touch_acpi_table(void)
+ {
++	int result;
+ 	lsapic_nbr = 0;
+ 	if (acpi_table_parse_madt(ACPI_MADT_LSAPIC, acpi_update_lsapic, 0) < 0)
+ 		printk("Error parsing MADT - no LAPIC entries\n");
+ 	if (acpi_table_parse_madt(ACPI_MADT_PLAT_INT_SRC,
+ 	                          acpi_patch_plat_int_src, 0) < 0)
+ 		printk("Error parsing MADT - no PLAT_INT_SRC entries\n");
++
++	result = acpi_table_disable(ACPI_SRAT);
++	if ( result == 0 )
++		printk("Success Disabling SRAT\n");
++	else if ( result != -ENOENT )
++		printk("ERROR: Failed Disabling SRAT\n");
++
++	result = acpi_table_disable(ACPI_SLIT);
++	if ( result == 0 )
++		printk("Success Disabling SLIT\n");
++	else if ( result != -ENOENT )
++		printk("ERROR: Failed Disabling SLIT\n");
+ 
+ 	acpi_table_parse(ACPI_APIC, acpi_update_madt_checksum);
+ 
diff -r 7ba52aa72ae5 -r 41c9c4fcf358 15742-2796311c6a55
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/15742-2796311c6a55	Wed Sep 12 15:02:25 2007 +0900
@@ -0,0 +1,23 @@
+# HG changeset patch
+# User Alex Williamson <alex.williamson@hp.com>
+# Date 1184527976 21600
+# Node ID 2796311c6a5537cff38bba20b74a1e64a1d9e909
+# Parent  f536eb8576eeb7363212911b02fbaff4918172df
+[IA64] Fix a memory allocation bug in MCA
+
+Signed-off-by: Kazuhiro Suzuki <kaz@jp.fujitsu.com>
+xen-unstable changeset: 15742:2796311c6a5537cff38bba20b74a1e64a1d9e909
+xen-unstable date: Sun Jul 15 13:32:56 2007 -0600
+
+diff -r f536eb8576ee -r 2796311c6a55 xen/arch/ia64/linux-xen/mca.c
+--- a/xen/arch/ia64/linux-xen/mca.c	Wed Jul 11 11:32:30 2007 -0600
++++ b/xen/arch/ia64/linux-xen/mca.c	Sun Jul 15 13:32:56 2007 -0600
+@@ -184,7 +184,7 @@ static ia64_state_log_t ia64_state_log[I
+ #define IA64_LOG_ALLOCATE(it, size) \
+ 	do { \
+ 		unsigned int pageorder; \
+-		pageorder  = get_order_from_bytes(sizeof(struct ia64_mca_cpu)); \
++		pageorder = get_order_from_bytes(size); \
+ 		ia64_state_log[it].isl_log[IA64_LOG_CURR_INDEX(it)] = \
+ 		  (ia64_err_rec_t *)alloc_xenheap_pages(pageorder); \
+ 		ia64_state_log[it].isl_log[IA64_LOG_NEXT_INDEX(it)] = \

[-- Attachment #3: Type: text/plain, Size: 152 bytes --]

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

Re: [Xen-ia64-devel] Re: Xen 3.1.1 -- initial patchqueue

[Alex Williamson]

On Wed, 2007-09-12 at 15:33 +0900, Kouya Shimura wrote:
> Alex Williamson writes:
>  >    Other ia64'ers, please speak up if there's something else missing.
> 
> Hi Keir and Alex,
> 
> Here's a list of additional(missing) patches for IA64:

Hi Kouya,

   I agree, these look like good patches to include in 3.1.1.  Thanks,

	Alex

> Must have fixes for HVM:
> http://xenbits.xensource.com/xen-unstable.hg?rev/8924215a5f95
> 15086-8924215a5f95 - fix VHPT insertion
> http://xenbits.xensource.com/xen-unstable.hg?rev/31be207e005e
> 15113-31be207e005e - fix VHPT walk
> http://xenbits.xensource.com/xen-unstable.hg?rev/7812598f65be
> 15115-7812598f65be - fix xen crash (vpd allocation)
> http://xenbits.xensource.com/xen-unstable.hg?rev/d6309cfd1fdd
> 15116-d6309cfd1fdd - fix resource allocation (rid)
> http://xenbits.xensource.com/xen-unstable.hg?rev/fd72e71de51a
> 15119-fd72e71de51a - fix Windows crash
> http://xenbits.xensource.com/xen-unstable.hg?rev/afb27041a2ce
> 15122-afb27041a2ce - fix Windows crash
> http://xenbits.xensource.com/xen-unstable.hg?rev/d30576123892
> 15307-d30576123892 - fix resource allocation (vpd size)
> http://xenbits.xensource.com/xen-unstable.hg?rev/466f71b1e831
> *15311-466f71b1e831 - fix crash of VTI domain
> http://xenbits.xensource.com/xen-unstable.hg?rev/2fd72ec88a9a
> 15341-2fd72ec88a9a - fix boot of VTI domain
> 
> Must have fixes:
> http://xenbits.xensource.com/xen-unstable.hg?rev/34f285b57b87
> 15568-34f285b57b87 - fix soft lock up 
> http://xenbits.xensource.com/xen-unstable.hg?rev/9cd309378326
> *15655-9cd309378326 - fix boot on NUMA systems
> http://xenbits.xensource.com/xen-unstable.hg?rev/2796311c6a55
> 15742-2796311c6a55 - fix boot related MCA
> 
> Must have fixes for save/restore:
> http://xenbits.xensource.com/xen-unstable.hg?rev/204046d99562
> 15090-204046d99562 - fix time_resume()
> http://xenbits.xensource.com/xen-unstable.hg?rev/63263d715d43
> 15093-63263d715d43 - fix vcpu hotplug
> http://xenbits.xensource.com/xen-unstable.hg?rev/1a010d9444ba
> 15103-1a010d9444ba - prevent softlock up message
> http://xenbits.xensource.com/xen-unstable.hg?rev/8b9637467068
> 15107-8b9637467068 - fix save/restore
> 
> An attached patch can be applied to xen-3.1-testing.pq.hg.
> Patches with an asterisk above are modified for xen-3.1-testing.hg.
> 
> Thanks,
> Kouya
> 

-- 
Alex Williamson                             HP Open Source & Linux Org.

Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue

[Chris Lalancette]

Keir Fraser wrote:
> Hi,
> 
> A provisional patchqueue for Xen 3.1.1 is available at
> http://xenbits.xensource.com/xen-3.1-testing.pq.hg. This pq partners with
> http://xenbits.xensource.com/xen-3.1-testing.hg.
> 
> Please kick this pq around and check whether the patches you want to see in
> 3.1.1 are included.
> 
>  -- Keir

Sorry for being late to the party.  I think if we can pull in the fixes to QEMU
and xend for the fully virtualized live migration, that would be good.

Changesets:

15778
15779
15780

Thanks,
Chris Lalancette

Re: Xen 3.1.1 -- initial patchqueue

[Travis Betak]

On Mon, 10 Sep 2007, Keir Fraser wrote:

> Hi,
>
> A provisional patchqueue for Xen 3.1.1 is available at
> http://xenbits.xensource.com/xen-3.1-testing.pq.hg. This pq partners with
> http://xenbits.xensource.com/xen-3.1-testing.hg.
>
> Please kick this pq around and check whether the patches you want to see in
> 3.1.1 are included.

I didn't notice it in the patch queue but it would be nice to include
the CR8 performance patch although not necessary.

15844-924c153e0cf9
http://xenbits.xensource.com/staging/xen-unstable.hg?rev/924c153e0cf9

   --travis

Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue

[Eduardo Habkost]

On Mon, Sep 10, 2007 at 09:56:11AM +0100, Keir Fraser wrote:
> Hi,
> 
> A provisional patchqueue for Xen 3.1.1 is available at
> http://xenbits.xensource.com/xen-3.1-testing.pq.hg. This pq partners with
> http://xenbits.xensource.com/xen-3.1-testing.hg.
> 
> Please kick this pq around and check whether the patches you want to see in
> 3.1.1 are included.

15214-5710c94e6539 is reverted by 15239-656b8175f4f2.

Should it be removed from the queue and 15239-656b8175f4f2 remade to
remove the parts that revert 15214?

-- 
Eduardo

Re: Xen 3.1.1 -- initial patchqueue

[Keir Fraser]

On 13/9/07 21:57, "Eduardo Habkost" <ehabkost@redhat.com> wrote:

>> Please kick this pq around and check whether the patches you want to see in
>> 3.1.1 are included.
> 
> 15214-5710c94e6539 is reverted by 15239-656b8175f4f2.
> 
> Should it be removed from the queue and 15239-656b8175f4f2 remade to
> remove the parts that revert 15214?

It would be neater, yes.

 -- Keir

Re: Xen 3.1.1 -- initial patchqueue

[Keir Fraser]

On 13/9/07 21:57, "Eduardo Habkost" <ehabkost@redhat.com> wrote:

>> Please kick this pq around and check whether the patches you want to see in
>> 3.1.1 are included.
> 
> 15214-5710c94e6539 is reverted by 15239-656b8175f4f2.
> 
> Should it be removed from the queue and 15239-656b8175f4f2 remade to
> remove the parts that revert 15214?

Now done.

 K.

Re: Xen 3.1.1 -- initial patchqueue

[Alex Williamson]

Hi Keir,

   Is there a staging version of the patch queue tree around that we can
use for testing?  I haven't seen any updates to
http://xenbits.xensource.com/xen-3.1-testing.pq.hg but it seems like
you're putting them in somewhere.  Thanks,

	Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.

Re: Xen 3.1.1 -- initial patchqueue

[Keir Fraser]

Unfortunately not. I'll get it pushed manually. I'd like to collapse it into
xen-3.1-testing.hg on Monday and do a proper release candidate.

 -- Keir

On 14/9/07 17:08, "Alex Williamson" <alex.williamson@hp.com> wrote:

> Hi Keir,
> 
>    Is there a staging version of the patch queue tree around that we can
> use for testing?  I haven't seen any updates to
> http://xenbits.xensource.com/xen-3.1-testing.pq.hg but it seems like
> you're putting them in somewhere.  Thanks,
> 
> Alex