>>> On 23.04.15 at 06:03, <xumengpa...@gmail.com> wrote: > The first question is: > Why should we use "foreigndom >> 16" instead of "foreigndom" to get the > pt_dom?
Because there are possibly three domains involved here: The current one (issuing the hypercall), the one owning the page, and the one owning the page table. > pt_owner is retrieved by the following line : > if ( (pt_owner = rcu_lock_domain_by_id(pt_dom - 1)) == NULL ) > My second question is: > Why should we use "pt_dom - 1" instead of "pt_dom" here? Because this consideration of three involved domains was made only after the interface was there, and hence the adjustment needed to be made such that zeros in the upper 16 bits would mean "no override", not "domain 0". See the description of this mechanism in public/xen.h. > If I set the old foreigndom (1) as (foreigndom << 16 | foreigndom) and pass > the new foreigndom as the last parameter of do_mmu_update(), and change > "pt_dom - 1" to "pt_dom", the xen-hptool will successfully make the mfn > offline. Here is the output after issuing the command:Memory > mfn 0x14ee17 offlined successfully, this page is DOM1 page and being > swapped successfully, current state is [PG_OFFLINE_OFFLINED, > PG_OFFLINE_OWNED] > > I'm wondering if this is a bug in do_mmu_update() or at least some > inconsistence is in the do_mmu_update() code? No, the above finding rather appears to indicate that the tool didn't get updated when the hypercall extension was done. I.e. if the page tables modified belong to the domain owning the page (and not the domain doing the hypercall) the invocation would need to be changed. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
