From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ed White Subject: Re: [PATCH 07/11] x86/altp2m: introduce p2m_ram_rw_ve type. Date: Fri, 16 Jan 2015 10:35:01 -0800 Message-ID: <54B959D5.3010008@intel.com> References: <1420838801-11704-1-git-send-email-edmund.h.white@intel.com> <1420838801-11704-8-git-send-email-edmund.h.white@intel.com> <20150115170344.GG57240@deinos.phlegethon.org> <54B8253E.2080900@intel.com> <20150116175252.GE48064@deinos.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150116175252.GE48064@deinos.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan Cc: keir@xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com, jbeulich@suse.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 01/16/2015 09:52 AM, Tim Deegan wrote: > At 12:38 -0800 on 15 Jan (1421321902), Ed White wrote: >> On 01/15/2015 09:03 AM, Tim Deegan wrote: >>> At 13:26 -0800 on 09 Jan (1420806397), Ed White wrote: >>>> This is treated exactly like p2m_ram_rw, except that suppress_ve is not >>>> set in the EPTE. >>> >>> I don't think this is going to work -- you probably want to support >>> p2m_ram_ro at least, and maybe other types, but duplicating each of >>> them as a 'type foo with #VE' doesn't seem right. >>> >>> Since the default is to set the ignore-#ve flag everywhere, how about >>> having an operation to enable #ve for a frame that just clears that >>> bit, and then having all other updates to altp2m entries preserve it? >> >> I hear you, but #VE is only even relevant for the in-domain agent >> model, and as the only current user of that model we not only don't >> want #VE to work on other page types, we specifically want it to be >> prohibited. > > I see. I think it would be very useful if you could add some > documentation of the new feature, covering this sort of thing, as well > as the exact semantics of the hypercalls. > >> Can we do it this way, and then change it later if required? > > No thank you. It shouldn't be hard to do it the clean way from the > start. The problem with doing it the clean way is that I have to use EPTE bit 63 even on hardware that doesn't support it. That's not a problem hardware-wise, because, at least for Intel, bit 63 is don't care for non-#VE hardware. It does mean Xen can't use it for anything else though. If you look at the code in the current patch series, for non-#VE hardware I don't use that bit, the nested page fault handler decides whether to emulate #VE based on the p2m_type value. Ed