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

[Julien Grall <julien@xxxxxxx>]

Hi,

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:
> > > > > 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.
> > > I don't think I agree here - I see nothing wrong with exposing of
> > > the memory being arch specific, when allocation is generic. This
> > > is no different from, in just x86, allocation logic being common
> > > to PV and HVM, but exposing being different for both.
> > Are you suggesting that the way it would be exposed may be different for
> > other architecture?
> Why not? To take a possibly extreme example - consider an arch
> where (for bare metal) the buffer is specified to appear at a
> fixed range of addresses.
I am probably missing something here... The current goal is the buffer 
will be mapped in the dom0. Most likely the way to map it will be using 
the acquire hypercall (unless you invent a brand new one...).
For a guest, you could possibly reserve a fixed range and then map it 
when creating the vCPU in Xen. But then, you will likely want a fixed 
size... So why would you bother to ask the user to define the size?
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).
> > If so, this is one more reason to not impose a way for allocating the
> > buffer in the common code until another arch add support for vmtrace.
> I'm still not seeing why allocation and exposure need to be done
> at the same place.
If I were going to add support for CoreSight on Arm, then the acquire 
hypercall is likely going to be the way to go for mapping the resource 
in the tools. At which point this will need to be common.
I am still not entirely happy to define the interface yet, but this 
would still be better than trying to make the allocation in common code 
and the leaving the mapping aside. After all, this is a "little bit" 
more code.
Cheers,

--
Julien Grall