>>> On 16.01.15 at 18:14, <edmund.h.wh...@intel.com> wrote: > On 01/16/2015 12:20 AM, Jan Beulich wrote: >>>>> On 15.01.15 at 21:38, <edmund.h.wh...@intel.com> 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. >>> >>> Can we do it this way, and then change it later if required? >> >> Without you explaining to us the full details of the in-domain >> agent model, I'm afraid this is going to remain dubious and the >> question hard to answer. In particular, if you indeed want to >> prohibit that behavior on _all_ other p2m types, how would >> subsequently changing the implementation then be compatible >> (if it can't be done this way right from the beginning)? > > I think I have explained it. There is software already commercially > available that uses a security hypervisor to partition memory at a > level below the OS page tables for Windows running on physical > hardware. We want to make that possible for Windows in a Xen domU. > The security hypervisor uses multiple EPTP's to apply different > access permissions to some guest physical addresses in different > views (p2m's) and in certain cases applies different > guest physical->host physical (gfn->mfn) mappings to some pages > between different views. The only pages to which any of these > operations is applied are pages which are rwx ram at a hardware level. > The security hypervisor works in concert with a protected agent that > runs inside the OS. > > I don't see any great difficulty at all in implementing the #VE > functionality through a p2m type initially and subsequently adding > a more generic facility. What do you see as the problem there?
You said above "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" - if in a first implementation you enforce this, and a later implementation relaxes it, the guest relying on the first implementation's behavior may break. I.e. I'm not certain whether with a later more complete implementation a guest wouldn't be required to actively request what behavior it wants, and whether making the default be how your first implementation is intended to behave is (design-/architecture-wise) reasonable. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
