Re: [Xen-devel] Possible bug/question in xen-hptool?

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.04.15 at 06:03, <xumengpanda@xxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel