[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 02/12] qtest: add spapr hypercall support
From: |
Anthony Liguori |
Subject: |
Re: [Qemu-devel] [PATCH 02/12] qtest: add spapr hypercall support |
Date: |
Thu, 20 Jun 2013 10:42:28 -0500 |
User-agent: |
Notmuch/0.15.2+77~g661dcf8 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) |
Andreas Färber <address@hidden> writes:
> Am 19.06.2013 22:40, schrieb Anthony Liguori:
>> Signed-off-by: Anthony Liguori <address@hidden>
>> ---
>> qtest.c | 29 +++++++++++++++++++++++++++++
>> tests/libqtest.c | 18 ++++++++++++++++++
>> tests/libqtest.h | 46 ++++++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 93 insertions(+)
>>
>> diff --git a/qtest.c b/qtest.c
>> index 07a9612..f8c8f44 100644
>> --- a/qtest.c
>> +++ b/qtest.c
>> @@ -19,6 +19,9 @@
>> #include "hw/irq.h"
>> #include "sysemu/sysemu.h"
>> #include "sysemu/cpus.h"
>> +#ifdef TARGET_PPC64
>> +#include "hw/ppc/spapr.h"
>> +#endif
>>
>> #define MAX_IRQ 256
>>
>> @@ -141,6 +144,13 @@ static bool qtest_opened;
>> * where NUM is an IRQ number. For the PC, interrupts can be intercepted
>> * simply with "irq_intercept_in ioapic" (note that IRQ0 comes out with
>> * NUM=0 even though it is remapped to GSI 2).
>> + *
>> + * Platform specific (sPAPR):
>> + *
>> + * > papr_hypercall NR ARG0 ARG1 ... ARG8
>
> The functions are called spapr_hcall*() but the protocol uses
> papr_hypercall?
The discrepancy is inherited in the KVM vs. QEMU interfaces. It's
called papr_hypercall in the KVM interface vs. spapr in QEMU.
I honestly don't know what the distinction between spapr and papr is.
>> +static inline uint64_t spapr_hcall5(uint64_t nr, uint64_t a0, uint64_t a1,
>> + uint64_t a2, uint64_t a3, uint64_t a4)
>> +{
>> + return qtest_spapr_hcall9(global_qtest, nr, a0, a1, a2, a3, a4, 0, 0,
>> 0, 0);
>> +}
>
> While for a large number of almost identical helpers this certainly
> sucks, I made an effort to document all functions in that file, so
> please keep it that way. :)
Seems a bit redundant to document every one of these but I don't mind
doing it.
Regards,
Anthony Liguori
>
> Looks very similar to what I had proposed for s390x, so fine with me.
>
> Regards,
> Andreas
>
>> +
>> #endif
>>
>
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg