On 12/8/20 5:28 PM, Eduardo Habkost wrote:
> On Tue, Dec 08, 2020 at 03:34:03PM +0100, Philippe Mathieu-Daudé wrote:
>> On 12/8/20 2:55 PM, Claudio Fontana wrote:
>>> On 12/8/20 2:51 PM, Claudio Fontana wrote:
On 12/8/20 2:27 PM, Philippe Mathieu-Daudé wrote:
> On 12/7/20 10:50 PM, Peter M
On Tue, Dec 08, 2020 at 03:34:03PM +0100, Philippe Mathieu-Daudé wrote:
> On 12/8/20 2:55 PM, Claudio Fontana wrote:
> > On 12/8/20 2:51 PM, Claudio Fontana wrote:
> >> On 12/8/20 2:27 PM, Philippe Mathieu-Daudé wrote:
> >>> On 12/7/20 10:50 PM, Peter Maydell wrote:
> On Mon, 7 Dec 2020 at 21:
On 12/8/20 3:34 PM, Philippe Mathieu-Daudé wrote:
> On 12/8/20 2:55 PM, Claudio Fontana wrote:
>> On 12/8/20 2:51 PM, Claudio Fontana wrote:
>>> On 12/8/20 2:27 PM, Philippe Mathieu-Daudé wrote:
On 12/7/20 10:50 PM, Peter Maydell wrote:
> On Mon, 7 Dec 2020 at 21:26, Eduardo Habkost wrote
On 12/8/20 2:55 PM, Claudio Fontana wrote:
> On 12/8/20 2:51 PM, Claudio Fontana wrote:
>> On 12/8/20 2:27 PM, Philippe Mathieu-Daudé wrote:
>>> On 12/7/20 10:50 PM, Peter Maydell wrote:
On Mon, 7 Dec 2020 at 21:26, Eduardo Habkost wrote:
> My understanding is that there's no reason for A
On 12/8/20 2:51 PM, Claudio Fontana wrote:
> On 12/8/20 2:27 PM, Philippe Mathieu-Daudé wrote:
>> On 12/7/20 10:50 PM, Peter Maydell wrote:
>>> On Mon, 7 Dec 2020 at 21:26, Eduardo Habkost wrote:
My understanding is that there's no reason for ARM KVM to use
another approach, and that CPU
On 12/8/20 2:27 PM, Philippe Mathieu-Daudé wrote:
> On 12/7/20 10:50 PM, Peter Maydell wrote:
>> On Mon, 7 Dec 2020 at 21:26, Eduardo Habkost wrote:
>>> My understanding is that there's no reason for ARM KVM to use
>>> another approach, and that CPUClass.do_interrupt is not really
>>> TCG-specific
On 12/7/20 10:50 PM, Peter Maydell wrote:
> On Mon, 7 Dec 2020 at 21:26, Eduardo Habkost wrote:
>> My understanding is that there's no reason for ARM KVM to use
>> another approach, and that CPUClass.do_interrupt is not really
>> TCG-specific.
>>
>> Do we have any case where the CPUClass.do_interr
On Mon, 7 Dec 2020 at 21:26, Eduardo Habkost wrote:
> My understanding is that there's no reason for ARM KVM to use
> another approach, and that CPUClass.do_interrupt is not really
> TCG-specific.
>
> Do we have any case where the CPUClass.do_interrupt
> implementation is really TCG-specific, or i
On Mon, Dec 07, 2020 at 09:12:34PM +, Peter Maydell wrote:
> On Mon, 7 Dec 2020 at 21:06, Claudio Fontana wrote:
> > As I understand it, for the purpose of code separation,
> > we could:
> >
> > 1) skip do_interrupt move to the separate tcg_ops structure, wait until
> > KVM/ARM uses another a
On Mon, Dec 07, 2020 at 10:06:55PM +0100, Claudio Fontana wrote:
> On 12/7/20 9:56 PM, Peter Maydell wrote:
> > On Mon, 7 Dec 2020 at 18:28, Eduardo Habkost wrote:
> >> All signs seem to indicate that CPUClass.do_interrupt is
> >> TCG-specific, except for those two lines of code in
> >> target/arm
On 12/7/20 10:12 PM, Peter Maydell wrote:
> On Mon, 7 Dec 2020 at 21:06, Claudio Fontana wrote:
>> As I understand it, for the purpose of code separation,
>> we could:
>>
>> 1) skip do_interrupt move to the separate tcg_ops structure, wait until
>> KVM/ARM uses another approach (if ever)
>> 2) do
On Mon, 7 Dec 2020 at 21:06, Claudio Fontana wrote:
> As I understand it, for the purpose of code separation,
> we could:
>
> 1) skip do_interrupt move to the separate tcg_ops structure, wait until
> KVM/ARM uses another approach (if ever)
> 2) do the move, and just call arm_cpu_do_interrupt() di
On 12/7/20 9:56 PM, Peter Maydell wrote:
> On Mon, 7 Dec 2020 at 18:28, Eduardo Habkost wrote:
>> All signs seem to indicate that CPUClass.do_interrupt is
>> TCG-specific, except for those two lines of code in
>> target/arm/kvm64.c. The point of this patch would be to allow us
>> to separate TCG-
On Mon, 7 Dec 2020 at 20:56, Peter Maydell wrote:
> These are fairly obscure, and it wouldn't surprise me if
> other target archs had picked a different separation of
> concerns between userspace and the kernel such that userspace
> didn't need to manually deliver an exception.
...looking at the
On Mon, 7 Dec 2020 at 18:28, Eduardo Habkost wrote:
> All signs seem to indicate that CPUClass.do_interrupt is
> TCG-specific, except for those two lines of code in
> target/arm/kvm64.c. The point of this patch would be to allow us
> to separate TCG-specific code from accel-independent code later
On Mon, Dec 07, 2020 at 06:07:32PM +, Peter Maydell wrote:
> On Mon, 7 Dec 2020 at 17:49, Eduardo Habkost wrote:
> > arm_v7m_class_init() (used by cortex-* CPU models) overrides it.
> > Those CPU models as "TCG CPUs" in the code, but I don't see what
> > makes them TCG-specific.
>
> They're T
On 12/7/20 7:07 PM, Peter Maydell wrote:
> On Mon, 7 Dec 2020 at 17:49, Eduardo Habkost wrote:
>> arm_v7m_class_init() (used by cortex-* CPU models) overrides it.
>> Those CPU models as "TCG CPUs" in the code, but I don't see what
>> makes them TCG-specific.
>
> They're TCG specific because the A
On 12/7/20 7:14 PM, Peter Maydell wrote:
> On Mon, 7 Dec 2020 at 18:08, Claudio Fontana wrote:
>> what about also the existing code with qemu-arm (user mode)?
>>
>> In that case do_interrupt is not set at all in target/arm/cpu.c, since it's
>> protected by #ifndef CONFIG_USER_ONLY
>>
>> Did we ha
On Mon, 7 Dec 2020 at 18:08, Claudio Fontana wrote:
> what about also the existing code with qemu-arm (user mode)?
>
> In that case do_interrupt is not set at all in target/arm/cpu.c, since it's
> protected by #ifndef CONFIG_USER_ONLY
>
> Did we have a potential NULL pointer trying to be derefere
On Mon, 7 Dec 2020 at 17:49, Eduardo Habkost wrote:
> arm_v7m_class_init() (used by cortex-* CPU models) overrides it.
> Those CPU models as "TCG CPUs" in the code, but I don't see what
> makes them TCG-specific.
They're TCG specific because the Arm Virtualization Extension
is for A-profile only
On 12/7/20 6:49 PM, Eduardo Habkost wrote:
> On Mon, Dec 07, 2020 at 09:40:42AM +0100, Claudio Fontana wrote:
>> cc->do_interrupt is a TCG callback used in accel/tcg only,
>> call instead directly the arm_cpu_do_interrupt for the
>> injection of exeptions from KVM, so that
>>
>> do_interrupt can be
On Mon, Dec 07, 2020 at 09:40:42AM +0100, Claudio Fontana wrote:
> cc->do_interrupt is a TCG callback used in accel/tcg only,
> call instead directly the arm_cpu_do_interrupt for the
> injection of exeptions from KVM, so that
>
> do_interrupt can be exported to TCG-only operations in the CPUClass.
Claudio Fontana writes:
> cc->do_interrupt is a TCG callback used in accel/tcg only,
> call instead directly the arm_cpu_do_interrupt for the
> injection of exeptions from KVM, so that
>
> do_interrupt can be exported to TCG-only operations in the CPUClass.
>
> Signed-off-by: Claudio Fontana
On 12/7/20 9:40 AM, Claudio Fontana wrote:
> cc->do_interrupt is a TCG callback used in accel/tcg only,
> call instead directly the arm_cpu_do_interrupt for the
> injection of exeptions from KVM, so that
>
> do_interrupt can be exported to TCG-only operations in the CPUClass.
>
> Signed-off-by: C
cc->do_interrupt is a TCG callback used in accel/tcg only,
call instead directly the arm_cpu_do_interrupt for the
injection of exeptions from KVM, so that
do_interrupt can be exported to TCG-only operations in the CPUClass.
Signed-off-by: Claudio Fontana
---
target/arm/helper.c | 4
target
25 matches
Mail list logo
