* Memory Mapping
@ 2011-05-06 14:50 Lakshitha Harshan
2011-05-06 15:31 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 6+ messages in thread
From: Lakshitha Harshan @ 2011-05-06 14:50 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 245 bytes --]
Hi all,
I want to get the access to task structs in domUs to get the memory
addresses of code segments in each process. So how do I read/map the data
correctly which I get through xc_map_foreign_range or xc_map_foreign_batch?
Thanks,
Harshan
[-- Attachment #1.2: Type: text/html, Size: 306 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Memory Mapping
2011-05-06 14:50 Memory Mapping Lakshitha Harshan
@ 2011-05-06 15:31 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 6+ messages in thread
From: Konrad Rzeszutek Wilk @ 2011-05-06 15:31 UTC (permalink / raw)
To: Lakshitha Harshan; +Cc: xen-devel
On Fri, May 06, 2011 at 08:20:18PM +0530, Lakshitha Harshan wrote:
> Hi all,
>
> I want to get the access to task structs in domUs to get the memory
> addresses of code segments in each process. So how do I read/map the data
> correctly which I get through xc_map_foreign_range or xc_map_foreign_batch?
You mean, how do I identify that the blob of memory you mapped is
a task struct? I would suggest you look in the debuggers (gdbsx for example)
and see how they figure this out.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Memory mapping
@ 2009-02-16 16:58 Frederic Beck
2009-02-18 14:35 ` Frederic Beck
0 siblings, 1 reply; 6+ messages in thread
From: Frederic Beck @ 2009-02-16 16:58 UTC (permalink / raw)
To: xen-devel
Hello
I managed to do what i wanted with my module (finally gave up on the
syscall and did everything in the module init), and i foudn the offsets
i was looking for. I later found out that what i've done was already
available via XenAccess (tools/linux-offset-finder).
I have the following offsets:
linux_name = 0x225;
linux_tasks = 0xd0;
linux_mm = 0xe8;
linux_pid = 0x10c;
linux_pgd = 0x24;
linux_addr = 0x84;
After disabling fast system calls handling, i modified do_guest_trap in
xen/arch/x86/traps.c. I get the user regs to have access to the CPU
registers EAX, EIP and ESP (info i wanna log via the tracing). I take
the ESP and apply the mask 0xFFFFF000 to get the base address of the
thread_info struct.
user_regs = guest_cpu_user_regs();
base_addr = (user_regs->esp & 0xFFFFF000);
Then the first 4 bytes after this base_addr are on a regular system a
pointer to a task_struct where the PId of the current task is stored,
which i wanna get. On a regular OS (i tested on Dom0 or DomU) I can
find easily the PID and print it out. I would like to do the same in
the hypervisor.
I tried to map the same code without modification, but i begin reading
memory addresses that do not exist and the hypervisor crashes when i
create my DomU. So far, i'm not very surprised, as there must be some
virtual memory handling that i'm missing.
However, i do not understand well how i can do the mapping. how do i
map this kernel address in the hypervisor to read the right memory
address ?
I guess that this mapping will be different for HVM and PV domains ? Is
there a function that dynamically detects what kind of domain the guest
is ?
Moreover, i found out in XenAccess that the right formula to get the
PID would be
memcpy(&pid, memory + offset + PID_OFFSET - TASKS_OFFSET,4);
I guess that memory is the base adress of the virtual stack. How can i
find that value ? in that case the base_addr i calculated earlier would
be the offset ?
Thanks for the help!
Regards
Fred
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Memory mapping
2009-02-16 16:58 Memory mapping Frederic Beck
@ 2009-02-18 14:35 ` Frederic Beck
0 siblings, 0 replies; 6+ messages in thread
From: Frederic Beck @ 2009-02-18 14:35 UTC (permalink / raw)
To: xen-devel
Well, first of all, i did a wrong copy and paste when i mapped the
code, the mask i apply is 0xFFFFE000.
I checked the control registers, cr0 and cr3 to ensure that paging is
used, i just have to understand now how it is implemented.
Digging right now in several file, prom mm.c to page.h, paging.h to
understand how i can walk through the memory.
Any hint or pointer to documentation would be helpful
Thanks
Fred
Le Mon, 16 Feb 2009 17:58:24 +0100,
Frederic Beck <frederic.beck@loria.fr> a écrit :
> Hello
>
> I managed to do what i wanted with my module (finally gave up on the
> syscall and did everything in the module init), and i foudn the
> offsets i was looking for. I later found out that what i've done was
> already available via XenAccess (tools/linux-offset-finder).
>
> I have the following offsets:
> linux_name = 0x225;
> linux_tasks = 0xd0;
> linux_mm = 0xe8;
> linux_pid = 0x10c;
> linux_pgd = 0x24;
> linux_addr = 0x84;
>
> After disabling fast system calls handling, i modified do_guest_trap
> in xen/arch/x86/traps.c. I get the user regs to have access to the CPU
> registers EAX, EIP and ESP (info i wanna log via the tracing). I take
> the ESP and apply the mask 0xFFFFF000 to get the base address of the
> thread_info struct.
>
> user_regs = guest_cpu_user_regs();
> base_addr = (user_regs->esp & 0xFFFFF000);
>
> Then the first 4 bytes after this base_addr are on a regular system a
> pointer to a task_struct where the PId of the current task is stored,
> which i wanna get. On a regular OS (i tested on Dom0 or DomU) I can
> find easily the PID and print it out. I would like to do the same in
> the hypervisor.
>
> I tried to map the same code without modification, but i begin reading
> memory addresses that do not exist and the hypervisor crashes when i
> create my DomU. So far, i'm not very surprised, as there must be some
> virtual memory handling that i'm missing.
>
> However, i do not understand well how i can do the mapping. how do i
> map this kernel address in the hypervisor to read the right memory
> address ?
>
> I guess that this mapping will be different for HVM and PV domains ?
> Is there a function that dynamically detects what kind of domain the
> guest is ?
>
> Moreover, i found out in XenAccess that the right formula to get the
> PID would be
> memcpy(&pid, memory + offset + PID_OFFSET - TASKS_OFFSET,4);
> I guess that memory is the base adress of the virtual stack. How can i
> find that value ? in that case the base_addr i calculated earlier
> would be the offset ?
>
> Thanks for the help!
>
> Regards
> Fred
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Xeno-unstable crashing at boot
@ 2005-05-16 19:55 Ian Pratt
2005-05-17 11:52 ` Mike Wray
0 siblings, 1 reply; 6+ messages in thread
From: Ian Pratt @ 2005-05-16 19:55 UTC (permalink / raw)
To: Mike Wray; +Cc: xen-devel
> > What hardware is the problem machine? It has an impresively
> long list of
> > ACPI table entries. Since the code being executed is the
> native Linux
> > code it's surprising that it's having problems.
>
> It's a dual processor 2.8GHz xeon, 2GB RAM.
> The cpuinfo was attached to an earlier email.
> I've attached it again, with hwconf.
No, I mean the make and model of the machine. I have 3 different kinds
of dual 2.8GHz Xeon with tg3 NICs that Xen unstable works fine with. It
something specific to your particular machine, probably the BIOS. (BTW:
are their BIOS upgrades available?)
> > Please can you try using a DEBUG=y build of Xen, and then adding
> > show_guest_stack earlier in the failure path.
>
> So 'DEBUG=y make world'?
"make clean; make debug=y dist" should do it.
> Can you suggest what a good place 'earlier in the failure
> path' might be?
I expect you'll get an error message from Xen before the BUG in domain
crash. See where the error message comes from, and then add the
show_guest_stack to the appropriate path.
Thanks,
Ian
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Xeno-unstable crashing at boot
@ 2005-05-17 11:52 ` Mike Wray
2005-05-17 13:26 ` Keir Fraser
0 siblings, 1 reply; 6+ messages in thread
From: Mike Wray @ 2005-05-17 11:52 UTC (permalink / raw)
To: Christian.Limpach; +Cc: Ian Pratt, xen-devel
Christian Limpach wrote:
> On 5/17/05, Mike Wray <mike.wray@hp.com> wrote:
>
>>> "make clean; make debug=y dist" should do it.
>>>
>>>
>>>
>>>>Can you suggest what a good place 'earlier in the failure
>>>>path' might be?
>>>
>>>I expect you'll get an error message from Xen before the BUG in domain
>>>crash. See where the error message comes from, and then add the
>>>show_guest_stack to the appropriate path.
>>
>>A debug build gave the following crash.
>>It's different, a page fault, but there's no previous error message
>>that lets me see where to put the show_guest_stack.
>
>
> The guest stack is now always printed when dom0 fails, which is why
> you get a more relevant error message.
>
> Could you please add "earlyprintk=serial" to the linux command line
> options (CONFIG_EARLY_PRINTK should be enabled in your kernel config
> file by default -- if not, please enable it) and add a call do
> dump_stack() at the beginning of acpi_table_compute_checksum in
> linux-2.6.11-xen-sparse/drivers/acpi/tables.c. Thanks!
OK, I did that and planted a few dump_stack() calls in the acpi code:
Xen version 3.0-devel (mjw@hpl.hp.com) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) Tue
May 17 12:46:45 BST 2005
Latest ChangeSet: 2005/05/16 14:16:20 1.1412 42889d24Cf_SZ1HYkTCtmREploQuWg
(XEN) Physical RAM map:
(XEN) 0000000000000000 - 000000000009fc00 (usable)
(XEN) 000000000009fc00 - 00000000000a0000 (reserved)
(XEN) 00000000000e8000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 000000007fff7b00 (usable)
(XEN) 000000007fff7b00 - 0000000080000000 (reserved)
(XEN) 00000000fec00000 - 0000000100000000 (reserved)
(XEN) System RAM: 2047MB (2096728kB)
(XEN) Xen heap: 10MB (10680kB)
(XEN) CPU0: Before vendor init, caps: bfebfbff 00000000 00000000, vendor = 0
(XEN) CPU#0: Physical ID: 0, Logical ID: 0
(XEN) CPU caps: bfebfbff 00000000 00000000 00000000
(XEN) found SMP MP-table at 000f9bf0
(XEN) ACPI: RSDP (v000 COMPAQ ) @ 0x000ea810
(XEN) ACPI: RSDT (v001 COMPAQ CPQ0054 0x20030821 0x00000000) @ 0x7fff7b40
(XEN) ACPI: FADT (v001 COMPAQ PLACER 0x00000001 0x00000000) @ 0x7fff7bf8
(XEN) ACPI: SSDT (v001 COMPAQ PROJECT 0x00000001 MSFT 0x0100000e) @ 0x7fff894d
(XEN) ACPI: SSDT (v001 COMPAQ CORE_PNP 0x00000001 MSFT 0x0100000e) @ 0x7fff8ee7
(XEN) ACPI: SSDT (v001 COMPAQ CORE_UTL 0x00000001 MSFT 0x0100000e) @ 0x7fff9433
(XEN) ACPI: SSDT (v001 COMPAQ VILLTBL1 0x00000001 MSFT 0x0100000e) @ 0x7fff95ce
(XEN) ACPI: SSDT (v001 COMPAQ LGCYLITE 0x00000001 MSFT 0x0100000e) @ 0x7fff98d6
(XEN) ACPI: SSDT (v001 COMPAQ UART2 0x00000001 MSFT 0x0100000e) @ 0x7fff9e15
(XEN) ACPI: SSDT (v001 COMPAQ FLOPPY 0x00000001 MSFT 0x0100000e) @ 0x7fff9f7c
(XEN) ACPI: MADT (v001 COMPAQ PLACER 0x00000001 0x00000000) @ 0x7fff7c6c
(XEN) ACPI: SSDT (v001 COMPAQ APIC 0x00000001 MSFT 0x0100000e) @ 0x7fffba41
(XEN) ACPI: ASF! (v016 COMPAQ PLACER 0x00000001 0x00000000) @ 0x7fff7cf0
(XEN) ACPI: SSDT (v001 COMPAQ PNP_PRSS 0x00000001 MSFT 0x0100000e) @ 0x7fffa538
(XEN) ACPI: SSDT (v001 COMPAQ UR2_PRSS 0x00000001 MSFT 0x0100000e) @ 0x7fffa95c
(XEN) ACPI: SSDT (v001 COMPAQ FPY_PRSS 0x00000001 MSFT 0x0100000e) @ 0x7fffaac9
(XEN) ACPI: SSDT (v001 COMPAQ S1 0x00000001 MSFT 0x0100000e) @ 0x7fffabe2
(XEN) ACPI: SSDT (v001 COMPAQ L08 0x00000001 MSFT 0x0100000e) @ 0x7fffb7e4
(XEN) ACPI: SSDT (v001 COMPAQ FINIS 0x00000001 MSFT 0x0100000e) @ 0x7fffbbdc
(XEN) ACPI: DSDT (v001 COMPAQ DSDT 0x00000001 MSFT 0x0100000e) @ 0x00000000
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 15:2 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled)
(XEN) Processor #6 15:2 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x07] disabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) Using scheduler: Borrowed Virtual Time (bvt)
(XEN) Initializing CPU#0
(XEN) Detected 2791.052 MHz processor.
(XEN) CPU0 booted
(XEN) Booting processor 1/6 eip 90000
(XEN) Initializing CPU#1
(XEN) CPU1: Before vendor init, caps: bfebfbff 00000000 00000000, vendor = 0
(XEN) CPU#1: Physical ID: 3, Logical ID: 0
(XEN) CPU caps: bfebfbff 00000000 00000000 00000000
(XEN) CPU1 has booted.
(XEN) Total of 2 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN) ..TIMER: vector=0x31 pin1=2 pin2=-1
(XEN) checking TSC synchronization across CPUs: passed.
(XEN) Time init:
(XEN) .... cpu_freq: 00000000:A65C1600
(XEN) .... scale: 00000001:6EE2FB37
(XEN) .... Wall Clock: 1116333274s 140000us
(XEN) mtrr: v2.0 (20020519)
(XEN) (file=grant_table.c, line=1230) Grant table init
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Xen-ELF header found:
'GUEST_OS=linux,GUEST_VER=2.6,XEN_VER=3.0,VIRT_BASE=0xC0000000,LOADER=generic'
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) Dom0 alloc.: 08000000->10000000
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN) Loaded kernel: c0100000->c05d0160
(XEN) Init. ramdisk: c05d1000->c05d1000
(XEN) Phys-Mach map: c05d1000->c05f1000
(XEN) Page tables: c05f1000->c05f4000
(XEN) Start info: c05f4000->c05f5000
(XEN) Boot stack: c05f5000->c05f6000
(XEN) TOTAL: c0000000->c0800000
(XEN) ENTRY ADDRESS: c0100000
(XEN) Scrubbing Free RAM: .....................done.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen).
Linux version 2.6.11.8-xen0 (mjw@wray-m-3.hpl.hp.com) (gcc version 3.2.2 20030222 (Red Hat Linux
3.2.2-5)) #7 Tue May 17 12:47:10 BST 2005
<6>BIOS-provided physical RAM map:
Xen: 0000000000100000 - 0000000008000000 (usable)
<5>128MB LOWMEM available.
<7>On node 0 totalpages: 32768
<7> DMA zone: 32768 pages, LIFO batch:8
<7> Normal zone: 0 pages, LIFO batch:1
<7> HighMem zone: 0 pages, LIFO batch:1
<6>found SMP MP-table at 3bfe2bf0
<6>DMI 2.3 present.
<6>acpi_table_init>
<6>acpi_table_init> dump_stack:
[<c0554a0a>] acpi_table_init+0x25/0xc6
[<c054b7fd>] acpi_boot_table_init+0x2d/0xe0
[<c054d83f>] dmi_scan_machine+0x1f/0x30
[<c0548b0f>] setup_arch+0x43f/0x540
[<c011ceb9>] vprintk+0x149/0x200
[<c05406c8>] start_kernel+0x28/0x1f0
<7>ACPI: RSDP (v000 COMPAQ ) @ 0x000ea810
<6>acpi_table_compute_checksum> table_pointer=fbfef810 length=20
<6>acpi_table_compute_checksum> dump_stack:
[<c022353e>] acpi_table_compute_checksum+0x32/0x64
[<c0554a52>] acpi_table_init+0x6d/0xc6
[<c054b7fd>] acpi_boot_table_init+0x2d/0xe0
[<c054d83f>] dmi_scan_machine+0x1f/0x30
[<c0548b0f>] setup_arch+0x43f/0x540
[<c011ceb9>] vprintk+0x149/0x200
[<c05406c8>] start_kernel+0x28/0x1f0
<6>acpi_table_init> dump_stack:
[<c0554a83>] acpi_table_init+0x9e/0xc6
[<c054b7fd>] acpi_boot_table_init+0x2d/0xe0
[<c054d83f>] dmi_scan_machine+0x1f/0x30
[<c0548b0f>] setup_arch+0x43f/0x540
[<c011ceb9>] vprintk+0x149/0x200
[<c05406c8>] start_kernel+0x28/0x1f0
<6>acpi_table_get_sdt>
<6>acpi_table_get_sdt> dump_stack:
[<c055469e>] acpi_table_get_sdt+0x35/0x37c
[<c0554a89>] acpi_table_init+0xa4/0xc6
[<c054b7fd>] acpi_boot_table_init+0x2d/0xe0
[<c054d83f>] dmi_scan_machine+0x1f/0x30
[<c0548b0f>] setup_arch+0x43f/0x540
[<c011ceb9>] vprintk+0x149/0x200
[<c05406c8>] start_kernel+0x28/0x1f0
<6>acpi_table_compute_checksum> table_pointer=fbff0b40 length=104
<6>acpi_table_compute_checksum> dump_stack:
[<c022353e>] acpi_table_compute_checksum+0x32/0x64
[<c055474a>] acpi_table_get_sdt+0xe1/0x37c
[<c0554a89>] acpi_table_init+0xa4/0xc6
[<c054b7fd>] acpi_boot_table_init+0x2d/0xe0
[<c054d83f>] dmi_scan_machine+0x1f/0x30
[<c0548b0f>] setup_arch+0x43f/0x540
[<c011ceb9>] vprintk+0x149/0x200
[<c05406c8>] start_kernel+0x28/0x1f0
<7>ACPI: RSDT (v001 COMPAQ CPQ0054 0x20030821 0x00000000) @ 0x7fff7b40
<7>ACPI: FADT (v001 COMPAQ PLACER 0x00000001 0x00000000) @ 0x7fff7bf8
<6>acpi_table_compute_checksum> table_pointer=fbff0bf8 length=116
<6>acpi_table_compute_checksum> dump_stack:
[<c022353e>] acpi_table_compute_checksum+0x32/0x64
[<c055483a>] acpi_table_get_sdt+0x1d1/0x37c
[<c0554a89>] acpi_table_init+0xa4/0xc6
[<c054b7fd>] acpi_boot_table_init+0x2d/0xe0
[<c054d83f>] dmi_scan_machine+0x1f/0x30
[<c0548b0f>] setup_arch+0x43f/0x540
[<c011ceb9>] vprintk+0x149/0x200
[<c05406c8>] start_kernel+0x28/0x1f0
<7>ACPI: SSDT (v001 COMPAQ PROJECT 0x00000001 MSFT 0x0100000e) @ 0x7fff894d
<6>acpi_table_compute_checksum> table_pointer=fbff094d length=1434
<6>acpi_table_compute_checksum> dump_stack:
[<c022353e>] acpi_table_compute_checksum+0x32/0x64
[<c055483a>] acpi_table_get_sdt+0x1d1/0x37c
[<c0554a89>] acpi_table_init+0xa4/0xc6
[<c054b7fd>] acpi_boot_table_init+0x2d/0xe0
[<c054d83f>] dmi_scan_machine+0x1f/0x30
[<c0548b0f>] setup_arch+0x43f/0x540
[<c011ceb9>] vprintk+0x149/0x200
[<c05406c8>] start_kernel+0x28/0x1f0
<7>ACPI: SSDT (v001 COMPAQ CORE_PNP 0x00000001 MSFT 0x0100000e) @ 0x7fff8ee7
<6>acpi_table_compute_checksum> table_pointer=fbff0ee7 length=1356
<6>acpi_table_compute_checksum> dump_stack:
[<c022353e>] acpi_table_compute_checksum+0x32/0x64
[<c055483a>] acpi_table_get_sdt+0x1d1/0x37c
[<c0554a89>] acpi_table_init+0xa4/0xc6
[<c054b7fd>] acpi_boot_table_init+0x2d/0xe0
[<c054d83f>] dmi_scan_machine+0x1f/0x30
[<c0548b0f>] setup_arch+0x43f/0x540
[<c011ceb9>] vprintk+0x149/0x200
[<c05406c8>] start_kernel+0x28/0x1f0
(XEN) CPU: 0
(XEN) EIP: 0819:[<c0223558>]
(XEN) EFLAGS: 00210217 CONTEXT: guest
(XEN) eax: 00000000 ebx: 00000432 ecx: c04ac2f8 edx: 00000001
(XEN) esi: fbff1000 edi: 00002834 ebp: 00000002 esp: c053ff28
(XEN) ds: 0821 es: 0821 fs: 0000 gs: 0000 ss: 0821 cs: 0819
(XEN) Stack trace from ESP=ff103fe4:
(XEN) c053ff28 00000821 00000821 00000821 00000000 00000000 ffbf8080
(XEN) Call Trace from ESP=ff103fe4:
(XEN)
(XEN) Guest EIP is c0223558
(XEN) 7fff8ee7 00000024 c0453869 c055483a fbff0ee7 0000054c fbff0ee7 7fff8ee7
(XEN) 00000018 fbff0ee7 fbfef810 00000000 00000010 00000000 c0554a89 fbfef810
(XEN) c0453884 c042fad3 00000000 00000000 c054b7fd 00000010 c054d83f c053ff9c
(XEN) c0548b0f c059ba20 c043afe5 00000000 0000008e 00000006 c053e000 00000001
(XEN) 0000008b 00000000 c011ceb9 0000000a 00000400 c042bbe0 c053ffe4 c053e000
(XEN) c05f4200 c053e000 c05f4200 c059b620 00000000 c05406c8 c053fff4 00000000
(XEN) 00000000 00000000 00000000 c059ba20 0002080b c010006c
(XEN) debugtrace_dump() starting
(XEN) debugtrace_dump() finished
****************************************
CPU0 FATAL PAGE FAULT
[error_code=0000]
Faulting linear address: fbff1000
Aieee! CPU0 is toast...
****************************************
Reboot in five seconds...
Mike
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Xeno-unstable crashing at boot
2005-05-17 11:52 ` Mike Wray
@ 2005-05-17 13:26 ` Keir Fraser
2005-05-17 16:01 ` memory mapping Grzegorz Milos
0 siblings, 1 reply; 6+ messages in thread
From: Keir Fraser @ 2005-05-17 13:26 UTC (permalink / raw)
To: Mike Wray; +Cc: Ian Pratt, xen-devel, Christian.Limpach
On 17 May 2005, at 12:52, Mike Wray wrote:
>> The guest stack is now always printed when dom0 fails, which is why
>> you get a more relevant error message.
>> Could you please add "earlyprintk=serial" to the linux command line
>> options (CONFIG_EARLY_PRINTK should be enabled in your kernel config
>> file by default -- if not, please enable it) and add a call do
>> dump_stack() at the beginning of acpi_table_compute_checksum in
>> linux-2.6.11-xen-sparse/drivers/acpi/tables.c. Thanks!
>
> OK, I did that and planted a few dump_stack() calls in the acpi code:
I've just checked in a fix -- the Xen-specific acpi_map_table()
function was both unnecessary and broken. Hopefully latest unstable
will boot on your test machine.
-- Keir
^ permalink raw reply [flat|nested] 6+ messages in thread
* memory mapping
2005-05-17 13:26 ` Keir Fraser
@ 2005-05-17 16:01 ` Grzegorz Milos
2005-05-17 16:09 ` Grzegorz Milos
0 siblings, 1 reply; 6+ messages in thread
From: Grzegorz Milos @ 2005-05-17 16:01 UTC (permalink / raw)
To: xen-devel
Hi there!
You were in a meeting half an hour ago (or so), so instead of asking in person
I am writing this email.
I am looking at the memory mapping done from a privileged domain, and I am
getting a bit lost in the call stack. Could you possibly fill in the missing
gap (hopefully I did not get everything wrong :) ):
xc_map_foreign_range (userspace dom0)
ioctl (userspace dom0)
privcmd_ioctl (kernelspace dom0)
direct_remap_area_pages (kernelspace dom0)
__HYPERVISOR_do_mmu_update ?
....
do_mmu_update (Xen)
Also, when dom0 decides to unmap some memory, isn't it that domain just drops
appropirate entry from its pagetable and Xen is not even informed? This would
mean that the counter we talked about could not be really made to work that
easily.
What if I wanted to force dom0 to drop some mapping. Any simple way of doing
that?
Thanks
Gregor
--
Quidquid latine dictum sit, altum viditur --- Anon
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: memory mapping
2005-05-17 16:01 ` memory mapping Grzegorz Milos
@ 2005-05-17 16:09 ` Grzegorz Milos
0 siblings, 0 replies; 6+ messages in thread
From: Grzegorz Milos @ 2005-05-17 16:09 UTC (permalink / raw)
To: xen-devel
Oops, sorry, that was supposed to be send to Keir directly. Please ignore.
Gregor
> Hi there!
>
> You were in a meeting half an hour ago (or so), so instead of asking in
> person I am writing this email.
>
> I am looking at the memory mapping done from a privileged domain, and I am
> getting a bit lost in the call stack. Could you possibly fill in the
> missing gap (hopefully I did not get everything wrong :) ):
>
> xc_map_foreign_range (userspace dom0)
> ioctl (userspace dom0)
>
> privcmd_ioctl (kernelspace dom0)
> direct_remap_area_pages (kernelspace dom0)
> __HYPERVISOR_do_mmu_update ?
> ....
>
> do_mmu_update (Xen)
>
>
> Also, when dom0 decides to unmap some memory, isn't it that domain just
> drops appropirate entry from its pagetable and Xen is not even informed?
> This would mean that the counter we talked about could not be really made
> to work that easily.
> What if I wanted to force dom0 to drop some mapping. Any simple way of
> doing that?
>
> Thanks
> Gregor
--
Quidquid latine dictum sit, altum viditur --- Anon
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-05-06 15:31 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-05-06 14:50 Memory Mapping Lakshitha Harshan
2011-05-06 15:31 ` Konrad Rzeszutek Wilk
-- strict thread matches above, loose matches on Subject: below --
2009-02-16 16:58 Memory mapping Frederic Beck
2009-02-18 14:35 ` Frederic Beck
2005-05-16 19:55 Xeno-unstable crashing at boot Ian Pratt
2005-05-17 11:52 ` Mike Wray
2005-05-17 13:26 ` Keir Fraser
2005-05-17 16:01 ` memory mapping Grzegorz Milos
2005-05-17 16:09 ` Grzegorz Milos
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).