WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

Re: [Xen-ia64-devel] progress on blktap

To: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-ia64-devel] progress on blktap
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Wed, 18 Oct 2006 10:31:40 +0900
Delivery-date: Tue, 17 Oct 2006 18:31:58 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20061017205458.GB27879@xxxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20061017205458.GB27879@xxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
Hi Aron.

This is the Xen/IA64 specific issues that Xen/IA64 doesn't
support grant table page mapping with GNTMAP_application_map and/or
GNTMAP_contains_pte specified.
Xen/IA64 fully virtualizes MMU and Xen/IA64 grant table mapping
mechanism is based on pseudo physical address, not virtual address,
so that those flags doesn't make sense.

I suppose that the basic functionalities of Xen/IA64 VMM itself
necessary for blktap are already there and only the Linux part
effort is necessary.
Probably the grant table interface for GNTMAP_application_map and
GNTMAP_contains_pte should be re-defined for
XENFEAT_auto_translated_physmap mode and the blktap code should be
made ware of it.
Maybe specialized mmap method and vm area methods are also necessary.

thanks.

On Tue, Oct 17, 2006 at 04:54:58PM -0400, Aron Griffis wrote:
> I started with Chris Wright's patch and "backported" it to
> xen-ia64-unstable, from 2.6.18 base to 2.6.16, which means simply that
> ioremap.c isn't available so the code needs another home.
> hypervisor.c seems like the right place.
> 
> The patch at the bottom of this mail allows blktap to build.  The
> kernel boots and other backend methods continue to work (tested
> booting domu).  blktap method starts to boot but hits a problem.
> 
> /etc/xen/domu-g2-blktap contains:
>     kernel = "/boot/vmlinux-xen.gz"
>     memory = 512
>     name = "domu-g2"
>     vif = [ '' ]
>     disk = [ 'tap:aio:/var/lib/xen/domu-g2.img,hda1,w' ]
>     root = "/dev/hda1 ro"
> 
> domu messages:
> ...
> netfront: device eth0 has flipping receive path.
> IP route cache hash table entries: 4096 (order: 1, 32768 bytes)
> TCP established hash table entries: 16384 (order: 4, 262144 bytes)
> TCP bind hash table entries: 16384 (order: 4, 262144 bytes)
> TCP: Hash tables configured (established 16384 bind 16384)
> TCP reno registered
> TCP bic registered
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> Bridge firewalling registered
> xen privcmd uses pseudo physical addr range [0x20000000, 0x3ffff000000] 
> (4193776MB)
> Xen p2m: assign p2m table of [0x0000000000000000, 0x0000000020000000)
> Xen p2m: to [0x0000000020000000, 0x0000000023ffc000) (65536 KBytes)
> [stops here]
> 
> dom0 messages:
> ...
> (XEN) tlb_track_allocate_entries:68 allocated 256 num_entries 256 num_free 256
> (XEN) tlb_track_create:114 hash 0xf0000040e5858000 hash_size 512 
> (XEN) ### domain f000000007b74080: rid=80000-c0000 mp_rid=2000
> (XEN) arch_domain_create: domain=f000000007b74080
> (XEN) DomainU EFI build up: ACPI 2.0=0x1000
> (XEN) dom mem: type=13, attr=0x8000000000000008, 
> range=[0x0000000000000000-0x0000000000001000) (4KB)
> (XEN) dom mem: type=10, attr=0x8000000000000008, 
> range=[0x0000000000001000-0x0000000000002000) (4KB)
> (XEN) dom mem: type= 6, attr=0x8000000000000008, 
> range=[0x0000000000002000-0x0000000000003000) (4KB)
> (XEN) dom mem: type= 7, attr=0x0000000000000008, 
> range=[0x0000000000003000-0x000000001fff4000) (511MB)
> (XEN) dom mem: type=12, attr=0x0000000000000001, 
> range=[0x00000ffffc000000-0x0000100000000000) (64MB)
> (XEN) vcpu_get_lrr0: Unmasked interrupts unsupported
> (XEN) vcpu_get_lrr1: Unmasked interrupts unsupported
> (XEN) Domain set shared_info_va to 0xfffffffffff00000
> (XEN) Linux version 2.6.16.29-xen (agriffis@xxxxxxxxxxxxxxx) (gcc version 
> 4.1.1 (Gentoo 4.1.1-r1)) #1 SMP Tue Oct 17 13:52:41 EDT 2006
> EFI v1.00 by Xen/ia64: SALsystab=0x2178 ACPI 2.0=0x1000
> SAL 0.1: Xen/ia64 Xen/ia64 version 0.0
> SAL: AP wakeup using external interrupt vector 0xf3
> xen_pal_emulator: UNIMPLEMENTED PAL CALL 42!!!!
> (XEN) No logical to physical processor mapping available
> ACPI: Local APIC address c0000000fee00000
> ACPI: Error parsing MADT - no IOSAPIC entries
> 1 CPUs available, 1 CPUs total
> Running on Xen! start_info_pfn=0x7ffd nr_pages=32768 flags=0x0
> *** CALLED SAL_MC_SET_PARAMS.  IGNORED...
> (XEN) *** CALLED SAL_MC_SET_PARAMS.  IGNORED...
> (XEN) *** CALLED SAL_SET_VECTORS 0.  IGNORED...
> (XEN) *** CALLED SAL_SET_VECTORS 1.  IGNORED...
> (XEN) MCA related initialization done
> SMP: Allowing 1 CPUs, 0 hotplug CPUs
> Built 1 zonelists
> Kernel command line:  root=/dev/hda1 ro
> PID hash table entries: 2048 (order: 11, 65536 bytes)
> lookup_domain_mpa: d 0xf000000007b74080 id 2 current 0xf000000007b58000 id 0
> (XEN) lookup_domain_mpa: bad mpa 0xffffc019064 (=> 0x20000000)
> (XEN) Warning: UC to WB for mpaddr=ffffc019064
> gnttab_map_grant_ref_pre:308 GNTMAP_application_map is not supported yet: 
> flags 0x1a
> xvd 2[7209]: bugcheck! 0 [1]
> Modules linked in:
> 
> Pid: 7209, CPU 0, comm:                xvd 2
> psr : 0000001008026010 ifs : 800000000000038b ip  : [<a00000010006a170>]    
> Not tainted
> ip is at HYPERVISOR_grant_table_op+0x170/0x280
> unat: 0000000000000000 pfs : 800000000000038b rsc : 000000000000000b
> rnat: 40000000001475d0 bsps: 400000000012b9c0 pr  : 0000000000006681
> ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70433f
> csd : 0000000000000000 ssd : 0000000000000000
> b0  : a00000010006a170 b6  : a000000100072e20 b7  : a0000001000681b0
> f6  : 1003e0000000000000028 f7  : 1003e28f5c28f5c28f5c3
> f8  : 1003e00000000000000fa f9  : 1003e0000000032000000
> f10 : 1003e000000003b9aca00 f11 : 1003ed6bf94d5e57a42bd
> r1  : a00000010102d710 r2  : a000000100e52738 r3  : a000000100e52738
> r8  : 0000000000000031 r9  : fffffffffff00001 r10 : 0000000000000000
> r11 : fffffffffff04c20 r12 : e000000016447b20 r13 : e000000016440000
> r14 : 0000000000004000 r15 : 0000000000000001 r16 : fffffffffff04c18
> r17 : e000000000014248 r18 : 0000000000000001 r19 : e000000000014b58
> r20 : e00000001c418030 r21 : e00000001c418030 r22 : 0000000000000001
> r23 : e0000000000152a8 r24 : e0000000000152a0 r25 : 0000000000000750
> r26 : 0000000000000730 r27 : 0000000000000073 r28 : 0000000000000073
> r29 : 0000000000000073 r30 : d6bf94d5e57a42bd r31 : e00000001c418078
> 
> Call Trace:
>  [<a00000010001ca20>] show_stack+0x40/0xa0
>                                 sp=e0000000164476b0 bsp=e000000016441260
>  [<a00000010001d320>] show_regs+0x840/0x880
>                                 sp=e000000016447880 bsp=e000000016441208
>  [<a0000001000415e0>] die+0x1c0/0x3c0
>                                 sp=e000000016447880 bsp=e0000000164411b8
>  [<a000000100041830>] die_if_kernel+0x50/0x80
>                                 sp=e0000000164478a0 bsp=e000000016441188
>  [<a000000100042f60>] ia64_bad_break+0x260/0x4a0
>                                 sp=e0000000164478a0 bsp=e000000016441160
>  [<a0000001000685a0>] xen_leave_kernel+0x0/0x3b0
>                                 sp=e000000016447950 bsp=e000000016441160
>  [<a00000010006a170>] HYPERVISOR_grant_table_op+0x170/0x280
>                                 sp=e000000016447b20 bsp=e000000016441108
>  [<a0000001006ae3c0>] dispatch_rw_block_io+0x640/0xd00
>                                 sp=e000000016447b20 bsp=e000000016441030
>  [<a0000001006af600>] tap_blkif_schedule+0x6c0/0x9c0
>                                 sp=e000000016447df0 bsp=e000000016440fd0
>  [<a0000001000bbfc0>] kthread+0x180/0x200
>                                 sp=e000000016447e20 bsp=e000000016440f98
>  [<a00000010001aed0>] kernel_thread_helper+0x30/0x60
>                                 sp=e000000016447e30 bsp=e000000016440f70
>  [<a0000001000110c0>] start_kernel_thread+0x20/0x40
>                                 sp=e000000016447e30 bsp=e000000016440f70
> 
> diff -r e06634ca24f6 buildconfigs/linux-defconfig_xen0_ia64
> --- a/buildconfigs/linux-defconfig_xen0_ia64  Mon Oct 16 22:44:25 2006 -0400
> +++ b/buildconfigs/linux-defconfig_xen0_ia64  Tue Oct 17 13:48:22 2006 -0400
> @@ -1529,7 +1529,7 @@ CONFIG_XEN_XENBUS_DEV=y
>  CONFIG_XEN_XENBUS_DEV=y
>  CONFIG_XEN_BACKEND=y
>  CONFIG_XEN_BLKDEV_BACKEND=y
> -# CONFIG_XEN_BLKDEV_TAP is not set
> +CONFIG_XEN_BLKDEV_TAP=y
>  CONFIG_XEN_NETDEV_BACKEND=y
>  # CONFIG_XEN_NETDEV_PIPELINED_TRANSMITTER is not set
>  CONFIG_XEN_NETDEV_LOOPBACK=y
> diff -r e06634ca24f6 buildconfigs/linux-defconfig_xen_ia64
> --- a/buildconfigs/linux-defconfig_xen_ia64   Mon Oct 16 22:44:25 2006 -0400
> +++ b/buildconfigs/linux-defconfig_xen_ia64   Tue Oct 17 13:48:32 2006 -0400
> @@ -1535,7 +1535,7 @@ CONFIG_XEN_XENBUS_DEV=y
>  CONFIG_XEN_XENBUS_DEV=y
>  CONFIG_XEN_BACKEND=y
>  CONFIG_XEN_BLKDEV_BACKEND=y
> -# CONFIG_XEN_BLKDEV_TAP is not set
> +CONFIG_XEN_BLKDEV_TAP=y
>  CONFIG_XEN_NETDEV_BACKEND=y
>  # CONFIG_XEN_NETDEV_PIPELINED_TRANSMITTER is not set
>  CONFIG_XEN_NETDEV_LOOPBACK=y
> diff -r e06634ca24f6 linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c
> --- a/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c Mon Oct 16 22:44:25 
> 2006 -0400
> +++ b/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c Tue Oct 17 00:05:31 
> 2006 -0400
> @@ -1050,3 +1050,27 @@ EXPORT_SYMBOL_GPL(p2m_pte);
>  EXPORT_SYMBOL_GPL(p2m_pte);
>  EXPORT_SYMBOL_GPL(p2m_phystomach);
>  #endif
> +
> +/*
> + * XXX lookup_pte_fn() and create_lookup_pte_addr() are duplicated from
> + * arch/i386/mm/ioremap-xen.c; should these be consolidated?
> + */
> +static int 
> +lookup_pte_fn(pte_t *pte, struct page *pmd_page, unsigned long addr, 
> +           void *data)
> +{
> +     uint64_t *ptep = (uint64_t *)data;
> +     if (ptep)
> +             *ptep = ((uint64_t)pfn_to_mfn(page_to_pfn(pmd_page)) <<
> +                      PAGE_SHIFT) | ((unsigned long)pte & ~PAGE_MASK);
> +     return 0;
> +}
> +
> +int 
> +create_lookup_pte_addr(struct mm_struct *mm, unsigned long address,
> +                    uint64_t *ptep)
> +{
> +     return apply_to_page_range(mm, address, PAGE_SIZE,
> +                                lookup_pte_fn, ptep);
> +}
> +EXPORT_SYMBOL(create_lookup_pte_addr);
> diff -r e06634ca24f6 linux-2.6-xen-sparse/include/asm-ia64/hypervisor.h
> --- a/linux-2.6-xen-sparse/include/asm-ia64/hypervisor.h      Mon Oct 16 
> 22:44:25 2006 -0400
> +++ b/linux-2.6-xen-sparse/include/asm-ia64/hypervisor.h      Tue Oct 17 
> 00:07:29 2006 -0400
> @@ -142,6 +142,11 @@ int privcmd_mmap(struct file * file, str
>  
>  #endif /* !CONFIG_VMX_GUEST */
>  
> +struct mm_struct;
> +int create_lookup_pte_addr(struct mm_struct *mm, 
> +                        unsigned long address,
> +                        uint64_t *ptep);
> +
>  #define __pte_ma(_x) ((pte_t) {(_x)})        /* unmodified use */
>  #define pfn_pte_ma(_x,_y)    __pte_ma(0)     /* unmodified use */
>  
> 
> _______________________________________________
> Xen-ia64-devel mailing list
> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-ia64-devel

-- 
yamahata

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

<Prev in Thread] Current Thread [Next in Thread>