search for: start_address

Hi, Header says: /* * Unmaps the @count pages starting at @start_address, which were mapped by a * call to xc_gntshr_share_*. Never logs. */ int xc_gntshr_munmap(xc_gntshr *xcg, void *start_address, uint32_t count); But implementation calls: static int linux_gntshr_munmap(xc_gntshr *xcg, xc_osdep_handle h, void *start_address, uint32_t...

...n(void) { int xcg_handle; xcg_handle = xc_gnttab_open(); if(xcg_handle == -1) { printf("Open xcg_handle Error!\n"); return -1; } else printf("Open xcg_handle Success!\n"); void* start_address; start_address = xc_gnttab_map_grant_ref(xcg_handle, 0, 3,PROT_WRITE); if(start_address != NULL) { printf("mapping success!\n"); } else { printf("mapping errror!=n"); } xc_gnttab_close(xcg_h...

...endif + FIXADDR_START_NR, +#endif +}; + /* Address space markers hints */ static struct addr_marker address_markers[] = { { 0, "User Space" }, @@ -331,14 +353,12 @@ static int pt_dump_init(void) #ifdef CONFIG_X86_32 /* Not a compile-time constant on x86-32 */ - address_markers[2].start_address = VMALLOC_START; - address_markers[3].start_address = VMALLOC_END; + address_markers[VMALLOC_START_NR].start_address = VMALLOC_START; + address_markers[VMALLOC_END_NR].start_address = VMALLOC_END; # ifdef CONFIG_HIGHMEM - address_markers[4].start_address = PKMAP_BASE; - address_markers[5].start_ad...

...to mmap() at index %#lx\n", map.index); + + addr = mmap(NULL, PAGE_SIZE * count, prot, MAP_SHARED, xcg_handle, + map.index); + if (addr == MAP_FAILED) { + return NULL; + } + + return addr; +} + +int xc_gnttab_munmap(int xcg_handle, + void *start_address, + uint32_t count) +{ + struct ioctl_gntdev_get_offset_for_vaddr get_offset; + struct ioctl_gntdev_unmap_grant_ref unmap_grant; + int rc; + + /* First, it is necessary to get the offset which was initially used to + * mmap() the pages. + */ + get_offset....

...code to 1. In other debug sections, these values are all resolved to > >zero. > > But, this would not completely solve the problem from > https://reviews.llvm.org/D59553 - Overlapped address ranges. Binutils > approach will solve the problem if the address range specified as > start_address:end_address. While resolving relocations, it would replace > such a range with 1:1. > However, It would not work if address ranges were specified as > start_address:length since the length is not relocated. > This case could be additionally fixed by fast scan debug_info for High_PC >...

So there have been several recent discussions about the issues around DWARF-agnostic linking and gc-sections, linkonce function definitions being dropped, etc - and just how much DWARF-awareness would be suitable in a linker to help with this situation. I'd like to discuss a narrower instance of this issue: Zero length gc'd/deduplicated functions. LLVM seems to at least produce zero

...lem from https://reviews.llvm.org/D59553<https://urldefense.com/v3/__https:/reviews.llvm.org/D59553__;!!JmoZiZGBv3RvKRSx!r2Jqc2yEgxrb2QcQEocDHJBizj0KUKE70_57b4_rsj1TN0qB8NpBvVKtY63HSqgMOg$> - Overlapped address ranges. Binutils approach will solve the problem if the address range specified as start_address:end_address. While resolving relocations, it would replace such a range with 1:1. However, It would not work if address ranges were specified as start_address:length since the length is not relocated. This case could be additionally fixed by fast scan debug_info for High_PC defined as length and ch...

...d corresponding bus\n"); return -EINVAL; } @@ -1253,11 +1308,13 @@ static int unconfigure_boot_device (u8 busno, u8 device, u8 function) pci_bus_read_config_dword (ibmphp_pci_bus, devfn, address[count], &size); pci_bus_write_config_dword (ibmphp_pci_bus, devfn, address[count], start_address); - debug ("start_address is %x\n", start_address); - debug ("busno, device, function %x %x %x\n", busno, device, function); + debug("start_address is %x\n", start_address); + debug("busno, device, function %x %x %x\n", + busno, device, function)...

...d corresponding bus\n"); return -EINVAL; } @@ -1253,11 +1308,13 @@ static int unconfigure_boot_device (u8 busno, u8 device, u8 function) pci_bus_read_config_dword (ibmphp_pci_bus, devfn, address[count], &size); pci_bus_write_config_dword (ibmphp_pci_bus, devfn, address[count], start_address); - debug ("start_address is %x\n", start_address); - debug ("busno, device, function %x %x %x\n", busno, device, function); + debug("start_address is %x\n", start_address); + debug("busno, device, function %x %x %x\n", + busno, device, function)...

...d corresponding bus\n"); return -EINVAL; } @@ -1253,11 +1308,13 @@ static int unconfigure_boot_device (u8 busno, u8 device, u8 function) pci_bus_read_config_dword (ibmphp_pci_bus, devfn, address[count], &size); pci_bus_write_config_dword (ibmphp_pci_bus, devfn, address[count], start_address); - debug ("start_address is %x\n", start_address); - debug ("busno, device, function %x %x %x\n", busno, device, function); + debug("start_address is %x\n", start_address); + debug("busno, device, function %x %x %x\n", + busno, device, function)...

Hi, This set of patches contains initial kexec/kdump implementation for Xen v2 (previous version were posted to few people by mistake; sorry for that). Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code.

Hi, This set of patches contains initial kexec/kdump implementation for Xen v2 (previous version were posted to few people by mistake; sorry for that). Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code.

Hi, This set of patches contains initial kexec/kdump implementation for Xen v2 (previous version were posted to few people by mistake; sorry for that). Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code.

This patch series contains a set of patches making minios rather easier to use, from an application development point of view. Overview of patches: 1 Command line argument parsing support, from Xen. 2 Weak console handler function. 3 Build system tweaks for application directories. 4 Trailing whitespace cleanup. (because it is very messy) Patch 4 is likely to be more controversial than

...m.org/D59553 >> <https://urldefense.com/v3/__https:/reviews.llvm.org/D59553__;!!JmoZiZGBv3RvKRSx!r2Jqc2yEgxrb2QcQEocDHJBizj0KUKE70_57b4_rsj1TN0qB8NpBvVKtY63HSqgMOg$> >> - Overlapped address ranges. Binutils approach will solve the problem if >> the address range specified as start_address:end_address. While resolving >> relocations, it would replace such a range with 1:1. >> However, It would not work if address ranges were specified as >> start_address:length since the length is not relocated. This case could be >> additionally fixed by fast scan debug_info...

...__https:/reviews.llvm.org/D59553__;!!JmoZiZGBv3 > > RvKRSx!r2Jqc2yEgxrb2QcQEocDHJBizj0KUKE70_57b4_rsj1TN0qB8NpBvVKtY63HSqgMOg$ > > > > > >> - Overlapped address ranges. Binutils approach will solve the problem > > if > > >> the address range specified as start_address:end_address. While > > resolving > > >> relocations, it would replace such a range with 1:1. > > >> However, It would not work if address ranges were specified as > > >> start_address:length since the length is not relocated. This case could > > be &g...

...t; > RvKRSx!r2Jqc2yEgxrb2QcQEocDHJBizj0KUKE70_57b4_rsj1TN0qB8NpBvVKtY63HSqgMOg$ > > > > > > > > > >> - Overlapped address ranges. Binutils approach will solve the > > problem > > > > if > > > > >> the address range specified as start_address:end_address. While > > > > resolving > > > > >> relocations, it would replace such a range with 1:1. > > > > >> However, It would not work if address ranges were specified as > > > > >> start_address:length since the length is not re...

...E70_57b4_rsj1TN0qB8NpBvVKtY63HSqgMOg$ > >> > > > > > >> > > > >> - Overlapped address ranges. Binutils approach will solve the > >> > problem > >> > > > if > >> > > > >> the address range specified as start_address:end_address. While > >> > > > resolving > >> > > > >> relocations, it would replace such a range with 1:1. > >> > > > >> However, It would not work if address ranges were specified as > >> > > > >> start_addre...

Hi everyone, I am very excited to see that dom0 pvops is finally coming close to working, so I wanted to give it a try. >From the description it was not clear to me which kernel to chose as base for the patches.hg, so I took the latest (that was ~ 2 weeks ago) kernel on git.kernel.org I could find (post-2.6.28 git tip at that point). I managed to more or less apply all of the patches in the

...t;> >> > > > > > >> >> > > > >> - Overlapped address ranges. Binutils approach will solve the > >> >> > problem > >> >> > > > if > >> >> > > > >> the address range specified as start_address:end_address. While > >> >> > > > resolving > >> >> > > > >> relocations, it would replace such a range with 1:1. > >> >> > > > >> However, It would not work if address ranges were specified as > >> >>...