Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

[Julien Grall <julien.grall@xxxxxxx>]

On 03/08/16 19:11, Tamas K Lengyel wrote:
> On Wed, Aug 3, 2016 at 11:56 AM, Julien Grall <julien.grall@xxxxxxx> wrote:
> > On 03/08/16 18:51, Tamas K Lengyel wrote:
> > > On Wed, Aug 3, 2016 at 11:45 AM, Julien Grall <julien.grall@xxxxxxx>
> > > wrote:
> > > > The whole discussion of this series was to defer the exposition of altp2m
> > > > HVMOP to the guest until we find a usage. I.e a simple:
> > > >
> > > > xsm_hvm_altp2m_op(XSM_PRIV/XSM_DM_PRIV, d);
> > > >
> > > > So why do you want to re-invent a new interface here?
> > >
> > > I guess I misinterpreted your request of not having this interface
> > > exposed to the guest. If we are fine with exposing the interface to
> > > the guest but having XSM manage whether it's allowed by default I'm
> > > certainly OK with that.
> >
> > By default the interface will not be exposed to the guest.
> > XSM_PRIV/XSM_DM_PRIV only allow a privileged domain or a device model domain
> > to use the interface. The guest will not be enabled to access it.
> Yes. I guess our terminology differs about what we mean by "exposed".
> In my book if the interface is available to the guest but access
> attempts are denied by XSM that means the interface is exposed but
> restricted.
Although the behavior is very different compare to what x86 does. By 
default the guest will be able to play with altp2m.
That was always my point, hence why I said there will be no issue to 
allow a guest accessing altp2m later on.
Andrew, is that what you had in mind?

Regards,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel