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

[Julien Grall <julien@xxxxxxx>]

Hi Jan,

On 02/07/2020 09:29, Jan Beulich wrote:
> On 01.07.2020 20:09, Julien Grall wrote:
> > On 01/07/2020 19:06, Andrew Cooper wrote:
> > > On 01/07/2020 19:02, Julien Grall wrote:
> > > > On 01/07/2020 18:26, Andrew Cooper wrote:
> > > > > For the sake of what is literally just one byte in common code, I stand
> > > > > my original suggestion of this being a common interface.  It is not
> > > > > something which should be x86 specific.
> > > > This argument can also be used against putting in common code. What I
> > > > am the most concern of is we are trying to guess how the interface
> > > > will look like for another architecture. Your suggested interface may
> > > > work, but this also may end up to be a complete mess.
> > > >
> > > > So I think we want to wait for a new architecture to use vmtrace
> > > > before moving to common code. This is not going to be a massive effort
> > > > to move that bit in common if needed.
> > > I suggest you read the series.
> > Already went through the series and ...
> >
> > > The only thing in common code is the bit of the interface saying "I'd
> > > like buffers this big please".
> > ... I stand by my point. There is no need to have this code in common
> > code until someone else need it. This code can be easily implemented in
> > arch_domain_create().
> I'm with Andrew here, fwiw, as long as the little bit of code that
> is actually put in common/ or include/xen/ doesn't imply arbitrary
> restrictions on acceptable values.
Well yes the code is simple. However, the code as it is wouldn't be 
usuable on other architecture without additional work (aside arch 
specific code). For instance, there is no way to map the buffer outside 
of Xen as it is all x86 specific.
If you want the allocation to be in the common code, then the 
infrastructure to map/unmap the buffer should also be in common code. 
Otherwise, there is no point to allocate it in common.
Cheers,

--
Julien Grall