[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi Jan,

2015-04-23 4:14 GMT-04:00 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.

I see. :-)

>
> > 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.

Right! Now I understand the whole story. :-)

Right now, `xen-hptool mem-offline <mfn>` does not take the <domid>,
to which the <mfn> belongs. I think this tool should take the <domid>
as an extra parameter just as `xen-mfndump lookup-pte <domid> <mfn>`
does. When the tool construct the foreigndom for mmu, it should make
the foreigndom as ((pt_owner_id + 1 << 16) | pg_owner_id).

Am I correct?

Thank you so much for your insightful explanation! It really helps!

Best regards,

Meng


-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.