[Xen-ia64-devel][PATCH] Add sal emulation to VTI domain
Add sal emulation to VTI domain Signed-off-by Anthony.xu <[EMAIL PROTECTED]> Thanks, -Anthony add_sal_emulation.patch Description: add_sal_emulation.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel][PATCH] fixed a small bug about VTLB
Initialize VHPT headers invalid Signed-off-by: Anthony Xu < [EMAIL PROTECTED] > Thanks, -Anthony fix_vtlb_bug.patch Description: fix_vtlb_bug.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel][PATCH] fixed a bug which causes Oops
Fixed an issue which causes VTI-domain complains "Oops: time tick before it's due" Signed-off-by: Anthony Xu < [EMAIL PROTECTED] > Thanks, -Anthony new_Oops.patch Description: new_Oops.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH]set isr before injecting fault to guest.
Sorry for forgetting the attachment. Patch attached. Thanks -Xiantao > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Zhang, > Xiantao > Sent: 2006年5月31日 10:35 > To: xen-ia64-devel@lists.xensource.com > Subject: [Xen-ia64-devel] [PATCH]set isr before injecting fault to guest. > > This patch intends to fix isr setting before injecting fault to it. > With this small fix, CPU2000 in VTi can pass now. > Thanks > -Xiantao > > ___ > Xen-ia64-devel mailing list > Xen-ia64-devel@lists.xensource.com > http://lists.xensource.com/xen-ia64-devel set_isr.patch Description: set_isr.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH]set isr before injecting fault to guest.
This patch intends to fix isr setting before injecting fault to it. With this small fix, CPU2000 in VTi can pass now. Thanks -Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] xen/ia64 supported hardware
Hi Alex, Fujitsu team has successfully booted Xen/IA64 on PRIMEQUEST (bigiron type business server). So far, we did some basic functional tests on that platform, but plan to do more extensive scalability tests later. Thanks, Yoshi Oguchi -- Alex Williamson wrote: >Hi everyone, > > I know we're probably not to the point of officially supporting >Xen/ia64 on hardware, but I'd like to get a list of known working >hardware setups to use as reference. So far, I know we have: > >Intel Tiger4 >HP rx2600/rx1600/rx2620 (and likely any HP zx1 based system) >Bull? >Fujitsu? >Others? > >I expect Xen/ia64 to work on HP sx1000 based systems as well, but >haven't tested it yet. If you have other systems you can mention, >please add them to the list. Thanks, > > Alex > >-- >Alex Williamson HP Open Source & Linux Org. > > >___ >Xen-ia64-devel mailing list >Xen-ia64-devel@lists.xensource.com >http://lists.xensource.com/xen-ia64-devel > ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] clean up ia64 xen-mkbuildtree-pre
On Tue, 2006-05-30 at 18:59 +0900, Isaku Yamahata wrote: > xen-mkbuildtree-pre of ia64 clean up. > evtchn_ia64.c doesn't exist now. Applied. -- Alex Williamson HP Open Source & Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH]use is_running_on_xen()
On Tue, 2006-05-30 at 18:56 +0900, Isaku Yamahata wrote: > Now xen drivers use is_running_on_xen() to check whether it runs on > xen or bare metal. There remains many if (running_on_xen) in ia64 > specific codes. This patch replaces running_on_xen with is_running_on_xen() Applied. -- Alex Williamson HP Open Source & Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] add missing END(xen_bsw1)
On Tue, 2006-05-30 at 18:56 +0900, Isaku Yamahata wrote: > add missing END(xen_bsw1) Applied. -- Alex Williamson HP Open Source & Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH] simple format cleanup
Applied. -- Alex Williamson HP Open Source & Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH] optimize thash vtlb algorithm
On Sat, 2006-05-27 at 10:45 +0800, Xu, Anthony wrote: > Optimize thash vtlb algorithm. Applied. -- Alex Williamson HP Open Source & Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] xen/ia64 supported hardware
Hi everyone, I know we're probably not to the point of officially supporting Xen/ia64 on hardware, but I'd like to get a list of known working hardware setups to use as reference. So far, I know we have: Intel Tiger4 HP rx2600/rx1600/rx2620 (and likely any HP zx1 based system) Bull? Fujitsu? Others? I expect Xen/ia64 to work on HP sx1000 based systems as well, but haven't tested it yet. If you have other systems you can mention, please add them to the list. Thanks, Alex -- Alex Williamson HP Open Source & Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Should we give up transparent virtualization ?
Transparent paravirtualization has little value to developers or technology providers but definitely has value for distros and software/system/support providers. Note for example that Vmware's PVI (for x86) has transparent paravirtualization because Vmware (the largest provider in the world of virtualization software) considers it valuable. My opinion: we should NOT give up this feature. The recent VP patches are critical to catching up with Xen/x86 functionality so we have to accept some short term minor regressions for this. I think all other patches (including event channel) should not be accepted if they break transparent paravirtualization. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Tristan Gingold > Sent: Tuesday, May 30, 2006 9:19 AM > To: xen-ia64-devel@lists.xensource.com > Subject: [Xen-ia64-devel] Should we give up transparent > virtualization ? > > Hi, > > most big recent patches (dom0vp, event channel) have broken > transparent > virtualization. > Should we give up this feature ? > > If only Dan and I like this feature, this question should be > clearly asked. > > Tristan. > > ___ > Xen-ia64-devel mailing list > Xen-ia64-devel@lists.xensource.com > http://lists.xensource.com/xen-ia64-devel > ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Should we give up transparent virtualization ?
On Tue, 2006-05-30 at 17:18 +0200, Tristan Gingold wrote: > Hi, > > most big recent patches (dom0vp, event channel) have broken transparent > virtualization. > Should we give up this feature ? > > If only Dan and I like this feature, this question should be clearly asked. I'm a fan of it too. I think it's something the distributions will eventually like if we can keep it working. How badly is it broken? Thanks, Alex -- Alex Williamson HP Open Source & Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] preparation for vga acceleration of VTI domain
This patch fixes several minor issues, as a prepare step to support VGA acceleration for VTI domain: - shared vram buffer needs to be mapped as WB in both sides, because the shared vram is the true WB memory though VTI domain is told as UC - Introduced a new pte_mem to indicate p2m entry containing valid mfn when replace p2m entry. Pte_none doesn't work for VTI case, since IO type is encoded into p2m entry which however doesn't contain valid mfn. After above change, guest_physmap_add/remove_page is available to be used by qemu to setup linear buffer for VTI domain. Signed-off-by Kevin Tian <[EMAIL PROTECTED]> Thanks, Kevin vga_accl_prepare.patch Description: vga_accl_prepare.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Should we give up transparent virtualization ?
Hi, most big recent patches (dom0vp, event channel) have broken transparent virtualization. Should we give up this feature ? If only Dan and I like this feature, this question should be clearly asked. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] RFC: adding a dom0_firmware_setup hypercall
Le Mardi 30 Mai 2006 16:42, Tian, Kevin a écrit : > From: Tristan Gingold [mailto:[EMAIL PROTECTED] > > >Sent: 2006年5月30日 15:57 > > > >> Since it's a RFC, it's better if, you could give more detail description > >> about why you need this change and what benefit people can achieve > >> from. For example: > >>- Why do you like to kill DOM0_SETVPUCONTEXT, which has > >> common concept and has been used for ia64 now? > > > >I don't want to kill it. > > Good. Also note setvcpucontext is still called but only to initialize the vcpu. > >>- Why is it the first step toward save&restore? > > > >Currently, SETVPUCONTEXT has side effects: initializing the domain. > >SETVPUCONTEXT has to be used during restore to set all VCPUs. If it > >also > >initialize the domain (ie, set the firmware), bad things may happen. > > I think SETVCPUCONTEXT is the standard interface either for domain > creation or restore This is ok. > and some special things are only required to be done > for vcpu 0. This is the beginning of kludges. > Actually debugger also utilizes SETVCPUCONTEXT to update > the modified context of target vcpu. This is Ok. > If, the code for ia64 version > SETVCPUCONTEXT is not ready for some reason, I think we should try > to fix arch_set_info_guest first. No, it is too early. > >> Based on those information, people can better understand your > >> proposal and thus give appropriate comments. > >> > >> BTW, why can't those new fields (or whole firmware setup structure) be > >> put in vcpu_guest_context without adding a new dom0_op? > > > >For the above reason. > >I think vcpu_guest_context should only modify the vcpu, not the domain. > > Vcpu 0 is special to take responsibility of initializing some domain wise > content. Yes, but it became too kludgy. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] RFC: adding a dom0_firmware_setup hypercall
>From: Tristan Gingold [mailto:[EMAIL PROTECTED] >Sent: 2006年5月30日 15:57 >> >> Since it's a RFC, it's better if, you could give more detail description >> about why you need this change and what benefit people can achieve >> from. For example: >> - Why do you like to kill DOM0_SETVPUCONTEXT, which has >> common concept and has been used for ia64 now? >I don't want to kill it. Good. > >> - Why is it the first step toward save&restore? >Currently, SETVPUCONTEXT has side effects: initializing the domain. >SETVPUCONTEXT has to be used during restore to set all VCPUs. If it >also >initialize the domain (ie, set the firmware), bad things may happen. I think SETVCPUCONTEXT is the standard interface either for domain creation or restore, and some special things are only required to be done for vcpu 0. Actually debugger also utilizes SETVCPUCONTEXT to update the modified context of target vcpu. If, the code for ia64 version SETVCPUCONTEXT is not ready for some reason, I think we should try to fix arch_set_info_guest first. > >> Based on those information, people can better understand your >> proposal and thus give appropriate comments. >> >> BTW, why can't those new fields (or whole firmware setup structure) be >> put in vcpu_guest_context without adding a new dom0_op? >For the above reason. >I think vcpu_guest_context should only modify the vcpu, not the domain. Vcpu 0 is special to take responsibility of initializing some domain wise content. Thanks, Kevin ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Re: [Xen-users] XEN on machines with EFI
You should modify your elilo.conf first and make default option to point xen(for example) as the following lines: prompt timeout=5 default=xen --ànot linux relocatable image=vmlinuz-2.6.9-22.EL label=linux initrd=initrd-2.6.9-22.EL.img read-only append="root=/dev/sda3 console=tty0 console=ttyS1,57600,8n1" image=vmlinuz-2.6-xen0 label=xen vmm=xen.gz initrd=initrd-2.6.12-xen0.img read-only append="com2=57600,8n1 console=com2 sched=bvt dom0_mem=1024M -- nomca console=tty0 console=ttyS1,57600,8n1 root=/dev/sda3" Is it clear ? Thanks -Xiantao From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rodrigo Lord Sent: 2006年5月30日 21:34 To: Akio Takebe; xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] Re: [Xen-users] XEN on machines with EFI Hello! :) So, I mounted the EFI partition and copied the "elilo-3.6-ia64.efi" there! I tried to run it on the EFI shell: fs0:/EFI/debian>elilo-3.6-ia64.efi (here my kernel was loaded normally and the elilo wasn`t updated!) Any specific command to install the "elilo-3.6-ia64.efi" in the EFI shell? Thanks! 2006/5/29, Akio Takebe <[EMAIL PROTECTED]>: Hi, Rodrigo You should not run new elilo.efi on bash. You should install new elilo.efi into /boot/efi of vfat filesystem. And you should run it on EFI shell. In the case of RHEL, we install it into /boot/efi/EFI/redhat/ . Best Regards, Akio Takebe >Hi! > >I tried " ./xen/arch/ia64/tools/xelilo/xlilo.efi " as Xiantao said, but: > >debian-ia64:/home/peso/xen-ia64-unstable.hg#./xen/arch/ia64/tools/xelilo/ >xlilo.efi >bash: ./xen/arch/ia64/tools/xelilo/xlilo.efi: cannot execute binary file > >I downloaded elilo-3.6-ia64.efi in >http://elilo.sourceforge.net/cgi-bin/blosxom as Akio Takebe said, but occurs >the same thing: > >debian-ia64:/home/peso# ./elilo-3.6-ia64.efi >bash: ./elilo-3.6-ia64.efi: cannot execute binary file > >ps: I`m root, and I do "chmod +x" > >Any solution? > >Thanks! :) > > > > > >2006/5/26, Jones, Chris <[EMAIL PROTECTED]>: >> >> I have found the efibootmgr that allows you to build a new label in EFI. >> Every time I try to boot off this new kernel I get a "file not found". >> >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] ] On Behalf Of Rodrigo Lord >> Sent: Thursday, May 25, 2006 7:32 AM >> To: [EMAIL PROTECTED] >> Subject: [Xen-users] XEN on machines with EFI >> >> Hello! >> >> I installed the xen3-unstable on an Itanium2. I`m using Debian Sarge >> 3.1! >> I configured the elilo.conf normally, but when I reboot... not shows the >> option "XEN" on my elilo! >> How do I boot the xen using EFI? Anything different? >> >> Thanks! >> >> ___ >> Xen-users mailing list >> [EMAIL PROTECTED] >> http://lists.xensource.com/xen-users >> > >---text/plain--- >___ >Xen-ia64-devel mailing list > Xen-ia64-devel@lists.xensource.com >http://lists.xensource.com/xen-ia64-devel > >---html-part included links--- >mailto: [EMAIL PROTECTED] >mailto:[EMAIL PROTECTED] >mailto:[EMAIL PROTECTED] ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Re: [Xen-users] XEN on machines with EFI
Hello! :) So, I mounted the EFI partition and copied the "elilo-3.6-ia64.efi" there! I tried to run it on the EFI shell: fs0:/EFI/debian>elilo-3.6-ia64.efi (here my kernel was loaded normally and the elilo wasn`t updated!) Any specific command to install the "elilo-3.6-ia64.efi" in the EFI shell? Thanks! 2006/5/29, Akio Takebe <[EMAIL PROTECTED]>: Hi, RodrigoYou should not run new elilo.efi on bash.You should install new elilo.efi into /boot/efi of vfat filesystem.And you should run it on EFI shell.In the case of RHEL, we install it into /boot/efi/EFI/redhat/ . Best Regards,Akio Takebe>Hi!>>I tried " ./xen/arch/ia64/tools/xelilo/xlilo.efi " as Xiantao said, but:>>debian-ia64:/home/peso/xen-ia64-unstable.hg#./xen/arch/ia64/tools/xelilo/ >xlilo.efi>bash: ./xen/arch/ia64/tools/xelilo/xlilo.efi: cannot execute binary file>>I downloaded elilo-3.6-ia64.efi in>http://elilo.sourceforge.net/cgi-bin/blosxom as Akio Takebe said, but occurs>the same thing:>>debian-ia64:/home/peso# ./elilo-3.6-ia64.efi>bash: ./elilo-3.6-ia64.efi: cannot execute binary file>>ps: I`m root, and I do "chmod +x" >>Any solution?>>Thanks! :)>>2006/5/26, Jones, Chris <[EMAIL PROTECTED]>:>> >> I have found the efibootmgr that allows you to build a new label in EFI.>> Every time I try to boot off this new kernel I get a "file not found". -Original Message- >> From: [EMAIL PROTECTED]>> [mailto:[EMAIL PROTECTED] ] On Behalf Of Rodrigo Lord>> Sent: Thursday, May 25, 2006 7:32 AM>> To: [EMAIL PROTECTED]>> Subject: [Xen-users] XEN on machines with EFI Hello! I installed the xen3-unstable on an Itanium2. I`m using Debian Sarge>> 3.1!>> I configured the elilo.conf normally, but when I reboot... not shows the >> option "XEN" on my elilo!>> How do I boot the xen using EFI? Anything different? Thanks! ___ >> Xen-users mailing list>> [EMAIL PROTECTED]>> http://lists.xensource.com/xen-users ---text/plain--->___>Xen-ia64-devel mailing list> Xen-ia64-devel@lists.xensource.com>http://lists.xensource.com/xen-ia64-devel>>---html-part included links--->mailto: [EMAIL PROTECTED]>mailto:[EMAIL PROTECTED]>mailto:[EMAIL PROTECTED] ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] clean up ia64 xen-mkbuildtree-pre
xen-mkbuildtree-pre of ia64 clean up. evtchn_ia64.c doesn't exist now. -- yamahata # HG changeset patch # User [EMAIL PROTECTED] # Node ID c4d9255bc266bc8ff28475d9b382a04f5ec6811a # Parent b712049222e6d8d1e578191c3d4facee0cdcef08 xen-mkbuildtree-pre of ia64 clean up. evtchn_ia64.c doesn't exist now. PATCHNAME: xen_mkbuildtree_pre_evtchn_ia64_c Signed-off-by: Isaku Yamahata <[EMAIL PROTECTED]> diff -r b712049222e6 -r c4d9255bc266 linux-2.6-xen-sparse/arch/ia64/xen-mkbuildtree-pre --- a/linux-2.6-xen-sparse/arch/ia64/xen-mkbuildtree-preTue May 30 11:43:16 2006 +0900 +++ b/linux-2.6-xen-sparse/arch/ia64/xen-mkbuildtree-preTue May 30 14:49:50 2006 +0900 @@ -18,7 +18,6 @@ ln -sf ../../../arch/ia64/xen/drivers/co #not sure where these ia64-specific files will end up in the future ln -sf ../../../arch/ia64/xen/drivers/xenia64_init.c drivers/xen/core -ln -sf ../../../arch/ia64/xen/drivers/evtchn_ia64.c drivers/xen/core #still a few x86-ism's in various drivers/xen files, patch them #cd drivers/xen ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH]use is_running_on_xen()
Now xen drivers use is_running_on_xen() to check whether it runs on
xen or bare metal. There remains many if (running_on_xen) in ia64
specific codes. This patch replaces running_on_xen with is_running_on_xen()
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID ce26c5b3c020d1f47d6cce81d70b548befac4c99
# Parent fdc4531a8adf9e751a3d84f0eac5d552e776a519
Now xen drivers use is_running_on_xen() to check whether it runs on
xen or bare metal. There remains many if (running_on_xen) in ia64
specific codes. This patch replaces running_on_xen with is_running_on_xen()
PATCHNAME: use_is_running_on_xen
Signed-off-by: Isaku Yamahata <[EMAIL PROTECTED]>
diff -r fdc4531a8adf -r ce26c5b3c020
linux-2.6-xen-sparse/arch/ia64/kernel/iosapic.c
--- a/linux-2.6-xen-sparse/arch/ia64/kernel/iosapic.c Tue May 30 18:45:12
2006 +0900
+++ b/linux-2.6-xen-sparse/arch/ia64/kernel/iosapic.c Tue May 30 18:47:08
2006 +0900
@@ -171,7 +171,7 @@ static inline void xen_iosapic_write(cha
static inline unsigned int iosapic_read(char __iomem *iosapic, unsigned int
reg)
{
- if (!running_on_xen) {
+ if (!is_running_on_xen()) {
writel(reg, iosapic + IOSAPIC_REG_SELECT);
return readl(iosapic + IOSAPIC_WINDOW);
} else
@@ -180,7 +180,7 @@ static inline unsigned int iosapic_read(
static inline void iosapic_write(char __iomem *iosapic, unsigned int reg, u32
val)
{
- if (!running_on_xen) {
+ if (!is_running_on_xen()) {
writel(reg, iosapic + IOSAPIC_REG_SELECT);
writel(val, iosapic + IOSAPIC_WINDOW);
} else
@@ -1015,7 +1015,7 @@ iosapic_system_init (int system_pcat_com
pcat_compat = system_pcat_compat;
#ifdef CONFIG_XEN
- if (running_on_xen)
+ if (is_running_on_xen())
return;
#endif
if (pcat_compat) {
diff -r fdc4531a8adf -r ce26c5b3c020
linux-2.6-xen-sparse/arch/ia64/kernel/irq_ia64.c
--- a/linux-2.6-xen-sparse/arch/ia64/kernel/irq_ia64.c Tue May 30 18:45:12
2006 +0900
+++ b/linux-2.6-xen-sparse/arch/ia64/kernel/irq_ia64.c Tue May 30 18:47:08
2006 +0900
@@ -68,7 +68,7 @@ assign_irq_vector (int irq)
int pos, vector;
#ifdef CONFIG_XEN
extern int xen_assign_irq_vector(int);
- if (running_on_xen)
+ if (is_running_on_xen())
return xen_assign_irq_vector(irq);
#endif /* CONFIG_XEN */
again:
@@ -382,7 +382,7 @@ register_percpu_irq (ia64_vector vec, st
for (irq = 0; irq < NR_IRQS; ++irq)
if (irq_to_vector(irq) == vec) {
#ifdef CONFIG_XEN
- if (running_on_xen)
+ if (is_running_on_xen())
return xen_register_percpu_irq(vec, action, 1);
#endif
desc = irq_descp(irq);
@@ -428,7 +428,7 @@ ia64_send_ipi (int cpu, int vector, int
unsigned long phys_cpu_id;
#ifdef CONFIG_XEN
-if (running_on_xen) {
+if (is_running_on_xen()) {
int irq = -1;
/* TODO: we need to call vcpu_up here */
diff -r fdc4531a8adf -r ce26c5b3c020
linux-2.6-xen-sparse/arch/ia64/kernel/setup.c
--- a/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c Tue May 30 18:45:12
2006 +0900
+++ b/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c Tue May 30 18:47:08
2006 +0900
@@ -248,7 +248,7 @@ reserve_memory (void)
n++;
#ifdef CONFIG_XEN
- if (running_on_xen) {
+ if (is_running_on_xen()) {
rsvd_region[n].start = (unsigned
long)__va((HYPERVISOR_shared_info->arch.start_info_pfn << PAGE_SHIFT));
rsvd_region[n].end = rsvd_region[n].start + PAGE_SIZE;
n++;
@@ -411,7 +411,7 @@ setup_arch (char **cmdline_p)
{
unw_init();
#ifdef CONFIG_XEN
- if (running_on_xen)
+ if (is_running_on_xen())
setup_xen_features();
#endif
@@ -512,7 +512,7 @@ setup_arch (char **cmdline_p)
# endif
}
#ifdef CONFIG_XEN
- if (running_on_xen) {
+ if (is_running_on_xen()) {
extern shared_info_t *HYPERVISOR_shared_info;
extern int xen_init (void);
diff -r fdc4531a8adf -r ce26c5b3c020
linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c
--- a/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c Tue May 30 18:45:12
2006 +0900
+++ b/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c Tue May 30 18:47:08
2006 +0900
@@ -672,7 +672,7 @@ privcmd_mmap(struct file * file, struct
struct xen_ia64_privcmd_vma* privcmd_vma = NULL;
struct resource* res = NULL;
unsigned long i;
- BUG_ON(!running_on_xen);
+ BUG_ON(!is_running_on_xen());
BUG_ON(file->private_data != NULL);
@@ -737,7 +737,7 @@ direct_remap_pfn_range(struct vm_area_st
unsigned long i;
unsigned long offset;
int error = 0;
- BUG_ON(!running_on_xen);
+ BUG_ON(!is_running_on_xen());
#if 0
if (prot != vm->vm_page_prot) {
diff -r f
[Xen-ia64-devel] [PATCH] add missing END(xen_bsw1)
add missing END(xen_bsw1) -- yamahata # HG changeset patch # User [EMAIL PROTECTED] # Node ID fdc4531a8adf9e751a3d84f0eac5d552e776a519 # Parent c073ebdbde8c0f5c9437706b46c4a34f35033c0c add missing END(xen_bsw1) PATCHNAME: add_missing_end_xen_bsw1 Signed-off-by: Isaku Yamahata <[EMAIL PROTECTED]> diff -r c073ebdbde8c -r fdc4531a8adf linux-2.6-xen-sparse/arch/ia64/xen/xenivt.S --- a/linux-2.6-xen-sparse/arch/ia64/xen/xenivt.S Fri May 26 13:41:49 2006 -0600 +++ b/linux-2.6-xen-sparse/arch/ia64/xen/xenivt.S Tue May 30 18:45:12 2006 +0900 @@ -2047,6 +2047,7 @@ GLOBAL_ENTRY(xen_bsw1) ld8 r28=[r30],16; ld8 r29=[r31],16;; ld8 r30=[r30]; ld8 r31=[r31];; br.ret.sptk.many b0 +END(xen_bsw1) #endif .org ia64_ivt+0x7f00 ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] RFC: adding a dom0_firmware_setup hypercall
Le Mercredi 24 Mai 2006 08:50, Tian, Kevin a écrit : > From: Tristan Gingold > > >Sent: 2006年5月23日 22:25 > >Hi, > > > >this a just for review and comments. The purpose is not to use > >DOM0_SETVPUCONTEXT to initialiaze a domain. > >This is the first step for save&restore. > > Since it's a RFC, it's better if, you could give more detail description > about why you need this change and what benefit people can achieve > from. For example: > - Why do you like to kill DOM0_SETVPUCONTEXT, which has > common concept and has been used for ia64 now? I don't want to kill it. > - Why is it the first step toward save&restore? Currently, SETVPUCONTEXT has side effects: initializing the domain. SETVPUCONTEXT has to be used during restore to set all VCPUs. If it also initialize the domain (ie, set the firmware), bad things may happen. > - ... ... > Based on those information, people can better understand your > proposal and thus give appropriate comments. > > BTW, why can't those new fields (or whole firmware setup structure) be > put in vcpu_guest_context without adding a new dom0_op? For the above reason. I think vcpu_guest_context should only modify the vcpu, not the domain. > >[This patch also contains warning cleanup, it will be separated of > >course]. > > It's still better if you could remove hunks which only contains warning > cleanup, and then make people further focusing the very content you > like others to review. :-) Sure. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] RFC: adding a dom0_firmware_setup hypercall
Le Jeudi 25 Mai 2006 04:04, Isaku Yamahata a écrit : > On Tue, May 23, 2006 at 04:25:25PM +0200, Tristan Gingold wrote: > > diff -r 303e1b6bf727 xen/arch/ia64/Rules.mk > > --- a/xen/arch/ia64/Rules.mkSun May 21 07:49:46 2006 -0600 > > +++ b/xen/arch/ia64/Rules.mkTue May 23 14:44:22 2006 +0200 > > @@ -40,7 +40,7 @@ CFLAGS+= -DCONFIG_XEN_IA64_DOM0_VP > > CFLAGS += -DCONFIG_XEN_IA64_DOM0_VP > > endif > > ifeq ($(no_warns),y) > > -CFLAGS += -Wa,--fatal-warnings > > +CFLAGS += -Wa,--fatal-warnings -Werror -Wno-uninitialized > > endif > > > > LDFLAGS := -g > > This isn't the main focus of the patch... > Why is -Wno-uninitialized needed? I think it's too daingerous. -Wuninitialized is really version dependant. Using gcc 4.1, I have a lot of these warnings, which may not appear with previous versions. If we combine -Werror and -Wuninitialized, Xen may not compile with some configurations. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
