Re: [Xen-devel] [V9 PATCH 6/8] pvh dom0: Add and remove foreign pages

[Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>]

On Thu, 17 Apr 2014 14:58:42 +0100
"Jan Beulich" <JBeulich@xxxxxxxx> wrote:

> >>> On 17.04.14 at 14:36, <tim@xxxxxxx> wrote:
> > At 07:50 +0100 on 17 Apr (1397717440), Jan Beulich wrote:
> >> >>> On 17.04.14 at 03:37, <mukesh.rathor@xxxxxxxxxx> wrote:
> >> > On Wed, 16 Apr 2014 17:00:35 +0100
> >> > "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> >> > 
.....
> > [I'm assuming the objection here is to having ther refcounts updated
> > in atomic_write_ept_entry, which was the change I requested.]
> > My opinion is still very strongly that reference counting must be
> > done when the entries change.  Trying to get this kind of thing
> > right in the callers is an _enormous_ PITA, as I learned working on
> > the shadow pagetables.  It would get very messy (see, e.g. the
> > myriad places where p2m op callers individually check for
> > paged/shared entries) and it'd be nigh impossible to debug where in
> > several hours of operation something changed a p2m entry from
> > foreign to something else without dropping a page ref.
> > 
> > That said, it should be easy enough only to refcount on leaf
> > entries, right?  I can't see how that would be incompatible with the
> > intermediate-node changes that Jan is working on.
> 
> Right - keeping the macro as is and introducing a derived function to
> handle the extra requirements on leaf entries would seem quite okay,
> so long as error propagation can be done properly.

Ok, thats doable.

> >> Plus
> >> their count multiplies by the number of domains managed (arguably
> >> that count should be greater than 1 only for non-Dom0 control
> >> domains, and Dom0 won't make it here anyway - which raises the
> >> question whether this change is of any practical use under the
> >> topic on the patch series, i.e. enabling PVH Dom0).

Which is why it was not part of series, but only added after nak from
Tim. Anyways, I understand and respect where h was coming from. My 
understanding was that the teardown would be pre-emptible soon, and if
not, it's not as critical overhead since it is only relevant when 
dom0/control-domain crashes while foreign pages are mapped by it.

I am happy to drop this change as part of this dom0 series, and it can
be done when PVH controlling domain gets added. Oracle product doesn't
use control domains, so I'm not a whole lot familiar with them at present. 

To your other comment: 
>Why can't this be done as pages get de-allocated (which is a
>preemptable process already)?

We are looking for foreign entries in the current privileged domain's
p2m and wanting to release refcnt on them. I don't understand which
pages being de-allocated we would look at? You mean p2m leaf pages?

thanks,
Mukesh


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