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

[Julien Grall <julien@xxxxxxx>]

Hi,

On 02/07/2020 21:28, Michał Leszczyński wrote:
> ----- 2 lip 2020 o 16:31, Julien Grall julien@xxxxxxx napisał(a):
>
> > 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
>
> Guys,
>
> could you express your final decision on this topic?
Can you move the acquire implementation from x86 to common code?

Cheers,

--
Julien Grall