[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v4 02/10] x86/vmx: add IPT cpu feature
----- 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? While I understand the discussion and the arguments you've raised, I would like to know what particular elements should be moved where. So are we going abstract way, or non-abstract-x86 only way? Best regards, Michał Leszczyński CERT Polska
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |