From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ed White Subject: Re: [PATCH 00/11] Alternate p2m: support multiple copies of host p2m Date: Fri, 16 Jan 2015 09:01:09 -0800 Message-ID: <54B943D5.90306@intel.com> References: <1420838801-11704-1-git-send-email-edmund.h.white@intel.com> <20150115161519.GA57240@deinos.phlegethon.org> <54B805B0.8090604@intel.com> <54B8D6080200007800055AE2@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54B8D6080200007800055AE2@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: keir@xen.org, Tim Deegan , ian.jackson@eu.citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 01/16/2015 12:12 AM, Jan Beulich wrote: >>>> On 15.01.15 at 19:23, wrote: >> On 01/15/2015 08:15 AM, Tim Deegan wrote: >>> - Feature compatibilty/completeness. You pointed out yourself that >>> it doesn't work with nested HVM or migration. I think I'd have to >>> add mem_event/access/paging and PCI passthrough to the list of >>> features that ought to still work. I'm resigned to the idea that >>> many new features don't work with shadow pagetables. :) >>> >> >> The intention is that mem_event/access should still work. I haven't >> specifically looked at paging, but I don't see any fundamental reason >> why it shouldn't. PCI passthrough I suspect won't. Does nested HVM >> work with migration? Is it simply not acceptable to submit a feature >> as experimental, with known compatibility issues? I had assumed that >> it was, based on the nested HVM status as documented in the release >> notes. > > It is generally acceptable, sure. But the sad thing here is that > particularly with such code coming from Intel (with the nested > VMX code being a good example, and certain IOMMU/pass- > through things being another) my experience is that once that > initial code drop happened, interest from the original authors is > lost (possibly not maliciously, but because of being assigned other > tasks) and the code therefore has to remain experimental for > extended periods of time (often until someone else gets > frustrated enough about its half baked state to spend non- > negligible amounts of time to deal with the loose ends). I can't make any guarantees, I'm just one person and I do what the people who pay me tell me to do. What I can tell you is that our primary motivation for producing this patch series is that we have an internal customer already shipping Xen-based products who wants to use these capabilities. That customer isn't going to go away, and isn't going to want to support something half-baked. Ed