RE: [Xen-devel] Re: is xen_l1_entry_update a nop?

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

Keir, sorry for wrong question. I forgot that dom0 output doesn't sync
with xen's output and they just shown up out of order. 
Xen_l1_entry_update does make effect which explains well to us 
now. :-)

Thanks,
Kevin

>-----Original Message-----
>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Tian,
>Kevin
>Sent: 2006年10月31日 17:53
>To: Keir Fraser; Xen-devel
>Cc: Jiang, Yunhong
>Subject: RE: [Xen-devel] Re: is xen_l1_entry_update a nop?
>
>>From: Keir Fraser
>>Sent: 2006年10月31日 17:44
>>
>>On 31/10/06 09:30, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>>
>>> However it seems that at least all __set_fix_maps depend on
>>> xen_l1_entry_update path, and if it's a nop, how is xenlinux page
>table
>>> modified indeed? Because we did see dom0 working correctly.
>>>
>>> Our environment is x86-64. :-(
>>
>>Have you disassembled xen_l1_entry_update() and checked that it
>>appears to
>>actually execute a hypercall?
>>
>>The BUG_ON() with side effect is considered bad form. It should really
>>be
>>if() BUG().
>>
>> -- Keir
>
>The disassembled code seems correct:
>ffffffff8011ba2c <xen_l1_entry_update>:
>...
>ffffffff8011ba9d:   49 c7 c2 f0 7f 00 00    mov    $0x7ff0,%r10
>ffffffff8011baa4:   e8 77 b5 fe ff          callq  ffffffff80107020
><hypercall_page+0x20>
>
>Actually dom0 works fine and acpi table can be seen correctly. That's
>why I'm interested how dom0 page table is actually updated? :-)
>
>Thanks,
>Kevin
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-devel

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