[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 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...


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

Julien Grall


could you express your final decision on this topic?

Can you move the acquire implementation from x86 to common code?


Julien Grall



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