qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC 1/3] qtest: Prepare hypercall support


From: Andreas Färber
Subject: Re: [Qemu-devel] [RFC 1/3] qtest: Prepare hypercall support
Date: Fri, 25 Jan 2013 15:49:53 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130105 Thunderbird/17.0.2

Am 25.01.2013 12:27, schrieb Alexander Graf:
> 
> On 23.01.2013, at 11:01, Andreas Färber wrote:
> 
>> diff --git a/include/sysemu/qtest.h b/include/sysemu/qtest.h
>> index 723a4f9..75ab29d 100644
>> --- a/include/sysemu/qtest.h
>> +++ b/include/sysemu/qtest.h
>> @@ -32,6 +32,8 @@ static inline int qtest_available(void)
>> }
>>
>> int qtest_init(void);
>> +bool qtest_hypercall_supported(void);
>> +int qtest_hypercall(uint64_t code, uint64_t *args);
>> #else
>> static inline bool qtest_enabled(void)
>> {
>> diff --git a/qtest.c b/qtest.c
>> index c9b58ce..a5b54e3 100644
>> --- a/qtest.c
>> +++ b/qtest.c
>> @@ -117,6 +117,11 @@ 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).
>> + *
>> + * Hypercalls:
>> + *
>> + * > hypercall CODE
>> + * < OK
>>  */
>>
>> static int hex2nib(char ch)
>> @@ -344,6 +349,27 @@ static void qtest_process_command(CharDriverState *chr, 
>> gchar **words)
>>         qtest_clock_warp(ns);
>>         qtest_send_prefix(chr);
>>         qtest_send(chr, "OK %"PRIi64"\n", 
>> (int64_t)qemu_get_clock_ns(vm_clock));
>> +    } else if (strcmp(words[0], "hypercall") == 0 &&
> 
> I don't think we will be able to find a common d[en]ominator for hypercall 
> ABIs across the board. So this one should be called s390_kvm_hypercall, as 
> that's what you are really modeling :).

If that is so, the stated issue remains that this qtest.c is generic
code. So if we add a qtest_s390x_hypercall() and qtest_ppc_hypercall()
we need to add matching stubs for each and some mechanism to suppress
them or error out in all other environments. Where exactly do you see
differences? The number of arguments is kept variable here. The same
could be done for return values. Wider than uint64_t arguments are
pretty unlikely, no?

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

[Prev in Thread] Current Thread [Next in Thread]