[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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.


Julien Grall



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.