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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 07 July 2015 15:04
> 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 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 don't think that the Xan parts of XenGT are that far off. I had a list of 3 
items:

- 16 byte I/O brokenness, which should be fixed now
- Basic PV-IOMMU implementation, which I think Malcolm should be posting very 
soon
- Shadow GTT emulation (which is what we're looking at here)

I had a chat with George earlier and wondered whether we might approach things 
this way:

- Add a new sub op to HVMOP_[un]map_io_range_to_ioreq_server or a new 
HVM_[un]map_gfn_to_ioreq_server
- Make rb_rangeset the default rangeset implementation (since I believe it can 
only be an improvement even if it makes no significant difference for small 
numbers of ranges)
- Use a common implementation for MMIO ranges and GFN ranges *for now* (which 
does mean increasing the limit) to allow us to be functionally complete for 4.6
- Follow up (post-4.6) with a different ioreq server redirection implementation 
for mmio-dm and mmio-dm-write pages, possibly based on claiming a range of page 
types for emulator use, to optimize shadow GTT implementation.

Does that sound plausible?

  Paul

> Jan


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