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

Re: [Xen-devel] [PATCH v2 5/6] ioreq-server: add support for multiple servers

  • To: George Dunlap <dunlapg@xxxxxxxxx>
  • From: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
  • Date: Tue, 11 Mar 2014 17:32:17 +0000
  • Accept-language: en-GB, en-US
  • Cc: "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>
  • Delivery-date: Tue, 11 Mar 2014 17:32:22 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: AQHPN56Wy5IdaTYGXE+fbEp/ZmSbm5raoJqAgAETpzCAAF8xgIAAG0wQ
  • Thread-topic: [Xen-devel] [PATCH v2 5/6] ioreq-server: add support for multiple servers

> -----Original Message-----
> Speaking of adding more emulators: After some more thinking, I'm not
> sure that baking the layout of the ioreq and buf_ioreq pages into Xen,
> the way the current patch series does, is a good idea.  At the moment,
> you set HVM_PARAM_[BUF]IOREQ_PFN, and assume that all the emulators
> will be contiguous.  Would it be better to introduce an interface to
> allow arbitrary pages to be used for each ioreq server as it's created
> (grandfathering in sid 0 to use the HVM_PARAMs)?  Then you wouldn't
> need to mark off pfn space to use for ioreq servers during domain
> creation at all.

Well, there still needs be a suitable hole in guest pfn space. Would you be 
happy leaving the existing HVM params alone then and adding a new pair of 
params for base and range of a new pfn space (the range one replacing the 
max_emulators HVM param - since it'll be 2 * (max_emulators - 1))?


Xen-devel mailing list



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