Re: [PATCH v4 02/10] x86/vmx: add IPT cpu feature

[Julien Grall <julien@xxxxxxx>]

On 02/07/2020 15:17, Jan Beulich wrote:
> On 02.07.2020 16:14, Julien Grall wrote:
> > On 02/07/2020 14:30, Jan Beulich wrote:
> > > On 02.07.2020 11:57, Julien Grall wrote:
> > > > On 02/07/2020 10:18, Jan Beulich wrote:
> > > > > On 02.07.2020 10:54, Julien Grall wrote:
> > > > > > On 02/07/2020 09:50, Jan Beulich wrote:
> > > > > > > On 02.07.2020 10:42, Julien Grall wrote:
> > > > > > > > On 02/07/2020 09:29, Jan Beulich wrote:
> > > > Another way to do it, would be the toolstack to do the mapping. At which
> > > > point, you still need an hypercall to do the mapping (probably the
> > > > hypercall acquire).
> > > There may not be any mapping to do in such a contrived, fixed-range
> > > environment. This scenario was specifically to demonstrate that the
> > > way the mapping gets done may be arch-specific (here: a no-op)
> > > despite the allocation not being so.
> > You are arguing on extreme cases which I don't think is really helpful
> > here. Yes if you want to map at a fixed address in a guest you may not
> > need the acquire hypercall. But in most of the other cases (see has for
> > the tools) you will need it.
> >
> > So what's the problem with requesting to have the acquire hypercall
> > implemented in common code?
> Didn't we start out by you asking that there be as little common code
> as possible for the time being?
Well as I said I am not in favor of having the allocation in common 
code, but if you want to keep it then you also want to implement 
map/unmap in the common code ([1], [2]).
> I have no issue with putting the
> acquire implementation there ...
This was definitely not clear given how you argued with extreme cases...

Cheers,

[1] <9a3f4d58-e5ad-c7a1-6c5f-42aa92101ca1@xxxxxxx>
[2] <cf41855b-9e5e-13f2-9ab0-04b98f8b3cdd@xxxxxxx>

--
Julien Grall