Re: [Xen-devel] [PATCH v2 1/2] Resize the MAX_NR_IO_RANGES for ioreq server

["Yu, Zhang" <yu.c.zhang@xxxxxxxxxxxxxxx>]

Hi Jan,

On 7/7/2015 10:04 PM, Jan Beulich wrote:
> > > > On 07.07.15 at 15:11, <Paul.Durrant@xxxxxxxxxx> wrote:
> > >   -----Original Message-----
> > > From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> > > Sent: 07 July 2015 13:53
> > > To: Paul Durrant
> > > Cc: Andrew Cooper; George Dunlap; Kevin Tian; zhiyuan.lv@xxxxxxxxx; Zhang
> > > Yu; xen-devel@xxxxxxxxxxxxx; Keir (Xen.org)
> > > Subject: RE: [Xen-devel] [PATCH v2 1/2] Resize the MAX_NR_IO_RANGES for
> > > ioreq server
> > >
> > > > > > On 07.07.15 at 11:23, <Paul.Durrant@xxxxxxxxxx> wrote:
> > > > I wonder, would it be sufficient - at this stage - to add a new mapping sub-
> > > op
> > > > to the HVM op to distinguish mapping of mapping gfns vs. MMIO ranges.
> > > That
> > > > way we could use the same implementation underneath for now (using
> > > the
> > > > rb_rangeset, which I think stands on its own merits for MMIO ranges
> > > anyway)
> > >
> > > Which would be (taking into account the good description of the
> > > differences between RAM and MMIO pages given by George
> > > yesterday [I think])? I continue to not be convinced we need
> > > this new rangeset type (the more that it's name seems wrong,
> > > since - as said by George - we're unlikely to deal with ranges
> > > here).
> > I don't see that implementing rangesets on top of rb tree is a problem. IMO
> > it's a useful optimization in its own right since it takes something that's
> > currently O(n) and makes it O(log n) using an rb tree implementation that's
> > already there. In fact, perhaps we just make the current rangeset
> > implementation use rb trees underneath, then there's no need for the extra
> > API.
> I wouldn't mind such an overall change (provided it doesn't
> introduce new issues), but I'm not convinced of having two
> rangeset implementations, and I don't see the lookup speed
> as an issue with the uses we have for rangesets now. The
> arguments for bumping the number of ranges, which would
> possibly affect lookup in a negative way, haven't been
> convincing to me so far (and XenGT isn't going to make 4.6
> anyway).
I know that George and you have concerns about the differences
between MMIO and guest page tables, but I do not quite understand
why. :)

Althogh the granularity of the write-protected memory is 4K in our
case, the trapped address is still a guest physical address, not a
guest page frame number. We can see the range as an 4K sized one,
right? Besides, in many cases, the guest graphic page tables are
continuous and the size of a range inside ioreq server is more than
4k. As you can see, the existing code already tracks the guest graphic
page tables by rangeset, and the difference here is that there would
be more page tables we need to take care of for BDW. Changing the
upper limit of the number of rangeset inside an ioreq server does
not necessarily mean there would be so many.

About the rb_rangeset I introduced, it is only for XenGT case,
because only in such cases will a more efficient data structure be
necessary - maybe in the future there would be more requirements to
this type.

Yes, XenGT may not catch up the 4.6. And thanks for your frankness. :)
But I'll still be very appreciated if you can give me some advices
and directions to go.

B.R.
Yu
> Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel