There''s an interesting finding about xen_l1_entry_update in dom0, when we''re doing some debug. We add a printk within xen_l1_entry_update (in xenlinux), and also add a printk at very start of each do_mmu_update (in xen). However what we observed is: - All xen_l1_entry_update prints have no corresponding do_mmu_update prints - All do_mmu_update prints also have no corresponding xen_l1_entry_update. So it seems that do_mmu_update is not invoked although xen_l1_entry_update is implemented as: -- BUG_ON(HYPERVISOR_mmu_update(&u, 1, NULL, DOMID_SELF) < 0); -- 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. :-( Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 31/10/06 09:30, "Tian, Kevin" <kevin.tian@intel.com> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Keir Fraser >Sent: 2006年10月31日 17:44 > >On 31/10/06 09:30, "Tian, Kevin" <kevin.tian@intel.com> 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(). > > -- KeirThe 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@lists.xensource.com http://lists.xensource.com/xen-devel
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@lists.xensource.com >[mailto:xen-devel-bounces@lists.xensource.com] 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@intel.com> 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@lists.xensource.com >http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel