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

[Jaeyong Yoo <jaeyong.yoo@xxxxxxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel-
> bounces@xxxxxxxxxxxxx] On Behalf Of Ian Campbell
> Sent: Tuesday, August 06, 2013 10:17 PM
> To: Jaeyong Yoo
> Cc: xen-devel@xxxxxxxxxxxxx; 'Stefano Stabellini'
> Subject: 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.
> 
> Correct.
> 
> > 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.

OK. It is no problem. 

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


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