Re: [Xen-ia64-devel] [RFC] necessary of `handling regNaT fault' message

2008-04-22 Thread Masaki Kanno
Hi all, I'm not sure that the check is required, though, I think that the message is noisy. So, I make a proposal that replaces the printk() by gdprintk(XENLOG_DEBUG, ...). What do you think? Best regards, Kan Fri, 11 Apr 2008 17:21:34 +0900 (JST), KUWAMURA Shin'ya wrote: Hi, Running

[Xen-ia64-devel] [PATCH 2/3] [RESEND] ia64/pv_ops: preparation: introduce ia64_set_rr0_to_rr4() to make kernel paravirtualization friendly.

2008-04-22 Thread Isaku Yamahata
make kernel paravirtualization friendly by introducing ia64_set_rr0_to_rr4(). ia64/Xen will replace setting rr[0-4] with single hypercall later. Signed-off-by: Isaku Yamahata [EMAIL PROTECTED] --- include/asm-ia64/intrinsics.h |9 + include/asm-ia64/mmu_context.h |6 +- 2

[Xen-ia64-devel] [PATCH 1/3] [RESEND] ia64: preparation: remove extern in irq_ia64.c

2008-04-22 Thread Isaku Yamahata
remove extern declaration of handle_IPI() in irq_ia64.c. Instead, declare it in asm-ia64/smp.h. Later handle_IPI() will be referenced from another file. Signed-off-by: Isaku Yamahata [EMAIL PROTECTED] --- arch/ia64/kernel/irq_ia64.c |1 - include/asm-ia64/smp.h |2 ++ 2 files

[Xen-ia64-devel] [PATCH 0/3] ia64/pv_ops preparation

2008-04-22 Thread Isaku Yamahata
Hi. This patchset is preparation patches for ia64/pv_ops support. They are almost trivial and mainly make kernel paravirtualization friendly. thanks, Diffstat: arch/ia64/kernel/irq_ia64.c|1 - include/asm-ia64/intrinsics.h | 11 +++ include/asm-ia64/mmu_context.h |6

[Xen-ia64-devel] [PATCH 3/3] ia64/pv_ops: preparation: introduce ia64_get_psr_i() to make kernel paravirtualization friendly.

2008-04-22 Thread Isaku Yamahata
__local_irq_save() and local_save_flags() are used to mask interruptions. They read all psr bits that requres whole bit emulation. On the other hand, reading only psr.i, the single bit, can be virtualized cheaply. Signed-off-by: Isaku Yamahata [EMAIL PROTECTED] --- include/asm-ia64/intrinsics.h

[Xen-ia64-devel] [PATCH 0/3] xen: more portability patches

2008-04-22 Thread Isaku Yamahata
Hi Jeremy. Here are the 3 patches for ia64/xen support. The first one is just to move manage.c under drivers/xen. This is trivial. The second and third ones are for compilation fix on ia64. You may want to postpone those 2 patches to make your merge task easy as you said before. thanks,

[Xen-ia64-devel] [PATCH 1/3] xen: Move manage.c to drivers/xen for ia64/xen support.

2008-04-22 Thread Isaku Yamahata
move arch/x86/xen/manage.c under drivers/xen/to share codes with x86 and ia64. ia64/xen also uses manage.c Signed-off-by: Isaku Yamahata [EMAIL PROTECTED] --- arch/x86/xen/Makefile |2 +- drivers/xen/Makefile |2 +- {arch/x86 = drivers}/xen/manage.c |0 3

[Xen-ia64-devel] [PATCH 2/3] xen: add missing definitions in include/xen/interface/memory.h which ia64/xen needs

2008-04-22 Thread Isaku Yamahata
Add xen handles realted definitions for xen memory which ia64/xen needs. Pointer argumsnts for ia64/xen hypercall are passed in pseudo physical address (guest physical address) so that it is required to convert guest kernel virtual address into pseudo physical address. The xen guest handle

[Xen-ia64-devel] [PATCH 3/3] xen: compilation fix to balloon driver for ia64 support.

2008-04-22 Thread Isaku Yamahata
fix compilation error of ballon driver on ia64. extent_start member is pointer argument. On x86 pointer argument for xen hypercall is passed as virtual address. On the other hand, ia64 and ppc, pointer argument is passed in pseudo physical address. (guest physicall address.) So they must be passed

[Xen-ia64-devel] pv_ops: ANN: the new branch, xen-ia64-domu-minimal-2008apr21

2008-04-22 Thread Isaku Yamahata
The pv_ops development branch is switched to xen-ia64-domu-minimal-2008apr21 which is based on linux 2.6.25 + ia64 pull + some. Please make sure your working repository is uptodate. If you have already patches for the old branch, you can send ones for the old branch. But it would be applyed to

[Xen-ia64-devel] Re: [PATCH 11/15] ia64/pv_ops: paravirtualize NR_IRQS

2008-04-22 Thread Jes Sorensen
Make NR_IRQ overridable by each pv instances. Pv instance may need each own number of irqs so that NR_IRQS should be the maximum number of nr_irqs each pv instances need. This really looks dodgy. +#ifdef CONFIG_PARAVIRT + +/* Determine the maximal NR_IRQ which each pv instances require. + *

[Xen-ia64-devel] Re: [PATCH 04/15] ia64/pv_ops: introduce pv_info which describes some random info.

2008-04-22 Thread Jes Sorensen
Isaku == Isaku Yamahata [EMAIL PROTECTED] writes: Isaku introduce pv_info which describes some randome info about Isaku underlying execution environment. Hi Isaku, I am missing some of the patches in this series for some reason. However, I'd like to open the discussion and ask why you are

[Xen-ia64-devel] Re: [PATCH 04/15] ia64/pv_ops: introduce pv_info which describes some random info.

2008-04-22 Thread Isaku Yamahata
On Tue, Apr 22, 2008 at 05:16:41AM -0400, Jes Sorensen wrote: Isaku == Isaku Yamahata [EMAIL PROTECTED] writes: Isaku introduce pv_info which describes some randome info about Isaku underlying execution environment. Hi Isaku, Hi. I'm very glad to get reply. I am missing some of the

[Xen-ia64-devel] Re: [PATCH 11/15] ia64/pv_ops: paravirtualize NR_IRQS

2008-04-22 Thread Isaku Yamahata
On Tue, Apr 22, 2008 at 05:08:22AM -0400, Jes Sorensen wrote: Make NR_IRQ overridable by each pv instances. Pv instance may need each own number of irqs so that NR_IRQS should be the maximum number of nr_irqs each pv instances need. This really looks dodgy. +#ifdef CONFIG_PARAVIRT

[Xen-ia64-devel] Re: [PATCH 04/15] ia64/pv_ops: introduce pv_info which describes some random info.

2008-04-22 Thread Jes Sorensen
Isaku Yamahata wrote: Our justification is as follows. The difference is its scope. pv_ops for virtualization and machine vector is for platform difference. - pv_ops does cover the area which shouldn't belong to machine vector. For example, ia64 intrinsics paravirtualization. It shouldn't

[Xen-ia64-devel] Re: [PATCH 04/15] ia64/pv_ops: introduce pv_info which describes some random info.

2008-04-22 Thread Isaku Yamahata
On Tue, Apr 22, 2008 at 12:37:06PM +0200, Jes Sorensen wrote: - pv_ops covers some performance critical part (e.g. ia64 intrinsics) so that in the future they should be optimized with binary patch like x86. We had the experimental patch to do that, but they are dropped for the merge.

[Xen-ia64-devel] RE: [PATCH 04/15] ia64/pv_ops: introduce pv_info which describes some random info.

2008-04-22 Thread Dong, Eddie
Rather than making these binary patches, why not make them fast syscalls and using a vdso page. Some of the priviledged instructions are simply reads and we could have that information in a read-only data page, so there is no need to do a context switch at all. Others could benefit from a

[Xen-ia64-devel] Re: [PATCH 04/15] ia64/pv_ops: introduce pv_info which describes some random info.

2008-04-22 Thread Jes Sorensen
Dong, Eddie wrote: Rather than making these binary patches, why not make them fast syscalls and using a vdso page. Some of the priviledged instructions are simply reads and we could have that information in a read-only data page, so there is no need to do a context switch at all. Others could

[Xen-ia64-devel] Re: [PATCH 11/15] ia64/pv_ops: paravirtualize NR_IRQS

2008-04-22 Thread Jes Sorensen
Isaku Yamahata wrote: I'm willing to introduce something like PARAVIRT_NR_IRQS, but I don't see how PARAVIRT_NR_IRQS solves the issues. What I want here is to define by cpp #define PARAVIRT_NR_IRQS\ max(

[Xen-ia64-devel] RE: [PATCH 04/15] ia64/pv_ops: introduce pv_info which describes some random info.

2008-04-22 Thread Dong, Eddie
Jes Sorensen wrote: Dong, Eddie wrote: Rather than making these binary patches, why not make them fast syscalls and using a vdso page. Some of the priviledged instructions are simply reads and we could have that information in a read-only data page, so there is no need to do a context switch

[Xen-ia64-devel] Re: [PATCH 04/15] ia64/pv_ops: introduce pv_info which describes some random info.

2008-04-22 Thread Jes Sorensen
Dong, Eddie wrote: My understanding is that code such as IVT table are well tuned and you are really difficult to pursuade people to replace those privilege resource access instruction to use vdso or something equalvalent such as mov GRx=CRy. For those C code previlige resource access, like

[Xen-ia64-devel] [patch 05/12] ia64: kexec: Header changes in preparation for EFI RID

2008-04-22 Thread Simon Horman
The EFI RID patches require pal.h to (directly or indirectly) have access to GRANULE_SIZE which is defined in pgtable.h. This effectively causes a header loop as pgtable.h includes system.h and system.h includes pal.h. This patch breaks that loop by not including pal.h in system.h if XEN is

[Xen-ia64-devel] [patch 03/12] ia64: kexec: Unpin the correct VHPT TR in ia64_do_tlb_purge

2008-04-22 Thread Simon Horman
When ia64_do_tlb_purge is called indrectly from play_dead() GET_VA_VCPU_VHPT_MADDR(r2,r3) does not give the value of the VHPT pinned into the TLB. I believe that this is because current is changed between pinning and calling play_dead, though I am not sure of the exact scemantics. In any case, by

[Xen-ia64-devel] [patch 01/12] ia64: kexec: Define macros for EFI RID

2008-04-22 Thread Simon Horman
Macros to be called by PAL, SAL and EFI to switch into and out of EFI RID. Cc: Tristan Gingold [EMAIL PROTECTED] Cc: Isaku Yamahata [EMAIL PROTECTED] Cc: Alex Williamson [EMAIL PROTECTED] Cc: Aron Griffis [EMAIL PROTECTED] Signed-off-by: Simon Horman [EMAIL PROTECTED] --- Thu, 22 Nov 2007

[Xen-ia64-devel] [patch 00/12] ia64: kexec: Map EFI memory in the same location as Linux (v20080423)

2008-04-22 Thread Simon Horman
Hi, here is another spin of the kexec EFI patches. This patchset adds repining of the VPD (privregs) in the ITLB which fixes a bug whereby the hypervisor would lock up when HVM domains were launched. Standard Intro: This series is what I believe to be a fairly complete set of patches to map

[Xen-ia64-devel] [patch 02/12] ia64: kexec: define EFI offsets for identity mapping

2008-04-22 Thread Simon Horman
This is used by paches that move the EFI runtime regions into what is normally guest space. A description of why this mapping is made is included in the patch that makes the mapping. Cc: Tristan Gingold [EMAIL PROTECTED] Cc: Isaku Yamahata [EMAIL PROTECTED] Cc: Alex Williamson [EMAIL PROTECTED]

[Xen-ia64-devel] [patch 07/12] ia64: kexec: Unpin VPD (privregs) on kexec

2008-04-22 Thread Simon Horman
If an HVM domain has been creaated then VPD (privregs) will be pinned into the ITLB and thus should be unpinned on kexec. Cc: Isaku Yamahata [EMAIL PROTECTED] Cc: Alex Williamson [EMAIL PROTECTED] Cc: Aron Griffis [EMAIL PROTECTED] Signed-off-by: Simon Horman [EMAIL PROTECTED] --- This depends

[Xen-ia64-devel] [patch 08/12] ia64: kexec: Allow EFI_RID to be used in ivt.S

2008-04-22 Thread Simon Horman
This is a preliminary patch to allow itentity mapping of EFI memory to be handled in the asm page fault handlers. Cc: Isaku Yamahata [EMAIL PROTECTED] Cc: Tristan Gingold [EMAIL PROTECTED] Cc: Alex Williamson [EMAIL PROTECTED] Cc: Aron Griffis [EMAIL PROTECTED] Signed-off-by: Simon Horman [EMAIL

[Xen-ia64-devel] [patch 11/12] ia64: kexec: add __va_efi

2008-04-22 Thread Simon Horman
sal_desc_entry_point() converts physical addresses into virtual addresses using __va() and these virtual addresses are used to register the SAL and PAL handlers - which exist in firmware memory. As the mapping of firmware memory is being moved from a PAGE_OFFSET of (0xf 60) to a PAGE_OFFSET of

[Xen-ia64-devel] [patch 09/12] ia64: kexec: Add identity mapping of EFI memory to alt_dtlb_miss

2008-04-22 Thread Simon Horman
Cc: Isaku Yamahata [EMAIL PROTECTED] Cc: Tristan Gingold [EMAIL PROTECTED] Cc: Alex Williamson [EMAIL PROTECTED] Cc: Aron Griffis [EMAIL PROTECTED] Signed-off-by: Simon Horman [EMAIL PROTECTED] --- Tue, 04 Dec 2007 22:19:26 +0900 * Remove duplicate comment Thu, 06 Dec 2007 16:09:14 +0900 * rr

[Xen-ia64-devel] [patch 06/12] ia64: kexec: Repining for EFI RID

2008-04-22 Thread Simon Horman
A cut down version of set_one_rr (and ia64_new_rr7) for use when switching to the EFI RID for SAL, PAL and EFI calls. There seems to be no need to repin: palcode, mapped_regs or vhpt in this case. If it turns they do need to be repinned then special care needs to betaken to track the correct

[Xen-ia64-devel] [patch 04/12] ia64: kexec: Unpin shared_info and mapped_regs TR in ia64_do_tlb_purge

2008-04-22 Thread Simon Horman
Unpinning shared_info and mapped_regs seems to be missing from ia64_do_tlb_purge and seems to be needed for kexec. Like VHPT, the pinned value is recored in a percpu variable so that the correct value can be unpinned. Cc: Isaku Yamahata [EMAIL PROTECTED] Signed-off-by: Simon Horman [EMAIL

[Xen-ia64-devel] [patch 12/12] ia64: kexec: Map EFI regions into the same place they are maped into in Linux

2008-04-22 Thread Simon Horman
Map EFI regions into the same place they are maped into in Linux This is because of an unfortunate problem with the way that EFI interacts with Kexec. The call to map the EFI regions may only be made once. This means that after Kexec the EFI regions must be mapped into the same region that they

[Xen-ia64-devel] ia64: Fix build problem when VHPT_ENABLED isn't defined

2008-04-22 Thread Simon Horman
arch.vhpt_page and arch.vhpt_maddr don't exist unless VHPT_ENABLED is defined. asm-offsets.c: In function `foo': asm-offsets.c:257: error: structure has no member named `vhpt_page' asm-offsets.c:259: error: structure has no member named `vhpt_maddr' Signed-off-by: Simon Horman [EMAIL PROTECTED]

[Xen-ia64-devel] Re: [PATCH 11/15] ia64/pv_ops: paravirtualize NR_IRQS

2008-04-22 Thread Isaku Yamahata
On Tue, Apr 22, 2008 at 02:05:59PM +0200, Jes Sorensen wrote: Isaku Yamahata wrote: I'm willing to introduce something like PARAVIRT_NR_IRQS, but I don't see how PARAVIRT_NR_IRQS solves the issues. What I want here is to define by cpp #define PARAVIRT_NR_IRQS

[Xen-ia64-devel] [Patch][RFC] Avoid to domain_put_page pte of INVALID_M2P_ENTRY

2008-04-22 Thread Akio Takebe
Hi, When we tested network between domU - dom0 with FTP load tools, we hitted BUG() in hypervisor. It is always reproducible for a few minutes. At that time, we got the following message. vmi15.sky.yk.fujitsu.co.jp login: (XEN) Xen BUG at mm.c:1254 (XEN) FIXME: implement ia64