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

["Jan Beulich" <JBeulich@suse.com>]

>>> On 07.07.15 at 17:12, <Paul.Durrant@citrix.com> wrote:
> 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

No matter how soon Malcolm would post that, unless it is in a shape
to go in without any revisions, it will - afaict - miss 4.6 (freezing at
the end of the week). I can't even guarantee that your HVM
emulation updates will have gone in by then, but I very much hope
so.

> - 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?

Yes, except that I think all of this will be post-4.6.

Jan