On Tue, 28 Jul 2020 at 11:00, Philippe Mathieu-Daudé wrote:
> Apparently kvm_enabled() checks CONFIG_KVM_IS_POSSIBLE instead
> of CONFIG_KVM, I suppose to bypass this limitation (from osdep.h):
>
> 21 #ifdef NEED_CPU_H
> 22 # ifdef CONFIG_KVM
> 24 # define CONFIG_KVM_IS_POSSIBLE
> 25 # endif
On 7/28/20 11:56 AM, Philippe Mathieu-Daudé wrote:
> On 7/28/20 11:53 AM, Peter Maydell wrote:
>> On Tue, 28 Jul 2020 at 10:51, Philippe Mathieu-Daudé
>> wrote:
>>> I'd rather uninline xen_enabled() but I'm not sure this has perf
>>> penalties. Paolo is that OK to uninline it?
>
> I suppose no b
On 7/28/20 11:53 AM, Peter Maydell wrote:
> On Tue, 28 Jul 2020 at 10:51, Philippe Mathieu-Daudé
> wrote:
>> I'd rather uninline xen_enabled() but I'm not sure this has perf
>> penalties. Paolo is that OK to uninline it?
I suppose no because it is in various hot paths:
exec.c:588:if (xen_en
On Tue, 28 Jul 2020 at 10:51, Philippe Mathieu-Daudé wrote:
> I'd rather uninline xen_enabled() but I'm not sure this has perf
> penalties. Paolo is that OK to uninline it?
Can we just follow the same working pattern we already have
for kvm_enabled() etc ?
thanks
-- PMM
On 7/28/20 11:27 AM, Peter Maydell wrote:
> On Tue, 28 Jul 2020 at 10:19, Paul Durrant wrote:
>>
>> From: Paul Durrant
>>
>> The recent commit da278d58a092 "accel: Move Xen accelerator code under
>> accel/xen/" introduced a subtle semantic change, making xen_enabled() always
>> return false unles
On Tue, 28 Jul 2020 at 10:19, Paul Durrant wrote:
>
> From: Paul Durrant
>
> The recent commit da278d58a092 "accel: Move Xen accelerator code under
> accel/xen/" introduced a subtle semantic change, making xen_enabled() always
> return false unless CONFIG_XEN is defined prior to inclusion of syse
From: Paul Durrant
The recent commit da278d58a092 "accel: Move Xen accelerator code under
accel/xen/" introduced a subtle semantic change, making xen_enabled() always
return false unless CONFIG_XEN is defined prior to inclusion of sysemu/xen.h,
which appears to be the normal case. This causes var
