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
[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
[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
[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
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 saverestore? 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
[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] [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
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
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
[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][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
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] 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]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] 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] 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
[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] [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] 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
[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
