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

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

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-
to the HVM op to distinguish mapping of mapping gfns vs. MMIO ranges.
way we could use the same implementation underneath for now (using
rb_rangeset, which I think stands on its own merits for MMIO ranges

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

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

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

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.


Xen-devel mailing list



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