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

Re: [Xen-devel] [PATCH v3 07/10] xen/arm: Add handling write fault for dirty-page tracing

On Tue, 2013-08-06 at 20:56 +0900, Jaeyong Yoo wrote:
> > I hope my description of a linear map makes sense, hard to do without a
> > whiteboard ;-)
> Thanks a lot for the ascii art! Even without whiteboard, it works very
> nicely for me :)

Oh good, I was worried I'd made it very confusing !

> I think I understand your points. Previously, in my implementation, I 
> created the Xen mapping to leaf PTE of the P2M by looking up the guest 
> leaf p2m and create_xen_table, but everything could be better if I just 
> map the xen_second to the guest's P2M first. Then, by just reading the 
> correct VA, I can immediately access leaf PTE of guest p2m.


> As a minor issue, I don't correctly understand your numbers within 
> XEN_SECOND[64..80] for p2m third and XEN_SECOND[80..144] for p2m second. 
> I think p2m third should have larger VA ranges than the one in p2m second.

The numbers are slot number (i.e. entries) within the xen_second table.

I think I was just a bit confused, the p2m_second entry only actually
needs one entry I think, since you just need it to loopback to the entry
containing the p2m_third mapping.

> If I'm not mistaken, if we try to migrate domU with memory size 4GB, it
> requires VA sizes of 8MB for p2m third and 16KB for p2m second.

Sounds about right. The reason I used 16 slots is that we, at least in
theory, support domU memory size up to 16GB and each slot == 1GB.

> Since we have 128MB size for vlpt, how about allocating vlpt for different 
> ranges 
> within 128MB to each migrating domU? This way, we don't need to context 
> switch the xen second page tables. Although it limits the simultaneous 
> live migration with large memory size DomU's, but for ARM, I think it is 
> reasonable.

You'd only be able to fit 4, I think, if supporting 16GB guests. I'm not
sure how I feel about making a slightly random limitation like that.

Why don't we just context switch the slots for now, only for domains
where log dirty is enabled, and then we can measure and see how bad it
is etc.


Xen-devel mailing list



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